ZRA Smart Invoice — Complete Suite (Zambia)
by AminiTech Solutions https://www.aminitechsolutions.com$ 1600.00
ZRA Smart Invoice Complete Suite — all-in-one (Zambia)
The whole line in one purchase: Invoicing, Point of Sale, Stock for Traders and Manufacturers, Importers and the Pro control tower, in a single module that needs only the free ZRA Smart Invoice Base. Every invoice, credit note and till sale is declared to your VSDC in real time: the fiscal signature block prints on the customer receipt, and the invoice PDF carries the full block plus a scannable verification QR. Every item registered, every stock movement and adjustment declared, your customs lines reconciled, and one dashboard over all of it. One purchase, one configuration.
Every paid app — invoicing, POS, stock (traders and manufacturer), importers and the Pro control tower — in one module, one configuration. Requires only the free ZRA Smart Invoice Base.
Everything the ZRA asks of you, configured once
The Suite replaces five separate purchases — ZRA Smart Invoice Invoice, POS, Stock (Traders and Manufacturer), Importers and Pro — with one module carrying all of their code. You set up the VSDC connection once, on one settings page, and every app in the suite uses it: one TPIN, one branch, one device, one queue, one dashboard. It talks straight to the VSDC you run yourself (or a hosted OSDC) — your tax data goes from your database to your device to the ZRA, with no third-party SaaS sitting in the middle of it. It needs only the free ZRA Smart Invoice Base.
Invoices, credit notes & till sales
Post an invoice and the saveSales declaration is queued for you; ring up a sale and it is declared inline so the receipt prints the ZRA signature block. The invoice PDF carries the full fiscal block and a scannable verification QR.
Items, stock, manufacturing & imports
Register every product (saveItems), declare each receipt and delivery (saveStockItems), keep the ZRA stock master in step, declare adjustments with a ZRA reason code, book manufacturing as processing movements, and reconcile what customs cleared.
One control tower over all of it
The ZRA Bot, the unified Declarations report with pivot and graph, the Tax Summary, the stock-movements analysis and a health log that records every time the integration repaired itself — supervising the whole suite from one screen.
The whole suite, feature by feature
Pause the ZRA without pausing the business
One radio on the ZRA Smart Invoice settings page decides whether declarations leave your database: Active — send in real time, or Paused — accumulate in queue. Paused is the honest way to trade through a VSDC outage or a cutover: invoicing, the till and the warehouse all keep working, and every declaration is recorded in the queue instead of failing. It is set per company, so a group can run one entity live and another still in testing. An Open Queue button sits right beside it.
Release the backlog in the order it was raised
Set transmission back and a Resume & Flush Queue button appears: one click re-activates the company and immediately sends everything that accumulated, oldest first. Chronological order is the point — the ZRA expects continuous, ordered sequences, and a sale’s stock movement must not arrive before the sale itself. Nothing is dropped when you flip the switch; the setting only ever decides whether the queue drains.
Prove the whole flow before a single real invoice
An Environment radio switches every call between Sandbox and Production, with a separate VSDC URL stored for each — because a business validating on the sandbox and then going live typically re-points the same local bridge, and you should not have to retype a URL to switch back. A blue banner confirms when you are on Sandbox and nothing is legally declared; an amber one warns when you are in Production and everything is. Both default to your local VSDC and stay independently editable.
Point it at the device you run — or at the ZRA’s hosted OSDC
Zambia’s Smart Invoice is reached through a VSDC: a bridge the taxpayer runs on their own server, which holds the device keys and relays to the ZRA. This connector posts plain JSON to that local URL — no API keys to paste, no client-side crypto to get wrong, because the device already holds the keys. Point it at your own VSDC or at the ZRA’s hosted OSDC; both speak the same JSON and both are a base URL away. Your tax data goes from your database to your device to the ZRA.
TPIN, branch and device serial — entered once for everything
One Device Identity block holds the three values that identify you on every call: your 10-digit ZRA TPIN, the 3-character branch ID (headquarters is 000) and the device serial you registered on the Smart Invoice Taxpayer Portal. The TPIN falls back to the company Tax ID if you have already captured it there, and the device serial is visible only to system administrators. Every declaration the suite makes — invoice, till sale, item, stock, import — is stamped with these. Nothing is re-entered per app.
One button runs the ZRA init handshake
Initialize Device posts your TPIN, branch and device serial to /initializer/selectInitInfo and stores what comes back: your SDC ID and MRC No, the communication, internal and sign keys, and the last invoice and stock-authorisation counters the ZRA holds for this device. A green “Device activated” banner then shows your SDC ID and MRC No on the page. The keys are stored in system-administrator-only fields — never pasted into a text box by hand. Those last counters matter: they seed your numbering so it continues where the ZRA left off.
Prove the link without declaring anything
Test Connection runs a read-only code lookup keyed by your TPIN and branch and tells you plainly what happened: the connection succeeded, or the VSDC is reachable but returned a specific result code and message, or the VSDC could not be reached at all. That distinction is the whole diagnosis — a device that answers with an error is a configuration problem, one that does not answer is a network or service problem. Press it before you blame the data.
For when the specification disagrees with itself
The ZRA’s own materials are inconsistent about endpoint pluralization — saveItem against saveItems, savePurchase against savePurchases — and a wrong path simply returns 404. Rather than pretend one form is right, every endpoint is overridable per company through a small JSON map, because the VSDC actually provisioned to you is the only authority. Set an override and it wins; leave it empty and the built-in paths are used. Invalid JSON falls back to the defaults with a warning rather than breaking your declarations. A default UNSPSC item class sits beside it for products with no explicit class.
Nothing is lost when the VSDC is slow or offline
Every declaration in the suite flows through one queue showing the date, the endpoint, the document type, the environment it was raised in, the attempt count, the next retry, the receipt number the VSDC returned and a colour-coded state: Sent green, Failed red, Sending blue, Cancelled muted. Failures retry on a widening back-off — roughly 5, 15, 45, 135 then 405 minutes, capped at twelve hours — so a brief outage recovers quickly while a long one does not hammer the device. Entries go out oldest first, and an atomic claim means two workers can never send the same entry twice.
Find the one stuck document without scrolling
The queue ships with its own search: filters for Pending, Failed and Sent, a Tracking Only filter for audit-trail records the cron never sends, search on the entry, the source document or the receipt number, and Group By for Status, Endpoint or Company. Group by status and you have an instant count of what is declared, what is waiting and what the VSDC refused. It opens filtered to Pending and Failed — the rows that need a human — rather than to everything you ever sent.
Every VSDC answer kept, payload and all
Open a sent entry and the ZRA Acknowledgement block holds exactly what came back: the receipt number, the total receipt number, the registered date, the receipt signature and internal data (both with copy-to-clipboard), the SDC ID and MRC No. A Payload tab shows the JSON that was actually transmitted, in a proper editor rather than a wall of text. This is the audit trail a Smart Invoice review asks for — what you sent, what the device said, and when.
Errors kept in full, with the buttons to fix them
A failed entry keeps its last error and a full attempt-by-attempt history stamped with times, so an intermittent problem is diagnosable rather than anecdotal. Four manager actions sit in the header: Send Now, Retry, Reset to Pending and Cancel — and a sent entry can be none of them, so an acknowledged declaration cannot be undone from the queue. When the last attempt may have reached the VSDC without a readable answer, an amber banner explains that the entry is safely re-sent because the VSDC rejects a duplicate of the same transaction with result code 921 or 994.
The ZRA wants the sale before its stock — and gets it
The ZRA rejects a stock movement that arrives before the sale it belongs to, with result code 922. Rather than build fragile gates across the apps, the suite treats 922 as what it is: a soft ordering dependency. The entry retries in a minute rather than backing off for hours, and it keeps doing so until the document it depends on lands — then it goes through on its own. Nothing to sequence by hand, nothing to babysit.
Who declares, who fixes, who configures
Three roles ship under the ZRA Smart Invoice (Zambia) privilege and they nest. User is the day job: send a document, check a TIN, read the queue and the reports. Manager adds the operations — queue management, exemptions, product and imported-item setup — but not the connection. Administrator alone reaches the VSDC configuration: TPIN, branch, device serial, environment and the keys. A multi-company rule keeps each company’s queue to itself, so a cashier can clear a stuck receipt without ever seeing your credentials.
Every posted invoice declares itself
Posting a customer invoice builds the full saveSales payload and hands it to the queue — the accountant never waits on the VSDC. The chatter records the moment: “Queued for ZRA transmission as invoice N° 1041 (S)”. If a declaration cannot even be built, the invoice still posts and the failure is written to the record rather than blocking your books. Invoices that came from the till are skipped here, because the POS side already declared them — so a sale is never declared twice.
The whole acknowledgement, on the invoice
Every customer invoice gains a ZRA Smart Invoice tab with two blocks. Declaration holds the status, the receipt type (S Sale or R Refund), the ZRA invoice number, the refund reason on a credit note, the manager-only Exempt tick and the environment it was declared in. ZRA Acknowledgement appears once the VSDC answers, carrying the receipt number, total receipt number, receipt signature, internal data, SDC ID, MRC No and VSDC date. A failure reason box appears only when there is a failure. A status badge in the header and a queue smart button complete it.
See which invoices reached the ZRA, without opening one
The invoice header carries a Send to ZRA button for any posted document not yet declared, and it disappears the moment the status is Declared, so an accountant can push a held or failed invoice on demand instead of waiting for the hourly sweep. The status itself is a colour-coded badge — green Declared, red Failed, amber Queued or Not Configured, muted Exempt — readable at a glance across your invoicing. Only posted documents can be sent; the action refuses a draft outright.
Refunds the ZRA can tie back to the original sale
A credit note is declared as a refund (rcptTyCd R) carrying orgInvcNo — the ZRA invoice number of the invoice it reverses, read automatically from the reversed entry — plus a refund date and a refund reason code you can set per document. It earns its own ZRA invoice number, its own receipt number and its own signature on its own ZRA tab, and prints its own fiscal footer. That is the compliant way to reverse a declared sale, and it is why the next feature exists.
A declared invoice cannot be quietly reopened
Try to reset a declared invoice to draft and the suite refuses, naming the document and its ZRA invoice number and telling you plainly why: it is declared at the ZRA, editing it would make your books diverge, and a credit note is the correct remedy. It is a small guard that prevents the most expensive mistake in a fiscalised ledger. Invoices that were never declared, or that are marked exempt, reset to draft exactly as normal.
The nine ZRA codes, and no guessing between them
Each sale tax carries a ZRA Tax Type from the ZRA’s own taxTyCd list: A Standard Rated 16%, B Minimum Taxable Value 16% (charged on the retail or recommended price), C1 Exports 0%, C2 Zero-rating on a Local Purchase Order 0%, C3 Zero-rated by nature 0%, D Exempt, RVAT Reverse VAT (the buyer accounts for it), E Disbursement and TOT Turnover Tax. Set it once per tax and every declaration afterwards reports VAT in the exact buckets the ZRA validates — standard VAT in Zambia is 16%.
An unmapped tax still declares correctly
You do not have to hand-map a tax table before going live. A sale tax left without a ZRA type falls back from its rate — a positive rate is Standard Rated (A, 16%), a zero rate is Exempt (D) — and a line with no tax at all declares as Exempt rather than failing. A one-pass classifier can stamp every unmapped sale tax the same way. What it deliberately never guesses is zero-rating: C1, C2 and C3 are also 0%, but which one applies is a decision, not an inference, so you pick.
The arithmetic the ZRA actually expects
The ZRA works in gross amounts: taxblAmt includes the VAT, and taxAmt is the VAT extracted back out of it. The suite computes every line that way — gross unit price, supply amount, discount rate and amount, taxable amount, tax and total — from your own Odoo taxes, so inclusive and exclusive price lists, discounts and multi-tax lines all declare correctly. The header buckets (taxblAmt, taxRt and taxAmt per band) are then summed from the lines themselves, so the declaration is internally consistent to the ngwee regardless of how Odoo rounded.
A printed invoice your buyer can verify
Once the VSDC answers, the invoice PDF gains the full fiscal footer: the ZRA invoice number, the receipt number, the SDC ID, the MRC No, the VSDC date, the internal data and the receipt signature, beside a scannable QR and the line stating this is a fiscal receipt declared to the Zambia Revenue Authority. The QR is composed by the connector from your device and signature values, because the VSDC returns no prebuilt link. The block prints only on a document the ZRA has actually accepted — so a printed invoice is never a hopeful one.
The declaration, written into the document’s own history
When the ZRA accepts a document, the suite posts a proper table into its chatter: the invoice number, the original invoice on a refund, the receipt type, the sale date, the customer name and TPIN, every taxable and VAT bucket by band (A Standard 16%, B MTV, C1 Exports, C2 LPO, C3 by nature, D Exempt, RVAT, E and TOT), the totals, the receipt and total receipt numbers, the SDC ID, MRC No, VSDC date, signature and internal data — then the line items exactly as transmitted. Not a log file. The document’s own history.
Check a customer against the ZRA before you invoice them
A Check TIN (ZRA) button on every contact validates their Tax ID against the ZRA through selectCustomer and writes back what it learns: a status badge — Not Checked, Valid or Invalid — the taxpayer name the ZRA holds for that TPIN, and the date you checked. The result is posted to the contact’s chatter too, so the check is evidence rather than a memory. Finding out that a buyer’s TPIN is wrong is much cheaper before the invoice than after.
Declared inline, so the receipt carries the signature
Because the VSDC runs on your own machine, a paid POS order is declared synchronously the instant it is validated — on a short eight-second leash — so the receipt number, signature, internal data, SDC ID and MRC No come back in time to print. If the device is momentarily unreachable the order falls into the queue and is declared automatically the moment it answers; the cashier is never blocked and no sale is ever lost. Any error is caught and logged rather than thrown at the till. Refunds go up as refunds, referencing the original order’s ZRA number.
A ZRA block printed on the customer slip
The signature values are pushed onto the receipt data, and the receipt prints a fenced ZRA Smart Invoice block carrying the SDC ID and MRC No, the receipt and invoice numbers, the signature and the internal data. It survives a reprint, because the fields load with the order rather than living in a single render. The payment type is derived from how the customer actually paid — cash, bank card or mixed — and a walk-in sale declares as a walk-in customer, which is exactly what a till needs. A per-register toggle lets a training till declare nothing at all.
Register a product with the ZRA before you sell it
Every product gains a ZRA Smart Invoice tab holding its ZRA identity: the item code (auto-generated to the compliant pattern on registration if you leave it blank, or taken from your internal reference), the UNSPSC item class, the item type — Raw Material, Finished Product or Service — the ISO-2 country of origin (defaulting to ZM), the packaging and quantity unit codes, and a Registered flag with the ZRA’s own message. Register with ZRA posts saveItems with the product’s default tax band, barcode and list price. Codes 921 and 994 count as registered, so re-registering an amended product never breaks.
Register in bulk, and see who is registered
The registration action works on a selection, so a whole catalogue can be registered in one pass rather than product by product, and it reports how many went through. A ZRA Item stat button on the product form shows the registered state at the top of the record, and the ZRA’s own rejection message is kept on the product in plain words when one is refused. Registration is blocked before it can fail if the ZRA settings are incomplete, naming exactly which field is missing.
Validate a transfer and the ZRA sees it
Validating a receipt or a delivery declares it as one ZRA stock-authorisation record carrying all its lines, typed automatically from the operation: an incoming transfer is a Purchase (02), or a Return in (03) when it is a return; an outgoing one is a Sale (11), or a Return to supplier (12). Internal transfers are deliberately not declared. A validation is never blocked — an unconfigured company, an unsupported operation or a purchase you opted out of is simply marked Not Declared with a status you can read, and an hourly sweeper catches anything left behind.
Your on-hand quantity, mirrored at the ZRA
The moment a movement is accepted, the suite pushes a stock-master update for every product in it, sending the product’s real on-hand quantity for that company — so the ZRA’s stock ledger tracks yours instead of drifting from it. And when a declared transfer is later cancelled in Odoo, the suite says so honestly in the chatter: cancelling here does not remove the declaration, and a counter ZRA Stock Adjustment is how you correct the declared stock. It tells you the truth rather than pretending.
Some receipts should not be declared — and you decide which
A Declare Receipts to ZRA tick on the purchase order lets you keep a specific order’s receipts out of the stock declaration entirely, and it is on by default so the safe behaviour is the automatic one. Untick it and the receipts of that order are marked Not Declared rather than sent. It is the right answer for the moves that genuinely should not raise your ZRA stock, and it is a checkbox rather than a support ticket.
Declare a loss with the ZRA’s own reason code
Every movement outside the normal purchase-and-sale flow is recorded on a ZRA Stock Adjustment, auto-numbered ZRA-ADJ/00001, carrying the product, the quantity, the unit cost (defaulted from the product’s cost and still editable), a mandatory description and a type that maps straight onto the ZRA reason codes: Inventory Increase (06), Inventory Decrease (16), Loss or Discard (15), Expired or Obsolete (15) and Breakage (15). The quantity must be positive — the direction comes from the type, not from a minus sign you might forget.
A standing audit trail of every write-down
The ZRA Stock Adjustments list shows the reference, date, product, type, quantity, unit cost and stock-authorisation number of every declaration, colour-coded by state — green once the ZRA accepted it, red when it needs attention, amber while queued. Declare to ZRA sends it immediately rather than waiting for the sweep, the record walks Draft → Queued → Declared with every change tracked in the chatter, and the VSDC’s response is kept on the record. A ZRA User can raise one; only a Manager can delete one, so a declared write-off cannot quietly vanish.
A finished MO declared as the ZRA models it
The ZRA models manufacturing as processing movements, and so does the suite: when a manufacturing order is marked done, the finished output is declared as an incoming processing movement (05) and the consumed components as an outgoing processing movement (14), each with its own stock-authorisation number and the MO named in the remark. A Declare to ZRA tick on the order lets you exclude one, and a status badge in the header shows where it stands with a Send to ZRA button for anything outstanding. Both halves roll their result back up to the manufacturing order.
Reconcile what customs cleared, and make it sellable
Fetch from ZRA pulls every imported line declared under your TPIN at customs into a reviewable register — task code, declaration number and date, HS code, origin and export nation, packages, quantities, the foreign-currency invoice amount, code and rate, the supplier and the clearing agent. Link each line to the product it really is and Approve at ZRA pushes it back with status 3, turning a customs line into a registered item you can invoice. Lines are keyed on company, declaration and sequence in the database, so re-fetching updates them instead of duplicating them.
The line as customs declared it, beside your product
Open an imported line and its customs identity is all there, read-only, because those are customs’ facts: task code, declaration number and date, item sequence, HS code, the ZRA customs status (Unsent, Waiting, Approved or Cancelled) and both country codes, with the packages, quantities and foreign-currency values beside them. Your part is the Link & Approve block: the product and the item class, which resolves from the customs line, then the product, then your company default. The VSDC’s answer is kept on the record.
One control tower over the entire suite
The Bot is the manager’s screen: live tiles for Pending, Failed, Declared Today and Sending, each opening the queue behind it, plus four buttons that solve almost every real problem. Flush Queue sends everything due right now, oldest first. Retry Failed re-queues every rejection in one click. Run Sweepers catches documents that never made it into the queue. Test VSDC probes each active company’s device and reports back by name. Banners warn when transmission is paused or a critical health alert is open — in words, not at month end.
Every document you declared, in one searchable view
The Declarations report unions every invoice, credit note and POS order the suite has declared, with the date, the ZRA invoice number, the source, the receipt type, the customer, the untaxed, VAT and total with column sums, the receipt number and a colour-coded status. Search by invoice number, customer or receipt number; filter to Declared or Failed, or to Invoices or POS Orders only; group by Type, Status, Source, Customer or Month. Open Source Document jumps from any line straight to the record behind it. It is the single place a manager, an auditor or a ZRA officer can see what has and has not reached the ZRA.
Your compliance picture in numbers, not anecdotes
The same declaration data opens as a pivot — months down, Sale against Refund across, measuring total and VAT — so refunds as a share of sales, month by month, reads straight off the grid. Drag in the customer, the source or the status to build whatever cross-tab the question needs. The stock side gets its own pivot of ZRA reason code against status, counting movements, so “every purchase went through but four discards are failing” is one glance rather than an investigation.
Spot the day it stopped
The graph turns declared value into a bar per day, carrying through any filter or grouping you set in the list, so it is a dashboard tile rather than a report you have to run. A stalled afternoon, the week a branch came online, a spike in rejections after a tax change — each shows up as a shape rather than a row buried in a list. The stock analysis graphs the same way, plotting movements per day split by direction, In against Out.
What you declared, ready to reconcile
Tax Summary opens as a pivot filtered to accepted declarations and grouped by month, so the figures you are about to put on a return are the figures the VSDC actually holds — not the figures your books hope it holds. No filters to set, no grouping to build. Drag in the customer, the source or the receipt type when a number needs explaining, and export it like any pivot when the accountant wants it in a file.
It repairs itself — and writes down what it did
A health monitor runs every half hour and records every intervention with a severity: a scheduled job someone switched off is switched back on, entries stuck in Sending for more than fifteen minutes are recovered, a VSDC that stops answering raises a Critical event naming the company, and anything that has failed five times or more raises a Critical event whose details tell you what to do. An hourly alert sweep e-mails every ZRA Manager a consolidated list of what needs attention, throttled to at most one message every six hours so an outage does not become an inbox.
A gap in your ZRA numbering will not stay quiet
Your ZRA invoice numbers come from a per-company, no-gap sequence seeded at device init from the last counter the ZRA holds — so your numbering continues where the device left off rather than starting at one. An hourly check then reads every ZRA number your invoices and POS orders carry and looks for duplicates and holes; either raises a Critical health event naming the offending numbers. It is the check nobody thinks to build until the audit asks for it.
All-inclusive by design — and it says so
The Suite carries the full code of the five standalone apps in one module, which means it cannot sit alongside them. Rather than let that collide at load time, the install refuses cleanly and tells you exactly which standalone ZRA apps to uninstall first. It needs only the free ZRA Smart Invoice Base, and installs itself over Invoicing, Point of Sale, Inventory, Purchase and Manufacturing — one module, one settings page, one queue, one dashboard, no volume limits.
We connect you to ZRA Smart Invoice
Buying the app includes the setup: we help you register your device on the ZRA Smart Invoice Taxpayer Portal, point the connector at your VSDC (or ZRA’s hosted OSDC), run the device initialisation, validate the full flow on the ZRA sandbox, then switch you to production.
Device on the ZRA Smart Invoice portal
TPIN, branch, device serial, tax bands
Full flow on the ZRA 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 exactly does the Suite replace?
Five separate purchases: ZRA Smart Invoice Invoice, POS, Stock (Traders and Manufacturer), Importers and Pro. The Suite ships all of their code in one module. It is one purchase and one configuration — one TPIN, one branch, one device, one queue, one dashboard.
Do I need anything else?
Only the free ZRA Smart Invoice Base, which holds the VSDC connection, the TPIN and branch identity and the submission engine. The Suite installs over Invoicing, Point of Sale, Inventory, Purchase and Manufacturing.
Can I install it alongside the standalone ZRA apps?
No, and it will not let you try. The Suite contains the same models and XML ids, so the install refuses cleanly and names the standalone modules to uninstall first.
What is a VSDC, and do I need one?
Zambia’s Smart Invoice is reached through a VSDC — a bridge the taxpayer runs on their own server, which holds the device keys and relays to the ZRA. The ZRA also offers a hosted OSDC. This connector posts plain JSON to whichever base URL you point it at: no API keys to paste and no client-side crypto, because your device already holds the keys. Your tax data never passes through a third-party service.
Where do the fiscal signature and the QR appear?
The signature block — SDC ID, MRC No, receipt and invoice numbers, signature and internal data — prints on the customer receipt at the till. The invoice PDF carries the same block plus a scannable verification QR composed from your device and signature values, and it prints only once the ZRA has accepted the document.
What if the VSDC is down mid-shift?
Nothing is lost. Invoices post, the till keeps ringing and transfers keep validating; declarations accumulate in the queue and retry on a widening back-off until the device answers. An attempt whose outcome could not be read is re-sent safely, because the VSDC rejects a duplicate of the same transaction with result code 921 or 994.
Any limits or subscription?
None. A one-time purchase, unlimited invoices, receipts, items, stock movements and imported lines, and free updates as the ZRA Smart Invoice specification moves.
Ready for ZRA Smart Invoice compliance?
Install now, or write to us — we set up your Smart Invoice connection with you.
reach@aminitechsolutions.comZRA, Smart Invoice and the Zambia Revenue Authority name are the property of the Zambia Revenue Authority and are used here only to identify the system this connector integrates with. AminiTech Solutions is an independent software vendor and is not affiliated with, or endorsed by, the ZRA.
| Availability |
Odoo Online
Odoo.sh
On Premise
|
| Odoo Apps Dependencies |
•
Inventory (stock)
• Invoicing (account) • Manufacturing (mrp) • Point of Sale (point_of_sale) • Purchase (purchase) • Discuss (mail) |
| Community Apps Dependencies | Show |
| Lines of code | 4154 |
| Technical Name |
aminitech_zra_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