Use your ERP with the GMAO Cloud mobile app

There’s a scene that repeats itself in almost every company that does maintenance: someone in the office, with the paper job sheet in front of them, typing into the ERP what a technician already wrote down that morning. The hours, the material, the customer, the reference. It’s work that adds nothing, introduces errors, and delays the invoice by several days.

The goal of connecting the mobile app to the ERP is to eliminate that scene. It’s not a complicated technology project; what’s complicated is what comes before it, which is deciding which system owns which piece of data.

First: who owns what

An integration that just copies records from one side to the other ends up creating more work than it saves. Duplicate customers show up, items don’t match, and you end up making manual corrections in both systems.

The rule that avoids almost all of those problems is simple to state, and it needs to be agreed before a single line of code is written: the ERP owns customers, items and pricing; the CMMS owns assets, interventions and consumption.

It makes sense if you think about where each thing is created. A new customer is born in the sales process, not in maintenance. A spare part consumption is born when a technician opens the box, not when someone invoices it. With that boundary clear, integration becomes a technical matter. Without it, it’s a permanent source of arguments.

What the technician records on mobile

What’s going to travel to the ERP is generated in the field. In the technician app, right on the work order itself, the technician starts and stops the stopwatch, consumes material from the warehouse with its batch, fills in the equipment’s checklist, attaches photos and collects the customer’s signature on the screen.

Two details matter for integration.

The first is that this works without coverage. Orders, assets and documents are stored on the device itself, and every action goes into a queue that empties out when signal comes back. If something fails to sync it doesn’t silently disappear: it stays flagged with the reason. This matters because maintenance happens in basements, warehouses and plant rooms, and an app that requires a connection records nothing precisely where most of the work happens.

The second is that the times are measured, not remembered. The difference shows up on the invoice: hours jotted down from memory at the end of the day are always fewer than the real ones.

The connectors that exist

GMAO Cloud has connectors in production — running on real installations, not just on a list of intentions — with several systems:

• Microsoft Dynamics 365 Business Central and Navision, including the SOAP variants and OAuth2 authentication, and a mode with multiple endpoints for groups with more than one entity.
• SAP, with work order export for the invoicing and cost circuit.
• Sage X3, which imports customers, addresses and items.
• Holded, Factura Directa and QuickBooks, the usual options when accounting is in the cloud.
• STEL Order, with its own connector.
• Libra, Golden, Progein and Freematica, niche systems widely used in specific sectors.
• Sage 200c, with direct database connections in several modes, including one built for group structures.

It’s worth checking the scope of each one and not assuming anything: not all of them do the same thing in both directions. Sage X3 is the clear example, because it imports masters but doesn’t export work orders. The detail is on the integrations page.

And if your system isn’t on the list

That’s the most common case, because management software is very fragmented and many companies work with custom-built systems developed years ago.

That’s what the public REST API is for, which is the normal path for a new integration and lets you read from and write to the CMMS from your own development. There’s also SOAP connectivity, direct SQL access and CSV/FTP exchange, which are still how many legacy systems communicate and solve more cases than it seems.

There’s also a connector between GMAO Cloud installations, designed for when both the customer and their maintenance company use the system: jobs move from one side to the other without going through an intermediate file.

What you don’t need to change

The question usually lurking behind all of this is whether connecting the CMMS forces you to touch the ERP. Usually not. The idea is actually the opposite: keep the ERP that already works — with its accounting, its invoicing and the people who already know how to use it — and add on top of it the part ERPs typically lack, which is fieldwork: the offline mobile app, per-equipment history, checklists, documentation with expiry alerts and customer access.

Migrating ERPs is an expensive project with a long learning curve. Connecting two systems that each already do their own part well isn’t.

What you can still do from the ERP

A reasonable concern when the ERP has been running for years is whether the office team will have to switch tools. Not necessarily.

The API lets management keep happening where it already happens for whoever is used to that system — creating the customer, creating the request, checking the status — while the technical work happens in the CMMS and on mobile. What changes location is where the work gets recorded, not necessarily the workstation from which it’s managed.

Where the ERP falls short is where the CMMS comes in, and it’s usually the same things: the QR code stuck on the equipment, compatible spare parts for each component, documentation with expiry alerts, per-asset intervention history, and customer access to their own job reports. These aren’t features missing from the ERP by oversight: they simply aren’t its subject matter.

Three questions before you start

What data has to travel, and in which direction? Usually it means bringing in customers and items from the ERP and sending closed orders with their hours and consumption the other way. Trying to sync everything both ways is the fastest way to complicate the project.

At what frequency? Real time is almost never necessary. Having closed orders reach the ERP every night is usually enough, and it’s much cheaper to maintain.

Who resolves conflicts? There will be a customer that exists twice and an item with no code. It’s worth deciding beforehand who looks at that and by what criteria.

If you’d like us to look at your specific case, tell us what ERP you work with via the contact page or request a demo.