What kind of Delphi ERP does JBKR support?
A complete ERP for a telecom services company, built by another software house from 2010 onwards and supported by JBKR since 2022: about 1,300 Object Pascal units, 500,000 lines, 56 runtime packages and 20 executables. The modules cover finance, tax documents (NF-e, NFS-e, NFC-e, CT-e), SPED, payroll and HR, inventory, purchasing, sales, contracts, work orders, point of sale and the telecom field operation. The database is Microsoft SQL Server; the interface is VCL with DevExpress and FastReport reports; the tax layer uses ACBr.
What keeps a system like this in production is not the age of the code but the method of whoever supports it. Without the original author and without documentation, the first step was recovering technical control (code, packages, certificates, database, scheduled jobs) and documenting what exists, with AI support and human review. From then on every change follows the same script: homologation, reversible package, written record.
How does tax-reform compliance work inside the ERP?
The Brazilian tax reform (IBS and CBS, Complementary Law 214/2025) changes the layout of the tax documents the ERP issues every day. In 2026 JBKR adapted the three documents of the supported ERP (NF-e, NFS-e in the national standard and the point-of-sale NFC-e) to the new tax groups, with a shared calculation and filling module and a homologation mode that allows issuing in a test environment before switching on in production.
The order matters: first the database (new fields and tables, through a tested migration), then the calculation module, then each document, each one validated against the SEFAZ or national-portal homologation environment. The integrations and government compliance page details the NT 2025.002 and split-payment calendar; the point here is that all of this happens inside Delphi, without replacing the system.
How do you change the SQL Server database without breaking operations?
Every structure or data change becomes an idempotent SQL script: it can run more than once without side effects, checks what already exists before creating or altering anything, and records what it did. Each script has a homologation mode, which allows running the change on a copy of the production database and checking totals, documents and master data before any cutover.
The practical result is that the database migration stops being the tense moment of a deployment. It has been rehearsed, the numbers matched and the rollback is written. If a data load has to be undone, such as a price list imported from the wrong spreadsheet, there is a rollback script generated together with the load script.
What does a risk-free desktop ERP deployment look like?
A Delphi ERP distributed across dozens of packages and executables, installed on Windows workstations, does not tolerate copy and paste. JBKR's deployment package backs up everything it is about to replace (packages, main executable, tax schemas), applies the swap in the right order, updates the database with the already homologated migrations and leaves a README with what changed, why and how to go back.
The deployment happens outside issuing hours, with a reference workstation validated before the others and the rollback path ready. Over four years of support, that discipline is what makes it possible to deliver tax changes with a date set by law without stopping the client's invoicing.
And the everyday data loads (price lists, master data)?
A good part of ERP support is not code: it is data. A new price list with hundreds of items and thousands of prices per state arrives in a spreadsheet and has to enter the database without errors. JBKR builds load tools that turn the spreadsheet into SQL and generate three scripts: simulate (shows what will change), verify (checks the result) and undo (returns to the previous state).
That takes data loads out of improvisation and puts them under the same method as migrations: rehearsed, checked, reversible. It applies to prices, customer and supplier records, charts of accounts and any recurring import.
COBOL routines on a mainframe: support, documentation and integration
Since 2020 JBKR has supported the COBOL routines of a large client (sector undisclosed) on an IBM mainframe: z/OS, CICS and DB2. The work is classic support (fixes, small evolutions, monitoring of batch and online routines) plus what is usually missing in those environments: readable documentation of the routines, generated with AI support and reviewed by someone who understands the program, and integration with new systems through services and files.
The experience comes from the inside: the founder started his career with two years on the IBM mainframe at HSBC (z/OS, COBOL, JCL, CICS, DB2, Endevor). For large mainframe projects JBKR brings in specialists on demand under the founder's technical coordination. What we do not do is promise to "migrate the COBOL" in one project: the responsible path is to document, integrate and replace in parts, when it pays off.
Can it be modernized without leaving Delphi?
Yes, and that is the path JBKR recommends for most Delphi ERPs. The supported system already has an HTTP API service, running as a Windows service, that exposes the Delphi business logic (bank slips, NFS-e, queries) to other systems. That service is the seam of the modernization: a new module, whether web, mobile or an integration, talks to the ERP through the API and Delphi stays in charge of the rules and the data.
JBKR has not migrated this ERP away from Delphi, and says so: the modernization roadmap states in writing which modules are worth rewriting (remote access, a customer portal, integrations) and which should stay where they are. The Legate case from 2024 follows the same logic: the integration with the national NFS-e was rebuilt inside the Delphi monolith, with zero days of invoicing stopped. The legacy modernization page describes the general assessment and roadmap method.
How much does supporting a Delphi or COBOL ERP cost?
An ERP with daily tax-document issuance usually goes on a monthly plan, Care from BRL 1,125/month (5 hours) or Expert from BRL 2,050/month (10 hours, 24/7 service), with a 1-hour minimum per request and additional hours at BRL 300. One-off demands, such as an assessment or an isolated tax-compliance change, use the On-Demand plan, from BRL 250/hour with an estimate before the work starts.
The SLA is published: same-business-day reply and work on critical failures started within 24 hours on monthly plans. The proposal is always in writing, with the system inventory as the starting point. The initial 30-minute assessment is free.
Frequently asked questions
What is Delphi ERP support?
Keeping a desktop ERP written in Delphi running, updated and compliant without rewriting it: bug fixes, tax compliance (NF-e, NFS-e, NFC-e, SPED, IBS/CBS), database changes through tested migrations, reversible deployments to workstations and module-by-module evolution. JBKR has done this since 2022 on an ERP of about 500,000 lines, with a published SLA.
Do you take over an ERP built by another software house?
Yes, including without documentation and without contact with the original author. The Delphi ERP JBKR supports today was built by another company from 2010 onwards. The work starts by recovering technical control (code, packages, database, certificates), documenting what exists with AI support and human review, and only then changing anything.
Does the ERP have to leave Delphi to comply with IBS and CBS?
No. In 2026 JBKR adapted NF-e, national NFS-e and NFC-e to IBS/CBS inside the Delphi ERP itself, with a homologation mode to test before the cutover. The tax reform is a reason to support the system with method, not to replace it in a hurry.
How is a database migration tested before production?
Every SQL migration is written so it can run more than once without side effects (idempotent), has a homologation mode and is rehearsed on a copy of the production database. Only after the results are checked (totals, documents, master data) does it go into the deployment package, together with the rollback script.
Can a deployment be rolled back?
Yes. The deployment package backs up what it is about to replace (packages, executable, tax schemas), applies the swap and leaves the rollback path documented in a README. In an ERP with dozens of packages and executables, deploying without a ready rollback is the biggest avoidable risk.
Do you support a point of sale with NFC-e and card payments?
Yes. The supported ERP includes a point of sale with NFC-e issuance, card payments through TEF and synchronisation with the central database. Tax changes for the POS go into the same deployment package as the ERP, tested in homologation.
How do you handle COBOL routines on a mainframe?
Since 2020 JBKR has supported the COBOL routines of a large client (sector undisclosed) on an IBM mainframe (z/OS, CICS, DB2): fixes, small evolutions, documentation of the routines with AI support reviewed by a human, and integration with new systems through services and files. The founder started his career on the HSBC mainframe; larger projects bring in specialists on demand.
When is it worth rewriting a module outside Delphi?
When the module blocks the business and Delphi is the cause: remote access, an integration that needs a modern API, a web interface for people outside the company network. In those cases the new module coexists with the ERP, reading the same data, and Delphi stays in charge of the rest. The roadmap says in writing what pays off and what does not.
How much does Delphi or COBOL ERP support cost?
It depends on the size of the system, the volume of tax changes and the SLA required. An ERP with daily tax-document issuance usually goes on a monthly plan, with hours reserved for compliance work and fixes. One-off work uses the On-Demand plan (from BRL 250/hour, estimate before the work starts); continuous evolution and support use the monthly plans: Care from BRL 1,125/month and Expert from BRL 2,050/month. Every proposal is written and itemized.
