A sale has more than one total

A retail sale connects the counter, stock, and accounts. Read how Niqat approaches a shared transaction record and clear meaning across the business.

The number on a receipt looks simple. Behind it are a product, a package, a quantity, a price, and a record of what changed.

If those meanings drift apart, staff end up explaining the difference by hand.

Start with the unit

A customer can buy one bottle while the supplier delivers a case. The catalog needs to express that relationship explicitly. A barcode belongs to the intended package, and the transaction should preserve its original unit and quantity.

That is why catalog preparation is operational work, not just data entry.

Keep the amount exact

Niqat’s conceptual money type combines an integer with a currency code. Currency scale comes from explicit registry metadata. The language used to display the amount does not change its stored meaning.

Exactness matters when a sale is returned, a statement is reconciled, or a report is reconstructed. An attractive rounded figure is not a substitute for a correct recorded value.

Coordinate the effects

Sales, inventory, and accounting have different responsibilities, but they need to agree about the same committed operation. The architecture keeps domain ownership explicit and coordinates mandatory effects through code-owned invariants.

Optional automation must not become a shortcut around those invariants or a path to unrestricted database mutation.

Make the boundary visible

The interactive counter on this site demonstrates basket arithmetic only. It deliberately creates no stock movement or accounting entry. Real transactions run in the Niqat application, through its authorized operation flow.

For a closer look at the underlying conventions, read money and data contracts.