Supplier

Overview

The Supplier applet is BigLedger’s supplier master. A supplier must exist here before a purchase requisition, purchase order, goods receipt, purchase invoice, debit or credit note, payment voucher or self-billed e-Invoice can name them. One record holds who you buy from (corporate or individual, registration and tax numbers), how you pay them (bank accounts, currency, AR/AP type, credit term and limit), how they are grouped and priced (categories, item pricing, branch and company links), and the identity data that self-billed e-Invoices and Peppol routing depend on.

It is opened by procurement staff who onboard suppliers, by finance who set payment and credit terms, and by master-data teams who bulk-load or de-duplicate supplier records. Suppliers, customers, employees and merchants are all rows in the same entity table; this applet is the supplier-typed view of it.

Where it fits

Modules: Core, Purchasing, Financial Accounting, E-Invoice.

Screens and menus

The route base is applets/wavelet/erp/entity/supplier-applet. Left menu (every entry except Supplier can be hidden in Application Settings):

Settings (Settings in the sidebar) groups: System Configuration — Application Settings, Default Selection, Entity Branch Group, Resource Bundle Configuration, Custom Field Placement; Server Side Permissions — Permission Wizard, Permission Set, User / Team / Role Permission; plus Feature Visibility and Webhook. Personalization offers Default Selection and Sidebar.

Creating a supplier

On the current listing the + button does not open a separate create form. It looks for an entity you previously left with status TEMP and reopens it; if there is none it inserts a new entity row with status = TEMP and opens Supplier Edit on it. The new row is pre-filled from Application Settings — Entity Type from DEFAULT_ENTITY_TYPE (default SUPPLIER), Supplier Type from DEFAULT_SUPPLIER_TYPE (falls back to CORPORATE), Identity Type from DEFAULT_ID_TYPE (falls back to BRN).

Supplier edit tabs

Tab order is not fixed: Settings > Default Selection > Details Tab Ordering is a drag-and-drop list saved as SUPPLIER_DETAILS_TAB_ORDER, and the edit screen renders the tabs in that order (tabs added by a later release are appended at the end). With ENABLE_VERTICAL_UI and ENABLE_SIMPLIFIED_UI both on, the same tabs render as a stacked accordion instead of a tab strip.

Configuration

Before you can use it

Applet settings

Settings › Field Settings. This applet has its own settings screen rather than the shared one the document applets use, and 95 of its 107 toggles hide a menu entry, a tab or a field on the supplier form — flip one and you can see what it did. The six below change what the applet will let you do, and three of them are felt in a different module altogether. How settings are stored and who they apply to.

Two things about hiding a field here that hiding does not usually mean. HIDE_SUPPLIER_CODE, HIDE_SUPPLIER_NICKNAME, HIDE_EMAIL and HIDE_PHONE_NUMBER do not merely hide their field — they disable it, and a disabled field is left out of what the form saves. The value is not hidden, it is not saved. And HIDE_AUDIT_LOG_MENU is the one menu toggle with no SHOW_* escape hatch, so it takes the Audit Trail away from administrators too.

On the screen and doing nothing

• DEFAULT_ID_TYPE — read when a new supplier is created, where it sets the record’s identity type and falls back to BRN. No screen in this applet renders it, so there is no way to change it from the product. It matters because the identity type travels to LHDN on an e-Invoice; a supplier identified by passport or NRIC has to be corrected on the record.
• HIDE_IDENTITY_TYPE — the supplier form honours it, and it is missing from the settings form model, so the toggle on the Main Details panel has nothing to bind to and the value cannot be set here.
• The contact-designation and listing-contact-title hides — declared, rendered and saved, and no screen reads them.
• The Lines Settings and Department Settings panels — eight toggles (Unit Discount, SST/VAT/GST, WHT, Blanket Order, Segment, G/L Dimension, Profit Center, Project) with no form control behind them, copied from the document-applet settings screen. Nothing is read and nothing is even saved.
• HIDE_SUPPLIER_CODE_PREFIX and the Supplier Code Prefix input are commented out in both the settings screen and the supplier form. The prefix that does work is a separate record — ENTITY_CODE_PREFIX / SUPPLIER in the application-configuration table — written by this applet’s Settings effects, not by APPLET_SETTINGS.
• Personalization › Default Selection offers Default Branch and Default Location and cannot save: the component is never given the applet container it writes into, so the first change throws in the browser. Nothing in this applet reads either key in any case. Saving Default Selection also writes DEFAULT_BRANCH, DEFAULT_LOCATION and the default AR/AP type as null for the same reason — three form fields with no control on the screen.

The one personal setting that does work is DEFAULT_TOGGLE_COLUMN (SINGLE / DOUBLE), written silently to your own settings whenever you use the one-column / two-column toggle on the listing.

Negative claims above are whole-identifier greps across the applet project, its bundled shared-utilities and the backend at the commit in sources.settings:.

Document behaviour settings

Not applicable — this applet maintains master records. There is no status flow beyond TEMP / ACTIVE / INACTIVE, no approval, no printable format registry and no e-Invoice submission flag on the applet itself (the supplier’s own EINVOICE_SELF_BILLED flag is a field on the record, not an applet setting).

Settings in other applets that control this applet

Who can change what

The applet checks ten client-side permission codes — SHOW_CATEGORY_MENU, SHOW_FILE_IMPORT_MENU, SHOW_UPLOAD_CREDIT_TERMS_MENU, SHOW_UPLOAD_CREDIT_LIMITS_MENU, SHOW_CREDIT_TERM_LISTING, SHOW_CREDIT_LIMIT_LISTING, SHOW_FILE_EXPORT_MENU, SHOW_CONSOLIDATED_ARAP_MENU, SHOW_ENTITY_MERGING_MENU, SHOW_ENTITY_MERGING_PROCESSING_MENU — and applies each as hide = !SHOW_X && HIDE_X, so a holder of the permission keeps a menu the tenant has hidden.

Server-side permissions (Permission Wizard, Permission Set, User / Team / Role Permission) and the Feature Visibility screen are the shared platform ones and gate access to the applet’s services in the usual way.

Fields

Main tab

The tab also takes a Company Tax Registration ID, a free-text Description, and a read-only audit block (created and modified by, with dates). None of the three is validated, defaulted or read anywhere else.

E-Invoice tab

Thirteen fields carry Validators.required: SIC code, business activity description, supplier name, ID number, contact number, email, address name, address line 1, country, state, city, postcode and e-Invoice ID type. The tab is validated as a block — a partially filled tab keeps the whole record from saving.

Seven fields are not on that list and the record saves without them: the self-billed flag, ATIGA number, FTA information, tourism-tax ID, SST number, and — the two that matter most — the tax identification number (TIN) and the e-Invoice ID value. Those last two are not checked at save; they are checked at submission, where a blank one diverts the document with “Supplier TIN is missing” or “Supplier id value is missing” (see Self-billed e-Invoices and Peppol routing). So a supplier record that saved cleanly is not evidence that its e-Invoice details are complete.

EINVOICE_SELF_BILLED on this tab is the flag that routes a supplier’s invoices into the self-billed e-Invoice pipeline (document types 11–14) with the supplier as issuer.

Address tab

An address record also holds Address Line 1–5, Country, State and City (all four required), and a delivery contact — Receiver Name, Mobile No. and Email.

Contact tab

Contact Name, Contact ID, Position and Mobile No. are required; Office No., Extension No., Fax No., Other No., Email and Phone are optional.

Payment Config tab

One field on this tab is enforced and one fills itself in; the rest are a record of the supplier’s bank details — Country, Bank (from the platform bank list), Bank Acc No., Bank Acc Holder Name, IBN Number, Account Expiry and Status.

Tax tab

One row per country, chosen from a hard-coded 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); a second row for a country you already have is refused. On Malaysia the Tax Type list is fixed to the three input types — GST-INPUT, SST-SLS-INPUT, SST-SVC-INPUT — whatever the tenant’s tax codes offer. That is the deliberate mirror of the customer applet, which fixes the same list to the three output types; the shared Entity Maintenance tab applies neither guard.

All five boxes are marked required, but you cannot type the Tax Rate: it is readonly disabled and is filled by copying the chosen code’s tax_rate_filing into the form. The whole row is then stored as a TAX_DETAILS JSON extension on the entity — so the rate is a copy taken at that moment, not a live reference. Change the rate later in Tax Configuration and this row keeps the old one.

Its one consumer is the shared pricing-scheme picker: when a purchase line’s item returns no pricing scheme for this supplier, the picker offers a fallback built from the stored code, rate and type, and selecting it stamps all three onto the line. Nothing in the backend reads a TAX_DETAILS row. So this tab is not where a purchase line’s tax comes from: the tax on a line is resolved from the item and the pricing scheme, and this row is only the fallback the picker offers when that resolution returns nothing.

Credit Term and Credit Limit

A credit term and a credit limit are reusable master records; the tab attaches one of each to the supplier. Read Lifecycle and effects before you rely on them — on the purchase side neither is enforced by the backend.

Credit term — Code and Name are required. The due date is expressed as set and add parts: Set Year / Set Month / Set Day fix a component of the date, Add Year / Add Month / Add Day shift it. Credit Term Logic offers None or End of Month; choosing End of Month pre-fills Set Day = 1, Add Month = 2, Add Day = −1 — that is, the 1st of the document’s month, plus two months, minus a day, which lands on the last day of the following month.

Credit limit — Code, Name and Currency are required; Amount is validated against ^[0-9]*$, so it takes whole numbers only. Decimals, thousands separators and currency symbols are rejected silently by the pattern.

Company Linking

Company and AR/AP Type are both required; AR/AP Type defaults to AP_TRADE. The link also carries this supplier’s per-company Customer Code, Supplier Code, Employee Code and Merchant Code, so one entity can have a different code in each of your companies.

Item Pricing

Per supplier and item: entity item code and name, UOM, currency, purchase unit / min / max price (with and without tax), the sales equivalents, tax code and percentage, and withholding-tax code and percentage. This is the Entity Pricing data that Stock Replenishment reads when it picks a supplier and a price for a generated purchase order — links whose entity is inactive or not of type supplier are dropped from that selection.

Login tab

The tab takes the user email or phone number of the akaun.com identity to link, a Rank and a Status. Rank defaults to MEMBER.

The flow is: type the address, Verify (checks whether the login already exists), then either Send Invite for an email or Send Tac / Verify Tac Code for a mobile number, then Invitation Accepted to resolve the new subject and Save. Save is blocked until a subject has actually been resolved. With INSTALL_ALL_APPLETS_ON_INVITE on, a catalogue picker appears and the invitation asks for every applet in the chosen catalogues to be installed for the new user.

An invitation creates a pending registration, not a link — the row in the supplier ↔ login table is written only when the invitee follows the emailed link and confirms, along with any applet catalogues and roles the invitation carried. Invitation links do not expire, so an old one stays usable until it is used. Rank defaults to MEMBER; the vocabulary is OWNER, ADMIN, MANAGER, MEMBER, GUEST, VISITOR, ANONYMOUS.

Lifecycle and effects

A supplier is master data. It has a status (TEMP → ACTIVE / INACTIVE) and no journal of its own — creating, editing or deactivating a supplier posts nothing to the General Ledger and moves no stock. What the record does is supply values that other documents post with.

What the backend enforces on save (EntityDataConsistencyObject, create and update validator sets):

Codes and the TEMP status. Codes are normalised on save — upper-cased, trimmed and stripped of spaces. Running numbers are only allocated when the status is not TEMP, so a stub record never consumes a supplier number; the number is issued the moment you set a real status and save. The prefix in front of the running number comes from the tenant configuration row ENTITY_CODE_PREFIX / SUPPLIER, not from an applet setting (the applet’s own prefix control is commented out).

What the supplier contributes when a purchase document is finalised

Deactivating a supplier does not touch documents already raised against it. Creating, updating or deleting a supplier fires the SUPPLIER_CREATED / SUPPLIER_UPDATED / SUPPLIER_DELETED webhooks.

Deleting is blocked while money is outstanding. The delete endpoint refuses with HTTP 403 and CLIENT_ENTITY_HAS_OUTSTANDING_GENERIC_DOCUMENT when any active generic document for the entity still has a non-zero AR/AP balance. Otherwise the header is soft-deleted and the extension, line, login-link and payment-method rows are removed outright.

How the AR/AP type reaches a GL code

Posting is done by the document, not by this applet — this is what the supplier contributes to it.

1. Posting uses the effective AR/AP type: the company’s Company Linking value if it has one, otherwise the supplier’s own — so a per-company override always wins.
2. It maps that type to a transaction code: AP_TRADE → CREDITOR, AP_OTHER → CREDITOR_NON_TRADE, AP_MERCHANT → MERCHANT_PAYABLE, AP_EMPLOYEE → EMPLOYEE_OTHER_PAYABLE, AR_TRADE → DEBTOR, AR_OTHER → DEBTOR_NON_TRADE, AR_MERCHANT → MERCHANT_RECEIVABLE. Consignment flows ignore the entity’s type and use the document type’s own default instead.
3. The code is looked up in the company’s default GL codes. If there is none for it, posting fails with MISSING_DEFAULT_GL_CODE: CREDITOR (HTTP 400); if the company has no mappings at all, COMPANY_DEFAULT_GL_CODE_NOT_EXIST.

What credit terms and limits actually do

Sales and purchase credit terms are stored in separate tables, so a supplier that is also a customer keeps two independent sets. The entity header carries default_sales_credit_term_guid and default_sales_credit_limit_guid; there are no purchase equivalents.

Bulk load and extract

File Import takes one UTF-8 CSV with a chosen delimiter — PIPE, COMMA (preselected), SEMICOLON or TAB. Four columns are mandatory: SUPPLIER_NAME, SUPPLIER_TYPE, DOC_CURRENCY, ARAP_TYPE. Forty-one column names are recognised in total, covering supplier code, identity type and ID number, tax registration number, description, phone and email, a twelve-field billing block and a twelve-field shipping block, the self-billed flag, SST registration and tourism-tax numbers, SIC code, the e-Invoice tax identification number and the supplier category code. Column order does not matter, but a column name the importer does not recognise fails the whole file rather than being ignored. Sample Format downloads a template in the delimiter you selected.

Processing is two-stage: the file is parsed into per-row helper records, then each row is validated and created. Validation is all or nothing — if any row fails, the job ends FAILED and no supplier is created. Per-column messages such as “SUPPLIER TYPE is Invalid”, “DOC CURRENCY is Invalid” or “Supplier Category Code is Invalid” are rolled up into the row’s validation description, which the job’s Checking tab shows.

File Export generates a supplier CSV for a created-date range; the listing tracks status and offers download or delete per file. Files are capped at 1,000 rows — a larger extract is split into SUPPLIER_EXPORT_<timestamp>_PART<n>_OF_<total>.csv, each with its own header row. Only one export may be queued at a time; a second request is answered with “Please wait until the current file finishes before generating additional files.”

Upload Credit Terms and Upload Credit Limits are the same mechanism for attaching credit definitions to suppliers in bulk.

Entity merging

Merging is a platform function shared with customer maintenance, not something local to this applet.

1. On Entity Merging, choose a Merge Criteria — Entity Name, Entity ID No, Entity Phone or Entity Email — type at least two characters of a search term and optionally adjust the similarity threshold (0.7 by default). The grid stays empty until all three are supplied; the search is fuzzy, not exact-substring.
2. Results are grouped by the normalised criteria value. Open a group and mark exactly one entity Keep as main and one or more Merge and delete. The action is refused unless there is one main and at least one merge target.
3. Confirming queues the merge (IN_QUEUE), with the surviving record and the records being merged into it.
4. Entity Merge Processing shows the main and old entity codes and names, the merge status and a merged/total counter.

Two processors then run in sequence. The first swaps the entity GUID; the second refreshes the denormalised entity snapshots on generic document headers — the entity JSON, the sales entity name and code, the three person-in-charge slots, the delivery entity and the e-Invoice buyer and supplier blocks. The queue moves through IN_QUEUE → MERGING → DATA_REPLACING_IN_PROGRESS → SUCCESSFUL or FAILED; failures carry an error message on the row. The merged-away suppliers are set to INACTIVE, not deleted.

Self-billed e-Invoices and Peppol routing

When a purchase document is submitted as a self-billed e-Invoice, this record supplies the supplier party block: tax identification number, e-Invoice ID type and value, ID number, SST number, tourism-tax ID, industry classification code and business activity description.

Missing data does not raise an error — the document is diverted with a reason recorded against it. The reasons are, verbatim, “Supplier TIN is missing”, “Supplier id type is missing”, “Supplier id value is missing”, “Supplier id no is missing” and “Supplier business activity description is missing”. A blank SST or tourism-tax number is substituted with NA and a blank industry classification code with 00000, so those two never stop a submission — they just go out wrong.

The tax identification number is not validated against the tax authority when the document is generated; validation happens only in the separate TIN update and bulk-upload flows, so a wrong-but-present number surfaces as a rejection after submission.

For Peppol, the receiver on an outbound document is the participant ID flagged Default on this supplier. The lookup takes the first matching row with no tie-break, so flagging two IDs as default gives a non-deterministic result. There is no separate scheme field — the identifier scheme is fixed, so the ICD prefix (for example 0230:) has to be part of the participant ID string itself.

Related applets

• Customer Maintenance, Employee Maintenance, Merchant Admin, Entity Maintenance — the same entity table through other type lenses. Entity Maintenance can create a record with any combination of types and maintains the same category trees.
• Organisation — companies and branches for the linking tabs; the company-level e-Invoice, Peppol and knock-off configuration that governs what this master data can be used for.
• Chart of Accounts — the payable accounts the AR/AP type resolves to.
• Tax Configuration — tax codes for the Tax tab and Item Pricing.
• Cashbook — settlement methods used when the supplier is paid.
• Doc Item Maintenance, Inventory Item Maintenance, Pricebook — items and pricing referenced by the Item Pricing tab.
• Purchase Requisition, Purchase Order, Blanket Purchase Order, Purchase GIN — purchase documents that name the supplier.
• Purchase Invoice (Internal), Purchase Debit Note, Purchase Credit Note, Purchase Refund Note, Payment Voucher (Internal) — the payables side, which reads the AR/AP type and credit term.
• Purchase Report — supplier as a filter and grouping dimension.
• Consignment GIN, Consignment GRN — consignment counterparties are supplier entities.
• Stock Replenishment — chooses a supplier from Entity Pricing when generating replenishment purchase orders.
• Supplier Delivery Order — depends on the Login tab link.
• MY E-Invoice Admin, MY E-Invoice Portal, MyPeppol Admin — self-billed submission and Peppol routing built on the E-Invoice and Peppol Config tabs.

Troubleshooting

Related documentation

• Standard procurement workflow — where the supplier record is used end to end.
• Direct invoice workflow — buying without a purchase order.
• Purchasing module and Financial Accounting module.