CRMconnect Azuvio · Docs

Most Common EDI Mistakes

Top 10 errors encountered during implementation — causes and solutions

This document covers the errors that occur most frequently in the first months of EDI integration with Azuvio / CRMconnect. Each error is documented with the exact symptom, the technical cause, and the resolution steps.


Error 1 — GLN with incorrect number of digits

Symptom: The partner or receiving system returns an Invalid GLN or Party not found error, even though the GLN appears correct.

Cause: The GLN was sent as a numeric type (integer) instead of a string. The source application dropped the leading 0 digit from the number. For example, the GLN 0594123456789 (13 digits) arrived as 594123456789 (12 digits).

Solution: Always store and transmit the GLN as a string of exactly 13 characters. If the database stores the value numerically, convert it with left-padding before writing it into the EDI message.

<!-- Wrong -->
<GLN>594123456789</GLN>

<!-- Correct -->
<GLN>0594123456789</GLN>

Error 2 — Incorrect UNT count

Symptom: The EDIfact message is rejected with a Segment count mismatch or UNT count error.

Cause: The value in the UNT segment (the first element, which declares the number of segments) does not match the actual number of segments in the message. This usually happens when segments are added or removed manually after the counter has been calculated.

Solution: Count ALL segments from UNH through UNT inclusive (both ends are included) and put that value in UNT. The calculation must be performed automatically by the application, not manually.

UNH+1+ORDERS:D:01B:UN:EAN010'   ← segment 1
BGM+220+CMD001+9'                 ← segment 2
DTM+137:20240307:102'             ← segment 3
... (other segments) ...
UNT+[TOTAL]+1'                    ← last segment, TOTAL = actual count

Error 3 — DocumentType=OR instead of O

Symptom: The order arrives at the receiver as a response to an order, not as a new order. The system may ignore it or incorrectly associate it with a previous order.

Cause: When sending a new order, the DocumentType field was set to OR (Order Response) instead of O (Order — new order).

Solution: New orders use DocumentType=O. Check the complete table of accepted values in the DocumentType XML section of the Quick Reference.

<!-- Wrong — this is an order response, not a new order -->
<DocumentType>OR</DocumentType>

<!-- Correct — new order -->
<DocumentType>O</DocumentType>

Error 4 — Wrong EDIfact version (D.96A instead of D.01B)

Symptom: The message is rejected or processed incorrectly. The log error may be Unknown message version or Version not supported.

Cause: The UNH segment contains a reference to version D.96A (an older EDIfact version) instead of D.01B, which is the EANCOM standard used in exchanges with Azuvio / CRMconnect.

Solution: Update the version identifier in the UNH segment for each message type.

<!-- Wrong -->
UNH+1+ORDERS:D:96A:UN'

<!-- Correct -->
UNH+1+ORDERS:D:01B:UN:EAN010'

The same format applies to DESADV, RECADV, and INVOIC.


Error 5 — SSCC with incorrect number of digits

Symptom: The SSCC code on the pallet or parcel cannot be scanned or is rejected by the system with Invalid SSCC length.

Cause: The SSCC was generated with 17 or 19 digits instead of 18. This error usually occurs due to an incorrect company prefix or an incorrectly calculated check digit.

Solution: The SSCC (Serial Shipping Container Code) must be exactly 18 digits according to the GS1 standard. The structure is: [1-digit extension] + [company GS1 prefix] + [serial number] + [check digit]. Verify that the SSCC generation application always produces exactly 18 digits.

<!-- Wrong -->
<SSCC>123456789012345</SSCC>    <!-- 15 digits -->
<SSCC>1234567890123456789</SSCC> <!-- 19 digits -->

<!-- Correct -->
<SSCC>123456789012345678</SSCC>  <!-- exactly 18 digits -->

Error 6 — Invalid EAN/GTIN (12 digits instead of 13)

Symptom: The product is not recognised in the receiving system. The error is of the type Product not found or Invalid GTIN.

Cause: The EAN was sent in UPC format (12 digits, US standard) instead of EAN-13 (13 digits, European standard). Just as with the GLN, the leading 0 digit was lost through numeric conversion.

Solution: Pad the EAN with a leading zero 0 to obtain 13 digits. Store and transmit the EAN as a string.

<!-- Wrong — US UPC format, 12 digits -->
<EAN>594123456789</EAN>

<!-- Correct — European EAN-13 format, 13 digits -->
<EAN>0594123456789</EAN>

Error 7 — Incorrect date format

Symptom: The date in the message is interpreted incorrectly (day and month swapped) or the message is rejected with Invalid date format.

Cause: The date was sent in a local format (07/03/2024) or in compact format without a separator (20240703) in the XML field, which only accepts ISO 8601 format.

Solution:

  • In XML messages: the mandatory format is YYYY-MM-DD (with a hyphen as separator).
  • In EDIfact messages: the format is YYYYMMDD (without separator), specified together with format code 102.
<!-- Wrong in XML -->
<Date>07/03/2024</Date>
<Date>20240307</Date>

<!-- Correct in XML -->
<Date>2024-03-07</Date>
<!-- Correct in EDIfact -->
DTM+137:20240307:102'

Error 8 — Missing or incomplete VAT table in INVOIC

Symptom: The invoice is rejected with Tax summary missing or Tax lines incomplete. Alternatively, the VAT total in the grand totals does not match the sum of the VAT detailed on individual lines.

Cause: The TaxSummary section is missing entirely from the invoice, or it contains a single TaxLine for all VAT rates even though the invoice includes products with different rates (e.g. 9% for food and 19% for other products).

Solution: Add a separate TaxLine for each distinct VAT rate on the invoice. Each TaxLine must contain the taxable base and the VAT amount for that rate.

<TaxSummary>
  <!-- One TaxLine for the 9% rate -->
  <TaxLine>
    <TaxRate>9</TaxRate>
    <TaxableAmount>1000.00</TaxableAmount>
    <TaxAmount>90.00</TaxAmount>
  </TaxLine>
  <!-- A separate TaxLine for the 19% rate -->
  <TaxLine>
    <TaxRate>19</TaxRate>
    <TaxableAmount>500.00</TaxableAmount>
    <TaxAmount>95.00</TaxAmount>
  </TaxLine>
</TaxSummary>

Error 9 — Missing registered capital in INVOIC

Symptom: The invoice is rejected by the receiving system or generates a RegisteredCapital missing or empty warning.

Cause: The Seller/RegisteredCapital field was left blank or omitted from the INVOIC message. According to Romanian legislation, registered capital must be stated on fiscal documents issued by commercial companies.

Solution: Fill in the field with the registered capital value in RON, as a whole number without a thousands separator (no period or comma).

<!-- Wrong -->
<RegisteredCapital></RegisteredCapital>
<RegisteredCapital>200.000</RegisteredCapital>

<!-- Correct -->
<RegisteredCapital>200000</RegisteredCapital>

Error 10 — InvoiceSeries + InvoiceNumber exceed 16 characters

Symptom: The invoice is rejected or truncated in older partner systems. The error may be Invoice reference too long or Field length exceeded.

Cause: The combined length of the InvoiceSeries and InvoiceNumber fields exceeds 16 characters, the limit accepted by older EDI systems.

Solution: The total length of InvoiceSeries + InvoiceNumber must not exceed 16 characters. If the series or number are alphanumeric and together exceed the limit, place the entire invoice identifier in the InvoiceSeries field and leave InvoiceNumber empty or set it to 0.

<!-- Wrong — 18 characters total -->
<InvoiceSeries>AZUVIO</InvoiceSeries>
<InvoiceNumber>2024031200001</InvoiceNumber>

<!-- Correct — 16 characters or fewer total -->
<InvoiceSeries>AZ</InvoiceSeries>
<InvoiceNumber>2024031200001</InvoiceNumber>

<!-- Alternative if the reference is alphanumeric -->
<InvoiceSeries>AZ-2024031200001</InvoiceSeries>
<InvoiceNumber>0</InvoiceNumber>

Where to report an error

If you have encountered an error not covered in this document, or if the solutions above did not work, contact the Azuvio / CRMconnect EDI support team:

EDI technical support email: edi-support@azuvio.io

What to include in your message:

  1. The type of EDI message affected (ORDERS, DESADV, RECADV or INVOIC)
  2. The DocumentType and document number
  3. The sender's and recipient's GLN
  4. The exact error message (copy the full text, not a screenshot)
  5. The original EDI or XML file that generated the error (attached to the email)
  6. The approximate date and time the error occurred

Response time: 1 business day for production errors, 3 business days for general technical questions.

Support portal: support.azuvio.io — you can open a ticket and track the resolution status.