BPM Examples

,

Good morning Epicor Community!

I wanted to create a post that gives everyone an opportunity to share how they’re using or have used BPMs in their current or past Epicor environments.

Maybe you’d like to share some of your favorite BPMs or one that you’re most proud of?

I am looking for inspiration and ideas that’ll help me and others in future BPM developments!

As always, you guys are the best, and I appreciate all you’ve helped me with.

2 Likes

Great idea Mike, im relatively new to BPM and would also like some ideas where possible

1 Like

I’ve got over 100 BPM’s at the moment, so I don’t recall everything that they do off the top of my head, but here’s the headlines:

  • Strip out weird characters, leading/trailing spaces, and other general nonsense from new PartNums.

  • Ditto for JobNums. In fact I force a fairly strict control over them to keep people from inventing their own secret codes. It’s one of a handful of Data Directives and the only DD that calls a function.

  • I turned the “on hold” checkbox in Order Entry from a soft warn a hard stop in shipment entry.

  • Disable various stock processes that, for practical or policy reasons, we don’t want them doing.

  • Rules based system that selects indirect codes automatically for users since they were not reliably selecting the right one.

  • Email alerting when a business event happens. Though, that’s more of a past thing. I’ve moved those into scheduled functions that trigger periodically to avoid spamming users.

  • Revision control system. Once you approve a rev, you cannot alter it. A new rev is required. This is also combined with a system for controlling the Rev field to include a customer/internal rev sequence. Plus, I hijacked Express Part Checkout to create a new internal rev rather than checkout the existing rev. There’s other QoL items to make this fairly easy for users. The whole thing is over a half-dozen BPM’s leaning on a library of about as many functions to drive the custom logic.

  • Sign-off routines where someone checks a box to approve/acknowledge something in the system and the BPM logs user and DateTime to UD fields (which are either read-only or invisible to the user).

  • System that uses ECM/DocStar to manage Supplier Certificates, the expire data attached to the doc as metadata, and warns/blocks users trying to cut PO’s or ship items to vendors with expired certs.

  • Various bits of custom logic that turn UD apps into something with actual rules that tie back into the stock modules.

  • Auto-print barcode labels. It sends an API call to Bartender.

4 Likes

10 years ago I built a class called “Five BPMs every consultant should know how to create”.
Here was the agenda:

Here are the main slides:

Main lesson on the next slide… do not do change logs without a condition… in the case of Jobs… only log FIRM jobs, because if you dont, then MRP will create change log entries for all sorts of things, and your change logs will be huge.

10 Likes

funeral im back GIF

Y’all over here digging up bones :rofl:

Hi John,

Great insight to some possibilities.

i am particularly interested in the revision control system, would it be possible to share how youve captured this?

  • Revision control system. Once you approve a rev, you cannot alter it. A new rev is required. This is also combined with a system for controlling the Rev field to include a customer/internal rev sequence. Plus, I hijacked Express Part Checkout to create a new internal rev rather than checkout the existing rev. There’s other QoL items to make this fairly easy for users. The whole thing is over a half-dozen BPM’s leaning on a library of about as many functions to drive the custom logic.

I don’t want to oversell this, it’s a rudimentary system. It’s not like I shoved Git into E10.

  1. Once an revision is approved, it cannot be altered. Accomplished by UD fields corresponding to the canned approved date and by fields, but they don’t get blanked when items are unapproved. BPM’s run checks on UDFs when user attempts to check-in a rev. Note that the permanent approval data was needed for its own sake. For the occasional accidental check-in, select users can override this. It’s not common. In fact, it’s so rare I haven’t delegated override authority to anyone. I’m the only one that can do it.

  2. Distinction between customer revision and internal revision. Each revision is delimited CustRev + “/” + two digit internal rev. Cust rev isn’t controlled by us (using theirs makes paperwork easier) so parsing this was kind of tricky.

  3. BPM’s that not only enforce the use of internal revisions, but auto-apply and increment them so users don’t have to keep track of which sequence they’re on (which they did in v1, many moons ago). Since each customer rev is considered its own “branch” the incrementer treats them all differently. New cust rev = counter resets to “00”.

  4. QoL features that make uplifting revisions about as easy as checking-out and back in. I hijacked Express Check Out to auto-increment internal revs (this was delightfully straightforward). New Customer revs are created from EWB or the normal “check out” action in Part Entry. There’s also a button in EWB that wipes the checked-out rev and repopulates it from a selected base rev, including all alt methods.

  5. Reporting that tracks rev changes over time, ID jobs using obsolete revisions (which was extremely hard for us to do before this was implemented), controls that force new jobs to use approved revs, and a mock router matching the format of our job router that lets stakeholders review new revs before approval.

What I won’t oversell was how much of a culture shock this was to everyone. We were as lax as the system let us. Prior to this, customers (at the time, at least) rarely up-revved their specs. So a part would sit on a base or second rev forever, regardless of how much our internal processes or documentation changed. Except the revision wasn’t really static. It was constantly edited and re-edited to keep the MoM current (when they were able to properly, manually ID which parts needed revising).

However, there was zero transparency to any of this. There might be a half dozen jobs mid-flight for any given part. However the MoM might be updated multiple times between the release of the first job and completion of the last. It was chaotic for those downstream, albeit easier for those upstream since there was no accountability. The writing was on the wall when we started getting bigger customers who had strict frozen planning requirements.

I had to defend against multiple attempts to water things down. Sometimes in meetings. Sometimes when people tried to find a workaround. I stood firm though. Eventually people relented. Then adapted. Then I got the occasional email from someone who said this system saved them a day of work that would have otherwise been lost by accident. There’s one guy who still hates me for all this. That brings me joy though.

2 Likes

denzel washington GIF

1 Like

This is exactly where im at, i need the ability to do everything you describe above. Is there a way you can share the BPM for me to trial in pilot? would be most grateful :slight_smile:

Whilst we’re on the BPM subject, im looking to create a notification to the user to ensure and item marked as shipment programming is sent for programming prior to dispatch, so at point of picking would be ideal. do you have any suggestions for this?

New Epicor user here. I signed in just to like this post :rofl:

3 Likes