Secure Mobile Timesheet Applications on SAP BusinessObjects

Summary

We build mobile timesheet applications for field claims and adjusting work, backed by a service layer and a SAP BusinessObjects reporting model. This kind of work covers offline-capable capture on the device, periodic background synchronisation, an auditable entry lifecycle, and row and column level security in the semantic layer. The same entries drive both payroll and what an insurer is invoiced, so the records have to be evidence-grade rather than merely convenient.

The Challenge

Time is billed in increments against a specific file, and the people recording it are rarely at a desk. Capture has to happen where the work happens and survive poor connectivity. Legacy timesheet systems typically fail on three counts: no mobile access, no secure distribution of the resulting reports, and no controlled way to correct an entry after submission.

Synchronisation is where most of the engineering difficulty actually sits. Entries created offline need device-generated identifiers so they can be inserted without a server round trip, and every sync operation must be idempotent because retries are guaranteed. Conflict resolution has to be defined explicitly: an entry edited on the device after being amended on the server is a real scenario, and silently taking the last write loses billable time. Device clocks drift and can be changed by the user, and a full push over a weak connection will not complete.

Naive builds treat deletion as a hard delete rather than a reversing audit record, allow edits to submitted periods without a re-approval path, and report directly against transactional tables so reporting load competes with data capture. Each of these surfaces as a dispute long afterwards, when the record has to be defended.

The Solution

Components

• Cross-platform mobile front end built with Xamarin Forms and XAML, sharing one code base across devices while keeping platform-specific storage and notification behaviour.
• Local store in SQLite, holding entries and reference data so the application is fully usable with no network.
• Service layer of WCF services hosted on IIS, exposing authentication, synchronisation and reporting operations.
• Relational database as system of record, with a three-tier separation of presentation, business and data access.
• SAP BusinessObjects as the reporting and semantic layer over submitted time data.

Functional core

The functional core is narrow but exacting: create an entry against a work code, date, file number, insured and hours, with a description; run a live timer for precise task duration; save, view, edit and delete entries with a full audit trail; submit and resubmit; and reuse recent entries so repetitive logging is not retyped. Deletion is a reversing record, and amendments to submitted periods route through re-approval.

Synchronisation

Periodic background synchronisation is designed for hostile conditions. Server-side receipt timestamps accompany the device-reported time rather than replacing it, so clock drift is visible instead of silently authoritative. Sync is incremental, resumable and idempotent, and conflicts resolve by an explicit rule rather than by arrival order.

Security and access control

Authentication uses a second factor, typically a one-time passcode screen after credential entry, with tokens stored in the platform secure keystore rather than application preferences. Beyond login, the reporting layer carries the harder controls. In BusinessObjects, row-level restrictions in the semantic layer limit each user to the files and cost centres they are entitled to see, and column-level restrictions hide sensitive measures such as rates from users who may view hours. Those restrictions live in the universe and security model, not in report definitions, otherwise a new report bypasses them entirely. Distribution is part of the same boundary: automated Excel and CSV delivery by email is the most likely place for a leak, so recipient lists derive from the same role model that governs the reports.

How we build it

We define the entry lifecycle and its audit semantics first, then build sync against deliberately degraded network conditions, and model reporting security before the first report is authored so that every later report inherits it.

What This Delivers

Field staff record time at the point of work without waiting for a signal, and what they submit becomes a defensible record with a traceable history of every correction. Payroll and billing draw from the same governed data, reporting is separated from capture, and each recipient sees only the files, cost centres and measures their role permits.

Technologies and Tools

Xamarin Forms and XAML, SQLite local storage, WCF services on IIS, a three-tier relational back end, SAP BusinessObjects universes with row and column level security, and automated Excel and CSV report distribution.