PO has not been posted

Invoice waiting reprocessing

Wait: The integration is designed to retry the invoice automatically (usually 5/10 minutes later).

• Verify: If you receive many of these, verify with Finance that the Banner Posting process is running.
• Technical Note (Oracle 19c): If reprocessing fails, your DBA may need to grant CREATE JOB permissions to the FISHRS user. To allow DBMS_SCHEDULER to handle the INV DELAY logic.

If an invoice is stuck in a failed retry loop, you can manually drop the scheduled job.

1. Identify the ID: SELECT * FROM USER_SCHEDULER_JOBS;
2. Match the JOB_ACTION to the FZBEPRC_ID.
3. Drop the job:
   BEGIN
     dbms_scheduler.drop_job(job_name => 'DBMS_JOB$_XXXXX'); 
   END;
   /

Purchase Order cannot be invoiced.

Purchase Order has not been posted to the ledgers.

Invoice scheduled to be reprocessed

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

Error occurs when the PO has not posted. If the PO is not posted, the PO cannot be invoiced.

The error must be resolved in Banner.

If error occurs in Prod:

Option 1:

1. Open a Ellucian ticket.
2. Once resolved, verify the POs has posted and are not in a Complete and Approved state.
3. Check FOAAPPD for documents that are pending posting. To see if the POs or Invoices are stuck.
4. If you have access to FGRACTG, you can view the .log file for any warnings.

Option 2: 

1. Check to see if any other POs are failing, to ensure that posting is running.
2. Look up the API error email for the PO (Note: 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).
3. Fix the PO.
4. Resend the invoice, in Unimarket.

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 the DBA in IT. To give permissions 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, assigned as 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 hasn't posted at the time it attempted to hit Banner.

Option 3: If the PO cannot be fixed, then:

1. Inactivate the current INV_Delay record, in FTVDAT.
2. Wait the X number of minutes that the reprocess would have occurred to allow the reprocess fail (do not try again, since the FTVSDAT record is inactive).
3. Create the new FTVDSDAT record with the same value like 10 or 15 minutes.

If error occurs in Demo:

Option 1: Update the INV_DELAY to a longer timeframe like 999 (Note: This does fix the PO and the team would still need to identify/resolve the error). This may be a viable option if the customer does not have posting running all the time, in TEST any longer.

Option 2: 

1. Inactivate the current INV_Delay record in FTVDAT.
2. Wait the X number of minutes that the reprocess would have occurred to allow the reprocess fail (do not try again, since the FTVSDAT record is inactive).
3. Create the new FTVDSDAT record with the new value like 9999.

1. Update FTMVEND with the default AP address/sequence. 

2. Resend Invoice from Unimarket.

In Unimarket, review the accounting string the user is approving the invoice for.

Verify the user has posting authority for the accounting string on the FOMPROF screen, in Banner.