Files

SonPhung 4534e4ecb8 feat: initialize project backend structure and document system specifications across all modules

2026-07-24 09:05:41 +07:00

166 KiB

Raw Blame History

title, type, status

title	type	status
Reward Campaign Management	OpenSpec	Draft

Reward Campaign Management

Highlights

Business rules controlling reward and redeem transactions are set up as Rules in “Campaigns”.
Customers enjoy different reward types depending on the type of card they hold and the details of the transactions.
In BLP, a single customer view is maintained such that all of a customer’s product holdings and the corresponding loyalty rewards are linked into a single customer view. This is illustrated in the following:

Customer

Account # 1

Account # 2

Account # 3

Smart$

Cash Rebates

UNIRM

Product Holdings

Reward Pools PoolsBalances

Account # 4

Reward Balance for each reward type is tracked at customer level in “Pools” – one Pool per reward type – e.g. Smart$ is a reward type, UNIRM is a reward type

Loyalty Account Acct

Figure 9 – Customer View

A merchant acquired by payment card acquiring may participate in one or more reward campaigns and contribute at different rates to different reward campaigns.
1. Transactions from EDC terminals of acquired merchants can earn rewards entitlements in real-time depending on the reward campaigns in force.
2. In the same transaction, cash rebates and points earned on past transactions can be used to offset the payment amount in real-time, thus reducing amount charged to card, so customer can earn and redeem in the same payment transaction (either in full or in part as “partial redemptions”) and enjoy a smaller amount charged to card.
Transactions from not-acquired merchants and from merchants who are acquired but not participating are received from Card System and can be processed for rewards in the form of cash rebates and points in OneLoyalty™ through batch files.
Rewards for a single transaction may be from multiple “contributors”, entities who fund the rewards.
A single transaction can trigger multiple concurrent award programs.
Groups of outlets can operate their own outlet-specific Campaign Rules with different rules and periods per Campaign Rule.
Many short-term, event-specific Campaign Rules can be set up and operated cost effectively with a short time to market with the flexibility of the rewards management module.
Points and e-coupons earning and/or redemption can be integrated into the same POS terminal payment transaction or effected through batch processes based on transaction inputs from external application systems.
Reward campaigns can be set up with multi-merchant support, including merchant-specific Campaign Rules, as an incentive for merchants to participate.
1. Rewards can be in various forms and have flexible point and e-coupon expiry policies:
2. E-coupons (as cash, discount or gift coupons; e.g. a $5 coupon, a 10% discount coupon, a coupon for free access to events, etc.)
3. Points redeemed for cash-back as part of payments, or for offsetting service fees, points transfer to external point programs, etc.
4. Lucky Draw chances for deferred electronic lucky draws that may be conducted periodically
5. Instant discounts (specific to SKU codes i.e. purchased item codes).
Point and e-coupon redemption against electronic catalogue are supported through the Internet, IVR, SMS as well as trough call center agents.
Seamless integration between magnetic- and chip-card-based loyalty functions allow transfer of points, coupons & other benefits between card and host (both ways).
Rewards and incentives (e.g. cash rebates and points) given to customer can be based on criteria such as types of products used, transactions performed, and the value and frequency of transactions, etc.
Practically unlimited number of reward campaign rules can be run concurrently.
Campaign Rule Criteria, i.e. the conditions under which to give rewards, can be defined based on customer and transaction data available, such as:
1. Demographic attributes: Age group, Gender, etc.
2. Date / time of transaction: specific date/time ranges, time period (happy hour), day of week
3. Location of transaction
4. Instant transaction amount
5. Cumulative transaction amount (by user selectable criteria – e.g. at particular merchants, or for spend in particular merchant categories, etc., or user-specified time periods)
6. Transaction count (number of transactions in a period
7. Average balance over a specified period, period-end balance over a specified period
8. Card type (product account type)
9. Customer’s product holdings (e.g. customer with product account types 1 and 2 gets this reward, customer without the products receives this message, etc)
10. User-defined attributes associated with customer and / or product accounts, etc.
Rewards can be tracked at
1. Customer level: single reward balance for customer
2. Product level: rewards tracked as a separate balance per Product Account.
Customer can redeem their incentives and rewards through any of the following:


* 1. EDC terminals at partner outlets	* 1. Call center
* 1. Website, through electronic catalogue	* 1. Interactive Voice Response System (IVRS).

Structure of a Campaign (HAVE TO BE ADJUSTED)

Types of Campaign Mechanics

Reward campaigns can be broadly divided into two types or models:
1. Those that award on every transaction (“Award on Every Transaction”) and
2. Those that award on the basis of the total spend or total number of transactions performed in a given period (“Award on Cumulative Criteria”), i.e. where the total achieved determines the earning rate or reward
Designing a Campaign for set-up in BLP is best done if the generic structure for each of these models is understood: these structures are discussed in the next 2 sections.

Award on Every Transaction

In an “Award on Every Transaction” campaign, the process flow is outlined in the following:
1. The reward is determined at the time the transaction is processed in BLP.
2. Processing can be in either real-time or in batch mode, and the structure is illustrated in the following:

[Image Removed]

Figure 10 – Process Flow for Award Per Transaction

Transaction data is received from external sources (e.g. Card System) or can be internally generated in BLP through the CEP (see section 1.1.1) and REP (see section 4.17) modules
1. Transaction data may be received in batch mode through the batch transaction interface file (BLPTXN) described in Reference R01.
2. Transaction data may also be received through online interfaces such as the POS Manager interface to payment terminals and MQ interfaces to front-end systems
Campaign Rules are set up as described in the rest of this section 4.
Campaign Rules derive the quantity to award and/or redeem from the Reward Pool, the structure of which is described in section 4.2.5.

Accumulate Then Award

In an “Accumulate then Award” campaign, the reward depends on the customer’s total spend or number of transactions performed over a period P of – e.g.
1. If the customer spends between $500 and $1,000 in the month in total to earn a 15% bonus, however if customer spends more than $1,000 in the month customer gets a 20% bonus.
2. In such a campaign, the award formula parameters cannot be determined until the end of the period P
  1. To achieve this, Campaign Rules are set up to accumulate the required transactions into Counters
  2. Separate Campaign Rules are also configured to extract and process the values in the Counters as transactions for the actual award at the end of the accumulation period P.
  3. The structure and mechanism of how Counters work are described in section 4.2.6.
3. The Campaign structure of such a Campaign is broadly outlined in the following:

[Image Removed]

Figure 11 – Structure of “Accumulate Then Award” Campaigns.

Again, the transaction data may be received from external sources (e.g. Card System) or can be internally generated in BLP through the CEP (see section 1.1.1) and REP (see section 4.17) modules
Campaigns to award on Cumulative basis based on internally derived transaction data are described more fully in section 1.1.1.

Auto-redemption Campaigns

Some campaigns, such as cash rebate or frequent flyer mile campaigns, require that the awarded quantities (cash rebates, frequent flyer miles or other partner points) be “redeemed” and sent to an external (destination) system – Card, deposits or partner airline, etc – in order to credit the customer’s account in the destination system.
Auto-redemption campaigns make use of the “Redeem, Extract and Process” or REP module, described further in section 4.17.

Reward Pool Structure & Bucket Deduction Sequence

Earnings (rewards) are tracked in “Pools”, each Pool for a specific type of reward.
Pools belong to “Loyalty Accounts” or LAs.
One LA is created per Customer (per unique CIF Number).
Pools are associated with the Customer’s Loyalty Account (see section Error! Reference source not found. for the data entity relationship), where each Loyalty Account can have multiple Pools, each Pool for a reward type – e.g. UNIRM Pool, SMT$ Pool, etc
Within each Pool, the earnings are tracked in Pool Buckets segregated by Expiry Date and Account Type. The earnings by an Account are tracked in that Account’s buckets in the Pool.
If the earnings fall into different expiry dates, then the earnings of each expiry date are tracked in a distinct bucket for that Account, for each Expiry Date.
The following illustrates buckets for 3 accounts A, B and C (where each row is a bucket):


UNIRM Pool	Account Type	Expiry Date	Balance
A	31-Mar-2015	100
B	31-Mar-2015	50
A	30-Jun-2015	110
B	30-Jun-2015	510
A	31-Sep-2015	140
C	No Expiry	215
TOTAL BALANCE		1,125

Account Type C earns evergreen points, whereas the other account A & B each earn points which expire on the usual 5-quarters from the quarter of earning.
When customer redeems:
1. Points are deducted in order of ascending Expiry Date (earliest expiring dates first).
2. If more than one Bucket has the same expiry date, the buckets are further sorted by a pre-configured priority sequence – i.e. buckets of lower priority Account Types will be deducted first.
3. Redemption from expired buckets is allowed with supervisor approval during item redemption through administration screen. See section Error! Reference source not found..
Note that the display in the administration screen will show the buckets as illustrated in section Error! Reference source not found..

Counters – Structure and Mechanics

A Counter is a conceptual entity that tracks a quantity over a defined period of time
For example, a Counter may track:
1. Customer’s total spend per month
  1. Use Case example: to award customers who spend more than 1,000 a month
  2. This is a Customer-level monthly spend Counter, i.e. the Entity is Customer, and this Counter is used in the Rule Criteria section to filter out eligible transactions.
2. The total points earned by an Account in the entire Campaign
  1. Use Case example: to give out not more than 1,000,000 points per Account in the Campaign [Image Removed]
  2. This is an Account-level, single-Bucket Point Counter, i.e. the Entity is Account, and this Counter is used in the Formula Header to cap the formula result.
3. The number transactions awarded at individual merchants (Store Ids) per month
  1. Use Case example: to award only the first 1,500 transactions in the month per merchant (Store id) in the Campaign
  2. This is a Store-level, monthly frequency Counter, i.e. the Entity is Store, and this Counter is used in the Rule Criteria to filter out the first 1,500 transactions.
The key data entities making up Counter are defined in the following table:


Data Entity		Description
Counter Id*	X(10)	Unique identifier for a Counter Definition record
Name*	X(30)	A text string that describes this counter; it can be used as a unique identifier for this Counter Definition.
Description	X(100)	A text string that more completely describes this Counter Definition, elaborating on what it is used for (its intended purpose) etc
Entity*	X(02)	The Entity level at which a quantity is to be tracked. Valid values are:
		* + - * CU – Customer					* + - * AC – Account			* + - * CA – Card
		* + - * ST – Store					* + - * CH – Chain			* + - * CO - Corporation
		* + - * CS – Customer-Store					* + - * CC – Customer-Chain			* + - * SY – System
Entity Counted*	X(02)	The data entity that is to be counted or tracked. Valid values are:
		* + - * GA – Gross Amount					Gross Transaction Amount
		* + - * NA – Nett Amount					Nett Transaction Amount
		* + - * PT – Points					Number of points awarded, redeemed or adjusted
		* + - * TX – Transaction					Number of transactions done
		* + - * QT – Any quantity					Any numeric quantity indicated by update Formula
First Start Date	Date	The start and end date of every Bucket Period is derived relative to the previous Bucket End Date (BED). The BED of the first Bucket is derived relative to the First Start Date (FSD) and each subsequent BED is derived relative to the previous BED. BED derivation is described in item xx, following this table. The FSD must be selected to be one of the following: * + - * A Fixed Date (FD) entered as a Counter Definition parameter * First Transaction Date (FTD), i.e. the Transaction Date of the first transaction to update the Counter. The FSD (= FD or FTD, depending on the Counter Definition set-up) is used to derive the BED as described in the following:
Period Unit*	X(02)	PU: units by which to count the time length of a period. Valid values are:
		DY	Day		* BSD = FSD * First BED = BSD + N – 1 days * BED = FSD + N(1+round down ((TD – FSD)/N)) Subsequent BED = N days + previous BED * E.g. if FSD = 10-Jan-20, TD = Txn Date, BED = (TD – FSD)/N * for various values of N are illustrated in the following:
					Txn Date			09-01-20	10-01-20		11-01-20	31-01-20
					N	TD		09-01-20	10-01-20		11-01-20	31-01-20
					1	BED		None	11-01-20		11-01-20
					2	BED		None	12-01-20		12-01-20
					5	BED		None	15-01-20		15-01-20
		QT	Quarter (Q)		* BSD = 1st day of calendar Q of FSD * First BED = end of N -1 calendar Qs from first Q * Subsequent BED = end of N Qs after previous BED
		LT	Days from Last Transaction		* BSD = First transaction date on or after FSD * First BED = N statement cycle(s) after FSD * Subsequent BED = N statement cycles after previous BED
		FD	Fixed Date		* BSD = 1 day after last statement date * First BED = N statement cycle(s) after FSD * Subsequent BED = N statement cycles after previous BED
		WK	Week		* FSD = 1 day after last statement date * First BED = N statement cycle(s) after FSD * Subsequent BED = N statement cycles after previous BED
		SA	Semi-annual		* FSD = 1 day after last statement date * First BED = N statement cycle(s) after FSD * Subsequent BED = N statement cycles after previous BED
		OD	Days from AOD		* FSD = 1 day after last statement date * First BED = N statement cycle(s) after FSD * Subsequent BED = N statement cycles after previous BED
		OA	AOD Anniversary		* FSD = 1 day after last statement date * First BED = N statement cycle(s) after FSD * Subsequent BED = N statement cycles after previous BED
		NE	No Expiry		* FSD = 1 day after last statement date * First BED = N statement cycle(s) after FSD * Subsequent BED = N statement cycles after previous BED
		MN	Month		* FSD = 1 day after last statement date * First BED = N statement cycle(s) after FSD * Subsequent BED = N statement cycles after previous BED
		AN	Annual		* FSD = 1 day after last statement date * First BED = N statement cycle(s) after FSD * Subsequent BED = N statement cycles after previous BED
		OM	Months from AOD		* FSD = 1 day after last statement date * First BED = N statement cycle(s) after FSD * Subsequent BED = N statement cycles after previous BED
		OQ	Quarters from AOD		* FSD = 1 day after last statement date * First BED = N statement cycle(s) after FSD * Subsequent BED = N statement cycles after previous BED
Period Length*	9(04)	Period Length P is the number of Period Units making up one Bucket Period
First Start Date	D(08)	The start and end date of every Bucket Period is derived relative to the previous Bucket End Date (BED). The BED of the first Bucket is derived relative to the First Start Date (FSD) and each subsequent BED is derived relative to the previous BED. BED derivation is described in item 4, following this table. The FSD can be selected to be one of the following: * + - * A Fixed Date (FD) entered as a Counter Definition parameter * First Transaction Date (FTD), the Transaction Date of the first transaction to update the Counter. The FSD is derived as described in the following:
		Period Unit		Derivation of Start Date (SD) of First Bucket
		DY		SD = FSD
		MN		SD = Start of Month of FSD
		QT		SD = Start of calendar Quarter of FSD
		YR		SD = start of calendar Year FSD
Reset Value	9(16,2)
Keep Remainder on Reset	X(01)	“Y” if the remainder (modulus) is retained in Counter Balance at time of reset on hitting Reset Value.. “N” if remainder is not retained.

About Loyalty Marketing Campaigns (HAVE TO BE ADDED)

External Transaction Code

Requirement Definition

1. In general, every incoming transaction from external sources carries an External Transaction Code (TC) on OLS system.
2. The External System TC is the first key is located OLS TC for processing the transaction.
3. The TC values will be agreed with users at the time of setting up the system.
4. Each External Transaction Code must have an OLS Transaction Code associated with it.

For example: If source system send purchase transaciton to OLS under TC4000 then in this case it is necessary to define one external TC TC400 in OLS.

Process Flow

[Image Removed]

Trigger

1. New transaction code coming from external system then user have to define new external TC in OLS.
2. Some description should be adjusted then user have to modify.
3. User need to review one or all External Transaction Codes which added on OLS then user go to this screen to review.

Pre-Conditions

1. Users have to have the access right on this screen in order to accesss this screen.
2. Depending on user’s access rights, they can view / add/edit or approve External Transaction Code records.

Wireframe

1. Summary listing page

[Image Removed]

1. Detail view
2. Detail view

[Image Removed]

1. Record status and history

[Image Removed]

1. Create/Edit form

[Image Removed]

Business Rules

If Source TC required has not been defined, click on External Transaction Code icon in Main Menu to bring up the summary list as illustrated in section 4.4.5
Click on Add button ([Image Removed]) in the screen to bring up the edit form; clicking on the MoreOutLined icon (⋮) then click on Edit icon (!) also brings up the same edit form. The edit form for Transaction Code is illustrated in section 4.4.5 :
Screen descriptions


No	Field	Description	Data tye
1	External Transaction Code*/ Mã giao dịch hệ thống ngoài	Enter the Source System Transaction Code to be defined.	X(10)
2	Description */ Mô tả	A 30-character description of the source transaction code. This is intended for user reference so that the transaction code can be easily recognised.	X(30)

A new/edit External Transaction Code will display in pending Tab and display in Active tab after user approve the TC.
Repeat for each TC to be added/Edited.

Post-Conditions

User able to proceed to OLS Transaction Code screen. See in section 4.5

Exception Flow

Input data are not passed all validation and then the user chooses to cancel the action then the use case ends in failure.

OLS Transaction Code

Requirement Definition

Every transaction processed against Campaign Rules must have an OLS Transaction Code (TC) associated with it. The OLS TC is the first key by which relevant Campaign Rules are located for processing the transaction.
In general, every OLS transaction carries an external TC. In some cases, the transaction being processed is internally generated in OLS. This is especially for bonus award campaigns.
For example:
1. If OLS is configured to award bonus points for customers who achieve a certain level of spend at the end of the month, the award transaction is generated in OLS and has no external TC associated with it.

Process Flow

[Image Removed]

Trigger

New transaction code coming from external system then the user has to define new OLS TC also.
New OLS transaction coming from internal transaction.
Some detailed information should be adjusted then the user has to modify it.
The user needs to review one or all OLS Transaction Codes that are added to OLS then the user goes to this screen to review.

Pre-Conditions

Users have to have the access right on this screen in order to access this screen.
Depending on user’s access rights, they can view/add/edit or approve OLS Transaction Code records.
An external TC is required if this OLS TC is used to trigger CP rule for transaction coming from external system.

Wireframe

Summary listing page

[Image Removed]

Figure 1 – Summary listing page

[Image Removed]

Figure 2 – Filer and quick search

Detail view
1. Detail view

[Image Removed]

1. Record status ( History)

[Image Removed]

Create/Edit form

[Image Removed]

Business Rules

If the OLS TC required has not been defined, click on the OLS Transaction Code icon in the Main Menu to bring up the summary list as illustrated in section 4.5.5
Click on the Add button ([Image Removed]) in the screen to bring up the edit form; clicking on the MoreOutLined icon (⋮) and then clicking on the Edit icon (!) also brings up the same edit form. The edit form for the OLS Transaction Code is illustrated in section 4.4.5 :
Screen descriptions


No	Field	Description	Data tye
1	OLS Transaction Code*/Mã giao dịch OLS	Enter the OLS Transaction Code to be defined.	X(10)
2	Description*/Mô tả	A 30-character description of the source transaction code. This is intended for user reference so that the transaction code can be easily recognized.	X(30)
3	External Transaction Code/ Mã giao dịch hệ thống ngoài	The TC that comes from the transaction external system, which is to be mapped to the OLS Transaction Code. Each External TC must be assigned to only one OLS TC. One or more Exteranl TCs to be mapped to the OLS TC.	Multiple select Drop-down Lookup data from the “External Transaction Code’ screen Refer to “ External Transaction Code” API under Campaign Management
4	Reversal Indicator/Chỉ báo đảo chiều	Indicates transaction code is for a reversal or a normal transaction.	Check box Default unchecked

A new/edit OLS Transaciton Code will display in pending Tab and display in Active tab after user approve the TC.
Repeat for each TC to be added/edited.

Post-Conditions

User able to proceed to Campaign Rule Set-up. See section>>>>>

Exception Flow

Input data are not passed all validation and then user choose cancel the action use case ends in failure.

Pool Definition

Requirement Definition

All stored value such as rewards and cash balances or lucky draw chances are tracked in Pools.
Each Pool tracks a particular reward type, which is also associated with a Currency Code which represents the units of the stored value. E.g. a cash pool is used to store the Gift Card cash pool, and a Currency Code is assigned to represent the cash Currency Code - e.g. in Viet Nam this would be VietNam Dong and the Currency Code is VND.
Each stored value Pool tracks the stored value in Buckets. Each time the stored value balance in the Pool is incremented, at the time of incrementing the Pool balance, the Expiry Policy selected for this Pool is used to determine the date by which the stored value is to expire. The stored value is then added to the Pool in a bucket which would expire on the given expiry date as determined by the Expiry Policy.
Pools belong to “Loyalty Accounts” (LA) or Account (ASN) or Card (PSN). It is defined by pool entity level.
One LA is created per Customer (per unique CIF Number). One ASN is created per Account (per unique Account Number/ Account Level). One PSN is created per Card (per unique Card Number).
Pools are associated with the Customer’s Loyalty Account, where each Loyalty Account can have multiple Pools, each Pool for a reward type – e.g. Poiint Pool, Cash rebate Pool, etc

Process Flow

[Image Removed]

Trigger

Reward pool is not existing in OLS or have some informations need to be corrected.

Pre-Conditions

Users have to have the access right on this screen in order to view/update or approve these records.
Pool conversion rate which apply for new reward pool have to be actived on OLS. See section Pool Conversion Rate.
Account type group which is assinged to reaward pool have to be actived on OLS. See section Account Type Group.
If reward pool requires velocity control to restrict the number of redemption points/earned points/ adjustment points then Message template and Recipient Group are required and have to be actived on OLS. See section =>>>>> (OMR)

Wireframe

Summary listing page

[Image Removed]

Figure 1- Empty page

[Image Removed]

Figure 2- Listing page

[Image Removed]

Figure 3- Filter

Detail view
1. Pool detail

[Image Removed]

1. Record history

[Image Removed]

1. Pending record

[Image Removed]

Create/Edit form
1. General information

[Image Removed]

1. Product Specific Expiry

[Image Removed]

1. Velocity Control

[Image Removed]

Business Rules

If the reward pool required has not been defined, click on the Pool Definition icon in the Main Menu to bring up the summary list as illustrated in section 4.5.5
Click on the Add button ([Image Removed]) in the screen to bring up the edit form; clicking on the MoreOutLined icon (⋮) and then clicking on the Edit icon (!) also brings up the same edit form. The edit form for Pool Definition is illustrated in section 4.4.5 :
Screen descriptions

Seq	Field (EN /VN)	Description		Type
Statistic information
	Period /Chu kì	The choices are: * + - This month - Today	Drop-down Select one Default today
2.	Balance for use/ Số dư khả dụng	The total available balance of the pool Use the Expiration date and start date of the balance bucket to compare them with the selected period. Based on sysdate to determine the date range of each period. Get data to get the balance of the pool from the LAB table. One balance bucket is available to use when it is eligible for Redemption. Use the start date and expiration date of the balance bucket to compare with a selected period.	Display Number
3.	Expired balance /Số dư quá hạn	Total expired balance of pool which have xpiring date of balance bucket less than selected period. Based on sysdate to get determine date range of each period. If Period is “This month” then get all balance bucket which will be expired on currently sysmonth. If Period is “to day” then get all balance bucket which will be expired on currently sysdate.	Display Number
	Earned points/ Điểm thưởng	Total earned points of pool on selected period. Use the system to determine the period. Total earned points on each period based on the post date of the transaction.	Display Number
	Redeemed points/ Điểm đã đổi thưởng	Total redeemed points of the pool on selected period. Use the system to determine the period. Total earned points on each period based on the post date of the transaction.	Display Number
Step 1: General information
	Pool Id*/ Pool ID	* Mandatory. System-generated * A Pool ID is used to identify a Rewards Pool and the Pool ID will be stored in all its dependent modules and transaction logs for reporting and reference.		~~X(05)~~ X(10)
	Pool Name*/ Tên Pool	* Mandatory Field * Any printable ASCII character * Represents the name of the rewards pool. This will be used for drop-downs, reports, etc.		X(30)
	Pool Description / Mô tả pool	* Optional Field * Any printable ASCII character * Describes the purpose of the Pool, for user reference. Not used in processing.		X(200)
	Pool Type*/ Loại Pool	* Mandatory Field * Pool Type indicates the type of rewards (value) stored in this Pool. A Pool Type should be one among the following values and meanings: + Points - Pool Units in Point Pools are “points” and each “point” has a cash value as set in the Currency Rate table. “Cash” is the currency that is pre-set in the OLS instance. + Cash Rebate - Pool Units in Cash Rebate Pools are “cash” and each “point” is equivalent to cash on a one-to-one basis. Cash Rebates are typically values to be credited to an external system. The Currency Rate is set to 1 to 1 for cash. + Lucky Draw chances - Lucky Draw Pools contain the number of chances a customer has earned through campaign Rules. A different Pool can be set up for each Draw program independently of other Pools. The Currency Rate is ignored. + EVoucher - A eVoucher Pool Unit is contain the number of evoucher a customer has earned through campaign Rules.”Evoucher” earned is formula result. * Lookup value from “Code management” with code_type =’pool-type”. Refer API “Get list-by-code-type” under Master Data. * Don’t allow to edit if found the balane bucket record of this pool.		Drop-down Select one
	Expiry Policy/ Chính sách hết hạn	* Condition field. Inactive for Evoucher pool and required and active for remaining pool. * An Expiry Policy determines how the system computes the expiry date for the reward earned during transaction processing. * If Pool Type selected is “Evoucher” then this field is inactive. There is non-expire for Evoucher pool type. * More detail are described in step 2. * Do not allow editing of the expiry policy (including the related field used to determine the expiry date of the balance bucket) if a balance bucket record for this pool is found.		Drop-down Select one Lookup value from “Code management” with code_type =’ pool-expiry-policy”. Refer API “Get list-by-code-type” under Master Data.
	Pool Expiry Policy Parameter N / Tham số chính sách hết hạn N	* Conditional field. * A number value that is taken to be the value of the Policy Parameter N, of the selected Expiry Policy * If the policy selected in the preceding field “Pool Expiry Policy” expects a parameter N, then this field is active and mandatory and a number value is expected. * If the policy selected in the preceding field “Pool Expiry Policy” expects a date parameter, then this field is inactive.		9(5) Should be greater than or equal to 0 if provided
	Expiry Date/ Ngày hết hạn	* Conditional field. * If the policy selected in the preceding field “Fixed Date” then this field is active and mandatory and a valid date is expected. * Otherwise, this field is inactive.		Date
	Ripening Period/Kì hạn được đổi thưởng	* Condition field. Inactive for Evoucher pool and active for remaining pool. * The Ripening Period is the number of days from the transaction date after which the reward will be eligible for Redemption. * The reward earned on day 1 will only be available for redemption after Ripening Period days from the date of earning. * By default, the reward ripens on the day of transaction, i.e. the reward is available for redemption immediately. * The Ripening Period is used to determine start date of balance bucket. If Ripening Period is 0 or empty then the sysytem default start date of balance bucket as 19000101 ( This value should be configurable value instead hardcoding) * Just active if Expiry Policy is actived. Otherwise, this field is inactive.		9(5) Should be greater than or equal to 0 if provided
	Pool Conversion Rate Code*/Mã tỉ lệ chuyển đổi pool	* Condition field. Inactive for Evoucher pool and active for remaining pool. * Currency representing a unit of reward in this Pool. This is a drop-down based on values in Pool cconversion Rate table.		Drop-down Select one Lookup value from “Pool Conversion Rate “ screen ( Pool_Conversion_Rate table) Refer to “Pool Conversion Rate” API under ”Campaign Management”
	Allow Negative Balance on Cancel/Refund/Ad-just / Cho phép số dư âm do giao dịch hủy hoặc điều chỉnh	* Condition field. Inactive for “Evoucher” pool. * Defaulted to “Do Not Allow”. In this mode, the amount that cannot be deducted because of insufficient Pool Balance will be posted as two adjustment transactions – one positive and one negative, with the Adjustment Reason set to “Negative Balance Adjustments”. * If set to “Allow”, indicates the Pool Balance is allowed to go negative during adjustment and cancellation/reversal processing. * Does not apply to redemption processing: redemptions declined if there is insufficient balance		Switch button Default OFF
	Precision (Number of Decimal Places) /Độ chính xác (Số thập phân)	* Condition field. Inactive for Evoucher pool and required and actived for remaining pool. * Defaulted to “2” decimal places * This represents the number of decimal places that is required to store the rewards in the Reward Pool. * Precision cannot be amended downwards to lower precision after transactions have been posted into the Pool (Found LAB records). * Show confirm message when user wants to change the precsion in case it is allowed to change such as “ The change in precision will be applicable only to new updates to the Pool Balance going forward. Existing pool balance data will retain the previous precision. Proceed with change?”/ “Thay đổi độ chính xác của số thập phân chỉ áp dụng cho việc cập nhập số dư mới tính từ thời điểm thay đổi. Số dư hiện tại vẫn theo độ chính xác số thập phân trước đó. Bạn có muốn thay đổi không?”		Drop-down Select one Lookup value from “Code management” with code_type = ’precision-scale’. Refer API “Get list-by-code-type” under Master Data.
	Account type group / Loại nhóm tài khoản	* Optional field * If Account Types are selected for the Pool and ATG logical is appliable, OLS will only allow transaction of the selected Account Types to earn/Postive adjustment to this Pool. * Don’t allow to edit if found the balane bucket record of this pool.		Drop-down Select one Lookup distinct ATGid from “Account Type Group” screen (Account_Type_Group table). Refer “Account Type Group” API under “Campaign Management”
	Grace Period/Kì ân hạn	* Condition field. Inactive for Evoucher pool * The number of months to keep expired buckets before forfeiting the points in the buckets. * This field is defaulted to empty.		9(2) Should be greater than or equal to 0 if provided
	Entity level*/ Cấp thực thể	* The Indicator determines whether the Pool balance is tracked at Card, Account or Customer level * Pool with Entity Level set to Account or Customer cannot be amended downwards to Card-level after transactions have been posted into the Pool (Found LAB records) * Pool with Entity level set to Account can be amended into Customer OR Customer pool can amended into Account level regardless transactions have been posted to the pool. * All pool entity level can be amended if there is no balance records on the pool * Pool with Entity level set to Card can not be amended into Customer/Accoutn level after transaction have been posted into the pool (found LAB record )		Radio button Lookup value from “Code management” with code_type = ‘entity-lvl’. Refer API “Get list-by-code-type” under Master Data.
Step 2: Product Specific Policy / Chính sách riêng về tài khoản * This is an optional step. * Avaiable PA which can be selected will be PA Types to which pool is restricted only. * Each PA Type can be selected only in one row. * More than one Expiry Policy can be added, one per display row, per group of PA Types. * OLS will apply specific expire policy for transaction which have account type in selected PA types. Otherwise apply common Expire policy of the pool.
	Product Account Level*/ Hạng tài khoản	* Mandatory field * Product account level		Drop-down Select one Lookup value from “Producar Account Level” screen ( Product_Account_Level table). Refer “Product Account Level” API unnder “Code Maintenance”
	Product Account Type*/Loại tài khoản	* Mandatory field * Product account type under selected Product account level. * Account type restricted to this pool only. * Lookup value from “Producar Account Type” screen (Product_Account_Type table). Refer “Product Account Type” API unnder “Code Maintenance”		Drop -down Select one
	Expire policy*/ Chính sách hết hạn	* Every Pool must have a Pool Expiry Policy, even if the policy is to never expire the balance in the Pool. * An Expiry Policy determines how the system computes the expiry date for the reward earned during transaction processing. * OLS provides the following standard polices: * N Months from month of earning: Points earned in month 1 expire at the end of month N+1. N is set in “Expiry Policy Parameter”. E.g. if N = 3, then points earned in January will expire end of April, points earned in February will expire end of May, etc. * N Quarters from quarter of earning: Points earned in quarter 1 expire at the end of quarter N+1. N is set in “Expiry Policy Parameter”. E.g. if N = 2, then points earned between 1-January ’15 and 31st March’15 will expire after 30th September’15, points earned between 1-April’15 and 30th June’15 will expire after 31st December’15 and points earned between 1-July’15 and 30th September’15 will expire after 31st March’16, etc. * Semi-annual, mid- and end-year: Points earned in 1st half of the year expire end of June the following year; points earned in 2nd half of year expire end December the following year. * N Years from year of earning: Points earned in year 1 expire at the end of year N+1. N is set in “Expiry Policy Parameter”. E.g. if N = 1, then points earned between 1-January ’15 and 31st December’15 will expire after 31st December’16, points earned between 1-January’16 and 31st December’16 will expire after 31st December’17 and points earned between 1-January’16 and 31st December ’16 will expire after 31st December’17, etc * Anniversary of membership: Points earned will expire on each anniversary of the customer’s membership. E.g. if customer joins on 15th February 2010, points earned before 15th February 2011 expire on 15th February 2011. * Fixed Date: Points will expire on the date specified in the “Expiry Date” parameter. A Campaign Rule which updates this Pool is not allowed to have End Date later than this date. * No Expiry: Points earned are in an ever-green bucket. Expiry Date in bucket will be defaulted to 31-Dec-2999.		Drop-down Select one Lookup value from “Code management” with code_type =’ pool-expiry-policy”. Refer API “Get list-by-code-type” under Master Data.
	Pool Expiry Policy Parameter N / Tham số chính sách hết hạn N	* Conditional field. * A number value that is taken to be the value of the Policy Parameter N, of the selected Expiry Policy * If the policy selected in the preceding field “Pool Expiry Policy” expects a parameter N, then this field is active and mandatory and a number value is expected. * If the policy selected in the preceding field “Pool Expiry Policy” expects a date parameter, then this field is inactive.		9(5) Should be greater than or equal to 0 if provided
	Expiry Date/ Ngày hết hạn	* Conditional field. * If the policy selected in the preceding field “Fixed Date” then this field is active and mandatory and a valid date is expected. * Otherwise, this field is inactive.		Date
Step 3: Velocity control / Kiểm soát hạn mức 1. This is an optional step 2. This step for editing Velocity Control parameters to define thresholds at which the system will send alerts and generate exception alert reports. 3. Multiple rows of velocity control conditions may be added to the display row 4. The parameters in the edit row collectively form a condition statement:
	Maximum*/ Tối da	* Mandatory field * The number of Pool Units beyond which alerts are triggered		9(10,2) Should be greater than 0
	Transaciton Type*/ Loại giao dịch	* Mandatory field + - * Award * Redeem * Adjust		Drop-down Select one Lookup value from “Code management” with code_type = ‘velocity-txn-type’. Refer API “Get list-by-code-type” under Master Data.
	Units*/ Đơn vị	* Mandatory field + - * Per Pool units * Per transaction		Drop-down Select one Lookup value from “Code management” with code_type = ‘velocity-unit’. Refer API “Get list-by-code-type” under Master Data.
	Per Entity 1/ Thực thể 1	* Optional field + - * Customer * Account * Card * If Per entity 1 is not provided then this limitation is applied for whole system.		Drop-down Select one Lookup value from “Code management” with code_type = ‘velocity-entity-lvl’. Refer API “Get list-by-code-type” under Master Data.
	Per Entity 2/ Thực thể 2	* Optional field + - * Corporation * Chain * Store * Terminal If Per entity 1 is not provided then this limitation is applied for whole system.		Drop-down Select one Lookup value from “Code management” with code_type = ‘velocity-merchant’. Refer API “Get list-by-code-type” under Master Data.
	Per period*/ Chu kì	Mandatory field * + - * Quarter * Month * Week * Day		Drop -down Select one Lookup value from “Code management” with code_type = ‘velocity-period’. Refer API “Get list-by-code-type” under Master Data.
	Alert Template*/ Mẫu cảnh báo	* Madatory field The template containing the alert message to be sent when velocity control conditions are met.		Drop -down Select one ==tbd==
	Alert Group*/Nhóm cảnh báo	* Mandatory field * The group of recipients to receive the alert message. * This can be an SMS group or an Email group or a mix of both		Drop-down Select one ==tbd==
Effected Campaign Rule listing linked this reward pool [Image Removed]
	Campaign /Mã chiến dịch	Campaign which reward rule belong to the choosen pool		Display Lookup value from CAMPAIGN_RULE table
	Rule /Mã quy tắc	Campain Rule which trigger to reward pool		Display Lookup value from CAMPAIGN_RULE table
	Transaction Code/ Mã giao dịch	Transaction Code linked to campain rule		Display Lookup value from CAMPAIGN_TC_LINKAGE table
	Start Date / Ngày bắt đầu	The start date of effected period Campaign Rule		Display Lookup value from CAMPAIGN_RULE table
	End date/ Ngày kết thúc	The end date of effected period Campaign Rule		Display Lookup value from CAMPAIGN_RULE table

A new/edit reward pool will display in pending Tab and display in Active tab after user approve the TC.
Repeat for each reward pools to be added/edited.

Post-Conditions

User able to proceed Campaign Rule setup/ Item price setup / Post new transaction/PwP setup….any where pool id is required.
A pool with Card-level setting will be updated with one Pool bucket per unique pair of Card number + period (start date and expiry date). The balance in each Bucket in the Pool can only be redeemed by the Card that earned the balance in that bucket.
A pool with Account-level setting will be updated with one Pool bucket per unique pair of Account & period (start date and expiry date). The balance in each Bucket in the Pool can only be redeemed by the Account (and any Card of that Account, depending on the redemption criteria) that earned the balance in that bucket.
A pool with Customer-level setting will be updated with one Pool bucket per unique pair Account & period (start date and expiry date). The balance in each Bucket in the Pool can only be redeemed by the Customer, using any Account/Card of the Customer (depending on the redemption criteria) that earned the balance in that bucket.
Within each Pool, the earnings are tracked in Pool Buckets segregated by Expiry Date and Account Type. The earnings by an Account are tracked in that Account’s buckets in the Pool if pool entity level is Customer or Account level. The earnings by a Card are tracked in that Card buckets in the Pool if pool under Card level.
If the earnings fall into different expiry dates, then the earnings of each expiry date are tracked in a distinct bucket for that Account/Card, for each preiod (The start date and expiry date of the bucket).

Exception Flow

Input data are not passed all validations and then user choose cancel the action then use case ends in failure.

Pool Conversion Rate

Requirement Definition

The Pool Conversion Rate table is a look-up to associate a description text to each Pool Conversion Rate Code for easy user reference in displays and reports.
Reward types are tracked in Pools. Each Pool is associated with a Pool Conversion Rate. The Pool Conversion Rate Code is associated with a Pool Conversion Rate set in the Currency_Rate table. When processing reward and redeem/adjustment transactions, the Currency Rate for the Pool is used.

Process Flow

[Image Removed]

Trigger

Pool conversion rate is not existing in OLS or have some informations need to be corrected.

Pre-Conditions

Users have to have the access rights in both Pool Converion Rate and Currency Rate moudles in order to can view/update or approve these records.
User must select a record in pool conversion rate listing page to bring up Curreny Rate tab.

Wireframe

Summary listing page

[Image Removed]

Figure 1 – Pool Conversion Rate

[Image Removed]

Figure 2- Currency Rate

Detail view
1. Detai view

[Image Removed]

Figure 1 - Pool Conversion Rate

[Image Removed]

Figure 2- Currency Rate

1. Record status

[Image Removed]

Figure 1- Pool Conversion Rate

Create/Edit form

[Image Removed]

Figure 1- Pool Conversion Rate

[Image Removed]

Figure 2 – Currency Rate

Business Rules

Click on the Pool Conversion Rate icon in the navigation panel under Campaign Management to get a listing of the existing Pool Conversion Rate, as illustrated in section 4.7.5.
Click on the Add button ([Image Removed]) in the screen to bring up the edit form; clicking on the MoreOutLined icon (⋮) and then clicking on the Edit icon (!) also brings up the same edit form. The edit form for Pool Conversion Rate is illustrated in section 4.7.5.
Double click on any existing record in Active Tab then the Currency Rate listing is illustrated in section 4.7.5
Click on the Add button ([Image Removed]) in the screen to bring up the edit form; clicking on the MoreOutLined icon (⋮) and then clicking on the Edit icon (!) also brings up the same edit form. The edit form for Pool Currency Rate is illustrated in section 4.7.5.
Screen descriptions:

Seq	Field (EN/VN)	Description	Type
Pool Conversion Rate Code/ Mã tỉ lệ chuyển đổi
1	Pool conversion Rate Code*/ Mã tỉ lệ chuyển đổi pool	* A code to represent the pool conversion rate. * To contain at least one alphabet.	~~X(3)~~ X(10)
2	Description*/ Mô tả	* Description of the currency code. This description will be shown in the drop-downs, reports etc.	X(30)
Pool conversion Rate / Tỷ lệ chuyển đổi
	Pool Conversion Rate Code*/Mã tỉ lệ chuyển đổi pool	* This is the Pool Conversion Rate whose Rate against the Base Currency is being configured.	View only
	Buy Rate*/ Tỉ giá mua	* This is the amount of Base Currency required to purchase 1 unit of the Currency Code (i.e. 1 Pool Unit). * This is used to calculate the value of a point awarded transaction for posting to GL for award. This is also used to calculate the value of a point adjustment transaciton for posting to GL for positive adjustments. * The rate used is the effective rate at the time of transaction.	9(6,2) Should be greater than 0
	Sell Rate*/ Tỉ giá bán	* This is the amount of Base Currency that will be received in exchange for giving away one Pool Unit of the Pool that is assigned to this Currency Code. * This is used to calculate the value of a point redemption transaction for posting to GL for non-catalogue item redemptions. This is also used to calculate the value of a point adjustment transaction for posting to GL for negative adjustments. * The rate used for deriving costs is the effective rate at the time of transaction.	9(6,2) Should be greater than 0
	Effective From Date*/ Ngày bắt đầu	* Start Date is the date on and after which the Rates in this record are effective * End Date is the date after which the Rates in this record is no longer effective. * The end date must greater than or equal to start date. * During the period between Start Date and End Date, the record is an “Effective Record”. * If there is more than one Effective Record for a Currency Code at any one time, then rates in the Effective Record with the latest Start Date are used.	Date The date format must adhere to the configured format
	Effective End Date*/ Ngày kết thúc

Post-Conditions

1. User able to proceed Pool Definition setup.

Exception Flow

- 1. Input data are not passed all validations and then user choose cancel the action then use case ends in failure.

Counter Definition

Requirement Definition

The system makes use of Counters to track totals – e.g. total spend, total earned, total redeemed – within given time periods.
The Counters can then be referenced in Campaign Rules are criteria.
Counters are updated only upon fulfilling the Rule Criteria, and hence be used to track transactions that fulfill particular conditions – e.g. only transaction so $100 or more, only transactions done on Wednesdays, etc.
A Counter is structured
- Counters can track totals by periods – e.g. monthly totals, quarterly totals, etc.
- The cut-over from one period to the next can be:
  - 1. Automatic based on the Transaction Date or the Batch Date, or
    2. Forced, by setting a Counter “State” when it is decided that a period total should be closed and a new one started. This is a “State Counter”
A “State Counter” tracks the total in the same bucket until a process (e.g. a Campaign Rule) specifically updates the State of the bucket to “close” the bucket.
- After the State of the bucket is updated to “Closed”, further updates to the Counter goes into a new “current” bucket.
- Every update to the Counter thereafter updates the “current” bucket until its State is updated to “closed”
- A new “current” bucket is automatically created by subsequent updates.
Use Case: the campaign is to reward customers with a 5% bonus on top of the month’s total earnings from regular campaigns if customer’s total spend in that month is more than $1,000
- Customer’s earnings from regular campaigns are updated into a monthly counter C1 by the regular Campaign Rules
- A separate Campaign Rule is set up to update a monthly spend counter C2 on every spend transaction processed throughout the month
- At the end of the month, all customers whose Counter C2 is more than $1,000 are awarded 5% of the total earnings tracked in C1.

Process Flow

[Image Removed]

Trigger

If the campaign requires transaction amounts to be accumulated or counted before the award can be determined, then Counters are required.
If Counter is required and it is not an existing Counter, click on Counter Definition icon in Main Menu to bring up the summary list as illustrated in section 4.7.5
For example:
- A Counter may be set up to track the total spend by the card in merchants with selected MCC – such a Counter is a “spend” Counter
- A Counter may be set up to track the number of pool units calculated by Rule Formulae (for award and redeem) – such a counter is a “Pool Units” Counter
- A Counter may be set up to track the number of transactions performed by card at a selected merchant – such a counter is a “frequency” Counter

Pre-Conditions

N/A

Wireframe

Click on Counter Definition in Main Menu to bring up the summary list as illustrated here:

[Image Removed]

Use the search filter to locate the counter required:

[Image Removed]

Click on Add a Counter in the screen will bring up the same edit form as illustrated in the following

[Image Removed]

Click on a row showing an existing Counter in the display will bring up the view form for that Counter as illustrated here:

[Image Removed]

Click on “Record Status” tab in the view form of counter will bring up the record history for that Counter as illustrated here:

[Image Removed]

Business Rules

The key data entities making up Counter are defined in the following table:


Index	Field (EN/VN)	Description	Data type
	Counter Id*/ ID bộ đếm	Unique identifier for a Counter Definition record	X(10)
	Counter Name*/Tên bộ đếm	A text string that describes this counter; it can be used as a unique identifier for this Counter Definition.	X(50)
	Counter Description/Mô tả bộ đếm	A text string that more completely describes this Counter Definition, elaborating on what it is used for (its intended purpose), etc	X(200)
	Effective From Date*/ Ngày hiệu lực bắt đầu	Start Date is the date on and after which the Counter is effective.	Date. The date format must adhere to the configured format
	Effective To Date */Ngày hiệu lực kết thúc	End Date is the date after which the Counter is no longer effective. • During the period between Start Date and End Date, the record is an “Effective Record”. End date must equal or greather than start date	Date. The date format must adhere to the configured format
	Entity*/Cấp thực thể	Drop-down, defines the Entity level at which the counter will be kept – this determines, for example, whether the count is tracking spend at customer level or account level, etc. E.g. a Counter at Customer level means there is a unique Counter per Customer. The Entity level at which a quantity is to be tracked	X(05) Drop-down. Select one. Lookup value from "Code_Management" table where code type is "counter-level". Refer "get-by-code-type" API under master data.
	Bucket Period Unit */Thời kì đếm	The Counter records data in “Buckets” per “Counter Period” The Counter Period of a Counter defines the time period for which to accumulate in a single bucket in the counter. When a transaction triggers a Counter update action, the Counter Method calculates the Counter Period based on the Counter Definition parameters and the Transaction Date: At the end of the Counter Period, a new bucket is automatically created. A Counter Period is quantified in terms of the Length of Counter Period, which is measured as “N Counter Period Units”, i.e. each Bucket tracks totals for one Counter Period of “N Period Units”; The “Period Unit” can be any one among the following values.
	Bucket End Date/ Ngày kết thúc bộ đếm	Condition field. This field is actived and required only when "Fixed date" Unit is selected	Date. The date format must adhere to the configured format
	Bucket Period Duration(N)/	Condition field. Inactive if Bucket period unit as Fixed date/Non-expiry. Required and active for remaining period unit. counter bucket based on duration as following: * N-Day Counter: One bucket is created every N Days, starting from the date of first transaction. E.g. + If first transaction is on 13th March and N is 10, then the first Bucket expires after 23rd March. + All transactions before and up to and including 23rd March updating the Counter will update this Bucket. + A transaction dated 24th March updating the Bucket on 24th March will result in a new Bucket expiring on 3rd April (10 days later). A transaction dated between 4th - 12th April 2018 will update a Bucket with Expiry Date 12th April 2018 N defaults to 0 (the minimum), in which case a Bucket is created everyday there is a transaction –i.e. Bucket Expiry Date is Transaction Date. * N-Month Counter: One bucket is created every N Months, starting from the month of first transaction + The month when the first Counter Bucket is created is the Start Month of the Counter. The Bucket Expiry date of the first Bucket is set to end of N months thereafter. E.g. if first transaction month is May, and * + N = 1, then the Bucket Expiry Date is 30-June. + Each transaction updates Bucket with the smallest Expiry Date which is later than Transaction Date. + If there is no Bucket with Expiry Date greater than or equal to Transaction Date, a new Bucket is created with Bucket Expiry Date set to the next end of month which is a multiple of N months from Start Month. N defaults to the minimum of 0, in which case the Expiry Date is the end of transaction Month. * N-Week Counter: One bucket is created every N Weeks, starting from the Week of first transaction. + N defaults to the minimum of 0, in which case the Expiry Date is the end of transaction Week Start of Week is entered as a second parameter * N-Quarter Counter: One bucket is created every N Quarters, starting from the Quarter of first transaction N defaults to the minimum of 0, in which case the Expiry Date is the end of transaction Quarter * N-Year Counter: One bucket is created every N Years, starting from the Year of first transaction N defaults to the minimum of 0, in which case the Expiry Date is the end of transaction year. * No Expiry The same Bucket is updated all the time, until the State is specifically updated to * Fixed Date Period + This is a single-period Counter period calculation method. The Bucket Expiry Date is set to the Fixed Date. Bucket is updated by all transactions that have a transaction date before the Fixed Date. * N Days from AOD * One bucket is created every N Days, starting from the AOD. * N Months from AOD * One bucket is created every N Months, starting from the AOD. E.g AOD = 15/July/2022 counter unit = 1 month of AOD Then counter bucket will be: 15/July - 14/Aug, 15/Aug - 14/Sep 15/Sep - 14/Oct... * N days from COD (Card Open Date) * One bucket is created every N Months, starting from the COD. E.g COD = 15/July/2022 counter unit = 1 days of COD Then counter bucket will be: 15/July – 15/Jul, 16/Jul – 16/Jul	9(02) Should be greater than 0 if provided
	What to count*/ Tiêu chí đếm	The data entity that is to be counted or tracked	Drop-down Select one Lookup value from "code_management" table where type code is "counter-count". Refer "get-by-code-type" API under master data
	Reset type*/Loại cài đặt lại giá trị	The Reset Type choices are as follows: Reset to 0 when Reset Value exceeded/ Reset to remainder when Reset Value exceeded	Drop-down Select one Lookup value from "counter-count" table where type code is " counter-reset-type". Refer "get-by-code-type" API under master data
	Reset Value*/Khi giá trị vượt qua	Defaulted to “999999999”. Must be numeric. Indicates the value at which the counter Bucket End Date will be set to the current date-time and a new bucket is started	9(14,2)
	First Start Date Is Fixed/ Ngày bắt đầu đầu tiên là cố định	Condition field.Inactive for following Buket Period Unit: Days from AOD, Months from AOD, AOD Anniversary, Quarters from AOD, Fixed Date, No Expiry, Days from COD	Switch button. Default off
	First Start Date/Ngày bắt đầu	Condition field. Active and required only when First Start Date is fixed	Date. The date format must adhere to the configured format
	Update State When*/ Cập nhật trạng thái bộ đếm khi	The Counter Buckets have a default State of “C” (“created”). This State can be updated to “A” to force a stop to the update of the Bucket and cause a new Bucket to be started in the same period. "On ward" when counter is extracted and hit CP rule. "On extract" when counter is extracted regardess to hit or no hit CP rule."Never" mean for Counter state still is C even counter is extracted or not"	Radio button. Lookup value from "Code_Management" table where type code is "counter-state". Please refer "get-by-code-type" API under master data
	Late transaction Posting Option*/ Đăng giao dịch trễ	This option is used to determine the counter bucket which late transaction posting will update. There are 2 options: * Late counter value: The TP will update counter value into “late counter value” if transaction posted after counter is extracted * Current counter bucket: The TP will update counter value into value of currently counter bucket regardless of Effective Date. Refer to post -condition to get more logical on this one	Radio button Default “Late counter value” Lookup value from “Code_Management” table with code type is “late-txn-posting”. Refer “get-by-code-type” API under master data.
Validation: - If the Counter Id already exists counter value (counter_stock table), please block changes to the Counter Definition record except for the End Date/Counter Name/Description. In this scenario allow End Date to be brought forward (>= current Batch Date) or pushed further into the future. - Cannot delete if counter id already exists in Counter_stock table.

Post-Conditions

- - - 1. The Expiry Date (ED) of a Counter Bucket to be updated by a transaction with Transaction Date = TD is the Bucket with ED derived as specified in the following link:

Update counter (Formula 5) Processing

Late counter transaction posting

When late transaction is comming:

If "Late Transaction Posting Option" = "Update Late Value"

& State! = C then update

Else if "Late Transaction Posting Option" = "Update Current Bucket"

& State! = C --> update Current Bucket (Use post date of the transaction to determine the current bucket to update), regardless of Effective Date.

Scenario: [Image Removed]

Exception Flow

Transaction Category

Requirement Definition

1. Transaction Category help business can define each processed transaction under pre-defined category.
2. Transaciton Category is one combination of more than one criteria, that allows same criteria set may be re-used many times. The most importantly, it allows a more efficient way to setup Campagin Rule Criteria.
3. Business case:

3.1 Enrollment Program


Index	Trasaction Category	Campaign Rule Criteira	Award rate
	Dining	Dinning transaction AND Local currency and DCC transaction	1%
	Entertaiment	Entertainment transaction AND local currency and DCC transaction	2%
	Dining	Dinning transaction AND Foreign currency and NOT a DCC transaction	3%
	Entertaiment	Entertainment transaction Foreign currency and NOT a DCC transaction	4%

If there is no Transaction Category, we need to have we need to have separate counter ids for these 4 cases so we need 4 Campaign Rules to update these 4 counters.

Therefore If the 4 conditions are are captured as transaction category then we have:

TxCat1 = Dining txns, local currency + DCC

TxCat2 = Entertainment txns, local currency + DCC

TxCat3 = Dining txns, foreign currency + not DCC

TxCat4 = Entertainment txns, foreign currency + DCC

To archive this campaign, when define the transaction category we just need:

One counter under Account-TxnCat couter level
One CEP rule to extract counter value to trigger award rule to get award points/cash back.
One Campaing Rule using F6 to fulfilment this requirement.

Process Flow

Trigger

Pre-Conditions

Users have to have the access right in the Transaction Category moudle in order to able to view/update or approve these records.
Assume that all criteria are defined as attribute and appear in right panel to user can drag/drop to setup

Wireframe

- - 1. Create/Edit mode

[Image Removed]

Business Rules

Each of these criteritions are accessed directly by drag/drop on the right Criteria panel as illustrated in the wirefarme.
OLS system will use Query Builder to build query for this screen such as Rule Criteria.
All criterions will be listed on selection criteria panel (right panel). User can drag/drop criteria from right panel to set up rule. Criterion list will be defined as attribute so that user can define needed criteritions.
OLS system support AND or OR condition between difference criteria groups on the same campagn rule. The relationship operator on each group will be applied for all criteritions on the group. User can setup only one or many group on the same rule but OLS system just support the same operator condition bettwen groups such as all are OR conditons or all are AND conditions.

For example:

Rule 1:

Group 1 OR Group 2 OR Group 3

Rule 2:

Group 1 AND Group 2 AND Group 3.

Introduce NOT toggle switch to support exclusion criteria.
User can put the key word to search criteria on Right Criteria panel.
Each criteria can be used one more time in the same category.
Screen description


Index	Field (EN/VN)	Description	Data type
General information
	Transaction Category Code*/Mã danh mục giao dịch	Unique identifier for a Txncat record	X(05)
	Transaction Category Name*/Tên danh mụ c giao dịch	Name of transaction category	X(50)
	Description/Mô tả	Description for refer only	X(100)
Transaction Category Configuration The same approach as Rule Criteria. See more detail in the section Rule Criteria. Note: The Criteria list are the same as Rule Criteria except Transaction Category Criteria

Post-Conditions

- - 1. Transaction category will be used in the Campaign Rule Criteria as a separate criterion.

Exception Flow

Account Type Group

Requirement Definition

- - 1. An account type is a combination of Product account level and product account type.
    2. Account Types are put into Account Type Groups (ATG). ATG is groups Account Types (Org + Logo) and orders them in priority for deductions during redemptions and adjustments (Customer-level Pools)
    3. Each reward Pool is assigned an ATG, and only Accounts of the selected ATG can earn/postive adjust into that Pool.
    4. There is no ATG checking for redemption and negative adjustment.
    5. An ATG Sequence number is assigned to each Account Type in an ATG.
    6. When system has to select an Account Type for a transaction, the Account Type with the smallest ATG Sequence is selected.

Process Flow

[Image Removed]

Trigger

New account type is coming then need to be added this account under ATG of reward pools.
Some points need to be corrected for existing ATG.

Pre-Conditions

Users have to have the access right on this screen in order to can view/update or approve these records.
Account type which apply for ATG have to be actived on OLS.

Wireframe

- - - 1. Summary listing page

[Image Removed]

Figure 1 – Listing page

[Image Removed]

Figure 2- Filter

- - - 1. Detail view
1. Detail view

[Image Removed]

1. Record status (history)

[Image Removed]

- - - 1. Create/Update form

[Image Removed]

Business Rules

- - - 1. The combination ATG id + Account type ( logo+ org) and Sequence No is unique.
      2. If ATG required has not been defined, click on Account Type Group icon in Main Menu to bring up the summary list as illustrated in section Wireframe
      3. Click on Add button ([Image Removed]) in the screen to bring up the edit form; clicking on the MoreOutLined icon (⋮) then click on Edit icon (!) also brings up the same edit form. The edit form for Account Type Group is illustrated in section Wireframe:
      4. Screen descriptions:

Seq	Field (EN/VN)	Description	Type
1.	Account Type Group Id* / Mã loại nhóm tài khoản	Account type group ID which assingned to rewards pool. The combination of ATGid and Account type is unique.	X(10)
2.	Description*/ Mô tả	Description to describe this ATG	X(100)
3.	Product Account Level*/Hạng tài khoản	* 1. An ATSP is a list of Account Type (PA Level
4.	Product Account type*/Loại tài khoản	Drop-down Select one Lookup value from “Product Account Type” screen- PAT table where PAL is selected PAL Refer to “Product Account Type” API under Code Maintenance
5.	Sequence No*/ Số thứ tự	The processing sequece number	9(04) Should be greater than or equal to 0
Linked Pool / Pool liên kết This listing page is actived when user click view detail of an ATG record. The listing page includes all pools linked to the selected ATG, as well as the effected campaign rule linked to each pool. [Image Removed]
	Pool/Pool	Pool linked to the selected ATG	Display Include Name and Code Lookup value from “Pool Definition” Screen. Lookup Pool_Definition table where ATG of the pool is selected ATG.
	~~Pool Name/ Tên pool~~	~~Pool Name~~	~~Display~~ ~~Lookup value from “Pool Definition” screen.~~ ~~Refer to “Pool Definition’ API under Campaign Management~~
	Campaign Rule / Quy tắc chiến dịch	Campaign Rule linked to the reward pool Leave as empty if there is no CP rule linked to this pool e.g New pool	Display Includes name and code Lookup value from Campaign_Rule table by specific pool Id
	~~Rule Name/ Tên quy tắc~~	~~Name of Campaign Rule~~	~~Display~~ ~~Lookup value from “Campaign_Rule” table by specific Campaign Rule ID~~
	Effective Date /Ngày hiệu lực	Effective Date of Campaing Rule Leave as empty if there is no CP rule linked to this pool e.g New pool	Display Includes Effective Start Date and Effective End Date Lookup value from “Campaign_Rule” table by specific Campaign Rule ID

Post-Conditions

ATG is used for dedection sequency control. When customer redeem/ post negative adjustment transaction under customer pool enity level:
1. Based on Pool entity level / ATG of pool to locate deducted pool balance bucket.
2. Points are deducted in order of ascending Expiry Date (earliest expiring dates first).
3. If more than one bucket has the same expiry date, the bucket are further sorted by start date (earliest starting dates first).
4. If more than one Bucket has the same expiry date and start date, the buckets are further sorted by a pre-configured priority sequence – i.e. buckets of lower priority Account Types will be deducted first. Account types are not under ATG will have the highest priority sequence.
5. Redemption from expired buckets is allowed with supervisor approval during item redemption through administration screen.

Example of an ATSP comprising 2 Account Types

ATSP Id PA Level PA Type Sequence Number

| 11 | | 830 550 | | 10 |

| 11 | | 830 630 | | 20 |

When posting transactions where the Entity provided is the CIF Number, an Account of the CIF with lowest ATSN will be selected to be the Transacting Account

Example 1: when transaction in batch transaction file contains CIF Number but not Account Number, an Account of the CIF Number will be selected whose Account Type has the smallest sequence number in the ATG of the Pool of the transaction.

Example 2: when a CEP transaction is posted where the Counter is at Customer level, an Account of the CIF Number will be selected whose Account Type has the smallest sequene No in the ATG of the Pool of the transaction.

ATG is used to find account to post transaction in case transaction is coming with CIF number only. In case ATG is appliable then:

A = set of all Acct Types of Cust
B = set of Acct Type in ATG of Pool
C = Intersection of A and B

Therefore:

If C is null then txn is rejected.
if C is not NULL, and more than one acct type found in C, TP will get Acct type with smallest seq no in ATG of Pool to post transaction.

Example: Adjustment transaction is posted by CIF number then TP must locate Account which under ATG of pool to post transaction.

ATG is used to validate transacting account/Card/CIF. Transacting Account/Card/CIF number should be under ATG of pool.

If incoming transacitons are posted by Account or Card then transacted account type should under ATG of reward pool. If not transaction will be rejected.
If CIF number is provided only then TP base on following process to find eligible account to process:

A = set of all Acct Types of Customer

B = set of Acct Type in ATG of Award Pool

C = Intersection of A and B

Therefore:

If C is null then txn is rejected.
if C is not NULL, and more than one acct type found in C, TP will get Acct type with smallest seq no in ATG of Pool to continue processing.

Example: Award transaction is posted by CIF number then TP must to locate Account under eligible acccount type to find valid rule and trigger CP rule.

ATG is used to validate blocked transaction.
ATG is employed to determine the account type restricted by the reward pool specified in the Pool Definition.

Exception Flow

- 1. Input data are not passed all validations and then user choose cancel the action then use case ends in failure.

Reward Campaign

Requirement Definition

Business rules controlling reward and redeem transactions are set up as Rules in “Campaigns”.
Customers enjoy different reward types depending on the type of card (Account/CIF) they hold and the details of the transactions.
A single transaction can trigger multiple concurrent award programs.
Groups of outlets can operate their own outlet-specific Campaign Rules with different rules and periods per Campaign Rule.
Type of campaign in OLS:

Award on every transactions: The reward is determined at the time the transaction is processed in OLS. Campaign structure as bellow:

[Image Removed]

Accumulate then Award: In an “Accumulate then Award” campaign, the reward depends on the customer’s total spend or number of transactions performed … over a period. Campaign structure as bellow:

[Image Removed]

Auto redemption Campagin: Some campaigns, such as cash rebate or frequent flyer mile campaigns, require that the awarded quantities (cash rebates, frequent flyer miles or other partner points) be “redeemed” and sent to an external (destination) system – Card, deposits or partner airline, etc – in order to credit the customer’s account in the destination system.
Combination of all above campaign type: Some campaign, such as welcome campaign, require that the awarded from customer’s total spending and the awared quantities be “redeemed” and sent to an external system.

Process Flow

Trigger

Pre-Conditions

Users have to have the access rights in Campaign moudle in order to can view/update or approve these records.

Wireframe

Refer wireframe on figma.

Business Rules

- - - 1. Click on “Campaign” icon in Main Menu to bring up the summary list as illustrated in section Wireframe

Click on Add button ([Image Removed]) in the screen to bring up the edit form; clicking on the MoreOutLined icon (⋮) then click on Edit icon (!) also brings up the same edit form. The edit form Campaign is illustrated in section Wireframe
Campagin Rule as a subtab of active campaign when user click to view any active campaign. User can directly create new campaign rule of selected campaign instead.
Screen descriptions


Index	Field (EN/VN)	Description	Data type
Create/Edit mode
	Campaign ID */ Mã chiến dịch	Uniquely identifies the Campaign: system generated or entered by user	X(10)
	Campaign Name*/Tên chiến dịch	Name of the campaign, used in drop-downs. Must include at least 10 non-space characters	X(50)
	Campaign Owner/Người sở hữu	Text string for user reference only	X(50)
	Campaign Description/ Mô tả chiến dịch	Description for user reference	X(500)
	Campaign Type/Loại chiến dịch	Campaigns are either “Base”, which are basic campaigns that generally apply across the board and a core part of the product, or “Tactical” campaigns, which are short-term campaigns with specific objectives – e.g. to boost the month’s spend in foreign currency, etc	Check box Default none. Select one Lookup data from “code_management” table where code-type is “campaing-type”. Refer "list-by-code-type" API under "Master data" with type code is" campaign-type"
	Campaign Target
	Target Active Customer Count /	This is used for Campaign insight The total targeting customer in the campaign.	9(10) Should be greater than 0 if provided
	Target Average Transaction Value/	This is used for Campaign insight to compare actual value with targeting value. The total targeting total spending in the campaign.	9(14,2) Should be greater than 0 if provided
View mode: Display all field of create mode and add following fields:
	Campagin Period/Thời gian hiệu lực của chiến dịch	This shows earliest Rule start date and the latest Rule end date in this campaign. These dates are derived from the actual rules in the Campaign and not derived	Display and enable for view mode only
	Number of Rules in Campaign/ Số quy tắc trong chiến dịch	Dynamically computed when screen is in display mode, shows the count of number of Rules in this campaign	Display and enable for view mode of active record only
	Campaign Rule tab: A sub tab to include all campaign rule belong to this CP. This appear when view any active CP.

Post-Conditions

Exception Flow

Reward Campaign Rule

Requirement Definition

1. Campaing Rule are used to define the business rules for giving a reward, or defining the conditions for redemption of a reward. Use a campaign rule also to define the rules for Load transactions.
2. Each campaign rule is comprised of the campaign rule header (as defined in this screen), the campaign rule master where some common parameters for reward calculation are set, and the Campaign Rule Formulas where the actual reward formulas are defined.
3. The Pool to which the result of the Campaign Rule Formulas are posted is set up in the Pool Relationship tab. The Transaction Link tab is used to link this scheme to all the transactions to which this scheme is to apply.
4. In this version we support following Campaign Rule type:
Award
Redeem
Adjust
Item Redemption
Counter Extract and Process
Redeem Extract and Process
Transaction Extract and Process
1. In this section, we just focus on the rule type which will go through Campaign Rule to check criteria and get reward points: Award/Redeem/Adjust

Process Flow

Trigger

Pre-Conditions

- 1. Users have to have the access rights in Campaign Rule moudle in order to can view/update or approve these records.

Wirefame

Refer to Figma.

Business Rules

- - - 1. Click on “Campaign Rule” icon in Main Menu to bring up the summary list as illustrated in section Wireframe
      2. Click on Add button ([Image Removed]) in the screen to bring up the edit form; clicking on the MoreOutLined icon (⋮) then click on Edit icon (!) also brings up the same edit form. The edit form Campaign is illustrated in section Wireframe
      3. Campaign Rule Screen can be display as a submodule of Campaing module as well
      4. Screen description for Edit/Create mode


Index	Field (EN/VN)	Description	Data type
Choose rule type to configurate campaign Rule
	Choose Rule type	Click on "Create" button to bring up main page. User must to choose"Award/Redeem/Adjust rule type" to go to next step. If Rule type is not selected user must to select existing template to continue otherwise "Next" botton is disbale". If user choose "Award/Redeem/Adjust" rule type then UI/UX of award rule type is displayed. Rule type is getting from	Radio button Rule type is getting from "Code_Managemnt" table. Refer "list-by-code-type" API under master data with code type is" rule-type"
Step 1: General information
	Campaign ID */ Mã chiến dịch	The Id and Campaign Name of the campaign to which this Rule belongs	Display if rule under campaign module. Drop-down if create fromseparately screen. Lookup value from Campaign Table. Refer to "Campaign"API under Campaign Management
	Campaign Rule ID*/Mã quy tắc chiến dịch	Rule identifier. Support system-generated. For reference only	X(10)
	Campaign Rule Name*/Tên quy tắc chiến dịch	Name of this Rule, for easy user reference	X(50)
	Description/ Mô tả	Long description of this Rule, for user reference	X(500)
	Rule Type*/ Loại quy tắc	The rule type which user selected on step 0	Display
	Effective Date From*/ Ngày bắt đầu hiệu lực	Apply this rule only to transactions with Transaction Date/Post Date (depended on effect rule based on between the Start and End Dates (inclusive) – the “Effective Period”.	Date
	Effective Date To*/Ngày hiệu lực kết thúc	All “Effective Periods” defined by “Start Date” and “End Date” always start at 00:00:00 and end at 23:59:59 midnight of the respective dates. To date must equal or greater than from date	Date
Step 2: Rule setting : If madatory fields in step 1 are not provided then step 2 is blocked Rule Detail
	Effective Period is Based On*/ Hiệu lực dựa trên	Determining whether the transaction being processed is within the Rule Effective Period is by using either the Transaction Date in the transaction data, or the system batch date (which is used as the Post Date for transaction processed during the day)	Radio button. Default "Transaction Date". Lookup value from "Code_Management" table. Refer to "get-by-code-type" API under master data with code type is "date-to-use-txn"
	Pool */Pool	The Reward Pool on which the result of this rule will be applied (i.e. the Pool awarded to, redeemed from, etc) Evoucher pool is applicable for Award Rule Type only	Drop-down. Select one. Lookup value from "Pool_Definition" table. Refer "Pool Definition" API under Campaign Management.
	Item Code/Vật phẩm	Condition field This is only active and required when Evoucher Pool is selected in the previous step	Drop down Select one Get active eVoucher item from Item master screen.
	Message Template ID/Mẫu tin nhắn	Message template containing the message text for sending an SMS or Email if this Rule is hit (depending on the template type) or to return the text from the message template in the response message to and online request. The message templates support a range of placeholders including all data elements in the transaction context, Customer and Account records	Drop-down. Select one API: =tbd=
	Stop if criteria met/Dừng tặng thưởng khi thỏa mãn điều kiện	If this is selected to Yes, the current transaction will not be processed against other Rules linked to the TC of the current transaction if the criteria in this Rule are met.	Switch botton. Defaut OFF
	Do not update pool/Không cập nhật pool	If this is selected, the Pool Balance is not updated with the Result of Formula calculations of this Rule even if the Criteria are met. This is usually set if the Rule is intended only for Counter Update or Attribute update and not to give the actual reward.	Switch botton. Defaut OFF
	Link Transaction Code * + 1. At least one transaction code must be provided 2. On the same campaign rule ID then transaction code must be unique 3. One the same combination of Rule Type and Transaction Code then Execution Sequence must be unique. 4. Reversal TC is not allowed for Adjustment Rule Type 5. Reversal TC is not allowed for reward Evoucher Pool In this part the system support “Quick add” feature for Transaction Code to allow a more efficient way to set up rules
	Add linked transaction code/Thêm mới mã giao dịch liên kết	Click on “Add” button to add linked TC to the rule. Multiple TCs can be linked to the Rule. TCs can be removed from the panel by clicking on the delete button.	Button
	Transaction Code*/Mã giao dịch	This field is for selecting the Transaction Code to trigger this Rule. When a TC is selected, all Rules linked to the TC, if any, will be listed in the panel “View Other Rules linked selected TC”, together with the current Rule, in the Execution Sequence number order. Take note that TC must be unique on each Campaign Rule	Drop-down. Select one. Lookup value from "Transaction_Code" table. Refer "OLS Transaction Code" API under Campaign Management
	Execution Sequence*/Trình tự thi hành	Execution Sequence of the Campaign Rule.	9(04) Should be greater than or equal to 0 if provided
	View Other Rules linked Selected TC	Click on this option to view all Active Campaign Rule in the system which under the same Rule type linked to the transaction code.
	Add new transaction code/ Thêm mới mã giao dịch	Quick add feature to support user add Transaciton Code from this screen. The new transaction will be automatiom approved when campaign rule is approved	Button
Step 3: Rule Criteria : If madatory fields in step 2 are not provided then step 3 is blocked Please refer more detail in FSD section 4.12 Rule Criteria. Take note that we must to support Include Counter Definition/Attribute Definition/Code Maintenance date for in-line editing and approval with the Rule.
Step 4: Formula setting
	Amount to use This is condition step. If campaign rule include award formula (F1, F4, F6, F8) then this step is required.
	Amount to Use in Formula (A)*/Giá trị sử dụng (A)	Derives the Amount A to use in Formula The result of this operation is used as Amount in Formula selected in this Rule	Drop-down. Select one. The drop-down inclues all numberic attribute AND all active counter (all of current/previous/before last bucket) AND lookup value from "Code_Management" table where code type is "amt-to-use-formula"
	Cap A not more than/A không vượt quá	Caps the Amount A to use in Formula to calculate the Result	9(14,2) Should be greater than 0 if provided
	Cap per/Giới hạn trên	Conditon field. It is required if Cap A not more than is provided	Drop-down. Select one. Lookup value from "Code_Management" table
	Cap-tracking Counter/Giới hạn trên bộ đếm	Condition field. This field is actived and required only when counter is selected on "Cap per"	Drop-down. Select one. Lookup value from "Counter_Definition" table with currently counter bucket only. Refer"Campaign Counter Definition" API under Campaign Management.
	Apply after Cap value/ Áp dụng thưởng sau giá trị giới hạn A	Condition field. This filed is active and required when “Cap per” is provided	Switch button. Default OFF
	Formula result is rounded*/Kết quả của công thức là	Choice of rounding method, select one: Down/To Nearest/ Up	Drop-down. Select one. Lookup value from "Code_Management" table where code type is"formula-rounded". Refer" get-by-code-type" API under Master data.
	Award limit: This is optional step. This sets the cap on the sum of Result from the formula set up in Campaign Rules. If the Result from Campaign Rules exceeds this cap, then this cap is used as the Result.
	Add Award Limit	Click to add limitation of the result On each Campaign rule just only one “Give at least” limit is applied. Can have more than one “Give No more than” limit are applied	Button Can’t add new limitation if all required field in currently limitation configuration are not provided.
	Give*/Tặng	Drop-down to select the limit type to sets the Cap of sum the result: * At Least * Nore More Than	Drop-down. Select one. Lookup value from "Code_Management" table
	Cap value*/Giá trị giới hạn	Limit value can be fixed value as numberic format filed or Attribute value of numeric atribute. Must only one value is provided. If fixed value is provied then "attrbite list" is inactive and vice versa	Fixed value: 9(14,2) Should be greater than 0 if provided Attribute value: Drop-down. Select one Lookup from “Attribute_Definiton” Table where data type is number” Refer “Attribute Definition” API under Code Maintenance
	Limit result to/Giới hạn theo	Condition field. This field is actived and required when give "No more than" only since “At least” if just apply for per campaign Rule only The drop-down list to select the limit result to as following : * Per Campagin Rule * Ask Tracked in Counter	Drop-down. Select one. Lookup value from "Code_Management" table
	Counter Id/Bộ đếm	Condition field. This field is active and required when "As tracked in counter" is selected only	Drop-down. Select one. Lookup value from "Counter_Definition" table to list all active point counter (filter by "counts" column). Refer "Campaign Counter Defintion" API under Campaign Management
	And Triger Alert/Mẫu thông điệp cảnh báo	Condition field. This field is actived when "As tracked in counter" is selected only	Drop-down. Select one.
	Sent to/Gửi cảnh báo tới	Condition field. This field is actived when "As tracked in counter" is selected only	Drop-down. Select one.
	When Counter reaches/Khi giá trị bộ đếm chạm tới	Send the notification when counter value is reached the inputed value	9(14,2) Should be greater than 0 if provided
	Formula Detail Refer Campaign Rule formula
Step 5: Contributor Details Optional step Refer Contributor

Post-Conditions

Amount to use feature with Transaction Processing.

[Image Removed]

Exception Flow

Campaign Rule Criteria

Requirement Definition

Rule criteria are divided into 5 categories for ease of maintenance:


Customer	Account	Transaction
Atttribute	Counter	Merchant

Campaign Criteria setup is the next step of campaign rule setting if Campaign Rule require transaction through campaign rule to validate criterions.

Process Flow

[Image Removed]

Trigger

1. Exsiting Campaign require at least one campagin rule validate criterions.

Pre-Conditions

Users have to have the access right in the Campaign Rule moudle in order to able to view/update or approve these records.
Assume that all criteria are defined as attribute and appear in right panel to user can drag/drop to setup. ==TBD==

[Image Removed]

Assume that each criteria has its own data type and condition list as well. Each condition, user can setup according filter value so that when user drag criteria to setup then filter value will be display based on selected data type and selected condition.

Wireframe

[Image Removed]

Figure 1 - Query builder

[Image Removed]

Figure 1 – Rule criteria

[Image Removed]

Figure 2- Drag criteria into Rule

[Image Removed]

Figure 3 – Rule criteria screen after complete setup

Business Rules

Each of these criteritions are accessed directly by drag/drop on the right Criteria panel as illustrated in the wireframe.
OLS system will use Query Builder to build query for Rule Criteria.
All criterions will be listed on selection criteria panel (right panel). User can drag/drop criteria from right panel to set up rule. Criterion list will be defined as attribute so that user can define needed criteritions.
OLS system support AND or OR condition between difference criteria groups on the same campaign rule. The relationship operator on each group will be applied for all criteritions on the group. User can setup only one or many group on the same rule but OLS system just support the same operator condition bettwen groups such as all are OR conditions or all are AND conditions.

For example:

Rule 1:

Group 1 OR Group 2 OR Group 3

Rule 2:

Group 1 AND Group 2 AND Group 3.

Introduce NOT toggle switch to support exclusion criteria.
User can put the key word to search criteria on Right Criteria panel.
Each criteria can be used one more time in the same campaign rule.
Screen description:


Index	Field (EN/VN)	Description	Data type
	[Image Removed]	Click to add new criteria	Button
	[Image Removed]	Depended on the purpose of each campaign rule and the criterions list need to be setup to allocate and arrange all criterions into only one or many group. Click on “[Image Removed]” button to create new group.	Button
	[Image Removed]	This button is used to exclude all the coming transaction meet the rule criteria. Switch NOT button are applied on combinaiton of all group OR on all criteria on each group.	Switch button
	Right panel	List all active criteria on the system. Each criteria per category will be defined as an attribute. See more on #9. [Image Removed]	View only
	Drag/Drop criteria	Each criteria can be drag one more time on each CP rule. The operator and filler value for each criteria will be display base on data type of selected criteria. See more detail on #10. [Image Removed]	Action
	[Image Removed]	Click to delete criteria	Button
	[Image Removed]	Operator between difference groups on the same campagn rule OR operator between difference criterions on the same group per each Campaign Rule.	Drop-down
	Criteria	Criteria Structure: Take note: Criteria is getting from Campaign Rule Criteria Definition API Operator follow by data type of each Criteria Input type is getting from Code_Management table by code type is “criteria-input-type”. Each operator have separately filter value

Right panel

In this phase, assume that all criteria has been defining as an attribute. We just focus on query builder for this scope.

Assumed that data source of each drop-down filter field are defined as pre-condition === tbd===

Assumed that data sources which is used to verify whether the incoming transaction meet criteria/doesn’t are taking from data lake/ data warehouse instead get directly from DB as currenlty. That mean for TP proceed validate from incoming transaction with data lake instead directly take from DB as currently. ===TBD====

Some use case for each criteia group:


Index	Use case	Criteria group
	Transaciton is in A transaciton category is combination of more than one transaction criteria. This conditon checks whether the incoming transaction is in any selected Transaction Category. Use case: Requirement: On statement cycle: Dining txns, local currency + DCC -- award x1 Entertainment txns, local currency + DCC --award x2 Dining txns, foreign currency + not DCC -- award x3 Entertainment txns, foreign currency + DCC -- award x4 In existing implementation, we need to have separate counter ids for these 4 cases So we need 4 rules to update the 4 counters. If the 4 conditions are are captured as TxCats: TxCat1 TxCat1= Dining txns, local currency + DCC TxCat2 = Entertainment txns, local currency + DCC TxCat3 = Dining txns, foreign currency + not DCC TxCat4 = Entertainment txns, foreign currency + DCC We just need one Counter, Entity = Acct-TxCat We just need one CEP to extract the one counter and just need one award Rule, using F6 to fulfilment this requirement.	Transaction criteria
	Counter criteria. Note that the Counter criteria list is dynamic and is from Counter Definition with N bucket per each counter. That mean for each counter must include N criterions per each counter bucket (Current Bucket, Previous Bucket, 1 Period Befor Last….N Period Before Last). Since the Counter value is one numeric value, if one counter criterion is selected, then the operator should follow the operator listing of the Number data type.	Counter criteria
	Last Transaction Date Customer's Tenure Is Between Transaction was done in(Country, currency)	Transaction criteria
	MCC group Store group Chain group Corporation group	Transaction criteria
	ATG criteria	Account Criteria
	Attribute Criteria Note that the Attribute criteria list is dynamic and is from Attribute Definition. Each Attribute ID have separately data type therefore the operator of attribute ID should follow data type of selected Attribute.	Attribute Criteria

Query builder structure

For example:

+ Account type criteria has data type as string and filter value is account type list from PRODUCT_ACCOUNT_TABLE.

+ Transaction description criteia has data type as string but filter value is enterted by user.

+ Counter criteria has data type as numberic and filter value is numeric attribute value from ATRIBUTE_VALUE table OR counter criteria can have filter value is fixed value which is entered by user.


Index	Data type	Filter condition	Desciptions	Filter value Descriptions
	String	Is equal to (=)	This condition checks whether the comparison value equal with the filter value. For example: [Image Removed]	Depened on selected input type then input type of filter value may be text box or drop-down list. Should not be case sensitive.
	Is NOT equal to (<> )	This condition checks whether the comparison is not equal with the filter value. [Image Removed]
	Is empty ( NULL)	This condition checks whether the comparison value is empty. [Image Removed]	MUST not display filter value field and input type
	Is NOT empty (Not null)	This condition checks whether the comparison value is NOT empty. [Image Removed]
	Contains	This condition checks whether the comparison value contains the filter value. [Image Removed]	~~Should be a textbox for filter value.~~ Depened on selected input type then input type of filter value may be text box or drop-down list. In case input type is “value”, use input tag for each filter value (in case multiple filter value). Use “” to match zero or more occurrences of the preceding subexpression (e.g. xyz could correspond to ~~"xz",~~ "xyz", "xyyz", etc.) Should not be case sensitive. For example [Image Removed]
	Does not contain	This condition checks whether the comparison value DOES NOT contain any filter value. [Image Removed]
	Is in	This condition checks whether the comparison value is in one of the filter value. [Image Removed]	1. Depened on selected input type then input type of filter value may be text box or drop-down list. Should not be case sensitive. In case input type is “value”, use input tag for each filter value (in case multiple filter value) For example [Image Removed] 1. If filter value is drop-down then comparison value must be IN/NOT in selected list.
	Is NOT in	This condition checks whether the comparison value is NOT in all of the filter value. [Image Removed]
	Begins with	This conditon checks whether the comparison text begins with the filter value. [Image Removed]	In case input type is “value”, use input tag for each filter value ( in case multiple filter value) For example [Image Removed] Should not be case sensitive
	String	Ends with	This conditon checks whether the comparison text ends with the filter value. [Image Removed]
	Does not begin with	This conditon checks whether the comparison text does not begin with the filter value. [Image Removed]
	Does not end with	This conditon checks whether the comparison text does not end with the filter value. [Image Removed]
	NUMBER	Is equal to (=)	This condition checks whether the comparison value equal with the filter value. [Image Removed]	Filter value depened on selected input type One number filter value. The assumption is that filter values can be entered by the user or selected from a drop-down list. E.g The number attribute list from Attribute Definition or a fixed value entered by the user
	Is NOT equal to (<> )	This condition checks whether the comparison value is NOT equal with the filter value. [Image Removed]
	Is less than (<)	This condition checks Comparison value is less than filter value. [Image Removed]
	Is equal to or less than (<=)	This condition checks whether the comparison value is less than or equal to filter value. [Image Removed]
	Is greater than (>)	This condition checks whether the comparison value is greater than filter value. [Image Removed]
	Is equal to or greater than (>=)	This condition checks whether the comparison value is greater than or equal to filter value. [Image Removed]
	Is between ( Min value <= X <= Max value)	This condition checks whether the comparison value is greater than or equal min filter value AND comparison value is less than or equal to max filter value. If Min value is not provided then this conditoon checks whether the comparison value is less than or equal Max filter value. If Max filter value is not provided then this condition checks whether the comparison value is greater than or equal to Min filter value. [Image Removed] [Image Removed]	Both Min/Max filter value should be number value At least Min or Max filter value should be provided. The assumption is that filter values can be entered by the user or selected from a drop-down list. E.g The number attribute list from Attribute Definition or a fixed value entered by the user
	Date	Is on or before	This condition check whether the comparison date is less than or equal to filter date. [Image Removed]	Fixed filter date. Date picker should be allow to choose past time/current time and in the future time.
	Is on or after	This condition checks whether the comparison date is greater than or equal to filter date. [Image Removed]	Fixed filter date. Date picker should be allow to choose past time/current time and in the future time.
	Is between date range with date format parameter	* + - * 1. TTwo date picker fields specify the date range of the comparison value must be within in selected date. 1. Third dop-down field is “Date format to Use”. This field is used to locate the format of the comparison date and date range filer before compare. 2. The system will convert all of filter date value and comparison value into selected date format before compare. 3. If Min filter date is not provided then this condition checks whether the comparison date is less than or equal to Max filter value. If Max filer date is not provided then this condition checks whether the comparison value is greater than or equal to Min filter value. The “Date format To Use” is used to locate the format of the comparison date and selected date before compare. * If DTU is Day of month (DD) or Month only (M) or Year only (Y) then just use day/month/year of the source date value and selected date to compare. * If DTU is Day and Month (DM) then just use day and month of the source date value and selected date to compare. * If DTU is Month and Year (MY) then just use Month and Year of the source date value and selected date to compare. * If DTU is Date (D) then use the source date value and selected date to compare * If DTU is Quarter (QY) then use the quarter (including year) of the comparision value and selected date to compare. * Some scenarios that use this operator as following: For example 1: Account open date from 01/07/2023 to 31/08/2023. [Image Removed] For example 2: Customer’s birthday from Jul 01 to Jul 15 [Image Removed]	Both Min/Max filter value should be date value. At least Min or Max value should be provided. Date picker should be allow to choose past /current and in the future time. Max value should be greater than or equal to Min value.
	Is fixed date	This condition checks whether the comparison value is equal to filter value [Image Removed]	Fixed filter date. Date picker should be allow to choose past time/current time and in the future time
	Is null	The comparison value must be null value	There is no filter value
	Is not null	The comparison value must be null value
	Is betweenperiod from N (min to max value).	[Image Removed] 1. This condition checks whether the comparison date (based on selected date format ) is in the time period required from "Compare with date" , where the period can be in days, months ,quarter or years ,as selected in the fourth drop-down field. 2. The periods can be in future (aways) or in the past (ago) from “Compare with date”. 3. Date format to use (DTU): The system will convert comparison value and “Compare with date” into selected date format before compare. * If DTU is Day of month (DOM) : Use day only for both source value and “compare with date” * If DTU is Month only (MO): Use Month only for both source value and “compare with date” * If DTU is quarter (QO) then use quarter (including year) for both source value and “compare with date”. e.g: sysdate is 20/05/2024 then use 01/04/2024 to process. * If DTU is Day and Month (DAM) Use day and month for both source value and “compare with date” e.g: Sysdate is 20/01/2024 then use “20/01” to process. * If DTU is Month and Year (MY) Use month and year for both source value and “compare with date”. e.g: Sysdate is 20/01/2024 then use “01/01/2024” to process. * If DTU is Date (DDMMYY) then use full value of source value (depend on selected criteria) and “compare with date. e.g AOD is 20/01/2024 then use “20/01/2024” to process Some examples to use this critera Example 1 : Post date is on 1 months ago from batch date [Image Removed] Example 2: Transacting Account Tenure Is Between 1 and 3 years ago ( from transaction date) [Image Removed] Example 3: Next AOD Anniversary is on 10 days away. (From base date) [Image Removed]	* + - * 1. WWhen this condition is selected then Min/Max filter field , “Compare with date” drop-down,”Date format “ drop-down and “Period” drop-down are actived and required. Min/Max filter fields are two numeric input fields specify the number of periods. Max/Min value should be integer value. Max value should be equal to or greater than Min value. At least Min or Max value should be provided. 1. The first drop-down is “Compare with date”. This value is used to locate the date will be used to compare with the comparison date before check with period. Following are compare with date list are avaliable for this condition: + Base date (Depend on Effected base on in Rule configuration). + Sysdate + Transaction date + Post Date 1. The second drop-down is used to select the date format to use (DTU). The system will convert “Compare with date” value and comparasion date into selected date format before compare. Date format can be : + Day of month + Month only + Year only + Quarter only + Day and Month + Month and Year + Date 1. The next filed is Period drop-down. Following are period list are avaliable for this condition: + Days ago + Months ago + Quarters ago + Years ago + Days away + Months away + Quarters away + Years away 1. “Period unit” is applicable for each selection “Date format to use” fied as following link: https://prnt.sc/yp3PsIjWSiLL
	Is the day of week	This condition checks whether the comparison date falls on selected day of the week. [Image Removed]	When this condition is selected then second field is a drop-down that allow multipe from the list day of the week.
	Time	Is between	Two time picker fields specify the time range of the comparison value must be within in selected time. If Min filter date is not provided then this condition checks whether the comparison value is less than or equal to Max filter value. If Max filer date is not provided then this condition checks whether the comparison value is greater than or equal to Min filter value. [Image Removed]	Time picker should be allow to choose from 00:00 upto 23:59. At least Min and Max value should be provided. Max value should be greater than or equal to Min value.
	Boolean	Is	This condition checks whether the comparison value is equal selected filter value [Image Removed]	When this condition is selected then second field is a drop-down include TRUE/FALSE value.

Post-Conditions

1. User able to proceed next step to complete campagin rule setup.

Exception Flow

- 1. Input data are not passed all validations and then user choose cancel the action then use case ends in failure.

Campaign Rule Formula

Requirement Definition

All most campaign rule formulas are utilized to configure the reward formula that end-users will receive after completing a transaction.
Sometimes we was using campaing formula to update the counter value or attribute value as well.
In this version, we support Formula 7 as query builder form and introduce drag/drop UI for constructing rules.

Process Flow

Trigger

Pre-Conditions

Wireframe

Business Rules

See more detail in attached file

[Image Removed]

Post-Conditions

Exception Flow

Campaign Rule – Contributor Settings

Requirement Definition

In case Campaign Rule does not use the Rate Table, and the earning under the rule is to have funding contributors other than the Merchant of transaction (the retailer) then user use this step to bring up the list of Contributors configured for the Rule.
If the payment transaction triggers a reward (campaign rule), and if the merchant is contributing to the funding of the reward, then the merchant is also a “contributor” for that award transaction.

Process Flow

[Image Removed]

Trigger

1. Campaign require a list of Contributors configured for the Rule.

Pre-Conditions

User have to have the access right in the Campaing Rule moudle to can add/update contributor of the rule.
The merchant as a “contributor” of the award transaction should availble on OLS system.

Wireframe

- 1. Contributor setting

[Image Removed]

Business Rules

- - 1. Contributor setting is the last step of campaign rule setting if Campaign Rule require a list of contributor for the rule.

If Contributor required has not been defined, click on next step to bring up the Contributor setting is illustrated in section Wireframe.
Click on Add button ([Image Removed]) in the screen to bring up the create form; click on Edit button in the screen to bring ip the edit from as illustrated in section Wireframe.
Screen descriptions


Seq	Field (EN/VN)	Description	Type
	Contributor Detail / Chi tiết phân bổ chi phí	This is the Contributor setting panel header.	Display
	Add a Contributor/ Thêm mới	This is the edit row for defining a Contributor’s percentage	Button
	Contributor*/ Đơn vị phân bổ	Selecting the Contributor	Drop-down Select one Look up value from Chain screen (Chain table). Refer “Chain” API under Merchant Management.
	Contributor Percentage*/ Phần trăm phân bổ	Entering the Contribution Percentage	9(5, 2) Should be greater than 0 if provided
	Absorb Remainder */ Hấp thụ số dư còn lại	Selecting whether this Contributor is to absorb any remainder (TRUE or FALSE) after allocating the amounts by percentage to other Contributors.	Swich button Default OFF
	[Image Removed]	Clicking Click on the “[Image Removed]” icon removes the Contributor row	Button

The total contribution must be 100%.
Contributor must be uinique on each campaign rule.
If contributors are configured then must have one and only one contributor is “absord remider”.
If there is no contributor configured for the Rule then the Chain of the incoming transaction is also a “contributor” for that award transaction. ( Default as Absorb Remainder)

Post-Conditions

TP posted transaction based on contributor setting. The transaction is split into each Contributor for that transaction.

Exception Flow

- 1. Input data are not passed all validations and then user choose cancel the action then use case ends in failure.

Counter Extract & Process (CEP) Request

Requirement Definition

- - 1. Some campaigns require the spend or count (number of transactions) to be accumulated over a period of time and then the total at the end of the period is used to compute the reward entitlement. Such a campaign requires a rule to accumulate spend in a counter, and at the end of each month a rule to use the total spend for the month in the counter to calculate the reward.Such a campaign would involve setting up an accumulation rule (Rule Type = Counter Update), a Rule to extract the Counter based which to form the transaction to compute the award amount (Counter Extract and Process or CEP Rule), and the award/Redeem Rule for specifying the award computation formula.

Process Flow

Trigger

Pre-Conditions

User have to have the access right in the Campaing Rule moudle to can add/update CEP Rule.
All drop-down value must avaiable in the system.

Wireframe

Please refer figma to get more detail.

Business Rules

- - 1. CEP is one of rule type of Campaign Rule. CEP Rule can be created/updated under Campaign Moduel as a parr of campaign or Create from "Campaign Rule" screen under "Campaign Management" module.
    2. Click on Add button ([Image Removed]) in the screen to bring up the create form. User must to choose"Counter Extract and Process" Rule type to go to next step. If Rule type is not selected user must to select existing template to continue otherwise "Next" botton is disbale". Click on Edit button in the screen to brings up the edit from as illustrated in section Wireframe. When the Rule Type in the Rule Header is CEP, the following is displayed for specifying parameters based on which to extract the Counter values and to form transactions for triggering award Rules:


Index	Field	Description	Data type
Step 1: Generation information. This step setup the generation information of CEP rule and mandatory step. Don't. Next step is blocked if all required field in this step are not provided
	Campaign ID*/ Mã chiến dịch	The Id and Campaign Name of the campaign to which this Rule belongs	Display if rule under selected campaign. Drop-down list if create from separately screen. Lookup value from Campaign Table. Refer to "Campaign"API under Campaign Management
	Campaign Rule ID*/Mã quy tắc chiến dịch	Rule identifier. Support system-generated. For reference only	X(10)
	Campaign Rule Name*/Tên quy tắc chiến dịch	Name of this Rule, for easy user reference	X(50)
	Description/Mô tả	Long description of this Rule, for user reference	X(500)
	Rule Type*/ Loại quy tắc	Counter Extract & Process [CEP]	Display. Refer "get-by-code-type" API under master data with code type is"rule-type"
	Effective Date From*/ Ngày bắt đầu hiệu lực	Apply this rule only to transactions with Transaction Date/Post Date(depended on effect rule based on between the Start and End Dates (inclusive) – the “Effective Period”	Date The date format must adhere to the configured format
	Effective Date To*/Ngày hiệu lực kết thúc	All “Effective Periods” defined by “Start Date” and “End Date” always start at 00:00:00 and end at 23:59:59 midnight of the respective dates. To date must equal or greater than from date	Date The date format must adhere to the configured format
Step 2: Rule setting
	Log transaction under this store*/ Ghi nhận giao dịch cho cửa hàng/đơn vị	This value will be defaulted to the "Merchant". All award and adjust transactions arising from this Rule will be logged with this Store as the merchant	Drop-down. Select one. Lookup data from "Store" table. Refer "Store" API under Merchant Management
	Counter to extract */ Kết xuất từ bộ đếm	The counter to extract, the value of which is to be used as the Transaction Amount in the Formula in this Rule	Drop-down. Select one. Lookup value from "Counter_Definition" table. Refer "Counter Definition" API under Campaign Management
	Bucket to extract */Kết xuất từ kho	The choices are: - Current Bucket (default) – will extract the latest bucket of the Counter - Previous Bucket – will extract the bucket ending the previous period, where the period is as defined in the Run Schedule - Period before Last – will extract the bucket ending the period before the last period, where the period is as defined in the Run Schedule Bucket value extracted is used as transaction amount in award Formula	Drop-down.Select one. Lookup data from "Code_Management" table where code type is "counter-bucket". Refer "get-by-code-type" API under master data
	Rule type to process*/ Loại quy tắc chiến dịch sử dụng	The transaction formed with the parameters in this CEP request are posted with this to system locates the rule type to process	Drop-down. Select one. Lookup value from "Code_Management" table where code type is "cep-trigger-rule-type". Refer "get-by-code-type" API under master data
	Transaction Code */Mã giao dịch	The transaction formed with the parameters in this CEP request are posted with this TC: system locates selected trigger Rules linked to this TC to process	Drop-down. Select one. Lookup value from "Transaction_Code" table. Refer to "OLS Transaction Code" API under Campaign Management
	-ve Bal. Adjust. Transaction Code/Mã giao dịch điều chỉnh âm	In the event the counter value extracted (Counter to Extract) is negative, it will be posted as a negative adjustment if this TC is provided, based on the Rule linked to this TC	Drop-down. Select one. Lookup value from "Transaction_Code" table. Refer to "OLS Transaction Code" API under Campaign Management
	Adjustment Transaction Reason/ Lí lo điều chỉnh	Condition field. This field is actived and required when Adjust TC is selected	Drop-down Select one Lookup value from "Reason_code" table. Refer "Reason Code"API under Code maintenance
	Adjustment Transaction Description/ Mô tả giao dịch điều chỉnh	The transaction description of negative adjustment transaction Condition field. This field is actived and required when Adjust TC is selected	X(50)
	Account with blocked Card /	The extracted Counters for generating transactions to process will include Counters of PA with Blocked Code or not, depending on the selection in this field. The default is to include. Condition filed. This filed just be actived and required when Account entity counter OR Card entity counter is extracted.	Radio button Default Include Refer “get-by-code-type” API under master data where code type is “cep-ac-block-card”
	Account with No Counter in Period	The extracted Counters for generating transactions to process will include a record for PA with no Counter Bucket and with Counter Bucket of balance 0, depending on the selection in this field. The default is to include. Condition filed. This filed just be actived and required when Account entity counter OR Card entity counter is extracted.	Radio button Default Exclude Refer “get-by-code-type” API under master data where code type is “cep-ac -no-counter”.
	Post Transactions under PA Account selected based on	If Counter is a customer-centric Counter and there are multiple PA Types included in the counter bucket extraction, the PA Type to use in the transaction posting can be selected based on the any of the following: * Account with most recent customer-initiated transaction * Account with highest spend in the past month + month-to-date * Account with lowest spend in the past month + month-to-date * Account based on ATG of Pool Note: This is conditon filed. Just be actived and required if customer entity counter is extracted.	Drop-down Select one Refer “get-by-code-type” API under master data where code type is “cep-ac-posted”.
	Execution Sequence Number /Thứ tự thi hành	The execution sequence to get the priority to run request.	9(4) Should be greater than 0 if provided
	Run schedule: CEP Rules are evaluated for execution by a CEP Batch which is scheduled to run every day as part of the end-of-day batch stream. This parameter determines when this Rule will be executed by CEP Batch The tabs are: Day – Month – Annulaly – N days after AOD – Statement Cycle Lookup value from “Code_Management” table where type code is ‘Cep-run-schedule’. Refer to ‘list-by-code-type’ API under Master Data Master
	Day	[Image Removed] * + - 1. This option includes following fields: - Repeat every: The drop-down list to select the frequency on every n day where n from 1 to 50. This is select one field. - Time of day to excute request: This field is time format field. If CEP run as an offline job then it is not used in OLS. 1. Request will occur on every n day at the selected time.	Repeat every: Drop-down Select one Get data from “Code_Management” table. Refer “get-by-code-type” API under master data with code type is “daily-repeat”. Time of day to excute request: Text box with HH:MM format.
	Month	[Image Removed] * + - 1. This option includes following fields: - Repeat every: The drop-down list to select the frequency on every n month where n from 1 to 12. This is select one filed. Refer “get-by-code-type”API under master data where code type is “month-of-year”. - Day of month: The drop-down list to select day of month the request will be occurred. The list includes 31 day from 1 to 31 - Last day of month: This is checkbox field with default as uncheck. If this field is checked then in case the last day of month is less than the “Day of month” then request will be occurred on last day of month instead. - Time of day to excute request*: The time to CEP batch job running to trigger this request. This field is time format field. If CEP run as an offline job then it is not used in OLS. 1. Request will occur on every n month on each selected day of the month and at the selected time.	Repeat every: Drop-down Select one Get data from “Code_Management” table. Refer “get-by-code-type” API under master data with code type is “monthly-repeat”. Day of month: Drop –down Multiple select Hardcoding from 1- 31. Time of day to excute request: Text box with HH:MM format
	Annually	[Image Removed] * + - 1. This option includes following fields: - Repeat every: The drop-down list to select the frequency on every n year where n from 1 to 5. This is select one filed. - Month of year: Drop-down to select month of year. The list includes 12 months of year from 1 to 12. . . - Day of month: The drop-down list to select day of month the request will be occurred. The list includes 31 day from 1 to 31. - Time of day to excute request: The time to CEP batch job running to trigger this request. This field is time format field. If CEP run as an offline job then it is not used in OLS. 1. Request will occurred every n year on the selected day and selected month.	Repeat every: Drop-down Select one Get data from “Code_Management” table. Refer “get-by-code-type” API under master data with code type is “yearly-repeat”. Month of year Drop –down Select one Hardcoding from 1- 12. Day of month: Drop –down Select one Hardcoding from 1- 31. Time of day to excute request: Text box with HH:MM format
	Statement Cycle	* + - 1. This option includes following fields: - Time of day to excute request*: This field is time format field. If CEP run as an offline job then it is not used in OLS. 2. CEP Batch extracts specified Counter on days when there is a Statement output and extracts only accounts which were statemented on that day, evaluates the value against the award Rule and adds the award to Pool in award Rule. =tbd==	Time of day to excute request: Text box with HH:MM format
	N days after AOD	* + - 1. This option includes following fields: - N parameter: CEP Batch extracts Counter on N days after the AOD of the Account. 9(2) format for N parameter. - Time of day to excute request*: The time to CEP batch job running to trigger this request. This field is time format field. If CEP run as an offline job then it is not used in OLS. 1. =TBD==	Time of day to excute request: Text box with HH:MM format

Post-Conditions

The following is a decision matrix for the possible combinations of “Counter Bucket to Extract” & “Run Schedule” for CEP batch job, where the following notation is used:
1. “Current Bucket” is the Bucket with the earliest ED greater than the current processing date ==tbd==
2. “Previous Bucket” is the Bucket with the latest ED smaller than the current processing date ==tbd==
3. “Bucket Before Previous” is the Bucket with the latest ED smaller than the Previous Bucket ED==tbd==


	Counter Bucket To Extract
Run Schedule Choice	Current	Previous	Period Before Last
* Daily	Extract Current Bucket where State = C or is NULL.	Extract Previous Bucket where State = C or is NULL	Extract Bucket Before Previous, where State = C or is NULL
* Monthly on Day N of Month
* Statement Cycle Date
* N Days after AOD
* Annually, on Day N of Month M

1. In all cases, if there is no batch run on the scheduled day, the batch is executed the next day on which there is an end-of-day batch run
2. Counter state is update when CEP extract based on Counter definition setup :
  - If counter state is update on aware then to avoid extracting the same Bucket again in the next run, the rules triggered by the CEP transaction must update the State of the extracted Bucket from “C” to “A” if CEP rule hit CP rule.
  - If counter state is update on extract then to avoid extracting the same Bucket again in the next run, the rules triggered by the CEP transaction must update the State of the extracted Bucket from “C” to “E” if CEP trigger CP rule regardess hit campaign rule or not.
  - If counter state is never updated then even CEP extract and hit CP rule then counter state still is C.

Exception Flow

N/A

Redemption Extract & Process (REP) Rule

Requirement Definition

Some campaigns require the reward amount is tracked in a dedicated Pool which is then redeemed and extracted as a cash rebate or partner points (e.g. frequent flyer miles) and output to be credited into a receiving account.
This is done using a Rule that is designed to “Redeem, Extract & Process” – i.e. and REP rule.
An REP Rule is added to the Campaign by selecting Rule Type as “REP” when adding the Rule in a Campaign set-up.

Process Flow

Trigger

- - 1. The campaigns require the system automation extract the pool balances.

Pre-Conditions

User have to have the access right in the Campaing Rule moudle to can add/update REP Rule.
All drop-down value must available in the system.

Wireframe

- - 1. Please help to refer on the figma.

Business Rules

- - 1. REP is one of rule type of Campaign Rule. REP Rule can be created/updated under Campaign Moduel as a parr of campaign or Create from "Campaign Rule" screen under "Campaign Management" module.
    2. Click on Add button ([Image Removed]) in the screen to bring up the create form. User must to choose"Redeem Extract and Process" Rule type to go to next step. If Rule type is not selected user must to select existing template to continue otherwise "Next" botton is disbale". Click on Edit button in the screen to bring up the edit from as illustrated in section Wireframe. When the Rule Type in the Rule Header is REP, the following is displayed for specifying parameters based on which to extract the balane value:


Index	Field	Description	Data type
Step 1: Generation information. This step setup the generation information of REP rule and mandatory step. Don't. Next step is blocked if all required field in this step are not provided
	Campaign ID*/ Mã chiến dịch	The Id and Campaign Name of the campaign to which this Rule belongs	Display if rule under selected campaign. Drop-down list if create from separately screen. Lookup value from Campaign Table. Refer to "Campaign"API under Campaign Management
	Campaign Rule ID*/Mã quy tắc chiến dịch	Rule identifier. Support system-generated. For reference only	X(10)
	Campaign Rule Name*/Tên quy tắc chiến dịch	Name of this Rule, for easy user reference	X(50)
	Description/Mô tả	Long description of this Rule, for user reference	X(500)
	Rule Type*/ Loại quy tắc	Counter Extract & Process [CEP]	Display. Refer "get-by-code-type" API under master data with code type is"rule-type"
	Effective From Date */ Ngày bắt đầu hiệu lực	Apply this rule only to transactions with Transaction Date/Post Date(depended on effect rule based on between the Start and End Dates (inclusive) – the “Effective Period”	Date The date format must adhere to the configured format
	Effective To Date*/Ngày hiệu lực kết thúc	All “Effective Periods” defined by “Start Date” and “End Date” always start at 00:00:00 and end at 23:59:59 midnight of the respective dates. To date must equal or greater than from date	Date The date format must adhere to the configured format
Step 2: Rule setting
	Pool to Extract*/Pool kết xuất	Pool to redeem for output as cash rebate or points posting to Destination Account. * The full amount of the Pool balance is deducted from the Pool and output to the destination account or system. For campaigns where the reward is extracted and output to destination account on a scheduled basis, a separate Pool should be defined for each Campaign.	Drop-down Select one Lookup value from”Pool_Definition” table. Refer “Pool Definition”API under Campaign Management
	Minimum Pool Balance	This is an optional field which defines the minimum number of points that a Pool must have before it is to be redeemed by the REP Batch.	9(12,2) Should be greater than 0 if provided
	Trigger Campaign rule	This option to allow REP rule trigger Campaign Rule to check criterion and computer the balance to extract If trigger CP rule option then REP will trigger redeem rule type for criterion validation and the balance to extract is smallest value of available balance and formula result.	Switch button Default OFF
	Redeem TC*	Select TC under which to post this redemption.	Drop-down Select one Lookup value from “Transaction_Code”table Refer “OLS Transaction Code” API under Campaign Management
	Redeem Transaction Description*	The text to be used in the redemption transaction record Description field.	X(50)
	Log Transactions Under This Store*	The redemption transaction generated by this Rule must be logged with a Store id, based on this selection	Drop-down Select one Lookup value from “Store” API
	-ve Bal. Adjust. Transaction Code/Mã giao dịch điều chỉnh âm	In the event the balance value extracted (pool balance to extract) is negative, it will be posted as a negative adjustment if this TC is provided, based on the Rule linked to this TC	Drop-down. Select one. Lookup value from "Transaction_Code" table. Refer to "OLS Transaction Code" API under Campaign Management
	Adjustment Transaction Reason/ Lí lo điều chỉnh	Condition field. This field is actived and required when Adjust TC is selected	Drop-down Select one Lookup value from "Reason_code" table. Refer "Reason Code"API under Code maintenance
	Adjustment Transaction Description/ Mô tả giao dịch điều chỉnh	The transaction description of negative adjustment transaction Condition field. This field is actived and required when Adjust TC is selected	X(50)
	Output Redemption As/	This drop-down contains the list of output types pre-configured in the REP batch properties file. The drop-down text describes the output to be generated from the redemption data. The currently supported outputs are:
	Run schedule: REP Rules are evaluated for execution by a REP Batch which is scheduled to run every day as part of the end-of-day batch stream. This parameter determines when this Rule will be executed by REP Batch The tabs are: Day – Month – Annulaly – N days after AOD – Statement Cycle – N months of AOD Lookup value from “Code_Management” table where type code is ‘rep-run-schedule’. Refer to ‘list-by-code-type’ API under Master Data Master
	Day	[Image Removed] * + - 1. This option includes following fields: - Repeat every: The drop-down list to select the frequency on every n day where n from 1 to 50. This is select one field. - Time of day to excute request: There are 2 drop-down to select hour from 0 upto 23 and minutues from 00 upto 59. The time to REP batch job running to trigger this request. This field is time format field. If REP run as an offline job then it is not used in OLS. 1. Request will occur on every n day at the selected time.	Repeat every: Drop-down Select one Get data from “Code_Management” table. Refer “get-by-code-type” API under master data with code type is “daily-repeat”. Time of day to excute request:
	Month	[Image Removed] * + - 1. This option includes following fields: - Repeat every: The drop-down list to select the frequency on every n month where n from 1 to 12. - Day of month: The drop-down list to select day of month the request will be occurred. The list includes 31 day from 1 to 31. - Last day of month: This is checkbox field with default as uncheck. If this field is checked then in case the last day of month is less than the “Day of month” then request will be occurred on last day of month instead. - Time of day to excute request*: The time to REP batch job running to trigger this request. This field is time format field. If REP run as an offline job then it is not used in OLS. 1. Request will occur on every n month on each selected day of the month and at the selected time.	Repeat every: Drop-down Select one Get data from “Code_Management” table. Refer “get-by-code-type” API under master data with code type is “monthly-repeat”. Day of month: Drop –down Multiple select Hardcoding from 1- 31. Time of day to excute request: Text box with HH:MM format
	Annually/Hàng năm	[Image Removed] * + - 1. This option includes following fields: - Repeat every: The drop-down list to select the frequency on every n year where n from 1 to 5. This is select one filed. - Month of year: Drop-down to select month of year. The list includes 12 months of year from 1 to 12. - Day of month: The drop-down list to select day of month the request will be occurred. The list includes 31 day from 1 to 31 - Time of day to excute request: The time to REP batch job running to trigger this request. This field is time format field. If REP run as an offline job then it is not used in OLS. 1. Request will occurred every n year on the selected day and selected month.	Repeat every: Get data from “Code_Management” table. Refer “get-by-code-type” API under master data with code type is “yearly-repeat”. Month of year Drop –down Select one Hardcoding from 1- 12. Day of month: Drop –down Select one Hardcoding from 1- 31. Time of day to excute request: Text box with HH:MM format
	Statement Cycle /Kì sao kê	* + - 1. This option includes following fields: - Time of day to excute request*: The time to REP batch job running to trigger this request. This field is time format field. If REP run as an offline job then it is not used in OLS. 2. REP Batch extracts specified Counter on days when there is a Statement output and extracts only accounts which were statemented on that day, evaluates the value against the award Rule and adds the award to Pool in award Rule. =tbd==	Time of day to excute request: Text box with HH:MM format
	N day after AOD/N ngày sau khi mở tài khoản	* + - 1. This option includes following fields: - N parameter: REP Batch extracts Counter during the end-of-day batch for all PA N days after the AOD of the PA. 9(2) format for N parameter. - Time of day to excute request: There are 2 drop-down to select hour from 0 upto 23 and minutues from 00 upto 59. The time to REP batch job running to trigger this request. This field is time format field. If REP run as an offline job then it is not used in OLS. 1. =TBD==	Time of day to excute request: Text box with HH:MM format
	N months from AOD/N tháng từ ngày mở tài khoản	This option includes following fields: * + - N parameter: REP Batch extracts balance during the end-of-day batch for all Account after N months from the AOD* of the Account. - Time of day to excute request*: There are 2 drop-down to select hour from 0 upto 23 and minutues from 00 upto 59. The time to REP batch job running to trigger this request. This field is time format field. If REP run as an offline job then it is not used in OLS.	N param 9(2): Should be greater than or equal to 0 if provided Time of day to excute request: Text box with HH:MM format

Post-Conditions

REP batch job extract balance based on REP rule type configure.

=tbd==

Exception Flow

Item Redemtion Rule Type (ITRD)

Requirement Definition

Item redemption Rule Type is used to to evaluate item redemption transactions.

The same approach as Award rule to evaluate the inputted data but there is no reward pool, formula and contributor on this rule type.

Redemption pool which be used to redeem wil be configured in item price instead.

Process Flow

Update later

Trigger

If you want to perform an item redemption transaction in the OLS, then an Item Redemption Rule must be created.

Pre-Conditions

User have to have the access right in the Campaing Rule moudle to can add/modify Item Redemption Rule.
All drop-down value must available in the system.

Wireframe

Please refer Award Rule Type.

Business Rules

- - 1. ITRD is one of rule type of Campaign Rule. ITRD Rule can be created/updated under Campaign module as a parr of campaign or Create from "Campaign Rule" screen under "Campaign Management" module.
    2. Click on Add button ([Image Removed]) in the screen to bring up the create form. User must to choose"Item Redemption" Rule type to go to next step. If Rule type is not selected user must to select existing template to continue otherwise "Next" botton is disbale".
    3. Click on Edit button in the screen to bring up the edit from as illustrated in section Wireframe. When the Rule Type in the Rule Header is Item Redemption , the following is displayed for specifying parameters based on which to extract the balane value:


Index	Field (EN/VN)	Description	Data type
Step 1: General information
	Campaign ID */ Mã chiến dịch	The Id and Campaign Name of the campaign to which this Rule belongs	Display if rule under campaign module. Drop-down if create fromseparately screen. Lookup value from Campaign Table. Refer to "Campaign"API under Campaign Management
	Campaign Rule ID*/Mã quy tắc chiến dịch	Rule identifier. Support system-generated. For reference only	X(10)
	Campaign Rule Name*/Tên quy tắc chiến dịch	Name of this Rule, for easy user reference	X(50)
	Description/ Mô tả	Long description of this Rule, for user reference	X(500)
	Rule Type*/ Loại quy tắc	The rule type which user selected on step 0	Display
	Effective Date From*/ Ngày bắt đầu hiệu lực	Apply this rule only to transactions with Transaction Date/Post Date (depended on effect rule based on between the Start and End Dates (inclusive) – the “Effective Period”.	Date
	Effective Date To*/Ngày hiệu lực kết thúc	All “Effective Periods” defined by “Start Date” and “End Date” always start at 00:00:00 and end at 23:59:59 midnight of the respective dates. To date must equal or greater than from date	Date
Step 2: Rule setting : If madatory fields in step 1 are not provided then step 2 is blocked Rule Detail
	Effective Period is Based On*/ Hiệu lực dựa trên	Determining whether the transaction being processed is within the Rule Effective Period is by using either the Transaction Date in the transaction data, or the system batch date (which is used as the Post Date for transaction processed during the day)	Radio button. Default "Transaction Date". Lookup value from "Code_Management" table. Refer to "get-by-code-type" API under master data with code type is "date-to-use-txn"
	Message Template ID/Mẫu tin nhắn	Message template containing the message text for sending an SMS or Email if this Rule is hit (depending on the template type) or to return the text from the message template in the response message to and online request. The message templates support a range of placeholders including all data elements in the transaction context, Customer and Account records	Drop-down. Select one API: =tbd=
	Stop if criteria met/Dừng tặng thưởng khi thỏa mãn điều kiện	If this is selected to Yes, the current transaction will not be processed against other Rules linked to the TC of the current transaction if the criteria in this Rule are met.	Switch botton. Defaut OFF
	Link Transaction Code * + 1. At least one transaction code must be provided 2. On the same campaign rule ID then transaction code must be unique 3. One the same combination of Rule Type and Transaction Code then Execution Sequence must be unique. In this part the system support “Quick add” feature for Transaction Code to allow a more efficient way to set up rules
	Add linked transaction code/Thêm mới mã giao dịch liên kết	Click on “Add” button to add linked TC to the rule. Multiple TCs can be linked to the Rule. TCs can be removed from the panel by clicking on the delete button.	Button
	Transaction Code*/Mã giao dịch	This field is for selecting the Transaction Code to trigger this Rule. When a TC is selected, all Rules linked to the TC, if any, will be listed in the panel “View Other Rules linked selected TC”, together with the current Rule, in the Execution Sequence number order. Take note that TC must be unique on each Campaign Rule	Drop-down. Select one. Lookup value from "Transaction_Code" table. Refer "OLS Transaction Code" API under Campaign Management
	Execution Sequence*/Trình tự thi hành	Execution Sequence of the Campaign Rule.	9(04) Should be greater than 0 if provided
	View Other Rules linked Selected TC	Click on this option to view all Active Campaign Rule in the system which under the same Rule type linked to the transaction code.
	Add new transaction code/ Thêm mới mã giao dịch	Quick add feature to support user add Transaciton Code from this screen. The new transaction will be automatiom approved when campaign rule is approved	Button
Step 3: Rule Criteria : The same approach as Award rule Refer to section 4.13 Campaign Rule Criteria

Post-Conditions

To post item redemption transaction, the item redemption transaction have to pass validation of Item Redemption Rule which linked to the Redemption Transaction code, otherwise the transaction is failed.

Exception Flow

- 1. Input data are not passed all validations and then user choose cancel the action then use case ends in failure.

Transaction Rule Analysis (HAVE TO BE ADDED)

Requirement Definition

Process Flow

Trigger

Pre-Conditions

Wireframe

Business Rules

Post-Conditions

Exception Flow

Campaign Insight

Requirement Definition

- - 1. Campaign Insight enables to combine data from across multiple data source into single chart in order to track and display customer/campaign activities clearly.

Process Flow

Trigger

N/A

Pre-Conditions

Users have to have the access right on Campaign Insight module to asssess to these dashboards.

Wireframe

[Image Removed]

Business Rules

Clicking on the chart icon at the top of the main Campaign list page will toggle between the Campaign list view and the Campaign Insight view.
Campaign Insight update constantly, giving user a real-time view of customer behavior, campaign activities.
Click “Campaign Insight” in the menu on OLS ‘s main menu. In the top right-hand on each dashboard enter/select the filter key to generate chart/graph.
OLS support following chart:

Top 10 Best customer of the campaign

- - - 1. This chart show the total point earn of each customer (on top 10 ) on each selected period of selected campaign.
      2. Dashboard description


Index	Field	Description
Filter key
	Campaign	This is a drop-down filter key. Optional and allow multiple select. Lookup active campagin from Campaign table. Refer to “Campaign API” under Campaign Management. Default empty. If Campaign is not provided then get top 10 customer of whole system.
	Period	This is drop-down filter key Optional and select one only OLS support following periods: * + 1. This week 2. This month 3. Last month 4. This quarter 5. This year Default as “This month” If period is not selected then get data of whole system.
Layout: [Image Removed]
	Customer information	Display top N customer including bellow information: * + 1. Top customer / 2. Customer full name and Registration date 3. CIF Number 4. Total earned point on selected period
	View all	Use scroll bar to view full list top 10 best customer.
Data source
	Get data from TRANSACTIONS table with transaction type = “Award” of selected campaign to determine the top 10 customer who got top 10 earned point on each period. Pool type should be point pool only…==TBD=== Use transaction date to determine period.

Number of enrrolled customers not - eligible because of criteria

This chart display total number of enrolled customers not -eligible campaing rule on each error code during each selected month.

Dashboard descriptions


Index	Field		Descriptions
I: Layout 1 [Image Removed]
Filter key
	Campaign		This is a drop-down filter key. Mandatory field and allow select one only. Lookup active campagin from Campaign table If Campaign is not provided then get data of whole system.
	Period		Last 12 months
Layout description
	Vertical axis		Fixed 12 last months from currenlty month. Currently month on the top of chart.
	Horizontal axis		Total number of enrolled customers not-eligible because of criteria. Use differernce colors to distinguish the difference erorr code on the same month. Should have the description for each error code. Hover over the bar graph to view a count of customers for the error code defined
Data source
	Get data from OLS_ORPHAN_TXN_NO_HIT table for selected campaign to determine the customer enroll in each month but did not get award because of criteira. The customer should have all transactions which did not hit any award rule (The rule get award points) on this campaign. Use Transaction date time of OLS_ORPHAN_TXN_NO_HIT table to determine period.
II : Layout 2 [Image Removed]
Filter
	Campaign	This is a drop-down filter key. Mandatory field and allow select one only. Lookup active campagin from Campaign table If Campaign is not provided then get data of whole system.
	Period	This is drop-down filter key Madatory and select one only OLS support following periods: * + 1. This month 2. Last month 3. Last 3 months (including curently month) Default as “This month”
Layout description
	Vertical axis	Total number of enrolled customers not-eligible because of criteria. Each error is separaty column in the chart. Use differernce colors to distinguish the difference months on the same error in case “Last 3 months” is selected”. Hover over the bar graph to view a count of customers for the error code defined
	Horizontal axis	Error code Should have the description for each error code when move mouse on the chart.
Data source
	Get data from OLS_ORPHAN_TXN_NO_HIT table for selected campaign to determine the customer enroll in each month but did not get award because of criteira. The customer should have all transactions which did not hit any award rule (The rule get award points) on this campaign. Use last_update_date of OLS_ORPHAN_TXN_NO_HIT table to determine period.

Number of enrolled customers eligibe vs not- eligible because of criteria

This chart display total number of enrolled customers: not -eligible campaing rule vs eligible campaign rule during each selected month.

Dashboard descriptions


Index	Field	Descriptions
Filter
	Campaign	This is a drop-down filter key. Optional field and allow multiple select Lookup active campagin from Campaign table If Campaign is not selected then get all campaigns.
	Period	Last 12 months
Layout: [Image Removed]
	Vertical axis	Total customer. We have 2 areas, one for enrolled customer eligible and other one for erolled customer not -eligible. Hover over the line graph to view a count of customers for the date range/time frame defined
	Horizontal axis	Fixed last 12 months from curenlty month. Curently month on the right side.
Data source
	Get data from TRANSACTIONs table to get total number of enrolled customers eligible of selected campaign per each months. Get data from OLS_ORPHAN_TXN_NO_HIT table to get the total number of enrolled customers NOT-eligible of selected CP per each month. Should there is no customer in intersection of eligible and Not- eligible

Earned points Vs redemmed points

- 1. This chart used to compare total earned point with total redeemed point during each selected period.
  2. Dashboard description


Index	Field	Description
Filter
	Period	This is drop-down filter key Madatory and select one only OLS support following periods: * + 1. This month 2. Last month 3. Last 3 months (including curently month) 4. Last 12 months Default as “This month”
Layout [Image Removed] [Image Removed]
	Vertical axis	Total point each selected period. Green line for earned point and red line for redemmed points.
	Horizontal axis	Condition data. If Period “Last 12 months” is selected then horizontal axis is including last 12 months from currently month. Total point will be monthly total point If Period “This month” or “Last Month” is selected then horizontal axis is including all day of the month. Total point will be daily total point. If Period “ Last 3 months” is selected then horizontal axis is including last 3 month from currenlty month. Total points will be monthly total points. Hover over the line graph to view a count of redemmed points/earned points for the date range/time frame defined
Data source
	Get data from TRANSACTIONS table with transaction type = “Award” for earned point /Transaction type = “Redeem” for redemmed point during each selected month. The transaction should be not cancellation. Use transaction date to determine period.

Redemptions point on each channel

- - - 1. This chart allow user can see that awared points used for wich purpose: Which channel user customer use to redeem point month. The fluctuation of redeemed point with previous month to user can change the campaign stratery to meet customer’s behaviors.
      2. Dashboard descriptions


Index	Field	Description
Filter
	Period	This is drop-down filter key Madatory and select one only OLS support following periods: * + 1. This month 2. Last month Default as “This month”
Layout [Image Removed]
	Icon [Image Removed]	Icon for each channel: Item redemption Automation redemption Pay with Points.
	Total redemmed points and rate [Image Removed]	#1: Total redemmed points on each channel and Percentage on total redemmed points of all 3 channels. #2: Percentage increase /descrese of redemmed poins which is compared with previous month on each chanel. Red color if #1 less than previous month Ograne color if no change on the ratio between 2 months. Green color if greater than previous month. Take note that “This month” will compare with last month and “Last month’ will compare with before last month.
Data source
	Get data from CAT_CATALOGUE_TRANS_DETAILS table for item redemption. Get data from TRANSACTIONS table which posted by REP for Automation redemption. Get data from TRANSACTIONS table which assigned as PwP transactions for Pay with Points . Use transaciton date to determine period.

Redemption on each item type

- - - 1. This chart allow user can see that awared points used for wich purpose. How many item to be redemmed and the best item which customer prefer to redeem each period: Currently month OR last month. Therefore user can base on this to understand customer’s behaviors and customer’s habit.
      2. Dashboard descriptions


Index	Filed	Description
Filter
	Period	This is drop-down filter key Madatory and select one only OLS support following periods: * + 1. This month 2. Last month Default as “This month”
Layout [Image Removed]
	Left vertical axis	Total redemmed points Use Bar chart to describe redemmed points per each item type.
	Right vertical axis	Total redemption quantity. Use line chart to describe redemption quantity per each item type
	Horizontal axis	Item type list which is redemmed on this period. Hover over the line graph to view a count of Redemmed quantity for the each item type. Hover over the bar graph to view a count of redeemed points for the each item type.
Data source
	Get data from CAT_CATALOGUE_TRANS_DETAILS table to get total redemmed point and total quanity per each item type. Use transaction date time do determine period. Period based on sysmonth

Customer’s activities

- - - 1. This dashboard describes the fluctuation of total number of new customer vs churn customer on each month. Based on this chart user can see have/should have implemented a solutution to reduce the churn.
      2. Dashboard descriptions


Index	Field	Description
Filter
	Month	Last 12 months
Layout [Image Removed]
	Left vertical axis	Total number of customers. Per each month we have 2 cloumns : Green column for new customer and Orange column for churn customer.
	Right vertical axis	The line chart will describe the customer churn rate. The units of measurement is percentage.
	Horizontal axis	Fixed 12 last months from currenlty month. Curently month on the right side.
Data source
	New customer = New customer added in OLS system Churn customer = The customer unactive in OLS system Customer churn rate = Number of customer churn /Total customer (including new and churn customer) Use Last_update_date in OLS system to determine period.

Campagin statistic

1. Use this dashboard to measure the impact of existing campaigns. The information available on the Campaign Statistics screen helps users analyze where you can make campaign changes to improve results.
2. Dashboard descriptions


Index	Filed	Description
Filter: Just use for detail listing only
	Campaign	This is a drop-down filter key. Optional and allow multiple select. Lookup active campagin from Campaign table Default empty. If Campaign is not provided then get data of whole system.
	Period	This is drop-down filter key Mandatory and select one only OLS support following periods: * + 1. This month 2. Last month 3. This quarter 4. This year 5. Select custom data Default as “This month”
Layout [Image Removed]
	Campagin statistic [Image Removed]	This part display some following indicators: * + 1. Total Campaigns: Total availble campaign in the system 2. Total customer: Total number of enrroled customer. 3. Total new customers on this day. 4. Total spending: Total nett amount for all purchase transactions on these campaigns. 5. Total cash rebate: Total cash rebate which customer got when errolled these campaigns. 6. Total awarded point: Total uni point which customer got when errolled these campaigns. These above value are updated realtime base one sysdatetime.
	Detail listing [Image Removed]	* This part includes following fields: + 1. Campaign ID: From selected Campaign 2. Target total spending value: From Campaign’s configuration 3. Actual total spending: Total nett transaction amount 4. Target Active Customer Count: From Campaign ‘s configuration 5. Actual Customer Count: Total number of enrolled customers. 6. New customer: Total number of new enrolled customer on this day. 7. Total rewarded points: Total earned points. * When click on each Campaign ID, the system will bring up to Campaign detail Screen. * Implement scroll bar and paging for campaign listing.
Data source
	Get data from TRANSACTIONs table for number of customers/ total spending and awarded points Get data from CAMPAIGN table for target value. Use transaciton date to determine period.

Post-Conditions

- 1. User can use these charts to decide the campaign strategy to meet customer’s demand.

166 KiB Raw Blame History Unescape Escape

Reward Campaign Management

Highlights

Structure of a Campaign (HAVE TO BE ADJUSTED)

Types of Campaign Mechanics

Award on Every Transaction

Accumulate Then Award

Auto-redemption Campaigns

Reward Pool Structure & Bucket Deduction Sequence

Counters – Structure and Mechanics

About Loyalty Marketing Campaigns (HAVE TO BE ADDED)

External Transaction Code

Requirement Definition

Process Flow

Trigger

Pre-Conditions

Wireframe

Business Rules

Post-Conditions

Exception Flow

OLS Transaction Code

Requirement Definition

Process Flow

Trigger

Pre-Conditions

Wireframe

Business Rules

Post-Conditions

Exception Flow

Pool Definition

Requirement Definition

Process Flow

Trigger

Pre-Conditions

Wireframe

Business Rules

Post-Conditions

Exception Flow

Pool Conversion Rate

Requirement Definition

Process Flow

Trigger

Pre-Conditions

Wireframe

Business Rules

Post-Conditions

Exception Flow

Counter Definition

Requirement Definition

Process Flow

Trigger

Pre-Conditions

Wireframe

Business Rules

Post-Conditions

Exception Flow

Transaction Category

Requirement Definition

Process Flow

Trigger

Pre-Conditions

Wireframe

Business Rules

Post-Conditions

Exception Flow

Account Type Group

Requirement Definition

Process Flow

Trigger

Pre-Conditions

Wireframe

Business Rules

Post-Conditions

Exception Flow

Reward Campaign

Requirement Definition

Process Flow

Trigger

Pre-Conditions

Wireframe

166 KiB

Raw Blame History