УМП - Универсальный механизм планирования

Обработки - Универсальные обработки

82
Лекарство от боли планирования в 1С.

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

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

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

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

  • Это процесс, или действие;
  • На входе этого процесса есть цели (чего хотим достичь);
  • На входе есть ресурсы, которыми мы располагаем;
  • Внутри процесса цели как-то сопоставляются с ресурсами;
  • На выходе дает, как минимум, два результата:
    • Распределенные ресурсы, т.е. информацию о целях, которые достигаются имеющимися ресурсами;
    • Цели, которых не достичь имеющимися ресурсами, или просто список дефицитных ресурсов;
  • Превращает оба результата в задачи:
    • По освоению/использованию имеющихся ресурсов;
    • По пополнению имеющихся ресурсов, если это возможно.

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

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

  • Цель – обеспечить все заказы покупателей. Эта цель вполне выражается остатками регистра накопления «Заказы покупателей»;
  • Ресурсы – то, чем могут быть обеспечены заказы покупателей. Очевидно, что это остатки на складах и остатки заказов поставщикам;
  • Процесс планирования простой – распределяем сначала остатки склада, затем остатки заказов поставщикам. У нас пример простой, поэтому считаем, что ресурс годится для обеспечения цели, если у них одинаковая номенклатура;
  • На выходе имеем:
    • Какие позиции заказов покупателей у нас обеспечены, причем с указанием источника обеспечения – склада или заказа поставщику;
    • Какие позиции заказов покупателей у нас не обеспечены ничем;
  • Ну и формируем задачи:
    • Собрать и отгрузить то, что на складах, проконтролировать поступления от поставщиков;
    • Заказать у поставщиков то, чего не хватает.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Настройки:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Профили

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Документ УМП

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Движения УМП

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

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

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

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

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

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

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

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

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

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

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

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

В итоге:

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

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

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

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

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

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

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

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

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

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

  • Определения ненужных заказов поставщикам – когда снабженцы заказывают что-то, не нужное никому;
  • Чрезмерные заказы поставщикам, когда заказать нужно 100, а заказывают 1000, нарушая бизнес-процесс и замораживая деньги. Партионный учет в свободных ресурсах точно также позволит понять, как давно этот излишек появился. А это уже, ни много ни мало, срок возникновения замороженных денег;
  • Для вычисления неликвидов – позиций на складе, которые долго лежат без движения и никому не нужны.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Установка

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

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

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

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

Отчеты

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

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

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

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

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

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

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

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

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

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

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

Что дальше?

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

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

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

P.S.

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

Для УМП есть отдельная ветка в репозитории 1c-intelligence – здесь.

UPDATE 19.12.2017.

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

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

Зацените хронометраж.

UPDATE 12.02.2018

Добавляю несколько кейсов, решенных с помощью УМП.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Статус буфера показывает, насколько наполнен склад фактически.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

82

Скачать файлы

Наименование Файл Версия Размер
УМП - Универсальный механизм планирования:
.cf 106,55Kb
11.12.17
28
.cf 106,55Kb 28 Скачать

См. также

Комментарии
Сортировка: Древо
1. Denium79 11 11.12.17 09:34 Сейчас в теме
Очень интересно. Не так давно сделал собственный расчет дефицита с учетом аналогов с приоритетами по датам запуска заказа. Также сделал регистр отслеживающий изменение дефицита ежедневно.
У тебя реализован универсальный расчет - это конечно сильно расширяет горизонт применяемости.
Не очень понял как с помощью твоего инструмента рассчитать дефицит, если есть несколько аналогов с разными приоритетами использования. Видимо, чтобы понять нужно попробовать. Буду ждать примеров реального использования.
4. 1c-intelligence 4759 11.12.17 15:51 Сейчас в теме
(1)
Не очень понял как с помощью твоего инструмента рассчитать дефицит, если есть несколько аналогов с разными приоритетами использования

Элементарно, см. раздел про сложное сопоставление.
Ты должен написать такой запрос, который соединит ресурсы с регистром аналогов, и отсортирует их по приоритету использования аналога.
Это фишка, которую я хотел раскрыть в следующей публикации - при использовании сложного сопоставления ресурсы можно пересортировывать так, как тебе нужно. Я так сделал когда-то планирования работы программистов в две стороны сразу - asap и alap.
Видимо, чтобы понять нужно попробовать.

да, с УМП это главное.
Светлый ум; +1 Ответить
2. genayo 11.12.17 10:07 Сейчас в теме
Пара вопросов:
1. Почему не пошли по пути ключей аналитики, вместо создания реквизитов типа Аналитика потребности 1, Аналитика потребности 2?
2. Нужно ли что-либо дорабатывать, чтобы учесть нереализованный спрос (например, неотгруженные позиции по уже закрытым заказам, по которым нет остатка на складе)?
5. 1c-intelligence 4759 11.12.17 15:57 Сейчас в теме
(2)
1. Почему не пошли по пути ключей аналитики

пошел когда-то, было такое заказное ответвление УМП - "Распределение ресурсов". Там не было аналитик, были ключи с жесткими реквизитами - номенклатура, характеристика, чего-то еще.
Отчеты писать проще, но свобода очень сильно ограничена, потому что регулировать состав ключей неудобно, где бы он ни хранился - в реквизитах ключа, в ТЧ ключа, в РС.
В общем, основное - из-за ограничения свободы.
2. Нужно ли что-либо дорабатывать, чтобы учесть нереализованный спрос (например, неотгруженные позиции по уже закрытым заказам, по которым нет остатка на складе)?

Ничего дорабатывать не нужно, нужен лишь запрос, который эти данные достанет. Это вроде несложно - это расход по регистру ЗаказыПокупателей с отбором по типу регистратора (ЗакрытиеЗаказовПокупателей).
Вы хотите это в качестве потребностей использовать? Напрашивается что-то вроде буфера по таким позициям. Задача ровно для УМП, типовые такого не умеют.
7. genayo 11.12.17 16:11 Сейчас в теме
(5) Понятно, тоесть в качестве потребности тоже может выступать любой запрос. Попробую на досуге прикрутить для маленького интернет-магазинчика на УТ 11.3 в качестве бэка.
8. 1c-intelligence 4759 11.12.17 16:20 Сейчас в теме
(7) любой запрос в качестве потребности, любой запрос в качестве ресурса, любой запрос их соединяющий.

Можно распределять товары по кассе, заказы понедельника по 13-й зарплате, приходы денег больше 100 тыс.р. на женскую часть коллектива и т.д.
3. CheBurator 3552 11.12.17 12:11 Сейчас в теме
эээ... как-то слабо понял (не спец) - планирование - это же оптимизационная задача?
есть вот куча потребнсотей, есть куча ресурсов - как распределить ресурсы на потребности для достижения максимального результата...
?
6. 1c-intelligence 4759 11.12.17 15:58 Сейчас в теме
(3)
как распределить ресурсы на потребности для достижения максимального результата...

вот тут сразу две задачи - распределить и достичь результата.
В типовых конфигурациях первая задача не решена - распределить. Куда уж до оптимального результата.
11. Goleff74 128 11.12.17 17:30 Сейчас в теме
(6)
Куда уж до оптимального результата.

Но простейшие варианты возможно тут реализовать - например, рассчитывать маржинальность заказов покупателя на основании плановой себестоимости (или с/с на складе, сумм в заказе поставщика, ценах поставщика и т.п.) и сортировать источники потребностей по этой маржинальности, добавив сроки отгрузки, политических клиентов и т.п. в условия сортировки.
Я верно идею понял?
13. 1c-intelligence 4759 11.12.17 20:09 Сейчас в теме
(11) верно. Именно с этих идей начинался УМП в далеком 2006 году - "набрать" план производства из заказов на производство, максимизируя прибыльность, сумму реализации и загрузку оборудования.
Уважаемый CheBurator, вероятнее всего, имел в виду задачу оптимизации, когда подбирается оптимальное решение с учетом всех ограничений. Такое делают симплекс-методом или генетикой.
УМП работает проще и, как мне кажется, в итоге эффективнее. Ребята, которые заморачиваются генетикой, когда не умеют еще задницу подтирать, результата не достигают.
Нисколько не умаляю достижения оптимизации, но ее место обычно на цеховом уровне, вроде оптимизации раскроя, а не составления производственной программы в условиях постоянной, ежедневной неопределенности всех видов ресурсов.
31. karimov_m 13.12.17 17:31 Сейчас в теме
(3) Суть решение задачи нахождения локального оптимума =)
https://ru.wikipedia.org/wiki/Область_допустимых_решений
9. karimov_m 11.12.17 17:05 Сейчас в теме
Неплохо. Интересный подход.
Сюда прикрутить еще механизм внешних "внеплановых" событий, которые влияют на логику и приоритеты расчетов (в виде отдельного регистра, например, и отдельный запрос к нему + сложное сопоставление).

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

Получиться автоматическая аналитическая система принятия решений и исполнения на их основе задач (предложения, закупки, резервирования, продажи, пополнение складов и тп.)
12. 1c-intelligence 4759 11.12.17 20:05 Сейчас в теме
(9)
Сюда прикрутить еще механизм внешних "внеплановых" событий

да, мы так делали. Например, регистр с приоритетами заказов, который Важный Человек мог двигать.
Единственное, что он внешний и внеплановый только для типовых объектов, а для УМП все равны. Она под конец научилась и из внешних источников данных читать.
в точках обращаемся к УМП-движку и в зависимости от фактов, делаем дела - стартуем процессы, рассылаем задачи и т.п.)

да, именно так. Мы делали через автозадачии рабочий стол (не опубликован).
10. karimov_m 11.12.17 17:11 Сейчас в теме
В целом, я например уже вижу, как с помощью этого можно автоматизировать процесс расчета Мотивации сотрудникам.
На входе номинальные цифры, планы на год (месячные), обороты продаж с накоплением в разрезе чего-угодно (филиалы, подразделения, сотрудники) + схемы расчетов (коэффициенты, пороги отношений (план/факт)) + схемы KPI.

На выходе: расчеты из фактических цифр относительно планов и логики расчетов бонусов и автоматические ведомости в бухгалтерию на выплату бонусной части )))

Easy
1c-intelligence; +1 Ответить
14. CheBurator 3552 11.12.17 23:44 Сейчас в теме
Мну мучают задачи распределения складских ресурсов (человеко-время исполнителей) на складские задачи передвижения объектов по складу...
15. 1c-intelligence 4759 12.12.17 08:01 Сейчас в теме
(14) мучают - в смысле решить не можете?
Можете поподробнее рассказать?
17. genayo 12.12.17 08:29 Сейчас в теме
(15) Например, на разгрузке стоит 10 фур, в них 200 тонн товара, за сколько с таким объемом справится 10 человек.
18. genayo 12.12.17 08:31 Сейчас в теме
(17) Кстати, правильный ответ - какого хрена все эти 10 фур приперлись в одно время :)
CheBurator; TreeDogNight; +2 Ответить
20. CheBurator 3552 12.12.17 20:34 Сейчас в теме
(17) это более-менее тривиальная задача, так как нет конкуренции за ресурсы.

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

для начала хорошо бы спланировать возможность выполнения совокупности заказов к установленным временам готовности в условиях появления новых заказов и известной емкости ресурсов на задачу обслуживания заказов...
22. genayo 12.12.17 21:13 Сейчас в теме
(20) Задачи интересные конечно, а если получится, что в результате расчетов при увеличении количества заказов на 10% надо еще один погрузчик покупать - его купят, или нормативы времени на обработку заказов уменьшат?
33. karimov_m 13.12.17 17:40 Сейчас в теме
(17) ну тут простая математика - достаточно знать (замерить тестами) за сколько выполняет одну полную операцию 1 человек над одной (максимально возможной для человека) порцией груза, а также комбинации 2-3 человека совместно за сколько могут выполнить одну полную комбинацию разгрузки. Все это сложить и варианты разделить на общее кол-во груза. и получим ответ =) Но незабываем про обеды, перекуры и передышки..
35. genayo 13.12.17 18:42 Сейчас в теме
(33) Это все в теории просто, на практике все несколько сложнее, и сильно зависит от конкретного склада. Еще раз повторю - этот инструмент не для WMS (и обсуждение не для этой темы соответственно)
16. genayo 12.12.17 08:27 Сейчас в теме
(14) А вы уже отнормировали все складские операции?
19. CheBurator 3552 12.12.17 20:29 Сейчас в теме
(16) отнормировать более-менее правильно - не проблема, статистика есть
21. genayo 12.12.17 21:10 Сейчас в теме
(19) Хорошо вам, а тут пришло 20 тонн конфет 150 наименований и 20 тонн муки в мешках по 50 кг, попробуй отнормируй, чтобы у людей зарплата более-менее одинаковой на сделке получилась...
23. CheBurator 3552 12.12.17 23:29 Сейчас в теме
(21) нормируйтесь по временным затратам.
Внятный механизм и определения стоимости и определения ресурсов - см.у Перова Д.
24. genayo 12.12.17 23:38 Сейчас в теме
(23) Не все так просто, ну да ладно, не для этой темы разговор.
32. karimov_m 13.12.17 17:35 Сейчас в теме
(24) в WMS подход немного другой - там больше комбинаторика нужна + здоровая статистика + фактические свойства склада/варианты отгрузок/единицы хранения
25. German_Tagil 6 13.12.17 09:22 Сейчас в теме
мда с ходу не осилить .....
Заинтриговало еще больше
37. 1c-intelligence 4759 13.12.17 20:56 Сейчас в теме
(25) все проще, чем кажется. Главное - начать.
26. German_Tagil 6 13.12.17 11:36 Сейчас в теме
скачал - для работы Вам требуется платформа не меньше 8.3.9
Текущая версия 8.2.19.90
Печально - а есть ли под 8.2.19.90
27. 1c-intelligence 4759 13.12.17 12:09 Сейчас в теме
(26) упс, не поставил режим совместимости, когда сохранял УМП отдельно от УПП. Исправлю.
Пока можете поправить сами - загрузить конфигурацию в пустую базу, поставить режим совместимости, сохранить в файл и пользоваться.
30. Denium79 11 13.12.17 16:35 Сейчас в теме
А можно ли сделать так, чтобы УМП кроме изменения дефицита, отслеживала ещё и изменение потребности? Если скажем потребность не статична и может меняться. Например отмена заказа покупателя или изменение норм в результате конструкторских доработок?
34. karimov_m 13.12.17 17:45 Сейчас в теме
(30) суть - внедрение внешних событий, отельный запрос к ним. И "рассмотр" этих событий как таблицу, которая "отдает" изменения в потребностях относительно базового плана (по потребности)
36. karimov_m 13.12.17 19:12 Сейчас в теме
(30) Хотя все зависит от сложности учета. Если отмена Заказа подразумевает Отмену резерва товара (управленческого), отмена движений по запланированным отгрузкам, отмена
складского резервирования. Были ли внедрены по данному заказу Наряды на отгрузку, возможно от этого тронулось перемещение между складами (пополнение под заказ), а также задачи связанные с будущей необходимостью закупки новой партии товара (в заказе).
В общем не всегда все можно просчитать глубоко вперед. Есть "предел видимости" просчета, в которых он точно будет исполнимым до конца. Но есть внешние факторы, не привязанные к ресурсам и/или количественным показателям. Необходимо их во-первых учитывать, во вторых "трансформировать" к вычислимым значениям (в цифры), чтобы система смогла строить по ним связи/сравнения.
39. Denium79 11 14.12.17 08:00 Сейчас в теме
(36) Я не использую резервирование, остатки при расчете дефицита распределяются динамически. Поэтому мне и необходимо отслеживать изменения потребностей. "Передел видимости" в данном случае - определяется открытыми заказами на производство.
38. 1c-intelligence 4759 13.12.17 21:08 Сейчас в теме
(30) да, конечно. УМП итак отслеживает именно изменение потребностей.
Дефицитные они или нет - решает разработчик.

Если хочешь именно отслеживать потребности, без учета их обеспеченности - просто скопируй профиль и убери оттуда ресурсы и сопоставление. У тебя будет профиль, который знает только ресурсы. И будет писать их в регистр, и красиво изо дня в день делать приход и расход по регистру, отражая динамику.
40. Denium79 11 14.12.17 08:07 Сейчас в теме
(38) Тогда получается мне необходимо вести две настройки УМП? Одну для отслеживания обеспеченности, другую для отслеживания изменений базовых потребностей. Именно не остатка потребностей, а прихода.

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

Это возможно? Вести отслеживание нескольких разных расчетов?
41. 1c-intelligence 4759 14.12.17 08:14 Сейчас в теме
(40)
Тогда получается мне необходимо вести две настройки УМП?

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

да.
Это возможно? Вести отслеживание нескольких разных расчетов?

да, это одна из главных особенностей УМП - многовариантность. Делаешь сколько надо профилей, каждый живет своей жизнью.
42. German_Tagil 6 28.12.17 14:47 Сейчас в теме
Впечатляет - наконец-то руки дошли
43. 1c-intelligence 4759 28.12.17 21:07 Сейчас в теме
(42) по-настоящему впечатлит, когда пользоваться начнете, особенно на реальной бизнес-задаче.
44. minimajack 49 28.12.17 21:14 Сейчас в теме
(43) применяли для расчета потребностей-обеспечения в производстве?
45. 1c-intelligence 4759 28.12.17 21:19 Сейчас в теме
46. minimajack 49 28.12.17 21:29 Сейчас в теме
(45) разузлование спецификаций тоже в запросе делали?
47. 1c-intelligence 4759 28.12.17 21:33 Сейчас в теме
(46) нет. Делал два варианта.
Первый - УМП позволяет после выполнения запроса выполнять произвольный код. Я делал разузлование типовыми средствами, в документ попадало уже разузлованное.
Но это хреновый способ, т.к. требует много времени.

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

К такой структуре легко и удобно обращаться запросом. Эту штуку тоже хотел опубликовать, но отдельно, т.к. она только для УПП и КА 1.
48. genayo 28.12.17 21:49 Сейчас в теме
(47) Плох тот программст 1С, который не делал разузлование запросом :). Решение с регистром видел в УПП на предыдущей работе, может, и вашими идеями было вдохновлено.
49. 1c-intelligence 4759 28.12.17 21:52 Сейчас в теме
(48) возможно и нашими - первый вариант кеширования даже в ПМК 1С:Машиностроение вошел. См слайдик. Я эту какашку делал.
50. 1c-intelligence 4759 28.12.17 21:57 Сейчас в теме
(48) а если мотнете на слайды 37-38, то увидите первый вариант УМП :)
Эх, ностальгия накатила. 11 лет прошло.
51. minimajack 49 28.12.17 22:09 Сейчас в теме
(47) нет доверия к перерасчету
таким образом можно и сервер положить
52. genayo 28.12.17 22:12 Сейчас в теме
(51) Именно поэтому перешли на запросы, что в общем стало возможно благодаря тому, что максимальная глубина была известна и не превышала 7...
54. minimajack 49 28.12.17 22:19 Сейчас в теме
(52) для использования запросов, есть много ограничений (
(53) достаточно поменять несколько раз основную спецификацию - и я не уверен в корректном результате )
53. 1c-intelligence 4759 28.12.17 22:18 Сейчас в теме
(51) нет, если нормально отрегулировать расписание и очередь пересчета.
НСИ меняется не так часто. Проблема возникает только в том случае, если кто-то перезаписывает всю номенклатуру групповой обработкой. Но это не проблема нагрузки, а проблема длинной очереди. Если очередь обрабатывается не вся сразу, а, например, по 5 позиций, то сервер не ляжет.
55. minimajack 49 28.12.17 22:23 Сейчас в теме
(53) так и не понял - а причем справочник номенклатура к разузлованию ....
что можно поменять в номенклатуре, что бы пересчитывать разузловку?
56. 1c-intelligence 4759 28.12.17 22:51 Сейчас в теме
(55) учет по доп.характеристикам, вид воспроизводства, вид номенклатуры.
Но вообще это вроде не важно. Подписаться можно на то, что нравится.
57. German_Tagil 6 07.02.18 11:46 Сейчас в теме
приступил к освоению
потребности, ресурсы заполнил
а вот настройкой сопоставления - встрял
если шаблон указываешь и жмешь выполнить
Справочник.ИсточникиДанныхУМП.Форма.ФормаЭлемента.Форма(73)}: Ошибка при вызове метода контекста (Вывести)
ПроцессорВывода.Вывести(ПроцессорКомпоновки, Истина);
по причине:
Ошибка вывода результата
по причине:
Ошибка при выводе результата
по причине:
Ошибка получения данных
по причине:
Ошибка создания набора данных "НаборДанных1"
по причине:
Ошибка при исполнении запроса набора данных
по причине:
{(8, 35)}: Не задано значение параметра "ДокументПланирования"
ДанныеУМП.ДокументПланирования = <<?>>&ДокументПланирования
а его вроде как и должно быть
58. 1c-intelligence 4759 07.02.18 21:19 Сейчас в теме
(57) настройку сопоставления выполнять смысла нет - ей нужны на вход данные, которые есть только в момент планирования. Указывайте настройку в профиле и пробуйте запустить планирование.

В частности, параметр ДокументПланирования заполняется при выполнении планирования.
59. German_Tagil 6 08.02.18 14:33 Сейчас в теме
угу вроде что-то начинает получаться - цифирки только не идут
выборку делал по оборотам
по остаткам не информативно
60. 1c-intelligence 4759 12.02.18 11:05 Сейчас в теме
Добавил в конце статьи три кейса - стандартные ситуации закупа, и как их решать с помощью УМП.
61. genayo 12.02.18 12:16 Сейчас в теме
(60) Неплохо было бы сделать демобазу с какой-нибудь из этих настроек.
62. 1c-intelligence 4759 12.02.18 12:23 Сейчас в теме
(61) да, надо.
Сделаю, когда у публикации +100 будет.
63. genayo 12.02.18 12:30 Сейчас в теме
(62) Фи, как меркантильно :)))
64. 1c-intelligence 4759 06.07.18 09:30 Сейчас в теме
Друзья, прошу прощения за спам - поучаствуйте в голосовании.
65. Confucius 75 13.08.18 09:53 Сейчас в теме
Можете подсказать можно ли настроить УМП в след ситуации (разделка и продажа мяса): Есть план на неделю какие запчасти туши получить: например вт окорок, лопатка и тд в каких то количествах. Среда тоже какие то материалы. и т/д. Материала из которого будут производить пока нет либо он в заказе поставщику едет. Но хотят уже резервировать заказами покупателя и ставить в резерв (по сути воздух). Но когда будет реальный выпуск (ОПзС) товар появится на складе и в заказах нужно будет подменить склад (с вируального на реальный). Как то так. Понятно что не все можно сделать УМП, но не могу понять нужна ли тут УМП?
66. 1c-intelligence 4759 14.08.18 06:45 Сейчас в теме
(65) всю задачу УМП не решит, т.к. не лезет в типовые документы и не делает резервирования.
Но задачу распределения между потребителями решит:
1. Покажет, какому заказу покупателя из какого заказа поставщику что достанется;
2. Когда будет ОПзС, и произойдет выпуск, раздаст тем же заказам покупателя остатки склада (только что нарезанные туши);
3. В процессе будет показывать лишние части туши, которые никем не востребованы.

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

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