MRP: Understanding ‘Directly Derived’ Planned Orders

Most Dynamics for Finance and Operations users (including AX 2012 R2 and R3 users!) will know that “directly derived” planned orders cannot be firmed. They are generated by MRP in these situations:

Line type – Phantom

If MRP sees a phantom in a BOM, it only uses the quantity of the phantom to continue the explosion.

Bill of Materials lines

Below is the planned order that is directly derived.

planned orders window

When trying to firm such a planned order, we get this:

firming planned orders window

If you click “OK” in this window, it will be ignored. This planned order cannot be firmed.

The “directly derived” planned production order will disappear when the planned production order for the next higher assembly is firmed.

Line type – Vendor when using a normal item

This is not very common. We typically use service items with Line type – Vendor, because this is the standard scenario for subcontracting. In that case, there are no planned orders at all because service items are ignored by MRP (this is hardcoded behavior).

In case we do have a standard item with “Vendor” line type, the system will create the purchase order during estimation of the production order. But MRP will have a “directly derived” planned purchase order. It will stay around until we have the actual Purchase order created during the estimation of the Production order.

Line type – Pegged supply when using a normal item

The bottom line is that for any line type that is not “item,” MRP creates “directly derived” planned orders when the item is a regular item. For line type “Pegged supply,” the system will generate lower-level Production order(s) during the estimation of the higher-level production order. Until that time, you will have a “directly derived” planned production order in the system.  

Behavior of “directly derived” planned orders

They cannot be firmed as this would disrupt the standard functionality.

They behave like “approved” planned orders. This means that their quantity never changes based on changed demand. The planned PO is a placeholder with the exact amount that is needed for the planned production order on the next higher level. It is created independent of any on-hand and it is not looking at any other demand even if you have period coverage. The pegging is strictly 1-1 to the BOM line demand. The bottom line is that the standard MRP calculation is not used for these “directly derived” planned orders. Not surprisingly then, they keep the same order number after MRP runs in regenerative mode.

Planner and buyers! You need a filter and a personalization.

For planners/buyers, the planned order list they work through should be filtering out the “directly derived” planned orders.

The Net Requirement screen should be personalized to show this “directly derived” value, so the user is not confused.

The “directly derived” field is called “Suborder” on that screen.

suborder screen


The “directly derived” planned orders are confusing for the user. In the older versions of D365 for Finance and Operations (before AX 2012), there were no planned orders for phantom items that showed up in the planned orders list. We saw them only as (dynamic) planned orders for these phantom items in the explosion. Since AX 2012, they show up as planned orders in the list.

Hopefully, this blog has helped any planners and buyers take into account some measures, so “directly derived” planned orders do not get “in the way” of daily work.

This publication contains general information only and Sikich is not, by means of this publication, rendering accounting, business, financial, investment, legal, tax, or any other professional advice or services. This publication is not a substitute for such professional advice or services, nor should you use it as a basis for any decision, action or omission that may affect you or your business. Before making any decision, taking any action or omitting an action that may affect you or your business, you should consult a qualified professional advisor. In addition, this publication may contain certain content generated by an artificial intelligence (AI) language model. You acknowledge that Sikich shall not be responsible for any loss sustained by you or any person who relies on this publication.

About the Author