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

docs/specs/00_MIGRATION_REPORT.md

@@ -0,0 +1,27 @@
+# Migration Report
+
+## Summary
+The migration of the monolithic FSD (Functional Specification Document) Markdown files to the OpenSpec standard is complete. The goal was to decompose massive, human-oriented Word-converted markdown files into Agent-Friendly, atomic, and structured OpenSpec documents. 
+
+## Completed Tasks
+1. **Decomposition:** All major monolithic files have been decomposed into domain-specific subdirectories.
+2. **Archiving:** The original monolithic markdown files have been moved to `docs/specs/archive/`.
+3. **Format Standardization:** The newly created documents follow the OpenSpec format, including proper YAML frontmatter (`title`, `type`, `status`, `domain`).
+4. **Cleanup:** Unnecessary UI clutter, malformed artifacts (e.g. `[Image Removed]`), and verbose narrative instructions were removed or converted into structured business rules and data schemas.
+
+## Output Structure
+The new documentation is organized into the following domains under `docs/specs/`:
+* `customer_management/`: Profiles, Accounts, Cards, Pool Balances, Transactions, Adjustments, etc.
+* `reward_campaign/`: Campaign Structures, Rules, Criteria, Formulas, Counter Definitions, Transaction Categories, etc.
+* `onetargeting/`: Segmentation, Audiences.
+* `onecatalogue/`: Catalogues, Categories, Master Items, Vouchers.
+* `onemarketing/`: Messages, Campaigns, A/B Testing, Whitelists, Blacklists.
+* `oneaccess/`: Users, Permissions, Profiles.
+* `oneadmin/`: Framework behavior.
+* `system_management/`: Application parameters.
+* `introduction/`: Terminology.
+* `reference/`: References, Change History.
+
+## Next Steps
+- Implement Agent tooling capable of reading these OpenSpec files to generate test cases or boilerplate code.
+- Ensure any future updates to the requirements are made directly to the atomic OpenSpec files, not the archived monolithic documents.

docs/specs/00_MIGRATION_TRACKER.md

@@ -0,0 +1,34 @@
+# Migration Tracker: FSD to OpenSpec
+
+## Objective
+Convert `docs/FSD P1_Finnal Version.docx` to a structured, modular Knowledge Base based on the OpenSpec format.
+
+## Stages
+- [x] **Step 1:** Convert `.docx` to HTML using Python (`mammoth`), then to Markdown (`markdownify`) to preserve tables and structure. (Script: `convert_fsd.py`)
+- [x] **Step 2:** Generate the Master Markdown file (`docs/FSD_Master_Clean.md`).
+- [x] **Step 3:** Analyze the Master Markdown file to extract domains (e.g., Campaign, Customer, OneAccess).
+- [x] **Step 4:** Split the content into modular OpenSpec Markdown files under `docs/specs/`, clean up heavy image tags, and apply standard headings.
+- [x] **Step 5:** Finalize migration and generate report (`docs/specs/00_MIGRATION_REPORT.md`), remove temporary files.
+
+## Extracted Domains
+1. `overview.md` (Overview)
+2. `scope_and_assumption.md` (Scope & Assumption)
+3. `one_access.md` (OneAccess)
+4. `one_loyalty.md` (OneLoyalty / Campaign)
+5. `customer_management.md` (Customer Management)
+6. `one_marketing.md` (OneMarketing)
+7. `one_catalogue.md` (OneCatalogue)
+8. `one_targeting.md` (OneTargeting)
+
+## Decomposed and Verified
+- [x] `onetargeting.md` -> `onetargeting/segmentation.md`, `onetargeting/audience_upload.md`, `onetargeting/customer_audience.md`
+- [x] `application_parameter.md` -> `system_management/application_parameter.md`
+- [x] `introduction.md` -> `introduction/terminology.md`
+- [x] `reference.md` -> `reference/change_history.md`, `reference/document_references.md`
+- [x] `oneaccess.md` -> `oneaccess/user_group.md`, `oneaccess/permission_management.md`, `oneaccess/user_profile.md`
+- [x] `oneadmin.md` -> `oneadmin/framework_behavior.md`
+- [x] `onecatalogue.md` -> `onecatalogue/catalogue.md`, `onecatalogue/category.md`, `onecatalogue/item_master.md`, `onecatalogue/item_price.md`, `onecatalogue/voucher_code.md`
+- [x] `onemarketing.md` -> `onemarketing/marketing_message.md`, `onemarketing/marketing_campaign.md`, `onemarketing/frequency_capping.md`, `onemarketing/ab_testing.md`, `onemarketing/blacklist.md`, `onemarketing/whitelist.md`
+- [x] `customer_management.md` -> `customer_management/customer_profile.md`, `customer_management/customer_360.md`, `customer_management/account.md`, `customer_management/card.md`, `customer_management/pool_balance_detail.md`, `customer_management/transaction_history.md`, `customer_management/no_hit_cp_transaction.md`, `customer_management/statement.md`, `customer_management/attribute.md`, `customer_management/counter.md`, `customer_management/adjustment.md`, `customer_management/transfer_balance.md`, `customer_management/re_instatement.md`, `customer_management/item_redemption.md`, `customer_management/award_transaction.md`
+- [x] `reward_campaign_management.md` -> `reward_campaign/campaign_structure.md`, `reward_campaign/external_transaction_code.md`, `reward_campaign/ols_transaction_code.md`, `reward_campaign/pool_definition.md`, `reward_campaign/counter_definition.md`, `reward_campaign/transaction_category.md`, `reward_campaign/account_type_group.md`, `reward_campaign/reward_campaign.md`, `reward_campaign/reward_campaign_rule.md`, `reward_campaign/campaign_rule_criteria.md`, `reward_campaign/campaign_rule_formula.md`, `reward_campaign/campaign_rule_contributor.md`, `reward_campaign/cep_rule.md`, `reward_campaign/rep_rule.md`, `reward_campaign/item_redemption_rule.md`, `reward_campaign/campaign_insight.md`
+1

docs/specs/archive/application_parameter.md

@@ -0,0 +1,78 @@
+---
+title: "Application Parameter"
+type: OpenSpec
+status: Draft
+---
+# Application Parameter
+
+## Requirement Definition
+
+* The “**Application Parameters**” module provides a means to maintain a set of application control parameters that define the system behavior in relation to user authentication, and user interface. These include password policy parameters session time-outs and system display format.
+
+## Process Flow
+
+## Wireframe
+
+* + 1. Access control
+
+[Image Removed]
+
+* + 1. Display setting
+
+[Image Removed]
+
+* + 1. Functionality
+
+[Image Removed]
+
+## Trigger
+
+## Pre-condition
+
+* Users have to have access right on this screen in order to access this screen.
+* Depending on the user’s access rights, they can view/add/edit/
+
+## Business Rule
+
+* + 1. When the Application Parameters option is selected (under the System Management module in the navigation panel), the screen is displayed with the "Access Control" tabs as the default, as illustrated in the following:
+
+[Image Removed]
+
+1. There are 3 tabs under the **Application Parameters** modules: **Access Control, System Display, and Functionality**.
+2. All parameters under each tab will be pre-defined by the system as default. When any tabs is selected then the parameters are displayed according and allow the user to modify them.
+3. Application parameters list detail:
+
+| Label (EN/VN) | Parameter | Data Type |
+| --- | --- | --- |
+| **Access *Control*** | | |
+| Same User Cannot Approve \*/ Người dùng không thể phê duyệt cùng bản ghi | Allow/Disallow the user to approve/reject the record that they themselves created. | Switch button  Default OFF |
+| Same User Cannot Modify Own Profile \*/ Người dung không thể thay đổi thông tin cá nhân | Allow/Disallow the user to change their profile in the system. | Switch Button  Default OFF |
+| User Session Inactivity Time-out (minutes)\* / Hết hạn phiên đăng nhập | The user session will be ended if there are no user actions for N minutes.  The system will throw an alert message and require the user login again. | 9(2)  Default N as 30 minutes |
+| Maximum Failed Forgotten Password Attempts \*/ | User id is blocked from further log-ins and the user profile record is suspended (blocked) until it is reset if customer enters more than N invalid passwords consecutively. | 9(2)  Default N as 5 tiems |
+| Inactivate User Id after N days of no log-ins\*/Tài khoản bị dừng hoạt động sau N ngày không đăng nhập. | User status is automatically inactive until reset if the user has not logged in for more than the number of days specified. | 9(3)  Default as 30 days |
+| Remind User to Change password N Days Before password expires\*/ Nhắc người dùng đổi mật khẩu trước N ngày trước khi hết hạn. | When the user logs into the system, the system will show an alert message to notify the user has to change the password from N day away before the password expires. | 9(3)  Defaut as 5 days |
+| Password expiration [days] \*/ Số ngày hiệu lực của mật khẩu | The number of days after which a new password will be expired. This determines how long a password remains valid before the user must change it.  After this period, the account is locked and the user is unable to log in until the administrator unlocks the account. | 9(3)  Default as 180 days |
+| Disallow re-use of the last N passwords \*/ Cho phép dùng lại mật khẩu trong N lần gần nhất | The system just allows the user to re-use the last N password only. These options help to ensure passwords are regularly updated and not recycled.  User can not re-use any of their last 2 passwords. | 9(1)  Default as 2 times |
+| Maximum password length \*/ Độ tài tối đa của mật khẩu | When the user is setting a new password or when changing an existing password, the new password must be not greater than this length | 9(2)  Default as 50 |
+| Minimum password length\* /Độ dài tối thiểu của mật khẩu | When the user is setting a new password or when changing an existing password, the new password must be at least this length | 9(2)  Default as 8 |
+| Password must at least N numeric digit \*/ Mật khẩu phải có ít nhất N số | When the user sets a new password or when changing an existing password, the new password must be at least N numeric digits. | 9(2)  Default as 1 digit |
+| Password must have at least [N] upper case alphabet\*/ Mật khẩu có ít nhất N kí tự in hoa | When the user sets a new password or when changing an existing password, the new password must be at least N upper case alphabet. | 9(2)  Default as 1 |
+| Password must have at least [N] lower case alphabet \*/ Mật khẩu có ít nhất N chữ cái thường | When the user sets a new password or when changing an existing password, the new password must be at least N lowercase alphabet. | 9(2)  Default as 1 |
+| Password must have at least [N] special character\*/ Mật khẩu có ít nhất N kí tự đặc biệt | When the user sets a new password or when changing an existing password, the new password must be at least N special character. | 9(2)  Default as 1 |
+| **Display Setting** | | |
+| Date format \* / Định dạng ngày | A drop-down to select the following date display format:   * DD/MM/YYYY * DD-MM-YYYY * DDMMYYYY * MM/DD/YYYY * MM-DD-YYYY * YYYY/MM/DD * YYYY-MM-DD * DD,MM,YYYY   This determines how dates are displayed throughout the system. This is the default display. | Dropdown  Select one  Default as DD/MM/YYYY |
+| Time format\* /Định dạng giờ | A drop-down to select the following time display format:   * HH:mm: ss * HHmmss * HH, mm, ss * HH;mm;ss * HH/mm/ss   This determines how times are displayed throughout the system. This is the default display. | Drop-down  Select one  Default as HH:mm: ss |
+| Amount display format \*/ Định dạng số | This parameter determines how amounts are displayed throughout the system:   * American [999,999,99] * European [999.999,99] | X(20) |
+| **Functionality** | | |
+| Processing Date / Ngày xử lí | The date on which a particular transaction or event is processed or recorded in the OLS system for the online transaction instead of the system.  This parameter must be used for testing only.  In production the processing date should be empty then the system always uses the system to process or record the online transaction. | Date  Default is empty |
+| Allow Cross Function Update\* / Cho phép cập nhật chéo | This allows or disallows cross-updates between data created by users and data created.  The following functions apply to this parameter:   * Customer data * Account data * Card data | Switch button  Default ON |
+
+## Post-Condition
+
+* The application now uses the new, standardized parameter format.
+* All existing parameter settings have been successfully migrated to the new format.
+* The application's functionality remains uninterrupted, and end-users can continue using the application without any noticeable changes.
+* The application's parameter management is more maintainable, scalable with other systems.
+
+## Exception flow
+

docs/specs/archive/introduction.md

@@ -0,0 +1,45 @@
+---
+title: "Introduction"
+type: OpenSpec
+status: Draft
+---
+# Introduction
+
+## Scope of Document
+
+## Terminology
+
+1. The following sets out the definition of terms which are used in this document:
+
+|  | **Term** | **Definition** |
+| --- | --- | --- |
+|  | Amount vs Quantity | * In OLS, “Amount” is used in connection with monetary amounts – i.e. when the unit of measure is an actual currency such as Dollars, Pesos, and Indonesian Rupiah etc. For example, “Transaction Amount” is the most frequently encountered “amount” entity. * Quantity is used to refer to the number of units of an entity, but not to monetary value. For example, the number of points awarded is typically referred to as the “Award Quantity”, and the number of points redeemed is the “Redeem Quantity”, whereas the value of the award is the “Award Amount” and the value of the redemption is the “Redeem Amount” |
+|  | Pool Blance Bucket (Bucket) | * It is used in the context of a Reward Pool Bucket, per bucket: based on pool entity level and expiring date to determine a pool balance bucket. |
+|  | Bucket Expiry Date | * If used in the context of a Counter, see Counter. * If used in the context of a Reward Pool Bucket, see Pool. |
+|  | Campaign Rule (Rule) | * A Rule is a business rule defining the conditions under which a reward will be given, including the type and quantity of reward. * The Rule includes a set of “**Rule Criteria**” that defines the conditions to be met in order that the quantity of rewards to be calculated with the formula and parameters that are defined in the “**Rule Formula**” is to be given to the customer. |
+|  | CEP | * “Counter Extract & Process” is a module for setting up job requests to extract a specified counter based on criteria set up in the request, and using the counter value as transaction amount, to form a transaction to process against Campaign Rules linked to the transaction through a Transaction Code and other Rule Criteria. * The module includes the corresponding batch processes to execute the requests. |
+|  | Contributor | * Identifies an entity which funds the rewards given under a given Rule. * One or more Contributors can be set up for rewards of each Rule. * If there is more than one Contributor for a Rule, the “**Rule Contributor Settings**” function is used to define the percentage of reward to be billed to each Contributor. The total contribution percentage must be 100%. * If the business entity with which the customer is transacting is the only Contributor for the rewards, then no setting has to be done in the “**Rule Contributor Settings**”, as BLP will consider the transacting entity as the default Contributor. * The Contributor setting is used in the end-of-day Contributor settlement report to calculate the amount due from each Contributor, for each reward transaction. |
+|  | Counter | * Counters are used to track customer’s transaction statistics. * Counters can be defined on demand to track a spend frequency or spend total for a given set of criteria. * For example, a Counter can be configured to track the number of transactions done by each customer in a specific Merchant Category Code or MCC. * If the count to be tracked is periodic – e.g. monthly – then the Counter can be configured to track the count for each period in a separate “**Counter Bucket**”, where each Counter Bucket has a “**Counter Bucket Date**” equal to the end date of the month. * What is tracked depends on which “**Counter Method**” is selected. * Counters are identified by “Counter Ids”. |
+|  | Effective Period | * Many parameters have a Start Date and End Date range during which the parameter is effective. * The general rule is that the Start Date starts on and after 00:00:00 hours and the End Date ends at 23:59:59. * Note that in BLP, time is considered a discrete quantity in seconds. * This definition applies for all cases where we have the “Start Date” and “End Date” parameters – e.g. campaign rules, currency rates, item price schedules, etc, where the corresponding start and end times are not specified. |
+|  | Expiry Policy | * See more on the Pool Definition section |
+|  | Formula | * This part of the Rule defines the calculation formula or formulae to be used for calculating the quantity (number of units in the Reward Pool – e.g. number of points, number of coupons) of reward to be given for a given transaction if the conditions set in the Rule Criteria are fulfilled. * The Formula comprises 2 parts: the Formula Header and the Formula Detail. * “**Formula Header**” defines a set of parameters to be adopted by all formulas selected in the Formula Detail – e.g. the maximum amount of reward to be given, the rounding rule (round down, round up, etc), the quantity to use for calculation (whether the Gross Amount or Nett Amount). * “**Formula Detail**” defines the details of the formula to be used in the calculations. Each Formula Detail can have one or more Formula. * **Execution Sequence**. A Rule has one or more Formula Details. Each Formula Detail is assigned an Execution Sequence number that determines the order in which the Formula is executed during transaction processing. The higher the numbers are executed first. |
+|  | Gross Amount | * See Transaction Amount. |
+|  | Pool | * Each type of reward – e.g. points or coupons, is tracked in a “**Pool**” or “**Reward Pool”**. * Each Reward Pool is associated with a “**Pool Expiry Policy**”, also referred to as “**Expiry Policy**”. * The Pool Expiry Policy selected for the Pool determines how the reward earned in that Pool is expired. * An example of a Pool Expiry Policy is “Expire 2 calendar quarters after earning”. * This would cause all the rewards earned in a given calendar quarter to be put in a Pool Bucket with an Bucket Expiry Date set to the end date 2 calendar quarters from the quarter in which the rewards were earned. * Rewards that expire on a given date are tracked in a separate “**Pool Bucket**”. * Example, if **Expiry Policy** for a Reward Pool is “Expire rewards 6 months from month of earning”, then all the points earned in each month will be stored in a separate bucket, each “Pool Bucket” having its own **Bucket Expiry Date**. * To meet the requirements of UNIRMs, new policy based on Card Types will be provided. For details of this, see “Expiry Policy” definition. |
+|  | REP | * “Redeem, Extract and Process” is a module for setting up a request to redeem a specified Pool, subject to criteria set up as part of the request, and to then output the redemption transaction details according to the selection set up in the request. |
+|  | Rule Criteria | * See Campaign Rule Criteria |
+|  | Rule Pool | * The Rule Pool is a Reward Pool which is updated with the results of the Rule Formula or Formulae. * Each Rule is associated with one Rule Pool. |
+|  | Transaction Amount | * Each transaction record in OLS for award processing has a mandatory column identified as the Transaction Amount. The Transaction Amount is used as the principal quantity for reward calculation in the Formula. * If the transaction is a payment transaction:   + The Transaction Amount is the payment amount   + If the transaction request includes a request to offset the payment amount by redeeming any available rewards, the amount remaining after deducting the available rewards value from the payment amount is referred to as the “**Nett Amount**”.   + The payment amount before the deduction is the “**Gross Amount**”. * The Transaction Amount is always logged in OLS as the “Gross Amount”. |
+|  | OLS Transaction Code (TC) | * Each transaction record received in OLS for award processing has a column identified as the Transaction Code or TC. * The TC is used as the key to locate applicable Rules. * If no Rule is linked to TC, no reward calculation is done for that transaction. * TC is user-defined but it must be set up in the Transaction Code look-up table. |
+
+## Structure of Document
+
+The rest of this document is made up of the following sections:
+
+1. Introduction
+2. OneAcess
+3. Customer Management
+4. Campaign Management
+5. OneCatalouge
+6. OneMarketing
+7. OneTargeting
+

docs/specs/archive/oneaccess.md

@@ -0,0 +1,243 @@
+---
+title: "OneAccess"
+type: OpenSpec
+status: Draft
+---
+# OneAccess
+
+## Overview
+
+1. OneAccess™ is the module for managing user access rights to OLS administration functions.
+2. The Access control Management functions are comprised of:
+
+* User Group definition
+* User Profile set-up (defining user IDs for logging into the system).
+* Permission Management setup 2 permission type: Particular user/ User Group.
+
+1. Report permission
+
+* To identify reports each Permission Group is allowed to access.
+
+1. View filter Management
+
+Every screen can be configured with a filter based on the value of fields in the screen (View Filter). The View Filter restricts which fields in which screens are displayed to users in a User Group. The View Filter can also be used to block the entire view from the users in a User Group.
+
+**In phase 1, we are focusing on item #1 first and allow automation to approve when user/edit record.**
+
+## User Group
+
+### Business Requirement
+
+1. The User Group module is utilized to categorize users who share identical permissions within OLS.
+2. Use this screen to define the group to be assigned to a particular user or group of users. When adding a new user to the system, select this group for that user.
+
+### Process Flow
+
+=TBD=
+
+### Trigger
+
+1. A new user group needs to be defined.
+2. An existing user group needs to be modified or the user needs to review the existing group to make any decision.
+
+### Post –Condition
+
+1. Users have to have the access right on this screen to access this screen.
+2. Depending on the user’s access rights, they can view/add/edit user group records.
+
+### Wireframe
+
+Please refer to the wireframe on the Figma.
+
+### Business Rules
+
+* + - * 1. The user group ID must be a unique value.
+        2. If the required user group has not been defined, click on the User group icon in the Main Menu to bring up the summary list as illustrated in section [Wireframe](#_Wireframe_18)
+        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 User Group is illustrated in section [Wireframe](#_Wireframe_18).
+        4. Screen description:
+
+|  |  |  |  |
+| --- | --- | --- | --- |
+| **Index** | **Field** | **Description** | **Data type** |
+| **Genneral information** | | | |
+|  | User Group ID\*/ Id nhóm người dùng | The identify of user group | ~~X(20)~~  X(10) |
+|  | User group Name\*/ Tên nhóm người dung | The name of the user group  For reference only | X(100) |
+|  | Description /Mô tả | Description for user group | X(200) |
+| **Group users: List all active User Profile record are assigned to this group.**  **This part is display when user click to view any active record only** | | | |
+|  | User ID\* / ID người dùng | The identify of the user who be long to the chosen group | Display |
+|  | User name\*/Tên người dung | The name of the user | Display |
+|  | Email \*/Địa chỉ email | Email | Display |
+
+### Post –Condition
+
+* 1. The data is updated in the DB and relation screen (if needed).
+
+### Exception Flow
+
+1. Input data are not passed all validations and then user choose cancel the action then use case ends in failure.
+
+## Permission Management
+
+### Business requirement
+
+1. The Permission Management module is used to maintain Access Rights Groups – i.e. to define:
+   1. Which modules and functions can be accessed by users in a group, and
+   2. Which of the applicable actions can be performed by the users in each of the functions within each of the modules in the group:
+
+|  |  |  |
+| --- | --- | --- |
+| * + 1. Add | * + 1. Change | * + 1. View |
+| * + 1. Delete | * + 1. Approve (or Reject) | * + 1. Copy |
+| * + 1. View History | h. Save as Template | |
+
+### Process Flow
+
+TBD
+
+### Trigger
+
+* + 1. New user group to be defined then need to add permission to this group.
+
+### Post-Conditions
+
+1. Users have to have the access right on this screen in order to access this screen.
+2. Depending on the user’s access rights, they can view/add/edit Permission Management records.
+
+### Wireframe
+
+Please refer to the wireframe on the Figma.
+
+### Business Rules
+
+* + - * 1. If permission required has not been defined, click on the Permission Management icon in the Main Menu to bring up the summary list as illustrated in the section [Wireframe](#_Wireframe_19)
+        2. 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 Permission Management is illustrated in the section [Wireframe](#_Wireframe_19).
+        3. Screen description
+
+|  |  |  |  |
+| --- | --- | --- | --- |
+| **Index** | **Field** | **Description** | **Data type** |
+| **Step 1\*: General information/Thông tin Chung** | | | |
+|  | Role \*/Quyền | The unique identifier of the permission group. | ~~X(20)~~  X(10) |
+|  | Role Name\*/Tên nhóm quyền | Text describing the Permission Group Name, for user reference | X(100) |
+|  | Permission Type \*/Loại quyền | Drop down to select the following permission type:  *Particular User*  *User Group* | Drop-down  Select one |
+|  | User/Người dùng | Condition field  Drop-down list to select one or more users who can be accessed on all functions of this role. This field is only active and required when "Particular User" is selected in the previous step. | Drop-down  Multiple select |
+|  | User group/ Nhóm người dung | Condition field  Drop-down list to select only one group and all users under this group can be accessed on all functions of this role.  This field is only active and required when this role is applicable to the user group type. | Drop-down  Select one |
+|  | Description/ Mô tả | Text describing the Role, for user reference | X(200) |
+| **Step 2**\*: **Permission Management** /Quản lí quyền | | | |
+|  | **Select Modules**  A hierarchy of modules contains the list of functions available.  Top-level module: The modules group  Second level module: The specific module for each group.  Allow the user to search the modules by entering the module name | | |
+|  | Select All/Chọn tất cả | Check/Uncheck to drag/drop all modules in the system into the permission part to configure the specific permission of the role. | Check box |
+|  | “Module Name” | Check/Uncheck to drag/drop this module permission part to configure the specific permission of the role.  Checked/Unchecked on top level then all second level modules will be applicable as well. | Check box |
+|  | Search /Tìm kiếm | Users input their search keyword(s) into a designated search bar to find the module they're looking for. | Search feature |
+|  | **Permission /Quyền**  **A list contains all selected modules in the previous step and the permission list applicable for each module.**  **Note that: N/A =**Not Applicable will be defined in the master data and the user can’t check/uncheck to allow/disallow the permission if this permission is not applicable.  **The system allows the user to quickly add/delete one permission to all modules per each module group.**  **Besides the system allows** to allow/disallow all available permissions for all modules that appeared in the “Permission” part | | |
+|  | Selected all/Chọn tất cả | Check/Uncheck to allow/disallow all available permissions for all modules that appeared in the “Permission” part. | Check box |
+|  | “Top-level module name”  E.g: Customer Management | The name of the top-level selected module.  Check/uncheck to allow/disallow all available permission for all second-level modules belonging to this module | Check box |
+|  | “Second level Module name” E.g: Card | The name of the second level selected module.  Check/uncheck to allow/disallow all available permissions for the chosen module. | Check box |
+|  | “Second level Module name” E.g: Card | Click on the second level module to bring up the popup to define the permission of each field on the each screen.  See more on “Acccess Right Fields” | Hyperlink |
+|  | View /Xem | This column contains one checkbox in each row corresponding to a function to which the View action is applicable. If checked, users in this role can view the data available in this function | Check box |
+|  | Create/Thêm mới | This column contains one checkbox in each row corresponding to a function to which the Create action is applicable. If checked, users in this role can create data in this function.  If user have created permisson then user will have "Save as draft" role also | Check box |
+|  | Edit /Sửa | This column contains one checkbox in each row corresponding to a function to which the Edit action is applicable. If checked, users in this role can do "update" action in this function. | Check box |
+|  | Delete/Xóa | This column contains one checkbox in each row corresponding to a function to which the Delete action is applicable. If checked, users in this role can do "delete" action in this function. | Check box |
+|  | Copy /Sao chép | This column contains one checkbox in each row corresponding to a function to which the Copy action is applicable. If checked, users in this Role can coppy available data in this function | Check box |
+|  | Approve /Phê duyệt | This column contains one checkbox in each row corresponding to a function to which the Approve/Reject action are applicable. If checked, users in this role can do " approve/reject" action in this function | Check box |
+|  | History/Xem lịch sử | This column contains one checkbox in each row corresponding to a function to which the History action (i.e. to view earlier versions of the data in the activity log) is applicable. If checked, users in this role can view data history in this function. | Check box |
+|  | Template/Tạo biểu mẫu | This column contains one checkbox in each row corresponding to a function to which the "Save As Tempalte"action is applicable. If checked, users in this role can save record as a template and able to access to "template" tab in listing page | Check box |
+| **Access rights field /Phần quyền chi tiết trường thông tin** | | | |
+|  | Access permission | The list available fields of chosen module | Display |
+|  | View/Xem | This column contains one checkbox in the each row corresponding to a function to which the “view” action is applicable. If checked, user in this role can view the field in the screen. | Check box |
+|  | Editable/Cho phép chỉnh sửa | This column contains one checkbox in the each row corresponding to a function to which the “Editable” action is applicable. If checked, user in this role can modify the value of this field in the screen. | Checkbox |
+
+* When viewing any record, the system displays only the available permissions for this group.
+
+### Post-Conditions
+
+Record is automation approval.
+
+Based on the permission the system will check and display available module/function of each user as following:
+
+A = Set of Permission of role which are assigned directly to user
+
+B= Set of Permission of Role which are assigned to permission group and user are in these permission group.
+
+**Therefore: C= User permission = Combination of A and B.**
+
+### Exception Flow
+
+1. Input data are not passed all validations and then user choose cancel the action then use case ends in failure.
+
+## User Profile
+
+### Business requirement
+
+The user profile defines user attributes and sets the date and time for allowing user access to system functions. User profile created will be used for login, and users, upon logging in, will be able to view a list of functions with specific operations set in the permission management section and will be associated with users through this function screen.
+
+### Process Flow
+
+N/A
+
+### Trigger
+
+* + 1. New account need to be defined.
+    2. Need to update information of any existing account in the system.
+
+### Post-codition
+
+1. Users have to have the access right on this screen in order to access this screen.
+2. Depending on user’s access rights, they can view/add/edit User Profile records.
+
+### Wireframe
+
+Please refer to the wireframe in the Figma.
+
+### Business Rules
+
+* + - * 1. If the permission required has not been defined, click on the User Profile icon in the Main Menu to bring up the summary list as illustrated in the section [Wireframe](#_Wireframe_20).
+        2. 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 User Profile is illustrated in the section [Wireframe](#_Wireframe_20).
+        3. Screen description
+
+|  |  |  |  |
+| --- | --- | --- | --- |
+| **Index** | **Field** | **Description** | **Data type** |
+| **General information** | | | |
+|  | User ID\*/ ID người dùng | Unique user identifier, assigned by the user | X(10) |
+|  | User Name\*/Tên người dùng | Name of the user associated with the User ID | X(50) |
+|  | Password/Mật khẩu | Condition field  This field is only active and required when creating a new user.  The password must be strong enough. | X(50) |
+|  | Re-enter password/Nhập lại mật khẩu | Condition filed  This field is only active and required when viewing any record.  The re-enter password must be matched with the password. | X(50) |
+|  | Reset Password | Condition field  This field is only active and required when updating the user profile record.  Click to reset the password in case the user forgot the password.  See more on “ Reset password” | Hyperlink |
+|  | Email \*/Email | User’s email address. A password reset link can be sent to this address if the system is configured to do so.  User can use this email to log in in the system instead.  The email must be unique value | X(100) |
+|  | Default Language\* /Ngôn ngữ mặc định | Determines the language in which the screen labels are displayed. | Drop-down  Select one |
+| **Access Detail** | | | |
+|  | Access Day \*/Ngày truy cập | Seven checkboxes, each of which indicates the day of week on which the user has (checked) or has no (unchecked) access to the system. | Check box  Allow to check more than one value |
+|  | Access time \*/Thời gian truy cập | On days when user has access, the Access Time is the time on and after which user has access to the system – i.e. is able to log in to the system | Time |
+|  | User Profile Effective From Date \*/Tài khoản có hiệu lực từ ngày | Date on and after which this User Profile is effective and the user can log in to the system | Date |
+|  | User Profile Effective End Date\*/Tài khoản hết hạn sau ngày | Date on and before which this User Profile is effective and the user can log in to the system  After this day user can no longer log in to the system | Date |
+|  | User Group\*/Nhóm người dùng | A drop-down listing the available User groups. The selected group determines the functions to which the user that this user profile is defined for has access. | Drop-down  Select one |
+|  | Report Access Right/ Quyền truy cập báo cáo | Drop-down listing the Report Access Rights groups. The selected Report Access Rights group determines which report(s) the user has access to. | Drop-down  Select one |
+|  | User Status\*/Trạng thái người dùng | Drop-down to select following user status:  Active  Blocked  If account is blocked then user can no longer login into the system. | Drop-down  Select one |
+| **Reset Password**  A pop-up will be appeared when user click to Reset password | | | |
+|  | New Password\*/ Mật khẩu mới | Enter new password  Password must be strong enough. | X(50) |
+|  | Re-enter Password\*/Nhập lại mật khẩu | Enters their new password again to confirm | X(50) |
+|  | Save /Lưu | Click to accept the change | Button |
+|  | Cancel /Hủy | Click to cancel the change | Button |
+| **User Permission / Quyền người dùng**  **Display for any active User Profile records**  **The list contains all permission which applicable for the chosen user** | | | |
+|  | “Top level module name”  E.g: Customer Management | The name of top-level module. | Display |
+|  | “Second level Module name” E.g: Card | The name of the seconde level selected module. | Display |
+|  | “Second level Module name” E.g: Card | Click on the second level module to bring up the popup show the access rights fields of chosen module. | Hyperlink |
+|  | View /Xem | Checked if allow  Unchecked if disallow  N/A if not applicable this action to that module | Display |
+|  | Create/Thêm mới | Display |
+|  | Edit /Sửa | Display |
+|  | Delete/Xóa | Display |
+|  | Copy /Sao chép | Display |
+|  | Approve /Phê duyệt | Display |
+|  | History/Xem lịch sử | Display |
+|  | Template/Tạo biểu mẫu | Display |
+
+### Post-Conditions
+
+When create new record then the new user account is successfully created in the system.
+
+The new user receives an email notification with login instructions and temporary password.
+
+When password is resetted then an email notification will send into user’s email with new password to user can login into the system again.
+
+### Exception Flow
+

docs/specs/archive/oneadmin.md

@@ -0,0 +1,186 @@
+---
+title: "OneAdmin™"
+type: OpenSpec
+status: Draft
+---
+# OneAdmin™
+
+## Overview
+
+1. OneAdmin™ is a browser-based application framework based on which all OLS administration screen functions are implemented.
+2. This section describes the admin screen functions in general.
+3. OneAdmin™ provides the screen functions such as the following for users to administer OLS:
+
+|  |  |
+| --- | --- |
+| * 1. Application parameters and campaign management | * 1. Creating and reviewing customer information through menus |
+| * 1. Viewing and Posting of transactions for award, redeems and adjusts | * 1. Requesting for generation and viewing of reports. |
+| * 1. Creating and reviewing catalogue information. | * 1. Generic Ledger management |
+| * 1. Creating and reviewing merchant information | * 1. Posting of transaction testing for award, redeem and adjusts. |
+
+1. Maintenance actions supported include:
+   1. “**Add**”, to add a new record in the module or function. See section 3.6 for an illustration of the [Add](#_Add_Form) form for adding a record.
+   2. “**Edit**”, to modify an existing record on the module or function. See section [Edit](#_Edit_Form) for an illustration of the Edit form for editing a record.
+   3. “**Copy**”, where user can add a new record with the contents of a currently selected record: user will be prompted to change key values which are not allowed to be replicated across records. See section [Record Copy](#_Record_Copy) for an illustration of the record copy screen.
+   4. “**History**” tab brings up a display of previous versions of this record. See section [History](#_Record_History) for an illustration of the History screen.
+   5. “**Save**” will save the record displayed in the edit form to the database (whether it’s a new record or changes made to an existing record).
+   6. “**Cancel**” will cancel the action.
+   7. “**Approve**”, to accept the change of the record in the module or function.
+   8. “**Reject**”, to reject the change of the record in the modue or function.
+   9. “**Save as Draft**”, to temporary save the record in the module or function without publishing it.
+   10. “**Save as Template**”, to save the record displayed in the form to re-use in the furture as a template.
+2. When first “saved”, the record is stored with its Status set to “Pending”.
+3. It has to be selected (by click on the “Pending” tab to locate records with Status = “Pending”), then clicking on the record to view and/or approve it.
+4. Upon approval, the record status is set to “Active”.
+5. See section [Approve](#_Approve_Pending_Record) for the process to “**Approve**” pending records.
+6. “**Delete**” marks the record being displayed as deleted or “inactive”.
+7. The record will be copied into a new record with its status set to “Pending”, and the original record will be left intact.
+8. A user with the necessary “Approval” rights must approve the deletion for the record to be deleted and blocked from further use.
+9. All updates posted through OneAdmin™ are reflected in the database immediately on approval.
+
+## Types of Screen Layouts
+
+1. OLS admin screen functions are generally made up of 3 types of screen layouts, each corresponding to the screen function
+2. The first is the **Home Page** – there is only one of this. This screen is displayed after a successful log in.
+3. The second is the **Listing** **Page**:
+   1. This class of screens is displayed when module in the navigation panel (Menu) is clicked.
+   2. It generally displays a default list of records that can be accessed through the module.
+4. The third type of screens is the “**Details Page**” layout:
+   1. This is the page displayed after a record in the Summary Listing page has been selected.
+   2. It shows the details of the selected record at the field level
+   3. In some cases, access to child records of the record on display is provided as tabs in the screen.
+5. The general features of each type of screen layout are described in the following sub-sections.
+
+## Home Page
+
+1. The following figure illustrates the Home Page screen:
+
+Main Menu
+
+1. The left panel (navigation panel) lists the module and functions to which user has access. The actual functions available in the navigation panel vary depending on the access rights of the user id that is used to log into the system. Only the functions to which the user has access will be displayed.
+2. The main display area shows charts of key statistics, pre-configured at time of deployment.
+3. Each of the listed modules in the navigation panel expands when clicked to show the functions available under that module.
+
+[Image Removed]
+
+Figure: The “Campaign Managemetn” module in illustrates this expanded view.
+
+This module has 07 functions – “Campaign Insight”, “Campaign”, “Campaign Rule”, “Pool Definition”, “Pool Conversion Rate”, “Counter Definition”, and “Account Type Group”.
+
+The total number of pending records on each module is displayed on the right side of the module name.
+
+1. Clicking on a function will bring up the summary listing page for that function: see section 3.4.
+
+## Summary Listing Screens
+
+1. When a function in the navigation menu is clicked, the main display area will typically show the summary listing page for that function.
+2. The typical layout is illustrated in the following:
+
+[Image Removed]
+
+Sample Summary Listing Screen Layout
+
+1. In the following table, the row numbers correspond to the display areas enclosed in red boxes with the same number:
+
+| Box | Description |
+| --- | --- |
+|  | The name and the path of the function are displayed at the top left corner of the main display area, in this case “Campaign Management > Pool List” – i.e. the function for maintaining “Pool Definition” records. |
+|  | The top right conner of the screen displays the language, with an icon of the language and language name.  To change the display language, click on the icon to choose another language. |
+|  | The top right corner of the screen displays the user id and an icon of the user, with a description of the user’s access rights, i.e. the actions to which the user has access.  To leave this screen simply click on the destination module and function in the navigation menu. |
+|  | The module name |
+|  | The area labelled in red displays the quick search form. It contains input boxes for filtering the records to be displayed.  There are two modes of search – the **Quick search**  mode and **Filter** mode:   * The **Quick Search** mode search involves searching by key word:   + Provides users with a fast and efficient way to access search functionality without navigating through multiple pages with the selection record status in the area 7.   + Entering keyword on the text box.   + By click on the  icon or press “Enter” key to get result. The system will display the list of records where the keyword is found in any column on the listing page except date time data type coulmn, in the area labeled as box number 9.   + The search uses the "Contains" operator in a case-insensitive manner to find the matching record |
+|  | The area labelled 4 in red displays the link to the advanced filter form where multiple fields can be set up as part of the search/filter criteria.   * The advanced mode involves clicking on the “**Filter**” link. * When click on the “Filter” button the advanced filter form that appears is illustrated as following:   [Image Removed]  Figure 1 – Example of the Advanced Filter Form   * When click to “Add” button the form that appears as illustrated in red box in area 2 as following:   [Image Removed]  Figure 2 – Example of the Advanced Filter when add any filter  In the red box, which represents the Advance Filter form (area 2):   * + Three purple boxes appear in the adjacent areas: area 4, area 5, and area 6.   + In the area 4, there is the “Search Field” drop-down a data field name by which to search. The system list all available **field in the listing page by the default, except “Action” and “Status” field.** * Some specific modules will need include custom filter field, that are not displayed on the listing page such as: “Customer Profile” and “Transacion History” screen. See more on its section. * Users can choose from the available data fields to narrow down their search.   + In the area 5, there is the “Search Operator”. For each data type‘s search filed then the system provides a set of “Operator” options that users can apply. These operator allow the user to specific how the field should be applied to the selected filter field.   All available operator according on each data type’s search field are described on the following table:   |  |  |  | | --- | --- | --- | | **Index** | **Data Type** | **Operator** | |  | Character | A drop dow to select following values:   * Equal * Not Equal * Empty * Not Empty * Contains * Not Contains * In * Not In | |  | Number | A drop dow to select following values:   * Equal * Not Equal * Greater Than * Less Than * Greater than Or Equal to * Less than or Equal to * Between | |  | Boolean | A drop dow to select following values:   * Equal | |  | Datetime | A drop down to select following values:   * Equal * Not Equal * Greather Than or Equal To * Less than or Equal to * Between |  * + In the area 6, there is the “Value Field”. This field can be of two types: Text box or Drop-Down. The type of value fields (text box or drop-down) displayed to users depends on the selected operator and searched field as following: * “Empty” and “Not Empty” operator should not require a value input field. * “Between” operator of Date/Time search field should require 2 value input fields with date/ time picker to allow the users to specific the range of date /time to be used in the filter query. * “Between” operator of number search field should require 2 text boxes with number format to allow user to specific the range of number to be used in the filter query. * “In” /”Not In” operator of character search field may present a drop-down list when search field is a lookup value field on that screen, meaning it is a field that fetches data from other tables in the system . The drop-donw list all active records of the search field and allow user select multiple value to be used in the filter query. * “In”/”Not In” operator of character search field may present a text box when search field is not a lookup value field on that screen. This text box should allow the user to enter multiple values, separated by input tag. * “Contain”/”Not Contain” operator of character search field shoud present a text box. This text box should allow the user to enter multiple values, separated by input tag. They system uses “\*” to match zero or more occurrences of the preceding subexpression. * All remaining operators may present a text box input filed to allow the users to enter a filter value. The system should validate the user-entered value based on the data type of the search field. * There is no sensitive case for character search fields. * All selected fields are used in an “AND” search. * On clicking the “Adanced Search” button, the list of records found to have the matching value would be displayed in area in box number 9. * Searching by “Filter” and “Status” be done together as an AND condition. * On clicking the “Reset” button, the system delete all filter field and return all records by the slection status. |
+|  | This are contains three distinct tabs, each representing a different record status: Active, Pending and Rejected.  On the “Pending” tab the system show the total number of pending records next to the tab label. |
+|  | This area contains the pagination control links – to page forward, backward or to navigate directly to a numbered page with the number of records displayed and the number of record in total. |
+|  | This is the main display area listing the first N records within the function selected, where N defaults to a system parameter. N can be changed in drop-down box in area 8.  The top row contains the column headings, with up to N numbered rows below it.  The right-most column in are 10, inclues the actions for viewing, editing, deleting and approval the record in each row. |
+|  | This area shows the number of records displayed and the number of record in total. |
+|  | This is the Add button which when clicked brings up the edit form described in section 3.6, for adding a new record in the system. |
+
+## Detail View
+
+1. When the View icon for a row is clicked in the Summary List page as described in section 3.4, the details of the record in that row is displayed as illustrated in the following:
+
+[Image Removed]
+
+Figure 3 – Sample Record View Screen with Labelled Areas
+
+[Image Removed]
+
+Figure 4 – Sample Record History
+
+|  |  |
+| --- | --- |
+| Box | Description (Refer to figure 3 and figure 4) |
+|  | * This area display the name of the module with the record status and record primary key. |
+|  | * Clicking on the “Copy” button brings up the view described in section 3.10. This feature provides a convenient means by which to create new records by changing existing records. The “Copy” feature is provided only for selected functions where a “Copy” action is practical. * Clicking on the “Edit” button, the fields are displayed with details of the record in that row, awaiting user input to amend the details. * Clicking on the “Delete” button brings up the pop-up to user confirm the deleted action. |
+|  | * The function accessed is displayed as a tab. * If the function has data which can be categorised separately in a logical way, each category is displayed as a different tab. * This area shows the tabs available and clicking on the tab brings up the display for that category of data. |
+|  | * This area shows the details of the record. |
+|  | * The panel on the right/bottom displays supplementary data relating to the record in the main display area (area 5). The details in the right panel vary depending on the function. |
+| 7 | * Clicking on the “Back” button brings the view back to the Summary Listing page. |
+| 8 | This area shows when the record was last changed, and by whom.   * Every time a record is updated or approved, the user id that last made the change and the user id that last approved a change are logged with the record, together with the date and time of the action. * This information is always shown at the bottom of the record details screen display. * Only records with Status = “A” for Active are taken into account during transaction processing: if a record status is not active it will not be taken into account for any transaction processing. * The “Last Updated By” field shows the user id of the user who last updated this record. If the record is updated by a batch process, this field will contain the Batch Id. * The “Last Updated Date” field shows the date and time when the record was last updated. * The “Last Approved By” field shows the user id of the user who last approved this record. For updates by programs (batch processes and online transactions), this field is empty. * The “Last Approved Date” field shows the date and time when the record was last Approved. For updates by programs (batch processes and online transactions), this field is empty. |
+| 9 | This area shows when the action records may can be changed   * Clicking on the “History” records will bring up the display described as in area 4. * By choose the 2 version and clicking the “Compare” button will bring up the display described in section 3.8: Record History. Feature allows for easy browsing of the changes made to the record |
+
+## Add/ Edit Screen
+
+1. When the Edit /add for a row is clicked in the Summary List page, the details of the record in that row is displayed in the edit form for editing, as illustrated in the following:
+
+[Image Removed]
+
+Figure 3 – Sample Record Edit Form with Labelled Areas
+
+1. Each row in the following describes the correspondingly numbered area in Figure 3:
+
+|  |  |
+| --- | --- |
+| Box | Description (Refer to Figure 3) |
+|  | This area shows the function for which the edit form is being displayed. |
+|  | This is the main edit form.   * Mandatory input fields have a coloured border on the left. * If the edit form is displayed as a result of the “Add” button being clicked in the previous screen, the fields will be displayed empty, awaiting user input * If the edit form is displayed as a result of the “Edit” button being clicked in the previous screen, the fields are displayed with details of the record in that row, awaiting user input to amend the details. |
+|  | * The “Create”/”Update” button will save the changes or in the case of the “Add” action, the input data, in the database as a new record with record Status = “Pending”. Note that the record being changed (“original record”) will remain unchanged. |
+|  | * The Cancel button causes any input or change made to be discarded and the display will return to the previous summary listing page. |
+
+## Approve Pending Record
+
+1. When a new record is first added, or when an existing record is “Changed” or “Deleted”, the new or modified record is inserted in the database with a Status set to “Pending”.
+2. The original record remains active.
+3. The “Pending” records must first be “Approved” by a user who has the rights to the “Approve” action for that function before the change becomes effective.
+4. To “Approve” a record, the record must first be located by clicking for records with the “Pending ” tab as illustrated here:
+
+[Image Removed]
+
+Figure 4 – Search for Pending Records
+
+[Image Removed]
+
+Figure 5– Pending Record Listing
+
+1. In change mode, the record values with and without the change are both displayed for comparison.The previous value (before change) and the modified value,that pending approval are displayed side by side, with modified fields displayed in a font of a different color, as illustrated:
+
+* Red text highlights changes of the active record, ~~Red text~~ highlight with strikethrough effect for the deteled data.
+* Green text highlights changes of the pending record.
+* **Black text** denotes unchanged information in both record versions.
+
+[Image Removed]
+
+Figure 6 – Pending Record Displayed Side-by-side with Currently “Active” Record
+
+1. At this point, it is possible to click on the Modify button to edit the record and save it back into the Pending list. The user who edits the record will not be able to “Approve” the change.
+2. Click on the “Approve” button to put the record into active use.
+3. Click on the “Reject” button to return the record to the Reject list for follow-up and correction.
+4. Users can “Approve/Reject” record from detail view mode or by clicking on the “Approve/Reject” button from listing page.
+
+## Record History
+
+1. The “History” feature is for scanning through historical versions of a record.
+2. When in the Record Detail view, clicking on the “History” Tab will bring up the all version of the record.
+3. When the “Compare” button is clicked, the display will show details of two chosen version as following:
+
+[Image Removed]
+
+Figure 7 – Sample Display of a Record’s History
+
+|  |  |
+| --- | --- |
+| Box | Description (Figure 7) |
+|  | Drop-down lisitng all history version inclues currently version.  Users can change version to compare by select the verion to compare. |
+|  | Details displayed in the change history of two selected versions by the version in the drop-down list in area 1.   * Red text highlights changes of the record in the red drop-down in the area 1. * Green text highlights changes of the redcoed in the green drop-down in the area 1. * **Black text** denotes unchanged information in both record versions. |
+

docs/specs/archive/onecatalogue.md

@@ -0,0 +1,377 @@
+---
+title: "OneCatalogue"
+type: OpenSpec
+status: Draft
+---
+# OneCatalogue
+
+## About Redemption Item in OLS system
+
+### Overview
+
+1. The catalogue is used to set up items for online (web site, Mobile App) redemptions.
+2. Redemption items such as Cash-back rebates, frequent flyer miles conversion and merchant vouchers can be set up in the redemption catalogue.
+3. Front-end systems access the catalogue through web services to display available items.
+4. Front-end systems accept user requests to redeem and send these requests to OLS for authorization (deduction of the relevant points) and to generate the fulfilment files for sending to designated recipient systems.
+5. Catalogues are managed through the browser-based administration screens, which update the catalogue in real-time. Once “Approved” the item is available commencing on the Start Date.
+6. Functions include adding catalogues to the system, adding items to catalogues, setting price rules and processing redemption requests from front-end systems.
+7. OLS also provides an administration function for back-office staff to redeem items through the administration screens directly on behalf of customers.
+
+## Catalogue
+
+### Requirement Definition
+
+* + - 1. A Catalogue must be defined and all items to be included in the Catalogue must be tagged with the Catalogue code before customers access the items.
+      2. A Catalogue code is tagged against each Item Master record.
+      3. More than one Catalogue can be configured at the same time, but each Catalogue must have its own set of Item master records.
+      4. Each Catalogue has a Start / End date range and items in the Catalogue will be picked for presentation to customer only if the current date falls in the Start / End date range for that Catalogue.
+
+### Process Flow
+
+==tbd==
+
+### Trigger
+
+* + - * 1. If an item is to be tagged to a Catalouge that has not yet been defined.
+
+### Pre-Conditions
+
+1. Users have to have access rights in “Catalogue” screen under “OneCatalouge” module.
+2. Depending on the user's access rights, they can view, add, edit, or approve catalogue records.
+
+### Wireframe
+
+[Image Removed]
+
+### Business Rules
+
+1. Click on Catalouge icon in navigation panel under OneCatalouge to get a listing of existing catalogs.
+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 for Catalouge is illustrated in section 7.2.5.
+3. **Descriptions**
+
+|  |  |  |  |
+| --- | --- | --- | --- |
+| **Index** | **Field** | **Description** | **Data type** |
+| **General Information /Thông tin chung** | | | |
+|  | Catalogue Code \*/Mã nhóm danh mục | User-specified code identifying the catalogue. Used by front-end system when requesting for item information. | ~~X(20)~~  X(10) |
+|  | Description\*/ Mô tả | A description of this catalogue. For user reference only.  Default description which will be used in case there is no specific description for chosen language. | X(50) |
+|  | Effective From Date \*/Có hiệu lực từ ngày | Catalogue is effective only when the processing date is between Start Date and End Date, inclusive. | Date |
+|  | Effective To Date \*/Có hiệu lực đến ngày | Date |
+|  | Icon/ Biểu tượng | Allow to upload/remove the icon of catalogue | Image |
+| **Content Configuration: This step is used to setup the description of catalogue follow each language.**  **This is optional step** | | | |
+|  | Select Language /Chọn ngôn ngữ | Click to add specific description | Button |
+|  | Language \*/Ngôn ngữ | A drop-down list to select the language which need to be setup specific description. | Drop-down  Select one  Get from master data |
+|  | Description\*/Mô tả | A description of this catalogue. For user reference on MP only. | X(100) |
+
+### Post- Conditon
+
+The Catalouge information for each item can be returned to the front-end during an Item Enquiry response message for the front-end to use in searching the catalogue for items.
+
+### Exception Flow
+
+N/A
+
+## Category
+
+### Requirement Definition
+
+A catalog is the main folder to organize categories and items for materials. A category is a group within a catalog that contains items. All items to be included in the Catalogue must be tagged with the Category code. Multiple Categories can be linked to form a hierarchy of categories. The hierarchy of categories is used on Member site.
+
+### Process Flow
+
+### Trigger
+
+If an item is to be tagged to a catagory that has not yet been defined.
+
+### Pre-Conditions
+
+1. Users have to have access rights in “Category” screen under “OneCatalouge” module.
+2. Depending on the user's access rights, they can view, add, edit, or approve category records.
+
+### Wireframe
+
+[Image Removed]
+
+### Business Rules
+
+1. Click on the category icon in the navigation panel under OneCatalouge to get a listing of existing catalogues.
+2. 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 category is illustrated in section 7.3.4.
+3. **Descriptions**
+
+|  |  |  |  |
+| --- | --- | --- | --- |
+| **Index** | **Field** | **Description** | **Data type** |
+| **General Information /Thông tin Chung** | | | |
+|  | Category Code \*/Mã danh mục vật phẩm | User-specified code identifying the category. Used by front-end system when requesting item information. | ~~X(20)~~  X(10) |
+|  | Description\*/ Mô tả | A description of this category. For user reference only.  Default description which will be used in case there is no specific description for the chosen language. | X(100) |
+|  | Effective From Date /Có hiệu lực từ ngày | Category is effective only when the processing date is between the Start Date and the End Date, inclusive.  If an effective date is not provided then this is a non-expire category. | Date |
+|  | Effective To Date /Có hiệu lực đến ngày | Date |
+|  | Parent Category | Multiple Categories can be linked to form a hierarchy of categories. | Drop-down  Select one  The parent categories value from master data. |
+|  | Display Ordering /Thứ tự hiển thi | The display ordering sequence on the Member Site. | 9(3) |
+|  | Icon/ Biểu tượng | Allow to upload/remove the icon of the category. | Image |
+|  | Image group /Nhóm hình ảnh | Drop-down list to select the image group | Drop-down  Select one |
+|  | Image /Ảnh vật phẩm | Condition field  This field is only active and required when the image group is selected | Drop-down  Select one  Lookup value from Image Stock screen by selected image group. |
+|  | Preview | Preview of selected image | Image |
+|  | Add image/Thêm mới ảnh vật phẩm | Quick add feature to support user add image from this screen. The new image will be automatiom approved when the category is approved | Button |
+| **Content Configuration: This step is used to setup the description of catalogue follow each language.**  **This is optional step** | | | |
+|  | Select Language /Chọn ngôn ngữ | Click to add specific description | Button |
+|  | Language \*/Ngôn ngữ | A drop-down list to select the language which need to be setup specific description. | Drop-down  Select one  Get from master data |
+|  | Description\*/Mô tả | A description of this category in the choosen language. For user reference on MP only. | X(100) |
+
+### Post –Condition
+
+### Exception Flow
+
+## Item master
+
+### Requirement Definition
+
+Describe details about a particular item: e.g. prices, quantities, availability dates, terms and conditions, etc. Item Master Records cannot be created unless the Stock Code is in place.
+
+### Process Flow
+
+### Trigger
+
+New items need to be defined.
+
+### Pre –Condition
+
+1. Users have to have access rights in the “Item Master” screen under the “OneCatalouge” module.
+2. Depending on the user's access rights, they can view, add, edit, or approve Item Master records.
+
+### Wireframe
+
+[Image Removed]
+
+### Business Rules
+
+1. Click on Item Master icon in navigation panel under OneCatalouge to get a listing of existing catalogs.
+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 for Item Master is illustrated in section 7.4.4
+3. **Description**
+
+|  |  |  |  |
+| --- | --- | --- | --- |
+| **Index** | **Field** | **Description** | **Data type** |
+| **General information: Mandatory Step** | | | |
+|  | Catalogue Code\*/Nhóm vật phẩm | The Catalogue for which this item is being configured. | Drop-down  Select one |
+|  | Category/Danh mục vật phẩm | Select the category under which this item is to be tagged, to facilitate searching in the customer-facing page – e.g. Retailer Vouchers, Frequent Flyer Points, Cash Rebate, etc. | Drop-down  Multiples select |
+|  | Item Code\*/Mã vật phẩm | Enter the item code to be added to the catalogue.  This is Item identify. | X(10) |
+|  | Item Name \*/Tên vật phẩm | Short description field used by customer-facing application for display for Catalogue item. The text can include control characters.  This is default name in case there is no specific item name of chosen language in the member site. | X(50) |
+|  | Redemption From Date From\*/Có hiệu lực từ ngày | “**From Date**” & “**To Date**” specify the period within this item is available and may be included in the Catalogue display and when after which it becomes unavailable and is excluded from the Catalogue display.  OLS will reject the Start Date and End Date if they are outside the Catalogue/Category Start Date and End Date period.  Once the item has been started for redemption, only End date will be allowed to modify. | Date |
+|  | Redemption To Date \*/ Có hiệu lực đến ngày | Date |
+|  | Redemption Store /Đối tác | Supplier of this item. The merchant (Store) that has to be configured appropriately in order for straight-through settlement processing. | Drop-down  Select one |
+|  | Redemption Transaction Code\*/Mã giao dịch đổi thưởng | OLS TC used for redemption processing and logging. | Drop-down  Select one |
+|  | Award Transaction Code/Mã giao dịch tặng thưởng | OLS TC  If selected, the **OLS** **Transaction Code”** used to locate any award campaign rules to be executed as a result of the catalogue item redemption. | Drop-down  Select one |
+|  | Item Type \*/ Loại vật phẩm | The type of item  Choose one of following types :   * + 1. Miles     2. Physical     3. eVoucher     4. Donation     5. Cash rebate     6. Other | Radio button  Item type list from master data |
+|  | Voucher Code /Mã voucher | Condition field  A drop-down to select voucher code  This field is only active and required when item is an eVoucher | Drop-down  Select one |
+|  | Face value/ Partner Point / Giá trị vật phẩm | Condition field  This field is only active and required for Cash rebate/eVoucher/Miles item.  This is the value of the cash rebate/voucher /miles that customer sees. This value is not used if the Face Value is also specified in the Item Price set-up | 9(14,2)  Should be positive value |
+|  | Display on Member Site | Turn off to restrict this item in member site. | Switch button  Default ON |
+|  | Hot item /Vật phẩm hot | Condition field  This field is active only when this item is displayed on the member site  Choose to indicate this is a hot item. Used to display on Member Site. | Switch button  Default OFF |
+|  | Display Ordering/ Thứ tự hiển thị | Condition filed  This field is active only when this item is displayed on the member site  The ordering sequence to display on member site | 9(3)  Should be greater than 0 if provided |
+|  | Track Quantiy on Hand/ Theo dõi số lượng vật phẩm | ON mode if the item is an item and that requires inventory control: the “Quantity-on-Hand” is updated for such items during redemption.  If this is a Voucher Code item, this field is force-set to Yes and cannot be changed. | Switch button  Default OFF |
+|  | Initialize Quantity of Stocks/ Số lượng ban đầu | Condition filed  This field is only active and required if track quantity on hand. Canot edit this value if this item has been redeemed.  This field is not activated for the Evoucher item due to the number of voucher being generated by another feature (via the Voucher Code screen or batch file). | 9(9)  Should be positive value.  In case item has been redemmed, then not allow to modify this field. Just display only |
+| **Item detail : Mandatory step**  **This step involves configuring the details of each item in multiple languages. By doing so, the system can utilize the specific details tailored to each language.** | | | |
+|  | Select Language /Chọn ngôn ngữ | Click to add specific item detail. | Button |
+|  | Language \*/Ngôn ngữ | A drop-down list to select the language which need to be setup specific description. | Drop-down  Select one  Get from master data |
+|  | Item name\*/Tên vật phẩm | Specific item name in the choosen language. | X(50) |
+|  | Item Description/Mô tả vật phẩm | Specific item description in the chosen language. | X(100) |
+|  | Item content/Thông tin chi tiết | The content of item in the choosen language | X(2000) |
+|  | How to use /Cách sử dụng | The way to use the item in the choosen language | X(2000) |
+|  | Term and Conditon/ Điều khoản | Term and Conditon  Free text to be returned in the Terms and Conditions field in the Web Service message and in redemption output template letters and email. | X(2000) |
+| **Item Image /Ảnh vật phẩm**  Optional step | | | |
+|  | Select image | Click to add image for item | Button |
+|  | Image group /Nhóm hình ảnh | Drop-down list to select the image group | Drop-down  Select one |
+|  | Image /Ảnh vật phẩm | Condiiton field  This field is only active and required when image group is selected | Drop-down  Select one  Lookup value from Image Stock screen by selected image group. |
+|  | Sort Order | The display odering sequence on Member Site. | 9(3)  Should be greater than 0 if provided |
+|  | Preview | Preview of selected image | Image |
+|  | Add image/Thêm mới ảnh vật phẩm | Quick add feature to support user add image from this screen. The new image will be automatiom approved when the category is approved | Button |
+| **Contact and Address information**  Optional step | | | |
+|  | Add Address | Click to add item address where we can to use this item | Button |
+|  | City\* | The drop-down to select the city where can use this item | Drop-down  Select one |
+|  | Address | Address detail | X(200) |
+|  | Email | Email address | X(100) |
+|  | Phone | Phone number | X(20) |
+
+### Post-Conditions
+
+* + 1. The newly created item should have all required fields populated with valid data.
+    2. The system should add/updated items in the database.
+    3. Other screen which lookup to item screen must be able to use new item.
+
+### Exception Flow
+
+## Item price
+
+### Requirement Definition
+
+* + - 1. Outlines the specifc criteria, functionalities and parameter that determine and manage item prices in the OLS:
+    1. Point valuation: Define the conversion rate between reward points and redemption quanity (e.g 100 point = 1 Ticket movie voucher) to establish the baseline for item redemption.
+    2. Criterions pricing: specify if different pricing tiers will be available for customer based on their account type or redemption channel or specific criterions such as gender, redemption quantity,etc.
+    3. Redemption options: Define the types of items price available for redemption, including using point only or both cash and points.
+
+### Process Flow
+
+[Image Removed]
+
+### Trigger
+
+* + - 1. New item is defined and must define item price to process redemption processing for this item.
+      2. If an item is to be tagged to a price that has not yet been defined.
+
+### Pre-Conditions
+
+1. Users have to have access rights in “Item Master” screen under “OneCatalouge” module.
+2. User have to have access rights in “Item Price” Screen under “OnCatalouge” module.
+3. Depending on the user's access rights, they can view, add, edit, or approve Item Price records.
+
+### Wireframe
+
+[Image Removed]
+
+### Business Rules
+
+1. Click on Item Master icon in navigation panel under OneCatalouge to get a listing of existing item master.
+2. Click to view detail any active item master records to bring up the “Item Price” screen as a new tab under item master detail record.
+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 Item Price is illustrated in section 7.5.5
+4. **Edit Screen Description**
+
+|  |  |  |  |
+| --- | --- | --- | --- |
+| **Index** | **Field** | **Description** | **Data type** |
+| **General information** | | | |
+|  | Item Code \*/ Mã vật phẩm | Item code | Display if configure item pirce under specific item.  Drop-down list to select an item code to configure the item price |
+|  | Price Code\*/Mã giá | The identify of the item price  For user refrence only | X(10) |
+|  | Pirce Name \*/Tên giá | Default name of the price  For user reference only | X(100) |
+|  | Effective Start Date \*/ Hiệu lực từ ngày | **From Date**” & “**To Date**” specify the period within this price. | Date |
+|  | Effective End Date \*/ Hiệu lực tới ngày | Date |
+|  | Redemption Channel \*/Kênh đổi thưởng | The drop-down to select the redemption channel. Supported channels are:  Call Center  Mobile Application  Internet Banking  Etc | Drop-down  Select one |
+|  | Account Type Group/Nhóm loại tài khoản | Optional filed  If Account Type or Account level is selected then account type group is blocked and vice versa. | Drop-down  Multi-select |
+|  | Product Account Level /Hạng tài khoản | Optional field  The drop-down to select the Account level (Card Level) to this this price applies. Leave as empty if all Account level are applies to this prce.  If Account type group are selected in previous step then this field is blocked and vice versa | Drop-down  Select one |
+|  | Product Account Type/Loại tài khoản | Optional field  Optional field  Multi-select drop-down to select the Account Type (Card Type) of selected account level in previous step which will be applies to this price. Leave as empty if all account types of selected PAL are applies to this price.  If Account type group are selected in previous step then this field is blocked and vice versa | Drop-down  Multi-select |
+|  | Redemption Pool\*/Pool đổi thưởng | Select the Pool from which to deduct points for redeeming this item | Drop-down  Select one |
+|  | Use Only Points from Selected PA Type/Chỉ sử dụng điểm từ các loại nhóm tai khoản được chỉ định | Restrict the use of points for redemption of this item at this price to only points earned by the selected account Type/ATG | Switch button  Default OFF |
+|  | Face value /Trị giá vật phẩm | If transacting Customer/Account meets the criteria in this set-up, what the Customer receives is this “Face Value”. E.g. if this is 500  KrisFlyer Miles, Customer receives 500 KrisFlyer Miles for redeeming one of this item. | 9(12,2)  Should be greater than 0 if provided |
+|  | Price in point \*(Full redemption) / Giá trị điểm | Price of item if paid for fully in points from the selected Pool | 9(12,2)  Should be greater than 0 if provided |
+|  | Original price /Giá gốc | The original price of the item  For user reference only | 9(12,2)  Should be greater than 0 if provided |
+|  | Partial Redemption Allowed/Cho phép đổi thưởng 1 phần | If allowed, customer can use a mix of points and cash to pay for this item. The number of points and amount of cash are derived from “Price in Cash Value-per Point” and “Minimum Partial Redeem Points”. See the description for these fields. | Swith button  Default OFF |
+|  | Minimum Partial Redeem Points/Số điểm tối thiểu | Condition field  This field is only active and required when Partinal Redemption is allowed.  Customer must use at least this number of points to redeem this item. | 9(12,2)  Should be greater than or equal to 0 if provided  0 for full cash redemption |
+|  | Cash per point/ Số tiền chi trả | Condition field  This field is only active and required when Partinal Redemption is allowed.  This is used to calculate the amount of cash required to redeem this item after taking into account the points redeemed, if any. | 9(12,2)  Should be greater than 0 if provided |
+|  | Appliable Taxes | The drop-down list to select the tax rate to be applicable. | Drop –down  Select one  Get data from “Tax Rate Maintenance” Screen |
+| **Price detail :**  **Optional step. If not provide then use default item price name to display if needed** | | | |
+|  | Select language /Chọn ngôn ngữ | Click to add item price detail on each language  For user reference only | Button |
+|  | Language \*/Ngôn ngữ | The drop-down to select the language to setup the specific item price detail | Drop-down  Select one |
+|  | Item price Name \*/Tên giá | The specific name of chosen language  For user reference only | X(100) |
+|  | Description/ Mô tả | The description of the price  For user reference only | X(500) |
+| **Item criteria**  A part to add criteria to meet the price  The approach the same as Rule criteria but just display all criteria which be tagged to “Item price “ module only | | | |
+|  |  | [Image Removed] | Click to add new criteria |
+|  |  | [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. |
+|  |  | [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. |
+|  |  | Right panel | List all active criteria on the system.  Each criteria per category will be defined as an attribute and to be tagged for “Item Price “ module |
+|  |  | 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. |
+|  |  | [Image Removed] | Click to delete criteria |
+|  |  | [Image Removed] | Operator between difference groups on the same campagn rule OR operator between difference criterions on the same group per each Campaign Rule. |
+
+### Post-Conditions
+
+With the item price configuration then here is the flow to get item price.
+
+Valid price
+
+[Image Removed]
+
+What is the price of the transaction
+
+[Image Removed]
+
+### Exception Flow
+
+## Voucher Code
+
+### Requirement Definition
+
+1 If the Item to be set up is for distribution of Voucher Numbers to customers, and these Voucher Numbers are from external partner merchants, then the Voucher Numbers must first be set up in OLS by uploading/creating the stock of Voucher Numbers.
+
+2 This voucher upload file must contain the Voucher Code (which identifies what this voucher is for – e.g. “$5 Lazada Voucher”), the period within which the vouchers are accepted at the partner merchant, and the individual voucher serial numbers (Voucher Numbers).
+
+3 The file format is set out later (to be decided).
+
+4 This upload can be done using the “Upload” functions in this screen.
+
+### Process Flow
+
+### Trigger
+
+N/A
+
+### Pre-Conditions
+
+1. Users have to have access rights in “Voucher Management” screen under “OneCatalouge” module.
+2. Depending on the user's access rights, they can view, add, edit, or approve Voucher records.
+
+### Wireframe
+
+* + - 1. **Create/Edit mode**
+
+[Image Removed]
+
+* + - 1. **View mode**
+
+[Image Removed]
+
+1. Listing page
+2. **Voucher Detail view** 
+   1. Listing Page
+
+[Image Removed]
+
+* 1. View
+
+Click to any record on the listing page to bring up the detail view as following:
+
+[Image Removed]
+
+### Business Rules
+
+1. Click on Voucher icon in navigation panel under OneCatalogue to get a listing of existing Voucher Code 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 for Voucher is illustrated in section Wireframe.
+3. Double click on any existing record in Active Tab then the Voucher Detail listing is illustrated in section 7.6.5.
+4. The system just allow to view the Voucher detail only.
+5. Can not allow deleting the voucher Code if voucher have been redeemed.
+6. **Screen description**
+
+|  |  |  |  |
+| --- | --- | --- | --- |
+| **Index** | **Field** | **Description** | **Data type** |
+| **Screen 1: Voucher Code** | | | |
+|  | **Voucher statistic / Tổng hợp thông tin voucher**  **This is displayed for active record only** | | |
+|  | Total Voucher /Tổng voucher | Total the serial number voucher belong to the choosen voucher code | Display as interger format |
+|  | Available Vouchers /Số voucher khả dụng | Total the valid voucher and ready to use: The voucher has not yet been redeemed and non- expired. |
+|  | Redeemed Vouchers/ Voucher đã đổi thưởng | Total the numner of the successfully redeemed vouchers. |
+|  | Cancelled Vouchers/ Voucher đã hủy | Total the number of the fail redeemed vouchers which is cancelled by customers/system by specific reason. |
+|  | Expired Vouchers/Voucher đã hết hạn | Total the number of expired voucher that has not yet been redeemed.  Use processing date to compare with expiry date of the voucher. |
+|  | **Voucher Code Detail information** | | |
+|  | Voucher Code\*/Mã voucher | Identifies the voucher. | ~~X(20)~~  X(10) |
+|  | Description /Mô tả | The description of the voucher. For user reference only. | X(100) |
+|  | Supplier / Nhà cung cấp | The partner/ organization that issues or provides the voucher | Drop-down  Select one |
+|  | Expiry Policy \*/ Hạn sử dụng | A drop-down list with the following choices:   * Fixed Date: Voucher will expire after the date specified in the “Expiry Date” parameter. * N days from Transaction Date: Voucher will expire after N days from Redemption Date (Transaction Date). * N days from Post Date: Voucher will expire after N days from redemption transaction is posted on the OLS. * N Months from Transaction Date: Voucher will expire after N months from redemption Date. * N months from Post Date: Voucher will expire after N moths from the moment a redemption transaction is posted on the OLS. | Drop-down  Select one |
+|  | Expiry Date / Ngày hết hạn | Condition field  This field is only active and required when the expiry policy is “Fixed Date”.  **A transaction which redeem this voucher is not allowed to have Transaction Date later than this date.**  Can not allow editing the policy (including the relative field that be used to determine expiry date of the voucher) | Date |
+|  | N Param/ Tham số N | Condition field  This field is only active and required when the Expiry Policy selected in the previous step requires a parameter N param.  e.g. “N days from Transaction Date” | 9(3)  Should be greater than or equal to 0 if provided |
+|  | Generate Voucher /Khởi tạo voucher | Turn on when the voucher is generated by OLS instead partner.  The system will automation create the number of vouher which user will provide on next step.  This field can’t be changed if the voucher have been redeemed. | Swith button  Default OFF |
+|  | Quantity /Số lượng | Condition filed  This filed is only active and required if “Generate Voucher” in the previous step under ON mode.  Specifies the number of voucher codes to be generated.  **When a voucher code record is approved in the system, the system should automatically generate voucher numbers corresponding to the entered quantity.**  This field can’t be changed if the voucher have been redeemed. In case users want to change then it should be “re-stock”/ “void” voucher use case instead. | 9(5)  Should be greater than 0 if provided |
+|  | This is a promo code/ Đây là mã khuyến mãi | Turn on when this is a promo code. For user reference only | Swith button  Default OFF |
+|  | ~~Voucher Type/Loại voucher~~  Promotion Type/Loại khuyến mãi | Conditon filed  This field is only active and required when this voucher is a promo code.  A drop-down list with the following choices:   * Fixed Percentage Discount: This type of voucher offers a discount as a percentage of the total purchase amount. * Fixed Monetary Value Discount: Instead of a percentage, this voucher provides a fixed monetary discount. * Cashback Voucher: For this type of voucher, the customer receives a certain percentage of the purchase amount back as cashback to use on future purchases. * Gif Voucher: This type of voucher is often purchased as a gift for someone else. It typically has a fixed monetary value that the recipient can use towards their purchases. | Drop-down  Select one |
+|  | Value /Giá trị | The specific value which customer can get from chosen voucher type.  Condition field  This field is only active and required when “Fixed Monetary Value” / “Fixed Percentation Discount” are selected on the previous step. | 9(14,2)  Should be greater than 0 if provided |
+| **Screen 2: Voucher Detail**  **Each voucher No is displayed under one detail record in listing page**  **Voucher detail is introduced as a subtab of Active voucher record.** | | | |
+|  | Voucher Code | Choosen voucher code | Display |
+|  | Voucher No | The serial voucher number of choosen voucher |
+|  | Redemption Date | The date when voucher is redeemed |
+|  | Expiry Date | Expiry date of the voucher number which is based on choosen expiry policy of the choosen voucher |
+|  | Redemption Indicator | One of following values:   * No: If voucher is not used for any redemption transaction. * Yes: If voucher have been redeemed by customer. |
+|  | Fulfillment Status | One of following values:   * New: When voucher is created/uploaded in OLS then the fuillment status should be new to indicator that voucher to be availbale to redeem. * Issued: The FFS is changed into Issued when voucher is successfully redeemed in the OLS. * **Fulfilled: The FFS is changed into Fulfilled when voucher is successfully redeemed and partner accept this voucher.** * Cancelled: FFS is changed intpo “Cancelled” if the customer cancels the transaction or if there are issues with the voucher that prevent its redemption. * Rejected: The vendor has rejected the voucher due to some reasons such as term and conditions, policy changes.etc.   The fufillment status is updated when fulfilment status is changed. |
+
+* + - 1. User who can create new voucher can use “upload” function to upload the voucher file into OLS
+
+### Post-Conditions
+
+### Exception Flow
+

docs/specs/archive/onemarketing.md

@@ -0,0 +1,751 @@
+---
+title: "OneMarketing"
+type: OpenSpec
+status: Draft
+---
+# OneMarketing
+
+## Overview
+
+OneMarketing Module includes 2 function modules:
+
+* **Marketing Message:** Manage (CRUD features) all message templates that are used in the system.
+* **OneMarketing Request (OMR):** Filter the target customers who satisfy the set-up-criteria to send messages or get reward transactions.
+* **A/Bn Testing:** to compare at least two versions of a SMS, email, or other marketing elements to determine which one performs better.
+* **Frequency Capping:** The function to practice of controlling the frequency and volume of notifications or channel delivered to customers to avoid overwhelming them
+* **Blacklist:** A list of customer who will be blocked for reward/promotion notification from a business.
+* **Whitelist:** A list of customer who has given their consent to receive specifc types of marketing message from business.
+
+## Marketing message
+
+### Requirement Definition
+
+1. The marketing message module is used to define a communication message that will be sent to the target list.
+2. A Message Template can be built based on a message with pre-defined parameters or HTML file.
+3. User can build different messages for different marketing channels (e.g: SMS / Notification Push/ Email/ OTT …).
+
+### Process Flow
+
+[Image Removed]
+
+### Trigger
+
+N/A
+
+### Pre-Conditions
+
+1. Users have to have access rights in “Marketing Message” module to able to access this screen.
+2. Depending on the user's access rights, they can view, add, edit, or approve manually message template.
+3. Assume that all OMR criteria are defined as attribute and appear in right panel in message content part to user can drag/drop to setup.
+
+### Wireframe
+
+* + - 1. Message summary listing page
+
+[Image Removed]
+
+* + - 1. Filter
+
+[Image Removed]
+
+* + - 1. SMS
+
+1. Create SMS
+
+**Step1 : Choose message chanel : SMS and choose create new or re-use existing message template**
+
+[Image Removed]
+
+**Step 2: Step up “General information”**
+
+[Image Removed]
+
+**Step 3: Set up message content**
+
+[Image Removed]
+
+[Image Removed]
+
+**Finish by save.**
+
+1. SMS detail view
+
+[Image Removed]
+
+* + - 1. **Email**
+
+1. Create Email message
+
+**Step 1: Choose message chanel : Email and choose create new or re-use existing Email template**
+
+[Image Removed]
+
+**Step 2: Set up “General information”**
+
+[Image Removed]
+
+**Step 3: Set up “Sender information”**
+
+[Image Removed]
+
+**Step 4: Setup Email content**
+
+[Image Removed]
+
+**Upload email template**
+
+[Image Removed]
+
+[Image Removed]
+
+* + - 1. **Push notification**
+
+Create Push notification message
+
+**Step 1: Choose message chanel : Push and choose create new or re-use existing Push template**
+
+[Image Removed]
+
+**Step 2: Update “Generate information”**
+
+[Image Removed]
+
+**Step 3.1: Message content configuration for “Richer push”**
+
+[Image Removed]
+
+**Step 3.2: Message content for “Carousel push”**
+
+[Image Removed]
+
+**View mode**
+
+[Image Removed]
+
+### Business Rules
+
+1. OLS system can send a message to target customer through a notification on the app, an email, an SMS, and so on. These varied media used for message delivery are known as “channels”.
+2. In this version, OLS support to user can test message enable previewing the message to make sure the message appear exactly the way it was meant to. Just enter the email adress or phone number user wish to check the message preview.
+3. Besides, OLS support to user can setup message template to re-use in the furture.
+4. Click on the “Marketing Message” in Main icon to bring up the screen for accessing the Markting Message listing page. The detail as illustrated in the [wireframe](#_Wireframe_10).
+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 marketing message screen is illustrated in the [wireframe](#_Wireframe_10).
+6. **Screen description**
+
+|  |  |  |  |
+| --- | --- | --- | --- |
+| **Index** | **Field** | **Description** | **Data type** |
+| **Create /Edit mode** | | | |
+| **SMS message** | | | |
+|  | **Step 1: General Information** | | |
+|  | Message ID \* | Unique identifier of the Message.  Not allow special characters | X(10) |
+|  | Message Description \* | Description of message | X(100) |
+|  | SMS Type | Drop-down to select SMS type:  Promotion/Marketing  Transaction | Check box type  Select one value only  Lookup value “Code Management” table where type code is “OMR-type”.  Refer to ‘list-by-code-type’ API under Master Data. |
+|  | Effective Date From \* | The start date of the effective period of the message | Date  Date time format must respect the date configuration format |
+|  | Effective End Date \* | The end date of the effective period of the message | Date  Date time format must respect the date configuration format |
+|  | **Step 2: SMS Content Configuration** | | |
+|  | SMS Brand Name \* | Drop -down to select SMS Sender | Drop-down  Lookup value from master data |
+|  | Message \* | The message content of the SMS.  The list of message parameters are included to be used.  User can drop/drag message paramters into message.  Assumation that the list of message parameters are defined as attribute (the same approach as Rule criteria) to able to drop/drag into message.  SMS message don’t support : 1. Images   1. A subject line 2. Attachments   **SMS messages are written in Unicode (non –GSM standard). Standard single message or multi-part message are credited based on the message content.** | X(5000) |
+|  | Message parameters | The message parameter list.  [Image Removed] | Tree list |
+|  | Preview | The message will be automation displayed in the preview part. | Displaya |
+|  | The number of characters in the message\* | This value will be automatically upadated when the user update the message content. | Display as number format |
+|  | Send sample | This functions to support user can test message enable previewing the message to make sure the message appear exactly the way it was meant to.   * + - 1. A textbox to user can enter a phone number is dispalyed       2. When user click on “Send sample” a confirm message is display. It use to user confirm that the system will send a testing message into inputed phone number. User can choose “OK” or “Cancel”. If user click on “OK” button the system will send a sms message into inputed phone number.       3. Mobile phone number should be required when user click on” Send sample”. If not found should reject with error message | Button |
+| **Email message** | | | |
+|  | **Step 1 : General Information** | | |
+|  | Message ID \* | Unique identifier of the Message.  Not allow special characters | X(10) |
+|  | Message Description \* | Description of message | X(100) |
+|  | Email Type | Drop-down to select Email type:  **Promotion/Marketing**  **Transaction** | Checkbox  Allow to select only one value.  Lookup value “Code Management” table where type code is “OMR-type”.  Refer to ‘list-by-code-type’ API under Master Data.  Lookup value from master data |
+|  | Effective Date From \* | The start date of the effective period of the message | Date  The date format must adhere to the configured format |
+|  | Effective End Date \* | The end date of the effective period of the message | Date  The date format must adhere to the configured format |
+|  | Use type \* | 2 options to config email message :   * + 1. Use messge.     2. Upload template. | Checkbox  Allow to select only one value.  Lookup value “Code Management” table where type code is “email-use-type”.  Refer to ‘list-by-code-type’ API under Master Data. |
+|  | **Step 2: Sender information** | | |
+|  | Sender Name\* | The name of sender | X(100) |
+|  | From email\* | The email addess used to send email to target customer | Display  This email is configured. |
+|  | Subject\* | Subject of email | X(100) |
+|  | Preview Text | Preheader of Email  Preheader can help user connect with customer and increase customer’s open rate.  If Prejeader is not provided then the first line of email content will be display instead | X(100) |
+| **3.** | **Step 3: Email content figuration** | | |
+|  | Message | Conditon field  The message content of the Email.  If “Use message” is selected then this field is actived.  System must allow to edit HTML format. The system should support to generate into text format.  System must allow to put image/url… as message content.  The list of message parameters are included to be used.  User can drop/drag message paramters into message.  Assumation that the list of message parameters are defined as attribute (the same approach as Rule criteria) to able to drop/drag into message. | Character |
+|  | Message parameters | The message parameter list.  [Image Removed] | Tree list |
+|  | Upload file | This filed is actived when “Use template” is selected.  [Image Removed]  Allow users to drag and drop an HTML template file, or they can choose a file from their computer to upload it into the system.  After uploading, the system displays message content based on the uploaded file and allows the user to review and make modifications. | Button |
+|  | Re-Upload | Use this button to re-upload the email template. | Button |
+|  | Preview the email | The message will be automation displayed in the preview part.  Sender / Subject and Preheader will be displayed here.  If Preheader is not provided then the first line of message will be display instead. | Display |
+|  | Send sample | This functions to support the user can test message enable previewing the message to make sure the message appear exactly the way it was meant to.   * + - 1. A textbox to user can enter an email address. This entry should adhere to the email format field.       2. When click on “Send sample” a confirm button to user confirm that the system will send a testing message into inputed email address. User can choose “OK” or “Cancel”. If user click on “OK” button the system will send a test email into inputed email address.       3. The email address should be required when user click on” Send sample”. If not found should reject with error message. | Button |
+| **Notification Push** | | | |
+|  | **Step 1: General information** | | |
+|  | Message ID \* | Unique identifier of the Message.  Not allow special characters | X(10) |
+|  | Message Description \* | Description of message | X(100) |
+|  | Notification Type | Drop-down to select Notification type:  Promotion/Marketing  Transaction | Check box  Allow to select only one value.  Lookup value “Code Management” table where type code is “email-use-type”.  Refer to ‘list-by-code-type’ API under Master Data. |
+|  | Effective Date From \* | The start date of the effective period of the message | Date  The date format must adhere to the configured format |
+|  | Effective End Date \* | The end date of the effective period of the message | Date  The date format must adhere to the configured format. |
+|  | **Step 2: Notification Content configuration** | | |
+|  | Message Title \* | The primary text that appears at the top of the notification | X(50) |
+|  | Message \* | The main content of the notification, providing additional information, context, or details related to the notification's purpose.  The list of message parameters are included to be used.  User can drop/drag message paramters into message.  System must allow to put image/url as message content. | Text Area |
+|  | Message parameters | The message parameter list.  [Image Removed] | Tree list |
+|  | Image type\* | Drop- down to selcte image type:  SingerEicheer push (No image )  Richer Push (one image)  Carousel Push (One or more than one image) | Drop- down  Select one only  Lookup value “Code Management” table where type code is “image-type”.  Refer to ‘list-by-code-type’ API under Master Data. |
+|  | Upload Image | Condition field   * + - 1. This field is not actived for Single Push       2. Image URL : Click on the Image URL field and type or paste the URL of the image       3. Upload: Drag/Drop image or click the uploaded from computer.   If the Image type is 'Carousel Push,' then users can upload more than one image. The sequence sorting will be the same as the sequence displayed in the mobile app. Users can rearrange the images to adjust the sortinng.  Image is required for “Richer push” and “Carousel Push”. |  |
+|  | Preview the notification | The message will be automation displayed in the preview part: content/ image.  Preview on IOS or Android | Display |
+|  | Link URL \* | Enter or paste the URL to which the user needs to navigate to. | X(100) |
+|  | Send sample | This functions to support user can test message enable previewing the message to make sure the message appear exactly the way it was meant to.   * + - 1. A textbox to user can enter a CIF Number. From CIF Number the system will locate device's registration token, a device group's notification key, or a single topic.       2. A confirm message to user confirm that the system will send a testing message into inputed email address. User can choose “OK” or “Cancel”. If user click on “OK” button the system will send a test notification.       3. The token or key or something else which one the system used determine destination of the push message should be required when user click on” Send sample”. If not found should reject with error message. | Button |
+
+### Post -codition
+
+* + 1. All message which will be sent to target customer are availble to config on following modules :
+
++ Marketing Request
+
++ Campaign Rule
+
++ Item master ….
+
+### Exception Flow
+
+* + 1. Input data are not passed all validations and then the user choose cancel the action then use case ends in failure.
+
+## Marketing Campaign
+
+### Requirement Definition
+
+* + - 1. Marketing Campagin Module is used to filter out a list of target customers that satisfy the marketing criterions.
+
+### Process Flow
+
+[Image Removed]
+
+### Trigger
+
+N/A
+
+### Pre- Conditon
+
+1. Users have to have access rights in “Marketing Request” module to able to access this screen.
+2. Depending on the user's access rights, they can view, add, edit, or approve manually marketing request.
+3. All OMR citerions must to be defined as an attribute for each criterion to user can drop/drag to determine target audience.
+4. To send marketing messange when an envent is triggered (real time events or batch events  
+   ) then :
+   1. Pre-Defined Event: Define the action to indentify when event triggers: such as login/ Get balance detail view/ leave feedback on portal app.
+   2. FE Events: APIs or services can be used to initiate the action and make a call to the backend (BE) to determine whether the event has been triggered; if so, the assigned message for this event should be sent.
+   3. Batch job: marketing message can be automatically sent by the system via batch jobs.
+
+### Wireframe
+
+* + - * 1. Marketing request summary listing page
+
+[Image Removed]
+
+1. Filter
+
+[Image Removed]
+
+1. Create/Edit mode
+   1. Step 1: General information
+
+[Image Removed]
+
+* 1. Step 2: Run schedule
+
+[Image Removed]
+
+[Image Removed]
+
+* 1. Step 3: Targeting
+
+[Image Removed]
+
+4. Detail view
+
+### Business Rules
+
+1. The same approach as Campaign Rule Criteria, each of marketing criterions are accessed directly by drag/drop on the right **Criteria** panel as illustrated in the [wireframe](#_Wireframe_12).
+2. OLS system will use Query Builder to build query for marketing criteria.
+3. 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.
+4. OLS system support AND or OR condition between difference criteria groups on the same request. 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.*
+
+1. Introduce NOT toggle switch to support exclusion criteria.
+2. Click on the “Marketing Request” in Main icon to bring up the screen for accessing the Marketing Request listing page. The detail as illustrated in the [wireframe](#_Wireframe_12).
+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 Marketing Request screen is illustrated in the [wireframe](#_Wireframe_12).
+4. **Screen description**
+
+|  |  |  |  |
+| --- | --- | --- | --- |
+| **Index** | **Field** | **Description** | **Data type** |
+| **Step 1: General Information** | | | |
+|  | Request ID \* | Unique identifier of the OneMarketing Request  Not allow special characters | X(20) |
+|  | Description \* | Description of the OneMarketing Request | X(100) |
+|  | Effective Date From\* | The start date of Effective period of the marketing request | Date  The date format must adhere to the configured format |
+|  | Effective Date To \* | The end date of Effective period of the marketing request | Date  The date format must adhere to the configured format |
+|  | Marketing Function \* | * Including 2 main functions of OneMarketing Request:   + Notification [N] - The message template set up at section [Marketing Message](#_Marketing_message) is sent to target customers   + Triger Campain Rule [TCR] - A campaign is applied to add/redeem/adjust points to target customers based on Transaction Code. | Check box  Allow to select only one value  Lookup value from “Code\_Management” table where type code is ‘OMR-function’.  Refer to ‘list-by-code-type’ API under Master Data Master. |
+| **Step 2: Run schedule and message content** | | | |
+|  | Trigger method \* | Two methods to select when message will be sent to target customer:  Schedule  Event trigger | Radio button  Lookup value from “Code\_Management” table where type code is ‘OMR-function’.  Refer to ‘list-by-code-type’ API under Master Data Master. |
+|  | Run Schedule \* | * This field is activated and required when “Schedule” method is selected only. * Schedule to run OneMarketing Request Batch, include:   *[O] – Once Time [D] - Daily*  *[W] - Weekly [M] - Monthly*  *[A] - Annually* | Radio button  Lookup value from “Code\_Management” table where type code is ‘run-schedule’.  Refer to ‘list-by-code-type’ API under Master Data Master. |
+|  | One time | [Image Removed]   * 1. This option includes following fields:      1. Fixed date\*: This field is only active and required when “One time” schedule is selected. This field is date format (Date time format must respect the date format configuration). This field is actived and required when “Schedule” method is selected only.      2. Time of day to excute request\*: The time to OMR batch job running to trigger this request. This field is time format field.   2. Request will occur only one time when process date is equal to the fixed date at the selected time. |  |
+|  | Daily | [Image Removed]   * + - 1. This option includes following fields:     1. Repeat every\*: The drop-down list to select the frequency on every n day where n from 1 to 100. This is select one field.     2. Time of day to excute request\*: The time to OMR batch job running to trigger this request. This field is time format field.        1. Request will occur on every n day at the selected time. |  |
+|  | Weekly | [Image Removed]   * + - 1. This option includes following fields:     1. Repeat every\*: The drop-down list to select the frequency on every n week where n from 1 to 52. This is select one field.     2. Day of the week: The drop -down list to select the day of week the request will be occurred. The list includes list of day of week (from Monday to Sunday). This is multiple select field.     3. Time of day to excute request\*: The time to OMR batch job running to trigger this request. This field is time format field.        1. Request will occur on every n weeks on selected day of the week and at the selected time |  |
+|  | Monthly | * 1. Option 1   [Image Removed]  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.     - Repeat on the: The drop-down list to select the repeat type. The list includes : Each /On the.”Each” is selected.     - 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. This field is activied and required only when “Each” is selected on “Repeat on the” filed. This is multiple select field.     - Last day of month: This field is activied and required only when “Each” is slected on “Repeat on the” filed. 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 OMR batch job running to trigger this request. This field is time format field.   Request will occur on every n month on each selected day of the month and at the selected time.   * 1. Option 2   [Image Removed]  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.     - Repeat on the: The drop-down list to select the repeat type. The list includes : Each /On the. “On the” is selected.     - In : The drop-dow to select the specific day of the week. The list includes : First/ Second/ Third/ Fouth/ Last. This filed is actived and required only when “On the” is selected. This is select one field.     - Day of the week: The drop-down list to select day of the week. The list includes: Monday … Sunday. This is multiple field.     - Time of day to excute request\*: The time to OMR batch job running to trigger this request. This field is time format field.   Request will occur on every n month on each selected period of day of the weeek and at the selected time. |  |
+|  | Annually | [Image Removed]  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 OMR batch job running to trigger this request. This field is time format field.   Request will occurred every n year on the selected day and selected month. | Drop-down  Select one |
+|  | Business Event | This filed is actived and requied when “Event trigger” method is selected.  A drop-down list is used to select the event. When the event occurs, a request is triggered to send a message to the target customer. | Drop-down  Multiple select. |
+|  | Message template\* | This filed is actived and required only when “Notification” marketing function is selected. | Drop-down  Lookup value from martketing message screen. |
+|  | OLS Transaction Code | This filed is actived and required only when “Trigger Campaign Rule” marketing function is selected. | Drop-down  Lookup value from OLS Transaction Code screen.  Refer “OLS Transaction Code” API under Campaign Management |
+| **Step 3: Targeting**  **This step is used to config the conditions to get target customer.** | | | |
+|  | Trigger method \* | There are two options to setup targeting.   * + - OMR Criteiria     - Upload file | Radio button  Lookup value from master data. |
+|  | **OMR Criteira is selected** | | |
+|  | [Image Removed] | Depended on the purpose of each OMR request 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.  Assumed that Each criteria per category will be defined as an attribute.  [Image Removed] | View only |
+|  | Drag/Drop criteria | Each criteria can be drag one more time on each request. The condition and filler value for each criteria will be display base on data type of criteria. See more detail on [Campaign Rule](#_Campaign_Rule_Criteria) Criteria.  [Image Removed] | Action |
+|  | **“Upload file” is selected**  [Image Removed] | | |
+|  | Browse File | Allow users to drag and drop an upload file, or the user can choose a file from their computer to upload it into the system.  Use the 'Upload file' option when users have a specific targeting list that they want to use for the campaign. | Button |
+
+* 1. “Save as draft” and “Save as template” feature are applied on this screen.
+  2. **OMR batch job will trigger marketing request as following processing:**
+
+OMR job (OMR) just trigger effectived marketing requests based on Effective period of each request compare with processing date (batch date/ sysdate). From effectived request list the batch job find the valid job which have run schedule on the day batch job is running.
+
+OMR creates notification messages to be sent to customers selected based on criteria configured by users in the step 3 -OMR criteria – e.g., to send an SMS message to customers whose birthday is due in the next N days.
+
+OMR can also be configured to trigger awarding batches generated by extracting transactions from Transaction log table.
+
+OMR can be configrured to trigger CP rule for the customer selected based on based on criteria configured by users in the step 3 -OMR criteria – e.g., to award 100 cash back to customers whose birthday in Tet holiday.
+
+OMR will stop send message when limit is reached. The limit based on frequency capping configurued by user in step 4- Frequency capping.
+
+|  |  |
+| --- | --- |
+| Batch id | OMR job ==tbd== |
+| Description | Processes OneMarketing Requests (OMR) on the configured schedule |
+| File Id | Nil |
+| Input file | Nil |
+| input staging table | ==TBD== |
+| Tables read | Its depending in OMR criteria list which should be defined as an attribute for each criteira.  == TBD==== |
+| Tables updated | =TBD=== |
+| Output staging table | Nil |
+| Output file | Nil |
+| Unwind job | ==TBD== |
+
+### Post – Condition
+
+* + - 1. Marketing content is sent to target customer or Target customer trigger CP rule.
+
+### Exception Flow
+
+* + 1. Input data are not passed all validations and then user choose cancel the action then use case ends in failure.
+
+## Marketing Frequency Cap
+
+### Requirement Defintion
+
+* + - 1. By controlling frequency capping, business can provide a more personalized customer expirence. Beside, frequency capping can provide a high level overview of the need for a notification capping system and the expected benefits for the business and its customers.
+      2. Business able to setup the daily, weekly, monthly capping per customer.
+      3. The system should automaticly enforcement of notification caps across different communication channels.
+
+### Process Flow
+
+### Trigger
+
+### Pre-Conditions
+
+1. Users have to have access rights in “Frequency Capping” module to able to access this screen.
+2. Depending on user’s access right to user can modify the frequency capping of the marketing campaign.
+
+### Wireframe
+
+* + - * 1. Listing page
+
+[Image Removed]
+
+* + - * 1. Edit mode
+
+[Image Removed]
+
+* + - * 1. View mode
+
+[Image Removed]
+
+### Business Rules
+
+1. This step is used to set up a limit to the number of times a message has been sent to per uniquie customer on specific period.
+2. This step is also used to setup a limit the number of message that a business allow to send to customer through specific message channel.
+3. Screen description
+
+|  |  |  |  |
+| --- | --- | --- | --- |
+| **Index** | **Field (EN/VN)** | **Description** | **Data type** |
+| **Listing page** | | | |
+|  | Notification Channel/Kênh thông báo | The name of the notification channel | Display |
+|  | Effective Date From /Hiệu lực từ ngày | The start date of the cap | Display as date format.  The display format should respect the configured format. |
+|  | Effective Date To/Hiệu lực tới ngày | The last effective date of the cap |
+|  | Frequency Cap/Giới hạn tần suất | The frequency cap on each channel.  Each period unit is displayed as a separate record with the cap | Display |
+|  | Include White List/Bao gồm danh sách trắng | Whitelist who are excluded from the cap or not | Display |
+| **Edit mode** | | | |
+|  | Frequency Cap Id\*/ Id giới hạn tần suất | The Record inditifier | X(10) |
+|  | Notification Channel\*/Kênh thông báo | Marketing Frequecny Capping identifier  A drop-down to select one channel to apply the capping rules.  A list incluse following channel:   * + - SMS     - Email     - Push Notifications | Drop-down  Select one |
+|  | Effective Date From \*/ Hiệu lực từ ngày | The start date of the effective period of the cap | Date  The system should only have one effective cap applied on each channel at any given time |
+|  | Effective Date To\*/Hiệu lực tới ngày | The end date of the effective period of the cap |
+|  | **Frequency Cap/ Giới hạn tần suất**  **Require at least one period unit** | | |
+|  | + Add Period Unit/ Thêm chu kì | Click to add new period unit to limit for chosen channel. | Button |
+|  | Capping Period \*/Chu kì | A drop-down to select the following period:   * + 1. Daily: Maximum number of notifications per day.     2. Weekly: Maximum number of notifications per week     3. Monthly: Maximun number of notifications per month. | Drop-down  Select one  Each period should only be configured with one cap value at the same time. |
+|  | Maximum number \*/Số lần gửi thông báo tối đa | The maximum the number of times a message has been sent to per uniquie customer. | 9(12) |
+|  | Include Whitelist/Không bao gồm danh sách trắng | This option disallows/allows the white customer list allow to receive a higher notification than normal customer for spefic scenario. | Swith button  Defaut OFF |
+|  | Customer list /Danh sách khách hàng | A drop-down to select the white customer list. This allows the system to recognize the white list customers and ignore the frequency capping rules.  This is a condition filed and only active and required if the capping rules include the white customer list. | Drop – down  Multiple select |
+|  | Description /Mô tả | The description of the capping. For refer only | X(100) |
+
+* 1. Frequency Capping are applied to all marketing campaigns in the system for customer level.
+  2. The system should automaticallytrack the number of notifications a customer has received across all notification channels as well as the period unit.
+  3. If the customer has reached the notification cap then the notification is not delivered to customer.
+  4. The white list who are excluded from the frequency cap rules should be tracked also.
+
+### Post –condition
+
+### Exception Flow
+
+## A/Bn Testing
+
+### Requirement Definition
+
+* + - 1. This function is used to evaluate and optimize various elements of the marketing program to improve customer engagement, retention, and overall performance.
+      2. OLS support both A/Bn content testing and A/Bn target customer testing.
+      3. For A/Bn content testing, one variation (content A) of the marketing request is sent to a subset of target customers, and one or more different variations (content sample B/ content sample n) are sent to the same subset of target customers. The goal is to identify which content in the marketing request yields the best results.
+      4. Unlike A/B content testing, A/Bn target customer testing focuses solely on the target customers. In the same testing request, one variation is designated for 'target customer A,' while one or more variations are designated for 'target customer B' or 'target customer n.' The goal is to identify which OMR criteria in the marketing request will reach more customers.
+
+### Process Flow
+
+[Image Removed]
+
+### Trigger
+
+N/A
+
+### Pre-Conditions
+
+* + - * 1. For A/Bn messsage content testing, result testing must be provied from third-party to OLS can collect data and analyze result to introduce report which user can use to make decision which on is better.
+        2. Users have to have access rights in “A/Bn Testing” module to able to access this screen.
+        3. Depending on the user's access rights, they can view, add, edit, or approve manually marketing request.
+        4. All OMR citerions must to be defined as an attribute for each criterion to user can drop/drag to determine target audience.
+
+### Wireframe
+
+Summary listing page
+
+[Image Removed]
+
+* 1. Filter
+
+[Image Removed]
+
+* 1. Content marketing testing configuration
+
+**Step1: Choose testing type is “Content message testing”**
+
+[Image Removed]
+
+Step 2: Setup general information
+
+[Image Removed]
+
+Step 3: Choose target customer
+
+[Image Removed]
+
+Step 4: Setup variant content message
+
+[Image Removed]
+
+Step 5: Set up run schedule
+
+[Image Removed]
+
+* 1. Target customer testing configuration
+
+Step 1: Choose “Target customer testing”
+
+[Image Removed]
+
+Step 2: Set up general information
+
+[Image Removed]
+
+Step 3: Setup variant target customer
+
+[Image Removed]
+
+Step 4: Setup run schedule
+
+[Image Removed]
+
+### Business Rules
+
+1. The same approach as Campaign Rule Criteria, each of marketing criterions are accessed directly by drag/drop on the right **Criteria** panel as illustrated in the wireframe.
+2. OLS system will use Query Builder to build query for OMR criteria when user setup target customer.
+3. 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.
+4. Click on the “A/Bn Testing” in Main icon to bring up the screen for accessing the A/Bn Testing listing page. The detail as illustrated in the [wireframe](#_Wireframe_16).
+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 A/B testing screen is illustrated in the [wireframe](#_Wireframe_16)s.
+6. **Screen description:**
+
+**Create/Edit mode**
+
+|  |  |  |  |  |
+| --- | --- | --- | --- | --- |
+| **Index** | **Field** | | **Descriptions** | **Data type** |
+| * + - * 1. **A/B message content testing** | | | | |
+| **Step 1: Campaign information** | | | | |
+|  | | Campaign ID \* | Marketing Campaign ID  Unique and Not allow specical characters | X(20) |
+|  | | Campaign Description | Description of Marketing Campaign ID | X(100) |
+|  | | Effective Date From | The start date of the effective period of the A/Bn testing request | Date  The date format must adhere to the configured format |
+|  | | Effective End date\* | The end date of the effective period of the A/Bn testing request | Date  The date format must adhere to the configured format |
+|  | | Message channel \* | SMS  Email  Push | Checkbox  Allow to select only one value  Lookup from master data. |
+| **Step 2: Choose target customer**  The OMR criteria list must be the same as the OMR criteria list on “[Marketing request”](#_Marketing_Request). | | | | |
+|  | [Image Removed] | | Depended on the purpose of each OMR request 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.  Assumed that Each criteria per category will be defined as an attribute.  [Image Removed] | View only |
+|  | Drag/Drop criteria | | Each criteria can be drag one more time on each request . The condition and filler value for each criteria will be display base on data type of criteria. See more detail on [Campaign Rule](#_Campaign_Rule_Criteria) Criteria.  [Image Removed] | Action |
+| **Step 3: Set up varial content**  [Image Removed] | | | | |
+|  | Variant A  Users can rename and should be unique value on one each campaign | | Depending in Message channel : SMS/ Email/ Push notification, this tab is display as step 2 of Marketing message screen according to each message channel. See more on [Marketing message](#_Business_Rules).  Content varial A will be added here. | Tab |
+|  | Varial B  Users can rename and should be unique value on one each campaign | | Depending in Message channel : SMS/ Email/ Push notification, this tab is display as step 2 of Marketing message screen according to each message channel. See more on [Marketing message](#_Business_Rules).  Content varial B will be added here. |  |
+|  | Add | | Click to add to introduce new tab to create new content varial.  System will automation populate varinant name as default and users can rename and should be unique value on one each campaign. | Button |
+| **Step 4: Running schedule** | | | | |
+|  | Run Schedule \* | | * This field is activated and required when “Schedule” method is selected only. * Schedule to run OneMarketing Request Batch, include:   *[O] – Once Time [D] - Daily*  *[W] - Weekly [M] - Monthly*  *[A] - Annually* | Drop-down  Select one  Lookup value from master data |
+|  | One time | | [Image Removed]   * 1. This option includes following fields:      1. Fixed date\* : This field is activated and required when “One time” schedule is selected. This field is Date format . This field is actived and required when “Schedule” method is selected only.      2. Time of day to excute request\* : The time to OMR batch job running to trigger this request. This field is time format field.   Campaign will run only one time when process date is equal to the fixed date at the selected time. |  |
+|  | Daily | | [Image Removed]   * + - 1. This option includes following fields:     1. Repeat every\* : The drop-down list to select the frequency on every n day where n from 1 to 100. This is select one field.     2. Time of day to excute request\* : The time to OMR batch job running to trigger this request. This field is time format field.   Campign will run and repeat on every n day at the selected time. |  |
+|  | Weekly | | [Image Removed]   * + - 1. This option includes following fields:     1. Repeat every\* : The drop-down list to select the frequency on every n week where n from 1 to 52. This is select one field.     2. Day of the week: The drop -down list to select the day of week the request will be occurred. The list includes list of day of week (from Monday to Sunday). This is multiple select field.     3. Time of day to excute request\* : The time to OMR batch job running to trigger this request. This field is time format field.   Campign will run and repeat on every n weeks on selected day of the week and at the selected time |  |
+|  | Monthly | | * 1. Option 1   [Image Removed]  This option includes following fields:   * + 1. 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.     2. Repeat on the: The drop-down list to select the repeat type. The list includes : Each /On the.”Each” is selected.     3. 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. This field is activied and required only when “Each” is slected on “Repeat on the” filed. This is multiple select field.     4. Last day of month: This field is activied and required only when “Each” is slected on “Repeat on the” filed. 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.     5. Time of day to excute request\* : The time to OMR batch job running to trigger this request. This field is time format field.   Campaign will trigger and repeat on every n month on each selected day of the month and at the selected time.   * 1. Option 2   [Image Removed]  This option includes following fields:   * + 1. 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.     2. Repeat on the: The drop-down list to select the repeat type. The list includes : Each /On the. “On the” is selected.     3. In : The drop-dow to select the specific day of the week. The list includes : First/ Second/ Third/ Fouth/ Last. This filed is actived and required only when “On the” is selected. This is select one field.     4. Day of the week: The drop-down list to select day of the week. The list includes: Monday … Sunday. This is multiple field.     5. Time of day to excute request\* : The time to OMR batch job running to trigger this request. This field is time format field.   Campaign will trigger and repeat on every n month on each selected period of day of the weeek and at the selected time. |  |
+|  | Annually | | [Image Removed]  This option includes following fields:   * + 1. 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.     2. Month of year: Drop-down to select month of year. The list includes 12 months of year from 1 to 12.     3. 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.     4. Time of day to excute request\* : The time to OMR batch job running to trigger this request. This field is time format field.   Campaign will trigger and repeat every n year on the selected day and selected month. | Drop-down  Select one |
+| **II: A/B target customer testing** | | | | |
+| **Step 1: General information** | | | | |
+|  | Campaign ID \* | | Marketing Campaign ID  Unique and Not allow specical characters | X(20) |
+|  | Campaign Description | | Description of Marketing Campaign ID | X(100) |
+|  | Effective Date From | | The start date of the effective period of the A/Bn testing request | Date  The date format must adhere to the configured format |
+|  | Effective End date\* | | The end date of the effective period of the A/Bn testing request | Date  The date format must adhere to the configured format |
+| **Step 2: Set up variant target customer** | | | | |
+|  | Variant A  User can rename and should be unique value on one each campaign | | This tab display the all OMR criteria to user can drag/drop to config the criterios to get the target customer.  The OMR criteria list must be the same as the OMR criteria list on “[Marketing request”](#_Marketing_Request).  Target customer varial A will be added here.  The system will use all OMR criteria configuration on this tab to conduct and get target customer A. | Tab |
+|  | Varial B  User can rename and should be unique value on one each campaign | | This tab display the all OMR criteria to user can drag/drop to config the criterios to get the target customer.  The OMR criteria list must be the same as the OMR criteria list on “[Marketing request”](#_Marketing_Request).  Target customer varial B will be added here.  The system will use all OMR criteria configuration on this tab to conduct and get target customer A. | Tab |
+|  | Add | | Click to add to introduce new tab to create new target customer varial.  The OMR criteria list must be the same as the OMR criteria list on “[Marketing request”](#_Marketing_Request).  System will automation populate variant name as default and User can rename and should be unique value on one each campaign. | Button |
+| **Step 3: Running schedule** | | | | |
+|  | Run Schedule \* | | * This field is activated and required when “Schedule” method is selected only. * Schedule to run OneMarketing Request Batch, include:   *[O] – Once Time [D] - Daily*  *[W] - Weekly [M] - Monthly*  *[A] - Annually* | Drop-down  Select one  Lookup value from master data |
+|  | One time | | [Image Removed]   * 1. This option includes following fields:      1. Fixed date\* : This field is activated and required when “One time” schedule is selected. This field is Date format. This field is actived and required when “Schedule” method is selected only.      2. Time of day to excute request\* : The time to OMR batch job running to trigger this request. This field is time format field. * Campaign will run only one time when process date is equal to the fixed date at the selected time. |  |
+|  | Daily | | [Image Removed]   * + - 1. This option includes following fields:     1. Repeat every\* : The drop-down list to select the frequency on every n day where n from 1 to 100. This is select one field.     2. Time of day to excute request\* : The time to OMR batch job running to trigger this request. This field is time format field.   Campign will run and repeat on every n day at the selected time. |  |
+|  | Weekly | | [Image Removed]   * + - 1. This option includes following fields:     1. Repeat every\* : The drop-down list to select the frequency on every n week where n from 1 to 52. This is select one field.     2. Day of the week: The drop -down list to select the day of week the request will be occurred. The list includes list of day of week (from Monday to Sunday). This is multiple select field.     3. Time of day to excute request\* : The time to OMR batch job running to trigger this request. This field is time format field.   Campign will run and repeat on every n weeks on selected day of the week and at the selected time |  |
+|  | Monthly | | * 1. Option 1   [Image Removed]  This option includes following fields:   * + 1. 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.     2. Repeat on the: The drop-down list to select the repeat type. The list includes : Each /On the.”Each” is selected.     3. 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. This field is activied and required only when “Each” is slected on “Repeat on the” filed. This is multiple select field.     4. Last day of month: This field is activied and required only when “Each” is slected on “Repeat on the” filed. 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.     5. Time of day to excute request\* : The time to OMR batch job running to trigger this request. This field is time format field.   Campaign will trigger and repeat on every n month on each selected day of the month and at the selected time.   * 1. Option 2   [Image Removed]  This option includes following fields:   * + 1. 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.     2. Repeat on the: The drop-down list to select the repeat type. The list includes : Each /On the. “On the” is selected.     3. In : The drop-dow to select the specific day of the week. The list includes : First/ Second/ Third/ Fouth/ Last. This filed is actived and required only when “On the” is selected. This is select one field.     4. Day of the week: The drop-down list to select day of the week. The list includes: Monday … Sunday. This is multiple field.     5. Time of day to excute request\* : The time to OMR batch job running to trigger this request. This field is time format field.   Campaign will trigger and repeat on every n month on each selected period of day of the weeek and at the selected time. |  |
+|  | Annually | | [Image Removed]  This option includes following fields:   * + 1. 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.     2. Month of year: Drop-down to select month of year. The list includes 12 months of year from 1 to 12.     3. 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.     4. Time of day to excute request\* : The time to OMR batch job running to trigger this request. This field is time format field.   Campaign will trigger and repeat every n year on the selected day and selected month. | Drop-down  Select one |
+
+**Content marketing testing view mode**
+
+|  |  |  |  |
+| --- | --- | --- | --- |
+| **Index** | **Field** | **Description** | **Data type** |
+|  | Campaign ID | Campaign ID | X(20) |
+|  | Campaign Description | Description of Marketing Campaign ID | X(100) |
+|  | Message chanel\* | Push or Email or SMS | Display |
+|  | Effective Date From | The start date of the effective period of the A/Bn testing request | Date  The date format must adhere to the configured format |
+|  | Effective End date\* | The end date of the effective period of the A/Bn testing request | Date  The date format must adhere to the configured format |
+|  | OMR criteria | View as Rule criteria view mode for this part | Display |
+|  | Variant A | View as Message Template view mode for message content part | Tab |
+|  | Variant B | View as Message Template view mode for message content part | Tab |
+|  | Variant N | View as Message Template view mode for message content part | Tab |
+|  | Result | =TBD== It is depened on the third-party partner and the goal. We can want to see the total result on each content variation or detail result for each target customer on each content variation. | ==tbd== |
+
+**Targeting marketing testing view mode**
+
+|  |  |  |  |
+| --- | --- | --- | --- |
+| **Index** | **Field** | **Description** | **Data type** |
+|  | Campaign ID | Campaign ID | X(20) |
+|  | Campaign Description | Description of Marketing Campaign ID | X(100) |
+|  | Message chanel\* | Push or Email or SMS | Display |
+|  | Effective Date From | The start date of the effective period of the A/Bn testing request | Date  The date format must adhere to the configured format |
+|  | Effective End date\* | The end date of the effective period of the A/Bn testing request | Date  The date format must adhere to the configured format |
+|  | Variant A | View as Marketing request view mode for OMR criteria part. | Tab |
+|  | Variant B | View as Marketing request view mode for OMR criteria part. | Tab |
+|  | Variant N | View as Marketing request view mode for OMR criteria part. | Tab |
+|  | Result | One gird to view the customer list on each variation   |  |  |  |  |  | | --- | --- | --- | --- | --- | | **Variation** | **Total number of customers** | **Total Female customer** | **Total male customer** | **….** | | Variation A | 100 | 10 | 90 |  | | Variation B | 150 | 100 | 50 |  | | Variation n | 140 | 50 | 90 |  | | ==tbd==  **Which criteria should be summarized??** |
+
+* 1. **A/Bn batch job will trigger marketing request as following processing:** 
+     1. A/Bn testing job (ABn) just trigger effectived A/Bn testing requests based on effectived period of each request compare with processing date (batch date/ sysdate). From effectived request list the batch job find the valid job which have run schedule on the day batch job is running.
+     2. For content testing, ABn creates A/Bn message content selected based on the variation content configured by user. These message to be sent to the same customers selected based on criteria configured by users. E.g to send 3 promotion messages to customers whose birthday is due in the next N days. The result testing should be provied by parter so that OLS can provide the report to user can decide which content messge is better.
+     3. Regarding to target customer testing, A/Bn locates the target customer based on criteria configured by users. User can verify the result testing after batch job is completed.
+     4. For A/Bn SMS content testing, we can track click-through rates if SMS includes links or calls to action. By including unique links for different messages or recipients, we can measure how many people clicked on those links to interact with each content. From this result we can have the temporary open rate to user can decide which one is better.
+     5. For A/Bn Email content testing, open rate = (Number of opens / Number of delivered emails)/100. Number of opens is provided by third-party or we have to send email is in HTML format, as tracking pixels work with HTML emails. The number of opens willl be is the number of times the tracking pixel was downloaded when recipients opened the email.
+     6. ==tbd==
+
+### Post-Conditions
+
+### Exception Flow
+
+## BlackList
+
+### Requirement Definition
+
+* + - 1. The business need to exclude specific customer or groups from marketing campaigns for strategic reasons, such as fraud customers.
+      2. Ensuring marketing efforts are focused on the most relevant and engaged audience to improve efficiency and return on investment.
+      3. A set of customer who will be blocked for reward/promotion notification from a business wil be pre-definiton in this module.
+
+### Process Flow
+
+### Trigger
+
+* + - * 1. The customer who has fraud behaviors will need to be added into black list.
+
+### Pre-Conditions
+
+* + - * 1. Users have to have access rights in “Black List” module to able to access this screen.
+        2. Depending on the user's access rights, they can view, add, edit, or approve manually marketing request.
+
+### Wireframe
+
+Listing page
+
+[Image Removed]
+
+Edit mode
+
+Step 1: Generral Information
+
+[Image Removed]
+
+Step 2: Customer List
+
+[Image Removed]
+
+[Image Removed]
+
+[Image Removed]
+
+Detail Mode
+
+[Image Removed]
+
+### Business Rules
+
+Users are able to upload a list of customers who will be blocked from the marketing campaign by uploading a file into the system.
+
+Additionally, users are able to assign customers to the blacklist by selecting a list of cif number belong to OLS system.
+
+Users are able to review the customer list or download the customer list that they have already uploaded to the system.
+
+Screen description
+
+|  |  |  |  |
+| --- | --- | --- | --- |
+| **Index** | **Field (EN/VN)** | **Description** | **Data type** |
+| **Listing page** | | | |
+|  | ID / ID | Blacklist indentifier | Display |
+|  | Name List/ Tên danh sách | The name of the black list. | Display |
+|  | Description/Mô tả | More description for this blacklist. | Display |
+|  | Customer List/Danh sách khách hàng | A list of customer that inputted by user or uploaded by user.  Use ellipsis (…) to indicate that the customer list is too long to display in full.  Mouseover to see full list. | Display |
+|  | [Image Removed] | By clicking here to download the customer list.  This should be orginal file if this file is uploaded by the user.  A file containing a list of customers entered by the user will be generated by the system. This file should under the CSV format as upload sample file. | Button |
+| **Edit mode** | | | |
+|  | **General Information** | | |
+|  | ID \*/ ID | Blacklist indentifier  For refer only | X(10) |
+|  | Name List\*/ Tên danh sách | The name of the black list.  For refere only | X(50) |
+|  | Description/Mô tả | More description for this blacklist.  For refer only | X(200) |
+|  | **Customer List** | | |
+|  | Input Type\*/ Kiểu nhập dữ liệu | Users can choose one of following option :   * + - Input from screen     - Upload file | Radio |
+|  | Customer List/ Danh sách khách hàng | A drop-down to select the customer who will be blocked from the marketing campaign if “input from screen” is selected in previous step. | Drop-down  Multiple select  To avoid performance issue, user should enter at least 4 digit of CIF number to select the customer |
+|  | Upload file/Tải file | This option allow users upload file from their divice.  The file shoud follow system’s format.  Just allow CSV, xls, xlsx extension and file size should less than or equal to 50 MB.  User can drag/drop or choose browse fiel from their device. | Button |
+|  | Customer List | If file upload successful then the customer list will be display here | Display |
+
+Users review and approve the record in the same manner as on other screens
+
+### Post-Conditions
+
+The blacklist is stored and accessible to another module.
+
+### Exception Flow
+
+If the file type or size is not valid, the system displays an error message and prompts the customer to select a different file.
+
+The system should clearly display the upload processing status to the user.
+
+## Whitelist
+
+### Requirement Definition
+
+* + - 1. The business need to exclude a list of customers that are excluded from the standard frequency cap rules.
+      2. The whitelist ensures your top customers continue receiving your marketing messages without limit. We can use the whitelist for testing and optimizing campaign purposes. We can aslo use the whitelist for user who have shown strong interest in your marketing campaigns.
+
+### Process Flow
+
+### Trigger
+
+* + - * 1. A set of customers needs to be added to the whitelist to exlcuse them from the frequency cap rules.
+
+### Pre-Conditions
+
+* + - * 1. Users have to have access rights in “Whitelist” module to able to access this screen.
+        2. Depending on the user's access rights, they can view, add, edit, or approve manually marketing request.
+
+### Wireframe
+
+Listing page
+
+[Image Removed]
+
+Edit mode
+
+Step 1: Generral Information
+
+[Image Removed]
+
+Step 2: Customer List
+
+[Image Removed]
+
+[Image Removed]
+
+[Image Removed]
+
+Detail Mode
+
+[Image Removed]
+
+### Business Rules
+
+Users are able to upload a list of customers who will be excluded from the frequency cap rules by uploading a file into the system.
+
+Additionally, users are able to assign customers to the whitelist by selecting a list of cif number belong to OLS system.
+
+Users are able to review the customer list or download the customer list that they have already uploaded to the system.
+
+Screen description
+
+|  |  |  |  |
+| --- | --- | --- | --- |
+| **Index** | **Field (EN/VN)** | **Description** | **Data type** |
+| **Listing page** | | | |
+|  | ID / ID | Blacklist indentifier | Display |
+|  | Name List/ Tên danh sách | The name of the black list. | Display |
+|  | Description/Mô tả | More description for this whitelist. | Display |
+|  | Customer List/Danh sách khách hàng | A list of customer that inputted by user or uploaded by user.  Use ellipsis (…) to indicate that the customer list is too long to display in full.  Mouseover to see full list. | Display |
+|  | [Image Removed] | By clicking here to download the customer list.  This should be orginal file if this file is uploaded by the user.  A file containing a list of customers entered by the user will be generated by the system. This file should under the CSV format as upload sample file. | Button |
+| **Edit mode** | | | |
+|  | **General Information** | | |
+|  | ID \*/ ID | Blacklist indentifier  For refer only | X(10) |
+|  | Name List\*/ Tên danh sách | The name of the whitelist.  For refere only | X(50) |
+|  | Description/Mô tả | More description for this blacklist.  For refer only | X(200) |
+|  | **Customer List** | | |
+|  | Input Type\*/ Kiểu nhập dữ liệu | Users can choose one of following option :   * + - Input from screen     - Upload file | Radio |
+|  | Customer List/ Danh sách khách hàng | A drop-down to select the customer who will be excluded from the frequency cap rules if “input from screen” is selected in previous step. | Drop-down  Multiple select  To avoid performance issue, user should enter at least 4 digit of CIF number to select the customer |
+|  | Upload file/Tải file | This option allow users upload file from their divice.  The file shoud follow system’s format.  Just allow CSV, xls, xlsx extension and file size should less than or equal to 50 MB.  User can drag/drop or choose browse fiel from their device. | Button |
+|  | Customer List | If file upload successful then the customer list will be display here | Display |
+
+Users review and approve the record in the same manner as on other screens
+
+### Post-Conditions
+
+The whitelist is stored and accessible to another module.
+
+The whitelist is excludes from the frequency cap rules as default. If there is any cap rules should need to include the whitelist then the user should indicate those whitelist.
+
+### Exception Flow
+
+If the file type or size is not valid, the system displays an error message and prompts the customer to select a different file.
+
+The system should clearly display the upload processing status to the user.
+

docs/specs/archive/onetargeting.md

@@ -0,0 +1,146 @@
+---
+title: "OneTargeting"
+type: OpenSpec
+status: Draft
+---
+# OneTargeting
+
+## Segmentation Definiiton
+
+### Requirement Definition
+
+* 1. Segmentation is one proessing to divide a customer base into smaller, that provides a way to narrow down the target audience based on the types of products or services the customers have previously purchased.
+  2. This screen allows businesses to create more personalized and effective marketing strategies for each segment, rather than adopting a one-size-fits-all approach.
+  3. In the system sides, segement 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 the targeting customer.
+
+### Process Flow
+
+### Trigger
+
+* + 1. User access to the OneTargeting Module to create/update new segment.
+
+### Pre-Conditions
+
+1. Users have to have access rights in “Segmentation” module to able to access this screen.
+2. Depending on the user's access rights, they can view, add, edit, or manually approval.
+3. Assume that all criteria are defined as attribute and appear in right panel in message content part to user can drag/drop to setup.
+
+### Wireframe
+
+* + - 1. Create /Edit mode
+
+[Image Removed]
+
+[Image Removed]
+
+* + - 1. View mode
+
+### Business Rules
+
+1. The same approach as Campaing Rule Crireria screen, OLS system will use Query Builder to build query for this screen.
+2. Refer to [Rule Criteria](#_Business_rules_1) section to get more detail about the business rule of this screen. The criterion list are described in the #3.
+3. Here are some way that business segment their targeting customer :
+
+| **Index** | **Segement Group** | **Criteria Group** | **Combination by following Criteia** | **Segment Example** |
+| --- | --- | --- | --- | --- |
+|  | Demographic Segmentation | Customer Profile | Age | Life Cycle segment:  Children: 0 -14  Youth: 15- 24  Adults: 24- 64  Seniors: 65 and above |
+| Last Name |  |
+| First Name |  |
+| Income | **Income segment**:  High-Income Customer  Middle –Icome Customer  Low-Income Customer |
+| Gender | Male customer  Female customer |
+| Marital Status | Singel customer  Married customer |
+| DOB | **Generation segment:**  Gen Z: Year DOB from 1997 – 2012  Gen Y: 1981 – 1996  Gen X: 1965 – 1980  Gen W (Baby Boomers): 1946- 1964 |
+| Location: Country/State/City/Zip Code | **Geography segement:**  International customer  Urban customer  Suburban customer  Mountain Customer |
+| Customer’s Tenure | **Customer’s Tunure**  **Segment** (Use Customer Registration) :  New customer: under 1 year  Early- tenured customer: 1- 2 years  Mid-Tenured customer: 2- 5 years  Long - tenured customer: above 5 years |
+| Account ‘s Tenure | **Account’s Tunure**  **Segment** (use AOD) :  New customer: under 1 year  Early - tenured customer: 1- 2 years  Mid-Tenured customer: 2- 5 years  Long tenured customer: above 5 years |
+| Account’s Status |  |
+| Next AOD |  |
+| Customer’s staus | Used in the many segment that |
+|  | Behavior Segmentation | Transaction | Last transaction /Integration | **Churned customer :**  E.g Last transaction is more than 6 months ago and customer status is active |
+| Transaction Frequency:  Should be tracked in the specific period such as day/week/month / Quarter/Year/Custom period to determine for following criteria :   * + 1. **Total number txn frequency on the specific period.**     2. **Avegare txn frequency** | **Customer Segment:**  High-Value Customers: frequency range depend on each business rule  Medium-Value Customers: frequency range depend on each business rule  Low-Value Customers: frequency range depend on each business rule |
+| Customer Recency: When was the last transaction/ integration. |
+| Total spending value: How much customer spends (total nett transaction amount) |
+| Transaction Date | **Peak –Time customer:**  E.g Transaction date is on special day  Transaction date on weekend (day of the week)  Midnight transaction (Time of the transaction)  **Consistent-Time Customers**:  E.g Transaciton do on each the first day of the month  **Flexible-Time Customers**  E.g Transaciton is on specific day |
+| Transaction Time |
+| Merchant: Coporation/Chain/Store/MCC | Use with another crieteria or itself only to create specific segment |
+| Merchant Group: Coporation/Chain/Store/MCC Group |
+| Transaction Description |
+| Transaction Category |
+| Transaction Gross Amount |
+| Transaction Nett Amount |
+|  | Flexible segment | Attribute | Attribute Criteria |  |
+|  | Psychographic Segmentation | Item | Favorite Category | **Life Style segment**  **Interest segment**  **Opinion segment** |
+| Favorite Item |
+| To be added when implement onedisplay so that we can have the data source for collect the Psychographic Segmentation from survey to decision the marketing strategy |
+
+### Post-Conditions
+
+* + - * 1. Each segment are used to define the targeting customer on the marketing module.
+
+### Exception Flow
+
+## Audience Upload
+
+### Requirement Definition
+
+Provide a user –friendly interface to marketers to manage audience uploads.
+
+### Process Flow
+
+### Trigger
+
+### Pre-Conditions
+
+1. Users have to have access rights in “Audience Upload” module to able to access this screen.
+2. Depending on the user's access rights, they can view, add, edit, or manually approval.
+
+### Wireframe
+
+### Business Rules
+
+Users are able to upload a customer data for targeted marketing campaigns by uploading a file into the system.
+
+The system should allow users map data from their source files to the required platform fields by accepting the CSV, excel spreadsheets.
+
+The system validates the uploaded data to ensure all required fields are present and in the correct format
+
+Screen descrition
+
+|  |  |  |  |
+| --- | --- | --- | --- |
+| **Index** | **Field (EN/VN)** | **Description** | **Data Type** |
+| **Listing page** | | | |
+|  | Audience Name /Tệp khán giả | Name of the audience | Dipslay |
+|  | Description /Mô tả | Audience description  For use refer only | Display |
+|  | File size /Dung lượng tệp | The file size | Display as number format |
+|  | [Image Removed] | By clicking here to download the audience.  This should be orginal file tha user already uploaded. | Button |
+| **Create/Edit Mode** | | | |
+|  | File ID \*/ ID tệp | Audience identifier  For system refer only | X(10) |
+|  | Audience Name \*/ Tệp khán giả | The name of the audience  Should be uniquie value in the system. | X(50) |
+|  | Description /Mô tả | Audience description | X(200) |
+|  | Upload file \*/ Đăng tệp tin lên | This option allow users upload file from their divice.  The file shoud follow system’s format.  Just allow CSV, xls, xlsx extension and file size should less than or equal to 50 MB.  User can drag/drop or choose browse file from their device. | Button |
+|  |  |  |  |
+
+### Post-Conditions
+
+### Exception Condition
+
+## Customer Audience
+
+### Requirement Definition
+
+### Process Flow
+
+### Trigger
+
+### Pre-Conditions
+
+### Wireframe
+
+### Business Rules
+
+### Post-Conditions
+
+### Exception Flow
+
+End of Document

docs/specs/archive/reference.md

@@ -0,0 +1,55 @@
+---
+title: "Reference"
+type: OpenSpec
+status: Draft
+---
+# Reference
+
+| Ref# | Description / File Name |
+| --- | --- |
+| R01 |  |
+| R02 |  |
+| R03 |  |
+| R04 |  |
+|  |  |
+
+Change History
+
+| **Version** | **Change Description** | **Date** | **Updated by** |
+| --- | --- | --- | --- |
+|  | The first version including:  Customer Management  Campaign Management  Draft OMR module | 14/12/2023 | Trangdth  Maivt |
+|  | 1. Customer 360: Add more detail for Account/Card information 2 Section 5.1 Add filter, Add/update some fields in the screen Section 5.5 Card: Update description and logical Section 5.9 and 5.10: Update label | 18/12/2023 | Trangdth |
+|  | 1. Update the Pool Conversion Rate module 2. Update data type DD/MM/YYYY into "Date" to respect the date time configuration format 3. Update the Card logically: Add more detail when updating the card 4. **Update customer Management module section 5: an update based on Sang's requirement (Customer/Account/dashboard/transaction history/attribute/counter)** Update Vietnamese fields and some cosmetic issues | 20/12/2023 | Trangdth |
+|  | 1. Update customer block data type from X(20) into X(10) 2. Section 5.4 update the card activation date from mandatory to optional 3. Section 5.2.6: Update the logic of most items 4. Section 4.7- Pool Conversion Rate: update field name and logic for pool conversion rate 5. Section 4.12 Campaign Rule Criteria: Correction some typos and add more detail for txncat criteria 6. Pool Definition: remove the item code field (move to Rule setup). Add some validations(red line)  7. Add CEP rule type | 27/12/2023 | Trangdth |
+|  | 1. Add REP Rule 2. Update Pool Definition Screen: screen and logical 3. Update Counter Defintion to match with PMS and add more detail. | 02/01/2024 | Trangdth |
+|  | 1. Update API information for REP rule 2. Update API information for CEP Rule 3. Add document for Formula (UI+ Logical) | 10/01/2024 | Trangdth |
+|  | 1. Add Section 5.15 Awward Transaction Entry Screen 2. Update Section 4.8 Counter Definition: Add Late txn posting option. Update logical on post-condition 3. Update Pool Defintion: add more detail for ATG field 4. CEP/REP: Update API for run schedule | 16/01/2024 | Trangdth |
+|  | 1. Counter definition: Update: Active "First start date is fixed" for "Days from COD" period unit 2. Pool conversion rate: Update code from X(03) into X(05) 3. Card - Update data type and logic for Old Card number - Update the relationship of Account type and Account number  4. Add Campaign : Add description for CP module | 24/01/2024 | Trangdth |
+|  | 1. Add section 4.12 Campaign Rule logical for Award/redem/Adjust rule type 2. Add section 4.9 Transaction Category module | 25/01/2024 | Trangdth |
+|  | 1. Campaign: change data type and add alidation for Campaign type 2. CEP: Update data type for Run schedule and change the sequence order in Layout 3. REP: Update data type for Run schedule and change the sequence order in Layout | 30/01/2024 | Trangdth |
+|  | Section 4.17 : CEP : Update API information of following fields: - Account with blocked Card - Post Transactions under PA Account selected based on | 19/02/2024 | Trangdth |
+|  | Section 4.12.6 : Campaign Rule/Business Rule : Update validation of "Apply after Cap value " field | 21/02/2024 | Trangdth |
+|  | 1. Correction typo 2. Section 4.13: Rule criteria: Update more detail and req 3. Section 5.11 Adjustment : Add field and update logical of quick view | 05/03/2024 | Trangdth |
+|  | 1. Correction typo 2. Section 5.11 Adjustment: Update Vietnamese label and correction logical 3. Section 5.12 Transfer Balance: Add fields, Update logical, Add User Stories and Accepted Criterions 4. Section 5.13 Re-instatement : Add fields, Update logical , Add User Stories and Accepted Criterions | 07/03/2024 | Trangdth |
+|  | 1. 5.2.6.3: Account/Card information: Update logical and data entities 2. 5.11 Adjust: Add US and AC 3. 5.12 Award Transaction: Add fields, Update logical , Add User Stories and Accepted Criterions 4 5.5 Pool Balance Detail: Correction and Add User Stories and Accepted Criterions | 11/03/2024 | Trangdth |
+|  | 1. Section 4.15 contributor setting: Update data type of "Contributor Percentage" field 2. Section 4.14 Campaign Rule formula: Remove validation of F5/Multiplier | 12/03/2024 | Trangdth |
+|  | 1. Section 7: Added OneCatelogue module, including: Item master/ Catalogue/Category/Voucher management 2. Section 4.12 Campaign Rule: Added Post-condition for Amount to Use feature (Transaction Processing with Amount to use). 3. Secttion 4.6 Pool Definition: Remove CP Rule name and change data for "List Of Campaign" listing page. | 20/03/2024 | Trangdth |
+|  | 1. Add section 7.5: Item Price 2. Update section 5.14 Item redemption to match onecatalogue logical 3. Update quick view of Adjust/transfer balance/Re-instatement/Award. Take note that I just remove redundant information and update the description to be more clearly. The logical is not changed. | 25/03/2024 | Trangdth |
+|  | 1. Added section 2 (2.1/ 2.2/2.3/2.4) OneAccess module, including Overview, User Group, Permission Management and User Profile 2. 4.6 Pool Definition: Correction typo 3. 4.13 Rule Criteria: Correct index of operator on each data type 4. 4.14 Campaign Formula : Update Formula logical on TP sides | 03/04/2024 | Trangdth |
+|  | 1. Correction typo 2. Section 4.13 Rule Criteria: Update logical of String data type (TP sides only) (change in red text) | 12/04/2024 | Trangdth |
+|  | 1. Section 5.6 Transaction History: Update sketch, Update US and AC, update Business rule 2. Section 5.11 Adjustment: Update sketch. Update US and AC, update business rule 3. Section 5.15 Award : Update US and AC | 15/04/2024 | Trangdth |
+|  | 1. Section 4.18 Added Item Redemption Rule Type | 16/04/2024 | Trangdth |
+|  | 1. Section 7: OneCatalogue: Typ0 correction and update section 7.6 Voucher Code module 2. Section 4.12.7 CP rule : Add Award limit use case in FSD | 19/04/2024 | Trangdth |
+|  | 1. Section 5.6 Transaction History: Added "Pool Unit Amount" on Award quick view. 2. Section 5.15 Item Redemption: update business req/ Flow and post condition 3. Section 7.5 Item Price Update flow/ post condition / add effective date | 26/04/2024 | Trangdth |
+|  | 1. Section 4.6 Pool Definition : Add validation for Card entity level field  2. Section 4.13 Campaign Rule Criteria : Correction description of filter value of Number data type  3. Section 5.14 Item Redemption : Correction Wireframe and update business rule  4. Section 7.3 Item master: Add Face value and correction typo | 02/05/2024 | Trangdth |
+|  | 1. Addded description to clear "Balance detail" quick view of Award and Adjustment Transaction Screen (in red text). 2. Section 5.14 Item redemption : Added User Stories and Acceptance criteria | 06/05/2024 | Trangdth |
+|  | 1. Section 4.13 Campaign Rule Criteria: Update String data type: Use Input tag instead of delimiter in case there are many filter value if input type as "value" | 09/05/2024 | Trangdth |
+|  | 1. Section 4.13 Campaign Rule Criteria: Add more description for Date Data type. 2. Section 4.12 Campaign Rule: Add new fields/validation to handle Evoucher Pool and Adjust Rule Type. ( Change in red) | 20/05/2024 | Trangdth |
+|  | 1. Section 4.6: Pool Definition: Add validation for Precision of Pool 2. Section 7.6: Voucher code: Change field name from Voucher type into Promotion Type 3. Section OneAdmin Overview: Update and correction section 3.1/3.2/3.3 4. Section 7.5 Item price: Add item code to avoid confuse 5. Customer Profile: Add "Address Type: field 6. Section 5.6 Item redemption Entry: Remove redudant field and add validation (Change in red text) | 24/05/2024 | Trangdth |
+|  | 1. Counter Definition: Add validation for "Bucket period Unit" 2. Campaign rule: Remove API of master data filed Remove Voucher code Add item code | 30/05/2024 | Trangdth |
+|  | 1. Section 5.9/5.10: Attribute/Counter: Correction and update more detail 2. Section 5.6: Transaction History: Remove Deleted field, correction typo and update detail for quick view 3. Section 5.11/5.12: Adjustment /Transfer balance: Correction process flow and business 4, Section 5.15: Award transaction: Update process flow on TP side 5. Other section: Update and correct to match with the system | 17/06/2024 | Trangdth |
+|  | All sections: Add more description for number field if needed | 19/06/2024 | Trangdth |
+|  | 1. Campaign formula /Business rule : Update validation for "Amount " field (F4/F6)  2. Section 5.2.6.2: Customer’s rewards statistic : Remove total spending, Update logical for Points/Cash back  All change in red text | 24/06/2024 | Trangdth |
+|  | 1. Add section 3: Oneadmin: Overview about the OLS system : Search/Filter/Add/View/Edit/Approve/History  2. Add Section 4: Application Parameter  3. Update section 6.2.6: Customer 360=>Business Rule: Correct typo. Add more detail for pool balance information and most redeemed item | 12/07/2024 | Trangdth |
+|  | Correction typos | 11/11/2024 | Trangdth |
+

docs/specs/customer_management/account.md

@@ -0,0 +1,46 @@
+---
+title: "Account"
+type: OpenSpec
+status: Draft
+domain: Customer Management
+---
+
+# Account
+
+## Requirement Definition
+Manages customer account information, which is either sent from an external system to OLS or added by users manually via the OLS system.
+
+## Process Flow
+
+### Pre-Conditions
+- Users must have access rights in the "Account" module.
+- An account type must exist in OLS before an account of that type can be added.
+- The user must select a customer to access the Account tab.
+
+## Business Rules
+
+### Data Schema
+
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| CIF Number | CIF number of selected customer. | String | Required. Read-only on creation. |
+| Product Account Level (PAL) | Product Account Level. | Enum (Lookup) | Required. |
+| Product Account Type (PAT) | Product Account Type. | Enum (Lookup) | Required. PAL + PAT = Account Type. |
+| Account Number | Product Account Number. | String (20) | Required. Combination of Account No + Account Type must be unique. |
+| Account Open Date | Open date of the account. | Date | Required. |
+| Account Indicator | Personal [P] or Corporate [C]. | Enum (Lookup) | Required. |
+| Account Block Code | Used to block transactions. | String (10) | Optional. |
+| Block Code Reason | Reason for blocking. | String (100) | Optional. |
+| Block Code Last Update Date | Date block was applied. | Date | Optional. |
+| Cycle | Statement cycle date. | Integer (2) | > 0 if provided. |
+| Account Status | Status of the account. | Enum (Lookup) | Required. |
+
+### Execution
+- Each account belongs to one Customer. The CIF number cannot be changed via this screen (requires CIF Merge batch).
+- Records managed by OLSACCT batch cannot typically be changed from the admin screen.
+- On Add: Rejected if Account No + Account Type already exists. Else, record added to PRODUCT_ACCOUNT and LOYALTY_ACCOUNT_PRODUCT created.
+- On Update: Must exist in OLS. Original record moved to history.
+- On Delete: Rejected if linked to an active Card record. Else, logical delete applied (moved to history).
+
+## Exception Flow
+- Input validation failures stop the action.

docs/specs/customer_management/adjustment.md

@@ -0,0 +1,53 @@
+---
+title: "Adjustment"
+type: OpenSpec
+status: Draft
+domain: Customer Management
+---
+
+# Adjustment
+
+## Requirement Definition
+Allows manual posting of adjustment transactions to correct balance discrepancies.
+
+## Process Flow
+
+### Pre-Conditions
+- Users must have access rights in the "Adjustment Entry" module.
+- Records require Maker-Checker approval.
+
+## Business Rules
+
+### Data Schema
+
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| Posted Transaction By | Card, Account, or CIF. | Enum | Required. |
+| Card / Account / CIF | Identifier based on above selection. | String | Required. |
+| Adjustment Quantity Sign | Positive or Negative adjustment. | Enum | Required. |
+| Store | Store of transaction. | Enum (Lookup) | Required. |
+| Pool Id | Pool to be adjusted. | Enum (Lookup) | Required. Must respect entity level logic. |
+| Transaction Date | Transaction date time. | Date | Required. |
+| Expiry Date (Positive) | Expiry date of the new bucket. | Date | Required if Positive Adjustment. Defaults to pool policy. |
+| Bucket Expiry Date (Negative)| Specific bucket to deduct from. | Enum (Lookup) | Optional. If empty, uses FIFO Redemption approach. |
+| Adjustment Quantity | Amount to adjust. | Decimal | Required. Must be > 0. |
+| Reason Code | Reason for adjustment. | Enum (Lookup) | Required. |
+| Transaction Code | OLS transaction code. | Enum (Lookup) | Required. |
+| Remarks | Additional notes. | String (100) | Optional. |
+
+### Execution
+- **Pending/Approve Flow**: New adjustments go to a Pending state. Authorized user must approve.
+- **Positive Adjustments**: 
+  - Offsets any negative balance buckets first.
+  - Remaining points added to a new bucket with specified Expiry Date.
+- **Negative Adjustments**: 
+  - If a specific Bucket Expiry Date is chosen, deduction happens there.
+  - Otherwise, points are deducted based on FIFO.
+- OLS validates status, permissions, and block codes for the entity.
+
+## Post-Conditions
+- Pool balance buckets updated.
+- Transaction logged in history.
+
+## Exception Flow
+- Validation failures or insufficient permissions.

docs/specs/customer_management/attribute.md

@@ -0,0 +1,51 @@
+---
+title: "Attribute"
+type: OpenSpec
+status: Draft
+domain: Customer Management
+---
+
+# Attribute
+
+## Requirement Definition
+Provides a consolidated view of all attributes assigned to a customer, account, or card, populated by batch processes or Campaign Rules.
+
+## Process Flow
+
+### Pre-Conditions
+- Users must have access rights in the "Attribute" module.
+
+## Business Rules
+
+### Data Schema
+
+#### Attribute Value Detail
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| Attribute Group | Group of attribute. | String | Read-only. |
+| Attribute ID | Attribute ID. | String | Read-only. |
+| Attribute Name | Attribute Name. | String | Read-only. |
+| Entity | Client, Product_Account, or Card. | Enum | Read-only. |
+| Entity ID | CIF Number, PA Number, or Card Number based on Entity. | String | Read-only. |
+| Account Type | Required for Account attribute. | String | Read-only. |
+| Attribute Value | Value of the attribute. | String/Number | Read-only. |
+| Effective Date From | Start date. | Date | Read-only. |
+| Effective Date To | End date. | Date | Read-only. |
+
+#### Linked Campaign Details
+Lists Campaign Rules referencing this attribute.
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| Campaign ID | Campaign ID. | String | Read-only. |
+| Campaign Name | Name of Campaign. | String | Read-only. |
+| Campaign Rule | Campaign Rules ID. | String | Read-only. |
+| Campaign Rule Name | Name of Campaign Rule. | String | Read-only. |
+| Effect Date | Effective from and to dates. | Date | Read-only. |
+
+### Execution
+- **View-only screen.**
+- Data from `ATTRIBUTE_VALUE` table.
+- Filterable by Entity level and effective dates. Only effective records listed by default.
+
+## Exception Flow
+- N/A

docs/specs/customer_management/award_transaction.md

@@ -0,0 +1,52 @@
+---
+title: "Award Transaction"
+type: OpenSpec
+status: Draft
+domain: Customer Management
+---
+
+# Award Transaction
+
+## Requirement Definition
+Allows users to review, verify, and manually create Award Transactions to grant points/rewards to a customer's account.
+
+## Process Flow
+
+### Pre-Conditions
+- Users must have access rights in both the "Customer Profile" and "Award Transaction" modules.
+- The user must select a customer on the customer profile listing page.
+- Dependent on access rights, users can view, add, edit, or approve manual Award Transaction records.
+
+## Business Rules
+
+### Data Schema
+
+#### General Information
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| Posted Transaction By | Card, Account, or CIF. | Enum | Required. |
+| Card / Account / CIF | Identifier based on above selection. | String | Required. |
+| Store | Store of transaction. | Enum (Lookup) | Required. |
+| Transaction Date | Transaction date time. | Date | Required. |
+| Reason Code | Reason for the award. | Enum (Lookup) | Required. |
+| Transaction Code | OLS transaction code. | Enum (Lookup) | Required. |
+| Remarks | Additional notes. | String (100) | Optional. |
+
+#### Award Details
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| Pool Id | Pool to be awarded. | Enum (Lookup) | Required. Must respect entity level logic. |
+| Award Quantity | Points to award. | Decimal | Required. Must be > 0. |
+| Expiry Date | Expiry date of the awarded points bucket. | Date | Required. Defaults based on pool's expiry policy. |
+
+### Execution
+- **Pending/Approve Flow**: New award transactions go to a Pending state. An authorized user must approve them.
+- Manual awards act similarly to positive Adjustments but follow the Award business logic path (potentially triggering Campaign Rules if configured).
+- Points are added to a new bucket with the specified Expiry Date.
+
+## Post-Conditions
+- Pool balance buckets are updated.
+- Transaction is logged in history.
+
+## Exception Flow
+- Validation failures or insufficient permissions.

docs/specs/customer_management/card.md

@@ -0,0 +1,47 @@
+---
+title: "Card"
+type: OpenSpec
+status: Draft
+domain: Customer Management
+---
+
+# Card
+
+## Requirement Definition
+Manages customer card information. Generally updated in the external system and loaded into OLS, thus often view-only, though manual additions/replacements are supported with strict rules.
+
+## Process Flow
+
+### Pre-Conditions
+- Users must have access rights in the "Card" module.
+- The parent account must exist in OLS before adding a card.
+- User must select a customer.
+
+## Business Rules
+
+### Data Schema
+
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| CIF Number | CIF Number of the card. | String | Required. Defaults to selected customer but can change for Supplement Cards. |
+| Account Type | Product Account Level + Type. | Enum (Lookup) | Required. |
+| Account Number | Parent Product Account Number. | Enum (Lookup) | Required. |
+| Card Number | The card number. | String (20) | Required. Must be globally unique. |
+| Masked Card Number | Masked version. | String (20) | Optional. |
+| Cardholder Name | Name on card. | String (50) | Required. |
+| Card Indicator | Supplement [S], Principal [P], Corporate [K]. | Enum (Lookup) | Required. If Principal, Card CIF must equal Account CIF. |
+| Card Status | Card status. | Enum (Lookup) | Required. |
+| Card Block Code | Block code for transactions. | String (10) | Optional. |
+| Card Activation Date | Date activated. | Date | Optional. |
+| Card Creation Date | Date created. | Date | Required. |
+| Card Expiry Date | Expiry date. | Date | Required. |
+| Old Card Number | For replacements only. | Enum (Lookup) | Required only if adding a replacement card for an existing one. |
+
+### Execution
+- Each Card belongs to one Account and one Customer. Changes to CIF/Account require CIF Merge batch.
+- On Add: Rejected if Card Number already exists, or if Account/CIF does not exist. Adds to CARD and CARD_PRODUCT_ACCOUNT_REL.
+- On Delete: Logical delete (moved to history).
+- Replacement Flow: When replacing an old card, the new card gets the same PSN (Plastic Serial Number). The old card remains active until its status/block code is updated. All attributes, counters, and pool buckets linked to the old card are automatically linked to the new card.
+
+## Exception Flow
+- Validation failures.

docs/specs/customer_management/counter.md

@@ -0,0 +1,51 @@
+---
+title: "Counter"
+type: OpenSpec
+status: Draft
+domain: Customer Management
+---
+
+# Counter
+
+## Requirement Definition
+Displays all counter buckets for a chosen customer, including Customer-level, Account-level, and Card-level counters, which are updated by Campaign Rules or manually.
+
+## Process Flow
+
+### Pre-Conditions
+- Users must have access rights in the "Counter" module.
+
+## Business Rules
+
+### Data Schema
+
+#### Counter Value Detail
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| Counter | Counter identifier. | String | Read-only. |
+| Entity | Cust [CU], Account [PA], Card [CA]. | Enum | Read-only. |
+| Entity ID | CIF Number, Account Number, or Card Number. | String | Read-only. |
+| What to count | The data entity tracked. | String | Read-only. |
+| Counter Value | Counter value. | Decimal | Read-only. |
+| Bucket Start Date | Start date. | Date | Read-only. |
+| Bucket End Date | End date. | Date | Read-only. |
+| Counter State | A: Awarded, C: New. | Enum | Read-only. |
+
+#### Counter Statistic (History)
+Lists transactions that updated this counter bucket.
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| Reference No | OLS Transaction Reference Number. | String | Read-only. |
+| Post Date | Post date of the transaction. | Date | Read-only. |
+| Counter Value | Value updated on this transaction. | Decimal | Read-only. |
+| Bucket Number | Bucket number of selected counter. | Integer | Read-only. |
+| Update Date | System date when updated. | Date | Read-only. |
+| Updated By | Batch/User who posted transaction. | String | Read-only. |
+
+### Execution
+- **View-only screen.**
+- Values retrieved from `Campaign_Counter` table.
+- Filterable by Entity level and bucket periods. Effective records listed by default.
+
+## Exception Flow
+- N/A

docs/specs/customer_management/customer_360.md

@@ -0,0 +1,56 @@
+---
+title: "Customer 360"
+type: OpenSpec
+status: Draft
+domain: Customer Management
+---
+
+# Customer 360
+
+## Requirement Definition
+A centralized dashboard providing key information about a customer, giving a real-time view of customer behavior, balances, cards, and transaction statistics.
+
+## Process Flow
+
+### Pre-Conditions
+- Users must have access rights in the "Customer Profile" module and select a customer to view the dashboard.
+
+## Business Rules
+
+### Dashboard Components
+
+#### 1. Customer Information
+- Summarized view of the customer's profile (name, CIF, status, etc.). Allows edit/delete actions from a pop-up.
+
+#### 2. Customer's Rewards Statistic
+- **Points**: Total available points.
+- **Cash back**: Total available cash back.
+- (Uses system date to determine balance bucket periods).
+
+#### 3. Account / Card Information
+- Lists all of the customer's accounts and cards.
+- If there are no cards, it shows just the accounts.
+- Columns include: Account Type, Account No, Card No, CIF, Card Status, Indicator, Expiry, Account Block Code, Account Status, Open Date.
+
+#### 4. Transaction Statistic
+- **Line Chart**: Shows fluctuation in balance (Earned/Redeemed/Adjusted) for a selected pool over a specified period (This month, Last month, Last 3/6 months). Data from TRANSACTION table.
+- **Combo Chart**: Illustrates relationship between total number of transactions (line) and total transacted merchants (bar) over a specified period.
+
+#### 5. Customer Activities
+- Logs loyalty program actions (enroll, earn, redeem, transfer), feedback/reviews, email engagement, and account management events.
+- Filterable by timeframe.
+
+#### 6. Customer Segmentation
+- Shows the demographic (Gender, Age, Marital Status, Income) and behavioral (Frequency, Membership class, Purchase channel, Hobby) segments the customer belongs to.
+
+#### 7. Most Redeemed Items
+- Displays the top N (configurable, default 10) redeemed items of the customer.
+- Shows Item Code, Name, Category, Quantity, Points used, Cash amount used.
+- Data from CAT_CATALOGUE_TRANS_DETAIL ordered by quantity descending.
+
+#### 8. Balance Information
+- Summary of all Pool balances for the customer.
+- Shows Pool ID, Pool Name, Balance (sum of all buckets), Redeemable Balance (non-expired/available), Earliest Expiring Balance and Date.
+
+## Post-Conditions
+- Strategy guide for personalized experiences.

docs/specs/customer_management/customer_profile.md

@@ -0,0 +1,62 @@
+---
+title: "Customer Profile"
+type: OpenSpec
+status: Draft
+domain: Customer Management
+---
+
+# Customer Profile
+
+## Requirement Definition
+Provides view-only access to Customer details within the OLS administration screens. Customer records are primarily updated from source systems via batch processes.
+
+## Process Flow
+
+### Pre-Conditions
+- Users must have access rights in the "Customer Profile" module.
+
+## Business Rules
+
+### Data Schema
+
+#### General Information
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| CIF Number | Unique CIF Number assigned to each customer. | String (30) | Required. |
+| First Name | Customer First Name. | String (50) | Required. |
+| Last Name | Customer Last Name. (First Name + Last Name = Customer Name) | String (50) | Required. |
+| Date of Birth | Customer birth date. | Date | Required. |
+| Registration Date | Date customer opened an account. | Date | Optional. |
+| Gender | Customer Gender. | Enum (Lookup) | Optional. |
+| Customer Status | Customer status. | Enum (Lookup) | Required. |
+| Customer Block Code | Customer block code. | String (10) | Optional. |
+| Marital Status | Customer marital status. | Enum (Lookup) | Optional. |
+| ID Type | ID Type of cardholder ID. | Enum (Lookup) | Optional. |
+| Cardholder ID | Cardholder ID. | String (30) | Required if ID Type is selected. |
+| Country Origin | Customer country origin. | Enum (Lookup) | Optional. |
+| Customer Income | Customer income. | Decimal (14,2) | >= 0 if provided. |
+| Profile Picture | Uploaded image file. | Image / URL | Optional. |
+
+#### Contact Detail
+Each customer can have more than one contact detail (e.g., customer contact, guardian contact). At least one must be provided.
+
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| Address Type | Home/Business/Shipping/Billing. | Enum | Required. Unique per customer. |
+| Phone Number | Phone number. | String (30) | Required. |
+| Email Address | Email address. | String (50) | Required. Must be valid email format. |
+| Address 1 | Main address. | String (100) | Optional. |
+| Address 2 | Other address. | String (100) | Optional. |
+| State | State code. | Enum (Lookup) | Optional. |
+| City | City code. | Enum (Lookup) | Optional. |
+| Zip Code | Postal code. | Enum (Lookup) | Optional. |
+
+### Execution
+- When a new customer is added in OLS, it is added to Client tables, and the corresponding LOYALTY_ACCOUNT is created.
+- A request to add a customer whose CIF already exists with an Active status is rejected.
+- A request to update/delete a CIF that does not exist or is inactive is rejected.
+- Deletion of a CIF linked to an active Account is rejected. Logical delete is used (moving to History).
+- Admin screen changes are generally restricted for records managed by the OLSCUST batch.
+
+## Exception Flow
+- N/A

docs/specs/customer_management/item_redemption.md

@@ -0,0 +1,59 @@
+---
+title: "Item Redemption"
+type: OpenSpec
+status: Draft
+domain: Customer Management
+---
+
+# Item Redemption
+
+## Requirement Definition
+Allows users (e.g., call center staff) to manually redeem items for customers in real-time, exchanging points (and optionally cash) for catalog items.
+
+## Process Flow
+
+### Pre-Conditions
+- Users must have access rights in the "Item Redemption Entry" module.
+- Real-time catalog configuration and customer balances must be available.
+
+## Business Rules
+
+### Data Schema
+
+#### General Information
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| Posted Transaction By | Card, Account, or CIF. | Enum | Required. |
+| Card / Account / CIF | Identifier. | String | Required. |
+| Redemption Channel | Channel of redemption. | Enum (Lookup) | Required. |
+| Redemption Date | Transaction date. | Date | Required. |
+| Store | Active store in OLS. | Enum (Lookup) | Required. |
+| Applicable Fee | Apply item fee if configured. | Boolean | Default False. |
+
+#### Item Details
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| Catalogue Code | Catalog to redeem from. | Enum (Lookup) | Required. |
+| Item | Item code. | Enum (Lookup) | Required. Item must have a matched price. |
+| Redemption Mode | Fixed Points or Fixed Partial (Cash + Points).| Enum | Required based on price configuration. |
+| Unit Price (Points) | Point cost per item. | Decimal | Required. Fixed for Fixed Points; editable but >= minimum for Fixed Partial. |
+| Unit Cash Amount | Cash cost per item. | Decimal | Required for Fixed Partial. Calculated: (Full Price - Unit Price) * Price in Cash. |
+| Unit Face Value | Face value of item. | Decimal | Read-only. Base face value or price config face value. |
+| Quantity on Hand | Available inventory. | Integer | Read-only. Displayed if tracked by quantity. |
+| Redemption Quantity | Amount to redeem. | Integer | Required. Must be > 0 and <= Quantity on Hand. |
+| Total Price (Points) | Total points required. | Decimal | Read-only. Unit Price * Redemption Quantity. |
+| Total Cash Amount | Total cash required. | Decimal | Read-only. Unit Cash Amount * Redemption Quantity. |
+| Delivery Address | Delivery details for Physical/Evoucher. | String | Auto-populated from profile, editable. |
+
+### Execution
+- Transactions cannot be modified after posting.
+- Validates block codes and permissions.
+- Net transaction value is sum of tax, total fee, and total cash required.
+- At EOD, approved items are output to a file for partners to fulfill.
+
+## Post-Conditions
+- Balances and inventory updated.
+- Transaction viewable in history.
+
+## Exception Flow
+- Insufficient balance or TP validation failure blocks transaction.

docs/specs/customer_management/no_hit_cp_transaction.md

@@ -0,0 +1,51 @@
+---
+title: "No-Hit CP Transaction"
+type: OpenSpec
+status: Draft
+domain: Customer Management
+---
+
+# No-Hit CP Transaction
+
+## Requirement Definition
+Tracks all incoming transactions that trigger a campaign rule but are not eligible (do not meet criteria) OR transactions that have no linked campaign rule. Helps in troubleshooting why a customer did not receive an expected reward.
+
+## Process Flow
+
+### Pre-Conditions
+- Incoming transactions trigger campaigns but do not hit the rule criteria.
+- Users must have access rights in the "No hit CP- Transaction" module.
+
+## Business Rules
+
+### Data Schema
+
+#### Transaction Detail (Incoming request data)
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| CIF Number | CIF Number. | String | Read-only. |
+| Product Account No | Product Account No. | String | Read-only. |
+| Card Number | Card Number. | String | Read-only. |
+| Invoice No | Generated unique incoming transaction ID. | String | Read-only. |
+| Transaction Type | AWD / RED / ADJ. | Enum | Read-only. |
+| OLS Transaction Code | Used to locate CP rule. | String | Read-only. |
+| Transaction Amount | Gross amount or adjust point. | Decimal | Read-only. |
+| Various | Store, Terminal, MCC, Currency, etc. | Various | Sourced from incoming transaction. |
+
+#### CP Rule Listing (Error Details)
+Displays details for each Campaign Rule the transaction triggered but failed to hit.
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| Campaign ID | Campaign ID. | String | Read-only. |
+| Campaign Rule | Campaign Rule ID. | String | Read-only. |
+| Pool ID | Reward pool. | String | Read-only. |
+| Error Code | Error response code from OLS. | String | Read-only. |
+| Error Descriptions | Detailed description of why criteria failed. | String | Read-only. |
+
+### Execution
+- **View-only screen.**
+- Data is sourced from `OLS_ORPHAN_TXN_NO_HIT`.
+- The error description should specify exactly which criteria failed (e.g., MCC didn't match, Minimum amount not met).
+
+## Exception Flow
+- N/A

docs/specs/customer_management/pool_balance_detail.md

@@ -0,0 +1,54 @@
+---
+title: "Pool Balance Detail"
+type: OpenSpec
+status: Draft
+domain: Customer Management
+---
+
+# Pool Balance Detail
+
+## Requirement Definition
+Provides a summary and detailed breakdown of all reward pools and their balance buckets for a selected customer.
+
+## Process Flow
+
+### Pre-Conditions
+- Users must have access rights in the "Balance Enquiry" module.
+
+## Business Rules
+
+### Data Schema
+
+#### Pool Balance Summary
+Displays a row for each pool the customer interacts with.
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| Pool ID | Pool ID. | String | Read-only. |
+| Pool Name | Pool Name. | String | Read-only. |
+| Pool Type | Pool Type. | String | Read-only. |
+| Pool Entity Level | Customer, Account, or Card level. | String | Read-only. |
+| Balance | Sum of all balance buckets. | Decimal | Read-only. |
+| Redeemable Balance | Sum of non-expired, available buckets. | Decimal | Read-only. |
+| Next Expiring Balance | The earliest non-expired balance bucket amount. | Decimal | Read-only. |
+
+#### Pool Balance Detail (Bucket Breakdown)
+Displays the individual expiry buckets for a selected pool.
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| Account Type | Account Type. | String | Read-only. |
+| Account No | Account Number. | String | Read-only. |
+| Card Number | Card Number (only if Card pool entity level). | String | Read-only. |
+| Pool ID | Selected Pool ID. | String | Read-only. |
+| Balance | Non-zero balance of the bucket. | Decimal | Read-only. |
+| Expiry Date | Expiring date of the bucket. | Date | Read-only. |
+
+### Execution
+- **View-only screen.** No modifications allowed directly.
+- Grouping/Visibility is dependent on the Pool Entity Level:
+  - Customer level: Shows buckets grouped under accounts, even though earned at customer level.
+  - Account level: Shows buckets earned by the specific Account.
+  - Card level: Shows buckets earned by the specific Card.
+- Expired buckets that have not yet forfeited are shown.
+
+## Exception Flow
+- N/A

docs/specs/customer_management/re_instatement.md

@@ -0,0 +1,46 @@
+---
+title: "Re-Instatement"
+type: OpenSpec
+status: Draft
+domain: Customer Management
+---
+
+# Re-Instatement
+
+## Requirement Definition
+Allows manual re-instatement of expired balance buckets that have not yet been forfeited.
+
+## Process Flow
+
+### Pre-Conditions
+- Users must have access rights in the "Re-Instatement" module.
+- The customer must have expired pool buckets that are within the grace period (not yet forfeited).
+- Requires Maker-Checker approval.
+
+## Business Rules
+
+### Data Schema
+
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| Posted Transaction By | Card, Account, or CIF. | Enum | Required. |
+| Card / Account / CIF | Identifier based on above selection. | String | Required. |
+| Store | Store of transaction. | Enum (Lookup) | Required. |
+| Pool Id | Pool of the bucket to re-instate. | Enum (Lookup) | Required. Lists pools with non-forfeited expired balances. |
+| Bucket to Re-instate | Specific expired bucket to reinstate. | Enum (Lookup) | Required. |
+| Expiry Date | New expiry date of the reinstated points. | Date | Required. |
+| Reason Code | Reason for re-instatement. | Enum (Lookup) | Required. |
+| Remarks | Additional notes. | String (100) | Optional. |
+
+### Execution
+- **Pending/Approve Flow**: New requests go to a pending list. Authorised user approves.
+- Re-instatement is posted as an Adjustment.
+- The expired bucket balance is set to 0.
+- If a bucket with the new Expiry Date already exists, the amount is added to it.
+- Otherwise, a new bucket is created with the new Expiry Date.
+
+## Post-Conditions
+- Balances updated and logged as adjustments.
+
+## Exception Flow
+- Rejected by TP validation or block code.

docs/specs/customer_management/statement.md

@@ -0,0 +1,52 @@
+---
+title: "Statement"
+type: OpenSpec
+status: Draft
+domain: Customer Management
+---
+
+# Statement
+
+## Requirement Definition
+Provides a list of all transactions for an account/customer over a set period (usually monthly). Includes earned, redeemed, adjusted points, beginning/ending balances, and expired points.
+
+## Process Flow
+
+### Pre-Conditions
+- Users must have access rights in the "Statement Enquiry" module.
+
+## Business Rules
+
+### Data Schema
+
+#### Statement Summary
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| Loyalty Account Number | Identifier. | String | Read-only. |
+| Product Account Number | Identifier. | String | Read-only. |
+| Pool ID | Statement Pool. | String | Read-only. |
+| Cycle Start Date | Previous statement cycle start. | Date | Read-only. |
+| Statement Opening Balance | Previous points balance. | Decimal | Read-only. |
+| Total Award | Earned points in cycle. | Decimal | Read-only. |
+| Total Redeem | Redeemed points in cycle. | Decimal | Read-only. |
+| Total Adjust | Adjusted points in cycle. | Decimal | Read-only. |
+| Statement Closing Balance | Accumulated points at cycle end. | Decimal | Read-only. |
+| Expired Points | Balance in expired but not forfeited buckets. | Decimal | Read-only. |
+| Cycle Statement Date | Generation date. | Date | Read-only. |
+
+#### Transaction Detail
+Lists transactions within the cycle.
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| Reference Number | OLS Reference Number. | String | Read-only. |
+| Transaction Type | Award, Redeem, Adjust. | Enum | Read-only. |
+| Unit | Earned/Redeemed/Adjusted points. | Decimal | Read-only. |
+| Post Date | Post Date. | Date | Read-only. |
+| Transaction Date | Transaction Date Time. | Date | Read-only. |
+
+### Execution
+- **View-only screen.** Records are updated by OLS batch jobs.
+- Output supports Customer and Account level, but stored under Account level.
+
+## Exception Flow
+- N/A

docs/specs/customer_management/transaction_history.md

@@ -0,0 +1,72 @@
+---
+title: "Transaction History"
+type: OpenSpec
+status: Draft
+domain: Customer Management
+---
+
+# Transaction History
+
+## Requirement Definition
+Provides a running record of all transactions logged in OLS for a customer, including cancellations, over a configurable period (normally the last 12 months).
+
+## Process Flow
+
+### Pre-Conditions
+- Users must have access rights in the "Transaction History" module.
+
+## Business Rules
+
+### Data Schema
+
+#### Transaction Detail
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| Invoice No | Internal invoice No generated by OLS. | String | Read-only. |
+| Reference No | OLS Transaction Reference Number. | String | Read-only. |
+| Source Reference Number | Reference number from source system. | String | Read-only. |
+| OLS Transaction Code | OLS Transaction Code. | String | Read-only. |
+| Gross Amount | Gross transaction amount. | Decimal | Read-only. |
+| Nett Amount | Nett transaction amount. | Decimal | Read-only. |
+| Redeem Points | Total redeem points. | Decimal | Read-only. |
+| Points Redeemed Amount | Total redeem points amount. | Decimal | Read-only. |
+| Adjust Points | Total adjustment points. | Decimal | Read-only. |
+| Points Adjustment Amount | Total adjust point amount. | Decimal | Read-only. |
+| Award Points | Total award points. | Decimal | Read-only. |
+| Points Awarded Amount | Total award point amount. | Decimal | Read-only. |
+| Transaction Date | Transaction Date Time. | Date | Read-only. |
+| Post Date | Post Date. | Date | Read-only. |
+| Settlement Date | Settlement Date. | Date | Read-only. |
+| Cancellation Indicator | Cancellation Indicator. | Boolean | Read-only. |
+| MCC | Transaction MCC Code. | String | Read-only. |
+| Store | Transaction Store ID. | String | Read-only. |
+| Terminal | Transaction Terminal ID. | String | Read-only. |
+| Transaction Description | Transaction Description. | String | Read-only. |
+
+#### Quick View Details (Right Panel)
+Provides a breakdown of the transaction into its component effects.
+
+**Reward Details** (Award/Redeem/Adjust)
+- Campaign Rule triggered.
+- Transaction Type.
+- OLS Transaction Code.
+- Reward Pool.
+- Pool Unit / Amount.
+
+**Counter Transaction Detail**
+- Campaign Rule triggered.
+- Counter updated.
+- Entity level.
+- Counter Value.
+- Bucket Number, Start Date, End Date.
+
+**Item Redemption Detail**
+- Item, Description.
+- Redeemed Quantity, Redeemed Points, Cash Amount Used.
+
+### Execution
+- **View-only screen.**
+- Represents all successful transaction impacts on balances, counters, and redemptions.
+
+## Exception Flow
+- N/A

docs/specs/customer_management/transfer_balance.md

@@ -0,0 +1,48 @@
+---
+title: "Transfer Balance"
+type: OpenSpec
+status: Draft
+domain: Customer Management
+---
+
+# Transfer Balance
+
+## Requirement Definition
+Allows manual transfer of points from a customer/account to another customer/account (External) or between the customer's own accounts (Internal).
+
+## Process Flow
+
+### Pre-Conditions
+- Users must have access rights in the "Transfer Balance" module.
+- Requires Maker-Checker approval.
+
+## Business Rules
+
+### Data Schema
+
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| Transfer Mode | Internal (self) or External (to another). | Enum | Required. |
+| Transfer Type | Entity type to transfer from (Card, Account, Client). | Enum | Required. |
+| From | Card/Account/CIF Number to transfer from. | String | Required. |
+| To | Card/Account/CIF Number to transfer to. | String | Required. |
+| Pool ID | The pool from which to transfer. | Enum (Lookup) | Required. Must respect "From" entity level. |
+| Store | The store where transaction is logged. | Enum (Lookup) | Required. |
+| Amount to Transfer | Amount. | Decimal | Required. > 0. Defaults to whole pool balance. |
+| Expiry Date | Expiry date of transferred points. | Date | Required. Defaults to source expiry date. |
+| Transaction Code | OLS transaction code. | Enum (Lookup) | Required. |
+| Reason Code | Pre-defined reason for transfer. | Enum (Lookup) | Required. Determines GL posting accounts. |
+| Remarks | Additional remarks. | String (100) | Optional. |
+
+### Execution
+- **Pending/Approve Flow**: Goes to a pending list. Authorised user approves.
+- OLS validates status, block codes, and permissions for both "From" and "To".
+- Rejected if "From" pool balance is insufficient.
+- Execution transfers all linked pools directly from "From" to "To".
+- Logged as a negative Adjustment on "From" and positive Adjustment on "To".
+
+## Post-Conditions
+- Pool balances updated.
+
+## Exception Flow
+- Insufficient balance, TP validation failures, or input errors block the action.

docs/specs/introduction/terminology.md

@@ -0,0 +1,42 @@
+---
+title: "Terminology"
+type: OpenSpec
+status: Draft
+domain: Introduction
+---
+
+# Terminology
+
+This document defines the terms used across the OLS (One Loyalty System) modules.
+
+## Term Definitions
+
+| Term | Definition |
+|---|---|
+| Amount vs Quantity | - **Amount**: Used in connection with monetary amounts (e.g., Dollars). For example, "Transaction Amount".<br>- **Quantity**: Refers to the number of units of an entity, not monetary value. For example, "Award Quantity" or "Redeem Quantity". |
+| Pool Balance Bucket (Bucket) | Used in the context of a Reward Pool Bucket. A bucket is determined based on the pool entity level and expiration date. |
+| Bucket Expiry Date | - If used in the context of a Counter, refers to the Counter Expiry.<br>- If used in the context of a Reward Pool Bucket, refers to the Pool Expiry. |
+| Campaign Rule (Rule) | A business rule defining the conditions under which a reward will be given, including the type and quantity of the reward. It includes **Rule Criteria** and **Rule Formula**. |
+| CEP | **Counter Extract & Process**. A module for setting up job requests to extract a specified counter based on criteria and using the counter value as a transaction amount to process against Campaign Rules. Includes batch processes to execute requests. |
+| Contributor | Identifies an entity which funds the rewards given under a specific Rule. One or more Contributors can be set up. **Rule Contributor Settings** define the percentage billed to each Contributor (totaling 100%). Default is the transacting business entity if only one exists. Used in end-of-day settlement reports. |
+| Counter | Used to track a customer's transaction statistics (e.g., spend frequency, spend total for specific criteria like MCC). Periodic counts (e.g., monthly) are tracked in separate **Counter Buckets** with a specific **Counter Bucket Date**. |
+| Effective Period | Defines a Start Date and End Date range during which a parameter is effective. Generally starts at 00:00:00 and ends at 23:59:59. Time is considered a discrete quantity in seconds. |
+| Expiry Policy | Defines how rewards expire. New policies based on Card Types will be supported. |
+| Formula | Defines the calculation formula used for calculating the reward quantity. Comprises:<br>- **Formula Header**: General parameters (e.g., max reward amount, rounding rules, Gross vs Nett amount).<br>- **Formula Detail**: Specific calculations, each with an Execution Sequence number (executed in descending order). |
+| Gross Amount | The payment amount before any reward deduction. |
+| Pool (Reward Pool) | Tracks each type of reward (e.g., points, coupons). Associated with a **Pool Expiry Policy**. Rewards expiring on a given date are tracked in a **Pool Bucket** with a **Bucket Expiry Date**. |
+| REP | **Redeem, Extract and Process**. A module for setting up requests to redeem a specified Pool based on criteria, and to output the redemption transaction details. |
+| Rule Criteria | Defines the conditions to be met for a rule to apply. |
+| Rule Pool | A Reward Pool which is updated with the results of a Rule Formula. Each Rule is associated with one Rule Pool. |
+| Transaction Amount | Mandatory column in OLS for award processing. Used as the principal quantity for reward calculations. For payment transactions:<br>- **Gross Amount**: Total payment amount.<br>- **Nett Amount**: Amount remaining after offsetting with redeemed rewards. (Logged in OLS as Gross Amount). |
+| OLS Transaction Code (TC) | The key used to locate applicable Rules for a transaction record. If no Rule is linked to a TC, no reward calculation occurs. Must be defined in the TC look-up table. |
+
+## Document Structure Reference
+The standard modules defined across the system include:
+1. Introduction
+2. OneAccess
+3. Customer Management
+4. Campaign Management
+5. OneCatalogue
+6. OneMarketing
+7. OneTargeting

docs/specs/oneaccess/permission_management.md

@@ -0,0 +1,65 @@
+---
+title: "Permission Management"
+type: OpenSpec
+status: Draft
+domain: OneAccess
+---
+
+# Permission Management
+
+## Requirement Definition
+The Permission Management module is used to maintain Access Rights Groups. It defines:
+1. Which modules and functions can be accessed by users in a group.
+2. Which applicable actions (Add, Change, View, Delete, Approve/Reject, Copy, View History, Save as Template) can be performed by users in each function within each module.
+
+## Process Flow
+
+### Trigger
+- A new user group is defined, requiring permission assignment.
+
+### Pre-Conditions
+- Users must have access rights to the Permission Management module to view, add, or edit permission records.
+
+## Business Rules
+- The system checks and displays available modules/functions for each user based on:
+  - **A**: Permissions assigned directly to the user.
+  - **B**: Permissions assigned to the user's permission group.
+  - **Total User Permission (C)** = Combination of A and B.
+
+### Data Schema
+
+#### General Information
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| Role | The unique identifier of the permission group. | String (10) | Required. |
+| Role Name | Text describing the Permission Group Name. | String (100) | Required. |
+| Permission Type | The type of permission assignment. | Enum | Required. Values: Particular User, User Group. |
+| User | Select one or more users for this role. | Array of User IDs | Required if Permission Type is "Particular User". |
+| User Group | Select one group for this role. | String (User Group ID) | Required if Permission Type is "User Group". |
+| Description | Text describing the Role. | String (200) | Optional. |
+
+#### Module Permissions
+*A hierarchy of modules containing the list of available functions (Top-level and Second-level modules).*
+
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| View | Allows viewing data available in the function. | Boolean | |
+| Create | Allows creating data in the function. (Includes "Save as draft" implicitly). | Boolean | |
+| Edit | Allows updating data in the function. | Boolean | |
+| Delete | Allows deleting data in the function. | Boolean | |
+| Copy | Allows copying available data in the function. | Boolean | |
+| Approve | Allows approving/rejecting data in the function. | Boolean | |
+| History | Allows viewing data history (activity log). | Boolean | |
+| Template | Allows saving records as a template. | Boolean | |
+
+#### Access Rights Fields (Field-Level Permissions)
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| View | Allows viewing the specific field on the screen. | Boolean | |
+| Editable | Allows modifying the value of the specific field. | Boolean | |
+
+## Post-Conditions
+- Records are automated for approval upon creation/modification.
+
+## Exception Flow
+- If input data fails validation, the action is canceled, and the operation fails.

docs/specs/oneaccess/user_group.md

@@ -0,0 +1,47 @@
+---
+title: "User Group"
+type: OpenSpec
+status: Draft
+domain: OneAccess
+---
+
+# User Group
+
+## Requirement Definition
+The User Group module is utilized to categorize users who share identical permissions within OLS. It defines the group to be assigned to a particular user or group of users.
+
+## Process Flow
+
+### Trigger
+- A new user group needs to be defined.
+- An existing user group needs to be modified, or a user needs to review the existing group.
+
+### Pre-Conditions
+- Users must have access rights to the User Group module to view, add, or edit user group records.
+
+## Business Rules
+- The user group ID must be a unique value.
+
+### Data Schema
+
+#### General Information
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| User Group ID | The identity of the user group. | String (10) | Required. Must be unique. |
+| User Group Name | The name of the user group. | String (100) | Required. |
+| Description | Description for the user group. | String (200) | Optional. |
+
+#### Group Users (View Only)
+*Lists all active User Profile records assigned to this group.*
+
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| User ID | The identity of the user belonging to the chosen group. | String | Read-only |
+| User Name | The name of the user. | String | Read-only |
+| Email | Email address of the user. | String | Read-only |
+
+## Post-Conditions
+- The data is updated in the database and related screens.
+
+## Exception Flow
+- If input data fails validation, the action is canceled, and the operation fails.

docs/specs/oneaccess/user_profile.md

@@ -0,0 +1,61 @@
+---
+title: "User Profile"
+type: OpenSpec
+status: Draft
+domain: OneAccess
+---
+
+# User Profile
+
+## Requirement Definition
+The User Profile defines user attributes and sets the date and time allowing user access to system functions. It is used for login. Upon logging in, users can view a list of functions with specific operations set in the permission management section.
+
+## Process Flow
+
+### Trigger
+- A new account needs to be defined.
+- Information of an existing account needs to be updated.
+
+### Pre-Conditions
+- Users must have access rights to the User Profile module to view, add, or edit User Profile records.
+
+## Business Rules
+
+### Data Schema
+
+#### General Information
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| User ID | Unique user identifier. | String (10) | Required. Must be unique. |
+| User Name | Name of the user associated with the User ID. | String (50) | Required. |
+| Password | User password. | String (50) | Required for new users. Must meet strong password policies. |
+| Re-enter Password | Confirmation of the password. | String (50) | Must match Password. |
+| Email | User's email address. Can be used for login and password resets. | String (100) | Required. Must be unique. |
+| Default Language | Determines the language for screen labels. | Enum | Required. |
+
+#### Access Detail
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| Access Day | Indicates the days of the week the user has access to the system. | Array of Enums | Required. (e.g., Monday-Sunday) |
+| Access Time | The time on and after which the user has access to the system on allowed days. | Time | Required. |
+| User Profile Effective From Date | Date on and after which the User Profile is effective. | Date | Required. |
+| User Profile Effective End Date | Date on and before which the User Profile is effective. | Date | Required. |
+| User Group | The selected group determining the functions the user can access. | String (User Group ID) | Required. |
+| Report Access Right | Determines which report(s) the user has access to. | String (Report Group ID) | Optional. |
+| User Status | Status of the user account. | Enum | Required. Values: Active, Blocked. |
+
+#### User Permission (View Only)
+*Displays all permissions applicable for the chosen user across top-level and second-level modules.*
+
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| Module Name | The name of the module. | String | Read-only |
+| Permissions | Available actions (View, Create, Edit, Delete, Copy, Approve, History, Template). | Boolean per action | Read-only |
+
+## Post-Conditions
+- When creating a new record, the user account is successfully created.
+- The new user receives an email notification with login instructions and a temporary password.
+- When the password is reset, an email notification is sent to the user's email with the new password.
+
+## Exception Flow
+- No specific exception flow defined.

docs/specs/oneadmin/framework_behavior.md

@@ -0,0 +1,50 @@
+---
+title: "OneAdmin Framework Behavior"
+type: OpenSpec
+status: Draft
+domain: OneAdmin
+---
+
+# OneAdmin Framework Behavior
+
+## Requirement Definition
+OneAdmin is the application framework upon which all OLS administration functions are built. It defines the standard behavior for data maintenance, record lifecycle states, search capabilities, and audit trailing across all modules (e.g., Campaign Management, Customer Management, Catalogue).
+
+## Business Rules
+
+### Maintenance Actions
+The framework supports the following standard maintenance actions across modules:
+- **Add**: Creates a new record in a Pending state.
+- **Edit**: Modifies an existing record. The modifications are saved as a new version in a Pending state, leaving the original active record unchanged until approval.
+- **Copy**: Duplicates an existing record, prompting the user to update unique key values.
+- **Delete**: Marks a record for deletion (Inactive). The deletion request creates a Pending state version.
+- **Approve**: Transitions a Pending record to Active state. The approving user must have appropriate approval rights and cannot be the user who submitted the change.
+- **Reject**: Transitions a Pending record to a Rejected state for follow-up.
+- **Save as Draft**: Temporarily saves the record without publishing it to a Pending state.
+- **Save as Template**: Saves the record details to be reused as a template.
+- **History**: Retrieves previous versions of a record.
+
+### Record State Transitions
+1. **Pending**: When a new record is added, edited, or deleted, the action results in a Pending state.
+2. **Active**: Upon approval, a Pending record becomes Active. Only Active records are considered during transaction processing.
+3. **Rejected**: If an approver rejects a Pending record, its state becomes Rejected.
+4. **Inactive**: An approved deletion sets the record to Inactive, blocking it from further use.
+
+### Search and Filtering Capabilities
+- **Quick Search**: Keyword-based search applied to all character columns using a case-insensitive "Contains" operator.
+- **Advanced Filter**: Allows compound criteria using AND logic. Supported operators vary by data type:
+  - **Character**: Equal, Not Equal, Empty, Not Empty, Contains, Not Contains, In, Not In.
+  - **Number**: Equal, Not Equal, Greater Than, Less Than, Greater Than Or Equal To, Less Than Or Equal To, Between.
+  - **Boolean**: Equal.
+  - **DateTime**: Equal, Not Equal, Greater Than Or Equal To, Less Than Or Equal To, Between.
+
+### Audit Logging
+Every record update or approval is logged. The following audit fields are maintained for all records:
+- **Last Updated By**: User ID (or Batch ID) that last updated the record.
+- **Last Updated Date**: Date and time of the last update.
+- **Last Approved By**: User ID that last approved the record.
+- **Last Approved Date**: Date and time of the last approval.
+
+## Post-Conditions
+- All updates are reflected in the database immediately upon approval.
+- Concurrent edits and approvals are strictly logged and version-controlled.

docs/specs/onecatalogue/catalogue.md

@@ -0,0 +1,44 @@
+---
+title: "Catalogue"
+type: OpenSpec
+status: Draft
+domain: OneCatalogue
+---
+
+# Catalogue
+
+## Requirement Definition
+A Catalogue groups items for online redemptions (e.g., Cash-back rebates, frequent flyer miles, merchant vouchers). All items included in the Catalogue must be tagged with a specific Catalogue Code. The system supports multiple concurrent catalogues, each with its own Item Master records.
+
+## Process Flow
+
+### Pre-Conditions
+- Users must have access rights to the "Catalogue" screen under the "OneCatalogue" module.
+- Depending on access rights, users can view, add, edit, or approve catalogue records.
+
+## Business Rules
+- Each Catalogue operates within a Start / End date range.
+- Items are only presented to customers if the current date falls within the Catalogue's effective date range.
+
+### Data Schema
+
+#### General Information
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| Catalogue Code | User-specified code identifying the catalogue. Used by front-end systems. | String (10) | Required. |
+| Description | A description of this catalogue. | String (50) | Required. Default description if no specific language is chosen. |
+| Effective From Date | Date from which the catalogue is effective. | Date | Required. |
+| Effective To Date | Date until which the catalogue is effective. | Date | Required. |
+| Icon | Icon of the catalogue. | Image | Optional. |
+
+#### Content Configuration
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| Language | Selected language for specific description setup. | String (Lookup) | Required. |
+| Description | Description of the catalogue in the chosen language. | String (100) | Required. |
+
+## Post-Conditions
+- The Catalogue information is returned to the front-end during Item Enquiry responses for searching.
+
+## Exception Flow
+- None specified.

docs/specs/onecatalogue/category.md

@@ -0,0 +1,40 @@
+---
+title: "Category"
+type: OpenSpec
+status: Draft
+domain: OneCatalogue
+---
+
+# Category
+
+## Requirement Definition
+A Category is a logical group within a catalog that organizes items. Multiple Categories can be linked to form a hierarchy, which is utilized on the Member site.
+
+## Process Flow
+
+### Pre-Conditions
+- Users must have access rights to the "Category" screen under the "OneCatalogue" module.
+- Depending on access rights, users can view, add, edit, or approve category records.
+
+## Business Rules
+
+### Data Schema
+
+#### General Information
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| Category Code | User-specified code identifying the category. | String (10) | Required. |
+| Description | Default description of this category. | String (100) | Required. |
+| Effective From Date | Date from which the category is effective. | Date | Optional. If empty, non-expiring. |
+| Effective To Date | Date until which the category is effective. | Date | Optional. |
+| Parent Category | Identifies the parent category to form a hierarchy. | String (Lookup) | Optional. |
+| Display Ordering | Ordering sequence on the Member Site. | Integer | Optional. |
+| Icon | Icon of the category. | Image | Optional. |
+| Image Group | Selected image group. | String (Lookup) | Optional. |
+| Image | Selected image from Image Stock. | String (Lookup) | Required if Image Group is selected. |
+
+#### Content Configuration
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| Language | Selected language for specific description setup. | String (Lookup) | Required. |
+| Description | Description of the category in the chosen language. | String (100) | Required. |

docs/specs/onecatalogue/item_master.md

@@ -0,0 +1,65 @@
+---
+title: "Item Master"
+type: OpenSpec
+status: Draft
+domain: OneCatalogue
+---
+
+# Item Master
+
+## Requirement Definition
+Item Master defines details about a particular item, such as prices, quantities, availability dates, terms, and conditions.
+
+## Process Flow
+
+### Pre-Conditions
+- Users must have access rights in the "Item Master" screen under the "OneCatalogue" module.
+- Depending on access rights, users can view, add, edit, or approve Item Master records.
+
+## Business Rules
+
+### Data Schema
+
+#### General Information
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| Catalogue Code | The Catalogue for which this item is configured. | String (Lookup) | Required. |
+| Category | Category under which this item is tagged. | Array of Strings (Lookup) | Optional. |
+| Item Code | Identifier for the item to be added. | String (10) | Required. |
+| Item Name | Short description used by customer-facing application. | String (50) | Required. |
+| Redemption From Date | Date from which the item is available for redemption. | Date | Required. Must fall within Catalogue/Category date range. |
+| Redemption To Date | Date until which the item is available. | Date | Required. Must fall within Catalogue/Category date range. |
+| Redemption Store | Supplier/merchant of this item. | String (Lookup) | Optional. |
+| Redemption Transaction Code | OLS TC used for redemption processing. | String (Lookup) | Required. |
+| Award Transaction Code | OLS TC used to locate award campaign rules upon redemption. | String (Lookup) | Optional. |
+| Item Type | Type of item. | Enum | Required. Values: Miles, Physical, eVoucher, Donation, Cash rebate, Other. |
+| Voucher Code | Selected voucher code. | String (Lookup) | Required if Item Type is eVoucher. |
+| Face Value | Value of the cash rebate/voucher/miles that customer receives. | Decimal (14,2) | Required for Cash rebate/eVoucher/Miles. Must be positive. |
+| Display on Member Site | Determines if the item is displayed on the member site. | Boolean | Default: True. |
+| Hot Item | Indicates if this is a hot item. | Boolean | Active only if Display on Member Site is True. Default: False. |
+| Display Ordering | Ordering sequence to display on member site. | Integer | Must be > 0. Active only if Display on Member Site is True. |
+| Track Quantity on Hand | Enables inventory control. | Boolean | Default: False. Forced to True if item is a Voucher Code. |
+| Initialize Quantity of Stocks | Initial stock quantity. | Integer | Required if Track Quantity on Hand is True. Read-only if item has been redeemed. |
+
+#### Item Detail (Localization)
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| Language | Selected language. | String (Lookup) | Required. |
+| Item Name | Specific item name in the chosen language. | String (50) | Required. |
+| Item Description | Specific item description. | String (100) | Optional. |
+| Item Content | Detailed content/information. | String (2000) | Optional. |
+| How to use | Instructions on how to use the item. | String (2000) | Optional. |
+| Term and Condition | Free text for Terms and Conditions. | String (2000) | Optional. |
+
+#### Contact and Address Information
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| City | City where the item can be used. | String (Lookup) | Required. |
+| Address | Detailed address. | String (200) | Optional. |
+| Email | Contact email. | String (100) | Optional. |
+| Phone | Contact phone number. | String (20) | Optional. |
+
+## Post-Conditions
+- The newly created item should have all required fields populated with valid data.
+- System adds/updates items in the database.
+- Other screens looking up the item screen can use the new item.

docs/specs/onecatalogue/item_price.md

@@ -0,0 +1,54 @@
+---
+title: "Item Price"
+type: OpenSpec
+status: Draft
+domain: OneCatalogue
+---
+
+# Item Price
+
+## Requirement Definition
+Item Price specifies the conversion rate between reward points and redemption quantity, defining pricing tiers based on account types, redemption channels, or specific criteria. It manages redemption options (points only vs. cash and points).
+
+## Process Flow
+
+### Pre-Conditions
+- Users must have access rights in the "Item Master" and "Item Price" screens under the "OneCatalogue" module.
+- Depending on access rights, users can view, add, edit, or approve Item Price records.
+
+## Business Rules
+
+### Data Schema
+
+#### General Information
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| Item Code | The item being configured. | String (Lookup) | Required. |
+| Price Code | Identifier of the item price. | String (10) | Required. |
+| Price Name | Default name of the price. | String (100) | Required. |
+| Effective Start Date | Start date of the price validity. | Date | Required. |
+| Effective End Date | End date of the price validity. | Date | Required. |
+| Redemption Channel | Channel applicable for this price (e.g., Call Center, Mobile App). | String (Lookup) | Required. |
+| Account Type Group | Account Type Group this price applies to. | Array of Strings (Lookup) | Optional. Mutually exclusive with Account Level/Type. |
+| Product Account Level | Account Level this price applies to. | String (Lookup) | Optional. Mutually exclusive with Account Type Group. |
+| Product Account Type | Account Type this price applies to. | Array of Strings (Lookup) | Optional. Mutually exclusive with Account Type Group. |
+| Redemption Pool | Pool from which to deduct points. | String (Lookup) | Required. |
+| Use Only Points from Selected PA Type | Restrict points usage to the selected Account Type/Group. | Boolean | Default: False. |
+| Face Value | The value the customer receives upon redemption. | Decimal (12,2) | Must be > 0. |
+| Price in Point | Price if paid fully in points. | Decimal (12,2) | Must be > 0. |
+| Original Price | The original price of the item (for reference). | Decimal (12,2) | Must be > 0. |
+| Partial Redemption Allowed | Allows a mix of points and cash for redemption. | Boolean | Default: False. |
+| Minimum Partial Redeem Points | Minimum points customer must use for partial redemption. | Decimal (12,2) | Required if Partial Redemption is Allowed. Must be >= 0. |
+| Cash per Point | Cash amount required to substitute one point during partial redemption. | Decimal (12,2) | Required if Partial Redemption is Allowed. Must be > 0. |
+| Applicable Taxes | Tax rate applicable. | String (Lookup) | Optional. |
+
+#### Price Detail (Localization)
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| Language | Selected language. | String (Lookup) | Required. |
+| Item Price Name | Specific name of chosen language. | String (100) | Required. |
+| Description | Description of the price. | String (500) | Optional. |
+
+#### Item Criteria
+- Utilizes the Query Builder logic. Criteria groups can be combined using logical OR/AND operators.
+- Applicable criteria are tagged specifically for the "Item Price" module.

docs/specs/onecatalogue/voucher_code.md

@@ -0,0 +1,58 @@
+---
+title: "Voucher Code"
+type: OpenSpec
+status: Draft
+domain: OneCatalogue
+---
+
+# Voucher Code
+
+## Requirement Definition
+Voucher Codes manage external partner vouchers distributed to customers. Vouchers are imported or generated with specific codes, valid periods, and serial numbers.
+
+## Process Flow
+
+### Pre-Conditions
+- Users must have access rights in the "Voucher Management" screen under the "OneCatalogue" module.
+- Depending on access rights, users can view, add, edit, or approve Voucher records.
+
+## Business Rules
+- Voucher codes cannot be deleted if any associated voucher serial number has been redeemed.
+
+### Data Schema
+
+#### Voucher Statistic (View Only)
+| Field Name | Description | Logic Type |
+|---|---|---|
+| Total Voucher | Total serial numbers under this voucher code. | Integer |
+| Available Vouchers | Total valid, non-expired, ready-to-use vouchers. | Integer |
+| Redeemed Vouchers | Total successfully redeemed vouchers. | Integer |
+| Cancelled Vouchers | Total failed redemptions canceled by customers/system. | Integer |
+| Expired Vouchers | Total expired vouchers not redeemed. | Integer |
+
+#### Voucher Code Detail
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| Voucher Code | Identifier of the voucher. | String (10) | Required. |
+| Description | Description of the voucher. | String (100) | Optional. |
+| Supplier | Partner issuing the voucher. | String (Lookup) | Optional. |
+| Expiry Policy | Determines how the voucher expires. | Enum | Required. Values: Fixed Date, N days from Transaction Date, N days from Post Date, N Months from Transaction Date, N months from Post Date. |
+| Expiry Date | The absolute expiry date. | Date | Required if Expiry Policy is "Fixed Date". |
+| N Param | Parameter N for relative expiry policies. | Integer | Required if Expiry Policy requires N parameter. Must be >= 0. |
+| Generate Voucher | Indicates if OLS generates the voucher (instead of partner upload). | Boolean | Default: False. Read-only if voucher is redeemed. |
+| Quantity | Number of voucher codes to generate. | Integer | Required if Generate Voucher is True. Read-only if voucher is redeemed. |
+| This is a promo code | Indicates if this is a promo code. | Boolean | Default: False. |
+| Promotion Type | Type of discount. | Enum | Required if This is a promo code is True. Values: Fixed Percentage Discount, Fixed Monetary Value Discount, Cashback Voucher, Gift Voucher. |
+| Value | The specific value of the discount. | Decimal (14,2) | Required if Promotion Type is Fixed Monetary Value or Fixed Percentage. Must be > 0. |
+
+#### Voucher Detail (View Only)
+*Displays specific serial numbers assigned to the Voucher Code.*
+
+| Field Name | Description | Logic Type |
+|---|---|---|
+| Voucher Code | The associated voucher code. | String |
+| Voucher No | The serial voucher number. | String |
+| Redemption Date | Date when voucher is redeemed. | Date |
+| Expiry Date | Expiry date of the serial number. | Date |
+| Redemption Indicator | Yes or No. | Boolean |
+| Fulfillment Status | New, Issued, Fulfilled, Cancelled, Rejected. | Enum |

docs/specs/onemarketing/ab_testing.md

@@ -0,0 +1,51 @@
+---
+title: "A/Bn Testing"
+type: OpenSpec
+status: Draft
+domain: OneMarketing
+---
+
+# A/Bn Testing
+
+## Requirement Definition
+Evaluates and optimizes marketing elements (content or target customers) to identify better performing campaigns. Supports A/Bn Content testing (same target, different messages) and A/Bn Target Customer testing (same message, different targets).
+
+## Process Flow
+
+### Pre-Conditions
+- Third-party data/results must be available for OLS to collect and analyze.
+- Users must have access rights in the "A/Bn Testing" module.
+
+## Business Rules
+
+### Data Schema (A/Bn Message Content Testing)
+
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| Campaign ID | Unique identifier. | String (20) | Required. No special characters. |
+| Campaign Description | Description. | String (100) | Optional. |
+| Effective Date From | Start date. | Date | Optional. |
+| Effective End date | End date. | Date | Required. |
+| Message Channel | SMS, Email, Push. | Enum | Required. |
+| Target Customer | OMR Criteria setup for targeting. | Rule | Required. |
+| Variant Content | Multiple variants (A, B, N) defining content based on channel. | Array of Messages | Required. Must be unique within the campaign. |
+| Run Schedule | Schedule parameters. | Complex | Required. |
+
+### Data Schema (A/Bn Target Customer Testing)
+
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| Campaign ID | Unique identifier. | String (20) | Required. No special characters. |
+| Campaign Description | Description. | String (100) | Optional. |
+| Effective Date From | Start date. | Date | Optional. |
+| Effective End date | End date. | Date | Required. |
+| Variant Target Customer | Multiple variants (A, B, N) defining OMR Criteria. | Array of Rules | Required. Must be unique within the campaign. |
+| Run Schedule | Schedule parameters. | Complex | Required. |
+
+### Execution
+- ABn batch job triggers effective testing requests based on schedule.
+- For content testing, sends variant messages to the same subset of targets. Tracks open rates, click-through rates.
+- For target testing, evaluates which criteria setup reaches the most/best customers.
+
+## Post-Conditions
+- Results are reported back to the user to make data-driven decisions on campaign rollout.

docs/specs/onemarketing/blacklist.md

@@ -0,0 +1,36 @@
+---
+title: "Blacklist"
+type: OpenSpec
+status: Draft
+domain: OneMarketing
+---
+
+# Blacklist
+
+## Requirement Definition
+A list of customers excluded from marketing campaigns for strategic reasons (e.g., fraud).
+
+## Process Flow
+
+### Pre-Conditions
+- Users must have access rights in the "Black List" module.
+
+## Business Rules
+
+### Data Schema
+
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| ID | Blacklist identifier. | String (10) | Required. |
+| Name List | Name of the blacklist. | String (50) | Required. |
+| Description | Description. | String (200) | Optional. |
+| Input Type | Input from screen or Upload file. | Enum | Required. |
+| Customer List | List of selected CIF numbers. | Array of Strings (Lookup) | Required if Input Type is "Input from screen". Requires >= 4 digits to search. |
+| Upload File | Uploaded CSV/XLS file. | File | Required if Input Type is "Upload file". Max 50MB. |
+
+### Execution
+- Users can review or download the customer list.
+- Blacklisted customers are strictly blocked from receiving notifications from OMR.
+
+## Exception Flow
+- Validation errors for file type/size during upload display an error message.

docs/specs/onemarketing/frequency_capping.md

@@ -0,0 +1,42 @@
+---
+title: "Marketing Frequency Cap"
+type: OpenSpec
+status: Draft
+domain: OneMarketing
+---
+
+# Marketing Frequency Cap
+
+## Requirement Definition
+Controls the frequency and volume of notifications delivered to customers to prevent overwhelming them. Caps can be set daily, weekly, or monthly per customer across different channels.
+
+## Process Flow
+
+### Pre-Conditions
+- Users must have access rights in the "Frequency Capping" module.
+
+## Business Rules
+
+### Data Schema
+
+#### Edit Mode Configuration
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| Frequency Cap Id | Record identifier. | String (10) | Required. |
+| Notification Channel | SMS, Email, or Push Notifications. | Enum | Required. |
+| Effective Date From | Start date of the cap. | Date | Required. Only one effective cap per channel at any given time. |
+| Effective Date To | End date of the cap. | Date | Required. |
+| Capping Period | Daily, Weekly, or Monthly. | Enum | Required. Each period must have only one cap value. |
+| Maximum number | Max messages per unique customer. | Integer (12) | Required. |
+| Include Whitelist | Disallows/allows whitelist customers to receive more notifications. | Boolean | Default: False. |
+| Customer list | Selected whitelist customers to ignore rules. | Array of Strings (Lookup) | Required if Include Whitelist is True. |
+| Description | Description of the capping. | String (100) | Optional. |
+
+### Execution
+- Frequency Capping is applied to all marketing campaigns at the customer level.
+- System automatically tracks notification counts per customer per channel and period unit.
+- If the customer reaches the cap, further notifications are blocked.
+- Whitelisted customers are excluded from the frequency cap unless explicitly included.
+
+## Post-Conditions
+- System enforces defined limits during OMR batch processing.

docs/specs/onemarketing/marketing_campaign.md

@@ -0,0 +1,62 @@
+---
+title: "Marketing Campaign (OneMarketing Request)"
+type: OpenSpec
+status: Draft
+domain: OneMarketing
+---
+
+# Marketing Campaign (OneMarketing Request)
+
+## Requirement Definition
+Filters target customers that satisfy specific marketing criteria. Triggers either notification messages or reward campaigns (via OLS Transaction Code) for the target customers.
+
+## Process Flow
+
+### Pre-Conditions
+- Users must have access rights in the "Marketing Request" module.
+- Depending on rights, users can view, add, edit, or approve requests.
+- All OMR criteria must be defined as attributes.
+
+## Business Rules
+
+### OMR Criteria Logic
+- Uses Query Builder for marketing criteria.
+- Criteria can be dragged/dropped from the right panel.
+- Supports AND/OR conditions between criteria groups.
+- Introduces NOT toggle for exclusion criteria.
+
+### Data Schema
+
+#### General Information
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| Request ID | Unique identifier. | String (20) | Required. No special characters. |
+| Description | Description. | String (100) | Required. |
+| Effective Date From | Start date. | Date | Required. |
+| Effective Date To | End date. | Date | Required. |
+| Marketing Function | Notification [N] or Trigger Campaign Rule [TCR]. | Enum | Required. |
+
+#### Run Schedule and Message Content
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| Trigger Method | Schedule or Event trigger. | Enum | Required. |
+| Run Schedule | Once Time [O], Daily [D], Weekly [W], Monthly [M], Annually [A]. | Enum | Required if Trigger Method is Schedule. |
+| Schedule Details | Specific details (e.g., Repeat every, Fixed Date, Time of day). | Complex | Required based on Run Schedule. |
+| Business Event | Specific event triggering the request. | Array of Strings (Lookup) | Required if Trigger Method is Event trigger. |
+| Message Template | The marketing message to send. | String (Lookup) | Required if Marketing Function is Notification. |
+| OLS Transaction Code | TC used to trigger campaign rule. | String (Lookup) | Required if Marketing Function is Trigger Campaign Rule. |
+
+#### Targeting
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| Trigger Method | OMR Criteria or Upload file. | Enum | Required. |
+| Targeting Data | The selected OMR criteria setup or the uploaded file. | Rule / File | Required based on Trigger Method. |
+
+### Batch Job Processing
+- OMR job checks effective requests based on processing date.
+- Finds valid jobs based on schedule.
+- Creates notifications or extracts transactions based on criteria.
+- Stops sending when frequency capping limits are reached.
+
+## Post-Conditions
+- Marketing content is sent to target customers, or target customers trigger a Campaign Rule.

docs/specs/onemarketing/marketing_message.md

@@ -0,0 +1,69 @@
+---
+title: "Marketing Message"
+type: OpenSpec
+status: Draft
+domain: OneMarketing
+---
+
+# Marketing Message
+
+## Requirement Definition
+Manages (CRUD) all message templates used in the system. A Message Template can be built for different channels (SMS, Push Notification, Email). The message can be based on pre-defined parameters or HTML files.
+
+## Process Flow
+
+### Pre-Conditions
+- Users must have access rights in the "Marketing Message" module.
+- Depending on rights, users can view, add, edit, or approve message templates manually.
+- OMR criteria must be defined as attributes available in the right panel for drag-and-drop setup.
+
+## Business Rules
+
+### Data Schema (SMS Message)
+
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| Message ID | Unique identifier. | String (10) | Required. No special characters. |
+| Message Description | Description. | String (100) | Required. |
+| SMS Type | Promotion/Marketing or Transaction. | String (Lookup) | Required. |
+| Effective Date From | Start date of the effective period. | Date | Required. |
+| Effective End Date | End date of the effective period. | Date | Required. |
+| SMS Brand Name | Select SMS Sender. | String (Lookup) | Required. |
+| Message | Message content. Supports drag/drop parameters. | String (5000) | Required. Unicode (non-GSM). No images, subject, or attachments. |
+
+### Data Schema (Email Message)
+
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| Message ID | Unique identifier. | String (10) | Required. No special characters. |
+| Message Description | Description. | String (100) | Required. |
+| Email Type | Promotion/Marketing or Transaction. | String (Lookup) | Required. |
+| Effective Date From | Start date of the effective period. | Date | Required. |
+| Effective End Date | End date of the effective period. | Date | Required. |
+| Use Type | Use Message or Upload Template. | Enum | Required. |
+| Sender Name | Name of sender. | String (100) | Required. |
+| From Email | Configured email address. | String (100) | Required. |
+| Subject | Subject of email. | String (100) | Required. |
+| Preview Text | Preheader of Email. | String (100) | Optional. Defaults to first line of content if not provided. |
+| Message / Upload File | HTML content or uploaded template file. | String / File | Required based on Use Type. |
+
+### Data Schema (Push Notification)
+
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| Message ID | Unique identifier. | String (10) | Required. No special characters. |
+| Message Description | Description. | String (100) | Required. |
+| Notification Type | Promotion/Marketing or Transaction. | String (Lookup) | Required. |
+| Effective Date From | Start date of the effective period. | Date | Required. |
+| Effective End Date | End date of the effective period. | Date | Required. |
+| Message Title | Primary text at the top. | String (50) | Required. |
+| Message | Main content. Supports drag/drop parameters. | String | Required. |
+| Image Type | Single (No image), Richer (1 image), Carousel (>1 images). | Enum | Required. |
+| Upload Image | Images for Richer or Carousel push. | Image / URL | Required if Image Type is not Single. |
+| Link URL | URL to navigate to. | String (100) | Required. |
+
+### Testing Message
+- A "Send sample" function exists for all channel types to test the message rendering using a sample phone number, email, or CIF number.
+
+## Post-Conditions
+- All configured messages are available for use in Marketing Request, Campaign Rule, and Item Master.

docs/specs/onemarketing/whitelist.md

@@ -0,0 +1,36 @@
+---
+title: "Whitelist"
+type: OpenSpec
+status: Draft
+domain: OneMarketing
+---
+
+# Whitelist
+
+## Requirement Definition
+A list of customers who have given consent or shown strong interest and are excluded from standard frequency cap rules, ensuring they receive all communications without limit.
+
+## Process Flow
+
+### Pre-Conditions
+- Users must have access rights in the "Whitelist" module.
+
+## Business Rules
+
+### Data Schema
+
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| ID | Whitelist identifier. | String (10) | Required. |
+| Name List | Name of the whitelist. | String (50) | Required. |
+| Description | Description. | String (200) | Optional. |
+| Input Type | Input from screen or Upload file. | Enum | Required. |
+| Customer List | List of selected CIF numbers. | Array of Strings (Lookup) | Required if Input Type is "Input from screen". Requires >= 4 digits to search. |
+| Upload File | Uploaded CSV/XLS file. | File | Required if Input Type is "Upload file". Max 50MB. |
+
+### Execution
+- Users can review or download the customer list.
+- Whitelisted customers bypass frequency capping restrictions by default, unless a specific frequency cap explicitly opts to "Include Whitelist".
+
+## Exception Flow
+- Validation errors for file type/size during upload display an error message.

docs/specs/onetargeting/audience_upload.md

@@ -0,0 +1,32 @@
+---
+title: "Audience Upload"
+type: OpenSpec
+status: Draft
+domain: OneTargeting
+---
+
+# Audience Upload
+
+## Requirement Definition
+Provides a module for marketers to manage audience uploads, enabling them to upload customer data for targeted marketing campaigns via file uploads.
+
+## Process Flow
+
+### Pre-Conditions
+- Users must have access rights in the "Audience Upload" module.
+- Depending on access rights, users can view, add, edit, or manually approve.
+
+## Business Rules
+- Users can upload customer data for targeted marketing campaigns via file upload (CSV, Excel spreadsheets).
+- The system allows users to map data from source files to required platform fields.
+- The system validates the uploaded data to ensure all required fields are present and in the correct format.
+
+### Data Schema
+
+| Field Name | Description | Data Type | Constraints / Rules |
+|---|---|---|---|
+| Audience Name | The name of the audience | String (50) | Required. Must be unique in the system. |
+| Description | Audience description | String (200) | Optional. |
+| File ID | Audience identifier | String (10) | Required. Internal system reference. |
+| File Size | The file size of the upload | Numeric | System generated. |
+| Upload File | The uploaded file data | File/Binary | Required. Allowed extensions: CSV, XLS, XLSX. Max size: <= 50 MB. |

docs/specs/onetargeting/customer_audience.md

@@ -0,0 +1,14 @@
+---
+title: "Customer Audience"
+type: OpenSpec
+status: Draft
+domain: OneTargeting
+---
+
+# Customer Audience
+
+## Requirement Definition
+No requirements defined yet.
+
+## Business Rules
+No business rules defined yet.

docs/specs/onetargeting/segmentation.md

@@ -0,0 +1,64 @@
+---
+title: "Segmentation"
+type: OpenSpec
+status: Draft
+domain: OneTargeting
+---
+
+# Segmentation
+
+## Requirement Definition
+Segmentation is a process to divide a customer base into smaller groups, providing a way to narrow down the target audience based on the types of products or services the customers have previously purchased. This allows businesses to create more personalized and effective marketing strategies for each segment, rather than adopting a one-size-fits-all approach.
+In the system, a segment is a combination of one or more criteria. The same criteria set may be reused multiple times, allowing an efficient way to set up targeted customers.
+
+## Process Flow
+
+### Trigger
+- User accesses the OneTargeting Module to create or update a new segment.
+
+### Pre-Conditions
+- Users must have access rights in the Segmentation module.
+- Depending on access rights, users can view, add, edit, or manually approve.
+- All criteria are defined as attributes and are available for setup.
+
+## Business Rules
+- The OLS system uses Query Builder to build queries for segmentation.
+- Business segments target customers using the following criteria combinations:
+
+### Criteria Matrix
+
+| Segment Group | Criteria Group | Combination by Following Criteria | Segment Example |
+|---|---|---|---|
+| Demographic Segmentation | Customer Profile | Age | Life Cycle segment: Children (0-14), Youth (15-24), Adults (24-64), Seniors (65+) |
+| Demographic Segmentation | Customer Profile | Last Name |  |
+| Demographic Segmentation | Customer Profile | First Name |  |
+| Demographic Segmentation | Customer Profile | Income | Income segment: High-Income, Middle-Income, Low-Income |
+| Demographic Segmentation | Customer Profile | Gender | Male, Female |
+| Demographic Segmentation | Customer Profile | Marital Status | Single, Married |
+| Demographic Segmentation | Customer Profile | DOB | Generation segment: Gen Z (1997-2012), Gen Y (1981-1996), Gen X (1965-1980), Gen W (1946-1964) |
+| Demographic Segmentation | Customer Profile | Location (Country/State/City/Zip Code) | Geography segment: International, Urban, Suburban, Mountain |
+| Demographic Segmentation | Customer Profile | Customer's Tenure | Customer Tenure Segment (based on Registration): New (<1 yr), Early-tenured (1-2 yrs), Mid-Tenured (2-5 yrs), Long-tenured (>5 yrs) |
+| Demographic Segmentation | Customer Profile | Account's Tenure | Account Tenure Segment (based on AOD): New (<1 yr), Early-tenured (1-2 yrs), Mid-Tenured (2-5 yrs), Long-tenured (>5 yrs) |
+| Demographic Segmentation | Customer Profile | Account's Status |  |
+| Demographic Segmentation | Customer Profile | Next AOD |  |
+| Demographic Segmentation | Customer Profile | Customer's status |  |
+| Behavior Segmentation | Transaction | Last transaction / Integration | Churned customer: Last transaction > 6 months ago and status is active |
+| Behavior Segmentation | Transaction | Transaction Frequency | Total number of transactions or Average transaction frequency in a specific period (day/week/month/quarter/year). Segment: High-Value, Medium-Value, Low-Value |
+| Behavior Segmentation | Transaction | Customer Recency | When was the last transaction/integration |
+| Behavior Segmentation | Transaction | Total spending value | Total net transaction amount |
+| Behavior Segmentation | Transaction | Transaction Date | Peak-Time customer (special day, weekend, midnight). Consistent-Time Customers (first day of month). Flexible-Time Customers (specific day) |
+| Behavior Segmentation | Transaction | Transaction Time |  |
+| Behavior Segmentation | Transaction | Merchant (Corporation/Chain/Store/MCC) | Used with another criteria or alone to create specific segments |
+| Behavior Segmentation | Transaction | Merchant Group |  |
+| Behavior Segmentation | Transaction | Transaction Description |  |
+| Behavior Segmentation | Transaction | Transaction Category |  |
+| Behavior Segmentation | Transaction | Transaction Gross Amount |  |
+| Behavior Segmentation | Transaction | Transaction Nett Amount |  |
+| Flexible Segment | Attribute | Attribute Criteria |  |
+| Psychographic Segmentation | Item | Favorite Category | Life Style segment, Interest segment, Opinion segment |
+| Psychographic Segmentation | Item | Favorite Item |  |
+
+Note: Psychographic segmentation data will be collected from surveys upon OneDisplay implementation.
+
+## Post-Conditions
+- Each segment is used to define the targeting customer in the marketing module.

docs/specs/reference/change_history.md

@@ -0,0 +1,46 @@
+---
+title: "Change History"
+type: OpenSpec
+status: Draft
+domain: Reference
+---
+
+# Change History
+
+| Version | Date | Updated By | Change Description |
+|---|---|---|---|
+| 1.0 | 14/12/2023 | Trangdth, Maivt | The first version including: Customer Management, Campaign Management, Draft OMR module |
+| 1.1 | 18/12/2023 | Trangdth | Customer 360: Add more detail for Account/Card information.<br>Section 5.1: Add filter, Add/update some fields in the screen.<br>Section 5.5 Card: Update description and logical.<br>Section 5.9 and 5.10: Update label |
+| 1.2 | 20/12/2023 | Trangdth | Update the Pool Conversion Rate module.<br>Update data type DD/MM/YYYY into "Date" to respect the date time configuration format.<br>Update the Card logically: Add more detail when updating the card.<br>Update customer Management module section 5: an update based on Sang's requirement (Customer/Account/dashboard/transaction history/attribute/counter).<br>Update Vietnamese fields and some cosmetic issues |
+| 1.3 | 27/12/2023 | Trangdth | Update customer block data type from X(20) into X(10).<br>Section 5.4 update the card activation date from mandatory to optional.<br>Section 5.2.6: Update the logic of most items.<br>Section 4.7- Pool Conversion Rate: update field name and logic for pool conversion rate.<br>Section 4.12 Campaign Rule Criteria: Correction some typos and add more detail for txncat criteria.<br>Pool Definition: remove the item code field (move to Rule setup). Add some validations(red line).<br>Add CEP rule type |
+| 1.4 | 02/01/2024 | Trangdth | Add REP Rule.<br>Update Pool Definition Screen: screen and logical.<br>Update Counter Defintion to match with PMS and add more detail. |
+| 1.5 | 10/01/2024 | Trangdth | Update API information for REP rule.<br>Update API information for CEP Rule.<br>Add document for Formula (UI+ Logical) |
+| 1.6 | 16/01/2024 | Trangdth | Add Section 5.15 Awward Transaction Entry Screen.<br>Update Section 4.8 Counter Definition: Add Late txn posting option. Update logical on post-condition.<br>Update Pool Defintion: add more detail for ATG field.<br>CEP/REP: Update API for run schedule |
+| 1.7 | 24/01/2024 | Trangdth | Counter definition: Update: Active "First start date is fixed" for "Days from COD" period unit.<br>Pool conversion rate: Update code from X(03) into X(05).<br>Card - Update data type and logic for Old Card number. Update the relationship of Account type and Account number.<br>Add Campaign : Add description for CP module |
+| 1.8 | 25/01/2024 | Trangdth | Add section 4.12 Campaign Rule logical for Award/redem/Adjust rule type.<br>Add section 4.9 Transaction Category module |
+| 1.9 | 30/01/2024 | Trangdth | Campaign: change data type and add alidation for Campaign type.<br>CEP: Update data type for Run schedule and change the sequence order in Layout.<br>REP: Update data type for Run schedule and change the sequence order in Layout |
+| 1.10 | 19/02/2024 | Trangdth | Section 4.17 : CEP : Update API information of following fields: - Account with blocked Card - Post Transactions under PA Account selected based on |
+| 1.11 | 21/02/2024 | Trangdth | Section 4.12.6 : Campaign Rule/Business Rule : Update validation of "Apply after Cap value " field |
+| 1.12 | 05/03/2024 | Trangdth | Correction typo.<br>Section 4.13: Rule criteria: Update more detail and req.<br>Section 5.11 Adjustment : Add field and update logical of quick view |
+| 1.13 | 07/03/2024 | Trangdth | Correction typo.<br>Section 5.11 Adjustment: Update Vietnamese label and correction logical.<br>Section 5.12 Transfer Balance: Add fields, Update logical, Add User Stories and Accepted Criterions.<br>Section 5.13 Re-instatement : Add fields, Update logical , Add User Stories and Accepted Criterions |
+| 1.14 | 11/03/2024 | Trangdth | 5.2.6.3: Account/Card information: Update logical and data entities.<br>5.11 Adjust: Add US and AC.<br>5.12 Award Transaction: Add fields, Update logical , Add User Stories and Accepted Criterions.<br>5.5 Pool Balance Detail: Correction and Add User Stories and Accepted Criterions |
+| 1.15 | 12/03/2024 | Trangdth | Section 4.15 contributor setting: Update data type of "Contributor Percentage" field.<br>Section 4.14 Campaign Rule formula: Remove validation of F5/Multiplier |
+| 1.16 | 20/03/2024 | Trangdth | Section 7: Added OneCatelogue module, including: Item master/ Catalogue/Category/Voucher management.<br>Section 4.12 Campaign Rule: Added Post-condition for Amount to Use feature (Transaction Processing with Amount to use).<br>Secttion 4.6 Pool Definition: Remove CP Rule name and change data for "List Of Campaign" listing page. |
+| 1.17 | 25/03/2024 | Trangdth | Add section 7.5: Item Price.<br>Update section 5.14 Item redemption to match onecatalogue logical.<br>Update quick view of Adjust/transfer balance/Re-instatement/Award. Take note that I just remove redundant information and update the description to be more clearly. The logical is not changed. |
+| 1.18 | 03/04/2024 | Trangdth | Added section 2 (2.1/ 2.2/2.3/2.4) OneAccess module, including Overview, User Group, Permission Management and User Profile.<br>4.6 Pool Definition: Correction typo.<br>4.13 Rule Criteria: Correct index of operator on each data type.<br>4.14 Campaign Formula : Update Formula logical on TP sides |
+| 1.19 | 12/04/2024 | Trangdth | Correction typo.<br>Section 4.13 Rule Criteria: Update logical of String data type (TP sides only) |
+| 1.20 | 15/04/2024 | Trangdth | Section 5.6 Transaction History: Update sketch, Update US and AC, update Business rule.<br>Section 5.11 Adjustment: Update sketch. Update US and AC, update business rule.<br>Section 5.15 Award : Update US and AC |
+| 1.21 | 16/04/2024 | Trangdth | Section 4.18 Added Item Redemption Rule Type |
+| 1.22 | 19/04/2024 | Trangdth | Section 7: OneCatalogue: Typ0 correction and update section 7.6 Voucher Code module.<br>Section 4.12.7 CP rule : Add Award limit use case in FSD |
+| 1.23 | 26/04/2024 | Trangdth | Section 5.6 Transaction History: Added "Pool Unit Amount" on Award quick view.<br>Section 5.15 Item Redemption: update business req/ Flow and post condition.<br>Section 7.5 Item Price Update flow/ post condition / add effective date |
+| 1.24 | 02/05/2024 | Trangdth | Section 4.6 Pool Definition : Add validation for Card entity level field.<br>Section 4.13 Campaign Rule Criteria : Correction description of filter value of Number data type.<br>Section 5.14 Item Redemption : Correction Wireframe and update business rule.<br>Section 7.3 Item master: Add Face value and correction typo |
+| 1.25 | 06/05/2024 | Trangdth | Addded description to clear "Balance detail" quick view of Award and Adjustment Transaction Screen.<br>Section 5.14 Item redemption : Added User Stories and Acceptance criteria |
+| 1.26 | 09/05/2024 | Trangdth | Section 4.13 Campaign Rule Criteria: Update String data type: Use Input tag instead of delimiter in case there are many filter value if input type as "value" |
+| 1.27 | 20/05/2024 | Trangdth | Section 4.13 Campaign Rule Criteria: Add more description for Date Data type.<br>Section 4.12 Campaign Rule: Add new fields/validation to handle Evoucher Pool and Adjust Rule Type. |
+| 1.28 | 24/05/2024 | Trangdth | Section 4.6: Pool Definition: Add validation for Precision of Pool.<br>Section 7.6: Voucher code: Change field name from Voucher type into Promotion Type.<br>Section OneAdmin Overview: Update and correction section 3.1/3.2/3.3.<br>Section 7.5 Item price: Add item code to avoid confuse.<br>Customer Profile: Add "Address Type: field.<br>Section 5.6 Item redemption Entry: Remove redudant field and add validation |
+| 1.29 | 30/05/2024 | Trangdth | Counter Definition: Add validation for "Bucket period Unit".<br>Campaign rule: Remove API of master data filed Remove Voucher code Add item code |
+| 1.30 | 17/06/2024 | Trangdth | Section 5.9/5.10: Attribute/Counter: Correction and update more detail.<br>Section 5.6: Transaction History: Remove Deleted field, correction typo and update detail for quick view.<br>Section 5.11/5.12: Adjustment /Transfer balance: Correction process flow and business.<br>Section 5.15: Award transaction: Update process flow on TP side.<br>Other section: Update and correct to match with the system |
+| 1.31 | 19/06/2024 | Trangdth | All sections: Add more description for number field if needed |
+| 1.32 | 24/06/2024 | Trangdth | Campaign formula /Business rule : Update validation for "Amount " field (F4/F6).<br>Section 5.2.6.2: Customer's rewards statistic : Remove total spending, Update logical for Points/Cash back |
+| 1.33 | 12/07/2024 | Trangdth | Add section 3: Oneadmin: Overview about the OLS system : Search/Filter/Add/View/Edit/Approve/History.<br>Add Section 4: Application Parameter.<br>Update section 6.2.6: Customer 360=>Business Rule: Correct typo. Add more detail for pool balance information and most redeemed item |
+| 1.34 | 11/11/2024 | Trangdth | Correction typos |

docs/specs/reference/document_references.md

@@ -0,0 +1,15 @@
+---
+title: "Document References"
+type: OpenSpec
+status: Draft
+domain: Reference
+---
+
+# Document References
+
+| Ref# | Description / File Name |
+|---|---|
+| R01 | |
+| R02 | |
+| R03 | |
+| R04 | |

docs/specs/reward_campaign/account_type_group.md

@@ -0,0 +1,42 @@
+---
+title: "Account Type Group"
+type: OpenSpec
+status: Draft
+domain: Reward Campaign Management
+---
+
+# Account Type Group (ATG)
+
+## Requirement Definition
+Groups Account Types (Product Account Level + Type) and orders them in priority sequence. ATGs are assigned to Reward Pools to restrict which accounts can earn into the pool, and to define the priority sequence for deducting points during redemptions at Customer-level pools.
+
+## Process Flow
+
+### Pre-Conditions
+- Users must have access rights.
+- Account Types must exist in OLS.
+
+## Business Rules
+
+### Data Schema
+
+#### General Information
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| Account Type Group Id | Identifier. | String (10) | Required. Unique. |
+| Description | Description. | String (100) | Required. |
+
+#### Account Type Sequence
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| Product Account Level | PAL. | Enum (Lookup) | Required. |
+| Product Account Type | PAT. | Enum (Lookup) | Required. |
+| Sequence No | Priority sequence (lowest is highest priority). | Integer | Required. |
+
+### Execution
+- **Redemption Priority**: When redeeming from a Customer pool, buckets with the same expiry date are deducted in ascending order of the Account Type's Sequence No in the pool's ATG. Account types NOT in the ATG have highest priority.
+- **Posting Priority**: If a transaction arrives with only a CIF Number (no Account Number), the system uses the ATG to find eligible accounts for that CIF. If multiple exist, the one with the lowest Sequence No in the ATG is selected for the transaction.
+- **Validation**: Incoming transactions must map to an Account Type that is within the Pool's ATG. If the intersection of Customer's Accounts and the Pool's ATG is null, the transaction is rejected.
+
+## Exception Flow
+- TP validation failures reject the transaction.

docs/specs/reward_campaign/campaign_insight.md

@@ -0,0 +1,38 @@
+---
+title: "Campaign Insight"
+type: OpenSpec
+status: Draft
+domain: Reward Campaign Management
+---
+
+# Campaign Insight
+
+## Requirement Definition
+Combines data from across multiple data sources into charts to track and display customer and campaign activities, providing a high-level performance overview.
+
+## Process Flow
+
+### Pre-Conditions
+- Users must have access rights to the Campaign Insight module.
+
+## Business Rules
+
+### Data Schema
+
+#### Key Metrics Displayed
+- Total Redeemed Points.
+- Total Members (Active vs Inactive).
+- Total Partners.
+- Total Active Reward Campaigns.
+
+#### Charts & Visualizations
+- **Campaign Performance**: Displays the Top N Campaigns by awarded points, comparing "Target Avg Transaction Value" vs actual awards.
+- **Top Channels**: Breakdown of transactions by entry channel (e.g., EDC, Web, Call Center).
+- **Points Awarded vs Redeemed**: Time-series comparison of point inflows vs outflows over a period.
+
+### Execution
+- **View-only dashboard.**
+- Real-time or near-real-time aggregation depending on batch job configuration for analytics.
+
+## Exception Flow
+- N/A

docs/specs/reward_campaign/campaign_rule_contributor.md

@@ -0,0 +1,35 @@
+---
+title: "Campaign Rule - Contributor Settings"
+type: OpenSpec
+status: Draft
+domain: Reward Campaign Management
+---
+
+# Campaign Rule - Contributor Settings
+
+## Requirement Definition
+Configures funding contributors for a reward. If a reward is funded by entities other than the transacting merchant (or split between them), Contributors define the split percentage.
+
+## Process Flow
+
+### Pre-Conditions
+- Rule must be created.
+- Contributing merchants (Chains) must exist in OLS.
+
+## Business Rules
+
+### Data Schema
+
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| Contributor | The Chain funding the reward. | Enum (Lookup) | Required. Unique per rule. |
+| Contributor Percentage | Percentage of cost to fund. | Decimal | Required. > 0. |
+| Absorb Remainder | Absorbs rounding remainders. | Boolean | Required. Exactly one must be true. |
+
+### Execution
+- Total contribution must equal 100%.
+- Transaction processing splits the awarded value across Contributors based on percentages.
+- If no contributors are configured, the transacting Merchant (Chain) absorbs 100% of the cost.
+
+## Exception Flow
+- Validation failures block saving.

docs/specs/reward_campaign/campaign_rule_criteria.md

@@ -0,0 +1,40 @@
+---
+title: "Campaign Rule Criteria"
+type: OpenSpec
+status: Draft
+domain: Reward Campaign Management
+---
+
+# Campaign Rule Criteria
+
+## Requirement Definition
+Defines the conditions a transaction must meet to trigger a Campaign Rule. Built using a drag-and-drop Query Builder interface.
+
+## Process Flow
+
+### Pre-Conditions
+- Rule must be created.
+
+## Business Rules
+
+### Data Schema
+Criteria are categorized into: Customer, Account, Transaction, Attribute, Counter, Merchant.
+
+#### Operators
+| Data Type | Operators | Logic Type / Details |
+|---|---|---|
+| String / Lookup | Is in, Is not in, Contains, Equal to, Not equal to, Starts with, Ends with, Is null, Is not null. | Validates against provided text or list of values. |
+| Number | Equal, Not equal, Less than, Less/equal, Greater, Greater/equal, Between, Null, Not null. | Standard numerical comparison. |
+| Date | On or before, On or after, Fixed date, Between date range, Between period from N. | Complex date logic (e.g. comparing Day/Month regardless of year, comparing "3 months ago"). |
+| Day of week | Is the day of week. | Monday-Sunday. |
+| Time | Is between. | Time-of-day comparison (00:00 - 23:59). |
+| Boolean | Is. | True / False. |
+
+### Execution
+- Supports AND and OR logic grouping.
+- A single rule can have multiple groups, but inter-group logic must be consistent (all ANDs or all ORs).
+- NOT toggles support exclusion.
+- All criteria defined in the rule must evaluate to true (for AND) or at least one (for OR) to trigger the Formula execution.
+
+## Exception Flow
+- Validation failure means the rule is not triggered (proceeds to next rule in Execution Sequence).

docs/specs/reward_campaign/campaign_rule_formula.md

@@ -0,0 +1,27 @@
+---
+title: "Campaign Rule Formula"
+type: OpenSpec
+status: Draft
+domain: Reward Campaign Management
+---
+
+# Campaign Rule Formula
+
+## Requirement Definition
+Configures the mathematical formula used to calculate the reward, redemption value, or counter increment for a given Rule.
+
+## Process Flow
+
+### Pre-Conditions
+- Rule must be created.
+
+## Business Rules
+
+### Execution
+- Formulas act on the "Amount to Use (A)" defined in the Rule Header.
+- Support mathematical operations (e.g., A * 0.05, A + 10).
+- Formulas can be assigned to different tiers based on criteria.
+- Formulas can be used to update Pool Balances, or simply update a Counter / Attribute without impacting a Pool.
+
+## Exception Flow
+- N/A

docs/specs/reward_campaign/campaign_structure.md

@@ -0,0 +1,40 @@
+---
+title: "Campaign Structure"
+type: OpenSpec
+status: Draft
+domain: Reward Campaign Management
+---
+
+# Campaign Structure
+
+## Requirement Definition
+Defines the conceptual structure and mechanics of how reward campaigns operate in OLS, managing the issuance and redemption of various reward types (Points, Cash Rebates, eCoupons, Lucky Draw chances).
+
+## Process Flow
+
+### Pre-Conditions
+- N/A (Core concepts)
+
+## Business Rules
+
+### Types of Campaign Mechanics
+1. **Award on Every Transaction**: Rewards are determined and given at the time the transaction is processed (real-time or batch).
+2. **Accumulate Then Award**: Rewards depend on cumulative criteria (e.g., total spend over a month). Transactions update Counters, and at the end of the period, a separate process extracts the Counter value to determine the award.
+3. **Auto-redemption Campaigns**: Awarded quantities (e.g., Cash Rebates) are immediately "redeemed" and sent to an external system (like a Core Banking system) to credit the customer's account.
+
+### Reward Pool Structure & Deduction
+- Earnings are tracked in "Pools" by reward type.
+- Pools belong to Loyalty Accounts (or specific Accounts/Cards).
+- Stored value is tracked in Buckets segregated by Expiry Date and Account Type.
+- **Redemption Sequence**: 
+  - Deducted in ascending Expiry Date (earliest expiring first).
+  - If identical expiry dates, sorted by a pre-configured Account Type priority sequence.
+
+### Counters
+- A Counter tracks a quantity (e.g., spend amount, transaction frequency) over a defined time period (Bucket).
+- Entities tracked: Customer, Account, Card, Store, Chain, etc.
+- Quantities tracked: Gross Amount, Nett Amount, Points, Transaction Count, Custom Quantities.
+- Counter Periods: Days, Weeks, Months, Quarters, Years, Fixed Date, No Expiry, Days/Months/Quarters from Account Open Date.
+
+## Exception Flow
+- N/A

docs/specs/reward_campaign/cep_rule.md

@@ -0,0 +1,41 @@
+---
+title: "Counter Extract & Process (CEP) Rule"
+type: OpenSpec
+status: Draft
+domain: Reward Campaign Management
+---
+
+# Counter Extract & Process (CEP) Rule
+
+## Requirement Definition
+Extracts values accumulated in a Counter at the end of a defined period and generates a transaction to trigger an Award/Redeem rule based on that accumulated total.
+
+## Process Flow
+
+### Pre-Conditions
+- Users must have access rights.
+- A Counter tracking the required metric must exist.
+
+## Business Rules
+
+### Data Schema
+
+#### General & Extraction Settings
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| Rule Type | CEP. | Enum | Required. |
+| Counter to Extract | Counter containing the value. | Enum (Lookup) | Required. |
+| Bucket to Extract | Current, Previous, Period Before Last. | Enum | Required. |
+| Rule type to process | Rule type of the destination rule. | Enum (Lookup) | Required. |
+| Transaction Code | TC used to post the extracted transaction. | Enum (Lookup) | Required. |
+| -ve Bal. Adjust. TC | TC for negative extracted values. | Enum (Lookup) | Optional. |
+| Account with blocked Card | Include or Exclude blocked cards. | Boolean | Conditional (if Acct/Card entity). |
+| Run schedule | Day, Month, Annual, N days AOD, Stmt Cycle. | Enum (Lookup) | Required. Defines execution frequency. |
+
+### Execution
+- Evaluated by the CEP Batch scheduled at end-of-day.
+- The extracted Counter Bucket value becomes the `Amount A` for the destination Rule.
+- State of Counter Buckets is updated based on Counter Definition (e.g., closed after extraction) to prevent double-processing.
+
+## Exception Flow
+- N/A

docs/specs/reward_campaign/counter_definition.md

@@ -0,0 +1,45 @@
+---
+title: "Counter Definition"
+type: OpenSpec
+status: Draft
+domain: Reward Campaign Management
+---
+
+# Counter Definition
+
+## Requirement Definition
+Defines conceptual entities that track quantities (spend amount, transactions, points) over defined periods of time.
+
+## Process Flow
+
+### Pre-Conditions
+- Users must have access rights.
+
+## Business Rules
+
+### Data Schema
+
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| Counter Id | Unique identifier. | String (10) | Required. |
+| Counter Name | Descriptive name. | String (50) | Required. |
+| Effective From Date | Start date of counter effectiveness. | Date | Required. |
+| Effective To Date | End date of counter effectiveness. | Date | Required. |
+| Entity | Level of tracking (Cust, Acct, Card, Store, etc).| Enum (Lookup) | Required. |
+| Bucket Period Unit | Time period for buckets (Day, Month, etc). | Enum (Lookup) | Required. |
+| Bucket End Date | Used if Unit is Fixed Date. | Date | Conditional. |
+| Bucket Period Duration(N)| Length of the period unit. | Integer | Conditional. |
+| What to count | Entity to track (Gross Amt, Txns, Points, etc). | Enum (Lookup) | Required. |
+| Reset type | Reset to 0, or keep remainder. | Enum (Lookup) | Required. |
+| Reset Value | Threshold at which counter resets and new bucket starts. | Decimal | Required. Default 999999999. |
+| First Start Date Is Fixed| Boolean flag. | Boolean | Conditional. |
+| First Start Date | Starting date for the first bucket. | Date | Conditional. |
+| Update State When | When to close bucket (On extract, On award). | Enum (Lookup) | Required. |
+| Late Posting Option | Update late value vs Current bucket. | Enum | Required. |
+
+### Execution
+- If counter ID has existing values in `counter_stock`, definition cannot be changed (except Name/Desc/End Date).
+- Late Posting determines how transactions with backdated post dates update counters (update the "Late Counter Value" or force update into the currently active time bucket).
+
+## Exception Flow
+- N/A

docs/specs/reward_campaign/external_transaction_code.md

@@ -0,0 +1,33 @@
+---
+title: "External Transaction Code"
+type: OpenSpec
+status: Draft
+domain: Reward Campaign Management
+---
+
+# External Transaction Code
+
+## Requirement Definition
+Maps incoming transaction codes from external systems (e.g., Card System) to OLS Transaction Codes.
+
+## Process Flow
+
+### Pre-Conditions
+- Users must have access rights in the module.
+
+## Business Rules
+
+### Data Schema
+
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| External Transaction Code | Source System Transaction Code. | String (10) | Required. |
+| Description | Description for reference. | String (30) | Required. |
+
+### Execution
+- An External System TC is the first key used to locate the corresponding OLS TC for processing.
+- Each External TC must be mapped to an OLS TC.
+- Supports Maker-Checker approval workflow (Pending -> Active).
+
+## Exception Flow
+- N/A

docs/specs/reward_campaign/item_redemption_rule.md

@@ -0,0 +1,36 @@
+---
+title: "Item Redemption Rule"
+type: OpenSpec
+status: Draft
+domain: Reward Campaign Management
+---
+
+# Item Redemption Rule
+
+## Requirement Definition
+Evaluates item redemption transactions (e.g. redeeming an eVoucher or physical item from a catalog).
+
+## Process Flow
+
+### Pre-Conditions
+- Users must have access rights.
+
+## Business Rules
+
+### Data Schema
+
+#### General Information
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| Rule Type | Item Redemption (ITRD). | Enum | Required. |
+| Message Template ID | SMS/Email template if rule hit. | Enum (Lookup) | Optional. |
+| Transaction Code | TC used to post the redemption. | Enum (Lookup) | Required. |
+
+### Execution
+- Same criteria evaluation approach as Award rules.
+- There is NO reward pool, formula, or contributor attached to this rule type.
+- The redemption pool to deduct from is configured separately in the Item Price configuration.
+- To post an item redemption, the transaction must pass the validation criteria of the Item Redemption Rule linked to the redemption TC.
+
+## Exception Flow
+- Criteria failure blocks the item redemption transaction.

docs/specs/reward_campaign/ols_transaction_code.md

@@ -0,0 +1,34 @@
+---
+title: "OLS Transaction Code"
+type: OpenSpec
+status: Draft
+domain: Reward Campaign Management
+---
+
+# OLS Transaction Code
+
+## Requirement Definition
+Every transaction processed against Campaign Rules must have an OLS Transaction Code (TC). It acts as the primary key to locate relevant Campaign Rules.
+
+## Process Flow
+
+### Pre-Conditions
+- Users must have access rights in the module.
+
+## Business Rules
+
+### Data Schema
+
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| OLS Transaction Code | The internal transaction code. | String (10) | Required. |
+| Description | Description of the code. | String (30) | Required. |
+| External Transaction Code | The mapped external TCs. | List of Strings | Optional. Many External TCs can map to one OLS TC. |
+| Reversal Indicator | Indicates if this is a reversal. | Boolean | Default False. |
+
+### Execution
+- Supports internal transactions (e.g., CEP Batch generated) that do not have an External TC.
+- Supports Maker-Checker approval workflow (Pending -> Active).
+
+## Exception Flow
+- N/A

docs/specs/reward_campaign/pool_definition.md

@@ -0,0 +1,68 @@
+---
+title: "Pool Definition"
+type: OpenSpec
+status: Draft
+domain: Reward Campaign Management
+---
+
+# Pool Definition
+
+## Requirement Definition
+Defines Reward Pools which track stored values (Points, Cash Rebates, Lucky Draw chances, eVouchers). Pools dictate expiry policies, entity tracking levels (Customer, Account, Card), and velocity controls.
+
+## Process Flow
+
+### Pre-Conditions
+- Users must have access rights.
+- Pool Conversion Rate must be active.
+- Account Type Groups (if applicable) must be active.
+
+## Business Rules
+
+### Data Schema
+
+#### General Information
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| Pool Id | System-generated identifier. | String (10) | Required. |
+| Pool Name | Name of the pool. | String (30) | Required. |
+| Pool Type | Points, Cash Rebate, Lucky Draw, eVoucher. | Enum | Required. |
+| Expiry Policy | Method to calculate expiry date. | Enum (Lookup) | Required (except eVoucher). |
+| Policy Parameter N | Numeric parameter for Expiry Policy. | Integer | Conditional based on policy. |
+| Expiry Date | Fixed expiry date. | Date | Conditional (if policy is Fixed Date). |
+| Ripening Period | Days before reward is redeemable. | Integer | Conditional. Default 0. |
+| Conversion Rate Code | Currency representing a unit of reward. | Enum (Lookup) | Conditional. |
+| Allow Negative Balance | Allow pool to go negative on adjust/cancel. | Boolean | Conditional. Default False. |
+| Precision | Number of decimal places. | Enum (Lookup) | Conditional. Default 2. |
+| Account Type Group | Restricts earning to specific accounts. | Enum (Lookup) | Optional. |
+| Grace Period | Months to keep expired buckets before forfeit. | Integer | Optional. |
+| Entity Level | Tracks balance at Customer, Account, Card. | Enum | Required. |
+
+#### Product Specific Policy
+Overrides general expiry policy for specific Account Types.
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| Product Account Level | PAL. | Enum (Lookup) | Required. |
+| Product Account Type | PAT. | Enum (Lookup) | Required. Unique per row. |
+| Expiry Policy | Specific expiry policy. | Enum (Lookup) | Required. |
+
+#### Velocity Control
+Defines thresholds for sending alerts (Exception Alert Reports).
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| Maximum | Threshold limit. | Decimal | Required. |
+| Transaction Type | Award, Redeem, Adjust. | Enum | Required. |
+| Units | Per Pool Units or Per Transaction. | Enum | Required. |
+| Per Entity 1 | Customer, Account, Card. | Enum | Optional (System-wide if null). |
+| Per Entity 2 | Corporation, Chain, Store, Terminal. | Enum | Optional. |
+| Per Period | Quarter, Month, Week, Day. | Enum | Required. |
+| Alert Template | Message template for alert. | Enum | Required. |
+| Alert Group | Recipient group (SMS/Email). | Enum | Required. |
+
+### Execution
+- Precision cannot be reduced after transactions are posted.
+- Entity Level cannot be moved downwards (e.g., Customer to Card) after transactions are posted.
+- Evoucher pools have No Expiry, no Precision, and no Negative Balances.
+
+## Exception Flow
+- N/A

docs/specs/reward_campaign/rep_rule.md

@@ -0,0 +1,39 @@
+---
+title: "Redemption Extract & Process (REP) Rule"
+type: OpenSpec
+status: Draft
+domain: Reward Campaign Management
+---
+
+# Redemption Extract & Process (REP) Rule
+
+## Requirement Definition
+Extracts reward pool balances to automatically output them as Cash Rebates or Partner Points to an external destination system (like a Core Banking system or Airline Partner).
+
+## Process Flow
+
+### Pre-Conditions
+- Users must have access rights.
+
+## Business Rules
+
+### Data Schema
+
+#### Extraction Settings
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| Rule Type | REP. | Enum | Required. |
+| Pool to Extract | Pool containing the balance. | Enum (Lookup) | Required. |
+| Minimum Pool Balance | Threshold before extraction. | Decimal | Optional. |
+| Trigger Campaign rule | Validates criteria before extraction. | Boolean | Default False. |
+| Redeem TC | TC used to post the redemption. | Enum (Lookup) | Required. |
+| Output Redemption As | Format/System of output (e.g. Cash Rebate file).| Enum (Lookup) | Required. |
+| Run schedule | Day, Month, Annual, Stmt Cycle, N days AOD. | Enum (Lookup) | Required. Defines execution frequency. |
+
+### Execution
+- Evaluated by the REP Batch scheduled at end-of-day.
+- The full eligible amount of the Pool balance is deducted and output to a file (e.g., `OLSCRTXN`).
+- If `Trigger Campaign rule` is true, an intermediate Redeem rule evaluates criteria, and the extracted amount is the minimum of (Available Balance, Formula Result).
+
+## Exception Flow
+- N/A

docs/specs/reward_campaign/reward_campaign.md

@@ -0,0 +1,37 @@
+---
+title: "Reward Campaign"
+type: OpenSpec
+status: Draft
+domain: Reward Campaign Management
+---
+
+# Reward Campaign
+
+## Requirement Definition
+Acts as the parent container for Business Rules (Campaign Rules) controlling rewards and redemptions. Campaigns can be "Base" (core product) or "Tactical" (short-term objectives).
+
+## Process Flow
+
+### Pre-Conditions
+- Users must have access rights.
+
+## Business Rules
+
+### Data Schema
+
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| Campaign ID | Identifier. | String (10) | Required. |
+| Campaign Name | Name of the campaign. | String (50) | Required. >= 10 chars. |
+| Campaign Owner | Owner reference. | String (50) | Optional. |
+| Campaign Description | Description. | String (500) | Optional. |
+| Campaign Type | Base or Tactical. | Enum (Lookup) | Required. |
+| Target Active Customer Count | Expected participant count. | Integer | Optional. Insight metric. |
+| Target Avg Transaction Value | Expected spend value. | Decimal | Optional. Insight metric. |
+| Campaign Period | Earliest Rule start to latest Rule end. | Date Range | Read-only based on Rules. |
+
+### Execution
+- Campaigns simply group Rules logically. The actual execution logic is defined in the child Campaign Rules.
+
+## Exception Flow
+- N/A

docs/specs/reward_campaign/reward_campaign_rule.md

@@ -0,0 +1,64 @@
+---
+title: "Reward Campaign Rule"
+type: OpenSpec
+status: Draft
+domain: Reward Campaign Management
+---
+
+# Reward Campaign Rule
+
+## Requirement Definition
+Campaign Rules define the business rules for giving a reward, defining conditions for redemption, or triggering batch updates (CEP/REP). This spec covers standard Award, Redeem, and Adjust rules.
+
+## Process Flow
+
+### Pre-Conditions
+- Users must have access rights.
+
+## Business Rules
+
+### Data Schema
+
+#### General Information
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| Campaign ID | Parent campaign. | Enum (Lookup) | Required. |
+| Campaign Rule ID | System-generated identifier. | String (10) | Required. |
+| Campaign Rule Name | Name of the rule. | String (50) | Required. |
+| Rule Type | Award, Redeem, Adjust. | Enum (Lookup) | Required. |
+| Effective Date From | Start of effective period. | Date | Required. |
+| Effective Date To | End of effective period. | Date | Required. |
+
+#### Rule Setting
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| Effective Period is Based On| Transaction Date vs Post Date. | Enum | Required. |
+| Pool | Reward pool applied to this rule. | Enum (Lookup) | Required. |
+| Item Code | eVoucher item if Pool Type is eVoucher. | Enum (Lookup) | Conditional. |
+| Message Template ID | SMS/Email template if rule hit. | Enum (Lookup) | Optional. |
+| Stop if criteria met | If true, halts further rule evaluation for this TC. | Boolean | Default False. |
+| Do not update pool | Rule updates Counters/Attributes but not the pool. | Boolean | Default False. |
+
+#### Transaction Code Linkage
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| Transaction Code | TC that triggers this rule. | Enum (Lookup) | Required. |
+| Execution Sequence | Priority order of execution. | Integer | Required. Unique per Rule Type + TC combo. |
+
+#### Formula Setting (If Rule Type requires formula)
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| Amount to Use (A) | Derived amount (from tx data or counter). | Enum | Required. |
+| Cap A not more than | Caps the input 'A'. | Decimal | Optional. |
+| Formula Result is rounded | Down, Nearest, Up. | Enum | Required. |
+| Award Limit (At Least) | Minimum guaranteed result. | Decimal | Optional. |
+| Award Limit (No More Than) | Max limit (can be tied to a Counter). | Decimal | Optional. |
+
+### Execution
+- An incoming transaction's TC is matched against Rules.
+- Rules linked to the TC are evaluated in Execution Sequence order.
+- If Rule Criteria (defined separately) pass, the Formula (defined separately) calculates the reward.
+- If "Stop if criteria met" is true, processing halts.
+
+## Exception Flow
+- N/A

docs/specs/reward_campaign/transaction_category.md

@@ -0,0 +1,37 @@
+---
+title: "Transaction Category"
+type: OpenSpec
+status: Draft
+domain: Reward Campaign Management
+---
+
+# Transaction Category
+
+## Requirement Definition
+A reusable group of conditions/criteria that define a specific category of transactions (e.g., "Dining transactions in Foreign Currency"). Allows efficient and reusable setup of Campaign Rule Criteria without needing multiple duplicated rules.
+
+## Process Flow
+
+### Pre-Conditions
+- Users must have access rights.
+- Criteria attributes must exist in the system.
+
+## Business Rules
+
+### Data Schema
+
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| Transaction Category Code | Unique identifier. | String (5) | Required. |
+| Transaction Category Name | Name of category. | String (50) | Required. |
+| Description | Description for reference. | String (100) | Optional. |
+| Configuration | Groupings of criteria (AND/OR). | Rule Builder | Required. Same structure as Rule Criteria. |
+
+### Execution
+- Built using the Query Builder UI.
+- Supports nested AND/OR logic.
+- Includes NOT operators for exclusions.
+- A Transaction Category acts as a single virtual criterion when configuring a Campaign Rule.
+
+## Exception Flow
+- N/A

docs/specs/system_management/application_parameter.md

@@ -0,0 +1,64 @@
+---
+title: "Application Parameter"
+type: OpenSpec
+status: Draft
+domain: System Management
+---
+
+# Application Parameter
+
+## Requirement Definition
+The "Application Parameters" module provides a means to maintain a set of application control parameters that define system behavior in relation to user authentication and display formats. This includes password policy parameters, session time-outs, and system display formats.
+
+## Process Flow
+
+### Trigger
+- User accesses the Application Parameters module under System Management.
+
+### Pre-Conditions
+- Users must have access rights to the Application Parameters module.
+- Depending on access rights, users can view, add, or edit parameters.
+
+## Business Rules
+- All parameters are pre-defined by the system with default values.
+- Users with appropriate rights can modify these parameter values.
+
+### Data Schema
+
+#### Access Control Parameters
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| Same User Cannot Approve | Allow/Disallow the user to approve/reject the record they created. | Boolean | Default: False |
+| Same User Cannot Modify Own Profile | Allow/Disallow the user to change their profile in the system. | Boolean | Default: False |
+| User Session Inactivity Time-out | The user session ends if there are no user actions for N minutes. Alert message required on timeout. | Integer | Default: 30 |
+| Maximum Failed Forgotten Password Attempts | User ID is blocked from further log-ins and profile suspended until reset if invalid passwords exceed this limit consecutively. | Integer | Default: 5 |
+| Inactivate User Id after N days of no log-ins | User status is automatically set to inactive until reset if not logged in for the specified number of days. | Integer | Default: 30 |
+| Remind User to Change password N Days Before | System notifies the user to change the password N days before expiration upon login. | Integer | Default: 5 |
+| Password expiration (days) | Number of days after which a new password expires. Account is locked post-expiration until admin unlocks. | Integer | Default: 180 |
+| Disallow re-use of the last N passwords | System restricts re-using the last N passwords to ensure regular updates. | Integer | Default: 2 |
+| Maximum password length | Maximum length of a new password. | Integer | Default: 50 |
+| Minimum password length | Minimum length of a new password. | Integer | Default: 8 |
+| Password must at least N numeric digit | Minimum numeric digits required in a password. | Integer | Default: 1 |
+| Password must have at least N upper case alphabet | Minimum uppercase letters required in a password. | Integer | Default: 1 |
+| Password must have at least N lower case alphabet | Minimum lowercase letters required in a password. | Integer | Default: 1 |
+| Password must have at least N special character | Minimum special characters required in a password. | Integer | Default: 1 |
+
+#### Display Setting Parameters
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| Date format | Determines how dates are displayed throughout the system. | String | Enum: DD/MM/YYYY, DD-MM-YYYY, DDMMYYYY, MM/DD/YYYY, MM-DD-YYYY, YYYY/MM/DD, YYYY-MM-DD, DD,MM,YYYY. Default: DD/MM/YYYY |
+| Time format | Determines how times are displayed throughout the system. | String | Enum: HH:mm:ss, HHmmss, HH,mm,ss, HH;mm;ss, HH/mm/ss. Default: HH:mm:ss |
+| Amount display format | Determines how amounts are displayed throughout the system. | String | Enum: American (999,999.99), European (999.999,99) |
+
+#### Functionality Parameters
+| Field Name | Description | Logic Type | Constraints / Rules |
+|---|---|---|---|
+| Processing Date | The date on which a transaction is processed. Used for testing only. If empty, the system date is used. | Date | Default: Empty |
+| Allow Cross Function Update | Allows or disallows cross-updates between data created by different users. Applies to Customer, Account, and Card data. | Boolean | Default: True |
+
+## Post-Conditions
+- The application uses the updated parameter configuration.
+- Application parameter management is maintainable and scalable with other systems.
+
+## Exception Flow
+No exceptions defined.

loyalty-agent/src/main/java/dev/sonpx/loyalty/agent/LoyaltyAgentApplication.java

@@ -6,7 +6,7 @@ import org.springframework.boot.autoconfigure.SpringBootApplication;
 @SpringBootApplication
 public class LoyaltyAgentApplication {
 
-    public static void main(String[] args) {
+    static void main(String[] args) {
         SpringApplication.run(LoyaltyAgentApplication.class, args);
     }
 }

loyalty-agent/src/main/java/dev/sonpx/loyalty/agent/config/FlywayConfig.java

@@ -1,25 +1,22 @@
-package dev.sonpx.loyalty.agent.config;
+//package dev.sonpx.loyalty.agent.config;
-
+//
-import org.flywaydb.core.Flyway;
+//import org.flywaydb.core.Flyway;
-import org.springframework.beans.BeansException;
+//import org.springframework.beans.BeansException;
-import org.springframework.beans.factory.config.BeanPostProcessor;
+//import org.springframework.beans.factory.config.BeanPostProcessor;
-import org.springframework.context.annotation.Configuration;
+//import org.springframework.context.annotation.Bean;
-import org.springframework.lang.NonNull;
+//import org.springframework.context.annotation.Configuration;
-import javax.sql.DataSource;
+//import org.springframework.lang.NonNull;
-
+//import javax.sql.DataSource;
-@Configuration
+//
-public class FlywayConfig implements BeanPostProcessor {
+//@Configuration
-
+//public class FlywayConfig {
-    @Override
+//
-    public Object postProcessAfterInitialization(@NonNull Object bean, @NonNull String beanName) throws BeansException {
+//    @Bean
-        if (bean instanceof DataSource) {
+//    public FlywayMigrationStrategy flywayMigrationStrategy() {
-            System.out.println("--- Running Flyway Migration before DataSource is used ---");
+//        return flyway -> {
-            Flyway.configure()
+//            // Ví dụ: Xóa hết schema cũ rồi mới chạy migration (chỉ áp dụng thử nghiệm!)
-                    .dataSource((DataSource) bean)
+//            // flyway.clean();
-                    .locations("classpath:db/migration")
+//            flyway.migrate();
-                    .load()
+//        };
-                    .migrate();
+//    }
-        }
+//}
-        return bean;
-    }
-}

loyalty-agent/src/main/java/dev/sonpx/loyalty/agent/config/McpConfig.java

@@ -0,0 +1,20 @@
+package dev.sonpx.loyalty.agent.config;
+
+import org.springframework.beans.factory.config.BeanFactoryPostProcessor;
+import org.springframework.context.annotation.Bean;
+import org.springframework.context.annotation.Configuration;
+
+@Configuration
+public class McpConfig {
+
+    @Bean
+    public static BeanFactoryPostProcessor lazyMcpClientPostProcessor() {
+        return beanFactory -> {
+            for (String beanName : beanFactory.getBeanDefinitionNames()) {
+                if (beanName.toLowerCase().contains("mcp") || beanName.toLowerCase().contains("toolcallbackprovider")) {
+                    beanFactory.getBeanDefinition(beanName).setLazyInit(true);
+                }
+            }
+        };
+    }
+}

loyalty-agent/src/main/java/dev/sonpx/loyalty/agent/config/WebSocketConfig.java

@@ -1,11 +1,16 @@
 package dev.sonpx.loyalty.agent.config;
 
+import java.security.Principal;
+import java.util.Map;
 import java.util.UUID;
 import org.springframework.context.annotation.Configuration;
+import org.springframework.http.server.ServerHttpRequest;
 import org.springframework.messaging.simp.config.MessageBrokerRegistry;
+import org.springframework.web.socket.WebSocketHandler;
 import org.springframework.web.socket.config.annotation.EnableWebSocketMessageBroker;
 import org.springframework.web.socket.config.annotation.StompEndpointRegistry;
 import org.springframework.web.socket.config.annotation.WebSocketMessageBrokerConfigurer;
+import org.springframework.web.socket.server.support.DefaultHandshakeHandler;
 
 @Configuration
 @EnableWebSocketMessageBroker
@@ -22,10 +27,10 @@ public class WebSocketConfig implements WebSocketMessageBrokerConfigurer {
     public void registerStompEndpoints(StompEndpointRegistry registry) {
         registry.addEndpoint("/ws")
                 .setAllowedOriginPatterns("*")
-                .setHandshakeHandler(new org.springframework.web.socket.server.support.DefaultHandshakeHandler() {
+                .setHandshakeHandler(new DefaultHandshakeHandler() {
                     @Override
-                    protected java.security.Principal determineUser(org.springframework.http.server.ServerHttpRequest request, org.springframework.web.socket.WebSocketHandler wsHandler, java.util.Map<String, Object> attributes) {
+                    protected Principal determineUser(ServerHttpRequest request, WebSocketHandler wsHandler, Map<String, Object> attributes) {
-                        return new java.security.Principal() {
+                        return new Principal() {
                             private final String id = UUID.randomUUID().toString();
                             @Override
                             public String getName() {

loyalty-agent/src/main/java/dev/sonpx/loyalty/agent/core/executor/SimpleAgentExecutor.java

@@ -58,8 +58,9 @@ public class SimpleAgentExecutor {
      * The LLM decides which tools to call via ReAct pattern.
      */
     public void executeWithTools(ChatRequest request, String connectionSessionId, String conversationKey, Intent intent) {
-        List<ToolCallback> wrappedTools = toolInterceptor.getWrappedTools(
+        try {
-                connectionSessionId, request.messageId(), AgentToolScope.READ_ONLY);
+            List<ToolCallback> wrappedTools = toolInterceptor.getWrappedTools(
+                    connectionSessionId, request.messageId(), AgentToolScope.READ_ONLY);
 
         String systemPrompt = promptBuilder.buildSystemPrompt(intent);
         String userPrompt = promptBuilder.buildUserPrompt(request);
@@ -94,10 +95,34 @@ public class SimpleAgentExecutor {
                         },
                         error -> {
                             log.error("Error during SimpleAgent execution for connection {}: {}", connectionSessionId, error.getMessage(), error);
-                            eventPublisher.error(connectionSessionId, request.messageId(),
+                            String errorMessage = "Xin lỗi, đã xảy ra lỗi khi xử lý yêu cầu. Vui lòng thử lại.";
-                                    "Xin lỗi, đã xảy ra lỗi khi xử lý yêu cầu. Vui lòng thử lại.");
+                            if (isConnectionError(error)) {
+                                errorMessage = "Hiện tại dịch vụ AI (Ollama) đang tạm thời gián đoạn. Vui lòng thử lại sau.";
+                            }
+                            eventPublisher.error(connectionSessionId, request.messageId(), errorMessage);
                         }
                 );
+        } catch (Exception e) {
+            log.error("Error setting up SimpleAgent for connection {}: {}", connectionSessionId, e.getMessage(), e);
+            String errorMessage = "Xin lỗi, không thể khởi tạo tool. Vui lòng thử lại.";
+            if (isConnectionError(e)) {
+                errorMessage = "Hiện tại dịch vụ tool (MCP) đang tạm thời gián đoạn. Vui lòng thử lại sau.";
+            }
+            eventPublisher.error(connectionSessionId, request.messageId(), errorMessage);
+        }
+    }
+
+    private boolean isConnectionError(Throwable t) {
+        if (t == null) return false;
+        Throwable current = t;
+        while (current != null) {
+            String name = current.getClass().getName();
+            if (name.contains("ConnectException") || name.contains("SocketException") || name.contains("ResourceAccessException")) {
+                return true;
+            }
+            current = current.getCause();
+        }
+        return false;
     }
 
     /**
@@ -136,8 +161,11 @@ public class SimpleAgentExecutor {
                         },
                         error -> {
                             log.error("Error during DirectChat execution for connection {}: {}", connectionSessionId, error.getMessage(), error);
-                            eventPublisher.error(connectionSessionId, request.messageId(),
+                            String errorMessage = "Xin lỗi, đã xảy ra lỗi. Vui lòng thử lại.";
-                                    "Xin lỗi, đã xảy ra lỗi. Vui lòng thử lại.");
+                            if (isConnectionError(error)) {
+                                errorMessage = "Hiện tại dịch vụ AI (Ollama) đang tạm thời gián đoạn. Vui lòng thử lại sau.";
+                            }
+                            eventPublisher.error(connectionSessionId, request.messageId(), errorMessage);
                         }
                 );
     }

loyalty-agent/src/main/java/dev/sonpx/loyalty/agent/core/executor/ToolInterceptor.java

@@ -33,7 +33,7 @@ import java.util.List;
 @RequiredArgsConstructor
 public class ToolInterceptor {
 
-    private final List<ToolCallbackProvider> toolProviders;
+    private final ObjectProvider<ToolCallbackProvider> toolProviders;
     private final AgentEventPublisher eventPublisher;
     private final ToolResultPresentationProcessor toolResultProcessor;
     private final AgentProperties agentProperties;
@@ -46,7 +46,7 @@ public class ToolInterceptor {
     public List<ToolCallback> getWrappedTools(String sessionId, String messageId, AgentToolScope scope) {
         List<ToolCallback> wrappedTools = new ArrayList<>();
 
-        for (ToolCallbackProvider provider : toolProviders) {
+        for (ToolCallbackProvider provider : toolProviders.stream().toList()) {
             for (ToolCallback tool : provider.getToolCallbacks()) {
                 String toolName = tool.getToolDefinition().name();
                 if (scope.allows(toolName)) {
@@ -107,9 +107,10 @@ public class ToolInterceptor {
         try {
             return tool.call(toolInput);
         } catch (Exception e) {
-            if (isConnectionOrSessionError(e)) {
+            Throwable rootCause = getRootCause(e);
+            if (isConnectionOrSessionError(rootCause)) {
                 log.warn("Detected MCP connection/session drop on tool {}: {}. Attempting auto-reconnect and retry...",
-                        toolName, e.getMessage());
+                        toolName, rootCause.getMessage());
                 attemptReconnect();
                 try {
                     return tool.call(toolInput);
@@ -122,7 +123,7 @@ public class ToolInterceptor {
         }
     }
 
-    private void attemptReconnect() {
+    private synchronized void attemptReconnect() {
         if (mcpSyncClientsProvider != null) {
             List<McpSyncClient> clients = mcpSyncClientsProvider.getIfAvailable();
             if (clients != null && !clients.isEmpty()) {
@@ -138,6 +139,14 @@ public class ToolInterceptor {
         }
     }
 
+    private Throwable getRootCause(Throwable t) {
+        if (t == null) return null;
+        Throwable current = t;
+        while (current.getCause() != null && current.getCause() != current) {
+            current = current.getCause();
+        }
+        return current;
+    }
     public boolean isConnectionOrSessionError(Throwable t) {
         if (t == null) {
             return false;
@@ -147,7 +156,9 @@ public class ToolInterceptor {
             if (current instanceof EOFException
                     || current instanceof ConnectException
                     || current instanceof SocketException
-                    || current instanceof ClosedChannelException) {
+                    || current instanceof ClosedChannelException
+                    || current.getClass().getName().contains("ConnectException")
+                    || current.getClass().getName().contains("SocketException")) {
                 return true;
             }
             String msg = current.getMessage();

loyalty-agent/src/main/resources/application.yml

@@ -40,7 +40,7 @@ spring:
           num_ctx: 32768
     mcp:
       client:
-        request-timeout: 60000
+        request-timeout: 3000
         enabled: true
         type: sync
         sse:

start-all.ps1

@@ -31,8 +31,8 @@ foreach ($port in 9331, 9332, 9333) {
     }
 }
 
-Get-Process | Where-Object { $_.CommandLine -like "*nodemon*$ProjectRoot*" } | Stop-Process -Force -ErrorAction SilentlyContinue
+Get-WmiObject Win32_Process | Where-Object { $_.CommandLine -like "*nodemon*$ProjectRoot*" } | ForEach-Object { Stop-Process -Id $_.ProcessId -Force -ErrorAction SilentlyContinue }
-Get-Process | Where-Object { $_.CommandLine -like "*MavenWrapperMain*$ProjectRoot*" } | Stop-Process -Force -ErrorAction SilentlyContinue
+Get-WmiObject Win32_Process | Where-Object { $_.CommandLine -like "*MavenWrapperMain*$ProjectRoot*" } | ForEach-Object { Stop-Process -Id $_.ProcessId -Force -ErrorAction SilentlyContinue }
 
 
 Write-Host "=========================================="