UMI.CMS and 1C Through Eofferix: Catalog, external

This guide covers the 1C -> Eofferix -> UMI.CMS catalog flow. Use it when 1C exports products, sections, trade offers, prices, stock, images, and properties, and reliable product-and-offer matching is required for orders.

If the UMI.CMS module is not installed yet, start with Importing a Catalog to UMI.CMS With Eofferix. This page focuses only on the 1C scenario: which identifiers to select, how to split full exchange and changes, and what to check before a test order.

What Eofferix Does

Eofferix receives the catalog from 1C, reads import.xml, offers.xml, and image archives, applies the snapshot rules, and sends prepared items to the installed UMI.CMS module. The module writes the result to the site catalog.

Eofferix does not support order exchange. Orders must be sent to 1C through the native UMI.CMS and 1C order integration. Eofferix must load the catalog first so UMI.CMS can later pass recognizable product and selected trade-offer identifiers to 1C.

Expected Result

After setup, a product from 1C should be found on the site by the selected key, each trade offer should be attached to its product, and variant price, stock, and properties should be stored on the trade offer. A repeated import without data changes should quickly skip unchanged items.

For orders, product names and storefront articles are not enough. UMI.CMS needs the native 1C identifiers for both the product and the selected trade offer. Without them, 1C can receive an order without a known catalog item or create a duplicate item.

Minimal Setup Order

Connect the UMI.CMS site and wait for a successful connection check.
Select the UMI.CMS data type for products and the data type for sections.
For 1C products, select external_id in product identification fields.
For trade offers, select offer external_id in offer identification fields.
In the snapshot, mark section, product, and trade-offer roles.
Bind variant price, stock, and properties inside the trade-offer role.
Run a small test export before running the full profile.

Identification Fields

Field	Use it for	Important
Product `external_id`	Main product key from 1C.	Usually this is what UMI.CMS needs to match the product in an order.
Trade-offer `external_id`	Specific variant key: size, color, pack, or another option.	Product and offer identifiers are different values. Do not mix them.
Product article `artikul`	A regular product field in UMI.CMS data templates.	Use it for matching only when the business intentionally matches by product article.
Offer article `vendor_code`	System trade-offer article in UMI.CMS.	This is the visible offer article. It does not replace `external_id` for 1C orders.
Eofferix service key `guid`	Internal matching inside Eofferix.	It is not a UMI.CMS and 1C order-exchange field.
UMI page ID `id`	Internal ID inside one UMI.CMS installation.	Use only for reverse loading back to the same site.

Main Search Rule

Eofferix searches existing products, sections, and trade offers only by the fields selected in the template. If external_id is selected, the search uses external_id. If an article is selected, the search uses that article. The service must not silently switch to vendor_code, sku, or another field.

If no section identification field is selected, section matching should use the full transformed section path. This keeps branches like Electronics / Other and Sensors / Other separate.

Snapshot Roles

In the full catalog, mark three roles: section, product, and trade offer. Bind the product identifier to product external_id. Bind the offer identifier to trade-offer external_id.

Variables and transformations can prepare keys before export. Check the transformed value, not the raw XML value.

Product and trade-offer roles in a 1C XML snapshot

Configure Trade Offer-To-Product Binding

A trade offer is not the first product in the list and not a copy of the parent product. It is a separate product variant with its own identifier, price, stock, and properties. If offers are nested inside products, mark them with the trade-offer role. If products and offers arrive separately in import.xml and offers.xml, configure the key that links an offer to a product.

1C sends its own product key in the productGuid#offerGuid form. For the integration, use it for export to external_id (the trade-offer key) and to product_external_id (the key that links the trade offer to the product).

Offer Properties, Prices, And Stock

Product properties go to the product, section properties go to the section, and trade-offer properties go to the data object of the specific offer. Use the offer fields returned by the connected UMI.CMS site. Variant size, color, offer price, offer stock, and vendor_code must not be written to the parent product by accident.

Binding a source value to a UMI.CMS field

Full Catalog And Changes

For 1C projects, use two profiles when possible. The first profile receives the full catalog and may own the site catalog. The second profile receives only changes and should not take ownership away from the full profile.

Setting	Full catalog	Changes exchange
Source	A file or exchange containing the whole current catalog.	A separate 1C export with only changed objects.
Scenario	Full source synchronization.	Careful update without full cleanup.
Profile ownership	Enabled when this profile owns the catalog.	Disabled when the full profile must remain the owner.
Deleting missing items	Only inside this source and with a deletion protection limit.	Usually disabled. Missing from a changes file does not mean deleted.
Zero stock	May follow the full catalog rules.	Apply only to objects present in the current exchange.
Images	Delete missing images only when the source is complete.	Keep existing images when they are simply absent from the changes file.

Two Sources

Create or keep the source for the full 1C catalog.
Create a second source for changes.
Configure 1C to send full export to the first source and changes to the second.
Copy the full profile so data types, roles, and field bindings stay the same.
Switch the copied profile to the changes source.
Disable settings that make the changes profile own the catalog or run full cleanup.
Test one small change: price, stock, one property, or one image.

Cleanup And Images

Deletion should be enabled only when the source is a complete source of truth. In a partial 1C file, a missing product or image usually means not changed, not deleted.

Do not enable full cleanup in the changes profile. If the source sends only changed products, full cleanup can treat the rest of the catalog as missing from the source.

Force deletion of images missing from export only for a full catalog with a guaranteed complete image set. If an image archive temporarily does not arrive, that setting can remove images already uploaded to the site.

Advanced image settings for UMI.CMS import

A regular test export does not run missing-object cleanup. If Test as full run is enabled, full-run rules apply to the limited sample: cleanup can affect missing products, offers, sections, and images within the selected scope.

The Eofferix module for UMI.CMS does not delete properties, characteristics, or dictionary values. It can match an existing property or value, or create a missing one, but it does not delete or unlink created properties and values during subsequent runs. Rules for missing products, offers, sections, and images work separately.

Importing into UMI.CMS does not support reverting to the state of a previous run and does not create rollback points. A stopped run can be continued only when a confirmed resume point exists; otherwise fix the cause and start a regular new import. Back up the site and database before a full run with deletion rules.

Repeated Import And Cost

After the first import, repeated runs should find existing products and offers. If transformed data did not change, the item should pass as the cheaper UMI.CMS · unchanged item action. If every run creates a new catalog again, check identification fields and whether external_id was saved.

Check In UMI.CMS

Open a product in UMI.CMS admin.
Check that the product 1C identifier is filled.
Open trade offers and make sure offers are created inside the product.
Check the selected offer external_id, vendor_code, price, and stock.
Check that variant properties are stored on the offer, not on the parent product.
Open product images and make sure files actually appeared in UMI.CMS admin.

Test Order Check

Place an order for a specific trade offer on the test site.
Send the order to 1C through the native UMI.CMS and 1C order integration.
In 1C, confirm that the order matched an existing product and the selected variant.
If 1C creates a new product or receives an order without item, return to product and offer identifiers.

If The Order Does Not Match

Symptom	What to check
Order has no catalog item	Whether product and selected offer `external_id` are filled in UMI.CMS.
1C creates a new product	Which external key UMI.CMS sent and whether that key exists in 1C.
Order uses product without variant	Whether trade offers exist and the storefront selects a specific offer.
Stock exists on product but not on offer	Whether offer stock was written to the parent product field.
Repeated import creates duplicates	Whether selected identification fields match the values actually loaded to UMI.CMS.
Images disappeared after exchange	Whether forced image deletion is enabled in a partial profile.

Final Checklist

The full profile loads sections, products, trade offers, prices, stock, properties, and images.
Each product has its own external_id.
Each trade offer has its own external_id.
vendor_code is used as the offer article, but does not replace the 1C identifier.
Offer properties are stored on the specific trade offer, not on the parent product.
The changes profile does not run full cleanup and does not take catalog ownership.
A repeated import without changes is billed as unchanged items.
A test order in 1C matches an existing product and the selected offer.