Каждый администратор и разработчик систем на базе 1С:ERP Управление предприятием рано или поздно сталкивается с ситуацией, когда регламентная процедура закрытия месяца начинает вести себя непредсказуемо. Система может часами «висеть» на этапе расчета себестоимости, нагружать процессор сервера под 100% или вовсе аварийно завершать работу без видимых причин. При этом стандартные административные меры — такие как тестирование и исправление базы данных, очистка серверного кэша или перестроение индексов на стороне СУБД MS SQL Server — не дают абсолютно никакого результата.
В этой статье мы подробно разберем, почему возникает подобное зависание, как локализовать проблему с помощью анализа служебных регистров сведений и какие шаги необходимо предпринять, чтобы вернуть скорость расчета себестоимости к штатным показателям.
Проанализируем ситуацию, когда система зависает еще на этапе открытия самой обработки «Закрытие месяца» или в первые минуты после запуска расчета себестоимости. Одной из главных причин такого поведения является накопление некорректных, устаревших или «битых» записей в специализированных регистрах сведений, которые 1С:ERP использует для отслеживания изменений в документах.
Дело в том, что при проведении любого документа, влияющего на складские остатки, затраты или расчеты, система регистрирует необходимость пересчета. Для этого используются служебные регистры сведений типа «Задания к...». Если в этих таблицах появляются некорректные данные, математический аппарат расчета себестоимости уходит в бесконечный цикл или тратит колоссальное количество времени на обработку несуществующих периодов.
Рассмотрим ключевые регистры сведений, которые нам необходимо проверить в первую очередь:
РегистрСведений.ЗаданияКРасчетуСебестоимости — хранит информацию о необходимости пересчета себестоимости товаров по организациям.РегистрСведений.ЗаданияКРаспределениюРасчетов — отвечает за актуализацию расчетов с клиентами и поставщиками.РегистрСведений.ЗаданияКФормированиюЗаписейКнигиПокупокКнигиПродаж — содержит очередь для регламентных операций по НДС.Выясним причину сбоя на конкретном примере. Откроем эти регистры напрямую через функции для технического специалиста или с помощью Универсального отчета. Нам нужно обратить особое внимание на записи, которые содержат:
30.11.0487, 01.01.2008) или далекого будущего.<Объект не найден...> (битая ссылка).Если такие записи присутствуют, алгоритм закрытия месяца пытается инициализировать расчет себестоимости начиная с этих некорректных дат. Система пытается сопоставить данные начала нашей эры с текущими остатками, что приводит к многочасовому зависанию СУБД.
Разберем, как исправить найденные ошибки. Непосредственное удаление записей вручную из формы списка регистра может быть заблокировано системой или неудобно при большом объеме данных. В таком случае мы можем воспользоваться простой обработкой или написать код в консоли кода для удаления записей с некорректными датами или пустыми ссылками.
Посмотрим на пример программного кода для удаления битых записей из регистра ЗаданияКРасчетуСебестоимости:
НаборЗаписей = РегистрыСведений.ЗаданияКРасчетуСебестоимости.СоздатьНаборЗаписей();
// Устанавливаем отбор по пустой организации или некорректному документу, если применимо.
// Либо считываем все записи, анализируем их в цикле и удаляем только поврежденные.
НаборЗаписей.Прочитать();
ТаблицаЗаписей = НаборЗаписей.Выгрузить();
КоличествоДоУдаления = ТаблицаЗаписей.Количество();
Индекс = ТаблицаЗаписей.Количество() - 1;
Пока Индекс >= 0 Цикл
СтрокаЗаписи = ТаблицаЗаписей[Индекс];
// Проверяем некорректную дату (например, ранее 2015 года) или битую ссылку
Если СтрокаЗаписи.Месяц < '20150101' Или СтрокаЗаписи.Документ.Пустая() Тогда
ТаблицаЗаписей.Удалить(СтрокаЗаписи);
КонецЕсли;
Индекс = Индекс - 1;
КонецЦикла;
Если КоличествоДоУдаления <> ТаблицаЗаписей.Количество() Тогда
НаборЗаписей.Загрузить(ТаблицаЗаписей);
НаборЗаписей.Записать(Истина);
Сообщить("Регистр успешно очищен от некорректных заданий!");
КонецЕсли;
После удаления записей с аномальными датами (например, записей за 2008 год или с пустыми документами) скорость открытия обработки «Закрытие месяца» мгновенно возвращается к стандартным нескольким секундам, а сам процесс расчета перестает спотыкаться на несуществующих периодах.
Что делать, если все служебные регистры чисты, но расчет себестоимости все равно неоправданно затягивается или зависает? Проанализируем методологические ошибки ведения учета в 1С:ERP, которые напрямую влияют на скорость работы математического ядра СЛАУ (системы линейных алгебраических уравнений), распределяющего затраты.
Если вы работаете на устаревших релизах платформы (например, ниже 8.3.14) и старых версиях ERP (линейка 2.2.х), вы сталкиваетесь с архитектурным ограничением старого движка расчета. В старых конфигурациях решение СЛАУ выполнялось кодом на встроенном языке 1С. Это требовало колоссальных объемов оперативной памяти на сервере приложений.
Начиная с версии платформы 8.3.14 и релизов ERP 2.4.8+, разработчики фирмы «1С» вынесли решение систем линейных уравнений непосредственно на уровень платформы (алгоритмы оптимизированы и реализованы на языке C++). Это позволило ускорить этап расчета себестоимости в разы и практически полностью исключило зависания по причине нехватки оперативной памяти (ошибка Out of memory). Если закрытие месяца регулярно вешает сервер, настоятельно рекомендуем рассмотреть вопрос обновления платформы и конфигурации.
Рассмотрим инфраструктурные «бутылочные горлышки», которые могут замедлять расчет себестоимости даже на идеально чистой базе данных:
tempdb. Если эта база расположена на медленном диске или для нее настроен некорректный шаг авторасширения (например, по умолчанию 1 Мб), то СУБД будет постоянно тратить время на дисковые операции выделения пространства. Рекомендуется перенести tempdb на самые быстрые SSD/NVMe накопители и установить фиксированный размер файлов базы данных.High Performance). В режиме динамического управления питанием процессор может не повышать частоту одного ядра, на котором выполняется однопоточный расчет себестоимости, считая общую нагрузку на многоядерный сервер незначительной.Регулярно проводя профилактику служебных регистров сведений и контролируя отсутствие отрицательных остатков на складах, мы обеспечим стабильную, быструю и предсказуемую работу процедуры закрытия месяца в вашей системе 1С:ERP.