Is my logic sound, how would you do it? Etc

Ok, I’m wrapping up a little project at work where we are attaching “Snapshots in Time” to JobHead, with the engineering documents that are current as of that date. We then mark them with a boolean for easy checking if this process has been done.

This is how I’m determining when to do the attachment process:

What they asked for, was when a user first starts working on a job, to do the attachment process.

So I put a BPM on Erp.BO.Labor.Update which checks if there is any laborDtl that exists for that job, and if not, do the attachment process.

Is that logic sound? Are there any other (common or likely) ways labor could get created for a job other than when they start activity for a job?

Just report qty without start end on a job

1 Like

I’d do the attachment on Job Release. The job’s MOM can’t change between the release and start of labor. So why delay it just to make the BPM more complicated with labor checks?

Well we already have to start the job, so my thinking was the files would also be available to view from job tracker. Trying to get the earliest point, but also not overlook something and miss out.

I think this logic is sound. One thing to consider would be if you set any early operations to backflush. Even with backflushing, eventually a user has to interact with Epicor. At that time the Labor.Update should fire and request your attachments. So, you should be all set!

Where are the places Labor.Update gets called? From my experience it happens with manual labor entries via MES or timeclock, labor adjustments, job completion, and backflushing.

Unfortunately… I work with people that are somewhat resistant to change and don’t always follow best practices. We are working on it.

1 Like

Are you only looking for production activities? They could start a setup activity and create a labor entry.

1 Like

I would probably do like @jtownsend said and use Job Release as a trigger.

2 Likes

Way 2 often I resemble that remark :frowning:

1 Like

Ok, that’s the kind of thing I was worried about. Luckily, we don’t currently use those. Is there anything else y’all can think of?

In this case, the bpm is on update, so it would still work even if we did use it, and be in the proper time-frame for a snapshot.

Heard, chef.

Still, that’s no reason to put their bad ideas into your code.

3 Likes

Yeah, with our current processes, I just can’t.

They may make this job 6 months out, and change engineering between now and then. We need the documents that are current at job start, as they are always what is used.

1 Like

I have enough of my own bad ideas in there, do you think they’d conflict?

Or combine to make some kind of Voltron like super-mech?

Well, do they ever change after startup of the job? Is there a possibility of using a setup operation? You could always have a Op for the drawings to attach themselves as trigger like having an Op for parts to be issued to a given operation have the drawings attach once that Op is reached and activity is started that would prevent it occurring during a setup op?

1 Like

You say that like there might be a different kind of people somewhere…

5 Likes

Oh… it was very much tongue-in-cheek :rofl:

I like the idea of a specific operation. A “Complete Documentation” operation. That could mean updating a lot of BOM’s tho

2 Likes

There is, and I would like to get them there eventually, as it would break out our costs a bit better, but while I have a lot of power here, probably more than I should, there are politics in play.

I’m playing the long game, and learning as I go as well.

Well technically… it’s my brother that has to do that, and he was a dick to me a lot growing up…

1 Like

Ok, then my vote for simple way is Op trigger like “Attach Docs” and the docs for parts & parts could be issued at same time or from the preceding one if you have issue parts op as well. Since you would need well defined itemized drawings to issue parts for the job op here.

1 Like