Sealed As-Is Arbitrage¶
Purpose¶
Use Sealed As-Is Arbitrage when Reyder buys already-packed device cartons, does not open or inspect them, and resells those same physical cartons against an existing customer invoice.
This workflow records carton custody, not device verification:
- Reyder attests that an identified, intact carton physically arrived.
- A supplier IMEI manifest or declared count is retained only as a supplier declaration.
- Reyder does not attest that the supplier's IMEIs, models, grades, locks, quantities, or other declared contents are correct.
- No
stock.lot, serial/IMEI record, or IMEI stock quantity is created while the carton remains sealed. - The exact received carton is the fulfillment unit. It cannot be split, substituted, or partially shipped in the sealed workflow.
Use Standard IMEI Receipt whenever Reyder opens a carton, scans devices, performs QC, sells only part of a carton, or needs IMEI-level inventory truth.
Purchase Order-centered UX¶
The Purchase Order is the control center for the deal:
- Create or open the supplier Purchase Order.
- Set Receiving Mode to Sealed As-Is Arbitrage.
- Select Customer Invoice to Fulfill.
- Enter Expected Sealed Carton Count.
- Confirm that the PO device products and quantities exactly match the customer invoice.
- Optionally upload the supplier's original IMEI manifest and enter its supplier-declared count.
- Confirm the Purchase Order.
The selected invoice must be an existing, non-cancelled customer invoice in the same company. The PO must use positive device quantities, positive costs, and one individual device unit of measure per possible IMEI.
The supplier file is stored on the PO with its filename, SHA-256 fingerprint, upload time, and user. The linked Sales Order and customer invoice expose that same supplier-provided evidence through their sealed-deal links. This traceability does not import the file into inventory and does not make any row Reyder-verified. The supplier-declared count is also evidence only; the PO contract quantities drive carton allocation.
The supported relationship is deliberately one-to-one:
one Purchase Order ↔ one customer invoice ↔ one fulfillment Sales Order
What confirmation does¶
Confirming a valid sealed Purchase Order performs one controlled, retry-safe operation:
- locks and validates the selected customer invoice;
- checks company, customer, currency, document state, products, quantities, totals, and duplicate-link safeguards;
- reuses the invoice's single untouched, matching fulfillment Sales Order when one exists, otherwise creates and confirms it through the invoice-first fulfillment service;
- permanently links the Purchase Order, customer invoice, and Sales Order;
- creates the expected sealed carton records; and
- allocates PO quantity and company-currency cost across those cartons.
Confirmation does not create a receiving IMEI manifest, delivery IMEI manifest, IMEI/serial, or ordinary device stock quant while the sealed path is active.
Changing a field in the draft form is only preparation. Confirmation is the transaction that creates the linked fulfillment graph. After confirmation, the deal-defining fields are locked; do not change the vendor, customer invoice, company, currency, quantities, or receiving mode to work around an exception.
Receive intact cartons¶
From the Purchase Order, select Open Sealed Cartons. Warehouse staff may also use Device Ops → Receiving → Sealed As-Is Cartons.
For each expected carton:
- enter the supplier carton ID and physical seal ID when available;
- select the internal stock location;
- verify only that the physical carton is present and its seal is intact;
- select Receive Sealed Carton; and
- physically scan the supplier carton ID or physical seal ID in the required scan dialog.
The Reyder-generated internal barcode is never accepted as proof that a specific supplier carton physically arrived. At least one external identifier must be recorded and physically scanned. The receipt action records the scan, location, user, and timestamp. It posts the carton allocation:
- debit Device Inventory Valuation;
- credit Device Inventory Input.
It does not open the carton, inspect its contents, import supplier IMEIs, or claim that the allocated PO quantity is physically present inside.
If the seal is not intact, do not use Receive Sealed Carton. Record the physical exception using the correct action described below.
Ship the exact same cartons¶
Payment before shipment is a hard gate. Sealed cartons can ship only when:
- every active carton on the PO is in Received Sealed with an intact seal;
- each carton is the exact carton linked to the PO/SO/invoice deal;
- the linked fulfillment Sales Order is confirmed and billed only by the selected customer invoice;
- the selected invoice is posted and its payment status is Paid; and
- no carton was opened, marked damaged, cancelled, or previously shipped.
Select Ship Same Sealed Carton on any received carton. For a one-carton deal, scan that carton. For a multi-carton deal, the wizard lists the entire active batch:
- physically scan every carton exactly once;
- make each scan match the identity captured for that carton at receipt; and
- select Confirm Physical Scan only after the full batch is present.
Multi-carton shipment is atomic: one carton cannot ship independently, and no carton may be omitted or added. If any scan or business control fails, none of the cartons in that batch is marked shipped and no partial COGS posting is accepted.
A successful shipment records every scan, user, and timestamp and posts each carton's allocated cost:
- debit Device Cost of Goods Sold;
- credit Device Inventory Valuation.
Repeated receive or ship calls are blocked from posting the same accounting effect twice.
Choose the correct physical exception¶
Damage and opening are different facts. Record what warehouse staff actually observed; never use one action as a shortcut for the other.
Seal damaged, but Reyder did not open the carton¶
On the affected carton, select Mark Seal Damaged & Reconcile when staff physically observe a broken, damaged, or compromised seal but did not open the carton.
This action:
- records the damaged seal, user, and observation time;
- does not claim that Reyder opened the carton;
- permanently blocks sealed shipment; and
- starts the standard IMEI reconciliation path.
The carton becomes Standard IMEI Reconciliation Required, not Opened.
Reyder opened or is opening the carton¶
Select Open & Reconcile IMEIs only when Reyder actually opened the carton or is intentionally opening it for device-level intake.
This action:
- records the carton as opened, including user and time;
- permanently blocks sealed shipment; and
- starts the standard IMEI reconciliation path.
Effect on the rest of the deal¶
Either exception ends sealed treatment for the whole PO. Any untouched sibling cartons become Standard IMEI Reconciliation Required without falsely claiming they were opened or damaged. Odoo creates the ordinary receiving manifest and restores the ordinary outbound IMEI workflow.
The PO tab also provides Open & Reconcile IMEIs for an intentional, deal-wide conversion to normal IMEI handling. It does not claim that every untouched carton was physically opened. When responding to a specific physical event, start from that carton record so the audit trail accurately distinguishes an observed damaged seal from a Reyder-opened carton.
Staff must physically scan and reconcile the actual devices. Supplier rows may help compare expectations, but only Reyder's physical scans become inventory truth. Never reset a damaged or opened carton to intact, create a replacement sealed record, or ship part of the deal to bypass reconciliation.
Accounting when sealed cartons are reconciled¶
Receipt of an intact carton already posted its allocated cost to inventory. Opening or marking the carton damaged does not post that value a second time. When the ordinary receiving manifest is completed, Odoo compares the physically received IMEI value with the value already posted for the sealed cartons:
- Equal value: no additional receipt valuation is posted.
- Higher physical value: only the unvalued remainder is debited to Device Inventory Valuation and credited to Device Inventory Input.
- Lower physical value: the shortage is debited to Device COGS/shortage expense and credited from Device Inventory Valuation. The manifest retains the unrestored shortage balance.
If a previously missing IMEI is physically received later through the controlled reconciliation workflow, Odoo posts supplemental valuation. It first restores the applicable shortage from Device COGS back to Device Inventory Valuation. Only value beyond the remaining shortage is credited to Device Inventory Input. The original entries remain as audit evidence; they are not silently rewritten or backdated.
Accounting does not verify an IMEI. The late device becomes inventory truth only through its physical scan and reconciliation.
Authoritative meaning of each record¶
| Record | What it proves | What it does not prove |
|---|---|---|
| Supplier manifest attachment | Which file the supplier provided, by hash and audit metadata | That any declared IMEI or attribute is physically present or correct |
Sealed carton in expected |
The PO expects a physical carton | Receipt or Reyder custody |
Sealed carton in received_sealed |
A user received the identified intact carton at the recorded location | Its internal IMEIs, grades, locks, quantities, or condition |
Sealed carton in reconciliation_required |
Sealed shipment ended and IMEI reconciliation is required | That Reyder opened that carton |
Sealed carton in opened |
Reyder recorded that the carton was physically opened | That any supplier-declared IMEI was present |
| Sealed carton with a damaged seal | Reyder recorded observed seal damage | That Reyder opened the carton |
Sealed carton in shipped |
The same tracked carton left against the linked paid invoice | IMEI-level delivery detail |
| Standard receiving manifest | Scanned and reconciled device-level intake after leaving the sealed path | That any carton remained sealed |
Controls and troubleshooting¶
The system blocks confirmation, receipt, reconciliation, or shipment instead of guessing when it finds:
- a missing, cancelled, reversed, or wrong-type customer invoice;
- a company, customer, currency, product, quantity, or amount mismatch;
- an invoice or Sales Order already linked to another sealed PO;
- multiple or unrelated active fulfillment invoices;
- a missing stock journal or valuation, input, or COGS account;
- a zero or inconsistent carton quantity/cost allocation;
- a missing or mismatched physical carton scan;
- an invoice that is not posted and fully paid;
- a damaged, opened, or reconciliation-required carton;
- a partial multi-carton shipment attempt;
- a missing or reversed accounting entry; or
- a repeated receive, ship, or reconciliation attempt.
Correct the authoritative source document or ask Inventory and Accounting to review the audit gap. Do not unlink records, directly change states, reverse and recreate entries, or substitute a different carton to work around a guard.
Standard receipt remains unchanged¶
Existing Purchase Orders default to Standard IMEI Receipt. Their supplier list, scanner, receiving manifest, QC, delivery manifest, and IMEI accounting behavior remain unchanged.