When there is an error transmitting or creating any of the integration messages or documents into Banner, the Banner APIs produce an error. The Interface logs the API error in the FZBEPRC and messages from Unimarket in the FZRCXML table. The Interface also triggers error emails to one or multiple email addresses defined in the FTVSDAT records (FZKEPRC-UM ERROR EMAIL-TO). The emails are sent using the Oracle UTL_MAIL function from the underlying Oracle database of Banner.

This document will focus on the troubleshooting of the common errors received during new customer setup, testing and general usage.

 

Interface Logs

FZBEPRC Request log table – cXML messages from Unimarket to Interface

FZRCXML Banner PO and Invoice API log table

 

Order Common Errors

Vendor Record Error for PO

Sample

Header Record Errors

*ERROR* Vendor address type PO and seqno 2 combination is invalid or inactive.

Sample 2

Header Record Errors

*ERROR* Vendor ID 00866219 is not valid as of 10-MAY-2017

*ERROR* Vendor address type is required.

*ERROR* Vendor address sequence is required.

*ERROR* Vendor address type and seqno combination is invalid or inactive.

Action

A few possible causes for this error are that the PO or Blanket Order Date is before the Vendor effective date, or the Vendor Addresses in FTMVEND do not have assigned sequence number or defaults.

If the vendor address in FTMVEND does not have an assigned sequence number or default, go to the Vendor Maintenance tab information to ensure that the address defaults for Procurement and Accounts Payable have set Type Codes for the default address and those also have a Sequence number applied, as shown below. 

 

Order Already Exists

Sample

EPUNIMARKET orderID UP123173(UP123173) already exists in the system

Action

The purchase order from Unimarket hit Banner and Banner already has a PO with that number. This generally happens when an order has an error but someone looking in Banner expects to see the order. When they don’t see the order, they resend it and the order header information is already existing in Banner but the commodity level information has the error.

Search error emails or logs for that order number to see if there are any other errors that need to be resolved before resending the order message from Unimarket to Banner.

 

Vendor ID error

Sample

Path //ItemOut[1]//SupplierID[1][@domain="external-id"] not found

Sample 2

API Error:

Invalid value for vendor

Action

Check the Vendor ID in Unimarket to make sure there is a vendor ID entered in the Manage Supplier, Edit Supplier window. The vendor ID may not be correct or may not be present at all.

 

ShipTo location code is invalid

Sample

Header Record Errors

*ERROR* Ship code D390 is not valid for 20-MAR-2017

Action

Check that there is a valid ShipTo location in Banner with the attempted code. Update Code appropriately in Unimarket or make active in Banner.

Resend order from Unimarket if ShipTo was reactivated in Banner.

If ShipTo code was incorrect in Unimarket, resending the order may not pick upm and use the updated ShipTo code if the change was made on the shipping location in Unimarket so a manual update to the PO in Banner may be required.

 

Program Code Required

Sample

Accounting Record Errors for sequence 1

*ERROR* Program code is required.

Action

If the FOAPAL structure in Unimarket does not contain the Program element of the FOAPAL because the Banner PO API defaults the PROG based on the ORGN code so you have chosen not to require the users to enter the PROG code in Unimarket you may get this error if you do not have a Default PROG code setup for every ORGN or you have multiple PROGs for 1 ORGN.

Manual update to the PO will be required in Banner or update the ORGN default PROG, delete the existing PO in Banner with the error and resend from Unimarket.

 

Buyer User Does not have proper Fund/Orgn Access

Sample

Accounting Record Errors for sequence 1

*ERROR* User JDOE does not have authority to post to chart 1, Fund 414140 and organization 425431

Action

If you are not using the Fund/Orgn checking at the time of checkout a user that does not have the proper Fund/Orgn access will be able to initiate a requisition. When that requisition is finally approved and hits Banner, Banner does another Fund/Orgn Access validation on the buyer.

Granting the Buyer user the needed access in Banner then reprocessing the order in Banner or deleting the Banner PO and resending the order from Unimarket to Banner would be needed.

 

Currency on PO not recognized in Banner

Sample

Header Record Errors

Currency code is invalid

Action

Unimarket allows for supplier to register with their own local currency and does a currency conversion update nightly. Unimarket provides both the supplier local currency and customer local currency in the order and invoice messages. the Interface uses the main currency which would be the supplier’s local currency is allowed. Banner has a Currency table for the referenced currency codes but most customers do not have that setup.

This can be avoided by reviewing any supplier registrations for currency other than USD or local customer currency and asking Unimarket to change the supplier’s currency to the customer’s local.

If this happens, a manual update to the PO in Banner is needed and the supplier may need to register again with the preferred currency.

Modification to the interface is possible to recognize when a non-customer local currency is used and for the interface to use the “alternate-currency” provided by Unimarket in the cXML order message. 

 

Line Level Unit Price is Greater than 4 decimal places

Sample

Document Edit errors

*ERROR* Accounting amounts are not equal to the commodity extended amounts.

Action

If the entered Unit Price in Unimarket is $0.10596 (5 dp), Banner will attempt to round that to 4 decimal places equaling $0.1060 then calculate times the line item quantity. The Accounting amount and Commodity Extended amounts in Banner use different number of allowed decimal places so their calculations will be different.

Manual edit of the PO to allow for it to post is needed directly in Banner.

 

Change or Update to Order attempted before PO Posted

Sample

API Error:

*ERROR* ORA-00001: unique constraint (FIMSMGR.FOBAPPD_KEY_INDEX) violated

Actions

If a PO has not yet been posted in Banner and a change or update to that existing PO like a cancelation is attempted before the PO is posted, the interface will trigger this error.

Make sure that the posting process is running properly.

Wait to make sure the PO posts then apply the update or change in Banner or ask Unimarket if the change/update message can be resent.

 

Cannot Cancel a Canceled PO

Sample

Purchase Order ID: EP013427 does not exist. Cannot cancel.

Sample 2

Header Record Errors, *ERROR* Purchase/Blanket order document previously

cancelled or closed.

Action

If a PO or Blanket Order has been canceled in Banner directly then it is attempted to be Canceled in Unimarket, Unimarket will send a message to Banner to attempt to cancel the order again.

No action required unless the initial cancellation was not known or expected then there may need to be an investigation into why it was canceled directly in Banner.

 

Mixed Expense Accounting

Sample

Document Edit errors

*ERROR* Cannot mix GL and expense accounting.

*ERROR* Cannot mix GL and expense accounting.

Action

When General Ledger Accounts, Operational Expenses Account and Fixed Asset Accounts are used on the same order Banner does not allow that on the same order.

 

Blanket Order Not Found for Release Order

Sample

Blanket PO not found for release orderID EP012541

Sample 2

Parent PO with orderID UP122375 not found!

Action

Release order sent to Banner has the above error that the Parent POP cannot be found. The Blanket likely had an error that needs to be resolved and have the blanket PO resent to Banner to post before the Release order can be resent to be processed against the existing Blanket order.

 

Blanket Order Not Found for Release Order

Sample

UB388138: Purchase Order has not been posted.

Action

The error indicates that the funds couldn't be released back to the budget because the original PO never posted. Check the FOIDOCH to see if the original blanket ever posted as complete, or otherwise check FPAPURR.

 

Change Order (Blankets mainly) where the FUND is no longer active

Sample

FPBPOHD_CODE: 

PO-EP010725 ITEM-1 SEQ-1  ~{101010} Create or Change Order Accounting Record

errors for sequence 1, ::Fund code 306598 has been terminated and user UNICON

has no authority to post beyond the termination date.::

Action

This happens most often with Grant or Sponsored Accounts when the FUND from the grant has been terminated by the Term Date in Banner but the PO or Blanket Order in Unimarket has not been closed. If a change is attempted to the order, Banner will produce this error.

These should be caught most of the time when the BBA and Fund/Orgn security check is happening during the change order unless a budget check is not needed for a reduction in the order.

Discuss with the grant office to reopen the FUND or Cancel the order in Unimarket.

 

Requisition # Already Exists

Sample

Document Edit errors

*ERROR* Document# RQ31226 already exists in the system.

*ERROR* Purchase Order failed validation.

Action

No action required. This is a warning message that only happens when you have the Cross-Supplier Checkout feature enabled in Unimarket to allow for 1 requisition to have multiple supplier items within it. When the PO goes to Banner, multiple orders have the same requisition number reference which causes this message. The POs are created and posted fine in Banner.

Cancel Order feature give error that Type “delete” is not supported

Sample

Interface Error:

Request Type "delete" not supported

Action

Cancel Order feature is enabled in Unimarket but your Banner Interface does not handle the Cancel Order integration message that have the Request Type=”Delete”.

Manually cancel the PO in Banner or upgrade the interface to add the Cancel PO code to the PO package.

 

FOMPROF User Organization -  Data Entry not allowed

Sample

UM Order ID: XU024337

FPBPOHD CODE: XU024337

VENDOR CODE: 000709856

 

Header Record Errors

Code 32700 . No Data Entry allowed.

Code 32700 . No Data Entry allowed.

Action

The PO Header Record Error "Code XXXXX. No Data Entry allowed" usually means the FOAPAL elements in the PO is not marked as Data Enterable in Banner. 

Step 1, review the FOAPAL “code” from the ERROR. If the FOAPAL “code” in the error is NOT the FOAPAL used on any of the order lines it is more likely an issue with the user FOMPROF record in Banner. 

Step 2, check the roles for the buyer on the order. If you see that the buyer is a browser in Unimarket, perhaps they don’t  have the proper setup in Banner. (We would encourage that Browsers not be listed as members of Blanket Orders so they aren't accepting transactions, as Banner won't play nice if their FOBPROF record isn't set up to let them buy. A simple fix if this is the case, would be to 'edit' the buyer on the release order to an adequate buyer, then resend the PO to Banner.)

The customer should check on the buyer’s home ORGN.  It would be set in FOBPROF and should be marked as Data Enterable or the home ORGN should be switched to one that is Data Enterable for the buyer.

 

Deadlock Detected

Sample

Error in p_get_po_data:

Last called f_get_val(Accounting_Charge)

ORA-00060: deadlock detected while waiting for resource

Action

This error is typically related to Banner receiving too many requests for processing at one time.  To resolve the error:

1. Verify if the PO record has posted to FOIDOCH.  
   1. If the PO does not appear in FOIDOCH, resend the PO message from Unimarket and confirm it posts correctly.
   2. If the PO does appear in FOIDOCH, the status field is likely going to be blank/not approved.
      1. Use FPAPURR to delete the incomplete PO record
         1. In FPAPURR, enter the PO#, NEXT BLOCK once, then click delete twice to remove the record
      2. Once the PO record is deleted, resend the PO message from Unimarket and confirm it posts correctly in FOIDOCH

 

The Account is Locked

Sample

 Error Message in Response for Invoice or PO: Could not get JDBC Connection; nested exception is java.sql.SQLException: ORA-28000: The account is locked. 

 

Action 

This error is typically related to access to Banner from the Connector. Usually found in a DEMO environment after a refresh, it means that the UNICON user account is locked so no integration messages are getting over to Banner. Ask the IT person to unlock the account and reset the password. 

If you can set the correct password on the connector.properties file on the server in the UCP-Test directory, then restart the service, that will re-establish the connection for Unimarket Demo to Banner Test. 

We recommend that institutions have the Connector properties file set with a consistent Unicon password for Production and Demo to avoid these errors after each clone.  

 

Invalid Organization Field in Banner

Sample

API Error:

Organization 72251 is invalid.

Action

The org field within Banner was invalid so the order could not be posted to Banner

The first step is to review the Buyer's FOMPROF record. In this case, there was an error response “Organization has been terminated.” Whenever the PO posts to Banner, there is an org field filled in within Banner based on the default org assigned in the users FOMPROF record (similar concept to an org unit in Unimarket). When the order record is posting, it cannot default to an invalid home org unit for a user so it will send back this error.

 

Accounting Period Closed in Banner

Sample

Accounting Record Errors for sequence 1

*ERROR* Transaction date 27-FEB-2023 is not in an open accounting period for chart 1. The customer should reopen the accounting period in Banner and then resend the order. 

Action

If this error comes up it usually is due to the accounting period for the Order Date being closed in Banner and the community will need to reopen and then resend or action. 

 

Clone of Prod to a DEV or PPRD Banner Instance

Sample

*ERROR* UM: INGR: Error In OrderRequest - Wrong Deployment Mode "Production" for Banner instance INGR (INGR will be customer specific based on what they name their Banner Instance)

Action

We've typically seen this error happen during a clone of Prod to a DEV or PPRD Banner instance or if a customers Demo Connector has been pointed to their Production Banner environment.

Customer should check with their internal team to see if they know which Banner Environment INGR is? (Note that it may not be INGR but you will check on the name that is listed in your error). Also, customer should check with their team to see if they have done a clone of Prod recently.