{"id":11303,"date":"2026-08-31T19:22:49","date_gmt":"2026-08-31T16:22:49","guid":{"rendered":"https:\/\/www.firstidea.gr\/?p=11303"},"modified":"2026-08-31T19:24:50","modified_gmt":"2026-08-31T16:24:50","slug":"how-to-connect-eshop-erp-xml","status":"publish","type":"post","link":"https:\/\/www.firstidea.gr\/en\/blog\/e-commerce\/how-to-connect-eshop-erp-xml\/","title":{"rendered":"How do you connect an eShop to ERP or XML? A practical guide to products, stock and orders"},"content":{"rendered":"\n
\n\n
\n

<\/span> The short answer<\/p>\n

A reliable integration does not start with a connector. It starts by deciding which system manages each datum.<\/h2>\n

Before code is written, the team must define product identifiers, the primary source for pricing and stock, the direction of orders, operational exceptions and how failures become visible. ERP, eShop and supplier feeds do not need to exchange everything, and every update does not need to be real time. They need explicit rules, validation and safe retries.<\/p>\n

DATA FLOW \/ CONTROLLED<\/span>
ERP \/ FEED<\/b><\/i>MAP<\/strong><\/i>ESHOP<\/b><\/div>
  1. PRODUCT<\/li>
  2. PRICE<\/li>
  3. STOCK<\/li>
  4. ORDER<\/li><\/ol><\/div>\n<\/div>\n\n

    Updated: August 2026.<\/strong> This guide distinguishes XML as a data format, an API as an interface and ERP as an operational system. It is grounded in the W3C XML specification<\/a>, the current WooCommerce REST API v3 documentation<\/a>, the GS1 GTIN Management Standard<\/a> and the official OpenCart documentation<\/a>. Actual capabilities always depend on system versions, licences and available interfaces.<\/p>\n<\/div>\n

    01<\/span>Which data moves?<\/strong>Products, variations, pricing, stock, customers, orders, documents and shipment updates.<\/small><\/p>\n

    02<\/span>Which system manages it?<\/strong>Each field receives one primary source and an explicit change rule.<\/small><\/p>\n

    03<\/span>What happens on failure?<\/strong>Validation, logs, alerts, retries and human decisions for genuine exceptions.<\/small><\/p>\n<\/div>\n

    What does \u201cconnecting an eShop to ERP\u201d actually mean?<\/h2>\n

    It is a controlled data flow between the online store and a commercial or accounting system. One flow may publish products, prices and availability to the store; another may send new orders to ERP; a third may return a document number or shipment status. It is not necessarily one bridge that does everything.<\/p>\n

    A dependable solution is divided into smaller flows, each with its own trigger, data, permissions, cadence and failure behavior. A temporary product-feed issue should not have to stop order export, and retrying one failed order should not create a duplicate ERP record.<\/p>\n

    ERP, API and XML are not the same thing.<\/h2>\n

    ERP is the operational system in which a business may manage products, inventory, customers, orders and accounting documents. An API is an agreed interface through which applications request or send data. XML is a data representation format; it can be delivered as a file or feed, but it does not define when imports run, how fields are mapped or how errors are handled.<\/p>\n

    A supplier may offer a product XML feed without an order API. An ERP may expose an API, a scheduled export or a connector limited to a particular version. Technical discovery begins with what is genuinely available rather than assuming every vendor supports the same method.<\/p>\n

    Every field needs one primary data source.<\/h2>\n

    If a price can be changed in ERP and eShop without a priority rule, the next update may undo a correct change. The same applies to stock, titles, descriptions, tax, categories and images. The team decides where each datum is maintained and which system is allowed to update it.<\/p>\n

    A common pattern keeps item code, price and accounting stock in ERP while the eShop owns commercial titles, descriptions, SEO fields, categories and media. That is not a universal rule; it is one possible architecture that must match the business operation.<\/p>\n

    PRIMARY SOURCE \/ WRITE RULE<\/span>
    ERP \/ FEED<\/b><\/i>MAP<\/strong><\/i>ESHOP<\/b><\/div>
    1. ID<\/li>
    2. PRICE<\/li>
    3. STOCK<\/li>
    4. CONTENT<\/li><\/ol><\/div>\n

      SKU, barcode and GTIN provide the matching foundation.<\/h2>\n

      A product name is not a safe identifier. It can change, be translated or be reused across variations. Each trade item needs a stable code and a clear relationship between the internal item code, store SKU, barcode or GTIN and supplier identifier.<\/p>\n

      GS1 notes that unique identification and communication of changes between trading partners are essential to correct product presentation and fulfilment in eCommerce. Before bulk import, the process audits duplicate codes, missing IDs, variations and identifier changes.<\/p>\n

      Product mapping is a business rule, not a field-copying exercise.<\/h2>\n

      A feed may call a category \u201cLiving room\u201d, the store may use \u201cHome furniture\u201d and ERP may represent the same group with a numeric code. Mapping is required for categories, attributes, units, tax, weight, dimensions, brand, images and variations. The process also defines what happens when a required field is absent or invalid.<\/p>\n

      A safe importer does not automatically publish every incomplete record. It may keep new items in draft, reject unsafe rows or route exceptions for review. That protects catalogue quality, SEO and the buying experience.<\/p>\n

      Pricing and stock need an explicit cadence and safety rules.<\/h2>\n

      Real time is not always necessary or available. A fast-moving store with scarce inventory may require more frequent updates than a made-to-order catalogue. Cadence depends on volume, API limits, processing cost and commercial risk.<\/p>\n

      The design may include stock buffers, checks for zero or negative prices, tolerance for temporarily stale data and a defined response when the source is unavailable. A failed feed must not zero an entire catalogue or publish a price that failed validation.<\/p>\n

      Order export needs to be safely repeatable.<\/h2>\n

      An order contains more than line items: customer, addresses, tax, discounts, shipping, payment and status. The business must decide when an order becomes ready for ERP \u2014 at creation, after payment or following human review.<\/p>\n

      Each export uses a stable identifier so a retry cannot create a second order. The result is stored with the ERP number or failure message. Returns, cancellations and partial fulfilment are designed separately because they are not simple reversals of the original flow.<\/p>\n

      INTEGRATION CONTROL<\/span>PRODUCT SOURCE<\/b>\u2192<\/i>STOCK<\/b>\u2192<\/i>ORDER<\/b>\u2192<\/i>ERP<\/b>\u2192<\/i>STATUS<\/b>VALIDATE \/ LOG \/ RETRY \/ ALERT<\/strong><\/p><\/div>\n

      One-way or two-way integration? Only what the operation genuinely needs.<\/h2>\n

      Two-way editing increases the number of possible conflicts. If ERP sends stock and the store sends orders, those are two separate one-way flows \u2014 not necessarily full synchronisation of every field in both directions.<\/p>\n

      Start with the flows that remove the most manual error or resolve the largest operational problem. Additional directions can be enabled after data, logs and real operating experience are strong enough to support them.<\/p>\n

      Validation, logs, alerts and retries make an integration operable.<\/h2>\n

      The useful question is not whether an error will ever occur, but whether it will be found quickly and understood. Logs identify the flow, record, time, result and an actionable message. They should not retain unnecessary personal data or access secrets.<\/p>\n

      Temporary failures can retry at a controlled rate. Permanent failures, such as an unknown tax code or malformed XML, stop the affected record and raise an alert. Endless blind retries load the systems and hide the underlying defect.<\/p>\n

      Security requires least privilege and controlled secrets.<\/h2>\n

      API keys and credentials do not belong in public code or browser-downloadable files. Every account receives only the permissions it needs, connections use encryption where supported, and keys should be replaceable without rebuilding the complete solution.<\/p>\n

      When customer or order data moves, the business must define what is necessary, who can access it, how long logs are retained and how its obligations are handled. Technical delivery does not replace legal or accounting advice.<\/p>\n

      WooCommerce, OpenCart or custom commerce: the principle is shared, implementation differs.<\/h2>\n

      WooCommerce provides a REST API for products, orders and other resources. OpenCart offers an extensible architecture, while the available integration route depends on version, extensions and existing custom code. A custom commerce system requires documentation or a technical audit of its endpoints and data model.<\/p>\n

      Firstidea builds integrations for WooCommerce<\/a>, OpenCart<\/a> and custom systems. Platform choice follows catalogue, operations, team and future change \u2014 not simply whether a connector exists. See also WooCommerce or OpenCart<\/a>.<\/p>\n

      Testing must cover normal flows and intentional failures.<\/h2>\n

      Before production, representative products cover simple items, variations, missing images, special tax, identifier changes and zero stock. Orders cover discounts, shipping, multiple payment methods, cancellation and safe retry.<\/p>\n

      Rollout is staged: a read-only check or limited sample first, then one flow, then the remaining flows. The release has a backup, rollback route, monitoring for the first cycles and a named decision owner for every exception.<\/p>\n

      What determines the time and cost of an integration?<\/h2>\n

      Field count alone is not enough. Important factors include documentation quality, available interfaces, versions, licences, volume, variations, update directions, exceptions, historical data and the required monitoring level.<\/p>\n

      A responsible estimate begins with samples and technical answers from all parties. Firstidea\u2019s ERP and XML integration service<\/a> structures that work from inventory and mapping through testing, controlled rollout and support.<\/p>\n

      INTEGRATION READINESS<\/span>INTERFACES<\/b><\/i>DATA<\/b><\/i>EXCEPTIONS<\/b><\/i>MONITORING<\/b>TEST \/ RELEASE \/ SUPPORT<\/strong><\/p><\/div>\n

      Checklist before requesting an estimate.<\/h2>\n

      You do not need a finished technical specification. You do need the real environment and the main operational priorities.<\/p>\n