I was asked to put together a method directive that pops a message when a part is added to a customer shipment that meets a certain condition with a UD field on the part table. Given this information, do you think it would be possible to create a BPM without custom code, or is this something that I would need to write something to handle?
Should be do-able with widgets but it really depends how complex the condition is. Something to consider are the various ways to create a pack line and how each might or might not get the message depending on what BO you put it on.
It is my understanding that our logistic team just enters shipments in the customer shipment entry screen.
My problem now becomes when I add a condition widget/shape, it does not give me the part table in the drop down
In that condition widget type the only tables available will be the transient data tables used for that BO and screen. You will need to pull in the Part table through a query condition. Note that before you do that you will have to get the keys needed to join the part table from the ttShipDtl table first. You canāt do a direct join between the Part and ttShipDtl tables unless you want to have a real bad time. I would create a local set of variables to store Company and PartNum and then use those in your query condition.
Excuse my ignorance, but when you say through a query condition, is that a different shape/widget than the condition one?
@cnewbould
It is the same condition widget, but a different option for the widget.
But if you are new to BPMās you should really get familiar with them by reading through a bit of documentation. Depending on what version you are on, there are different options.
But if you are just checking for a field value for the part to determine a pop up, there is no need for custom code. Iād suggest that the vast majority of BPMās do not need to be custom code anymore.
What version of Epicor are you working with?
We are a cloud customer running 11.2.300, and yes you correct in that I am getting my feet wet with BPMs.
Iām going through the BPM cookbook, but if you have any other suggestions on documentation, training videos, etc., I would appreciate that.
My end goal here is once a line is added via customer shipment entry, if a UD flag on the part is marked as true, to pop a message box when a user goes to save the line item. It seems like I would need to create a pre-processing method directive invoking Update Master. I guess now I need to figure out how to pull back the UD field from the parts table to see if it is flagged as true.
The BPM Cookbook is great for getting familiar and examples.
Based on what you describe you want to do, here are some tips:
- Use the Trace to help determine which BO Method would be best to put the BPM on.
- There are two types of BPMās, Method Directives and Data Directives. Method Directives have Pre/Post and Data Directives have Standard/In-Transaction.
- Method Directives are great for when something changes but the record is not yet saved. The trace can help you identify the Method that was called, that you can then use. For instance you will see OnChange methods, for when a Customer on a Sales Order is changed or a Part is changed.
- Data Directives are ideal when the record is being saved.
- You said, you want a pop up when a Pack Line is saved. If it were me, I would try a Data Directive on the ShipDtl table, In-Transaction. In-Transaction because showing a message widget is available there. Youāll basically do a Condition widget, that will check for query row count > 1, and you define the query to check for the ShipDtl.PartNum in the Part table and where the UD field is true. Then on the true side of the condition, you would use the Show Message (or exception) widget to define the message you want.
Like @jgiese.wci said, you want to get your keys from ShipDtl and assign them to variables (create them on the variable tab and use the Assign widget to set them), then you can use the widgets in your Query.
I donāt want to give it all away, just wanted to get you in the right place and have an idea how it should be constructed, but itās best if you struggle a little working things out so you learn best.
Thanks Rick, I appreciate you taking the time to provide this high level overview. From my readings on this forum, it seems like we want to avoid Data Directives at all possible as they are worse off for performance? That is why I was thinking about using a method directive
@cnewbould
While Data Directives are marginally slower, I wouldnāt say avoid at all possible.
Perhaps you can share the post that gives that advice?
I use whatever fits best for the situation. While I do first attempt to use a Method Directive, it depends on the BPM requirements.
1 Like
Thanks Rick and Joshua for the help! I think I have it figured out what I need to do but Iām sure something will come up.
Is it best practice to limit the amount of custom code within the workflow and just use the āShapesā or does that not matter on performance?
1 Like
It can be argued that Custom Code is better for performance.
But in my experience, custom code can create upgrading challenges.
I have found widgets to be a better choice for upgrading, but others will argue it doesnāt matter.
Personally, I see it as Epicor has provided tools for users of different skills.
I prefer to first use widgets where possible and if that is challenging or what I need to do cannot be done with widgets then I will use Custom Code widgets. But even then I try to use widgets as much as possible. Just my preference, all about your comfort level and who may need to support it later. I had a college professor once give the advice to write and comment your code as if the person who will inherit your code is a closet serial killer with your addressā¦
Also, I wouldnāt chase āperformanceā too much, since performance is somewhat fluid and dependent on many things, which can change, and Iāve seen change from version to version. Something that performed fine or awesome in one version is a disaster in another, and sometimes it doesnāt make senseā¦ Remember you are writing BPMās or customizations that are dependent on Epicor base code, if they change something, you have to accommodate itā¦ they have more control over performance than you do really.