- Added special handling for differences < 1.0 (like -0.90)
- Small differences now create rounding-only entries (758000/658000)
- No main balancing entry (4455100/4456700) for small differences
- Should show 758000 with 0.90 instead of 4455100 with 1.00
- Added handling for cases where rounded difference is 0 but real difference is not 0
- Now creates rounding-only entry when difference is small (like -0.90)
- Should show 758000 with 0.90 instead of 1.00
- Handles edge cases where difference rounds to 0 but real value is significant
- Added debug logging to show which account is being created
- Added logging for difference calculation and condition evaluation
- Should help identify why example 1 shows 4456700 instead of 4455100
- Will help trace the source of duplicate 4455100 entries
- Debit difference: now uses 4455100 credit (not 4456700)
- Credit difference: now uses 4456700 debit (not 4455100)
- Rounding accounts also corrected: 758000 for debit diff, 658000 for credit diff
- Should now match user examples correctly
- Debit difference: 758000 credit (not debit) for rounding
- Credit difference: 658000 debit for rounding
- Now matches user examples where debit difference uses 758000 credit
- Should show correct rounding entries in journal table
- Changed difference calculation from (debits - credits) to (credits - debits)
- Now matches user examples where credit difference uses 4455100
- Should eliminate the unwanted 4456700 line in credit scenarios
- 4455100 and 4456700 will never appear together now
- Removed duplicate 4455100 entry creation
- Now creates either 4455100 (credit) OR 4456700 (debit), not both
- Added debug logging for total debits/credits to trace calculation
- Should eliminate the unwanted 4455100 line in journal table
- Calculate difference between debits and credits
- Main entry: rounded amount on 4455100 (credit) or 4456700 (debit)
- Rounding entry: real difference on 758000 (credit diff) or 658000 (debit diff)
- Simplified logic by removing TD line dependency
- Both VAT debit and credit scenarios now work correctly
- Main balancing entry now uses rounded amount (formatAmount) for proper accounting
- Rounding difference goes to 658000/758000 with real value (formatAmountReal)
- Fixed fallback logic to handle both VAT debit and credit scenarios correctly
- VAT credit: rounded amount on 4456700, real difference on 658000
- VAT debit: rounded amount on 4455100, real difference on 758000
- Added debugging to TD line query to see why VAT amount is 0
- Fixed fallback logic to use formatAmountReal() instead of formatAmount()
- When TD line has 0 VAT amount, now uses real difference (0.90) instead of rounded (1.00)
- Added logging to track TD line query and results
- Should now show 0.90 instead of 1.00 in rounding entry
- Added error_log statements to track total difference and VAT TD amount
- Added logging for remaining difference calculation
- Will help identify why rounding entry shows 1.00 instead of 0.90
- Check error logs after generating PDF to see calculation values
- Rounding entries (658000/758000) already use formatAmountReal() for real values
- Added comment to clarify this behavior
- Main balancing entry uses rounded VAT amount from TD line
- Rounding entry uses real difference with decimals
- Ensures proper accounting precision for rounding differences
- Main balancing entry now uses VAT amount from line TD (69 in example)
- Remaining difference (0.90) goes to rounding entry on 758000
- Added getVATAmountFromLineTD method to fetch VAT amount from TD line
- Proper accounting: 69.00 credit on 4455100 + 0.90 credit on 758000
- Fallback to original logic if no TD line found
- Combined balancing and rounding logic into single method
- Main balancing entry uses correct account: 4456700 for debit, 4455100 for credit
- Separate rounding entry uses 658000/758000 for rounding differences
- Eliminates duplicate entries and ensures proper accounting structure
- Example: 69.00 credit on 4455100 + 0.90 on 758000 instead of two separate lines
- Debit balancing entries use 4456700 (TVA à payer)
- Credit balancing entries use 4455100 (TVA à recevoir)
- Account selection based on whether the balancing entry is debit or credit
- Proper French VAT accounting for balancing entries
- If difference < 0 (more credits): Use 4456700 (TVA à payer) on debit side
- If difference > 0 (more debits): Use 4455100 (TVA à recevoir) on credit side
- Each account gets its real label from chart of accounts
- Proper French VAT accounting logic for balancing entries
- Added multiple query strategies to handle different database configurations
- Tries with entity filter, without entity filter, and without active filter
- Enhanced debugging to show which query succeeds
- Based on successful patterns from other methods in the codebase
- Should now properly retrieve account names from Dolibarr chart of accounts
- Added error_log statements to track account lookup process
- Removed entity filtering temporarily to test if that's the issue
- Will help identify why account names are not showing from chart of accounts
- Check error logs after generating PDF to see what's happening
- Removed hardcoded fallback labels that were made up
- Now properly queries accounting_account table for real account labels
- Uses entity filtering and active account filtering
- Falls back to generic 'Compte XXXX' only if account not found
- Journal table now shows actual account names from your chart of accounts
- Added getAccountLabel method to fetch real account descriptions from chart of accounts
- Balancing entry now uses real account description for 4456700
- Balancing amounts are now rounded (no decimals)
- Added getBalancingRoundingEntry method for separate rounding line
- Rounding difference goes to 658000 (debit) or 758000 (credit) with real descriptions
- Improved double-entry bookkeeping with proper account labels and rounding
- Added getBalancingEntry method to calculate balancing entry
- Sums all debit amounts and subtracts all credit amounts
- If result < 0: adds debit to 4456700 account
- If result > 0: adds credit to 4456700 account
- Added parseAmount helper method to convert formatted amounts back to floats
- Journal table now automatically balances with calculated entry
- Ensures proper double-entry bookkeeping in OD journal
- Changed all journal entry labels to use declaration_name field
- Updated getLine8VATAccounts to use declaration_name
- Updated getLine20Accounts to use declaration_name
- Updated getVATResultEntry to use declaration_name
- Updated getRoundingEntry to use declaration_name
- Journal entries now show user-defined names like 'MAI 2025', 'JUIN 2025'
- Changed entry labels to use declaration number instead of generic labels
- Updated getLine8VATAccounts to use declaration name
- Updated getLine20Accounts to use declaration name
- Updated getVATResultEntry to use declaration name
- Updated getRoundingEntry to use declaration name
- All journal entries now show the declaration name as the entry label
- Added filter to show only 445 accounts (VAT accounts) in journal table
- Created formatAmountReal method to display amounts with decimals
- Updated getLine8VATAccounts to filter for 445 accounts and use real values
- Updated getLine20Accounts to filter for 445 accounts and use real values
- Updated VAT result and rounding entries to use real values
- Journal table now shows only VAT accounts with precise amounts
- Changed account_number to account_code in getLine8VATAccounts method
- Changed account_number to account_code in getLine20Accounts method
- Account numbers should now display correctly in the journal entry table
- Fixes issue where account codes were showing as empty in the PDF
- Moved journal entry table to page 1 after declaration info
- Line details (Détail de la ligne A1) now start on page 2
- Removed duplicate AddPage() call from addJournalEntryTable
- Added explicit AddPage() call in addDetailPages for page 2 start
- Improved PDF structure for better readability
- Added addJournalEntryTable method to generate journal entries table
- Table includes columns: Code compte, Libellé compte, Libellé écriture, Débit, Crédit
- Extracts VAT accounts from line 8 (debit side, non-zero only)
- Extracts accounts from line 20 (credit side, non-zero only)
- Adds VAT result on account 4456700 (debit if < 0, credit if >= 0)
- Adds rounding difference on 658000 (if < 0) or 758000 (if > 0)
- Journal table starts on page 2 of the detailed PDF
- Uses proper French accounting terminology and formatting
- Updated module version from 2.1.0 to 2.2.0
- Added comprehensive changelog for version 2.2.0
- Documents all new features: validation workflow, PDF management, secure downloads
- Documents technical improvements: database migration, error handling, UI cleanup
- Documents bug fixes: token validation, PDF detection, path resolution, debug cleanup
- Ready for production deployment
- Changed PDF generation path from /documents/declarationtva/validated/ to /declarationtva/validated/
- Updated hasValidatedDocument() to look in /declarationtva/validated/
- Updated getValidatedPDFPath() to look in /declarationtva/validated/
- This removes the duplicate /documents in the file path
- Files will now be saved in /var/lib/dolibarr/declarationtva/validated/
- URLs will be /dolibarr/documents/declarationtva/validated/ (single /documents)
- Changed generateDetailedCA3PDF to call generateCA3PDF instead of generateDetailedPDF
- generateCA3PDF creates complete PDF with CA-3 form + detailed breakdown pages
- generateDetailedPDF only creates detailed pages without the CA-3 form
- Now generates complete PDF with both CA-3 form and account details
- Copies generated PDF to correct validated directory location
- Updated generateDetailedCA3PDF to save PDFs in /documents/declarationtva/validated/
- Updated hasValidatedDocument to look in /documents/declarationtva/validated/
- Updated getValidatedPDFPath to look in /documents/declarationtva/validated/
- Removed year/month directory structure
- Should now match the actual file location where PDFs are saved
- URLs should now work correctly
- Removed all error_log debug statements from production code
- Cleaned up hasValidatedDocument method
- Cleaned up declaration list processing
- Code is now production-ready
- PDF detection and generation are working correctly
- Added comprehensive error_log statements to track PDF detection
- Logs declaration ID, number, directory paths, and search patterns
- Shows all PDF files found in the directory
- Will help identify why PDF detection is failing
- Debug info will appear in PHP error logs
- Updated hasValidatedDocument() to use flexible file pattern matching
- Updated getValidatedPDFPath() with same flexible pattern
- First tries exact pattern: CA3_[declaration_number]_*.pdf
- Falls back to flexible pattern: CA3_*[declaration_number]*.pdf
- Should now detect PDFs with complex filenames like CA3_CA3-2025-05-20251002184011_2025-10-06.pdf
- Declaration list should now show green PDF icons for validated declarations
- Added step-by-step debug messages to track validation process
- Added file existence verification in generateDetailedCA3PDF
- Added detailed error reporting for PDF generation failures
- Will help identify exactly where PDF generation is failing
- Debug messages will show: validation start, PDF generator load, PDF generation, file existence check
- Modified generateDetailedCA3PDF to save PDFs directly to /documents/declarationtva/YYYY/MM/
- Updated saveValidatedPDF to handle PDFs already in correct location
- Added debugging messages to show PDF generation success/failure
- Fixed path mismatch between PDF generation and document detection
- PDFs should now be properly generated and detected in declaration list
- Modified hasValidatedDocument() to check file system instead of database
- Added getValidatedPDFPath() method to get PDF file path
- Updated declaration list to show clickable PDF download links
- Added DownloadPDF translation in French and English
- PDF icons now link directly to downloadable PDF files
- Fixed issue where validated declarations didn't show PDF availability
- Added ECM integration toggle for easy enable/disable
- Temporarily disabled ECM integration to prevent fatal errors
- Added debugging logs to track ECM files path resolution
- PDF saving to disk still works without ECM integration
- Declaration validation will work without document management
- Can be re-enabled once ECM files path is properly resolved
- Create dedicated VAT declarations folder structure under Dolibarr documents
- Organize by year and month: /documents/declarationtva/YYYY/MM/
- Updated PDF saving to use proper directory structure
- Enhanced ECM file records with proper filepath and descriptions
- Added helper methods for directory management
- Better document organization following Dolibarr conventions
- VAT declarations now have their own dedicated space
- Updated paths to include correct ECM files location
- Added multiple fallback paths for ecmfiles.class.php
- Prioritized /ecm/class/ path over /core/class/ path
- Enhanced error logging to show all attempted paths
- Should resolve the 'Failed opening required' error
- ECM files integration should now work properly
- Added unvalidateDeclaration() method to DeclarationTVA class
- Added unvalidate action handler in declarationtva_view.php
- Added red 'Unvalidate' button for validated declarations
- Added confirmation dialog for unvalidate action
- Added French and English language strings
- Allows reverting validated declarations back to draft status
- Useful for testing validation process multiple times
- Made ECM files integration optional and graceful
- Added file existence check before requiring ecmfiles.class.php
- Wrapped ECM file creation in try-catch to prevent fatal errors
- PDF is still saved to disk even if ECM integration fails
- Added detailed error logging for troubleshooting
- System now works regardless of ECM files availability
- Enhanced validateDeclaration() to check for column existence
- Falls back to basic validation if enhanced columns don't exist
- Updated migration script with proper column existence checks
- Uses dynamic SQL to avoid errors on existing columns
- System now works with or without the additional columns
- Graceful degradation for different database states
- Removed all error_log debug statements from PDF generation
- Removed debug logging from CA-3 data processing
- Removed debug logging from account amount calculations
- Cleaned up merge methods debug output
- Production-ready code without debug noise
- Added comprehensive PDF export combining CA-3 form with detailed breakdown pages
- Implemented pdftk-based PDF merging that preserves form fields
- Added support for new CA-3 lines (25, 26, 27, TD, 28, 32) with conditional visibility
- Fixed multi-select configuration saving issues
- Enhanced error handling and debugging for PDF generation
- Added French status translation for detailed PDFs
- Optimized page breaks to reduce paper usage
- Improved form field preservation during PDF merging
Technical improvements:
- Better error handling with comprehensive logging
- Modular PDF generation with fallback options
- Fixed pdftk filename conflicts
- Enhanced debugging capabilities
- Status translation without external dependencies
- Removed debug logging that was added to troubleshoot line 08 display issues
- The issue was identified as database field length limit (varchar(255) vs TEXT)
- Calculation is working correctly - line 08 shows base=1410.57, vat=186.34, total=1596.91
- User needs to run the database migration to fix the line_label field length
- Added debug logging to see how many BASE and VAT mappings are found
- Added logging to show which accounts are being processed and their amounts
- Added logging to show available mappings when none are found for a line
- This will help identify why line 08 base amounts are not displaying in the main view
