Spanish VAT listing

Feature
1

Rational

When the VAT listing was discussed for inclusion on Tryton, the Spanish chart of account was not part of the supported modules so it VAT listing was not included. As we now have it available it will be great to include it’s VAT listing.

On Spain we have to include the following reports:

  • Modelo 347: Which includes the list of National parties and it’s amount operation which operations are above the limit of 3005.06€. It’s required to include the list of both purchases and sales operations and they are differentiated by a code: A for purchases and B for Sales. This should be reported once per fiscalyear.

  • Modelo 349: Which includes the list of intracomunitary operations. This is very similar to the EC Sales List which currently exist in Tryton, but we include purchases also. There is also a operation code which is used to differentiate if there is a services or goods related operation.

Proposal

account_es:

  • Add EC Operation List model, which includes sale list code and purchase invoices.
  • Add EC purchase list codes for purchase taxes.
  • Add a new view for national taxes operation. This should be a table query very similar to the one of the account_be module but including more details:
    • Operation Code: Purchase/Sale identifier
    • Party Information including: Tax Identifier, Name and Province Code.
    • Sum of invoices total amount broken down by quarter
    • Total amount.

Implementation

issue7558

2

I do not think EC Sales List should be changed, this is the official report for all EU. Indeed this is the Spanish requirements that extend it. So I think account_es should create a new listing but probably doing an union with ECSalesList query.

I did not see that in the description of the report.

I do not think it is a good idea to hard code such value. There is the same kind of value for Belgium and we did not put it because it is subject to change. So it will be more annoying to the user if he can not customize it himself.

3

On file format (Pages 18-22) is detailed that the user should enter the amount for each quarter.

This is also required on the webform to introduce the data:

Screenshot-2018-5-30%20Modelo%20347
Screenshot-2018-5-30%20Modelo%203471290×545 28.7 KB

4

Then it should be clearly defined what are those periods? Are they the tax period? Are they based on month?

5

This is yearly report that must be presented each January no mather how the fiscalyear of the company is defined. So the periods are based on the month:

  • 1T: January - March
  • 2T: April - June
  • 3T: July - September
  • 4T: October - December
6

So this is not similar to account_be report because this report is based on fiscal year.
But I still have some doubts because the form use 1T, 2T, 3T and 4T instead of dates. Such format is usually used when the period are not static.

7

In the spanish case: 1T, 2T, 3T and 4T always refer to the static period date and months Sergi says.

8

In some companies, 1T start in july at end to next june.

1T: July - September
2T: October - December
3T: January - March
4T: April - June
9

This is managed by the fiscalyear.

What are we talking about here is about the requirement to report the National parties operation (Modelo 347) broken by Quarter, which is independent on how the company has created his fiscalyear:

  • It should be presented always on January
  • It includes the operations of the previous year
  • The periods are based on the months of the year
1 Like
10

This implies that we should add a new field to indicate the purchase code list as we can not reuse the ec_sales_list_code. Should this field specific to Spain?

11

It will depend if this code exists in other countries.

12

Indeed in Spanish the Party name is required, do you think it’s good to add this field to the account_eu sales list (which will allow to extend it) or generate a new (similar) query which adds the new field?

13

I think that you should be able to add a column to the SQL query with python-sql, don’t you?

>>> import sql
>>> a = sql.Table('foo')
>>> q = a.select(a.bar, a.baz, where=a.quux == 'brol')
>>> q.where &= a.stuff == 'truc'
>>> q.columns = list(q.columns) + [q.bazar]
>>> print(q)
SELECT "a"."bar", "a"."baz", "b"."bazar" FROM "foo" AS "a" WHERE (("a"."quux" = %s) AND ("a"."stuff" = %s))

Maybe not in fact, I think this usecase should work.

14

For me, localization should never modify standard behavior globally. It can only for the case of the company being in the country. The activation of the module should not modify the standard behavior.

15

You can when you have the reference to the table (so you can select the columsn of the same table) but it gets harder when you only have the q variable, as my code looks like:

q = super().table_query()

Without any reference to the query tables.

16

I see your point and agree to it. I think I did not explain myself properly.

My idea is to add the party field on the account_eu module so it’s also shown when the account_es module is not activated. Is there any reason to not include it?

17

The design was based on: Redirecting to Google Groups
But it seems the Belgium and Luxembourg listing are a little bit different than the others for SAP: https://help.sap.com/doc/erp2005_ehp_06/6.0.6/en-US/2d/b88a6dc6214b2382f55a3fe8f908a6/content.htm?no_cache=true
I do not think it will not to add a column for the party name.

18

I see SAP also include the party name but I see this is not used on the Belgium reports. Maybe this is the main difference?

Sorry but I do not understand.

19

Oups double negation. I mean: I do not think it will hurt to add a column for the party name.