The problem
Customer and account data in a corporate SAP S/4HANA needs periodic mass corrections: a field to standardise on hundreds of accounts, a classification to re-assign, a batch of records to align with the CRM after a clean-up. Done by hand in the SAP GUI it is one transaction per record — slow, boring and, above all, a source of new errors while fixing old ones.
What I built
A small Python application that drives the SAP GUI through SAP GUI Scripting (the automation API that ships with the SAP client) and applies changes in bulk from an Excel file:
- Excel in, Excel out: colleagues fill a template (one row per record: key, field, new value); the tool reads it, executes it and writes the result next to each row.
- Dry-run first: every batch can be simulated — it navigates, reads the current value and reports what would change — before anything is saved.
- Per-row validation against the value the GUI shows, so a stale spreadsheet never overwrites a newer change blindly.
- Change log with before/after values, user and timestamp, so any batch can be audited or reverted.
- Plain error messages (“record locked by another user”, “value not allowed for this field”) instead of a stack trace, because the users are not developers.
It is used by my own team and by other departments that needed the same kind of mass update; each department gets its own template.
Why this approach
We had no access to LSMW, BAPIs or a mass-maintenance transaction for these objects, an RPA licence was out of scope, and the usual VBS macros recorded from the GUI break the moment a screen changes. Python on top of the scripting API keeps the logic readable and testable, and the same code runs a dry-run and the real batch.
What I learned
Automation without validation just makes mistakes faster: the dry-run and the row-by-row checks matter more than the clicking. And a change you cannot undo should not be automated — the log was designed before the first real batch.
Built as part of my job and owned by my employer. This page describes the approach only: no code, screenshots, data or internal details are published.