Appendix - Merging/Splitting PayGlobal databases

Overview

The ATO accept that an employer may have multiple databases and/or use multiple software products to support how the organisation segments the payroll across their business. For example, "Executive" payroll on one DB and "Salary/Wages" on another, or prehaps its segmented by location/trading entity).

The ATO require each database that the data comes from to be uniquely identifiable and as such the ATO creates a virtual Payment Summary per unique combination of:

• ABN/Branch
• Business Management System Identifier (BMS ID)
• Employee code

In PayGlobal your BMS ID is formed as follows:

MYOB-<PRODUCT>-<PAYER ABN and BRANCH>-<GUID>

Where:

• MYOB is hardcoded
• <PRODUCT> is PAYGLOBAL
• <PAYER ABN and BRANCH> is derived from the Internal Company record linked to the pay being submitted
• <GUID> is a Globally Unique Identifier, this value is generated automatically when a new DB is created.

To avoid submission rejections and/or issues with filing tax returns it's important to follow the correct processes when it comes to dealing with the following business activities:

• Acquisitions and mergers (i.e. adding new "payers" to an existing PG database that may or may not have come from another PG database)
• Partial migration of data from "on-prem" to "on-line" or vs versa
• Renaming employee codes

Acquisitions and mergers

Employee moving to a new payer

Where the employee's payer has changed (new ABN or same ABN just new branch), you need to

1. Determine whether the current YTD values all need to be transferred to new payer or whether some remain with old payer.
2. Complete termination procedures for the old payer

   If all YTD values for an employee(s) are to be transferred to the new payer, you need to do a manual pay in old DB to zero out current YTD amounts.

   In STP v3 - do not submit the related pay event. The ATO doesn't accept pay events with negative values. Instead, create and send an Update event for those employees.

   In STP v4 - you can submit the related pay event or send an Update event

In the new DB, create an opening balance pay to bring across the transferred YTD amounts. Submitting the related pay event for the opening balance pay should get everything on the right track to go forward.

If the new payer is commencing part-way through the current YTD, then the old payer will need to submit a finalisation event. However, if some employees are to be retained by the older payer, this will need to be completed in two steps:

1. Create/send Finalisation event for old payer. This indicates to the ATO that these employees will not receive any further pays from this employer this year.
2. Create/send Update event for remaining employees on old payer. This reverses the finalisation flag on all remaining employees, and also caters for correcting employees that might not be included in the next pay event.

Splitting databases

IMPORTANT: Taking a backup from one DB and restoring it separately DOES NOT constitute the definition of a new database.

If you use this process to move "some" employees from one database instance to another, the subsequent instances require a new GUID to be created manually.

If the new GUID is not generated, then you run the risk of having submission failure!

The message you will receive is:

"A record with the same submission ID already exists, we were unable to process your submission because we already have a submission with this submission ID"

The "Submission ID" is your Pay Sequence number. Which means "original" database and the "copy" database have both submitted a payevent for the same payer with the same pay sequence number even though the employee content is different.

IMPORTANT: You will require Professional Services assistance to help create a new GUID

Renaming employee codes

IMPORTANT: It is recommended to engage with Professional Services if you are considering changing employee codes.

When you change an employee's employee code, EVERY record in your database for the employee is updated with the new code.

This causes the following issues:

1. Inability to amend previous tax year's data.

   If you do need to report an amendment to a previous tax year after the employee code has been changed - your only option is to contact ATO directly.

2. Multiple Payment Summary records for the same employer in the same tax year.

   With STP v3, preventing this issue requires zero-ising the values for the old employee code held by the ATO before submitting any pays under the new employee code.

   Not doing this can block your/employee's the ability to complete employee tax returns .

   Timing of this process is crucial. It must to be actioned between pays.

   Begin the process only after successful submission of the last pay where the old employee code is used AND before changing the employee code

   You must do the following:

   1. Open a manual pay and use this to action a full YTD reversal.
   2. Process/close the manual pay - DO NOT submit the related Pay Event!!
   3. Create and submit an "Update" event.
   4. Once the Update event has been submitted successfully, roll-back and reset the manual pay - DO NOT submit the related Pay Event!!
   5. Change the employee code

   If the above process is not followed, the only way to remove the obsolete Payment Summary records from the ATO is to contact them directly.

Topic: 44674