Advanced: Work Reports

For users who already know the basics — this guide covers template design best practices, all custom field types and their constraints, the offer-based workflow in depth, signature edge cases, GPS modes, and how work-report items are merged into invoices.

Template Design Best Practices

A template (Work Reports → Templates) is the master definition that field workers select when creating a new report. Because templates are snapshotted at report creation time, changes you make to a template do not affect reports already in progress or completed — only new reports will see the update.

Design principles:

• One template per service type, not one per client. Templates should reflect the kind of work (e.g., "HVAC Maintenance Visit", "Electrical Installation Report"), not the individual customer.
• Pre-fill items with your standard work. The more of the template that maps to typical job content, the less the field worker needs to type on site. Use products from your catalog for standard services; add free-text rows for variable work.
• Use custom fields for information you always need. If every report needs a "Machine serial number" or "Site contact name", make it a required custom field on the template. Don't rely on workers adding it to the notes — they won't consistently.
• Keep the item list focused. A template with 30 line items where only 4 typically apply is slower to use than three narrower templates. Workers will check off the right items faster from a tighter list.

Template Versioning in Practice

Because there's no formal version history, use a naming convention when you update templates significantly:

• Current: HVAC Maintenance Visit
• After regulation change: HVAC Maintenance Visit v2

Keep the old template active for reports already in progress, then deactivate it once all in-progress reports using it are completed.

Custom Field Types in Depth

Making fields required: Each custom field can be marked required. Workers will not be able to complete the report until all required fields are filled. Use this sparingly — required fields that workers routinely can't fill (e.g., "Machine serial number" on a site where the serial plate is inaccessible) cause friction and workarounds.

Select field options are frozen at template creation. You can add new options to a select field on the template, and new reports will include them. Existing completed reports will retain whatever value was selected when the report was created — they won't retroactively show the new option.

No file upload custom fields. Custom fields are text-based. Photos are handled separately by the photos feature (toggled at the organization level). You cannot create a custom field of type "attachment."

Offer-Based Workflow in Depth

The offer-based workflow pre-populates a work report from an accepted client offer, eliminating manual data entry for planned jobs.

Full flow:

1. Rechnungsstellung → Offers → New — create an offer with line items representing the planned work. Set a valid-until date.
2. Send the offer; client accepts via the public link.
3. On the accepted offer in Stunden, click Create work report — the system:
   • Creates a new work report with all the offer's line items pre-loaded.
   • Creates a calendar shift on the assigned worker's Meine Schichten schedule (linked via Shift.work_report_id).
4. The worker opens the pre-populated report, makes any adjustments, executes the work, and captures the client signature.
5. On completion, office staff can import the work report's items into an invoice.

The auto-created shift is a real shift. It appears in the worker's schedule exactly like a manager-assigned shift. If the worker unclaims it (possible within the 24-hour window), the shift-work report link is broken — the work report still exists but the calendar entry is gone. Avoid unclaiming these shifts; use status changes or notes to flag reschedules instead.

Offer vs. work report discrepancies. If the actual work differed from what the offer described (different quantities, additional items), edit the work report before completing it. The invoice should reflect what was actually done (work report items), not what was quoted (offer items). If the discrepancy is significant, discuss with the client before completing.

Signature Edge Cases

The client signature is a canvas drawing captured on the device. Common edge cases:

Client is not present: The worker can still complete the report. A client_signature_missing flag is set and the PDF notes the absence. Use this when the work is done remotely, or the client representative was unavailable. Do not skip it silently — the flag ensures the office knows to follow up for a countersignature if needed.

Client refuses to sign: Same flow as "not present" — set the missing flag and note the refusal in the report notes field. This creates an audit record of the refusal.

Wrong device / screen issue: If the signature canvas fails to render (old device, browser compatibility issue), the worker can complete without a signature using the same flag flow. Capturing a photo of a paper signature as a workaround and uploading it as a report photo is acceptable.

Signed report corrections: Once a report is completed (signature captured), it cannot be edited by the field worker. Only a user with work_reports.manage permission can cancel a completed report (with a required written reason) and create a corrected version. The cancelled report keeps a watermark in its PDF. This ensures the client-signed version is never silently altered.

GPS Modes

GPS behaviour is set at the organization level (Organization → Work Reports → GPS mode) and applies to all reports:

Force mode and browser permissions: If the worker has previously denied location permission to the browser and GPS mode is force, the report submission will be blocked until they grant permission in browser settings. Test your deployment device before rolling this out. Tablet browsers sometimes have location permission managed at the OS level, not just the browser — check both.

GPS is point-in-time at report creation. The system captures coordinates when the report is started, not continuously tracked throughout the visit. The coordinates appear in the report history but are not shown to the client on the PDF.

Importing Work Report Items into Invoices: Merging Logic

When you import work-report items into an invoice (Rechnungsstellung → Invoice → Add work-report items), the system merges items using the rule:

Items with the same product + unit are combined into a single line.

If three work reports each contain "Labour – Electrician" at CHF 120/hour for 2 hours each, they merge into one invoice line: "Labour – Electrician × 6 hours @ CHF 120 = CHF 720."

When merging is useful: For clients who receive multiple service visits in a billing period, merging produces a clean invoice with summary totals rather than dozens of individual rows.

When merging is unwanted: If each job site visit should appear as a separate line item (e.g., for project-cost tracking or client transparency), use products with distinct names per visit — or manually split the merged line after import.

Free-text items do not merge. Only items with a product_id (linked to the products catalog) participate in merging. Free-text rows with no product ID appear as individual rows regardless of how many reports they came from.

Related Guides

• Modules-Arbeitsrapporte — basic setup and daily workflow
• Advanced: Rechnungsstellung — the invoice-side of the import and merging workflow