Dominican Republic accounting localization (account_do)

Feature Ideas
1

Dominican Republic accounting localization (account_do)

Summary

I propose adding account_do, an accounting localization module for the
Dominican Republic, to Tryton.

The module follows the account_<country> naming convention and uses the
standard accounting template models provided by account.

The initial reviewed implementation is available at:

Main branch:

Current 8.1 implementation:

The module is maintained by Fundación Un País Mejor:

Rationale

Tryton does not currently provide a core accounting localization for the
Dominican Republic.

Dominican companies need reusable accounting templates for their chart of
accounts and for the accounting treatment of ITBIS, ISR withholdings,
selective consumption taxes and other national taxes.

Without a maintained localization, each Tryton implementation must recreate
account types, accounts, tax templates, tax codes and tax rules. This
duplicates work, produces incompatible XML identifiers and makes complementary
Dominican modules depend on private charts or translated account names.

The proposed module provides a common accounting baseline using the standard
template models from account.

The Dominican Republic does not prescribe a single general-purpose account
numbering system for all ordinary companies. Therefore, this chart is not
presented as an official statutory catalogue. It is an IFRS-oriented Tryton
baseline designed using the following criteria:

  • support the receivable and payable properties required by Tryton;
  • provide current and non-current financial-statement classifications;
  • support standard Tryton accounting modules;
  • provide separate accounting controls for supported Dominican taxes;
  • provide stable identifiers for complementary Dominican reporting modules;
  • avoid company-specific accounting policies;
  • avoid claiming that IFRS prescribes account numbers;
  • keep sector-specific mandatory charts outside the general localization.

IFRS does not prescribe account numbers, and regulated entities may be
required to use sector-specific charts. These limitations are explicitly
documented.

The localization also requires language-specific datasets. Account and tax
template names are static accounting data in Tryton, so changing the user
interface language does not rename an existing chart.

For this reason, the module follows the language-scoped XML approach used by
the account module.

The Dominican Spanish dataset uses es_419 because Tryton does not currently
provide es_DO.

Proposal

Add a new core module named account_do.

The module will provide two complete language-scoped accounting datasets:

  • English (en);
  • Latin American Spanish (es_419), pending availability of es_DO.

Each language-specific dataset contains:

  • 36 account type templates;
  • 281 account templates;
  • 7 tax groups;
  • 50 tax templates;
  • 44 tax code templates;
  • 93 tax code line templates;
  • 23 tax rule templates;
  • 30 tax rule line templates.

The chart contains 281 account templates:

  • 70 grouping nodes;
  • 211 posting leaves.

Of the posting leaves, 61 are tax control accounts:

  • 45 payable tax control accounts;
  • 16 recoverable tax control accounts.

The chart provides accounting structures for:

  • current and non-current assets;
  • current and non-current liabilities;
  • cash and cash equivalents;
  • accounts receivable;
  • accounts payable;
  • inventories;
  • property, plant and equipment;
  • accumulated depreciation;
  • impairment;
  • right-of-use assets;
  • lease liabilities;
  • investment property;
  • intangible assets;
  • financial instruments;
  • deferred taxes;
  • provisions;
  • revenue contracts;
  • equity;
  • retained earnings;
  • other comprehensive income;
  • assets held for sale;
  • income;
  • cost of sales;
  • operating expenses;
  • income tax;
  • Dominican tax control accounts;
  • closing accounts;
  • off-balance accounts.

The tax templates cover the supported accounting treatment of:

  • ITBIS on sales;
  • recoverable ITBIS on purchases;
  • exempt ITBIS;
  • zero-rate ITBIS;
  • ITBIS withholdings;
  • ISR withholdings;
  • selective consumption taxes;
  • telecommunications contributions;
  • legal tip;
  • asset tax;
  • real-estate transfer tax;
  • checks and electronic transfers tax.

Tax templates with limited validity use start_date and end_date.

The chart creation wizard automatically proposes the corresponding receivable
and payable accounts for the selected Dominican chart.

The module provides stable XML identifiers for:

  • account type templates;
  • account templates;
  • tax groups;
  • tax templates;
  • tax code templates;
  • tax code line templates;
  • tax rule templates;
  • tax rule line templates.

Complementary modules may use these identifiers but must not depend on
translated account or tax names.

The following functionality is explicitly outside the scope of account_do:

  • DGII report generation;
  • DGII form-box mappings;
  • electronic fiscal documents;
  • NCF sequence management;
  • NCF validation;
  • RNC lookup;
  • payroll;
  • invoice workflow customizations;
  • company-specific accounting policies;
  • sector-specific mandatory charts.

These features belong in separate modules.

Implementation

The module is implemented using the standard template models provided by
account:

  • account.account.type.template;
  • account.account.template;
  • account.tax.group;
  • account.tax.template;
  • account.tax.code.template;
  • account.tax.code.line.template;
  • account.tax.rule.template;
  • account.tax.rule.line.template.

The module depends only on:

  • account;
  • ir.

Language-specific data is loaded from the following English files:

  • account_chart_do_en.xml;
  • tax_do_en.xml;
  • tax_code_do_en.xml;
  • tax_rule_do_en.xml.

The Latin American Spanish dataset is loaded from:

  • account_chart_do_es_419.xml;
  • tax_do_es_419.xml;
  • tax_code_do_es_419.xml;
  • tax_rule_do_es_419.xml.

Every XML data block declares its language explicitly.

English identifiers use the _en suffix, for example:

  • account_do.do_account_root_en;
  • account_do.do_account_110201_en;
  • account_do.do_account_210101_en.

Dominican Spanish identifiers use the _es_419 suffix, for example:

  • account_do.do_account_root_es_419;
  • account_do.do_account_110201_es_419;
  • account_do.do_account_210101_es_419.

The account.create_chart wizard is extended only to select the appropriate
default receivable and payable accounts.

The module does not replace the accounting engine, tax computation engine,
chart creation process or chart update process.

The external 8.0 release originally used identifiers without a language
suffix. The current migration:

  • maps active historical identifiers to _es_419;
  • preserves the underlying template records;
  • preserves accounts created from those templates;
  • preserves taxes created from those templates;
  • removes only obsolete technical metadata;
  • retains referenced historical records;
  • prevents duplicate chart roots.

This migration has been tested against a database containing a company and a
Dominican chart created with the previous external 8.0 implementation.

The migration may be omitted from the upstream implementation if maintainers
do not want compatibility code for a module that was not previously part of
the Tryton core.

Current branches are:

  • main: version 8.1.0;
  • 8.1: version 8.1.0;
  • 8.0: version 8.0.1.

The external repository is a review and staging repository. Once there is
consensus on the blueprint, the module can be adapted to the development
series used by Tryton’s default branch.

Documentation and official sources

The repository contains detailed documentation for:

  • functional requirements;
  • chart design;
  • account inclusion criteria;
  • IFRS structural coverage;
  • tax design;
  • tax validation;
  • official legal sources;
  • module limitations;
  • core-readiness analysis.

Documentation index:

Requirements:

Design:

Official sources:

Tax design:

Tax validation inventory:

Core-readiness analysis:

The main official references include:

Accounting standards

Dominican Republic IFRS jurisdiction profile:

ICPARD international financial reporting standards:

Dominican Tax Code

Dominican Tax Code, Law 11-92:

DGII ITBIS overview:

Law 253-12:

Tax Code Title V, asset tax:

Law 173-07, real-estate transfer tax:

Other Dominican legislation

Labour Code, Law 16-92:

https://mt.gob.do/transparencia/images/docs/publicaciones/codigo-de-trabajo.pdf

General Rule 06-12:

General Rule 04-2025:

Law 30-26:

Every change to a rate, validity date or legal notice should cite an official
primary source.

The software and documentation do not replace the responsibility of companies
and accounting professionals to verify the applicability of each tax.

Testing

The current test suite contains 74 passing tests.

Measured Python coverage:

  • 100% statement coverage;
  • 100% branch coverage.

The tests cover:

  • module installation in an English database;
  • module installation in an es_419 database;
  • English chart availability;
  • Dominican Spanish chart availability;
  • complete chart creation;
  • account type creation;
  • account creation;
  • account classifications;
  • account codes;
  • receivable account properties;
  • payable account properties;
  • default receivable selection;
  • default payable selection;
  • behavior when another chart is selected;
  • tax group creation;
  • tax template creation;
  • tax account mapping;
  • tax validity dates;
  • tax code creation;
  • tax code line creation;
  • invoice signs;
  • credit-note signs;
  • tax rule creation;
  • tax rule line creation;
  • date-sensitive check and transfer taxes;
  • XML record inventory;
  • XML identifier uniqueness;
  • XML reference integrity;
  • parallel English and es_419 identifiers;
  • IFRS structural account coverage;
  • English accounting terminology;
  • migration from the previous external 8.0 identifier scheme;
  • package configuration;
  • wheel construction;
  • source distribution construction.

Current package validation results:

  • all 74 tests pass;
  • wheel construction passes;
  • source distribution construction passes;
  • twine check passes;
  • Python compilation passes;
  • git diff --check passes.

The English and es_419 charts have the same models and technical structure.
Only the language-specific identifiers and displayed accounting terminology
differ.

Non-goals

The module does not attempt to implement every Dominican fiscal or accounting
requirement.

The following features are intentionally excluded:

  • DGII 606 report generation;
  • DGII 607 report generation;
  • DGII 608 report generation;
  • DGII 609 report generation;
  • DGII IT-1 report generation;
  • DGII IR-17 report generation;
  • DGII form-box mappings;
  • electronic fiscal document generation;
  • electronic fiscal document transmission;
  • NCF sequence management;
  • NCF validation;
  • RNC lookup;
  • taxpayer status lookup;
  • invoice workflow changes;
  • credit-note workflow changes;
  • payroll;
  • payroll withholding calculations;
  • company-specific accounting policies;
  • industry-specific accounting reports;
  • charts prescribed for banks;
  • charts prescribed for insurance companies;
  • charts prescribed for other regulated sectors.

DGII reporting modules may use the stable account, tax and tax-code identifiers
provided by account_do.

The module also does not claim that:

  • its account numbers are prescribed by IFRS;
  • its account numbers are a mandatory Dominican statutory catalogue;
  • every tax applies to every company;
  • software configuration replaces professional tax advice.

Maintenance

Fundación Un País Mejor is willing to maintain the localization.

The proposed maintenance responsibilities include:

  • monitoring changes in Dominican accounting and tax legislation;
  • reviewing new DGII rules;
  • updating tax validity dates;
  • updating official legal references;
  • maintaining the English dataset;
  • maintaining the es_419 dataset;
  • migrating to es_DO if it becomes available;
  • keeping XML identifiers stable;
  • preserving upgrade compatibility;
  • updating the module for future Tryton releases;
  • responding to reported defects;
  • participating in code review;
  • coordinating professional Dominican accounting review when required.

The initial reviewed source is hosted at:

Questions for the community

I would appreciate feedback from the community and maintainers on the
following points:

  1. Is an IFRS-oriented general-purpose chart acceptable when the Dominican
    Republic does not prescribe a single general statutory account numbering
    system?

  2. Is the proposed chart size appropriate for a core localization?

  3. Should all 61 tax control accounts remain separate, or should some of them
    be consolidated?

  4. Should all 50 tax templates remain in the base localization?

  5. Should any sector-specific taxes be moved to a complementary module?

  6. Is es_419 the appropriate language for the Dominican Spanish dataset
    until es_DO becomes available?

  7. Should a separate work item be created to request the addition of
    es_DO?

  8. Should the migration for the previously published external 8.0 module be
    included in the upstream version?

  9. Should compatibility with the external 8.0 release remain only in the
    external repository?

  10. Is the separation between account_do and Dominican reporting modules
    appropriate?

  11. Are the supplied primary legal references sufficient for the initial
    review?

  12. Is formal sign-off by a Dominican accounting or tax professional required
    before integration?

  13. Are there account groups or posting accounts that should be removed from
    the general-purpose baseline?

  14. Are there additional Tryton accounting modules that the chart should
    support explicitly?

  15. What additional changes are required before preparing the final patch
    against Tryton’s default branch?

Once there is consensus on the scope and design, I can prepare the module
against Tryton’s default branch and submit the corresponding upstream
change.

2

This is a great initiative and thanks for sharing.
But I do not think we can take the burden of maintaining another chart of account in core (see Is there anybody caring about Spanish modules? and Is there anybody caring about German module?).
So I think it will be better for now if you could maintain it on your server like you do, publish it on PyPI (with a different prefix than trytond_) etc.
You can use Message Board to communicate about your progress etc.

3

Thanks Cedrik for your comment

4

I’m wondeirng if it won’t be better to just use the es language with the dominicaion prefix. This way the translations will be available for any derivative language.

I think its apropiate for the first version of the module but the module should include reporting functionalities in newer changes. That aproach worked very well for the spanish module.

There are some modules that add some special checks to account types to make their accounts usables for other uses. It will be great to support them as extra depends when available. At first tought I think there is account_deposit and sale_advance_payment modules but I’m just writing on memory without checking them.