Excel/CSV Parsing: Automatic Import to 1C-Bitrix

Parsing Excel into Bitrix: where import breaks

A supplier's price list arrives as a spreadsheet: its own column names, units of measurement, merged cells, SKU sometimes with a space, sometimes with a hyphen. While there are dozens of items, the manager transfers them by hand and doesn't see the catch.

With thousands of rows, manual transfer becomes a source of discrepancies: the price in the product card is one thing, in the invoice another. Parsing Excel into Bitrix removes some of these errors, but only when parsing rules are described in advance.

Stock discrepancies accumulate quietly: the upload runs against an old file, some rows are filtered out by a rule — and the storefront offers a product that isn't in stock.

The customer places an order, the manager calls with apologies, and the next price list drags the same errors along.

Duplicate products in the catalog appear where the supplier changed the SKU or the spelling of the name. The system faithfully creates a new product card, while the old one remains with zero stock and its own descriptions. Search returns two items instead of one, and characteristics are filled in for half the products.

Lost rows are a separate problem: the file didn't finish downloading, the column structure shifted, and some items simply didn't update. No one notices until a customer stumbles upon an outdated price. At such moments the storefront sits with an incomplete assortment.

We break down how this is addressed: structure validation before upload, a stable key for linking a price list row to a product card, and a separate policy for items that are no longer in the file.

What automatic price list import into the catalog gives

A supplier price file is read line by line, without fully loading it into process memory — so a catalog with tens of thousands of items is rebuilt in minutes, not hours.

First, rows pass validation and go into an intermediate table, and only then are applied to the catalog in batches: section, brand, product type.

Each batch runs in a transaction, and if an error arrives midway, a rollback is applied — the catalog remains in a consistent state, not half-updated.

Filtering defective rows is a separate layer of rules. Empty or non-unique SKU, text instead of a number in price, negative stock, zero price, column misalignment — such a row doesn't enter 1C-Bitrix at all, but goes to a report with the row number and reason.

On real price lists, 2–5% of items are filtered out this way: without this layer they settle in the catalog as products with zero price or duplicates and surface in orders.

Price and stock updates are done by matching by external code and SKU, so a repeated run doesn't create duplicates and doesn't break links to trade offers.

Only items whose values actually differ are changed — search reindexing and catalog cache are not triggered for the entire volume, and the upload doesn't kill site responsiveness during sales hours.

Stock is written separately from prices so product availability doesn't wait for trade offer recalculation.

The data upload schedule fixes the timetable, the person responsible for the file, and the entry point for manual launch. A whole class of failures goes away: catalog with old prices, sold product in stock, manager editing items manually after every supplier mailing.

An upload failure is visible in the log on the first run, not a week later via a customer complaint.

Methods of loading data from Excel: comparison of modes

The Excel loading mode is chosen not by developer convenience but by data update frequency and who owns the source.

If the price list arrives quarterly, there's no point in setting up scheduled exchange; if prices and stock change daily, manual Excel loading becomes a constant operation with the risk of human error.

In practice, options are combined: one-time import fills the catalog, schedule updates prices, and exchange via the exchange module covers stock and orders.

The difference between them is in requirements for format stability, presence of a reverse flow, and who and how often handles a failure.

We fix the choice in the technical solution: for each source — its own scenario, its own row validation rules, and its own rollback order. Below we break down how this looks in practice.

Implementation stages of import: from file analysis to handover

Import from Excel or CSV almost never comes down to "read a table and write to an information block".

Supplier exports contain merged cells, SKUs in different formats, duplicate rows, and hidden sheets, while the catalog has trade offers and properties that are not in the file. Therefore we structure the import implementation stages so that each ends with a verifiable result.

1. Audit of files and catalog. We collect exports, review column structure, value types, and update frequency; in the catalog we record information blocks, properties, and the link to trade offers. Without this map, any mapping rule is a guess.
2. Field mapping rules. We formalize as a table: file column → property, type conversion, default value, requiredness. We separately describe new items and updates to existing ones so manual edits are not overwritten.
3. Handler setup. File parsing, value normalization — encoding, delimiters, units, prices — and writing via standard exchange mechanisms. We create a profile for each source so suppliers do not break each other.
4. Test upload run. We run on a copy of the working database and a real export: compare the number of items, prices, sections, and trade offer links; resolve discrepancies before acceptance.
5. Reports and failure handling. We log line by line: what loaded, what was skipped, and why. Some errors go to auto-retry, critical ones to a notification for the responsible person.
6. Acceptance and handover to support. We observe several scheduled runs, check recovery after failure, and hand over the regulations, rule description, typical error instructions, and access credentials.

We agree on the stage order with you: you see what the import rests on and what to do when the supplier changes the export format.

What remains in your hands after implementation

Implementation ends not with launching the exchange but with handing over a package — without it, the first new supplier or change in the price list structure turns into emergency manual troubleshooting.

Below is what remains in your repository and with your employees, not in correspondence with the contractor.

• Exchange configurations — import profiles for Excel and CSV: required and ignored columns, encoding, delimiter, behavior for duplicates and empty rows.
• Mapping rules — table "price list column → catalog field": SKU, units of measurement, tax rate, link to sections and trade offers.
• Data flow diagram — where the file comes from, where it is stored, at which step it is validated, where the log goes on failure, and who receives the notification.
• Import documentation — how file parsing works, which formats are supported, how to add a new column without breaking current rules.
• Price list update schedule — upload frequency, responsible person, procedure for price discrepancies, and rollback to the previous catalog version.
• Instructions for the content manager — step-by-step scenario with error examples: what to check before upload, what to do on failure, whom to contact.

We hand over the package with a walkthrough on your files: we show the launch, answer configuration questions, and after that the exchange works without our involvement.

Case: price list of 40 thousand items without manual edits

A supplier price list with 40,000 items arrived in Excel: different brand spellings, prices sometimes with a wholesale column, sometimes without, and some rows — discontinued products.

The manager manually reconciled it with the catalog, the update took a working day, and all that time prices on the site remained old. Every edit — a risk of discrepancy between the site, warehouse, and invoice.

What changed in import

Import was moved inside 1C-Bitrix: the file is read line by line and put into an intermediate table where each row gets a hash by SKU, name, price, and stock.

Then — comparison with the catalog: only changed items are updated, new ones are added, items missing from the price list are marked inactive rather than deleted.

Search reindexing and cache reset happen after the transaction is committed, so the visitor does not see a half-empty catalog during upload.

Metrics before and after

The load on the catalog remained manageable: writing is done in batches, not one long transaction, so the admin panel and storefront respond during import.

Rows that were not parsed automatically go to a separate report with the reason indicated — they are fixed once, the rule is added, and in the next price list they pass on their own.

How one-time import differs from regular synchronization

One-time import solves the migration task: the file is received, columns are mapped to information block properties, data is loaded, and the output is a report on rejected rows.

Requirements are low: launch by button, ability to stop and repeat from scratch, and human review of the result.

Regular synchronization is a process, not an operation. Price list update frequency appears — once a day, by shift opening, or upon source change — and state between runs: what was loaded, what changed, what disappeared from the supplier.

Upload must be repeatable: the same file submitted twice must not breed duplicate products and prices.

Upload error handling is structured differently. In a one-time scenario, it is enough to write problem rows to the log and send the file for correction.

In continuous exchange, complete failure is unacceptable: the failed item is isolated, the rest of the array passes, and a notification about quarantine goes to the responsible person.

Infrastructure-wise, regular exchange requires a schedule, protection from parallel runs, and result control. Support shifts from "parse the log manually" to monitoring and regulations for when the supplier changes the file structure without warning.

The selection criterion is not the export size but the frequency of data changes and the cost of a pricing error. A quarterly catalog lives on one-time import, a daily price list — only on synchronization.

Technical concerns: encodings, duplicates, upload volumes

Price list import breaks not on exchange logic but on input data: file encoding turns SKUs into garbage, duplicates create a second product card instead of updating the price, and a large file hits the execution time limit. Below are the questions we resolve before launching upload in 1C-Bitrix.

How are duplicate items in the price list filtered out?

Matching is done by external code or SKU, not by name: the supplier may rename the product, the code remains the same. Duplicates within the file are collapsed by a priority rule, and a match with an existing product is closed by updating price and stock, not by a second card.

What happens with a file of a hundred thousand rows and an interrupted upload?

The file is read as a stream, rows are processed in batches, and the remainder goes to the background jobs queue — the size does not hit the execution time limit. Each run writes a log: processed row, rejection reason, rollback of unfinished changes. After a failure, the next run picks up the missing data from the last successful item.

Let's discuss your task and come back with an estimate and plan

So that the estimate for the loading work relies on facts, not assumptions, we need the same data that the import will work with: the export in the form in which it comes from the supplier or accounting system, and a description of how the catalog on the site is structured.

Send what you have now — even if the files are maintained manually and some fields are filled in "as it turns out".

• Samples of Excel/CSV files — two or three, including a "dirty" one: with merged cells, extra sheets, empty rows, and different number formats.
• Catalog structure: sections and subsections, product properties, trade offers, linking items to sections.
• SKUs and mapping rules — by which field we recognize a product that already exists on the site, and what to do with duplicates.
• Policy for new, changed, and missing items: add, update prices and stock, unpublish, or delete.
• Exchange direction: file from the supplier, export from 1C to the catalog, or reverse writing of orders and stock from the site to the accounting system.
• Update schedule: how often the file changes, who exports it, what to do on failure, and how to roll back a failed upload.
• Access to the test environment and schedule for when changes can be made to the production catalog.

Based on this data, we will come back with a timeline estimate and an exchange implementation plan: stages, checkpoints on the test environment, and the launch procedure on the production site.

Describe your import task — we will analyze your files and propose a scheme that will survive a supplier change and the appearance of a new export format.