SAP, MS Office, PDF, Web Automation & more

End-to-end process automation across every surface an enterprise runs on — from SAP transactions and Excel workbooks to email workflows and web portals.

Enterprise automation is not about one system — it is about connecting all of them. A single business process might read data from SAP, consolidate it across Excel workbooks, generate a PDF report, send it by email, and upload the result to a web portal — all in sequence, all without a human in the loop. Building that chain reliably is the real job.

Over 4+ years I have built and maintained production automation across every surface type that enterprises actually run on. This post covers the full platform stack in depth — SAP, MS Office, email, PDF, web, and specialist portals.

SAP is the operational backbone at ArcelorMittal — HR, finance, procurement, and logistics all live there. Automating SAP means navigating transaction codes, reading and writing field values, executing reports, and handling session state across long-running bot runs. I work with two distinct approaches depending on what access is available.

SAP GUI Scripting simulates user interaction at the GUI layer — opening transactions, filling fields, clicking buttons, reading output screens. It works across all SAP modules without requiring any special access beyond a normal user account. The tradeoff is fragility: screen layouts must be consistent, and session timeouts need explicit recovery logic.

PyRFC / BAPI calls bypass the GUI entirely and call SAP function modules directly via the Remote Function Call interface. This is significantly faster and more robust for high-volume data operations, but requires RFC access to be granted by SAP basis — which is not always available. Where it is, I prefer it strongly over GUI scripting.

Regardless of how modern an organisation’s core systems are, the business layer almost always runs on Excel, Word, and Outlook. Automating here means handling the full lifecycle of each format — reading, transforming, generating, and distributing — often across files that were built incrementally over years with no consistent structure.

Excel is the most common automation surface I encounter. I work with it at every level: pure Python libraries (openpyxl, xlrd, xlsxwriter) for headless processing, pandas for data transformation and consolidation, and win32com for cases where Excel formulas, pivot tables, or VBA-dependent formatting must be preserved. Multi-sheet workbooks with inconsistent column headers, merged cells, and embedded charts are routine production inputs — not edge cases.

Word document generation is a key output layer for HR and compliance workflows. I use python-docx to generate contracts, reports, and formal documents from structured templates — populating placeholders, inserting tables, and applying consistent formatting. For complex documents that require preserving native Word formatting, win32com drives Word directly.

Email is both a trigger and a delivery mechanism in many enterprise automation workflows. I work with email in both directions — monitoring inboxes for incoming requests that kick off a process, and dispatching structured output at the end of a pipeline to the right recipients with the right attachments.

Inbound email processing involves monitoring a shared mailbox, parsing subject lines and body content to classify the request type, extracting attachments for downstream processing, and routing the email to the appropriate workflow branch. At ArcelorMittal Luxembourg, incoming client inquiry emails triggered the entire AI offer generation pipeline — the bot read the email, retrieved matching historical orders, generated a personalised proposal via GPT-4o, and dispatched the reply automatically.

Outbound email dispatch is the final step of many pipelines — sending run summary reports to process owners, distributing generated PDF reports to stakeholders, alerting on exceptions, and delivering automated client responses. I use Microsoft Graph API as the primary email channel (OAuth2, no SMTP credentials required), with win32com Outlook automation as a fallback for on-premise environments.

PDF automation splits cleanly into two directions. Extraction means reading structured data out of existing documents — research reports, invoices, contracts, identity documents. Generation means producing formatted, submission-ready output from data — compliance reports, HR documents, run summaries.

Web automation covers authenticated internal portals, external data sources, and specialised industry systems. At ING, bots interacted with IRIS — a financial security monitoring portal — loading data, retrieving records, and generating output files for the KYC compliance pipeline. At ArcelorMittal, the compliance reporting workflow automated SARA and REX , two workplace safety portals used for collecting incident documentation — downloading records, uploading processed data, copying information between systems, and generating regulatory report files.

None of these portals expose a public API. All interaction is engineered through the browser layer using Selenium with explicit wait strategies, session management, and retry logic to handle the inevitable timeouts and page state changes that occur in long unattended runs.

For legacy Windows applications with no web layer and no API, I use UIAutomation (Windows accessibility tree) as the primary approach — robust to resolution and DPI changes — with PyAutoGUI as a last resort for applications that expose no accessibility interface. At ING, I built and delivered a GUI bot on SAIO, ING’s proprietary RPA platform, and ran training sessions to promote wider team adoption.