So if there is a pre-made UD field on JobHead Table to fill with a “email sent” preventing the re-release to trigger another email. Is there a pre-made UD field on the Part Table that could be use to mark the part as already had the first time make job? Otherwise, how do you prevent the next job for that part from triggering the email to be sent again?
You could use a UD User field on the Part table, or you could modify the other original query check to prevent it. You can use the same UD field on the JobHead table to check this.
I made an outline of a data directive on the JobHead table to help as an example. It’s 2 parts, 1 in-trans directive to check for the conditions and update the UD field if they’re met, and one standard to send the email that’s enabled by the in-trans:
It doesn’t account for the job being for a top level part. Also the query table joins could be made more efficient by not joining the temp table to the job head table, and filtering using variables instead (Edit: updated to reflect this).
Some fields on just about every table seem useless. For example, Part.Gravity. We will never use that. Perfect example of a field that is useless which you can make useful. Not a perfect solution but a workable one.
I would get the admin of Epicor to create the UD field on the part table as a better alternative.
There is a field that is rarely used by companies that would be perfect for this feature… The "Head/Asm Analysis code field. It is a combo box on the Part table.
- create a new Head/Asm Analysis code called “First Build”
- When the new part is created, assign give it the “First Build” assignment.
- create a BPM that fires when a job is RELEASED. The BPM would look to see if the Part has the First Build flag on in the part table… if so, it would send notification to Engineering.
- Engineering, upon review would need to manually turn off the first build flag in the Part table, which would stop notifications in the future.
This idea could be enhanced to simply call the value “Notify Engineering” instead of “First Build”, and could be used in the future for other features.
Dont join on ttTables.
My company currently uses that field, however it will still work. Is there any way have the method directive set the Head/Asm Analysis code to ‘Blank’/null. The reason being, when jobs get cut planning usually cuts a few. If that field isn’t changed then all those jobs would be considered first time build jobs, when really they are not.
Might be a silly question, but in the image where you show the query…would that be considered joining to a TTtable? Being I am using the TTJobhead to get the part number, would using the ERP.JobHead in the query be considered ‘joining’ them? Or does that only apply when they are actually joined in the query itself?
Only when they are actually joined in the query. I updated my post, so there aren’t any ttTable joins now.
So I am trying to combine what you have drawn out with Tims suggestion to about using the Head/Asm Analysis Code. The reason is because I like the idea of allowing Engineering to turn the notification option back on if needed.
That being said, is there a way to modify what you have to do something more like:
The ttJobHead.JobReleased field has changed from False to True
Set Var. Job_PartNum = ttJobHead.PartNum
Then check If ERP.Part.AnalysisCode = NEW/REV if it is Then
Email Engineering and Set ERP.Part.AnalysisCode = Null or Blank (So the next job doesn’t send the email as well).
Would I need to change this over to the Method Directive and Invoke Part.Update to do something like that?
Yep, you would need to change to method and invoke BO with the widget.
Okay, I have been trying the method directive way all day yesterday and only got part of it to work.
So maybe you can help me with a couple of questions I have.
For the Method Directive,
Question 1.) Would I still want to create it on the JobEntry Method such as JobEntry.ChangeJobHeadJobReleased?
(Right now this is where I have tried to build it)
Question 2.) Would I want a Pre-Process that checks that the Job Release is True and sends the email, then have a Post-Process that sets the Part.Analysis Code back to blank?
(I have tried putting it all on Pre -Process and had no luck. Then I tried to split it up to have the Check/Email on the pre with the Field setting on the post and I still cannot seem to get it to update the Part.Analysis code to blank.)
Question 3.) When trying to change the Part.Analysis Code back to blank, what would be the best BO to use and do I need multiple ones to accomplish this?
(I have tried just Part.Update and Part.GetByID/Part.GetRows with Part.Update. Every time I get an Error regarding the object)
Here is the second attempted I tried:
*Which does produce the Message, but I cannot figure out how to Changing the Part.Analysis code to blank.
Q1: I think that’s a great method for this BPM.
Q2: Since you won’t be updating anything until after the job is updated to released, I think everything could go in 1 post-processing directive. The analysis code update can definitely work here.
Q3: The Part.Update should be the BO Method you want to invoke (probably after the email is actually sent). It looks like it uses the same table set (PartTableSet) as the one that is returned by the Part.GetByID method (PartDetails). You should be able to update the PartDetails.AnalysisCode in a set field widget, then pass it in the parameters of the Part.Update BO widget. Can you post the error message you are getting when you try to do the Part.Update?
Here is the Error it gives me.
What I did:
1.) I place the Invoke BO Method
2.) Select to invoke Erp.Part.GetByID
3.) Set the configured parameters I set to PartNum in Va.PartNum and out to PartDetails
4.) Select ok
5.) I get this Error…
Hmm ok. I thought you said the BPM was working up until the message box (which included the GetByID widget)? Either way, you’re going to need 2 widgets I’m pretty sure. The Part.GetByID will get you the info about the part you want to update, then you can pass that info to another widget that calls Part.Update. I tested this a little, I think you’ll actually want to use Part.UpdateExt
It did work all the way through when I had it on Pre-Process. I moved it to Post-Process and then got the error. I will give that a try. By the way, thank you so much for helping me and for all the quick replies. I really appreciate it.
No problem!
Here’s something I set up that JUST updates a field on the part table when a job is released (I didn’t have analysis codes set up, so I just updated a UDChar field):
The ds parameter for the UpdateExt is a UpdExtPartTableset type variable, so the PartTableset that is returned by the GetByID method won’t work. Instead, I made a new UpdExtPartTableset variable that I fill with the PartTableset.Part in the “Fill Table by Query” widget:
I think you just need the key fields here, but I went ahead and brought everything over (including the updated UDChar field)
This updated the Part.UDChar01 field to “NEWCODE” for a job’s part when the job is released. I used UpdateExt because I couldn’t get Update to work.
1 Like
Oh My Goodness!! You are absolutely wonderful! That worked. That 100% worked. Thank you SOO much for all of your help with this! I appreciate it so much. You are 100% correct, it was the last two widgets that I was missing. Thank you Adam! 
You Rock!
1 Like
Good deal! Now that I think about it, the BPM probably doesn’t need the GetByID widget. Could have filled the UpdateExtTableset just with the standard part table (then update your field), and pass that to the UpdateExt widget. But either way, glad you got it working!