Bug: Period conflict error when using default/last period - affects both Homebrew and Cargo installations

[o-vuong]

🐛 Bug Report

Problem

Both Homebrew and Cargo installations of klirr fail with a period conflict error when using the default period ("Last") or explicitly specifying --period last.

Error Message

Error creating PDF: Start period ('2025-07-second-half') is after end period ('2025-07-first-half')

Code Logic Issue

The bug appears to be in the period calculation logic where:

1. The system correctly identifies the target period as 2025-07-first-half (which should be the "last" period)
2. But internally during validation, it's comparing against 2025-07-second-half (current period) as the "start period"
3. This creates a logical conflict because 2025-07-second-half > 2025-07-first-half

The issue suggests the validation logic is incorrectly treating the current period as the start period when it should be validating against the target period.

Reproduction Steps

❌ FAILS - Default period (both versions):

# Homebrew v0.2.0
/opt/homebrew/bin/klirr invoice services
# Result: period: 2025-07-first-half, ERROR: Start period ('2025-07-second-half') is after end period ('2025-07-first-half')

# Cargo v0.2.1  
/Users/oscar/.cargo/bin/klirr invoice services
# Result: period: 2025-07-first-half, ERROR: Start period ('2025-07-second-half') is after end period ('2025-07-first-half')

❌ FAILS - Explicit last period (both versions):

# Homebrew v0.2.0
/opt/homebrew/bin/klirr invoice --period last services
# Result: Same error

# Cargo v0.2.1
/Users/oscar/.cargo/bin/klirr invoice --period last services  
# Result: Same error

✅ WORKS - Current period (both versions):

# Homebrew v0.2.0
/opt/homebrew/bin/klirr invoice --period current services
# Result: period: 2025-07-second-half, SUCCESS

# Cargo v0.2.1
/Users/oscar/.cargo/bin/klirr invoice --period current services
# Result: period: 2025-07-second-half, SUCCESS

Environment Details

• klirr versions:
  • Homebrew: 0.2.0 (/opt/homebrew/bin/klirr)
  • Cargo: 0.2.1 (/Users/oscar/.cargo/bin/klirr)
• OS: macOS ARM64
• Test date: July 24, 2025 (second half of month)
• Bug confirmed: Both installations affected identically

Root Cause Analysis

The bug appears to be in the period validation logic where:

1. period: 2025-07-first-half is correctly calculated as the target "last" period
2. During PDF generation, the validation incorrectly uses 2025-07-second-half as a "start period"
3. The comparison '2025-07-second-half' > '2025-07-first-half' triggers the error

The validation should either:

• Use the target period (2025-07-first-half) as both start and end
• Or properly calculate the date range for the target period without comparing against current period

Temporary Workaround

Use --period current instead of default/last period.

[Sajjon]

Thx, I will take a look!

[Sajjon]

@o-vuong What did you put in invoice_info.ron?

 cat ~/Library/Application\ Support/klirr/data/invoice_info.ron
ProtoInvoiceInfo(
    offset: TimestampedInvoiceNumber(
        offset: 1000,
        period: "2025-04-second-half",
    ),
    record_of_periods_off: RecordOfPeriodsOff([
        "2025-06-first-half",
        "2025-06-second-half",
    ]),
    purchase_order: Some("PO-12345"),
    footer_text: Some("Reverse VAT according to chapter 1 2§ first section 4b in the VAT regulation."),
    emphasize_color_hex: Some("#8b008b"),
)

I suspect you might have:

ProtoInvoiceInfo(
    offset: TimestampedInvoiceNumber(
        offset: 1000,
        period: "2025-07-second-half",
    ),

in invoice_info.ron?

[Sajjon]

right so, when one runs klirr data init I incorrectly default to current period instead of last for offset.