$ 299.00
| Availability |
Odoo Online
Odoo.sh
On Premise
|
| Odoo Apps Dependencies |
•
Inventory (stock)
• Invoicing (account) • Point of Sale (point_of_sale) • Discuss (mail) |
| Community Apps Dependencies | Show |
| Lines of code | 1854 |
| Technical Name |
aminitech_efris_suite |
| License | OPL-1 |
| Website | https://www.aminitechsolutions.com |
| Versions | 17.0 18.0 19.0 |
EFRIS Suite — complete, all-in-one (Uganda URA)
Fiscalise every customer invoice, credit note and till sale straight to Uganda Revenue Authority EFRIS, register your goods, declare stock-in and adjustments, and supervise it all from one dashboard. Invoicing, Point of Sale, Stock and the Pro control tower ship in a single module on the free EFRIS Base — one purchase, one configuration. The Fiscal Document Number (FDN) and verification QR land on every invoice and receipt.
Every paid app — e-invoicing, POS, goods & stock and the Pro control tower — in one module, one configuration. No separate Base needed.
Everything URA asks of you, configured once
The Suite bundles all four paid EFRIS apps into one self-contained module on top of the free EFRIS Base. Real-time invoicing and POS fiscalisation, goods registration and stock movements, and the Pro control tower — every customer invoice, credit note and till sale uploaded to URA the moment it is posted, with the FDN and verification QR on the paper. One encrypted connection, one reliable queue, one configuration — because EFRIS is a URA cloud service, there is no local device to run.
Invoicing & POS, fiscalised
Every invoice, credit note and till sale is uploaded to URA (T109), with the FDN and a scannable verification QR printed on the invoice and the customer receipt — no cashier wait.
Goods, stock-in & adjustments
Register each product with its UNSPSC commodity code (T130), raise your URA stock on every receipt, and write down loss with a mandatory reason code (T131).
The EFRIS control tower
The EFRIS Bot, one unified Declarations view over every upload, and a health-event log — supervise the whole suite, invoices to stock, from a single screen.
The whole suite, feature by feature
Prove the whole flow before a single real invoice
EFRIS Settings carries an Environment switch — Sandbox or Production — with both URA endpoints already filled in: efristest.ura.go.ug for the sandbox and efrisws.ura.go.ug for production. Flipping the radio repoints every call, so you can post invoices, ring up POS sales, register goods and declare stock against URA’s test service with zero fiscal impact, then go live without touching a line of code. It is the same engine either way, so what passes in sandbox passes in production.
Your URA identity, entered once for the whole suite
One Taxpayer & Device block holds the URA TIN, the EFRIS TaxpayerID, the Device Number (DSN) registered on the URA portal and your BRN. Every declaration the suite sends — invoice, credit note, till sale, goods upload, stock movement — is stamped with these, so there is nothing to re-enter per app. If the TIN is left blank the app falls back to the company VAT number, and any document raised while a mandatory value is missing is parked as No EFRIS Config with the exact missing field named, rather than failing silently at URA.
One button exchanges the encryption keys with URA
Initialize Device runs the URA handshake for you: it fetches the white-box client private key and URA’s server public key, decrypts the key with the init key derived from your TaxpayerID, then draws the AES session key and caches it. From then on every business payload is AES-encrypted and RSA-signed exactly as URA’s own reference client does, and when URA answers code 402 (key expired) the session key is refreshed and the call retried without anyone noticing. A green Device initialized banner confirms the keys are in place. This paid Suite runs on the free EFRIS Base, which supplies that connection.
Pause the upload without stopping the business
Set Transmission to Paused — hold in queue and the tills, invoices and stock keep running while every declaration accumulates safely in the queue instead of going to URA. When you are ready, Resume & Flush Queue turns transmission back on and pushes the backlog in the order it was raised, and Open Queue takes you straight to the pile. Perfect for a URA maintenance window, a month-end review, or a cautious first week in production.
Nothing is lost when URA is slow or offline
Every declaration in the suite flows through one shared queue showing the interface code (T109 invoice, T110 credit note, T131 stock), the source document, the FDN returned by URA, the attempt count, the next scheduled attempt, a colour state badge and the failure reason verbatim. Failed calls retry automatically on an escalating back-off — a minute, then two, five, ten, twenty, thirty, sixty — and Send now forces any row immediately. Entries are sent in sequence order so URA receives your documents in the order you raised them, and every state change is committed so an acknowledgement can never be lost to a rollback.
Find the failures without scrolling
The queue ships with its own search view: one-click filters for Pending, Failed and Sent, group-by for Status or Interface, and search on the interface code or document model. Group by status and you see instantly how many declarations are waiting, how many URA accepted and how many need a human — the fastest daily check a finance team can do.
Post as usual — the T109 goes out on its own
Posting a customer invoice enqueues the URA T109 declaration automatically and logs it in the chatter (Queued for URA EFRIS declaration). The EFRIS tab then holds the whole acknowledgement — status, Fiscal Document Number (FDN), EFRIS Invoice ID, verification code, the EFRIS reference and the verification QR string — while a shield pill in the header turns to Fiscalised. Amounts come straight from Odoo’s tax engine, so inclusive and exclusive pricing, multi-tax lines and discounts all reach URA correctly. A Declare to EFRIS button is there for anything you want to push by hand.
Exclude a document on purpose
A Skip EFRIS tick box on the invoice keeps a document out of the declaration flow entirely — useful for an internal or intercompany move that must never reach URA. It is deliberately not copied when you duplicate the invoice, so an exclusion can never be inherited by accident, and everything else posts and fiscalises as normal.
Map your VAT once, the way URA expects it
Each sale tax carries an EFRIS Tax Category — 01 Standard (18%), 02 Zero-rated, 03 Exempt or 04 Deemed — and the suite aggregates the invoice into the taxDetails buckets URA wants. Exempt is transmitted as the literal dash, not as zero, which is the single most common cause of a rejected Ugandan e-invoice, and a Deemed line automatically raises the deemed flag. Leave a tax unclassified and it is inferred from the rate, so a fresh database is compliant on day one.
A printed invoice your buyer can actually verify
The invoice PDF gains the full URA fiscal footer: the Fiscal Document Number, the verification code, the EFRIS Invoice ID, your TIN and a scannable QR, under the line stating this is a fiscal document issued through URA EFRIS, with the 18% VAT totals above it. The block only prints once URA has accepted the upload, so a printed invoice is always a genuinely fiscalised one — never a hopeful one. Your customer can confirm the sale with URA from the paper in their hand.
Reversals URA ties back to the original sale
A customer credit note is declared through the dedicated T110 credit-note interface, carrying the original invoice’s EFRIS Invoice ID and FDN plus a reason code, so URA links the reversal to the exact document it corrects. The note earns its own FDN and verification code and shows Reversal of the source invoice on the record, keeping both halves of the correction on the URA ledger. This is the only compliant way to undo a fiscalised sale.
A fiscalised invoice cannot be quietly edited
Try to reset a fiscalised invoice to draft and the app refuses, naming the document and its FDN and telling you plainly that editing it would diverge your books from EFRIS — issue a credit note instead. It is a small guard that saves an expensive URA reconciliation, because in EFRIS the declaration is already in URA’s hands the moment the FDN comes back.
Every till sale fiscalised the second it is paid
Each paid POS order is declared to URA (T109) as it is validated, synchronously where URA responds, so the Fiscal Document Number and verification code print on the customer receipt under a URA EFRIS header block. If URA is briefly slow the register never freezes: the order simply queues and fiscalises itself the moment the service answers. The order’s EFRIS tab keeps the acknowledgement — status, FDN, verification code, EFRIS Invoice ID — with a Declare to EFRIS button for anything not yet sent.
See at a glance which sales reached URA
The POS Orders list gains an EFRIS Status column with colour-coded badges — green for Fiscalised, amber for Queued, red for Failed — beside the FDN of every sale. A manager scans a day’s trading in seconds and knows exactly which receipts URA has and which still need a push.
Register every item with URA before it can be sold
URA requires each product to exist in its goods catalogue (T130) before it may appear on a fiscal invoice. The product form adds an EFRIS tab with the commodity code (the mandatory UNSPSC category), the goods code (defaulting to your internal reference), an excise-duty flag, a registered badge and a live status — To Register, Queued, Registered or Failed — behind a one-click Register with EFRIS action. The first upload is a create; a later one is an update, so your URA catalogue stays in step with Odoo, and the app refuses to send an item whose commodity code is still blank.
Speak URA’s unit-of-measure dictionary
Every Unit of Measure carries an EFRIS Unit Code, and that code travels on the goods registration, on each invoice and POS line, and on every stock item you declare. Set it once per unit and URA never rejects a document for an unrecognised measure; anything left unmapped falls back to the safe default.
Every receipt raises the stock URA thinks you hold
Validating an incoming transfer declares a T131 stock-in automatically, with the supplier TIN and name URA expects and an EFRIS Stock-in Type of Import or Local Purchase on the receipt itself. That matters, because URA will not let you fiscalise a sale of goods it does not believe you have. Only genuine incoming receipts are declared — internal transfers and deliveries are left alone — and a receipt with nothing received is marked Not Declared rather than sent as an empty movement. A Declare stock-in to EFRIS button covers anything you need to resend.
Write down loss with the reason URA demands
When goods expire, are damaged, are taken for personal use or vanish for any other reason, an EFRIS Stock Adjustment declares the decrease to URA (T131) with the mandatory reason code — Expired, Damaged, Personal Use or Others. Choose Others and the app forces you to type a remark, exactly as EFRIS requires, so the declaration is never rejected for a missing explanation. Each adjustment gets its own reference from a dedicated sequence (EFRIS-ADJ/00001), a Draft to Queued to Declared status bar and a tracked chatter.
A clean audit trail for every write-down
All adjustments live in one colour-coded register — green once URA has accepted, red where it has not — with the product, quantity, reason and date on every line and the URA failure reason kept on the record. It is the evidence file for every movement that happened outside the normal purchase-and-sale flow, ready for the day someone asks.
One control tower over the entire suite
The EFRIS Bot is the manager’s screen: live tiles for Pending / Failed, Fiscalised today, Fiscalised total and Failed, each drilling straight into the matching queue entries, plus the transmission mode and the timestamp of the last successful upload to URA. Flush Queue pushes everything due right now; Retry Failed re-queues every rejected declaration in one click. When something has failed, a warning banner says so in plain words instead of leaving you to find out at month end.
Every upload to URA, in one searchable view
The Declarations view unions everything the suite has ever sent — invoices, credit notes, POS orders, goods registrations, stock-in and adjustments — with the registration date, interface code, type, source model, FDN, attempt count and status. Filter to Fiscalised or Failed, group by interface or status, search by FDN, and use the Open link to jump straight to the document behind any line. It is the single place a manager, an auditor or a URA officer can see exactly what has and has not reached URA.
Slice your declarations by interface and status
The same declaration data opens as a pivot, interface against status, so you can see in one grid how many T109 invoices, T110 credit notes and T131 stock movements went through and how many were rejected. Drill, group and export it like any Odoo pivot — useful evidence when you need to show a period’s compliance rather than assert it.
Spot a failure spike before it becomes a fine
The declarations also render as a graph, so a bad afternoon — a run of rejections after a tax change, a URA outage, a mis-mapped product — shows up as a shape rather than as a row buried in a list. It is the fastest way to see that something changed, and when.
The queue repairs itself — and tells you it did
A health monitor runs on its own schedule and writes what it finds to a Health Events log with an Info, Warning or Critical severity: a declaration stuck mid-send is recovered and re-queued, the flush job is switched back on if anyone disables it, a session key refresh is noted, and a backlog past the safe threshold raises a critical warning. You get an honest record of every intervention the system made on your behalf, instead of a queue that quietly stopped.
Who may declare, retry and configure
Three roles ship under the EFRIS (Uganda URA) privilege. User sees the queue, the declarations and the Bot and can push a document; Manager also gets the health log and can clear entries; Administrator alone reaches the settings, the environment switch and the device initialisation. The encryption keys are locked to system administrators, and a multi-company rule keeps each company’s declarations to itself — so a cashier can fix a stuck receipt without ever seeing your URA credentials.
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?
Yes — the free EFRIS Base is the shared engine. It provides the AES-encrypted, RSA-signed API client, the online key handshake with URA and the resilient submission queue that all four apps in the Suite run on.
How is EFRIS different from a local fiscal device?
EFRIS is a URA cloud service (system-to-system), not a box on your counter. Your Odoo POSTs encrypted, signed documents directly to URA using your URA-issued TIN and device number — we help you bootstrap the keys and point the app at the sandbox, then switch to production.
Any limits or subscription?
None. One-time purchase, unlimited invoices, receipts, goods and stock movements, and free updates on every EFRIS spec change — one module, one configuration, no per-document fees.
Ready for URA EFRIS compliance?
Install now, or write to us — we set up your EFRIS connection with you.
reach@aminitechsolutions.comURA EFRIS connector for Odoo · Uganda e-invoicing · T109 fiscalisation
| Availability |
Odoo Online
Odoo.sh
On Premise
|
| Odoo Apps Dependencies |
•
Inventory (stock)
• Invoicing (account) • Point of Sale (point_of_sale) • Discuss (mail) |
| Community Apps Dependencies | Show |
| Lines of code | 1854 |
| Technical Name |
aminitech_efris_suite |
| 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