We have only one active site in Epicor currently. There were no parts in our company before go-live so all were loaded via DMT. There are 18,500 ish parts in total. I am the only person who can add parts and modify parts as teams only have access to SO Entry, Shipment Entry etc.
Out of those total 18,500 parts, 13,500 exist in only the active site but 5,000 exist in both sites. I have double checked my go-live DMT and also my current DMTs to add parts but all reference the one site. Any ideas how parts are being added to the other site? We are just buying and selling parts so no jobs.
Are these unwanted 5,000 PartPlant records definitely emerging/growing over time? Or do you think they could have been created somehow during the initial DMT imports (but not noticed until later)?
Transactions can create PartPlant records. I don’t have a good memory of which ones, but they are there. For example, the bug with RMAs:
The bug isn’t the PartPlant record getting created automatically. The bug was no PartCost record.
Personally I block this in a functional way by blocking transactions for zero standard cost (with some exceptions, long story). But that only makes sense for std. costing, of course.
Thanks again Jason. Your post is very helpful. Now I am aware the real fix for costs issues due to your lessons from dealing with support. We are very small on the number of RMA transactions so there is something else create the part record. Will post when I find out what in my specific instance.
DMT assumes you are operating in the site that was last used by the user.
What probably happened was that you were in the main site in the E10 Client UI, and then used DMT to upload parts. Those 13,500 went in with the part plant defaulting to the current site (your main site).
In the UI you switched to the other site for something, and then used DMT to upload the next 5,000 parts. These 5,000 were created with the alternate site as their default part plant.
Note that whatever site you are in in the UI (or were last in when you closed the E10 Client) that is the site that DMT will use.
There’s a topic on this site about switch sites via DMT. I think it takes some trickery to do so.
Also, Does the DMT UI allow displaying the site your connected to in the status bar like the E10 client does? If so, enable that so you can always tell.
edit
You might want to experiment to see how a DMT session manages which site it is in. When you launch the client, it automatically starts in the site you (your user id) were last in. When you change sites, that is probably instantly saved to your user profile. If you opened another client session I’d bet that it would start in the site you switched to. And a DMT session interfaces to the App server just like a client session would.
The million dollar question is what happens in the following scenario:
Launch E10 client and it starts in site A (the site I was in when I last closed the client program)
Launch DMT (the user interface version) - I assume its session is also using site A
In the client switch to to site B
Is the DMT session know going to use site B?
Will it maintain using site A as long as the DMT UI is open?
If I closed the DMT session then re-opened it, I think it would start in site B.
I have reviewed further and still not making much sense as to the cause.
Calvin - I can see how the process you outlined would be applicable but in Live I stay in one site in the client as there is no activity in the other site i.e. no SO or POs.
When I ran a report to show when the parts were created the Excel date filter showed something interesting:
There are big chunks of time where all is ok i.e. February & April but for 7 days in March the issue was happening.
I tried to delete a part from the MfgSys as a test but Epicor said no due to transactions. Running part history transaction tracker there was the initial cost adjustment as a transaction in MfgSys.
Okay, going talk out loud a bit. You probably know most of the following. But maybe it’ll jog some thoughts…
From what I understand, when creating a new part (via part maintenance, as opposed to something like the configurator making it), the Part table record is created as well as a PartPlant record for the site that Part maintenance was launched from). To use that part in other plants, you need to add the plant from within part maintenance. Some of the PartPlant settings for the new plant will be copied from the part record (like cost method).
As long as no part transactions have been applied(even ones that “do nothing” like setting the cost of a part with zero QOH), you should be able to delete the part entry.
You might be able to add another plant, and delete the first one.
DMT should work the same way as the UI.
Did your DMT file have lots of columns, or just the basic / minimal required ones?
Anything different about the way the two sites are setup? Something that might cause the other site to be used by default?
One odd thing I’ve seen happen is that if a POTF (part on the fly) was used on an order or PO, and then a part entry created for that part, some properties of the new part record will default what was used on the order. For example, the line on the order (when it was a PTOF) was for 50 LB. But when you go to make the part, you want it to be a UOM of EA (as it will be the count of 50 LB bags). There will be problems because of the inconsistent UOM classes (assuming one is COUNT and the other is WEIGHT)
Thanks for the info Calvin. This is an odd one so I appreciate all the info. My DMT templates remained the same throughout December, Partplant was updated to add a new part to two warehouses in Jan and then back to one around June. Partplant, PlantWarehouse & Partcost DMTs only ever referenced the active site. DMT are pretty minimal and just state required plus a couple of fields. I have a sneaking suspicion the partplant DMT with 2x W/H may be the cause due to the dates in the Excel report. This whole item has been a bit of shock and was due to me investigating streamlining the process of splitting the Part master search between the two sites. Because of this issue I will have to change tact and will implement Tim Shuwy’s record level security on the part master. I had thought of adding a dummy site but thought there would be more risk.
It might be from the fact that to setup warehouses you must be in that site. Maybe DMT auto switches the session site, when it needs to do things in a site different thn what it launched in. Then any following DMT uploads would use that site it switched to.
Some things I wish I had known before my initial setup of E10 (even though we were currently on V8).
You will inevitably do something wrong during your setup and data uploads. So make backups of the DB fairly regularly, and use these as “rollback points”. That way when you do something that you find out is irreversible, you could restore the DB from a prior backup, and then carry on from there. Otherwise you may have to delete the DB and start from scratch.
You cannot disable a site. So if you mess one up, don’t think that you’ll just disable that one and create a new one in its place. I don’t know what Epicor expects you to do if your business was to close or sell off a site. You can remove users access to it, but it still resides active in the DB and could cause problems.
Really, really make sure you have your UOM’s setup right, and that you fully understand how UOM’s and UOM Classes work. Changing the UOM on a part can be near impossible to do - and often is.
Don’t import/DMT in any more data than you need. I thought I could just bring in all our parts from V8, and later delete the ones we don’t want. But then I also did a cost update, and that created parttran records for those parts I didn’t really want. And that made them forever undeleteable.
Setup as few as possible codes like ShipVia, PartClass, ProdGrp, Terms, etc … Just because a shipping company offers a “Purple Plus” service (I totally made that up), you don’t (and shouldn’t) make a ShipVia for it. You can always add it later.
Did I mention the UOM’s? Seriously, that can be the biggest problem. We’ve had to inactivate part numbers and make a new one because the UOM was screwed up. This came about mostly due to internal differences of opinion. Like if a 10’ length of pipe with a male end and female end (think the old sewer pipe with one end like a bell shape), is sold by the foot or each 10’ length is a unit. To gett 120 FT of pipe, you’d need either 120 FT or 12 EA.
Don’t let the GL Acct program automatically create the accounts. It will make an Acct for every combo of Div, Dept, and Chart. And I’m pretty sure most company will only have one Inventory acct for the company (or one per each Div/Plant). But they won’t need one for each department. No need to search through hundreds of bogus accounts when searching for an account. If you do let it make them automatically, go back and delete (or deactivate) the ones that shouldn’t exist.
I’m sure there’s lots more, but that’s the most important ones (at least to me).
Thanks so much for the info Calvin. Other than these odd entries going into MfgSys I have made sure no-one is creating data in that site. The UOM piece is something I am aware of but did not get stressed enough by our partner. We discovered early on that shipping a part causes a PPV if there is no cost (don’t want to dive into that!) so all parts with zero cost were made inactive. We are 99% EA for UOM but parts have their UOM checked before making active.
I don’t know if you do this already, but I save every DMT upload that I have ever done. The file and the logs and errors, etc. Well over four thousand files, going back to go-live in 2016. I title them very verbosely, like “Delete unapproved indirect labor from Jan 2021 and earlier.”
Any time anyone asks what happened, I can say what I did - and undo it if need be. I also now have the person do a help ticket for the request.
