Create eCoC XML from controlled vehicle data
Creating an eCoC XML file starts with the vehicle record and its approval context. Select the receiving route and applicable schema first, map the reviewed source values to that structure, then generate a candidate you can reproduce. Converting a PDF or renaming a spreadsheet does not establish an IVI XML record.
Choose the destination before mapping
Write down the intended recipient, specification version and document revision used for the mapping. EUCARIS points implementers to IVI messagebooks and XSD resources. Its IVI guidance distinguishes the 1.x and 2.x structures; do not assume a mapping for one family works unchanged in another. UK files require the UK IVI XSD published by VCA.
Build a mapping sheet with accountable sources
For each destination concept, record the source system, source field, transformation, unit where relevant, applicability condition and review owner. A value can be absent because it is not applicable, has not arrived or is genuinely missing. Resolve those cases explicitly rather than filling every blank with a default.
- Vehicle identity: identify the production record that owns the VIN.
- Approval context: identify the controlled reference for the vehicle's type, variant and version.
- Vehicle-specific technical data: record the source revision and how applicability is determined.
- Multi-stage information: preserve the stage that supplied or changed a value.
A synthetic example: one stale source value
Suppose a fictitious vehicle V-001 was reviewed against source revision A. Before generation, the production team corrects a technical value in revision B. A useful generation process checks which revision is being used, requests review of the changed value and produces a new candidate linked to revision B. Copying the earlier draft and editing its XML by hand hides the relationship between the output and its source.
Generate a candidate, then test it
Retain the source-record revision, mapping revision, schema package identifier and output identifier. Check XML parsing and schema conformance, then compare the values against the approved vehicle record. Structural validity alone cannot tell whether the correct vehicle was selected. Keep the output pending until the responsible team resolves each failed check.
Hand over an evidence package
A practical handover includes the candidate XML, validation report, reviewed source reference and release decision. Identify which exact file enters signing or sealing. After that step, retain the returned artifact separately and verify it before submission. Generation, sealing and receiving-system acceptance are distinct outcomes; record each against the correct revision.
Where does Digital CoC fit?
Use the platform discussion to agree how your vehicle templates, data owners and review steps fit together. Confirm the actual XML mapping and destination requirements during the pilot. A repeatable, reviewable candidate is a useful first milestone before a wider integration.