Changelogs difficult for end users

Epicor ERP 10
1

Our end users are confused by the changelogs. I believe the source of the confusion is they are expecting user interface level changelogs(e.g. I clicked Action->Freight), where the changelogs are at the database level(these 10 fields were updated today) and they don’t have an understanding of how UI actions map to database changes. I believe this is inherent complexity that can’t be avoided, but just wanted to ask in case there is a simpler solution for our end users to understand the changelogs.

Any suggestions?

2

I’m still quite a beginner in terms of Epicor so I’m sure there’s a better suggestion, but you could build a tracker dashboard and embed it in the window that you’re talking about. Then it could display the field that was changed and the new value of the field. Over time you would then see the change history in the dashboard.

3

The confusion seems to be they don’t understand the fields in the database, so it is confusing to them when they do something simple(click Action->Freight) there isn’t a simple 1 line change indicating user x clicked Freight in the changelog. Instead there are many rows, one for each database field indicating what it was and what it is now with their name next to it. The response is what’s all this clutter, I don’t know what those things(fields) are / I didn’t change those. How do we get rid of this clutter and make this simpler?

4

You could make MD BPM’s that add to the change log. Just make sure your additions are in the right structure.

You might not know the exact UI action that caused the BPM to fire, but you could record that the BPM happened. And if it is something that is only ever user initiated, then the log text could indicate the possible ways it happened.

For example, the Shiphead.Status changes to SHIPPED, when either :
A) the Shipped checkbox is marked in Packer Entry
-OR-
B) you answer “Yes” to the question of “Ready to Ship?” after printing the packer.

The Log Text could be, “Packer marked SHIPPED, by checkbox, or after printing packer.”

If you really need to know which UI action caused it, you might need to customize the form, and either update the ChangeLog in the customization, or have the customization create a UD table entry, and let the BPM read that UD table, for determining the exact ChangeLog text.

5

Thanks @ckrusen, I realize I should have mentioned how we are updating the changelogs :slight_smile: Currently we are using data directives. Is there a better way to do this?

image
image874×644 59.9 KB

6

Data Directives is the correct way to do it. Adding to the ChangLog tables any other way is a bit of a hack.

Another alternative, would be to make your own “ActionLog” in a UD table. This would require a lot more work, but wouldn’t possibly interfere with the built-in change log.

7

Sounds like at the end of the day, if we want to log database changes, then people need to understand what the database tables/fields are to understand the changelogs and if they don’t they will be potentially confused by the changelogs which is what we’re seeing.

8

How long have you been live? I hear you on this and also like that dashboard idea, but maybe this is something that people will just have to get used to. For as maddening as some users can be with initial criticisms, I’ve found that most are remarkably capable of getting used to things like this over time.

1 Like
9

@TomAlexander Good point we’ve been live on E10 for about 6 months. Users are constantly wanting things changed / improved, so it can be difficult at times to decipher when we really can / should improve things or if the current solution is OK just different than what they are used to(Who moved my cheese?). I’m thinking this is more a case of the current solution is OK, might just take some time for people to get used to it and occasionally ask for help if they don’t understand a changelog :slight_smile:

10

I played around for a bit and came up with an “Action Log”.

It is implemented as a customization at the form level. Use the Form Event Wizard to make a BeforeTool event, and set it like:

private void QuoteForm_BeforeToolClick(object sender, Ice.Lib.Framework.BeforeToolClickEventArgs args)
	{
	Ice.Core.Session ss=(Ice.Core.Session)QuoteForm.Session;
	//MessageBox.Show(args.Tool.Key);
	
	string cs = args.Tool.Key;
	string userID = ss.UserID;
	DateTime localDate = DateTime.Now;
	
	EpiDataView edvQuoteHed = (EpiDataView)(oTrans.EpiDataViews["QuoteHed"]);
	
	if(edvQuoteHed.HasRow){
		string ActionLog = edvQuoteHed.dataView[edvQuoteHed.Row]["QuoteComment"].ToString();
		
		ActionLog = ActionLog + Environment.NewLine;
		ActionLog = ActionLog + localDate.ToString();
		ActionLog = ActionLog + " by: " + userID + ": "; 
		ActionLog = ActionLog + " Tool used: " + cs ;
		edvQuoteHed.dataView[edvQuoteHed.Row]["QuoteComment"] = ActionLog;
		}
	}

(note there’s a bug in that. It doesn’t work right when no Quote is loaded.)
Edit: changed if() to check if edv HasRow. Should work fine now.

That writes it to the QuoteHed.QuoteComments, but you could add a UD Column to OrderHed, and add a sheet to display that UD field as a read only.

Here’s a sample:
image

2 Likes
11

Maybe off-base, but something I have taught the users is to split the screen and save the layout, like this:

image
image1220×605 28.8 KB

This is so they don’t have to flip back and forth between the List and Detail tabs.

I know the issue is that it’s logged in geek-speak, but the layout does make a world of difference.

4 Likes
12

This is pretty cool

13

There are also different options for how the change log is captured. Under Company Configuration > Modules > All Modules > General. Change log collection methods are daily, by user, by transaction. You could play with those settings in a test environment and see if that helps any.

I’m not sure when this feature came out, but I know it’s in 10.1.

Jenn

1 Like
14

@JennL thank you this is really good to know. I think this might help!!!

15

Peeling back the onion a bit… How/why are endusers looking at changelogs? Most companies I work with who use them have a need because of compliance reasons (i.e. SOX) and auditing.

I’ve also run into some who either don’t trust the system is doing things correctly or look to place blame for errors. Usually I see this for the first 3-9 months after go-live, resulting from early mistakes or some users not knowing how to do their transactions correctly. To prevent them from going down a rabbit hole, focusing on making sure the processes are solid (and documented) and doing some additional training usually makes these reasons go away so they can spend time on analyzing data instead of errors.\

If you think it is more of the second, digging into the underlying reasons takes more time upfront but ends up with everyone happier overall…

1 Like
16

THIS

But on a serious note… The change logs helped me do a post-mortem on an issue we were having. The logs ended up showing the exact sequence of events that led to the problem.

FWIW - The Part number on an Order was changed after the Packer was created, but before it was marked shipped.

2 Likes