LeshicТо еслть легко сожно было провести по кредиту 51 рубли, а на дебете 57 увидеть доллары и т.п.Видел я эту штуку в Scala - и был шокирован. Там можно было не только такие кренделя выписывать, но и провести на дебете 10 рублей, а на кредите - 20 рублей. Я не считаю это достижением. Ничего хорошего или полезного он не дает, за исключением высокой вероятности ошибок, приводящих к нарушению оборотно-сальдового баланса. Фактически этот подход игнорирует правила двойной записи.

У меня нет опыта работы в OEBS и небольшой опыт работы с парусом, поэтому буду говорить про то, что хорошо знаю - про ИНФИН, полагая, что в других продуктах концепции могут быть схожими. В ИНФИНе счета могут быть нескольких видов - бухгалтерские балансовые, бухгалтерские забалансовые, налоговые и вспомогательные. Если вы завели бухгалтерский балансовый счет, то как бы вы не кувыркались, вам не удастся никогда нарушить баланс, даже если вы попытаетесь намеренно внести какие-то ошибки в настройки проводок. Бухгалтерские балансовые счета могут корреспондировать только друг с другом (и это правильно!). Для счетов трех остальных видов нарушение принципа двойной записи вполне допустимо. В настройке групповой операции может быть задействована последовательность взаимоувязанных действий над счетами разного вида, ничто не мешает выполнять проводки по нескольким счетам разного вида таким образом, чтобы их суммы и аналитики зависели друг от друга, но оборотно-сальдовый баланс нарушить не удастся ни при каком раскладе.

Рассмотрим конкретный пример. Реализация коммисионером принятого ранее на реализацию товара. Участвуют счета:
040 "Товары, принятые на комиссию" - забалансовый, на нем ведется количественный учет товаров в продажных рублевых ценах (не ведется валюта)
90/1 "Доходы" - балансовый, рублевый, учет количества не ведется
76/1 "Расчеты с дебиторами/кредиторами в валюте" - балансовый, рублевый и валютный, количественный учет не ведется
68/2 "Расчеты по НДС" - балансовый, рублевый, количественный учет не ведется

Вариант многострочной проводки Scala:
1. Кредит счета 040 1000 рублей 2 шт - с забалансового счета ушел товар по продажной стоимости
2. Кредит счета 90/1 42.37 рублей - начислен доход от комисионного вознаграждения
3. Дебет счета 76/1 50 рублей, 1.7 USD - отражена задолженность валютного комитента перед комиссионером
4. Кредит счета 68/2 7.63 рублей - начислен НДС на комисионное вознаграждение.

Если вы сложите в этой проводке все дебеты и кредиты, вы увидете, что сумма дебетов не равна сумме кредитов. Это нормально, потому что один из счетов - забалансовый.

Аналогичный вариант "стандартной" (групповой) проводки ИНФИНа:
1. Д 040 К (пусто) 1000 рублей 2 шт - с забалансового счета ушел товар по продажной стоимости. Внимание! Поскольку счет 040 забалансовый, ИНФИН разрешил НЕ указывать корреспондирующий счет, а значит, нарушение принципа двойной записи. Но только в этой проводке - №1!
2. Д 76/1 К 90/1 42.37 рублей, 1.44 USD - начислен доход от комисионного вознаграждения
3. Д 76/1 К 68/2 7.63 рублей, 0.26 USD - начислен НДС на комисионное вознаграждение. При выполнении этой проводки аналитика "орагнизация" счета 76/1 автоматически берется из аналитики этого же счета проводки №2. Если счета 040 и 76/1 завязаны на один и тот же справочник организаций (возможно, на разных аналитических уровнях), то при выполнении проводки №2 информация об организации тоже может быть автоматически подставлена - из проводки №1. Суммы НДС расчитаны по ставке 18%, что вводится, а что расчитывается - задается настройкой.

Смотрим, в чем разница между Scala и ИНФИН. Разница в том, что сумма рублевая, валютная и количество в ИНФИНе являются атрибутом элементарной ПРОВОДКИ, то есть относятся одновременно и к дебетовой и к кредитовой части. ИНФИН не даст нарушить баланс, не указав для балансового счета 76/1 в проводке №2 или №3 корреспондирующий, не только в момент выполнения проводки, но даже в настройке этой групповой операции. Таким образом, указанная сумма в любом случае отражается сразу на двух счетах - что и выражает требования правила "двойной записи".
Рассмотрим ИНФИН-овскую проводку №2. В ней фигурируют счета 76/1 и 90/1, при этом счет 76/1 - валютный, а 90/1 - рублевый. Рублевая сумма должна быть указана обязательно для обоих счетов, поскольку рубль - это валюта баланса. Раз в проводке участвует хотя бы один валютный счет, то запрашивается валютная сумма, которая записывается ТОЛЬКО на счет 76/1. То есть, на счет 76/1 записывается и рублевая, и валютная сумма, а на счет 90/1 - только рублевая. Если бы корреспондировались два влютных счета, валютная сумма вместе с рублевой одновременно нашла бы отражение на обеих счетах. Примерно так же себя ведет привязка количества. Если ни один из корреспондирующих счетов не настроен на учет количества, значит количество запрашиваться не будет (даже в настройке это поле пропадает). Если один из счетов настроен на учет количества, количество будет запрашиваться, но при выполнении проводки оно записывается только на один счет. Если оба корреспондирующих счета настроены на количественный учет, одно и то же количество будет записано на разные стороны двух счетов при выполнении проводки.

Где я вижу еще существенную разницу между методами отражения информации Scala и ИНФИН? В информации, отраженной на счете 76/1. Если просматривать эту информацию средствами Scala, без настройки специальных отчетов и дополнительных кувырканий вы не сможете сразу ответить на вопрос, как разбилась отраженная на этом счете сумма на НДС и доход. В ИНФИНе это сразу видно, поскольку на самом счете 76/1 отражена не одна проводка, а две - в каждой свой корреспондирующий счет, у каждой свой комментарий, своя валютная и рублевая сумма. Сразу всё видно. Можно информацию свернуть, можно развернуть, никаких специальных отчетов настраивать не нужно.

Но самое главное - в ИНФИНе вы никогда не сможете, даже преднамеренными действиями нарушить баланс для балансовых счетов. В Scala - запросто. Есть, правда, отчеты, которые позволяют найти причины нарушения баланса, но я считаю, что лучше не допускать нарушений, нежели допускать, а потом выискивать их причины.

Теперь - главное. Попробуйте ответить на вопрос "зачем"? Зачем вам так понадобились эти "многострочные проводки"? Какой цели вы пытаетесь добиться? Нарушить баланс? Кому и зачем это нужно? Если у вас нет цели нарушать баланс, и вы хотите выполнить учетные операции на вспомогательных (для управленческого только учета) счетах, то для этого можно использовать одностороннюю запись, но предварительно сообщив системе, что счет НЕ балансовый (см. проводку, сделанную по счету 040).

Если речь идет о возможности указания РАЗНЫХ валют, причем, отличающихся от валюты баланса, для корреспондирующих счетов, то в любом случае приведение курсов проивзодится через валюту баланса. Иначе станет невозможным автоматический расчет курсовых разниц.

LeshicНельзя там было нарушать баланс стандартными средствами
только нестандартными
такие же балансовые и забаланосвые счета
сумма балансовых счетов в проводке 0Я был на 1-дневном семинаре по Scala, мне это продемонстрировали, выдав за достижение. Возможно, это нестандартный подход, который я принял за общепринятый.

LeshicНапример сделать взаимозачет USD c EUR в одной операции
в инфине это будут две опреации через рубли???Конкретно в ИНФИНе - невозможно. Это концептуальная особенность - те атрибуты проводки, которые совпадают с атрибутами дебетового и/или кредитового счета, принимают то же самое значение, что и указанное в проводке МЕЖДУ счетами.
Теоретически можно разрешить запись в дебет и в кредит пар сумм, одна из которых является опорной (то есть, указана в валюте баланса). В ИНФИНе практически это сделать невозможно. Только через вспомогательный счет. Так сказать, технические нюансы модель-концепции :)...

Но это не так страшно, как может показаться. Нужно четко понимать, что в системе имеется валюта баланса, в которой абсолютно все валютное и не валютное должно оцениваться в обязательном порядке. При изменении курса оценка оказывается искаженной, и требуется с помощью проводок на сумму курсовых разниц (корреспонденция между рублевым и валютным счетом) это искажение устранить. Валютные курсы ЦБ РФ публикуются только по отношению к рублю. Пожно попытаться вывести "взаимные", "межвалютные" курсы, но на самом деле это не совсем корректно. Таких курсов нет - это вычисляемая величина, которая зависит сразу от нескольких параметров. Она может измениться одним способом, если изменился официальный курс одной валюты, другим способом, если изменился курс другой валюты и третим способом, если изменились оба курса. В любом случае исходными являются курсы валют относительно рубля, а не относительно друг друга.

В РСБУ нет никаких операций, которые хотя бы теоретически могут потребовать прямой корреспонденции валютных счетов в разных валютах. Это некорректная корреспонденция. В любом случае перевод из одной валюты в другую, например, на банковских счетах, проходит процедуру конвертации валюты (за которую банк берет комиссию, что отражается на всей совокупности проводок). "Волшебных" превращений одной валюты в другую быть не может в принципе.

LeshicЯ пытаюсь правильно настроить переоценку в OEBS по данным приходящим из паруса. Вот допустим есть СФ в рублях КТ 60
и платеж по этому СФ в УЕ ДТ 60
как это будет в инфине
Дт 20 Кт 60 300 РУБ
Дт 60 Кт 51 10 УЕ 300 РУБ
Дальше что-нибудь будет???Оп! Это же совсем другая постановка вопроса! Тут речь идет не о курсовых, а о суммовых разницах! Суммовые разницы возникают на рублевых счетах, если платеж осуществляется в рублях, но цены выражены в USD, EUR, или даже в убитых енотах по курсу на момент платежа . Но возникают суммовые разницы НЕ ВСЕГДА. В частности, если произведена 100%-ная предоплата, то при последующей отгрузке можно просто посмотреть, когда был произведен платеж, "в уме" прикинуть валютный (или УЕ-шный) эквивалент, убедиться, что он соответствует достигнутым договоренностям, и дальше просто сделать проводку по реализации на ту же рублевую сумму, на которую ранее был получен платеж. Если же сначала производится отгрузка, а оплата еще не поступила и неизвестно, когда она поступит, по правилам бухгалтерского и налогового учета выраженная в валюте цена приводится к рублевому эквиваленту по курсу ЦБ РФ. Полученная таким способом сумма и отражается в бухучете и в налоговом учете как временная оценка переданных между сторонами ценностей. Очень важный нюанс. Если в договоре написано, например, "цена - 100 USD, оплата в рублях по курсу ЦБ РФ + 3% ", то в момент оценки, когда оплата еще не производилась, эти самые 3% отбрасываются, и реализация расчитывается по чистому курсу.
Позже, когда производится оплата, определяется фактическая выручка и рублевая цена ранее отгруженного товара (продукции, основного средства, материала и т.д.), причем, уже с учетом пресловутых 3%. На разницу между фактически определившейся стоимостью и ранее сделанной временной оценкой ценностей, уже отраженной в учете, делается проводка на суммовую разницу - переоценка, как ты ее называешь.
Все, абсолютно все эти проводки, делаются по рублевым счетам и только в рублях . То есть, 60 счет - рублевый, 20 - рублевый, 51 - тоже рублевый.
Приведенные выше нюансы кажутся не очень сложными до тех пор, пока одной платежкой не оплачивается несколько поставок с частичным перекрытием одной из поставок, пока не производятся несколько частичных оплат одной и той же поставки. Тогда выясняется, что как совокупность поставок, так и совокупность платежей необходимо выстраивать в последовательность по FIFO, бить на элементарные партии платежей, часть из которых выражена в валюте, часть - в рублях (в зависимости от того, что было раньше - оплата или отгрука). Тогда может выясниться, что одна и та же отгрузка "переоценивается" несколько раз. Причем, для следующих "переоценок" необходимо учитывать результаты ранее произведенных переоценок этой же самой поставки.
Могу сказать, что расчет суммовых разниц - на порядок более сложная задача, нежели расчет курсовых разниц. Без кувырканий я не смог с ней справиться в ИНФИНе. Мне пришлось наваять в Access программу, которая производит подобный расчет за пределами ИНФИН, а бухгалтер руками делает проводки, используя сгенерированный в программе отчет. Если очень нужно, могу выслать - напиши мне на мыло (см.в профиле).

LeshicМне надо дальше эти операции трансформировать в МСФО и там их успешно переоценить :)Без комментариев... Я не до такой степени знаком с IAS или c GAAP, чтобы четко представлять, как эти операции находят отражение.

ModelRЕсли в договоре так написано, то это означает, что до оплаты рублевая оценка не определена в принципе. Воля предприятия, что написать в учетной политике на этот случай.Учетная политика составляется раз в год. Если в ней по этому поводу ничего не написано, то оценка обязана производиться описанным мной способом. Бухучет не допускает вольностей в таких вопросах, как оценка.

LeshicВзаимозачет дебиторке в евро кредиторка в долларах
не в эквивалентах а в родных валютах как сделать?Да, пожалуй, это тот самый редкий случай, когда подобная вещь может быть полезной. В ИНФИНе - через вспомогательный счет.