| Status | Approved |
|---|---|
| Owner | BIDALIA-ext, Kuldeep |
| Stakeholders | |
| Jira Request ID | ERP-167 - Getting issue details... STATUS |
| Jira Development ID | ERP-512 - Getting issue details... STATUS |
High- Level Specification
| Parameter | Value |
|---|---|
| Application System | S/4Hana ROW, S/4Hana China, S/4Hana CUI |
| Business Process Reference | 10.02.01.01. Manage Project/WBS Changes 10.01.03.01. Manage Initiatives and Items |
Functional Overview
In the standard SAP S/4HANA system, named users are typically assigned to the "Person Responsible No." and "Applicant No." fields within both the Project Definition and Work Breakdown Structure (WBS) elements of a project. These assignments are used to track accountability and facilitate project-related notifications & workflows.
However, under the I2M proposed solution, this approach is being redefined. Instead of linking these fields to individual named users, the system will utilize Role based HR position. This means-
- HR positions assigned to specific roles, rather than specific named user, will be designated as the responsible entities at the Project Definition and WBS levels.
- This enables a role-based project system, allowing for greater flexibility and scalability in project governance.
- It supports organizational continuity, as responsibilities are tied to HR Position rather than individuals—reducing the need for manual updates when personnel changes occur.
- Enhanced search help will be enabled for "Person Responsible No." and "Applicant No." fields.
Scope and Objectives
Scope- This enhancement defines a scheduled SAP batch job that extracts HR positions based on their role relationships and updates-
- Person Responsible No. Table: Populated with positions linked to Security Roles ‘Person Responsible - Project’, ‘Person Responsible - WBS’
- Applicant No. Table: Populated with positions linked to Security Role ‘Project Financial Controller’.
- Enhance Search Help: Enhance the search help tab to find Position based on Position Name, Personnel ID, Personnel name etc.
Objective- The key objective are to improve data accuracy and timeliness in project and financial role assignments and reduce manual intervention in HR-Role mapping updates.
N/A
Process steps are-
Step | Description | Comment |
|---|---|---|
| 1 | Create a HR Position | Create a HR Position and assign organizational units and necessary information. |
| 2 | Assign Security Role | Assign Security Role e.g. ‘Person Responsible - Project’ OR ‘Person Responsible - WBS’ OR 'Project Financial Controller' to newly created Position |
| 3 | Execute Batch Job manually | Based upon the Security Role assigned to the Position Person Responsible No. or Applicant No. table will be appended as-
|
| 4 | Check Positions available in Project Definition and WBS elements | Open a project and select project definition/ WBS element- If Security Role ‘Person Responsible - Project’ OR ‘Person Responsible - WBS’ is assigned to the Position then search the Position in the Person Responsible No. field. If Security Role ‘Project Financial Controller’ is assigned to the Position then search the Position in the Applicant No. field. |
| 5 | Check Positions available in the PPM Item | Open an PPM Item- If Security Role ‘Person Responsible - Project’ OR ‘Person Responsible - WBS’ is assigned to the Position then search the Position in the Person Responsible field. If Security Role ‘Project Financial Controller’ is assigned to the Position then search the Position in the Project Financial Controller field. |
DELETE-
Internal testing, TCode PO13, Position 50000038, Infotype Communication B 007
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 available.
- Role-to-position relationships are maintained in standard HR Infotype.
- Given that HR position is Tier-1 master data, it will be replicated across all instances along with its associated infotypes.
Dependencies
- HR master data must be up to date i.e. applicable Security Roles must be assigned to project management specific Position.
- Table structures for Person Responsible No. and Applicant No. must allow maintenance via Batch Job without creating Transport Request.
Security, Integrity and Controls
- Authorization Checks: Batch job runs under a technical user with restricted write access to Person Responsible No. and Applicant No. tables.
- Data Validation: Security Role and position IDs are validated before update.
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 are available for the project governance. First, the system must extract HR positions from standard infotypes by evaluating their relationship to predefined Security Roles i.e. "Person Responsible- Project", "Person Responsible- WBS" and Project Financial Controller.
Once extracted, the batch logic must filter positions based on their role mapping: positions linked to "Person Responsible- Project", "Person Responsible- WBS" roles must be inserted or updated in the Person Responsible table, while those linked to the Project Financial Controller 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
| Table | Field Name | Comments/Calculation/Field Manipulation |
|---|---|---|
Data Validation Considerations
N/A
| Table | Field Name | Comments/Calculation/Field Manipulation |
|---|---|---|
Custom Tables
N/A
Master Data
N/A
| Field | Description | Data Type/Length | Validation rule/ Value Help |
|---|---|---|---|
Configuration Table
N/A
| Field | Description | Data Type/Length | Validation rule/ Value Help |
|---|---|---|---|
Selection Screen Enhancement
N/A
| Field Name | Description | Select: | Data Type/Length | Default Value/ Validation rule/ Value Help | Selection Logic |
|---|---|---|---|---|---|
Processing Logic
This enhancement is initiated through a daily batch job to ensure that Security Role based positions are consistently maintained within the OPS6 and OPS7 transactions, sequence is-
- Identify Person Responsible Positions
Pick all active Positions based on Security Roles i.e. HRP1001-SOBID = "Person Responsible- Project" or "Person Responsible- WBS" where
- Object Type = S (Position)
- Relationship type/relationship = B and Relationship object= 007
- Position with future end date are Active Positions, Positions with past End Dates are Inactive Positions.
- Infotype = 1001, Subtype B007
- Type of related object = AG i.e. Role
- Retrieve the latest position description from HRP1001 using the end date logic.
- If a Position is found having both the roles then continue with single record with role "Person Responsible- Project".
- Identify Applicant Positions
Pick all active Positions based on Security Roles i.e. HRP1001-SOBID = "Project Financial Controller" where
- Object Type = S (Position)
- Relationship type/relationship = B and Relationship object= 007
- Positions with future end date are Active Positions, Positions with past End Dates are Inactive Positions.
- Infotype = 1001, Subtype B007
- Type of related object = AG i.e. Role
- Retrieve the latest position description from HRP1001 using the end date logic.
3. Select action-
- Create
- Person Responsible table
For Security Roles 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 Security Roles 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 Security Roles 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 Security Roles 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 ticket raised.
Volumetrics
N/A
Performance Considerations
N/A
Error Handling
Monitoring and tracking of all budget overrun events should enable notification status checks (success or failure) and the ability to resend notifications if needed.
Failed Batch jobs must be identifiable with exact reason of failure.
- If one Position has multiple roles i.e. "Person Responsible- Project" and/or "Person Responsible- WBS" and "Project Financial Controller", show error that "Position "00000" with wrong Security Roles "Role
1" and "Role 2" and "Role 3""
Testing
How to Test
Some HR Positions are required which are assigned to respective Security Role/s.
Test Conditions and Expected Results
| ID | Condition | Expected Result |
|---|---|---|
| 1 | ||
Test Considerations/Dependencies
Other Information
Development Details
Package
| Package Name | Parent Package |
|---|---|
Enhancement Implementation
| Enhancement Type | Standard Definition Name | Custom Implementation Name | Design Rationale Reference |
|---|---|---|---|
Other Development Objects
| Object Type | Object Name | Purpose/High Level Logic | Design Rationale Reference |
|---|---|---|---|
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.
ABAP | ZFI | ZMM | ZPS | ZCO | ZSD | ZBC | ZFI | ZCA |
|---|---|---|---|---|---|---|---|---|
| TABLES | ZFIT | ZMMT | ZPST | ZCOT | ZSDT | ZBCT | ZFIT | ZCAT |