I think the only way I can explain this properly is if I give a brief breakdown of our process for New Parts.
Step 1.) Quote Request comes in from Customer
Step 2.) Engineering Quotes it
Step 3.) If we win the Quote, we get a sales order which drive us to prepare for production
Note: (Some times larger parts/assemblies are broken down to sub- components/assemblies, but ONLY the finished good is connected to the Customer Part Number)
Step 4.) Once the Prep process is completed for New Part, a Make to inventory Job is cut and sent to the production floor
Note: (We only make to inventory, which I know that will make some of you wince lol)
Step 5.) Once the job is complete, parts are put into inventory
Step 6.) Shipping will kit the parts out and ship them to the customer
Now that you have a small overview of the process, here is what I am trying to figure out. Engineering is requesting to have some kind of notification put in place that tells them when a part is a first time build, but only for the âUpperâ level part that will be shipped out the door. They do not want to be notified for sub-assemblies/components. So the upper level part will be connected on a Sales Order, and Engineering only wants to know when the first job for the upper level part is cut for production.
What would be the best way to accomplish this? What would work best a BAQ, Method Directive, or Data Directive? The Engineers donât care how they are notified, they just need to be notified.
There is probably more than one way to do this, but it will certainly involve a BPM of either the Method or Data type. Iâd also probably use a UD field on the Part table. Hereâs what I first thought:
Create a UD field on the Part table for âalready made on a jobâ (this would have to be set TRUE for all parts that had ever been made on a job before)
DEPENDING on WHEN your engineers want the notification to be sent (when MRP creates the job? when Production Planning firms the job? when the first labor is reported against the job?), Iâd likely use a Method BPM looking for that condition, whether the jobâs part number exists on a sales order, and whether or not the âalready made on a jobâ checkbox is true at the part level.
if all those three things are in the right state (job is when engineering wants to be notified, part number is on a sales order, âalready madeâ is false), then the engineers get a buzz on their electric shock collars⌠AND the BPM would need to check that box on the Part table so it doesnât happen next time too.
You could use Data Directive BPM instead, each has its uses, but I almost always start with the Method ones first.
Thank you for the quick reply. That would be a fantastic fix. Unfortunately, I donât have the ability to create a UD Field on our Production platform yet. So I would need a way of doing this without creating a UD field. :\
That means youâd need to have a query in your BPM that looks at the JobHead table to see if that part number has been on a job before. If you have a LOT of jobs (hundreds of thousands or more), that query might take some time to run. THAT may impact what Method it could be used on, or if it would run efficiently on a Data Directive at all.
THAT adds a complication⌠if you use the "Releasedâ flag changing from FALSE to TRUE as your trigger to send out an notification, and a single job can be released, unreleased, and re-released, youâd need to find some way so duplicate notifications arenât sent if the SAME job number is âreleasedâ multiple times.
There should be pre-made UD fields on the JobHead table (UserChar1 etc.) that you could use to record when a job was initially released and the email is sent. Then, once the email is sent, you can update one of these UD fields to âemail sentâ or something, and use that field to filter out jobs that are re-released so they donât send out additional emails.
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.
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?
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?
