Dynamics F/SCM Customer Experience (CRM) Dynamics GP Dynamics Business Central (NAV) Dynamics SL Power Platform Fabric Copilot

[Jeff Henry]

We currently run AX 2012 R3 CU11 with AWAX and ATRAX

During a recent cost roll-up, I found that some of our component items were missed because they were assigned the wrong costing level.  And, as an aside, Master Planning regularly misses some items (we never knew why until now) and, after looking into those items, I found that the BOM levels on those items are wrong, too.
 
From what I’ve read in this forum and blogs elsewhere, it’s clear that this isn’t a new problem.  What isn’t clear is what people have used as a solution.  Has anyone else encountered this problem, and if so, how did your organization deal with it?  And, does anyone know if this is still an issue in D365?
 
One more bit of information:
We use lots predefined Product variants, and have lots of variability within the same Product master:
For example, in most cases, the same Product master has variants that are purchased, make to order, or are regular production items with deep BOMs – including phantom BOMs.; so, Item coverage does a lot of work in our setup.

——————————
Jeff Henry
Kai USA Ltd
Tualatin OR
——————————

[Kevin McLean]

You’ve probably already run the batch job to recalculate BOM levels.  You should make sure that you’ve set a couple of configuration switches:

• There is a setting on BOM tab of the inventory management parameters for the optimize circularity check for low or high complexity.  I do not know if that will affect the setting of the BOM level, but you should definitely set that for high complexity.  
• There is a setting on the costing fast tab of the released products form to allow separate costs by variant.  You should have that checked for anything that has product variants.  

Microsoft did add some functionality to help manage the situation that you appear to have: variants of an item that might be parents or components of each other.  I don’t remember when that was added.  It might have been as early as CU 11 or as late as CU 13.  The main component of the enhancement is a new table: ReqItemLevel.  That table is keyed by a combination of:

• Item product dimensions
• Item number
• Inventory dimension

It holds the level code for planning purposes, and lets you have different level codes for the same item with different item dimensions.  I have seen problems with that table that were caused by having the same item with the same dimensions on the production order header and the production BOM (rework production order). I was able to fix the problem by deleting the production order after it was ended, and then purging the table.  If the table is completely empty, master scheduling will rebuild it.  

You might check to see if you have that table, and see what the level codes are for the different variants of your problem items.  If they look bad, you should consider purging the table.  I’d plan that for a weekend, because the master scheduling run that rebuilds it will take much longer than usual.  If you can’t find the table, you should consider upgrading to a newer cumulative update.  I’m not sure if D365 has the same functions.  I just checked and cannot find ReqItemLevel in D365.  That does not mean that Microsoft has not incorporated the  same function in some other way, but you’ll want to conduct a more thorough analysis before you migrate.

——————————
Kevin McLean
Strategic Solutions NW
Beaverton OR
——————————
——————————————-

[Jeff Henry]

Kevin,

Thank you for your reply – we appreciate it very much.

We’ve already done most of what you’ve suggested:

• We’ve run the batch job to recalculate BOM levels
• Our Circularity check strategy in Inventory management parameters is set to Optimize for high complexity
• We allow cost price by variant
• We’ve deleted re-work production orders (in our test environment) and,
• ReqItemLevel is present in our system and, it dutifully records the wrong BOM level for some items

The only thing we haven’t done is purge the BOM levels from ReqItemLevel. We’ll give that a try in a test environment and let you know how it goes.  If it works, in the short term, unless we change how we do re-work, it’s only a partial solution; the problem may return the next time we run a re-work production order.  

If purging the BOM level for affected items from ReqItemLevel works, in the future, I suppose we can avoid the problem by changing the way we do re-work – we could release new, non-standard components (probably just a re-work variant) for use in re-work production orders.

Thanks again for the information.
#FinanceandOperations

——————————
Jeff Henry
Kai USA Ltd
Tualatin OR
——————————
——————————————-

[Kevin McLean]

Just to be clear, you have to purge the whole table to get a line rebuilt.  It  won’t rebuild for a single item if the table  is not empty.

——————————
Kevin McLean
Strategic Solutions NW
Beaverton OR
——————————
——————————————-

[Jeff Henry]

Kevin,

Got it.  Thank you for that clarification.

——————————
Jeff Henry
Kai USA Ltd
Tualatin OR
——————————
——————————————-

[Kevin McLean]

You’re correct.  Sorry, I’m trying to juggle a couple of things here, and I was not paying as much attention to what I was reading as I should have been.

——————————
Kevin McLean
Strategic Solutions NW
Beaverton OR
——————————
——————————————-

[Kevin McLean]

A second thought just occurred to me.  You might be able to use one of the product dimensions to hold a value to indicate material to rework.  You’d have to use a BOM journal to convert the bad item produced by a production order to an item to be reworked, but then you could create the rework order consuming a component with one dimension, and producing a good finished good with the standard dimension.  

I’ve always liked using rework orders to consume and produce the same item.  You get the timing of the movement from and to inventory for MRP, the right variances for finance, and capacity reservations for scheduling.  I’d like to think that there is more coming to flesh out this functionality.

——————————
Kevin McLean
Strategic Solutions NW
Beaverton OR
——————————
——————————————-

[Dave Phillips]

Hi – 

In MRP calculations, PRODBOM can also throw off Levels especially in rework scenarios. Rare situations where someone changes the data in a Production BOM.

Do missing Items show up in Net Requirements but not in a full regen of MRP?

Do Level issues seem to come and go? Perhaps when Production Orders (Batch) are Ended?

Thanks…..Dave

——————————
Dave Phillips
Sr Support Escalation Engineer
Microsoft
Fargo ND
——————————
——————————————-

[Kevin McLean]

Here’s what I saw in AX 2012-, CU13.

Creating a rework order with the same item on the production BOM and the production order increased the value of the level in ReqItemLevel by 1, which had the effect of moving the item down 1 level.  From that point on, the components of that item were no longer planned if two conditions were true:

• The item number of the component had a lower value than the item number of the parent.  I believe the sequence of the master scheduling job planned by item number within level, so that the component was correctly planned if it was planned after the parent.
• The full plan was deleted and regenerated.  The component  would re-plan correctly if the master schedule for the component was regenerated from the net requirements form.  

It appeared that what was happening was that the change in the level on the parent meant that it was no longer planning before the component, so the component demand linked to a planned order for the parent was not reflected in the demand profile of the component.  

The level change persisted after the rework order was ended.  The only way I could find to fix the problem was to delete the rework orders, which got rid of the problem production BOM records, and then delete all records in ReqItemLevel.  ReqItemLevel was then rebuilt with correct values, and component items planned correctly again.

——————————
Kevin McLean
Strategic Solutions NW
Beaverton OR
——————————
——————————————-

[Dave Phillips]

Hi Kevin – 

Nice digging.

If you have a consistent repro you should get a ticket entered with MSFT.

The simpler and better documented the repro the faster tickets go.

Thanks…..Dave

——————————
Dave Phillips
Sr Support Escalation Engineer
Microsoft
Fargo ND
——————————
——————————————-

[Jeff Henry]

Kevin,

One more bit of info, and a question:

We’ve found that it’s not necessary to have the parent and the component at different levels.  The same thing happens (and is more likely) when the parent and the component are on the same level. 

Would a ticket to MS be in order if the problem is already addressed in CU13?

——————————
Jeff Henry
Kai USA Ltd
Tualatin OR
——————————
——————————————-

[Kevin McLean]

The parent and component should never be at the same level, because that risks the component being planned before the parent.  I would enter the ticket.  I don’t think CU13 deals with the problem completely.

——————————
Kevin McLean
Strategic Solutions NW
Beaverton OR
——————————
——————————————-

[Jeff Henry]

Kevin,

Thank you for the technical information and for your advice. We appreciate that very much.

——————————
Jeff Henry
Kai USA Ltd
Tualatin OR
——————————
——————————————-

[Jeff Henry]

Dave,

That’s correct – missing items show up in Net requirements.

Net requirements calculates demand for the item(s), but Master planning doesn’t produce planned orders to cover that demand.

We run a simple SQL query to find these items.  It returns any item whose net requirements, plus planned orders is less than zero

I haven’t noticed that the level issues come and go.

——————————
Jeff Henry
Kai USA Ltd
Tualatin OR
——————————
——————————————-

[Dave Phillips]

Hi – 

If you have a solid repro a ticket would be best.

Also, side observation, on missing Items and Net Requirements, check for expired Batches.

Lastly, anyone thinking of CU13, there is a later version of CU13 called “February 2019”. See, https://cloudblogs.microsoft.com/dynamics365/no-audience/2012/03/29/overview-of-microsoft-dynamics-ax-build-numbers/.

Thanks…..Dave

——————————
Dave Phillips
Sr Support Escalation Engineer
Microsoft
Fargo ND
——————————
——————————————-

[Jeff Henry]

Dave,

Thank you for the info on “February 2019”, and the expiry dates for batches.  We’ll get a ticket in with MS.

——————————
Jeff Henry
Kai USA Ltd
Tualatin OR
——————————
——————————————-

[Jeff Henry]

Dave and Kevin,

So, following up after testing your suggestions:

We successfully corrected our BOM levels by:

• Deleting all production orders where any child part had the exact same Item# and dimensions as the parent
• Then purging ReqItemLevel
• Running the Recalculate BOM levels utility.

We had only one surprise.  We ran Master Scheduling after purging ReqItemLevel and all our re-work production orders – that repopulated the BOM levels, but they were still wrong . . . So, I ran the Recalculate BOM levels utility and, that corrected them.

Items plan and rollup correctly now.  Thanks again for your help!

——————————
Jeff Henry
Kai USA Ltd
Tualatin OR
——————————
——————————————-

[Kevin McLean]

You’re welcome.

——————————
Kevin McLean
Strategic Solutions NW
Beaverton OR
——————————
——————————————-