Excerpt | ||
---|---|---|
| ||
Understand the usage of Wallets within CRM.COM |
Panel | ||
---|---|---|
| ||
Table of Contents
|
What are Wallets?
A Wallet is a type of account which contains an amount of money that can be used to fund transactions within CRM.COM. It works as a mini-ledger that can easily be topped up by various payment events, or spent by CRM.COM functions such as Prepaid Subscriptions or the Redemption of Awards.Wallets are managed through Wallet-specific processes which can create, update or cancel Wallets manually or automatically, as well as generate Wallet Transactions that credit, debit or refund Wallets.
Optionally, Wallets can be configured so that the Transactions affecting their Balance automatically generate the respective Financial Transactions on the related Accounts Receivable.
Wallets Glossary
Wallet Balance
The amount of money which is available (credits less debits) in a Wallet and can be used to carry out transactions within CRM.COM.
Wallet Credit Transaction
A transaction that funds the Wallet. Credit Wallet Transaction amounts:
- can be allotted to specific products
- can be assigned specific days of the week or times of the day when they can be spent
- can be appointed specific shops/departments where they can be spent.
- can have a validity date set to designate the day, from which the amount can be spent
Credit Transactions created automatically are defined in the Wallet Definitions - Crediting Causes.
Wallet Debit Transaction
A transaction that deducts funds from the Wallet.
Debit Transactions created automatically are defined in the Wallet Definitions - Debiting Causes
Wallet Reimburse Transaction
Reimburse Transactions created automatically are defined in the Wallet Definitions - Reimburse Causes
Wallet Void Transaction
A transaction that cancels or reverses any type of Wallet Transaction (credit, debit, reimburse) by voiding it. A Wallet Void Transaction is always related to the Wallet Transaction that it cancelled
Wallet Transactions can either be voided by the System or manually. Events causing the voiding of Transactions by the System are defined in the Wallet Definitions - Void Causes
Restrictions on how the amount available in the Wallet can be spent. For example, from a Balance of €20, there can be an Allotment of €15 to be spent exclusively on Product A.
Allotments on Debit Transactions provide information on how the Balance was spent.
- Credit Wallet Allotments: Wallet Allotments that credit the Wallet, which can be created by Credit Wallet Transactions, Voided Debit Transactions or Voided Reimburse Transactions.
- Debit Wallet Allotments: Wallet Allotments that debit the Wallet, which can be created by Debit Wallet Transactions, Reimburse Wallet Transactions or Voided Credit Wallet Transactions.
Wallet Transaction Expiration Date
Status | ||||
---|---|---|---|---|
|
A date available on Credit Transactions (Credit Wallet Transactions, Transfer Wallet Transactions) that indicates the expiration of the credit amount.
Note |
---|
Used by the System Allocation Process to allocate debit transactions on credit transactions, and by Wallet Balance Expiration Runs to expire Wallet Amount that has not been spent and is expired. |
Wallets Key Processes and Concepts
Excerpt | ||
---|---|---|
| ||
Understand the usage of Wallets within CRM.COM |
Panel | ||
---|---|---|
| ||
Table of Contents
|
What are Wallets?
A Wallet is a financial account which allows customers to use a credit balance to fund transactions within CRM.COM. It works as a mini-ledger that can easily be topped up by various payment methods or spent by CRM.COM functions such as Prepaid Subscriptions or the Redemption of Awards.
Wallets are managed through Wallet-specific processes which can create, update or cancel Wallets manually or automatically, as well as generate Wallet Transactions that credit, debit or refund Wallets.
Optionally, Wallets can be configured so that on every top up a sales invoice is generated, allowing the Company to record revenue and VAT on the top up rather than the spend transactions which tend to be multiple time more.
Wallets Glossary
Terms | Descriptions | ||||||||
---|---|---|---|---|---|---|---|---|---|
Wallet Balance | The amount of money which is available (credits fewer debits) in a Wallet and can be used to carry out transactions within CRM.COM. | ||||||||
Wallet Opening Balance
| The Wallet balance brought forward from the previous Wallet balance period, as calculated by the Wallet Balance Period closing process. | ||||||||
Wallet Transactions | Transactions which are used to debit or credit a Wallet. | ||||||||
Wallet Credit Transaction | A transaction that funds the Wallet. Credit Wallet Transaction amounts:
Credit Transactions created automatically are defined in the Wallet Definitions - Crediting Causes. | ||||||||
Wallet Debit Transaction | A transaction that deducts funds from the Wallet. Debit Transactions created automatically are defined in the Wallet Definitions - Debiting Causes | ||||||||
Wallet Reimburse Transaction | A transaction that deducts funds from the Wallet to pay back an amount of money. The Reimburse Transaction can also use that amount for processes other than payback. It can, for example, convert the amount remaining in the Wallet into a credit Financial Transaction and allocate it against the Wallet holder's Accounts Receivable. Reimburse Transactions created automatically are defined in the Wallet Definitions - Reimburse Causes | ||||||||
Wallet Void Transaction | A transaction that cancels or reverses any type of Wallet Transaction (credit, debit, reimburse) by voiding it. A Wallet Void Transaction is always related to the Wallet Transaction that it cancelled Wallet Transactions can either be voided by the System or manually. Events causing the voiding of Transactions by the System are defined in the Wallet Definitions - Void Causes | ||||||||
Wallet Transfer Transaction | A transaction which is used to transfer money from one Wallet to another. The Wallet Transfer Transaction refers to two Wallets, the (debit) Wallet from which money is transferred and the (credit) Wallet to which money is transferred. | ||||||||
Wallet Allotments | Restrictions on how the amount available in the Wallet can be spent. For example, from a Balance of €20, there can be an Allotment of €15 to be spent exclusively on Product A.
| ||||||||
Validity Consumption Date | The date from which allotment funds are available for spending. Before this date, the funds are not considered in the calculation of the Wallet Balance. | ||||||||
Wallet Transaction Expiration Date
| A date available on Credit Transactions (Credit Wallet Transactions, Transfer Wallet Transactions) that indicates the expiration of the credit amount.
|
Wallets Key Processes and Concepts
Processes / Concept | Description | |||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Transfer Money between Wallets | Money can be transferred between Wallets belonging to different owners. Transferring money triggers the creation of two new Wallet Transactions, a debit for the current Wallet from which money is transferred and a credit for the new Wallet to which the money is transferred. The transfer function can be accessed from the Wallets Data Entry or the Wallets Transactions Data Entry pages. | |||||||||||||||||||||||||
Expiration of Wallet Balance
| The Wallet Balance Expiration process is available and is used to identify the Wallet Amount that has not been spent and has expired. The resulting debit reflecting the expired amount is directly allocated against the expired credit amount.
| |||||||||||||||||||||||||
| The Wallet Balance Expiration process is available and is used to identify the Wallet Amount that has not been spent and has expired. The resulting debit reflecting the expired amount is directly allocated against the expired credit amount.
|
| allocation | allocation | Allocation for Wallet Transaction Allotments
Status | ||
---|---|---|
|
Funds spent from the Wallet (e.g. Debit Wallet Transactions) are allocated against funds available in the Wallet (money from Credit Wallet Transactions).
The System first allocates the debit to the credit with the oldest Expiration Date. In case a Credit Transactions with an expiration Date is not present, then the FIFO principle is applied, i.e. the Debit Transactions are allocated against the Credit Transactions with the earliest Created Date.
Note |
---|
The allocation takes place within the same allotment group, and the Validity Consumption Date is also taken into consideration. |
A positive Wallet Balance indicates how much money is available in the Wallet to be spent, while a negative Wallet Balance indicates how much money is owed.
Note |
---|
The balance logic of a Wallet is opposite to that of the Accounts Receivable, where a positive amount indicates money owed to the company and a negative amount indicates money owed to the customer by the company. |
Two fields provide information related to Wallet balance:
- Wallet Balance
Balance = (credit WT amounts + voided debit WT amounts + voided reimburse WT amounts) - ( debit WT amounts + reimburse WT amounts + voided credit WT amounts)Status colour Blue title Available from CRM.COM
R12.0.0
Funds spent from the Wallet (e.g. Debit Wallet Transactions) are allocated against funds available in the Wallet (money from Credit Wallet Transactions).
The System first allocates the debit to the credit with the oldest Expiration Date. In case a Credit Transactions with an expiration Date is not present, then the FIFO principle is applied, i.e. the Debit Transactions are allocated against the Credit Transactions with the earliest Created Date.
Note |
---|
The allocation takes place within the same allotment group, and the Validity Consumption Date is also taken into consideration. |
A positive Wallet Balance indicates how much money is available in the Wallet to be spent, while a negative Wallet Balance indicates how much money is owed.
Note |
---|
The balance logic of a Wallet is opposite to that of the Accounts Receivable, where a positive amount indicates money owed to the company and a negative amount indicates money owed to the customer by the company. |
- Wallet Balance
Balance = (credit WT amounts + voided debit WT amounts + voided reimburse WT amounts) - ( debit WT amounts + reimburse WT amounts + voided credit WT amounts)
- Product Balance
Balance = (credit WTA amounts + voided debit WTA amounts + voided reimburse WTA amounts) - ( debit WTA amounts + reimburse WTA amounts + voided credit WTA amounts)
WTA = Wallet Transaction Allotment (related to a specific product)
title | Ignored by the calculation |
---|
- As from CRM.COM R12.0.0 the Wallet's opening balance is also taken into account in the Wallet's total Balance. The opening balance is summed with the aggregated amounts of Wallet Transactions which are not related to a Wallet Balance Period.
- Product Balance
Balance = (credit WTA amounts + voided debit WTA amounts + voided reimburse WTA amounts) - ( debit WTA amounts + reimburse WTA amounts + voided credit WTA amounts)
WTA = Wallet Transaction Allotment (related to a specific product)Status colour Blue title Available from CRM.COM R12.0.0
As from CRM.COM R12.0.0 the Product's opening balance is also taken into account in the Product's total Balance. The opening balance is summed with the aggregated amounts of Wallet Transaction Allotments (related to a specific product) which are not related to a Wallet Balance Period.
View Wallet Balance amount, which is valid only in the future
Status | ||||
---|---|---|---|---|
|
The balance of a Wallet for a day in the future may differ to the current balance, due to amounts that will be made available in the future, i.e they have a future Validity Date.
Note |
---|
Money that will expire between current day and the future date are not taken into consideration. |
Consumption Amount Calculation for long periods
- If the remaining consumption amount is more than six months, then the estimation may not be precise.
- If the remaining consumption amount is more than three years, then no results will be retrieved.
Note |
---|
The maximum estimated time is one year by default, but can be configured for more through Configuring Prepaid Billing Run Definitions. The 3-year limit on the maximum estimation period no longer applies. |
- Once a BR (Billing Run) is executed the amount on the Wallet, and the remaining product allotted amount are calculated.
- The cost of the product is calculated per day according to the price on the Price Plan.
- If more than one products exist then, the sum of all the products is calculated. For example:
Product Allotted = Cost per Product per day
Wallet = Sum of (Cost per Product per day)
- If more than one products exist then, the sum of all the products is calculated. For example:
Remaining consumption days (Wallet) = Remaining Balance / Sum of (Cost per Product per Day)
Remaining consumption days (Product) = Remaining Allotted Amount / Cost per Product per Day
Note | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
Unless the UOT (Unit of Time) of a product in the Price Plans is set to 'Daily', the calculation of the daily rate will vary according to the number of days in each month, as in the example below:
|
Wallet Transactions are voided (reversed) instead of cancelled. All types of Wallet Transactions can be voided except Transfer Wallet Transactions. When a Wallet Transaction is voided, the System creates a Void Wallet Transaction which is an exact opposite of the initial transaction.
- If you void a (-) Debit Wallet Transaction, then a (+) Void Wallet Transaction is created.
- If you void a (-) Reimburse Wallet Transaction, then a (+) Void Wallet Transaction is created.
- If you void a (+) Credit Wallet Transaction, then a (-) Void Wallet Transaction is created.
Wallet Transactions can be manually created via the Wallet Transactions Data Entry page.
Provided it is configured to do so (via the active Wallets Definition), CRM.COM can automatically generate Wallet Transactions of any type through various System processes.
CRM.COM processes that can be configured to automatically generate Wallet Transactions are the following:
Wallet Transactions are voided (reversed) instead of cancelled. All types of Wallet Transactions can be voided except Transfer Wallet Transactions. When a Wallet Transaction is voided, the System creates a Void Wallet Transaction which is an exact opposite of the initial transaction.
- If you void a (-) Debit Wallet Transaction, then a (+) Void Wallet Transaction is created.
- If you void a (-) Reimburse Wallet Transaction, then a (+) Void Wallet Transaction is created.
- If you void a (+) Credit Wallet Transaction, then a (-) Void Wallet Transaction is created.
Wallet Transactions can be manually created via the Wallet Transactions Data Entry page.
Provided it is configured to do so (via the active Wallets Definition), CRM.COM can automatically generate Wallet Transactions of any type through various System processes.
CRM.COM processes that can be configured to automatically generate Wallet Transactions are the following:
- Creating Financial Transactions
- Cancelling Financial Transactions
- Executing Prepaid Billing Runs
- Cancelling Wallets
- Creation of Customer Events
- Creation and cancellation of Spend Reward Transactions
- Creation and cancellation of Award Reward Transactions
- Creation and cancellation of Award Expiration Reward Transactions
Status colour Red title Applicable up to CRM.COM R9.0.0
Working with Wallet Balance Periods
Status | ||||
---|---|---|---|---|
|
A Wallet Balance Period is defined as the time frame in which Wallet Transactions are posted. The time frame can be set to monthly and cannot be modified through the System.
There is always one open period in the System, which includes all new Wallet Transactions posted during that period.
The Wallet Balance Periods also affect the way that the Wallet Balance is calculated. During the process of closing a Period, the opening balance of all Wallets is calculated.
Wallets Viewing & Access Controls
Business Network Characteristics define the level of access for each record. i.e., whether it will be available for selection, viewing or editing.
Entity | Network Characteristics | Description |
---|---|---|
Wallets |
| |
Wallet Transaction Types |
|
Wallets Related Modules
Entity | How Wallets interact with Entity |
---|---|
Accounts Receivable | An Accounts Receivable must be selected to create a Wallet. The System can be configured as such that transactions affecting the Wallet also affect the Accounts Receivable (and vice versa). For example, when a Payment is made to the Accounts Receivable, a Credit Wallet Transaction credits the Wallet, and an Invoice debits the Accounts Receivable. |
Wallet Transactions | Wallet Transactions are created to debit or credit Wallets. |
Rewards Participants | Rewards Participants own a Wallet which contains Wallet Transactions created via Reward Award Transactions and Reward Spend Transactions. |
Prepaid Subscription | Prepaid Subscriptions Billing affect subscribers' Wallets, rather than their Accounts Receivable. When Prepaid Billing is executed, the Wallet is debited accordingly and its Balance evaluated to determine whether a Subscription should stay activated. |
Vouchers | Vouchers can be used as a payment to Top Up a Wallet by triggering Credit Wallet Transactions. If specific products are defined on the Vouchers, then Wallet Allotments are created, restricting the use of the available amount to these products. |
Rewards | Customers participating in Rewards schemes can access their awards and spend funds via their Wallets. |
Wallets - Business Examples
The following section provides business examples of how the CRM.COM Wallets module is used.
Calculation of Wallet estimated consumption for Prepaid Subscriptions
Panel | ||||
---|---|---|---|---|
| ||||
Business Requirement Company ZX offers Prepaid Subscriptions to its customers.
Case The customer has paid €300 and has two products, Sports HD and Kids HD, on their Subscription. Customer has subscribed to the normal Price Plan with the following rates: Kids HD: €20 per month Sports HD: €30 per month CRM.COM Solution Customers with Prepaid Subscriptions have an Accounts Receivable and a Wallet. The Wallet contains the money that the customer has paid upfront for use on their Prepaid Subscription. Once the Prepaid Billing Run is executed the following information will be entered in the Wallet:
|
Allocation of Wallet Transactions -
Status | ||||
---|---|---|---|---|
|
Panel | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The following process demonstrates how funds spent from the consumer's Wallet are allocated against Credit Transactions (funds already available in the Wallet) based on the aforementioned allocation logic. Table 1 lists a number of Debit and Credit Transactions reported into the System.
Table 1 - Wallet Transactions Table
Table 2 - Allocations Table Table 2 shows the allocation and the order in which it occurs in the System, taking into consideration the:
|
Panel | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
Related Areas
|