Prepare Dominican accounting localization for core review

doc/core_readiness.rst

@@ -0,0 +1,71 @@
+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 281 templates: 70 grouping nodes and 211 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
+281 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
+281 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.