Leading ERPNext Implementation Company

Orders arrive from three very different places and have to end up in one queue, in one shape, with nothing counted twice.

Inbound webhooks per store. Each storefront posts to its own endpoint. The raw payload is written to a log table before anything is parsed, so a malformed order can always be read back or replayed.

Free-text WhatsApp parsing. Manual WhatsApp messages run through a Unicode-safe key/value parser that pulls out reference number, customer name and number, product SKU and quantity, address, COD amount and store code.

Phone normalisation. Customer numbers are normalised to Saudi format on arrival, so the same customer is recognised however the number was typed.

Store scoping from the session. For store-scoped users the store code is read from the signed-in profile, never from the request body — an agent cannot push an order into another store.

No double handling. Live unconfirmed orders are filtered against what is already assigned locally, so the same order cannot be handed to two agents.

The panel exists because someone has to phone the customer. Everything about that call is recorded.

Status flow. Unassigned to assigned, then confirmed, cancelled or postponed. Withdrawal only applies while an order is still assigned — once it is confirmed or cancelled it cannot be pulled back.

Attempt log. Every call attempt is stored with its number, its result and the agent who made it.

Automatic triage. Two consecutive “no response” or “messaged” attempts move the order into its own tab, so unreachable customers stop clogging the live queue.

Postpone with a date. A postponed order carries the date it should come back, and a nightly job auto-confirms postponed orders whose date has arrived.

Full audit trail. Assign, withdraw, edit and status change each write an audit row — actor, action, entity and the fields that changed.

The failure that costs real money is a duplicate order. The guard here is structural, not a retry counter.

Claim before call. A row is claimed on a unique idempotency key before the outbound request is made. A replay finds the existing claim and stops.

The payload outlives the browser. The full order payload is stored with the claim, so an order that failed mid-flight can be replayed server-side long after the agent has closed the tab.

Sync is safe to press. Re-sending orders that never landed upstream is idempotent by construction — press it as many times as you like.

Non-retryable rejections. Business rejections such as an invalid city or product are flagged non-retryable, because replaying them cannot fix the problem.

Duplicate detection on intake. The same normalised phone number with the same SKU and quantity map inside a 24-hour window of a live order is detected and auto-cancelled.

Concurrency. Inserts run inside a lock, so two webhooks arriving in the same instant cannot both create the order.

Money leaving the business needs a different shape from money coming in, so refunds run on approval rather than on trust.

Two paths. Privileged roles create the refund order directly. Agents raise a request instead, which sits pending until an admin approves or rejects it.

Snapshot on the request. The request stores a snapshot of the original order, so approval builds the order from what was actually agreed, not from data that may have moved since.

Payment queue. Approved and unpaid refunds form a queue for whoever pays. Marking one paid is concurrency-safe, so the same refund cannot be paid twice.

Evidence attached. Payment proof — image or video, up to 25 MB — and bank details as PDF upload to object storage and are held against the refund.

Rules enforced at lookup. Finding the original order enforces store scoping and the delivered-status rule, so a refund cannot be raised against an order that is not eligible.

Everything audited. Request created, approved, rejected, paid and proof attached each write their own audit action.

The web host and the database host run their clocks in different zones. If “today” is read from either machine, the numbers are wrong.

One helper, everywhere. A single time helper resolves the Asia/Riyadh day. Nothing reads the machine clock directly.

Reports and KPIs. Dashboard counters, agent and admin reports and every date filter are anchored to the KSA day, not the server’s.

Imports. Orders imported in bulk have their dates anchored to the KSA day as they land.

Scheduled jobs. The nightly auto-confirmation runs at midnight KSA, pinned to Asia/Riyadh rather than to the host’s locale.

Inbound timestamps. Courier callback timestamps are normalised to the KSA zone on arrival, so a delivery never appears to have happened the day before.