Canonical business vocabulary for Lakuyo. Product docs, control-plane specs, client code, backend contracts, database names, and UI copy should use these meanings consistently.

Domain architecture (agreed)

Founders agreed this product-domain tree on 31 Aug 2026:

Lakuyo
├── POS
│   ├── Cart
│   ├── Checkout
│   ├── Payment
│   ├── Receipt
│   └── Sale / transaction history

├── Inventory
│   ├── Product catalogue
│   ├── Stock quantity
│   ├── Receiving / adjustment
│   └── Stock movement history

└── Customer membership (Phase 3, POS-024)
    ├── Member registry (pelanggan member)
    ├── Member vs walk-in pricing
    ├── Admin membership discounts
    └── Member purchase history
 
Order Management
→ separate domain
→ expands later
→ Order ≠ Sale

Phase 1 ships POS + Inventory only. Order Management is deliberately outside that Phase 1 tree. Customer membership (POS-024) expands in Phase 3.

Core domains

POS

Checkout and transaction processing. Includes Cart, Checkout, Payment, Receipt, and completed Sale / transaction history.

Inventory

Product and stock management. Includes Product catalogue (with optional image and category per product), stock quantity, receiving / positive adjustment, and Stock movement history.

Category distinction: category is optional when saving a product (POS-002) but expected in cart browsing (POS-004). Uncategorised products still appear under a default bucket at checkout.

POS and Inventory are both first-class core Lakuyo domains. Inventory is not merely a secondary feature of checkout.

Order Management

Customer requests before final checkout. Includes Order, Order Item, table/order-taking flows, waiter/Sales workflows, and fulfilment. Full Order Management expands later (Phase 3). It is a separate domain, not nested under POS, and Order ≠ Sale.

Customer membership

Registered store customers (pelanggan member) managed by the merchant — not Lakuyo Pro subscription. Phase 3 (POS-024). Members get optional member pricing and admin-configured discounts; only member-linked sales appear in that member’s purchase history. Walk-in (non-member) sales have no customer-level history.

Canonical nouns

TermMeaning
OrderCustomer-requested items before final checkout. May be edited, fulfilled, cancelled, or later converted into a Sale.
SaleCompleted commercial transaction after checkout/payment confirmation.
SalesStaff role that assists customers and may create or prepare an Order. Never use “Sales” to mean a completed transaction entity.
WaiterRestaurant/café-specialized Sales/order-taking role.
KasirCashier role responsible for checkout/payment completion and creating the Sale.
PaymentSettlement record attached to checkout/Sale, such as cash, EDC, or manually confirmed QRIS.
ReceiptCustomer-facing record generated for a completed Sale. Merchants often call the printed copy invoice or struk; Lakuyo domain term is Receipt.
Invoice / struk (merchant language)Colloquial label for a printed Receipt on thermal paper — not a formal B2B tax invoice (NPWP, numbering). Thermal print: POS-023.
ProductSellable catalogue item. Optional fields include SKU, category, and image.
CategoryOptional label on a product (POS-002). Cart UI derives category buckets for browsing (POS-004); products without a category use a default uncategorised bucket.
Stock MovementAuditable change in product stock caused by receiving, adjustment, sale consumption, transfer, or another defined stock event.
Stock Movement HistoryChronological ledger view of movements for a tracked product (or inventory-wide).
Tax (store)Store-level tax enabled/rate from setup (POS-001). Applied to the whole discounted sale at checkout (POS-005). Phase 1 has no per-product taxability.
Member / pelanggan memberCustomer registered in the merchant’s membership program (POS-024). Receives member pricing and accumulates purchase history.
Walk-in / non-memberCheckout without a linked member. Uses regular product price; sale has no customer-level purchase history.
Member priceOptional per-product price for registered members (member_price). When absent, members pay regular price.
Lakuyo ProMerchant’s paid subscription to Lakuyo (POS-010). Not the same as store customer membership.

Critical distinction: Order ≠ Sale

Example restaurant flow:

Customer orders at Table 5

Waiter records an Order

Kitchen / fulfilment

Kasir performs checkout

Payment confirmed

Sale created

An Order may exist for a period of time before payment. The Sale exists only once checkout/payment is completed.

Retail follows the same distinction: Sales staff may assist a customer and prepare an Order; Kasir later completes the Sale.

Roles are not domains

Admin, Kasir, Sales, Inventory, and Waiter describe employee responsibilities. A person may hold multiple roles, especially on a free single-device setup.

For example:

Small merchant owner
= Admin + Inventory + Sales + Kasir

On larger paid deployments, roles may use distinct synced devices.

Engineering naming rule

Prefer explicit domain nouns in code and contracts:

  • Order, OrderItem
  • Sale, SaleItem
  • Payment, Receipt
  • Product, StockMovement
  • Member, MembershipSettings
  • Employee, Role

Avoid ambiguous names where sales could mean staff, orders, completed transactions, or reports.

Roadmap boundary

This vocabulary does not move full Order Management into Phase 1. Phase 1 remains core POS + Inventory; Phase 3 introduces restaurant tables, waiter/Sales order-taking, kitchen/fulfilment, and related Order Management flows.

Spec cross-reference (Phase 1 inventory)

Authoritative behaviour: lakuyo-control-plane specs.

TopicSpec ID
Store taxPOS-001
Product image, optional categoryPOS-002
Positive adjustment, Stock Movement HistoryPOS-003
Category browsing in cartPOS-004
Checkout tax calculationPOS-005
Receipt view + sharePOS-007
Thermal receipt print (invoice/struk)POS-023
Product images in backupPOS-008
Customer membershipPOS-024