VAT listing

[Cédric Krier]

Hi,

In Belgium, we have to generate two listing related to the VAT.
The first one is a list of all parties with locale VAT number which were
invoiced during the previous year (civil year). It must include the sum
without taxes of the invoiced amount and the sum of the taxes.
The second is a list of the all parties with EU VAT number (but not
locale) with the sum of invoiced amount (without taxes but the rate is
0%) and a tax code (L, T or S) depending of the operation (service,
goods, triangular goods).

See in french:

https://finances.belgium.be/sites/default/files/downloads/165-725-formulaire-2016.pdf
https://finances.belgium.be/fr/entreprises/tva/declaration/liste_annuelle_clients_assujettis
https://finances.belgium.be/sites/default/files/downloads/165-723-formulaire-2016.pdf
https://finances.belgium.be/sites/default/files/downloads/165-723-directives-2016.pdf

I would like to know if this is general for all EU countries, if the
reports are similar. If so, I will make a proposal for a account_eu
module.

--
Cédric Krier - B2CK SPRL
Email/Jabber: cedric...@b2ck.com
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/

[Sebastien Marie]

On Fri, Aug 04, 2017 at 10:37:30AM +0200, Cédric Krier wrote:
> Hi,
>
> In Belgium, we have to generate two listing related to the VAT.
> The first one is a list of all parties with locale VAT number which were
> invoiced during the previous year (civil year). It must include the sum
> without taxes of the invoiced amount and the sum of the taxes.
> The second is a list of the all parties with EU VAT number (but not
> locale) with the sum of invoiced amount (without taxes but the rate is
> 0%) and a tax code (L, T or S) depending of the operation (service,
> goods, triangular goods).
>

> [...]

>
> I would like to know if this is general for all EU countries, if the
> reports are similar. If so, I will make a proposal for a account_eu
> module.
>

In France, this kind of declaration should be done monthly (and the
format is different from Belgium).

The goods trade declaration is mandatory as soon you are subject to VAT
and you engaged intra- Community trade.

Depending the amount of arrivals and dispatches, the reporting level
changes: beyond €460 000 a detailed declaration is required for arrivals
and dispatches ; whereas below €460 000 a simplified declaration is
enough for dispatches (and no declaration for arrivals).

Some links:
- [fr] http://www.douane.gouv.fr/articles/a10897-notions-essentielles-sur-la-declaration-d-echanges-de-biens
- [en] http://www.douane.gouv.fr/articles/a13025-formalities-for-intra-community-trade

More elements on elements required for detailed/simplified declaration:
- [fr] http://www.douane.gouv.fr/articles/a10896-comment-remplir-sa-declaration-d-echanges-de-biens

Thanks.
--
Sebastien Marie

[Cédric Krier]

It seems France is the only country who is mixing tax reports with
Intrastat.
http://www.asd-int.com/actualites/article/12-deb-vs-intrastat

So I guess France will have to write his own custom intrastat report.

But here, I'm focused on VAT reports only.

[Sergi Almacellas Abellana]

El 04/08/17 a les 10:37, Cédric Krier ha escrit:

> Hi,
>
> In Belgium, we have to generate two listing related to the VAT.
> The first one is a list of all parties with locale VAT number which were
> invoiced during the previous year (civil year). It must include the sum
> without taxes of the invoiced amount and the sum of the taxes.

We have a similar report in spain, which may include all the parties,
which operations are higher than 3.005,06 euros (per party). See:

http://www.agenciatributaria.es/AEAT.internet/en_gb/GI27/informacion.shtml
https://bitbucket.org/trytonspain/trytond-aeat_347/

> The second is a list of the all parties with EU VAT number (but not
> locale) with the sum of invoiced amount (without taxes but the rate is
> 0%) and a tax code (L, T or S) depending of the operation (service,
> goods, triangular goods).

We have a very similar report too where we specify the operation type
for each invoiced amount. See:

http://www.agenciatributaria.es/static_files/AEAT/Contenidos_Comunes/La_Agencia_Tributaria/Ayuda/Disenyos_de_registro/Ayudas/DR_300_a_399/ficheros/NREG-349-2016.docx
https://bitbucket.org/trytonspain/trytond-aeat_349/

>
> See in french:
>
> https://finances.belgium.be/sites/default/files/downloads/165-725-formulaire-2016.pdf
> https://finances.belgium.be/fr/entreprises/tva/declaration/liste_annuelle_clients_assujettis
> https://finances.belgium.be/sites/default/files/downloads/165-723-formulaire-2016.pdf
> https://finances.belgium.be/sites/default/files/downloads/165-723-directives-2016.pdf
>
> I would like to know if this is general for all EU countries, if the
> reports are similar. If so, I will make a proposal for a account_eu
> module.
>


--

Sergi Almacellas Abellana
www.koolpi.com
Twitter: @pokoli_srk

[Cédric Krier]

On 2017-08-07 09:47, Sergi Almacellas Abellana wrote:
> El 04/08/17 a les 10:37, Cédric Krier ha escrit:
> > Hi,
> >
> > In Belgium, we have to generate two listing related to the VAT.
> > The first one is a list of all parties with locale VAT number which were
> > invoiced during the previous year (civil year). It must include the sum
> > without taxes of the invoiced amount and the sum of the taxes.
>
> We have a similar report in spain, which may include all the parties,
> which operations are higher than 3.005,06 euros (per party). See:
>
> http://www.agenciatributaria.es/AEAT.internet/en_gb/GI27/informacion.shtml
> https://bitbucket.org/trytonspain/trytond-aeat_347/
>
>
> > The second is a list of the all parties with EU VAT number (but not
> > locale) with the sum of invoiced amount (without taxes but the rate is
> > 0%) and a tax code (L, T or S) depending of the operation (service,
> > goods, triangular goods).
>
> We have a very similar report too where we specify the operation type
> for each invoiced amount. See:
>
> http://www.agenciatributaria.es/static_files/AEAT/Contenidos_Comunes/La_Agencia_Tributaria/Ayuda/Disenyos_de_registro/Ayudas/DR_300_a_399/ficheros/NREG-349-2016.docx
> https://bitbucket.org/trytonspain/trytond-aeat_349/

I do not understand how this module works.
Could you explain them? What is important is to see what could be put in
common and what is specific etc.

[Sergi Almacellas Abellana]

El 07/08/17 a les 10:01, Cédric Krier ha escrit:

> I do not understand how this module works.
> Could you explain them? What is important is to see what could be put in

> common and what is specific etc.Basically the modules create record table that is filled for each
invoice. This record table is quite similar to the file format which is
used to send
the information to the tax authorities.

If this data is computed by the new module, our module can read most of
it's data from there. Maybe we can compute it from account.invoice.tax
table.

For the Spain Parties report we compute the following information:

https://bitbucket.org/trytonspain/trytond-aeat_347/src/026fe12cfc2340b56ffd9dd8c2c2563bd5758b2f/invoice.py?at=default&fileviewer=file-view-default#invoice.py-160

For the EU parties report we compute the following information:

https://bitbucket.org/trytonspain/trytond-aeat_349/src/54658e4c5ebde8be3061820e3358eb4985566989/invoice.py?at=default&fileviewer=file-view-default#invoice.py-305


For the EU parties report, we also have a "mapping", which defines the
report key that must be used of each invoice tax. I don't know if we can
find something generic here. For the Spain Parties report, the key used
depends on the invoice type

P.S: Probably the design of both modules can be improved.

[Cédric Krier]

On 2017-08-07 11:04, Sergi Almacellas Abellana wrote:
> El 07/08/17 a les 10:01, Cédric Krier ha escrit:
> > I do not understand how this module works.
> > Could you explain them? What is important is to see what could be put in
> > common and what is specific etc.Basically the modules create record table that is filled for each
> invoice. This record table is quite similar to the file format which is
> used to send
> the information to the tax authorities.
>
> If this data is computed by the new module, our module can read most of
> it's data from there. Maybe we can compute it from account.invoice.tax
> table.
>
> For the Spain Parties report we compute the following information:
>
> https://bitbucket.org/trytonspain/trytond-aeat_347/src/026fe12cfc2340b56ffd9dd8c2c2563bd5758b2f/invoice.py?at=default&fileviewer=file-view-default#invoice.py-160
>
> For the EU parties report we compute the following information:
>
> https://bitbucket.org/trytonspain/trytond-aeat_349/src/54658e4c5ebde8be3061820e3358eb4985566989/invoice.py?at=default&fileviewer=file-view-default#invoice.py-305

It looks like the "operation key" is really a similar concept to the
Belgian tax code.

> For the EU parties report, we also have a "mapping", which defines the
> report key that must be used of each invoice tax. I don't know if we can
> find something generic here. For the Spain Parties report, the key used
> depends on the invoice type

Can you explain the mapping?

[Sergi Almacellas Abellana]

El 07/08/17 a les 11:23, Cédric Krier ha escrit:

>> For the EU parties report, we also have a "mapping", which defines the
>> report key that must be used of each invoice tax. I don't know if we can
>> find something generic here. For the Spain Parties report, the key used
>> depends on the invoice type
> Can you explain the mapping?

On each tax we define two things:

- A Many2Many with the list of available operations keys
- The default operation key for this tax.

Our module has an optional dependency with the Spanish chart of
accounts, which fill this data from the chart templates when creating
the chart of accounts.

[Cédric Krier]

I do not understand. Could you give concrete example (not linked to
module implementation).

[Sergi Almacellas Abellana]

El 07/08/17 a les 12:00, Cédric Krier ha escrit:

> I do not understand. Could you give concrete example (not linked to
> module implementation).

The tax mapping it's used for two things:

1. Proposing a default operation key to the user depending on the taxes
selected on the invoice.
2. Restricting the available operation keys. In Spain there are some
keys that are only available for "in" invoices and others for "out"
invoices. As each tax has the "sale" or "purchase" kind, we define the
available keys on it. All the taxes that are not related to
intracomunitary operations have an empty keys, so no operation key can
be selected for this invoices.

[Cédric Krier]

But why do you need more than 1 key per tax?
How do you select the key? Based on which criteria?

[Sergi Almacellas Abellana]

El 07/08/17 a les 12:40, Cédric Krier ha escrit:

> On 2017-08-07 12:14, Sergi Almacellas Abellana wrote:
>> El 07/08/17 a les 12:00, Cédric Krier ha escrit:
>>> I do not understand. Could you give concrete example (not linked to
>>> module implementation).
>> The tax mapping it's used for two things:
>>
>> 1. Proposing a default operation key to the user depending on the taxes
>> selected on the invoice.
>> 2. Restricting the available operation keys. In Spain there are some
>> keys that are only available for "in" invoices and others for "out"
>> invoices. As each tax has the "sale" or "purchase" kind, we define the
>> available keys on it. All the taxes that are not related to
>> intracomunitary operations have an empty keys, so no operation key can
>> be selected for this invoices.
> But why do you need more than 1 key per tax?

No, only one.

> How do you select the key? Based on which criteria?

We select the default key, based on which is most commonly used, but the
user can customize the key as it may be a different one.

But if we have to choose one key criteria it will be probably the tax,
so each tax will have it's own key.

[Cédric Krier]

On 2017-08-07 13:16, Sergi Almacellas Abellana wrote:
> El 07/08/17 a les 12:40, Cédric Krier ha escrit:
> > On 2017-08-07 12:14, Sergi Almacellas Abellana wrote:
> >> El 07/08/17 a les 12:00, Cédric Krier ha escrit:
> >>> I do not understand. Could you give concrete example (not linked to
> >>> module implementation).
> >> The tax mapping it's used for two things:
> >>
> >> 1. Proposing a default operation key to the user depending on the taxes
> >> selected on the invoice.
> >> 2. Restricting the available operation keys. In Spain there are some
> >> keys that are only available for "in" invoices and others for "out"
> >> invoices. As each tax has the "sale" or "purchase" kind, we define the
> >> available keys on it. All the taxes that are not related to
> >> intracomunitary operations have an empty keys, so no operation key can
> >> be selected for this invoices.
> > But why do you need more than 1 key per tax?
> No, only one.
> > How do you select the key? Based on which criteria?
>
> We select the default key, based on which is most commonly used, but the
> user can customize the key as it may be a different one.

Please be more specific. I do not understand how this key is selected.

> But if we have to choose one key criteria it will be probably the tax,
> so each tax will have it's own key.
--

[Sergi Almacellas Abellana]

El 07/08/17 a les 13:25, Cédric Krier ha escrit:

> On 2017-08-07 13:16, Sergi Almacellas Abellana wrote:
>> El 07/08/17 a les 12:40, Cédric Krier ha escrit:
>>> On 2017-08-07 12:14, Sergi Almacellas Abellana wrote:
>>>> El 07/08/17 a les 12:00, Cédric Krier ha escrit:
>>>>> I do not understand. Could you give concrete example (not linked to
>>>>> module implementation).
>>>> The tax mapping it's used for two things:
>>>>
>>>> 1. Proposing a default operation key to the user depending on the taxes
>>>> selected on the invoice.
>>>> 2. Restricting the available operation keys. In Spain there are some
>>>> keys that are only available for "in" invoices and others for "out"
>>>> invoices. As each tax has the "sale" or "purchase" kind, we define the
>>>> available keys on it. All the taxes that are not related to
>>>> intracomunitary operations have an empty keys, so no operation key can
>>>> be selected for this invoices.
>>> But why do you need more than 1 key per tax?
>> No, only one.
>>> How do you select the key? Based on which criteria?
>> We select the default key, based on which is most commonly used, but the
>> user can customize the key as it may be a different one.
> Please be more specific. I do not understand how this key is selected.
>

It depends on the kind of operation. Here are the available keys:

https://bitbucket.org/trytonspain/trytond-aeat_349/src/54658e4c5ebde8be3061820e3358eb4985566989/aeat.py?at=default&fileviewer=file-view-default#aeat.py-37

[Cédric Krier]

Yes they look very similar to the Belgian ones which are link to the tax
in a one2one relation. So I do not understand why one tax could have
many optional keys.

[Sergi Almacellas Abellana]

El 07/08/17 a les 15:19, Cédric Krier ha escrit:

Probably we are missing some taxes, and that's why we allow to change it
latter.

But a direct relation with the tax makes sense for me.

[Albert Cervera i Areny]

Ideally there should be a tax and this would improve some things.
However we aleady have +1000 taxes defined, so we need other changes
before we can use taxes only.

>
> But a direct relation with the tax makes sense for me.
>
>
> --
> Sergi Almacellas Abellana
> www.koolpi.com
> Twitter: @pokoli_srk
>

> --
> You received this message because you are subscribed to the Google Groups
> "tryton" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/tryton/706e928e-923a-2b5a-947f-7b9b5a746670%40koolpi.com.

[Cédric Krier]

On 2017-08-08 18:46, Albert Cervera i Areny wrote:
>
> Ideally there should be a tax and this would improve some things.
> However we aleady have +1000 taxes defined, so we need other changes
> before we can use taxes only.

You are in a Kafkaesque country or you are wrongly using the tax system.

[Sergi Almacellas Abellana]

El 08/08/17 a les 20:07, Cédric Krier ha escrit:

> On 2017-08-08 18:46, Albert Cervera i Areny wrote:
>> Ideally there should be a tax and this would improve some things.
>> However we aleady have +1000 taxes defined, so we need other changes
>> before we can use taxes only.
> You are in a Kafkaesque country or you are wrongly using the tax system.

We have a lot of taxes due to tax rules. Let me explain:

Most of our tax rules are used to add one additional tax to the original
tax. In order to support this, we have a lot of taxes which have two
childs: The original tax + Tax Rule added tax. This is a product of two
lists of all taxes, which makes the list so huge.

I haven't found any way to preserve the original tax when applying a tax
rule. Is this possible?

[Cédric Krier]

Yes, just make TaxRuleLine.get_taxes return more than just the tax id.
I will not be against a standard module that extend tax rule line to
have a list of extra taxes.

[Sergi Almacellas Abellana]

El 09/08/17 a les 10:05, Cédric Krier ha escrit:

> On 2017-08-09 09:41, Sergi Almacellas Abellana wrote:
>> El 08/08/17 a les 20:07, Cédric Krier ha escrit:
>>> On 2017-08-08 18:46, Albert Cervera i Areny wrote:
>>>> Ideally there should be a tax and this would improve some things.
>>>> However we aleady have +1000 taxes defined, so we need other changes
>>>> before we can use taxes only.
>>> You are in a Kafkaesque country or you are wrongly using the tax system.
>> We have a lot of taxes due to tax rules. Let me explain:
>>
>> Most of our tax rules are used to add one additional tax to the original
>> tax. In order to support this, we have a lot of taxes which have two
>> childs: The original tax + Tax Rule added tax. This is a product of two
>> lists of all taxes, which makes the list so huge.
>>
>> I haven't found any way to preserve the original tax when applying a tax
>> rule. Is this possible?
>
> Yes, just make TaxRuleLine.get_taxes return more than just the tax id.

That's what I was wondering, current code have to be extended.

> I will not be against a standard module that extend tax rule line to
> have a list of extra taxes.

I'm wondering if it should not be included on the account module. As
it's only adding one field and not so much lines of code.

[Cédric Krier]

No, KISS.

[Sergi Almacellas Abellana]

El 09/08/17 a les 11:28, Cédric Krier ha escrit:

Indeed i think we can keep it simple. I've written a proposal on:

https://discuss.tryton.org/t/preserve-original-tax-when-appling-tax-rules/397

Which also includes the full rational.

So I think it's better to continue the discussion there.

[Cédric Krier]

On 2017-08-04 10:37, Cédric Krier wrote:
> Hi,
>
> In Belgium, we have to generate two listing related to the VAT.
> The first one is a list of all parties with locale VAT number which were
> invoiced during the previous year (civil year). It must include the sum
> without taxes of the invoiced amount and the sum of the taxes.
> The second is a list of the all parties with EU VAT number (but not
> locale) with the sum of invoiced amount (without taxes but the rate is
> 0%) and a tax code (L, T or S) depending of the operation (service,
> goods, triangular goods).
>
> See in french:
>
> https://finances.belgium.be/sites/default/files/downloads/165-725-formulaire-2016.pdf
> https://finances.belgium.be/fr/entreprises/tva/declaration/liste_annuelle_clients_assujettis
> https://finances.belgium.be/sites/default/files/downloads/165-723-formulaire-2016.pdf
> https://finances.belgium.be/sites/default/files/downloads/165-723-directives-2016.pdf
>
> I would like to know if this is general for all EU countries, if the
> reports are similar. If so, I will make a proposal for a account_eu
> module.

It will be good to here from Germany, Netherlands and Italy (maybe
England).

[Sasa Ostrouska]

I dont know exactly is this is the same as the intrastat declaration. In Italy you have to declare it once

per year, once per month or once per three months , i am not an accountant but I know we do it for all

related operations with EU countires, there is one list for sales and one for purchases. And from what

I see they are quite similar to the once you linked in here.

http://www.agenziaentrate.gov.it/wps/content/nsilib/nsi/home/cosadevifare/dichiarare/dichiarazioni+operazioni+intracomunitarie/elenchi+riepilogativi+intrastat/scheda+informativa+elenchi+intrastat
https://www.agenziadoganemonopoli.gov.it/portale/dogane/operatore/servizi-online/intrastat
https://www.agenziadoganemonopoli.gov.it/portale/documents/20182/908833/AllegatoIII.pdf/effdc7a1-82e8-47a4-913f-e697c19212b5

Rgds

Saxa

[Cédric Krier]

I'm not talking about intrastat which is about goods only.
But I just saw on [1] that Italy and France, they collect with the
Intrastat the EC sales lists.

[1] https://en.wikipedia.org/wiki/Intrastat

[Sasa Ostrouska]

As said, I do not have the perfect understanding of the listings you linked in the first email

as they are in French. The first think I connect up by similarity was the intrastat declaration

which have a very similar form and we have to declare it. I am not sure if it is used for services

too, but I am sure there is no other lists we supply in Italy except the Customers and Suppliers

list where we have to supply all the customers and suppliers list to the tax department, and there

is their VAT number also. But as far as I know this is something declared with the UNICO model

of declaration.

Anyway maybe somebody else more in the accounting business from Italy can tell you this more in detail.

Rgds

Saxa

[Korbinian Preisler]

On 04.08.2017 10:37, Cédric Krier wrote:
> Hi,
>
> In Belgium, we have to generate two listing related to the VAT.
> The first one is a list of all parties with locale VAT number which were
> invoiced during the previous year (civil year). It must include the sum
> without taxes of the invoiced amount and the sum of the taxes.
> The second is a list of the all parties with EU VAT number (but not
> locale) with the sum of invoiced amount (without taxes but the rate is
> 0%) and a tax code (L, T or S) depending of the operation (service,
> goods, triangular goods).
>
> See in french:
>

> https://finances.belgium.be/sites/default/files/downloads/165-725-formulaire-2016.pdf
> https://finances.belgium.be/fr/entreprises/tva/declaration/liste_annuelle_clients_assujettis
> https://finances.belgium.be/sites/default/files/downloads/165-723-formulaire-2016.pdf
> https://finances.belgium.be/sites/default/files/downloads/165-723-directives-2016.pdf
>

> I would like to know if this is general for all EU countries, if the
> reports are similar. If so, I will make a proposal for a account_eu
> module.
>

In Germany only the listing with all parties with EU VAT number is
necessary.

See in german:


http://www.bzst.de/DE/Steuern_International/USt_Kontrollverfahren_ZM_eCommerce/Zusammenfassende_Meldungen/Zusammenfassende_Meldungen_node.html

http://www.gesetze-im-internet.de/ustg_1980/__18a.html