Configuring One-Way Export from 1C to 1C-Bitrix
One-way export is a scenario in which 1C is the sole source of truth for the catalog: prices, stock levels, and product attributes are managed exclusively in 1C and transferred to the site. The site sends nothing back to the product data side. The simplicity of this scheme is its main advantage — and the main source of problems when misconfigured.
When This Is the Right Choice
A one-way scheme is justified when:
- Product content (descriptions, photos) is managed on the site, while accounting data (prices, stock levels, SKUs) is managed in 1C
- There is no risk of version conflicts — 1C always overwrites site data
- Simplicity of maintenance matters more than flexibility, and the exchange is configured once for the long term
Common mistake: using one-way export while manually editing prices or stock levels on the site. At the next exchange, all changes will be overwritten without warning. This is the primary cause of incidents in stores with new managers.
Configuring the Prohibition of Reverse Data Transfer
In the site's exchange module settings, disable order exchange if it is not needed:
Settings → Product Settings → Online Store → Exchange with 1C → Orders:
- Option "Export orders to 1C": disable if orders in 1C are not needed
On the 1C side in the scheduled task:
- Enable only "Export products and stock levels"
- Disable "Import orders from site"
Protecting Content from Overwriting
The key task in one-way export — clearly define which fields come from 1C and which are managed on the site.
Settings → Product Settings → Online Store → Fields to update:
Recommended list of fields to overwrite from 1C:
- Name (
NAME) — if 1C maintains proper nomenclature - Prices — always from 1C
- Stock levels — always from 1C
- SKU (
ARTICLE) — always from 1C
Fields that must remain under site management:
-
DETAIL_TEXT— SEO description written by a copywriter -
PREVIEW_PICTURE,DETAIL_PICTURE— retouched photos - Tag properties (
SEO_*,META_*) — metadata for search engines
For fine-grained control at the code level — an OnIBlockElementBeforeUpdate handler that checks a list of protected fields and removes them from the update array:
\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]
);
}
);
Deactivating Products Not Included in the Export
The "Deactivate products not transferred in the exchange" option — dangerous but often necessary. If a product is discontinued in 1C — it should disappear from the site. Enable only after confirming that the full export genuinely includes the entire active assortment. Partial exports (only changed items) and this option together do not work — they deactivate everything not present in the file.
Setup Timeframes
Configuring one-way export with content field protection — 4–8 hours. More complex if historical data needs to be resolved and the existing catalog brought into a consistent state — 1–2 days.