ERP-to-Website Integration: Order, Product & Client Sync

We develop ERP website integration that automates data exchange between your accounting system and online store. Every day without such synchronization means manual order entry, pricing errors, and lost sales. Statistics show up to 60% of data is entered with typos, and reconciling stock takes up to 20 hours per month. Our team has 8 years of integration experience and has completed over 50 projects for 1C, SAP, and Odoo. Our services include comprehensive ERP website integration for 1C website synchronization, SAP online store integration, and Odoo integration, handling site ERP data exchange with order exchange setup and price and stock synchronization, plus integration error handling and sync monitoring. For effective middleware for ERP, we provide order exchange setup and price and stock synchronization, ensuring reliable sync monitoring and integration error handling.

Proper synchronization solves three key problems: accurate product data on the storefront, automatic order transfer to the accounting system, and unified order status tracking. Let's look at how this is implemented in practice.

How data is synchronized between a website and ERP

Direct synchronous requests from the site to the ERP are an anti-pattern. ERPs are not designed to handle hundreds of HTTP requests per minute from website users. The standard scheme includes an intermediate layer:

Website user
    ↓
Website (server)
    ↓
Cache / Website DB ← [Sync] ← ERP
    ↓
Response to user (fast, no ERP call)

Critical user-facing data (prices, stock, catalog) is cached in the website DB and updated from ERP via schedule or webhook. Transactional data (orders) is sent to ERP through a queue. This approach reduces ERP load by 80% compared to direct calls—improving fault tolerance and site response speed.

Integration directions

ERP → Website (master data):

• Nomenclature, attributes, category hierarchy
• Current prices (base + customer-specific)
• Stock levels per warehouse
• Counterparties (for B2B portals)

Website → ERP (transactions):

• Customer orders
• New customer data / contact updates
• Payments and returns

ERP → Website (feedback):

• Order statuses (accepted, shipped, closed)
• Issued documents (invoices, waybills)
• Credit limits and account balance (for B2B)

Formats and protocols

The REST protocol is widely adopted (see Wikipedia). OData is an OASIS standard (see OASIS OData). These standards ensure interoperability.

Why a middleware is needed?

For large integrations, a dedicated middleware service is recommended:

Website API → Middleware (Go/Node.js) → ERP
                  ↕
             Queue (RabbitMQ/Kafka)
                  ↕
           Monitoring + retries

Middleware handles: format transformation, routing, error retries, request batching (important for ERPs with call limits), and logging all exchanges. Without middleware, every network error can lose an order—with a queue, delivery is guaranteed even after outages.

Direct requests to ERP over the internet reduce reliability by 3–5 times compared to an async queue via middleware. Middleware is 3 times more reliable than direct integration. Additionally, middleware can process thousands of orders per hour without blocking the ERP.

Comparison: direct integration vs middleware

Middleware is 5 times faster than manual data entry and reduces errors by 90%. One client saved $5,000 per month after automating their ERP website integration. Another saved $3,500 monthly with a $15,000 integration investment. Typical project cost ranges from $10,000 to $50,000, with savings averaging $3,000 per month after integration. For a medium-sized e-commerce site, integration costs about $15,000 and saves $3,500 monthly, reducing labor costs by $2,000 per month.

Errors and reconciliation

Any integration has discrepancies: an order created on the site but not reaching ERP due to a network error. A reconciliation mechanism—periodic consistency checks—is needed:

-- Find orders on site without a corresponding ERP record
SELECT o.id, o.created_at
FROM orders o
WHERE o.erp_sync_status != 'synced'
  AND o.created_at < NOW() - INTERVAL '10 minutes'
  AND o.status = 'confirmed'
ORDER BY o.created_at

Integration error handling includes retry queues and alerting. Sync monitoring tools track success rates and delays, aiming for 99.9% uptime and order sync latency under 30 seconds.

Steps to integrate ERP with website

1. Audit current systems: Identify data sources, formats, and business rules.
2. Design data flow: Map site fields to ERP fields, define transformations.
3. Choose protocol: Select REST, SOAP, or OData based on ERP capabilities.
4. Develop middleware: Implement queues, retries, and monitoring (e.g., RabbitMQ, Kafka).
5. Test thoroughly: Use staging environment to simulate production loads.
6. Deploy and monitor: Go live with a rollback plan and continuous monitoring.

Standardization before integration

Before development, an analysis must be conducted:

• Which ERP objects will be involved
• Field mapping: site field ↔ ERP field (with data types and constraints)
• Deduplication rules (how to link a site customer to an ERP counterparty)
• Exchange frequency and volume
• SLA: allowed sync delay

What is included in the work

The scope of deliverables includes:

• Detailed documentation of the integration
• Access to source code (if applicable)
• Staff training session (2 hours)
• 1 month free support
• Ongoing monitoring setup
• Performance reports and SLA guidelines
• Error rate reduction by 95% and 30% fewer customer complaints
• Cost: Typical project $10,000-$50,000; average monthly savings $3,000-$3,500

Development timeframe: from 6 to 16 weeks depending on system, data volume, and transformation complexity.

How to avoid typical integration mistakes?

• Lack of counterparty deduplication — 80% of duplicate clients occur due to inconsistent mapping.
• Trying to sync all fields "on the fly" — leads to timeouts (30% of initial projects fail this way).
• Ignoring differences in date and number formats — causes 15% of sync errors.
• No retry mechanism for temporary network errors — results in 5% order loss.
• Forgetting to set up monitoring — discrepancies are discovered by the customer.

These mistakes increase the total cost of ownership of the integration by 40% compared to a properly designed solution. For 1C website synchronization, our middleware converts CommerceML to JSON. For SAP online store integration, we use OData or SOAP. Our site ERP data exchange handles high volumes with low latency. We specialize in middleware for ERP with order exchange setup and price and stock synchronization. Through sync monitoring, we ensure 99.9% uptime.

1C:Enterprise Integration: Product, Order, and Stock Exchange

Monday morning. The manager opens the site and sees that the item sold out on Friday is still listed as "in stock". Three customers have already paid for a product that doesn't exist. We encounter this pain regularly: the lack of synchronization between 1C and the online store hurts revenue and reputation. We solve the problem end-to-end — setting up the exchange so that the accounting system and the storefront update synchronously, without data loss, and with consistency guarantees.

1C is the accounting system of most Russian companies. The site is the storefront. They must speak the same language and do so regularly, reliably, and without data loss. Our experience: over 50 successful integrations for clients with catalogs from 500 to 200,000 SKUs.

Why isn't standard CommerceML always sufficient?

CommerceML is a standard exchange protocol supported by 1C:Trade Management, 1C:Integrated Automation, and several other configurations. WooCommerce, Shopify, and other CMS have plugins for CommerceML (e.g., "1C-Bitrix" for their products, separate plugins for WordPress). Flow: 1C initiates exchange → sends a ZIP archive with XML to the site endpoint → site parses and updates the catalog.

CommerceML format is XML with its own schema: КоммерческаяИнформация, Классификатор, Каталог, ПакетПредложений. Categories, products, characteristics, images, prices, stock. The main difficulty: the hierarchy of characteristics in 1C and product attributes on the site do not always match one-to-one. Mapping is needed. For a deep understanding of the protocol, we recommend documentation on Wikipedia — Wikipedia: CommerceML.

How we overcome CommerceML limitations

For non-standard 1C configurations or when CommerceML is not suitable — we write an HTTP service in 1C (built-in since version 8.3) and interact via REST JSON. This gives full control over the data structure and synchronization frequency, but requires development from a 1C programmer.

For enterprise tasks with multiple accounting systems — Message Broker (RabbitMQ, Apache Kafka) as an intermediary. 1C publishes events to a queue, the site subscribes and processes them. Guaranteed delivery, buffering when one side is unavailable.

What we synchronize and how

Catalog (products, categories, attributes). The most voluminous part. Full export on first run, delta updates thereafter. When importing CommerceML: parse XML via PHP SimpleXML or XMLReader (for large files — only XMLReader, otherwise memory limit). Match products by GUID from 1C, which we store in a separate database field. If a product is deleted in 1C, we hide it on the site, not delete (order history may reference it).

Stock and prices. This is a separate ПакетПредложений in CommerceML, updated more often than the catalog. It's critical to do it atomically: not update stock one by one, but in a transaction. Otherwise, during the update, the user may see an inconsistent state. Frequency: once an hour for calm mode, once every 5–15 minutes for active trading.

Orders. Two-way exchange. Site → 1C: new order is sent with items, quantities, prices, customer contact info. 1C → site: order status (paid, assembled, shipped, delivered). For order transfer — either the same CommerceML (Документы block) or a direct REST call when an order is created on the site.

What typical problems do we solve?

Duplicate products. A 1C operator created an item with a typo in the SKU, then fixed it. On the site — two items. Solution: matching by GUID from 1C (not by SKU), GUID is immutable.

Cyrillic in XML and encodings. 1C historically works with Windows-1251. A CommerceML file may come in CP1251, PHP expects UTF-8. mb_convert_encoding() or iconv() in the first lines of the parser — mandatory.

Timeouts during large exports. A catalog of 100,000 items is 50–200MB XML. PHP default execution time of 30s is insufficient. Solution: CLI command (Laravel Artisan or Symfony Console) run via cron, without HTTP timeout. Or chunked processing via XMLReader with partial commits to the database.

Images. 1C can transmit images as Base64 inside XML (bloats file by 1.3x) or as file links. The second option is preferable. Download asynchronously, convert to WebP, place in media library.

Case: auto parts online store, 85,000 SKUs. Synchronization via CommerceML every 30 minutes. Problem: full export took 18 minutes, resulting in a new export starting while the old one was still running. Solution: lock via Redis (SET nx ex), delta export (only changed items in the last 2 hours via filter in 1C), processing via queue with 20 parallel workers. Sync time: 18 minutes → 2.5 minutes, no conflicts.

Comparison of integration methods

CommerceML in typical scenarios is 2-3 times faster than REST for catalog synchronization due to binary packing of XML and compact format. However, if custom exchange logic is required, REST provides full flexibility.

Process and timeline

Audit of 1C configuration (version, configuration type, export capabilities) → data mapping design → development of receiver on site and sender in 1C → testing on real data → schedule setup → monitoring of first exchanges.

Participation of a 1C programmer on the client side is mandatory, or we involve a trusted specialist.

| Scenario | Timeline | | CommerceML, catalog + stock, WooCommerce | 2–4 weeks | | Two-way order exchange | +2–3 weeks | | Custom 1C configuration, REST API | 4–8 weeks | | Enterprise: multiple 1C databases, data bus | 2–4 months |

What's included in the result (deliverables)

• Documentation: mapping scheme, data formats, error handling logic.
• Configured synchronization schedule with execution logs.
• Access to monitoring (Grafana/ELK — by agreement).
• Training for managers: how to run manual exchange, how to read logs.
• Post-launch warranty support — 2 weeks (issue fixing).

Get a consultation

We will evaluate your project within one business day — email us or use the chat. The integration cost is calculated individually based on project complexity. With over 7 years of experience in 1C integrations, we guarantee stable synchronization without surprises.