This portion of EDI basic components configuration is in continuation with previous post.

1· IDoc sys. environment:These parameters should always be checked.

2.General IDoc Interface, Max. Number of Syntax Errors: This parameter sets the maximum limit on the number of status records created for syntax errorsa good recommendation is five. If your IDoc gets more than five syntax errors in a production environment, something is terribly wrong. Setting this number higher usually does not help you debug the problem; at that point, you need to investigate the process more deeply at the source of data.

3· IDoc inbound from file, Synchronous Processing: The standard IDoc processing method is asynchronous, which usually provides higher throughput and allows decoupled parallel processing of individual IDocs. At times, such as when IDocs must be processed in sequence to prevent record−locking problems, synchronous processing can offer a possible solution.

Be careful with the Synchronous Processing parameter. It affects all inbound IDocs and can profoundly slow the throughput of IDoc processing.

4.Test tab, Parameter Setting, TestPort: You use this setting for testing purposes only. It defines the port name that will be used for assigning default parameters during inbound testing. The naming convention used for this port is SAP, where is a three−character ID assigned to your SAP instance. For example, if the System ID (SID) of your development instance is DV1, the port name will be SAPDV1. This port must be defined in the port definition.

5·The instance ID is the three−character name in the status bar that appears at the bottom portion of any SAP screen. However, if the status bar is turned off, you can also determine the instance ID by executing transaction SM51. The three characters following the first underscore under the server name are the instance ID .

Coupling IDoc Creation to IDoc Processing

Path: EDI settings in the IMG, Activate event receiver linkage for IDoc inbound

The process of creating IDocs from the input file was disconnected from the processing of the IDocs for posting for two reasons.

1· To improve the efficiency of the process of creating IDocs from a file.
2.To separate logically the process of posting an IDoc from the process of creating an IDoc, because they are two independent processes.

Anyway , the two processes have to be coupled for EDI process flow. The workflow concept of publish and subscribe, shown in Figure , accomplishes the coupling. The link is maintained via an event−linkage table.

When an IDoc is created, it raises an event, which is the publishing piece, to inform the system about the creation. The subscriber is the process that processes the IDoc. The subscriber starts automatically when the corresponding event is published. To establish the linkage, you execute the customizing step (Activate Event Receiver Linkage) in the EDI settings of the IMG or run program RSEINBEV.

For inbound IDoc processing, the event triggered is PROCESSSTATEREACHED, and the subscriber is the workflow standard task TS30200090.

Related Posts

EDI basic components configuration part one
EDI sub system part one and Two
EDI inbound process overview
EDI subsystem architecture and mapping

ABAP TOPIC WISE COMPLETE COURSE

BDC OOPS ABAP ALE IDOC'S BADI BAPI Syntax Check
Interview Questions ALV Reports with sample code ABAP complete course
ABAP Dictionary SAP Scripts Script Controls Smart Forms
Work Flow Work Flow MM Work Flow SD Communication Interface
SAP Financial Part Two

SAP Financial Customer Vendor Accounts
EnjoySAP Financial Invoice Entry
SAP Financial Automatic Payments
SAP Financial General Ledger Accounts
SAP Financial Customer and Vendor Accounts
SAP Financial Open Item Clearing
SAP Financial Correspondence
SAP Financial Receivables
SAP Financial General Ledger Special Transactions
SAP Financial Credit Risk Management
SAP Financial Reporting Tools
SAP Financial Closing Process

Thank you for visiting SAP ABAP.If you liked the post, please subscribe to RSS FEED or get the updates directly into your mail box through EMAIL SUBSCRIPTION.

You must set up the various components before you can get an IDoc out of or into the system. Two types of components build and support the SAP EDI process.

1.Components specifically designed for the ALE/EDI process (for example, the port definition, partner profiles, and process codes)·

2.Flexible cross−application technologies that are deployed in the EDI process and can be adapted
across multiple applications (for example, Message control and workflow).

The Configuration Settings

The various configuration settings for the EDI process are done in the IMG and in the area menu of the EDI system.

Implementation Guide: The various EDI customization settings (see Figure 6.1) are available under the following path in the IMG: Basis Components, Basis Services, IDoc Interface/Electronic Data Interchange.


Number Ranges for IDocs :

Transaction: OYSN

Path: EDI settings in the IMG, Create number ranges Every IDoc created in the system, inbound or outbound, is assigned a 16−digit number that uniquely identifies it in the system. The IDoc number range is already defined. You normally do not have to maintain this number range, but theoretically you could exhaust the number range and then have to reset it.

Be careful when resetting the number range. Make sure that old IDocs with the number range to
which you are resetting have been archived and deleted from the system. Otherwise, the system will not be able to create IDocs in the number range that has been initialized.

Global IDoc Interface Parameters

Transaction: WE46

Path: From the Area menu of EDI, choose Control, Partner profile, IDoc administration In transaction WE46, you assign values to the global variables used in the EDI process.

The settings you need to make for the global IDoc interface parameters are explained in the following list.

IDoc Administrator : This parameter group specifies the administrator for the IDoc interface at run time. The IDoc Administrator group consists of two parameters, named Recipient Type and Identification, which identify the individual(s) who will be responsible for the integrity of the overall IDoc interface.

You must enter the recipient type (for example, US for user ID, S for position, or O for organizational unit), along with the identification value.

For example, if the position with position number 12345678 is assigned as the administrator, the value of the parameter in the Recipient Type field will be S, and the value for the Identification field will be 12345678. If a user with user ID AN000001 is the administrator, the value of the parameter in the Recipient Type field will be US, and the Identification field will be AN000001. This parameter is used by the workflow system in either of the following situations.

1.A technical error occurs in the EDI interface layer, for example, an error in deleting an IDoc file after successfully creating an IDoc.

2. An application error occurs in processing an IDoc. In this case, workflow first attempts to send a notification to the ID specified in the partner profile. If the error is such that the partner profile cannot be read, notification is sent to the IDoc administrator.

Normally, these situations should not occur because the IDoc administrator has overall responsibility for the interface and cannot handle application−specific errors.

It's better to avoid a user ID as the IDoc Administrator. You should use more abstract object types, such as position, job, or organizational unit. This approach saves you the headache of changing the entry when the user leaves the company or changes jobs. Compared to users, organizational objects such as positions, jobs, and organizational units tend to be more stable.(59.1)

Related Posts

EDI sub system part one and Two
EDI inbound process overview
EDI subsystem architecture and mapping

ABAP TOPIC WISE COMPLETE COURSE

BDC OOPS ABAP ALE IDOC'S BADI BAPI Syntax Check
Interview Questions ALV Reports with sample code ABAP complete course
ABAP Dictionary SAP Scripts Script Controls Smart Forms
Work Flow Work Flow MM Work Flow SD Communication Interface

SAP Financial Part Two

SAP Financial Customer Vendor Accounts
EnjoySAP Financial Invoice Entry
SAP Financial Automatic Payments
SAP Financial General Ledger Accounts
SAP Financial Customer and Vendor Accounts
SAP Financial Open Item Clearing
SAP Financial Correspondence
SAP Financial Receivables
SAP Financial General Ledger Special Transactions
SAP Financial Credit Risk Management
SAP Financial Reporting Tools
SAP Financial Closing Process

Thank you for visiting SAP ABAP.If you liked the post, please subscribe to RSS FEED or get the updates directly into your mail box through EMAIL SUBSCRIPTION.

The Definition Component

The definition component is where mapping definitions between EDI and IDoc formats are created. This component can run without any connection to the SAP system or its server module. The maps are platform independent. The definition component carries out the following functions.

1. Defines the source structure and destination structure.
2. Maps fields in the source structure to fields in the destination structure.
3. Compiles maps for other platforms.
4. Tests maps.
5. Provides utilities to download and upload IDoc structures, document structures, and maps.

The structure of standard EDI documents for commonly−used standards (ANSI X12 and EDIFACT) is shipped with most EDI subsystems.

The Execution Component
Maps created in the definition component step are executed on the server, which is known as the execution component. The execution component is where the complete environment for executing the maps, trading partner relationships, and other server−related functions are performed. The list of common tasks performed on the server and features commonly found in EDI subsystems is given below.

1. Execution of maps
2. Maintenance of trading partner agreements
3. Configuration of the environment
4. Maintenance of log information
5. Archiving
6. Tools for monitoring the process
7. Tools for restart and recovery of failed transactions
8. Scripts for connectivity with VAN

Mapping Concepts for IDocs and EDI Document Formats

A map is created for every message exchanged with a business partner. Mapping an IDoc to an EDI format requires the following steps.

1.Download the SAP IDoc structure :The IDoc structure is downloaded into the definition component. SAP provides a program named RSEIDOC3 that generates a structured report of the IDoc structure. The report is downloaded to a file and can then be copied to the PC on which the definition component is installed.

2.Define the IDoc structure: The output file can be imported into the definition component to make the IDoc format known to the system. To create the IDoc structure, the software vendors provide a utility program to import the file automatically. The IDoc structure has a control record structure and several data record structures.

3.Define the EDI document structure: Software vendors usually provide the structure of the standard EDI documents.

4.Define the maps:Mapping is the process of linking source fields to destination fields. In complex mapping, values from several fields of the source structure are manipulated in different ways to generate an output value for a field in the destination structure. The systems usually allow manipulation using functions, external program calls, and so on. You must check with your software vendor about the sophistication of the mapping process.

5.Compile the maps: Maps need to be compiled before they can be executed. The compilation process is simple. The system checks the syntax of the map, the consistency of business rules used in the map, and the source and destination data elements in the map. If compilation is successful, the map is ready to be executed.

6.Test the compiled maps: The maps can be tested on the definition system using some test data. An input file is processed through a map to generate the output. The output should be verified manually the data should be in the correct location and in the correct format.

7.Transport the maps: The definition component can usually compile maps for use on other platforms. Thus, if the execution engine resides on UNIX and the definition component is on a PC, the system can generate a compile map for the UNIX system. The compiled map can then be transported to the EDI server system via any file transfer techniques.

8.Execute the maps: The maps can then be executed on the server. During production, the system executes maps on the server.(53.2)

Related Posts

EDI sub system part one and Two
EDI inbound process overview
EDI inbound process via work flow
EDI outbound process part one and two

ABAP TOPIC WISE COMPLETE COURSE

BDC OOPS ABAP ALE IDOC'S BADI BAPI Syntax Check
Interview Questions ALV Reports with sample code ABAP complete course
ABAP Dictionary SAP Scripts Script Controls Smart Forms
Work Flow Work Flow MM Work Flow SD Communication Interface
SAP Financial Part Two

SAP Financial Customer Vendor Accounts
EnjoySAP Financial Invoice Entry
SAP Financial Automatic Payments
SAP Financial General Ledger Accounts
SAP Financial Customer and Vendor Accounts
SAP Financial Open Item Clearing
SAP Financial Correspondence
SAP Financial Receivables
SAP Financial General Ledger Special Transactions
SAP Financial Credit Risk Management
SAP Financial Reporting Tools
SAP Financial Closing Process


Thank you for visiting SAP ABAP.If you liked the post, please subscribe to RSS FEED or get the updates directly into your mail box through EMAIL SUBSCRIPTION.

This part of EDI sub system is in continuation with the previous post about EDI subsystem.

Handling Functional and Interchange Acknowledgments

An interchange acknowledgment is the message that the VAN sends to the subsystem to inform it about the transmission results. A functional acknowledgment (ANSI X12 transaction 997) acknowledges the receipt of data by the receiving system. This transaction verifies the successful receipt of an EDI document but does not guarantee successful data processing. The subsystems are responsible for generating this document on receipt of an EDI transmission.

For an outbound process, the status codes that the subsystem reports to SAP depend on the results of the acknowledgment. Status codes 14, 15, 16, 17, and 22 are returned to SAP.

Performing a Syntax Check

The EDI standards have a rigid structure. The segments and fields have the following characteristics.

1. Optional or mandatory
2. Conditional or non−conditional
3. Data format
4. Data length
5. Loop counts
6. ID codes (similar to SAP IDoc qualifiers)

These characteristics form the basis for a syntax check. If any rules are violated, the document processing can fail. To avoid wasteful transmissions, the subsystem checks the documents for conformance to the standards defined by the standards committee. The results of the syntax check are sent back to SAP using status code 07 or 08.

Handling Partner−Specific Processing

The subsystem also handles partner−specific processing.Several data elements in the EDI transactions have not been assigned a definitive meaning. The subsystem can handle this partner−specific processing.

Handling Errors

In the outbound process, the subsystem is responsible for reporting to SAP any errors, including translation errors, syntax errors, transmission errors, and connectivity issues. In the inbound process, until an IDoc is created, the subsystem is responsible for reporting and managing the errors. The subsystem provides the necessary monitoring and recovery tools. Once an IDoc is inside SAP, SAP has full responsibility for handling errors.

Communicating with Business Partners

Business partners can provide a direct connection to their network or subscribe to a VAN. The subsystem is responsible for establishing and terminating connections with the business partner's network or VAN to send and receive EDI transmissions. The subsystem is also responsible for processing acknowledgments from the VAN and communicating those to SAP.

Attaching EDI Headers and Controls

EDI transmissions have several header and trailer segments that act as control information The subsystem is responsible for attaching these segments to the document.

Archiving

All important documents, such as payment stubs or remittance advice transmitted to the trading partners, might have to be archived for auditing purposes and liability issues. The subsystems provide data archiving and management options.(51.8)

Related Posts

EDI sub system part one
EDI inbound process overview
EDI inbound process via work flow
EDI outbound process part one and two

ABAP TOPIC WISE COMPLETE COURSE

BDC OOPS ABAP ALE IDOC'S BADI BAPI Syntax Check
Interview Questions ALV Reports with sample code ABAP complete course
ABAP Dictionary SAP Scripts Script Controls Smart Forms
Work Flow Work Flow MM Work Flow SD Communication Interface

SAP Financial Part Two

SAP Financial Customer Vendor Accounts
EnjoySAP Financial Invoice Entry
SAP Financial Automatic Payments
SAP Financial General Ledger Accounts
SAP Financial Customer and Vendor Accounts
SAP Financial Open Item Clearing
SAP Financial Correspondence
SAP Financial Receivables
SAP Financial General Ledger Special Transactions
SAP Financial Credit Risk Management
SAP Financial Reporting Tools
SAP Financial Closing Process

The EDI subsystem carries out the task of converting an EDI document in a standard EDI format to an IDoc file, and vice versa. SAP does not supply the EDI subsystem because several EDI standards are in existence and each standard has multiple versions. To further complicate the process, these standards are still evolving. Hence, this task is best carried out by EDI vendors, who stay current with the standards.

EDI vendors have developed translators to help with the conversion of application−specific messages IDocs, in the case of SAPto standard EDI format. Any translator software product is completely independent of the SAP software and resides outside the SAP system.

The translator can be installed on the same hardware as the SAP system, or it can stand alone on another computer. The operating system environment of the EDI subsystem can be different than the SAP operating system environment. If the SAP system is installed on a UNIX platform, the subsystem can reside on a separate platform that operates on, for example, Windows NT.

SAP certifies several EDI subsystems for compatibility with the EDI interface. The IDoc interface has changed with every release . For this reason, the certification is applicable only for a specific release of SAP.

The subsystem has several responsibilities in the EDI process chain.

Data Mapping

Within the framework of SAP EDI, the conversion of a business document in IDoc format to an EDI standard format (and vice versa) is the most important task performed by a subsystem. This process is resource intensive and, hence, is better done at the subsystem level than within SAP.

The following conversions and translations are carried out by the subsystem.

1. Creating a control record for each inbound IDoc. An inbound IDoc must have a control record.The EDI subsystem builds the control record using the information stored in its local repository or from the SAP repository.
2. Removing the control record during the outbound process. The control record in the IDoc file is used by the subsystem for housekeeping functions, such as locating the trading partner profile. The data on the control record is not needed for translating the content of the EDI documents.
3. Translating data from IDoc format to EDI format. For an outbound transaction, the EDIsubsystem converts data in the IDoc format to a suitable EDI format.
4. Translating data from EDI format to IDoc format. For an inbound transaction, the EDI subsystem converts data in the standard EDI format to IDoc format.
   
5. Bundling and unbundling IDocs. If several IDocs are passed to the EDI subsystem in one file, thesubsystem separates them into individual documents. Similarly, on the inbound process the subsystem can bundle multiple IDocs into a single file to improve performance.

Maintaining the Partner Profile

A partner is defined as the business partner with whom you conduct business and exchange EDI documents. These partners are not necessarily the same as the partners in the partner profile of SAP.
In SAP, the partner profile maintains parameters specific to the IDoc process, and in the subsystem the partner profile maintains parameters specific to the EDI process.

Some attributes in a partner profile are

1. A unique partner number
2. The partner type (Customer, Vendor)
3. The standard used (EDIFACT, ANSI X12, and so on)
4. The version of the EDI standard
5. The EDI message exchanged (850, 860, ORDERS, ORDCHG)
6. A functional acknowledgment flag

Triggering the Inbound Process

After receiving an inbound EDI transmission and creating an IDoc file, the subsystem is often responsible for triggering the inbound process. SAP provides a program named startrfc to start any RFC−enabled function module from the operating system level. For the EDI process, the subsystem uses the start rfc program to trigger the function module EDI_DATA_INCOMING.

Reporting Process Status to SAP

In an outbound process, after an IDoc has been transferred from SAP to the subsystem, SAP loses control over the process. However, SAP maintains visibility into the process by requiring the subsystem to report on the status of the process. SAP provides a file interface for the subsystem to send a status report at every milestone.

When the subsystem has status information to send to SAP, it creates a status file and uses the startrfc program to trigger the SAP system. The status file contains the IDoc number, which is used to identify the IDoc to which the status record is to be attached. The startrfc program calls the EDI_STATUS_INCOMING function module to start the processing of the status file in SAP.

Status Code Description

04 Error within control information of EDI subsystem
05 Error during translation
06 Translation OK
07 Error during syntax check
08 Syntax check OK
09 Error during interchange handling
10 Interchange handling OK
11 Error during dispatch
12 Dispatch OK
13 Retransmission OK
14 Interchange Acknowledgment positive
15 Interchange Acknowledgment negative
16 Functional Acknowledgment positive
17 Functional Acknowledgment negative
22 Dispatch OK, Acknowledgment still due
23 Error during retransmission
24 Control information of EDI subsystem OK
36 Electronic signature not performed (timeout)

Related Posts

EDI inbound process overview
EDI inbound process via work flow
EDI outbound process part one and two
Outbound process with message control

ABAP TOPIC WISE COMPLETE COURSE

BDC OOPS ABAP ALE IDOC'S BADI BAPI Syntax Check
Interview Questions ALV Reports with sample code ABAP complete course
ABAP Dictionary SAP Scripts Script Controls Smart Forms
Work Flow Work Flow MM Work Flow SD Communication Interface

SAP Financial Part Two

SAP Financial Customer Vendor Accounts
EnjoySAP Financial Invoice Entry
SAP Financial Automatic Payments
SAP Financial General Ledger Accounts
SAP Financial Customer and Vendor Accounts
SAP Financial Open Item Clearing
SAP Financial Correspondence
SAP Financial Receivables
SAP Financial General Ledger Special Transactions
SAP Financial Credit Risk Management
SAP Financial Reporting Tools
SAP Financial Closing Process

The inbound process via workflow is similar to the inbound process via function module, except for the difference in the processing that occurs in the application layer.

The IDoc, instead of being processed by a posting program, is processed by a single−step task or a multi−step workflow. Pointing the process code to processing by task or process, instead of processing by function module, configures this option.

Workflow allows human intervention in the process, which is sometimes necessary. A typical example is the sales order change transaction coming in via EDI. Someone might need to review any change from a customer before the change can be accepted; if you have already begun production, you might not be able to accept a change in quantity or delivery date. This process gives you the option of reviewing the changes and taking appropriate action.

In the standard system, the inbound processes use function modules for posting the document. Although no process uses workflow by default, you can customize the interface to start workflow.

The inbound process via workflow differs from processing via function module mainly in the processing that occurs in the application layer. The processing that occurs in the EDI subsystem layer and the ALE/EDI layer is the same in the two approaches as shown in the figure.

Processing in the Application Layer

The posting module in this case is a workflow task. The workflow task can be designed to accommodate any customized processing, such as reviewing an incoming order change transaction followed by posting, or posting an incoming order change document followed by review.

If a complex business process is associated with an incoming document, you can use a multi−step workflow to map that process.

Workflow is a useful method for processing inbound EDI transactions, but it adds additional load to the system, especially when you have high−volume EDI transactions. It also blocks the process unless someone processes the work item, which can cause unnecessary delays.

Exception Handling in the Inbound Process

The inbound process described in this chapter shows the success path from the IDoc's creation through the final creation of the application document, but the system can experience problems at any stage during the process. Compared to the outbound process, the inbound process has more opportunity for error because data originates outside the SAP system. SAP validates the data using the same business rules as if the document were entered online.

The workflow system uses the Post Processing: Permitted Agent fields in the partner profile to send the error notification. For example, an error might occur before an IDoc is created or because the partner profile cannot be read; in any case, the EDI administrator is notified.(47)

Related Posts

EDI inbound process overview
EDI outbound process part one and two
Outbound process with message control

ABAP TOPIC WISE COMPLETE COURSE

BDC OOPS ABAP ALE IDOC'S BADI BAPI Syntax Check
Interview Questions ALV Reports with sample code ABAP complete course
ABAP Dictionary SAP Scripts Script Controls Smart Forms
Work Flow Work Flow MM Work Flow SD Communication Interface

SAP Financial Part Two

SAP Financial Customer Vendor Accounts
EnjoySAP Financial Invoice Entry
SAP Financial Automatic Payments
SAP Financial General Ledger Accounts
SAP Financial Customer and Vendor Accounts
SAP Financial Open Item Clearing
SAP Financial Correspondence
SAP Financial Receivables
SAP Financial General Ledger Special Transactions
SAP Financial Credit Risk Management
SAP Financial Reporting Tools
SAP Financial Closing Process

Thank you for visiting SAP ABAP.If you liked the post, please subscribe to RSS FEED or get the updates directly into your mail box through EMAIL SUBSCRIPTION.

Basic form

LOOP AT itab.
LOOP AT itab INTO wa.

Additions

1. ... FROM n1
2. ... TO n2
3. ... WHERE logexp
4. ... TRANSPORTING NO FIELDS

Effect

Processes an internal table (DATA ) in a loop which begins with LOOP and ends with END LOOP . Each of the internal table entries is sent to the output area in turn.When LOOP AT itab. is used, the header line of the internal table itab is used as output area. In the case of LOOP AT itab INTO wa , there is an explicitly specified work area wa .

If the internal table is empty, all the statements between LOOP and ENDLOOP are ignored. In each loop pass, SY-TABIX contains the index of the current table entry. After leaving a LOOP , SY-TABIX has the same value as it had before. Inserting and/or deleting lines in a LOOP affects subsequent loop passes.

You can use the CONTINUE statement to leave the current loop pass prematurely and continue with the next loop pass. To leave loop processing altogether, you use EXIT . At the end of loop processing (i.e. after ENDLOOP ), the return code value of SY-SUBRC specifies whether the loop
was actually processed.

SY-SUBRC = 0 The loop was executed at least once.
SY_SUBRC = 4 The loop was not executed, either because there was no entry at all or because there was no entry which satisfied the conditions.

Example

The table T is defined as follows:

DATA: BEGIN OF T OCCURS 100,
BAREA(2), BLNCE TYPE P,
END OF T.
After the table has been filled with data (using APPEND ), it is
then output:
LOOP AT T.
WRITE: / T-BAREA, T-BLNCE.
ENDLOOP.

If an internal table is processed only on a restricted basis (with the additions FROM , TO and /or WHERE ), you should not use the control structures for control break processing because the interaction of a restricted LOOP and the AT statement is undefined at present.

If SUM is used in a LOOP and an explicit output area wa has also been specified, this output area must be compatible with the line type of the internal table itab .(91.4)

ABAP TOPIC WISE COMPLETE COURSE

BDC OOPS ABAP ALE IDOC'S BADI BAPI Syntax Check
Interview Questions ALV Reports with sample code ABAP complete course
ABAP Dictionary SAP Scripts Script Controls Smart Forms
Work Flow Work Flow MM Work Flow SD Communication Interface

SAP Financial Part Two

SAP Financial Customer Vendor Accounts
EnjoySAP Financial Invoice Entry
SAP Financial Automatic Payments
SAP Financial General Ledger Accounts
SAP Financial Customer and Vendor Accounts
SAP Financial Open Item Clearing
SAP Financial Correspondence
SAP Financial Receivables
SAP Financial General Ledger Special Transactions
SAP Financial Credit Risk Management
SAP Financial Reporting Tools
SAP Financial Closing Process


Thank you for visiting SAP ABAP.If you liked the post, please subscribe to RSS FEED or get the updates directly into your mail box through EMAIL SUBSCRIPTION.

Basic form

LOOP AT dbtab.

Addition

... VERSION vers

This variant is no longer maintained and should therefore not be used . Instead, please use a SELECT statement.

Effect

Loop processing of the database table dbtab .You must declare the table dbtab under TABLES in the program. dbtab is a table name which begins with "T" and consists of up to five characters.The processing is the same as for variant 1 (except that the system field SY-TABIX is not set). If you want to process the whole table, you must set all table fields to SPACE . Otherwise, the table fields you want to use as a generic argument must be filled beforehand.

Fields of type P and type N have an initial value other than SPACE . This means that fields of this type after CLEAR or MOVE SPACE TO ... are not set to SPACE .

In the case of tables which have arguments containing fields of type P or type N , the entire table header line must be set to SPACE ( MOVE SPACE TO dbtab , not (!) CLEAR dbtab ). It is preferable to use SELECT instead.

Addition

... VERSION vers

You should use this addition only if it is absolutely necessary. In some cases, you can (and it makes sense) to avoid this LOOP addition by using a generation program.

Effect

Specifies a dynamically definable table name. The field varaiable must be a 4-character C field which contains the table name. It is declared under PARAMETERS and evaluated at runtime. The entry read is always placed in the assigned table T.... .

ABAP TOPIC WISE COMPLETE COURSE

BDC OOPS ABAP ALE IDOC'S BADI BAPI Syntax Check
Interview Questions ALV Reports with sample code ABAP complete course
ABAP Dictionary SAP Scripts Script Controls Smart Forms
Work Flow Work Flow MM Work Flow SD Communication Interface

SAP Financial Part Two

SAP Financial Customer Vendor Accounts
EnjoySAP Financial Invoice Entry
SAP Financial Automatic Payments
SAP Financial General Ledger Accounts
SAP Financial Customer and Vendor Accounts
SAP Financial Open Item Clearing
SAP Financial Correspondence
SAP Financial Receivables
SAP Financial General Ledger Special Transactions
SAP Financial Credit Risk Management
SAP Financial Reporting Tools
SAP Financial Closing Process


Thank you for visiting SAP ABAP.If you liked the post, please subscribe to RSS FEED or get the updates directly into your mail box through EMAIL SUBSCRIPTION.

Addition 1

... FROM n1

Addition 2

... TO n2

Effect

Places all internal table entries from the entry with the index (SY-TABIX ) = n1 to the entry with the index = n2 inclusive in the output area in turn.

If either one of the additions " FROM n1 " or " TO n2 " is missing, then the table is processed either from the first entry or up to the last entry (according to what is missing).

Example

Output table entries 7 and 8:

DATA: BEGIN OF T OCCURS 100,
BAREA(5), BLNCE(5),
END OF T.
LOOP AT T FROM 7 TO 8.
WRITE: / T-BAREA, T-BLNCE.
ENDLOOP.

Addition 3

... WHERE logexp

Effect

Places all internal table entries which satisfy the condition logexp in turn in the output area. The condition logexp can be almost any logical expression . The only restriction is that the first field for each comparison must be a sub-field of the line structure of the internal table itab .

Example

DATA: BEGIN OF T OCCURS 100,
BAREA(5), BLNCE(5),
END OF T.
LOOP AT T WHERE BAREA > 0.
WRITE: / T-BAREA, T-BLNCE.
ENDLOOP.
which has the same effect as:
LOOP AT T.
CHECK T-BAREA > 0.
WRITE: / T-BAREA, T-BLNCE.
ENDLOOP.

The interaction between the LOOP AT ... WHERE statement and the AT control break statements is currently undefined. It is therefore important to avoid using either the AT NEW/END OF or FIRST/LAST statements in a LOOP loop with a WHERE condition.

The performance of a LOOP AT ... WHERE statement can be improved significantly if the fields to be compared always have the same data type. The comparison fields should be defined as follows:

DATA LIKE .

Example:

DATA: BEGIN OF T OCCURS 100,
BAREA(5), BLNCE(5),
END OF T.
DATA CMP_BAREA LIKE T-BAREA.
CMP_BAREA = '01'.
LOOP AT T WHERE BAREA = CMP_BAREA.
WRITE: / T-BAREA, T-BLNCE.
ENDLOOP.

ABAP TOPIC WISE COMPLETE COURSE

BDC OOPS ABAP ALE IDOC'S BADI BAPI Syntax Check
Interview Questions ALV Reports with sample code ABAP complete course
ABAP Dictionary SAP Scripts Script Controls Smart Forms
Work Flow Work Flow MM Work Flow SD Communication Interface


SAP Financial Part Two

SAP Financial Customer Vendor Accounts
EnjoySAP Financial Invoice Entry
SAP Financial Automatic Payments
SAP Financial General Ledger Accounts
SAP Financial Customer and Vendor Accounts
SAP Financial Open Item Clearing
SAP Financial Correspondence
SAP Financial Receivables
SAP Financial General Ledger Special Transactions
SAP Financial Credit Risk Management
SAP Financial Reporting Tools
SAP Financial Closing Process

This man named his group as the synonym of truth and never appeared like deviating from the values what he believed.

He has taken the name of andhra pradesh to new heighs and we are still proud to have this man on our soil.

He has not had his life in a highly lavished manner and always down to the ground in terms of character and behaviour.

He may have cooked the books for the sake of brand but we the andhra pradesh people still don't believe that he used that money for his own sake.

Don't mean to say what he has done is correct and want to say give him a chance at least to expalin what went wrong.

Very much disturbed to see the news spreding saying that Raju is a cheat and going home for holidays with a heavy heart .


People might say that the service he is making in the name of Birraju foundation is also for the sake of tax but it is changing the face rural India.

At this hour of crisis I want to express my solidarity to Satyam Staff and simply to put Satyam is a dream of Indains and in specific Andhra pradesh people and let us don't to see this dream collapsing.

Let us be patient for few more days and give some time to settele down every thing and we want to see the truth coming out and up to that I woild likle to give him benifit of doubt.

What do say dear friends ?

We had a overview of EDI inbound process in the previous post.Now we are going to have a discussion of EDI Inbound process through function module.

In this process, the IDocs are transferred from the EDI subsystem to SAP, and then they are passed to the posting function module to post an application document.

Processing in the EDI Subsystem Layer

The inbound SAP EDI process begins at the subsystem layer with an EDI document converted to an IDoc format. The IDoc is stored in a text file at the operating system (OS) layer. The IDoc file can be passed to the ALE/EDI interface layer immediately via the file port using the startrfc program, or can be processed at a later time through execution of program RSEINB00.

The startrfc program is a standard SAP program at the OS level to call any RFC−enabled function module in SAP. To trigger the inbound process, the startrfc program calls the function module EDI_DATA_INCOMING, which acts as the entry point for inbound processes. The name of the IDoc file is passed as an input parameter to this function module.

Processing in the ALE/EDI Layer

The EDI_DATA_INCOMING function module reads the IDoc file into an internal table. The IDoc is first checked for integrity by doing a syntax check. Then the standard ALE services such as version change,filtering, and conversion are applied, if necessary.

The ALE/EDI layer creates an application IDoc in the database. At this point IDoc, which can be monitored via one of the monitoring transactions, is created in the system. The IDoc gets a status code of 50 (IDoc added). If the IDoc passed the syntax check process earlier, it gets a status code of 64 (IDoc ready to be passed to application), signifying that the process can continue.

The processing flag and process code are read from the partner profile table. If the value of the Processing field is set to Process Immediately, the IDoc is passed to the posting program using the RBDAPP01 program.

If the field is set to Background Processing, the IDocs are buffered in the system until the RBDAPP01 program is executed explicitly. RBDAPP01 is usually scheduled to run on a regular basis, or it can be started as a result of an event raised by the subsystem after the IDoc file has been loaded into the SAP system.

Processing in the Application Layer

The posting function module either calls a standard SAP transaction, using the call transaction command for posting the document, or invokes a direct input function module.

The results of the execution are passed back via the function module's output parameters. If posting is successful, an application document is created. The IDoc gets a status code of 53 (Application document posted). If errors occur, the IDoc gets a status code of 51 (Application document not posted).


Related Posts

EDI inbound process overview
EDI outbound process part one and two
Outbound process with message control

ABAP TOPIC WISE COMPLETE COURSE

BDC OOPS ABAP ALE IDOC'S BADI BAPI Syntax Check
Interview Questions ALV Reports with sample code ABAP complete course
ABAP Dictionary SAP Scripts Script Controls Smart Forms
Work Flow Work Flow MM Work Flow SD Communication Interface

SAP Financial Part Two

SAP Financial Customer Vendor Accounts
EnjoySAP Financial Invoice Entry
SAP Financial Automatic Payments
SAP Financial General Ledger Accounts
SAP Financial Customer and Vendor Accounts
SAP Financial Open Item Clearing
SAP Financial Correspondence
SAP Financial Receivables
SAP Financial General Ledger Special Transactions
SAP Financial Credit Risk Management
SAP Financial Reporting Tools
SAP Financial Closing Process