Каждый бухгалтер или специалист по расчету себестоимости рано или поздно сталкивается с ситуацией, когда при списании ТМЦ (например, ГСМ или строительных материалов) математика в печатной форме документа "трещит по швам". Открывая печатную форму документа ТребованиеНакладная, мы видим вполне конкретные цифры: количество списания и цену за единицу. Однако при попытке перемножить эти показатели на обычном калькуляторе мы получаем итоговую сумму, которая отличается от суммы, зафиксированной в программе 1С, на несколько копеек (а иногда и рублей).
Проанализируем конкретную ситуацию: в программе 1С:Комплексная автоматизация 1.1 после перехода на партионный учет при оформлении списания ГСМ требованием-накладной в печатной форме выводятся следующие показатели: 262,27 л * 37,42 руб. = 9814,94 руб.. Если же мы перемножим эти числа на калькуляторе, то получим 9814,14 руб.. Возникает расхождение в 80 копеек. В этой статье мы подробно разберем, почему возникает такая погрешность, где искать ее корни в системе и как правильно решить эту проблему без ущерба для бухгалтерского и налогового учета.
Спешим успокоить пользователей и методологов: разница в копейках между ручным пересчетом и данными программы — это не сбой в алгоритмах 1С, а классическое следствие работы партионного учета и правил округления чисел в печатных формах. Разберем этот механизм по шагам.
Во-первых, необходимо понять, что в системе 1С при партионном учете (будь то метод FIFO или "по средней") стоимость списания первична, а цена — вторична. Программа не умножает количество на цену при списании. Вместо этого она берет конкретную партию товара (или несколько партий), находит их общую историческую стоимость на балансе и списывает конкретную сумму.
Рассмотрим подробнее числовой пример из нашего вопроса:
ПартииТоваровНаСкладах ровно 9814,94 руб.. Это реальная сумма расходов организации на приобретение данного топлива.9814,94 руб. / 262,27 л = 37,4222747... руб.262,27 л * 37,42 руб. = 9814,14 руб.Разница в 80 копеек — это не ошибка расчетов, а накопленная погрешность округления цены на каждой единице объема топлива: 0,0022747... руб. * 262,27 л ≈ 0,80 руб..
Ситуация с округлениями обостряется в следующих случаях:
Если у вас возникли сомнения в корректности списания себестоимости, проанализируем ситуацию в базе данных. Выполним следующие проверочные действия по шагам:
Шаг 1. Анализируем движения документа по регистрам.
Перейдем в движения документа ТребованиеНакладная (кнопка "Перейти" - "Движения документа по регистрам"). Нас интересует регистр накопления ПартииТоваровНаСкладах (управленческий учет) или ПартииТоваровНаСкладах (бухгалтерский учет). Посмотрим, из каких партий (документов поступления) списался ГСМ и какие точные суммы зафиксированы по каждой строке.
Шаг 2. Формируем отчет "Ведомость по партиям товаров на складах".
Откроем данный отчет и настроим группировку по номенклатуре ГСМ, складам и документам-партиям (документам поступления). Проверим, нет ли по проблемной позиции "зависшей" копеечной стоимости без количества. Если ранее возникали ситуации, когда количество было списано в ноль, а копейки остались, программа могла распределить эти копейки на текущее списание, что и привело к увеличению итоговой суммы. Для быстрого выявления расхождений между остатками и регистром партий можно использовать отчет для сравнения движений регистров "Товары на складах" и "Партии товаров на складах".
Шаг 3. Восстановление последовательности партионного учета.
Поскольку авторы темы упомянули, что партионный учет был введен недавно, высока вероятность проведения документов "задним числом" или нарушения хронологии. Запустим обработку Проведение по партиям (или Восстановление последовательности партионного учета), чтобы система правильно пересчитала себестоимость по всем цепочкам документов.
Шаг 4. Расчет себестоимости в конце месяца.
Помните, что в комплексных конфигурациях (1С:КА 1.1, 1С:УПП 1.3) окончательная себестоимость формируется только после проведения регламентного документа РасчетСебестоимостиВыпуска. До момента проведения этого документа в конце месяца оперативные суммы в требованиях-накладных являются предварительными и могут корректироваться.
С точки зрения методологии бухгалтерского учета, сумма списания в проводках (9814,94 руб.) является единственно верной, так как она отражает реальные затраты на приобретение запасов. Однако расхождения между ценой, количеством и суммой в печатных формах часто вызывают вопросы у аудиторов и налоговых инспекторов. Рассмотрим три варианта решения этой проблемы.
Это стандартное поведение всех ERP-систем. Сумма в балансе и проводках имеет приоритет над результатом простого перемножения округленных показателей в печатной форме на калькуляторе. При возникновении вопросов у контролирующих органов им предоставляется регистр учета (например, оборотно-сальдовая ведомость или ведомость по партиям), подтверждающий фактическую себестоимость приобретения ТМЦ.
Если для вашей организации критично, чтобы показатели в печатной форме сходились при проверке на калькуляторе, самым красивым решением будет доработка печатной формы документа. Мы можем создать внешнюю печатную форму требования-накладной и настроить в ней вывод цены не с двумя, а с четырьмя или пятью знаками после запятой.
Посмотрим на пример кода, который форматирует цену в модуле печатной формы:
// Пример форматирования вывода расчетной цены в макет печатной формы
РасчетнаяЦена = СуммаСписания / КоличествоСписания;
// Выводим цену с точностью до 4 знаков после запятой
ОбластьМакета.Параметры.Цена = Формат(РасчетнаяЦена, "ЧЦ=15; ЧДЦ=4");
ОбластьМакета.Параметры.Сумма = СуммаСписания; // Сумма остается точной из проводки
При таком подходе в печатной форме мы увидим: 262,27 л * 37,4223 руб. = 9814,94 руб.. Перемножение на калькуляторе даст результат 9814,94119, что при округлении до копеек даст ровно 9814,94. Проблема нестыковки будет полностью решена.
Этот вариант предполагает изменение алгоритма печатной формы таким образом, чтобы цена жестко округлялась до 2 знаков, а сумма в печатной форме рассчитывалась как произведение количества на эту округленную цену.
Посмотрим, как может выглядеть такой алгоритм в коде:
// Принудительный расчет суммы по округленной цене
ОкругленнаяЦена = Округлить(СуммаСписания / КоличествоСписания, 2);
ПечатнаяСумма = КоличествоСписания * ОкругленнаяЦена;
ОбластьМакета.Параметры.Цена = ОкругленнаяЦена;
ОбластьМакета.Параметры.Сумма = ПечатнаяСумма;
Важное предупреждение: применение этого варианта несет в себе серьезные риски! В этом случае сумма, напечатанная на бумаге (9814,14 руб.), разойдется с суммой, проведенной по бухгалтерским счетам и регистрам в базе данных (9814,94 руб.). Подобное расхождение между "бумажным" документом и данными учета в программе является грубым нарушением требований к оформлению первичных документов и может повлечь за собой штрафы при налоговых проверках. Поэтому мы настоятельно рекомендуем использовать Вариант 2 как наиболее безопасный и методологически верный.