Kinetic UI and Classic UI Using Different Service Method For Same Action?

We are currently implementing Epicor and just starting to familiarize ourselves with basic customizations. To help educate ourselves on all the different ICE tools and get familiar with them, we wanted to see if we could implement a simple customization using a few different techniques. Our goal was to make the system throw an exception/error when clicking “Create” after launching the “Quote Order Wizard” within “Opportunity/Quote Entry” if the “Need By” date was blank. We wanted to see if we could first achieve this through a BPM method directive so that this logic would be applied in both UIs and then we were going to test our abilities using “Events” within “Application Studio” to see if we could achieve the same result in Kinetic solely.

However, when trying to determine what Service Method to attach the method directive, we discovered that the Kinetic UI and Class UI utilize different service methods when clicking “Create” in the “Quote Order Wizard.” Can anyone confirm whether or not this type of situation is prevalent throughout the application? Recently, we reached out to Epicor about developing a customization for us, and the consultant assigned let me know that for the time being (while Classic and Kinetic forms are still available), they plan to continue using BPM directives almost exclusively to implement custom application logic so that the logic is applied across both UIs. But what’s the point of that if they use different service methods to accomplish the same task? I then have to create multiple directives. This also feeds into a bigger question that I have…

What’s everyone’s approach to customizations with the updated interface? I know that this limbo phase where both UIs are available and need to be supported by existing and new customizations makes it murkier, but what will be the best way to customize the system when the Classic UI no longer exists? Will be it be solely in “Application Studio”? Will BPM directives still play a role depending on the scenario? I know that the BPM directive maintenance screens haven’t been lifted to Kinetic yet, but I would assume that they have to be unless there is going to be a conversion process for creating events from BPM directives. I’m really just curios as to the different philosophies regarding customizations both now and in the future.


Can you mention which method is used in which interface? I know this happens on some screens, I don’t think we have a list but what I have seen is that while the classic UI used to retrieve everything, in kinetic sometimes we just want specific pieces so a separate server side logic was added.

As Jonathan mentioned, if the trace changes (to improve performance in this case), then there’s going to be some reconciliation to do. And it really depends on the nature of the directive. I can’t think of a case where a data directive is affected by the UI change without a wholesale change of the business object - which could happen but is rare.

The ICE User Guide describes the various directives and you see that the UI is abstracted away. But you’re correct, if Epicor changes the trace between the UIs, maybe that should be disclosed as a breaking change. :person_shrugging:

The Kinetic UI calls CreateOrderFromQuote while the Classic UI calls CreateOrder.

It seems this was needed because with kinetic we try to move as much stuff as possible from the UI to the Backend, and it seems this is what happened here.

But I can see that internally CreateOrderFromQuote calls CreateOrder, so any bpms should trigger in both Classic/New UX, it just has some additional preprocessing which I guess it was either done on the classic client, or required additional server calls before CreateOrder was called.

1 Like

I’m pretty sure that both Classic and Kinetic can each call CreateOrderFromQuote and CreateOrder depending on the menu item (Actions | Get Opportunity/Quote). And like Jonathon says, both will end up calling CreateOrder.

1 Like

Thanks for the responses. Jonathan, you were correct. The directive was created on CreateOrder and triggered in both UIs.