Универсальный механизм планирования (бесплатная версия)

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

Что такое вообще планирование?

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

Разложим по полкам:

Посмотрим на простом примере – планировании закупок под заказы покупателей для непроизводственного предприятия.

Получается так:

Пример простой, все расчеты делаются элементарно. В УПП с такой задачей почти справится, например, «Помощник планирования».

Но в жизни все обычно сложнее. Усложнения встречаются на всех этапах процесса планирования.

Цели обычно сложнее – их нужно собрать из разных источников, и это не всегда типовые объекты. Зачастую цели даже не детерминированы, для их определения нужно проводить отдельный процесс планирования.

Заказы покупателей надо брать не все, а только оплаченные. А по клиентам класса А можно и неоплаченные взять.

Номенклатуру надо не просто купить, а произвести. Что будем производить, написано в плане производства. Из плана производства создаются заказы на производство, которые в свою очередь должны обеспечиваться материалами.

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

А тут оказывается, что в заказах покупателей не только продукция, но и материалы, или запчасти, которые и в готовую продукцию входят, и отдельно продаются. Их, значит, не надо искать в плане производства и заказах на производство, они на складе и в заказах поставщикам. Значит, заказы покупателей, которые размещаются в заказах на производство, еще и конкурируют с ними за материалы.

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

А если у нас не неснижаемый остаток, а буфер по ТОС? Тогда заказы покупателей должны размещаться в буфере, а не складываться с ним.

Где-то в середине мы еще выборочное резервирование применяем, т.е. не можем раздавать все подряд ресурсы – некоторые уже забронированы.

А еще у нас есть аналоги, но они непростые – в заказах на производство мы можем заменить материал, в заказе покупателя для клиента класса C – тоже можем, а для классов B и A – уже не можем.

Раз мы выполняем планирование с учетом такого количества данных, то этот процесс – планирование – мы должны выполнять достаточно часто, чтобы учесть постоянно происходящие изменения.

Когда мы спланировали и получили задачи, мы хотим их контролировать – знать, когда задачи поставлены, когда обновились (при перепланировании), кто ответственный за исполнение, видеть зависшие задачи и т.д.

Эх, опять увлекся. О проблемах планирования и его вариабельности уже была статья.

Все перечисленные, и не только, задачи можно решить с помощью УМП.

Алгоритм работы УМП

Алгоритм работы УМП предельно прост:

  1. Берем из информационной базы все, что считаем потребностями;
  2. Берем из информационной базы все, что считаем ресурсами;
  3. Распределяем ресурсы по потребностям так, как сочтем нужным.

На выходе имеем:

  1. Закрытые и незакрытые потребности;
  2. Использованные и неиспользованные ресурсы;
  3. Таблицу распределения ресурсов по потребностям.

Это базовый, описанный крупными мазками алгоритм. Как видите, он очень похож а определение планирования из Вики. Но это – случайное совпадение. Определение из Вики я прочитал месяц назад, а УМП существует уже более 10 лет.

Источники данных

УМП – это инструмент из кастомизации на лету, поэтому его настройка основана на схемах компоновки данных (СКД).

С помощью СКД определяются потребности и ресурсы, с помощью СКД они друг с другом сопоставляются.

Для хранения СКД используется справочник «Источники данных».

Для того, чтобы описать, как формируется потребности, достаточно создать элемент справочника «Источники данных», открыть в нем редактор СКД, написать требуемый запрос и заполнить настройки компоновки (выбранные поля, параметры, отбор и т.д.)

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

Если разработчик хочет все потребности описать одним запросом – на здоровье. Если хочет один регистр (заказы покупателей, например) выбирать тремя запросами, меняя только отбор или сортировку – УМП не против.

Главное, что следует помнить при делении источников – в их разрезе настраивается сопоставление. Это станет понятно из дальнейшего изложения.

Какие требования УМП предъявляет к схеме компоновки:

  1. Результат выполнения схемы должен быть плоской таблицей. Соответственно, не нужно создавать группировки и итоги. Достаточно сделать одну группировку <Детальные записи> и в выбранные поля добавить все, что вам нужно из запроса;
  2. Для потребностей УМП возьмет поля:
    • ДатаПотребности;
    • Количество;
    • АналитикаПотребности1, АналитикаПотребности2, …, АналитикаПотребности8;
  3. Для ресурсов УМП возьмет:
    • ДатаДоступности;
    • Количество;
    • АналитикаРесурса1, АналитикаРесурса2, …, АналитикаРесурса8;

Нет смысла использовать наборы данных-объекты – УМП в них ничего не передаст. Только наборы данных-запросы. Все остальное, что есть полезного в СКД – на здоровье. Функции общих модулей, вычисляемые поля, выражения в параметрах и т.д. – все может помочь в определении потребностей и ресурсов.

В форме элемента источника данных есть кнопка выполнения схемы – можно сразу пробовать и отлаживать схему.

Вот пример запроса, который выберет потребности – незакрытые заказы покупателей:

image

Вот настройки схемы компоновки:

image

Пример запроса, который достает ресурсы – остатки на складах:

image

Настройки:

image

Отдельно отмечу сортировку. В каком порядке запрос выдаст потребности, в таком порядке они и будут обеспечиваться. То же касается и ресурсов.

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

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

Или вообще отсортировать потребности по общей дебиторской задолженности покупателей – сначала обеспечивать тех, кто имеет меньше долгов перед вами.

Или использовать данные о просроченной дебиторской задолженности для сортировки потребностей.

Или обеспечивать сначала те заказы, где содержатся ваши неликвиды.

В общем, простор для фантазии вашей и ваших клиентов – открыт.

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

Например, классы контрагентов (ABC) можно использовать для сортировки внутри одного источника, а можно разбить потребности на три источника в соответствии с классами и внутри сделать еще какую-нибудь сортировку, причем разную для разных классов.

Тут кому как удобнее, у каждого вырабатывается свой стиль работы с УМП.

Настройки сопоставления

Когда у нас есть источники потребностей и ресурсов, нам нужно их сопоставить. Цель сопоставления – сказать движку, какие строки ресурсов подходят для данной строки потребностей.

Принципиально варианта два: простой и через СКД.

Простой вариант – это равенство некоторых полей потребности и ресурса. Например, равенство номенклатуры и характеристики. Если же при учете по характеристикам оставить только равенство номенклатур, то получится автоподбор характеристики.

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

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

image

Простая настройка сопоставления настраивается на закладке:

image

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

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

  1. Текущая строка потребностей;
  2. Данные о свободных ресурсах.

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

С передачей строки потребностей все просто – передаются значения всех ее полей в виде параметров СКД. Такой подход позволяет избежать использования наборов данных-объектов, которые неудобно соединять с обычными запросами.

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

Сопоставление потребностей и ресурсов выполняется многократно, для каждой строки потребностей. При этом свободные ресурсы на каждой итерации могут уменьшаться (если они отдаются под данную потребность). Значит, СКД сопоставления должна получать актуальные данные о ресурсах в ходе выполнения сопоставления.

Передать большую таблицу ресурсов в виде параметра СКД нельзя, наборы-объекты использовать неудобно, поэтому пришлось выкручиваться.

Решение – простое и вроде шуршит с приемлемой скоростью: независимый регистр сведений с коротким набором измерений и ресурсов – «Данные УМП». Запись в него ведется на каждой итерации, в которой был потреблен какой-нибудь ресурс.

Чтобы не таскать с собой сложную структуру данных с восемью Аналитиками, я сделал проще – связь через идентификаторы. Каждая строка ресурсов (впрочем, как и потребностей) при заполнении из источника данных маркируется строковым уникальным идентификатором, те же идентификаторы сохраняются в табличной части «Результаты планирования», что позволяет легко собирать отчеты по таблицам УМП. Когда попробуете, то убедитесь в этом.

Вернемся к регистру сведений «Данные УМП». Каждая итерация сопоставления оставляет в нем след – меняет количества тех ресурсов, которые были потреблены. Теперь понятно, как собрать в запросе сопоставления ресурсы: аналитики взять из документа, а остаток количества из регистра. Документ перед планированием в обязательном порядке записывается, поэтому все данные об аналитиках ресурсов в нем всегда актуальны.

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

image

Сам запрос не пишу здесь, он длинный из-за полного перечисления всех восьми аналитик. Но в итоге запрос из шаблона содержит готовую настройку сложного сопоставления – нужно только добавить свои условия, которые скажут УМП, какой ресурс подходит для строки потребностей.

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

  1. «ИдентификаторРесурса» (из регистра сведений «Данные УМП»), дальше УМП сам найдет конкретную строку ресурса;
  2. «Количество» - количество ресурса, которое доступно к использованию;
  3. «ЗакрываемоеКоличество» - какое количество потребности закроется указанным количеством ресурса.

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

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

image

Это простой справочник, который позволяет разделить способы обеспечения, чтобы потом использовать эту информацию в отчетах.

Поясню на примере.

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

После выполнения сопоставления результат работы обеих настроек будет выглядеть одинаково – такая-то строка потребностей берет такую-то строку ресурсов. Как теперь понять, что подошло один к одному, а что в качестве замен? Ответ – по типу результата.

В первом случае он будет «Взять со склада», во втором – «Взять со склада, оформить замену».

Разумеется, это опциональный механизм: хотите – пользуйтесь, не хотите – оставляйте тип результата пустым, или одинаковым для всех настроек сопоставления.

Профили

Теперь все наши источники данных – потребности, ресурсы, настройки сопоставления – надо собрать в кучу, чтобы получалась общая схема, или профиль планирования. Сборка идет в справочнике «Профили УМП».

Профиль – это основной разделитель УМП, своего рода сценарий и алгоритм планирования в одном лице. Каждый профиль – это отдельный вид планирования, который живет по своим правилам и служит своим целям.

Один профиль может планировать закупки, второй – деньги, третий – работу программистов, четвертый – те же закупки, только в более пессимистичной настройке.

Профили могут быть взаимосвязанными, когда результаты одного планирования используются в другом планировании (об этом чуть ниже).

Итак, первая закладка профиля – источники потребностей:

image

Здесь перечисляются все источники данных, которые будут формировать потребности для данного профиля.

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

Вторая закладка – аналогичная, только про ресурсы:

image

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

На третьей закладке настраивается сопоставление потребностей и ресурсов:

image

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

Порядок строк работает точно также.

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

Обратите внимание: количество строк в настройке сопоставления равно количеству строк в источниках потребностей, умноженному на количество строк в источниках ресурсов.

Например, у нас два источника потребностей – заказы покупателей и внутренние заказы, и два источника ресурсов – склады и заказы поставщикам. Настройка сопоставления будет выглядеть так:

image

Буквально это означает:

  1. Сначала заказы покупателей берут все, что им надо, на складах;
  2. Потом заказы покупателей заберут все, чего не хватило на складах, в заказах поставщикам;
  3. Потом внутренние заказы пойдут на склад и пороются в остатках, которые не забрали заказы покупателей;
  4. Ну и, наконец, внутренние заказы попробуют что-нибудь найти в заказах поставщикам.

На следующей закладке указываются синонимы и настраивается видимость аналитик:

image

Назначение этой настройки – чисто интерфейсное, чтобы было удобнее отлаживать профиль. Синонимы и видимость работают только в документе «УМП».

Теперь остановимся и посмотрим на документ «УМП». Позже рассмотрим остальные настройки профиля.

Документ УМП

Документ УМП выполняет, собственно, планирование.

Структура основных метаданных документа:

  1. В шапке указывается профиль, по которому будет планироваться;
  2. Табличные части «Источники потребностей», «Источники ресурсов», «Настройки сопоставления» - полностью копируются из профиля;
  3. «Потребности» - табличная часть, в которую помещаются все потребности, вычисленные профилем. Тут мы видим, что появляется «Идентификатор потребности». Также видим, что в каждой строке потребностей сохраняется источник данных, который эту строку посчитал;
  4. «Ресурсы» - аналогично. В эту табличную часть помещаются все ресурсы, которые вернул профиль;
  5. «Результаты планирования» - табличная часть, в которую пишется результат сопоставления потребностей и ресурсов. Каждый результат планирования содержит в себе все реквизиты и строки потребностей, и строки ресурсов. Это избыточно, но очень удобно при разработке отчетов.

Видя метаданные документа, вы понимаете, что с ним легко работать. Алгоритм простой:

  1. Указываем профиль, он предлагает заполнить настройки – соглашаемся;
  2. На закладке «Потребности» нажимаем «Заполнить» - заполняется табличная часть «Потребности»;
  3. На закладке «Ресурсы» нажимаем «Заполнить» - заполняется табличная часть «Ресурсы»;
  4. Нажимаем «Выполнить планирование» на основной панели формы – УМП выполняет сопоставление и заполняет табличную часть «Результаты планирования».

Все, можно смотреть результаты. Если что-то не понравилось – смотрим/проверяем профиль, источники данных, снова заполняем документ

Так выполняется отладка профиля. Когда результат вас устроил, можно переводить профиль в автоматическое выполнение.

При выполнении планирования в табличных частях «Потребности» и «Ресурсы» меняются значения только в трех колонках – «Осталось», «Хватает» и «Еще есть». Тут все просто:

  1. При начале планирования «Осталось» устанавливается равным колонке «Количество»;
  2. Когда потребность при сопоставлении уменьшается, это отражается в колонке «Осталось»;
  3. Аналогично, когда ресурс используется, у него «Осталось» тоже уменьшается;
  4. Флаг «Хватает» взводится у потребности, которая закрылась полностью;
  5. Флаг «Еще есть» взводится, если ресурс использован не полностью.

Последние два флага – чисто для отладки, чтобы можно было быстро фильтровать табличные части.

Автоматическое выполнение

Настройка автоматического выполнения находится в профиле:

image

Просто взводим флаг и настраиваем расписание регламентного задания. Я в своей практике использовал две основные частоты – 15 минут и 1 час. Чаще необходимости не было, т.к. частота изменения данных в источниках была схожей.

Автоматическое выполнение работает просто:

  1. Регламентное задание запускается и ищет документ УМП с нужным профилем за текущий день;
  2. Если документ есть, он перезаполняется;
  3. Если документа нет, он создается и заполняется;
  4. Заполнение документа стандартное:
    • В документе указывается профиль и перезаполняются настройки;
    • Заполняются потребности и ресурсы по профилю;
    • Выполняется планирование (как мы это делали вручную, нажимая на кнопку);
  5. Документ проводится текущей датой и временем.

При проведении документа УМП, в зависимости от настроек, выполняются движения по нескольким регистрам.

Движения УМП

Первый регистр – это регистр сведений «Результаты УМП». В него просто записывается табличная часть «Результаты планирования».

Движения в нем появляются, если в документе УМП стоит флаг «Фиксировать результат». Когда УМП выполняется автоматически, этот флаг взведен всегда.

Второй регистр – самый интересный и полезный, это остаточный регистр накопления «Дефициты УМП». Движения в нем появляются, если взведен флаг «Записывать дефициты в регистр» в профиле.

В этом регистре хранятся остатки и динамика изменения незакрытых потребностей.

Работает он интересно, но просто. Как вы заметили, каждый документ УМП – самодостаточный. Он содержит в себе все текущие потребности, все текущие ресурсы, и все результаты распределения ресурсов по потребностям.

Соответственно, он содержит в себе все дефициты, до единого.

Но документ не может ответить на вопрос – как изменились дефициты со вчерашнего дня, или за месяц. Для ответа на этот вопрос и служит регистр «Дефициты УМП».

При проведении УМП в регистр пишется разница между текущими дефицитами и дефицитами, которые были в прошлом документе (т.е. вчера).

Например, если проводится первый документ по профилю, то в регистр попадут все дефициты, потому что документ – первый, не с чем сравнивать.

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

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

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

В итоге:

  1. Если просто взять остатки регистра «Дефициты УМП», то мы всегда видим актуальные дефициты;
  2. Если вы возьмем обороты регистра «Дефициты УМП», то увидим динамику изменения дефицитов.

Динамика изменения дефицитов – это полный кайф, особенно если выводить ее в виде графика.

Но это еще не все. Когда у вас начнут считаться дефициты, у вас появятся правильные вопросы: а как давно эти дефициты возникли? Можно их сгруппировать по срокам возникновения, как мы это делаем с запасами и дебиторской задолженностью?

Регистр «Дефициты УМП» ответит на эти вопросы, потому что в нем реализован партионный учет. Одно из измерений регистра – «Документ дефицита». Когда дефицит возникает в первый раз, делается приход в регистр и документ дефицита становится равен тому документу УМП, который обнаружил дефицит.

Соответственно, в остатках регистра этот дефицит будет храниться в разрезе партии – документа УМП, который его нашел и плюсанул.

Когда один из последующих УМП обнаружит уменьшение этого дефицита, он сделает расходную запись именно по такой партии, которая была на остатках.

В общем, вы и так знаете, что такое партионный учет, это ровно он.

Последний регистр – «Свободные ресурсы УМП», полный аналог «Дефицитов УМП», только для ресурсов. Хранит в себе те ресурсы, которые не были полностью использованы при распределении по потребностям.

Движения в этом регистре появляются, если взведен флаг «Записывать свободные ресурсы в регистр» в профиле.

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

Последовательное выполнение профилей

Бывает такая ситуация, когда одно планирование зависит от результатов другого планирования. Причем, использоваться может все, что есть в документе УМП – результаты, незакрытые или закрытые потребности, неиспользованные или использованные ресурсы и т.д.

Для разрешения таких ситуаций служит последовательное выполнение профилей. Настраивается в профиле, который будет выполняться первым:

image

Работает очень просто:

  1. После автоматического выполнения любого профиля система смотрит, нужно ли после него выполнять еще профили;
  2. Если нужно – выполняет их последовательно (как будто его вызвало регл.задание);
  3. Если у какого-то из выполняемых профилей тоже есть последующие, то они выполнятся;
  4. Если встретилось зацикливание, то сработает проверка и второй раз один и тот же профиль планироваться не будет.

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

Зачем может понадобиться последовательное выполнение? Когда начнете активно использовать УМП, вам это станет понятно.

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

Результат – обеспеченность по каждой позиции заказа на производство. Сворачиваем ее по заказу, и получаем ответ на вопрос – обеспечен заказ на производство целиком, или нет.

Эту информацию используем во втором профиле. Там в качестве потребностей используется уже продукция заказов на производство, которые мы просто фильтруем в запросе – мы ведь знаем, какие заказы на производство обеспечены материалами, а какие нет.

Типы аналитик

Каждое поле Аналитика имеет один и тот же тип - Характеристика.ВидыАналитикУМП. Это такой план видов характеристик, типы данных которого вы можете менять в конфигураторе так, как вам угодно.

Когда я делал УМП, еще не было определяемых типов, да и не работают они в режиме совместимости (а УПП есть и будет в таком режиме).

Была мысль сразу поставить тип «Любая ссылка», но вы знаете, что это так себе решение – при добавлении или удалении любого объекта метаданных и обновлении конфигурации базы данных будет выполняться реструктуризация документов и регистров УМП, и вас это будет бесить.

Поэтому сразу ставьте в плане видов характеристик «Виды аналитик УМП» те типы, которые вам нужны, а потом всегда можете расширить.

Установка

Устанавливается УМП сравнением/объединением конфигураций. Все объекты УМП объединены в одну подсистему «УМП» - просто ставьте по ней отбор и заливайте.

Никакие объекты типовой конфигурации не затрагиваются.

УМП подходит для любой конфигурации на платформе 8.2 и старше.

Единственное – для настройки источников данных нужно будет запускать 1С в толстом клиенте, но это вроде не большая проблема. После настройки УМП будет работать на сервере, в регламентных заданиях, визуально с ним работать не нужно будет – только в отчетах.

Отчеты

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

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

Но собираясь опубликовать УМП, я решил включить в него один демо-отчет, который наиболее часто требуется в реальной практике – «УМП Дефициты». Отчет рабочий, им можно пользоваться, но я рекомендую сделать свои отчеты (например, скопировав и доработав мой).

Лично я почти все отчеты по УМП делал в справочнике «Произвольные отчеты» в УПП – просто, быстро и можно на этапе разработки использовать данные информационной базы, а не только метаданные, как в конфигураторе. Использование данных крайне важно и полезно при работе с УМП – это ведь кастомизация на лету.

Отчет «УМП Дефициты» показывает незакрытые потребности во всей их аналитике. Вот пример по заказам и номенклатуре:

image

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

image

Отчет «УМП Дефициты» - это просто остатки регистра накопления «Дефициты УМП». Блин, зеркальная тавтология, только сейчас заметил.

У качестве эксперимента я встроил в этот отчет автоматическую деуниверсализацию – избавление от неиспользуемых в профиле.

Когда у вас настроен профиль, вы заходите в отчет, указываете там свой профиль, и жмете кнопку «Все действия» - «Деуниверсализация».

Разумеется, это просто пример. Когда вы начнете работать с УМП, вы сделаете намного более качественные и понятные отчеты.

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

Что дальше?

Данная публикация – своего рода знакомство с УМП и инструкция по его применению. Я, конечно, включил в текст несколько примеров, но уверен, что до конца вы УМП и его преимущества не прочувствовали. А может, и прочувствовали, ведь за 10 лет набралось несколько десятков программистов, которые использовали УМП на своих внедрениях.

Чтобы прочувствовать, нужно попробовать. Пробуйте, экспериментируйте, задавайте вопросы.

А я расскажу о своей практике работы с УМП и решенных кейсах в следующих публикациях.

P.S.

УМП, как вы поняли - это инструмент для программиста, а не для пользователя. Для программиста, который хочет осчастливить пользователя.

Еще я снял видео с встраиванием УМП в УПП, настройкой профиля и ретроспективным пересчетом.

Т.е. создается готовое решение, для простого случая расчета обеспеченности. Зацените хронометраж.

Кейсы

Простой закуп под заказы покупателей

Это самый распространенный, наверное, вариант для торговли. Есть заказы покупателей, есть склад, есть заказы поставщикам.

УМП настраивается так:

  1. Потребности – заказы покупателей;
  2. Ресурсы:
    • Остатки на складах;
    • Заказы поставщикам.

На выходе имеем дефицитную ведомость – каких позиций и в каком количестве не хватает, и нужно их закупить.

Простой закуп, с учетом графиков

Если важно учитывать плановые даты отгрузок и поставок от поставщиков, то настройка УМП немного изменится (по сравнению с предыдущим вариантом).

  1. Потребности – заказы покупателей, с выводом даты потребности. Сортировка – по возрастанию даты потребности.
  2. Ресурсы:
    • Остатки на складах;
    • Заказы поставщикам с выводом даты доступности, сортировка по возрастанию даты доступности;
  3. Сопоставление:
    • Со складом – простое, по номенклатуре;
    • С заказами поставщикам – через СКД, в отборе указать Дата потребности ≥ Даты доступности.

Лично я делал чуть сложнее – добавлял еще 1-2 этапа сопоставления заказов покупателей с заказами поставщикам, где менял условие сопоставления – например, ставил Дата доступности ≤ Дата потребности + 7 дней, или Дата доступности ≤ Дата потребности + 14 дней.

В итоге получал более понятные результаты распределения:

  1. Заказы, которые уже можно отгружать (все есть на складе);
  2. Заказы, которые отгрузятся по графику (плановые даты прихода от поставщиков меньше, чем дата отгрузки);
  3. Заказы, которые отгрузятся с опозданием в неделю;
  4. Заказы, которые отгрузятся с опозданием в 2 недели;
  5. Ну и заказы, которые вообще нет шанса отгрузить при таком подходе к снабжению.

ТОС (барабан-буфер-веревка)

Закуп по методу ББВ реализуется элементарно. Единственное, что нужно иметь вне УМП – целевые уровни, или размеры буферов по номенклатурам.

В УПП можно использовать документ «Установка значений точки заказа». Вносите номенклатуру, указываете количества, и идете настраивать УМП.

Лично я добавил отдельный документ, назвал «Установка целевых уровней», потому что хотел иметь целевые уровни по деталям, из которых состоит оборудование, зная целевой уровень на это оборудование. При этом, нужны были отдельные целевые уровни на детали. Документ разузловывал оборудование, получал детали, смешивал с отдельными целевыми уровнями на детали, получал общий размер буфера.

Настройка УМП для целевых уровней очень простая:

  1. Потребности: целевые уровни, номенклатура и количество;
  2. Ресурсы:
    • Остатки на складах, с отбором. Цеховые склады не брал, т.к. если деталь уехала в цех, то ее, считай, уже нет;
    • Заказы поставщикам, чтобы знать, что из недостающего уже заказано, а что еще нет.

В итоге имеем два показателя:

  1. Статус буфера по каждой номенклатуре – это отношение остатка на складе к целевому уровню;
  2. Статус предзаказа – это отношение остатка на складе + заказа поставщику к целевому уровню.

Статус буфера показывает, насколько наполнен склад фактически. Статус предзаказа показывает, насколько выполнена функция размещения. Статус предзаказа – главный источник задач для снабженцев.

Статус традиционно выражаются в процентах и делятся на три зоны:

  1. Красная – от 0 до 33 %;
  2. Желтая – от 33 до 66 %;
  3. Зеленая – от 66 до 100 %.

Я еще добавлял фиолетовую зону (> 100 %), чтобы видеть избыточное количество какой-то позиции.

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

ТОС с учетом заказов

Когда спрос рваный по времени и количеству, может потребоваться защитный контур. Например, может поступить заказ с достаточно коротким сроком исполнения и количеством, превышающим размер буфера. Это еще неплохой случай, т.к. его хорошо видно невооруженным взглядом.

А может поступить 10 заказов от разных покупателей, каждый по 1/3 буфера, т.е. сам по себе заказ не вызывает подозрений. Но в сумме эти 10 заказов составляют три размера буфера. Если они все по дате отгрузки попадут в 1-2 периода пополнения, то может наступить жесткий дефицит.

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

В УМП это настроил так. Взял настройку из обычного ТОС, и сделал ее двухэтапной, т.е. состоящей из двух профилей.

Первый профиль:

  1. Потребности – заказы покупателей;
  2. Ресурсы:
    • Остатки на складах;
    • Заказы поставщикам;

На выходе имеем:

  1. Неиспользуемые ресурсы (склад и заказы поставщикам);
  2. Незакрытые заказы покупателей;

Второй профиль:

  1. Потребности – целевые уровни;
  2. Ресурсы – неиспользованные ресурсы 1-го профиля.

Первый профиль как бы выполняет резервирование, получает свободные остатки склада и заказов поставщикам. Эти свободные остатки используются вторым профилем, как ресурсы.

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

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

Есть вариант попроще – в потребностях складывать целевой уровень и заказы покупателей. Но мне он не нравится, т.к. не дает черной зоны – будет только разный процент красноты, т.е. визуально одно и то же. Поэтому рекомендую использовать черную зону.