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.