I’m looking to create a BPM to change the job prefix depending on the part’s reference category.
Right now, our MRP jobs prefix is “UF” and the regular jobs are set to “S” for now.
My condition is that, if the part is a new part (NPI), then when firming UF jobs, it would have “N” as a prefix plus the next job seq. For example N00010.
Similarly, if the part is a regular part, then when firming UF jobs, it would have “S” as a prefix plus the next job seq. For example S00011.
I’m halfway there with my process. I created a post-processing for JobEntry.CheckUnfirmJob. I also did get the conditioning part down (checking the part’s status). However, I got stuck on changing the prefix part. I managed “solved” the issue by updating the Site Configuration field every time this BPM runs but I think this is a bad idea. Anyone else might have a better suggestion or any pointers?
IMO, job numbers should just be job numbers. Avoid turning them into secret codes. If you want to highlight something special for a job, create a field for that purpose.
Thanks John! That’s exactly my thoughts as well but this is 10+ years of practice here and I guess people do really hate changes. Trust me I fought tooth and nail on this one.
Every shop wants to turn the job# into a cypher. I get that. My typical response is to just build my proposed change, and tell them that it’s the recommended practice over whatever bad idea you were originally pitched. 99% of the time they either accept it right away, or suggest a minor tweak.
It’s simple enough to look through JobHead and figure out whether or not a job is the first for a part or rev. Turn that into a custom checkbox, or a calculated field on the form. The on-the-fly method has the added advantage of updating itself should someone insert a new “first” job earlier in the pipeline.
For example, the Inv/WIP Recon report just shows only job numbers, and it can be helpful when the number has meaning. Less to cross-reference by hand.
On the other hand, I also don’t really care. I have pushed for years to get past this notion. I have a screen called “Time Phase with Projects” and it shows extra information so that we don’t need the job number to be special. But it has never been enough. So instead, every day or so, we delete the (massive) unfirm jobs and create new, identical ones from scratch with our special job numbers. Total waste of time. But I can’t win every fight. However, it seems our new COO is very open to this so there is hope…
PS, myself and others in this forum have tried to lick this BPM issue before, to no avail.
OPINION (getting on my soapbox)…
Job numbers are just that… a number. There should be NO MEANING to the number itself. It is a one time use thingy, and it doesn’t matter what that number is. Trying to put meaning into the job number just starts you down the path that can cause problems. Putting meaning into things like Job numbers (Or Sales Orders, or POs, or RMA, etc) takes us back to the 1980s when there were so few fields in the database that we had to bury data into other fields. (TRUE STORY: One time I called a computer company for an RMA to return a computer… after answering 10 questions, they gave me an RMA number that was about 35 digits long… buried in the RMA number were all my answers.)
Now… for the additional facts… I never found it possible to have a BPM to modify the job number, ESPECIALLY since MRP creates those job numbers. Note that MRP will create UNFIRM jobs, but there is also the possibility for MRP to automatically firm jobs, or for your users to firm jobs in multiple different paths.
Your BEST path is to reeducate your team so that they don’t look at the JOB NUMBER for any meaning, and instead look at the other information in the job (part number, description, product group, other UD Fields) to get the information you need.
OK… I am off my soapbox… you may proceed with your day.
I, too, prefer a separate field. Where necessary, the two can be combined in a formula. If a job is mis-categorized, you don’t have to delete the job to change it. Just like orders, POs, etc., it’s just a number…
Another example… when you buy a car, the license plate that you get does not define the year, model, make, etc… it is simply the next value available in the license plate series (unless you purchase the Vanity plate option).
BUT a License plate DOES have the STATE that issued the plate… This is something that we CAN do with job numbers (applying a prefix to the job different for each SITE). That is the only “meaning” that we apply to job numbers, and even that, I do not like to have for anything other than unfirm jobs. (my option again).
Thank you all for your constructive feedback. Seems like it’s time for us to radically evaluate our process. You guys are right, job number should be a job number.
“The good news is we came a long way, the bad news is we came the wrong way.” - J. Cole
