Sales Report

See sales, cost and gross profit by item, document, salesman, hour, period, branch or customer category, and tie sales to the money collected. Only finalised documents count, returns and credit notes reduce the figures, and the profit is only as good as the cost basis you choose: an item with no cost on that basis shows 100% GP.

Overview

The Sales Report applet is a set of read-only grid reports over finalised sales documents — cash bills, sales invoices, sales returns, trade-ins and (for the collection reports) receipt and payment vouchers. Sales managers use it to see sales, cost, gross profit and delta margins by item, document, salesman, hour, day / week / month, branch or customer category; finance uses the collection, credit-card receipt and cashflow views to tie sales to money received. Every report has the same shape: an advanced search on top, an ag-grid listing with totals, and export from the grid’s status bar. Which reports, which cost columns and which cost basis a user sees is decided by applet settings paired with client-side permissions.

Where it fits

Screens and menus

Each menu item can be removed with its HIDE_<MENU>_MENU setting unless the user holds the matching SHOW_<MENU>_MENU permission (see Configuration). All reports read FINAL documents only, with one exception: Daily Cashflow Analysis also runs a query over VOID receipt vouchers and returns them as a section of their own, so a voided receipt appears there and in no other report of this applet.

One further report exists but is not in the menu: a general purchase / sales / inventory report. A member reward redemption route also exists in the build, but it is not a report: the screen calls no endpoint and shows the Item-Salesman-Customer-Category report’s rows under its own column headings, and the backend’s member-points reward-redemption endpoint has no caller in this applet.

Screenshot withdrawn; a recapture from a demo tenant is on the list.

Screenshot withdrawn; a recapture from a demo tenant is on the list.

Screenshot withdrawn; a recapture from a demo tenant is on the list.

Screenshot withdrawn; a recapture from a demo tenant is on the list.

Screenshot withdrawn; a recapture from a demo tenant is on the list.

Screenshot withdrawn; a recapture from a demo tenant is on the list.

Screenshot withdrawn; a recapture from a demo tenant is on the list.

Advanced search

Fields vary per report; the common ones are Branch (multi-select, grouped by company, limited to the branches the user’s API permission targets), Date range (or Date Option for Multi Branch Sales), Customer, Customer Category, Salesman, Shipping Entity, Item Code, Item Type (basic, grouped, NSTI, bundle, coupon, service, warranty, GL code, header adjustment …), Item Status, Item Category Level 1–20, Calculate Base On (cost basis, see below), Sales Lead (sales-lead type / label), Optional (HIDE_GL_CODE_TYPE — leave GL-code lines out), Invoice No (SR By Document), Cashbook and Credit Card item (Receipt with Credit Card), Group By 1 / 2 (SR By Item Salesman Customer Category), Company / Voucher Code / Date Redeem (Voucher Redemption).

Calculate Base On chooses the cost or price used for cost, GP and delta columns: cost_ma (default), cost_wa, cost_fifo, cost_lifo, cost_replacement, cost_manual, ref_price1–3, delta_price1–3, rebate_price1–3, sales_min_price, sales_max_price, purchase_min_price, purchase_max_price, report_unit_replacement_cost, report_unit_manual_cost, report_unit_commission, report_unit_rebate. Replacement cost falls back to MA cost when zero; SR By Document uses delta price and falls back to the delta-price percentage amount when empty.

The four report_unit_… choices are not item costs. They are figures written onto each document line when the document is saved, by a rule on the item’s category — the Report Item Price tab of a category in Doc Item Maintenance. A line whose item has no such rule carries none. The report adds them up as they are, without multiplying by the quantity as it does for every other cost choice, so each one is already a figure for the whole line.

Grid and export

Each grid supports column grouping, a totals footer row, a document popup from a row (cost amount and GP in the popup are hideable), and export of the current grid — title, filename and date-range subtitle are set per report — from the status bar (PDF and Excel).

Hourly SR and a landlord’s hourly sales feed are two different counts

Some shopping-centre landlords ask each shop to send its takings hour by hour. BigLedger can do this for a branch with two scheduled jobs, and neither of them is the Hourly SR. If GadgetSphere’s branch GS-KV-03 sits in a mall that collects hourly sales, the figure the landlord receives for 14:00 yesterday and the figure Hourly SR shows for the same hour are built differently, and they will not always agree.

What happens behind the scene. Neither job has a screen of its own; both run from the Scheduler:

1. The populate job works out the 24 hours of the day before it runs, in Malaysian time. For each hour it counts the branch’s cash bills and adds up their transaction amount and their discount, then stores one row per hour with the machine ID it was given. Leave the branch out and it counts every branch’s cash bills together.
2. The send job runs afterwards. It takes the last seven days, sends every day that has exactly 24 hourly rows to the landlord’s system, and records the landlord’s answer as SYNCED or FAILED with its message. A failure is e-mailed to the addresses on the job. A day without exactly 24 rows is not sent, and its date is e-mailed as missing.

Where the landlord’s number comes from, and why it differs from Hourly SR:

Cautions, and how you will notice:

• Everything goes in as cash. The feed has columns for card schemes, e-wallets and vouchers, but the job fills only the receipt count, the total (as cash and as gross turnover) and the discount. A landlord who reads the split will see 100% cash.
• A missed day is never filled in. The job only ever works out the day before it runs. If it did not run one day, that day stays empty, and the missing-dates e-mail repeats for a week.
• A second run on the same day blocks that day. A second run adds another 24 rows instead of replacing the first 24, and a day with 48 rows is never sent. You find out from the missing-dates e-mail, not from the landlord.
• A stored hour is never recalculated. The hour is worked out once, when the job runs. A cash bill changed after that is not counted again.

The job that remains yours. Your lease decides what counts as turnover, and it may leave out returns or tax. The feed leaves out neither. Before you sign the landlord’s monthly turnover statement, compare its monthly total with Hourly SR for the same branch and month. Explain any gap by the rows above: voided or draft cash bills, returns, invoices, or a day that never went. A day that did not go is reported only by e-mail, and only to the addresses on the job, so one of those addresses has to belong to someone who reads it every day.

What it will not do. It does not send sales invoices or returns. Each run sends the last seven complete days again exactly as they were stored, so nothing it resends is corrected. Nothing in BigLedger shows you what it sent.

Settings and Personalization menus

Configuration

Before you can use it

Applet settings

Default Selection: DEFAULT_BRANCH, DEFAULT_LOCATION. Personalization → Default Selection holds the same two keys per user.

Application Settings — this applet renders its own screen with four groups:

Document behaviour settings

Not applicable — the applet creates no documents. Cost basis defaults to cost_ma when nothing is chosen; the document popup opens the source document read-only.

Feature visibility / permissions

Client-side permissions registered for this applet (49):

Fields

Read-only applet; the only inputs are the advanced-search fields above and the two default-selection keys.

Lifecycle and effects

Not applicable. Reports never change documents, stock or the ledger. Amounts are multiplied by each line’s amount signum, so returns, credit notes and trade-ins reduce sales, and posting status must be FINAL.

Related applets

• POS General, Sales Invoice (Internal), Sales Return (Internal), Sales Credit Note (Internal), Sales Debit Note (Internal) — the documents reported.
• Receipt Voucher (Internal), Payment Voucher (Internal) — collection reports.
• Daily Cashier Report — Z Report and Cashier Collection.
• Sales Report Supplier Access — supplier-facing sales by item.
• Non Stock and Trade In, Voucher Management, Membership Admin — trade-in, voucher and points rows.
• Inv Item Maintenance, Pricebook, Customer, Cashbook, Organisation — master data the filters and columns come from.

Troubleshooting

Related documentation

• Sales module
• Sales Workflow applets