Report an issue here
ooptify community
Roadmap
Add inventory rounding and refresh controls
## 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.
RX based suggestion
create rules that will flag patients based on their RX wether they're a good fit for contacts, multifocal lenses etc.
Multi location printing
allow 1 location to print the barcodes for all locations' inventory
Movable widgets
allow widgets to be moved around on the dashboard Additional feedback from Calvin (9 November 2026): - Move the button used to enter rearrange mode from the top right of the page to the bottom right, so it stays out of the way when it is not needed. [Superseded by the revised placement below after DEV testing.] - Rename the widget move buttons from “Earlier” and “Later” to “Up” and “Down”, respectively. Revised feedback after DEV testing (9 November 2026): - Replace the lower-right rearrange button with a simple settings/gear icon immediately after the Dashboard heading. It should open the same rearranging/edit mode. - In rearranging mode, allow the three dashboard sections (Today, KPIs, and Snapshot) to be reordered as whole units, including placing Today at the bottom. - Preserve the existing ability to reorder individual cards within their own sections, independently of the section order. - Implement, test, and deploy this revision to DEV only; retain Awaiting Testing after verified readiness. Further DEV testing feedback (9 November 2026): - Give the gear icon a visibly pressed/active state while rearranging mode is enabled. - Clearly distinguish whole-section Up/Down controls from individual widget Up/Down controls. The rightmost widget controls currently sit too close to section controls and can be confusing. - Use distinct accessible styling for section controls, such as color with clear section labeling and spacing, rather than relying on color alone. - Preserve section/card ordering behavior and deploy this refinement to DEV only after tests.
Provider calendar sync
Allow providers to sync their personal devices to their appointment schedule using CalDAV / .ics. That way their smart phones is in sync with their appointment diary
3rd party billing
Allow practices to allocate patient bills or balances to third-party payers, such as DVA, work safety/compensation schemes, employers paying for safety glasses, or other external parties. Scope clarified by Calvin: - This is optional for each practice: some practices use third-party claiming and others do not. - Practices can create their own labels/buckets for third-party claims rather than being limited to fixed schemes. - Provide a UI to link/allocate the relevant bill or balance to the third-party payer/bucket while retaining its relationship to the patient and the associated consultation and/or dispensing. - The practice handles claiming in the relevant external portal or process. How payment is determined and processed, including the amount payable, remains outside ooptify. - ooptify records the external payment amount and its reference/ID against the relevant bill/claim. - Support a possible patient gap payment alongside the third-party portion. - Keep outstanding third-party balances in the relevant billing bucket/account until reconciled. This is flexible third-party billing and payment recording/reconciliation, not direct electronic DVA claiming or a new integration with external claiming portals.
Upload limits and optimisation
Make sure the upload limits for media are feasible, and implement more aggresive optimisation. We need to do a pass and make sure that we don't over bloat out db's without optimisation, and sensible limits.
Heidi Health integration
Until ooptify develops their own integrated dictation feature. Allow users to use things like Heidi health in the interim
Patient tasks on consult screen
Consult view screen should be able to show patients that have tasks / important notes
Approval override controls
Develop price override approval work flows for the different access levels for staff
Customer direct routing
allow an option for CL supplier to send directly to the patient. There maybe extra fees involved, and the practice would still get a commission on all future sales.
Limit advance online bookings
Allow practices to limit how far ahead online appointments can be made, allow the users the ability to set this in the amount of days i.e. 30-90 days etc.
Allow independent products per eye
Allow dispensing staff to order a pair of spectacles where the Right and Left lens differs
Shopify Integration
Allow ooptify users to connect their inventory to a shopify store, so that their inventory can be sync'd and sold both in store and online
Consultation re-assignment
can consultations be reassigned
Allow dispensing orders to send immediately
Allow dispensing orders to send immediately for the staff with the correct access level privileges