Below you will find common Single Sign-On errors and troubleshooting steps. 

 

Single Sign-On Error 1

Single Sign-On request to Unimarket failed.

The Authentication Service configured for your Community did not authenticate you or did not return a valid response. Please try again or contact your administrator.

 

Cause:

This error indicates there is an issue on the community side and the user cannot be successfully validated.

Troubleshooting Steps:

We recommend reaching out to your IT team to check the users details, in your identity management system. 

If the above does not resolve the matter, reach out to the Unimarket Support team with the following information:

• The user's first and last name and
• Date and time stamp when the error occurred 

Note: This is usually not an issue on the Unimarket side; unless a new development has rolled out.

 

Single Sign-On Error 2

Single Sign-On request to Unimarket failed.

Auto-Provisioning not enabled

 

Cause: 

This error indicates the user tried to log into Unimarket via SSO with user login credentials and they do not exist in Unimarket, and the community is configured to not to permit.

Troubleshooting Steps:

• Check inside Unimarket to confirm if the user login has been created.
• If user login credentials has been created, compare the SSO username and the Unimarket username. To ensure the usernames are exactly the same. 
  • If the username is not the same, make updates.
  • If the username is the same, please reach out to the Unimarket Support team with the following information:
    • • The SSO username
      • The Unimarket username and
      • Date and time stamp when user last attempted login

 

Single Sign-On Error 3

Your account has been locked. Contact your support person to unlock it, then try again.

 

Cause:

This error occurs when the user login credentials have been locked. Usually due to inserting incorrect password multiple times.

Troubleshooting Steps:

• Check Unimarket for duplicate user logins created.
  • If there are duplicate logins, please deactivate the desired login and ask user to use the forgotten password feature to reset password.
• Determine if the user is able to access other customer portals. To identify, if issue is occurring with  logging into Unimarket or logging into other community applications.
• If your community is using SAML SSO, make sure the user login is enabled, in Unimarket.

If the above does not resolve the matter, reach out to your IT team to check SAML setup for the user. To determine if the user is logging into Unimarket via Single Sign On.

 

Single Sign-On Error 4

Single Sign-On request to Unimarket failed
The user account is disabled. Please contact your Administrator

 

Troubleshooting Steps:

Please reach out to the Unimarket Support team with the following information:

• The user's first and last name and
• Date and time stamp when the error occurred 

 

Single Sign-On Error 5

Single Sign-On request to Unimarket failed

Authentication Service Error

 

Troubleshooting Steps:

• Ask user to clear cache and use a different web browser to access Unimarket.

If the above does not resolve the matter, reach out to the Unimarket Support team with the following information:

• • The user's first and last name and
  • Date and time stamp when the error occurred 

 

Single Sign-On Error 6

Single Sign-On request to Unimarket failed

Missing data

 

Troubleshooting Steps:

We recommend reaching out to your IT team to check the users setup, in their identity management system. 

If the above does not resolve the matter, reach out to the Unimarket Support team with the following information:

• The user's first and last name and
• Date and time stamp when the error occurred 

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 FTMSDAT records (FZKEPRC-UM ERROR EMAIL-TO). The emails are sent using the Oracle UTL_MAIL function from the underlying Oracle database of Banner.

Sometimes, orders and invoices can make it to Banner but need adjusting. This document will focus on troubleshooting the common errors received during new customer setup, testing, and general usage, as well as instructions to reconcile between the two systems. It is intended to be used by functional users within Procurement and Accounts Payable Departments.

 

Interface Logs

When there is an error transmitting or creating any of the integration messages into Banner, the Banner APIs produce an error. The Interface logs the API activity, including error messages in two tables:

• FZBEPRC Request log table – cXML messages from Unimarket to Interface
• FZRCXML Banner PO and Invoice API log table

Purchase Orders and Invoices can make it to Banner when they error out, but they will come in as Incomplete. This allows you to fix the error in Banner and then complete the document accordingly. You should consistently run the Incomplete Documents (FGRIDOC) report from Banner to validate that all purchase orders and invoices are complete. Look at the error emails for the orders or invoices with issues to show you further why it failed.

The sample API emails below are the most commonly encountered. The user's action to resolve the issue is also listed.

API Error Email Sample for Order Summary:

Order Common Errors

Vendor Record Error for PO

Sample 1

Subject from API email: PROD: Error in OrderRequest (254643)

Header Record Errors

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

Sample 2

Subject from API email: PROD: Error in OrderRequest (254642)

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, and the Vendor Addresses in FTMVEND do not have an assigned sequence number or defaults.

If you see that the Order Date (on the PO inside of Unimarket) is before the Vendor effective date (shown on the FTMVEND form in Banner under the Vendor Maintenance tab in the start date box), you can fix this by backdating the start date on the Vendor Maintenance tab to before the date of the PO.

If the Address Type is missing, check the FTMVEND form for that Vendor. The Vendor Maintenance tab should have a default address type code and sequence listed for Procurement and Accounts Payable, as shown below. After Banner has been updated, the Order in Unimarket will need to be resent.

 

Order Already Exists

Sample

Subject from API email: PROD: Error in OrderRequest (10290)

EPUNIMARKET orderID UP123173(UP123173) already exists in the system

Action

The purchase order from Unimarket hits 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 already exists in Banner, but the Purchase Order is in an incomplete status.

Check FOIDOCH for 3-way matching and approved status for Purchase Order. If matched and approved, no additional actions are required.

If not approved, view FPAPURR and search for the Purchase Order. Resolve the error(s) found in the API error email and complete the document.

To prevent this from happening in the future, 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 1

Subject from API email: PROD: Error in OrderRequest (3281742)

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

Sample 2

Subject from API email: PROD: Error in InvoiceDetailRequest (471954)

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.

Contact Unimarket Support at support@unimarket.com to request that a default Vendor ID sequence be configured in your Unimarket tenant so that the error is more descriptive and provides the defaulted Vendor ID like “NEEDS ID #.”

 

ShipTo location code is invalid

Sample

Subject from API Email: PROD: Error in OrderRequest (247490)

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 on form FTMSHIP.

Resend order from Unimarket if ShipTo was reactivated in Banner.

If the ShipTo code was incorrect in Unimarket, resending the order may not pick up 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 on FPAPURR may be required.

 

Program Code Required

Sample

Subject from API email: PROD: Error in OrderRequest (123053)

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

Subject from API email: PROD: Error in OrderRequest (499054)

Accounting Record Errors for sequence 1

*ERROR* User JDOE does not have authority to post a 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 on FOMPROF and its associated forms 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

Subject from API email: PROD: Error in OrderRequest (296555)

Header Record Errors

Currency code is invalid

Action

Unimarket allows a 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. 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 via submitting a helpdesk ticket at support@unimarket.com.  There is also the option to switch off the ability to allow foreign currencies on the Manage Suppliers Administration section under the Registration tab.  This will only affect new supplier registrations.

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.

Contact Unimarket Support at support@unimarket.com for more information on modifying the interface.

 

Line Level Unit Price is Greater than 4 decimal places

Sample

Subject from API email: PROD: Error in OrderRequest (28814)

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 numbers of allowed decimal places, so their calculations will differ.

The PO must be manually edited on Banner form FPAPURR to post.

 

Change or Update to Order attempted before PO Posted

Sample

Subject from API email: PROD: Error in OrderRequest (407362)

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 1

Subject from API email: PROD: Error in OrderRequest (90950)

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

Sample 2

Subject from API email: PROD: Error in OrderRequest (90951)

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. In the baseline version 4.5, we have improved this error to be shown in the Checkout screen before the budget check is performed to alert the buyer and any approvers of the mixed ACCT types before the PO reaches Banner.

 

Blanket Order Not Found for Release Order

Sample 1

Subject from API email: PROD: Error in OrderRequest (90950)

Blanket PO not found for release orderID EP012541

Sample 2

Subject from API email: PROD: Error in InvoiceDetailRequest (3291359)

Parent PO with orderID UP122375 not found!

Sample 3

UB388138: Purchase Order has not been posted.

Action

Release order sent to Banner has the above error that the Parent PO 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.

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

Subject from API email: PROD: Error in OrderRequest (92752)

FPBPOHD_CODE: UP500005

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 is 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 gave an error that Type “delete” is not supported

Sample

Subject from API email: PROD: Error in OrderRequest (84773)

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.

Contact Unimarket Support at support@unimarket.com for more information on modifying the interface.

 

FOMPROF User Organization - Data Entry not allowed

Sample

Subject from API email: PROD: Error in OrderRequest (172788)

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

We recommend that all Banner customers use a consistent user id to create the Purchase Order (generally UNIPO.) However, some customers insist on using the actual user to post the order to Banner. If FOMPROF is actively managed this is not an issue, but often find that this is an administrative task that is overlooked.

Banner does not allow the FOMPROF home Organization for a user to allow purchases if the Org is not Data Enterable. If the users home Organization in FOMPROF is not Data enterable in the Chart of Accounts, it will fail with this error. In FTMORGN, there is a field for data entry that should be ‘Y’ (FTVORGN_DATA_ENTRY_IND).  If it is not, then Banner provides this error.  The User's home org in FOMPROF should be changed to something that is data enterable on FTMORGN, and the PO can be resent to Banner.

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. 

To resolve the issue:

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.
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 FOMPROF 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.)

 

Deadlock Detected

Sample

Subject from API email: PROD: Error in OrderRequest (462596)

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. 

Option 1:

1. Verify if the PO record has been posted by viewing it in FOIDOCH.  
2. If the PO does not appear in FOIDOCH, resend the PO message from Unimarket and confirm it posts correctly.

Option 2:

1. If the PO does appear in FOIDOCH, the status field is likely going to be blank/not approved.
2. Use FPAPURR to delete the incomplete PO record
3. In FPAPURR, enter the PO#, NEXT BLOCK once, then click delete twice to remove the record
4. 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.  This will require your IT’s involvement to resolve the issue. 

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

Subject from API email: PROD: Error in OrderRequest (699256)

API Error: Organization 72251 is invalid.

Action

The ORGN field within Banner was invalid, so the order could not be posted to Banner.

Check the Buyer's FOMPROF record for the default ORGN on the account, then verify it has not been terminated. There was an error response: “Organization has been terminated.” Whenever the PO posts to Banner, there is an ORGN field filled in within Banner based on the default ORGN assigned in the user's FOMPROF record (similar concept to an org unit in Unimarket.) When the order record is posted, it cannot default to an invalid home org unit for a user so it will send back this error.

 

Invalid Account Code Field in Banner

Sample

Subject from API email: PROD: Error in OrderRequest (84282)

Accounting Record Errors for sequence 1
*ERROR* Account 714000 is invalid.

Action

This could be related to the Account Code roll-up not being data enterable when it’s associated with another account code, causing the PO to error in Banner. Verify that the account code in FTMACCT is data enterable.  

 

Purchase Order is valid but failed available balance check

Sample

UM Order ID: XU051493
FPBPOHD CODE: XB051493
VENDOR CODE: 000616057
Insufficient budget for item 1,sequence 1, suspending transaction.
*ERROR* Purchase Order is valid but failed available balance check.

Action

It can happen if the approvers approve multiple large POs for the same budget in rapid succession where the initial POs post but after the approval budget check happens. If the budget is say $100 and there are 3 reqs for $75, $50, $30 and all (mainly #3) get budget checked and approved before the $75 and $50 POs post and encumber the funds, the last PO can get this error.  You will want to check the budget and transaction activity on the particular FOAP and confirm there is budget available.  This can be viewed on FGIBAVL; once the budget issue is resolved resend the PO to Banner.

 

Accounting Period Closed in Banner

Sample

Subject from API email: PROD: Error in OrderRequest (84282)

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 you will need to open and then resend the PO to Banner. 

 

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.

Customers 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. 

 

Order Status Change Errors

Sample

Subject from API email: PROD: Error in request (FZBEPRC_ID): StatusUpdateRequest (1125783)

Request to re-open order UZ500185, User UI1234 has re-opened order UZ500185
UZ500185: PO not found in fzepcpo

Action

If the PO is already closed in Unimarket and another Invoice or Credit memo is received, the PO will need to be re-opened.  The integration does not re-open in Banner; this will have to be done manually using rule code E090. 

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.

Sometimes, orders and invoices can make it to Banner but need adjusting. This document will focus on troubleshooting the common errors received during new customer setup, testing, and general usage, as well as instructions to reconcile between the two systems. It is intended to be used by functional users within Procurement and Accounts Payable Departments.

 

Interface Logs

When there is an error transmitting or creating any of the integration messages into Banner, the Banner APIs produce an error. The Interface logs the API activity, including error messages in two tables

• FZBEPRC Request log table – cXML messages from Unimarket to Interface
• FZRCXML Banner PO and Invoice API log table

Invoice Summary emails are also sent from the integration when an invoice is matched in Unimarket by passing the matching criteria to create the invoice in Banner. The integration configuration table FZREPRF and FTMSDAT records are used to trigger the emails and define which email addresses should receive the email.

FZREPRF_INV_EMAIL_SEND (Y/N)—If set to “Y,” the emails will be sent based on the FTMSDAT records (FZKEPRC-UM ERROR EMAIL-TO). The emails are sent using the Oracle UTL_MAIL function from Banner's underlying Oracle database.

API Error Email Sample for Invoice Summary:

Invoice Common Errors

Invoice cannot be created because the Purchase Order has not been posted 

Sample

Subject from API Email:PROD: Error in InvoiceDetailRequest (3290680)

PO: PO163110
INVOICE: 56321237

API Error: Purchase Order cannot be invoiced.
Purchase Order has not been posted to the ledgers.

Action

This error occurs when the PO has not posted. If the PO is not posted, the PO cannot be invoiced. Check to see if any other POs are failing, to ensure that posting is running. 

Look up the API error email for the PO, fix the PO, and then resend the invoice. 

If you have access to the tables associated with Unimarket you can look in the FZRCXML log for the error that needs to be fixed. Once the PO has been fixed, the invoice message can be resent.

IF the posting process is running the customer has recently upgraded Oracle to version 19c which will need to have the below grant performed by their DBA in IT to give the permission to the FISHRS user to reprocess the invoice for a retrofit order. This will allow FISHRS to use DBMS_JOB functions from the FTMSDAT record for the “INV DELAY” when the invoice is reprocessed.

The issue with the Oracle 19c upgrade was the DBMS_Jobs not being a default with the DBMS_Scheduler being the Oracle default job. The solution was to grant the FISHER user permission to “create job” so that it can perform the DBMS_Job to reprocess an invoice if the PO wasn’t posted at the time it attempted to hit Banner.

 

Sample

PO: UP389903

INVOICE: UI394356

API Error: Purchase order not posted to ledgers. Invoice scheduled to be reprocessed.

Action

This error is expected and okay to ignore.

The reason this error occurs is on retrofit releases, both the release order and the invoice are sent to Banner at the exact same time. Often times, the invoice makes it there first. Resulting, in the error message received because the release order hasn't posted yet. The integration is set to resend the invoice message approximately 5 minutes later, to allow time for the release order to post, along with the invoice. Most customers have an email rule to filter this out since there can a lot of emails, depending upon how heavy the blanket order usage is. We suggest using the "Invoice scheduled to be reprocessed" portion of the error message, as the primary criteria for the email filtering. Since that tells you this invoice is going to be resent again and no action is needed.

 

Purchase Order has not been posted (Invoice scheduled to be reprocessed)

Sample

PO: PO163110

INVOICE: 56321237

API Error: Purchase Order cannot be invoiced.

Purchase Order has not been posted to the ledgers.

Invoice scheduled to be reprocessed

Action

This happens for Retrofit Invoices where the Retrofit Order is being created at the same time as the Invoice. Both are sent to Banner and the invoice may try to hit the PO before the PO has been posted. 

Waiting for posting process, invoice will reprocess in # number of minutes defined in FTMSDAT.  If you get several of these messages verify with finance that the posting process is running.

 

Stopping a reprocessing error for a specific invoice

Action

First, find the FZBEPRC_ID of the reprocessing job. Next identify the active scheduled job in the FISHRS schema: 

SELECT * FROM USER_SCHEDULER_JOBS;

 This select will pull fields JOB_NAME, JOB_ACTION

-- the  JOB_NAME  will look something like this: DBMS_JOB$_28225

-- the associated  JOB_ACTION will look something like this: fzkeprc.p_request(273276,'EPUNIMARKET'); the first parameter of the p_request is the  FZBEPRC_ID.

• Find the job_name with the fzkeprc.p_request parameter that matches the  FZBEPRC_ID of the reprocessing job.

• Then use the job scheduler to drop the job by JOB_NAME or run an SQL that looks like this:

BEGIN

  dbms_scheduler.drop_job(job_name => 'DBMS_JOB$_28225'); 

END;

/

Vendor Invoice Already Exists 

Sample 1

Subject from API email: PROD: Error in request (FZBEPRC_ID): InvoiceDetailRequest (1728276)

API Error: This Vendor Invoice already exists for this vendor 

Sample 2

Invoice IU017253/EP017512/02298183 already exists

Action

Invoice was resent manually from Unimarket to Banner because someone could not find the invoice in Banner. There may be another error with the invoice but when the invoice was initially sent to Banner, the Banner invoice (I#) was created but the other possible error caused it to not be completed.

OR

Vendor invoice number already exists in Banner. Unimarket will validate against invoices in Unimarket and not allow the same invoice number to be used for the same supplier. For any invoices that are in Banner only the invoice validation on the supplier invoice number is not done until the invoice hits Banner. AP will need to edit the Banner invoice to add a suffix to the vendor invoice number then complete the invoice in Banner.

 

Vendor FTMVEND Address Issue

Sample

Subject from API email: Error in request (FZBEPRC_ID): InvoiceDetailRequest (95869)

API Error: Invalid combination of address type and sequence for vendor.

Or

API Error: Purchase Order cannot be invoiced.
Purchase Order has not been posted to the ledgers.
Invalid combination of address type and sequence for vendor. (UNIINV)

Action

If the Address Type is missing, check the FTMVEND form for that Vendor. The Vendor Maintenance tab should have a default address type code and sequence listed for Procurement and Accounts Payable. After Banner has been updated, the Invoice in Unimarket will need to be resent.

 

Invoice line item amount exceeds purchase order line amount

Sample

Subject from API email: PROD: Error in InvoiceDetailRequest (287046)

*FB_INVOICE_ITEM*

Approved amount exceeds tolerance percent or amount on commodity item 1.       

Action

Invoice Matching Tolerance in Unimarket is not the same or lower than the Banner invoice tolerances so the approved and matched invoice in Unimarket does not match per Banner tolerances.

Purchase order line item amount may have been changed manually between the time of creation by the Unimarket interface and invoice time. Whatever the cause the amounts don’t match and an invoice cannot be created. A manual invoice needs to be created by A/P to invoice this item. 

 

Invoice Item Unit Price is $0.00

Sample

Subject from API email: PROD: Error in InvoiceDetailRequest (252589)

API Error: Approved unit price should be positive.

Action

The Banner API for invoices does not allow for a unit price of $0.00. This is used sometimes for free products or discounted products on an invoice from a supplier.

The Invoice will need to be edited in Banner to give the offending line item a Unit price of $0.0001. Banner allows for unit prices with 4 decimal places but rounds up the line subtotal to 2 decimal places. So depending on the line item quantity, a unit price of $0.0001 will still round up to a subtotal of $0.00.

There is a modification that has been done to recognize the $0.00 unit prices and change them to $0.0001 in the interface as the invoice is being created so contact the Unimarket customer community to see who is using that to see if it will be an option for your IT department to add to your Banner Interface.

 

Invoice for Split Lines (more than 2 splits) does not calculate correctly

Sample

*FB_INVOICE_ACCTG*

Approved Amount: ::Percent and Amount do not match

Action

There is a known API issue with Banner for invoices against order with a line item containing more than 2 split line accounts. The calculation that Banner does with the unit price X Quantity divided by the percentage of the split accounting does not equal the total of the line item subtotal. This is a known Banner API issue and the invoice will need to have manual intervention in Banner to ensure that the amounts of the split funding equal the line subtotal. The difference is usually a penny or two.

 

Shipping on Split Line Invoice with Additional Charge shipping amount error

Sample

*FB_INVOICE_ACCTG*

Additional Charge: Percent and Amount do not match

Action

Similar to the error invoice for split lines does not calculate issue. If you have your interface configured to add the shipping from an invoice to 1 line item in the Additional Charges field in Banner and the line item is split by 2 or more funding sources, the calculation that Banner does for the amount and split percentages may not match the initial amount which causes this error. Manual editing of the Additional Charge amounts need to be done in Banner to ensure that the amounts per split equal the initial shipping amount. Likely 1 funding source will need to pay an additional penny.

 

Unit Price Exceeds expected character count, $1,000,000 unit prices

Sample

Error in p_do_item_data:

Last called f_get_val(Item_UnitPrice)

   ORA-06502: PL/SQL: numeric or value error: number precision too large

Action

This is an Oracle Error and due to the Interface not expecting unit prices as large as a million dollars with 7 characters. This can be changed with custom coding of the interface or reported to USNH for updates to the baseline code. This bug has been resolved in baseline code versions 4.0 and later with to correct data declaration for variable l_tot_item_tax_amt.

Contact Unimarket Support at support@unimarket.com for more information on modifying the interface.

 

Invoice Detail Tax exceeds the expected character count

Sample

Error in p_do_item_data:
Last called f_get_val(InvoiceDetailTax)
  ORA-06502: PL/SQL: numeric or value error: number precision too large

Action

This is an Oracle Error and due to the Interface not expecting tax prices as large as a million dollars with 7 characters. This bug has been resolved in baseline code versions 4.0 and later with to correct data declaration for variable l_tot_item_tax_amt.

Contact Unimarket Support at support@unimarket.com for more information on modifying the interface.

 

PO is Closed and cannot be invoiced

Sample

API Error:

The item from the purchase order cannot be copied to the invoice as it is closed

Action

PO in Banner needs to be reopened and invoice resent from Unimarket.

Invoicing a PO from a different Fiscal Year

Sample

Subject of the API Email: PROD: Error in request (FZBEPRC_ID): InvoiceDetailRequest (1728350)

API Error: Purchase Order cannot be invoiced.
Encumbrance does not exist in the fiscal year in which the invoice transaction date falls.

Action

Manually change the transaction date on the invoice in Banner

Change the INV_TRANS_DATE in FZREPRF to “Y”

 

Crediting an Invoice with a past Fiscal year date on the credit invoice

Sample

API Error: Cannot create credit memo in prior year if the purchase order has rolled into the next year.

Action

Manually edit the invoice transaction date in Banner.

Change your FZREPRF_INV_TRANS_DATE Interface Configuration setting for the Invoice Trans Date to always set the invoice transaction date as the PO transaction date.

 

Purchase Order Canceled and cannot be invoiced

Sample

API Error: Purchase Order cannot be invoiced.

Purchase Order has been canceled

Action

PO was canceled in Banner so there would need to be an investigation with the buyer to find out why the PO was canceled and if the invoice should be paid. 

Cancel the invoice if the PO was canceled intentionally and communicate to the supplier to have them credit the invoice on their books.

 

FUND Terminated and Invoice Failed to Post against PO

Sample

API Error: Fund code 551543 has been terminated as of 23-DEC-2016.

Action

This error generally happens with Grants or Sponsored Account Funds. PO was created when the Fund was active but the time between the PO being created and the invoice being matched and submitted for payment may have had the Fund activity date past and the Fund gets Terminated. 

To resolve, the Grant or Fund Owner will need to give approval for the Fund to be reopened so that the invoice can be paid. Direct action in Banner required.

 

Vendor ID not Valid on the Invoice compared to the Order

Sample

API Error: Invalid value for vendor

Action

Issue is sometimes that the vendor ID needed to be changed after the PO was created. The vendor ID was not updated in Unimarket so the invoice referenced the initial (old) vendor ID but the PO number was carried over to the new vendor. The Banner API validated the PO reference number for Vendor B and the vendor ID representing vendor A which did not match.

 

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:

2. Verify if the Invoice record has posted to FOIDOCH.  
   1. If the Invoice does not appear in FOIDOCH, resend the Invoice message from Unimarket and confirm it posts correctly.
   2. If the Invoice does appear in FOIDOCH, the status field is likely going to be Suspended or Incomplete..
      1. Delete the incomplete Invoice record from Banner (FAAINVE is likely the screen, but can’t confirm)  
      2. Once the invoice record is deleted, resend the invoice message from Unimarket and confirm it posts correctly in FOIDOCH

Returning the Banner Invoice to Unimarket

Available to institutions on Banner Interface Code 4.5 or greater, the Reference Number on the Invoice page will populate with the Banner Invoice Number. In some cases, the web service message to Banner fails; causing Unimarket and Banner to not be in-sync. In the past, you could find this issue through an error email or a reconciliation. With this enhancement, you can simply look at the Invoices tab to determine if an error occurred when the invoice was passed to Banner.

When viewing the Invoices tab in Unimarket, the Reference field indicates the Banner Invoice number. If the Reference field is not populated, the Invoice is pending acceptance and Unimarket has not tried to send it. 

Below you can see two invoices errored out based on the Reference Number having the format of “Error_”.

Error Messages in the Reference field have codes associated with them to help you and the Unimarket team troubleshoot the error. The API Error emails from the integration will provide the specifics of the error that occurs in Banner. Below is a list of the error messages you could potentially see in the Reference field, for specific API errors, the API error email is the place to look:

Error_10 - Error occurred when trying to build the Invoice Header Information. This error could occur if you try to invoice against a PO that did not post, or a supplier is not set up in Banner.

Error_20 - Error occurred in the Banner API to create invoice header. This error will rarely occur, but happens when the Banner API fails.

Error_30 - Invoice when Banner tries to create the Item/Accounting lines. When the invoice is created it needs to reference the PO lines, so if lines on the PO are closed in Banner then this error will occur. 

Error_40 - Banner Invoice Complete API error. The error will rarely occur, and the Invoice is in an incomplete status within Banner. Update the Reference ID in Unimarket after the Invoice has been completed.

 

Clone of Prod to a DEV or PPRD Banner Instance

Sample

*ERROR* UM: INGR: Error In InvoiceDetailRequest - 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. 

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.

 

Interface Logs

FZBEPRC Request log table – cXML messages from Unimarket to Interface

FZRCXML Banner PO and Invoice API log table

Unimarket-Banner Interface Error Emails

The Interface error emails utilize the Oracle UTL_MAIL.SEND. If you are not getting the error emails, the issue is likely with the smtp_out_server setup or the permissions granted to the Oracle user or schema in the access control list (ACL) are insufficient or have been removed. This section below will focus on the troubleshooting and setup for the Error Emails using the oracle UTL_MAIL.SEND.

Error Email Test

login as FISHRS try this simple test:

begin

UTL_MAIL.SEND(sender => 'somebody@school.edu',

recipients => 'somebody@school.edu',

cc => 'somebody@school.edu',

subject => 'Just test',

message => 'test');

end;

 

Setup and Troubleshooting:

Script:  utlmail_grant_080500.sql  

Note:  change the '<SERVER_NAME>.<DOMAIN>' fields below to match your own SMTP server and domain.

 

start /u01/app/oracle/product/11.2.0/db11203/rdbms/admin/utlmail.sql

start /u01/app/oracle/product/11.2.0/db11203/rdbms/admin/prvtmail.plb

grant EXECUTE ON utl_mail TO BANINST1;

ALTER SYSTEM SET smtp_out_server = '<SERVER_NAME>.<DOMAIN>' SCOPE=BOTH;

 

Script:  utlmail_acl_11g.sql

begin

  dbms_network_acl_admin.create_acl (

    acl         => 'utl_mail.xml',

    description => 'Allow mail to be sent',

    principal   => 'BANINST1',

    is_grant    => TRUE,

    privilege   => 'connect'

    );

    commit;

end;

/

 

begin

  dbms_network_acl_admin.add_privilege (

  acl       => 'utl_mail.xml',

  principal => 'WWW_USER',

  is_grant  => TRUE,

  privilege => 'connect'

  );

  commit;

end;

/

 

Note:  change the '<SERVER_NAME>.<DOMAIN>' fields below to match your own SMTP server and domain – should match what you entered for the “smtp_out_server” init parameter above.

 

begin

  dbms_network_acl_admin.assign_acl(

  acl  => 'utl_mail.xml',

  host => '<SERVER_NAME>.<DOMAIN>',

  lower_port => 25,

  upper_port => 25

  );

  commit;

end;

/

ACL (run later)

begin

  dbms_network_acl_admin.add_privilege (

    acl         => 'utl_mail.xml',

    principal   => 'FISHRS',

    is_grant    => TRUE,

    privilege   => 'connect'

    );

    commit;

end;

/

 

Customer is not receiving errors via email

If a customer is not receiving their error emails, they can check that the FISHRS user in Oracle has access to the UTL_Mail or if they can use ACL permissions, check that FISHRS is included in the ACLs. If that's not the issue, it could be an SMTP_Out configuration issue with the email server on the customer side.