Invoice types

Register the invoice types used. The type is mandatory on the transaction and helps analysis (how much comes in via PIX vs boleto).

How your company classifies payable and receivable entries — the label that appears on the entry, in the filters and in the finance reports.

Registers a type of financial entry — the label that classifies entries (bank slip, PIX, debit note, whatever your operation uses). The fields are Name, Description, Active and ERP Code, which ties the type to the source system in integrations. The form uses the platform engine: the previous/next arrows move between types without going back to the list, and the preference for 1, 2 or 3 columns is saved per user.

?q= opens the list already searched, ?fd_= filters by a dictionary field and ?excluidas=1 shows the recycle bin — links from other screens arrive here with the same selection that formed the number clicked. Saved views keep filter combinations per user, the displayed columns are your preference, and Excel/PDF/CSV export the entire filtered set, not just the page. Ctrl+K finds any screen by name or synonym.

ERP Code stores this type's identifier in the system the data comes from (or goes to). In imports and integrations it is by this code that records recognize each other — without it, a new load may create a duplicate type instead of reusing the existing one. If the company operates integrated with another ERP, fill it in from the start; if the operation is born and lives in Tenka, you can leave it blank with no harm.

An inactive type leaves the list of choices for NEW entries. Old entries keep it, remain editable and keep appearing in reports with the same label — the history is not rewritten.

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.

Unchecking Active removes the type from new choices without touching the entries that already use it — the history stays intact and old reports read the same way. It is the right path when a type has fallen out of use: prefer deactivating over deleting whenever the type has already been used in entries; that way the record disappears from new options and the past remains readable for audit and review.

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.

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