Two-Way Catalog Synchronization with 1C

Imagine: a manager updated a price in 1C, but the old price lingers on the site for three days. Or a product is discontinued in the accounting system but remains orderable online. Two-way catalog sync with 1C is not just import and export. It's designing a rule system that resolves data conflicts when information changes in both systems simultaneously. Without a clear definition of the source of truth, synchronization turns into chaos: data gets overwritten, duplicates appear, orders are lost.

A typical scenario: price and stock are changed in 1C, while the description is edited on the site. If the exchange is set up as one-way import, the description may be overwritten. Our approach is two-way exchange with field-level master systems. We design the logic so that the site and 1C remain consistent without manual intervention.

Defining Sources of Truth

The first step is to document for each field which system is the master:

How Conflicts Are Resolved During Synchronization

Conflict: the active_site field was set to false by a site operator (unpublished), but the next export from 1C contains active = true. According to the table above, 1C is the master for active_1c, but active_site remains untouched. Result: active_1c = true, active_site = false → product is not displayed. The site operator retains control. For each field, we define a master system and merge rule. This ensures data integrity and prevents information loss.

Database Schema

CREATE TABLE products (
    id              BIGSERIAL PRIMARY KEY,
    onec_guid       UUID UNIQUE,           -- 1C identifier
    sku             TEXT,

    -- Fields from 1C (overwritten on each sync)
    name_1c         TEXT,
    price_1c        NUMERIC(12,2),
    stock_1c        INTEGER,
    category_guid   UUID,
    active_1c       BOOLEAN DEFAULT true,

    -- Site fields (not overwritten by sync)
    description     TEXT,
    meta_title      TEXT,
    meta_description TEXT,
    images          JSONB,
    active_site     BOOLEAN DEFAULT true,

    -- Sync metadata
    last_sync_1c    TIMESTAMPTZ,
    sync_hash_1c    CHAR(64)              -- hash of data from 1C for change detection
);

-- Final status: product is active only if active in both 1C and site
CREATE VIEW products_active AS
SELECT * FROM products WHERE active_1c = true AND active_site = true;

Synchronization Algorithm from 1C to Site

class OnecToSiteSyncService
{
    public function sync(CommerceMLData $data): SyncResult
    {
        $result = new SyncResult();

        foreach ($data->products as $onecProduct) {
            $syncHash = $this->computeHash($onecProduct);

            $product = Product::firstOrNew(['onec_guid' => $onecProduct->guid]);

            // Skip if data hasn't changed
            if ($product->exists && $product->sync_hash_1c === $syncHash) {
                $result->skipped++;
                continue;
            }

            // Update ONLY fields from 1C (do not touch description, images, etc.)
            $product->fill([
                'sku'          => $onecProduct->sku,
                'name_1c'      => $onecProduct->name,
                'price_1c'     => $onecProduct->price,
                'stock_1c'     => $onecProduct->stock,
                'category_guid'=> $onecProduct->categoryGuid,
                'active_1c'    => $onecProduct->active,
                'last_sync_1c' => now(),
                'sync_hash_1c' => $syncHash,
            ]);

            $product->save();
            $result->updated++;
        }

        // Products no longer exported by 1C are deactivated
        $syncedGuids = $data->products->pluck('guid');
        Product::whereNotIn('onec_guid', $syncedGuids)
               ->update(['active_1c' => false]);

        return $result;
    }
}

Synchronization Site to 1C

The site sends to 1C only what has changed on the site and matters to 1C: new orders, returns, payment notifications.

class SiteToOnecSyncService
{
    public function getUnsyncedOrders(): Collection
    {
        return Order::where('sent_to_1c', false)
                    ->where('status', '!=', 'draft')
                    ->with(['items.product', 'customer'])
                    ->get();
    }
}

Why Choosing the Right Exchange Format Matters

CommerceML is the industry standard for integration with 1C, but REST API gives more control. Comparison:

We choose the approach for the specific task. For small businesses, CommerceML is often sufficient; for large catalogs with high load, REST API is preferred.

Monitoring Synchronization

-- Last sync statuses
SELECT
    source,
    COUNT(*) FILTER (WHERE status = 'success') AS success,
    COUNT(*) FILTER (WHERE status = 'error')   AS errors,
    MAX(finished_at) AS last_run,
    AVG(EXTRACT(EPOCH FROM (finished_at - started_at))) AS avg_duration_sec
FROM sync_logs
WHERE started_at > NOW() - INTERVAL '7 days'
GROUP BY source;

How Often Should Synchronization Occur?

The interval depends on change intensity and load. For an online store with 10,000 products, it's optimal to update prices and stock every 15-30 minutes. For a large marketplace (100,000+ items) — every 5 minutes during peak hours and less frequently at night. We always set up an adjustable schedule with manual trigger capability.

Typical Mistakes When Setting Up Synchronization

• Lack of data hashing: each export overwrites all fields even if data hasn't changed. Solution: store the last sync hash and compare.
• Ignoring activity status: if a product is unavailable in either system, it still appears on the site. Use AND logic between active_1c and active_site.
• Incorrect processing order: import from 1C first, then export orders — otherwise collisions may occur. Maintain sequence.

What's Included in the Work

• Audit of current data schema — identify mismatches and growth points.
• Designing synchronization rules — define sources of truth and conflict resolution logic.
• Implementing the exchange — write sync code using CommerceML or REST API.
• Testing with real data — verify on live configuration, fix errors.
• Documentation and training — provide operation instructions.
• Post-launch support — guarantee stable operation, resolve incidents.

Timeline

Two-way catalog synchronization with 1C, including testing on a real configuration: 14–20 business days. Contact us for an audit of your current sync scheme. Get a consultation on data exchange setup — we will assess the scope of work and propose the optimal solution.

1C:Enterprise Integration: Product, Order, and Stock Exchange

Monday morning. The manager opens the site and sees that the item sold out on Friday is still listed as "in stock". Three customers have already paid for a product that doesn't exist. We encounter this pain regularly: the lack of synchronization between 1C and the online store hurts revenue and reputation. We solve the problem end-to-end — setting up the exchange so that the accounting system and the storefront update synchronously, without data loss, and with consistency guarantees.

1C is the accounting system of most Russian companies. The site is the storefront. They must speak the same language and do so regularly, reliably, and without data loss. Our experience: over 50 successful integrations for clients with catalogs from 500 to 200,000 SKUs.

Why isn't standard CommerceML always sufficient?

CommerceML is a standard exchange protocol supported by 1C:Trade Management, 1C:Integrated Automation, and several other configurations. WooCommerce, Shopify, and other CMS have plugins for CommerceML (e.g., "1C-Bitrix" for their products, separate plugins for WordPress). Flow: 1C initiates exchange → sends a ZIP archive with XML to the site endpoint → site parses and updates the catalog.

CommerceML format is XML with its own schema: КоммерческаяИнформация, Классификатор, Каталог, ПакетПредложений. Categories, products, characteristics, images, prices, stock. The main difficulty: the hierarchy of characteristics in 1C and product attributes on the site do not always match one-to-one. Mapping is needed. For a deep understanding of the protocol, we recommend documentation on Wikipedia — Wikipedia: CommerceML.

How we overcome CommerceML limitations

For non-standard 1C configurations or when CommerceML is not suitable — we write an HTTP service in 1C (built-in since version 8.3) and interact via REST JSON. This gives full control over the data structure and synchronization frequency, but requires development from a 1C programmer.

For enterprise tasks with multiple accounting systems — Message Broker (RabbitMQ, Apache Kafka) as an intermediary. 1C publishes events to a queue, the site subscribes and processes them. Guaranteed delivery, buffering when one side is unavailable.

What we synchronize and how

Catalog (products, categories, attributes). The most voluminous part. Full export on first run, delta updates thereafter. When importing CommerceML: parse XML via PHP SimpleXML or XMLReader (for large files — only XMLReader, otherwise memory limit). Match products by GUID from 1C, which we store in a separate database field. If a product is deleted in 1C, we hide it on the site, not delete (order history may reference it).

Stock and prices. This is a separate ПакетПредложений in CommerceML, updated more often than the catalog. It's critical to do it atomically: not update stock one by one, but in a transaction. Otherwise, during the update, the user may see an inconsistent state. Frequency: once an hour for calm mode, once every 5–15 minutes for active trading.

Orders. Two-way exchange. Site → 1C: new order is sent with items, quantities, prices, customer contact info. 1C → site: order status (paid, assembled, shipped, delivered). For order transfer — either the same CommerceML (Документы block) or a direct REST call when an order is created on the site.

What typical problems do we solve?

Duplicate products. A 1C operator created an item with a typo in the SKU, then fixed it. On the site — two items. Solution: matching by GUID from 1C (not by SKU), GUID is immutable.

Cyrillic in XML and encodings. 1C historically works with Windows-1251. A CommerceML file may come in CP1251, PHP expects UTF-8. mb_convert_encoding() or iconv() in the first lines of the parser — mandatory.

Timeouts during large exports. A catalog of 100,000 items is 50–200MB XML. PHP default execution time of 30s is insufficient. Solution: CLI command (Laravel Artisan or Symfony Console) run via cron, without HTTP timeout. Or chunked processing via XMLReader with partial commits to the database.

Images. 1C can transmit images as Base64 inside XML (bloats file by 1.3x) or as file links. The second option is preferable. Download asynchronously, convert to WebP, place in media library.

Case: auto parts online store, 85,000 SKUs. Synchronization via CommerceML every 30 minutes. Problem: full export took 18 minutes, resulting in a new export starting while the old one was still running. Solution: lock via Redis (SET nx ex), delta export (only changed items in the last 2 hours via filter in 1C), processing via queue with 20 parallel workers. Sync time: 18 minutes → 2.5 minutes, no conflicts.

Comparison of integration methods

CommerceML in typical scenarios is 2-3 times faster than REST for catalog synchronization due to binary packing of XML and compact format. However, if custom exchange logic is required, REST provides full flexibility.

Process and timeline

Audit of 1C configuration (version, configuration type, export capabilities) → data mapping design → development of receiver on site and sender in 1C → testing on real data → schedule setup → monitoring of first exchanges.

Participation of a 1C programmer on the client side is mandatory, or we involve a trusted specialist.

| Scenario | Timeline | | CommerceML, catalog + stock, WooCommerce | 2–4 weeks | | Two-way order exchange | +2–3 weeks | | Custom 1C configuration, REST API | 4–8 weeks | | Enterprise: multiple 1C databases, data bus | 2–4 months |

What's included in the result (deliverables)

• Documentation: mapping scheme, data formats, error handling logic.
• Configured synchronization schedule with execution logs.
• Access to monitoring (Grafana/ELK — by agreement).
• Training for managers: how to run manual exchange, how to read logs.
• Post-launch warranty support — 2 weeks (issue fixing).

Get a consultation

We will evaluate your project within one business day — email us or use the chat. The integration cost is calculated individually based on project complexity. With over 7 years of experience in 1C integrations, we guarantee stable synchronization without surprises.