Credit Approvals

1Overview #

Licence. Credit Control is a feature of Finance and Accounts, bought on its own. Without it this page and the ledger's Credit Limit button are not offered, and vouchers are saved without the credit-limit and overdue checks.

2Purpose #

The credit limit is a hard stop inside the voucher save. Before this page, the only way past it was editing the master limit - permanent, and gated by master-edit rights. A ticket instead records the exception AS an exception: who asked, who granted how much, for how many bills, and which bills rode it - the four-eyes trail an auditor asks for.

This page only moves tickets. The effective limit itself is computed in the database, where the save procedure, the alerts, the customer portal and the reports all read the same figure - none of them can disagree.

3Step by step - the whole journey #

1. An outward voucher fails to save with a Credit Limit variation - the transaction screen offers Request approval , which raises the ticket with the block's own figures. (A ticket can also be raised here with Raise a ticket . Pick the party and its credit position appears at once - balance, credit limit, any live grant, what is available or how far it is over, the credit period with its overdue bills, and whether a ticket is already waiting. Key the blocked bill's value and a With this bill line shows where that bill would leave the account. The panel names the ledger that is actually selected, so a similarly named account cannot be raised against by mistake.)
2. The ticket lands on this page as Pending . At most one pending ticket per account - a re-attempt returns the standing ticket's number instead of a twin.
3. An approver opens Decide : the allowed deviation (seeded with the shortfall), how many bills it covers, an optional last-valid date, remarks. Approve or Reject (a rejection requires a remark - the requester reads why). The app-wide dialog keys apply: F5 presses the primary button (Approve here, Raise on the raise dialog, Request approval on the transaction screen's prompt), Esc closes.
4. The operator saves the same voucher again - no special path; the check now reads limit + deviation and admits it.
5. Every outward book-affecting voucher of that party burns one of the N bills, inside the save itself. At N the grant flips to Exhausted ; the register shows exactly which bills rode it.
6. Cancel withdraws a pending ticket (its raiser or an approver) or kills a live grant early (approvers only).

4Who may decide #

• The account's own approver , when one is keyed on its credit-limit record.
• Anyone on the fallback approver list - General Settings item 211, comma-separated user IDs.
• Any administrator .
• Four eyes : the user who raised a ticket may not approve it, unless setting 212 allows self-approval (administrators are exempt).
• The largest N-bills a single grant may carry is setting 213 (10 unless changed).

5Field details #

• Balance / Limit at block / Exceeded by - the figures the save computed at the moment it refused, pending linked vouchers included where the voucher types are flagged for the check. The approver decides on the number the save saw.
• Allowed deviation - the temporary amount ABOVE the limit. Must be above zero; it is seeded with the shortfall rounded up.
• Valid for next N bills - how many subsequent outward bills the grant covers. ALL of them count, not only over-limit ones: "the next N bills" means what it says.
• Valid until - an optional calendar cap; the grant dies at whichever of N-bills or the date comes first. Blank = no date cap.
• Bills - consumed of granted, live from the books. Status : Pending, Approved (the live grant), Rejected, Exhausted, Cancelled.

6Credit modes - Block, Warn, Approval #

• Block (and any legacy value, and blank) - the hard stop, exactly as it always was.
• Warn - the save proceeds and the limit is advisory. Note the stock alerts read the same rule, so they stand down for a Warn account too.
• Approval - the hard stop plus this page's ticket path.
• The mode is keyed per account on the credit-limit record (the ledger master's credit section).

7Why is this page empty? #

• No tickets yet is the normal state: tickets only rise when a save is actually blocked for a party whose limit is keyed. An account with limit zero, or none, is NOT limited - key the limit on the ledger master first.
• No Decide buttons means you are not an approver for the listed tickets - see Who may decide .

8Rules and integrity #

• At most ONE pending and ONE live grant per account, enforced by the database itself - approving a second grant while one lives is refused, naming the live ticket.
• Grant consumption happens INSIDE the voucher save's own transaction - a failed save never burns a bill, and a bill burned is recorded with its voucher in the usage audit.
• Cancelling a voucher later does NOT hand its bill back - a grant spent is spent.
• Every refusal lists ALL its reasons at once, numbered - fix the lot, not one per attempt.
• Raising a ticket writes a notification alert riding the blocked voucher's type; the ticket itself is the record either way.
• Decisions are stamped - who, when, remarks - and a decided ticket never changes again; the register keeps the full story.

9If something does not work #