E9.2 Sales Order Maximum Order Qty

[tboat00]

Does anyone have a way to create a maximum order quantity for a given item on a sales order? We have a scenario where we may have limited supply of a product and want to limit the number of items a given customer may order so there is enough product for other customers as well.

I am aware of min and max order value options but that doesn't fit the issue. Also, product allocation scenarios also so not work for us.

 

[DaveWagoner]

FEXT tied to row exit & changed that kicks off an orchestration set to exception out when conditions are met (or work to try to set qty of that line to max if over, this might be tricky). You could store max qty per item in the Orch Cross Reference if you want to avoid tying up a user reserved field in the item branch or spinning up a new tag table

Just spitballing here!

 

[tboat00]

My current solution is to hold the maximum order values in a custom table/app with effective dates and update the row exit and changed event to provide a warning if the qty ordered is over the derived table amount. Overriding the qty ordered to the max value is a good idea if the custom table has an override flag set. I'm going down that route unless I find another way via configuration.

 

[Craig_Potter]

Hi tboat.

Here are are a few standard ways...

1. Product Allocation - this is designed to control purchases for a period (not just at a specific order level). Hierarchy controls the level
2. Next Status Preference - set up a invalid Next Status Preference rule (e.g. Next Status = "MAX" or "ERR") if the Qty is greater than x
3. Advanced Pricing - triggering a Mandatory adjustment error if Max reached. As follows....
(i) Set up an Adjustment Definition with hierarchy at Item Level (Qty Based) with a $0 Adj Detail with a From Qty greater than your desired Max
(ii) Set up a Mandatory Adjustment Definition with preference ALL Customer/ALL (value based) - with no valid Adj Details
(iii) Set up a Adjustment Definition with preference ALL Customer/ALL Item (value based) with a $0 value Adjustment Detail
Then add these three adjustments to your Schedule(s) in the sequence (i), (ii) , (iii). Set (i) to Skip to (iii) and (ii) to skip PAST (iii) or to End if adding these three Adj Definitions to the end of the Schedule.

(2) is the easiest option but does not stop the Customer Ordering multiple times (is that not an issue?).
(1) has been specifically designed to handle limited supply scenarios. It puts Orders on Hold (with warning) and lets you make a decision whether you want to let order through, cancel or talk customer down when Maximum limit reached . Why does this not suit your scenarios?

Regards,
Craig

 

[mateo31]

Hi tboat.

Here are are a few standard ways...

1. Product Allocation - this is designed to control purchases for a period (not just at a specific order level). Hierarchy controls the level
2. Next Status Preference - set up a invalid Next Status Preference rule (e.g. Next Status = "MAX" or "ERR") if the Qty is greater than x
3. Advanced Pricing - triggering a Mandatory adjustment error if Max reached. As follows....
(i) Set up an Adjustment Definition with hierarchy at Item Level (Qty Based) with a $0 Adj Detail with a From Qty greater than your desired Max
(ii) Set up a Mandatory Adjustment Definition with preference ALL Customer/ALL (value based) - with no valid Adj Details
(iii) Set up a Adjustment Definition with preference ALL Customer/ALL Item (value based) with a $0 value Adjustment Detail
Then add these three adjustments to your Schedule(s) in the sequence (i), (ii) , (iii). Set (i) to Skip to (iii) and (ii) to skip PAST (iii) or to End if adding these three Adj Definitions to the end of the Schedule.

(2) is the easiest option but does not stop the Customer Ordering multiple times (is that not an issue?).
(1) has been specifically designed to handle limited supply scenarios. It puts Orders on Hold (with warning) and lets you make a decision whether you want to let order through, cancel or talk customer down when Maximum limit reached . Why does this not suit your scenarios?

Regards,
Craig

Hi Craig, just for clarification , it seems that the business need here, is based on cumulative quantities on a period. So, the solution based on advanced pricing is "one shot" at the order line entry (same for Next status preference), isn't it? The Product allocation seems the most suitable solution as it can take in account credit order if needed (see P.O. P4210/P42101) and be used in cunjonction with hold code. The drawback of this solution is the start-up during the current period as the quantity over can not be manually setup (cf F40307). Mathieu

 

[Stank1964]

JDE does not do a great job when it comes to dishing out scarce product. It seems like it was never designed with that kind of business environment. That being said, there is an allocation add on to the base product that we have looked at. The business decided that it had it's limitations as well that would not be all that much better than doing the inventory allocation job manually. We have a person that does this. There are career professional that do allocation.

I am not sure how much good a computer will be if you have 30 customers wanting 100 units and you only have 10 of them? Could a computer (or even a person) ever really be expected to make decisions that are fair and equitable under that scenario? Maximum order quantity sounds simple but very rigid too. A wise customer could simply enter more orders for the item and get around that kind of solution.

 

[tboat00]

Circling back on this business case. Our product is fresh produce and inventory turns are quite fast on most items. We do get into a situation occasionally where based on current stock levels, we may want to limit order quantities to ensure most customers get a least a portion of the requested item ordered. The sales team requested a warning message so the options provided so far (well received) dont satisfy that aspect. However, we all know that most warning messages have no real merit in the end as most users will just click through them and move on. In this business case, we do need the item and max qty values to be date sensitive (effective and expiration). I am electing to create custom objects to accommodate the request and then check the custom tables in the row-is-exited-and changed event in SOE. Thanks all for your input.