REPROCESS_PRODUCTS is not in SYNC_JOB_KINDS, so it fell to the else branch of execute_job and hardcoded company=None for _unified_fiscal - a real gap, not a missing feature: the same deterministic, fail-closed company_context.resolve() every sync job already uses is cheap (no full-table scan, confirmed against the real database) and applies just as well to a one-off reprocess job. Now resolves the real company the same way; falls back to None only when the company genuinely cannot be resolved yet, never a silent guess. Does not touch RTC rule logic. Verified end-to-end against the real production database (dry-run, zero writes) that this was the last domain still carrying the old bug - field_contract's post-NCM fiscal completion already bypassed it entirely by reading Installation.company_uf/crt/company_contribuinte_ipi directly (populated via the 1.3.7 heartbeat fix). 1123 tests passed (tests + central/tests + agent/tests), 0 failed. Version 1.3.8 (single GTI_FISCAL_VERSION).
9 lines
575 B
Python
9 lines
575 B
Python
"""Single source of truth for the release version. Also what the Agent Windows
|
|
package is versioned as (scripts/build_agent_package.py reads release/VERSION,
|
|
kept identical to this) and what an AgentRelease row's `version` column holds
|
|
once published — never a second, independent version number. Fiscal semantics
|
|
are versioned separately (ENGINE_VERSION/DECISION_VERSION in classification.py,
|
|
DECISION_ENGINE_VERSION etc.) and are NOT changed by a release bump."""
|
|
GTI_FISCAL_VERSION = "1.3.8"
|
|
API_COMPAT_MAJOR_MINOR = "1.0" # an Agent 1.0.x/1.1.x talks to any Hub 1.0.x
|