Field Service and Technician Mobile App

The problem this solves

SAP Business One already has the service module: Service Calls, Service Contracts with their entitlement and response terms, Equipment Cards tracking serial numbers at customer sites, and the Item and Warehouse master behind every spare part. What it does not have is a technician in a van.

So the day runs on WhatsApp and paper. Dispatch is a phone call. The job card is a triplicate pad that arrives at the office three days later, if it arrives. Parts come off the van and get retro-fitted to a stock adjustment at month end, so van stock in B1 is fiction. The customer signs a page nobody can find when the invoice is disputed. Billing waits on the paperwork, then waits again while somebody works out whether the visit was covered by contract or chargeable — and when in doubt, it does not get billed at all.

The revenue leak is the real cost: unbilled labour, unbilled parts, warranty work billed as chargeable, chargeable work written off as warranty, and contract response times you cannot evidence when a customer challenges them.

What ECOSIRE builds

ECOSIRE builds a dispatcher console and a technician mobile app on top of your existing SAP Business One service data, connected through the Service Layer (REST) and the DI API. B1 stays the system of record — the app does not run a parallel service database. A job the technician closes on their phone becomes a completed B1 Service Call with consumed parts, captured time and a customer signature attached, ready to bill.

Dispatch and scheduling

The dispatcher works a board of open B1 Service Calls across a day or a week, assigning technicians by skill, territory and availability. Service Contract entitlement is read directly from B1, so the response and resolution clocks on the board are the contract's actual terms rather than a note in someone's head, and calls at risk of breach surface before they breach rather than after. Recurring preventive-maintenance visits can be generated from contract terms as scheduled Service Calls, so planned work competes for the same capacity as reactive work instead of being forgotten.

The technician mobile app

Technicians see their assigned calls with the customer's Business Partner record, the site address, the Equipment Card and its serial number, the full prior service history on that equipment, and any open contract. On site they progress the job through the statuses you define — travelling, on site, on hold awaiting parts, complete — with timestamps captured as they happen rather than reconstructed later.

The job card itself is a User-Defined Object (UDO) linked to the Service Call, so it is a first-class B1 document with numbering, an audit trail and a Crystal Reports layout you can hand to a customer. Technicians record fault codes, work performed, labour time, meter readings, and photos before and after. Checklists — safety, commissioning, statutory inspection — are configured per service type as User-Defined Tables (UDTs) so a job cannot be closed with a mandatory step unanswered.

Field work happens where signal does not. The app queues job progress, parts, photos and signatures locally when offline and synchronises when connectivity returns, with conflicts surfaced to the dispatcher rather than resolved silently.

Parts consumption and van stock

Each technician's van is modelled as a B1 Warehouse. A part consumed on a job is issued against the Service Call from that warehouse in the app, which means van stock in B1 reflects reality instead of a month-end guess, and replenishment can be driven from actual consumption. Serial and batch-managed items are captured properly at the point of use, so a serialised component fitted to a customer's equipment updates the Equipment Card rather than becoming an untraceable issue. Parts the technician does not carry are raised as a request the office can turn into a Purchase Order or a transfer.

Signature and completion

The customer signs on the device. The signature, the completion timestamp, the geolocation where you require it, and the finished job card render are attached against the Service Call in the B1 Attachments folder. The customer receives their copy by email from the same completion action, so proof of service exists before the technician leaves the car park.

Service billing

This is where the app pays for itself. On completion the app classifies every line — labour and each part — as contract-covered, warranty, or chargeable, using the Service Contract entitlement and warranty terms already in B1. Chargeable lines flow into a draft Sales Order or A/R Invoice against the customer's Business Partner, priced from your B1 price lists and any contract-specific pricing, ready for review and posting by the office. Nothing posts to a customer's account unattended: the billing document lands as a draft for a human to release, because a wrongly issued invoice costs more than a queue. Covered and warranty lines are recorded against the contract so consumption against entitlement is visible and contract profitability becomes measurable.

Reporting

Crystal Reports layouts and saved B1 queries cover technician utilisation, first-time-fix rate, response and resolution against contract terms, parts consumption by van and by equipment type, unbilled completed jobs, and contract profitability. Because it is all in your company database, it joins to the financial reporting your controller already runs.

Who this is for

SAP Business One 10.0 businesses that send people to customer sites: HVAC and refrigeration contractors, industrial and process equipment dealers with installed-base service obligations, medical and laboratory equipment service providers, lift and access-equipment maintainers, IT and security systems integrators, generator and power-equipment servicers, and facilities maintenance contractors. It suits teams from a handful of technicians upward, and it matters most where service contracts carry response commitments and where spare parts move through vans.

How delivery works

Built to order. There is no pre-built app to download, no free trial, and no pretence that a field service operation is generic.

1. Scoping call. We map your service process end to end: call intake, dispatch rules, technician statuses, what a job card must capture, your checklists per service type, how van stock works today, your contract and warranty entitlement structure, and exactly how a completed job should become a billing document. Your B1 version, database platform and the mobile devices in the field are confirmed here. 2. Fixed quote. A written scope covering the object model, the mobile screens, the offline behaviour, the billing rules and the reports, with a fixed price and a delivery date. 3. Build. ECOSIRE develops the console, the mobile app and the B1 integration against your database structure. Typical lead time is two to four weeks from a signed scope; a large checklist library, complex entitlement rules or several service types push it toward the upper end and the quote says so. 4. Install in test. Installed against your test company database. Real technicians run real jobs against it, including a deliberate offline job and at least one contract-covered, one warranty and one chargeable completion so you can verify the billing classification on your own data before it ever touches a customer invoice. 5. Install in production. After written sign-off, ECOSIRE installs into the production company database — the UDOs and UDTs, the van warehouses, the checklist configuration, the billing rules, the reports and the mobile distribution to your devices. 6. Support window. A defect-fix support window follows go-live, covering the first weeks of live dispatch, with a documented route for new service types, checklists and change requests afterwards.

Delivery is per-tenant. You get the source, the installer and the documentation for your build, so growing the technician count or adding a service line later does not mean starting again.