Skip to content

Architecture: Central pricing/adjustment service & financial ledger boundary #369

Description

@khaira777

Architecture: Central pricing/adjustment service & financial ledger boundary

Summary

Pricing logic is currently spread across POS, orders and bills. Manual discounts (#359-adjacent), promotions/coupons (#359), combos (#366), tips (#364), gift cards (#363), split checks and refunds (#278) will all interact — a small central pricing/adjustment service and a proper financial transaction/ledger boundary will pay for themselves.

Goals

Order
  ↓
Bill
  ↓
Payments (Cash | Card | Gift card | Loyalty)

Bill adjustments (Manual discount | Promotion | Coupon)

Refunds → reference original payment/bill

Shift → cash in − cash refunds = expected drawer
  • A single place that computes prices/adjustments, taking an order snapshot so historical bills are immutable.
  • A ledger boundary so promotions/gift cards/tips/refunds don't become four unrelated piles of accounting.
  • Incremental: introduce with these features, not a giant "rewrite pricing engine" project.

Related existing work

Acceptance criteria

  • Order/bill pricing flows through one adjustment module; snapshots stored (see Feature: Promotion engine with coupons as one mechanism #359 order_adjustments).
  • Financial transactions write through a ledger boundary (payments, refunds, gift-card movements).
  • No behavior change for existing manual discounts/split checks (regression-tested).

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:backendBackend (Express/SQLite)enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions