Intrastat/Extrastat Implementation

How do we configure Intrastat/Extrastat reporting in S.D, what are the steps to implement them?
- Sai

hi sai,
just to add some valuable information on intrastat
SAP Electronic Compliance Reporting
Purpose
The single market of the European Union reduces the transactions that are officially recorded to imports and exports with countries outside of the EU. Nonetheless, the recording of country-specific intra-European transactions is just as relevant for individual member states of the European Union, to derive information about a countrys economic strength, foreign trade activities, and trade. Countries can use this data, for example, to implement measures to optimize its trade conditions.
As a result, every company is obliged to record the necessary statistical data. SAP Electronic Compliance Reporting (SAP ECR) supports you with the statistics declarations that you have to submit to the authorities for transactions involving trade between two member states of the EU. Moreover, you have to provide the statistical data in the proper format for your countrys statistics authorities (these formats vary within the EU). The relevant data for the Intrastat declarations is based on the logistics processes. You can collect the Intrastat-relevant data from these logistics processes and submit them to the national statistics authorities in periodic Intrastat declarations.
Implementation Considerations
SAP ECR helps you create Intrastat declarations, where you can enter the relevant items for dispatches and receipts of traded goods, together with the necessary details. To create the Intrastat declaration for your statistics authorities in your country-specific format, you can use SAP ECR to generate the necessary file and send it to the authorities.
Integration
You can use the nomenclature of goods from SAP Customs Management to determine the commodity codes you use to report the products involved in your logistics processes to the authorities. To do so, you have to configure the settings for commodity codes and their integration with SAP ECR in the Implementation Guide (IMG) of SAP Global Trade Services. For more information about the settings, see the Configuration Guide for SAP ECR at the SAP Service Marketplace, under service.sap.com/swdc ® Download ® Installation and Upgrades ® Entry by Application Group ® SAP Application Components ® SAP Global Trade Services (GTS) ® SAP GTS ® Installation and Upgrade.
Features
●      Master data
○       Provider of information
Companies have to notify the statistics authorities of their intra-European transactions that cross their own countries borders. You can define the appropriate information to identify the company providing the information to the authorities in the master data.
○       Default values for import from worklist
The statistics data for a provider of information's trading activities is based on business transactions in the logistics system. If you use integration with this system, SAP ECR collects the relevant information in a worklist. You can define default values to reduce the effort required to import the worklist into a statistics declaration. The system uses these default values for the imported values in the declaration.
○       Commodity codes
If you want to use the nomenclature of goods for commodity codes and have configured integration with SAP ECR, you have to make these numbers available in your system. To do so, you can create the commodity codes and their descriptions manually or upload XML files from your data provider into your system.
○       Classification
The system lets you classify your products with the correct commodity codes once, to optimize the generation of Intrastat declarations. If you use logistics system integration to create Intrastat declarations, the system can find the valid commodity code automatically for each document item in the feeder system and use it instead to create the Intrastat declaration, instead of the product numbers.
●      Worklist
You can create Intrastat declarations based on your logistics processes in the feeder system. Once you configure integration with the logistics system, the relevant business transactions are transferred automatically to a worklist in SAP ECR, from which you can create the Intrastat declarations. You can also display and delete entries in the worklist, as necessary.
●      Intrastat declaration
You use Intrastat declarations to submit binding information about shipments and goods receipts between two countries in the European Union. You can either aggregate the goods movements for a period and direction by statistical goods movement or record the items for each transaction. You can use SAP ECR to create the declaration file to ensure that your trade information meets the data format requirements of your statistics authorities.
regards
sadhu kishore

Similar Messages

Preference code for intrastat/extrastat

Hi,
Please provide me steps to configure preference code (PAC) for intrastat/ Extrastat repoting.
Thanks
Arpit

If it is a legal requirement, that the VAT number must be in the file that you send to the government, then SAP has to take care about that in its programs if that is not already done.
Such changes can be found in OSS.
I just briefly checked the requirements and had not seen the VAT number for Intrastat puposes, maybe I just overlooked it.
You can find yourself the legal requirements in the offcial manuals:
http://www.agenziadogane.gov.it/wps/wcm/connect/ed/Servizi/Intrastat/

INTRASTAT/ EXTRASTAT- OUTPUT FIELDS

Hello Experts,
For intrastat and extrastat reporting , for italy, when i run MEIS for intrastat i get the following fields in the output.
Our Italian client requires the intrastat to be sorted as per vendor VAT number and commercial code
is this the legal requirement.
If yes, how do i change the display of the fields for the intrastat reporting.
how can i add new fields?
Thanks in advance for your help.pints would be rewarded immediately.
Regards,
Rajeshwari

If it is a legal requirement, that the VAT number must be in the file that you send to the government, then SAP has to take care about that in its programs if that is not already done.
Such changes can be found in OSS.
I just briefly checked the requirements and had not seen the VAT number for Intrastat puposes, maybe I just overlooked it.
You can find yourself the legal requirements in the offcial manuals:
http://www.agenziadogane.gov.it/wps/wcm/connect/ed/Servizi/Intrastat/

Intrastat - Inbound/Outbound of non valuated materials used in production.

Hello everyone,
I've found several threads and very useful posts (ex: Re: PO Creation of free goods for intrastat reporting) regarding similar issue, but the solution proposed was manual input, therefore not answering totally to my client requirement.
I am actually performing maintenance activities and there is this new business process, I have been searching for the correct understandind of this process regarding intrastat here and I haven't found.
So i will describe the process hoping that someone can give me some hint:
Vendor A
Customer B
Raw Material R
Finish Product P
Service S
1. So we ( Vendor A ) receive raw material from our Customer B (+mov.type +)
2. We ( Vendor A ) with a production order process the Raw material R into Finish Product P.
3. We ( vendor A ) send the Finish Product P back to the Customer B.
4. We ( Vendor A ) then issue an invoice for the Service S to the Customer B.
5. It can occur that we Vendor A, can send back the Raw material R which was not manufactured back to Customer B (with a mov type.)
So thiswas the scenario and how the process is beeing done, and the client understanding is:
- As far as i understood, (please correct me if i am wrong) the Raw Material R must be declared (Quantity and statistic value) in Purchasing Intrastat, in the transactions where the Vendor A receives the raw material and as well in the case that they send it back to Customer B.
- Regarding the Invoice from the Vendor A to Customer B, the Raw Material R is incorporated in the Finish Product P, therefore I've been told that, the Statistic Value determined in the invoice in this situation has to include the cost value of the raw materials R.
My issues in MM are the following:
1 - If Raw Material R is non valuated, how can i maintain its statistic value to be declared, in inbound as well outbound? as an Info-record?
My issues in SD are the following:
1 - If the Statistic Value GRWR can be for example 102% calculated over the net value, and if the cost value of Raw Materials R are to be included, so i would have to add them somehow to the statistic value.
In this case the question comes up, where do i maintain the value of the raw materials R, and how to add it to the statistic value automatically ?
Regarding what is implemented in this client, they have SD intrastat running, but not MM intrastat was implemented.
Feedback would be highly appreciated!!
Thank you in advance.

Hi Sergio,
I have this exact same requirement but on a bigger scale.
The complexities are:
1. The raw material which client use, that can be either supplied by customer or can be procured by client. Remember, customer's raw material and my externally procured raw material is exactly same in all properties.
2. There are many customers who send same exact raw material.
Requirements:
1. Client wants to use same material codes (for raw materials and even for finished products) for normal production cycle and for Job work cycle. Master data needs to be the same, and data need to be separated at transaction level.
2. Whatever raw material client gets from customer, its statistical value should be entered at the time of goods receipt.
Please suggest if preference processing can handle this.
Thanks & Regards,
Vishal

Sap oss note

Hi Experts,
Please see the following requirement and let me give the sujjestion for it,It will be very helpfull to me.Thanks in advance.
SAP Note No. 851943 04.07.2005 Page 1
 Number 851943
 Version 3 from 27.06.2005
 Status Released for Customer
 Set on 27.06.2005
 Language EN Caution: Translation Not Current!
 Master language DE
 Short text Separate country codes for Serbia, Montenegro and
 Kosovo
 Responsible SAP AG
 Component SD-FT-GOV
 Declarations to Authorities Export
 Long text
 Symptom
 As a result of EU regulation 750/2005 of May 18, 2005, the 'CS' country
 code (094) for Serbia and Montenegro in the area of foreign trade
 statistics is to be replaced with the following new country codes as of
 June 01, 2005:
 o XK (095) Kosovo
 o XM (097) Montenegro
 o XS (098) Serbia
 Other terms
 Intrastat, Extrastat, country of origin, Serbia, Montenegro, Kosovo,
 country code, ENPA, VE01, MEIS, country of departure, URSPRSLND,
 URSPRSLND, HERKL, URZLA, BESTILAND, country of destination, country of
 dispatch
 Reason and Prerequisites
 This is a legal change.
 Solution
 As the country key is checked against the country table (T005) in
 several parts of the program, it is necessary to add three new country
 codes ( XK, XM and XS) to this table even though these country codes do
 not form part of the ISO 3166 nomenclature (link:
 http://www.iso.org/iso/en/prod
 s-services/iso3166ma/02iso-3166-code-lists/index.html).
 To enter the new country codes, proceed as follows:
 Customizing --> General Settings --> Set Countries --> Define Countries
 in R/3 Systems --> New Entries
 At present, the three new country codes are only relevant for the area
 of foreign trade statistics. Therefore, a basic definition is
 sufficient.
 Specify the following information:
 o Country XK
 Alternative key: 094
 Page 2
 Name: Kosovo
 ISO code: XK
 o Country XM
 Alternative key: 097
 Name: Montenegro
 ISO code: XM
 o Country XS
 Alternative key: 098
 Name: Serbia
 ISO code: XS
 Caution
 The unfavorable effect of adding these new country codes to the country
 table is that they are available throughout the SAP system and can be
 selected for all country specifications. For example, you can now set
 the country of a customer or vendor to one of these new values, but this
 is certainly never desired.
 For this reason and because these new country codes are only required by
 a relatively small number of SAP customers, the new country codes XK, XM
 and XS are not delivered as SAP standard Customizing, but rather, each
 customer must add these to the table if they require them.
 Each customer must take the necessary steps to ensure that these country
 codes are not "misused" (as described in the above example).
 As a standard country code is no longer available for Serbia and
 Montenegro (the country codes are XK/XM/XS for foreign trade statistics
 and CS for other applications), this new requirement must be met using
 the user exits that are available. To avoid conflicts between the
 applications, we advise against changing the country code in the master
 data.
 Approaches:
 - Intrastat
 Since Serbia and Montenegro does not form part of the European
 Union, the changes to the country code only affect the
 specification of the country of origin.
 If the volume of data is low, you can change the country code
 for the country of origin from 'CS' to 'XK', 'XM' or 'XS'
 either directly in the documents (billing documents and
 purchase orders) before selecting the Intrastat data, or using
 Transaction VEFU after selecting the data.
 Page 3
 In theory, the EXIT_SAPLV50E_003 and EXIT_SAPLV50E_004 user
 exits (change foreign trade item data in the SD and MM
 documents), the EXIT_SAPLV50G_001 user exit (change the
 document data before processing in the selection program) and
 the EXIT_SAPLV50G_002 user exit (change the Intrastat data
 after processing in the selection program) are suitable for
 automatic implementation of these data changes.
 The correction instructions contain example code for a
 possible solution using the EXIT_SAPLV50G_002 user exit
 (section entitled "INTRASTAT"). This user exit is processed at
 the end of the data selection program, shortly before the
 Intrastat data is written to the VEIAV file.
 - Extrastat
 This affects the specification of the country of destination
 (export declaration), the country of dispatch (import
 declaration) and the country of origin (import declaration and
 export declaration).
 If the volume of data is low, you can change the country code
 either directly in the documents before selecting the
 Extrastat data (country of dispatch and country of origin in
 the foreign trade data for billing documents and purchase
 orders), or using Transaction VEXU after selecting the data.
 In theory, the EXIT_SAPLV50E_003 and EXIT_SAPLV50E_004 user
 exits (change foreign trade item data in the SD and MM
 documents), the EXIT_SAPLV50G_001 user exit (change the
 document data before processing in the selection program) and
 the EXIT_SAPLV50G_002 user exit (change the Extrastat data
 after processing in the selection program) are suitable for
 automatic implementation of these data changes.
 The correction instructions contain example code for a
 possible solution using the EXIT_SAPLV50G_002 user exit
 (section entitled "EXTRASTAT"). This user exit is processed at
 the end of the data selection program, shortly before the
 Extrastat data is written to the VEXAV file.
 Of course, the source code contained in the correction instructions is
 merely example source code. Insert your values in those places marked
 with arrow ( <-- ).
 Of course, other conditions may also require you to set the new country
 codes; the EXIT_SAPLV50G_002 user exit has header data and item data for
 the billing documents and purchase orders as well as their foreign trade
 data.
 Comments:
 Background:
 By default, the country of origin for both the Intrastat declaration and
 Page 4
 the Extrastat declaration are determined as follows:
 o Receipt/import
 The information for the country of origin is copied from the
 purchasing info record of the vendor (EINA-URZLA field); if the
 field is not set, the country of origin is set from the material
 master record (MARC-HERKL field).
 o Dispatch/export
 The information for the country of origin (and the region of
 origin) is copied from the material master record or the batch
 master record.
 By default, the country of destination is set in the Extrastat
 declaration for exports from the "Destination Country" field in the
 billing header (VBRK-LAND1).
 By default, the country of dispatch is set in the Extrastat declaration
 for imports from the "Country of dispatch" field for the export data of
 the billing item (EIPO-VERLD). If this is not filled, the country of the
 supplying vendor or the country of the vendor is set.
 It is therefore quite possible that the country of dispatch is not set
 in the foreign trade data for the document item (EIPO-VERLD). In this
 case, you would have to change the command line from:
 IF i_direction EQ '1' AND "import
 c_record_extrastat-versendld EQ 'CS'. "Serbia/Montenegro
 to:
 IF i_direction EQ '1' AND "import
 c_record_extrastat-versendld IS INITIAL. "initial
 After this change, only the vendor number (and other fields, if
 required) determines whether you have to set the country code.
 Releases 4.0B and 3.1I
 In these releases, the use of user exits when selecting data is
 extremely limited. We recommend that you use the user exits that are
 processed to determine the foreign trade data for billing items
 (EXIT_SAPLV50E_003) and purchase order items (EXIT_SAPLV50E_004), in
 order to already set the required country code in the documents.
 Otherwise, in these releases you can also use Transactions VEFU and VEXU
 to manually maintain Intrastat data.
 Page 5
 Valid releases
 Software Component Release
 from to
 SAP_APPL SAP Application
 500 - 500
 470 - 470
 46C - 46C
 46B - 46B
 45B - 45B
 40B - 40B
 31I - 31I
 Further components
 MM-FT-GOV
 Declarations to Authorities Import
 Reference to related Notes
 Number Short text
 603152 Country Code for "Serbia and Montenegro"
 Page 6
 Assigned Correction Instructions
 $$----
$$
 $ Correction Inst. 0120061532 0000735967 $
 $----$
 $ Valid for : $
 $ Software Component SAP_APPL SAP Application $
 $ Release 45B All Support Package Levels $
 $ Release 46B All Support Package Levels $
 $ Release 46C All Support Package Levels $
 $ Release 470 All Support Package Levels $
 $ Release 500 All Support Package Levels $
 $----$
 $ Changes/Objects Not Contained in Standard SAP System $
 $$----
$$
 *& Object REPS ZX50GU02
 *& Object Header PROG ZX50GU02
 *>>>> START OF INSERTION <<<<
INTRASTAT
 IF i_reporting_type EQ 'I'.
change COUNTRY OF ORIGIN
 IF c_record_intrastat-ursprslnd EQ 'CS'. "Serbia/Montenegro
arrival
 IF i_direction EQ '1'.
 DATA: z_lifnr LIKE ekko-lifnr.
 IF i_mm_purch_order_header-llief IS INITIAL.
 z_lifnr = i_mm_purch_order_header-lifnr.
 ELSE.
 z_lifnr = i_mm_purch_order_header-llief.
 ENDIF.
set country depending on vendor
 IF z_lifnr EQ 'XS4711'. "<-- vendor
 c_record_intrastat-ursprslnd = 'XS'. "<-- new country code
 ENDIF.
 IF z_lifnr EQ 'XK4712'. "<-- vendor
 c_record_intrastat-ursprslnd = 'XK'. "<-- new country code
 ENDIF.
set country depending on vendor and material
 IF z_lifnr EQ 'CS4713'. "<-- vendor
 IF i_mm_purch_order_line_item-matnr EQ 'mat55'. "<-- mat.no.
 c_record_intrastat-ursprslnd = 'XM'. "<-- new country code
 ENDIF.
 IF i_mm_purch_order_line_item-matnr EQ 'mat71'. "<-- mat.no.
 c_record_intrastat-ursprslnd = 'XS'. "<-- new country code
 Page 7
 ENDIF.
 ENDIF.
dispatch
 ELSEIF i_direction EQ '2'.
set country depending on material and plant
 IF ( i_sd_invoice_line_item-matnr EQ 'mat_from_serbia' "<-- mat.no.
 AND i_sd_invoice_line_item-werks EQ 'CS01' ). "<-- plant
 c_record_intrastat-ursprslnd = 'XS'. "<-- new country code
 ENDIF.
 IF ( i_sd_invoice_line_item-matnr EQ 'mat_from_kosovo' "<-- mat.no.
 AND i_sd_invoice_line_item-werks EQ 'CS12' ). "<-- plant
 c_record_intrastat-ursprslnd = 'XK'. "<-- new country code
 ENDIF.
 IF ( i_sd_invoice_line_item-matnr EQ 'mat_from_montenegro' "<-- mat.
 AND i_sd_invoice_line_item-werks EQ 'CS99' ). "<-- plant
 c_record_intrastat-ursprslnd = 'XM'. "<-- new country code
 ENDIF.
 ENDIF.
 ENDIF.
 ENDIF.
EXTRASTAT
 IF i_reporting_type EQ 'E'.
change COUNTRY OF ORIGIN
 IF c_record_extrastat-ursprslnd EQ 'CS'. "Serbia/Montenegro
 *... see INTRASTAT !
 *... !!! just replace 'c_record_intrastat-ursprslnd' by
 *... 'c_record_extrastat-ursprslnd' !!!
 ENDIF.
change COUNTRY OF DISPATCH
 IF i_direction EQ '1' AND "import
 c_record_extrastat-versendld EQ 'CS'. "Serbia/Montenegro
 DATA: zz_lifnr LIKE ekko-lifnr.
 IF i_mm_purch_order_header-llief IS INITIAL.
 zz_lifnr = i_mm_purch_order_header-lifnr.
 ELSE.
 zz_lifnr = i_mm_purch_order_header-llief.
 ENDIF.
set country depending on vendor
 Page 8
 IF zz_lifnr EQ 'XS4711'. "<-- vendor
 c_record_extrastat-versendld = 'XS'. "<-- new country code
 ENDIF.
 IF zz_lifnr EQ 'XK4712'. "<-- vendor
 c_record_extrastat-versendld = 'XK'. "<-- new country code
 ENDIF.
 ENDIF.
change COUNTRY OF DESTINATION
 IF i_direction EQ '2' AND "export
 c_record_extrastat-bestiland EQ 'CS'. "Serbia/Montenegro
set country depending on sold-to-party
 IF i_sd_invoice_header-kunag EQ 'monte01'. "<-- sold-to-party
 c_record_extrastat-bestiland = 'XM'. "<-- new country code
 ENDIF.
set country depending on payer
 IF i_sd_invoice_header-kunrg EQ 'Kos05'. "<-- payer
 c_record_extrastat-bestiland = 'XK'. "<-- new country code
 ENDIF.
set country depending on material
 IF i_sd_invoice_line_item-matnr EQ 'mat_to_serbia'. "<-- mat.no.
 c_record_extrastat-bestiland = 'XS'. "<-- new country code
 ENDIF.
 ENDIF.
 ENDIF.
 *>>>> END OF INSERTION <<<<<<

Hi
Which your problem?
It seems the std code has to be changed because the sign of some countries are changed.
So you have to insert/delete the new code as the note explains:
- Insert the code between *>>>> START OF INSERTION <<<<
and *>>>> END OF INSERTION <<<<
- Delete the code between *>>>> START OF DELETION <<<<
and *>>>> END OF DELETION <<<<
So you should implement the user-exit indicate in the note.
Max

Scenario for EDI

hi can anybody tell me how the concept of EDI works?
1)do configurations like setting logical system, partner profiles etc have to be made?
2)is there standard idocs like MATMAS or CREMAS that are sent via EDI?
3)is there a step-by-step procedure for EDI

hi anjali,
IDocs are basically a small number of records in ASCII format, building a logical
entity. It makes sense to see an IDoc as a plain and simple ASCII text file, even if it
might be transported via other means.
Any IDoc consists of two sections:
the control record
which is always the first line of the file and provides the administrative information.
the data record which contains the application dependent data, as in our example below the material master data.
We will discuss the exchange of the material master IDoc MATMAS in the
paragraphs that follow..
The definition of the IDoc structure MATMAS01 is deposited in the data dictionary
and can be viewed with WE30.
The very first record of an IDoc package is always a control record. The structure of this control record is the DDic structure EDIDC and describes the contents of the data contained in the package.
The control record carries all the administrative information of the IDoc, such as its origin, its destination and a categorical description of the contents and context of the attached IDoc data. This is very much like the envelope or cover sheet that
would accompany any paper document sent via postal mail.
For R/3 inbound processing, the control record is used by the standard IDoc
processing mechanism to determine the method for processing the IDoc. This
method is usually a function module but may be a business object as well. The
processing method can be fully customised.
Once the IDoc data is handed over to a processing function module, you will no
longer need the control record information. The function modules are aware of the
individual structure of the IDoc type and the meaning of the data. In other words:
for every context and syntax of an IDoc, you would write an individual function module or business object (note: a business object is also a function module in R/3) to deal with.
The control record has a fixed pre-defined structure, which is defined in the data
dictionary as EDIDC and can be viewed with SE11 in the R/3 data dictionary. The
header of our example will tell us, that the IDoc has been received from a sender
with the name PROCLNT100 and sent to the system with the name DEVCLNT100 .
It further tells us that the IDoc is to be interpreted according to the IDoc definition called MATMAS01 .
All records in the IDocs, which come after the control record are the IDoc data. They are all structured alike, with a segment information part and a data part which is 1000 characters in length, filling the rest of the line.
All records of an IDoc are structured the same way, regardless of their actual
content. They are records with a fixed length segment info part to the left, which is
followed by the segment data, which is always 1000 characters long.
You can view the definition of any IDoc data structure directly within R/3 with transaction WE30.
Regardless of the used IDoc type, all IDocs are stored in the same database tables
EDID4 for release 4.x and EDID3 for release 2.x and 3.x. Both release formats are
slightly different with respect to the lengths of some fields.
Depending on the R/3 release, the IDoc data records are formatted either according
the DDic structure EDID3 or EDID3. The difference between the two structures
reflects mainly the changes in the R/3 repository, which allow longer names starting
from release 4.x.
All IDoc data record have a segment info part and 1000 characters for data IDoc type definition can be edited with WE30 Data and segment info are stored in EDID4 .
All IDoc data records are exchanged in a fixed format, regardless of the segment type. The
segments true structure is stored in R/3s repository as a DDic structure of the same name.
The segment info tells the IDoc processor how the current segment data is structured
and should be interpreted. The information, which is usually the only interest, is the name of the segment EDID4-SEGNAM.
The segment name corresponds to a data dictionary structure with the same name,
which has been created automatically when defining the IDoc segment definition
with transaction WE31 .
For most applications, the remaining information in the segment info can be ignored
as being redundant. Some older, non-SAP-compliant partners may require it. E.g.
the IDoc segment info will also store the unique segment number for systems, which
require numeric segment identification.
To have the segment made up for processing in an ABAP, it is usually wise to move
the segment data into a structure, which matches the segment definition.
When R/3 processes an IDoc via the standard inbound or outbound mechanism, the IDoc is stored in the tables. The control record goes to table EDIDC and the data goes to table EDID4.
All IDoc, whether sent or received are stored in the table EDID4. The corresponding
control file header goes into EDIDC.
There are standard programs that read and write the data to and from the IDoc base.
These programs and transaction are heavily dependent on the customising, where
rules are defined which tell how the IDocs are to be processed.
Of course, as IDocs are nothing more than structured ASCII data, you could always
process them directly with an ABAP. This is certainly the quick and dirty solution,
bypassing all the internal checks and processing mechanisms. We will not reinvent
the wheel here.
To do this customising setting, check with transaction WEDI and see the points,
dealing with ports, partner profiles, and all under IDoc development.
All inbound and outbound Documents are stored in EDID4 Avoid reinventing the
wheel Customising is done from the central menu WEDI and see the points,
dealing with ports, partner profiles, and all under IDoc development
The declaration of valid combinations is done to allow validation, if the system can
handle a certain combination.
The combination of message type and IDoc type determine the processing algorithm. This is
usually a function module with a well defined interface or a SAP business object and is set up
in table EDIFCT.
The entry made here points to a function module which will be called when the IDoc
is to be processed.
The entries for message code and message function are usually left blank. They can
be used to derive sub types of messages together with the partner profile used.
Figure 25: Assign a handler function to a message/message type
The definition for inbound and outbound IDocs is analogous. Of course, the function
module will be different.
R/3 uses the method of logical process codes to detach the IDoc processing and the
processing function module. They assign a logical name to the function instead of specifying the physical function name.
The IDoc functions are often used for a series of message type/IDoc type
combination. It is necessary to replace the processing function by a different one.
E.g. when you make a copy of a standard function to avoid modifying the standard.
The combination message type/IDoc will determine the logical processing code,
which itself points to a function. If the function changes, only the definition of the processing codes will be changed and the new function will be immediately
effective for all IDocs associated with the process code.
For inbound processing codes you have to specify the method to use for the
determination of the inbound function.
This is the option you would usually choose. It allows processing via the ALE
scenarios.
After defining the processing code you have to assign it to one or several logical
message types. This declaration is used to validate, if a message can be handled by
the receiving system.
The inbound processing code is assigned analogously. The processing code is a pointer to a function module which can handle the inbound request for the specified IDoc and message type.
The definition of the processing code is identifying the handler routine and assigning a serious of processing options.
You need to click "Processing with ALE", if your function can be used via the ALE
engine. This is the option you would usually choose. It allows processing via the
ALE scenarios.
Associate a function module with a process code
For inbound processing you need to indicate whether the function will be capable of
dialog processing. This is meant for those functions which process the inbound data
via call transaction. Those functions can be replayed in visible batch input mode to
check why the processing might have failed.
There are several common expressions and methods that you need to know, when dealing
with IDoc.
The message type defines the semantic context of an IDoc. The message type tells
the processing routines, how the message has to be interpreted.
The same IDoc data can be sent with different message types. E.g. The same IDoc
structure which is used for a purchase order can also be used for transmitting a sales order. Imagine the situation that you receive a sales order from your clients and in addition you receive copies of sales orders sent by an subsidiary of your company.
An IDoc type defines the syntax of the IDoc data. It tells which segments are found
in an Idoc and what fields the segments are made of.
The processing code is a logical name that determines the processing routine. This
points usually to a function module, but the processing routine can also be a
workflow or an event.
The use of a logical processing code makes it easy to modify the processing routine
for a series of partner profiles at once.
Every sender-receiver relationship needs a profile defined. This one determines
the processing code
the processing times and conditions
and in the case of outbound IDocs
the media port used to send the IDoc and
the triggers used to send the IDoc
The IDoc partners are classified in logical groups. Up to release 4.5 there were the
following standard partner types defined: LS, KU, LI.
The logical system is meant to be a different computer and was primarily introduced
for use with the ALE functionality. You would use a partner type of LS, when
linking with a different computer system, e.g. a legacy or subsystem.
The partner type customer is used in classical EDI transmission to designate a
partner, that requires a service from your company or is in the role of a debtor with
respect to your company, e.g. the payer, sold-to-party, ship-to-party.
The partner type supplier is used in classical EDI transmission to designate a
partner, that delivers a service to your company. This is typically the supplier in a
purchase order. In SD orders you also find LI type partners, e.g. the shipping agent.
Message Type How to Know What the Data Means
Data exchanged by an IDoc via EDI is known as message. Messages of the same kind belong to the same message type.
The message type defines the semantic context of an IDoc. The message type tells
the receiverhow the message has to be interpreted.
The term message is commonly used in communication, be it EDI or
telecommunication. Any stream of data sent to a receiver with well-defined
information in itis known as a message. EDIFACT, ANSI/X.12, XML and others
use message the same way.
Unfortunately, the term message is used in many contexts other than EDI as well.
Even R/3 uses the word message for the internal communication between
applications. While this is totally OK from the abstract point of view of data
modelling, it may sometimes cause confusion if it is unclear whether we are
referring to IDoc messages or internal messages.
The specification of the message type along with the sent IDoc package is especially
important when the physical IDoc type (the data structure of the IDoc file) is used
for different purposes.
A classical ambiguity arises in communication with customs via EDI. They usually
set up a universal file format for an arbitrary kind of declaration, e.g. Intrastat,
Extrastat, Export declarations, monthly reports etc. Depending on the message type,
only applicable fields are filled with valid data. The message type tells the receiver which fields are of interest at all.
Partner Profiles How to Know the Format of the Partner
Different partners may speak different languages. While the information remains the same, different receivers may require completely different file formats and communication protocols.
This information is stored in a partner profile.
In a partner profile you will specify the names of the partners which are allowed to
exchange IDocs to your system. For each partner you have to list the message types
that the partner may send.
For any such message type, the profile tells the IDoc type, which the partner expects
for that kind of message.
For outbound processing, the partner profile also sets the media to transport the data to its receiver, e.g.
an operating system file
automated FTP
XML or EDIFACT transmission via a broker/converter
internet
direct remote function call
The means of transport depends on the receiving partner, the IDoc type and message
type (context).
Therefore, you may choose to send the same data as a file to your vendor and via
FTP to your remote plant.
Also you may decide to exchange purchase data with a vendor via FTP but send
payment notes to the same vendor in a file.
For inbound processing, the partner profile customizsng will also determine a
processing code, which can handle the received data.
IDoc Type The Structure of the IDoc File
The IDoc type is the name of the data structure used to describe the file format of a specific IDoc.
An IDoc is a segmented data file. It has typically several segments. The segments
are usually structured into fields; however, different segments use different fields.
The Idoc type is defined with transaction WE30, the respective segments are defined
with transaction WE31.
Processing Codes
The processing code is a pointer to an algorithm to process an IDoc. It is used to allow more flexibility in assigning the processing function to an IDoc message.
The processing code is a logical name for the algorithm used to process the IDoc.
The processing code points itself to a method or function, which is capable of
processing the IDoc data.
A processing code can point to an SAP predefined or a self-written business object
or function module as long as they comply with certain interface standards.
The processing codes allow you to easily change the processing algorithm. Because
the process code can be used for more than one partner profile, the algorithm can be
easily changed for every concerned IDoc.
The IDoc engine will call a function module or a business object which is expected
to perform the application processing for the received IDoc data. The function
module must provide exactly the interface parameters which are needed to call it
from the IDoc engine.
In addition to the writing of the processing function modules, IDoc development requires the
definition of the segment structures and a series of customising settings to control the flow of the IDoc engine.
In Summary
Customise basic installation parameters
Define segment structures
Define message types, processing codes
Segments define the structure of the records in an IDoc. They are defined with transaction WE31.
Check first, whether the client you are working with already has a logical system
name assigned.
The logical system name is stored in table T000 as T000-LOGSYS. This is the table
of installed clients.
If there is no name defined, you need to create a logical system name . This means
simply adding a line to table TBDLS. You can edit the table directly or access the
table from transaction SALE.
The recommended naming convention is
sysid + "CLNT" + client
If your system is DEV and client is 100, then the logical system name should be:
DEVCLNT100.
System PRO with client 123 would be PROCLNT123 etc.
The logical system also needs to be defined as a target within the R/3 network.
Those definitions are done with transaction SM59 and are usually part of the work
of the R/3 basis team
see this link for all info on idocs
http://abapprogramming.blogspot.com/2007/11/abap-idocs-basic-tools.html
thanks
karthik
reward me points if usefull

NEED DEFINITIONS

HI
I need Interview point of definitions for Cross Application Concepts...so, can any of you plz give me a brief explination about
1 .PROCESS CODE
2. MESSAGE TYPE
3. OUTPUT TYPES
4. customer distribution model.
what is these are.. and what is the purpose of these..
Thanks
babu

Hi Babu,
Processing Code
The processing code is a logical name that determines the processing routine. This points usually to a function module, but the processing routine can also be a
workflow or an event. The use of a logical processing code makes it easy to modify the processing routine for a series of partner profiles at once.
The logical processing code determines the algorithm in R/3 used to process the IDoc
The processing code is a pointer to an algorithm to process an IDoc. It is used to allow more
flexibility in assigning the processing function to an IDoc message.
The processing code is a logical name for the algorithm used to process the IDoc.
The processing code points itself to a method or function, which is capable of
processing the IDoc data.
A processing code can point to an SAP predefined or a self-written business object or function module as long as they comply with certain interface standards.
Allows changing the algorithm easily
The processing codes allow you to easily change the processing algorithm. Because the process code can be used for more than one partner profile, the algorithm can be easily changed for every concerned IDoc.
The processing code defines a method or function to process an IDoc
The IDoc engine will call a function module or a business object which is expected
to perform the application processing for the received IDoc data. The function
module must provide exactly the interface parameters which are needed to call it
from the IDoc engine.
Message Type
The message type defines the semantic context of an IDoc. The message type tells the processing routines, how the message has to be interpreted.
The same IDoc data can be sent with different message types. E.g. The same IDoc structure which is used for a purchase order can also be used for transmitting a sales order. Imagine the situation that you receive a sales order from your clients and in addition you receive copies of sales orders sent by an subsidiary of your company.
The message type defines the semantic context of an IDoc. The message type tells the receiverhow the message has to be interpreted.
The term message is commonly used in communication, be it EDI or
telecommunication. Any stream of data sent to a receiver with well-defined
information in itis known as a message. EDIFACT, ANSI/X.12, XML and others
use message the same way.
Unfortunately, the term message is used in many contexts other than EDI as well.
Even R/3 uses the word message for the internal communication between
applications. While this is totally OK from the abstract point of view of data
modelling, it may sometimes cause confusion if it is unclear whether we are
referring to IDoc messages or internal messages.
The specification of the message type along with the sent IDoc package is especially important when the physical IDoc type (the data structure of the IDoc file) is used for different purposes.
A classical ambiguity arises in communication with customs via EDI. They usually
set up a universal file format for an arbitrary kind of declaration, e.g. Intrastat,
Extrastat, Export declarations, monthly reports etc. Depending on the message type, only applicable fields are filled with valid data. The message type tells the receiver which fields are of interest at all.

Output of Intrastat and extrastat

Hello Experts,
For intrastat and extrastat reporting , for italy, when i run MEIS for intrastat i get the following fields in the output.
Our Italian client requires the intrastat to be sorted as per vendor VAT number and commercial code
is this the legal requirement.
If yes, how do i change the display of the fields for the intrastat reporting.
how can i add new fields?
Thanks in advance for your help.pints would be rewarded immediately.
Regards,
Rajeshwari

INTRASTAT and EXTRASTAT are European Union Trade reports.
Cusotmizing is to be done in the foreign trade path of SD and MM.
Depending on the reporting country the requirements are slightly different.
For customizing start reading here: http://help.sap.com/saphelp_46c/helpdata/en/66/72369adc56d11195100060b03c6b76/frameset.htm

Implementation for Germany -- ATLAS, INTRASTAT, COBRA.

Can somebody help to understand how this can be done in GTS. I have following questions?
1. Process.
Do we need to activate transit procedure?
What kind of Feedersystem documetns can be mapped to this transit procedure. For ex we have activated customs process and mapped all billing documents. in ase of exports we will create proforma and will get transffered to GTS. In case of transit procedure what is the source.
2. What is the check list for ATLAS implementation. Like for example may be we need seeburger and what else. How we will connect to the DE customs authorites.
3. for Intrasta and extrasta reportin, do we have any services or transactions in GTS like we have in foreign trade module in ECC. What is the data required to activate this reporting service. I read one tread but that service in area menu in ECC is not available. They suggested to install gts7.2 plugin. but it is huge effeort. is there any shortcut.
4. How do we find of which AES version that we implemented.
Basically what I am looking for is just high level steps.
Any help would be appreciated. I am really thankful to them.
Edited by: thirumal gunukula on Dec 10, 2008 9:55 PM

Fields for Intrastat in SRM 7.0 Purchase order

Hi experts,
we use SRM 7.0 extended scenario and the requirement is to enter data for Intrastat in the SRM PO fields and transfer this to ERP PO to exedute the Intrastat report in ERP.
What I have to do in detail to see the fields on the screen like ERP PO if we order goods/services from a EU supplier ?
Kind Regards

Check this Custom solution for implementing Intrastat in SRM (Extended Classic Scenario). I have implemented this in one of my clients and it works without any issues.
Import-Export (Intrastat) data in SRM - Supplier Relationship Management - SCN Wiki
http://wiki.scn.sap.com/wiki/download/attachments/250383577/Custom%20Solution%20for%20INTRASTAT_ERP604_v2.pdf?version=1&…
Hope this helps.
Regards
Venkat

Foreign Trade / Intrastat - data order-related billing (downpayments)

Hi,
Shortly we have implemented the down payment functionality in our flows. Because downpayments require order-related billing the intrastat/foreign trade data is not copied into the closing invoice.
Apparently it is only possible to copy the data from a delivery.
We are in a make-to-order environment and we still create deliveries but because of the down payments, the invoice is created from the sales order and hence no intrastat data is copied which ofcourse is required ...
Can't find a suitable user exit for filling this data into the billing document. Also tried using copy data transfer (vofm) filling up tables eikp and eipo but that didn't work.
The only option open for me at the moment is creating a proforma invoice automatically from the delivery. This document can then be included in the intrastat reporting.
Is there another solution ?
with regards

Hi,
in the copy control between order and invoice you need to set the 'determine export data' to 'B' so that it will be redetermined in the invoice. After that the relevant foreign trade userexits will work as well.
Balazs

Intrastat / EC sales reporting for Italy

Hi all. We have implemented a new company code for italy. Business is now requiring several country specific reporting, namely the intrastat and EC sales reporting. I tried going through some documentation but there are several reports available for intrastat, so i am not getting the whole picture or which report(s) i should be using. Does anyone know the sap note which describes the full intrastat reports or have any similar documentation?
thanks in advance for your help.

Hello Simon,
The below documents might be helpful to you,
http://www.scmexpertonline.com/downloads/Kees%20Intrastat%20download%201-23-07.doc
http://www.appliconsolutions.com/fileadmin/filer_solutions/pdf/White_paper/White_Paper_APM__v._2.9.pdf
http://mbs.microsoft.com/downloads/public/GP10Docs/EnhancedIntrastat.pdf
This is the last one for oracle,
http://download.oracle.com/docs/cd/A60725_05/pdf/gemmsin.pdf
br,
Pushkar

Intrastat Reporting error

Hello All,
I have configured intrastate reporting in the GTS system
While trying to transfer import relevant documents, system is not able to find any document and gives error
while if I try to transfer Dispatch documents, I am getting error " Atleast one information provider's VAT registration number was not transferred" Although the details are maintained in GTS
Please help me to resolve these issues
Thanks & Regards
Rahul

Hi Rahul
I presume you are running transaction /SAPSLL/IS_MM and the error encountered is:
"No provider of information found for at least one VAT registration number
Message no. /SAPSLL/PLUGINR3604 "
If so, Could you check if note 2054390 is implemented in your GTS systems. There was a issue a reported a few months ago and the note was created to fix an issue with the code.
The system checks for an entry in table /ECRS/POIA for Vat No. (POIVA) being passed from the feeder system. If no entry is found then the above error is correctly issued.
Kind Regards
Ann Marie

SAPSCRIPT for Intrastat.

Hi all experts!
I have a question concerning sapscript and Intrastat.
First some background information:
Country's inside EU have to inform to the locally central Statistic bureau. This information can be printed out from SAP. For my case we have to send the information to the Statistics Sweden.
In the SAP system, I am working with, the printout is coming with only the values and text. This mean that the form with the fields and logo have to be put in the printer, by our self. And hope that the value and text come in the right fields. Like you se a quit bad solution.
My question's are:
Is it a standard program/sapscript in SAP, that can be used?
Or is it a Bapi or Badi that can be implemented and will do the work?
Or do we have to make the hole form by our self, in Sapscript?
First one with the right answer will be given lots of point
Thanks a lot for helping me out.

Hi Ali,
it depends , which module is it related to. if there are no standard script that meets your requirement then , you need to Start create a NEw script or Smart form to do the job.
Regards
vijay

Intrastat Exports/Imports

Folks,
As Intrastat declarations are done for EU countries wherein statistics of exports/imports are declared to local authorities.Currently I want to know if any one has implemented the SAP provided standard functionality in ECC5.0.to use standard reports for intrastat declarations.
Additionally I have couple of questions relating to this:
1-Is "Plants abroad customizing" a prerequisite for implementing SAP standard Intrastat reports.
2-Is there any way to add our own customs fields as a parameter to run th SAP standard report.eg:company's own fiscal year.
3-Incase of imports-How can we print few more fields in the output of the SAP standard report(eg.Invoice no(RE)), which does not print in SAP standard report nor has a option in layout settings.(This RE number would help the users for doing VAT reconciliation with Intrastat).
4-Lastly,is there any SAP standard tool or report present in ECC5.0 which can perform VAT vs Intrastat reconciliation.
Friends,not necessary that one needs to answer all questions, but any or all questions answered quickly and correctly shall be rewarded.
Thanks
Gary

Please check this link
http://www.google.com/url?sa=t&source=web&ct=res&cd=3&ved=0CA4QFjAC&url=http%3A%2F%2Fwww.scmexpertonline.com%2Fdownloads%2FKees%2520Intrastat%2520download%25201-23-07.doc&rct=j&q=SAPintrastatfor+EU&ei=Ncm8S-rUMMT38AaA4IHcBg&usg=AFQjCNFWXtBMAjyjJK9ZmxKuIj_3KEABaw
Regard
Sai

Intrastat/Extrastat Implementation

Similar Messages

Maybe you are looking for