Troubleshooting
What goes wrong with Customer Statements & Ageing, how to recognise it, and what to do.
The closing balance does not match the lines
It should, always: opening + charges − credits = closing, and a test fails if that ever stops holding.
If you have a statement where it does not, that is a defect rather than a configuration problem. Send it to info@technovision.dev with the period and the customer — we want it.
Before you do, check you are not comparing the closing balance against the total overdue. They are different numbers: the closing balance includes amounts that are not yet due.
An invoice the customer is querying shows as overdue
It has not been flagged. Open the invoice and tick Disputed, then regenerate the statement — it will appear with a badge and outside the ageing.
Statements are a snapshot taken when generated. Flagging an invoice does not retrospectively change a statement you already produced.
An invoice is missing from the statement
In order:
- Is it posted? Drafts are not on the ledger and are not on the statement.
- Is it inside the period? Movements are selected by date.
- Is it flagged Excluded from statements? That removes it entirely.
- Is it on the right contact? A branch's invoices roll up to the head office, not the other way round — generating for a branch shows only the branch's own.
Everything is in the wrong ageing bucket
Almost certainly the invoices have no payment terms, so their due date equals their invoice date, and ageing from the due date then looks like ageing from the invoice date.
Check the due date on an invoice you think is misplaced. The bucket is computed from that field, not from the invoice date.
The head office statement shows more than expected
Branch invoices roll up. That is the default because the alternative quietly understates what the group owes.
For the branch's own position, generate a statement for the branch contact.
The Arabic half is blank or shows boxes
A font problem in the PDF renderer rather than the module. The template asks for a font with Arabic coverage; if wkhtmltopdf on your server has none installed, you get boxes.
Install an Arabic-capable font on the Odoo host — Noto Naskh Arabic or DejaVu Sans — and restart.
The totals are in the wrong currency
A statement is produced in a single currency, converting each document at its own date. If a customer trades with you in two, you get one statement in one currency; there is no per-currency split.
Check the customer's currency, and the company currency behind it.
A user cannot see a statement they generated
Multi-company record rules. The Statements User group implies account.group_account_readonly rather than using sudo(), so somebody who cannot see a company's invoices cannot see its statements either.
That is deliberate — the alternative would make statements a way around the company rules.
No reminders are being sent
Correct. There is no dunning engine in this module. Install technovision_payment_reminders if you want chasing; the two are complementary and neither depends on the other.
After upgrading, three tables are unused
statement_reminder_policy, statement_reminder_level and statement_communication. Left deliberately by the 2.0.0 migration: they are your history of who was chased, and an upgrade should not delete that.
The server log names them with row counts. Drop them by hand if you want the space; nothing reads them.