> ## Documentation Index > Fetch the complete documentation index at: https://docs.omnilinker.pl/llms.txt > Use this file to discover all available pages before exploring further. # Products from your ERP > Take product details from your ERP, choose which fields it fills, and decide how products link and get created. Once the agent has sent your ERP's products, each connection's **Mappings** tab shows a **Products from ‹connection›** card, above the **Products** section. There you decide, for that connection: * who manages product SKUs, * how each product field arrives from the ERP, * what links ERP products to catalog products on its own, and * whether products are created in Catalog automatically. Reading the card needs the **ERP Connections** permission, and the tab itself needs **Reference Data** and **Entity Mappings**. The other permissions are listed [at the end](#permissions). To open the card, go to **ERP Integration** > **Connections**, choose **Details** on the connection and open the **Mappings** tab. Update the ERP Sync agent first. An older agent sends only each product's code, name and whether it is active, so the card has nothing to work with. See [Install the agent](/erp/install-agent). ## When the card is available Until the first complete product list with details has arrived, the card says why it cannot be used yet: * **Waiting for the first product list**, with **Last attempt** and the time, or "ERP Sync hasn't sent a product list yet." * **Update the ERP Sync agent to send product details**: the agent sends products, but not their details. * **The connection is inactive**: activate the connection first. If the connection is still the source of some fields, the card shows the field table even then, so you can give those fields back: set each one to **Off**, or to **Fill when empty** where it is **Always from** this connection. If you have never saved the table, nothing has been applied yet, so give all of those fields back at once, each set to **Off**. If automatic creation is still on, the card shows **Turn off** too. Nothing else on the card can be saved until it is available, and automatic creation creates nothing meanwhile (a run already under way stops at its next batch and counts the rest as skipped). If you leave it on, it resumes with the next product list the agent sends after the card is available again (about once a day, or when you click **Refresh lists**). The agent sends the product list when it has never sent it, about once a day after that, and when you click **Refresh lists**. A change in the ERP reaches Omnilinker with the next list. See [Lists and mappings](/erp/reference-items#when-the-lists-are-read). ## Getting started The card opens with a **Getting started** checklist. Each step shows **Done** or **To do**: 1. **Choose how each product field arrives.** 2. **Choose what links automatically.** 3. **Review suggestions**: "No suggestions to review", or "Review ‹n› suggestions". 4. **Create products**: "No products waiting to be created", "‹n› products can be created in Catalog", or "New products are created automatically". Nothing from the ERP reaches products you already have until you have saved the field table once (step 1). ## Who manages SKUs The card says who sets product SKUs. By default it is **Omnilinker · Catalog**: your team edits SKUs and deletes products in Catalog. If you have the **Choose where product SKUs and fields come from** permission, **Change owner** opens a dialog that lets you make the connection the manager. Before you confirm, **What changes now** counts what the change would do: how many linked products take their SKU from the ERP, how many SKUs change at the next read (with a few examples), how many ERP products are not linked yet (with a link to review them), and when the last complete product list was read. **Make ‹connection› the owner** applies it. When the ERP manages SKUs, a linked product's SKU comes from the ERP's code and the product cannot be deleted in Catalog. Products that are not linked keep working as before. **Change owner** appears only when a choice is possible. See [Products](/catalog/products#who-manages-skus). ## Product fields The **Product fields** table has one row for each of nine fields. For each, you choose how it arrives from this connection: | Mode | What it does | | - | - | | **Off** | Nothing arrives. The product keeps what it has. | | **Fill when empty** | The ERP's value is written only where the product has none. It never replaces a value. | | **Always from ‹connection›** | The ERP's value replaces the product's value whenever it changes in the ERP. | | Field | Arrives in Catalog as | Suggested mode | | - | - | - | | **Name** | The product name: the ERP's full name (its invoice name when it has one, otherwise its name) | **Fill when empty** | | **Invoice name** | **Invoice name** | **Always** | | **Sales VAT** | **Sales VAT** | **Always** | | **Sales unit** | **Sales unit** | **Always** | | **EAN** | **GTIN** | **Fill when empty** | | **Brand** | **Brand**. A brand that does not exist yet is created. | **Fill when empty** | | **Weight** | The product's weight | **Fill when empty** | | **Dimensions** | The product's length, width and height | **Fill when empty** | | **Purchase cost** | The product's purchase price | **Always** | An EAN arrives as a GTIN only when it is a valid GTIN: 8, 12, 13 or 14 digits, the right check digit, and not all zeros. ERPs often hold `0000000000000`, a dash or a made-up number for "no barcode", and such an EAN is not taken into Catalog, whether the field is **Fill when empty** or **Always**, and whether the product is updated or created. It never clears a GTIN the product already has. The product's row in the **Products** section says **EAN in the ERP is not a valid GTIN**, so you can fix it in the ERP. GTINs are compared in their 14-digit form: `5901234123457` and `05901234123457` are the same GTIN, so a product that has one of them is left as it is, and another product that has either one counts as having it already. The modes you see before the first save are only suggestions: "These are the suggested settings. Nothing is applied until you save." Use the choices in the **How it arrives** column. Click **Preview**. For each field that changes, the card counts the linked products, how many values would be replaced and how many empty values would be filled, with a few examples. A field you turn off changes nothing: "Turned off: nothing changes, and products keep their last values." Click **Save fields**. The confirmation, **Save these field settings?**, repeats the preview. Click **Save**. If someone else changed the settings meanwhile, the card asks you to click **Reload** and choose again. ### What "Always" means A field that is **Always** from the ERP is not locked. People can still edit it in Catalog, in an import, in a bulk edit or through the API, and the product's **Details** (or, for the purchase cost, **Pricing**) say where it comes from: "Comes from ‹connection› — replaced when ‹connection› changes it." On **Pricing** the note names the field: "Purchase cost: comes from ‹connection› — replaced when ‹connection› changes it." * The ERP's value is applied **only when it changes in the ERP**, compared with the last value Omnilinker received from it. It is not applied again on every read, so your edit stays until the ERP changes that field. * Changes from the ERP appear in the product's **History**. **Changes** lists every value the ERP writes, including a SKU it changes, beside what people change in Omnilinker, named after the connection ("by ‹connection›"), and a product the ERP created reads as created by the connection. A pass in which nothing changed in the ERP, in your links, in the field table or in who manages SKUs, adds nothing. The purchase cost keeps its own history, which names the ERP. * A product that becomes linked, by code, by EAN, by hand or again after an unlink, takes every **Always** field once. That replaces what people typed in those fields. * When you turn a field on, or choose **Always** for it, the values come from the ERP data Omnilinker already holds: the products update without a new read. * Only one connection can be **Always** for a field. If another connection already is, the row says **Always from another connection**, and choosing **Always** for it here is refused with "‹field› already comes from ‹connection›. Change it on that connection first." * Changing a field to or from **Always** needs the **Choose where product SKUs and fields come from** permission. * A product that is inactive in the ERP stays linked and keeps receiving its fields. A product that is no longer in the ERP's product list stops receiving **Always** fields, and its SKU is yours again. A blank value from the ERP never clears a field in Catalog. A purchase cost of 0 is skipped too. ## Automatic linking **Automatic linking** chooses what links ERP products to catalog products without you: | Choice | Links when | | - | - | | **By code** (the default) | An ERP product's code equals the SKU of exactly one catalog product, letter case included. | | **By code, then EAN (GTIN)** | The code first. A product the code did not link is matched by EAN. | | **By EAN (GTIN) only** | Only a matching EAN links. A matching code is only suggested. | An EAN links only when all of these hold: its check digit is right, exactly one ERP product in the company has it, exactly one catalog product has it, neither product is linked yet, and nobody has unlinked or ignored the ERP product before. In every other case Omnilinker does not link; it suggests a match and says why (see [Suggestions](#suggestions-and-problems)). Nothing is ever unlinked by this setting. Click **Preview** to see how many products would link by code and by EAN, how many would only get a suggestion, and how many EANs are wrong or shared. If the products that would link are going to receive **Always** fields, the preview says "‹n› newly linked products would receive the fields that are Always from this connection" and counts the values that would change. Then click **Save linking** and confirm **Save this linking?**. Linking runs in the background. ## Automatic creation With **Automatic creation** on, products that your ERP marks for use by other systems are created in Catalog by themselves, and linked to their ERP product. Click **Review and turn on**. Nothing is created until you confirm. The confirmation, **Create products from ‹connection›?**, says how many products would be created, for example "‹n› products are marked in the ERP for other systems and not in Catalog yet. Create them?" Click **Confirm**. If new products arrived while you were looking, the card says "The number changed since you looked. Check it and confirm again." and shows the new count. Turning it on needs the Catalog permission to create products (**Product** > **Create**). After that, new matching products are created as they appear, and the card shows who turned it on and when. Click **Turn off** to stop; nothing that was created is removed. * **Match first, create second.** Only an ERP product with no link, no suggestion to review and no remembered unlink, ignore or deletion is created. * **A deletion sticks.** When you delete a catalog product that is linked to an ERP product, the ERP product is marked **Deleted in Omnilinker** and is not created again automatically. It still links by code or EAN, so a catalog product you create again with the same SKU links as usual. Deletions made before this release left no trace, so before you turn automatic creation on, check the products under **Not linked** and ignore any you do not want created again. * **Never deletes.** If a product stops qualifying, for example because the ERP blocks it, it stays in Catalog and linked, and keeps receiving its fields. Only a product that is inactive in the ERP shows **Inactive in ‹ERP›**. * A created product takes its SKU from the ERP's code, its name from the ERP's full name, and the other fields the connection's table allows. If its code cannot be a SKU (blank, or longer than 50 characters), it is skipped and reported. What qualifies depends on the ERP. For Wapro, see [Wapro](/erp/providers/wapro#which-products-are-created-automatically). To create other products, including inactive ones, select them in the **Products** section. ## Review the products The **Products** section lists every product the ERP has sent. See [Lists and mappings](/erp/reference-items#link-products) for the filters, the columns and what you can do with a row. That page also explains why an unlink sticks. ### Products deleted in Omnilinker Deleting a linked catalog product removes its link, and the ERP product is listed under **Deleted in Omnilinker**. Automatic creation leaves it alone, and so does **Create in Catalog**: the result says how many products were deleted in Omnilinker and not created again. To bring one back, click **Create again** on its row, or tick several rows and click **Create again** above the list. A new link of the ERP product, automatic or by hand, also takes it off the list. ### Suggestions and problems A product that did not link by itself may carry a suggestion, with its reason: the same code, the same SKU apart from case, spaces or leading zeros, the same EAN, a code that equals its warehouse code, or a similar name. A reason can also say why it did not link: the EAN's check digit is wrong, the EAN is shared by other ERP products or by catalog products, or the catalog product is linked to another ERP product. **Link suggested** confirms suggestions in one click. A linked product shows a red badge when something is wrong with its update: **SKU taken by another product**, **EAN taken by another product**, **SKU too long**, **A field's source moved**, **EAN in the ERP is not a valid GTIN** or **The last update failed**. ## Permissions | To | You need | | - | - | | See the card | **ERP Connections**, and **Reference Data** and **Entity Mappings** for the tab | | Preview a change | **Entity Mappings** | | Save the field table, the linking, or turn automatic creation off | **Manage Entity Mappings** | | Change a field to or from **Always**, or change who manages SKUs | **Choose where product SKUs and fields come from** (Catalog) | | Turn automatic creation on | **Manage Entity Mappings** and **Product** > **Create** (Catalog) | | Create products from the **Products** section, or create them again | **Manage Entity Mappings** and **Product** > **Create** (Catalog) | ## Related pages Link, unlink, ignore and create products one by one or in bulk. Where the fields appear and who manages SKUs. What Wapro sends and which products it creates. A connection that cannot be deleted, or a product that does not link. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.