March 2009

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
SAP OOPS ABAP PART 6

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.

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.

PO10 Organizational unit
PO03 Job
PO13 Position
PO01 Workcenter
PFCT Task catalog
PP01 General

The transaction code for this is PPOC and the menu Path is : From the Area menu of Workflow, choose Organizational Management, Organizational Plan, Create.

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
SAP ABAP BDC PART 1

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

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 RolesSAP ABAP BDC PART 11

SAP ABAP BDC PART 12 BDC SAMPLE CODE FOR XD01

SAP ABAP BDC PART 13 BDC SESSON METHOD SAMPLE CODE

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.

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.

Determining the Task

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

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.

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.

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.

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 _Error.

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).

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

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

Control table in message control

SAP SCRIPTS PART 16

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 process for 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
SAP SCRIPT CONTROLS PART 6

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
CREATION OF SMART FORMS PART THREE

EDI Message Control Setting Up

The standard system ships with a complete suite of Message control components for each application. We can use these components as is, or you can modify them to suit your needs. If the objective is to use the standard components, all we have to do is create condition records to enable the application to use Message control. To plan to build some of the components, such as a new condition table, we have to carry out some configuration steps.They are explained here below in detail.

Creating Condition Records

Creating condition records is specific to each application. We can reach the screen to create condition records via the application menu or by using transaction NACE.

The steps are

1.Execute NACE to display the various applications.

2.Choose the application in which you're interested, and click the Condition Records button.

3.Specify the output type for which you want to create the condition records.

4.Pick the business rule (condition table) for which you want to maintain the condition records.

5.Enter values for the key fields, and specify the output medium, output timing, partner number, and partner function for each record.

6.Save your entries.

Creating a New Condition Component

If the standard Message control functionality does not meet your requirements, we can build the necessary pieces in Message control. The process of that is explained here with an example.

An area presented here sends out an order response via EDI for customer group 01 and sales organization 3000. Standard components are used wherever appropriate. In the analysis of the standard system, output type BA01 is used for EDI output. It points to access sequence 0003, which lacks a business rule based on customer group and sales organization. Therefore, a new business rule will be created and added to an access sequence.

The customer group number is available on the header portion of the sales order. An analysis of the existing condition table shows that there is no condition table based on the customer group and sales organization combination. We reach the steps to build the components for the SD applications from the IMG under Logistics−General, Sales and Distribution, Basic Functions, Output Control or from the SAP standard menu under Logistics, Sales and Distribution, Master Data, Output. You can also access the steps via transaction VOK2.(94.2)

Accessing the Field Catalog

Transaction: V/86
Menu path: From transaction VOK2, choose SD Document, Sales Document, Condition Table, Field Catalog. We have to make sure that the Customer group field (KDGRP) is selected in the field catalog. If it is not, insert the entry in the field catalog.

Creating a Condition Table

Transaction: V/56
Menu path: From transaction VOK2, choose SD Document, Sales Document, Condition Table, Create and establish the key for your business rule in this step. For the scenario, the key fields are Customer group (KDGRP) and Sales organization (VKORG).

Creating an Access Sequence

Transaction: V/48

Menu path: From transaction VOK2, choose SD Document, Sales Document, Access Sequence.A new access sequence does not have to be created, because you can modify the existing access sequence 0003 being used in the condition type BA01. Because the access sequence can be used in several output types, you should build a new access sequence to avoid conflicts with other output types.

Creating an Output Type

Transaction: V/30

Menu path: From transaction VOK2, choose SD Document, Sales Document, Condition Type we can assign the new access sequence to BA01 (order response) or create a new output type. If a new output type is to be created, the best option is to copy BA01 as ZB01 (order response). Select BA01 and click the Copy icon.

Adding the Output Type to a Procedure

Transaction: V/32

Menu path: From transaction VOK2, choose SD Document, Sales Document, Output Determination Proc.

Assigning the Procedure at the Header Level

Transaction: V/43

Menu path: From transaction VOK2, choose SD Document, Sales Document, Assign, Header(96)

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
SAP ABAP SAMPLE CODE FOR ALV LIST DISPLAY REPORT
SAP ABAP SAMPLE CODE FOR ALV LAYOUT DISPLAY REPORT

EDI Message Control Working part two

The present post is in continuation with previous post EDI Message Control how it works part one and going through it give a sort of feeling of continuation.

After the output proposal process is complete, the list of proposed outputs displays on the output control screen of an application, as shown in figure below. The output control screen is usually available at the header level, but in some cases it is available at other levels. For example, with sales orders, it is available at the sales order header and at the sales order item level.

To reach the output control screen of an application, we have to follow the following steps.

Go to the application document with which you are working (a sales order, purchase order, delivery, or billing document).

1. Look for Extras, Output or Header, Output or Header, Messages on the menu, depending on the application area. At the line−item level, you look for Item, Output.

2. The initial status of these outputs is 0 (not processed), displayed as an icon with a yellow light. After the output has been successfully issued it is in status 1 (successfully processed), displayed as a green light icon.

The user entering the application document can carry out the following editing operations.

Delete proposed outputs.
Change timing.
Select new outputs from the list. The same output cannot be listed twice in status 0.
Copy a previously processed output for reprocessing.

If the output medium is 6 (EDI) for an output, the partner number in the proposed output is validated against a partner profile entry. If an entry does not exist in the partner profile table, you cannot save the output.

Output Processing

When the final selection of the output is complete, you can save the application document. A record for each proposed output is saved in the NAST table with the following values.

Application ID ·
Application document key (prefixed with zeros if fewer than 10 characters) ·
Output type ·
Output medium ·
Output timing ·
Status code with value 0 (not processed) ·

We can view a complete list of fields in the NAST table via transaction SE11.

The RSNAST00 program processes entries in the NAST table. This program is started immediately for NAST entries whose timing is set to immediate. For other NAST entries, you must schedule this program. The selection list for this program allows you to specify various parameters.

After RSNAST00 selects a record for processing, it checks the TNAPR table for the processing program associated with an output medium. For EDI, a standard routine, EDI_PROCESSING, exists in the RSNASTED program.

The EDI_PROCESSING routine reads the Message control record in the partner profile and determines the process code. The process code points to a function module. The function module has a standard interface for its input and output parameters. One of the input parameters is the NAST record.

This function module then has all the information necessary to read the application document data and formats the document for the message to be generated, using the IDoc format. The output parameters of the function module are the IDoc data and the control record.

The EDI_PROCESSING program creates a physical IDoc from the data passed back to it from the function module. Then the IDoc is ready for the ALE service layer, where it goes through version change, filtering, and conversion, and is subsequently sent to the operating system through a file port.

Related Posts

EDI Message control configuration and part two
Maintaining partner profiles in EDI
EDI in bound parameters over view
Control table in message control
SAP ABAP SAMPLE CODE ALV SIMPLE REPORT

EDI Message Control Working Way

Message control is basically a three step process.They are

1.Output proposal: Message control checks various business rules and proposes various output types.

2.Output editing: The user accepts or changes the proposed output types.

3.Output processing: The system processes the final list of output types to produce the actual outputs.

They are discussed in detailed below.

Output Proposal

The process described in figure below begins when an application document is created or changed. The application program fills the communication structure with values from the application data entered on the screen. This communication structure is passed to the Message control, along with the application ID and the procedure.

The various output types defined in a procedure are processed one at a time. They are mutually independent, so the results of one do not affect the other outputs. An output type marked as manual in a procedure is not used for an automatic proposal. Only the end user can manually select this output. This approach can be important when we do not want an automatic proposal or when business rules are based on human intelligence and cannot be encapsulated in an ABAP routine.

The processing of output types that are not marked as manual is as follows. If we specify a requirement for an output type in the procedure, the code behind the requirement is executed to see whether the output type meets the requirements or preconditions. If requirements are met, further checking continues. If the output type does not meet the requirements, the next output type in the list is processed. (For example, a sales order response should not be sent out unless the sales order is complete.)

After parsing the list of output types in a procedure, the system "short lists" the output types that meet the requirements or preconditions. In the case of output types for the SD modules (sales, shipping, and billing), the system checks whether the access condition flag is set for an output type. If the flag is not set, the values for the output medium and timing for the output type are determined from the customer master data. If the flag is selected, processing continues for determining the output medium and timing.

For each output type in which the access condition flag is set, the access sequence associated with the output type is used to access various business rules and determine which of these business rules are satisfied. A business rule is satisfied if the application values passed in the communication structure result in a condition record being found using the keys of the business rule.

The process is

Validate any requirements that exist for a business rule. If the result is negative, the current business rule is skipped, and the next business rule in the sequence is checked.

1. If a business rule passes the requirement check or a requirement is not specified, the condition table for that business rule is accessed for any condition records that match the application data passed in the communication structures.

2. If a match is found, the values of the partner function, partner number, output medium, output language, and output timing are copied for that output type, and the output type is considered as proposed.

3. If the business rule uses exclusive strategy, the process ends here, and the whole processing starts from the very beginning for the next output type.

4. If an inclusive strategy is used, the next business rule in the access sequence is processed. The
purpose of an inclusive strategy is to propose multiple outputs of the same type to different partners.

5.Two instances of the same output type cannot have identical output parameters.

Related Posts

EDI Message control configuration and part two
Maintaining partner profiles in EDI
EDI in bound parameters over view
Control table in message control
SAP ABAP SAMPLE CODE FOR MULTIPLE INTERACTIVE REPORT
SAP ABAP SAMPLE CODE MULTIPLE INTERACTIVE REPORT TWO

EDI,Idoc Message Control and Control Table

The condition table specifies the key fields for a business rule. If a business rule requires you to send EDI based on sales organization and customer, the key for the business rule is Sales Organization (VKORG) and Customer Number (KNDNR).

Thus, we formulate a business rule by specifying the fields that are to be used in decision making, as shown in figure below and we can get to this screen from the Access sequence by double−clicking on the Fields folder in the Dialog Structure frame.) You use this key to access the condition records for output values such as output medium, partner function, partner number, output language, and output time for the message.

If the standard condition tables supplied in the system do not meet your requirements, you can create new condition tables. We must derive the keys for condition tables from the field catalog, which is a subset of the communication structure. This added layer helps you to manage fields. We can select all the fields from the communication structure in our field catalog.

Condition Records

Condition records are inserted in the condition table. Condition records contain the actual data against which the business rules are checked to propose an output. In the figure below, customer number is used as a rule to propose the output. Here we can see that a condition record has two pieces.

1.Key values of the business rule by which a condition record is accessed. (In the figure , customer number is the key value.)

2·The output values of partner function and number, and output medium, timing, and language.

Condition records are considered master data and are maintained by customers. If we are using standard pieces of Message control, the only components we need to create are condition records and Message control parameters in the partner profile.

Related Posts

EDI Message control configuration and part two
Maintaining partner profiles in EDI
EDI in bound parameters over view
EDI outbound parameters view part one and Two
abap programming for mm module

EDI Output Type part two

Request you to go through EDI Output type part one first to get the feel of continuation.

Access Sequence

An access sequence defines a sequence in which business rules are checked for proposing an output type. A business rule is checked by comparing the values passed in the application data with the values defined in the condition records of the condition table. If a match occurs, a business rule is considered satisfied. After a business rule is satisfied, the output values from the condition record are used for the output type.

We give an access sequence a four−character name, usually a number. It has the following attributes.

A set of business rules or conditions ·
A sequence in which the rules or conditions are checked ·
A requirement that checks for business rules using ABAP programs ·
An exclusive or inclusive strategy ·

To view the access sequence, select an application in transaction NACE, then click on the Access sequences button. To see the details of an access sequence, select it and then double−click on the Accesses folder in the Dialog Structure frame. figure below illustrates two business rules. Business rule 1 is based on Doc.Type/Sales Org./Customer. Business rule 2 is based on Sales Organization/Customer Number. Each business rule is, effectively, a set of fields defined in a condition table.

Each business rule can also have some preconditions, which are implemented in requirements. These preconditions are captured in the requirements. A requirement is implemented as an ABAP/4 program and assigned a number. You can view a list of requirements defined in the system by using transaction VOFM.

A requirement is optional, but if you prefer, you can specify it for each business rule used in an access sequence. The exclusive or inclusive strategy specifies whether the system should exit after the first match of the business rule against the condition records or should continue to process other business rules in the access sequence.

If we choose the exclusive strategy, the system exits on the first match. In the inclusive strategy, the system continues to validate the rest of the business rules. The reason for an inclusive strategy is to have an output type proposed multiple times. However, one of the attributes (partner function, partner number, or language) must be different. The system does not allow two output types to have identical values.

For example, you choose the inclusive strategy when you have to send a purchase order to your business partner via EDI and also to another SAP system via ALE. The output is the same, but the partners are different. An access sequence can define any number of business rules.

Related Posts

EDI Message control configuration and part two
Maintaining partner profiles in EDI
EDI in bound parameters over view
EDI outbound parameters view part one and Two
EDI partner profile configuration
SAP ABAP INTERVIEW ROUND ONE FAQ'S PART TWO

EDI Output Type

An output type defines the characteristics and attributes of the output itself, as shown in figure below. We access the output types on transaction NACE by selecting an application and clicking the Output type button.

Then double click an output type to see its details. Examples of output types available for a sales order are BA00 (sales order response), ESYM (internal output), and MAIL (mail).

We define the following attributes for an output type, beginning with the output type name, which is a maximum of four characters long. Examples of output type names are NEU and BA00.

On the General Data tab, we define the following:

Access Sequence: Basically, this is a set of business rules.

Access to Conditions: If you select this flag, the values for the output medium and timing are determined from the condition records using the access sequence. For the output types used in the SD modules (sales, shipping, and billing), if this flag is not selected, the values for the output medium and timing are not determined from the condition records. Instead, those values are determined from the customer master data.

In the customer master data, an output view exists in the sales area data to specify the values for the output medium and the language. Specifying the values in the customer master is useful when you do not have any complex rules and the values for the output medium and timing are based on the customer number.

Cannot Be Changed: This determines whether the output can be edited.

Multiple Issuing: This determines whether multiple outputs are permitted.

Change Output: Here we can specify a program and form routine that determines whether changes made to the document are relevant for sending the output in a change mode.

On the Default Values tab, we define the following:

Transmission Medium: Possible values include EDI, print, SAP office mail, workflow, and ALE.

Dispatch Time:This determines whether the message is sent immediately or in batch.(86)

EDI Message Control Architecture part two

This post is in continuation with EDI Message control architecture part one and going through that post will give comfort in understanding the present post.

Communication Structure

The communication structure passes application information to the Message control. The communication structure acts as a container. Each application has its own application structure.

The communication structure for output determination uses the naming convention KOMxByy, where x can be K or P. K means the header structure and P means the line−item structure. yy is the two−character application ID. Hence, KOMKBV1 is the communication structure for sales order header information.

Procedure

A procedure defines a set of possible outputs for an application. A procedure is assigned a six−character name. We can define several procedures for an application, but only one can be configured as active.

A list of procedures for an application can be seen via the IMG or, in transaction NACE, by selecting an application and clicking the Procedures button. To see the attributes of a procedure, select a procedure and double−click the Control folder in the Dialog Structure frame. A procedure has three main attributes that affect the proposal of an output type .

A list of output types ·
A Requirement field ·
A manual flag

We can view fields in a communication structure by using transaction SE11. By using append structures, even we can extend communication structures. If a communication structure is extended, the extended fields have to be populated in a user exit to pass those values to the Message control.

User exits are available for populating the extended fields in a communication structure. The list of output types represents a set of outputs that are possible for an application. It does not mean that they will be proposed; it simply means that the system evaluates these outputs for proposal. An output type that does not exist in a procedure cannot be proposed. Examples of certain output types applicable for a sales order are

A sales order response
An internal message
Hard copy output

For each output type, we can define preconditions. (For example, a sales order response should not be sent out unless the sales order is complete.) These preconditions are captured in the requirements. A requirement is implemented as an ABAP/4 program and assigned a number. You can view a list of requirements defined in the system by using transaction VOFM. A requirement is optional, but if you want, you can specify one for each output used in a procedure.

We can mark an output type as manual in a procedure, meaning that the system does not attempt to propose that output automatically. This output can only be selected manually by a user. This type of output can be important when you do not want an automatic proposal or when the business rules are based on human intelligence and cannot be encapsulated in an ABAP/4 routine.

We can create new procedures, output types, and requirements to suit your needs.

Related Posts

EDI Message control configuration
Maintaining partner profiles in EDI
EDI in bound parameters over view
EDI outbound parameters view part one and Two
EDI partner profile configuration

EDI Message Control Architecture

The important terms for message control are

1.Output types are also called messages, message types, or condition types.
2.Procedures are also called message schemas.
3.Condition type and condition record are two separate things.

The figure shows the relationship between various components that make up the Message control system and the re usability of components. Components are reusable within an application.

For example, we can use a condition table in more than one access sequence. Components are related to each other via one to one relationships or one to many relationships. In a one to one relationship, a component can have only one component linked to it.

For example, an output type can have only one access sequence associated with it. In one to many relationships, a component can be associated with more than one component. For example, an application can have more than one procedure associated with it. To access the Message control components for various applications, you execute either transaction NACE or NACO.

If we are using an R/3 version older than 4.6, use transaction NACE. We might see a button labeled Expert Mode. If so, click it to see the list of Message control applications.

The Application ID

Applications capable of generating various outputs are assigned a two−character application ID in Message control. For example, the ID for the purchasing application is EF, and the ID for the sales order application is V1. figure (transaction NACE) shows a complete list of application IDs.

Application IDs serve as the starting points to drill down into the various Message control components used by an application.

A quick shortcut to access various Message control components for the SD and MM applications is to use transactions VOK2 for SD and VOK3 for purchasing.(84.2)

Related Posts

EDI Message control configuration
Maintaining partner profiles in EDI
EDI in bound parameters over view
EDI outbound parameters view part one and Two
EDI partner profile configuration
EDI inbound process
EDI Outbound process
EDI Port defination
EDI outbound message control

Subscribe to: Posts ( Atom )