Trailing white space changes can be difficult to determine when looking at the Old Value and New Value columns of the grid. For example, if a user changes the text “Hot Dog” to “Hot Dog ”, the user would not be able to tell that something changed, because the Old/ New values would appear to look the same. Because of this, changes of this type display the Old/New value, followed by the value in quotes to show where the extra space characters exist. For example, the new value for “Hot Dog” changing to “Hot Dog” appears like this: Hot Dog (“Hot Dog”).
Changes made in the Property Merchant Groups module are treated like a single-record module (similar to RVC Parameters or Property Descriptors); all records for this module are logged without an Object Number.
Other than the name, changes in the Selection Hierarchies module are not currently logged to Audit Trail.
When a macro record is created, its 16 steps are not created. The first time a macro record is saved after its creation, Audit Trail shows each step being added.
The configurable data for Credit Card Drivers and Credit Card Merchant Groups are displayed in EMC using standard controls that are found throughout EMC. However, this data is actually stored in the database in a single data column as an XML string. Because of this, changes in these modules show the Field as Configuration, and the Old/New values display the entire XML string.
When an Audit Trail report is taken, this activity is logged to Audit Trail. All generated Audit Trail Reports are logged as an Enterprise-Level activity.
Internationalization
Text is stored in the AUDIT_TRAIL database table so that an EMC user views the text in his/her own language. For example, if a user from England changes Menu Item Class option bit 1 from ON to OFF, the data is stored in the table so that the Audit Trail report shows the name of the option in Japanese for an EMC user from Japan. (The Audit Trail report translates the text key that is stored in the database at the time the Audit Trail report is generated, using the logged-in user's EmcText file.)
The following table summarizes the methods for Audit Trail internationalization:
Table 3-3 Audit Trail Translation Capabilities
Audit Trail Column(s) | Description | Translatable? |
---|---|---|
Employee Application Module Operation |
These fields are all stored as numbers in the database. When taking the report, the number is converted into the appropriate text. |
Yes |
Field |
The name of the field or option bit that was changed. |
Yes |
Sub-record Name |
The name of the sub-record. A “sub-record” is something that has its own database table but is used by other records. Examples include Macro Steps, Workstation Devices, and Touchscreen Keys, etc. |
Yes |
Sub-record Field |
The name of the field for the sub-record. For example, a Touchscreen Key legend or a KDS Bump Bar Scan code Value. |
Yes |
Old Value New Value |
Displays the old/new values of a changed record. |
Sometimes. In most cases, these fields are not translatable. For example, if a user changes a Menu Item Definition's SLU or name, Audit Trail determines the old/new value appropriately; there is no need for translation. Sometimes this field is translated when the change is made as an example, if a Discount's Menu Level #1 is changed from ON to OFF, the text “ON” and “OFF” comes from the EmcText file of the EMC handler. |
Comments |
The data in this field is typically not used by EMC end-users. It is simply a mechanism for providing more information about the audit trail record. |
No |
Parent topic: Audit Trail