Workflow Map¶
Use this page to understand where each person, document, and automatic handoff belongs. It is a map—not a substitute for the detailed task guides.
One process, six records¶
| Record | Created from | Business question it answers |
|---|---|---|
| Purchase Order (PO) | Purchasing | What did Reyder order from the supplier? |
| Receiving Manifest | Confirmed device PO | Which exact IMEIs physically arrived? |
| Inventory Device / IMEI | Accepted receiving scan | What is known about this exact physical phone? |
| Sales Order (SO) | Sales or invoice-first automation | What did Reyder promise the customer? |
| Delivery Manifest | Confirmed device SO | Which exact inventory IMEIs are leaving? |
| Customer Invoice | SO fulfillment or invoice-first workflow | What was the customer billed, and has it been paid? |
The links are directional. A supplier IMEI file can populate a Receiving Manifest, but it is not an Odoo inventory receipt. A sales order can create a Delivery Manifest, but the phones are not sold until the outbound flow completes.
Human actions and automatic actions¶
| Stage | Person does | Odoo does automatically |
|---|---|---|
| Purchase | Enters and confirms the PO | Creates the Receiving Manifest |
| Receive | Chooses the correct scan mode and scans physical IMEIs | Creates inventory IMEI records and intake provenance |
| Condition | Chooses As Received or performs real Reyder QC | Preserves intake and verified results separately |
| Sell | Enters the customer promise on the SO | Creates/reopens the Delivery Manifest when scanning starts |
| Fulfill | Scans the physical IMEIs leaving and confirms completion | Allocates exact units, marks them sold, posts COGS, creates/reuses the linked invoice |
| Account | Reviews payment and linked documents | Keeps SO, invoice, manifest, and IMEI references connected |
The four control points¶
1. Before receiving¶
Decide whether an exact supplier IMEI list exists. This decision controls the scanner:
- known exact list → verify that list;
- no list → receive by PO row.
See Single Scan vs. Batch Scan.
2. Before selling¶
Decide whose condition claim is being sold:
- supplier/PO claim → As Received;
- Reyder's tested result → Reyder QC Verified.
See Quality Control & Selling As.
3. Before outbound scanning¶
Check the sales order describes only what was promised. Optional blank fields are not errors; they mean Any / not promised.
See Sales Orders.
4. Before delivery completion¶
The physical phones, accepted scan count, and order quantities must agree. Completion has inventory and accounting effects.
See Delivery Manifests.
Choose the correct sales and invoice lane¶
There are three supported lanes:
- SO-first default: create SO → scan → Finish IMEI Scan → Complete Delivery → Odoo creates/posts the linked invoice.
- SO-first with early invoice: create SO → create its invoice early from that SO → scan → Complete Delivery posts existing billing and invoices only any real remainder.
- New Prepaid Device Invoice: the wizard creates and links the invoice, internal SO, and Delivery Manifest → receive payment → scan.
A direct customer invoice created outside these lanes is a rescue case. Do not manually build a second SO; use Create Linked IMEI Fulfillment once.
See Sales Order & Invoice Linkage.
Where to stop¶
Stop instead of improvising when:
- the wrong company is active;
- an exact-list shipment contains an IMEI that is not on the list;
- the customer promise differs from the sales row;
- a red outbound scan appears;
- the invoice and SO cannot be opened from each other; or
- the physical count differs from Odoo.
Use Troubleshooting and provide the PO/SO/invoice reference plus the exact message.