При работе с валютными операциями в 1С:ERP пользователи часто сталкиваются с ситуацией, когда рублевая сумма в проводках по счету 90.01 (Выручка) или 62.11 (Расчеты в валюте) не совпадает с результатом простого умножения валютной суммы на курс ЦБ РФ на дату документа. Особенно остро этот вопрос встает, когда в проводках появляются «странные» цифры, совершенно не похожие на текущие рыночные котировки. В этой статье мы подробно разберем механизмы системы, которые приводят к таким результатам, и выясним, является ли это ошибкой программы или требованием законодательства.
Прежде чем искать техническую ошибку в конфигурации, нам необходимо обратиться к правилам ведения бухгалтерского и налогового учета. Согласно ПБУ 3/2006 («Учет активов и обязательств, стоимость которых выражена в иностранной валюте»), активы и расходы, которые были оплачены в порядке предварительной оплаты (аванса), принимаются к учету в оценке в рублях по курсу, действовавшему на дату пересчета в рубли средств полученного аванса.
Простыми словами: если клиент прислал нам 100 евро в прошлом месяце, когда курс был 70 рублей, а отгрузку мы делаем сегодня, когда курс 100 рублей, то выручка в бухгалтерском и налоговом учете должна быть отражена по курсу 70 рублей. Таким образом, сумма реализации в рублях будет «заморожена» по курсу аванса. Если же аванс покрывает только часть поставки, то итоговый рублевый эквивалент будет представлять собой средневзвешенное значение: часть по курсу аванса, часть по курсу на дату отгрузки.
Разберем подробнее, как именно 1С:ERP формирует проводки в таких случаях. Система использует сложный алгоритм сопоставления документов оплаты и документов отгрузки. Рассмотрим по шагам, на что нужно обратить внимание при анализе проводок:
Ситуация, описанная в теме (курс 14 рублей при реализации), выглядит подозрительно, так как такой курс евро был очень давно. Проанализируем, почему это может произойти в 1С:ERP: в случае накопления чрезмерного объема исторических записей эффективна многопоточная свёртка 1С:ERP для очистки регистров, очищающая старые записи в параллельных потоках.
1. Наличие «зависших» старых авансов. Рассмотрим ситуацию: в системе числится нераспределенный аванс от 2014 года. Это могло произойти из-за ошибки в аналитике (например, указано другое подразделение или другое «Направление деятельности»). При проведении новой реализации система, следуя алгоритму ФИФО, находит этот древний аванс и «подтягивает» его курс в текущую реализацию. Для исправления такой ситуации необходимо сформировать отчет Ведомость расчетов с клиентами с максимальной детализацией и найти остаток, который не должен там находиться.
2. Ошибки в Группах финансового учета (ГФУ). Выясним, правильно ли настроены счета учета. Если аналитика расчетов разделилась (например, часть суммы зависла на счете 62.02, а реализация пытается закрыться по 62.22), автоматический зачет может сработать некорректно, или, наоборот, зачесть суммы, которые не предполагались к зачету. Для быстрого выявления расщепления аналитики и сопоставления остатков по счетам 60 и 62 пригодится отчет для проверки расчетов с поставщиками и покупателями.
3. Ручная корректировка курса в документе. Проанализируем настройки самого документа Реализация товаров и услуг. На вкладке «Основное» есть гиперссылка «Валюта». Если пользователь установил переключатель в положение «Установить курс вручную», то автоматические механизмы пересчета по ПБУ перестают работать так, как ожидается. Система будет использовать зафиксированный пользователем курс, что приведет к расхождениям с данными регистров накопления.
Посмотрим на алгоритм проверки, который поможет локализовать проблему:
Сумма_в_рублях = (Валютная_сумма_аванса * Курс_аванса) + (Остаток_валютной_суммы_реализации * Курс_ЦБ_на_дату_отгрузки)Важно помнить, что окончательный финансовый результат и корректное состояние валютных счетов формируются только после выполнения регламентной операции «Переоценка валютных средств». Рассмотрим подробнее: эта операция не меняет сумму выручки (счет 90), но она корректирует остатки задолженности на счетах 62 или 60 на конец отчетного периода. Если вы видите странные проводки в середине месяца, попробуйте выполнить процедуру закрытия месяца в копии базы — вполне вероятно, что система выровняет расчеты и сформирует необходимые курсовые разницы.
Также стоит проверить регистр КурсовыеРазницы. В 1С:ERP версии 2.5 и выше алгоритм расчета курсовых разниц был существенно переработан. Теперь система более строго следит за соответствием рублевой массы и валютного остатка по каждой транзакции. Если в цепочке документов была допущена ручная правка или удаление движений, «хвосты» будут тянуться во все последующие документы реализации.
Для программистов и опытных аналитиков полезно будет заглянуть «под капот» документа. Проанализируем движения документа по регистру накопления РасчетыСКлиентамиПоДокументам. Нам интересны следующие поля:
Сумма (валютная сумма);СуммаРегл (сумма в рублях);СтавкаКурса.Если в этом регистре СуммаРегл разделена на несколько строк, где одна соответствует авансу, а другая — остатку долга, то проводки в бухгалтерском учете будут суммировать эти данные. Это и объясняет «сборный» курс.
Если же вы уверены, что авансов нет, а курс все равно неверный, попробуйте выполнить следующие действия:
Подводя итог, можно сказать, что в 99% случаев «неправильный» курс в 1С:ERP является следствием работы алгоритмов зачета авансов. Программа строго соблюдает методологию учета, согласно которой доход признается по курсу получения предоплаты, а не по текущему курсу продажи. Для автоматического проведения перерасчетов при расхождениях по объектам расчетов пригодится обработка для автоматизации зачета авансов.