Good morning,
I was just using the DMT program “Job Operation” to change the operations for all open and engineered jobs. For now I am only doing this on one part number at a time, but eventually I will run it wide open for all the parts/jobs.
In the past our operations were all the same, 99999 DEFAULT. Each operation was assigned a resource group that defined the task to be performed. Moving forward, I have created operations for each resource group. These new operations utilize capabilities rather than resource groups. I update the excel file using the old resource group ID to define the new OpCode.
When I run the “Job Operation” DMT program, I can replace the OpCode just fine. However, the resource group assigned to the original operation is not replaced with the capabilities assigned to the new operation. Under Job Entry > Operations > Scheduling Resources > Detail, I should see the capability there instead of a resource group. And under Job Entry > Operations > Scheduling Resources > Scheduled Resources, I should see the resource ID chosen from the capability for that op. Instead I see only the values that were previously there before I update the job’s operations.
My question is, what DMT program do I use to update the job scheduling resources and job scheduled resources?
As always, I look forward to your words of caution!
To update or delete Job Operations please note the following:
Job Operation
Objective: To Delete JobOpDtl records from Jobs
Requirements
Job Closed and Complete = FALSE
NO Labor reported against operation
PrimarySetup/ProdOpDtl cannot be deleted
Include JobOpDtl#RowMod = D
Run Import in Update Mode
Perhaps DMT has changed significantly from my version… I have never input a rowmod in loading up or deleting methods. Our version has a checkbox for deleting. Any chance you have one of these too (screenshot)?
I think that the JobOperation template builder should be used, with particular attention to the JobOpDtl# fields. These are in the JobOpDtl table and DMT is combining them. I recommend tossing your subject job(s) in a UD and doing a query to get the operations for the subject jobs and trying to get a handle on at least the indexes in there for JobOpDtl too and do the delete using that. On an aside, I was told by scheduling experts to only have a capabilityID or a resouregroupID or a resourceID, never more than one ID or you won’t be able to let the scheduling engine do its work. We haven’t worked with finite scheduling in awhile however.
You might want to run global scheduling after doing the DMT to get your jobs to all reschedule… I’m not sure how the jobs will get rescheduled with just the DMT.
Yes, The DMT does have the delete field. I think the Epicor tech suggested to add that rowmod flag for the OpDtl record. As the Job Operation program in DMT only works on the job operations and not their operation details. I am holding off for now. I think that we are going to have to do some serious thinking about how our open jobs will be updated.
If I understand…
Then yes, I’d usually do something like what they indicated
Firat pass the JobOp template(s) - just to set the OpCode(s)
Then I’d follow up with a JobOpDtl template(s) to set resources and capabilities
In theory you should be able to do everything in one pass using the “combined” template but… seems like I always run into snags with that.
To add I would recommend whenever you have a field with # in the header include both the # version and none # version.
e.g. use OprSeq & JobOpDtl#OprSeq both with the same data. Just looking at my DMT version it says jobopdtl#opdtlseq is system assigned so I would try leaving it out
Good morning,
We met today to review the process we are going to use for getting our open jobs up to date with our new process.
I came to the meeting with two solutions that I didn’t like.
Complete the operations that have labor against them. Complete the rest of the ops. Create a new set of ops in the same job to duplicate the old ops. Use the new opcodes.
Close the job and create a new job. Transfer any remaining demand from the old job to the new job.
During the meeting we discovered a compromise approach that I hadn’t considered.
Ignore operations with labor charged against them. Let these ops complete naturally. For the ops that haven’t had labor charged, update the opcode.
I am not sure if this will work, but it seems like a good approach. What do you all think?
Off the top of my head, a mix like this sounds OK
just wondering if you’d be making the updates after normal shop hours?
i.e. you’ll be leaving yourself plenty of time for review before labor entry starts back up.
Good morning,
I am using the DMT to delete operations for open jobs. As I discussed with my Epicor support, we can’t delete ops that have labor transactions, material transactions, or subcontractor/PO transactions. Today I found out that ops referenced by a sub-assembly can’t be deleted. I am getting this error in DMT:
“Delete not allowed. Referenced by at least one Job Assembly”
This message is repeated for every operation in each job, regardless of if the operation requires sub-assemblies.
I would like to filter my export BAQ to exclude these ops. But I can’t seem to find a suitable criteria to exclude them.
Edit: I can manually delete these operations, except for one that references the assemblies. Why would DMT give the error for all ops, and not just the one that has an assembly?
Can you tell me what I am missing?
I have attached my BAQ for review. ExportJobs-OpenEng.baq (60.6 KB)
Just curious if you have you tried manually deleting a sub-assm op in Job entry?
I am able to delete sub-asm ops… as long as they don’t have related materials.
If this is the case, then possibly another template first to reassign or delete related materials before changing sub-asm ops?
Haha I tried that while you were typing it. Great minds, huh? The op that has assemblies will not allow me to delete, it, but all the others ops delete just fine. But DMT still throws that error for all the ops. Very strange!
My goal is to ignore any op with materials, or labor, or any other kind of transaction.
Oooh I think I got it. I added in the Job Asm table and linked on parent and related op. I think that did the trick, as my delete is running flawlessly in DMT now. Yay!!
For reference: ExportJobs-OpenEng.baq (63.4 KB)
Yeah, DMT can be finicky and the error messages might mislead.
I’ve had some luck figuring out what is really going on by processing a template with just one record at a time… repeat with the different types. When I get an error, try to do the same thing manually thru Job entry. Tedious but…
Wasn’t doing exactly what you are but FWIW I remember when updating jobs I had to use multiple templates/passes - e.g. JobHead, JobAsm, JobOp “regular”, JobOp “subcontract”, JobOpDtl, JobMtl
