Master Data
Every sales invoice finalises, but none of them post, and the trace names a missing default GL code. That sentence is the commonest way a reader meets this folder, and the invoice applet is the wrong place to look for the cause. Nothing here writes a journal, moves stock or sends an e-invoice: these sixteen applets hold the records every document reads — the company and branch it is tagged with, the account its customer posts to, the price and tax code its lines start from, the identity LHDN is told about — and a mistake made here is reported somewhere else, minutes or months later, usually to somebody who did not make it. This page is for whoever sets a tenant up or inherits one: which applet owns which record, which values a document copies and which it reads live when it posts, which of two look-alike records to create, and how to tell a new company, customer or item is actually usable.
The page routes; each row links to the page that proves it.
What each record feeds, and whose screen it is
| Applet | Whose screen | What a document takes from it | Where it stops |
|---|---|---|---|
| Organization | The tenant administrator, once | Company, branch and location on every document header; at FINAL, the company’s Knock Off Configuration, e-invoice status, skip flags, the branch default location and the timezone | The company’s Default GL Codes are mapped in Chart of Account, not here. The tree divides documents, not master data: customers, suppliers, items and prices are one list for the whole tenant |
| Chart of Account | Finance administrator at setup, the accountant at month end | The GL codes every journal lands in, and per company the Default GL Codes (41 keys) the posting job reads after FINAL; fiscal-period locks | A missing key is discovered after FINAL: the document is FINAL with no journal and Trace Document reads MISSING_DEFAULT_GL_CODE |
| Tax Configuration | Finance administrator, when a statutory rate changes | The line-level tax drop-down and the rate stamped onto the line when the document is saved; the line keeps its own copy | It does not decide the account: that is the company’s OUTPUT_TAX / INPUT_TAX default GL code. A mapping with no sub-ledger drops the tax line without a message |
| Cashbook | Finance administrator sets up; cashier and clerk pick from it daily | Every place money is held and every settlement method a receipt, payment, till or bank reconciliation can choose; a settlement line resolves to its cashbook’s GL code when the cashbook job runs after FINAL | A settlement method with no cashbook, or a cashbook with no GL code, fails that job, not the save. Cash Transfer posts a journal; Cash Adjustment writes cashbook lines only |
| Forex | Finance administrator, each day a foreign-currency document is raised | The newest recorded rate of the pair, copied once onto the document’s Currency Rate when the pair is picked, whatever the document’s date | It posts nothing. The foreign-currency document’s books are posted from its company-currency twin; there is no period-end revaluation run |
| Customer Maintenance | Sales admin onboards; credit control sets terms and limits | A block copied onto each sales document when it is raised — code, name, addresses, GL code, identity, credit term and limit — and an AR/AP type read live when the journal is built; the e-invoice falls back to that copy for the buyer and reads this record’s identity for the TIN lookup | The credit limit is a check in the Sales Order and Sales Invoice screens plus the blacklist job; a cash bill and a document arriving by API are not measured. Its Item Pricing tab’s sales half is read by no sales screen |
| Supplier | Procurement onboards; finance sets payment terms | The AR/AP type the payable account is chosen by at posting (the Company Linking row first), a default purchase price per item, the issuer block for self-billed e-invoices, the Peppol IDs, and the same copied name-and-address block | A supplier’s credit limit and terms are recorded and displayed; nothing reads them at posting |
| Employee Maintenance | HR or whoever onboards staff | The salesperson slot on a sales document (ACTIVE records only) and the commission posted from it; the claimant on claims; the person payroll attaches a salary to; the identity block on a self-billed e-invoice | It holds no salary, records no leave, and Report To is read by nothing outside the applet |
| Merchant Admin | The platform or finance administrator onboarding outside sellers | Payment-gateway merchant code and key (the key is copied onto each payment transaction when it is created), Peppol IDs, contracts and rate cards the monthly merchant report job reads | It is for external businesses; your own companies live in Organization. Remove deletes a merchant without checking for contracts or transactions that point at it |
| Entity Maintenance | The master-data team | The one list of every customer, supplier, employee and merchant — they are one record with four flags — and the category trees the typed applets use | A record with none of the four flags appears here and in no typed applet; the Entity Category tab’s selection is not saved from here |
| Doc Item Maintenance | Merchandising or purchasing for stock; accounts for account-code and service items | Every document line: unit, tax code, the pricing-scheme price, categories, the e-invoice classification, and the item’s company GL link (third in the posting precedence). Creating a Basic Item queues the creation of its inventory record | A blank e-invoice classification stops nothing and is submitted as 022 Others. Item type and quantity-tracking mode lock at the create screen’s auto-save |
| Inventory Item Maintenance | The warehouse or inventory controller | The record stock ledgers, balances, serial numbers and costing are keyed on; alternative units, per-location min/max, serial imports | As read for its page, the item editor’s own Save never enables, so day-to-day edits to an item are made in Doc Item Maintenance |
| Pricebook | The pricing administrator | Price sets that POS, Sales Invoice, Sales Order and Sales Quotation evaluate when a line is added, from the price book named in each applet’s Default Pricebook setting | Five engines, and they disagree: the till reads a set’s first treatment only and ANDs its rules; the sales documents OR them. The price book’s Status is read by nothing that prices a line |
| Shipping Pricebook | E-commerce or logistics administrator | The shipping methods the CP Commerce storefront offers at checkout and the fee it writes as a service-item line, computed in the shopper’s browser | Nothing in the back office evaluates it, and the storefront ignores its Status flag — delete a book to withdraw it |
| Workflow Design | Tenant administrator, once per company | A status track a document applet attaches per company, and the status that lets its FINAL button show | Enforced in the browser only; an API client may set any status. It is not the Document Approval engine, and its transition actions and subscribers are executed by nothing |
| Group Maintenance | Platform administrator | A named, flat set of logins a permission screen can name instead of each user | Not installable today — its registry row is DELETED; groups themselves are real |
Copied when the document is raised, or read when it posts
The question behind most master-data surprises is when a document looks at the record. There are two answers, and the same record gives both.
Copied, once. When a customer or supplier is picked, the applet writes a block of the record onto the document — code, name, addresses, contact, GL code, identity number and type, credit term and limit — and the server fills that block only when it arrives empty. Nothing refreshes it. So a correction here reaches the next document, a reprint of last year’s invoice still shows last year’s address, and that is the design: an invoice is evidence of what was agreed (what a document keeps). The one path that rewrites those copies is an entity merge, which refreshes every document that points at the surviving record (entity merging).
Read live, every time. The AR/AP type is not in the copy. When the journal is built after FINAL,
the posting job asks the entity master for the type — the Company Linking row’s value for the posting
company if there is one, else the record’s own — and maps it to the default GL key: AR_TRADE to
DEBTOR, AR_OTHER to DEBTOR_NON_TRADE, AP_TRADE to CREDITOR, AP_OTHER to CREDITOR_NON_TRADE,
and the merchant and employee types to their own payables and receivables. Two things follow. A
customer created first and later ticked as a supplier keeps AR_TRADE, because the type is filled
once, when blank, and never revisited — so its purchase invoices post into your debtors, and the
only sign is a supplier balance sitting inside receivables. And correcting the type moves the account
for every posting from then on, including a Repost of a document raised before the change
(how the AR/AP type reaches a GL code).
Checking the type before the first document is a person’s job: whoever approves a new customer or
supplier record, on the Main tab and on its Company Linking row.
Where the other numbers on a document came from, in one line each:
| Figure on the document | Comes from | When |
|---|---|---|
| The price a line started at | The pricing-scheme row for the item — the branch’s default scheme, or the customer’s own scheme when one is set and the item is priced on it; the row is recorded on the line as the one thread back to a price list | When the line was added (the price on a document line) |
| The tax rate on a line | The tax code’s transaction rate, copied onto the line; the same rate can also sit on the item and on the pricing-scheme link, and changing it in Tax Configuration changes the code only | At save, when the line carries a code and no type; otherwise the line keeps what the item or the picker gave it (how a document picks the rate up) |
| The exchange rate | The pair’s newest recorded rate, whatever the document’s date | When the pair was picked; never re-read (Forex) |
| The buyer LHDN is told about | The document’s own e-invoice buyer block when one is filled, else the customer copy the document took when it was raised; the TIN lookup reads the identity type and number on the customer record, not on a member card | When the e-invoice record is built after FINAL (why your buyer has an applet of their own) |
| The unit cost on a finalised line | Not master data at all: the costing job writes it back onto the line after the stock line exists | After FINAL (what happens when you press Save) |
Which one to pick
| You want to | Use | Rather than |
|---|---|---|
| Run a second operation of the group | A branch, if the two operations file one return; a company only when the law makes it a separate legal entity, because a company commits you to a second chart, a second set of default GL codes and a second e-invoice registration (a second company, or another branch?) | A company because the operation feels big enough — the costly direction, maintained twice for ever |
| Keep two brands or a joint venture from seeing each other’s customers | A separate tenant. The customer, supplier, item and price lists are tenant-wide; a branch-scoped login still browses the group’s whole customer list, and the only scope that refuses is the export (what the organisation tree does not divide) | A second company, which divides documents and nothing else |
| Deal with a business you both buy from and sell to | One entity record with both flags — created with both in Entity Maintenance, or given the second type on the Main tab of Customer Maintenance or Supplier — and then set the AR/AP type by hand, because it was filled from whichever flag came first | Two records, which split the balance you want to contra |
| Give members, retail and wholesale different prices | A pricing scheme per list: it is the mechanism nearly every group runs on, and the scan path reads nothing else. A price book is the promotion, tier or date window laid on top (pricing schemes) | The customer record’s Item Pricing tab, whose sales half no sales screen or till reads — it is honoured when you buy, not when you sell |
| Describe what you sell versus what you count | Doc Item when the answer changes what a document says — price, tax, classification; Inventory Item when it changes what a count says — units, location levels, serials (which record are you editing?) | Looking for a sellable price or a tax code in the inventory record, which has neither |
| Decide where tax posts | The company’s OUTPUT_TAX and INPUT_TAX default GL codes in Chart of Account, each with a sub-ledger | A field on the tax code, which has no GL field |
| Put an approval in front of a document | Document Approval settings in the purchase order, requisition and stock requisition applets; a Workflow Design process is a status track whose one real effect is when the FINAL button shows (the one real gate) | A workflow transition with an action or a subscriber, which nothing executes |
| Set up a partner who sells or collects payment through you | Merchant Admin — an entity with gateway credentials and a contract | Organization, which is your own companies and branches |
| Give a buyer the tax number their e-invoice needs | Before the first invoice: the identity type and number on the customer record. After FINAL: the e-invoice side — the Portal if the buyer has a login and the receipt is this month’s, My E-Invoice Admin for everything else; both write back to the customer record, and the Portal’s Submit replaces the customer’s whole address book with the one address typed (when two applets seem to do the same job) | Keying the IC onto the member card, which the e-invoice never reads |
The customer-and-supplier row is the one that costs real money when it is missed. Across BigLedger nearly every record carries the type its first flag implies, and a record flagged both ways is unusual — a couple of them in a list, where there are any. The two shapes that go wrong are rarer and real: a customer-flagged record typed as a payable, or a supplier typed as a receivable, turns up as a handful of records in a group’s list more often than you would expect — and a bulk load with the wrong column has done it by the thousand, which is the one way to make many at once. Rarer still, and worse, is a record with no type at all, and few customer lists are without one: a document raised on it posts no debtor or creditor line, so the journal does not balance and the posting job refuses it, and the document stays FINAL with no journal (the AR/AP type is decided once).
When a master-data mistake shows up somewhere else
| What you see | Why | What to do |
|---|---|---|
Invoices are FINAL with an empty Journal Txn grid; Trace Document reads MISSING_DEFAULT_GL_CODE: DEBTOR (or CREDITOR, OUTPUT_TAX, …) | The company’s default GL code for that key is not mapped — in a group, usually the second or third company | Map it under Chart of Account › Companies › Default GL Codes, then Trace Document › Missing Journal › Resolve (Chart of Account troubleshooting) |
| A supplier balance is sitting inside trade debtors, or a supplier’s bills are missing from the creditor reports | The record was created as a customer and typed AR_TRADE; ticking Supplier later changed nothing | Correct the AR/AP type on the Main tab and the Company Linking row, then Repost each document (a worked month) |
| Last year’s invoice still shows the customer’s old address after you corrected the record | The document keeps the copy taken when it was raised | Nothing. Correct one document on the document itself if it must be reissued; the master is for the next one |
The customer listing has rows with status TEMP and no name | Each is a customer somebody started and never finished — the record exists from the moment New is pressed, and the sweep that would tidy them is a scheduled clock that is off unless somebody switched it on | Open it; finish it if it is yours (the first complete save promotes it), otherwise delete it (scenario: the unfinished customer) |
| A new item saves but the till cannot find it, or prices it at zero | It is not Active, the scheme the branch reads has no price for it, or its inventory record has not been created yet by the queued job | The five-step check on how you know it worked |
| A finalised invoice or GRN never changed the stock balance | The document item is not a stock item — a service, or an alias that points at no inventory item — so it posts its sale and moves nothing. An unlinked basic item is linked for you when it posts | Fix the item in Doc Item Maintenance, then ask support about the documents already finalised (Inventory’s related applets) |
| You set a price for this customer and the sales order still uses the scheme price | The Item Pricing tab’s sales half is read by purchase orders and replenishment only | Put the price on a scheme the customer is on, or in a price set that names the customer |
| You changed a tax rate and the invoice still charges the old one | The rate is copied onto the item, the pricing-scheme link and each saved line; Tax Configuration changes the code only | Re-save the item’s pricing link and re-pick the code on open lines (how a document picks the rate up) |
An e-invoice line went to LHDN as 022 Others | The item’s e-invoice classification was blank, and the payload builder filled it with no error | Classify the item; the submitted record is the only place the substitution shows |
| A customer’s delivery address has vanished | The buyer completed their details in the Portal, whose Submit replaces the address book with the one address typed | Re-enter the delivery address; tell whoever owns customer records when buyers start using the Portal |
| The member’s IC is on the card and Customer Maintenance is blank | A member and a customer are two linked records, and editing the card never writes the customer; the e-invoice reads the customer | Put the identity on the customer record before the first invoice (Membership Admin) |
| A branch manager can see every customer in the group | Master data is one list per tenant by design, so a return bought at one branch can be taken at another | If that is a boundary you need, it is a separate tenant; the export does honour scope (teams and permissions) |
How you know a new company, customer or item is usable
Saving succeeds either way, so the test is a document, not a screen. About ten minutes.
- A new company can post. Chart of Account › Companies › the company › Default GL Codes has a
row for at least
DEBTOR,CREDITOR,SALES,PURCHASE,OUTPUT_TAXandCOGS. Then finalise one document and open its Posting tab, or Financial Report › Error Checking › Trace Document: a journal should be there. The rest of the company checklist — knock-off pairs, the branch’s main location, the e-invoice pool, the timezone — is on how you know it worked. - A new customer or supplier posts to the right account. On its first FINAL document, read the journal’s debtor or creditor line. A purchase posted to a debtors account is the AR/AP type, not the document.
- A new item can be transacted. Scan it at a till or add it to a draft invoice: found, priced from the scheme, tax line present. An item that saves and will not scan is status, scheme or a missing inventory link.
- A new buyer’s e-invoice will carry a TIN. The identity type and number are on the customer record itself, not only on a member card or an invoice.
Where these applets sit
- Must exist first: the tenant and a login with the applets installed (Tenant Admin). Inside this folder the order is fixed by what each record points at: a company, then its chart and default GL codes, then tax codes and cashbooks the company and branch forms pick from, then items, then customers and suppliers. Treat Organization and Chart of Account as one task; a company is not postable until the second is done.
- Downstream: every document folder — Sales Workflow, Purchase Workflow, Inventory Workflow, Finance, E-Invoice — reads these records at raise time and at FINAL, and reports the failure.
- Siblings in other folders: the MY-SST applet maintains the same tax-code list through its own screens; Membership Admin holds the member, which is linked to a customer and writes onto it only from its E-Invoice tab and when a member’s name, birth date or gender changes; My E-Invoice Admin writes buyer corrections back to the customer record; Tenant Admin owns logins, teams and permission sets.
- Blast radius: one company with no default GL codes leaves every document type it raises FINAL with no journal; one customer with the wrong AR/AP type misposts every document until it is fixed; one item with a blank classification misreports every e-invoice line it appears on; one settlement method with no cashbook strands every receipt that uses it.
- Used together: Organization with Chart of Account; Doc Item with Inventory Item (the second is created from the first); Customer with Pricebook and Membership; Supplier with Forex for foreign purchases; Cashbook with Bank Reconciliation.
Which pages this folder holds
Reference for the Customer Maintenance applet — the customer master (profiles, addresses, tax and e-Invoice identity, credit terms and limits, categories, conglomerates) that sales, POS, receivables and e-Invoicing read from.
Reference for the Chart of Account applet, used by finance administrators and accountants to maintain GL sections, categories and codes, company default GL mappings, ledgers, sets of books, fiscal years, period locks and month-end closing-stock values.
Reference for the Cashbook applet, used by finance administrators and accounts clerks to maintain bank and cash accounts (cashbooks), settlement methods with charges and branch access, cash transfers, cash adjustments, post-dated cheques, bank-reconciliation matching weights and the cashbook enquiry screens.
Reference for the Organization applet (shown as Organisation Applet in the UI): companies, branches and locations, the company-level settings other applets read at FINAL (Knock Off Configuration, e-Invoice and Peppol, tax defaults, timezone), branch defaults (main location, delivery location, marketplace), labels, groups, category groups, notification templates and the applet's own Field Settings.
Reference for the Doc Item Maintenance applet — the item master (products, services, vouchers, account-code items) that every sales, purchase, POS and e-commerce document in BigLedger draws from.
The employee master: which identifier the rest of the platform keys a person on, what a document keeps of them, what happens when somebody leaves, and what this applet will not do.
Reference for the Forex applet, used by finance administrators to define currency pairs (forex data sources) and record dated buy, sell and mid rates that document applets pick up through the Forex Data Source selector.
Reference for the Supplier applet — the supplier master (profiles, bank and tax details, e-Invoice and Peppol identity, credit terms and limits, item pricing, logins) that purchasing, payables and self-billed e-Invoicing read from.
Reference for the Pricebook applet, used by pricing administrators to define price books and their price sets (rules for who, where, when and which items, plus discount, sales-price and membership-point treatments) that POS, the sales document applets and the OCR membership processor apply.
Reference for the Workflow Design applet — the tenant-wide catalogue of workflow processes, statuses, resolutions and transitions that document applets attach to their documents as an approval-style status track.
Reference for the Tax Configuration applet — the tenant-wide list of tax codes (code, name, tax type, rate, country) that every sales, purchase and POS document reads when a line is taxed.
Reference for the Inventory Item Maintenance applet — the stock-keeping record behind every stock-tracked item: inventory categories, multi-UOM, per-location min/max levels, serial-number import and trace, and the FIFO stock aging report.
Reference for the Merchant Admin applet — the merchant view of the shared entity master (payment-gateway merchant code and key, Peppol IDs, logins, return URLs, tax, bank details, addresses, contacts, company links, merchant branches, credit terms and limits, logo), merchant contracts with rate cards and charge rates, the monthly merchant transaction summary report, and the entity event audit trail.
Reference for the Shipping Pricebook applet, used by e-commerce and logistics administrators to define shipping price books and their price sets (who, where and which items, plus Standard Shipping Fee, Handling Fee and Fuel Surcharge treatments) that the CP Commerce storefront evaluates at checkout.
Reference for the Entity Maintenance applet — the type-agnostic view of the shared entity master (one record can be customer, supplier, employee and merchant at once) with its Payment Config, Tax, Address, Contact, Intercompany Branch and Company Linking tabs, plus the Entity, Customer, Employee and Supplier category trees.
Reference for the Group Maintenance applet: one listing of platform groups, each with a code, a group e-mail address, a visibility and a joining rule, its members, and a link into team permissions. Not separately installable — the registry row is DELETED.