Spanish VAT listing

accounting

(Sergi Almacellas Abellana) #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


Replace mailing list by discuss
(Cédric Krier) #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.


(Sergi Almacellas Abellana) #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:


(Cédric Krier) #4

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


(Sergi Almacellas Abellana) #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

(Cédric Krier) #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.


(Jose Salvador) #7

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


(resteve) #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

(Sergi Almacellas Abellana) #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

(Sergi Almacellas Abellana) #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?


(Cédric Krier) #11

It will depend if this code exists in other countries.