Connecting a field application to a Sage 100 running on the company's own server

The context

A French SME distributing industrial supplies had built a field application for its sales team with Lovable: visit planning, quotes, tracking of sales, stock and payments, prospects, travel expenses, product catalogue.

The application works and fits the job of the people using it. But it lives in isolation. The items, the customers and the sales documents are in Sage 100, and nothing moves between the two. It had been designed from frozen Excel exports: to bring it up to date, someone had to redo the export, then import it back into the Lovable project.

The challenge

Linking an AI-generated application to an ERP sitting on a server inside the company’s own offices. This is exactly where Lovable reaches its limit, for four reasons.

The application has no server of its own

What Lovable produces is a so-called single-page application: all the code runs in the salesperson’s browser. There is no program of ours, running on a server, able to go and talk to another piece of software.

An ERP installed on an internal server does not talk to a browser. Something has to sit between the two, a program that fetches the data on one side and drops it on the other. That link is missing, and no generation tool produces it.

The ERP had no way in

Sage 100 was running on a Windows server belonging to the company, on its premises rather than at a hosting provider. The web services modules, the ones that let another piece of software query it through the official route, were not installed.

One way in remained: a direct read-only connection to the database, over ODBC. It was only possible because the IT provider running the server worked with us.

Writing into Sage is not the mirror image of reading

Sage applies a strict schema. One missing field and the whole document is rejected. Writing straight into the database, without going through the accesses meant for it, would bypass its own consistency checks, with serious accounting consequences.

Two jobs on entirely different scales

The client is not technical and was comparing the speed at which a Lovable interface comes together with the job of wiring up an ERP. The comparison is a natural one: they had their application within a few weeks for a few tens of euros. We had to explain why the second job has nothing to do with the first, and scope it before committing.

What we did

• Tight scoping before any commitment. Given the context, feasibility had to be established before pricing: the exact Sage version, how it was hosted, whether server access was possible at all, the volumes involved. Those answers come from the IT provider, not from the client. The scope was written and approved, and the prerequisites on the client’s side listed, before the first line of code.
• A synchronisation agent installed on the client’s server. A light service that reads the Sage database locally: items, customers, sales document lines. It filters and prepares that data, because Sage stores it for its own purposes rather than to be read as it stands. It then pushes it to the application’s database, overnight and at midday. That is the rhythm the client asked for; a shorter interval was possible.
• Logs you can look at. The agent writes down what it did. The application knows the state of the last synchronisation and can raise a flag when a discrepancy appears. A synchronisation that falls over must not go unnoticed.
• Read-only as a principle. Quotes are entered in the application, then keyed into Sage. We will not write into an ERP’s database without going through the accesses meant for it: the risk is out of proportion with the time saved. We set the situation out for the client, who understood and approved it. The topic stays open: part of the code is already prepared to carry quotes across the day the web services module is installed on their Sage instance.
• A written report on what fell outside the scope. Inspecting the code, we found problems that were not part of our engagement: credentials and email addresses hard-coded, frozen lists, and above all an application published on the web with no authentication at all. Anyone could open the interface and read internal data, with no accounts, no roles and no access rights. We documented it and sent it in writing, which let the client deal with it.

The outcome

The application now works with the ERP’s data, with no manual import. The client keeps their tool and their ERP, and the engagement continues: new requests are handled as they come, with a written scope each time.

What this case shows

• A generation tool puts an interface together quickly. Connecting the real world, an ERP, an internal server, a business schema, calls for engineering and scoping work.
• A Lovable application has no server of its own. As soon as two pieces of software have to talk to each other with nobody in front of a screen, that intermediary has to be built.
• A written scope protects the client as much as the supplier.
• Building a tool without technical knowledge can expose a company’s data. Having what you produce checked is neither optional nor a luxury.