SAP PM - Phased-Based Process Part 2 Plan, Approve, and Prepare

 

CLICK here to view the Presentation

SAP PP - REM Planning Table for Non Repetitive Manufacturing Material

CLICK here to view Presentation

Q&A in Class (2025-07-18) S4120

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Questions: How to we know which Project Profile to use when creating a Project ?

Answer: To determine the appropriate Project Profile in SAP when creating a project, consider the project's nature, organizational requirements, and the desired functionality. Project profiles act as templates, predefining key settings for dates, costs, and other aspects, streamlining the project creation process. Choosing the correct profile ensures consistency and efficiency throughout the project lifecycle. The project profile serves as a blueprint for your project in SAP, predefining key settings and configurations based on the project's nature and organizational requirements. By carefully selecting the appropriate profile, you can ensure a smooth and efficient project setup and execution. 

Here's a breakdown of factors to consider:
1. Project Type and Nature:

Investment Projects: If the project involves creating or upgrading fixed assets (like buildings or machinery), select a profile that supports investment management, asset creation, and cost settlement to assets under construction (AuC).
Internal Projects: For internal projects like process optimization or product development, choose a profile that aligns with internal cost accounting and resource management.
External Projects: If the project is related to external contracts or customer projects, select a profile that integrates with sales and distribution, billing, and revenue recognition.
Development Projects: If the project involves development, use a profile that allows for versioning, change management, and testing.

2. Organizational Requirements:

Controlling Area: Ensure the profile aligns with the controlling area relevant for cost and revenue accounting.
Company Code: Select a profile compatible with the relevant company code for financial reporting.
Functional Area: Consider the functional area to which the project belongs for reporting and analysis.
Currency: Make sure the project currency is consistent with the organization's policies and the project's financial requirements.

3. Functional Needs:

Planning Profile: If cost planning and scheduling are required, link the profile to appropriate planning profiles.
Graphic Profile: If you need graphical representations of project progress, ensure the profile allows for the use of graphic profiles.
Version Profile: If project versions are needed, select a profile that supports versioning and data transfer between versions.
Information System Profile:
If you need to analyze project data, ensure the profile is compatible with the desired information system.

4. Streamlining Project Creation:

Default Settings: The project profile should contain default settings for key fields, such as project ID structure (coding mask), responsible organizational unit, and default dates.
Consistency: A well-defined project profile promotes consistency across all projects of a similar type.
Efficiency: Using a project profile minimizes the need to manually enter data for each new project.

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Questions: Why is there a Network Header ?

Answer: In SAP Project System, a Network Header acts as a central control point for a network, which represents the flow of activities within a project. It holds default organizational and control data that applies to all activities within that network, similar to how a project definition does for WBS elements. This simplifies management by allowing you to define settings once at the header level and have them applied to the entire network. 

Reasons for the Network Header: 

Default Settings: The network header provides a place to define default values for the entire network, such as organizational assignments (company code, plant), control indicators (scheduling parameters), and basic start/finish dates. 

Centralized Management: Instead of maintaining these settings individually for each activity, you can manage them at the network header level, making it easier to ensure consistency and efficiency. 

Integration Points: The network header can be linked to a Work Breakdown Structure (WBS) element or a sales order, providing a structured way to integrate the network with other project management objects. 

Scheduling: The network header's scheduling indicators (forward/backward) determine how the network's activities are scheduled. 

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Questions: Why doo we need to enter Planned Revenues for the Project despite having a Billing Plan with Revenue figures in the Sales Order ?

Answer: In SAP Project System (PS), Planned Revenues represent the expected income from a project, while billing plan revenue refers to the specific revenue amounts and dates defined within a billing plan, typically associated with a sales order or WBS element. SAP PS offers various methods to manage and plan revenues, including manual planning, integration with sales documents, and the use of billing 
plans.

Notes:
1. Planned Revenues:

Definition: This refers to the projected revenue that a project is expected to generate.

Methods in SAP PS: Manual Revenue Planning: Allows for direct input of planned revenue values for WBS elements.

Automatic Update from Sales Documents: If a sales document (like a sales order) is linked to a WBS element, the planned revenue can be automatically updated based on the sales document's pricing and billing plan.

Revenue Planning with Billing Plans: Billing plans define a schedule of billing dates and associated revenue amounts for a project or sales order item, impacting the overall planned revenue.

2. Billing Plan Revenue:

Definition: This is the revenue specifically defined within a billing plan.

Functionality: Billing plans are used to structure invoicing schedules, breaking down the total project revenue into specific billing dates and amounts.

• They can be created at the WBS element level or within sales documents, and they determine when payment requests or invoices are sent to the customer.

• The system records the planned revenue based on the billing plan in the relevant WBS element and commitment item.

• Relationship with Planned Revenue: If a billing plan is used in conjunction with a sales order and WBS element, the system may combine the planned revenues from both sources, or it may prioritize one source over the other.

Revenues planned via the Billing Plan in the Sales Order can be displayed in this report
S_ALR_87013565
See the following Blog Posts:

https://froggysap.blogspot.com/2015/02/plan-revenue-to-project-via-sales-order.html

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Questions: When scheduling the Project, does the system use the Work Center work hours or the Durations ?

Answer: In SAP Project System (PS), Work represents the planned effort (usually in hours or other units) required to complete an activity, while Duration is the length of time an activity is scheduled to take. They are interconnected, as the duration is often calculated based on the work and the capacity (number of resources) assigned to the activity. 

Notes:

Work:

Represents the amount of effort needed to complete an activity. 

Typically expressed in work units (e.g., hours, man-hours). 

Can be assigned to internal activities (performed by internal resources) or external activities (performed by external vendors). 

Duration:

Indicates the length of time an activity is scheduled to last. 

Calculated based on the planned work, work center capacity, and available working hours. 

For example, if an activity requires 10 hours of work and the work center has a capacity of 2 people, the duration might be 5 hours if both work at the same time. 

Relationship:

SAP PS allows you to calculate duration based on the work and work center capacity. 

You can specify a calculation key in the system settings to automatically calculate the duration based on the entered work and work center details. 

If you change the work or capacity, the duration will be recalculated accordingly. 

See the following Blog Posts:

https://froggysap.blogspot.com/2016/09/project-system-create-network.html

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Questions: What are the purpose of the Network Control Keys ?

Answer: In SAP Project System (PS), Network Activities are individual tasks or steps within a project that define the work to be done and how it relates to other tasks. They are fundamental components used to plan, execute, and monitor project progress, resources, and costs. Networks, composed of these activities and their relationships, represent the project's workflow.

Some note: 

Definition: Network activities are the specific tasks or steps within a project that need to be completed to achieve project goals. 

Purpose: They serve as the building blocks for project planning and execution, allowing for detailed scheduling, resource allocation, and cost tracking

Types: Internal, External Activities, and Costs

Internal Processing: ZPS1 (or PS01) for Activities done by Internal Work Centers (Technicians)

External Processing; ZPS2 (or PS02) for Work by 3rd Party via PR - PO - GR - Invoice

Cost: ZPS4 (or PS04) for Cost Planning

Service: ZPS5 (or PS05) for Work by 3rd Party via PR - PO - SES - Approval - Invoice

Control Key are user-defined (the above are the standard provided by SAP)

Relationships: Activities are linked together using relationships, which define the sequence and dependencies between them, forming the project's network structure. 

Key Features:

• Network activities enable features like: Scheduling: Determining planned dates for activities based on their duration and dependencies. 

• Resource Planning: Assigning resources (personnel, materials, etc.) to activities. 

Cost Planning and Tracking: Calculating and monitoring costs associated with each activity. 

• Progress Monitoring: Tracking the completion status of activities and the overall project progress. 

• Procurement: Facilitating the procurement of materials or services required for specific activities. 

See the following Blot Post:

https://froggysap.blogspot.com/2016/12/create-project-structure-using-project.html

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Questions: How do we schedule a Project with Network ?

Answer: To schedule a project in SAP, you'll primarily use the Project Builder (transaction CJ20N) and the Project Planning Board (accessed through CJ20N). The process involves defining the project's structure (using WBS elements), scheduling activities within that structure, and managing dates using the planning board. 
See the following Blog Posts:

https://froggysap.blogspot.com/2016/12/perform-scheduling-of-network-and.html

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Questions: When a Project is rescheduled, can the Billing Plan dates generated earlier in the Sales Order also rescheduled according to new Milestone dates ?

Answer: Yes, Billing Plan dates in SAP can be rescheduled based on the latest SAP PS (Project System) milestone dates. This is achieved by linking the milestones in the project to the billing plan dates within the sales document. When the milestone dates in the project are adjusted, the corresponding billing plan dates in the sales document can be automatically updated to reflect the new schedule. 

Important considerations:

1. Linking Milestones to Billing Plan Dates:

• In SAP PS, milestones are defined within a network and are associated with planned and actual dates for the completion of work.
• These milestones can be linked to the billing plan dates within a sales document.

When the billing plan is created, it can be configured to either copy milestone dates from the network or to manually assign milestones to specific billing dates.

• When a milestone is confirmed (i.e., marked as complete), it can trigger the removal of a billing block and allow for the execution of the billing plan.

2. Automatic Rescheduling:

• When a milestone date in the project is changed, the linked billing plan date in the sales document can be automatically updated to reflect the new date.

• This automatic rescheduling ensures that the billing plan remains aligned with the project's schedule.

3. Important Considerations:

• Milestone Confirmation: Billing plan dates tied to milestones are typically blocked until the milestone is confirmed as completed.

See the following Blog Posts:

https://docs.google.com/Milestone Billing Plan without PS Network/
https://docs.google.com/Milestone Billing Plan with PS Network/

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Q&A in Class (2025-07-17) EWM130

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Questions: Why do consultants recommended "Embedded EWM" over "Distributed EWM" ?

Answer: 

First, the definitions: 

Decentralized SAP EWM (Extended Warehouse Management)

• SAP EWM was initially released in 2005 as a separate system for intralogistics, distinct from the SAP WM (Warehouse Management) module.

• As a separate solution, the Decentralized SAP EWM (Extended Warehouse Management) was introduced alongside SAP ERP ECC 6.0. This means it was available as a standalone system alongside the ERP system, rather than being integrated directly within it. This approach was marketed at the time (20 years ago) as the approach would allowed for better performance and scalability, especially for complex warehouses. 
• is a separate, independent system that manages warehouse operations, distinct from the main SAP ERP or S/4HANA system.
• It communicates with the ERP system through interfaces like RFC or IDocs, enabling a high degree of flexibility and customization for complex warehouse scenarios.

Advantages of Decentralized SAP EWM

• Flexibility and Scalability: Handles complex warehouse structures and high transaction volumes, making it suitable for large, automated warehouses. 

• Integration with Multiple ERP Systems: Connects to various SAP and non-SAP ERP systems, offering a unified view of warehouse operations across different systems. 

• Independent Operation: EWM functions independently of the ERP system, allowing it to continue operating even if the ERP system is down for maintenance or upgrades. 

Disadvantages of Decentralized SAP EWM

• Higher Costs: Requires separate infrastructure, licenses, and maintenance, leading to a higher total cost of ownership compared to embedded EWM. 

• Increased Complexity: Requires separate system administration, data replication, and integration efforts, increasing complexity. 

• Data Replication: Requires robust data replication mechanisms (IDoc, ALE, or DRF) to synchronize data between the ERP and EWM systems. 

Maintenance Overhead:

• Maintenance Overhead: Requires separate maintenance for the EWM system, including updates, patches, and performance monitoring. 

• Potential for Performance Issues: Requires careful monitoring and optimization to prevent performance bottlenecks, especially in high-volume scenarios. 

 

Embedded S/4HANA SAP EWM (Extended Warehouse Management)

• SAP Embedded SAP EWM (Extended Warehouse Management) was introduced with the release of SAP S/4HANA, specifically in the Q4/2016 release, version 1610

• This embedded version brought the EWM functionality directly into the S/4HANA core, eliminating the need for a separate, decentralized EWM system in many cases.

• S/4HANA offers both basic and advanced versions of Embedded EWM, with the basic version included with the S/4HANA license and advanced features available through an additional license.

• Embedded EWM provides functionalities for not just inbound and outbound processing, storage and operations, physical inventory, but also advanced features like value-added-service, kit-to-stock management, yard management, and more.

Advantages of Decentralized Embedded EWM

• Lower Costs: Embedded EWM eliminates the need for separate hardware, software, and integration efforts, resulting in lower overall costs. 

• Simplified System Landscape: A single S/4HANA system reduces complexity and simplifies data management. 

• Seamless Integration: Embedded EWM leverages the same data structures and business processes as S/4HANA, leading to better data consistency and reduced integration challenges. 

• Faster Implementation: The integration with S/4HANA speeds up the implementation process. 

• Reduced Complexity: For organizations with less complex warehouse needs, embedded EWM simplifies warehouse operations

Disadvantages of Decentralized Embedded EWM

• Functionality Limitations: Embedded EWM may not offer the full range of advanced features and customization options available in the decentralized version, particularly for highly specialized or high-volume warehouse operations.

• Potential Performance Bottlenecks: In high-volume scenarios, the embedded EWM might face performance limitations due to its integration with the core S/4HANA system.

• Scalability Issues: For large and complex warehouse networks, embedded EWM might not be as scalable as the decentralized version.

Conclusions: The key difference between decentralized and embedded Extended Warehouse Management (EWM) in SAP S/4HANA lies in their integration and deployment. Decentralized EWM is a separate system, while embedded EWM is integrated directly within the S/4HANA system. The choice depends on factors like warehouse complexity, automation level, and integration needs which can be summarized as below:

• Decentralized EWM is better suited for organizations with large, complex, and potentially growing warehouse operations that require high flexibility and customization.

• Separate system: A distinct system landscape with its own database and application server.

• Flexibility and scalability: Suitable for complex, high-volume warehouses with high automation and multiple ERP connections.

• Independent operation: Can operate even if the ERP system is down.

• Higher complexity: Requires more effort for initial setup and ongoing integration.

• Performance benefits: Can handle high transaction volumes and complex processes.

• Embedded EWM is a good choice for companies with less complex warehouse networks and a focus on seamless integration with S/4HANA.

• Integrated within S/4HANA: Part of the core ERP system, simplifying integration with other modules.Simplified landscape: Reduces IT overhead by eliminating the need for a separate system.

• Real-time data: Uses direct updates for faster data processing.

• Suitable for: Smaller to mid-sized warehouses with simpler processes and less automation.

• Cost-effective: Basic EWM features are included in the standard S/4HANA license.

Factors to consider when choosing: 

• Warehouse size and complexity: Larger, more automated warehouses often benefit from decentralized EWM.
• Integration requirements: Embedded EWM offers seamless integration with other SAP modules. Embedded EWM (Extended Warehouse Management) in SAP S/4HANA is generally considered better than decentralized EWM for many scenarios due to its tighter integration, reduced complexity, and lower total cost of ownership.
• Performance needs: Decentralized EWM is better suited for high-volume, high-transaction environments.
• IT infrastructure and resources: Embedded EWM requires less infrastructure and maintenance.
• Future growth and scalability: Decentralized EWM provides more flexibility for future expansion. 

Useful Reference Resources:

https://youtu.be/Embedded or Decentralized SAP EWM? That's the question!/

https://www.youtube.com/Hallmark Cards UK EWM Deployment/

https://westernacher.com/EWM-integration-with-s4hana/

https://www.ssi-schaefer.com/en-asia/newsroom/company-blog/Sap-the-future-looks-Embedded/

https://www.kagool.com/warehouse-management-deployment-in-s-4-hana

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Questions: New Storage Location (with EWM integration) configuration requirement demonstration.

Answer: Here is a Blog Posts on how to setup a new EWM relevant MM Storage Location for Production Supply to the Shop Floor. The new Storage Locaiton is "PS20" in Plant "SPCW" to be activated for EWM Warehouse "E120":

See the following Blog Post: 

https://froggysap.blogspot.com/2025/07/blog-post_19.html

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Questions: The choice between "Delivery-based" production supply vs "Production material request" production supply?

Answer: The choice between delivery-based and Production Material Request (PMR) based production supply in SAP EWM (Extended Warehouse Management) depends on specific production processes and requirements. PMR-based staging is suitable for advanced production integration, offering features like independent operation from the ERP system and the ability to organize staging within the warehouse. 

Delivery-based staging, on the other hand, is best for scenarios needing exact quantities staged at specific times, especially when space is limited or staging spans a longer period.

PMR-based Production Supply (Advanced Production Integration): 

Pros: 

Independent Operation: Allows for independent operation from the ERP system after PMR creation. 

Enhanced Warehouse Management: Enables organizing staging for production using warehouse management capabilities. 

Quantity Flexibility: Can split large component quantities into smaller, manageable units for the Production Supply Area (PSA). 

Reduced System Load: Sends only goods movements instead of full deliveries, reducing system strain. 

Advanced Search: Features advanced search and retrieval capabilities for process documents. 

Cons: 

Complexity: Can be more complex to set up and manage compared to delivery-based. 

Integration Challenges: May not fully support all advanced production processes like JIT kanban and repetitive manufacturing at the version simulated of of today. 

Potential for Over-staging: If not configured correctly, might stage more material than needed initially, especially for processes with variable consumption. 

Not Ideal for All Processes: May not be the best fit for all production scenarios, particularly those requiring precise, real-time staging. 

Delivery-based Production Supply:

Pros:

Precise Quantity Staging: Best for staging exact quantities at specific times. 

Suitable for Limited Space: Ideal when space in the production area is limited, allowing for staged quantities to be delivered as needed. 

Efficient for Longer Staging Times: Well-suited for processes where staging and consumption occur over a longer duration. 

Simplified Setup: Generally simpler to implement and manage compared to PMR-based. 

Cons: 

Less Flexibility: Less flexible in terms of quantity adjustments during staging. 

Potential for Errors: Might lead to errors if consumption quantities deviate significantly from planned ones. 

Not Ideal for All Production Types: May not be suitable for all production processes, especially those requiring frequent adjustments or real-time adjustments. 

Limited Integration: May not fully integrate with all advanced production processes. 

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Question: Is this possible to block the transfer from one Storage Type to another Storage Type in the classic LE-WM ?

Answer: First of all, Storage Types cannot be mapped to MM Storage Location in LE-WM (However, there is one such possibility to mapped GR-Area Storage Type to the same in MM-SLoc fro GR-Area but this is for MM Goods receipt for Purchase Order scenario). 

In this Question, it is about internal transfer in LE-WM from Bin of One Storage Type to bin that belong to another Storage Type AND the user assume the Storage Types are physically belong to different Storage Type in the Warehouse. The User's question is about is it possible to stop a user from performing this task. 

• To manually transfer stock between different storage types within a warehouse using a transfer order (TO) in SAP WM, you'll use transaction code LT01. This transaction allows you to create a transfer order that specifies the source and destination storage bins, even if they are in different storage types. 
• Step-by-step breakdown: 
• Access LT01: Enter transaction code LT01 in the SAP command field.
• Enter Warehouse Details: Specify the warehouse number, material, quantity, and the source and destination storage bins. Ensure you select the correct storage types for both source and destination.
• Manual Bin Specification: Crucially, you will manually enter the source and destination storage bin details. This is how you move stock between bins in different storage types.
• Create the Transfer Order: After entering all the necessary information, create the transfer order.
• Confirm the Transfer Order (LT12): Once the stock has been physically moved, confirm the transfer order using transaction code LT12.
• The LT01 transaction in SAP WM (Warehouse Management) is primarily designed for bin-to-bin transfers within a single storage location. It does not directly support transfers between storage types that "supposedly" belong to different storage locations, even if those locations are within the same warehouse. 

If the intention is to block user from entering a specific Storage Type in LT01, then consider the following User Exit:

• MWMRFDLV
• EXIT_SAPLLMOBSD_010

Or 

It is possible to implement Authorizations at the storage type level in SAP, specifically within Warehouse Management (WM). The Authorization Object L_LGNUM is used to control access based on Warehouse Number and Storage Type. When a user attempts to perform actions within a warehouse, the system checks for authorization against this object, verifying if the user has the necessary permissions for the specific storage type. 

In order to transfer from Storage Location to Storage Location, whether the 2 SLocs belong to the same or different LE-WM Warehouse, use MIGO. 

• It is then possible to setup Storage Location Authorization Object M_MSEG_LGO  if a user is not allow to process for that Storage Location. 

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Questions: "Delivery-based" Production Supply integration steps review.

Answer: There are two models for production integration available in SAP EWM: 

• Delivery-based model (where deliveries are sent as information from ERP to SAP EWM for requirements and goods issues) 

• Advanced production integration model (which does not use deliveries). 

Both models have specific features and the model used depends on the customer’s requirements.

Delivery-based production integration in systems like SAP EWM (Extended Warehouse Management) refers to a method where production orders are linked to outbound deliveries for material staging and consumption. This means that when a production order is released, an outbound delivery is created and replicated to EWM. This delivery then triggers the necessary warehouse tasks for material staging to the production supply area (PSA). 

Key aspects of delivery-based production integration:

Outbound Delivery as the Key: The outbound delivery acts as the central document that connects production orders and warehouse operations in EWM.

PSA Mapping: ERP PSA must be replicated to EWM as EWM PSA and Mapped together.

ERP Control Cycle determines the methods of Staging:

Staging Strategy "1" - Pick Part 

Staging Strategy "2" - Crate Part (not supported)

Staging Strategy "3" - Release Order Part

Staging Strategy "4" - Manual (this is select to use EWM method for Crate Part)

EWM Assign Bin to Product/Entitled in PSA (it's not really a Control Cycle): 

For Crate Part, assign EWM Bin + Minimum & Replenishment Quantities here

For Others with ERP Control Cycle Strategy "1" and "3", ony assign the EWM Bin here

See the following Blog Posts:

https://docs.google.com/Delivery-Based-Staging

https://docs.google.com/Deliery-Based-Backflush

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Questions: "Production Material Supply" Production Supply steps review.

Answer: In SAP Extended Warehouse Management (EWM), a Production Material Request (PMR) is a document that links production planning and EWM, facilitating the staging of materials for production orders (PPDI) or process orders (PPPI). It contains essential information like the product, quantity, production supply area, and staging date, enabling the system to move materials from storage to the production area. Essentially, the PMR acts as a bridge, connecting the production order in SAP ERP with the material staging and consumption processes in EWM. 

Purpose:

PMRs are created in EWM to manage the staging of materials for production orders. 

Data Source: 

The data required to create a PMR is transferred from SAP ERP to SAP EWM, typically via a qRFC (queued Remote Function Call). 

Key Information: 

A PMR includes details like the product being produced, the quantity of components needed, the production supply area (PSA), and the date for which material staging is planned. 

Material Staging: 

The PMR triggers the movement of materials from the warehouse to the production supply area, ensuring that the necessary components are available when needed for production. 

Advanced Production Integration:

PMRs are a core component of SAP EWM's advanced production integration, enabling efficient material staging and consumption for production. 

Staging Methods: 

PMRs can be used for different staging methods, such as single-order staging or cross-order staging. 

Real-time Integration: 

PMRs allow for real-time synchronization of material staging information between SAP ERP and SAP EWM, ensuring accurate inventory and efficient production. 

See the following Blog Posts:

https://docs.google.com/PMR-Based-Staging

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

SAP S/4EWM-ECC6 - Delivery-based Staging Part 1 Create new Storage Location fo Shop Floor Production Supply

 CLICK here to view the Presentation

SAP LES - HU Packed HU into Higher HU

CLICK here to view Presentation

Question no 4057 : Control Parameters for Production Orders

In SAP Production Planning & Execution as at S/4 1909, which of the following Parameters provides the following controls:

. BOM and Rouning selection

. Batch Determination Procedure

. Status Change Documentation

. Costing Variants for Planned and Actual Costs

(only one answer)

A)  Order Type Plant independent Parameter
B)  Order Type Plant dependent Parameter
C)  Confirmation Parameter.
D)  Production Scheduler Profile.
E)  Non of the above.
.

Answer: B

SAP PM - FIORI for Single Cycle Maintenance Plan

CLICK here to view Presentation

Question no 4056 : COGI in Production Orders

In SAP Production Planning & Distribution as at S/4 1909, which of the following settings will Post a Component to Post Processing record (COGI), when not enough stocks were found in the Staging Storage Location when Material was to be back-flushed during a Confirmation activity ?

I. Setup Negative Stock indicator in the Component Material Master Plant/Storage data view.

II. Setup the Plant and Storage Location in the configuration to allow Negative Stock posting.

III. Remove the "Goods Movement" Error handling indicator in the Confirmation Parameter for the Plant where the Production Order was created at.

IV. Select "COGI" indicator in the Confirmation Profile and assign the Parameter ID "AAT" to the User.

V. Set Message "M7021" as ERROR in the configuration.

(only one answer)

A) I, II, III

B) I, II, IV

C) I, II, III, V

D) IV

E) III

Answer: E

SAP PS - Assignment to WBS and Network Activity Level

CLICK here to view the Presentation

Q&A in Class (2025-07-05) S4120

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Question: Exercise#7 Project with Network End-to-End Class Exercise

Answer: See the following as Guide to the Exercise, the Configuration and Master Data is based on S/4HANA2023:
https://froggysap.blogspot.com/2025/06/blog-post_30.html

https://docs.google.com/document/Exercise#7 Steps/ (updated on July.05.2024)

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Question: How and which modules is/are used to calculate Commissions for Sales personnels so that these employees can be paid via HR Salary module for the Commissions earned.

Answer: In SAP, sales commissions for salary payments can be calculated using the Sales Commissions and Channel Commissions module, which is part of the Commission Management functionality. This involves defining remuneration models, calculating commissions based on sales data, and integrating the results with payroll for payment. SAP Incentive and Commission Management (ICM) is part of the SAP S/4HANA system, specifically within the broader Sales and Distribution (SD) and Financials modules. It is a dedicated module designed to manage and calculate sales commissions. 

SAP Incentive and Commission Management (ICM) is part of the Financials module, specifically within the SAP S/4HANA suite. It's also referred to as SAP FS-ICM (Financial Services Incentive and Commission Management). This module is designed to handle the complex process of calculating and managing variable compensation, including commissions, brokerage, profit sharing, and bonuses for employees and partners.

To access SAP Incentive and Commission Management information, you can use the SAP Easy Access screen or directly enter transaction codes. The main menu can be found under "Accounting → Incentive and Commission Management → Start Menu". Alternatively, you can use the transaction code CACS. For customizing, the path is "Accounting → Incentive and Commission Management → Administration → System Administration → Customizing" or use transaction code CACSIMG. 

Here's a more detailed breakdown:
1. Setting up Commission Management:

• Define Remuneration Models: Establish rules that determine how commissions are calculated. This includes specifying the activities that trigger commissions, the participants eligible for commission, and the valuation parameters (e.g., commission rates, sales targets).

• Commission Keys: Create commission keys to define specific commission rates or rules associated with particular products, customers, or sales representatives.
• Condition References: Set up condition references to determine the commission basis, such as sales revenue or quantities, and create condition records for direct entry in sales processing.

2. Calculating Sales Commissions:

• Process Incoming Transactions: SAP Commissions processes sales data to determine the commission amount for each recipient.
• Run Calculation: The system calculates commissions based on the defined remuneration models and commission keys.
• Review Results: The results are available for review by financial and marketing personnel, including commission details and accrual information.

3. Integrating with Payroll:

• Accrual Items: The commission details are saved as accrual items, which are then used to calculate the total commission amount for each sales representative.
• Payment Processing: The calculated commission amounts are integrated into the payroll system for inclusion in the salary payment process.

4. Key SAP Objects and Transactions:

• Commission Case: This business object processes the incoming transaction data to determine the remuneration due.
• Commission Management: This module provides tools for managing sales commissions and channel commissions.
• Pricing and Conditions: SAP's pricing and condition techniques are used to define and manage commission rates and rules.
• SAP Commissions (formerly SAP Sales Performance Management): This is a dedicated solution for incentive compensation management, providing features for creating, managing, and optimizing commission plans.

5. Example:

Let's say a salesperson sells a product for $100, and the commission rate is 5%. The commission calculation would be: $100 * 5% = $5. This $5 would then be added to the salesperson's salary payment.

By leveraging SAP's Commission Management and related tools, businesses can effectively calculate and manage sales commissions, ensuring accurate and timely payments to their sales teams, according to SAP resources.

SAP Offician references:
https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/Incentive and Commission Management/

https://help.sap.com/doc/ICM Incentive and Commission Management ECC 6.0 Release Notes/

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Question: How to assign DMS Document to the Project

Answer: SAP Document Management System (DMS) documents can be assigned to SAP Project System (PS) projects. Specifically, you can link document info records (DIRs) from SAP DMS to WBS elements and network activities within a PS project. This allows for the management and access of project-related documents directly within the project structure. 

See the following Blog Posts for steps to create a DMS document and subsequently assign the DMS document to a WBS in a Project: 
https://froggysap.blogspot.com/2025/07/blog-post_4.html

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Question: Review of the "Coding Mask" in the Project system. 

Answer: In SAP Project Systems, a coding mask is a template that defines the structure and format for project numbers and Work Breakdown Structure (WBS) element IDs. It dictates how these IDs are constructed, ensuring consistency and clarity in project identification. Coding masks utilize special characters like 'X' for alphanumeric values, '0' for numeric values, and separators (like '/') to define the structure. 

Key aspects of a coding mask:

• Structure and Format: The coding mask defines the overall structure of project numbers and WBS element IDs, including the number of characters and their arrangement. 

• Special Characters: 'X' represents alphanumeric characters (letters and numbers). 

'0' represents numerical characters. 

Special characters like '/' or '-' can be used as separators. 

• WBS Element Identification: The coding mask helps in identifying the position and level of WBS elements within the project structure. 

• Project Length and Structure Length: The coding mask can specify the length of the project ID and the structure length for WBS elements, ensuring consistent project numbering. 

Configuration: The coding mask is configured using: 

SPRO - PS - Structures - Operative Structures - WBS - Project Coding Mask

Transaction code OPSK - Special characters for Projects

Transaction code OPSJ - Define Project Coding Mask

• Maximum Length: A coding mask can be up to 24 characters long, including separators. 

• Example: A coding mask like "XXXX-000-XXX" could be used to represent a project with an alphanumeric project ID, followed by a numerical WBS element ID, and another alphanumeric section. 

• Consistency: Coding masks ensure that all projects are created with a consistent structure and format, which is crucial for reporting and analysis

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Question: What is the purpose of the "Calculation Key" in an Internal Activity screen for a Network Activity ?

Answer: The "Calculation Key" for Internal Actvity is to select which variable in the Internal Activty to be calculated, there are 4 variables in the formula:

For example, if the Calculation Key = "Calculate Duration"

then 

Duration in Days = Work / (Number of Capacity x Operating Time /Day) 

Duration in Days = 80 hours / (2 people x 10 hours per day) 

Duration in Days = 4 Days 

See the following Blog Posts for details:

https://froggysap.blogspot.com/2025/07/sap-ps-internal-activity-calculation-key.html

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Question: Between Project Definition, WBS, Network Header, Network Activity, which of the objects eg: Materials (Component), PS Text, Milestone, DMS Document can be assigned to what level of a Project ? 

Answer: Note the following assignable objects:

What can be assigned to a Project Definition:

• WBS 

• Network Header

What can be assigned to a WBS:

• Network Header

• Lower level WBS 

• PS Text(s)

• DMS Document(s)

• Milestone(s)

What can be assigned to a Network Header: 

• Network Activities. 

What can be assigned to a Network Activity: 

• PS Text(s)

• DMS Document(s)

• Milestone(s)

• Material Component(s)

See the following Blog Posts for how Milestones, DMS Document, PS Text, Material Components can be assigned to levels of a Project:

https://froggysap.blogspot.com/2025/07/blog-post_5.html

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------