ERP-1045 - Datasphere foundation build for S/4 - S2S FS in Progress
The DDFS covers the end to end datasphere data flows for S2S area. The sub area it covers include EHS - Environment, Health & Safety , PRC - Product Compliance, SCT - Sustainability Control Tower and SFM - Sustainability Footprint Management. Below are the details on each sub area and KPIS it will cover:
| Sub-Area | Details | KPIs | Comments |
|---|---|---|---|
| EHS - Environment, Health & Safety | The SAP EHS (Environment, Health and Safety) module is designed to help organizations capture, analyse and communicate safety, environmental and compliance data in a structured way. At its core, SAP EHS reporting consolidates data from different subcomponents like incident management, occupational health, product safety, and environmental compliance into meaningful outputs for both operational and regulatory use. | Emissions, waste, and resource usage (air, water, energy), tracking workplace incidents, near misses, injuries, and illnesses | |
| PRC - Product Compliance | The SAP Product Compliance (PRC) is part of SAP’s EHS and product stewardship portfolio. From a reporting perspective, its main role is to ensure companies can track, document, and report regulatory compliance data for products across global markets. It is created as a separate sub-module in datasphere considering the authorisation rules to only provide a sub-user group access to this data. | Compliance reporting, SVT, SVHC, Substance & Composition Reporting | |
| SCT -Sustainability Control Tower | SAP Sustainability Control Tower (SCT) is designed to centralize, standardize, and automate ESG (Environmental, Social, Governance) data reporting across an organization. It enables automated, compliant and audit-ready sustainability reporting. SCT relies on SAP datasphere for data foundation and scalability. SAP Datasphere acts as the data layer beneath SCT. It integrates data from various SAP and non-SAP sources, models and harmonizes this data before it reaches SCT. This integration happens via SAP supplied DPI (Data Provisioning & Integration). | Emissions, Energy, Water Management, Waste, Social KPIs, Carbon Credits, Financial KPIs | |
| SFM - Sustainability Footprint Management. | SAP Sustainability Footprint Management (SFM) is a cloud-based solution designed to calculate, analyse, and report product and corporate level carbon footprints. From a reporting perspective, its value lies in turning complex emissions data into structured, auditable and decision ready outputs. Datasphere will be used to send some of the already consolidated data (like waste) and also to extract the footprint data to be used in reporting. | Product Carbon Footprints (PCF) per product and supplier |
The models covered under this DDFS will cater towards requirements from the following Jira Requests -
Standard extractors do not need to be documented unless extended.
Where custom extractors / extensions are required, reference the FSD for that enhancement.
| Extractor Name | Build Jira Ref For Extension Information |
|---|---|
Inbound layer objects only need documentation if some field adjustment is made (over and above the standard load date / time and source system stamp).
Field XYZ converted to date.
Field ABC converted from BIGINT to...
Every table will have it's own harmonization view. This only needs to be documented if field adjustments are required. E.g. Conversion of data field / type.
Where actions are performed to improve reusability, e.g. joining header and item tables, details of the join (left outer, which is left, which is right, fields to join with, cardinality etc) should listed.
Each node inside the view will appear as a heading 3 in this document detailing what it does and, if not obvious, why.
Calculated dimension CD_PLANT to change length of field 'Plant' from 4 to 5 to align with WHM plant. (Ubiquitously true, reusable change made at lowest level possible).
Calculated measure: CM_PRICE = Value / Quantity. (Ubiquitously true, reusable change made at lowest level possible).
Purpose: Join PO header and item to create reusable view at item level that contains all fields from PO header
LHS: 2VR_S4H_C_PurchaseOrderDex
RHS: 2VR_S4H_C_PurchaseOrderItemDex
Join Field: POHeader to POHeader
Join type: Left outer join
Cardinality: 1: Many
Remove fields that occur in both PO Header and Item views leaving fields from PO Header side.
A line item level calculation which applies specific business rules that are owned by the POD would be added here.
Purpose: etc
Purpose: etc
Purpose: etc
Calculated measure: CM_DocItemValue = DocQuantity * CM_PRICE
Purpose: To bring in values from PO level alongside lower level granularity documents
| Target Field | Source1-Field | Source2-Field |
|---|---|---|
| PO | PO | PO |
| POItem | POItem | POItem |
| MaterialDocument | - | MaterialDocument |
List objects where material master associations are to be made.
Link to FSD (Each Analytic model should have its own FSD).
Include technical details for:
Detail restrictions
Detail rate type, from currency