POS System (Envisage)

Custom React/NodeJS retail Point of Sale platform built by Envisage for Aidacare — integrated with GP via the HANDLR SQL database, Westpac PayWay for card-not-present payments, and Linkly/EFTPOS for in-store terminal payments.

POS@Aidacare.docx

Source: POS@Aidacare.docx Source: GP Modification Docs / PayWay Credit Card Payment Integration.docx

POS Version

4.0.2

Envisage Software

App Server

AIDAPOS01V

POS application host

Database

HANDLR

GP SQL Server DB

Payments

Linkly / PayWay

EFTPOS + card-not-present

Tech Stack

React + NodeJS

Web application

Support / IP

Envisage

Source code IP with Envisage

Direct SQL Risk (risk-006): POS connects directly to HANDLR (GP DB) via SQL — this is a documented risk (risk-006). This bypasses GP business logic and validation layers. See Risks & Gaps page for full risk register.

System Details

Envisage POS

System Envisage POS — Point of Sale (IP with Envisage)

URL pos.aidacare.com.au / www.pos.aidacare.com

App Server AIDAPOS01V

Database HANDLR — GP SQL Server database

DB Server GP DB, SQL Server

Version 4.0.2

Tech Stack React, NodeJS

Integrations Direct GP SQL Server connection • Westpac PayWay • EFTPOS Linkly

Support Envisage — source code IP held exclusively by Envisage

GP Team Contact Aidacare GP team (EFTPOS / payment issues)

Architecture & Integration Points

3 integrations

The POS platform is a custom React/NodeJS web application hosted on AIDAPOS01V. It integrates with three external systems:

Integration 1 — HANDLR (GP) Direct SQL

POS connects directly to the HANDLR GP SQL Server database. This is the primary integration — sales, inventory, customer data and invoices are read and written via direct SQL. There is no GP API or eConnect layer; POS operates directly against the GP database tables.

Integration 2 — EFTPOS via Linkly (in-store card payments)

Physical card machines are connected through Linkly middleware. POS sends a payment request to Linkly; Linkly communicates with the EFTPOS terminal; Westpac merchant services handle bank authorisation. See the EFTPOS Flow tab for the full 10-step data flow.

Integration 3 — Westpac PayWay (card-not-present)

PayWay handles online, phone, stored card, API-based, and recurring payments. It is integrated into both POS and MS-GP (via the AIDACARE.DIC Dexterity customisation). See the PayWay tab for GP customisation details.

POSReact / NodeJS
AIDAPOS01V

SQLHANDLR DB
GP SQL Server

EFTLinkly
EFTPOS middleware

PAYWestpac PayWay
Card-not-present

POS System Overview — 6 Core Capabilities

Retail Operations

The POS is a custom retail Point of Sale platform tailored specifically for Aidacare retail operations. It enables retail staff to perform the following functions, all tightly integrated with Microsoft GP:

Process Customer Sales

Complete retail sales transactions with item selection, pricing, and tax calculation pulled from GP.

Accept Payments

Cash, EFTPOS (Linkly), and card-not-present payments via Westpac PayWay within the same POS interface.

Handle Refunds

Process customer refunds with reference to original transaction; updates GP and payment records accordingly.

Capture Customer Details

Customer lookup and creation linked to GP customer master — centralised customer management across POS and GP.

Process Retail Invoices

Sales are invoiced in real time; invoice records are written to the HANDLR GP database for financial reconciliation.

Update Inventory

Stock is decremented in real time against the correct GP site/warehouse — enabling accurate inventory visibility across branches.

GP Integration Benefits

Inventory VisibilityAccurate real-time stock levels across all retail branches

Financial ReconciliationSales, payments and refunds reconcile directly with GP financial records

Customer ManagementCentralised customer master shared between POS and GP

Order SynchronisationReal-time order synchronisation — no batch delay for retail transactions

Sales ReportingConsistent sales and operational reporting — POS data visible in GP reports

POS Architecture — Source Document Screenshot

POS Architecture diagram from POS@Aidacare source document

POS architecture — from POS@Aidacare.docx source document

Critical note: An HTTP 200/202 response from Linkly does NOT mean the payment succeeded. You must inspect the actual EFT response payload (approved/declined flag, response code) before finalising any sale.

EFTPOS / POS Data Flow — Source Document Screenshot

EFTPOS/POS data flow diagram from POS@Aidacare source document

EFTPOS/POS data flow — from POS@Aidacare.docx source document

EFTPOS Data Flow — 10-Step Breakdown

Full end-to-end flow

#	From	To	Data / Action	Via	Notes
1	POS user / session	POS	User selects "Pay by EFTPOS"	UI action	Staff initiates payment type selection in POS
2	POS	Linkly	Payment request: transaction type, amount, invoice/receipt reference, terminal/register details	Linkly API	POS sends full payment request to Linkly middleware
3	Linkly	EFTPOS terminal	Transaction amount appears on terminal display	Linkly → terminal	Staff must not manually key the amount — it is pushed by Linkly
4	EFTPOS terminal	Customer / card	Tap / insert / swipe / PIN entry	Physical terminal	Customer presents card at terminal; terminal captures card data
5	EFTPOS terminal	Westpac	Authorisation request sent to Westpac / bank network	Linkly connects POS to terminal; Westpac/bank network handles authorisation	Westpac merchant services process the authorisation with card-issuing bank
6	Westpac	EFTPOS terminal	Authorisation result: Approved / Declined / Cancelled / Timeout	Westpac payment network	Bank authorisation result returned to terminal
7	EFTPOS terminal	Linkly	Transaction response (terminal/payment response)	Linkly middleware	Linkly receives the terminal/payment response
8	Linkly	POS	Approved/declined response, transaction reference, receipt data	Linkly API response	IMPORTANT: HTTP 200/202 does NOT mean payment succeeded — must inspect actual EFT response (approved/declined flag, response code)
9	POS	POS database / MS-GP SQL	Finalise sale / refund / payment / inventory update	Direct SQL to HANDLR	Only after confirmed approval — POS writes to GP database to complete the transaction
10	POS / Finance	Westpac / settlement reports	Daily reconciliation against Westpac settlement report	Westpac merchant portal / reports	Finance team reconciles POS daily takings with Westpac settlement and GP cash receipts

Data Sent: POS → Linkly / EFTPOS

Request payload

Field	Description
Transaction type	Purchase, refund, reversal, status enquiry, or logon
Amount	Sale or refund amount in cents
POS transaction ID / receipt number	Unique POS-side reference for the transaction
Register / terminal identifier	Identifies which physical terminal to route payment to
Merchant / terminal configuration	Merchant ID, terminal ID, and Linkly connection settings
Refund reference	Original transaction reference (for refund transactions)
Optional fields	Surcharge, cash-out amount, tipping fields (where applicable)

Data Returned: Linkly / EFTPOS → POS

Response payload

Field	Description
Approved / declined flag	The definitive approval result — POS must read this, not just HTTP status
Response code / response text	Bank/gateway response code and human-readable description
Approval code	Bank-issued authorisation code (only present on approved transactions)
Receipt number / RRN / RFN	Transaction reference, Retrieval Reference Number, Reference Number for reconciliation
Terminal ID / merchant ID	Identifies the terminal and merchant account that processed the payment
Receipt content	Full receipt text for printing (customer and merchant copies)
Status result	Final transaction status for POS to determine next action (finalise, retry, or abort)

Source: GP Modification Docs / PayWay Credit Card Payment Integration.docx — Dexterity-based GP customisation enabling PayWay payments directly from GP windows.

Westpac PayWay — Overview

Card-not-present

Westpac PayWay is Aidacare's gateway for non-physical card payments — it handles any payment scenario where a physical card machine is not involved.

Payment typesOnline, phone, stored card, API-based, recurring / scheduled

ProviderWestpac (SaaS payment gateway)

IntegrationsPOS (Envisage) and MS-GP (via AIDACARE.DIC customisation)

ProcessingWestpac payment processing network

PayWay Data Flow

1POS or GP application initiates payment

2Request sent to Westpac PayWay gateway

3Westpac processes via payment network

4Result returned to POS / GP for finalisation

GP Customisation — AIDACARE.DIC

Dexterity + .NET

A GP Dexterity customisation (AIDACARE.DIC) developed by Maksud Halai integrates PayWay directly into the GP Sales Payment Entry window, enabling finance staff to process payments without leaving GP.

Customisation fileAIDACARE.DIC (Dexterity dictionary)

TechnologyDexterity + .NET integration layer

Developed byMaksud Halai

GP Window modifiedSales Payment Entry window (SopPaymentEntry)

Capabilities enabledCredit card payments, refunds, prepayments, reversals — all directly within GP

Custom Windows Added

HsPayWayCustomerMaintenance — Customer maintenance for PayWay

SopPaymentEntry modified — Sales Order Payment Entry

HsPayWayRefundEntry — PayWay refund entry

HS_PayWay_Login_Setup — PayWay login configuration

HS_PayWay_Setup — PayWay system setup

View Source Code & Config →

PayWay Integration — Source Document Screenshot

Westpac PayWay Credit Card Payment Integration screenshot from GP Modification Docs

Westpac PayWay Credit Card Payment Integration — from GP Modification Docs / PayWay Credit Card Payment Integration.docx

Core POS Capabilities

6 capabilities

1 Process Customer Sales

Retail staff can process complete point-of-sale transactions — item lookup, quantity, pricing (sourced from GP price lists), tax calculation, and sale finalisation. The POS presents a user-friendly interface while writing the transaction directly to the HANDLR GP database.

2 Accept Payments

The POS supports multiple payment methods within a single sale: cash, EFTPOS via Linkly (physical terminal), and card-not-present via Westpac PayWay. Split payments are supported. Payment outcomes are reconciled with GP and Westpac settlement reports.

3 Handle Refunds

Refunds are processed via the POS with reference to the original transaction. The POS sends a refund request through Linkly (for EFTPOS refunds) or PayWay (for card-not-present refunds). The GP database is updated to reflect the credit. Refund eligibility rules apply.

4 Capture Customer Details

Customer lookup and creation within the POS is linked to the GP customer master in HANDLR. This ensures centralised customer management — details entered at POS are available across GP, and vice versa.

5 Process Retail Invoices

Sales generate retail invoices in real time. Invoice records are written directly to the GP HANDLR database (SOP tables), enabling financial reconciliation between POS retail sales and GP accounts receivable without manual re-entry.

6 Update Inventory

Each POS sale decrements stock in the correct GP site/warehouse in real time. This provides accurate inventory visibility across all Aidacare retail branches and ensures consistent stock levels between physical retail and the GP inventory module.

EFTPOS & Westpac Merchant Services

Payment infrastructure

EFTPOS — Physical In-Store Payments

Physical card machines at Aidacare retail branches accept tap, insert, swipe, and PIN transactions. These terminals are connected to the POS through Linkly middleware (formerly PC-EFTPOS). Linkly acts as the bridge between the POS software and the physical terminal hardware.

MiddlewareLinkly (formerly PC-EFTPOS)

Terminal typesTap / Insert / Swipe / PIN — Westpac EFTPOS terminals

AuthorisationWestpac merchant services (bank network)

SupportAidacare GP team (hardware support: Linkly/Westpac)

Westpac Merchant Services

Westpac is Aidacare's merchant bank for both EFTPOS terminal payments and PayWay card-not-present payments. Westpac processes authorisations via the card network (Visa/Mastercard etc.) and provides daily settlement reports used for reconciliation.

Merchant bankWestpac Banking Corporation

SettlementDaily Westpac settlement report — reconciled against POS daily takings and GP cash receipts

EFTPOS channelPhysical terminals via Linkly

CNP channelWestpac PayWay API

POS Capabilities — Source Document Screenshot

POS capabilities screenshot from POS@Aidacare source document

POS capabilities — from POS@Aidacare.docx source document

30+ production issues documented. Key issues are listed below with resolution steps. For all issues, always confirm whether the problem is at POS, Linkly, Westpac, or GP/SQL Server before taking corrective action.

POS Application Issues

1Determine scope: is it one branch or all branches? Check other users/registers at same branch.

2Test the POS URL directly: pos.aidacare.com.au / www.pos.aidacare.com from affected machine and from another device.

3Check the Node.js backend service on AIDAPOS01V — confirm the service is running and not in an error state.

4Open browser developer console (F12) and check for JavaScript errors or failed network requests.

5If Node.js backend is down — restart the service on AIDAPOS01V and monitor startup logs.

6If infrastructure issue — escalate to Envisage and infra team with scope details (affected branches/registers).

1Confirm whether other users at the same branch can log in — isolate to single user vs. branch-wide issue.

2Check the user's role, branch assignment, and POS configuration in the POS admin/user management area.

3Review POS backend logs on AIDAPOS01V for authentication errors relating to the user's login attempt.

4Check if the user's account is active and not locked — confirm with Envisage if POS user management is required.

5If branch-wide — investigate Node.js backend connectivity to HANDLR SQL Server.

1Check POS branch settings — confirm the "Eftpos Enabled" tick box is checked for the affected branch.

2Check the user's POS settings — confirm the user account has EFTPOS payment type enabled.

3Confirm terminal/register configuration — the register may not have an EFTPOS terminal assigned.

4If settings appear correct but EFTPOS still not visible — escalate to Envisage to review POS branch/user configuration.

EFTPOS / Terminal Issues

1Check terminal power — confirm the EFTPOS terminal is switched on and displaying the idle screen.

2Check network connection — confirm the terminal's Ethernet or Wi-Fi connection is active.

3Use the "Poll Terminal" function in POS or Linkly client to test communication with the terminal.

4Confirm the Linkly / PC-EFTPOS client service is running on the register PC — restart if needed.

5If terminal still not responding after restart — contact Westpac support (for terminal hardware) or Linkly support (for middleware).

1Confirm the Linkly / PC-EFTPOS client is running on the register PC — check Windows services or system tray.

2Check Linkly logs for the error — look for connection refused, timeout, or authentication errors.

3Confirm POS can reach the Linkly client on the local network — check IP/port settings in POS branch configuration.

4Restart the Linkly client and retry the payment.

5If issue persists — escalate to Linkly support with the error logs.

1A declined payment is a normal outcome — the POS will not be finalised. No GP correction is required if POS was not finalised.

2Advise the customer to try another card or payment method (cash, different card, PayWay).

3Check the response code returned from Linkly — "Do Not Honour", "Insufficient Funds", "Expired Card" etc. — for the specific decline reason.

4Do not retry the same card repeatedly — advise customer to contact their bank if they believe it is a bank error.

Do NOT reprocess immediately. A double charge will occur if the original payment was approved. Always confirm status first.

1Check the terminal — print the terminal receipt. If "Approved" is shown, payment was processed by Westpac.

2Check Linkly transaction log for the transaction reference / RRN — confirm the final response status.

3Use the Linkly or Westpac reference to confirm payment status before taking any further action.

4If confirmed approved — manually finalise the sale in POS/GP with finance approval. Do not re-run the EFTPOS payment.

5If status is unclear — contact Westpac merchant services with the RRN to confirm the outcome.

1Check the POS audit trail for the transaction — confirm the recorded payment outcome.

2Check Linkly logs and the terminal receipt — confirm no valid approval code exists for the transaction.

3If no valid approval — the sale must be reversed or corrected. Do not assume payment was received.

4Work with finance team to reverse the GP invoice/payment record and reconcile the discrepancy.

5Escalate to Envisage and finance for audit trail correction if GP records cannot be self-corrected.

Refund Issues

1Confirm the original transaction reference is available — refunds in POS require reference to the original sale.

2Check refund eligibility: confirm the item/order meets the refund policy and time limits.

3Check if refund amount exceeds original transaction amount — Linkly/PayWay will reject this.

4Verify the original payment method — refunds must generally be returned to the original card/method.

5If POS error on refund — check Linkly logs for the specific refund response code and escalate to Envisage.

1Confirm the refund was approved on Westpac / Linkly — check terminal receipt and Linkly log for approval code.

2Check POS transaction status — did POS receive the Linkly approval response before disconnecting?

3Check GP database for the refund record — search HANDLR SOP/cash receipt tables for the transaction.

4If GP record is missing — manually reconcile the refund with finance approval. Do not reprocess the refund on Linkly/PayWay.

5Document the manual correction and notify Envisage for investigation of the root cause.

GP / Inventory / SQL Issues

1Check POS transaction status — did the sale finalise successfully in POS, or did POS show an error?

2Check GP SOP tables (SOP10100 header, SOP10200 lines) in HANDLR — search for the POS transaction reference.

3Check SQL Server connectivity from AIDAPOS01V — confirm POS can reach HANDLR at time of sale (check SQL error logs).

4If SQL timeout caused failure — check for blocking sessions in SQL Server Activity Monitor (with DBA approval).

5If POS succeeded but GP record missing — manually create the GP invoice with finance approval and document the discrepancy.

6Escalate to Envisage if POS-to-GP SQL write is failing systematically.

1Search GP SOP tables by POS transaction ID / receipt number to identify all related invoice records.

2Determine which record is the legitimate invoice — confirm against POS audit trail and payment reference.

3Void or reverse the duplicate invoice in GP — with finance team approval.

4If payment was applied to both invoices — reverse the duplicate payment application and reconcile cash receipts.

5Notify Envisage of the duplicate creation scenario — likely a POS retry on timeout without idempotency check.

1Identify the item, site/warehouse, and quantity involved in the POS sale.

2Check GP inventory tables for the item at the expected site/warehouse — confirm current on-hand quantity.

3If wrong site was updated — check POS branch-to-GP site/warehouse mapping configuration.

4Correct the branch/site mapping in POS configuration (escalate to Envisage if POS config change is required).

5Perform a manual inventory adjustment in GP to correct on-hand quantities — with warehouse manager approval.

1Compare the POS displayed price against the GP/OmniPrice item price for the same item and customer.

2Check if POS has a cached price that has not refreshed since the last GP price update.

3Force a POS price cache refresh if the option is available — or restart the affected POS register/session.

4Confirm the price in GP item master and OmniPrice contract is correct for the item.

5If price in GP is wrong — correct in GP/OmniPrice and wait for POS cache to refresh. Notify Envisage if cache refresh timing is problematic.

1Test SQL connectivity from AIDAPOS01V to the HANDLR SQL Server instance — use SSMS or sqlcmd.

2Check SQL Server service status on the GP DB server — confirm the SQL Server service is running.

3Check firewall rules between AIDAPOS01V and the GP DB server — port 1433 must be open.

4Verify the SQL credentials used by POS/NodeJS backend — check connection string configuration on AIDAPOS01V.

5Escalate to infra team if SQL Server is unreachable and the cause is network/firewall.

6Escalate to Envisage if credentials or connection configuration needs to be updated.

1Check SQL Server Activity Monitor for blocking sessions or long-running queries at the time of the issue.

2Identify the blocking session (SPID) and the blocking SQL statement.

3Only kill the blocking session with explicit DBA / management approval — never kill sessions without sign-off.

4Investigate the root cause: long GP batch posting, reporting query, or unindexed query from POS NodeJS.

5Escalate to Envisage if POS SQL queries are causing excessive blocking — may require query optimisation.

1Pull the POS daily sales report for the affected date and branch.

2Pull the Linkly transaction report for the same date and terminal.

3Compare against the Westpac merchant settlement report for the same date.

4Cross-reference GP cash receipts for the date — identify any discrepancy between the three systems.

5Identify the specific transactions causing the discrepancy — check for approved-on-terminal-not-in-POS or vice versa scenarios.

6Reconcile with finance team — manually correct any GP records with finance approval before settlement cut-off.

Use this matrix to classify POS/EFTPOS/PayWay incidents before logging or escalating. Correct classification ensures the right team is engaged and the right workaround is applied without delay.

Issue Severity Classification Matrix

POS / EFTPOS / PayWay

Severity	Example Scenario	Immediate Action
P1	All branches cannot process POS / EFTPOS payments Complete POS outage — no register at any branch can process a sale or accept any form of payment.	Immediate escalation to POS team (Envisage), infrastructure team, Linkly/Westpac, and GP team simultaneously. Activate business continuity (manual receipts). Notify management.
P2	One branch cannot process EFTPOS payments Single branch EFTPOS is down — other branches unaffected. Cash and PayWay may still be available.	Apply branch-level workaround (cash, PayWay). Investigate terminal and Linkly at affected branch. Escalate to Linkly/Westpac if terminal hardware issue. Engage Aidacare GP team.
P2	Payment approved on terminal/PayWay but GP or POS not updated Money has left the customer's account but no GP invoice or POS record was created. Risk of double-charge if retried.	Stop all retry attempts immediately. Confirm payment status via Linkly/Westpac reference. Manually reconcile the transaction with finance approval. Correct GP records. Do not reprocess until confirmed.
P3	Individual invoice / customer / inventory sync issue A single transaction did not write correctly to GP — wrong stock site, missing invoice, duplicate, or customer data mismatch.	Investigate POS and GP logs for the specific transaction. Correct the transaction/master data in GP with appropriate approval. Log for Envisage review if pattern emerges.
P4	Receipt print issue / user setting issue / daily banking view issue Non-critical cosmetic or configuration issue — payments and GP data are intact, no financial risk.	Standard support fix. Review POS user/branch settings, printer configuration, or daily banking report filter. Escalate to Envisage if configuration change is needed.

POS Triage Guidance — First Steps for Any POS Issue

Use before escalating

1 Determine scope: Is it one register, one branch, or all branches? Scope determines severity (P1 vs. P2/P3).

2 Identify the layer: Is the issue in POS UI, POS backend (NodeJS), Linkly/EFTPOS, PayWay, or SQL/GP? Each has a different owner.

3 Check for payment risk: Has money moved (Westpac approved) without a corresponding GP/POS record? If yes — treat as P2 minimum. Stop retrying.

4 Collect reference numbers: Gather POS transaction ID, Linkly reference, RRN, terminal receipt number, and GP invoice number before escalating.

5 Escalate to the right team: Envisage (POS software/config), Linkly (EFTPOS middleware), Westpac (terminal/merchant/settlement), Infra (AIDAPOS01V/SQL Server), GP team (HANDLR DB / finance).

6 Document the incident: Record scope, affected branch/register, timeline, reference numbers, and actions taken — even if resolved at L1/L2.

Key reminder: An HTTP 200/202 from Linkly does not confirm payment success. Always read the EFT response body. When in doubt about a payment outcome — check the Linkly log and Westpac merchant portal before taking any corrective action or reprocessing.