Reimbursement Payment Voucher Applet (Internal)

Overview

The Reimbursement Payment Voucher records money paid back to someone who spent it on the company’s behalf — a staff claim, a petty-cash top-up, an expense a branch manager put on a personal card. You list what was spent on the Expenses tab, record how you paid it back on the Payment tab, and finalise. BigLedger then writes the cashbook transaction and the journal.

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.

Four routes exist that nothing in the UI links to, so they open only if you type the URL: File Import (file-import — its menu entry is commented out in menu-items.ts), Feature Visibility, Webhook, Team Permission, Client-Side Permission and Applet Log. The last five are not linked because the shared settings navigation has those <li> entries commented out. File Import is also worth knowing about for a second reason: it reads and writes bl_fi_internal_payment_voucher_import_file_hdr — the Payment Voucher import table — not a table of its own.

Screenshots needed

No screenshots exist for this applet. 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 FieldConfigurationComponent from blg-shared-utilities (imported directly in app.routing.ts as Application Settings), plus four applet-local screens: Default Selection, Printable Format Settings, Email Template and Release Notes. Only a tenant administrator with the applet’s settings route open can change them; there is no per-row authority difference.

Measured at commit 8faf206 against blg-shared-utilities HEAD: the shared screen renders 298 controls for this applet code, of which 102 are actually read by this applet. Those 102 are the ones documented below. The remaining 196 render but are inert here.

Application Settings — what the applet reads

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

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

Default Selection (applet) and Default Selection (personal)

Both screens have a RESET button that writes nulls back. The applet screen dispatches saveMasterSettingsInit; the personal screen dispatches savePersonalSettingsInit.

Printable Format Settings and Email Template

Printable Format Settings lists bl_prt_printable_format_hdr (Default Selection tick, Format Code, Format Name, File Name, File Size, Uploaded Date, Uploaded By) and stores the ticked row’s GUID as PRINTABLE. Email Template lists bl_applet_notification_template_hdr (Template Code, Status, Created Date, Created By); templates created here are bound to the print service class PAYMENT_RECEIPT_VOUCHER_PRINT_SERVICE.

Document behaviour settings

FINAL is offered only when all of the following hold (showFinal()):

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

Feature visibility / permissions

bl_applet_client_side_perm_dfn holds zero rows for internalReimbursementPaymentVoucherApplet (checked 2026-09-14). The applet 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 ever be true on a live tenant until those definitions are seeded. 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

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

Expenses — the line grid. Each line carries an item, quantity, prices, discount, tax configuration and, critically, its own GL code; 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

Posting proof

The missing sub-ledger map. JournalPostingTypeHandler.handlers contains seven document types: SALES, PURCHASE, INTERNAL_PURCHASE_GRN_STOCK_IN, INTERNAL_RECEIPT_VOUCHER, INTERNAL_PAYMENT_VOUCHER, PURCHASE_CONSIGNMENT and INTERNAL_STOCK_ADJUSTMENT. INTERNAL_REIMBURSEMENT_PAYMENT_VOUCHER is not among them, and the fallback in JournalPostingService only rescues a type whose name contains the substring SALES or PURCHASE. So every sub-ledger code — pns, pnsTax, pnsReturn, pnsDiscount, pnsEntity, pnsStock — resolves to the empty string (getSubLedgerCode returns "" when the handler list is empty). Three consequences:

1. No creditor line. The debtor/creditor journal line is written only if (StringUtils.isNotBlank(pnsEntity) && StringUtils.isNotBlank(arap)). With pnsEntity empty it is never written, so the voucher raises no accounts-payable balance. That is consistent with what a reimbursement is — you are paying, not accruing — but it also means the creditor line cannot absorb any imbalance the way it does on a Payment Voucher.
2. No tax line. The tax journal line is written only if (StringUtils.isNotBlank(pnsTax)). SST or withholding tax captured on an expense line does not reach the general ledger from this document.
3. Expense lines need their own GL code. When a PNS line has no guid_glcode, posting falls back to the item-company link and then the company default, both filtered on the (empty) txn code, so neither matches. If the header carries no GL code either, the line ends with no sub-ledger and Optional.ofNullable(line.getSub_ledger_guid()).ifPresent(...) drops it from the journal without a word.

At FINAL, the generic-document primary processor fans out to whichever subscriber job processors are enabled for the tenant, filtered by the company’s posting_final_json (includeJobProcessorCode / excludeJobProcessorCode) and by each subscriber’s own server-doc-type constraint. Before the journal is saved, lines are merged by sub-ledger + branch + dimension + profit centre + project + description, rounded to two decimals, and checked: unequal debits and credits throw TOTAL_DEBITS_AND_TOTAL_CREDITS_NOT_BALANCES with both totals in the message; a journal with nothing in it throws NO_JOURNAL_CREATED.

Intercompany. A finalised voucher that matches a branch intercompany configuration lands in bl_fi_mst_intercompany_processing_queue. It stays there until either the processor runs or someone selects it on the Intercompany screen and presses Confirm Intercompany Transaction; the resulting pair is then visible as a bl_fi_generic_doc_intercompany_link row on the PROCESSED tab.

Related applets

• Payment Voucher (Internal) — the same form for supplier payments. It is registered in the journal posting type map, so it raises the creditor line, the purchase sub-ledger 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