UMI.CMS and 1C Integration Through Eofferix

This guide explains the practical 1C catalog workflow: 1C -> Eofferix -> UMI.CMS. Orders still go through the native UMI.CMS -> 1C path, so Eofferix must load the catalog and identifiers correctly before orders are created.

How The Chain Works

1C sends catalog files to Eofferix. Eofferix assembles and transforms the catalog, then the UMI.CMS module writes products, sections, trade offers, prices, stock, images, files, and properties to the site.

What Orders Need

UMI.CMS must have native 1C identifiers on products and offers. For 1C projects, use product external_id and trade-offer external_id. Without them, an order can reach 1C without a recognizable catalog item.

UMI.CMS identification fields for products, offers, and sections — The screenshot was captured from the real Eofferix interface using a demo profile and test names.

External ID, GUID, Page ID, And Offer Article

Field	Meaning	Use for 1C orders
`external_id`	Native 1C identifier for a product or offer.	Usually yes.
Eofferix `guid`	Internal Eofferix matching key.	No.
UMI page `id`	Internal ID inside one UMI.CMS installation.	Only for reverse import to the same site.
Offer article `vendor_code`	System article field of a trade offer.	Can be used for matching if selected, but it does not replace `external_id`.

Snapshot Roles

Mark product, section, and trade-offer nodes in the snapshot. Prices, stock, size, color, offer article, and offer identifiers must stay inside the trade-offer role when they describe a specific variant.

Product and trade-offer roles in a 1C XML snapshot — The screenshot was captured from the real Eofferix interface using a demo profile and test names.

Trade Offer Properties

Offer properties must be written to the offer data object, normally in the trade_offers group. They must not be accidentally written to the parent product.

Full Exchange Profile

The full profile receives the whole 1C catalog and owns the site catalog. It may bind imported elements to itself and may clean up objects that belong to its source, with deletion protection enabled.

Incremental Changes Profile

The changes profile receives only modified products or offers. It should update prices, stock, images, and properties, but normally it should not take catalog ownership from the full profile and should not run full cleanup.

Two 1C Sources

Use one source and profile for the full catalog, and another source and profile for changes. Copy settings from the full profile, then disable ownership and full cleanup in the changes profile.

Images And Partial Files

If a changes file does not include images, this usually means images were not changed. Do not force deletion of existing images unless the source is a complete image authority.

Advanced image settings for UMI.CMS import — The screenshot was captured from the real Eofferix interface using a demo profile and test names.

Costs And Unchanged Items

After the first full import, repeated imports should find existing products and offers. Unchanged items should pass through the cheaper unchanged-element action instead of being created again.

Before A Test Order

Open a product in UMI.CMS admin.
Check product external_id.
Check that trade offers exist.
Check the selected offer external_id, price, stock, and vendor_code.
Place a test order for a specific offer.
Confirm that 1C matched an existing item.

If 1C Receives An Order Without Item

Check missing product or offer external_id, missing trade offers, stock written to the product instead of offers, wrong matching field in the template, and accidental cleanup of offers.

Checklist

Products and offers have external_id.
Offer fields are inside trade_offers.
The full profile owns the catalog.
The changes profile does not take ownership.
Cleanup is disabled or safely limited for changes.