Account_es and cia

Introduction

At Tryton Spain we would like to improve Tryton ERP system in order to get it working out of the box under the Spain laws.

To reach that there are some law requirements required that should be included into the foundation modules, by now they are into the foundation account_es and many other third modules.

It will be very good that other friends of Tryton take a quick look, may be some many countries have the same constraints, and we can work together in order to evict “localization modules”.

So here I’m gonna to divide them into two sections, those which are legally required and those which will be desirable to have included.

Legally required features

Renumber account moves

Renumber account moves ordered by date and number: Código de comercio

An existing implementation: https://bitbucket.org/trytonspain/trytond-account_move_renumber/src/default/

Ensure invoice date consecutive

Ensure that a new invoice has not previous date that the last one: Ley del Iva

An existing implementation: https://bitbucket.org/trytonspain/trytond-account_invoice_consecutive/src/default/

Accountability reports

Balance Sheet and Revenue and Loss: Modelos oficiales para las cuentas anuales

An existing implementation: https://bitbucket.org/trytonspain/trytond-account_financial_statement_es/src/default/

SII

A must procedure for the companies to communicate the invoices to government: SII (Suministro de Información Inmediata)

An existing implementation: https://bitbucket.org/trytonspain/trytond-aeat_sii/src/default/

Desirable features

Right pad accounts with zero digits

To pad account code with a defined number of digits.

An existing implementation: https://bitbucket.org/trytonspain/trytond-account_code_digits/src/default/

Prevent invoice duplication

To prevent user to post twice the same invoice.

An existing implementation: https://bitbucket.org/trytonspain/trytond-account_invoice_prevent_duplicates/src/default/

Include line invoice discount option

To add the option to do discount line by line in an invoice.

An existing implementation: https://bitbucket.org/trytonspain/trytond-account_invoice_discount/src/default/

Payment types

To reflect a prior agreement between parties on how invoices will be paid.

Related to this topic.

Existing implementations:

Could you point to the exact description of this requirement. For me, it is a very strange requirement because the principle of immutability of posted accounting is very common and general.
More over there is the post_date and post_number that have the constraint/design to follow each other order.

There is already Issue 5205: Remove check_invoice_sequences - Tryton issue tracker

Why are the standard reports not good?

Which one is missing? We have AEAT111, AEAT115, AEAT303, AEAT347 and AEAT349.

For me, it is really a feature to please people who can not adapt. It will not provide any functionality except introduce complex code and bugs.

This is a feature that for me is not possible to implement right. It was discussed on Issue 8244: Add warning when an supplier with same reference already exists - Tryton issue tracker

Discount display is a marketing thing so I think it is better to implement it on sale.
We had an old prototype but it will be better to start from Discount on Sale

They’re quite good but do not have a “printable” (libreoffice) version as general ledger do and Registro Mercantil (state authority in charge of receive that documents) expects official documents as described in Modelos oficiales para las cuentas anuales.

The AEAT11X are to inform about amount retention (normally to party as an employee), the AEAT3XX are about to inform taxes (VAT). SII (Suministro de Información Inmediata) is about to inform invoices to government.

Totally agree with you but here we’re close to impossible to fit Tryton without that “feature” :frowning:

:smiley:

So it is just a matter to define a report in account_es based on GL and Income statement.

Not sure to understand what it is. Is it like account_fr_chorus which is to send invoice which has a government agency as customer?
If yes, then you should create a blueprint and probably copy the design of account_fr_chorus.

It is not the same. It is a requirement for companies with more than 6M€ of revenue that have to send all of them invoices (from all customers and suppliers) to the tax authorithy using a web service.

Yes I think we can follow the same design.

Indeed is for companies subscribed to REDEME (monthly VAT declaration).

Yep. For Balance Sheet and Income Statement.

There is a work in progress for this by @ced. Here the review.

Committed here.

The exact description is on Article 25 but it is a bit ambiguos (as usual in Spanish regulatory writing) .
In practice, the presentation of annual general ledger in the “Registro mercantil” is rejected if the account moves are not ordered chronologically and numbered consecutively.

But what is the definition of the date and the number?
Having such constraint does not mean that you have to change the number. For me, it means you must follow the rule for every moves and not cheating by renumbering.

By the way for me, this sounds like the posting number and the posting date which respect this constraint. So nothing new.

Indeed:

  • chronologically => posting date
  • numbered consecutively => posting number

So there is no need to renumber the move as the posting date and posting number provides the chronological order and they are guarantee by the code to stay like that (requirements in many countries).

After talk with a finantial mate I was wrong. The requisite is:

  • chronologically => date
  • numbered consecutively => posting number (ascending, starting in 1)

So if a post a move on 15th of January (posting date) with date 1st of January (date) the posting number should be “1” (considering there aren’t more moves on 1st of January).

Is this number GL wide or per journal?

It is per fiscal year.

Could you tell me how such constraints are managed manually? I can not see how an accountant can deal with such thing manually (neither with a computer).
I really doubt that your “financial mate” understand correctly what are the different dates. Could you ask what is the definition of “date”?

It is not managed at the moment. It is managed while preparing the presentation of annual general ledger (when closing fiscal year).
So for this reason we are taking always of “renumber” concept.
Actually in Tryton it is manged with https://bitbucket.org/trytonspain/trytond-account_move_renumber

date: the date on which the accounting fact happens.
posting_date: the date on which the move is posted.

What is this? Please provide the definition. Could you point the precise paragraph talking about that in https://www.boe.es/buscar/act.php?id=BOE-A-1885-6627&p=20181229&tn=2

For me, it is the tryton definition. What I want is the definition of the date implied in this numbering.

Also I can not find any (none Odoo) references about such practice.

Title 3 section First, articles from 25 to 33

Date implied in this numbering: the date on which the accounting fact happens.

You can try googling “<erpname> renumerar asientos”:

Odoo reference

SAGE 200cloud reference (also exists on 50cloud and other products).

NAV references (complementary):