Start with a record, not a pile of unrelated variables

A dispatch screen needs an identifier, a status, and a package count. Declaring each field separately makes it easy to accidentally mix values from different deliveries. A structured type gives one dispatch a named, reusable shape.

Describe the shape with TYPES

TYPES: BEGIN OF ty_dispatch,
         dispatch_id TYPE string,
         status TYPE string,
         package_count TYPE i,
       END OF ty_dispatch.

TYPES defines a type; it does not create a populated dispatch. The components can have different elementary types and are accessed by name later. Choose names and types that reflect the values your own business rule needs.

Create a value using the type

DATA(dispatch) = VALUE ty_dispatch(
  dispatch_id = 'D-104'
  status = 'READY'
  package_count = 3 ).

This is a fictional local type, not an SAP-delivered table or API. In a real project, an existing DDIC or CDS type may be appropriate, but ABAP Cloud code must use repository objects released for its language version. Don’t create a duplicate type without checking the project’s existing model.

Classic ABAP and ABAP Cloud use the same structure ideas here; the surrounding program entry point and available repository types can differ. The snippets show source fragments, not a complete executable program.

When to use it

Use a local TYPES declaration when a small record is specific to one program or class. If several components of the application need the same public shape, a released shared type may be more suitable.

Sources

• SAP Samples: Structures
• ABAP Keyword Documentation: structured types

TYPES: BEGIN OF ty_dispatch,
         dispatch_id TYPE string,
         status TYPE string,
         package_count TYPE i,
       END OF ty_dispatch.
DATA(dispatch) = VALUE ty_dispatch( dispatch_id = 'D-104' status = 'READY' package_count = 3 ).
DATA(result) = dispatch-dispatch_id.

WRITE result.

out->write( result ).