Cost centers

Register profit centers (areas, squads, units). Classify invoices to answer "which area is profitable?" without a parallel spreadsheet.

Registers and organizes the company's profit (or cost) centers. They're hierarchical — the Parent center field builds the tree — and they're reused in contracts and financial transactions, to read revenue, cost and result by area. The ERP Code ties each center to the source system's code when there's an integration. Clicking the row opens the record for editing.

This list accepts filtering by link: ?q= searches, ?fd_= filters by a dictionary field and ?excluidas=1 opens the recycle bin. That's how a total clicked on another screen arrives here already narrowed to the same set that made up the number. Also: views saved per user, column preferences and Excel/PDF/CSV export of the entire filtered set — not just the visible page. And Ctrl+K finds any screen by name or synonym.

Parent center places the center in the hierarchy: leave it empty for a top-level center and point to a parent to create subdivisions (e.g. "Sales" with "Pre-sales" under it). This tree is what contracts and finance reuse to allocate and group results. ERP Code is the reference used to match the center with the source system in imports and integrations — if the company came from another ERP, filling it in avoids duplicate centers in the loads.

The collapsible Center structure block at the top of the list shows the tree: groups (summary) in bold and leaves (detail) below. On each node: Move (choose the parent group), Make root, Visibility by company and Type (operational or project/CAPEX). The Show inactive button only appears when there is an inactive center. The old structure address opens the list with the block already open.

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.

When the type is Person, the form asks for the relationship, the birth date and whether the person is an income-tax dependant. The dependant goes into the return of their holder (the "Holder" field): the family income tax shows each person’s dependants and deducts the legal amount per dependant in the monthly tax, when you don’t use the simplified discount.

In a Family account, open the card of a member of type Person and use “Invite to the account”: enter the e-mail and, for a child, tick Child. The invite goes by e-mail with a link for the person to set the password (the link also shows on screen, to send another way). The member logs in with their own “for whom” already set on entries.

A center cannot be its own parent or the parent of an ancestor (it would create a cycle), and a center that already has entries does not become a group — reclassify its entries to a leaf first. Importing the tree from the bar shows the review (name, status and parent) and only saves after confirmation; the parent is the code declared in the spreadsheet, never the prefix.

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?".