When an order is cancelled in Unimarket, a cXML message is sent to Banner to liquidate the encumbrance. If the cancellation does not reflect in Banner (e.g., the PO remains "Open" in FPIPURR or FGIENCD), follow these steps to identify and resolve the bottleneck.

Primary Diagnostic Step: Check FZRCXML

The most reliable way to find why a cancellation failed is to check the Banner API log table.

SQL Query:

SELECT FZRCXML_DOCUMENT_ID, FZRCXML_ERROR_MSG, FZRCXML_ACTIVITY_DATE 
FROM FISHRS.FZRCXML 
WHERE FZRCXML_DOCUMENT_ID = 'P0XXXXXX' -- Replace with your PO number
ORDER BY FZRCXML_ACTIVITY_DATE DESC;

Common Functional Blocks

A. Incomplete Invoices (The "Incomplete Docs" Error)

Banner will block a PO cancellation if there is an "Incomplete" purchase order or invoice associated with that PO. Even if the invoice was never finished, its existence "locks" the PO record.  This error can also occur if a Change Order is associated with the PO.

• Error Message in FZRCXML: 
  • Document has incomplete docs: Incomplete Invoice exists against PO
  • Document has incomplete docs: Incomplete Change Order exists against PO

• Action: 1. Search for the PO number in Banner form FGRIDOC (Incomplete Document Listing) or FAAINVE.

  2. Delete or Complete the incomplete invoice in Banner.

  3. Once the invoice is cleared, return to the PO in Unimarket, then More Actions > Close Message to resend the cXML.

B. Fiscal Year Restrictions

If the order belongs to a prior fiscal year that has already been rolled and closed, the Banner API may reject the cancellation because it cannot modify the old year's encumbrance.

• Error Message in FZRCXML: Encumbrance does not exist in the fiscal year in which the transaction date falls.

• Action: 1. Verify the current Fiscal Year status in Banner.

  2. If the year is closed, your Finance team must manually liquidate the PO in the current year via FPAEOCD.

C. Fully Invoiced Line Items

If all lines on the PO have been fully invoiced (even if the payment hasn't been sent), the PO is considered "exhausted" in Banner.

• Action: Verify the PO is closed and fully liquidated in Banner form FGIENCD. If it is still Open then search for an incomplete document associated with the PO.

Technical & System Blocks

A. Integration Queue (FZBEPRC)

Check if the cancellation message is stuck in the raw request table.

SQL Query:

SELECT FZBEPRC_ID, FZBEPRC_STATUS, FZBEPRC_DATE_TIME 
FROM FISHRS.FZBEPRC 
WHERE FZBEPRC_CXML LIKE '%P0XXXXXX%' -- Replace with your PO number
ORDER BY FZBEPRC_DATE_TIME DESC;

• Status = 'PENDING': The integration listener may be down.
• Status = 'ERROR': The message reached Banner but the API failed (refer back to FZRCXML).

B. Oracle 19c Permissions

As noted in the Integration Troubleshooting Guide, if you recently upgraded to Oracle 19c, the FISHRS user requires specific permissions to handle background jobs.

• Requirement: GRANT CREATE JOB TO FISHRS;
• Impact: Without this, automated retries for cancellations (especially those hitting "Deadlocks") will fail.

Manual Resolution Process

If the integration cannot be fixed immediately and the budget needs to be released:

1. Banner Manual Liquidation: Use form FPAEOCD to manually liquidate the PO encumbrance to $0.00.
2. Unimarket Synchronization: Ensure the Unimarket order is marked as "Cancelled." If the integration "Resend" continues to fail after manual liquidation, contact Unimarket Support to "Force Complete" the record in the Unimarket logs to stop the retry attempts.

Technical Note: Always check for ORA-00060 (Deadlock detected) in the logs. This often occurs if multiple users are trying to access the same vendor or PO record simultaneously. A simple Resend from Unimarket usually fixes this.