Order Multiple in Requisition Worksheet

NASi

Hi :
This is my scenario.
NAV 6.0 SP1 Spanish version.
I created an Item with the following planning data:
Reording Policy -> Fixed Reorder Qty.
Minimum Order Quantiy -> 300 Units
Order Multiple -> 300 Units
the rest of values are 0.

Replenishment Data:
Replenishment System : Purchase

There is not any SKU defined for the Item.

The demand for this Item is just a sales order with 1000 Units.
There are not Purchases sales, Transfers, etc...

When I run the requisition worksheet I expect that the quantity should be 1200 units (major multiple of 300 after 1000).
But the result is always 1.000

After a long time debugging I arrive at the conclusion that the Procedure LotForLot from de codeunit 9900855 Planning-Get Parameter is not running well. So I decided modify it with the modification as you see after the line //FR34.
With this modification is working fine, and the quantity issued at the requisition line is 1.200.
My question is : I will get collaterals effects?. Why this procedure is working like this? (putting a 0 to minimum, maximum, order multiple, etc...)


LotForLot(VAR SKU : Record "Stockkeeping Unit";ItemNo : Code[20];VariantCode : Code[10];LocationCode : Code[10])
GetMfgSetUp;
WITH GlobalSKU DO BEGIN
IF (ItemNo <> "Item No.") OR
(VariantCode <> "Variant Code") OR
(LocationCode <> "Location Code")
THEN BEGIN
CLEAR(GlobalSKU);
SETRANGE("Item No.",ItemNo);
SETRANGE("Variant Code",VariantCode);
SETRANGE("Location Code",LocationCode);
IF NOT FINDFIRST THEN BEGIN
GetItem(ItemNo);
"Item No." := ItemNo;
"Variant Code" := VariantCode;
"Location Code" := LocationCode;
"Vendor No." := Item."Vendor No.";
"Vendor Item No." := Item."Vendor Item No.";
"Lead Time Calculation" := Item."Lead Time Calculation";
"Reorder Point" := 0;
"Maximum Inventory" := 0;
"Reorder Quantity" := 0;
CASE Item."Reordering Policy" OF
"Reordering Policy"::" ": "Reordering Policy" := "Reordering Policy"::" ";
"Reordering Policy"::Order: "Reordering Policy" := "Reordering Policy"::Order;
"Reordering Policy"::"Lot-for-Lot": "Reordering Policy" := "Reordering Policy"::"Lot-for-Lot";
ELSE "Reordering Policy" := "Reordering Policy"::"Lot-for-Lot";
END;
IF "Reordering Policy" = "Reordering Policy"::"Lot-for-Lot" THEN
"Include Inventory" := TRUE
ELSE
"Include Inventory" := Item."Include Inventory";
"Manufacturing Policy" := Item."Manufacturing Policy";
"Minimum Order Quantity" := 0;
"Maximum Order Quantity" := 0;
"Safety Stock Quantity" := 0;
//FR34
//"Order Multiple" := 0;
"Order Multiple" := Item."Order Multiple";
//
"Safety Lead Time" := Item."Safety Lead Time";
"Flushing Method" := Item."Flushing Method";
"Replenishment System" := Item."Replenishment System";
"Reorder Cycle" := Item."Reorder Cycle";
"Lot Size" := Item."Lot Size";
"Last Direct Cost" := Item."Last Direct Cost";
END;

AdamRoue

Does the components at location setting in manufacturing have anything except blank?

Andwian

You might want to define a SKU for this item, and then set the Planning Parameter, then try to run the Planning again, and please let me know how it goes.

NASi

Hi AdamRoue:
Components at Location in Manufacturing setup is blank.

NASi

Hi Andwian :
I have created the SKU for the item and the planing parameters are the same than the item card, but the result is not ok.
The quantity proposed is 1.000 (not the 1.200 that I expect ).

rhpnt

The proposed 1.000 is OK because you don't have any safety stock defined. Therefore the system is proposing just the quantity placed in the sales order and avoiding stock on that item.
Before making any design changes do read ALL available official NAV documentation on this topic!

Andwian

rhpnt wrote:

The proposed 1.000 is OK because you don't have any safety stock defined

He suppose that the Qty. is 1200, since the Order Multiple is 300, hence 300 * 4 = 1200 > 1000
instead of 300 * 3 = 900 < 1000

NASi wrote:

I have created the SKU for the item

Have you set the Sales Order with any location which has SKU?
Do you use Variant Code?
What is the type of your SKU Card? Item? Item&Var&Loc?

AdamRoue

NASi wrote:

Hi AdamRoue:
Components at Location in Manufacturing setup is blank.

If it is blank and you are not using SKUs you have not told NAV a base location to begin planning, and therefore it struggles with any calcualtions. Put your main warehouse in here (or frankly any) and run planning again.

NASi

Hi : thanks to all for your help, but my case is not under your propositions. This is more simple.
This is an easy implementation with not Manufacturing, not SKU's, and never mind if there are variants or not.
The result of the requisition journal that I'm looking for is that I have to buy, depending on my sales orders, my purchases orders, and my basic item planning parameters: Minimun Order Quantity and Order Multiple. Thats all!
The help for the Order Multiple field says:
'In this field, you can specify a quantity to be used as an order multiple. The program will, if necessary, round the order proposal quantity upwards in accordance with the order multiple that you define for the item'.
What minds 'if necessary'?. For me, in my case, if I have to by 1000 units but the order multiple is 300, at least is necessary to by 1.200 units.
The NAV documentation of this topic says that I can't use Order Multiple for this case?.
What do you think?.

rhpnt

As I said in my previous post. As of your current setup the system will NEVER propose 1200 because you would have 200 in stock! You have to read the whole NAV requisition management functionality and consider all active fields for the current setup otherwise you'll never find a solution that would fit your requirements.

Andwian

rhpnt wrote:

As of your current setup the system will NEVER propose 1200 because you would have 200 in stock!

If you don't mind rhnpt, could you give us a light? Thanks in advance.

Andwian

Is Location Mandatory set to TRUE?

AdamRoue

NASi wrote:

Hi : thanks to all for your help, but my case is not under your propositions. This is more simple.
This is an easy implementation with not Manufacturing, not SKU's, and never mind if there are variants or not.
The result of the requisition journal that I'm looking for is that I have to buy, depending on my sales orders, my purchases orders, and my basic item planning parameters: Minimun Order Quantity and Order Multiple. Thats all!
The help for the Order Multiple field says:
'In this field, you can specify a quantity to be used as an order multiple. The program will, if necessary, round the order proposal quantity upwards in accordance with the order multiple that you define for the item'.
What minds 'if necessary'?. For me, in my case, if I have to by 1000 units but the order multiple is 300, at least is necessary to by 1.200 units.
The NAV documentation of this topic says that I can't use Order Multiple for this case?.
What do you think?.

The field is in the manufacturing setup but has NOTHING to do with manufacturing, it is the base warehouse to ensure planning knows what to do.

rhpnt

NASi wrote:

Hi :
This is my scenario.
NAV 6.0 SP1 Spanish version.
I created an Item with the following planning data:
Reording Policy -> Fixed Reorder Qty.
Minimum Order Quantiy -> 300 Units
Order Multiple -> 300 Units
the rest of values are 0.

The demand for this Item is just a sales order with 1000 Units.

When I run the requisition worksheet I expect that the quantity should be 1200 units (major multiple of 300 after 1000).
But the result is always 1.000

Hope this shines a light...

NASi

Hi:
AdamRoue: I put a Location code in de Manufacturing Setup. The results are the same.
Andwian: Location Mandatory was set to True from the begining.


rhpnt : at first I can understand that the system propose only the quantity placed in the sales order (1.000), but If I define a Safety Stock Quantity (i.e. 400), the requisition that I get are two lines: 1.000 and 400. The same situation if I define Reorde point (i.e. 400), I get two lines: 1.000 and 400. When I say 'the rest of values are 0' minds that my Reorder Point is 0 (I haven't reorder point), and Safety Stock Quantity is 0 (I don't want work with Safety Stock). If I define this parameters I will get extra lines that I don't want. And if I have 200 units extra in stock, maybe my sales order will be converted in 1200.

So I will ask to you in a different form :
Anybody knows in that conditions the system uses the parameter 'Order Multiple'?. Anyone has used this parameter?.

rhpnt : I am arranged to read all type of documentation, of course. Find a solution to this problem will be my challenge, but can you say to me exactly where I can find it?.

And if I don't get any results, maybe the solution will be a control in the Quantity on the Sales line and/or Purchase Line saying :'The quantity must be multiple of 300 ...' or something like that rather than modify the codeunit 9900855.

@simon

I have had a similar issue, where a breach if safety stock that created a new order requirement did not take MOQ into account.

It seems, from what I can tell, that the scenario we were dealing was considered 'exception' demand and was not taking into account these factors (MOQ, Order Multiple).

V5 it seems did (we are using 2009SP1).

In the end I modified the Inventory Profiling codeunit (I forget the number) to call a routine called AdjustOrderQty for these exception planning lines; this factors in MOQ and Order Multiples.

It was with great reluctance I did this as I'm keen to keep this system as native as possible - we've added a flag in setup to activate this on/off and are testing solidly...so far so good.

If this is of interest I can post the exact code and codeunit/function details?

rhpnt

NASi wrote:

rhpnt : at first I can understand that the system propose only the quantity placed in the sales order (1.000), but If I define a Safety Stock Quantity (i.e. 400), the requisition that I get are two lines: 1.000 and 400. The same situation if I define Reorde point (i.e. 400), I get two lines: 1.000 and 400. When I say 'the rest of values are 0' minds that my Reorder Point is 0 (I haven't reorder point), and Safety Stock Quantity is 0 (I don't want work with Safety Stock). If I define this parameters I will get extra lines that I don't want. And if I have 200 units extra in stock, maybe my sales order will be converted in 1200.

It's how NAV works by design. The main purpose of the requisition worksheet is to avoid unnecessary stock and optimize purchase quantities. Your requirement breaks that logic. The second line (for stock) is by purpose because you have the choice to take or leave it. The function does not mix items that must be ordered with items that should be ordered.

NASi wrote:

rhpnt : I am arranged to read all type of documentation, of course. Find a solution to this problem will be my challenge, but can you say to me exactly where I can find it?.

There are many docs on Partner- or Customersource available.

NASi

@simon wrote:

If this is of interest I can post the exact code and codeunit/function details?

Please @simon, let me know this modification. At least I would know if I'm in a worng way or not ](*,)

Andwian

I quote the NAV online help for you convenience:

Planning for Locations without Using SKU

A reordering policy of Lot-for-lot + blank planning parameters will be applied automatically if planning for demand at a location that is different from the Components at Location field and SKU is not used. (Items using reordering policy Order remain using Order).

Planning with/without Locations
Concerning planning with or without location codes on demand lines, the planning system operates in a straight forward way when:

demand lines always carry location codes and the system fully uses stockkeeping units, including the relevant location setup.

demand lines never carry location codes and the system does not use SKUs or any location setup (see last scenario below).

However, if demand lines sometimes have location codes and other times do not, the planning system will follow certain rules depending on setup.

Demand at Location
When the planning system detects demand at a location (a line with a location code), it will behave in different ways depending on 3 critical setup values.

During a planning run, the system checks for the 3 setup values in sequence and plans accordingly:

Is there a check mark in the Location Mandatory field?

If yes, then:

Does SKU exist for the item?

If yes, then:

The item is planned according to planning parameters on the SKU card.

If no, then:

Does the Components at Location field contain the demanded location code?

If yes, then:

The item is planned according to planning parameters on the item card.

If no, then:

The item is planned according to: Reordering Policy = Lot-for-Lot, Include Inventory = Yes, all other planning parameters = Empty. (Items using reordering policy Order remain using Order as well as the other settings.)

Note: This "minimal alternative" only covers the exact demand. Any planning parameters defined are ignored.

See variations in the scenarios below.

Demand at "Blank Location"
Even if the Location Mandatory field is checkmarked, the system will allow demand lines to be created without a location code – also referred to as "BLANK location”. This is a deviation for the system because it has various setup values tuned to dealing with locations (see above) and as a result, the planning engine will not create a planning line for such a demand line. If the Location Mandatory field is not checkmarked but any of the location setup values exist, then that is also considered a deviation and the planning system will react by outputting the "minimal alternative":
The item is planned according to: Reordering Policy = Lot-for-Lot (Order remains Order), Include Inventory = Yes, all other planning parameters = Empty.

See variations in the scenarios below.

Scenarios
Setup 1:

Location Mandatory = Yes

SKU is set up for RED

Component at Location = BLUE

Case 1.1: Demand is at RED location

The item is planned according to planning parameters on the SKU card (including possible transfer).

Case 1.2: Demand is at BLUE location

The item is planned according to: Reordering Policy = Lot-for-Lot (Order remains Order), Include Inventory = Yes, all other planning parameters = Empty.

Case 1.3: Demand is at GREEN location

The item is planned according to: Reordering Policy = Lot-for-Lot (Order remains Order), Include Inventory = Yes, all other planning parameters = Empty.

Case 1.4: Demand is at BLANK location

The item is not planned because no location is defined on the demand line.



Setup 2:

Location Mandatory = Yes

No SKU exists

Component at Location = BLUE

Case 2.1: Demand is at RED location

The item is planned according to: Reordering Policy = Lot-for-Lot (Order remains Order), Include Inventory = Yes, all other planning parameters = Empty.

Case 2.2: Demand is at BLUE location

The item is planned according to planning parameters on the item card.

Setup 3:

Location Mandatory = No

No SKU exists

Component at Location = BLUE

Case 3.1: Demand is at RED location

The item is planned according to: Reordering Policy = Lot-for-Lot (Order remains Order), Include Inventory = Yes, all other planning parameters = Empty.

Case 3.2: Demand is at BLUE location

The item is planned according to planning parameters on the item card.

Case 3.3: Demand is at BLANK location

The item is planned according to: Reordering Policy = Lot-for-Lot (Order remains Order), Include Inventory = Yes, all other planning parameters = Empty.

Setup 4:

Location Mandatory = No

No SKU exists

Component at Location = BLANK

Case 4.1: Demand is at BLUE location

The item is planned according to: Reordering Policy = Lot-for-Lot (Order remains Order), Include Inventory = Yes, all other planning parameters = Empty.

Case 4.2: Demand is at BLANK location

The item is planned according to planning parameters on the item card.



As you can see from the last scenario, the only way to get a correct result for a demand line without a location code is to disable all setup values relating to locations. Similarly, the only way to get stable planning results for demand at locations is to use stockkeeping units.

Therefore, if you often plan for demand at locations, it is strongly advised to use the Stockkeeping Units feature.

From above long explanation, I could conclude that the logic is true when we do not use SKU. Otherwise, if we are using SKU, I think the Order Qty. should be 1200, just like NAsi expect.