Dentolize · Treasury & Step Payments Fixes Walkthrough
On this pageWhat users will noticeLikely tickets — before vs. afterTriage checklistThings to set expectations onWhen to escalate

For Support

What users will notice

Two long-standing money annoyances go away:

  1. On mobile, the treasury field no longer goes blank after you pick a

treasury for a collected diagnostic fee.

  1. Payments on multi-session ("pulse") treatments record as a **single

clean payment, and the doctor's commission is fully recorded** — no more "why is this payment split in two?" or "the doctor's commission looks low."

Likely tickets — before vs. after

Ticket themeBefore the fixAfter the fix
"I picked a treasury for the exam fee but the field is empty" (mobile)Field cleared, couldn't save / saved blankSelected treasury stays in the field
"My collected fee isn't tied to a treasury"Possible when the field was blankFee posts to the chosen treasury
"One payment shows as two records on a stepped operation"Could happenRecords as one
"Doctor's commission on a multi-visit treatment is too low"Adjustment only on the first split recordAttributed correctly
"This operation still shows as not fully paid after I paid it off"Possible (wrong paid-in-full check)Marked paid in full correctly

Triage checklist

For the treasury-blank report:

  1. Confirm the user is on the mobile app (the fix is mobile-specific).
  2. Confirm they're in New Appointment → Diagnostic Fees → Collected, then

tapping the Treasury picker.

  1. Confirm they're on the fixed build (branch mo/fix_treasury_and_payment_steps

or later). On older builds the field will still blank out.

  1. Workaround on old builds: use the default treasury (pre-filled) rather

than changing it, or record the fee from the web app.

For split-payment / low-commission reports:

  1. Identify whether the operation has steps ("Pulses / Sessions") — check the

patient's Operations tab.

  1. Note whether the operation had partial payment before a step was added —

that's the trigger for the old over-counting.

  1. On the fixed build, new payments record correctly. Historical records

created before the fix are not retroactively repaired by this change — escalate those for manual correction if the clinic needs the old data fixed.

Things to set expectations on

  • This release fixes future behavior. It does not go back and re-split or

re-attribute payments that were already recorded incorrectly. If a clinic asks "will my old numbers fix themselves?" the answer is no — escalate for manual review.

  • The treasury fix does not change the web app's behavior (web already

displayed the value); a web user reporting "it works fine" is expected.

When to escalate

  • Any request to correct historical split payments or under-counted

commissions.

  • A treasury still blanking out on a build that should include the fix (capture

app version / commit, device, and a screen recording of the picker).