> For the complete documentation index, see [llms.txt](https://docs.unimarket.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.unimarket.com/documentation/troubleshooting/unimarket-to-banner-po-integration-errors.md). # Troubleshooting Unimarket-to-Banner PO Integration Errors This guide provides **functional users** in Procurement and Finance offices with instructions for troubleshooting common errors encountered during the transmission of Purchase Orders (POs) from Unimarket to Banner, and offers guidance on reconciling data between the two systems. ## Interface Logging and Error Notifications When the Banner APIs produce an error during message transmission, the interface logs the activity and triggers an error notification. ### Error Notification Error emails are sent using the Oracle `UTL_MAIL` function to the addresses defined in the **FTMSDAT** record (`FZKEPRC-UM ERROR EMAIL-TO`). These emails contain the document ID and the specific API error message. ### Interface Error Logging Tables (FISHRS Database Schema) | Table | Content Logged | Purpose | | ----------- | ----------------------------- | -------------------------------------------------------------------------------------- | | **FZBEPRC** | Request Log (cXML messages) | Records messages sent from Unimarket to the Banner Interface. | | **FZRCXML** | Banner PO and Invoice API Log | Records Banner PO and Invoice API activity, including the detailed API error messages. | ## General Troubleshooting & Reconciling Steps Purchase Orders that encounter an error in Banner will often exist in an **Incomplete** status. Use these steps to validate and begin resolving the issue: | Step | Banner Form / Report | Action | | --------------------------- | ------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | | 1. Validate Document Status | **FGRIDOC** (Incomplete Documents Report) | Consistently run this report to identify all orders and invoices that are Incomplete and need reconciliation or completion. | | 2. Review Error Details | API Error Email / **FZBEPRC** / **FZRCXML** | Use the error email subject line (e.g., `PROD: Error in OrderRequest (12345)`) and document ID to find the precise error message logged in the tables. | | 3. Complete/Fix Document | **FPAPURR** (Purchase Orders) | If the document is Incomplete, use this form to resolve the error(s) and complete the document accordingly. | ## Common Purchase Order (PO) Errors Use the table below to quickly identify the error, its cause, and the required action: | Error Sample / Subject Line | Primary Cause in Banner | User Action to Resolve | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | |

Vendor Record Error for PO
Vendor address type is required.
Vendor address sequence is required.
Vendor address type and seqno combination is invalid or inactive.

| PO Transaction Date is before the Vendor Effective Date in **FTMVEND**, or the Vendor Address Type/Sequence is missing or inactive in **FTMVEND**. |

1. Check FTMVEND: backdate the vendor's effective start date, or ensure a default Address Type/Sequence is assigned for PO/AP.
2. Resend the Order from Unimarket and check Banner to see if the order appears.
If the dates do not match, update the record in Banner and resend the PO in Unimarket. If the above does not resolve the issue, provide a full screenshot of the FOIDOCH screen for the vendor (including the Address tab) to the Unimarket Support team.

| | Order Already Exists | A previous error occurred and the order was resent from Unimarket, but the header already exists in Banner as Incomplete. |

1. Check FOIDOCH for 3-way match/approval status.
2. If Incomplete, view FPAPURR, resolve the specific error from the API email, and complete the document.

| | Invalid Purchase Order Code | A user attempted to close a PO in Unimarket that does not exist in Banner. | Review the order in Unimarket to confirm there are no invoices against the order and that receiving has been manually closed. No action required — this is a non-impacting informational error. | | Vendor ID error (e.g., `Path //SupplierID[1]... not found` or `Invalid value for vendor`) | The Vendor ID is missing or incorrect in the Manage Supplier record in Unimarket. |

1. Check Unimarket: verify the correct Vendor ID is present.
2. Contact Unimarket Support to configure a default Vendor ID sequence for better error messages.

| | ShipTo location code is invalid | The ShipTo code used is not valid or inactive in Banner form **FTMSHIP**. |

1. Check FTMSHIP: reactivate the code or confirm the code's effective date is before the Transaction Date of the PO.
2. Update Unimarket, or manually update the PO in FPAPURR if a resend fails to pick up the updated code.

| | `Document has incomplete docs: Incomplete Invoice exists against Purchase Order UP122375.` | This occurs when a user attempts to close a Purchase Order in Unimarket while an associated invoice in Banner remains in an Incomplete status. |

1. Locate the invoice: search for it in Banner using form FAAINVE (Invoice/Credit Memo Header).
2. Alternatively, run the FGRIDOC (Incomplete Document Listing) report to find all documents preventing the PO from being finalized.
3. Once the invoice is completed and approved in Banner, the PO can be successfully closed in Unimarket, or resend the close message from Unimarket.

| | `Purchase Order cannot be invoiced.` / `Purchase order has been canceled.` | The PO was closed or cancelled in Banner. | Investigate why the PO was closed/cancelled in Banner. If payment is valid, reopen the PO in Banner and resend the invoice. If the cancellation was correct, cancel the invoice in Unimarket. | | `Location XXX is invalid.` |

1. Missing code: the location code (e.g., S09) has not been set up in the ERP's validation tables.
2. Inactive status: the code exists but has been terminated or marked inactive for the current fiscal period.
3. Mapping issue: the code in Unimarket does not exactly match the code in the ERP (case sensitivity or leading zeros).

|

1. Check the ERP record: look up the location code in Banner form FTVLOCN. Ensure the code is active and the "Terminated" date is blank or in the future.
2. Verify the Unimarket profile: check the user's default shipping address or the specific line item on the requisition to see if the location was entered correctly.
3. Resend after fix: once the code is reactivated in the ERP, go to the Unimarket portal and resend the failed document.

| | `Purchase order does not exist.` / `Must be created before it can be referenced` | The Purchase Order mentioned in the invoice cannot be found in the Banner PO tables (`FPBPOHD`). |

Step 1 — Manual resend from Unimarket: go to Marketplace, locate the Order, select More Actions > Order Message to re-push the cXML to Banner. Wait 5–10 minutes and check Banner.
Step 2 — Vendor maintenance check (FTMVEND): if the order still does not appear, review the vendor record for valid Procurement/Accounts Payable address defaults with Type Codes and an associated Sequence Number. If missing or null, the API will fail to create the PO header.

| | `Purchase order has not been posted.` / `Cannot be referenced` | The Purchase Order record exists in Banner but is in an Incomplete or Suspended status, and has not yet posted to the ledgers. | Query the integration log tables in schema `FISHRS`, tables `FZRCXML` or `FZBEPRC`. Search by the PO number (`FZRCXML_DOC_ID`) to find the error message in `FZRCXML_ERROR_MSG`. Common findings: **NSF** (budget exceeded), **Invalid Accounting** (a FOAPAL element is closed or inactive), or **Vendor Hold** (the vendor was placed on hold after the requisition was approved). | | `Purchase Order cannot be invoiced.` / `Purchase Order not completed or approved.` | The PO is not complete or approved in Banner. | Review the order in Banner and determine why it isn't complete or approved. You may need to back out/remove it and then resend the PO from Unimarket. | | `UP122375: Unable to select PO.` | | Review the **FGIENCD** screen. If the status is Open (O), the error message is expected. If no additional invoices are expected against this PO, manually close the order in **FPAEOCD**. | | `Commodity code XXXXX is not valid as of XX-NOV-XXXX` | | Cancel the PO and create a new PO with a commodity code that is active in Banner. Note: once a PO is Completed and Approved in Banner, the commodity code cannot be updated. | | `PO already closed in Banner` | | No action required by customer or Unimarket. | | `PO is general encumbrance. Close with Banner Forms.` | | Customer must use Banner to close the PO. | | `Pending Documents in Banner cannot close the PO` | | Make sure the Invoice is completed before the PO can be closed. Once completed, resend the Close Order Message from within Unimarket. | | `Another batch close process session is running. Resubmitting...` | Likely caused by a locked record. | Check the Banner database table `FOBPROC` for a record. If one exists, delete it and resend the Close Order Message from Unimarket for the affected PO. | | `*ERROR* Vendor address type RM and seqno 1 combination is invalid or inactive.` | The PO or Blanket Order date is before the Vendor effective date, or the Vendor Addresses in **FTMVEND** do not have an assigned sequence number or default. | The error on the order must be resolved before the invoice can be resent in Unimarket. Reach out to the team that manages vendor profiles to confirm there are no issues with the RM address in Banner, then confirm the PO looks correct on the **FOIDOCH** screen. Compare the PO order date (in Unimarket) against the vendor's Start Date in **FTMVEND**. If the dates match, resend the order in Unimarket. If they don't match, update the vendor record in Banner (backdate the start date) and then resend. If unresolved, contact Unimarket Support with a full screenshot of the **FOIDOCH** screen (including the Address tab), the order number, the error received, and the troubleshooting steps taken. | | `Purchase Order is valid but failed available balance check` / `PO deleted from Banner System.` | The budget check that happens as part of PO creation failed and deleted the PO from Banner. | Option 1: transfer budget to the FOAP the PO needs. Option 2: cancel the PO or use a different FOAP with sufficient budget. If you don't want this to happen and want POs created in Banner even when funds are unavailable (going into an NSF state, depending on Banner settings), change the **FOMPROF** permissions for the UNIPO user so it has the `NSF_Override` permission. **Note:** NSF override applies to all orders — the budget check at Checkout will still catch NSFs, which also resolves the issue for change orders when the budget is still encumbered in Banner. | ## Common Accounting or Budget Errors These errors relate to accounting/FOAPAL or budget issues. | Error Sample / Subject Line | Primary Cause in Banner | User Action to Resolve | | --------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Program Code Required | The ORGN code on the FOAPAL does not have a default PROG code set up in Banner, and the PROG was not entered in Unimarket. |

1. Update the ORGN default PROG in Banner.
2. Manually update the PO in FPAPURR, or delete the PO and resend from Unimarket.

| | Buyer User Does not have proper Fund/Orgn Access | The Buyer's user ID is missing the required Fund/Organization access on Banner forms like **FOMPROF**. |

1. Grant the Buyer the necessary Fund/Orgn access in Banner.
2. Reprocess the order in Banner, or delete and resend from Unimarket.

| | Mixed Expense Accounting (GL, Operational, Fixed Asset Accounts) | General Ledger, Operational Expense, and Fixed Asset accounts were used on the same order. | Manually update the PO in **FPAPURR** to separate the account types onto different documents or lines. Note: newer Unimarket versions catch this error at checkout. | | Purchase Order is valid but failed the available budget/balance check | Insufficient budget available (e.g., multiple large POs approved simultaneously outstripped the budget before encumbrance). |

1. Check budget: use FGIBAVL to confirm budget availability.
2. Resend the PO to Banner once the budget issue is resolved.

| | Accounting Period Closed in Banner | The PO Transaction Date is not within an open accounting period for the Chart of Accounts in Banner. | Reopen the accounting period in Banner and then resend the order from Unimarket. | | Mixing asset and non-asset accounts results in an incomplete fixed asset record | Banner's Fixed Asset API expects a clean relationship between the procurement document and the asset record. When a single PO or Invoice contains a mix of asset and non-asset accounting codes on the same line or document, it often results in an incomplete or "orphaned" fixed asset record. Capital accounts are typically tied to fixed asset tagging in Banner, and the Banner API does not allow regular expense accounts and capital accounts to be charged on the same PO. If unsure whether an account is set up as an asset account, check with your Accounting team/Controller's Office. |

1. Identify the document: locate the PO or Invoice in FZBEPRC or FZRCXML to see how the accounts were distributed.
2. Manual correction in Banner: access FFAMAST (Fixed Asset Master) or FAAINVE and manually complete the asset information (Manufacturer, Model, Serial Number) that failed to pull from the Unimarket cXML.
3. Adjust the encumbrance: if the error happened on a PO, ensure the encumbrance in FMAPO reflects the correct capital amount so the subsequent invoice doesn't repeat the error.

| | Accounting Record Errors for sequence 1 — `*ERROR* Transaction date 01-JUL-2025 is not in an open accounting period for chart 1.` | The accounting period for the PO Order Date is closed in Banner. | Reopen the applicable accounting period, then resend the PO in Unimarket to Banner. | ## Common Change Order and System Errors These errors relate to blanket orders, change orders, or system configuration. | Error Sample / Subject Line | Primary Cause (Where to Check) | Action to Resolve | | ---------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Change or Update attempted before PO Posted (`ORA-00001: unique constraint... violated`) | A change (e.g., cancellation) was attempted on a PO that is still in process and has not yet been posted in Banner. |

1. Verify the standard PO posting process is running.
2. Wait for the PO to post, then resend the change/update message from Unimarket.

| | Blanket Order Not Found for Release Order (`Parent PO with orderID UP122375 not found!`) | The Parent Blanket PO is either Incomplete in Banner or was never successfully posted. |

1. Check FOIDOCH or FPAPURR: resolve the underlying error on the Blanket PO first.
2. Resend the Blanket PO, then resend the Release Order.

| | Change Order where the FUND is no longer active | Most common with Grant/Sponsored Accounts: a change is attempted on an order where the FUND Term Date in Banner has passed. |

1. Discuss with Grant/Finance Office to reopen the FUND.
2. Alternatively, cancel the order in Unimarket.

| | Blanket Release Order — Could not create JV detail for PO | The encumbrances have not rolled to the next fiscal year, and the JV is using the system date to post the release order in the new fiscal year. | Create a manual **E035 Journal** in Banner to ensure the balance is the same in both systems. | | Cannot Cancel: Type "delete" is not supported | Cancel Order is enabled in Unimarket, but the Banner Interface is not configured to handle the `Request Type="Delete"` integration message. |

1. Manually cancel the PO in Banner.
2. Contact Unimarket Support to upgrade the interface to include the Cancel PO code.

| | FOMPROF User Organization - Data Entry not allowed | The user ID used to post the PO has a home Organization (**FOMPROF** record) that is not marked as Data Enterable in **FTMORGN**. |

1. Check FTMORGN: verify the user's home org in FOMPROF is Data Enterable ('Y').
2. Change the user's home org in FOMPROF to a Data Enterable one and resend the PO.

| | Deadlock Detected (`ORA-00060: deadlock detected`) | Banner is receiving too many requests for processing at once (system congestion). |

PO not in Banner: verify the PO is not in Banner via FOIDOCH or FPIPURR; if not, resend the PO from Unimarket.
PO in Banner and not posted: if the PO appears in FOIDOCH with a blank/not-approved status field, use FPAPURR to delete the Incomplete PO record, then resend the PO from Unimarket.

| | The Account is Locked (`ORA-28000: The account is locked`) | The dedicated integration user account (`UNICON`) is locked (often after a database refresh/clone). | Contact IT to unlock the `UNICON` account and update the password in the `connector.properties` file. | | Clone of Prod to a DEV or PPRD Banner Instance (Wrong Deployment Mode "Production") | The Banner Connector configuration is incorrect for the target Banner environment (e.g., Development/Test). | Contact IT to verify the correct Deployment Mode is configured in the Banner Connector properties file for the specific Banner instance. | {% hint style="info" %} For related issues, see [Invoices Not Appearing in Banner](/documentation/troubleshooting/invoices-not-appearing-in-banner.md), [Purchase Orders Not Appearing in Banner](/documentation/troubleshooting/purchase-orders-not-appearing-in-banner.md), and [Cancel Order Not Appearing in Banner](/documentation/troubleshooting/cancel-order-not-appearing-in-banner.md). {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.unimarket.com/documentation/troubleshooting/unimarket-to-banner-po-integration-errors.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.