Core Concepts

“The invoice says RM 106. Why did the ledger only get RM 6?” Because nearly every value on a document, and everything that happens after you finalise it, was decided earlier in this module: some of it copied onto the document when it was raised, some of it read only when the journal is built. This page is for whoever traces a wrong figure, a missing journal or a hidden record back to the setup it came from. It explains how Core’s records feed every other module; which way to set them for a group is on Setting up a group.

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. The mapping that decides whether anything posts carries the arithmetic.

The mapping that decides whether anything posts

The company’s Default GL Codes tab — which lives in the Chart of Account applet, not on the company record — answers, once per company, “for this kind of movement, use this account”. There are 41 such roles across seven sub-tabs, and creating a company creates none of them. A brand-new company starts with the tab empty, nothing prompts you to fill it, and nothing stops you finalising a document before you have.

Entity roles throw an error that names the missing key. Item, tax, charge and stock lines resolve their account by falling back through line, header, item-company link and company default, and when none is found the line is simply omitted.

On a sales or purchase document the customer’s or supplier’s line is then built from what remains, so it absorbs the missing amount and the journal balances and posts: a RM 106 invoice with no sales code credits output tax RM 6 and debits trade debtors only RM 6. The document is FINAL, has a journal, and nobody is told; the only sign is the receivable or payable GL account drifting away from the ageing, which is built from documents and looks right. (Only when the customer or supplier has no AR/AP type, or nothing resolves at all, does the job fail instead — FINAL, no journal.)

A link that exists with an empty sub-ledger behaves the same way: the output-tax or input-tax line is dropped without an error, the customer’s or supplier’s line absorbs the amount, and your tax account is short. And month-end writes the cost-of-goods-sold journal only when COGS and STOCK_BALANCE are mapped, and the retained-earnings journal only when PROFIT_LOSS and RETAINED_EARNING are: a company missing both gets a close that completes with neither journal and no message.

Which roles to map, and the two pairs to check by name, are recommendations on Setting up a group › The mapping that decides whether anything posts.

An item is two records

Every stock-tracked item created as a Basic Item in Doc Item Maintenance is a doc item, the commercial record a document line picks (price, tax codes, e-Invoice classification), and an inventory item, the stock-keeping record the stock ledger, serial numbers and cost hang off. Creating a Basic Item in Doc Item Maintenance creates the inventory twin a moment later and links the two.

Code, name, tracking and EAN are copied to the twin once and drift apart afterwards; the one that bites is the barcode, because the till scans the doc item’s EAN and a stock take scans the twin’s. A service, a deposit or a delivery charge is a doc item with no twin, which is why it can sit on an invoice and never be counted; an item created in Inventory Item Maintenance alone is the reverse, counted and never on a document. Which record owns which fact is on Inventory Item Maintenance › The two records, and what each one decides.

A document line keeps a copy

A document does not point at its master data and read through it later. When you pick a customer, the document copies a block of the customer record: name, address, identity number, credit term and GL code among them. When you add a line, the line copies the item’s code and tax code and the tax code’s rate, and on a sales invoice the item’s e-Invoice classification.

So a correction to the customer, the item or the tax code reaches the next document, not one already raised, draft or final. Two exceptions: the AR/AP type is read when the journal is built (the table above), and merging one customer into another rewrites the copies on documents already raised. What is copied, what is read live and what a merge rewrites are on What a document keeps of the customer; the item’s tax code, on Maintaining the Item Master › Step 2.

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.

  Because nothing warns you that live documents still use a record, retire a company or branch by marking it Closed instead, and keep the delete right with an administrator.

• 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 routes only Purchase Orders and Purchase Requisitions (Stock Requisition has its settings and no submit step); Workflow Design defines status tracks enforced only on the document’s own screen, not an approval. 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 Blacklist Overdue Customer 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. When it runs it sets the stop flag, which orders, invoices, delivery orders and cash bills refuse, on every customer over their limit or past their company-level term — and it first clears every stop flag, hand-set ones included, so re-set those afterwards, or give a customer you mean to keep stopped a credit limit of 0, which every run re-flags while their net balance is above zero. So on a tenant where nobody has scheduled it, no customer is ever flagged automatically. Schedule it (daily, outside trading hours, is the recommended setup), and until it is 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 What success looks like.

• 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 you know it worked

The checks are on Setting up a group: post one test invoice and find its three-line journal (check 1), sign in as a test user in the branch role, and confirm the Blacklist Overdue Customer clock reads ACTIVE if you rely on it (the Scheduler Code to look for).

Read next

• Setting up a group — which way to set each of these records for a multi-company group, and the order to set them up in
• Chart of Accounts Setup — the job that builds the chart and the Default GL Codes the mapping reads
• Teams and permissions — the job behind Who can see what
• Maintaining the Item Master — creating an item, and the fields its first save locks
• When two numbers don’t tally — start here when a figure will not agree with another
• Core module — every applet these records live in