Is there anybody caring about Spanish modules?

Organisation
23

I created a MR in order to remove them:

As next series is LTS series which means that it should be mantained for 5 years I will be great to have a solution of this topic before the release.

24

It seems strange to me that you kinda are celebrating such failure.

26

It is clear for me that we will fail to have a working version for 8.0 series and I want to ensure that our customers have the needed features (that we are currently manually fixing for them) and that they are properly supported for the needed years.

I have this clear path because @ced told me privatlly that he “deliberately stopped reviewing those MR until the desing issue has been fix and after many years no progresses have been made”. I don’t think this will change before the next 8.0 series.

So instead of having another private fork:

I prefer to remove them from standard modules and try to join efforts on another public repository having a diference developement and backport pace. This will also allow to release missing fixes until a better design is developed.

If anyone else have a better plan, please share it here.

27

Nothing prevents to have a proper fixes for the design issue.

I do not see why such thing will happen if there is no pressure for it.

28

I feel more pressure for users that have issues and can do not have the proper usage of the module than for the desing of the module. So its a mather of priorization:

  1. Fix all current issues and make all currently broken features working again.
  2. Improve the desing to ease the maintenance of the module.
29

Tryton project is not about your users.
It is about sharing the maintenance effort and the evolution of the code.

I think this is the main problem here as I speak as a maintainer and everyone else as a consumer.

PS: an this is also often the case in many issues.

30

Let me propose a different path:

  • If you are absolutely sure, that you want maintain the modules in question outside Standard then please fork them beforehand (e.g. to https://foss.heptapod.net/tryton-community/modules), so that users and packagers are able to have a look, give them a try and adapt evtl. the packaging to use that source.
  • After forking just leave it to the maintainer to remove, or better archive those modules as he sees fit.

This procedure would establish a path where users would not be faced with sudden breakages.

31

Hi Mathias, that’s have been always the plan :slight_smile:

I proposed the removal because I do not want spanish users to have some non working features and found issues that had been already reported but not fixed.

But we may probably have a middle plan which would be:

  1. Fork the modules to fix what we already have.
  2. Keep the modules as is and include some “Not Implemented Error” on features that we now are not working.
  3. Redesing the module on external fork to validate and re-introduce changes slowly to upstream module.

I’m open to any posiblities but I’m not the one who should take the decision on core modules.

32

Forks are done:

I will try to do the work of review all the existing issues MR and include the in new fork.

33

I would like to add a small perspective to this discussion, based on my experience using Tryton in multiple countries and now considering its use for a Spanish company.

From what I understand, part of the difficulty with the Spanish modules comes from mixing two concerns that evolve at very different speeds:

  • The Chart of Accounts and basic accounting structure (which is relatively stable)
  • The AEAT-related obligations (SII, reporting, formats), which change frequently and require fast adaptation

In other localizations, these concerns are often separated. The Chart of Accounts provides a stable foundation, while regulatory and reporting requirements are implemented in independent modules that can evolve more quickly.

With that in mind, would it make sense to split the current responsibilities along those lines?

  • Keep a minimal account_es focused on the Spanish Chart of Accounts and core accounting structure
  • Move AEAT/SII/Verifactu/Facturae and similar requirements into separate modules (whether in tryton-community or elsewhere)

This could have a few benefits:

  • Reduce pressure on core maintainers regarding fast-changing regulatory requirements
  • Allow contributors to iterate more quickly on compliance-related modules
  • Preserve visibility and confidence that Spain is supported in Tryton through a stable base module
  • Lower the need for users to maintain private forks for regulatory changes

Additionally, from a user perspective, having accounting inside Tryton does not necessarily mean that tax authority reporting must be submitted directly from Tryton itself. In practice, many companies rely on third-party integrators such as B2Brouter, Ecosio, Edicom, or similar platforms to handle communication with AEAT and other systems.

In that context, Tryton’s role can remain focused on providing clean and reliable accounting data, while external tools handle submission, validation, and compliance workflows. This further supports the idea of keeping regulatory integrations loosely coupled rather than embedded in the core accounting module.

Of course, I may be missing historical or technical constraints that make this harder than it sounds, but I wanted to share this idea in case it helps move the discussion forward.

Thanks

34

The tryton chart of accounts also include, tax and tax code definition. Tax code definition is used for AEAT-related obligations.

With this in mind, spliting both features makes having a complete solution more complex as it will required to make changes in to separate modules or even just create some tax records manually in databases.

While your proposal may work, I’m not sure if it make everything jusst more complex.

35

Thanks @pokoli for the detailed explanation — my knowledge of the module is not as deep as yours, so this is very helpful.

I think the issue is not that taxes are part of the chart, but that account_es mixes them with AEAT-specific logic.

Regarding the concern about complexity when splitting: as far as I understand, AEAT requirements mainly need a classification layer on top of taxes (e.g. mapping taxes to report boxes, operation types, etc.), rather than defining the taxes themselves. If that mapping is implemented in AEAT-specific modules and ships with sensible defaults for the standard taxes defined in the chart, it should not require manual database work nor make the setup more complex for users.

Also, AEAT functionality is not always required in all deployments (some rely on external tools), so it could reasonably be optional. ← This point, in my experience, is really relevant (imagine a module account_es_edicom or similar)

Regards

36

This mapping is done by account.tax.code in Tryton which is included in the chart of accounts. But as this records can be created/updated manually on the database we just include the most common definitions in the chart of accounts.

For me, such separation only makes sense to transform the tryton codes into the AEAT format (which have more changes). This had been discussed here and the idea is that a change in the AEAT format only requires to update the file generator module and not the tryton modules.