Inventory, Order & Warehouse Management: OMS / WMS

The most insidious cost for a business selling across multiple channels is that no one knows exactly where the stock is. A product showing one unit on Trendyol has actually been sold in the store, an order placed on your own site cannot be found in the warehouse, and the stock figure sent to Hepsiburada is left over from an Excel sheet two days old. The result: the same product is sold on two channels (over-selling), cancellation and return rates rise, and the marketplace performance score drops. On the warehouse side, the operation still runs on paper order slips and memory; staff know the shelves by heart, a new hire is lost for half a day, and on count day the chasm between physical and system stock surfaces. These two problems cannot be solved separately, because stock accuracy is fed by warehouse discipline and order orchestration is fed by stock accuracy. On the e-commerce and ERP side, this is exactly where we most often step in: building an order orchestration layer (OMS) that pools channel stock into a single pool together with a warehouse management layer (WMS) run on barcodes and handheld terminals.

Our Approach

On OMS/WMS projects our first recommendation is to separate the two layers conceptually but sit them on a single data model. The heart of order orchestration (OMS) is a single available-to-promise (ATP) stock pool: from physical stock we subtract quantity reserved on open orders and add inbound goods to compute the truly sellable count at any moment. We'd hold this pool on PostgreSQL with row-level locking, because the technical root of over-selling is almost always two orders reading the same stock at the same time and both deciding it is "available". We publish stock movements as events to Apache Kafka and push them to each channel (Trendyol, Hepsiburada, own site, store POS) with a separate consumer; so when one channel's API slows down, the others are not blocked.

The second decision is making channel integration idempotent and self-healing. Marketplace APIs apply rate limits, occasionally time out, and sometimes deliver the same webhook twice. So we process every order and every stock update with an idempotency key; we keep a short-lived deduplication layer on Redis so the same order does not enter the system twice. When a channel is unreachable for a few minutes, queued updates accumulate, and when the channel returns the latest state is pushed in one go; so the "my stock is not updated on the marketplace" problem closes automatically. Order states (received, reserved, picked, packed, shipped, delivered) are modelled in a single state machine; each channel maps to its own terminology, but internally one language is spoken.

The third layer is warehouse management (WMS) and physical discipline. We'd model the warehouse with PostgreSQL plus PostGIS in a zone/aisle/shelf/bin hierarchy; each location can carry capacity, product-type constraints, and temperature or shelf-life rules. The operation runs on a React Native app on Zebra or Honeywell handheld terminals: at goods-in the barcode is scanned and a put-away shelf is suggested, during picking the shortest walking route is computed (pick path optimisation), during packing the lines are re-scanned to verify the carton. For products without a barcode we print our own internal SKU/SSCC barcode at goods-in; in sectors needing lot and expiry tracking such as food, cosmetics, and pharma, we embed the FEFO (first-expired-first-out) rule into the picking logic.

The final layer is cycle counting, traceability, and reporting. Instead of a year-end full count we'd set up ABC-based cycle counting; the system generates count tasks more often for fast-moving products and locks any discrepant location to open a recount. All movements (goods-in, transfer, picking, shipment, count adjustment) are written to an immutable movement ledger; the source of any stock discrepancy stays traceable. For management, a live operations panel (pending orders, shipments breaching SLA, staff efficiency, shelf occupancy) is delivered through a Next.js admin panel; shipping labels and product images live on S3 / Cloudflare R2, and error tracking on Sentry.

Our Preferred Technology Stack

We typically reach for the following, adapted per project to your channel count, warehouse size, and SKU volume.