Wondering if anyone has figured out a way to override the job number when firming up a job that MRP has created… example:
mrp creates a job UJ00000001
You firm the job, and the system auto assigns the next job number “0012345”.
INSTEAD, I want to have a special job number “AB101” - This value is in a UD FIeld on the unfirm JobHead… i want to read this value and force the job number
@Alex & @Kimberley, both your ideas are how I would normally recommend, but in this particular case, there the numbers are not sequential. They are assigned at the sales order level… but they are not the sales order number. They are a special type of identification number that the entire job uses for a complex large asset build. So the first job might be AB123, then next job might be xy321… So I cannot rely on how Epicor normally assigns numbers, but must override it.
(NOTE: One could ask “Why”… i already did the “Why” question many times with the customer… and I got back “Because we need it that way”).
Even easier create a BPM or Customization that works pulling that value the BPM will be post procesing connect jobprod to orderrel and from there to orderhed if needed pull the UDField and assign it to the JobEntry.JobNum
Has anyone ever figured out how to do what the title asks? My scenario is different (I want to use the project number as the firm job number), but the idea is the same.
I made a data directive on JobHead. It worked. It worked so well that the JobHead was one job number, yet the JobMtl and JobOper and JobAsmbl were all still tied to the unfirm job number, so the head was disembodied, basically.
So I guess the real question is, how do you change the job number for ALL of the job tables while firming? Probably need to consider JobProd as well…
I tried doing this on additional data directives, but I must be missing a step or just using bad logic.
I did a stack trace (full data set) and it references the unfirm job (UNFIRM-000001) every step of the way until the very end. (Snippet below; firm job is W116218.)
I don’t see any mention in the stack of the process of changing the job number. It’s like magic.
@JasonMcD Have you figured it out? I have the same issue. I dunno how to make an ERP originated Job Unfirm while making sure respecting all the constraints!
So you have tried to change JobNum from JobMtl, JobAsmbl, JobOper and JobOperDtl but it didn’t allow you?? I though that would be my last option! There is a method in JobEntryImpl that gets you the next available JobNum btw…
@RickG@JasonMcD I recently made a UBAQ that doesn’t change the jobnum during firming, but I think could get around your issue.
We have placeholder jobs that are entered to drive long lead time materials IE 101RAW when we enter the fabrication window they want 101RAW to become 101FAB including any operation or material changes so I make a new job 101FAB and call JobEntry Service GetDetails and set the source as the 101RAW job then delete the 101RAW.
Interesting. I have said before that DMT needs a GetDetails option, but you did one better and baked it into a uBAQ. That’s definitely better than what we do now - DMT and then Job Entry.
So, our jobs have about:
1,700 rows of JobMtl
100+ subassemblies
300-400 operations
And we do that 5-7 times a day. You know, unless we get ahead or behind.
I don’t know, but I would guess that the firming process is faster than Get Details. But maybe not.
It’s a ton of processing either way. Firming would still have to change the job number on 1700 JobMtl records, 1700 PartDtl records, 400 JobOper records, etc.
@JasonMcD It is faster than get details in job entry, but I would assume firming takes a firehose approach to the job renaming. I worked on another project assuming that get details was linear and in post processing I would get back op 1,2,3 but instead got a random return order which made processing speed sense. I human sees them in order on a job, but the system doesn’t need that.
So I know it is supposedly under consideration for 2039 or whenever, but I’m not holding my breadth for it to be part of the UI.
But this is the thing right there – we can’t even grab onto the mystery method(s) that do the number change internally. Just access to that would be the lifeline needed, right?