The totals PL/SQL block was generating invalid SQL with duplicate WHERE clauses
when bank/cash filters were applied (e.g., "WHERE bank_account=X WHERE dataact IS NULL").
Now properly uses AND when where_clause exists, WHERE otherwise.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Previously, totals were computed client-side from only the current page data,
which gave incorrect results when paginating. Now the backend calculates totals
across ALL filtered records and returns them in the API response.
- Invoice: Add total_sold_all field for sum of all filtered invoice balances
- Treasury: Add sold_precedent_all, total_incasari_all, total_plati_all, sold_final_all
- Trial Balance: Add 6-column totals (debit/credit for each balance type)
- Frontend stores and views updated to use backend totals
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Add PeriodSelectorMini component for global period selection
- Add accountingPeriod store for shared period state
- Add calendar service/router/model for available periods API
- Update Dashboard, Invoices, Trial Balance, Bank/Cash Register views
to respect selected period
- Fix Trial Balance navigation sync bug (period now syncs on mount)
- Update backend services to accept luna/an parameters
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Add bancasa as third sorting criterion (date, number, bank name)
- Sort null-date rows (previous balances) alphabetically by bank name
- Sort bank names alphabetically in PDF export
- Improve window function for cumulative balance calculation
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Cache System (Backend):
- Implemented two-tier hybrid cache: L1 (in-memory) + L2 (SQLite)
- L1 cache: Fast dictionary-based with 5-minute TTL for hot data
- L2 cache: Persistent SQLite with 1-hour TTL for warm data
- Cache decorator with automatic tier management and fallback
- Cache key generation with per-user isolation
- Event monitoring system for cache statistics
- Cache benchmarking utilities for performance testing
- Added cache management endpoints: /api/cache/stats, /api/cache/clear, /api/cache/benchmark
- Cache configuration via environment variables (CACHE_ENABLED, CACHE_L1_TTL, etc.)
Backend Services:
- Updated dashboard_service to use @cached decorator with request context
- Added cache support to invoice_service and treasury_service
- Integrated cache manager into main.py with lifespan events
- Added Request parameter to service methods for cache metadata
Frontend Enhancements:
- New CacheStatsView.vue for real-time cache monitoring dashboard
- Cache store (cacheStore.js) for state management
- Updated router to include /cache-stats route
- Navigation updates in DashboardHeader and HamburgerMenu
- Cache stats accessible from main navigation
Telegram Bot Improvements:
- Enhanced formatters with YTD comparison data
- Improved menu navigation and button layout
- Better error handling and user feedback
- Bot startup improvements with graceful shutdown
Auth & Middleware:
- Enhanced middleware with cache metadata injection
- Improved request state handling for cache source tracking
Development:
- Updated start-dev.sh with better error handling
- Added TELEGRAM_EMAIL_AUTH_PLAN.md documentation
- Updated requirements.txt with aiosqlite for async SQLite
Performance:
- L1 cache provides <1ms response for hot data
- L2 cache provides ~5ms response for warm data
- Database queries only for cold data or cache misses
- Cache hit rates tracked and displayed in real-time
🤖 Generated with Claude Code
Co-Authored-By: Claude <noreply@anthropic.com>
