Channel 1
ReadDirect database access
Lookups, searches, reports and dashboards go through direct access to your SQL Server database. Screens stay instant even on large databases, with no limit on how far back you look.
Architecture
The question that decides whether a Sage integration succeeds is not “does it connect”. It is “what writes, and how”. OptiFlowPro keeps the two strictly apart.
Channel 1
ReadLookups, searches, reports and dashboards go through direct access to your SQL Server database. Screens stay instant even on large databases, with no limit on how far back you look.
Channel 2
WriteEvery document creation or change goes through a service that talks to Sage via its own components. The resulting document is identical to one keyed in Sage: same checks, same counters, same postings.
The Sage data model carries business rules that are not all expressed in the database schema: counters, header-to-line consistency, analytical postings, document chaining. A direct write that ignores one of them produces a database that is consistent for SQL Server and inconsistent for Sage. The symptom appears only weeks later, often at period close. That is why all of our writes go through the web service.
Sage remains your system of record. OptiFlowPro is an operations layer on top of it, not a second ERP to reconcile.
An installation with several companies means several Sage databases. OptiFlowPro handles them from a single application, keeping each company's data strictly separate.
Each company has its own users, permissions and data. A user in one company sees nothing of the others.
The Sage databases covered are declared by name. A database that is not declared stays invisible to the application.
Management functions can aggregate several companies for the profiles authorised to see them.
Version, modules in place, customisations, data volume: the audit answers those questions before the first line of code is written.