Add inventory rounding and refresh controls

About this issue

## Report Uploaded inventory with a supplied selling price of $495 shows $544.50 including 10% GST. A manual override to $500 shows $550. Changing inventory rounding to Nearest $10 appeared not to alter existing uploads. Calvin requested diagnosis before creating this task. ## Diagnosis Read-only source diagnosis at ooptify commit 10c939c174db3cdd447f031f09f922d1713aae05. The behavior is consistent with the current save/recalculate workflow, not an established GST arithmetic defect: - Upload mapping labels the price “Selling Price (ex GST)”. It saves the original baseline and calculated prices. A supplied upload price does not automatically become a manual override; reimports preserve an existing override. - Pricing rules are location- and head-category-specific. Supplier Catalogue and My Inventory have separate rules. The settings UI initially selects Supplier Catalogue; uploaded local stock uses My Inventory. - Saving rules only updates location_pricing_rules. Existing local_inventory_items retain their stored prices until separately recalculated. - Bulk Repricing → Recalculate from rules previews existing active inventory in the selected location and filters, then requires explicit Apply. It skips manual overrides and retains unavailable prices. - Automatic pricing adds GST before rounding the customer price. Nearest $10 is ordinary nearest rounding, not round up. Manual overrides are ex GST and bypass merchandising rounding. - My Inventory defaults preserve the uploaded baseline with no rounding. Inactive/unmatched rules or missing formula inputs can also retain baseline pricing without rounding. Verified example: - $495 ex GST, no rounding → $544.50. - Same baseline, active Keep Inventory Selling Price + Nearest $10 → $540.00, not $550.00. - Manual override $500 ex GST → $550.00. - Manual override $495 remains $544.50 even with Nearest $10 configured. - Round up whole dollar gives $545.00. No round-up-to-next-$10 option exists in the inspected enum. Do not infer that $550 is the intended nearest-$10 result or change supplied/manual prices automatically. ## Updated feature request — 4 November 2026 Calvin asked: “can we add a option that would round up or down, like they can set it them selves, and in the bulk repricing we could add a button to refresh aka re round existing prices?” Replace the earlier clarification-only scope with configurable rounding direction and an explicit way to refresh/re-round existing inventory prices. Requested behavior: - Let practice admins choose round up, round down or nearest, plus the rounding increment. Preserve No rounding and the existing .95/.99 options unless a later product decision changes them. The reported $10 use case must be supported; confirm the full increment list during design rather than assuming arbitrary custom increments. - Continue rounding the final customer price after GST. At $544.50 inclusive, $10 rounding means up → $550, down → $540, nearest → $540. Exact multiples stay unchanged. - Add a clearly labelled Refresh / Re-round existing prices button in Bulk Repricing. It must open an explicit preview for the current location and selected category/stock/brand/supplier filters before applying any price changes. - Make clear that saving rounding settings alone does not alter existing inventory. Show the selected My Inventory versus Supplier Catalogue scope and the relevant category. - Preserve historical invoices and existing location/business isolation. Existing implementation to extend: The rounding enum currently provides nearest $1/$5/$10, round up whole dollar, .95, .99 and none. The existing bulk Recalculate from rules action recomputes the complete pricing formula using base_selling_price ?? srp, then applies rounding. It is not a rounding-only refresh of the current stored customer price. Its preview/apply flow can be reused, but the new button must not silently change the pricing basis. Acceptance criteria: 1. Rounding direction and increment are explicit, persisted, validated and used consistently by preview and pricing calculation. Include the $10 examples above, exact multiples, midpoint behavior, GST-free items, zero/free prices and no-rounding. 2. Refresh/Re-round clearly states whether it rounds current stored inclusive prices or recalculates the full formula. Before/after prices, matched/changed counts, skipped overrides and unavailable prices are visible. No automatic repricing on settings save. 3. Apply requires an explicit confirmation for the displayed location/filter scope. Cancel makes no changes. Handle stale previews or changed rules/rows safely so confirmation does not silently apply materially different results. 4. Manual overrides remain unchanged by default and are clearly counted as skipped. Do not clear or rewrite manual overrides silently. If inclusion is desired, settle its explicit opt-in behavior and whether override provenance is retained before implementing it. 5. Repeated refresh with unchanged settings is stable. Preserve original baseline/provenance appropriately, do not apply repeated rounding drift, and do not mutate historical invoices. 6. Clearly report applied/skipped/failed results; partial failure or a retry must not be represented as a complete successful refresh. 7. Add focused regression tests for each new direction/increment and refresh mode, clearing overrides, repeat runs and scope isolation. Earlier diagnostic test results below cover existing behavior only, not the proposed feature. Update relevant architecture/ADR documentation for changed pricing rules. Open design decisions before implementation: - Refresh basis: rounding-only on the current stored inclusive price, full Recalculate from rules, or two explicitly labelled actions. Do not assume the existing full recalculation is equivalent to the requested re-round. - Supported increments beyond the required $10 example. $1/$5/$10 match current nearest options; arbitrary custom increments have not been requested or approved. - Whether admins should ever opt in to include manual overrides, and what happens to their override status. Safe default is to skip them. - Whether these controls also appear for Supplier Catalogue rules; this reported problem and refresh action concern My Inventory. The user has requested task capture, not implementation or live repricing. The previous diagnosis and its live-data limitations remain valid. ## Evidence All source links use the inspected commit: - [Upload field definition](https://github.com/karubi02/ooptify/blob/10c939c174db3cdd447f031f09f922d1713aae05/lib/inventory/import-definitions.ts#L222) and [import pricing](https://github.com/karubi02/ooptify/blob/10c939c174db3cdd447f031f09f922d1713aae05/app/api/inventory/import/route.ts#L241). - [Calculation, fallback and overrides](https://github.com/karubi02/ooptify/blob/10c939c174db3cdd447f031f09f922d1713aae05/lib/pricing/inventory-pricing.ts#L125). - [Save rules API](https://github.com/karubi02/ooptify/blob/10c939c174db3cdd447f031f09f922d1713aae05/app/api/locations/%5BlocationId%5D/pricing-rules/route.ts#L100), [bulk recalculation](https://github.com/karubi02/ooptify/blob/10c939c174db3cdd447f031f09f922d1713aae05/app/api/locations/%5BlocationId%5D/pricing-rules/bulk-reprice/route.ts#L137), and [settings UI](https://github.com/karubi02/ooptify/blob/10c939c174db3cdd447f031f09f922d1713aae05/components/locations/location-pricing-rules-tab.tsx#L129). - [ADR-153: separate local inventory defaults](https://github.com/karubi02/ooptify/blob/10c939c174db3cdd447f031f09f922d1713aae05/docs/architecture/decisions/ADR-153.md), [ADR-049: GST rounding order](https://github.com/karubi02/ooptify/blob/10c939c174db3cdd447f031f09f922d1713aae05/docs/architecture/decisions/ADR-049.md). Verification: 27 existing focused non-browser tests and 12 diagnostic assertions passed using Node 24 native TypeScript with in-memory import resolution; dependencies were absent. No code changes, installations, full builds, browser tests, live database calls, repricing or deployment. Checkout remained clean. Still unverified: affected tenant/location/item, original mapping, stored baseline/override/rule values, selected scope/category, whether recalculation was applied, and deployed commit/schema. These must be checked before claiming the exact reported incident is reproduced. Duplicate check found no matching active task. Historical “Pricing formula” (3185226a-ccca-450e-936f-d48286846638) concerns multiplier plus fixed amount and is distinct. Tracking only: keep New, private/internal and unpublished. This task capture does not start implementation, change prices, release code or send email.