Frota de Robôs — Operação Autônoma do ERP
15 robots in production that operate the ERP on their own — tax, receivables, legal and infrastructure.
- autonomous robots in production
- 15
- courts monitored daily
- 91
- operational fronts covered
- 4
From pain to result
Before
Critical routines depended on someone remembering to run them — and failed silently when that person was out.
Dozens of critical routines depended on someone remembering to run them: approving payment processes, importing invoice XMLs, checking court publications, chasing suppliers. Each one consumed hours a day — and failed silently whenever that person was away.
Worse: every new automation started from scratch. The same ERP authentication, the same error handling, the same email report, rewritten every time.
How · 1/4
I built a fleet of 15 Python robots across four fronts: tax/finance, receivables, legal and infrastructure. Each runs on a schedule — from continuous daemons to fixed-time daily jobs — with an audit log and an automatic email report.
How · 2/4
I standardised what repeats across them: ERP API authentication with token renewal, hash-based deduplication, idempotent upserts, PDF generation and notification. A new robot inherits that base instead of reinventing it.
How · 3/4
The infrastructure robots watch the others: they audit active SQL Server sessions and verify that the replica restore — which every pipeline depends on — is still running.
How · 4/4
Since August 2026, part of the fleet — replica watching, database auditing and process approvals — runs inside Pandora, which gave those robots persistent state and auditable runs. They are still the same 15; what changed is who orchestrates them.
After
15 robots across four fronts — tax, collections, legal and infrastructure — approve, import, monitor and report every day, with no one in the loop.
- 15
- autonomous robots in production
- 91
- courts monitored daily
- 4
- operational fronts covered
Reading the diagram
Four source families feed the same fleet. Some robots act straight against the ERP API — they read the replica to know what to do and execute; others persist first, with hash-based deduplication, and that is where briefs and alerts come from. Drawing a single database is a simplification: each robot has its own.
Technical highlights
- 1 The court-monitoring robot grew into a platform of its own — multi-client, with a dashboard, an API and 91 courts read every night. Its story is in the Court Monitor case.
- 2 An audit daemon that captures active database sessions and queries every 60 seconds and deduplicates by a SHA-256 hash computed only over the stable fields: CPU and I/O are excluded, otherwise the same in-flight query would register as a new event on every sweep.
- 3 Tax robots that reconcile invoices against payment processes, import NF-e and CT-e XMLs into the ERP and keep provisioning status correct per document type.
- 4 Escalating supplier collection and pending-item notices through the ERP’s own internal mail — the automation speaks the language of the system the team already opens every day.