Core Module

Core is the module you finish before any document is raised. Nothing in it sells, buys, ships or pays; it holds the records those documents point at — the company and its branches, the GL codes a journal lands in, the bank accounts money moves through, the tax codes a line carries, the customers, suppliers, employees and merchants (one entity table with four flags), the items, and the price books — and the two consoles that decide who may open which applet. Every other module reads this data when its documents finalise and post, and most of the failures that look like a sales or purchasing problem (a FINAL document with no journal because a default GL code is missing, a tax line silently dropped, an item nobody can pick) are something missing here.

One invoice, and everything it reads from here

You raise a sales invoice at GS-KV-01 for a corporate customer: one extended-warranty plan, RM 100 plus 6% service tax, RM 106. Nothing on the invoice screen says so, but nearly every value on it — and everything that happens after you finalise it — was decided in this module, earlier, often by somebody else. When a figure on that invoice looks wrong, the question is which record it came from and when it was taken:

Finalising does not write the journal: FINAL succeeds and a posting job builds the journal a moment later from the mappings above, so a missing mapping never shows at the Final button. An invoice that posted RM 6 instead of RM 106 looks right on every sales screen; the gap shows only when trade debtors stops agreeing with the ageing, which is built from documents. Setting up a group carries the arithmetic.

Applets in this module

Membership is an editorial judgement — the product has no module↔applet relationship in its data. Core owns 17 applets: the master-data applets and the two tenant-administration consoles. Sixteen have a reference page; one does not, and the end of this list says why. The Also serves column is the modules: assignment from the membership table: the module whose documented workflow cannot complete without this applet.

Your organisation, and who may use it

Money — where it is classified, held, taxed and converted

Who you trade with — one entity table, four flags

Every customer, supplier, employee and merchant is one entity record with four flags — customer, supplier, employee, merchant. The same person or business can carry more than one flag; the four typed applets are richer forms over the same row.

What you sell, and at what price

Workflow Design — listed, not promoted

Registry applet with no reference page yet

Applets owned elsewhere that core also serves

Two applets sit in the master-data folder or list core as a supporting module but are owned by E-Commerce: Shipping Pricebook (delivery charges the storefront evaluates at checkout — membership spec §5, A7) and Media Library Applet (tenant file drives). This page links them; their pages and the E-Commerce module page describe them.

Group Maintenance and Group Maintenance V2 are not installable applets and are not counted. Roles and who holds them are maintained under Tenant Roles in the Tenant Admin Applet.

The order a new tenant sets things up in

There is no setup wizard and no checklist screen. The order below is derived from what each applet’s own page says it requires before it can be used — every arrow is a prerequisite one page states, cited in that page’s Before you can use it table. Where two applets require each other, the page says which half comes first.

    flowchart TD
  TA["Tenant Admin<br/>rank OWNER / ADMIN · install applets · roles"] --> ORG["Organization<br/>Company → Branch → Location"]
  COA0["Chart of Account<br/>a chart (or the DEFAULT one)"] --> ORG
  ORG --> COA["Chart of Account, per company<br/>ledgers · Default GL Codes · fiscal year · set of books"]
  COA --> TAX["Tax Configuration<br/>tax codes"]
  COA --> CB["Cashbook<br/>cashbooks → settlement methods → branch links"]
  CB --> ORGB["Organization › Branch<br/>settlement, default pricing"]
  COA --> FX["Forex<br/>only for foreign-currency trade"]
  ORG --> ENT["Entity code prefixes, then<br/>Employee · Customer · Supplier · Merchant"]
  TAX --> ENT
  CB --> ENT
  TAX --> ITEM["Doc Item Maintenance<br/>pricing schemes · category groups · items"]
  COA --> ITEM
  ITEM --> INV["Inventory Item Maintenance<br/>auto-created from a Basic Item"]
  ITEM --> PB["Pricebook"]
  ENT --> PB
  TA --> WF["Workflow Design<br/>only if a status track is wanted"]
  ORG --> WF
  

1. Tenant Admin first. You need rank OWNER or ADMIN on the tenant to open it at all; from there applets are installed for users, tenant roles are created, and permission sets are targeted at companies, branches and locations — which is why the Organization page lists applet installed and server-side permissions granted as its own first prerequisite. A permission target has to be a company or branch that already exists, so you will come back here after step 3.
2. A chart of accounts before the company. Create Company requires a chart; the + beside the field creates one coded DEFAULT if you have none. Sections, categories and codes can be built or imported before or after — but nothing can be mapped until the company exists.
3. Organization: Company, then Branch, then Location. Creating a company also creates its CORPORATE entity, its PRIMARY ledger in the company currency and the stock-in-transit location. It does not create default GL codes, a branch, knock-off rows or a cashbook — each of those is a later step. A branch can create its default location for you.
4. Back to Chart of Account for the company. Map Default GL Codes — the posting job that runs after a document goes FINAL throws MISSING_DEFAULT_GL_CODE: <type> for any type the document needs that is not mapped, leaving a FINAL document with no journal — create a fiscal year covering today (documents are validated against the period of their transaction date), and a set of books if you want financial reports. The page’s own order: verify the company → ledgers → codes → default GL codes → set of books → fiscal year.
5. Tax codes. The applet itself needs nothing, but its codes are useless until the company’s OUTPUT_TAX and INPUT_TAX default GL links exist with a subledger — without them the tax line of every journal is dropped without an error and the customer’s or supplier’s line absorbs it, so the journal posts with your tax account short. Once codes exist, the Organization company Tax tab picks the default sales and purchase code.
6. Cashbooks, then settlement methods, then branch links. A cashbook needs a company and a GL code in that company’s chart (the backend rejects a mismatch); settlement methods need a cashbook; the transaction applets filter settlement methods by the branches linked to them. Only then can Organization › Branch › Settlement link them to a branch.
7. Forex, only if you trade in foreign currency. Both currencies must be in the tenant currency list and the company base currency set; the pair only appears on a document applet whose SHOW_FOREX_DATA_SOURCE setting is on (off by default), and settlement needs FOREX_GAIN / FOREX_LOSS mapped in step 4.
8. Set the entity code prefixes, then the people and businesses. The typed applets generate customer / supplier / employee / merchant codes from a running number plus the tenant’s per-type prefix — there is no screen for the prefix today (the Supplier applet’s control is commented out), so ask BigLedger to set it before the first record if you want codes like C1000000 (the prefix, then a plain running number from 1,000,000 — no zero-padding) — see Document numbering. Then: employees (the create form requires a branch; a login link needs the person to have accepted an invitation first) — before customers if you want a default sales agent on the customer; customers (receivable GL code from the chart, tax codes, credit terms and limits created in the applet, a category group bound to each category slot in its Application Settings); suppliers (payable defaults, tax codes, categories; self-billed e-Invoicing needs the company enabled in Organization); merchants (a contract company, tax codes, GL codes with subledgers for the merchant branch control account, settlement methods for Payment Config).
9. Items. Doc Item Maintenance needs tax codes, GL codes, companies and branches, and its own pricing schemes and category groups bound to slots before prices or categories can be entered. A Basic Item creates and links its inventory record; an item created directly in Inventory Item Maintenance has no doc item and cannot appear on a document until one is linked. Per-location min / max levels need the locations from Warehouse Management (Inventory module).
10. Price books last — they match on items, categories, pricing schemes, customer and employee categories, companies and branches, and member classes from Membership Admin. Nothing is applied until Default Selection → Default Pricebook is set in POS General, Sales Invoice, Sales Order or Sales Quotation.
11. Workflow Design, if at all. It needs roles with users (a transition with no Role row is invisible to everyone) and a company; a process that is never linked to a company and an applet is inert. It is not where approvals are configured.
12. T2T Admin is not part of first setup: it needs a second, existing tenant with a registered database connection, and companies, branches and items on both sides before anything can be mapped.

What posts, and what does not

    flowchart LR
  MD["15 master-data applets<br/>write ACTIVE / INACTIVE rows<br/>soft delete · no signum · no journal · no stock"] -.read at FINAL.-> DOCS["Documents in every other module"]
  CT["Cashbook › Cash Transfer<br/>INTERNAL_CASH_TRANSFER"] -->|"FINAL: journal + cashbook lines + PD cheque queue<br/>VOID: all three reversed"| GL["General Ledger"]
  CA["Cashbook › Cash Adjustment<br/>INTERNAL_CASH_ADJUSTMENT"] -->|"FINAL: cashbook transaction lines only<br/>no journal"| CBL["Cashbook balance"]
  

• Master data posts nothing. Organization, Chart of Account, Tax Configuration, Forex, the five entity applets, the three item and pricing applets, Workflow Design, Tenant Admin and T2T Admin have no server document type, no amount or quantity signum, no journal rule and no open-queue rows. They write rows that documents in other modules read at FINAL. Chart of Account is the nearest thing to an exception: its Opening Balance writes a journal on the primary ledger, its Remove Journal hard-deletes journals, and its fiscal-period locks decide when posting is allowed at all.
• One document in this module posts. Cashbook’s Cash Transfer (INTERNAL_CASH_TRANSFER, DRAFT → FINAL → VOID) queues journal posting, cashbook transaction lines and the PD cheque queue at FINAL, and reverses all three at VOID: Dr the To cashbook GL (and charges GL), Cr the From cashbook GL, one journal line per transfer line. Cash Adjustment (INTERNAL_CASH_ADJUSTMENT) writes cashbook transaction lines only; the journal processor returns without posting for that type. The posting proof is on the Cashbook page.
• Deletes are soft, and mostly unchecked. Every master-data delete in this module found in code sets status = 'DELETED' and leaves the row. No validator checks whether documents still reference a company, branch or location (Organization) or a forex data source (Forex), so a deleted record disappears from pickers while its documents keep the guid. A GL code is the exception: its delete is refused once a journal line carries it (a voided document’s journal counts) or an item, a cashbook or a company default GL code links it — set it INACTIVE or merge it. The one hard delete is Chart of Account’s Remove Journal.
• Tax rates and forex rates are snapshots. A document line copies the tax code’s rate when it is saved, and a document copies the latest forex rate when the source is picked; changing either here afterwards does not restate anything already saved.

What this module has no engine for

Each of these is a job the product leaves to a person. The sentence after each says whose, and when.

• No approval on master-data changes. The generic document approval engine exists only for Purchase Order, Purchase Requisition and Stock Requisition; Workflow Design is a status catalogue that no lifecycle consults. Who may change a credit limit, a GL code or a supplier’s bank account is decided by permissions in Tenant Admin, not by a sign-off. So the control is separation of duties, and it is yours to design: keep edit rights on customers, suppliers and the chart in a small role that does not also raise invoices or release payments, and review who holds it whenever somebody joins or leaves. A supplier’s changed bank account is the one to check by hand — against a letter or a document from the supplier, before the next payment run, by someone other than the person who changed it.
• No save-time credit gate here. Customer Maintenance stores the credit term, credit limit and a credit status (OK / BLACKLISTED); whether a sale is stopped is a property of the document applets. The one server-side credit-control mechanism is a batch job — it never runs when a document is saved. And it does not run on its own. The job is ENTITY_BLACKLIST_CUSTOMER_PROCESSOR in the Scheduler applet’s processor picker and ships with no schedule: it does nothing until somebody gives it one there, or runs Blacklist Overdue Customer on demand. So on a tenant where nobody has scheduled it, no customer is ever flagged automatically. Check yours before you rely on it, and if it is not scheduled, credit control is a person’s job with a report behind it: whoever releases large orders reads the customer’s balance and ageing before releasing one, and the credit limits guide says what each of the three mechanisms actually stops.
• No tax-to-GL mapping on the tax code. A tax code has no GL field; the account comes from the company’s OUTPUT_TAX / INPUT_TAX Default GL Code links. Whoever sets up a company maps them, once, per company — and confirms it with the test invoice under How you know it worked.
• No engine applies a price book on its own. The sales applets and POS evaluate the price book named in their Default Pricebook setting in the browser, and the OCR points processor evaluates one on the server; the Pricebook applet only stores it. Whoever sets up a till or a sales applet points it at the book, and rings one qualifying item to see the price change.

Who can see what

Every permission is granted to a role (or a user), and a grant can carry a target — a company, a branch or a location — set through Permission Wizard, Permission Set or Role Permission in the Tenant Admin Applet. Four rules decide almost every “I cannot see it and my colleague can”:

1. A target scopes documents, and not much else. A document is visible where the user is permitted at its company, its branch or its delivery branch. Scoping a listing is opt-in per listing, most other listings apply no target, and a target does not limit which company or branch record a role may edit — Tenant Admin → what the target actually does. Treat targets as a control over whose documents a person sees, not over who edits the organisation.
2. A grant with no target named on it is full access, not no access — Stock shows zero → your search was quietly narrowed.
3. Where a target applies, it narrows the answer rather than refusing the request. Stock Availability, for example, cuts the companies and locations you asked for down to the ones your grant targets and runs on what is left; it refuses only when nothing is left, and it never says what it removed. So a short list and a missing permission look identical, and the question to ask first is which role are you in, not what is wrong with the data.
4. Tenant owners and administrators pass every check. Users or roles holding TNT_TENANT_ADMIN / TNT_TENANT_OWNER see everything, which is why the person investigating usually cannot reproduce the problem from their own login. Test as the person, or as a test user in their role.

For GadgetSphere that means one Branch Supervisor role with 22 branch targets, not 22 hand-built permission sets that drift apart within a quarter: correct the role once and every supervisor follows.

This module’s screens are guarded on the server (API_TNT_DM_*, TNT_API_TAX_CODE_CFG_*, TNT_API_DM_WF_MD_*, T2T_*, the price-book and forex codes). The Tenant Admin Applet itself is gated by rank (OWNER / ADMIN), with role assignment also needing a tenant-database permission.

A few applets also have client-side SHOW_* permissions, which let a role keep a menu or tab the tenant has hidden: Customer Maintenance (menus and edit tabs), Doc Item Maintenance (the Costings tab, cost columns and category grids), Cashbook (eight of the eleven menus it checks) and Inventory Item Maintenance (two Trace Serial No columns). The other core applets register none. One trap: Supplier checks ten codes that are not seeded, so its HIDE_* switches hide for everyone, administrators included. Each applet page is the source for what its codes gate.

How this module connects to the others

What must exist before it. Almost nothing: a tenant, and someone of rank OWNER or ADMIN to open the Tenant Admin Applet. Inside the module the order is strict, and the setup order above gives it; two prerequisites sit outside core: the locations from Warehouse Management that per-location stock levels depend on, and the member classes from Membership Admin, if a price book matches on them.

What becomes possible once it is done. Every document in every other module. Once a company has its Default GL Codes, a fiscal year and its knock-off pairs, its sales, purchase and stock documents post, lock by period and chain into each other; once a role has its targets, a branch can be handed to the people who run it.

Siblings, and when to use which.

• Entity Maintenance or a typed applet? Use Customer Maintenance, Supplier, Employee or Merchant Admin to create and edit; use Entity Maintenance to see everyone in one listing and to maintain the category trees. Four of Entity Maintenance’s tabs save nothing.
• Doc Item or Inventory Item Maintenance? Create items in Doc Item Maintenance as a Basic Item: it creates the stock record for you. An item created only in Inventory Item Maintenance has no doc item and stays off every document until one is linked.
• Workflow Design or Approval Settings? Approval Settings, on the three purchasing and requisition documents that have them, if you want a document held until somebody approves it. Workflow Design only adds a status track.
• A second company or another branch? A company is a legal entity with its own chart mapping, fiscal year and knock-off rows; a branch is a slice of one. Setting up a group argues it through for a retail group.

What breaks elsewhere when something here is wrong.

• An entity’s AR/AP type decides the control account for every document with that entity, in every module — wrong, and its balance sits on the other side of the balance sheet with no error.
• A company’s Default GL Codes decide every journal its documents produce, in every module.
• A company’s knock-off rows decide whether a finalised order leaves anything for the next document to find. Documents finalised before the row existed stay unlinked until somebody re-queues them.
• A deleted company, branch or location disappears from pickers while its documents keep it, because the delete is soft and nothing checks for documents first.
• A role’s targets decide which branches’ documents every person in that role sees, in every module, and what the target-scoped reports such as Stock Availability return.

What it pairs with in practice. The Scheduler applet, because several things this module stores only take effect when a clock runs a job (the credit sweep above is one). Financial Report › Error Checking, which is where a document with a missing journal shows up. And the Data Fix applet, which re-queues documents finalised before their knock-off row existed.

When it goes wrong

A core problem almost always arrives as a complaint about another module. The cause is usually one record here that nothing on the complaining screen shows.

How you know it worked

Ten minutes per company, once setup is done and before anybody else is let in. For GS, at GS-KV-01:

1. Finalise a test invoice and find its journal. Use a service item, RM 100 plus 6%. Give the posting job a moment, then open the invoice’s Trace Document tab and its Journal grid. You want three lines: trade debtors debited RM 106, the sales code credited RM 100, output tax credited RM 6. Debtors at RM 6 means the sales mapping is missing; an empty grid usually means the receivable mapping or the customer’s AR/AP type is.
2. Prove one knock-off pair. Finalise a sales order, open a new sales invoice, and look in Search Document: the order is there.
3. Sign in as a test user in the branch role. In Stock Availability their location picker should offer only GS-KV-01’s locations, and the report should cover only those. If they are offered every location in the group, a permission set in that role has no target.
4. Open the Scheduler listing. If you rely on the credit sweep, the row for the Blacklist Overdue Customer job (the processor named in the credit bullet above) reads ACTIVE.

Four checks per company, three companies, and you hand over a tenant whose gaps are known rather than discovered. Setting up a group → What success looks like adds the period-lock and opening-balance checks.

Related documentation

Deeper pages in this module — written from the schema and the backend, for the things every tenant uses and no applet page owns:

• Setting up a group: what we recommend — the opinionated layer over the setup order: how a multi-company Malaysian retail group should actually configure this, with the cost of each recommendation and the shape of business it suits

• Document numbering — where every running number comes from: one counter table, three numbering levels, no gaps, and what you can and cannot change

• Printable formats — the uploaded template behind every printed document, the per-branch default, and the four rules by which screen, e-mail and e-Invoice each pick a layout

• Sign-in options — e-mail or mobile with a password, Google, Facebook, Apple; how each is checked, how an invitation becomes a sign-in, what MFA does and does not do

• When a figure will not agree with another, start in Guide, not here: Troubleshooting → When two numbers don’t tally — by symptom, each with a thirty-second check, and one page behind them on which figures BigLedger stores and which it works out fresh.

• User guides that begin in this module: Chart of Accounts Setup and, for the approval question this module keeps getting asked, Document Approvals.

• The modules that read this data: Financial Accounting, Sales, Point of Sale, Purchasing, Inventory, E-Commerce, E-Invoice, Claims, Membership.

• The membership judgement behind this page is editorial; the platform tools (Developer Sysadmin and its siblings) that belong to no module are listed there under §6.