Cashflow Projection Applet

A planning register for money you expect to bill and collect: programs group client engagements, engagements break into lines with a value, and each line carries target and actual billing and collection per fiscal month, which a dashboard and two reports turn into collection rates and month-by-month projections. It reads no invoice, receipt or ledger and writes nothing to them — every actual figure is typed by hand, no overnight job corrects or rolls it forward, and no alert fires when collection falls behind; the Collection Delay Report tells you, when someone opens it. It is a separate register from the CRM Engagement applet.

Your job, and the screen for it

Overview

The Cashflow Projection Applet is a planning register for money you expect to bill and collect. You group work into programs, record each piece of client work as an engagement, break an engagement into lines with a value, and then — per line and per fiscal month — enter the target billing, target collection, actual billing and actual collection figures. A dashboard and two reports read those figures back as collection rates, outstanding amounts and month-by-month projections.

It is a standalone register. Nothing in it is a financial document: the applet does not read invoices, receipts or the ledger, and — see Lifecycle and effects — it writes nothing to them either. Every “actual” figure is typed in by hand.

Where it fits

Screens and menus

The sidebar offers the menus below, plus Settings and Personalization. Opening the applet lands on Program. The header title is Cashflow Projection Applet.

The settings gear (OWNER and ADMIN ranks) and the Personalization link render as in every applet.

Program

Program Listing shows Program Code, Program Name, Description, Status, Created Date, Updated Date, Created By, Updated By. The advanced search offers Program Code, Program Name, Status (ACTIVE / INACTIVE, preset to ACTIVE), Created By, Created Date and Updated Date; a free-text keyword must be at least three characters. Created By is shown in the search panel but is never applied. The first load asks for everything. There is no delete button on this listing.

Create Program has a single Main Details tab (Program Code, Program Name, Description, Status) and a CREATE button. Edit Program adds read-only audit fields and three more tabs:

Engagement

CFP Engagement Listing shows Title, Currency, Status, Process Status, Created By, Created Date and Updated Date. The Title cell is an expandable group: opening it loads a detail grid of the parent program’s items (Item Code, Item Name, Item Type, Currency, Status, Created Date). The advanced search offers Title, Currency and Created Date; only Title and the dates are applied. The listing always shows only ACTIVE engagements — inactive engagements never appear here (they still appear on a program’s Engagement tab).

Create Engagement / Edit Engagement (one form, used for both) has five tabs:

The SAVE button is disabled while the form is invalid only in create mode; in edit mode it is always enabled and does not re-check validity.

Dashboard

Engagement Dashboard loads up to 5,000 engagements in one request, each with the sum and count of its lines and the sums of its fiscal-period figures, and then computes everything in the browser:

• Filters — fiscal-year presets (This Year, Last Year, Last 3 Years, Last 5 Years), Engagement Title (matched against title or currency code), Process Status (multi), Currency (multi, from a fixed list of 13 ISO codes built into the screen, not from Forex), Fiscal Year From / To, Fiscal Month, Fiscal Day, Fiscal Txn Date From / To, Created From / To. When any fiscal filter is set, only engagements with at least one matching fiscal-period row are returned and the sums cover only those rows — and the screen opens with Fiscal Year From / To already set to the current year, so that narrowing is in force before you touch anything. No status filter is sent, so INACTIVE engagements are included.
• KPI cards — Active Engagements (row count), Engagement Value (sum of line values), Target Billing, Target Collection, Actual Collection, Collection Rate, Billing Realization Rate, Pending Amount, AR/AP Open (sum of ARAP Open Balance). What each one is actually counting, and what it quietly leaves out, is in Where each report figure comes from.
• Charts — top engagements by line value; collection rate by engagement; process-status distribution; actual collection by currency; highest actual collection; engagements with the most fiscal-period rows. Clicking a chart segment filters the table below it (a removable chip).
• Table — Title, Currency, Status, Process Status, Lines, Target Collection, Actual Collection, Pending, Collection Rate, and a “View details” icon that only shows a toast. Export writes the table to CSV.

Reports

Cashflow Projection Report: search by Program Name, Engagement, Fiscal Year (a select of the current year ± 2, preset to the current year), Month From and Month To. One row per engagement, pinned Program and Engagement columns, then a Total for <year> group — Total Project Value, Project Balance, Target Billing, Adjustment, Adjusted Target Billing, Actual Billing, Target Collection, Actual Collection, Outstanding Amount — and one column group per month in the range with Open Bal, Target Billing, Adjustment, Adj. Target Billing, Actual Billing, Target Collection, Actual Collection and Remarks. Expanding a row loads a per-item detail grid. The formulas are in Where each report figure comes from.

Collection Delay Report: search by Program Name, Engagement, Fiscal Year, Month From and Month To. Columns Program, Engagement, Item, Year, Month, Target, Actual, Variance, Status — one row per fiscal-period row whose actual collection is below its target collection.

Configuration

Before you can use it

Applet settings

The settings gear opens the shared settings shell, whose menu for this applet is: System Configuration — Application Settings, Default Selection, Printable Format Settings; Server Side Permissions — Permission Wizard, Permission Set, User Permission, Role Permission; Developer Tools — Release Notes. A handful of other settings screens inherited from the Sales Invoice applet (e-mail templates, webhooks, feature visibility, branch settings, workflow settings and others) have no menu entry and are reachable only by typing their address; they do nothing for this applet.

Application Settings is the shared field-configuration screen, not an applet-local one. In the build of this applet served on 2026-10-06 (published 2026-07-23), it shows the full Sales Invoice set of tabs — Gen Doc Listing, Main Details, Account, Line Items and the rest — and a CHANGE VIEW button that switches to one long vertical list of the same controls. Almost every control on it saves a key this applet never reads. It has no Hide Program or Hide Engagement switch: the applet reads those two keys (table below), but on this build they can be set only through the API. Only an OWNER or ADMIN can open it. SAVE writes the whole form as the applet’s master settings.

Dated note, 2026-10-06. The shared screen’s current source, which this applet picks up when it is next rebuilt, trims the view for this applet to three tabs — Sidebar Menu (with Hide Program and Hide Engagement), Advanced Search Filter and Free Gift — and hides CHANGE VIEW. One caution carries over: if anyone presses CHANGE VIEW on today’s build and saves, the tenant’s settings remember the vertical layout, and after the rebuild the screen opens in that full vertical list with no button to leave it. Press CHANGE VIEW back to the tab layout and save before then.

Settings that are declared, rendered, persisted and actually read by this applet:

Rendered on the same screens and persisted, but read by nothing in this applet (changing them does nothing here):

• Application Settings: every control except Enable Vertical Orientation and the two search keys in the next table — including HIDE_TRANSACTION_DATE (no search in this applet has a transaction date). There is no audit-trail menu on today’s build. Dated note, 2026-10-06: the shared sidebar’s current source adds an Audit Trail entry for owners and administrators, which opens the platform’s shared audit-trail screen; after the next rebuild it will appear here too. The Sidebar Menu switch HIDE_AUDIT_TRAIL_MENU removes it for everyone who is not granted an audit-trail permission of their own.
• Default Selection (master): Default Branch, Default Location, Default Pricing Scheme, Unit Price Decimal Precision, Transaction Date Logic and the “Details Tab Ordering” list are all fields of the sales-invoice screen this was built from. None of them affects a screen here.
• Personalization → Default Selection: Default Branch, Default Location, Default Delivery Branch and Default Delivery Location. (Default Tab Orientation is read only while Enable Vertical Orientation is on — table above.)

Read at runtime without a control of their own — this applet passes its settings into the shared advanced search on the Program and Engagement listings and both reports, which honours them:

Printable Format Settings lists the tenant’s printable formats registered under the Sales Invoice document type (Default, Format Code, Format Name, File Name, File Size, Created Date, Updated Date, Updated By). + uploads a new format (Format Code, Format Name, one .jrxml file — the button stays disabled for any other extension) and SET DEFAULT stores the selected row as PRINTABLE. The document type is fixed, so the formats you see here are the tenant’s Sales Invoice printable formats, and a CFP engagement template must be registered under that type even though the parameters it receives (the engagement’s title, currency, status, process status, program, entity, entity branch, conglomerate, created and updated dates, and per line its title, value, process status and status) are nothing like an invoice’s.

Settings in other applets that control this applet

None found. The applet reads no financial configuration, no default GL mapping, no document numbering and no tax code.

Who can change what

There are no client-side permission codes defined for this applet, so the Applet Access screen has nothing to grant; a request to create them is open. The applet still asks for the Sales Invoice codes it inherited, but the menu entries they would show (Pick Pack Queue, File Import, Approval and the like) do not exist in this applet, so granting them changes nothing.

Server-side gates (one family per record type, each with OWNER, ADMIN, CREATE, READ, UPDATE, DELETE):

Portal (customer-login) users have a separate read path gated by their login-to-entity link rather than a permission code. The applet’s screens do not use it.

Fields

Validation happens on the screen; the server validates none of the business fields (see What the backend actually validates).

Taken together the seven forms capture this, and nothing else. Program — Main Details: Program Code, Program Name, Description, Status, plus read-only Created/Updated Date and By in edit mode. Program — Member: an e-mail or phone number to verify, Rank, Status. Program — Program Item: Item Code, Item Name, Item Type, Currency, Entity, Entity Branch, Sales Entity, External PIC 01, External PIC 02, Remark, Status. Engagement — Main Details: Engagement Title, Program, Conglomerate, Branch, Currency, Status, Process Status. Engagement — Account: Entity Id and Entity Branch are the only two controls that write; Status, Identity Type, Currency, Description, Entity Name, Entity Type, ID Number, Email and Phone Number are read-only copies of the chosen entity, and the engagement’s own form does not require an entity, so an engagement saves without one. Engagement — Line: Title, Value, Process Status, Status. Engagement — Fiscal Period: Fiscal Year, Fiscal Month, Fiscal Day, Txn Date, ARAP Open Balance, Target Billing, Target Adjustment, Target Collection, Actual Billing, Actual Collection, Remarks, Status. Engagement — Member: an e-mail or phone number to verify, Rank / Role, Status.

Status defaults to ACTIVE on every form, Item Type to SERVICE and Member Rank / Role to MEMBER. Everything below is the part of those forms that behaves in a way the screen does not show.

Program and Program Item

Engagement, line and fiscal period

Two editors replace the whole row; the other three do not

There is no partial update in this register. Every save replaces every field of the record with what the screen sent; the server fills in only the two dates and never reads the stored record first. A field your screen did not send is written blank.

Three of the five editors send the whole record and are safe: the engagement form and the program form both start from the loaded record before applying the form values, and the Program Item form happens to carry a control for every one of its fields.

The other two rebuild the record from the form and patch the audit fields back on:

The line case is the one that bites, because it silently undoes the only workaround there is. No screen in any applet sets the line-to-Program-Item link, so the only way to link a line to a Program Item — and the only way to make the Collection Delay Report or the projection report’s detail grid return anything — is through the API. Open that line in the UI afterwards, change nothing, press SAVE, and the link is gone again, under a “Line item updated successfully.” toast.

The fiscal-period case costs nothing today, because nothing writes the recurring-period fields either. They are not dead, though: the fiscal-period listing can filter on them and returns them. If an integration ever starts grouping recurring periods, a single screen edit will unpick the chain — how one-time versus recurring periods are meant to be expressed is still an open question.

Lifecycle and effects

Posting proof

Everything the dashboard and reports show is therefore an arithmetic view of what users typed into the fiscal-period rows. Actual billing and actual collection are not reconciled against Sales Invoices or Receipt Vouchers.

Nothing is queued, so nothing happens afterwards

Most applets in BigLedger separate saving from finalising: the second starts a background run that fans out into stock, journals, the cashbook and more. This applet has none of that, and the absence is worth stating precisely because it is the reason the figures never move on their own:

• Shipped — there is no background job for this register anywhere in the product.
• Registered — nothing for this register appears in the Scheduler applet’s processor picker.
• Scheduled — nothing to schedule; there is no scheduled recalculation, roll-forward or reminder.
• Run — nothing runs. Every number on the dashboard and both reports is computed by the request that asked for it, from rows a person typed.

So there is no overnight job that will fix a figure you entered wrongly, no roll-forward that carries December’s closing balance into January’s ARAP Open Balance, and no alert when actual collection falls behind target. The Collection Delay Report is the only thing that will ever tell you, and only when somebody opens it.

Statuses

Every record has a Status (ACTIVE / INACTIVE from the screens; the server default is ACTIVE). A third value, DELETED, is what every delete writes; listings, the dashboard and both reports skip those rows, and an API query sees them only when it asks for that status by name. Engagement headers and lines also carry a Process Status label with four values (PENDING_REVIEW, APPROVED, DUPLICATE, REJECTED). There are no transitions: any value can be set at any time, nothing locks a record after “Approved”, and no notification, workflow or approval step is attached (the Workflow Settings screen in the settings area is inherited from the Sales Invoice applet and has no menu entry).

Relationships and deletes

• Engagement → Program, Line → Engagement, Fiscal Period → Line and Engagement, Member → Program or Engagement, Program Item → Program are enforced relationships.
• DELETE buttons (program item, program member, engagement line, fiscal period, engagement member) do not remove the row: they set its status to DELETED. Nothing is checked first, so a row that others still point at is deleted all the same, and its children are left as they were. That matters most for an engagement line. Its fiscal-period rows stay ACTIVE and keep counting in the Cashflow Projection Report’s monthly and year figures, in the dashboard’s billing and collection totals and in the Collection Delay Report — while the line’s own Value drops out of Total Project Value and Engagement Value, and the rows can no longer be opened, because the Fiscal Period tab is reached only through the line. Delete a line’s fiscal-period rows first, then the line. If the line is already gone, the leftover rows can be deleted only through the API (the fiscal-period endpoint, by row).
• Failed to delete … therefore never means “still referenced”. It appears when the row was already deleted (for example by someone else, in another tab) or when you lack the delete permission for that record type.
• Programs and engagements have no delete button anywhere in the UI; set them INACTIVE instead. The API can delete them the same way — a status change that leaves their engagements, lines and fiscal-period rows untouched.
• The fiscal-period audit trail exists as a record type with its own API, but nothing in the product writes to it and no screen reads it. It stays empty unless something outside the product writes it.

What the backend actually validates

On create and update the server checks that the record identity is new (create) or exists (update), that the revision and status are set, that the creating and updating users are real logins, and that the dates are present; on create it fills the dates, defaults Status to ACTIVE and generates a revision. No relationship, code uniqueness, month range, currency existence or role value is checked on the server; the only “duplicate” errors it knows are duplicate identities. A bad reference surfaces as a database error, which the screens show as a generic Failed to create/update … toast.

Where each report figure comes from

Nothing here is stored. Every figure on the dashboard and on both reports is recomputed by the request that asked for it, from the fiscal-period rows and engagement lines as they stand at that moment. All three exclude only deleted rows — so in practice they include everything, INACTIVE rows included.

The one thing to know before reading any of the three: each of them mixes figures scoped to the period you chose with figures scoped to all time, in the same row, with no visual difference between them. Three columns are lifetime figures wearing a period heading.

Cashflow Projection Report

Two consequences worth having in mind:

• Engagements with nothing in the chosen year still appear, as a full row of zeros with their lifetime Total Project Value filled in. The year filter narrows the fiscal-period figures, not the engagement list, which is filtered only by “not deleted” and the Program / Engagement name search.
• A year total can exceed the months shown. Nothing validates the fiscal month into 1–12, and on first load the screen sends no month range at all — the grid builds columns for 1 to 12 from its own defaults while the query sums every month value present. A row keyed to month 0 or 13 lands in the year total with no column to sit under. The expand-row detail grid always sends the 1–12 range, so the detail will not add up to the summary either.

Rows are engagements joined to their program, ordered by program name then title, twenty per page — an engagement saved with Program = – None – is not listed at all. The status bar’s record count is not a count: the screen reports “rows fetched, plus one if a full page came back”. Use All (which asks for 9,999) if you need the real extent.

The detail grid lists one row per engagement line that is linked to a Program Item, with the line’s value as Project Value. Because no screen writes that link (see Two editors replace the whole row), expanding a row on a UI-built engagement returns nothing.

Collection Delay Report

One row per fiscal-period row where actual collection is below target collection, for lines that are linked to a Program Item and engagements that belong to a program. Variance is actual − target, negative by construction. The same Program Item requirement means this report can only ever be empty for rows the UI created.

It also carries a project-manager filter that the UI does not expose, which matches engagement members whose role is exactly Project Manager — a value the Rank drop-down cannot produce. If an API caller ever does set that role on two members of one engagement, every qualifying fiscal-period row is listed twice.

Engagement Dashboard

The dashboard asks for one page of up to 5,000 engagements and computes everything in the browser. Three things about those numbers are invisible on the screen:

• It opens filtered to the current year. Fiscal Year From / To start at this year, which the server treats as a fiscal filter and therefore returns only engagements that have at least one matching fiscal-period row. An engagement with no row for this year is not counted at all — including in the Active Engagements card, which is simply the number of rows returned.
• Engagement Value and Lines ignore that filter. The line totals are never constrained by the fiscal window, so the value and line count are lifetime figures sitting beside windowed collection figures.
• The money cards add currencies together. The cards sum target billing, target collection, actual collection and ARAP open balance straight across every row with no grouping. On a tenant with MYR and USD engagements the Engagement Value, Target Collection and Pending Amount cards are numbers with no currency. The Currency filter is the only way to make them mean anything, and it is a fixed list of 13 ISO codes built into the screen rather than the tenant’s Forex list.

Collection Rate is actual ÷ target collection × 100 and Pending Amount is max(0, target − actual collection), so an engagement that over-collected does not net off against one that under-collected. Billing Realization Rate divides actual collection by target billing — two different quantities — so it is a cash-conversion ratio, not a billing accuracy one, whatever the name suggests.

Related applets

• Customer Maintenance — the customer listing behind every Select Entity column, and the conglomerate master behind the Conglomerate drop-down.
• Entity Maintenance — where an entity’s branches are maintained; both Entity Branch drop-downs read them.
• Forex — the currency list on engagements and program items.
• Tenant Admin — the tenant users that program and engagement members are resolved from.

Troubleshooting

Related documentation

• Financial Accounting module
• Customer Maintenance — customers, conglomerates
• Entity Maintenance — entity branches
• Tenant Admin Applet — tenant users for members
• Engagement Applet (CRM) — the other engagement register, not linked to this one