Intrastat Arrival (MM-FT-GOV)

Data selection

Which documents are selected?

The Intrastat selection programs for MM documents read and process only purchase orders (PO) and MM scheduling agreements.

The order types are defined in table T161. Customizing: Materials Management -> Purchasing -> Purchase Order -> Define Document Types.

In order to be selected these documents must have item data and foreign trade data at header and item level. For the determination of the reporting period, the delivered quantities and the values in the invoice it is necessary to read also the purchase order history (document flow).

The following database tables are evaluated:

Table	Content
EKKO	Purchase order header data
EKPO	Purchase order item data
EIKP	Foreign trade header data
EIPO	Foreign trade item data
EKBE	Purchase order history

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

Transaction	Program	Status	Selects
MEIS	RMIMST00	Main program	Deliveries from vendors ("Arrivals")
VI99	RMEXST00	Special program	Goods returns to the vendors ("Dispatches")

Difference from the SD selection programs:

The selection of the MM-data for Intrastat differs fundamentally from the selection of SD data. Why? In SD billing documents are evaluated which were created for goods delivered already to customers. These billing documents contain all the values which are required for Intrastat, including the invoice value and the statistical value.

The MM purchase orders on the other hand, which are evaluated by MM selection program, provide only a “declaration of intent”. The delivered quantities (goods receipts) and the values provided by the vendor in the invoice (invoice receipts) must be determined from the PO history. There is no direct link between the particular goods receipts and the invoice receipts, the assignment happens chronologically. For this reason the determination of the MM Intrastat data is clearly more complex and time-consuming than that of the SD Intrastat data.

Minimum requirements for the selection of a document

If a document or a document item is not selected the following points should be examined:

Does the document have foreign trade data? This is the case if the document has a “foreign trade number” assigned. It can be found here:Transaction ME23N / ME33L -> Header -> tab “Import” -> subscreen: Organization -> field “Number of foreign trade data” must be filled

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

Does the document have a purchase order history?

Transaction ME23N / ME33L -> Item data -> tab “Purchase order history”

Or technically: transaction SE16 -> table EKBE -> are there any records for the document number / document item?

Receiving country (field EIKP-ALAND) = reporting country (from the selection screen)?
Vendor / delivering vendor party is outside the EU? (EIPO-VERLD check)
Is the exclusion indicator set? Technically EIKP-SEGAL (header level) or EIPO-SEGAL (item level)
Is a user-exit active?
Text items (field EKPO-PSTYP = 6) are not selected as a basic principle
Service items (field EKPO-PSTYP = 9) are only selected if the corresponding parameter is checked on the selection screen.

The selection screen

General information about the selection screen of periodic declarations is available here http://wiki.scn.sap.com/wiki/x/UosmG

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 creating 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

: 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 Tr. MEIS ->

Purchasing document = document number of the purchasing document ->EKKO-EBELN

Purchasing organization -> EKKO-EKORG

Company code = company code which has created the document -> EKKO-BUKRS

Plant = receiving plant -> EKPO-WERKS

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 period depends on the available goods- and invoice receipts as well as the selection logic.

Country of declaration = country for which the report is created

MEIS = country into which the goods are delivered

VI98 = country from which the goods are returned

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 Details”

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.

Select Services => service items are also selected (field EKPO-PSTYP = 9). Currently only required for reporting country=Italy.

only MEIS

Selection by Document Date => during the selection of the PO history instead of the posting date (EKBE-BUDAT) the document date (EKBE-BLDAT) is taken into consideration.

Exchange Rate Date w/o Invoice => special logic for the currency conversion: if a goods receipt is reported in a subsequent period for which no invoice receipt is available yet, the 15^thday of the reporting month is set as the conversion date.

Exchange Rate Date Invoice in Previous Month => special logic for the currency conversion: if to a goods receipt an invoice from a previous month is assigned then the conversion date is taken from the date of the goods receipt.

Exchange Rate from Invoice => special logic for the currency conversion: the exchange rate is determined not from the purchase order or from customizing but from the invoice that was assigned to the goods receipt.

only VI99:

Copy Region from Plant => If this is checked the region of origin is determined in different way from the standard (i.e. being set from the foreign trade item data). If checked, the region (VEIAV-URSPRSREG) is set from the receiving plant (field T001W-REGIO).

Processing of the purchasing history

Why does the PO history have to be evaluated?

A major part of the data required for the Intrastat report can be taken directly from the purchase order or from its foreign trade data.

The most important information however is missing from the PO:

When did the goods sent from the other EU-country arrive in my plant?

Or in case of returns:

When did I send the goods back to the vendor?

This question can only be answered by analyzing the goods receipts (GRs) in the purchase order history. This point in time determines in which period the goods movement has to be reported to Intrastat. For this the selection logic used plays an important role.

In addition to the goods movements the invoice movements in the PO history are also evaluated: invoice receipts (IRs), cancelations, credit and debit memos.

This is required as the prices found in the PO are not necessarily identical with the values entered eventually in the invoice: price variances, cancelations, credit or debit memos are also to be considered.

This means that also the invoice and statistical values required for the report are taken or derived (if possible) from the invoice receipts in the PO history. As in the invoice receipt records only the invoice values are available but not the statistical values, these must be calculated. If no invoice receipt is available for the goods movement then the required values are derived from the values in the goods receipts or from the PO.

As there is no direct link between goods movements and invoice movements (the documents are always created with just reference to the PO) this relationship must be “simulated” by the selection programs, i.e. the program checks: “which IR might belong to which GR?” It is understandable that this cannot be successful in 100% of the cases.

Selection logic

General

Which goods receipts should be reported when - it depends essentially on the selection logic set for the reporting country.

In standard the selection logic “_” (blank) is set:

Customizing: Sales and Distribution -> Foreign Trade and Customs / Periodic Declarations -> Control Data -> Data Selection Control -> Data Selection Control:

Message category Intrastat /Country of declaration/Receipt/Import

field “Selection Logic”

The selection logic determines in which way the PO history is to be interpreted: whether and how goods receipts and invoice receipts should be considered.

As a basic principle the evaluation of the PO history is done item by item, i.e. to each PO item exactly one VEIAV-record is created (exception: selection logic A).

Of course a PO item can have several goods- and invoice receipts in a month. These are evaluated individually and their values are cumulated at the end.

The PO history contains as relevant information: point in time, quantity and value.

All other data are taken from the PO, in particular from its import data (exception: selection logic A).

If an invoice receipt is available then the values to be reported are taken from this, not from the goods receipt data. This applies to all selection logics.

Invoice values can be completely different from those in the goods receipts (price variances!). The values of the goods receipts are taken directly from the conditions of the PO item.

Please see the Note 534504 for the explanation of the different selection logics.

Characteristics

“_” (blank) – Report GR and Wait for IR / Import Data from PO

This is the standard selection logic set as default, used by most customers.

How this logic works:

If there is a GR in the reporting month then it is reported if there is also a matching IR.
If there is no IR for the GR in the same month then the GR is not reported, its reporting is postponed until the following month. Then in the following month the GR is reported regardless of whether there is a matching IR available by then or not!
The import data required for the Intrastat report are taken from the PO. Note 213765

A - Report GR and Wait for IR / Import Data from Inbound Delivery

How this logic works:

The logic is identical with that of the above selection logic (blank). The difference is that with selection logic “A” also the deliveries are evaluated (= inbound deliveries, i.e. an SD document).

Why could it be desirable to consider also the deliveries?

Example:

My receiving plant is in Germany. My vendor has plants in different countries, in France, Italy, the USA and Germany. The deliveries to a PO item may be coming from a different country each time. But only those GRs for the deliveries are relevant for Intrastat which are coming from France and Italy!

In this case it is reasonable and necessary to work with deliveries and to consider these for the Intrastat selection. Each delivery is assigned exactly to one GR. As the delivering country in the delivery (field EIPO-VERLD) is evaluated, GRs coming from Germany or the USA are de-selected.

If no delivery is available for a GR then the processing logic is as with the selection logic “_”.
If a delivery is available the foreign trade data (header and item, tables EIKP and EIPO) are taken from the delivery, not from the PO.
For each relevant delivery one record is written to the able VEIAV. So for one PO item several VEIAV-entries may exist. This effect (several VEIAV-records per PO item) may only come up in case selection logic “A” is used.
Only deliveries with foreign trade data are considered.

Requirements:

Confirmation control must be activated:
Entry in table T163D with IBTYP = “2”: external confirmation category (field EBTYP) must be assigned!

Entry in T163G must be available:

Access with: BSTAE = EKPO-BSTAE

EBTYP = T163D-EBTYP

The direct assignment from deliveries to goods receipts must be activated via table T163G. For this the following customizing setting is necessary:

Purchasing -> Confirmations -> Set Up Confirmation Control -> select Confirmation Control Key (EKPO-BSTAE) -> double click on Confirmation Sequence -> flag “GR Assignment” must be set!

Technically:

The assignment of delivery and GR is created via the filed ETENS (Sequential Number of Vendor Confirmation): Tables EKES and EKBE.

The deliveries for the PO item are read in FORM ship_notific_doc_determine (RMIMSELS)

Relevant deliveries “replace” the normal PO item, i.e. in case there are 4 deliveries for a PO item the PO history analysis runs through 4 times. As the history records of the GRs are assigned to a specific delivery, only these relevant GRs are considered.

The sorting of the entries not matching the delivery happens at the end of FORM eliminate_po_hist_items_after (RMIMSELS).

B - Report Invoice Receipt (IR) / Import Data from MM Purchase Order

How this logic works:

Goods receipts are not considered at all! Only invoice receipts are relevant. For this reason also only the PO history of the selected reporting month.
The import data required for the Intrastat report are taken from the PO.

C – Report GR / Import Data from MM Purchase Order

How this logic works:

If there is a GR in the reporting month then it is reported regardless of whether there is a matching IR or not.
The import data required for the Intrastat report are taken from the PO.

How the evaluation of the PO history works?

The processing of the PO history of a PO item comprises of the following steps:

Reading the PO history
Consolidation of the goods movements
Consolidation of the invoice movements
Assignment of the invoices to the goods movements
Determination of the statistical value of the item

The central processing routine of the PO history is FORM po_history_analyze (Include RMIMSELS).

The routine uses two central internal tables:

lt_work_po_hist (short: HISTORY-table): this table contains the data of the PO history. This is also where the consolidation of these data takes place.

pt_po_hist_result (short: RESULT-table): the program tries to assign the invoice movements to the goods movements. The result is written into this table. At the end of the routine the invoice values and statistical values are also stored here.

The goal of the routine is to generate the RESULT-table from the HISTORY-table. The RESULT-table contains at the end:

MEIS: assignment of the IRs to the GRs

VI99: assignment of the credit memos to the goods returns.

At the end of the routine the statistical values are derived from the invoice values contained in the RESULT-table, and they are also written to the RESULT-table. The RESULT-table can contain several records during the processing of the PO history of the PO item. The invoice value and the statistical value reported for this item is the sum of these records respectively.

The summation of the values and the potential currency conversion happens in the routines:

FORM get_charact_rechnweak

FORM get_charact_grenznweak.

Tips for debugging

After reading the PO history of the item in FORM read_po_history_db the preselection of the data takes place in FORM eliminate_po_hist_items_before.

After this routine the HISTORY-table is available in its initial state. A good point for finding out which data of the PO history are being processed.

After this it is recommended to check the contents of the HISTORY-table and the RESULT-table (which is created later on) after each call of a routine, to find out if records have been added or deleted.

At the end of the central routine after FORM no_referenced_items_spread the RESULT-table is available in its almost final state. Now only the determination of the statistical values is left, which are then also written into the RESULT-table. If the determination of the statistical values for an item is to be checked then a breakpoint should be set at the following line:

IF ps_po_item-pstyp <> gc_item_categ_consignment.

Which types of PO-history records are processed?

The records of the PO-history (DB-table EKBE) to be processed can be divided into two main groups:

goods movements (goods receipts [GRs] and goods issues [GIs])
invoice movements (invoice / cancelation / credit memo / subsequent credit / subsequent debit)
(An additional special type are records in which the “consumption of the provision” is updated. These are however only required in the special scenario of subcontracting).
For the identification of the EKBE-records the following 2 table fields are relevant:
VGABE = Transaction type
SHKZG = Debit/credit indicator

Schematic representation of the processed EKBE-records

Goods movements:

VGABE	SHKZG	Meaning	Designation	Sign
1	S	Goods receipt	GR	plus
1	H	Goods issue	GR	minus
6	S	Stock transfer	GI	plus

Invoice movements:

VGABE	SHKZG	Meaning	Designation	Sign
2	S	Invoice	IR / IR-L	plus
2	H	Credit memo / cancelation	IR / IR-L	minus
3	S	Subsequent debit	SDeb / SD-L	plus
3	H	Subsequent credit	SDeb / SD-L	minus

Subcontracting:

VGABE	SHKZG	Meaning	Designation	Sign
7	S	Consumption of the provision	SC	plus

the text of the “Designation” in the PO depends on the filed EKBE-BEWTP (table field: T163B-BEWTK).

Goods movements

Types of goods movements

Goods receipt

How do I recognize a goods receipt (in the PO history)?

All goods movements with a positive value which are not a cancelation for a return to the vendor.

Technically:

VGABE = 1

SHKZG = S

Normal case:

Movement type 101

Goods receipt cancelation

How do I recognize a goods receipt cancelation (in the PO history)?

All goods movements with a negative value which are not a return to the vendor.

Technically:

VGABE = 1

SHKZG = H

Normal case:

Movement type 102 ( = cancelation of 101)

Return to the vendor

How do I recognize a return to the vendor (in the PO history)?

All goods movements with a negative value whose movement type is marked as return delivery in the customizing:

Transaction OMJJ: field “Print item” = “2” (technically: T156-KZDRU = “2”)

Technically:

VGABE = 1

SHKZG = H

Normal case:

Movement types 122 and 161

Cancelation of a return to the vendor

How do I recognize a cancelation of a return to the vendor (in the PO history)?

All goods movements with a positive value whose movement type is defined in the customizing as cancelation to a movement type defined as return delivery. So first the movement type for returns must be checked to find out which cancelation movement type is defined for it:

Transaction OMJJ: select movement type for returns and in the navigation tree select “Reversal/follow-on movement types” -> the cancelation movement type can be found in the line with “FCode”= ST (Reversal) (technically: T156N-BWART-NEXT)

Technically:

VGABE = 1

SHKZG = S

Normal case:

Movement types 123 (= cancelation of 122) and 162 (= cancelation of 161).

Consolidation of the goods movements

“Consolidation” of the goods movements read from the PO history means that specific movements can be summed up or rejected. This happens in:

FORM GR_CANCELLATION_CONSOLIDATE

(: for selection logic “B” this routine does not run through, as only IR-documents are present in the HISTORY-table).

The consolidation is carried out in two steps:

"Step 1": consolidation of the goods returns

Movement types defined as returns and their cancelation movement types are determined: FORM credit_movement_types_get.

Then the returns are consolidated with the return cancelations. As no direct relationship (no reference number) exists between the cancelation and the original document, the consolidation “neighborly”, i.e. a cancelation document is settled with the goods return that is closest in time before it. In this process identical posting periods are not used a restriction (technically: parameter gp_grcan = initial). The cancelation entries and the GR-entries with quantity 0 are then deleted from the HISTORY-table.

"Step 2": consolidation of the goods receipts

All goods movements that are not equal the returns and return cancelations determined in the previous step are now processed in the same way as in the first step, i.e. entries with SHKZG = H (GR-cancelations) are settled with the entries with SHKZG = S (GRs).

Result: consolidated HISTORY-table:

entry with VGABE = 1 / SHKZG = S -> goods receipt

entry with VGABE = 1 /SHKZG = H -> goods return

Special routine:

There are so-called unvaluated goods receipts (both for VGABE = 1 and also for stock transfers: VGABE = 6) whose EKBE-records contain no values (filed EKPO-WEUNB = X). For these entries too, the values have to be determined though. This happens in FORM non_valued_gr_value_get.

The values are calculated by rule of three from the net value of the item (EKPO-NETWR):

GR value = (net value of the item / item quantity) x GR quantity= WRBTR (value in document currency).

Then optionally a conversion into the local currency may be necessary: = DMBTR (value in local currency).

The otherwise strict chronological processing logic of the movements (i.e. a cancelation document is settled with the goods receipt that is closest in time before it) is abandoned if the cancelation of the goods receipt takes place only in the subsequent period. In this case the system attempts to settle the cancelation with a goods receipt of the same period, otherwise the GR would be reported twice (in the actual and in the previous period). Notes: 1436820, 1717468, 1787702 and 1972369

Invoice movements

Types of invoice movements

Invoice receipt

How do I recognize an invoice receipt (in the PO history

All movements marked as an invoice receipt (IR) with a positive value.

Technically:

VGABE = 2

SHKZG = S

Invoice receipt cancelation

How do I recognize an invoice receipt cancelation (in the PO history)?

All movements marked as an invoice receipt (IR) with a negative value which are not credit memos. Cancelations and credit memos cannot be distinguished from one another in the PO history screen. Cancelations are basically no other than credit memos for the whole invoice value. To be able to identify “real” cancelation entries the billing documents themselves need to be examined (by double click in the PO history). There the number of the canceled invoice document can be found in fields RBKP-STBLG and BKPF-STBLG.

Technically:

VGABE = 2

SHKZG = H

How are cancelations of an invoice receipt processed?

For the identification of “real” cancelation documents (i.e. not credit memos) the selection program must read the underlying DB-tables (BKPF and RBKP). The check happens in FORM consolidate_inv_cacnellations.

There the number of the canceled document is contained in field STBLG. Now these reference documents are read from the PO history and examined: are the original document and the cancelation document from the same period?

- - - yes: they get cumulated (i.e. they offset each other)
    - no (i.e. the invoice is from a previous period): the cancelation document is ignored! The system pretends there is no cancelation (in Intrastat for MM-documents there is no correction procedure like for SD-documents).

Technically: the cancelation document for an invoice of a previous period is excluded from the further processing.

Reason: the invoice receipt has been reported in the previous period as the cancelation document was not yet available at that time. In order to ensure correct reporting it must be reconstructed what has been reported already in previous periods. And in the previous period the (in the meantime canceled) IR has been reported. For this reason the IR of the previous period is preserved. If this got cumulated with the cancelation, then the GR assigned to this IR would become “free” and would get reported again.

Credit memo

How do I recognize a credit memo (in the PO history)?

All movements marked as an invoice receipt (IR) with a negative value which are not invoice receipt cancelations.

The MM-credit memo has the character of returns- or value credit memo in SD. See the section “Invoice receipt cancelation” above on how “real” cancelation documents can be identified. Everything that is not identified as a cancelation of an IR is a credit memo.

Technically:

VGABE = 2

SHKZG = H

How are credit memos processed?

With credit memos there is a further, not insignificant difficulty in addition to the differentiation to cancelations: a credit memo can be created based on a goods return to the vendor – but does not have to be. The credit memo may also be created because a part of the delivered goods is of poor quality or similar (i.e. there is no goods return involved). In this case it has the character of a subsequent credit.

The problem here is thus the following: if the credit memo was created for a goods return then it must be considered for Intrastat: this return delivery is to be reported as a dispatch (with transaction VI99). However there is no direct link between credit memo and goods movement. Neither the PO history, nor the credit memo itself contains the information to which goods return the credit memo is related. The credit memo is created with reference to the PO (as all goods movements and invoice movements), never with reference to the material document (exception: cancelations do contain the number of the original IR).

What do MEIS/VI99 do in this case?

Goods returns and credit memos are assigned to each other chronologically, i.e. after the consolidation of the invoice cancelations there are no more cancelation entries in the HISTORY-table: all remaining records with VGABE = 2 and SHKZG = H are credit memos.

These are (if possible) assigned to the return deliveries as it is assumed that if a return delivery took place then a credit memo was created for it. The assignment is recorded in the RESULT-table: FORM consolidate_gr_and_ir.

(: not to forget that these instances are dispatches and are reported with VI99. The routine however must also run in MEIS to ascertain whether the credit memo refers to a goods return or not.)

The assignment of the credit memos to the returns deliveries is done in the following way: starting with the oldest return delivery the credit memo next to it chronologically is searched for. The assignment of these two documents is written to the RESULT-table. It is determined based on the quantities if a further credit memo is necessary to cover the quantity in the delivery. The values written to the RESULT-table are always taken from the IR-records. If the quantities in the return delivery and credit memo are different then the value is calculated by the rule of three.

Return deliveries without IR are also written into the RESULT-table, the values in this case are taken from the GR-record of the return delivery.

Remaining credit memos (which could not be assigned to a goods movement) are handled as subsequent credit (value credit memo) and are consolidated with older invoices of the reporting period in FORM consolidate_cred_debits_gr_ir.

(If something still remains afterwards, then these entries are though saved to the table lt_no_ref_po_hist_inv_credit, but are not processed later on).

the character of a credit memo is not clear. If no goods return can be determined then it obtains the character of a value credit memo which reduces the invoice value of an existing invoice (up to full cancelation!).

Problem in case of selection logic “B”: the assignment to GI does not happen. Due to Note 791895 credit memos are basically handled as subsequent credit. VI99 returns no result. Note 1051673 explains this scenario and possible solutions.

Subsequent debit

How do I recognize a subsequent debit (in the PO history)?

All movements marked as subsequent debit (SDeb or similar) with a positive value.

The MM- subsequent debit has the character of value debit memo in SD.

Technically:

VGABE = 3

SHKZG = S

How are subsequent debit memos processed?

The value of the subsequent debit is added to the value of the invoice that lies closest before it chronologically in the same month. If the quantity of the subsequent debit is greater than the quantity in the invoice then the next oldest invoice within the same month is used, and so on: FORM consolidate_cred_debits_gr_ir.

Subsequent debits which cannot be assigned to any invoice from the same month are written into the table lt_no_ref_po_hist_subseq and the very end added to the values in the RESULT-table: FORM no_referenced_items_srpead.

Subsequent credit

How do I recognize a subsequent credit (in the PO history)?

All movements marked as subsequent debit (SDeb or similar) with a negative value.

The MM- subsequent credit has the character of value credit memo in SD.

Technically:

VGABE = 3

SHKZG = H

How are subsequent credit memos processed?

The value of the subsequent credit is subtracted from the value of the invoice that lies closest before it chronologically in the same month. If the quantity of the subsequent credit is greater than the quantity in the invoice then the next oldest invoice within the same month is used, and so on: FORM consolidate_cred_debits_gr_ir.

Subsequent credits which cannot be assigned to any invoice from the same month are written into the table lt_no_ref_po_hist_subseq and the very end subtracted from the values in the RESULT-table: FORM no_referenced_items_srpead.

Consolidation of invoice movements

“Consolidation” of the invoice movements read from the PO history means that certain movements can be summed up or rejected.

First the invoice cancelations are matched with the original invoices: FORM consolidate_inv_cancellations
Then all cancelations to invoice receipts are eliminated from the HISTORY-table, entries with VGABE = 2 are either invoices (SHKZG = S) or credit memos (SHKZG = H).
Now subsequent debits and credits are cumulated (if possible) with existing invoice receipts (see details below). The following routine is called up once for subsequent credits and once for subsequent debits: FORM consolidate_cred_debits_gr_ir.
In an intermediate step the assignment of the goods returns to the credit memos is done and the result written to the RESULT-table: FORM consolidate_gr_and_ir
Afterwards the goods returns are assigned in the RESULT-table to the credit memos found. These credit memos are settled now.
Credit memos without assignment to a return delivery are handled as subsequent credit. The consolidation of these credit memos with the invoice receipts happens when the FORM consolidate_cred_debits_gr_ir is called up again.
In the HISTORY-table all credit memos, subsequent credits and debits have been handled now. Potential remaining subsequent credits/debits are collected in the table lt_no_ref_po_hist_subseq.

Assignment of the invoice movements to the goods movements

Now is the turn for “normal” invoice receipts. These have to be assigned to goods receipts: FORM consolidate_gr_and_ir
Beginning with the oldest goods receipt, the invoice that lies closest AFTER it chronologically in the same month is searched for and these documents are assigned to each other in the RESULT-table. It is determined based on the quantities if a further invoice is required to cover the quantity of the goods receipt.
The values are always taken from the IR-records (not from the GR-records), if necessary calculated by the rule of three. GRs without IRs are also written into the RESULT-table, in this case the values are taken from the GR-records.
Remaining credit memos are handled as subsequent credit memos. First the system attempts to subtract their value from the value of older invoices of the same month: FORM consolidate_cred_debits_gr_ir.
Any remaining entries are written to the table lt_no_ref_po_hist_subseq. These entries are then cleared with the invoice values in the RESULT-table (subtracted): FORM no_referenced_items_spread.

Clearing of debits / credits with invoices (technically)

The clearing happens in FORM consolidate_cred_debits_gr_ir.

The following logic is valid since Note1560216 (previously the clearing happened based on quantities for subsequent credits):

Credit:

IR-value > Credit value

IR-value =< Credit value

IR-value = IR-value minus credit value

Credit value = 0

Credit quantitiy = 0

IR-value = 0

IR-quantity = 0

Credit value = IR-value minus credit value

continue with next IR

Debit:

IR-value <=> Debit value

IR-value = IR-value plus debit value

Debit value = 0

Debit quantity = 0

“Value” actually stands for 2 values here: EKBE-DMBTR (in local currency) and EKBE-WRBTR (in document currency). In case different currencies are involved the clearing can “drift” with subsequent credits, i.e. DMBTR = 0 while WRBTR <> 0 (or vice versa), see Note 2138274

In the routine the OUTER-structure contains the data of the subsequent credits and subsequent debits and the INNER-structure contains the data of the invoice receipts.

Special business transactions

Stock transfer

What does a stock transfer mean?

A stock transfer means the transport of goods from one plant into another within the same concern. We differentiate between inter-company (where plants belong to the same company code) and cross-company (where plants belong to different company codes) stock transfers.

Before Note 801369 there was no differentiation between inter-company and cross-company stock transfers, the reporting was done based on goods issues.

Inter-company stock transfer

It is also known as a replenishment delivery. The order type used is stock transfer (order type ‘UB’).

As the goods remain with the company and only their location is changed, no exchange of money is involved in the process so there is nothing to bill. The PO history contains only GI and GR.
For internal stock transfers the following uniqueness exists: the reporting is based not on the goods receipts (invoice receipts do not exist anyway), but on the goods issues instead. The reported values are taken from the good issue documents.
The VAT ID number of the vendor and of the customer does not have to be reported in case of stock transfers.

Example:

Company code CC01 transfers goods from its Plant 1 in country A across the border into its Plant 2 in country B.

Inter-company stock transfers can be carried out in two different ways: the 1-step process which consists of just a PO and a GI (the GR happens automatically in the background) is not suitable for the Intrastat reporting. For that the 2-step process must be used.

Schematic representation of the 2-step process:

Application

Operation

Company code

MM

PO (UB)

↓

CC01

SD

Delivery +

goods issue +

WIA invoice

CC01

MM

goods receipt

CC01

Who has to report what?

Delivery:

- Dispatch of the goods from country A

Who reports? -> CC01

How? -> VE01 -> selects WIA

in order to be able to report the dispatch a dummy invoice with billing type WIA (plants abroad) and item category NLN (stock transfer) has to be created. It is crucial here to set the billing relevance of the item category to ‘J’ in customizing

- Receipt of the goods in country B

Who reports? -> CC01

How? -> MEIS -> selects UB

In case of internal stock transfer only the GI documents are evaluated and the values are taken from there: EKBE-VGABE = ‘6’.
When filling the RESULT-table SHKZG must be reversed.
In case of internal stock transfer there is no invoice and so no net value in the PO (= zero). For the calculation of the condition type GRWR the pricing procedure RM2000 exists in standard; the calculation is done based on the condition type P101-> effect in MEIS: the final calculation of the statistical value leads to a different result than the calculation by rule of three if P101 is not equal the value from the goods issue.

Technically:
EKKO-BSAKZ = T
EKKO-RESWK <> initial (= delivering plant)
EKKO-LIFNR = initial
EKKO-LLIEF = initial
EKPO-REPOS = initial (i.e. no IR is awaited)

Cross-company stock transfer
The order type used is standard PO (order type ‘NB’).
- Not only the location but also the ownership of the goods is changed. The delivering company code sends the receiving company code an invoice for the delivered goods. Thus the PO history contains not only a GI and a GR but an IR as well.
Example:
Company code CC01 orders goods from company code CC02 for its Plant 1. CC02 delivers the goods from its Plant 2. CC02 issues an intercompany invoice to CC01.

Schematic representation:

Application	Operation	Company code
MM	PO(NB)	CC01
SD	Delivery + GlDELIVRY	CC02
SD	Intercompany invoice	CC02
MM	GR+ Vendor invoice	CC01

Who has to report what?

Delivery:

- Dispatch of the goods from country B

Who reports? -> CC02

How? -> VE01 -> selects IV

- Receipt of the goods in country A

Who reports? -> CC01

How? -> MEIS -> selects NB

Notes:

The vendor number is determined from the delivering plant (T001W-LIFNR)
The VAT ID number of the vendor and of the customer does not have to be reported in case of stock transfers.

Technically:

EKKO-BSAKZ = initial

EKKO-RESWK <> initial (= delivering plant)

Subcontracting

What does subcontracting mean?

Subcontracting means the transport of materials to an external company for further processing. After the processing the materials are retuned in the form of finished goods (final product).

The company that processes the materials is called the subcontractor. The materials sent to the subcontractor are called subcontracting components. The delivery of the components to the subcontractor is called the provision. The materials are also called components / materials provided (for subcontracting).

Example:

A clothing company sends fabric and buttons to a company abroad. The fabric is dyed, trimmed, and sewn together. The finished clothes are then returned. The amount of work is billed.

How to recognize a subcontracting PO?

From the item category in the PO item: EKPO-PSTYP = ‘L’

Specialties in the document flow:

At the posting of the GR of the finished (processed) materials the consumption of the components is also posted automatically. This is recorded in the document flow (even if these records are not necessarily visible in the PO history): for each consumed component a record is created in table EKBE with VGABE = ‘7’. These records contain the quantity and the value of the components. This is important as the value of the condition GWLB is determined from these records in the transactions MEIS/VI99. The CPU-date and the CPU-time (date and time of entry) of these records correspond to that of the related GRs which allows their assignment.

Who has to report what?

Components:

- Dispatch of the components from country A

Who reports? -> CC01

How? -> VE01 -> selects billing type FL

In order to be able to report the dispatch a pro-forma invoice has to be created. See details in Note 139724

- Receipt in country B

-> subcontractor’s responsibility!

Final product:

- Dispatch from country B

-> subcontractor’s responsibility!

- Receipt in country A

Who reports? -> CC01

How? -> MEIS -> selects PO

Pricing

For the Intrastat reporting of arrivals from subcontracting, in addition to the standard condition type GRWR, another condition type is required: GWLB. Why?

Checking the above figure it becomes clear that the value in the invoice does not contain the value of the materials used, as these were provided (“supplied”) by the subcontractor itself. As the statistical value must contain the complete value of the goods at border-crossing, the information on the value of the supplied components is required. Because of this, for the calculation of the full statistical value of the final product, in addition to the “normal” condition type GRWR (which is derived from the net value of the vendor invoice / PO item) another condition type must be used which contains the value of the supplied components as well: GWLB.

Technical note:

When using master conditions the value of the components is determined from the PO history records with field VGABE = 7 and added to the invoice value. The records matching the GR of the end product are determined based on the creation date (CPUDT) and time (CPUTM); these are identical for the GR of the final product and the consumption record of the components. This happens in FORM CONSIDER_SUBCONTR_STAT_VALUE (include RMIMSELS).

Consignment (MM-view)

What does consignment mean?

The vendor’s goods are delivered into my plant (“consignment fill-up”) but the ownership of the goods remains with them. The goods are managed in an own stock (“consignment stock”). I become the owner of these goods only upon the “consignment withdrawal”. Then the vendor sends an invoice for the goods.

Terminology:

Consignment stock = vendor’s stock, stored and managed in my own plant

Consignment order = I order goods from a vendor who delivers these into his consignment stock in my plant

Consignment fill-up = vendor delivers the goods into his consignment stock in my plant

Consignment issue/withdrawal = goods are posted from the vendor’s consignment stock into my own stock (with the aim of consumption, further processing or selling)

Consignment pickup = vendor retrieves the goods from his own consignment stock

How to recognize a consignment PO?

From the item category in the PO item: EKPO-PSTYP = ‘2’.

Who has to report what?

- Dispatch from country B

-> subcontractor’s responsibility!

- Receipt in country A

Who reports? -> CC01

How? -> MEIS -> selects PO

Consignment pickup needs to be reported by CC01 as dispatch! This functionality is not developed. The goods movement must be entered manually (using transaction VEFU).

Pricing:

In case of consignment orders the price determination is not active as the goods become own property only at withdrawal from consignment into own stock. As a result the value determination happens only at the GR into own stock. A longer time gap between consignment fill-up and consignment withdrawal is possible, however for Intrastat the time of the border-crossing is relevant, i.e. the time of the consignment fill-up. How can the values be determined then?

Solution: during the selection run the invoice value and statistical value are determined internally via a function module:

“MB_READ_CONSIGNMENT”

Routine: FORM determine_inv_stat_val_consign

Important in this case is the correct maintenance of the pricing procedure, for details see Note 317787

Notes:

The consignment withdrawal is posted without reference to the consignment order and also the invoice receipt (which has reference to the consignment withdrawal), i.e. in the PO history (table EKBE) of the consignment order there are records of only the GRs of the consignment fill-ups.

Internally (transaction MEIS) the selection logic is changed:

_ -> C

A -> D

B -> unchanged.

Third-party purchase order

See general documentation here (hyperlink to SD-FT-GOV relevant page:

http://wiki.scn.sap.com/wiki/display/SD/Intrastat+Dispatch) -> Third-party sales

Region of destination in case of third-party purchase: see consulting Note 1387693

Special logic for Italy: Report arrival, even if delivery address is not in Italy, see Note 1324468

Repair

Goods which are imported to be repaired do not have to be reported in Intrastat as the value of the goods does not change. Additional parts, on the other hand, which alter the value must be reported as well as imported material that is used for the reparation.

Important terms

Scheduling agreements

Scheduling agreements are (as opposed to a normal PO) generally active over a longer time period (often several years). It is recommended to use a scheduling agreement instead of a normal PO in case regular deliveries of the same goods, with the same conditions by the same vendor are needed. If a new delivery of the goods by this vendor is required then a new PO is not necessary each time, but instead only a new schedule line can be created with the requested order date for the scheduling agreement item. This saves time and effort.

As the price conditions can change throughout the year, in most cases time-dependent conditions (“master conditions”) are used in case of scheduling agreements. It means that the pice conditions of the document are not constant but variable on the time axis. For this reason the conditions in the conditions screen of the order item have no value, generally only the condition type PB00 (gross price) is shown there.

There is nothing special about scheduling agreements themselves. The specialty lies in the master conditions which are used in most cases in scheduling agreements, see details below. There is an exception: subcontracting scheduling agreements without master conditions (see part “Subcontracting” above).

Notes:

Transaction for displaying scheduling agreements/ outline agreements: ME33L

Indicator that the document is a scheduling agreement: EKKO-BSTYP = ‘L’

Indicator that master conditions are used: EKKO-STAKKO = ‘X’

Master conditions

Master conditions are time-dependent conditions. They are used mainly in scheduling agreements.

As the conditions of the order item are not constant but variable on the time axis, the tab “Conditions” of the order item has no entries generally except for the condition type PB00 (gross price). The field “statistical value” in the import data of the item is in this case also zero of course.

The price determination is carried out only at the time of the GR as this time point is decisive for selecting the relevant time-dependent condition. To display the condition values determined at the GR, the PO history of the document item is to be checked; there position the cursor on the GR and from the menu select Environment -> Conditions. The condition values determined by the price determination can be displayed here (if not, then something is amiss with the price determination).

Consequently, in the selection programs the values of the master conditions have to be determined from the document flow or (in case of selection logic B) calculated:

FORM recalculate_stat_value_no_pric → FORM pricing_condition_determine

Notes:

Whether in the document master conditions are used can be recognized by field EKKO-STAKKO = ‘X’. The relevant customizing setting is under: Materials Management -> Purchasing -> Scheduling Agreement -> Define Document Types -> indicator “Time-Dep. Conditions” (table T161, can only be activated for scheduling agreements obviously)

Condition type GWLB

The condition type GWLB is required for determining the value of the components to be provided in case of subcontracting. For the calculation of the GWLB value within the order the calculation formula 60 is used in standard. In this formula the bill of material is read and the component are valuated. Technical note: the EXPORT of the components, which are read in the formula 60 per IMPORT, happens in the FM ME_COMPONENTS_MAINTAIN (called from FORM MDPM_MAINTAIN in SAPMM06E). For this reason for normal POs on the condition tab of the order item the condition type GWLB (as well as GRWR) should always be filled.

When using master conditions (field EKKO-STAKO = ‘X’, usual with scheduling agreements) the price determination runs only at the time of the GR; the conditions tab in the order contains no values, but the EKBE-record of the GR does: there the net value is filled. As the Intrastat selection program determines the value from the EKBE-records, the value determination for the master conditions is the same as in the normal case.

The net value -and based on that, the value of the condition type GRWR- can be determined from the EKBE-values, but where does the value of the components provided come from, i.e. condition type GWLB? Answer: when posting a GR for a subcontracting order item not only an EKBE-record for the GR is created but also EKBE-records for the consumed components (field VGABE = ‘7’). These are not visible in the PO history. These records contain the value of the components (this value is determined by the price determination at the GR posting).

GWLB = 0?

If despite correct customizing and definition for the condition type GWLB still zero value is determined, then the reason could be that there is no stock for the components used. As a result the stock cannot be valuated, a quantity = 0 will always have value = 0 (so it is not sufficient to just enter a price, stock must exist too).

Notes: 139724 and 1087403

Determination of the values

Invoice value

The invoice value for Intrastat is not read from the PO item but determined from the PO-history (table EKBE). There are 2 fields which contain the value of the GR and the IR:

EKBE-DMBTR = amount in local currency (currency: T001-WAERS)

EKBE-WRBTR = amount in document currency (currency: EKBE-WAERS)

As outlined earlier in this document, the system tries to assign the IRs to the GRs. The result is recorded in an internal table (RESULT):

If an IR could be assigned to a GR, then:

WRBTR = derived from the amount in the invoice

DMBTR = derived from the amount in the invoice, converted using the conversion factor from the invoice

FLGIR = X

If no IR could be assigned to the GR, then:

WRBTR = derived from the net value in the PO

DMBTR = derived from the net value in the PO, converted using the conversion factor from

a) table TCURR, determined with date EKBE-BUDAT or

b) the PO, in case the indicator for fixing the exchange rate is set

FLGIR = _

At the end in the routine FORM get_charact_rechnweak (RMIMSELS) the amounts from the RESULT- table are added up. If necessary, the conversion from the document currency into the reporting currency is carried out there as well.

Note:

Due to the complex assignment of IRs to GRs it is often difficult to retrace the formation of the RECHNWEAK-values.

Special cases:

Internal stock transfer: invoice value is determined from the EKBE-record of the GI (EKBE-VGABE = 6)

Consignment: invoice value is determined from the pricing procedure as no price determination is active.

Debugging / description of the program flow:

After the consolidation of the PO item history comes the assignment of GRs to IRs and with that the determination of the invoice value in the routine:

FORM consolidate_gr_and_ir (RMIMSELS)

In case of reporting based on IRs it is the routine:

FORM consolidate_ir (RMIMSELS).

The result is saved into the table pt_po_hist_result (short: RESULT) in the fileds:

DMBTR = amount in local currency

WRBTR = amount in foreign currency

This RESULT-table thus contains the outcome of the assignment of the entire PO item history (except: reporting based on IRs). This is necessary to be able to track what has been reported in previous periods. Then the superfluous records are deleted from the table, i.e. records that are not assigned to the relevant reporting period (fields MONAT and GJAHR). The responsible routine is:

FORM eleminate_po_hist_items_after (RMIMSELS)

Now all the invoice values have been found for this PO item for the given reporting period. In most cases there are several records contained in the RESULT-table, this is due to the fact that for the PO item in the given period several GRs and/or IRs exist.

What is still missing at this point are the statistical values belonging to the invoice values.

The potentially required conversion of the invoice values into the reporting currency as well as the necessary cumulation of the RESULT-records into one VEIAV-record happens later in the routine:

FORM get_charact_rechnweak (RMIMSELS)

With a breakpoint at the beginning of this routine you can find out which invoice values have been determined for this PO item based on the existing GRs and IRs.

Statisitcal value

After the determination of the invoice values in the RESULT-table (see above) the corresponding statistical values must now be determined. In the coding this happens in include RMIMSELS after the line:

*-- Statistischen Wert ermitteln für Normalgeschäfte

The problem is that the table EKBE only contains the corresponding invoice value, but not the statistical value. The IR-document doesn’t contain it either. The statistical value (i.e the value that is marked in the pricing procedure EKKO-KALSM with subtotal = C) is only available in the foreign trade data of the PO item (field EIPO-GRWRT), but there always relating to the total order quantity.

As the statistical value is determined through pricing and this document-relevant information is stored in table KONV, it provides another way of determination for the statistical value from these tables.

Internally there are 2 possible ways for the determination of the statistical value:

method A = from field EIPO-GRWRT
method B = from KONV-data

Note: method B is preferred. However this method is not always usable, and in such cases method A is used.

Step 1: method A or method B?

FORM determine_cond_types_stat_val

The condition types required for the determination of the statistical value are sought from the pricing procedure (e.g. GRWR and GWLB -> table A), then it is checked:

is a formula needed for the determination of the statistical value or
is the statistical value defined as a from-to interval, in which a subtotal is defined which refers to a value outside the interval?

If yes, and if EIPO-GRWRT <> 0: method A is used (technically: field lv_no_recalc_possible = X); otherwise: method B.

Step 2a: method A

This method is used also in case method B (which runs through before!) determined a statistical value = 0.

FORM calculate_stat_value_imp_data

The statistical value is determined from EIPO-GRWRT by rule of three. The calculation method is (simplified):

RESULT-GRWRT_P = EIPO-GRWRT of the PO item * RESULT-quantity / EKPO-quantity of the PO item.

Result: statistical value in local currency for each RESULT-record of the item (in local currency, as EIPO-GRWRT is stored in local currency as a basic principle).

Step 2b: method B

FORM recalculate_stat_value_no_pric

Loop over RESULT-table

è read table KONV with entries from table A for the corresponding PO item -> table B

FORM condition_recalculate.

Loop over table A

-> read table B with corresponding condition type from table A (e.g. GRWR). Determination of the parameters relevant for the calculation rule (percentage, quantity-based, amount-based) of this condition type, for calling:

FORM recalculate_cond_type_no_pric

-> currency conversion from condition currency into document currency. Post calculation of the condition amount based on the RESULT-quantity (e.g. in case of quantity-based condition type) or based on the RESULT-amount (e.g. in case of amount-based condition type). Result: condition amount matching the RESULT-quantity.

-> addition of determined condition amount to RESULT-GRWRT_P

Endloop over table A.

Endloop over RESULT-table.

Result: statistical value in document currency for each RESULT-record of the item.

Technical note: access KONV with EKKO-KNUMV from the PO header, in case of master conditions with EKBE-KNUMV of the GR.

Step 3: indicator if method A or B

Whether the method A or B was used to determine the statistical value (field RESULT-GRWRT_P) is recorded in field RESULT-GRORI:

= A -> method A
= B -> method B

Last step:

The potentially required conversion of the statistical value into the reporting currency as well as the necessary cumulation of the RESULT-records into one VEIAV-record happens later in the routine:

FORM get_charact_grenzweak (RMIMSELS).

With a breakpoint at the beginning of this routine you can find out which statistical values have been determined for this PO item.

Currency conversion

Note 1104062 must be implemented.

See also the notes on currency conversion here (hyperlink to relevant SD-FT-GOV wiki page)

Preliminary note:

Currencies to be considered:

The following currencies are considered for the determination of the invoice value and statistical value. In the ideal case all currencies are identical.

Abbr.	Description	determined form
HW	local currency (currency of the company code in the PO)	T001-WAERS, accessed with EKKO-BUKRS
BW	document currency (of the PO) = PO currency	EKKO-WAERS
MW	reporting currency	parameter of the selection screen
RW	currency of the vendor invoice	RBKP-WAERS or BKPF-WAERS
KW	currency in the condition record	KONV-WAERS

It is ensured by pre-work that by the time the central routines for currency conversion are reached the amounts are available in either document currency or local currency (or both).

Representation of the conversion factor:

In case a conversion factor field has a negative value, e.g. -2,000, then this means that for the foreign currency translation the reciprocal value is used, here: 1 / 2,000.

In the screen fields a negative factor is recognizable by the prefix “/”.

Fixed exchange rate indicator

If in the PO the “Indicator: Fixing of Exchange Rate” (field EKKO-KUFIX) is set then for the conversion from BW into HW the exchange rate is taken from the PO (field EKKO-WKURS).

Currency conversion for the invoice value

Preliminary step: currency conversion for EKBE-records

FORM inv_po_currency_convert

[Core assumption: EKBE-WAERS is identical with the currency from the IR (RBKP-WEARS or BKPF-WAERS): this however does not have to be identical with the order currency EKKO-WAERS.]

The system checks if the amount in foreign currency (field EKBE-WRBTR with currency WAERS) is the same as the document currency. If not, then the field WRBTR is converted into the document currency. If the document currency is identical with the local currency, then the exchange rate is taken from the invoice and this exchange rate (RBKP-KURSF or BKPF-KURSF) is used for the conversion into document currency, otherwise via TCURR with the posting date of the IR.

Notes:

The currency of EKBE-WRBTR of an GR is always the same as the document currency.
In case of non-valuated GRs (field EKPO-WEUNB = X) DMBTR and WRBTR are determined from the PO data via rule of three. Here too, a currency conversion is possibly necessary with the posting date of the GR: FORM non_valued_gr_value_get.
Since the implementation of Note 1104062 the routine is also used –in case the parameter “Exchange Rate from Invoice” is set on the selection screen- to read the exchange rate from the IR documents.

Central routine:

FORM get_charact_rechnweak

-> FORM convert_inv_based_values

The preliminary step guarantees that when this routine is reached the invoice value is available in both document currency and local currency in every record of the RESULT-table. Of course the document currency and local currency may be identical:

RESULT-WRBTR = invoice value in document currency (in field RESULT-WRWAE)
RESULT-DMBTR = invoice value in local currency (in field RESULT-DMWAE)
The system aims to have the amount in reporting currency. For the conversion of field RECHNWEAK into reporting currency the following rules apply:

Logic for the conversion of field RECHNWEAK into the reporting currency:
Rate type M Rate type I
MW = BW
OK
OK
MW = HW
OK
BW → (M/fix) → MW (*)
BW → (I) → MW
MW <> BW <>HW
BW → (M) → MW
BW → (I) → MW
HW → (M/fix) → BW → (I) → MW (**)

(M) conversion with exchange rate type ‘M’

(I) conversion with exchange rate type ‘I’

(M/fix) conversion with exchange rate type ‘M’, if in the PO the indicator “Fixing of Exchange Rate” is set then the exchange rate is taken from the PO.

(*) only if the amount is not available in HW, it should not occur!

(**) only if the amount is not available in BW, it should not occur!

For the determination of the exchange rate from the customizing the posting date (field EKBE-BUDAT) of the IR is used.

If no IR could be assigned to the GR then the posting date of the GR is used.

Basic rule: the conversion into the reporting currency is done always from the document currency, never directly from the local currency!

Currency conversion for the statistical value

Preliminary step: currency conversion for KONV-records

FORM recalculate_cond_type_no_pric

Aim: conversion of condition currency into document currency.

If the first bit of KONV-KBFLAG is set then the conversion happens with KONV-KKURS directly from the condition currency into the document currency (in this case = the local currency), otherwise via TCURR with KONV-DATUM (price date of the condition).

Central routine:

FORM get_charact_grenzweak

-> FORM convert_stat_based_values

The statistical value of each movement is available in the RESULT-table:

Fields GRWRT_P statistical value

GRWCU currency for statistical value

Currency GRWCU is:

either = local currency, if determined with method A (field GRORI = A)

or = document currency, if determined with method B (field GRORI = B).

1^st step: conversion from HW into BW:

If the statistical value is available in local currency (so derived from EIPO-GRWRT = method A) then it is first of all necessary to convert this value into document currency. The exchange rate is the one that was used in the PO, to convert the statistical value (in document currency, determined by price determination) into the local currency (for EIPO-GRWRT).

Conversion rule:

If the fixed exchange rate indicator is set

or

if the statistical value is determined from EIPO (RESULT-GRORI = A) and pricing date is initial:

exchange rate = exchange rate from the PO (EKKO-WKURS)

otherwise:

exchange date = pricing date of the document item (EKPO-PRDAT), with subsequent determination of the exchange rate from TCURR.

2^nd step: conversion from BW into MW:

Now the statistical value is available in the document currency (BW).

The corresponding amount in the reporting currency is required now. For the conversion the following rules apply:

Logic for the conversion of field GRENZNWEAK into the reporting currency:

	Rate type M	Rate type I
MW = BW	OK	OK
MW = HW	BW → (M/fix) → MW	BW → (I) → MW
MW <> BW <>HW	BW → (M) → MW	BW → (I) → MW

For the determination of the exchange rates from the customizing the posting date of the invoice receipt (EKBE-BUDAT) is used.

If no IR could be assigned to the GR then the posting date of the GR is used.

Basic rule: the conversion into the reporting currency is done always from the document currency, never directly from the local currency!

Example: Exchange rate changes between the PO creation and the invoice creation

Document currency Local currency Statistical value 50%

---------------------------------------------------------------------------------------------------------------

PO 1000 USD 100 EUR 50 EUR (EIPO)

500 USD (KONV)

Exchange rate factor in the PO : * 10

Invoice 1000 USD 200 EUR

Exchange rate factor at IR : * 5

Result of the determination of the invoice value and the statistical value:

1000 USD 200 EUR 50 EUR (method A)

500 USD (method B)

The statistical value = 50% of the invoice value,

so the correct result is : 500 USD

100 EUR

As you can see: the result using method A is wrong!

For this reason the 50 EUR must be converted using the “old” exchange rate from the PO (1^st step):

50 EUR * 10 = 500 EUR

If the reporting currency = the local currency (EUR), then this value must be converted again into the local currency, however this time using the rate which was used at the IR (2^nd step):

500 EUR / 5 = 100 EUR

____________________________________________________________________________________________________________________________________________________

Parameters relevant for the currency conversion

On the selection screen for the creation of the Intrastat report (Transaction MIES) there are several parameters which are relevant for the currency conversion.

Parameter “INTRASTAT Exchange Rate Type”:

For the determination of the exchange rate from the customizing (table TCURR) the exchange rate type “I” is used, which is to be defined specially to be used in the periodic declarations (otherwise: the exchange rate type “M” = middle rate).

Parameter “Selection by Document Date”:

As by using this parameter the data are selected based on the document date, the date used for the determination of the exchange rate from customizing (table TCURR) is the document date of the IR and the GR (otherwise: the posting date).

Parameter “Exchange Rate Date w/o Invoice”:

If a GR is reported for which no IR could be assigned by the system, the date for determining the exchange rate from Customizing (table TCURR) is set as the 15^th of the reporting month.

Parameter “Exchange Rate Date Invoice in Previous Month”:

If a GR is reported for which the system has assigned an IR with an earlier posting date, then the date of the GR will be relevant for the determination of the exchange rate from Customizing (table TCURR) (otherwise: the date of the IR).

Parameter “Exchange Rate from Invoice”:

The exchange rate used for the conversion from document currency into local currency is taken from the IR document (otherwise: determined from Customizing with the date of the IR). (Note: although setting this parameter should deliver the most accurate result, there is a constellation in which setting it leads to a false result, while not setting it leads to the correct result: exchange rates in Customizing (table TCURR) were changed subsequently / statistical value was determined from EIPO / access of table TCURR with pricing date and posting date of the IR leads to the same rate. Reason: the wrong rate is used for the conversion from HW into BW, then the same (wrong) rate used again for the conversion back from BW into HW.)

Related SAP Notes/KBAs

Correct use of EXIT_SAPLV50G_001 and EXIT_SAPLV50G_002

Intrastat - Selektion von MM-Belegen: Fragen & Probleme

Intrastat - Selektion von SD-Belegen: Fragen & Probleme

Child pages

Intrastat Arrival Part1 - Processing

Intrastat reporting process overview

ERP Foreign Trade Declarations to Authorities - Customizing

Page tree

Data selection

Processing of the purchasing history

Goods movements

Invoice movements

Special business transactions

Important terms

Determination of the values

Related SAP Notes/KBAs

Child pages

1 Comment

SAP consultant NN