SAP EDI Work flow set up part three
SAP is the wonderful ERP which is most successful and implemented thousands of times in MNC's all over the world.The flexibility of SAP and its customization according to the client requirement are biggest strengths of it.
It has cross application components like ALE and EDI which are very much useful to integrate the business with in house as well as third party soft wares. Work flow is a serious and advanced technology used in SAP ABAP which makes a lot of problem assignment and solving is automated with the help of team members of the project.
Previously we had discussed about setting up of work flow for EDI and ALE here at
SAP ABAP EDI WORK FLOW SET UP PART ONE
SAP ABAP EDI WORK FLOW SET UP PART TWO
and this present post is in continuation with that.
Setting Up Active Monitoring
Active monitoring sends a work item when the state of the system exceeds a predefined threshold state. For example, if the number of error IDocs for invoices exceeds 100, you can have the system send a work item to a user or position.
SAP provides a report program RSEIDOCM that you can schedule to run at regular intervals or execute online. The selection parameters for this report allow you to specify the threshold values and the person to be notified . We can restrict the report by IDoc type, groups of messages, and several other parameters. The system starts a single−step task (TS30200088) when it exceeds the defined threshold.
Follow these steps to run the report online
1.Create a task profile: Like any other task, you have to define the possible agents for the task (TS30200088).
2.Execute the report (RSEIDOCM) by using transaction SE38.
3.Specify the responsible PD−ORG object on the selection screen. This object can be a user, a position,a job, or an organizational unit.
4.Define threshold values. The selection parameters allow you to specify threshold values.
Setting Up an Inbound Process via Work flow
In the standard SAP ABAP system, the inbound process is implemented as a function module that calls a posting program for an IDoc. The standard system can be configured to start a workflow or a single−step task for an incoming IDoc. This approach of using a workflow or a single step task can be useful when you want someone to review the IDoc data before it's posted in the system.
Steps to process an incoming IDoc via a single step task or workflow are
1.Identify a standard task, customer task, or workflow that needs to be started. In the standard system, none of the processes are configured for starting a task or workflow for inbound. You have to develop a custom workflow to implement your business process.
2. Create a new process code, and point the process code to the new workflow using transaction WE42.
3.In the partner profile for the inbound message, make sure that the inbound message uses the new process code.
Related topics with Complete series of lessons
ALE IDOC complete series
ABAP WORK FLOW complete
ALE Complete
Request you to subscribe for RSS FEED or get the updates directly into your mail box through EMAIL SUBSCRIPTION.
Support this blog with Your Google Vote here @
It has cross application components like ALE and EDI which are very much useful to integrate the business with in house as well as third party soft wares. Work flow is a serious and advanced technology used in SAP ABAP which makes a lot of problem assignment and solving is automated with the help of team members of the project.
Previously we had discussed about setting up of work flow for EDI and ALE here at
SAP ABAP EDI WORK FLOW SET UP PART ONE
SAP ABAP EDI WORK FLOW SET UP PART TWO
and this present post is in continuation with that.
Setting Up Active Monitoring
Active monitoring sends a work item when the state of the system exceeds a predefined threshold state. For example, if the number of error IDocs for invoices exceeds 100, you can have the system send a work item to a user or position.
SAP provides a report program RSEIDOCM that you can schedule to run at regular intervals or execute online. The selection parameters for this report allow you to specify the threshold values and the person to be notified . We can restrict the report by IDoc type, groups of messages, and several other parameters. The system starts a single−step task (TS30200088) when it exceeds the defined threshold.
Follow these steps to run the report online
1.Create a task profile: Like any other task, you have to define the possible agents for the task (TS30200088).
2.Execute the report (RSEIDOCM) by using transaction SE38.
3.Specify the responsible PD−ORG object on the selection screen. This object can be a user, a position,a job, or an organizational unit.
4.Define threshold values. The selection parameters allow you to specify threshold values.
Setting Up an Inbound Process via Work flow
In the standard SAP ABAP system, the inbound process is implemented as a function module that calls a posting program for an IDoc. The standard system can be configured to start a workflow or a single−step task for an incoming IDoc. This approach of using a workflow or a single step task can be useful when you want someone to review the IDoc data before it's posted in the system.
Steps to process an incoming IDoc via a single step task or workflow are
1.Identify a standard task, customer task, or workflow that needs to be started. In the standard system, none of the processes are configured for starting a task or workflow for inbound. You have to develop a custom workflow to implement your business process.
2. Create a new process code, and point the process code to the new workflow using transaction WE42.
3.In the partner profile for the inbound message, make sure that the inbound message uses the new process code.
Related topics with Complete series of lessons
ALE IDOC complete series
ABAP WORK FLOW complete
ALE Complete
Request you to subscribe for RSS FEED or get the updates directly into your mail box through EMAIL SUBSCRIPTION.
SAP EDI Work Flow Setting part two
SAP EDI work flow set up is the continuation of previous post Setting up work flow part one which is a vital part in the cross applications of SAP ABAP and going through the previous post gives more convenience in understanding the present topic.
To build an organizational unit
1.We have to start by using transaction PPOCE. Accept the default validity dates on the Create Root Organizational Object pop−up dialog.
2. The main maintenance screen, shown in figure below, has four windows. Clockwise from the upper−left corner, these are the Object Selection window, the Overview window, the Details window, and the Search Result window. Enter an abbreviation and name for your organizational unit in the Details window, and click the Save icon.
3.To create and assign positions to your organization, click the far−left icon in the Overview window to display a list of views as shown in the figure below. Select the Staff Assignments (List) view. At this point, we can change the view to a workflow−specific one by selecting Goto, Switch Settings from the drop−down menu. Select the Organization and Staffing (Workflow) view. This will add several workflow−specific object icons in the Object Selection window.
4.Create the various positions as required by clicking the Create Position icon in the Overview window as shown in the figure. We can leave the job description blank for now. Assign an abbreviation to the position, and give it a meaningful name. Repeat this step for all positions identified earlier.
5.Assign users to these positions. Click the User icon in the Search window, and select a group of users. The Search Result window will display the users selected. Drag each user to the Overview window,and drop it into the appropriate position. Figure below shows the result. Repeat this step for all positions.
Related PostsWork item in work flow
SAP WORK ITEM AND INBOX
EDI Tasks and Roles
Request you to subscribe for RSS FEED or get the updates directly into your mail box through EMAIL SUBSCRIPTION.
Setting Up Workflow
Before any workflow configuration can begin, a set of basic workflow settings must be maintained in the system. If an application is using the workflow module for the first time, these settings will most likely be missing.
The steps to carry out the Basic workflow settings are not in the scope of ALE/EDI settings, but we will have to verify that these settings are maintained. These settings establish a basic infrastructure for the various workflow components.
At the bottom of the screen are two sets of lights: one for the definition components and one for the run time components of workflow. A green light indicates that all the necessary settings are correct. However, a red light does not necessarily mean that workflow will not work; that depends on the item that is not configured correctly.
We can use the Automatic Customizing button, but we must be logged on with the highest authorization level. A Basis person is usually the best person to execute Automatic Customizing because his or her ID should have all possible authorizations.
Developing a Strategy for developing a work flow error notification :
Our objective is to design the organization structure so that the right person is notified and the workload can be managed efficiently. The following steps will help you build a strategy.
1.Develop a list of messages being used in the ALE/EDI process. Identify the tasks associated with each message.
2.Develop a list of users who will handle application errors for each of the identified messages. When selecting a user, make sure that you select a business person and not a technical person, because mostverrors that occur during production are data related, and business people are the best equipped to fixvdata errors.
3.Identify a key technical person who will handle technical problems with the interface. This person becomes the IDoc administrator; he or she does not need detailed functional knowledge.
4.Identify the number of positions that will be required to handle the ALE/EDI process. This number depends on the organization's complexity, the number of EDI messages, and the volume of EDI transactions. It is usually best to define a position for each business function. For example, one position can handle all messages related to the purchasing cycle, and another position can handle messages related to invoicing. Your organization might require one person per message type.
5·Identify backups for each user.
Building an Organizational Unit
We can reach it from the Organizational Plan node on the SAP standard menu or with the following transactions.
Further part will be continued in the next post.
Related Posts
Work item in work flow
SAP WORK ITEM AND INBOX
EDI Tasks and Roles
Request you to subscribe for RSS FEED or get the updates directly into your mail box through EMAIL SUBSCRIPTION.
Support this blog with Your Google Vote here @
The steps to carry out the Basic workflow settings are not in the scope of ALE/EDI settings, but we will have to verify that these settings are maintained. These settings establish a basic infrastructure for the various workflow components.
At the bottom of the screen are two sets of lights: one for the definition components and one for the run time components of workflow. A green light indicates that all the necessary settings are correct. However, a red light does not necessarily mean that workflow will not work; that depends on the item that is not configured correctly.
We can use the Automatic Customizing button, but we must be logged on with the highest authorization level. A Basis person is usually the best person to execute Automatic Customizing because his or her ID should have all possible authorizations.
Developing a Strategy for developing a work flow error notification :
Our objective is to design the organization structure so that the right person is notified and the workload can be managed efficiently. The following steps will help you build a strategy.
1.Develop a list of messages being used in the ALE/EDI process. Identify the tasks associated with each message.
2.Develop a list of users who will handle application errors for each of the identified messages. When selecting a user, make sure that you select a business person and not a technical person, because mostverrors that occur during production are data related, and business people are the best equipped to fixvdata errors.
3.Identify a key technical person who will handle technical problems with the interface. This person becomes the IDoc administrator; he or she does not need detailed functional knowledge.
4.Identify the number of positions that will be required to handle the ALE/EDI process. This number depends on the organization's complexity, the number of EDI messages, and the volume of EDI transactions. It is usually best to define a position for each business function. For example, one position can handle all messages related to the purchasing cycle, and another position can handle messages related to invoicing. Your organization might require one person per message type.
5·Identify backups for each user.
Building an Organizational Unit
We can reach it from the Organizational Plan node on the SAP standard menu or with the following transactions.
- PO10 Organizational unit
- PO03 Job
- PO13 Position
- PO01 Workcenter
- PFCT Task catalog
- PP01 General
Further part will be continued in the next post.
Related Posts
Work item in work flow
SAP WORK ITEM AND INBOX
EDI Tasks and Roles
Request you to subscribe for RSS FEED or get the updates directly into your mail box through EMAIL SUBSCRIPTION.
Work Item in EDI Work Flow
During the work flow different kinds of errors will occur and error notification process is discussed in earlier posts. Now how this errors are handled will be coming to discussion in the present post.
Routing Error to a Responsible Agent as a Work Item
After an error has been classified into one of the preceding categories, the task associated with the error is started. The user responsible for the task is determined via the role defined at the task level. A work item is created for the task and sent to the person identified using the role.
The workflow concept behind resolving a person responsible for an error is interesting. The system defines various types of agents, and each type has a specific objective.
A task has three types of agents: possible agents, selected agents, and the actual agent .Possible agents represent persons who can execute a task. Not all the possible agents get a work item when a task is started.
Possible agents are configured in the system by assigning a task to several HR objects (job, position, organizational unit, and so on). A task can be set to General Task, which means that it can be executed by anyone. If we define a task as a General Task, we do not have to assign a task specifically to an HR object.
Setting a task as a General Task is useful if the possible agents cannot be identified any other way. Drawback is that workflow sends a work item to possible agents if it cannot determine selected agents, meaning that everyone in the SAP system will get a work item in their Inbox. Such a situation indicates that the IDoc administrator is not set up correctly.Selected agents are the users who get a work item in their Inbox. They are determined by the role resolution logic. Selected agents must be a subset of possible agents. If they are not a subset of possible agents, the status of the work item is set to Error, and the work item is routed to the workflow administrator.
If the selected agents cannot be found, the work item is sent to all possible agents. In the ALE/EDI process, the selected agents are configured in the partner profile and the IDoc Administrator settings in transaction WE46.
The actual agent is the person who executes the work item from the Inbox. A work item can have several selected agents but only one actual agent. When a selected agent executes a work item, the actual agent for the work item is established, and the work item immediately disappears from the Inbox of other selected agents. If an actual agent realizes that he or she cannot resolve the problem, the user can replace the work item, causing it to reappear in the selected agents' Inbox.
The EDIM, EDIP, EDIL, EDIR, and EDIS categories of errors are reported directly to the EDI administrator. The remaining errors, EDIX, EDIY, EDIO, EDIN, and EDII, have three levels of support for reporting the error.
Level 1 If a partner profile is located for that problem, the organizational object specified at the
message level (inbound or outbound) in the partner profile is notified.
Level 2 If level 1 cannot be identified because of a problem in locating the record, the level−2 organizational object specified in the General view of the partner profile is read.
Level 3 If neither level 1 nor level 2 can be identified, the system reads the EDICONFIG table for the IDoc administrator and sends a notification.
Related Posts
SAP WORK ITEM AND INBOX
EDI Tasks and Roles
Please subscribe to RSS FEED or get the updates directly into your mail box through EMAIL SUBSCRIPTION.
Work Flow Error Notificaiton Process part two
This present post is in continuation with previous post of Error notification process part one . Going through the that post will give more convenience in under standing the present post.
Errors in the Inbound ALE/EDI Interface
Errors other than syntax errors can occur from the point at which a physical IDoc is created in the system to the point at which the IDoc is delivered to the application−posting program. These errors are mainly due to configuration problems in the partner profile or to information passed in the control record that does not find a matching partner profile. These errors are logged with a status code of 56 (IDoc with Errors Added).
Error in the Inbound Process: EDIITS00008068
For a non−syntax error during inbound IDoc processing before calling the posting program, the system initiates this task, and the person identified in the General view of the partner profile is notified. If a partner profile cannot be read at all, the IDoc administrator is notified.
Errors in the Application Posting Program
After an IDoc is passed to the posting program, errors reported by the posting program are considered application errors. These are logged in the IDoc with a status code of 51 (Application Document Not Posted).
Such errors are usually related to data in the IDoc and are among the most common errors seen on an inbound process.
A standard task exists for each incoming message. The naming convention is_Errors. These tasks are initiated as a result of an error event (InputErrorOccurred) triggered by the system on the application IDoc object. The person identified in the Inbound view of the partner profile for that message is notified.
For example, the task for incoming orders is Orders_Error (TS00008046). This task is started when the InputErrorOccurred event is raised on object IDOCORDERS. By using transaction SWE2, we can see the linkage between an event and the task in the event linkage table.
Syntax Errors during Outbound Processing
After an outbound IDoc has been created successfully in the system, the IDoc goes through a syntax check. This task is started for syntax errors found on an outbound IDoc. Errors are logged in the IDoc with a status code of 26 (Error during Syntax CheckOutbound). This error usually occurs during testing, and frequent syntax errors in a live system suggest a lack of testing .
Syntax ErrorOutbound: EDIXTS00008070
If an outbound IDoc fails the syntax check, the system initiates this task. The person identified in the partner profile for the IDoc message is notified.
Errors in the Outbound ALE/EDI Interface
Errors other than syntax errors can occur from the point at which a physical IDoc is created in the system to the point at which the IDoc is delivered to the EDI subsystem. These errors are mainly due to configuration problems in the partner profile, but can also occur when receivers for a message cannot be determined. These errors are logged with a status code of 29 (Error in ALE Service).
Error in the Outbound Process: EDIOTS00007989
For non−syntax errors when processing outbound IDocs the system initiates this task, and the person identified in the General view of the partner profile is notified. If a partner profile cannot be read at all, the IDoc administrator is notified.
Errors in the Outbound ALE/EDI Interface (IDoc Packet Processing)
When outbound IDocs are processed in groups, errors other than syntax errors can occur from the point at which a physical IDoc is created in the system to the point at which the IDoc is delivered to the EDI subsystem. These errors are mainly due to configuration problems in the partner profile, but can also occur when receivers for a message cannot be determined. These errors are logged with a status code of 29 (Error in ALE Service).
Error in the Outbound Process (IDoc Packet Processing): EDIPTS60001307
For non−syntax errors when processing outbound IDocs in packets the system initiates this task, and the IDoc administrator is notified.
Errors in the Subsystem
These errors are relevant only for outbound IDocs. When an IDoc leaves the SAP system and is transferred to the subsystem, errors encountered in the subsystem or processes thereafter are reported to SAP. These errors start a workflow that sends a notification to the EDI administrator. This task allows the administrator to initiate immediate reprocessing of the IDoc, if desired, when executing the work item.
Error in the Subsystem, Post−Processing Allowed: EDIRTS70008125
When the subsystem sends a status record reporting a processing error, the system starts this task, and the IDoc administrator is notified.
Error in the subsystem: EDISTS30000078
This error is also relevant only for outbound IDocs and is triggered by situations similar to those that trigger EDIR. EDIS was the standard process code up to version 4.6A, when EDIR replaced it. It can still be triggered as a fallback when configuration does not result in EDIR being called. If triggered, the system starts this task, and the IDoc administrator is notified.
Related Posts
SAP WORK ITEM AND INBOX
EDI Tasks and Roles
Please subscribe to RSS FEED or get the updates directly into your mail box through EMAIL SUBSCRIPTION.
Support this blog with Your Google Vote here @
Errors in the Inbound ALE/EDI Interface
Errors other than syntax errors can occur from the point at which a physical IDoc is created in the system to the point at which the IDoc is delivered to the application−posting program. These errors are mainly due to configuration problems in the partner profile or to information passed in the control record that does not find a matching partner profile. These errors are logged with a status code of 56 (IDoc with Errors Added).
Error in the Inbound Process: EDIITS00008068
For a non−syntax error during inbound IDoc processing before calling the posting program, the system initiates this task, and the person identified in the General view of the partner profile is notified. If a partner profile cannot be read at all, the IDoc administrator is notified.
Errors in the Application Posting Program
After an IDoc is passed to the posting program, errors reported by the posting program are considered application errors. These are logged in the IDoc with a status code of 51 (Application Document Not Posted).
Such errors are usually related to data in the IDoc and are among the most common errors seen on an inbound process.
A standard task exists for each incoming message. The naming convention is
For example, the task for incoming orders is Orders_Error (TS00008046). This task is started when the InputErrorOccurred event is raised on object IDOCORDERS. By using transaction SWE2, we can see the linkage between an event and the task in the event linkage table.
Syntax Errors during Outbound Processing
After an outbound IDoc has been created successfully in the system, the IDoc goes through a syntax check. This task is started for syntax errors found on an outbound IDoc. Errors are logged in the IDoc with a status code of 26 (Error during Syntax CheckOutbound). This error usually occurs during testing, and frequent syntax errors in a live system suggest a lack of testing .
Syntax ErrorOutbound: EDIXTS00008070
If an outbound IDoc fails the syntax check, the system initiates this task. The person identified in the partner profile for the IDoc message is notified.
Errors in the Outbound ALE/EDI Interface
Errors other than syntax errors can occur from the point at which a physical IDoc is created in the system to the point at which the IDoc is delivered to the EDI subsystem. These errors are mainly due to configuration problems in the partner profile, but can also occur when receivers for a message cannot be determined. These errors are logged with a status code of 29 (Error in ALE Service).
Error in the Outbound Process: EDIOTS00007989
For non−syntax errors when processing outbound IDocs the system initiates this task, and the person identified in the General view of the partner profile is notified. If a partner profile cannot be read at all, the IDoc administrator is notified.
Errors in the Outbound ALE/EDI Interface (IDoc Packet Processing)
When outbound IDocs are processed in groups, errors other than syntax errors can occur from the point at which a physical IDoc is created in the system to the point at which the IDoc is delivered to the EDI subsystem. These errors are mainly due to configuration problems in the partner profile, but can also occur when receivers for a message cannot be determined. These errors are logged with a status code of 29 (Error in ALE Service).
Error in the Outbound Process (IDoc Packet Processing): EDIPTS60001307
For non−syntax errors when processing outbound IDocs in packets the system initiates this task, and the IDoc administrator is notified.
Errors in the Subsystem
These errors are relevant only for outbound IDocs. When an IDoc leaves the SAP system and is transferred to the subsystem, errors encountered in the subsystem or processes thereafter are reported to SAP. These errors start a workflow that sends a notification to the EDI administrator. This task allows the administrator to initiate immediate reprocessing of the IDoc, if desired, when executing the work item.
Error in the Subsystem, Post−Processing Allowed: EDIRTS70008125
When the subsystem sends a status record reporting a processing error, the system starts this task, and the IDoc administrator is notified.
Error in the subsystem: EDISTS30000078
This error is also relevant only for outbound IDocs and is triggered by situations similar to those that trigger EDIR. EDIS was the standard process code up to version 4.6A, when EDIR replaced it. It can still be triggered as a fallback when configuration does not result in EDIR being called. If triggered, the system starts this task, and the IDoc administrator is notified.
Related Posts
SAP WORK ITEM AND INBOX
EDI Tasks and Roles
Please subscribe to RSS FEED or get the updates directly into your mail box through EMAIL SUBSCRIPTION.
Work Flow Error Notificaiton Process
Errors can be encountered at various points in the inbound and outbound processes of SAP edi/ale. work flow. Errors are routed to responsible agents via workflow. The selected agents find a work item in their Inbox. The work items can be executed to examine the details of the error. After the problem is fixed, the process can be restarted from the point of failure.
The error notification process comprises the three steps given below and are explained further.
Errors are classified into categories, depending on the type. A task is started in response to an error. The error−handling process for each type of error is unique and defined in a task via the method that is executed.
A role is also defined for each task to identify the person responsible for it. The following sections describe the error categories, listing the process code and task for each.
General Errors are encountered in the process before an IDoc is created. In the inbound process, these errors are related to reading or deleting the IDoc file at the OS level, or to any internal errors in processing an incoming IDoc file. In the outbound process, these errors can be related to errors creating the output file.
No IDoc created yet: EDIMTS30000020
This process code can sometimes be invoked by file−opening and reading problems when processing status files from the EDI subsystem. The system initiates this task, and the IDoc administrator is notified.
Display NAST Record with Msg. No IDoc created yet: EDINTS70008037
If an error occurs before an IDoc is created in an outbound process using Message control, this process code is invoked. When the work item is processed, it displays the object keys of the NAST record that attempted to trigger the IDoc creation.
Using information from the NAST record, the system attempts to notify the receiver identified either in the Outbound Partner Profile view for the partner and document or in the General view. If neither can be determined, the IDoc administrator is notified.
Error in the Inbound Status File: EDILTS70008373
If an error occurs in the processing of an IDoc status file from the EDI subsystem before an IDoc is created, the system triggers this process code. Such errors result from problems in opening the file, reading the status records, or formatting problems on a record and the IDoc administrator is notified.
Syntax Errors during Inbound Processing
After an inbound IDoc has been created successfully in the system, the IDoc goes through a syntax check. When syntax errors are found in an incoming IDoc, they are logged in the IDoc with a status code of 60 (Error during Syntax CheckInbound). Syntax errors usually occur during testing; frequent syntax errors in a live system suggest a lack of testing.
Syntax ErrorInbound: EDIYTS00008074
If the inbound IDoc fails the syntax check, the system initiates this task, and the person identified in the partner profile for the IDoc message is notified.
Related Posts
SAP WORK ITEM AND INBOX
EDI Tasks and Roles
Business Objects
ALE EDI WORK FLOW architechere
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
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 can contact me at d_vsuresh[at the rate of ]yahoo[dot]co[dot]in for any specific feed back and suggestions.
Support this blog with Your Google Vote here @
The error notification process comprises the three steps given below and are explained further.
- Determining the task to be started.
- Routing the error to a responsible agent as a work item.
- Processing the work item by the responsible agent.
Errors are classified into categories, depending on the type. A task is started in response to an error. The error−handling process for each type of error is unique and defined in a task via the method that is executed.
A role is also defined for each task to identify the person responsible for it. The following sections describe the error categories, listing the process code and task for each.
General Errors are encountered in the process before an IDoc is created. In the inbound process, these errors are related to reading or deleting the IDoc file at the OS level, or to any internal errors in processing an incoming IDoc file. In the outbound process, these errors can be related to errors creating the output file.
No IDoc created yet: EDIMTS30000020
This process code can sometimes be invoked by file−opening and reading problems when processing status files from the EDI subsystem. The system initiates this task, and the IDoc administrator is notified.
Display NAST Record with Msg. No IDoc created yet: EDINTS70008037
If an error occurs before an IDoc is created in an outbound process using Message control, this process code is invoked. When the work item is processed, it displays the object keys of the NAST record that attempted to trigger the IDoc creation.
Using information from the NAST record, the system attempts to notify the receiver identified either in the Outbound Partner Profile view for the partner and document or in the General view. If neither can be determined, the IDoc administrator is notified.
Error in the Inbound Status File: EDILTS70008373
If an error occurs in the processing of an IDoc status file from the EDI subsystem before an IDoc is created, the system triggers this process code. Such errors result from problems in opening the file, reading the status records, or formatting problems on a record and the IDoc administrator is notified.
Syntax Errors during Inbound Processing
After an inbound IDoc has been created successfully in the system, the IDoc goes through a syntax check. When syntax errors are found in an incoming IDoc, they are logged in the IDoc with a status code of 60 (Error during Syntax CheckInbound). Syntax errors usually occur during testing; frequent syntax errors in a live system suggest a lack of testing.
Syntax ErrorInbound: EDIYTS00008074
If the inbound IDoc fails the syntax check, the system initiates this task, and the person identified in the partner profile for the IDoc message is notified.
Related Posts
SAP WORK ITEM AND INBOX
EDI Tasks and Roles
Business Objects
ALE EDI WORK FLOW architechere
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
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 can contact me at d_vsuresh[at the rate of ]yahoo[dot]co[dot]in for any specific feed back and suggestions.
EDI Work Items and SAP Inbox
A work item represents an instance of a task that needs to be executed. A work item has text describing its purpose and can have various states that govern the operations allowed.
We can see the table below which describes the various states of a work item and its effect on usability.
Status and Description of work items :
The following are the different status of work item and their description.
The SAP Inbox is an interface to manage workflow work items and SAP office documents. The figure below shows a list of work items in a user's Inbox. It can be compared with the Inbox of regular e−mail systems that we use at work. The SAP Inbox contains separate buckets for office documents and workflow items. Office documents are the e−mail documents, and workflow items are work items. We can display and execute the work items from the Inbox. The Inbox interface is highly configurable.
The transaction code is SBWP and the menu Paths is From the SAP Easy Access menu, click on the Business Workplace icon. Or, from the SAP standard menu, choose Office, Workplace, and then expand the entry for Inbox. From the area menu for Workflow, choose Runtime Tools, Business Workplace.
Related Posts
EDI Tasks and Roles
Business Objects
ALE EDI WORK FLOW architechere
Work flow in ale and edi
Work flow management
Working of message control part one and two
EDI Message control configuration and part 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
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 can contact me at d_vsuresh[at the rate of ]yahoo[dot]co[dot]in for any specific feed back and suggestions.
Support this blog with Your Google Vote here @
We can see the table below which describes the various states of a work item and its effect on usability.
Status and Description of work items :
The following are the different status of work item and their description.
- Ready A work item is created and is visible to all selected agents.
- Reserved Reserved by a user and disappears from the Inbox of other selected users.
- In Process worked on and can be seen only in the Inbox of the user who started it.
- Completed A work item is complete and cannot be seen in the Inbox of any user.
The SAP Inbox is an interface to manage workflow work items and SAP office documents. The figure below shows a list of work items in a user's Inbox. It can be compared with the Inbox of regular e−mail systems that we use at work. The SAP Inbox contains separate buckets for office documents and workflow items. Office documents are the e−mail documents, and workflow items are work items. We can display and execute the work items from the Inbox. The Inbox interface is highly configurable.
The transaction code is SBWP and the menu Paths is From the SAP Easy Access menu, click on the Business Workplace icon. Or, from the SAP standard menu, choose Office, Workplace, and then expand the entry for Inbox. From the area menu for Workflow, choose Runtime Tools, Business Workplace.
Related PostsEDI Tasks and Roles
Business Objects
ALE EDI WORK FLOW architechere
Work flow in ale and edi
Work flow management
Working of message control part one and two
EDI Message control configuration and part 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
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 can contact me at d_vsuresh[at the rate of ]yahoo[dot]co[dot]in for any specific feed back and suggestions.
EDI Tasks and Roles
A task defines a piece of work that can be executed and tracked in the system. A task points to a method of an object, as shown .
A task defines the text describing the purpose of the task, the triggering event based on which the task is started, the terminating event that marks the completion of a task, and a role that contains the rules to identify the person who is responsible for executing the task. A task can be started in response to an event triggered in the system.
A task defines the text describing the purpose of the task, the triggering event based on which the task is started, the terminating event that marks the completion of a task, and a role that contains the rules to identify the person who is responsible for executing the task. A task can be started in response to an event triggered in the system.
The menu Path for task is From the Area menu of Workflow, choose Definition Tools, Tasks/Task Groups.
Tasks are categorized as standard tasks (TS) or customer tasks (T). Standard tasks are provided by SAP and are client independent, and customer tasks are client dependent and developed by customers.
In the ALE/EDI process, tasks are mainly used for error handling. A task has been defined for every standard message and for each type of error in the process. The tasks for a message are named as
Customers can change Work item text and Triggering events attributes of a task.Roles are workflow objects used to determine the person responsible for carrying out a specific task. Each task has a role assigned to it. Roles for the ALE/EDI process are implemented as function modules in the system .These function modules can read any information stored in the SAP system. SAP sets the interface for these function modules. The return parameters of this function module are the object type and object ID.
Transaction code for roles is PFAC and menu path is transactions is PFAC_INS (create), PFAC_CHG (change) PFAC_DIS (display) PFAC_DEL (delete).
Related PostsBusiness Objects
ALE EDI WORK FLOW architechere
Work flow in ale and edi
Work flow management
Working of message control part one and two
EDI Message control configuration and part 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
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 can contact me at d_vsuresh[at the rate of ]yahoo[dot]co[dot]in for any specific feed back and suggestions.
Business Objects
A business object represents a business entity that has a definite state and various properties. We can carry out various functions on the object. A business object encapsulates the entire functionality of an object.
A business object is given a name in SAP. For instance, a standard material is assigned the name BUS1001006; it has properties such as material number, description, and material type. These properties are represented using attributes of the business object.
The various operations that can be carried out on an object are implemented with methods. For example, if we want to create a material, we can call that business object's Create method. An object also has different states. It exposes its various states by publishing events. For example, the material object has a created event that is published whenever a new material is created.
Transaction code for business objects is SWO1 and menu path is from the Area menu of Workflow, choose Definition Tools, Business Object Builder.
Several business objects are defined in the system and organized in the BOR (Business Object Repository). Objects are implemented as a series of inherited objects, starting with a generic object and ending with a very specific object. The various objects designed for the ALE/EDI process are IDOC related as explained below.
The IDOC object represents a generic IDoc. This object is not used directly in the process, but provides a generic implementation of the attributes and functions associated with an IDoc.
The IDOCAPPL object represents a generic application IDoc used in ALE and EDI. It is inherited from the IDOC object and acts as the main object from which application−specific objects are inherited. Most functions and attributes used in an IDoc are implemented in this object as shown in the figure below. The transaction SW01 display for this object, shows the various components of the IDOCAPPL.
IDOC is derived from the IDOCAPPL object and represents an application−specific object. Although no additional functionality is added after inheriting the IDOCAPPL object, it is the application−specific object that is referenced in the configuration tables.
IDOCPACKET object represents a packet of IDocs.
IDPK represents a packet of specific types of IDocs. For example, IDPKORDERS represents a packet of IDoc orders. The IDPKORDERS object is inherited from IDOCPACKET.
Related Posts
ALE EDI WORK FLOW architechere
Work flow in ale and edi
Work flow management
Working of message control part one and two
EDI Message control configuration and part 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 Five
SAP Financial Cost Management
SAP Financial Dunning
SAP Financial Lock Box
SAP Financial Interest Calculation
SAP Financial Payment Cards
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 can contact me at d_vsuresh[at the rate of ]yahoo[dot]co[dot]in for any specific feed back and suggestions.
Support this blog with Your Google Vote here @
A business object is given a name in SAP. For instance, a standard material is assigned the name BUS1001006; it has properties such as material number, description, and material type. These properties are represented using attributes of the business object.
The various operations that can be carried out on an object are implemented with methods. For example, if we want to create a material, we can call that business object's Create method. An object also has different states. It exposes its various states by publishing events. For example, the material object has a created event that is published whenever a new material is created.
Transaction code for business objects is SWO1 and menu path is from the Area menu of Workflow, choose Definition Tools, Business Object Builder.
Several business objects are defined in the system and organized in the BOR (Business Object Repository). Objects are implemented as a series of inherited objects, starting with a generic object and ending with a very specific object. The various objects designed for the ALE/EDI process are IDOC related as explained below.
The IDOC object represents a generic IDoc. This object is not used directly in the process, but provides a generic implementation of the attributes and functions associated with an IDoc.
The IDOCAPPL object represents a generic application IDoc used in ALE and EDI. It is inherited from the IDOC object and acts as the main object from which application−specific objects are inherited. Most functions and attributes used in an IDoc are implemented in this object as shown in the figure below. The transaction SW01 display for this object, shows the various components of the IDOCAPPL.
IDOC is derived from the IDOCAPPL object and represents an application−specific object. Although no additional functionality is added after inheriting the IDOCAPPL object, it is the application−specific object that is referenced in the configuration tables.
IDOCPACKET object represents a packet of IDocs.
IDPK represents a packet of specific types of IDocs. For example, IDPKORDERS represents a packet of IDoc orders. The IDPKORDERS object is inherited from IDOCPACKET.
Related Posts
ALE EDI WORK FLOW architechere
Work flow in ale and edi
Work flow management
Working of message control part one and two
EDI Message control configuration and part 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 Five
SAP Financial Cost Management
SAP Financial Dunning
SAP Financial Lock Box
SAP Financial Interest Calculation
SAP Financial Payment Cards
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 can contact me at d_vsuresh[at the rate of ]yahoo[dot]co[dot]in for any specific feed back and suggestions.
ALE and EDI Workflow Architecture
The components used in workflow fall into two categories: PD−ORG (organizational) objects and workflow objects, as shown in figure below We can view and maintain these components by using standard transactions, which you reach via the area menu for workflow.
The transaction code is SWLD and the menu Path is from the SAP standard menu, choose Tools, Business Workflow, Development.
PD−ORG objects are used to represent a company's organization structure in SAP. SAP provides several types of PD−ORG objects, such as positions, jobs, organizational units, and work centers. These objects are assigned a one−character or two−character ID to represent the object type. The type of object appears in parentheses wherever applicable.
Organizational Plans
An organizational plan represents the complete information about a company's organization structure. The main elements of an organizational plan are
Hierarchy among various organizational units : A company can have several organizational units broken down by function. For example, a company can have several divisions, such as engineering, manufacturing, and finance. A division can be divided further. For example, a manufacturing division can contain several plants.
Jobs performed in a company : A job involves performing one or more business tasks. For example, purchasing clerk, sales order clerk, design engineer, programmer, secretary, and manager.
Positions held by the organization's employees in the organization and the reporting structure : For example, purchasing clerk for plant 1000, manager of the accounting department, and secretary to the CEO. The reporting structure or chain of command might be that the accounting department manager reports to the head of the finance division, and so on.
Organizational Units (O)
An organizational unit is responsible for a specific function in a company. For example, an organizational unit can represent a department, physical location, division, subsidiary, or project team. An organizational unit can contain other organizational units. Organizational units are linked in a hierarchical fashion to form the entire organization structure. An EDI department is an example of an organizational unit.
Jobs (C)
Jobs represent a flexible means of identifying a user responsible for handling errors. A job describes a set of tasks performed by a person holding a position to which that job is assigned. Although we can assign individual tasks directly to a position, it is advisable to group tasks together in a job and to assign the job to the position. This approach helps to reduce the maintenance effort. EDI administrator, manager, secretary, and engineer are jobs. The job of an EDI administrator can be to handle all the technical errors associated with the EDI interface.
Positions (S)
A position is another flexible means of finding a person responsible for handling errors. A position in a company represents a rank. For example, a level 1 manager represents the first level of management. Positions are linked in hierarchical fashion to represent the chain of command in a company.
A user is assigned to a position that represents his or her rank. If an employee is promoted, that person leaves his or her current position and is assigned to another position. Positions are thus more stable entities than employees in a company. Positions are assigned jobs to represent the tasks performed by a position. Tasks can be assigned to a position directly or via jobs.
Workcenters (A) Workcenters represent a physical location where a set of activities is carried out. In the case of workflow, we can use workcenters to represent one or more groups in the EDI department.
Users (US) A user is a person who has been granted access to the SAP system to use its various functions. A user ID identifies a user in the system.
Related Posts
Work flow in ale and edi
Work flow management
Working of message control part one and two
EDI Message control configuration and part two
Maintaining partner profiles in EDI
EDI in bound parameters over view
Control table in 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 Five
SAP Financial Cost Management
SAP Financial Dunning
SAP Financial Lock Box
SAP Financial Interest Calculation
SAP Financial Payment Cards
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 can contact me at d_vsuresh[at the rate of ]yahoo[dot]co[dot]in for any specific feed back and suggestions.
Support this blog with Your Google Vote here @
The transaction code is SWLD and the menu Path is from the SAP standard menu, choose Tools, Business Workflow, Development.
PD−ORG objects are used to represent a company's organization structure in SAP. SAP provides several types of PD−ORG objects, such as positions, jobs, organizational units, and work centers. These objects are assigned a one−character or two−character ID to represent the object type. The type of object appears in parentheses wherever applicable.
Organizational Plans
An organizational plan represents the complete information about a company's organization structure. The main elements of an organizational plan are
Hierarchy among various organizational units : A company can have several organizational units broken down by function. For example, a company can have several divisions, such as engineering, manufacturing, and finance. A division can be divided further. For example, a manufacturing division can contain several plants.
Jobs performed in a company : A job involves performing one or more business tasks. For example, purchasing clerk, sales order clerk, design engineer, programmer, secretary, and manager.
Positions held by the organization's employees in the organization and the reporting structure : For example, purchasing clerk for plant 1000, manager of the accounting department, and secretary to the CEO. The reporting structure or chain of command might be that the accounting department manager reports to the head of the finance division, and so on.
Organizational Units (O)
An organizational unit is responsible for a specific function in a company. For example, an organizational unit can represent a department, physical location, division, subsidiary, or project team. An organizational unit can contain other organizational units. Organizational units are linked in a hierarchical fashion to form the entire organization structure. An EDI department is an example of an organizational unit.
Jobs (C)
Jobs represent a flexible means of identifying a user responsible for handling errors. A job describes a set of tasks performed by a person holding a position to which that job is assigned. Although we can assign individual tasks directly to a position, it is advisable to group tasks together in a job and to assign the job to the position. This approach helps to reduce the maintenance effort. EDI administrator, manager, secretary, and engineer are jobs. The job of an EDI administrator can be to handle all the technical errors associated with the EDI interface.
Positions (S)
A position is another flexible means of finding a person responsible for handling errors. A position in a company represents a rank. For example, a level 1 manager represents the first level of management. Positions are linked in hierarchical fashion to represent the chain of command in a company.
A user is assigned to a position that represents his or her rank. If an employee is promoted, that person leaves his or her current position and is assigned to another position. Positions are thus more stable entities than employees in a company. Positions are assigned jobs to represent the tasks performed by a position. Tasks can be assigned to a position directly or via jobs.
Workcenters (A) Workcenters represent a physical location where a set of activities is carried out. In the case of workflow, we can use workcenters to represent one or more groups in the EDI department.
Users (US) A user is a person who has been granted access to the SAP system to use its various functions. A user ID identifies a user in the system.
Related Posts
Work flow in ale and edi
Work flow management
Working of message control part one and two
EDI Message control configuration and part two
Maintaining partner profiles in EDI
EDI in bound parameters over view
Control table in 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 Five
SAP Financial Cost Management
SAP Financial Dunning
SAP Financial Lock Box
SAP Financial Interest Calculation
SAP Financial Payment Cards
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 can contact me at d_vsuresh[at the rate of ]yahoo[dot]co[dot]in for any specific feed back and suggestions.
Work Flow Usage in ALE and EDI
The ALE/EDI interface mainly uses workflow for exception (or error) handling. We can also use workflow for handling notifications in other areas.
Error Notification
Error notification is the primary use of workflow in the ALE/EDI interface. Figure bleow illustrates the processfor error handling via workflow. When exceptions are raised in the outbound or inbound process, workflow is started, and a user responsible for handling the error receives a notification in his or her SAP Inbox. After the problem is analyzed and fixed, the process can be restarted from the Inbox. If the problem is severe enough to require the process to be restarted from the beginning, the process in error can be purged to avoid any further processing.
Errors are intelligently routed to the right person based on the type of error. Errors have been grouped into various categories. A person can be responsible for handling multiple types of errors, or several users can be responsible for resolving a single type of error. We can configure the system to handle errors in various ways, depending on the size of company.
Active Monitoring
Active monitoring allows you to specify threshold values for the state of the system. If the system crosses the threshold limit, a person responsible for system problems can be notified. We set a threshold on the number of IDocs in error or the time limit in which a process must complete.
Rule Based Inbound Flow
We can set up workflow to handle processing of an inbound IDoc .An inbound IDoc starts a function module that invokes the posting program to create an application document from the IDoc.
If we use a workflow, we can set it up to do whatever is needed for your business process. SAP does not provide standard workflows for the inbound ALE/EDI processes, but we can develop our own workflows and tie them to the ALE/EDI process.
Check ABAP WORK FLOW Complete here for a over view .
Related Posts
Work flow management
Working of message control part one and two
EDI Message control configuration and part two
Maintaining partner profiles in EDI
EDI in bound parameters over view
Control table in 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 Five
SAP Financial Cost Management
SAP Financial Dunning
SAP Financial Lock Box
SAP Financial Interest Calculation
SAP Financial Payment Cards
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 can contact me at d_vsuresh[at the rate of ]yahoo[dot]co[dot]in for any specific feed back and suggestions.
Work Flow Management
The work flow management system provides procedural automation of steps in a business process. Work flow defined as the automation of a business process, in whole or part, during which documents, information, or tasks are passed from one participant to another for action, according to a set of procedural rules.
SAP embraces work flow as a cross application technology for use in all modules. SAP provides a full development environment to model and implement your business process via work flow.
The workflow development environment is a true object oriented development environment. The basic component in workflow is a business object on which operations are carried out. These operations are implemented as methods. BAPIs (Business Application Programming Interfaces) are special methods implemented in the business objects.
Events, which are part of the business object, are triggered for changes in the state of the object, which can cause other processes to begin. Workflow uses the organization structure to determine the person responsible for executing a task. The organization structure is modeled by using the Organizational Management component of the HR (Human Resources) module.
Advantages of Work Flow :
Business process integration: The actual time spent executing a task is far less than the time it becomes available for execution to the time it is completed. When a task is ready for execution,workflow eliminates unnecessary waiting by sending it directly to the right person to execute it.
Intelligent routing: Tasks are often routed to the wrong person because the person who originally carried out the task is no longer with the company or has moved to another division. Workflow has a built−in module to determine the right person for the job dynamically at run time. Workflow takes into account the organization's dynamics and ensures that the right person is notified.
Flexible task assignments: Using workflow, you can set the person to be notified at a level that is more abstract than user ID. Assigning a task directly to a user has several disadvantages. The user can leave the company or change jobs. On the other hand, positions and jobs tend to be relatively stable. It is more likely that a user would leave a job than that a company would eliminate a job. Thus, if tasks are assigned to a position or a job, whoever holds that position in the company at any given time is responsible for the task.
Proactive approach: The responsible person does not have to look constantly for problems. If a situation requires the user's attention, a work item appears in his or her SAP Inbox. This system is also called active monitoring.
Substitution and backup facility: Substitution and backup are built in to the workflow system. We can assign a backup for each position on an as−needed basis. When the primary person for execution of a task is unavailable, work can be automatically routed to a backup.
Process monitoring capability: Several tools are available in the workflow system to monitor the current state of a process and to determine workload by user, position, and so on.
Deadline monitoring: Tasks in a business process can be assigned a time limit for completion. If the task is not completed within the time frame, someone else (such as the person's supervisor) can be notified.
Statistical analysis: The monitoring tools also provide statistical information for fine−tuning the business process. We can identify bottlenecks in the process and take corrective measures.
Check ABAP WORK FLOW Complete here for a over view .
Related Posts
Working of message control part one and two
EDI Message control configuration and part two
Maintaining partner profiles in EDI
EDI in bound parameters over view
Control table in 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 Five
SAP Financial Cost Management
SAP Financial Dunning
SAP Financial Lock Box
SAP Financial Interest Calculation
SAP Financial Payment Cards
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 can contact me at d_vsuresh[at the rate of ]yahoo[dot]co[dot]in for any specific feed back and suggestions.
Support this blog with Your Google Vote here @
SAP embraces work flow as a cross application technology for use in all modules. SAP provides a full development environment to model and implement your business process via work flow.
The workflow development environment is a true object oriented development environment. The basic component in workflow is a business object on which operations are carried out. These operations are implemented as methods. BAPIs (Business Application Programming Interfaces) are special methods implemented in the business objects.
Events, which are part of the business object, are triggered for changes in the state of the object, which can cause other processes to begin. Workflow uses the organization structure to determine the person responsible for executing a task. The organization structure is modeled by using the Organizational Management component of the HR (Human Resources) module.
Advantages of Work Flow :
Business process integration: The actual time spent executing a task is far less than the time it becomes available for execution to the time it is completed. When a task is ready for execution,workflow eliminates unnecessary waiting by sending it directly to the right person to execute it.
Intelligent routing: Tasks are often routed to the wrong person because the person who originally carried out the task is no longer with the company or has moved to another division. Workflow has a built−in module to determine the right person for the job dynamically at run time. Workflow takes into account the organization's dynamics and ensures that the right person is notified.
Flexible task assignments: Using workflow, you can set the person to be notified at a level that is more abstract than user ID. Assigning a task directly to a user has several disadvantages. The user can leave the company or change jobs. On the other hand, positions and jobs tend to be relatively stable. It is more likely that a user would leave a job than that a company would eliminate a job. Thus, if tasks are assigned to a position or a job, whoever holds that position in the company at any given time is responsible for the task.
Proactive approach: The responsible person does not have to look constantly for problems. If a situation requires the user's attention, a work item appears in his or her SAP Inbox. This system is also called active monitoring.
Substitution and backup facility: Substitution and backup are built in to the workflow system. We can assign a backup for each position on an as−needed basis. When the primary person for execution of a task is unavailable, work can be automatically routed to a backup.
Process monitoring capability: Several tools are available in the workflow system to monitor the current state of a process and to determine workload by user, position, and so on.
Deadline monitoring: Tasks in a business process can be assigned a time limit for completion. If the task is not completed within the time frame, someone else (such as the person's supervisor) can be notified.
Statistical analysis: The monitoring tools also provide statistical information for fine−tuning the business process. We can identify bottlenecks in the process and take corrective measures.
Check ABAP WORK FLOW Complete here for a over view .
Related Posts
Working of message control part one and two
EDI Message control configuration and part two
Maintaining partner profiles in EDI
EDI in bound parameters over view
Control table in 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 Five
SAP Financial Cost Management
SAP Financial Dunning
SAP Financial Lock Box
SAP Financial Interest Calculation
SAP Financial Payment Cards
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 can contact me at d_vsuresh[at the rate of ]yahoo[dot]co[dot]in for any specific feed back and suggestions.
