Has anyone encountered a situation where ** are in the State Tax fields of the paysheets

PS NA Payroll 9.1. Has anyone encountered a situation where ** are in the State Tax fields of the paysheets after the creation process is run? 

 When this happens this means that the employee doesn't have a state entered in the state tax table. If you go update the employees state in which they are part of and re-run the paysheets process you should see the state populate.

 

Pay confirmation failed with Unique constraint error

Pay confirmation failed with Unique constraint error
Application Program Failed
 In Pgm Section  : INSERT-BALANCE                                     
 With Return Code: 00805
 Error Message   : ORA-00001: unique constraint (SYSADM.PS_CHECK_YTD) violated
PAGE_NUM=  240,LINE_NUM=  1,SEPCHK= 0,EMPLID=987162

Application Program Failed
 In Pgm Section  : PROCESS-CHECK(PSPCBUPD)                            
 With Return Code: 00805
 Error Message   : ORA-00001: unique constraint (SYSADM.PS_CHECK_YTD) violated

Solution:

Pay confirmation ran for October Period.

Verified EE 987162 has balances for period 11 for paycheck, earnings and taxes and that is why the confirm is erring. We need to update 987162 to OK_TO_PAY = N
UPDATE ps_pay_earnings SET OK_TO_PAY = 'N' where emplid = '987162' and company = 'XXX' AND PAYGROUP = 'XXX'
UPDATE PS_PAY_CALENDAR SET PAY_CONFIRM_START = 'N' WHERE COMPANY = 'XXX' AND PAYGROUP = 'XXX' AND PAY_END_DT = '30-OCT-2012'  Now they can calc where needed and then rerun the confirm. Or other way is that they can Update 987162 to remove balances for period 11 and flip okay to pay back to Y. Later run Recalc where needed and confirm.  

Top 6 Tables in Peoplesoft Time and Labor

TL_EMPL_DATA

o    Maps data between EMPLID and T&L parameters like Workgroup, Taskgroup and Time Reporter Status.

o    The PS_JOB of Time and Labor.

o    Keys: EMPLID, EMPL_RCD, EFFDT.

o    Used to find the Workgroup, Taskgroup, Active status, Time Reporter Type, Timezone etc. of an employee.

o    Found under the Enroll Time Reporters component.

o    Needs to be in sync with PS_JOB data.

TL_RPTD_TIME

o    The single most important transaction table in Time and Labor.

o    Holds all data regarding the time reported by employees.

o    Key: EMPLID, EMPL_RCD, DUR and SEQ_NBR.

o    Both Punch and Elapsed data reside in this table – distinguished by the PUNCH_TYPE field.

o    Other important fields – TRC, TL_QUANTITY, RT_SOURCE.

o    Has an audit table – AUDIT_TLRPTTIME.

o    Final target table of the timesheet component.

3TL_PAYABLE_TIME

o    Contains final processed time ready to be sent to a Payroll System.

o    Output of the Time Administration process and has the TL_RPTD_TIME as the source.

o    Keys: EMPLID, EMPL_RCD, DUR, SEQ_NBR.

o    Other important fields – TRC, TL_QUANTITY, PAYABLE_STATUS, PAYROLL_REQ_NUM.

o    To be used for custom reports and interfaces requiring to take the final output in Time and Labor.

TL_TR_STATUS

o    Table used by the Time Administration process to determine the employees to be processed.

o    Not externalised through any component – updated by the Time Administration process and Peoplecode in various components including timesheet.

o    Keys – EMPLID, EMPL_RCD.

o    Other important fields – EARLIEST_CHGDT, TA_STATUS.

TL_IPT

o    Intermediary Payable Time tables – IPT tables are the most important temporary tables in Time Administration processing.

o    Data from reported time and scheduling tables are populated in TL_IPT1.

o    Extensively used by almost all T&L rules where data is transferred from one IPT table to another for rule processing.

o    TL_PAYABLE_TIME data is populated from TL_IPT1 table at the end of rule processing.

TL_EXCEPTION

o    Transaction table containing the details of all exceptions that are generated.

o    Exception_Status field tells whether the exception is resolved (R), unresolved (U) , allowed (A) or changed (A).

o    All exceptions with an ‘Archive’ flag on will remain in the TL_EXCEPTION table after the exception is resolved.

o    All High Severity exceptions will have to be resolved for payable time to be generated.

Ben Admin tables

Ben Admin tables:

SELECT * FROM PS_BAS_PARTIC
SELECT * FROM PS_BAS_PARTIC_PLAN
SELECT * FROM PS_BAS_PARTIC_ELIG
 SELECT * FROM PS_BAS_PARTIC_OPTN
SELECT * FROM PS_BAS_PARTIC_COST
SELECT * FROM PS_BAS_PARTIC_DPND
SELECT * FROM PS_BAS_PARTIC_INVT


Benefit Plan tables:
--FSA Plan Table
SELECT * FROM PS_FSA_BENEFIT

--Health Plan Table
SELECT * FROM PS_HEALTH_BENEFIT

--Life Plan Table
SELECT * FROM PS_LIFE_ADD_BEN

--Dependent Details table
SELECT * FROM PS_DEP_BEN_EFF

--Savings Plan Table
SELECT * FROM PS_SAVINGS_PLAN

Position Management Error: "Error Updating Incumbent with Employee ID xx, Employee Record #0, (1000,1358)"

When you update the Position Record, and the "Update Incumbents" check box is checked, after saving the record, the system returns message (1000,1358) stating that an error occurred when updating one or more incumbents. The incumbent's job record is not updated as expected. Performing the same task with other positions does not give this warning and incumbent records are updated.

STEPS TO REPLICATE:
--------------------------
1. Navigate to Organizational Development > Position Management > Maintain Positions/Budgets > Add/Update Position. Open a position and change data on the position.
2. Verify the "Update Incumbents" box is checked on the Specific Information tab.
3. Click Save.

ERROR:
---------
Error updating incumbent with Employee ID xx, Employee Record #0, (1000,1358).
An error occurred when updating one or more incumbent(s) through the update incumbent function.
Check the CI log for more information.

Resolution:

Step 1 - Check Job Data Setup

This error can be caused by data in the employee's job record that triggers a warning when Position Management attempts to update the job record.
Follow these steps in a copy of production (e.g. a test or development environment which contains the same data):

1. Navigate to Workforce Administration > Job Information > Job Data. Open the employee's Job Record.

2. Insert a new row in Job Data and change the same data which you were trying to change on the Position Data record, e.g. Location, Business Unit, etc.

3. Save the record.

4. Take note of every warning or error that you receive while performing this task.

5. Correct all those conditions. Note, you do not need to save the record, just correct all the conditions that give errors and warnings.

6. Navigate to Organizational Development > Position Management > Maintain Positions/Budgets > Add/Update Position and open the position which needs to be updated.

7. Make the desired change to the position and save.

8. If after making the changes on the Job Data record, the Position Data change is successful, then make the same changes to the employee's job record in production environment, then update the position record.

Retro Troubleshooting - Why did I not get a Retro Trigger?

If no retro triggers are displayed, first look for the obvious:

1.  Are there any confirmed paychecks with a pay end date later than the date of the change to JOB or Additional Pay? You won't get a retro request unless there is pay to be recalculated.

2.  Does the Paygroup Table have Retro Pay Program and Retro Trigger Program specified on ALL effective dated rows? This is not absolutely essential, but it is easy to overlook missing values on earlier effective dated rows that could be pertinent to the JOB or Additional Pay change.

3.  Is your Retro Pay Trigger program defined at the FIELD trigger level?     

4.  Have Retro Pay Trigger Values been defined for the fields you are changing? 

5.  Is there something on the row being inserted/updated/deleted that is different, and does that field/value match what is on the Retro Trigger Values definition? Again, watch out for effective dates.

6. Esnure that the earnings codes that are eligible for retro pay are setup in the retro program tbl.

In 9.1, retro requests are no longer created through SavePostChange PeopleCode, we use Event Processing to generate the requests.

1. On your Application Server, have pub/sub transactions been enabled?

2. Has the Integration Broker gateway been configured, and is it running?