При ведении учета в 1С:ERP Управление предприятием многие производственные компании сталкиваются с неприятной проблемой: после успешного выполнения процедуры закрытия месяца на счете 20 "Основное производство" зависает незначительный остаток — буквально несколько копеек (например, 0,15 руб.). Особо часто эта ситуация проявляется при работе по давальческой схеме (производство из материалов переработчика), когда цепочка документов включает передачу сырья, отчет переработчика и поступление готовой продукции.
В этой статье мы подробно разберем, почему возникают эти погрешности, детально изучим зарегистрированную ошибку разработчиков 1С, рассмотрим варианты ручного исправления программного кода, а также разберем системные настройки программы, которые помогут навсегда избавиться от копеечных «хвостов».
Для начала проанализируем техническую сторону вопроса. Разработчиками фирмы 1С официально зарегистрирована и подтверждена ошибка за номером 00-00201996. Суть ее заключается в некорректном алгоритме формирования временных таблиц при отражении операций в регламентированном учете. Для анализа промежуточных данных при расчете себестоимости подойдет расширение для просмотра временных таблиц при закрытии месяца.
При расчете себестоимости по давальческой схеме программа связывает данные регистра накопления СебестоимостьТоваров, справочника ПартииПроизводства и документа ОтчетПереработчика. Если по одной партии производства формируется несколько записей погрешности или в документах указаны несколько партнеров-переработчиков, исходный запрос в системе начинал дублировать строки. В результате этого дублирования сумма погрешности округления рассчитывалась некорректно, удваивалась или утраивалась, из-за чего на 20 счете образовывалось незакрытое сальдо.
Для исправления этой ошибки нам потребуется внести изменения в общий модуль РасчетСебестоимостиТоваровЛокализация в режиме Конфигуратора (желательно выполнять это через механизм расширений, чтобы не снимать конфигурацию с поддержки).
Давайте рассмотрим, как выглядит исходный код в функции ТекстЗапросаВТОтраженияВРеглУчете:
|ВЫБРАТЬ
| Погрешность.Организация,
| Погрешность.АналитикаУчетаНоменклатуры,
| Погрешность.ВидЗапасов,
| Погрешность.АналитикаУчетаНоменклатуры.МестоХранения КАК Подразделение,
| ОтчетПереработчика.Партнер КАК МестоУчета
|ИЗ
| РегистрНакопления.СебестоимостьТоваров КАК Погрешность
| ВНУТРЕННЕЕ СОЕДИНЕНИЕ Справочник.ПартииПроизводства КАК ПартииПроизводства
| ПО ПартииПроизводства.Ссылка = Погрешность.Партия
|
| ВНУТРЕННЕЕ СОЕДИНЕНИЕ Документ.ОтчетПереработчика КАК ОтчетПереработчика
| ПО ОтчетПереработчика.Ссылка = ПартииПроизводства.Документ
|ГДЕ
| Погрешность.Регистратор = &Ссылка
| И Погрешность.Активность
| И Погрешность.РазделУчета В (ЗНАЧЕНИЕ(Перечисление.РазделыУчетаСебестоимостиТоваров.ПроизводственныеЗатраты),
| ЗНАЧЕНИЕ(Перечисление.РазделыУчетаСебестоимостиТоваров.НезавершенноеПроизводство))
| И Погрешность.СтатьяРасходовСписания = ЗНАЧЕНИЕ(ПланВидовХарактеристик.СтатьиРасходов.ПогрешностьРасчетаСебестоимости)
Для устранения проблемы дублирования строк мы должны сгруппировать выборку и получить максимальное значение по полю партнера. Заменим вышеуказанный участок кода на следующий вариант:
|ВЫБРАТЬ
| Погрешность.Организация,
| Погрешность.АналитикаУчетаНоменклатуры,
| Погрешность.ВидЗапасов,
| Погрешность.АналитикаУчетаНоменклатуры.МестоХранения КАК Подразделение,
| МАКСИМУМ(ОтчетПереработчика.Партнер) КАК МестоУчета
|ИЗ
| РегистрНакопления.СебестоимостьТоваров КАК Погрешность
| ВНУТРЕННЕЕ СОЕДИНЕНИЕ Справочник.ПартииПроизводства КАК ПартииПроизводства
| ПО ПартииПроизводства.Ссылка = Погрешность.Партия
|
| ВНУТРЕННЕЕ СОЕДИНЕНИЕ Документ.ОтчетПереработчика КАК ОтчетПереработчика
| ПО ОтчетПереработчика.Ссылка = ПартииПроизводства.Документ
|ГДЕ
| Погрешность.Регистратор = &Ссылка
| И Погрешность.Активность
| И Погрешность.РазделУчета В (ЗНАЧЕНИЕ(Перечисление.РазделыУчетаСебестоимостиТоваров.ПроизводственныеЗатраты),
| ЗНАЧЕНИЕ(Перечисление.РазделыУчетаСебестоимостиТоваров.НезавершенноеПроизводство))
| И Погрешность.СтатьяРасходовСписания = ЗНАЧЕНИЕ(ПланВидовХарактеристик.СтатьиРасходов.ПогрешностьРасчетаСебестоимости)
|СГРУППИРОВАТЬ ПО
| Погрешность.Организация,
| Погрешность.АналитикаУчетаНоменклатуры,
| Погрешность.ВидЗапасов,
| Погрешность.АналитикаУчетаНоменклатуры.МестоХранения
После применения этой корректировки и перезапуска процедуры Закрытие месяца избыточные записи перестанут двоиться, и копейки закроются корректно.
Выясним математическую причину появления копеек. В 1С:ERP расчет себестоимости реализован через решение Системы Линейных Алгебраических Уравнений (СЛАУ). Это мощный инструмент, который позволяет рассчитывать встречные услуги и сложные производственные петли. При расчете СЛАУ точность вычислений в оперативной памяти чрезвычайно высока (до десятков знаков после запятой). Однако при записи итогов в информационную базу происходит жесткое округление до двух знаков.
Накопленная погрешность округления может «зависать» на счетах затрат. В старых конфигурациях (например, УПП) параметры СЛАУ настраивались в меню настройки программы. В современных релизах 1С:ERP эти настройки скрыты внутри самого рабочего места по закрытию месяца.
Давайте разберем по шагам, как получить доступ к этим параметрам:
Распределение затрат и расчет себестоимости.Здесь мы можем отрегулировать параметры СЛАУ для повышения точности расчетов:
Даже если система СЛАУ нашла копеечную погрешность, программа должна знать, куда ее списать. Для этого в ERP используется предопределенная статья расходов — Погрешность расчета себестоимости. По умолчанию копейки с нее должны уходить на счет 91.02 "Прочие расходы".
Однако на практике часто возникает ситуация, когда настройки Групп финансового учета (ГФУ) для этой статьи «слетают» после очередного обновления программы или некорректного переноса данных. Проанализируем эту ситуацию:
Проанализируем влияние метода оценки себестоимости. В условиях нашего примера используется метод ФИФО (взвешенная оценка). Этот метод рассчитывает себестоимость партий в целом за отчетный период (месяц), что неизбежно приводит к формированию громоздких систем уравнений СЛАУ, так как все затраты за месяц перемешиваются и усредняются в рамках партий.
В качестве альтернативного решения, не требующего изменения программного кода, рассмотрим переход на метод ФИФО (скользящая оценка). При скользящей оценке расчет партий списания материальных ценностей производится последовательно, в хронологическом порядке проведения документов. Этот метод исключает итерационные приближения СЛАУ для партионного учета, рассчитывая каждую операцию последовательно, что практически полностью исключает возникновение копеечных погрешностей округления при распределении партий.
Необходимо четко понимать базовый принцип архитектуры 1С:ERP: оперативный учет всегда первичен по отношению к регламентированному (бухгалтерскому) учету. Проводки по 20 счету формируются строго на основании движений по регистрам накопления. Если у нас не закрывается 20 счет, нужно искать причину не в оборотно-сальдовой ведомости, а в регистрах.
Для локализации проблемы выполним следующие шаги:
Себестоимость товаров.Раздел учета (нас интересуют разделы Производственные затраты и Незавершенное производство).Здесь возможны два сценария:
Себестоимость товаров остатка в 15 копеек нет (там все закрылось в ноль), а на счете 20 в ОСВ копейки висят. Это явный признак программного сбоя при формировании проводок регламентированного учета (актуальна Ошибка № 00-00201996, описанная в первом пункте). Потребуется либо обновить релиз ERP, либо внести исправления в код запроса.Себестоимость товаров. Это означает, что проблема кроется в распределении затрат. Система не смогла распределить эти 15 копеек на выпуск продукции из-за несоответствия аналитик.Рассмотрим подробнее сценарий Б. При давальческой переработке крайне важно соблюдать строгую идентичность аналитики передаваемого сырья и выпускаемой продукции. Если у переданных в переработку материалов и полученных от переработчика изделий не совпадают такие параметры, как Группы аналитического учета номенклатуры, Характеристики или Назначения (при обособленном учете под назначение), алгоритм распределения затрат может отработать некорректно.
Сумма затрат распределится на выпуск не полностью, и «зависшие» копейки останутся на незавершенном производстве (счет 20), поскольку система не сможет сопоставить оставшуюся часть стоимости сырья с конкретными выпусками готовой продукции. Обязательно проверьте документы Передача сырья переработчику, Отчет переработчика и Поступление от переработчика на предмет полной идентичности аналитики учета. Для автоматической корректировки зависших суммовых хвостов в подобных ситуациях можно использовать обработку для исправления ненулевых остатков в регистре себестоимости.