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

[Sergey Petrov]

Уважаемые коллеги! Добрый день.

Возникла задача:
При обработке потребности в рамках процедуры сводного планирования система создаёт Спланированный заказ на перемещение или на покупку с учётом кратности упаковки. При этом округление всегда идёт в бОльшую сторону. К примеру, у нас потребность в 2 шт. некоторой номенклатурной позиции, а переместить мы можем минимум 10 шт. в одной упаковке. В этом случае система (если не найдено иных способов покрытия данной потребности 2 шт.) обязательно создаёт Спланированный заказ на перемещение минимум из 1 упаковки, в которой 10 шт. Дальнейшие потребности сопоставляются с созданным Спланированным заказом на перемещение по-порядку. Если больше потребностей нет, то несопоставленный остаток (минимум 8 шт. в нашем примере) останется мёртвым грузом на складе.
Суть задачи: Возникла идея отказываться от создания Спланированного заказа на перемещение или на покупку, если потребность не превосходит некоторый процент от упаковки. Тем самым мы, возможно, будем иметь некоторую ничем не покрытую потребность, но избежим затоваривания склада.
Например, если мы устанавливаем этот процент в размере 40%, то Спланированный заказ на перемещение может быть создан только если потребность составит 4 шт. и более при кратности упаковки при перемещении 10 шт.
Таким образом, при обработке потребностей в сводном планировании мы пропустим эту потребность 2 шт., и только при обработке следующей потребности на следующую дату (предположим, что она составляет 3 шт.) создадим Спланированный заказ на перемещение (на 10 шт., то есть упаковку). Этот Спланированный заказ также будет датирован следующей датой.
А вот теперь начинается самое интересное. Система автоматически сопоставит вторую потребность 3 шт. и созданный Спланированный заказ. Первая же потребность останется ни с чем не сопоставленной.
ВОПРОС. Если мы заставим систему сопоставить первую потребность (2 шт.) с созданным ПОСЛЕ ЕЁ ДАТЫ Спланированным заказом, как это будет выглядеть с точки зрения принципов сводного планирования и может ли такое сопоставление иметь какие-то последствия для системы в целом?

[S.Kuskov]

Может будет проще сдвигать вперёд дату потребности, так сказать группировать потребности согласно настроек кратности?

[Vals]

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

[Sergey Petrov]

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

Прошу поправить, если мои представления не верны. Буду очень признателен.

Итак, насколько я понимаю, суть алгоритма покрытия потребности состоит в следующем: система определяет текущую потребность и пытается сопоставить её с покрытием, производя для этого поиск существующего на данный момент источника покрытия как вперёд по датам (отрицательные дни, т.е. количество дней в будущем, где могут быть найдены ресурсы для покрытия данной потребности), так и назад (положительные дни, т.е. количество дней в прошлом, где могут быть найдены ресурсы для покрытия данной потребности). Нашла - всё здорово.
Не нашла - начинаем создавать покрытие для данной потребности. Его количество включает в себя: а) обязательно величину самой потребности (непокрытая текущая потребность) и б) потребности (непокрытые) за предстоящий период (период покрытия).
После этого в стандартной реализации система округляет вычисленное количество с учётом кратности упаковок. При этом, округление всегда ведётся в бОльшую сторону, то есть мы никогда не получаем ситуации, когда какая-то потребность останется непокрытой (не сопоставленной с соответствующим покрытием).

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

Вопросы в следующем:
1. Можно ли реализовать сопоставление Спланированных заказов из будущего с потребностями из прошлого? В оригинальной системе этого нет. И к чему это может привести?
2. Что будет, если мы какую-то часть потребностей оставим вообще без покрытия (такие потребности будут в самом конце, когда новый Спланированный заказ уже система не создаст)?

[Vals]

Цитата:

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

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

В Вашем случае - вы сознательно допускаете отсрочку отгрузки 2 шт из палеты 10 шт до тех пор, пока не наберётся потребностей до 10шт. Несколько по-другому, но вы можете объяснить, что система может ждать 5 дней по этой группе товаров (отрицательные дни) чтобы собрать больше потребностей и она вам предложит действие по ускорению или отсрочке переноса, отгрузки, заказа (фьючерс). Оператор легко отлавливает эти строчки и решает, что с ними делать.

http://www.amand.ru/modules/wordpress/archives/131

Цитата:

Вопросы в следующем:
1. Можно ли реализовать сопоставление Спланированных заказов из будущего с потребностями из прошлого? В оригинальной системе этого нет. И к чему это может привести?

В системе есть. Непокрытая потребность у вас будет видна при каждом перепланировании. Ещё вам поможет параметр резервирования Назад от даты (там две галки - ими поиграться)

Цитата:

2. Что будет, если мы какую-то часть потребностей оставим вообще без покрытия (такие потребности будут в самом конце, когда новый Спланированный заказ уже система не создаст)?

Обработаете ручками, но это не лучший вариант.

[Sergey Petrov]

Цитата:

Сообщение от Vals

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

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

Цитата:

Сообщение от Vals

В Вашем случае - вы сознательно допускаете отсрочку отгрузки 2 шт из палеты 10 шт до тех пор, пока не наберётся потребностей до 10шт. Несколько по-другому, но вы можете объяснить, что система может ждать 5 дней по этой группе товаров (отрицательные дни) чтобы собрать больше потребностей и она вам предложит действие по ускорению или отсрочке переноса, отгрузки, заказа (фьючерс). Оператор легко отлавливает эти строчки и решает, что с ними делать.

Другими словами, если мы указываем количество "Отрицательных дней" равным 5, то система ДОПУСКАЕТ покрытие текущей потребности каким-то УЖЕ СУЩЕСТВУЮЩИМ приходом, который будет выполнен в ближайшем будущем. С точки зрения данных понятие "допускает покрытие" означает, что данный расход (потребность, её количество) может быть сопоставлен с некоторым заранее известным приходом, который ожидается в ближайшие 5 дней.
НО если этого прихода в течение ближайших 5 дней попросту ещё нет, то система создаёт этот приход. Правильно? И приход этот (в оригинальной версии) гарантированно больше или равен этой самой потребности (расхода). То есть, сопоставление данной потребности с созданным при её обработке покрытием будет 100%. Так?
В соответствии с положением склада, куда будет осуществляться этот приход, в цепочке покрытия, он - либо закупка, либо перенос с вышестоящего склада. На вышестоящем складе, в свою очередь, данный искуственно созданный перенос будет потребностью, которая так же в свою очередь будет обрабатываться и т.д. В конечном счёте мы имеем для каждой конкретной потребности по продаже связанную с ней цепочку Спланированных перемещений, которая заканчивается Спланированным заказом.

Теперь предлагаю рассмотреть ту модификацию, которую мы хотим реализовать. Предположим, что в тот момент, когда система, не обнаружив никаких источников для покрытия потребности, создаёт Спланированный заказ на количество, меньшее, чем в данной обрабатываемой потребности (или вообще его не создаёт). Это означает, что какое-то звено из цепочки "Заказ - Закупка" выпадет (либо эта цепочка вообще не создаётся, если наше округление вообще не дало покрыть потребность (Заказ)).
Какие проблемы мы можем приобрести при такой ломаной схеме сводного планирования?

Цитата:

Сообщение от Vals

В системе есть. Непокрытая потребность у вас будет видна при каждом перепланировании. Ещё вам поможет параметр резервирования Назад от даты (там две галки - ими поиграться)
Обработаете ручками, но это не лучший вариант.

Если можно, пожалуйста, расскажите поподробнее о "перепланировании" и о параметре "Назад от даты".

P.S. Спасибо за ссылку!

[S.Kuskov]

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

[Vals]

Цитата:

Если можно, пожалуйста, расскажите поподробнее о "перепланировании" и о параметре "Назад от даты".

Есть описание в рководстве по логистике к 2009-й аксапте (забавно, сколько лет прошло после динамикса, а всё ещё аксапта) в главе про резервирование. Более точно скажу позже.

[Vals]

Цитата:

Какие проблемы мы можем приобрести при такой ломаной схеме сводного планирования?

Я бы сделал так:
- Настроить Действия
- Выбрать действия касающиеся вашего случая (фильтры)
- Оператор группирует строки спланированных заказов как считает нужным.

И скорее, пилил бы механизм действий на "отменить". То есть, в вашем случае по спланированному заказу, не достигшему параметров оптимального заказа, генерится действие Отменить. И оператор принимает решение: утвердить или нет.
Так хотя бы, потребность не пропадёт и будет видна.

[EVGL]

Цитата:

Сообщение от Sergey Petrov

Какие проблемы мы можем приобрести при такой ломаной схеме сводного планирования?

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

Мне нравится идея S.Kuskovа о страховом запасе.

[Sergey Petrov]

Цитата:

Сообщение от EVGL

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

Вот с последствиями такого перепрограммирования мы и столкнулись в результате своих копаний. За счёт округления в меньшую сторону при создании покрывающих ресурсов мы получили "кусочное" отсутствие покрытия, причём нигде не учитываемое. Всё это нам показалось крайне некрасивым. Отсюда и возникла эта ветка форума.
Лично мне (с технической точки зрения) больше всего понравилась идея Vals. Округление в меньшую сторону (по упаковкам) будет по-прежнему работать, но на недостающую упаковочку (которую мы срезали из-за округления в меньшую сторону) мы всё же будем создавать ещё один приход, сопровождая его действием "отменить" (увы, без допила кода сводника не обойтись...).
Таким образом, мы всё-таки будем соблюдать приличия в смысле покрытия потребностей, но и дадим возможность оператору отделить то, что точно нужно, от того, что, возможно, будет излишним.

[Vals]

Цитата:

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

Лучше сделать новый тип действия, типа "округление до полного".

[Sergey Petrov]

К сожалению, с действиями тоже не очень получается.
Дело в том, что действия создаются для имеющихся операций уже после создания полного набора этих операций, покрывающих потребности. То есть:
1. сначала мы должны обработать ВСЕ потребности, создав для их покрытия Спланированные заказы на округлённые в бОльшую сторону количества (как это делает система по стандартной схеме);
2. а уже потом с помощью создания действий подсказывать операторам, что нужно сделать, чтобы схема удовлетворения потребностей была более оптимальна.
Если я не прав, то прошу меня поправить.

Далее, если мы хотим, чтобы система для какого-то из Спланированных заказов нам подсказала, что нужно планировать приход в МЕНЬШЕМ количестве (из-за округления по упаковкам), то это изменение может привести к тому, что все последующие спланированные приходы (они были созданы ранее с учётом того, что наш уменьшаемый спланированный приход имеет определённое не уменьшенное количество!) либо сдвинутся по датам, либо изменятся по количеству, либо и то и другое. Своего рода, эффект карточного домика, когда одна потревоженная карта вызывает обрушение всей конструкции.

Таким образом, остаётся одна возможность решить поставленную задачу. Нужно в момент создания Спланированного заказа уменьшать его количество. Тогда при обработке последующих потребностей система будет пользоваться уже фактически уменьшенным покрытием и сможет его корректно учесть.
Один неприятный нюанс - а что, если при таком уменьшении сама текущая потребность не будет полностью покрыта создаваемым Спланированным заказом? В этом случае придётся накапливать такие непокрытые потребности и прибавлять их к следующим обрабатываемым потребностям. Как только система создаст Спланированный заказ, эти несопоставленые потребности должны быть с ним сопоставлены в первую очередь.
Похоже на то, как система сопоставляет потребность с неким покрытием в будущем. Вся разница в том, что при обычном сопоставлении это покрытие уже существует в момент обработки потребности, а здесь мы будем сопоставлять потребность с покрытием, которого при первичной обработке потребности ещё не было.
Соответственно, данное покрытие (относительно нашей несопоставленной ранее потребности оно в будущем!) должно удовлетворять критерию "отрицательных дней". То есть, настройки системы должны позволять такое сопоставление потребности и её покрытия.
Остаётся последний вопрос: а что делать, если Спланированный заказ не укладывается в рамки "отрицательных дней"? Думаю, что придётся ограничиться просто выводом инфо-лога и всё равно сопоставлять с ним нашу обделённую несопоставленную потребность.

[S.Kuskov]

Цитата:

Сообщение от Sergey Petrov

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

На самом деле это очень интересный момент. Вы хотите не просто предоставить действие на выбор: привозить ли лишнюю коробку сейчас или включить её в объём следующей поставки? А вы хотите замещать потребность в неполной коробке за счёт вскрытия следующей коробки, покрывающей другую потребность. Т.е. испольнитель отрабатывающий список полученных действий должен отвечать на вопрос не когда, а на вопрос за счёт кого. Тогда естественно, что выбрав решение покрыть потребность соседним заказом он оголяет потребность, которую тот покрывал, и получает следующий вопрос, а что теперь делать со вновь оголившейся потребностью и так до тех пор, пока стягивание одеяла не остановиться.
Здесь конечно нужно определиться, действительно ли вы хотите вручную анализировать полученные действия и принимать/не принимать такие решения о перебросе покрытия с одной потребности на другую, или же "стягивание одеяла" должно происходить всегда?

[Vals]

Цитата:

Остаётся последний вопрос: а что делать, если Спланированный заказ не укладывается в рамки "отрицательных дней"? Думаю, что придётся ограничиться просто выводом инфо-лога и всё равно сопоставлять с ним нашу обделённую несопоставленную потребность

Вы сами устанавливаете правила

Цитата:

Далее, если мы хотим, чтобы система для какого-то из Спланированных заказов нам подсказала, что нужно планировать приход в МЕНЬШЕМ количестве

ИМХО, дальше поток сознания пошёл То есть рассуждение вроде верные, но ненужные.
Моя идея в том состояла, что вы не настраиваете округления, только отриц. дни. А дальше доработка уже считает действия необходимые.