Has anyone ever needed to change a job operation to something new in mass? Did you use the DMT tool? Is there a better way than DMT?
We have an operation that over time has evolved and split into 2 different areas that do the same process but only for specific types (Rectangles or Rings) so the operation is actually different despite the machines being identical. Before I came along no one made any of these changes so I have inherited it.
There are currently around ~1.1k jobs this will effect and manually adjusting these sounds awful. I do see that there is a job operation area under the DMT templates so I believe it can be done that way just wanting to see others thoughts and opinions or experiences if possbile.
I have done this, and I don’t recommend it. The best bet is to update the part masters so that future jobs will be created correctly. Then let those older jobs naturally close. However, sometimes you just have to get the jobs updated. Before you start with DMT, remember:
If the job has any labor transactions against the operation, you can’t change it. Use this to help filter out the jobs/operations that can be updated from the ones that can’t. If a job operation can’t be updated you just have to wait until it naturally closes out.
If you have comments in your operations that you want to keep, don’t forget to export them along with the other data you will need for DMT. Often comments are added to the operations after a job is created. If you just tell DMT to put in a new operation, it will pull in the default comments for that op if there are any, and blank if there aren’t any.
Break up your changes into multiple files to run through DMT simultaneously. I try to run files less than 1000 records per file. Break up your file as you see fit. Keep processing and reviewing the output files until you have processed all the records and have no remaining errors. If you can push an update file into Pilot twice with no errors, it is safe to move on to Live.
Always run the DMT in pilot first. Do it twice. Do it three times to make sure your process is sound, and no surprises will pop up. Document how long it takes to process each file to get a good idea of how fast this process will be when you finally do it in Live. You will have to work with Epicor support to refresh your pilot snapshot between your attempts.
A biggie we ran into is on the JobOpDtl table. If you do an add/update, do not make your JobOpDtl.OpDtlSeq match your JobOper.OpSeq. It ends up doubling all of your resources AND costs… (Same goes for PartOper and PartOpDtl). JobOpDtl.OpDtlSeq will always add a sequence #10, so if you match an operseq at 20 - it adds both a 10 and 20.
Don’t forget, you can close out any firm jobs with no activity and let MRP recreate them. I would also do a full regen without recycling unfirm jobs if you are making major changes and want to clean up any existing unfirm jobs.
As Nate indicated - this is not for the faint at heart. I would recommend transacting those test jobs in pilot and having accounting validate job costs too. Also have a planner look at scheduling to make sure things appear reasonable. If something is wrong, then repeat all until all parties are confident.
Thank you for the information. I honestly am thinking this might be above me at this point but it needs done so might have to go about a more phased out approach as @NateS mentioned with some manual touches where they have to be.