Supplier

A supplier must exist here before any purchasing document, payment voucher or self-billed e-Invoice can name them. Suppliers, customers, employees and merchants share one entity record, so the same business can be your supplier and your customer at once — the Entity Type field on the Main tab decides which.

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).

The record saves itself as ACTIVE once three fields hold a value. On current builds (the change landed in December 2025), Supplier Edit watches Supplier Name, Currency and AR/AP Type; the moment all three are filled on a TEMP record it sets the status to ACTIVE and saves, without waiting for you to press Save. This mirrors the Customer applet and is deliberate: a supplier you have named is a supplier, not a stub. Two things follow. AR/AP Type arrives pre-filled (AP_TRADE unless DEFAULT_AR_AP_TYPE says otherwise) and Currency does too when DEFAULT_CURRENCY is set, so on such a tenant the first pause while you type the name is enough — the record is then ACTIVE, and if you left the Supplier Code blank it has taken a number from the supplier running number, even if you close the form straight away. And a record abandoned before a name is typed stays TEMP. Pressing Save on a TEMP record also saves it as ACTIVE. If you want a supplier kept out of purchasing until it is checked, set it to INACTIVE after that first save.

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 › Application Settings (the screen’s route is 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.

The TIN matters for suppliers you do not self-bill too. When a purchase document is finalised for a company with e-invoicing enabled, a background job adds it to the list of purchases awaiting the supplier’s own e-invoice — but only if this record carries a TIN. A supplier without one is left off that list silently, for all three of GadgetSphere’s companies at once, since they share the record (Supplier e-invoices).

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 and leaves Set Year and Set Month empty. That does not give the last day of the following month. With Set Year and Set Month empty the Set group is not a real date, so the arithmetic falls back to the document’s transaction date and adds the Add parts to that: a 10 March document gives 9 May, not 30 April. The word End of Month itself is kept for reference only; nothing computes a date from it. Work one example by hand before you rely on the term — Credit limits and terms, Step 1 explains the arithmetic. A purchase invoice stores no due date at all, so no purchase document will show you the result.

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.

Once a company has a link, the link decides. Because the form will not save a link without an AR/AP type, every link carries one, and posting takes the link’s type ahead of the Main tab’s for that company. So after you link a supplier to a company, changing AR/AP Type on the Main tab changes nothing for that company: edit the link instead. The form refuses a second link to the same company for the same supplier. Customer Maintenance writes to the same list of links, with the receivable trade type as its default, and a link added there shows here too — see One supplier, three companies, two roles.

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 (on create and on update) — a save that breaks any of these is refused:

• Status must be present.
• Supplier Type must be exactly INDIVIDUAL or CORPORATE.
• AR/AP type must be present — when it is not, the backend fills in AP_TRADE for a supplier (and AR_TRADE for a non-supplier) before validating.
• Supplier Code must be unique among non-deleted entities.
• Supplier Nickname must be unique among suppliers.
• The internal supplier id must be unique among non-deleted entities.
• A supplier code may not be set on a record that is not flagged as a supplier.
• A referenced consolidated AR/AP account must exist.

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 at the first save as ACTIVE — which Supplier Edit does by itself once name, currency and AR/AP type are filled (see Creating a supplier). 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 is refused 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 — but only when the document’s other lines leave something to balance; a document whose lines total zero needs no supplier line and posts without one. If there is no default for the code, the document still goes FINAL; the journal posting that runs after it fails with MISSING_DEFAULT_GL_CODE: CREDITOR and the document is left FINAL with no journal. If the company has no mappings at all, the posting fails because the company has no default GL codes.

One supplier, three companies, two roles

GadgetSphere’s three companies share one supplier master: a supplier is one record, whichever company buys from it. Take one of its 1,200 suppliers, for example, an accessory wholesaler billing in ringgit.

• GadgetSphere Distribution (GSD) buys stock from it — about RM 40,000 a month on 60-day terms. That is trade, so the Main tab’s AR/AP Type stays at the trade payable default, and GSD’s purchase invoices credit your trade creditors account, LIAB-SUPPLIER-TRADE.
• GadgetSphere Sdn Bhd (GS) buys only shop-display fixtures and co-op marketing from it. Those are not stock purchases, and your accountant wants them in non-trade creditors. Add a Company Linking row for GS with the non-trade payable type: GS’s invoices now credit non-trade creditors while GSD’s still credit trade creditors, from one record. That is what the per-company type is for, and it beats a second supplier record, which would split the wholesaler’s documents, contacts and e-invoice details between two.
• The wholesaler also buys from you. GSD sells it about RM 5,000 a month of returned demo stock, so somebody adds Customer to its Entity Type. Change nothing else, and GSD’s sales invoice to it debits the same trade creditors account: the RM 5,000 comes off the RM 40,000 you owe, and the account shows RM 35,000, the amount you will actually pay. It is a contra without a contra document, and for a partner you trade with both ways it is usually what you want.

The trap is the fourth step nobody plans. Months later someone in sales opens the same record in Customer Maintenance and adds a company link for GSD there. That form defaults a link to the receivable trade type, and the link now wins for GSD in both directions. The next RM 40,000 purchase invoice credits your trade debtors account: trade creditors is RM 40,000 below the wholesaler’s statement, and trade debtors carries an RM 40,000 credit nobody can place. Nothing fails and nobody is told — both accounts exist and the journal balances.

Where the number came from: the payable account is not stored with the supplier’s invoices; each posting reads the type as it stands when the posting runs. So the fix is the link’s type, and it only moves what posts next. Invoices already posted keep their journals until you rebuild them: Repost beside Posting Journal in Financial Report › Error Checking › Trace Document deletes an invoice’s journal and builds it again from the invoice with the type as it now stands (Purchase Invoice (Internal)). A correcting journal is the other way.

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. The check stage is all or nothing — if any row fails a check, the job ends FAILED before a single supplier is created. Once the checks pass, rows are created one at a time, and a row that fails there is marked failed and the job ends FAILED without undoing the rows already created. So a FAILED job does not always mean nothing happened: before you upload the same file again, search for the codes in the file to see which rows are still missing. 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.

An import updates as well as creates, and the supplier code decides which records it can touch.

An update writes every value the row carries, and four values are always carried, because the check stage refuses a row without them: the name, the supplier type, the currency and the AR/AP type. So a matched record always takes the sheet’s AR/AP type — for a customer that also sells to you, its sales invoices then post to the payable account (the worked example above shows what that does to two control accounts). Unlike the customer import, a blank AR/AP type is refused at the check stage rather than read as a default. A misspelt one passes the checks and fails that row when it is saved.

Prevention: before you load into a populated master, check the sheet against your customers by registration number. For each business you already hold, open that customer record, add Supplier to its Entity Type and set the AR/AP type yourself; take it out of the sheet. Give every remaining row a supplier code, so that none of them can land on a record you did not mean. Load five rows first and open what they changed.

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.

How you know a supplier is ready for the first purchase invoice

About two minutes, on a supplier you have just set up or imported:

1. Company Linking tab. For each company with a row, that row’s AR/AP type is what the company posts with; for a company with no row, it is the Main tab’s. Read them as an accountant would — trade or non-trade, and never a receivable type unless you mean the supplier’s purchases to net against what it owes you.
2. The company’s default GL codes. In Chart of Accounts, each company that will buy from the supplier has a GL code for the creditor key that type maps to — trade creditors for the trade payable type, non-trade creditors for the non-trade one.
3. Reopen the record and look at Email. If it is empty although you typed one, the tenant has never saved Application Settings and the address was not stored (Applet settings).
4. E-Invoice tab, TIN. Filled for any supplier that issues e-invoices to you, so its purchases reach the matching list; for one you self-bill, also the ID type and value, the ID number and the business activity description, the fields whose absence diverts a self-billed document.
5. After the first purchase invoice is finalised: open it in Purchase Invoice (Internal) and check that its journal is posted and that the journal’s credit lands on the payable account you meant — LIAB-SUPPLIER-TRADE for a trade supplier — for the invoice total less anything paid on its Payment tab. An empty journal is the missing-mapping case in How the AR/AP type reaches a GL code.

When all five hold, the supplier’s invoices post to the account you chose, reach the e-invoice matching list, and the record holds the contact details you typed.

What stays your job

• Deciding each company’s payable type. BigLedger posts with whatever type it finds; whether the wholesaler is trade for GSD and non-trade for GS is the accountant’s decision. Whoever owns the supplier master reviews the Company Linking rows of any record that is also a customer once a quarter, since a link added from Customer Maintenance changes them without anyone opening this applet.
• Checking bank details before money moves. The Payment Config tab records the account you type; nothing on it confirms the account belongs to the supplier. Before the first payment to a new account, or after a change, confirm it with the supplier on a phone number you already held, and keep the person who edits supplier bank details apart from the person who releases payments.
• Choosing what a bulk load may touch. The importer matches on whatever it is given (see Bulk load and extract); deciding which rows are new and which are businesses you already hold is done before the upload, not after.

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.