Integrations

Yes. Record and confirm the order here and allocate its stock as usual. Then, on the order, open More → Send to Shopify. QUOMODA shows what it will send: one Shopify order per stock location and delivery door, with the units allocated there that are not already shipped, on a pick or with Shopify, at your wholesale prices and with the customer's VAT. Send it, and the warehouse picks, packs and ships it in Shopify like any other order.

1. 1Stock: allocated units are reserved in Shopify as always. Once sent, the Shopify order holds them itself, so QUOMODA releases its reservation and nothing is held twice. The units stay allocated to the order here.
2. 2Shipping: when Shopify ships, the shipment arrives here by itself, with carrier and tracking. The order becomes shipped or partly shipped and your team is notified. QUOMODA does not take the stock off a second time; Shopify's count comes through the stock sync.
3. 3Paperwork: delivery note, packing list and invoice are made here from what shipped, exactly as for a shipment of your own.
4. 4Not your web shop: these orders are tagged *quomoda* in Shopify and never counted as web-shop sales in your dashboard or demand planning. Shopify sends the buyer no email, and payment shows as pending because you invoice from QUOMODA.

The order panel lists each Shopify order it became, with a link to it in Shopify. Check reads it back from Shopify if a shipment has not arrived yet. Cancel cancels and restocks it in Shopify while nothing has shipped, and the units return to reserved. An order cancelled in Shopify does the same by itself. In Fulfilment, units with Shopify show as *With Shopify* and cannot be picked here.

QUOMODA has a native Shopify integration for syncing products, variants, prices, images, and inventory, a Resourced (PLM) catalogue import, Fortnox and Xero for accounting, and UPS for shipping labels and rates. More integrations are being developed.

Yes, both ways. A description imported from Shopify — by a sync or by the store's own update notification — is kept as the store's HTML: paragraphs, bold, lists. The product page edits it as rich text. Pushing it back sends that HTML unchanged, and a plain-text description (from a CSV, Resourced or an AI suggestion) has its blank lines turned into paragraphs so it does not arrive as one block. Earlier the store's update notification flattened descriptions to plain text on the way in — four seconds after every push, since Shopify notifies about the change the push just made — and the next push sent the flattened text back to the store. If a store has descriptions that lost their paragraphs that way, select the products and use Sync with only Description ticked to send the formatted ones again.

Ask for it. Under Shipping on the Integrations page, FedEx and DHL Express show Request integration rather than a credentials form. Press it, add anything useful — your account number, the services you ship with, roughly how many parcels a month — and send.

The QUOMODA team is emailed and notified straight away, and comes back to you to set it up with your account. The card then reads *Requested on* the date you asked.

A duplicate means one product holds two records for the same SKU that describe the SAME article — same size, same colourway, same name — usually after a product was deleted and re-imported in Shopify, so its stock is split and totals disagree. The sync now re-links re-imported variants instead of creating duplicates, and if any exist you'll see an amber "duplicate SKUs" card on the Integrations page. Open Review & merge, pick which record to keep per SKU (the Shopify-linked one is pre-selected), and the other's stock, orders and history fold into it — Shopify is re-synced automatically.

Because they are not duplicates. If two records share a SKU but differ in size, colourway or name — the same skirt in wool and in cupro, say, or one code covering XS, S and M — then both articles are real, separately stocked, and separately sold. Merging would delete one of them for good. QUOMODA lists these under "used by more than one article" on the Integrations page and deliberately gives them no merge button. Nothing is broken in QUOMODA, but a code that means two garments will confuse a warehouse and any barcode scan, so it is worth giving them distinct SKUs in your store.

1. 1In Shopify, create a custom app: Settings → Apps → Develop apps → Build apps.
2. 2On the app's API access page, grant these Admin API scopes — products: read_products, write_products; stock: read_inventory, write_inventory, read_locations; orders: read_orders, write_orders; fulfilment: read_fulfillments, read_merchant_managed_fulfillment_orders, write_merchant_managed_fulfillment_orders; markets: read_markets, write_products. Then Release (not Save).
3. 3Install the app on your store. Orders count as customer data in Shopify; a custom app on your own store gets that access automatically with this install, so there is nothing to request.
4. 4Copy the app's Client ID and Client secret.
5. 5In QUOMODA go to Integrations → Connect Shopify and paste them in.
6. 6Run your first full sync from the integration card. This imports your catalogue, maps your variants and locations, and switches on the live webhooks.
7. 7Open ⋯ → Markets & prices and choose which price list is your store's own prices (required), and which prices each Shopify market. Until the store prices are mapped, the sync holds prices: products and stock still come in.

The custom app is the only way to connect a new store for now. A one-click QUOMODA app on the Shopify App Store is waiting for Shopify's approval; until it is listed, there is nothing to install from the App Store.

Yes. Click the Shopify card on Integrations to open its panel: the connection, every data flow in both directions, the catalogue mapping, markets & prices and the latest activity, all in one place.

Under Data flows each flow has its own switch. Shopify → QUOMODA: product changes, stock levels, web-shop and POS sales, shipments of orders sent to Shopify, and prices. QUOMODA → Shopify: stock levels, wholesale reservations, and price switches by retail date. Pushing products, sending orders for fulfilment and pushing market prices stay on request.

Click its card on Integrations (or Open settings on it). Every connected integration opens the same wide panel: who it is connected to and its state, what needs doing, every data flow in each direction with when it runs, the settings that shape it, and the latest activity.

Shopify: a switch per flow, in both directions, plus catalogue mapping and markets & prices.

Resourced: live article changes (with a switch to pause them) and the catalogue import; What Resourced may write shows which fields a sync or a live change may overwrite. Nothing ever goes from QUOMODA to Resourced.

UPS, FedEx, DHL: rates, labels and label cancelling (all from a shipment) and tracking coming back, with a Use this account switch and the account's recent shipments.

Revolut Business: incoming payments every 30 minutes, the switch that records exact matches on invoices, and the payments still waiting for you. QUOMODA can never pay or move money.

Currency rates: your saved rates next to today's European Central Bank rates, and Take today's rates to use them. Nothing changes on a schedule.

Fortnox and Xero: what can be posted (on request, from the document), what blocks posting, the mapping and what was posted. Nothing comes back from the ledger.

Yes, two ways, both in the Resourced panel on Integrations.

Choose fields under *What Resourced may write*: untick what you maintain in QUOMODA (prices, descriptions, images…). Save choice stores it without importing anything. It governs every sync and every live change from the webhook; an unticked field is never written, and never blanked.

Live article changes under *Data flows*: switch it off and changes Resourced sends are acknowledged and ignored. The Sync button still works when you want it.

A value you lock on a product is never overwritten by either, whatever the field choice.

In the integration's field mapping window, opened from the integration panel. For each of QUOMODA's three levels you pick the source: Resourced's hierarchy level 1, 2 or 3, or Shopify's *Type* or its standard category — or leave the level empty.

The window reads your own catalogue as it opens, so you choose with your values in front of you: under each level it lists what the chosen source holds and how many styles use each value, and a table shows real styles filed exactly as the next sync would file them. Change a level and the table follows.

Nothing changes until you Save mapping, and then only on the next sync.

Into the price list of the season they belong to. Resourced prices an article per season — a wholesale and a retail price, each in a currency — and every season's figures go into that season's price list in the same currency. That is the list the price calendar uses for the season: B2B orders during its order window, retail and Shopify by the list's retail dates. Nothing is converted between currencies.

A season with no list in that currency keeps its prices waiting instead of putting them somewhere they would be wrong. The article's current season also fills blanks in your season-less default list, which screens fall back to when a season has no list of its own.

A price changed in QUOMODA is never overwritten. QUOMODA remembers the last figure Resourced sent for each price: while the price still equals it, a new Resourced figure replaces it; once you change it, it is yours. A price you lock is never written either.

1. 1Open Integrations → Resourced and click Preview on *Sell prices*. It reads Resourced and shows, per season, what would be added, updated, is already the same, is kept because you changed it, and what is waiting for a list. Nothing is written.
2. 2For a season that is waiting, Create its list in one click, then set the list's retail dates in the price calendar.
3. 3Prices are written by Sync now with *Wholesale & retail* ticked, or by a live change from Resourced.

In QUOMODA, on the Integrations page. The Shopify card shows the connection status, the last sync, which live webhooks are registered and any missing permissions, with buttons to sync now, re-register webhooks, edit the connection or disconnect.

Stores connected through the older QUOMODA Shopify app also get the same card under Apps in the Shopify admin. Both act on one record, so they cannot disagree.

Products, variants, images, prices, and inventory levels sync between QUOMODA and Shopify. Wholesale orders stay in QUOMODA. With the read_orders scope, your consumer sales — e-commerce and retail/POS — also flow in as sell-out, split per channel and store, to power demand planning's velocity and reorder suggestions.

Live demo · loops

Q

QUOMODA

Products

Shopify

Allocated wholesale stock shows as reserved in Shopify

On the Shopify card open ⋯ → Markets & prices. It lists your store prices (each product's own price in Shopify) and every Shopify market with its currency. Each one takes one or more QUOMODA price lists in its currency: a list's RRP, or a regional RRP for a QUOMODA market in that currency.

1. 1Map the store prices first: it is required. Until it is set, a Shopify sync holds prices (products and stock still sync), and the card says so.
2. 2Map the markets you want QUOMODA to price. Leave the others empty: Shopify keeps converting them.
3. 3Press Push on a row (store prices: Push to every product), or Push all markets.

Prices go both ways. A sync reads Shopify's store prices and each mapped market's fixed prices into their lists; Push and a product's Sync to Shopify send QUOMODA's back, per size (the size's price, else its colourway's, else the product's). Only prices that changed are sent.

Demand planning's velocity, weeks-of-cover and reorder suggestions run on your own-channel sell-out — e-commerce and retail/POS sales (wholesale bookings don't trigger reorders). To feed them, your Shopify custom app needs the read_orders scope, installed on the store after it was released. From then on, new sales arrive automatically via webhooks — no reconnect needed.

To load past sales as well, open the Shopify card's ⋯ menu → Import sales history. It backfills recent e-commerce and POS orders into demand planning so velocity is meaningful from day one, and it's safe to re-run. Shopify shares the last 60 days of orders; older ones need the read_all_orders scope, which Shopify has to approve for the app before it can be added.

QUOMODA works out which of your Shopify options separates one article from another by looking for one called Colour. If your styles vary by something else — fabric, material, finish, wash — no option matches, and every variant arrives with that field empty. Three sizes in two fabrics then land as three articles that cannot be told apart, which is what looks like a duplicate.

Tell it which option to use: on the Shopify card choose ⋯ → Variant axis. It reads the option names straight out of your store and shows a few real values under each, so you can point at the right one rather than guess.

1. 1Pick the option that separates your articles — Fabric, say — as the colourway axis.
2. 2Confirm the size axis, if it is called something other than Size.
3. 3Set what you want the field to be called in QUOMODA. It follows through to the products table, order forms, linesheets and printed documents.
4. 4Run a sync. Products already imported are filled in as well — nothing has to be re-created.

As pairs. A Shopify product with a Waist and a Length option (or W / L, Inseam, Leg) gets sizes like 28/32, and one with only a waist, such as shorts, gets the waist on its own. Before, those products arrived with no size at all, so every row showed an empty size box.

A sync also adds the size systems your store uses and you do not have yet, in Settings → Size systems: letters (S–3XL), plain numbers, a waist on its own, and a two-dimensional Waist × Length system with both axes kept. It only ever adds; a system you already have, or one that covers the same sizes, is left as it is.

On the product page, under Sizes & stock → SKUs, waist/length sizes are grouped by length (or by waist, if there are fewer waists), sorted, and each group shows how many sizes it holds and their stock. Waist and length are edited separately. + Add size opens on the system that fits the article and shows a waist × length grid: tap a cell to add one size, or a waist or length heading to add the whole row or column.

As one size with two halves, the way trousers have waist and length. A Shopify product with a Size option and a Fit option gets sizes like M/Slim and M/Regular — before, both came in as plain "M", two SKUs nobody could tell apart. A fit written with a bar, such as "Slim | Long", comes in as Slim Long.

A sync adds a Size × Fit system for it in Settings → Size systems, with the fits in the order your store lists them. On the product page the SKUs are grouped by fit, and each SKU's size and fit are picked from that system.

In a grid. On the card and on the product page, a two-axis run is laid out with one axis across the top (waist, or size) and the other down the side (length, or fit), with a quantity box in every combination you make. A combination you do not make shows as an empty cell, not a missing column, and the product page totals each row.

When the linesheet sells from stock, the product page shows what is left under each box and the card says how many sizes are in stock. The PDF prints the run by its axes — "Waist 28–36 × Length 30–34" — rather than listing every pair.

Orders work the same way on your side: on an order, when you build one from a linesheet, and when you add products by hand, a two-axis article takes one row per length (or fit) with the waists (or sizes) across — each row tagged "Length 32" or "Fit Slim". The linesheet editor previews the card as buyers will see it.

Yes. QUOMODA pushes product, price and stock changes to Shopify as you make them, and Shopify pushes product and inventory changes back via webhooks — so both stay in step automatically, without a manual sync each time.

It depends on the integration, so the answer is different for each one:

Shopify — no, we create them. The live link runs on webhooks, and we register them for you on your first full sync. Connecting alone does not create them. They cover products (create / update / delete), inventory levels, and orders (which feed sales velocity in demand planning).

Resourced — yes, you create it. The webhook lives in Resourced and only you can add it. Connecting gets you the Sync button; without the webhook, Resourced changes arrive only when you press Sync. On the Resourced card choose ⋯ → Real-time webhook (or Set up webhook in its panel) to get the URL, username and key, then paste them into Resourced under Settings → Webhooks → Add webhook (Method POST, with *Include resource* and *Enabled* on). Live changes can be paused from the panel at any time.

Yes — QUOMODA connects to Fortnox and Xero, so your accountant stops re-keying invoices by hand. There is no single accounting system across Europe, so the connector is built to take more of them: each one is a separate connection you authorise from Integrations → Accounting.

A connection belongs to a brand, not to your workspace. An agency running six brands connects six ledgers, one per brand, and they never see each other's documents.

Only what an accountant needs. The ledger gets your books, not your catalogue.

1. 1Customers — the wholesale accounts your invoices point at.
2. 2Invoices you have issued (sent, part-paid or paid). Drafts and cancelled documents stay put.
3. 3Credit notes, linked to the invoice they credit.
4. 4Payments you record in QUOMODA, against those invoices.
5. 5Proformas — only if you switch them on, and never as a booked document.

Never sent: products, variants, stock, locations, allocations, linesheets, selections, and any order that has not been invoiced. Pushing your articles into an accounting system would give you a second product master that immediately starts drifting from the real one.

Because nothing about tax or bookkeeping may be guessed. A new connection sits at Not mapped and refuses to run until you have filled in and confirmed the mapping — that is the whole point of the step, not a formality.

1. 1Tax codes — for every VAT rate you actually invoice at, pick the code your ledger uses. Xero publishes its own list and QUOMODA reads it live; Fortnox publishes none, so you type the code your accountant uses.
2. 2Chart of accounts — which revenue account, which receivables account, and (if you post approved invoices) which bank account payments land in.
3. 3Confirm — each row records who confirmed it and when. Editing any row un-confirms the connection and you re-confirm before the next run.
4. 4Dry run — builds every document and resolves every code without writing a single thing to your ledger. Do this before the first real sync.

Because accounting systems do not let a booked invoice be edited, and neither will we. Before every update QUOMODA reads the document back and checks its state:

1. 1Not booked yet — the change is pushed normally.
2. 2Already booked, approved or in a closed period — the document is blocked, with a sentence naming the ledger's own number so you can find it.
3. 3Part-paid or paid — amounts, quantities and tax are frozen. QUOMODA will still push the harmless header fields (reference, due date, number, link back), but if the total no longer matches it blocks instead.
4. 4Voided or deleted in the ledger — the link is closed and QUOMODA never writes to that document again.

Credit notes work differently per system. Xero takes a standalone credit note, which you then apply to the invoice yourself in Xero. Fortnox models a credit as an operation on the invoice it credits, so it must be linked to that invoice and must credit it in full — a partial credit cannot be sent to Fortnox.

Yes. Every document QUOMODA has pushed is recorded against the remote document it became, and that record is consulted before anything is sent — so a second run updates or skips, it never creates a second invoice. A document QUOMODA has not changed since the last run is reported as Unchanged and costs no call at all.

If a run is interrupted halfway, the next one looks your documents up in the ledger by the reference QUOMODA stamped on them before creating a duplicate.

Draft is the safe default and what a first connection should use: documents arrive unbooked, they create no journals and appear in no report, and your accountant approves them in their own system. Approved posts them straight to the ledger.

Proformas are always pushed unbooked, whatever this setting says — a proforma is not a tax document and must never create a receivable. They are off by default; if you switch them on, be aware that anyone can approve one inside the accounting system afterwards and turn it into a real invoice.

Whichever you choose — and both numbers are always stored and shown together. You can push QUOMODA's number, or let the ledger assign its own (Fortnox always assigns its own; Xero lets you pick).

The run history shows the pair for every document, because without it reconciling your QUOMODA invoice list against your accountant's is guesswork.

QUOMODA sends the document currency and the document amounts, and lets your accounting system apply its own exchange rate. It never sends, computes or invents a rate — an inverted FX rate misstates revenue, and your ledger already knows the rate it wants to book at.

Every press of Post is recorded against that document, with the accounting system's own words kept verbatim. The vocabulary matters:

1. 1Created / Updated — it reached the ledger.
2. 2Unchanged — nothing has changed since it was last posted, so nothing was sent.
3. 3Blocked — QUOMODA stopped on purpose and you need to act: a mapping is missing, the remote document is booked, or the customer or supplier has no VAT treatment set. It is not an error and it is never a silent skip.
4. 4Rejected — the ledger refused the document. The reason is shown exactly as it came back, and pressing Post again will not help until the underlying data is corrected.
5. 5Skipped — the document cannot be posted as it stands: a draft, or one that has been cancelled.

The tokens are deleted and QUOMODA stops pushing immediately — but the record of what already reached your ledger is kept. That record is what stops a later reconnect from re-creating every invoice you already have in your books, so it is never deleted.

If you only want to stop temporarily, use Pause instead: it keeps the connection, the mapping and the record intact.