Across a fleet of thousands of units, mandatory documents were tracked by hand across sites and spreadsheets, deadlines slipped easily, and a repair or replacement meant recalculating the whole maintenance schedule from scratch.
The portal creates a document by event, schedule or manually, derives the next due date each time from the unit's actual history, routes the filled form through configurable approval and signature, and files it in a PDF archive; administrators build and change form templates themselves, no code changes needed.
The person in charge gets the document already created before the deadline, pre-filled with the unit's data, while the company sees fleet-wide what's filed, what's under approval and where a mandatory form is still missing.
Paperwork gets lost, the deadline slips by
At a company with a large fleet of equipment, documents come up for all sorts of reasons. A unit is put into service - one package is needed. Maintenance comes due - another. After a repair, replacement, or write-off, new forms appear.
With a fleet of thousands of units, this work quickly scatters across sites. One copy sits on location, a second is entered into the system, and some forms are filled in by hand. Copies have to be reconciled, while deadlines are tracked through spreadsheets and the memory of the people in charge. A mandatory document is easy to remember only once it is already overdue.
A simple electronic archive solves only the last part of the problem: it is a convenient place to store finished PDFs. But an empty folder will not tell you that in two months a particular unit will need a new document and that it is already time to schedule an engineer's visit.
A single repair changes the entire schedule that follows
Take a unit of equipment that is serviced every three months. The system knows the installation date, the document's frequency, and the lead time: for example, create the form two months or one week before the deadline. When the moment arrives, the document appears on its own, and the person in charge receives a notification.
Now imagine the equipment was repaired off schedule. The next cycle should start from the repair date: the equipment has already been serviced, and sending an engineer on the old schedule makes no sense. If you calculate the deadlines from the installation date once and store them forever, the whole chain that follows becomes wrong.
That is why the portal derives the next date each time from the unit's current history. A repair or replacement shifts the starting point, and with it the future document and reminder. This is exactly what sets the system apart from a calendar with dates set in advance.
A document appears in one of three ways
The system creates most recurring documents by event or by schedule. A non-standard document can be created by an administrator, and a finished paper from the site is attached by the person in charge as a photo or scan. Once created, all three variants pass through a common route.
The event can be putting equipment into service, a scheduled maintenance coming due, or a unit replacement. A schedule suits recurring forms, while manual creation leaves room for one-off documents that cannot be tied to a cycle in advance.
Next, the empty document goes through one and the same route, with exactly one fork on it:
Known data is pulled from the unit's profile, and the rest is entered by a person. An unfinished form stays a draft and is not lost. A signed document goes into the PDF archive and remains available for review; and if it is no longer current or was filled in with an error, it is archived and a new one is created in its place.
At every stage it is clear who holds the document and what should happen next. If a deadline is approaching and the form is not ready, the person in charge receives a reminder. For a document that requires approval, a random photo does not count as a result until the approver has checked it.
The approver sees the form in the portal and, with a single action, accepts or rejects it. There is no need to print the document just to review it and then scan it again. Approval, however, is not required to be set up: a simple document can move straight from completion to signing or to the archive.
The person draws the signature on the screen with a finger or a mouse. Along with it, the system stores the name, role, and date of confirmation.
A signature drawn on the screen records an internal confirmation along with a name and date. It does not replace a cryptographic electronic signature where such a form is required by law or regulation.
Insurance policies and other documents for the equipment pass through the same portal, although the main load falls on the equipment and its deadlines.
Familiar data comes back into the next form
The serial number, site, passport data, and specifications are already stored in the equipment's profile. A new document takes them from there, so the person in charge does not have to rewrite the same information into every form.
The link works both ways: if a person refines the data while filling in the form, the change goes back into the profile. This matters especially for recurring forms. The equipment card and the form do not end up with two diverging versions of the same specification, an error does not multiply into every next copy, and a person does not have to correct the same field over and over.
A document's attributes are independent of one another
Whether a document is mandatory and how it is filled in are independent of each other. A mandatory form can be filled in right in the portal or attached as a finished photo. A non-mandatory document can also exist in either of these variants.
| Document parameter | Options | What it affects |
|---|---|---|
| Mandatory status | Mandatory or non-mandatory | Whether the presence of the form must be tracked to comply with the regulation |
| Filling method | Form in the portal or photo/scan | Whether a person fills in the fields or attaches a finished document |
| Repeatability | One-time or periodic | Whether the document is created once or comes back on a calculated deadline |
| Approval | Enabled or not required | Whether an approver must review the form before signing and the archive |
Some forms are needed once: the document appeared when the equipment was put into service, it was filled in and sent to the archive. Others come back after a set period. For a recurring document, the portal calculates the next date, and for a mandatory one it additionally shows which unit has not yet met the requirement.
This difference matters for oversight. A non-mandatory form helps with the work, but its absence does not block the process. A mandatory one must appear by the deadline, go through its route, and remain in the archive. The person in charge sees the gap before an inspection, rather than hunting for the right paper once a regulator has already asked.
The form changes without reworking the portal
The set of documents is dictated by regulations, and it does not stay fixed forever. That is why the administrator assembles the template themselves: they add text, numbers, dates, tables, images, a file upload, and a signature field. Some fields are linked to shared reference lists, for example the list of sites, and the rest are created specifically for this form.
The administrator can add, remove, and rename fields. A value for one of them is chosen from a shared list, another is entered by hand, and a third is pulled from the equipment's profile. The form itself is assembled with the mouse in a visual editor, so changing an ordinary form remains a matter of configuration rather than a task to release a new version of the portal.
The on-screen form and the resulting PDF are configured separately. On a phone it matters that a person can fill in the fields conveniently, while in the archive and in print the same document should look like a proper form.
That is why a single template has two representations. The first is responsible for a person's work: the order of fields, entry from a phone or computer, uploading photos, and signing on the screen. The second determines how the values are laid out across the page of the finished PDF. Without this, a convenient mobile form would turn into a messy printed document, or a neat form would be hard to fill in on a small on-screen form.
When a regulation changes, a field can be added, removed, or renamed in the builder. An ordinary change to a form does not require waiting for a separate reworking from a programmer.
Two hard parts are hidden inside a simple form
The first is already described above: a deadline cannot be recorded once and then trusted without checking, because an unplanned repair or replacement rewrites the unit's history and the whole subsequent chain of dates.
The second hard part is giving the administrator the freedom to assemble a form while keeping its link to the data. A field on the screen has to be tied to the correct equipment specification or shared reference list, and the filled-in values then have to be laid out neatly in the PDF. The visual editor, the field binding, and a separate print view together turn the builder from a set of rectangles into a working document-workflow tool.
What changes for the person in charge
A person no longer starts work by searching for the right form and calculating the date. By the time it is time to act, the document is already created, the equipment's data is filled in, and the task has appeared on the plan. After it is completed, the system moves it through the configured route on its own and saves the finished PDF.
The company gets an overall picture of the fleet: which documents are already drawn up, what is in approval, and where a mandatory form is not yet ready. A particular unit's history determines its future deadlines, so unplanned servicing does not leave an outdated reminder on the calendar.
Automation starts with a properly described regulation
The portal does not decide on its own which form is mandatory, what it should contain, and how often to create it. These rules are set by the client and the regulator. An error in the frequency or the starting point will turn into an equally erroneous schedule, only an automatic one.
The builder covers document creation, filling in, approval, an internal signature, and the archive. A cryptographic signature, non-standard business logic, and integration with other accounting software remain separate tasks. That is why, before launch, it is important to work through the document workflow itself: which events move the deadlines, who is responsible for a form, and at what moment it is considered ready.
Oleksandr
This is a real project, presented anonymized. We deliberately change the identifying details - the industry, the specifics, anything that could point to the client - and we don't reveal the client's name or trade secrets. What stays intact is the substance: the problem we solved and the engineering approach behind it. This case study is here to show the problem and its solution - what we do and how.