9 個 AI 編碼助手常犯的 ABAP 錯誤及預防方法

AI coding assistants are great at languages with millions of public examples. ABAP isn't one of them, and it trips them up in two specific ways:

1. The language changes a lot between releases. Code that activates on S/4HANA 2023 can be a syntax error on an ECC system running SAP_BASIS 7.50.
2. Most of what you call lives inside SAP systems, not on GitHub. Function modules, BAPIs, CDS views and tables aren't public, so the model can't check whether they exist. It guesses, and the guesses look convincing.

The result is a small set of mistakes that come back again and again, whether you use Cursor, Claude Code or GitHub Copilot. Here are nine of them, with the fix for each.

TL;DR

• Tell the assistant your language version, product and SAP_BASIS release first. Most wrong ABAP is valid syntax from a different release.
• Guard every FOR ALL ENTRIES with IF itab IS NOT INITIAL.
• Plausible names prove nothing. Verify every SAP object the assistant uses.
• Table expressions don't set sy-subrc, BAPIs report errors in RETURN, and RAP owns the LUW.
• Put these points in a short rules file and keep ATC and ABAP Unit as the real gate.

1. Syntax from the wrong release

The assistant doesn't know which system you're on, so it writes the newest syntax it has seen. Some availability dates worth knowing (from SAP's ABAP Keyword Documentation release notes):

ECC 6.0 runs on SAP_BASIS 7.50 at most (EHP8), so x += 1. won't compile there, and neither will a view entity. On 7.40 SP05 to SP07, this is a syntax error:

SELECT vbeln, erdat FROM vbak
  WHERE erdat >= @date_from
  INTO TABLE @DATA(orders).   " needs 7.40 SP08

The SP05-safe version declares the target first:

TYPES: BEGIN OF ty_order,
         vbeln TYPE vbak-vbeln,
         erdat TYPE vbak-erdat,
       END OF ty_order.
DATA orders TYPE STANDARD TABLE OF ty_order WITH EMPTY KEY.

SELECT vbeln, erdat FROM vbak
  INTO TABLE @orders
  WHERE erdat >= @date_from.

Prevention: give the assistant three facts before it writes a line: language version (ABAP for Cloud Development or Standard ABAP), product (S/4HANA or ECC) and release. If you can't, tell it to assume the lowest plausible release and never mix syntax from different releases in one answer.

2. FOR ALL ENTRIES on an empty table

This one activates fine and passes a quick test, which is why it's dangerous. If the internal table after FOR ALL ENTRIES IN is empty, the whole WHERE clause is ignored and every row of the database table is read.

IF keys IS NOT INITIAL.
  SELECT vbeln, erdat FROM vbak
    FOR ALL ENTRIES IN @keys
    WHERE vbeln = @keys-vbeln
    INTO TABLE @DATA(orders).
ENDIF.

FOR ALL ENTRIES also removes duplicate result rows, so select all key fields or you lose data silently. There's a full walkthrough in FOR ALL ENTRIES with an empty table.

3. Invented function modules, BAPIs and CDS views

Z_GET_ORDER_STATUS, I_SomethingView, BAPI_WHATEVER: invented names follow SAP's naming conventions, so they read as real. A model will also invent parameter names for function modules that do exist.

Prevention: require the assistant to name every SAP object it relies on and to flag the ones it isn't sure about. Then check them yourself: "Open ABAP Development Object" in ADT, SE37/SE24/SE11 in SAP GUI, or SAP's Cloudification Repository for the release state. In ABAP Cloud only released objects are allowed, and an I_ prefix is not proof of either existence or release.

4. Checking sy-subrc after a table expression

Models trained on classic READ TABLE code write this:

DATA(item) = items[ id = key ].
IF sy-subrc <> 0.       " never reached on a miss
  ...
ENDIF.

A table expression doesn't set sy-subrc. If the line isn't found it raises CX_SY_ITAB_LINE_NOT_FOUND, and without a TRY block the program dumps. Use one of these instead:

IF line_exists( items[ id = key ] ).
  ...
ENDIF.

" 7.40 SP08+: initial value instead of an exception
item = VALUE #( items[ id = key ] OPTIONAL ).

(The exception: ASSIGN items[ id = key ] TO <item>. does set sy-subrc and raises nothing.)

5. Java, C# and JavaScript habits

ABAP looks enough like other languages for the model to slip:

IF a != b.          " wrong: ABAP uses <>
i++.                " wrong: no ++ operator
s = "text".         " wrong: " starts a comment

The correct forms are IF a <> b., i = i + 1. (or i += 1. from 7.54) and s = `text`. with backquotes or single quotes. There is no null either: use IS INITIAL or IS NOT BOUND. And RETURN value. only exists in functional methods from 7.58 (ABAP Cloud 2211); below that, assign the returning parameter and then RETURN.

6. boolc( ) instead of xsdbool( )

boolc( ) returns a string, not abap_bool, which can surprise you in comparisons. xsdbool( ) returns type c length 1 and works with abap_true / abap_false:

DATA(is_late) = xsdbool( due_date < today ).
IF is_late = abap_true.
  ...
ENDIF.

7. Classic ABAP inside ABAP Cloud

In ABAP for Cloud Development, sy-datum, WRITE, SUBMIT, CALL TRANSACTION, direct reads of SAP tables like VBAK and non-released function modules are not allowed. Assistants reach for them first because that's what most public ABAP looks like. For the date, use the released class:

DATA(today) = cl_abap_context_info=>get_system_date( ).   " UTC

That returns the system date in UTC. For the user's local date, SAP points to the XCO library with the user time zone.

8. COMMIT WORK inside a RAP handler

In the ABAP RESTful Application Programming Model (RAP), the framework owns the logical unit of work. COMMIT WORK, ROLLBACK WORK, COMMIT ENTITIES and ROLLBACK ENTITIES don't belong in behavior handler or saver methods. Errors go back through the failed and reported structures, not through MESSAGE or exceptions. Many classic BAPIs commit internally, so they must not be called in the interaction phase either.

9. Ignoring the BAPI RETURN table

BAPIs don't raise exceptions or set sy-subrc for business errors. They fill a RETURN table, so read it:

DATA return TYPE STANDARD TABLE OF bapiret2 WITH EMPTY KEY.
" ... call the BAPI, passing return ...
IF line_exists( return[ type = 'E' ] ) OR line_exists( return[ type = 'A' ] ).
  " handle the error, do not commit
ENDIF.

Commit separately with BAPI_TRANSACTION_COMMIT, and not once per record inside a loop.

How to stop repeating these corrections

You can paste these reminders into every prompt, but it's easier to put them in the file your tool reads automatically:

• Cursor: project rules in .cursor/rules/*.mdc (setup guide)
• Claude Code, Codex and other agents: AGENTS.md, imported from CLAUDE.md (guide)
• GitHub Copilot: .github/copilot-instructions.md plus path-specific instructions (guide)

Keep these files short. Every always-on line costs context, and long instruction files are followed less reliably. A good rules file states the target release, forbids invented objects, lists the traps above and ends with a self-check the assistant runs before answering.

Rules are guidance, not enforcement. The assistant can still ignore them, so keep the syntax check, ATC and ABAP Unit as your gate, and run them on everything AI-generated before it reaches a transport.

Free MIT-licensed ABAP rules for Cursor, Claude Code and Copilot are on GitHub, and there are more guides at abapforagents.com/guides.