Troubleshooting: supplier files, statements and discrepancies

Core module For: Administrator, Compliance manager, Warehouse staff Checked on 18.0.0.2.0

What to do when recording a Transaction Statement, resolving a receiving discrepancy, cancelling or correcting a supplier file or a done receipt stops with an error, and what each warning on a supplier file's Warnings tab means. Errors that refuse the import itself (another buyer, an unknown GTIN, a product not on the receipt) and the Scan Serials messages, a duplicate serial included, are on Troubleshooting: receiving. Messages about access rights are on Access, companies and setup. Abbreviations: EPCIS: Electronic Product Code Information Services; GLN: Global Location Number; GTIN: Global Trade Item Number; NDC: National Drug Code (see the glossary).

Error: "Confirm that the supplier's statement affirms the §581(27) Transaction Statement …"

What you see: an Invalid Operation dialog:

Confirm that the supplier's statement affirms the §581(27) Transaction Statement. If it doesn't, the discrepancy stays open: ask the
supplier for it.

When: selecting Record or Record and Release in the Record Transaction Statement dialog (DISC-06, DISC-07).

Cause: the checkbox The supplier's statement affirms the §581(27) Transaction Statement is not selected. The software records a statement only when the person recording it confirms that the supplier's statement affirms it.

Remedy: a resolution.

1. Select Close.
2. Check the supplier's document. If it affirms the statement, select the checkbox and select Record (or Record and Release) again. If the evidence file is not attached yet, don't attach it in this dialog: select Cancel, open the dialog again and attach the file first (Known issue PF-W06-02, see Error: "Upload the evidence files …").
3. If it doesn't affirm it, select Cancel and ask the supplier for its Transaction Statement. Your procedure decides what happens to the goods in the meantime.

Who can fix it: Rx Tracking User or Manager.

Error: "Attach the evidence file(s) …"

What you see: an Invalid Operation dialog with one of:

Attach the evidence file(s): the T3 or packing slip, a copy of the portal page, or the email.

Attach the evidence file(s), or give a reference to the EDI message or record.

When: selecting Record or Record and Release in the Record Transaction Statement dialog (DISC-06).

Cause: no file is attached. With T3 / Packing-Slip PDF, Supplier Portal or Email, a file is required. With EDI or Other, a Reference alone is enough.

Remedy: a resolution. Select Close, then either attach the evidence under Evidence Files, or, for EDI or Other, enter the Reference. Select Record again. If the attached file is then refused, see Error: "Upload the evidence files …".

Who can fix it: Rx Tracking User or Manager.

Error: "Upload the evidence files in the Record Transaction Statement window …"

What you see:

Upload the evidence files in the Record Transaction Statement window; files that belong to other records can't be used (FILE-NAMES).

When: selecting Record or Record and Release after an earlier attempt in the same dialog was refused (DISC-06).

Cause: a refused attempt saves the dialog. A file attached after that is stored as belonging to the dialog, and the software accepts only files attached before the first attempt (Known issue PF-W06-02).

Remedy: a workaround.

1. Select Close, then Cancel to close the dialog.
2. Select Record Transaction Statement again.
3. Attach the evidence file first, then fill in the other fields, select the checkbox and select Record (or Record and Release).

Who can fix it: Rx Tracking User or Manager.

Error: "The date the Transaction Statement was obtained can't be in the future."

What you see:

The date the Transaction Statement was obtained can't be in the future.

Through an import or the API, a missing date gives "Give the date the Transaction Statement was obtained." instead; the dialog marks an empty Obtained On as an invalid field.

When: recording a Transaction Statement (DISC-06).

Cause: Obtained On is after today.

Remedy: a resolution. Select Close, set Obtained On to the day you obtained the statement, and record again.

Who can fix it: Rx Tracking User or Manager.

Error: "Invalid fields: Where Was It Obtained?"

What you see: a red notification "Invalid fields:" listing Where Was It Obtained?, and the field outlined in red. Through an import or the API, the message is "Choose where the Transaction Statement was obtained."

When: recording a Transaction Statement without a source (DISC-06).

Cause: Where Was It Obtained? is empty.

Remedy: a resolution. Choose T3 / Packing-Slip PDF, Supplier Portal, Email, EDI or Other, and record again.

Who can fix it: Rx Tracking User or Manager.

Error: "Supplier file … is no longer awaiting its receipt …"

What you see: one of:

Supplier file FILE is no longer awaiting its receipt; record the Transaction Statement on its 'Transaction Statement missing' discrepancy.

Supplier file FILE affirms the Transaction Statement already.

The Transaction Statement of supplier file FILE is already recorded (DISC/YYYY/NNNNN).

When: recording a Transaction Statement for a supplier file before validation (DISC-06), when the file changed after you opened the dialog, or through the API.

Cause: the receipt became Done meanwhile (the file is Received), the file affirms the statement (a corrected file was imported), or someone already recorded it.

Remedy: a resolution. Close the dialog and reload the receipt.

• If the receipt is Done with a red banner, record the statement after validation: DISC-07.
• If the banner is gone, there is nothing left to record: the Discrepancies smart button shows the recording.

Who can fix it: Rx Tracking User or Manager.

Error: "Choose the discrepancies or the supplier file to record the Transaction Statement for."

What you see: an Invalid Operation dialog when you select Record and Release:

Choose the discrepancies or the supplier file to record the Transaction Statement for.

The dialog lists no Discrepancies and no Lots on Hold. Through the API, the messages are "There is no open 'Transaction Statement missing' discrepancy to record a Transaction Statement for.", "A Transaction Statement can only be recorded on open 'Transaction Statement missing' discrepancies (DISC/YYYY/NNNNN)." or "Choose the discrepancies to record the Transaction Statement for."

When: Actions ‣ Record Transaction Statement on the receiving discrepancies list (DISC-07).

Cause: there is no open Transaction Statement Missing discrepancy to record on. Either it was already resolved (often with Mark Resolved, Known issue PF-A02-03), or the rows you selected in the list are other types of discrepancy.

Remedy: a resolution.

• If the discrepancy was resolved with Mark Resolved and the statement was never recorded, an Rx Tracking Manager opens it and selects Reopen (Reopen a resolved discrepancy); then record the statement (DISC-07).
• In the list, select only open rows of the type Transaction Statement Missing (use that filter).

Who can fix it: Rx Tracking User or Manager; Rx Tracking Manager to reopen.

The lot stays quarantined

What you see: the discrepancy is Resolved, or the Transaction Statement is recorded, but the lot is still Quarantined. Rx Tracking managers may have an activity Lot LOT still quarantined on it.

When: after Mark Resolved (DISC-08) or Record and Release (DISC-07).

Cause: resolving a discrepancy never releases its lot; releasing is a manager's decision. Record and Release releases a lot only when nothing else holds it: no other open discrepancy on the lot, and no quarantine from outside the discrepancies (the lot's Quarantine tab has Held Outside Discrepancies selected). The activity's note names what still holds it.

Remedy: a resolution.

1. Open the lot (Inventory ‣ Rx Tracking ‣ Quarantined Lots) and read its Quarantine tab: the Quarantine Reason lists every hold, with the discrepancy numbers.
2. Resolve the other open discrepancies (DISC-08).
3. An Rx Tracking Manager releases the lot (Release a lot from quarantine). Its Lot … still quarantined activities are then marked done with "Lot released."

Who can fix it: Rx Tracking Manager (the release).

Error: "Write how the discrepancy was resolved first …"

What you see:

Write how the discrepancy was resolved first (DISC/YYYY/NNNNN).

When: selecting Mark Resolved on a discrepancy (DISC-08).

Cause: the Resolution Note is empty.

Remedy: a resolution. Select Close, enter how the discrepancy was resolved in Resolution Note, and select Mark Resolved again. For a Transaction Statement Missing discrepancy, use Record Transaction Statement instead: Mark Resolved records no statement and releases nothing (Known issue PF-A02-03).

Who can fix it: Rx Tracking User or Manager.

Error: "Only a DSCSA manager can reopen a discrepancy."

What you see: an Rx Tracking User has no Reopen button on a resolved discrepancy. Through the API, the call is refused with "Only a DSCSA manager can reopen a discrepancy."

When: trying to reopen a resolved discrepancy (Reopen a resolved discrepancy).

Cause: reopening a resolved discrepancy needs the Rx Tracking Manager right.

Remedy: a resolution. Ask an Rx Tracking Manager to reopen it. See also Error: "Only a DSCSA manager can …".

Who can fix it: Rx Tracking Manager.

A supplier file, a discrepancy or its receipt can't be deleted or changed

What you see: supplier files and receiving discrepancies have no Delete, and their forms have no ⚙ (Actions) menu. Through an import or the API, Odoo refuses with its access message (Known issue PF-W06-04: it doesn't say that the record is kept on purpose):

You are not allowed to delete 'DSCSA Receiving Discrepancy' (dscsa.discrepancy) records.

No group currently allows this operation.

(the same with 'Supplier EPCIS File' (dscsa.epcis.import)). Changing a discrepancy field other than Responsible and Resolution Note through an import or the API gives:

These discrepancy fields can't be changed: FIELDS.

Deleting a cancelled receipt that has a supplier file gives "The operation cannot be completed: another model requires the record being deleted. If possible, archive it instead." naming Supplier EPCIS File (dscsa.epcis.import). When a deletion comes from somewhere that has every right (for example a script run as the superuser), the software's own texts refuse it: "Receiving discrepancies are part of the DSCSA record and can't be deleted; resolve them." and "Supplier EPCIS files are kept as a record of what the supplier sent; cancel the import instead."

When: deleting a discrepancy, a supplier file or a receipt that has one; or changing a discrepancy through an import or the API.

Cause: supplier files and receiving discrepancies are kept as the record of what the supplier sent and what was found. See What is kept, and what can never be deleted or changed.

Remedy: by design; nothing to fix. Cancel an import instead of deleting it (DISC-04); resolve a discrepancy instead of deleting it (DISC-08). See also Error: "… can't be changed" or "… can't be deleted" on a kept record.

Who can fix it: nobody; it is by design.

Error: "Only an import awaiting its receipt can be cancelled …"

What you see: a Received, Superseded or Cancelled file has no Cancel Import button. Through the API:

Only an import awaiting its receipt can be cancelled (FILE is STATE).

When: cancelling a supplier file (DISC-04).

Cause: only a file whose receipt is still open can be cancelled.

Remedy: by design. A received file stays as the record. To correct the stock of its receipt, see Correct a receipt after validation.

Who can fix it: nobody; it is by design.

Error: "… this done DSCSA operation can't be edited …"

What you see: an Oh snap! dialog with one of:

PRODUCT: this done DSCSA operation can't be edited (quantity, lot, locations or product): the package ledger and the DSCSA documents
record it as validated. Use a return, a scrap or an inventory count instead.

PRODUCT can't be added to TRANSFER-NUMBER: 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: saving a done transfer that an Inventory Administrator unlocked (⚙ (Actions) ‣ Lock/Unlock), after changing a DSCSA line or adding one (Correct a receipt after validation).

Cause: done DSCSA lines are recorded in the package ledger and the DSCSA documents; editing them would make those records wrong. Lines of other products are not affected.

Remedy: a resolution. Select Discard changes. Correct the stock with a new receipt, a return, an inventory count or a lot correction, as the table in Correct a receipt after validation shows. The message also names a scrap, but ⚙ (Actions) ‣ Scrap on the done transfer itself is refused for DSCSA units (known issue PF-W09-01, see Error: "… can't be added to …: it is done" when scrapping from a transfer): use a return or an inventory count, or scrap the units on their own (Scrap DSCSA units, naming each unit's serial).

Who can fix it: Rx Tracking User or Manager (the correcting records).

Every unit of the file is a duplicate, and the receipt won't validate

What you see: the supplier file's Duplicates tab lists every unit, Received / Expected shows 0 / 0, scanning a unit is refused (Error: "… is already registered …"), and Validate says "… can't be validated: scan one DSCSA serial for each unit being validated." (the serial-count entry). With the quantity set to 0, Odoo says "You cannot validate a transfer if no quantities are reserved, or if only non-reserved moves are picked.To force the transfer, encode quantities."

When: receiving against a file whose serials are all already in the package ledger (DISC-09).

Cause: the duplicates are never received, so there is nothing to validate; the Duplicate Serial discrepancies are created only by a validation (Known issue PF-W06-03).

Remedy: a workaround.

1. An Rx Tracking Manager quarantines the lot of the units already in the ledger (the lot named on the Duplicates tab): Quarantine a lot.
2. Investigate the suspect product. Your procedure decides how.
3. Cancel the receipt (DISC-04). The file stays on record as Cancelled, with its Duplicates tab.

Who can fix it: Rx Tracking Manager.

A discrepancy is past its deadline

What you see: the discrepancy's form shows the red banner "This discrepancy is past its 10-business-day resolution deadline.", and its row is red in Inventory ‣ Rx Tracking ‣ Receiving Discrepancies.

When: after the Resolve By date of an open discrepancy (DISC-08).

Cause: Resolve By is 10 business days after detection. Nothing reminds anyone before or at that date (Known issue PF-A02-07).

Remedy: a resolution. Resolve it (DISC-08). To see every late one, remove Open from the search box and select the filter Overdue.

Who can fix it: Rx Tracking User or Manager.

Error: "Which holds keep a lot quarantined is recorded by the system."

What you see:

Which holds keep a lot quarantined is recorded by the system.

When: changing a lot's Held Outside Discrepancies through an import or the API.

Cause: Held Outside Discrepancies is set by the software when a lot is quarantined outside the discrepancy flows, and cleared when it is released. Nobody sets it by hand.

Remedy: by design. To hold a lot for another reason, quarantine it (Quarantine a lot).

Who can fix it: nobody; it is by design.

Warnings on a supplier file's Warnings tab

What you see: the receipt's chatter says "… N warning(s): see the import.", and the supplier file's Warnings tab lists them, one per line starting with "-".

When: after Import EPCIS (Read the warnings of an imported supplier EPCIS file).

Cause: the file was imported, but something in it looks wrong or incomplete. A warning never stops the import. The file's own reader writes the technical warnings in English; the others come from the checks against your receipt and master data.

Remedy: find the warning in the entries below and follow their remedy:

The warning is about	Entry
the Transaction Statement	Transaction Statement warnings
the quantity or the purchase order number	Quantity and purchase order warnings
GLNs, parties or locations	GLN and party warnings
lot numbers or expiry dates	Lot and expiry warnings
the product data in the file, or products left out	Product warnings
events, identifiers or the file format	Event and file-format warnings

Who can fix it: Rx Tracking User or Manager reads them; some remedies need the supplier or a master-data change.

Warning: "The seller has not affirmed the DSCSA Transaction Statement in this file …"

What you see: on the Warnings tab, this line, usually with one of the file's own lines below:

- The seller has not affirmed the DSCSA Transaction Statement in this file. We may only accept ownership with a Transaction Statement:
ask the supplier for it.
- The file has no DSCSA transaction statement (GS1 US healthcare extension).
- The file has a DSCSA transaction statement but no affirmTransactionStatement value.
- The supplier did not affirm the DSCSA transaction statement (affirmTransactionStatement is false).

Related lines from the file's reader: "LABEL: affirmTransactionStatement VALUE is not true or false.", "LABEL: DSCSA element 'NAME' is in namespace … instead of …; it was read anyway.", "LABEL: direct purchase statement VALUE was read as 'direct purchase'." and "The file contains a 'NAME' element (…); transaction history in it was not read."

When: after importing a file whose Transaction Statement is missing, not affirmed, or written in an unexpected way.

Cause: the file doesn't carry an affirmed Transaction Statement. The receipt and the file show a banner.

Remedy: record the statement before you validate (DISC-06), or ask the supplier for a corrected file (DISC-03). The lines about the namespace, the direct purchase statement and transaction history are notes: the file was read.

Who can fix it: Rx Tracking User or Manager; the supplier for a corrected file.

Warning: "… the file announces N package(s) but the receipt expects M."

What you see: one or both of:

- PRODUCT: the file announces N package(s) but the receipt expects M.
- The file's purchase order number (FILE-PO) is not ours (OUR-REFERENCES).

When: after importing a file whose units or purchase order don't match the receipt.

Cause: the supplier shipped more or fewer units than the receipt expects, or its file names another purchase order number than the order, its vendor reference or the receipt's source document.

Remedy: check with the supplier. If fewer units arrive, the receipt can go to a backorder (Receive part of a shipment); units the file lists but that don't arrive become Missing discrepancies at validation (DISC-08). If the file was meant for another order, cancel it (DISC-04).

Who can fix it: Rx Tracking User or Manager.

Warning: "… has no GLN in Odoo, so the … in the file (GLN …) could not be checked."

What you see: one or more of:

- PARTNER has no GLN in Odoo, so the ROLE in the file (GLN GLN) could not be checked. Record the GLN so later files are checked.
- The file does not give the ROLE's GLN, so it could not be checked against PARTNER.
- The ship-to location of the file (GLN GLN) is not one of our GLNs.

ROLE is "seller" or "buyer". Lines from the file's reader about parties: "The shipping events name more than one ROLE (…); the first one was used.", "The shipping event does not name the seller (source owning_party).", "The shipping event does not name the buyer (destination owning_party).", and about identifiers: "LABEL: VALUE is not an SGLN or GLN, so this party or location cannot be matched.", "LABEL: VALUE is not a valid SGLN or GLN: …", "LABEL identifier VALUE is not a GLN.", "LABEL: identifier VALUE was not understood: …".

When: after importing a file whose parties could not be compared with the supplier and your company.

Cause: the supplier or your company has no GLN in Odoo, the file leaves a party out, or it ships to a GLN that is not one of yours (your company's, its contacts' and your warehouses' GLNs count).

Remedy: record the missing GLN on the supplier or on your company or warehouse, so the next file is checked (see Troubleshooting: products, partners and licenses). If the file names a party you don't know, ask the supplier for a corrected file (DISC-03).

Who can fix it: Rx Tracking User or Manager with a right to edit contacts (partner GLN); an administrator (company or warehouse GLN).

Warning: "N shipped package(s) have no expiry date …"

What you see: one or more of:

- N shipped package(s) have no expiry date: IDENTIFIERS.
- N shipped package(s) have no lot number: IDENTIFIERS.
- N shipped package(s) have no lot in their commissioning data; the only lot of their product in the file was assumed: IDENTIFIERS.
- Lot LOT of PRODUCT expires DATE in Odoo but DATE in the file.

Other lines from the file's reader: "Lot LOT of product GTIN has two expiry dates in the file (… and …).", "Package ID is commissioned twice with different lot or expiry data.", "LABEL: lot number VALUE is not a valid GS1 lot number (…); it was kept as is.", "LABEL: expiry date VALUE is not a valid date." and "Lot LOT of product GTIN: expiry date VALUE is not a valid date."

When: after importing a file with missing, conflicting or badly formed lot or expiry data.

Cause: the file doesn't give the lot data the package ledger needs, or gives other data than Odoo already has for that lot.

Remedy: compare with the labels on the units, and ask the supplier for a corrected file (DISC-03). A lot the file created without an expiry date gets today's date as its expiry (Known issue PF-T03b-01): correct it before you sell from it (Correct a lot's number or expiry). A different expiry on a unit's label becomes a Wrong Expiry discrepancy at validation (DISC-08).

Who can fix it: Rx Tracking User or Manager; the supplier for a corrected file.

Warning: "Products that are not DSCSA products were left out …"

What you see: one or more of:

- Products that are not DSCSA products were left out: PRODUCTS.
- Product GTIN: the NDC VALUE in the master data is not a valid NDC.
- Product GTIN: the NDC in the master data (VALUE) does not match the NDC in the GTIN; the GTIN was used.
- Product GTIN: the NDC could be VALUE or VALUE; the file does not say which.
- Product GTIN: the file gives no NDC and the GTIN does not embed one.
- Product GTIN is shipped but has no master data (name, NDC) in the file.
- Product GTIN has a case-level GTIN (indicator digit N) but was shipped as a single package without aggregation data.

Other lines about the file's product data: "Master data vocabulary 'TYPE' is not used and was skipped.", "Product master data entry ID was skipped: …" and "Product master data entry ID is not a product class (idpat:sgtin or lgtin); skipped."

When: after importing a file whose product data is incomplete, or that lists products that are not DSCSA products in Odoo.

Cause: the file's product data (NDC, name, case GTIN) is missing or inconsistent, or the file lists a product whose DSCSA Product box is not selected in Odoo. Such products are never touched by Rx Tracking.

Remedy: check the product's NDC and GTIN in Odoo (Set up a DSCSA product). If a product left out should be tracked, turn on DSCSA Product for it and import the file again. Ask the supplier about wrong product data in its file.

Who can fix it: Rx Tracking Manager with a right to edit products.

Warning: "The file has no shipping event …" and other file-format notes

What you see: lines such as:

- The file has no shipping event, so it does not say which packages were shipped.
- No event has bizStep shipping; the events with disposition in_transit were used instead.
- Shipping event N lists no identifiers.
- Package ID is listed N times in the shipping events.
- Shipped identifier ID could not be resolved to packages: REASON.
- Package ID is aggregated into more than one container (… and …).
- The file does not state its EPCIS schemaVersion; it was read as EPCIS 1.2.

The complete list of these lines:

• Events: "LABEL: quantity VALUE is not a number.", "LABEL: eventTimeZoneOffset VALUE is not valid.", "LABEL has no valid eventTime (…).", "LABEL: action VALUE is not ADD, OBSERVE or DELETE.", "LABEL: transformation events are not used for DSCSA; only its output identifiers were read.", "Event(s) NUMBERS are withdrawn by an error declaration and were ignored.", and the lines above.
• Business transactions: "The shipping event has no business transactions; those of the other events were used." and "LABEL: business transaction VALUE is malformed (…); it was kept as is."
• File format: "The NAME element has no namespace; it was read as EPCIS 1.2 anyway.", "The file does not state its EPCIS schemaVersion; it was read as EPCIS 1.2.", "The file declares EPCIS schemaVersion VERSION; it was read as EPCIS 1.2.", "Unknown element 'NAME' in the event list was skipped." and "The file has no EPCISBody."

When: after importing a file with unusual events or structure.

Cause: the file was read, but it is not written the usual way.

Remedy: usually nothing. Scan what arrived: if units the supplier shipped are not in the file, they become Extra discrepancies at validation, and units in the file that didn't arrive become Missing (DISC-08). If the file announces no units at all, ask the supplier for a corrected file (DISC-03).

Who can fix it: Rx Tracking User or Manager; the supplier for a corrected file.