Question

CustNum


Userlevel 2

We are moving from E9 to Kinetic and loading Data via DMT. One thing that has been brought up is can we use the CustNum in E9 in Kinetic as it seems that when loading via DMT it is generating a new CustNum? 

Maybe i am doing something wrong.


12 replies

Userlevel 4

You should be using the CustID field not the CustNum field...CustID is the field that holds your customer ID whereas CustNum is a field maintained by Epicor and incremented by one each time a record is added.

This allows the change of customer ID after transactions have taken place

It is the same for Suppliers

Userlevel 2

I totally agree but it seems like in the past someone has created external systems and DBs based on the CustNum and even the VendorNum! :sweat:

 

At the same time though the ****Num when we load the Customers and Vendors into Kinetic will be different to those that are in E9 which unfortunately is going to break quite a few links and also potentially means we will not be able to do a clean up of our ID fields to bring them into some sort of Uniformity.

Userlevel 3

It should work if you sort your DMT file by CustNum. 

 

Sue is correct about the CustID being used throughout the system in input fields on various screens where CustNum is not.

 

However, IF you are using Parent/Child relationships for customers this is how the relationship works - by CustNum.  So if you are using this and do not give your customers the same CustNum in Kinetic, you will have to update the ParentCustNum to reflect the new CustNum.

Userlevel 4

You could add a UD field for the old E9 *Num field, yes it will still need some work on the external DB/systems etc. but it would still allow you to clean up the ID fields for use in the upgraded environment

 

Userlevel 2

It should work if you sort your DMT file by CustNum. 

 

Again i agree with what you are saying, however, we are not taking over all of our customers from E9. Essentially we are starting afresh on a new system as it were, cleansing all of our data, getting rid of all of the dead wood and having a brand new Kinetic system with only ‘Live’ data in it. In everywhere i have worked previously the ID fields are the ones that have been used for reporting, links, DBs etc.. unfortunately it seems someone has had a different view in my current company PLUS we have a ‘Cowboy’ IT department that do not fall under the remit of the IT department and they seem to do things their own way as well. That bit i am not so bothered about, as far as i am concerned if their stuff breaks, that is their own fault :joy:

 

Our old E9 system will be converted as is when we go live so that we have a historical view,

Userlevel 1

You do not use DMT to migrate from E9 to Kinetic (or E10). You use migration program provided by Epicor. DMT is not the way to migrate any of the data between versions. Once migrated, you can clean them up in new Epicor. You can also clean data in old DB before migration as well.

Userlevel 4

I concur with Doug’s idea of sorting the load file by old customer number.  I wonder if this would work if any of the entities were deleted in the meantime.  In other words, if the old customer numbers were 1, 2, 4, 5… if they would load in the new system as 1, 2, 3, 4… and I suspect you would again have misnumbering.

 

I’m currently doing a dump, transform, load from Vantage 5 to Epicor 10.2, and we did what Sue suggested: drop the CustNum and VendorNum fields from the load, using instead CustNumCustID and VendorNumVendorID.  But then when you do shipping points, CusCnt, etc. it’s necessary to have a from/to transformation table for that as well.  You can do this by making a simple BAQ or SQL query, which in the new system pulls the customer numbers and customer IDs, so you can build a cross reference.

 

HTH

……..Monty.

Userlevel 2

You do not use DMT to migrate from E9 to Kinetic (or E10). You use migration program provided by Epicor. DMT is not the way to migrate any of the data between versions. Once migrated, you can clean them up in new Epicor. You can also clean data in old DB before migration as well.

Whilst i agree with you to a certain point/ When you have 20+ years of bad data on your current system, the Sirus migration tool is not the way to go and having spoken with EPICOR on this many times we agree that the clean up should be done before migration and migration should be Done using the DMT.

Userlevel 2

Just noticed a further issue with this, Customer Managed and Supplier Managed Bins work from the CustNum and VendorNum respectively despite when you setup manually you enter the Vendor ID. We have multiple Customer Warehouses and 1000s of bins in each one.

Userlevel 4

Dear Daniel, 

 

In the spreadsheets you’re using to migrate customer-managed bins and vendor-managed bins, you’ll need to build a lookup table to transform the old CustNum into the new one.  When you’ve migrated the customers to the new system, you can write a quick BAQ to export the CustNum / CustID, then put it together with the same info from the legacy system, to make your lookup table.  Then you can just VLOOKUP the old CustNum in the lookup table sheet, to get the new CustNum.

 

HTH

..Monty.

I agree with vshevchenko. Use the Epicor migration tool.

 

 

randallweber.com

Userlevel 2

I agree with vshevchenko. Use the Epicor migration tool.

 

 

randallweber.com

You obviously did not read my reply to him.

Reply