При автоматизации бухгалтерского учета в системе 1С:Предприятие одной из классических проблем является появление «лишних копеек» или недостача небольших сумм при распределении затрат. Типичная ситуация: при проведении документа общая сумма по дебету не совпадает с суммой по кредиту на несколько копеек, хотя в исходных данных все расчеты кажутся верными. Рассмотрим, почему это происходит и как правильно решить эту задачу на программном и методологическом уровнях.
Первое, что необходимо проанализировать — это метаданные системы. В типовых конфигурациях (например, «Бухгалтерия предприятия 2.0») ресурс Сумма в плане счетов и соответствующих регистрах бухгалтерии имеет жестко заданную точность — 2 десятичных знака. Это продиктовано требованиями законодательства: бухгалтерский учет ведется в рублях и копейках.
Даже если в программном коде вы используете переменную с точностью до 10 знаков после запятой, при попытке записать это значение в Проводка.Сумма платформа принудительно округлит его до 2 знаков. Когда мы распределяем одну общую сумму на множество строк (например, списываем материалы пропорционально их количеству), сумма округленных значений почти всегда будет отличаться от округленной общей суммы. Разберем на примере: нужно распределить 10 рублей на 3 равные части. Математически это 3.3333... В проводках это превратится в 3.33 + 3.33 + 3.33 = 9.99. В итоге 1 копейка «потеряется».
Чтобы избежать расхождений в оборотно-сальдовой ведомости (ОСВ), программисты используют метод «распределения на последнюю строку». Суть метода заключается в том, что для всех строк, кроме последней, сумма рассчитывается обычным способом с округлением, а в последнюю строку записывается разница между исходной суммой и уже распределенной частью.
Рассмотрим пошаговый алгоритм:
ВсегоСумма).Распределено).ВсегоСумма накопленное значение Распределено.Проанализируем пример кода для реализации этого механизма:
// Пример распределения суммы пропорционально количеству
ОбщаяСуммаДляРаспределения = 1123044.78;
ВсегоКол = ТаблицаПродукции.Итог("Количество");
РаспределеннаяСумма = 0;
КоличествоСтрок = ТаблицаПродукции.Количество();
Для Сч = 1 По КоличествоСтрок Цикл
Строка = ТаблицаПродукции[Сч - 1];
Если Сч <> КоличествоСтрок Тогда
// Расчет для обычных строк с округлением
ТекущаяСумма = Окр(ОбщаяСуммаДляРаспределения * (Строка.Количество / ВсегоКол), 2);
РаспределеннаяСумма = РаспределеннаяСумма + ТекущаяСумма;
Иначе
// В последнюю строку записываем остаток
ТекущаяСумма = ОбщаяСуммаДляРаспределения - РаспределеннаяСумма;
КонецЕсли;
// Запись суммы в проводку
Строка.СуммаДляПроводки = ТекущаяСумма;
КонецЦикла;
Такой подход гарантирует, что итоговая сумма всех проводок в точности до копейки совпадет с исходным значением, а погрешность будет «поглощена» последней позицией (материалом или номенклатурной группой).
Выясним причину, по которой в ОСВ по счету 20 могут «висеть» копейки, даже если суммы кажутся верными. В конфигурации БП 2.0 документ «Поступление из переработки» работает по сложным правилам распределения затрат. Если в конце месяца дебет и кредит по счету 20 не сходятся на незначительную сумму (как в примере автора — 18 копеек), это может быть связано с аналитикой.
Важные моменты:
Корректировка стоимости номенклатуры или Закрытие счетов 20, 23, 25, 26 в конце месяца должна автоматически рассчитать фактическую себестоимость и убрать копеечные погрешности.Если данные для распределения вы получаете из запроса, убедитесь, что вы не применяете функции представления или избыточного округления внутри самого текста запроса, которые могут исказить исходные числа до того, как они попадут в алгоритм распределения в коде 1С. Лучше получать максимально точные значения (типа Число(15, 5)) и выполнять окончательное округление до 2 знаков непосредственно перед записью в объект РегистрБухгалтерииНаборЗаписей.
Резюмируем: погрешность в копейках — это не ошибка программы, а следствие ограничения точности финансового учета. Решается она либо программной корректировкой последней строки распределения, либо средствами типового закрытия месяца.