Skip to main content
Product details are displayed in English. Translations coming soon.
Vietnam E-Invoice Compliance — Issue Vietnamese e-invoices directly from Odoo, with provider API transmission, invoice-code h — 1/1مثالی پیش منظر

Issue Vietnamese e-invoices directly from Odoo, with provider API transmission,

invoice-code handling, tax mapping from your own master data, and a full correction and archiving trail. Built to order by ECOSIRE for Odoo 17.0, 18.0 or 19.0.

Vietnam E-Invoice Compliance کیا ہے؟

Issue Vietnamese e-invoices directly from Odoo, with provider API transmission, invoice-code handling, tax mapping from your own master data, and a full correction and archiving trail. Built to order by ECOSIRE for Odoo 17.0, 18.0 or 19.0. Built to order by ECOSIRE for Odoo 17, 18, 19 — indicative price from $999.00 USD; request a quote for a scoped proposal.

اہم خصوصیات

Dedicated `ecosire.einvoice.document` model with an explicit lifecycle state machine (draft/queued/sent/accepted/rejected/cancelled/replaced) linked one-to-one with `account.move`
Asynchronous provider transmission via queued job or `ir.cron` sweep, so a provider timeout or outage never blocks or rolls back an invoice posting
Full request/response persistence per attempt: payload, HTTP status, provider error code, correlation id and timestamp, retained for support and audit
Provider invoice-code handling — the returned official code and lookup reference are stored on the document, shown on the invoice form, and printed on the QWeb report
Tax-category and UoM code mapping declared on `account.tax`, `product.template` and `product.category`, resolved per `account.move.line` by an `@api.depends` compute
Pre-submission validation gate on post that names the exact unmapped tax, product or missing partner field instead of failing later at the provider
Partner tax-code format and completeness validation on `res.partner`, catching the most common rejection causes inside Odoo
Explicit handling for exempt, zero-rated, reduced-rate and non-declarable lines rather than a silent default fallback
Rejection workflow: reason surfaced on the form, posted to chatter via `message_post`, and an `mail.activity` scheduled for the responsible accountant
Correction and replacement documents created as linked records that preserve the reference to the superseded original, keeping the sequence auditable
Compliant archiving of both the machine-readable issued file and the human-readable rendering as checksummed `ir.attachment` records
Searchable archive view with filters by period, partner, tax code, provider status and document state, plus export for tax filing preparation
Per-company provider credentials and endpoint configuration in `ir.config_parameter`, with separate sandbox and production endpoints for safe UAT
Security via `ir.model.access.csv` plus record rules, including multi-company isolation of issued documents and a read-only auditor group
Idempotent retry that reuses the original correlation reference, so a network failure cannot cause a duplicate submission for the same move
Exception view listing every document stuck in `queued` or `rejected`, so no failed transmission is discovered only at month end

آرڈر پر تیار، مکمل طور پر آپ کے لیے

خود سیٹ اپ کی ضرورت نہیں — ایک کام کرنے والی ایپ جو ECOSIRE بناتا، انسٹال اور سپورٹ کرتا ہے۔

  1. 1

    آپ آرڈر دیتے ہیں

    ایک بار کی تعمیر کی قیمت سے آغاز کریں۔ آغاز پر ہم آپ کے ساتھ مل کر دائرہ کار طے کرتے ہیں۔

  2. 2

    ہم بناتے اور انسٹال کرتے ہیں

    ECOSIRE اسے آپ کے Odoo پر بناتا، ترتیب دیتا اور انسٹال کرتا ہے۔

  3. 3

    لائیو + معاونت

    آپ تقریباً ایک کاروباری ہفتے میں لائیو ہو جاتے ہیں، گو لائیو کے بعد دو ہفتوں کی معاونت کے ساتھ۔ ہمارے فراہم کردہ کوڈ کی خرابیاں مفت درست کی جاتی ہیں۔

تکنیکی تفصیلات

Odoo ہم آہنگی
Odoo 17, Odoo 18, Odoo 19
ایڈیشنز
Enterprise اور Community
لائسنس
لائسنس کی تصدیق درکار ہے
Python کی ضرورت
Python 3.10+
ڈیٹابیس
PostgreSQL 12+

اس مصنوع کے بارے میں

Finance teams invoicing in Vietnam carry a compliance obligation that Odoo's standard accounting does not answer. account.move posts a document, numbers it with an ir.sequence, and renders a QWeb PDF — but Vietnamese e-invoicing requires that the same posting be transmitted to an authorised e-invoice service provider, receive back an official invoice code, be represented in a machine-readable structure alongside the human-readable copy, and be retrievable in that exact issued form for years afterwards. Nothing in Odoo Community or Enterprise does this. The usual fallback is a parallel workflow: post in Odoo, re-key into the provider's web portal, download the returned file, and reconcile two systems by hand at month end. That is where numbering diverges, where a customer receives a document the tax record does not recognise, and where a rejected submission sits unnoticed until someone reads an email.

We build a module that makes transmission part of posting. A new model — typically ecosire.einvoice.document — is created on account.move post and carries its own lifecycle state (draft, queued, sent, accepted, rejected, cancelled, replaced), the provider request and response payloads, the returned invoice code and lookup reference, and relations back to account.move and res.partner so the chain is traceable from either end. Transmission runs asynchronously through a queued job or an ir.cron sweep rather than inline in the write transaction, so a provider timeout never blocks a user's posting. Every call is stored with its request body, HTTP status, provider error code and timestamp, which is what turns "the invoice failed" into a specific, answerable question.

Tax handling is driven by your own master data, not a hard-coded table. We extend account.tax, product.template and product.category with the provider's tax-category and unit-of-measure codes, and a compute (@api.depends on the line taxes and product) resolves each account.move.line to the code set the provider expects. Exempt, zero-rated, non-declarable and reduced-rate cases each get an explicit mapping rather than falling through to a default, and a validation gate on post raises a clear message naming the specific tax or product that is unmapped — before the document is submitted and rejected. Partner-side data (tax code, legal name, address) is validated for format and completeness on res.partner, so the common rejection causes are caught inside Odoo.

Rejections are treated as a workflow, not an error log. A rejected document moves to rejected with the provider's reason surfaced on the form and posted to the chatter via message_post, and an mail.activity is scheduled for the responsible accountant. From there the correction path — adjustment or replacement, depending on what the original document's state allows — creates the linked corrective document and preserves the reference to what it supersedes, so the audit trail shows the full sequence rather than a silently amended record. Archiving stores the issued machine-readable file and the rendered human-readable copy as checksummed ir.attachment records, and a dedicated menu lets finance search and export by period, partner, tax code or document state. Access is governed by ir.model.access.csv plus record rules, so multi-company installs cannot see each other's issued documents, and provider credentials live in ir.config_parameter scoped per company rather than in source.

This is a build-to-order product: ECOSIRE develops it against your Odoo version (17.0, 18.0 or 19.0), your chart of accounts, and your specific e-invoice service provider's API contract — providers differ in authentication, payload schema and error semantics, so the connector is written to yours rather than assumed. It is not an instant download. After a short scoping call we confirm scope in writing, and typical delivery is one working week from that confirmation. You receive installable source, deployment on your staging database for UAT against the provider's test environment, and a git repository handover, so the module remains yours to maintain, extend, or hand to another team.

What you get

  • Installable module source code (`__manifest__.py`, models, views, security, data) built for your exact Odoo version — 17.0, 18.0 or 19.0 — and Community or Enterprise edition
  • Installation and configuration on your environment, including provider credentials, sandbox and production endpoints, tax-code mapping and sequence setup
  • Technical documentation: data model, state machine, provider integration contract, configuration reference, and the extension points for future changes
  • End-user guide for the finance team plus a live training session covering issuance, rejection handling, corrections and archive search
  • UAT on a staging database against the provider's test environment, with an agreed test script and a documented rollback plan before production cutover
  • Post-go-live support window for defect fixes and configuration adjustments on the delivered scope
  • Private git repository handover with full commit history, so your team or any other partner can maintain and extend the module
  • Handover session covering deployment, upgrade considerations across Odoo versions, and monitoring of the transmission queue

Who this is for

Chief Accountant / Finance Manager (Vietnam entity)

Owns the tax filing and answers to the authorities when an invoice cannot be produced in its issued form. Needs every posted invoice to carry a provider-acknowledged code, needs rejections visible the same day rather than at month end, and needs a searchable archive that matches the ledger exactly.

Group Finance Controller (multi-country Odoo)

Runs one Odoo instance across several countries and refuses to add a country-specific parallel system. Needs Vietnamese compliance to live inside the same `account.move` flow as every other entity, with per-company isolation so the Vietnam records are governed separately without a second database.

ERP / IT Manager

Responsible for the Odoo estate and its upgrade path. Needs the integration written as a clean addon rather than core patches, credentials kept out of source, the transmission queue observable, and the git repository in hand so the module is not a black box at the next version upgrade.

AR / Billing Team Lead

Issues invoices daily and fields the customer calls when a document is queried. Needs the invoice code and lookup reference visible on the record and the printed copy, the rejection reason in plain language, and the correction path to be a guided workflow rather than manual re-entry.

How Vietnam E-Invoice Compliance Compares

CriterionECOSIRECustom BuildCompetitorOdoo نیٹو
Fit to your provider's APIConnector written against your provider's actual contract, sandbox-tested during UATSame fidelity possible, but your team absorbs the full integration learning curveSupports the providers the vendor chose; yours may be unsupported or partially coveredNo e-invoice provider integration of any kind
Transmission and invoice-code handlingAsync queue with idempotent retry; official code stored on the record and printed on the reportDepends entirely on the developer's care with queueing and idempotencyUsually present, though retry and idempotency behaviour is often undocumentedPosting produces a numbered `account.move` and a PDF only
Tax and UoM code mappingDeclared on your own `account.tax` and product records, validated before submissionBuilt to your spec; mapping is frequently under-scoped and discovered during UATGeneric mapping table that may not reflect your chart of accountsOdoo taxes carry no provider tax-category codes
Rejection and correction workflowReason on the form, chatter entry, scheduled activity, and a linked correction pathOften stops at logging the error; the correction workflow becomes a second projectVaries widely — many surface only a status flag with no guided correctionNothing to reject against; corrections are manual credit notes
Archiving and audit trailChecksummed attachments for both formats, searchable archive with exportAchievable, but retention and search are usually deferred past go-liveAttachments typically stored; search and export depth is inconsistentPDF attachment only, no issued machine-readable copy
Odoo version supportBuilt for your target version — 17.0, 18.0 or 19.0 — Community or EnterpriseWhatever you build; upgrade cost lands on your team each cycleVersion support depends on the vendor's release cadence; gaps are commonVersion-agnostic because the capability does not exist
Ownership and lock-inPrivate git repository with full commit history handed over to youYou own it outright, along with all maintenanceLicensed source; continued fixes depend on the vendor staying activeNot applicable
Time and effort to productionTypically one working week from confirmed scope, including staging UAT and rollback planCommonly several months once provider integration and edge cases are realFast to install, then weeks of adaptation if your provider or taxes differImmediate, but the compliance obligation remains unmet

Frequently Asked Questions about Vietnam E-Invoice Compliance

How long does delivery take, and can I download this today?

No — this is a build-to-order product, not an existing apps.odoo.com download. We start with a short scoping call, confirm scope in writing, then build against your Odoo version and your e-invoice service provider's API. Typical delivery is one working week from confirmed scope, including UAT on your staging database. Complex multi-company setups or heavily customised charts of accounts can extend that, and we tell you before we start rather than after.

Which e-invoice service provider does it work with?

We build the connector against the authorised provider you already use. Providers differ meaningfully in authentication, payload schema, invoice-code semantics and error codes, so we write to your provider's published API contract rather than assuming a generic one. During scoping we ask for that integration documentation and sandbox access. If you have not selected a provider yet, we can talk through the integration implications of the common options, but the choice and any commercial relationship remain yours.

Does this work on Odoo Community or only Enterprise?

Both. The module is built on standard `account` functionality present in Community, so it does not require Enterprise. We build and test against your target version — 17.0, 18.0 or 19.0 — and your edition. If you run Enterprise we take advantage of Enterprise accounting features where they genuinely help; nothing in the compliance path depends on them.

What happens if the provider is unreachable when we post an invoice?

Posting still succeeds. Transmission runs asynchronously via a queued job or an `ir.cron` sweep, never inline in the posting transaction, so a provider outage cannot block your team from invoicing. The document stays in `queued` and retries using its original correlation reference, which makes the retry idempotent — a network failure cannot produce a duplicate submission. If retries keep failing, the document surfaces in the exception view with the provider's last error rather than sitting silently.

What does support and updates cover after go-live?

Delivery includes a post-go-live support window for defect fixes and configuration adjustments within the agreed scope. Beyond that, ongoing support and change requests — a provider API version change, a regulatory format update, or a port to a newer Odoo version — are quoted separately. Because you receive the git repository with full history, you are never locked in: your own team or another partner can maintain the module. We are happy to keep doing it, but that is your choice, not a dependency.

How do corrections and cancellations work once an invoice has been accepted?

Once a document carries an official invoice code it cannot simply be edited. The module implements the correction path your provider and the regulations allow — adjustment or replacement — by creating a linked corrective document that preserves the reference to what it supersedes. Both records stay in the archive, so the audit trail shows the full sequence. The available options are constrained by the original document's state, and the interface only offers what is actually permitted.

Can we see it working before committing to production?

Yes. Delivery includes UAT on your staging database against the provider's sandbox environment, with an agreed test script covering successful issuance, a deliberate rejection, a correction, and archive retrieval. We also agree a rollback plan before production cutover. We do not ask you to accept the work on the basis of a demo of somebody else's data.

آرڈر پر تیار
Visa & Passport Expiry Notifications
Odoo

Visa & Passport Expiry Notifications

Automated Odoo email alerts to HR a configurable number of days before employee visa or passport expiry.

From $999.00ابتدائی قیمت — آپ کے دائرۂ کار کے مطابق مقرر کی جائے گی
آرڈر پر تیار
Vonage (Nexmo) SMS Gateway for Odoo
Odoo

Vonage (Nexmo) SMS Gateway for Odoo

A build-to-order Odoo module that routes all SMS through your Vonage (Nexmo) account for global transactional and bulk messaging. ECOSIRE builds, installs, and supports it on your Odoo 17, 18, or 19.

From $999.00ابتدائی قیمت — آپ کے دائرۂ کار کے مطابق مقرر کی جائے گی
قیمت کا تخمینہ طلب کریں

Vietnam E-Invoice Compliance

Issue Vietnamese e-invoices directly from Odoo, with provider API transmission, invoice-code handling, tax mapping from your own master data, and a full correction and archiving trail. Built to order by ECOSIRE for Odoo 17.0, 18.0 or 19.0.

  • Dedicated `ecosire.einvoice.document` model with an explicit lifecycle state machine (draft/queued/sent/accepted/rejected/cancelled/replaced) linked one-to-one with `account.move`
  • Asynchronous provider transmission via queued job or `ir.cron` sweep, so a provider timeout or outage never blocks or rolls back an invoice posting
  • Full request/response persistence per attempt: payload, HTTP status, provider error code, correlation id and timestamp, retained for support and audit
  • Provider invoice-code handling — the returned official code and lookup reference are stored on the document, shown on the invoice form, and printed on the QWeb report

قیمت کا تخمینہ طلب کریں

ہمیں Vietnam E-Invoice Compliance کے لیے اپنی ضروریات بتائیں اور ہم آپ کو قیمتیں، لائسنس کے اختیارات اور ایک مخصوص تجویز بھیجیں گے — عام طور پر ایک کاروباری دن میں۔

ابھی کوئی ادائیگی نہیں۔ یہ ہماری ٹیم کو قیمت کی درخواست بھیجتا ہے — ہم قیمت اور اگلے اقدامات کے ساتھ ای میل کے ذریعے رابطہ کریں گے۔