Fawran’s receiving process is scan-driven: what isn’t labeled can’t be scanned, and what can’t be scanned can’t be received. That’s why the shipment wizard makes you print and then formally attest — tick a pledge — before it lets you submit.
When you must print
| Label | Print by when |
|---|---|
| Carton labels | Before handover — one on every box, in every shipment, always. |
| Shipment label | Before handover — attached visibly for the warehouse gate scan. |
Unit (FWU) labels — only under SELLER_PRINTS | After allocation, before handover — one unique label per physical unit. |
Unit (FWU) labels — under FAWRAN_PRINTS | Never. The warehouse prints and attaches them during receiving; attaching your own creates identity conflicts. |
The attestations, word for word
At step 4 of the shipment wizard you confirm with checkboxes — these are the exact on-screen pledges:
- Carton labels (always required): «أتعهّد بطباعة وإلصاق جميع ملصقات الكراتين على كل صندوق قبل تسليم الشحنة.» — I pledge to print and attach all carton labels to every box before handing over the shipment.
- Unit labels (only when you chose
SELLER_PRINTS): «أتعهّد بطباعة وإلصاق جميع ملصقات الوحدات (FWU) على كل وحدة قبل تسليم الشحنة.» — I pledge to print and attach all unit (FWU) labels to every unit before handing over the shipment.
Until every applicable pledge is ticked, the pre-dispatch checklist stays «غير مكتملة» and Confirm shipment remains disabled.
Why the platform requires this
The attestation is your formal statement that the physical goods match the digital declaration. Receiving is built on it: the captain and warehouse scan what you attached, and every discrepancy between pledge and reality costs real time — yours included. It also makes responsibility unambiguous when a shipment arrives unlabeled.
If you skip printing
- Unlabeled cartons can’t be checked in box-by-box — receiving is delayed while the warehouse identifies contents manually, and discrepancies open issue cases.
- Unlabeled units under
SELLER_PRINTSfail the receiving scan — the shipment stalls until labels are sorted out, and problem units are split into cases. - Units under
FAWRAN_PRINTSexist asUNPRINTEDuntil the warehouse prints, attaches and scans their labels at arrival — warehouse scans rejectUNPRINTEDunits until that’s done. That’s the platform doing its job; your only duty in this mode is the cartons.
Ticking the pledge "to get past the button" and printing later. If the captain arrives before you print, the handover fails or the shipment arrives unlabeled — both end in delays and cases against your shipment.
Reprints and the audit log
Labels can be reprinted from the Barcode Center, but a reprint always requires a reason (the app prompts «سبب إعادة طباعة ملصقات الوحدات:» or «سبب إعادة طباعة ملصقات الكراتين:»). Crucially, a reprint reuses the same barcodes — no new identities are minted, so a damaged label can be replaced without breaking the unit’s history.
Every generation and reprint is recorded in the Barcode Center’s label-jobs history («سجل توليد وإعادة طباعة الملصقات»): shipment, label kind, count, reprint sequence, reason, who and when. Repeated reprints of the same labels are visibly flagged.
Reprint only for real reasons — a smudged sheet, a torn label. The audit trail is visible to the platform, and clean print discipline keeps your receiving fast.