Menu ID groups by POS menu code; mapped codes use their Menu Mapping alias. Lines without a menu code stay grouped by name (“no code”). Press Apply after changing it.

Computed bottom-up: fill each branch's months in “Monthly Target per Branch” below, and these Brand and Company totals roll up automatically. Names come from your Mapping Template Report groupings.

These sections drive the Sales Peak Hour table on the Sales Panel. Give each window a title and an hour range (24h HH:MM). A window may wrap past midnight (e.g. 22:00 – 06:59). Bills are bucketed by the HOUR of their Sales Date In.

The COA master mirrors ESB’s Master Charts Of Account Management. Upload the ESB export and it is matched to the right company automatically (cell A2 is verified). Only level 4 accounts take a Mapping, exactly like ESB; refreshing the master never touches it.

Give each POS Menu Code (from the Sales Detail data) a friendly alias. Codes without an alias stay blank and are hidden from Sales Menu Projection. Several codes may share one alias; their quantities are summed there.

The ESB API names the staff behind a void / cancel by POS user code. Give each code a name; the Sales Panel Top 20 Void / Cancel table and the Void / Cancel page then show the name instead of the code. Names are learned automatically when a Cancel Menu Detail report is uploaded for bills the ESB sync also holds; a name typed here is manual and is never overwritten by learning. Blank = show the code.

Source: ESB API (auto); an uploaded Cancel Menu Detail report replaces it for the period it covers. Void = the bill was already paid (the system had detected payment) and was then voided. Cancel = no payment was detected yet (bill unpaid) when the menu / bill was cancelled. Staff from the ESB API are shown by name once their POS user code is known (Menu Mapping ▸ POS User Names), else by code.

Period selects Purchase Orders by Purchase Date (statuses Rejected / Waiting For Approval never count); every Goods Receipt of those POs counts, even when received after the period. Only GR lines of Transaction Type "Purchase Order" exist here; Goods Delivery / Simple Transfer are internal moves and are never stored. Source: Purchase Recapitulation + Goods Receipt Recap (With Value) uploads in Data Import, or the ESB Core API pull; the last load wins for its period, never both.

Each stage selects its documents by its own date: PRs by PR Date, GTRs by Transfer Date, GDs by GD Date; follow-up documents count whatever their date, and Close Deliveries follow their GD. Branch = the PR's branch for stage 1 and the destination (the requester waiting for the goods) for GTR / GD / Closed. Source: the four uploads in Data Import (Purchase Request Realization, Transfer Report Flow, Goods Delivery Recap With Value, Close Delivery Value), or the ESB Core API pull; the last load wins for its period, never both.

Period selects Goods Receipts by GR Date (statuses Rejected / New never count). A GR line is invoiced by the Purchase Invoice lines with the same GR number + product code + unit (the product name when there is no code), whatever the invoice date; uninvoiced qty = GR qty − returned qty − Σ Invoice Qty, never below 0; over-invoiced lines are flagged, never netted. Source: the Goods Receipt Recap upload or purchase pull (v1.45) plus the Purchase Invoice Report upload in Data Import, or the payables Pull from ESB.

Period selects invoices and disbursements by their document date; open / overdue is read as of today. A document is PAID only when its payment voucher's release has a released date (an advance used inside a voucher counts when that voucher is released); ESB's own invoice status (Full Paid / Half Paid) only means a voucher exists and is shown as "ESB status". A Payment Method CREDIT disbursement is a payable; its due date is the document date. One document = one payable, whatever the source. Source: the Purchase Invoice / Disbursement / Purchase Payment / Release Payment uploads in Data Import, or the payables Pull from ESB.

Period selects payment vouchers (VS) by their Doc. Date (the day the voucher was submitted to finance). Not yet released = no released date as of today; days waiting = today − the voucher date. Released: gap days = released date − voucher date (a voucher released in parts uses the last part's date). Only Purchase Payment vouchers appear here; Cash Payment (CO) releases are stored but never shown. Source: the Purchase Payment + Release Payment uploads in Data Import, or the payables Pull from ESB.

No period here: everything is computed from the beginning of the stored data up to ONE as-of date. Advance = opening balance + released Advance Purchase documents − advance used by released vouchers (its own column, never netted against Payable). Payable Suspense = goods received but not invoiced (the GR to Invoice rule as of the date). Payable = the open amount of invoices and CREDIT disbursements; Not Yet Overdue + Overdue = Payable on every row. The view is only right when the stored history reaches back to go-live; watch the coverage line below.

Standard Cost (Manual HPP): edit with your known recipe cost per unit. System Cost (API-filled): sourced automatically from connected SaaS systems; shows '—' until a source provides it.

Upload ESB report exports here. General Ledger: export with Branch: - All -; cell A2 must exactly equal the mapped company name. Only rows matching the same date + account + branch are replaced; other files of the same period are kept, so a split period can be uploaded file by file and nothing duplicates. Opening Balance rows are skipped automatically.

Loading status…

Choose how SALESDASHBOARD receives transactions. Whichever source is active, raw rows are stored first, validated against the Mapping Template Report below, and only then shown on the dashboard.

Upload the three ESB exports as CSV or Excel. Columns are matched by header name, so column order does not matter. Each upload is recorded below and can be removed as a unit. The Cancel Menu Detail report (Excel, Type "Cancel / Void (Default)") replaces its own period on every upload, so re-uploading never duplicates. It is optional: Void / Cancel comes from the ESB API sync automatically; an uploaded report replaces the API figures for the period it covers and teaches the staff names behind the POS user codes.

Reports are ingested raw; nothing in the source file is edited. This mapping decides how each file is validated and how its rows roll up on the dashboard. A Sales Recapitulation upload is rejected if its Company (cell B8), or any row's Brand or Branch, is not listed here.

Built from the groupings and aliases above. Each brand belongs to exactly one company; each branch to exactly one brand. Reports (Sales Year, Target Ops) consolidate using this structure.

Shown in the browser tab. Recommended: keep it under 60 characters so it isn't truncated.

Connect this dashboard to ESB OMS and Core: two APIs with two base URLs. OMS (static token from your ESB PIC) pulls sales and the General Ledger automatically; Core (Core username/password) feeds Stock Movement, Item Journal and System Cost. Leave a base URL blank to use the default shown. Full setup guide: see ESB-API-MANUAL.md in the release.

The accent color used across the dashboard: buttons, highlights, active menu, and charts. Pick with the color picker or type a hex code (e.g. #E8622C). Default is the ember orange.