$_ CodeCosts

ERP/SAP engineering is the discipline where a misplaced decimal in a pricing condition record can cascade through an entire order-to-cash cycle and cost a manufacturing company seven figures before anyone notices. You are not building greenfield web applications — you are modifying systems that run payroll for 400,000 employees, manage inventory across 200 warehouses, and process purchase orders denominated in 47 currencies with tax calculations governed by the legislation of 80 jurisdictions. The codebase is not something you designed. It is ABAP written across three decades by consultants who were billing by the hour, running on a kernel that treats whitespace as syntactically significant and stores dates as eight-character strings in YYYYMMDD format. Your CDS view must produce the exact same result set as the legacy ALV report it replaces, down to the currency conversion rounding behavior for Japanese Yen (zero decimal places) versus Bahraini Dinar (three decimal places), because the finance team reconciles against that report at month-end close and a one-cent discrepancy triggers a manual investigation that delays the close by two days.

The technology stack spans five decades of enterprise computing. Classic ABAP procedural code from the R/3 era coexists with ABAP Objects, CDS views that push computation to the HANA database layer, Fiori Elements applications that generate UI from OData annotations, SAP Cloud Application Programming Model (CAP) services written in Node.js or Java running on SAP BTP, and integration layers built on IDocs, BAPIs, RFCs, and increasingly on SAP Event Mesh and SAP Integration Suite. A single business process — say, procure-to-pay — might touch a custom Z-transaction built in 2004, a Fiori app deployed in 2022, an Integration Suite iFlow that maps IDocs to REST APIs, a BTP extension that adds ML-based invoice matching, and an S/4HANA Cloud API that replaced the legacy BAPI. Understanding any one of these technologies is necessary but not sufficient. Understanding how they interact — how the transport layer moves changes across DEV/QAS/PRD, how authorization objects cascade through the call stack, how field exits and BAdIs intercept standard code at precisely defined enhancement points — is what separates an SAP engineer from a general-purpose developer who happens to know some ABAP syntax.

AI coding tools in 2026 have a fundamental problem with ERP/SAP engineering: the training data is overwhelmingly biased toward open-source web development. ABAP is a proprietary language with a comparatively small public codebase. SAP’s documentation is vast but much of it lives behind SAP Help Portal authentication, in OSS Notes that describe specific bug fixes and workarounds, and in the collective knowledge of a consultant ecosystem that communicates through SAP Community blog posts, customer-specific wikis, and oral tradition passed down during project implementations. The result is that AI tools can generate syntactically valid ABAP that would make any experienced SAP developer wince: obsolete MOVE statements instead of inline declarations, SELECT * against cluster tables that no longer exist in S/4HANA, RFC calls without proper exception handling, and Fiori code that ignores the manifest.json descriptor entirely. This guide evaluates every major AI coding tool against the actual work ERP/SAP engineers do — not toy examples, but the transport-managed, authorization-checked, enhancement-framework-aware, HANA-optimized code that runs the global economy.

Why ERP/SAP Engineering Is Different

• Proprietary language with limited public training data: ABAP is not Python. There is no equivalent of PyPI with 500,000 packages and millions of public repositories. ABAP code lives inside SAP systems behind corporate firewalls. The public ABAP corpus — SAP Community blog posts, GitHub repositories (mostly small utilities and learning projects), and scattered documentation — represents a tiny fraction of the ABAP code that actually runs in production. This means AI models have seen far less ABAP than they have seen Python, JavaScript, or Java. The consequence is predictable: tools generate ABAP that is syntactically plausible but idiomatically wrong. They produce MOVE source TO target instead of target = source, use WRITE statements in contexts where they make no sense, and generate SELECT SINGLE * against tables that have been deprecated in S/4HANA. The ABAP they produce reads like someone learned the language from a 2005 textbook and never touched a real system. For Fiori/UI5, the training data situation is better because it is JavaScript-based, but UI5’s framework conventions (Component.js, manifest.json, XML views with custom controls) are still niche enough that tools frequently generate generic React or Angular patterns instead of proper UI5 code.
• Transport-managed development lifecycle: Every change in an SAP system is tracked by a transport request. You do not git push to deploy. You create a transport request (workbench or customizing), assign your changes to it, release it, and the transport management system (TMS) moves it through the landscape: DEV to QAS to PRD. A transport can contain ABAP programs, data dictionary objects, customizing entries, Fiori app registrations, OData service metadata, and BTP destination configurations. Transports must be imported in the correct sequence — a transport that references a table field must be imported after the transport that creates that field, or the import fails and blocks the entire import queue. AI tools have zero awareness of this lifecycle. They generate code without considering which transport it belongs to, whether the dependent objects have been transported, or how the transport sequence affects the deployment timeline. In a real SAP project, the transport management strategy — task assignments, dependencies, release scheduling, quality gate checks — consumes as much planning effort as the code itself.
• Authorization concept permeates everything: SAP’s authorization model is not role-based access control bolted on after the fact — it is woven into the kernel. Every transaction, every BAPI call, every RFC function module checks authorization objects. An authorization object like F_BKPF_BUK controls which company codes a user can post accounting documents to. M_BEST_BSA controls which purchasing document types a user can create. S_TCODE controls which transactions a user can execute. A custom Z-program that reads financial data must include explicit AUTHORITY-CHECK statements, or it creates an audit finding that will surface during the next SOX compliance review. AI tools almost never generate authorization checks. They produce programs that read from every company code, post to every plant, and access every cost center — which works perfectly in a development system where developers have SAP_ALL authorization but fails catastrophically (or worse, succeeds silently with too much data) in production where users have role-based restrictions.
• Enhancement framework instead of forking: You do not modify SAP standard code. Ever. The modification adjustment (SPAU/SPDD) process during upgrades is painful enough that the entire SAP ecosystem has evolved a layered enhancement architecture to avoid it. Classic modifications with SMOD/CMOD, Business Add-Ins (BAdIs) with implicit and explicit enhancement points, customer exits, user exits, enhancement spots and enhancement sections for implicit enhancements, Business Transaction Events (BTE) for financial processes, and now the clean core extensibility approach for S/4HANA Cloud that pushes all custom logic to BTP side-by-side extensions. Knowing which enhancement mechanism to use for a given requirement — and more importantly, knowing which enhancement point exists in the standard code path you need to intercept — requires deep knowledge of SAP’s application architecture that AI tools simply do not have. They will suggest modifying standard includes, which is the one thing you must never do.
• Data model complexity with business semantics: SAP’s data dictionary is not a generic relational schema — it encodes business semantics at the type level. A field of type CURR (currency amount) always has a reference currency field that determines its decimal places. DATS stores dates as YYYYMMDD character strings, not as SQL DATE types, which means WHERE erdat > '20260101' works as a string comparison but WHERE erdat > 20260101 treats it as an integer and produces wrong results for dates before 19991231. QUAN (quantity) fields require a unit of measure reference. CLNT (client) fields are automatically filtered by the logon client in Open SQL unless you explicitly use CLIENT SPECIFIED. Transparent tables, pool tables (removed in S/4HANA), cluster tables (removed in S/4HANA), views, CDS views, and CDS view entities each have different capabilities and restrictions. AI tools generate SQL against SAP tables as if they were generic database tables, ignoring the type semantics, the client handling, and the S/4HANA compatibility matrix that determines which classic tables have been replaced by CDS views in the new data model.

ERP/SAP Task Support Matrix

1. ABAP Development (Classic ABAP, ABAP OO, CDS Views)

ABAP is the backbone of every SAP system. Whether you are writing a custom report, implementing a BAdI, building an OData service, or defining CDS views for embedded analytics, ABAP is where the business logic lives. The language has evolved dramatically — from the procedural ABAP/4 of the R/3 era through ABAP Objects and into the modern ABAP with inline declarations, string templates, internal table expressions, and CDS view entities that push computation down to the HANA database. But evolution does not mean replacement: a production S/4HANA system contains code spanning all these eras, and an SAP engineer must be fluent in every dialect because you will debug a 1998 user exit at 2 AM during month-end close, then write a CDS view entity with ABAP-managed annotations the next morning.

The critical distinction in modern ABAP is between classic Open SQL (now called ABAP SQL) and CDS views. Classic ABAP processes data in the application server — SELECT into an internal table, LOOP over it, apply business logic row by row. This was fine on Oracle or DB2 where database round-trips were expensive and application server CPU was cheap. On HANA, this pattern is an anti-pattern: you want to push as much computation as possible into the database layer via CDS views, table functions, and AMDP (ABAP-Managed Database Procedures). A CDS view that joins I_SalesOrder with I_SalesOrderItem, applies filters, and computes aggregates executes entirely in HANA’s in-memory column store. The equivalent classic ABAP — three nested SELECT statements, a LOOP with READ TABLE for lookups, and a COLLECT for aggregation — transfers gigabytes of raw data to the application server for processing that HANA could have done in milliseconds.

CDS View with annotations and associations

@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Sales Order with Delivery Status'
@Metadata.allowExtensions: true
@ObjectModel.usageType: {
  serviceQuality: #C,
  sizeCategory: #XL,
  dataClass: #MIXED
}
define view entity ZI_SalesOrderDelivery
  as select from I_SalesOrder as SalesOrder

  association [1..1] to I_SalesOrderType     as _SalesOrderType
    on $projection.SalesOrderType = _SalesOrderType.SalesOrderType

  association [0..*] to I_SalesOrderItem      as _Item
    on $projection.SalesOrder = _Item.SalesOrder

  association [0..*] to I_DeliveryDocument     as _Delivery
    on $projection.SalesOrder = _Delivery.ReferenceSDDocument

  association [0..1] to I_Customer             as _SoldToParty
    on $projection.SoldToParty = _SoldToParty.Customer

  association [0..1] to I_CompanyCode          as _CompanyCode
    on $projection.SalesOrganization = _CompanyCode.CompanyCode

{
      @ObjectModel.text.association: '_SalesOrderType'
  key SalesOrder.SalesOrder,

      @ObjectModel.text.element: ['SoldToPartyName']
      SalesOrder.SoldToParty,
      _SoldToParty.CustomerName           as SoldToPartyName,

      SalesOrder.SalesOrderType,
      SalesOrder.SalesOrganization,
      SalesOrder.DistributionChannel,
      SalesOrder.OrganizationDivision,

      @Semantics.amount.currencyCode: 'TransactionCurrency'
      SalesOrder.TotalNetAmount,
      SalesOrder.TransactionCurrency,

      @Semantics.calendar.date: true
      SalesOrder.SalesOrderDate,
      SalesOrder.CreationDate,

      /* Delivery status derived from item-level data */
      case when _Delivery.DeliveryDocument is not null
           then 'X'
           else ' '
      end                                   as HasDelivery,

      /* Calculated field: days since order creation */
      dats_days_between(
        SalesOrder.SalesOrderDate,
        $session.system_date
      )                                     as DaysSinceOrder,

      /* Associations for consumption views */
      _SalesOrderType,
      _Item,
      _Delivery,
      _SoldToParty,
      _CompanyCode
}

Claude Code generates CDS views with correct annotation syntax, proper association cardinalities, and the semantic annotations (@Semantics.amount.currencyCode, @Semantics.calendar.date) that are mandatory for Fiori Elements consumption. It understands the difference between define view (classic CDS) and define view entity (the modern replacement that does not generate an SQL view in the database dictionary), and it correctly uses the I_ prefix for standard SAP interface views. Critically, it includes @AccessControl.authorizationCheck: #CHECK, which generates the DCL (Data Control Language) authorization check — without this annotation, the CDS view returns data for all company codes and sales organizations regardless of the user’s authorization profile. Gemini CLI handles CDS syntax reasonably when given enough context (paste the relevant SAP Help documentation into its 1M window), but struggles with the semantic annotations and sometimes generates deprecated @AbapCatalog.sqlViewName for view entities (view entities do not have SQL view names). Cursor and Copilot produce syntactically valid CDS when working in ADT (ABAP Development Tools in Eclipse), but tend to miss the authorization check annotation and use outdated annotation syntax from CDS views instead of view entities. Windsurf and Amazon Q have minimal ABAP/CDS training data and produce unreliable output — expect to rewrite rather than edit.

Modern ABAP with inline declarations and expressions

CLASS zcl_sales_order_processor DEFINITION
  PUBLIC FINAL CREATE PUBLIC.

  PUBLIC SECTION.
    TYPES: BEGIN OF ty_order_result,
             sales_order     TYPE vbeln,
             sold_to_party   TYPE kunnr,
             customer_name   TYPE name1_gp,
             net_amount      TYPE netwr_ak,
             currency        TYPE waerk,
             delivery_status TYPE char1,
           END OF ty_order_result,
           tt_order_results TYPE STANDARD TABLE OF ty_order_result
                            WITH EMPTY KEY.

    METHODS get_open_orders
      IMPORTING
        iv_sales_org TYPE vkorg
        iv_date_from TYPE sydatum DEFAULT sy-datum - 90
      RETURNING
        VALUE(rt_orders) TYPE tt_order_results
      RAISING
        zcx_sales_order_error.

  PRIVATE SECTION.
    METHODS check_authorization
      IMPORTING
        iv_sales_org TYPE vkorg
      RAISING
        zcx_sales_order_error.
ENDCLASS.

CLASS zcl_sales_order_processor IMPLEMENTATION.
  METHOD get_open_orders.
    " Authorization check BEFORE any data access
    check_authorization( iv_sales_org ).

    " Modern ABAP SQL with inline declarations
    SELECT so~vbeln           AS sales_order,
           so~kunnr           AS sold_to_party,
           bp~name1_gp        AS customer_name,
           so~netwr           AS net_amount,
           so~waerk           AS currency,
           CASE WHEN dl~vbeln IS NOT NULL
                THEN @abap_true
                ELSE @abap_false
           END                AS delivery_status
      FROM vbak AS so
      LEFT OUTER JOIN but000 AS bp
        ON so~kunnr = bp~partner
      LEFT OUTER JOIN likp AS dl
        ON so~vbeln = dl~vgbel
      WHERE so~vkorg  = @iv_sales_org
        AND so~erdat >= @iv_date_from
        AND so~gbstk <> 'C'  " Not fully processed
      ORDER BY so~erdat DESCENDING
      INTO TABLE @rt_orders.

    IF sy-subrc <> 0.
      rt_orders = VALUE #( ).
    ENDIF.
  ENDMETHOD.

  METHOD check_authorization.
    AUTHORITY-CHECK OBJECT 'V_VBAK_VKO'
      ID 'VKORG' FIELD iv_sales_org
      ID 'VTWEG' DUMMY
      ID 'SPART' DUMMY
      ID 'ACTVT' FIELD '03'.  " Display activity

    IF sy-subrc <> 0.
      RAISE EXCEPTION TYPE zcx_sales_order_error
        EXPORTING
          textid   = zcx_sales_order_error=>no_authorization
          mv_vkorg = iv_sales_org.
    ENDIF.
  ENDMETHOD.
ENDCLASS.

This example demonstrates what AI tools consistently get wrong about ABAP. The AUTHORITY-CHECK before data access is not optional — it is an audit requirement. The V_VBAK_VKO authorization object controls access to sales documents by sales organization, distribution channel, and division. The DUMMY keyword skips a check field when you do not want to restrict on that dimension. The modern SQL syntax uses host expressions (@iv_sales_org with the @ prefix), inline declarations (INTO TABLE @rt_orders declaring the variable at the point of use), and VALUE #( ) constructor expressions. AI tools that generate MOVE-CORRESPONDING, WRITE statements inside methods, or use obsolete SELECT ... ENDSELECT loops instead of INTO TABLE are producing code that works but violates every modern ABAP guideline and will not pass code review at any competent SAP shop.

2. Fiori/UI5 Frontend Development

SAP Fiori is not just a UI library — it is an entire user experience paradigm that dictates how enterprise applications should look, behave, and integrate with the SAP Launchpad. Fiori applications are built on SAPUI5 (SAP’s proprietary extension of OpenUI5), use the MVC pattern with XML views, and communicate with SAP backends through OData V2 or V4 services. The Fiori design system specifies floorplans — List Report, Object Page, Worklist, Overview Page, Analytical List Page — each with specific layout rules, navigation patterns, and interaction behaviors that users across 400,000 SAP customer organizations have learned to expect. A Fiori Elements application generates its entire UI from OData service metadata and CDS annotations, meaning you write zero JavaScript for standard scenarios — the List Report, filters, table columns, object page sections, and navigation are all derived from annotations on your CDS view.

The complexity lies in the annotation-driven development model. A Fiori Elements List Report requires @UI.lineItem annotations to define table columns, @UI.selectionField for filter bar fields, @UI.headerInfo for the object page header, @UI.facet for object page sections, and @UI.fieldGroup for field groupings. Each annotation has specific positioning via position and qualifier attributes, importance levels (#HIGH, #MEDIUM, #LOW) that determine responsive behavior on different screen sizes, and criticality calculations that drive semantic coloring (red/yellow/green status indicators). Getting these annotations wrong does not produce an error — it produces a Fiori app that looks subtly broken: columns in the wrong order, filters missing, header fields not appearing, navigation not working.

Fiori Elements List Report with OData V4 and annotations

// manifest.json — Fiori Elements List Report Object Page
{
  "_version": "1.59.0",
  "sap.app": {
    "id": "z.salesorder.monitor",
    "type": "application",
    "title": "{{appTitle}}",
    "description": "{{appDescription}}",
    "applicationVersion": { "version": "1.0.0" },
    "dataSources": {
      "mainService": {
        "uri": "/sap/opu/odata4/sap/zsalesorder_monitor/srvd_a2x/sap/zsalesorder_monitor/0001/",
        "type": "OData",
        "settings": {
          "annotations": ["annotation0"],
          "localUri": "localService/metadata.xml",
          "odataVersion": "4.0"
        }
      },
      "annotation0": {
        "uri": "/sap/opu/odata4/sap/zsalesorder_monitor/srvd_a2x/sap/zsalesorder_monitor/0001/$metadata",
        "type": "ODataAnnotation"
      }
    },
    "crossNavigation": {
      "inbounds": {
        "SalesOrderMonitor-display": {
          "semanticObject": "SalesOrderMonitor",
          "action": "display",
          "title": "{{flpTitle}}",
          "signature": {
            "parameters": {},
            "additionalParameters": "allowed"
          }
        }
      }
    }
  },
  "sap.ui5": {
    "flexEnabled": true,
    "dependencies": {
      "minUI5Version": "1.120.0",
      "libs": {
        "sap.m": {},
        "sap.ushell": {},
        "sap.fe.templates": {}
      }
    },
    "models": {
      "": {
        "dataSource": "mainService",
        "preload": true,
        "settings": {
          "operationMode": "Server",
          "autoExpandSelect": true,
          "earlyRequests": true,
          "groupId": "$auto"
        }
      },
      "i18n": {
        "type": "sap.ui.model.resource.ResourceModel",
        "settings": {
          "bundleName": "z.salesorder.monitor.i18n.i18n"
        }
      }
    },
    "routing": {
      "routes": [
        {
          "pattern": ":?query:",
          "name": "SalesOrderList",
          "target": "SalesOrderList"
        },
        {
          "pattern": "SalesOrder({key}):?query:",
          "name": "SalesOrderObjectPage",
          "target": "SalesOrderObjectPage"
        }
      ],
      "targets": {
        "SalesOrderList": {
          "type": "Component",
          "id": "SalesOrderList",
          "name": "sap.fe.templates.ListReport",
          "options": {
            "settings": {
              "contextPath": "/SalesOrder",
              "variantManagement": "Page",
              "initialLoad": "Enabled",
              "controlConfiguration": {
                "@com.sap.vocabularies.UI.v1.LineItem": {
                  "tableSettings": {
                    "type": "ResponsiveTable",
                    "selectionMode": "Multi",
                    "enableExport": true,
                    "condensedTableLayout": true
                  }
                }
              }
            }
          }
        },
        "SalesOrderObjectPage": {
          "type": "Component",
          "id": "SalesOrderObjectPage",
          "name": "sap.fe.templates.ObjectPage",
          "options": {
            "settings": {
              "contextPath": "/SalesOrder",
              "editableHeaderContent": false,
              "sectionLayout": "Tabs"
            }
          }
        }
      }
    }
  }
}

Cursor excels here because Fiori development is fundamentally JavaScript/JSON development with SAP-specific conventions. Cursor’s codebase indexing means it can learn your project’s manifest.json patterns, your annotation conventions, and your custom control implementations, then autocomplete consistently across files. It correctly generates the sap.fe.templates routing configuration for OData V4 Fiori Elements, including the contextPath, controlConfiguration, and variantManagement settings that trip up other tools. Claude Code handles the manifest.json structure well and understands the relationship between CDS annotations and Fiori Elements rendering — it can explain why a column is not appearing (missing @UI.lineItem annotation) or why navigation is broken (incorrect semanticObject/action pair in the cross-navigation configuration). Copilot generates valid JSON structure but frequently produces OData V2 patterns (sap.ui.generic.template) when you need V4 (sap.fe.templates), and it does not understand the subtle differences in model settings between V2 and V4 (V4 uses $auto group IDs, V2 uses batch groups). Windsurf produces generic UI5 code that does not follow Fiori design guidelines — functional but not conformant, which matters when your app must pass the Fiori Design Compliance Check before deployment to a customer’s Launchpad.

3. SAP BTP/Cloud Application Programming (CAP)

SAP Cloud Application Programming Model (CAP) is SAP’s opinionated framework for building cloud-native applications on BTP. It uses Core Data Services (CDS) — a different CDS than ABAP CDS, confusingly sharing the name but with different syntax — to define data models and services, with runtime implementations in Node.js or Java. CAP enforces convention over configuration: you define your domain model in .cds files, expose services in .cds service definitions, and implement custom logic in event handlers that hook into the framework’s generic CRUD processing. CAP handles OData serialization, database deployment (to SQLite for development, SAP HANA Cloud for production), authentication via SAP XSUAA, multitenancy, and feature toggles out of the box.

The power of CAP is that a surprisingly small amount of CDS and JavaScript produces a fully functional OData V4 service with authorization, draft handling, and database persistence. The danger is that AI tools do not understand CAP’s specific conventions — they generate generic Express.js patterns instead of CAP event handlers, use raw SQL instead of CDS queries, and ignore the cds.requires configuration for managed services. CAP has its own way of doing everything: cds.connect.to() for service consumption, cds.spawn() for background jobs, cds.tx() for transaction management, cds.log() for logging. Using generic Node.js alternatives works locally but breaks in production on Cloud Foundry or Kyma because CAP’s managed services handle connection pooling, credential rotation, and multitenancy transparently.

CAP data model and service with custom handlers

// db/schema.cds — Domain model
namespace z.procurement;

using { cuid, managed, temporal, Currency, Country } from '@sap/cds/common';

entity PurchaseOrders : cuid, managed {
  orderNumber     : String(10)  @mandatory;
  supplier        : Association to Suppliers;
  status          : String enum {
    DRAFT     = 'D';
    SUBMITTED = 'S';
    APPROVED  = 'A';
    REJECTED  = 'R';
    ORDERED   = 'O';
  } default 'D';
  orderDate       : Date;
  totalAmount     : Decimal(15,2);
  currency        : Currency;
  deliveryAddress : Association to Addresses;
  items           : Composition of many PurchaseOrderItems on items.parent = $self;
  approvalHistory : Composition of many ApprovalSteps on approvalHistory.parent = $self;
}

entity PurchaseOrderItems : cuid {
  parent          : Association to PurchaseOrders;
  itemNumber      : Integer;
  material        : Association to Materials;
  description     : localized String(255);
  quantity        : Decimal(13,3);
  unit            : String(3);
  unitPrice       : Decimal(15,2);
  currency        : Currency;
  netAmount       : Decimal(15,2);
  deliveryDate    : Date;
}

entity Suppliers : cuid, managed {
  supplierNumber  : String(10) @mandatory;
  name            : localized String(255);
  country         : Country;
  orders          : Association to many PurchaseOrders on orders.supplier = $self;
}

entity Materials : cuid {
  materialNumber  : String(18) @mandatory;
  description     : localized String(255);
  materialGroup   : String(9);
  baseUnit        : String(3);
}

entity Addresses : cuid, managed {
  street          : String(255);
  city            : String(40);
  postalCode      : String(10);
  country         : Country;
}

entity ApprovalSteps : cuid, managed {
  parent          : Association to PurchaseOrders;
  stepNumber      : Integer;
  approver        : String(255);  // user ID
  decision        : String enum { PENDING='P'; APPROVED='A'; REJECTED='R'; };
  comment         : String(1000);
  decidedAt       : Timestamp;
}

// srv/procurement-service.cds — Service definition
using { z.procurement as db } from '../db/schema';

service ProcurementService @(requires: 'authenticated-user') {

  @odata.draft.enabled
  entity PurchaseOrders as projection on db.PurchaseOrders {
    *,
    items : redirected to PurchaseOrderItems,
    approvalHistory : redirected to ApprovalSteps
  } actions {
    @(requires: 'Approver')
    action approve (comment: String);
    @(requires: 'Approver')
    action reject  (comment: String);
    action submit();
  };

  @readonly
  entity PurchaseOrderItems as projection on db.PurchaseOrderItems;

  @readonly
  entity Suppliers as projection on db.Suppliers;

  @readonly
  entity Materials as projection on db.Materials;

  entity ApprovalSteps as projection on db.ApprovalSteps;
}

// srv/procurement-service.js — Custom event handlers
const cds = require('@sap/cds');
const LOG = cds.log('procurement');

module.exports = class ProcurementService extends cds.ApplicationService {

  async init() {
    const { PurchaseOrders, PurchaseOrderItems, ApprovalSteps } = this.entities;

    // Validate before saving
    this.before('CREATE', PurchaseOrders, async (req) => {
      const { orderNumber, items } = req.data;
      if (!orderNumber) {
        req.error(400, 'Order number is required', 'orderNumber');
      }
      if (!items || items.length === 0) {
        req.error(400, 'At least one line item is required', 'items');
      }
    });

    // Calculate totals on item changes
    this.before('SAVE', PurchaseOrders, async (req) => {
      const order = req.data;
      if (order.items) {
        let total = 0;
        for (const item of order.items) {
          item.netAmount = (item.quantity || 0) * (item.unitPrice || 0);
          total += item.netAmount;
        }
        order.totalAmount = total;
      }
    });

    // Bound action: submit for approval
    this.on('submit', PurchaseOrders, async (req) => {
      const order = await SELECT.one.from(PurchaseOrders)
        .where({ ID: req.params[0].ID })
        .columns('ID', 'status', 'totalAmount');

      if (order.status !== 'D') {
        return req.error(409, 'Only draft orders can be submitted');
      }
      if (!order.totalAmount || order.totalAmount <= 0) {
        return req.error(400, 'Order must have a positive total amount');
      }

      // Determine approval strategy based on amount
      const approver = order.totalAmount > 10000
        ? await this._getManagerApprover(req.user.id)
        : req.user.id;  // self-approval for small amounts

      await UPDATE(PurchaseOrders)
        .set({ status: 'S' })
        .where({ ID: order.ID });

      await INSERT.into(ApprovalSteps).entries({
        parent_ID: order.ID,
        stepNumber: 1,
        approver: approver,
        decision: 'P'
      });

      LOG.info('Order submitted', { orderID: order.ID, approver });
      return { status: 'S' };
    });

    // Bound action: approve
    this.on('approve', PurchaseOrders, async (req) => {
      const { ID } = req.params[0];
      const { comment } = req.data;

      const step = await SELECT.one.from(ApprovalSteps)
        .where({ parent_ID: ID, approver: req.user.id, decision: 'P' });

      if (!step) {
        return req.error(403, 'No pending approval found for current user');
      }

      await UPDATE(ApprovalSteps)
        .set({
          decision: 'A',
          comment: comment || '',
          decidedAt: new Date().toISOString()
        })
        .where({ ID: step.ID });

      await UPDATE(PurchaseOrders)
        .set({ status: 'A' })
        .where({ ID });

      LOG.info('Order approved', { orderID: ID, approver: req.user.id });
    });

    // Bound action: reject
    this.on('reject', PurchaseOrders, async (req) => {
      const { ID } = req.params[0];
      const { comment } = req.data;

      if (!comment) {
        return req.error(400, 'Rejection comment is required');
      }

      const step = await SELECT.one.from(ApprovalSteps)
        .where({ parent_ID: ID, approver: req.user.id, decision: 'P' });

      if (!step) {
        return req.error(403, 'No pending approval found for current user');
      }

      await UPDATE(ApprovalSteps)
        .set({
          decision: 'R',
          comment,
          decidedAt: new Date().toISOString()
        })
        .where({ ID: step.ID });

      await UPDATE(PurchaseOrders)
        .set({ status: 'R' })
        .where({ ID });

      LOG.info('Order rejected', { orderID: ID, approver: req.user.id });
    });

    await super.init();
  }

  async _getManagerApprover(userId) {
    // In production: call SAP SuccessFactors or Identity Service
    // to resolve the manager hierarchy
    const { Users } = cds.entities('sap.ias');
    try {
      const user = await cds.connect.to('sap-ias')
        .then(srv => srv.get(`/Users('${userId}')/manager`));
      return user?.id || 'FALLBACK_APPROVER';
    } catch (err) {
      LOG.warn('Manager resolution failed, using fallback', err.message);
      return 'FALLBACK_APPROVER';
    }
  }
};

Claude Code is the strongest tool for CAP development. It understands the framework’s conventions: extending cds.ApplicationService, using this.before/this.on/this.after event handlers, the CDS query language (SELECT.one.from(), UPDATE().set().where(), INSERT.into().entries()), draft enablement via @odata.draft.enabled, authorization annotations (@requires), and the composition/association patterns that drive OData deep insert and expand behavior. It generates the SAVE event correctly for draft-enabled entities (the SAVE event fires when the user activates a draft, not on individual CREATE/UPDATE operations). Cursor handles CAP well because it indexes the full project structure and learns from the @sap/cds package types, producing consistent completions that match the project’s existing patterns. Copilot generates reasonable Node.js but often produces Express.js middleware patterns (app.post('/approve', ...)) instead of CAP event handler patterns, which is a fundamental misunderstanding of the framework. Gemini CLI can discuss CAP architecture and generate CDS models effectively but sometimes confuses CAP CDS syntax with ABAP CDS syntax (different languages, different annotation systems). Windsurf and Amazon Q have weak CAP support and typically generate generic REST API code that ignores the entire CAP runtime.

4. RFC/BAPI/IDoc Integration

Integrating with SAP from external systems is where most non-SAP developers first encounter the SAP ecosystem, and it is where AI tools produce their most confidently wrong output. The integration layer has three primary mechanisms: Remote Function Calls (RFCs) for synchronous function invocation, BAPIs (Business Application Programming Interfaces) for standardized business object operations, and IDocs (Intermediate Documents) for asynchronous message exchange. Each has different calling conventions, error handling patterns, and transactional semantics that AI tools consistently conflate.

An RFC call is a remote procedure call to an ABAP function module. A BAPI is a specific type of RFC that follows SAP’s BAPI programming guidelines: it uses a RETURN parameter (structure BAPIRET2 or table of BAPIRET2) for error reporting instead of exceptions, and it requires an explicit BAPI_TRANSACTION_COMMIT call to persist changes (BAPIs do not commit automatically, which is the number one integration bug). An IDoc is an XML or flat-file message format used for EDI and asynchronous integration, processed by SAP’s IDoc framework with status tracking, error handling, and reprocessing capabilities. AI tools treat all three as interchangeable “API calls,” which leads to integration code that silently loses data because it never commits, never checks the RETURN table for errors, or sends malformed IDocs that land in status 51 (application error) and sit unprocessed until someone checks transaction WE02.

Python RFC integration with pyrfc

"""
SAP RFC/BAPI Integration with proper error handling.
Demonstrates BAPI_SALESORDER_CREATEFROMDAT2 — the standard BAPI
for creating sales orders in SAP SD.

Requirements: pyrfc (pip install pyrfc), SAP NW RFC SDK installed.
"""
from pyrfc import Connection, ABAPApplicationError, ABAPRuntimeError, \
    LogonError, CommunicationError
from dataclasses import dataclass, field
from typing import Optional
import logging

logger = logging.getLogger(__name__)

@dataclass
class SAPConnectionParams:
    ashost: str       # Application server host
    sysnr: str        # System number (00-99)
    client: str       # SAP client (e.g., '100')
    user: str
    passwd: str
    lang: str = 'EN'
    saprouter: str = ''  # SAP Router string for external access

@dataclass
class SalesOrderItem:
    material: str
    quantity: float
    plant: str
    item_category: str = ''  # Let SAP determine from material/order type

@dataclass
class SalesOrderHeader:
    order_type: str       # e.g., 'OR' for standard order
    sales_org: str        # e.g., '1000'
    dist_channel: str     # e.g., '10'
    division: str         # e.g., '00'
    sold_to_party: str    # Customer number
    po_number: str = ''   # Customer PO reference
    req_delivery_date: str = ''  # YYYYMMDD

@dataclass
class BAPIResult:
    success: bool
    sales_order: str = ''
    messages: list = field(default_factory=list)

class SAPSalesOrderClient:
    """SAP Sales Order integration via BAPI."""

    def __init__(self, params: SAPConnectionParams):
        self._params = params
        self._conn: Optional[Connection] = None

    def __enter__(self):
        self.connect()
        return self

    def __exit__(self, exc_type, exc_val, exc_tb):
        self.disconnect()
        return False

    def connect(self):
        """Establish RFC connection with proper error handling."""
        try:
            conn_params = {
                'ashost': self._params.ashost,
                'sysnr':  self._params.sysnr,
                'client': self._params.client,
                'user':   self._params.user,
                'passwd': self._params.passwd,
                'lang':   self._params.lang,
            }
            if self._params.saprouter:
                conn_params['saprouter'] = self._params.saprouter

            self._conn = Connection(**conn_params)
            logger.info('RFC connection established to %s client %s',
                        self._params.ashost, self._params.client)

        except LogonError as e:
            logger.error('SAP logon failed: %s', e)
            raise
        except CommunicationError as e:
            logger.error('RFC communication error: %s', e)
            raise

    def disconnect(self):
        """Close RFC connection."""
        if self._conn:
            self._conn.close()
            self._conn = None

    def create_sales_order(
        self,
        header: SalesOrderHeader,
        items: list[SalesOrderItem],
    ) -> BAPIResult:
        """
        Create a sales order via BAPI_SALESORDER_CREATEFROMDAT2.

        CRITICAL: BAPIs do NOT auto-commit. You MUST call
        BAPI_TRANSACTION_COMMIT after a successful BAPI call,
        or BAPI_TRANSACTION_ROLLBACK on failure.
        """
        if not self._conn:
            raise RuntimeError('Not connected — call connect() first')

        # Build BAPI import structures
        order_header_in = {
            'DOC_TYPE':    header.order_type,
            'SALES_ORG':   header.sales_org,
            'DISTR_CHAN':   header.dist_channel,
            'DIVISION':     header.division,
            'PURCH_NO_C':   header.po_number,
            'REQ_DATE_H':   header.req_delivery_date or '00000000',
        }

        order_partners = [
            {
                'PARTN_ROLE': 'AG',  # Sold-to party
                'PARTN_NUMB': header.sold_to_party,
            }
        ]

        order_items_in = []
        order_schedules_in = []
        for idx, item in enumerate(items, start=1):
            item_number = str(idx * 10).zfill(6)  # 000010, 000020, ...
            order_items_in.append({
                'ITM_NUMBER': item_number,
                'MATERIAL':   item.material,
                'PLANT':      item.plant,
                'TARGET_QTY': str(item.quantity),
                'ITEM_CATEG': item.item_category,
            })
            order_schedules_in.append({
                'ITM_NUMBER': item_number,
                'SCHED_LINE': '0001',
                'REQ_QTY':    str(item.quantity),
            })

        try:
            result = self._conn.call(
                'BAPI_SALESORDER_CREATEFROMDAT2',
                ORDER_HEADER_IN=order_header_in,
                ORDER_PARTNERS=order_partners,
                ORDER_ITEMS_IN=order_items_in,
                ORDER_SCHEDULES_IN=order_schedules_in,
            )

            # Parse RETURN table — this is where BAPI errors live
            messages = []
            has_error = False
            for msg in result.get('RETURN', []):
                messages.append({
                    'type':    msg.get('TYPE', ''),
                    'id':      msg.get('ID', ''),
                    'number':  msg.get('NUMBER', ''),
                    'message': msg.get('MESSAGE', ''),
                })
                if msg.get('TYPE') in ('E', 'A'):  # Error or Abort
                    has_error = True
                    logger.error('BAPI error: %s — %s',
                                 msg.get('NUMBER'), msg.get('MESSAGE'))

            sales_order = result.get('SALESDOCUMENT', '')

            if has_error or not sales_order:
                # ROLLBACK — do not leave dangling LUWs
                self._conn.call('BAPI_TRANSACTION_ROLLBACK')
                logger.warning('Sales order creation rolled back')
                return BAPIResult(
                    success=False,
                    messages=messages,
                )

            # COMMIT — this is MANDATORY for BAPIs
            # Without this call, the sales order exists in memory
            # but is never persisted to the database.
            commit_result = self._conn.call(
                'BAPI_TRANSACTION_COMMIT',
                WAIT='X',  # Synchronous commit — wait for DB update
            )

            logger.info('Sales order %s created successfully', sales_order)
            return BAPIResult(
                success=True,
                sales_order=sales_order,
                messages=messages,
            )

        except ABAPApplicationError as e:
            logger.error('ABAP application error: %s', e)
            self._conn.call('BAPI_TRANSACTION_ROLLBACK')
            return BAPIResult(success=False, messages=[{
                'type': 'A', 'message': str(e)
            }])
        except ABAPRuntimeError as e:
            logger.error('ABAP runtime error: %s', e)
            # Connection may be broken — do not attempt rollback
            return BAPIResult(success=False, messages=[{
                'type': 'A', 'message': f'ABAP runtime error: {e}'
            }])

# Usage
if __name__ == '__main__':
    params = SAPConnectionParams(
        ashost='sap-prod.example.com',
        sysnr='00',
        client='100',
        user='RFC_USER',
        passwd='***',  # Use SAP Secure Store in production
    )

    with SAPSalesOrderClient(params) as client:
        result = client.create_sales_order(
            header=SalesOrderHeader(
                order_type='OR',
                sales_org='1000',
                dist_channel='10',
                division='00',
                sold_to_party='0000001000',
                po_number='PO-2026-00142',
                req_delivery_date='20260415',
            ),
            items=[
                SalesOrderItem(material='MAT-001', quantity=10.0, plant='1000'),
                SalesOrderItem(material='MAT-002', quantity=5.0, plant='1000'),
            ],
        )
        if result.success:
            print(f'Created sales order: {result.sales_order}')
        else:
            print(f'Failed: {result.messages}')

The BAPI_TRANSACTION_COMMIT with WAIT='X' is the single most important line in any BAPI integration. Without it, the sales order is created in the application server’s memory but never written to the database. The WAIT='X' parameter makes the commit synchronous — without it, the commit is asynchronous and your code might check the order before the database write completes, finding nothing. AI tools consistently omit this call because it is not part of the BAPI itself — it is a separate function module that you must call explicitly after the business BAPI succeeds. Claude Code generates this pattern correctly, including the rollback path, the RETURN table parsing (checking for types ‘E’ and ‘A’), and the WAIT parameter. Cursor handles it when the project already has pyrfc examples to learn from. Copilot and Gemini CLI generate the BAPI call but frequently omit the commit, producing code that appears to work in testing (if you check immediately, the document might still be in memory) but loses data in production. Windsurf and Amazon Q generate generic REST API call patterns that do not apply to RFC at all.

5. Data Migration (LSMW, BODS, S/4HANA Migration)

Data migration in SAP is not an ETL job — it is a business process with legal implications. When you migrate customer master data from a legacy system to S/4HANA, every customer number, credit limit, payment term, and tax classification must be mapped correctly because those values determine how invoices are calculated, how dunning notices are sent, and how tax is reported to authorities. A migration that maps a payment term incorrectly — Net 30 instead of Net 60 — creates 10,000 invoices with wrong due dates, triggering premature dunning letters that damage customer relationships. A migration that drops the tax registration number for a European customer means SAP cannot perform the tax determination for intra-community supplies, and every invoice to that customer has incorrect VAT treatment until someone notices and manually corrects the master data.

The S/4HANA migration from ECC involves fundamental data model changes. The general ledger has been completely restructured: the classic tables BSEG, BKPF, BSID, BSAD, BSIK, BSAK are replaced by ACDOCA (the Universal Journal), which merges financial accounting, controlling, and material ledger into a single table. Customer and vendor master data (KNA1/KNB1/LFA1/LFB1) are replaced by the Business Partner model (BUT000/BUT020/BP001). Material stock tables (MARD, MARC, MCHB) are supplemented by MATDOC (the new material document table) and inventory management views. Migration tools must handle these structural transformations while preserving business meaning, referential integrity, and historical data for audit requirements that may span seven or more years.

S/4HANA Business Partner migration ABAP

*&---------------------------------------------------------------------*
*& Report Z_MIGRATE_CUSTOMER_TO_BP
*& Migrate legacy customer master to S/4HANA Business Partner
*& using CVI (Customer-Vendor Integration) synchronization.
*&---------------------------------------------------------------------*
REPORT z_migrate_customer_to_bp.

CLASS lcl_bp_migration DEFINITION FINAL.
  PUBLIC SECTION.
    TYPES: BEGIN OF ty_legacy_customer,
             customer_id     TYPE kunnr,
             name1           TYPE name1_gp,
             name2           TYPE name2_gp,
             street          TYPE ad_street,
             city            TYPE ad_city1,
             postal_code     TYPE ad_pstcd1,
             country         TYPE land1_gp,
             region          TYPE regio,
             tax_number      TYPE stcd1,
             payment_terms   TYPE dzterm,
             account_group   TYPE ktokd,
             sales_org       TYPE vkorg,
             dist_channel    TYPE vtweg,
             division        TYPE spart,
             currency        TYPE waers,
             reconciliation  TYPE akont,
           END OF ty_legacy_customer,
           tt_legacy_customers TYPE STANDARD TABLE OF ty_legacy_customer
                               WITH KEY customer_id.

    TYPES: BEGIN OF ty_migration_result,
             customer_id   TYPE kunnr,
             bp_number     TYPE bu_partner,
             status        TYPE char1,   " S=Success, E=Error, W=Warning
             message       TYPE string,
           END OF ty_migration_result,
           tt_migration_results TYPE STANDARD TABLE OF ty_migration_result
                                WITH EMPTY KEY.

    CLASS-METHODS execute
      IMPORTING
        it_customers TYPE tt_legacy_customers
        iv_test_mode TYPE abap_bool DEFAULT abap_true
      RETURNING
        VALUE(rt_results) TYPE tt_migration_results.

  PRIVATE SECTION.
    CLASS-METHODS migrate_single_customer
      IMPORTING
        is_customer TYPE ty_legacy_customer
        iv_test_mode TYPE abap_bool
      RETURNING
        VALUE(rs_result) TYPE ty_migration_result.

    CLASS-METHODS validate_customer
      IMPORTING
        is_customer TYPE ty_legacy_customer
      RETURNING
        VALUE(rv_valid) TYPE abap_bool.

    CLASS-METHODS map_account_group_to_bp_role
      IMPORTING
        iv_account_group TYPE ktokd
      RETURNING
        VALUE(rv_bp_role) TYPE bu_role.
ENDCLASS.

CLASS lcl_bp_migration IMPLEMENTATION.
  METHOD execute.
    DATA: lv_count_success TYPE i,
          lv_count_error   TYPE i.

    " Authorization check for BP maintenance
    AUTHORITY-CHECK OBJECT 'B_BUPA_GRP'
      ID 'BGRP'  DUMMY
      ID 'ACTVT' FIELD '01'.   " Create
    IF sy-subrc <> 0.
      APPEND VALUE #(
        status  = 'E'
        message = 'No authorization for Business Partner creation'
      ) TO rt_results.
      RETURN.
    ENDIF.

    LOOP AT it_customers ASSIGNING FIELD-SYMBOL(<customer>).
      DATA(ls_result) = migrate_single_customer(
        is_customer  = <customer>
        iv_test_mode = iv_test_mode
      ).
      APPEND ls_result TO rt_results.

      IF ls_result-status = 'S'.
        lv_count_success += 1.
      ELSE.
        lv_count_error += 1.
      ENDIF.

      " Commit every 100 records to avoid memory issues
      " and allow restart after errors
      IF lv_count_success MOD 100 = 0 AND iv_test_mode = abap_false.
        CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'
          EXPORTING wait = abap_true.
      ENDIF.
    ENDLOOP.

    " Final commit for remaining records
    IF iv_test_mode = abap_false.
      CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'
        EXPORTING wait = abap_true.
    ENDIF.

    " Log summary
    MESSAGE |Migration complete: { lv_count_success } success, | &&
            |{ lv_count_error } errors| TYPE 'I'.
  ENDMETHOD.

  METHOD migrate_single_customer.
    rs_result-customer_id = is_customer-customer_id.

    " Validate before attempting creation
    IF validate_customer( is_customer ) = abap_false.
      rs_result-status  = 'E'.
      rs_result-message = 'Validation failed — check mandatory fields'.
      RETURN.
    ENDIF.

    " Check if customer already migrated (idempotency)
    SELECT SINGLE partner FROM but000
      WHERE partner = @is_customer-customer_id
      INTO @DATA(lv_existing_bp).
    IF sy-subrc = 0.
      rs_result-bp_number = lv_existing_bp.
      rs_result-status    = 'W'.
      rs_result-message   = |BP { lv_existing_bp } already exists — skipped|.
      RETURN.
    ENDIF.

    DATA: ls_central_data  TYPE bapibus1006_central,
          ls_central_datax TYPE bapibus1006_central_x,
          ls_address       TYPE bapibus1006_address,
          lt_return        TYPE TABLE OF bapiret2.

    " Map to BP central data
    ls_central_data-searchterm1 = is_customer-name1(20).
    ls_central_datax-searchterm1 = abap_true.

    " Map to BP address
    ls_address-name        = is_customer-name1.
    ls_address-name_2      = is_customer-name2.
    ls_address-str_suppl3  = is_customer-street.
    ls_address-city        = is_customer-city.
    ls_address-postl_cod1  = is_customer-postal_code.
    ls_address-country     = is_customer-country.
    ls_address-region      = is_customer-region.

    " Determine BP role from account group
    DATA(lv_bp_role) = map_account_group_to_bp_role(
      is_customer-account_group
    ).

    IF iv_test_mode = abap_true.
      rs_result-status  = 'S'.
      rs_result-message = |Test mode — would create BP with role { lv_bp_role }|.
      RETURN.
    ENDIF.

    " Create Business Partner via BAPI
    CALL FUNCTION 'BAPI_BUPA_CREATE_FROM_DATA'
      EXPORTING
        partnercategory    = '1'      " Organization
        partnergroup       = lv_bp_role
        centraldata        = ls_central_data
        centraldataperson  = VALUE bapibus1006_central_person( )
        centraldataorganization = VALUE bapibus1006_central_organ(
          name1 = is_customer-name1
          name2 = is_customer-name2
        )
        addressdata        = ls_address
      IMPORTING
        businesspartner    = rs_result-bp_number
      TABLES
        return             = lt_return.

    " Check RETURN for errors
    LOOP AT lt_return ASSIGNING FIELD-SYMBOL(<msg>)
      WHERE type CA 'EA'.
      rs_result-status  = 'E'.
      rs_result-message = <msg>-message.
      RETURN.
    ENDLOOP.

    IF rs_result-bp_number IS INITIAL.
      rs_result-status  = 'E'.
      rs_result-message = 'BAPI returned no BP number and no error'.
      RETURN.
    ENDIF.

    rs_result-status  = 'S'.
    rs_result-message = |BP { rs_result-bp_number } created successfully|.
  ENDMETHOD.

  METHOD validate_customer.
    rv_valid = abap_true.
    IF is_customer-customer_id IS INITIAL
    OR is_customer-name1 IS INITIAL
    OR is_customer-country IS INITIAL
    OR is_customer-account_group IS INITIAL.
      rv_valid = abap_false.
    ENDIF.
  ENDMETHOD.

  METHOD map_account_group_to_bp_role.
    " Mapping depends on customer implementation
    " Common mappings for standard account groups:
    CASE iv_account_group.
      WHEN 'KUNA'. rv_bp_role = 'FLCU00'. " Sold-to party
      WHEN 'KUNL'. rv_bp_role = 'FLCU00'. " Vendor (1-time)
      WHEN 'KUNW'. rv_bp_role = 'FLCU00'. " Competitor
      WHEN OTHERS. rv_bp_role = 'FLCU00'. " Default
    ENDCASE.
  ENDMETHOD.
ENDCLASS.

" Selection screen for batch execution
SELECTION-SCREEN BEGIN OF BLOCK b01 WITH FRAME TITLE TEXT-001.
  PARAMETERS: p_file  TYPE string LOWER CASE OBLIGATORY,
              p_test  TYPE abap_bool AS CHECKBOX DEFAULT abap_true.
SELECTION-SCREEN END OF BLOCK b01.

START-OF-SELECTION.
  " In production: read from file, map, and call lcl_bp_migration=>execute
  " This is the framework — file parsing and mapping are customer-specific.

The key patterns here: idempotency check (skip if BP already exists), batch commit every 100 records (to avoid consuming all dialog work process memory and to enable restart after failures), test mode that validates without persisting, BAPI RETURN table parsing, and the account group to BP role mapping that is always customer-specific. AI tools miss the idempotency check (running the migration twice creates duplicate BPs), the batch commit pattern (committing only at the end means a failure at record 9,999 loses all 9,998 previous records), and the test mode concept (you always run a migration in simulation first). Claude Code generates structurally correct migration code with these patterns when prompted with enough context about the business requirements. Gemini CLI can discuss migration strategy at length but its ABAP generation is hit-or-miss. Cursor and Copilot produce ABAP that works syntactically but misses the operational patterns (batch commits, restart capability, reconciliation) that make the difference between a migration that runs once in production and one that requires three weekends of retries.

6. Oracle EBS/PL/SQL & Dynamics 365/X++ Development

ERP engineering extends beyond SAP. Oracle E-Business Suite runs on PL/SQL with its own API framework (Oracle Apps APIs), concurrent program architecture, and flexfield customization model. Microsoft Dynamics 365 Finance & Operations uses X++ — a C#-like language that compiles to CIL and runs on the .NET runtime — with its own ORM, form patterns, data entities, and extension model. Both share the same fundamental challenge as SAP: you are customizing a vendor application with strict rules about what you can modify and how, using proprietary languages with limited public training data.

Oracle EBS development centers on PL/SQL packages that interact with Oracle Apps tables through the API layer. You do not insert directly into OE_ORDER_HEADERS_ALL — you call OE_ORDER_PUB.PROCESS_ORDER, which validates the data, applies defaulting rules, runs pricing, checks credit, and manages the workflow. The API does all the work that would take thousands of lines of custom PL/SQL. Similarly, Dynamics 365 X++ development uses the Application Object Tree (AOT), chains of command for extensions (replacing the old overlayering approach), data entities for OData integration, and business events for integration with Power Platform and Azure services.

Oracle EBS: Concurrent program with PL/SQL API calls

CREATE OR REPLACE PACKAGE BODY xxcust_order_import_pkg AS
  /*
   * Custom concurrent program to import sales orders
   * from staging table into Oracle Order Management.
   *
   * Uses OE_ORDER_PUB.PROCESS_ORDER — the standard API
   * for order creation. NEVER insert directly into
   * OE_ORDER_HEADERS_ALL / OE_ORDER_LINES_ALL.
   */

  gc_api_version  CONSTANT NUMBER := 1.0;
  gc_batch_size   CONSTANT NUMBER := 100;

  PROCEDURE import_orders(
    errbuf    OUT VARCHAR2,
    retcode   OUT VARCHAR2,
    p_org_id  IN  NUMBER
  ) IS
    -- API output variables
    l_header_rec         OE_ORDER_PUB.Header_Rec_Type;
    l_line_tbl           OE_ORDER_PUB.Line_Tbl_Type;
    l_action_request_tbl OE_ORDER_PUB.Request_Tbl_Type;
    l_return_status      VARCHAR2(1);
    l_msg_count          NUMBER;
    l_msg_data           VARCHAR2(4000);
    l_msg_index_out      NUMBER;

    l_success_count      NUMBER := 0;
    l_error_count        NUMBER := 0;

    CURSOR c_staging IS
      SELECT *
        FROM xxcust_order_staging
       WHERE org_id        = p_org_id
         AND process_flag  = 'N'  -- Not yet processed
         AND error_message IS NULL
       ORDER BY order_reference
       FOR UPDATE OF process_flag;

  BEGIN
    -- Set org context — mandatory for multi-org
    mo_global.set_policy_context('S', p_org_id);
    fnd_global.apps_initialize(
      user_id      => fnd_global.user_id,
      resp_id      => fnd_global.resp_id,
      resp_appl_id => fnd_global.resp_appl_id
    );

    FOR rec IN c_staging LOOP
      BEGIN
        -- Initialize header
        l_header_rec := OE_ORDER_PUB.G_MISS_HEADER_REC;
        l_header_rec.operation     := OE_GLOBALS.G_OPR_CREATE;
        l_header_rec.order_type_id := rec.order_type_id;
        l_header_rec.sold_to_org_id := rec.customer_id;
        l_header_rec.ship_to_org_id := rec.ship_to_site_id;
        l_header_rec.price_list_id  := rec.price_list_id;
        l_header_rec.ordered_date   := SYSDATE;
        l_header_rec.cust_po_number := rec.po_number;
        l_header_rec.transactional_curr_code := rec.currency_code;

        -- Initialize line (simplified — single line per order)
        l_line_tbl.DELETE;
        l_line_tbl(1) := OE_ORDER_PUB.G_MISS_LINE_REC;
        l_line_tbl(1).operation         := OE_GLOBALS.G_OPR_CREATE;
        l_line_tbl(1).inventory_item_id := rec.item_id;
        l_line_tbl(1).ordered_quantity  := rec.quantity;
        l_line_tbl(1).order_quantity_uom := rec.uom_code;
        l_line_tbl(1).ship_from_org_id  := rec.warehouse_id;
        l_line_tbl(1).request_date      := rec.requested_date;

        -- Book order after creation
        l_action_request_tbl(1).entity_code := OE_GLOBALS.G_ENTITY_HEADER;
        l_action_request_tbl(1).request_type := OE_GLOBALS.G_BOOK_ORDER;

        -- Call the API
        OE_ORDER_PUB.PROCESS_ORDER(
          p_api_version_number => gc_api_version,
          p_init_msg_list      => FND_API.G_TRUE,
          p_return_values      => FND_API.G_FALSE,
          x_return_status      => l_return_status,
          x_msg_count          => l_msg_count,
          x_msg_data           => l_msg_data,
          p_header_rec         => l_header_rec,
          p_line_tbl           => l_line_tbl,
          p_action_request_tbl => l_action_request_tbl,
          -- OUT parameters
          x_header_rec         => l_header_rec,
          x_line_tbl           => l_line_tbl,
          x_action_request_tbl => l_action_request_tbl
        );

        IF l_return_status = FND_API.G_RET_STS_SUCCESS THEN
          UPDATE xxcust_order_staging
             SET process_flag  = 'Y',
                 order_number  = l_header_rec.order_number,
                 last_updated  = SYSDATE
           WHERE CURRENT OF c_staging;

          l_success_count := l_success_count + 1;
        ELSE
          -- Retrieve all error messages from the stack
          l_msg_data := '';
          FOR i IN 1..l_msg_count LOOP
            OE_MSG_PUB.Get(
              p_msg_index     => i,
              p_encoded       => FND_API.G_FALSE,
              p_data          => l_msg_data,
              p_msg_index_out => l_msg_index_out
            );
          END LOOP;

          UPDATE xxcust_order_staging
             SET process_flag  = 'E',
                 error_message = SUBSTR(l_msg_data, 1, 4000),
                 last_updated  = SYSDATE
           WHERE CURRENT OF c_staging;

          l_error_count := l_error_count + 1;
        END IF;

        -- Batch commit
        IF MOD(l_success_count, gc_batch_size) = 0 THEN
          COMMIT;
        END IF;

      EXCEPTION
        WHEN OTHERS THEN
          UPDATE xxcust_order_staging
             SET process_flag  = 'E',
                 error_message = SUBSTR(SQLERRM, 1, 4000),
                 last_updated  = SYSDATE
           WHERE CURRENT OF c_staging;
          l_error_count := l_error_count + 1;
      END;
    END LOOP;

    COMMIT;

    -- Concurrent program return
    fnd_file.put_line(fnd_file.output,
      'Import complete: ' || l_success_count || ' success, ' ||
      l_error_count || ' errors');

    IF l_error_count > 0 THEN
      retcode := '1';  -- Warning
      errbuf  := l_error_count || ' orders failed';
    ELSE
      retcode := '0';  -- Success
      errbuf  := NULL;
    END IF;

  END import_orders;

END xxcust_order_import_pkg;
/

Dynamics 365 X++: Chain of command extension

/// <summary>
/// Extension of SalesLineType to add custom validation
/// for minimum order quantity by customer group.
/// Uses Chain of Command (CoC) — the standard extension
/// pattern in D365 F&O. Never overlayer standard code.
/// </summary>
[ExtensionOf(classStr(SalesLineType))]
final class SalesLineType_Extension
{
    public boolean validateWrite(boolean _skipCreditCheck)
    {
        boolean ret = next validateWrite(_skipCreditCheck);

        if (ret)
        {
            SalesLine salesLine = this.parmSalesLine();

            // Custom validation: minimum order quantity
            ret = this.validateMinOrderQty(salesLine);
        }

        return ret;
    }

    private boolean validateMinOrderQty(SalesLine _salesLine)
    {
        boolean     isValid = true;
        CustTable   custTable = CustTable::find(_salesLine.CustAccount);

        // Lookup minimum quantity from custom table
        XXMinOrderQty minQtyRec = XXMinOrderQty::find(
            custTable.CustGroup,
            _salesLine.ItemId
        );

        if (minQtyRec.RecId != 0
            && _salesLine.SalesQty < minQtyRec.MinQty)
        {
            // Use SysInfoAction for clickable error with navigation
            isValid = checkFailed(
                strFmt("@XX:MinQtyError",
                    _salesLine.ItemId,
                    minQtyRec.MinQty,
                    _salesLine.UnitOfMeasure)
            );
        }

        return isValid;
    }
}

Cursor and Claude Code both handle PL/SQL and X++ reasonably well. Cursor excels when the project already has established patterns — it learns the Oracle Apps API calling conventions, the G_MISS record initialization pattern (you must use G_MISS records rather than null initialization, because the API interprets null as “clear this field” versus G_MISS as “leave this field unchanged”), and the concurrent program output format (fnd_file.put_line). Claude Code understands the Chain of Command pattern in X++ and correctly generates the next keyword call that chains to the base method — omitting next breaks the extension chain and effectively overrides the standard method, which is the exact problem CoC was designed to prevent. Copilot generates valid PL/SQL but often produces direct DML against Oracle Apps base tables instead of API calls, which bypasses all validation, defaulting, and workflow processing. Gemini CLI handles the conceptual discussion well but its X++ code generation is unreliable — it sometimes generates C# syntax that is close to X++ but not quite right (X++ uses str prefix for string functions, has a different inheritance syntax, and requires the [ExtensionOf] attribute rather than C#-style class inheritance for extensions). Windsurf and Amazon Q have minimal useful training data for either Oracle EBS APIs or D365 X++.

7. Enterprise Workflow & Business Process Automation

Enterprise workflow in SAP is not a simple state machine — it is a distributed process engine that coordinates human approvals, automated decisions, deadline monitoring, and exception handling across business objects. SAP Business Workflow (transaction SWDD) uses event-driven triggers: when a purchase order is created above a certain threshold, the system raises event BUS2012.CREATED, which triggers a workflow that routes an approval work item to the purchasing manager’s Universal Worklist. If the manager does not respond within three days, an escalation agent assigns the work item to their superior. If the work item is rejected, a notification is sent to the requisitioner and the purchase order status reverts to “In Approval.” This entire flow is configured in the workflow builder with steps, conditions, container elements, binding definitions, and agent determination rules — no code required for standard scenarios, but custom workflows require ABAP classes that implement specific interfaces.

The modern approach uses SAP Build Process Automation (formerly SAP Workflow Management on BTP), which provides a low-code workflow designer that integrates with S/4HANA via APIs, supports human task UIs built with SAP Build Apps, includes decision tables for rule-based routing, and connects to external systems through SAP Integration Suite. The transition from classic SAP Workflow to BTP-based process automation is similar to the broader ECC-to-S/4HANA-Cloud transition: on-premise control and complexity giving way to cloud simplicity with less customization depth. Both models coexist in most enterprise landscapes.

SAP Build Process Automation: Approval workflow with decision table

// SAP Build Process Automation — workflow definition (JSON)
// This is the API representation; typically designed in the visual editor
{
  "id": "z_po_approval_workflow",
  "name": "Purchase Order Approval",
  "version": "1.0.0",
  "starterInputs": {
    "PurchaseOrder": "string",
    "TotalAmount": "number",
    "Currency": "string",
    "CompanyCode": "string",
    "CostCenter": "string",
    "RequestorEmail": "string",
    "RequestorName": "string"
  },
  "steps": [
    {
      "type": "decision",
      "name": "DetermineApprovalLevel",
      "decisionTableId": "z_po_approval_rules",
      "inputMapping": {
        "amount": "${TotalAmount}",
        "currency": "${Currency}",
        "companyCode": "${CompanyCode}",
        "costCenter": "${CostCenter}"
      },
      "outputMapping": {
        "approverLevel": "ApproverLevel",
        "approverGroup": "ApproverGroup"
      }
    },
    {
      "type": "condition",
      "name": "CheckAutoApproval",
      "condition": "${ApproverLevel} == 'AUTO'",
      "trueBranch": "AutoApprove",
      "falseBranch": "HumanApproval"
    },
    {
      "id": "AutoApprove",
      "type": "automation",
      "name": "AutoApproveOrder",
      "automationId": "z_po_auto_approve",
      "inputMapping": {
        "purchaseOrder": "${PurchaseOrder}"
      }
    },
    {
      "id": "HumanApproval",
      "type": "approval",
      "name": "ManagerApproval",
      "assignedTo": {
        "type": "group",
        "value": "${ApproverGroup}"
      },
      "taskTitle": "Approve PO ${PurchaseOrder} — ${TotalAmount} ${Currency}",
      "taskDescription": "Purchase Order from ${RequestorName} for cost center ${CostCenter}",
      "dueDate": {
        "duration": "P3D"
      },
      "escalation": {
        "after": "P5D",
        "to": {
          "type": "role",
          "value": "SeniorPurchasingManager"
        }
      },
      "outcomes": ["APPROVED", "REJECTED", "REWORK"]
    },
    {
      "type": "condition",
      "name": "CheckApprovalResult",
      "conditions": [
        { "value": "APPROVED", "goto": "NotifyApproved" },
        { "value": "REJECTED", "goto": "NotifyRejected" },
        { "value": "REWORK", "goto": "NotifyRework" }
      ]
    },
    {
      "id": "NotifyApproved",
      "type": "mail",
      "to": "${RequestorEmail}",
      "subject": "PO ${PurchaseOrder} Approved",
      "body": "Your purchase order ${PurchaseOrder} for ${TotalAmount} ${Currency} has been approved."
    },
    {
      "id": "NotifyRejected",
      "type": "mail",
      "to": "${RequestorEmail}",
      "subject": "PO ${PurchaseOrder} Rejected",
      "body": "Your purchase order ${PurchaseOrder} has been rejected. Please contact your manager for details."
    },
    {
      "id": "NotifyRework",
      "type": "mail",
      "to": "${RequestorEmail}",
      "subject": "PO ${PurchaseOrder} — Changes Requested",
      "body": "Your purchase order ${PurchaseOrder} requires changes. Please review and resubmit."
    }
  ]
}

// Decision table: z_po_approval_rules
// Determines approval routing based on amount and company code
//
// | Amount (Currency) | Company Code | Cost Center Pattern | -> Approver Level | Approver Group           |
// |-------------------|--------------|---------------------|-------------------|--------------------------|
// | <= 1000 EUR       | *            | *                   | AUTO              |                          |
// | <= 5000 EUR       | 1000         | CC10*               | L1                | PurchasingManagers_DE    |
// | <= 5000 EUR       | 2000         | *                   | L1                | PurchasingManagers_US    |
// | <= 50000 EUR      | *            | *                   | L2                | SeniorPurchasingManagers |
// | > 50000 EUR       | *            | *                   | L3                | VPProcurement            |

Claude Code handles workflow design well because it understands the business process logic: approval thresholds, escalation patterns, rework loops, and the decision table structure that drives routing. It can generate the complete workflow definition with proper variable binding, due date calculations using ISO 8601 durations, and escalation chains. It also understands the relationship between the workflow and the backend API calls that actually approve or reject the purchase order in S/4HANA. Cursor handles the JSON/JavaScript aspects but does not have the SAP-specific business process knowledge to generate correct decision tables or escalation rules without detailed prompting. Copilot generates generic workflow patterns (AWS Step Functions, Temporal) that do not map to SAP’s workflow model. Gemini CLI can discuss workflow architecture comprehensively given its large context window but generates workflow definitions that mix SAP-specific and generic concepts. Windsurf and Amazon Q produce generic process automation code without SAP integration awareness.

What AI Tools Get Wrong About ERP/SAP

Every AI tool makes SAP-specific errors that an experienced consultant would catch immediately but a junior developer might deploy to production. These are not edge cases — they are the most common failure patterns, encountered in virtually every AI-generated SAP code snippet.

• Generating obsolete ABAP syntax: AI tools produce MOVE source TO target instead of target = source, COMPUTE result = a + b instead of result = a + b, IF NOT var IS INITIAL instead of IF var IS NOT INITIAL, CALL METHOD obj->method instead of obj->method( ), CREATE OBJECT instead of NEW, and READ TABLE itab WITH KEY field = value without INTO or ASSIGNING result specification. They generate SELECT ... ENDSELECT loops instead of SELECT ... INTO TABLE, which performs a separate database roundtrip for each row — catastrophic on HANA where the overhead per roundtrip dominates the actual data retrieval time. They use WRITE statements inside methods, which only works in classic reports and produces no output in HTTP-triggered contexts (OData, RFC, background jobs). Every one of these patterns was deprecated at least a decade ago. Code review at any SAP shop following the Clean ABAP guidelines will reject all of them. The fundamental issue: AI training data includes decades of legacy ABAP examples, blog posts, and forum answers that teach the old syntax because that is what existed when the material was written.
• Ignoring SAP naming conventions (Z/Y namespace, customer exits): All custom development objects in SAP must use the customer namespace — names starting with Z or Y for the default namespace, or a registered namespace like /COMPANY/ for ISV solutions. AI tools generate programs named SALES_ORDER_REPORT, classes named CL_ORDER_PROCESSOR, tables named ORDER_STAGING — all of which conflict with the SAP namespace and will either fail to activate (if they collide with an existing SAP object) or will be overwritten during the next system upgrade. The correct names are Z_SALES_ORDER_REPORT, ZCL_ORDER_PROCESSOR, ZORDER_STAGING. This is not a convention — it is enforced by the ABAP workbench. Additionally, AI tools name function modules without the Z_ prefix, name message classes without considering the customer namespace, and create data elements and domains that collide with SAP standard naming. The entire transport and upgrade system depends on the namespace separation between SAP standard and customer objects.
• Wrong transport layer handling: AI tools generate ABAP code as standalone files, ignoring the transport system entirely. In reality, every ABAP object is assigned to a package (formerly development class), which is assigned to a transport layer, which determines the transport route through the system landscape. A workbench transport request contains all the objects you have created or modified, and it must be released and imported through DEV → QAS → PRD in sequence. AI tools do not understand that creating a Z-table requires a transport request for the dictionary object, a separate transport (or the same one) for any data loads, and that the table must be activated in the target system before any code that references it can be transported. They generate code that references objects that do not exist yet in the target system, creating transport dependency issues that block the entire import queue and require manual intervention by a Basis administrator.
• Incorrect authorization object checks: AI tools either omit AUTHORITY-CHECK entirely or generate checks against wrong authorization objects. The correct authorization object depends on the business context: F_BKPF_BUK for financial document access by company code, M_BEST_BSA for purchase order creation by document type, V_VBAK_VKO for sales order access by sales organization, S_TCODE for transaction authorization. Each object has specific fields that must be checked: ACTVT (activity — 01=create, 02=change, 03=display), plus the business-specific fields. AI tools generate AUTHORITY-CHECK OBJECT 'S_PROGRAM' as a generic check for everything, which only controls program execution and does not restrict business data access. The result: programs that pass authorization checks but expose data from all company codes, all plants, and all sales organizations to every user who can execute the transaction — a SOX compliance violation that auditors specifically look for.
• Misunderstanding SAP data dictionary types: The CURR (currency amount) data type requires a reference currency field — without it, the system cannot determine decimal places (JPY has zero, BHD has three, most currencies have two). AI tools create ABAP structures with TYPE p DECIMALS 2 for amounts instead of using the proper data element (like NETWR) that carries the currency reference. The DATS type stores dates as YYYYMMDD strings, meaning date arithmetic requires cl_abap_datfm or built-in date functions, not string manipulation. TIMS stores times as HHMMSS. QUAN (quantity) requires a unit of measure reference field. AI tools generate DATA lv_date TYPE d and then try lv_date = lv_date + 30 for date arithmetic (this actually works in ABAP for day addition, but lv_date - lv_date2 returns a day count as an integer, which confuses tools into thinking dates are integers). They create internal tables with TYPE TABLE OF generic types instead of using the proper table types with key definitions from the data dictionary. They ignore the client field (MANDT) handling, which is automatic in Open SQL but must be explicit in native SQL and ADBC.
• Generating Fiori code without proper OData annotations: A Fiori Elements application is driven by annotations, not by JavaScript UI code. AI tools generate custom SAPUI5 views with explicit sap.m.Table controls, sap.m.Input fields, and manual OData bindings instead of using the annotation-driven Fiori Elements approach where the runtime generates the UI from @UI.lineItem, @UI.identification, @UI.facet, and @UI.headerInfo annotations on the CDS view. The result is a Fiori app that looks like a Fiori app but does not benefit from the standard Fiori Elements features: variant management, table personalization, filter bar adaptation, export to Excel, draft handling, and automatic responsive layout. It also cannot be extended by customers using SAP Adaptation Projects, which is a key requirement for SAP partners building reusable applications. Even when AI tools generate annotations, they frequently use the wrong vocabulary: @sap.label (OData V2 annotation) instead of @EndUserText.label (CDS annotation), or @Common.Text without the proper @Common.TextArrangement annotation that controls whether the text is displayed before, after, or instead of the technical key.
• Ignoring SAP enhancement framework: When business requirements require modifying standard SAP behavior, AI tools suggest editing SAP standard code directly (“just add your logic after line 42 in the standard include”). This creates a modification that must be manually adjusted during every SAP upgrade and support package import (transactions SPAU/SPDD). The correct approach uses the enhancement framework: Business Add-Ins (BAdIs) for object-oriented enhancement spots with filter values, implicit enhancements (available at the beginning and end of every form routine and method), enhancement sections for inserting code at specific points in standard programs, Business Transaction Events (BTEs) for financial posting enhancements, and the new clean core extensibility framework for S/4HANA Cloud that uses released APIs and side-by-side extensions on BTP. AI tools do not know which BAdIs exist for a given business process, which filter values to use for BAdI implementations, or how to find the correct enhancement spot using transaction SE18 (BAdI definition) or SE19 (BAdI implementation). Finding the right enhancement point requires navigating the standard code with the enhancement framework browser — a skill that AI tools cannot replicate because they do not have access to the SAP system’s repository.
• Wrong RFC error handling patterns: AI tools generate RFC calls with basic try/catch blocks that catch generic exceptions. Correct RFC error handling must distinguish between communication failures (system unavailable, connection timeout — SYSTEM_FAILURE and COMMUNICATION_FAILURE in ABAP, CommunicationError in pyrfc), application errors (ABAP exception raised inside the function module), and BAPI return messages (not exceptions at all, but structured error messages in the RETURN parameter). Communication failures mean the remote system might have processed the request but the response was lost — you need idempotency to handle this. Application errors mean the input was rejected and nothing was persisted. BAPI return errors mean the BAPI executed but validation failed — you must explicitly rollback with BAPI_TRANSACTION_ROLLBACK or the partial changes remain in the LUW (Logical Unit of Work) and affect subsequent BAPI calls in the same session. AI tools flatten all of these into a single error handler, losing the distinction between retryable and non-retryable failures and between committed and uncommitted state.

Cost Model: What ERP/SAP Engineers Actually Pay

Scenario 1: SAP Consultant Learning ABAP — $0/month

• Copilot Free (2,000 completions/mo) for basic ABAP syntax, simple SELECT statements, and internal table operations
• Plus Gemini CLI Free for discussing SAP concepts, understanding CDS view annotations, and asking questions about SAP documentation with its 1M context window (paste entire SAP Help pages for analysis)
• Sufficient for learning: writing simple reports, understanding ABAP Objects basics, exploring CDS view syntax. You will need to manually verify every ABAP pattern against Clean ABAP guidelines — AI-generated ABAP at this level is frequently obsolete syntax that would not pass code review. Use the SAP Learning Hub and ABAP trial systems (available via SAP BTP Trial) for hands-on practice. Expect to rewrite 60-70% of generated ABAP code.

Scenario 2: Junior ABAP Developer — $10/month

• Copilot Pro ($10/mo) for unlimited completions when writing ABAP in ADT (Eclipse) or VS Code with ABAP extensions
• Good for day-to-day ABAP development: data declarations, internal table operations, SELECT statements with JOINs, class method implementations, ALV report scaffolding. Copilot learns your project’s patterns after a few files and produces consistent completions for repetitive structures (AUTHORITY-CHECK blocks, BAPI RETURN parsing, exception class definitions). Be vigilant about deprecated syntax in completions — Copilot frequently suggests MOVE, CALL METHOD, and READ TABLE without result specification. Worth the $10 for the productivity gain on boilerplate, but review everything against the ABAP style guide.

Scenario 3: SAP Fiori/UI5 Developer — $20/month

• Cursor Pro ($20/mo) for codebase-indexed development across UI5 components, manifest.json, i18n files, and OData service metadata
• The best single tool for Fiori development. Cursor indexes your entire Fiori project — Component.js, manifest.json, XML views, controllers, model files, test pages — and produces completions that match your project’s existing conventions. It handles UI5 control API patterns (binding syntax, formatter functions, event handler signatures), Fiori Elements configuration (routing targets, control configuration, variant management settings), and the i18n resource model pattern. Significantly faster than Copilot for multi-file Fiori development where changes span the manifest, XML views, and controller files simultaneously.

Scenario 4: SAP BTP/CAP Developer — $20/month

• Claude Code ($20/mo) for CAP CDS modeling, service design, custom event handlers, and BTP integration architecture
• The best tool for the thinking-heavy parts of BTP development. Claude Code understands CAP’s convention-over-configuration philosophy, generates correct event handler patterns (before/on/after hooks, draft activation events, bound and unbound actions), and handles the CDS modeling for complex domain models with compositions, aspects, and localized fields. It is particularly strong for architectural decisions: when to use a CAP service versus a direct HANA Cloud procedure, how to structure multitenancy with the @cds.requires: 'mtx' annotation, and how to integrate with SAP Destination Service for on-premise system connectivity through Cloud Connector.

Scenario 5: Senior SAP Architect — $40/month

• Claude Code ($20/mo) for architecture decisions, integration pattern design, CDS view modeling, and complex ABAP logic
• Plus Cursor Pro ($20/mo) for daily development velocity across ABAP, Fiori, CAP, and integration code
• The optimal combination for senior SAP engineers who work across the full stack. Claude Code for the design questions: should this logic be a CDS view, an AMDP, or application-server ABAP? Which BAdI handles this enhancement requirement? How should the migration cockpit custom object be structured? Cursor for the execution: writing the CDS views, implementing the BAdI class, building the Fiori app, coding the integration iFlow. This combination covers both the “what to build” and the “how to build it” across SAP’s entire technology stack.

Scenario 6: SAP SI/Consulting Firm — $99/seat

• Copilot Enterprise ($39/mo) or Cursor Business ($40/mo) for team-wide codebase indexing of customer SAP projects, coding standards enforcement, and knowledge sharing across consultants
• Plus Claude Code ($20/mo) for senior consultants doing architecture and technical design
• SAP system integrators (Accenture, Deloitte, Cognizant, Infosys, and the hundreds of mid-market partners) have a specific need: onboard junior consultants quickly onto customer-specific codebases, enforce consistent coding standards across teams of 20-50 developers, and share knowledge about customer-specific enhancement patterns and data model extensions. Enterprise tiers index the customer’s entire Z-namespace codebase (often hundreds of thousands of lines across Z-programs, Z-function modules, Z-classes, and CDS views), enabling consultants to discover existing implementations before writing duplicates. Tabnine Enterprise ($39/user/mo) offers private deployment for customers with strict data residency requirements who cannot send SAP code to external AI providers.

The ERP/SAP Engineer’s Verdict

AI coding tools in 2026 are useful but not trustworthy for ERP/SAP engineering. They accelerate the mechanical parts of SAP development — writing ABAP class shells, generating CDS view skeletons, scaffolding Fiori manifest.json configurations, producing boilerplate for BAPI integration — but they lack the domain knowledge that makes SAP code production-ready. The gap between “syntactically valid ABAP” and “transport-managed, authorization-checked, enhancement-framework-aware, HANA-optimized ABAP that passes a code review at a serious SAP shop” is enormous, and AI tools consistently fall into that gap. They generate code that runs in a sandbox and breaks in a landscape.

The fundamental problem is training data. SAP’s proprietary ecosystem means the public corpus of ABAP code is tiny compared to Python or JavaScript. The ABAP that does exist publicly is disproportionately from tutorials, learning exercises, and blog posts that use obsolete syntax because that is what existed when the content was created. The result: AI tools have internalized ABAP patterns from 2005 and present them as current best practice. They generate MOVE and COMPUTE and CALL METHOD because those keywords appear frequently in the training data, not because they are correct in 2026. CDS views, CAP, and Fiori Elements are underrepresented in training data because they are newer technologies with less publicly available code. The irony is that the technologies where AI tools would add the most value (complex CDS view annotations, CAP event handler patterns, Fiori Elements configuration) are exactly the technologies with the least training data.

The tool-specific recommendations: Claude Code is the best single tool for ERP/SAP reasoning — it understands why BAPI_TRANSACTION_COMMIT is mandatory, why authorization checks must precede data access, why CDS view entities replaced classic CDS views, and how to structure CAP services with proper draft handling and bound actions. Use it for design decisions, code review, and complex logic where understanding the “why” matters more than typing speed. Cursor Pro is the best for daily development velocity, especially for Fiori/UI5 where the JavaScript ecosystem gives it strong training data and codebase indexing provides project-specific context. Copilot Pro is the budget option that handles ABAP boilerplate adequately but requires constant vigilance for obsolete patterns. Gemini CLI is the best free option for discussing SAP architecture — paste the SAP Help documentation for a BAdI or CDS annotation into its 1M context window and get detailed guidance. Amazon Q and Windsurf have too little SAP-specific training data to be useful for core SAP development, though Amazon Q handles general enterprise patterns (IAM, cloud architecture) where SAP intersects with AWS infrastructure.

The right workflow for SAP engineers: use AI tools for scaffolding and boilerplate, verify every generated pattern against the Clean ABAP guidelines and SAP’s current development best practices, and never skip the manual checks that AI tools consistently miss — authorization checks, transport dependencies, naming conventions, and the enhancement framework. The 30% of development time that AI tools save on typing is real. The 300% of debugging time you spend when AI-generated code breaks in QAS because it references an object that has not been transported, uses an obsolete BAPI that was replaced in S/4HANA, or exposes data from all company codes because it forgot the AUTHORITY-CHECK — that is also real. The net productivity gain depends entirely on how rigorously you review what the AI produces.

Compare all tools and pricing on our main comparison table, or check the cheapest tools guide for budget options.

Related on CodeCosts

• AI Coding Tools for Backend Engineers (2026) — server-side development, APIs, database integration
• AI Coding Tools for Enterprise Engineers (2026) — large-scale enterprise application development
• AI Coding Tools for Database Administrators (2026) — SQL optimization, schema design, HANA and Oracle tuning
• AI Coding Tools for Compliance Engineers (2026) — SOX compliance, audit preparation, regulatory requirements
• AI Coding Tools for Data Engineers (2026) — ETL pipelines, data warehousing, migration tooling