Part delete

Epicor ERP 9
1

Epicor version 9.05.701

We have approx 17,000 parts in our database.
We think we actually only use about 3,000 and we’d like to tidy our database up.

  1. Is there a report that tells you if the part has been used previously?
  2. If i ran a DMT to delete all parts, would it only delete the ones that had never been used? (assuming it can’t delete ones with a transaction against it).

What is the best approach for this?
Many thanks in advance.

2

That’s a good question. I am guessing that you need to do a Database Purge and summarize of any related transactions first…and of course backup first…and test in your test environment before performing on Production.

E10 has this, but not sure what it is like in 9 as I have never run it. Perhaps it’s time to look at it.

image.png1366×768 57.2 KB

1 Like
3

DMT would be, in my opinion, the best choice since it is subject to the same business objects as a user in the screen. A part cannot be deleted if it has transactions, has a BOM or is on a BOM. There are some other hurdles too (like if the part is on a quote, order, job, PO, etc.). DMT will run slowly during the deletion process since the same BO’s are being called and then each error message needs to be written to the screen and error log.

1 Like
4

Mark,
I misread your question. I read it as you had run the delete via the DMT… Matt is correct the DMT will error out on those parts that have business object referential integrity, although it really should be in the database design.

From my post I was assuming you had a lot of parts you wanted to get rid of (14000 odd) and they had old transactions that you were happy to remove from the system. The purge may or may not help except for older parts that you are happy to remove the associated transactions related to the relevant parts…I hope that makes sense.

Cheers
Simon

5

Mark,
@mhellwig is right DMT would be a good option. Just keep in mind that your definition of a part not being used and Epicor’s definition of a part not being used might not be the same. So you might want to back up your DB, restore it to a test environment and run your DMT delete against that. This will give you some very valuable data:

  1. How long the process might take.
  2. What will not be deleted (the Error Reprocess file)
  3. Why parts were not deleted (the Error Log)
  4. What will be deleted (Complete Log)

-Rick
www.getaligned.solutions

1 Like
6

Just a side note: I don’t think Epicor would be able to do this in the database design and still be able to do parts-on-the-fly. This leaves the Entity Framework to enforce the integrity.

Mark W.

7

It’s a tricky one I guess, if you were starting totally from scratch then you would be able to squeeze more into the DB design, but Epicor are not.

Not being armed with all of the knowledge of the whole system and the design decisions behind them, I really should not have made that comment. So Mark, as long as there is consistency in the approach of the business rules/data logic then it does not matter that much. The downside is you have to program for it so from a performance standpoint having this sort of stuff in the database design does make sense,

Anyway you are always going to get proponents for each method.

Touching on database design, Those multi-value fields that are concatenated with a ~ have always bugged me.

8

Completely agree. If Epicor was written from scratch and not evolved, I’m sure they would do things differently. Epicor 11 maybe? :wink:

Truth!

Also, SalesRep1, SalesRep2, etc…

Cheers,

Mark W.