Question

Loading Jobs via DMT (Old system to new system)

  • 14 July 2022
  • 7 replies
  • 319 views

Userlevel 2

Can someone explain the process to migrate Jobs from your old system to your new system using the DMT? We have queries for Job Head - Part - Prod - Assmbl - Oper - Mtl which i have extracted from E9 and i am loading them into Kinetic but i feel i am missing something.

 

What should you ensure about the jobs in the old system before transferring. Its been many years since i have done this and i am sure i am missing something.

 

I guess i am after a Best Practice method of some sorts.

 

Thanks.


7 replies

Userlevel 2

Do you have any transactions against these jobs?  You may want to load them from the part trans file. If you have links to orders you may want to load the orders and the jobprod file. If you want any posted labor then you would need labor head and detail.  you would need to load any purchase orders for material or subcontract that are open linked to these jobs.  

When we have done this, we created “conversion” part numbers for material, labor and burden.  We loaded the current job costs into these dummy part numbers and issued them complete.  Then we just loaded open materials and operations.  If you create parts on the fly and need full job details in Kinetic, then you would have to go the route explained by bkyle.  Definitely want to make sure you convert the JobProd demand links either way you go.

Userlevel 2

What kind of volume are you talking about?  We put a big effort into completing most jobs prior to our conversion day.  The few that remained open we just entered manually.  The finance and materials people will be involved to make sure the balances match the old system.

We did what Jenn describes with conversion materials but these will need to be balanced to the old system.

I would caution against DMT because this is not an IT process but a business process.  Use DMT for some of the supporting data but the core jobs have a significant amount of data that will be created different from your old system.

In my experience, this gives the production people an opportunity to gain some ownership of these key records as well.

Userlevel 4

We are also re-implementing by dump / transform / load via DMT, and are about to load some transactions into our “live” evaluation system to prepare for CRP testing.  Interested to hear more about the loads being run, and the results.  Likewise I have done this before but it was several years ago.

Userlevel 2

We are also re-implementing by dump / transform / load via DMT, and are about to load some transactions into our “live” evaluation system to prepare for CRP testing.  Interested to hear more about the loads being run, and the results.  Likewise I have done this before but it was several years ago.

Hi Monty,

  We failed at the first hurdle as our jobs were in such a poor state of affairs. I have now got the Operations guys to look at and cleanse what is currently in our E9 DB so that if we get any other issues on the next test cutover it should only be ones that may fall into an area we have not thought about. We currently believe we will have about 1000 ish jobs we will need to take over to Kinetic.

 

Daniel

We recently went live and followed a process similar to the one that Jenn describes above. Our finance department now wants to measure aged WIP and We are struggling with how to get the LastLabor field to populate with the legacy last labor date.

We have tried usingJob Labor Adjustmment to load the Last Labor field. The DMT runs without errors but nothing gets updated. Have tried this with the operation open and then completing the opeartion. Last Labor still shows up as our go live date.  Tried adding a new operation to the legacy job with the aged WIP date  and get the error that 2/2/22 is less that the earliest apply date of 9/1/22. We get this same error when trying to add a new labor detail record. Anyone have any ideas on how to get the last labor field to populate with the legacy date?

Userlevel 4

@MTPP Earliest Apply Date is set by Finance each month, and is a safeguard to avoid illegal transactions being entered or created.  It can be set to another date temporarily, to allow DMT loading of prior transactions, then put back to the appropriate date.

Reply