Troubleshooting: selling and shipping
Core module For: Administrator, Compliance manager, Warehouse staff, Sales and purchasing Checked on 18.0.0.2.0
What to do when scanning or validating a delivery stops with an error, when a customer can't accept or pay an order online, or when a DSCSA document isn't what you expected. Entries are ordered from the most frequent.
Elsewhere:
- Refusals that name a trading partner ("… can't be confirmed: it contains DSCSA products …", "… can't be validated: it moves DSCSA products … to or from a trading partner.", "… has no valid state license …", "Delivery address …", "… but no trading partner is set on the transfer."): see Troubleshooting: products, partners and licenses, starting at Error: "… can't be confirmed: it contains DSCSA products …".
- The yellow banner on an open delivery "The DSCSA document of this shipment will have no EPCIS file: …" (a missing GLN, Global Location Number): see Warning: "The DSCSA document of this shipment will have no EPCIS file …".
- "… can't be validated: scan one DSCSA serial for each unit being validated" and "DSCSA packages don't match the quantities being validated": see Error: "… can't be validated: scan one DSCSA serial for each unit being validated" and Error: "DSCSA packages don't match the quantities being validated". They stop deliveries as they stop receipts.
- Scan errors shared with receipts ("Some lines could not be read", "… is not on this transfer", "no DSCSA product has GTIN …", "… is already scanned on …", "Scan or paste at least one package DataMatrix.", "… is already done or cancelled."): see Troubleshooting: receiving.
- "These lots are quarantined and can't be shipped or sent to transit or another company until a DSCSA manager releases them": see Troubleshooting: quarantine, scrap and trace requests.
- "Only DSCSA users can …" (scanning or removing scans without an Rx Tracking right): see Error: "Only DSCSA users can ...".
Error: "Serial … can't be used here: it is …"
What you see: when you select Register in the Scan DSCSA Serials dialog:
Nothing was registered. Fix these scans and try again:
Line N: Serial SERIAL can't be used here: it is STATE.
For example: "Line 1: Serial 200000000002 can't be used here: it is Shipped."
When: scanning units onto a delivery in Scan the serials of a delivery and validate it, or onto a pick in Ship part of a delivery, or ship in pick, pack and ship steps.
Cause: a delivery ships only units that are In Stock in the package ledger. The unit's package is in another state:
| State | What it means | What to do |
|---|---|---|
| Shipped | the unit already left on an earlier delivery (a label scanned twice, or a unit that came back without a return) | Set it aside. If it came back, receive it as a return first (Receive a saleable customer return with its serials). |
| Returned | a customer return waiting in Returns to Verify | Scan another unit, or ask an Rx Tracking Manager to verify it (Verify returned units for resale). |
| Quarantined | its lot is quarantined | Scan a unit of another lot, or ask an Rx Tracking Manager to release the lot (Release a lot from quarantine). |
| Destroyed, Missing | the unit was scrapped, or recorded as missing at a receipt or a count | Set it aside and tell an Rx Tracking Manager. |
Remedy: resolution. Delete the line from the scan box, scan an available unit instead, and select Register again.
Who can fix it: Rx Tracking User or Manager (another unit); Rx Tracking Manager (verify or release).
Error: "… packages scanned but only … ordered."
What you see:
Nothing was registered. Fix these scans and try again:
PRODUCT: SCANNED packages scanned but only DEMAND ordered.
For example: "[DEMO-DPZ-20] Demoprazole 20 mg Delayed-Release Capsules, 30 count: 13 packages scanned but only 12.0 ordered."
When: registering scans in Scan the serials of a delivery and validate it; the count includes the units already on the DSCSA Packages tab.
Cause: the delivery asks for fewer units of the product than are scanned on it. None of the new lines is registered.
Remedy: resolution. Choose one:
- Scan only the units this delivery needs; if a wrong unit is already on the delivery, remove it first (Correct the scans of an open delivery).
- If the customer wants more, ask the salesperson to change the order, then scan the extra units.
Who can fix it: Rx Tracking User or Manager; the salesperson for the order quantity.
Error: "Serial … is not in the package ledger …"
What you see:
Nothing was registered. Fix these scans and try again:
Line N: Serial SERIAL is not in the package ledger, so it can't be shipped or moved.
When: scanning units onto a delivery in Scan the serials of a delivery and validate it.
Cause: no unit with this product and serial number was ever received with its serial or registered: the stock predates the package ledger, the unit was received without scanning, or the label was misread.
Remedy:
- Scan the label again, or type the serial number printed on it.
- If the unit is stock you held before you went live with Rx Tracking, ask an Rx Tracking Manager to register it (Register the opening balance for stock that predates the package ledger), then scan it again. This is a resolution.
- Otherwise set the unit aside and tell an Rx Tracking Manager. Your procedure decides how a unit on the shelf that isn't in the ledger is investigated.
Who can fix it: Rx Tracking Manager.
Error: "the scan says lot … but the ledger has lot …"
What you see:
Nothing was registered. Fix these scans and try again:
Line N: Serial SERIAL: the scan says lot SCANNED-LOT but the ledger has lot LOT.
or, for the expiry date:
Line N: Serial SERIAL: the scan says expiry SCANNED-DATE but the ledger has DATE.
For example: "Line 5: Serial 200000000023: the scan says lot BPDPZ2509B but the ledger has lot BPDPZ2508K."
When: scanning units onto a delivery in Scan the serials of a delivery and validate it.
Cause: the serial number is in the ledger, but with another lot or expiry date than the label now shows: a misread, a typed line with a typing error, or a label that doesn't match what was received.
Remedy:
- Scan the label again (resolution for a misread or a typing error).
- If the label really shows another lot or expiry than the ledger, don't ship the unit: set it aside and tell an Rx Tracking Manager. Your procedure decides whether it is investigated as a suspect product.
Who can fix it: Rx Tracking User or Manager (rescan); Rx Tracking Manager (investigation).
Error: "… only … more unit(s) of lot … are available in …"
What you see:
PRODUCT: only AVAILABLE more unit(s) of lot LOT are available in LOCATION, but SCANNED were scanned.
For example: "[DEMO-SMS-40] Samplostatin 40 mg Tablets, 90 count: only 0 more unit(s) of lot BPSMS2508B are available in WH2/Stock, but 1 were scanned."
When: registering scans in Scan the serials of a delivery and validate it, or on the pick of a multi-step delivery (OUT-04).
Cause: the delivery takes its units from the location named in the message, and Odoo's stock has too few free units of that lot there: the unit you scanned is stored in another warehouse or location, or the lot's units there are reserved by other deliveries. Nothing is registered.
Remedy: resolution. Choose one:
- Scan a unit that is stored in that location.
- Move the units to that location with an internal transfer first, then scan them.
- If another delivery holds the lot's units, ask who handles it; unreserving or shipping it frees them.
Who can fix it: Rx Tracking User or Manager.
Error: "SSCC … is not a case the supplier's EPCIS file lists for this transfer" on a delivery
What you see:
Nothing was registered. Fix these scans and try again:
Line N: SSCC SSCC is not a case the supplier's EPCIS file lists for this transfer. Scan the packages inside it one by one.
For example:
Line 1: SSCC 003999900000003888 is not a case the supplier's EPCIS file lists for this transfer. Scan the packages inside it one by one.
When: scanning the case label (SSCC, Serial Shipping Container Code) of a sealed case in Scan the serials of a delivery and validate it.
Cause: Rx Tracking ships units, not cases. A case label is accepted only on a receipt whose imported supplier EPCIS (Electronic Product Code Information Services) file lists that case; on a delivery it is always refused, even for a case that is still sealed. Nothing is registered. The EPCIS file of the delivery's DSCSA document lists the units loose, without the case (The outbound EPCIS 1.2 file).
Remedy: a workaround. Open the case, scan the DataMatrix of every unit you ship, and select Register again. Shipping a sealed case as a case, with the units aggregated under it, isn't available (Known issue PF-F04-01). For the same message on a receipt, see Error: "SSCC … is not a case the supplier's EPCIS file lists for this transfer".
Who can fix it: Rx Tracking User or Manager (the scans); nobody can make a delivery accept a case label.
A small dispenser's delivery asks for serial numbers
What you see: validating the delivery of a customer flagged as a small business dispenser, without scanning, is refused:
WH/OUT/NNNNN can't be validated: scan one DSCSA serial for each unit being validated.
- PRODUCT: QUANTITY expected, 0 scanned.
When: in Ship at lot level to an exempt small dispenser.
Cause: the exemption doesn't apply to this delivery, so every unit needs a scan. On the customer's DSCSA tab, Exemption in Effect is cleared, because:
- the company's Small-dispenser exemption end date is today or past, or empty (Set the small-dispenser exemption end date);
- Small Business Dispenser is cleared, or the customer's DSCSA Role isn't Dispenser;
- the contact was promoted to a company of its own: its chatter says "Small-dispenser exemption cleared: PARTNER is no longer a contact of COMPANY and must attest for itself.".
It also happens when you scanned some but not all units of a product: once one unit is scanned, all must be.
Remedy: resolution. Scan the units and validate (Scan the serials of a delivery and validate it). If the flag or the date is wrong, have it corrected first (Flag a small-dispenser customer and record its attestation).
Who can fix it: Rx Tracking User or Manager (scans, the flag); an administrator (the end date).
Warning: "No EPCIS file was generated: …"
What you see: a yellow banner on a posted outbound DSCSA document:
No EPCIS file was generated: REASON
The document's chatter, and the chatter of its delivery, say:
No EPCIS file was generated for DSCSA document DOCUMENT: REASON. The T3 report was stored as usual. Complete the master data so that the next deliveries get their EPCIS file; this document can't be changed any more.
The document is listed under the EPCIS Missing filter of Inventory ‣ Rx Tracking ‣ Documents, and has Download T3 but no Download EPCIS.
When: after a delivery becomes Done (Scan the serials of a delivery and validate it); found in Handle a document posted without an EPCIS file.
Cause: the EPCIS file needs data that was missing or invalid when the delivery became Done. The delivery isn't stopped: the document is posted with its T3 report (Transaction Report) only. REASON is one or more of:
| REASON | Fix for the next deliveries |
|---|---|
| "the buyer NAME has no GLN" | Fix a missing GLN before shipping |
| "our company NAME has no GLN" | Set the company's address, GLN and GS1 prefix length |
"receiver.street is required." (also name, city, zip, country, and state for a US address) | complete the address of the buyer's company (Onboard a trading partner) |
"sender.street is required." (also name, city, zip, country, and state for a US address) | complete our company's address (Complete the company's name and address, part of CFG-02) |
| "PRODUCT has no NDC" | Set up a DSCSA product |
| "…: NDC NDC does not match GTIN GTIN, which contains NDC NDC." | correct the product's NDC (National Drug Code) or GTIN (Global Trade Item Number) (Set up a DSCSA product) |
| "the GS1 company prefix length of PRODUCT (GTIN GTIN) is unknown" | Set the company's address, GLN and GS1 prefix length |
| "the document has no transaction statement" | both texts were emptied in the settings: Review the Transaction Statement and the EPCIS legal notice |
| "… contains a control character that XML cannot carry.", or a message about GS1 characters in a lot name | remove the character from the field named (an address line, a lot name) |
| "PRODUCT lot LOT is listed without serial numbers", "no serialized package was shipped" | the units weren't scanned on a package-level delivery; scan every unit next time (OUT-03) |
| "… .expiry_date: lot … has expiry … here but … in …" | the same lot has two expiry dates in the ledger; ask an Rx Tracking Manager to check the lot |
| "the shipment has no business reference" | the delivery has no number or order; ship DSCSA products on a delivery of a sales order |
Remedy: a workaround for the posted document, a resolution for the next ones:
- Fix the cause in the table, so that the next deliveries get their EPCIS file.
- Give the customer the document's T3 report (Find, view, download and print DSCSA documents). Nothing can add the EPCIS file to the posted document; your procedure decides how a customer that needs that shipment's EPCIS data gets it.
Who can fix it: the fix in the table (an administrator for our company's data; a user who can edit contacts or products for the partner's and the products'); anyone with Rx Tracking User to download the T3.
Error: "This order can't be paid online yet."
What you see: a customer who selects Pay on a quotation, or on a payment link, gets a "Payment processing failed" window:
This order can't be paid online yet.
ORDER can't be confirmed: it contains DSCSA products (PRODUCTS).
REASON
For example: "S00035 can't be confirmed: …" and "Lakeview Apothecary (dispenser) has no valid state license: license DEMO-CA-PHY-61177 expired on 2026-09-11."
When: in Let a customer accept or pay an order online.
Cause: the quotation has DSCSA products, and the customer's company (or the company of the delivery address) isn't an authorized trading partner. The check runs before the customer reaches the payment step, so nothing is paid. The quotation stays Quotation Sent; a signature given just before is kept.
Remedy: resolution. Fix the reason as in Error: "… can't be confirmed: it contains DSCSA products …", then ask the customer to pay again.
Who can fix it: Rx Tracking Manager (licenses and roles). The customer can't fix it.
The customer's Accept & Sign button keeps spinning
What you see: a customer reports that, after signing a quotation and selecting Accept & Sign, the button keeps spinning and nothing happens. The quotation stays Quotation Sent, with no signature.
When: in Let a customer accept or pay an order online, on a quotation without online payment.
Cause: the quotation has DSCSA products and the customer isn't an authorized trading partner: confirming it is refused, but the page doesn't show the refusal (Known issue PF-W07-01). The refusal is the one of Confirm a sales order for DSCSA products; select Confirm on the quotation yourself to read it.
Remedy: resolution. Fix the reason as in Error: "… can't be confirmed: it contains DSCSA products …". Then ask the customer to sign again, or confirm the order yourself.
Who can fix it: Rx Tracking Manager (licenses and roles); the salesperson (confirming the order).
The DSCSA Documents smart button isn't shown
What you see: a delivery has no DSCSA Documents smart button.
When: in Open the DSCSA document a delivery posted.
Cause: one of:
- the delivery isn't Done: the document is posted when it becomes Done;
- your user has no Rx Tracking right (an Inventory User only): you can validate deliveries but not see their documents;
- the delivery had no DSCSA products;
- the transfer posts no outbound document by design: a customer return, the pick and pack steps of a multi-step delivery (the ship step has the document), or a return to the supplier marked non-saleable (Send a non-saleable return to the supplier).
Remedy: validate the delivery, or ask a colleague with an Rx Tracking right; the document is also in Inventory ‣ Rx Tracking ‣ Documents (search by Transfer).
Who can fix it: Rx Tracking User or Manager; an administrator grants the right (Give staff the right Rx Tracking access).
Send message is greyed out on a DSCSA document
What you see: on a DSCSA document, Send message and Log note are greyed out and do nothing.
When: in Send one document's link to a customer.
Cause: Rx Tracking User can read DSCSA documents but not post on them; only Rx Tracking Manager can (Known issue PF-W07-02).
Remedy: workaround. Ask an Rx Tracking Manager to send the message, or download the T3 report and email it yourself (Find, view, download and print DSCSA documents).
Who can fix it: Rx Tracking Manager.
Error: "The T3 report of DSCSA document … was frozen when it was posted …"
What you see:
The T3 report of DSCSA document DOCUMENT was frozen when it was posted and is never generated again. Download the stored file from the document; if it is missing, run Verify Integrity.
When: selecting ⚙ (Actions) ‣ T3 Report (DSCSA) on a DSCSA document, in Find, view, download and print DSCSA documents.
Cause: the document has no stored T3 report to print. On a supplier's (Inbound (received)) document this is always the case: we don't make a T3 report for what we receive, and the supplier's files are on the Files tab (Known issue PF-A03-04). On an outbound document, the stored file is missing: see Error: "DSCSA document … has no stored T3 report.".
Remedy: on an inbound document, open the Files tab and download the supplier's files; there is nothing to fix. On an outbound document, follow the next entry.
Who can fix it: no fix needed for inbound documents.
Error: "DSCSA document … has no stored T3 report."
What you see:
DSCSA document DOCUMENT has no stored T3 report. Run Verify Integrity.
When: selecting Download T3 on a posted outbound document, in Find, view, download and print DSCSA documents.
Cause: the T3 report stored when the document was posted can't be found: it was removed from Odoo's file store or database outside the application. A posted document is never rendered again.
Remedy:
- Ask an Rx Tracking Manager to run Verify the integrity of the DSCSA documents: it names the documents whose files are missing or changed.
- Restore the file from your backups (your system administrator). There is no way to generate it again in the software.
Who can fix it: Rx Tracking Manager (the check); the system administrator (the restore).
Error: "The DSCSA hash chain of … is broken …"
What you see: validating a delivery is refused:
The DSCSA hash chain of COMPANY is broken: position N is missing. Run Verify Integrity.
When: selecting Validate on a delivery (or any transfer that posts a DSCSA document), in Scan the serials of a delivery and validate it.
Cause: every posted document is linked to the previous one of the same company. A document of that chain is missing (removed from the database outside the application), so no new document can be added after it, and nothing posts until it is investigated.
Remedy:
- Ask an Rx Tracking Manager to run Verify the integrity of the DSCSA documents, which names the gap.
- Restore the missing document from your backups (your system administrator), then validate the delivery again.
Who can fix it: Rx Tracking Manager and the system administrator.
Error: "The T3 report of DSCSA document … could not be rendered as a PDF."
What you see: validating a delivery is refused:
The T3 report of DSCSA document DOCUMENT could not be rendered as a PDF.
When: selecting Validate in Scan the serials of a delivery and validate it.
Cause: the server couldn't turn the T3 report into a PDF, usually because wkhtmltopdf (the PDF tool Odoo uses) is missing or
broken on the server. The whole validation is undone: the delivery stays open, and no document is posted.
Remedy: resolution. Ask your system administrator to install a working wkhtmltopdf (Odoo 18 uses version 0.12.6 with patched Qt;
see Odoo's installation documentation), then validate
the delivery again.
Who can fix it: the system administrator.