View source | View content page | Page history | Printable version   

Projects:Intrastat/Functional Document

Contents

Functional Specification: Intrastat Spain

Section 1: Overview & Justification

Purpose:

The purpose of this document is to describe the functional specifications for a new extension module which is the “Spanish Intrastat”.

Intrastat is a statistical declaration of goods trade within the European Union.

The purpose of the Intrastat is to provide tax authorities with good movements information within European Union after European Union customs removal in 1993.

Intrastat report must be sent to the Tax Authorities monthly, within the 12 natural days of the corresponding month after the month in which the transactions were done.

Intrastat declaration must be sent through the INTERNET – on line submission of a valid Intrastat file.

On line submission implies that the Spanish companies must have a Tax ID as well as a user Certificate X.509.V3 issued by FNMT or any other valid Certificate according to tax authorities requirements.

There are 3 ways of submission:

This is the way of submission current feature must implement. Please see Scope section.

This way of submission is out of scope. Please see Scope section.

There are several type of Intrastat declarations according to the tax requirements.

It is important to note that for more information regarding how each Intrastat Declaration type is going to be handled, Persona based scenarios must be taken into account.

1.- “Normal declaration” declarations for both acquisition and delivery transactions.

2.- “Complementary declaration” declarations for those cases in which some transactions were not included in a normal declaration regardless those one should have been included.

3.- “No transactions declaration”for those tax payers who must mandatory submit Intrastat regardless of not having any transaction/operation to submit for a particular period (month).

4.- “Corrective declaration” including corrective transactions already included in a previous declaration but this time being corrected.

5.- “Void declaration” to void a previous declaration totally or partially due to goods returns which could be total or partial returns of goods. In the cases of a partial good returns there is no need to declare it unless it can be added as a contrary goods flow, that means that a partial delivery of goods return should be declared as an acquisition of goods.

Intrastat module information is listed below:

Module Help= “Spanish Intrastat feature will allow Spanish companies to provide statistical information related to goods trade within the EU as a valid txt file according to Spanish Intrastat requirements, to be submitted to the tax authorities regularly; by EU goods trade it is meant the goods exchange (From/To) Spain, excluding Canary Island and the rest of EU countries”

It is up to the development team to decide how to implement this functionality, therefore additional projects/modules could be create.

This new feature is going to be developed and delivered as a new extension module which will be part of the ES Localization Professional Pack v 1.3; which will be implemented according to the Technical Documentation which can be found here : <Technical Design link>

Scope:

In Scope:

Spanish Intrastat feature will allow the Spanish companies to provide statistical information related to goods trade within the EU as a valid txt file to be submitted to the tax authorities regularly; by EU goods trade it is meant the goods exchange (From/To) Spain, excluding Canary Island and the rest of EU countries.

Spanish Intrastat must be submitted to the tax authorities as a valid Intrastat txt file which must contain a maximum of 1000 transactions otherwise an additional new valid txt file will have to be created for those transactions up to 1000.

As we will submit Intrastat as a valid txt file below type of Intrastat declaration will be supported:

For more information see persona based scenarios section below.

It is also in scope to provide the end-user with the list of transactions to be included in an Intrastat report for a given period as a txt file so end-user can review them before generating the txt file; besides the systems should also track which transactions have been submitted in an Intrastat report for a given period.

It is important to note that as we are talking about exchange of goods therefore:

Out of scope:

Corrective declarations as Void declarations will be used instead. See persona based scenarios.

EDIFACT telematic presentation for those cases of submitting more that 1000 transactions.

Completed and posted AP and AR credit memos document type will not be taken into account as those ones do not reflect goods returns but just goods credits due to discounts or rappels.Corrective invoices will not be taken into account as that functionality is not existing in OB.

In relation to Goods Return, it is important to remark that:

Partial and Total goods return will be taken into account while generating Intrastat declaration lines.

In case of a company having just 1 Intrastat flow (Acquisitions) to submit to the tax authorities, partial goods return will have to be removed manually by the end-user from Intrastat lines (Acquisition) declaration as there is no way to distinguish them and only total return of goods must be submitted to the tax authorities in case of having just 1 flow to submit.

It is currently out of scope "Operaciones Triangulares" but it could be later on implemented, see Feature Request 12447

Justification:

Spanish Intrastat is a statistical declaration of goods trade (purchase and sales) within the European Union, excluding Canary islands.

There are some type of goods such as gold, emergency goods and others which are not supposed to be taken into account. This list of goods can be found in the “27th January Law - Annex I”

Spanish Intrastat must be submitted on a monthly basis within the 12 days of the next month and it must contain the corresponding transaction for each month.


Spanish Intrastat must be submitted in the cases described below, excluding those tax payers who did not exceed total Sales or Purchase invoice amount limit during the corresponding “previous” year regardless it will become mandatory as soon as that limit is exceeded during “current” year:

1.- those tax payers subject to VAT in Spain who exchange goods within the EU, regardless whether they are located or not in Spain.

2.- those tax payers who receive (Intracommunity acquisitions) or send (Intracommunity deliveries) goods equal or over to a total invoiced amount of 250.000,00 € each (yearly amount limit); as each kind of transaction (acquisition or delivery) must be submitted separately.

It is also important to remark that those ones who have to mandatory submit Intrastat will get it submitted each period required regardless there is not any transaction to be submitted for a particular period/month. That means Intrastat should be submitted as “No-transaction” Intrastat declaration type. Same applies in those case in which all transactions reported where returned for whatever kind of reason, in that case a Void declaration must be submitted and a “No-transaction” Intrastat declaration must be submitted instead.

3.- There is another limit amount which is known as statistical limit amount (6.000.000,00€); in case of a company having either purchase or sales transaction over that amount limit Spanish Intrastat declaration must also contain “Statistical Value”.


The applicable legislation is listed below:

New definitions and acronyms:

AEAT=> Acronyms for the Spanish Public Treasury = “Agencia Estatal de Administración Tributaria”

“I”=>Intracommunity acquisitions, in Spanish “Introducción or Flujo de Introducción” = Intrastat (Arrivals) = ACQUISITIONS.

“E”=>Intracommunity deliverables, in Spanish “Expedición or Flujo de Expedición” = Intrastat (DispatchS) = SHIPMENTS

Intrastat => Spanish Intrastat (going forward)

Section 2: Users & business process description

User goals

Intrastat transactions

Intrastat feature will allow the end user to get a list of Intra-Community transactions to be included in the corresponding Intrastat declaration (either Acquisitions/Purchase or shipments/Sales) for a given period of time (month) therefore each declaration can be reviewed by the end-user.

Spanish Intrastat in case of Acquistions or Introductions transactions must list the transactions listed below, in case of a company requested to submit to the tax authorities both Intrastat declarations (Acquisitions and shipments):

In case just the Intrastat for Acquisition must be submitted, it will include AP invoices and negative AP invoices

Spanish Intrastat in case of Sales or shipments transactions must list the transactions listed below, in case of a company requested to submit to the tax authorities both Intrastat declarations (Acquisitions and shipments):

In case just the Intrastat for shipments must be submitted, it will include AR invoices and negative AR invoices

These lists of transactions must be shown in the corresponding new windows in OB.

Each window must contain several columns, those columns must be at least the same as the fields required by the Intrastat txt file. See section 2.1.2 Intrastat txt file.

Those columns/fields must be editable in case the end user needs to change any value, system should check that as a manual change.

Intrastat txt file

Intrastat feature will allow the end user to submit to the tax authorities those transactions (statistical goods trade information) as a valid txt file containing below information.

Same structure applies to both Introductions and shipments Spanish Intrastat declarations as described below:

Field name

(in Spanish)

Field name

(in English)

Field type/

Positions

Possible values Mandatory

(YES/NO)

Global/Spain
“Estado miembro

procedencia / destino”

Consignment country (Introductions)

Destination Country

(shipments)

An

2 positions

Country ID Reference list:

FR- Francia

BE-Bélgica

LU- Luxemburgo

NL- Países Bajos

DE-Alemania

IT- Italia

GB- Reino Unido

IE- Irlanda

DK- Dinamarca

GR- Grecia

PT- Portugal

ES- España

SE- Suecia

FI- Finlandia

AT- Austria

PL- Polonia

EE- Estonia

LV- Letonia

LT- Lituania

HU- Hungría

CZ- República Checa

SK- Eslovaquia

MT- Malta

CY-Chipre

SI- Eslovenia

RO- Rumania

BG- Bulgaria

Country id must be taken from Business Partner – Location/Address tab – Country field

yes Global
“Provincia procedencia / destino” Destination Spanish region in case of Introductions

Consignment Spanish region in case of shipments

Num

2 positions

Region ID Reference list:

See annex 1 below – Spanish Regions

Region id must be taken from Spanish Business Partners, Location/Address tab – Region field.

yes Spain
“Condiciones de entrega” Incoterms or Delivery Terms An

3 positions2

Reference list to be created:

EXW- En la fábrica

FCA- Franco transportista

FAS-Franqueo al costado del buque

FOB-Franco a bordo

CFR-Coste y flete (C&F)

CIF-Coste, seguro y flete

CPT- Porte pagado hasta

CIP-Porte pagado, incluido seguro, hasta

DAF- Franco frontera

DES-Franco “ex ship”

DEQ- Franco muelle

DDU- Franco sin despachar en aduana

DDP- Franco despacho en aduana

XXX – Condiciones de entrega distintas de las anteriores

yes Global
“Naturaleza Transacción”


Nature of Transaction code Num

2 positions

Reference list to be created:

Possible values as a combination of columns “A” and “B” as shown in annex 2 below (11, 12, 13, 14, 15, 12, 22, 23, 31, 32, 33, 34, 40, 50, 70, 80 or 90)

See annex 2 below – Nature of Transaction Code

yes Spain
“Modalidad de

transporte”

Transportation type Num

1 position

Reference list to be created:

1 – Transporte marítimo (Sea)

2 – Transporte por ferrocaril (Rail)

3 – Transporte por carretera (Road)

4 – Transporte aéreo (Air )

5 – Envíos potales (Postal consignment)

6 – Not used

7 – Instalaciones fijas de transporte

(Fixed transport installations)

8 – Transporte de navegación interior

(Inland waterway transport)

9 – Autopropulsión (Own propulsion)

yes Global
Puerto / Aeropuerto carga / descarga Port / Airport Num

4 positions

Reference list to be created:

See annex 3 - Port/Airport

yes Spain
“Código de mercancía” ICN code

(Commodity code)

Num

8 positions

Free text field to be filled by end-user according to “NC8 nomenclature”

by example: 85182190

The Commodity Code is an 8 digit number taken from the Intrastat Classification Nomenclature (ICN) which is common to all EU countries.

In the link below 2009 valid nomenclature can be found:

http://www.aeat.es/AEAT/Aduanas/Contenidos_Privados/Intrastat/nc_2009.xls

yes n/a
“País de origen”


Consignment country

(Introductions)

An

2 positions

Reference List:

See annex 4 – Consignment country

Country id must be taken from Business Partner – Location/Address tab – Country field

yes Global
“Régimen estadístico” Statistical Regimen Num

1 position

Reference lists to be created.

Reference List in case of Acquisitions:

1-Llegadas de mercancías comunitarias con destino final en el Estado miembro de introducción.

2 – Llegadas temporales de mercancías comunitarias para ser reexpedias al Estado miembro de procedencia o a otro Estado miembro, en el mismo estado en que llegaron.

3 – Llegadas temporales de mercancías comunitarias para ser reexpedidas al Estado miembro de procedencia o a otro Estado miembro, después de sufir una operación de transformación.

4 – Llegadas de mercancías comunitarias, devueltas en el mismo estado en el que fueron previament expedidas al Estado miembro de procedencia o a otro Estados miembros.

5 – Llegadas de mercancías comunitarias, devueltas después de haber sufrido una operación de reparación o transformación, previamente expedidos al Estado miembro de procedencia o a otro Estado miembro

Reference list in case of Deliveries:

1 – Salida de mercancía comunitarias con destino final en el Estado miembro de destino.

2 – Salida temporal de mercancías comunitarias para ser reintroducidas con posterioridad desde el Estado miembro de destino o desde otro Estado miembro en el mismo estado en que son expedidas.

3 – Salida temporal de mercancías comunitarias para ser reintroducidas con posterioridad, desde el Estado miembro de destion o desde otro Estado miembro después de haber sufrido una operación de reparación o transformación.

4 – Salida de mercancías comunitarias, que se devuelven en el mismo estado en el que previamente llegaron procedentes del Estado miembro de destino o procedentes de otro Estado miembro.

5 – Salida de mercancías comunitarias, que se devuelven después de haber sufrido una operación de transformación, previamente recibidas del Estado miembro de destino o de otro Estado miembro.

yes Spain
“Masa neta en kilos” Net mass (Kg) Num

12 integer + 3 decimals (comma separator)

Free text field to be filled by end-user or either calculated by the system based on conversion rate + supplementary units Yes

mainly in case supplementary units are required.

n/a
“Unidades Suplementarias” Supplementary units Num

12 integer + 3 decimals (comma separator)

Free text field to be filled by end-user for those items (ICN code) for which a supplementary unit of measure is required.

See annex 5 – Supplementary units of measure

Yes

mainly in case supplementary units are required.

Spain
“Importe linea factura” Invoice line amount Num

13 integers + 2 decimals (comma separator)

Output field yes n/a
“Valor estadístico” Statistical value Num

13 integers + 2 decimals (comma separator)

Free text field to be filled by end-user per each line.

The technical definition of the Statistical Value is;- the invoice value of the goods adjusted in the case of Imports to a CIF basis, and in the case of exports to a FOB basis.

No

but in case invoice total amount per Nature of Transaction Code is over 6.000.000,00€

n/a

Intrastat txt file required that the fields are separated by “;” and in case a field is empty it should also be there and separated by “;” as shown in the example below:

FR;31;FOB;11;3;;85182190;CN;1;115;162;15,37;15,37

DE;28;CIF;11;1;0811;85182190;US;1;2459;1982;4589,46;4589,46

IT;12;FOB;11;3;;02012030;;1;800;;987,00;890,45

An example of an empty files are the ones listed below:

Annex 1 – Spanish Regions

“Código” = Spanish region id

“Provincia” = Region description

Spanish regions.png

Annex 2 – Nature of Transaction Code

Most common Nature of Transaction Code are:

11 – in case of purchase/sales and 21 in case of purchase/sales returns.

NatureOfTrnasctions.png

Annex 3 – Port/Airport

“Código” = Spanish region id

“Provincia” = Region description

PortAirport1.png

PortAirport2.png

Annex 4 – Consignment country

Pages 14482, 14483, 14484, 14485 and 14486 of document below

http://www.aeat.es/AEAT/Contenidos_Comunes/La_Agencia_Tributaria/Normativas/Ficheros_Asociados_a_Las_Normativas/Legislacion_de_Aduanas_e_Impuestos_Especiales/Ficheros2009/Resolucion27enero09.pdf

Annex 5 – Supplementary Units of Measure (Supplementary UOM)

Supplementary units ID Supplementary Units description
BO BOMBONA
BR ARQUEO BRUTO
CE CENTENAS (100 UNIDADES)
CL NUMERO DE CELDAS
CT CAPACIDAD CARGA UTIL EN TONELADAS METRICAS
GI GRAMOS ISOTOPOS FISIONABLES
GN GRAMOS NETOS
HA GRADO ALCOHOLICO VOLUMENTRICO POR NÚMERO DE HETOLITROS
HG HETOLITROS DE ALCOHOL PURO 100%
HL HECTOLITROS
HM HECTOMETROS
HP HECTOLITRO x GRADO PLATO
H1 HECTOKILOGRAMOS DE AZUCAR BLACA (100kg)
H2 HECTOKILOGRAMOS DE TRIGO BLANCO (100kg)
H3 HECTOKILOGRAMOS NETO DE MATERIA SECA (100kg)
H4 HECTOKILOGRAMOS NETOS POR FRACIÓN DEL 1% DEL PESO
EN SACAROSA
H5 HECTOLILOGRAMOS DE PESO VIVO
KA KILOGRAMOS TOTAL ALCOHOL
KL MILES DE LITROS
KN KILOGRAMOS NETOS
KP KILOGRAMO DE MATERIA LACTICA
KT KILOGRAMO DE MATERIA SECA LACTICA
LA LITROS DE ALCHOHOL PURO 100%
LT LITROS
M1 METROS LINEALES
M2 METROS CUADRADOS
M3 METROS CUBICOS
M4 MIL METROS CUBICOS
MI MILLARES
MK MILES KILOVATIOS/HORA
PA NUMERO DE PARES
QE QUINTALES DE PESO NETO ESCURRIDO
QN QUINTALES NETOS
TA TONELADAS DE CLORURO POTASICO
TB TONELADAS NETAS DE MATERIA SECA
TC TONELADA NETA POR FRACCIÓN DEL 1% DEL PESO
TJ TERAJOULE
TN TONELADAS NETAS
UN UNIDADES
WA KILOGRAMOS NETOS DE DIHIDROESTRETOMICINA
WB KILOGRAMOS NETOS DE COLINCLORURO
WE KILOGRAMOS DE PESO NETO ESCURRIDO
WL NUMERO DE QUILATES
W1 KILOGRAMOS NETOS DE K20 (OXIDO DE POTASION)
W2 KILOGRAMOS NETOS DE KOH (HIDROXIDO DE POTASION)
W3 KILOGRAMOS NETOS DE N (NITROGENO)
W4 KILOGRAMOS NETOS DE NaOH (HIDROXIDO DE SODIO)
W5 KILOGRAMOS NETOS DE P205 (PENTAOXIDO DE DIFOSFORO)
W6 KILOGRAMOS NETOS DE U (URANIO)
W7 KILOGRAMOS NETOS DE MATERIA SECA AL 90%
W8 KILOGRAMOS NETOS DE AGUA OXIGENADA H2O2
W9 KILOGRAMOS DE METILAMINA

User Roles and Personas :

The following roles are involved:

Sales staff (Mike): Mike is an employee part of the sales staff. He will be the one entering sales transactions as appropriate, which should be part of the Intrastat tax report in the end.

Purchase staff (Alice): Alice is an employee part of the purchase staff. She will be the one entering purchase transactions as appropriate, which should be part of the Intrastat tax report in the end.

Business scenario/s:

Small Bazaar is an enterprise located in Spain made of several subsidiaries. Small Bazaar Holding is the parent company while, Small Bazaar Pamp and Small Bazaar Barc are two subsidiaries. Each subsidiary is modeled in OB ERP as a legal entity organization.


January Sales transactions:

Dated on January 2009, Mike is aware of the fact that the Total Intra-Community Sales Amount for fiscal year 2008 was up to 250.000,00€, therefore Small Bazaar must submit Intrastat (Sales) to the tax authorities.

On January 7th Mike issues a sales invoice to an EU customer A. Sales invoice amount is 10,000.00€

On January 25th Mike issues a sales invoice to an EU customer B. Sales invoice amount is 15,000.00€

On January 27th Mike issues a sales invoice to an EU customer A. Sales invoice amount is 35,000.00€

On January 30th Mike issues a sales invoice to an EU customer C. Sales invoice amount is 56,550.20€

Total Intra-Community Sales Invoice amount in January 2009 = 116.550,20€


On February 12th Mike will launch the Intrastat (Sales) statistical declaration to check if EU sales transactions listed above are properly collected for the period from Jan 1st to Jan 31st and therefore can be submitted to the tax authorities as requested.

Mike should submit above sales transactions to the tax authorities as a valid Intrastat txt file according to Intrastat requirements.


January Purchase transactions:

Alice is aware of the fact that the Total Intra-Community Purchase Amount for fiscal year 2008 was NOT up to 250.000,00€, in other words, Small Bazaar is not supposed to submit Intrastat (Purchase) to the tax authorities.

On January 8th Alice enters in the system a purchase invoice from EU vendor Z. Purchase amount is 2,500.00€

On January 10th Alice enters in the system a purchase invoice from EU vendor D. Purchase amount is 5,500.00€

On January 20th Alice enters in the system a purchase invoice from EU vendor Z. Purchase amount is 2,500.00€

Total Intra-Community Purchase Invoice amount in January 2009 = 10.500,00€


This time Alice does not need to launch the Intrastat (Purchase) statistical tax report as she does not need to submit any type of Intrastat (Purchase) declaration based on Intrastat Limit amount do not exceeded.


February Sales Transactions:

There have not been any Intra-Community Sales transactions during February but Intrastat (Sales) must be submitted as 2008 Total Intra-Community Sales amount exceeded 250.000,00 €.

If that is the case Mike should submit a “No transactions Intrastat declaration” for February period. That declaration must be submitted dated on March 12th


February Purchase Transactions:

There have not been any Intra-Community purchase transactions during February.

This time Alice does not need to launch the Intrastat (Purchase) statistical tax report as she does not need to submit any type of Intrastat declaration based on Intrastat amount limit not exceeded 250.000,00 € once again.


March Sales transactions:

On March 10th Mike issues a sales invoice to an EU customer A. Sales invoice amount is 110,000.00€

On March 15th Mike staff issues a sales invoice to an EU customer B. Sales invoice amount is 5,000.00€

On March 18th Mike issues a sales invoice to an EU customer A. Sales invoice amount is 45,000.00€

Total Intra-Community Sales Invoice amount in March 2009 = 166.000,00€


On April 12th Mike will launch the Intrastat (Sales) statistical tax report to check if EU sales transactions listed above are properly collected for the period from March 1st to March Jan 31st and therefore can be submitted to the tax authorities as requested.

Mike should submit above sales transactions to the tax authorities as a valid Intrastat txt file according to Intrastat requirements.


March Purchase transactions:

2009 Total Intra-Community Purchase have exceeded Intrastat (Purchase) limit.

In that scenario Intra-Community purchase transactions done during March should be submitted to the tax authorities, regardless 2008 Total Intra-Community Purchase did not exceed Intrastat (Purchase) limit.

Section 3: Functional requirements

Functional Requirement 1 – Set up

Products Setup

As described below there are a few new “Intrastat” related field which needs to be added in the application path: Master Data Management / Product – under a new tab named “Intrastat”


Client System should show the corresponding Client or Legal entity for which current Intrastat info is being setup for the product. This field must not be editable.
Organization System should show the corresponding Organization for which current Intrastat info is being setup for the product. This field must not be editable
Product System should show here the product for with Intrastat info is being setup. This field must not be editable.
ICN code Text Field.

The end-user must enter here the “Intrastat Classification Nomenclature (ICN)” as a Free 8 text field according to “NC8 nomenclature” by example: 85182190.


This value will be inherit by each purchase/sales transaction line that the item is included in.

Has Supplementary units? Check field (Yes/No)


In case Yes is the option selected below fields will be shown.


In case NO is the option selected below fields will not be shown and only Net Mass in KG will be the data to report as part of Intrastat lines information for an item.

Supplementary UOM Reference List

The end-user must select here the corresponding Supplementary unit of measure from the Supplementary Unit of Measure reference list for those items for which a supplementary unit of measure is requested.


This value will be inherit by each purchase/sales transaction line that the item is included in so supplementary units can be entered by the end-user as quantity and therefore collected by Intrastat declaration.

Conversion rate to Supplementary UOM End-user must enter here the conversion rate from the corresponding item UOM to the Supplementary UOM.
Conversion rate to Net Mass (Kg) End-user must enter here the conversion rate from the corresponding Supplementary UOM to Kg.

“Supplementary units” reference list must be created as a new window under the application path “Master Data Management – Product Setup – “Spanish Intrastat Supplementary UOM“ so the end user can add new supplementary units in case needed and in case it is applicable.

Calendar Setup

A new flag is needed for the end-user to be able to setup which Fiscal Calendar will be the ones to be used while launching Intrastat declarations.

This new flag need to be created under below application path:

Financial Management / Accounting / Setup / Fiscal Calendar – Calendar tab

And it should be named “Valid for Intrastat” and it should be set as Yes by default, see screen below:

Calendar.png

Only those calendars marked as “Valid for Intrastat” will be shown while setting-up Intrastat at Organization level, see section 3.1.3 below.

Document type Setup

End-user could setup Document types by linking them to the corresponding “Statistical Regimen” and “Nature of Transaction”.

For doing that he should go to below application path:

Financial Management || Accounting || Setup || Document Type

Once there 2 new fields must be created as reference list:

Intrastat setup at Organization level

Intrastat must be setup at Organization level based on the fact that there are common info like Intrastat Amount limit, reporting calendar, Incoterms and so on so forth to take into account globally for an organization.

End-user must be able to setup Acquisition Intrastat Declaration as well as Deliveries Intrastat Declaration at organization level and for a correspondent period and taking into account a specific Limit amount as this might change from year to year.

It is important to remark that Intrastat setup window can be manually setup by the end-user but it could only be used to support further Intrastat setup.

For the first time end-user should manually enter Limit amount and YTD reported amount (Intrastat reported amount per each flow).

By example: In the case an end-user start operations and use of Intrastat feature for 2010 year, he/she should also setup Intrastat for 2009 by entering manually 2009 Acquisitions Intrastat setup and then entering both Limit amount = 250.000,00 (limit amount applicable to 2009) and YTD reported amount (2009 Intrastat reported amount for each Intrastat declaration type by example Acquisitions = 358.520,00).

Next times end-user can press “Copy the current setup to next year” and get the system to copy Limit amount and set as not editable YTD reported amount which will be automatically calculated and filled-in by the system based on Intrastat reported amount for a give year.

In our example: end-user must also setup Intrastat for 2010 by clicking “Copy the current setup to next year”. The system will copy Limit Amount from 2009 setup record to 2010 setup record and get YTD reported amount = 0,00. System will recalculated that amount as soon as Intrastat declaration are being processed and sent.

As described below there are several Intrastat related field to be created at application path:

General Setup / Enterprise / Organization, under a new tab named “Intrastat”.

That new window must show below information:

A process button can be created in order to “Copy the current setup to next year” once all info is properly filled-in, in order to facilitate Intrastat Declaration setup for further years.

It is important to highlight that in case both type of Intrastat Declarations have been setup for an Organization and in case YTD amount > Limit amount below must be taken into account:

YTD reported amount detailed explanation:

1.- In the case of 2009 Total Intra-Community Sales Amount exceeding Intrastat (shipments) amount limit, Intrastat (shipments) must be submitted in 2010.

2.- In the case of 2009 Total Intra-Community Sales Amount not exceeding Intrastat (shipments) amount limit, Intrastat (shipments) must not be submitted but just in case 2010 Total Intra-Community Sales Amount up to a given period exceed Intrastat (shipments) amount limit.

3.- In the case of 2009 Total Intra-Community Sales Amount exceeding Intrastat (shipments) amount limit but not having any Intra-Community sales for a given period of time (February 2010 by example) Intrastat (shipments) should also be submitted for February 2010 period but as an Intrastat (shipments) without transactions. For more information see Persona based Scenarios section below.

4.- In the case of either Intra-Community Purchase or Sales in other than € currency, the system should calculate the corresponding amount in €. This scenario applies for goods exchange with an EU country not having € as default currency (by example: Denmark or United Kingdom).

5.- Same applies to Intra-Community Purchase transactions.

Business Partner Setup

As described below there are few new “Intrastat” related fields which needs to be added in the application path: Master Data Management / Business Partner – Customer/Vendor – Intrastat tab, as it is data which could be filled in by the end-user in case it is know in advance for those “EU Business Partners” an Organization is going to exchange goods with.


Client System should show the corresponding Client or Legal entity for which current Intrastat info is being setup for the BP. This field must not be editable.
Organization System should show the corresponding Organization for which current Intrastat info is being setup for the BP. This field must not be editable
Business partner System should show here the BP for with Intrastat info is being setup. This field must not be editable.
Transportation type Reference List. The end-user must select from the “Transportation type” reference list the “Transportation type” used by the EU BP by default.


This value will be inherit by each purchase/sales transaction BP is included in.

Port/Airport Reference List. The end-user must select from the “Port/Airport” reference list the “Port/Airport” used by the EU BP by default.


This value will be inherit by each purchase/sales transaction BP is included in.

Consignment Country Reference List. The end-user must select from the “Consignment Country” reference list the “Consignment Country” used by the EU BP by default in case goods come from a different country than BP consignment country.


This value will be inherit by each purchase/sales transaction BP is included in.

As described below there is an existing field for which we need to add new Delivery Terms (Incoterms) based on Incoterms reference list, under application path: Master Data Management / Business Partner – Customer or Vendor


Delivery terms

(Incoterms)

Reference List. The end-user must select from the “Delivery terms” reference list the “Delivery Terms” used by the EU BP by default.


This value will be inherit by each purchase/sales transaction BP is included in.

Functional Requirement 2 – Purchase and Sales windows changes

Purchase order & Sales order lines changes

There several “Intrastat” related fields which needs to be added in the application path:

Procurement Management – Transactions – Purchase order – Lines tab

and same applies to Sales Management – Transactions – Sales order – Lines tab

For getting that a new tab named “Intrastat” must be created at lines level, in order to place below listed fields:

None of these fields are mandatory at this point and should be split under below sections:

Business Partner info section =>

Delivery terms

(Incoterms)

Reference list field.

The end-user must select Incoterms from the list provided in case it was not setup at BP level

Transportation type Reference list field.

The end-user must select Transportation type from the list provided in case it was not setup at BP level

Port / Airport Reference list field.

The end-user must select Port/Airport from the list provided.

Consigment country

(ONLY PURCHASE)

Reference list field.

The end-user must select Consigment Country from the list provided.

Transaction info section =>

Nature of Transaction The system must fill-in here the Nature of Transaction being setup for the corresponding Document type at the application path: Financial Management Accounting Setup Document Type


This field must be editable.

Statistical Regimen. The system must fill-in here the Statistical Regime being setup for the corresponding Document type at the application path: Financial Management Accounting Setup Document Type


This field must be editable.

Product info section =>

ICN code Once an item is selected in a purchase line, OB must fill in here the “ICN” for the item, which can be found in the application path: Master Data Management / Product-Spanish Intrastat tab – “ICN code” field.
Supplementary UOM? (yes/no) check Once an item is selected in a purchase line, OB must fill in here the right value taking into account what is setup for the product. It could also be modified by end-user at transaction level.
Intrastat Supplementary UOM Once an item is selected in a purchase line, OB must fill in here the “Supplementary unit of measure” for the item if applicable, which can be found in the application path: Master Data Management / Product – Spanish Intrastat tab – “Intrastat Supplementary UOM.
Supplementary UOM units End-user can enter here manually Supplementary UOM units or can be calculated by the system based on Item units to Supplementary UOM conversion rate if applicable.
Net mass End-user can enter here manually Net mass in Kg or can be calculated by the system based on Supplementary UOM to Net Mass (kg) conversion rate if applicable.

Goods receipt & Good Shipment Lines windows

See section 3.2.1 as same applies here. Info entered at purchase level should be inherit here.

None of these fields are mandatory at this point.

Purchase & Sales Invoice Lines windows

See section 3.2.1 as same applies here. Info entered at goods receipt and good shipment level should be inherit here including Statistical Value which is a free text field where user should fill-in the corresponding “Statistical Value” which is the invoice value of the goods including insurance and transportation costs (in case of acquisitions: invoice value of the goods adjusted to a CIF basis; in case of shipments adjusted to FOB basis)

None of these fields are mandatory at this time

Functional Requirement 3 - Intrastat Declaration launcher

A new window must be created to Launch Intrastat and the end-user should be able to enter below information:

Once above data is entered by the end-user, end-user must be able to press either “OK” process button or “Cancel”; in case OK button is press the system will create the corresponding Intrastat Header and Lines, see sections 3.4.1 and 3.4.2, based on Intrastat setup at organization level for each type of Intrastat declaration (Acquisitions/Purchase or shipments/Sales).

Intrastat - Header

Below fields must be included in the header.

Those fields will be automatically populated by taking into account the info entered in the Intrastat Launcher as well as Intrastat setup at organization level.

This section must also contain two process buttons:

Those transactions included in a Final Intrastat declaration for a given period of time must be marked as included for the corresponding period, regardless could be “voided” later on.

Intrastat - Lines

This tab should list the corresponding transactions to be included in the Intrastat txt file for the given period entered by the end-user and according to Intrastat requirements.

Each transactions should include below mandatory data/fields:

Invoice info section – not editable

Transaction info section:

BP info section:

Product info section:

All above fields are mandatory but Statistical value and Origin country in case of Intrastat (Acquisitions) and could be manually modified by the end-user but Invoice section.

Port/Airport should only be mandatory in case of “Sea/Air transportation” from/to Spain.

End-user could enter new transactions manually, those ones will be marked as “Manual Change” as well.

Functional Requirement 5 – Persona based scenarios

Intrastat setup and “Normal” Intrastat declaration generation. Both limit exceeded.

Dated on January 2010, Mike is aware of the fact that the Total Intra-Community Sales Amount for fiscal year 2009 was up to 250.000,00€ therefore Small Bazaar must submit Intrastat (shipments/Sales) to the tax authorities; same applies to Total-Intra Community Purchase amount therefore Small Bazaar must also submit Intrastat (Acquisitions/Purchase) to the tax authorities.

It is important to note that 2009 Sales and Purchase Intrastat must be properly setup and the amount limit of 250.000,00 € must be entered for Small Bazaar Pamplona Org as well as YTD amount reported that year 2009, for each flow.


Intrastat Setup:

For doing that Mike needs to go to “General Setup – Enterprise – Organization – Intrastat tab and enter below information:

New record:

A new record will be automatically created by the system:


New record:

A new record will be automatically created by the system:

Products setup:

While creating the items/goods to be sold or purchase to/from EU Customers, Mike needs to enter below Intrastat related information:


For doing that Mike needs to go to “Master Data Management – Product- Intrastat tab”.


Business Partner setup:

While creating the EU BP customer/vendors to/from which Small Bazaar company is going to exchange goods with, Mike and Alice needs to enter below Intrastat related information in case it is know and in case it is likely to be used for most of the transactions done with a specific BP.


For doing that Mike/Alice needs to go to “Master Data Management – Business Partner setup - Intrastat tab”.

Incoterms (Delivery Terms) can also be entered here in case it is likely to be used for most of the transactions done with a specific BP.


Sales & Purchase transactions:

On January 7th Mike issues a sales invoice to an EU customer A (France).

Sales invoice number 1, 100 units of item A, Sales invoice amount is 10,000.00€


On January 15th Alice enters a purchase invoice coming from an EU vendor A (France).

Purchase invoice number 520, 50 units of item B, Purchase Invoice amount is 28.777,00 €


On January 17th Alice enters a purchase invoice coming from an EU vendor B (Italy).

Purchase Invoice number 786, 300 units of item C, Purchase invoice amount is 145.970,00 €


On January 25th Mike issues a sales invoice to an EU customer B (Italy).

Sales invoice number 2, 560 units of item A, Sales invoice amount is 15,000.00€


On January 27th Mike issues a sales invoice to an EU customer A (France).

Sales invoice number 3, 50 units of item D, Sales amount is 35,000.00€


On January 30th Mike issues a sales invoice to an EU customer C (Germany).

Sales invoice number 4, 60 units of item , Sales amount is 56,550.20€


On January 31st Mike issues a negative sales invoice to EU customer A (France) due to partial good return of 50 units of item A (Sales invoice number 1).

Sales credit invoice number A1, -50 units of item A, Sales credit invoice amount -5.000,00€


On January 31st Alice enters a negative purchase invoice to EU vendor A due to total good returns of 50 units of item B (Purchase invoice number 520)

Purchase credit invoice number A520, -50 units of item B, Purchase credit invoice -28.777,00€


Intrastat Creation/Process/File generation, in case of exceeding both flow limits:

Dated on February 12th Mike must launch the Intrastat (shipments) statistical declaration to check if Intra-Community Sales invoices listed above as well as Intra-Community Purchase credit invoices are properly collected for the given period (from Jan 1st to Jan 31st ) and therefore can be submitted to the tax authorities as a valid txt file.

For doing that Mike needs to go to “Financial Management - Intrastat”, and once there he needs to enter below information:

System will create the corresponding Intrastat header with below information:

System will create the corresponding Intrastat lines with the information/data described in section “3.4.2 Intrastat Lines”, marked as included unless Mike remove that flag, in that case those transactions will not be included as part of Intrastat declaration. Those ones set as not included will be included once again in case of generating a new Intrastat for the same period after voiding the original one.

Mike can review Intrastat lines and can make whatever kind of change in case it is allowed.

He could change by example an Incoterms but he will not be able to change invoice number.


After that end-user can press “Generate file” button, Intrastat status will change to “Processed”.

Intrastat txt file should look like as shown below (as described in section 2.1.2 Intrastat txt file):

FR;31;FOB;11;3;;85182190;CN;1;115;162;45000,00;10000,00

IT;12;FOB;11;3;;02012030;;1;800;;15000,00;15000,00

FR;31;FOB;11;3;;85182190;CN;1;115;162;45000,00;35000,00

DE;28;CIF;11;1;0811;85182190;US;1;2459;1982;56550,20;56550,20

FR;28;CIF;21;1;0811;85182190;US;1;2459;1982;56550,20;28777,00

Intrastat txt file should be submitted by using below Public Treasury web page:

https://www2.aeat.es/L/inwinvoc/es.aeat.dit.adu.adit.intrasw.AltaImpFichW?fAccion=alta

Once there Mike should follow below steps (as described here https://www3.aeat.es/ADUA/internet/aydconsu/aydintr4.htm):

1.- Mike needs to get a valid Certificate in order to submit this kind of files by using the Public Treasury web application.

2.- After selecting the corresponding Certificate he needs to enter Intrastat (Sales) Header information:

- Goods Exchange type: Mike should must “I” in case of Intra-Community purchase transactions reporting and “E” in case of Intra-Community Sales transactions reporting. In this scenario Mike must select “E”.

- Period: Mike must select month and year as applicable.

- Declaration number: By default “1” is shown but it can be modified.

3.- After filling in Header information, Mike must press “Examinar” button to import the Intrastat txt file containing Intrastat Lines he has generated from OB. This file can also be reviewed here.

4.- Last step for Mike to take is to sign and send the file

Dated on February 12th Alice must launch the Intrastat (Acquisitions) statistical declaration to check if Intra-Community Purchase invoices listed above as well as Intra-Community Sales credit invoices are properly collected for the given period (from Jan 1st to Jan 31st ) and therefore can be submitted to the tax authorities as a valid txt file.

For doing that Mike needs to go to “Financial Management - Intrastat”, and once there he needs to enter below information:

System will create the corresponding Intrastat header with below information:

System will create the corresponding Intrastat lines with the information/data described in section “3.4.2 Intrastat Lines”, marked as included unless Alice remove that flag.

Alice can review Intrastat lines and can make whatever kind of change in case it is allowed.

After that end-user can press “Generate file” button, Intrastat status will change to “Processed”.

Intrastat txt file should look like as shown below (as described in section 2.1.2 Intrastat txt file):

FR;31;FOB;11;3;;85182190;CN;1;115;162;45000,00;28777,00

IT;12;FOB;11;3;;02012030;;1;800;;15000,00;145970,00

FR;28;CIF;21;1;0811;85182190;US;1;2459;1982;56550,20;5000,00


“Normal” Intrastat declaration. Limit do not exceeded for Purchase but for Sales.

Dated on January 2010, Alice is aware of the fact that the Total Intra-Community Purchase Amount for fiscal year 2009 was NOT up to 250.000,00€ therefore Small Bazaar is not obligated to submit Intrastat (Acquisitions) to the tax authorities.

Anyway, it is important to note that (Acquisitions) Intrastat must be properly setup and the amount limit of 250.000,00 € must be entered for Small Bazaar as it could be that amount limit is exceed in further years.

For doing that Mike needs to go to “General Setup – Enterprise – Organization – Intrastat tab and enter below information:

New record:

A new record will be automatically created by the system:

Regarding Intrastat (shipments) setup, see above persona based scenario 3.5.1 as there is no change here.

Products setup and BP setup:

See above scenario.

Sales and Purchase Transactions:

On January 8th Alice enters in the system a purchase invoice from EU vendor Z. 100 units of item A. Purchase amount is 2.500,00€

On January 10th Alice enters in the system a purchase invoice from EU vendor D. 50 units of item B. Purchase amount is 5.500,00€

On January 20th Alice enters in the system a purchase invoice from EU vendor Z. 75 units of item C. Purchase amount is 2.500,00€

On January 31st Alice enters in the system a purchase credit invoice for EU vendor Z due to good return of -50 units of Item A. Purchase credit invoice amount is -1.250,00€.

On January 7th Mike issues a sales invoice to an EU customer A (France).

Sales invoice number 10, 100 units of item A, Sales invoice amount is 250,000.00€

On January 25th Mike issues a sales invoice to an EU customer B (Italy).

Sales invoice number 11, 560 units of item B, Sales invoice amount is 630,000.00€

On January 31st Mike issues a negative sales invoice to EU customer B (Italy) due to partial good return of 60 units of item A (Sales invoice number 11). Partial Goods Return.

Sales credit invoice number A11, -60 units of item B, Sales credit invoice amount -15.000,00€

On January 31st Mike enters a negative sales invoice to EU customer A due to total good returns of 100 units of item A (Sales invoice number 10). Total Goods Return.

Sales credit invoice number A10, -100 units of item A, Sales credit invoice -250.000,00€

Dated on February 12th Alice could launch the Intrastat (Acquisitions) statistical declaration to check if Intra-Community Purchase listed above are properly collected for the given period (from Jan 1st to Jan 31st ) and therefore can be submitted to the tax authorities as a valid txt file if applicable.

System should not generate any Intrastat lines for Intrastat (Acquisitions) because YTD amount reported for 2009 (=25.000,00€) did not exceeded the limit amount same as YTD amount calculated so far for 2010 (=9.250,00 = 2.500,00+5.500,00+2.500,00-1.250,00)

System should populate YTD amount for 2010 so far calculated at the application path:

“General Setup – Enterprise – Organization – Intrastat tab – YTD amount (year 2010)

Dated on February 12th Mike could launch the Intrastat (shipments) statistical declaration to check if Intra-Community Sales listed above are properly collected for the given period (from January 1st to January 31st ) and therefore can be submitted to the tax authorities as a valid txt file if applicable.

For doing that Mike needs to go to “Financial Management – Intrastat” , once there she needs to enter below information:

System will create the corresponding Intrastat header with below information:

System will create the corresponding Intrastat lines with the information/data described in section “3.4.2 Intrastat Lines”, marked as included unless Mike remove that flag, in that case those transactions will not be included as part of Intrastat declaration. Those ones set as not included will be included once again in case of generating a new Intrastat for the same period after voiding the original one.

Mike can review Intrastat lines and can make whatever kind of change in case it is allowed.

He could change by example an Incoterms but he will not be able to change invoice number.

After that end-user can press “Generate file” button, Intrastat status will change to “Processed”.

Intrastat txt file should look like as shown below (as described in section 2.1.2 Intrastat txt file):

FR;31;FOB;11;3;;85182190;CN;1;115;162;45000,00;250000,00

IT;12;FOB;11;3;;02012030;;1;800;;15000,00;630000,00


This time only 1 flow (Sales) must be submitted to the tax authorities therefore sales returns will not be included in any Intrastat Acquisition declaration; therefore Intrastat shipments declaration will have to be voided and created once again to include sales goods returns, see scenario below.

“Void” Intrastat declaration. Limit do not exceeded for Purchase but for Sales.

As described in above scenario:

On January 7th Mike issues a sales invoice to an EU customer A (France).

Sales invoice number 10, 100 units of item A, Sales invoice amount is 250,000.00€

On January 25th Mike issues a sales invoice to an EU customer B (Italy).

Sales invoice number 11, 560 units of item B, Sales invoice amount is 630,000.00€

On January 27th Mike issues a negative sales invoice to EU customer B (Italy) due to partial good return of 60 units of item A (Sales invoice number 11). Partial Goods Return.

Sales credit invoice number A11, -60 units of item B, Sales credit invoice amount -15.000,00€

On January 31st Mike enters a negative sales invoice to EU customer A due to total good returns of 100 units of item A (Sales invoice number 10). Total Goods Return.

Sales credit invoice number A10, -100 units of item A, Sales credit invoice -250.000,00€

Dated on February 12th Mike launched Intrastat (shipments) and he got below Intrastat txt file for the sales invoices:

FR;31;FOB;11;3;;85182190;CN;1;115;162;45000,00;250000,00

IT;12;FOB;11;3;;02012030;;1;800;;15000,00;630000,00

Due to the fact that only 1 flow (shipments) must be submitted to the tax authorities, sales return of goods can not be included in any Intrastat declaration (Acquisitions), therefore Mike should follow below steps:

1.- Mike needs to go to Financial Management – Intrastat and create a void declaration by entering below information:

After doing that none of the sales transactions included in previous Intrastat Normal Declaration for 2010 Jan 2010 will be marked as included once again.

2.- Mike needs to launch a new Intrastat Normal Declarations for the same period and this time sales goods returns for that period will be taken into account. Mike should remove partial good returns from the Intrastat Lines.

Purchase/Sales transactions submitted as “No-transaction” Intrastat declaration

There have not been any Intra-Community Sales transactions during February but Intrastat (shipments) must be submitted anyway as a “No-transaction Intrastat” because 2009 Total Intra-Community Sales amount exceeded 250.000,00 €.

Mike needs to submit a No-Transaction Intrastat declaration which can be found here:

https://www2.aeat.es/L/inwinvoc/es.aeat.dit.adu.adit.intrasw.AltaDeclaSinOp?fAccion=alta


Once there Mike should follow below steps (as described here https://www3.aeat.es/ADUA/internet/aydconsu/aydintr2.htm):

1.- Mike needs to get a valid Certificate in order to access to above web link

2.- After selecting the corresponding Certificate he needs to enter Intrastat (Sales) Header information:

- Goods Exchange type: Mike should must “I” in case of Intra-Community purchase transactions reporting and “E” in case of Intra-Community Sales transactions reporting. In this scenario Mike must select “E”.

- Period: Mike must select month and year as applicable.

- Declaration number: By default “1” is shown but it can be modified.

3.- After filling in Header information last step for Mike to take is to sign and send the file

Purchase/Sales transactions submitted as “complementary” Intrastat declaration

Dated on February 12th Mike launched the Intrastat (shipments) statistical declaration as described in above persona base scenario and submitted Intrastat (shipments) declaration as an Intrastat txt file.

Dated on February 20th Mike realized he forgot to enter an Intra-Community Sales invoice which needs to be submitted to the tax authorities as part of January Intrastat (shipments) declaration.

Mike should create the Intra-Community Sales invoice left to be registered in the system and once done, he should launch a Complementary shipments Intrastat for January:

For doing that Mike needs to go to “Financial Management – Intrastat ”, and once there he needs to enter below information:

Once above data is entered Mike needs to press “OK” button.

System will create the corresponding Intrastat header with below information:

System will create the corresponding Intrastat lines (this time only 1 new line) with the information/data described in section “3.4.2 Intrastat Lines”.

After that Mike can press “Generate file” button, Intrastat status will change to “Processed”.

Intrastat txt file should look like as shown below (as described in section 2.1.2 Intrastat txt file):

FR;31;FOB;11;3;;85182191;CN;1;115;162;56000,00;56000,00

Intrastat txt file just created should be submitted once again by using below Public Treasury web page:

https://www2.aeat.es/L/inwinvoc/es.aeat.dit.adu.adit.intrasw.AltaImpFichW?fAccion=alta

Once there Mike should follow below steps (as described here https://www3.aeat.es/ADUA/internet/aydconsu/aydintr4.htm):


1.- Mike needs to get a valid Certificate in order to submit this kind of files by using the Public Treasury web application.

2.- After selecting the corresponding Certificate he needs to enter Intrastat (Purchase) Header information:

- Goods Exchange type: Mike should must “I” in case of Intra-Community purchase transactions reporting and “E” in case of Intra-Community Sales transactions reporting. In this scenario Mike must select “E”.

- Period: Mike must select month and year as applicable.

- Declaration number: In this case Mike must enter here the former Intrastat (shipments) declaration already submitted for the same period.

3.- After filling in Header information, Mike must press “Examinar” button to import the new Intrastat txt file containing Intrastat Line left to be submitted he has generated from OB. This file can also be reviewed here.

4.- Last step for Mike to take is to sign and send the file

Assumptions & Dependencies

Assumptions

N/A

Dependencies

N/A

Design & Technical considerations

Design considerations

Intrastat feature must be implemented as an extended module part of the ES professional localization pack v1.3

Technical constraints

None

To be confirmed by Development Team.

Technical Requirements

See Technical document for this project.


User interface

New User Interface

(image to be included while uploading this Spec in Openbravo Wiki, see screens above)

Intrastat Setup

Intrastat Declaration


User interface changes

(image to be included while uploading this Spec in Openbravo Wike, see screens above)

Product setup

Purchase and Sale Order/Receipt-Shipments/Invoice lines


License

License code description

Intrastat feature must be released under the Openbravo Commercial License (OBCL) as Intrastat is a commercial module

Functionality enabled by the license code

The functionality enable by the license code will be “Intrastat declaration submitted as a valid txt file”

Discussion items

Open discussion items

Closed discussion items

Appendix

Retrieved from "http://wiki.openbravo.com/wiki/Projects:Intrastat/Functional_Document"

This page has been accessed 11,602 times. This page was last modified on 8 June 2012, at 05:28. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.