Field service in SAP Business One: what the standard Service module does, and where an app for the technician comes in

What is in the standard Service module.

• Service calls: the ticket. Customer, contact, address, the equipment it is about, problem type, priority, status, a queue or an assigned technician, and a resolution text.
• Service contracts with templates: what is covered, response times, and the link to recurring invoices.
• Customer equipment cards: every serial number you sold or maintain, with its history of calls.
• Scheduling lines on the call: a planned visit with a technician, a start and an end. Since B1 10 those lines also have check-in and check-out with time and GPS, and a field for who signed.
• Activities in the B1 calendar: phone notes, tasks, follow-ups.
• The Technician role on the employee master, and a warehouse per van, with a transfer to and from the technician.
• A knowledge base of solutions, linked to problem types.
• SAP's own mobile Service app for technicians, and service screens in the Web Client.

That is a solid record of what happened. It is the planning and the day on the road where it thins out.

What it lacks.

• A planning board. There is no timeline per technician, no drag and drop, no map. The calendar's group view shows at most seven people side by side.
• Automatic planning. No route planning, no matching of skills to jobs, no capacity check. Whether a technician can still make it today is something the planner works out by hand.
• Skills and certificates. The employee master has no field for them, so a job that needs a certified technician cannot be matched to one.
• Planned maintenance. It does not exist. A contract can trigger recurring invoices, not recurring visits. Contract renewal is a reminder, not an action.
• Checklists. No inspection forms, no required questions, no "measured value out of range, create a follow-up".
• A signed work order to the customer. There is a print layout for paper. The signature itself cannot be read back through the Service Layer, so an add-on has to store it as an attachment.
• Mobile work. The SAP Service app covers the basics and little more; working offline is not part of it.
• The link between a technician and a van. There is a warehouse per van, but no field on the employee that says which one is theirs.
• Customer communication and dashboards. No "your technician is on the way", no first-time-fix rate, no SLA overview.

Three ways companies fill the gap.

1. A spreadsheet, a whiteboard and paper. Where most small service companies are today. The calls are in B1, the planning is on the wall, the technician gets the job by phone, writes what was done on a slip, and someone in the office types it in the evening. It works until the fourth van, and it never scales.

2. A full field service suite next to B1. Its own planning, its own customer and equipment data, its own app, and an integration that keeps the two in sync. Powerful, and right for a company with thirty technicians and a planning department. The price per technician and the months of implementation are the reason smaller companies stay at option 1.

3. An add-on that keeps the B1 service call as the single record. The call stays the call, the scheduling lines stay the scheduling lines, and the add-on only adds what is missing: a board for the planner and an app for the technician, both writing back to the same call. No second administration to keep in sync, and nothing to migrate if you ever stop using it.

What to check before you choose.

• Where does the visit live? On the standard scheduling line of the B1 call, or in the tool's own table? The first keeps your reports and history in B1; the second builds a second truth.
• Can the planner stay in B1? A board that opens from the service call, and a call that opens from the board, saves a planner from living in two systems.
• One B1 user per technician. Every technician works under their own named user, never a shared one: it is what SAP's licence terms ask and what keeps the audit trail honest. What that costs per technician is in the licence guide.
• What leaves the building. A map and travel times mean addresses go to a maps provider. Everything else can stay on your own server. Ask.
• Materials. What happens with the parts from the van: a note on the call, a delivery, a sales order? Decide this before the pilot, because it decides how invoicing works.
• No signal. A cellar with a boiler has none. Does the app queue what the technician does and send it later, or does it stop?

How KFSM approaches it.

KFSM is our option 3. The service call, the scheduling lines, contracts, equipment and attachments stay the standard B1 objects; KFSM adds a handful of its own fields and tables, all with its own prefix, through an installer. The planning board opens inside the B1 client, the Android app gives the technician the day, a GPS check-in, checklists that create a follow-up call on a deviation, photos, materials from the van warehouse, a signature and a work order PDF, all written back to the call through the Service Layer. It is in development: built and tested against a simulated B1, not yet at a customer, with no price and no date. The product page says exactly where it stands.