The New Microsoft Dynamics AX (V7) and Performance improvements in Master Planning

The new Microsoft Dynamics AX Performance improvements has made some performance improvements to master planning.  In order to talk to these improvements, I’ll first explain how master planning works in Microsoft Dynamics AX.  Each thread goes through the following steps as part of MRP:

1. Preparation – meta data; consistency checks (BOM circularity; BOM level)
2. Demand collection (updates) – transactions and collect demand (sales/safety stock/physical supply – on-hand/orders) direct demand + available supply
3. Demand coverage (coverage) – matches supply and demand; creates planned orders to cover this demand; explosion; scheduling
4. Delays calculation (futures) – reviews planned orders and calculate delays expected
5. Actions –  creates recommendations
6. Clean up – ran separately as a batch task (no impact on performance)

The following improvements were announced at Tech Conference 2016 in Seattle this past week:

• BOM level recalculation which controls the relationship between items in system (0/1/2) was improved.  The old way was taking BOM structures, loading them to memory, going through all relationships in memory and calculating BOM levels; upload would go back to invent table, set to 0 and then update all levels not = 0 to set levels even if it hasn’t changed. New Dynamics AX V7 update – load original BOM levels in memory; during update only update the DELTA.  This helps to avoid a lot of updates and increase performance.
• Bundling and Tasks – The old way included tasks each executed per item -> 1 task per item loaded into table.  The issue with is that threads were waiting on each other.  1 task per bundle so one piece of code was doing this.  And it was also running all items, so lots of tasks. New Microsoft Dynamics AX V7 update – Bundling now allows grouping of tasks and each thread has several tasks.
• Demand filtering – as part of the Demand collection phase, pre demand filtering is done to collect only the items that need to be run through MRP. It first uses the items only in the Requirement transactions table ReqTrans; then adds new items during an explosion process to the table ReqProcessItem.   New Dynamics AX V7 update – Two new parameters have been introduced to improve performance for this:

1. Pre-processing: Filtering items to be processed by MRP (by demand and available supply), prior to the collection of the actual transactional data into ReqTrans table (occurs during the demand collection phase of MRP), where items with on hand, but no other type of demand or firmed supply are excluded from the item filtering.
2. Post-processing: Filtering items to be processed by MRP; by the set of items recorded in the ReqTrans table after the demand/supply collection but prior to Demand coverage phase of MRP.  Note: This also may not be optimal for companies with a lot of indirect demand, distributed over many sub items -> in this case it is recommended to turn off demand filtering parameters since this would result in adding items AFTER the first collection task…

• InventSumLogTTS – This is a long time standing issue and we are very happy to hear there is now a proper resolution.  There has always been an issue that transactions are written into this table upon any update to sales/supply/etc. MRP was the only process that truncates this and thus if a company isn’t running MRP, this doesn’t get cleaned up. The only previous solution was to clean up manually (create a script) or turn off configuration key. New Dynamics AX V7 update –a new parameter ‘Disable all planning processes’ has been introduced that disables all planning processes which disables insertion into the InventSumLogTTS table…This also introduces checks when enabled to avoid companies from using MRP so it’s not unreliable. 

Several improvements have also been made in conjunction with the move to SQL Azure for the new Dynamics AX (V7):

SQL Azure and transaction scope in MRP – Previous versions used the transactional TTS end/commit and thus needed to increase scope and balance. New Dynamics AX V7 -> TTS scope now balances through encapsulating.

SQL azure timeout – reader-writer lock for MRP plan locking. In previous versions, the SQL app lock was used to maintain a lock through the user connection. In the new SQL Azure world, there is a timeout and since MRP can run over several hours, a collection timeout of 30 min could kill off the lock.  New Dynamics AX V7 -> keep SQL app lock but method created for a separate thread from main thread to keep this thread alive and to maintain SQL lock (once every 4 minutes) in order to keep lock alive.

With the new cloud based solution, there have been some additional features introduced as well:

Cloud based Telemetry – MRP parameters added in order to collect run details for each run. Allows you to see events and troubleshoot MRP issues without disrupting production environment.

LCS rules around usage of helpers; caching, bundling and scheduling methods.  Install client and these are suggestions on actions to be taken to improve performance, correct data, etc. so recommendations of MRP are now included.  Rules can also be ignored. On trial right now.

Note: For Dynamics AX 2012 customers, some of non SQL azure changes are going to be back portable and made available, no date promised.