Diagnosing and Resolving Exchange Errors Between 1C and 1C-Bitrix
The exchange has broken — products are not updating, orders are not reaching 1C. This is a standard situation for any store that has been running for more than six months. The problem is that error messages in the CommerceML exchange are vague, and there can be dozens of possible causes. Below is a systematic approach to diagnostics.
First Diagnostic Point: the Exchange Log in Bitrix
Shop → 1C Exchange Log — the first place to check:
- Green row — exchange completed successfully
- Red row — error, expand for details
- No records — exchange has not been triggered (problem with the schedule or authentication)
Typical messages and their meaning:
| Message | Cause |
|---|---|
Invalid login or password |
Exchange user is blocked or password has changed |
Invalid server response |
HTTP 500 on 1c_exchange.php, check PHP error_log |
Property PROP_XXX not found |
Property was deleted on the site but 1C still sends it |
Time limit exceeded |
PHP timeout while parsing a large XML |
XML parsing error |
Corrupted file or incorrect encoding |
Diagnostics via Direct Request
Check the endpoint manually via curl or Postman:
# Step 1: authentication
curl -c cookies.txt \
"https://myshop.ru/bitrix/admin/1c_exchange.php?type=catalog&mode=checkauth" \
-u "login:password"
# Step 2: initialization
curl -b cookies.txt \
"https://myshop.ru/bitrix/admin/1c_exchange.php?type=catalog&mode=init"
A success response to the first request means authentication is working. A failure response — check the user's permissions and account status.
"Products Duplicated" Errors
The most problematic situation: after the exchange, the number of products in the infoblock has doubled. The cause — the GUID identifiers of products in 1C changed (database migration, restructuring), Bitrix did not find existing elements by ID and created new ones.
Diagnostics:
SELECT XML_ID, COUNT(*) as cnt
FROM b_iblock_element
WHERE IBLOCK_ID = :iblock_id
GROUP BY XML_ID
HAVING cnt > 1;
Duplicates: records with the same XML_ID or similar SKU, different ID.
Resolution:
- Find the mapping between old and new GUIDs via SKU or barcode
- Update
XML_IDon existing elements to the new GUIDs from 1C - Deactivate (do not delete) the duplicates
- Re-run the exchange — 1C will now find elements by the correct XML_ID
Order Exchange Errors
Orders are not reaching 1C. Check:
- The "Export orders" option is enabled in the site exchange settings
- The order status is included in the list of statuses eligible for export
- The exchange user has access to the
salemodule
1C creates orders with "unknown nomenclature". The product in the order lacks the CML2_LINK property with a GUID from 1C. This happens for products created manually on the site. Solution — manually populate CML2_LINK or exclude such products from transmission to 1C.
Encoding Issues
Older 1C configurations may export Windows-1251. The symptom — garbled characters in product names after import.
// In the event handler before import
if (!mb_detect_encoding($xmlContent, 'UTF-8', true)) {
$xmlContent = mb_convert_encoding($xmlContent, 'UTF-8', 'Windows-1251');
}
In newer Trade Management versions this issue has been resolved — export is always in UTF-8.
Case Study: "Missing" Products After Scheduled Maintenance
A hosting provider migrated the database to a new server with a different MySQL version. After the migration, the exchange ran but 12% of products "disappeared" from the site (status ACTIVE = N). The cause: during migration, several thousand XML_ID values acquired trailing spaces due to differences in handling CHAR and VARCHAR fields. Bitrix could not find elements by XML_ID with a space — it created new ones and deactivated the old ones.
Diagnostics identified the problem in 15 minutes (SELECT * FROM b_iblock_element WHERE XML_ID LIKE '% %'). Fix: UPDATE b_iblock_element SET XML_ID = TRIM(XML_ID) — and re-running the exchange restored all products.
Preventive Monitoring
Configure automatic checks after every exchange:
// Suspicious indicators — triggers a notification
$checks = [
'deactivated_count' => 'SELECT COUNT(*) FROM b_iblock_element WHERE ACTIVE = "N" AND MODIFIED_BY = 1', // modified by the exchange agent
'duplicate_xml_id' => 'SELECT COUNT(*) FROM (SELECT XML_ID FROM b_iblock_element GROUP BY XML_ID HAVING COUNT(*) > 1) t',
'last_exchange' => 'SELECT MAX(TIMESTAMP_X) FROM b_iblock_element WHERE IBLOCK_ID = ' . CATALOG_IBLOCK_ID,
];
If the number of deactivated products in a single exchange session exceeds a threshold (e.g., 100 items) — send an alert and block the next exchange session until a manual review is completed.
Diagnostics and Resolution Timeline
| Issue type | Resolution time |
|---|---|
| Authentication error / timeout | 1–2 hours |
| Product duplication | 4–8 hours |
| Encoding mismatch | 1–3 hours |
| Order loss during exchange | 2–4 hours |
| System issues after database migration | 1–2 days |







