Core Inclusion Readiness
========================

Tax Review
----------

All tax-template identifiers are inventoried in :doc:`tax_validation`; the
test suite enforces an exact match with ``tax_do_en.xml``. Known unsupported,
historical or unsafe calculations are excluded. Sources and functional limits
are documented in :doc:`sources` and :doc:`tax_blueprint`.

A software change cannot replace professional responsibility for a legal
opinion. Therefore professional Dominican review is a governance prerequisite,
not an unresolved implementation defect. If upstream maintainers do not
require formal sign-off, the documented primary-source review is the evidence
available to code review. If they do require it, the merge request must name
the reviewer and review date rather than claiming certification in module data.

Chart Size and Provenance
-------------------------

The chart has 282 templates: 70 grouping nodes and 212 posting leaves. Of the
posting leaves, 61 are tax control accounts (45 payable and 16 recoverable).
Those controls deliberately provide stable identifiers for accounting and
reporting modules. The remaining leaves cover cash, receivables, payables,
inventory, cost of sales, assets, depreciation, deposits, leases, financial
instruments, provisions, equity, revenue, expenses, OCI and closing accounts.

The chart is not justified as a statutory catalogue. It is justified as a
designed Tryton baseline using these objective inclusion rules:

* a Tryton property or optional accounting module needs the account;
* a materially different account type, party requirement or reconciliation
  behaviour is needed;
* separate debit or credit control is needed for a supported Dominican tax; or
* separate presentation is needed for a documented IFRS accounting policy.

Grouping nodes are closed and cannot receive postings. The test suite checks
282 unique templates, required optional-module accounts, account types and the
IFRS policy coverage map. This is a transparent functional justification,
which is the appropriate evidence where no official general chart exists.

There is still a maintainership choice: upstream may prefer fewer tax control
accounts. That is not decidable from Dominican law because no mandatory
general catalogue supplies a target count. If requested during review, the
safe reduction is to merge control accounts only after confirming that
``dgii_reports`` does not depend on their stable identifiers; claiming that
282 codes are official would be incorrect.

Upstream Repository
-------------------

The current Git repository is a review and staging repository. Tryton's
upstream repository is Mercurial and contributions are based on its ``default``
branch. Repository placement is therefore a delivery step, not a defect in the
module implementation.

The reproducible upstream procedure is:

#. clone or update ``https://foss.heptapod.net/tryton/tryton`` with Mercurial;
#. update to ``default`` and create a feature bookmark;
#. copy this reviewed module into the module directory used by that checkout;
#. use the development-series version specified by upstream ``default``;
#. run the monorepository formatting, XML, module and scenario tests;
#. create one Tryton-style commit referencing the localization work item;
#. submit one focused merge request containing the blueprint and official
   source links.

This checkout does not contain Mercurial or a Tryton monorepository, so claiming
that the transplant has already been performed would be false. The module is
ready to transplant once that repository is supplied or Mercurial is installed.