I’m trying to complete a customization that creates and deletes records from UD tables (UD100 and UD100A) in synch with the creation and “finalization” of a sales order. We want to store calculated data within these UD fields that can be difficult to store within the Order Entry tables. I’ve found that adding too many custom functions to Order Entry has sometimes caused competition with Epicor functions for record access and updates.
I’m using the ‘AfterAdapterMethod’ function to detect the creation of new OrderHed and/or OrderDtl records, but I can’t figure out how to tell… A) when a record is deleted, and B) which record has been deleted. The traces I’ve run show no hint of deletions, which I find rather strange.
If anyone has done anything similar, or has some insight into what I might try, I’d sure appreciate a bit of guidance on this. Thanks.
You mentioned after adapter method… Am i correct in assuming you are trying to do all this client side in a UI customization? If so what you’re trying to accomplish might well be better supported on the server side with BPM’s. This will allow you to more consistently and accurately trigger from method events and row states such as ADDED|UPDATED|DELETED Many times Epicor doesn’t exactly expose methods publicly through the UI’s making it difficult to consistently implement efforts such as this.
Your assumption is correct and I did not realize the delineation was so clear between BPMs (server side) and customizations (client side). I had no idea, actually, but it makes perfect sense now that I think about it.
If I were to use BPMs, I’m guessing I’d be limited to ABL in order to do everything I’d need to do (record handling, data manipulation and calculations, etc)? One of my concerns is that we’re going to start the migration planning for moving to E10 later this year and I don’t want to build anything that’ll be problematic later. Are these concerns justified?
Your worries are somewhat justified on the conversion aspect migrating from ABL to C#. While Epicor does provide a tool (Code Converter) for the translation, it isn’t bullet proof and the code will need to be revisited at the very least. If your customization is going to be used or relied on with any regularity I would either wait to implement it if you don’t want to deal with the migration issue, or write it in ABL and deal with the migration/translation. There is lots of help on here with ABL coding (I’ve written a fair amount, and others here even more so) as well as the C# side of it. I had to convert a fair amount of ABL and it wasn’t too bad, but it all had to be looked at for sure.
Thanks Rob,
I’ve been examining the level of user interactivity that’ll be required of the newly-created records as a part of the customization.
The UD records will have to function as extensions of the OrderHed/OrderDtl records and be available for bound controls.
Perhaps, I’ll have to mix BPMs and C#, as I really don’t want to have to try to figure out how to populate a Combo Box using ABL - if that’s even possible.
Is it possible that client-side C# may be preferable in this case? Or perhaps stick with BPMs for CRUD operations while using C# for interactivity? Whew! This’ll be fun.
Well, you don’t have to tell me three times. Thank you!
Rob, I appreciate the guidance. I’m glad I found this site as I’ll undoubtedly be posting a question or two as I undertake this challenge.