Hierarchy
SAP_HRCGB (Software Component) Sub component SAP_HRCGB of SAP_HR⤷
PY-GB (Application Component) United Kingdom⤷
PC08 (Package) HR accounting: GB
IMG Activity
| ID | PYGB_PAE_STAGING_01 | Maintain Solution Change-Over Date (Feature GBCHG) |
| Transaction Code | S_L4H_49003128 | (empty) |
| Created on | 20121123 | |
| Customizing Attributes | PYGB_PAE_STAGING_01 | Maintain Solution Change-Over Date (Feature GBCHG) |
| Customizing Activity | PYGB_PAE_STAGING_01 | Maintain Solution Change-Over Date (Feature GBCHG) |
Document
| Document Class | SIMG | Hypertext: Object Class - Class to which a document belongs. |
| Document Name | PYGB_PAE_STAGING_01 |
Use
CHECK YOUR STAGING DATE!
TPR have based your staging date on information supplied to TPR by HMRC, but that information may not have been as complete or accurate as it could have been. So you need to pro-actively check your staging date. TPR have provided a "Staging Date Checking" tool on their website that will be available from December 2012.
You need to think about ALL your PAYE references that you have employees in and how they interrelate!
Example 1:
It may be that you share a PAYE reference with another part of your business and even though you have only one employee in the PAYE reference that that PAYE reference is still your largest PAYE reference due to the employees that are in that PAYE reference with another part of your business. You will need to make that PAYE reference's staging date the staging date for you also.
Example 2:
You have a number of separate entities within your business. You need to ensure whether they can be treated separately as far as staging is concerned or whether they have to be treated as a single entity.
Requirements
Standard settings
Activities
You need to decide on your Staging Date and then implement that in Feature GBCHG Node 012. This date is fundamental to the PAE solution, but more importantly it is fundamental for you to able to meet your duties.
IMPORTANT:
Ensure that ABKRS is the first decision field in your "decision tree", if you need to make decisions under Node 012.
The reason for this is that both the pre-payroll and post-payroll programs use the Payroll Area entered at the top of the screen to decide whether PAE is active at that point in time. If you use another decision field first (i.e. Company Code BUKRS) then you will get undesirable messages that PAE is not active when you process either the pre-payroll and post-payroll programs.
If you decide not to reflect you actual stating date in Feature GBCHG Node 012, then you cannot expect the PAE solution to react as you would expect;
Example
Example 1:
Employer has a staging date of 01.11.2013. The implementation team has decided not to use the SAP PAE solution and instead are using their own bespoke solution to meet their AE duties. The return value of Node 012 is set as 31.12.9999.
This is a possible approach, but we would hope that all customers will use the SAP PAE solution.
Example 2:
Employer has a staging date of 01.11.2013. But has a Pensioners payroll that they wish to exclude from AE duties. The implementation team has decided not to activate the SAP PAE solution for these pensioners.
The return value of Node 012 is set as 31.12.9999 for the Pensioner Payroll Area.
The return value of Node 012 is set as 01.11.2013 for all other Payroll Areas.
This is ok.
Example 3:
Employer has a staging date of 01.11.2013. The implementation team set up the staging date as payroll area specific, so that the staging date matches the payroll period start date, so the monthly payrolls all have a staging date of 01.11.2013, but the weekly payrolls have a staging date of 04.11.2013 (to line up with the start of the next payroll week).
This is not the correct approach. You can only delay your staging date for a specific group of employees by postponing them.
Example 4:
Employer has a staging date of 01.04.2013. However, due to an upgrade schedule that falls at exactly that point, it is not possible to "Go Live" on the SAP PAE solution before 01.04.2013. The implementation team decides that Staging will be postponed for ALL employees for 3 months on 01.04.2013 (using postponement notice GNA). This will allow them to complete the upgrade before going live of the SAP PAE solution. The implementation team set up the Staging Date as 01.07.2013 and carefully ensure (by using the postponement BADIs) that no further postponement can be applied on 01.07.2013 if any postponement has been customised.
This is not the correct approach, but it is acceptable. The system is likely to process the employees correctly, but there will be no staging data held within SAP and as a direct result the "Registration" report will have to be generated outside SAP.
Business Attributes
| ASAP Roadmap ID | 207 | Establish Reporting |
| Mandatory / Optional | 2 | Optional activity |
| Critical / Non-Critical | 2 | Non-critical |
| Country-Dependency | I | Valid for countries specified |
| Customizing Attributes | Country Key | Country Name |
|---|---|---|
| PYGB_PAE_STAGING_01 | GB | United Kingdom |
Assigned Application Components
| Documentation Object Class | Documentation Object Name | Current line number | Application Component | Application Component Name |
|---|---|---|---|---|
| SIMG | PYGB_PAE_STAGING_01 | 0 | HLA0009560 | United Kingdom |
Maintenance Objects
| Maintenance object type | C | Customizing Object |
| Assigned objects | ||||||
|---|---|---|---|---|---|---|
| Customizing Object | Object Type | Transaction Code | Sub-object | Do not Summarize | Skip Subset Dialog Box | Description for multiple selections |
| PMKC | L - Logical transport object | PE00 | GBCHG |
History
| Last changed by/on | SAP | 20121129 |
| SAP Release Created in |
