My Oracle Support Banner

ETP Data is Staged Differently When Run for a Single Emplid Compared to Staging by Pay Entity (Doc ID 2669673.1)

Last updated on MAY 15, 2020

Applies to:

PeopleSoft Enterprise HCM Global Payroll Australia - Version 9.2 to 9.2 [Release 9]
Information in this document applies to any platform.


Some ETP data is staged differently when run for a single EMPLID compared to staging by Pay Entity

The issue can be reproduced at will with the following steps:
1) KA0001-- Transfer-- KABIWEEKLY-- 1st March 2019
2) KA0001-- Terminated-- KA 2019TB01-- 13 March 2019
ETP Payment on KA 2019TB01-- ETP NonTAX: 40000
ETP TAX: 50000
LUMP C Tax: 16000

3) KA0004-- Transfer to KA Biweekly-- 1st Mar 2019
4) KA0001-- Rehired KAFNIGHT-- 13th March 2019-- effective seq 1

KA0001 paid in KA 2019TF01 and KA 2019TF02

5) KA0001-- Terminated-- KA 2019TF03-- 15th Apr 2019-- effective seq 0

ETP Payment on KA 2019TF03-- ETP NonTAX: 123456
ETP TAX: 987654
LUMP C Tax: 456947

6)KA0004-- Teminated -- KA 2019TB03-- 15th Apr 2019-- effective seq 0
ETP Payment on KA 2019TB03-- ETP NonTAX: 600
ETP TAX: 500
LUMP C Tax: 160

7) Run the STP Preparation process by EMPLID for KA0001.
For the First Pay Event, KA0001 has the correct YTD for both Payment Dates
8) Rerun the STP Preparation process by Pay Entity.

9) Delete the ETP transactions for KA0004.
10) Recalculate KA 2019TB03.
11) Rerun the STP Preparation process by Pay Entity.

KA0001 still has both ETPs, but now there are no other ETPs being processed for any other
Payee or Pay Group.
KA0001returns to the correct ETP YTD for both Payment Dates.




To view full details, sign in with your My Oracle Support account.

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

In this Document

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