Skip to main content
The agent reads three lists from your ERP and sends them to Omnilinker: price levels, warehouses and products. It also sends the ERP’s stock and, once you ask for it, its selling prices. On the connection’s page you match each list item to its Omnilinker counterpart:
  • an ERP price level to a catalog price level, on the Price levels tab;
  • an ERP warehouse to an Omnilinker warehouse, on the Warehouses and products tab;
  • an ERP product to a catalog product (a link), on the Warehouses and products tab. Omnilinker links most products by itself.
You need the Reference Data and Entity Mappings permissions to see the two tabs, and Manage Entity Mappings to change mappings, link products or click Refresh lists. Open ERP Integration > Connected systems, open the connection, and choose the tab. When you set a connection up, the setup’s Who sets what step maps the price levels and warehouses for you in one save; see Create a connection.

Lists from the ERP

For each product the agent sends, besides its code and name, the details your catalog can use: invoice name, VAT, unit, EAN, brand, purchase cost, weight and dimensions. See Products from your ERP. The lists hold only the company set in the agent (Company number). See Wapro.

Stock

Stock is the fourth thing the agent sends. You don’t map it: Omnilinker shows it on Stock Levels, a product’s page and Warehouses, beside your own stock, for products linked to an ERP product and warehouses mapped on this connection. On a warehouse Omnilinker manages it is for comparison only: nothing lands in your stock levels and channels keep using Omnilinker’s stock. On a warehouse this connection manages, it becomes the warehouse’s stock; see Hand a warehouse to your ERP. For Wapro the agent reads it every 5 minutes while at least one warehouse of the connection is mapped, sends only what changed, and sends a complete set once a day; see Wapro. It needs an agent from this release: an older agent sends no stock.

Prices

Prices are read for comparison, and only when you ask for them. The agent reads the ERP’s selling prices only while both of these are true:
  • a price level of the connection is mapped to a catalog price level, and
  • Read prices from the ERP is switched on for your organization. It is off until Omnilinker switches it on for you: ask Omnilinker. See Modules and feature availability.
Then the agent reads the ERP’s price of every product at every price level: every 15 minutes, comparing with the last read and sending only what changed, and in full once a day. Mapping a price level asks for a read at once, so a new level shows its prices within minutes. Switching the feature off stops the reading at the agent’s next heartbeat, within a minute or so, and hides the comparison. You can change the 15 minutes; see Reading prices. A price arrives for a product’s base unit, one per price level and product; quantity tiers and other units are not read. A price whose net and gross are both 0 counts as no price: it is not sent, and 0.00 or a missing price never blanks a price in your catalog. A price that disappears from the ERP is marked as gone in Omnilinker, never as 0. On a price level Omnilinker sets, nothing changes in your catalog: the ERP’s prices do not replace yours. They are compared with yours for each mapped price level (see Compare the ERP’s prices with yours). On a price level the ERP sets, they replace yours for the linked products; see Prices from your ERP. For Wapro, see How prices are read. It needs an agent from this release: an older agent reads no prices, and the lists card says so.

When the lists are read

The agent reads the lists:
  • when its connector starts, for example after the service starts, but only for a list that has not been read yet, is more than a day old, or was read under other settings (another database, company or warehouse),
  • when the connection’s settings change and a list was read under the earlier ones,
  • about once a day after that,
  • when you click Refresh lists on the connection’s Overview tab, and
  • when an operator clicks Refresh lists in the tray app’s Settings.
Each list arrives complete (stock also arrives as changes in between). An item that is missing from a complete list is not deleted in Omnilinker: it is marked Stale. A read that stops part-way, for example because the computer was switched off, marks nothing Stale: the items from the pages that already arrived are updated or added, and the next read starts again.

The lists card

The connection’s Overview tab has a Lists from ‹ERP› card, with one line per list, for example Receives stock · Read 14:02 · by comparison · 120 products in 3 warehouses. Times are when Omnilinker received each list:
  • Receives stock, Receives products, Receives price levels, Receives warehouses, Receives prices, Receives orders sent from Omnilinker or Receives product images: the lists this connection’s connector sends. Receives orders sent from Omnilinker is the read-back of the orders you sent (see Invoices); it appears once the connection has sent an order, and the agent reads it only while an order was sent in the last 90 days. Receives prices appears once a price level of the connection is mapped, and not before. Receives product images appears while the agent is asked for images: Read product images from the ERP is on for your organization, the connection’s Images field is not Off and a product is linked (see Product images); its count is the products the last complete read carried.
  • Read and a time (or not read yet for a list the agent has not sent): when the list was last read. Hover over it to see the full date and time in your organization’s time zone. The time turns amber when stock is more than 6 hours old, when prices are more than 6 hours old, when the orders sent from Omnilinker are more than 1 hour old, and when any other list, product images included, is more than 48 hours old, or has never been read. Prices are amber only while Omnilinker asks the agent for them. A line the agent is no longer asked for, because no order was sent for 90 days or images are no longer wanted, is never amber. Omnilinker measures it on its own clock, from when the agent’s report arrived.
  • by changes, by comparison or by complete reads: how the agent reads the list. For Wapro, stock, prices and the orders sent from Omnilinker are read by comparison (the agent compares each read with the last one and sends the differences), and the other lists are read by complete reads.
  • 120 products in 3 warehouses for stock, 1,200 prices on 3 levels for prices, or 6 items for the other lists: what the last read carried.
  • reading prices is off for this account: the Prices line says this instead of the time, the mode and the counts while Read prices from the ERP is off for your organization. Omnilinker has not asked the agent for prices, and it stays so until Omnilinker switches the feature on.
  • Update the ERP Sync agent to read prices: the connection’s agent is older than the release that reads prices. Update it; see Install the agent.
  • Refresh requested at a time: Omnilinker has asked the agent for the lists, and they appear when the agent has read them.
  • ERP Sync has not reported any list this connection’s connector sends.: the agent has not reported its connector yet, or the connector cannot read the lists right now. See Troubleshooting.
Refresh lists asks the agent to read every list again. Omnilinker confirms with “ERP Sync was asked to refresh the lists. They appear here when it has read them.” The agent picks the request up within about a minute while it is online. Omnilinker offers a request to the agent for one hour only: if the agent is offline, or waiting for an update, for longer than that, the request lapses and Refresh requested at disappears, so click Refresh lists again when the agent is back.

Price levels

The connection’s Price levels tab has one row per catalog price level: the ERP level it is mapped to, who sets it, and its prices with one time. A level’s owner and its ERP level are changed here and nowhere else on the connection.
1

Map each price level

In a row, choose the ERP level for the catalog level. Choose — Not mapped — to remove the mapping. An ERP level already used for another catalog level says “(used for …)”, and one the ERP calculates “(calculated in ‹ERP›)”.
2

Check that it saved

Each choice is saved as soon as you make it; the row says Saved, or Saved · read requested when the mapping asked the ERP for a read of its prices.
The rows are grouped by direction, each group with a count:
  • Received from ‹ERP›: the ERP sets the catalog level, and its prices come from the ERP for the products linked to it.
  • Sent to ‹ERP› automatically: the catalog level is Omnilinker’s, and every change to its prices goes to this ERP automatically. See Send prices automatically.
  • Can be sent with Send to ERP: the catalog level is Omnilinker’s, so its prices can be sent to this ERP.
  • Neither received nor sent: for example a level that is not mapped, or one another system manages.
Sending automatically. While Omnilinker has switched on Send prices to the ERP automatically for your organization, a level Omnilinker sets, mapped once to a level the ERP does not calculate, has the switch Send changes automatically and the action Send all ‹n› prices now, for people who have both Manage Entity Mappings and Send prices to ERP. A level sent automatically has a line with when its prices were last sent, what waits, why sends are held and what was not written, with Try again. While the feature is off, the tab says “Automatic sending is not switched on for your organization”. See Send prices automatically. Under the rows, ‹ERP› levels not used lists the ERP’s levels no catalog level uses. One the ERP works out from another level is tagged Calculated in ‹ERP› · can only be received. To use a level, pick it in a row above, or create a level in Catalog > Price Levels first. Who sets it. Each row shows the owner of the catalog level and since when, for example “Omnilinker · Catalog since 09:57”, with Change owner for people who may change who sets price levels; see Who sets a level’s prices. A level Omnilinker sets also names the rule that writes it, for example a repricer rule. A level the ERP sets cannot be unmapped while it sets it (“Can’t be unmapped while ‹ERP› sets it.”). Catalog’s Price Levels shows the same owners. One time per row. A received row shows when the ERP’s prices were read (“Received from ‹ERP› · read 14:02”); a row Omnilinker sets shows when they were compared (“Compared with ‹ERP› at 14:05”). Hover over a time for its date and time zone. While Read prices from the ERP is off, a callout says “Reading prices is off for this account.”, a received row says no prices are read while reading is off and the last ones stay as they landed, a compared row says “Not compared: reading prices is off for this account.”, and no time is shown. What landed (a level the ERP sets): under the read time, a line counts what landed, for example Landed 118 · Not linked 4, with the other outcomes in its details. Not linked opens the connection’s unlinked products. Details opens What landed and What you can do: link the products that are not linked, give a product without a sales VAT rate one in Catalog (its price lands at the next read), and see the prices in another currency, the ones that could not be written and the ones that wait to land. See Prices from your ERP. The read banner. When you change a mapping, the tab shows Read requested with what the read covers. A mapping you change before the read starts joins it; no second read is asked for. A comparison restarts when its read arrives. A row can also say why its prices do not move:
  • “‹ERP› calculates this level, so Send to ERP refuses its prices. To send them, map the catalog level to a level ‹ERP› does not calculate.”
  • “This catalog level is mapped to more than one level of this ERP (…). Send to ERP sends none of its prices until it is mapped once.”
  • “Another system manages this level: Omnilinker neither receives nor sends its prices.”
  • “‹ERP› sets this level, but no ‹ERP› level is mapped to it, so its prices do not arrive. Pick its ‹ERP› level.”
If the tab says No reference data discovered yet. It is uploaded by the on-premise agent., the list has not arrived yet: see The lists card.

What a mapped price level is used for

A price level mapping does two things. It tells Omnilinker which ERP price level a catalog price level is sent to, when you send prices to your ERP by hand or automatically, and it makes the agent read the ERP’s prices at that level so you can compare them with yours (see below). It is also where the ERP’s prices land when you let the ERP set the level. A level the ERP calculates (Calculated in ‹ERP› · can only be received) can be compared, but cannot take a price: a send to it is refused with “This ERP price level is calculated in the ERP and cannot be written.” Map each catalog price level to one ERP price level only: with two mappings Omnilinker refuses to send a price, because it could reach the wrong level. When you move or remove a mapping, the price sends still waiting for the old ERP level are withdrawn, so none of them reaches a level the catalog level is no longer mapped to.

Compare the ERP’s prices with yours

While Omnilinker asks the agent for prices, a row Omnilinker sets compares the ERP’s prices at its level with the prices of your catalog, for the products linked to an ERP product: Compared with ‹ERP› at 14:05 · Equal 120 · Differs 3 · No price in Omnilinker 5
  • Equal: the ERP’s net and gross are the same as the product’s price at the mapped level. Both are rounded half away from zero to the currency’s smallest unit before they are compared. A price you sent also counts as Equal when the ERP still holds what it stored for it, the amount you sent (net or gross) is unchanged on both sides, and the other amount differs by at most the currency’s smallest unit (one grosz) because the ERP rounds it its own way. This applies only on a level the ERP does not set. On a level the ERP sets, Omnilinker must hold the ERP’s exact prices, so such a gap stays Differs and the ERP’s price lands again.
  • Differs: the amounts are not the same. That includes a price the ERP holds because Omnilinker sent it, when you have changed the product’s price since and not sent it again. Only a price that is still on its way to the ERP is not counted as a difference.
  • No price in Omnilinker: the ERP has a price and the product has none at the mapped level.
  • Compared with ‹ERP› at: when the comparison was last made. Omnilinker compares again a few minutes after new prices arrive or a price changes in Omnilinker, and once a day.
When prices changed in Catalog since the comparison, the row says so, for example “3 Allegro PLN prices changed in Catalog since, by ‹person›”, and offers Compare again, which shows “Comparing… asked 14:07” until it is done. “Up to date with Catalog.” means nothing changed since. Click Details to open the rest: Sent by Omnilinker, still on its way (the prices differ while Omnilinker is still sending the product’s price to the ERP), Price gone from ‹ERP› (the ERP had a price for the product and no longer has one), Other currency (the two prices are in different currencies, so they are not compared), No price on either side (the ERP’s price is gone and the product has none at the mapped level either) and No sales VAT rate, counted above. Every compared product is in exactly one of the groups from Equal to No price on either side, so together they add up to the products compared. Prices that differ lists up to 5 of the products that differ, with Omnilinker’s net price, the ERP’s, and what Omnilinker keeps; each opens the product. The comparison covers the prices the ERP has reported for your linked products. A product the ERP has never priced at that level (or priced at 0) is not in it yet. A row says Not compared yet until the first comparison has run after reading started. The comparison only shows; it changes no price in your catalog or in the ERP. On a level Omnilinker sets, a price changed in the ERP shows “Differs in ‹ERP›: 6 · found 14:05”, with Change who sets prices and Open details, which opens the level’s page; see A level Omnilinker keeps.

Warehouses

The Warehouses and products tab starts with the ERP’s warehouses, one row each, with when the connection’s stock was last read. Each row shows the warehouse In ‹ERP›, its warehouse In Inventory, Who changes stock and the flow. Not mapped: 3 counts the ERP warehouses that are neither mapped nor ignored. Map a warehouse. Choose an Omnilinker warehouse in the row’s Inventory warehouse list; choose — Not mapped — to remove the mapping. Each choice is saved as soon as you make it. A warehouse the ERP manages cannot be unmapped (“Can’t be unmapped while ‹ERP› changes its stock.”). A row that is not mapped can offer:
  • Suggested: ‹warehouse› · same code (or similar name) when an unmapped Omnilinker warehouse has the same code as the ERP warehouse, or a name that differs only in case and spacing. Click Map it to map to it. The suggestions are worked out each time the list is shown, so a warehouse you create or rename in Inventory is suggested at once, without waiting for the next list from the ERP.
  • Create in Inventory: creates an Omnilinker warehouse from the ERP warehouse and maps it in one step (“Created … in Inventory and mapped it. Omnilinker · Inventory manages its stock.”). It needs the Create Warehouses permission in Inventory. A code longer than 20 characters is shortened, and the row says “Its code in Inventory is …”.
  • Ignore: for an ERP warehouse you never want in Omnilinker. An ignored warehouse is listed as Ignored, with who ignored it and when, is not offered for creation, is not counted in Not mapped, shows no stock and cannot be mapped (Omnilinker says “The ERP warehouse … is ignored on this connection. Stop ignoring it before you map it.”). Stop ignoring brings it back.
Omnilinker can refuse a creation, and then says why on the row:
  • “Inventory already has a warehouse with the code …”: click Map to the existing warehouse. If that warehouse is inactive, activate it in Inventory first. If it is already mapped to another ERP warehouse of this connection, no button is offered: a warehouse mapped twice shows no ERP stock, so pick another warehouse or change the existing mapping.
  • “Your plan allows one warehouse in Inventory, and it already has one.” or “Your plan allows at most N warehouses in Inventory, and all of them are used.”: map the ERP warehouse to an existing one instead.
  • “You can’t create warehouses in Inventory. Ask someone who can, or map this ERP warehouse to an existing one.”
The warehouse you create is an ordinary Omnilinker warehouse; see Warehouses. Open in Inventory on a mapped row opens it there.

Who changes a mapped warehouse’s stock

Who changes stock reads Omnilinker · Inventory when your team changes the stock in Omnilinker, or the connection’s name when the ERP manages it, with since when. With the Change who changes stock permission, Change owner opens the warehouse’s owner dialog, a guided switch in Inventory; see Hand a warehouse to your ERP. The flow says what this connection does with the warehouse’s stock:
  • Stock managed by ‹connection› with when it was read: this connection manages the warehouse’s stock, and Omnilinker’s stock for the warehouse follows its reads. The time turns amber after 6 hours; before the first read it shows an amber not read yet, and Omnilinker keeps the warehouse’s last stock until then.
  • Stock read from ‹connection› with when it was read: ERP Sync reads the ERP’s stock in this warehouse, and Omnilinker shows it beside its own on Stock Levels, on a product’s page and on Warehouses, for comparison only. The time is when the connection last read its stock, the same for all its warehouses; it turns amber after 6 hours.
  • Not read until it’s mapped, No stock shown (for example because two ERP warehouses are mapped to the same Omnilinker warehouse), or Not on the ERP’s list any more.
Tick Show stale to also list warehouses that are no longer in the ERP. A badge Inactive in the ERP marks a warehouse the ERP no longer uses. Below the warehouses, Products that need you lists the ERP’s products with their links to catalog products. It appears when the connection’s connector sends products, and it opens on what needs a person: the Suggested group while it holds anything, then Not linked, no suggestion, then Linked. The line under the title counts the products in the ERP and how many are linked, with when the list was read. What links on its own, which fields a product takes from the ERP and how products are created is shown under How products arrive from ‹ERP›, further down the tab. See Products from your ERP.
  • Groups: Suggested, Not linked, no suggestion, Linked, Ignored, Inactive in ‹ERP›, Missing in ‹ERP› and Deleted in Omnilinker, each with its count. Groups with nothing in them are hidden.
  • Linked narrows linked products by how they were linked: Any way, By a person, By code, By GTIN or Created from this ERP.
  • Search by code, name or ERP key finds a product.
  • Each row shows the ERP product, Why it is in its group (for example the reason for a suggestion), and the catalog product it is linked to, or Not linked. A linked row says how it was linked. A red badge on a linked row names a problem: SKU taken by another product, EAN taken by another product, SKU too long, A field’s source moved or The last update failed.
Suggestions. A product that did not link by itself gets a suggested catalog product when one is close enough, with the reason, for example Same code or GTIN shared by 3 products. In the Suggested group, Link links a row to its suggestion, Link another lets you choose another catalog product, and Not this one ignores the product: it won’t be suggested or linked automatically (Stop ignoring is in the Ignored group). Link all ‹n› links every suggested product to its suggestion after you confirm the count; it says how many were linked and how many were not. If the suggestions changed while you were deciding, nothing is linked and Omnilinker asks you to check the list and press Link all again. Not linked, no suggestion. A card says how many products the ERP has that nothing suggests a catalog product for, with Review them. Create them in Catalog after a review, link them by hand, or ignore the ones you don’t sell. Until they are linked, nothing moves between Omnilinker and the ERP for them. Automatic links. After each complete product list, Omnilinker links the ERP products that are not linked yet and are active in the ERP, using the connection’s link key: by code (the default), by code then EAN (GTIN), or by EAN (GTIN) only. With the default, a product links when its code equals the SKU of exactly one catalog product. A link is kept by the ERP key, so it survives a change of the product’s code in the ERP: the new code is shown at the next list. Omnilinker never links a product that a person unlinked or ignored. See Automatic linking. Link by hand. Click Link on a row, search the catalog by SKU or name (type at least 2 characters), and choose the product. A catalog product can be linked to only one ERP product on a connection; otherwise Omnilinker says “This catalog product is already linked to another ERP product on this connection.” An ERP product that is inactive in the ERP can still be linked by hand. Unlink. Click Unlink on a row and confirm. Omnilinker remembers it: the row shows Won’t link automatically, and no automatic link, re-key or creation touches that product again, even while its code equals a SKU. To undo it, click Link and link it by hand. Unlinks made before this release were not remembered, so some of those products may have linked again by themselves: open Linked, choose By code and check the list. A link whose catalog product no longer exists is the exception: unlinking it marks the ERP product Deleted in Omnilinker (it is not created again by itself), and it can still link by the connection’s link key. Ignore. Click Ignore on a row for an ERP product you never want linked or created, and Stop ignoring to bring it back. Ignored products are listed under Ignored. Create in Catalog. Click Create in Catalog on a row to create a catalog product from the ERP product and link it to it. The SKU is the ERP’s code, the name is its full name, and the other fields follow the connection’s product settings. A product whose SKU is already in Catalog is not created: link it instead. Create again. When you delete a linked catalog product, its ERP product is listed under Deleted in Omnilinker, with a badge of the same name, and is never created again by itself: automatic creation and Create in Catalog skip it. Click Create again on its row to create it anyway. It still links by code, EAN or by hand, and a new link clears the mark. See Products deleted in Omnilinker. Several at once. Tick rows to act on them together: Link suggested, Create in Catalog, Create again or Ignore. The selection holds the rows of one page, and Clear selection empties it. Omnilinker asks you to confirm with the count. More than 50 products from Create in Catalog are created in the background: the Creating products in Catalog window shows the progress, and you can close it while the creation goes on. Create again always creates the selection directly, in batches, with no progress window. The result counts the products created, those already in Catalog under the same SKU, those deleted in Omnilinker and not created again, those skipped and those that failed. Linking and unlinking need Manage Entity Mappings, and creating products also needs the Catalog permission to create products. A Create in Catalog or Create again button you cannot use is hidden. Products no longer in the ERP. A product that is inactive in the ERP stays linked and is marked Inactive in ‹ERP›. When a linked product disappears from the ERP’s product list, it is marked Missing in ‹ERP›: it keeps its link, but its Always fields stop updating and its SKU is yours again. The list says “Links to products that are no longer on the ERP’s product list: ‹n›. Sending their price fails until they are linked again.”, and Show them lists them. Unlink them, then link each catalog product to its product on the ERP’s current list. A link becomes live again by itself if the product returns to the ERP’s list. Omnilinker deletes no product. If the list says “The ERP’s product list has not arrived yet. ERP Sync sends it by itself; Refresh lists (Manage Entity Mappings) asks for it at once.”, wait for the agent or click Refresh lists on the Overview tab.
After Omnilinker moved to stable ERP keys, product links are made again from the ERP’s product list. If a connection shows no product links, click Refresh lists once.

Who manages SKUs

How products arrive from ‹ERP› says who may change product SKUs and delete products, under Who manages SKUs. By default it reads Omnilinker · Catalog. Changing it is a guided switch; see Products from your ERP.

Dangling mappings

A list shows mapping(s) need attention when a mapping no longer fits:
  • — ERP item no longer present: the ERP price level or warehouse is gone from the latest list.
  • — target no longer available: the catalog price level or Omnilinker warehouse it points to was deleted.
Click Delete next to the item to remove the mapping, then map the item again if it still exists.

The source warehouse

Wapro keeps one row per warehouse for each article. The connection’s Source warehouse says which warehouse’s row Omnilinker works with for a product’s prices. It is shown under Current answers on the connection’s Overview tab. To change it, click Change next to Source warehouse (you need the Edit ERP Connection permission), choose a warehouse from the ERP’s warehouse list, and click Save. — not set — (automatic fallback) uses the article’s active row with the lowest number. The agent picks the change up within about a minute. The list offers the warehouses the agent sent. Before the first list arrives, type the warehouse’s ID instead. A warehouse that is not on the list is refused with “This warehouse is not on the ERP’s warehouse list. Refresh lists and pick one.”