Master data and the multi-entity model

An entity in NOVERA is a company code paired with a catalog, and the signed-in entity is the only entity in play at any moment. Individual screens have no entity selector, because a second source for one fact is how two screens end up disagreeing. Switching is done from a single control in the header, which validates the requested entity against the user's own permitted list instead of trusting the form, never accepts a catalog name from the browser, and re-issues the authentication cookie with new claims. Where a switch would destroy unsaved work, the control arms first and names what will be lost, in the reader's own language.

Two rules make switching predictable.

• A period carries across entities and an account code does not, so a screen keeps the month or date range and drops the account.
• A switch lands the reader exactly where a fresh visit would land, because the entity is the only thing it is meant to change.

The account card is the system's master data screen, with eight tabs covering details, addresses, terms and banking, groups, analysis, periods and an AI setup assistant.

• Addresses carry the full set of real columns, with search by address or telephone; a hit in another entity is named and never silently opened.
• Terms cover bank details, credit limits and payment types.
• Groups hold the two statutory report references, written only by picking from the chart tree and never by typing a code, with the entity's country deciding which trees apply. A Slovak or Czech financial account cannot be saved until it carries both references, and the refusal names the missing one and offers a worked example.

The account lifecycle is complete.

• Create: from a blank template, in a single transaction that writes the account, its address and its banking together.
• Codes: generated by class, with distinct prefixes for creditors, debtors and employees and none for nominal accounts.
• Copy: within the entity or to another entity across catalogs, taking a fresh code from the destination's own generator and dropping statutory codes that do not apply there. The consequences are stated before the click.
• Delete: postings are counted first and never cascaded, and nineteen dependent tables are cleared before the account itself is removed.
• Change type: allowed through a whitelist re-checked inside the transaction.
• Change code: specified, not yet built.