Intrastat Dispatch (SD-FT-GOV)

Purpose 

The purpose of this page is to clarify the understanding of the system logic and requirements in relation to Intrastat declaration on dispatch side.

Data Selection

Which documents are selected?

The Intrastat selection programs for SD documents read and process only billing documents (billing types are defined in table TVFK = transaction VOFA).

In order to be selected these documents must have billing- and foreign trade data at header and item level. The following database tables are evaluated:

There are two selection programs, a main program and a program for special business transactions:

Minimum requirements for the selection of a document

If a document is not selected, the following points should be checked:

• Does the document have foreign trade data? In this case a “Number of foreign trade data” is assigned to the document. Here is how you find it:

  Transaction VF03 -> Goto -> Header -> Foreign Trade / Customs -> subscreen: Organization -> field “Number of foreign trade data” must be filled

  Or technically: transaction SE16 -> table VBRK -> field EXNUM <> initial

• Is the billing date (field VBRK-FKDAT) within the selection period?

• Attention: it can be set in Customizing that instead of the billing date the “Date on which services rendered” (field VBRP-FBUDA) is considered for the selection: Periodic Declarations -> Data Selection Control

• Departure country (field EIKP-ALAND) = reporting country (from the selection screen)?

• Ship-to party is outside the EU?

• Is the billing document posted to accounting (VBRK-RFBSK <> CDJ)? If not, then the document will be logged under “Open business transactions”.No selection if the country of the VAT-Registration Number (VBRK-STCEG_L)  = country of the Sold-to Party = Reporting country

• Is the exclusion indicator set?

• Is a user-exit active? see Note 303984

• Is the item category is excluded from the selection? In the Customizing transaction VE80 it is possible define exclusion for the item categories.

The selection screen

General information about the selection screen of periodic declarations is available here .

Minimum required entries on the selection screen

Basically each separate company code ( = independent accounting unit) must submit an Intrastat report on a monthly basis, for each country in which this company code has plants from which goods are delivered into EU-countries (SD side) or into which goods are received from an EU-country (MM side).

The following data must be specified on the selection screen:

•  Company code = the company which is createing the Intrastat report
•  Reporting period = reporting year and month
•  Reporting country = country for which the report is submitted
•  Reporting currency = currency in which values (e.g. invoice value) must be reported to the authorities
•  Log type = update run  / test run

 Notes:

• If a company code has plants abroad (relevant for Intrastat), then a separate selection must be started for each of these countries.

Example: “XX Company Germany” has in addition to its local plants also plants in France and Austria. For the company code of “XX Company Germany” a total of three selections must be started: one for each country.

•  For test runs, or in order to reduce the runtime, you can define in the selection screen further selection criteria, e.g. document numbers, plants, destination country (=country of the ship-to party), creation date and billing date. In case of an update run however it must be ensured that no relevant document is left out.

Input options

Section “Selection criteria”

Billing document = document number of the billing document (VBRK-VBELN)

Date of creation = date of the document creation (VBRK-ERDAT)

only VE01:

Company code = company code which has created the document (VBRK-BUKRS)

Plant = delivering plant (VBRP-WERKS)

Country of destination = country of the ship-to party

Section “Billing document types”

The selection can be restricted to certain billing types. The flags correspond to the field “sales document category” from the table of the billing types (field TVFK-VBTYP).

Section “Dispatching organizational units” (only VI98)

Company code = Company code which has created the document (VBRK-BUKRS)

Plant = delivering plant (VBRP-WERKS)

Section “Ordering organizational units”(only VI98)

Company code = company code which has issued the sales order to the customer, not the delivering company code. This company code is the invoice recipient.

• • This company code is company code determined internally from the sales organization: VBRP-VKORG -> TVKO-BUKRS
  • In case of stock transfers it is determined from the VAT registration number VBRK-STCEG.
    
    

Section “INTRASTAT – General”

Reporting month = month for which the Intrastat report is created

Reporting year = year for which the Intrastat report is created

Whether a document is relevant for the predefined reporting month depends on the billing date (VBRK-FKDAT = default) or on the posting date of the item (VBRP-FBUDA) -  see the relevant customizing setting here (>>> hyperlink to the relevant section of the “Allgemein” docu) 

Country of declaration = country for which the report is created

VE01 = country from where the goods are dispatched

VI98 = country into which the goods are delivered

Declaration currency = currency in which the values are to be reported to the authorities. This currency is predefined. As documents can also be created in different currencies a conversion into the declaration currency is often necessary.

Section  “Issue / Update”

Log type = this field controls not only the extent of the log but also – and primarily – whether an update run (values A/B/C = with database update) or a test run (values D/E/F = without database update) should be started.

Recommendation: for update run select “B”, for test run select “E”, in order to get as much information via the logs as possible.

Layout = determines the layout of the selection log; usually this is not filled

Deletion type = relevant only in case of an update run. As in case of an update run under certain circumstances old data (from a previous selection run) must be deleted from the table VEIAV, the scope of the deletion can be controlled by this field.

Section “Additional Specifications”

INTRASTAT exchange rate type = Relevant for currency conversions. In standard the conversion table TCURR is read with exchange rate type “M” (unless controlled by TCURF). It can be controlled by this field if the conversion table is to be read with exchange rate type “I” (stands for “Intrastat”). This can be used e.g. if a fixed conversion rate between two currencies is specified by the authorities.

Issue warnings incompletion = determines if the log should contain also warning messages.

Issue additional info incompletion = determines if the log should contain also information messages.

only VE01:

Copy region from plant => determines if the region of origin should be determined differently from the standard method (= setting the foreign trade item data). If this indicator is checked, the region (VEIAV-URSPRSREG) is determined from the delivering plant (field T001W-REGIO).

Section “Declaration of Services” (only VE01)

            Item category = determines which item categories are to be regarded as services.

How are the billing types processed?

General notes

In addition to the “normal” invoice (the best-known billing type is the F2) there are additional billing types which are handled by the Intrastat programs. The processing of these special types happens mostly in the FORM get_reference_data. The following SD sales document categories are processed by the Intrastat programs:

During the processing of the credit memos it is decisive whether the credit memo is a credit memo with a goods movement (= return: customer sends the goods back completely or partially) or a credit memo without a goods movement (e.g. the goods arrive damaged and are immediately discarded or a part of the goods is lost underway). For returns the billing type “RE” (“Credit for Returns”) is available in standard. For credit memos without goods movement the credit memo type “G2” (“Credit Memo”) is used in standard. As not only standard billing types may be used, the program checks the type of the preceding document:

 VBRP-VGTYP = J / T / 7 / g => with goods movement (return)

Normal invoice

A customer in a non-EU country orders goods at a sales organization which belongs to company code CC01 and receives the goods from a plant which is assigned to the company code CC01.

Who has to report what?

Delivery:

• Dispatch of the goods from Country A

Who reports? => CC01

How? => transaction VE01 => selects F2

• Receipt of the goods in Country B

 The customer’s responsibility!

Field contents of the VEIAV-record created for the F2 item:

Returns

The customer sends the goods back, e.g. because the wrong material has been delivered or the goods are damaged. For the returned goods a return credit memo (“RE”) is issued to the customer.

Who has to report what?

Delivery (Dispatch and Receipt) => see above

Return:

• Dispatch (return) of the goods from Country B

 The customer’s responsibility!

• Receipt of the returned goods in Country A

Who reports? => CC01

How? => transaction VE01 => selects RE

Field contents of the VEIAV-record created for the RE item:

 Notes:

• Contrary to the processing of credit memos, debit memos and cancelations, in case of returns it makes no difference if the original invoice (F2) has been reported to Intrastat in the same period or in a previous one. The delivery and the return are considered as two separate processes (due to the two different goods movement directions) and are consequently reported separately. For this reason no assignment to a reference document is necessary here.

• Although return credit memos are selected with transaction VE01, they are reported as Receipt (except for Italy).

• Special case - Italy: return credit memos are handled as normal credit memos, i.e. these are reported not as Receipt but as Dispatch. Technically this is controlled in the function module RV_FTT_GOV_REPORT_INFO_GET. This also means that a return credit memo is settled with the original invoice (F2) if both documents are reported in the same period; whereas in case they are reported in different periods the return credit memo is reported as a correction. In case of corrections the system needs an original invoice. (You can check this in the Document History) If there is no original invoice, the document won't be selected. 

• A return credit memo is a credit memo with reference to a goods movement. Whether a goods movement has taken place can be recognized from the type of the preceding document: field VBRP-VGTYP = J / T / 7/  g / H.

• Special case - Germany : the invoice value of the return credit memos is reported as zero. Note: in case of a test run the invoice value is filled, but in case of an update run it is zero.

• Log: the logs of an update run and a test run are different. In test run the line for the return credit memo is highlighted in red and shows negative values (as also in the case of credit and debit memos). In an update run it is displayed as a normal item (with negative value). The reason for this difference is that it is checked only in update run whether there is an underlying goods movement for the return credit memo. If this is the case the return credit memo is reported as a normal record (though on the Receipt side – except for Italy as already mentioned).

      

Credit memos / debit memos

The goods arrive at the customer broken or damaged and are not returned. The customer receives a credit memo (G2) which reduces the value of the invoice (F2).

In the opposite case it can happen that the customer was undercharged. In this case a debit memo (L2) is issued to the customer which increases the invoice value.

Who has to report what?

Delivery (Dispatch and Receipt) => see above (see: “Normal invoice”)

Value correction by credit / debit memo:

It must be differentiated whether the reference document (F2) is reported in the same period or has been reported already:

• Reference document F2 in the same reporting month as the G2 / L2:

Step 1: selects F2 and G2 / L2 (G2 is highlighted in red in the log)

Step 2: value of the G2 is subtracted from the F2 / value of the L2 is added to the F2

• Reference document F2 already reported in a previous period:

Step 1: selects G2 / L2 (G2 is highlighted in red in the log)

Step 2: G2 / L2 is logged under the menu point “Processes not relevant for declaration”

 Message EIP054 “Document item corrects transaction in previous periods (reporting month /year of F2)”

Explanation: F2 has been reported in a previous period. From the credit/debit memo for this F2 it is clear that the value reported to Intrastat in the previous month is too high (G2) / too low (L2). A correction report must be created for the authorities - in case the amount to be corrected is relevant (there is no functionality available in ERP for the correction report).

Credit and Debit memos always need a reference invoice, because otherwise they won't be reported by the system. 

Exception: Italy (see comments below).

Field contents of the VEIAV-record created for the G2 item:

Field contents of the VEIAV-record created for the L2 item:

 Notes:

• Reference documents which have been reported in a previous period must exist in the table VEIAV, otherwise the credit / debit memos cannot be assigned. Such documents are written to VEIAV but are not selected during the file/form creation and also not logged.
• To determine the data in the selection run, the system needs a reference invoice to the credit / debit memo (visible in the document flow). The system is searching internally for a VBTYP = M (invoice). If it can not find an invoice than tries to determine the following document types: 'U', 'P', 'O' , '5' or '6'. The credit/debit memo is a correction to a previous document. So it is not enough to have only a credit memo request in the document flow of the credit memo. 
• Settlement of the documents in Step 2 happens in FORM correction_handling_veiav (report SAPLV50G)
• There can be any number of G2 / L2 documents to an F2; it does not influence the reported invoice value.
• Weights are changed to zero during update run! (In test run they are displayed with their real value in the log). Reason: credit and debit memos are settled with the original invoice only on a value basis. The weights in the original invoice must be kept.
• If no reference to an original invoice can be determined (e.g. in case a debit memo is created with reference to a debit memo request) then this is documented in the selection run (Step 1 - in the incompletion log) as well as in the file creation run (Step 2 – under “Processes not relevant for declaration.") The reference to an invoice is determined from the document flow (in report RVEXIEKS, FORM get_reference_doc).
• Special case - Italy : a credit / debit memo whose reference document (F2) has been reported in a previous period is not simply logged (as for other countries), but is contained in the report file as a separate record, marked as “Sezione 2” (correction to a previous period). 
• Log: the entries for credit memos are highlighted with red, the values are negative. Debit memos are displayed as normal invoices. The net weight of credit/debit memos are only displayed in a test run (correctly, as the information is irrelevant in an update run).

The credit memo request has the document type 'K', that's why the credit memo is not determined.

Cancelations

The F2 invoice was created unjustly or incorrectly and is revoked via a cancelation document S1. If the goods has been delivered this is charged through another F2 invoice.

Who has to report what?

Delivery (Dispatch and Receipt) => see above (“Normal invoice”)

Value correction by cancelation:

It must be differentiated whether the reference document (F2) is reported in the same period or has been reported already:

• Reference document F2 in the same reporting month as the S1:

Step 1: selects F2 and S1 (S1 is highlighted in red in the log)

Step 2: nothing is reported. F2 and S1 are logged under the menu point “Processes not relevant for declaration"

           F2: message EIP050 “The document item was completely cancelled”

           S1: message EIP051 “The cancelled item was not copied into the declaration”

• Reference document F2 already reported in a previous period:

Step 1: selects S1 (highlighted in red in the log)

Step 2: S1 logged under the menu point “Processes not relevant for declaration"

          Message EIP053 “The cancellation item was not included in the declaration (reporting month /year of F2)”

Explanation: F2 has been reported in a previous period. From the cancelation of this F2 it is clear that the value reported to Intrastat in the previous month is too high. A correction report must be created for the authorities - in case the amount to be corrected is relevant (there is no functionality available in ERP for the correction report).

Exception: Italy (see comments below).

Field contents of the VEIAV-record created for the S1 item:

 Notes:

• Reference documents which have been reported in a previous period must exist in the table VEIAV, otherwise the cancelations cannot be assigned. Such documents are written to VEIAV but are not selected during the file/form creation and also not logged.
• Settlement of the documents in Step 2 happens in FORM correction_handling_veiav (report SAPLV50G)
• Log: the lines for cancelations are highlighted in red, the values are negative.

Special processing for Italy

Credit / debit memos and cancelations of invoices which have already been reported in a previous month are not - as in other EU countries – reported to the authorities as an informal correction, but instead such records are a real part of the Italian monthly report, marked as “Sezione 2” records (which means that these records are corrections to a previous period – as opposed to “Sezione 1” = normal records). See Note 528941 .

Another Italian special feature is related to return credit memos: these are not - as in other EU countries – reported as normal Receipt, but instead as a correction “Sezione 2” on the Dispatch side.

Yet another Italian special feature is related to cross-company scenarios involving 3 countries, see here (see below) and another one to third-party business transactions (see below).

Special processing for France

Solution in consulting Note 1295791:

Credit / debit memos and cancelations of invoices which have already been reported in a previous month are not - as in other EU countries – reported to the authorities as an informal correction, but instead such records are a real part of the French monthly report, marked as “code régime” = ‘26’ records (debit memo) or  ‘25’ (credit memo / cancelation). The field “Code régime” is set based on the first two digits of the export procedure.

Solution in consulting Note 1171707:

Although return credit memos are – as in other EU countries – reported as normal Receipt, but these also have to be reported on the Dispatch side. This way a return credit memo will result in two VEIAV-records.

Another French special feature exists for Plants Abroad scenarios with 3 countries involved, see here (see below).

Special processing for Great Britain

Solution in consulting Note 1171707:

Although return credit memos are – as in other EU countries – reported as normal Receipt, but these also have to be reported on the Dispatch side. This way a return credit memo will result in two VEIAV-records.

Special business scenarios

Cross-company sales

What is a cross-company sales scenario?

Example

 A sales organization which is assigned to company code CC01 (e.g. XYZ Germany) sells goods to a customer. The goods however are delivered from a plant which belongs to company code CC02 (e.g. subsidiary XYZ Austria). The sales order (OR) and the invoice to customer (F2) are issued by CC01, the delivery (LF) is issued by CC02. Of course CC02 wants money for the delivered goods, so CC02 issues an intercompany invoice (IV) to CC01.

Normally both the F2 and the IV are created with reference to the LF.

How to recognize an intercompany scenario?

Unfortunately there is no indicator either in the sales order or in the invoice which would indicate at first sight that the document belongs to a cross-company scenario. There are however clues, e.g. if in the document flow there is an F2 and also an IV.

In a cross-company case the company code of the sales organization is not identical with the company code of the delivering plant.

How do I find the company code of the sales organization?

VF03 -> Goto -> Header -> Header -> section “Accounting Data” -> field “Company Code” (VBRK-BUKRS)

How do I find the company code of the delivering plant?

VF03 -> Goto -> Item -> Item Detail -> section “Billing Data” -> field “Plant” (VBRP-WERKS)

To which company code is the plant assigned?

Customizing -> Enterprise Structure -> Assignment -> Logistics – General -> Assign plant to company code

or technically:

SE16 -> T001W with WERKS = VBRP-WERKS

                                   >> determine valuation area: T001W-BWKEY

SE16 -> T001K with BWKEY = T001W-BWKEY

                                   >> determine company code: T001K-BUKRS

Who reports?

Basic principle:

            The sender of the goods has to report the dispatch.

            The recipient of the goods has to report the receipt of the goods.

Exception:

This rule is not valid if the delivering company code or the customer (i.e. the goods recipient) is based in the same country as the selling company code. In this case the selling company code is responsible for reporting the goods movement. To put it differently, Intrastat reporting in the own country it is always the responsibility of the selling company code (i.e. the one that issued the sales order). 

Intercomany billing

The intercompany invoice is issued by the delivering company code.

Sold-to party is the selling company code (internal customer).

Goods recipient is the actual goods recipient, who is also in the F2 invoice. But: due to tax determination reasons the goods recipient country (field VBRK-LAND1) is set from the country of the sold-to party (see Note 1032869). This has a negative impact if the country of the sold-to party is not an EU-country. Consequence: the document is not selection for Intrastat! Solution: set the inclusion indicator.

Technically: for the IV the ship-to party’s view (table KUWEV) is filled differently than for the normal invoice; it contains the data of the sold-to party (F2: data of the goods recipient)  ->  FORM kundenviews_fuellen (SAPLV60A). Structure KUAGV also contains the data of the sold-to party (like the F2).

The data are set for the intercompany invoice in FORM vbrk_vbrp_datentransport (SAPLV60A), e.g.:

VBRK-LAND1 = KUWEV-LAND1     = country of the sold-to party

VBRK-REGIO = KUWEV-REGIO     = region of the sold-to party

VBRP-ALAND = T001-LAND1         = country of the delivering company code

The departure country contains the country of the delivering company code (F2: country of the delivering plant). This leads to problems if the country of the delivering plant is not the same as the country of the delivering company code -> see Note 2056243.

On the topic “Cancelation of an intercompany credit memo” see Notes 529980 / 587077.

Scenarios

Selling company code and customer in the same country (normal case)

Who has to report what?

Delivery:

• Dispatch of the goods from Country B

Who reports? => CC02

How? -> transaction VE01 => selects IV

• Receipt of the goods in Country A

Who reports? -> CC01

How? -> transaction VI98 => selects IV (dispatching org.unit = CC02 / selling org.unit = CC01)

Return:

• Dispatch of the returned goods from Country A

Who reports? => CC01

How? -> transaction VI98 => selects IG /intercompany credit memo/ (dispatching org.unit = CC02 / selling org.unit = CC01)

 VI98 cannot report dispatches, it can only select the relevant documents, so the documents have to be selected in a test run and then an according VEIAV-record created manually using transaction VEFU.

• Receipt of the goods return in Country B

Who reports? -> CC02

How? -> transaction VE01 => selects IG

 It works only if the IG was created with reference to goods movement (delivery; copy control: VTFL). ). In standard it is also possible to create an intercompany credit memo with reference to intercompany invoice (copy control: transaction VTFF). Whether a good movement has taken place is determined based on field VBRP-VGTYP (Document category of preceding SD document). A goods movement is supposed in case this field has either of the following values: J (Delivery) / T (Return delivery) / 7 (Inbound delivery) / g (Rough Goods Receipt (only IS-Retail))  / H (Return). 

 the invoice documents F2 and RE both contain foreign trade data (as delivering plant country is not equal the goods recipient’s country). However these documents are deselected in VE01 (as reporting country = country of the goods recipient, see Note 203734), otherwise it would be reported twice.

Selling and delivering company code in the same country

 Who has to report what?

Delivery:

• Dispatch of the goods from Country A

Who reports? => CC01

How? -> manually, using transaction VEFU (transaction VE01 cannot select the F2 as the delivering plant is not assigned to the company code CC01)

Alternatively: VE01 -> small trick necessary: create selection variant for CC01 with all plants assigned to CC01 then including also the delivering plant

• Receipt of the goods in Country B

 Customer’s responsibility!

Return:

• Dispatch of the returned goods from Country B

 Customer’s responsibility!

• Receipt of the returned goods in Country A

Who reports? -> CC01

How? -> manually, using transaction VEFU (transaction VE01 cannot select the F2 as the delivering plant is not assigned to the company code CC01).

Alternatively: VE01 -> small trick necessary: create selection variant for CC01 with all plants assigned to CC01 then including also the delivering plant.

 Note: Selection of the IV in VE01 with company code CC02 is prevented by Note 397313, to avoid double reporting.

Delivering company code and customer in the same country

Who has to report what?

Nothing – it is not an export case! The goods do not cross any border here.

Special case: 3 different countries

Who has to report what?

Delivery:

• Dispatch of the goods from Country C

Who reports? -> CC02

How? -> transaction VE01 -> selects IV

Here the consulting Note 459296 is necessary to ensure that for CC01 in VE01 the F2 invoice (plant country is Country C) not selected (otherwise double reporting). In addition, some fields determined from the IV must be refilled.

• Receipt of the goods in Country B

Customer’s responsibility!

Third-party sales

What is a third-party sales scenario?

Example:

A sales organization which is assigned to company code CC01 (e.g. XYZ Germany) sells goods to a customer. The goods however are delivered not by the company XYZ itself, but instead an external vendor is contracted to deliver directly to the customer. At the sales order creation, in the background a purchase requirement and then from this a purchase order (PO) is generated. The external vendor issues a vendor invoice (“Incoming Invoice”) to company XYZ.

As company XYZ itself is not delivering the goods, no delivery is created there. The billing is done with reference to the sales order to the customer (billing type F5).

In case of order-related billing in the copy control (transaction VTFA) the indicator for determining the export data (field EXPIM) should be set to “B” (=“Redetermine the export data”).

How to recognize a third-party sales scenario?

In standard the item category TAS is used for third-party items. The billing-relevance of the order item is = F (“Order-related billing doc. - status according to invoice quantity”).

Scenarios

Selling company code and customer in the same country (normal case)

Who has to report what?

Delivery:

• Dispatch of the goods from Country B

 Vendor’s responsibility!

• Receipt of the goods in Country A

Who reports? -> CC01

How? -> transaction MEIS -> selects PO

Selling company code and vendor in the same country

Who has to report what?

Delivery:

• Dispatch of the goods from Country A

Who reports? -> CC01

How? -> VE01 -> selects F5

• Receipt of the goods in Country B

 Customer’s responsibility!

Vendor and customer in the same country

Nothing – it is not an export case! The goods do not cross any border here.

 Note: As in case of third-party sales scenario in the sales order a (dummy) delivering plant is entered (mostly in the same country as the company code) and because the goods recipient is abroad, in the F5 billing document foreign trade data are populated. In order to prevent the selection of the F5 invoice in VE01 for the company code CC01 in country A, an exclusion indicator must be set in the foreign trade header data of the F5 (field EIKP-SEGAL).

Special case: 3 different countries

Who has to report what?

Delivery:

• Dispatch of the goods from Country C

 Vendor’s responsibility!

• Receipt of the goods in Country B

 Customer’s responsibility!

 Note: as in case of third-party sales scenario in the sales order a (dummy) delivering plant is entered (mostly in the same country as the company code) and because the goods recipient is abroad, in the F5 billing document foreign trade data are populated. In order to prevent the selection of the F5 invoice in VE01 for the company code CC01 in country A, an exclusion indicator must be set in the foreign trade header data of the F5 (field EIKP-SEGAL).

The purchase order is automatically excluded as the program compares the delivery address with the reporting country.

Plants Abroad

What is a plants abroad scenario?

 Example:

A sales organization which is assigned to company code CC01 (e.g. XYZ Germany) sells goods to a customer. The goods however are delivered not from the country of the company code but from a plant in another country (e.g. Austria). To put it differently, the country of the delivering plant is not equal to the country of the company code to which the plant is assigned.

How to recognize a plants abroad scenario?

Generally it is sufficient to compare the departure country of the F2 invoice (i.e. the country of the delivering plant: field VBRP-ALAND) with the country of the company code (field T001-LAND1). However it could also be a cross-company scenario, namely a case where the plant is not assigned to this company code but to a different one. To be able to tell for sure, a check must be performed on the cross-company case, see here (hyperlink to this doku’s cross-company section).

Note: in case of intercompany invoices / credit / debit memos it is always an intercompany scenario, i.e. the delivering plant is not assigned to the selling company code. But there is  a special case in cross-company, where the country of the delivering plant is not the same as the country of the delivering company code, i.e. both scenarios are combined. The solution for this special case is provided in Note 2056243.

If to a company code foreign plants are assigned then the message EI475 is issued in VE01: “Your selection is based on organizational units that are not in the declaration country”, i.e. to the company code specified in the selection screen plants are assigned which are not in the reporting country.

Scenarios

Selling company code and customer in the same country

Who has to report what?

Delivery:

• Dispatch of the goods from Country B

Who reports? -> CC01

How? -> VE01 -> selects F2

• Receipt of the goods in Country A

Who reports? -> CC01

How? -> manually, using transaction VEFU

Delivering plant and customer in the same country

Who has to report what?

Nothing – it is not an export case! The goods do not cross any border here.

Special case: 3 different countries

Who has to report what?

Delivery:

• Dispatch of the goods from Country C

Who reports? -> CC01

How? -> VE01 -> selects F2

• Receipt of the goods in Country B

 Customer’s responsibility!

Special case - France  (-> corresponds to Country A): the goods dispatch must be reported from country A. Solution is provided in Note 560737.

Consignment

Who has to report what?

Delivery:

• Dispatch of the goods from Country B

Who reports? -> CC01

How? -> VE01 -> selects WIA

• Receipt of the goods in Country A

 Customer’s responsibility!

Exception: if company code CC01 is liable to tax on sales/purcheses in country A (i.e. it has a VAT registration number there). In this case CC01 is responsible for reporting the receipt of the goods -> manually, using transaction VEFU (the receiving plant must be specified as plant, i.e. the plant that is in the reporting country).

Problem: it is the dispatch of the goods that has to be reported, i.e. the “Consignment Fill-up”, but this is not relevant for billing (as here the own stock is being transferred within own plants). For this reason a workaround is necessary: a WIA (Plants abroad) - invoice has to be issued.  Note: item category KEN must be excluded from the selection via customizing, otherwise the F2 invoice for the Consignment Issue would also be selected.

A “Consignment pick-up” needs to be reported with VEFU (as the document type “Return for WIA” does not exist in standard).

Further special cases

Cross-company plus third-party

IVA = order-related inter-company billing document

Who has to report what?

Delivery:

• Dispatch of the goods from Country C

 Vendor’s responsibility!

• Receipt of the goods in Country A

Who reports? -> CC01

How? -> VI98 -> selects IVA

Exception: if company code CC01 is liable to tax on sales/purchases in country A (i.e. it has a VAT registration number there). In this case CC01 is responsible for reporting the receipt of the goods -> manually, using transaction VEFU (the receiving plant must be specified as plant, i.e. the plant that is in the reporting country).

 A conversion of the SD-data (dispatch) into MM-data (receipt) via customizing is required.

 The dispatch country (VEIAV-BESTILAND) will be set incorrectly (country B instead of C)

 The PO will not be selected in transaction MEIS for country A, as the plant country (country B) is unequal the reporting country (country A).

 Billing type IVA can be created with the report RVIVAUFT (see Note 63459).

Repair

Goods which are moved across borders for repairing do not have to be reported as no change in value occurs. Additional parts which alter the value (e.g. technical extensions) must however be reported, as well as exported material which is used for the reparation.

Currency conversions

When is a conversion required?

In the Intrastat declaration there are also value fields: the statistical and/or the invoice value. The values must be shown in the declaration file in the currency of the reporting country. The amounts in the selected documents can however be in a different currency (e.g. USD). In this case a conversion into the reporting currency is necessary.

Amounts in the document can be present in the document currency (e.g. the net value) or in the home/company currency (e.g. the statistical value). With the reporting currency three currencies can come into play:

-          CC = Company Currency = currency of the selling company code (a.k.a. home currency)

-          DC = Document Currency = currency of the amounts in the billing document

-          RC = Reporting Currency = currency in which the values are to be reported to the Authorities

In case of conversion problems it is important to determine these three currencies at the beginning. Afterwards it can be figured out based on the below described formula how the system calculates.

In Italy an additional currency comes into play: in case of receipts the values must also be specified in the currency of delivering country if this is different from the Italian reporting currency (EUR).

Exchange rate type

To ensure variable conversion between two currencies the exchange rate type is defined as part of the key fields in the conversion table (TCURR –it can be maintained with transaction OB08). Normally the exchange rate type ‘M’ (middle rate) is used for conversions, this is also true for the Intrastat selection programs.

In some countries the use of a specific exchange rate - which differs from the middle rate - is required for the Intrastat reports by the Authorities. To ensure compliance with these requirements these mandatory rates must be maintained with exchange rate type ‘I’ (for Intrastat) in the conversion rate table. In this case in the Intrastat selection screen, in section “Additional Specifications” the parameter ‘INTRASTAT exch. rate type’ = ‘I’ must be set.

The exchange rate type ‘I’ is only used for the conversion from document currency into the reporting currency, not for the conversion from home currency into the document currency. 

Conversion factor

When using the exchange rate type ‘M’ the exchange rate is taken from the billing document: field VBRK-KURRF (Exchange rate for FI postings). In the billing document this field can be found on the tab Header, section Accounting Data. If this field is not filled then the rate is set from field VBRP-KURSK (Exchange Rate for Price Determination). This field can be found on tab Item Detail, section Price data. (screenshots?)

When using the exchange rate type ‘I’ the exchange rate is set as a basic principle from the customizing table TCURR.

Rule of thumb: if the above parameter is checked in the selection screen then the exchange rate type ‘I’ is used only for the conversion from the document currency into the reporting currency. For the conversion from the home currency into the document currency the exchange rate type ‘M’ is used.

Related Documents (Size: Heading 2)

Insert SAP Help links or other WIKI content link.
Please hyperlink the title of the related document

Related SAP Notes/KBAs

303984   Correct use of EXIT_SAPLV50G_001 and EXIT_SAPLV50G_002

528941 Intrastat Italy: dispatch processing of corrections

1295791  Intrastat France: value corrections for previous period

1171707 Intrastat: Reporting returns as arrival and dispatch

1032869 Tax determination in intercompany billing

2056243 Intercompany billing: Incorrect country of departure in foreign trade data

529980 INTRASTAT: Cancellation internal credit memo on receipt side

587077 Intrastat: No allocation settlement of internal credit memo

203734 Intrastat:Intercompany processing - invoice selectd

397313 INTRASTAT: Germany - No obl. to inf. at domstc sold-to-party

459296 INTRASTAT/EXTRASTAT: Triangular deals - intercompany billing

2056243 Intercompany billing: Incorrect country of departure in foreign trade data

560737 INTRASTAT: France - Triangular deal procedure 31

63459  Order and third-party-related intercompany billing