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.
- 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.
- Before importing an item’s inventTrans/inventSum data into net requirements (step 4 of the previous case), the system cleans all records of inventSumLogTTS table for the item.
- On coverage phase, before processing of an item (even if it was not in Session Item Set) the system runs special class (reqTransUpdate) which updates net requirements for the item with relevant information from the inventSumLogTTS table and then drop this information from aforementioned table. I will call this process a Dynamic Update Stage.
- In Net Change Minimized mode, the system includes into Initial Working Set only those net requirements, which are marked as uncovered. Since after regeneration planning, the plan can not have uncovered net requirements, technically, the Initial Working Set consists only from the uncovered issue net requirements which were updated on net requirements update stage. Since no receipt net requirements are included into Initial Working Set by update stage, subsequent futures and action calculation stages will work only with the net requirements which were actually used in the planning session (in case of Item MRP) or with the net requirements which has the same itemId and coverage dimensions as any of the net requirements used in coverage phase of planning session (in case of Full MRP).
- In Net Change, the system includes into Initial Working Set all net requirements for all items in Session Item Set. Also, the system drops action information (action quantity and action days in net requirements and coverage table) for all net requirements in Initial Working Set (even already covered). As a result, action phase works for all net requirement with items in Session Item Set. (Coverage phase of MRP session cannot be influenced by inclusion of all net requirements, since MRP simply ignores all issue net requirements which are already covered).
- Sales line explosion. Implemented by the class ReqCalcExplodeSO. This class runs when you click ‘Update’ button on top of the Explosion form, called from sales orders form by clicking on Inquiries->Explosion. It also automatically run on salesLine creation or update if salesLine has reservation mode Explosion;Also, It runs when a user has changed marking for inventory transaction. The last point looks a unclear at a first sight, but purpose of this behavior is very simple: Whenever a user is changing inventory marking (which is mirrored in coverage info), the system must drop existing coverage info and rebuild it from new marking information. (We will talk later about extra marking-related functions of explosion, which are not supported by regular MRP)
- Production order explosion. Implemented by the class ReqCalcExplodeProd. This class runs when you click ‘Update’ button on top of the Explosion form, called from production orders form by clicking on Inquiries->Explosion. It also can be automatically run during Operation/Job Scheduling in of production order. Automatic explosion of production order happen in two cases: First of all, it happens when at least one of the ProdBOM lines have a ‘On Schedule’ automatic reservation mode and the product order is being scheduled for the first time in its life cycle. Second, it happens when production order does not have related Net Requirements in current dynamic plan (probably – because the order was entered manually and never was scheduled before) and user is running order scheduling with checked ‘Finite material’ checkbox in scheduling parameters. It might look surprising on a first look, but ‘Finite material’ mode asumes compulsory integration of production order scheduling into MRP. There is no other way for Axapta to find availability of a material for a production order, but the usage of MRP. So, if you are going to use production orders without setting up master planning module and implementing master planning business process , do not hope to have reasonable results of production scheduling with ‘Finite materials’ checkbox. If you have not specified current dynamic plan in Master Planning parameters, the system will use current static plan. If both static and dynamic plans have not been specified, the system will create new plan with reasonable defaults and set it in Master planning parameters as both current static and current dynamic plans.
- Planned order explosion. Implemented by the class ReqCalcExplodePO. This class starts when you click ‘Update’ button on top of the Explosion form, called from planned orders form by clicking on Inquiries->Explosion. It is also called automatically when user creates/modify planned order or when planned production order is firmed.
- Current Explosion. This checkbox enables so to say, selective regeneration for explosion.All coverage information for the net requirement is being exploded. If covering net requirement was planned order and it does not cover another net requirements, it is also deleted, leading to recursive deletion of derived net requirements and so on. I want to warn you that this mode does not prevent incorrect planing phenomena, which we discussed in previous section. Since this mode only deletes coverage information for demand and derived demand of given net requirement, it won’t help if we have non-urgent net requirement, independent from net requirement being exploded and our on-hand data is covering this non-urgent net requirement.
- Marking and Reservation. This checkbox is available only for salesLine explosion and production order explosion. It instructs the system to delete marking information and drop reservations from underlying inventory transactions. As you probably knew, marking and reservation have impact on coverage planning. If two inventory transactions are marked, their net requirements will be connected by coverage. If inventory transaction is Reserved Physically, it always covered from on-hand net requirement. So, if you checked Current Explosion, you would probably need to check this checkbox as well, otherwise most of dropped coverage information,would be recreated from inventTrans data.
- Autoreservation. This checkbox is available only for salesLine explosion and production order explosion. If you enabled this checkbox, after explosion, the system will duplicate coverage information into inventory transactions. Coverage info will be transferred into marking; If the requirement was covered by an on-hand net requirement, related inventory transaction will be reserved. This checkbox is especially useful if you want to handle the situation of manual production order entry. In ideal world, users never enter production orders manually. They run regeneration MRP for all items, firm resulting planned production orders and the firming process creates inventory markings from coverage info. But what if a user have manually created new production order? How can we create marking from coverage info in a quick way ? Just try to check this checkbox and run explosion.
Change of current dynamic plan
If you try to change Current Dynamic Plan setting in master planning parameters, you witness very strange behavior. On attempt to change, the system pops-up a dialog box with the message “Update and move transactions to new dynamic master plan?”. If you agree, on attempt to save changes, the system will hang for a while. After that you will be surprised a lot: Your new dynamic plan contains exactly the same information as old dynamic plan. The system was hanging during parameters update just because it was copying old dynamic plan content into the new dynamic plan…
On a first sight it looks totally weird and counter-intuitive. We are deliberately changing dynamic plan and yet, as a result, we have the same plan under a different name. But if we think more about it, it is not so weird as t seems. Say, we just changed current dynamic plan without copying. What should the next explosion do ? We have a lot of recorded changes in inventSumLogTTS; Which of them should be applied to the new dynamic plan and which – should not ? The system does not have information to make this decision at all. We have only one dynamic plan which is synchronized with inventTrans/InventSumLogTTS state. So, if we are changing current dynamic plan settings, there is only one relatively fast way to bring it to synchronous state – to copy the old dynamic plan (which is kept in sync by definition) to the new one. An alternative approach would be to run Full MRP in regeneration mode, but it would require much more time and DB/AOS server capacity. That’s why designers of MRP module in Dynamics AX decided to always copy dynamic plan on change of current dynamic plan setting.
Dynamic Update process
Dynamic update algorithm is pretty straightforward. The system runs over the inventSumLogTTS records for the specified item sorted by sequence number and applies every change to underlying net requirement record (reqTrans). There are few points to be made though:
- InventSumLogTTS table uses pessimistic locking. If two users are trying to run planning or explosion for the same item, one of them will be suspended. If we have a lot of changes for the given item, this user can spend 20-30 seconds waiting. In version 2012, developers has changed this approach and now the system uses optimistic locking for the table.
- Dynamic Update process starts not only during MRP or Explosion, but also when a user opens Requirement Profile or Explosion forms. If your inventSumLogTTS has a lot of records for the given item, do not be surprised that on attempt to open any of these forms for the item, Axapta client can hang for a while (up to several minutes, if you have not run regeneration planning for a long time and your database server is weak). Another interesting effect of this mechanism is that even if you just created new order line (say – Sales Order line) and have not run MRP/Explosion afterwards, in the Requirements Profile form, you can see requirement for this line. The call to Dynamic Update class in the init() method of the forms mentioned, caused it to create new net requirement even before any MRP/Explosion runs.
- When the system is running Dynamic Update process, it keeps list of changed dimensions and changed quantities. After the update, it tries to find paired Net requirements with changed dimensions and ‘re-wire’ coverage information for them. Say, if you changed warehouse in purchase line and the system automatically changed warehouse in marked inventory transaction for sales order, next dynamic update will first drop and then re-create coverage information even before real MRP coverage stage is run. (You can check it if you open Requirements Profile form after changing warehouse, but before running MRP/Explosion).
- I never saw the following situation, but I still believe that it can happen sometimes: Since Axapta does not use serializable transaction isolation level, it might happen that after the system red inventTrans data (used to regenerate net requirements) but before the deletion of inventSumLogTTS data, another user might update inventTrans. As a result: Information about change is deleted from inventSumLogTTS (since we deleted all info for the item) and is not present in Net Requirements (because query which is reading inventTrans to build net requirements was started before the change). Probability of this situation is very low, but it still can cause minor inconsistency in planning results. I believe that the only way to fix it is to implement a support for snapshot transaction isolation level in Axapta and then use this new isolation level in code of MRP Update phase.
We are an AX2009 shop. We do not use Master Planning. What is the safest way to clean up InventSumLogTTS?
First of all – you can simply disable configuration key Master planing and solve the problem once and for all. (If this key is disabled, logistic module does not insert new records into the table).
If you cannot disable master planning module, you can clean-up this table by call to inventSumLogTTS::deleteCommittedItemId(”).
Hi Denis, great job on this article. I’m not a developer and am just learning AX but there is so much great information here. I’m working on an implementation and a practical question was asked: “What is the difference, operationally, between running Net Requirements on a sales line and Explosion?” That is, when should we run one or the other? Can you offer some guidance on this? Thanks very much.
Sorry for the delay – somehow wordpress eat-up notification of your comment. Explosion and MRP for one item in Net Change mode are very close by the way they operate. The biggest difference is that explosion can clear marking and reservation in the beginning of the process (thus clearing up coverage information used during subsequent MRP process) and explosion can rebuild reservations/marking from results of MRP (new or updated coverage information). Otherwise – they are almost similar.
Great article about MRP. I have one question about ERP. We are a company which automaticly receives sales orders from a website. This process is 24/7
Now we want to run a MRP for a specific coverage group. We plan this for example on 20:00H. Problem is that de MRP never ends because every minute a new order arrived in AX2012 from the website.
I tried to add a query on the MRP run(e.g. for the field creation date/time), but the MRP never looks in this query.
Can you advise me for this problem in a functional way? We use AX2012.
Honestly speaking, I do not think that insertion of new orders can make MRP to run indefinitely. In the beginning of planning session, system scans inventTrans table, creating all necessary net requirements. Even if your new order was created during this phase, MRP won’t see inventory transactions created from this new SO, because Dynamics AX use read committed mode for queries and generally is unable to see changes made by other session after start of the query. Then system start calculate coverage for the items in working set from least nested products (saleable products) to most nested products (material). If Axapta is working with dynamic plan, before calculating coverage for every item, system runs quick requirements update, transfering from inventory transactions to current plan all changes made after MRP was started and before coverage for the given item was initiated. So: If your order was created before 1st phase (requirements regeneration), then it will be processed during requirements regeneration. If it was created after requirements regeneration but before item coverage calculation for salesLine’s item – it will be processed during item coverage. if order is created after beginning of coverage calculation for given item – then this order will be completely ignored by MRP and won’t be processed till next MRP session.
Probably, you are facing performance issues, caused by some other problem. During MRP run, try to look into two tables ReqCalcTaskBundle and ReqCalcTask. ReqCalcTaskBundle hold a list of similar tasks (this table contains status and kind of task), ReqCalcTask contains info about specific task. MRP helpers process a bundle of task at a time. Processed tasks are dropped from the table, while new bundles can be created as a result of processing. (Say – if coverage processing created new planned production orders, it creates also special task to run resource scheduling for this orders).
Try to look into these tables and check what’s your MRP is doing and on what tasks (and items) it spend most of the time. Perhaps it will shine some light on the performance issues, you are facing…
First of all many thanks for a very clear blog on MRP logics. I have been going through many blogs about MRP to understand the logics, of Static Plan and Dynamic plan, as well the actual functions of Regeneration and net change” in detail, and your blog answered almost all.
I would like to have your opinion on the below Scenario:
We are running Master planning “With Regeneration mode” every day, and we are into Project based manufacturing. so that the Planner goes into project item requirements > Inquiries > Explosion > Planned orders and firm them all. and please note the dates of each planned purchase order is manually entered by the planner.
We are using “standard marking” during firming of all planned orders.
There key requirement is that, for a particular Project, they want a list of Production orders, and purchase orders firmed , to follow up and get the materials in on time.
But Many times, MRP keep changing the pegging, and allocate a production order/ Purchase order to different project, than the firmed one. because of these, they loosing track of purchase order follow up, and screws up the delivery of the whole project.
I understand that system peggs to a different project, because of various reasons, and delivery date of the project could be one of the reason. but my question here is , when there is marking established during firming, still how it can allocate to a different project? then is it overwrites marking? or do I need to use extended marking instead of standard marking? (if you could me an example for the Difference of Standard marking and Extended marking” it would be really helpful).
so what I should do , to keep the same pegging as it is? – this is what is my one line question?
Running Net change would solve the problem?
And the final question is that , does the Action message base date “Requirement date or Future date” is considered for “Decrease actions”. Because we have enabled only decrease action on action messages , whether this is having any implication on change of pegging?
Please throw some lights. and many thanks in advance.
Awaiting for your reply. Thanks again.
Sorry for delay. First of all – MRP it totally project agnostic. It does not know anything about projects functionality and it plans it the same way as usual orders. Also, MRP itself certainly do not change coverage data created from marking information.
When your managers update explosion, they check ‘delete reservation and marking’ checkbox, which simply leads to deletion of marking information. You can try to put some kind of logging code into inventTrans::deleteMarking() function and then check when it is called. (I once made something similar – I was logging into a new table calling user and call stack. It helped me to diagnose the problem).
I do not think that changing planning mode from Regenration to Net Change can help. I am 95% sure that the root cause lays not in MRP itself, but in loss of marking during daily operations.
Speaking about the difference between Standard and extended marking. In many cases, marking, in turn is mirrored into the order line. Say – in purchase line you have three fields – Reference Type, Reference Id and Reference Lot. They can point to production BOM Line or sales order line for which the purchase line is intended. In Standard marking mode these fields are set ONLY if marking is made for full quantity (like 20 pieces in purchase line and full 20 pieces are marked). In extended mode these fields are set even if marking is made for partial quantity. (Do not ask me what will happen if you mark inventTrans to several different inventTrans. Perhaps, it will set reference fields in source order to the last target inventory transactions)…
I do not have too much experienc with Decrease action setting, you mentioned. I am only sure that firming is totally independent from the planning itself. Firming only takes planned order (or chain of planned orders in case of nested productions), and create orders for them. It does not check anything in actions messages.
Many thanks again for the reply.
I am now clear about the Standard and Extended Marking, and I have faced the similar issues of losing the reference at the production line level if the Marked Qty is different than the required qty. which i need to control through Extended marking henceforth.
But now my main pain, is changing of the pegging. where I was believing that Net change would 90% solve the problem, as it won’t touch the demand itself once it is planned with the supplies, unless otherwise if some of the below is changed on the demand:
2. Inventory dimensions (Site,Warehouse)
3. BOM amendments
4. Delivery date of the demand
hence there won’t be any problem once the orders are firmed and pegged to the project, and the project will not be planned again. please give your suggestion on this. I am sorry to ask the same question again and again, as I am really screwed up because of this.
And for the Marking removal, we don’t update the explosion and we only view the explosion and then go to the Planned orders from there to firm them, hence there is no way that the marking is getting deleted in our scenario, and I am claiming that the regeneration is removing the marking which eventually leads to changing of pegging, depends on the delivery date, etc.. Please clarify this.
Finally currently I am generating a material shortage report from Explosion > Critical on hand inventory and other details from explosion form. But this has to be done by each and every single line item > Explosion, which is really a time consuming job from the end user point of view.. Is there any way that I can customize this for multiple Project item requirements/Sales orders, and please provide your suggestion to customize the same, as our techies are finding it is nearly impossible, hence please throw some lights.
Awaiting your reply. And many thanks again.
if you don’t mind can i have your mobile number or Skype Id please, just to get some more clarifications on overall Master planning.
Perhaps, Net Change minimized can solve your problems, but it can solve them at the cost: If your item has ‘Period’ coverage mode, then Net Change won’t group your requirements properly and you will have several planned orders instead of one.
Speaking of your situation in general – I see two possibilities: 1. Something is removing your marking. Can you test the following scenario: Find out couple of messed up net requirements and check marking data of their inventory transactions. (Of course, I mean – net requirements from real orders, not planned ones).If these markings are messed up the same as net requirements, then we are dealing with completely different situation: It is not the MRP which is causing your problems, but some unknown functionality in logistics, which is re-wiring your markings. (And you will need to try to catch it…). 2. Another possibility is that your MRP is modified by some vertial solution or customized function. Normally MRP never ignores marking and it never deletes it. The only place in MRP module which actually can change something in inventory transactions is autofirming. (But I guess you do not use it).But even if you use auto-firming, it should not change existing markings, but only create marking for new orders.
Speaking about explosion problem – I once created feature, which I call ‘static explosion’. It runs after normal MRP regeneration (and it takes about 20-30 mins to run for the plan with 300000 net requirements). After run it saves the table which lists all orders/planned orders, which are necessary to fulfill for given salesLine. Now in our sales table form we have a grid with the list of orders to complete for given salesLine and in our orders we have a grid with the list of sales lines, depending on the order’s execution. Of course, if you are updating explosion or running partial MRP during day time, this static explosion data become obsolete (and you usually do not want to run it after every plan update). Nevertheless, it still usefull, because for 99% of of orders, partial scheduling or explosion update does not change the situation significantly.
This article is great! I’m still fairly new to AX so some of it is a little beyond me, but we’ve been having an issue with our MRP lately (2009 btw) so I’ve been trying to gain a better understand of what exactly its doing, but perhaps you could help?
Basically we have been running static MRP regen every night for a long while now with little to no issues, but as of the other day, it suddenly takes a 1/3 of the time to finish, has no errors and basically seems like it just drops out. It doesn’t finish processing order lines…doing only ~2000 or so when it should be doing ~11000. Hence its only able to process a relative handful of items inventory.
I found another person with a similar issue, but he had blank itemid in the inventtable, this however, we do not have.
Any assistance would be appreciated! Thanks again!
If you are sure that you do not have any error messages, I can give you only one advise: Try to delete all saved data (sysLastValue table) for the user which runs nightly MRP. I saw (about 5-6 times), situation when after someone ran partial MRP (I mean – batch mode MRP for only several item/item groups/etc), saved query somehow stuck in saved data. When you run MRP in multi-threaded mode, system passes info between main thread and helper-threads in the saved data. Somehow, this mechanism breaks somehow and system keeps old data with saved PARTIAL MRP query and reuse it on every run. It ends up in miscommunication between main thread and helper threads. Usually it ends up with MRP executed only for part of the items.
is there any way to set parameters or plan up, to schedule and reserve capacity on work center with finite material while MRP is running? When I run reschedule PO and mark finite materaials, results are OK.
Thanks for your reply!
We ended up figuring it out, we took a few steps so without further testing in our copied test environment, I am unsure exactly which worked.
1- We did clear usage data from the account running the job, like you mentioned (I believe this to be a direct correlation with deleting that users rows from the SysLastValue table). We actually had done that much earlier in the troubleshooting process, and did not fix it…but did it again for good measure.
2- Deleted unfinished scheduling processes
3- And finally, ended up just recreated the nightly batch job and just changed the user it runs under…which would nullify #1s effect I suppose.
I’m just glad to have it back to normal again! Appreciated!
Hi Denis – thanks for a great article. I hope you can help with an issue we have. We are running Ax 2012 R2 and also do a full (regeneration) MRP run every night through a batch job. The batch job return with some errors like:
“Cannot delete a record in Net requirements (ReqTrans).
An update conflict occurred due to another user process deleting the record or changing one or more fields in the record.”
When I look at the log / session log, it seems that the MRP has run completely. However, on some items, when you want to look at the net requirements (either through the item or works orders) we receive the same error as above.
My next step is to clear the usage data of the user that runs the job, clear the unfinished (error) process and re-create the batch job.
Any other ideas? Mutch appreciated.
Hi Dennis, thanks for a great article. I hope that you can help me with an issue we have running MRP. We run a full regeneration every night in a batch job, but receive the following error message:
“Cannot delete a record in Net requirements (ReqTrans). an update conflict occurred due to another user process deleting the record or changing one or more fields in the record.”
Even, for some items, selecting the Nett requirements, we receive this error. We are running Ax 2012 R2 Cu6.
Any help would be appreciated!
We are running Dynamics AX 2009. We also regen MRP every night. My question is with Min/Max. While looking at the MRP action items, it is telling me to move the demand out for the min/max to the very last demand found. How can we set it up so the Min/Max is shown as a demand today?
Great article! There are so many things really hard to understand in MRP functionality and you give some light here 🙂 so now I have new doubts.
We are using the same plan for static and dynamic mrp. We run the regen master plan every night and normally run explosion for every working order before releasing them. What are your thoughts about this?
Thanks a lot!!
I am running MRP for the whole demand with Regeration, I run during the night.. my issues are that I don’t want to include the BOM Lines because for us BOM Lines are not yet a productive lines until it gets converted into Production Order. Second I want to stop the lines in the item requirements for sometime until we consolidate the requirement. For this purpose we have customized a field with the status “Draft”, once it is approved we change it to “For Procurement”. How to handle this? anyone can has any suggestion?
Thank you for a great blog.
I have been investigating MRP today, because I have an odd problem with Ax 2012 R3. The problem is, that the MRP works fine as long as the sales orders aren’t posted. When I post the sales order to an invoice – then the sales-lines are not collected by the MRP-form and the SalesForecastQty is therefore not taking the Invoiced SalesLine into account when summing up the SalesForecastQty.
It seems quite sophisticated to figure out how the source-data is transformed into ReqTrans. My goal is actually to find out how come these invoiced saleslines aren’t taken into account. I know that the data is fetched for invoices if I make a similar setup in 2012 RTM. I might have overlooked a setting. Do you have an idea, what I miss ?
A very informative blog. Thank you!
I have a question for you.(AX2012 R2)
We are seeing a strange issue when trying to firm planned production orders at one of our clients. Sometimes the error message states that “the item does not exist”, and others, that “the planned order does not exist”. It is impossible to replicate, in their Test environment, and Microsoft have not been much help. The client runs a Dynamic Plan and a Static Plan. Have you seen this elsewhere?
This was really helpful. I got another case, if you had any experience, I will apprreciate your comments.
Here is the case:
We’d like to run the planning and use planned messages only for material level. We have firmed production plan in Excel and want to explode to sub-assembly and materials as is (do not take on hand/transactions into consideration). But on material level we want to include on hand/open transactions.
e.g. Plan the item X (Finished Good)as is, explode the item Z (Sub Assmebly) as is (do not include on hand/transactions), calculate requirements for items Y, Z1 and Z2 (Materials – include on hand/transactions).
What is the best way to implement this? I have tried several ways (different master plan versions, firmed planned orders and rerun MRP, run MP once go change parameters and select only materials and run again,…) but it does not look OK.
Any suggestions/experiences will be appreciated.
1. Most obvious approach: If you import your production plan from excel as a bunch of production orders (not planned, real production orders), you can mark order lines to another orders. In this case, normal coverage planning will be skipped and coverage will be build from marking info. I am not sure whatever it is suitable for your task, but if you are trying to import plan from APS, it can work.
2. You can modify method RecCalc.InsertItemInventSum(). In the very beginning it calls reqPlanData.useInventOnHands() to find whatever on-hand data should be imported. You can get itemId from Setup variable (it is an instance of ReqSetup class). Then you can somehow decide whatever you want or not to import on-hand for this specific item.
3. You can create dummy inventory journal before planning and reserve all your on-hand for this journal. if you have reserved inventory transactions, their net requirements are covered (by default) by on-hand stock. This way you can prevent on-hand stock from being used to cover normal net requirements.
I would prefer way 2, of course. It seems to be the easiest.
Есть вопросы но по 365, так как на старости лет пришлось встретиться с этим чУдным произведением МС.
И все таки зачем нужна эта странная таблица inventSumLogTTS . Я все таки на практике ее всегда очищал под НОЛЬ, т.к. она увеличивала время выполнения сводного планирования, но в 365 появилось еще множество не понятных таблиц, которые рекомендуют чистить, например эти:
MSFT Script example (performance gains are possible)
/*Only run these scripts when no one is running MRP*/
/*Delete Batch Thread process records*/
select COUNT(*) from reqprocessitem
select COUNT(*) from reqcalctask
select COUNT(*) from reqcalctasksbundle
select COUNT(*) from requnscheduledorders
/*If there is data in the inactive master plan versions. All data related to inactive plan versions can be safely cleaned up.
FYI – The data in the following tables should have been automatically be cleaned up via a batch job after MRP completes*/
select COUNT(*) from reqtrans where planversion in (select recid from reqplanversion where active = 0)
select COUNT(*) from reqtranscov where planversion in (select recid from reqplanversion where active = 0)
select COUNT(*) from reqpo where planversion in (select recid from reqplanversion where active = 0)
select COUNT(*) from reqroute where planversion in (select recid from reqplanversion where active = 0)
select COUNT(*) from reqroutejob where planversion in (select recid from reqplanversion where active = 0)
select COUNT(*) from wrkctrcapres where planversion in (select recid from reqplanversion where active = 0)
select COUNT(*) from reqplanversion where active = 0
/*There may be some data that is missing a valid plan versions Header Record all together. (Ie Orphaned records)
The data in the following tables should have been automatically be cleaned up via a batch job after MRP completes*/
select COUNT(*) from reqtrans where planversion not in (select recid from reqplanversion)
select COUNT(*) from reqtranscov where planversion not in (select recid from reqplanversion)
select COUNT(*) from reqpo where planversion not in (select recid from reqplanversion)
select COUNT(*) from reqroute where planversion not in (select recid from reqplanversion)
select COUNT(*) from reqroutejob where planversion not in (select recid from reqplanversion)
select COUNT(*) from wrkctrcapres where planversion 0 and planversion not in (select recid from reqplanversion)
delete from reqtrans where planversion in (select recid from reqplanversion where active = 0)
delete from reqtranscov where planversion in (select recid from reqplanversion where active = 0)
delete from reqpo where planversion in (select recid from reqplanversion where active = 0)
delete from reqroute where planversion in (select recid from reqplanversion where active = 0)
delete from reqroutejob where planversion in (select recid from reqplanversion where active = 0)
delete from wrkctrcapre swhere planversion in (select recid from reqplanversion where active = 0)
delete from reqplanversion where active = 0
delete from reqtrans where planversion not in (select recid from reqplanversion)
delete from reqtranscov where planversion not in (select recid from reqplanversion)
delete from reqpo where planversion not in (select recid from reqplanversion)
delete from reqroute where planversion not in (select recid from reqplanversion)
delete from reqroutejob where planversion not in (select recid from reqplanversion)
delete from wrkctrcapres where planversion 0 and planversion not in (select recid from reqplanversion)
Что скажешь? Надо с ними бороться или нет?
В общем – inventSumLogTTS, это табличка, в которой накапливается информация об изменении ситуации на складе (в первом приближении). Когда мы запускаем пересчет плана в режиме регенерации, эта табличка чиститься. Дальше – по мере изменения складских проводок, эти изменения записываются в inventSumLogTTS. А когда ты запускаешь пересчет плана в режиме Net Change, система просто эти изменения применяет к динамическому плану, вычищает их из inventSumLogTTS, а потом пересчитывает покрытие. Если ты только регенерацией плана пользуешься, то можно эту табличку чистить. Хотя большого смысла в этом нету, потому что перед рассчето каждой номенклатуры в режиме регенерации, система эти данные и так удаляет. Таблички reqProcessItem, reqCalcTask, ReqCalcTaskBundle, reqUnscheduledOrders, это артефакты системы синхронизации и распараллеливания планирования, которая работает при режиме планирования с хелперами (когда у тебя много батчей параллельно покрытие считают например). Если у тебя планирование завершилось с ошибкой, то данные в этих таблица остаются. Если у тебя одна сессия планирования померла, то можно просто зайти в форму Master Planning->Inquiries and reports->Master planning->Unfinished planning processes и оттуда через интерфейс удалить все эти артефакты. Если клиент у тебя очень долго там ничего не чистил, то можно через SQL Server удалить напрямую коммандами “delete Reqprocessitem delete reqcalctask delete reqcalctasksbundle delete requnscheduledorders”. Я тоже так иногда делаю, потому что это реально может давать прирост производительности планирования. Важно: Даже если ты не пользуешься хелперами в сводном, при запуске сводного из периодических операций, данные в этих таблицах все-равно создаются.
Все остальные delete из микрософтовского скрипта, полезны только в очень экзотических ситуациях, когда кто-то с кривыми руками и кучей джобиков удалил данные о версиях плана, не удалив перед этим, относящиеся к данной версии плана чистые потребности, плановые заказы, резервирование мощностей и тп. Если эти скрипты запустить, особого вреда не будет, но в целом – я пока не встречал бы клиента или партнера с настолько кривыми руками, чтобы данные сводного планирования так испортить.
Leave a comment