Anonymized engineering case study

Scheduling & Invoicing Workflows

Advanced scheduling and invoicing functionality for operational teams, including employee assignments, work periods, dynamic data grids, approval flows, PDF generation and multilingual communication.

  • Angular
  • Bryntum Grid
  • Node.js
  • Express
  • MongoDB
  • i18n

My contribution

Implemented Bryntum Grid solutions with real-time filtering, grouping, virtualization and custom renderers, and built the approval, PDF and multilingual email paths that turn a completed schedule into an invoice.

Key capabilities

  • Scheduling interfaces
  • Dynamic grids
  • Filtering and grouping
  • Approval workflows
  • PDF and email generation
  • Internationalization

Project context

Scheduling and invoicing are the same data seen twice. Someone plans who works which period; later, that plan has to become an approved, documented, sendable invoice — and the two views must never disagree.

This work covered both halves: the grid where operational teams assign employees to work periods, and the pipeline that turns approved periods into generated documents sent in the recipient’s language.

Technical challenge

Scheduling grids are dense. Users need many rows visible, grouped in a way that matches how they think about the work, filterable in real time, and editable without a page reload between every change.

The invoicing half brought a different problem: correctness under localisation. The same figures had to render identically in an on-screen summary, a generated PDF and an email — in more than one language, with formatting that stays right in each.

  • Keeping a dense, editable grid responsive in real time
  • Grouping and filtering that reflect operational structure
  • One source of truth shared by screen, PDF and email
  • Localised output that stays consistent across all three

Architecture

The scheduling surface is built on Bryntum Grid, integrated into Angular with custom renderers so domain-specific cells display meaningfully rather than as raw values. Virtualization keeps rendering cost tied to what is visible instead of to the size of the dataset.

Document generation runs server-side from the same computed model that feeds the UI. Templates for PDF and email pull from shared i18n resources, so adding a language is a resource change rather than a code change in three places.

  • Bryntum Grid integrated with custom Angular renderers
  • Virtualized rendering for large period datasets
  • Server-side PDF generation from a shared computed model
  • Shared i18n resources across UI, PDF and email templates

Features

From planning through approval to the document that leaves the system.

  • Employee assignment across defined work periods
  • Real-time filtering, grouping and sorting in the grid
  • Custom cell renderers for domain-specific values
  • Multi-step approval flow before invoicing
  • PDF invoice generation from approved data
  • Multilingual email delivery with localised templates

Security considerations

Approval is a privileged action with financial consequences, so it is guarded like one — the server decides whether a caller may approve, and generated documents are never served from a guessable location.

  • Role checks on approval and invoicing endpoints
  • Server-side revalidation of figures before document generation
  • Controlled, authorized access to generated documents
  • Audit-friendly state transitions between workflow steps

UX considerations

A scheduling grid is a working surface, not a report. Edits happen in place, grouping matches the mental model of the team using it, and the path from a completed period to a sent invoice is short enough that nobody keeps a parallel spreadsheet.

  • In-place editing without full page reloads
  • Grouping that mirrors operational structure
  • Visible workflow state on every row
  • Language-aware formatting of dates and amounts

Lessons learned

Virtualization changes how you write cell logic. Anything expensive inside a renderer is paid repeatedly during scrolling, so the work belongs in the data model rather than in the view.

Localisation is far easier when it is a constraint from the first template than when it is retrofitted — especially once the same values appear in a PDF and an email as well as on screen.

Technologies

  • Angular
  • TypeScript
  • Bryntum Grid
  • RxJS
  • Node.js
  • Express
  • MongoDB
  • PDF generation
  • i18n

Next step

Have a similar system to build?

Tell me what you are working on — the business problem, the constraints, and where the current setup falls short.

kreshnik.zabergja1@hotmail.com+383 44 919 372