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 …
Are you trying to use transscope in a client customization or in a bpm or service on the server?
Transscope is a db API. ERP 10 is a layered architecture with no db functions on the client.
This is a Client Customization,
Then there is no such thing as a db transaction.
Thanks for a clear answer,
How to control the Data integrity then ?
Use the business object it’ll handle that for you. How are you creating your records?
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.
@Mark_Wonsil, that is the best description I’ve ever heard regarding Customization vs BPM.
This is all using Epicor BO’s, but with different approaches.
E,g: PO Detail is created by Epicor Methods picked up from Tracing, Then PO Rel, and then ReqDetail.
That’s true for other systems if they need integration, but if its related to specific needs, we ultimately need to put the source code in the UI.
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.
If you are already using the business objects you do not need to worry about transaction scope. The business objects handle that for you.
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?
josecgomez : This is what I am looking for a Transacton Scope here, and so far I realized that we can’t pull it in here.
i have a same requirement , if you don’t mind , could you please share the code with me.