If a website shows the wrong price or stock quantity, do not begin by re-exporting the entire catalogue. First trace one product through the whole route: 1C data → exchange package → import → Bitrix data → visitor-facing display. This identifies where the value first became incorrect. The result is a specific example to fix rather than a general “synchronisation is broken” request.
Collect evidence before changing settings
Select one affected product and one similar working product. Record item code, external identifier, variant, expected price, currency, unit, warehouse and the last change time in 1C. Add the page URL and observation time with timezone. For personal prices, specify the test user’s group without sharing a password.
You need the 1C version and configuration, exchange module name and version, CMS edition and job-launch method. Do not change these during diagnosis. The official 1C integration course covers different modules and settings: instructions for another configuration or version may not apply to your installation.
Determine which system controls each field. For example, 1C may own base price and stock while the website owns descriptions and SEO copy. Manually editing a website price is not an exchange fix if the next export legitimately overwrites it. Without clear ownership, two editors or systems can endlessly reverse each other’s changes.
Step 1. Make sure you are comparing the same thing
A product name is a weak identifier. Identically named items may differ in packaging, modification or external code. Item codes sometimes repeat too. Exchange depends on the actual identifier mapping in your design, not on product pages looking alike.
Pay particular attention to product offers. The parent “Work jacket” record and its “blue, size 52” variant may be separate entities. Price, stock and customer availability may belong to the variant while your screenshot shows the parent. Record both and their relationship. Do not create a new product to repair a relationship before finding the cause: that can duplicate the catalogue.
| Comparison | Reference | Common confusion |
|---|---|---|
| Product and variant | External IDs and relationship | Size versus model |
| Price | Type, currency and unit | Retail versus wholesale |
| Stock | Warehouse and calculation rule | Physical versus available quantity |
Compare prices for the same unit. One item, a set and a pack of ten are not equivalent values. Also record whether the displayed amount includes tax and whether a discount applies. Establish these calculation conditions instead of inferring them from the final number.
Step 2. Check the source in 1C
Open the selected item’s data in 1C with the employee responsible for accounting. Confirm that the change was saved and is included in the exchange in use. A new price appearing in a document does not prove it is effective on the relevant date or selected for export.
Compare selection settings: organisation, price type, warehouses, product groups and other module-specific conditions. If the issue began after selection changed, retain previous and current values in the report. Do not expand selection to the entire catalogue without understanding the consequences. The website may receive items and terms not intended for publication.
Agree the availability formula. It may account for reservations, expected receipts, selling without stock and other rules. There is no universal “1C stock” formula for every configuration. Compare the value the business intends to display or sell against the value actually transferred.
Step 3. Find the value in the exchange package
Ask the responsible specialist to retain a small diagnostic package or log excerpt from the specific run. Work on a copy with personal data, passwords and service tokens removed. An exchange package may contain more than the public catalogue reveals; do not attach the whole package to a public message.
Find the selected external ID, relevant price or quantity and run marker. Check the package that actually reached the website: a local file from another time does not prove successful transmission. Record the literal result: “Package price 1200”, “Item absent” or “Only another price present”. Absence from a partial package does not always mean deletion; that depends on exchange mode.
If the value is correct in 1C but wrong in the export, investigate source data, selection or pre-send transformation. If the package is correct, move to receipt and import. You can already divide responsibility between the 1C specialist and website developer without asking both to “check everything”.
Step 4. Separate transfer from import
A successful connection and file upload do not prove every value was applied. Check completion of the specific exchange session and its import messages. One stage of a multistage process may finish while the next stops because of time limits, invalid data or resource limits.
Correlate start and finish times, received package size, processed-object count and errors for the affected ID. If scheduled, establish whether a new job starts before its predecessor finishes. Fix overlap through launch coordination and locking, rather than repeated manual starts.
Distinguish full and partial exchange. Full exchange sends the entire agreed dataset; partial exchange sends changes according to the mechanism’s rules. Check how your version handles absent items, deletion and deactivation. Before a full exchange, understand especially what happens to manually created product pages and local edits.
Training example: the price exists, but the storefront shows another
A fictional “Work jacket” model has external ID demo-jacket, and its blue size-52 variant has demo-jacket-blue-52. The training package sends two prices for this SKU: base price RUB 1,000 and retail price RUB 1,200. Both exist in the administration area. A guest sees RUB 1,000 although the agreed public price is RUB 1,200. This is a fictional diagnostic example.
The route through storage is correct. Next ask which price type the page component selects and whether a guest may see it. If the template uses the base price, another import will not fix the display. Correct price-type selection and permissions, then check the product page, listing, search and basket if used. One correct number on a product page does not validate the entire purchase journey.
A second training symptom: there are 12 units physically in stock, 3 reserved and, under this example’s agreed rule, 9 available. The site shows 12. Establish whether it reads physical quantity, a separate availability field or its own warehouse total. The formula 12 − 3 = 9 applies only to this training rule. Do not apply it to another configuration without agreement.
Step 5. Check display and caching
If Bitrix stores the correct values, check the page in the user context where the fault occurred. Guests, retail customers and wholesalers may receive different prices. Account for city or warehouse selection, currency, discounts and product variant. Each context needs its own expected result.
Compare product pages, category listings, search results and orders. They may use different components and settings. If only one block is wrong, that strongly suggests a local display problem. Do not alter the source data to compensate for an incorrect block.
Check caching after comparing stored data. A one-off cache clear may remove the symptom without restoring cache invalidation after imports. Test the next change to the same product: does its display update without intervention? If the issue recurs, fix cache dependencies or refresh logic. Permanently disabling caching usually hides the issue and increases load.
Make fixes reversible
First reproduce the fault on a protected test copy with real exchange, email and payments disabled. Back up affected settings and data. Change one cause at a time: selection, mapping, price type or display. Repeat a limited training exchange and compare the result.
Before the live maintenance window, decide who stops and resumes the schedule, which run is the control run and where the previous configuration is stored. Do not delete the catalogue for a “clean import”: that may change URLs, relationships, baskets and order history. A full re-export must be a deliberate operation with verified rules, not a universal first step.
Rollback depends on what changed. Restoring a setting does not undo incorrect prices already written. Restoring the whole database to an earlier date may delete new orders. Plan targeted restoration of affected data or agreed reconciliation of new records. If uncertain, stop further damaging runs and preserve diagnostic evidence instead of experimenting on the entire database.
Acceptance: one corrected product is not enough
- Check the affected and control SKUs, a product without variants and a product with several variants.
- On the test system, change a price, then a quantity. Confirm that both changes propagate independently.
- Test zero stock, return to stock and a missing price under the agreed rules.
- Compare a guest and a logged-in test customer if prices depend on permissions.
- Wait for the next scheduled run: the fix must persist without manual cache clearing.
- Check that there are no duplicates and that URLs, images and site-edited copy have not changed.
Keep the control-run time, external ID and expected versus actual values at every stage in the report. This lets another specialist continue the investigation. “Everything works” without this evidence does not explain what was fixed.
When you do not need a new exchange module
If the package and stored data are correct and only template price selection is wrong, buying another exchange will not fix the cause. If schedules overlap, first fix run coordination. If 1C selection is wrong, another importer receives the same wrong data. Consider a new module after identifying a limitation in the existing solution and checking compatibility.
SKU means a specific product offer; an external ID matches records between systems; a delta is a set of changes; an exchange session is one transfer-and-processing cycle; a cache stores a computed or rendered result. A completed single-SKU trace makes a useful attachment to a 1C–Bitrix integration task and helps you verify the fix independently.
Apply this to your own project
Find the first stage where one SKU’s price or stock diverges, collect evidence and accept the fix without a speculative full re-export.
Single-SKU 1C–Bitrix exchange trace: open the worksheet · Download the CSV to complete. Free access, no registration. Use it independently or pass it to your contractor.