Release V9.2.6.5
Fixes
Notable fixes in this release:
Fixed Combined Statement Periods in the Console
Context: The Merchant Console was displaying combined statement periods that included transactions from two different months when the last Deposit statement's end date was the last day of a month but its deposit date fell in the following month.
Solution: Modified the statement aggregation logic to correctly use deposit dates instead of end dates for period calculations and applied the minimum date values for proper boundary determination.
Impact: Monthly statements now correctly display transactions from a single calendar month period, allowing merchants to properly download and view reports without timeout issues.
- Implementation Details
- Testing & Validation
- Database Changes
System Changes Overview
- Database Changes: None
- Configuration Changes: None
- Code Changes: Modified SQL query for statement aggregation
- Filesystem Changes: None
- Data Migration: None
Update Actions Analysis
Update actions are not required for this change.
- The fix is implemented entirely through code changes
- The changes are automatically applied during standard deployment
- No database structure modifications are needed
- No configuration parameter changes are required
Implementation Actions
- Modified statement aggregation query to use MIN() function for date fields
- Changed statement ID generation to use deposit_date instead of end_date
- Corrected date boundary calculations in ListVM_FindMerchantStatementExtended query
- Ensured backward compatibility with existing statement data
Configuration and Access Steps
- No special configuration required
- Navigation: Merchant Console → Statements
- Access merchant accounts that process transactions spanning month boundaries
- Check monthly statement periods for single-month display
Test Scenarios
-
Verify statement period for transactions with last day deposits
- Steps: Find a merchant with deposits on the last day of the month, check monthly statement period
- Expected result: Statement should show a single month period (e.g., Jan 1-31)
-
Check statement display for deposits made after statement end date
- Steps: Locate a merchant with deposit dates falling after statement end dates
- Expected result: Statement periods should not combine multiple months
-
Verify PDF generation for previously problematic statements
- Steps: Attempt to download PDF for a merchant statement that previously showed combined periods
- Expected result: PDF should generate successfully without timeout
-
Validate statement data integrity
- Steps: Compare transaction data in monthly statements with deposit statements
- Expected result: All transactions should be included in the correct monthly period
Common Issues
- Statements may initially appear unchanged in cache until refreshed
- Previously generated combined statements may still exist until new ones are generated
- PDF generation may still be slow for statements with extremely high transaction volumes
- Historical statement issues will not be retroactively fixed (only new statement generation is affected)
Potential Impact Areas
- UI Components: Statements section displays corrected period dates without showing combined months
- Reports & Analytics: Monthly statement reports show transactions from single calendar months
- APIs & Integrations: API endpoints for statement retrieval return correct period data
- Database Queries: Statement list query performance is unaffected by the change
- Business Logic: Statement period calculations now correctly respect deposit dates
- Performance: Reduced likelihood of timeouts during PDF generation for monthly statements
Schema Updates
- No database schema changes were required for this fix
- No data migration needed
- No index modifications required
- No table structure alterations
Rollback Possibility Assessment
Database rollback is possible if needed.
- The change only affects query logic, not database structure
- No data transformations or migrations were performed
- Reverting the code changes would restore previous behavior
- No risk of data loss or corruption from rollback
System Performance Improvements
Performance optimizations to enhance system stability and responsiveness:
- Merchant Statement Query Optimization(UP-643)
- Database Performance Optimization for Merchant Statements(UP-644)
Merchant Statement Query Optimization
Context: The query for retrieving merchant statement transaction details was causing excessive database load and performance issues during statement generation, especially with large transaction volumes.
Solution: Implemented query optimization that limits result sets to 400 most recent transactions and restructured SQL joins to eliminate redundant table connections and improve data retrieval efficiency.
Impact: Significantly reduced database load and query execution time when viewing merchant statements, resulting in faster page loads and improved system response times for users working with transaction history.
- Implementation Details
- Testing & Validation
- Database Changes
System Changes Overview
- Database Changes: No structural changes to database schema
- Configuration Changes: None
- Code Changes: Modified FindMerchantStatementTransactionDetails SQL query in merchant statement data retrieval logic
- Filesystem Changes: None
- Data Migration: None
Update Actions Analysis
No update actions are required for this improvement.
- The optimization is implemented through standard code changes
- No database schema modifications are needed
- No configuration changes are required
- The changes are applied automatically through normal deployment process
Implementation Actions
- Deploy updated application package to target environments
- Verify proper functioning of merchant statement transaction details display
- Monitor database performance metrics after deployment
- No special deployment steps required beyond standard release process
Configuration and Access Steps
- No special configuration required
- Navigate to: Management → Statements → Statement Details
- Select any merchant statement that contains transactions
- Navigate to transaction details section
Test Scenarios
-
Basic Functionality Verification
- Steps: Open a merchant statement with various transaction types
- Expected result: Transactions should display correctly with all details intact
-
Performance Comparison
- Steps: Compare response time for statement details page before and after the update
- Expected result: Page should load noticeably faster with the optimized query
-
Large Volume Testing
- Steps: Test with a merchant having a large number of transactions
- Expected result: System should efficiently retrieve and display the most recent 400 transactions
-
Transaction Type Verification
- Steps: Verify both regular transactions and chargebacks display correctly
- Expected result: Both transaction types should show proper details and amounts
Common Issues
- Verify that transaction totals match expected values
- Confirm that transaction sorting is correct (newest transactions appearing first)
- Check that chargebacks are properly linked to their original transactions
- Validate that transaction details remain accurate and complete
Potential Impact Areas
- UI Components: No changes to UI components, only backend performance improvements
- Reports & Analytics: Statement reports should show identical data but load faster
- APIs & Integrations: No impact on external APIs
- Database Queries: Significant improvement in merchant_statement query performance
- Business Logic: No changes to business logic or calculation methods
- Performance: Monitor database server CPU and memory usage; significant reduction in query execution time expected
Schema Updates
- No structural changes to database schema
- No new tables or columns added
- No modifications to existing field types or constraints
Rollback Possibility Assessment
Database rollback is possible if needed.
- The change affects only query logic, not database structure
- No data migrations or transformations are performed
- No destructive changes or data modifications involved
- Standard code deployment rollback would completely restore previous functionality
Database Performance Optimization for Merchant Statements
Context: The merchant_statement_extended_detail and merchant_statement_extended_fee_detail database tables lacked indexes for the STATEMENT_CODE field, which caused slower execution of queries using this field.
Solution: Implemented database indexes on the STATEMENT_CODE field in both merchant_statement_extended_detail and merchant_statement_extended_fee_detail tables.
Impact: Improved query performance and system responsiveness for statement-related operations, particularly for queries that filter or join by statement code.
- Implementation Details
- Testing & Validation
- Database Changes
System Changes Overview
- Database Changes: Added indexes on STATEMENT_CODE field in merchant_statement_extended_detail and merchant_statement_extended_fee_detail tables
- Configuration Changes: None
- Code Changes: None
- Filesystem Changes: Added delta scripts for index creation
- Data Migration: None
Update Actions Analysis
Update actions are not required for this change.
- The changes can be executed through standard database delta scripts
- No manual intervention is needed during the deployment process
- The index creation scripts are part of the standard deployment package
- Database delta mechanism handles the changes automatically
Implementation Actions
- Apply database delta script 32915_800 to create index on merchant_statement_extended_detail table
- Apply database delta script 32915_801 to create index on merchant_statement_extended_fee_detail table
- No additional configuration is required
- No application restart is needed specifically for this change
Configuration and Access Steps
- No special configuration is required for testing this change
- No specific UI navigation paths are affected
- Database indexes work automatically to improve query performance
- Navigation: N/A - Backend performance improvement only
Test Scenarios
-
Verify Index Creation
- Steps: Check database schema to confirm index exists
- Expected result: Index 'statement_code_index' exists on both merchant_statement_extended_detail and merchant_statement_extended_fee_detail tables
-
Run Statement Query Performance Test
- Steps: Execute queries that filter by STATEMENT_CODE field and measure execution time
- Expected result: Queries should execute faster than before the index implementation
-
Regression Testing for Statement Processing
- Steps: Execute standard statement processing operations
- Expected result: All operations should work correctly with no errors
-
Load Testing
- Steps: Simulate high volumes of statement queries using the STATEMENT_CODE field
- Expected result: System maintains good performance under load
Common Issues
- Performance improvements may vary depending on the database size and server configuration
- First execution after index creation may trigger index rebuilding
- Large database tables may experience slightly longer initial index creation time
- Query optimizer may not use the index in all scenarios
Potential Impact Areas
- UI Components: No direct impact on UI elements
- Reports & Analytics: Statement reports may execute faster, especially when filtering by statement code
- APIs & Integrations: APIs that query statement data may show improved response times
- Database Queries: Queries involving statement_code will utilize the new indexes for faster retrieval
- Business Logic: No changes to business logic
- Performance: Improved query execution time for statement data retrieval operations
Schema Updates
- Added index 'statement_code_index' on STATEMENT_CODE field in merchant_statement_extended_detail table
- Added index 'statement_code_index' on STATEMENT_CODE field in merchant_statement_extended_fee_detail table
- No table structure modifications were made
Rollback Possibility Assessment
Rollback is possible for these changes without data impact.
- The changes only add indexes without modifying the underlying data structure
- Indexes can be safely dropped if needed using standard DROP INDEX commands
- No data transformations or migrations are involved
- Removing the indexes would only affect performance, not data integrity
Deployment Recommendations
It is recommended to schedule this deployment during non-business hours in the client's time zone, as index creation on large tables could temporarily increase database load. While the changes are non-destructive and don't require extended downtime, potential offline periods may extend beyond estimates due to unforeseen circumstances.