On this page
Overview
A wallet is a financial account which allows customers to use a credit balance to fund transactions within CRM.COM.
Major features
- It works as a mini-ledger that can easily be topped up by various payment methods such as credit card and voucher payments or by awards earned through reward program participation, and spent either on prepaid subscriptions or redemption of awards.
- Wallets are managed through wallet-specific processes which can create, update or cancel wallets manually or automatically.
- Wallet transactions are used to credit debit and refund wallets and can either be created manually or triggered via other processes
- Money can be transferred between wallets of different owners.
- Wallet are always related to accounts receivable where wallet money can flow from and to. It's through the accounts receivable that the wallet is related to various other entities in the system such as subscriptions and rewards. It is up to you whether the balance in the account and the wallet of the customer should agree
Setting Up Wallets
Wallet Transaction Types
A Wallet Transaction Type is used to define the nature of each wallet transaction which is based on the classification of the type. There are five predefined system transaction classifications:
- Wallet Credit: A transaction that funds the wallet.
- Wallet Debit: A transaction that deducts funds from the wallet.
- Wallet Reimburse: A transaction that deducts funds from the wallet and credit the wallet's owner Accounts Receivable.
- Wallet Void: A transaction that cancels or reverses any type of wallet transaction (credit, debit, reimburse) by voiding it.
- Wallet Transfer: 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.
Multiple wallet transaction types can be created for every classification. However one of them (for every classification) must be set as default. Use the Set as Deafult action available from the Data entry page Actions Menu to set the type as default and remove any other type of the same classification from being the default one.
Once transaction types are created they are then used in the wallet definition where you can define what type of wallet transaction is to be created by the system on the execution of specific events.
Business definitions
Wallets definitions are business rules which are used to control the behaviour of wallets throughout their life cycle. There can only be one active definition at a time.
Definition fields
This table contains an explanation of the sections of the wallet definition Data Entry page, a description of the usage of its fields and additional information.
Mandatory Configurable
Wallet Causes Define the events/causes that will trigger automation on various wallet functions such as creation, cancellation and debiting. In some cases you must also define the wallet transaction type for the transactions that may have to be created. | |
---|---|
Create Wallets | By default wallets are created automatically when:
You have the option to define whether a wallet should also be created automatically when an accounts receivable is created. |
Cancel Wallets | By default wallets are cancelled automatically when:
You have the option to define whether a wallet should be cancelled when the relation between the prepaid subscription or rewards participant and the wallet no longer exists. This happens when the prepaid subscription is terminated or the accounts receivable handling the subscription financials is changed or when the rewards participant is terminated. |
Debit Wallets | By default wallets are debited automatically when :
For each case you can define the a transaction type for the debit wallet transactions to be created, other than the default one which is automatically set. |
Credit Wallets | By default wallets are credited automatically when:
For each case you can define the a transaction type for the credit wallet transactions to be created, other than the default one which is automatically set. |
Reimburse Wallets | Amount available in wallets which are to be cancelled can be reimbursed to the accounts receivable related to the wallet, so that the money is not lost You can select whether you would like to enable reimbursing and on which occasions:
For each case you can define the a transaction type for the reimburse wallet transactions to be created, other than the default one which is automatically set. |
Void Wallet Transactions | By default wallet transactions are voided when:
For each case you can define the a transaction type for the void wallet transactions to be created, other than the default one which is automatically set. |
Wallet Rules Define rules related to various wallet functions that will dictate how the system should behave on the execution of certain events, such as crediting and reimbursing the wallet. | |
Balance Threshold Rules - | Define the minimum wallet balance threshold which is the minimum value the system accepts for the wallet balance. If the balance drops below the threshold, then the system blocks transactions that result in a debit (creation of debit, reimburse, transfer transactions or voiding of credit transactions). |
Crediting Rules | A set of rules applied while crediting a wallet that aim to keep the wallet and related accounts receivable in balance Debit the related Accounts Receivable: An invoice (financial transaction) is posted against the accounts receivable, using the invoice type and product attributes (Applicable for all credit type wallet transactions or for specific types as specified in the Conditions). |
Reimbursing Rules | A set of rules applied while reimbursing a wallet that aim to keep the wallet and related accounts receivable in balance
|
Voiding Rules | A set of rules applied while voiding a wallet transaction that aim to keep the wallet and related accounts receivable in balance
|
Auto Top Up Rules Defines a set of rules which are applied while automatically topping up a wallet. | |
For each top up rule you can define the following parameters:
| |
Applicable Classification | Define the classifications that an accounts receivable should have, for the top up rule to be applied. You have the option to apply the rules on all classifications or specific classifications . Each classification can be added in only one rule. |
Wallet balance periods
Wallet Balance Periods represent the periods of time during which the balance of each wallet was calculated. As a result, the opening balance of each wallet is calculated based on the wallet transactions which were generated within that period's time frame plus the balance brought forward from previous periods. Periods can be either 'Open' or 'Closed'. However, only one period can be 'Open' at a time and it will always be the latest one. Each period's duration is Monthly.
The first period is automatically created by the system. The following periods are created once the current period is closed (via Closing Period process). Once a period is closed it cannot be reopened and no more wallet transactions can be posted against it, as wallet transactions can only be posted against 'Open' periods and can only be related to a single period.
To close a period through the Data Entry page click on 'Actions > Calculate Wallet Balance per Period' available through the Actions Menu. To view a list of errors that may identified while calculating the period and therefore not processed click on 'Actions > View Wallet Balance per Period Errors' from the Actions Menu.
Wallet Balance period fields
This table contains an explanation of the sections of the wallet balance period Data Entry page, a description of the usage of its fields and additional information.
Mandatory Configurable
Main Information | |
---|---|
Number: The period's number which is consisted by the period's month and year, e.g. 201701 for January 2017. Name: The period's name which is consisted by the period's month and year, e.g. January 2017. Life Cycle State: The period's life cycle state which can be 'Open' or 'Closed'. Multiple closed periods can exist but at any point of time, one and only one of them can be in an 'Open' life cycle state. From Date: The first day of the period's month. To Date: The last day of the period's month. Closed Date: The date when the period was closed. This is available once a Period Calculation process is completed which is also the only process which modifies this information. Closed by Wallet Balance Period: The period which follows this period. This information is available only as long as this period is 'Closed'. Period Closing Performed by User: The user who initiated the Period Closing process. This information is available only when the period is 'Closed'. | |
Wallet Balance Period Totals | The Period's totals as calculated during the 'period closing' process. This information includes the following:
|
Period Wallet Transactions | |
The wallet transactions of any type that were submitted against the period. |
Related configuration areas
The following modules are related to Wallets and may be configured for the Wallets module to operate at its full capacity.
Module Link | Area | Description |
---|---|---|
Financial Transactions | Financial Transaction Types | The financial transaction types will be used in the wallet definitions to define the transaction types to be created on certain wallet events or that will be used as conditions to triggering certain events. |
Payment Gateways | Payment Run Definitions | Payment runs are used to automatically top up wallets of customers that are paying with credit cards and their wallet balance falls below a defined threshold |
Using Wallets and Wallet Transactions
Finance > Wallets > Manage Wallets
Wallet fields
This table contains an explanation of the sections of the Wallets Data Entry page, a description of the usage of its fields and additional information.
Mandatory Configurable
Main Information | |
---|---|
Accounts Receivable: The accounts receivable which is related with the wallet and which can be kept in balance with. In the case that the wallet is cancelled and there is money in the wallet, then the account will be reimbursed with that money. Life Cycle State: The life cycle state of the wallet which shows whether its operational. It can be 'Effective' or 'Cancelled'. | |
Balance information | Balance: This is the balance of the account as of today. Note that a part of the amount may only be available in the future which can be seen from the 'Allotments' drill-down available in the 'Wallet Transactions' tab 30-days Expiring Amount: The total amount that expires in the next 30 days Unconditional Balance:The total amount, that depends on conditions which can be found in the 'Allotments' drill-down available in the 'Wallet Transactions' tab Conditional Balance: The total amount, that has no conditions |
Wallet Transaction Information | Latest Auto Top Up Date: The latest date that an automatic top up was applied on the wallet. Latest Debit: The latest date that the wallet was debited with a debit wallet transaction Latest Credit: The latest date that the wallet was credited with a credit wallet transaction Last 12-months Awarded Amount: Amount that was awarded in the last 12 months, which is only applicable if the wallet owner participates in a Reward program Last 12-months Spent Amount: Amount that was redeemed in the last 12 months, which is only applicable if the wallet owner participates in a Reward program Last 12-months Subscription Spent Amount: Amount that was spent in the last 12 months on subscriptions, which is only applicable if the wallet owner is a subscriber |
Wallet Balance Period Information | Wallet Balance Period: The period which is considered the current running period and for which the balance is calculate Total Period Debits: The sum of all debit wallet transactions created for the current period Total Period Credits: The sum of all credit wallet transactions created for the current period Opening Balance: The balance carried from the previous period Opening Balance Calculation Date: The date which the current period started |
Wallet Consumption | |
Estimated Consumption | Estimated Consumption Days: An estimate of the number of days until the total Wallet Balance will run out. Estimated Consumption Date: An estimate of the date on which the Wallet Balance will run out. |
Product Consumption | Information related to the consumption of the Wallet Balance of each of the products related to the Wallet: Estimated Days Left To Consume Full Amount: An estimate on the number of days left until the total Wallet amount allotted for the specified product is consumed. Estimated Date Of Full Amount Consumption: An estimate of the date by which the Wallet amount allotted for the specified product will be consumed. Latest Date Of Estimation: The date that the last estimate was performed. |
Balance Breakdown | |
Search Criteria / Conditions: A list of search criteria is available which represent the conditions set on the available balance. Either search without conditions to see the breakdown of the total balance or define a condition to only find the amount available to be spent based on those conditions. Available search conditions are Merchant, Products, Days,Time which are what is set on wallet transaction allotments, usually coming from the spend conditions set on reward offers. Amount Based on conditions: The total amount which can only be spent if the conditions on the amount are met The result of the search is a breakdown on the balance based on the conditions | |
Wallet Transactions | |
All the wallet transactions which have been created for the wallet with information on the date from which the amount is available and the conditions (Allotments) that define how the money can be spent (for credit wallet transactions) | |
Beneficiaries | |
Subscription | The prepaid subscription which are paid through the specific wallet |
Rewards Participant | The rewards participant whose awards are handled through the specific wallet. |
Log Information | |
Provides details related to the process that created or cancelled the wallet, according to the current life cycle state. For example:
|
Wallet transaction fields
There are multiple types of wallet transactions, (debit, credit, void, reimburse) and each one has different areas available according to its type
This table contains an explanation of the sections of the Wallet Transactions Data Entry page, a description of the usage of its fields and additional information.
Mandatory Configurable
Main Information | Which type of wallet transaction is the field available? | |
---|---|---|
Type | The Wallet Transaction Type, which determines the nature of each transaction depending on its classification. The supported Wallet Transaction Type classifications are the following:
| All |
Wallet | The wallet for which the transaction is created for | All |
To Wallet | The wallet to which money will be transferred. | Transfer wallet transactions |
Amount | The total amount of the wallet transaction. | All |
Extra Added Amount | A bonus amount that will affect the wallet balance on crediting the wallet, but will not be taken into consideration during processes such as reimbursing the wallet or invoicing the related accounts receivable. | Credit wallet transactions |
Voided by | When transactions must be cancelled so that their amount does not affect the wallet balance they are voided. Wallet transaction that can be voided are debit, credit or reimburse. | Transactions that are voided |
Life Cycle State | A transaction with an 'Effective' life cycle state is taken into consideration when calculating the balance of the wallet. Any transaction with a 'Voided' state is ignored. | All |
Expiration Date | The date on which the money added in the wallet will expire. The date is used by 'Wallet Balance Expiration Runs' to debit the wallet with unspent wallet Amounts that are past their expiration date. | Credit and transfer wallet transactions |
Allotments | Credit and debit wallet transactions. | |
A wallet transaction allotment is used to identify restrictions on how the funds available in the wallet, generated by credit transactions, can be consumed. The consist of the following fields:
| ||
Products | ||
Wallet products are used to track the products that the wallet was credited or debited as part of a wallet transaction. Multiple products can be specified on each Wallet Transaction. | Debit and Credit Wallet transactions | |
Log Information | ||
Provides information related to the process that created the transaction. | All |
Creating and processing wallets
Actions are subject to validations which take place before an action is initiated (prerequisite) or after it is submitted (postcondition).
Selecting and creating a wallet
Wallets can be created manually or automatically.
To manually create a wallet navigate to Wallets and specify the criteria that match the wallets you are interested in, or click on NEW from the Actions Menu in the Summary page. You only need to define the accounts receivable of the customer that the wallet is created for before you click on SAVE and create the wallet.
Wallets are created automatically as configured in the 'Wallet Definition' when the following events occur in the system
- On creating a new accounts receivable
- On adding an accounts receivable that is not already related to a wallet on a prepaid subscription
- On adding an accounts receivable that is not already related to a wallet on a rewards participants
Postconditions | Only one wallet with an 'Effective' life cycle state can be related to an accounts receivable at a time. |
---|
Modifying a wallet
Unlike other modules, Data Entry pages, information available in the Wallets Data Entry page is mostly informational, apart from the accounts receivable which can be set only when creating the wallet. The rest of the information, cannot be manually set and it's automatically updated when various events occur in the system. For example, when the Prepaid billing Run is executed the balance information, transaction information and balance breakdown is updated accordingly. In the same way, when awards or spends are done for a rewards participant, information in the wallet is updated accordingly.
Cancelling a wallet
Instead of deleting a wallet you can cancel it so that important information kept on the wallet are readily available. You can cancel a wallet either manually or automatically.
To manually cancel a wallet while in the Data Entry page click on Actions > Cancel from the Actions Menu.
Wallets are cancelled automatically when the following events occur in the system
- The related accounts receivable is terminated
- When the related accounts receivable is changed on the prepaid subscription
- When the prepaid subscription related to the accounts receivable is terminated
- When the Rewards Participant related to the accounts receivable is terminated
Funding a wallet
Funds available in the wallet are available for spending by the wallet owner. There are many ways by which a wallet is funded and it all depends on your line of business which methods will be followed.
Manual credit wallet transaction
Wallet funds can be increased by creating credit wallet transactions.
Credit wallet transactions can be created at the Wallet Transaction Data Entry page by selecting NEW or by selecting Actions > Credit Wallet Transaction from the Actions Menu of the Wallet Data Entry page.
'Top Up' wallet
Funds from a wallet are deducted usually when a prepaid subscription is billed or when rewards participants redeem their awards. A functionality is available which detects whether the wallet balance has fallen beneath a certain threshold, in which case the system automatically tops up the wallet from a subscriber's online account, which it can either be through a credit card or Paypal. This is particularly useful to avoid the interruption of a subscription service with a recurring fee, which requires automatic payments.
In order to be able to use the Top up functionality the Top Up rules in the Wallet Definition must be set up and the payment gateway run which is responsible for conducting the payments.
Payments and Credit Note
When posting a Payment or a Credit Note (Financial Transactions) to the related accounts receivable the system can be configured to automatically add the amount of money paid to the account, to the wallet. For example, lets say that subscribers to a prepaid model can buy vouchers with which they can pay for their prepaid subscription. When the subscriber pays with the voucher, a payment will be made to the accounts receivable, equal to the voucher amount. The system will then automatically credit the wallet with the same amount of money so the subscriber can start paying for his subscription through the wallet. In the same way if a credit note is created at the accounts receivable, the wallet can be credited so that the money can be used to fund processes through the wallet
Executing prepaid billing run
Prepaid billing run is responsible for billing prepaid subscriptions for the services a customer is subscribed to. In the case that a service has already been paid and for some reason removed before using all the days it was paid for, the billing run will credit the wallet for the unused amount and the funds can again be used by the subscriber on something else.
On award transactions
Rewards participants gain awards through reward offers which they can then spend to buy services or products. As awards are handled through the participant's wallet, when an award is gained then the wallet will be credited and therefore funds increased. Many times awards come with conditions / restrictions how the awarded money can be spent. These conditions are carried over in the wallet funds and therefore the owner is only allowed to spend the available funds as dictated by the conditions. For example, if you receive an award or €20 that can only be spent on Mondays and the current day is Tuesday then even though that you will have the money available in the wallet for spending, you will not be allowed to use that amount today.
Note that award transactions in most the cases they are created through the creation of customer events which in turn trigger the awards.
Cancellation of spend transactions (Voiding)
Rewards participants can redeem the awards gained. Awards and spends (redemption) are handled through the participant's wallets. When a spend is done (i.e. redeeming of awards) money is deducted from the particiapnt's wallet; if for any reason the spend is cancelled, for example the participant returns the product bought with the award money, then the money will be placed back to the wallet.
This is achieved by voiding the debit wallet transaction responsible for deducting money from the wallet.
Cancellation of expiration transactions (Voiding)
Funds available in the wallet may have an expiration date. This is particularly common when funds are earned through awards. For example, when you participate in a rewards program, the awards you earn will not last forever but will most probably expire by the end of the month or year. Expiration transactions are the ones created to deduct money from the wallet equal to the amount that has expired and which in turn debit the wallet. If for some reason the award was mistakenly expired then the funds are added back to the wallet by cancelling the expiration transaction.
This is achieved by voiding the debit wallet transaction responsible for deducting money from the wallet.
Spending or deducting money from the wallet
Funds in the wallet are used by two primary processes within CRM.COM. Pay for prepaid subscriptions and redeem awards gained from reward participation.
In some occasions money used to fund the wallet they have an expiration date. This means, that even if not spent by the customer, the money can not be used once expired and therefore they are deducted from the wallet's available funds.
Manual debit wallet transactions
Wallet funds can be deducted from the wallet by creating debit wallet transactions.
Debit wallet transactions can be created at the Wallet Transaction Data Entry page by selecting NEW or by selecting Actions > Debit Wallet Transaction from the Actions Menu of the Wallet Data Entry page.
Executing Prepaid Billing run
Prepaid billing run is responsible for billing prepaid subscriptions for the services a customer is subscribed to. When executed services will be billed and money will be directly deducted from the subscriber's wallet to pay for the billed services. The wallet is debited by using debit wallet transactions.
Cancelling a payment (Voiding)
When a payment (financial transaction) which was used to add money to the wallet is cancelled then the related money must also be removed from the wallet so that the customer can no longer spend them. This is achieved by voiding the credit wallet transaction that was used to add the money to the wallet
Cancellation of award reward transactions (Voiding)
Rewards participants can be awarded when participating in a rewards program. The awards gained, are available in their wallets and can be redeemed. If for some reason, the award is cancelled, for example the participant returned the products that gained him the awards, then the wallet money must also be deducted. This is achieved by voiding the credit wallet transaction responsible for funding the wallet.
Creation of spend reward transactions
As aforementioned, rewards participants can redeem the awards gained. Awards add money to the wallet, while spends (redemption) deducts money from the wallet. When a participant makes a purchase using the money that was awarded to her the system will debit the wallet accordingly. The system creates debit wallet transaction which is equal to the spend reward transaction used to redeem the points.
Note that spend transactions are created through the creation of 'spend customer events' which in turn trigger the spend reward transaction.
Wallet expiration run
Funds available in the wallet may have an expiration date. This is particularly common when funds are earned through awards. For example, when you participate in a rewards program, the awards you earn will not last forever but will most probably expire by the end of the month or year. When funds expire, the system creates award expiration transactions which in turn trigger the creation of debit wallet transactions which debit the wallet with the same amount as the expired amount.
Reimbursing a wallet
Reimbursing process makes sure that wallet owner's money will not be lost in case that her wallet is no longer operational, by placing the money in her accounts receivable. The system has the ability to handle reimbursement automatically in two cases that it is required. You have the option to define the maximum amount of money allowed to be reimbursed every time reimbursement is triggered through the wallets definition
Cancelling Wallets
When a wallet is cancelled the money a wallet reimburse transaction is created and deducts the money form the wallet for the total balance (provided it is positive) including any extra added amounts and adds that amount to the customer's wallet
On changing a prepaid subs A/c
When the accounts receivable which is related with a wallet is changed from a prepaid subscription, for example when the subscription's owner is changed, then the related wallet's money are deducted ( the total balance, provided it is positive, including any extra added amounts ) from the wallet by creating a reimburse wallet transaction and added to the accounts receivable
Manual reimbursing
You have the option not to enable automatic reimbursing and handle reimbursement manually so you can have more control.To manually reimburse an amount you can create a NEW reimbursement transaction through the Wallet Transaction Summary page or by using the Actions > Reimburse Wallet Transaction from the Actions menu in the Data Entry page of the Wallet you wish to reimburse.
Voiding a wallet transaction
Voiding a wallet transaction cancels the transaction reverting the financial impact the transaction has on the wallet. For example if you void a transaction that added money to the wallet, that money will now be removed, and if you void a transaction that deducted money from the wallet, then money will now be added back.
Voiding can be done for 'Credit', 'Debit', 'Reimburse' and 'Transfer' wallet transactions. In most cases it is done automatically by the system, resulting to either funding or removing funds from the wallet, as configured in the wallet definitions.
You can, however, manually void a wallet transaction from the transaction's Data Entry page. From the Actions Menu click on Actions > Void and then click on SAVE on the modal window
The voided transactions remain visible and are always related to the void wallet transaction.
Transferring money between wallets
Wallet funds can be easily transferred from one wallet to another by creating a NEW transfer wallet transaction from wallet transactions summary page or by Actions > Transfer Wallet Transaction available in the Data Entry page of the wallet you wish to transfer money from.
When a transfer transaction. The system creates three transactions. A wallet transfer, a debit wallet transaction which will debit the source wallet (the wallet FROM which money will be transferred) and a credit wallet transaction to credit the target wallet (the wallet TO which money will be transferred).
Preconditions | Both Wallets are 'Effective' There is enough money in the Wallet |
---|
Handling wallet money allotment
As previously explained, wallets are primariy used in 2 major areas in the system. For handling the financials of a prepaid subscription or of a rewards participant. In both areas funds in the wallet may be conditional, that is, reserved for the purchase of certain products, or on certain dates or through certain merchants. In CRM.COM this is achieved through wallet transaction allotments which is the reservation of funds of a Wallet Transaction for use on specific products.
In the system allotments can be seen through Allotments section in credit and debit wallet transactions, available in the Wallet and Wallet Transaction Data Entry pages and through the Wallet Balance Breakdown section available in the Wallet Data Entry page.
- In credit wallet transactions, allotments designate the conditions FOR which the transaction money should be allocated.
- In debit wallet transactions, allotments designate the conditions TO which the transaction money was allocated.
Allotment can take place either manually or automatically. The system will (automatically) set the wallet transaction allotments in the following cases:
- Voucher Usage: When vouchers are used as a payment method for prepaid subscriptions , if the voucher is designated for specific products then a wallet credit transaction is created for the amount of the voucher and a allotment is added for each voucher specific product.
- Prepaid Billing Run Execution : When a prepaid billing run is performed and the wallet amount is consumed by specific products then a debit Wallet transaction is created for the consumed amount and an allotment for that product and its amount consumed is added on the Wallet Transaction.
- Award Reward Transaction Generation : When an award transaction is provided to a rewards participant, which can be consumed only by specific products, on a specific day of the week and by a specific merchant is submitted then a wallet credit transaction is created for the amount of the award and allotments are created for that same amount.
All spend conditions defined in the reward offer, that granted the award are added in the wallet allotment conditions.
Applying business flows on wallets
Expiring wallet balance
Funds available in a wallet may be expiring at some point. This is particularly popular feature in the case when funds have been earned through awards from reward offers, however, funds that are manually added to the wallet through credit wallet transactions can be created with an expiration date set. The amount of money that has expired is deducted from the wallet therefore the funds available to be spent are less by the amount that has been expired.
In order to achieve this, an expiration process is available in the system which can be set once and automatically executed to identify unspent wallet amount that should be expired based on the already specified 'Expiration Date', and debit the wallet for that amount.
If the expired amount is related to funds earned through awards, as opposed to manual credits with expiration date, then an Awards Expiration Transaction will be created which will in turn debit the wallet
It is recommended that Wallet Balance Expiration Runs are configured to be executed on a daily basis.
Wallet Balance Expiration Runs Fields
Criteria Define the criteria that will be used to identify the amount that will be expired. | |
---|---|
Wallet Allotments Expired X Days Ago | Determines the Wallet Allotment Expiration Date in relation to the date of execution, measured in days. The process will retrieve wallet allotments having an expiration date which is equal to or before the execution date minus the specified number of days. If nothing is defined then '0' is assumed, so the process will retrieve wallet allotments having an 'Expiration Date' which is equal to or before the date of execution. |
Setting up the expiration process
Finance > Wallets > Perform Wallet Balance Expiration Runs
Access the definition and create a NEW definition by providing the required information. Once all the information is provided and the definition saved, click on SUBMIT to send the job to the scheduler to be executed or schedule for a later time. Given that you have set the 'Scheduling Settings' in the definition to be executed repeatedly then once the job is executed a new one will be scheduled for the frequency set in the settings.
Viewing future wallet balance
Funds available in the wallet today may differ to the same funds (i.e. with no additional crediting or debiting taking place) in the future, and this is due to amounts that will be made available in the future, i.e they have a future 'Validity Date'. This is usually the case when funds are earned through awards from reward offers that have s future validity date set on their spend conditions, or can even be done manually when setting a 'Validity Date' in the 'Allotments' of a credit wallet transaction.
The balance available in the wallet data entry page takes into consideration the validity date. If you would like to check how much money will be available in the future, i.e. when the validity date of some of the locked funds is passed, then use Actions > View Future Balance from the Actions menu of the Wallets's Data Entry page and provide the date.
Communicating wallet information
Wallets information can be communicated by using the Communicate Wallets action available through the Actions Menu.
You can use wallets related communication tags (text that is automatically replaced by values specific to selected records) when creating communications for wallets. Tags are available for selection by typing '#'.
Refer to Communications manual for a complete list of Wallets tags.
Notifying wallet amount
As wallets are used to either pay for prepaid subscriptions or reward offers awards and spends, there are many occasions where you would like to communicate with your customers, informing them that the funds in the wallet are running out or that there are awards about to be expired, as part of your customer relationship management. CRM.COM gives you the option to set up automatic batch processes that can identify and communicate with wallet owners informing them accordingly. For more information view Notifications.
Wallets Analytics
Segmenting wallets
You can group wallets with common business characteristics. Use the lists in system business processes for identification of customers or for simple statistical calculations.
For more information on Segmentation and how you can create Wallets lists refer to Segmentation.
Printouts
A wallet balance printout displays the transaction which took place in the current year, the year's balance to-date and the balance carried over from the previous year. It is available through the Wallets Data Entry page in one of the following formats: HTML, XLS, CSV, RTF, PDF.
Refer to Printouts for information on how they can be created, printed and sent.
Wallets Business Examples
Scenario 1.
Company ZX offers Prepaid Subscriptions to its customers.
- In Prepaid Subscriptions, customers pay upfront for the services they chose to use
- The credited amount can be allotted to specific products on their Subscription
- When the customer's balance is insufficient to cover all the chosen services they are deactivated
- Customers can call to inquire on how much money is left in their Wallet and when their subscription will be disconnected
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
Solution
Customers with Prepaid Subscriptions have both an accounts receivable and a wallet. The wallet has the funds that the customer has paid upfront for use on their subscription. Once the prepaid billing run is executed the following information is available in the wallet:
Current Date: 01.06
Wallet
- Estimated Consumption Days:183 days
- Estimated Consumption Date: 01.12
- Estimated Consumption As of Date: 01.06
- Balance: €300
Per Product
- Sports HD
- Estimated Consumption Days: 183 days
- Estimated Consumption Date: 01.12
- Estimated Consumption As of Date: 01.06
- Kids HD
- Estimated Consumption Days: 183 days
- Estimated Consumption Date: 01.12
- Estimated Consumption As of Date: 01.06
Next Day: 02.06
Wallet
- Estimated Consumption Days:182 days
- Estimated Consumption Date: 01.12
- Estimated Consumption As of Date: 02.06
- Balance: €298.33
Per Product
- Sports HD
- Estimated Consumption Days: 182 days
- Estimated Consumption Date: 01.12
- Estimated Consumption As of Date: 02.06
- Kids HD
- Estimated Consumption Days: 182 days
- Estimated Consumption Date: 01.12
- Estimated Consumption As of Date: 02.06
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.
- Green and Pink Cells indicate Credit and Debit Transactions respectively.
- Some Credit Transactions have an Expiration or Consumption Validity Date. Some have both or none.
- Two Allotment Condition Groups are available indicating that allocation occurs within each Group.
Table 1 - Wallet Transactions Table
Order of creation | Created Date | Number | Wallet Transaction Type | Amount | Allotment Condition Group | Consumption Validity Date | Expiration Date |
---|---|---|---|---|---|---|---|
1 | 01/10/2017 | WT0001 | Credit | €10 | Group 1 | N/A | N/A |
2 | 01/10/2017 | WT0002 | Credit | €10 | Group 1 | N/A | 01/11/2017 |
3 | 02/10/2017 | WT0003 | Credit | €10 | Group 1 | N/A | 15/10/2017 |
4 | 02/10/2017 | WT0004 | Credit | €10 | Group 1 | 05/10/2017 | 10/10/2017 |
5 | 02/10/2017 | WT0005 | Credit | €10 | Group 2 | N/A | 09/10/2017 |
6 | 03/10/2017 | WT0006 | Debit | €-8 | Group 1 | N/A | N/A |
7 | 05/10/2017 | WT0007 | Debit | €-15 | Group 1 | N/A | N/A |
8 | 05/10/2017 | WT0008 | Debit | €-10 | Group 2 | N/A | N/A |
9 | 06/10/2017 | WT0009 | Credit | €10 | Group 1 | N/A | 20/10/2017 |
10 | 07/10/2017 | WT0010 | Debit | €-15 | Group 1 | N/A | N/A |
11 | 08/10/2017 | WT0011 | Credit | €10 | Group 1 | N/A | N/A |
12 | 09/10/2017 | WT0012 | Debit | €-12 | Group 1 | N/A | N/A |
13 | 10/10/2017 | WT0013 | Debit | €-10 | Group 1 | N/A | N/A |
Table 2 - Allocations Table
Table 2 shows the allocation and the order in which it occurs in the System, taking into consideration the:
- Allotment Condition Group
- The Credit Transactions that belong to the same Allotment Condition Group as the Debit Transaction and are not fully allocated.
- Expiration Date & Created Date
- Credit Transactions with the earliest Expiration and Created Date are sorted by Expiration and Created Date from earliest to latest (if no Expiration Date exists then the sorting is done based on the Created Date only).
- Consumption Validity Date
- Credit Transactions whose Consumption Validity Date is before the current date.
Order of Allocation | Credit Allotment | Debit Allotment | Allocated Amount | Allocation Date | Unallocated Amount |
---|---|---|---|---|---|
1 | WT0003 | WT0006 | €8 | 03/10/2017 | €2 |
2 | WT0004 | WT0007 | €10 | 05/10/2017 | €0 |
3 | WT0003 | WT0007 | €2 | 05/10/2017 | €0 |
4 | WT0002 | WT0007 | €3 | 05/10/2017 | €7 |
5 | WT0005 | WT0008 | €10 | 05/10/2017 | €0 |
6 | WT0009 | WT0010 | €10 | 07/10/2017 | €0 |
7 | WT0002 | WT0010 | €5 | 07/10/2017 | €2 |
8 | WT0002 | WT0012 | €2 | 09/10/2017 | €0 |
9 | WT0001 | WT0012 | €10 | 09/10/2017 | €0 |
10 | WT0011 | WT0013 | €10 | 10/10/2017 | €0 |
Notes
- If you are using a previous release, view CRM.COM Release Changes.
- Use the Wallets WEB API to create and manage Wallets from an external system, such as a customer portal. View the Wallets WEB API and Wallet Transactions WEB API for a complete list of actions available through the WEB API.
Glossary
CRM.COM Term | Definition |
---|---|
Prepaid Subscription | A collection of customer services billed and paid in advance. |
Accounts Receivable | An accounts receivable is a ledger of the financial transactions carried out between a company and its customers, such as invoices and payments. It keeps a running balance of debits and credits and displays the amount a company is owed in exchange for goods supplied and services rendered. |
Customer Events | Customer Events are financial and marketing events performed by customers and are registered within CRM.COM to be rewarded or additionally processed by other functions of CRM.COM |
Award Transactions | Award Transactions are used to award a Rewards Participant, for a specific amount of money that was provided by a Reward Offer, and credit the Rewards Participants Wallet for that specific amount. |
Spend Transactions | Spend Transactions are used to spend a specific amount of money, that was awarded by a Reward Offer, and debit the Rewards Participants Wallet for that specific amount. |
Expiration Transactions | Expiration Transactions are used to expire an awarded amount given to a Rewards Participant by debiting the Rewards Participant's Wallet. Award Expiration Transactions are generated because the Rewards Participant's awarded amount expires due to Reward Award Offer Validity period. |
Rewards Participants | The customers who have signed up for rewards or have been automatically selected to participate |
Merchants | Rewards Participating Merchants are merchants that have a partnership with the business that owns the reward platform and can participate in the provided reward Schemes. |