Sales Order & Customer Invoice Linkage¶
The sales order, customer invoice, and Delivery Manifest should be one connected chain. Users do not manually type a sales-order number into an unrelated invoice to imitate a link.
What each document controls¶
| Document | Controls |
|---|---|
| Sales Order (SO) | Customer promise, quantities, prices, and fulfillment requirements |
| Delivery Manifest | Exact inventory IMEIs scanned for that SO |
| Customer Invoice | Amount billed, posting state, and payment |
The exact IMEIs come from fulfillment. The invoice quantities and prices come from the sales order/invoice lines.
Lane 1 — SO-first default (recommended)¶
Use this unless the business specifically needs an invoice before fulfillment.
Create SO → Scan IMEIs → Finish IMEI Scan → Complete Delivery
→ Odoo creates/posts the Customer Invoice
- Create and review the SO.
- Click Scan IMEIs. Odoo confirms the SO if necessary and creates/reopens its Delivery Manifest.
- Scan the exact physical IMEIs.
- Click Finish IMEI Scan, review the confirmation, then click Complete Delivery.
- Odoo creates and posts the invoice from that SO, then links it to the SO and manifest.
No customer prepayment is required by this normal sale-first lane.
Lane 2 — SO-first with an early invoice¶
Use this when accounting wants the invoice before the phones ship, but the transaction is still a normal SO-first sale rather than the prepaid invoice-first workflow.
Create/confirm SO → Create Invoice from that SO → scan and complete delivery
→ Odoo posts existing billing and invoices only any remainder
- Create and confirm the SO with the correct device requirements.
- Use Odoo's Create Invoice action from that SO. Do not start in a blank invoice.
- Review the draft/posted invoice through the SO's Invoices smart button.
- Return to the same SO and use Scan IMEIs.
- At delivery completion, Odoo finds the existing non-cancelled customer invoice and posts it if still draft. If the SO quantity increased after a partial invoice, Odoo creates a remainder invoice only for the uninvoiced quantity. It never bills the already invoiced units twice.
Creating an invoice early from a normal SO does not by itself convert the order into the New Prepaid Device Invoice lane or add its payment gate.
Lane 3 — New Prepaid Device Invoice¶
Use this only when the invoice must be posted and fully paid before exact IMEIs can be fulfilled.
Open Invoicing → Customers → New Prepaid Device Invoice, enter the customer and device promise, review every row, and click Create Linked Order & Post Invoice. That single controlled action:
- collects customer and device requirements;
- creates an internal device sales order;
- confirms that sales order and creates its Delivery Manifest;
- creates and posts the customer invoice; and
- links all three records automatically.
Register full customer payment. Then open the linked Sale Orders from the invoice and click Scan IMEIs. Exact IMEI allocation and final shipment remain payment-gated for this lane.
The wizard defaults Selling As to As Received, so a prepaid sale of newly received supplier-grade phones can preserve its intake evidence. Color, Grade, and Lock are optional promises: set only what the customer was actually promised. Change Selling As to Reyder QC Verified only when Reyder completed QC and is making that verified promise.
Direct invoice rescue — Create Linked IMEI Fulfillment once¶
Sometimes a customer invoice was created directly in Invoicing instead of through one of the three lanes. This is an exception, not the normal workflow.
If it is a genuine device invoice and has no fulfillment SO:
- open that invoice;
- click Create Linked IMEI Fulfillment once;
- set the fulfillment requirements for every positive device invoice line: storage and Selling As, plus optional grade, color, and lock promises. Product, quantity, price, and taxes stay locked to the posted commercial invoice;
- confirm the wizard; and
- let Odoo create and link the internal SO and Delivery Manifest.
The rescued invoice becomes an invoice-first fulfillment and must meet the payment gate before scanning. Do not manually create a second SO and do not click Create Linked IMEI Fulfillment twice.
On a mixed invoice, the rescue covers every positive device line and leaves service or other non-device lines on the invoice only; those non-device rows do not become IMEI requirements. If any device line is missing from the wizard, commercial values differ, the invoice is already linked, or the action is not appropriate, Odoo blocks the rescue.
The rescue wizard shows the invoice-owned values as locked and asks only for the IMEI matching promises that were not present on the invoice:
How to prove the link¶
From the sales order¶
- Invoices opens the customer invoice(s) created from its lines.
- IMEI Manifest opens its Delivery Manifest.
- The customer, quantities, and prices should match the commercial record.
From the customer invoice¶
- Sale Orders opens the linked fulfillment SO(s) when applicable.
- IMEI Manifest opens the related Delivery Manifest.
- Invoice Origin/reference may describe the SO, but it is not proof of linkage. The Sale Orders smart button/native sale-line relationship is authoritative.
- Fulfillment status shows whether inventory is pending, partially picked, ready, or shipped for invoice-first records.
Never do these¶
- Do not create a second invoice because an IMEI is rejected.
- Do not create a second SO because the invoice already exists.
- Do not type an SO number only in free text and assume it creates relational linkage.
- Do not cancel/recreate posted accounting documents without accounting approval.
- Do not weaken storage, condition, grade, color, or lock promises to make fulfillment pass.
Common questions¶
When is the invoice created on the default path?
At Complete Delivery, after the Finish IMEI Scan review. Confirmation alone creates the Delivery Manifest, not the default customer invoice.
What if the SO already has an invoice?
Open it from Invoices. Delivery completion posts valid draft billing from that SO and, only when necessary, creates an invoice for the uninvoiced remainder. It never duplicates quantities already billed.
Does an early SO invoice require payment before scanning?
Not merely because it was created early. The special payment gate belongs to the New Prepaid Device Invoice/direct-rescue invoice-first lane.
How did the invoice and SO become linked?
SO-created invoices inherit the standard sale-line relationship. The device workflows also record the fulfillment SO/origin so the invoice and Delivery Manifest smart buttons can navigate back to the same chain.






