$ 515.73
In-App Purchases| Availability |
Odoo Online
Odoo.sh
On Premise
|
| Odoo Apps Dependencies |
•
Point of Sale (point_of_sale)
• Discuss (mail) • Invoicing (account) • Inventory (stock) |
| Community Apps Dependencies | Show |
| Lines of code | 2488 |
| Technical Name |
eh_l10n_mu_einvoice_pos |
| License | OPL-1 |
| Website | https://www.erpheritage.com.au/ |
| Versions | 16.0 17.0 18.0 19.0 |
| Availability |
Odoo Online
Odoo.sh
On Premise
|
| Odoo Apps Dependencies |
•
Point of Sale (point_of_sale)
• Discuss (mail) • Invoicing (account) • Inventory (stock) |
| Community Apps Dependencies | Show |
| Lines of code | 2488 |
| Technical Name |
eh_l10n_mu_einvoice_pos |
| License | OPL-1 |
| Website | https://www.erpheritage.com.au/ |
| Versions | 16.0 17.0 18.0 19.0 |
Mauritius e-Invoicing POS
Fiscalise every paid POS order with the MRA in real time and print the QR code on the receipt.
Store price is USD 518 all-in: installing this also pulls the 1 paid ERP Heritage module it depends on.
Why this module
Mauritius e-Invoicing POS
A live MRA transport, not a placeholder
Each paid order is encrypted and POSTed to the real MRA transmission endpoint with the RSA and AES-256 scheme from the EBS technical guide. The response is parsed, the IRN and QR are written to the order, and the EBS chain advances. This is a working connector, not a stub framework.
POS and invoices share one EBS chain
The module reuses the base module authentication session, the row-locked per-EBS invoice counter, and the EBS-wide previous-note-hash chain. Invoices and POS receipts advance the same chain in order, so the MRA sees one consistent sequence per registration.
A till outage never blocks a sale
Fiscalisation runs in a savepoint inside the payment hook and catches every failure. An MRA outage leaves the order Not Yet Fiscalised for a one-click resubmit or an opt-in scheduled retry, so the cashier is never stopped at the point of payment.
Day in the life
From tender to fiscalised receipt
A cashier closes an order and takes payment. As the order syncs, the module builds the MRA invoice payload from the order lines, reserves the next EBS invoice counter, attaches the current previous-note-hash, signs the payload if signing is enabled, encrypts it, and transmits it to the MRA. On success the IRN, QR code, counter, and fiscalised timestamp are written to the order, the chain pointer advances, and the receipt prints with the 2cm MRA QR code. If the MRA cannot be reached, the order is marked Not Yet Fiscalised and the sale still completes; a manager later fiscalises it with one button or lets the scheduled retry pick it up. Every attempt, success or failure, is recorded in the append-only request log with the request id, status, and response.
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.
If the MRA is unreachable or times out, the order is marked Not Yet Fiscalised and the sale still completes. The module never auto-retries on timeout inline, because a timed-out order may already have been fiscalised and a blind retry would duplicate.
Resubmitting an already-fiscalised order is skipped: orders in the fiscalised state are not re-sent. The counter and note-hash are only consumed once, on the successful submission, so a retry of a failed order does not burn the chain.
A 200 response carrying a per-receipt rejection does not crash. The order moves to Rejected by MRA with the MRA error code and description stored, and the scheduled retry deliberately never re-sends rejected orders, only connectivity failures.
The per-EBS invoice counter is reserved with a row-level database lock, so two tills closing orders at the same instant cannot collide on the same invoiceCounter value.
A product whose tax has no MRA TC tax code is refused with a clear message naming the product, rather than sending an invalid payload that the MRA would reject.
When digital signing is enabled but the EBS private key cannot be loaded or used, the order is moved to the error state with the cause logged, instead of transmitting an unsigned or malformed payload.
The optional scheduled retry is opt-in per company, processes only Not Yet Fiscalised orders, runs each attempt in its own savepoint, and stops after the company maximum attempts so a stuck order is left for manual handling.
What is inside
Built to do the job, end to end.
- POS payment hook. Fiscalisation is triggered from the server-side paid hook so the IRN and QR are on the order before the receipt renders. The whole step is wrapped in a savepoint with a broad catch, guaranteeing the sale completes even if fiscalisation fails.
- Receipt QR rendering. An OWL extension of the POS order receipt prints the base64 MRA QR code at 2cm by 2cm when present. The IRN is captured on the order but, in line with the MRA receipt template, is not printed on the slip.
- Order fields and back office. The pos.order form gains an MRA status badge, the IRN, fiscalised date, invoice counter, the QR image, the error message, and a Fiscalise with MRA button for manual resubmission of orders not yet fiscalised.
- Reused base transport. Authentication, the cached 23-hour token, the AES-256 data key, the credential vault, the encrypted transmission, and the append-only request log all live in the base e-Invoicing module and are reused unchanged. Only the pos.order to MRA payload mapping is new here.
- Optional scheduled retry. An inactive-by-default scheduled action retries Not Yet Fiscalised orders on the per-company toggle, capped by the maximum attempts setting, each retry isolated in its own savepoint.
Honest about the edges
What this does not do, so nothing surprises you.
- Requires the Mauritius e-Invoicing base module and the standard Point of Sale module; it is an add-on, not a standalone product.
- Requires live MRA EBS credentials registered with the Mauritius Revenue Authority and the credential vault master key configured on the server before any order can be fiscalised.
- The test or live environment is determined by your EBS registration status at the MRA, not by a separate sandbox URL; this module sends to the configured MRA endpoints.
- It fiscalises POS receipts with the MRA; it is not a replacement for the MRA portal, for your accounting close, or for professional tax advice.
- Tax codes must be mapped to MRA TC codes and customer or company identifiers configured in the base module; orders with an unmapped tax are refused rather than sent.
- The module does not impose any mandate or go-live dates; configure it according to your own MRA registration timetable.
- No external services, no phone-home, and no third-party intermediary: the only outbound calls are directly to the MRA endpoints you configure.
Mauritius e-invoicing POS, MRA fiscalisation Odoo, MRA EBS Point of Sale, Mauritius Revenue Authority e-invoice, real-time invoice transmission Mauritius, IRN POS receipt, MRA QR code receipt, vfisc Odoo connector, Odoo 19 Mauritius localization, previous note hash chain, EBS invoice counter, POS fiscalisation Odoo Community
Odoo Proprietary License v1.0 This software and associated files (the "Software") may only be used (executed, modified, executed after modifications) if you have purchased a valid license from the authors, typically via Odoo Apps, or if you have received a written agreement from the authors of the Software (see the COPYRIGHT file). You may develop Odoo modules that use the Software as a library (typically by depending on it, importing it and using its resources), but without copying any source code or material from the Software. You may distribute those modules under the license of your choice, provided that this license is compatible with the terms of the Odoo Proprietary License (For example: LGPL, MIT, or proprietary licenses similar to this one). It is forbidden to publish, distribute, sublicense, or sell copies of the Software or modified copies of the Software. The above copyright notice and this permission notice must be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Please log in to comment on this module