Shifts & transactions
The operating context around one shift.
- Opening, closing and cash handover
- Orders, tendering and payment methods
- Returns, voids and in-shift adjustments
F&B solution
POS APPLICATION · POINT OF SALE
Sell at the counter on the POS. Run the business on one logical core.
The POS is the counter-side operating application: open a shift, take the order, take payment, apply a promotion, close the shift. From the moment a shift closes, revenue, ingredient draw-down and takings carry on into the shared data plane — where the company's inventory, purchasing and Finance already live.
This page defines scope and handover points, not a POS feature list. The POS can be the system you already run, another vendor's, or one supplied by Apus — the handover point is the same, only the integration effort differs.
FRONT-OFFICE SCOPE
A complete operating domain, not another ERP module.
The POS owns an interaction model specific to the counter: fast, usable when the network drops, and in a salesperson's hands all shift. Platform modules keep owning the shared enterprise records and controls.
Goods at the counter
The front-office view of daily selling.
- Menu, item codes and sale prices at the site
- Counter promotions and voucher redemption
- Recognising regulars and loyalty points
The line before accounting
Where the POS stops and the enterprise starts.
- Closing shift revenue and reconciling cash
- Recording ingredient draw-down against recipes
- Handing agreed records to Finance
SHARED PLATFORM CORE
The same business record carries on after the shift closes.
A POS supplied by Apus and Apus Platform already share one logical core and business data plane; another vendor's POS joins the same plane through a controlled interchange. The commercial product and UX differ; the enterprise records do not become a second island.
- Tenant and company structure
- Shared master data
- Recipes, yields and item codes
- Inventory records
- Purchasing records
- Finance records
HANDOVER ON ONE CORE
From one shift to enterprise control.
- POSInventory
What sold during the shift draws ingredients down against the recipe, so stock reflects what was actually used rather than a figure typed in at close.
- POSPurchasing
Stock falling below the site's threshold becomes a purchase request with an approver, instead of a message to the manager.
- POSFinance
Reconciled shift revenue and takings reach accounting without standing up a parallel revenue ledger.
SYSTEM BOUNDARY
One core; three layers of system.
- The POS carries the counter experience: shifts, orders, payment and promotions — whether that is the system you already run or one supplied by Apus.
- Other specialist systems on site (a PMS for stays, scales, time clocks) keep their own work and hand over into the same data plane.
- Apus Platform owns the enterprise journey across Finance, supply, people, knowledge and control.
No one-click migration or zero-downtime cutover is implied. The agreed architecture and rollout plan govern each project.
FAQ
How do the POS and Platform work together?
Which POS does this page describe — the Apus one, or ours?
Both. The POS is a counter-side front-office application, and it can be the system you already run, another vendor's, or one supplied by Apus. The scope and handover points above hold in all three cases; what differs is the integration effort, surveyed against your actual system and settled during solution design.
Is POS a Platform module?
No. The POS is a front-office application and it connects to the same logical Apus Platform core.
Is this the POS product page?
It is not. This page draws the boundary and the handover points so you know what belongs where. Selling features, hardware and pricing live with the POS product itself — linked at the foot of this page.
Does the POS replace Finance or purchasing?
The two domains stay apart: the POS owns work at the counter, while Platform modules own the shared enterprise records and controls.
Does one logical core mean one physical deployment?
One logical core describes continuity of business records, not the number of physical deployments. Topology varies by solution, and a rollout can require integration, relocation or cutover work.
Design the counter-to-enterprise operating journey.
Confirm POS scope, shared records, integrations and rollout boundaries with the Apus team.
See the POS product