Net requirements update in MRP Module and Working Set of MRP
Most of Dynamics AX specialists (especially from support) heard about inventSumLogTTS table. Everyone knows that this table somehow is related to MRP; Everyone knows that if you do not run MRP, your inventSumLogTTS table grows bigger and bigger and eventually you need to clean it somehow. But since detailed documentation on static/dynamic plan update algorithms is absent, not many people understand how Axapta actually use this table for plan updates; what are advantages and caveats of dynamic vs static plan use;how order explosion differs from regeneration planning and so on…
I wrote this text mostly from my experience with Dynamics AX 2009. In the new version (DAX2012) approach remained the same from functional point of view, only technical details changed, so this information can be useful also for people using DAX2012.
A bit of history
As I wrote in my blog before , inventSumLogTTS table began its life (somewhere in late releases Axapta 2.5) only as a tool to track a list of changes which was applied to inventSum table in independent DB transaction. Should the main transaction be rolled back, the system was to iterate over related records in inventSumLogTTS and programmatically rollback changes to inventSum. Starting from Axapta 3.0, inventSumLogTTS table started to be also used to support dynamic update to MRP plan. In version Dynamics AX 4.0, the whole Inventory MultiTransaction System was dropped from Axapta and replaced with a new approach. Nevertheless inventSumLogTTS table still exists in the system, but nowadays it is used only to support dynamic MRP plan update. Today, name of the table is misleading, because now it is not used to log InventSum updates. As of versions 4-2012, it is used only to keep track of inventTrans changes, which have not been applied to dynamic plan yet.
How data gets into inventSumLogTTS
The mechanism which now (in versions 4.0/2009/2012) creates new records in inventSumLogTTS is the very same mechanism which is used to update inventSum. (I described this mechanism in details in the article I mentioned). When inventTrans is inserted/updated/deleted the system calls inventUpdateOnHand.addInventSumLogTTS() method to register deletion or insertion of inventTrans record. (An update goes as a delete and insert). InventSumLogTTS records are kept in cache till the end of the transaction and are actually written to the database at the same time when the system updates the inventSum records, related to inventory transactions updated in the database transaction.
To link two records of inventSumLogTTS related to the same update of an inventory transaction, the system uses the sequenceNumber field of the inventSumLogTTS table. The system registers changes of inventTrans record, till it become physically/financially updated (Deducted/Sold or Received/Purchased statuses). Only the very first change of the transaction to physical/financial status is registered to inventSumLogTTS. Later this change is to be applied to Net Requirement of On-Hand type by dynamic plan update mechanism. Subsequent changes to the same inventory transaction are not recorded, since they are not anymore relevant for MRP; Now the transaction is a part of OnHand Stock which is represented in Net Requirements as a one on-hand net requirement per item and coverage dimension.
Working Set of MRP and a bit of terminology
To simplify further discussion I want to introduce a new term – Working Set. I will use this term to describe a list of net requirements which are participating in the current MRP session. In different stages of an MRP session, content of that list is different. In the beginning of an update stage, it contains the issue net requirements to be covered, during a coverage phase it contain mixture of covered issue net requirements, covering receipt net requirements and uncovered issue net requirements to be covered. After coverage phase, working set contains only covered/covering net requirements.
But the point is: Working set of MRP session is the most fundamental thing for understanding of MRP process and it is always defined by adding the uncovered issue net requirements to it. Everything else is implementation details.
Generally, there are two ways to start MRP: One is to start MRP from Master Planning->Periodic->Master planning; Another – to click Master Planning->Periodic->Master planning in Requirement Profile form. These menu items point to the different classes. From implementation point of view, both classes use different algorithms. First class is optimized for a multi-threaded scheduling of large number of net requirements. Second is optimized for a scheduling of only 1 item, but it has good caching mechanisms, so it might work much faster sometimes. I will use term Full MRP for MRP from Periodic menu and term Item MRP for MRP from Requirement Profile form. From functional point of view, two kinds of MRP differ a lot. Item MRP runs on the level of the set of specific net requirements; Full MRP works on the level of item+coverage dimension combination. When net requirement is added to Working Set of Full MRP, it implicitly adds a whole set of net requirements with a given item and coverage dimension combination into Working Set. Technically speaking, Item MRP is implemented by combination of classes ReqCalcScheduleItem (Responsible for the planning process itself) and ReqTransCache_Daily(Responsible for Working Set support). ReqTransCache_daily class holds a set of itemIds in a Working Set, a set of coverage dimension combinations for every item in a Working Set and a map with Net Requirements of Working Set itself. Full MRP is implemented by combination of classes ReqCalcScheduleItemTable (responsible for planning process) and ReqTransCache_Periodic (Responsible for Working Set support).ReqTransCache_Periodic class holds only a set of items and set of coverage dimensions for items in a
Working Set. ( Technically these sets are stored as ReqProcessItemListLine and ReqProcessItemDim list tables).
As we will see later, working set is created on Update phase of MRP session (I will use term Initial Working Set for it), but can grow as a result of the Coverage phase of MRP Session (I will use term Extended Working Set for working set after extension by the coverage planning).
I will also occasionally use term Items in working set. to refer to the list of items which have net requirements in the given Working Set ; Sometimes, I will also use term Session Item Set to designate the set of items defined before MRP start. In case of Item MRP, this item is defined by current content of Requirements Profile form; In case of Full MRP, these items are defined by query parameters in dialog box which is popping up in beginning of MRP process
Simplest scenario: Regeneration of static plan
Before we proceed with our discussion any further, I want to discuss the simplest scenario of MRP: Regeneration of static plan. If we are running MRP in regeneration mode, here is what happens:
- The system deletes all net requirements and all coverage information for the Session Item Set of MRP session (actually, approved planned orders can be spared from deletion, but we are not going into such a deep discussion).
- If some of the deleted net requirements were planned orders, the system also deletes derived demand for them (say, demand for sub-components of planned production order). If some of deleted derived net requirements was covered by another planned orders, these planned orders are deleted recursively and so on. The main point is: If we are running MRP for a limited working set. after an update stage, we won’t have net requirements for all items in Session Item Set ;Also some of receipt net requirements items outside of the Session Item Set will become available. Say, we are running MRP for Item A, which consists from items B,C and D. Update stage will delete all item requirements for item A, including planned production order. It leads also to deletion of the issue item requirements (not all of them, just this PO) for item B,C and D. We also delete coverage for these issue net requirements and some other receipt net requirements (say – from invent on-hand) become unused and available to cover something else.
- The system creates new issue net requirements for all items from Session Item Set. It imports info from all necessary sources – on-hand data, inventory transactions, forecast data, Min/Max data from Item Coverage setup and so on… Created uncovered issue net requirement are added to Working Set. thus forming Initial Working Set .
- Coverage phase begins for the working set items. having lowest BOM Level. The system fetches from working set all uncovered issue net requirements for an item (all our newly created net requirements from previous step are uncovered) creates coverage info (if appropriate receipt net requirements were found) or creates a new planned order and create coverage info for it. Covering net requirement is added to working set. If new planned orders were planed production orders, then the system adds derived issue net requirements for sub-components for the planned production orders into initial working set. (Thus is making it to be an Extended Working Set ) .
- Then the system proceed to build coverage for the working set items with next lowest BOM level; Again new planned orders are created; Again it leads to creation of planned orders and to further extension of working set. So, with every new BOM level, the working set contains more and more net requirements.
- Finally, after processing of working set items with highest BOM Level, the system finish coverage phase and proceed to subsequent phases.
- Futures and action planning are executed over net requirements in working set. Since this stages are more receipt-oriented, behavior of Item MRP and Full MRP differs a lot. In case of Item MRP. the system calculates action/futures only for receipt net requirements which were actually used in current MRP session(at least one record in coverage was created for these receipt net requirements). In case of Full MRP, the system calculates action/futures for all net requirements which has the same itemid+coverage dimensions combination as any the requirement used in the current planning session.
The main conclusion of this section is that the Session Item Set in Regeneration mode MRP have two purposes:
- It show the system, net requirements for which items must be regenerated and included into Initial Working Set.
- It implicitly define extended working set of planning session, by providing root items for implicit BOM explosion. Every net requirements of this explosion is included into extended working set.
I also want to mention that ONLY full regeneration for all items (MRP Item Set have all items in the system) can result in perfect plan. Even in regeneration mode (which brings much more up-to-the-rules planning results then Net Change/Net Change Minimized mode), the system can create a bit inconsistent planned orders. Say, if we created new sales line and ran regeneration mode MRP for the item used in this salesLine, it can create new planned production order to cover it and then new planned purchase order to cover the demand requirement for one of its sub-components. If this sub-component has Requirement coverage model – it is Okey. If the sub-components has ‘period’ coverage model – it is a minor problem in the plan. (Since we would probably have two planned orders for a period, instead of one).