Parsing Excel into Bitrix: why import breaks
Parsing Excel into Bitrix looks like an evening task: read a spreadsheet, map columns, write to catalog.
In production, what breaks is not the code but the quality of the file — supplier rearranges the header, adds a separator row, merges columns, and Excel import into Bitrix silently uploads zeros instead of prices into catalog.
The first typical failure is price and stock desynchronization. If catalog update runs in two independent passes, a window remains between them when a product is sold at the old price with already zero stock: the customer places an order that physically does not exist.
The second is duplicate items. A SKU with a space, non-breaking space, or different case creates a new card because matching uses the raw string, not a normalized external code. The catalog bloats, properties and stock spread across copies.
The third is export interruption midway. The script hits the execution time limit: some products updated, some left with old prices, and no one parses CSV load errors line by line — the discrepancy surfaces only through customer complaints.
We analyze how this is closed: key normalization before matching, writing in one operation, and file validation before start — this is how automatic price import stops depending on supplier accuracy.
What automatic import delivers: time, errors, control
Manual price upload looks harmless while the catalog is measured in hundreds of items. At thousands of rows, price discrepancies, lost SKUs, and duplicates appear, and stock in the card diverges from actual — the order is canceled after confirmation.
Automatic product import removes this work from the manager: an Excel or CSV file is picked up on schedule, rows are matched by SKU and supplier code, changes are applied to the 1C-Bitrix catalog in batches.
Scheduled catalog update — at night or every half hour — keeps prices and availability current without human involvement, and the reduction in manual work is visible by the share of items that require no edits at all.
A separate effect is stock reconciliation. Instead of a one-time export, the system compares warehouse data line by line, marks discrepancies, and by a given rule zeroes out or hides missing products.
A whole class of failures goes away: selling an item that is not in stock, and a return that eats customer trust.
Control remains with humans: the import log records how many rows came in, how many updated, how many rejected and why. Review takes minutes and concerns only disputed records, not the entire file.
Source formats: Excel, CSV, and exports from accounting
The source determines not only the parsing format but also how often you'll have to return to the task. Excel is convenient when a human maintains structure: columns are renamed, separator rows and merged cells are added.
CSV import is more predictable — it is plain text, but encoding and delimiter break uploads no less often than errors in the data itself.
Export from 1C removes manual labor, but its schema lives by accounting rules: attributes, reference books, and units of measure arrive as they are customarily stored, not as the catalog expects them.
Therefore, we first fix the table structure and field mapping — otherwise any change on the source side breaks the load.
Comparison of upload options
| Option | When suitable | Limitations |
|---|---|---|
| One-time file import | Catalog migration at launch or major assortment update | Manual launch, table structure checked before each upload |
| Regular scheduled export | Supplier price lists that change predictably | Breaks when source columns change, need review of rejected rows |
| Intermediate table | Multiple sources with different structures, normalization needed | Requires policy: who and when updates the intermediate layer |
| Exchange with accounting system | Products, prices, and stock change constantly | Depends on access and exchange schedule, conflict handling needed |
One-time import covers migration, regular synchronization covers freshness; mixing them in one scenario is not advisable.
On 1C-Bitrix, we usually leave the file as an emergency channel, and build the main flow through exchange with accounting: then structure changes in one place and does not require edits in two systems.
How we implement import: engineering work stages
Catalog import is not a one-off script but a policy that lives together with the supplier price list. Files change: columns are added, delimiters shift, some rows arrive with empty SKUs.
So we structure the work order so every change can be checked before it affects the production catalog.
Work order
-
Analysis of source files. We look at all export variants: encoding, delimiter, merged cells, multiple sheets in the workbook, duplicate SKUs. We record required and optional columns — loader behavior on incomplete rows depends on this.
-
Field mapping schema. Price list column → property or infoblock field, plus normalization rules: decimal separator, units of measure, pack multiple, binding to sections by product group. We agree on the schema in writing — after that all edits go only through it.
-
Upload setup. Update by external key (SKU or supplier code) so a repeat run changes price and stock rather than spawning duplicates. Modes are separated: update existing, create new, hide items not in the file.
-
Test environment. We work on a catalog copy: a dry run writes a log per line — what updated, what skipped and why. We reconcile the total by item count and selectively by cards.
-
Upload policy. Schedule via Bitrix agent or system scheduler, behavior on partial failure: file recorded, transaction rolled back, catalog not left half-updated. The export archive allows return to the previous price list version.
-
Handover and support. We provide the field schema, policy, and review of typical errors, and train the employee who will run the upload. Then we respond to supplier format changes — usually within a couple of days.
What we hand over at output: settings and policies
An import that works but is not documented lives until the supplier's first export change.
Therefore, together with the configured exchange, we hand over a package that lets upload be operated and changed without us: file parsing rules, profiles, field mapping schemas, run logs, and employee instructions.
- Row processing rules — how the file is read: delimiter and encoding, number and date format, behavior with empty cells, spaces in SKUs, and duplicate rows.
- Upload profiles — a separate settings set per supplier or marketplace: own source, own template, "update only" or "create and update" mode, unpublishing missing items.
- Mapping schemas — a "column in file → catalog field or property" table with required, calculated, and ignored marks, including binding to sections and trade offers.
- Import log — report per run: time, how many rows accepted, how many rejected and why, which files were partially processed and require rerun.
- Import documentation — description of all profiles and their settings with file examples, so an edit can be made without reconstructing logic from code.
- Instruction for content manager — step-by-step scenario: how to start exchange manually, how to schedule it, how to read the report, and what to do on error in a specific row.
- Support and acceptance policy — frequency of reconciliation with supplier, order of test run on catalog copy, and control row set used to verify correctness after any changes.
Case study: price list with several thousand items without manual editing
A wholesale supplier has a catalog of about 6,000 items, and price lists come as Excel and CSV files from a dozen suppliers, each with its own structure. Consolidation rested on a manager: update took 6-8 hours, price discrepancies surfaced after shipment. About every eighth item required manual edit — the file could not simply be uploaded.
SKU matching
Main work went into matching rules for import into 1C-Bitrix: SKU normalization (case, separators, leading zeros, similar Latin and Cyrillic characters) and priority of exact match by the "SKU + manufacturer" pair.
Items that did not match go to quarantine with a report, not into catalog — the manager reviews a discrepancy list instead of a sheet of thousands of rows.
Update policy
The import starts on schedule and before publication compares structure and file volume with the previous run, cutting off corrupted exports.
Prices, stock, and characteristics are updated in one set, so the site never has a state where some items already have new prices and some have old ones.
After migration, price list update takes 15-20 minutes instead of 6-8 hours. Matching errors — a few per run instead of hundreds, share of items edited manually dropped from 12% to 2%.
The catalog is updated by shift opening, and the manager handles orders instead of reconciling files.
How does one-time upload differ from regular synchronization?
One-time upload is a single migration: the file is parsed, rows are matched to catalog cards by external code or SKU, and the result is recorded as is.
At input, encoding, delimiter, and number format are taken into account; otherwise prices with a comma instead of a dot go to garbage.
This is how project launch, migration from another platform, or first delivery from a wholesaler is handled, and the migration itself runs in one transaction — a failure midway through the file does not leave the catalog half-updated.
Regular synchronization is needed where data changes constantly: prices, stock, bundle, warehouse quantities. Here the exchange schedule works — once an hour, once a day, or when a new file appears in the export folder.
The fundamental difference is that the catalog is not fully re-uploaded: the system calculates the difference between the fresh export and current state and applies only that.
Partial update is what makes such a scheme safe. Only fields marked as updatable are compared: price and stock change, while manually added description, photos, and section binding remain untouched.
An item not in the new file is not silently deleted — it goes to report and awaits a decision, otherwise one corrupted export will zero out the catalog.
The selection criterion is simple. If the supplier provides a file less than once a month and column structure is stable, one-time upload with manual launch is enough.
If prices or stock live their own life, exchange schedule removes manual editing and discrepancies between warehouse and site.
Common technical questions about table import
Table import rarely goes smoothly from the first file: export arrives with empty SKUs, mismatched delimiters, and traces of manual edits. We review how the catalog behaves in four situations that most often raise questions.
What happens to corrupted rows — will the import fail entirely?
No. A row with an empty SKU or broken column count goes into the error report, other items are processed normally. Upload does not stop — you get a list of rows with rejection reason.
The file arrived in a different encoding — will data turn into gibberish?
Encoding and delimiter are set in the profile: before parsing, values are converted to a single format, so a semicolon instead of comma does not merge columns.
We remove the invisible service character at the beginning of the file separately — it most often corrupts the header row.
How does import handle duplicate products?
The matching key is SKU or external code, not name: matched — update card, not matched — create new. If SKUs duplicate across price lists, we add a merge rule by manufacturer code, otherwise the catalog will start to bloat.
What happens if upload breaks midway?
Import runs in chunks, processing position is recorded before each write. If connection breaks, the catalog remains in a consistent state, and the next run continues from the last successful row without rebuilding everything. Full replacement is performed only after parsing the entire file.
Let's discuss the task: we'll return with an estimate and work plan
To return with an import estimate and a work plan, we don't need full access to the entire project — a test catalog copy and one real export file are enough. From it we see column structure, data types, duplicates, and "empty" rows that most often break upload.
If the supplier provides an export sample, we'll take it as is, with all its deviations from format.
We will separately discuss matching rules: which column becomes product name, which we bind to section, what goes to properties, how we calculate price and stock, what to do with missing items.
Here we also fix the person responsible for data on your side — they confirm rules and resolve disputed cases when the file contradicts the current catalog.
What we need from you to start:
- access to test catalog copy or separate section for trial upload — we change nothing on live catalog
- an Excel or CSV export sample in the form the supplier provides it, not manually "polished"
- 2-3 examples of rows that previously loaded with errors or were duplicated
- column mapping rules: section, properties, units of measure, multiple, tax rate
- update policy: full catalog replacement or loading only changes, and how often
- one person responsible for data on your side — with authority to approve rules rather than coordinate every row
- supplier contact or their format description, if export changes from batch to batch
This is enough to assemble a prototype on your file, show how problematic rows will be handled, and estimate work volume for your catalog. Describe the task and attach an export sample — we'll return with an estimate, work plan, and list of checks we will close before going live.
