Skip to content

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.

Sales order and invoice linkage

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.


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
  1. Create and review the SO.
  2. Click Scan IMEIs. Odoo confirms the SO if necessary and creates/reopens its Delivery Manifest.
  3. Scan the exact physical IMEIs.
  4. Click Finish IMEI Scan, review the confirmation, then click Complete Delivery.
  5. 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.

completed SO with Invoices and IMEI Manifest smart buttons


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
  1. Create and confirm the SO with the correct device requirements.
  2. Use Odoo's Create Invoice action from that SO. Do not start in a blank invoice.
  3. Review the draft/posted invoice through the SO's Invoices smart button.
  4. Return to the same SO and use Scan IMEIs.
  5. 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.

Create Invoice from confirmed SO and resulting Invoices smart button


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:

  1. collects customer and device requirements;
  2. creates an internal device sales order;
  3. confirms that sales order and creates its Delivery Manifest;
  4. creates and posts the customer invoice; and
  5. 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.

customer, As Received default, optional Color/Grade/Lock, and Create Linked Order & Post Invoice action

posted invoice with Sale Orders, IMEI Manifest, fulfillment status, and payment state


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:

  1. open that invoice;
  2. click Create Linked IMEI Fulfillment once;
  3. 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;
  4. confirm the wizard; and
  5. 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.

device-only invoice and one-time Create Linked IMEI Fulfillment rescue action

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:

direct-invoice rescue wizard with locked commercial values and editable IMEI requirements


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.

invoice-side Sale Orders, IMEI Manifest, Devices, and matching link message


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.