Feed Generation Module for 1C-Bitrix: Automating Export

A marketer discovers that the product feed for Yandex.Market updates once a day through a manual export, while prices in the catalog change several times a day due to imports from 1C. The result: marketplaces show outdated prices — customers click, see a different price, and leave. The standard Bitrix export module (catalog.export) handles basic cases, but encounters limitations with non-standard requirements (multiple warehouses, custom properties, regional conditions). On a project with a catalog of 50,000 products, the price discrepancy hit 15%, causing a 30% abandonment rate. Only after implementing a custom module with incremental updates was the problem resolved. Our experience spans over 30 successful projects. We guarantee correct stock handling and no duplicates. Contact us for a module tailored to your specifics.

Why Standard Export Falls Short for Feed Generation

The standard catalog.export module does not support:

• Multiple warehouses with separate stock levels.
• Custom properties for different channels (e.g., condition for Google Merchant).
• Regional prices and discounts.
• Incremental updates — full feed regeneration each time, which on 50,000 products takes 5–10 minutes and loads the server.

These limitations lead to manual exports, errors, and outdated data. A custom module solves it all.

How the Feed Generation Module Works

The core task is to make generation fast, flexible, and automatic. The module is built around three components: a feed template engine, an update scheduler, and a format registry.

The format registry stores configurations for each channel: Yandex.Market (YML), Google Merchant (XML/CSV), VK, Avito, Ozon, custom client formats. Each format is described by a PHP class implementing the FeedFormatInterface:

interface FeedFormatInterface { public function getHeader(): string; public function renderOffer(array $element, array $prices): string; public function getFooter(): string; public function getMimeType(): string; } 

This allows adding new formats without touching the generator core. More about YML format on Wikipedia.

The generator works in a streaming mode: data is read from b_iblock_element, b_catalog_price, b_catalog_product via DataManager::getList with pagination (batches of 500 elements) and immediately written to a file using fwrite. Generating a feed of 50,000 products does not require 512 MB of RAM. The final file is atomically replaced (rename), so a crawler never receives a partially written document.

How Price and Stock Resolvers Work

This is the most variable part. One project needs prices for unregistered users, another for special prices with promotions, yet another for the minimum price across all warehouses.

The module implements a price resolver — a strategy that selects the final price based on a set of rules:

$priceResolver = new PriceResolver([ new DiscountRule($userId), // apply discounts via Sale\Discount new RegionPriceRule($regionCode), // regional markup new MinPriceRule(), // take minimum among price types ]); $finalPrice = $priceResolver->resolve($productId); 

Stock by warehouses. For Ozon and other platforms, you need to specify stocks for specific warehouses (b_catalog_store_product). The module aggregates stocks from multiple warehouses (up to 50), applies reserves from b_sale_basket, and outputs the correct available quantity.

Product filtering. Through the module interface, you define conditions: only products with non-zero stock, specific sections, exclude by property CML2_EXPORT = N. Conditions are compiled into a filter for CIBlockElement::GetList.

What Is Incremental Update?

Full regeneration of a feed with 50,000 items takes 3–5 minutes. For frequent price changes, this is unacceptable. The module supports incremental mode: via the OnAfterCatalogPriceUpdate event, changed products are recorded, and an agent regenerates only their lines in the feed every 15 minutes using a partial update (temporary file and patching). This update is 10 times faster than full regeneration. The event is described in the Bitrix documentation.

How Monitoring Helps Module Operation

The module maintains a table myvendor_feed_log with generation history: start/end time, element count, file size, errors. The admin interface shows a dashboard: when each feed was last updated, how many products were exported, which were filtered out and why. This enables quick detection of data or configuration issues.

Development Process

1. Audit of current catalog and feed requirements.
2. Architecture design (resolvers, formats, caching).
3. Module development and integration on your project.
4. Configuration of agents and scheduler for automatic generation.
5. Testing on real data and adjustments.
6. Documentation handover and admin training.
7. 1-month warranty support.

What's Included in the Deliverable

• Full module source code with installation instructions.
• Configuration and integration of all required feed formats (up to 5 in standard package).
• Price resolver and stock logic tailored to your catalog.
• Incremental update mechanism with agent setup.
• Monitoring dashboard and logging system.
• Administrator training (2 sessions) and written documentation.
• 1-month priority support after launch.

Comparison: Standard vs. Custom Module

Timeline

Timelines can be adjusted after analyzing your catalog. For an accurate estimate, contact us for a consultation on your project. The trade catalog configuration (prices, warehouse structure, presence of SKUs) must be finalized before development begins. Typical investment starts at $3,000 and pays back within 2 months through reduced abandonment and manual work.