Manufacturing workflow Improvements

[Saurabh Dixit]

Hello All,

While working on the Manufacturing workflow, I found a gap in the creation
of requirements using createATPRequirementsForOrder service.

Failing Scenario:

Consider a fresh setup up with a product of type FINISHED_GOOD with a BOM
(say product whose inventory is always 0 or less than 0) whose attributes
are as follows,

ordered = 4 (with a check of cancelQty = null)
minimumStock = 0
atp = 0
previousRequirements = 0

So, the shortfall will be calculated as,

shortfall = minimumStock - atp - previousRequirements = 0 (results in a
zero)

then, the min(ordered, shortfall) is calculated which evaluates to be,

required = min(ordered, shortfall) = min(4,0) = 0

This required is then compared with value ZERO, and the maximum between the
both decides the further flow. If the required is found max then, the
createRequirement is called and the requirement is created, if not, then
the requirement for that order item is skipped and the loop continues with
the next order item.

In this case, it evaluates as,
max(0, 0) <= 0 which evaluated to true, and the loop continues to execute
for other items (if any) instead of creating the requirement for the
ordered quantity.

If we now see the Sales Order and the quantity for which the requirement
was meant to be created (but had not),
Qty (Sales Order asks for) = 4
Qty (Requirement is created) = 0,

This definitely represents the flaw in the process, which is to choose the
max(ordered, shortfall) instead of min(ordered, shortfall) based on some
condition that distinguishes the scenarios, so that this case is also
considered with the previous workflow.

Please put forth your valuable feedbacks.

Thanks and regards

Saurabh Dixit
Enterprise Software Engineer
HotWax Systems

[Suraj Khurana]

Thanks Saurabh,

One thing I would like to add here is createATPRequirementsForOrder service
runs before reservation logic.
IMO, we should change that seca rule event to 'global-commit-post-run'
instead of 'commit'.

In this way, requirement generation flow will run after reservation logic
and shortfall calculation will become more accurate.
Also, I see no reason to calculate minimum from shortfall and ordered
quantity. I guess we should create requirement for shortfall quantity if
results to a positive integer.

HTH.
--
Thanks and Regards,
Suraj Khurana | Omni-channel OMS Technical Expert



On Sat, Jul 14, 2018 at 2:30 PM, Saurabh Dixit <
[hidden email]> wrote:

> Hello All,
>
> While working on the Manufacturing workflow, I found a gap in the creation
> of requirements using createATPRequirementsForOrder service.
>
> Failing Scenario:
>
> Consider a fresh setup up with a product of type FINISHED_GOOD with a BOM
> (say product whose inventory is always 0 or less than 0) whose attributes
> are as follows,
>
> ordered = 4 (with a check of cancelQty = null)
> minimumStock = 0
> atp = 0
> previousRequirements = 0
>
> So, the shortfall will be calculated as,
>
> shortfall = minimumStock - atp - previousRequirements = 0 (results in a
> zero)
>
> then, the min(ordered, shortfall) is calculated which evaluates to be,
>
> required = min(ordered, shortfall) = min(4,0) = 0
>
> This required is then compared with value ZERO, and the maximum between the
> both decides the further flow. If the required is found max then, the
> createRequirement is called and the requirement is created, if not, then
> the requirement for that order item is skipped and the loop continues with
> the next order item.
>
> In this case, it evaluates as,
> max(0, 0) <= 0 which evaluated to true, and the loop continues to execute
> for other items (if any) instead of creating the requirement for the
> ordered quantity.
>
> If we now see the Sales Order and the quantity for which the requirement
> was meant to be created (but had not),
> Qty (Sales Order asks for) = 4
> Qty (Requirement is created) = 0,
>
> This definitely represents the flaw in the process, which is to choose the
> max(ordered, shortfall) instead of min(ordered, shortfall) based on some
> condition that distinguishes the scenarios, so that this case is also
> considered with the previous workflow.
>
> Please put forth your valuable feedbacks.
>
> Thanks and regards
>
> Saurabh Dixit
> Enterprise Software Engineer
> HotWax Systems
>