I have successfully achieved creating the PO Lines, Releases and linking to Requisition Lines based on additional Tab on PO Entry that shows Approved Req. Lines.
However, I am looking to encapulate all 3 areas under Transaction Scope.
I tried to use the Transaction Scope, but system is not happy without including Assembly References. I tried to include System.Transaction dll file from : C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.5 But looks like this is not working.
Has someone worked in this way ?
Please provide the code and/or addition of references …
When Epicor moved from Vantage 6 to Vantage 8 (the predecessors to Epicor 9 and 10), they separated the UI from the business logic. Technically, the Customization is the method used to alter the behavior of the UI but that hasn’t stopped users from placing business logic there. The BPM process is the method for users to change the behavior of code at the server. Alternatively, one can purchase the SDK to get full control of server-side code.
The other reason not to put business logic in the UI is that other systems that interact with the business objects (WCF, REST, and even UBAQ) will not see the logic in a UI elsewhere.
I have seen multiple times where someone added some business logic directly in the UI for sales… the new business logic worked well UNTIL they did something that doesn’t use the UI… for example:
modify the Sales Order UI to do something/populate a UD field when an order is created, or lines added, or schedule change, or something else happens… it will work well, and test well… all the testers are happy.
but then someone creates an order from a Quote… since they are not in the UI, the logic in that UI doesnt fire, and the UD Fields are not populated.
By putting the business logic into BPMs (in this case, Data BPMs), the new logic fires both when you save the sales order, AND when the quote is converted to an order. The logic only needs to reside in one location.
Since the UI has no transaction-scope then you’ll need to code that in the UI too. I would be surprised if there isn’t a way to do this as a combination Customization/BPM. Professional curiosity wants me to understand what kind of specific needs (the business problem not the coding problem) leads to a UI-only solution.
Ok - The need is to allow user to select Approved Requisition Lines using a Customized Grid, and Attach them in a PO, also Link the PO / PO Line to the Requisition Line
Let me try to crash the code (through Debugging, I guess) and see if it does rollback. I feel that the PO Line and PO Rel can get rollback But will Req. Lines also ? a check is required.
I guess it depends to what you mean by roll back.
Each table is its own component so if you’ve already created a POHeader and a POLine they won’t get automatically deleted if someone else happens down the line.
You’ll have to handle that yourself.
We recently have started using Agile methods to run our Epicor processes. It’s a bit experimental to use Scrum for non-development tasks. One of the first things I have learned (and still learning) is how to phrase a user-story/issue without having a solution in mind. Our Scrum Master knows little about programming or ERP so any time I say BAQ, grid, form, etc. he asks me to “State the business need - not the technology need. Quit ‘solutioning’”
Epicor has a method to convert requisitions to purchase orders already. What do the users not like about that process so much so that they’ve asked you to re-implement it?