On this page
Executive summaryWhy it mattersRisk & impactWhat is explicitly not addressedPR-vs-code note (transparency)Recommended gates before releaseFor Stakeholders
Executive summary
PR #358 delivers two financial-correctness bug fixes in Dentolize:
- On mobile, the treasury selection now persists when collecting a
diagnostic fee at booking (previously the field blanked out).
- Server-side, payments on multi-session ("pulse") operations are
allocated and settled correctly, ending a defect that split one payment into two records and under-recorded the doctor's commission.
Small footprint (3 files, ~20 lines), high trust value. Unreleased — currently on a pre-release branch/sandbox.
Why it matters
- Books that reconcile. Collected cash tied to the wrong or no treasury is a
direct hit to end-of-day reconciliation — the daily ritual clinic owners judge the software by.
- Fair doctor pay. Under-recorded commission on stepped treatments is a
payroll and trust problem between clinic and clinician.
- Data integrity. One payment recorded as two is corrupt financial data that
ripples into reports, tax, and audits — costly to unwind later.
Risk & impact
| Dimension | Assessment |
|---|---|
| Blast radius | Money-handling paths: appointment diagnostic-fee capture (mobile) and operation step-payment settlement (all clients) |
| Change size | Low — 3 files, no schema/migration change |
| Data migration | None. Fixes are forward-looking; historical mis-recorded payments are not auto-corrected |
| Regression surface | Payment allocation and "paid in full" detection — must be verified across single-step, multi-step, discounted, taxed, and insured operations |
| Rollback | Straightforward — self-contained logic changes, no data shape change |
What is explicitly not addressed
- Historical correction. Payments recorded incorrectly before this release
stay as they are; clinics needing clean historical data require manual remediation. Plan support/finance guidance accordingly.
- Web treasury field. Unchanged (it already worked); only the mobile field
is fixed.
PR-vs-code note (transparency)
The PR title/description describe the symptoms (payment "splits into two records," "salary adjustment only recorded for first record"). The committed code fixes the underlying math — how a new step inherits already-paid amounts, and how "paid in full" is computed using the operation's own discount/tax. The commission symptom is a downstream effect of that math. Documentation reflects the code as written, not the description alone.
Recommended gates before release
- Finance-scenario QA sign-off (see For Quality).
- Support enablement on the "no retroactive fix" message.
- Confirm mobile build carrying the treasury fix is the one shipped.