Oracle E-Business Suite Blog

Some things there are just no explanation for and this is one of them.

 When we first started testing in Iteration 1, I opened an SR because when creating a NACHA payment run, we came across this error:

Payments cannot be marked complete because an error was returned by the callout AP_PMT_CALLOUT_PKG.payments_completed.

I opened an SR and gave Oracle Support all the necessary documentation from that run, outputs, diagnostics, etc.  They came back and wanted me to retest the payment run in debug mode.  Wouldn't you know that when I went to retest again, twice, that everything worked flawlessly, no errors.  So, since we can't reproduce and the error is no longer an issue, I have closed the SR.

The third SR, that has been open since we upgraded to R12, is still an issue.  We had hoped it would be fixed with R12.1, but that is not the case.  This issue has to do with random lines on our NACHA output being off by .01.  Sometimes, the total is off by a penny as well, but most often not.  Oracle support is closing down our existing R12 SR regarding this issue and reopening one for the same issue in R12.1.  It would definitely be nice to get this issue resolved!

Comment (0)

We have successfully resolved the Payment Document issue.  Thankfully it was a fairly easy fix.  We simply had to remove the documents from the setup and add them back in.  Why?  Can't explain, but it seems to have fixed the issue and I was able to complete a printed check run with no issues.

I've entered numerous expense reports to retest the two NACHA issues in Iteration 1.  I'm having to rerun the processes for NACHA runs in debug mode to get Oracle the data they need for the flagged completion issue.  I'll also be testing the penny issue with the same data.

 I'll keep you posted as we progress.

Comment (0)

Well - so far testing is going so so.  I've had no issues in most of the modules I've been testing.   AR, Advanced Collections, FA, GL and iExpense have gone alright. 

The thorn in my side right now is AP.  Right now, I've got two current SR's open, both have to do with payments, which obviously would be a show stopper for go live. 

The first issue I have is with NACHA payments.  The process itself is going okay, however, in the output from the Format Payments report there is an error at the bottom stating:

Payments cannot be marked complete because an error was returned by the callout AP_PMT_CALLOUT_PKG.payments_completed.

 I've updated the SR with multiple diagnostics that I've ran on our system, so we'll see what Oracle has to say.

 The second issue is with the Created Printed Payment Instructions process.  On step 2 in the process, when selecting the Payment Process Profile of Standard Check Format, I end up with no LOV in the Payment Document field which is a required field. 

I've check the Payment Process Profile setup under Payment Administrator and everything is setup correctly.  So in theory, I should have 2 values in that field.  After updating the SR with some diagnostics and some screenshots, I'm waiting on Oracle.

On top of those two issues, we are hoping that our long standing issue with NACHA payments is resolved with the R12.1 upgrade.  This has to do with all our NACHA payments being off by a penny.  Causing us to have to manually manipulate the file we send to the bank.  Jessica opened this SR when we upgraded to R12 April 2008.

Comment (0)

There are some great enhancements with R12.1 when it comes to Financials.  It will definitely be fun to take advantage of all this.

Advanced Collections - Well with our upgrade to R12 last year, collections no longer was a function of Receivables.  It took on new life with its own module, Advanced Collections.  Overall, it allows for greater management of collections, which all companies, I'm sure can definitely use.  A few new enhancements and features with R12.1 are:

          Customer Dispute Enhancement - There is now a new ‘Internal Comment' field.  This allows collectors to enter comments that are only visible to internal users.  It's always a good idea to be as detailed as possible on disputed transactions!

          Customer Level Bankruptcy - We can now assign a bankruptcy status at the customer level when a client declares bankruptcy.  By doing so, all business transactions of the customer will inherit the status entered.  This is also a good starting point to adopting practices around a bankruptcy declaration.

          Status Assignment at Case and Contract Level - Status Assignments (Write-Off, Repo, etc) can now be done at the contract level, not the transaction level.

Oracle Assets - Nothing new to report.

Oracle Payables - There are a few enhancements and features to the Payable module, that I believe we can benefit from.

          Discount Calculation Enhancement - Some companies these days will provide a vendor a discount if payment is made within the due date.  This discount is a percentage or fixed amount.  With R12.1, the Payment Terms in Oracle Payable is now enhanced to allow a discount definition by means of a Criteria field.

          Subcontractor Management - There are some unique requirements when working with subcontractors and with this release, it makes things a little easier by applying payment controls for subcontractor payments.

                                Pay when Paid

                                PO Deliverable Control

                                Automatic Payment Holds/Releases

                Other enhancements include Supplier Dispute Processing and Third Party Payments.

Oracle Receivables - There are some pretty good enhancements on the Receivables front.

          Cash Application Work Queue - One of the key business processes in Receivables is to apply customer receipts to transactions to reflect the correct outstanding balance. Unapplied customer receipts are assigned to the cash application owners for processing. The cash application owners research the receipts, identify the related customer debit items and apply the receipts.

The new ‘Cash Application Work Queue' feature introduced in Oracle Receivables enables users to addresses these business requirements for receipt processing with the following new functionality:

Rules engine ‘Cash Application Owner Assignment' to assign unapplied receipts to cash application owners based on user-defined assignment criteria.

Concurrent program ‘Assign Cash Application Work Items' to evaluate rules and assign unapplied receipt to cash application owners.

Workbench ‘Cash Application Work Queue' to review and process unapplied receipts.

Report ‘Cash Application Work Load Review Report' to review the workload of cash application owners.

          Enhanced Line Level Cash Application - This is a great enhancement to users who support receipts that are brought in via lockbox.  Users can now write their own business logic to accommodate selection of invoices and invoices lines for lockbox receipts.  This will definitely be a plus for us internally.

          Enhance Performance for high Volume Receivables Processing - In this release, performance of the key batch processing programs is enhanced to support high volume processing requirements of customers belonging to industries which process large number of transactions every day. Performance of these programs is vastly enhanced by implementing parallel processing and leveraging database indexes and statistics.  The programs below have received a performance boost to support the high volume processing:

                                AutoInvoice Master Program

                                Automatic Clearing for Receipts

                                Automatic Remittances Master Program

                                Lockbox Execution Program

Well - I think that's about it all I can say right now about Financials and R12.1.  Enjoy!

Comment (0)