ZRA Smart Invoice — Manufacturing (Zambia)
by AminiTech Solutions https://www.aminitechsolutions.com$ 488.00
ZRA Smart Invoice — Manufacturing (Zambia)
A build is not a purchase and not a sale — it is a transformation, and the Zambia Revenue Authority has its own reason codes for it. When a manufacturing order is done, this app declares the finished output as an incoming processing movement (sarTyCd 05) and the components it consumed as an outgoing processing movement (sarTyCd 14), each on its own sarNo, straight to your own VSDC. Extends ZRA Smart Invoice Stock.
One-time purchase · unlimited documents · free updates on every ZRA Smart Invoice spec change. Requires the free ZRA Smart Invoice Base.
The one movement a stock connector usually gets wrong
Declare a build as a plain adjustment and your ZRA ledger tells a story that never happened: stock appearing from nowhere, stock vanishing for no reason, and an inspector asking why. ZRA models manufacturing properly, with processing reason codes for both halves of the transformation, and this app uses them — the finished goods declared in, the raw materials declared out, both derived automatically from the moves the manufacturing order actually completed. Everything rides the free Base queue and goes to your own VSDC or OSDC, with no third-party SaaS sitting in the middle of your tax data.
Both halves of the build
Finished output goes up as processing in (05) and consumed components as processing out (14) — two declarations from one Mark as Done, each with its own stock-authorization number.
Derived, never typed
The lines come from the moves the manufacturing order actually completed — finished goods and by-products on one side, raw materials on the other — with quantities, cost and tax band read from your own data.
Nothing stops production
The declaration is enqueued, not called inline, and any error is logged rather than raised — a device that is busy, mid-restart or unreachable can never stop a manufacturing order from being marked done.
Manufacturing, declared the way ZRA models it
One build, two declarations, no extra clicks
Marking a manufacturing order done declares it to ZRA automatically — there is no separate step to remember and nothing to schedule. The app reads the moves the order actually completed and builds two separate stock declarations from them: one for what came out of the build, one for what went into it. Both are enqueued rather than called inline, so the shop floor never waits on the device. If the company’s ZRA configuration is not yet complete, the order is marked Not Declared instead of firing calls that could only be rejected.
The finished output declared as goods created by processing
The finished products are declared to /stock/saveStockItems with reason code 05, ZRA’s incoming processing movement — the code that says these goods exist because you made them, not because you bought them. Every completed finished move is included, which means by-products are declared alongside the main output rather than quietly disappearing from the ledger. The order’s finish date becomes the occurrence date, and the build reference travels as a remark, so a movement can be traced back to the order that produced it.
The components declared as consumed by processing
The raw materials the build consumed are declared with reason code 14, ZRA’s outgoing processing movement — the counterpart that explains where the cement, the pigment or the fixings went. Only moves that actually completed with a quantity are sent, so a partially consumed component declares what was really used rather than what was planned. Without this half, ZRA would see finished goods materialise from nothing and your declared stock would drift from your yard on every single build.
Each half carries its own stock-authorization number
The finished movement and the components movement each take their own sarNo from the company’s continuous no-gap counter, and both are stored on the manufacturing order as ZRA Finished sarNo and ZRA Components sarNo. Assigning them once and reusing them on every retry is what makes a resend safe: the device either registers a movement that never landed, or answers 921 or 994 to say it already holds it, which the queue converges rather than looping on. The numbers are visible on the order, so a build can be reconciled against the ZRA ledger without opening a queue entry.
Two declarations, one status you can trust
Because the two halves are declared separately, the components entry is registered against the component move rather than the order — a deliberate detail that stops the queue’s own duplicate guard from collapsing the two into one. The app then rolls the outcome back up: whichever entry the device answers, the manufacturing order’s own ZRA Status moves with it, so a planner reads one badge instead of hunting two queue rows. It is plumbing you should never have to think about, which is exactly why it is worth knowing it is there.
The fiscal state of every build, and one click to push it
The manufacturing order header carries a colour-coded ZRA Status badge — green Declared, amber Queued, red Failed, grey Not Declared — beside a Send to ZRA button that appears only on a done order that has not already been declared or skipped. Pressing it re-prepares whatever is missing and immediately fires every pending or failed entry for the build, finding both the order’s entry and the component move’s entry in one sweep rather than making you chase them separately. The button is scoped to the ZRA User role.
A build that must not be declared, is not
A “Declare to ZRA” switch sits on the manufacturing order beside its start date, on by default. Untick it and that build is left out of the declaration flow entirely — the right answer for a migration build reconstructing history, or a scrap rework you are declaring another way. It is not copied when you duplicate an order, so an exclusion can never be inherited by accident onto a real build.
A busy or unreachable device never stops a build
The declaration is wrapped so that anything going wrong is logged rather than thrown at the person marking the order done: the order still completes, the stock still moves, the books still balance. A build with nothing actually completed on either side is marked Not Declared rather than sent as an empty movement, and a build already Queued or Declared is never re-registered. Combined with the Base queue’s widening back-off and its automatic recovery of entries left mid-send, a device outage costs you nothing but a short delay.
A build can only declare items ZRA already knows
Manufacturing declares the same item identity that ZRA Smart Invoice Stock registers — the item code, the UNSPSC classification, the packaging and quantity units — for both the finished goods and every component. That is why this app extends Stock rather than standing alone: register your products once and every build afterwards declares under the codes the device already accepted. A product that somehow reaches a build unregistered still declares with a coherent synthesised identity rather than failing outright.
Valued from your own cost, banded the Zambian way
Both halves of the build are valued at each product’s own standard cost multiplied by the quantity that actually moved — your data, not a re-keyed figure. Each line is then banded on a real Zambian taxation-type code (A Standard Rated 16% through to D Exempt, RVAT, E and TOT), amounts are declared VAT-inclusive as ZRA expects, and the header totals are summed from the lines so the declaration is internally consistent to the ngwee. A component with no tax at all falls back to D rather than breaking the upload.
The compliant way to fix a declared transformation
A declared build is at ZRA, and cancelling or editing it in Odoo does not reach back and remove it. The remedy is the one ZRA recognises and the one ZRA Smart Invoice Stock gives you: a numbered stock adjustment declaring the counter-movement with its own reason code, its own sarNo and the device’s verbatim response on the record. It keeps both halves of the correction on the ZRA ledger, which is what an audit asks for — a build that was wrong and a correction that says so, rather than a silence where a movement used to be.
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 does it need installed?
ZRA Smart Invoice Stock, which itself runs on the free ZRA Smart Invoice Base. Stock supplies the item registration and the shared movement machinery; the Base supplies your TPIN, branch, VSDC URL and the resilient submission queue. Add Manufacturing on top of those.
Why not just declare a build as an adjustment?
Because ZRA models it differently, and the ledger shows it. Processing in (05) and processing out (14) say a transformation happened; an adjustment says stock appeared or vanished. The reason code is what an inspector reads.
Are by-products declared?
Yes. Every finished move the order completed is included in the processing-in declaration, so by-products are declared alongside the main output rather than being left off the ZRA ledger.
What happens if the VSDC is unreachable when I mark a build done?
Nothing stops. The declaration is enqueued rather than called inline and any error is logged instead of raised, so the order completes and the movements are sent automatically once the device answers — on a widening back-off, oldest first, with stuck entries recovered on their own.
Any limits or subscription?
None. One-time purchase, unlimited manufacturing orders, and free updates on every ZRA Smart Invoice specification change.
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 |
•
Manufacturing (mrp)
• Inventory (stock) • Discuss (mail) • Purchase (purchase) • Invoicing (account) |
| Community Apps Dependencies | Show |
| Lines of code | 2329 |
| Technical Name |
aminitech_zra_stock_mfg |
| 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