Overview
Two systems, one stock figure, and no agreement about it. That is the whole problem with selling online alongside an ERP. The storefront sells eight of something you have five of; the price you dropped this morning is still the old one on the website; and somebody spends the first hour of every day copying yesterday’s orders into the system by hand, introducing a wrong unit here and a mismatched address there.
Nama’s answer is deliberately narrow: it does not sell you a storefront. Nama has no cart, no checkout and no shop of its own — it connects the one you already run to the ERP behind it, in both directions.
What connects
Each storefront is configured as its own site record, so a business can run several — a Salla shop, a Magento site and a marketplace listing — against one inventory.
- Salla and Zid — the platforms most Saudi merchants actually sell on.
- Magento, both 1.x and 2.x, over REST or GraphQL.
- Shopify, WooCommerce and BigCommerce.
- Amazon, over the SP-API.
- OTO for logistics stock synchronisation, and Omniful when warehousing and fulfilment are outsourced to a 3PL.
- Anything else, through the same configurable APIs and webhooks the named platforms use.
What flows, and in which direction
Out to the store: items and their categories, the product settings that decide how each one is presented, prices — including a price-update document, so a repricing is a deliberate, reviewable action rather than a background job nobody can audit — and stock, at the level of each warehouse, so a store that ships from one branch does not sell the other branch’s shelf.
In from the store: orders, as real sales documents. The import carries the payment method — mapped to your own payment types, so a card sale and a cash-on-delivery sale post differently, as they should — the shipping method, the delivery fee and any other charge. Customers that do not exist yet can be created as they order.
Back out again: the order’s status as your operation moves it, so a customer watching their order online sees initial, in progress and delivered because that is what actually happened in the warehouse — along with any note or extra requirement recorded on the sales document.
Real-time updates arrive by webhook; the rest runs on a sync schedule, with an audit trail and error handling for the messages that fail, because an integration that silently drops an order is worse than no integration at all.
Amazon works differently, and it matters
Amazon will not push notifications to your ERP. The only place it agrees to deliver order events is an SQS queue in your own AWS account. So Nama polls that queue on a schedule, and every order Amazon marks as shipped is read fresh and becomes a sales order.
It is worth knowing before you plan the project: the queue is set up once in your AWS account, Nama is given three values so it can read it, and after that it runs. Anyone who tells you Amazon can post directly into an ERP has not built it.
What you actually gain
The point is not the sync. It is that an online order stops being a special case. Once it lands, it is an ordinary sales order in the same system as everything else: it reserves the same stock, it prices from the same price list, it is picked and delivered by the same documents, it posts the same ledger entry, and it becomes the same e-invoice your counter sales do.
Setting up a site, the item linker, price updates, the Amazon queue and the Omniful flows are documented in the e-commerce section.
