The ExchangeRate field is where this whole system lives or dies. Not the order status. Not the customer name. The rate — because when you're clearing Shein orders from Saudi Arabia into Yemen, a 50-rial swing per SAR on 40 open orders can flip a profitable week into a wash.
When the Numbers Stop Adding Up at Closing Time
Cross-border purchasing agencies operating in the Yemeni market face a structural data problem that spreadsheets never solve cleanly. You've got customers ordering through Shein. Other customers ordering through Noon, AliExpress, or direct retailer carts. Each order was priced in SAR on the day it was placed. But your customer pays in YER, at whatever the street rate is today, which is not what it was when the order shipped from Riyadh.
If you're running this on WhatsApp threads and a notebook, you find out about the discrepancy when the customer is standing at your counter, and you're doing math in your head while three other people are waiting. That's the point of failure this template was built to eliminate.
The CustomerBalanceYER field is a calculated field that aggregates across two separate order pipelines — CustomerTotalDueYER (Shein orders) and CustomerTotalDueOtherYER (all other platforms) — then subtracts whatever has already been paid to the office from either stream. One number. One field. Every customer's live balance when they walk through the door.
The Architecture Behind Two Parallel Order Pipelines
The template separates Shein orders from other-platform orders not as a cosmetic distinction but because the fee structures differ. The "طلبيات العملاء" (Shein orders) library is simpler: you enter Total_SR, the current ExchangeRate, and the system calculates Total_YR automatically as Total_SR × ExchangeRate. Payment in YER is recorded in Paid_YR, and RemainingYER updates immediately.
The "طلب مواقع أخرى" (other sites orders) library adds two additional SAR fields: LocalShippingFee (domestic Saudi shipping, typically handled by a local forwarder in Jeddah or Riyadh) and ShippingFee (international leg, Yemen-bound). These are summed into TotalSAR before the exchange rate multiplication. The granularity matters — customers dispute shipping fees more than product costs, and having both line items in the record ends the argument.
The CreatedBy choice field, tagged A, M, or 1R, is the agent identifier. Multiple staff can process orders, and the CustomerID is generated as "CU-" + CreatedBy + "-" + ID, so every record carries the originating agent embedded in the identifier. At reconciliation, you can filter by agent and see who's carrying the most open receivables without running a separate report.
What the Checkout Module Shows at Scale
The "تسجيل خروج من المكتب" (office checkout) library is where the day closes. It runs aggregate lookups across both pipelines: TotalRemaining and TotalRemainingOtherSites combine into TotalRemainingBalance, and TotalCashToOffice plus CashToOfficeOtherSites gives you TotalCashReceived. The ReceivingStatus field moves from "قيد التنفيذ" (in progress) through "تحت المراجعة" (under review) to "تم التصفية" (settled).
At 1,000 customer records with an average of 3–4 active orders each, the daily checkout entry becomes the single most important record in the system. The ExitNote field carries any discrepancy annotations — a partial payment promised for Thursday, a package held at the border, a customer who paid in mixed currency. Without that field, the next agent who opens that checkout record has no context for why TotalRemainingBalance doesn't match the physical cash count.
The Photo field on checkout, and ReceiptImages on individual orders, mean that every disputed payment has a receipt scan attached. When a customer claims they paid, you open the record. Either the image is there or it isn't.