SAP EDI Basic Components Configuration part two

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

SAP EDI Basic Components Configuration

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
Vendor balance in local currency report

H

EDI Subsystem Architecture and Mapping

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

Customer open item analysis report in erp sap

SAP EDI Sub System part two

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

General ledger balance report in mysap.com

General ledger account balance report for fico of sap abap

EDI Subsystem

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

MYsap crm business scenarios and sap solutions

EDI Inbound Process via Workflow

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

What is EDI an introduction
Business process with EDI

What is Loops on an internal table

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)

What is a Idoc?
Outbound process overview
Outbound process via message control
EDI outbound process
EDI inbound process overview

What is syntax for loop part two

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

What is loops on internal table part two

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

Is Satyam Raju is a cheater ?

First time after creation of this blog i would like to deviate from the core ABAP topic here. This is to cross check once about the character of Sayam's Rama Linga Raju.

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 settee down every thing and we want to see the truth coming out and up to that I would like to give him benefit of doubt.

What do say dear friends ?

EDI Inbound Process via Function Module

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

Inbound process via function module
Inbound process via work flow
EDI subsystem part one and twoEDI Subsystem architecture and mapping
EDI basic components configuration part one and two

EDI inbound process overview

The inbound process uses IDoc type, port definition, posting programs, service programs, and configuration tables. The inbound process components are specified in the partner profile and configuration tables.

IDoc Types

The EDI document to be posted has an equivalent message type defined in the SAP system. The message type is based on an IDoc structure.

Posting Programs

Posting programs are implemented in the system as function modules. A posting program exists for each message type. The programs are named with the following naming convention:

IDOC_INPUT_message type

These function modules have a standard interface for their input and output parameters. The function modules can handle one IDoc or multiple IDocs of the same type simultaneously.

A process code is assigned to each posting program. Because process codes are flexible, you can assign any processing type to a process code. A process code can point to a function module or a workflow. In the standard system, process codes always use the Processing by Function module processing type with the Processing with ALE service option.

The Port Definition

In the inbound process, the port definition specifies the name of the input IDoc file and the directory path where the file is located.

The SAP Business Workflow

SAP business workflow represents a sequence of customized steps (dialog and background) that are to be carried out for a process. The workflow management system is used to model the sequence, the information required to carry out the various steps, and the person responsible for the dialog steps.
In workflow terminology, if there is only one step in a flow, it can be implemented using a single−step task. A single−step task is technically defined as a task described by an object method.

If there are multiple steps, they are implemented as a workflow that contains multiple single−step tasks.

The Partner Profile

A partner profile specifies the various components used in an inbound process (partner number, message type, or process code), the mode in which it communicates with the posting program (batch or immediate), and the person to be notified in case of errors.

A partner profile is created for each business partner, and a record exists for each inbound message received from a business partner.

Service Programs and Configuration Tables

The inbound process is asynchronous and can be regarded as a sequence of several processes that work together. To link the components and provide customizing options for an inbound process, SAP provides service programs and configuration tables. The process flow for the inbound process describes the role played by each service program.(43.2)

Related Posts

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

How to set RFC destination part two and part oneDefining a port for message control
EDI Outbound process
Inbound process
Partner profiles configuration part one and two
Overview of outbound parameters part one and two

EDI outbound process

Here we are going to discuss regarding EDI outbound process with out message control.This is in continuation with the previous discussion of EDI outbound process with message control.

The following are the problems in EDI outbound with message control.

1 . Message control might not be available for your application document. Here we have no choice. Applications are programmed to make use of the Message control service, and it is not automatically available for every application. The FI applications, for example, do not use Message control. The REMADV message is generated by the Payment Run program, which does not use Message control. Most ALE processes do not use Message control.

2 · The Message control component is intricate because of its generic technology of building business rules without coding ABAP/4 programs. Here client may not want to maintain Message control because of its complexity and decided to bypass it completely. This is not a configuration option. The client had developed custom programs to select IDoc data and pass it directly to the ALE/EDI layer.

Here are the following steps in this process.

Processing in the Application Layer :

1. The application document is entered by way of a transaction.
2. The business rules for selecting objects for EDI output are established through a selection screen or a dialog box.
3. The data−extraction logic, which is built into the application, is implemented as a separate function module but is still a part of the application logic. This concept is different compared to the outbound process with Message control, in which the data−extraction logic is not part of theapplication logic.
4. The application builds the IDoc and passes control to the ALE layer. The interface to the ALE layer is through the function module MASTER_IDOC_DISTRIBUTE.

Processing in the ALE/EDI Layer

1. The ALE/EDI layer checks for the sender and receiver fields. If they are not supplied, the ALE distribution model is consulted to determine the recipients. The ALE distribution model is used to model the messages exchanged between the systems. A message can have multiple recipients.
2. After the set of receivers is determined, the IDocs are processed for filtering, data conversion, and version change. An IDoc is generated for each partner identified in the distribution model. These IDocs, called communication IDocs, are then saved in the SAP database. That IDoc gets a status record with a status code of 01 (IDoc Created).
3. The IDoc goes through a syntax check and other validations. If there are no errors, the IDoc gets a status of 30 (IDoc Ready for Dispatch to ALE Service).(40.2)

Related Posts about EDI:

EDI outbound process Idoc overview
EDI Process components AND part two
ALE IDOC'S Complete

EDI outbound parameters for message control
EDI inbound parameter views
Partner profile maintenance
Message control Configuration

What is Syntax for Loop ?

Basic form

LOOP.

Effect

Processes the extracted dataset.
By using LOOP ... ENDLOOP , you can process the dataset generated by EXTRACT like an internal table (as in LOOP AT itab ) - if required, after sorting with SORT .

At the end of a control level, the control total of a numeric field f is stored in the field SUM(f) . This total includes all records read, even if further processing in the LOOP has been skipped by CHECK . At the end of a control level, the number of different values which a field f has accepted from the sort key within the group, i.e. the number of control records where the field f has changed its value, is stored in the field CNT(f) .

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 present, the return code value in SY-SUBRC is not set when you use LOOP with extracts. In Release 4.0, however, SYSUBRC will also specify for LOOP via extracts at the end of loop processing (i.e. after ENDLOOP ) whether the loop was processed at least once.

When you have processed a dataset with SORT or LOOP ... ENDLOOP , you cannot extract any more records with EXTRACT . You cannot nest loops on extracted datasets (unlike internal tables), i.e. only one loop on an extracted dataset can be active at any time. However, several consecutive loops are allowed.

Example

DATA: ONR(7), POSITION(3) TYPE N,
CUSTOMER(20),
PNR(5) TYPE N, NAME(15), UNITS TYPE I,
ORDERS TYPE I.
FIELD-GROUPS: HEADER, ORDER, PRODUCT.

INSERT ONR POSITION INTO HEADER.
INSERT CUSTOMER INTO ORDER.
INSERT PNR NAME UNITS INTO PRODUCT.

ONR = 'GF00012'. POSITION = '000'.
CUSTOMER = 'Good friend'.
EXTRACT ORDER.
ADD 1 TO POSITION.
PNR = '12345'. NAME = 'Screw'. UNITS = 100.
EXTRACT PRODUCT.

ADD 1 TO POSITION.

PNR = '23456'. NAME = 'Nail'. UNITS = 200.
EXTRACT PRODUCT.
ONR = 'NB00056'. POSITION = '000'.
CUSTOMER = 'Nobody'.

EXTRACT ORDER.

ONR = 'MM00034'. POSITION = '000'.
CUSTOMER = 'Moneymaker'.
EXTRACT ORDER.

ADD 1 TO POSITION.

PNR = '23456'. NAME = 'Nail'. UNITS = 300.
EXTRACT PRODUCT.
ADD 1 TO POSITION.

PNR = '34567'. NAME = 'Hammer'. UNITS = 4.
EXTRACT PRODUCT.
SORT.
LOOP.
AT ORDER.
WRITE: /, / ONR, CUSTOMER.
ENDAT.
AT ORDER WITH PRODUCT.
WRITE 'ordered:'.
ENDAT.
AT PRODUCT.
WRITE: / ONR, PNR, NAME, UNITS.
ENDAT.
AT END OF ONR.
WRITE: / 'Sum of units:', 26 SUM(UNITS).
ORDERS = CNT(POSITION) - 1.
WRITE: / 'Number of orders:', ORDERS.
ENDAT.
ENDLOOP.

This code generates the following list:

GF00012 Good friend ordered:
GF00012 12345 Screw 100
GF00012 23456 Nail 200
Sum of units: 300
Number of orders: 2
MM00034 Moneymaker ordered:
MM00034 23456 Nail 300
MM00034 34567 Hammer 4
Sum of units: 304
Number of orders: 2
NB00056 Nobody
Sum of units: 0
Number of orders: 0

The previous post of the blog deals with edi outbound process.
Message control architecture part one and two
EDI output types part one and twoMessage control and control table
Working of message control part one and two

EDI Outbound Process with Message Control

Processing in the Application Layer

An application document is entered via a transaction.Before an application document is saved, the Message control component is invoked. An application passes several key elements of the application data to the Message control component via communication structures.

Processing in the Message Control Layer

The Message control component checks various business rules defined in the Message control configuration. Based on the business rules, Message control proposes the output type ,medium and language of the message. Multiple outputs are possible from Message control. Each output is processed independently.

The output proposed by the Message control component can be edited. The user can delete, add, or modify any outputs proposed on the output control screen.

When the application document is saved, the outputs proposed on the output control screen are saved as a record in the NAST table. An entry in the NAST table stores the key of the application document, output type, timing, processing status, and language.

If the timing for an output is set to 4 (Immediate), the system immediately starts the processing of the output type by executing the RSNAST00 program. If the timing is set to 1 (Batch Mode), the entries are processed when the RSNAST00 program is executed explicitly.

The RSNAST00 program is usually scheduled to run on a regular basis. It selects entries that can be processed based on their status and calls the appropriate program for the selected medium. Each output medium (EDI, ALE, fax, printed output, and so on) has a corresponding program to generate the output in the required medium. SAP provides standard processing programs for each output medium.

In the case of EDI, the processing program is a form routine: EDI_PROCESSING in the RSNASTED program. This program is a generic program for all EDI outputs and reads the partner profile configuration to determine the selection program for a particular message.

In ALE, the processing program is also a form routine: ALE_PROCESSING in the RSNASTED program. This program is a generic program for all ALE outputs and reads the partner profile configuration to determine the selection program for a particular message.

Processing in the Selection Program

The selection program is specified in the partner profile with a process code. The RSNASTED program calls the appropriate selection program.

One of the parameters for these function modules is the NAST entry, which contains the key of the application document. These programs extract application data, format it into an IDoc format in an internal table, and then pass control to the ALE/EDI layer.

Processing in the ALE/EDI Layer

The ALE/EDI layer is responsible for creating the IDoc in the SAP database. By now, a tangible IDoc that can be viewed using the various monitoring tools has been created in the system. The IDoc gets a status record with a status code of 01 (IDoc Created).

The IDoc, before being saved in the database, goes through a syntax check and other validations. If there are no errors, the IDoc gets a status of 30 (IDoc Ready for Dispatch to ALE Service).

Dispatching the IDoc

The settings of the Output Mode fields in the partner profile are read to determine the timing of dispatching idoc,and the port definition is read to determine the directory location in which the file will be created. If the mode is set to Do Not Collect IDocs, the IDoc isimmediately passed to the operating system layer automatically, using program RSEOUT00.

The subsystem takes the IDoc file as input and translates it into an EDI standard format. At various milestones, the subsystem reports the status of the process to SAP, thus providing complete visibility into the process from within SAP. The status reported by the subsystem is attached as a status record to the IDoc in the SAP database.

To report status back to the SAP system, the subsystem creates a status file at the OS level and calls the function module EDI_STATUS_INCOMING in SAP, passing the status file name as an input parameter. For this, SAP provides a standard program named startrfc at the OS level to execute any RFC−enabled function module in SAP.


See complete course about ALE IDOC'S HERE.



EDI outbound process Idoc overview
EDI Process components AND part two
Architecture of work flow
Business objects

Out bound EDI Process Over view

The outbound process uses IDoc types, Message control, partner profiles, port definitions, selection programs, service programs, and tables to generate an IDoc.

The IDoc Structure

The EDI document to be generated has an equivalent message type defined in the SAP system. The message type is based on an IDoc structure. For example, if you are going to generate EDI transaction 850, which is a purchase order, the message type ORDERS is assigned in SAP to purchase orders. This message is based on IDoc type ORDERS01 and ORDERS02.

Selection Programs

Selection programs, which are typically implemented as function modules, are designed to extract application data and create an IDoc. A selection program exists for each message type. The programs are generally named with the following naming convention:

IDOC_OUTPUT_message type

The naming convention mentioned here is not a rule, but it is a common practice for naming the outbound programs.

These function modules have a standard interface for input and output parameters. A process code is assigned to each selection program that executes under Message control. Because process codes are flexible, you can assign any processing option to a process code. A process code can point to a function module or a workflow. In the standard system, process codes always point to a function module.

Message Control

Message control is a cross−application technology. It is used in pricing, account determination, material determination, and output determination. The message control component enables you to encapsulate business rules without having to write ABAP/4 programs. In the EDI process, Message control determines and processes the various outputs associated with an application document (for example, EDI, printed output, fax, confirmation, and mail).

The Port Definition

Portis used in the outbound process to determine the name of the EDI subsystem program ,the directory path where the IDoc file will be created at the operating system level, the IDoc file names, and the RFC destination.

The RFC Destination

RFC (Remote Function Call) destination is the term used to define the characteristics of communication links to a remote system on which a function needs to be executed. In EDI, it is used to specify information required to gain access to the system on which the EDI subsystem is installed.

The Partner Profile

A partner profile specifies the various components used in an outbound process (partner number, IDoc type, message type, port, process code), the mode in which it communicates with the subsystem (batch versus immediate), and the person to be notified in case of errors. A partner profile is created for each business partner, and a record exists for each outbound message sent to a business partner.

For example, if two outbound messages (purchase order and purchase order change) are being sent to vendor number VEN001, a partner profile must exist for VEN001, and two outbound records (one for each message type) must exist in the partner profile. The partner profile is an important and frequently referenced component.

Service Programs and Configuration Tables

The asynchronous outbound process can be seen as a sequence of several processes that work together. SAP provides service programs and configuration tables to link the various components and provide customizing options for an outbound process. The process flow for the outbound process describes the role played by each service program and configuration table.(35.1)

See complete course about ALE IDOC'S HERE.

Related Posts about EDI:

EDI outbound process Idoc overview
EDI Process components
EDI Tasks and roles
Work item and SAP IN box
Error notification process part one and two
Work item in EDI Work flow