The Eofferix module is installed on the UMI.CMS site and receives the prepared catalog from the service: sections, products, trade offers, prices, stock, images, files, and source properties. The service can collect source files from email, file-sharing services, FTP, 1C, direct links, and password-protected supplier portals, then transform the data by configured rules and write it to the UMI.CMS catalog structure.
What You Need
- Access to the site files through SSH, SFTP, FTP, or the hosting file manager.
- Administrator access to the UMI.CMS backend.
- The installer archive
eofferix-umi-install.zipor, if the installer is blocked, the module archiveeofferix-umi-cms-module.zip.
Step 1. Install The UMI.CMS Module
- Sign in to the UMI.CMS admin panel in the same browser.
- Unpack
eofferix-umi-install.zip. - Upload
eofferix-umi-installto the site root next toindex.php. - Open
https://site.com/eofferix-umi-install/install.php. - Wait for the success message.
- Delete the installer folder from the site.
Step 2. Connect The Eofferix Profile
Open the profile, choose the UMI.CMS template, enter the site URL and administrator credentials, then click Check connection. After a successful check, Eofferix loads the site data types, fields, and root sections.

Step 3. Choose Data Types, Root Section, And Identification Fields
In the UMI.CMS element identification block, choose the UMI.CMS data types for products and sections, the import root section, and the fields Eofferix will use to find existing sections, products, and trade offers.

Identification fields define how the service matches the source with the existing UMI.CMS catalog. Choose the stable key used by your source: external_id, article/SKU, id, a combination such as product name plus article, or another reliable field.
How AND and OR work. Separate identification chips are joined with AND. Inside one chip, the “or …” button adds alternative fields that are tried from left to right. For example: (SKU OR External code OR Barcode) AND Supplier AND (Brand OR Manufacturer).
Eofferix stops at the first complete combination that finds existing objects. If that combination finds several objects, the complete result set is passed to the selected duplicate policy; matching does not fall through to the next alternative. Every required group must have a value. Users may choose any available fields, and extra alternatives do not consume extra credits.
The root section defines where new source sections are created. If a specific section is selected, new catalog branches are created inside it. If the site root is selected, sections are created from the root.

For 1C, it is best to use external_id for both products and trade offers: these identifiers are always unique.
For sections, choose a separate identification field mainly when sections come as a separate block in the source. If the section is written inside the product as a full path or a simple name, separate section matching is usually unnecessary: use the transformed section path.
Step 4. Choose The Import Scenario
In the profile settings you can choose a ready-made exchange scenario. It defines what Eofferix does with new products, matched products, trade offers, and objects that are no longer present in the source.
| Scenario | Use when |
|---|---|
| Safe sync | Eofferix creates new products and updates matched ones, but does not delete missing objects automatically. It also does not bind products and trade offers to a specific profile. |
| Full source synchronization | The profile binds all imported products and trade offers to itself. A repeated profile run deletes products and trade offers that disappeared from the source and adds new ones that appeared with the latest update. |
| Update matched | Use this scenario when you need to change prices, stock, names, or properties only for already matched products and trade offers. New products are not created. |
| Add only new | Use it when you need to add missing products and trade offers without changing what is already on the site. |
| Full catalog overwrite | This scenario removes missing products, offers, and sections within the selected scope, then creates or updates objects from the current source. Properties and dictionary values are retained. |
You can also configure exchange behavior manually for products, trade offers, and sections.
Step 5. Mark Snapshot Roles
Mark which XML node is a product, section, and trade offer. If offers are nested inside products, Eofferix reads the relation from the XML structure. If offers come as a separate block, bind the service field product_external_id — Offer-to-product binding.
Step 6. Bind Product, Section, And Offer Fields
Product properties must be written to the selected product type. Section properties must be written to the section type. Trade-offer properties must be written to the specific offer data object, using the offer fields returned by the connected UMI.CMS site.
Before writing a value to the CMS, you can prepare it: clean text, normalize a number or date, compose a value from several nodes, map through a dictionary, or add export conditions. Useful examples: value transformations, field export conditions, dictionary value mapping, and multiple values in one field.
Step 7. Configure Images And Files
XML, CSV, Excel, and other sources usually contain image URLs, paths, or filenames rather than image binaries. Eofferix downloads images from URLs, extracts them from 1C archives or uploaded companion archives and files, then sends prepared files to UMI.CMS. In the advanced image-field settings, Eofferix can save the file on the service, convert the format, resize large images to the selected width and height, and set JPEG/WEBP quality. These options strongly affect file size and page loading speed.
The same settings allow a watermark: upload a PNG/WEBP file, choose its position, opacity, and maximum size. For galleries, you can configure the image separator, image range, and skipping repeated uploads when the file has not changed.

Step 8. Run A Test Export
Use Test export for validation. It sends a limited sample of 5 products to UMI.CMS and does not delete missing elements, sections, or other objects.

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.
Costs And Unchanged Items
Before launch, Eofferix calculates the estimated cost. During repeated imports, unchanged products and trade offers should go through the cheaper UMI.CMS · unchanged element action. This keeps a regular exchange from costing like a full catalog rebuild.
If the catalog has already been imported but the next run again looks like thousands of new objects are being created, check product and offer identification fields, the import scenario, and profile binding.
If you need to force a rewrite of matched catalog items, clear the Do not update the UMI item when data has not changed checkbox in Advanced import settings. The service will stop fast-skipping unchanged items and will send a full update for them; such a run may take longer and cost more.
