DMS-IS — Contract & Procurement Management

Procurement teams were running on spreadsheets, shared folders and paper trails. A contract lived in one file, its amendments in another, a supplier complaint in an email thread — and nobody could say, without an afternoon of digging, which contracts were about to expire or how much of a contract's value had actually been delivered.

Three things had to change: one source of truth for the whole contract lifecycle; delivery numbers tied to real invoices instead of estimates; and a hard guarantee that one organization's data can never surface in another's, because the same platform would serve several organizations.

Six workspaces that share one data model, so a supplier, a contract and a complaint are never copies of each other — they're linked records.

A contract isn't a PDF — it's a promise being delivered against. Every contract carries its line items: what was ordered, in which unit, how much has shipped. Every delivery is logged as an activity with quantity, value, invoice number, invoice date and payment date, and the invoice itself attached.

Completion is calculated from those records on the server, per row. The progress bar in the register and the 100% on a contract page are the same number — and because nobody types it in, it can't drift from reality.

Framework agreements sit above contracts. Raise a contract from an agreement and the supplier is pre-filled and locked — the form says so — so a call-off can't quietly drift to a different vendor.

Supplier KPIs — contracts concluded, contracts fulfilled, value of fulfilled work — come from a dedicated aggregate query, not from the page of rows on screen. A paginated list would otherwise understate them, and the whole point of the card is to be right.

Quality and quantity complaints and court disputes used to be the least visible part of a contract's life. Here they're first-class records, each linked to the contract it concerns.

Complaints get a “contractual sanctions” view that swaps the status column for the consequence — and the consequence field itself only appears while a complaint is unresolved. Court disputes are tracked by competent court and status: in progress, or finally resolved.

Requisitions are the most intricate module: organizational units order against successive-delivery contracts, a verifier approves, and headquarters records the delivery. Each step is gated by role, and each rule is enforced twice — the interface hides what you can't do, and the API refuses it independently.

• Each requisition snapshots the submitter's organizational unit at creation, so reorganizing the org chart never rewrites history.
• Only successive-delivery contracts can be ordered against. The form filters them out for convenience; the API rejects the rest on its own.
• An evidence view rolls requisitions up by organizational unit and unit of measure — kilograms and pieces are never added together.

Six report areas — contracts, framework agreements, requisitions, complaints, court disputes and suppliers — each with KPI cards, charts and the table behind them. Contracts alone have eight views: overview, by year, by type, by value, by goods category, by place of delivery, quality and quantity, and by execution method.

Every report exports to Excel from exactly the data on screen, formatted in local number conventions. “Realized” means delivered in full; the quality and quantity view deliberately looks at all contracts, and ranks suppliers by how many quality complaints they've drawn.

A Spring Boot 4 API on Java 21 behind a Next.js 16 / React 19 frontend. Keycloak handles sign-in and carries the tenant in the user's token; the API validates every token by introspection. PostgreSQL holds the data under 11 Flyway migrations, MinIO holds the documents, and Caddy terminates TLS in front.

• Push to main deploys. GitHub Actions connects over SSH with a pinned host key — and fails the deploy if the server's identity ever changes — rebuilds only what changed, then checks the live site and the login service from outside.
• Encrypted, deduplicated backups every night — databases, identity store and documents — to off-site storage, with seven daily, four weekly and six monthly restore points. A full test-restore into throwaway containers matched production before we called it done.
• Tuned for a small server: capped JVM heaps, a smaller connection pool, request throttling and swap, all verified under load with container stats.
• A cloud firewall, a host firewall and fail2ban sit in front of an automatic-TLS reverse proxy. Development-only ports don't exist in production, because the production deploy excludes the override file that opens them.

Live on its own production infrastructure since July 2026, with automated deploys, nightly restore-tested backups, and a portable offline edition running the identical application.

For the people using it, the answer to “which contracts expire soon, and how much has actually been delivered?” went from an afternoon of spreadsheets to a filter and a progress bar.