I’m curious if anyone else who has parts setup as transfer in some plants has seen this bug we just found. We’re on 10.1.600.20
When we have a manufactured part setup for two plants and the first plant in our list is setup to be transferred to and the second plant in our list is the manufacturing one, a change in the Sales Unit Price on the Part record changes the first plant (that’s setup as transfer source type) to manufacture.
The means by which the change occurs is on exit from the form after change of price and after save (per screenshot), it asks if you want to save changes… despite the fact that I didn’t do any change after the Sales Unit Price change.
I agree with @Jason_Woods… I just tried this in E10.2.200, and it didn’t happen. I have never heard of this type of thing and I have been on Epicor since the Vantage 8.0 days (and a little Vantage 6)… The only thing that touches the PartPlant table is when you change one of the Default Site Parameters, and even then, it asks you if you want to.
Check for Part.Update Method BPMs, or in Data Directives on the Part table. Also check for a customization to the Part Entry UI.
Thanks for your responses Jason and Tim.
I set the webconfig file enable customizations to false per post below, and recycled the app pool.
After that I ran in base mode on customization. I checked that some known bpms didn’t run, so I assumed that the webconfig change turned the bpms off. Whaddya think?
In further testing, I have found that it doesn’t matter if the Part is setup on main detail page as P or M. I need two sites and the first one in the list needs to be the transfer one. Then a change in Sales Unit Price, and subsequent save, causes the first site to get its sourcetype changed to agree with the Part detail when user exits out of Part Entry and it unexpectedly asks user if they want to save changes… this is despite having saved the sales unit price change already.
You might try contacting Tech Support to see if this was a known bug in that version… if it was, then maybe there is a hotfix? if not, I cannot replicate it on a later version, so Tech support may need further investigation.
I can’t confirm this per se, but I’ll tell you, I sure want this to be true. I think we might be experiencing the same thing. I have seen many parts where I was sure I had set it up as transfer. And I loaded prices after the initial go-live of another site in February.
Complete tangent here, but I’ll tell you what I have seen.
I have two (of many) UD fields on Project called
Line Start Date
Gold Sticker Date
The QA Manager updates the Gold Sticker date (but not the other one).
I made an updatable dashboard for QA that can only update that field. (And QA has no rights to Project Entry.)
Sometimes when he updates the Gold Sticker date, the Line Start Date gets wiped out. The change logs prove it.
Well, that used to happen, until I made a BPM called “Stop it, James,” (that’s his name) and it blocks the update and the dashboard turns red on that row.
I did some digging. I can’t find causality, but I see the change.
On Feb 1, I loaded 466 parts (PartPlant records) as SourceType T (transfer)
Development environment is from a backup on Feb 26, all 466 parts still SourceType T.
Today, not a single one of those parts is SourceType T.
Wow I didn’t realize it was that extreme. Yeah, something is fishy.
Unfortunately, though, I don’t see the link to the pricing. Prices in Development environment are the same as Production.
We are using pricing for the first time ever, though. Before Feb 1 we sold only trucks and trailers, and all build-to-order, so there was no set pricing in Epicor for us. But now our service center is on Epicor and they sell parts with a list price, and we have done a lot of work in that area. So I’m trying to keep some hope alive.
Since I have a complete and total wipeout, I just looked through all my DMT uploads since Feb 26 (I keep them all in a folder). The only mass update I did that hit all of those part numbers was to populate a UD field that I recently created on PartPlant. (It’s a legacy date from the old system.)
That doesn’t tell you anything, but I just wanted to close the loop on my end.
I can confirm this is a bug just based on the code, I wasn’t able to fully duplicate it since it is fixed in the latest 10.1.600 version, and latest 10.1.500 doesn’t trigger the “Confirm changes” message on exit.
Basically if the part has 2 or more Plants, any change will update the PartPlant record of the current Plant(not necessarily the first one or the one setup as Transfer) and it copies the type among a few other properties from Part to PartPlant.
The workaround is to simply click No on the confirmation message, the unit price change is already saved, what you are confirming are most likely the PartPlant changes.
One other comment here… I rarely suggest that companies actually use the Sales price on the Part table. The main reason is that that field is the fallback for if the part does not have a price in any pricelist.
I would rather have a pricelist that is editable without going to the Part table, and have all saleable parts in the pricelist. This allows better control over who can edit the parts in the part table. Also, it is easier to upload a pricelist, as you dont need to have access to DMT tool.
You don’t know how many times I have added a UD Field called Part.Saleable_c to the database… then affixed a BPM to the sales order to actually enforce it.
But now, I realize that this should be in the PartPlant instead of Part, because in a multi-site environment, sometimes a part is saleable in some sites but not others. Hereafter I will always suggest PartPlant.Saleable_c for where it goes.
