How are Retro Benefits requests identified?

If RetroBen is checked on the Installation Table, the system inserts RetroBen requests (PS_RETRODED_RQST) for Job changes, payroll changes or benefit enrollment changes via PeopleCode and/or Benefits Administration.

The system retrieves the RetroDed Sequence Number from the Installation Table.

For Base Benefits, PeopleCode updates the Installation Table with RetroDed Sequence Number + 1.

For Benefits Administration, COBOL updates the Installation Table with RetroDed Sequence Number + 1000 so that the process does not need to grab a number from the Installation table for each person it is processing when running through batch mode.

The Benefits Administration event is evaluated to see if it needs a Retro request:

If Enroll Action on BAS_PARTIC_PLAN = Enroll or TER then check dates
Get the Deduction Begin Date; Get today’s date; Get current Pay Period for employee
If Deduction Begin date is less than Today’s Pay End Date or
If the Status/Event Date is greater than the current Pay Begin Date,
Then Insert RetroBen Request.

If an employee had multiple retro “events” before running RetroBen, the prior request status will be “Duplicate” – i.e. “closed” as one request will cover all RetroBen Plan Types – 1x, 2x and 3x.

Retroben will process only rate-based benefits which means it will process only Health, Dental, Vision, Life and Disability. It will not process 401K, FSA, Leave, Pension etc. There must also be a rate table (not salary % or goal amount) to calculate the deduction.

How to run XML Publisher(XMLP) processes to generate PDF paychecks in PeopleSoft HCM 9.0 and above

Below are the steps briefing on how to run the PeopleSoft delivered XMLP processes for NA Payroll to generate *.PDF paychecks.

Payroll for North America provides user to select from two methods of printing checks and advices:

• Printing by SQR Reports (PAY003, PAY003CN, DDP003, and DDP003CN). The Check Print and Cheque Print SQR reports (PAY003 and PAY003CN) and the Direct Deposit Advice Print SQR reports (DDP003 and DDP003CN) extract the payroll data for check and advice printing and format it for printing checks and advices.
• Printing in PDF by RTF Templates using XML Publisher (PYCHKUSA, PYCHQCAN, PYDDAUSA, and PYDDACAN). These PSJob processes prepare the check and advice report files:
• Print US Checks PSJob process (PYCHKUSA).
• Print Canadian Cheques PSJob process (PYCHQCAN).
• Print US Direct Deposit Advice PSJob process (PYDDAUSA).
• Print Canadian Direct Deposit Advice PSJob process (PYDDACAN).

This post deals about the second method of generating PDF paychecks using XML Publisher. Click here to find out the initial setup required and how to configure XMLP processes for NA Payroll.

How to run XMLP Process to generate PDF Paychecks and Direct Deposit Advice?

1. Instead of the usual ‘Print Paycheck’, run Create PDF Paychecks from the navigation: Payroll for North America > Payroll Processing USA Produce Checks > Create PDF Paychecks > Create PDF Paychecks; or Payroll for North America > Payroll Processing CAN > Produce Cheques > Create PDF Paycheques > Create PDF Paycheques. For Direct Depost Advice the navigation and the process names would change.
2. Enter the pay run id and the other required values
3. Days From Check Date: Leave this field blank to retain the default value entered on the Paycheck Options Table page. To override the value on the Paycheck Options Table for this check or advice print run, enter a different number of days from check date. The system issues a confirmation message if you enter an override. If you do not confirm the override, the system does not save the value you entered and the field remains blank.
4. Click 'Run'
5. On the Process Request page, select the type Web and the format PDF.

Paychecks can be viewed by employees under self service. For administrator to view all the PDF checks or advice forms run through XMLP, must use the Report Manager to view the PDF print files.

How/Where to view the Paychecks created by XMLP process?

1. Access the Report Manager.
2. To locate and open the PDF file use one of these methods(whichever is available):
• From the Report Manager - List page.
• Click the XMLP link in the Report column for the selected batch file.
• From the Report Manager - Administration page.
• Click the Details link for the selected batch file.

The system displays another page, where you click the *.pdf file link to access the PDF report in Adobe Acrobat. Depending upon the bursting option chosen, paycheck files would be bursted accordingly.

Running an SQR from within your PeopleCode program

I am often asked a common question on launching other applications from within PeopleCode. Most of the time I am asked.. "How do I launch an SQR from within my PeopleCode program?"

SQR's are already setup and defined as a Process Definition inside of your PeopleSoft application, so we will deal with how to launch an SQR. There are two ways of launching a program from within your PeopleCode programs. The first way is to make a system call to launch the SQRW.exe if you are on windows or the equivalent binary program if you are running on a UNIX operating system. However, this is not the best method.

Using the method to make a call to the system does not give you the control and integration that you desire with your PeopleSoft environment. Therefore, the best and safest way to launch an SQR program is to use the PeopleCode functions CreateProcessRequest() and Schedule().

The CreateProcessRequest function allows you to create a ProcessRequest object. Remember, you should be coding your PeopleCode programs using the Object Oriented methods. Once you've created your object, you can assign values to its properties and use the Schedule method to submit the process request for scheduling. The CreateProccessRequest function takes 2 arguments. The Process Type and the Process Name.

REM Declare your Variables;
Local ProcessRequest &MYRQST;
Local String &MySQR;

&MySQR = "DDDAUDIT"

REM Create My Process Request Object;
&MYRQST = CreateProcessRequest("SQR Process", &MySQR);

REM Set Properties of My Process Request Object;
&MYRQST.RunControlID = "MYRUNCNTRL_ID"

REM Set Properties of My Process Request Object;
&MYRQST.SetOutputOption("Web", "PDF", "", &MySQR);

The above example creates a ProcessRequest object for the DDDAUDIT SQR named &MYRQST. You will notice that I also specified Run Control ID and the output options. I can now take this Object and use the Schedule() method agains it to Schedule the SQR. Here is an example.

&MYRQST.Schedule();
If &MYRQST.Status = 0 then
/* Schedule succeeded. */
Else
/* Process (job) not scheduled, do error processing */
End-If;

That's how you run an SQR program from within your PeopleCode program. Now, if you want to run any other type of program that is not an SQR, AppEngine, or Crystal I would highly suggest that you first setup a Process Definition for the type of application you are running and run it through the process scheduler. We'll table this discussion for another time

Paysheet Creation Process for Off Cycle

When you create an Off-Cycle Paysheet the Tax Distribution does not get applied.  Also the Earns Begin and Earns End date are for the entire period and do not break out by week (FLSA).

This is currently as designed.  It is the Paysheet Creation Process that splits these out.  Since you are adding these folks manually (not via paysheet creation) you are required to key in the appropriate data.  This is as designed.  Off-Cycles were designed to make no assumptions of what State or what Earnings Begin and End dates should be used.  This was designed for special processing like Bonus where Tax Distribution/ Earnings Begin/End dates may not be for that period / apply.  

The Create Paysheet COBOL SQL process (PSPPYBLD) uses tax distribution information to set the state and locality by default on the paysheet and to distribute the employee's hours and/or earnings as specified. If this tax distribution data is changed after the paysheet is created, you must manually update the paysheet with the distribution changes.

What effective dates does Paycalc use for tax purposes?

What dates does the pay calculation look at for tax purposes? 

Ans: 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/98 and a Paycheck Issue Date of 01/06/99.  PeopleSoft Payroll will use the Issue Date to determine which tax record will be used;   in this example 01/06/99 will be used.  This means that the 1999 rates (which are delivered with an effective date of 01/01/99) would be applied.

How does PeopleSoft calculate taxes when an employee transfers, after the pay end date and before the check date?

Ans: The paysheet will be created with PA as the work location, because this is where the employee worked for the time frame of 12/1/00 through 12/15/00.

The paycheck shows the following:
UI will be taken in the new location. In this case it will be OH. If you check the EE tax records, you will see that the UI record is on for OH as of 12/19/2000. Withholding - The employee should be taxed in both states because the reciprocity rule for Ohio residents is "tax in both work and resident state". Ohio will be the resident state. He did live and work in PA and then transferred so that as of the check date he lives and works in Ohio. The residency for this check's tax calculations is based on where he lives on the check date, so Ohio would be right. But he performed the work in PA earlier in the pay period, so a work tax is calculated.

In reviewing this scenrio, the bottom line is that the system now does some "fancy dancing." It looks at the old state as the Work State and the new state as the live state, and calculates taxes based on reciprocity rules between those two states. Of course, if you don't want this "fancy" calculation, then it's back to the same old issue of procedure and timing, and having HR or whomever, wait to enter transfer info UNTIL PAYROLL HAS BEEN CONFIRMED. Then they can go in and enter "backdated" transfer info and new tax locations to their hearts content!

Tax Location and Tax Distribution Must Reflect Employee Work Location

The tax location code assigned at the employee's Job record defines tax jurisdictions based upon where the employee works. The Tax Distribution record contains details for that employee and allows for a percentage allocation when an employee works in multiple locations that fall within different jurisdictions (State or Local).

The employee may also have tax jurisdictions based upon residency and these may be different than the work jurisdictions.  Both resident and work jurisdictions must also be defined in the Employee Tax Data panel.  If an employee does not work in the jurisdiction where they live, the jurisdiction should not be defined at the tax distribution panel.  It should be marked as resident at the employee tax data panel.

For Example: Employee lived in Chambersburg, PA and worked in Washington County, MD.  Based on local reciprocity rules, taxes should be taken for both localities, but were only coming out for the PA local.  Both localities were set up at the employee tax data panel with Chambersburg marked as resident.  The Employee Tax Distribution and/or Tax Location were not set up correctly, so the work only jurisdiction was not calculating. 

How do you set up balance adjustment elements for the new Pennsylvania Act 32 PSD balances?

The Tax balance adjustment process has also been modified to create the
appropriate run results for the new PSD elements.

NOTE: For the Tax Balance Adjustment process to work, the Resident AND Work
Jurisdictions must be entered, including the school district codes, on the
city tax information (local tax rules) form for the assignment.

IMPORTANT NOTE ABOUT SIMPLE BALANCE ADJUSTMENTS:

If a balance adjustment is made to adjust an existing City Subject (RS or
WK), City Withheld (RS or WK) OR a School Withheld (RS) balance in a
Pennsylvania locality, then a corresponding entry must also be made into
the new PSD balances as follows:

PSD Subj Whable
PSD Withheld
City PSD Subj Whable
City RS PSD Subj Whable
City WK PSD Subj Whable
City PSD Withheld
City RS PSD Withheld
City WK PSD Withheld
School PSD Withheld
School RS PSD Withheld

Example:

CITY Withheld (Spring Garden Twp) 5.77
SCHOOL Withheld (YORK SUBURBAN-67940) 5.77

City_RS 39-133-5082
City_SC_RS 39-67940
City_PSD_SUBJECT_RS 39-671501-220102
Subj Whable 1153.85
City_PSD_RS 39-671501-220102             5.77
City_PSD_SC_RS 39-671501-220102      5.77

IF an employee either lives or works out of state. The OUT OF STATE PSD code is 880000.

Will have to do the normal
City Tax Balance Adjustment per Note 227477.1    Jurisdiction Code 39-133-5082
School Tax Balance Adjustment per Note 227477.1  Jurisdiction Code  39-67940

01-JAN-2012
Created an element
Resident PSD Bal Adj > Information > Nonrecurring
Input Values :
Jurisdiction > Character > Sequence 1 > check Required & User Enterable
Subj Whable > Money > Sequence 2 > check User Enterable
City Withheld > Money > Sequence 3 > check User Enterable
School Withheld > Money > Sequence 4 > check User Enterable

Saved as an open Link
Costing does not need to be done

Balances:
City PSD Subj Whable > Feeds > Resident PSD Bal Adj > Information > Subj Whable > Add
City PSD Withheld > Feeds > Resident PSD Bal Adj > Information > City Withheld > Add
City RS PSD Subj Whable > Feeds > Resident PSD Bal Adj > Information > Subj Whable > Add
City RS PSD Withheld > Feeds > Resident PSD Bal Adj > Information > City Withheld > Add
PSD Subj Whable > Feeds > Resident PSD Bal Adj > Information > Subj Whable > Add
PSD Withheld > Feeds > Resident PSD Bal Adj > Information > City Withheld > Add
                       and Resident PSD Bal Adj > Information > School Withheld > Add
School PSD Withheld > Feeds > Resident PSD Bal Adj > Information > School Withheld > Add
School RS PSD Withheld > Feeds > Resident PSD Bal Adj > Information > School Withheld > Add
School WK PSD Withheld > ignore this balance

Created a second element
Work PSD Bal Adj > Information > Nonrecurring
Input Values:
Jurisdiction > Character > Sequence 1 > check Required & User Enterable
Subj Whable > Money > Sequence 2 > check User Enterable
City Withheld > Money > Sequence 3 > check User Enterable

Saved as an open Link
Costing does not need to be done

Balances:
City PSD Subj Whable > Feeds > Work PSD Bal Adj > Information > Subj WHable > Add
City PSD Withheld > Feeds > Work PSD Bal Adj > Information > City Withheld > Add
City WK PSD Subj Whable > Feeds > Work PSD Bal Adj > Information > Subj WHable > Add
City WK PSD Withheld > Feeds > Work PSD Bal Adj > Information > City Withheld > Add
PSD Subj Whable > Feeds > Work PSD Bal Adj > Information > Subj WHable > Add
PSD Withheld > Feeds > Work PSD Bal Adj > Information > City Withheld > Add
School WK PSD Withheld > ignore this balance