Preskoči na vsebino

Fiscal-date validation guide

This is a current verification guide, not a record of a test run or a migration success certificate. Earlier iteration counts and old private Python paths are not acceptance evidence for the current checkout. Retain actual runner logs outside user documentation and associate them with the tested revision.

Source and test map

  • pmis_account_dates/models/ and wizard/ implement permanent accounting date roles, posted fixation, manager decisions, tax synchronization, and locks.

  • pmis_stock_move_fiscal_month/models/ implements stock instructions and company-aware period classification.

  • pmis_stock_account/models/stock_valuation_layer.py implements permanent valuation date authority and independent date-write protection.

  • Temporary runtime helpers, models, and audit/review wizard Python are under the owning addons' fiscal_migration/ packages. Odoo-discovered versioned scripts remain in migrations/18.0.2.0.0/.

  • Migration regressions and upgrade_fiscal_registry.py are under tests/fiscal_migration/. Ordinary behavior tests remain under tests/. The accounting-date tests/fiscal_date_browser.py supplies native browser acceptance for the exception-return/retry workflow.

Read the repository retirement contract at docs/fiscal_migration.md before changing these boundaries. Model/field/XML IDs and manifest versions are not private implementation details.

Deterministic acceptance

Use the configured interpreter and repository-owned runners on collision-checked, task-owned disposable test databases only. Do not target a production-derived restore with these commands. From the repository root:

/srv/pmiverse/_pmiconfig/scripts/test/run_pytest_repo.sh \
    --addons "$PWD/pmis_account_dates" \
    "$PWD/pmis_stock_move_fiscal_month" "$PWD/pmis_stock_account" \
    "$PWD/pmis_stock_reconcile" "$PWD/pmis_account_financial_report" \
    --db-prefix test_fiscal_acceptance_ --parallel 2 -- -q --maxfail=1

Choose a task-specific unused prefix; a test_ name alone does not prove ownership. Read the runner summary, JUnit, and coverage XML. A rounded 100% display is not proof that every statement is covered. Do not publish badges from a partial run. Check applicable Ruff, formatting, lint, and IDE diagnostics separately; a successful test run does not prove zero IDE warnings.

The historical registry rehearsal must exercise the actual old-field schema and versioned entrypoints, verify protected financial periods/amounts and stock authority, and repeat the upgrade to prove retry safety. Follow the current tests/fiscal_migration/upgrade_fiscal_registry.py guard and invocation contract; do not bypass its owned-database safeguards or infer preservation from a fresh install.

Business acceptance after an approved restore/upgrade

  1. Before resuming transactions, inspect all three review lists for each company, including queued/failed/unclassified records. A zero visible count is insufficient.

  2. Run Fiscal Migration Audit for the full intended company scope. Require sealed preservation evidence for entries, items, and valuation layers, plus zero live exceptions. Missing original evidence cannot be recreated afterward.

  3. Distinguish a sealed migration result from Changed since upgrade, which can reflect subsequent legitimate transactions. Investigate without rewriting evidence.

  4. Compare posted fiscal inventory-account balances to fiscal-date valuation with matching company, currency, cutoff, accounts, and posting scope.

  5. Inspect representative same-period accounting dates, overridden periods, primary stock layers, later zero-quantity adjustments, unlinked layers, canceled sources, and genuinely conflicting primary periods.

  6. Check normal manager correction, source edits leaving posted recognition fixed, old/new lock intervals, company isolation, and exception expiry/return behavior.

Runtime and visual boundaries

Use fictional records for manual screenshots. Capture the actual current Odoo interface in each language; do not edit labels or amounts into an image. A fresh installation showing Missing evidence illustrates the audit control, not a successful historical upgrade. A rendered HTML report does not prove PDF pagination, binary export fidelity, VAT policy, or historical FIFO reconstruction. Document those checks separately when performed; never infer them from coverage.