Как устранить расхождения в копейках в НДС валютных документов между 1С:УТ и 1С:БП при синхронизации?

← На главную

Уважаемые коллеги, рассмотрим одну из часто встречающихся проблем при обмене данными между конфигурациями 1С:Управление торговлей (УТ) и 1С:Бухгалтерия предприятия (БП) или 1С:Управление нашей фирмой (УНФ) и 1С:БП, а именно — расхождения в копейках в валютных документах, особенно в суммах НДС. Эти расхождения могут привести к серьезным проблемам с контролирующими органами, таким как ИФНС, поскольку они затрагивают книгу продаж и книгу покупок контрагентов. Давайте вместе разберемся в причинах этих расхождений и возможных путях их устранения.

Анализ причин расхождений в копейках при синхронизации валютных документов

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

Повторный пересчет в базе-приемнике: Типовой механизм обмена 1С, к сожалению, не всегда просто переносит уже рассчитанные рублевые эквиваленты валютных сумм из базы-источника (например, УТ) в базу-приемник (БП). Вместо этого, БП может самостоятельно пересчитывать эти суммы, используя свои внутренние правила, курсы валют на момент проведения и алгоритмы округления. Это происходит, потому что в процессе обмена не всегда передается полная информация о рублевом покрытии, что вынуждает базу-приемник производить собственные вычисления.
Различные правила округления: Каждая конфигурация 1С может иметь свои внутренние алгоритмы округления, а также настройки точности, которые могут отличаться. Даже если курсы валют одинаковы, небольшие различия в точности вычислений или порядке округления промежуточных значений могут приводить к расхождениям в итоговых суммах, особенно это заметно в НДС и общих суммах документов. Например, округление может происходить до 2 знаков после запятой, но путь к этому округлению (последовательность операций деления и умножения) может быть разным.
Разная логика распределения рублевых сумм по строкам: Это один из наиболее коварных аспектов проблемы. Например, в УНФ и БП (или УТ и БП) может использоваться разный подход к распределению общей рублевой суммы документа по его табличным частям (строкам).
Рассмотрим пример, который был описан коллегами. Допустим, у нас есть документ "Реализация товаров" в валюте. Общая сумма документа в рублях в УНФ может быть 11 199 531,35, а в БП — 11 199 531,34. Это расхождение в одну копейку обусловлено тем, что:
- В УНФ общая сумма документа в рублях распределяется по строкам пропорционально валютной сумме каждой строки.
- В Бухгалтерии общая сумма распределяется пропорционально рублёвой сумме, посчитанной просто по курсу документа и округлённой до 2-х знаков после запятой.
Даже если дать один и тот же исходный рублевый итог для распределения, из-за различий в алгоритмах строки будут иметь разные значения, что в итоге приводит к расхождению в общей сумме документа и, как следствие, в НДС.
Особенности расчета НДС при авансах: При получении аванса в иностранной валюте сумма для целей НДС пересчитывается в рубли по курсу ЦБ РФ на дату получения оплаты (поступления денежных средств). Это может создать расхождения с суммами, рассчитанными по курсу на дату отгрузки, если курс меняется.
Нормативное регулирование валютных операций (ПБУ 3/2006): В соответствии с ПБУ 3/2006, учет активов и обязательств в иностранной валюте требует пересчета в рубли на дату принятия к учету, а также регулярной переоценки по курсу ЦБ РФ (или курсу договора) на каждую отчетную дату или дату совершения операции. Это означает, что рублевые суммы постоянно меняются из-за курсовых разниц, что делает задачу поддержания идеального соответствия еще сложнее.
Точность хранения курсов валют: Курсы валют в 1С могут храниться с разной точностью, и применение разных курсов (на дату операции, дату платежа) также может влиять на итоговые суммы после округления.

Примеры кода и модулей для анализа

Для глубокого понимания проблемы, рассмотрим код, который отвечает за расчеты взаиморасчетов и проведение документов в разных конфигурациях.

В модуле УчетВзаиморасчетов одной из конфигураций может использоваться следующий подход для расчета рублевого коэффициента и суммы:


КоэффициентРуб = ?(НЕ СтрокаДокумента.РасчетыВВалюте, 1, ?(СтрокаДокумента.СуммаВзаиморасчетов = 0, 0, СтрокаДокумента.СуммаРуб / СтрокаДокумента.СуммаВзаиморасчетов));
КонецЕсли; 
СтрокаВзаиморасчетов.СуммаРуб = Окр(НераспределеннаяСумма * КоэффициентРуб, 2);

Здесь видно, что КоэффициентРуб вычисляется как отношение уже существующей рублевой суммы к валютной, а затем применяется к нераспределенной сумме с округлением до двух знаков.

В то же время, в модуле РасчетыПроведениеДокументов другой конфигурации (например, УНФ) может использоваться иная логика для расчета рублевой суммы движения:


Движение.Сумма = Движение.СуммаВал * ДополнительныеСвойства.КурсДокумента * ДополнительныеСвойства.КратностьВалютыУчета / (?(ДополнительныеСвойства.КратностьДокумента = 0, 1, ДополнительныеСвойства.КратностьДокумента) * ?(ДополнительныеСвойства.КурсВалютыУчета = 0, 1, ДополнительныеСвойства.КурсВалютыУчета));

Здесь рублевая сумма движения рассчитывается напрямую через валютную сумму, курс документа, кратность валюты учета и другие параметры, что может давать отличный результат при округлении, особенно если курс документа хранится с высокой точностью, а итоговая сумма затем округляется. Эти различия в логике и последовательности операций, а также в округлении, и приводят к тем самым "копеечным" расхождениям.

Возможные подходы и решения для устранения расхождений

Поскольку проблема носит системный характер и признана разработчиками 1С, существует несколько подходов к ее решению. Некоторые из них временные или частичные, другие требуют более серьезной доработки.

1. Настройка точности округления в 1С

В 1С:Бухгалтерии 3.0 мы можем изменить точность округления чисел. Эти настройки применяются к новым документам и потенциально могут помочь избежать расхождений при обмене с внешними системами. Однако для уже созданных документов, возможно, потребуется их перепроведение. Также мы можем настроить округление цен номенклатуры (например, до 0.10 коп.), но для весового товара это часто требует доработки кода.

2. Корректировка долга

Для списания мелких копеечных остатков, возникающих в валютных операциях, особенно на счетах расчетов (например, 60), мы можем использовать документ «Корректировка долга». Однако важно убедиться, что это не нарушает соответствие сальдо расчетов с контрагентом и допустимо с точки зрения учета.

3. Ожидание официальных исправлений от 1С

Разработчики 1С осведомлены о данной проблеме и занимаются ее решением, о чем неоднократно сообщалось на форумах. Мы можем отслеживать новые релизы конфигураций и их описания, так как некоторые проблемы с некорректной выгрузкой документов при синхронизации могут быть ошибками конкретных релизов и исправляются в более новых версиях. Поддерживать конфигурации в актуальном состоянии — важная рекомендация.

4. Программная доработка механизмов обмена и учета (наиболее эффективное решение)

Если официальные исправления не удовлетворяют нашим требованиям или мы не можем ждать, наиболее надежным решением является программная доработка. Рассмотрим шаги, которые мы можем предпринять:

Выбор эталонного алгоритма: Определим, какой алгоритм расчета рублевых сумм и их распределения по строкам мы будем считать эталонным. Чаще всего за эталон принимается алгоритм из 1С:Бухгалтерии, поскольку именно эта база формирует отчетность для ИФНС.
Создание расширения или внешней обработки: Разработаем расширение конфигурации или внешнюю обработку, которая будет выполнять следующие функции:
- Перехват событий: Реализуем подписку на события после проведения документов (например, "Реализация товаров") в базе-источнике (УТ/УНФ) или при их загрузке в базу-приемник (БП).
- Сравнение и пересчет: После проведения или загрузки документа, мы должны пересчитать рублевые суммы (особенно НДС и итоговые суммы) по строкам, используя эталонный алгоритм.
- Корректировка записей в регистрах: Если обнаружены расхождения, расширение должно делать корректирующие записи в соответствующие регистры накопления (например, РегистрНакопления.НДСПредъявленный, РегистрНакопления.РасчетыСКонтрагентами) и регистры сведений, которые хранят рублевые суммы документов. Например, можно скорректировать записи в регистре сведений с рублевыми суммами, чтобы они соответствовали эталонному расчету.
- Унификация КоэффициентРуб: Мы можем проанализировать и унифицировать расчет КоэффициентРуб, чтобы он был одинаковым в обеих конфигурациях. Например, если в УТ коэффициент считается одним образом, а в БП — другим, нам потребуется привести их к единому стандарту.
- Единый алгоритм распределения: Особое внимание уделим алгоритму распределения общей рублевой суммы по строкам документа. Мы должны убедиться, что он одинаково работает в обеих системах, чтобы избежать копеечных сдвигов в каждой строке.

Пример реализации (концепция):

Допустим, мы хотим, чтобы рублевые суммы в УТ (при передаче в БП) всегда соответствовали тому, как их рассчитает БП. Тогда мы можем:

При проведении документа в УТ, помимо стандартного расчета, выполнить "контрольный" расчет рублевых сумм по алгоритму БП.
Сохранить эти "контрольные" суммы, например, в дополнительных реквизитах документа или в специальном регистре сведений.
При выгрузке документа в БП, передавать эти "контрольные" суммы, а в БП при загрузке использовать их, а не пересчитывать заново, либо модифицировать алгоритм БП для принятия этих сумм.

Альтернативный подход (как было реализовано в одном из случаев): после загрузки документов в БП, специализированное расширение корректирует записи в регистрах накопления и сведений, выравнивая рублевые суммы (особенно НДС) по эталонному алгоритму БП. Этот подход может выглядеть следующим образом:


// Примерный псевдокод для расширения в БП после загрузки документа
Процедура ПослеЗагрузкиДокументаРеализация(ДокументСсылка) Экспорт
    ДокументОбъект = ДокументСсылка.ПолучитьОбъект();
    Если ДокументОбъект.Проведен Тогда
        // Отменить движения, сделанные типовым проведением
        ДокументОбъект.Движения.НДСПредъявленный.Очистить();
        ДокументОбъект.Движения.РасчетыСКонтрагентами.Очистить();
        // ... другие регистры

        // Пересчитать НДС и другие рублевые суммы по строкам
        // используя эталонный алгоритм БП или унифицированный
        Для Каждого СтрокаТЧ Из ДокументОбъект.Товары Цикл
            // Вычисление правильной рублевой суммы НДС для строки
            ПравильныйНДСРуб = ВычислитьНДСПоЭталону(СтрокаТЧ.СуммаВал, СтрокаТЧ.СтавкаНДС, ДокументОбъект.Курс);
                    
            // Создание нового движения для регистра НДСПредъявленный
            ДвижениеНДС = ДокументОбъект.Движения.НДСПредъявленный.Добавить();
            ДвижениеНДС.СуммаБезНДС = ПравильнаяСуммаБезНДСРуб;
            ДвижениеНДС.СуммаНДС = ПравильныйНДСРуб;
            // ... заполнение остальных полей движения
        КонецЦикла;
                
        // Пересчитать и скорректировать общую сумму в регистрах взаиморасчетов
        // ...

        // Записать новые движения
        ДокументОбъект.Движения.Записать();
    КонецЕсли;
КонецПроцедуры

Функция ВычислитьНДСПоЭталону(СуммаВал, СтавкаНДС, Курс)
    // Здесь должна быть логика расчета НДС, которая точно соответствует
    // тому, как она рассчитывается в БП, или унифицированный алгоритм
    // с учетом требуемого округления
    СуммаРуб = Окр(СуммаВал * Курс, 2);
    НДС = Окр(СуммаРуб * СтавкаНДС / 100, 2);
    Возврат НДС;
КонецФункции

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