Fix VAT calculation and validation issues

[fank]

Summary

This PR fixes two critical issues identified during a comprehensive codebase review:

1. Missing rounding in VAT category basis validations (4 files)
2. Redundant BR-CO-19/BR-CO-20 validation logic

Both issues have been fixed with comprehensive test coverage and no regressions.

---

Missing Rounding in VAT Category Basis Validations

Problem

Four VAT category validation files were missing .Round(2) calls when calculating expected basis amounts for comparison with TradeTax.BasisAmount. This caused false violations when invoice line totals had more than 2 decimal places.

Root cause: The UpdateApplicableTradeTax() function rounds BasisAmount to 2 decimals (line 79 in calculate.go), but the validation logic in four category files calculated unrounded expected values for comparison, leading to mismatches like:

• Stored value: 100.00 (rounded)
• Calculated value: 100.001 (unrounded)
• Result: False violation triggered

Affected Business Rules

• BR-IC-06, BR-IC-08 (Intracommunity supply - category K)
• BR-O-09, BR-O-10 (Not subject to VAT - category O)
• BR-AF-05, BR-AF-07 (IGIC Canary Islands - category L)
• BR-AG-05, BR-AG-07 (IPSI Ceuta/Melilla - category M)

Files Fixed

Added .Round(2) to expected basis calculations:

• check_vat_intracommunity.go: Lines 124, 161
• check_vat_notsubject.go: Lines 168, 197
• check_vat_igic.go: Lines 81, 121
• check_vat_ipsi.go: Lines 82, 122

This aligns with existing implementations in:

• ✓ check_vat_exempt.go (already had rounding)
• ✓ check_vat_reverse.go (already had rounding)
• ✓ check_vat_zero.go (already had rounding)
• ✓ check_vat_export.go (already had rounding)
• ✓ check_vat_standard.go (already had rounding)

Example Fix

Before (check_vat_intracommunity.go:124):

expectedBasis := lineTotal.Sub(allowanceTotal).Add(chargeTotal)

After:

expectedBasis := lineTotal.Sub(allowanceTotal).Add(chargeTotal).Round(2)

---

Redundant BR-CO-19/BR-CO-20 Validation Logic

Problem

The validation logic for BR-CO-19 (invoice period) and BR-CO-20 (invoice line period) contained logically impossible nested conditions:

if !start.IsZero() || !end.IsZero() {  // "If at least one date is set..."
    if start.IsZero() && end.IsZero() {  // "...check if both are zero"
        violation
    }
}

The inner condition can never be true if the outer condition is true.

Root Cause

The rules state: "If INVOICING PERIOD (BG-14) is used, at least one date must be filled."

However:

1. The Go struct has no way to distinguish "BG-14 not present in XML" from "BG-14 present with zero dates"
2. The writer only outputs BG-14 when at least one date exists (correct behavior)
3. The outer if already ensures the rule is satisfied

Solution

Removed the redundant validation logic and added clarifying comments explaining why the rules are satisfied by construction. The writer ensures compliance by only writing the groups when at least one date exists.

File: check.go (lines 156-166)

---

Testing

Created comprehensive test suite in critical_issues_test.go:

C1 Tests (7 tests)

• ✓ TestC1_MissingRoundingInVATExempt - Category E (already had rounding, baseline)
• ✓ TestC1_MissingRoundingInVATReverseCharge - Category AE (already had rounding, baseline)
• ✓ TestC1_MissingRoundingInVATZeroRated - Category Z (already had rounding, baseline)
• ✓ TestC1_MissingRoundingInVATIntracommunity - Category K (fixed)
• ✓ TestC1_MissingRoundingInVATNotSubject - Category O (fixed)
• ✓ TestC1_MissingRoundingInVATIGIC - Category L (fixed)
• ✓ TestC1_MissingRoundingInVATIPSI - Category M (fixed)
• ✓ TestC1_AllVATCategoriesWithDocumentLevelAllowances - Integration test

C2 Tests (2 tests)

• ✓ TestC2_BRCO19_LogicError - Invoice period validation (3 subtests)
• ✓ TestC2_BRCO20_LogicError - Invoice line period validation (2 subtests)

Test Strategy

1. Before fix: Tests used values that sum to exactly 100.000 → rounded to 100.00 → no violation (bug not exposed)
2. After investigation: Updated test values to sum to 100.001 → rounds to 100.00 → would trigger false violation without fix
3. After fix: Tests verify that specific violations (BR-IC-06, BR-O-09, etc.) are not triggered

Test Results

$ go test
PASS
ok      github.com/speedata/einvoice    0.015s

All 223 tests pass with no regressions.

---

Changes Summary

• 6 files changed: 807 insertions(+), 20 deletions(-)
• New file: critical_issues_test.go (642 lines)
• Modified files:
  • check.go: Removed redundant validation logic
  • check_vat_intracommunity.go: Added rounding (2 locations)
  • check_vat_notsubject.go: Added rounding (2 locations)
  • check_vat_igic.go: Added rounding (2 locations)
  • check_vat_ipsi.go: Added rounding (2 locations)

---

Compliance

These fixes ensure strict compliance with:

• EN 16931 standard for electronic invoicing
• BR-DEC-19: VAT category taxable amount must have max 2 decimal places
• BR-IC-06, BR-IC-08: Intracommunity supply validation rules
• BR-O-09, BR-O-10: Not subject to VAT validation rules
• BR-AF-05, BR-AF-07: IGIC validation rules
• BR-AG-05, BR-AG-07: IPSI validation rules

---

Checklist

• All tests pass
• No regressions in existing functionality
• Comprehensive test coverage for both fixes
• Fixes align with existing patterns in codebase
• Comments added explaining C2 logic removal
• Commit message follows project conventions