This is an old revision of the document!
<< List of all previous releases
Release 19.3 - Key Features
Event Financials and Reconciliation
It is always challenging for a section to know how well they've been managing their finances (which are driven largely by their events). So, ScoutsTracker now gives an event-by-event, and year-by-year overview of event financials.
Viewing an event's wallet now not only shows the transactions in/out of the wallet, but additionally clarifies the financials via three more detail reports
Assessed Fees (i.e., automatically calculated based on members' signup and/or attendance). These are “receivables”, because you need to collect money for each assessed fee.
Accrued expenses (i.e., recording when a member pays for groceries, supplies, accommodation, facilities. These are “payables”, because you need to reimburse each expense.
Adjustments (i.e., the amount you had to transfer to/from the Troop's wallet to zero out the event's profit/loss, or to cover a specific member's bad debt
The detail reports then get rolled up into a “Reconciliation” report, that lets one see the *expected* numbers (i.e., the assessed fees - accrued expenses) vs the *actual* numbers (e.g., fees received, reimbursed expenses). Ideally the expected numbers should equal the actual money handled, but if they don't, then tips are provided recommending how to make them balance. Finally if the event's profit was eventually absorbed into the Troop's wallet, or if the Troop had to cover a member's bad debt, then those adjustments are used to affect the event's final wallet balance.
Going to “Account” | “Wallets” | “Event wallets” now shows for each event in a year the event's expected vs actual numbers and the wallet balance.
Additionally, “Account” | “Wallets” | “Event wallets” now includes an “All Events” rollup, so that one can find out the expected and actual numbers added up across all the events in a specific year. Drilling down on “All Events” will show a reconciliation report that provides an year's overview of information such as the total expenses recorded for food, for accommodation, etc. plus the overall profit/loss.
Other Wallet Enhancements
SS-6425: When self-pay is disabled for an event, use default source selection of cash/cheque/e-transfer when recording payments via “Manage Selections”
The “All” payment button in “Manage Selections” (for past events with signup enabled) needs to consider attendance recorded without signup
Added next/prev buttons so you can quickly scroll through member or event wallets
SS-6641: Prevent recording fee payment with auto-deposit for self-signups
SS-6410: Add a rollup toggle to list of member wallets, that shows an entry for each (possibly shared) wallet rather than for each member
When adding new non-member payments, the source wallet is pre-selected when there's only one choice
Add a “Event Wallet” link to the event's action menu, for easy access
In an event wallet, add a link to the event when viewing from “Account” | “Wallets” | “Event wallets”, for easy navigation
Wallet Bug Fixes
There was a reference to fundraising wallets on “Account” | “Event defaults”
SS-6344: If a sync times out on a “Sign Me Up!” action, but actually succeeds on the server after the timeout period, then the automatic sync retry can create a second payment record
Add an expense to a member who HASN'T SIGNED UP for a fee event. The owing amount incorrectly shows them as owing the expense they just paid, rather than needing a reimbursement. Also impacts “Manage Signup/Attendance” total.
Access by reference/value error meant that some expense-only transactions for members not signed up wouldn't be recorded
SS-6404: Couldn't record multiple expenses, because 2nd expense gets recorded as reimbursement
SS-6404: Misleading/incorrect values for event's profit/loss
When editing the event and deleting/updating transactions, going to “Add” transaction and covering loss / claiming profit was using the non-edited balance
Miscellaneous Enhancements
SS-6429: Always preserve training progress when you change your email address
Don't let people pick “scout trek” when creating new events
Deep equals comparison wasn't handing NaN values
Bug Fixes
RSVP: Servlet
HTML body had no scrollbar
Editing an event, as a Scouter, and then clicking the “RSVP” button was actually taking you to the “Manage Signups” page
Trying to revert YES signup back to Unknown for a member who never actually signed up but was implicitly signed up because they'd paid now changes signup to an explicit NO
Fixed a login role issue when you were signed into the same account in two tabs, as a Scouter login in one tab and a non-Scouter login in the other tab
SS-6448: Attendance report showing all inactive youth
Patch (2024-10-24)
Miscellaneous Enhancements
PAYMENT, SS-6425: When paying/refunding fees or reimbursing expenses, pre-select the source wallet choice last used for that member
COLLABORATION: A section with a subgroup's shorted name becomes “(Monday) - Beavers”, whereas “Monday - Beavers” is sufficient
COLLABORATION: Name swatches on co-subscribed/shared calendar items should be using the shortened name
Let emails be filtered by email address (search doesn't permit '@' or '.'). Allow apostrophes and spaces to be a valid search/filter character
(Kenneth Kully) don't navigate after initial sync if you've already navigated somewhere
(Kenneth Kully) less visually-intrusive way to show sync progress
Can now close Sync Progress lightbox
Bug Fixes
SS-6453: Active youth with valid entry date but no attendance in any events were being excluded from attendance report
SS-6457: The initial number beside the “Unfinalized events” link was initially including old personal events that had no attendees
ADMIN: left pane width is too narrow for support@scoutstracker.ca login
SEA_SCOUTS: Once you set a troop to sea scouts, all subsequent connections to troop accounts showed that vocabulary
PUSH: preview message of unconfirmed events with Scouter-only visibility, was using term “(Scouter)” rather than “(Scouters)”
PAYMENT: Recording a new member payment, and then re-editing that payment before saving, was resulting in the payment source not being recorded