EFRIS Base — the required configuration layer
This is only the shared configuration base for the AminiTech EFRIS suite for Uganda. On its own it does NOT invoice, sell or fiscalise anything — it stores your URA EFRIS connection settings, validates 10-digit TINs, and provides the encrypted system-to-system engine the paid apps run on. Install a paid app (Invoice, POS, Stock, Pro) to actually fiscalise documents to URA.
This is a configuration base, not a standalone app. Installed on its own it only adds the URA EFRIS connection settings, the secure key store and the submission queue — it does not invoice, run a point of sale, move stock or declare anything to URA. Those live in the paid apps below, which all require this base.
The required base every EFRIS app needs
On its own, the Base adds two things you can use directly: the URA EFRIS connection settings and 10-digit TIN validation. It does not fiscalise documents by itself — it is the shared, encrypted engine the paid apps build on: the AES-encrypted, RSA-signed system-to-system client, the one-click T102/T104 key exchange, and the self-healing submission queue. Add EFRIS Invoice, POS, Stock or Pro (below) to actually fiscalise invoices, sales and stock to URA.
URA connection & device Initialize
Enter your TIN, TaxpayerID, Device No and BRN, pick Sandbox or Production, then click Initialize Device — the T102 client-init and T104 session-key exchange run with URA and a green “Device initialized” confirms EFRIS is ready. A Sandbox / Production switch keeps testing safely separate from live.
10-digit TIN validation
Every URA TIN is validated as a proper 10-digit number before it is stored on your company or a contact — so you never fiscalise a document against a malformed TIN.
The engine the paid apps use
A complete AES+RSA EFRIS system-to-system client and a self-healing submission queue power the Invoice, POS, Stock and Pro apps — the crypto and queue plumbing you never touch until you add one of them.
What the Base does on its own
Turn URA transmission on or off without touching a document
A single Transmission Control radio on the EFRIS Settings page decides whether declarations leave your database: “Active — send to URA” or “Paused — hold in queue”. It is set per company, so a group with several Ugandan entities can run one live and one still in testing. An “Open Queue” button sits next to it so you can jump straight from the switch to the documents it governs. Nothing is ever dropped when you flip it — the setting only decides whether the queue drains.
Pause during a URA outage, then flush the backlog in order
Set transmission to “Paused — hold in queue” and a “Resume & Flush Queue” button appears. While paused, every declarable document still registers its queue entry — invoicing, selling and stock keep working — but nothing is posted to URA. When URA is back, one click flips the company to Active and immediately sweeps the whole backlog, sending entries in their stored sequence so EFRIS receives them in the right order.
Prove the whole flow on the URA sandbox before you go live
An Environment radio switches the connector between Sandbox and Production, and both URA endpoints come pre-filled — efristest.ura.go.ug for the sandbox and efrisws.ura.go.ug for production. Sandbox exercises the complete encrypted round trip with zero fiscal impact; Production fiscalises for real. Either URL can be overridden if URA moves an endpoint, and the active URL is computed for you, so there is no way to sign a live invoice against a test host by accident.
One place for your URA TIN, TaxpayerID, DSN and BRN
The Taxpayer & Device block holds every credential the URA EFRIS cloud API stamps onto each request: your 10-digit URA TIN, the EFRIS TaxpayerID, the Device Number (DSN) you registered on the EFRIS portal, and your BRN. App ID and API version are carried too, pre-set to the values URA expects. The TIN falls back to the company’s VAT number if you have already captured it there, so you never key it twice.
A malformed TIN is caught before it can reach URA
URA TINs are exactly ten digits, and the Base validates that rule wherever a TIN is captured — the field even carries a “10-digit URA TIN” placeholder. A pre-flight check also lists what is still missing (TIN, TaxpayerID, Device Number, EFRIS URL) before any declaration is attempted, so a half-configured company holds its documents instead of firing rejects at URA. This validation is one of the two things the free Base gives you outright.
Initialize Device runs the full URA key exchange for you
Press “Initialize Device” and the connector performs the complete EFRIS handshake: the T102 client init, which returns URA’s server public key plus your own RSA private key in white-box form (unwrapped with the init key derived from your TaxpayerID), then the T104 exchange that fetches the AES session key. A green “Device initialized. Keys exchanged with URA” banner confirms you are connected. The keys are stored on the company, readable only by system administrators — never pasted into a text field by hand.
Every declaration is a tracked, inspectable queue entry
The EFRIS Queue lists one row per declaration with its interface code — T109 for an invoice, T110 for a credit note, T130 for goods, T131 for stock — the source document model and record, the FDN (Fiscal Document Number) URA returned, the attempt count, the next retry time, a colour-coded state badge (Sent green, Pending grey, Failed red) and the exact Failed Reason. A “Send now” button on each row pushes an entry immediately, and opening the entry shows the JSON payload and the raw URA response side by side.
Back-off retries and an automatic session-key refresh
Everything the Base sends is wrapped in URA’s exact envelope — the payload AES-encrypted, the encrypted content RSA-signed, each request tagged with its own dataExchangeId from a dedicated sequence. If URA is busy or briefly offline the entry retries on a rising back-off (1, 2, 5, 10, 20, 30 then 60 minutes) that you can watch in the Attempt and Next Attempt columns. If the AES session key expires mid-flight, URA answers with code 402 and the connector silently fetches a fresh key and retries the same request — you only ever see it succeed.
A two-minute cron that drains the queue and rescues stuck entries
A scheduled job sweeps the queue every two minutes, sending only entries that are due and only for companies whose transmission is Active. Entries left in “Sending” for more than fifteen minutes — a worker killed mid-post, say — are recovered automatically and re-queued rather than silently lost. Each state change is committed as it happens, so a URA acknowledgement can never be rolled back, and a drag handle lets you re-order entries when URA requires a specific declaration sequence.
Filter and group the queue to find the one rejected document
Ready-made filters for Pending, Failed and Sent sit in the search bar, alongside search on interface code and document model, plus Group By status and Group By interface. Group by status and you get an instant count of what is fiscalised, what is waiting and what URA rejected, with the failure text on each row. It turns “is anything stuck with URA today?” into a two-second answer.
Three EFRIS roles, and keys only administrators can see
The Base installs a dedicated “EFRIS (Uganda URA)” privilege with three roles: User (can see the queue and push an entry), Manager (can also delete entries) and Administrator (the only role that sees the EFRIS Settings page at all). The private key, server public key and AES session key are further restricted to system administrators, so a clerk can clear a backlog without ever being able to read your URA credentials. A multi-company record rule keeps each company’s queue to itself.
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
What do I actually get for free?
The URA EFRIS connection settings and 10-digit TIN validation — plus the shared engine (the AES+RSA system-to-system client and the self-healing submission queue) that the paid apps use. The Base does not fiscalise invoices, sales or stock on its own; add a paid app for that.
Is it really free, and is it configuration-only?
Yes on both. The Base is the shared engine and costs nothing, and it is configuration-only — it never issues an FDN by itself. You only pay for the document apps you need (Invoice, POS, Stock, Pro).
Do I need EFRIS credentials first?
Yes — register your device on the URA EFRIS portal to obtain your TIN, TaxpayerID and Device No, then click Initialize Device to exchange keys. Sandbox credentials are URA-issued and separate from production. Implementation help is included with any paid app.
Ready for URA EFRIS compliance?
Install now, or write to us — we set up your EFRIS connection with you.
reach@aminitechsolutions.comURA EFRIS system-to-system connector for Odoo · Uganda e-invoicing · T102/T104 key exchange
| Availability |
Odoo Online
Odoo.sh
On Premise
|
| Odoo Apps Dependencies |
Discuss (mail)
|
| Lines of code | 703 |
| Technical Name |
aminitech_efris_base |
| 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