ScoutsTracker has added the concept of a “wallet”, that is basically like a bank account in which financial transactions can be recorded, e.g., its balance can be topped-up with deposits, payments can be made for events, and transfers can be made between wallets.

The term “wallet” is being used rather than “account” because “account” already has meaning within ScoutsTracker (i.e., the entire collection of roster, events, badge progression, emails, inventory, etc.), and additionally, “wallet” better connotes the ability to pay for things directly from the wallet.

There is a wallet for each member, each event, and the Section itself.

When a parent/guardian gives you cash, a cheque or sends you an e-transfer, you can record that amount in the member's top-up wallet. Likewise, if your Group Committee, Sponsor, or other donor gives your Section money, you can record that amount in your Section's wallet.

A key feature of a member's wallet is that when a member signs up for an event that has a fee, the member can opt to pay the fee directly their wallet (provided there's sufficient balance), and not have to write a cheque or organize an e-transfer.

Similarly, when a Scouter records a signup, they can optionally record payment directly from the member's wallet. And when a refund or expense reimbursement is recorded, you'll have the ability to simply transfer the amount back into the member's wallet for use towards the next event.

One of the key goals of this feature is to dramatically reduce the amount of time Scouters spend processing external payments and chasing down unpaid fees! It is envisaged that parents will periodically give you a top-up cheque/e-transfer but thereafter, you can withdraw funds as necessary.

If a parent does still give you cash/cheque/e-transfer to pay for an event, when recording the payment in the event, ScoutsTracker will actually record their cash/cheque/e-transfer as a deposit into the member's wallet followed immediately by transfer to the event. This standard accounting practice means it's possible to “follow the money” via a formal wallet statement (like your bank statement) that shows all the money in/out of the wallet, with explicit references to any applicable event and/or member. I.e., a parent/guardian will have complete clarity as to what has happened the balance in their wallet.

And there are also other features and benefits. E.g., if the Section decides to subsidize an event, that subsidy can be recorded in the event's wallet (and will correspondingly appear as a deduction in the Section's wallet). And when reviewing the event's wallets, you can quickly see which events made a profit or lost money; and the Section can claim an event's profit or cover an event's loss, by transferring money in/out of the Section's wallet.

To support all this, there is now a new login permission called “Can see everyone's wallets”. Note, anyone with the “Can manage the schedule” can see an event's wallet as they need to track payments and expenses. However, simply needing to manage an event's finances should not entitle the login to see all of a member's other transactions, hence the new login permission.

There is now additional built-in Training to cover the basics of wallets and recording transactions.

There is a SC trial underway that lets all Scouters earn OAS. ScoutsTracker now lets you Give Credit and track Scouters' progression through the OAS stages.

To be clear, Scouters who are active Youth members in another section have already been able to earn OAS for quite some time, and this new feature just extends that ability to all Scouters.

Also, Scouters are able to earn only OAS stages… PAB's or other Program badges are still off-limits.

However, allowing adult Scouters to earn OAS is a concept that is under trial by Scouts Canada, and can be viewed as controversial. On the one hand, letting Scouters earn OAS stages lets Groups see how well skilled their Scouters are to help the Youth progress through the OAS, it lets parents identify Groups with the best-skilled Scouters, it lets SC identify which Skills need more resources, and it can contribute to a “whole Section” enthusiasm for OAS particularly in the older Sections. On the other hand, there is a valid concern that Scouters will unwittingly but inevitably shift the focus of the Section's activities from what the Youth need to what the Scouters want; and, it fundamentally goes against the dogma that Scouting is a Youth development program so that by allowing Scouters to track their skills, this basic philosophical tenet has been compromised.

For Sections that oppose the idea of allowing their all Scouters to track OAS, this new ability can be enabled/disabled by going to “Account” | “Program preferences”.

• SS-5957: Support British convention of using periods instead of colons in times (e.g., “6.30pm”)
• SS-6011: Better generation of login names when a) there are redundant LoginAccess records, and b) when there are customized parent login names but no parent login members
• Reduce red-herring messages relating to duplicate LoginAccess records
• RSVP: RSVP form now uses members' actual ages as the primary indicator of whether consent is required

• SS-5984: Embedded calendar was showing “Commissioners” instead of “Committee” in the calendar swatches
• SS-5993: COMMITTEE: Missing whitespace in Welcome Message text
• SS-6012: Personal Record Sheets (and initial requirements report) weren't showing the requirement numbers)

• SS-6099: Allow transferred youth to be left active in the Section
• WALLETS: SS-6092: Some payments weren't being saved
• SS-6079: Inactive sections with no signup/remittance history should not be included in the Master/Overview rollups
• Simplified database accesses re SyncTimestamp
• PAYMENTS: Wired-off red-herring ASSERT
• Avoid second ASSERT when dealing with StaleStateException when saving presence

• SS-6066: You could get stuck in a loop of not being able to load the page
• Couldn't record P/G Consent via “Manage Signups”
• SS-6076: Special awards were breaking synchronization
• SS-6084: Adult Scouter OAS being saved, but not downloaded
• Duplicate outing LID's could generate synchronization exceptions
• A “duplicate” menu item was appearing in the action menu for regular badges (should only appear for SDG projects)
• SS-6087: Can't re-edit previously-entered requirement notes
• SS-6100: Javascript error in embedded calendar
• WALLETS: SS-6088: Couldn't add new payments to old events, when accessing payment via “Edit” (rather than “Manage Signups/Attendance”)
• WALLETS: SS-6104: Could mistakenly be led to believe all your payments disappeared
• SS-5999: Emergency List for events was including all members of a particular type if NONE of that particular type were signed up
• COMMITTEE: SS-6110: Couldn't click back, if you selected the last missing Section in an event's Target Audience
• A “sync after” timestamp of -1 wasn't forcing a full refetch
• SS-6112: Multiple leaders for a single login could grind performance to a halt
• COMMITTEE: SS-6121: Making a non-administrator login the “master” was resulting in mis-configured master login permissions
• ADMIN: Avoid potential exception when doing fixDuplicateUsers

• SS-6170: Trickle out resolveFinalized calls when doing them in bulk
• Trimmed down logging statements
• Use new radio selectors for event Risk Category
• AAF (Cat1): Message about GC's that are opted out of notifications shouldn't say “cannot approve this” for Cat 1 events
• AAF (Cat1): Post-submission “No further action is required” lightbox should be expanded to say “because this is a Cat 1…”
• AAF (Cat1): SS-6167: Add a message during AAF submission, if it's Cat 1.
• SS-6137: Import Servlet should not inactivate members who are listed as both active (this year) and pending (next year)
• Added a timeout task to help debug synchronization timeouts
• Don't do a confirmation when user does a manual sync (only if they are online)
• Suppress the ScoutsTracker Built-in Training post once you reach Stage 3
• PRS: Added a “don't include events” to “Reports” | “Record sheets”, if you just want to print off the youths' sheets

• SS-6144: Couldn't delete a qualification via “Reports” | “Member qualifications”
• AAF (Cat1): list of AAF's .aaf-count glyph is wrong for Cat 1 events (shouldn't say not yet approved)
• SS-6154: Can't re-RSVP if there are payments and the balance owing is zero
• TRAINING: Typo “You can sit down with the span”. also, explain where to find All Requirements
• TRAINING: Clearing a training doesn't trigger a sync upload
• Delay the updating of cachedOutings to prevent postgresql hang from breaking download syncs
• PRS: PRS contained an OAS group for “training”
• PRS: Sheets republished via “Report” | “Record sheets” have dashes

• Removed duplicate (but harmless) cid attachment
• SS-6218: Better wording (including tip) explaining that you're not enabled for off-line access
• SS-6204: AAF: Events with embedded images in the program description or transportation notes now have the embedded images replaced with CID attachments
• WALLET: SS-6216: Scroll to the input field when there's a problem with the amount entered for a new transaction
• WALLET: SS-6223: Payments recorded by Scouters that exceed the member's wallet balance generate a warning message (they can continue or cancel)
• SS-6220: Subscription source's attachments are shown when editing the section event's attachments, but may not be removed

• SS-6207: Definition of active earners in DbSynchronizer was including “inactive - unknown” members
• Fixed use of “Ledger” rather than “Wallet”
• SS-6211: “Transfer to another member” is displaying as “Transfer to self” in source member's wallet
• SS-6207: addSpecialAward was doing a rejectNonEarners check
• SS-6213: Wallet “Add Payment” not rounding default value to two decimals
• SS-6213: Event payments could sometimes show members as owing $0 (epsilon rounding error)
• SS-6215: Doing a transfer from one wallet to another member's shouldn't list inactive members

It is now possible for siblings, or parents/children, or spouses to share the same wallet.

This means that funds deposited to a top-up wallet can be used to pay for events attended by any of the members who share the wallet.

You can configure sharing by going to “Account” | “Wallets” | “Member wallets” | “Sharing”. There you'll see a table report, with names in both the rows and the columns. If two members are sharing a wallet, there will be a dot in the table cell corresponding to the row and column of the two members.

Clicking on a blank cell will cause the member designated in the column to start sharing the wallet of the member designated in the row. All the previously-recorded transactions from both members will be aggregated under the shared wallet.

You can also split apart a previously-shared wallet. I.e., clicking on a cell with a dot will create a new wallet for the member designated in the column, and migrate all the previously-recorded transactions pertaining to that member into their new wallet.

• SS-6229: Default event eligibility should be switched to “Eligible” when an Other Participant is changed to a proper youth member
• SS-6220: List of event attachments should show subscription source attachments at the head of the list, and not allow editing them
• WALLET: Fixed up a couple of misleading/confusing to/from designations in ledger statements

• WALLET: SS-6230: Inappropriate error message when wallet is empty, but receiving funds via check/cash/e-transfer (i.e., not from the empty wallet)
• SYNC: Could timeout if there were AAF's for events with lots of embedded images in the program description or transportation notes

ScoutsTracker now integrates with ScoutShop.ca for program badges and most uniform elements (woggles, council crests, etc.)

When you go to “Account” | “Inventory”, if you have a recommended order quantity (based on the stock you have on-hand, your preferred minimum stock, and the number of badges that are “complete but not yet awarded”), then an “Add to Cart” button will appear. Clicking this button will cause your ScoutShop.ca shopping cart to be set to the required number for that specific badg e.

At the bottom of the report there is an “Add All to Cart” that will ensure your shopping cart contains *all* the recommended quantities for those badges needing ordering.

ScoutsTracker's “Add to Cart” does not impact anything else you might already have in your cart (e.g., if you're also purchasing a tent).

ScoutsTracker's “Add to Cart” is compatible with the ScoutShop “Group Order Tool”.

Note: there are some items which won't have an “Add to Cart” button, because they're either not carried by the ScoutShop (e.g., your Group's crest) or there's not enough information (e.g., ScoutsTracker doesn't track the exact language of a youth's language strip). You'll have to order them outside of ScoutsTracker.

Additionally, the Inventory report is now editable. I.e., you can quickly tweak the numbers of badges on-hand and the preferred number, or the recommended order quantity for all inventory items from a single page.

The “Reports” | “Shopping list” report has been deprecated, and is now supported by a “Show as shopping list” toggle when viewing “Account” | “Inventory”.

• Cleaned up migration code
• “Position in the Troop” list should use new radio selectors
• Special Award image selector list should use new radio selectors

• SS-6131: National Standing report's national average stats weren't being locally stored on a per-section basis
• Could display duplicate event labels for some events

• Fixed some minor formatting issues in the history report
• Sticky header, and independently scrolling sidebar/page-content
• Improved message in “Access granted by logins” report when there aren't any parent/guardian logins

• Fixed server exception in scrubMember (due to deprecated LedgerPayment members)
• Fixed a non-navigation problem when clicking on an event in “Home” | “My reports” | “My events”
• “Reports” | “Event Signup/Attendance” shouldn't contain master/overview events
• SS-6625: Parent logins weren't being told they hadn't paid for events