1C-Bitrix Data Import Module Development

Custom 1C-Bitrix Data Import Module Development

A client brought an Excel file with 15,000 rows of unique product attributes. The built-in CommerceML couldn't handle the custom format — we needed to update existing items without touching prices or stock. Manual entry would take a month. We built a custom import module in 13 working days. With over 10 years of Bitrix development and 50+ completed integration projects, we guarantee stable performance under load. You get a solution that saves 10x the time compared to manual upload.

The standard catalog module supports import via CSaleImport and CDataExchangeXML for CommerceML 2.x. It works fine for simple catalogs. Problems arise with arbitrary formats (Excel, JSON, XML with non-standard schemas), multi-infoblock imports, updating existing records with merge logic, importing users, orders, CRM entities, and large files (10,000+ rows) without timeouts. A custom module solves these using streaming processing and configurable mapping.

The vendor.importer module is built on three abstractions: Reader (reads source), Transformer (transforms data), and Writer (writes into Bitrix). This architecture allows plugging in any source and target without changing the core. More about the platform can be found on Wikipedia.

How the Module Works

The vendor.importer module revolves around Reader, Transformer, and Writer.

SourceFile → Reader → RawRow[] → Transformer → MappedRow[] → Writer → Bitrix entities 

ReaderInterface:

interface ReaderInterface { public function open(string $filePath): void; public function readNext(): ?array; // null = end of file public function getHeaders(): array; public function close(): void; } 

Implementations: CsvReader, XlsxReader (via PhpSpreadsheet), XmlReader (via XMLReader for streaming large files), JsonReader.

Field Mapping — Import Module Development

Mapping configuration is stored in b_vendor_importer_mapping:

{ "source": "csv", "target": "catalog_product", "iblock_id": 5, "fields": { "article": "PROPERTY_ARTICLE", "name": "NAME", "price": "CATALOG_PRICE_1", "stock": "CATALOG_STORE_PRODUCT_AMOUNT" }, "key_field": "article", "update_strategy": "merge" } 

key_field defines the field to identify existing records. update_strategy:

• merge — updates only mapped fields;
• replace — full overwrite;
• skip — skip existing.

How Large Files Are Handled

Importing 50,000 rows in one HTTP request is not feasible. We use agents:

// Step 1: upload file, create job $job = ImportJobTable::add([ 'FILE_PATH' => $uploadedPath, 'MAPPING_ID' => $mappingId, 'STATUS' => 'pending', 'TOTAL' => 0, 'PROCESSED' => 0, ]); // Step 2: agent processes chunks public static function processChunk(int $jobId, int $offset, int $limit = 100): string { $job = ImportJobTable::getById($jobId)->fetch(); $reader = ReaderFactory::create($job['FILE_PATH']); $reader->open($job['FILE_PATH']); // skip offset rows, read limit rows // write, update PROCESSED return "\\Bitrix\\Main\\Agent::executeImporter($jobId, $newOffset);"; } 

The agent runs every minute; progress is visible in the admin panel in real time. Streaming processing is 10x faster than a single-request import.

Writer: Writing to Infoblock

class IblockElementWriter implements WriterInterface { public function write(MappedRow $row): WriteResult { $existing = $this->findByKey($row->getKeyValue()); if ($existing) { $result = \CIBlockElement::Update($existing['ID'], $row->toIblockArray()); } else { $element = new \CIBlockElement(); $result = $element->Add($row->toIblockArray()); } return new WriteResult($result !== false, $existing ? 'updated' : 'created'); } } 

Similar Writers: CrmLeadWriter, SaleOrderWriter, UserWriter.

Data Validation and Error Handling

Before writing, each row is validated. Rules are set in configuration:

Rows with errors are logged in b_vendor_importer_error. After import, a report and CSV with problematic rows are available.

Notifications and Logging

After completion, the module sends an email to the initiator via \Bitrix\Main\Mail\Event::send(): total rows, created/updated/errors, link to the log.

Development Process

1. Format analysis and mapping — we study your data sources, agree on fields.
2. Architecture design — define Reader, Transformer, Writer.
3. Reader development — implement streaming parsers for your formats.
4. Mapping configuration — set field correspondences.
5. Writer implementation — write to infoblocks, CRM, orders.
6. Streaming processing and agents — set up background import.
7. Validation and logging — configure check rules and error log.
8. Administrative interface — create page for launch and monitoring.
9. Testing and load testing — run on real data.
10. Documentation and training — hand over to team.

Why Order a Custom Module?

We are certified 1C-Bitrix specialists with 10+ years of experience. Every module undergoes load testing. You get a guarantee of stable operation and post-implementation support. According to official 1C-Bitrix documentation, standard tools do not cover custom formats and complex update logic. Our module delivers significant savings compared to manual processing. For a consultation and preliminary assessment, contact us — we will prepare a proposal tailored to your needs.

Development Timeline

Total: from 13 working days. Complex formats or transformations — evaluated separately. Get a consultation and preliminary assessment of your project, write to us. Order a module that solves your problem.