Reimbursement Payment Voucher Applet (Internal)

Records money paid back to someone who spent it on the company’s behalf — a staff claim, a petty-cash top-up, an expense put on a personal card: what was spent on one tab, how you paid it back on another; posting it writes the cashbook transaction and the ledger entries. Unlike the Payment Voucher it raises no payee balance and no tax line: the debits are the expense lines before tax, so an expense line that carries SST or withholding tax leaves the entry unbalanced — the voucher is FINAL and the cashbook line posts, but no journal is written. Each expense line takes its GL code from the GL-code item you pick. The edit form offers FINAL only once the payment lines clear the expenses to zero. This posting has not yet been exercised in production use, so read the journal of your first voucher before you rely on it.

Your job, and the screen for it

Overview

It is a near-twin of the Payment Voucher (Internal) and shares its edit form, its settings screen and most of its tabs. The difference that matters is in the backend: this document type is not registered in the journal posting type map, so it never raises a creditor (accounts-payable) control entry. Read Lifecycle and effects before you design a chart of accounts around it.

Where it fits

Screens and menus

Edit-form tabs, in their default order: Main Details · Account · Expenses · ARAP · Payment · Payment Adjustment · Department Hdr · TraceDocument · Contra · Doc Link · Attachments · Export · Sales Commission. The order is configurable (see Default Selection), and the whole form can be rendered as a vertical accordion instead of tabs.

Six screens exist that nothing in the menus links to, so they open only if you type their address: File Import, Feature Visibility, Webhook, Team Permission, Client-Side Permission and Applet Log. File Import is also worth knowing about for a second reason: it imports into the Payment Voucher import batches, not batches of its own.

Screenshots needed

Screenshots of this applet are still to be captured. A capture session should take: the voucher listing showing the ARAP columns; Main Details; the Expenses tab with two or three lines; Add Line Item; the Payment tab; the ARAP tab; the Intercompany screen with both tabs; Settings → Application Settings; and Settings → Default Selection with the tab-ordering list. Use a scratch tenant — the listing shows payee names.

Configuration

Before you can use it

Applet settings

Settings live on the shared settings screen (Application Settings), plus four screens of this applet’s own: Default Selection, Printable Format Settings, Email Template and Release Notes. Only a tenant administrator with the applet’s settings open can change them; there is no per-row authority difference.

The shared screen shows 274 controls for this applet code, and a large share of them do nothing here. The tables below document the keys the applet actually reads; a few of those have no control (see the next table).

Application Settings — what the applet reads

Read at runtime with no control on this applet’s settings screen

These keys change what the applet does, but the shared Application Settings screen renders no control for them under the applet code internalReimbursementPaymentVoucherApplet:

The four make-mandatory switches for segment, dimension, profit centre and project do have controls: each appears beside its dimension’s hide switch while that dimension is not hidden.

Default Selection (applet) and Default Selection (personal)

A personal default beats the applet default for that user. RESET does not do the same thing on the two screens:

• On the applet screen it clears branch, location and company but keeps the tab order as it stands — to get the default order back, drag it back by hand.
• On the personal screen it writes empty values rather than removing yours, and because personal values win, an empty personal branch appears to hide the applet’s Default Branch from that user too (read, not run). If a user reports that new vouchers stopped pre-filling after they pressed RESET, that is the likely cause; ask an administrator to check the applet default is still set, then have the user pick the branch on their own screen.

Printable Format Settings and Email Template

Printable Format Settings lists the printable formats (Default Selection tick, Format Code, Format Name, File Name, File Size, Uploaded Date, Uploaded By) and stores the ticked one as PRINTABLE. Email Template lists the e-mail templates (Template Code, Status, Created Date, Created By); templates created here print through the payment/receipt voucher layout.

Document behaviour settings

On the edit form, FINAL is offered only when all of the following hold:

• the document is not inside a locked financial filing period;
• HIDE_GENDOC_FINAL_BUTTON is off, or the user holds the client-side permission SHOW_GENDOC_FINAL_BUTTON;
• header status is ACTIVE and posting status is empty or DRAFT;
• there is at least one payment line;
• the document’s open amount is exactly zero — that is, the payment lines fully clear the expense lines.

The last two are the ones that surprise people: a voucher with expenses and no payment, or with a part payment, simply has no FINAL button and no message explaining why.

The listing’s FINAL (tick rows, then FINAL) applies a looser rule: it holds back a row only when the voucher has no payment line and a non-zero open amount. A part-paid voucher — one payment line, Doc Open not zero — is finalised from there. Because this document type has no payee line to absorb the difference, its journal then fails to balance: the voucher reads FINAL, the cashbook line for the part payment posts, and the voucher’s own Trace Document tab shows an empty Journal Txn grid. No screen says why: the journal failed on unequal debits and credits. Check Doc Open reads zero on every row before you finalise from the listing. The rule lives in the screens; the server’s finalise does not check payment lines or the open amount.

Who can change what

No client-side permissions are defined for this applet. It checks four client-side permission codes — SHOW_GENDOC_FINAL_BUTTON, SHOW_GENDOC_DISCARD_BUTTON, SHOW_GENDOC_VOID_BUTTON, SHOW_EDIT_SETTLEMENT_FINAL — and none of them can be granted until they are defined. In practice that means every HIDE_* button switch above is an all-or-nothing tenant-wide switch with no per-role exception, and the Payment Adjustment tab cannot be turned on at all.

Server-side, the document type is guarded by its own four target permissions (TNT_API_DOC_INTERNAL_REIMBURSEMENT_PAYMENT_VOUCHER_CREATE/READ/UPDATE/DELETE_TGT_GUID), registered in GenericDocumentTypeHandler against the endpoint path internal-reimbursement-payment-vouchers. The listing’s Add button and the edit form’s SAVE button are additionally disabled when the user’s resolved create / update permission targets are empty. Note that the descriptions on all four permission constants read “internal payment voucher” — they are the reimbursement ones despite the wording.

Fields

Main Details

Changing Transaction Date also moves the date on every payment line. The switch that lets a payment line keep a date of its own has no control on this applet’s settings screen, and even set through the API it changes only the form: every save resets each line’s date to the voucher’s Transaction Date, and the cashbook line always carries the voucher date. Date the voucher on the day the money left.

A new voucher is only a draft until Branch, Location, Currency and the payee on the Account tab are all filled — at that moment it saves itself as an active voucher, before you press SAVE. One you then abandon by closing the form stays behind as an unposted voucher; discard it instead.

Account — picks the entity being paid, through the Select Supplier listing, with billing-address and shipping sub-panels.

Expenses — the line grid. The item picker lists only GL-code items, and the line takes that item’s GL code; each line also carries quantity, prices, discount and tax configuration. Sub-panels cover serial, bin and batch numbers, costing details, issue link, pricing details, delivery details and department.

Payment — the settlement lines (STL_MTHD): which settlement method and cashbook paid the claim back, and how much.

ARAP — five read-only figures: PNS, Settlement, Doc Open, Contra, Bal.

Contra — select another open document and clear part or all of it against this one.

Payment Adjustment — only present when ENABLE_EDIT_SETTLEMENT_FINAL, the SHOW_EDIT_SETTLEMENT_FINAL permission and posting status FINAL all hold.

Lifecycle and effects

What posting does

No purchase journal mapping. Unlike the Payment Voucher, this document type has no journal mapping of its own and does not fall back to the sales or purchase one. So it has no supplier, tax, return, discount or stock line to post to. Three consequences:

1. No creditor line. The voucher raises no accounts-payable balance. That is consistent with what a reimbursement is — you are paying, not accruing — but it also means there is no creditor line to absorb any difference the way it does on a Payment Voucher. Whatever the debits and credits do not match on, the journal fails.
2. No tax line — and a taxed line stops the journal. Expense lines post their amount before tax, while the payment that clears them is the line total: amount + SST − withholding tax. A voucher with RM 500.00 of expenses carrying 6% SST is paid RM 530.00; the journal holds Dr RM 500.00 against Cr RM 530.00 and is refused as unbalanced. The voucher still reads FINAL and the cashbook line for RM 530.00 still posts, so the bank side looks complete. The only sign is an empty Journal Txn grid on the voucher’s Trace Document tab; the reason, unequal debits and credits with both totals, is recorded where no screen shows it, and BigLedger support can read it. Withholding tax does the same in the other direction. Keep SST and withholding tax off this document: record a claim that carries recoverable tax on a Payment Voucher or a purchase invoice.
3. Expense lines need a GL code from their item. A line with no GL code of its own falls back to the item’s and the company’s defaults, and neither ever matches here. If the header carries no GL code either (it cannot from the form), the line is left out of the journal — and the journal then fails to balance, as in point 2.

After FINAL — the status change is saved first and only then does the main posting job start — the follow-on jobs your tenant has switched on run, subject to the company’s include / exclude list and to each job’s own document types. Before the journal is saved, lines are merged by sub-ledger + branch + dimension + profit centre + project + segment + description, rounded to two decimals, and checked: unequal debits and credits fail with TOTAL_DEBITS_AND_TOTAL_CREDITS_NOT_BALANCES and both totals in the message; a journal with nothing in it fails with NO_JOURNAL_CREATED. Either fails the job, not the FINAL: the voucher stays FINAL with no journal. Nothing on screen reports it. The voucher’s Trace Document tab shows an empty Journal Txn grid, and the reason is recorded where only BigLedger support can read it. Financial Report › Error Checking › Trace Document finds the voucher and shows its posting statuses, but its Missing Journal check reads Unsupported document type and offers no Resolve.

Intercompany. As a source document this voucher has no intercompany pairing defined. A counterpart raised from it gets zero quantity and amount signs, and carries the expense lines only — payment lines are copied only when the source is a Payment or Receipt Voucher. That is read from the code, not run: test a counterpart on a scratch company before you rely on an intercompany configuration that names this voucher as its source. What follows is how the two Modes of a branch intercompany configuration behave.

In AUTO mode the intercompany job creates the target document as soon as the source is finalised and links the pair itself; nothing is queued and there is nothing to confirm.

In MANUAL mode it adds one UNPROCESSED row to the Intercompany screen and stops. Nothing ever clears that row automatically. It leaves only when a person opens the Intercompany screen, selects it and presses Confirm Intercompany Transaction — that is what MANUAL means, and it is the point of the mode: the counterpart document in the other company is somebody’s decision, not a sweep’s. The pair then appears on the PROCESSED tab. (The intercompany auto-stock job works a different queue entirely; do not expect it to touch this one.)

So put someone on that screen, and make it a standing job rather than something you react to. An UNPROCESSED row waits indefinitely: nothing ages it, nothing escalates it and nothing tells anybody it is there, so a voucher whose counterpart document was never raised looks exactly like one whose counterpart was — from every screen except this one. If a configuration fails while it runs, the row is written with status ERROR and the error text — but the screen shows neither: the Unprocessed listing has no status or error column, so a failed row looks exactly like one waiting to be confirmed. Since AUTO never leaves a row there, a row whose Used Config is an AUTO configuration is a failure, and that row needs a person too.

Related applets

• Payment Voucher (Internal) — the same form for supplier payments. It does have a journal mapping, so it raises the creditor line, the purchase line and the input-tax line that this applet does not.
• Receipt Voucher (Internal) — the money-in counterpart.
• Cashbook Applet — the cashbooks and settlement methods a payment line can use.
• Bank Reconciliation Applet — where the resulting cashbook transaction is matched to the statement.
• Chart of Accounts — the GL codes the expense lines must carry.
• Employee Applet — Checked By and Approved By.
• Supplier Applet — the entity on the Account tab.

Troubleshooting

Related documentation

• Bank Reconciliation Guide
• Financial Accounting module