Customer Maintenance

A customer must exist here before any quotation, order, invoice, POS receipt or e-Invoice can name them. The record holds who they are, where to deliver, how they are grouped, and the credit term and credit limit that the sales and receivables applets read — their invoices and orders live in those applets, not here.

Overview

The Customer Maintenance applet is BigLedger’s customer master. A customer must exist here before a sales quotation, sales order, invoice, POS receipt, delivery order or e-Invoice can name them. The record holds who the customer is (corporate or individual, registration and tax numbers), how to reach and deliver to them (addresses, contacts), how they are grouped (categories, category groups, conglomerates, business nature), and the credit term and credit limit that the sales and receivables applets read.

It is used by sales administrators who onboard customers, by finance or credit control who set terms and limits, and by operations teams who import customers in bulk or merge duplicates. It is master data only — invoices and orders are viewed in their own applets, although a Statement of Account tab is available on the customer record.

Where it fits

Modules: Core, CRM, Financial Accounting, POS, E-Invoice.

Screens and menus

Left menu (any entry can be hidden in Application Settings):

Gear (Settings) menu: Application Settings, Default Selection, Business Nature, Printable Format Settings, Entity Branch Group and a Webhook configuration screen. Personalisation offers a per-user Default Selection.

Customer listing

The listing shows code, name, type, e-mail, phone, incorporation date, fiscal year end, tax registration numbers, business nature, classification and the personal-detail columns for individuals; every column can be hidden tenant-wide (HIDE_* under Customer Listing Settings Hidden).

Create customer

The create screen is a single Main form. It asks for name, code, nickname, entity type(s), customer type (Corporate or Individual), status, ID type / number / expiry, gender and date of birth (individuals), fiscal year end, tax ID and category, country, currency, description, AR/AP type, phone, e-mail, website, business nature, classification, SST / SST exemption / GST / WHT numbers, GL code, SIC code and business activity description, default sales agent, default label, default sales-return pricing option and an alert message. Defaults come from Default Selection: customer type (falls back to CORPORATE), country, currency, credit term and credit limit; AR/AP type defaults to AR_TRADE, entity type to CUSTOMER, status to ACTIVE.

Edit customer

Tabs, in order (each has a HIDE_* setting and a matching SHOW_*_TAB permission):

Main · E-Invoice · Subsidiary · Peppol Config · Address · Remark · Customer Category · Category Group · Login · Vehicle · Payment Config · Tax · Branch Linking · Customer Branch · Intercompany Branch · Company Linking · Item Pricing · Credit Term and Limit · Membership · Employee · Attachments · Statement Of Account · Documents.

• E-Invoice — buyer’s name, TIN, ID / registration number, SST number, tourism tax ID, business activity, contact number, e-mail and the full e-Invoice address; a skip e-Invoice flag for buyers who do not need one.
• Subsidiary — parent / child links between customer records.
• Peppol Config — Peppol participant details for cross-border e-Invoicing.
• Address — any number of addresses, each with an address type (main, billing, shipping), receiver name, five address lines, city, postcode, state, country, mobile, e-mail and a secondary contact. Default and default e-Invoice address selection is a setting.
• Customer Category / Category Group — up to 20 category slots, each bound to a category group in Application Settings.
• Login — invite the customer to a portal login (optionally installing all applets on invite).
• Vehicle — vehicles owned by the customer (workshop and automotive tenants).
• Payment Config — settlement methods available to this customer: bank transfer, cash, cheque, credit card, e-wallet, FPX e-mandate, payment gateway, membership point currency, open credit, voucher, others.
• Tax — tax category and tax codes.
• Branch Linking / Company Linking — which of your branches or companies may transact with the customer.
• Customer Branch / Intercompany Branch — the customer’s own branches, and mapping to an intercompany branch when the customer is another company in the group.
• Item Pricing — per-item prices for this customer: the same rows as the Entity Pricing tab in Doc Item Maintenance. The purchase half of a row is read by the product; the sales half is not — see below before you use it to give a customer a price.
• Credit Term and Limit — attach a credit term and a credit limit to this customer. The Default Credit Limit / Default Credit Term pickers and the two credit-status dropdowns sit on the Main tab, not here.
• Membership — membership plan and points (editing points is permission-gated).
• Employee — staff records attached to the customer.
• Attachments, Documents, Statement Of Account, Remark.

What the Item Pricing tab does and does not reach

Each row is one pricing record for this customer on one item, and it carries two halves: a purchase price, min / max price, order-quantity bands and a lead time, and a sales price with its own min / max and bands.

The purchase half is consumed. The replenishment run’s order-fulfilment step reads the supplier’s row for the item and puts its purchase unit price, minimum and maximum order quantity and lead time onto the generated purchase order line.

The sales half is not consumed when a sales line is priced. When you add a line, the selling applets look the item up by pricing scheme and nothing else — the lookup carries no customer at all, so it cannot filter by the customer on the document. Nothing else on the selling side reads the sales price off this tab either; the one sales report that does read it restricts itself to suppliers. So a sales price typed here is saved, exported and reportable, and never changes the price on a sales order, invoice, quotation or POS line. Nothing warns you.

To actually price one customer differently, put that customer in a customer category (the Customer Category tab) and target the category from a price book price set: Customer Category is one of the header rules the shared sales-side calculator really evaluates. A pricing scheme is the other route when the difference is a whole price list rather than one account.

Credit terms and credit limits

Both are reusable definitions maintained in their own listings and then copied onto a customer as an assignment row. The copy is taken at the moment of assignment: editing a definition afterwards does not change customers already assigned it.

A credit term carries a code, a name, a status and six integers in two triples — Set Year / Set Month / Set Day and Add Year / Add Month / Add Day. A credit limit carries a code, a name, a status, a currency and an amount.

Every tenant is seeded by the platform with one credit limit EMP_CREDIT_LIMITS (MYR, amount 0) and six credit terms EMP_CREDIT_TERMS_0 … EMP_CREDIT_TERMS_5 (all six integers 0). These are for employee accounts and are not templates.

How the six integers become a due date. The document applet builds a base date literally out of Set Year, Set Month and Set Day; if that is not a valid date it falls back to the document’s transaction date; it then adds the three Add values. So a “net 30 days” term is Set 0/0/0 and Add 0/0/30. A term with some Set values filled produces an invalid base and silently falls back to the transaction date — the Set triple only takes effect when all three are a real date. The purchase side carries the same arithmetic.

Four different resolutions of “this customer’s credit limit” exist in the backend, and they can disagree when a customer has more than one assignment row:

The online store’s figure is worked out when the shopper’s account loads. On a website with Restrict View/Access by Entity on, checkout compares the basket with it in the shopper’s browser: an order within it is placed on account, one above it goes to the payment gateway or is refused. The Sales Order screen’s check runs only on orders finalised on that screen, so an order the store placed on account was never measured by it. Which of the two a credit controller relies on is their call; E-commerce best practices sets out what each costs.

The Statement of Account renders the term as N DAYS, built from Add Day alone, so a term expressed in months displays misleadingly there.

Conglomerates, categories, business nature

• Conglomerate — code, name, description, status; used to report across a corporate family.
• Category Group and Category — hierarchical classification; slots 0–19 on the customer are each tied to one group.
• Business Nature — code and title; a dropdown value on the customer.
• Entity Branch Group — code, name, description; groups the customer’s branches.
• Printable Format Settings — format code and name for customer printables (statements, labels).

Business Nature: a label for your own sorting

The Business Nature list is a code and a title per entry, kept under the gear menu. On a customer’s Main tab you pick one entry from it, shown as code - title. The box appears only when the customer type is Corporate. An individual customer has no Business Nature box.

What happens behind the screen. The customer record keeps the code you picked, a copy, not a link to the entry. The code then does one thing: it fills a Business Nature column in the customer listing. The column is hidden until you show it, and you can filter on it. Beyond that, nothing in BigLedger reads it: it does not choose a price, a tax or a GL code, no standard print template carries it, and it is not sent with an e-invoice.

Three cautions:

• Codes are not checked for duplicates. Two entries can share a code, and the drop-down shows both. Symptom: a filter on the code returns customers you meant to keep apart.
• Deleting or re-coding an entry does not touch customers. A customer keeps the old code, and the listing column still shows it. Nothing warns you that the entry was in use.
• Suppliers get one only by accident. The Supplier applet has no Business Nature box. The quick “create supplier” form inside a purchase document does have one, so a supplier created there can carry a code that the Supplier applet shows only on its merge screen and cannot change.

Your job. The list is your own vocabulary, so the person who owns the customer master decides it once: a short set of natures, one code each, written down. Settle it before anyone starts picking, and do not delete or re-code an entry while customers carry it. To reach customers by nature, show the column in the listing and filter. To report on a nature, export the listing. For anything that has to change a price or a report grouping, use a Customer Category instead, because a category is read elsewhere and a nature is not.

Import, export, merge

• File Import uses the DOC_CUSTOMER template; the link imports (branch, company, employee, category) and credit term / limit uploads have their own templates and listings.
• File Export downloads the customer database for offline editing and re-import.
• Entity Merging lets you pick a surviving entity and the duplicates to fold into it; Entity Merge Processing shows each merge job’s status. Use it instead of deleting duplicates that already have transactions. Before you merge, read Duplicate customers: what counts as evidence that two records are one person, what a merge changes that cannot be changed back, and the check to run afterwards.

Configuration

Before you can use it

Applet settings

Settings › Application Settings is this applet’s own settings screen, not the shared Field Configuration screen the document applets use, and Settings › Default Selection repeats five of its pickers. 108 keys reach the customer applet and 67 of them begin HIDE_ — one switch per menu entry, tab or field on the customer form, and flipping one shows you what it did at once. The eight below change what the applet will let you do, or write something onto the customer record that another module later reads. How settings are stored and who they apply to.

Two things to know before you change anything on this screen. First, the name in italics under each setting is the applet’s internal key. It is there so you can match what you are looking at to what support asks you about; it is not a stable name and it can be renamed, replaced or dropped when the applet is updated, so do not build a script or an integration around one. Second, a setting can be switched back but it cannot be returned to never saved: the first time anybody saves this screen, every toggle somebody touched, and every toggle the screen pre-fills, is written into your tenant’s settings at whatever it was showing, and for those the applet stops falling back to its own built-in default. The Default when never saved column above is what you give up at that moment — worth reading before the first save rather than after.

On the screen and doing nothing

• The twenty Category Group Settings pickers — twenty category-group pickers under Category Group Settings, bound to real dropdowns and saved with the rest of the screen, and read by nothing in the product. Configuring them changes no category slot on any customer. This is the largest inert panel on the screen, and it looks like the most configurable one.
• The create form’s own expiry-date switch — the create form reads a differently named key that has no control on the settings screen. See the expiry-date row above; it is the reason that setting only half works.

Document behaviour settings

Not applicable — the applet maintains master records. Printable Format Settings only registers format codes and names for customer printables; there is no status flow, approval or e-Invoice submission here.

Who can change what

Server-side. Entity reads and writes go through the tenant entity API; a branch-targeted TNT_API_DOC_…_READ_TGT_GUID is what the Documents tabs consult when ENABLE_TARGETED_PERMISSION is on. These are the only permissions that can return a 403.

The applet registers 35 client-side permissions. Thirty-four of them are the SHOW_* partner of a HIDE_* setting: hide a menu entry or an edit tab for the tenant, then hand the matching code to the one role that should still see it. The usual shape is hiding Credit Term and Limit with HIDE_CREDIT_TERM_LIMIT and granting SHOW_CREDIT_TERM_LIMIT_TAB to credit control alone.

The one that is not a tab. ALLOW_EDIT_MEMBERSHIP_POINTS is the standing exception to DISALLOW_EDIT_MEMBERSHIP_POINTS above — a setting and a permission governing the same five fields on the Membership tab, and the clearest reason on this applet to read both together.

Fields

Create customer — Main

Most of this screen does what it looks like it does. Name, Gender and Date of birth for an individual, Fiscal year end and Date of incorporation for a company, E-mail and Website are stored on the record as typed, and nothing else in BigLedger changes because of them. The rows below are the ones that reach somewhere you cannot see from here.

Edit customer — Address

An address record holds what you would expect — an addressee (Name, Receiver name), five address lines with city, postal code, state and country, a Mobile no and E-mail for that address, and a secondary contact. Two things about it are not on the screen.

Edit customer — E-Invoice

This tab is the buyer block LHDN receives: Buyer’s name, e-Invoice TIN, ID number (BRN, NRIC or passport), SST number, Tourism tax ID, Business activity description, Contact no and E-mail, plus Skip e-Invoice to exclude this buyer entirely.

The buyer address is copied, not entered. When the tab opens it scans the customer’s addresses for the one ticked default e-Invoice address and patches its name, five lines, city, postcode, state and country into these boxes. The scan runs billing addresses, then main, then shipping, and each pass overwrites the previous one — so if you have ticked more than one, the shipping address wins, whatever order you ticked them in. If none is ticked, every address box here stays empty and the e-Invoice goes out without a buyer address.

Symptom: the buyer address on a submitted e-Invoice is the customer’s warehouse, or is blank, and nothing on the E-Invoice tab explains why. Cause: the tick is on the wrong address record, or on none. Fix: go to the Address tab and put it on the one address you want the regulator to see.

Three of the boxes are not this tab’s own. Buyer’s name, Contact no and E-mail are the record’s Name, Phone and E-mail under another label: there is one column of each, and the Main and E-Invoice tabs keep each other in step. Rename the buyer here and you have renamed the customer. When the person you bill and the buyer LHDN should see are different parties, this record is the wrong place to say so; the buyer is set on the e-invoice itself (below).

Check the TIN before you rely on it. Verify TIN sends the TIN, the ID type and the ID number to LHDN together and shows TIN Valid only when LHDN accepts the three as one taxpayer; Get TIN asks LHDN for the TIN that belongs to the ID type and number you entered. As you type a TIN, the tab also looks through your own customers and warns TIN Already Exits For Another Customer when another record carries it — usually a duplicate customer, or one company billed under two accounts. The verification result is not saved: the record keeps the TIN, not the fact that somebody verified it.

Edit customer: the Tax tab

One row per country, from a list of four: Malaysia, Singapore, Thailand, Indonesia. Each row carries a Tax Type, a Tax Code, a Tax Rate and a Tax Option (INCLUDE TAX / EXCLUDE TAX), and the whole row is stored as one block of text per country on the record. On Malaysia the Tax Type list is fixed to the three output types — GST-OUTPUT, SST-SLS-OUTPUT, SST-SVC-OUTPUT — whatever the tenant’s tax codes actually offer. Adding a second row for a country you already have is refused.

Credit term / credit limit

Credit term definition.

The Supplier applet’s credit-term form carries one further control, a credit-term logic, that this applet’s form does not offer; a description is not exposed on either form.

Credit limit definition. A definition is a Credit Limit Code, a Credit Limit Name, a Currency and an amount; only two of the four behave in a way the form does not show you.

Assignment — the Credit Term and Limit tab’s + opens a picker with a Select Mode / Create Mode toggle: Select attaches an existing definition, Create defines a new one inline. Either writes an assignment row on the customer, copying the code, name, currency, amount and the six integers.

Defaults and status — the customer’s Main tab carries four further controls in the credit block: Default Credit Limit and Default Credit Term, and Credit Limit Status and Credit Term Status, each a two-value list of OK and BLACKLISTED. This applet is the only one in the product that writes those two default pointers — a customer created in Entity Maintenance or through the API has them null.

When Settings > Default Selection holds DEFAULT_CREDIT_TERM_GUID / DEFAULT_CREDIT_LIMIT_GUID, the applet creates the assignment row and sets the matching default pointer automatically — but only while the record is still at status TEMP, i.e. during initial creation. It never retro-fits an existing customer, and a CSV assignment upload does not set the pointers either.

Lifecycle and effects

A customer is a master record with a status of ACTIVE, INACTIVE or TEMP; it does not post to the General Ledger. On creation the backend sets Credit Limit Status and Credit Term Status to OK when they are blank. Backend validation on save: customer code and customer ID must be unique among non-deleted customers — and the customer ID is the stricter of the two, because the database itself refuses a duplicate, as it does for supplier, employee and merchant IDs — the AR/AP type must be set, and referenced GL code, default label and consolidated AR/AP entity must exist. Sales documents read the customer’s GL code, credit term and credit limit at the time the document is created.

What happens behind the screen when you save, import or merge

Saving. The screen’s save and every row of File Import pass the same server check before anything is written: the code is upper-cased and stripped of spaces, a code or customer ID another customer holds is refused, a blank AR/AP type is filled (AP_TRADE if the record is flagged as a supplier, AR_TRADE otherwise), and a running-number code is minted only once the record has left TEMP. A customer record posts nothing and moves no balance. What a save changes is what the next document copies (below) and what the posting job reads live: the AR/AP type.

Importing updates as well as creates, and the customer code decides which records a row can reach. Each File Import row is first matched against the records you already hold, and a row that matches overwrites that record with the values it carries:

• A blank AR/AP type is read as AR_TRADE, on an existing record too. Import a sheet with that column empty over a customer-and-supplier record set to AP_TRADE, and its next purchase document posts to the receivable account (The AR/AP type is decided once).
• The row’s ID type and ID number are copied into the E-Invoice tab’s ID type and value, replacing what the tab held.
• The row’s address is added as a billing or shipping address, and ticked as the default e-invoice address when the row carries a TIN. An address identical to one already on the record is not added again.

Symptom: after an import, an existing walk-in customer has a new name, a supplier or an employee now appears in the customer listing, or a debtor’s AR/AP type has changed. Cause: a row without a code matched the record on a shared phone number or e-mail, or carried a blank AR/AP type. A supplier made a customer this way with a blank AR/AP type in the sheet is also reset to AR_TRADE, so its next purchase document posts to the receivable account. Prevention: when you import into a populated customer list — GadgetSphere’s runs to about 85,000 records, most of them walk-ins — give every row a code and keep the AR/AP type column filled.

Merging runs as two background jobs. The first re-points everything that referred to the records you merged away at the surviving one. The second rebuilds the customer snapshot on every document that now points at the survivor, including the documents first raised on the survivor itself, from the survivor’s record as it is at that moment: name, code, contact, identity, the first credit term and limit it finds, the shipping recipient and the e-invoice buyer block. Two details:

• The rebuilt e-invoice buyer block takes its address from an address ticked default e-invoice address among the survivor’s shipping, then billing addresses; a tick on a main address is not looked at. With no such tick, the documents are left with no buyer block of their own, and one not yet e-invoiced takes its buyer from the survivor’s record when the e-invoice job runs.
• The e-invoice records already built for those documents are a separate table and are not rewritten: what LHDN received stays as it was.

Before you merge, read Duplicate customers, and put the default e-invoice tick on one of the survivor’s billing or shipping addresses.

What a document keeps of this record, and what it does not

Somebody will ask you this the first time they correct a customer here and then open last year’s invoice: why does the old invoice still show the old details? Because that is what it is for.

When a customer is picked on a sales document, BigLedger copies a block of this record onto the document — customer code, name (with the contact’s name appended when a contact was picked), status, e-mail, phone, GL code, identity number and type, entity type, description and currency, plus the billing and shipping contact and the address chosen from the Address tab. The document does not point at this record and read through it. The server fills that block from here only when it arrives empty, and never refreshes one that is already there.

So a correction on this screen reaches the next document, not the ones already raised — and that is deliberate. An invoice is evidence of what was agreed; it has to keep the name and address it was raised against, or a reprint stops matching the copy the customer is holding.

Two things follow for you. A clerk who corrects a customer’s details on one invoice has corrected that invoice, not this record — nobody is prompted to bring the correction back here, and it is worth asking for when you see an invoice that disagrees with the master. And when a report built from documents disagrees with this screen, the documents are not stale data to clean up; they are the record of what was true at the time.

The same rule applies to suppliers and to every document-issuing applet.

The e-invoice buyer: read once, then frozen

The e-invoice is the one copy that is not taken when the document is raised. After FINAL, the e-invoice job builds an e-invoice record, the copy LHDN actually receives, and takes the buyer from the first of these that has one:

1. the document’s own e-invoice buyer block (or, failing that, its general e-invoice block), which the storefront’s e-invoice request and the sales document imports, among others, can fill;
2. otherwise this customer record as it is at that moment: Name, the E-Invoice tab’s TIN, ID type and value and SST number, the Main tab’s ID number, e-mail, phone, and the address ticked default e-invoice address (shipping, then billing, then main).

From then on the e-invoice record keeps its own copy. Correct the TIN here afterwards and the e-invoice already built keeps the old one, including after LHDN has rejected it: Save and Resubmit sends the record’s own buyer again and never reads this screen. Fix a rejected buyer on the record’s Account tab in My E-Invoice Admin, and here as well so the next sale is right. The record that goes to LHDN is not your invoice follows one record through.

Why the buyer is not simply this customer. The person you bill and the party LHDN should see as buyer are not always the same. A shopper buys a laptop at GS-KV-03 and pays for it himself, so the cash bill and the receivable are his; later he needs the e-invoice in his employer’s name to claim the cost back. BigLedger lets the two differ, and lets the buyer be completed afterwards in My E-Invoice Admin by someone with time to get it right, rather than at the till. An e-invoice whose buyer differs from this record is therefore not, by itself, an error.

One job writes back. When a sales invoice or cash bill of RM 10,000 or more reaches the e-invoice job with a buyer whose ID type is a business registration number (BRN), an ID number and no TIN, the job asks LHDN for the TIN by that registration number. A TIN found is written onto the e-invoice record, onto the document’s buyer block if it has one, and onto this customer’s E-Invoice TIN.

The AR/AP type is decided once

The backend never recalculates this field. On both the create and the update path it supplies a value only when the one it is given is blank — AP_TRADE if the supplier flag is on, AR_TRADE otherwise. So a record created as a customer is stamped AR_TRADE; ticking Supplier on it a year later changes nothing, and every purchase invoice you then raise on it debits the debtor control account, netting against what they owe you, with no contra document. This does happen, and it is invisible until somebody reads the control account and asks why a supplier balance is sitting inside receivables. The fix is one field on this tab, and it is yours to make.

At posting the value is read live, not from the document: BigLedger takes the Company Linking row’s type for the posting company if there is one and the header’s otherwise, so a correction here moves the account the next time the document posts. Two details worth knowing: the lookup matches the company link on company alone and takes the first row it finds, in no particular order, so with more than one link row for that company the winner is arbitrary; and if the value comes back blank, posting builds no debtor or creditor line. The journal then no longer balances, and the posting refuses it with TOTAL_DEBITS_AND_TOTAL_CREDITS_NOT_BALANCES: the document stays FINAL with no journal at all. Nothing lopsided is posted; the document simply has none. The same happens when the company’s mapping row for the code exists but has no sub-ledger. Entities carrying no AR/AP type do exist — imports and records that predate the defaulting above — and a document raised on one takes this path.

How you find out. After finalising a document for a record you are unsure of, check that it has a journal: on a sales invoice, the Posting tab in Sales Invoice (Internal) should show the journal posted, and Financial Report › Error Checking › Trace Document on that document reports a missing journal and offers Resolve, which re-runs the posting once the AR/AP type is set.

What enforces a credit limit

Nothing in this applet, and nothing on the server at the moment of sale. The server’s whole enforcement is two pieces of backend, and a third, optional check lives in the sales screens:

• The Blacklist Overdue Customer job — ENTITY_BLACKLIST_CUSTOMER_PROCESSOR in the Scheduler applet’s processor picker, if you want to schedule it. Each run clears every BLACKLISTED value in the tenant — both status fields — then sets Credit Limit Status to BLACKLISTED on each customer whose summed outstanding balance in a company, across FINAL, non-voided, non-forex documents, exceeds their company-level limit for that company or, where there is none, their Default Credit Limit. A blacklist set by hand on the Main tab therefore lapses at the next run.
• The check at FINAL, run for exactly four document types — Cash Bill, Sales Invoice, Sales Order and Outbound Delivery Order. It reads the two status fields on the customer record, never a live balance, and returns error code ENTITY_BLACKLISTED.
• The optional credit check on the Sales Order and Sales Invoice screens, switched on in each applet’s settings. It refuses FINAL once the customer’s available credit in that company is used up, counts one company, and checks nothing that arrives another way. See Deciding on Credit.

The job’s second branch blacklists customers aged past their terms: a FINAL document with a balance, past its due date, whose age counted from the document date exceeds the customer’s company-level credit term (its Add Day figure). Two things about it are not what the screen suggests:

• Only the company-level term counts. The fallback to the customer’s Default Credit Term looks the term up through the Default Credit Limit pointer instead, finds nothing, and so a customer with no company-level term is never caught by this branch. Recorded as a product defect; this is the shipped behaviour.
• It sets Credit Limit Status, not Credit Term Status. A customer stopped for overdue invoices is therefore refused at FINAL with “Customer is blacklisted due to credit limit” — even when their balance is well inside the limit. Look at the ageing before the limit when you see that message.

On the purchase side — a supplier’s credit limit and terms — there is no equivalent processor and no check — those rows are recorded and displayed only.

Who else writes to a customer

This screen is not the only thing that changes a customer record, and the others do not ask first:

Because Buyer’s name is the record’s Name, the first row also changes the buyer on that customer’s next e-invoice. The design reason is that a member is the person at the till and a customer is the account you bill, and they are the same person only sometimes; Customer and Member sets out when each copies the other.

Where the figures on a customer come from

The balances on a customer record are added up from the documents’ own balances when you search; none is kept on the customer:

• Statement Of Account tab, aging. You pick a company and a Month To. When that is the current month, the six buckets are calendar months (Malaysia time), each holding the open balance, right now, of the FINAL documents dated in it, and the last holding everything older. For an earlier month the balance is rebuilt as at that month end, counting only the knock-offs dated before it. Purchase invoices, purchase returns and goods-received documents are left out, so a record that is also a supplier shows its sales side here. The running Balance column is added up in your browser, row by row. Because this is a live figure and the Aging Report is a copy taken once a month, the two disagree whenever something was raised or paid since that copy.
• Credit figures. Four parts of BigLedger read “this customer’s credit limit” four ways; the table under Credit terms and credit limits says which reads what.

How you know a customer is ready for the first invoice

About a minute, on a record you have just set up:

1. E-Invoice tab → Verify TIN. TIN Valid means LHDN matched the TIN, ID type and ID number as one taxpayer. On TIN Not Valid, correct whichever of the three is wrong; Get TIN fetches the TIN for the ID you hold.
2. E-Invoice tab, address boxes. Empty boxes mean no address carries the default e-invoice address tick; a warehouse here means the tick is on the wrong one.
3. Main → AR/AP type. AR_TRADE for an ordinary trade customer. Anything else should be a decision somebody can name.
4. Main → Default Credit Term and Default Credit Limit, if they buy on account: the due date and the overdue job read these.
5. After their first invoice is finalised: the Posting tab in Sales Invoice (Internal) shows a journal, and the invoice’s To IRB reference fills in once the e-invoice job has run, or the document is waiting in a pool for a missing field (Submission mechanics).

When all five hold, the customer posts to the account you meant, ages from the right due date, and reaches an e-invoice as the buyer you intend.

What stays your job

• Deciding that two records are one customer. BigLedger finds candidates (Entity Merging’s similarity search, the TIN warning on the E-Invoice tab); the merge itself is queued from Entity Merging when somebody confirms a group. The person who owns the customer master decides, out of hours, with the evidence in Duplicate customers, and afterwards opens two or three of the survivor’s documents to see the survivor’s name on them.
• Knowing the buyer is who they say. Verify TIN proves that a TIN, an ID type and an ID number belong together at LHDN; it does not prove they belong to the person at your counter. Whoever opens a corporate account compares the registration certificate with the record once, before the first credit sale.
• Keeping the master clean. Once a month, whoever owns the master filters the listing for TEMP to see how many blank stubs have built up (Status), and after any import into a populated list reviews the AR/AP type of the records it matched.

Related applets

• Supplier, Employee, Merchant, Entity — the same entity table seen through other entity types; a customer can also be a supplier or employee.
• Organisation — companies and branches for linking.
• Tax Configuration — tax categories and codes on the Tax tab.
• Chart of Accounts — the receivable control account per customer.
• Doc Item Maintenance — item prices per customer (Item Pricing / Entity Pricing).
• Sales Order and Sales Invoice — consume the customer, its addresses, tax and credit data.
• Debtor and Creditor Report and Statement of Account — balances and statements per customer.
• My E-Invoice Portal — reads the E-Invoice tab as the buyer when a document carries none of its own; My E-Invoice Admin — corrects one e-invoice’s buyer without touching this record.
• Membership Admin — writes a member’s name, date of birth, gender and e-invoice details onto customers (Who else writes to a customer).
• Shopping Cart Customer Access (Internal) — a customer whose Login tab links a login to this record can keep and submit a cart there.

Troubleshooting

Related documentation

• Credit Limits and Payment Terms — the guide that builds the definitions, assigns them, and explains what each part of BigLedger does with the numbers.
• Credit sales workflow — selling on those terms, and the blacklist at FINAL.
• Stopping Supply to a Customer — the two status dropdowns as a credit controller’s stop, what they refuse, and how to keep a hand-set stop.
• Can This Customer Take More Goods? — the credit decision, and the Alert Message as the place to record it.
• Core module and CRM module use cases.
• E-Invoice module configuration — buyer data requirements.