| Availability |
Odoo Online
Odoo.sh
On Premise
|
| Odoo Apps Dependencies |
•
Invoicing (account)
• Discuss (mail) |
| Community Apps Dependencies | Show |
| Lines of code | 7086 |
| Technical Name |
eh_account_portal_extra |
| License | LGPL-3 |
| Website | https://www.erpheritage.com.au/ |
| Availability |
Odoo Online
Odoo.sh
On Premise
|
| Odoo Apps Dependencies |
•
Invoicing (account)
• Discuss (mail) |
| Community Apps Dependencies | Show |
| Lines of code | 7086 |
| Technical Name |
eh_account_portal_extra |
| License | LGPL-3 |
| Website | https://www.erpheritage.com.au/ |
Customer Portal Extra
Let customers pull their own statement PDF and see what they owe today, straight from the portal home.
Why this module
Customer Portal Extra
The customer pulls their own statement
One click on the portal home renders a period-range statement PDF for the logged-in customer. No email request, no back-office task, no waiting on the accounts team.
Same engine as the back office
The download runs the same report handler and the same get_default_options and render_pdf path the internal statement uses, so portal numbers and back-office numbers never diverge.
No one reads another customer's books
Routes resolve the logged-in user's commercial_partner_id and accept no partner_id override. Both routes require login. There is no parameter a customer could tamper with to fetch someone else's data.
Day in the life
A customer settles up before month-end without emailing anyone.
A buyer logs into the portal and lands on the home page. The AR card already shows three open invoices, the total overdue, and that the oldest is 41 days past due. They pick a date range, click once, and download a statement PDF that matches the seller's books to the cent. Need last quarter's position for an audit? They set the end date back and the statement rewinds the reconciliations booked since, showing exactly what was open then. The accounts team never touched it.
Edge cases
The cases most modules quietly ignore.
In the shipped code today, each one a place where a cheaper module silently does the wrong thing.
Ask for a statement as at a past date and it reverses the partial reconciliations created after that date, so historical open balances match what was actually outstanding then, not today's residual. Most portal add-ons just print today's numbers under yesterday's heading.
Four failure modes (portal user not linked to a partner, unparseable dates, an inverted date range, and the statement report not registered) each render a clear branded page instead of a 500 stack trace.
If the PDF render itself raises, the exception is caught and logged and the customer sees a friendly message rather than the underlying error leaking through.
The card and JSON never crash on a partner with no explicit currency. It falls back partner currency, then company currency, then AUD.
Both routes are auth=user, so an unauthenticated visitor is redirected to login rather than shown any data. Covered by the route tests.
The overdue total and oldest due date come from a single grouped SQL read, so the home card stays fast even for a partner carrying many open lines.
What is inside
Built to do the job, end to end.
- Statement download route. A partner-scoped /my route that takes a date range and statement type, validates the dates, resolves the customer statement report, and serves the rendered PDF inline. Defaults to the current month to today when no range is given.
- Portal home AR card. Layers open invoice count, total overdue, oldest unpaid due date, and a days-overdue counter onto the standard portal home values, all aggregated server side.
- Reused statement generator. No new report definitions. It calls the existing customer statement handler from eh_account_dynamic_reports, so one statement engine serves both the portal and the back office.
- QWeb templates only. The module ships HTTP controllers and portal templates and defines no new ORM models, so there is no new access-control surface to manage.
Honest about the edges
What this does not do, so nothing surprises you.
- The render path does not write its own audit log row. Neither the portal nor the back office signs an audit entry when a statement PDF is produced, so do not expect a per-render audit trail.
- Data queries scope by partner, account type, and state. Currency and rendering follow the active company context from the request, but the underlying data domains carry no explicit company_id filter, so this is not a substitute for hard per-company data isolation.
- There is no credit-limit integration. The AR card shows balance and overdue only. It does not surface a credit limit or headroom, even alongside other suite modules.
- It adds a statement download and a summary card. It is not a full customer payment portal and does not add online payment, dispute, or messaging flows of its own.
- Requires eh_account_dynamic_reports for the statement engine and an authenticated portal user. It does not generate statements for anonymous visitors.
odoo 19 customer portal statement download, customer portal account statement pdf, portal AR balance card odoo community, self-service customer statement odoo, portal open invoices overdue summary, odoo 19 community accounts receivable portal, one click customer statement pdf, partner scoped portal routes odoo
Please log in to comment on this module