## Why Superseding an earlier auto-merge design after finding a real business case it breaks: a customer buying 1 sealed bottle ("Chai") of a medicine, plus 3 loose pills ("Viên") dispensed against a prescription, is two operationally distinct dispensing actions. Auto-converting and merging them into a single "103 Viên" line is mathematically correct (pricing is consistent per `conversion_qty`) but destroys information the business needs — the receipt/cart should still show a whole bottle was sold separately from a counted-out prescription amount. Combined with an unrelated, hard requirement that **no cart quantity may ever display as a decimal** (a prior unit-conversion design was rejected specifically because it could show e.g. `0.0167 Hộp`), automatic cross-unit merging is not an acceptable design for this system. Separately, the "Đơn hàng đã mua" tab still has no empty-state message when a customer has no orders, inconsistent with the rest of the system's list pages. ## What Changes - **Cart lines are keyed by `(product code, unit)`, not by product code alone.** Adding a product under a unit that has no existing line creates a new line at quantity 1. Adding under a unit that already has a line for that product increments that line's quantity by 1. Two different units of the same product are never auto-converted into each other or merged — each is always its own line. - **BREAKING (internal only):** the POS cart's submitted `items[...]` form-field shape changes from one entry per product code to one entry per cart line (code + unit), since a product can now appear more than once. No external API is affected — this is a same-request round trip between the POS page and `OrderController`. - Autocomplete search results (the non-barcode "type a product name" flow) expand to show **one selectable entry per configured unit** for a matched product, not just its default unit, so a cashier can deliberately add "Chai" and "Viên" as two distinct actions. Exact-barcode scanning is unchanged — it still adds/increments at the product's single default unit, since the data model has no per-unit barcode. - **The existing per-line unit-select dropdown is kept — but switching a line's unit only relabels it, it does not convert or scale the quantity number.** This was reconsidered mid-design: the exact-barcode-scan path (still single-default-unit, no per-unit picker) has no other way to correct a mis-scanned line's unit, so removing the dropdown entirely would have made any non-default-unit sale unreachable whenever a cashier scans instead of searching by name. Switching a line's unit recomputes its price/subtotal at the new unit and updates its label, leaving the quantity number exactly as it was — the number represents how many times the cashier added/scanned, not a physical amount that must be preserved across units, so the cashier can adjust it afterward via the existing quantity input if needed. This still guarantees no decimal quantity can ever appear, because no division/multiplication of quantity happens anywhere in the cart (neither on add nor on switch) — a stronger guarantee than a whole-number conversion guard, without losing the ability to fix a line after adding it. If switching a line's unit lands on a unit that another separate line (for the same product) already occupies, the two lines merge by directly summing their quantities (both already share the same unit at that point, so no conversion is involved) into the target line, and the line being switched from is removed. - `OrderController::store`, `update`, and the `create_now_mode` draft-rebuild path change from being keyed by product code/id (which silently collapses multiple submitted lines for the same product into one) to being keyed per submitted line, so multiple lines for the same product persist as separate `order_product` pivot rows. No schema change — the pivot table already has no uniqueness constraint on `(order_id, product_id)`. - `customer-orders.blade.php`'s order list gets a "Không có dữ liệu" empty-state row (`@empty` branch, `colspan="7"`), matching the convention already used by `orders`, `products`, `customers`, `debts`, and `customer-gift-received` — unrelated to the cart-lines work above, carried over unchanged from the earlier version of this proposal. - Adds PHPUnit feature tests for `OrderController::store`/`update` covering multi-unit-line persistence — this controller currently has zero automated test coverage, and the `$order_attach[$prod->id] = [...]`/`$products[$item->code] = [...]` keying bugs this change fixes are exactly the kind of regression that would otherwise go unnoticed. ## Capabilities ### New Capabilities *(none)* ### Modified Capabilities - `product-unit-pricing`: cart-line requirements are substantially revised — a product can have multiple simultaneous cart lines (one per unit actually sold), the unit-switch dropdown is kept but changed to relabel-only (no quantity conversion) with merge-on-collision, and order submission/persistence supports multiple lines per product per order. - `customer-order-category-filter`: unchanged from the prior version of this proposal — add a requirement that the "Đơn hàng đã mua" order list shows a "Không có dữ liệu" empty-state row when there are no orders to display. ## Impact - `app/Http/Controllers/PosController.php` — inline POS cart JS (`Admin::script` block): cart-line identity/keying (using a CSS-selector-safe `__` separator, not `::` — see Design), the autocomplete render (per-unit entries), the `.unit-select` change handler (relabel-only + merge-on-collision, not removed), and the `create_now_mode`-equivalent draft-reload path (`fillOrderDraft`) so reloading a draft with multiple lines for one product doesn't collapse them. - `resources/views/vendor/admin/index.blade.php` — the `#scannerItem` jsrender template (line identity/DOM id, `