PMISuite Beta — Developer Guide

For addon selection, setup, and user documentation, start with the repository landing page.

Source and documentation

The addons target Odoo 18 Community. Each manifest owns its dependencies and license. pyproject.toml configures Ruff for Python 3.12 and a 100-character line limit. Model and wizard filenames follow their full technical model names; separate extensions use descriptive suffixes. Model-specific XML files use the corresponding model prefix.

README bodies and localized companions are maintained directly. Keep public overviews and user manuals focused on current behavior, setup, workflows, and limitations. Put pending implementation in addon docs/todo.md files and delivered-code history in dedicated changelogs. Keep test instructions and evidence outside those product documents. The repository badges are maintained by the workspace badge publisher; documentation edits do not regenerate them.

Scoped checks

pytest.ini and conftest.py configure the repository suites. Addon tests live under each addon's tests/ directory. Test filenames mirror their source modules, with scenario suffixes where useful.

From the repository root in a configured PMIVerse workspace, use the existing runners with the scope limited to the affected addon. Replace the addon and database name with the intended addon and a collision-free, task-owned disposable target:

/srv/pmiverse/_pmiconfig/scripts/test/run_pytest_addon.sh \
  -a pmis_nextcloud/tests -d test_unique_task -- -q

For scoped statement/branch coverage:

/srv/pmiverse/_pmiconfig/scripts/test/run_pytest_repo.sh \
  --addons pmis_nextcloud --db-prefix test_unique_task_ --parallel 1 -- \
  -q --cov-branch --cov-fail-under=100

Use run_lint_addon.sh --addon <addon-path> --check for nonwriting static checks. Verify database ownership and runner connection before reuse or cleanup. A test_ prefix alone does not establish ownership. Do not target business databases. Runners can create/drop disposable databases and write logs and filestore data. Documentation-only edits do not require database-backed tests.

Addon test boundaries

• Nextcloud: client/account and CardDAV suites use synthetic responses; the HOOT suite tagged pmis_nextcloud_password uses mocked RPC services. These suites do not certify a particular remote server deployment.
• AI operator: deterministic tests use synthetic provider responses and ordinary-user Odoo execution. tests/odoo_dependencies.txt declares CRM, Sales, and Website as test-only applications. Concurrency tests commit synthetic fixtures, making an isolated disposable database essential. These apps remain optional in production.
• FURS: deterministic tests and optional live-service tests are separate. Live checks perform external writes; use the controls below deliberately.
• e-SLOG and UNECE: parser/generator and tax-mapping tests cover specific supported cases. Structural XSD checks do not establish recipient business acceptance or every statutory scenario.

Optional FURS service tests

Live tests are skipped when L10N_SI_FURS_LIVE_TESTS is unset. The current gate accepts any nonempty value, including 0. Set it to 1 only for explicitly authorized FURS test-service calls. Requests include business-premise registration and invoice submissions.

Each test requires its own subset of these environment variables:

Echo requires the fiscal certificate, password, and supplier tax number. Invoice cases also require premise/device identifiers. Never commit credentials or certificate material.

e-SLOG reference-file maintenance

XML examples and XSDs in l10n_si_einvoice/docs/official are reference inputs. Preserve their content, unused namespace declarations, and the XML Signature schema's original DOCTYPE. Narrow nonfunctional inspection suppressions may be used where necessary; IDE warnings do not justify changing the reference schema.

PyCharm's Xerces validator can report a namespace declaration in the XML Signature DTD prolog that tag-level suppression does not silence. Runtime XSD validation remains enabled. Each example under primeri_davcne_kode has schema/parser cases; keep their inventory and category/rate expectations aligned when changing examples.

Receiver-specific semantic rules, delivery, and business acceptance need the receiving system's agreed integration contract. Preserve the distinction between local generation, transport status, and recipient acceptance.

Implementation follow-ups

• AI operator
• FURS fiscal confirmation

For screenshots, use synthetic records, redact sensitive information, and disclose simulated service outcomes. The AI manual's image notes document its capture provenance.