E1: 03B: R03B50D Does Not Create A Minor Write Off When One Receipt With Two Line Numbers Is Matched With A Single Invoice (R03B50, R03B50D) (Doc ID 2195979.1)

Last updated on OCTOBER 21, 2016

Applies to:

JD Edwards EnterpriseOne Accounts Receivable - Version 9.1 and later
Information in this document applies to any platform.

Symptoms

The Known Invoice Match With Amount (R03B50D) algorithm's write off functionality is not able to create a writeoff when a receipt with two line numbers is matched with a single invoice record. To illustrate, consider the following scenarios:

Scenario 1: An invoice for $100.00 is created, and then two receipt records (one for $50.00, and the other for $49.99) are created via Electronic Receipt Revisions (P03B121) to be added to the F03B13Z1 table. Both of these receipts are in the same batch, but they have different Transaction Numbers. When the R03B50 process runs and calls the R03B50D algorithm, the receipts are matched against the $100.00 invoice, and the difference of $0.01 is written off automatically as a minor write off.

Scenario 2: An invoice for $100.00 is created, and then one $99.99 receipt with two line number records (one for $50.00, and the other for $49.99) is created via P03B121 to be added to the F03B13Z1 table. Both of these receipts are in the same batch, but they have different Line Numbers. When the R03B50 process runs and calls the R03B50D algorithm, the aggregate amount of both lines on the receipt of $99.99 is matched against the $100.00 invoice, and the difference of $0.01 remains open on the invoice.

In either scenario, the aggregate payment amount of $99.99 is matched and applied against the $100.00 invoice, but only in the first scenario is the $0.01 difference written off. Here is the reason why the current functionality is only able to create the writeoff in the first scenario:

The functions that support cash application use memory (cache) to reconcile amounts when applying cash ($). When applying cash ($) to the open amount of an invoice, the system has to detect when the open amount of the invoice is not quite exhausted in order to initiate logic to start booking a writeoff. The autocash algorithms are not designed to process multiple cash application attempts in the same transaction for a single invoice pay item. This can be remedied by populating the F03B13Z1 differently. For system performance and processing reasons, the information is cached, and not committed to the database immediately, until the transaction is complete. Therefore, the system requires that separate attempts of applying cash to an open amount of an invoice be separated (unique) by a different transaction number in the F03B13Z1. Once the transaction is committed to the database, the system can process the remaining open amount properly and book write-offs properly with a new transaction number.

This enhancement bug is requesting a future change to R03B50D functionality so both scenarios listed above will result in the desired writeoff.

Cause

Sign In with your My Oracle Support account

Don't have a My Oracle Support account? Click to get started

My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms