Переход с исторических систем (например, УПП) на современные решения класса ERP часто сопровождается вопросами производительности. Одной из самых болезненных точек является процедура Закрытие месяца. Если в старых системах расчет мог занимать 40 минут, то в ERP пользователи нередко сталкиваются с ситуацией, когда процедура длится 4–6 часов или даже суток. Разберем подробно, почему это происходит и какие шаги необходимо предпринять для оптимизации этого процесса.
Мы проанализируем ситуацию комплексно: от методологических ошибок пользователей до тонких технических настроек платформы и СУБД. Наша задача — сократить время простоя системы и добиться стабильного выполнения регламентных операций.
Первое, с чего нам следует начать, — это аудит используемой аналитики. В отличие от РАУЗ в УПП, архитектура регистров в ERP построена иначе. Избыточная детализация здесь наказывается экспоненциальным ростом времени выполнения запросов при расчете себестоимости.
Рассмотрим типичную ошибку, упомянутому в обсуждении. Заказчики часто пытаются перенести логику старого учета "в лоб". Например, создают отдельную НоменклатурнуюГруппу для каждого элемента справочника Номенклатура или Продукция. Это приводит к катастрофическому раздуванию таблиц.
Почему это тормозит систему?
При расчете себестоимости система строит сложные деревья распределения затрат. Если количество уникальных сочетаний аналитик (ключей) исчисляется миллионами, сервер СУБД тратит все ресурсы не на расчет, а на операции соединения таблиц (JOIN).
Что нам нужно сделать:
ГруппыАналитическогоУчетаНоменклатуры. Их не должно быть слишком много (один к одному с номенклатурой — это ошибка).Одна из главных причин длительного закрытия — постоянные перезапуски процедуры из-за ошибок. Если мы запускаем расчет, ждем 2 часа, получаем ошибку "Отрицательный остаток", исправляем и запускаем снова — мы теряем дни.
Эффективным решением, которое мы применим, является создание внешних отчетов-проверок. Смысл метода заключается в том, чтобы исправить данные до запуска тяжелой процедуры закрытия. Например, для оперативного исправления дефицита в цехах можно использовать заполнение документа «Передача материалов в производство» по отрицательным остаткам.
Нам необходимо реализовать отчеты, контролирующие следующие показатели:
РасчетыСКлиентами и РасчетыСПоставщиками.НезавершенноеПроизводство без выпуска.Исправляя эти ошибки в оперативном режиме в течение месяца, мы значительно разгружаем регламентную процедуру в конце периода.
1C:ERP умеет выполнять задачи параллельно, но эта возможность должна быть корректно настроена. Часто администраторы оставляют настройки "по умолчанию", что приводит к использованию лишь одного ядра мощного сервера.
Перейдем в раздел НСИ и администрирование — Прочее и найдем настройки регламентных заданий. Нам нужно обратить внимание на параметры многопоточности.
Рекомендации по настройке:
Также обратим внимание на режим "Предварительный расчет". Мы можем настроить расписание так, чтобы система каждую ночь выполняла предварительный расчет. Кроме того, можно использовать специализированный отчет, чтобы увидеть прибыль, себестоимость и рентабельность без закрытия месяца, что позволит менеджменту получать цифры, не дожидаясь финализации периода.
Самый ресурсоемкий этап — это решение систем линейных уравнений (СЛУ) при расчете себестоимости. Это происходит, когда у нас есть сложные схемы распределения косвенных расходов.
Проанализируем наши правила распределения расходов. Главный враг производительности здесь — циклические ссылки (встречный выпуск или перекрестное распределение затрат). К ним часто приводят ошибки в ресурсных спецификациях. Чтобы их исключить, рекомендуется регулярная проверка зацикливания спецификации.
Для решения таких систем ERP использует итерационные методы, которые могут работать очень долго. Если мы упростим модель учета, разорвав циклические связи или заменив базу распределения на фиксированную (где это допустимо), мы получим кратный прирост производительности.
В процессе работы в регистрах сведений накапливаются неиспользуемые записи. В ERP критически важными являются регистры группы КлючиАналитики... (например, КлючиАналитикиУчетаНоменклатуры, КлючиАналитикиУчетаПартнеров).
Если мы часто меняем настройки, перепроводим документы с разными параметрами, таблица ключей разрастается. Помимо самих ключей, нагрузку создают и устаревшие данные в связанных таблицах, поэтому полезно периодическое удаление неактуальных цен, валют и версий объектов.
Разберем, как бороться с разрастанием аналитики. В составе конфигурации или в библиотеке стандартных подсистем существуют обработки по свертке и удалению неиспользуемых ключей. Рекомендуется регулярно (раз в квартал) выполнять процедуру Удаление неиспользуемых ключей аналитики. Это "технический мусор", который не виден пользователю, но сильно тормозит систему.
Даже идеально настроенная 1С будет тормозить на плохо настроенном SQL Server или PostgreSQL. Для выявления проблем на этом уровне полезно провести комплексный замер производительности контура 1С и поиск узких мест.
Обновление статистики
Часто план обслуживания настроен на обновление статистики раз в сутки (ночью). Однако закрытие месяца создает и модифицирует огромные временные таблицы в процессе работы. Статистика устаревает мгновенно.
Мы рекомендуем настроить принудительное обновление статистики именно для таблиц регистров накопления (CUMULATIVE...) и регистров сведений, участвующих в расчете, непосредственно перед запуском процедуры закрытия месяца.
TempDB
Механизм расчета себестоимости в ERP чрезвычайно активно использует временные таблицы (tempdb). Если файл tempdb расположен на медленном диске, закрытие будет идти часами. Вынесем tempdb на самый быстрый доступный носитель (NVMe SSD или даже RAM-диск, если позволяет оперативная память).
Наконец, посмотрим на учетную политику. В версиях ERP (особенно до 2.5) метод оценки "ФИФО (Скользящая оценка)" является наиболее ресурсоемким. Он требует точного отслеживания партий в каждом движении.
Если бизнес-процессы компании позволяют, рассмотрите переход на "Средневзвешенную оценку". Математически она рассчитывается значительно быстрее, так как системе не нужно решать задачу подбора партий при списании. Если же ФИФО строго необходимо, убедитесь, что вы используете актуальный релиз конфигурации (версии 2.5.x+), где механизм партионного учета был переработан и оптимизирован по сравнению с ранними версиями.
Ускорение закрытия месяца в ERP — это не поиск одной "волшебной галочки". Это комплекс мер:
Применяя эти подходы последовательно, мы сможем сократить время расчета с нескольких дней до приемлемых нескольких часов.