29 lines
1.5 KiB
Markdown
29 lines
1.5 KiB
Markdown
# Changelog
|
|
|
|
## [17.0.1.0.1] - 2025-11-21
|
|
|
|
### Fixed
|
|
- **Bank Statement Matching Issue**: Fixed residual amounts showing incorrectly when payments are already reconciled/matched with bank statements
|
|
- **Unmatched Payment Issue**: Fixed unmatched payments showing 0 residual when they should show actual residual amounts
|
|
|
|
### Changed
|
|
- Modified `_compute_payment_residual()` to check `is_matched` status only
|
|
- If payment is matched with bank statement (`is_matched=True`), residual is always 0
|
|
- For unmatched payments, calculates residual from receivable/payable lines only
|
|
- Excluded liquidity account lines (bank/cash accounts) from residual calculation
|
|
- Removed `is_reconciled` check as it was causing false positives
|
|
|
|
### Technical Details
|
|
The issues occurred because:
|
|
1. When a payment is matched with a bank statement, the `is_matched` flag is set to True
|
|
2. The previous implementation was calculating residuals regardless of matching status
|
|
3. Even though the payment was matched, the receivable/payable line could still show a residual if not applied to an invoice
|
|
4. Using `is_reconciled` check caused unmatched payments to show 0 residual incorrectly
|
|
|
|
The fix:
|
|
- Only checks `is_matched` flag - if True, returns 0 residual
|
|
- This ensures matched payments always show 0 residual
|
|
- For unmatched payments, calculates residual from receivable/payable lines
|
|
- Excludes liquidity account lines to focus on actual customer/vendor balances
|
|
- This correctly shows residuals for unmatched payments while hiding them for matched ones
|