Область применения
Универсальный механизм планирования, или УМП – это абстрактный движок, решающий задачи произвольного планирования произвольных потребностей с произвольным учетом произвольных ресурсов. УМП - это инструмент для программиста, а не для пользователя.
Что такое вообще планирование?
Википедия говорит - планирование – оптимальное распределение ресурсов для достижения поставленных целей, деятельность (совокупность процессов), связанная с постановкой целей (задач) и действий в будущем.
Разложим по полкам:
- Это процесс, или действие;
- На входе этого процесса есть цели (чего хотим достичь);
- На входе есть ресурсы, которыми мы располагаем;
- Внутри процесса цели как-то сопоставляются с ресурсами;
- На выходе дает, как минимум, два результата:
- Распределенные ресурсы, т.е. информацию о целях, которые достигаются имеющимися ресурсами;
- Цели, которых не достичь имеющимися ресурсами, или просто список дефицитных ресурсов;
- Превращает оба результата в задачи:
- По освоению/использованию имеющихся ресурсов;
- По пополнению имеющихся ресурсов, если это возможно.
Алгоритм работы УМП
- Берем из информационной базы все, что считаем потребностями;
- Берем из информационной базы все, что считаем ресурсами;
- Распределяем ресурсы по потребностям так, как сочтем нужным.
Получаем:
- Закрытые и незакрытые потребности;
- Использованные и неиспользованные ресурсы;
- Таблицу распределения ресурсов по потребностям.
Это базовый, описанный крупными мазками алгоритм. Как видите, он очень похож а определение планирования из Вики. Но это – случайное совпадение. Определение из Вики я прочитал месяц назад, а УМП существует уже более 10 лет.
Источники данных
УМП – это инструмент и его настройка основана на схемах компоновки данных (СКД).
С помощью СКД определяются потребности и ресурсы, с помощью СКД они друг с другом сопоставляются.
Для хранения СКД используется справочник «Источники данных».
Для того, чтобы описать, как формируется потребности, достаточно создать элемент справочника «Источники данных», открыть в нем редактор СКД, написать требуемый запрос и заполнить настройки компоновки (выбранные поля, параметры, отбор и т.д.)
Важно: сценарий планирования может содержать произвольное количество источников потребностей и ресурсов.
Если разработчик хочет все потребности описать одним запросом – на здоровье. Если хочет один регистр (заказы покупателей, например) выбирать тремя запросами, меняя только отбор или сортировку – УМП не против.
Главное, что следует помнить при делении источников – в их разрезе настраивается сопоставление. Это станет понятно из дальнейшего изложения.
Демонстрация ПО
Видео с встраиванием УМП в УПП, настройкой профиля и ретроспективным пересчетом, создается готовое решение, для простого случая расчета обеспеченности.
Настройки сопоставления
Когда у нас есть источники потребностей и ресурсов, нам нужно их сопоставить. Цель сопоставления – сказать движку, какие строки ресурсов подходят для данной строки потребностей.
Принципиально варианта два: простой и через СКД.
Простой вариант – это равенство некоторых полей потребности и ресурса. Например, равенство номенклатуры и характеристики. Если же при учете по характеристикам оставить только равенство номенклатур, то получится автоподбор характеристики.
Каждая настройка сопоставления хранится в отдельном элементе справочника «Источники данных». Сама по себе настройка – абстрактна, она ничего не знает об источниках потребностей и ресурсов, которые будет сравнивать.
Выбор варианта сопоставления находится в форме элемента источника данных:
Простая настройка сопоставления настраивается на закладке:
Сложная настройка сопоставления нужна для случаев, когда равенством полей не обойтись. Типичные примеры – сопоставление номенклатуры с учетом аналогов, и банальная проверка дат, когда плановая дата отгрузки должна быть больше, чем плановая дата поступления.
В схему компоновки данных, которая выполняет сопоставление, передается:
- Текущая строка потребностей;
- Данные о свободных ресурсах.
На выходе схема должна вернуть строки ресурсов, которые подходят для данной строки потребностей. Дальше движок сам подберет из этих строк нужное количество.
С передачей строки потребностей все просто – передаются значения всех ее полей в виде параметров СКД. Такой подход позволяет избежать использования наборов данных-объектов, которые неудобно соединять с обычными запросами.
Соответственно, нужно лишь написать запрос, который по значениям параметров выберет подходящие ресурсы.
Сопоставление потребностей и ресурсов выполняется многократно, для каждой строки потребностей. При этом свободные ресурсы на каждой итерации могут уменьшаться (если они отдаются под данную потребность). Значит, СКД сопоставления должна получать актуальные данные о ресурсах в ходе выполнения сопоставления.
Передать большую таблицу ресурсов в виде параметра СКД нельзя, наборы-объекты использовать неудобно, поэтому пришлось выкручиваться.
Решение – простое и вроде шуршит с приемлемой скоростью: независимый регистр сведений с коротким набором измерений и ресурсов – «Данные УМП». Запись в него ведется на каждой итерации, в которой был потреблен какой-нибудь ресурс.
Чтобы не таскать с собой сложную структуру данных с восемью Аналитиками, я сделал проще – связь через идентификаторы. Каждая строка ресурсов (впрочем, как и потребностей) при заполнении из источника данных маркируется строковым уникальным идентификатором, те же идентификаторы сохраняются в табличной части «Результаты планирования», что позволяет легко собирать отчеты по таблицам УМП. Когда попробуете, то убедитесь в этом.
Вернемся к регистру сведений «Данные УМП». Каждая итерация сопоставления оставляет в нем след – меняет количества тех ресурсов, которые были потреблены. Теперь понятно, как собрать в запросе сопоставления ресурсы: аналитики взять из документа, а остаток количества из регистра. Документ перед планированием в обязательном порядке записывается, поэтому все данные об аналитиках ресурсов в нем всегда актуальны.
Выглядит страшновато, поэтому я снабдил справочник Источники данных шаблоном настройки, который сделает типовую схему за вас:
Сам запрос не пишу здесь, он длинный из-за полного перечисления всех восьми аналитик. Но в итоге запрос из шаблона содержит готовую настройку сложного сопоставления – нужно только добавить свои условия, которые скажут УМП, какой ресурс подходит для строки потребностей.
Схема компоновки сопоставления так же должна возвращать плоскую таблицу, но колонок требуется всего три:
- «ИдентификаторРесурса» (из регистра сведений «Данные УМП»), дальше УМП сам найдет конкретную строку ресурса;
- «Количество» - количество ресурса, которое доступно к использованию;
- «ЗакрываемоеКоличество» - какое количество потребности закроется указанным количеством ресурса.
Вот это достаточно интересное место, оно позволяет делать пересчет количества. Банальный пример – пересчет количества ресурса в единицу измерения потребности, причем произвольным образом – так, как считаете нужным.
Последнее, что стоит отметить про настройку сопоставления – тип результата, который указывается в источнике данных:
Это простой справочник, который позволяет разделить способы обеспечения, чтобы потом использовать эту информацию в отчетах.
Поясню на примере.
Есть у нас потребности – заказы покупателей, ресурсы – остатки на складах, и две настройки сопоставления – простая по равенству номенклатуры и сложная, с учетом аналогов.
После выполнения сопоставления результат работы обеих настроек будет выглядеть одинаково – такая-то строка потребностей берет такую-то строку ресурсов. Как теперь понять, что подошло один к одному, а что в качестве замен? Ответ – по типу результата.
В первом случае он будет «Взять со склада», во втором – «Взять со склада, оформить замену».
Разумеется, это опциональный механизм: хотите – пользуйтесь, не хотите – оставляйте тип результата пустым, или одинаковым для всех настроек сопоставления.
Профили
Теперь все наши источники данных – потребности, ресурсы, настройки сопоставления – надо собрать в кучу, чтобы получалась общая схема, или профиль планирования. Сборка идет в справочнике «Профили УМП».
Профиль – это основной разделитель УМП, своего рода сценарий и алгоритм планирования в одном лице. Каждый профиль – это отдельный вид планирования, который живет по своим правилам и служит своим целям.
Один профиль может планировать закупки, второй – деньги, третий – работу программистов, четвертый – те же закупки, только в более пессимистичной настройке.
Профили могут быть взаимосвязанными, когда результаты одного планирования используются в другом планировании (об этом чуть ниже).
Итак, первая закладка профиля – источники потребностей:
Документ УМП
Документ УМП выполняет, собственно, планирование.
Структура основных метаданных документа:
- В шапке указывается профиль, по которому будет планироваться;
- Табличные части «Источники потребностей», «Источники ресурсов», «Настройки сопоставления» - полностью копируются из профиля;
- «Потребности» - табличная часть, в которую помещаются все потребности, вычисленные профилем. Тут мы видим, что появляется «Идентификатор потребности». Также видим, что в каждой строке потребностей сохраняется источник данных, который эту строку посчитал;
- «Ресурсы» - аналогично. В эту табличную часть помещаются все ресурсы, которые вернул профиль;
- «Результаты планирования» - табличная часть, в которую пишется результат сопоставления потребностей и ресурсов. Каждый результат планирования содержит в себе все реквизиты и строки потребностей, и строки ресурсов. Это избыточно, но очень удобно при разработке отчетов.
Видя метаданные документа, вы понимаете, что с ним легко работать. Алгоритм простой:
- Указываем профиль, он предлагает заполнить настройки – соглашаемся;
- На закладке «Потребности» нажимаем «Заполнить» - заполняется табличная часть «Потребности»;
- На закладке «Ресурсы» нажимаем «Заполнить» - заполняется табличная часть «Ресурсы»;
- Нажимаем «Выполнить планирование» на основной панели формы – УМП выполняет сопоставление и заполняет табличную часть «Результаты планирования».
Все, можно смотреть результаты. Если что-то не понравилось – смотрим/проверяем профиль, источники данных, снова заполняем документ
Так выполняется отладка профиля. Когда результат вас устроил, можно переводить профиль в автоматическое выполнение.
При выполнении планирования в табличных частях «Потребности» и «Ресурсы» меняются значения только в трех колонках – «Осталось», «Хватает» и «Еще есть». Тут все просто:
- При начале планирования «Осталось» устанавливается равным колонке «Количество»;
- Когда потребность при сопоставлении уменьшается, это отражается в колонке «Осталось»;
- Аналогично, когда ресурс используется, у него «Осталось» тоже уменьшается;
- Флаг «Хватает» взводится у потребности, которая закрылась полностью;
- Флаг «Еще есть» взводится, если ресурс использован не полностью.
Последние два флага – чисто для отладки, чтобы можно было быстро фильтровать табличные части.
Автоматическое выполнение
Настройка автоматического выполнения находится в профиле:
Просто взводим флаг и настраиваем расписание регламентного задания. Я в своей практике использовал две основные частоты – 15 минут и 1 час. Чаще необходимости не было, т.к. частота изменения данных в источниках была схожей.
Автоматическое выполнение работает просто:
- Регламентное задание запускается и ищет документ УМП с нужным профилем за текущий день;
- Если документ есть, он перезаполняется;
- Если документа нет, он создается и заполняется;
- Заполнение документа стандартное:
- В документе указывается профиль и перезаполняются настройки;
- Заполняются потребности и ресурсы по профилю;
- Выполняется планирование (как мы это делали вручную, нажимая на кнопку);
- Документ проводится текущей датой и временем.
При проведении документа УМП, в зависимости от настроек, выполняются движения по нескольким регистрам.
Движения УМП
Первый регистр – это регистр сведений «Результаты УМП». В него просто записывается табличная часть «Результаты планирования».
Движения в нем появляются, если в документе УМП стоит флаг «Фиксировать результат». Когда УМП выполняется автоматически, этот флаг взведен всегда.
Второй регистр – самый интересный и полезный, это остаточный регистр накопления «Дефициты УМП». Движения в нем появляются, если взведен флаг «Записывать дефициты в регистр» в профиле.
В этом регистре хранятся остатки и динамика изменения незакрытых потребностей.
Работает он интересно, но просто. Как вы заметили, каждый документ УМП – самодостаточный. Он содержит в себе все текущие потребности, все текущие ресурсы, и все результаты распределения ресурсов по потребностям.
Соответственно, он содержит в себе все дефициты, до единого.
Но документ не может ответить на вопрос – как изменились дефициты со вчерашнего дня, или за месяц. Для ответа на этот вопрос и служит регистр «Дефициты УМП».
При проведении УМП в регистр пишется разница между текущими дефицитами и дефицитами, которые были в прошлом документе (т.е. вчера).
Например, если проводится первый документ по профилю, то в регистр попадут все дефициты, потому что документ – первый, не с чем сравнивать.
На следующий день, если никаких изменений в потребностях и ресурсах не было, движения по регистру у второго документа будут пустыми.
Дальше, допустим, произошло только одно изменение – появился один новый заказ, с двумя позициями, одна из которых закрылась (ей хватило ресурсов), а другая – нет. В таком случае в движениях этого документа будет одна запись – приход дефицитного количества по второй позиции.
Если увеличился ресурс – например, появился новый заказ поставщику или был приход на склад – и в нем разместились дефицитные позиции – то появятся расходные движения по регистру.
В итоге:
- Если просто взять остатки регистра «Дефициты УМП», то мы всегда видим актуальные дефициты;
- Если вы возьмем обороты регистра «Дефициты УМП», то увидим динамику изменения дефицитов.
Динамика изменения дефицитов – это полный кайф, особенно если выводить ее в виде графика.
Но это еще не все. Когда у вас начнут считаться дефициты, у вас появятся правильные вопросы: а как давно эти дефициты возникли? Можно их сгруппировать по срокам возникновения, как мы это делаем с запасами и дебиторской задолженностью?
Регистр «Дефициты УМП» ответит на эти вопросы, потому что в нем реализован партионный учет. Одно из измерений регистра – «Документ дефицита». Когда дефицит возникает в первый раз, делается приход в регистр и документ дефицита становится равен тому документу УМП, который обнаружил дефицит.
Соответственно, в остатках регистра этот дефицит будет храниться в разрезе партии – документа УМП, который его нашел и плюсанул.
Когда один из последующих УМП обнаружит уменьшение этого дефицита, он сделает расходную запись именно по такой партии, которая была на остатках.
В общем, вы и так знаете, что такое партионный учет, это ровно он.
Последний регистр – «Свободные ресурсы УМП», полный аналог «Дефицитов УМП», только для ресурсов. Хранит в себе те ресурсы, которые не были полностью использованы при распределении по потребностям.
Движения в этом регистре появляются, если взведен флаг «Записывать свободные ресурсы в регистр» в профиле.
Этот регистр появился не так давно, сам я не накопил большой практики его использования. Мне он был нужен для трех целей:
- Определения ненужных заказов поставщикам – когда снабженцы заказывают что-то, не нужное никому;
- Чрезмерные заказы поставщикам, когда заказать нужно 100, а заказывают 1000, нарушая бизнес-процесс и замораживая деньги. Партионный учет в свободных ресурсах точно также позволит понять, как давно этот излишек появился. А это уже, ни много ни мало, срок возникновения замороженных денег;
- Для вычисления неликвидов – позиций на складе, которые долго лежат без движения и никому не нужны.
Последовательное выполнение профилей
Бывает такая ситуация, когда одно планирование зависит от результатов другого планирования. Причем, использоваться может все, что есть в документе УМП – результаты, незакрытые или закрытые потребности, неиспользованные или использованные ресурсы и т.д.
Для разрешения таких ситуаций служит последовательное выполнение профилей. Настраивается в профиле, который будет выполняться первым:
Работает очень просто:
- После автоматического выполнения любого профиля система смотрит, нужно ли после него выполнять еще профили;
- Если нужно – выполняет их последовательно (как будто его вызвало регл.задание);
- Если у какого-то из выполняемых профилей тоже есть последующие, то они выполнятся;
- Если встретилось зацикливание, то сработает проверка и второй раз один и тот же профиль планироваться не будет.
Как обращаться к результатам выполнения предыдущих профилей, вы уже понимаете – через СКД. Когда профиль отработал, у нас в информационной базе есть проведенный документ УМП – его можно читать запросом, его движения тоже.
Зачем может понадобиться последовательное выполнение? Когда начнете активно использовать УМП, вам это станет понятно.
Приведу простой пример из своей практики – планирование производства в разрезе заказов на производство. Чтобы запустить заказ на производство в работу, нужно знать, обеспечен он полностью или нет. Получается простая схема. Первый профиль считает обеспеченность заказа на производство материалами на складах. Потребности – это материалы заказа на производство, ресурсы – остатки на складах.
Результат – обеспеченность по каждой позиции заказа на производство. Сворачиваем ее по заказу, и получаем ответ на вопрос – обеспечен заказ на производство целиком, или нет.
Эту информацию используем во втором профиле. Там в качестве потребностей используется уже продукция заказов на производство, которые мы просто фильтруем в запросе – мы ведь знаем, какие заказы на производство обеспечены материалами, а какие нет.
Типы аналитик
Каждое поле Аналитика имеет один и тот же тип - Характеристика.ВидыАналитикУМП. Это такой план видов характеристик, типы данных которого вы можете менять в конфигураторе так, как вам угодно.
Когда я делал УМП, еще не было определяемых типов, да и не работают они в режиме совместимости (а УПП есть и будет в таком режиме).
Была мысль сразу поставить тип «Любая ссылка», но вы знаете, что это так себе решение – при добавлении или удалении любого объекта метаданных и обновлении конфигурации базы данных будет выполняться реструктуризация документов и регистров УМП, и вас это будет бесить.
Поэтому сразу ставьте в плане видов характеристик «Виды аналитик УМП» те типы, которые вам нужны, а потом всегда можете расширить.
Установка
Устанавливается УМП сравнением/объединением конфигураций. Все объекты УМП объединены в одну подсистему «УМП» - просто ставьте по ней отбор и заливайте.
Никакие объекты типовой конфигурации не затрагиваются.
УМП подходит для любой конфигурации на платформе 8.2.19.130 и старше.
Единственное – для настройки источников данных нужно будет запускать 1С в толстом клиенте, но это вроде не большая проблема. После настройки УМП будет работать на сервере, в регламентных заданиях, визуально с ним работать не нужно будет – только в отчетах.
Отчеты
В УМП никогда не было встроенных отчетов, потому что всякое планирование уникально. Заранее не известно ни количество аналитик, ни их имена, ни профили, ни даже назначение отчетов.
Поэтому мои усилия были сосредоточены на движке, который будет правильно считать, и на структурах данных, по которым другие программисты смогут быстро сделать отчет на СКД.
Но собираясь опубликовать УМП, я решил включить в него один демо-отчет, который наиболее часто требуется в реальной практике – «УМП Дефициты». Отчет рабочий, им можно пользоваться, но я рекомендую сделать свои отчеты (например, скопировав и доработав мой).
Лично я почти все отчеты по УМП делал в справочнике «Произвольные отчеты» в УПП – просто, быстро и можно на этапе разработки использовать данные информационной базы, а не только метаданные, как в конфигураторе. Использование данных крайне важно и полезно при работе с УМП – это ведь кастомизация на лету.
Отчет «УМП Дефициты» показывает незакрытые потребности во всей их аналитике. Вот пример по заказам и номенклатуре:
Если убрать заказы и оставить только номенклатуру, то получится простой плоский список того, что нужно купить:
Отчет «УМП Дефициты» - это просто остатки регистра накопления «Дефициты УМП». Блин, зеркальная тавтология, только сейчас заметил.
У качестве эксперимента я встроил в этот отчет автоматическую деуниверсализацию – избавление от неиспользуемых в профиле.
Когда у вас настроен профиль, вы заходите в отчет, указываете там свой профиль, и жмете кнопку «Все действия» - «Деуниверсализация».
Разумеется, это просто пример. Когда вы начнете работать с УМП, вы сделаете намного более качественные и понятные отчеты.
В своей практике я сделал десятки отчетов по УМП, с самым разным назначением. Наверное, сделаю отдельную публикацию про отчеты по УМП – покажу, какими они бывают, как их использовать, какие приживаются, а какие – нет.
