Skip to content

ABAP Keyword Documentation →  ABAP − Reference →  ABAP RESTful Programming Model →  Behavior Definitions →  ABAP BDL →  ABAP BDL - DEFINE BEHAVIOR 

ABAP BDL - DEFINE BEHAVIOR, late numbering

Other versions: 7.31 | 7.40 | 7.54


... late numbering [in place]


Late numbering is a concept for gapless assignments of unique keys when creating new entity instances. New entity instances are given their final key shortly before the business object is saved. Until this moment, the application logic uses a temporary key that has to be replaced when the business object data is saved.

The addition in place indicates that a CDS entity uses its own key fields for late numbering. These key fields are written to the special values, which are identified as temporary. This means that the derived types for the entity do not contain an additional field %PID. The task when assigning the keys (TYPE TABLE FOR MAPPED) therefore is to map from a temporary key to the final key and not to map from a %PID to the final key. This means that the mapped structure contains the entity key fields twice, once as a component %TMP and once as a component %KEY.

Late numbering must be applied by implementing the method adjust_numbers() of the local saver class that is part of the behavior implementation. When declared in the behavior definition of the entity, late numbering causes the runtime to call the method adjust_numbers() at the time in question. This implementation is then responsible for assigning the final keys and passing them to the method parameter mapped.


  • The parameter mapped is used to pass the final keys to the framework and hence replace the temporary keys. Ideally, this replacement action is decoupled from the actual saving of the data but many legacy applications determine their keys when the data is saved. In these cases, it is best to implement the save logic in adjust_numbers() and leave the method save itself empty.

  • Late numbering modifies the derived types: The tables mapped, reported, and failed are given the additional field %PID to hold a temporary key.


In the following example, the data from the ABAP flight data reference scenario (or flight data scenario for short) is used. It represents a legacy business logic that can be used to create and edit flight bookings. The CDS view /DMO/I_Travel represents the root node of the business object for managing flight trips. The underlying business model is described in ABAP BDL - Example.

The following example shows the behavior definition for the root entity Travel.

implementation unmanaged;
define behavior for /DMO/I_Travel alias Travel
late numbering
  action set_status_booked result [1] $self;