При проведении регламентной процедуры закрытия месяца в программе 1С:Комплексная автоматизация 2 (или 1С:ERP) пользователи часто сталкиваются с критическим падением производительности на этапе партионного учета. Процесс, который ранее занимал минуты, внезапно начинает длиться по 14–16 часов или полностью зависает. Проанализируем лог расчета себестоимости и разберем по шагам, почему возникает эта проблема и как ее оперативно локализовать и устранить.
Обратим внимание на ключевые показатели из протокола расчета за проблемный месяц:
ЗаполнениеПартийВРегистреСебестоимостьТоваров.СебестоимостьТоваров — 15 059 053 записей, при этом уникальных ключей всего 4 894.Такое колоссальное соотношение (более 15 миллионов сформированных движений на 5 тысяч узлов) однозначно указывает на возникновение так называемого комбинаторного взрыва при обходе графа распределения партий. Программа уходит в рекурсивные циклы, пытаясь распределить стоимость по сложным цепочкам перемещений и возвратов, многократно дублируя записи во временных таблицах СУБД.
Выясним причину, почему проблема «выстрелила» после обновления системы (например, в ноябре), хотя сам закрываемый исторический месяц (январь) ранее закрывался без сбоев. В версиях линейки 2.4.5 и 2.4.6 фирма «1С» кардинально переписала внутренние алгоритмы движка «Партионный учет 2.2». Новые релизы стали значительно строже относиться к расхождениям в аналитике учета номенклатуры. Если старый алгоритм просто списывал стоимость по упрощенной схеме или игнорировал мелкие ошибки, то новый пытается во что бы то ни стало построить математически точный направленный граф. При наличии ошибок в данных алгоритм начинает зацикливаться.
Выделим основные технические причины, приводящие к зависанию партионного движка:
ВводНачальныхОстатков. Наличие суммовых остатков без количественных (или наоборот) приводит к невозможности корректного расчета себестоимости партий.Рассмотрим метод локализации проблемы, основанный на анализе резервных копий. Выполним следующие действия:
Если после обновления на тестовой базе процедура закрытия зависла так же, как на рабочей, — дело исключительно в изменении алгоритмов платформы/конфигурации, которые «не переваривают» специфику ваших исторических данных. Если же на обновленной тестовой базе закрытие прошло быстро — значит, в рабочей базе задним числом были изменены или перепроведены документы января.
Проанализируем оперативную отчетность. Нам необходимо полностью исключить отрицательные остатки товаров на любую дату внутри закрываемого месяца. Сформируем отчет «Ведомость по товарам на складах» за январь с детализацией до регистратора.
Если в течение месяца возникают ситуации, когда расход проводится раньше прихода (даже в пределах одного дня), это ломает последовательность партионного учета. Нам нужно исправить время проведения документов, чтобы приходные накладные всегда были записаны раньше расходных документов.
Поскольку январь — это первый месяц работы в программе, особое внимание уделим документам ВводНачальныхОстатков. Проверим соблюдение трех жестких правил:
СебестоимостьТоваров гарантированно приведет к зависанию распределения партий. Для выявления таких позиций можно использовать консоль запросов.Рассмотрим пример запроса, который мы можем написать в консоли запросов для быстрого поиска «зависшей» стоимости без количества на начало ведения учета:
ВЫБРАТЬ
СебестоимостьОстатки.АналитикаУчетаНоменклатуры.Номенклатура КАК Номенклатура,
СебестоимостьОстатки.РазделУчета КАК РазделУчета,
СебестоимостьОстатки.КоличествоОстаток КАК Количество,
СебестоимостьОстатки.СтоимостьОстаток КАК Стоимость
ИЗ
РегистрНакопления.СебестоимостьТоваров.Остатки(&НачалоПериода, ) КАК СебестоимостьОстатки
ГДЕ
СебестоимостьОстатки.КоличествоОстаток <= 0
И СебестоимостьОстатки.СтоимостьОстаток <> 0
Если запрос вернул строки — необходимо скорректировать соответствующие документы ввода начальных остатков, добавив количество или убрав некорректную стоимость.
Если в нашей базе настроена передача товаров между организациями, проверим корректность оформления этих документов. Откроем отчет «Контроль передач товаров между организациями». Если в январе были продажи товаров, принадлежащих другой организации, но документы передачи товаров (выкуп) оформлены не были, партионный учет не сможет завершить цепочку списания. Оформим все недостающие передачи товаров между фирмами.
Проанализируем, действительно ли проблема кроется только в партионном движке. Для этого выполним диагностический тест:
Расчет по средней стоимости не строит сложные направленные графы партий, поэтому он должен выполниться за несколько минут. Если расчет по средней завершился успешно и быстро, это подтверждает, что физическая структура данных и регистры в порядке, а проблема кроется именно в логических петлях и ошибках партионного учета ФИФО.
Если мы используем релиз 2.4.6.162, то работаем на версии с неоптимальными и устаревшими алгоритмами распределения партий. В последующих релизах веток 2.4.13, 2.4.14 и при переходе на редакцию 2.5 фирма «1С» внесла множество критических исправлений:
КорректировкаРеализации и ВозвратТоваровОтКлиента.Рекомендуется обновить конфигурацию до актуального релиза. Это позволит избежать проявления системных ошибок платформы.
Процедура расчета себестоимости активно использует создание, индексацию и чтение огромного количества временных таблиц в базе данных tempdb на сервере MS SQL Server. Если дисковая подсистема сервера перегружена, запись миллионов строк будет длиться часами. Проведем техническую оптимизацию:
tempdb на самые быстрые твердотельные накопители (SSD NVMe).
EXEC sp_updatestats;
DBCC FREEPROCCACHE;
Выполнив последовательно все указанные шаги — от анализа остатков до технической оптимизации СУБД и обновления конфигурации, — мы сможем успешно закрыть проблемный месяц и обеспечить стабильную и быструю работу процедуры закрытия месяца в будущем.