Be explicit when names or data boundaries differ

The operational record calls a value dispatch_id; a partner-facing report calls it tracking_code. CORRESPONDING can express that relationship and deliberately leave fields out.

Rename and omit

DATA(report) = CORRESPONDING ty_report(
  dispatch
  MAPPING tracking_code = dispatch_id
  EXCEPT internal_note ).

MAPPING target = source names the field on each side. EXCEPT prevents a same-named field from being copied, so internal_note remains initial in the report. This is a useful safeguard, but a mapping list is not by itself a complete security policy. Define the target data shape narrowly and review every field that crosses a boundary.

Mapping expressions and their additions vary by release and context. Check the target system’s ABAP Keyword Documentation, especially when combining mappings, defaults, or deep components.

Sources

Developer practice · ABAP

Practice: map only approved report fields

Build a report row that renames dispatch_id to tracking_code and excludes internal_note.

Choose your ABAP environment

This choice changes the output pattern checked here: WRITE belongs in a classic executable report, while out->write( ) uses the supplied output reference in an ABAP Cloud class-run method. It does not switch the language version of the other code; check release and API availability in your target system.

Complete the task and include the output statement shown for your selected environment. Variable names can differ if you use them consistently. This browser checker checks structure only; it does not compile or run ABAP.

0 required structures detected · 0 checks

Debug this code

Assume the dispatch and report structures are already defined. The field mapping is reversed; correct the target and source sides.

Edit the code, then check for the expected repair. This is a structure check, not an ABAP compiler.