Claim Cycle Applet

Pay out the employee claims that supervisors have already approved: a cycle gathers one company’s approved lines for one month, finance reviewers accept or hold them, and the Bank Report and the PV Details Report are what the money is paid from. Nothing here posts a journal or raises a payment voucher, and lines reach a cycle when the last approver signs off, or later through Auto-add or the claim-cycle sweep; the scheduled cut-off job is what creates each month’s cycle, so a company with no cut-off logic receives nothing.

Your job, and the screen for it

Overview

The Claim Cycle Applet is the finance side of employee claims. Once supervisors have approved a claim line in the Claim Applet, the line waits as Pending Doc Review until a claim cycle — one company, one month — collects it. In the cycle, finance reviewers accept lines level by level or put them on hold, auditors draw samples and record check results, and the applet produces the reports payment is made from: the Bank Report (one payment per employee, with bank code and account number), the PV Details Report (per claim line with GL code and tax), the Cross-Billing Report (claims charged to another company or branch), the Pivot Report and the Professional Subscription Report. Closing the cycle moves whatever is still unreviewed into next month’s cycle.

Cycles are normally created by a scheduled job from the company’s Claim Cut-Off Logic (configured in the Claim Applet); the Create button exists for manual cycles and can be hidden. The applet posts no journal and creates no payment voucher: the Bank Report and the salary-payment CSV are the hand-off to the bank portal, payroll or the Payment Voucher, and an external integration can pick up closed cycles by their syncing status.

Where it fits

Module: Claims Management.

Screens and menus

Cycle edit (claim-cycle-edit) tabs: Main Details · Claim Lines (every line in the cycle, duplicate-receipt view, approval and reviewer history, receipt images) · Checking Reports with sub-tabs Inbox, Approved, On Hold (the reviewer’s work queue; Approve and On Hold buttons, single or mass) · Payroll Payment (hidden by a personal setting) · Sampling (Create a sample, sample listings, link view) · Sampling Analysis Report · Bank Report · PV Details Report · Cross-Billing Report · Pivot Report · Prof Subscription Report. Bank and PV Details tabs have a Reviewed By Level filter.

Settings → System Configuration: Application Settings (application-settings), Reviewer Setting (reviewer-setting, per company). Also reachable by URL: default-selection and field-settings (not in the menu). Webhook, Feature Visibility, Permission Wizard / Set / User / Team / Role, Applet Log.

Personalization: Default Selection (personal-default-selection), Sidebar.

This page carries no captures: every one available shows a real customer’s cycle listing in the side panel.

Configuration

Before you can use it

Applet settings

Settings live in three places. A Field Settings screen exists by URL but the menu does not link it, and the applet reads none of the document-style keys it shows (HIDE_UNIT_PRICE_*, custom statuses, the SST enable flag, …) — saving them changes nothing.

1. Application Settings (Settings → Application Settings, saved for the whole tenant; anyone with the Settings menu can change them):

Rendered and saved but not read anywhere: Enable Audit Trail (the Applet Log screen works regardless), and the default company that Default Selection patches from the chosen branch (no screen reads it — the cycle create form takes its company from the branch you pick).

2. Default Selection (tenant-wide, reachable by URL only): DEFAULT_BRANCH, DEFAULT_LOCATION and, patched from the branch, a default company that nothing reads.

3. Personalization → Default Selection (per user):

Because DEFAULT_PAYMENT_PROCESSING_OPTION is personal, two finance users can see different totals for the same cycle.

Reviewer Setting (one row per employee per company): Employee Name, Email, Approval Level, Is Final Approval Level. Rules the server enforces: a reviewer can act only on lines whose latest reviewed level is below their own; a line becomes Approved when the highest configured level accepts it; only a final-level reviewer can close the cycle.

Document behaviour settings

The cycle has no status-flow, posting or printable toggles. Its dates are set by the company’s Claim Cut-Off Logic (last day of the month, a specific day of the month, or a number of days before or after the finance cut-off date) when the scheduled job creates it, and can be edited on Main Details afterwards. Final approval itself attaches a line to the month’s cycle when that cycle already exists and the approval is inside its approval cut-off; for a line that finds no cycle, the cut-off row’s Auto-add approved claims to active cycle switch (on the Claim Applet’s cut-off form) decides between immediate ingestion and the periodic sweep — see the Claim Applet page.

Feature visibility / permissions

• This applet defines no client-side permissions and reads no SHOW_* codes.
• Access is by API permission sets through the shared Permission Wizard; who may act on a line is decided by Reviewer Setting, not by permissions.

Fields

Cycle — create

The Create Claim Cycle form asks for the company, a code and a name (all required), an opening and a closing date, the planned and actual crediting dates, and two amounts, Cycle Opening Balance and Grand Total, both required. What the form does not tell you:

• A cycle made here receives no claim lines and does not appear in the Claim Cycle listing. The form saves no cycle month, year or status. Every path that puts a line into a cycle — the scheduled sweep, immediate ingestion at final approval, and the carry-forward when a cycle closes — looks the cycle up by company, month and year, so it never finds this one. The listing shows only cycles whose status is OPEN, and Claim Cycle History only CLOSED, so after the success message you will not find the cycle you just made on either screen. Nothing checks for a second cycle for the same company either. For a real month, set up the company’s Claim Cut-Off Logic in the Claim Applet and let the job create the cycle; that is why Create can be hidden.
• Cycle Opening Balance is not saved. You must fill it to enable CREATE, but the value is never sent.
• Grand Total is not a total yet. What you type is stored as the cycle’s total until the cycle is closed; closing replaces it with the sum, tax included, of the Finance Payment lines that are approved and ready to pay (withdrawn, rejected and non-reimbursable lines left out). If no line qualifies, the typed figure stays.
• Only the Planned Crediting Date reaches the Bank Report, as each line’s credit date and the company payment date. The Actual Crediting Date is stored and shown, and nothing else reads it. A job-created cycle sets the planned date to the last day of the month.
• The opening and closing dates are not shown again once the cycle exists.

Job-created cycles are coded and named from the company’s code and name plus the year and month, not from the cut-off row.

Cycle — Main Details (edit)

Adds: Status (OPEN / CLOSED), Supervisor Approval Start / End Date (lines whose final approval falls after the end date wait for the next cycle), Finance Cut-off Date, Extension End Date, audit fields. Held on the cycle but not shown: the finance review end date, the fiscal year and period (created if missing), the four report totals, the line count at loading, the external payment-voucher reference and the syncing status.

Sample — create (Sampling tab)

Give the sample a name, a Source, a Size and a Type; the filters narrow the lines it is drawn from.

The sample is drawn by a background job: the success message means the request was queued, so refresh the sample listing if the new sample is not there yet. When nothing matches, the server answers There is no claim data from given sample conditions. and this form shows no message and stays open.

Each sampled line records its sampling level, a check result (PASS / FAIL), remarks and the checker; accepting or holding a sampled line also updates its sample record.

Lifecycle and effects

Cycle statuses: OPEN → CLOSED. There is no draft or in-review status on the header; “in review” is a property of the lines.

Creation: the scheduled cut-off job (set up per tenant) reads every cut-off row, computes the finance cut-off, finance last-review, approval cut-off and extension dates in company time zone skipping company holiday events, creates missing fiscal year / period rows, and creates the month’s cycle as OPEN if none exists. It also installs the daily approval-reminder schedule. A cycle made with Create is not the same kind of cycle: it has no month, year or OPEN status, so no line ever enters it (see Cycle — create).

Lines entering the cycle: the sweep job selects the company’s Pending Doc Review lines that are in no cycle, whose final approval date is on or before the cycle’s approval cut-off end date, and that have not been withdrawn, and stamps them with the cycle and the date they were added. Most lines do not wait for it: the final approval itself attaches the line to the company’s cycle for the month of the approval when that cycle already exists and the approval is on or before its approval cut-off end (or inside the line’s on-hold window), whatever the switch says. Only a line that finds no such cycle depends on the cut-off row’s Auto-add approved claims to active cycle switch: on, it goes straight to the current month’s open cycle (created if missing); off, it waits for the sweep. A line moved from an earlier cycle remembers which cycle it came from.

Finance review: the reviewer’s setting for the line’s company is loaded; lines already reviewed by someone else fail with Claim Document Line is reviewed by another reviewer …; acceptance marks the line reviewed at your level, records your name and a review-history entry; when your level is the highest configured level the line becomes Approved and ready to pay. A reviewer whose level is not above the line’s latest reviewed level is rejected with an on-screen error. On Hold: same level rule; sets the line to On Hold with the date, remarks, history and an audit-trail entry; the daily review-notification job (9 am Malaysia time) e-mails the claimant, where that clock has been set up — it is never installed automatically. The claimant resubmits from the Claim Applet, which returns the line to the Inbox. Every line change recomputes the claim header status.

Reports: each Generate reads the cycle’s lines and stores the result: Bank Report aggregates approved Finance Payment lines per employee, adds bank code / name / account number from the employee’s payment method, shows There is no claim data. when empty and writes the bank report total on the cycle; PV Details writes one row per line with company, branch, claim item, GL code, tax and amount; Cross-Billing lists lines whose billing branch differs; Pivot and Professional Subscription similarly. Reviewed By Level filters Bank and PV reports to lines reviewed at that level. The salary-payment CSV is a separate export of the Salary Payment lines.

Close (saving the cycle with status CLOSED): you must hold a final-level Reviewer Setting for the company; the cycle’s syncing status becomes READY_TO_SYNC, its transaction date is stamped and its total is recomputed; then next month’s cycle is fetched or created and every Pending Doc Review line of the company that is not yet ready to pay moves into it, remembering the cycle it came from. The screen asks for confirmation (Are you sure you want to Update/Close the claim cycle?); a customer-specific variant instead demands a payment-voucher reference number and refuses the close without it. A closed cycle appears under Claim Cycle History; there is no reopen action in the UI.

What it does not post: a claim cycle is not a financial document — it has no signums, no journal posting, no stock movement and no void. Nothing in the claim domain writes a payment voucher or journal; the payment-voucher link on a cycle payment line is populated only if an integration or manual process sets it.

The claim this subsystem exists for

An area manager at GadgetSphere’s Penang branch, GS-PEN-01, replaces the back-office laptop at another retailer for RM 4,299.00 and pays with his own card. The shop’s cash bill is in his name — he paid, so the receivable is his, and that never changes. He then asks the shop for the e-invoice in the name of GadgetSphere Sdn Bhd, with the company’s tax and registration numbers, because it is the company whose expense this is. A buyer on an e-invoice may legitimately differ from the account the shop billed; that split is deliberate, and the shop completes it afterwards (why your buyer has an applet of their own).

Everything on this page is the company’s half of that story: he raises a claim line, his supervisor approves it, finance reviews it in the month’s cycle, pays him RM 4,299.00 from the Bank Report, and records the payment on a voucher that debits the laptop’s GL code and credits CASH-PRI-PEN01. Attach the company-named e-invoice to the claim line with the receipt; the claim line keeps it as a receipt like any other, and the person coding the voucher is the one who needs it.

The claims applets and the vouchers side by side

Neither voucher reads a claim, and neither claims applet writes a voucher. The Claim Cycle’s PV Details report is the working paper, and the voucher is keyed from it by hand.

Choosing what to pay a claim with

The laptop raises one question that is a person’s call, not a field’s: is it equipment or an expense? That is the accountant’s decision, made before the voucher line is coded. If it is capitalised, the Fixed Asset applet writes its own acquisition journal, so decide which document carries the cost before both do.

The claim figures, and what makes each

What will not happen on its own

• No posting from a claim. Approving, reviewing and closing a cycle write nothing to the general ledger, the cashbook or payables. Whoever pays the Bank Report raises the voucher; that is a standing job for the day after each payment run, and the cycle will not remind anyone.
• No voucher from a cycle, and no cycle from a voucher. A voucher does not mark claim lines paid, and a closed cycle shows Ready to Sync until an external integration, if you have one, picks it up.
• No e-invoice check. A claim line holds the e-invoice only as an attachment. Whether it names your company, not the employee, is the approver’s or the reviewer’s check.
• No sweeping on a clock unless somebody set one up. The cut-off job that creates each month’s cycle and the sweep that collects late approvals are clocks a tenant creates by hand (the processors).
• Rare in production. The claims applets and the Reimbursement voucher are used by very few groups; a Payment Voucher on the employee’s own record is the common route. Expect fewer worked examples, and test a month on a scratch company first.

Checking that a month’s claims were paid and booked

About five minutes, once per cycle.

1. Everything approved reached the cycle. In Claim Cycle, the month’s cycle Inbox holds the lines your supervisors approved before the cut-off. A line still Pending Doc Review outside any cycle is a missing cut-off row or a late approval.
2. The report you paid from is current. Generate the Bank Report again just before you pay; its total is written on the cycle.
3. Every payment is on a voucher. The sum of the vouchers you raised for the run equals that total.
4. Every voucher booked. On each voucher, Trace Document › Journal Txn shows an expense line per claim line, a tax line where the receipt carried tax, and the bank credit. An empty grid is a journal that failed after FINAL.
5. The bank agrees. The payment appears as a cashbook line ready to match in Bank Reconciliation.

Prerequisites, blast radius and siblings

• Must exist first: an employee record per claimant and approver, with the Main-tab e-mail they log in with and a Login-tab link; bank details on each employee’s payment method for the Bank Report (Employee); the company and branches (Organisation); expense GL codes for the claim items (Chart of Account); and a cut-off row per company.
• Downstream: the voucher, the cashbook it pays from (Cashbook), then Bank Reconciliation; or payroll, for Salary Payment items.
• Siblings: the Reimbursement and Payment Vouchers in Finance — two ways to record the same payment, compared above.
• Blast radius: one employee with the wrong e-mail is locked out of claims; one company with no cut-off row receives no approved line; one claim account with Display off has no entitlement limit.
• Used together: Claim with Claim Cycle, always; Claim Cycle with a voucher per payment run; the e-invoice buyer correction on the seller’s side with the claim on yours.

Related applets

• Claim Applet — the source of every line, and home of the Cut-Off Logic that creates cycles.
• Employee Applet — reviewers, and the bank details the Bank Report needs.
• Organisation Applet — one cycle per company; holidays and fiscal periods.
• Payment Voucher (Internal) — where the payment is actually recorded, from the PV Details Report.
• Cashbook Applet — the bank the reimbursement leaves from.

Troubleshooting

Claim symptoms across the screens

These span the Claim applet, this cycle and the vouchers that pay it.

Related documentation

• Claims Management module
• Claim Applet
• Financial Accounting module