E1: 48S: 52: Workfile Generation (R48120) Only Filters on the Transaction Number Field (PRTR) When Validating Records in the Employee Transaction History Table (F0618) (Doc ID 2974733.1)

Last updated on NOVEMBER 08, 2024

Applies to:

Symptoms

If the Transaction Number (PRTR) field reaches its last Next Number digit and starts over again (NN 06|3), the Billing Workfile Generation (R48120) may process T2 Payroll Labor Distribution Records in the Account Ledger (F0911) and fetch old unrelated F0618 records. This causes Workfile (F4812) records to have old Service Tax Date information when two F0618 records have the same PRTR number.

Steps
1. Create a Time Entry Record, P051121. This updates the F06116 with a Transaction No (PRTR) with a value from Next Numbers (06|3).
2. Generate Timecard Entries (R052901, R05229); this creates the Pro-Forma Timecard Batch Type.
3. Post the batch (R09801), the system removes the record from F06116 and creates an F0618 record with the same Transaction Number.
4. Review the batch in F0911 (G/L Posted Code = P). The ALID field inherits the same value as the Transaction Number (PRTR) in the F0618.
5. Run R48120 over the T2 batch in the F0911 with UBE logs active; for the system to get the correct Service Tax Date, the system needs to use the ALID to fetch the corresponding F0618 Transaction Number.
6. If the Transaction Number PRTR Next Number reaches the last digit due the large quantity of transactions, the next number from NN 06|3 starts over again. This repeated number gets populated in the F0618 and F0911, and this condition could cause the R48120 to fetch an old date from an old F0618 record.
7. In the UBE logs, note that the filtering on the F0618 is only on the Transaction Number; for example:
SELECT  *  FROM PDCUR.F0618  WHERE  ( YTPRTR = 1234.000000 )

Changes

Cause

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.