Entity Maintenance

See every customer, supplier, employee and merchant in one list, and create a record that is more than one of them, such as the agent you both buy from and sell to. A record with none of the four flags appears in no type-specific applet, only here, which is how records go missing without being deleted.

Overview

Entity Maintenance is the type-agnostic view of BigLedger’s entity master. Every customer, supplier, employee and merchant is one row in the same entity master with four flags — customer, supplier, employee, merchant — and this applet is the one place where you can create a record with any combination of those flags, or see all of them in a single listing regardless of type. The dedicated applets (Customer Maintenance, Supplier, Employee Maintenance, Merchant) edit the same rows through a richer, type-specific form.

Nothing forces a record to carry exactly one flag. A record can be both a customer and a supplier, or both a customer and an employee, and this applet is the only screen that will create one — the freight agent you buy from and sell to, or the staff member who also holds an account. A record can also carry none of the four flags at all: it still holds a name, addresses and contacts, but no type-specific applet will list it, and this screen is the only place it is visible. That is how records go missing — not deleted, just untyped.

It is opened by master-data administrators who need the cross-type view (for example, to turn an existing customer into a supplier as well), and by whoever maintains the four category trees — Entity, Customer, Employee and Supplier categories — that the type-specific applets tag their records with.

Where it fits

Modules: Core, Purchasing, HR & Payroll, Claims.

Screens and menus

Left menu:

Gear (Settings) menu: Field Settings and Default Selection under System Configuration. Webhook, Feature Visibility and the shared Permission Set / User / Team / Role listings also exist but are not listed in the settings menu; they are reachable only by typing the URL. Personalisation offers a per-user Default Selection.

Entity listing

Columns: Entity Name, Entity Ext Type (the type flags joined — for example CUSTOMER, EMPLOYEE), Entity Type (CORPORATE / INDIVIDUAL), Currency, Status, Creation Date, Modified Date; newest modification first. The advanced search offers a keyword (matched against the name and the customer / supplier / employee / merchant codes), Entity Type, Status and a Modified Date range. The + button opens the create form; clicking a row opens the edit form.

Create form

A single Main tab. CREATE is enabled only while every required field is valid (see Fields).

Edit form

Tabs, in order: Main, Entity Category, Login, Payment Config, Tax, Address, Contact, Intercompany Branch, Company Linking, Remark, Credit Term and Limit (with inner Credit Term and Credit Limit tabs). There is no Branch tab.

How the tabs save differs, and it matters:

• Update (header button) saves the Main tab, the Remark, and every row you added on the Tax, Address and Contact tabs — those tabs only stage rows in memory until you press Update.
• Payment Config, Company Linking and Intercompany Branch save immediately through their own services when you press Add / Save inside the tab.
• Entity Category, Login, Credit Term and Credit Limit have Add / Save buttons that persist nothing (see Lifecycle and effects).
• There is no delete: the edit form has no Remove button.

Category screens

Each of the four category menus is a listing (Category Code, Category Name, Level Value, Type, Creation Date, Modified Date, Status; keyword search plus Status and Modified Date filters) with a create panel (Category Code, Category Name, Description — all mandatory — and an optional parent picked from the existing tree) and an edit panel that adds Status. The first time a category of a given kind is created the applet also creates the list it belongs to.

Configuration

Before you can use it

• Companies and branches in the Organisation applet — Company Linking picks companies; Intercompany Branch picks a branch and derives its company.
• Tax codes in Tax Configuration — the Tax tab lists the tax types and codes of the chosen country; with no codes for that country the Tax Type list is empty.
• Settlement methods in the Cashbook applet — they are the Payment Type options on Payment Config.
• Entity code prefixes — this applet never sends a customer / supplier / employee / merchant code, so the backend generates one for every flag that is set, from the CUSTOMER_ID / SUPPLIER_ID / EMPLOYEE_ID / MERCHANT_ID running numbers plus the tenant’s per-type prefix. Set the prefixes before you create entities if you want codes like C000123.

Applet settings

Settings live in two applet-local screens — Field Settings and Default Selection — plus a per-user Default Selection under Personalisation. None of them is functional, and nothing in the applet reads any applet setting:

There is no working applet setting. If you need hidden fields, mandatory-field switches or default currency / country / credit terms, they exist in Customer Maintenance and Employee Maintenance, not here.

Document behaviour settings

Not applicable — this is a master-data applet with no document statuses, posting or printables.

Feature visibility / permissions

• Client-side permissions: the applet defines and checks no client-side permission codes. The Feature Visibility route is the shared Manage Team Access screen only.
• Server-side permissions: the Permission Set / User / Team / Role routes are the shared containers; permission targets can be any of the Applet, Branch, Company, Currency, Customer, Employee, Entity, Entity Login, GL Code, Label / Label List, Location, Merchant, Settlement Method, Supplier, Tax Code, Team and Tenant lookups.

Fields

Create — Main tab

Entity Name and Description are plain text of up to 255 characters. The form will not create a record without a name; Description is optional. Three things about them are not on the screen:

• The name is not unique, and nothing checks it. The form requires a name, but neither the form nor the server’s entity checks compare it with other records, so a second record called GadgetSphere Trading is accepted without a word. Each gets its own generated code, so everywhere else the two look like different customers, with balances and statements split between them. This is read from the code, not tried. Checking for a duplicate is the job of whoever creates the record, and it takes ten seconds: before CREATE, type the name into the listing’s search box. If a record comes back, open it and add the extra role (customer, supplier, employee or merchant) under Type instead of creating a second record. One record carrying several roles is what this applet is for.
• Renaming a record does not rename documents already raised. A document keeps its own copy of the name, taken when the customer or supplier was picked. The sales invoice screen, for one, copies it in at that moment, and the purchase order print and the document view read that copy, not the record. Saving a new name here changes the documents you raise from now on. Earlier invoices keep the old name, on screen and when reprinted. If a customer needs a document in its new name, that means a new document, and your accounts team decides whether to raise one. Nothing here does it for you.
• Description is searched but not shown. The listing has no Description column, but its keyword search looks in Description as well as the name, codes and ID number. That makes it a good place for something people search by and would not otherwise see, such as a former trading name or the group a company belongs to. This too is read from the code, not tried: put a word in one record’s Description, search for it, and confirm the record comes back before your team relies on it.

Edit — Main tab

The same fields plus Tax Registration Number (label changes to Company Tax Registration Number for CORPORATE), Phone Number, Email (both max 255, no format check), and read-only Created By, Creation Date, Modified By, Modified Date. Picking INDIVIDUAL defaults Identity Type to IDENTITY_CARD when empty. The Currency field is shown and marked required, but Update does not write it back — currency can only be set on create (see Troubleshooting).

Edit — other tabs

The Credit Term and Credit Limit listings read credit-term / credit-limit records that nothing in this applet writes; credit control is maintained in Customer Maintenance.

Lifecycle and effects

This applet writes master data; nothing here posts to the ledger or moves stock.

• The AR / AP type is supplied once, and only when blank. The backend fills it with AP_TRADE when the supplier flag is on and AR_TRADE otherwise, on create and on update, but only if the value it is handed is empty. Ticking a second flag later never revisits it — a record created as a customer stays AR_TRADE for its purchases too, and nothing on the screen warns you. Check the AR / AP type by hand every time you tick a new flag on an existing record.
• Codes are rewritten on save. Any customer, supplier, employee or merchant code sent is upper-cased, trimmed and stripped of every space before it is stored.
• Status is ACTIVE or INACTIVE in this applet’s forms; the backend also accepts TEMP, which the sibling applets can set. Changing the status is a normal Update — no other effect is triggered.
• Create saves the header with its currency, ID number and tax registration number. The backend requires a status, an Entity Type of INDIVIDUAL or CORPORATE and a default AR / AP type, then generates the per-type codes for every flag that is set. Because the applet sends no codes, the …CODE_SHOULD_NOT_BE_SET and …CODE_ALREADY_EXISTS rules cannot fire from here.
• Update first re-reads the entity to copy the current revision of the header and of every extension and line, then saves the whole record. Each address, contact and tax row is validated for its parent, status and revision (ENTITY_EXT_OBJECT_*, ENTITY_LINE_OBJECT_* errors). A success toast “The Entity has been updated” returns you to the listing.
• Payment methods are saved immediately; the backend requires the entity, a country code that exists, and — when given — an existing settlement method and bank.
• Company links are saved, updated and deleted immediately; the backend requires an existing company and entity. The client refuses to add a company that is already linked (toast “…is already linked to this entity”) before calling the backend.
• Intercompany branches are saved immediately; the backend requires an existing entity and branch.
• Logins: the backend requires both the entity and the login. The create panel never fills in the entity, so every attempt from this applet fails; the listing filters on a fixed entity rather than the open one and therefore never shows the open entity’s logins.
• Categories (all four menus) are saved as labels of the matching kind (ENTITY_CATEGORY / CUSTOMER_CATEGORY / EMPLOYEE_CATEGORY / SUPPLIER_CATEGORY), status ACTIVE, with an optional parent. The backend requires code, name, kind and status, an existing parent, and a code that is unique across every label in the tenant — the uniqueness check ignores the list and the kind.
• Tagging an entity with a category is not persisted by this applet: the Entity Category tab’s selection is sent to an action that nothing handles, and Update does not include it.
• No webhook or job is triggered from this applet’s code; the Webhook route is the shared configuration screen.

Related applets

• Customer Maintenance — the customer view of the same rows, with the working category, login, credit-term / credit-limit, e-Invoice and file-import features that this applet lacks.
• Supplier — the supplier view; uses the Supplier Category tree maintained here.
• Employee Maintenance — the employee view; uses the Employee Category tree maintained here and adds logins, branch / company linking and spending limits.
• Merchant — the merchant view (AR_MERCHANT / AP_MERCHANT).
• Organisation — companies and branches for Company Linking and Intercompany Branch.
• Tax Configuration — the tax codes offered per country on the Tax tab.
• Cashbook — settlement methods, the Payment Type list on Payment Config.
• Tenant Admin — the confirmed logins the Login tab verifies against.

Troubleshooting

Related documentation

• Core module · Purchasing module · HR & Payroll module · Claims module
• Customer Maintenance — the fullest description of the shared entity model and its settings