POS / Retail testing profile

Critical journeys (4)

A journey is the smallest unit a product owner feels end to end. These are the journeys this profile treats as critical; each is linked to test cases, or states plainly why it cannot execute yet.

• Login → Billing → bill print/share — cases: JRN-POS-01, GEN-WEB-BILLING — Blocked: no TEST-QA credentials are configured in the platform secret store, so no authenticated case may execute (Sections 14/31). The journey skeleton is PROPOSED and requires owner approval plus credentials.
• Quotation → Sales Order → Delivery Challan → Bill — cases: JRN-POS-02, GEN-WEB-QUOTATIONS, GEN-WEB-SALE-ORDERS, GEN-WEB-DELIVERY-CHALLANS, GEN-WEB-BILLING — Blocked: no TEST-QA credentials are configured in the platform secret store, so no authenticated case may execute (Sections 14/31). The journey skeleton is PROPOSED and requires owner approval plus credentials.
• Purchase Order → stock-in → inventory reflects — cases: JRN-POS-03, GEN-WEB-PURCHASE-ORDERS, GEN-WEB-INVENTORY — Blocked: no TEST-QA credentials are configured in the platform secret store, so no authenticated case may execute (Sections 14/31). The journey skeleton is PROPOSED and requires owner approval plus credentials.
• Sale → stock decreases → Day Close totals reconcile — cases: JRN-POS-04, GEN-WEB-SALES, GEN-WEB-INVENTORY, GEN-WEB-DAY-CLOSE — Blocked: no TEST-QA credentials are configured in the platform secret store, so no authenticated case may execute (Sections 14/31). The journey skeleton is PROPOSED and requires owner approval plus credentials.

Proposed business invariants (5)

Invariants are the arithmetic rules a product in this category must never break. In MC Testing they are platform proposals (status PROPOSED) seeded from standard practice for the category, each carrying a source note; they bind a product only after its owner approves them, and they are never presented as the product's own documented rules.

• Trial balance: total debits equal total credits for every period.
  Platform proposal from standard POS/accounting practice — not yet confirmed against Dukaan's documented rules (Section 17: PROPOSED until owner-approved).
• Bill total = Σ line amounts − discount + tax, on every generated bill.
  Platform proposal from standard POS/accounting practice — not yet confirmed against Dukaan's documented rules (Section 17: PROPOSED until owner-approved).
• Stock after a sale = stock before − quantity sold (per SKU, per warehouse).
  Platform proposal from standard POS/accounting practice — not yet confirmed against Dukaan's documented rules (Section 17: PROPOSED until owner-approved).
• Day Close total = Σ of that day's bills (net of returns and discounts).
  Platform proposal from standard POS/accounting practice — not yet confirmed against Dukaan's documented rules (Section 17: PROPOSED until owner-approved).
• A completed return restores the returned quantity to stock and reverses the sale amount.
  Platform proposal from standard POS/accounting practice — not yet confirmed against Dukaan's documented rules (Section 17: PROPOSED until owner-approved).

Readiness gates

Category weights (proposed, stored with every score snapshot): Functional correctness 25% · Business logic & data integrity 20% · Security 20% · Integration & reliability 10% · UI/UX & accessibility 10% · Performance 10% · Deployment & operational 5%.

• No open P0 finding (including any confirmed public data exposure).
• Billing critical journey PASS on the TEST-QA account.
• Day-close reconciliation invariant holds on TEST-QA data (after owner approval of the invariant).
• Public-surface suites (smoke, visual, a11y, security) executed with zero unexplained FAILs.

Platform proposal seeded from the Section 25 defaults — owner approval pending. These thresholds are NOT Dukaan's documented release rules (none are published); they take effect only when the owner approves them.

Release blockers

• Any confirmed public data exposure (P0, Section 18.1).
• Any open critical security finding.
• Billing journey (JRN-POS-01) failing on the TEST-QA account.
• A PROPOSED business invariant found violated on TEST-QA data after owner approval of that invariant.

Security requirements

• No confirmed public data exposure (Section 18.1 leak sweep clean) — a confirmed exposure is a P0 release blocker.
• Tenant isolation: one shop's data must never be visible to another shop (verified on the TEST-QA account once credentials exist).
• Security headers present on public pages (HSTS, CSP, nosniff, clickjacking protection) — Section 29.
• Authentication boundaries hold: every non-public route redirects to /login when unauthenticated (Phase 3 verified 29/31 routes).

Required evidence

• Per-case step results with screenshots on failure (browser/visual cases).
• Redacted API snapshots for API cases (no secret values in evidence).
• Leak-sweep probe table (JSON) per security run.
• Lighthouse metrics per profile (standard and low-end reported separately).

Cross-cutting packs on this profile