Проблема медленного расчета себестоимости в крупных базах 1С:Управление торговлей 11.5 — одна из самых частых задач, с которыми сталкиваются технические специалисты. В попытках ускорить процесс часто возникают идеи вмешаться в программный код, чтобы система обрабатывала не весь массив данных, а только «нужные» товары. В этой статье мы подробно разберем, почему такой подход опасен, и какие системные методы действительно помогают сократить время выполнения регламентных операций.
Рассмотрим ситуацию: разработчик находит процедуру расчета и пытается наложить фильтр по конкретной номенклатуре. На первый взгляд, это логично — если нам важна прибыль только по определенной группе товаров, зачем тратить ресурсы на всё остальное? Однако проанализируем внутреннюю архитектуру УТ 11.5. Расчет себестоимости здесь — это не просто арифметическое умножение количества на цену прихода. Это решение сложной системы линейных уравнений.
Основные риски модификации алгоритма:
СебестоимостьТоваров и ВыручкаИСебестоимостьПродаж. Если рассчитать часть записей, нарушится общая сходимость партионного учета, и последующие отчеты (например, валовая прибыль) будут показывать недостоверную информацию.Выясним причину медленной работы на уровне инфраструктуры. Как показывает практика, часто проблема кроется в «железе». Рассмотрим пример из обсуждения: база работает на SQL Server 2008 R2 с 16 Гб оперативной памяти. Для современных конфигураций на платформе 8.3.20+ это критически низкие показатели.
Проанализируем необходимые изменения:
TempDB на максимально быстрых дисках (NVMe SSD) и разделим их на несколько файлов по количеству ядер процессора.Прежде чем менять код, разберем возможности конфигурации УТ 11.5, которые позволяют ускорить закрытие месяца без риска потери данных.
Фоновый расчет себестоимости
В настройках системы (НСИ и администрирование -> Финансовый результат и контроллинг) включим фоновый расчет. Это позволит системе выполнять предварительные расчеты порциями в течение дня. Когда придет время закрывать месяц, основная часть работы уже будет выполнена.
Использование предварительного расчета
Если руководству требуется видеть прибыль «здесь и сейчас», не обязательно запускать полный фактический расчет. Рассмотрим разницу:
Проанализируем ситуацию, когда расчет «зацикливается» или пересчитывает старые периоды. В системе существует регистр сведений ЗаданияКРасчетуСебестоимости. Посмотрим на него внимательнее:
Каждое изменение документа задним числом создает запись в этом регистре. Если в базе много «хвостов» за прошлые годы, система будет пытаться пересчитать всё с момента первого изменения. Рекомендуется регулярно очищать записи по закрытым (прошлым) периодам, если пересчет в них не требуется по методическим соображениям.
Если мы хотим понять, какой именно этап занимает больше всего времени, можно воспользоваться замером производительности. Обратите внимание на функции в модуле РасчетСебестоимостиПрикладныеЗадачи. Мы можем добавить логирование времени начала и окончания каждого этапа в журнал регистрации:
// Пример добавления отладочного замера в процедуру расчета
НачалоЭтапа = ТекущаяДатаСеанса();
// ... выполнение штатного алгоритма этапа ...
КонецЭтапа = ТекущаяДатаСеанса();
ЗаписьЖурналаРегистрации("РасчетСебестоимости.Лог", УровеньЖурналаРегистрации.Информационный, , ,
"Этап распределения партий завершен за: " + (КонецЭтапа - НачалоЭтапа) + " сек.");
Такой подход позволит выявить, на чем именно спотыкается система: на расчете партий, распределении постатейных расходов или расчете НДС.
Подведем итог. Вместо опасного пути частичного расчета по фильтру номенклатуры, выполним следующие шаги:
MS SQL Server и увеличим RAM до адекватных значений (от 32-64 Гб).MAXDOP на SQL-сервере (рекомендуемое значение 1 для 1С), чтобы тяжелые запросы не вызывали ожиданий на других процессах.Помните, что архитектура 1С:УТ 11.5 построена на целостности финансового результата. Любое «ручное» вмешательство в выборку данных для расчета неизбежно приведет к ошибкам, которые могут быть обнаружены только спустя несколько месяцев при сдаче отчетности.