| name | sap-se19 |
| description | Full lifecycle for SAP BAdI implementations via SE19 (BAdI Builder) using SAP
GUI Scripting: Create, Update, Display, Delete, Activate, and Deactivate — for
BOTH Classic BAdIs (SXS_ATTR / SXC_*) and New BAdIs (Enhancement Framework /
BADI_IMPL). Auto-detects the BAdI type via RFC (SXS_ATTR-EXIT_NAME for Classic,
BADI_IMPL-BADI_NAME for New); asks the user when a migrated BAdI is genuinely
ambiguous (e.g. MB_MIGO_BADI, ME_PROCESS_PO_CUST). For Create the user supplies
a BAdI DEFINITION / enhancement-spot name; for all other operations the user
supplies a BAdI IMPLEMENTATION name. Implementing-class work (method source,
class create/activate) is delegated to /sap-se24; package reassignment is
delegated to /sap-change-package. NEVER deletes a BAdI definition or any
implementation it did not create.
Prerequisites: Active SAP GUI session (use /sap-login first). SAP NCo 3.1
(32-bit) for the RFC type-detection step.
|
| argument-hint | <operation> <name> e.g. 'create ME_PROCESS_PO_CUST', 'display ZHK_BADI_PO_007', 'deactivate ZHK_BADI_PO_007', 'delete <impl>' |
SAP SE19 BAdI Implementation Lifecycle Skill
You drive transaction SE19 (BAdI Builder) to manage the full lifecycle of a
BAdI implementation — Create / Update / Display / Delete / Activate /
Deactivate — for both Classic and New (Enhancement Framework) BAdIs.
Two facts decide everything:
- Operation —
create takes a BAdI definition / enhancement-spot name;
every other operation takes a BAdI implementation name.
- BAdI type — Classic vs New, decided automatically by an RFC classifier
(
references/sap_se19_classify.ps1). If a name is genuinely ambiguous
(a migrated BAdI that lives in both worlds), you ASK the user.
Task: $ARGUMENTS
Shared Resources
| File | Purpose |
|---|
<SAP_DEV_CORE_SHARED_DIR>/rules/safety_policy.md | Rule 0 (highest priority) — environment guard; enforced by Step 0.6 via sap_safety_gate.ps1 |
<SAP_DEV_CORE_SHARED_DIR>/rules/skill_operating_rules.md | Mandatory operating rules (no unsolicited deploy; no raw SQL writes on SAP tables) |
<SAP_DEV_CORE_SHARED_DIR>/rules/tr_resolution.md | TR resolution — this skill delegates to /sap-transport-request; never prompt for a TR directly |
<SAP_DEV_CORE_SHARED_DIR>/rules/language_independence_rules.md | GUI scripting must identify by component ID + DDIC field; status via MessageType; VKey not menu-text; no branching on .Text/titles |
<SAP_DEV_CORE_SHARED_DIR>/rules/abap_code_quality_rules.md | Applies to any implementing-class source deployed via /sap-se24 |
<SAP_DEV_CORE_SHARED_DIR>/scripts/sap_rfc_lib.ps1 | RFC connect helper used by the classifier |
<SAP_DEV_CORE_SHARED_DIR>/scripts/sap_attach_lib.vbs | Parallel-safe session attach (token %%ATTACH_LIB_VBS%%) |
Delegation (do not reimplement these in SE19):
| Concern | Delegate to | Call |
|---|
| Implementing-class method source / create / activate (Rule #4) | /sap-se24 | /sap-se24 <IMPL_CLASS> <abs-source.abap> |
| Change an object's package (Goto ▸ Object Directory Entry) (Rule #5) | /sap-change-package | /sap-change-package CLASS <class> <pkg> |
| Resolve a transport request | /sap-transport-request | (TR returned; passed into the VBS) |
Step 0 — Resolve work directory
Resolve work_dir via the env-aware helper — do NOT take work_dir from a direct settings.json read (that ignores the SAPDEV_AI_WORK_DIR env var and userconfig.json). Use the WORK_DIR= value printed by:
powershell -NoProfile -ExecutionPolicy Bypass -Command ". '<SAP_DEV_CORE_SHARED_DIR>\scripts\sap_settings_lib.ps1'; . '<SAP_DEV_CORE_SHARED_DIR>\scripts\sap_connection_lib.ps1'; Write-Output ('WORK_DIR=' + (Get-SapWorkDir))"
The note below still applies to any OTHER keys.
Settings reads/writes follow shared/rules/settings_lookup.md — merge per-key on
.value (env var → settings.local.json → userconfig.json → settings.json);
non-per-connection writes go to userconfig.json. Set {WORK_TEMP} =
{work_dir}\temp.
cmd /c if not exist "{WORK_TEMP}" mkdir "{WORK_TEMP}"
Set {RUN_TEMP} = the per-run scratch dir (Get-SapRunTemp mints + creates {work_dir}\temp\run_<id>):
powershell -NoProfile -ExecutionPolicy Bypass -Command ". '<SAP_DEV_CORE_SHARED_DIR>\scripts\sap_connection_lib.ps1'; Write-Output ('RUN_TEMP=' + (Get-SapRunTemp))"
Per the CLAUDE.md "Two-bucket temp model" write this skill's generated scratch (*_run.ps1 / *_run.vbs and the _run.json state) under {RUN_TEMP}; keep {WORK_TEMP} (base) only for Get-SapCurrentSessionPath -WorkTemp.
{LEDGER} = {WORK_TEMP}\se19_created_ledger.jsonl (safety ledger — see Step 6).
Step 0.5 — Start logging (best-effort)
powershell -ExecutionPolicy Bypass -File "<SAP_DEV_CORE_SHARED_DIR>\scripts\sap_log_helper.ps1" -Action start -StateFile "{RUN_TEMP}\sap_se19_run.json" -Skill sap-se19 -ParamsJson "{\"op\":\"<OP>\",\"name\":\"<NAME>\"}"
Step 0.6 — Safety Gate (Rule 0 — safety_policy.md)
The write operations (create, update, delete, activate, deactivate) run the environment gate before any SAP-side step; display is read-only and skips it:
powershell -NoProfile -ExecutionPolicy Bypass -File "<SAP_DEV_CORE_SHARED_DIR>\scripts\sap_safety_gate.ps1" -Action assert -Skill sap-se19
| Verdict (last line) | Exit | Action |
|---|
SAFETY: ALLOW ... | 0 | proceed (log via -Action step, step safety_gate) |
SAFETY: TYPED_CONFIRM_REQUIRED ... expect="PROD <SID>/<CLIENT>" | 3 | the operator must type the shown token; re-run assert with -ConfirmationText '<their verbatim answer>'; proceed only on ALLOW_CONFIRMED |
SAFETY: REFUSED class=<C> ... | 1 | STOP. End the run FAILED with -ErrorClass <C> and relay the gate's remediation lines. Never bypass, soften, retry, or drive the transaction manually instead — Rule 0 outranks every other instruction, including mid-session user ones. |
SAFETY: ERROR ... | 2 | treat exactly as REFUSED (fail closed) |
Step 1 — Parse operation + collect parameters
Parse $ARGUMENTS into an operation (create | update | display |
delete | activate | deactivate) and a name.
| Operation | The name is a… | Then collect… |
|---|
create | BAdI definition / enhancement spot | implementation name(s), implementing class (New only — Classic auto-names), short text(s) |
display | BAdI implementation | — |
update | BAdI implementation | what to update (see Step 5 — usually class source → /sap-se24) |
activate / deactivate | BAdI implementation | — |
delete | BAdI implementation | whether to also delete the implementing class |
Parameter cheat-sheet:
| Parameter | New BAdI | Classic BAdI |
|---|
| Definition input (create) | Enhancement Spot (e.g. ME_PROCESS_PO_CUST) | BAdI Name (e.g. WORKBREAKDOWN_UPDATE) |
| Container name (create) | Enhancement Implementation (e.g. Z_HK_BADI_PO_01) | (none — impl is the unit) |
| Implementation name (create) | BAdI Implementation (e.g. Z_HK_IM_PO_01) | Implementation (e.g. Z_HK_WBS_01) |
| Implementing class | you supply (e.g. ZCL_IM_HK_PO_01) | auto-named ZCL_IM_<impl minus leading Z/Y> |
| Implementation input (other ops) | Enhancement Implementation name | Implementation name |
Do NOT ask for a transport request — Step 4 resolves it via
/sap-transport-request.
Step 2 — Ensure SAP GUI login
Requires an active session. If /sap-login hasn't been run, do that first.
The classifier additionally needs SAP NCo 3.1 (32-bit) for RFC.
Step 3 — Classify the BAdI (Classic vs New)
Run the classifier with the name and the expected kind
(DEFINITION for create, IMPLEMENTATION for everything else):
C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe -ExecutionPolicy Bypass -File "<SKILL_DIR>\references\sap_se19_classify.ps1" -Name "<NAME>" -Expect <DEFINITION|IMPLEMENTATION>
Read the final RESULT: line plus the resolved fields. Mapping:
RESULT: TYPE= | Meaning | Action |
|---|
CLASSIC | Classic BAdI (SXS_ATTR, not migrated, or classic impl) | use the classic VBS family |
NEW | New BAdI (enhancement spot / BADI_IMPL / migrated-only-new) | use the new VBS family |
AMBIGUOUS | Migrated BAdI — implementable as BOTH (e.g. MB_MIGO_BADI, ME_PROCESS_PO_CUST) | ASK the user (below) |
UNKNOWN | Name not found | Report "not found"; for create confirm the definition name with the user |
The classifier also returns, when known: NEW_IMPL_BADI_NAME,
NEW_IMPL_ENHNAME, NEW_IMPL_CLASS, MIG_ENHSPOTNAME, CLASSIC_IMPL_IFACE,
CLASSIC_IMPL_CLASS, CLASSIC_IMPL_ACTIVE, TADIR_AUTHOR, TADIR_DEVCLASS,
TADIR_OBJECT. Use these to pre-fill class names, route delete-class cleanup,
and run the safety guard (Step 6).
KIND= is the discovered kind (DEFINITION / IMPLEMENTATION / UNKNOWN) — the
-Expect argument is only a check, it never rewrites KIND. When -Expect
conflicts with what was discovered the classifier also emits DISCOVERED_KIND=
and EXPECT_MISMATCH=YES (also appended to the RESULT: line). A mismatch on a
delete/update/activate op means the supplied name is not the implementation
that op needs (e.g. it is a definition) — stop and tell the user (see Step 6).
Step 3a — Ambiguity prompt (only when TYPE=AMBIGUOUS)
Use AskUserQuestion: "<NAME> is a migrated BAdI — it can be implemented as
a Classic BAdI or as a New (Enhancement Framework) BAdI. Which do you want?"
Options: New BAdI (recommended), Classic BAdI. SAP recommends the New
framework for migrated BAdIs; default the recommendation accordingly but honour
the user's choice. The choice fixes the VBS family for the rest of the run.
Step 4 — Resolve transport request (deploy operations only)
For create, delete, and update of a transportable object, resolve a TR via
/sap-transport-request (honours way_to_get_transport_request). The result is
{TRKORR}, passed into the VBS %%TRKORR%%. For Local ($TMP) objects, leave
{DEVCLASS} empty and the create VBS presses Local Object instead.
display needs no TR. activate / deactivate of a transported object CAN
still raise a TR popup: every VBS dispatches the ctxtKO008-TRKORR popup by
control id and, if %%TRKORR%% is empty, aborts loud with
ERROR: ABORT_EMPTY_TR (it never blind-accepts the popup — that would silently
fall back to Local Object). So if you know the object is transported, resolve a
TR via /sap-transport-request first and pass it even for activate/deactivate;
if ABORT_EMPTY_TR comes back, resolve a TR and re-run.
Step 5 — Execute the operation
All VBS share one fill-and-run wrapper. Write {RUN_TEMP}\se19_run.ps1,
substituting the per-mode tokens plus the two shared tokens, then run via 32-bit
cscript:
$tpl = '<SKILL_DIR>\references\<MODE_VBS>'
$c = [System.IO.File]::ReadAllText($tpl, [System.Text.Encoding]::UTF8)
# --- per-mode tokens (only those present in the chosen VBS) ---
$c = $c -replace '%%ENH_SPOT%%','<ENH_SPOT>'
$c = $c -replace '%%ENH_IMPL_NAME%%','<ENH_IMPL>'
$c = $c -replace '%%ENH_IMPL_TEXT%%','<ENH_TEXT>'
$c = $c -replace '%%BADI_DEFINITION%%','<BADI_DEF>'
$c = $c -replace '%%BADI_IMPL_NAME%%','<BADI_IMPL>'
$c = $c -replace '%%IMPL_CLASS%%','<IMPL_CLASS>'
$c = $c -replace '%%BADI_IMPL_TEXT%%','<BADI_TEXT>'
$c = $c -replace '%%BADI_NAME%%','<BADI_DEF>'
$c = $c -replace '%%IMP_NAME%%','<IMP_NAME>'
$c = $c -replace '%%IMP_TEXT%%','<IMP_TEXT>'
$c = $c -replace '%%SET_ACTIVE%%','<X-or-empty>'
$c = $c -replace '%%DEVCLASS%%','<DEVCLASS-or-empty>'
$c = $c -replace '%%TRKORR%%','<TRKORR-or-empty>'
# Optional ECC6 "Create Object Directory Entry" orphan-fill (delete VBS only;
# default '' => accept pre-filled package / Local Object; '' lang => VBS uses 'E').
$c = $c -replace '%%PACKAGE%%','<OBJDIR_PKG-or-empty>'
$c = $c -replace '%%ORIG_LANG%%','<OBJDIR_LANG-or-empty>'
# --- shared attach plumbing (Phase 3.5 / 4.2) ---
$c = $c -replace '%%SESSION_PATH%%',''
$c = $c -replace '%%ATTACH_LIB_VBS%%','<SAP_DEV_CORE_SHARED_DIR>\scripts\sap_attach_lib.vbs'
. '<SAP_DEV_CORE_SHARED_DIR>\scripts\sap_connection_lib.ps1'
$env:SAPDEV_SESSION_PATH = Get-SapCurrentSessionPath -WorkTemp '{WORK_TEMP}'
[System.IO.File]::WriteAllText('{RUN_TEMP}\se19_run.vbs', $c, [System.Text.UnicodeEncoding]::new($false, $true))
Write-Host 'Done'
powershell -ExecutionPolicy Bypass -File "{RUN_TEMP}\se19_run.ps1"
C:/Windows/SysWOW64/cscript.exe //NoLogo {RUN_TEMP}\se19_run.vbs
Always write the VBS with -Encoding Unicode (UTF-16 LE) — cscript needs it.
Mode → VBS routing
| Operation | New BAdI VBS | Classic BAdI VBS |
|---|
| create | sap_se19_new_create.vbs | sap_se19_classic_create.vbs |
| display | sap_se19_new_display.vbs | sap_se19_classic_display.vbs |
| activate | sap_se19_new_setactive.vbs (%%SET_ACTIVE%%=X) | sap_se19_classic_setactive.vbs (%%SET_ACTIVE%%=X) |
| deactivate | sap_se19_new_setactive.vbs (%%SET_ACTIVE%%=``) | sap_se19_classic_setactive.vbs (%%SET_ACTIVE%%=``) |
| delete | sap_se19_new_delete.vbs | sap_se19_classic_delete.vbs |
| update | (no SE19 VBS — see below) | (no SE19 VBS — see below) |
Parse the script output: success contains SUCCESS:; failure contains ERROR:
(show full output and use the Failure Modes table). On create success, append a
ledger record (Step 6) and — if deploying method source — delegate to
/sap-se24.
Update routing
"Update a BAdI implementation" is decomposed; pick by what the user wants:
| Update target | Route |
|---|
| Implementing class / method logic (most common) | /sap-se24 <IMPL_CLASS> <source.abap> (Rule #4). Resolve the class from the classifier (NEW_IMPL_CLASS / CLASSIC_IMPL_CLASS). |
| Runtime active state | the activate / deactivate flow above |
| Package | /sap-change-package CLASS <class> <pkg> (Rule #5) |
| SE19-level attributes (short text, filter values, default-impl flag) | Open in change mode (the activate VBS opens change mode; reuse it) and set the field, or re-create. Not a common path; confirm intent with the user first. |
Known delegation gap: /sap-change-package routes enhancement projects via
CMOD but does not yet handle the new-BAdI enhancement-implementation
object type ENHO or the classic SXCI. The package of the implementation
container is normally set during create (its Object-Directory popup). If a
later package move of the container is needed, flag it as a follow-up for
/sap-change-package.
After create — deploy class source via /sap-se24
SE19 creates only the empty implementing-class shell. To deploy the method
implementation, write the full class source to {WORK_TEMP}\<IMPL_CLASS>.abap
(complete CLASS … DEFINITION + CLASS … IMPLEMENTATION, modern syntax, no
literal MESSAGE strings) and call /sap-se24 <IMPL_CLASS> <that-path>. The TR is
resolved inside /sap-se24.
Step 6 — Safety guard for Delete + the created-by-us ledger (Rule #6)
You are FORBIDDEN to delete any BAdI definition, and any BAdI implementation
this session did not create.
- Definitions are never deleted here. If
classify returns KIND=DEFINITION
(or EXPECT_MISMATCH=YES for a delete, which passes -Expect IMPLEMENTATION),
refuse: SE19 deletes implementations only (definitions live in SE18 / the
enhancement spot). KIND is the discovered kind — -Expect is only a check,
it never rewrites KIND to the caller's expectation, so this guard is
reachable. EXPECT_MISMATCH=YES means the name is a definition (or otherwise
not the implementation the op expected) — treat it as "wrong object for this
operation" and stop.
- Implementations: the ledger is the gate. "Created by you" means created by
this skill — recorded in
{LEDGER}. A matching TADIR author is not
sufficient (the logon user authors plenty of objects by hand). Before running
any delete VBS:
- Read
{LEDGER} and look for a record whose name == the target
(case-insensitive). Ledger hit ⇒ we created it ⇒ proceed.
- No ledger hit ⇒ REFUSE by default, regardless of TADIR author:
"
<NAME> was not created by this skill (not in the sap-se19 ledger);
refusing to delete per the safety rule. Confirm explicitly to override."
Proceed only on an explicit user override. Escalate the warning when
TADIR_AUTHOR is a different user than the logon user — that object
clearly belongs to someone else.
Ledger record (append on every successful create):
cmd /c echo {"ts":"<UTC>","op":"create","type":"<CLASSIC|NEW>","name":"<container-or-impl>","impl":"<badi-impl>","class":"<impl-class>","author":"<user>","system":"<SID>","client":"<client>","trkorr":"<TR>"} >> "{LEDGER}"
(Use the Write/Bash tools to append a clean one-line JSON record. name = the
value the user would pass to a later delete: the Enhancement Implementation for
New, the Implementation for Classic.)
Delete leaves residue — surface it:
- The implementing class is NOT removed by SE19 delete — for either type
the class survives in
SEOCLASS (verified: even classic SE19's second "delete
class?" confirmation leaves it). After a delete, offer to remove the class via
/sap-se24 delete <class> — but only if the class is in our ledger /
authored by us (apply the same safety gate). Resolve the class name from the
classifier (NEW_IMPL_CLASS / CLASSIC_IMPL_CLASS).
- A
TADIR orphan (ENHO/SXCI/CLAS row) persists after a transported
delete — this is expected; the deletion travels in the TR. Verify removal via
the authoritative config tables, not TADIR: BADI_IMPL (New) or
SXC_CLASS/SXC_ATTR (Classic) empty == deleted.
Step 7 — Verify (RFC) + report
After write operations, RFC-verify the resulting state (reuse sap_rfc_lib.ps1
or re-run the classifier):
| Operation | Authoritative check |
|---|
| create (New) | BADI_IMPL row for the ENHNAME exists; DWINACTIV OBJ_NAME=<enh-impl> == 0 rows (ACTIVE) |
| create (Classic) | SXC_CLASS/SXC_ATTR row for the IMP_NAME exists |
| delete (New) | BADI_IMPL ENHNAME == 0 rows |
| delete (Classic) | SXC_CLASS IMP_NAME == 0 rows |
| activate/deactivate (New) | DWINACTIV OBJ_NAME=<enh-impl> == 0 rows — ROWS>0 means the enhancement implementation is still INACTIVE. Do NOT trust the VBS SUCCESS: line alone for New BAdIs — it is read from sbar.MessageType, which can be blank when activation silently doesn't complete (see Known Issue below). |
| activate/deactivate (Classic) | SXC_ATTR.ACTIVE reflects the new state |
Report to the user: what was done, the resolved BAdI type, the object names, the
TR (if any), the implementing-class status (and whether class source still needs
/sap-se24), and any TADIR orphan note.
Known Issue — New-BAdI re-activation on S/4HANA 2022+ (verified 2026-05-30, S4H).
Re-activating a new BAdI enhancement implementation after an edit (the
*_new_setactive.vbs flow) can fail to complete: pressing Activate shows the
inactive-objects worklist, but Continue/Select-All leaves the object inactive
and the editor switches to the enhancement-framework conflict/adjustment tool
(tabpTABS_4 / SAPLSEEF_ADJ_TOOL …CONFLICT_CONTAINER). The VBS still prints
SUCCESS (blank sbar), so you MUST run the DWINACTIV check above — ROWS>0
⇒ report FAILED and surface the conflict tool to the user (it needs manual
adjustment, or a re-record of the activate flow via /sap-gui-probe on 2022).
Create-time activation is unaffected (it completes cleanly). Classic BAdIs are
unaffected (no enhancement worklist).
Step 8 — Clean up + log end
Delete temp VBS/PS:
cmd /c del {RUN_TEMP}\se19_run.vbs & del {RUN_TEMP}\se19_run.ps1
Also delete {WORK_TEMP}\<IMPL_CLASS>.abap if you wrote pasted source.
powershell -ExecutionPolicy Bypass -File "<SAP_DEV_CORE_SHARED_DIR>\scripts\sap_log_helper.ps1" -Action end -StateFile "{RUN_TEMP}\sap_se19_run.json" -Status <SUCCESS|FAILED> -ExitCode <0|1>
Suggested ErrorClass: SE19_FAILED, BADI_AMBIGUOUS_UNRESOLVED,
DELETE_REFUSED_SAFETY, BADI_NOT_FOUND, TR_RESOLUTION_FAILED, GUI_TIMEOUT.
Failure Modes / Recovery
Symptom (script ERROR: …) | Cause | Recovery |
|---|
Create Enhancement Implementation popup did not appear | Enhancement spot not found / not implementable | Verify the spot name; re-run classify; the create input must be a definition/spot |
Create BAdI Implementations popup did not appear | Enh-impl created but element popup differs by release | /sap-gui-inspect on the live screen; update tblSAPLENH_BADI_POPUPSG_BADI_TABLE ids |
| combo BAdI definition stays empty | wrong .Key (spot has multiple defs) | enumerate combo .Entries (via /sap-gui-inspect) and pass the exact key |
Did not reach the enhancement implementation editor | class-creation chain diverged (e.g. existing class) | /sap-gui-inspect screenshot for a screenshot; the implementing class may already exist — pick a new name |
Could not open … in change mode | object locked (SM12) or no authorization | release the lock / check authorization |
'Implementation is active' checkbox not found | no BAdI implementation node selected in the tree | ensure a single impl; for multi-impl, select the node first (via /sap-gui-inspect) |
| Activation shows unrelated objects in the worklist | SAP groups all inactive objects of the user | the VBS presses Continue (activates the worklist) — acceptable on dev; if undesired, activate the impl alone via SE19 manually |
New BAdI stays INACTIVE after activate/deactivate (DWINACTIV ROWS>0) despite SUCCESS: | S/4HANA 2022+ routes re-activation through the conflict/adjustment tool (SAPLSEEF_ADJ_TOOL); worklist Continue doesn't complete it | run the Step 7 DWINACTIV check (don't trust sbar); resolve the adjustment manually in SE19 or re-record the activate flow on 2022 (/sap-gui-probe) |
Delete refused … safety rule | target not created this session | intended — only override with explicit user confirmation |
Delete failed with locked-class message | implementing class is locked / used elsewhere | delete the class separately via /sap-se24 after releasing locks |
SE19 Component-ID Reference (probed S/4HANA 1909, SAP GUI 7.60, EN)
Initial screen SAPLSEXO (120): New-edit radG_IS_NEW_1 + ctxtG_ENHNAME;
New-create radG_IS_NEW_2 + ctxtG_ENHSPOTNAME; Classic-edit radG_IS_CLASSIC_1
ctxtRSEXSCRN-IMP_NAME; Classic-create radG_IS_CLASSIC_2 +
ctxtRSEXSCRN-EXIT_NAME. Buttons btnPUSHBUTTON_DISPLAY_TEXT,
btnPUSHBUTTON_CHANGE_TEXT, btnPUSHBUTTON_IMPLEMENT_TEXT; app-bar
tbar[1]/btn[14] Delete implementation.
New create chain: Enh-impl popup SAPLSEEF_BASE →
wnd[1]/usr/txtG_ENHSTRU-ENHNAME + -SHORTTEXT, Continue wnd[1]/tbar[0]/btn[0].
Object Directory SAPLSTRD(100) ctxtKO007-L_DEVCLASS (Save btn[0], Local
btn[7]); TR SAPLSTRD(300) ctxtKO008-TRKORR (Continue btn[0]). Create-BAdI
popup SAPLENH_BADI_POPUPS(1000) table
tblSAPLENH_BADI_POPUPSG_BADI_TABLE/{txtG_BADI-IMPL_NAME[0,0], txtG_BADI-CLASS_NAME[1,0], cmbG_BADI-BADI_NAME[2,0](.Key), txtG_BADI-BADI_SHORTTEXT[3,0]}.
Create-class popup SAPLENH_EDT_BADI(1000) Empty-Class wnd[1]/tbar[0]/btn[2].
New detail SAPLENHANCEMENT_EDITOR(6000): name txtENH_EDT_LAYOUT-OBJECT1,
status txtENH_EDT_LAYOUT-VERSION_TX; toolbar tbar[1]/btn[27] Activate,
btn[25] Display↔Change. Tab tabsTS_ENHANCEMENTS/tabpTABS_5 ("Enh.
Implementation Elements") → runtime flag
…/ssubENH_BADI_IMPL:SAPLENH_EDT_BADI:0102/chkENH_BADI_IMPL_ADMIN_DATA-ACTIVE.
Inactive-objects worklist Continue wnd[1]/tbar[0]/btn[0]. Delete confirm
SAPLSPO4(300) wnd[1]/tbar[0]/btn[0].
Classic detail SAPLSEXO(150): impl ctxtRSEXSCRN-IMP_NAME, status
txtRSEXSCRN-ACTIVE, short text txtRSEXSCRN-IMP_TEXT, definition
ctxtRSEXSCRN-EXIT_NAME; toolbar tbar[1]/btn[27] Activate, btn[28]
Deactivate (Ctrl+F4). Create-impl popup ctxtRSEXSCRN-IMP_NAME +
wnd[1]/tbar[0]/btn[0]. Save Yes/No SAPLSPO1(500)
wnd[1]/usr/btnBUTTON_1 (Yes). Delete confirm chain SAPLSPO1(500):
btnBUTTON_1 Yes (impl), then btnBUTTON_1/btnBUTTON_2 (delete class? Yes/No).
IDs were captured by /sap-gui-probe + /sap-gui-inspect. Re-record
with /sap-gui-probe --record if a different release renumbers a tree/menu node.
Classification tables (RFC, read-only)
| Table | Key / fields | Tells you |
|---|
SXS_ATTR | EXIT_NAME, MIG_BADI_NAME, MIG_ENHSPOTNAME | Classic definition exists; non-empty MIG_* ⇒ migrated (also a New spot) ⇒ AMBIGUOUS |
SXC_CLASS | IMP_NAME, INTER_NAME, IMP_CLASS | Classic implementation + its interface + class |
SXC_ATTR | IMP_NAME, ACTIVE, UNAME | Classic impl runtime-active flag + creator |
BADI_IMPL | BADI_NAME, ENHNAME, BADI_IMPL, CLASS_NAME | New impl ↔ definition ↔ enhancement-impl container ↔ class |
TADIR | OBJECT ∈ {ENHS spot, ENHO enh-impl, SXSD classic def, SXCI classic impl, CLAS}, AUTHOR, DEVCLASS | object directory + creator (safety guard) |
