Skip to main content

The Megaventory integration overview

How the Smeetz and Megaventory integration works: the entities on each side, how they relate, multi-location setup with Sales Collections, and how sales, cancellations and taxes flow between the two systems.

This article is only visible to the Smeetz team.

This article explains how the Smeetz and Megaventory integration works: the entities on each side, how they relate to each other, and how to set up multi-location selling. It is written for technical implementation managers and support teams.


1. What the integration does

Megaventory is the source of truth for inventory. Smeetz is the selling layer. The integration works on three levels:

  1. Product synchronization: products created in Megaventory are mirrored as items in Smeetz.

  2. Availability synchronization: stock adjustments in Megaventory reflect in Smeetz within seconds. A reconciliation job also pulls updates automatically as a safety net.

  3. Sales and cancellation flows: every sale in Smeetz deducts stock from the right warehouse in Megaventory. Cancellations and refunds restore it.

Stock alerts and minimum reorder quantities are managed in Megaventory, not in Smeetz.


2. Entities and how they relate

Smeetz has no native location concept. To mirror a multi-warehouse Megaventory account, one Smeetz item is created per product and per warehouse. Everything else follows from that rule.

MEGAVENTORY (inventory master)          SMEETZ (selling layer)

+---------------+ mirrored as one +----------------------+
| Product (SKU) |---- item per synced ->| Item |
+-------+-------+ warehouse | (1 per SKU+warehouse)|
| +-----+----------+-----+
| stock held | |
v per warehouse bound to 1 | | added to
+---------------------+ warehouse | |
| Inventory Location |<--------------------+ |
| Shop 1 / Store / | +-------v----------+
| Main ... | | Sales Collection |
+---------+-----------+ | (1 per shop) |
^ +--------+---------+
| deducts / restores | assigned
| stock v to POS
+---------+------------+ +------------------+
| Documents: | 1 Goods Outbound | POS (per shop) |
| Goods Outbound / |<--- per sale line ----- | shows only its |
| Goods Inbound | (tax rate passed as | shop's items |
+----------------------+ DocumentRowTaxID) +------------------+

Relations at a glance:

Relation

Cardinality

Meaning

Megaventory Product to Inventory Location

1 to many

One product holds a separate stock level in each warehouse.

Megaventory Product to Smeetz Item

1 to many

The product is mirrored once per synced warehouse. The pair (SKU + warehouse) identifies the item.

Smeetz Item to Inventory Location

many to 1

Each item is bound to exactly one warehouse. Its stock quantity in Smeetz is that warehouse's stock.

Smeetz Item to Sales Collection

many to many

Items are added to Sales Collections. Convention: one collection per shop, containing that shop's items.

Sales Collection to POS

1 to 1

Each POS uses its shop's collection, so it only displays and sells that warehouse's inventory.

Smeetz sale line to Megaventory document

1 to 1

A sale creates a Goods Outbound at the item's bound warehouse. Cancellations and refunds create the reverse at the same warehouse.


3. Multi-location setup

📌 How to access: app.smeetz.com > Account details > Inventory integration

Step 1 - Enable the integration. The page shows the provider (Megaventory), the API key (only the last digits are displayed), the last sync time and a Stock sync enabled toggle.

Step 2 - Pick the warehouses to keep in sync. The first warehouse you pick becomes the default warehouse: it is used for sales that cannot be tied to another warehouse.

Step 3 - Sync the catalogue. Each Megaventory product arrives as one Smeetz item per synced warehouse.

Step 4 - Create one Sales Collection per shop and add that shop's items under Retail products. The dropdown groups items by warehouse name, and each group has a Select all link to add the whole location in one click (and Unselect all to remove it).

Step 5 - Assign each collection to the shop's POS. The POS then only displays inventory of its own warehouse, while the back-office keeps visibility of all synced warehouses.

✅ You can verify the result in Catalogue > Retail Inventory: the list has a Warehouse column and shows one row per item and warehouse (plus an aggregate row without a warehouse), so you can see the stock of each location side by side.


4. Sales, cancellations and refunds

  • A POS sale deducts stock from the item's warehouse in Megaventory automatically. The cashier sees nothing new.

  • Scanning or selecting an item loads only the stock level of that POS's warehouse.

  • In Create a sale in the back-office, the Retail product dropdown shows the same grouping by warehouse, so the operator always knows which location's item they are selling.

  • The tax rate is a property of the sale, not the product. It is passed per sale line to Megaventory as DocumentRowTaxID on the Goods Outbound document.

  • Cancellations and refunds restore items to their original Megaventory warehouse, independently per line.


5. Taxes and product attributes

  • Product attributes, including the collection grouping, live on the Megaventory product. Nothing needs to be passed at sale time.

  • VAT mapping during product synchronization is not supported yet. Until the automated solution ships, tax settings need manual review per item.

  • Custom fields from Megaventory are currently stored in the item's long description in Smeetz. Keep custom field usage minimal to avoid mixing account setups.


6. Known limitations (September 2026)

  • VAT synchronization requires manual configuration per item for now.

  • Online sales can run through a separate channel (for example Shopify at Kunsthaus) and are out of scope of this integration.

  • Client training and onboarding on Megaventory itself is positioned as a billable service.


Related resources

  • SmeetzPedia entry: pages.smeetz.com/smeetzpedia/advanced-integrations/megaventory

  • PRD: Megaventory Inventory Integration (Notion)

Did this answer your question?