Projects:Intrastat/Functional Document

Contents 1 Functional Specification: Intrastat Spain 1.1 Section 1: Overview & Justification 1.1.1 Purpose: 1.1.2 Scope: 1.1.3 Justification: 1.1.4 New definitions and acronyms: 1.2 Section 2: Users & business process description 1.2.1 User goals 1.2.1.1 Intrastat transactions 1.2.1.2 Intrastat txt file 1.2.2 User Roles and Personas : 1.2.3 Business scenario/s: 1.3 Section 3: Functional requirements 1.3.1 Functional Requirement 1 – Set up 1.3.1.1 Products Setup 1.3.1.2 Calendar Setup 1.3.1.3 Document type Setup 1.3.1.4 Intrastat setup at Organization level 1.3.1.5 Business Partner Setup 1.3.2 Functional Requirement 2 – Purchase and Sales windows changes 1.3.2.1 Purchase order & Sales order lines changes 1.3.2.2 Goods receipt & Good Shipment Lines windows 1.3.2.3 Purchase & Sales Invoice Lines windows 1.3.3 Functional Requirement 3 - Intrastat Declaration launcher 1.3.3.1 Intrastat - Header 1.3.3.2 Intrastat - Lines 1.3.4 Functional Requirement 5 – Persona based scenarios 1.3.4.1 Intrastat setup and “Normal” Intrastat declaration generation. Both limit exceeded. 1.3.4.2 “Normal” Intrastat declaration. Limit do not exceeded for Purchase but for Sales. 1.3.4.3 “Void” Intrastat declaration. Limit do not exceeded for Purchase but for Sales. 1.3.4.4 Purchase/Sales transactions submitted as “No-transaction” Intrastat declaration 1.3.4.5 Purchase/Sales transactions submitted as “complementary” Intrastat declaration 1.4 Assumptions & Dependencies 1.4.1 Assumptions 1.4.2 Dependencies 2 Design & Technical considerations 2.1 Design considerations 2.2 Technical constraints 2.3 Technical Requirements 3 User interface 3.1 New User Interface 3.2 User interface changes 4 License 4.1 License code description 4.2 Functionality enabled by the license code 5 Discussion items 5.1 Open discussion items 5.2 Closed discussion items 6 Appendix

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:

• manually by accessing to the aeat web; this way allows a maximum of 25 records per declaration
  up to 25 records:
  http://www.aeat.es/wps/portal/Listado?channel=a76557c399809110VgnVCM1000004ef01e0a____&ver=L&site=56d8237c0bc1ff00VgnVCM100000d7005a80____&idioma=es_ES&menu=0&img=0
  
• by accessing to the aeat web and importing a valid txt file; this way allows a maximum of 1000 records per declaration, in the link below:
  http://www.aeat.es/wps/portal/Listado?channel=8a7557c399809110VgnVCM1000004ef01e0a____&ver=L&site=56d8237c0bc1ff00VgnVCM100000d7005a80____&idioma=es_ES&menu=0&img=0
  

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

• by creating an EDIFACT file in case of large companies with a huge amount of records, in the link below:
  (http://www.aeat.es/wps/portal/Listado?channel=800dfc44a81f8110VgnVCM1000004ef01e0a____&ver=L&site=56d8237c0bc1ff00VgnVCM100000d7005a80____&idioma=es_ES&menu=0&img=0)
  

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 Name = “Intrastat for Spain”
• Module Description = “Spanish Intrastat declaration to be submitted to the tax authorities as a valid txt file”
• Module language = English and Spanish translation
• Module url = url forge for the project

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”

• Module author = Openbravo SLU
• Module License=OB Commercial License

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:

• Normal declarations – “Normal” declaration must contain Intra-community purchase invoices (AP invoices) and Intra-community sales credit invoices (negative AR invoices) as ACQUISITIONS; and Intra-community sales invoices (AR invoices) and Intra-community purchase credit invoices (negative AP invoices) as SHIPMENTS; in the case of companies which must mandatory submit both type of transactions (introductions and shipments).
• Complementary declarations – “Complementary “ declarations must contain transactions which were not included in an already submitted declaration. In this case the end-user should type “former” Intrastat declaration number as part of the header information before importing the valid txt file including missing transactions (Intra-community purchase/sales invoices)
• Corrective declarations - An Intrastat declaration can be corrected due to errors or due to total return of goods in case it has less than 100 hundred transactions by using AEAT web “Consulta y Actualización de Declaraciones”, otherwise a void declaration must be used.
• Void declarations – Void declarations are used to submit Intra-community sales/purchase credit invoices in case of total return of goods for those companies which do not have to mandatory submit both type of transactions (introductions and shipments) but just one. Partial return of goods do not need to be submitted. Same applies in those cases in which a declaration was submitted by error or in case all transactions reported were totally 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.

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:

• Completed and posted AP invoices (Introductions) and AR invoices (shipments) will be taken into account as good acquisitions and good deliveries transactions respectively
• and completed and posted negative AP invoice (shipments) and negative AR invoices (Introductions) will be taken into account as goods returns transactions respectively
  

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 “27^th 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:

• “Order (CE) 638/2004 del Parlamento Europeo y del Consejo, de 31 de marzo de 2004.”
• “Order (CE) nº 1982/2004 de la Comisión, de 18 de noviembre de 2004.”
• “Resolution 27 de enero de 2009, de la Presidencia de la Agencia Estatal de Administración Tributaria.”

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):

• Intra-Community Purchase invoices (AP Invoices) corresponding to Intra-Community purchase from any of the European Union countries with destination Spain, excluding Canary Islands.
• Intra-Community Sales Credit Invoices (negative AR invoices)

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):

• Intra-Community Sales (AR Invoices) corresponding to Intra-Community Sales from Spain, excluding Canary Island, to any of the European Union countries.
• Intra-Community Purchase Credit Invoices (negative AP invoices)

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:

• Origin country field in case of shipments
• Port/Airport in case of ground transportation

Annex 1 – Spanish Regions

“Código” = Spanish region id

“Provincia” = Region description

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.

Annex 3 – Port/Airport

“Código” = Spanish region id

“Provincia” = Region description

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 7^th Mike issues a sales invoice to an EU customer A. Sales invoice amount is 10,000.00€

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

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

On January 30^th 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 12^th Mike will launch the Intrastat (Sales) statistical declaration to check if EU sales transactions listed above are properly collected for the period from Jan 1^st to Jan 31^st 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 8^th Alice enters in the system a purchase invoice from EU vendor Z. Purchase amount is 2,500.00€

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

On January 20^th 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 12^th

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 10^th Mike issues a sales invoice to an EU customer A. Sales invoice amount is 110,000.00€

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

On March 18^th 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 12^th 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 1^st to March Jan 31^st 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:

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:

• Statistical Regimen – in case of an AP invoice it should commonly be “11” and in case of AR invoice it should commonly be “11”. End-user should change to “21” at transaction level in case of negative AR/AP invoice (return of goods).
• Nature of Transaction – in case of an AP invoice it should commonly be “1” and in case of an AR invoice it should commonly be “1”.
  

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:

• Client – system must show the “Client” for which a specific Intrastat declarations is being setup. This field must not be editable.
• Organization – system must show the “Organization”for which a specific Intrastat declaration is being setup. This field must not be editable.
• Reporting calendar – the end-user must be able to select a calendar; only those ones marked as “Valid for Intrastat” must be displayed here. (by example: 2009 calendar)
• Year – the end-user must be able to select a year for which Intrastat declaration is being setup at organization level.(by example: 2009)
• Intrastat declaration – system must show a reference list with below values. End-user must create an Intrastat setup for each Intrastat Declaration type in case both flow types must be reported to tax authorities.
• Acquisitions
• Deliveries
• Limit amount – end-user must enter here Intrastat Amount limit for each Intrastat type (current limit for 2009 and 2010 is = 250.000,00). This limit amount could be changed from year to year so end-user should manually change this data if applicable.
• YTD reported amount – First time the end-user must enter this data manually (by example YTD reported amount for 2009 Intrastat in case he/she starts using Intrastat feature for 2010 as 2010 Intrastat declaration submission would be required depending on 2009 amounts). Going forward system will calculate YTD reported amount based on Intrastat declarations being processed in the system.
• And under a “Default Data” section, end-user can enter below data to be taken by default while creating Intrastat transactions in case it is not setup at BP or Product level.
  • Incoterms
  • Transportation type
  • Nature of transaction
  • Port/Airport
  • Statistical Regimen

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:

• Purchase/Acquisitions Intrastat Declaration will must have into account AP invoice and negative AR Invoices (Sales returns)
• Sales/shipments Intrastat Declaration must have into account AR invoice and negative AP Invoices (Purchase returns)

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:

• Organization – End-user must select here the organizations for which Intrastat declaration must be launched.
• Year – End-user must select here the year for which Intrastat declaration must be launched.
• Period - End-user must select here the period for which Intrastat declaration must be launched.
• Intrastat declaration: reference list = “Acquisitions”, “shipments”. End-user should pick just one of them.
• Intrastat declaration type: reference list = “Normal”, “Complementary”, “Void”. End-user should pick just one of them.
  

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.

• Client – as entered above. Not editable.
• Organization - as entered above. Not editable
• Year – as entered above. Not editable.
• Period - as entered above. Not editable.
• Intrastat declaration -as entered above. Not editable.
• Intrastat declaration type - as entered above. Not editable.
• Intrastat declaration name – system will fill-in here a name based on: “Intrastat” + Intrastat Intrastat Declaration + Intrastat Declaration type + Year + Period by example: Intrastat Acquisitions Normal 2010 January.
• Status: it could either be:
  • Draft – before processing
  • Processed – after processing
  • Voided – after voiding the corresponding Intrastat declaration by creating a Voided type for a specific period.
• Total amount – this field will be empty until Intrastat declaration is being processed, then system will populate total amount as a sum up of the Intrastat lines amount, field Invoice amount value.

This section must also contain two process buttons:

• to ”Process” Intrastat transactions which can be reviewed by the end-user under “Lines” tab.
• and to “Generate” Intrastat declaration as a valid txt file.
  Once the file is generated the corresponding Intrastat declaration for a given type/period will be marked as “Processed” and it could not be generated once again unless is previously voided.
  In case there is Intrastat data missing, by example Incoterms information or port/airport in case of “Sea/Plane transport”, the system should prompt the end-user with an error message to fill in the information missing. Those transactions manually modified will be marked as “Manual change”. (Audit trail).
  Only in case all mandatory information is filled-in Intrastat declaration could be generated as a valid txt file.

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:

• Client – not editable
• Organization – not editable
• Intrastat name/id – not editable
• Included (yes/no) – It will be automatically filled-in by the system once a transaction is generated unless end-user manually remove that flag to no before processing.
• Manual change (yes/no) – It will be marked as yes in case of a change in an existing transaction or in case the end-user creates a new transaction to be included in the Intrastat txt file.

Invoice info section – not editable

• Invoice number
• Invoice line
• Invoice date
• Invoice line amount – this is the only one editable in case of an end-user manually insert a new transaction.

Transaction info section:

• Nature of Transaction Code
• Statistical Regimen

BP info section:

• Business Partner
• Incoterms (Delivery Terms)
• Transportation type
• Consignment/Destination Country (BP Country)
• Consignment/Destination Spanish Region
• Consignment country (in case it is different than BP country and just for Acquisitions Intrastat)
  

Product info section:

• NC8 item code (Intrastat item code)
• Supplementary UOM – not mandatory in case of none Supplementary units.
• Supplementary Units – not mandatory in case of none Supplementary units.
• Net Mass (kg)

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:

• Client = “Small Bazaar Holding”
• Organization = “Small Bazaar Pamplona”
• Year = “2009”
• Reporting Calendar = “2009”
• Intrastat Declaration = Acquisitions
• Limit amount = 250.000,00
• YTD reported amount = 350.000,00 €
• Default data section can also be filled in as appropriate.
  And then press “Copy to next year”

A new record will be automatically created by the system:

• Client = “Small Bazaar Holding”
• Organization = “Small Bazaar Pamplona”
• Year = “2010”
• Reporting Calendar = “2010”
• Intrastat Declaration = Acquisitions
• Limit amount = 250.000,00
• YTD reported amount = 0,00 €
• Default data section can also be filled in as appropriate.
  

New record:

• Client = “Small Bazaar Holding”
• Organization = “Small Bazaar Pamplona”
• Year = “2009”
• Reporting Calendar = “2009”
• Intrastat Declaration = shipments
• Limit amount = 250.000,00
• YTD reported amount = 570.000,00 €
• Default data section can also be filled in as appropriate.
  And then press “Copy to next year”

A new record will be automatically created by the system:

• Client = “Small Bazaar Holding”
• Organization = “Small Bazaar Pamplona”
• Year = “2010”
• Reporting Calendar = “2010”
• Intrastat Declaration = shipments
• Limit amount = 250.000,00
• YTD reported amount = 0,00 €
• Default data section can also be filled in as appropriate.

Products setup:

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

• ICN code
• Intrastat Supplementary UOM (in case applicable depending on ICN code used)
• Supplementary UOM if any
• Conversion rate from item UOM to supplementary UOM if any, otherwise “1”
• Conversion rate from supplementary UOM to Net Mass (kn) if any, otherwise “1”.
  

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.

• Transportation type
• Port/Airport if applicable
• Consignment country
  

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 7^th 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 15^th 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 17^th 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 25^th 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 27^th 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 30^th 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 31^st 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 31^st 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 12^th 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 1^st to Jan 31^{st )} 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:

• Organization: “Small Bazaar Pamplona”
• Year: “2010”
• Period : “Jan 2010”
• Intrastat Declaration: “shipments”
• Intrastat Declaration type: “Normal”
  And then press OK button.
  

System will create the corresponding Intrastat header with below information:

• Client: “Small Bazaar”
• Organization: “Small Bazaar Pamplona”
• Name: “Intrastat shipments Normal 2010 January 2010
• Year: “2010”
• Period : “Jan 2010”
• Intrastat Declaration: “shipments”
• Intrastat Declaration type: “Normal”
• Status: “Draft”
• Total Amount = empty

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 12^th 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 1^st to Jan 31^{st )} 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:

• Organization: “Small Bazaar Pamplona”
• Year: “2010”
• Period : “Jan 2010”
• Intrastat Declaration: “Acquisitions”
• Intrastat Declaration type: “Normal”
  And then press OK button.
  

System will create the corresponding Intrastat header with below information:

• Client: “Small Bazaar”
• Organization: “Small Bazaar Pamplona”
• Name: “Intrastat Acquisitions Normal 2010 January 2010
• Year: “2010”
• Period : “Jan 2010”
• Intrastat Declaration: “Acquisitions”
• Intrastat Declaration type: “Normal”
• Status: “Draft”
• Total Amount = empty

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:

• Client = “Small Bazaar Holding”
• Organization = “Small Bazaar Pamplona”
• Year = “2009”
• Reporting Calendar = “2009”
• Intrastat Declaration = Acquisitions
• Limit amount = 250.000,00
• YTD reported amount = 25.000,00 €
• Default data section can also be filled in as appropriate.
  And then press “Copy to next year”

A new record will be automatically created by the system:

• Client = “Small Bazaar Holding”
• Organization = “Small Bazaar Pamplona”
• Year = “2010”
• Reporting Calendar = “2010”
• Intrastat Declaration = Acquisitions
• Limit amount = 250.000,00
• YTD reported amount = 0,00 €
• Default data section can also be filled in as appropriate.

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 8^th 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 10^th 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 20^th 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 31^st 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 7^th 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 25^th 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 31^st 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 31^st 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 12^th 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 1^st to Jan 31^{st )} 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 12^th 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 1^st to January 31^{st )} 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:

• Organization: “Small Bazaar Pamplona”
• Year: “2010”
• Period : “Jan 2010”
• Intrastat Declaration: “shipments”
• Intrastat Declaration type: “Normal”
  And then press OK button.
  

System will create the corresponding Intrastat header with below information:

• Client: “Small Bazaar”
• Organization: “Small Bazaar Pamplona”
• Name: “Intrastat shipments Normal 2010 January 2010
• Year: “2010”
• Period : “Jan 2010”
• Intrastat Declaration: “shipments”
• Intrastat Declaration type: “Normal”
• Status: “Draft”
• Total Amount = empty

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 7^th 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 25^th 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 27^th 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 31^st 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 12^th 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:

• Organization: “Small Bazaar Pamplona”
• Year: “2010”
• Period : “Jan 2010”
• Intrastat Declaration: “shipments”
• Intrastat Declaration type: “Void”
  And then press OK button.
  

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 12^th 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 20^th 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:

• Organization: “Small Bazaar Pamplona”
• Year: “2010”
• Period: “January”
• Intrastat Declaration : “shipments”
• Intrastat Declaration type: “Complementary”

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

System will create the corresponding Intrastat header with below information:

• Client: “Small Bazaar”
• Organization: “Small Bazaar Pamplona”
• Name: “Intrastat shipments Complementary 2010 January 2010
• Year: “2010”
• Period : “Jan 2010”
• Intrastat Declaration: “shipments”
• Intrastat Declaration type: “Complementary”
• Status: “Draft”
• Total Amount = empty

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

Category: Projects ERP