Microsoft Dynamics AX 2012
®
Issues and requirements:
The transaction framework
Concept Paper
The Master Planning module in Microsoft Dynamics AX 2012
works on a principle of fulfilling demand with supply; however in
practice it can be a very complicated process. This document
gives an overview of the data the master planning operates on
and provides insight in the decisions taken during the MRP run.
September 2011
CCAX2012DI0061
Table of Contents
Overview..................................................................................................... 3
Architecture of the MRP transactions .......................................................... 3
Master plan .......................................................................................................................... 3
Net requirements .................................................................................................................. 3
Planned order ....................................................................................................................... 4
Coverage ............................................................................................................................. 5
Fulfilling requirements ................................................................................ 5
The many dates........................................................................................... 7
2
ISSUES AND REQUIREMENTS: THE TRANSACTION FRAMEWORK
Overview
The Master Planning module in Microsoft Dynamics® AX 2012 works on a principle of fulfilling demand
with supply; however in practice it can be a very complicated process. This document gives an
overview of the data the master planning operates on and provides insight in the decisions taken
during the MRP run.
Architecture of the MRP transactions
Below is a conceptual model of the transactions that is input and output to the master planning
process.
Master plan
1
*
Issue
Net requirement
1
Planned order
1
0..1
*
1
Receipt
Coverage
*
Master plan
All transactions belong to a specific master plan. The plan entity is in itself just a number of setting
fields, but the purpose of having the entity is to allow separation, so e.g. different combinations of
settings can be tried without effecting the plan that is currently being executed.
Net requirements
Transactions in master planning can have different directions: An issue is something that decreases
the stock and a receipt is something increases the stock. Besides the direction they are separated by a
type. For each type, there is a standard direction, which is the typical direction that the transaction
will have however when making e.g. a credit note for a sales order it can be reversed.
Type
Direction
Description
On-hand
Receipt
Generated based on the sum of inventory transactions.
The requirement date of this special transaction is set to
the system minimum date.
Purchase order
Receipt
One transaction will be inserted for each purchase order
line.
Sales order
Issue
One transaction will be inserted for each sales order line.
Production order
Receipt
The production order will trigger a receipt at the scheduled
end date.
3
ISSUES AND REQUIREMENTS: THE TRANSACTION FRAMEWORK
Type
Direction
Description
Production line
Issue
One transaction will be inserted for each BOM line in the
production order.
Inventory journal
Issue
Will be inserted from inventory journals with line type
BOM line.
Safety stock
Issue
If an item has a minimum stock level set then an issue will
be inserted. The date of the issue depends on the settings
and can be today’s date, today’s date + procurement time,
first issue date or at the end of the coverage time fence.
Inventory journal transfer
Receipt
Will be inserted from inventory transfer journals.
Transfer order shipment
Issue
The “From” part of the transfer order.
Transfer order receive
Receipt
The “To” part of the transfer order.
Demand forecast
Issue
If a forecast model has been defined in the master
planning settings then all demand forecast transactions are
inserted. Note that the supply forecast are inserted with
the default planned order type (like Planned purchase
order) and so they will not be directly distinguishable.
Planned production order
Receipt
The planned production order receipts will either be
generated from master planning or have been manually
inserted by the user.
BOM line
Issue
All BOM lines of the planned production order will be
inserted as issue transactions.
Planned purchase order
Receipt
Planned purchase orders are the default way of fulfilling a
demand during master planning.
Planned transfer
Receipt
The “From” part of a planned transfer order.
Transfer demand
Issue
The “To” part of a planned transfer order.
Quarantine order
Issue
A quarantine order effectively reduces stock at least for a
period, so it is considered an issue.
Quotation
Issue
One transaction will be inserted for each sales quotation
line.
Kanban
Receipt
The inventory transaction of type Kanban process job
will be inserted as a receipt.
Kanban line
Issue
Several inventory transaction types (like Kanban
emptied) are all inserted as kanban line requirements as
they should be treated similar by master planning.
Planned Kanban
Receipt
A Planned Kanban receipt will either be generated by
master planning or have been manually inserted by the
user.
Planned Kanban line
Issue
The derived requirements of a planned kanban.
Planned intercompany demand
Issue
Demand coming from other legal entities that are part of
the intercompany planning group.
Planned order
Many of the net requirement transactions are inserted based on information from other modules of
Microsoft Dynamics AX. These transactions are the basis on which the master planning runs and
determines if new receipts are required in order to fulfill all the issues. When a new planned order is
created a record is inserted both in the net requirements table and in the planned order table. The
4
ISSUES AND REQUIREMENTS: THE TRANSACTION FRAMEWORK
latter holds additional information that is only applicable to planned orders like the scheduled from/to
dates, the vendor, etc.
Coverage
The Coverage entity links net requirement issues with receipts and stores how much quantity of the
receipt has been allocated for the specific issue.
Fulfilling requirements
When an issue requirement exists the task of the master planning is to fulfill this. The basic process of
matching issues with receipts that MRP process goes through is fairly simple as illustrated in the
diagram below.
Start
Item coverage is set
to ”Manual”
Yes
No
Done
No
Issue has uncovered
quantity?
Yes
Can find existing
receipt with open
quantity?
Yes
No
Create new planned
order receipt
Open receipt
quantity >=
uncovered issue
quantity
No
Create coverage with
open receipt quantity
Yes
Create coverage with
uncovered issue quantity
For some items the coverage rule in the coverage group has been set to Manual. This means that
master planning should ignore the issues and just leave them uncovered.
5
ISSUES AND REQUIREMENTS: THE TRANSACTION FRAMEWORK
Note that in the diagram the term receipt applies to both regular receipts like a purchase orders but it
can also be the special on-hand transaction.
The search for existing receipts is done with the following criteria:

Requirement date: The minimum date of the interval in which the receipt’s requirement date
must be in is bounded by the issue requirement date minus the number days of the “positive
days” setting. The maximum date is the issue requirement date plus the number of days of the
“negative days” setting minus the receipt margin.

Inventory dimensions: The value of those inventory dimension fields, which are marked as
Coverage planned in the dimension group, must be the same on the issue and receipt.
Dimension fields which are not marked as Coverage planned will be ignored for the matching.

BOM and route: If the issue has a specific BOM or route stated (e.g. when set on a sales order)
and the BOM version requirement or Route version requirement option on the coverage
group is marked, then the receipt must also have been created with the specific BOM or route.

Status: Only open receipts (= which have some unallocated quantity).
When no existing receipt can be found a new planned order will be created. The quantity of the new
order will depend on the coverage rule used:

Requirement: The entire remaining uncovered issue quantity will be used.

Period: The quantity of all similar uncovered issues will be aggregated. The issues included in the
sum must have a minimum requirement date of the requirement date of the original issue and a
maximum requirement date of the requirement date of the original issue plus the number of
“coverage period” days (or the number of “positive days” if this is less than the “coverage period”
days).

Min/Max: When generating a planned order for a safety stock issue, the quantity will be set so
the available stock will reach the value stated in the Maximum field on the item coverage.
After the preceding rules are applied, the planned order quantity might be further adjusted based on
the default order settings. The minimum and maximum order size setting can cause the quantity to be
decreased or increased and depending on the unit of measure decimals the quantity might be rounded
up.
6
ISSUES AND REQUIREMENTS: THE TRANSACTION FRAMEWORK
The many dates
In the master planning transactions there are many dates to keep track of. In the following scenario a
sales order for an item has been created. To fulfill the sales order issue master planning has created a
new planned production order, which requires one subcomponent. Since the component is not in stock
a planned purchase order is created so all issues are covered by receipts.
When the sales net requirement transaction is created, the sales order line’s Requested ship date is
transferred directly to the Requested date field (displayed in the diagram as ORD). From this date is
then subtracted the one day issue margin which results in the Requirement date (RD).
The planned production order that should fulfill the sales order issue will then get the same
requirement date, from which the receipt margin is then subtracted to get the Requested date. The
scheduling engine will then use either the route or a simple lead time to determine the order’s
scheduled start date, depending on if a route has been defined and the requirement date is within the
capacity time fence. The Order date will be offset from the start date with the reorder margin.
Each of the lines in the planned production order’s bills of materials will get the Requested date set to
the scheduled start date of the production order, and like for the sales order the issue margin is
subtracted to get the Requirement date.
The dates for the planned purchase order will then be set using the same logic as for the planned
production order with the exception that the lead time will always be applied.
After all the margins and so on has been applied in the scenario the end result is that the planned
purchase order gets an order date 3 days before today. Since this is not possible to execute in real life
7
ISSUES AND REQUIREMENTS: THE TRANSACTION FRAMEWORK
the planned purchase order will get a future date that is 3 days after the Requested date. The number
of future days is then applied all the way up through the hierarchy so the sales order also ends up
with a future date 3 days after the original Requested date.
On the master plan there are options to Use Futures date as requirement date for each of the
planned order types. If this is switched on then the requirement date will be adjusted forward
according to the futures date, which means that the order date is also adjusted forward. In the
scenario shown in the diagram this option is not switched on, which means that even though it is
known that the orders will be delayed the scheduling etc. will not be changed.
8
ISSUES AND REQUIREMENTS: THE TRANSACTION FRAMEWORK
Microsoft Dynamics is a line of integrated, adaptable business management solutions that enables you and your
people to make business decisions with greater confidence. Microsoft Dynamics works like and with familiar
Microsoft software, automating and streamlining financial, customer relationship and supply chain processes in a
way that helps you drive business success.
U.S. and Canada Toll Free 1-888-477-7989
Worldwide +1-701-281-6500
www.microsoft.com/dynamics
This document is provided “as-is.” Information and views expressed in this document, including URL and other Internet Web site
references, may change without notice. You bear the risk of using it.
Some examples depicted herein are provided for illustration only and are fictitious. No real association or connection is intended or
should be inferred.
This document does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and
use this document for your internal, reference purposes. You may modify this document for your internal, reference purposes.
© 2012 Microsoft Corporation. All rights reserved.
Microsoft, Microsoft Dynamics, and the Microsoft Dynamics logo are trademarks of the Microsoft group of companies.
All other trademarks are property of their respective owners.
9
ISSUES AND REQUIREMENTS: THE TRANSACTION FRAMEWORK