How to Configure One-Way Export from 1C to 1C-Bitrix
Imagine: a manager manually changes a price on the site, and an hour later a CommerceML export from 1C overwrites it back. A familiar scenario? In one-way export, this is standard behavior — and it must be accounted for.
One-way export is a scenario where 1C is the single source of truth for the catalog: prices, stock, and product attributes are managed only in 1C and pushed to the site via scheduled tasks. The site sends nothing back. The scheme's simplicity is its main advantage, but it is also the primary source of problems when configured incorrectly. We set up the exchange so that content remains under site control while accounting data syncs without conflicts. Typical setup cost is calculated individually based on your needs.
When Is One-Way Export Justified?
- Product content (descriptions, images) is managed on the site, while accounting data (prices, stock, SKUs) is managed in 1C.
- No risk of version conflicts — 1C always overwrites data on the site.
- Maintenance simplicity outweighs flexibility, and the exchange is configured once.
Common mistake: using one-way export while manually editing prices or stock on the site. The next exchange will overwrite all changes without warning. This is the main cause of incidents in stores with new managers. To avoid this, clearly separate data sources.
How to Protect Content from Overwrite?
The key task is to explicitly define which fields come from 1C and which are managed on the site.
In the exchange module settings (Settings → Product Settings → Online Store → Fields for update), we recommend:
| Field | Source | Comment |
|---|---|---|
| NAME | 1C | If nomenclature is well-maintained in 1C |
| Prices | 1C | Always from 1C |
| Stock | 1C | Always from 1C |
| ARTICLE | 1C | Always from 1C |
| DETAIL_TEXT | Site | SEO description written by copywriter |
| PREVIEW_PICTURE, DETAIL_PICTURE | Site | Retouched photos |
| SEO_, META_ | Site | Metadata for search engines |
For fine-grained code-level control — the OnIBlockElementBeforeUpdate handler:
\Bitrix\Main\EventManager::getInstance()->addEventHandler( 'iblock', 'OnIBlockElementBeforeUpdate', function(\Bitrix\Main\Event $event) { $fields = $event->getParameter('fields'); $protectedFields = ['DETAIL_TEXT', 'PREVIEW_PICTURE']; foreach ($protectedFields as $field) { unset($fields[$field]); } return new \Bitrix\Main\EventResult( \Bitrix\Main\EventResult::SUCCESS, ['fields' => $fields] ); } ); This handler guarantees that even if content fields arrive in the CommerceML XML file, they will not be applied. Use it together with module settings for double protection.
Why Is Deactivating Missing Items Important?
The option "Deactivate items not transferred during exchange" is dangerous but often necessary. If an item is discontinued in 1C, it should disappear from the site. Enable it only after confirming that the full export includes the entire active assortment. Partial exports (only changed items) do not work with this option — they deactivate everything not present in the file.
Compare with two-way export: one-way reduces data loss risks by 2–3 times if content is managed on the site. Below is a summary table.
Comparison of Export Schemes: One-Way vs Two-Way
| Parameter | One-Way | Two-Way |
|---|---|---|
| Data conflicts | Minimal — 1C always has priority | High risk of conflicts with simultaneous edits |
| Setup complexity | Low (4–8 hours) | Medium (1–3 days) |
| Flexibility | Low — all accounting data from 1C only | High — can edit on both sides |
| Maintenance | Simple — single source of truth | Requires constant sync monitoring |
One-way export is especially suitable for stores with large catalogs where content is prepared separately and accounting is done in 1C. CommerceML is the standard protocol for such exchange.
Step-by-Step Configuration Process
- Audit the current exchange scheme and catalog structure.
- Design export rules with field separation.
- Configure the exchange module on the site and 1C (scheduled task).
- Protect content fields using the
OnIBlockElementBeforeUpdatehandler. - Test all scenarios: full export, partial, deactivation.
- Document the exchange scheme for your staff.
- Train managers on catalog management rules.
Timeline and Cost
Basic one-way export setup with field protection — 4–8 hours. If historical data needs cleanup and standardization of the existing catalog — 1–2 days. Cost is calculated individually based on your specific requirements. We guarantee stable exchange operation after implementation. Our experience: 5+ years of integrations and over 50 successful projects.
Order one-way export setup from us to ensure stable operation. For consultation, contact us or get a preliminary cost estimate for your project.