CU99000854 – States on the planning process

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.

Integration of the MRP with Jobs

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.

How to determine if average cost is correct

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

Average cost calculation vs. discounts

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 …

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

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.

 

 

 

Using inbound Production Bins as Pick Bins

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.

 

 

Order Planning vs. Reorder point items

Remember my post about "Items with reorder point policy defined not use reservations"·

 

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).

ERP Audit: a tool for SCM individuals to be the “key” on protecting the information

This time, this post is something different. This is about productivity … but not SCM productivity. This is something that you (SCM expert) can help about. Lets begin.

You SCM expert know how information flows through the companies. You could even define what is the critical information for a company and which one is not. Thus, you (as SCM expert) are a key individual on helping companies on protecting their information: you can know information flows in the company.

The goal here is that you (SCM expert) could provide expertise on helping companies to protect their information. Keep note, I am not taking about protecting their systems but their information. Thus, we are talking here on providing guidance on setting up procedures to protect the “Information”. Then, IT (technical) people can take the procedures you (SCM) defined and setup the right technical tools to protect the systems. But, is this protection on their information something you should have only in mind after ERP is deployed? No, selling and implementing an ERP like Microsoft Dynamics NAV is something different than selling and implementing another software (Vista, Exchange, …).

It requires that ERP is align with company business goals. Without the proper skills about what business does (SCM skills), the implementation of an ERP fails (then customers blames the implementation team and them to the ERP vendor … ). Thus, this protection should start during the point in time when the ERP is even considered to be implemented. For instance, lets focus on the ERP implementation. There are quite a number of situations where companies failed implementation: company does not have the Culture to adopt an ERP, high management levels were not compromised on finding resources and defining corporate goals to achieve, Project leader does not have the skills, key users were not identified, requirements are not properly documented, there is no such a methodology to implement the ERP, there is no analysis on support incidents reported, security requirements were not properly defined … There could be tons of reasons.

Another example, before implementation there should be a phase to analyze if ERP is the right tool. This phase is called ERP Adoption. If you are an SCM individual, you should be going through these questions:
– Did the management levels define the business goals to implement the ERP? Do we know why company needs this ERP?
– Does not company have the necessary “corporate culture” to implement an ERP?
– What is the communication in the company about this ERP implementation?
– Has been a Project Leader identified? Does this Project leader have the right experience and reputation in the organization?
– What is the hierarchy structure in the organization?
– What is the IT role in the ERP implementation?
And, the role of the Business departments:
– How the organization has defined their processes with policies, procedures and standards?
– Who else but the SCM individual can better determine if ERP and business are aligned?
– Who knows better than SCM how should business be done efficiently and effective?

Not having the above in mind could lead to not having available the information that company needs or to a "leakage" on the information protection since the critical information has not been properly defined …  And now, what would be my proposal to you as SCM individual: minimize the risk by using your expertise on the "company’s information.

If you are having this in mind, you are in the right direction: you identified the information, you know what is the critical information and you are on the way to manage the risks.

To emphasize, SCM expert: you are key on protecting the "information flow" just because you can visualize it. Do not let people think IT is the key. Use this tool: ERP audit and make sure you also use your SCM skills to determine and help on how effective and efficient is the ERP.

NAV “core” Planning: CU 99000854 ( II ): Demand types

First, lets review the foundation here … lets review what the "Supply Planning White Paper" mentions:

"

…

DEMAND AND SUPPLY:

Demand is the common term used for any kind of gross demand, such as sales order and component need from a production order. In addition, the program allows more technical types of demand, such as negative inventory and purchase returns

…

Planning parameters and inventory levels are other types of demand …

…

"

 

Checking the CU 99000854, what is a demand for NAV planning engine?

a. Sales Orders

b. Service Orders

c. Planned Production consumption

d. Transfer orders

 

The actual code to find the data considered as demand can be found on the DemandToInvProfile procedure in CU 99000854.

 

As an example …

a. sales orders are being considered as demands by using this query:

…

SalesLine.SETCURRENTKEY(Type,"No.","Variant Code","Drop Shipment","Location Code","Document Type","Shipment Date");
SalesLine.SETFILTER("Document Type",’%1|%2′,SalesLine."Document Type"::Order,SalesLine."Document Type"::"Return Order");
SalesLine.SETRANGE(Type,SalesLine.Type::Item);
SalesLine.SETRANGE("No.",Item."No.");
Item.COPYFILTER("Location Filter",SalesLine."Location Code");
Item.COPYFILTER("Variant Filter",SalesLine."Variant Code");
SalesLine.SETFILTER("Outstanding Qty. (Base)",'<>0′);
SalesLine.SETFILTER("Shipment Date",’>%1&<=%2′,0D,ToDate);

…

 

b. service orders …

…
ServiceLine.SETCURRENTKEY(Type,"No.","Variant Code","Location Code","Posting Date");
ServiceLine.SETRANGE("Document Type",ServiceLine."Document Type"::Order);
ServiceLine.SETRANGE(Type,ServiceLine.Type::Item);
ServiceLine.SETRANGE("No.",Item."No.");
Item.COPYFILTER("Location Filter",ServiceLine."Location Code");
Item.COPYFILTER("Variant Filter",ServiceLine."Variant Code");
ServiceLine.SETFILTER("Outstanding Qty. (Base)",'<>0′);
ServiceLine.SETFILTER("Posting Date",’>%1&<=%2′,0D,ToDate);

…

 

c. production order consumption …

…

ReqLine.SETCURRENTKEY("Ref. Order Type","Ref. Order Status","Ref. Order No.","Ref. Line No.");
ReqLine.SETRANGE("Ref. Order Type",ReqLine."Ref. Order Type"::"Prod. Order");
ProdOrderComp.SETCURRENTKEY("Item No.","Variant Code","Location Code",Status,"Due Date");
ProdOrderComp.SETRANGE("Item No.",Item."No.");
Item.COPYFILTER("Location Filter",ProdOrderComp."Location Code");
Item.COPYFILTER("Variant Filter",ProdOrderComp."Variant Code");
ProdOrderComp.SETRANGE(Status,ProdOrderComp.Status::Planned,ProdOrderComp.Status::Released);
ProdOrderComp.SETFILTER("Due Date",’>%1&<=%2′,0D,ToDate);

…

 

and so on with other type of demands like planned consumption (check DemandToInvProfile procedure).

 

For any of these "queries", the exact filters used should be analyzed. For instance, sales line considered are those which have a shipment date equal or earlier than the planning ending date … regardless of the status in the sales order.

NAV “core” Planning: CU 99000854 ( I )

Why focusing Codeunit 99000854? If you interested on what is the logic behind NAV planning, you should look into this codeunit.

 

This codeunit is the link between how NAV planning logic is written (= "NAV Supply Planning White Paper") and how this logic is executed (=functionality around Planning and Requisition Worksheets).

 

Based on this, I will be posting a series of entries regarding how this CU 99000854 performs. Furthermore, this series on entries will:

– provide info about what are the demands taken into account during planning run

– understand what are the considered supplies in NAV

– identify the primary code related with the how NAV will treat demands and supplies (ie. will any of these be allowed to reschedule?)

– understand why priorities are needed when netting demands/supplies

– understand what is the forecast and blanket order consumption

– verify what is the planning flexibility flag in NAV

…

 

To start with, we will be understanding what are the demand types from a NAV planning engine perspective.