Reimplement 10.2 using cleaned data

,

I have a 10.1 DB that contains years of garbage in transactional as well master data. I want to use the migration to 10.2 as a opportunity to purge this baggage and start clean with only Parts, Part Classes, Terms, Projects, Jobs, Resources, etc that we use. We would like to keep historical data, and are not opposed to the idea of letting that continue to exist in a reference only DB.
Is there a whitepaper or an article on how to achieve this? Or anything other documentation on DB migration strategies with Epicor in mind?

Thanks!

1 Like

I did this when we moved from E9 to 10.1. Accounting reworked the books, whoever implemented the thing fudged up the UOM, necessitating two definitions of “each” to allow serialization. We geographically and electronically consolidated from multiple sites to one. They gave me six weeks to do it at the end of the calendar year, with go live the first Monday of the year. I was drinking champagne straight from the bottle while hunched over my laptop as the ball dropped in NYC. Everything worked on go-live day, but it was a close call.

First thing, be very sure you want to go this route. Junk transactions, old parts, meh. Not a good enough reason. You’ll build up more cruft anyway. I’d really only go this route if your A) you botched implementation in some irreversible way or B) your organization changed in a fundamental way.

Second, get everything cleaned up. Close out old sales orders, jobs, Vendor PO’s, Projects, etc. Start now and keep on top of people to keep it clean.

Third, get very familiar with DMT. There is actually a “migration” option in the tree view that walks you through the various phases of dumping data into the system. Go through each item, figure out which one’s you’ll need to run, prepare ETL documents to load in. And test, test, test. Particularly on the transactional stuff.

Because DMT doesn’t always fail in an obvious way. It will (or did at the time), for example, renumber sales order releases instead of following your input release number. It also didn’t let me import closed order lines in one go. To keep everything consistent from E9 to E10 I had to import all the open SO’s, then run a second import to close the lines. Stuff like that…for everything.

2 Likes

We “migrated” from V8 to E10.1.400 via DMT. So going from E10.1 to E10.2 should be very straightforward. As @jtownsend said, there is a Menu structure in DMT that is geared towards migration. The menu items are in the order that you’d need to import data in.

One big warning about DMT, is that some fields provided aren’t respected. When I DMT’d in Order info (using individual DMT’s for Header, Line and Release), Things that auto increment - like line number - aren’t maintained. If your old system had 10 lines (1-6, and 9 -12; lines 7 and 8 had been deleted), DMT would create them as 1-10. Now if you DMT in the OrderRel info and one of your Releases referenced Line 9, that would be applied to the new line 9, which was line 11 in the original system. Not only would your release info not be applied to the correct line, Jobs numbers that used the Ord-Line-Rel format, would no longer match the line and release the were created for.

Uploading PO’s also suffered this re-numbering issue.

A similar thing happened with MtlSeq on BOM’s We had BOM’s with Mtl Seq’s like: 10,20,22,24,25,30,35. But DMT’ing them in created the Sequences 10,20,30,40,50, etc…

What I ended up doing on the orders and PO’s was to pad the DMT file with lines I could later delete

A DMT file for an order with lines:

OrderNum  OrderLine   PartNum   Other_fields...
12345     1           ABC-123   .....
12345     3           XYZ-123   .....

should be

OrderNum  OrderLine   PartNum   Other_fields...
12345     1           ABC-123   .....
12345     2           DMT-PAD   .....
12345     3           XYZ-123   .....

That will keep line 3 from the old system as line 3 on the new one.

Some other off the top of my head

  • Quadruple check the UOM setup.
  • Don’t upload anything that you expect to delete later (save for those items used to pad gaps). I uploaded all the parts, with the intent of deleteing the ones we didn’t want transferred later. But then uploaded costs for all the parts. That created ADJ-CST parttran records, thus preventing me from ever deleting those parts I was going to delete later.
  • Make backups of the DB after each major DMT upload. If you find that something went wrong, it’s easier to restore the DB from a couple of steps ago, than it is to start from scratch.
  • Did I mention the importance of the UOM system being correct?
  • You’ll have to do the Extended UD Column updates first as your DMT’s that hit the affected tables most likely need the UD fields.
  • If you want transactional data for reference, put it into UD tables, and then make BAQs to query them. An overzealous person would structure the UD table identical to the transaction tables, then in a BAQ you could union the UD table to transaction table in a sub-query, thus combining the historical and current transaction data into one dataset.
1 Like

At the heart of our troubles today is a very poor implementation a few years ago. Just an example: in the US we have 2 Companies/Plants. They are separate business entities with their own Tax ID, P&Ls, etc. The Epicor partner that did the Vantage 6 to E10 upgrade didn’t explain the Multi Company set up, and set us up as Single Company - Multi Site. And that’s where it started going downhill… As a result Month End reconciliation is a recurring nightmare. Things like this permeate the system. In order to make Epicor work, I think I do have to restructure both the organization and Epicor. At the moment it seems like a monstrous undertaking and it is hard to figure out where to start.

I looked at the DMT approach; I am familiar with DMT and a few of its quirks, but the tool never fails to put me in my spot when I thought I had seen it all :wink: It does provide a good road map, however even with my experience I am not always sure which tables to skip if I don’t want to lose a link between eg part and sales order. I wish it was as easy as “bring over Parts, Orders, and Customers” and be done…

P.

Calvin;

UoM is one of the other main sources of agony. At the time it was thought that it was best to stock sheet metal in square inches. Still causes weekly issues at purchasing or receiving… Setting it up right is one of our main drivers. At least we have experience in what does not work…

Your other points are understood. I have started a document with potential pitfalls and the exact timing of each step. We do make use of Ext UD Cols throughout. I like the idea for the transactional data.

Paul

1 Like

If confusing valid UOMs for a part is the worst of your UOM problems, consider yourself lucky! When I migrated from V8 to E10, I messed up big time when I failed to add the UOM Class to to the Part DMT file. It uploaded just fine, as UOM Classes have one set as a default (class COUNT in my case). That then set all the parts that should have had class LENGTH to COUNT, with the IUM defaulting to EA. And we use lots and lots of wire and cable. Uploading the Part Cost created partrans for all those parts. Now we’ve had to make a UOM of “EAFT” for class COUNT to represent things that should have been class LENGTH and UOM FT.

@psiebers There are open invoice load modules, too. (Notice that “invoice” is not in the name!) I have never used them, but they are advertised as creating the invoices without the GL activity, if desired.

image

That is endlessly frustrating.

  • You can create an order number out of sequence but not a line
  • Ditto for PO
  • You can create a Mtl Seq out of sequence, but not an Asm Seq

So arbitrary.

Oh, and @ckrusen, I am sitting here trying to pronounce “EAFT.” And laughing to myself.

1 Like

Bad UOM setup is a very valid reason to reimplement with a clean start. UOMs are one of those things that are near impossible to change.

a way to navigate around the auto increment is to load all the lines on the order and PO then run a follow up DMT to close the lines that were closed in your legacy system.

My legacy system was Vantage 8, and had lines deleted, not just closed. Those missing lines from V8 is what made the gaps. That’s why I had to add them back in as fillers.