Client on 10.1.400.4, getting an error when trying to run “Min Max Safety Mass Update”. Support sent us a fix program “DATA FIX FOR CHANGE REQUEST 13067BRK - - incorrect historical costs and amounts in stock status report”, that (assumedly) cures the symptom… but we’re wondering if the disease will go merrily along and we’ll have to continue running the fix.
This is a multi-company multi-site installation, and in one company (with two sites) there is one part number with entries for both sites but only a PartCost record in one of the sites, and when we try to adjust the cost in the other site that triggers the error. We can’t update that cost record, even by transacting the part.
Questions:
Is this a problem that gets fixed sometime after 10.1.400.4 (we’re upgrading to 10.1.500.x in the hopefully-not-too-distant future)?
Was this some sort of user error at some point in the part creation process (I can’t figure out how that would be, but you never know… those users are endlessly clever)
What does the data fix do? The accompanying text file only references “Plant.PlantCostID Update”
Followup… there are actually six part numbers involved… all of them were originally sold out of Plant 2, given an RMA, and returned to Plant 1 where an RMA-INS transaction occurred. Now none of those 6 part numbers can be cost adjusted, there is no PartCost record in Plant 1.
aidacra
(Nathan your friendly neighborhood Support Engineer)
3
Those questions can be posed to the Support analyst that provided the data fix. They’d really be in the best position to speak to them.
aidacra
(Nathan your friendly neighborhood Support Engineer)
8
Below are the responses to your questions based on a few conversations I had with my counterpart in application support, an inventory support expert who has familiarity with this specific data fix and reviewing our case system for the frequency that this data fix was requested (and for whom). Anything that may be incorrect below is entirely on me.
Questions: Q1. Is this a problem that gets fixed sometime after 10.1.400.4 (we’re upgrading to 10.1.500.x in the hopefully-not-too-distant future)? A1. There is not a specific change in the base product between 10.1.400.x and 10.1.600.x that would prevent the underlying condition. That being said, this is one of those “one and done” data fixes; those that run into it only appear to run into it once based on the data I see. We haven’t sent out this data fix to a customer more than once based on what I am seeing but please see other answers for more context.
Q2. Was this some sort of user error at some point in the part creation process (I can’t figure out how that would be, but you never know… those users are endlessly clever) A2. The underlying data issue may have been present in Epicor 9.05 or earlier depending on what the last major release a customer was live on before 10.1 but didn’t present as a problem because there wasn’t a process that looked directly at the data in question like the min/max safety update feature. This new E10 feature does look directly at it so this underlying data issue issue was exposed . This is my way of saying that the exact cause isn’t known at this time, but, it would appear that the data condition that causes this error isn’t a current issue in the base product on any release that is currently being developed (10.1+).
Q3. What does the data fix do? The accompanying text file only references “Plant.PlantCostID Update” A3: It updates the plantcostid on the erp.plant table with a value that is predefined when the plantcostid is blank.
As the logic to check for this condition is pretty straightforward even for a non inventory expert like myself (if erp.plant.plantcostid = ‘’ then there is an issue) I think it would be a good candidate to add it to our health checker bundle so we can be more proactive with preventing this issue even if it isn’t a relatively common one.
