Проблема «лишней копейки» или её нехватки — одна из самых часто встречающихся в крупных системах на базе платформы 1С, таких как 1С:Комплексная автоматизация 2.4 (КА 2.4) и 1С:ERP. На первый взгляд ситуация выглядит странно: общая сумма документа в шапке верна, регламентированный учет (проводки) отражает правильные цифры, а в регистрах управленческого учета (взаиморасчетах) сумма «рвется» на 0,01 рубля. Разберем подробно, почему это происходит и как с этим бороться.
Рассмотрим типовую ситуацию. Мы создаем документ РеализацияТоваровУслуг на сумму 13 764,38 руб. При проведении документа мы открываем движения и видим следующую картину в регистре Расчеты с клиентами:
Сумма (управленческая): 13 764,37К оплате: 13 764,37Сумма регл (регламентированная): 13 764,38В результате возникает разрыв. Бухгалтерия при сверке с клиентом видит одну сумму, а отчеты по управленческому учету показывают другую. Выясним причину такого поведения системы.
В конфигурациях линейки 2.4 сумма в регистре взаиморасчетов формируется не прямым копированием итога из шапки документа. Система использует сложный алгоритм распределения общей суммы документа по каждой строке табличной части. Это необходимо для обеспечения аналитического учета в разрезе номенклатуры, направлений деятельности и заказов.
Проанализируем ситуацию: если в документе много строк, система берет общую сумму и пропорционально «размазывает» её по позициям. При этом возникают дробные части копеек. Правила округления в управленческом учете могут работать жестче, чем в бухгалтерском. В итоге, после суммирования округленных значений по каждой строке, итоговая сумма в регистре может отличаться от визуального итога в документе на 1 копейку в любую сторону. Это так называемая ошибка накопления округления.
Одной из самых частых причин является настройка расчета налога. В 1С существует два принципиально разных подхода к вычислению НДС:
Если в настройках системы (раздел НСИ и администрирование — Настройка НСИ и разделов — Учет НДС) установлен расчет «по каждой строке», то при большом количестве позиций суммарный НДС почти всегда будет отличаться от расчета «от итога». Проблема в том, что регламентированный учет может следовать одним правилам, а движения по регистрам Расчеты с клиентами — другим алгоритмам распределения, которые заложены в программном коде проведения документа.
Посмотрим на пример логики, которая может приводить к ошибке: Сумма НДС может вычисляться как разность между суммами НДС (округленными до 2-х знаков) от разных составляющих (например, отгрузка и аванс), а должна вычисляться как НДС от разности сумм. Из-за этого «хвосты» округления вылезают в управленческом учете.
Даже если ваша организация работает только в рублях, система 1С:КА 2.4 всегда ведет параллельный учет в валюте управленческого учета. Если в качестве валюты упр. учета также выбран рубль, система все равно прогоняет суммы через механизмы пересчета. Рассмотрим ситуацию: в карточке валюты может быть задана точность округления или правила кросс-курсов, которые неявно влияют на формирование ресурсов в регистрах. Сумма СуммаРегл берется напрямую из первичных данных, а Сумма (упр) проходит через дополнительные фильтры распределения затрат и выручки.
Когда в соглашении с клиентом указано, что учет ведется «По накладным», система становится крайне требовательной к чистоте данных внутри документа. В этом режиме 1С пытается закрыть задолженность «копейка в копейку» по конкретному объекту расчетов. Если документ был создан путем копирования или в нем вручную корректировались цены/скидки, в скрытых колонках табличной части могут остаться значения с точностью более двух знаков после запятой. При записи в регистр эти значения округляются, и возникает расхождение.
Разберем методы решения, от самых простых до технических.
Шаг 1: Проверка настройки НДС
Перейдем в настройки учета НДС и проверим метод начисления. Если бухгалтерия требует соответствия первичным документам (счетам-фактурам), расчет должен быть идентичен. Часто помогает переключение метода расчета НДС и перепроведение документов, но это затронет всю базу, поэтому действуйте осторожно.
Шаг 2: Пересчет табличной части
Если расхождение возникло в конкретном документе, попробуем «сбросить» накопленную ошибку округления. Вместо ручной правки итогов, выполните следующие действия:
Изменить таблицу).Шаг 3: Использование регламентных заданий
В 1С:КА 2.4 движения по расчетам с партнерами часто формируются не в момент нажатия кнопки «Провести», а отложенно. Проанализируем состояние закрытия месяца. Запустите обработку Закрытие месяца и обратите внимание на операцию «Формирование движений по расчетам с партнерами». Часто после выполнения этого задания система сама «схлопывает» копейки, распределяя их корректно по регистрам.
Шаг 4: Программная диагностика (для разработчиков)
Если проблема носит массовый характер, стоит заглянуть в код процедуры распределения. В модулях проведения документов реализации задействован механизм распределения сумм по аналитикам. Можно использовать следующий программный прием для поиска расхождений в коде:
// Пример логики поиска расхождения в движениях
Для Каждого СтрокаДвижений Из РегистрыБухгалтерии.Хозрасчетный.Выбрать() Цикл
Если СтрокаДвижений.Сумма <> РегистрыНакопления.РасчетыСКлиентами.Итог("Сумма") Тогда
Сообщить("Обнаружено расхождение в документе: " + СтрокаДвижений.Регистратор);
КонецЕсли;
КонецЦикла;
Шаг 5: Сверка регистров накопления
Проанализируем данные двух регистров: РасчетыСКлиентами и РасчетыСКлиентамиПоДокументам. В системе 2.4 они должны быть синхронны. Если в одном из них сумма верная, а в другом — нет, это признак программного сбоя в алгоритме распределения. В ранних релизах ветки 2.4 такие ошибки встречались часто и исправлялись выпуском патчей от 1С. Рекомендуется обновить конфигурацию до актуального релиза.
Расхождение в одну копейку — это не всегда ошибка пользователя, чаще это особенность работы алгоритмов округления в распределенных системах. Для исправления ситуации важно:
Помните, что регламентированный учет в 1С:КА 2.4 опирается на бухгалтерские счета, а управленческий — на регистры накопления, и небольшие разрывы между ними при округлении больших объемов данных заложены в архитектуру системы, но их можно минимизировать правильной настройкой учетной политики.