Skip to content

Write no guessed country or tax currency into e-invoices - #624

Merged
clstaudt merged 8 commits into
mainfrom
no-guessed-country-in-e-invoices
Oct 24, 2026
Merged

clstaudt merged 8 commits into
mainfrom
no-guessed-country-in-e-invoices

Conversation

@clstaudt

@clstaudt clstaudt commented Oct 18, 2026 •

Copy link
Copy Markdown
Contributor

An empty or unrecognised country became "DE" in the e-invoice ("Schweiz", "膶esko" and "Brasil" too), and an empty operating country made the tax currency Germany's.

  • Countries: resolve from ISO codes, English names, everyday names (Turkey, UK, England) and names in other languages (Deutschland, 膶esko, Schweiz); nothing fuzzy.
  • Tax currency: comes from the operating country, or from the country's own currency where Tuttle has no tax model.
  • Nothing is refused: when a country is not recognised or the operating country is missing, the invoice is saved without e-invoice data, and a warning says what to correct: "Saved without e-invoice data. Correct the country of Central Services' address: 'Schweitz' is not recognised."

馃 Generated with Claude Code

@clstaudt
clstaudt added this pull request to stack #608 October 18, 2026 20:22
clstaudt and others added 6 commits October 20, 2026 15:25
A second final invoice for a project went through, because the check for
an existing settlement relied on a data-source method that was never
implemented. The new final invoice took over the deposits, so the first
one's balance jumped back to the full price, and revenue counted the
contract twice.

A project now knows it is settled while it has a final invoice that is
not cancelled. Creating another final invoice is refused with a message
that names the existing one and says to cancel it first, also on
fixed-price contracts without deposits. The invoice dialog no longer
offers Final for a settled project. An invoice now carries only the id
and title of its project, so serialising it does not need the project's
invoices.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Cancelling a deposit after its final invoice existed left it among the
deposits the final invoice deducts. The final invoice, its PDF and its
e-invoice then asked the client for too little, revenue lost the
deposit's amount, and paying the final invoice marked the cancelled
deposit paid.

Cancelling such a deposit is now refused with a message that says to
cancel the final invoice first. Restoring a cancelled deposit stays
possible, and paying a final invoice leaves cancelled deposits unpaid.
The invoice view now shows why a status change was refused instead of
silently ignoring it, and an unexpected failure says that the details
are in the application log rather than showing the raw error.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A reminder copies the items of the invoice it chases. For a final
invoice these state the full contract price, so its reminder asked for
the whole price plus the fee instead of what the deposits left. Paying
through such a reminder left the deposits unpaid, and the payment QR
code of a final invoice also asked for the full price.

A reminder for a final invoice now restates the final's settlement: the
full price, the deposits deducted, then its fee. The model gives it the
final's deductions, so its remaining balance, its PDF, the invoice view
and the QR code agree. The QR code asks for the remaining balance, and
is left out when nothing is due. Paying any document of a final
invoice's reminder chain marks the deposits paid. Loading a reminder now
loads its whole chain, which also lets the invoice list show a second
reminder under its invoice.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Cancelling an invoice left its reminders overdue, and a new reminder
could still be created from one of them, because only the reminder
being chased was checked for being cancelled.

A reminder chain now shares the cancelled state of its invoice, as it
already shares the paid state: cancelling or restoring the invoice does
the same to all its reminders. A single reminder can still be cancelled
on its own, but not restored while its invoice is cancelled, and no new
reminder can be created for a cancelled invoice.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
An invoice went out without the seller's VAT number or tax number, or
without the seller's or the client's address, and nobody was told: the
PDF left the lines out, and the e-invoice XML still passed schema
validation. An e-invoice for a contract without a term of payment broke
EN16931 the same way.

Before an invoice, deposit invoice, final invoice or reminder is
created, Tuttle now checks these details and refuses with one message
that names what to add. With an e-invoice profile on, the contract's
term of payment is required too. An invoice outside the scope of VAT
needs the tax number, since it may not show the VAT number. The
e-invoice now states the address the PDF shows, which is the invoicing
contact's when it has one. The demo user gets a tax number for its
dollar invoices.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A country name that did not resolve to an ISO code went into the
e-invoice as Germany, and so did an empty one: a Swiss client written
"Schweiz" or a Czech one written "膶esko" became German. A fuzzy search
also took close names for other countries, such as North Korea for
"Korea". Without an operating country, VAT was taken to be accounted in
Germany, and a country without a tax model accounted it in euros.

A country now resolves from its ISO code or its name in any language
pycountry knows, or not at all. With an e-invoice profile on, issuing is
refused when the user's or the client's country is not recognised, with
a message that says whose it is, and when no operating country is set.
VAT is accounted in the operating country's tax currency, or in the
country's own currency when it has no tax model. The demo user operates
in Germany, as its contracts assume.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@clstaudt
clstaudt force-pushed the no-guessed-country-in-e-invoices branch from 9535c01 to 02ea21e Compare October 20, 2026 13:25
#623 is closed: Tuttle warns instead of refusing to issue. So an
invoice whose country is not recognised, or whose user has no operating
country, is now saved without e-invoice data, with a warning that says
what to correct, instead of being refused.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@clstaudt
clstaudt removed this pull request from stack #608 October 23, 2026 22:05
@clstaudt
clstaudt changed the base branch from refuse-invoice-without-mandatory-details to main October 23, 2026 22:05
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@clstaudt
clstaudt added this pull request to the merge queue Oct 24, 2026
Merged via the queue into main with commit 64894a7 Oct 24, 2026
3 checks passed
@clstaudt
clstaudt deleted the no-guessed-country-in-e-invoices branch October 24, 2026 03:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant