CU99000854 – States on the planning process

3 November, 2010 3 comments

Not sure if you are familiar with this. But, I believe it worths covering it …

During NAV planning, the logic goes through different steps in the planning cycle: StartOver, MatchDates, MatchQty, CreateSupply, ReduceSupply, CloseDemand, CloseSupply, CloseLoop. All these steps are being performed on the PlanItem procedure from CU99000854. The way planning goes through each of these steps depends on the reordering policy. But basically:

First state is StartOver which determines if there is any demand to plan for. If so, it try to determines if there is any supply. If this is the case, next state would be MatchDates. If no supply exists, next state would be CreateSupply. If there is no other demand to plan for, next state would be ReduceSupply (if any exists) or CloseLoop (to finalize the loop through all states).

MatchDates state. This is about matching demand and supply dates to make sure that both can be plan together (ie. supply can be used to meet demand). If cannot be met, next state would be CreateSupply (another supply needs to be created). If it can, the existing untracked quantity in the supply needs to be reduced and state would be ReduceSupply.

MatchQty state. If supply quantity is not enough, it needs to be closed (no more available) through CloseSupply state. If this is a supply where quantity can be increased, then CloseDemand state can be next.

CreateSupply state. This is the step where supply will be created depending on the policy.

ReduceSupply state. Here, the untracked (unnecessary) quantity will be reduced from the supply. Next state would be to close the supply.

CloseDemand state. In here, the demand will be closed which means that demand has been planned for. The next thing (state) to do here would be StartOver to start the planning of another demand.

CloseSupply state. This is similar than CloseDemand state but from the supply perspective. If supply has been entirely planned, another supply needs to be considered and StartOver state will be next.

CloseLoop state. This is where planning finalizes. Before doing that, it will determine if ROP has been crossed. If so, it will be planned for again by going through the StartOver state.

Hopefully someone finds the above info useful. Think about a sequence of steps before plan can be considered as finalized. These sequences of steps are being done in the PlanItem procedure through a WHILE loop until plan is done.

Categories: Sin categoría

Integration of the MRP with Jobs

15 October, 2010 Leave a comment

This is not to use it but to test it. Yeap, this is a disclaimer so reader knows that testing should always be done.

What I would like to cover here is how to integrate MRP with Jobs so material required for jobs create action messages. Before that, lets see how CU99000854 determines where the demands are coming from. This is done on function DemandToInvProfile. Here it goes through the different types of demand (Service, Sales, Production, …) and make planning aware of them.

Back to our case, this same function is where we need to add code so MRP is aware that Job Planning Lines carry demands (material requirements). As an example, the piece of code we could consider is the following:


JobPlanningLine.SETCURRENTKEY(Type,”No.”,”Variant Code”,”Location Code”,”Planning Date”);
JobPlanningLine.SETRANGE(Type,JobPlanningLine.Type::Item);
JobPlanningLine.SETRANGE(“No.”,Item.”No.”);
Item.COPYFILTER(“Location Filter”,JobPlanningLine.”Location Code”);
Item.COPYFILTER(“Variant Filter”,JobPlanningLine.”Variant Code”);
JobPlanningLine.SETFILTER(“Planning Date”,’>%1&<=%2',0D,ToDate);

IF JobPlanningLine.FIND('-') THEN
REPEAT
InventoryProfile.INIT;
InventoryProfile."Line No." := NextLineNo;
InventoryProfile.TransferFromJobPlanningLine(JobPlanningLine);
IF InventoryProfile.IsSupply THEN
InventoryProfile.ChangeSign;
InventoryProfile.INSERT;
UNTIL JobPlanningLine.NEXT = 0;

What we are doing above is using the job planning lines of type "Item" to be considered as demand and use the planning date as due date for the demand.

Going forward, reader could take it from here to finalize the development.

Categories: Sin categoría

How to determine if average cost is correct

29 September, 2010 Leave a comment

This is a frequent question from out there: how could I determine if Average cost is correct? How NAV calculates this average?

The simple answer is: average cost is determine by the following formula through value entry table: (sum of actual cost + sum of expected costs) / (sum of item ledger entry quantity). This will provide the average cost (unit cost) when Adjust cost is run.

And, how NAV calculates this average cost for a specific date? This is done by ordering the value entries by valuation date. This date is when entry is valued. Thus, we need to order the entries how they are valued. Once this is done, next order to consider is: inbound entries first, outbound entries next. In other words: we calculate the average cost by using the positive entries and we then deduct the value of the outbound entries to find out the final average cost on that given date

Categories: Sin categoría

Average cost calculation vs. discounts

10 September, 2010 Leave a comment
We already know average cost is being updated on the "Unit Cost" field from Item card. This unit cost is being updated when:
- Adjust is run from average cost calculation
- When purchase is posted and unit cost is 0, or inventory turn to be positive. This unit cost is being copied from the Last Direct Cost.
 
This second case is the relevant here. The Last Direct Cost field do not have the discounts included to avoid that discounts are forwarded to other orders. The design interpretation here is that discounts are dependant on vendor, date (campaign), … so it is better not to include the discount when purchase cost is copied to Last Direct Cost. If later, Unit cost needs to be updated from Last Direct Cost, it would mean that also Unit Cost will not have this info. However, on a later run of the Adjusted cost this Unit cost will be recalculated and discounts will be used.
 
So, it means that Unit cost should have been have the discounts included in the first place. The design do not do this since it is clearly explained on the online help. So, for those of you which would like to modify this …
CU22 (proc. UpdateUnitCost). This calculates the Last Direct Cost. Here you could control if discount should be taken into account or not.

      LastDirectCost :=
        ROUND(
          (ItemJnlLine.Amount + ItemJnlLine."Discount Amount") / "Invoiced Quantity",
          GLSetup."Unit-Amount Rounding Precision");

b.      CU5804 (proc. UpdateUnitCost). This updates "Unit Cost" and "Last Direct Cost" in item card. Here, we could determine how/when to update this.

      IF ("Unit Cost" = 0) OR ((InvoicedQty > 0) AND (LastDirectCost <> 0)) THEN BEGIN
        CALCFIELDS("Net Invoiced Qty.");
        IF ("Net Invoiced Qty." > 0) AND ("Net Invoiced Qty." <= InvoicedQty) THEN
          "Unit Cost" := LastDirectCost;

IFI

Categories: Sin categoría

What happens when both Inbound and Outbound Production bin codes are the same …

1 March, 2010 4 comments
This is an unexpected setting for NAV. Think about this …
- If this is the "Inbound Production Bin Code", NAV understands that stock on these are not available since is pending to be consumed in Manufacturing
- If this is the "Outbound Production Bin Code", NAV understands this is available since stock is whatever has been already produced and it is ready for any sales, transfer, other production stage …
 
So, depending on what production bin is, NAV determines this is available or not. And … what happens if we set both inbound and outbound production bins the same? Problems … yeap, problems. In one hand, NAV removes inventory from the stock availability when this is the inbound. Thus, it will not be available. For your curiosity, this is done on the CU7312 – SetOutboundFilter where NAV determines if the stock can be used or not.
 
As previous post here, if users need stock from the "Inbound …" (ie. stock which was placed to be consumed but due to a sales urgency needs to be picked), this stock need to be moved (Warehouse movement) to any other bin which is able to be picked from.
 
FYI "Open Shop Floor Bin Code" and "Adjustment Bin Code" have same treatment as the "Inbound Production Bin Code". Thus, stock there is not available for a pick.
 
 
 
Categories: Sin categoría

Using inbound Production Bins as Pick Bins

18 February, 2010 3 comments
What are the inbound Production Bins in NAV? These are the bins defined in the Warehouse setup with the following names:
- "Open Shop Floor Bin Code". This is the one used with Backflushing when Flushing Method is set to Backward/Forward
- "Inbound Production Bin Code". This is the standard bin for the consumptions and it is also used with flushing when this is set to "Pick+Backward" or "Pick+Forward"
 
From this perspective, should be have these type of bins set with the Pick flag enabled? Well, it mit might be on your customer but NAV availability calculation wouldn’t like it. Think about this:
- Inbound Production bins contain inventory required for Manufacturing
- This inventory should be respected and "soft reserved" for Manufactuing (not as the general reservations)
- Based on this, if there is a customer (ie. a sales order picking) which tries to take inventory from these bins, NAV provides an error to preserve the need from Manufacturing
 
This is reasonable, I believe. Do not take the inventory which is required by Manufacturing personnel. Now, what happens if there is an urgent customer order which requires to take inventory from this bin? In this case, it would be required to move inventory (Movement document in Warehouse) from the production bin to a pick bin.
 
Having this in mind, it is not adviced to have these inbound production bins with the Pick flag activated. This will disturb inventory availability calculations and it is not an intended workflow.
 
 
Categories: Sin categoría

Order Planning vs. Reorder point items

22 September, 2009 13 comments
 
What I was trying to mention on this entry is that Reorder point items (Fixed Reorder Qty. or Maximum Qty.) are two planning policies where item is being planned against stock. What this means is that whenever stock is below a specific inventory level (reorder point), NAV will automatically create (or propose) a new replenishment. If this reorder point is properly calculated, this planning policy guarantees that there would be enough stock to cover for the average demand.
 
Now, we already mentioned that reservations should not be used with this type of items (that is the mentioned post). But, please also keep in mind this is also relevant for Order Planning. If users execute Order Planning, this means that a specific replenishment is going to be created for a specific demand. These two (replenishment and demand) are being pegged using reservations. But, what will be the point of using reorder point if this replenishment is specifically created and reserved for a demand. This is also a manual action (to create the replenishment) vs. the automatic reaction where NAV suggests new replenishment when stock is below reorder point. This is also make to stock (reorder point) vs. make to order (order planning).
 
To conclude, Reservations and Order Promising disturb the planning since we assign specific replenishment to demands when the expectation is that stock will be enough (no matter what demand/replenisment will be created).
Categories: Sin categoría
Follow

Get every new post delivered to your Inbox.