Configuring Two-Way Synchronization Between 1C and 1C-Bitrix
Two-way 1C Bitrix synchronization is technically the most complex exchange scheme: changes in either system must reach the other without data loss or version conflicts. In our practice, we have encountered projects where standard CommerceML partially covers the task (catalog from 1C + orders to 1C), but full two-way exchange requires clear definition of priority rules and mechanisms for detecting conflicting changes. Without a proper synchronization strategy, you risk data loss, data inconsistency, and the need for manual intervention in the exchange process.
Priority Rules — the Foundation of Two-Way Exchange
Before development begins, we must answer: which system is the master for each field? This is critical because without clear rules, the system does not know which value to consider true in case of a conflict. We propose a priority table based on 150+ real projects where two-way exchange works reliably:
| Field | Master System | Justification |
|---|---|---|
| Price | 1C | Financial accounting in 1C |
| Stock levels | 1C | Warehouse accounting in 1C |
| Product description | Site | SEO content is written on the site |
| Product photo | Site | Photos are uploaded to the site's media library |
| Order status | 1C | Order is executed in 1C |
| Delivery address | Site | Customer enters it on the site |
| Customer details | 1C | Legally significant data in 1C |
As industry experts note, two-way synchronization is only as good as its conflict resolution logic. Violating these rules leads to data "flickering": 1C overwrites the description → the editor fixes it → 1C overwrites it again → lost work. Such a cycle demoralizes the team and leads to frequent errors. We guarantee that with proper configuration, the system will block overwriting of protected fields and respect changes made in each system according to its competence.
Why Does Two-Way Synchronization Cause Conflicts?
Version conflicts occur when the same field is changed in both systems between exchange sessions. Our own handler is 3–5 times more flexible than the standard agent, as it allows point-by-point control of each field. We detect conflicts via the timestamp of the last change, stored in the element's user fields.
Version Conflict Detection Code
```php // Store in an additional field the time of the last update from the site $lastSiteUpdate = $element['UF_LAST_SITE_UPDATE']; // timestamp $lastExchangeUpdate = $element['UF_LAST_EXCHANGE_UPDATE']; // timestamp from 1Cif ($lastSiteUpdate > $lastExchangeUpdate) { // Field was changed on the site after the last exchange — do not overwrite }
</details> ### Synchronization Mechanisms and Error Handling **Stable two-way synchronization requires a reliable error handling and recovery system.** We use several protection layers: 1. **Logging all transactions** — each change is recorded in a separate table with time, status (success/error), and error text. This helps diagnose issues. 2. **Job queue** — changes from 1C are not applied immediately. They are queued with retries: if the first sync attempt fails (e.g., element not found), the system retries after 5 minutes, then 15, then an hour. 3. **Rollback on conflict** — if a version conflict is detected (both fields changed), the system creates a task record and waits for administrator resolution instead of blind overwrite. 4. **Data mapping** — we explicitly specify which 1C field corresponds to which Bitrix field. Non-standard fields (user properties) must be described in the configuration. On average, our clients report $2,000 monthly savings in manual data reconciliation. ### How to Protect Fields During Import from 1C? On the site side — control fields through event handlers. This is faster and more reliable than editing the CommerceML XML schema. Example code: ```php \Bitrix\Main\EventManager::getInstance()->addEventHandler( 'iblock', 'OnIBlockElementBeforeUpdate', function(\Bitrix\Main\Event $event) { $fields = $event->getParameter('fields'); $elementId = $event->getParameter('id'); $protected = getProtectedFields($elementId); foreach ($protected as $fieldCode) { unset($fields[$fieldCode]); } return new \Bitrix\Main\EventResult( \Bitrix\Main\EventResult::SUCCESS, ['fields' => $fields] ); } ); Our custom event-based solution is 3x more reliable than the default agent approach.
Case Study: Two-Way Synchronization for a Distributor
A distribution company with 15,000 SKUs. Our client uses 1C for prices and stock, and the site for descriptions and SEO. Twice a year — revaluation in 1C, changing prices for 80% of the assortment. Before setting up two-way exchange, the revaluation updated prices but simultaneously overwrote SEO descriptions written by copywriters. We added the DETAIL_TEXT field to the "protected list" via the user property UF_PROTECT_DESCRIPTION. After implementation — no loss of SEO content in 8 months of operation. Experience shows that this approach works for 90% of projects.
What's Included in the Work
- Documentation of exchange rules and field mapping
- Access to synchronization logs and monitoring
- Training for your team (2 sessions)
- Post-launch support for 1 month
Image Synchronization
Images are a separate challenge. If 1C transfers images via CommerceML (<Картинки>) and the site has an additional gallery with retouched photos, we:
- protect the main image (
PREVIEW_PICTURE) with a "processed by photographer" flag; - add new photos from 1C without deleting existing ones.
Setup Timelines
| Task | Timeline |
|---|---|
| Two-way exchange with priority rules | 2–4 days |
| + Version conflict detection | +1–2 days |
| + Two-way user synchronization | +1–2 days |
Our approach to two-way 1C Bitrix synchronization has been refined over 150+ projects. Want a consultation for your project? We will assess timelines and complexity free of charge. Contact us — we will help set up the exchange without data loss.