- Who is this for?
- Logistics managers, WMS teams, IT departments, and quality managers
- Question addressed
- Automate delivery document ingestion into a WMS.
Key takeaways
- The target field depends on the workflow and the WMS, not only on the label that was read.
- Normalization must be defined using real-world examples.
- The confidence level must lead to either validation or an explicit exception.
- The source document and the transmitted data must remain traceable to each other.
- A captured value is not yet business-ready data: it must be assigned to a field, typed, normalised and validated.
- The mapping is a versioned contract between the document, the workflow rules and the target WMS data model.
- Validation must test relationships between fields as well as the legibility of each value in isolation.
- A WMS write is complete only after its outcome has been checked; a result that cannot be verified must remain an exception.
- Vidoc prepares and sends validated document data to a WMS; Vigilo maintains continuity across transport events, rules, decisions and actions.
Reading is not mapping
A document may display “Lot,” “Batch,” an internal reference, or a handwritten value. OCR returns a character string. The workflow must still determine what it means, which format is expected, and which WMS field it belongs to.
This step depends on the structure of the documents actually received and the data model actually in use. This is why universal compatibility cannot be inferred from a simple list of formats.
A practical ingestion workflow
- 01Receive
Identify the channel, the document, and the potential logistics record.
- 02Classify
Identify the document type and the relevant version.
- 03Extract
Read the values and their surrounding context.
- 04Normalize
Apply the expected formats, units, naming conventions, and validation rules.
- 05Map
Link each value to its defined WMS field.
- 06Validate
Check consistency, then transmit the data or escalate the case.
Examples of checks before transmission
- the product reference exists in the approved master data;
- the extracted unit matches the expected unit;
- the date uses the required format and falls within the permitted range;
- the batch number is consistent with the relevant line item;
- the total quantity matches the legible details;
- mandatory fields are present or explicitly flagged as missing.
The role of Vidoc
Vidoc is designed for this ingestion and field-preparation workflow. The documents, values, rules, target systems, and actions are defined for the workflow in scope. Incomplete or inconsistent cases remain visible for review.
Vigilo and Vidoc serve distinct purposes: Vigilo connects the transport record from end to end, while Vidoc addresses the more focused logistics requirement of sending delivery document data to the WMS.
Define the field contract before reading documents
An ingestion project should start with the data the WMS actually needs, not with a promise to read every document. For each delivery-note type, the team defines the required business field, its data type, whether it is mandatory or conditional, its reference source and what should happen when it is missing.
This contract keeps three separate concepts from being conflated: the label printed on the document, the normalised business value and the technical destination field. Process and WMS owners should review it, and it should be versioned whenever the document or target model changes.
| Scoping question | Decision to document | Illustrative example |
|---|---|---|
| What data is required? | Business-field name, type and level of detail | Batch number at product-line level |
| When is it required? | Mandatory, optional or conditional | Mandatory only for a batch-controlled item |
| How should it be normalised? | Expected format, unit, time zone or nomenclature | Quantity expressed as a whole number of logistics units |
| Which reference is authoritative? | Approved master data or source used for validation | Item reference known to the WMS |
| What happens when it fails? | Block, request approval or send with an explicit status | Hold the line when two batch numbers remain plausible |
Worked example: from delivery note to business fields
Consider a synthetic delivery note used solely to explain the method. It shows document number “DN-7842”, a printed date of “7/9/26” and a line reading “Item AX-14 — 12 PAL — Batch L240901”. The WMS expects a document reference, an ISO date, an internal item reference, a quantity, a unit and a batch number.
The reading step preserves the raw value and its location on the source. Normalisation then produces a typed value without discarding that evidence. If the source remains ambiguous, the workflow must not invent the most likely value.
| Document area | Captured value | Prepared business field | Transformation or check |
|---|---|---|---|
| Header / Delivery note no. | DN-7842 | Document reference: DN-7842 | Preserve significant characters and check for a potential duplicate |
| Header / Date | 7/9/26 | Delivery date: 2026-09-07 | Interpret the format under an approved rule; hold the case if it remains ambiguous |
| Line / Item | AX-14 | Item reference: AX-14 | Check that the reference exists and is active in the authorised master data |
| Line / Quantity | 12 PAL | Quantity: 12; unit: pallet | Separate number and unit, then apply the target nomenclature |
| Line / Batch | L240901 | Batch number: L240901 | Keep it attached to the AX-14 line and apply the relevant batch rules |
Map fields independently of the printed labels
Mapping connects prepared business fields to the objects and attributes expected by the destination. The names below are teaching aids, not the schema of a particular WMS. In a live project, they are replaced with documented fields from the target system and its authorised integration method.
The same piece of information may have a different destination depending on the document type or process stage. Each mapping rule therefore needs a defined scope, version and set of conditions.
| Business field | Illustrative destination | Mapping rule | When to escalate |
|---|---|---|---|
| Document reference | reception.document_reference | Write one unique value for the relevant receipt | Reference missing, already used or no matching record |
| Delivery date | reception.delivery_date | Send an ISO date after qualifying the source format | Date ambiguous or inconsistent with the record |
| Item reference | reception_line.item_reference | Attach the value to the correct line and active master-data record | Unknown or inactive reference, or more than one match |
| Quantity and unit | reception_line.quantity / unit | Convert only when an approved unit rule exists | Unknown unit, illegible quantity or undefined conversion |
| Batch number | reception_line.batch_number | Write it to the relevant item line when batch control applies | Batch missing, multiple or attributable to more than one line |
Validate before the write, then validate the write
Validation is more than an OCR confidence score. It combines presence, format, master-data, matching and consistency rules. Thresholds and outcomes are defined for the workflow: accept, request approval, hold or reject.
- 01Preserve the source evidence
Keep the document, captured area and raw value so that every prepared field can be explained.
- 02Validate each field
Check its type, format, length, allowed values and whether it is mandatory or conditional.
- 03Validate relationships
Confirm that the batch belongs to the correct line, the unit is valid for the item and the totals remain consistent.
- 04Qualify the destination
Confirm the record, target object and mapping version before transmission.
- 05Write through the authorised channel
Use the API, file exchange or authorised interface interaction selected for this scope.
- 06Read the result back
Check the acknowledgement, status or state shown in the WMS; an attempt without a verifiable outcome is not treated as successful.
- 07Open an actionable exception
When a case fails or remains ambiguous, give the team the source, affected fields, applied rule and action already attempted.
Vidoc and Vigilo: two products with different scopes
Vidoc and Vigilo may operate in the same logistics environment, but they are not the same product. Keeping them distinct clarifies the source, the object being processed and the responsibility expected from each workflow.
| Product | Primary purpose | Example outcome | Boundary for this guide |
|---|---|---|---|
| Vidoc | Ingest documents and prepare validated fields for a WMS | A receipt line that is mapped, validated and traceable to its source delivery note | The exact scope depends on validated documents, fields, access methods and controls |
| Vigilo | Maintain continuity across transport events, documents, rules, decisions, actions and evidence | A request or discrepancy placed in its transport record with its status and next action | This guide does not present Vigilo as the WMS document-ingestion engine |
Checklist for scoping a first Vidoc workflow
- collect representative documents, including incomplete, annotated and hard-to-read versions;
- inventory the WMS fields actually used and identify which are mandatory or conditional;
- document master data, formats, units, nomenclatures and matching rules;
- define the authorised write channel and the evidence expected after transmission;
- specify thresholds, responsibilities and the context required to handle an exception;
- build a validation set that is separate from the examples used to configure the workflow;
- plan how the mapping will be versioned and tested when a document or the WMS changes.
Frequently asked questions
Direct answers
Is Vidoc an OCR solution?
Vidoc can use document-reading capabilities, but its purpose is to prepare validated data for the expected WMS fields.
Which WMS platforms are supported?
Compatibility must be assessed against the workflow, fields, access methods, and intended target system. No universal compatibility list is claimed.
What happens when a document is unreadable?
The case is flagged according to the workflow controls so that a person can correct, complete, or reject the document.
Is an OCR confidence score enough to write to the WMS?
No. It reflects the reading step, but it does not prove that the value is attached to the right record, valid for the business process or consistent with other fields. The decision combines the controls defined for the workflow.
How can the workflow avoid creating the same receipt twice?
It should define a matching key or combination of criteria, check the state already held in the WMS and escalate whenever more than one record remains plausible.
What happens when the delivery-note layout changes?
The change is assessed against representative examples, the mapping or rules are versioned where needed, and a validation set checks that known formats and edge cases still behave as intended.
Does Vidoc replace the WMS?
No. Vidoc prepares, validates and sends document data to the target system under the approved workflow; the WMS continues to own its objects and management rules.
Does using Vidoc guarantee compatibility with any WMS?
No. Feasibility is assessed from the required fields, authorised access methods, available controls and the ability to verify the outcome in the specific WMS.
Sources and methodology
This resource describes Axonovia's product approach based on transport workflows. The examples are illustrative and do not constitute a performance commitment or a universally applicable contractual rule.
Product review: Axonovia team · next review recommended before 31 August 2027 or following a material change in scope.