Troubleshooting: quarantine, scrap and trace requests
Core module For: Administrator, Compliance manager, Warehouse staff Checked on 18.0.0.2.0
What to do when a quarantined lot stops a transfer, when quarantining, releasing or scrapping is refused, and when a trace request can't be searched or answered. Entries are ordered from the most frequent.
Elsewhere:
- "Line N: Serial … can't be used here: it is Quarantined." when you scan a held unit onto a delivery: see Error: "Serial … can't be used here: it is …".
- Scan errors shared with receipts ("Some lines could not be read", "… is already scanned on …", "no DSCSA product has GTIN …"): see Troubleshooting: receiving.
- Lots held by a receiving discrepancy or a missing Transaction Statement: see Troubleshooting: supplier files, statements and discrepancies.
- Refusals about access rights in general ("Only DSCSA users can …", "You are not allowed to access …"): see Troubleshooting: access, companies and setup.
Error: "These lots are quarantined and can't be shipped …"
What you see: an Invalid Operation dialog when you select Validate:
These lots are quarantined and can't be shipped or sent to transit or another company until a DSCSA manager releases them:
PRODUCT, lot LOT (QUARANTINE-REASON)
For example: "[DEMO-FMY-250] Fictimycin 250 mg/5 mL for Oral Suspension, 100 mL, lot BPFMY2509D (The carrier reported a temperature excursion on this shipment. Hold until Bluepeak confirms the product is not affected.)"
When: validating a transfer that would take units of a quarantined lot out of your company's custody:
- a delivery whose line was given the quarantined lot by hand, typically a lot-level delivery to an exempt small dispenser, where no serial is scanned (Scan the serials of a delivery and validate it);
- a return to the supplier (Return saleable product to the supplier);
- an internal transfer to a transit location (for example
Virtual Locations/Inter-company transit) or to another company's location (Move quarantined stock to a quarantine shelf).
Cause: the lot is quarantined. The software never reserves a quarantined lot, and refuses every validation that would ship it or send it outside the company, however the lot got onto the transfer. The transfer stays as it was.
Remedy: a resolution. Select Close, then choose one:
- Ship other units: open the ⚙ (Actions) menu of the transfer and select Unreserve (the transfer goes back to Waiting), then select Check Availability: the software reserves units of other lots and the transfer is Ready again. For a scanned delivery, scan units of another lot.
- The lot is cleared: ask an Rx Tracking Manager to release it (Release a lot from quarantine), then select Validate again.
- Quarantined product goes back to the supplier: use a non-saleable return (Send a non-saleable return to the supplier), the one return that may carry held units.
- An internal move: choose an internal location of your company as the Destination Location, for example
WH/Stock/Quarantine.
Who can fix it: Rx Tracking User or Manager to change the units; Rx Tracking Manager to release the lot.
Error: "Serial … can't be used here" on a scrap
What you see: an Invalid Operation dialog when you select Validate on a scrap, with one or more of these lines:
PRODUCT can't be scrapped:
Line N: Serial SERIAL can't be used here: it is STATE.
Line N: Serial SERIAL is not in the package ledger, so it can't be shipped or moved.
Line N: Serial SERIAL is already scanned on TRANSFER.
Line N: Serial SERIAL belongs to OTHER-PRODUCT.
Line N: Serial SERIAL: the scan says lot LOT but the ledger has lot LOT.
Line N: Serial SERIAL: the scan says expiry DATE but the ledger has DATE.
For example: "Line 1: Serial 500000007001 can't be used here: it is Destroyed."
When: scrapping units in Scrap DSCSA units, naming each unit's serial.
Cause: that unit can't be scrapped now:
- Destroyed, Shipped or Missing: it is no longer in your stock (already scrapped, sold, or counted as missing);
- not in the package ledger: it was never received or registered;
- already scanned on another open transfer;
- the line names another product, or its lot or expiry differs from what the ledger recorded at receipt (a misread label, or a label of another unit).
Remedy: a resolution. Select Close, delete or correct the lines named, and select Validate again. Set a unit that isn't in stock aside: if it is physically there, find out why (Look up a unit in the package ledger). A missing unit that turns up is first recorded in a count (Record units found in a count). A unit scanned on an open transfer is removed from it there first (DSCSA Packages tab, remove the scan).
Who can fix it: Rx Tracking User or Manager.
Error: "… serial(s) scanned for … scrapped"
What you see: an Invalid Operation dialog when you select Validate on a scrap:
PRODUCT can't be scrapped:
N serial(s) scanned for QUANTITY Units scrapped: scan one serial per unit.
For example: "2 serial(s) scanned for 3 Units scrapped: scan one serial per unit."
When: in Scrap DSCSA units, naming each unit's serial, after you changed Quantity, or when two lines name the same unit (it counts once).
Cause: each scrapped unit needs its own serial, so the Quantity must equal the number of different units in DSCSA Serials.
Remedy: a resolution. Select Close. Scan the missing units (the Quantity follows the lines), or set Quantity to the number of units scanned, then select Validate again.
Who can fix it: Rx Tracking User or Manager.
Error: "Invalid fields: Lot/Serial" on a scrap
What you see: a red notification "Invalid fields:" with Lot/Serial when you select Validate, and the Lot/Serial field is outlined in red.
When: in Scrap DSCSA units, naming each unit's serial, when Lot/Serial is empty: no line was entered, the lines belong to several lots, or the only line is a case label.
Cause: Odoo needs one lot on a scrap of a lot-tracked product. The software fills Lot/Serial from the lines only when they all name the same lot.
Remedy: a resolution. Scrap each lot on its own scrap: keep only the lines of one lot (or choose the lot in Lot/Serial), select Validate, then make a new scrap for the other lot. Replace a case label with the labels of the units.
Who can fix it: the person scrapping.
Error: "Serial … is in lot …, not in the scrapped lot …"
What you see: an Invalid Operation dialog when you select Validate on a scrap:
PRODUCT can't be scrapped:
Line N: Serial SERIAL is in lot LOT, not in the scrapped lot SCRAP-LOT.
A scrap created by import or through the API may also show "The serials belong to lots LOT, LOT: scrap each lot separately.".
When: in Scrap DSCSA units, naming each unit's serial, when Lot/Serial was chosen and a line names a unit of another lot.
Cause: a scrap removes units of one lot; the package ledger records each unit in its own lot.
Remedy: a resolution. Select Close, remove the lines of the other lot, and select Validate again. Scrap the other lot's units on a new scrap.
Who can fix it: Rx Tracking User or Manager.
Error: "Serial … is in …, not at …"
What you see: an Invalid Operation dialog when you select Validate on a scrap:
PRODUCT can't be scrapped:
Line N: Serial SERIAL is in LOCATION, not at SOURCE-LOCATION.
For example: "Line 1: Serial 500000007003 is in WH/Stock, not at WH2/Stock."
When: in Scrap DSCSA units, naming each unit's serial, when the scrap's Source Location is in another warehouse than the one where the package ledger last recorded the unit.
Cause: a scrap takes units from its Source Location; the ledger knows in which warehouse each unit is. Moves between shelves of one warehouse don't matter.
Remedy: a resolution. Select Close, set Source Location to the warehouse where the unit is, and select Validate again. If the unit really is in the other warehouse, move it there first with a transfer and its scans.
Who can fix it: Rx Tracking User or Manager.
Error: "… is a DSCSA product: scan the serial of each unit being scrapped"
What you see: an Invalid Operation dialog when you select Validate on a scrap:
PRODUCT is a DSCSA product: scan the serial of each unit being scrapped (DSCSA Serials).
Or, when the box holds only empty lines: "Scan or paste at least one package DataMatrix."
When: in Scrap DSCSA units, naming each unit's serial, when DSCSA Serials is empty.
Cause: the package ledger must learn which units are destroyed, so every scrap of a DSCSA product names its units.
Remedy: a resolution. Select Close, scan each unit into DSCSA Serials, and select Validate again.
Who can fix it: Rx Tracking User or Manager.
Error: "a case (SSCC) label can't be used here"
What you see: an Invalid Operation dialog when you select Validate on a scrap:
PRODUCT can't be scrapped:
Line N: a case (SSCC) label can't be used here; scan each unit's DataMatrix.
When: in Scrap DSCSA units, naming each unit's serial, when a line is the label of a sealed case.
Cause: a case label names the case, not the units in it. A scrap needs each unit's serial.
Remedy: a resolution. Select Close, replace the case label with the DataMatrix of each unit, and select Validate again.
Who can fix it: Rx Tracking User or Manager.
Error: "Only DSCSA users can scrap …"
What you see: an Access Error dialog when you select Validate on a scrap:
Only DSCSA users can scrap PRODUCT: the serials of the scrapped units must be recorded in the package ledger.
When: an Inventory User without an Rx Tracking right scraps a DSCSA product. The DSCSA Serials block isn't shown to them.
Cause: scrapping a DSCSA product writes the package ledger, which only Rx Tracking users do.
Remedy: a resolution. Select Close and Discard, and ask an Rx Tracking User to scrap the units, or ask an administrator for the Rx Tracking User right. Products that aren't DSCSA products scrap as usual.
Who can fix it: Rx Tracking User or Manager; an administrator (Administration: Settings) for the right.
Error: "… can't be added to …: it is done" when scrapping from a transfer
What you see: an Invalid Operation dialog when you select Scrap Products in the dialog of a transfer's ⚙ (Actions) ‣ Scrap:
PRODUCT can't be added to TRANSFER: it is done, and DSCSA units must go through the checks of a validation (serials, trading partner,
quarantine, documents). Put the extra units on a new transfer instead.
When: scrapping DSCSA units from a transfer that is already Done, for example a receipt (see From an open transfer).
Cause: Odoo attaches a scrap made from a transfer to that transfer, and the software refuses to add a DSCSA line to a done transfer. The message speaks of "extra units" because the same check guards done transfers against edits. This is a known issue (PF-W09-01).
Remedy: a workaround. Select Close, then Discard. Go to Inventory ‣ Operations ‣ Scrap, select New and scrap the units there (Scrap DSCSA units, naming each unit's serial); in Source Location, choose where the units are now. The draft scrap the dialog saved stays in Scrap Orders as "New"; an Inventory Administrator can delete it (⚙ (Actions) ‣ Delete).
Who can fix it: Rx Tracking User or Manager.
Error: "DSCSA stock (…) can only be relocated …"
What you see: an Oh snap! dialog when you save:
DSCSA stock (PRODUCT) can only be relocated to an internal location of its company, not to LOCATION. Use a transfer, a scrap or an
inventory count.
For example: "… not to Partners/Customers."
When: an Inventory Administrator changes the Location of a lot on its form (the field shows when all the lot's units are in one location) to a location outside the company's stock, such as a customer, supplier, scrap or transit location. Odoo moves such stock at once, without a transfer.
Cause: a move out of your stock must go through a transfer, a scrap or a count, so the package ledger records it and every check runs.
Remedy: a resolution. Select Discard changes. Move the units with the procedure that fits: Move quarantined stock to a quarantine shelf (an internal transfer), Scrap DSCSA units, naming each unit's serial, or Count stock and record the units that are gone.
Who can fix it: Rx Tracking User or Manager.
The Quarantine or Release button isn't shown
What you see: the lot form has no Quarantine button (or no Release button).
When: in Quarantine a lot so it can't be reserved or shipped or Release a lot from quarantine.
Cause: one of these:
| What the form shows | Cause | What to do |
|---|---|---|
| The status bar (Not Quarantined, Quarantined, Released) but no button | You don't have the Rx Tracking Manager right | Ask an Rx Tracking Manager to quarantine or release the lot |
| Release, not Quarantine | The lot is already Quarantined | Nothing: the lot is on hold. Its reason is on the Quarantine tab |
| Quarantine, not Release | The lot isn't quarantined (Not Quarantined or Released) | Nothing to release |
| No status bar at all | The lot's product isn't a DSCSA product | Only lots of DSCSA products can be quarantined. If the product should be one, see Set up a DSCSA product |
| No button on a new lot | The lot isn't saved yet | Save the lot first |
Remedy: as the table says.
Who can fix it: Rx Tracking Manager; an administrator (Administration: Settings) for the right.
Error: "Give a reason for the quarantine."
What you see: in the Quarantine Lot or Release Lot dialog, after you select Quarantine or Release, either a red notification "Invalid fields:" with Reason (the field is outlined in red), or an Invalid Operation dialog:
Give a reason for the quarantine.
or "Give a reason for the release."
When: in Quarantine a lot so it can't be reserved or shipped or Release a lot from quarantine, when Reason is empty or holds only spaces.
Cause: every quarantine and release keeps its reason on the lot and in its chatter.
Remedy: a resolution. Select Close if a dialog shows, enter a reason, and select Quarantine or Release again.
Who can fix it: Rx Tracking Manager.
Error: "These lots are not quarantined."
What you see: an Invalid Operation dialog when you select Release:
These lots are not quarantined.
When: in Release a lot from quarantine, on a lot form that was opened before someone else (or an automatic release, when a missing Transaction Statement was recorded) released the lot.
Cause: the lot was released in the meantime; your page still shows it as quarantined.
Remedy: a resolution. Select Close and reload the page (press F5). The chatter shows who released the lot, and why.
Who can fix it: Rx Tracking Manager.
Errors when quarantine fields are imported or set through the API
What you see: one of these, when lots are imported or changed through the API (they don't appear in the forms):
Only a DSCSA manager can quarantine or release a lot.
Only lots of DSCSA products can be quarantined: LOT.
Lot LOT: only lots of DSCSA products can be quarantined.
Lot LOT: a quarantine needs a reason.
Lot LOT: a release needs a reason.
Which holds keep a lot quarantined is recorded by the system.
When: an import or a script sets Quarantine, a quarantine or release reason, or Held Outside Discrepancies on a lot.
Cause: the same rules as in the forms: only an Rx Tracking Manager quarantines or releases, only lots of DSCSA products, always with a reason. Held Outside Discrepancies is set by the software only.
Remedy: a resolution. Import as an Rx Tracking Manager, only lots of DSCSA products, with the reason column filled in, and leave Held Outside Discrepancies out of the file. Or use the forms: Quarantine a lot so it can't be reserved or shipped.
Who can fix it: Rx Tracking Manager.
Error: "Enter at least one serial, lot, product, GTIN or transaction date."
What you see: an Invalid Operation dialog when you select Search on a trace request:
Enter at least one serial, lot, product, GTIN or transaction date.
When: in Search the records a trace request asks for, when the Query group is empty.
Cause: the search needs at least one criterion.
Remedy: a resolution. Select Close, fill in Serials, Lots, Products, GTINs / NDCs or Transaction Dates from the request, and select Search again.
Who can fix it: Rx Tracking User or Manager.
Error: "Some serial lines could not be read"
What you see: an Invalid Operation dialog when you select Search on a trace request, with one line per problem:
Some serial lines could not be read:
Line N: PROBLEM
or, for the GTINs / NDCs field, "Some GTINs / NDCs could not be read:" with one line per value. For example:
Some serial lines could not be read:
Line 1: Some lines could not be read:
Line 1: GTIN '00399990101301' has an invalid check digit: the last digit should be 0, not 1. Check for a typing or scanning error.
Line 2: enter a GS1 DataMatrix, '<GTIN> <serial>' or one serial per line.
Other problems: "only SGTIN and SSCC URNs name packages; enter lots and products in their own fields." and "the GS1 data has no GTIN (01) and serial (21).".
When: in Search the records a trace request asks for.
Cause: a line of Serials (or a value of GTINs / NDCs) isn't in a form the search can read: a typing error, a GTIN whose check digit is wrong, free text, or an EPC URN that names a lot or a product instead of a unit.
Remedy: a resolution. Select Close and correct the lines named: one unit per line, as a DataMatrix, (01)…(21)… text, GTIN SERIAL,
an SGTIN or SSCC URN, or a serial number alone. Put lots in Lots and
products in Products. Select Search again.
Who can fix it: Rx Tracking User or Manager.
Known issue (PF-W09-02): a line with a wrong check digit is reported inside a second "Some lines could not be read:" heading, as in the example. Read the innermost line: it names the problem.
Error: "The transaction date range of … ends before it starts."
What you see: an Oh snap! dialog when you save a trace request:
The transaction date range of DSCSA/TR/YYYY/NNNNN ends before it starts.
When: in Search the records a trace request asks for, when the second Transaction Dates date is before the first.
Cause: the range would find nothing.
Remedy: a resolution. Select Stay here, swap the two dates, and save.
Who can fix it: Rx Tracking User or Manager.
Warning: "Not found: …" on a trace request
What you see: a yellow banner at the top of a searched trace request, for example:
Not found: serial (01)00399990101300(21)299999999999
When: after Search the records a trace request asks for.
Cause: a serial or lot of the query matches no unit and no DSCSA document of the request's company. It may be a typing error, a unit you never held, or a product that isn't a DSCSA product (those are never in the results).
Remedy: check the line against the request. Correct it and select Search Again, or respond as it is: the zip's request.txt lists
what was not found, which is part of the answer.
Who can fix it: Rx Tracking User or Manager.
Error: "The stored files of these DSCSA documents don't match their checksums"
What you see: an Invalid Operation dialog when you confirm Respond:
The stored files of these DSCSA documents don't match their checksums; run Verify Integrity before responding:
DOCUMENT: PROBLEM
When: in Respond to a trace request with the response zip, and send it.
Cause: a file stored with a document the request found (its T3 report or EPCIS file) is missing or differs from the checksum recorded when the document was posted. The zip is not built, so no altered file is sent.
Remedy: a resolution, by a manager. Run the integrity check and investigate the documents named (Verify the integrity of the DSCSA documents). The request stays In Progress; tell the requester if the deadline is at risk.
Who can fix it: Rx Tracking Manager.
Error: "Search trace request … before responding."
What you see: an Invalid Operation dialog with one of:
Search trace request DSCSA/TR/YYYY/NNNNN before responding.
Trace request DSCSA/TR/YYYY/NNNNN is closed.
Trace request DSCSA/TR/YYYY/NNNNN is already closed.
Trace request DSCSA/TR/YYYY/NNNNN has no response yet.
Trace request DSCSA/TR/YYYY/NNNNN is closed and can't be changed (fields: FIELDS).
When: selecting Respond, Search Again, Cancel Request or Download Response, or saving, on a request that someone changed in another window: it was answered, cancelled, or its query changed (which sends it back to New). Imports and API calls that change a closed request show the last line.
Cause: the buttons you see belong to the state the page had when you opened it.
Remedy: a resolution. Select Close and reload the page (press F5), then continue from the request's real state. A Responded or
Cancelled request can't change any more.
Who can fix it: Rx Tracking User or Manager.
Error: "Only DSCSA managers can do this on a trace request."
What you see: the Cancel Request button isn't shown, or, through an import or the API, an Access Error:
Only DSCSA managers can do this on a trace request.
or "Only DSCSA users can do this on a trace request." for Search and Respond.
When: in Cancel a trace request that needs no answer as an Rx Tracking User; or searching and responding without an Rx Tracking right.
Cause: any Rx Tracking User logs, searches and answers a trace request; only an Rx Tracking Manager cancels one. Without an Rx Tracking right, the Trace Requests menu isn't shown and Odoo refuses the records ("You are not allowed to access 'DSCSA Trace Request' …", see Error: "You are not allowed to access ... records").
Remedy: a resolution. Ask an Rx Tracking Manager to cancel the request, or an administrator for the right you need.
Who can fix it: Rx Tracking Manager; an administrator (Administration: Settings) for the rights.
The trace request reminder went to the wrong person or date
What you see: after you changed a trace request's Responsible or Received On, its "Respond to the trace request within 24 hours" activity still shows the first person or the first due date.
When: after saving a change in Log a trace request from the FDA, a state or a trading partner.
Cause: the activity is scheduled only when the request is first saved; later changes don't move it. Due On itself is right. This is a known issue (PF-A04-03).
Remedy: a workaround. In the request's chatter, select Edit on the activity, set Assigned to and Due Date to match Responsible and Due On, and save.
Who can fix it: Rx Tracking User or Manager.
Errors when trace requests are imported or changed through the API
What you see: one of these, from an import or a script (the forms never show them):
A new trace request starts without a log; these fields are set by Search, Respond and Cancel only: FIELDS.
The log of trace request DSCSA/TR/YYYY/NNNNN is set by Search, Respond and Cancel only; it can't be changed directly (fields: FIELDS).
A trace request number must be unique per company.
Trace requests are kept as a record that the request was received and answered; cancel the request instead.
Trace requests only cover DSCSA products; PRODUCT is not one.
Trace request DSCSA/TR/YYYY/NNNNN only covers the records of COMPANY; these belong to another company: RECORDS.
When: importing trace requests, or a script that sets their number, status, results or response, deletes one, or adds a product that isn't a DSCSA product to the query.
Cause: a trace request's log (number, status, results, response, who and when) is written only by Search, Respond and Cancel Request, so it can't be forged or backdated; requests are never deleted; the search covers DSCSA products of the request's company only.
Remedy: a resolution. Import only the request fields (Requested By, Requester, Their Reference, Received On, Responsible, the request text and the query), then use the buttons: Search the records a trace request asks for. To drop a request, cancel it: Cancel a trace request that needs no answer.
Who can fix it: Rx Tracking User or Manager; Rx Tracking Manager to cancel.
Error: "The serials of a done scrap are recorded in the package ledger and can't be changed."
What you see: from an import or a script (in the form, the DSCSA Serials of a done scrap are read-only):
The serials of a done scrap are recorded in the package ledger and can't be changed.
When: changing DSCSA Serials on a scrap that is Done.
Cause: the units it lists are recorded as Destroyed in the package ledger; the record can't be rewritten.
Remedy: none needed: a scrap is final. If a wrong unit was scrapped, the ledger shows it as Destroyed; record the correction outside Odoo as your procedure says, and count the real stock (Count stock and record the units that are gone).
Who can fix it: nobody can change a done scrap.