I am looking for ideas on how to implement a Order Change log. The idea is to add a new tab to the order entry which will display a Order Change Log as a grid with fields line #, change date, amount and description. The user will enter all fields whenever they make a change to an order line dollar value, add or delete a line, etc or cancel an order entirely.
Specifically looking on how I could define and link a db table to the OrderHed? Can I use UD tables, not sure how I could link it? Any other ideas?
I took a look at the booking function, it does capture some of what we want but not exactly. The same for logging, we are not looking to log every action. The idea of this is to leave it to the user to track specific activities at both the line and header level. Currently they are entering this information into an Order Change Log spreadsheet. This data will be used in reporting of monthly sales activities. If I need to do some custom coding to achieve this, that is fine.
You can add a UD Table as a child, then add that tab and grid to your screen to make lists of whatever you want. In the customization editor, there is a wizard to do this and it does most of the setup work for you. Then you can simply add a grid, bind to the view that was created for you, and off you go. Obviously there is going to be some tweaking, but itâs not too hard.
Why not just have the system capture the changes to the fields on the table you specify you want logging on? A simple data directive on the OrderHed and OrderDtl tables with the change log workflow element will achieve this.
Certainly a user can forget to add their changes, but they are currently trained to enter those changes in the Order Change Log spreadsheet and that has been working fine for many years. The change log would give too much information. We would like to capture a reason for a change as well, example a price increase was due to customer requested a different paint type.
The Book Details captures much of the information we need, just not everything we what in this instance. I have turned book details on just for the audit trail.
I like the idea of adding the UD Table, I will explore that option next.
Another thought would be to add UD fields to the Bookings table, for things like reason and comments. You could then create a BPM that would provide a BPM Form to capture the Reason and Comments WHEN either a certain Booking type record is created or the change is âsignificant enoughâ (for the BPM conditions to prompt the BPM Form.
I did something similar to this for the Order Header for when the Ship By Date is changed. It pops up a BPM Form prompting for comments and a Reason Code, which we created Reason Codes in UD Code Entry AKA User Codes Entry.
While the current process has been working fine for years, you have an opportunity here to automate a bit of that process and only prompt the user for additional details when needed, which can free up time to be used towards more value added tasks.
Where do I find instruction or example on adding a UD Table as a child? Where is the wizard found to do this? I could not find anything in the customization editor.
Iâm not at my computer, but in the menu items at the top of the customization editor, there is an option I think called customization wizards. When you open that there is a menu that letâs you choose what you want to do. Add UD table as a child is one of the options (other options include extended properties I think). Then you pick what you want your keys to be. Itâs all based on the views that are in the screen you are customizing. So on your case order entry.
What about a UD reason field that is captured in the built in change log. The field is cleared on a post process order update directive. You could add custom validation that the field needs a reason after a user changes certain fields.
While I appreciate everyoneâs thoughts on thisâŚI truly believe an over-engineered solution is being pushed here. The solution being proposed is more time consuming for the end users to enter the data accurately, and they may not like needing to navigate to an extra screen. Why not use automation and make their job a little easier too? While I donât have 20 min right now to whip up a demo of what I am thinking, I can give a high level overview.
Add a âReasonâ field on the order entry screen tied to a ud field (we will validate off this to ensure users enter a reason)
Include the reason field, and whatever fields you want to monitor in the change log on the order head and dtl data directives
Add validation that the reason field is populated with data using a method directive on the change existing order business object
Clear the reason field after an update using c#
Simple. Elegant. Effective. The reasons will be captured by the change log and whichever fields you want to monitor automatically. 1. You will make their job easier with less data entry 2. You will have more accurate data (you could even use UD codes for reasons so that reasons are consistent) and 3. You look like a superstar
Elegant until you realize you are storing a numeric value someone wants to report on in the middle of one long text field that is tracking all your changes. They would go back to the spreadsheet a week later when they try to add up the changes on an order.
Testing adding the UD Table as a child. Does this wizard actually work? I have added the table and linked a couple fields, the code gets generated. I have yet to compile it as the errors are endless.
I was able to do it without much hassle. You are on the order entry screen?
edit
I tried it and it worked just fine. Added Key1 and Key2 as OrderNum and OrderLine. It finished, now compile errors. What are some of the errors that you are seeing?
We are on different versions though, so maybe there has been some work done on it.
Okay, so a search of Epicareâs sup[port KB revealed KB0030682 which basically says that in order to actually do this you have to match up the first 4 UD Key fields with something, otherwise there is nothing to return with a vague reference to possibly handling missing keys better in the future.
To fix it, he just used duplicate values for the keys he didnât need. (so make both Key3 and Key4 orderline or something)
Obviously itâs been fixed in future versions. That user was on 10.2.100
And his would compile and was on a different screen, so it may not be the same problem.
