Packages and the serial ledger
Core module 3PL add-on For: Administrator, Compliance manager, Warehouse staff Checked on 18.0.0.2.0, 18.0.1.0.0
Rx Tracking keeps one record, a package, for every serialized unit of a DSCSA product you hold or have held. Together these records are the package ledger: the answer to "where is serial X, where did it come from, and who did we ship it to?".
What it is
A drug's saleable unit (a bottle, a carton) carries a 2D barcode, a GS1 DataMatrix, with four facts: the product's GTIN, the expiry date, the lot and the unit's own serial number. Standard Odoo tracks a product either by lot or by serial number, never both. Rx Tracking keeps DSCSA products lot-tracked, so Odoo's stock, reservation and expiry dates work by lot as usual, and adds the serial of each unit as a package in its own ledger.
A package holds:
- Identity: Product, GTIN, Serial Number, SGTIN (the unit's identifier in EPCIS files), Lot, Expiration Date, and the SSCC of the sealed case it came in, if any.
- Where it is in its life: its State (see below), its Origin, the receipt line it came in on, the delivery line it left on and who it was Shipped To.
- Movement History: every stock move the unit took part in.
- With the 3PL add-on: Held for Owner (the owner whose stock it is; empty means your own stock) and, once shipped, the Seller of Record. See Owner stock and own stock.
The ledger is in Inventory ‣ Rx Tracking ‣ Packages. Each lot's form has a Packages smart button, and each receipt and delivery a DSCSA Packages tab. How to search it: Look up a unit in the package ledger.
A sealed case is not a package of its own. Its SSCC (Serial Shipping Container Code) label is stored on each unit it contains, so scanning the label once receives every unit the supplier's EPCIS file lists in that case (Receive a sealed case by scanning its SSCC label).
How a package moves through its states
Packages are never created, edited or deleted by hand. Only the ledger's own operations change them, and each operation changes the state of the units it names:
| Operation | What it does to packages | Procedure |
|---|---|---|
| Import a supplier's EPCIS file on a receipt | creates the announced units as Expected | IN-03 |
| Scan Serials on a receipt (a unit, or a sealed case's SSCC) | makes the units Received, or creates them when no file announced them | IN-04, IN-08 |
| Validate the receipt | Received units become In Stock, with origin Receipt | IN-05 |
| Validate a delivery, or a return to the supplier | the scanned units become Shipped, with Shipped To | OUT-03, RET-04 |
| Validate a customer return | the units come back as Returned and wait in Returns to Verify | RET-01 |
| Verify or reject a returned unit | In Stock (Verified for Resale) or Destroyed (Rejected and Destroyed) | RET-02 |
| Validate a scrap, naming each unit | Destroyed | EXC-05 |
| Apply an inventory count | units gone become Missing; units found are created, with origin Found in Inventory Count | REC-03, REC-04 |
| Register the opening balance | creates the units already on the shelf, with origin Opening Balance | REC-01 |
| Quarantine or release a lot | In Stock and Returned units become Quarantined; the release gives each its earlier state back | EXC-01, EXC-02 |
A unit scanned onto an open receipt or delivery by mistake can be taken off it with the ✖ (Remove this scan) icon until the transfer is Done (Undo a scan). Once a unit was received, its package is kept for good. The full list of states and origins is in Fields and statuses the core module adds.
How the software uses the ledger
- One serial per unit. Validating a receipt, a delivery or a return of DSCSA products needs exactly one scanned serial for each unit on it. Scraps and inventory counts of DSCSA products need the serials of the units concerned. Products that aren't DSCSA products are never asked for serials. See What is checked where.
- Documents list the packages. The outbound DSCSA document of a delivery lists the serials of the packages it shipped; a customer return is matched against the packages you shipped to that customer; a trace request searches the packages by serial, lot or GTIN. See DSCSA documents.
- Holds act on packages. A quarantined lot's packages can't be scanned onto a delivery, and units waiting in Returns to Verify are never reserved. See Quarantine and holds.
- The ledger and Odoo's stock are checked against each other. Inventory ‣ Rx Tracking ‣ Ledger vs Stock lists each product, lot and warehouse where the packages on hand (In Stock, Returned or Quarantined) don't match Odoo's on-hand quantity, for example stock that existed before the product became a DSCSA product. See Check the package ledger against the stock.
- Nothing is deleted. A package, like a posted document, is part of the DSCSA record: deleting it or changing it outside the ledger's operations is refused for every user, the administrator included. See Records that are kept.
A lot's own number and product can't change once a posted document names the lot; its expiry date can, and the documents keep the date they were posted with (Correct a lot's number or expiry after documents were posted).
With the 3PL add-on
Each package also carries its owner. The owner is set when an owner receipt becomes Done, and afterwards it changes only through a title transfer, which changes the owner of chosen serials without moving them. One lot can therefore hold your units and several owners' units at once, told apart serial by serial. Ledger vs Stock per Owner (3PL ‣ Reports) compares each package's owner with the owner of Odoo's stock. See Owner stock and own stock and The title model.
Why it exists
Background: Odoo tracks either a unit's lot or its serial, so the modules add a ledger that keeps each unit's serial while the unit still belongs to its lot, and they refuse a shipment whose recorded serials don't match its quantity. The modules follow the reading that the transaction information a seller provides includes the product identifier (GTIN, serial, lot and expiry) of every package, and that a receiver may infer the units of a case whose seal is intact from the supplier's aggregation data, but not of a case whose seal is broken (FD&C Act § 582(c)(1)(A)(i), § 582(g)(1); FDA interoperable exchange guidance (September 2023); see Compliance background).
Your procedure decides when a case counts as sealed and intact, and when your staff scan every unit instead; the software accepts the case label only for a case the supplier's file lists.