Wallets: managing records
You need: Wallet manager — edit to create or change records. Browsing needs only the view permission. Importing credit needs Wallet codes — import, separate again.
A wallet record is one movement of credit. The customer's balance is the net of their records — so you never edit a balance directly, you add or adjust the records behind it.
Adding credit
Create a record against the customer with its amount and the dates it is valid between. This is the manual path: service recovery, a goodwill gesture, a correction.
For many customers at once, import a phone list — see Importing from a CSV.
Set an end date deliberately. Credit with an unnecessarily long life is a liability that sits on the books; credit that expires sooner than the customer expects becomes a complaint. Pick the date on purpose rather than accepting a default.
Adjusting a record
An existing record's end date and amount can be updated.
Use this to correct a genuine data-entry error. For anything a customer has already seen, prefer adding a correcting record instead: editing the original rewrites what the customer was told, and leaves nobody able to see what happened.
Expiring records
Expiring ends one or more records immediately. The credit stops being spendable from now on, and the record stays visible.
This is the right tool for credit issued in error, or for closing out a promotion. It is gentler than deletion and it preserves the explanation.
Bulk changes
Wallets follow the standard pattern — read How bulk changes work first.
The criteria are starting date, ending date, amount and, optionally, a comment.
| Operation | Effect |
|---|---|
| Check | Counts non-redeemed records matching the criteria |
| Bulk update | Updates every matching non-redeemed record |
| Bulk delete | Removes every matching non-redeemed record |
The comment is the most useful criterion you have. If you tag a batch with a distinctive comment when you create it, you can later act on exactly that batch and nothing else. Without it you are matching on dates and amount, which will eventually catch records from a different campaign that happen to share them.
Credit already spent is never affected, whatever you do here.
Deciding what to do
| Situation | Action |
|---|---|
| Customer owed compensation | Create a record |
| Credit issued at the wrong amount | Create a correcting record; don't edit the original |
| Credit issued to the wrong customer | Expire it, then create it on the right customer |
| A whole batch issued with the wrong dates | Bulk update, matched on the batch's comment |
| A batch that should never have gone out | Bulk delete — removes only what nobody has spent |
Before any bulk operation
- Run the check and read the count.
- If it isn't what you expected, your criteria are wrong — especially if you are matching without a comment.
- Apply, then track to completion.
- Spot-check a customer from the batch on Wallets: finding a customer.
Related pages
- Wallets: finding a customer — lookup, balance and records
- How bulk changes work — the shared pattern
- Importing from a CSV — issuing credit in bulk
- Vouchers — a fixed single-use amount instead of a balance