Single Touch Payroll - Phase 2
A legislative instrument issued by the Australian Taxation Office (ATO) on 03 February 2021 has confirmed that the commencement date for mandatory Single Touch Payroll Phase 2 reporting will start from 01 January 2022 — a six-month extension from the previously proposed 01 July 2021 start date.
The Single Touch Payroll Phase 2 aims to simplify the reporting obligations for the payer and payee so that consolidated reporting removes the need for manual reporting to other government agencies. Australian Tax Office is changing reporting requirements to better assist employees while completing Individual Income Tax Returns, and income-tested payments are accurately calculated when taking into consideration employee earnings for the financial year.
The biggest change is in the aspect of reporting obligations. By introducing new cessation types, it replaces majority of DHS (Department of Human Services) employment separation certificate forms. Payers are not required to provide separate reports to the Child Support Registrar each month. Payers can voluntarily report child support.
For more details, refer Single Touch Payroll Phase 2 details on the ATO website.
Transitioning to STP Phase 2
A payer can transition from the pay event 2018 to the pay event 2020 service at any time throughout the financial year. Once the payer transitions to and begins reporting through the pay event 2020 service, then the payer must report in-line with the rules of this Business Implementation Guide. A payer must report by income stream collection and provide the employment conditions.
Unlike the initial phase of Single Touch Payroll, phase 2 addresses the interaction between the old and new data, functionality, and design. Many aspects of the reporting have been introduced to meet the needs of Services Australia, which relies on the accuracy and frequency of the granular reporting of income to streamline their welfare payments processes.
The entire financial year data must be present for the key identifiers of ABN, Branch, BMS Id and Payroll Id when YTD data is being reported during the mid-year Go Live.
This steps provide direct mapping between the PAYEVNT.2018 elements and the PAYEVNT.2020 elements:
Where a field is not included in the PAYEVNT.2020 service it is marked as REMOVED.
Where a field is new for PAYEVNT.2020 it is identified as NEW.
Some fields that are the same have enhanced guidance that may have an impact. These are identified as ENHANCED.
Some fields from PAYEVNT.2018 may be mapped to a specific field in PAYEVNT.2020, but the Income Stream Collection depends on what and how those payments for income types are in their PAYEVNT.2018 solutions. These fields are marked as DEPENDENT.
Where one PAYEVNT.2018 field splits into more than one PAYEVNT.2020 field, the decision points are referenced by using references to the PAYEVNT.2018 code label as (2018#999) where 999 represents the number of the label. For example, (2018#47) refers to PAYEVNTEMP47 Payee Gross Payments and the new field is referenced only by its field label. Another example is that (#7) refers to PAYEVNTEMP7 Allowance Type Code. This reference indicates that allowances that were formerly reported under the aggregated gross are now to be separately itemised as specific allowances.
Where a field can only apply to a specific or range of income types, it is referenced as = xxx, where xxx refers to Income Stream Collections.
Where the enumerations have changed, the mapping from old value to new value is included in the mapping comments.
Disaggregation of Gross
The Single Touch Payroll Phase 2 introduces the requirement to report a gross amount for each income type as a disaggregated, or separately itemised, amount. Rather than focus on the Income Tax Return (ITR) classification of assessable income, the data that is to be reported in STP Phase 2 is more aligned to the way the different payment types are categorised in the payroll systems. This change is required to ensure the flexibility of the data use for the future and the full visibility of income for Services Australia to assess, given the different definitions used to determine welfare benefits. Disaggregation of gross provides the granularity to support improving the application of employment income and streamlining claims processes. This improves the accuracy of payments, ensuring individuals receive the right payment at the right time. Gross Amount is the residual amount remaining of the Aggregated Gross YTD after all the other itemised elements have been discretely reported.
Note: PAYEVNT.2020 consists of PAYEVNT (Parent) & PAYEVNTEMP (Child). Payer Total Gross Payments Amount (PAYEVNT22) facts under Payer Period Totals Tuple remains the same of what is being reported under STP Phase 1. Gross Amount (PAYEVNTEMP258) reported under Income Stream Collection (PAYEVNTEMP256) must be reported per income type and by country code. If a payee has received more than one income type in the financial year, or more than one country code for relevant income types, then all Income Stream Collections must be reported each time the payee is included in the payroll for payments subject to withholding. The definition of reportable remuneration has not changed, only the reporting of it has changed.
Pay Event 2020 services has moved to a framework where the Payment Types (labels) are grouped by Income Type and, for some income types, by Country Code. This is known as the Income Stream Collection.
An inbound assignee who is seconded to work in Australia for an Australian entity but is employed by an offshore entity and is paid, in whole or part of their base salary and other remuneration, by an offshore entity. As the work performed in Australia may be subject to payroll taxes, superannuation guarantee and PAYGW, but not wholly paid by the Australian entity, the income must be reported by Country Code of the offshore entity (home country). The following payment types are permissible for the income types of IAA: PAYGW, Gross, Paid Leave, Allowance, Overtime, Bonus and Commission, Directors Fees, Salary Sacrifice, Lump Sum and ETP.
IAA employees are identified by giving supporting element override of ‘I’ value against the variable AUS VR FRGN TYPE. Since the processing of this employee is same as the other normal employees (SAW), same elements are used for reporting.
For specific income types such as Foreign Employment, inbound assignees to Australia and Working Holiday Maker country code are mandatory whereas for other income types it is assumed as AU. To report the country code for these income types, the solution is driven through Supporting Element Override (SOVR) using the variable AUS VR STP CTRY CD.
Note: The Character Value selected in the Supporting Element page a 3 character code. The output file (XML file) prints only the 2 character country code.
Payers who have child support withholding obligations provide monthly reports to the Child Support Program in Services Australia who in turn detail the withholdings made for each payee over the previous month.
Currently, an employer must submit a deduction report to the relevant child support agency when they deduct the child support from an employee's payment.
The inclusion of child support reporting in Single Touch Payroll (STP) works towards reducing the reporting burden placed on payers. A payer’s obligations are satisfied when payment of the child support garnishee amount is received by the Child Support Registrar, not when the amount is reported. The child support amounts reported by the payer using STP are used by Child Support to reconcile the payer’s child support record when payment of reported amounts is received from the payer.
Child Support Garnishee & Deduction amounts processed via STP Phase 2 allows employers to report for both the Parent record (Employer / Financial Period to Date Amount / FPTDA) and the Child record (Employee / Financial Year to Date Amount, FYTDA).
Child Support amounts consist of 3 different types:
Child Support Deductions
Child Support Garnishees
Voluntary Child Support (This is Out of Scope for STP Reporting)
Payers’ may voluntarily choose to report their child support amounts via STP PAYEVNT 2020 Services. Payers’ may elect to commence reporting child support amounts upon/after transitioning to STP PAYEVNT 2020 Services. Payers may choose to move from STP PAYEVNT 2018 Services to STP PAYEVNT2020 Services to be able to report child support amounts.
Salary sacrifice is an agreement between employer and employee that allows the employee to forego some part of their salary in exchange for other benefits.
The primary benefit used in salary sacrifice is the superannuation fund (or ‘super’) which is Australia’s pension program.
The minimum mandatory employer contribution to super is 10.00% of wages, which is known as the super guarantee, and that portion is taxed to the employee at only 15%, much less than income tax rates. A salary sacrifice arrangement will permit employee to shift an additional part of their monthly salary into the superannuation fund, which can reduce taxes and provide greater savings for retirement.
The values permissible for the salary sacrifice type (PAYEVNTEMP266) are:
Superannuation (S) – an effective salary sacrifice arrangement, entered before the work is performed, where contributions are paid to a complying fund, where the sacrificed salary is permanently foregone
Other Employee Benefits (O) – an effective salary sacrifice arrangement, entered before the work is performed, for benefits other than for superannuation, where the sacrificed salary is permanently foregone.
Salary sacrifice contributions can no longer:
be used to reduce ordinary time earnings.
count towards minimum superannuation guarantee obligations.
For the PAYEVNT.2020, this means that if employees were formerly (PAYEVNT.2018) not included in the report, as 100% of their payments were sacrificed, including sacrifice to superannuation, those employees must now be reported. For example, if an employee had reportable payments of 50,000 and 30,000 was sacrificed to superannuation and 20,000 was sacrificed to other employee benefits, resulting in taxable gross of zero, this employee may have previously been excluded but must now be reported.
Note: PAYEVNT.2020 consist of PAYEVNT (Parent) & PAYEVNTEMP (Child).The Payer Total Gross Payments Amount (PAYEVNT22) facts under Payer Period Totals Tuple remains the same of what is being reported under STP Phase 1. Whereas Gross Amount (PAYEVNTEMP258) reported under Income Stream Collection (PAYEVNTEMP256) must be reported per income type and country code without reducing the salary sacrifice amount.
PAYEVNT.2020 consist of PAYEVNT (Parent) & PAYEVNTEMP (Child). Please note that Payer Total Gross Payments Amount (PAYEVNT22) facts under Payer Period Totals Tuple remains the same of what is being reported under STP Phase 1. Whereas Gross Amount (PAYEVNTEMP258) reported under Income Stream Collection (PAYEVNTEMP256) must be reported per income type and country code without reducing the salary sacrifice amount.
A lump-sum payment is often a large sum that is paid in one single payment instead of breaking it up into instalments.
Lump Sum A and B payments cover unused annual leave or unused long service leave. Lump Sum C used to be the component for Payment in Lieu of notice (but not a bona-fide redundancy), classified as an “O” type payment. A Lump Sum D is the tax-free component of a bona-fide redundancy and does not appear on an employee's tax return. Lump Sum E is used when employer make certain Lump Sum Payments in arrears (or back pays). When an employer makes back payment of salary and wages relating to a period PAYEVNT.2018 PAYEVNT.2020 16 PeopleSoft Global Payroll for Australia Single Touch Payroll (Phase 2) Solution Overview Copyright © 2021, Oracle and/or its affiliates more than 12 months before the date that the back pay itself is being paid. A return-to-work amount is paid to induce a person to resume work, on account of either to end industrial action or to leave another employer.
Return to Work Payments will be separately itemised as Lump Sum W rather than included in Gross. Lump Sum E Financial Year – Lump Sum E YTD amounts must be reported by each prior financial year to which the arrears payment relates. Lump Sum payments were previously reported as separate fields within a single Tuple, now it is reported with codes and amount against each Lump Sum types.
RETRO12MTH - Any back payment of remuneration that is accrued or was payable more than 12 months before the date of payment either pay or Update Date.
RETRO CY (Current Year) – Any back payment of remuneration that is accrued or was payable less than 12 months before the date of payment either pay or update date and falls within the same financial year.
RETRO PY (Previous year) - Any back payment of remuneration that is accrued or was payable less than 12 months before the date of payment either pay or update date and falls in the same prior financial year.
|
Page Name |
Definition Name |
Usage |
|---|---|---|
|
GP_PIN |
To retrieve the Cessation Type code by mapping the combination of Action and Action Reasons. |
|
|
GPAU_STP_MLS |
Capture employees medicare levy tier information The STP Preparation Process fetches the information into the fourth character of the tax treatment code. |
|
|
GPAU_STP_PERS_DTL |
Update event adjustments through the Update Event AUS. |
|
|
GPAU_STP_RUNCTL |
Generate or update Pay Event files. For more information on how to generate pay event file, see Generating Pay Event File. |
|
|
GPAU_STP_CAT |
Map the Tuple and, Facts along with respective EOY or STP VR Category for extracting data during STP Pre Process for Pay Event Reporting. |
Services Australia is aiming to implement a solution that uses the expanded STP dataset to streamline the employment separation certificate process. Reporting the type of cessation reason that ended the employment or engagement relationship between the payee and the payer will generally replace the need for payers to provide separate payee employment separation certificates to Services Australia.
ATO has categorised Cessation Reason into the following:
|
Sl.No |
Reason |
Code |
Description |
|---|---|---|---|
|
1 |
Voluntary |
V |
An employee resignation, retirement, domestic or pressing necessity or abandonment of employment. |
|
2 |
Ill Health |
I |
An employee resignation due to medical condition that prevents the continuation of employment, such as for illness, ill-health, medical unfitness or total permanent disability. |
|
3 |
Deceased |
D |
The death of an employee. |
|
4 |
Redundancy |
R |
An employer-initiated termination of employment due to a genuine bona-fide redundancy or approved early retirement scheme. |
|
5 |
Dismissed |
F |
An employer-initiated termination of employment due to dismissal, inability to perform the required work, misconduct or inefficiency. |
|
6 |
Contract Cessation |
C |
The natural conclusion of a limited employment relationship due to contract/engagement duration or task completion, seasonal work completion, or to cease casuals that are no longer required. |
|
7 |
Transfer |
T |
The administrative arrangements performed to transfer employees across payroll systems, move them temporarily to another employer (machinery of government for public servants), transfer of business, move them to outsourcing arrangements or other such technical activities. |
Use the bracket data page AUS BR CESATN TYPE to retrieve the Cessation Type code by mapping the combination of Action and Action Reasons.
The advantage of using this bracket is to help customers dynamically accommodate their customer specific Action and Action Reasons.
Navigation:
This example illustrates the fields and controls on the Brackets_Data page.
The purpose of this fact is to inform government of the employment or engagement relationship and define the withholding rates applied by the payer. This is an annual dollar amount of total offsets claimed by employee to vary their withholding, this field should be supplied only if employee claims an offset.
Payees may be eligible to claim a tax offset to vary their PAYGW amount. The offset is claimed by providing the payer with the completed Withholding Declaration form/s (NAT 3093, 5072)
In PeopleSoft, Tax Offset Amount is fetched from Maintain Tax Data AUS > Total Rebates field.
Maintain Tax Data AUS page
Tax Treatment Code is used to define the core rate or amount of withholding.
There are two types of tax tables/guidance available to define the core rate or amount of withholding:
People - Applicable to a type of worker, defined by residency status, profession, age, visa arrangements. There are options within the categories that further define PAYGW variations for thresholds, professions, living arrangements, residency status, regional programme, registration status, instalment rates or work patterns
Payments - Applicable to a specific type of payment only, defined by circumstances or other factors like Tax Table for unused leave payments on termination of employment, as these apply specifically to the explicit payments.
Permissible variations of the core rate or amount of withholding that “supplement” the PAYGW rate:
Study and Training Support Loans – where the payee has an obligation to repay a higher rate of withholding when income thresholds are reached.
Medicare Levy Variations – where the payee may have personal circumstances that meet pre\u0002defined criteria that permit a lower rate of the Medicare Levy component of the withholding rate. The variation includes surcharge, exemptions, reductions.
Purpose of the Tax Treatment field is to inform the ATO of the factors that the payer has applied to determine the withholding for the worker/payee, excluding payment-specific withholding rates.
Tax Treatment Code will be 6-Character Code, where the first two characters have specific values for every payee and characters 3-6 are specific values only if the payee notifies choices.
Navigation
A new bracket AUS BR TXTRMT CODE is created for fetching the Tax Treatment Code by mapping the combination as defined by ATO for various types of Payees.
A new bracket AUS BR TXTRMT CODE is created for fetching the Tax Treatment Code by mapping the combination as defined by authorities for various types of payees.
Bracket for fetching Tax Treatment Code
A new component for STP Medicare Levy Surcharge solution to capture employees medicare levy tier information (Tier 1, 2, and 3).
Use STP Medicare Levy Surcharge (GPAU_STP_MLS) page to capture employees medicare levy tier information The STP Preparation Process fetches the information into the fourth character of the tax treatment code.
This example illustrates the field and controls of STP Medicare Levy Surcharge page.
Note: Medicare Levy Surcharge is purely for the reporting purpose and not considered for the taxation. When Payee Tax Scale is '3' or '4R' or '4N' or 'H' then Medicare Levy Surcharge is not provided.
Update Event aligns the latest employer Business Management Software (BMS) data with the last employee data reported to the ATO, or to assist with the End of financial year (EOFY) processes, including finalization and amendments to Single Touch Payroll (STP) for prior finalized years.
After the end of fiscal year (June 30th), any changes made to report employee data for the prior financial year must only be submitted through the update event.
Update event must include the latest Year to Date (YTD) value for all payments (including each Employment Termination Payment (ETP by payment date and code) made in the financial year. It cannot include only the values that have changed.
Employers’ pay period totals for gross payments and PAYG withholding cannot be included in an update event as there is no associated payment to the employee when the changes are reported via the update event.
Here are a few examples where the employer can make use of the Update Event:
Overpayment within a financial year - Where there is no future payment to the employees, YTD amounts should be reduced to reflect the overpayment through an update event.
Misclassification with no additional payment - misclassification is when information has previously been reported under an incorrect salary and wage item and there is no additional payment to the employee.
Where an employee is reported under the incorrect ABN or PAYG withholding branch - If an employee has been reported under an incorrect ABN the employer needs to report these amounts under the correct ABN and adjust the employee YTD amounts on the incorrect ABN.
Overpayment identified after End of Financial Year - If the overpayment occurred in more than one prior year, the employer should provide an update event for each financial year reported via STP.
Steps for running the Update Event:
Select the Employee for whom the update event is to be executed. Note: Update Event should always be submitted against the last Pay Event.
Click + to add a new row.
Select Update Event.
Update Event Date – This field is enabled once the user selects Update Event Radio Button. This is a mandatory field and the same is used as an indicator to generate the Update Event File.
Incorporate the necessary correction or updates to the respective Personal and Payroll fields and save the page.
Note: Any data entered using this component will not cascade to Payroll, user need to take care of it.
Use the search based on various options like EMPLID, Tax Year, Pay Entity, Pay Group & Calendar Group ID. This is a new component to accommodate the disaggregation and other reporting requirement of STP Phase 2.
Use STP 2.0 Update Event AUS (GPAU_STP_PERS_DTL) page to update event adjustments through the Update Event AUS.
Navigation
Note: The existing component STP Update Event AUS can be used only for PAYEVNT 2018.
This example illustrates the fields and controls of the STP 2.0 Update Event AUS page.
Note: The page lists all Payee data for which payroll are finalized and Pay Event File are already generated. Ensure that the update event executes only after the Pay Event in original submitted to ATO. For example, if the Pay Event are submitted for July and Aug 2022, then update event can be submitted only against August 2022 Pay Event.
|
Field or Control |
Description |
|---|---|
|
Personal Information |
Employee details are fetched from PS_GPAU_STP_HR_STG table and if user updates any data, the same will consider while reporting Update Event. |
|
Final Event Indicator |
This is reported per employee, per payroll ID as part of the employee record. User may submit via pay event or through update event. Users need to select the check box to report this indicator in output file. |
|
Employment Basis |
As part of Onboarding tuple in PAYEVNT.2018 and moved into Employment Conditions tuple. A mandatory field to be included in every report of Submit and Update. This field is used to determine hierarchy, for those workers with multiple engagements. Valid values are F = Full time, P = Part time, C = Casual, L = Labour Hire, V = Voluntary Agreement, D= Death benefits, N = non\u0002employee. |
|
Tax offset |
Annual dollar amount of total offsets claimed by employee to vary their withholding, this field should be supplied only if employee claims an offset. |
|
Tax treatment Code |
The tax treatment of an employee, including main tax scales, student loans and Medicare levy variations. |
|
Cessation Type |
to enter when cessation date is provided. |
|
Income Stream |
On selecting the calendar group id for which the amendments to be done, the system by default would populate the values submitted in the original file. Earnings information that needs to report in an Update Event should contain changed or corrected year to date values you originally submitted on the employee's Pay Event for the period in the respective fields. For example: If you report the value via Pay Event as $500.00, and the actual value to correct or change is $600, then the respective field need to populate with new values as $600.00 The required data for Wages & Taxation derived from PS_GPAU_STP_PAYTBL & for Employee Termination Payments (ETP) it is PS_GPAU_STP_ETP. |
|
Employee Termination Payments |
As per ATO, Employee Termination Payments Codes and Values can iterate up to a maximum of 25 times. Thus, once the user made use of 25 field values, add button will disable from the grid. |
|
Allowances |
Modify related values using this field and this can hold maximum of 30 Allowance category. As per ATO, Employee Allowance Codes and values and can be iterated to maximum of 30 times. Thus, once the user enters 30 field values, add button will disable from the grid. Allowances information are derived from PS_GPAU_STP_ALLOW record. |
|
Deductions |
Union Fees, Workplace Giving, Child Support Deductions and Garnishees can be modified using this field and can hold maximum of 4-deduction categories. As per ATO, Employee deduction codes and Values and can be iterated up to a maximum of four times. Thus, once the user enters 4 values, the add button will be disabled from the grid. Deduction information derived from PS_GPAU_STP_DED record. |
|
RFB/Super Entitlement |
Modify Superannuation Contribution Tuple data. Superannuation information derived from PS_GPAU_STP_RFB/PS_GPAU_STP_SUP record. |
Use the STP Payroll Event File AUS page (GPAU_STP_RUNCTL) to generate or update Pay Event files. For more information on how to generate pay event file, see Generating Pay Event File
Navigation:
This example illustrates the fields and controls on the STP Payroll Event File AUS (1_2)Page. You can find definitions for the fields and controls later on this page.
This example illustrates the fields and controls on the STP Payroll Event File AUS (2_2)Page
|
Field or Control |
Description |
|---|---|
|
Tax Year |
Enter the Fiscal Year for which the update event is processed. For example, enter, "2017" for 2016-17 Tax Year. |
|
STP File Type |
Select the STP file type. Available options are:
|
|
Pay Entity |
Select the pay entity, for which the employer would like to generate Payroll Event (PAYEVNT & PAYEVNTEMP). |
|
Run Type |
Select the Run Type. Available options are:
|
|
XML with Root Node |
Select the checkbox if you want to generate a temporary XML file with Root Node, which can be viewed in a browser, with the ability to export to excel. Note: This option is for easier validation. The Final XML file to be submitted to the authorities should be generated without a Root node, which is a non-standard XML structure and thereby does not open properly in a normal browser; instead, the file can be opened and reviewed in text editors, such as Notepad, Notepad++ or Text Pad. |
|
Output |
For each entity, there will be a Single File (contains PAYEVNT & PAYEVNTEMP in a single file with Parent and Child) are generated in XML format as per ATO guidelines. |
|
Pay Group |
Select the paygroup if you want to generate the file for a particular pay group. For example, if there are pay groups for Weekly and Monthly, employers would be able to generate the separate file for each pay group. |
|
Update Event Date |
Select the date on which the update event is carried out for the employees. |
|
Reporting Party |
Select the Reporting Party. Available options are:
|
|
Declaration |
Select the option as True or False to indicate whether the terms stated in the Declaration Text have been accepted or declined. |
|
Final Event Indicator |
An employer is required to make a declaration to the ATO, that they have provided all the information for each employee for a financial year, by providing the finalization indicator as a part of an employee’s Single Touch Payroll report. Select this check box if you want to include this indicator in the final output. |
|
Final Pay Event |
This indicates whether the report is the employer’s final payroll for the current reporting period. An employer is required to make a declaration to the ATO, that they have provided all the information for each employee for a financial year, by providing the finalization indicator as a part of an employee’s Single Touch Payroll report. This declaration allows ATO to make the employee information available for income tax return prefill for employees. It will also update the employee’s myGov payroll page, to show that the Single Touch Payroll reported information is final for the financial year. |
|
Submission ID |
A unique identifier to identify a payroll event transaction sent to ATO. PeopleSoft while generating the Pay Event automatically generates Submission ID. |
Use the STP Category Setup AUS page (GPAU_STP_CAT) to map between XML Tuple with Category and XML Fact with Sub Category. SOVR Variable determines, the Variable that is assigned in the Earnings and Deductions to determine the SOVR category in the Supporting element override. The setup uses the EOY VR CATEGORY (existing one which is used for generating the Payment Summaries), and STP VR CATEGORY/STP VR P2 CATEGORY (these are new variables created to map against respective earnings/deductions) required for STP file generation and reporting. For each active SOVR category against an earning or a deduction, a new variable should be assigned. To accommodate three active SOVRs in the supporting element override, customers can use these delivered variables.
Navigation:
The STP Category setup AUS page sets the mapping between XML Tuple with Category and XML Fact with Subcategory.
This example illustrates the STP Category Setup AUS page.
|
Field or Control |
Description |
|---|---|
|
Effective Date |
Date between the Period Begin Date and Period End Date of the Go-live period. The below dates should be synced when transitioning from Phase 1 to Phase 2 (any date between the Period Begin Date and Period End Date of the Go-live period):
|
|
Record (Table) Name |
Select the Staging Record where the data to be stored for reporting while running STP Preparation Process. This field is to define the Staging table record where the data to be stored for final reporting. |
|
Report PTD |
Select the check box if PTDs are required under the specified Category and Sub-Category. This enables PTD field name where we can define the Field of the staging table defined under Record Name. The PTD value calculated update in the respective field defined. |
|
Report YTD |
Select the check box if YTDs are required under the specified Category and Sub-Category. This enables YTD field name where we can define the Field of the staging table defined under Record Name. The YTD value calculated update in the respective field defined. |
|
Iterative |
Select this checkbox if the amounts under a tuple needs to be reported as separate collection. For example, Allowance, Deduction, Paid Leave, Lumpsum Payments, etc. Note: YTD Field Name will be the same for all the Sub-Categories of Iterative Category. |
|
Sub Category |
This field stores the list of XML facts with amounts to be reported under the respective Categories. |
|
Description |
Meaningful description for the sub category. |
|
YTD Field Name |
This field stores the Year to date amounts to be reported in PAYEVENTEMP XML extracted during STP Prep process AUS. The List of Values displays the fields of the Record Name specified under the Category. |
|
SOVR Variable |
Select the variable that is assigned in the Earnings. This determine the SOVR category and the Supplementary Element Override. The SOVR Variable are either EOY VR Category or STP VR Category. |
|
SOVR Category |
Select the respective EOY VR or STP VR Category corresponding to those earnings and deductions that is required for each facts of that Tuple. This determines the actual SOVR categories that contribute to the Sub-Category, which is the Final amount to display in the report. |
|
Sign |
Determines whether the earnings or deductions of the selected SOVR to be added or deducted for reporting. |
Note: This setup is pre-seeded as system data and employer can make necessary changes to set up additional categories as part of STP Reporting.
STP Income Type Field Mapping
STP Income Type Field Mapping is to draw between fields for Gross, Tax, CDEP, EFEI between GPAU_STP_PAYSTG and GPAU_STP_PAYTBL to convert payroll data stored in Phase 1 staging record into Phase 2 format of reporting. This transition is from horizontal to vertical data.
In Phase 2, Gross, tax, bonus and commissions, directors’ fee, overtime payments, CDEP, EFEI are still stored in PS_GPAU_STP_PAYSTG but data is converted and stored in PS_GPAU_STP_PAYTBL to make it compatible with the latest format. This conversion is done with the below setup.
STP Income Type Field mapping should be done only for the categories related to Income types like INB, IAA, WHM, FRGN, JPD (not valid for Phase 2).
This mapping needs to be done if the customer wants to add a new Income type as a Category.
Note: STP Income Type Field Mapping should be done only if customer has any specific income types which is not delivered by Oracle.
This example illustrates the fields and controls on the STP Category Setup AUS_STP Income Type Field Mapping page.
|
Field or Control |
Description |
|---|---|
|
Target Record |
This field is to define the Staging table record of Phase 2. |
|
Source Record |
This field is to define the Staging table record of Phase 1. |
|
Income Type |
This field determines the income type. |
To add a new income type, perform the following:
Add the new SOVR Category to the STP SOVR Setup Component.
Map new Earnings & Deductions with new SOVR Category in the Supporting Element Override.
Add a new row in STP Category Setup with the Category of the new Income Type.
Enter the STP Phase 2 Effective Date and Record Name as GPAU_STP_PAYSTG.
Add the new Sub-Categories for GROSS and TAX along with mapping the respective SOVR Categories.
Enter the YTD field name for Gross and Tax as the respective fields delivered for each income type.
In STP Income Type Field Mapping, add a new row with STP Phase 2 Effective Date.
Select the Target Record as GPAU_STP_PAYTBL and Source Record as GPAU_STP_PAYSTG.
Field mapping should be done for Gross and Tax.