При работе в конфигурации 1С:Управление производственным предприятием 1.3 (УПП) или 1С:Комплексная автоматизация 1.1 с использованием механизма РАУЗ (Расширенная аналитика учета затрат) пользователи часто сталкиваются с труднообъяснимыми расхождениями при расчете себестоимости. Одна из самых коварных проблем — ситуация, когда в регистре УчетЗатратРегл (или его управленческом аналоге) по разделу учета «Выпуск» сумма прихода не совпадает с суммой расхода по конкретному ключу аналитики, в то время как количество закрывается в ноль, незавершенного производства (НЗП) нет, а раздел «Затраты на выпуск» сошелся идеально.
Особенно загадочно выглядит ситуация, когда при выгрузке этой же информационной базы в файловый вариант и повторном запуске документа РасчетСебестоимостиВыпуска (РСВ) все стоимостные остатки закрываются без копеек и расхождений. Проанализируем, почему возникает эта техническая проблема, как она связана с особенностями работы СУБД PostgreSQL и как решить ее на клиент-серверном варианте базы данных.
---
Для начала разберем логику работы регистров РАУЗ, чтобы понять физику процесса. В отличие от традиционного партионного учета, РАУЗ разделяет движение затрат на несколько технологических разделов учета:
РаспределениеМатериаловНаВыпуск). При успешном проведении РСВ этот раздел должен закрываться полностью (Приход = Расход), транслируя накопленную стоимость в выпуск.Если по результатам расчета себестоимости по разделу «Затраты на выпуск» приход равен расходу, значит, система успешно собрала все затраты на производство конкретной номенклатуры. Но если в разделе «Выпуск» приход не равен расходу по той же аналитике, это означает, что математический аппарат 1С успешно оценил выпущенную продукцию, но не смог до конца распределить эту стоимость получателю. В итоге на ключах аналитики «Выпуска» зависает стоимостный остаток при нулевом количестве.
---
Для расчета себестоимости РАУЗ строит огромную Систему Линейных Алгебраических Уравнений (СЛАУ), которая описывает все движения затрат, выпусков, встречных выпусков и внутренних перемещений за месяц. Эта система решается итерационным путем (как правило, методом Зейделя) непосредственно в базе данных с помощью массивных SQL-запросов, задействующих временные таблицы.
Выясним причину, почему в файловой базе расчет сходится, а на сервере под управлением СУБД PostgreSQL — нет:
work_mem и temp_buffers в файле конфигурации настроены некорректно (занижены), PostgreSQL при нехватке оперативной памяти начинает сбрасывать временные таблицы на жесткий диск. Это лавинообразно увеличивает время расчета, вызывая микрозависания. В условиях ограниченного времени выполнения транзакции алгоритм расчета 1С прерывает итерационные циклы раньше времени, не доведя распределение стоимости до логического финала. В файловой же базе распределение памяти происходит иначе, накладные расходы на сетевой стек и СУБД отсутствуют, поэтому расчет укладывается в лимиты.---
Чтобы решить проблему расхождения стоимости в разделе «Выпуск» без постоянных выгрузок базы в файловый вариант, выполним ряд последовательных шагов по оптимизации настроек СУБД PostgreSQL и параметров расчета 1С.
Администратору СУБД необходимо скорректировать параметры производительности в файле postgresql.conf, чтобы сервер выделял достаточно памяти под сложные запросы СЛАУ.
Рассмотрим ключевые параметры, которые нужно изменить (значения приведены для сервера с 32 ГБ оперативной памяти в качестве примера):
# Память для хранения временных таблиц в рамках одной сессии
temp_buffers = 256MB
# Объем памяти, используемый для сортировок и сложных соединений в запросах
work_mem = 128MB
# Общий объем оперативной памяти, выделяемый PostgreSQL под буферы данных
shared_buffers = 8GB
Важно: Нехватка памяти work_mem заставляет PostgreSQL записывать промежуточные результаты вычислений на диск, что критически замедляет расчет СЛАУ и приводит к аварийной остановке итерационного процесса в РСВ.
Проанализируем настройки самого алгоритма РАУЗ в информационной базе. Перейдем в интерфейс «Заведующий учетом» и откроем настройки параметров расчета себестоимости:
Иногда причиной «зацикливания» СЛАУ и невозможности распределения стоимости становится рассинхронизация или дублирование ключей аналитики в SQL-базе. Проверим базу данных на наличие битых ключей:
Если технические оптимизации выполнены, но зависшая стоимость все равно остается, проанализируем производство на предмет «зацикленного» выпуска (когда продукция А используется для производства продукции Б, а продукция Б в этом же месяце используется для выпуска продукции А).
Для минимизации циклов воспользуемся документом СпособыРаспределенияСтатейЗатратОрганизаций и настроим жесткую последовательность распределения затрат по переделам, чтобы упростить СЛАУ для СУБД. Также рекомендуется проверить корректность заполнения встречного выпуска в регистре сведений ВстречныйВыпускПродукцииУслуг.