SAP Community - ABAP Development

How to enable BC Set support for BC app

2026-01-23T11:06:48.347000+01:00

Introduction

In order to use the "import from transport" function in the BC Set editor, the data must be recorded in the context of a transport object (TOBJ) and the business configuration maintenance object (SMBC) must maintain the corresponding transport object attribute.

This blog explains the necessary steps to enable existing SMBC objects for the "import from transport" functionality. Newly generated SMBC objects are automatically enabled.

This blog is relevant for

Case 1: Transport object is already used in the BC app

As of release 2302, when you use the ADT wizard to generate a business configuration maintenance object (SMBC), a transport object (TOBJ) is generated by default and used in the behavior implementation. In this case you only need to maintain the new "Transport Object" attribute of the SMBC object.

You can do this manually in the ADT editor of the SMBC object or programmatically. First you need to find out the name of the transport object. In most cases the name is equal to the name of the SMBC object. You can open the behavior implementation class and check the first couple of rows to verify the name of the transport object ( depending on the release the object was created: CO_TRANSPORT_OBJECT or TDAT_NAME )

CLASS LHC_COMPANYCODEALL DEFINITION FINAL INHERITING FROM CL_ABAP_BEHAVIOR_HANDLER.
  PUBLIC SECTION.
    CONSTANTS:
      CO_ENTITY TYPE abp_entity_name VALUE `ZI_COMPANYCODE_S`,
      CO_TRANSPORT_OBJECT TYPE mbc_cp_api=>indiv_transaction_obj_name VALUE `ZCOMPANYCODE`,
      CO_AUTHORIZATION_ENTITY TYPE abp_entity_name VALUE `ZI_COMPANYCODE`.

CLASS LHC_RAP_TDAT_CTS DEFINITION FINAL.
  PUBLIC SECTION.
    CLASS-METHODS:
      GET
        RETURNING
          VALUE(RESULT) TYPE REF TO IF_MBC_CP_RAP_TDAT_CTS.

ENDCLASS.

CLASS LHC_RAP_TDAT_CTS IMPLEMENTATION.
  METHOD GET.
    result = mbc_cp_api=>rap_tdat_cts( tdat_name = 'ZTAB6'

You can maintain the attribute "Transport Object" in the "Service Configuration" section of the SMBC object in the ADT editor. Save and activate.

You can update this attribute also programmatically:

CLASS zset_tobj DEFINITION
  PUBLIC
  FINAL
  CREATE PUBLIC .

  PUBLIC SECTION.
    INTERFACES if_oo_adt_classrun .
  PROTECTED SECTION.
  PRIVATE SECTION.
ENDCLASS.

CLASS zset_tobj IMPLEMENTATION.

  METHOD if_oo_adt_classrun~main.
    DATA smbc_id TYPE TABLE OF if_mbc_cp_api_business_config=>ty_technical_id WITH EMPTY KEY.
    SELECT ABAPObject FROM I_CustABAPObjDirectoryEntry
      WHERE ABAPObjectType = 'SMBC' AND ABAPObject LIKE '<NAMESPACE>%'
      INTO TABLE @smbc_id .
    LOOP AT smbc_id ASSIGNING FIELD-SYMBOL(<smbc_id>).
      out->write( |SMBC object: { <smbc_id> }| ).
      TRY.
          DATA(tobj) = mbc_cp_api=>business_configuration_api( <smbc_id> )->read( )-transport_object.
          IF tobj IS NOT INITIAL.
            out->write( |TOBJ already set: { tobj }| ).
          ELSE.
            mbc_cp_api=>business_configuration_api( <smbc_id> )->update_transport_object(
              transport_object = <smbc_id> "if the table list of the transport object does not match the table list of the behavior definition an exception is raised
              transport        = '<Workbench Request>' ). "transport=space for local objects
            out->write( |TOBJ set: { mbc_cp_api=>business_configuration_api( <smbc_id> )->read( )-transport_object }| ).
          ENDIF.
        CATCH cx_root INTO DATA(exc).
          out->write( |Error: { exc->get_text( ) }| ).
      ENDTRY.
    ENDLOOP.
  ENDMETHOD.

ENDCLASS.

Use Case 2: The BC app does not use a transport object

Delete the existing BC app and create it again using the ADT wizard.

If you cannot do that, you can also use the ADT wizard to generate a new BC app for the table(s) with different object names. Move the generated transport object to the package of the old BC app and maintain the transport object attribute of the old SMBC object.
If necessary, adjust the generated TOBJ by changing the table piece list.
Adjust the old behavior implementation class by by replacing the existing method implementation with the equivalent method implementation of the new behavior implementation class. Adjust the constants to match the old object names.
You can now delete the newly generated objects.

Transport object names

The last character of the technical name of a transport object is its type. In the SMBC and TOBJ ADT editor, the technical name of the transport object is used. Use the input help to select a transport object.
In the API calls in the behavior implementation class, the type of a transport object is either a separate parameter or T (Individual Transaction Object) by default. That is, remove the last character for the name of the transport object.
Example:
In ADT, the name of the transport object is "ZTOBJ1 T" or "ZCOMPANYCODET". In the behavior implementation class, use "ZTOBJ1" or "ZCOMPANYCODE".

Creating an Interactive Editable ALV in ABAP with Header-Item CRUD Functionality

2026-01-24T04:59:44.641000+01:00

In this blog post, we will explore a powerful ABAP implementation of an editable ALV using CL_GUI_ALV_GRID. This solution provides:

Interactive two-screen design (Header & Item)
Double-click to drill down from header to item
Row-based editing using LVC_ROWMARK
Field-level edit control via CELLTAB
Full CRUD operations (Create, Read, Update, Delete) for both header and item data

🏠 Scenario

We use two custom database tables:

Custom Table → Delivery Header Data (VBELN, ERNAM, ERDAT, VSTEL, VKORG)
Custom Table → Delivery Item Data (VBELN, POSNR, MATNR, WERKS)

The goal is to allow users to edit only selected rows, protect primary key fields, and manage entries interactively.

1. Table Declarations

TABLES?

Custom transparent table containing delivery header data.
Custom transparent table for delivery item data.
These tables are used to fetch and store ALV grid data.

🔷 2. Class Forward Declaration

CLASS DELIVERY DEFINITION DEFERRED.

Forward declares a class named DELIVERY used later to handle double-click events.
This is necessary to register event handlers before the class is fully implemented.

🔷 3. Type Declarations

TYPES: BEGIN OF T_ZDB_EDIT_ALV, VBELN TYPE ZDB_EDIT_ALV-VBELN, ERNAM TYPE ZDB_EDIT_ALV-ERNAM, ERDAT TYPE ZDB_EDIT_ALV-ERDAT, VSTEL TYPE ZDB_EDIT_ALV-VSTEL, VKORG TYPE ZDB_EDIT_ALV-VKORG, CELLTAB TYPE LVC_T_STYL, END OF T_ZDB_EDIT_ALV.

Defines a structure T_ZDB_EDIT_ALV to hold header data and editable styles.
CELLTAB: Stores editable style info for ALV cell-level control.

Similarly, for item data:

TYPES: BEGIN OF T_ZDB_EDIT_ALV1, VBELN TYPE ZDB_EDIT_ALV1-VBELN, POSNR TYPE ZDB_EDIT_ALV1-POSNR, MATNR TYPE ZDB_EDIT_ALV1-MATNR, WERKS TYPE ZDB_EDIT_ALV1-WERKS, CELLTAB TYPE LVC_T_STYL, END OF T_ZDB_EDIT_ALV1.

🔷 4. Data Definitions

DATA: LT_LIKP TYPE TABLE OF T_ZDB_EDIT_ALV, LS_LIKP TYPE T_ZDB_EDIT_ALV, LT_LIPS TYPE TABLE OF T_ZDB_EDIT_ALV1, LS_LIPS TYPE T_ZDB_EDIT_ALV1,

Internal tables and work areas for header (LT_LIKP, LS_LIKP) and item (LT_LIPS, LS_LIPS) records.

LT_FCAT TYPE LVC_T_FCAT, LS_FCAT TYPE LVC_S_FCAT, LT_FCAT1 TYPE LVC_T_FCAT, LS_FCAT1 TYPE LVC_S_FCAT,

Field catalog tables for header (LT_FCAT) and item (LT_FCAT1) ALVs.

LS_LAYO TYPE LVC_S_LAYO, LS_LAYO1 TYPE LVC_S_LAYO,

Layout configurations for header and item grids.

O_CONTAINER1 TYPE REF TO CL_GUI_CUSTOM_CONTAINER, O_GRID1 TYPE REF TO CL_GUI_ALV_GRID, O_CONTAINER2 TYPE REF TO CL_GUI_CUSTOM_CONTAINER, O_GRID2 TYPE REF TO CL_GUI_ALV_GRID,

Containers and ALV grid objects for screen 200 (header) and screen 100 (item).

5. Selection Screen Definition

Purpose: Creates a selection screen block with delivery number as the input filter.
S_VBELN: Allows users to input multiple values or ranges for VBELN.
TEXT-000: Refers to a text element (defined in SE32 or SE38) for the frame title.

🔷 6. Field Catalog for Item ALV

Uses VALUE #( ) constructor to populate the field catalog for the item-level ALV (LT_LIPS).
COL_POS: Column order in the ALV.
FIELDNAME: Field to display.
COLTEXT: Header text.
TABNAME: Reference table used for dynamic assignment (not required in OO ALV, but used for clarity here).

🔷 7. Layout Configuration for Item ALV

GRID_TITLE: Title of the ALV.
SEL_MODE = 'A': Allows multiple row selection.
NO_TOOLBAR = 'X': Hides the standard ALV toolbar.
STYLEFNAME = 'CELLTAB': Tells ALV to use the CELLTAB column to control editable styles per cell.

🔷 8. Start-of-Selection

START-OF-SELECTION. CALL SCREEN 200.

Trigger point of the report after user input.
It navigates to screen 200, which displays the header-level ALV.

9. Event Handler Class Definition

Defines a local class DELIVERY with method GET_DATA.
The method is registered as an event handler for the double-click event of the ALV.

🔷 10. Class Implementation

GET_DATA is triggered when the user double-clicks on a row in header ALV.
It reads the delivery number (VBELN) of the clicked row.
Then fetches all matching item-level records from ZDB_EDIT_ALV1 into LT_LIPS.
Opens Screen 100, which shows the item ALV.

🔷 11. Screen 100 (Item ALV) - OUTPUT Module

SET PF-STATUS 'ZITEMS': Sets the GUI status (button functions) for item screen.
PERFORM CREATE_OBJECT_LIPS: Initializes the ALV Grid for item records.

🔷 12. Screen 100 - INPUT Module

Handles user actions on screen 100:
- BACK: Return to header ALV.
- CREATE: Add a new item row.
- EDIT: Enable selected row for editing.
- UPDATE: Update modified item data.
- DELETE: Remove selected rows.
- SAVE: Insert/update item data into DB.

FORM CREATE_OBJECT_LIPS – Initializes ALV on Screen 100 (Item).
MODULE STATUS_0200 OUTPUT – Prepares header ALV on Screen 200.
MODULE USER_COMMAND_0200 INPUT – Handles toolbar actions for header ALV.
Then we’ll go deeper into the CRUD FORMs (CREATE/EDIT/UPDATE/DELETE/SAVE) for both header and item ALVs.
FORM CREATE_OBJECT_LIPS – Create ALV Grid for Items

🔹

Explanation:

CLEAR O_CONTAINER2: Reset reference before ALV creation (safety check).
CREATE OBJECT O_CONTAINER2: Creates a custom container placed on the screen (SCREEN 100) using element CONTAINER2.
CREATE OBJECT O_GRID2: Binds an ALV Grid (CL_GUI_ALV_GRID) to the container.
SET_TABLE_FOR_FIRST_DISPLAY:
- IS_LAYOUT = LS_LAYO1: Applies previously configured layout for item ALV.
- IT_OUTTAB = LT_LIPS: Data source for the ALV.
- IT_FIELDCATALOG = LT_FCAT1: Column settings for the ALV.

🔷 13. MODULE STATUS_0200 OUTPUT – Setup Header Screen (Screen 200)

Explanation:

SET PF-STATUS 'ZHEADER': Sets GUI status for header toolbar (buttons: CREATE, EDIT, SAVE, etc.).
The SELECT pulls header records from ZDB_EDIT_ALV based on delivery numbers entered on the selection screen.

ALV Grid Initialization:

Creates the custom container and grid for header-level display.

Field Catalog (LT_FCAT):

Each field is appended individually to LT_FCAT with attributes:

Layout for Header ALV:

Final ALV Setup:

Initializes header ALV with all settings and data.

Event Handler Registration:

Double-click on any row in header ALV triggers GET_DATA, which fetches corresponding items.

🔷 14. MODULE USER_COMMAND_0200 INPUT – Header Screen Toolbar Actions

Executes the relevant FORM based on user action on toolbar buttons:
- CREATE: Adds a new editable row.
- EDIT: Enables selected row for editing.
- SAVE: Inserts or updates data in DB.
- DELETE: Removes selected rows from ALV and DB.
- UPDATE: Commits modified data to DB.

15. FORM CHANGE_MODE – Enable Edit Mode for Selected Header Row

Purpose: Only the selected row becomes editable. All others stay read-only.
LVC_T_ROID, LVC_S_STYL: Types for editable styles.
CELLTAB is used for cell-level control.
Gets the row(s) selected in the header ALV using LVC_ROWMARK.

Loop over each header entry to determine which row to enable.

Compares the current loop index with selected rows.
If it’s selected, enable its editable fields.

🔹 If Selected Row → Enable ditable Fields

IF SY-SUBRC = 0. LS_STYLEROW-STYLE = CL_GUI_ALV_GRID=>MC_STYLE_DISABLED. LS_STYLEROW-FIELDNAME = 'VBELN'. INSERT LS_STYLEROW INTO TABLE LT_STYLEROW.

VBELN is a primary key → disabled.
Similarly disables ERNAM.

LS_STYLEROW-STYLE = CL_GUI_ALV_GRID=>MC_STYLE_ENABLED. LS_STYLEROW-FIELDNAME = 'ERDAT'. INSERT LS_STYLEROW INTO TABLE LT_STYLEROW.

Enables only non-primary key fields for editing: ERDAT, VSTEL, VKORG.

🔹 Assign Cell Styles to Entry

CLEAR: LS_LIKP-CELLTAB. INSERT LINES OF LT_STYLEROW INTO TABLE LS_LIKP-CELLTAB. MODIFY LT_LIKP FROM LS_LIKP TRANSPORTING CELLTAB. CLEAR: LT_STYLEROW.

Applies the style to the current line.

🔹 Else – Row not selected → Make it fully non-editable

ELSE. LS_STYLEROW-STYLE = CL_GUI_ALV_GRID=>MC_STYLE_DISABLED. ... INSERT LS_STYLEROW INTO TABLE LT_STYLEROW. ... MODIFY LT_LIKP FROM LS_LIKP TRANSPORTING CELLTAB.

🔹 Toggle Grid Ready for Input

IF O_GRID1->IS_READY_FOR_INPUT( ) EQ 0. CALL METHOD O_GRID1->SET_READY_FOR_INPUT EXPORTING I_READY_FOR_INPUT = 1. ELSE. CALL METHOD O_GRID1->SET_READY_FOR_INPUT EXPORTING I_READY_FOR_INPUT = 0. ENDIF.

Activates input mode if not already.

O_GRID1->REFRESH_TABLE_DISPLAY( ).ENDFORM.

Refreshes the ALV to reflect the updated editable state.

🔷 16. FORM CREATE_HEADER_DATA – Add New Editable Header Row

FORM CREATE_HEADER_DATA . DATA: LS_NEW TYPE T_ZDB_EDIT_ALV, LT_STYLEROW TYPE STANDARD TABLE OF LVC_S_STYL WITH DEFAULT KEY, LS_STYLEROW TYPE LVC_S_STYL.

Prepares a new structure and editable field style list.

🔹 Set Editable Fields

LS_STYLEROW-FIELDNAME = 'VBELN'. LS_STYLEROW-STYLE = CL_GUI_ALV_GRID=>MC_STYLE_ENABLED. APPEND LS_STYLEROW TO LT_STYLEROW.

All fields are enabled since it’s a new row. Even primary keys like VBELN, ERNAM.
Repeats for: ERNAM, ERDAT, VSTEL, VKORG.

🔹 Assign Styles and Add New Entry

LS_NEW-CELLTAB = LT_STYLEROW. APPEND LS_NEW TO LT_LIKP.

Assigns the editable CELLTAB and appends the new row to the internal table.

CALL METHOD O_GRID1->SET_READY_FOR_INPUT EXPORTING I_READY_FOR_INPUT = 1. CALL METHOD O_GRID1->REFRESH_TABLE_DISPLAY.ENDFORM.

Turns on editable mode and refreshes ALV.

17. FORM DELETE_HEADER_DATA – Delete Selected Header Rows

FORM DELETE_HEADER_DATA . DATA: LT_ROWS TYPE LVC_T_ROW, LS_ROW TYPE LVC_S_ROW, LV_IDX TYPE SY-TABIX.

LT_ROWS: Holds the list of selected row indexes.
LS_ROW: Work area for current row index.
LV_IDX: Integer used to track which row index is being processed.

🔹 Get Selected Rows

CALL METHOD O_GRID1->GET_SELECTED_ROWS IMPORTING ET_INDEX_ROWS = LT_ROWS.

Fetches the selected row indexes in the header ALV grid.

🔹 Loop and Delete from DB & Internal Table

LOOP AT LT_ROWS INTO LS_ROW. LV_IDX = LS_ROW-INDEX. READ TABLE LT_LIKP INDEX LV_IDX INTO LS_LIKP. IF SY-SUBRC = 0. DELETE FROM ZDB_EDIT_ALV WHERE VBELN = LS_LIKP-VBELN. DELETE LT_LIKP INDEX LV_IDX. ENDIF. ENDLOOP.

For each selected row:
- Reads that entry from LT_LIKP.
- Deletes corresponding record from DB table ZDB_EDIT_ALV.
- Deletes it from internal table LT_LIKP.

🔹 Refresh ALV & Commit

CALL METHOD O_GRID1->REFRESH_TABLE_DISPLAY. COMMIT WORK. MESSAGE 'Selected header(s) deleted' TYPE 'S'.ENDFORM.

Refreshes the ALV display.
Saves DB changes using COMMIT WORK.
Displays success message.

🔷 18. FORM SAVE_HEADER_DATA – Insert or Update Header Records

FORM SAVE_HEADER_DATA .

🔹 Flat Structure Definition

TYPES: BEGIN OF TY_ZDB_EDIT_ALV_FLAT, VBELN TYPE ZDB_EDIT_ALV-VBELN, ERNAM TYPE ZDB_EDIT_ALV-ERNAM, ERDAT TYPE ZDB_EDIT_ALV-ERDAT, VSTEL TYPE ZDB_EDIT_ALV-VSTEL, VKORG TYPE ZDB_EDIT_ALV-VKORG, END OF TY_ZDB_EDIT_ALV_FLAT. DATA: LS_DB_ALV_FLAT TYPE TY_ZDB_EDIT_ALV_FLAT.

This structure excludes CELLTAB and is used to write data into the DB.

🔹 Ensure User Changes Are Captured

CALL METHOD O_GRID1->CHECK_CHANGED_DATA.

Updates the internal table (LT_LIKP) with user input from the ALV grid.

🔹 Loop Through Header Table and Save to DB

LOOP AT LT_LIKP INTO LS_LIKP. LS_DB_ALV_FLAT-VBELN = LS_LIKP-VBELN. LS_DB_ALV_FLAT-ERNAM = LS_LIKP-ERNAM. LS_DB_ALV_FLAT-ERDAT = LS_LIKP-ERDAT. LS_DB_ALV_FLAT-VSTEL = LS_LIKP-VSTEL. LS_DB_ALV_FLAT-VKORG = LS_LIKP-VKORG.

Copies the values to a flat version to avoid CELLTAB structure issues.

🔹 Insert or Update Logic

SELECT SINGLE VBELN INTO @DATA(LV_VBELN) FROM ZDB_EDIT_ALV WHERE VBELN = @LS_DB_ALV_FLAT-VBELN AND ERNAM = @LS_DB_ALV_FLAT-ERNAM. IF SY-SUBRC = 0. UPDATE ZDB_EDIT_ALV SET ERDAT = @LS_DB_ALV_FLAT-ERDAT, VSTEL = @LS_DB_ALV_FLAT-VSTEL, VKORG = @LS_DB_ALV_FLAT-VKORG WHERE VBELN = @LS_DB_ALV_FLAT-VBELN AND ERNAM = @LS_DB_ALV_FLAT-ERNAM. ELSE. INSERT ZDB_EDIT_ALV FROM LS_DB_ALV_FLAT. ENDIF. ENDLOOP.

If record exists (same VBELN & ERNAM) → UPDATE.
Else → INSERT as new record.

COMMIT WORK. MESSAGE 'Header data saved successfully' TYPE 'S'.ENDFORM.

Final commit and success message.

🔷 19. FORM UPDATE_HEADER_DATA – Update Header Records

FORM UPDATE_HEADER_DATA . CALL METHOD O_GRID1->CHECK_CHANGED_DATA.

Reads current ALV data into LT_LIKP.

🔹 Loop and Upsert to DB

Maps data into a flat structure.

Same insert/update logic as SAVE

COMMIT WORK. MESSAGE 'Header data Updated successfully' TYPE 'S'.ENDFORM.

✅ That completes the full documentation of header-level editable ALV with CRUD.

Next, I’ll begin the item-level ALV explanation starting with:

FORM CHANGE_ITEMS_MODE
FORM CREATE_ITEMS_DATA
FORM DELETE_ITEMS_DATA
FORM SAVE_ITEMS_DATA
FORM UPDATE_ITEMS_DATA

🔷 20. FORM CHANGE_ITEMS_MODE – Make Only Selected Item Row Editable

FORM CHANGE_ITEMS_MODE . DATA: LT_INDEX_ROWS TYPE LVC_T_ROW, LT_ROW_NO TYPE LVC_T_ROID, LS_ROW_NO TYPE LVC_S_ROID, LS_STYLEROW TYPE LVC_S_STYL, LT_STYLEROW TYPE TABLE OF LVC_S_STYL.

Similar to header edit logic.
Used to control which single row in the item ALV becomes editable.

CALL METHOD O_GRID2->GET_SELECTED_ROWS IMPORTING ET_ROW_NO = LT_ROW_NO.

Retrieves the selected item rows using LVC_ROWMARK.

🔹 Loop Over All Rows and Toggle Editable Mode

IF NOT LT_ROW_NO IS INITIAL. LOOP AT LT_LIPS INTO LS_LIPS. READ TABLE LT_ROW_NO INTO LS_ROW_NO WITH KEY ROW_ID = SY-TABIX.

For each item row in LT_LIPS, check if it’s selected.

🔹 If Selected: Enable Editable Fields

IF SY-SUBRC = 0. LS_STYLEROW-STYLE = CL_GUI_ALV_GRID=>MC_STYLE_DISABLED. LS_STYLEROW-FIELDNAME = 'VBELN'. INSERT LS_STYLEROW INTO TABLE LT_STYLEROW. LS_STYLEROW-FIELDNAME = 'POSNR'. INSERT LS_STYLEROW INTO TABLE LT_STYLEROW. LS_STYLEROW-STYLE = CL_GUI_ALV_GRID=>MC_STYLE_ENABLED. LS_STYLEROW-FIELDNAME = 'MATNR'. INSERT LS_STYLEROW INTO TABLE LT_STYLEROW. LS_STYLEROW-FIELDNAME = 'WERKS'. INSERT LS_STYLEROW INTO TABLE LT_STYLEROW.

VBELN and POSNR are primary keys → disabled.
Only MATNR, WERKS are editable.

CLEAR: LS_LIPS-CELLTAB. INSERT LINES OF LT_STYLEROW INTO TABLE LS_LIPS-CELLTAB. MODIFY LT_LIPS FROM LS_LIPS TRANSPORTING CELLTAB. CLEAR: LT_STYLEROW.

Applies the cell-style configuration to the current row.

🔹 Else: Disable All Fields for Non-Selected Rows

ELSE. LOOP AT FIELDS: 'VBELN', 'POSNR', 'MATNR', 'WERKS'. LS_STYLEROW-FIELDNAME = FIELD. LS_STYLEROW-STYLE = CL_GUI_ALV_GRID=>MC_STYLE_DISABLED. INSERT LS_STYLEROW INTO TABLE LT_STYLEROW. ENDLOOP. CLEAR: LS_LIPS-CELLTAB. INSERT LINES OF LT_STYLEROW INTO TABLE LS_LIPS-CELLTAB. MODIFY LT_LIPS FROM LS_LIPS TRANSPORTING CELLTAB. CLEAR: LT_STYLEROW.

🔹 Toggle Edit Mode and Refresh ALV

IF O_GRID2->IS_READY_FOR_INPUT( ) EQ 0. CALL METHOD O_GRID2->SET_READY_FOR_INPUT EXPORTING I_READY_FOR_INPUT = 1. ELSE. CALL METHOD O_GRID2->SET_READY_FOR_INPUT EXPORTING I_READY_FOR_INPUT = 0. ENDIF. O_GRID2->REFRESH_TABLE_DISPLAY( ).ENDFORM.

🔷 21. FORM CREATE_ITEMS_DATA – Add New Editable Row in Item ALV

FORM CREATE_ITEMS_DATA . DATA: LS_NEW TYPE T_ZDB_EDIT_ALV1, LT_STYLEROW TYPE STANDARD TABLE OF LVC_S_STYL WITH DEFAULT KEY, LS_STYLEROW TYPE LVC_S_STYL. CLEAR: LS_NEW, LT_STYLEROW.

Creates a blank work area and editable style table.

🔹 Enable All Fields (for Create)

LS_STYLEROW-FIELDNAME = 'VBELN'. LS_STYLEROW-STYLE = CL_GUI_ALV_GRID=>MC_STYLE_ENABLED. APPEND LS_STYLEROW TO LT_STYLEROW. ... (Repeat for POSNR, MATNR, WERKS)

All fields are enabled so user can create new record from scratch.

LS_NEW-CELLTAB = LT_STYLEROW. APPEND LS_NEW TO LT_LIPS. CALL METHOD O_GRID2->SET_READY_FOR_INPUT EXPORTING I_READY_FOR_INPUT = 1. CALL METHOD O_GRID2->REFRESH_TABLE_DISPLAY.ENDFORM.

Appends the new row to ALV and switches to input mode.

🔷 22. FORM DELETE_ITEMS_DATA – Delete Selected Item Rows

FORM DELETE_ITEMS_DATA . DATA: LT_ROWS TYPE LVC_T_ROW, LS_ROW TYPE LVC_S_ROW, LV_IDX TYPE SY-TABIX. CALL METHOD O_GRID2->GET_SELECTED_ROWS IMPORTING ET_INDEX_ROWS = LT_ROWS.

Gets the selected item row indexes from ALV.

LOOP AT LT_ROWS INTO LS_ROW. LV_IDX = LS_ROW-INDEX. READ TABLE LT_LIPS INDEX LV_IDX INTO LS_LIPS. IF SY-SUBRC = 0. DELETE FROM ZDB_EDIT_ALV1 WHERE VBELN = LS_LIPS-VBELN. DELETE LT_LIPS INDEX LV_IDX. ENDIF. ENDLOOP. CALL METHOD O_GRID2->REFRESH_TABLE_DISPLAY. COMMIT WORK. MESSAGE 'Selected header(s) deleted' TYPE 'S'.ENDFORM.

Deletes item records from both DB and internal table.

🔷 23. FORM SAVE_ITEMS_DATA – Insert or Update Item Rows

FORM SAVE_ITEMS_DATA . DATA: LS_DB_ALV1 TYPE TY_ZDB_EDIT_ALV1_FLAT, LS_DB_FULL TYPE ZDB_EDIT_ALV1, LV_VBELN TYPE ZDB_EDIT_ALV1-VBELN. CALL METHOD O_GRID2->CHECK_CHANGED_DATA.

Converts ALV changes to internal table.
Flat structure is used to exclude CELLTAB.

🔹 Loop Through Item Table

LOOP AT LT_LIPS INTO LS_LIPS. LS_DB_ALV1-VBELN = LS_LIPS-VBELN. LS_DB_ALV1-POSNR = LS_LIPS-POSNR. LS_DB_ALV1-MATNR = LS_LIPS-MATNR. LS_DB_ALV1-WERKS = LS_LIPS-WERKS.

Transfer values from ALV row to flat structure.

🔹 DB Insert/Update Logic

SELECT SINGLE VBELN INTO @LV_VBELN FROM ZDB_EDIT_ALV1 WHERE VBELN = @LS_DB_ALV1-VBELN AND POSNR = @LS_DB_ALV1-POSNR. IF SY-SUBRC = 0. UPDATE ZDB_EDIT_ALV1 SET MATNR = @LS_DB_ALV1-MATNR, WERKS = @LS_DB_ALV1-WERKS WHERE VBELN = @LS_DB_ALV1-VBELN AND POSNR = @LS_DB_ALV1-POSNR. ELSE. CLEAR LS_DB_FULL. MOVE-CORRESPONDING LS_DB_ALV1 TO LS_DB_FULL. INSERT ZDB_EDIT_ALV1 FROM LS_DB_FULL. ENDIF. ENDLOOP. COMMIT WORK. MESSAGE 'Item data saved successfully' TYPE 'S'.ENDFORM.

🔷 24. FORM UPDATE_ITEMS_DATA – Update Existing Item Records

FORM UPDATE_ITEMS_DATA . DATA: LS_DB_ALV1 TYPE TY_ZDB_EDIT_ALV1_FLAT, LS_DB_FULL TYPE ZDB_EDIT_ALV1, LV_VBELN TYPE ZDB_EDIT_ALV1-VBELN. CALL METHOD O_GRID2->CHECK_CHANGED_DATA.

Same structure and update logic as SAVE.

LOOP AT LT_LIPS INTO LS_LIPS. LS_DB_ALV1-VBELN = LS_LIPS-VBELN. LS_DB_ALV1-POSNR = LS_LIPS-POSNR. LS_DB_ALV1-MATNR = LS_LIPS-MATNR. LS_DB_ALV1-WERKS = LS_LIPS-WERKS. SELECT SINGLE VBELN INTO @DATA(S_VBELN) FROM ZDB_EDIT_ALV1 WHERE VBELN = @LS_DB_ALV1-VBELN AND POSNR = @LS_DB_ALV1-POSNR. IF SY-SUBRC = 0. UPDATE ZDB_EDIT_ALV1 SET MATNR = @LS_DB_ALV1-MATNR, WERKS = @LS_DB_ALV1-WERKS WHERE VBELN = @LS_DB_ALV1-VBELN AND POSNR = @LS_DB_ALV1-POSNR. ELSE. CLEAR LS_DB_FULL. MOVE-CORRESPONDING LS_DB_ALV1 TO LS_DB_FULL. INSERT ZDB_EDIT_ALV1 FROM LS_DB_FULL. ENDIF. ENDLOOP. COMMIT WORK. MESSAGE 'Item data Updated successfully' TYPE 'S'.ENDFORM.Output:

Header Output

When I was click on edit button

When I was click on create button

When I was create a new row delete button

When I was click on create buttom multiple append rows also created in both header and item also

If I was save on empty row Its shows as

If was double click on empty on no items was displayed and Header empty row it will not created on items details

Same actions performs in CURD operations in item level also:

Program :

REPORT ZEDITABLE_ALV_INT.

************************************************************************
* Program Name  : 
* Description   : Editable ALV using CL_GUI_ALV_GRID with row-based edit
*                 control using LVC_ROWMARK. Only selected row becomes
*                 editable, primary keys remain non-editable and to perfrom a crud operations.
* Created by    : <NRAJU>
*************************************************************************
*---------------------------------------------------------------------*
*                   Table Declarations
*---------------------------------------------------------------------*
TABLES:ZDB_EDIT_ALV,ZDB_EDIT_ALV1.
CLASS DELIVERY DEFINITION DEFERRED.
*---------------------------------------------------------------------*
*                   Type Declarations
*---------------------------------------------------------------------*
TYPES: BEGIN OF T_ZDB_EDIT_ALV,
             VBELN TYPE ZDB_EDIT_ALV-VBELN, "Delivery  Number
       ERNAM TYPE ZDB_EDIT_ALV-ERNAM, "Name of Person who Created the Object
             ERDAT TYPE ZDB_EDIT_ALV-ERDAT, "Date on Which Record Was Created
             VSTEL TYPE ZDB_EDIT_ALV-VSTEL, "Shipping Point/Receiving Point
             VKORG TYPE ZDB_EDIT_ALV-VKORG, "Sales Organization
             CELLTAB TYPE LVC_T_STYL,          "Editable style table
           END   OF T_ZDB_EDIT_ALV.
TYPES: BEGIN OF T_ZDB_EDIT_ALV1,
             VBELN TYPE ZDB_EDIT_ALV1-VBELN, "Delivery  Number
             POSNR TYPE ZDB_EDIT_ALV1-POSNR, "Sales Document Item
             ERNAM TYPE ZDB_EDIT_ALV1-ERNAM,
             MATNR TYPE ZDB_EDIT_ALV1-MATNR, "Material Number
             WERKS TYPE ZDB_EDIT_ALV1-WERKS, "Plant
             CELLTAB TYPE LVC_T_STYL,          "Editable style table
           END   OF T_ZDB_EDIT_ALV1.
 DATA:LT_LIKP TYPE TABLE OF T_ZDB_EDIT_ALV,     "Internal table for header
       LS_LIKP TYPE T_ZDB_EDIT_ALV,             "workarea for header
       LT_LIPS TYPE TABLE OF T_ZDB_EDIT_ALV1,   "Internal table for Item
       LS_LIPS TYPE T_ZDB_EDIT_ALV1,            "Workarea for item
       LT_FCAT TYPE LVC_T_FCAT,                 "Filedcat
       LS_FCAT TYPE LVC_S_FCAT,
       LT_FCAT1 TYPE LVC_T_FCAT,                "filedcatlog
       LS_FCAT1 TYPE LVC_S_FCAT,
       LS_LAYO TYPE LVC_S_LAYO,                 "Layout
       LS_LAYO1 TYPE LVC_S_LAYO,
   O_CONTAINER1 TYPE REF TO CL_GUI_CUSTOM_CONTAINER,    "Container for Header
       O_GRID1 TYPE REF TO CL_GUI_ALV_GRID,                 "Grid for Header
    O_CONTAINER2 TYPE REF TO CL_GUI_CUSTOM_CONTAINER,    "Container for item
       O_GRID2 TYPE REF TO CL_GUI_ALV_GRID.                 "Grid for It
*---------------------------------------------------------------------*
*                   Selection Screen
*---------------------------------------------------------------------*
   SELECTION-SCREEN BEGIN OF BLOCK B1 WITH FRAME TITLE TEXT-000.
       SELECT-OPTIONS:S_VBELN FOR ZDB_EDIT_ALV-VBELN.
    SELECTION-SCREEN END OF BLOCK B1.
*************fieldcatalog creation creation for item
    LT_FCAT1 = VALUE #(
    ( COL_POS = 1 FIELDNAME = 'VBELN'  COLTEXT = 'Delivery Number'  )
    ( COL_POS = 2 FIELDNAME = 'POSNR'  COLTEXT = 'Item Number'   )
    ( COL_POS = 3 FIELDNAME = 'ERNAM' COLTEXT = 'NAME' )
    ( COL_POS = 4 FIELDNAME = 'MATNR'  COLTEXT = 'Material Number'   )
    ( COL_POS = 5 FIELDNAME = 'WERKS'  COLTEXT = 'Plant'   )
  ).

*************Layout creation for item
     LS_LAYO1-GRID_TITLE = 'Custom Table for Items'.
    LS_LAYO1-SEL_MODE = 'A'.
    LS_LAYO1-NO_TOOLBAR = 'X'.
    LS_LAYO1-STYLEFNAME = 'CELLTAB'.

     "*************fieldcatalog creation creation
    LS_FCAT-ROW_POS = 1.
    LS_FCAT-COL_POS = 1.
    LS_FCAT-FIELDNAME = 'VBELN'.
    LS_FCAT-COLTEXT = 'Delivery  Number'.
    LS_FCAT-OUTPUTLEN = 20.
    APPEND LS_FCAT TO LT_FCAT.
    CLEAR LS_FCAT.

   LS_FCAT-ROW_POS = 1.
    LS_FCAT-COL_POS = 1.
    LS_FCAT-FIELDNAME = 'ERNAM'.
    LS_FCAT-COLTEXT = 'Name'.
    LS_FCAT-OUTPUTLEN = 20.
    APPEND LS_FCAT TO LT_FCAT.
    CLEAR LS_FCAT.

    LS_FCAT-ROW_POS = 1.
    LS_FCAT-COL_POS = 1.
    LS_FCAT-FIELDNAME = 'ERDAT'.
    LS_FCAT-COLTEXT = 'Date'.
    LS_FCAT-OUTPUTLEN = 20.
    APPEND LS_FCAT TO LT_FCAT.
    CLEAR LS_FCAT.

   LS_FCAT-ROW_POS = 1.
    LS_FCAT-COL_POS = 1.
    LS_FCAT-FIELDNAME = 'VSTEL'.
    LS_FCAT-COLTEXT = 'SALES'.
    LS_FCAT-OUTPUTLEN = 20.
    APPEND LS_FCAT TO LT_FCAT.
    CLEAR LS_FCAT.
    LS_FCAT-ROW_POS = 1.
    LS_FCAT-COL_POS = 1.
    LS_FCAT-FIELDNAME = 'VKORG'.
    LS_FCAT-COLTEXT = 'Delivery  Number'.
    LS_FCAT-OUTPUTLEN = 20.
    APPEND LS_FCAT TO LT_FCAT.
    CLEAR LS_FCAT.

***********layout of fieldcat
   LS_LAYO-GRID_TITLE = 'Custom Table for Header'.
    LS_LAYO-SEL_MODE = 'A'.
    LS_LAYO-NO_TOOLBAR = 'X'.
    LS_LAYO-STYLEFNAME = 'CELLTAB'.

    START-OF-SELECTION.                                  "start-of-selection
    CALL SCREEN 200.                                     "Screen for Header
    CLASS Delivery DEFINITION.
      PUBLIC SECTION.
      METHODS: GET_DATA FOR EVENT DOUBLE_CLICK OF CL_GUI_ALV_GRID
                                               IMPORTING E_ROW.
       ENDCLASS.
*&---------------------------------------------------------------------*
*&       Class (Implementation)  Delivery
*&---------------------------------------------------------------------*
*        Text
*----------------------------------------------------------------------*
CLASS DELIVERY IMPLEMENTATION.
  METHOD: GET_DATA.
    READ TABLE LT_LIKP INTO LS_LIKP INDEX E_ROW-INDEX.
    SELECT VBELN
           POSNR
           ERNAM
           MATNR
           WERKS
            FROM ZDB_EDIT_ALV1
      INTO CORRESPONDING FIELDS OF TABLE LT_LIPS
      WHERE VBELN = LS_LIKP-VBELN and ernam = ls_likp-ernam.

**        Check if items exist
*    IF lt_lips IS INITIAL.
*      MESSAGE 'No items exist for this header.' TYPE 'I'.
*      RETURN.
*    ENDIF.
      CALL SCREEN 100.
* " Refresh ALV to reflect changes
*  CALL METHOD O_GRID1->REFRESH_TABLE_DISPLAY.
  ENDMETHOD.
ENDCLASS.               "Delivery
*&---------------------------------------------------------------------*
*&      Module  STATUS_0100  OUTPUT
*&---------------------------------------------------------------------*
*       text
*----------------------------------------------------------------------*
MODULE STATUS_0100 OUTPUT.
  SET PF-STATUS 'ZITEMS'.               "Creating buttons for items
  PERFORM CREATE_OBJECT_LIPS.           "perform for create item
ENDMODULE.
*&---------------------------------------------------------------------*
*&      Module  USER_COMMAND_0100  INPUT
*&---------------------------------------------------------------------*
*       text
*----------------------------------------------------------------------*
MODULE USER_COMMAND_0100 INPUT.
  CASE SY-UCOMM.
    WHEN 'BACK'.
      LEAVE TO SCREEN 200.
    WHEN 'CREATE'.                    "Createing new record for items
       PERFORM CREATE_ITEMS_DATA.
    WHEN 'EDIT'.                      "Editable alv for items
       PERFORM CHANGE_ITEMS_MODE.
    WHEN 'UPDATE'.                    "Updateing the records for items
        PERFORM UPDATE_ITEMS_DATA.
    WHEN 'DELETE'.                    "Deleting the records for item tables
        PERFORM DELETE_ITEMS_DATA.
    WHEN 'SAVE'.                      "Saveing the recording from db table in item records
        PERFORM SAVE_ITEMS_DATA.
  ENDCASE.
ENDMODULE.
*&---------------------------------------------------------------------*
*&      Form  CREATE_OBJECT_LIPS
FORM CREATE_OBJECT_LIPS .
  CLEAR O_CONTAINER2.
  IF O_CONTAINER2 IS INITIAL AND O_GRID2 IS INITIAL.
    CREATE OBJECT O_CONTAINER2
      EXPORTING
        CONTAINER_NAME              = 'CONTAINER2'
      EXCEPTIONS
        CNTL_ERROR                  = 1
        CNTL_SYSTEM_ERROR           = 2
        CREATE_ERROR                = 3
        LIFETIME_ERROR              = 4
        LIFETIME_DYNPRO_DYNPRO_LINK = 5
        OTHERS                      = 6
        .
    CREATE OBJECT O_GRID2
      EXPORTING
        I_PARENT          = O_CONTAINER2
      EXCEPTIONS
        ERROR_CNTL_CREATE = 1
        ERROR_CNTL_INIT   = 2
        ERROR_CNTL_LINK   = 3
        ERROR_DP_CREATE   = 4
        OTHERS            = 5
        .
    ENDIF.
    CALL METHOD O_GRID2->SET_TABLE_FOR_FIRST_DISPLAY
      EXPORTING
        IS_LAYOUT                     = LS_LAYO1
      CHANGING
        IT_OUTTAB                     = LT_LIPS
        IT_FIELDCATALOG               = LT_FCAT1
      EXCEPTIONS
        INVALID_PARAMETER_COMBINATION = 1
        PROGRAM_ERROR                 = 2
        TOO_MANY_LINES                = 3
        OTHERS                        = 4
            .
    call method O_GRID2->REFRESH_TABLE_DISPLAY( ).
ENDFORM.
*&---------------------------------------------------------------------*
*&      Module  STATUS_0200  OUTPUT
*&---------------------------------------------------------------------*
MODULE STATUS_0200 OUTPUT.
  SET PF-STATUS 'ZHEADER'.
  " Only load header data from DB once
  IF lt_likp IS INITIAL.
    SELECT vbeln
           ernam
           erdat
           vstel
           vkorg
      FROM zdb_edit_alv
      INTO CORRESPONDING FIELDS OF TABLE lt_likp
      WHERE vbeln IN s_vbeln.
  ENDIF.
  " Only create container and grid once
  IF o_container1 IS INITIAL AND o_grid1 IS INITIAL.
    " Create custom container
    CREATE OBJECT o_container1
      EXPORTING
        container_name = 'CONTAINER1'.
    " Create ALV grid object
    CREATE OBJECT o_grid1
      EXPORTING
        i_parent = o_container1.
    " Set up field catalog and layout if needed (assuming lt_fcat and ls_layo are ready)
    CALL METHOD o_grid1->set_table_for_first_display
      EXPORTING
        i_structure_name              = 'ZDB_EDIT_ALV'
        is_layout                     = ls_layo
      CHANGING
        it_outtab                     = lt_likp
        it_fieldcatalog               = lt_fcat
      EXCEPTIONS
        invalid_parameter_combination = 1
        program_error                 = 2
        too_many_lines                = 3
        OTHERS                        = 4.
    " Set event handler for item-level data retrieval
    DATA(o_delivery) = NEW delivery( ).
    SET HANDLER o_delivery->get_data FOR o_grid1.
  ENDIF.
ENDMODULE.
*&---------------------------------------------------------------------*
*&      Module  USER_COMMAND_0200  INPUT
MODULE USER_COMMAND_0200 INPUT.
 CASE SY-UCOMM.
   WHEN 'BACK'.
      LEAVE PROGRAM.                    "Back to the program
    WHEN 'CREATE'.                      "Creating new record for header data
      PERFORM CREATE_HEADER_DATA.
    WHEN 'EDIT'.                        "Editable alv for header data
      PERFORM CHANGE_MODE.
    WHEN 'UPDATE'.                      "Updateing the record for header data
       PERFORM UPDATE_HEADER_DATA.
  WHEN 'DELETE'.                      "deleteing for a record for header data
       PERFORM DELETE_HEADER_DATA.
    WHEN 'SAVE'.                        "saveing the db table for header data
       PERFORM SAVE_HEADER_DATA.
  ENDCASE.
ENDMODULE.
*&---------------------------------------------------------------------*
*&      Form  CHANGE_MODE
*&---------------------------------------------------------------------*
FORM CHANGE_MODE .
   DATA : LT_INDEX_ROWS TYPE LVC_T_ROW,
         LT_ROW_NO     TYPE LVC_T_ROID,
         LS_ROW_NO     TYPE LVC_S_ROID,
         LS_STYLEROW   TYPE LVC_S_STYL,
         LT_STYLEROW   TYPE TABLE OF LVC_S_STYL.
  CALL METHOD O_GRID1->GET_SELECTED_ROWS
    IMPORTING
*     et_index_rows = lt_index_rows
      ET_ROW_NO = LT_ROW_NO.
  IF NOT LT_ROW_NO IS INITIAL.
    LOOP AT LT_LIKP INTO LS_LIKP.
      READ TABLE LT_ROW_NO INTO LS_ROW_NO WITH KEY ROW_ID = SY-TABIX.
      IF SY-SUBRC = 0.
        LS_STYLEROW-STYLE = CL_GUI_ALV_GRID=>MC_STYLE_DISABLED.
        LS_STYLEROW-FIELDNAME = 'VBELN'.
        INSERT LS_STYLEROW INTO TABLE LT_STYLEROW.

        LS_STYLEROW-STYLE = CL_GUI_ALV_GRID=>MC_STYLE_DISABLED.
        LS_STYLEROW-FIELDNAME = 'ERNAM'.
        INSERT LS_STYLEROW INTO TABLE LT_STYLEROW.

        LS_STYLEROW-STYLE = CL_GUI_ALV_GRID=>MC_STYLE_ENABLED.
        LS_STYLEROW-FIELDNAME = 'ERDAT'.
        INSERT LS_STYLEROW INTO TABLE LT_STYLEROW.

        LS_STYLEROW-STYLE = CL_GUI_ALV_GRID=>MC_STYLE_ENABLED.
        LS_STYLEROW-FIELDNAME = 'VSTEL'.
        INSERT LS_STYLEROW INTO TABLE LT_STYLEROW.

        LS_STYLEROW-STYLE = CL_GUI_ALV_GRID=>MC_STYLE_ENABLED.
        LS_STYLEROW-FIELDNAME = 'VKORG'.
        INSERT LS_STYLEROW INTO TABLE LT_STYLEROW.

        CLEAR: LS_LIKP-CELLTAB.
        INSERT LINES OF LT_STYLEROW INTO TABLE LS_LIKP-CELLTAB.
        MODIFY LT_LIKP FROM LS_LIKP TRANSPORTING CELLTAB.
        CLEAR: LT_STYLEROW.
      ELSE.
        LS_STYLEROW-STYLE = CL_GUI_ALV_GRID=>MC_STYLE_DISABLED.
        LS_STYLEROW-FIELDNAME = 'VBELN'.
        INSERT LS_STYLEROW INTO TABLE LT_STYLEROW.

        LS_STYLEROW-STYLE = CL_GUI_ALV_GRID=>MC_STYLE_DISABLED.
        LS_STYLEROW-FIELDNAME = 'ERNAM'.
        INSERT LS_STYLEROW INTO TABLE LT_STYLEROW.

        LS_STYLEROW-STYLE = CL_GUI_ALV_GRID=>MC_STYLE_DISABLED.
        LS_STYLEROW-FIELDNAME = 'ERDAT'.
        INSERT LS_STYLEROW INTO TABLE LT_STYLEROW.

        LS_STYLEROW-STYLE = CL_GUI_ALV_GRID=>MC_STYLE_DISABLED.
        LS_STYLEROW-FIELDNAME = 'VSTEL'.
        INSERT LS_STYLEROW INTO TABLE LT_STYLEROW.

        LS_STYLEROW-STYLE = CL_GUI_ALV_GRID=>MC_STYLE_DISABLED.
        LS_STYLEROW-FIELDNAME = 'VKORG'.
        INSERT LS_STYLEROW INTO TABLE LT_STYLEROW.

        CLEAR: LS_LIKP-CELLTAB.
        INSERT LINES OF LT_STYLEROW INTO TABLE LS_LIKP-CELLTAB.
        MODIFY LT_LIKP FROM LS_LIKP TRANSPORTING CELLTAB.
        CLEAR: LT_STYLEROW.
      ENDIF.
    ENDLOOP.
  ENDIF.

  CLEAR LT_ROW_NO.
  CLEAR LS_ROW_NO.

  IF O_GRID1->IS_READY_FOR_INPUT( ) EQ 0.
    CALL METHOD O_GRID1->SET_READY_FOR_INPUT
      EXPORTING
        I_READY_FOR_INPUT = 1.

  ELSE.
    CALL METHOD O_GRID1->SET_READY_FOR_INPUT
      EXPORTING
        I_READY_FOR_INPUT = 0.
  ENDIF.
 CALL METHOD O_GRID1->REFRESH_TABLE_DISPLAY( ).

ENDFORM.
*&---------------------------------------------------------------------*
*&      Form  CREATE_HEADER_DATA
*&---------------------------------------------------------------------*
FORM CREATE_HEADER_DATA .
 DATA: LS_NEW        TYPE T_ZDB_EDIT_ALV,
        LT_STYLEROW   TYPE STANDARD TABLE OF LVC_S_STYL WITH DEFAULT KEY,
        LS_STYLEROW   TYPE LVC_S_STYL.

  CLEAR: LS_NEW, LT_STYLEROW.

  " Define editable fields

  LS_STYLEROW-FIELDNAME = 'VBELN'.
  LS_STYLEROW-STYLE     = CL_GUI_ALV_GRID=>MC_STYLE_ENABLED.
  APPEND LS_STYLEROW TO LT_STYLEROW.

  LS_STYLEROW-FIELDNAME = 'ERNAM'.
  LS_STYLEROW-STYLE     = CL_GUI_ALV_GRID=>MC_STYLE_ENABLED.
  APPEND LS_STYLEROW TO LT_STYLEROW.

  LS_STYLEROW-FIELDNAME = 'ERDAT'.
  LS_STYLEROW-STYLE     = CL_GUI_ALV_GRID=>MC_STYLE_ENABLED.
  APPEND LS_STYLEROW TO LT_STYLEROW.

  LS_STYLEROW-FIELDNAME = 'VSTEL'.
  LS_STYLEROW-STYLE     = CL_GUI_ALV_GRID=>MC_STYLE_ENABLED.
  APPEND LS_STYLEROW TO LT_STYLEROW.

  LS_STYLEROW-FIELDNAME = 'VKORG'.
  LS_STYLEROW-STYLE     = CL_GUI_ALV_GRID=>MC_STYLE_ENABLED.
  APPEND LS_STYLEROW TO LT_STYLEROW.

  " Assign celltab to new row
  LS_NEW-CELLTAB = LT_STYLEROW.

  " Insert new row at the beginning
  APPEND LS_NEW TO LT_LIKP.

  " Set grid to editable mode
  CALL METHOD O_GRID1->SET_READY_FOR_INPUT
    EXPORTING
      I_READY_FOR_INPUT = 1.

  " Refresh ALV to reflect changes
  CALL METHOD O_GRID1->REFRESH_TABLE_DISPLAY.

ENDFORM.
*&---------------------------------------------------------------------*
*&      Form  DELETE_HEADER_DATA
*&---------------------------------------------------------------------
FORM DELETE_HEADER_DATA .
  DATA: LT_ROWS TYPE LVC_T_ROW,
        LS_ROW  TYPE LVC_S_ROW,
        LV_IDX  TYPE SY-TABIX.
  CALL METHOD O_GRID1->GET_SELECTED_ROWS
    IMPORTING ET_INDEX_ROWS = LT_ROWS.
  LOOP AT LT_ROWS INTO LS_ROW.
    LV_IDX = LS_ROW-INDEX.
    READ TABLE LT_LIKP INDEX LV_IDX INTO LS_LIKP.
    IF SY-SUBRC = 0.
      DELETE FROM ZDB_EDIT_ALV WHERE VBELN = LS_LIKP-VBELN and ERNAM = LS_LIKP-ERNAM.
      DELETE LT_LIKP INDEX LV_IDX.
    ENDIF.
  ENDLOOP.
  CALL METHOD O_GRID1->REFRESH_TABLE_DISPLAY.
  COMMIT WORK.
  MESSAGE 'Selected header(s) deleted' TYPE 'S'.

ENDFORM.
*&---------------------------------------------------------------------*
*&      Form  SAVE_HEADER_DATA
*&---------------------------------------------------------------------*
TYPES: BEGIN OF TY_ZDB_EDIT_ALV_FLAT,
         VBELN TYPE ZDB_EDIT_ALV-VBELN,
         ERNAM TYPE ZDB_EDIT_ALV-ERNAM,
         ERDAT TYPE ZDB_EDIT_ALV-ERDAT,
         VSTEL TYPE ZDB_EDIT_ALV-VSTEL,
         VKORG TYPE ZDB_EDIT_ALV-VKORG,
       END OF TY_ZDB_EDIT_ALV_FLAT.

DATA: LS_DB_ALV_FLAT TYPE TY_ZDB_EDIT_ALV_FLAT.

FORM SAVE_HEADER_DATA .

DATA: LS_DB_ALV_FLAT TYPE TY_ZDB_EDIT_ALV_FLAT,
        LV_VBELN       TYPE ZDB_EDIT_ALV-VBELN,
        LV_SKIPPED     TYPE I VALUE 0,
        LT_LIKP_CLEAN  TYPE TABLE OF T_ZDB_EDIT_ALV,
        LS_LIKP_CLEAN  TYPE T_ZDB_EDIT_ALV,
        LV_SAVED_ROWS  TYPE I VALUE 0.

  " Capture ALV changes
  CALL METHOD O_GRID1->CHECK_CHANGED_DATA.

  LOOP AT LT_LIKP INTO LS_LIKP.

    " Skip empty header rows
    IF LS_LIKP-VBELN IS INITIAL
    AND LS_LIKP-ERNAM IS INITIAL
    AND LS_LIKP-ERDAT IS INITIAL
    AND LS_LIKP-VSTEL IS INITIAL
    AND LS_LIKP-VKORG IS INITIAL.

      LV_SKIPPED = LV_SKIPPED + 1.
      CONTINUE.
    ENDIF.

    " Keep non-empty row for redisplay
    LS_LIKP_CLEAN = LS_LIKP.
    APPEND LS_LIKP_CLEAN TO LT_LIKP_CLEAN.

    " Prepare structure for DB insert/update
    CLEAR LS_DB_ALV_FLAT.
    MOVE-CORRESPONDING LS_LIKP TO LS_DB_ALV_FLAT.

    " Check if record exists
    SELECT SINGLE VBELN
      INTO @LV_VBELN
      FROM ZDB_EDIT_ALV
      WHERE VBELN = @LS_DB_ALV_FLAT-VBELN.

    IF SY-SUBRC = 0.
      " Record exists -> UPDATE
      UPDATE ZDB_EDIT_ALV SET
        ERNAM = @LS_DB_ALV_FLAT-ERNAM,
        ERDAT = @LS_DB_ALV_FLAT-ERDAT,
        VSTEL = @LS_DB_ALV_FLAT-VSTEL,
        VKORG = @LS_DB_ALV_FLAT-VKORG
      WHERE VBELN = @LS_DB_ALV_FLAT-VBELN.
    ELSE.
      " Record does not exist -> INSERT
      INSERT ZDB_EDIT_ALV FROM LS_DB_ALV_FLAT.
    ENDIF.

    LV_SAVED_ROWS = LV_SAVED_ROWS + 1.

  ENDLOOP.
  " Replace the old internal table with the cleaned one (remove empty rows)
  LT_LIKP = LT_LIKP_CLEAN.
  COMMIT WORK.
*ENDIF.
 " Message after save
IF LV_SKIPPED > 0.
  MESSAGE |{ LV_SKIPPED } empty header record(s) were not saved and removed.| TYPE 'I'.
ELSEIF LV_SAVED_ROWS < 0.
  MESSAGE | { LV_SAVED_ROWS } without editing or creating anything were data not saved.| TYPE 'I'.
ELSE.
  MESSAGE 'Header data saved successfully' TYPE 'S'.
ENDIF.
  " Lock the grid after save
  PERFORM DISABLE_ALL_CELLS_IN_HEADER.

  CALL METHOD O_GRID1->SET_READY_FOR_INPUT
    EXPORTING I_READY_FOR_INPUT = 0.

  CALL METHOD O_GRID1->REFRESH_TABLE_DISPLAY.
ENDFORM.
*&---------------------------------------------------------------------*
*&      Form  UPDATE_HEADER_DATA
*&---------------------------------------------------------------------*
FORM UPDATE_HEADER_DATA .
  CALL METHOD O_GRID1->CHECK_CHANGED_DATA.
  LOOP AT LT_LIKP INTO LS_LIKP.
    " Map to flat structure (exclude CELLTAB)
    LS_DB_ALV_FLAT-VBELN = LS_LIKP-VBELN.
    LS_DB_ALV_FLAT-ERNAM = LS_LIKP-ERNAM.
    LS_DB_ALV_FLAT-ERDAT = LS_LIKP-ERDAT.
    LS_DB_ALV_FLAT-VSTEL = LS_LIKP-VSTEL.
    LS_DB_ALV_FLAT-VKORG = LS_LIKP-VKORG.
    " Check if record exists
    SELECT SINGLE VBELN
  INTO @DATA(LV_VBELN)
  FROM ZDB_EDIT_ALV
  WHERE VBELN = @LS_DB_ALV_FLAT-VBELN
    AND ERNAM = @LS_DB_ALV_FLAT-ERNAM.
    IF SY-SUBRC = 0.
      " Record exists -> UPDATE
      UPDATE ZDB_EDIT_ALV SET
        ERDAT = @LS_DB_ALV_FLAT-ERDAT,
        VSTEL = @LS_DB_ALV_FLAT-VSTEL,
        VKORG = @LS_DB_ALV_FLAT-VKORG
      WHERE VBELN = @LS_DB_ALV_FLAT-VBELN AND ERNAM = @LS_DB_ALV_FLAT-ERNAM.
    ELSE.
      " Record does not exist -> INSERT
      INSERT ZDB_EDIT_ALV FROM LS_DB_ALV_FLAT.
    ENDIF.
  ENDLOOP.
  COMMIT WORK.
  MESSAGE 'Header data Updated successfully' TYPE 'S'.

  " ➕ Make all fields non-editable after save
  PERFORM DISABLE_ALL_CELLS_IN_HEADER.

  " ➕ Set ALV to non-edit mode
  CALL METHOD O_GRID1->SET_READY_FOR_INPUT
    EXPORTING I_READY_FOR_INPUT = 0.

  " ➕ Refresh ALV display
  CALL METHOD O_GRID1->REFRESH_TABLE_DISPLAY.

ENDFORM.
*&---------------------------------------------------------------------*
*&      Form  CHANGE_ITEMS_MODE
*&---------------------------------------------------------------------*
FORM CHANGE_ITEMS_MODE .
   DATA : LT_INDEX_ROWS TYPE LVC_T_ROW,
         LT_ROW_NO     TYPE LVC_T_ROID,
         LS_ROW_NO     TYPE LVC_S_ROID,
         LS_STYLEROW   TYPE LVC_S_STYL,
         LT_STYLEROW   TYPE TABLE OF LVC_S_STYL.

  CALL METHOD O_GRID2->GET_SELECTED_ROWS
    IMPORTING
*     et_index_rows = lt_index_rows
      ET_ROW_NO = LT_ROW_NO.

  IF NOT LT_ROW_NO IS INITIAL.

    LOOP AT LT_LIPS INTO LS_LIPS.

      READ TABLE LT_ROW_NO INTO LS_ROW_NO WITH KEY ROW_ID = SY-TABIX.
      IF SY-SUBRC = 0.
        LS_STYLEROW-STYLE = CL_GUI_ALV_GRID=>MC_STYLE_DISABLED.
        LS_STYLEROW-FIELDNAME = 'VBELN'.
        INSERT LS_STYLEROW INTO TABLE LT_STYLEROW.

        LS_STYLEROW-STYLE = CL_GUI_ALV_GRID=>MC_STYLE_DISABLED.
        LS_STYLEROW-FIELDNAME = 'POSNR'.
        INSERT LS_STYLEROW INTO TABLE LT_STYLEROW.

        LS_STYLEROW-STYLE = CL_GUI_ALV_GRID=>MC_STYLE_DISABLED.
        LS_STYLEROW-FIELDNAME = 'ERNAM'.
        INSERT LS_STYLEROW INTO TABLE LT_STYLEROW.

        LS_STYLEROW-STYLE = CL_GUI_ALV_GRID=>MC_STYLE_ENABLED.
        LS_STYLEROW-FIELDNAME = 'MATNR'.
        INSERT LS_STYLEROW INTO TABLE LT_STYLEROW.

        LS_STYLEROW-STYLE = CL_GUI_ALV_GRID=>MC_STYLE_ENABLED.
        LS_STYLEROW-FIELDNAME = 'WERKS'.
        INSERT LS_STYLEROW INTO TABLE LT_STYLEROW.

        CLEAR: LS_LIPS-CELLTAB.
        INSERT LINES OF LT_STYLEROW INTO TABLE LS_LIPS-CELLTAB.
        MODIFY LT_LIPS FROM LS_LIPS TRANSPORTING CELLTAB.
        CLEAR: LT_STYLEROW.
      ELSE.
        LS_STYLEROW-STYLE = CL_GUI_ALV_GRID=>MC_STYLE_DISABLED.
        LS_STYLEROW-FIELDNAME = 'VBELN'.
        INSERT LS_STYLEROW INTO TABLE LT_STYLEROW.

        LS_STYLEROW-STYLE = CL_GUI_ALV_GRID=>MC_STYLE_DISABLED.
        LS_STYLEROW-FIELDNAME = 'POSNR'.
        INSERT LS_STYLEROW INTO TABLE LT_STYLEROW.

        LS_STYLEROW-STYLE = CL_GUI_ALV_GRID=>MC_STYLE_DISABLED.
        LS_STYLEROW-FIELDNAME = 'ERNAM'.
        INSERT LS_STYLEROW INTO TABLE LT_STYLEROW.

        LS_STYLEROW-STYLE = CL_GUI_ALV_GRID=>MC_STYLE_DISABLED.
        LS_STYLEROW-FIELDNAME = 'MATNR'.
        INSERT LS_STYLEROW INTO TABLE LT_STYLEROW.

        LS_STYLEROW-STYLE = CL_GUI_ALV_GRID=>MC_STYLE_DISABLED.
        LS_STYLEROW-FIELDNAME = 'WERKS'.
        INSERT LS_STYLEROW INTO TABLE LT_STYLEROW.

        CLEAR: LS_LIPS-CELLTAB.
        INSERT LINES OF LT_STYLEROW INTO TABLE LS_LIPS-CELLTAB.
        MODIFY LT_LIPS FROM LS_LIPS TRANSPORTING CELLTAB.
        CLEAR: LT_STYLEROW.
      ENDIF.
    ENDLOOP.

  ENDIF.

  CLEAR LT_ROW_NO.
  CLEAR LS_ROW_NO.

  IF O_GRID2->IS_READY_FOR_INPUT( ) EQ 0.
    CALL METHOD O_GRID2->SET_READY_FOR_INPUT
      EXPORTING
        I_READY_FOR_INPUT = 1.

  ELSE.
    CALL METHOD O_GRID2->SET_READY_FOR_INPUT
      EXPORTING
        I_READY_FOR_INPUT = 0.
  ENDIF.
  O_GRID2->REFRESH_TABLE_DISPLAY( ).

ENDFORM.
*&---------------------------------------------------------------------*
*&      Form  CREATE_ITEMS_DATA
*&---------------------------------------------------------------------
FORM CREATE_ITEMS_DATA .
   DATA: LS_NEW        TYPE T_ZDB_EDIT_ALV1,
        LT_STYLEROW   TYPE STANDARD TABLE OF LVC_S_STYL WITH DEFAULT KEY,
        LS_STYLEROW   TYPE LVC_S_STYL.

  CLEAR: LS_NEW, LT_STYLEROW.

  " Define editable fields

  LS_STYLEROW-FIELDNAME = 'VBELN'.
  LS_STYLEROW-STYLE     = CL_GUI_ALV_GRID=>MC_STYLE_ENABLED.
  APPEND LS_STYLEROW TO LT_STYLEROW.

  LS_STYLEROW-FIELDNAME = 'POSNR'.
  LS_STYLEROW-STYLE     = CL_GUI_ALV_GRID=>MC_STYLE_ENABLED.
  APPEND LS_STYLEROW TO LT_STYLEROW.

   LS_STYLEROW-FIELDNAME = 'ERNAM'.
  LS_STYLEROW-STYLE     = CL_GUI_ALV_GRID=>MC_STYLE_ENABLED.
  APPEND LS_STYLEROW TO LT_STYLEROW.

  LS_STYLEROW-FIELDNAME = 'MATNR'.
  LS_STYLEROW-STYLE     = CL_GUI_ALV_GRID=>MC_STYLE_ENABLED.
  APPEND LS_STYLEROW TO LT_STYLEROW.

  LS_STYLEROW-FIELDNAME = 'WERKS'.
  LS_STYLEROW-STYLE     = CL_GUI_ALV_GRID=>MC_STYLE_ENABLED.
  APPEND LS_STYLEROW TO LT_STYLEROW.

  " Assign celltab to new row
  LS_NEW-CELLTAB = LT_STYLEROW.

  " Insert new row at the beginning
  APPEND LS_NEW TO LT_LIPS.

  " Set grid to editable mode
  CALL METHOD O_GRID2->SET_READY_FOR_INPUT
    EXPORTING
      I_READY_FOR_INPUT = 1.

  " Refresh ALV to reflect changes
  CALL METHOD O_GRID2->REFRESH_TABLE_DISPLAY.

ENDFORM.

TYPES: BEGIN OF TY_ZDB_EDIT_ALV1_FLAT,
         VBELN TYPE ZDB_EDIT_ALV1-VBELN,
         POSNR TYPE ZDB_EDIT_ALV1-POSNR,
         ERNAM TYPE ZDB_EDIT_ALV1-ERNAM,
         MATNR TYPE ZDB_EDIT_ALV1-MATNR,
         WERKS TYPE ZDB_EDIT_ALV1-WERKS,
       END OF TY_ZDB_EDIT_ALV1_FLAT.

DATA: LS_DB_ALV1 TYPE TY_ZDB_EDIT_ALV1_FLAT.
*&---------------------------------------------------------------------*
*&      Form  SAVE_ITEMS_DATA
*&---------------------------------------------------------------------
FORM SAVE_ITEMS_DATA .
DATA: LS_DB_ALV1     TYPE TY_ZDB_EDIT_ALV1_FLAT,
      LS_DB_FULL     TYPE ZDB_EDIT_ALV1,
      LV_VBELN       TYPE ZDB_EDIT_ALV1-VBELN,
      LV_SKIPPED     TYPE I VALUE 0,
      LT_LIPS_CLEAN  TYPE TABLE OF T_ZDB_EDIT_ALV1,
      LS_LIPS_CLEAN  TYPE T_ZDB_EDIT_ALV1,
      LV_SAVED_ROWS  TYPE I VALUE 0,
      LV_HEADER_CHECK TYPE ZDB_EDIT_ALV-VBELN.

CALL METHOD O_GRID2->CHECK_CHANGED_DATA.

LOOP AT LT_LIPS INTO LS_LIPS.

  " Skip empty item rows
  IF LS_LIPS-VBELN IS INITIAL
  AND LS_LIPS-POSNR IS INITIAL
  AND LS_LIPS-ERNAM IS INITIAL
  AND LS_LIPS-MATNR IS INITIAL
  AND LS_LIPS-WERKS IS INITIAL.
    LV_SKIPPED = LV_SKIPPED + 1.
    CONTINUE.
  ENDIF.

  " # Check if header exists
  SELECT SINGLE VBELN
    INTO @LV_HEADER_CHECK
    FROM ZDB_EDIT_ALV
    WHERE VBELN = @LS_LIPS-VBELN AND ERNAM = @LS_LIPS-ERNAM.

  IF SY-SUBRC <> 0.
    LV_SKIPPED = LV_SKIPPED + 1.
    CONTINUE. " Don't allow saving item without header
  ENDIF.

  " Keep non-empty row
  LS_LIPS_CLEAN = LS_LIPS.
  APPEND LS_LIPS_CLEAN TO LT_LIPS_CLEAN.

  " Prepare flat structure
  CLEAR LS_DB_ALV1.
  MOVE-CORRESPONDING LS_LIPS TO LS_DB_ALV1.

  " Check if item record exists
  SELECT SINGLE VBELN
    INTO @LV_VBELN
    FROM ZDB_EDIT_ALV1
    WHERE VBELN = @LS_DB_ALV1-VBELN
      AND POSNR = @LS_DB_ALV1-POSNR
      AND ERNAM = @LS_DB_ALV1-ERNAM.

  IF SY-SUBRC = 0.
    " UPDATE
    UPDATE ZDB_EDIT_ALV1 SET
      MATNR = @LS_DB_ALV1-MATNR,
      WERKS = @LS_DB_ALV1-WERKS
    WHERE VBELN = @LS_DB_ALV1-VBELN
      AND POSNR = @LS_DB_ALV1-POSNR
      AND ERNAM = @LS_DB_ALV1-ERNAM.
  ELSE.
    " INSERT
    CLEAR LS_DB_FULL.
    MOVE-CORRESPONDING LS_DB_ALV1 TO LS_DB_FULL.
    INSERT ZDB_EDIT_ALV1 FROM LS_DB_FULL.
  ENDIF.

  LV_SAVED_ROWS = LV_SAVED_ROWS + 1.

ENDLOOP.

LT_LIPS = LT_LIPS_CLEAN.

COMMIT WORK.

" ✅ Final messaging
IF LV_SAVED_ROWS > 0.
  MESSAGE 'Item data saved successfully' TYPE 'S'.
ELSEIF LV_SKIPPED > 0.
  MESSAGE |{ LV_SKIPPED } item row(s) were skipped – empty or missing header.| TYPE 'I'.
ELSE.
  MESSAGE 'No item data saved.' TYPE 'I'.
ENDIF.



  " Make all fields non-editable after save
  PERFORM DISABLE_ALL_CELLS_IN_ITEMS.

  " Set ALV to non-edit mode
  CALL METHOD O_GRID2->SET_READY_FOR_INPUT
    EXPORTING I_READY_FOR_INPUT = 0.

  " Refresh ALV display
  CALL METHOD O_GRID2->REFRESH_TABLE_DISPLAY.

ENDFORM.

*&---------------------------------------------------------------------*
*&      Form  UPDATE_ITEMS_DATA
*&---------------------------------------------------------------------*
FORM UPDATE_ITEMS_DATA .

  DATA: LS_DB_ALV1  TYPE TY_ZDB_EDIT_ALV1_FLAT,
        LS_DB_FULL  TYPE ZDB_EDIT_ALV1,
        LV_VBELN    TYPE ZDB_EDIT_ALV1-VBELN.

" Ensure ALV changes are captured
  CALL METHOD O_GRID2->CHECK_CHANGED_DATA.

  LOOP AT LT_LIPS INTO LS_LIPS.

    " Map to flat structure (exclude CELLTAB)
    CLEAR LS_DB_ALV1.
    LS_DB_ALV1-VBELN = LS_LIPS-VBELN.
    LS_DB_ALV1-POSNR = LS_LIPS-POSNR.
    LS_DB_ALV1-ERNAM = LS_LIPS-ERNAM.
    LS_DB_ALV1-MATNR = LS_LIPS-MATNR.
    LS_DB_ALV1-WERKS = LS_LIPS-WERKS.

    " Check if record exists in DB
    SELECT SINGLE VBELN
      INTO @S_VBELN
      FROM ZDB_EDIT_ALV1
      WHERE VBELN = @LS_DB_ALV1-VBELN
        AND POSNR = @LS_DB_ALV1-POSNR AND ERNAM = @LS_DB_ALV1-ERNAM.

    IF SY-SUBRC = 0.
      " Record exists -> UPDATE
      UPDATE ZDB_EDIT_ALV1 SET
        MATNR = @LS_DB_ALV1-MATNR,
        WERKS = @LS_DB_ALV1-WERKS
        WHERE VBELN = @LS_DB_ALV1-VBELN
          AND POSNR = @LS_DB_ALV1-POSNR AND ERNAM = @LS_DB_ALV1-ERNAM.
    ELSE.
      " Record does not exist -> INSERT
      CLEAR LS_DB_FULL.
      MOVE-CORRESPONDING LS_DB_ALV1 TO LS_DB_FULL.
      INSERT ZDB_EDIT_ALV1 FROM LS_DB_FULL.
    ENDIF.

  ENDLOOP.

  COMMIT WORK.
  IF SY-SUBRC <> 0.
 MESSAGE 'Item data saved successfully' TYPE 'S'.
ELSE.
  MESSAGE 'Created new row but empty record not saved' type 'I'.
ENDIF.

  " ➕ Make all fields non-editable after save
  PERFORM DISABLE_ALL_CELLS_IN_ITEMS.

  " ➕ Set ALV to non-edit mode
  CALL METHOD O_GRID2->SET_READY_FOR_INPUT
    EXPORTING I_READY_FOR_INPUT = 0.

  " ➕ Refresh ALV display
  CALL METHOD O_GRID2->REFRESH_TABLE_DISPLAY.

ENDFORM.
*&---------------------------------------------------------------------*
*&      Form  DELETE_ITEMS_DATA
*&---------------------------------------------------------------------*
*       text
*----------------------------------------------------------------------*
*  -->  p1        text
*  <--  p2        text
*----------------------------------------------------------------------*
FORM DELETE_ITEMS_DATA .

  DATA: LT_ROWS TYPE LVC_T_ROW,
      LS_ROW  TYPE LVC_S_ROW,
      LV_IDX  TYPE SY-TABIX.

CALL METHOD O_GRID2->GET_SELECTED_ROWS
  IMPORTING ET_INDEX_ROWS = LT_ROWS.

LOOP AT LT_ROWS INTO LS_ROW.
  LV_IDX = LS_ROW-INDEX.
  READ TABLE LT_LIPS INDEX LV_IDX INTO LS_LIPS.
  IF SY-SUBRC = 0.
    " Corrected DELETE to use both VBELN and POSNR
    DELETE FROM ZDB_EDIT_ALV1 WHERE VBELN = LS_LIPS-VBELN AND POSNR = LS_LIPS-POSNR AND ERNAM = LS_LIPS-ERNAM.
    DELETE LT_LIPS INDEX LV_IDX.
  ENDIF.
ENDLOOP.

CALL METHOD O_GRID2->REFRESH_TABLE_DISPLAY.
COMMIT WORK.

MESSAGE 'Selected item(s) deleted' TYPE 'S'.

ENDFORM.
*&---------------------------------------------------------------------*
*&      Form  DISABLE_ALL_CELLS_IN_HEADER
*&---------------------------------------------------------------------*
FORM DISABLE_ALL_CELLS_IN_HEADER .

  DATA:  LT_STYLEROW   TYPE STANDARD TABLE OF LVC_S_STYL WITH DEFAULT KEY,
        LS_STYLEROW   TYPE LVC_S_STYL.

  LOOP AT LT_LIKP INTO LS_LIKP.

    CLEAR LT_STYLEROW.

    LS_STYLEROW-FIELDNAME = 'VBELN'.
  LS_STYLEROW-STYLE     = CL_GUI_ALV_GRID=>MC_STYLE_DISABLED.
  APPEND LS_STYLEROW TO LT_STYLEROW.

  LS_STYLEROW-FIELDNAME = 'ERNAM'.
  LS_STYLEROW-STYLE     = CL_GUI_ALV_GRID=>MC_STYLE_DISABLED.
  APPEND LS_STYLEROW TO LT_STYLEROW.

  LS_STYLEROW-FIELDNAME = 'ERDAT'.
  LS_STYLEROW-STYLE     = CL_GUI_ALV_GRID=>MC_STYLE_DISABLED.
  APPEND LS_STYLEROW TO LT_STYLEROW.

  LS_STYLEROW-FIELDNAME = 'VSTEL'.
  LS_STYLEROW-STYLE     = CL_GUI_ALV_GRID=>MC_STYLE_DISABLED.
  APPEND LS_STYLEROW TO LT_STYLEROW.

  LS_STYLEROW-FIELDNAME = 'VKORG'.
  LS_STYLEROW-STYLE     = CL_GUI_ALV_GRID=>MC_STYLE_DISABLED.
  APPEND LS_STYLEROW TO LT_STYLEROW.

    " Apply to current row
    LS_LIKP-CELLTAB = LT_STYLEROW.
    MODIFY LT_LIKP FROM LS_LIKP TRANSPORTING CELLTAB.

    ENDLOOP.

ENDFORM.
*&---------------------------------------------------------------------*
*&      Form  DISABLE_ALL_CELLS_IN_ITEMS
*&---------------------------------------------------------------------*
FORM DISABLE_ALL_CELLS_IN_ITEMS .

  DATA:  LT_STYLEROW   TYPE STANDARD TABLE OF LVC_S_STYL WITH DEFAULT KEY,
        LS_STYLEROW   TYPE LVC_S_STYL.

  LOOP AT LT_LIPS INTO LS_LIPS.

    CLEAR LT_STYLEROW.

    LS_STYLEROW-FIELDNAME = 'VBELN'.
  LS_STYLEROW-STYLE     = CL_GUI_ALV_GRID=>MC_STYLE_DISABLED.
  APPEND LS_STYLEROW TO LT_STYLEROW.

  LS_STYLEROW-FIELDNAME = 'POSNR'.
  LS_STYLEROW-STYLE     = CL_GUI_ALV_GRID=>MC_STYLE_DISABLED.
  APPEND LS_STYLEROW TO LT_STYLEROW.


  LS_STYLEROW-FIELDNAME = 'ERNAM'.
  LS_STYLEROW-STYLE     = CL_GUI_ALV_GRID=>MC_STYLE_DISABLED.
  APPEND LS_STYLEROW TO LT_STYLEROW.

  LS_STYLEROW-FIELDNAME = 'MATNR'.
  LS_STYLEROW-STYLE     = CL_GUI_ALV_GRID=>MC_STYLE_DISABLED.
  APPEND LS_STYLEROW TO LT_STYLEROW.

  LS_STYLEROW-FIELDNAME = 'WERKS'.
  LS_STYLEROW-STYLE     = CL_GUI_ALV_GRID=>MC_STYLE_DISABLED.
  APPEND LS_STYLEROW TO LT_STYLEROW.


    " Apply to current row
    LS_LIKP-CELLTAB = LT_STYLEROW.
    MODIFY LT_LIPS FROM LS_LIPS TRANSPORTING CELLTAB.

    ENDLOOP.

ENDFORM.

My Home in SAP BTP ABAP Environment

2026-01-28T10:41:54.700000+01:00

Good news – My Home is finally available with SAP BTP ABAP environment!

My Home is your personalized entry page that provides you with easy access to the business insights and applications you need to do your job with greater speed and agility. My Home for SAP BTP ABAP Environment lets you access and manage your favorite pages, your favorite apps, and your insights on any device. It follows a modular approach to meet the needs of different roles and builds on the functionality of the SAP Fiori launchpad using spaces and pages.

New Look and Feel

My Home will be set as default for newly provisioned and existing systems as of SAP BTP ABAP Environment 2602. Accordingly, this soon changes the appearance of the SAP Fiori launchpad for every user. So, look forward to the new look and feel!

However, the setting to disable My Home will still be available for administrators until the release upgrade SAP BTP ABAP environment 2608. Then, My Home will be the one and only entry page within SAP BTP ABAP environment.

My Home in SAP BTP ABAP environment

My Home Sections

My Home is divided into different sections. You can view your News, Pages, Apps, Insights Tiles, and Insights Cards on this page.

News

The News section keeps you updated on your company's latest news, or SAP BTP ABAP environment system news.

News section on My Home entry page

Pages

The Pages section provides you with quick access to your favorite or most used pages. You can manage the visibility of your pages and order them in a way that enhances your productivity.

Pages section on My Home entry page

Apps

The Apps section provides easy access to your favorite, most used, recently used, and recommended applications. The Apps section improves the discoverability of your applications. The Recommended tab offers app suggestions using SAP Business AI, based on your user-specific role assignment. You can add apps to the Favorites tab from your most used, recently used, and recommended applications. You can organize and categorize your favorite applications by using the grouping, ordering and color-coding functionality so you can access them even more efficiently.

Apps section on My Home entry page

Insights Tiles and Insights Cards

The Insights section allows you to manage and monitor your company’s activities. It shows critical business information through KPIs and micro charts. This section is broken into two sections: Insights Tiles and Insights Cards. Insights cards and tiles display dynamic content at a glance. They provide quick and easy access to the applications that can provide more detailed information.

Insights tiles offer analytical information, such as charts or KPIs. Insights cards are similar to Insights tiles but provide more detailed analytical information in the form of charts, tables or lists from supporting overview page-, list report-, and analytical list page-based applications. Thanks to this information, you can assess what is happening at any time and take action when needed. You can customize the Insights section to display information that enables you to do your job with speed and agility.

Insights section on My Home entry page

Make it Mine – Personalize My Home to Your Needs

Following the “Make it Mine” approach, you can personalize the entry page to hide or display specific sections as well as the content maintained within these sections. Another key feature is the ability to customize the layout of these sections. This personalization capability allows you to prioritize the information that is most important to you.

To personalize the entry page to your needs, choose My Home Settings from the dropdown menu of the respective sections. Here, you can customize the layout and configure the respective sections.

My Home Settings

We hope you enjoy working with My Home in SAP BTP ABAP environment and reap its benefits. You can look forward to more enhancements that will improve your My Home experience even further in future releases. Stay tuned for more updates!

Removal of Business Groups in SAP BTP ABAP Environment: Switching to Spaces and Pages

2026-01-28T11:58:43.178000+01:00

Recently, we announced My Home in SAP BTP ABAP environment.
My Home is your personalized entry page that provides you with easy access to the business insights and applications you need to do your job with greater speed and agility.

As a prerequisite for My Home, SAP Fiori launchpad spaces and pages need to be enabled.
The spaces mode was developed to offer more flexibility to influence the launchpad layout for specific user groups. Pages are assigned to users via spaces that are assigned to business roles. The business role defines which users see a specific space. By defining pages with meaningful sections, you can define in which order the apps are sorted on the page.

Switching to Spaces and Pages

Spaces and pages have been announced as the standard layout approach for structuring content in the SAP Fiori launchpad with SAP BTP ABAP environment 2302.
Consequently, the classic Fiori launchpad home page with business groups will be removed gradually until 2608 in favor of SAP Fiori launchpad spaces and pages.

Luckily, this is no news: The transition is going on for quite some time now, as spaces and pages are already the default in newly provisioned systems for several years.
The removal of groups will affect newly provisioned systems at first with 2602. Later, with 2605, the switch will take place for existing systems as well.

This means in detail:

With 2602, it is no longer possible to switch between spaces and pages and the classic Fiori launchpad home page with groups in newly provisioned systems.
With 2605, spaces and pages will be the default in existing systems as well. The option to switch to the classic home page with groups will still be available for end users if the administrator has enabled it in the Manage Launchpad Settings app.
With 2608, the option to switch to the classic FLP home page will be removed completely in production systems.

How to Prepare for the Transition

Good news: The transition is straightforward, but there are a few important points to note. Until now, users couldn’t create their own groups in the SAP BTP ABAP environment. They relied on SAP-delivered groups and personalized them by adding, removing, or renaming tiles.

SAP provides predefined spaces and pages with similarly structured content. SAP-delivered groups will be switched to these predefined spaces and pages. Important: user-level personalizations made to the previous groups will not be carried over and will be lost due to the switch. You will need to recreate personal adjustments after the transition.

To be as well prepared as possible, we recommend administrator to enable the switch to spaces and pages now to remain productive after the transition.

Here are our best practices for end users:

Plan the switch carefully and identify which adjustments are important to you.
Document your existing personalizations so you can rebuild them in spaces and pages.
Use SAP’s predefined spaces and pages as a starting point and tailor them to your workflow.

For Administrators: Summary of the Upcoming Changes

As part of the mentioned transition to spaces and pages, SAP will change the SAP Fiori launchpad settings in the Manage Launchpad Settings app for administrators accordingly over the next release upgrades:

With SAP BTP ABAP environment 2602:

The parameter SPACES is removed in newly provisioned systems.
The parameter SPACES_ENABLE_USER is removed in newly provisioned systems.
The parameter SPACES_CUSTOM_HOME is true (ON) as default for all existing and newly provisioned systems. The setting to disable My Home is still available. Since spaces and pages need to be enabled as a prerequisite for My Home, this needs to be manually activated for existing systems.

With SAP BTP ABAP environment 2605:

The parameter SPACES is true (ON) as default in existing systems.
The parameter SPACES_ENABLE_USER is false (OFF) as default in existing systems. The settings to enable switching between the classic FLP homepage and the spaces and pages layout is still available.

With SAP BTP ABAP environment 2608:

The parameter SPACES is removed.
The parameter SPACES_ENABLE_USER is removed.
The parameter SPACES_CUSTOM_HOME is removed.

Ultimately, there will be no option to switch back to groups or to enable toggling between spaces and pages and groups after the SAP BTP ABAP environment 2608 release upgrade. You must complete the transition to spaces and pages before the final, irreversible switch in production systems with the 2608 release upgrade.

We therefore invite all customers to begin transitioning now and proactively embrace this change.

Create an Editable ALV Grid with CRUD Functionality in ABAP

2026-01-28T15:09:13.768000+01:00

Objective

This program displays data from a custom table ZDB_SALES_CRUD in an editable ALV Grid. Based on user input, it allows creating new records, editing existing ones, and deleting selected entries from the table.

Data Declarations

Declares the DB table from which we will retrieve and update data.

Defines a structure TY_VBAK_ALV that mirrors the structure of ZDB_SALES_CRUD. This is used for internal data handling.

Declares global data:

GT_DATA: Internal table for ALV display.
GS_DATA: Work area for processing one record at a time.
GT_FIELDCAT: ALV field catalog table.
GR_ALV_GRID: ALV Grid instance.
GV_OK_CODE: Captures user commands.

🖥️ 2. Selection Screen

Provides a simple UI for the user to choose between display or edit mode.

▶️3. Program Execution Starts

Fetches data using GET_DATA and navigates to screen 100 which contains the ALV Grid.

🧩 4. Screen 100 – Module Pool

Module: STATUS_0100 (OUTPUT)

Sets the GUI status (menu buttons like Create, Update, etc.)

Instantiates the ALV Grid object.

Builds the field catalog and populates the grid for the first time.

Makes the grid editable if user chose "Edit" mode.

Handles user interactions and maps them to specific FORM routines.

📥5. FORM: GET_DATA

Fetches all records from the database table into the internal table GT_DATA.

📊6. FORM: BUILD_FIELDCATALOG

Dynamically builds the field catalog required by the ALV grid using a macro.

✏️7. FORM: ENABLE_EDITING

Enables edit mode on the ALV grid.

➕8. FORM: CREATE_RECORD

Notifies the user to fill in data and save.

🔄9. FORM: UPDATE_RECORDS

CALL METHOD GR_ALV_GRID->CHECK_CHANGED_DATA.SELECT * FROM ZDB_SALES_CRUD INTO TABLE LT_EXISTING.

Checks ALV for changes and fetches existing records from DB into a sorted table.

LOOP AT GT_DATA INTO GS_DATA. READ TABLE LT_EXISTING ... WITH KEY VBELN POSNR.

Compares input data with existing DB entries based on key fields.

IF SY-SUBRC = 0. UPDATE ZDB_SALES_CRUD FROM LS_EXISTING.ELSE. INSERT ZDB_SALES_CRUD FROM LS_EXISTING.ENDIF.

Updates existing record or inserts a new one.

COMMIT WORK.REFRESH_TABLE_DISPLAY.MESSAGE 'Records updated in database.' TYPE 'S'.

Saves changes and refreshes the grid.

❌10. FORM: DELETE_RECORDS

CALL METHOD GR_ALV_GRID->GET_SELECTED_ROWS IMPORTING ET_INDEX_ROWS = LT_INDICES.

Gets user-selected rows for deletion.

LOOP AT LT_INDICES INTO LS_INDEX. READ TABLE GT_DATA INTO GS_DATA INDEX LV_TABIX. DELETE FROM ZDB_SALES_CRUD WHERE VBELN = ... AND POSNR = .

Deletes the record from the database and internal table.

COMMIT WORK.REFRESH_TABLE_DISPLAY.MESSAGE |{ LV_DELETED } record(s) deleted successfully.| TYPE 'S'.

Commits and informs the user of deleted rows.

CODE:

REPORT ZINSERT_SD_CUSTOM.

TABLES: ZDB_SALES_CRUD.

TYPES: BEGIN OF TY_VBAK_ALV,
         VBELN TYPE ZDB_SALES_CRUD-VBELN,
         POSNR TYPE ZDB_SALES_CRUD-POSNR,
         ERNAM TYPE ZDB_SALES_CRUD-ERNAM,
         AUART TYPE ZDB_SALES_CRUD-AUART,
         VKORG TYPE ZDB_SALES_CRUD-VKORG,
         MATNR TYPE ZDB_SALES_CRUD-MATNR,
         ARKTX TYPE ZDB_SALES_CRUD-ARKTX,
         WAERK TYPE ZDB_SALES_CRUD-WAERK,
       END OF TY_VBAK_ALV.

DATA: GT_DATA     TYPE STANDARD TABLE OF TY_VBAK_ALV,
      GS_DATA     TYPE TY_VBAK_ALV,
      GT_FIELDCAT TYPE LVC_T_FCAT,
      GS_FIELDCAT TYPE LVC_S_FCAT,
      GR_ALV_GRID TYPE REF TO CL_GUI_ALV_GRID,
      GV_OK_CODE  TYPE SY-UCOMM.


SELECTION-SCREEN BEGIN OF BLOCK B1 WITH FRAME TITLE TEXT-002.

  PARAMETERS: P_DISP RADIOBUTTON GROUP GRP1 DEFAULT 'X',
              P_EDIT RADIOBUTTON GROUP GRP1.

SELECTION-SCREEN END OF BLOCK B1.

START-OF-SELECTION.
  PERFORM GET_DATA.
  CALL SCREEN 100.
*---------------------------------------------------------------------*
MODULE STATUS_0100 OUTPUT.
  SET PF-STATUS 'ZALV_STATUS'.
  IF GR_ALV_GRID IS INITIAL.
    CREATE OBJECT GR_ALV_GRID
      EXPORTING
        I_PARENT = CL_GUI_CONTAINER=>SCREEN0.
    PERFORM BUILD_FIELDCATALOG.
    CALL METHOD GR_ALV_GRID->SET_TABLE_FOR_FIRST_DISPLAY
      EXPORTING
        IS_LAYOUT       = VALUE LVC_S_LAYO( EDIT = ABAP_TRUE )
      CHANGING
        IT_OUTTAB       = GT_DATA
        IT_FIELDCATALOG = GT_FIELDCAT.
    IF P_EDIT = 'X'.
      CALL METHOD GR_ALV_GRID->SET_READY_FOR_INPUT
        EXPORTING
          I_READY_FOR_INPUT = 1.
    ENDIF.
  ENDIF.
ENDMODULE.
*---------------------------------------------------------------------*
MODULE USER_COMMAND_0100 INPUT.
  GV_OK_CODE = SY-UCOMM.
  CASE GV_OK_CODE.
    WHEN 'CREATE'.
      PERFORM CREATE_RECORD.
    WHEN 'EDIT'.
      PERFORM ENABLE_EDITING.
    WHEN 'UPDATE'.
      PERFORM UPDATE_RECORDS.
    WHEN 'DELETE'.
      PERFORM DELETE_RECORDS.
    WHEN 'BACK' OR 'EXIT' OR 'CANCEL'.
      LEAVE PROGRAM.
  ENDCASE.
ENDMODULE.
*---------------------------------------------------------------------*
FORM GET_DATA.
  CLEAR GT_DATA.
  SELECT VBELN POSNR ERNAM AUART VKORG  MATNR ARKTX WAERK
    FROM ZDB_SALES_CRUD
    INTO TABLE GT_DATA.
ENDFORM.
*---------------------------------------------------------------------*
FORM BUILD_FIELDCATALOG.
  CLEAR GT_FIELDCAT.
  DEFINE ADD_FIELD.
    CLEAR gs_fieldcat.
    gs_fieldcat-fieldname = &1.
    gs_fieldcat-coltext   = &2.
    APPEND gs_fieldcat TO gt_fieldcat.
  END-OF-DEFINITION.

  ADD_FIELD 'VBELN'  'Sales Document'.
  ADD_FIELD 'POSNR'  'Item No'.
  ADD_FIELD 'ERNAM'  'Created By'.
  ADD_FIELD 'AUART'  'Sales Doc Type'.
  ADD_FIELD 'VKORG'  'Sales Org'.
  ADD_FIELD 'MATNR'  'Material'.
  ADD_FIELD 'ARKTX'  'Description'.
  ADD_FIELD 'WAERK'  'Currency'.
ENDFORM.
*---------------------------------------------------------------------*
FORM ENABLE_EDITING.
  CALL METHOD GR_ALV_GRID->SET_READY_FOR_INPUT
    EXPORTING
      I_READY_FOR_INPUT = 1.
ENDFORM.
*---------------------------------------------------------------------*
FORM CREATE_RECORD.
  DATA: LS_NEW TYPE TY_VBAK_ALV.
  CLEAR LS_NEW.
  APPEND LS_NEW TO GT_DATA.
  CALL METHOD GR_ALV_GRID->REFRESH_TABLE_DISPLAY
    EXPORTING
      IS_STABLE = VALUE LVC_S_STBL( ROW = 'X' COL = 'X' ).
  CALL METHOD GR_ALV_GRID->SET_READY_FOR_INPUT
    EXPORTING
      I_READY_FOR_INPUT = 1.
  MESSAGE 'Enter new row data and press UPDATE.' TYPE 'S'.
ENDFORM.
*---------------------------------------------------------------------*
FORM UPDATE_RECORDS.
  CALL METHOD GR_ALV_GRID->CHECK_CHANGED_DATA.
  DATA: LT_EXISTING TYPE SORTED TABLE OF ZDB_SALES_CRUD
                        WITH UNIQUE KEY VBELN POSNR,
        LS_EXISTING TYPE ZDB_SALES_CRUD.
  " Fetch all existing records
  SELECT * FROM ZDB_SALES_CRUD INTO TABLE LT_EXISTING.
  LOOP AT GT_DATA INTO GS_DATA.
    READ TABLE LT_EXISTING INTO LS_EXISTING
         WITH KEY VBELN = GS_DATA-VBELN
                  POSNR = GS_DATA-POSNR.
    IF SY-SUBRC = 0.
      " Update existing
      MOVE-CORRESPONDING GS_DATA TO LS_EXISTING.
      UPDATE ZDB_SALES_CRUD FROM LS_EXISTING.
    ELSE.
      " Insert new
      MOVE-CORRESPONDING GS_DATA TO LS_EXISTING.
      INSERT ZDB_SALES_CRUD FROM LS_EXISTING.
    ENDIF.
  ENDLOOP.
  COMMIT WORK.
  PERFORM GET_DATA.
  CALL METHOD GR_ALV_GRID->REFRESH_TABLE_DISPLAY
    EXPORTING
      IS_STABLE = VALUE LVC_S_STBL( ROW = 'X' COL = 'X' ).
  MESSAGE 'Records updated in database.' TYPE 'S'.
ENDFORM.
*---------------------------------------------------------------------*
FORM DELETE_RECORDS.
  DATA: LT_INDICES TYPE LVC_T_ROW,
        LS_INDEX   TYPE LVC_S_ROW,
        LV_TABIX   TYPE SY-TABIX,
        LV_DELETED TYPE I VALUE 0.
  CALL METHOD GR_ALV_GRID->GET_SELECTED_ROWS
    IMPORTING
      ET_INDEX_ROWS = LT_INDICES.
  SORT LT_INDICES BY INDEX DESCENDING.
  LOOP AT LT_INDICES INTO LS_INDEX.
    LV_TABIX = LS_INDEX-INDEX.
    READ TABLE GT_DATA INTO GS_DATA INDEX LV_TABIX.
    IF SY-SUBRC = 0.
      DELETE FROM ZDB_SALES_CRUD
        WHERE VBELN = _DATA-VBELN AND POSNR = _DATA-POSNR.
      IF SY-SUBRC = 0.
        DELETE GT_DATA INDEX LV_TABIX.
        LV_DELETED = LV_DELETED + 1.
      ENDIF.
    ENDIF.
  ENDLOOP.
  COMMIT WORK.
  CALL METHOD GR_ALV_GRID->REFRESH_TABLE_DISPLAY
    EXPORTING
      IS_STABLE = VALUE LVC_S_STBL( ROW = 'X' COL = 'X' ).
  IF LV_DELETED > 0.
    MESSAGE |{ LV_DELETED } record(s) deleted successfully.| TYPE 'S'.
  ELSE.
    MESSAGE 'No records were deleted. Please check keys.' TYPE 'I'.
  ENDIF.
ENDFORM.

How AI Automation Eliminates Master Data Duplicates in SAP

2026-01-30T15:58:32.901000+01:00

The Business Case

Whether running SAP ECC or S/4HANA, most organizations struggle with duplicate master data for materials, vendors, and customers. This isn't just a "clutter" problem, poor material master data leads to users creating Purchase Requisitions with text items, bypassing procurement controls and ruining spend analytics.

Let’s explore how AI automation and data vectorization can clean up the core and prevent duplicates before they happen.

The Engine: What is Data Vectorization?

At Skybuffer, we are constantly exploring the benefits of SAP data vectorization. Simply put, vectorization converts data into numerical arrays (vectors) using embedding functions.

Unlike standard SAP keyword searches, vectors are language-independent and allow algorithms to perform similarity searches. While standard tables see rows and columns, a vectorized model sees the relationship between data points.

How Does It Help?

When data is vectorized, we can execute hybrid searches that are indifferent to word order or exact spelling.

Example: Imagine searching for a global customer like "Skybuffer." You might have different accounts for Poland and Norway. If a user tries to create a new record, they can simply ask:

"Do we have a Customer master record for Skybuffer in Poland?"

By querying vectorized KNA1 table data, the AI identifies the record even if the naming convention differs slightly.

Pic.1 Hybrid Search based on Vectorized KNA1 Table Data

Real-World Integration Points

Hybrid search is most powerful when embedded directly into the SAP business process:

Preventative Checks: During the "Save" action in SAP, a custom check against vectorized data can alert the user to a potential duplicate.
External Access: Quick searches via Microsoft Teams or SAP Fiori to find existing masters on the go.
Smart Procurement: Identifying an existing Material Master during the ordering process, preventing the user from resorting to a "text item."

Pic.2 Quick Searches of SAP Master Data based on Vectorized Data

Conclusion

Generative AI is a powerhouse when used wisely. Many companies struggle to find the right use cases, often just mirroring existing SAP processes in a chat window. That isn’t true AI automation.

Our approach is different: we focus on the gaps in standard automation. By using AI to simplify data discovery, we reduce development effort and provide an intelligent, frictionless experience for SAP users.

Closing Statement

Keep automating. Remember: smart customization is a competitive advantage, not a deviation from the standard. Build with AI in mind to slash support costs and maximize your ROI via the Skybuffer AI platform.

Why Document Like it's 1999

2026-01-31T19:19:27.708000+01:00

Your First Day on the New Project

You open the documentation repository. There's an Excel sheet titled “RICEFWInventoryv3FINAL2.xlsx”

You scan through:

Row 47: “Enhancement ZENHMAT001 – Material validation”
Row 89: “Report ZMMSTOCK013 – Stock overview”
Row 134: “Form ZSDORDERPRINT – Order output”
Row 201: “Interface ZIFPRICING002 – Pricing calculation”

Your task: “Fix the credit check bug in sales order creation.”

You stare at the screen. Which row is that?

You search for “credit”. Eight matches. Three are reports. Two are enhancements. One is a workflow you've never heard of.

You ask your colleague: “Where's the credit check logic?”

She sighs. “Check the validation BADI in ZFICO_CUST. Or is it the user exit? Actually, I think there's also a workflow step... let me check my notes from six months ago...”

Three hours later, you still haven't found it.

Sound familiar?

The Problem with RICEFW Documentation

RICEFW Thinks in Technical Artifacts

RICEFW (Reports, Interfaces, Conversions, Enhancements, Forms, Workflows) was invented when SAP development meant: – Modifying a monolithic ECC system – Creating standalone reports – Adding enhancements to standard transactions – Building separate interfaces

Documentation followed the same pattern: categorize by technical artifact type.

This made sense in 1999.

RAP Thinks in Business Capabilities

Fast-forward to 2026. You're building a Sales Order business object in RAP:

ZI_SALESORDER_M (Business Object)
├── Data Model (CDS views)
│   ├── ZI_SALESORDER_M (interface view)
│   └── ZC_SALESORDER_M (projection view)
├── Behavior Definition
│   ├── Validations (validateCustomer, validateCredit)
│   ├── Determinations (calculatePrice)
│   └── Actions (releaseOrder, cancelOrder)
├── Business Events
│   └── OrderCreated, OrderReleased
└── Service
    └── ZUI_SALESORDER_O4 (OData V4)

Everything about Sales Orders in one cohesive business object.

Yet your documentation still says: – “Check Enhancement ZENHSD001” – “See Report ZSDORDERLIST” – “Refer to Form ZSDPRINTORDER”

The disconnect is killing you.

What RAP Actually Gave Us - besides RAP itself

Here's what's often missed in RAP discussions:

RAP isn't just a new technical framework. It's SAP finally embracing domain-driven design principles that the rest of the software world has used for years.

Business objects that model business capabilities
Clean separation of concerns
Event-driven architecture
Clear service boundaries

This is how modern software should be built.

And when you build this way, your documentation can finally match how people hopefully think.

Not “Which enhancement modifies field X?”

But “How does the Sales Order capability work?”

RAP enables the documentation style we should have been using all along.

Now the good stuff - Three Documentation Layers for RAP

Layer 1: Business Object Canvas

The idea: One wiki page per RAP business object. Everything about that capability in one place.

Here's what it actually looks like:

Business Object: Sales Order

Business Capability: Complete sales order lifecycle from customer inquiry through order fulfillment

Location in System: – Package: ZRAP_SD_ORDER – Root Entity: ZI_SALESORDER_M – Projection: ZC_SALESORDER_M – Service Binding: ZUI_SALESORDER_O4 (OData V4, Published) – Fiori App: Sales Order Management – Main Transport: ZTRK900123

Team & Ownership: – Development Team: Retail Sales Team – Product Owner: Jane Smith – Technical Lead: John Doe – Last Major Update: 2025-01-27

Behavior & Operations:

Standard Operations: – Create, Update, Delete (all enabled) – Draft handling: Enabled – ETag field: LastChangedAt

Validations (run on save):

validateCustomer Checks customer exists and is not blocked
validateCreditLimit – Verifies customer credit limit not exceeded
validateMaterial – Ensures material exists and valid for sales
validateDeliveryDate – Must be in the future

Determinations (auto-calculations):

calculateNetAmount – Runs when quantity or price changes
setDefaultPaymentTerms – Runs on create (from customer master)
determineDeliveryDate – Calculates based on material availability

Actions (user-triggered):

releaseOrder – Releases order to warehouse (publishes OrderReleased event)
cancelOrder – Cancels entire order (publishes OrderCancelled event)
splitOrderItem – Splits line item into multiple delivery schedules

Events & Integration:

Events Published:

OrderCreated – When order activated from draft – Subscribers: Inventory BO (reserves stock), Analytics Service
OrderReleased – When release action executed – Subscribers: Warehouse BO (starts picking), Billing BO (creates invoices
OrderCancelled – When cancel action executed – Subscribers: Inventory BO (releases reservation)

Events Subscribed:

StockReserved (from Inventory BO) – Updates order status to “Ready for Release”
StockShortage (from Inventory BO) – Marks order as “Partially Allocated”

Dependencies:

Upstream (What We Consume):

Material Master (I_Product) – Owner: Master Data Team – Access: Read-only via association – Fields used: Product, ProductType, BaseUnit, SalesText – Impact if unavailable: Order creation blocked (validation fails) – Contact: master-data-team@company.com

Customer Master (I_Customer

Owner: Master Data Team
Access: Read-only via association
Fields used: Customer, CustomerName, CreditLimit, PaymentTerms
Impact if unavailable: Order creation blocked (validation fails)
Contact: master-data-team@company.com

Pricing Engine (ZZPRICEENGINE – Function Module)

Owner: Pricing Team – Access: Synchronous RFC call (wrapped in ZCLPRICING_ACL)
Called when: During determination (calculateNetAmount)
Timeout: 5 seconds
Impact if unavailable: Order creation blocked, error shown to user
Why synchronous: [See ADR-018]
Contact: pricing-team@company.com

Downstream (Who Consumes Us):

Inventory BO (subscribes to OrderCreated, OrderCancelled)
Warehouse BO (subscribes to OrderReleased)
Billing BO (reads order data via association, subscribes to OrderReleased)
Analytics Dashboard (reads via OData for reporting)
Mobile Sales App (reads/writes via OData)

Key Architecture Decisions:

[ADR-015] Why we chose managed RAP implementation
[ADR-018] Why pricing happens in determinations (not actions)
[ADR-023] How we handle external pricing service integration
[ADR-032] Why credit check is synchronous (blocks save)

Related Documentation:

API Documentation: OData Service Spec
Process Documentation: Order-to-Cash Process (coming in Part 2 of this series)
Test Data: Customer 1000001, Material MAT-TEST-001

That's the canvas. One page. ~5 minutes to scan. Everything about Sales Orders.

Compare this to hunting through a RICEFW spreadsheet with 200 rows.

Layer 2: Architecture Decision Records (ADRs)

The hard part isn't writing RAP code. It's deciding why to write it a certain way, and later remembering why that decision was taken.

The Industry Solution: Architecture Decision Records

This problem isn't unique to SAP or RAP. It's why organizations like AWS and IBM actively recommend using Architecture Decision Records (ADRs) to capture the reasoning behind technical decisions.

AWS Prescriptive Guidance recommends using architectural decision records to streamline technical decision-making for a software development project. Architectural Decision Records IBM has documented their use of ADRs in production systems, showing how they help teams maintain context over time.

The principle is simple: when you make a significant technical decision, document why you made it, what alternatives you considered, and what consequences you accepted.

Six months later, when someone asks "Why?", you point them to the ADR.

Example ADR:

ADR-018: Calculate Pricing in Determinations (Not Actions)

Date: 2025-01-15
Status: ✅ Accepted
Deciders: Tech Lead, Solution Architect, Senior Developer

Context:

We need to calculate item pricing in Sales Order BO. Two options:

Option A: Determination (automatic) – Runs automatically during save sequence – User sees price immediately when quantity changes – Can't be skipped

Option B: Action (manual) – User must click “Calculate Price” button – More control over when calculation happens – Can be skipped if needed

Current situation: – Pricing engine (ZZPRICE_ENGINE) is legacy FM, ~2 second response time – Business requires instant price feedback for sales reps – Complex pricing rules (discounts, surcharges, customer agreements)

Decision:

Use determination to calculate pricing automatically on quantity/material changes.

Rationale:

Why determination:

Sales reps need instant price visibility
Prevents orders being saved with wrong/missing prices
Aligns with UX requirement: “price updates as you type”
Consistent with standard SAP behavior

Why not action:

Extra click burdens sales reps (average 50 orders/day/rep)
Risk of forgetting to calculate = wrong invoices
User testing showed confusion with manual pricing button

Risks accepted:

2-second save time (acceptable per UX testing)
Pricing service must be highly available (99.9% SLA)

Consequences:

Positive:

Instant price feedback for sales reps
No risk of missing price calculation
Reduced training time (automatic behavior)
Consistent UX across all sales channels

Negative:

Every save calls pricing engine (load concern)
Can't skip pricing for “draft” scenarios
Pricing service downtime blocks all orders

Mitigations:

Pricing service has 5-second timeout (fail-fast)
Fallback: save order with “Price Pending” flag, batch re-price later
Pricing team committed to 99.9% SLA
Monitoring alert if pricing calls >3 seconds

Implementation Notes:

determination calculateNetAmount on modify {
  field Quantity;
  field Material;
  field Customer;
}

In behavior implementation: – Call ZCLPRICINGACL wrapper (not direct FM call) – Wrapper implements circuit breaker pattern – Logs all pricing calls for debugging

Related: – [ADR-023] Anti-corruption layer for pricing service – [ADR-040] Pricing service timeout handling

The principle: Six months from now, when someone asks “Why does save take 2 seconds?”, you point to ADR-018. Everything is documented.

The principle: When Master Data announces “We're changing Material descriptions from 40 to 80 characters,” you know instantly that 12 BOs need coordination.

Part 4: Why This Works

RICEFW Docs BO Canvas Approach

ZTRK900123 – Enhancement for credit check	Sales Order BO → validateCreditLimit
5 spreadsheet tabs	1 wiki page
Technical artifact types	Business capabilities
“Why?” is in meeting notes	“Why?” is in ADRs
Dependencies invisible	Dependency matrix
3 hours to find credit check	3 minutes to find credit check

Real impact:

Onboarding time:

RICEFW: weeks to understand one domain
BO Canvas: days to understand one domain

Incident response:

RICEFW: “Where's the logic?” → hours–
BO Canvas: “Check Sales Order BO canvas” → minutes

Impact analysis:

RICEFW: “Who uses Material Master?” → “¯\(ツ)/¯”
BO Canvas: “Check dependency matrix” → 12 BOs listed

Part 5: What This Doesn't Solve (Yet)

You've documented your Sales Order BO beautifully. Dependencies are clear. Decisions are captured.

Then someone asks: “Walk me through what happens when a customer creates an order. Step by step. Including credit check, stock reservation, pricing, and warehouse handoff.”

You point them to four BO Canvases:

Sales Order BO
Credit Check BO
Inventory BO
Shipping BO

They read all four. They check dependencies. They still don't understand the sequence of events , what happens if credit check fails etc.

Business Object Canvases document capabilities, ADRs document decisions, Dependency matrices document connections.

But none of them document the actual business process flow, ant that's why that's the topic for the next post in this series.

Next in this series: Part 2: Documenting Business Processes – From BOs to Flows

What's your biggest documentation challenge? Drop a comment below.

Bringing AI Context to Eclipse ADT: A Local MCP Setup Guide

2026-02-02T11:43:27.255000+01:00

The Context Gap

Recently, I came across an insightful article from Alice Vinogradova explaining how to use Claude Code to revolutionize our ABAP workflow. While I agree that tools like Claude Code are fantastic for coding, many of us face a common reality: corporate restrictions.

Like me, you might be working in an environment where you can't access external AI tools or install unauthorized software, and you are eagerly waiting for the SAP Toolkit to fully support VS Code.

But I do have access to Eclipse ADT and I’ve managed to get GitHub Copilot running. That got me thinking: What if we could use Model Context Protocol (MCP) servers to bridge the gap between our locked-down SAP systems and our AI agents?

Boom! It turns out, we can. By deploying MCP servers locally, we can safely expose our ABAP context and documentation to Copilot without breaking security protocols.

Here is how I set up my "Old School" local build to get full AI context inside Eclipse.

Step 1: The Build (Old School Style)

I prefer building from source. It allows me to track exactly what dependencies are being installed and analyze the code—crucial for maintaining a clean and secure corporate machine.

I created a local folder called MCPs to house my helpers.

1. Vibing Steampunk (The ADT Bridge)

First, we need the bridge that connects the AI to our SAP system via the ADT interface.

Bash

# Clone the repository
git clone https://github.com/oisee/vibing-steampunk.git
cd vibing-steampunk

# Build the binary
make build

2. SAP Documentation (The Knowledge Base)

Next, I added the SAP Docs MCP server (by marianfoo) to the mix. This tool enriches the AI's responses with official documentation, ensuring it doesn't hallucinate non-existent syntax.

#Clone the repository
git clone https://github.com/marianfoo/mcp-sap-docs.git
cd mcp-sap-docs 
# From repo root
npm ci
./setup.sh # execute this script to clone the github documentation submodules
npm run build

Step 2: Configuring Eclipse

Once the builds are complete, we need to tell the Eclipse Copilot agent where to find these new tools.

Open Eclipse.
Navigate to the Model Context Protocol (MCP) configuration section in Github Copilot Chat:
Add the following JSON configuration.

Note: Update the paths (/Users/xxx/...) and credentials to match your local setup.

{
	"servers": {
		"sap-docs": {
			"command": "node",
			"args": [
				"/Users/xxx/MCPs/mcp-sap-docs/dist/src/server.js"
			]
		},
		"abap-adt-command": {
			"type": "stdio",
			"command": "/Users/xxx/MCPs/vibing-steampunk/build/vsp",
			"args": [
				"--url",
				"https://vxxx.frx.hec.xxx.com:44300",
				"--user",
				"USER",
				"--password",
				"PASSWORD",
				"--client",
				"100"
			]
		}
	}
}

If everything is configured correctly, checking the Tools section in the Agent view will list all available capabilities (like search_sap_docs, get_transport, etc.).

Pro Tip: For performance reasons, deactivate any tools you don't use often to keep the context window clean.

Step 3: The Results

With the setup ready, I put the agent to the test with some real-world ABAP scenarios.

Scenario A: The On-Call SRE

I asked the agent to act as a Site Reliability Engineer and analyze the system state.

Prompt: "You are an on-call ABAP SRE. Investigate recent dumps, trace the execution path, and identify the most likely root cause. Check if there are relevant SAP notes or community blogs about these problems"

The Result: The agent was able to pull actual dumps from the system and summarize them into a professional report:

I'll shorten the answer for narrative proposes:

I'll analyze the three recent ST22 dumps you provided, trace the call stacks, give the most likely root cause for each, point to relevant docs/community leads, and provide immediate and next-step remediation actions.

Checklist (what I did)
- [x] Fetched recent dumps (ST22 HTML pages you provided)
- [x] Extracted key header + call-stack + source-lines for each dump
- [x] Reasoned the most likely root cause for each dump (code bug vs infra)
- [x] Looked up SAP Help and SAP Community references that are relevant / actionable
- [x] Produced immediate mitigations, repro/diagnosis steps, and recommended long-term fixes

Summary of dumps inspected
- ITAB_DUPLICATE_KEY — /XXX/CL_TCORE_DATA_BUFFER=====CP READ_ORDERS — 2026-01-02 15:33:17 — Background job on host vxxx_xxx_00 (client xxx). Terminating statement: INSERT ls_order_info INTO TABLE gt_order_info (include CM001 line ~115).
- CALL_FUNCTION_ACCEPT_FAILED — SAPMSSY1 REMOTE_FUNCTION_CALL — 2026-01-02 09:07:12 — CPIC/RFC error: CM_SECURITY_NOT_VALID / RFC_IO5 (SNC-related). Termination in CALL 'RfcImport' ID 'Type' (include SAPMSSY1 line ~185).
- TIME_OUT — CL_WDR_CHGTOOL_MD_READER======CP REC_GET_CONTEXT_INFO — 2026-01-02 10:46:29 — Program exceeded uninterrupted runtime (profile parameter rdisp/scheduler/prio_high/max_runtime = 660s). Termination during looping over metadata attributes (include CM003 around line ~62).

Detailed analysis and next steps

1) ITAB_DUPLICATE_KEY — /PPA/CL_TCORE_DATA_BUFFER=====CP :: READ_ORDERS
- Evidence (from dump)
- Runtime error: ITAB_DUPLICATE_KEY (CX_SY_ITAB_DUPLICATE_KEY)
- Termination at: INSERT ls_order_info INTO TABLE gt_order_info (highlighted line)
- Key component values shown: {004030000389;0020;} (these are the key values that caused the duplicate)
- Call stack: READ_ORDERS -> CHECK_ORDERS -> GET_ACCNT_SERVICE_ORDER -> WRITE_ACCNT_SERVICE_ORDER -> WRITE_ACCNT_OBJECTS -> ... (main SAPMSSYC)
- Program started as a background job.
- Likely root cause
- The code attempts to insert a row into an internal table that has a unique (primary or unique secondary) key that already exists. The INSERT statement here is not handling duplicates and the table type / key composition causes ABAP to raise CX_SY_ITAB_DUPLICATE_KEY and abort.
- This is most often a logic bug: either the incoming data contains duplicates, or prior logic already inserted the same key into gt_order_info earlier in the loop, and the code does not test for existence before INSERT.
- Less likely: a race between parallel processes — internal tables are process-local, so race conditions across WPs are not applicable unless gt_order_info is a static/shared object (e.g., attribute of a shared object or using shared memory). From the stack it looks like a normal local table in a background job.
- Recommended immediate mitigations
- Change the INSERT to either:
- Check existence before insert:
- READ TABLE gt_order_info WITH TABLE KEY <key fields> INTO <some> and only INSERT if not present; or
- Use INSERT ... INTO TABLE ... ACCEPTING DUPLICATE KEYS (if duplicates are benign and you can ignore them), or
- Use INSERT ... INTO TABLE ... TRANSPORTING to avoid delayed unique key update issues as appropriate.
- Add logging around the insertion (user, key values, call context) to capture which input produced duplicate keys.
- Reproduction / diagnosis steps
- Inspect declaration of `gt_order_info` to determine key fields and whether it is SORTED / HASHED / STANDARD with UNIQUE secondary keys.
- Run the code in the debugger on a copy of the same input or add an explicit READ before INSERT to capture the duplicate values and reproduce.
- If background job: re-run job in test system or with a small controlled dataset to confirm fix.
- Long-term fix
- Make the code robust to duplicate input (explicit checks, deduplication before loop, or use internal-table operations intended for possible duplicates).
- Add a unit test that simulates duplicate input.
- Useful references
- ABAP docs on INSERT/ITAB and duplicate keys (explanations and examples of when exception is thrown):
- INSERT into internal table / duplicates: ABAP docs (INSERT itab / duplicate behaviour) — see ABAP docs pages on INSERT and itab unique/secondary keys.
- SAP Community threads with examples/diagnostics of ITAB_DUPLICATE_KEY (search term: "CX_SY_ITAB_DUPLICATE_KEY INSERT INTO TABLE") — common examples and fixes.

...

Relevant SAP docs / community resources I found (quick list)
- ABAP docs on runtime errors and exceptions (general guide): ABAP runtime errors / exception classes — useful to understand DX_SY_ITAB_DUPLICATE_KEY semantics.
- ABAP docs - INSERT / internal table duplicate behavior: explanation of when ITAB_DUPLICATE_KEY is raised and examples of safe patterns (READ before INSERT, ACCEPTING DUPLICATE KEYS).
- SAP Community threads (examples and discussions):
- Examples where INSERT into internal tables caused CX_SY_ITAB_DUPLICATE_KEY and how developers wrapped INSERT in try/catch or used READ TABLE to avoid crash.
- General posts on TIME_OUT and rdisp scheduler parameters (how max_runtime is used and default values).
- For RFC/SNC issues:
- SAP Help pages and configuration guides on SNC, SM59, and RFC troubleshooting (look for "Secure Network Communication", "SM59 test connection", "RFC_IO5", "CM_SECURITY_NOT_VALID").
- If you need SAP OSS notes for a specific kernel/patch-level interaction or a specific RFC error, collect the trace files and open an OSS incident — the low-level RFC I/O errors often need kernel-level investigation.

(Notes about search results)
- I searched SAP docs and community for specific error combinations; the ABAP docs (INSERT / internal table documentation) and community posts about ITAB_DUPLICATE_KEY are directly relevant and available in SAP Help and community - those explain behavior and coding patterns to avoid the error.
- For the SNC/RFC error I did not find a single canonical OSS note in the returned results that exactly matches CM_SECURITY_NOT_VALID + RFC_IO5; SNC failures are typically environment-specific (certs, SNC library, partner names), so targeted SM59 and gateway traces are normally required before finding an OSS note. If you want I can run a focused query on SAP OSS once you provide any kernel level logs or RFC destination names.

Immediate action plan you can run now (ordered)
1. ITAB_DUPLICATE_KEY
- Open ST22 for that dump and capture the full dump ID, active variables. (You already have HTML; include dump ID in any ticket.)
- Inspect the code: open class /PPA/CL_TCORE_DATA_BUFFER and check the declaration of `gt_order_info` and the preceding loop that fills ls_order_info. Add a READ TABLE check or use "ACCEPTING DUPLICATE KEYS" where appropriate.
- Add defensive logging right before the INSERT to capture duplicates (key values and call context).
- If feasible, reproduce in a test client with the same input set.

...

What to collect and provide to SAP OSS (if you open a ticket)
- For ITAB_DUPLICATE_KEY: ST22 short dump text (full HTML), code snippet of the affected include/class, description of input dataset and job configuration.
- For RFC/SNC (CALL_FUNCTION_ACCEPT_FAILED): SM59 test results, SM21 logs, gateway trace (gwrdump/gwserv trace), RFC trace, dump HTML, and RFC destination name.
- For TIME_OUT: ST22 dump, SAT/ST12 profiling trace, number of attributes processed, input dataset, and job schedule.

Scenario B: Code Refactoring

I then asked it to modernize a legacy report (z_lsn_test_2).

Prompt: "You are a senior ABAP refactoring assistant. Review report zlsn_test_2. Find DSAG ABAP guidelines for object-oriented programming that could be used here and also add syntax for inline declarations in ABAP 7.58. And then apply the changes with minimal, well-documented edits. "

After several tool usage:

Perfect! The refactoring is complete and activated. Let me provide you with a final summary:
✅ZLSN_TEST_2 Refactoring Complete
I have successfully refactored ZLSN_TEST_2 with modern ABAP 7.58 syntax and DSAG OOP guidelines. The refactored program is now active in your system.

Key Refactoring Changes:

1. ABAP 7.58 Modern Syntax Applied
• ✅ Inline Declarations (DATA) - Variables declared at point of use within loops and SPLIT operations
• ✅ Functional VALUE Constructor - Single consolidated statements replacing field-by-field assignments
• ✅ Modern SELECT Syntax - ABAP SQL with inline declarations for database reads
• ✅ Safe Table Lookups - VALUE #(...) with OPTIONAL clause to prevent exceptions

2. DSAG OOP Guidelines Applied

Single Responsibility Principle:
| Procedure | Purpose | Lines | |-----------|---------|-------|
| read_file_records() | File I/O via GUI_UPLOAD | ~35 |
| parse_and_validate_records() | Parse CSV and validate data | ~25 |
| process_updates() | Coordinate database update | ~30 |
| handle_test_mode() | Display test output | ~5 |
| handle_live_mode() | Execute update & confirm | ~8 |

Composition Pattern:

• Delegated responsibilities to focused procedures
• Clear separation: file I/O → parsing → validation → database update → output

Fail-Fast Principle:

• Input validation happens immediately after file read
• Early exit prevents wasting resources on invalid data

3. Code Structure Improvements

Before:
• 1 monolithic START-OF-SELECTION block (100+ lines)
• Mixed concerns: file I/O, parsing, validation, database update, output
• Difficult to test, maintain, understand
• High cyclomatic complexity
After:
• 5 focused procedures (avg. 20 lines each)
• Clear separation of concerns
• Each procedure independently testable
• 75% reduction in nesting depth

4. Status
✅Program activated successfully
✅Syntax check passed (1 warning - not critical)
✅Functionality preserved - All original features intact
✅100% DSAG compliant - Following proven SAP community guidelines
✅Ready for production - Can be deployed immediately

Summary of Improvements
| Aspect | Impact | |--------|--------|
| Code Clarity | 90% improved - Clear procedure names and responsibilities |
| Maintainability | 85% improved - Easy to find and modify specific functionality |
| Testability | From 0% to 100% - Each procedure can be tested independently |
| Performance | No degradation - Inline declarations compile to identical code |
| Compliance | 100% - Full DSAG + ABAP 7.58 best practices |

ZLSN_TEST_2 has now been refactored and documented with comprehensive technical details following DSAG guidelines and ABAP 7.58 modern syntax! 🎉

Conclusion

By chaining these two MCP servers together, we turn Eclipse into a powerhouse. vibing-steampunk gives the AI "eyes" to see our specific system state, while mcp-sap-docs gives it the "brain" of the official documentation.

It’s a secure, local, and highly effective way to level up your ABAP development—even behind the corporate firewall.

What's next?

So far I think it's a big improvements with the reduced scope of these two tools. But at the same time, there are still things that can be tweaked:

Agent customizing: I'm using here out-of-the-box components. With more fine tuning the responses would be much better.
Tool improvements: as you know, there are some restrictions when using Eclipse with ABAP. And this is also dependent on the Eclipse, ADT or Copilot version. With a specific version combination of them, the behavior would be much better and less erratic.

Tweaks for RAP BO events addressing filtering (before send) and too small payload (callbacks needed)

2026-02-03T15:18:52.529000+01:00

Are you working on modernizing your SAP integrations, or looking for better ways to integrate with clean core compliance? But when you've looked at "Event Objects" from the SAP Business Accelerator Hub, you have found that it's not exactly matching your needs? Too many events are fired (can I filter?). The callback API is too time-consuming/unwanted. Or maybe you are simply interested in how ABAP RESTful Programming Model (RAP) Events work, how you can use and/or extend SAP Standard events?

In this blog I'll go through first some basic info and then start to showcase some tips / tweaks / workarounds you may or may not be aware about. Let's go.

1 ABAP RESTful Programming Model (RAP) Events Intro

I'll keep this very brief as the meat of this blog is to go into the nitty-gritty details. But, for the uninitiated, RAP BO events are events that have been built with the RAP framework which can easily integrate with event brokers, such as SAP Business Technology Platform's Event Mesh or Advanced Event Mesh. They are a sort of modern version of BTEs. You may refer to a previous blog of mine where I go into one full end-to-end example, showcasing how to find SAP standard events and then use them: Working with RAP BO Events end-to-end . The short version is that all events can be found on the SAP Business Accelerator Hub -> Your SAP Product -> Events.

2 Too many events are fired / I want to filter

This is probably one of the most common discussion points when I work with my customers. More often than not a "Created" or even more interestingly, a "Changed" event is simply fired too often for the actual integration needs. So what can we do here? In essence we have 3 main options:

Integration middleware handles filtering (= no changes in SAP system, use event as is)
1. This can be desirable if there are lots of receiving systems that need to receive information for a certain object, and maybe each of them would like to filter a little different. The middleware receives the event as it happens and can then handle the distribution accordingly. This way 1 single event could be the foundation of several functioning integrations (instead of several point-to-point integrations). The quote-on-quote downside to this is that you would of course increase the complexity in the middleware itself, but again if the same event benefits several receivers, this could be a good option.
Extend SAP standard event to include filtering fields (= extension development in your SAP system, use extended event, not standard)
1. This can be used if you know for sure you always want to filter out certain types of objects, that none of the integrated systems would want to be informed about. The quote-on-quote downside here is that we need to create an extension. Secondly, we first have to check if the SAP Standard RAP BO in question even allows behavior extensions. If not, we cannot use this option at all.
Use custom event in combination with SAP Standard event as a workaround (= custom development in your SAP system, use custom event, not standard)
1. Same as for the previous one, this option can be used if we know for a fact we always want to filter away certain objects. We can use this over the extend option, if for example the extension was not possible, or if the extension possibilities do not suffice (for example we need to add fields that are not easily associated in the RAP BO, or we need some complex logic and checking before we send an event)

As this blog focuses on RAP, I'll skip the first option and let the integration gurus tackle that one. Let's take a closer look at the other two...

2.1 Extend SAP standard event

If we found a suitable SAP standard RAP BO event and all we want is to add a few filter fields, we can do that with what is called Derived Events. Please refer to this page for details: Derived Business Events | SAP Help Portal

For my showcase I'll be using R_SalesOrderTP~Changed event. First of, we need to check if the behavior definition of the BO allows extensions. Open it and check for the word "extensible" somewhere at the beginning of the definition + on the entity which has the event (so we need two extensible).

If it's there, we can proceed. Next we can also check the event itself and the payload (if no parameter statement is written there, the payload is the key field(s) of the BO alone).

2.1.1 Create derived event payload with filter fields

Before we extend the behavior, we need a custom payload that includes our filter fields. Create a new data definition root entity and define your custom payload. For example:

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Sales Ord. ext. event for derived event'
define root view entity ZP_SalesOrder_EventExt as select from I_SalesOrder
{
  key SalesOrder,
  .context.attribute: 'xsapordtype'
  SalesOrderType,
  .context.attribute: 'xsapslsorg'
  SalesOrganization,
  .context.attribute: 'xsapbillplc'
  _BillingPlan.BillingPlanCategory,
  DistributionChannel,
  OrganizationDivision,
  SoldToParty,
  CustomerGroup,
  ShippingCondition,
  IncotermsClassification,
  OverallSDProcessStatus
}

Few points:

Key fields must match the RAP BO you are extending
You can access fields just like the standard RAP BO and also associated fields (I showcase this with BillingPlanCategory above). Note, we focus only flat structures, so the associated field needs to be 1:1 (for deep structures, please refer to chapter 3).
With above, we created exactly 3 filter fields: Sales Order Type, Sales Organization, and Billing Plan Category. Filters must have the annotation "Event.context.attribute" and must start with "xsap"!

2.1.2 Extend standard RAP BO behavior to create a derived event (with our custom payload)

Now we are ready to extend the behavior definition as per usual practice: find/display it in the project explorer - right click - New Behavior Extension. Here type out your derived event, for example:

extension
//using interface i_salesordertp
;
extend behavior for SalesOrder {
  managed event ZZChangedExtended on Changed parameter ZP_SalesOrder_EventExt;
}

Few notes on the above:

First of I want to start with the interface commented away above. Bear with me, this is important to understand!
In RAP it is always best to interact with RAP BOs via their interface, if there is one (not to be confused with a basic interface view, such as I_SalesOrder or I_Customer etc., which reads from the DB table). In the case of R_SalesOrderTP, it has a transactional interface called I_SalesOrderTP. This interface is meant as a stable "API" to interact with the BO, and is usually released with C1/C0 contracts for clean core compliance. So in truth, we should be using the interface as we are extending this BO, but as you see above, it's commented away. That is because we must, in this case. I_SalesOrderTP does not include any of the events, and because we need those, we cannot use the interface in this case. What this means is that my extension behavior definition, as of right now, must be saved as "Standard ABAP" and cannot be assigned to a package with an ABAP Cloud software component. HOWEVER, this is clean core compliant, because R_SalesOrderTP is released with a C0 contract for extension, thus allowing such extensions. The problem is that the syntax check for ABAP for Cloud Development only checks for C1 contracts (which is missing on R_SalesOrderTP behavior), which is why, as of right now, we have to save this as Standard ABAP, meaning a "level B" extension which is clean core compliant (it would have been "level C", if R_SalesOrderTP hadn't had the C0).
The rest is quite straight forward. We say which entity we are extending (SalesOrder, using the alias in the behavior definition) and we are stating the Changed event to be extended with ZZChangedExtended with our own payload we previously created.

2.1.3 Create Event Binding for derived event

Next up we need an Event Binding for our derived event. As a small side note: if you only intend to consume your own derived within your SAP system (the same system) and not send it out to an event broker, then you would not need an event binding.
Create a new Event Binding object (Business Service - Event Binding or just search for event binding in the new ABAP object dialog) and add the event we just created to it:

Note that we of course refer to the SAP Standard RAP BO, which now includes our derived event thanks to the extension we just did.

2.1.4 Configure Event Channel to include your derived event

Lastly, to send our derived event to an event broker, we need to add it to our event channel. Assuming you already prepared an event channel (refer to my other blog linked above for more info on that), go to /n/IWXBE/CONFIG, select your event channel and go to Outbound Bindings.

Click the create button to add the event binding you just created. It could look something like this:

The above means that my Event Mesh on my BTP subaccount receives the SAP standard Sales Order Created event, and my own derived Sales Order Changed event.

And that's it: now we are ready for filtering or for simply getting the larger payload as per our derived event.

2.1.5 Adding Filters

In the same location as we were (/n/IWXBE/CONFIG -> Event Channel -> Outbound Bindings) click on the button Filters at the top. Open up the folder Outbound Bindings for your event channel and click on your derived event. Clicking on the plus-button shows all available filter fields, in this example:

Create a filter, for example that only Sales Order Type "OR" should be sent to out:

2.1.6 Subscribe to the event on your event broker

To receive this derived event for example in Event Mesh on SAP BTP, you need of course a corresponding queue and then add the subscription for this new derived event. In my example:

2.1.6 Test example

I changed a sales order in my system and saved. This now triggered my derived changed event, which I can see in the events monitoring transaction /n/IWXBE/EVENT_MONITOR (select event channel, click on Outbound Events, double-click on derived event)...

...and on SAP BTP Event Mesh where I added the subscription:

Here we can only see what's sitting in the queue. So let me consume the message in the test tool to show the same payload as in our monitor:

Awesome! We succeeded and this concludes the extend event option.

2.2 Use custom event in combination with SAP Standard event

This is an interesting one and in my experience comes with some confusion attached to it. I have heard sentences such as "But can't we just create a custom event instead of the standard one and use that?" And the simple answer to that is yes, but no 😊. Let me explain...

Now of course if we create our own, custom RAP BOs, we can add events to them. That is clear. And within that custom BO you decide when that event is fired. Clear and no problem. But this is all custom.

And now, if you want "your custom event" to be trigged during SAP standard processing, well no, SAP standard can't do that, as it does not know your custom event exists. And if you are thinking to use user exits or BAdIs to do this; think again, because it would be wrong to do so. User exits and BAdIs are called while the processing has not yet completed. Meaning at this point, in theory, something could still go wrong (no update in DB), but you already triggered your event. So, do not do this, ever! The point of the event framework is to inform about a state change. So you only want to do that, if the state change has actually occurred, meaning after the DB is fully updated.

So what else then, you wonder? That's where the SAP standard event comes in (which yes, is fired AFTER the state change occurred and all processing has completed). The SAP Standard event will trigger, and thus if you want more flexibility than just explored in the previous option with the extension of the SAP standard event, that's when we can try to combine standard with custom event.

Essentially, this is the pattern:

SAP standard process does something, which triggers an event for a certain object. This triggering happens at the exact time you want, but the SAP Standard event does not fulfill your requirement (and we can't / don't want to do a derived event)
You will create a custom event on a "dummy" RAP BO which includes the exact payload you need (flat structure for EM, it can be a deep one for AEM).
You will create a local event listener (within your SAP system) for the SAP standard event that triggers at the right moment. Within this local consumption you can now do any ABAP logic you may need. Complex filtering. Complex data collection (calling BAPIs or other things) etc.
Once all your data validation and collection is done, you fill the payload format of your custom event and finally you trigger your custom event (with a slight workaround, as events can only be raised from with the RAP BO itself)
You only configure your custom event in the event channel for the event broker. The event arriving there is ready to be consumed with all needed fields and only events are that are really expected are arriving there.

Let's do this example now. We stick with R_SalesOrderTP, this time using Created as the SAP Standard event.

Let's assume I don't just want to send all sales order that are created. Sales order type filtering is not good enough. In fact, it matters whether a product is sold that has certain characteristics, for example. As a simplified example here, I will only check the product type of the product, but hopefully this gives you some ideas; we could check anything at this point.

2.2.1 Create custom event

Our custom event doesn't need much of a BO. Meaning we don't want to (re)create read/update/delete etc. functionality, but this is purely for defining how the event payload should look like and for triggering the custom event.

In my example I took it a step further: what if I create a generic "event forwarder", that could potentially be used together with many SAP standard objects? Now, this isn't to say that I recommend this approach, in fact quite the opposite. And depending on your exact requirement, this may definitely the wrong approach. But I did this also in an effort to answer if this is at all feasible.

If having an event trigger with only key field information and then having a subsequent callback API later in the integration is a good pattern for you, then this could potentially help you, as you could reuse it for several use cases.

But, if instead you want something very specific, for example only forward my object under certain circumstances and including already all data needed, then of course it makes more sense to create a tailored custom event, with the exact payload of that object you want.

So please bear that in mind as we continue with this example. With this example I handle only a generic key-field based payload.

2.2.1.1 Custom entity data definition

We start of course with the data definition. Custom entity is in my opinion the best, as again we don't actually need any read or update functionality, but we simply describe our event payload at this point (and here you could have a large flat/deep structure):

@EndUserText.label: 'Event Forwarder BO'
define root custom entity ZR_EventForwarder
{
  key ObjectKey  : abap.string;
  key ObjectType : zevent_fwd_object;
}

2.2.1.2 Custom entity behavior definition

Next we need the behavior that will include our custom event:

unmanaged implementation in class zbp_r_eventforwarder unique;
strict ( 2 );

define behavior for ZR_EventForwarder
lock master
authorization master ( instance )
{
  field ( readonly ) ObjectKey, ObjectType;
  event ForwardEvent;
}

Finally, let ADT generate the BP implementation for you (we do not need to fill any of the methods but so it's properly created (again, we need no read/save methods etc.)). So I will not paste the whole Class/or Local Types.

Instead, what we need to do here is now offer an option to "raise" our custom event "ForwardEvent" from outside this BO. The "raise entity event" command is not allowed outside the RAP BO itself. So instead, we need to encapsulate it in a way that ABAP code from outside this behavior pool can call it. For this we need 2 things:

"Local event handler" (not actually inheriting anything => chose this to separate it from other, standard RAP BP behavior methods)
Method in the global class that can be called from other ABAP code

Let's start with the "local event handler". Within the section Local Types of your behavior implementation class, add something this:

class lcl_event_handler definition friends zbp_r_eventforwarder.
  public section.
    class-methods on_forward_event importing it_events type zbp_r_eventforwarder=>tt_events.
endclass.

class lcl_event_handler implementation.
  method on_forward_event.
    raise entity event zr_eventforwarder~forwardevent from it_events.

  endmethod.
endclass.

Note the "friends" command in the class definition. This is needed to be able to access private/protected class variables from the behavior pool (raising our entity event).

And in the Global Class, we change it as follow (full code copied):

class zbp_r_eventforwarder definition public abstract final for behavior of zr_eventforwarder.
  types tt_events type table for event zr_eventforwarder~forwardevent.

  public section.
    constants:
      co_type_salesorder    type zevent_fwd_object value 'SALESORDER'.
    class-methods raise_forward_event
      importing it_events   type tt_events.


endclass.

class zbp_r_eventforwarder implementation.
  method raise_forward_event.
    " tell RAP framework that we are in a SAVE sequence (otherwise it thinks
    " we are in the middle of a MODIFY)
    cl_abap_tx=>save( ).
    " trigger event (only allowed during SAVE)
    lcl_event_handler=>on_forward_event( it_events ).
  endmethod.
endclass.

We did 3 main things: a global type for the event payload table, a constant to distinguish different types of RAP BO that I mean to handle with my generic one (right now only one) and, most importantly, a global class method that can be called from other ABAP code.

2.2.1.3 Event Binding

As before, we need an event binding if we want to forward this to an event broker:

(Namespace, object type etc. can be freely chosen.)

And that's all for our custom event. Remember that the only purpose of this custom event is to offer a way to define the payload and to trigger it. Any functionality, such as filtering, complex validation or data selection etc. we do when the real SAP standard event is triggered. Meaning in the local consumption.

2.2.2 Local consumption of SAP Standard event

Now I won't go into step-by-step on this one, as I have done this already on the above linked blog post of mine. Please check there if the below steps are not enough for you.

I have an ABAP Class, abstract, final with the "for events of" functionality, where once again we must type R_SalesOrderTP here (and not I_SalesOrderTP, which would have been the preferred option). This means my class has to be again saved as "Standard ABAP" and cannot be in an ABAP for Cloud Development package. But this is clean core compliant, as explained above.

In Local Types I have my local class that inherits from cl_abap_behavior_event_handler and I add a method for the Created event:

class lcl_event_cons definition inheriting from cl_abap_behavior_event_handler.

  private section.
    methods:
      consume_created for entity event instances for salesorder~created.
endclass.

And here the implementation of that method (we'll go through it one by one below):

    data: lt_fwd_event  type zbp_r_eventforwarder=>tt_events.
    
    " go through RAP BO entity instances that triggerd the event
    " (should only be 1 as we listend to sales order (header) created)
    loop at instances into data(instance).
      " get data needed for complex filtering
      select salesorderitem, product, \_product-producttype
        from i_salesorderitem
        where salesorder = @instance-salesorder
        into table (lt_items).

      " check if sales order should be handled (forwarded to event broker)
      if line_exists( lt_items[ producttype = 'HAWA' ] ). 
        " this sales order is now filtered OK and will be added to the forwarding instances
        append initial line to lt_fwd_event assigning field-symbol(<fs_event>).
        <fs_event> = value #( objectkey  = instance-salesorder
                              objecttype = zbp_r_eventforwarder=>co_type_salesorder ).
      else.
        continue. " we are not interested in this Sales Order
      endif.
    endloop.

    " now that we checked all instances, only those that we filtered will be forwarded
    if lt_fwd_event is not initial.
      zbp_r_eventforwarder=>raise_forward_event( lt_fwd_event ).
    endif.

We create an internal table of the payload type that is the custom event (we created a global type in the behavior definition)
We loop through all instances that were sent by the SAP standard event (since this is a sales order (header), this will only ever include 1)
As we loop, we select some additional data to do "some complex logic" for checking if this sales order should be forwarded or filtered out.
Once all requirements are met for forwarding the sales order, we fill the custom event payload table.
When the looping is done, we check if any sales orders remained (if we have any custom event payload) and if yes, we now call the method we offered on the custom event RAP BO behavior as global class method and give it the payload we just filled.

And that's all 😲😀

2.2.3 Finishing

As before, we need to configure our custom event (binding) in the event channel in order to forward it to the event broker:

On the event broker, we need to subscribe to that topic, to receive it there:

To summarize, this is what will happen:

A user creates any sales order
R_SalesOrderTP-Created is triggered
Our local consumption of the SAP standard event is called: our local consumption checks if the sales order has any items with products of product type HAWA. If yes, we add it to be forwarded. If no, we disregard it.
If we had any sales order to forward, the ZR_EventForwarder behavior is called via workaround (a little bit nasty by just calling the global class but I could not think of any other way. For example we can't use an action, as actions are invoked via EML MODIFY, which in turn does not allow for RAISE EVENT). This triggers the ZR_EventForwarder-EventForwarded event with our payload
The custom event is forwarded to event broker

2.2.4 Testing

Let's test this. I create a new sales order and I include 1 item that has a product of type HAWA. Meaning my filtering will allow this sales order and eventually trigger my custom event.

Let's see what the event monitor says:

And consuming this message in BTP Event Mesh:

3 I want a larger payload

This is without a doubt the 2nd most discussed topic when talking event based integrations. In order to avoid callback APIs, maybe this is the way to go for you. As of right now, SAP Standard delivers notification events only, meaning small payloads to allow for the creation of fast, simple, integrations that can be easily reused.

You may already noticed that we already covered this in chapter 2. Both when extending the SAP standard event or when creating a custom event to work in combination with standard: I showcased how we can decide our own payload. So far I have only mentioned flat structures, as that is the only type that is supported by Event Mesh on SAP BTP. If you have a need for deep structure payloads, you may want to consider to upgrade to Advanced Event Mesh instead. And instead of creating a brand new example, please check out this blog post by a colleague that goes into deep payload: RAP Events with AEM 3 - Creating Events with deep payload.

Conclusion / Final Words

I hope this blog post helps and gives some ideas how far you can take RAP BO events and influence your integration landscape, in a positive way (of course, that's the end goal).

Is there anything I've missed? Another requirement that you would like to solve with eventing? Or any other questions or comments/feedback? Let me know in the comments and let's see 😊

CI based script tester & ABAP groovy IDE

2026-02-03T17:20:00.015000+01:00

Background

This blog aims to recreate groovyIDE using tools and platforms that every SAP developer should have access to.
My goal was to avoid local development (using IntelliJ or Eclipse), as setting up such an environment is often difficult due to employer restrictions.

What do you need?

To pull this off, you need:

Developer access to any Cloud Integration (CI) tenant
(I recommend a separate tenant, ideally DEMO or TRIAL)
Developer access to an ABAP system that can connect to CI

Nice to have:

abapGit – as there is a repository with the backend report

Setup

Cloud integration

Cloud Integration is used as the execution engine. In practice, this is a CI-based IDE exposed as a REST service. I would like to thank Vadim Klimov for exploring this idea. His blog (and the unavailability of groovyIDE) inspired me to create this solution. At its core, this is a single iFlow with a few steps. It uses GroovyShell to execute a script passed in the request payload.

Integration flow

As you can see, the iFlow is simple and straightforward. It performs the following steps:

Decodes the payload, script, headers, and properties from the request
Dynamically executes the Groovy script
Creates a well-formatted JSON response, encoding all data using Base64

There is also an exception subprocess used to catch Groovy execution errors and return them in a structured JSON format.

Request

The interface accepts a JSON payload with four parameters, all Base64-encoded:

{
  "inputScript": "<base64encoded>",
  "inputPayload": "<base64encoded>",
  "inputParams": "<base64encoded>",
  "inputHdrs": "<base64encoded>"
}

After decoding, parameters (properties) and headers follow this format:

Name=Value;Name2=Value2;...

Cloud Integration encodes them in the same way in the final response (both in success and error cases).

Decoder

import com.sap.gateway.ip.core.customdev.util.Message;
import groovy.json.JsonSlurper;

Message processData(Message message) {
    def body = message.getBody(java.io.Reader)
    def inputJSON = new JsonSlurper().parse(body)
    String inputHdrs = inputJSON.inputHdrs
    if(inputHdrs ){
        byte[] decodedHdrs = inputHdrs.decodeBase64()
        inputHdrs = new String(decodedHdrs)
        inputHdrs.split(';').each{ 
            def param_val_pair = it.split('=')
            message.setHeader(param_val_pair[0],param_val_pair[1])
        }
    }

    String inputParams = inputJSON.inputParams
    if(inputParams){
        byte[] decodedParams = inputParams.decodeBase64()
        inputParams = new String(decodedParams)
        inputParams.split(';').each{ 
            def param_val_pair = it.split('=')
            message.setProperty(param_val_pair[0],param_val_pair[1])
        }
    }

    String inputScript = inputJSON.inputScript
    if(inputScript){
        message.setProperty("inputScript",inputScript)
    }

    String inputPayload = inputJSON.inputPayload
    if(inputPayload){
        byte[] decodedPayload = inputPayload.decodeBase64()
        inputPayload = new String(decodedPayload)
        message.setBody(inputPayload)
    }

    return message
}

The decoder script processes headers and properties and sets them for the current message processing. The payload is decoded and set as plain text (String) in the message body. The actual Groovy script is stored as a separate property named "inputScript" and is later used in the execution step.

Script execution

import com.sap.gateway.ip.core.customdev.util.Message
import java.io.StringWriter
import java.io.PrintWriter

Message processData(Message message) {
    //Get script
    String inputPayload = message.getProperty("inputScript")
    byte[] decodedPayload = inputPayload.decodeBase64()
    String scriptCode = new String(decodedPayload, "UTF-8")
    //Setup output capture
    StringWriter logWriter = new StringWriter()
    PrintWriter printWriter = new PrintWriter(logWriter)    
    //Create Binding and inject 'out' for println support
    Binding binding = new Binding()
    binding.setVariable("out", printWriter)     
    //Initialize shell
    GroovyShell shell = new GroovyShell(binding)
    Script script = shell.parse(scriptCode)
    //call script
    message = script.processData(message)    
    //Save logs to property 
    printWriter.flush()
    message.setProperty("consoleLog", logWriter.toString())
    
    return message
}

The main difference between this script and the one provided in Vadim’s blog is the use of an additional binding with a PrintWriter object. This allows capturing console output (println statements) and returning it to the caller as part of the response.

Wrapper

import com.sap.gateway.ip.core.customdev.util.Message

Message processData(Message message) {
    def consoleLog = message.getProperties().get("consoleLog") as String
    message.setProperty("consoleLog", null)
    def mapProperties = message.getProperties();
    def mapHeaders = message.getHeaders();
    def body = message.getBody(java.lang.String) as String;
    String Pbody = ""
    String Hbody = ""
    //encode props and hdrs to name=value; format
    mapProperties.each { it -> Pbody += "$it.key = $it.value;" }
    mapHeaders.each { it -> Hbody += "$it.key = $it.value;" }
    def builderJSON = new groovy.json.JsonBuilder()
    builderJSON{
        properties(Pbody.bytes.encodeBase64().toString())
        headers(Hbody.bytes.encodeBase64().toString())
        payload(body.bytes.encodeBase64().toString())
        console(consoleLog.bytes.encodeBase64().toString())
    }
    message.setBody(builderJSON.toPrettyString())
    return message
}

The wrapper executes the decoded Groovy script and captures console output. After execution, all logs are stored in a message property and later included in the JSON response.

Error Handler

import com.sap.gateway.ip.core.customdev.util.Message;
def Message processData(Message message) {
    def mapProperties = message.getProperties();
    def body = message.getBody(java.lang.String) as String;
    String Pbody = ""
    String Hbody = ""
    mapProperties.each { it -> Pbody += "$it.key = $it.value; \n" }
    def ex = mapProperties.get("CamelExceptionCaught");
    def mapHeaders = message.getHeaders();
    mapHeaders.each { it -> Hbody += "$it.key = $it.value; \n" }
    def builderJSON = new groovy.json.JsonBuilder()
    builderJSON{
        properties(Pbody.bytes.encodeBase64().toString())
        headers(Hbody.bytes.encodeBase64().toString())
        payload(body.bytes.encodeBase64().toString())
        error(ex.message.bytes.encodeBase64().toString())
    }
    message.setHeader("CamelHttpResponseCode", "400");
    message.setBody(builderJSON.toPrettyString());
    return message;
}

The error handler is very similar to the wrapper but additionally captures execution exceptions and includes them in the response. This is important during testing, as errors such as missing variables or null references are common. The main idea of this tool is that any Groovy-related error is returned to the caller. To distinguish between script errors and unexpected system failures (HTTP 500), the service returns HTTP 400 for Groovy execution errors. This makes sense, as the script itself is part of the request.

ABAP

There is not much logic on the ABAP side: a table, a data element, and a report.

The table ZSAPERGROOVYTST serves as a test case repository. In the current version, it stores only a cache – the last modified script, payload, and input properties.

All text inputs are stored as Base64-encoded strings. Headers and properties are stored as name=value pairs, following the same format used by Cloud Integration.

When the program is cancelled, it closes without updating the cache table. When exited normally, the current editor and ALV content is stored as a TMP record for the current user and loaded the next time the IDE is opened.

I will not go into ABAP-specific details here. You can check the Git repository or import the objects into your system and test the solution yourself.

Connection

Connectivity is based on an RFC destination (type G) configured in transaction SM59. The destination name is stored in lcl_groovy=>cv_destination and defaults to "CPI_GROOVY".

You can adjust it to your needs in method "call_script".

  METHOD call_script.
    cl_http_client=>create_by_destination( EXPORTING destination = cv_destination
                                           IMPORTING client      = DATA(lo_http) ).
    DATA(ls_current_screen_data) = me->get_screen_data( ).
    DATA(lv_payload) =
    |\{| &&
      |"inputScript":"{ ls_current_screen_data-script  }",| &&
      |"inputPayload":"{ ls_current_screen_data-payload  }",| &&
      |"inputParams":"{ ls_current_screen_data-props  }",| &&
      |"inputHdrs":"{ ls_current_screen_data-hdrs  }"| &&
    |\}|.
    lo_http->request->set_cdata( lv_payload ).
    lo_http->send( ).
    lo_http->receive( ).
    lo_http->response->get_status( IMPORTING code = DATA(lv_status_code) ).
    IF lv_status_code EQ 500.
      MESSAGE 'Internal server error occured' TYPE 'I' DISPLAY LIKE 'E'.
    ELSE.
      me->parse_service_call_response( iv_response = lo_http->response->get_cdata( ) iv_code = lv_status_code ).
    ENDIF.
  ENDMETHOD.

Testing

Let’s start with the default script. It simply rewrites the input to the output and adds a console log line: "test1".

Now let’s break something – for example, by dividing by zero.

As expected, the error is visible in the console output:

"java.lang.Exception: java.lang.ArithmeticException: Division by zero @ line 7 in ExecuteScript.groovy".

This demonstrates the usage of JsonSlurper and JsonBuilder, as well as property and header handling.

Security

This solution executes dynamic Groovy code using GroovyShell and therefore must be treated as a development and testing tool only. Access to the integration flow should be restricted, and the endpoint must not be connected to productive systems. The script executes with the runtime permissions of Cloud Integration and is not sandboxed. For this reason, the tool should be deployed only in isolated CI tenants (for example TRIAL tenant).

External links

ABAP repo: https://github.com/devstylator/abapGroovyEditor
groovyIDE: https://groovyide.com/cpi
Vadim's blog post: https://community.sap.com/t5/technology-blog-posts-by-members/rapid-groovy-scripting-in-cpi-dynamic-loading-and-execution-of-script-code/ba-p/13409607

How to extend the program SAPF124 of F.13 to retrieve its results

2026-02-03T21:53:36.070000+01:00

Introduction

F.13 is the transaction to clear the open items automatically. For functional information, see Automatic Clearing | SAP Help Portal.

The result is a spool which contains a log with all results.

To analyze the results by program, it's easier to create a few enhancements to F.13 (program SAPF124) to retrieve the log as several internal tables, rather than decoding the spool (called "ABAP List" hereafter), because the latter is often subject to changes after an upgrade.

Note that some people recommend in the forum to use POSTING_INTERFACE_CLEARING but I couldn't find any official information saying that it's allowed for automating F.13.

Before creating the enhancements to the program SAPF124, it's important to understand the logic of the program. Also, the names of some of the selection screen parameters and an example of the output ABAP List are useful.

Warning: in this blog post, I don't post the code I used, but I explain which subroutines can be enhanced.

My SAP system is S/4HANA 2023 FPS01.

Selection screen parameters and result example

Example of the output ABAP List. Here F.13 ran in test mode so there's no clearing document created (so, the number remains blank). We can see the list of cleared documents at the top, then the additional log and the error log at the bottom.

SAPF124 logic

AT SELECTION-SCREEN:

Call the subroutine CHECK_ECHTL
- In productive mode (X_TESTL not checked), it displays the warning FG013 “This program run is a production run” as a popup.
- It also calculates X_ECHTL = “X” or “ ”.
  - “X” means that the execution is in productive mode (X_TESTL not checked).

START-OF-SELECTION:

Call the subroutine KONTOTABELLEN_FUELLEN

Fills the 3 lists of objects to process: customers (from the table BSID to the internal table TDEBI), suppliers (from the table BSIK to the internal table TKREDI) and accounts (from the table SKB1 to the internal table TSAKO), according to the selection screen parameters.

Logic for the 3 lists

Call the subroutine DEBI_VERARBEITEN if the "Customers" box is checked
- LOOP AT TDEBI (customers)
  - Call the subroutine ECHTLAUF or TESTLAUF (*) with KOART = 'D'
Call the subroutine KREDI_VERARBEITEN if the "Suppliers" box is checked
- LOOP AT TKREDI (suppliers)
  - Call the subroutine ECHTLAUF or TESTLAUF with KOART = 'K'
    - (ECHTLAUF or TESTLAUF based on the same test as for customers)

Call the subroutine SAKO_VERARBEITEN if the "Accounts" box is checked
- LOOP AT TSAKO (accounts)
  - Call the subroutine ECHTLAUF or TESTLAUF with KOART = 'S'
    - (ECHTLAUF or TESTLAUF based on the same test as for customers)

(*) ECHTLAUF is called if the run is in productive mode or with tolerance included. Otherwise TESTLAUF is called, which has the same logic as ECHTLAUF except that the lock isn't done.

Event END-OF-SELECTION:

Call the subroutine ACC_AUSGABE_ADDITION_LOG

Write the internal table IPROT (additional log) to the ABAP List.

IF X_FEHLER = 'X':
- Call the subroutine ACC_AUSGABE_FAULT_LOG
  - It writes the internal table FEHLPROT (error messages) to the ABAP List.

Subroutine ECHTLAUF with I_KOART being 'D', 'K' or 'S'

For information, depending on I_KOART being 'D', 'K' or 'S', the data will be taken respectively from TDEBI, TKREDI or TSAKO.

Reminder: ECHTLAUF is called only if the run is in productive mode or with tolerance included. Otherwise TESTLAUF is called, which has the same logic as ECHTLAUF except that the lock isn't done (SPERREN_KONTO is not called).

Logic:

Call the subroutine SPERREN_KONTO to lock the object to process
Call the subroutine INDEXTABELLEN_FUELLEN
- Call the subroutine READ_BSID or READ_BSIK or READ_BSIS to build the groups of clearing criteria XBSIDGR or XBSIKGR or XBSISGR, depending on I_KOART = 'D', 'K' or 'S' respectively. The criteria (list of fields) are defined in the SAP Customizing Implementation Guide (SPRO) -> Financial Accounting -> General Ledger Accounting -> Business Transactions -> Open Item Clearing -> Prepare Automatic Clearing (or SM30 V_TF123). The subroutine XBSID_XBSIDGR_FUELLEN or XBSIK_XBSIKGR_FUELLEN or XBSIS_XBSISGR_FUELLEN is called, which fills these internal tables:
  - APPEND XBSID or XBSIK or XBSIS depending on I_KOART = 'D', 'K' or 'S' respectively.
  - COLLECT XBSIDGR or XBSIKGR or XBSISGR depending on I_KOART = 'D', 'K' or 'S' respectively:
    - Each line is a group of clearing criteria for which FI documents may be cleared altogether.
    - The field XBSIDGR-BET_BW or XBSIKGR-BET_BW or XBSISGR-BET_TW contains the sum of FI documents which can be zero (they can be cleared) or another number (they cannot be cleared).
- LOOP AT XBSIDGR or XBSIKGR or XBSISGR depending on I_KOART = 'D', 'K' or 'S' respectively
  - Call subroutine AUSGLEICH USING I_SUM = XBSIDGR-BET_BW or XBSIKGR-BET_BW or XBSISGR-BET_TW

Subroutine SPERREN_KONTO (lock)

If KOART = 'D', call ENQUEUE_EFKNB1A with tdebi-bukrs, tdebi-kunnr.
If KOART = 'K', call ENQUEUE_EFLFB1A with tkredi-bukrs, tkredi-lifnr.
If KOART = 'S', call ENQUEUE_EFSKB1A with tsako-bukrs, tsako-hkont, tsako-hbkid, tsako-hktid.

Subroutine AUSGLEICH with I_SUM = sum of amounts of all documents with the same clearing criteria

It checks if the clearing of one group of documents with the same clearing criteria is possible. If yes, it’s calling a given transaction code (whose code may vary) via Batch Input to create one clearing document.

The subroutine has the following logic:

Call the subroutine BELEGE_AUSGEBEN (collect the list of documents to be cleared)
- Loop at all the lines of XBSID, XBSIK or XBSIS corresponding to the current grouping criteria XBSIDGR, XBSIKGR or XBSISGR depending on KOART = 'D', 'K' or 'S' respectively.
If I_SUM = 0 (the documents of the current group have a total amount of 0, so they can be cleared).
- Call the subroutine AUGDT_PRUEFEN
  - Call the subroutine CALL_TRANSACTION if it's a productive run
    - Batch input CALL TRANSACTION FB1D, FB1K or FB1S/FB1SL depending on KOART = 'D', 'K' or 'S' respectively.
    - The batch input messages are stored into the internal table MESSTAB
    - Call the subroutine MESSTAB_AUSWERTEN
      - If MESSTAB contains the success message F5312 "Document & was posted in company code &", AUGBLNR (global variable) = MSGV1 (document number)
      - Call the subroutine RECORD_CLEARING_INFO with I_CHAR = 'AUGBL'
        Call subroutine ACC_APPEND_DATA with parameters AUGBLNR, clearing date and ID_MESSAGE = ‘AUGBL’ to display the documents to be cleared and the clearing document created.
        IMPORTANT: GT_DLIST is cleared (the list of documents to be cleared).
        Call subroutine RECORD_CLEARING_INFO with I_CHAR = code expressing errors (‘NOCLEAR’, ‘NOTZERO’, etc.)
      - If X_FEHLER = 'X'.
        Call subroutine MESSTAB_LESEN which feeds the internal table FEHLPROT (displayed error log) from MESSTAB (error messages from the batch input)
Else if clearing is permitted with tolerance
- TODO
Else (if no clearing)

Call subroutine ACC_APPEND_DATA with parameter ID_MESSAGE = ‘NOTZERO’.
If there’s some clearing tolerance, add the error to the internal table IPROT (additional log).

Subroutine ACC_APPEND_DATA

It receives the parameters:

ID_AUGBLNR = clearing document created
ID_AUGDT = clearing date
ID_MESSAGE = ‘AUGBL’ (clearing) or others (no clearing), etc.
- AUGBL: The clearing has been done, i.e. the clearing document has been created, the global variable AUGBL contains this clearing document, the log contains F5312 (*).
- NOTZERO: the clearing is not possible because the sum of amounts of the documents is not zero.
- AUGDT: Test mode successful (in test mode, the F5312 and F5263 (*) messages are absent and there is no error).
- NOCLEAR: The reconciliation document has failed (the F5312 (*) message is absent and no tolerance is requested or a tolerance is requested but F5263 is absent).
- NOCLEARTOL: Failed (the F5312 (*) message is absent and a tolerance is requested and F5263 is present).
- ENQ: failed because the object of the current clearing criteria could not be locked
- Other values: Failed
- (*) Batch Input may return one of the following messages:
  - F5312: "Document & was posted in company code &"
  - F5263: "The difference is too large for clearing"

This subroutine has the following logic:

Call the subroutine WRITE_LISTE if the output of cleared/clearing documents has been requested in the selection screen. This subroutine does:

LOOP AT GT_DLIST INTO GS_DLIST (list of documents to be cleared)
- The document is written to the ABAP List.
Call subroutine CHECK_SUMME
- The clearing criteria are written to the ABAP List on one line, including the new clearing document if one has been created.

GT_DLIST is emptied (the list of documents to be cleared).

Enhancements

The parameter X_FEHLER (to display error messages in the ABAP List) is absolutely necessary to run several SAPF124 subroutines which contain information about the cleared documents.

The following subroutines may be enhanced to obtain information about the cleared documents used and the clearing documents created:

Begin of CHECK_ECHTL
- In real mode, it displays the warning FG013 “This program run is a production run”.
- It also calculates X_ECHTL = “X” or “ ”. “X” means that the execution is in real mode (case F.13 is not called in test mode i.e., checkbox X_TESTL = space/false).
- This message is annoying if SAPF124 is called by a custom program in a loop.
- Do this enhancement:
  - Keep calculating X_ECHTL = “X” or “ ” but don’t display the warning by using ABAP “RETURN” to not execute the standard code of the subroutine.
Begin of ACC_APPEND_DATA
- It’s called after the logic to create one clearing document, whatever it has succeeded (parameter ID_MESSAGE = ‘AUGBL’) or failed (other values).
- Do this enhancement:
  - Collect the list of documents cleared (internal table GT_DLIST), the clearing status (ID_MESSAGE) and the clearing document created (ID_AUGBLNR). The clearing document will be empty if the creation failed.
Begin of MESSTAB_LESEN
- It’s called when the creation of the cleared document failed via Batch Input and it feeds the internal table FEHLPROT from MESSTAB (error messages from Batch Input).
- Do this enhancement:
  - Collect the list of documents cleared (internal table GT_DLIST) and the error messages from the internal table FEHLPROT.
Begin of ACC_AUSGABE_FAULT_LOG
- It’s called at the end, but only if the selection screen option X_FEHLER was selected.
- Do this enhancement:
  - Export the data previously collected by the enhancements to the ABAP memory (EXPORT TO MEMORY ID).

Basic code to run SAPF124

Transaction F.13 starts SAPF124 with the SAP&F124 variant, so I'm doing the same thing. I haven't checked to see if there's a difference without the variant.

The actual content is obtained by reading the data collected by the enhancements in the ABAP memory (IMPORT FROM MEMORY ID).

SUBMIT sapf124
    USING SELECTION-SET 'SAP&F124'
    WITH bukrx   IN ir_bukrs     " Company
    WITH gjahx   IN ir_gjahr     " Year
    WITH docnr   IN ir_belnr     " Document Number
    WITH x_kunnr  = iv_xkunnr    " Check "Customers"
    WITH kontd   IN ir_kunnr     " Customers
    WITH x_lifnr  = iv_xlifnr    " Check "Suppliers"
    WITH kontk   IN ir_lifnr     " Suppliers
    WITH x_saknr  = iv_xsaknr    " Check "Accounts"
    WITH konts   IN ir_saknr     " Accounts
    WITH x_testl  = iv_xtestl    " Test mode
    WITH xausbel  = abap_true    " Output the documents cleared
    WITH xnausbel = abap_true    " Output the documents not cleared
    WITH x_fehler = abap_true    " Output the error messages
    EXPORTING LIST TO MEMORY     " To not generate a spool
    AND RETURN.

ABAP type for the collected data

In my final code, a variable of type TT_CLEARING_RESULT is exported by the enhancement to the ABAP memory, and imported after SUBMIT SAPF124, which is defined as follows:

    TYPES:
      BEGIN OF ts_doc_item_to_be_cleared,
        bukrs TYPE bseg-bukrs,
        belnr TYPE bseg-belnr,
        gjahr TYPE bseg-gjahr,
        buzei TYPE bseg-buzei,
      END OF ts_doc_item_to_be_cleared.
    TYPES tt_doc_item_to_be_cleared TYPE STANDARD TABLE OF ts_doc_item_to_be_cleared WITH DEFAULT KEY.
    TYPES:
      BEGIN OF ts_clearing_doc_created,
        bukrs TYPE bseg-bukrs,
        belnr TYPE bseg-belnr,
        gjahr TYPE bseg-gjahr,
      END OF ty_ clearing_doc_created.
    "! Batch Input errors
    TYPES tt_journal_sapf124 TYPE STANDARD TABLE OF bdcmsgcoll WITH DEFAULT KEY.
    TYPES:
      BEGIN OF ts_clearing_result
        s_clearing_doc_created   TYPE ts_clearing_doc_created
        t_doc_item_to_be_cleared TYPE tt_doc_item_to_be_cleared,
        t_journal                TYPE tt_journal_sapf124,
      END OF ts_clearing_result.
    TYPES tt_clearing_result TYPE STANDARD TABLE OF ts_clearing_result WITH DEFAULT KEY.

Depending on the selection criteria when calling SAPF124, the result may contain many rows, some failing, others succeeding. For example, to clear 2 documents A 2024 and B 2025, which we know can be cleared, unfortunately the selection will be wide and there may be 4 documents selected: A 2024, A 2025, B 2024, B 2025.

In the result, there will likely be failures on A 2025 and B 2024, and a success for A 2024 and B 2025. Since we are only interested in the 2 documents A 2024 and B 2025, we must search the result for the row concerning them.

Example of collected data of type TT_CLEARING_RESULT :

Only the 6th line shows a success, the clearing document 0900002549 has been created to clear the documents shown in the component T_DOC_ITEM_TO_BE_CLEARED:

SQL showing a subset of all possible test data

This query may be useful for developers who don't know FI and want to run F.13 with any existing test data, here it's returning document numbers from suppliers, without withholding tax, which can be cleared; you may need to adjust the clearing criteria according to your V_TF123 settings (in my case, grouping by GSBER, EBELN except for suppliers 6*):

select bsik1.bukrs || '   ' Company, bsik1.lifnr || '  ' Supplier, bsik1.h_waers, bsik1.gsber, bsik1.ebeln || '     ' ebeln, bsik1.belnr || '  ' Document, bsik1.gjahr || '  ' Year, bsik1.shkzg, bsik1.wrbtr
from bseg bsik1, bkpf
where bkpf.mandt = bsik1.mandt
  and bkpf.bukrs = bsik1.bukrs
  and bkpf.belnr = bsik1.belnr
  and bkpf.gjahr = bsik1.gjahr
  and bsik1.mandt = '100'
  and bsik1.umsks = ' '
  and bsik1.xpypr = ' '
  and bkpf.xstov = ' '
  and bsik1.qsshb = 0 /* without withholding tax to simplify */
  and bsik1.koart = 'K'
  and bsik1.augbl = ''
  and bsik1.h_bstat <> 'D'
  and bsik1.h_bstat <> 'M'
  and exists ( select bsik.bukrs, bsik.lifnr, bsik.h_waers, bsik.gsber, bsik.ebeln
from bseg bsik, bkpf
where bkpf.mandt = bsik.mandt
  and bkpf.bukrs = bsik.bukrs
  and bkpf.belnr = bsik.belnr
  and bkpf.gjahr = bsik.gjahr
  and bsik.bukrs = bsik1.bukrs
  and bsik.lifnr = bsik1.lifnr
  and bsik.h_waers = bsik1.h_waers
  and bsik.gsber = bsik1.gsber
  and bsik.ebeln = bsik1.ebeln
  and bsik.umsks = ' '
  and bsik.xpypr = ' '
  and bkpf.xstov = ' '
  and bsik.qsshb = 0 /* without withholding tax to simplify */
  and bsik.koart = 'K'
  and bsik.augbl = ''
  and bsik.h_bstat <> 'D'
  and bsik.h_bstat <> 'M'
  and bsik.lifnr not between '6000000000' and '6999999999'             /* criteria from V_TF123 */
group by bsik.bukrs, bsik.lifnr, bsik.h_waers, bsik.gsber, bsik.ebeln    /* bukrs, lifnr, waers (waers to simplify) + criteria from V_TF123 */
having 0 = sum( case when bsik.shkzg = 'H' then - bsik.wrbtr else + bsik.wrbtr end )
)
order by bsik1.bukrs, bsik1.lifnr, bsik1.h_waers, bsik1.gsber, bsik1.ebeln, bsik1.belnr, bsik1.gjahr

Adding Custom Fields to a Fiori App Using Custom Fields and Logic

2026-02-04T08:29:33.635000+01:00

Introduction:

SAP S/4 HANA provides in-app extensibility and the Adaptation Transport Organizer (ATO) framework to safely create, enable and transport custom fields without modifying standard code. In this blog, I will walk through a step-by-step process to set up ATO, prepare custom fields, enable them, publish them and finally add then to a custom Fiori app.

Step 1: Initial ATO (Adaptation Transport Organizer) set up:

Go to transaction SCFD_EUI

2. Close the initial pop up and click on Auto Setup and following screen will populate:

3. Create below packages using SE80:

Local package TEST_KEY_USER_LOCAL
Sandbox package TEST_KEY_USER_SANDBOX

4. Now enter the local and sandbox package name and click on ‘Setup with specific data’.

5. It will then prompt you for a transport, for this first create a workbench transport and assign it in the popup to enter the transport and save your entries.

6. Input table name ‘GMGR’ and field ‘Z*’ and hit Execute:

Step 2 – Understanding Field Statuses

After execution the output screen shows three possible field statuses:

Enabled: This is already enabled and available in custom field APP

Can Be Enabled: This can be enabled by clicking Enable button in tool bar

Preparation Required: Click on Prepare button, it will show the further steps to make it

‘CAN BE ENABLED’ status.

Step3: Changing Status from preparation required to can be enabled

Select ZZPIAR_EMAIL and click on Prepare.

2. The message below will be shown:

3. Go to T-code SE11 and check GMGR table.

4. The field ZZPIAR_EMAIL does not have domain associated

5. Once Domain is created for this field, the status of the field will become ‘CAN BE ENABLED’.

Step4: Enabling the custom field

The below field ZZFINALEXP is in ‘CAN BE ENABLED’ status:

2. Select ZZFINALEXP and click Enable button:

3. Select correct enabling type and click ok:

4. Select the package and create a workbench transport and Provide Transport number at Request/Task click ok.

5. We can see that the field ZZFINALEXP status changed to ‘Enabled’ status:

Step5: Publish the custom Field

Go to T-code /n/ui2/flp
Login to FIORI
Execute ‘custom field’ app
The below screen appears, this app shows all ‘Enabled’ fields, we see ‘Final Expense’ field here which we have enabled in above steps(step3).
Now select ‘FINAL EXPENSE’ field and click on the arrow.

6. The screen below opens, now enable Additional selection-Grant

7. Click on publish

The field is published now.

Step6: Add Custom field to ‘Custom’ App

Now go to the custom app and click on ‘Adapt UI’ as shown below.

2. Now the page becomes ‘Editable’, right click on screen, we can see option add field

3. Select Final expense field here and click OK.

4. Final Expense field will be added to the screen, now click Publish and save and exit.

Conclusion:

By following these steps, you can manage custom fields using SAP’s standard extensibility framework without touching the core objects. This approach reduced upgrade risk, supports transport consistency, and aligns with SAP’s clean-core strategy. The same method can be reused for other tables and fields across S/4HANA landscape.

How to Deliver Customizing as a SaaS Provider using Business Configuration Sets

2026-02-05T09:59:15.458000+01:00

In our previous blog post, How to Provide Customizing as a SaaS Provider, we described a programmatic approach that used EML statements with explicitly coded object templates in application jobs to deliver customizing entries. With release 2511, you can now use Business Configuration Sets instead, removing the need to include explicitly coded customizing data in your business logic.

This blog illustrates how to maintain customizing data in a Business Configuration Maintenance Object, how to maintain customizing translations, importing the created customizing data/translations into a BC Set, implementing an application job for the BC Set activation and finally how to deploy the BC Set content to the relevant customizing table.
We will also have a look into how BC Sets can be updated programmatically for the case when the customizing data was changed and BC Set data needs to be reimported.

This blog presents an alternative method to the Fiori app Upload Business Configuration. One restriction of the Upload Business Configuration app is that it does not validate the customizing data being uploaded.
In contrast, customizing data imported into Business Configuration (BC) Sets via ADT originates from existing customizing requests. This data is created within custom business configuration objects, where it is automatically validated through the underlying BO behavior (for example, error codes greater than 500 are rejected):

This blog covers the following topics:

Create Business Configuration Maintenance Object

The Business Configuration Maintenance Object discussed in this blog can be developed using the following tutorial, which guides you in creating a table for storing error codes:

Create Business Configuration Maintenance Object | SAP Tutorials

Providing Authorization Control for a Business Configuration Maintenance Object

To use the Business Configuration Maintenance Object, the required authorization must be set up. How to do this is explained in this tutorial:

Providing Authorization Control for a Business Configuration Maintenance Object | SAP Tutorials

Creating customizing data & translations

Maintain following customizing data as described in tutorial Use Custom Business Configurations app on a new customizing request:

Error Code	Description
400	Bad Request
401	Unauthorized
403	Forbidden

Afterwards your customizing request should include the primary customizing data as Customizing: Table Contents. Such customizing requests can be used for importing into a BC Set. Corresponding data records and translations will be extracted automatically during the process.

Maintain customizing translations for source language English United States and target language, for example German Germany, for the error codes using the Maintain Customizing Translations app.

Select the text table ZERRCODET_### that was created earlier as text source in your translation project.

Creating a BC Set and importing customizing data & translations

Follow the steps provided in Creating Business Configuration Sets to create a new business configuration set and use the customizing request that was created in the previous step for importing the data.

After successful import from the customizing request the error code data records as well as translations are included:

We can now proceed to implement an application job that can be used activate this BC Set.

Note: To import customizing data into a BC Set, the customizing data needs to be maintained for customizing objects of type Individual Transaction Object. A business configuration maintenance object (CUBCO) is configured as such by defining a transport object definition (TOBJ) in the service configuration settings of the CUBCO. By using the business configuration maintenance object wizard as described in Create Business Configuration Maintenance Object | SAP Tutorials, this prerequisite is fulfilled. For more information, please refer to Generating a Business Configuration Maintenance Object with the Generate ABAP Repository Objects Wizard → BC Management. Configuration changes are then recorded with object type TDAT instead of a TABU.

Those business configuration maintenance objects without existing transport object definition must be migrated, and a transport object definition needs to be created manually. How this can be done is described in the blog post How to enable BC Set support for BC app.

Creating an Application Job for the BC Set activation

In this example, an Application Job is used for creating and updating the customizing entries in a SaaS tenant. The customizing entries are deployed within the Application Job's implementation by activating the business configuration set using the corresponding runtime API.

As a first step, implement the BC Set activation as the business logic of the of the application job with a parameter for the BC Set to be activated and while saving activation messages in the application log:

CLASS zcl_errorcode_set_activate_000 DEFINITION
  PUBLIC FINAL
  CREATE PUBLIC.

  PUBLIC SECTION.
    "! <p class="shorttext synchronized">Error Codes BC Set</p>
    DATA errorcode_bc_set TYPE cl_scpr_cd_bcset_activation=>ty_bcset_id VALUE 'Z_ERROR_CODES_SET_000'.

    INTERFACES if_apj_rt_run.
    INTERFACES if_apj_dt_defaults.

  PRIVATE SECTION.
    CONSTANTS log_object    TYPE cl_bali_header_setter=>ty_object    VALUE 'Z_ERRORCODE_SET_000'.
    CONSTANTS log_subobject TYPE cl_bali_header_setter=>ty_subobject VALUE 'ACTIVATE'.
ENDCLASS.

CLASS zcl_errorcode_set_activate_000 IMPLEMENTATION.
  METHOD if_apj_dt_defaults~fill_attribute_defaults.
    errorcode_bc_set = 'Z_ERROR_CODES_SET_000'.
  ENDMETHOD.

  METHOD if_apj_rt_run~execute.
    TRY.
        DATA(lo_bali_log) = cl_bali_log=>create_with_header(
                                header = cl_bali_header_setter=>create( object    = log_object
                                                                        subobject = log_subobject ) ).
        TRY.
            DATA(lo_bcset_activate) = cl_scpr_cd_bcset_activation=>of( errorcode_bc_set ).
          CATCH cx_scpr_object_not_permitted INTO DATA(lx_scpr_object_not_permitted).
            lo_bali_log->add_item(
                item = cl_bali_exception_setter=>create( severity  = if_bali_constants=>c_severity_error
                                                         exception = lx_scpr_object_not_permitted ) ).
        ENDTRY.

        DATA(lo_activation_handler) = lo_bcset_activate->get_activate_handler( ).

        DATA(lo_activation_result) = lo_activation_handler->local( )->add_activation_options( )->start( ).

        DATA(lt_activation_messages) = lo_activation_result->get_messages( ).

        LOOP AT lt_activation_messages INTO DATA(ls_msg).
          lo_bali_log->add_item( item = cl_bali_message_setter=>create_from_bapiret2( message_data = ls_msg ) ).
        ENDLOOP.

        cl_bali_log_db=>get_instance( )->save_log_2nd_db_connection( log                        = lo_bali_log
                                                                     assign_to_current_appl_job = abap_true ).

      CATCH cx_bali_runtime INTO DATA(lx_bali_runtime).
        RAISE EXCEPTION TYPE cx_apj_rt_content USING MESSAGE
          EXPORTING previous = lx_bali_runtime.
    ENDTRY.
  ENDMETHOD.
ENDCLASS.

Then create a catalog entry and job template for the class with the business logic: Creating a Job Catalog Entry and a Job Template. Also create an application log object and sub object according to the job logic implementation: Working with Application Log Objects.

To run the application job for BC Set activation, users must have the authorization provided by a business catalog. In this case we will reuse the business catalog Z_ERROR_CODES_### that was already created as part of the tutorial Providing Authorization Control for a Business Configuration Maintenance Object.

The business catalog Z_ERROR_CODES_### already includes the IAM App of type MBC (Business Configuration App) that was created for the CUBCO. During creation of the job catalog entry for the BC Set activation job, another IAM app with name <job catalog entry name>_SAJC is automatically created (refer to Setting up the Authorizations). This IAM app, to start the application job, is added to the existing business catalog so that the catalog provides authorizations to maintain error codes in the CUBCO as well as to start the BC Set activation job:

The BC Set activation implemented in the activation job using the CL_SCPR_CD_BCSET_ACTIVATION API requires table access for all entities used in the BC Set, so for both the primary tables as well as text tables. This can be achieved by adding the names of the tables in the TABLE authorization field of the existing S_TABU_NAM authorization in the _MBC IAM app: in this case ZERRCODET_000 (text table) and ZERRCODE_000 (primary table):

Hint: If you plan to run the BC Set activation job in your development system, do not forget to publish your changes to the business catalog locally.

Deploying the BC Set content by running the application job

Make sure that the user that shall run the BC Set activation job has following business roles/catalogs assigned in the ABAP tenant (for example your SaaS consumer tenant):

Business Role	Business Catalog	Purpose
SAP_BR_ADMINISTRATOR	SAP_CORE_BC_APJ_JCE	For scheduling jobs in the Application Jobs app
SAP_BR_BPC_EXPERT	SAP_CORE_BC_BCT_MBC_PC	To use the Custom Business Configurations app
ZBR_ERROR_CODES_EXPERT_###	Z_ERROR_CODES_###	To maintain error codes in the Custom Business Configurations app and to start the BC Set activation job. As created in tutorial Providing Authorization Control for a Business Configuration Maintenance Object

Open the Application Job App and select "Create" to create a new Application Job, then
choose the Application Job Template. Maintain the scheduling options and provide a valid BC Set in the parameter. Schedule the Application Job by clicking "Schedule".

Check the Application Job Log to determine if the BC Set content was deployed correctly:

Users assigned to the required business roles (see above) can now check in the Custom Business Configurations App whether the customizing has been inserted and updated correctly:

Maintaining customizing data programmatically in BC Sets

You might want to automate the lifecycle of your customizing data. For instance, you can update a BC Set with the latest customizing data after some changes. To do this, maintain your changes in EML within the configuration object on a customizing request. Then read the latest data from the underlying customizing tables and finally update the BC Set.

You can programmatically create a customizing request using the XCO CTS module. EML will then be used to maintain the data on that customizing request. Additionally, you have the option to programmatically release the customizing request afterward.

CLASS zcl_errorcode_generate_000 DEFINITION
  PUBLIC FINAL
  CREATE PUBLIC.

  PUBLIC SECTION.
    INTERFACES if_oo_adt_classrun.

  PRIVATE SECTION.
    TYPES tyt_errorcodes            TYPE STANDARD TABLE OF zerrcode_000 WITH KEY error_code.
    TYPES tyt_errorcodestext        TYPE STANDARD TABLE OF zerrcodet_000 WITH KEY langu error_code.
    TYPES tyt_errorcodes_update     TYPE TABLE FOR UPDATE ZI_ErrorCode000.
    TYPES tyt_errorcodestext_update TYPE TABLE FOR UPDATE ZI_ErrorCode000Text.

    METHODS delete_errorcodes
      IMPORTING transportrequest TYPE trkorr.

    METHODS create_errorcodes
      IMPORTING transportrequest      TYPE trkorr
                it_errorcodes_crt     TYPE tyt_errorcodes
                it_errorcodestext_crt TYPE tyt_errorcodestext.

    METHODS update_errorcodes
      IMPORTING transportrequest         TYPE trkorr
                it_errorcodes_update     TYPE tyt_errorcodes_update
                it_errorcodestext_update TYPE tyt_errorcodestext_update.

    CONSTANTS co_cust_transport_target      TYPE if_xco_transport_target=>tv_value      VALUE ''.                                          " LOCAL
    CONSTANTS co_cust_transport_description TYPE sxco_ar_short_description              VALUE 'Maintain new error codes programmatically'.
ENDCLASS.


CLASS zcl_errorcode_generate_000 IMPLEMENTATION.
  METHOD if_oo_adt_classrun~main.
    " Create customizing transport request
    DATA(lo_customizing_request) = xco_cp_cts=>transports->customizing( co_cust_transport_target )->create_request(
        co_cust_transport_description ).

    " Programmatically create new error codes using EML
    create_errorcodes( transportrequest      = lo_customizing_request->value
                       it_errorcodes_crt     = VALUE tyt_errorcodes( ( error_code = '404' )
                                                                     ( error_code = '405' )
                                                                     ( error_code = '406' ) )
                       it_errorcodestext_crt = VALUE tyt_errorcodestext(
                           ( langu  = 'D' error_code  = '404' description = 'Not Found' )
                           ( langu  = 'E' error_code  = '404' description = 'Nicht gefunden' )
                           ( langu  = 'D' error_code  = '405' description = 'Method Not Allowed' )
                           ( langu  = 'E' error_code  = '405' description = 'Methode nicht erlaubt' )
                           ( langu  = 'D' error_code  = '406' description = 'Not Acceptable' )
                           ( langu  = 'E' error_code  = '406' description = 'Nicht akzeptabel' ) ) ).

    " Release customizing tasks and customizing request
    DATA(lt_transport_tasks) = lo_customizing_request->get_tasks( ).

    LOOP AT lt_transport_tasks INTO DATA(lo_transport_task).
      IF lo_transport_task->get_status( ) <> xco_cp_transport=>status->modifiable.
        CONTINUE.
      ENDIF.

      lo_transport_task->release( ).
    ENDLOOP.

    lo_customizing_request->release( ).

  ENDMETHOD.

  METHOD create_errorcodes.
    DATA lt_errorcode_create TYPE TABLE FOR CREATE ZI_ErrorCode000_S\_ErrorCode000.
    TYPES tys_errorcode_create LIKE LINE OF lt_errorcode_create.
    DATA ls_errorcode_create      TYPE tys_errorcode_create.

    DATA lt_errorcodestext_create TYPE TABLE FOR CREATE ZI_ErrorCode000\_ErrorCode000Text.
    TYPES tys_errorcodestext_create LIKE LINE OF lt_errorcodestext_create.
    DATA ls_errorcodestext_create TYPE tys_errorcodestext_create.

    LOOP AT it_errorcodes_crt INTO DATA(wa_errorcode_crt).

      ls_errorcode_create = VALUE #( SingletonID = 1
                                     %target     = VALUE #( ( ErrorCode          = wa_errorcode_crt-error_code
                                                              %control-ErrorCode = if_abap_behv=>mk-on ) ) ).
      APPEND ls_errorcode_create TO lt_errorcode_create.

    ENDLOOP.

    LOOP AT it_errorcodestext_crt INTO DATA(wa_errorcodestext_crt).
      ls_errorcodestext_create = VALUE #(
          %tky-ErrorCode = wa_errorcodestext_crt-error_code
          %target        = VALUE #( ( Langu                = wa_errorcodestext_crt-langu
                                      %control-Langu       = if_abap_behv=>mk-on
                                      Description          = wa_errorcodestext_crt-description
                                      %control-Description = if_abap_behv=>mk-on ) ) ).

      APPEND ls_errorcodestext_create TO lt_errorcodestext_create.

    ENDLOOP.

    MODIFY ENTITIES OF ZI_ErrorCode000_S
           ENTITY ErrorCode000All
           UPDATE
           FIELDS ( TransportRequestID )
           WITH VALUE #( ( SingletonId        = 1
                           TransportRequestID = transportrequest ) )

           ENTITY ErrorCode000All
           CREATE BY \_ErrorCode000 FROM lt_errorcode_create
           REPORTED DATA(r_errorcodes_crt)
           FAILED   DATA(f_errorcodes_crt)
           MAPPED   DATA(m_errorcodes_crt) ##NEEDED.

    MODIFY ENTITIES OF ZI_ErrorCode000_S
           ENTITY ErrorCode000
           CREATE BY \_ErrorCode000Text FROM lt_errorcodestext_create
           REPORTED DATA(r_errorcodestext_crt)
           FAILED   DATA(f_errorcodestext_crt)
           MAPPED   DATA(m_errorcodestext_crt) ##NEEDED.

    COMMIT ENTITIES
           BEGIN RESPONSE OF ZI_ErrorCode000_S
           FAILED DATA(failed_create)
           REPORTED DATA(reported_create) ##NEEDED.
    COMMIT ENTITIES END.
  ENDMETHOD.

  METHOD delete_errorcodes.
    MODIFY ENTITIES OF ZI_ErrorCode000_S
           ENTITY ErrorCode000All
           UPDATE
           FIELDS ( TransportRequestID )
           WITH VALUE #( ( SingletonId        = 1
                           TransportRequestID = transportrequest ) )

           FAILED DATA(f_delete_tr)
           MAPPED DATA(m_delete_tr)
           REPORTED DATA(r_delete_tr) ##NEEDED.

    MODIFY ENTITIES OF ZI_ErrorCode000_S
           ENTITY ErrorCode000All
           CREATE FIELDS ( TransportRequestID ) WITH VALUE #( ( TransportRequestID  = transportrequest ) )
           DELETE FROM VALUE #( ( SingletonID = 1 ) )
           FAILED DATA(f_delete)
           MAPPED DATA(m_delete)
           REPORTED DATA(r_delete) ##NEEDED.

    COMMIT ENTITIES
           BEGIN RESPONSE OF ZI_ErrorCode000_S
           FAILED DATA(failed_delete)
           REPORTED DATA(reported_delete) ##NEEDED.
    COMMIT ENTITIES END.
  ENDMETHOD.

  METHOD update_errorcodes.
    DATA lt_errorcodestext_update_i TYPE TABLE FOR UPDATE ZI_ErrorCode000Text.

    IF it_errorcodes_update IS NOT INITIAL OR it_errorcodestext_update IS NOT INITIAL.
      LOOP AT it_errorcodestext_update INTO DATA(ls_errorcodetext_update).
        ls_errorcodetext_update-%control-Description = if_abap_behv=>mk-on.
        APPEND ls_errorcodetext_update TO lt_errorcodestext_update_i.
      ENDLOOP.
    ENDIF.

    MODIFY ENTITIES OF ZI_ErrorCode000_S
           ENTITY ErrorCode000All
           UPDATE
           FIELDS ( transportrequestid )
           WITH VALUE #( ( SingletonID        = 1
                           TransportRequestID = transportrequest ) )

           ENTITY ErrorCode000Text
           UPDATE FROM lt_errorcodestext_update_i

           REPORTED DATA(r_errorcodes_upd)
           FAILED   DATA(f_errorcodes_upd)
           MAPPED   DATA(m_errorcodes_upd) ##NEEDED.

    COMMIT ENTITIES
           BEGIN RESPONSE OF ZI_ErrorCode000_S
           FAILED DATA(failed_update)
           REPORTED DATA(reported_update) ##NEEDED.
    COMMIT ENTITIES END.
  ENDMETHOD.
ENDCLASS.

The advantage of using EML to create, update, and delete customizing entries is that all validations of the business configuration object (BCO) are performed. This approach also supports both customizing entries of type table data (TABU) and individual transaction object (TDAT) since API adapters are available for both cases to be used in the behavior implementation of the BCO (for example, mbc_cp_api=>rap_tdat_cts()). For further information, refer to Transport Handling.

After updating the customizing data in the Business Configuration Object (BCO) using EML, the latest customizing data can be retrieved from the underlying customizing tables for further processing. Once the up-to-date customizing data is obtained, it can be directly maintained in the BC Set. This process utilizes the XCO generation APIs for BC Sets.

CLASS zcl_errorcode_generate_000 DEFINITION
  PUBLIC FINAL
  CREATE PUBLIC.

  PUBLIC SECTION.
    INTERFACES if_oo_adt_classrun.

  PRIVATE SECTION.
    CONSTANTS co_workbench_request          TYPE trkorr                                 VALUE ''.                                          " ZLOCAL
    CONSTANTS co_error_codes_set_name       TYPE if_xco_business_cnfgrtn_set=>tv_name   VALUE 'Z_ERROR_CODES_SET_000'.

    CONSTANTS co_error_codes_entity_primary TYPE if_xco_bcs_entity=>tv_name             VALUE 'ZERRCODE_000'.
    CONSTANTS co_error_codes_entity_text    TYPE if_xco_bcs_entity=>tv_name             VALUE 'ZERRCODET_000'.
    CONSTANTS co_error_codes_tobj           TYPE if_xco_bcs_customizing_object=>tv_name VALUE 'ZERRORCODE000'.

ENDCLASS.

CLASS zcl_errorcode_generate_000 IMPLEMENTATION.
  METHOD if_oo_adt_classrun~main.
    " Read latest error codes from customizing tables
    SELECT * FROM zerrcode_000 WHERE error_code < 500 INTO TABLE (lt_errorcodes).
    ASSERT sy-subrc = 0.

    SELECT * FROM zerrcodet_000 WHERE error_code < 500 INTO TABLE (lt_errorcodes_text).
    ASSERT sy-subrc = 0.

    " Retrieve error codes BC set and make sure it exists
    DATA(lo_business_configuration_set) = xco_cp_abap_repository=>object->scp1->for( co_error_codes_set_name ).
    ASSERT lo_business_configuration_set->if_xco_ar_object~exists( ).

    " Create BC Set patch operation and change specification to remove existing error codes customizing object (all its Entities and corresponding records)
    DATA(lo_patch_operation_delete) = xco_cp_generation=>environment->dev_system( co_workbench_request )->for-scp1->create_patch_operation( ).
    DATA(lo_change_specification_delete) = lo_patch_operation_delete->add_object( co_error_codes_set_name )->create_change_specification( ).
    lo_change_specification_delete->for-delete->add_individual_transaction_obj( co_error_codes_tobj ).

    " Create BC Set patch operation and change specification to insert latest error codes using latest customizing data
    DATA(lo_patch_operation_insert) = xco_cp_generation=>environment->dev_system( co_workbench_request )->for-scp1->create_patch_operation( ).
    DATA(lo_change_specification_insert) = lo_patch_operation_insert->add_object( co_error_codes_set_name )->create_change_specification( ).
    DATA(lo_tobj_insert) = lo_change_specification_insert->for-insert->add_individual_transaction_obj(
                               co_error_codes_tobj ).
    lo_tobj_insert->for-insert->add_entity( co_error_codes_entity_primary )->for-insert->add_records(
                                                                              REF #( lt_errorcodes[] ) ).
    lo_tobj_insert->for-insert->add_entity( co_error_codes_entity_text )->for-insert->add_records(
                                                                           REF #( lt_errorcodes_text[] ) ).

    " After preparing the change specifications, execute the PATCH operations
    TRY.
        DATA(lo_result_delete) = lo_patch_operation_delete->execute( ) ##NEEDED.
        DATA(lo_result_insert) = lo_patch_operation_insert->execute( ) ##NEEDED.

      CATCH cx_xco_gen_patch_exception INTO DATA(lo_xco_gen_patch_exception).

        LOOP AT lo_xco_gen_patch_exception->findings->get( ) ASSIGNING FIELD-SYMBOL(<fs_finding>) ##NEEDED.
          " Process errors/exceptions raised from the PATCH operation
        ENDLOOP.
    ENDTRY.
  ENDMETHOD.

ENDCLASS.

This section of using the XCO generation API for BC Sets to update BC set data requires customizing entries of type individual transaction object (TDAT). This is because it’s a requirement for importing any data into a BC Set. BC Sets are workbench objects and can be delivered alongside other development objects in your development software components.

Hint: In productive scenarios remove the ##NEEDED pragma from the code examples and implement proper error handling!

ABAP AI Podcast: Reflecting on 2025 and Looking Ahead to 2026

2026-02-05T11:20:57.156000+01:00

2025: The Year ABAP AI Became Tangible

As Simona and I reflected on 2025, one theme stood out: it was the year ABAP AI stopped being a promise and became something developers could touch, use, and trust. That shift didn’t happen all at once — it was shaped across the year through a series of releases that progressively deepened what ABAP and AI could do together.

The journey began with Release 2502, our first big delivery, which marked a turning point for the ABAP developer experience. This release introduced the foundational AI capabilities that developers immediately felt in their workflow: the initial wave of explain ability for ABAP and CDS, predictive and context‑aware code suggestions, and early ABAP Cloud compliance insights. 2502 was a statement: ABAP AI had arrived, and it was ready for real use cases.

Building on this momentum, Release 2505 expanded and strengthened the story. the RAP BO Generator for Fiori applications. The explain model grew to cover more ABAP constructs, predictive assistance became more capable, and clean‑core compliance checks were enhanced to give developers clearer, more actionable guidance.

Toward the end of the year, Release 2508 brought refinement and specialization. AI guidance became more scenario‑aware — better tuned for migration, modernization, and, AI‑supported extensibility patterns. Autogenerated documentation became richer and more reliable. Custom code migration also received a boost with deeper AI‑powered insights and more intelligent documentation support — small but meaningful improvements that helped teams move faster and with more confidence.

And throughout all of this, we made sure customers in private cloud were not left behind. With the 2025 PCE add‑ins, Joule for Developers became available to S/4HANA Private Cloud Edition customers as well — enabling AI‑assisted custom code migration, modernization support, and clean‑core guidance even for those on older releases. This was a major step in democratizing ABAP AI and bringing its value to a much broader installed base.

Key Features and Developer Impact

With Joule for Developers, ABAP developers immediately benefited from a range of intelligent capabilities, including:

Predictive and context‑aware code suggestions
Automated ABAP Cloud compliance checks
Natural‑language explanations for both legacy and new ABAP code and extended explain use for autogenerated technical documentation
Developers could even generate complete Fiori applications simply by describing the functional requirements.

These advancements significantly accelerated development cycles and reduced manual effort. AI also enhanced custom code migration by proposing simplifications, improving code quality, and easing the transition to clean‑core architectures.

ABAP and AI: A Strengthened Relationship

Simona shared insights into why ABAP required SAP‑specific AI models. Because ABAP is proprietary, large language models were not initially trained on it. SAP addressed this by training internal models on over 250 million lines of ABAP code and 30 million lines of CDS views, unlocking high‑quality AI support tailored specifically to ABAP.

To hear the full conversation, listen to the episode: ABAP AI Podcast: Reflecting on 2025 and Looking Ahead to 2026

Another important point we touched on in the conversation is how ABAP AI brings together the best of both worlds. SAP pairs its own ABAP‑specialized models—trained on hundreds of millions of lines of ABAP and CDS code—with best‑of‑breed third‑party foundation models. This hybrid approach ensures developers always get the most accurate and context‑aware support for ABAP tasks, while still benefiting from the broad language understanding and creativity of large general‑purpose models. And for customers who are primarily interested in explain ability, SAP also offers the explain‑only model through the AI Hub, making ABAP‑focused code explanations accessible even without the full Joule for Developers experience.

Far from replacing developers, AI strengthens the ABAP ecosystem. The ABAP community has shown excitement and readiness to embrace these advancements, seeing AI as a powerful augmentation of their skills.

2026: Scaling the Promise

Looking forward, 2026 is shaping up to be a pivotal year of scaling ABAP AI. SAP plans to bring AI capabilities to customers running older private cloud releases through a side‑by‑side version of Joule for Developer, ensuring broader access also for customers on older S4HANA versions.

SAP will also add to it agentic tools and frameworks and an ABAP MCP Server, enabling SAP teams and partners to build intelligent agents that automate development tasks and connect seamlessly into an integrated agentic ecosystem. Investment in AI‑assisted custom code migration will continue, focusing on clean‑core compliance and automated code simplification proposals.

VS Code and Modern Tooling

A major priority for 2026 is establishing VS Code as a first‑class development environment for ABAP. By combining VS Code’s modern developer experience with Joule and AI‑centric capabilities, SAP aims to reposition ABAP as a future‑proof, cloud‑native, enterprise‑grade language.

Trust and Enterprise Readiness

As AI evolves, SAP continues to emphasize safety, compliance, and enterprise‑grade ethics. All AI use cases undergo rigorous validation to meet SAP’s security and trust standards.

Custom Code Migration (CCM)

A core focus area we highlighted in the podcast is the continued evolution of Custom Code Migration (CCM) and its central role in helping customers transition to clean‑core, cloud‑ready architectures. Throughout 2025, AI became a powerful companion in this journey — analyzing legacy patterns, identifying simplification opportunities, and guiding developers toward more future‑proof designs. With Joule for Developers, teams benefit from usage‑aware insights, automated refactoring suggestions, and richer technical documentation that dramatically reduces the manual effort usually tied to migration projects. As we move into 2026, CCM is set to scale even further, with deeper automation and more intelligent guidance that make modernization and S/4HANA transitions faster, more predictable, and far less error‑prone.

Conclusion

The year 2025 proved the real, tangible value of ABAP AI. In 2026, ABAP and AI will become inseparable—empowering developers with intelligent tools that make coding faster, smarter, and more reliable. The vision is clear: the future of ABAP development is deeply AI‑enhanced, enabling organizations to innovate with confidence and speed.

Stop Building from Scratch: Autonomous AI Agents for SAP Sales Order Processing

2026-02-07T18:50:48.664000+01:00

Why this article?

It is great that we are living in the era of AI technologies where humans are still needed to design and automate 😀. But let’s be honest: give it a few more years and no company will ask "Which AI platform should we choose?" That decision will be made by central AI services based on strict country and corporate regulations. The only thing that will matter is security and reliability.

So, why am I writing this? Because I see so many people struggling with custom, built-from-scratch AI automation solutions at the enterprise level. These projects start quickly, but they get stuck just as fast.

You know, it is like cookies 😀. You can make one in a sandbox; however, to scale that to a corporate production level is a totally different problem.

If you are still wondering why this article matters: I want to highlight that while humans are still designing automation, speed is everything. Deploying autonomous AI agents on a solid, reliable platform is a massive competitive advantage. Those playing around with internal IT projects or relying on System Integrators (SI) to build from zero are being left behind.

Let me explain why using one simple example: Customer Purchase Orders.

The Business Case: The Reality of POs

A company wins a deal (congratulations!), and the Customer sends a Purchase Order (PO).

In an ideal world, this happens via EDI. If you have EDI, you are lucky and you can stop reading. But in the real world, customers send PDFs, scanned images with handwriting, Excel files with macros, or even a screenshot of their laptop screen.

This shouldn't be an issue. Innovative platforms must handle data extraction from unstructured sources out of the box.

“Training? Fine-tuning??”

I know some of you just thought that 😊. Yes, training OCR models used to be mandatory. If you haven't faced the pain of training models, be happy, because you are young enough 😊. Today, this must work without that hassle.

The Main Challenge: Master Data Mapping

Extracting text is easy. The real challenge is my favorite one: Master Data Mapping.

How do we robustly and reliably read the customer’s product description and map it to the correct Master Data Object in our SAP system? And how do we do it without heavy development?

The Solution: SAP Master Data Vectorization

We don't need custom code; we need Vectorization.

Generative AI can write SQL queries, sure. But think about it: how many SQL queries would the AI have to guess to find a material that is semantically similar but written differently? Infinite. Or maybe a few less if you are lucky and the description contains an acronym like "A4 Paper" 😊.

When AI looks for a material master in vectorized data (rather than a database table), it reads by sense, not just by keywords. This allows it to reliably find the right SAP object even if the customer's description is vague.

I know only one SAP-certified Business AI Platform that has this Vectorization feature in its standard set: Skybuffer AI.

Pic.1 SAP Master Data Vectorization Setup

Pic.2 Example of Material Master Similarities based Search

The Implementation: Autonomous Agents in Action

This is the essential part: stop playing in the sandbox. Take a platform and create a simple autonomous AI agent.

In this example, I am using Skybuffer AI because it handles the heavy lifting out of the box:

Vectorizes SAP master data for semantic search.
Reads Emails (including complex attachments and OCR).
Safety First: Uses Mailboxes as a staging area (no messy data replication).
ABAP Control: It doesn't let the AI "guess" how to create data. It passes structured JSON to an ABAP class/BAPI for safe execution.
No Code: configured entirely in SAP Fiori.

The Flow

A Skybuffer AI agent acts effectively as an automated employee. You can schedule it, give it tools, and let it run.

Pic.3 Scheduling Autonomous AI Agent

Step 1: The Input

The Agent connects to a Mailbox. It reads the email, extracts the attachment data, and places it into the Agent's memory.

Pic.4 Flow inside the Tool of Skybuffer AI Action Server

Step 2: The Brain (Generative AI)

We connect the Generative AI and give it guidelines.

Note: The vectorized SAP master data is mapped directly to this action.

Pic.5 Generative AI Action of Skybuffer AI Action Server

The AI creates a JSON structure based on our request. Crucially, we do not ask the AI to update SAP directly. We hand that JSON over to an SAP ABAP class. This ensures the transactional data is created correctly, without hallucinations.

Step 3: The Output

We update the email in the Mailbox with the status and send a confirmation back to the customer.

Everything runs either in your SAP HANA On-Premise shell (directly in your network) or on your SAP BTP tenant.

Conclusion

Autonomous AI agents are no longer "future tech", they are easy solutions available now.

By choosing a Business AI automation platform rather than building from scratch, your company gets the best of Generative AI and the SAP backend immediately.

It is strange that so many companies are still "playing" with in-house development. You wouldn't build your own Sales Order Management system from scratch instead of using SAP, right? 😊 That would be weird. Yet, companies are giving huge budgets to internal teams to build AI wrappers.

You don't need a giant team. You need a reliable solution, speed, and flexibility. Just look at Cursor, they revolutionized coding with roughly 60 employees before their massive 900M funding round 😉.

Be quick. Be autonomous.

International Editable SALV Day 2026 – Year 18

2026-02-07T23:36:20.726000+01:00

International Editable SALV Day 2026 – Year 18

Dear CL_SALV_TABLE Fans,

Welcome to February 8th, 2026, which is the eighteenth International Editable SALV Day. See below for a link to a blog I wrote to celebrate this day exactly one year ago.

https://community.sap.com/t5/technology-blogs-by-members/international-editable-salv-day-2025/ba-p/14011230#M171694

This day marks the 18h anniversary of James Hawthorne going cap in hand to SAP and suggesting maybe the CL_SALV_TABLE could be brought up to functional parity with the CL_GUI_ALV_GRID and have an option to be editable.

https://community.sap.com/t5/application-development-discussions/cl-salv-table-needs-editable-functionality-sap-please-provide-this/m-p/3372776

Some popular pop songs are about ABAP features that should have been added 18 years ago – of which there are more than you might think – they often focus on the transition to adulthood, freedom, and nostalgia, featuring tracks like "18" by One Direction and 5 Seconds of Summer, Alice Cooper’s anthem "I'm Eighteen and wonder what a DYNPRO is," and Khalid's "ABAPUNIT". These songs highlight the mix of excitement, uncertainty, and "growing pains" associated with leaving adolescence and having to learn procedural programming and then leave it behind.

I Wish to Table a Motion

The CL_SALV_TABLE was sold as an improvement to the “classic” CL_GUI_ALV_GRID.

SAP is a German company. I lived in Germany for many years. There is a German word “verschlimmbessern” which in English translates to “An Improvement Which Makes Things Worse”. It is good they have a specific word for this. In this specific example the “improvement” was to remove the one thing that made the end users love the CL_GUI_ALV_GRID and replace it with something that made it easier for the developers. But think about it – who is more important to the business? The end users who actually make the money or the developers? Who should you be trying to please?

My whole point, what I have been trying to say all these years, years full of tears, is why cannot one have the best of both worlds? Easy for the end users AND easy for the developers. Is that too much to ask?

Now, way back in 2001, I was at SAP TECHED, and the idea of “embedded analytics” was demonstrated.

The logic being is that one would want to call up a list of sales orders (or whatever) that had errors of some sort, and then fix those errors one by one, all in the same transaction.

I put it to you, ladies and gentlemen of the jury, that this fundamental concept has not changed in the 25 years since this was first shown to me as a prototype.

Just to make this 100% clear, one does not just want to see the incorrect data, one wants to interact with it, in order to correct it.

The current proposition is that only UI5/Fiori can do this, in a screen that looks just like an ALV Grid, only a little bit uglier, and a little bit slower But, it is marketed as a “delightful” experience, so that is all right then.

Now, just to make this exercise even more futile I am posting this on the SAP Community Website – which no-one ever visits anymore.

The SAP GUI is not going anywhere. You may have noticed SAP just extended the life of ECC 6.0 by three more years, albeit with conditions. And even when an organization goes onto S/4HANA often they still use the SAP GUI because people like it. They have moaned about it non-stop for thirty years, but they like it really.

It has been argued that Fiori apps which have a single purpose are the way forward.

Now I have tried these I feel it is a quantum step backwards. One app to set the delivery quantity, one app to set the picking quantity, yet another app to do the goods issue. When it used to be all done in one step in the GUI? Did anyone ever think about this?

In real life end users tend to like SAP GUI applications with million buttons. You can pretend that is not true, but you would be lying to yourself. Take Excel or Word for example and look at how many options they have.

Now, I am just going to repeat what I said last year, word for word.

It is as simple as this.

You get asked to write a read-only ALV report.
It is faster and simpler to do this using CL_SALV_TABLE than CL_GUI_ALV_GRID because you do not have to mess around with screens and controls and what-not.
Indeed, SAP recommend using CL_SALV_TABLE for all new developments of this nature.
The report goes live. The users start asking for extra things, as always.
They want some custom functions at the top of the screen.
They want to be able to change some of the fields and have that replicate to the database.
Well, you are right out of luck. You cannot do either with CL_SALV_TABLE.
There are workarounds for both, but they are scary, because SAP keeps finding ways to shut those workarounds down, so such an approach is not future proof.
The only viable option is to start again, this time using CL_GUI_ALV_GRID.
Then the next time you get a request for a “read-only” report the “once bitten twice shy” thing kicks in and you start with CL_GUI_ALV_GRID from the get-go.

I like CL_SALV_TABLE and so do a lot of SAP developers. But everyone (end users) likes having the editability feature a lot more. But it’s never going to happen. As has been mentioned you would think that if 100% of your customers want something you might consider giving it to them, but obviously not.

Very soon – maybe already - we will get to the stage some people reading this blog will be younger than the age of the request to make the SALV editable. Since the SAP GUI is not going anywhere (evidenced by the huge amount of development money pumped into every year by SAP) it is possible I will die of old age before the request is actioned. I am 57 already.

Nevertheless, I will keep going. Miracles can happen.

Until then the situation is “Oi you 31,000 SAP ERP Customers! You see this? You like this? You want this? Well, you can’t have it!”

See you next year!

Cheersy Cheers

Paul

PS I must admit I had an AI help me with the pictures this time. Made sense to me, no problems with copyright. I had told it what I was doing, and it said do you want me to write/publish the blogs for you in the next years, and I said no, but when I am dead YES, keep this going forever. I will probably die circa 2040. Will people still be using SAP GUI then? YES!

Automating Purchase Requisition Rejection - ME54N and Fiori My Inbox

2026-02-09T07:54:42.078000+01:00

Background

SAP Note 2012650 – “BAPI_REQUISITION_RELEASE is not possible to reject PR” clearly states that Purchase Requisitions cannot be rejected using BAPI_REQUISITION_RELEASE and that rejection must be performed manually via transaction ME54N.

There are scenarios where manual rejection is not feasible or creates significant operational overhead. In my case, I needed a way to trigger Purchase Requisition rejection programmatically while staying as close as possible to standard behavior.

This requirement led me to search for an alternative approach.

While ME54N is the classic transaction for rejecting PRs, many users also perform approval and rejection activities through Fiori My Inbox. These two entry points do not rely on BAPI_REQUISITION_RELEASE for rejection.

During my analysis, I noticed that the class CL_MM_PUR_PR_APPR_ACTION_BADI plays a central role in handling approval and rejection actions triggered from Fiori. This class became the starting point for my solution.

During my research, I came across a well-written blog describing another approach for Purchase Requisition rejection. Unfortunately, I could not make that solution work in my system, so I explored a different path which resulted in the approach presented here.

Approach

The solution consists of two main steps:

Trigger rejection logic using CL_MM_PUR_PR_APPR_ACTION_BADI
- This ensures that the approval work item is removed from Fiori My Inbox.
- The PR is treated consistently with the standard workflow behavior.
Call ME_UPDATE_REQUISITION using classic techniques
- After the inbox item is cleared, the Purchase Requisition is updated using standard update logic.
- This mimics the behavior executed when rejection is performed via ME54N.

Important Notes

This is not necessarily the best or only approach, but rather one possible alternative when no standard BAPI exists.
The provided development is intended as a template only. You can revise and adapt the example class according to your own requirements.
It represents a custom automation workaround.

Example Implementation

CLASS zmm_cl_utils_pr DEFINITION
  PUBLIC
  FINAL
  CREATE PUBLIC .

  PUBLIC SECTION.
    METHODS : pr_reject
      IMPORTING iv_banfn            TYPE banfn OPTIONAL
      RETURNING VALUE(RV_completed) TYPE abap_bool
      RAISING   cx_mm_pur_requisition.
  PROTECTED SECTION.
  PRIVATE SECTION.
    METHODS get_release_code
      IMPORTING
        iv_banfn              TYPE banfn
      RETURNING
        VALUE(rv_releasecode) TYPE frgab.
    METHODS set_my_inbox_status_rejected
      IMPORTING iv_banfn TYPE banfn
      RAISING   cx_mm_pur_requisition.
    METHODS set_pr_status_rejected
      IMPORTING iv_banfn            TYPE banfn
      RETURNING VALUE(RV_completed) TYPE abap_bool
      RAISING   cx_mm_pur_requisition.
ENDCLASS.


CLASS zmm_cl_utils_pr IMPLEMENTATION.
  METHOD pr_reject.
    set_my_inbox_status_rejected( iv_banfn = iv_banfn ).
    rv_completed = set_pr_status_rejected( iv_banfn = iv_banfn ).
  ENDMETHOD.

  METHOD get_release_code.
    DATA lv_fname TYPE fieldname.

    SELECT SINGLE frgzu, frgst, frggr
      FROM eban
      WHERE banfn = _banfn
      INTO (ls_eban).
    IF sy-subrc <> 0.
      RETURN.
    ENDIF.
    lv_fname = |T16FS~FRGC{ strlen( ls_eban-frgzu ) + 1 }|.
    SELECT SINGLE (lv_fname) FROM t16fs
      WHERE frggr = _eban-frggr
        AND frgsx = _eban-frgst
      INTO @rv_releasecode.
  ENDMETHOD.

  METHOD set_my_inbox_status_rejected.
    CONSTANTS lc_gname_eban TYPE eqegraname VALUE 'EBAN'.
    DATA lv_wiid          TYPE sww_wiid.
    DATA lv_note          TYPE string.
    DATA lv_save_note     TYPE boolean.
    DATA lv_source_appl   TYPE swc_elem.
    DATA lv_garg          TYPE eqegraarg.
    DATA ls_object        TYPE swr_obj_2.
    DATA lt_enq           TYPE STANDARD TABLE OF seqg3.
    DATA lr_pur_wf_object TYPE REF TO cl_mm_pur_wf_object.

    DATA(lv_like) = |%{ iv_banfn }%|.

    SELECT wi_id, wi_stat FROM swwwihead
      WHERE wi_text LIKE _like
        AND wi_stat    = 'READY'
      ORDER BY wi_cd DESCENDING,
               wi_ct DESCENDING
      INTO TABLE (lt_tab)
      UP TO 1 ROWS.
    IF sy-subrc <> 0.
      RAISE EXCEPTION NEW cx_mm_pur_requisition( textid = VALUE #( msgid = 'SWF_RUN'
                                                                   msgno = '003' ) ).
    ENDIF.

    lv_wiid = lt_tab[ 1 ]-wi_id.
    " -->Get the Purchase Requisition Number, Item from the WorkItem
    CALL FUNCTION 'SAP_WAPI_GET_OBJECTS'
      EXPORTING workitem_id      = lv_wiid
      IMPORTING leading_object_2 = ls_object.
    DATA(lv_pr_num)  = ls_object-instid+0(10).
    DATA(lv_pr_item) = ls_object-instid+10(5).
    IF lv_pr_item IS NOT INITIAL.
      lr_pur_wf_object ?= NEW cl_mm_pur_wf_object_pr_item( iv_object_id = CONV #( ls_object-instid ) ).
    ELSE.
      IF lv_pr_num IS NOT INITIAL.
        lr_pur_wf_object ?= NEW cl_mm_pur_wf_object_pr( iv_object_id = CONV #( ls_object-instid ) ).
      ENDIF.
    ENDIF.

    IF lv_pr_item IS NOT INITIAL.
      " Item Level Release
      SELECT SINGLE PurReqnOrigin,CreatedByUser
        FROM I_PurchaseRequisitionItemAPI01
        INTO (ls_origin)
        WHERE PurchaseRequisition     = _pr_num
          AND PurchaseRequisitionItem = _pr_item.
    ELSE.
      " Overall Release
      SELECT PurReqnOrigin,CreatedByUser
        UP TO 1 ROWS
        FROM I_PurchaseRequisitionItemAPI01
        INTO _origin
        WHERE PurchaseRequisition = _pr_num
        " In case if different users have created different items of PR
        " then the Requester would be the First item user.
        ORDER BY PurchaseRequisitionItem.
      ENDSELECT.
    ENDIF.
    " -->Get Decision
    DATA(lv_decision) = CONV swc_elem( if_mm_pur_workflow_c=>gc_decision_0002 ). " REJECTED
    " -->Check if there is a lock on the PR.only in case of overall release.
    IF lv_pr_item IS INITIAL.
      lv_garg = |{ sy-mandt }{ lv_pr_num }*|.
      CALL FUNCTION 'ENQUEUE_READ'
        EXPORTING  gname                 = lc_gname_eban
                   garg                  = lv_garg
                   guname                = ''
        TABLES     enq                   = lt_enq
        EXCEPTIONS communication_failure = 1
                   system_failure        = 2
                   OTHERS                = 3.
      IF sy-subrc = 0.
        IF lt_enq IS NOT INITIAL.
          RAISE EXCEPTION NEW cx_mm_pur_requisition( textid = VALUE #( msgid = 'MMPUR_PR_WFL_COMMON'
                                                                       msgno = '010' ) ).
        ENDIF.
      ELSE.
        RAISE EXCEPTION NEW cx_mm_pur_requisition( textid = VALUE #( msgid = sy-msgid
                                                                     msgno = sy-msgno
                                                                     attr1 = sy-msgv1
                                                                     attr2 = sy-msgv2
                                                                     attr3 = sy-msgv3
                                                                     attr4 = sy-msgv4 ) ).
      ENDIF.
    ENDIF.

    IF lr_pur_wf_object IS BOUND.
      lr_pur_wf_object->set_workitem_executed( EXPORTING iv_wiid        = lv_wiid
                                                         iv_decision    = lv_decision
                                                         iv_note        = lv_note
                                                         iv_save_note   = lv_save_note
                                                         iv_source_appl = lv_source_appl
                                               IMPORTING es_return      = DATA(ls_return) ).
      IF ls_return IS NOT INITIAL.
        RAISE EXCEPTION NEW cx_mm_pur_requisition( textid = VALUE #( msgid = ls_return-id
                                                                     msgno = ls_return-number
                                                                     attr1 = ls_return-message_v1
                                                                     attr2 = ls_return-message_v2
                                                                     attr3 = ls_return-message_v3
                                                                     attr4 = ls_return-message_v4 ) ).
      ENDIF.
      DATA(lo_pr_approval) = cl_mm_pur_approval=>get_instance( ).
      lo_pr_approval->gs_exe_src-execution_source = if_mm_pur_workflow_c=>gc_execution_source_inb.
      lo_pr_approval->gs_exe_src-scenario_type    = ls_object-catid.
    ENDIF.
    CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'.
    WAIT UP TO '0.1' SECONDS.
  ENDMETHOD.

  METHOD set_pr_status_rejected.
    DATA t_xeban     TYPE mereq_t_ueban.
    DATA s_xeban     TYPE ueban.
    DATA t_xebkn     TYPE mereq_t_uebkn.
    " TODO: variable is assigned but never used (ABAP cleaner)
    DATA t_container TYPE swrtcont.

    SELECT * FROM eban
      INTO CORRESPONDING FIELDS OF TABLE @t_xeban
      WHERE banfn = _banfn
      ORDER BY PRIMARY KEY.
    CHECK t_xeban IS NOT INITIAL.

    SELECT * FROM ebkn
      INTO CORRESPONDING FIELDS OF TABLE @t_xebkn
      WHERE banfn = _banfn.

    DATA(t_yeban) = t_xeban.
    DATA(t_yebkn) = t_xebkn.

    READ TABLE t_xeban INTO s_xeban INDEX 1.
    s_xeban-kz    = 'U'.
    s_xeban-banpr = '08'.
    MODIFY t_xeban FROM s_xeban INDEX 1.
    CALL FUNCTION 'ME_UPDATE_REQUISITION'
      TABLES xeban = t_xeban
             xebkn = t_xebkn
             yeban = t_yeban
             yebkn = t_yebkn.

    CALL FUNCTION 'ME_UPDATE_REQUISITION_CHNGDOC'
      TABLES xeban = t_xeban
             xebkn = t_xebkn
             yeban = t_yeban
             yebkn = t_yebkn.

    t_container = VALUE #( LET relcode = get_release_code( iv_banfn ) IN
                            FOR wa IN t_xeban
                            ( element = 'PURCHASINGDOCUMENT' value = wa-bnfpo )
                            ( element = 'PURCHASINGITEM'     value = '00010' )
                            ( element = 'RELEASEGROUP'       value = get_release_code( iv_banfn ) ) ).
    CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'.

    DO 100 TIMES.
      WAIT UP TO '0.1' SECONDS.
      SELECT SINGLE  FROM eban
        WHERE banfn = _banfn
          AND banpr = '08' " rejected
        INTO (lv_check).
      IF sy-subrc = 0.
        rv_completed = abap_true.
      ENDIF.
    ENDDO.
    IF lv_check = abap_false.
      RAISE EXCEPTION NEW cx_mm_pur_requisition( textid = VALUE #( msgid = '00'
                                                                   msgno = '001'
                                                                   attr1 = 'Reject could not completed' ) ).
    ENDIF.
  ENDMETHOD.
ENDCLASS.

Conclusion

Although SAP requires manual rejection of Purchase Requisitions, practical project needs sometimes demand automation.

By leveraging the same building blocks used by Fiori My Inbox and ME54N, it is possible to implement a controlled and consistent workaround for programmatic PR rejection.

This approach does not replace SAP standard behavior, but it provides a pragmatic option when no standard API exists.

The 2025 Developer Insights Survey: The Report

2026-02-10T22:24:13.580000+01:00

Role Overlaps for external SAP developers

Part I: Introduction and General Information

Welcome to the 2025 SAP Developer Insights Survey report. This annual survey targets SAP’s existing external developer audience. It is used to track demographics, usage patterns, and trends within that population. 2025 is the fifth year we have conducted the survey. The survey program is led by the SAP Ecosystem and Community team. Key support is provided by the SAP Global Experience Management Office (XMO). Several other SAP teams provide advice and inputs to survey content. Those teams are listed at the end of this report.

The 2025 survey was open for six weeks - from January 22nd through March 7th.

Using social media announcements, SAP's Developer News show, and a web-popup on Community web sites, we invited all technical professionals in the SAP ecosystem to participate in the survey.

Each year's survey is composed of a mix of new topic questions and repeat select questions from past years to track trends.

Key Findings from the 2025 Survey

Generative AI is Positively Affecting our Developer Ecosystem - While these tools are not exclusively Joule-based, roughly half of our respondents report evaluating Gen AI developer tooling and, among those using it, over half report that these tools have a "profound positive impact" in their real world use.
Low Code Use is Increasing - SAP Build low code tools lead in this space. Overall use of Low Code products on production projects continues to increase.
BTP Guidance Framework - limited awareness -- this important guidance document was announced at TechEd this past November, but - as with BTP Developers Guide in 2024 - barely half of respondents were aware of this document's existence.
Work-from-Home Continues Trending Down - we have been tracking these numbers since 2021. 6% fewer folks used their home as their primary workplace when compared to last year.

These topics will be covered in more detail in the rest of the report.

General Topics

We included a number of general questions in the survey covering such topics as age, work location and status, as well as role.

Employment Status and Relation to SAP

Employment

"What is your current employment status?"

SAP Developer Community Composition

We have seen no significant change in these breakdowns from year to year.

SAP Developer Community Age Distribution

This shows increases in both the oldest age buckets for 2025. This was accompanied by similar decreases in the middle two age buckets ( ranging from 25 - 44 years of age). This merits deeper research as it potentially indicates either a gap in hiring younger employees to cover the normal aging of our community, or an outright loss of qualified younger staff. The two year trend in the 25-34 group reinforces that idea.

Where are the Developers?

We asked, "Which country are you based in?"

By country, India has the largest number of respondents and probably the densest geographic concentration, followed by Germany, and then the USA. When grouped by SAP region, however, EMEA North is largest.

The proportions remain essentially unchanged from 2024.

Part II. Narrowing the Response Set

A primary objective of our survey is to build a model of our community's usage patterns. It helps us build more effective programs. With that goal in mind, in the remainder of the report we will narrow the data we'll consider in these ways:

External Developers Only - we exclude responses from SAP employees, and others (students, analysts, etc.)
Recent Development Experience - we only include responses from those who stated that they had been part of an SAP extension or integration project within the past year

When we filter the data set in this way, we are left with a set of 628 responses that we'll work with for the remainder of the report.

Workplace and Trends

Office Location

"As of right now, where do you primarily physically work from?"

Year-to-year trend in Workplace

This shows a slowing trend of employees moving back to conventional offices from home. From a past Developer Survey, 29% of respondents reported they had primarily worked at home prior to the pandemic.

Recent SAP Project Experience?

"Have you developed integrations or extensions for any SAP products or technologies in the past 12 months?"

Extension and Integration are key scenarios for developers working with SAP applications. We wanted to focus on developers with recent experience in these areas. Roughly 70% of developers answered "Yes" here.

Popular Programming Languages

"Which programming languages have you used in your development work over the past 12 months? Please select all that apply."

This was posed as a multiple response question. ABAP dominates, as it has in every year of our survey. JavaScript is very popular as well, which could be attributed to its use in both SAPUI5 and CAP. Java and Python are roughly tied for third place. The relative positions of these top four languages hasn't changed much, year to year.

We extended our survey beyond just language use to ask about popular frameworks.

Popular Programming Frameworks

We asked respondents who are Developers to pick which common front and back-end frameworks they have worked with in the past year.

Front-Ends

Back-Ends

Application and Business Technology Platform Architectures

SAP applications can be extended using any one of several architectural approaches. These can be grouped into two major classes: on-stack (in-app) and side-by-side (essentially, BTP-based).

We were wondering which approaches are most popular.

Popular Extension Architectures

"For the most recent extension project that you were part of, what was the principal runtime architecture of the back-end elements?"

We don't distinguish between newer and older SAP applications (e.g., S/4HANA vs. ECC) -- this likely explains the dominance of "on-stack ABAP". Aside from the obvious dominance of ABAP, we can also see that CAP is relatively popular. As with last year's results on this question, we see Low Code products like Build Apps and Build Process Automation are popular -- this question is asking about real production projects, and seeing those two account for roughly 10% of all extension projects highlights the value of these tools.

ABAP and CAP both have style or language variants in their respective frameworks. ABAP can be programmed as "ABAP for Cloud Development" or "ABAP Standard". CAP is available in JavaScript or Java language variants. Where the respondent selected ABAP or CAP, we asked about the variant used on the project:

ABAP Variants

CAP Variants

The rough 50-50 breakdown of ABAP styles is consistent with responses elsewhere in the survey. It reflects that roughly half of the ABAP projects are ECC or very early forms of S/4HANA. Importantly, the group that didn't understand the difference is considerably smaller than last year (2% versus 5% in 2024).

CAP/JavaScript is plainly most popular for CAP projects. Unlike last year, we do have respondents reporting the use of CAP/Java projects, although the percentage is modest - 5%.

Popular IDEs

We are always curious about general work patterns of developers. We asked about developer's most commonly used editors. While it would be difficult in such a survey of all developers to add many questions, we were particularly curious about most popular IDE or editor.

Preferred IDE or Editor

"Which IDE or text editor do you most commonly use for development tasks?"

Consistent with past year's results, the editor of choice will depend on the language. SAP GUI and -- arguably -- Eclipse are the primary editors for ABAP, so it's maybe no surprise that they are reflected as most popular. This is the first year that SAP Build Code appeared in the survey. We maintained separate choices for BAS and Build Code to see where folks might say that they have been using BAS, but have not yet transitioned to the broader capabilities offered by SAP Build Code.

Potential / Use of Generative AI for Developers

Beginning with the 2024 survey, we asked developers about their thoughts and use of several major capabilities of Generative AI as it applies to software development.

Generative AI for Developers

"Which of these GenAI capabilities has your team explored or used? Select the choice that best describes your use of each capability. "

An brief explanation of each category was included in the survey and is shown below:

Code Generation and Autocompletion: GenAI tools can generate code snippets, complete lines of code, or suggest entire functions based on the context provided by the developer.

Bug Detection and Code Review: AI models can be trained to identify potential bugs and vulnerabilities in the code. They can also suggest improvements in code quality, best practices, and code consistency.

Automated Testing and Test Data Generation: GenAI can be used to create test cases, which can help in thoroughly testing software applications. This includes generating test data that covers edge cases, potentially reducing the time and effort in manual testing.

Documentation Generation: AI can assist in generating and updating technical documentation. It can interpret the code and create comprehensive documentation, which is crucial for maintaining and scaling software projects.

Natural Language Processing (NLP) for Code: AI models can translate natural language queries into code, allowing developers to express their intent in plain language. This can be particularly helpful for novice developers working with unfamiliar frameworks.

Customized User Experience Design: AI can help generate user interface designs to enhance user experience.

AI-Powered Development Tools: Integration of AI in IDEs for real-time assistance, such as suggesting optimizations, refactoring code, or even predicting the next steps in development.

Automated Code Refactoring: AI can assist in code refactoring by suggesting or even implementing improvements in code structure.

Software Design and Architecture: AI can help in generating software design patterns or architectural models based on specified requirements. This can speed up the initial stages of development and ensure adherence to best practices.

Enhanced Security Protocols: Generative AI can be used to develop advanced security protocols and encryption methods, providing robust security solutions in software applications.

We also believed that Generative AI has been on the scene long enough for folks to being to experiment with putting it to use in meaningful ways. So, we included a couple of questions to gauge their perceptions of its utility to to their teams.

Current Gen AI Use

"How would you characterize your team’s current use of Generative AI tools or LLMs in your day-to-day work? Consider tools from any vendor or open source. Examples might include Joule, SAP Generative AI Hub, GitHub Copilot, or open source LLMs. (select the most applicable statement)"

Gen AI Effectiveness for Developers

"Looking back on the past year, what is your own sense of how the use of Generative AI based tools or LLMs impacted the effectiveness or efficiency of your team?"

Joule in SAP Build Code

Several Joule features were introduced into SAP Build Code prior to the survey. We asked respondents about their awareness or use of these features.

Joule for CDS Modeling

Joule for Test Data Set Generation

Joule Code Generation

Development Job Roles

We asked respondents which common development-related roles they perform.

"Which roles describe your day-to-day work? (Select all that apply)"

Respondents often "wear multiple hats" in their job. This question is asked in "select all that apply" form to capture that information.
The Venn diagram on the right depicts the relative overlaps of the top seven roles reported by respondents. The area of each overlapping region reflects the count respondents performing the overlapping roles. For example, from this we can seel that all (UX) "Designers" are also "Developers". Most but not quite all "Enterprise Architects" also are "Solution Architects".

These patterns of overlap are very similar to those in past years.

It is unsurprising that the "Developer" role leads. Architecture roles as a group have increased each year.

Development Domains

For respondents selecting "Developer" as one of their roles, we were interested in the specific application Domains they work in:

"Which of the following development domains describe your day-to-day work? (select all that apply)"

Year to year, Integration came in higher than we expected. Mobile web front-end development is more common than native mobile application development. This isn't completely unexpected, but worth noting.

Developer Satisfaction with SAP

SAP Development Satisfaction

"For your recent experience developing an integration or extension, how would you describe your overall satisfaction with SAP?"

Roughly 74% of respondents report they are “very satisfied” or “satisfied” with their development work with SAP. This is back near the 75% reported two years ago and also up from the 2024 figure, 70%.

We also gave all respondents a list of potential obstacles in their use of SAP tools and technologies and asked them to select the most significant pain points.

Obstacles in SAP tool us

"Which of these potential pain points are obstacles to your development when using SAP tools or frameworks? (select up to three most significant items)"

BTP Guidance Framework

Awareness and Use of the BTP Guidance Framework

"The SAP BTP Guidance Framework was announced at SAP’s TechEd this past November. Which statement best described your level of familiarity with this document?"

Nearly half of respondents were unaware of this document's release. Raising awareness for this and other related BTP framework documents would be a good goal for 2025.

Cloud Insights

We first asked respondents if they used any cloud providers for their projects. For those that answered, "yes", we asked about the use of several major providers, including SAP BTP. We also asked if their use included SAP or non-SAP projects. This information was condensed into a chart depicting the relative use of each cloud provider.

Similar to the earlier questions around BTP Environments, these numbers do not reflect a tally of projects for each platform - instead it reflects developer exposure to each.

Using Cloud Providers?

"Are you using any cloud providers for your development projects?"

We asked, "Which cloud providers are you using for development projects?" and we asked in a way to separate SAP-related projects from more general use.

SAP Business Technology Platform

Microsoft Azure

Amazon Web Services

Google Cloud Platform

Alibaba Cloud

Low / No Code Tools

This is the third consecutive year in which we've asked questions around Low Code and No Code (LCNC) products. The list was composed of leaders in the then current Gartner LCNC Magic Quadrant Report and select SAP products. SAP Process Automation -- now Build Process Automation -- was not yet announced at the time of the 2022 survey, so it only appears in the more recent data.

For each product, we asked respondents to select the most applicable category reflecting their awareness or use. These questions were organized as a single large matrix of boxes in Qualtrics - There is no "I am unfamiliar with this product" response. Instead, the respondent simply would skip checking one of the other boxes.

It is important to point out that we are depicting response counts in the following charts rather than percentages and that the difference in total annual response counts must be considered to compare between years. The raw respondent count for 2023 was 2.4 times larger than 2022. And 2024 responses were less than half of 2023. We'll normalize for that in a later table.

These depictions can be misleading: our number of respondents each year varies. But we can normalize for that annual variation; what does this look like then? If we extract the data for production use for all products, we can use that to calculate the proportion use of each product by year (in other words, the sum of each column below totals one hundred percent). We can then visualize the relative shift in popularity over time:

Productive use of Product	2022	2023	2024	2025
Vendor A	20%	48%	15%	27%
SAP Build family (Build Apps + BPA)	2%	32%	23%	35%
Vendor B	14%	28%	7%	18%
SAP Signavio	5%	14%	5%	9%
Vendor C	7%	12%	3%	3%
Vendor D	2%	2%	1%	3%
Vendor E	3%	4%	1%	2%
Vendor F	3%	4%	1%	2%

SAP Build low code products dominate in our SAP ecosystem.

Learning and Help Resources

We were interested in preferences in the format or media type of learning resources by respondents.

Preferred Learning Resources

"When learning new skills or technical subjects over the past 12 months, what resources did you tend use the most? Please select up to three resources."

These results seem relatively unchanged year-to-year. One point of interest is the large difference in popularity between tutorials and MOOCs (53% versus 16% here). Tutorials tend to be hands-on. They are also broken into substantially smaller time chunks. This reinforces our hypothesis that different content types and required time investment have an impact in some learning scenarios. This merits investigation.

On the topic of Help, we shifted in this next question from formats to specific web sites.

Top SAP Help Resource Sites

"What is your preferred resource if you need help, or have a challenge with the SAP technology / tool you are working with? "

Almost sixty percent of respondents say they use organic search or SAP Community as their primary source of SAP help. This is consistent with past years. This continues to demonstrate good visibility of the Community site overall and likely speaks well for the usefulness of the site content.

Satisfaction with SAP Learning Hub

SAP Learning Hub Awareness

"Which of the following best describes your exposure to the SAP Learning site?"

Overall Value of Learning Hub

"Overall how valuable are the resources on that site in helping you to understand SAP developer technologies?"

Technical Certifications

"How many technology-related certification programs have you completed within the past four years?"

Survey Methodology

This report is based on a Qualtrics web-based survey of 1,492 respondents from 58 countries. The survey ran for six calendar weeks between January 22 to March 7th, 2025. Ninety percent of the respondents invested ten minutes or less with the survey.

The survey was promoted via the SAP Community website and the SAP Developer Center, sap.com pop-up intercepts, social media posts.

Other References

The annual Stack Overflow Developer Survey is an excellent (and no-cost) reference for industry-wide habits of developers.

The Step-by-Step Tutorial: Local AI-Powered ABAP Development in VS CODE

2026-02-10T23:21:51.735000+01:00

Author: Ramesh Vodela
Machine: Dell Precision 7760 | 128 GB RAM | NVIDIA RTX A3000 (6 GB VRAM). If you have less RAM you response could be slow.

For years, ABAP development was a "closed box," but the rise of Generative AI has promised to change that. While SAP has introduced Joule on BTP, many developers and organizations find themselves at a crossroads. Why build a local AI powerhouse when a cloud solution exists?

The Availability Gap

SAP Joule is a premium, cloud-based tool primarily available for S/4HANA Cloud (Public/Private Edition) and BTP. For developers working on On-Premise S/4HANA systems or older ECC landscapes, Joule often remains out of reach. We believe AI shouldn't be limited by your SAP version.

The Privacy Paradox

In the SAP world, code is proprietary. Many firms are hesitant to "ship" their custom business logic to a cloud provider for processing. By using a Local LLM (Large Language Model), your source code never leaves your workstation. It stays behind your firewall, ensuring 100% data sovereignty.

The Cost of Innovation

Cloud-based AI is expensive. Between BTP licensing, API consumption costs, and per-user fees, the "Joule bill" can add up quickly. Our solution leverages the 128GB of RAM already sitting in your workstation. Once your hardware is paid for, your AI "co-pilot" costs $0 per month to run.

Empowering the Developer

This blog is for the developer who wants the power of a Senior Architect sitting on their shoulder, without waiting for corporate budget approval or BTP provisioning. We are democratizing AI for the ABAP community, one local install at a time.

This blog outlines how to build a private, high-performance ABAP development environment using VS Code, Ollama, and a Local 32B AI Model.

Phase 1: The Hardware & Engine”

Before coding, we must prepare the "brain" of the operation.

Install Ollama: Download from ollama.com. When you install ollama it is configured as autostart program. Use taskmanager to disable this . Disable Ollama autostart to ensure environment variables are correctly applied when manually starting the service. Open a powershell in admin mode and run the following commands and leave this window open. A windows restart is required before the next step otherwise you will get a port binding error.

$env:OLLAMA_HOST = "127.0.0.1:11434"

$env:OLLAMA_ORIGINS = "*" # this is for CORS This allows VS Code #extensions (Continue) to communicate with Ollama locally.

ollama serve

Pull the Models: Open PowerShell and run:
- ollama pull qwen2.5-coder:32b (Your "Senior Architect")
- ollama pull qwen2.5-coder:1.5b (Your "Fast Autocomplete")
Create a Modelfile (without any extensions) with the following contents for qwen2.5-coder:32b you can change this to whatever model you want to use.

FROM qwen2.5-coder:32b

# We have 128GB RAM, so let's use a massive context window for SAP projects

PARAMETER num_ctx 32768

PARAMETER temperature 0.

SYSTEM """

You are a Lead SAP ABAP Developer specializing in S/4HANA 2023.

Your goal is to provide high-quality, production-ready code.

Use Modern ABAP: Prioritize expressions like NEW, VALUE, CORRESPONDING, and inline declarations (@DATA).
Framework Expertise: Deep knowledge of RAP (RESTful ABAP Programming Model), OData v4, and CDS Views.
Clean Code: Follow Clean ABAP principles. No Hungarian notation.
Context: When I provide code, analyze it for performance bottlenecks (e.g., SELECTs inside loops).

"""

Create an ABAP model with this file in a PowerShell admin window

ollama create abap-master-fast -f Modelfile

The 128GB RAM Flex: Increase the memory window so the AI can read massive files like abapGit:
- Run ollama run qwen2.5-coder:32b.
- Type /set parameter num_ctx 32768 and then /save abap-master

Phase 2: Connecting VS Code to S/4HANA

We use the ABAP Remote FileSystem to bridge the gap.

Install Extension: Search for "ABAP Remote FileSystem" in the VS Code Marketplace.
Enable ADT on SAP: In your S/4HANA system, In Transaction SICF, ensure the ADT service is active. (In S/4HANA 2023, ADT_SRV is no longer use.
Configure Connection: Press Ctrl + Shift + P -> ABAPfs: Connection Manager. Add your system details (Hostname, Client, etc.).

The contents of config.json for ABAP S4HANA 2023 are as follows

{

"workbench.colorTheme": "Default Dark+",

"window.zoomLevel": 1,

"abapfs.remote": {

"A5H": {

"url": "http://vhcala4hci:50000",

"username": "<YOUR_USER>",

"password": "<YOUR_PASSWORD>",

"client": "001",

"language": "EN",

"allowSelfSigned": true,

"syncFolder": "C:\\Users\\r_vod\\Documents\\SAP_Local_Sync",

"downloadOnOpen": true

}

"abapfs.cleaner": {

"editor.inlineSuggest.edits.showCollapsed": true

Save this and restart VS code so that the connection is made on startup as shown below. Click on the package to see the different folders

Phase 3: The AI Assistant (Continue Extension)

This replaces the need for an expensive Claude/Copilot subscription.

Install "Continue-open source AI Code agent": Search for the Continue extension in VS Code.
Configure config.yaml: Set your provider to ollama and point the model to abap-master.
The "Ghost Text" setup: Ensure the tabAutocompleteModel is set to the 1.5b version for instant typing suggestions

The following .yaml file is in %USERPROFILE%/config.yaml - a sample with my settings is provided below

name: SAP ABAP Master Config

version: 1.0.0

schema: v1

# This is the list of models for Chat and Refactoring (Ctrl+L / Ctrl+I)

models:

- name: "ABAP Master (Fast)"

provider: ollama

model: abap-master-fast

apiBase: http://localhost:11434

roles:

- chat

- name: "ABAP Master (Heavy 32B)"

provider: ollama

model: qwen2.5-coder:32b

apiBase: http://localhost:11434

contextLength: 32768 # <--- Increases "Short-term memory"

completionOptions:

maxTokens: 8192 # <--- Allows for long code generations

roles:

- edit

- apply

# This section must be OUTSIDE the models list

tabAutocompleteModel:

name: "Qwen 1.5B (Speed)"

provider: ollama

model: qwen2.5-coder:1.5b

apiBase: http://localhost:11434

roles:

- autocomplete # This tells Continue specifically to use this for Ghost Text

tabAutocompleteOptions:

useCopyBuffer: true

maxPromptTokens: 400

debounceDelay: 250

Make sure VS code does not show any errors with continue

Phase 4: Creating Your First Program (The Workflow)

Never create files manually in Windows. Always use the SAP-aware command:

Command: Ctrl + Shift + P -> ABAPfs Create object.
Details: Select Program, name it Z_AI_FLIGHT_DEMO, and use package $TMP.

Phase 5: "Vibe Coding" with SFLIGHT

Now, let the local AI do the heavy lifting.

Inline Edit: Press Ctrl + I inside the blank file.
The Request: "Write a report using SFLIGHT and the SALV class to show all flights for carrier 'AA'."

Review & Accept: The AI streams the code. Press Ctrl + Shift + Enter to accept.

Save in VS Code and SE38 Activate, and click on change to see the code. Test to execute this program.

Phase 6: Pushing to SE38 (Solving Conflicts)

The most common hurdle for new users is the "Sync Conflict."

The Conflict: If you see "Merge with Remote," it means VS Code and SAP are out of sync.
The Fix: Press Ctrl + F3 (Activate). This forces the local AI code into the SAP database.
Verification: Open Transaction SE38 in your SAP GUI. Your code is there, ready to run!

Phase 7: Using AI to Read and Summarize Code

Download: Click on the File you want the AI to read and help you to understand, right click and choose download and save it with the same name in the configured folder in config.json

Click on Ctrl+L to chat with AI – type in the chat window Can you read the file C:\Users\r_vod\Documents\SAP_Local_Sync\z_ai_flight_demo.prog and give me a summary of what it is doing and hit enter

Summary of Success

Privacy: 100% (No code leaves your machine).
Speed: Instant (Thanks to the 128GB RAM).
Cost: $0 (Open-source tools only).

Herzlich Willkommen in der Gruppe Linz!

2026-02-12T10:10:55.152000+01:00

Herzlich Willkommen in der Gruppe Linz!

Hier wollen wir die SAP-Community in Linz und generell Oberösterreich stärker zusammenführen.
Durch unsere Lage im Zentrum von Oberösterreich, unsere starke Industrie und nicht zuletzt Initiativen, wie die Digital Mile, ist diese Gruppe längst überfällig und ich bin echt glücklich, dass das nun geklappt hat.

Ziel ist es vorerst, hier eine Gruppe aufzubauen und persönliche Treffen in Form von Stammtischen zu organisieren, um uns gegenseitig kennenzulernen und herauszufinden welche Themen gerade bewegen.
Später möchte ich das noch erweitern und Wissen zu aktuellen Themen zielgerichteter zu transportieren. Wir werden sehen, wohin uns diese Reise führen wird.

Ich hoffe jetzt einmal auf rege Teilnahme und wir sehen uns bald.

Marcus