Override job number when firming an unfirm job?

Wondering if anyone has figured out a way to override the job number when firming up a job that MRP has created… example:

  1. mrp creates a job UJ00000001
  2. You firm the job, and the system auto assigns the next job number “0012345”.
  3. 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


You can create a BPM or customization that create this jobnum on that BO and auto increase for the next jobnum

What about creating a MRP firm job prefix? All our firmed MRP jobs start with T.

@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”).

1 Like

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

Yes I agree with Alex. Would a data directive on JobHead change job number work?


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. :woozy_face:

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.

    <paramDataSet name="ds" useDataSetNbr="0">
      <changedValue tableName="JobHead" rowState="Modified" rowNum="0" colName="JobFirm"><![CDATA[True]]></changedValue>
      <changedValue tableName="JobHead" rowState="Modified" rowNum="0" colName="UD_SysRevID"><![CDATA[System.Byte[]]]></changedValue>

  <localTime>11/21/2019 08:00:46:1643652 AM</localTime>
  <executionTime total="104" roundTrip="96" channel="0" bpm="0" other="8" />
    <parameter name="ipJobNum" type="System.String"><![CDATA[W116218]]></parameter>
    <parameter name="ipStartAssemblySeq" type="System.Int32"><![CDATA[0]]></parameter>
    <parameter name="ipCurrentAssemblySeq" type="System.Int32"><![CDATA[0]]></parameter>
    <parameter name="ipCompleteTree" type="System.Boolean"><![CDATA[False]]></parameter>
    <parameter name="ipJobTypeMode" type="System.String"><![CDATA[MFG,PRJ,SRV]]></parameter>

@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!

No, this was as far as I got. Like I say, changing JobHead was easy. But if I can’t change JobMtl and JobAsmbl and JobOper, it’s all for naught.

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…

This is under “Future Consideration” as part of the ERP.


Did you ever find a solution? I just hit the same wall you did, edited the JobHead but not any of the other related tables.

Tim, did you ever figure out how to make this work?

@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.

And… I need this one too. Odd there is nothing that allows us to inject a new Job Number…

Wow… this old question coming back to haunt.
I am wondering if if it would be possible to:

  1. mark the unfirm job as a “template” job (do this with a BPM).
  2. have a BPM create a new job with your job number, copying the data from the JobHead, & JobProd.
  3. Have the BPM “Get details” from the template job
  4. have the BPM delete the Template job.

Bummer. That is my code (30 widgets and code later). I am still having issues deleting the old job and having the UI be OK with the changes…

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?