Treasury & Step Payments Fixes
PR #358 — fix When user add new payment for operation with pulses … Branch: mo/fix_treasury_and_payment_steps
This change is a pair of targeted bug fixes in the money-handling parts of Dentolize. It is small in code (3 files, ~20 lines changed) but it touches two places clinics use every single day: taking the diagnostic fee when an appointment is booked, and collecting payments for multi-session treatments. Both bugs caused money to be recorded in the wrong place or split into the wrong number of records — exactly the kind of thing an accountant notices at the end of the day and cannot easily un-tangle.
This feature is unreleased. Everything below describes behavior on the pre-release branch sandbox and in the branch source; it is written so each team can prepare before it ships.
The two problems this PR fixes
1. The treasury box went blank when collecting a diagnostic fee
When a receptionist created a new appointment and chose to collect the diagnostic (examination) fee on the spot, they picked which treasury (cash drawer / bank account) the money went into. On the mobile app, selecting a treasury left the field empty — the choice did not "stick." Staff either could not save, or saved with no treasury attached, so the cash landed in the wrong drawer or nowhere obvious.
Root cause: the selection screen handed the chosen treasury back under one name, and the appointment form read it under another. It stored the treasury's name text instead of the treasury object the field needed to display.
2. Paying a multi-step ("pulse") operation split into two records
Some treatments are billed as a course of sessions / pulses / steps — for example an implant done over several visits. When staff added a new step to an operation that had already received some payment, the system over-counted how much of that operation was already paid, then, on the next payment, it split one payment into two step-payment records and only attached the doctor's salary/commission adjustment to the first of the two. The doctor's commission was therefore under-recorded.
Root cause: two calculation mistakes — (a) when a new step was added, the already-paid amount was spread onto the new step proportionally instead of only filling what was genuinely still unpaid; and (b) when deciding whether an operation was fully paid, the code compared the operation's total against a single step's discount and tax instead of the operation's discount and tax.
What changed, at a glance
| Area | File | What it does now |
|---|---|---|
| Treasury field (mobile) | packages/clinic-mobile/.../newAppointment/NewAppointmentScreen.js | Reads the returned treasury as an object, so the field shows the picked treasury |
| New step paid amount (server) | packages/server/src/resolvers/mutations/actions/addOperationStep.js | Fills a new step with only the truly-unpaid remainder of what was already collected |
| Fully-paid check (server) | packages/server/src/resolvers/mutations/mutationUtils/paymentUtils.js | Uses the operation's own discount & tax to decide "paid in full" |
How to read these docs
- Walkthrough — annotated screenshots from the live sandbox showing the two
real screens involved.
- Feature breakdown — each fix explained twice: a plain-language
Business view, then a Technical view with exact file:line references into the repository.
- By team — the same change re-framed for Marketing, Sales, Support,
Training, Stakeholders, and Quality.
- Reference — a glossary of the domain terms (treasury, pulse, step
payment, salary adjustment) and the relevant data-model notes.