Contents
1Background & Goal
The Equipment Domain at Palfinger is the central database for the complete lifecycle of a device — from production through sale and warranty to service and decommissioning.
Project Goal:
Partners performing services and end customers of the equipment should receive complete information about service status and be able to directly plan follow-up actions (e.g. scheduling appointments).
Affected Systems
- Equipment Screen – Dashboard Widget
- Service Cockpit – Assigned Equipments Filter
- Equipment GraphQL API
- Telematics Integration
- Notification System (Partner + End Customer)
Affected Roles
- Palfinger Internal (Equipment Manager)
- Partner / Service Provider
- End Customer
- System (Telematics Auto-Trigger)
2Current State
Current Data Model (simplified)
Code anzeigen / Show code
// GraphQL: equipment.expected_service_date // Store: TimeToServiceState interface TimeToServiceState { isLoading: boolean; hasError: boolean; expectedServiceDate: Date | null; // single date field }
Date Population Sources (current)
| # | Source | When? | Metadata stored? |
|---|---|---|---|
| 1 | Telematics Auto | Equipment activation (Warranty + 1 year) | No |
| 2 | Manual (User) | On change in widget | Partial (date of change) |
| 3 | Smart Process – Service | After service completion | Partial (date of change) |
No audit trail: It is not possible to determine where a date comes from or who last changed it. The "Telematics Auto" source leaves no trace.
3Problems & Gaps
Missing Date Types
- No "Last Service Date"
- No separate "Manually Set Date"
- No agreed customer appointment
- No distinction: calculated vs. manual
Missing Telematics Display
- Operating hours until service are received but not displayed
- Reset to 0 after service → no notification
- No link between hours and date
Missing Audit Trail
- No
changedBy - No
changedAt - No
source(telematic / manual / smart_process)
No Filter Functionality
- Service Cockpit: no date range filter for Service Date
- No filter for Statutory Inspection Date
4New Data Model
4.1 Service Date – Extended Model
Code anzeigen / Show code
interface ServiceDateData { // ── Core Dates ───────────────────────────────────────────── lastServiceDate: Date | null; // When was the last service performed expectedServiceDate: Date | null; // Auto-calculated (e.g. lastService + interval) manualServiceDate: Date | null; // Manually set by user / Smart Process customerAppointment: CustomerAppointment | null; // ── Audit Trail ──────────────────────────────────────────── dateSource: 'telematic' | 'manual' | 'smart_process' | null; lastChangedBy: string | null; // User name or "System" lastChangedAt: Date | null; // ── Telematics (optional) ────────────────────────────────── isTelematic: boolean; remainingOperatingHours: number | null; // remaining hours until service operatingHourThreshold: number | null; // threshold (e.g. 1000 hrs) currentOperatingHours: number | null; // current operating hours } interface CustomerAppointment { date: Date; time: string | null; // e.g. "14:30" confirmedBy: string | null; }
4.2 Priority Logic: Which date is displayed?
| Priority | Date | Badge | Condition |
|---|---|---|---|
| 1 (highest) | manualServiceDate | Manual | If present |
| 2 | expectedServiceDate | Calculated | Fallback if no manual date |
| 3 | (no date) | Not set | Neither manual nor calculated available |
4.3 Naming: "Legal Inspection Date"
Recommendation:
Statutory Inspection Date
Internationally understood, legally precise and unambiguously translatable in all languages. Replaces "Legal Inspection Date" uniformly everywhere.
Naming-Kandidaten anzeigen / Show naming candidates
| Candidate | Pro | Con |
|---|---|---|
| Statutory Inspection Date ✅ | International, legally precise | Slightly formal |
| Legal Inspection Date | Already in codebase | "Legal" is ambiguous (≠ lawful) |
| Mandatory Inspection Date | Simple & clear | Less precise |
| Periodic Safety Inspection Date | Very descriptive | Too long |
5Widget Design: Service Date
See the German section for full widget mockups — layout is identical in both languages.
Widget variants summary:
- Without Telematics (standard size): Last service date, Next service date (manual or calculated), Progress bar, Customer appointment, Audit info line
- With Telematics (extended, 2 Gridster rows): All of the above + Operating Hours block (current / threshold / remaining)
- Overdue state: Red header, warning badge, red progress bar
- Warning state (hours low): Orange telematics block when remaining hours < 10%
6Service Cockpit: Filter & Search
In Service Cockpit under Assigned Equipments, a date range search for Service Date will be introduced — analogous to the existing filter for Statutory Inspection Date.
New Filter Fields
| Field | Type | Filter Options |
|---|---|---|
| Service Date (Next) | Date Range | From – To, "overdue only", "no date set" |
| Last Service Date | Date Range | From – To |
| Statutory Inspection Date | Date Range | From – To, "overdue only" |
| Customer Appointment | Date Range | From – To, "has appointment" |
Implementation Pattern: Use the existing Statutory Inspection Date filter implementation as a template and apply it to Service Date (same GraphQL filter structure, same UI component).
7POC Plan & Phases
1
Discovery
Analysis, data model, API design
→
2
Backend POC
GraphQL schema, DB migration
→
3
Widget POC
Angular widget redesign
→
4
Cockpit
Filter & search
→
5
Rollout
Statutory Inspection + Notifications
Phase 1 · Discovery
Analysis & Concept Finalization
- Stakeholder alignment (Equipment Domain, Service Cockpit, Telematics team)
- GraphQL API design for the new ServiceDateData model
- Clarification: Where does "last service date" come from? (Smart Process trigger?)
- Define DB migration strategy
- Decision: "Statutory Inspection Date" as the final name?
Phase 2 · Backend POC
GraphQL Schema & Database
- New schema:
ServiceDateDataas GQL type - Add audit fields to DB:
source,changed_by,changed_at - Introduce
last_service_datefield - Expose telematics hours field:
remaining_operating_hours - Migration of existing
expected_service_datedata
Phase 3 · Widget POC
Angular Dashboard Widget Redesign
- Extend
TimeToServiceContentComponent(new inputs) - Refactor
TimeToServiceStorestate toServiceDateData - Two widget sizes: Standard (no telematics) / Extended (with telematics)
- Edit dialog: ability to set customer appointment with time
- Source badge + audit info row
- Gridster config: dynamic row count based on
isTelematic
Phase 4 · Service Cockpit
Filter & Date Range Search
- Assigned Equipments: Service Date range filter
- Reuse pattern from Statutory Inspection Date filter
- Extend GraphQL filter query
- "Has customer appointment" filter
Phase 5 · Rollout
Statutory Inspection Date + Notifications
- Apply same concept to Statutory Inspection Date
- Legal → Statutory rename (API migration)
- Notification system: inform partner + end customer
- Email / push when service due / customer appointment created
8Open Questions
1
Where does "Last Service Date" come from?
Is it automatically set when Smart Process – Service is completed? Or does the partner need to manually confirm it?
2
Telematics: Hours Reset Trigger
Who resets the hours to 0 after service? Does it come automatically from the device or does the partner confirm it? And does this reset trigger the "lastServiceDate" update?
3
Customer Appointment: Who can set it?
Only the partner? Or also Palfinger internal? Does the end customer receive a notification when an appointment is scheduled?
4
Statutory vs. Legal: Breaking Change Strategy
When will the old API name be deprecated? Are there external consumers of the GraphQL API that need to be migrated?
5
Notification System: POC Scope?
Should the notification system be part of the POC or a separate feature after initial implementation?