EFRIS POS — the till, fiscalised in real time
Fiscalise every paid Point of Sale order to the Uganda Revenue Authority through EFRIS the instant it is validated. The Fiscal Document Number (FDN) and verification code come back from URA’s T109 upload and print straight onto the customer receipt, next to the EFRIS QR — with zero cashier wait.
One-time purchase · unlimited documents · free updates on every URA EFRIS spec change. Requires the free EFRIS Base.
Fiscal receipts, without slowing the queue
EFRIS is a URA cloud service, so the moment an order is paid the connector uploads it through T109 and prints the returned FDN, verification (anti-fake) code and QR on the customer receipt — a valid fiscal document the buyer can check on the URA EFRIS app. If URA is momentarily busy or offline, the order falls back to the free EFRIS Base queue and is fiscalised automatically the moment the service is back. The cashier is never blocked.
FDN on the paper
The Fiscal Document Number (FDN), the verification (anti-fake) code and the EFRIS QR print on the customer receipt, so every sale is a valid URA fiscal document the buyer can validate on the EFRIS app or the ura.go.ug FDN page.
Real-time, then resilient
The T109 upload is attempted inline the instant an order is validated; if URA is briefly unreachable the order falls back to the Base queue and retries by itself — the till keeps moving, nothing is lost.
Fiscalised on the right categories
Each line is uploaded with the EFRIS tax category (standard 18%, zero-rated, exempt or deemed) and the UNSPSC commodity category from EFRIS Invoice, so VAT reaches URA exactly as the spec expects.
Real-time fiscalisation at the till
Every paid order is fiscalised the moment it is validated
The connector hooks the order the instant the cashier takes payment and uploads it to the URA EFRIS cloud through interface T109. The upload is attempted inline — not on a nightly batch — so the Fiscal Document Number (FDN), the verification (anti-fake) code and the URA invoice ID are written back onto the order before the paper leaves the printer. The buyer’s TIN travels with the sale when a customer is set on the order; anonymous sales go up as a walk-in buyer, which is exactly what a till needs. Each order also gets its own EFRIS reference number, so a resend can never double-declare the same sale at URA.
The FDN and verification code print on the customer receipt
The three values URA hands back — FDN, verification code and EFRIS invoice ID — are pushed straight into the Point of Sale receipt data, and the receipt header prints a fenced “URA EFRIS” block carrying the FDN and the verification code. That turns an ordinary till slip into a valid fiscal document the customer can check on the URA EFRIS app or the FDN-validation page. Nothing to re-key, no separate fiscal printer, no second device on the counter.
Full URA acknowledgement on every order, in one tab
Each POS order gains a dedicated EFRIS tab holding the EFRIS Status (To Declare, Queued, Fiscalised, Failed or No EFRIS Config), the FDN, the verification code and the EFRIS invoice ID. If URA rejects the sale, the exact failure reason returned by the service appears on the same tab — it stays hidden while everything is healthy, so the form is not cluttered. The fiscal fields are read-only and are never copied when an order is duplicated, so a fiscal identity can never be forged in Odoo.
A one-click “Declare to EFRIS” button for anything still pending
A Declare to EFRIS button sits in the POS order header for any sale that has not yet reached URA, and it disappears the moment the order is fiscalised — so a manager can never accidentally re-declare a sale that already has an FDN. Pressing it re-prepares the T109 payload if needed and pushes every pending or failed queue entry for that order immediately, instead of waiting for the next scheduled sweep. It is the one button a supervisor needs after an outage.
Fiscal status and FDN as columns in the POS orders list
The Point of Sale orders list gains a colour-coded EFRIS Status badge — green for Fiscalised, amber for Queued, red for Failed — plus an FDN column next to the order total. A manager closing the day can see in one glance which sales have landed at URA and which have not, without opening a single order. The FDN column is optional, so it can be toggled off for a leaner list.
A slow or offline URA never freezes the cashier
EFRIS is a cloud service, and cloud services have bad minutes. If the T109 call is slow, refused or the network is down, the order is still completed, still paid and still printed — the declaration simply falls back into the shared EFRIS submission queue and is picked up automatically. Any error raised while declaring is caught and logged rather than thrown at the till, so a URA problem can never become a cashier problem. The FDN is attached to the order the moment URA answers.
Failed uploads retry themselves on a widening back-off
Every declaration lives as a queue entry with its interface code (T109), its attempt count, its next-attempt time and the last response from URA. Failures are retried on a widening back-off — roughly 1, 2, 5, 10, 20, 30 then 60 minutes — so a brief URA outage recovers in minutes while a longer one does not hammer the service. A scheduled job sweeps the due entries every two minutes in strict order, and a per-row Send now action fires any entry immediately when you do not want to wait.
Nothing gets stuck, nothing gets lost, everything is provable
An entry that dies mid-flight (an interrupted worker, a dropped connection) is recovered automatically: anything left Sending for more than fifteen minutes is returned to the retry pool rather than sitting there forever. Each state change is committed as it happens, so a URA acknowledgement can never be lost to a later rollback, and a resend reuses the same queue entry rather than piling up duplicates for the same sale. The payload sent, the URA response, the attempt count and the failure reason are all kept on the entry — the audit trail an EFRIS review asks for.
AES encryption, RSA signing and self-refreshing session keys
Each POS declaration is sent exactly the way URA’s own reference client does it: the JSON payload is AES-encrypted, the encrypted content is RSA-signed, and the whole envelope is posted to the single EFRIS system-to-system endpoint. Initialize Device performs the URA key handshake once — unwrapping the client private key and the AES session key — and stores them in system-admin-only fields. When URA answers that the session key has expired (code 402), the connector transparently fetches a new key and re-sends the very same sale; the cashier never sees it happen.
Every line uploaded on the correct URA tax category
Each order line is declared with the EFRIS tax category mapped onto your Odoo tax — 01 Standard (18%), 02 Zero-rated, 03 Exempt or 04 Deemed. The awkward parts are handled for you: Exempt lines are sent with the literal “-” rate that EFRIS demands rather than a zero, deemed supplies carry the deemed flag, and a line with no tax at all falls back to Exempt instead of failing. The connector also builds the per-category VAT summary URA expects, bucketing net, tax and gross by category across the whole order.
Item codes, commodity codes and units travel with each sale
Every declared line carries the product name, the item code taken from the internal reference (falling back to the barcode), the quantity, the unit price, the line total and the tax amount — already rounded to the two decimals EFRIS accepts. Where EFRIS Stock is also installed, the product’s UNSPSC commodity category and its EFRIS unit code are picked up automatically from the product and its unit of measure, so goods reach URA under the codes they were registered with. Otherwise the line still declares cleanly with a sensible default unit.
Sandbox first, pause when you need to, and a guard against half-set-up tills
The settings page carries a Sandbox / Production switch with the URA test and live URLs already filled in, so you can run a full shift of real sales through the EFRIS sandbox with zero fiscal impact and flip to production only when you are satisfied. A transmission control lets you pause declarations — orders keep queueing safely instead of being sent — and Resume & Flush pushes the whole backlog to URA in order when you are ready. If the TIN, TaxpayerID, device number or URL are not yet in place, orders are marked “No EFRIS Config” rather than being silently dropped, and the queue is one click away from the same page.
We connect you to URA EFRIS
Buying the app includes the setup: we help you register your device on the URA EFRIS portal, initialize the secure keys with URA over the cloud API, validate the full flow on the EFRIS sandbox, then switch you to production.
Device on the URA EFRIS portal
TIN, TaxpayerID, device, tax categories
Full flow on the EFRIS sandbox
Switch to production, declare for real
One suite, sold your way
Buy only what you need on the free Base, or take the all-in-one Suite.
Frequently asked
Does it need EFRIS Base and EFRIS Invoice?
Yes — the free EFRIS Base provides the URA cloud connection, the AES/RSA crypto and the resilient retry queue, and EFRIS Invoice provides the tax categories and UNSPSC commodity categories each order line is fiscalised with.
What if URA is down mid-shift?
The order is fiscalised offline into the Base queue and retried automatically; the receipt still prints and the FDN and verification code are attached the moment URA responds — the cashier is never blocked.
Any limits or subscription?
None. Unlimited orders, one-time purchase, and free updates on every URA EFRIS spec change.
Ready for URA EFRIS compliance?
Install now, or write to us — we set up your EFRIS connection with you.
reach@aminitechsolutions.comURA EFRIS receipting for Odoo · Uganda fiscalisation · T109 → FDN + QR on the receipt
| Availability |
Odoo Online
Odoo.sh
On Premise
|
| Odoo Apps Dependencies |
•
Point of Sale (point_of_sale)
• Invoicing (account) • Discuss (mail) • Inventory (stock) |
| Community Apps Dependencies | Show |
| Lines of code | 1199 |
| Technical Name |
aminitech_efris_pos |
| License | OPL-1 |
| Website | https://www.aminitechsolutions.com |
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