High- Level Specification

Functional Overview

Standard fields "Person Responsible No." and "Applicant No." are utilized in Project Definition and Work Breakdown Structure (WBS) elements of a project to track accountability and facilitate project-related notifications & workflows. Given that standard fields are maintained through manual configuration. In Syway design , it is intended to use Position numbers in this table based on the roles assigned. This means-

• HR positions assigned to specific Security Roles will be designated as the responsible entities at the Project Definition and WBS element levels.
• It supports organizational continuity, as responsibilities are tied to HR Position rather than individuals- reducing the need for manual updates when personnel changes occur.

Scope and Objectives

Scope- This enhancement defines a scheduled batch job that extracts HR positions based on their Security Role assignment and updates-

1. Person Responsible No. Table: Populated with positions linked to Security Roles ‘Person Responsible - Project’, ‘Person Responsible - WBS’
2. Applicant No. Table: Populated with positions linked to Security Role ‘Project Financial Controller’.

Objective- The key objective is to auto populate the Person Responsible and Applicant tables with relevant Positions based on relevant Security Roles.

N/A

Process steps are-

Assumptions

• The system will have predefined and stable Security Role. Security Roles like ‘Person Responsible – Project’, ‘Person Responsible – WBS’, and ‘Project Financial Controller’ are expected to be consistently active. These Security Role name can vary based on Syensqo's nomenclature standards. 
• One Position will be assigned to a single user.
• HR positions do not have direct security role assignments.

Dependencies

• HR master data must be up to date i.e. Positions must be assigned to relevant Personnel Nos.
• Table structures for Person Responsible No. and Applicant No. must allow maintenance via Batch Job without creating Transport Request.
• Given that HR Position is Tier-1 master data, they will be replicated across all instances along with its associated infotypes.

Security, Integrity and Controls

• Authorization Checks: Batch job runs under a technical user with write access to Person Responsible No. and Applicant No. tables.

Configuration Requirements

N/A

Language Requirements

N/A

Special Requirements

N/A

Design Rationale

Functional Requirements

The proposed batch job must fulfill functional requirement to ensure accurate, Security Role based HR Positions via SAP User ID are available and extracted for the project governance. First, the system must extract HR positions from standard infotypes by evaluating their relationship to predefined Job i.e. "Person Responsible- Project", "Person Responsible- WBS" and Project Financial Controller. 

Once extracted, the batch logic must filter positions based on Security Role: positions linked to "Person Responsible- Project", "Person Responsible- WBS" Security Roles must be inserted or updated in the Person Responsible table, while those linked to the Project Financial Controller Security Role must populate the Applicant table. 

Additionally, the batch job must log all successful and failed updates, capturing metadata such as timestamp, record ID, and error type to support audit traceability. 

Proposed Technology to Use

N/A

Data Source Considerations

N/A

Data Validation Considerations

N/A

• Data Validation: Position IDs are validated before update.

Custom Tables

N/A

Master Data

N/A

Configuration Table

N/A

Selection Screen Enhancement

Processing Logic

This enhancement is initiated through a daily batch job to ensure that Job based positions are consistently maintained within the TCJ04 & TCJ05 tables, sequence is-

Step-1 Pass Person Responsible-Project or other roles to AGR_USERS-AGR_NAME and pick all users with valid validity i.e. current date must be falling between Start (FROM_DAT) and End date (TO_DAT). 
Step-2 Pick the User ID and get the active Personal no. from PA0105. Pass User ID to PA0105-USRID where PA0105-USRTY= 0001, ensure active Personnel No. i.e. current date must be falling between Start (BEGDA) and End date (ENDDA). Pick personal no. PA0105-PERNR.
Step-3 Pass the Personal no. to HRP1001 to get the active Position. Pass below information to HRP1001 to pick active position i.e. HRP1001-SOBID
OTYPE = P
PLVAR = 01
RSIGN = 008
Current date between Start (BEGDA) and End date (ENDDA) to ensure Person to Position mapping is active
SCLAS = S
Pick SOBID

Step-4 Pick Position description from HRP1000-MC_STEXT where     
OTYPE= S
OBJID= Position no.

1. Identify Person Responsible Positions

           Pass Personnel Area defined in the selection screen and pick all active Positions i.e. pass Personnel Area in HRP1008-PERSA and pick all active HRP1008- OBJID. Get only those positions which are assigned to specified Jobs Person Responsible- Project" or "Person Responsible- WBS"- 

1. 1. Object Type = S (Position)
   2. Relationship type/relationship = B and Relationship object= 007
   3. Position with future end date are Active Positions, Positions with past End Dates are Inactive Positions.
   4. Infotype =1001, Subtype B007, Type of related object = C i.e. Job 
   5. Retrieve the latest position description from HRP1001 using the end date logic.
   6. If a Position is found having both the Jobs then continue with single record with job "Person Responsible- Project".

        2. Identify Applicant Positions

          Pick all active Positions based on Job "Project Financial Controller" where

1. 1. Object Type = S (Position)
   2. Relationship type/relationship = B and Relationship object= 007
   3. Positions with future end date are Active Positions, Positions with past End Dates are Inactive Positions.
   4. Infotype =1001, Subtype B007, Type of related object =C i.e. Job 
   5. Retrieve the latest position description from HRP1001 using the end date logic.

       3. Select action-

• Create
  • Person Responsible table

                      For Job i.e. HRP1001-SOBID = "Person Responsible- Project" or "Person Responsible- WBS", Compare TCJ04 table entry with Step-1 data.

                      If new Positions are found in Step-1 data, then insert them as new Records in TCJ04 i.e. Position in VERNR and Position text in VERNA.

• • Applicant table

                     For Job i.e. HRP1001-SOBID = "Project Financial Controller", Compare TCJ04 table entry with Step-2 data.

                     If new Positions are found in Step-1 data, then insert them as new Records in TCJ05 i.e. Position in ASTNR and Position text in ASTNA.

• Change-
  • Person Responsible table

                      For Job i.e. HRP1001-SOBID = "Person Responsible- Project" or "Person Responsible- WBS", Compare TCJ04 table entry with Step-1 data.

                      If same Positions are found in both the tables, then update each Position text i.e. TCJ04-VERNA.

• • Applicant table

                     For Job i.e. HRP1001-SOBID = "Project Financial Controller", Compare TCJ04 table entry with Step-2 data.

                     If same Positions are found in both the tables, then update each Position text i.e. TCJ05-ASTNA.

• Delete- Inactive Position

                    Inactive Positions found in step-1 & 2 should be deleted from TCJ04 & TCJ05 tables if exist.

                 Note: SAP has provided Blocked option in both TCJ04 & TCJ05 tables, how to use it? SAP incident raised.

Volumetrics

N/A

Performance Considerations

N/A

Error Handling

Monitoring and tracking of batch job (success or failure) and the ability to retrigger the batch job if needed.

Failed Batch jobs must be identifiable with exact reason of failure.

1. If one Position has multiple Jobs i.e. "Person Responsible- Project" and/or "Person Responsible- WBS" and "Project Financial Controller", show error that "Position "00000" with multiple Jobs "Job 1" and "Job 2" and "Job 3""

Testing

How to Test

Some HR Positions are required which are assigned to respective Job. 

Test Conditions and Expected Results

Test Considerations/Dependencies

• The H2R team to allocate 10 positions to support the execution of the various tests outlined above.

Other Information

N/A

Development Details

Package

Enhancement Implementation

Other Development Objects

Appendix

Custom Authorization Group Naming Convention

This table is based on the Syensqo development standards document. It provides the naming conventions for authorization groups to associated with custom reports and tables to comply with security requirements.

See also

Insert links and references to other documents which are relevant when trying to understand this decision and its implications. Other decisions are often impacted, so it's good to list them here with links. Attachments are also possible but dangerous as they are static documents and not updated by their authors.

Change log