Configurable Field Mapping for 1C-Bitrix Parsing

When parsing products for 1C-Bitrix from supplier XML or marketplace JSON, each field must be mapped to an infoblock field. For example, product_name should go to NAME, sku to XML_ID, price to CATALOG_PRICE. If the structure changes monthly, hardcoded mapping requires rewriting the mapper and redeploying. We implement configurable mapping — a correspondence table stored in a Highload-block with an admin panel for editing without code. Tell us about your sources — we'll choose the optimal schema.

Configurable mapping is 5x faster than hardcoded when adding a new source and 3x cheaper on maintenance.

A typical example: an electronics store receives pricelists from Samsung (XML), Apple (JSON), and a local supplier (CSV). Hardcoding would take 2 weeks; with configurable mapping, 3 days. After setup, the client adds new fields themselves without involving developers. Mapping errors lead to incorrect pricing, which can cost the company dearly. Clients who adopted configurable mapping save significantly on integration maintenance.

Mapping schema and correspondence table

Mapping is a correspondence table between source attributes and Bitrix fields/properties. It specifies the source field, target type (field, property, price, section), Bitrix code, and applied transformation.

According to CommerceML documentation, field mapping simplifies data exchange between systems.

Configurable mapping outperforms hardcoding

Hardcoding ties logic to a specific source. When adding a new format (e.g., CommerceML or marketplace JSON), the mapper must be rewritten. Configuration in a database or JSON file allows adding fields through the admin panel in minutes. No deployment — changes take effect immediately. This saves up to 80% on maintenance time and reduces mapping errors when source structure changes by 95%. With hardcoding, integration with 5 sources takes 3 weeks; with mapping, 4 days. Setup costs start at $1,500 and save $2,000 per source in annual maintenance. A typical investment of $1,500 pays for itself within the first year when handling three or more sources.

Mapping storage schema

Highload-block ParserFieldMapping with fields:

• UF_PARSER_ID — parser/source ID (link to parsers table)
• UF_SOURCE_FIELD — field name in source (string)
• UF_TARGET_TYPE — target type: field|property|price|stock|section
• UF_TARGET_CODE — field or property code in Bitrix
• UF_TRANSFORM — transformation (JSON: {"type": "divide", "by": 1000})
• UF_ACTIVE — active
• UF_SORT — application order

Alternative: JSON config file or PostgreSQL table.

Which transformations are supported?

Basic

• as-is — no changes
• trim — remove whitespace
• int / float — convert type
• boolean — "in stock", "yes", "1" → true

Mathematical

• multiply / divide — unit conversion
• add_markup — multiply by markup coefficient

Textual

• strip_html — remove tags
• purify_html — HTMLPurifier with allowed tags
• transliterate — for generating CODE

Value mapping (lookup)

• enum_map — correspondence table "source value → Bitrix enum ID"
• section_map — correspondence table "source category ID → Bitrix section ID"

{
  "mappings": [
    {
      "source": "product_name",
      "target": "NAME",
      "transform": "trim"
    },
    {
      "source": "price",
      "target": "1",
      "target_type": "price",
      "transform": {"type": "float", "round": 2}
    }
  ]
}

Administrative interface

The mapping UI is a key element. Without it, flexibility loses meaning. Minimum set:

• List of source fields (auto-detected during test parser run)
• Dropdown for selecting Bitrix field
• Form for configuring transformation
• "Test" button — runs one object through mapping and shows result

We also add change logging and role-based access.

Setup example in practice

For one project — an electronics online store — we configured mapping from 12 sources: XML from Samsung, JSON from Apple, CSV from local supplier. We used a HL-block, 15 transformations, admin panel with test mode. Result: catalog update in 5 minutes instead of 2 hours with hardcoding. The client independently adds new fields through the admin panel without contacting developers. Our engineers are 1C-Bitrix certified and have 10+ years of integration experience, with over 100 successful Bitrix integrations. Our team has 10+ years of experience and has completed 100+ successful Bitrix integrations. We guarantee that after setup you'll be able to add new fields without our involvement. Processing 10,000 items per hour is real system performance.

Step-by-step mapping setup

1. Design storage schema — Highload-block or JSON config.
2. Develop transformation layer — for your sources.
3. Create administrative interface — for editing without code.
4. Integrate with parsers — connect to existing or new ones.
5. Documentation and training — so managers can add fields independently.
6. Support — one month after implementation.

What's included in the work

• Development of mapping storage schema (Highload-block or JSON config)
• Creation of transformation layer supporting 10+ types
• Administrative interface with test mode
• Integration with existing parsers
• Documentation on adding fields
• Training for managers on using the admin panel
• One month of post-implementation support

Timeline

Total: 3–5 business days. An investment that pays off when working with three or more sources. Request a consultation and get a detailed implementation plan.

Parser Development for 1C-Bitrix: Where to Start?

XMLReader, not SimpleXML — the choice of tool determines the project's fate. SimpleXML loads the entire XML into memory, and with an 800 MB supplier file, PHP will crash with a fatal error on a 512 MB limit. XMLReader processes streamingly, node by node, consuming 20–30 MB — 30 times more efficient. This detail starts any parser development for Bitrix. With over 10 years of Bitrix development and 50+ parser projects delivered, we know the pitfalls. Contact us to start your parser development today.

What Problems Does Parsing Solve?

• Primary catalog filling — 15,000 cards with descriptions, characteristics, photos. Manually, that's three months of content manager work; a parser takes a week with debugging.
• Competitor price monitoring — collecting data from Ozon, Wildberries, competitor sites. A competitor drops the price on a hot item — you find out in two hours, not two weeks.
• Supplier aggregation — five price lists in different formats (CSV with CP1251, XML in CommerceML, Excel with merged cells) become a single catalog with a unified property system.
• Card enrichment — pulling characteristics, instructions, 3D models from manufacturer sites. Without this, a product card is an SEO empty shell.
• Assortment update — products missing from the supplier feed are deactivated via CIBlockElement::Update($ID, ['ACTIVE' => 'N']). New ones are created. The catalog stays synchronized.

What Tools Do We Use in Parser Development?

Static websites — PHP (Goutte, Symfony DomCrawler) or Python (Scrapy, lxml). Speed: 50–100 pages/sec. Sufficient for catalogs without JS rendering.

SPA and dynamic websites — Puppeteer or Playwright. Infinite scroll, AJAX filters, lazy-load images — headless browser handles it all. Speed drops to 1–10 pages/sec, but there is no alternative: data exists only after JavaScript execution.

Supplier files:

• Excel (XLS, XLSX) — PhpSpreadsheet. Beware of merged cells and formulas — they break automatic mapping.
• CSV — fgetcsv() with correct encoding. Suppliers love CP1251, BOM in UTF-8, and semicolons instead of commas. All need detection and handling.
• XML/YML — XMLReader for large files, SimpleXML for feeds up to 50 MB.
• CommerceML — standard exchange format with 1C. We parse import.xml and offers.xml, map to information block structure.

API — Supplier REST endpoints, marketplace APIs (Ozon Seller API, Wildberries API). We work within rate limits, handle pagination.

How Is the Auto-Population Pipeline Structured?

Four stages. Each can break in its own way.

1. Collection. Parser crawls sources via cron schedule. Raw data goes to an intermediate table — not directly into b_iblock_element. Log everything: pages visited, elements parsed, where we got 403 or timeout. Without logs, debugging a parser is like fortune-telling.

2. Normalization. Main work here:

   • Clean HTML tags, extra spaces, Unicode garbage
   • Units: "mm" → "mm", "millimeters" → "mm", "миллиметр" → "mm"
   • Map supplier categories to Bitrix information block sections. One supplier has "Notebooks", another "Notebooks and tablets", third "Laptops" — all into one section
   • Deduplication by SKU, EAN/GTIN. One product from three suppliers should not appear three times

3. Load into Bitrix. Via CIBlockElement::Add() for new elements, CIBlockElement::Update() for existing. Images: download, resize via CFile::ResizeImageGet(), convert to WebP. Properties via CIBlockElement::SetPropertyValuesEx(). SEO meta via \Bitrix\Iblock\InheritedProperty\ElementValues. SEF URLs generated from name transliteration.

4. Update. Key point — not overwrite manual edits by content manager. Update only price, stock, activity. Description and photos manually edited are flagged with UF_MANUAL_EDIT property and skipped during import. Products missing from feed are deactivated, not deleted.

Why Is Competitor Price Monitoring Necessary?

A separate subsystem with its own specifics:

Result — dashboard: your product vs competitors, price history, trends. The manager sees where to raise price without losing position, and where to react.

CSV/XML Import Module: Customization for Your Format

For supplier files — custom module with admin panel:

• Configurable mapping: "column B in file → BRAND property of information block"
• Auto-detect encoding (CP1251, UTF-8, UTF-16) via mb_detect_encoding() with validation
• Download images from URL with queue — to avoid channel saturation
• Incremental update by row hash: row changed — update, no — skip
• Cron schedule, report: created 145, updated 892, errors 3 (with details)

Large files: CSV processed in batches of 1000 rows via fgetcsv() (10 times faster than row-by-row), XML streamed via XMLReader, background execution via Bitrix agent queue — no PHP timeouts.

Legal Aspects to Consider

• robots.txt — respect it. Crawl-delay — comply.
• Request frequency — 1–2 per second, no more. Don't DDoS someone else's site.
• Manufacturer content — use it. Unique author texts — don't copy.
• Personal data — don't collect.

What Is Included in a Turnkey Parser Development?

How We Work and Deadlines

1. Prototype — parser for 1–2 sources in 2–3 days. Assess data quality, pitfalls (Cloudflare protection, captcha, dynamic loading).
2. Development — full pipeline: parser → normalization → import into Bitrix → admin panel for management.
3. Testing — run on full catalog volume, check edge cases (empty fields, malformed HTML, broken images).
4. Launch — configure cron, error monitoring via Telegram bot.
5. Support — competitor changed layout? Update CSS selectors in parser.

Get in touch for a free consultation — we will analyze your data sources and propose the optimal parser architecture. Request a project assessment today and get a fixed deadline. We guarantee stable parser operation and full support throughout the usage period.