SAP BTP platform for vehicle repair and insurance claims

Description

The cloud platform of an Italian company specialised in repairing hail damage on vehicle fleets using PDR (paintless dent repair) and in handling the related insurance claims. It covers the full cycle: opening a repair campaign, registering vehicles by VIN, assigning operations to technicians with times and prices, warehouses and transport, claim handling with documents and estimates, through to invoicing into SAP ERP. It consists of a Node.js backend built with the SAP Cloud Application Programming Model (CAP) on SAP HANA Cloud and 22 SAPUI5 applications grouped into a single launchpad. I built the first feasibility mock for the client and, once the project started, became its team lead: I guided three developers for the whole engagement — roughly one year and two months — assigning the work, coordinating with the delivery manager and running the requirement calls with the client myself.

The problem

The company worked with a previous application outside the SAP landscape: data collected in the field stayed there and never reached the group's ERP. Different people act on the same vehicle — technicians repairing it on site, supervisors checking progress, back office issuing invoices — and each of them saw only their own slice. Vehicle data moved around as Excel files, insurance claims lived outside the company systems, and whoever prepared the invoices had to reconstruct by hand what had been done, on which vehicle and by whom. There was no traceable path between the work done in the field and the accounting document issued in SAP.

Constraints

The platform had to fit between systems already in production: the group's SAP ERP, the WinCar body-shop estimating system and a pre-existing integration flow, all reachable only through SAP BTP destination and connectivity services. Functional requirements changed when the platform was already built and already populated with data from the field trials: entities and fields explicitly marked as superseded after requirement changes are still visible in the code. Releases had to stay manageable across three landscapes (development, test, production) from a single codebase. The work was spread across four developers on the same monorepo: without shared conventions on data model, services and naming, 22 applications would have become 22 different dialects.

Architecture

Multi-Target Application (MTA) monorepo on SAP BTP, Cloud Foundry runtime.

Backend: SAP Cloud Application Programming Model (CAP) for Node.js (@sap/cds 9): one OData V4 catalog exposing more than 80 entities, plus six application services with custom JavaScript logic (operations, invoicing, reporting, master data, external estimates).
Data: SAP HANA Cloud in an HDI container, ~90 CDS entities, hand-written .hdbview views for aggregations, HDI synonyms and roles for consumption from SAP Datasphere.
Frontend: 22 freestyle SAPUI5 applications (~39,000 lines of controller code, 103 XML views, 74 fragments) on html5-apps-repo, grouped into one launchpad with cross-navigation. The technicians' application runs on SAP Build Work Zone and is built for use on site: pick the campaign, type the VIN, get to work.

 SAPUI5 (22 apps, launchpad)     technician app (SAP Build Work Zone)
              \                     /
               managed approuter (XSUAA)
                        |
                 CAP OData V4 (Node.js)
                        |
        +---------------+----------------+
        v                                v
  SAP HANA Cloud (HDI)          BTP destinations
  ~90 CDS entities                      |
  .hdbview views            +-----------+-----------+
        |                   v           v           v
        v              SAP ERP      WinCar     iFlow / SMTP
  SAP Datasphere      (invoicing)  (estimates)  Google Drive API
  (reporting)

The operations model is the heart of the system. A campaign is created with its supervisors and the list of authorised users: nobody else sees that data. Vehicles are loaded from an XLS or CSV list of VINs; the work items come from a catalog the client configures on its own. From there, three rules apply:

enforced sequence: an operation only opens if the preceding one is closed, and a technician who tries gets a clear message rather than a generic error;
per-operation permissions: each user sees the work items they are authorised for, so the system offers the first operation available to them on that vehicle, not the first available overall;
random assignment in the PDR stage: the vehicle is drawn from those ready for that operation, never chosen.

Every step leaves a trace: which operation, on which VIN, by whom, when, with what outcome. That is where the per-vehicle history, the handling of blocked vehicles and the reporting aggregates come from.

Outcome

What was delivered#

Both halves of the programme were built: PDR repair — campaigns, vehicles, work items, the site itself — and insurance claim handling, with estimates pulled from WinCar and stored alongside the vehicle. Technicians, supervisors and back office work on the same data model and the same launchpad, inside the SAP landscape instead of the external application they used before. Every technical work item carries its invoice code, SAP order number, the payload that was sent and any error returned: an invoicing issue is reconstructed from the data, not from email threads. HANA views exposed to SAP Datasphere opened reporting beyond the application's own boundary.

Tested in the field#

The platform was trialled twice with real operators, not in a lab. First on a repair campaign followed for two to three weeks. Then on site: operators used the application for about a week, and for three of those days we were physically there, watching them work and collecting feedback straight from them rather than through a written report. For an application used with gloves on, next to a vehicle waiting to be repaired, that is the only serious way to find out whether it works.

A rule that comes from the shop floor, not from a technical requirement#

In the PDR stage the vehicle is not chosen: the system draws it from those ready for that operation. This is not an implementation detail. At the same rate it pays to work the least damaged vehicles, and leaving the choice to the operators created friction; the client explicitly asked that nobody could pick their own work. The same idea of impartiality underpins the enforced operation sequence and the per-user permissions: the system decides what can be done now, and explains why.

My role#

The first mock — the one that showed the client what could be done — was mine. When the project started I became its team lead and stayed to the end, roughly one year and two months: three developers to coordinate, work to assign, technical conventions to hold together across a monorepo that grew to 22 applications, and the requirement calls with the client run in person.

How it ended#

The client suspended the programme for internal priorities, before the rollout to the full user base: the platform was sized for around a thousand users between operators and supervisors, with campaigns reaching a few thousand vehicles each. At suspension the MTA descriptor was at version 2.0.58 — an incremental release every few days for more than a year.