Does Job Wizard trigger the JobEntry Methods?

Epicor ERP 10
,
1

I ran a trace during order entry and used the job wizard, like my reps would do, to create jobs.

In the trace, I see the BO.OrderJobWiz and CreateJobs method, which is followed by the BO.JobEntry but the only method I see in JobEntry is GetList. I don’t see GetNew, Update or GetDetail methods.

image

image

image

My original thought was to have the BPM fire on JobEntry - AddOperation OR GetNewOper methods, but it doesn’t look like those are even triggered by CreateJobWizard.

My question is, if I’m using OrderJobWizard to create jobs, how would I enumerate through the operations of the created jobs afterwords using BPM? In a nutshell, I would like to look at each operation as they are made, if it’s a subcontract operation and the supplier is “Company A”, create a PO.

Thanks!

2

It does not call the same methods from the client. I would also doubt it calls the exact methods from that method internally. It can be checked by either sending an email or writing to the server log inside the method you want to test.
To your question though, this can be done in Post Processing if the dataset returns the list of Jobs. If not, a Data Directive on JobOper can also performm the logic.

1 Like
3

No it does not. Method directives are inconsistently called between screens and are likely to be one off (sometimes Epicor will simply rename the methods being called by the screen between minor releases).

If it helps, I’ve been through something similar and written POST directives on OrderJobWizard to set values after the fact keying off the order release to find the related job similar to below. Basically the logic in the loop is a slight variance of the natural way to do this (ie, JobEntry.Update):

//loop through temp table records that are being passed back to interface
foreach(var i in (from t in ttJWOrderRel select t))
{
//if there is a job related to the release
if(Db.JobHead.With(LockHint.NoLock).Where(r=>r.Company==i.Company && r.JobNum == i.JobNum).Any())
{  
//do something with related job.  Similar logic to what I would do in JobEntry.Update..
}
}

Data directives are another way to interact with the specific table across applications but can be dangerous if poorly written.

1 Like
4

The only “good” way to find anytime a new job is created is by using a Data directive. The challenge is that there are multiple processes that create jobs, and they do NOT all use the same business objects. This may seem at first to be inefficient… but (for example) MRP creates MANY MANY jobs… it needs to run more efficiently, and it “breaks the rules” to make this happen faster. MRP knows how to create jobs properly, but doesn’t use the “normal” business objects to do that. Same goes for Order Job Wizard, and Quick Job…
But also, remember that when creating Data Directives on Job data, that (as said before) MRP creates and manipulates MANY MANY jobs… if you do something bad in a data directive, you can end significantly slowing down MRP at best, and worst… crashing it. proceed with caution.

3 Likes
5

I appreciate all the input!

@timshuwy, I’ve been told we don’t use MRP for anything. From my understanding, all our jobs are created in 3 ways. If we have to make a rework job that needs entered manually, we use JobEntry. If it’s for stock, we use Quick Job, but most, >95%, of our jobs are made using OrderJobWizard. We make-to-order.

We want any subcontract operation going to a certain supplier (intercompany), so I’m assuming a data directive would be the way to go?

Or is there a better way to automate intercompany transactions?

I’ve been reading on IC trading, from what I’m understanding that just gets us the PO suggestions? We don’t need suggestions, we want the real deal. Also, our PO suggestions process seems to take nearly an hour to run so we only run it twice a day, once at lunch and once after close. We manufacture over 15,000 different part numbers, I’m assuming that’s why the process takes so long. I believe they use regenerative suggestions too, not sure why. This was setup before I was involved.

So, for example, a CNC guy at Caster Concepts completes a wheel core, we then need to send the core to our other company, Reaction, to have the polyurethane put on. As it stands, it can take hours, if not next day, until our other company has the job for this operation. We’re in the same building… I want it to move from Company A to Company B seamlessly. This would certainly help decrease our lead times.

The ultimate goal here is to automate the purchase order entirely on Casters side, then automate the sales order and job creation for our other company, Reaction. I’m finding it to be much easier said than done.

6

did you know that you can specify who the supplier is in the part’s operation? If you pre-define this in the engineering, then when you create the job, the operation will automatically be pointing to the supplier, and then when you generate PO suggestions, this will also be pre-defined. No need for BPMs.

2 Likes
7

Perhaps you can automate the process using a Post-Processing BPM on OrderJobWizard by creating Inter company PO for required subcontract operation.

2 Likes
8

@timshuwy, I had to double check and yes, we do have the suppliers pre-defined.

@Arul, that’s what my original idea was but it sounds like Data Definitions are the way to go.

So, I decided to tackle this head on, with my limited knowledge, and surprised myself. It wasn’t as hard as I thought it was going to be, just took a little effort to learn the elements and how to use them.

I ran another trace, created my PO manually and replicated it through BPM. I’m able to create an automated PO, no matter how the job is created, by using a standard Data Directive on JobOper like @Jason_Woods had mentioned.

This is what I have so far:
image

Condition:

image
image713×137 16 KB

Created a POTableset variable on GetNewPOHeader.
image

image
image806×121 4.01 KB

The rest is pretty self explanatory
image

I send myself an email containing the field data, just for verfication purposes. Everything looks in order so far.

1 Like
9

Well done!

1 Like
10

@CasterConcepts: 10 points to Gryffindor for naming your widgets. :trophy:

2 Likes
11

Gryffindor or die! :lion:

1 Like
12
13

Great job following the trace… That is what I’m talkin’ about…

2 Likes
14

Great work @CasterConcepts. One of the reasons I prefer to use Method Directive instead of the Data Directive where possible is some of the related tables will not update when using Data Directive. For example, when updating JobMtl or JobOper or LaborDtl costs/hours, Epicor updates JobAsmbl table which may not get updated when using Data Directive. I had one BPM, where I updated LaborHrs in LaborDtl table using In-Transaction Data Directive which didn’t update JobAsmbl oost. When the job is closed, it created variance.

2 Likes