The deterministic agent-driven environment for SAP S/4HANA EWM.
Reads requirements. Executes. Verifies. Documents — live on the system.
Most SAP teams ship customising the way they did in 2010 — by hand, by ticket, by hope. SAPMatik keeps the same SAP standards but compresses the loop into a deterministic, audited agent.
Three specialists, six weeks, brittle handoffs
One agent, one session, one audit trail
Commercial leadership sees throughput. Basis sees auditability. Security sees controls. Same toolkit, three answers.
save_with_trEvery request flows through six phases. SAPMatik declares the current phase at every response, so the user always knows where in the process they are.
Extract actor, object, action, constraints. Ask blocking questions before anything else.
Split into atomic work-items mapped to UX, process, data, config layers.
Triangulate against indexed books, SAP Help, SAP Notes, live verification.
Roadmap card per item — owner, effort, sequence, tests defined first.
Drive the system. Each step wrapped in a tracked phase with sbar capture.
Re-extract changed tables, replay the process, log everything in the audit folder.
All wired through the same operator session. Modules compose freely under safe_run.phase() for full traceability.
SAP GUI driven via COM. Auto-handles popups + session death. Foreground-attached keystroke injection for the modern ABAP editor.
SE16N tab-delimited exports, multi-select probes, no silent truncation. Pre-check exactly once, post-check exactly once.
IMG navigation via cached node keys. Per-warehouse TR reuse. FK-aware copy across warehouses.
Any FUGR / PROG / FM / INCLUDE turns into a ready-to-deliver Word TDS document with embedded flow diagrams.
Stock upload + bin mass-create + sort. Verified live: 100 HU in 18.2 s, 10 bins + sort in 11.5 s.
Replay recordings, run YAML plans, auto-derive smoke tests. Pluggable patcher (default = grep hints, optional = LLM).
Indexed books (929 pp), full /SCWM/ + /LIME/ + /SCDL/ catalog (3.9 K CLAS, 1.6 K INTF, 4.5 K FM, 10 K TABL/VIEW), 35-plugin SAP marketplace, cumulative lessons-learned (25 patterns), per-warehouse state.
SAPMatik attaches to the operator's already-authenticated SAP GUI session via COM. No service account, no impersonation, no direct database access, no RFC backend.
password.KB/<area>/<run_id>/. Filesystem-local by default.Every number below comes from a real run on the development landscape. Reproducible from the audit folders in KB/STOCK_UPLOADS/, KB/BIN_UPLOADS/, KB/TESTS/.
Per-row throughput on /SCWM/ISU is ~0.18 s / HU. A 1000-HU upload should land near 3 minutes. Bins on /SCWM/SBUP run ~0.7 s / bin; 100 bins are expected in ~ 70 s plus sort. Single-bin floor cost is ~3 s no matter the volume.
Open the repository and run py automation/scripts/security_inventory.py — every number below regenerates from source.
Concrete situations a warehouse operations team faces every week, and how SAPMatik shrinks them.
YAML plan → offline validation → online master-data probes → /SCWM/ISU upload → NRIV + SLG1 post-check. Every record audited.
100 HU in 18.2 s liveRange expansion → storage-type existence check → bin collision check → /SCWM/SBUP + /SCWM/SBST → verified against /SCWM/LAGP.
10 bins + sort in 11.5 sOne command classifies a FUGR/PROG via TFDIR+TADIR, downloads all sources, regex-mines callgraphs, renders a SAP-grade Word TDS document.
Full FUGR ≈ 60 sTester catches a red sbar → debugger captures short-dump + ABAP context → patcher emits diff → syntax-check + activate → re-test until green.
Dry-run in < 10 sRecorded directly off the dev landscape. From command-line to a verified change on the SAP system.
A snapshot of where the code lives. The biggest share is data extraction + verification — because every claim SAPMatik makes is cross-checked against the live system.
Every claim below points to a control in the codebase that the reviewer can open and verify. Full pack: KB/SECURITY/ + SAPMatik_SECURITY_REVIEW.pdf.
password= / sapconn matches.save_with_tr.safe_run.phase() wraps every step with sbar + traceback + session-alive check.Blocked. SAPMatik runs as the operator. SAP kernel checks every authorization object. No service account, no SAP_ALL.
Blocked. No UPDATE/INSERT SQL in the codebase. All writes are tcode-driven and go through the same SAP authorisation flow as a manual click.
No SAP password, certificate, or token on disk. No vault to compromise. Operator's session is borrowed for the duration of the Python process.
Two gates. Syntax_check refuses to activate. Byte-compare refuses no-op diffs. In production the --apply path requires explicit --prod-confirm.
Zero outbound by default. The LLM patcher is the only egress path and ships disabled. Customer firewall whitelists api.anthropic.com only if activated.
The audit folder is created automatically by the toolkit. Skipping requires a code change, which lands in git history.
PII scoped to three narrow channels (operator's user-id, ABAP authoring metadata, BP refs in SAP error messages). No HR, no payroll, no banking. Retention defaults documented; right-to-be-forgotten path via cleanup.py --apply --delete.
All customising + ABAP changes preserve the standard TR + 4-eye chain. SOX evidence is identical to a manual SAP change (TR contents, release approver).
Default profile (LLM off) does no automated decision-making about people — out of high-risk scope. Enabling LLM for autonomous prod code changes triggers Annex III review.
Maps to A.8 (access control), A.9 (cryptography), A.12 (operations), A.16 (incident management), A.18 (compliance). Artefacts ready to plug into a customer ISMS.
No. It attaches to the operator's already-running SAP GUI session via the COM scripting API. There is no password, certificate, or SAML assertion on disk.
No. The COM scripting interface is bound to the session. Every action is checked against the user's role at the SAP kernel level. If the operator can't do X manually, SAPMatik can't either.
Two layers. SAP side: standard sbar, SLG1, STAD, TR contents. SAPMatik side: a per-run folder with input YAML, every captured sbar (JSON), screenshots on failure, before/after extracts, and RUN.json with the final verdict.
No, by default. The single exception is the optional LLM patcher (Anthropic). When off, no outbound HTTPS call is made.
Every write keeps a .bak next to the source. If activation failed, the SAP active version is still the previous one. If activation succeeded but the change is wrong, restore the .bak and push it via the same path.
Not on the default profile. With the LLM patcher enabled to autonomously change production code it becomes a candidate for Annex III classification.
Yes. SAPMatik preserves the standard TR + 4-eye chain, so the SOX evidence is identical to a manual SAP change.
Three horizons, each unlocks a new class of customer engagement.
LLM-driven bug-fix loop replaces the patcher stub. Auto-test plans derived from the analysis narrative. Same backbone, more autonomy. Infrastructure ready — switch on when paying customers arrive.
For bulk reads and writes that don't need a GUI screen, switch to PyRFC. Cuts wall-clock by 5–10× on extractions and mass loads. Same Python APIs, faster floor.
Extend the same architecture to MM, SD, PP. Compose stock + bins + customising + reverse-engineering into a single declarative go-live YAML — one document for an entire customer engagement.
No exotic dependencies. The stack uses what the SAP workstation already has, plus a thin Python orchestration layer.
Two tracks. Pick the one that matches your team's question — or open both.