PotoP Enterprise Suite

The schedule is a view over the same job and absence records the planning board uses, grouped by day, with planned hours added up beside the hours the person has clocked. Nothing extra is stored for it. The calendar link is a private, revocable address that serves a standard iCalendar feed, so Outlook, Google Calendar or a phone calendar can subscribe and refresh it themselves. The address contains a secret token and can be switched off at any time, which stops the feed immediately.

A project is the record that groups jobs, with a customer and a budget. The page adds up booked hours from approved timesheets and planned hours from the planning board, both read from PostgreSQL when the page is opened, so the totals always match the underlying entries. Engineering packages, extra work and materials attach to the project through ordinary database relations, and each tab is a separate server-rendered view that appears only if the company has licensed that module and the user has permission to see it.

The list is the technician's own view of the shared job table: jobs assigned to that person, grouped by day, with the status they move through as they work. Sharing location is a switch the technician controls, and the banner shows the browser is sending a position at a fixed interval while the switch is on. Reporting a fault opens the same fault form the office uses, so the report lands directly in the fault queue. The page is responsive and is the same one the Android app shows.

Each fault is matched to a service-level policy for its priority, and the first-response and resolution deadlines are calculated from it on the server and stored with the fault. Drawings and whitebook entries are linked through the installation the fault belongs to. The chat on the fault is the same end-to-end encrypted messenger used elsewhere: encryption and decryption happen in the browser, and the server only holds ciphertext. Every visit, status change and update is written to the fault's history with the person's name and time.

A work order is one job record with relations to everything around it. The drawing and documents are links to the installation and its stored files, the instructions are text the office wrote for the site, and the history is an audit trail of who changed what and when. Technicians record time as segments that are marked either as clocked with a button or typed in afterwards, so a correction is visible instead of silently rewriting what the phone recorded. Materials booked here reduce stock and appear on the project.

An entry is filed under a system type, in the same vocabulary the engineering drawings use, so the same entry appears for every installation of that system. Photos are taken with the phone or browser camera, and simple sketches are drawn with a finger on a canvas and stored as images next to the text. Read, edit and add-a-note rights are separate permissions. Entries can be printed as a PDF, and the link to the people who know the system comes from the skills ratings kept in the people module.

Each card is one system description stored as data: its part types, the connections allowed between them and the tables of numbers and addresses the engineering document needs. Because the editor is generic, adding support for another manufacturer means adding a new description rather than new code. The counts on the cards are taken from those descriptions when the page loads. The PotoP VMS Studio entry is one of these descriptions, which is what lets a drawing be turned into a working camera and recording setup on a VMS server.

Any part on any drawing can carry a certificate end date, and this page collects all of them across the company with one query, sorted by remaining days. A background job checks the dates every day and sends warnings at six, three, two and one month, then at twenty, ten and one day before the end, and once after expiry. Warnings go by e-mail, Telegram and inside the suite to people who may edit drawings. Each warning step is recorded on the item itself, so a restart or a second run never repeats it.

A run is calculated on the server from records already in the product: the contract, the effective-dated wage, hours that a manager approved split by the company's own hour codes and factors, leave and sickness percentages, and approved expenses. Gross, tax and net pay follow from those, and the pre-check lists people with no salary record before anything is calculated. Payslips are produced as PDFs, and the payment batch can be exported as a SEPA file or handed to a bank's payment API, where a person still authorises it at the bank.

Hours are entered against a project or a work order and stored as time segments in the database. The page compares them with the planned jobs and roster for the same week, so planned but unbooked work is marked. Submitting the week locks it for review by a manager, and only approved weeks flow on to payroll and to the hours totals on projects. Segments record whether they were clocked with a button or typed in afterwards, which keeps corrections visible and attributable to a named person.

A supplier invoice is entered with its scanned PDF attached, then moves through checked, approved and paid states, each step recorded with the person who took it. Approval creates the ledger posting, so the books reflect the liability straight away. Approved invoices can be collected into a single payment batch and exported as a SEPA credit transfer file for internet banking, or sent to a bank's payment-initiation interface, where a person authorises the payment at the bank. Due and overdue counters are calculated from the payment terms.

The books are a double-entry ledger in PostgreSQL. Every figure on this page is a sum over posted lines, calculated when the page is requested, so a stored total can never disagree with the entries behind it. Other modules post automatically, for example payroll, depreciation of fixed assets or an approved purchase invoice, and each posting keeps a reference to its source. The checks above the list test the ledger itself, such as whether debit equals credit. Correcting a source document rebooks it rather than leaving an orphaned entry.

Reports never write anything. The balance sheet, profit and loss, trial balance and day books are queries over the posted ledger lines for the chosen period, so they are always current and any figure can be traced to its entries. Results can be downloaded as CSV, and spreadsheet exports use the suite's house layout. The annual accounts are produced as a PDF, and the audit file is a standard XML file that an accountant or the tax authority's tools can read. Reading reports needs its own permission.

A tool is a record with its own inspection interval, insurance expiry and day rate. Inspections and repairs are logged as entries with their cost, and the next inspection date is calculated from the last logged one. Reservations are rows linking the tool to a work order and dates, so two jobs cannot silently claim the same ladder. The daily background job that watches expiry dates can warn by e-mail and inside the suite, and the day rate feeds project cost figures.

The vault is zero-knowledge. Each user has a key derived from a passphrase with PBKDF2 and a P-256 key pair, and every item has its own random key with the content sealed as AES-GCM in the browser before it is sent. The server stores ciphertext and wrapped keys and can list, count and share, but cannot open anything. The health check therefore runs in the browser after decryption, counting weak, reused and old passwords locally. Sharing wraps an item's key for a collection, and the company can hold a recovery key.

The assistant is a set of actions, not a free-running model. Questions such as where a device is, what is planned today or who knows a system are answered by database queries that respect the asker's permissions. Actions that change data are labelled and need confirmation. A language model is optional: the company can connect any OpenAI-compatible endpoint, including a local one such as Ollama on its own hardware, and everything works without it. Answers run in the background so long generations do not time out.

The charts are aggregated on the server from the same operational tables the rest of the suite uses: finished jobs, faults, clocked hours and sign-in activity per day. The warnings come from health checks such as failed e-mail delivery and breached service levels. For infrastructure monitoring, PES also exposes a text metrics endpoint in the Prometheus format, which Grafana, Zabbix or Uptime Kuma can scrape. Operators can additionally be alerted by e-mail and Telegram when a new error or a security event occurs.

Each report is a read-only query over faults and their recorded deadlines, grouped by priority, customer and team. Percentages are shown with the counts behind them, such as 47 of 50, so a figure can be defended. The window and filters used are printed on the report. PDF files are drawn on the server, Excel and CSV are generated as files, and the weekly schedule runs as a background job that mails the finished report to the chosen recipients using the company's mail settings.

Passwords are stored as Argon2id hashes and sessions are kept on the server, so an administrator can revoke one. Two-step verification uses standard time-based codes with recovery codes, passkeys use WebAuthn, and a company can require two-step for everyone. Users belong to groups that carry permissions. Accounts can be created in bulk from a spreadsheet, with a generated password sent by e-mail, or synced from Active Directory or LDAP, where people who leave are disabled rather than deleted. Every change is written to the audit trail.