Как ускорить закрытие месяца в 1С:ERP 2.4 при экстремально долгом расчете партионного учета?

Ситуация, когда время закрытия месяца в 1С:ERP 2.4 резко увеличивается с приемлемых 12 часов до катастрофических 60 и более, часто ставит в тупик даже опытных специалистов. Основной удар обычно приходится на этап ПодготовкаДанныхДляУчетаНДСиУСН2_4 или расчет себестоимости. Разберем детально, как проанализировать протоколы расчета, найти «узкие места» в данных и оптимизировать работу системы.

Анализируем показатели графа: что значат цифры в протоколе?

Для начала проанализируем технический журнал этапа партионного учета. Если мы видим показатели, подобные приведенным в обсуждении, это прямой сигнал о проблемах в структуре данных:

• ОжиданиеДанных (более 1 млрд): Этот счетчик увеличивается экспоненциально, когда система пытается рассчитать узел графа, но не может этого сделать, так как зависящие от него данные еще не готовы. Такое огромное число говорит о том, что граф расчета «перепутан» — существует колоссальное количество взаимозависимых документов.
• Зацикливание (десятки тысяч): Это критический маркер. Циклы возникают, когда товар перемещается по кругу (например, Склад А -> Склад Б -> Склад А) или когда в производстве продукция сама же используется как сырье (через несколько переделов) в одном периоде. Система пытается «разрулить» это итерациями, что превращает расчет в бесконечный процесс.
• Глубина обхода (от 50 и выше): В норме глубина цепочек в реальном производстве составляет 5–15 уровней. Показатель 50+ свидетельствует о «кольцевых» перемещениях между складами или организациями (интеркампани), которые система не может эффективно свернуть.

Проблема «Мега-графа» и потеря параллелизма

Рассмотрим ситуацию, когда почти все узлы (например, 1.9 млн из 1.9 млн) попадают в один огромный подграф. В норме 1С:ERP должна разбивать расчет на множество мелких независимых цепочек (подграфов), которые рассчитываются параллельно в несколько потоков.

Если же все документы месяца связались в один «ком», расчет фактически идет в один поток. Любая ошибка или «тяжелый» документ в этой цепочке тормозит весь массив данных. Чаще всего это происходит из-за использования общих ресурсов: например, одна и та же номенклатурная позиция, которая проходит через все документы производства и перемещения, или один склад, через который «прогоняется» абсолютно всё движение компании.

Аномалии временных таблиц: ВТПлановыеЦены

Проанализируем этап формирования временных таблиц. Если ВТПлановыеЦены формируется несколько часов (в нашем примере — почти 6 часов), это явная аномалия. Выясним причины:

1. В системе не установлены цены номенклатуры для типа цен, указанного в настройках как «плановый».
2. Записей в регистре ЦеныНоменклатуры миллионы, и SQL-сервер не может эффективно построить срез последних.
3. Рекомендуется проверить, заполнены ли плановые цены для всей продукции, участвующей в выпуске, и актуализировать статистику по этому регистру.

Поиск «битых» данных и пустых аналитик

Иногда причиной «схлопывания» всех расчетов в один гигантский граф является наличие некорректных записей в регистрах. Выясним, как их найти. В сообщении упоминается запись с пустым полем Документ в регистре ДетализацияПартийТоваровДляНДСиУСН2_4.

Пустое поле «Документ-регистратор» или «Документ-источник» заставляет систему считать, что эта запись относится ко всем операциям сразу. Это связывает все независимые цепочки в один мега-граф. Проанализируем регистры с помощью консоли запросов:

ВЫБРАТЬ
    *
ИЗ
    РегистрНакопления.ДетализацияПартийТоваровДляНДСиУСН2_4 КАК Детализация
ГДЕ
    Детализация.Период МЕЖДУ &НачалоПериода И &КонецПериода
    И Детализация.Регистратор ЕСТЬ NULL

Также стоит проверить регистр АналитикаУчетаНоменклатуры на наличие дублей или пустых значений. Если одна и та же номенклатура на одном складе имеет разные ключи аналитики, это создает избыточные связи, которые перегружают алгоритм распределения.

Техническая оптимизация SQL и платформы

При огромных объемах данных (сотни миллионов движений) стандартные настройки могут не справляться. Рассмотрим шаги по технической настройке:

• TempDB: При расчете партий ERP активно использует временные таблицы. Убедимся, что TempDB вынесена на самый быстрый диск (NVMe) и разделена на несколько файлов по числу ядер процессора.
• Обновление статистики: Перед закрытием месяца крайне желательно обновить статистику SQL вручную по регистрам партий и себестоимости. Стандартный регламент может не успевать за лавинообразным ростом данных во время расчета.
• Механизм СЛУ: Хотя отключение Системы Линейных Уравнений (СЛУ) помогает при расчете косвенных затрат, в случае проблем с партионным учетом важнее проверить настройку «Количество потоков обновления партий». Попробуем уменьшить количество потоков до 2-4 (вместо авто-настройки или высоких значений). Парадоксально, но это часто ускоряет расчет за счет снижения блокировок на уровне базы данных.

Рекомендации по локализации «виновника»

Чтобы найти конкретную номенклатуру или склад, вызывающий зацикливание, проанализируем следующие отчеты и регистры:

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

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