This page (revision-26) was last changed on 26-Nov-2021 10:22 by Karen Parrott

This page was created on 26-Nov-2021 10:22 by JEscott

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note
26 26-Nov-2021 10:22 5 KB Karen Parrott to previous
25 26-Nov-2021 10:22 5 KB mmcfarland to previous | to last
24 26-Nov-2021 10:22 5 KB mmcfarland to previous | to last
23 26-Nov-2021 10:22 5 KB khiggs to previous | to last
22 26-Nov-2021 10:22 5 KB khiggs to previous | to last
21 26-Nov-2021 10:22 5 KB kparrott to previous | to last

Page References

Incoming links Outgoing links
UPTR
UPTR

Version management

Difference between version and

At line 4 changed one line
The Process Pay Transactions (UPTR) form allows you to process pay transactions according to selection criteria, from [IPTR] (Pay Transactions) and create pay headers and pay lines. These new pays are then audited ([UPAUDT]) to prepare them for calculation ([UPCALC]).
The Process Pay Transactions Report (UPTR) processes pay transactions according to the defined selection criteria on the Maintain Pay Transactions [IPTR] form and creates pay headers and pay lines. These pays are then audited through the ([UPAUDT]) process and prepares them for calculation for the ([UPCALC]) process.
At line 7 changed 4 lines
* Transactions within a batch will be bypassed if the Time Code does not have an associated Pay Component in [IDTC] and also when the Associated Pay Component is not valid (Based on PCRULES) for the Employee Entity, Unit and Group.
* With the introduction of this Preference [UPTR CLEANUP(System_Preference)], the User can force UPTR to mark the Batch as ‘Processed by UPTR’.
* If UPTR locates this Preference with a value of ‘Y’, then it will mark the Batch as Processed regardless of any errors located on Transactions in the Batch.
* In addition, ANY Time codes that do NOT have an associated PC need to have the 'Bypass UPTR' toggle turned on (in [IDTC]) to allow the preference to work properly.
* Transactions within a batch will be bypassed if the Time Code does not have an associated Pay Component in [IDTC] and also when the Associated Pay Component is not valid (Based on PCRULES) for the Employee Entity, Unit and Group.
* By defining the [UPTR CLEANUP(System_Preference)] Preference, users can force UPTR to mark the batch as ‘Processed by UPTR’.
** When this Preference is set to YES, UPTR will mark the batch as 'Processed', regardless of any errors located on Transactions in the batch.
* In addition, ANY Time codes that do NOT have an associated PC must have the 'Bypass UPTR' toggle set to ON (in [IDTC]) to allow the preference to work properly.
At line 12 changed one line
This form creates one batch per run and creates pay headers within that batch or adds to existing pay headers with matching EE, Pay Period and Pay Category.
This process creates one batch per run and creates pay headers within that batch, or, adds to existing pay headers with the matching EE, Pay Period and Pay Category.
At line 14 changed one line
If the Updating Existing Pays toggle is on, then UPTR will attempt to locate a pay to use before creating a new one.
If the 'Updating Existing Pays' toggle is set to ON, UPTR will attempt to locate a pay to use before creating a new one.
At line 16 changed one line
This form will create pay headers and/or add information to existing pay headers with matching EE, pay period and pay category.
If multiple transaction batches are chosen in one UPTR run, any employees in multiple batches will have one pay header generated with multiple transactions.
At line 18 changed 3 lines
If multiple transaction batches are chosen in one UPTR run, any employees in multiple batches will have one pay header with multiple transactions.
What are the conditions when a UPTR will create a new pay header even if the employee has an existing pay header for the same payroll already?
What are the conditions when UPTR will create a new pay header even if the employee has an existing pay header for the same payroll already?
At line 22 changed 6 lines
* Wether or not a new Pay Header is created is determined by comparing the values in all of the columns and they all must match for the Employee Pay to be considered ‘Existing’.
* This determination is done one transaction at a time as the records are processed from IPTR. Theoretically, a separate Pay Header could be created for each Transaction.
* The information that must be identical are
** Employment Pay Category Pay Period Group School District Work State/Province Home State/Province Work Jurisdiction Home Jurisdiction
** It also depends on the ‘Prior Period Separate’ Toggle in UPTR
** To get more complicated the determination of the ‘Group Code’ depends on the setting in the [GROUP_SOURCE] column in [IDWR]
* Whether or not a new Pay Header is generated is determined by comparing the values in all of the columns and they all must match for the Employee Pay to be considered ‘Existing’.
* The parameter ‘Demographics Source’ will be used to determine which date to use when comparing columns from the employee’s information, which will then determine if changes in the employee’s data will cause a new pay header to be generated.
* The ‘Prior Period Separate’ toggle setting in UPTR is also used to determine if a new pay header will be generated.
* This determination is done one transaction at a time, as the records are processed from IPTR. Theoretically, a separate Pay Header could be created from each Transaction.
* The information that must be identical are:
** Employment Pay Category
** Pay Period
** Group
** School District
** Work State/Province
** Home State/Province
** Work Jurisdiction
** Home Jurisdiction
* The determination of the ‘Group Code’ also depends on the setting in the [GROUP_SOURCE] column in [IDWR]
\\
At line 36 added one line
When the IPTR record has the Work Tax Jurisdictions (GNIS Code), it will be considered an override on the Work Jurisdiction for the IPPH form. A new Pay Header will be created on IPPH for each jurisdiction.
At line 38 added one line
At line 31 changed one line
!!Report Parameters & Filters
!!UPTR Report Parameters
At line 33 changed 13 lines
||Report Parameters||
|Entity|Mandatory, LOV available\\Limits the process to the entity specified.
|Pay Calendar|Mandatory, LOV Available \\The report will be limited to the pay calendars identified in this field.
|Current Pay Period|Mandatory, LOV Available\\The report will be limited to the pay periods identified in this field.
|Demographics Source|Mandatory, [Date Source|X_UPTR_DATE_SOURCE] lexicon available\\This field is used to identify which date to use to get the employee’s information, which will then determine if changes in the employee’s data will cause a new pay header to be created. The values are: \\01-Use the Transaction Date \\02-Use Pay Period End Date (default value)
|Pay Issue Period|Optional, LOV Available \\If this is not entered, the system will derive the [IPPH] Pay Issue Date from the Pay Transaction with the latest Transaction date.\\ \\If a Pay Period is entered in this field, the system will use the associated Pay Issue date from the Pay Calendar.
|Override Batch Code|Optional, Text
|Pay By|Optional, [Pay By|X_PAY_BY_METHOD] lexicon available\\This field allows you to indicate the payment method
|Prior Period Separate|Optional,[Yes or No|X_YES_NO} Default is No. If set to Yes, then transactions from a prior period will be put into a separate pay header.
|Create as Eligible|Optional,[Yes or No|X_YES_NO] lexicon available\\Should the pay header batch be created as eligible?
|Update Existing Pays|Optional,[Yes or No|X_YES_NO] lexicon available\\If a pay header already exists for this pay period and category and is not calculated or closed, should it be updated with the transactions being processed?
|Bypass if Paid in Period|Optional,[Yes or No|X_YES_NO] lexicon available\\Should the pay header be bypassed if already paid in this period?
|Exception Level|Optional, [Exception Level|X_TRACE_LEVEL] lexicon available\\This field defines the exception level (report messages) required.
||Field||Description
|Entity|Mandatory, LOV available. \\Users can define a specific entity to be processed.
|Pay Calendar|Mandatory, LOV Available. \\Users can define specific pay calendars identified to be processed.
|Current Pay Period|Mandatory, LOV Available. \\Users can define specific pay periods to be processed.
|Demographics Source|Mandatory, [Date Source|X_UPTR_DATE_SOURCE] lexicon available. \\Defines the date to process employee information, which will then determine if changes in an employee’s data will generate a new pay header. The values are: \\01-Use the Transaction Date\\02-Use Pay Period End Date (default value) \\03-Use Pay Issue date\\04-Use Pay Period Start Date (for use with UPCPAY created pay headers)
|Pay Issue Period|Optional, LOV Available. \\If this field is not defined, the system will derive the [IPPH] Pay Issue Date from the Pay Transaction with the latest Transaction date.\\If a Pay Period is defined, the system will use the associated Pay Issue date from the Pay Calendar.
|Override Batch Code|Optional, Text. \\Users can enter a specific batch code to override.
|Pay By|Optional, [Pay By|X_PAY_BY_METHOD] lexicon available. \\This field defines the payment method.
|Prior Period Separate|Optional, [Yes or No|X_YES_NO] Default is No. \\When this field is set to Yes, transactions from a prior period will be generated into a separate pay header.
|Create as Eligible|Optional, [Yes or No|X_YES_NO] lexicon available. \\When this field is set to YES, the pay header batch will be created as eligible.
|Update Existing Pays|Optional, [Yes or No|X_YES_NO] lexicon available. \\When this field is set to YES, if a pay header already exists for this pay period and category, and is not calculated or closed, it will be updated with the transactions being processed.
|Bypass if Paid in Period|Optional, [Yes or No|X_YES_NO] lexicon available. \\When this field is set to YES, the pay header will be bypassed if already paid in this period.
|Exception Level|Optional, [Exception Level|X_TRACE_LEVEL] lexicon available. \\This field defines the exception level (report messages) to be printed.
At line 47 changed 4 lines
||Report Filters||
|Payroll|Optional, Multiple, and LOV available\\Multiple payrolls may be selected per execution of this function.
|Pay Category| Optional, Multiple, and LOV available\\Users must indicate the category that the batches and pay headers are to be\\processed under.
|Batch Number|Optional, Multiple, and LOV available\\This is the pay transaction batch that is to be processed.
!!UPTR Report Filters
At line 58 added 5 lines
||Field||Description
|Payroll|Optional, Multiple, and LOV available. \\Multiple payrolls can be defined for each execution of this function.
|Pay Category| Optional, Multiple, and LOV available. \\Users must define the category that the batches and pay headers are to be processed under.
|Batch Number|Optional, Multiple, and LOV available. \\Defines the pay transaction batch to be processed.
This page (revision-26) was last changed on 26-Nov-2021 10:22 by Karen ParrottTop