Odoo on Lessons learned

A read with legal effect: listing ISDS messages counts as delivery

Sun, 13 Sep 2026 14:09:00 +0200

Polling an inbox from a cron job looks harmless, since reading has no side effects. In the Czech Data Box system (ISDS, datové schránky) it does: the moment an authorized person logs in to the box is the moment every message waiting in it is legally delivered (doručení). An application counts as that person when it logs in and fetches the list of received messages. A 3 a.m. retrieval of a tax office’s request starts the deadline to answer it, whether anyone reads the message or not.

If your code talks to ISDS, every scheduled retrieval and every copy of your database that still holds the box’s password is a legal act.

Setup

An Odoo 18 addon files incoming Data Box messages into the company’s document store (the OCA dms addon). It talks to ISDS over SOAP with zeep (the parsing bug from that client is here ). A retrieval calls GetListOfReceivedMessages for the last 100 days and downloads each new message with its signed copy.

A possible next feature was a cron job, so that the documents appear without anyone pressing a button.

Why a read starts a deadline

Act No. 300/2008 Sb. delivers a message in one of two ways. Under § 17(3), it is delivered when a person whose permissions cover it logs in to the box. Under § 17(4), if nobody logs in within 10 days of the message’s arrival, it counts as delivered on the last day of that period, which Czech lawyers call delivery by fiction.

People rely on fiction as a buffer. A box that nobody opens for a week gives you up to 10 extra days before a deadline starts running. A nightly cron throws that buffer away. Every message is delivered the night after it arrives, and its deadline starts then, while the documents sit unread in a folder.

Not every call has this effect. GetOwnerInfoFromLogin checks the credentials and returns the box ID and owner without causing delivery. The addon uses it to validate a login before it creates anything.

The design

Once the domain model had the rule written down (“Every Retrieval causes Delivery of the Messages waiting in the box”), the decisions followed from it:

Each connection has a Retrieval Mode, On demand or Scheduled, and On demand is the default.
The “Check data box” button asks for confirmation: “Checking the data box counts as Delivery (doručení) of every Message waiting in it, which starts legal deadlines. Continue?”
Choosing Scheduled shows a warning, and the form keeps showing it for as long as the connection stays Scheduled. The daily cron job skips On demand connections.
The one-step setup wizard says that its first retrieval counts as delivery.

Copies of the production database

The usual way to get a realistic test environment for Odoo is to restore a production backup. That copy holds the ISDS username and password, and possibly a scheduled connection. A staging server that runs the cron, or a developer who presses “Check data box” to see what it does, delivers the production company’s official mail.

Odoo has a hook for this. When you run odoo-bin neutralize, or restore a database with Neutralize checked in the database manager, it runs each installed module’s data/neutralize.sql. Core modules use it to switch off outgoing mail and crons. The ISDS addon adds its own:

-- a neutralized copy must never cause Delivery: drop the Credential passwords
-- and stop Scheduled Retrievals
UPDATE dms_isds_connection
 SET password = NULL,
 retrieval_mode = 'on_demand';

-- unfinished Quick Starts hold a password too, and connecting retrieves at once
DELETE FROM dms_isds_quick_start;

A retrieval on a neutralized copy fails on the missing password before it contacts ISDS. The test checks exactly that. It runs the module’s neutralization queries, presses the button, triggers the cron, and asserts that the ISDS listing was never called:

self._neutralize()

with self.assertRaisesRegex(UserError, "password"):
 self.connection.action_check_data_box()
self.env.ref(CRON).method_direct_trigger()

listing.assert_not_called()

The development setup restores production data and neutralizes it on every refresh, so nobody has to remember.

Neutralization changes only the copy. The original backup still holds the password in plaintext, so restrict access to backups and encrypt them.

Takeaway

Before you schedule a “read-only” integration, find out what reading does on the other side. In ISDS, it is legal delivery, so the integration retrieves on demand by default, and a restored database can’t log in.

List the integrations in your own staging setup that still hold production credentials, and check whether any of their reads change something for someone else.

Uninstalling one Odoo module can remove its dependents and their data

Sun, 30 Aug 2026 00:00:00 +0000

An Odoo module replacement passed a rehearsal’s record-count and accounting-total checks, yet the uninstall also removed a dependent addon that owned important business data. The application still loaded. The acceptance checks had missed the field that mattered.

Before replacing a module, inspect its reverse dependencies and data ownership. Rehearse the corrected transition on a restored copy, then compare the affected values by record identity before approving the live change.

Uninstall computes a reverse-dependency set

In Odoo 18’s module implementation , downstream_dependencies() recursively finds modules that depend on the selected modules. button_uninstall() marks both the selection and those dependents as to remove.

The same source describes module_uninstall() as removing database structures created by the module, including tables and columns. Actual deletion depends on the affected records and metadata; do not assume every business record disappears, or that surviving rows retain every field.

Generalize the replacement to a full addon, a smaller replacement, and an extension that depends on the full addon. Installing the smaller addon does not automatically redirect the extension’s dependency. Uninstalling the full addon still includes that extension in the removal set.

The first rehearsal had the wrong acceptance criteria

The historical transition checked surviving records, aggregate totals, and registry health. Those checks passed while the dependent addon was also uninstalled. The user caught the missing preservation requirement and required a restore.

The subsequent investigation found a second problem: changing the extension’s manifest alone would be insufficient. The smaller replacement did not yet implement a field the extension required. That field’s behavior needed to be ported before changing the dependency.

The retained record includes the corrective restore and a later clone’s uninstall/registry-reload output. It ends with the corrected rehearsal and final verification still open. It does not prove a successful final transition or a completed before/after digest comparison.

Rehearse the field handoff explicitly

A safer transition procedure is:

Quiesce writes and capture a consistent database and filestore backup. Verify checksums and prove that the pair restores.
Record installed module states, reverse dependencies, and the fields and records that must survive. Keep the addon source revisions with the backup.
Implement the required field behavior in the replacement, including compute and reversal behavior where applicable. Version-control the dependent addon too.
On an isolated restore, install the replacement and upgrade the dependent addon so the database’s module metadata reflects the new dependency. Inspect the removal set again before uninstalling the old addon.
Complete the uninstall, reload the registry, and compare the required values and behavior. Investigate field metadata and ownership during the handoff; identical field names alone do not establish safe transfer.

Disable scheduled jobs and outbound integrations on the clone. A rehearsal should not send mail, contact payment services, or write to production storage.

Compare identity and value, not only counts

For a small affected dataset, compare canonical exports directly. For larger exports, a digest is convenient if the query scope, ordering, and serialization remain identical.

This synthetic Python check demonstrates why counts and non-null counts are insufficient. It models two records whose field values were exchanged; it is not an Odoo migration test:

import hashlib
import json


def digest(rows):
 payload = json.dumps(sorted(rows), separators=(",", ":"), ensure_ascii=True)
 return hashlib.sha256(payload.encode("utf-8")).hexdigest()


before = [(1, "2026-01-10"), (2, None), (3, "2026-01-20")]
after = [(1, "2026-01-20"), (2, None), (3, "2026-01-10")]
assert len(before) == len(after)
assert sum(value is not None for _, value in before) == 2
assert sum(value is not None for _, value in after) == 2
assert digest(before) == digest(list(reversed(before)))
assert digest(before) != digest(after)
print("counts match; identity/value digest detects the change")

For a real comparison, export the stable record ID alongside each affected field, preserve nulls, and normalize dates and other types explicitly. A missing column must fail the check. Also test compute behavior and important workflows: a value digest cannot prove those work.

Before your next uninstall, list which dependent addons and field values must remain, and make their survival a rehearsal acceptance criterion.

ISDOC.PDF: an XML invoice in a PDF, and the VAT date it can't structure

Sun, 09 Aug 2026 05:06:00 +0200

Czech VAT law lets you put a month of separate supplies on one tax document, as long as each supply states its own date. ISDOC, the national e-invoicing format, has one tax date per document. Move that element onto an invoice line and validation fails:

Element 'TaxPointDate': This element is not expected.
Expected is one of ( Note, VATNote, Item, ... )

A human reading the PDF sees every date. The accounting software importing the XML sees one.

What ISDOC is

ISDOC is an XML invoice format, free to use, and maintained by the Czech Ministry of the Interior as the “national standard for electronic invoicing.” The current version is 6.0.2 from March 2022. Many accounting programs open it directly, so nobody retypes the invoice. A 2018 Ministry of Finance notice also lists ISDOC 5.2 and later among the formats central government bodies must accept.

A document comes in three representations :

.isdoc: plain XML in UTF-8
-isdoc.pdf: the XML embedded in a PDF/A-3, known as ISDOC.PDF
.isdocx: an archive with a manifest and attachments

ISDOC.PDF is the practical choice when you don’t know the recipient’s software. It opens like any PDF, and software that understands the format extracts the XML. German ZUGFeRD and French Factur-X use the same idea.

Making an ISDOC.PDF

The spec’s requirements for the PDF:

The PDF is PDF/A-3a, and the file name ends in -isdoc.pdf.
The embedded XML is named exactly invoice.isdoc, with subtype text/xml.
Its /Filespec is listed both in the catalog’s /AF array and in the /EmbeddedFiles name tree.
The /Filespec has /F, /UF and /EF, and /EF holds both F and UF stream entries.
/AFRelationship is /Source if the PDF was rendered from the XML, or /Alternative if both came from your database.

Generate the XML first, since LaTeX has to find it at compile time. With pdflatex, the preamble is short:

\usepackage[a-3b]{pdfx} % needs \jobname.xmpdata next to the .tex
\usepackage{embedfile}
\embedfile[
 filespec=invoice.isdoc,
 mimetype=text/xml,
 afrelationship=Alternative
]{invoice.isdoc}

If you already have a PDF, the official repository has a Java tool that joins a PDF and an ISDOC file and links to a Ghostscript-based script. Its examples/output folder is the reference to compare against.

The ministry doesn’t run a validator , so check the output yourself:

xmllint --noout --schema isdoc-invoice-6.0.2.xsd invoice.isdoc
pdfdetach -list invoice-isdoc.pdf # 1: invoice.isdoc
pdfdetach -save 1 -o extracted.isdoc invoice-isdoc.pdf
cmp extracted.isdoc invoice.isdoc
pdfinfo -meta invoice-isdoc.pdf | grep pdfaid
pdfinfo invoice-isdoc.pdf | grep Tagged

These commands don’t prove PDF/A conformance. For that, use a validator such as veraPDF. XSD validation also doesn’t run ISDOC’s Schematron rules.

What the checks turned up

Our generator’s XML validated, and we extracted its attachment byte for byte. The PDF still differs from the spec in two ways, as a comparison with an official sample showed:

	Official sample	`pdfx` + `embedfile`
`pdfaid` conformance	A	B
`Tagged`	yes	no
`/EF` keys	`F`, `UF`	`F`

A tolerant reader won’t care, and pdfdetach didn’t. A strict one could. PDF/A-3a needs a fully tagged document, which this pdflatex setup doesn’t produce.

Three other traps:

Optional validation can skip silently. Our --xsd flag printed “validation skipped” and carried on, because lxml was missing. In CI, make a skipped check fail.
TaxPointDate is not the issue date. A summary document can go out up to 15 days after the end of the month, so the two differ by design.
Signing happens before embedding. The ISDOC signature is an enveloped XMLDSig inside the XML. The transform removes only the Signature element, so reformatting the file afterward breaks the digest. A signature on the PDF is a separate step and should be an incremental update, which leaves the embedded bytes alone.

What the law requires and the standard lacks

The summary tax document (souhrnný daňový doklad, § 31b of Act No. 235/2004 Sb.) covers several separate supplies to one customer within a calendar month. Under § 31b(4), it must state separately for each supply its scope, date, unit price, tax base, rate and tax, and for each received payment its date of receipt. Data common to all of them can appear once (§ 31b(3)), so a header date is enough only if every supply happened on the same day.

VAT Act	ISDOC 6.0.2	Gap
§ 31b(4)(a)(2): date of each supply	`TaxPointDate` on `Invoice` only	No structured field per line
§ 31b(4)(b)(2): date of each payment	`TaxedDeposit` has no date	No structured field per payment
§ 31b: a separate kind of document	`DocumentType` 1–7, none for it, and the spec’s definition of “tax document” doesn’t list it	Receiver can’t tell from the standard fields
§ 29(1)(h): date of supply on a tax document	`TaxPointDate` is optional in the XSD, and only the spec’s prose says to fill it	XSD accepts a document without it
§ 26(3): customer consents to electronic form	`ElectronicPossibilityAgreementReference` is mandatory, but empty validates	Presence is checked, consent is not
§ 34: origin and integrity	Optional XML signature	None: a recognized signature is one route among several

I tested the per-line and document-type rows by editing a valid file: TaxPointDate on a line, TaxPointDate on an item, and DocumentType 8 each failed the XSD. The payment row comes from reading TaxedDepositType. This is my reading of the statute and the schema, not a ruling or tax advice. Nor does it make an ISDOC.PDF unlawful. If the visible document prints every date, the data is on the document. The gap is that the machine-readable half can’t carry it in a form a recipient’s software will understand.

The spec says its rules should, where possible, be independent of legislation. That is a fair position for validation rules. It doesn’t help when the structure has nowhere to put a value the law requires.

The implementations have the same shape

Header-only dates aren’t unique to ISDOC. In Odoo 18, account.move.line.date is a read-only related field that mirrors the journal entry’s date, and the Czech localization adds a single taxable_supply_date to the entry, defaulting to today. Modeling this correctly took a dedicated per-line field and a rule that derives the header from it. The upstream issue also notes that many commercial accounting systems lack per-line dates.

Our generator has its own limits: one VAT rate per invoice, CZK only, no deposits, and no reverse charge.

EN 16931, the European e-invoicing norm, offers a partial precedent. It has an invoice line period (BG-26) with start and end dates. A line period is not a tax date, but it shows that per-line dates fit in an invoice model.

What to do today

Print each supply’s date in the visible PDF. That is the part a person, or a tax auditor, reads.
Set TaxPointDate to the last supply date. Section 31b doesn’t define a document-level date, but the 2024 VAT control statement instructions ask for “the last (calendar) date” of the supplies on a summary document, so this keeps the two consistent.
Put each date on its own line in a fixed format. Both of these validate:

<Note>Datum plnění: 2026-07-14</Note>
<Item><Description>Work A</Description></Item>
<Extensions>
 <x:TaxPointDate xmlns:x="urn:example:line-tax-point">2026-07-14</x:TaxPointDate>
</Extensions>

Agree on the format with any recipient who needs to import the dates. A standard importer won’t read your note or your namespace.
If a recipient needs structured dates and can’t parse those, issue one ordinary invoice per date. It costs you the summary document, but the data is exact.

The proper fix looks small: in a new schema version, an optional TaxPointDate on InvoiceLine and a date on payments, with the header kept as it is. Issue #7 reports the missing per-line date and is open.

Takeaway

XSD-valid doesn’t mean legally complete, and legally complete doesn’t mean importable. Before you adopt an exchange format for regulated data, list what the law requires per record and find the element that holds each field. Any requirement that ends up in a free-text note is one your recipient’s software can’t see.

Odoo on Lessons learned

A read with legal effect: listing ISDS messages counts as delivery

Setup

Why a read starts a deadline

The design

Copies of the production database

Other reads with side effects

Takeaway

Uninstalling one Odoo module can remove its dependents and their data

Uninstall computes a reverse-dependency set

The first rehearsal had the wrong acceptance criteria

Rehearse the field handoff explicitly

Compare identity and value, not only counts

ISDOC.PDF: an XML invoice in a PDF, and the VAT date it can't structure

What ISDOC is

Making an ISDOC.PDF

What the checks turned up

What the law requires and the standard lacks

The implementations have the same shape

What to do today

Takeaway