Imagine your enterprise producing custom products. Customers place orders on the website, but the production department only receives them after manual entry into 1C:ERP. Errors, delays, lost orders — a typical picture without integration. We solve this by setting up direct synchronization between the site and 1C:ERP at the level of orders, stock, prices, and production tasks.
1C:ERP Enterprise Management is the most comprehensive 1C configuration, covering production, supply chain, financial accounting, asset and personnel management. Integration with the site is part of a broader corporate information system architecture. Without it, order processing time grows, stock discrepancies appear, and prices for different customers must be updated manually.
Over 10 years, we have completed 30+ projects integrating 1C:ERP with websites. Our experience includes enterprises with dozens of legal entities, complex pricing conditions, and multi-level production. Each integration is unique, but architectural solutions remain similar. In this article, we will explain how to build a reliable integration using OData and an ESB data bus.
How Integration Works: From 2 Days to 30 Minutes
For a machine-building enterprise, we implemented an integration where an order from the site triggers a chain of documents in 1C:ERP:
- Customer order → material requirements calculation
- Requirements → purchase orders or production tasks
- Finished goods → reservation for customer order
Previously, order processing took 2 days: the manager manually transferred data from the site to 1C. After integration, time dropped to 30 minutes. Key decisions: using OData for item and stock export (every 5 minutes), RabbitMQ for asynchronous order transfer (real time), and modifying the 1C module to automatically create documents from the bus data.
Why OData Is the Best Choice for 1C:ERP Integration
1C:ERP supports publishing via OData — a REST-based protocol. This is the most modern integration method. OData integration is 3 times faster and more reliable than FTP/XML exchange. Example request:
GET https://1c-server/odata/standard.odata/Catalog_Номенклатура
?$filter=DeletionMark eq false
&$select=Code,Description,Weight,НоменклатурнаяГруппа_Key
&$expand=НоменклатурнаяГруппа
OData supports filtering, sorting, pagination, and expanding related objects — convenient for incremental synchronization. Unlike legacy XML/FTP exchanges, OData provides data typing and transparent error handling. Learn more about OData in the official Microsoft documentation.
How Often to Synchronize Data?
| Data Type |
Periodicity |
Real-Time Requirements |
| Stock and prices |
5-15 minutes |
No |
| Orders |
Real time via queues |
Yes |
| Items |
Incrementally once per day |
No |
| Counterparties |
Incrementally once per day |
No |
Comparison: Direct Integration vs ESB
| Criterion |
Direct Integration |
Integration via ESB |
| Adding new systems |
High (new connections each time) |
Low (connect to the bus) |
| Reliability during failures |
No retry |
Retry logic and message queue |
| Data flow monitoring |
Only 1C logs |
Centralized via RabbitMQ/Kafka |
| Scalability |
Limited |
Easily scalable |
How the Integration Bus (ESB) Works
ESB (Enterprise Service Bus) is an intermediate layer between the site and 1C:ERP. It receives messages from the site, transforms them into 1C format, and delivers them with guaranteed delivery. On failure, the bus automatically retries. ESB also allows connecting other systems (WMS, CRM, BI) without modifying existing integrations.
Typical stack: RabbitMQ for message queues, WSO2 for data transformation, PostgreSQL for logging. The bus is deployed on a separate server or Docker container.
What If 1C:ERP Is Heavily Modified?
At many enterprises, 1C:ERP is customized for specific business processes. In such cases, integration requires additional analysis: we check which objects were changed and adapt OData queries or add custom handlers. Even with deep customizations, we aim to keep the standard OData interface, adding only necessary extensions.
Process of Work
-
Analysis — We study current business processes, 1C:ERP configuration, and site architecture. Prepare a requirements document.
-
Design — Determine the integration scheme (ESB or direct), data format, and protocols. Align with your 1C team.
-
Implementation — Configure OData on the 1C side, develop connector to ESB or integration scripts on the site. Perform unit testing.
-
Testing — Conduct load and acceptance testing on a test database. Fix bugs.
-
Deployment — Deploy the solution on production servers, set up monitoring and logging.
What Is Included
- Technical documentation (architecture, API description, settings)
- OData setup on the 1C:ERP server
- Development of connector to ESB (RabbitMQ/Kafka)
- Administration console (manual resynchronization, log viewer)
- Training for 1C staff
- 6 months warranty on integration scripts
Estimated Timelines
From 10 to 20 weeks depending on integration scope, complexity of 1C:ERP configuration, and chosen ESB architecture.
Typical Integration Mistakes
- Ignoring OData versioning — updating 1C may change query structure.
- Lack of retry mechanism for temporary failures (solved by ESB).
- Attempting to sync all data at once instead of incremental approach — causes high load on 1C and site.
If you want to automate data exchange between your site and 1C:ERP — contact us. We will audit, propose an optimal architecture, and perform turnkey integration. Get a free engineer consultation. Order integration today and cut order processing time in half.
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
| Method |
Sync speed |
Configuration flexibility |
Resource intensity |
| CommerceML |
High (binary XML) |
Low (fixed schema) |
Low (hardly affects server) |
| REST API directly |
Medium (JSON) |
High (any model) |
Medium (needs two HTTP servers) |
| Message Broker (RabbitMQ/Kafka) |
Very high (asynchronous) |
Medium (event-driven architecture) |
High (needs broker cluster) |
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.
