← На главную

Длительное выполнение процедуры закрытия месяца и расчета себестоимости в 1С:ERP Управление предприятием — одна из наиболее частых проблем на производственных предприятиях. Ситуация, когда на относительно небольшом массиве документов (порядка 8–10 тысяч документов в месяц) регламентная процедура закрытия длится 6–7 часов, не является нормальной. В большинстве случаев основное время занимает этап «Формирование движений по партиям и расчет себестоимости», а также последующее отражение документов в регламентированном учете.

Разберем по шагам, как локализовать узкие места, устранить учетные коллизии, правильно настроить регламентные задания и оптимизировать параметры платформы и СУБД.

1. Локализация проблемы с помощью Журнала регистрации

Прежде чем приступать к оптимизации оборудования или переписыванию процедур, выясним, на каком конкретно этапе система зависает. Для этого проанализируем записи журнала регистрации:

1. Открываем Журнал регистрации в меню администрирования.
2. Устанавливаем отбор по событию: Расчет партий и себестоимости.Протокол расчета.
3. Смотрим детальный протокол: платформа 1С фиксирует в журнале каждый шаг расчета, включая время подготовки данных, решение систем линейных уравнений, распределение дополнительных расходов и формирование движений по регистрам.
4. Анализируем время выполнения отдельных шагов: если расчет себестоимости занимает 30 минут, а формирование движений по партиям или переотражение документов в регл. учете идет более 5 часов, узкое место находится в детализации партий или массовом сбросе статусов отражения проводок.

2. Исправление учетных ошибок и оптимизация производственных цепочек

В большинстве производственных баз первопричина многочасового расчета кроется в методических ошибках ведения учета. Алгоритмы распределения партий работают итеративно, и при наличии коллизий число итераций лавинообразно растет:

1. Устранение отрицательных остатков: если в регистрах партий или запасов возникают остатки со знаком «минус» (списание раньше оприходования), система пытается найти партии для покрытия разрывов, перебирая огромные массивы данных. Все отрицательные остатки должны выявляться и устраняться проверочными отчетами ДО старта процедуры закрытия месяца.
2. Анализ встречного выпуска и кольцевых затрат: ситуация, когда подразделение А передает полуфабрикат в подразделение Б, а подразделение Б возвращает доработанную продукцию или отходы обратно в подразделение А в рамках одного периода (встречный выпуск). Решение таких систем уравнений требует большого числа итераций. Для ускорения расчета настраивают четкую последовательность этапов производства либо разделяют номенклатуру по уникальным характеристикам или сериям.
3. Выбор метода оценки стоимости: метод «ФИФО (скользящая оценка)» требует строго хронологического поштучного расчета каждого движения по всей цепочке документов. Переход на «ФИФО (взвешенная оценка)» или «Средняя за месяц» значительно снижает вычислительную сложность, так как расчет себестоимости выполняется агрегированно за отчетный период.

3. Настройка регулярного регламентного расчета партий

Типичная ошибка регламента работы — запускать формирование партий исключительно в конце месяца. При таком подходе система вынуждена за один сеанс обрабатывать миллионы записей движений за все 30 дней.

Для решения этой проблемы настроим фоновое выполнение процедур:

1. Включаем штатное регламентное задание Формирование движений по партиям и себестоимости.
2. Задаем расписание с запуском каждые 15–30 минут (или в нерабочие часы ночью).
3. При таком подходе партии распределяются инкрементально в течение всего месяца. К моменту финального закрытия периода зам. главного бухгалтера обрабатывает только финальные корректировки, что сокращает итоговую процедуру закрытия в разы.

4. Архитектура конфигурации: версии партионного учета

Если система работает на устаревших релизах линейки 2.1 (например, 2.1.3), в ней задействован старый механизм партионного учета, выполнявший большое количество последовательных запросов и блокировок таблиц. Начиная с версии 2.2, в конфигурацию внедрен механизм «Партионный учет 2.2».

Новая архитектура использует векторные алгоритмы расчета затрат и графы переделов, что исключает избыточные пересчеты и позволяет задействовать многопоточное закрытие месяца. Обновление конфигурации до актуальных версий дает кратный прирост производительности на этапе закрытия месяца.

5. Тонкая настройка сервера и СУБД MS SQL Server

Процедура закрытия месяца создает интенсивную нагрузку на дисковую подсистему и центральный процессор. Выполним ключевые технические настройки:

1. Производительность процессора (CPU Single-Core Performance): серверный процесс rphost выполняет значительную часть вычислительных алгоритмов в один поток. Сервер с меньшим числом ядер, но с высокой базовой частотой (от 3.5–4.0 ГГц) справляется с закрытием месяца в 1С значительно быстрее многоядерных процессоров с низкой частотой (2.0–2.2 ГГц).
2. Оптимизация служебной базы `tempdb`: расчет партий оперирует огромным числом временных таблиц. Необходимо:
   • Разместить файлы tempdb на быстрых NVMe/SSD-дисках.
   • Разбить базу tempdb на несколько файлов данных одинакового размера (по числу физических ядер, обычно 4–8 файлов).
   • В MS SQL Server 2014 активировать флаги трассировки -T1117 (равномерный рост файлов) и -T1118 (выделение страниц полными экстентами для снижения блокировок SGAM/PFS).
3. Параметры параллелизма в MS SQL Server: параметр Cost Threshold for Parallelism необходимо поднять со стандартного значения 5 до 30–50, чтобы СУБД не тратила ресурсы на распараллеливание простых подзапросов, а значение Max Degree of Parallelism (MAXDOP) ограничить количеством ядер в рамках одного NUMA-узла (обычно от 2 до 6).
4. Управление Cardinality Estimation: при работе с MS SQL Server 2014 новый оптимизатор запросов может строить неоптимальные планы на временных таблицах 1С. Включение флага трассировки -T9481 (или включение режима устаревшей оценки кардинальности для базы) помогает стабилизировать скорость выполнения сложных запросов закрытия месяца.