S/004

SayHesap

Current accounts, stock, banks, cash, cheques, invoices, point of sale, warehouse and production orders as one modular application — rather than nine screens that disagree with each other.

StatusActive
Active2026 —
CategoriesData, Software, Commerce
StackReact · JavaScript · Vite · Context state · MySQL
01

Context

Small and mid-sized businesses do not lack accounting software. They lack accounting software that agrees with the warehouse.

02

Friction

Stock lived in one program, invoices in another, cheques in a folder, and the bank in a browser tab. Each was correct on its own terms and none of them could be added up.

Closing a month meant reconciling systems rather than reading them.

The ledger isnot a report.It is the shop.

03

System

One application, many modules, a single shared state. A movement recorded in point of sale is the same movement the stock module decrements and the reporting module counts — not a copy of it.

Modules are split by the way a business thinks (firms, customers, stock, banks, cash, cheques, invoices, expenses, warehouse, production) rather than by the way a database is shaped.

Architecture
Point of saleInvoiceCurrent accountsStock / WarehouseCash / Bank / ChequesProduction ordersReporting
04

Interface

Dense by design. A detail view opens over the list instead of navigating away from it, because the work is comparative: you are almost never looking at one record for its own sake.

Point of sale is the exception — it is the only screen tuned for speed over density.

05

Data

Money and material are modelled as the same kind of event: something moved, from somewhere, to somewhere, at a time, for a reason. Cash, bank, cheque and stock are then views over one movement log.

06

Evolution

The current work is the boundary with the operational side: making the ERP the place financial truth is settled, while the store and service systems stay the place operational truth is produced.