Any drawbacks to us marking all fields on HR10 - Data Item Attributes to capture History? It seemed the logical way to go versus trying to narrow them down.

Thanks so much to all who graciously give of their time to us newcomers. :bow:

I can't see that it will hurt anything but I do think there is value in going through the exercise of evaluating the fields that you want to track history on. Depending on your setup, you'll find that there are numerous fields that you won't use and I don't see any reason to track history on those (personal preference). Also, going through the process may give you a feel for how Lawson organizes data.

There's one possible drawback I can think of right away -- large file size. If you have a lot of activity and a lot of employees, file size may be an issue.

We have over a thousand employees, and we're tracking just about everything. It seems that it's better to track than not to track. Just my 2-cents'-worth.

... and help you keep track of the fields that you actually are using.

If you Log History for fields that you use, and don't log history for fields that you don't use, then the HR History file will not be filled with "empty" and meaningless records. This is important if you intend to report on history regardless of the reporting tool (HR Writer, delivered reports like HR105, and the Query Tool).

To "lock down" a field (prevent it from being used), flag it as "Pers Action" on HR10, then do not include the field in any Personnel Action Codes (which are defined on PA50).

Be sure the HR10 DM (deduction master) topic is flagged appropriately for History, in addition to the E (employee) topics. If you log history on all the fields in the DM topic, the HR History file can get really big.

I agreee that file size is the biggest con and my experience has been that it is better to track than not to track.

We mark all our fields for history - and the only "issue" we've really encountered is when our users reverse a personnel action (which I'm personally trying to stop the process, since it's bad for auditing....) we will get the message that history doesn't exist for a field if it has data for the reversal, but previously didn't). It's a minor inconvenience because we have to add a line of blank history for the reversal, but HAVING the data has proved more than useful in the long run!! BTW, we process an average of 5000-7000 transactions per month, and haven't run into any table size issues at this point, and we've been live for several years without any archiving.