Slovenia - Davcna Blagajna

Language / Jezik: English | Slovenščina

This addon provides an Odoo 18 integration with the Slovenian FURS/eDavki fiscal invoice confirmation system (davcna blagajna) using the JSON/JWS protocol.

Current addon version: 18.0.1.0.0. Documentation checked against the working tree on October 9, 2026. Fiscal confirmation is separate from e-SLOG exchange.

See the illustrated user manual for step-by-step configuration, daily operations, recovery, and current UI limitations.

Features

FURS configuration per company and environment (test/production).
Fiscal certificate handling (PKCS#12) with validity checks.
Response-signature verification (off/warn/strict) with response certificates.
Business premise registration (single and batch).
Fiscal devices with journal/payment mappings and numbering validation.
Invoice and refund fiscalization with JSON/JWS signing.
ZOI/EOR storage with QR/report integration.
Manual fiscalization and auto fiscalization on post or payment.
FURS message audit logs with route/endpoint, hashes, and transport metadata.
Retry/backoff scheduling with optional queue_job async processing.
Retryability semantics aligned to final message state (accepted/rejected clear schedules).
Batch submission for invoices and premises with record mapping.
Backfill finder wizard and persistent recovery run tracking.
Recovery run lines capture explicit outcomes (result state, timestamps, EOR/ZOI, errors).
Multi-company isolation with manager/operator/auditor roles.

Dependencies

Odoo: account, mail, l10n_si2.
Python: cryptography, requests.
Optional: queue_job if installed/enabled.

Security

FURS Configuration Manager: full configuration access and certificate management. This group includes FURS Manager; the base manager group alone does not grant the configuration model's ACLs or certificate field access.
FURS Operator: fiscalization, retry/recovery, and premise/device operations.
FURS Auditor: read-only access to audit logs and recovery runs.

Certificate attachment and password fields are restricted to FURS Configuration Manager access. Multi-company record rules prevent cross-company visibility.

The Configuration Manager role does not imply the Operator role. Assign FURS Operator as well when a configuration manager must use the operator-only premise registration or recovery/backfill wizards. The auditor ACLs include recovery runs, but the supplied Recovery Runs menu is visible only to operators and configuration managers. Accounting users inherit the auditor role.

Configuration

Company setup: confirm the company VAT and Slovenian localization settings.
Environment: select test or production environment in FURS Configuration.
Fiscal certificate: upload the PKCS#12 certificate and set the password.
Response certificate: upload the FURS response signing certificate when verification is enabled.
Supplier tax number: set the supplier tax number (VAT without the SI prefix).
Business premises: create at least one premise and register it with the official ID.
Fiscal devices: link devices to journals and premises; set electronic device IDs.
Numbering validation mode: choose warn or strict numbering validation per device.

Open configuration, premises, and devices under Accounting → Configuration → Slovenia FURS. Messages, failed fiscalizations, and recovery actions are under Accounting → Reporting → Slovenia FURS, with visibility controlled by the roles above.

The current configuration action has an undefined company_id context value; several list actions still request tree rather than Odoo 18 list. These defined menu paths are therefore not all usable as shipped. See the manual's navigation blockers and the TODO section before operational use.

New configurations default to the test environment, a 30-second timeout, disabled automatic fiscalization, and disabled response-signature verification. Enable verification and select Warn or Strict deliberately: Warn records verification errors and continues processing; Strict blocks acceptance when verification fails. Device numbering validation defaults to Warn.

Invoice configuration selection honors the furs_environment context when provided; otherwise it prefers an active production configuration over test. Creating a test configuration does not force invoices to use it while an active production configuration also exists.

FURS test environment setup

The configuration form exposes Test and Production, the selected API URLs, and links to the test invoice and premise verification portals. Test is the default. The URLs are read-only and follow the selected environment.

FURS uses certificate authentication (mutual TLS) and signed JSON messages, not an API username/password login. There is no shared test user or test password to bundle with this addon. Certificate Password is the password for your own PKCS#12 file; obtain it with the certificate from its issuer. Browser eDavki or miniBlagajna accounts are separate from this integration.

Request a developer test certificate from sd.fu@gov.si. State the name of the company developing the solution. FURS supplies a .p12 issued for an anonymized test identity with a randomly assigned tax number.
In a separate test database, create a FURS configuration with Environment = Test. Upload that file under Fiscal Certificate and enter its password. Use its assigned tax number in Supplier Tax Number; this overrides company VAT for invoice, premise, and ZOI generation.
Download DavPotRacTEST.cer from the official FURS developer page. Upload it under Response Certificate, enable signature verification, and select Strict to exercise response verification. The TLS server certificate and this response signing certificate serve different purposes.
Ensure the Odoo host trusts the current SIGOV-CA/SI-TRUST certificate chain listed on that page and can reach TCP port 9002. TLS certificate verification remains enabled; do not disable it to bypass trust errors.
Use Test Connection for an echo check, then register a test business premise, configure a device, and fiscalize a sample invoice. Echo alone does not validate invoice contents, numbering, or premise registration.
Check submitted records using the portals below, with the assigned test tax number and the invoice/premise identifiers requested by the portal.

Test service and portal URLs (FURS technical specification v3.2, section 6.1):

Invoice JSON API: https://blagajne-test.fu.gov.si:9002/v1/cash_registers/invoices
Premise JSON API: https://blagajne-test.fu.gov.si:9002/v1/cash_registers/invoices/register
Echo JSON API: https://blagajne-test.fu.gov.si:9002/v1/cash_registers/echo
Invoice verification: https://blagajne-test.fu.gov.si:9002/cash_registers/ui/check_invoice/index.html
Premise verification: https://blagajne-test.fu.gov.si:9002/cash_registers/ui/check_premise/index.html

Before going live, use the production database with Environment = Production, a production fiscal certificate/password, the real taxpayer number, and the current production response signing certificate (DavPotRac). Production uses https://blagajne.fu.gov.si:9003 with the same API paths. Register the production premises separately. Test certificates cannot be used in production and production certificates cannot be used in test.

Keep test fiscalizations in the test database: an invoice accepted in test is already marked accepted by this addon and is not automatically resubmitted when switching environments. Switching a configuration also affects subsequent requests that use it, including retries. Use separate configurations/databases instead of repurposing a configuration with existing messages.

Sources checked on October 3, 2026: the official developer page linked above and FURS technical specification v3.2 (March 23, 2026), sections 2, 2.3, and 6.1. FURS recommends at least two days of stable test operation before moving to production. Certificates can rotate; obtain current public certificates from FURS rather than bundling them or private credentials.

Fiscalization workflows

Manual invoice fiscalization via Fiscalize Now.
Auto-on-post when enabled on the selected device or configuration.
Payment-trigger evaluation when payment_state is written, using reconciled payment journals/methods and the device or configuration's automatic setting.
Refunds (credit notes) are supported.
Accepted responses store EOR and update invoice state.
Rejected/error responses remain visible with error codes/messages.

Eligibility requires a posted customer invoice or refund, a Slovenian company, an active FURS configuration, and a ready device and premise. Already accepted invoices are not submitted again. Automatic paths record caught user errors in chatter; inspect the fiscal state and message outcome after posting or payment.

The payment hook depends on an explicit ORM write containing payment_state; it is not a reconciliation callback. A computed payment-state change alone does not prove that this hook ran. A matching fiscal payment journal or method can qualify partial or mixed payments; qualification is not limited to fully paid invoices. Review the recorded trigger and fiscal result in the actual payment workflow.

Batch and recovery

Batch invoice and premise actions submit grouped records and map individual replies to their invoices or premises.
Recovery runs can plan and execute single or batch re-submissions.
Backfill wizard supports dry-run planning and opens eligible records.
A completed recovery run records processing outcomes; acceptance must be checked on each line rather than inferred from submission alone.

Automatic message retries apply to timeout, connection, and HTTP 5xx failures, subject to the retry limit and due time. Backoff delays are 5, 15, 60, and then 1440 minutes. The supplied retry scheduled action runs every 15 minutes, so a due time is not an exact execution time. Accepted and rejected outcomes clear the retry schedule.

Recovery workflow

Recovery is designed for auditing and controlled re-submission:

Use the backfill wizard to filter invoices/messages by date, device, premise, and retry limits, then create a recovery run.
Recovery runs record every selected line, skipped reason, and resulting message for auditability, including explicit per-line result states and timestamps.
Submission mode can be dry_run (plan only), single (per record), or batch (grouped by config/device/premise).
Accepted records are skipped; non-retryable messages are preserved with a clear reason.
Results update counts (accepted/rejected/failed/skipped) and are visible to operators and auditors, including mixed outcomes for partial batch replies.

Live FURS tests

Live tests are skipped by default. The current test gate accepts any nonempty L10N_SI_FURS_LIVE_TESTS value, including 0; leave it unset to disable external calls and set it to 1 deliberately to opt in. These tests make requests to the FURS test service, including premise and invoice submissions.

Environment variables used across the live tests:

L10N_SI_FURS_LIVE_TESTS=1
L10N_SI_FURS_CERT_PATH=/path/to/test-certificate.p12
L10N_SI_FURS_CERT_PASSWORD=...
L10N_SI_FURS_RESPONSE_CERT_PATH=/path/to/furs-response-cert.pem
L10N_SI_FURS_SUPPLIER_TAX_NUMBER=...
L10N_SI_FURS_COMPANY_VAT=...
L10N_SI_FURS_PREMISE_ID=...
L10N_SI_FURS_DEVICE_ID=...

Each test checks its own required subset. Echo needs the fiscal certificate, password, and supplier tax number; invoice tests additionally require premise and device identifiers. Company VAT is an optional override. The response certificate is needed for the signature-verification case, not every live test.

Never commit credentials or certificates.

Developer validation

Each Python class has its own source file, including service exceptions and test doubles. Test files use the source basename (for example, test_furs_config.py covers models/furs_config.py); scenario suffixes separate batch, security, and optional live-service cases. Reusable doubles live under tests/doubles/. Recovery run and recovery line models and tests are maintained separately.

Methods document their purpose and relevant state transitions. Inline comments explain batch reply mapping, preserved audit history, temporary TLS files, and optional queue hooks. Narrow inspection annotations preserve intentional Odoo extension points and dynamically supplied methods; they do not disable checks for the addon as a whole.

Run the configured Ruff checks and PyCharm inspections across the addon, plus the PMIVerse run_lint_addon.sh --addon <addon-path> --check runner. Run run_pytest_repo.sh --addons <addon-path> for scoped database-backed coverage, using --cov-branch to detect untested decisions as well as missing lines. Keep live FURS tests disabled unless their external calls are explicitly intended.

Known limitations

Some menu actions and legacy visibility modifiers are incompatible with Odoo 18. Server eligibility checks remain necessary even when a button is visible.
Device sequences validate prefix/suffix only; they do not generate invoice numbers or establish gap-free/legal numbering.
Refund submission uses absolute amounts and does not include an original-invoice reference. Operator and software-supplier tax numbers use the configured supplier number; there is no separate cashier/software-vendor identity setting.
Tax payloads aggregate posted tax lines by their numeric rate using absolute bases and balances. UNECE categories and e-SLOG clauses are not mapped into this payload. Validate exemptions, reverse charges, and nonstandard tax setups.
Request timestamps use the submitting user's context time zone. Configure Europe/Ljubljana for the intended Slovenian workflow and verify queued users too.
Accepted messages are protected from non-manager edits, not immutable for Configuration Managers or superusers. A manual transport error can roll back local audit-message creation; inspect persisted evidence after failures.
Configuration uniqueness also limits archived records per company/environment. An accepted Test invoice is not automatically submitted to Production later.
Batch behavior must be validated against the latest deployed FURS specification.
Live tests require FURS test credentials/certificates.
Queue processing is optional.
Production deployments must choose a response-signature policy and load the correct response certificate.

TODO

Correct configuration action context, legacy list action types, and visibility modifiers; verify menu and button behavior for each role.
Validate or replace the explicit payment_state write hook for the actual reconciliation workflow before relying on automatic payment fiscalization.
Establish complete refund/correction payloads and separate operator/software supplier identities for the intended production use.
Validate batch wrappers, live FURS exchange, reports, retries, and recovery with the intended certificates and business scenarios before production acceptance.

Production readiness checklist

Test certificate validated.
Premise registered in test environment.
Sample invoice fiscalized in test environment.
Response certificate loaded if strict verification is enabled.
Numbering policy approved.
Payment trigger policy approved.
Backup/recovery process tested.

Bug Tracker

Bugs are tracked on PMISuite Repository Issues. Before opening a new issue, check whether it has already been reported. Include the module and Odoo versions, steps to reproduce, and expected and actual results. Use synthetic examples and redact sensitive information.