Federal, State, and Local Tax records are selected based on the Effective Date of the Tax record in relation to the Paycheck Issue Date, NOT the Pay Period End Date. For example, assume a Pay Run with a Pay Period End Date of 12/31/2009 and a Paycheck Issue Date of 01/06/2010. PeopleSoft Payroll will use the Issue Date to determine which tax record will be used; in this example 01/06/2010 will be used. This means that the 2010 rates (which are delivered with an effective date of 01/01/2010) would be applied.
Wednesday, July 13, 2011
Here are reasons why Time and Labor Payable Time is rejected from NA Payroll
1. TRC not mapped to a valid NA Earnings Code
2. Currency Code reported in Payable Time does not match to Currency Code of the employee's paygroup
3. Employee is not active in JOB (for example, Terminated or Leave of Absence).
4. Employee has changed paygroups in the pay period being processed. (Time will reject, and then load in the new paygroup unless the new paygroup is also in a different company.)
5. TRC in Payable Time is mapped to a NA Earnings Code that is not in the Employee's Earnings Program
6. You run PayUnsheet and all payable time is set to Rejected
7. You enter override state and locality which is not setup for the employee's Tax Data records
8. Employee has prior period adjustments when associated to a different paygroup (Changed in latest release, will now load time to current paygroup unless Company or currency code differences exist).
9. If the Time Reporting Code is Hours or Units and if the value is not between +/- 9,9999.99, the time is rejected by the Load Time And Labor with a error message # 000255. If the Time Reporting Code is Amount type and if the value is not between +/- 99,999,999.99 then time is rejected by Load Time And Labor with the same error message.
2. Currency Code reported in Payable Time does not match to Currency Code of the employee's paygroup
3. Employee is not active in JOB (for example, Terminated or Leave of Absence).
4. Employee has changed paygroups in the pay period being processed. (Time will reject, and then load in the new paygroup unless the new paygroup is also in a different company.)
5. TRC in Payable Time is mapped to a NA Earnings Code that is not in the Employee's Earnings Program
6. You run PayUnsheet and all payable time is set to Rejected
7. You enter override state and locality which is not setup for the employee's Tax Data records
8. Employee has prior period adjustments when associated to a different paygroup (Changed in latest release, will now load time to current paygroup unless Company or currency code differences exist).
9. If the Time Reporting Code is Hours or Units and if the value is not between +/- 9,9999.99, the time is rejected by the Load Time And Labor with a error message # 000255. If the Time Reporting Code is Amount type and if the value is not between +/- 99,999,999.99 then time is rejected by Load Time And Labor with the same error message.
Also, if the sum of the hours/units/amount for a payperiod exceeds +/-9,9999.99 in the case of hours/units and +/-99,999,999.99 in the case of amount the same error message is displayed and the employees, time for the entire payperiod is rejected.
10. The incoming rows from Payable Time have negative override rates (no message will be provided at this time). Update: This is no longer an issue in current releases, applies only to 8 SP1 release.
11. Employee had a job change since the last run of Load Time and Labor. Time for all jobs will reject and be reloaded.
12. The employee terminated prior to the Pay Period Begin Date, and there is unprocessed Payable Time. (Message 005019)10. The incoming rows from Payable Time have negative override rates (no message will be provided at this time). Update: This is no longer an issue in current releases, applies only to 8 SP1 release.
11. Employee had a job change since the last run of Load Time and Labor. Time for all jobs will reject and be reloaded.
13. The employee has too many prior period adjustments. (NOTE: In the delivered version, this will occur when an employee has 99 XREF_NUM's already loaded to paysheets from a previous run. For example, this could occur when there have been a large number of prior period adjustments.)
14. Final Calc and Confirm has been run which stops paysheets from being updated. In order to load more time after a final calc and confirm is done they need to run pre-calc again after unconfirming. This is only a problem when a pay unconfirm has been run - because pay unconfirm updates the pay_calendar status, but not the payline status on the individual rows of PS_PAY_EARNINGS. There is no message for a final calc because a final calc might have run, but time can still be loaded if there are employees with individual payline status <>'F' (allows clients to fix errors).
When do the Off-Cycle Calendar Calc Outstanding and Off-Cycle Closed flags on the Pay Calendar get set on or off?
Off-Cycle Calc Outstanding check box on Off-Cycle Pay Calendar
The Off-cycle Calcs Outstanding checkbox becomes checked when you run any Pay Calc for a check associated with the Pay Calendar. It becomes unchecked after you have run the Pay Confirm on the an off-cycle paycheque. -- if there are no other paychecks associatee with the Pay Calendar. Deleting a reversal/adjustment paysheet will also clear the flag.
Off-Cycle Closed check box
Whenever any Off-cycle pay from the next Pay Calendar or the On-cycle pay from the next Pay Calendar are Confirmed, the Off-cycle from the current Pay Calendar will close. The Pay period begin and end dates must not include any dates within the begin and end dates of the previous calendar.
For example:-
Whenever any Off-cycle pay from February's pay or the On-cycle pay for February are Confirmed, the Off-cycle for January will close.
The Off-cycle Calcs Outstanding checkbox becomes checked when you run any Pay Calc for a check associated with the Pay Calendar. It becomes unchecked after you have run the Pay Confirm on the an off-cycle paycheque. -- if there are no other paychecks associatee with the Pay Calendar. Deleting a reversal/adjustment paysheet will also clear the flag.
Off-Cycle Closed check box
Whenever any Off-cycle pay from the next Pay Calendar or the On-cycle pay from the next Pay Calendar are Confirmed, the Off-cycle from the current Pay Calendar will close. The Pay period begin and end dates must not include any dates within the begin and end dates of the previous calendar.
For example:-
Whenever any Off-cycle pay from February's pay or the On-cycle pay for February are Confirmed, the Off-cycle for January will close.
Pay Unconfirm (PSPUNCNF)
Do not run UNCONFIRM if the original confirm process did not complete successfully.
The Pay Unconfirm batch process is used to unconfirm a payroll cycle that has been confirmed. That is, it backs all of the detail out of the balance tables and resets the status of paysheet details, so that everything looks like you are ready to run final Pay Calculation, prior to Pay Confirmation. To run UNCONFIRM, access the Pay Unconfirm component in North American Payroll.
Pay Unconfirm reverses out the entire pay run; use Paycheck Reversal/Adjustment for individual checks.
Note the following differences between unconfirm and restoring to prior to confirmation:
1) After you run Pay Unconfirm, you must manually reset the Last Form Number Used field in the Form Table to the last number that was used before you ran Pay Confirmation; Pay Unconfirm does not reset this number automatically.
2) When unconfirm is run for the first confirm of any balance period, the balance records will be updated to zero, but not deleted. If after unconfirm, the next confirmation run will be for a prior period, these remaining balance records must be deleted to prevent duplicate insert errors on confirmation.
3) Since unconfirm will only update records, when the proper record to update is not found, errors will occur. In particular End-of Fetch errors during unconfirm are generally caused by missing or incorrectly ordered balance records.
4) The CONFIRM process deletes paysheet records where OK_TO_PAY = 'N'. The UNCONFIRM process does not add these records back.
5) In Release 9 and beyond, there may be an issue with the Garnishment status if the flag was set by the system in the confirm process. Once the payroll has been confirmed and the garnishment status has been set to complete, there is no way for us to go back and systematically know at what point it was set to complete. The status could have been changed by the confirm process because of either a limit amount or Stop Date that has been reached, or the status could have been manually changed by the customer to "complete". So when the customer wants to run an Unconfirm, we do not know which one of these scenarios applied. In addition to that, the status could have been changed in a prior pay period, we don't currently have the means to figure that out systematically either
======================
DETAILS OF UNCONFIRM PROCESS:
The Pay Unconfirm batch process is used to unconfirm a payroll cycle that has been confirmed. That is, it backs all of the detail out of the balance tables and resets the status of paysheet details, so that everything looks like you are ready to run final Pay Calculation, prior to Pay Confirmation. To run UNCONFIRM, access the Pay Unconfirm component in North American Payroll.
Pay Unconfirm reverses out the entire pay run; use Paycheck Reversal/Adjustment for individual checks.
Note the following differences between unconfirm and restoring to prior to confirmation:
1) After you run Pay Unconfirm, you must manually reset the Last Form Number Used field in the Form Table to the last number that was used before you ran Pay Confirmation; Pay Unconfirm does not reset this number automatically.
2) When unconfirm is run for the first confirm of any balance period, the balance records will be updated to zero, but not deleted. If after unconfirm, the next confirmation run will be for a prior period, these remaining balance records must be deleted to prevent duplicate insert errors on confirmation.
3) Since unconfirm will only update records, when the proper record to update is not found, errors will occur. In particular End-of Fetch errors during unconfirm are generally caused by missing or incorrectly ordered balance records.
4) The CONFIRM process deletes paysheet records where OK_TO_PAY = 'N'. The UNCONFIRM process does not add these records back.
5) In Release 9 and beyond, there may be an issue with the Garnishment status if the flag was set by the system in the confirm process. Once the payroll has been confirmed and the garnishment status has been set to complete, there is no way for us to go back and systematically know at what point it was set to complete. The status could have been changed by the confirm process because of either a limit amount or Stop Date that has been reached, or the status could have been manually changed by the customer to "complete". So when the customer wants to run an Unconfirm, we do not know which one of these scenarios applied. In addition to that, the status could have been changed in a prior pay period, we don't currently have the means to figure that out systematically either
======================
DETAILS OF UNCONFIRM PROCESS:
- Backs out all of the detail from the employee balance tables for the specified payroll cycle. (Note: if balance records were inserted by the CONFIRM process, UNCNFRM will zero these amounts rather than delete the record.)
- Resets the status on the paysheet records to a calculated status.
- Updates the pay calendar to reflect that CONFIRM has not been run.
- The CONFIRM process creates entries in PS_PAY_DISTRIBUTN. The UNCONFIRM process deletes these records.
To run Pay Unconfirm, set up a run control request and run the batch process. As of HRMS 8, there is a separate component -- Pay Unconfirm, which should be used to set up the run request and start the process. As of HCM 8.8, use the Reverse Pay Confirmation menu item to initiate Pay Unconfirm.
UNCONFIRM is frequently used in a testing environment because it allows users to rerun a payroll cycle once it has been confirmed. In a production environment, this process is rarely used. It may be used if there was a high-level table change that requires the recalculation of all paychecks.
It is very important that you understand exactly what UNCNFRM will do in your particular situation before using it. The recovery steps necessary may differ depending on the actual situation. The PS_PAY_FORM_TBL may need to be updated manually so CONFIRM can reassign the check numbers correctly.
Points to consider when running the UNCNFRM batch process:
- After running UNCNFRM, you must rerun CALCPAY. Otherwise, the JOB.LOCATION field on PS_PAY_CHECK will not be repopulated. (Payroll uses the JOB.LOCATION value to sort checks as a sort option for company distribution). It is recommended to run ReCalc ALL after Unconfirm, prior to running the Confirm process again. This will populate the LOCATION field with the LOCATION code on PS_JOB.
- The CONFIRM process deletes paysheet records where OK_TO_PAY = 'N'. The UNCONFIRM process does not add these records back. Therefore, a backup is recommended prior to running the CONFIRM process.
- If there are multiple Paygroups using the same Run ID but only some of the Paygroups need to be Unconfirmed, update the Pay Calendar table by removing the Run ID for any Paygroups tied to this Run ID that are correct , leaving the problem PayGroup(s) tied to the Run ID. This will allow you to Unconfirm only the problem PayGroup(s).
Friday, July 1, 2011
PERSON MODEL
How to add job rows for a Person of Interest (POI)?
Other Payee (JOB_ADD_POI component) is used to add job rows for POIs without jobs.
Navigation: Workforce Administration > Job Information > Other Payee
Navigation: Workforce Administration > Job Information > Other Payee
How to create multiple organizational instances for this POI?
Multiple organizational instances can be created for a POI using Other Payee (JOB_ADD_POI) as outlined in point 1. Provide the Person Id, Person of Interest Type and Click on Add the relationship. The Empl_Rcd will be different for multiple organizational instances.
How to add an additional assignment for this POI?
Additional assignment functionality is not available for POI. Because these are the people who are not the part of the organization but they are some how related with organization. So instead of giving additional assignment, add a new POI Type Record.
For POIs (without job) you can not add additional assignment, it can be done only for Employees or Contingent workers. For an Employee who has a POI record, you can add an additional assignment.
When you use 'JOB_ADD_POI' component to add a job row for a POI, the Action/Reason is defaulted to 'Add Person of Interest'. In case you choose Action/Reason as 'Assignment', it throws an error that 'This action is not allowed for Non-employees'. Multiple organizational instances can be created for persons of interest (POIs). However, these organizational instances do not imply additional assignments.
Note: Under Set Up HRMS > Foundation Tables > Organization > Person of Interest Types: Job Record Required? The checkbox is unchecked for the POI type.
Workforce Administration, Personal Information, Add a person: Add a new Person with Organizational relationship of POI (without job row)
For POIs (without job) you can not add additional assignment, it can be done only for Employees or Contingent workers. For an Employee who has a POI record, you can add an additional assignment.
When you use 'JOB_ADD_POI' component to add a job row for a POI, the Action/Reason is defaulted to 'Add Person of Interest'. In case you choose Action/Reason as 'Assignment', it throws an error that 'This action is not allowed for Non-employees'. Multiple organizational instances can be created for persons of interest (POIs). However, these organizational instances do not imply additional assignments.
Note: Under Set Up HRMS > Foundation Tables > Organization > Person of Interest Types: Job Record Required? The checkbox is unchecked for the POI type.
Workforce Administration, Personal Information, Add a person: Add a new Person with Organizational relationship of POI (without job row)
What is usage of Other Payee (JOB_ADD_POI) as already Add POI instance (JOB_DATA_POI) is provided?
Other Payee (JOB_ADD_POI) is used to add job rows for POIs.
Please note that if you create a organizational instance using a POI (who is not an employee) you can not add a Job row for this POI using 'Administer Workforce > Job data' component.
However JOB_ADD_POI component helps you in adding a Job row for a POI.
JOB_ADD_POI (Other Payee) component can be obtained after implementing HR 8.9 MP5. For details please refer to the attached document 'HR8.9 - JOB_ADD_POI .doc'.
Please note that if you create a organizational instance using a POI (who is not an employee) you can not add a Job row for this POI using 'Administer Workforce > Job data' component.
However JOB_ADD_POI component helps you in adding a Job row for a POI.
JOB_ADD_POI (Other Payee) component can be obtained after implementing HR 8.9 MP5. For details please refer to the attached document 'HR8.9 - JOB_ADD_POI .doc'.
Tuesday, June 28, 2011
Peoplesoft Certification and Interview Questions
PeopleSoft certification Exam - Dumps
PeopleSoft Certificaiton Question Bank
Peoplesoft Certification Exam
Peoplesoft Certification Questions & Answers
Peoplesoft Certification Additional Questions
People Soft 8 Tools Implementation Champion Proficiency Level Assessment
People Tools Certification Questions
Certification Detalis
Exam - I - PeopleTools Developer Certified Expert - 1z0-241
Exam - II - PeopleTools Advanced Developer Certified Expert 1z0-242
PeopleSoft Certificaiton Question Bank
Peoplesoft Certification Exam
Peoplesoft Certification Questions & Answers
Peoplesoft Certification Additional Questions
People Soft 8 Tools Implementation Champion Proficiency Level Assessment
People Tools Certification Questions
Certification Detalis
Exam - I - PeopleTools Developer Certified Expert - 1z0-241
Exam - II - PeopleTools Advanced Developer Certified Expert 1z0-242
How to disable auto-numering feature in Peoplesoft
the Installation table fill the the last assigned value with 9's.
Eg:- Last Employee ID Assigned field on the Last ID Assigned tab should be filled with only 9's.
Eg:- Last Employee ID Assigned field on the Last ID Assigned tab should be filled with only 9's.
Subscribe to:
Posts (Atom)