- Completely removed rounding logic
- Now uses real difference values only (formatAmountReal)
- No more rounded amounts or complex rounding logic
- Simple: real difference goes to 4455100/4456700 with real value
- Should show 4455100 with 0.90 instead of 1.00
- 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
- 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
- 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
- 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
- Updated getCA3LineAmount method to handle duplicate CA-3 line entries
- Prioritizes 'Calculated' entries over 'No accounts mapped' entries
- This fixes lines 28 and 29 not displaying in PDF (they were showing 0 instead of calculated values)
- The method now correctly extracts calculated values: D28=357, D29=0
- Added debug logging for DTD_amount, D28_amount, D29_amount values
- Added debug logging for all D-section field values being sent to PDF
- This will help identify why lines 28 and 29 are not displaying in PDF
- Debug will show if the values are being extracted correctly and what's being sent to PDF
- Added debug logging to see D28_amount and D29_amount values
- This will help identify why lines 28 and 29 are not displaying in PDF
- Debug will show if the values are being extracted correctly from ca3_data
- Changed from 3 spaces after first 2 chars to 2 extra spaces
- Changed from 43 spaces after first 4 chars to 2 extra spaces
- Updated method documentation to reflect correct spacing
- Example: FR85489417469 → F R 8 5 4 8 9 4 1 7 4 6 9 (with 2 extra spaces after positions 1 and 3)
- Added formatVatNumber() method for special VAT number formatting
- Space between every character
- 3 extra spaces after first 2 characters
- 43 extra spaces after first 4 characters
- Example: FR85489417469 → F R 8 5 4 8 9 4 1 7 4 6 9
- Handles edge cases like empty or short VAT numbers
- Cleans input by removing non-alphanumeric characters and converting to uppercase
- Changed from 4 total spaces to 3 spaces before last 5 characters
- Updated method documentation to reflect the change
- Example: 48941746900033 → 4 8 9 4 1 7 4 6 9 0 0 0 3 3 (with 3 spaces before last 5)
- Changed from 2 extra spaces to 4 total spaces before last 5 characters
- Updated method documentation to reflect the change
- Example: 48941746900033 → 4 8 9 4 1 7 4 6 9 0 0 0 3 3 (with 4 spaces before last 5)
- Changed from 1 extra space to 2 extra spaces before last 5 characters
- Updated method documentation to reflect the change
- Example: 48941746900033 → 4 8 9 4 1 7 4 6 9 0 0 0 3 3 (with 2 spaces before last 5)
- Added formatSiret() method for special SIRET formatting
- Spaces between every character in main part
- Extra space before last 5 characters
- Example: 48941746900033 → 4 8 9 4 1 7 4 6 9 0 0 0 3 3
- Handles edge cases like SIRET_NOT_CONFIGURED
- Cleans input by removing non-numeric characters
- Removed duplicate F1/F2 field mappings that were overwriting correct values
- Updated all remaining fields to use getCA3LineAmount() helper method
- Fixed D25, D26, DTD, D28, D29, subtotal_B16, subtotal_C23 fields
- All fields now consistently use the correct array structure lookup
- F2 should now display correct amount instead of 0,00
- Updated formatAmount() method to use 0 decimal places instead of 2
- All amounts in PDF will now display as whole numbers (e.g., 1 958 instead of 1 958,00)
- Maintains French number formatting with comma as decimal separator and space as thousands separator
- Added getCA3LineAmount() helper method to search through numeric array
- Updated all field mappings to use the new helper method
- Fixed A1_amount and other fields to correctly extract from ca3_data array
- The data structure is numeric array with ca3_line field, not associative
- Now correctly extracts A1 amount (1958.00) from the data structure
- Added detailed logging to see what's actually in ca3_data['A1']
- This will help identify why A1_amount shows 0,00 in PDF
- Debug will show if A1 exists and what data it contains
- Every field that shows on the view page should also show on the PDF
- Restored A1-A5 field mapping with proper amount extraction
- Added all Section A additional fields: E1-E6, F1-F2, F6-F8
- Updated debug logging to show actual field values
- Enhanced manual data file generation to include all fields
- PDF now mirrors the complete view page structure
- A1-A5 fields are reference only and don't have actual amounts
- Real amounts come from B section calculation fields (B08, B09, 9B, etc.)
- Updated field mapping to correctly show 0,00 for reference fields
- Enhanced debug logging to reflect correct data structure
- Updated manual data file generation with proper field descriptions
