We ask first.

This website works without cookies. If you agree, we will also use cookies for measuring visits and our advertising. You can change your mind at any time from “Cookie settings” at the bottom of every page. Cookie policy

On a limestone shelf, a row of identical white ceramic cups and, beside them, a thin glass channel carrying water from one spring into three basins.

ServicesSystems & applications

One source for price and stock: what the customer sees is what the warehouse holds.

Prices & stock in sync

One source for price and stock: what the customer sees is what the warehouse holds.

A product's price and stock travel from the ERP to the shop, from there into an XML file or an API, and on to Skroutz, BestPrice and Google. Every stop keeps its own clock, and wherever the clocks disagree the customer sees something wrong. Here is where the path breaks, what each platform does when it notices, and how to build one source of truth with logs, retries and alerts.

Tell us about yours
Once
a day at least, a cached XML for Skroutz has to be regenerated. That is the minimum, not the goal: stock changes far more often.Skroutz, XML specification
500
products per request is what Skroutz's Products API accepts for price, quantity and status changes, processed asynchronously, without waiting for the next XML.Skroutz, Products API
4 fields
Google corrects by itself from your page, with automatic item updates: price, sale price, availability, condition. They do not replace regular updates of your product data.Google Merchant Center
30
days: a discount is calculated from the lowest price of at least the 30 previous days, as the EU Court of Justice confirmed in 2024. The “was” price in the feed has to come from the same history.Directive 98/6/EC, Article 6a, and CJEU C-330/23

Last updated:

One number, five copies.

A product's stock does not live in one place. It lives in the ERP, in the shop's database, in the XML that Skroutz and BestPrice read, in Google Merchant Center's data and, if you sell on Skroutz Marketplace, in the orders that arrive from there. Five copies of the same number, each updated its own way.

The ERP changes with every delivery and every sale in the store. The shop learns of it when the sync runs. The XML is rewritten when the job that produces it runs, and the platform reads it when its turn comes. Google also visits the page and compares. Each delay adds to the next.

That is why the question “why does Skroutz show something in stock that has sold out?” rarely has one answer. You have to find which of the five copies lost the change, and when.

  • ERP

    Usually the source for stock, codes and list prices. It changes with purchases, in-store sales and stock counts.

  • Shop

    Shows the customer the price and availability and holds their orders. Often it holds the offers too.

  • XML feed

    A file produced by the shop for Skroutz and BestPrice. It is a photograph of the moment it was written.

  • Skroutz Products API

    Price and quantity changes that arrive without waiting for the next XML, for products already in the feed.

  • Google Merchant Center

    Data from a feed or an API, which Google compares with the product page and the checkout.

  • Marketplace orders

    Sales made outside the shop, which must reduce the ERP's stock like any other.

Eight places where the truth gets lost.

Errors in price and availability look random, but they recur in the same places. These are generic patterns that shop operators describe publicly, and they turn up in almost any setup that has grown through plugins.

  • A schedule slower than the sales

    The feed is rewritten every few hours, sales happen every few minutes. Whatever sells out in between keeps selling.

  • A file served from cache

    The server or plugin serves a stored XML. The job ran, but the platform reads the old one.

  • Variants with their own stock

    A common symptom: the size has sold out in the shop, yet the feed shows the product in stock, because it reads the parent product's stock.

  • Offers and dates

    Sale prices set in bulk or with dates do not reach the feed, or reach it and stay after they end.

  • VAT and rounding

    The ERP holds prices without VAT, the shop with VAT, and rounding happens in a different place. A one-cent difference is enough for a mismatch.

  • A feed that comes out half-built

    Automatic generation stops midway, on a time or memory limit, and the file comes out with a few dozen products instead of thousands. Generated by hand, it is correct.

  • A plugin update

    A new version of the plugin that produces the feed changes fields, categories or images, and nobody knows until the first rejection.

  • Two systems writing stock

    Both the ERP and the shop change the same quantity. Whoever writes last wins, and Marketplace orders often never reach the ERP at all.

What each platform asks for, and what it does when you disagree.

Google asks that the price, sale price and availability in your data match the page, the structured data and the checkout, with VAT included in Europe. When it finds a difference, the product may be disapproved, and many differences can lead to the account being suspended. Once fixed, Google re-checks the page by itself.

Skroutz asks for a price with VAT, the same for everyone, and a quantity of 0 for whatever has sold out. Availability uses its own values, from “In stock” to “Available up to 12 days”, and for products with sizes the quantity is the sum of the sizes available. Marketplace orders arrive automatically, and if something is missing you reject the line through the API, stating how many you have.

Then there is the law. When you show a discount, the previous price is the lowest of the last 30 days. If the feed takes its “was” price from somewhere other than the shop, the same offer can be correct in one shop window and misleading in another.

  • Google: a price that differs

    The product may be disapproved. A common cause, according to Google: the delay between a change in the shop and the update in Merchant Center.

  • Google: availability that differs

    The product is disapproved until the two agree. Too many such products can bring an account suspension.

  • Google: a sale price without dates

    If no effective period is given, the sale price always applies. The offer that ended in the shop carries on in the feed.

  • Google: automatic item updates

    On by default, they correct price and availability from the page. A useful safety net, not a sync.

  • Skroutz: file and API

    The XML is rewritten at least once a day. Price and quantity change in between through the Products API.

  • Skroutz Marketplace: orders

    They arrive by webhook. If stock falls short, you reject the line and Skroutz reprocesses the order.

Every field has one owner, and every change leaves a trace.

The answer is not another plugin. It is a decision: for every field, which system is the source, and all the others only read. Stock usually belongs to the ERP, descriptions and photographs to the shop, offers to whichever system also holds their dates. When two systems write the same field, one of them will lose.

Then the transport. Whatever changes often, stock and price, travels as events: a sale or a delivery sends the change at once, through an API wherever the platform accepts one. Whatever changes rarely travels on a schedule. Every send is logged, retried if it fails, and alerts a person if it fails again.

And one check that trusts nobody: every day, a sample of codes is compared across ERP, shop, feed and platforms. If a new feed has far fewer products than the last one, it is not published and someone hears about it.

  • A source per field

    A table that says, for stock, price, offer, availability and codes, which system writes and which ones read.

  • One code everywhere

    Every product and every variant under the same code in ERP, shop, feed and platforms. Without it, no sync knows what to update.

  • Events for what changes often

    Stock and price arrive within minutes. The XML stays for the full catalogue.

  • Logs and retries

    Every change with its time, source and result. What failed is held and sent again, never lost silently.

  • A brake on half a feed

    If the product count drops sharply, the previous file is published and an alert goes out.

  • A daily reconciliation

    A sample of codes is compared at every point. Differences go to a person, not to a log nobody opens.

Before you fix the next error.

In this order, because each step rests on the one before.

  1. Draw the path: from which system to which one price, offers and stock travel, with what tool and how often.

  2. Give every field one source, and stop every second system that writes it.

  3. Check that every variant has its own code and its own stock at every point.

  4. Bring prices into one form: VAT included, rounded in one place, with their offers and dates.

  5. Send stock and prices as events or through an API, and keep the XML for the full catalogue, rewritten at least once a day.

  6. Bring Marketplace orders into the same system, so they reduce the ERP's stock.

  7. Add logging, retries, an alert to a person and a daily sample check across every channel.

You change one number. We carry it everywhere, correct.

We do not sell plugins and we do not replace your ERP. We connect the systems you already have through their interfaces, so price and stock have one source and reach every channel correctly, and whatever fails, someone hears about it.

  • Field mapping

    Every field from source to channel: stock, price, offer, VAT, availability, variants. Before anything changes.

  • One source per field

    We decide with you which system writes each field, and close off the double writes.

  • Sync with retries

    Events or a schedule, depending on the field and on what each system allows, with every change logged and every failure retried.

  • Feeds checked before they leave

    XML for Skroutz and BestPrice and data for Google, with a check on product count and fields before they are published.

  • A daily reconciliation

    A sample of codes is compared every day across shop, feed and channels. Differences reach a person as an alert.

  • Documentation and handover

    The field table, the flows and what to do when an alert arrives, written down and handed to your team.

Start with usPart of Systems & applications

What people ask once it has happened.

Usually because the XML was read before the change arrived: the feed is rewritten every few hours or served from cache, or the variant's stock does not reach the feed. Skroutz asks for a quantity of 0 for whatever has sold out and, for products with sizes, a quantity equal to the sum of the sizes available. For changes between XML runs there is the Products API.

Google visits the product page and compares it with the Merchant Center data. If the price, sale price or availability differ, the product may be disapproved, and many differences can bring an account suspension. The most common cause is the delay between a change in the shop and the update in Merchant Center. Once fixed, Google re-checks the page by itself.

Skroutz asks that a cached XML is regenerated at least once a day. For price and stock that is too little. The full catalogue can stay in the XML, while price and quantity changes are sent in between through the Products API, up to 500 products per request.

Usually because the offer was set in a way the feed plugin does not read, for example in bulk or with dates, or because the feed holds a different price from the one the page shows. On Google, if you give no effective period, the sale price always applies. And when you show a discount, the previous price must be the lowest of the last 30 days.

Through the interfaces (APIs) of the two systems. First we check what your ERP allows and define which system is the source for each field. Then stock and prices are sent on every change or on a schedule, with logging and retries, and the connection is tested on real cases, such as a variant selling out or an outage, before it goes live.

A common symptom: automatic generation stops midway, on a time limit, memory or a job that ran twice, while generating it by hand works. The platform reads half a file. The defence is a check before publishing: if the product count drops sharply, the previous file stays and an alert goes out.

With one stock for every channel. Marketplace orders arrive automatically by webhook and must enter the same system as the shop's orders, so they reduce the ERP's stock. If something is still missing, you reject only the missing line through the API, stating how many you have.