Skip to content

Worked examples ​

Twelve short stories, each with real-looking numbers and what you will see on the screen. They follow the rules explained in How it works. Unless a story says otherwise, the account is Live, Active and Healthy, publishes Available, and has No limit for lead time.

#StoryWhat it shows
1A product sells out in the warehouseThe ordinary path, end to end
2A new product appears in the PIMNot linked becomes Linked
3An offer on eMAG with no PIM productNot linked offers are left alone
4The marketplace rejects a quantityRejected, and what to do
5Credentials expireSuspended and Recover
6Switching an account to LivePreview to Live
7A long lead-time productEligibility and stock 0
8Why available and not on handOn hand is shown, never sent
9Read PIM nowNot waiting for the quarter hour
10A burst of changesBatching and speed
11eMAG has an outageWaiting, Failed, Retry failed
12A customer order before the PIM knowsDrift and the daily import

1. A product sells out in the warehouse ​

Situation. Offer 101577 on eMAG RO (a jacket, size M) shows Published 2. At 14:03 the last two pieces are sold in the shop. The warehouse system updates the PIM: available 0, on hand 0.

What Stock Sync does.

  1. 14:07 — the PIM reading sees product 101577 changed: available 2 → 0.
  2. The offer is recalculated: stock to publish 0. Published is 2, so it becomes Waiting to send.
  3. 14:07, a second later — the sending round sends "101577: 0". eMAG accepts.

What you see.

WhereBeforeAfter
Offers list, Stock column (PIM available › stock to publish › marketplace shows)2 › 2 › 20 › 0 › 0 (after the next offer import; Sent is 0 at once)
The offer's PIM stock2 / 20 / 0
Stock to publish20
Sent (published)20
StatusIn syncIn sync (Waiting to send for about a second; the row flashes as it changes)
The offer's History—Stock to publish changed, then Published

Nobody oversells the jacket on eMAG after 14:07.

2. A new product appears in the PIM ​

Situation. Last week operations listed a new T-shirt on Fashion Days RO with offer id 120350, before the PIM team had created the product. The daily import found the offer; it is Not linked and shows 0 on the marketplace. Today at 09:40 the PIM team creates product 120350: available 12.

What Stock Sync does.

  1. 09:52 — the PIM reading brings the new product 120350.
  2. Stock Sync finds the not-linked offer 120350 waiting for exactly this id. The offer becomes Linked.
  3. Stock to publish 12; Published 0; so Waiting to send, and 12 is sent.

What you see. On the account's Summary, Not linked drops by one, and the row leaves the Not linked quick view of Offers. The offer's history shows Linked to PIM product, Stock to publish changed, Published. The T-shirt starts selling at 09:52, without waiting for the next day's import.

3. An offer on eMAG with no PIM product ​

Situation. The eMAG BG import finds offer 55012 with 15 pieces. It was listed by hand years ago, with an id that is not a PIM product id: the PIM has no product 55012.

What Stock Sync does. No PIM product has this id, so the offer is Not linked. Stock Sync never sends anything for it, whatever happens in the PIM.

What you see.

  • The Not linked quick view of Offers shows 55012 with the status Not linked. The Product column has no brand, name or SKU from the PIM; the Stock column is empty (hover: "Stock Sync never sends stock for this offer."), and Eligible shows —. Its side panel says "Not linked to a PIM product: Stock Sync never sends stock for this offer." instead of a stock path; Marketplace shows is 15.
  • It counts in Not linked on the account's Summary.
  • It is not counted in the account's In sync percentage, which is about linked offers only.

What to do. If the product should be synced, list it again on eMAG BG with its PIM product id as the offer id, and end the old offer. To find the right product, look up the offer's barcode on the marketplace and search the PIM for it: the Offers list cannot find a not-linked offer by barcode, because barcodes come from the linked PIM product. Matching by barcode is never automatic. See Matching offers to products.

4. The marketplace rejects a quantity ​

Situation. Offer 204411 on eMAG RO is part of a campaign. At 11:22 the PIM drops from 10 to 6.

What Stock Sync does.

  1. 11:22 — sends 6. eMAG refuses, with a message saying the offer is in a campaign.
  2. The offer becomes Rejected. Because the reason is a campaign, Stock Sync tries 6 again every 6 hours: 17:22, 23:22, 05:22 …
  3. Day 3, 05:22 — the campaign has ended. eMAG accepts. In sync, Published 6.

What you see.

  • Status: Rejected, and Last problem shows eMAG's message.
  • The Overview's Needs your attention: "1 offer rejected by the marketplace on eMAG RO — Campaign locks retry by themselves; the others need the cause fixed, then Resync." The Needs a fix tile shows "0 failed · 1 rejected · 0 orphaned".
  • In the offer's History, Request and response shows exactly what eMAG answered.

If the reason were different (for example "This offer does not exist"), there would be no automatic retry. Fix the offer on the marketplace, then press Resync on the offer. See Sending stock to the marketplace.

5. Credentials expire ​

Situation. The API password of eMAG HU is changed in the eMAG seller portal on Friday at 16:00. Nobody updates Stock Sync.

What Stock Sync does.

  1. 16:07 — a PIM reading changes 9 offers of eMAG HU. The sending round's first request is answered "401", the marketplace's code for a wrong login.
  2. The account becomes Suspended, with the reason "eMAG offer/save answered 401: …". No offer import or Recalculation runs for eMAG HU, and nothing is sent. Stock to publish still follows the PIM.
  3. Over the weekend PIM changes keep updating Stock to publish. The Waiting to send count grows to 430.

What you see.

  • Top of the Overview's Needs your attention, in red: "eMAG HU is suspended", with the reason and the Edit connection and Recover buttons.
  • A red SUSPENDED tag beside eMAG HU in the sidebar; its status reads Suspended, and its red status banner gives the reason.

What to do. On Monday, get the new password, click Edit connection, enter it in Settings → Connection, save, then press Recover and confirm. eMAG accepts: "eMAG HU is recovered; its offers are being imported and its waiting stock updates sent." The offers are imported again and the 430 updates go out within a few minutes. See Bring back a suspended account.

6. Switching an account to Live ​

Situation. Fashion Days BG was created on Monday and has been in Preview since. Its status banner says "Going Live would send 812 stock updates now."

Checks before going Live.

  • On the account's Offers tab, pick the Waiting view. Open a few offers in the side panel and compare Stock to publish with Marketplace shows. For offer 300001: PIM 3 / 5, publishes Available, so 3; the marketplace shows 8. Operations agrees 3 is right.
  • Look at Not linked offers (179 of them). They will not be touched.

Going Live. An operator presses Go Live in the status banner. The dialog Go live with Fashion Days BG? repeats "Going Live would send 812 stock updates now." The operator types Fashion Days BG and presses Go live.

What you see. "Fashion Days BG is Live; its waiting stock updates are being sent." A Sending round with "812 published" appears in the Live feed a few seconds later. The account's Waiting drops to 0, and its status reads Sending. See Go from Preview to Live.

7. A long lead-time product ​

Situation. eMAG RO has a Lead-time limit of 2 days. Product 88420 is a bag with 4 pieces available. Its stock now comes from a supplier with a lead time of 5 days.

What Stock Sync does. Lead time 5 days is longer than 2: the offer is not eligible. Stock to publish 0, although the PIM says 4. 0 is sent.

What you see. In the Offers list: Stock 4 › 0 › 0, Eligible 5 d > 2 d, and "Not eligible — publishes 0" under the status. On the offer: Eligible: No — 5 days > 2 days, Stock to publish 0. The Not eligible option of the Eligible filter, or the Not selling view, lists all such offers.

On Fashion Days RO, which has No limit, the same bag still publishes 4.

Later. Own stock arrives and the PIM's lead time drops to 1 day. At the next reading the offer becomes eligible again and 4 is sent. See How the quantity is calculated.

8. Why available and not on hand ​

Situation. A tester opens offer 300001 on eMAG BG. Its PIM stock reads "3 available / 5 on hand", and Stock to publish is 3. She asks why the marketplace is not offered the 5 pieces on the shelf.

What Stock Sync does. It publishes the PIM's available stock on every account. On hand counts every piece in the warehouse, including the 2 Odoo has reserved for orders that are not shipped yet; offering them again would sell them twice. Some examples:

OfferPIM available / on handStock to publish
3000013 / 53
3000020 / 20 (both pieces are reserved)
3000039 / 39 (6 pieces are at a supplier)
30000480,000 / 80,00065,535 (the marketplace maximum)

What you see. The available number (the first of PIM stock, and the first of the list's Stock column) is the one that is sent. When on hand changes and available does not, nothing is sent. See How the quantity is calculated.

9. Read PIM now ​

Situation. At 10:25 the PIM team calls: they corrected the stock of 300 products that were wrong since the morning. The next PIM reading is at 10:37.

What you do. On the Overview, press Read PIM now (or press Ctrl K and choose it).

What you see. "A PIM reading was requested. PIM data updates when it finishes, usually within a minute." Within a minute the PIM data tile shows about a minute ago, and Activity → Sync runs has a new PIM reading with "300 changed" among its counts. The corrected numbers are sent to every Live account in a few seconds, 12 minutes earlier than they would otherwise have been.

If a colleague presses the button at the same moment, only one reading runs. See Read the catalog again now.

10. A burst of changes ​

Situation. At 05:50 the warehouse finishes its night stock count and the PIM updates 20,000 products at once. eMAG RO has offers for 18,000 of them.

What Stock Sync does.

  1. 06:07 — the PIM reading sees 20,000 changed products.
  2. The offers are recalculated. 15,000 of the 18,000 really differ from Published; they become Waiting to send. The other 3,000 are unchanged and are not sent.
  3. The sending round sends them 50 per request, 2 requests per second: about 100 offers per second. The 15,000 go out in about 2.5 minutes.

What you see. The Waiting to send tile on the Overview jumps to about 15,000 and falls to 0 over a few minutes, as you watch. The throughput chart shows a spike. Nothing needs doing.

11. eMAG has an outage ​

Situation. eMAG answers every request with a server error (code 503, "service unavailable") from 14:00 to 15:30. 37 offers of eMAG RO are waiting.

What Stock Sync does. Retries after 30 s, 1 min, 2 min, 4 min, 8 min, 16 min and 30 min. The 8th failure, at about 15:02, turns the 37 offers Failed.

What you see.

  • While retrying: Status: Waiting to send, Last problem: "eMAG offer/save answered 503: … · attempt 4, next try in 4 minutes". The sending rounds in Activity → Sync runs still say Succeeded: nothing has given up yet.
  • After 15:02: the round at about 15:02 counts "37 failed", and the Overview's Needs your attention shows "37 offers failed on eMAG RO — Sending gave up after 8 temporary errors. Retry once the marketplace works." Needs a fix turns red.

What to do. At 15:35, check that eMAG works again, then press Retry failed on that row of the Overview (or at the top of the Offers list). The 37 go out in a second.

12. A customer order before the PIM knows ​

Situation. Offer 101577 on eMAG RO shows 5. At 22:10 a customer buys one piece on eMAG. eMAG lowers its own stock to 4. The order reaches the warehouse system and the PIM only at 07:30 the next morning.

What Stock Sync does.

  1. 04:41 — the daily offer import reads Marketplace shows 4. Stock Sync last published 5, and the PIM still says 5. This difference is drift. The offer goes to Waiting to send and 5 is sent again.
  2. 07:37 — the PIM reading brings the order: available 4. Stock to publish 4; 4 is sent.

What you see. The offer's History shows both sends. This is expected behaviour: the PIM is the source of truth, and Stock Sync follows it, even when the marketplace knows about an order first.

More ​

Channel Hub Stock Sync — user guide for operators and viewers