Group units

Equipment without a plan generates no preventive maintenance at all: it's only serviced when someone calls to complain. It's the silent explanation of an operation that lives putting out fires — and it's the reason the installed base panel counts how many pieces of equipment are in that situation.

The periodicity of each piece of equipment (or each type) and the checklist the visit will follow. This is where the preventive order is born on its own, without anyone remembering to schedule it — and it's preventive maintenance that sustains the recurring contract. — this is the role of the "Maintenance plans" screen within the platform.

Generation runs on its own once a day. Whoever has just registered the plan wouldn't see anything happen until tomorrow and would conclude, rightly, that it didn't work. The button runs it immediately, and it's safe to press twice: generation is idempotent per plan and per period, so it doesn't create a duplicate order.

The order is opened a few days before the scheduled date, so that whoever builds the route has time to fit it into the day of a technician who already has a schedule. Zero days means the order appears on the day itself — which in practice is usually too late.

The "Next execution" field is the anchor of the plan: it is from this date that the first preventive order comes, and the frequency pushes the following ones from it. When registering a plan for equipment that has just been installed, use the date of the first visit agreed with the customer — not today's date —, otherwise the preventive maintenance is born overdue or too early. Once the schedule gets going, the system itself recalculates the date at each execution; you only touch it again if the contract changes pace.

This record uses the platform's standard form: the previous/next arrows at the top move from one plan to another without going back to the list — useful in the annual review, when you check the frequency of dozens of plans in sequence. The 1, 2 or 3 column preference of the form is also yours and is saved per screen (the global default lives in the User Preferences). And the "?" button opens this help on any screen.

A TYPE plan whose last piece of equipment was deactivated stays in the register and stops producing. In that situation the next execution date does NOT advance — on purpose: the plan stays overdue and visible, instead of marching on silently looking healthy.

Manual generation is idempotent per plan and period: if that plan's order already exists for the period, pressing again doesn't create a second one — the button exists because the scheduler runs once a day, and whoever has just registered the plan wouldn't see anything happen until tomorrow, concluding it didn't work. Use it without fear after registering or correcting a plan; the worst that happens is the answer that the period's orders had already been generated.

When you save a view with the Views button, it stores four things: the search text, the applied filters, which columns appear (and in what order) and which column the list is sorted by. Applying the view restores everything at once — including resetting the sort and the page you were on, so the result is exactly what the view describes. Views saved before this version remain valid: whatever they didn't store simply doesn't change when applied.

Nas fichas, sair de um campo já dispara a conferência do que dá para conferir na hora: campo obrigatório deixado em branco e e-mail mal formado. O aviso aparece embaixo do campo e desaparece quando você começa a corrigir. Campo numérico não precisa de aviso: ele simplesmente não aceita letra enquanto você digita. Isso é conforto, não a validação final: ao salvar, o sistema confere tudo de novo do lado do servidor.

Choose the EQUIPMENT when that machine needs its own rhythm; choose the TYPE when the rule applies to all of the same type. With both filled in, the same equipment would receive the preventive maintenance from its own plan and from the type's plan: two visits for the same machine, and nobody understands why. That is why the screen refuses it. A piece of equipment that has its own plan is automatically ignored by the type's plan. That is how you make an exception for one machine without dismantling the general rule.

In the record's activity panel, each note has "Turn into request". The click creates a ticket with the note's text, who wrote it and the link to this record — nothing is retyped. Use it when the note is a request for action ("someone needs to review this"); the note stays where it was. The button only appears once the record has been saved; a read-only session (demo) doesn't create one.

"How often does each piece of equipment need a visit?" — when that question comes up, this is the screen where it gets answered.

The plans list runs on the standard engine: it exports Excel, PDF and CSV of the entire set, keeps saved views per user and has a trash (?excluidas=1 in the URL). Search accepts ?q=text and filtering by field accepts ?fd_=valor with the dictionary key — for example, filtering by periodicity to review all monthly plans at once. Column preferences are per user, so organize the list your way without affecting the rest of the team.

Open the record and look at the Timeline on the right: it shows each change as "from one value to another", with the person and the date. When there are many changes, use the two filters at the top of the timeline — one by field, the other by person. The search runs in the database, so old changes show up just the same. You can also ask Tenkai: "who changed contract 482?".

Because the preventive order is born with the routine attached, and it is the routine that says what to check. Without it, the visit reaches the technician without a checklist — they complete it with nothing to answer, and the inspection cannot become a report. The dropdown only offers routines of the chosen type: attaching a fire extinguisher routine to an elevator would open the inspection with the wrong questions.