How would I go about adding LaborDtl to this bpm? or is it even possible what I’m trying to do.
I want to be able to adjust JobOper.LaborEntryMethod field based on if Quantity is entered and the field is set to T and should be Q then change it back after the Quantity is entered.
But I can’t for the life of me work how to pull in LaborDtl so I can look at this field.
Here is my current BPM (I’m new to it all)
You will have to use an Execute Custom Code widget to get labordtl records at this point. I am not tracking with what you are trying to accomplish, though. Why do you want to change it back?
Thank you for getting back to me.
Ok my plan of action is to have a BPM which will unrelease & unengineer a job in Job Entry change the Labor Entry method to: Quantity Only then change it back to Time & Quantity and re-engineer, re-release the job. - Repeat.
The bpm will need to trigger off MES > Report Quantity button and field: RQ.CurrentQty but i’m unsure of… We currently have a BPM inplace which prevents overbooking quantities on jobs. This is within JobEntry.Update.
I’m new to programming & BPMs hence asking lots of questions, I don’t even know where to start to resolve this issue or even how the code should look.
Thanks for help.
The JobOper Data Directive will be too late for that. The method firing at your point will be ReportQuantity.ReportQty. You can see the process in the Trace Log for any transactions. Either a Data Directive on LaborDtl or a Method Directive on ReportQuantity.ReportQty is a place to start.
Realistically, there is a ton of power and possibility with BPM’s. This might be more involved that you want for a first BPM which is why I was wondering what the reasoning behind it was. Maybe there is an easier way…
A starting point could be (and I have not created or verified this so you will have to experiment):
- pre-processing method directive on ReportQuantity.ReportQty
- widget to get job dataset and uncheck released and engineered (this might be multiple steps depending on dataset requirements)
- widget to flip your labor entry method on joboper table and save record
- enable post processing directive
Post Processing Directive on ReportQuantity.ReportQty
- widget to flip back labor entry method
- widget to recheck releases and engineered flags
Only a starting point. You could also do all of this is a custom code widget but it requires C# Linq and non-code widgets are going to be more accessible.
If you explain the end operational goal there are a lot of people here with a broad range of experience that can help solve the overall problem. If you just want to get this BPM working, you will need to try some of it and keep posting.
Thank you for that excellent reply!
Our operational end goal is to prevent zero hours on a job operation. If a quantity is entered using Time and Quantity it results in a zero time rather than the 16.00 or so on there should be when it’s changed to Quantity Only.
I basically want to mimic a human unreleasing and unengineering a job and changing that field to Quantity only, save then enter their Quantity via MES report quantity and going back and repeating the first steps resulting in correctly calculated time.
I hope that makes sense?
I’ve done a few BPMs and done some of the classes with Epicor Training people but this one is a challenge and I needed help.
The easy option would be to pay someone to do but that way I would never learn.
Can’t you get that result by just converting your operations to Quantity Only and just leaving them that way?
Unfortunately, I offered that option but it went down like a lead balloon.
I will give your previous option a go and report back.
All the best
in your BPM, can you use the code instead of the control. if so, you can use DB.LaborDtl
Are you able to put together a few screenshots of your BPM using the detail you said above? I’m still struggling to make this work.
I don’t have a BPM for this and was just theorizing.
“Our operational end goal is to prevent zero hours on a job operation. If a quantity is entered using Time and Quantity it results in a zero time rather than the 16.00 or so on there should be when it’s changed to Quantity Only.”
Perhaps I am misunderstanding, but if the intention is to simply ensure there are specific hours on an op that reports qty, why not just put a BPM on LaborDtl to do that? I would warn that this is going to affect your job costing. Wouldnt configuring your operation to properly know how much time per op\qty be the proper solution here? I’d consult with an Ops person (and that is not me) before looking at BPMs.
I agree with that and figure I must be missing something. It seems you could either block the labor transaction or just convert them all to Q since you want to do that with a BPM anyway. I don’t understand the value of toggling the labor entry method in this scenario. If you can share the rationale we can help get to a solution.
Would it be best blocking the labor transaction using C# or a BPM widgets? The logic around it is that I am happy to block the transactions. If the LaborEntryMethod = T when entering Quantity from MES but I didn’t want this creating additional work of them having to go into Job Entry, unreleasing the job, changing the LaborEntryMethod to Quantity saving and re-engineering the job, just to enter their quantity in MES.
The whole point is to prevent cost variations or under costed jobs. I created another post previously a while back I didn’t have much hope back then I’m still in the same position… @rosshughes you’ve pointed me in a right direction but it’s completing the task I’m struggling with.
Original post: Time and Qty
What is the ideal logic you are considering? Do you want to lock people in to an operation (or toggle T/Q/T) if it is under X minutes?
I would like the Act Hours to be more accature on the operations when it’s Time & Quantity. If it’s quantity only the Est. Hours and Act Hours match.
I’m very sorry this has become long winded. I have come to realise that this is not the correct method of resolving this issue. It would be as @Chris_Conn said speaking to the Ops person and having them create the job correctly.
Unless you can think of another method of resolving this?
I think you might just be trading one set of problems for another. Don’t worry about the conversation length.
Labor collection needs accountability and discipline or automation and predictability. And, there is still accountability in the latter because we still need to report qty.
If it were my problem to solve, my first question would be whether you are aiming for actual time or estimated time? If you want real-time feedback from your production system you need to log in and collect actual time and use the corresponding production detail report to recalibrate your production standards and keep that cycle going. Or, if you are paying people based on labor header and/or details it becomes critical. A lot of people want this but can’t manage it well.
If you believe that your production standards are accurate and you just want them to roll forward and be the same then I would just convert your operations to Quantity Only and save the pain of actual time labor editing. In fact, you could just backflush all of your material and auto receive to inventory which would allow you to just report the quantity and complete rolling estimated labor to actual, material issuing and job receipts simultaneously. Pretty slick with an accurate BOM and a correct production standard.
Hopefully this makes sense.
I have opted out to throw an expection or warning message if the LaborEntryMethod is set to T using ReportQty.ReportQauntity method but I don’t know how to start it because I can’t see JobOper to get to LaborEntryMethod to check if it’s T using a BPM method ReportQty would it need to be custom code?
One method is to use the query is >= 1 in the condition widget and connect to the joboper table and look for the time entry method equaling ‘T’ and then throw an exception. I have attached an example as a starting point for the method you stated. It is on a newer 10.2.600 version but maybe it will import. If not, we can work through it together as it is basically a query and an exception.
Block Time and Expense Ops.bpm (32.6 KB)
You can also look at the trace log as there might be an option to block it earlier.
I’m running 10.2.400 so it may not import. I will try tomorrow and report back.
Thank you so much for all of your help. I didn’t expect this much help so I’m very grateful.
All the best
I do customizations and custom code BPM’s all the time. I concur with a lot of what was said here. If you were my client, my first goal would be to talk you out of the “unengineer, fix, report, reengineer” approach. unless my sole goal would be to create a maintenance nightmare. One thing you always have to consider when creating BPM’s is what happens when the unexpected happens part way through - because it will eventually happen. You’ve got a risk of unreleasing jobs and then having some hiccup keep it from re-releasing at the end.
I’m not following fully what it is you’re trying to accomplish, but if you simply need to get the Labor Entry method passed back to the UI, you can run a trace and if needed, read the JobOper record at the right point and set a CallContextBPMData field to the Labor Entry method, then check that in your calling program to display a warning or a hard stop.