SAP MDG · UTILITIES
How do I build a flattened SAP MDG Change Request extraction report for Business Partner data?
Use USMD120C for Change Request headers, USMD1213 to resolve the BP technical key, CL_USMD_ADAPTER_PROVIDER to resolve the generated BP table names, and dynamic ABAP reads to move the BP header and vendor fields into a flattened target table such as ZMDG_CHGREQ.
SOLUTION SUMMARY · SHORT ANSWER
Use USMD120C for Change Request headers, USMD1213 to resolve the BP technical key, CL_USMD_ADAPTER_PROVIDER to resolve the generated BP table names, and dynamic ABAP reads to move the BP header and vendor fields into a flattened target table such as ZMDG_CHGREQ.
This report pattern reads Business Partner Change Requests of type ZSUP* from USMD120C within a timestamp window, resolves the BP technical key from USMD1213, then uses CL_USMD_ADAPTER_PROVIDER to find the generated BP staging tables. The report finally reads organizational and vendor-related data dynamically and writes a flattened result set into ZMDG_CHGREQ.
Process flow
- Read TVARVC entry `ZMDG_REPORT2ONEDATA` or derive a default timestamp window.
- Select Change Request headers from `USMD120C` for `
USMD_CREQ_TYPE` like `ZSUP*`. - Select BP technical keys from `USMD1213` for entity `BP_HEADER`.
- Remove duplicates and build the unique technical key list.
- Call `CL_USMD_ADAPTER_PROVIDER=>GET_MODEL_GENERATION_ADAPTER` for model `BP`.
- Call `GET_GENERATED_OBJECTS` to retrieve generated physical table names.
- Read generated BP header and vendor tables dynamically.
- Assign the required generated components and fill the target structure `ZMDG_CHGREQ`.
CONFIGURATIONSource-backed paths
TVARVC entry `ZMDG_REPORT2ONEDATA`
Stores the saved low timestamp for the extraction window.
MDG model generation for `BP`
Provides the generated physical objects used by the dynamic reads.
Target table `ZMDG_CHGREQ`
Stores the flattened Change Request output rows.
Referenced tables
| Object | Purpose |
|---|---|
USMD120C | Change Request header table used to read type, status, reason, and timestamps. |
USMD1213 | Technical-key mapping table used to resolve the BP key from the Change Request. |
TVARVC | Stores the saved extraction timestamp used by the report. |
ZMDG_CHGREQ | Target table for the flattened report output. |
ILLUSTRATIVE ABAP SAMPLE
Source ABAP example
Exact relevant implementation excerpt from the knowledge document.
1*&---------------------------------------------------------------------*
2*& Report CHANGE_REQUEST_REPORT
3*&---------------------------------------------------------------------*
4*& Purpose:
5*& This report creates a flattened, non-modular view of the change
6*& request extraction logic from ZMDG_CHANGE_REQUEST_REPORT.
7*&
8*& What it does:
9*& - Reads change requests of type ZSUP* created in a time window
10*& - Resolves the BP technical key from USMD1213
11*& - Finds the dynamic generated staging table for BP data
12*& - Reads organizational and vendor-specific data dynamically
13*& - Combines header data and staging data into ZMDG_CHGREQ
14*& - Updates the target table with the generated results
15*&
16*& This file is intentionally flattened so the full flow can be studied
17*& without navigating includes or FORM modularization.
18*&---------------------------------------------------------------------*
19
20REPORT zmdg_change_request_report.
21
22"---------------------------------------------------------------------
23" Global data declarations from the TOP include
24" These variables hold the selection window, technical keys, dynamic
25" table references, and the final output rows.
26"---------------------------------------------------------------------
27DATA: gv_low TYPE timestamp,
28 gv_high TYPE timestamp,
29 gv_sid TYPE usmd_flg,
30 gt_techkey TYPE TABLE OF usmd_tech_key,
31 gs_techkey TYPE usmd_tech_key,
32 gt_techkey1 TYPE TABLE OF usmd_tech_key,
33 gt_usmd1210 TYPE STANDARD TABLE OF usmd1210,
34 gs_final TYPE zmdg_chgreq.
35
36" Range table for filtering change request types.
37DATA: gr_type TYPE RANGE OF usmd_crequest_type.
38
39" Helper structures for dynamic field handling.
40DATA: lt_key_fields_range TYPE RANGE OF name_komp,
41 lt_key_fields TYPE TABLE OF name_komp,
42 ls_key_data TYPE REF TO data,
43 go_data TYPE REF TO data.
44
45FIELD-SYMBOLS: <lfs_t_org_data> TYPE ANY TABLE,
46 <lfs_t_vengen> TYPE ANY TABLE.
47
48DATA: gr_data TYPE REF TO data.
49
50" Change request header data and intermediate technical-key mapping data.
51DATA: lt_usmd1213 TYPE TABLE OF usmd1213,
52 ls_usmd1213 TYPE usmd1213,
53 lt_usmd120c TYPE TABLE OF usmd120c,
54 ls_usmd120c TYPE usmd120c.
55
56" Final output buffer to be written to ZMDG_CHGREQ.
57DATA: gt_data TYPE TABLE OF zmdg_chgreq,
58 gs_data TYPE zmdg_chgreq.
59
60" Empty selection-screen include from the original program.
61" The original include exists only as a placeholder, so the flat version
62" keeps the same structure but does not add custom selection fields.
63
64"---------------------------------------------------------------------
65" Main execution flow
66"---------------------------------------------------------------------
67START-OF-SELECTION.
68 " Read and prepare the source data first.
69 PERFORM get_data.
70
71END-OF-SELECTION.
72 " After data extraction, build the final output rows and persist them.
73 PERFORM process_data.
74
75"---------------------------------------------------------------------
76" FORM get_data
77" Purpose:
78" Collect all change requests and staging-table data needed to build
79" the flattened change request report.
80"---------------------------------------------------------------------
81FORM get_data.
82
83 " Reset key runtime variables before the extraction starts.
84 CLEAR: gv_low, gv_high, gv_sid, gt_techkey.
85
86 " Only change request types that start with ZSUP are relevant.
87 gr_type = VALUE #( ( sign = 'I' option = 'CP' low = 'ZSUP*' ) ).
88
89 "---------------------------------------------------------------
90 " Determine the extraction time window.
91 " If TVARVC contains a saved low timestamp, use it; otherwise use
92 " the current timestamp and subtract one month.
93 "---------------------------------------------------------------
94 SELECT SINGLE * FROM tvarvc
95 INTO @DATA(ls_tvarvc)
96 WHERE name = 'ZMDG_REPORT2ONEDATA'.
97 IF sy-subrc = 0 AND ls_tvarvc-low IS NOT INITIAL.
98 gv_low = ls_tvarvc-low.
99 ELSE.
100 GET TIME STAMP FIELD DATA(lv_current_timestamp).
101 CONVERT TIME STAMP lv_current_timestamp TIME ZONE 'UTC'
102 INTO DATE DATA(lv_date)
103 TIME DATA(lv_time).
104 TRY.
105 cl_hrpad_date_computations=>add_months_to_date(
106 EXPORTING
107 start_date = lv_date
108 months = -1
109 RECEIVING
110 date = DATA(lv_past_date)
111 ).
112 CATCH cx_hrpa_violated_postcondition.
113 " Fallback if month subtraction hits a date postcondition.
114 lv_past_date = lv_date - 30.
115 ENDTRY.
116 CONVERT DATE lv_past_date TIME lv_time
117 INTO TIME STAMP DATA(lv_target_timestamp) TIME ZONE 'UTC'.
118 gv_low = lv_target_timestamp.
119 gv_high = lv_current_timestamp.
120 ENDIF.The remaining configuration, implementation details, and testing guidance continue from this answer more…
Related questions and keywords
Alternative questions
- How does the report read MDG Change Requests and dynamic BP staging tables?
- How do I extract BP Change Requests from USMD120C and USMD1213 into a custom table?
- How do I read generated BP staging tables dynamically in ABAP for MDG reporting?
Possible questions
- How does the report determine the extraction window?
- Which tables does the report use for Change Request headers and technical keys?
- How are generated BP staging table names resolved dynamically?
- How are organizational and vendor-related BP fields read from generated tables?
- How is the final target table filled from the extracted data?