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

[Vals]

Цитата:

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

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

[Sergey Petrov]

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

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

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

[S.Kuskov]

Цитата:

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

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

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