Document control version tracking report fails data mapping to audit trail

QMS ETQ Reliance
, , , , , , , ,
1

Our document version history reports are failing to map correctly to the audit trail system. When we export version tracking data to XML format for compliance archival, critical metadata fields are either missing or incorrectly typed, creating gaps in our audit trail.

The XML schema mapping seems to be converting datetime fields to strings without timezone information, and the field type conversion is losing precision on version numbers (converting 2.1.3 to 2.13). This is causing significant compliance concerns as we can’t accurately reconstruct the document change history.

Here’s a sample of the problematic XML output:

<version>2.13</version>
<modifiedDate>2024-11-15</modifiedDate>
<approver>NULL</approver>

The metadata preservation is incomplete - approver names, review comments, and change reasons aren’t being captured. Has anyone resolved XML schema mapping issues for document version reports while maintaining audit trail integrity?

2

This looks like a data type mapping issue in your export configuration. ETQ 2022 should handle version numbers as strings to preserve the dot notation. Check if your XML schema definition has version defined as numeric instead of string type. That would explain the concatenation you’re seeing.

3

Thanks for the feedback. I’ve verified the XML schema has version as string type, but the field type conversion is still happening somewhere in the export process. The datetime issue is also critical - we need full ISO 8601 timestamps with timezone for regulatory compliance. Any ideas on forcing proper datetime formatting in XML exports?

4

I’ve dealt with similar audit trail integrity issues during data migrations. The problem often stems from ETQ using different internal representations for display versus export. Version numbers are stored as strings internally but sometimes get processed through numeric formatters during export. You might need to create a custom export script that bypasses the standard formatters and directly accesses the raw field values. This ensures metadata preservation without unwanted type conversions.

5

The missing approver and metadata fields are concerning from a compliance perspective. In our setup, we had to create a custom report template that explicitly includes all audit trail fields. The standard version history report doesn’t capture workflow metadata by default. You need to add those fields manually in the report designer and ensure they’re mapped to the correct XML elements in your schema definition.