Document Links

Introduction

This Data Flow Specification (DFS) defines the end-to-end data flow required to meet the following requirements:

• Total stock balances (value and quantity) by Posting Date for every Material/Plant/Storage Location/Stock Type.

Stock Balances

The objective of the Stock Balances Analytical Model is to provide a comprehensive view of Material/Plant/Storage Location/Stock Type values and quantities at a given date, which reconciles to MB52.

Quantities and values are obtained from a combination of Goods Movement (MM) documents and Fi adjustment postings. 

Snapshots of monthly and weekly inventories will be created and partitioned (how so it makes sense?)

A persisted/portioned flow, containing aggregated data will also be created. This aggregated view will carry the stock balances for a month by Material/Plant/Storage Location/Stock Type. The current month stock movements will be union-ed to it to get to the current month ending balance.

EWM Managed Plants:

No differentiation in the handling of EWM managed plants are required. EWM handles the process, but each movement is reflected as a GoodsMovementDocument in table MSEG. This allows for a single process to calculate Closing Inventory.

The standard CDS views for physical stock and plant stock for EWM managed plants will be extracted and made available for reporting (if required for cross instance reporting...).

Source System Extractors

Inbound Layer

Harmonisation Layer

2TL_S2HARM_GoodsMovementDocumentDEX

Source: 1TL_S4Hx_I_GOODSMOVEMENTDOCUMENTDEX

Purpose:

• Harmonise maintenance order technical object data for reuse across A2DAMM.
• Standardise Equipment and Functional Location identifiers.
• Preserve scheduled basic start and end timestamps for planned downtime calculations.

2VR_A2DAMM_PMNotifMaintenanceData

Source: 1TL_S4Hx_Z_I_PMNotifMaintenanceData

Purpose:

• Harmonise notification maintenance data.
• Preserve raw downtime duration (seconds) and malfunction timestamps.
• Align technical object identifiers with order data.

Propagation Layer

3VR_A2DAMM_PlannedDownTime

Source: 2VR_A2DAMM_MaintOrderTech

Transformations/Calculations:

• Planned downtime window derived from Scheduled Basic Start and End date/time.
• PlannedVsUnplanned flag set to 'PLANNED'.
• SourceType set to 'ORDER'.

3VR_A2DAMM_UnplannedDownTime

Source: 2VR_A2DAMM_PMNotifMaintenanceData

Calculation:

• Unplanned downtime duration sourced from MaintObjectDowntimeDuration (seconds). 
• PlannedVsUnplanned flag set to 'UNPLANNED'.
• SourceType set to 'NOTIF'.

3VF_A2MAMM_PMNotifMaintenanceData

Source: 2VR_PMNotif

Logic / Adjustments:

• Project the notification-centric reporting grain (1 row per Maintenance Notification).
• Include required dimensions from the FS (e.g., Notification Type/Priority/Origin, Maintenance Plant, Creation Date/Time, Equipment, Functional Location).
• Include raw downtime duration (seconds) and derived hours where required (no pre-aggregation).

3VF_A2DAMM_DowntimeFact

Union:
Purpose: Combine planned and unplanned downtime into a single reusable downtime fact.

Union of: 3VR_A2DAMM_UnplannedDownTime & 3VR_A2DAMM_PlannedDownTime

Target Field Mapping:
- Technical Object fields aligned across both sources.
- Downtime duration stored in hours (conversion applied where required).

No aggregation is performed at this stage.

Datamodel, calculations and associations.

Projection:

Projection before union. Two objectives: 

Create a shared downtime schema. 

• SourceType = 'ORDER' / 'NOTIF'
• PlannedVsUnplanned = 'PLANNED' / 'UNPLANNED'
• DowntimeSeconds and/or DowntimeHours
• Normalise Functional Location: I_PMNotifMaintenanceData.RelevantFunctionalLocation & I_MaintOrderTechObjCube._LocationAccountAssignment.FunctionalLocation

Standardise time fields

• Planned: map scheduled basic start/end into StartDateTime, EndDateTime

• Unplanned: map malfunction start/end into StartDateTime, EndDateTime

Union:

Common fields

• Equipment
• Functional Location
• MaintenancePlanningPlant
• MaintenancePlannerGroup
• MaintenancePlant

Reporting Layer

4MA_A2DAMM_DowntimeFact

Supports:

• ERP-1012 Asset Down Time Planned vs Unplanned
• ERP-1012 Loss Driver (# breakdown hours)

Includes technical details for:

• Post-aggregation calculations
• Restricted measures
• Time-based analysis and drill-through

Calculated Measures (Post Aggregation Calculations / exception aggregation etc)

Restricted Measures

tbd

Currency Conversions

tbd

Variables

Data access controls

4MA_A2DAMM_PMNotifMaintenanceData

Supports:

• ERP-1012 Loss Driver (# breakdown hours) – unplanned downtime hours from notifications
• ERP-1012 Loss Driver (# notifications) – notification counts and status-driven slicing
• ERP-1012 Technical Availability (input measures) – unplanned downtime and breakdown flags used in SAC availability calculations
• ERP-1013 MTBF assuming the definition is "Time between failure events".*

*Since this potentially is the difference between two consecutive breakdown records, more calculations may be required in a separate model. Complexity ramps up if it requires actual operating hours between failures.

Includes technical details for:

• Post-aggregation calculations in SAC (e.g., hours conversions, ratios, availability formulas)
• Restricted measures by breakdown / downtime flags and status
• Time-based analysis (malfunction start/end, creation dates) and drill-through to Maintenance Notification

Dimensions & Measures are defined in the Functional Specification under “Dimensions & Measures: Requirements View”; the analytical model exposes those fields at notification grain without pre-aggregation.

Calculated Measures (Post Aggregation Calculations / exception aggregation etc)

Outbound Layer