Skip to main content

Module 2: Core Data Processing Engine - process_data Form

← Back to Overview | ← Previous: Data Selection | Next: Output Builder →

Module Overview​

Lines: 1664-2108
Importance: Tier 1 (Critical) - The heart of demand aggregation
Purpose: Transforms raw material requirements into time-bucketed demand forecasts

Business Context - The "Demand Aggregation Factory"​

Think of this module as a sophisticated factory conveyor belt that:

  • Takes raw material requirements from SAP's MRP system
  • Sorts them into time periods (buckets)
  • Calculates net demands after considering stock
  • Handles different types of requirements (production, purchase orders, etc.)
  • Outputs organized demand data ready for reporting

High-Level Processing Flow​

Detailed Section Analysis​

Section 1: Initialization and Setup (Lines 1664-1691)​

DATA: lw_demand TYPE mdez-mng01,
      lw_stockh TYPE mdez-mng01,
      lw_tabix  TYPE sy-tabix,
      lw_stock  TYPE mdez-mng01

IF p_pd = true.
  lw_ergbz = c_pd_ergbz.    " Production Demand
ELSEIF p_co = true.
  lw_ergbz = c_co_ergbz.    " Committed Orders  
ELSE.
  lw_ergbz = c_sl_ergbz.    " Sales/Libre
ENDIF.

What happens:

  • Sets up work variables for calculations
  • Determines which type of requirements to process based on user selection
  • lw_ergbz controls what data the MRP API will return

Analogy: Like setting up different assembly line configurations in a factory - one for raw materials, one for finished goods, etc.

Section 2: Period Adjustment Logic (Lines 1697-1717)​

IF lv_period = sy-datum+4(2).    " Current month
  w_future_periods-start_date = w_odue_date.
  MODIFY t_future_periods FROM w_future_periods INDEX 1

Business Logic:

  • If processing the current accounting/calendar period
  • Adjusts the first time bucket to start from the "overdue date"
  • Ensures overdue requirements are captured in the first period

Critical for Beginners: This handles the common business scenario where "Week 1" should include all overdue requirements, not just the current week.

Section 3: Main Processing Loop (Lines 1720-2108)​

3A: Stock Requirements API Call (Lines 1735-1748)​

CALL FUNCTION 'MD_STOCK_REQUIREMENTS_LIST_API'
  EXPORTING
    matnr                    = <lw_materials>-matnr
    werks                    = <lw_materials>-werks  
    ergbz                    = lw_ergbz
  IMPORTING
    e_mt61d                  = wa_mt61d
  TABLES
    mdezx                    = t_mdezx

What this API does:

3B: Stock Level Processing (Lines 1755-1764)​

READ TABLE t_mdezx INTO lw_mdezx WITH KEY delkz = c_wb.
IF sy-subrc = 0.
  <lw_materials>-stock = lw_mdezx-mng01.
ENDIF.

PERFORM appotion_quantity USING    <lw_materials>-matnr
                                   <lw_materials>-werks  
                                   <lw_materials>-lifnr
                          CHANGING <lw_materials>-stock.

Key Processing:

  1. Extracts current stock level (delkz = 'WB' means warehouse stock)
  2. Calls appotion_quantity to allocate stock among vendors proportionally
  3. This ensures each vendor sees their "fair share" of available stock

3C: Requirement Type Filtering (Lines 1776-1855)​

The module has three distinct processing paths:

Production Demand Mode (p_pd = 'X'):

Committed Orders Mode (p_co = 'X'):

Sales/Libre Mode (Default):

3D: Complex Subcontractor Stock Logic (Lines 1785-1805)​

This is one of the most complex parts:

LOOP AT t_mdezx INTO lw_mdezx WHERE planr NE space.
  IF lw_mdezx-delkz = c_lk.                    " Stock with subcontractor
    lw_stock = lw_mdezx-mng01.
    <lw_materials>-stock = <lw_materials>-stock + lw_mdezx-mng01.
  ELSE.
    IF lw_stock > 0.
      lw_stock = lw_stock + lw_mdezx-mng01.
      IF lw_stock < 0.
        lw_mdezx-mng01 = lw_stockh * -1.

Business Logic Explained:

Data Transformation Flow​

Input Data Structure:​

SourceTypeContent
t_materialsDriving TableMaterials to process
t_mdezxAPI ResultRaw requirements/receipts
t_future_datesTime BucketsDate ranges for aggregation

Processing Steps:​

  1. Extract Stock: Find warehouse stock (WB) and subcontractor stock (LK)
  2. Filter Requirements: Keep only relevant requirement types
  3. Apply Stock: Net requirements against available stock
  4. Time Bucket: Aggregate into weekly/monthly periods
  5. Store Results: Build t_matfcast table

Output Data Structure:​

TablePurposeKey Fields
t_matfcastAggregated demandsmatnr, werks, period, quantity
t_materialsEnhanced material datastock, meins, maktx

Critical Business Rules Implemented​

Rule 1: Stock Consumption Priority​

  • Available stock reduces demand in chronological order
  • Subcontractor stock is treated as available inventory
  • Stock shortages appear as positive demand

Rule 2: Vendor-Specific Processing​

  • In vendor mode, only requirements for the specific vendor count
  • Purchase orders are filtered by vendor assignment
  • Materials without vendor assignments may still show demand

Rule 3: Time Period Aggregation​

  • All requirements within a time bucket are summed
  • Overdue requirements go to the first bucket
  • Future requirements are distributed to appropriate buckets

Performance Critical Sections​

  1. Lines 1735-1748: API call - potentially expensive for many materials
  2. Lines 1785-1805: Complex looping logic that processes all requirements
  3. Lines 1820-1890: Multiple DELETE operations on large internal tables

Error Handling​

  1. Line 1749: CHECK sy-subrc = 0 - Skip materials with API errors
  2. Line 1752: Delete specific order types that cause data issues
  3. Line 1755: Safe READ TABLE operations with existence checks

Common Beginner Questions​

Q: Why are there three different processing modes? A: Different business users need different views:

  • Production: "What do I need to manufacture?"
  • Purchasing: "What purchase orders are committed?"
  • Sales: "What did customers order?"

Q: What is the subcontractor logic doing? A: When we send material to a subcontractor for processing, it's still our inventory. The logic ensures this "external stock" reduces our demand appropriately.

Q: Why filter by date ranges?
A: Users typically want forecasts for specific time periods (next 52 weeks, next 18 months, etc.). Requirements beyond the horizon are ignored.

Integration Points​

Incoming Dependencies:

  • t_materials from select_data
  • t_future_dates from period calculation routines
  • User selection parameters (p_pd, p_co, etc.)

Outgoing Results:

  • t_matfcast → Used by build_output_table
  • Enhanced t_materials → Used for display
  • t_vendor → Used for vendor name display

Next Module Connection​

The t_matfcast table populated here becomes the primary input for build_output_table, which structures the data for ALV display.

← Back to Overview | ← Previous: Data Selection | Next: Output Builder →