Automated Product Description Filling in 1C-Bitrix

You launched an online store on 1C-Bitrix. Thousands of products, but descriptions are empty or copied from a price list. Content managers spend hours searching and formatting — yet descriptions still differ in style and quality. Mistakes during copying, duplicates, outdated information.

The solution is automated population from external sources. Our solution for automatic description population in 1C-Bitrix uses product description parsing from donor sites, Icecat integration, and AI description generation. Recently, a client approached us with a catalog of 10,000 electronics products. Descriptions existed for only 20%; the rest were empty. After implementation, coverage reached 95% in two weeks. Our fallback approach ensures 3x higher stability than single-source parsing.

We design a system that collects descriptions on its own without overwriting manual edits, using a chain of sources with fallback. Integration with any supplier through a unified provider interface. We use Bitrix event handlers to trigger auto-population. Our catalog automation for 1C-Bitrix commercial catalog integrates with 1C UT exchange for data synchronization. Get a consultation for your project — we will assess the scope of work free of charge.

Implementation cost starts from 90,000 rubles, with annual savings up to 500,000 rubles — a 5x return on investment. AI generates descriptions 10x faster than manual writing, reducing costs by 60% and saving 80% of managers' time.

What Triggers Description Population?

Auto-population launches in three situations:

• When a new product is added — handling the OnAfterIBlockElementAdd event. The product is just created, fields are empty — the system goes for a description to the sources.
• On a schedule for unfilled items — a cron job finds elements with empty DETAIL_TEXT and puts them in the queue.
• On a manual request — a manager clicks 'Get Description' for a specific product in the administrative section.

How to Protect Manual Edits?

The key element is the DESCRIPTION_LOCKED property (type S, values Y/N). When a manager manually edits a description in the administrative section:

• DESCRIPTION_LOCKED = Y is set
• The auto-population system skips this element

We set the flag via the OnBeforeIBlockElementUpdate handler — we check if DETAIL_TEXT changed relative to the previous value. If yes and the change did not come from the auto-population system, we set the flag.

In the Bitrix Framework documentation, the recommended approach to change control via events is described.

Source Chain with Fallback

The description is searched sequentially: if the first source does not yield a result, we try the next one:

1. Manufacturer API by VENDOR_CODE
2. Icecat database by EAN/barcode
3. Manufacturer website parsing
4. AI generation by name and characteristics (last resort)

Each source implements a unified interface:

interface DescriptionProviderInterface {
    public function getDescription(string $sku): ?string;
}

The orchestrator iterates through providers in priority order. Additionally, we cache responses — if a provider fails, we use the last successful result.

Queue and Prioritization Importance

Not all products are equally important. Queue priority:

• High: products with active orders or views (data from b_sale_order_item, b_stat_session)
• Medium: new products without description
• Low: old products not viewed for more than 30 days

Implemented via a priority field in the queue table; the worker picks tasks ORDER BY priority DESC. This ensures the most important items get descriptions first.

Process

Common mistakes in auto-population:

• Overwriting manual edits: our solution with the DESCRIPTION_LOCKED flag eliminates this problem.
• Unstable sources: fallback and response caching ensure fault tolerance.
• Source mixing: priority and meta-information preservation allow tracing the description's origin.

Deliverables

• Fully implemented auto-population system with queue and priorities
• Connected sources (up to 4 in the base version)
• Manual edit protection mechanism
• Architecture and operation documentation
• Manager training (1 hour)
• Technical support for 1 month after launch

Economic Effect

For a catalog of 10,000 products, the annual savings amount to up to 500,000 rubles. Replacing manual labor with automation reduces costs by 60%. The project pays for itself in 2–3 months.

We guarantee that after implementation, managers spend 80% less time on product descriptions. Certified specialists with over 10 years of experience. Contact us to discuss your catalog and get an estimate.

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.