Importing data from Ordizi into the ERP system

XML format technical specification
For specialists integrating an ERP system with Ordizi
Version 1.0

Document scope: This document describes importing visits, payments, orders, and returns created in Ordizi into the ERP system. Exporting reference and operational data from the ERP system to Ordizi is described in a separate document.

Document purpose
General data transfer workflow
Generating export files
General XML requirements
File structure
Detailed field descriptions
XML file example

1. Document purpose

This document is intended for specialists importing data from Ordizi into 1C or another ERP system.

The Ordizi exchange service generates XML files containing documents created by sales representatives in the mobile application. The file includes visits, recorded shelf stock levels, received payments, orders, products for shipment, and products for return.

Customer, sales representative, product, unit of measure, price type, and payment type identifiers are transferred in the same form in which they were previously received by Ordizi from the ERP system. This allows the ERP system to uniquely match the received documents with its reference data.

2. General data transfer workflow

The sales representative creates a visit and related documents in the Ordizi mobile application.
The data is transferred to the Ordizi exchange service.
The service generates an XML file in the ERP system exchange directory.
The ERP system imports visits, payments, orders, and returns from the generated file.

3. Generating export files

3.1. File name

Each new export file is assigned a unique name in the form exportN.xml, where N is a sequential number. After the data has been successfully imported into the ERP system, it is recommended to delete the file from the exchange directory or move it to an archive.

export1.xml
export2.xml
export3.xml

The number in the file name is the exchange package number and is not the visit or order number.

3.2. Repeated document transfer

A visit may be transferred more than once. For example, this can happen if a new order is added to the visit after the previous transfer or if data associated with the visit has changed.

When a visit is transferred again, it is exported in full: the visit header, stock records, payments, and all associated orders. Orders may also appear again in a new file.

The doc_number field is the document number in Ordizi. The ERP system must store this number and use it to identify a previously imported visit or order so that repeated transfers do not create duplicates.

An order is always transferred within its corresponding visit. No separate field is used to link an order to a visit; the relationship is determined by the nesting of the order element inside the visit element.

4. General XML requirements

File encoding — UTF-8.
Root element — <extdata name="ordizi">.
A single file may contain one or more <visit> elements.
An empty list is represented by an empty element, for example <returns/> or <payments/>.
String and date fields without a value are represented by an empty element.
The order of fields within each element is fixed and must match the examples in this document.

4.1. Data types

Type	Description
`string`	String value. Identifiers are processed as strings and may contain leading zeros.
`integer`	Integer value.
`decimal`	Numeric value. A period is used as the decimal separator.
`datetime`	Date and time in YYYY-MM-DDTHH:MM:SS format, for example 2026-07-14T09:31:02.
`integer (0/1)`	Boolean value: 0 — flag is not set, 1 — flag is set.

All reference identifiers are transferred as strings. They must not be converted to numbers before matching them with reference data, because the values may contain leading zeros.

5. File structure

Element	Purpose
`extdata`	Root element of the file. The `name` attribute has the value `ordizi`.
`visit`	“Visit” document. A single file may contain multiple `visit` elements.
`visit/header`	Visit header.
`visit/inventory`	Product shelf stock levels recorded during the visit.
`visit/payments`	Payments received during the visit.
`visit/orders`	Orders associated with the visit.
`order/header`	Order header.
`order/items`	Products for shipment.
`order/returns`	Products for return.

<extdata name="ordizi">
  <visit>
    <header>...</header>
    <inventory>...</inventory>
    <payments>...</payments>
    <orders>
      <order>
        <header>...</header>
        <items>...</items>
        <returns>...</returns>
      </order>
    </orders>
  </visit>
</extdata>

6. Detailed field descriptions

6.1. “Visit” document

The <visit> element contains the visit header and nested lists of stock records, payments, and orders. The relationship between the nested data and the visit is determined by its location within the corresponding <visit> element.

6.1.1. Visit header — visit/header

Field	Type	Description
`doc_number`	`string`	“Visit” document number generated in Ordizi. The ERP system must store this number to identify the visit if it is transferred again.
`doc_date`	`datetime`	Date and time when the visit was created.
`client_id`	`string`	Unique customer identifier from the `client.xml` file.
`comment`	`string`	Visit comment.
`agent_id`	`string`	Unique sales representative identifier from the `agent.xml` file.
`gps_lat`	`string`	Geographic latitude recorded during the visit.
`gps_lon`	`string`	Geographic longitude recorded during the visit.
`gps_sat`	`integer`	Number of satellites used when determining the coordinates.
`gps_time`	`datetime`	Date and time when the coordinates were determined. If coordinates were not obtained, the field may be empty.

6.1.2. Shelf stock levels — visit/inventory

This section contains products and their actual quantities recorded by the sales representative during the visit. Each record is transferred in a separate <row> element.

Field	Type	Description
`product_id`	`string`	Unique product identifier from the `product.xml` file.
`qty`	`decimal`	Product quantity in the base unit of measure.
`qty_display`	`decimal`	Quantity entered by the sales representative in the selected unit of measure.
`unit_id`	`string`	Unique identifier of the selected unit of measure from the `product_unit.xml` file.
`unit_name`	`string`	Name of the selected unit of measure.
`coefficient`	`decimal`	Conversion factor of the selected unit of measure relative to the product’s base unit.
`base_unit_name`	`string`	Name of the product’s base unit of measure.

Quantity: qty_display contains the quantity in the selected unit of measure, coefficient is the conversion factor for that unit, and qty is the quantity in the base unit. Calculation: qty = qty_display × coefficient.

6.1.3. Received payments — visit/payments

This section contains payments received by the sales representative during the visit against outstanding documents.

Field	Type	Description
`doc_number`	`string`	Number of the outstanding document from the `debt.xml` file against which the payment was received.
`doc_date`	`datetime`	Date of the outstanding document. The field may be empty if the date is unavailable.
`doc_sum`	`decimal`	Payment amount received during the visit against the specified document.

6.2. Orders — visit/orders/order

All orders are transferred within the corresponding visit. A single visit may contain multiple <order> elements. Each order includes a header, products for shipment, and products for return.

6.2.1. Order header — order/header

Field	Type	Description
`doc_number`	`string`	Order number generated in Ordizi. The ERP system must store this number and use it to identify the order if it is transferred again.
`doc_date`	`datetime`	Date and time when the order was created.
`doc_delivery`	`datetime`	Planned delivery date and time. The field may be empty if no delivery date is specified.
`client_id`	`string`	Unique customer identifier from the `client.xml` file.
`price_id`	`string`	Unique price type identifier from the `price_type.xml` file.
`payment_id`	`string`	Unique payment type identifier from the `payment_type.xml` file.
`comment`	`string`	Order comment.
`agent_id`	`string`	Unique sales representative identifier from the `agent.xml` file.
`doc_sum`	`decimal`	Total order amount.
`main_warehouse`	`integer (0/1)`	Indicates whether the order is to be shipped from the main warehouse. This optional field can be used by the ERP system for its own order processing logic.
`call_phone`	`integer (0/1)`	Indicates whether the order was created by phone without visiting the sales outlet: 1 — order created by phone, 0 — regular order.
`return_status`	`integer (0/1)`	Indicates a compensatory return or exchange. This optional field can be used by the ERP system for its own return processing logic.

6.2.2. Products for shipment — order/items

Each product line is transferred in a separate <row> element.

Field	Type	Description
`product_id`	`string`	Unique product identifier from the `product.xml` file.
`qty`	`decimal`	Product quantity in the base unit of measure.
`qty_display`	`decimal`	Quantity entered by the sales representative in the selected unit of measure.
`price`	`decimal`	Price per base unit of the product before applying a discount or markup.
`discount`	`integer`	Discount or markup percentage.
`is_markup`	`integer (0/1)`	Defines how the `discount` field is applied: 0 — discount, 1 — markup.
`row_sum`	`decimal`	Final line amount after applying the discount or markup and rounding. The value may differ from the result of simply multiplying `price` by `qty`.
`unit_id`	`string`	Unique identifier of the selected unit of measure from the `product_unit.xml` file.
`unit_name`	`string`	Name of the selected unit of measure.
`coefficient`	`decimal`	Conversion factor of the selected unit of measure relative to the product’s base unit.
`base_unit_name`	`string`	Name of the product’s base unit of measure.

Price and line amount: price contains the price per base unit before any price adjustment. discount contains the discount or markup percentage, while is_markup defines the type of adjustment. row_sum is the final line amount after applying the price adjustment and rounding; the ERP system should not recalculate row_sum by simply multiplying price by qty.

6.2.3. Products for return — order/returns

This section contains products entered for return as part of the order. Each line is transferred in a separate <row> element.

Field	Type	Description
`product_id`	`string`	Unique identifier of the returned product from the `product.xml` file.
`qty`	`decimal`	Quantity of the returned product in the base unit of measure.
`qty_display`	`decimal`	Return quantity entered by the sales representative in the selected unit of measure.
`price`	`decimal`	Price per base unit of the returned product.
`row_sum`	`decimal`	Final amount of the return line.
`unit_id`	`string`	Unique identifier of the selected unit of measure from the `product_unit.xml` file.
`unit_name`	`string`	Name of the selected unit of measure.
`coefficient`	`decimal`	Conversion factor of the selected unit of measure relative to the product’s base unit.
`base_unit_name`	`string`	Name of the product’s base unit of measure.

7. XML file example

The example shows one visit, one inventory line, one payment, and one order. In an actual file, the number of visits, orders, and lines can be arbitrary.

<?xml version="1.0" encoding="utf-8"?>
<extdata name="ordizi">
  <visit>
    <header>
      <doc_number>260714093102967</doc_number>
      <doc_date>2026-07-14T09:31:02</doc_date>
      <client_id>00050003</client_id>
      <comment>Visit comment</comment>
      <agent_id>00000255</agent_id>
      <gps_lat>55.6948</gps_lat>
      <gps_lon>37.3532</gps_lon>
      <gps_sat>8</gps_sat>
      <gps_time>2026-07-14T09:30:58</gps_time>
    </header>
    <inventory>
      <row>
        <product_id>00003005</product_id>
        <qty>40.0000</qty>
        <qty_display>2.0000</qty_display>
        <unit_id>00000002</unit_id>
        <unit_name>pkg (20)</unit_name>
        <coefficient>20.0000</coefficient>
        <base_unit_name>pcs.</base_unit_name>
      </row>
    </inventory>
    <payments>
      <row>
        <doc_number>INV-25-0104</doc_number>
        <doc_date>2025-06-19T00:00:00</doc_date>
        <doc_sum>1500.0000</doc_sum>
      </row>
    </payments>
    <orders>
      <order>
        <header>
          <doc_number>260714093300563</doc_number>
          <doc_date>2026-07-14T09:33:00</doc_date>
          <doc_delivery>2026-07-15T08:00:00</doc_delivery>
          <client_id>00050003</client_id>
          <price_id>00000001</price_id>
          <payment_id>00000001</payment_id>
          <comment />
          <agent_id>00000255</agent_id>
          <doc_sum>990.0000</doc_sum>
          <main_warehouse>0</main_warehouse>
          <call_phone>1</call_phone>
          <return_status>0</return_status>
        </header>
        <items>
          <row>
            <product_id>00001008</product_id>
            <qty>10.0000</qty>
            <qty_display>1.0000</qty_display>
            <price>110.0000</price>
            <discount>10</discount>
            <is_markup>0</is_markup>
            <row_sum>990.0000</row_sum>
            <unit_id>00000002</unit_id>
            <unit_name>pkg (10)</unit_name>
            <coefficient>10.0000</coefficient>
            <base_unit_name>pcs.</base_unit_name>
          </row>
        </items>
        <returns />
      </order>
    </orders>
  </visit>
</extdata>

Contents