Developing Bitrix24 Integration with ERP Systems
Bitrix24 is the front office: CRM, tasks, communications. ERP (SAP, 1C:ERP, Microsoft Dynamics, Odoo, Oracle) is the back office: production, finance, warehouse, procurement. Integration between them is needed so that a manager in the CRM sees real stock levels, while production receives orders without manual re-entry. But this is one of the most complex tasks in corporate automation — ERP systems are architecturally not designed for frequent external requests, and data volumes run into millions of records.
Typical Synchronisation Scenarios
Counterparty directories. A client is created in Bitrix24 (lead → company) and must appear in the ERP for invoicing. Or the reverse — a supplier from the ERP is needed in the CRM for a procurement manager. Master data (the counterparty card, details) is stored in one system; the other is the consumer.
Product catalogue and stock. The ERP is the source of truth for stock levels and prices. Bitrix24 receives up-to-date data: when creating a deal, a manager sees the real warehouse stock, not yesterday's figures.
Orders. The deal moves to the "Contract Signed" status — an order for production or dispatch is automatically created in the ERP. The order execution status from the ERP updates the deal stage in the CRM.
Financial documents. Invoice from Bitrix24 → ERP for accounting and generation of primary documentation. Payment from ERP (confirmed payment) → CRM to close the deal.
Architectural Approaches
Direct peer-to-peer integration (Bitrix24 ↔ ERP) is an anti-pattern for complex systems. The correct architecture includes an intermediate layer.
Integration bus (ESB/iPaaS). Bitrix24 and the ERP communicate through an intermediary: Apache Kafka, RabbitMQ, or an iPaaS platform (1C-integrator, Mulesoft, WSO2). The bus normalises data formats, ensures delivery guarantees, and stores message history. This is the enterprise standard.
Microservice adapter. A custom service (PHP/Python/Go) that knows both APIs. It receives events from Bitrix24 via webhook, transforms data, and calls the ERP API. And vice versa. Simpler to implement, but scales poorly as the number of integrated systems grows.
File exchange via FTP/S3. Works with ERP systems that do not provide an API (outdated versions of SAP R/2, some 1C configurations). The ERP exports XML/CSV on a schedule, the adapter fetches the file, parses it, and loads it into Bitrix24. Reliable, but introduces a lag of several minutes.
Integration with 1C:ERP
The most common case. Technical options:
Via Bitrix24 REST API + 1C HTTP service. 1C:ERP supports publishing HTTP services (analogous to REST endpoints). The adapter calls the 1C HTTP service to retrieve data, and the Bitrix24 REST API to write it. The direction of request initiation matters: for synchronous operations (check stock) — Bitrix24 initiates the request to 1C. For asynchronous events (order fulfilled) — 1C notifies the Bitrix24 webhook via an HTTP request.
Via standard exchange. If a 1C ↔ site exchange (CommerceML) is already configured, it can be extended for CRM needs. This is a compromise — the CommerceML protocol is designed for an online store, so it requires adaptation for CRM data.
Via an intermediate database. 1C writes changes to a separate database (PostgreSQL, MySQL), the adapter reads from it and publishes to Bitrix24. Slower, but isolates the ERP from the load of direct API requests.
Data Transformation
The main technical challenge is the mismatch of data models. Example: in the ERP a counterparty is a legal entity with a tax ID, registration codes, bank accounts, and multiple contracts. In Bitrix24 it is a crm.company with a set of fields and linked contacts. A mapping is required:
| ERP entity | Bitrix24 entity | Link key |
|---|---|---|
| Counterparty | crm.company | Tax ID (UF_INN) |
| Contract | crm.deal (type "Contract") | Contract number (UF_CONTRACT_ID) |
| Nomenclature | Catalogue product (crm.product) | 1C code (XML_ID) |
| Customer order | crm.deal | ERP order number (UF_ERP_ORDER_ID) |
| Payment invoice | crm.invoice | ERP invoice number (UF_ERP_INVOICE_ID) |
Link keys (external identifiers) are stored in custom fields UF_*. This allows idempotent record updates without duplication: before creating, search by key; if found — update; if not — create.
Conflict Management
In bidirectional synchronisation, conflicts are inevitable: the same record is changed in both systems simultaneously. Strategies:
- Master system. For each data type, a source of truth is designated. Prices and stock — from the ERP; comments and communication history — from Bitrix24. A record in the master system always takes priority.
- Timestamp-based merge. The more recent record wins. Works for simple fields, breaks on simultaneous changes.
- Locking. After sending data to one system, the field is marked as "in sync" until confirmation arrives. Complex to implement, but reliable.
Monitoring and Debugging
An ERP integration is a long-lived system. Monitoring is required:
- Message queue: queue size, number of unprocessed messages
- Transformation errors: data type mismatches, missing reference values
- Synchronisation lag: time between a change in the source and its appearance in the target system
- Metrics dashboard — in Grafana or via Bitrix24's built-in reports
Project Stages
| Stage | Content | Duration |
|---|---|---|
| Analysis and specification | Data map, scenarios, architecture selection | 2–3 weeks |
| Adapter prototype | One scenario (e.g. counterparty sync) | 1–2 weeks |
| Core scenario development | Full set of integration flows | 3–6 weeks |
| Directory mapping | Normalising reference data | 1–2 weeks |
| Testing | Edge cases, load, conflicts | 1–2 weeks |
| Historical data migration | Transferring accumulated data | 1–3 weeks |
| Pilot and stabilisation | Running on a limited data volume | 1–2 weeks |
An ERP integration project is not a one-time development effort — it is a long-term system that must be maintained whenever either platform is updated. This should be factored into the budget from the outset.