Deposit Applet

Records money market deposit placements — company cash placed with a financial institution for a fixed term at an agreed rate — from the request for quotes to the live placement and its computed interest schedule. Its own records never reach the ledger: the ledger effect comes from the payment voucher that pays the bank and the receipt voucher that receives the money back, which are linked on the Payment/Receipt tab and never created by it. Rollover is manual only, and a rollover always carries the full maturity amount forward as the new principal.

Overview

The Deposit Applet records money market (MM) deposit placements — company cash placed with a financial institution for a fixed term at an agreed interest rate. It is a treasury register, not a posting document: it keeps the terms, the invited counterparties and their quotations, a computed interest schedule, and links to the cash documents that actually moved the money.

The applet has three menus — a requisition (the request for quotes), a register (the live placement), and a category (a grouping label).

Where it fits

Screens and menus

The applet has exactly three menus. The title shown in the layout header is Money Market Deposit Applet.

The applet opens on MM Deposit Requisition. There is no settings menu — see Configuration.

MM Deposit Requisition

The listing shows active requisitions, most recently updated first. Columns: Doc No., Deposit Name, Deposit Code, Company, Amount Initial Deposit, Amount Upon Maturity, Interest Type, Currency, Interest Rate (%), Interest Rate Effective (%), Est. Interest Amount, Est. Start Date, Est. End Date, Posting Status, Status.

Pressing + creates a row on the server immediately, with status TEMP, before you type anything, and the screen jumps straight to Edit MM Deposit Requisition.

The edit screen has two tabs:

• Details — the form documented under Fields.
• Invitee — hidden while the row is still TEMP; appears after the first SAVE. A grid of the invited institutions, with + and row-click both opening the same Edit Invitee panel.

Action buttons on the requisition: FINAL (shown only while the row is ACTIVE and not yet FINAL) and SAVE. A DELETE button exists in the code but never appears on a requisition.

MM Deposit Register

The listing shows registers, most recently updated first. Columns: Deposit Name, Company, Posting Status, Deposit Date, Maturity Date, Principal Amount, Interest Rate (%), Interest Rate Effective (%), Interest Earned, Interest Amount, Amount Upon Maturity, Rollover. There is no document-number column because the register has no running number (see Lifecycle).

+ creates a TEMP register row on the server the same way the requisition does, then opens Edit MM Deposit Register with five tabs. The last four are hidden while the row is still TEMP:

Action buttons on the register: FINAL, Select Requisition, SAVE (all three hidden once posting status is FINAL; Select Requisition is also hidden when the register is INACTIVE). The DELETE button never appears on a register either.

MM Deposit Category

A single-tab master-data screen. The listing shows Category Code, Category Name, Posting Status, Created Date, Updated Date, Status. The edit screen has SAVE, FINAL (while the row is ACTIVE and not yet FINAL) and a working DELETE (two clicks to confirm; shown whenever status is ACTIVE, regardless of posting status).

Configuration

Before you can use it

Applet settings

This applet has no settings screen. The settings gear and the Personalization link are hidden in the sidebar for every user, owners and admins included, and no settings screen is reachable by any route.

Consequently there is no Application Settings screen, no Default Selection, no printable format configuration and no configurable e-mail template in this applet. The invitation e-mail body is fixed and is not editable from the product.

Settings read at runtime without a control

Three applet-settings keys are honoured by this applet’s screens. Because there is no settings screen, they cannot be set from inside the applet — ask support to set them for your tenant. All three are off by default.

Feature visibility and permissions

There is no client-side feature gating in this applet and no menu hiding. Everything is enforced server side, through the permission codes below, which you assign in the Permission Set screen.

Starting a new requisition with + checks API_TNT_BUDGET_VOTEBOOK_CREATE rather than a deposit permission, so a user needs that permission as well before they can begin a requisition.

Fields

Two screens capture placement terms and one captures a grouping label. Each is named in a sentence below; the table under it holds only the fields that behave in a way the screen does not show. Every rule listed is enforced by the form in the browser — the backend validates none of them (see What the backend actually validates).

Requisition — Details tab

The form takes the identification (Server Doc No, Deposit Name, Deposit Code, Company, GL Code, Currency, Requisition Status), the money (Amount Initial Deposit, Amount Upon Maturity, Interest Amount, Inflation Rate), the interest terms (Interest Type, Interest Payout Frequency, Interest Calculation, Interest Rate, the four Interest Rate Reference fields, Interest Rate Effective, Interest Convert to Principal), the dates (Est Start Date, Est End Date, Term (Days)), Auto Rollover Logic, and four read-only audit fields. Amount Upon Maturity, Interest Amount, Interest Rate Effective and Term (Days) are read-only. Inflation Rate and Interest Rate Reference Source are the only typed fields that are never required; the rate fields become required or stop being required as Interest Calculation changes.

Requisition — Invitee tab

One row per invited institution. The panel repeats the requisition’s terms so the recipient’s quotation can be compared against them, but only three controls accept input:

The grid above the panel is the one you compare quotes in, and its ten columns are all deposit terms — Deposit Name, Deposit Code, Currency, Interest Type, Interest Rate (%), Interest Rate Effective (%), Amount Initial Deposit, Amount Upon Maturity, Est. Start Date, Est. End Date, plus Actions. There is no Entity Name, Email Address or Winner column, so until quotations come back every row looks identical and the institution behind each one is visible only by opening it.

Everything else on the panel — amounts, currency, interest type, rates, dates, Term (Days), Interest Convert to Principal, Auto Rollover Logic, status, inflation rate — is read-only, so an invitee row cannot drift from its requisition through this screen.

Register — Details tab

The register repeats the requisition’s interest terms and dates and adds Financial Institution, Deposit Category, Deposit Status, Principal Amount, Interest Earned, Rollover options, GL Code for Interest, GL Code for Interest Expense, Collaterals, Approval Workflow, Description and Supervisor Remarks. Deposit Name, Deposit Category, Company, GL Code, Principal Amount, Currency, both dates, Deposit Status, Interest Convert to Principal and Auto Rollover Logic are required; the free-text fields and Inflation Rate are not. The interest fields behave exactly as on the requisition — the same rules apply. What differs here:

Register — Transaction line (Edit Transaction panel)

+ on the Transactions tab opens a seven-field panel — Transaction Type, Transaction Date, Total Amount, Principal Amount, Interest Amount and GL Code, all required, plus an optional Description. Clicking a row opens the same panel on an existing line. Three things about it are invisible from the screen, and each one costs somebody an afternoon.

The tab shows at most 25 lines, ever. The tab loads the first 25 lines, oldest first, and never loads any more: the paginator above the grid pages the 25 rows already in the browser, and the search box filters those same 25. A MULTI deposit paying daily over a 90-day term generates about 95 lines, so its Interest Capitalized rows, the Principal Return and both SUMMARY totals are simply not reachable from this tab. Ask for the whole schedule through the API, or through support, when you need it.

Editing a generated line blanks five of the grid’s ten columns. The panel saves twelve fields and leaves Name, Remarks, Amount, Currency and Deposit Txn Type Code blank — and the save replaces the whole line rather than merging into what was stored, so those five columns are wiped. Correct one interest figure and the line loses its Name (Interest Earned), its Remarks, its Amount, its Currency and its Deposit Txn Type Code, and its Created date is reset to now. Amount (Total), Amount (Principal) and Amount (Interest) survive, so the row still looks plausible in the grid.

The Transaction Type list cannot express what FINAL wrote. The drop-down offers Debit, Credit, Adjustment, Principal and Interest. FINAL writes Debit, Credit or SUMMARY — so opening either summary line shows an empty, required Transaction Type and SAVE stays disabled until you pick one of the five, which changes what the line claims to be. A line you add by hand gets no Deposit Txn Type Code at all, so it is not a PLACEMENT / INTEREST / INFLATION / COMPOUND / MATURITY / SUMMARY row and anything grouping by that code will not count it.

And the two SUMMARY lines are written once, at FINAL, and never recomputed. Correct an interest line by hand and Total Interest Earned still reports the old figure.

Category — Details tab

Category Name and Status are required; Category Code and Description are not. Despite the listing having a Category Code column, the form puts no validator and no uniqueness check on it, so blank and duplicate codes both save. The category is referenced from a register by its identifier alone, and the only backend check anywhere is that the category still exists — the category name never reaches the register. Created and modified stamps are read-only.

Where these numbers come from

Amount Upon Maturity and Interest Amount are never typed. Both forms send the current form values — not what was last saved — to BigLedger for calculation; the reply carries the maturity amount and the total interest and nothing else, and the form rounds both to two decimals.

The call is made only when principal, Interest Type, Interest Calculation and Term (Days) are all present, plus Interest Rate for FIXED or Interest Rate Effective for FLOATING. Miss one and no call goes out. On the register the two fields are cleared to null before every call, so a call that fails leaves them blank with nothing on screen to say why — the failure is written to the browser console and nowhere else.

Behind the calculation, BigLedger uses simple daily accrual on a 365-day year:

interest = principal × rate × days ÷ (100 × 365)     rounded HALF_UP to 2 decimals

with days = Term (Days) for ONCE, and one figure per payout period for MULTI — each period measured exclusively, the last period plus one day so that the term is counted inclusively exactly once. The rate it reads is Interest Rate Effective when Interest Calculation is FLOATING and Interest Rate otherwise, and a null rate yields zero rather than an error: a FLOATING register written through the API without an effective rate finalises cleanly and posts an interest schedule of zeros.

Term (Days) is the one number the two sides of the product disagree about. The form computes it inclusively (end − start + 1); a rollover recomputes the child’s term exclusively (end − start) — so a rolled-over deposit’s term is one day shorter than its parent’s. See Rollover.

Lifecycle and effects

Posting proof

The ledger effect of a placement therefore comes entirely from the Internal Payment Voucher that pays the bank and the Internal Receipt Voucher that receives principal and interest back. Linking those to the register on the Payment/Receipt tab is a cross-reference only — the link carries no amount and drives no posting.

Requisition statuses

TEMP → ACTIVE (first SAVE) → posting status FINAL.

• A TEMP row exists on the server from the moment you press +. Abandoning the screen leaves it behind; a scheduled clean-up job (“Delete Temp rows after certain time”) sweeps them after a configurable number of hours.
• SAVE is disabled while the form is invalid or the row is already FINAL.
• FINAL is the same disabled condition plus the update permission, and the button is only rendered while the row is ACTIVE and not already FINAL.
• FINAL sends the invitation e-mails. On the transition to FINAL only, BigLedger sends one HTML e-mail per invitee row with a non-blank e-mail, subject “Money Market Deposit Placement Invitation — <deposit name>”, containing the deposit terms, the floating-reference block when a reference type is set, a link to the quotation form, and the requisition creator’s e-mail address as the contact. The stated submission deadline is always seven days from the moment the e-mail is built and is not stored or enforced anywhere.

The invitee quotation form

The link in the e-mail opens a public quotation page that reads the invitee row and renders a quotation form. Opening the page and submitting the form require no login, no token, no expiry, no permission check. Anyone holding the link can read and overwrite that invitee row. Treat the link as the credential and send it only to the intended institution.

Submitting overwrites the invitee’s own copy of the terms (amount, maturity amount, currency, dates, interest type, payout frequency, calculation logic, rate, the floating-reference fields, effective rate and estimated interest). The requisition header is untouched.

Register statuses

TEMP → ACTIVE → posting status FINAL.

• Select Requisition copies values from a requisition into the register form. It does not create a link: the register never records which requisition it came from, so a saved register does not point back at the requisition. The requisition is not knocked off, closed or changed. The picker lists requisitions whose status is ACTIVE only — a requisition that is still DRAFT can be selected. What is copied: name, principal, maturity amount, interest type, payout frequency, calculation logic, the four reference fields, effective rate, Interest Convert to Principal, dates, term, inflation rate, Auto Rollover Logic, and — after the company and GL-code lists reload — Company and GL Code. What is not copied: Interest Rate, Currency, Deposit Category, Financial Institution.
• FINAL does two things on the transition to FINAL:
  1. If this is the first deposit in its chain and Auto Rollover Logic is YES, it stamps a fresh chain identifier — the identifier that ties a rollover chain together.
  2. It writes the interest schedule described below.
• The register has no running number. FINAL sets only the record’s identifier, dates, status and revision — the document number is left blank.

What FINAL generates on the register

FINAL reads the saved register and writes its transaction lines. The rate used is Interest Rate Effective when the calculation logic is FLOATING, otherwise Interest Rate. Both interest and inflation use simple daily accrual:

amount = principal × rate × days ÷ (100 × 365)     rounded HALF_UP to 2 decimals

For MULTI, payout dates are generated by stepping the frequency from the start date while the cursor is before the end date, then appending the maturity date. Each period is measured exclusively (end − start), and the final period gets +1 day so the whole term is counted inclusively once.

The maturity value is principal + interest − inflation when Interest Convert to Principal is YES, and principal − inflation when it is NO — that is, with NO the interest is not added to the principal return line, because it has already been paid out on the interest lines.

FINAL does not check whether transactions already exist. Re-issuing the same FINAL transition against an already-final register through the API would append a second schedule.

Rollover

There is exactly one rollover path and it is manual. The Manual Rollover button on the Transactions tab renders and is clickable only when all of these hold:

• posting status is FINAL, and
• Rollover options = Manual Rollover, and
• Auto Rollover Logic = YES, and
• the deposit has not already been rolled over.

Setting Auto Rollover Logic to YES and Rollover options to Automatic Rollover therefore gives you no rollover at all — the button is hidden and nothing runs on a schedule.

Manual Rollover does the work:

1. Refuses with “Deposit already Rolled Over” if the parent has already been rolled over, and with “Deposit not found for GUID” if the register is missing.
2. Creates a new register copying company, category, GL codes, currency, interest terms, rollover settings and the chain identifier from the parent, and recording the parent — its document type, number, deposit date and maturity date — as where the child came from. The child’s document number is blank, Supervisor Remarks is cleared, and the Description is set to “Rollover of deposit <name> WITH DEPOSIT START DATE … AND END DATE …”.
3. Sets the child’s principal to the parent’s Amount Upon Maturity — always. Rollover options is copied but plays no part in the amount, so there is no “principal only” behaviour: a rollover always carries principal plus interest less inflation forward.
4. Sets the child’s start date to the parent’s maturity date and its end date to that plus the parent’s term, computed here as the exclusive day count (end − start), one day shorter than the inclusive Term (Days) the form shows.
5. Recomputes the child’s maturity amount and estimated interest with the same calculation the form uses.
6. Creates the child already FINAL, marks the parent as rolled over with a pointer to the child, and writes the child’s interest schedule.

What the backend actually validates

The server checks only structural things on the requisition and the register: the record identifier is present and new (or present and existing, on update), the category resolves to an existing category, the audit stamps — who created or updated it, and when — are present, and status and revision are present. No business field is validated server side — not the amounts, not the dates, not the rate, not the company, not the GL code. There is no check that the GL code or the company on the register exist. Every rule you see enforced in the register and requisition forms is enforced by the form in the browser and disappears if the row is written through the API.

Related applets

• Chart of Account — supplies GL Code, GL Code for Interest and GL Code for Interest Expense. The list is scoped to the selected company’s chart.
• Organization — the Company drop-down and, through it, the chart of accounts used for the GL Code list.
• Customer Maintenance — the entity behind each invitee; this applet embeds its create/edit screens for the Entity Name picker.
• Forex — the Currency drop-down.
• Ledger And Journal — where the placement is visible in the accounts, via the payment and receipt vouchers rather than this applet.
• Cashbook — the bank side of the same money.
• Internal Payment Voucher and Internal Receipt Voucher — the only documents the Payment/Receipt tab links, and the only ones that post a journal for the placement.

Troubleshooting

Related documentation

• Financial Accounting module
• Ledger And Journal — where the cash movement appears
• Chart of Account Applet — GL code setup