A vendor list that can say no.
Names and phone numbers are an address book. What stops an uninsured contractor walking onto a roof is a register that knows when the policy lapsed, gets asked before the work is booked, and answers with the document and the date rather than a shrug. In Zenith that rule is written once and guards three doors — a purchase order, a site visit, and the contractor's own record — so there is no version of it that is quietly out of date.
Compliance expiry · Engage gate on three doors · Subcontractor calendar · Purchasing · Bilingual EN / FRSix parts, one outside company
The word for an outside company is one of the most contested in maintenance — a hospital says service provider, a mill says contractor, purchasing says supplier, and all three mean the same record. Zenith holds one record and lets you call it whatever your people already call it.
Who they are
Code, type, status, the trades they actually do, the asset classes they are competent on, the sites they may be sent to, and the manufacturers they are authorized to service.
Their paperwork
Six document types with an issue date, a required expiry, a reference and a coverage amount in the vendor's own currency. Renewing a policy replaces it rather than stacking a second one.
The gate
One function that answers “may this company be engaged, for this site, on this date?” — and returns every reason it cannot, rather than a bare no a planner has to guess at.
Their people
A vendor's field engineer is a record in the people register like everyone else. A second contact table would mean two answers to “who worked on this generator?”, which is the duplication the register exists to prevent.
What they are booked for
A Monday-based subcontractor calendar, gated by the same rule, with a dispatch sheet assembled from the work order it references — so the sheet cannot drift from the job.
What you have bought
Requisitions, approvals, purchase orders, receiving against the storeroom ledger, and closing short with a written reason. A vendor page that cannot answer “what have we bought from them?” is an address book again.
Four states, because a tick would be a lie
Most vendor lists carry a compliance checkbox. A checkbox has two states and the problem has four — and the two it collapses are the two that matter. A policy that lapsed in March stops work today. One lapsing next month creates a task for somebody. And “no documents on file” is not the same as “all current”: a tick against a parts supplier who has never recorded anything would be a lie told by the same pixel that tells the truth about everybody else.
- Expired, expiring, current, none on file — a filterable column on the register, computed for a date you choose rather than for whenever the page loaded.
- The worst thing true is what it says — a contractor with a current ticket, current coverage and one lapsed policy reads as expired, because that is the fact that changes what happens next.
- Sorted by severity, not alphabetically — the reason anyone sorts this column is to bring the problems to the top, and “current” filing above “expired” because C precedes E would defeat that entirely.
- Every row on the page answers as of the same day — the date is read once per render, so two reads either side of midnight can never disagree with each other.
- Current on the day it expires — insurance runs to the end of its last day, and sending a crew home on the renewal date would be a bug wearing a badge of diligence.
“No” is not an answer anybody can act on
When a system blocks something, the person in front of it has to work out what to do next. So the gate does not return a boolean — it returns the reasons, all of them, in sentences. Chasing an insurance renewal is the vendor's job. Lifting a suspension is procurement's. Finding somebody approved for that site is the planner's. Showing one reason at a time turns three parallel problems into a queue.
- Five typed reasons — the record is retired; the relationship is suspended or terminated; a named document lapsed on a named date; the vendor does not serve that site; the vendor has no recorded competence on that asset class.
- Every reason, not the first — a vendor with two problems shows two, because they are fixed by two different people at the same time.
- The banner sits above the tabs — whether this contractor may be sent today is the expensive thing to get wrong; the rates, the trades and the contact list are reference material a phone call could supply.
- An empty site list means everywhere — a national supplier is not restricted, and forcing somebody to list every site would guarantee the list goes stale within a year.
- An empty class list means “no restriction recorded” — not “competent on nothing”. Printing a dash would read as the second.
One rule. Three doors. No second copy.
The usual failure is not that a system lacks a compliance check. It is that it has three of them — one in the vendor screen, one in the purchasing screen, one in the scheduling screen — written at different times by different people, and two of them are wrong. In Zenith the check exists once, as a function that takes the vendor, the requirement and the date. Everything that needs to know calls it.
- A purchase order will not issue to a company the register says cannot be engaged. The refusal panel names the document, and the button stays disabled until it is fixed or a different vendor is chosen.
- A site visit will not schedule for the same reason. A contractor whose insurance lapsed should not be booked onto a roof any more than onto an order.
- The vendor's own record answers the general question — asked with no site and no asset class: may this company be engaged at all, today?
- The site is inferred where it is known — an order delivering to a Victoria storeroom is checked against Victoria, so a vendor who serves Vancouver only is refused with that reason rather than a generic one.
- Change the rule once — add a document type or a status and all three doors move together, because there is nothing else to move.
Compliance is a question about a date
Almost every vendor module answers “is this contractor compliant?” against the wall clock. That is the wrong question. Nobody schedules work for right now — they schedule it for the outage in six weeks, and what matters is whether the coverage will still be in force when the crew arrives. So in Zenith the date is a required argument everywhere it could matter, and there is no default that could quietly answer something else.
- The register filter takes a date — “show me who will be expired on 25 October” is the same screen, not a report somebody has to build.
- The expiry warning takes a horizon — sixty days by default, and it is a parameter rather than a constant buried in a screen.
- The refusal is reproducible — the same vendor, requirement and date always produce the same list of reasons, which is what makes it defensible when somebody challenges it.
- Documents renew, they do not accumulate — recording a new liability policy replaces the old one, because a list with two is a list where somebody has to decide which counts.
- A policy expiring before it was issued is refused — storing that typo would leave a contractor permanently blocked for a reason nobody could see.
“The chiller is down — who do we call?”
That question is asked by somebody who does not know the answer and cannot afford to find it out by ringing around. It is answerable in Zenith because a vendor records the manufacturers they are authorized to service and an equipment model records its manufacturer. The tab just joins them — and it puts the compliance badge right there, because the moment somebody picks a name off that list is the moment it matters whether the name they picked still has insurance.
- Authorization is on the record, not in somebody's memory — “who is approved for Trane equipment?” is a field, not a folder.
- Preferred vendors come first — a policy flag that changes the order of a picker, not a rating anybody has to defend.
- The promised response time is shown beside the name — in hours, because “next business day” cannot be compared with “four hours”.
- It appears on the equipment model, not only on the vendor — reached from the machine that is broken, which is where somebody is standing at 2am.
- Nobody servicing that make returns nothing, not an error — an honest empty answer beats a screen that looks like it failed.
Booking a contractor asks the same question
The vendor schedule is a Monday-based week with the visits under it and a form to add one. The form is live-gated: choose a company and a site, and if the register has a reason to refuse them it appears immediately with the Schedule button disabled — before somebody has typed the times, not after they have told the contractor to come.
- A visit references the job, it does not copy it — the dispatch sheet reads the work order, the asset and the site live, so it cannot drift from what was actually agreed.
- Complete and cancel are one-way and only from Scheduled — a completed visit cannot be quietly cancelled afterwards, which is how a week's record stays worth reading.
- A window that ends before it starts is refused at the door rather than stored and puzzled over later.
- Today's visits appear on the home dashboard beside today's work orders and PM due — assembled from the registers that already know, so nothing is typed into a calendar twice.
- Print or save as PDF — the sheet a coordinator hands over or attaches to their own email.
A shortage walks left to right across one page
A requisition is a maintenance question — “we need filters” — raised by whoever saw the shelf. An order is a commercial commitment to a named company with prices on it. Zenith keeps them apart, because collapsing them means either every storekeeper can commit the organization's money or every purchase waits for a buyer to notice a shelf, and every real plant has learned to want neither.
- Replenishment is computed, not remembered — what fell below its reorder point, less what is already on order, rounded up to whole purchase packs, because a vendor sells cases and “order 11.7 cases” is a number nobody can act on.
- The cheapest order is the one never raised — if another storeroom is holding more than it needs, the transfer is suggested out loud, beside the buy button rather than after the invoice.
- Approval sits on the requisition, where the budget decision belongs, and declining one requires a reason.
- Receiving lands in the storeroom ledger through the same append-only receipt as everything else, in packs, converted by the item master's factor — so the balance, the movement history and the order agree because they are reading the same rows.
- More than was ordered is refused at the door — the difference between a generous delivery and a wrong one is somebody checking here.
- Closing short demands a written reason — the outstanding quantity was a promise to a shelf, and whoever breaks it writes down why, where replenishment will see the gap again.
WCB in British Columbia is WSIB in Ontario
Compliance document names are statutory and they differ by province and by country. Same rule, same expiry date, a different name on the certificate — and a system that hard-codes one of them makes every other jurisdiction read its own paperwork in a foreign dialect. In Zenith the vendor entity, its type values, its status values and all six document names go through the terminology registry.
- Six vendor types, four statuses, six document names — every one of them renameable, in both languages, without a developer.
- Full en-CA / fr-CA parity on every label, hint, empty state and refusal — including the sentence explaining why a contractor cannot be engaged.
- The list stays closed — you can rename “Liability Insurance”, you cannot turn the document set into a free-text field, because that is the moment “is this vendor insured?” stops being answerable.
- Product prose stays product prose — the surrounding sentences are our voice; the words that name your records are yours.
The job that has to leave the building
A contractor is usually not chosen — they are arrived at, because nobody on the books can legally do the work. Zenith says that out loud on the planning side, before anybody starts ringing around, and it distinguishes the two cases that get confused: nobody holds the ticket at all, and only a contractor holds it.
- “Only a contractor holds this ticket” is reported as its own answer — the work can still happen, at somebody else's rate on somebody else's calendar, which is a decision rather than a blockage.
- The backlog says why a job is stuck — “vendor required: no craft on the books can do this work” is a reason with a link, not a job sitting silently at the bottom of a list.
- An approval step appears automatically — work that leaves the building needs somebody who can commit the organization to buying it, and that step is added to the chain rather than remembered.
- Answered for a date, like everything else — “nobody holds it” and “everybody's certification has lapsed by then” are the same answer to a planner and completely different answers to a supervisor.
- Contractor hours carry a rate or declare they don't — a contractor with no rate on file makes a job look cheap, and a total that quietly omits them is worse than one that says how much of itself is missing.
Everything the register touches
Coverage amounts name their currency
A bare 2,000,000 beside rates quoted in dollars is a number nobody can act on. Coverage is money, so it says which money.
Contacts are people, not a second table
A vendor's field engineer links into the people register. One record, one place it is maintained, and one answer to who worked on the machine.
Filter by trade, not by company name
Pacific Controls Group does not appear under the Controls trade filter. Matching a name and calling it a capability is how a consultant gets sent to fix a starter.
New vendors start provisional
Approval is a decision somebody makes, not a side effect of typing a name. A reinstated vendor comes back provisional too, for exactly the same reason.
Retire, don't delete
A terminated contractor's name is on four years of completed work. The record stays readable and is simply never offered for new work again.
What has been bought from them
Purchase orders appear as a tab on the vendor's own record — code, status, date raised and value — because “what have we bought from them?” is the second question anybody asks.
Cover before the clocks
A machine under warranty or service contract is repaired by somebody else's labour. That is said on the work order above the time fields, not discovered after the hours are booked.
Rented tools know whose they are
A rented tool with no vendor on it is one nobody can give back, and the invoice arrives regardless — so the record refuses to be saved without one.
Site-scoped throughout
Every list and picker respects the sites somebody is authorized for — enforced in the query. A vendor serving no particular site stays visible everywhere, which is correct for a national supplier.
Where this build stops
We would rather lose a deal here than in month four of an implementation. Everything above is in the product and demonstrable today. Everything below is not, and we would rather you knew before the demo than after the contract.
The register is read-only in this build
The rules are real and the screens are real. What is not there yet is the maintenance of the register itself: the vendor grid, the record, the compliance tab, the gate, the schedule and the purchasing desk all read, filter, refuse and explain — but adding a company, recording a renewed policy, attaching a contact or suspending somebody are platform commands with no screen in front of them.
- Create, edit, record-compliance, add-contact, deactivate and reactivate all exist as tested commands with their validation and their refusals — they land with the administration screens and the persistence layer.
- Nothing promotes a vendor to Approved yet — the two-step convention is enforced (new and reinstated companies are Provisional) but the promotion itself has no command in this build.
- Every register in the platform is session state until the API lands — this one included. What we are showing you is the model and the screens, honestly labelled.
Contracts exist — but not from the vendor's side
This is the gap we get asked about most, so here it is precisely. A service contract is a real record in Zenith with SLA response and resolution hours, an annual value, the assets it covers, and a renewal date that counts down to the decision rather than to the end — because a contract that auto-renews sixty days early has already renewed by the time an expiry report notices.
- You reach it from a machine, not from a company — a Cover tab on the asset answers “is somebody else paying for this repair?”, which is the question that stops money being spent twice.
- The vendor record carries contract identifiers that do not resolve yet — and the screen says exactly that, rather than pretending.
- There is no contract register and no renewals list — no page that answers “what is up for renewal this quarter?” across the whole portfolio. That is the contract module, and it is not in this build.
- A warranty is not a service contract — one comes with the asset and covers defects, the other is bought and covers work. They expire differently and are claimed differently, so Zenith keeps them apart even though most systems do not.
One fact, one place, every screen
The discipline behind this module is that a rule lives in exactly one function and a fact lives in exactly one record. That is what stops a compliance check on the purchasing screen quietly disagreeing with the one on the vendor screen two releases after anybody remembers they were separate.
Referenced, never retyped
Contacts point at the people register, authorizations at the catalog, sites at the location tree. A dispatch sheet reads the work order rather than copying it.
Refusals in sentences
Every gate returns typed reasons, and every reason has a sentence in both languages. A blocked screen tells you who fixes it.
Bilingual by birth
Full en-CA / fr-CA parity on every label, hint, empty state and refusal — the vocabulary your province uses, not a translation of ours.
Accessible to everyone
WCAG 2.2 AA as a build rule: real table semantics, compliance states announced in words rather than colour alone, and focus that lands where an error refers.
Before you book the demo
Can it stop an uninsured contractor being sent to site?
Can we upload the certificate of insurance itself?
Will it email us before a policy expires?
Do you score or rate vendors?
Is this a procurement system?
Can we track service contracts and their SLAs?
How does it handle a contractor working across several sites?
Can contractors log in and see their own work?
Do you capture contractor hours and cost?
What happens to a vendor we stop using?
Our people say “supplier”, not “vendor”. Does that matter?
Where do we start?
Bring the certificate nobody can find.
Bring one contractor, their real documents and their real expiry dates, and we will build the record in front of you — then ask the product whether they can be sent to a job in six weeks, and watch it answer with the policy number and the date rather than a shrug.