| Status | Approved |
|---|---|
| Owner | FRUTEAU-ext, Sabrina |
| Stakeholders | |
| Jira Request ID | ERP-896 - Getting issue details... STATUS |
| Jira Development ID | ERP-1365 - Getting issue details... STATUS |
High- Level Specification
| Parameter | Value |
|---|---|
| Application System | S/4HANA - China instance SAP S/4HANA - Rest of World instance |
| Business Process Reference | 10.02.02.02. Manage Project Budget and Forecasts |
Functional Overview
Project budget is approved through the Stage Gate Approval and Variation Approval workflows. After approval, the budget is automatically assigned to the PS project, at level 1 (L1) WBS element as the overall project budget. Users can re distribute the budget over the different level 2 WBS elements created underneath the L1. However, users should not be able to modify in PS the total amount of total budget at L1.
Scope and Objectives
The purpose of this enhancement is to prevent any manual change of the approved overall project budget at L1, while still allowing budget distribution and transfers below L1 (L2, L3, L4).
The Fiori app Edit Original Budget is used to re distribute the budget. The approved budget on the PPM item is transferred to the PS project and is available at L1 WBS element. The same budget can be re distributed throughout the lower WBS elements with the app.
The standard application allows the user to edit the budget assigned at the L1. This goes against our approval process. This custom development will ensure the approved budget baseline cannot be altered outside the governance workflows. This is an authorization enhancement to grey out the L1 budget field and prevent any direct and indirect modifications to the L1 budget through the app’s Total-Up and Copy functions.
The user will still be able to display the budget on L1 and distribute it across the lower levels.
The authorization restriction will apply to all PS projects, regardless of whether they are linked to a PPM Item. Since budgets are not managed for PS projects that are not associated with a PPM Item, this change will not cause any issues.
Step | Description | Comment |
|---|---|---|
| 1 | The user enters financial data in the SG Funding Request view for a specific PPM item within the PPM application. | This step initiates a budget request for a project. |
| 2 | The user submits the stage gate for approval in the PPM application, which starts an approval workflow involving multiple stakeholders. | This ensures that all relevant parties review the funding request. |
| 3 | Because the stage gate approval includes a funding request, the Delegation of Authority (DOA) approver is included in the approval process. | The DOA approver is responsible for authorizing budget allocations. |
| 4 | Once approved, the SG Funding Request is transferred to the Approved Budget financial view in PPM. | The Approved Budget view displays the total budget authorized for the project. Users can request additional funds via the stage gate or through a variation process. |
| 5 | After full stage gate approval, the Approved Budget is transferred from the PPM item to the Level 1 (L1) of the PS project. | This step ensures the approved budget is reflected in the project’s SAP structure. |
| 6 | Based on the project’s type and complexity, the budget may be further allocated to lower-level WBS elements using the Edit Original Budget app. | Budget distribution across WBS elements is allowed, but the total assigned to L1 must remain unchanged. A standard control ensures that the sum of distributed budgets does not exceed the L1 allocation. |
| 7 | Users are not permitted to modify the budget at L1. To request additional funds, a variation or a new stage gate approval must be initiated. | This maintains budget control and ensures all increases follow the proper approval process. |
Assumptions
Dependencies
Security, Integrity and Controls
Configuration Requirements
Language Requirements
Special Requirements
Design Rationale
Functional Requirements
Proposed Technology to Use
Data Source Considerations
| Table | Field Name | Comments/Calculation/Field Manipulation |
|---|---|---|
Data Validation Considerations
| Table | Field Name | Comments/Calculation/Field Manipulation |
|---|---|---|
Custom Tables
Master Data
| Field | Description | Data Type/Length | Validation rule/ Value Help |
|---|---|---|---|
Configuration Table
| Field | Description | Data Type/Length | Validation rule/ Value Help |
|---|---|---|---|
Selection Screen Enhancement
| Field Name | Description | Select: | Data Type/Length | Default Value/ Validation rule/ Value Help | Selection Logic |
|---|---|---|---|---|---|
Processing Logic
Volumetrics
Performance Considerations
Error Handling
Testing
How to Test
Test Conditions and Expected Results
| ID | Condition | Expected Result |
|---|---|---|
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 |