Как ускорить расчет и проведение партий товаров в 1С:Управление торговлей 10.3?

При большой активности пользователей и высоком документообороте процесс партионного учета по методу ФИФО в типовой конфигурации 1С:Управление торговлей 10.3 начинает существенно замедляться. Перепроведение документов за прошлые периоды может занимать долгие часы и приводить к блокировкам СУБД. Проанализируем основные причины этой проблемы и разберем эффективные варианты ускорения партионного учета — от доработки архитектуры запросов до оптимизации СУБД и изменения методики учета.

Основные причины замедления партионного учета

Выясним, почему стандартный пересчет партий начинает тормозить со временем:

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

Вариант 1. Оптимизация определения даты партии через журнал документов

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

Разберем порядок действий по оптимизации:

1. Создадим в конфигураторе специализированный журнал документов, в который включим все документы, формирующие партии товаров (Приходная накладная, Чек ККМ, Отчет о розничных продажах и др.).
2. В алгоритме списывания партий изменим запрос получения партионных остатков: вместо соединения с таблицами отдельных документов обратимся напрямую к созданному журналу.
3. Получение даты партии непосредственно из индексированной таблицы журнала ускоряет выборку и дает прирост производительности при проведении списывающих документов.

Вариант 2. Отключение проверок и оперативности при массовом проведении

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

Сформулируем правила для ускорения группового проведения:

1. Перед массовым пересчетом партий отключим проведение по всем регистрам, кроме регистра ПартииТоваровНаСкладах.
2. Программно взведем флаг неоперативного проведения, чтобы алгоритмы не выполняли дополнительные проверки наличия товара на складе «здесь и сейчас».
3. Исключим вызов интерактивных форм и обработок событий при проведении документов алгоритмом восстановления последовательности.

Вариант 3. Перезапись движений через НаборЗаписей без проведения документа

Посмотрим на более радикальный технический ход: полное разделение документа и его партионных движений. Чтобы не «перепроводить» сам документ со всеми его накладными расходами, используем объект НаборЗаписей.

Алгоритм работы следующего вида снижает нагрузку на СУБД в несколько раз:

1. Считываем массив документов, требующих восстановления партий.
2. Формируем партионные движения полностью в оперативной памяти или через специализированную обработку.
3. Записываем сформированные движения напрямую в регистр накопления ПартииТоваровНаСкладах, отключив замещение и обходя стандартные подписки документа:

НаборЗаписей = РегистрыНакопления.ПартииТоваровНаСкладах.СоздатьНаборЗаписей();
НаборЗаписей.Отбор.Регистратор.Установить(СсылкаНаДокумент);

// Заполняем НаборЗаписей рассчитанными движениями
// ...

НаборЗаписей.ОбменДанными.Загрузка = Истина; // Отключаем лишние проверки
НаборЗаписей.Записать();

Вариант 4. Распараллеливание (многопоточность) по номенклатуре

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

Корректный способ параллельной обработки через фоновые задания:

1. Распределяем весь массив товаров по отдельным потокам (фоновым заданиям) строго по аналитике номенклатуры (например, по хэшу кода товара или ссылке).
2. Каждый поток пересчитывает партии только для выделенной группы товаров изолированно.
3. Так как списываемые партии одного товара абсолютно не зависят от остатков другого товара, потоки выполняются параллельно без блокировок СУБД на всех ядрах сервера приложений.

Вариант 5. Настройка СУБД и отключение итогов на время расчета

Рассмотрим действия на уровне платформы 1С и базы данных, которые помогут выжать максимум производительности:

1. Отключение итогов регистра партий: Перед запуском тотального пересчета партий вызовем метод УстановитьИспользованиеИтогов(Ложь) для регистра партий. После завершения записи всех движений включим итоги обратно и выполним однократный пересчет итогов. Это сэкономит время СУБД на постоянный пересчет агрегатов.
2. Обновление статистики СУБД: В процессе массовой перезаписи таблиц регистра статистика MS SQL Server или PostgreSQL быстро устаревает. Настроим регламентное выполнение команды UPDATE STATISTICS каждые 10 000–20 000 обработанных документов.
3. Дисковая подсистема: Убедимся, что файлы базы данных и временные таблицы СУБД размещены на быстрых SSD (NVMe) дисках. Это критично для операций активной перезаписи регистров.

Вариант 6. Изменение методики учета (По средней / РАУЗ)

Посмотрим на проблему с точки зрения методологии учета. В 99% случаев детальный партионный учет по ФИФО в торговых организациях не является законодательным требованием и лишь усложняет сопровождение системы.

Сложившиеся альтернативы:

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

Подведем итог: Для быстрого точечного ускорения без изменения методики учета оптимизируем запросы партий с помощью журнала документов и перезаписываем движения наборами записей с отключенными проверками. Если требуется кардинальное решение проблемы блокировок на больших объемах данных — внедряем многопоточный пересчет по номенклатуре или переходим на учет по средней себестоимости.