Почему долго проводится расчет себестоимости по РАУЗ в 1С:УПП и как ускорить этот процесс?

Проведение документа «Расчет себестоимости выпуска» при использовании режима расширенной аналитики учета затрат (РАУЗ) в конфигурации «1С:Управление производственным предприятием» может занимать десятки часов или завершаться падением рабочего процесса с разрывом соединения. Проанализируем ключевые причины таких задержек и разберем по шагам действенные способы ускорения проведения.

1. Проверка актуальности итогов регистров накопления

Рассмотрим одну из наиболее распространенных причин зависания на этапе записи движений — пересчет итогов регистров накопления. Если точка рассчитанных итогов в базе отстает от периода проведения документа, СУБД вынуждена рассчитывать и перезаписывать агрегированные данные на весь промежуток времени от даты итогов до текущей даты.

Выясним, как правильно обслужить итоги регистров:

1. Откроем режим управления итогами через меню конфигуратора или с помощью обработки «Управление итогами».
2. Рассчитаем и установим период итогов регистров накопления на конец месяца, предшествующего месяцу расчета себестоимости.
3. Убедимся, что пересчет итогов выполняется регулярно перед процедурой закрытия месяца.

2. Оптимизация уровня параллелизма в MS SQL Server (MAXDOP)

Проанализируем поведение СУБД. Высокий уровень параллелизма (MAXDOP со значением 8 и более) при массовых операциях записи движений часто вызывает субоптимальные планы запросов, длительное ожидание ресурсов и блокировки таблиц итогов.

Для корректной работы 1С с СУБД MS SQL Server ограничим параллелизм выполнения индивидуальных запросов:

1. Запустим SQL Server Management Studio (SSMS) и откроем свойства сервера.
2. Перейдем на страницу Advanced.
3. Установим параметр Max Degree of Parallelism (MAXDOP) в значение 1 (в редких случаях — 2).

Рассмотрим пример тяжелого SQL-запроса к таблице итогов регистра, задержки в котором возникают при некорректном параллелизме:

UPDATE T2 
SET _Fld20879 = T2._Fld20879 + T1._Fld20879, 
    _Fld20880 = T2._Fld20880 + T1._Fld20880, 
    _Fld20881 = T2._Fld20881 + T1._Fld20881
FROM #tt20 T1 WITH(NOLOCK)
INNER JOIN dbo._AccumRgT20892 T2 WITH(TABLOCK)
ON T1._Period = T2._Period 
   AND T1._Fld20875RRef = T2._Fld20875RRef 
   AND T1._Fld20876RRef = T2._Fld20876RRef 
   AND T1._Fld20877RRef = T2._Fld20877RRef 
   AND T1._Fld20878RRef = T2._Fld20878RRef 
   AND T2._Splitter = P1

3. Обновление статистики и обслуживание индексов

При расчете РАУЗ система генерирует большой объем временных таблиц и производит многократные изменения в регистрах затрат. Если статистика СУБД неактуальна, оптимизатор SQL создает неэффективные планы запросов.

Выполним регулярный регламент обслуживания СУБД:

1. Настроим регулярное обновление статистики (UPDATE STATISTICS) перед запуском расчета себестоимости.
2. Проведем дефрагментацию или перестроение индексов (REBUILD INDEX) для основных таблиц регистров накопления и сведений.

4. Диагностика дисковой подсистемы и TempDB

Посмотрим на аппаратную часть сервера. При построении и решении системы алгебраических уравнений (СЛУ) платформой выполняется интенсивный ввод-вывод. Очередь к диску и размещение базы данных на медленных накопителях создают узкое место (I/O Bottleneck).

Для решения дисковых проблем применим следующие рекомендации:

1. Перенесем базу данных 1С и базу TempDB на высокоскоростные накопители SSD или NVMe.
2. Разделим TempDB на несколько файлов данных одинакового размера (по количеству физических ядер процессора, но не более 8).
3. Ограничим максимальный объем памяти для SQL Server (Max Server Memory), чтобы предотвратить дефицит ОЗУ у процесса rphost сервера приложений 1С.

5. Корректировка точности вычислений РАУЗ

В настройках параметров учета для алгоритмов РАУЗ задается допустимая погрешность расчета решений СЛУ. Если установлена слишком высокая точность или в учете присутствует мелкое дробление копеек, система тратит сотни итераций на сведение матрицы.

Проанализируем точность вычислений:

1. Проверим настройки закрытия месяца и параметры расчета себестоимости.
2. Если система делает избыточные итерации ради выравнивания копеек, попробуем незначительно снизить точность вычислений (увеличить допустимую погрешность).

6. Поиск и устранение отрицательных остатков

Один из самых частых факторов, приводящих алгоритм расчета в замкнутый цикл, — наличие отрицательных остатков по аналитикам учета затрат или партий (количественных и суммовых списаний «в минус»).

Выясним, как выявить проблемы в данных перед расчетом:

1. Сформируем отчет «Проверка учета затрат» за рассчитываемый период.
2. Проверим наличие нулевых остатков по количеству с ненулевой суммой и наоборот.
3. Устраним обнаруженные отрицательные остатки и выправим последовательность документов.

7. Оптимизация способов проведения документа

Разберем дополнительные варианты проведения, встроенные в УПП:

1. В документе «Расчет себестоимости» воспользуемся режимом проведения «Провести вне транзакции» (доступно в меню действий документа). Это уменьшит влияние длительных транзакционных блокировок при обработке больших массивов данных.
2. Если позволяет методология предприятия, разделим расчет себестоимости на отдельные документы по видам учета (сначала управленческий учет, затем регламентированный) или по отдельным организациям.