Как реализовать сценарное моделирование и сравнение вариантов графика производства в 1С:ERP

← На главную

На любом реальном производстве диспетчеры регулярно сталкиваются с классической дилеммой: в очередь заказов внезапно «прилетает» новый срочный заказ с наивысшим приоритетом. Возникает необходимость перепланировать весь график. Однако просто запустить перерасчет в «боевой» базе опасно — это может привести к лавинообразному сдвигу сроков по десяткам других заказов, срыву обязательств перед ключевыми клиентами и хаосу в снабжении. Требуется инструмент сценарного моделирования («что будет, если...»), который позволит рассчитать альтернативный график, наглядно сравнить его с текущим и только после согласования записать изменения.

В этой статье мы подробно проанализируем ситуацию, выясним причины архитектурных ограничений типовой системы и разберем практические варианты решения этой задачи в среде 1С:ERP Управление предприятием.

В чем сложность задачи в типовой архитектуре 1С:ERP?

Для того чтобы понять, почему сравнение графиков вызывает затруднения, проанализируем структуру хранения данных планирования. В типовой архитектуре «1С:ERP» расчет графика производства — это ресурсоемкая процедура, которая сразу производит физическую запись данных в ключевые регистры системы. К ним относятся:

Регистр сведений ГрафикЭтапов_22 (или аналогичный регистр в зависимости от версии подсистемы производства);
Регистры накопления занятости видов рабочих центров (например, ЗанятостьРабочихЦентров);
Регистры распределения запасов и обеспечения материалами.

Когда диспетчер запускает расчет расписания, система перезаписывает фактические даты в документах Этап производства. Сделать «пробный» расчет без изменения этих документов в стандартном режиме невозможно: любое перепланирование затирает старый вариант графика. Таким образом, у пользователя отсутствует кнопка «Отмена» для результатов сложного расчета.

Давайте рассмотрим три основных подхода к решению этой проблемы: организационный, интеграционный и глубокую техническую доработку системы.

---

Вариант 1. Моделирование на копии базы (быстрый организационный обход)

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

Регулярно (например, раз в день или по требованию) создается резервная копия рабочей базы данных.
Планировщик заходит в копию базы, добавляет новый приоритетный заказ и запускает полное перепланирование очереди заказов.
С помощью специализированного отчета или простого сопоставления диаграмм Ганта специалист анализирует, какие заказы сдвинулись «вправо» и насколько критичны эти задержки.
Если сдвиг сроков приемлем, аналогичные действия (добавление заказа и пересчет графика) повторяются уже в «боевой» базе. Если неприемлем — расчет в копии просто выбрасывается, а в рабочей базе приоритет заказа пересматривается.

Важное ограничение: Если объем базы данных измеряется сотнями гигабайт, ежедневное создание полных копий становится технически сложной и ресурсоемкой задачей. В таких случаях системные администраторы настраивают работу через «быстрые снимки» (snapshots) на уровне СУБД или систем хранения данных, что позволяет разворачивать тестовые контуры за считанные минуты.

---

Вариант 2. Разработка расширения с использованием буферных графиков

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

В регистре сведений ГрафикЭтапов_22 присутствует служебное измерение или реквизит, отвечающий за статус графика (например, СтатусГрафика, принимающий числовые значения). Мы можем использовать свободные числовые идентификаторы для хранения альтернативных («черновых») вариантов расчета.

Разберем по шагам алгоритм создания такого инструмента:

Шаг 1. Создание внешнего интерфейса для моделирования

Создадим обработку, которая будет копировать логику стандартной обработки ПланированиеГрафика_22. В интерфейсе добавим возможность выбора сценария (например, «Основной», «Вариант 1», «Вариант 2»).

Шаг 2. Разделение записей в регистре сведений

При записи результатов расчета альтернативного графика мы не затираем основные записи со статусом 0 (актуальный график), а записываем новые строки со статусом, соответствующим нашему варианту моделирования (например, статус 7 для черновика).

Пример кода для записи расчетных данных в альтернативный статус регистра:


Процедура ЗаписатьАльтернативныйГрафик(ТаблицаЭтапов, ИдентификаторВарианта) Экспорт
    
    Для Каждого СтрокаЭтапа Из ТаблицаЭтапов Цикл
        
        НаборЗаписей = РегистрыСведений.ГрафикЭтапов_22.СоздатьНаборЗаписей();
        НаборЗаписей.Отбор.Этап.Установить(СтрокаЭтапа.Этап);
        
        // В типовом механизме отбор может строиться по распоряжению или этапу
        // Добавляем запись с альтернативным статусом
        НоваяЗапись = НаборЗаписей.Добавить();
        ЗаполнитьЗначенияСвойств(НоваяЗапись, СтрокаЭтапа);
        НоваяЗапись.СтатусГрафика = ИдентификаторВарианта; // Например, 7
        
        Попытка
            НаборЗаписей.Записать(Истина);
        Исключение
            ЗаписатьЛогОшибки(ОписаниеОшибки());
        КонецПопытки;
        
    КонецЦикла;
    
КонецПроцедуры

Шаг 3. Учет доступности оборудования (Регистры накопления)

Расчет графика невозможен без оценки занятости рабочих центров. Типовые алгоритмы проверяют занятость по регистру накопления (или сведений) доступности оборудования. Чтобы наши альтернативные расчеты не пересекались с основным графиком и друг с другом, нам необходимо реализовать механизм виртуального кэширования доступности.

Для этого в момент расчета «Варианта 1» мы:

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

Шаг 4. Визуальное сравнение вариантов

После проведения расчетов для «Основного графика» и «Варианта 1» мы можем построить отчет на базе диаграммы Ганта. Посмотрим на пример логики формирования сравнительной таблицы:


Функция ПолучитьТаблицуСравненияГрафиков(МассивЗаказов, ВариантЧерновика) Экспорт
    
    Запрос = Новый Запрос;
    Запрос.Текст = 
        "ВЫБРАТЬ
        |   ГрафикОсновной.Этап КАК Этап,
        |   ГрафикОсновной.ДатаНачала КАК ДатаНачала_Основной,
        |   ГрафикОсновной.ДатаОкончания КАК ДатаОкончания_Основной,
        |   ГрафикАльтернативный.ДатаНачала КАК ДатаНачала_Альтерн,
        |   ГрафикАльтернативный.ДатаОкончания КАК ДатаОкончания_Альтерн,
        |   РАЗНОСТЬДАТ(ГрафикОсновной.ДатаОкончания, ГрафикАльтернативный.ДатаОкончания, ДЕНЬ) КАК ОтклонениеДней
        |ИЗ
        |   РегистрСведений.ГрафикЭтапов_22 КАК ГрафикОсновной
        |       ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрСведений.ГрафикЭтапов_22 КАК ГрафикАльтернативный
        |       ПО ГрафикОсновной.Этап = ГрафикАльтернативный.Этап
        |ГДЕ
        |   ГрафикОсновной.СтатусГрафика = 0
        |   И ГрафикАльтернативный.СтатусГрафика = &ВариантЧерновика
        |   И ГрафикОсновной.Распоряжение В (&МассивЗаказов)";
        
    Запрос.УстановитьПараметр("ВариантЧерновика", ВариантЧерновика);
    Запрос.УстановитьПараметр("МассивЗаказов", МассивЗаказов);
    
    Возврат Запрос.Выполнить().Выгрузить();
    
КонецФункции

Диспетчер сразу видит в интерфейсе строки, у которых ОтклонениеДней > 0. Это и есть список этапов и заказов, которые пострадали (сдвинулись на более поздний срок) из-за внедрения нового срочного заказа. Если пользователя устраивает полученная картина, запускается процедура «применения» варианта, которая перезаписывает данные со статусом 0 значениями из статуса 7 и обновляет даты в документах этапов.

---

Вариант 3. Интеграция с внешними APS-системами

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

В этом случае оптимальным решением является интеграция с внешними специализированными системами детального планирования — APS (Advanced Planning and Scheduling). Процесс строится по следующему сценарию:

Из «1С:ERP» во внешнюю APS-систему передаются нормативно-справочная информация (ресурсные спецификации, рабочие центры), текущие остатки материалов и очередь невыполненных заказов.
Планировщик работает в интерактивном интерфейсе APS-системы (обычно это высокоскоростная in-memory диаграмма Ганта).
При поступлении срочного заказа диспетчер добавляет его на карту планирования. APS-система мгновенно (за несколько секунд) пересчитывает сотни вариантов распределения мощностей и визуально подсвечивает «покрасневшие» (просроченные) этапы других заказов.
Диспетчер может вручную перетаскивать операции на диаграмме, оптимизируя график под текущие реалии.
После утверждения финального варианта расписания, APS-система передает рассчитанные даты обратно в «1С:ERP», где они автоматически записываются в документы этапов производства.

Такой подход позволяет полностью разгрузить транзакционную систему «1С» от тяжелых расчетных операций моделирования и предоставить пользователям удобный визуальный инструмент.

---

Резюме и рекомендации

Мы проанализировали три кардинально отличающихся подхода к реализации сценарного планирования производства:

Моделирование на копии базы — отлично подходит для быстрого старта, не требует программирования, но накладывает системные ограничения при больших объемах данных.
Разработка расширения (буферные графики в 1С) — требует высокой квалификации разработчика для изоляции расчетов по доступности рабочих центров и обеспечению, однако позволяет пользователям работать в режиме «одного окна» без переключения между базами.
Интеграция с APS — профессиональное решение для крупных промышленных предприятий с дискретным типом производства, где важна скорость пересчета и глубина оптимизации графика.

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