Данная концепция используется в системе Скала и необходима для целей консолидации, когда делается не только перекладка в другой план счетов, но и пересчёт в другую валюту учёта. Это, безусловно, расширенная и очень продвинутая функциональность, которую попытаемся здесь разобрать «по полочкам» на конкретном примере. Для примера в качестве валюты был выбран Юань. Курсы взяты с сайта ЦБ РФ.
Разберём всё подробно. На картинке для упрощения не указан код и название товара. Будем исходить из предположения, что мы закупаем один и тот же товар и его же расходуем.
- На начало 2026 года на складе нет нашего товара
- 13.01.2026 мы закупили 100 штук товара по цене 100 юаней. Курс на дату закупки 11,2856 рублей за юань, цена в рублях получается 1128,56 рублей за штуку, всего закупили на сумму 10000 юаней, что эквивалентно 112856 рублям. И эти суммы — остаток на складе на конец 13.01.2026
- 17.01.2026 мы заплатили таможенную пошлину в размере 10% от суммы закупки в рублях, то есть 11285,60 рубля, что при курсе на дату оплаты эквивалентно 1012,070666 юаня. Соответственно, количество товара на складе не меняется, но эти суммы мы должны добавить к его себестоимости, причем отдельно рублёвую сумму к рублевой, а юаневую — к юаневой. Получается остаток на складе в рублях 124141,60 рубля и в юанях — 11012,07067. Соответственно, если эти суммы поделить на количество товара на складе, мы получим средние цены за единицу товара в рублях — 1241,416 и юанях — 110,1207067. Также можно заметить, что эффективный курс на конец дня (сумму в рублях поделить на сумму в юанях) уже ничему не соответствует, он получился 11,27322951 и никак не коррелирует с курсами валют. Запомним это утверждение.
- 23.01.2026 мы закупили ещё 100 единиц того же самого товара, но уже по цене 120 юаней за штуку. При курсе 10,8646 это получается в рублях по 1303,752 за штуку, а всего на сумму в юанях 1200 и в рублях — 130375,20. Прибавляем эти суммы к суммам остатков на складе, получаем в юанях — 23012,07067, в рублях — 254516,80. А количество на складе становится 200 штук (было 100 и докупили ещё 100). Соответственно, средние цены на конец дня становятся в юанях — 115,0603533 и в рублях — 1272,584
- 31.01.2026 мы продаём 150 штук товара. Курс на дату продажи 10,8689. Но мы его не используем, так как это не операция прихода, а операция расхода и цены за единицу товара должны быть взяты как средние цены за единицу товара, сложившиеся до момента совершения расходной операции. То есть мы должны взять средние цены в юанях — 115,0603533 и в рублях — 1272,584. Что мы и делаем. В таблице обозначено зелёным фоном и стрелками откуда это берётся. Пожалуйста, обратите внимание, что мы ведём речь не о ценах продажи, а о складских ценах, т.е. себестоимости проданных товаров
- 06.02.2026 мы списываем оставшиеся 50 единиц товара на собственные нужды. Здесь всё аналогично предыдущей операции, так как это расходная операция. В результате на складе количество товара становится равным нулю, и никакие суммы не «зависают», как было бы, если бы мы не вели учёт одновременно в двух валютах, а просто пересчитывали бы цены из рублей в юани по курсу на дату совершения операции. Это как раз столбцы O и P таблицы
Именно такой алгоритм используется при «продвинутых» моделях консолидации с пересчётом сумм в валюту. То есть все операции делаются по курсу на дату совершения операции, кроме складских проводок. В них валютная сумма подставляется из модуля «Управление Запасами». Есть и другие исключения, но они к данной теме отношения не имеют.
Эта модель нам представляется наиболее адекватной. А попытки использовать при продаже курс на дату прихода товара не выдерживают никакой критики, так как в нашем примере показан «Эффективный курс», который как правило ни с чем не совпадает, ни с курсом на дату прихода (кроме самого первого прихода), ни с курсом на дату начисления дополнительных затрат (например, пошлины, транспортные, погрузо-разгрузочные операции и т.п.), ни с чем-то ещё.
Смотрите также:
