Release Procedure for Purchasing Documents

15.10.2002

Release Procedure in Purchasing Documents

Version 1.00
(7.10.2002)

Gerhard Fuchs

Release Procedure for Purchasing Documents

15.10.2002

References...........................................................................................................................3 Introduction........................................................................................................................3 Persistency Layer...............................................................................................................3

Persistency Layer: EBAN.............................................................................................................................3 Persistency Layer: EKKO.............................................................................................................................3 Persistency Layer: ESSR..............................................................................................................................4

Release Strategy Determination.......................................................................................4

Overview.......................................................................................................................................................4 Customizing/Master Data.............................................................................................................................4 Without classification...............................................................................................................................4 With classification....................................................................................................................................4 Communication Structures...........................................................................................................................5 CEBAN.....................................................................................................................................................5 CEKKO.....................................................................................................................................................5 CESSR......................................................................................................................................................5 Programs.......................................................................................................................................................5

Release State and State Transitions.................................................................................6

Customizing Tables......................................................................................................................................6 Release strategy without classification.....................................................................................................6 Release strategy with classification..........................................................................................................6 How the game works....................................................................................................................................6 State Transition: Old Style Transactions......................................................................................................7 State Transition: Enjoy Transactions............................................................................................................7

Integration Aspects............................................................................................................7
Purchasing Documents.................................................................................................................................7 Requisitions..................................................................................................................................................7 Old style transactions ME51 ff.................................................................................................................7 Collective Release....................................................................................................................................8 External requisitions.................................................................................................................................8 MRP generated requisitions......................................................................................................................8 Enjoy transactions ME51Nff, ME54N.....................................................................................................8

User Interface for Enjoy Transactions............................................................................8 Workflow Interface............................................................................................................8

BOR Integration............................................................................................................................................8 Components..................................................................................................................................................9 Event creation...........................................................................................................................................9 Check module...........................................................................................................................................9 Role resolution..........................................................................................................................................9 Customizing .................................................................................................................................................9 Purchasing.................................................................................................................................................9 Workflow System.....................................................................................................................................9

Release Procedure for Purchasing Documents

15.10.2002

References
A sound online documentation, newly created as of release 4.6C can be found in the SAP info portal.

Introduction
Release procedures in purchasing are used to add a state to the business object, which allows some kind of monitoring on what can be done with the document. Two different kinds of release strategies have to be distinguished: Release strategy determination without classification. The old style strategy determination known from R/2 and R/3 Release < 3.X. Used only for requisition item release. Release strategy determination with classification. Used in purchasing documents (header level), requisition item release and requisition overall release and service entry sheets. Also important: workflow features are only available in this procedure. The following aspects are covered in this document Persistency The determination of the release procedures based on information of the business object. Here only the strategy determination with classification is considered. The old style method is trivial and not covered here. The sequence of release codes which define the release state of an object and thus the allowed follow-on processes. Release procedures are flexible and can be configured in customizing Integration aspects User interface Workflow interface

Persistency Layer
Release strategy attributes are part of the corresponding business object. Two cases have to be considered, requisition items and purchasing document headers.

Persistency Layer: EBAN

EBAN-FRGGR EBAN-FRGST EBAN-FRGKZ EBAN-FRGZU EBAN-FRGRL EBAN-GSFRG Release group. Important for authority checks also. This field is used in the case of release strategy with classification and is empty for the old style method Release strategy Release indicator. Monitors follow-on processes Release state. Describes which release codes have already released the object Relevant for release. Performance indicator. Set to SPACE when object is finally released or object not relevant for release Requisition subject to overall release. Triggered via customizing of the document type.

One important aspect here: in the case of overall release no header information is available in requisitions. The release information is shared over all items.

Persistency Layer: EKKO

EKKO-FRGGR EKKO-FRGSX EKKO-FRGKE EKKO-FRGZU EKKO-FRGRL Release group. Important for authority checks also Release strategy Release indicator. Monitors follow-on processes Release state. Describes which release codes have already released the object Relevant for release. Performance indicator. Set to SPACE when object is finally released or object not relevant for release

Release Procedure for Purchasing Documents

15.10.2002

Persistency Layer: ESSR

ESSR-FRGGR ESSR-FRGSX ESSR-FRGKL EKKO-FRGZU EKKO-FRGRL ESSR-F_LOCK Release group. Important for authority checks also Release strategy Release indicator. Monitors follow-on processes Release state. Describes which release codes have already released the object Relevant for release. Performance indicator. Set to SPACE when object is finally released or object not relevant for release Block release of entry sheet

Release Strategy Determination

Here, only the case release strategy with classification is considered.

Overview
The release strategy determination is based on the classification system. A class type 032 was defined and shipped, which allows a release strategy consisting of a join of release group and release strategy to be classified. The characteristics used here have to be defined with a reference to a table field which is noting else but a component of the relevant communication structure CEBAN ( requisitions ) or CEKKO ( purchasing documents ). Whenever a business object is processed the relevant communication structure is filled (see below) and the release strategy determination gets called. The link between a characteristic and the corresponding value of the communication structure component is established and a class search is executed automatically via function module CLSC_SELECT_OBJECTS. The search result is filtered. This is because the classification system handles a search characteristic value SPACE as a wild card, but our business logic treats space as a valid value. The filtered result contains no, one or more than one search result. In the case of a non-unique result usually a configuration problem exist. In that case we take any of the hits. The result of character length 4 is split into release group and release strategy. Example: Characteristic FRG_EBAN_KNTTP with label Account Assignment Category stands for the account assignment category and points the table field CEBAN-KNTTP. When a requisition is checked for a release strategy, CEBAN-KNTTP gets filled with the value of component KNTTP of the requisition. The search is carried out with FRG_EBAN_KNTTP = CEBAN-KNTTP. As a result we obtain GFS1 which is split into release group GF and release strategy S1. Note: The object search can be carried out also manually via transaction CL24N. This is very helpful for trouble shooting purposes.

Customizing/Master Data
Release strategy determination is based on the following customizing/master data tables.

Without classification
T161I. Account assignment category, material group, plant and value of the item are used for the strategy determination.

With classification
Customizing tables: T161 Document type. In the case of requisitions T161-GSFRG specifies whether overall or item release has to be carried out. T16FG Release groups. Contains a link to the class. Also whether release group is used for overall or item release. For each of these two categories exactly one class can be specified. 4

Release Procedure for Purchasing Documents T16FS Release strategies Master data: Class as defined in T16FG Characteristics, each with the important link to a reference table component. Classification data linked to joined release group/release strategie.

15.10.2002

Communication Structures CEBAN

Requisition item release: Filled in function module ME_REL_STRATEGIE_EBAN, form CEBAN-AUFBAUEN. Account assignment and then item data are moved into corresponding fields of the communication structure. The total value of the item is calculated and stored in CEBAN-GSWRT. A CFC EXIT_SAPLEBND_001 allows a modification of the communication
structure. Requisition overall release. All items and accounting lines are transferred to function module ME_REL_GENERAL_STRATEGY_EBAN. In form CEBAN_AUFBAUEN_GESAMTFRG CEBAN get filled from the first item. Next for all components, which are defined in the characteristics, a check for uniqueness is carried out and if so this unique value is stored in the corresponding CEBAN component. For amount characteristics the first one is taken and the single total amounts are cumulated and stored in CEBAN-GFWRT. A CFC EXIT_SAPLEBND_004 is used to allow the customer to manipulate the result.

CEKKO
The communication structure CEKKO is filled outside of the release strategy determination in the responsible business object. Form STRATEGIE_CEKKO(MM06EF0S_STRATEGIE_CEKKO). An aggregation over all items is carried out and the total net value is stored in CEKKO-GNETW in the case of purchase orders. In the case of outline agreements, the header Target value is used if filled, otherwise the sum of the item target values. Since a note we have a reasonable CFC EXIT_SAPLEBND_002, which receives nearly all of the relevant information form the business object.

CESSR
The communication structure CESSR is filled outside of the release strategy determination in the responsible business object. Form FILL_CESSR(LMLSRF3K). CESSR is filled from ESSR and some purchase order header data linked to the entry sheet. CFC EXIT_SAPLEBND_003 is available to manipulate the data.

Programs
Function group EBND Strategy determination requisition item: Function module ME_REL_STRATEGIE_EBAN. Form CEBAN_AUFBAUEN to fill CEBAN from item/accounting data. Form STRATEGIE_NEU in order to execute the object search Strategy determination requisition overall release: Function module ME_REL_GENERAL_STRATEGY_EBAN. Form CEBAN_AUFBAUEN_GESAMT_FRG to fill CEBAN. Form STRATEGIE_NEU in order to execute the object search. Strategy determination purchasing document: Function module ME_REL_STRATEGIE_EKKO. Form STRATEGIE_CEKKO(MM06EF0S_STRATEGIE_CEKKO) to fill CEKKO from header/item data. Form STRATEGIE_NEU in order to execute the object search Strategy determination service entry sheet: Function module ME_REL_STRATEGIE_ESSR. Form FILL_CESSR(LMLSRF3K) to fill CESSR from ESSR and EKKO data. Form STRATEGIE_NEU in order to execute the object search.

Release Procedure for Purchasing Documents

15.10.2002

Release State and State Transitions

Allowed state transitions ( prerequisites of a release code are fulfilled ) and the action to be carried out when a release code releases an object can be configured in customizing. Such a state transition changes the FRGZU field of the business object. FRGZU is a 8 character field, each character stands for a certain release code as defined in customizing. The assignment of a release indicator as a function of the release state FRGZU is also highly configurable and defined in customizing.

Customizing Tables Release strategy without classification

T161I as described above. T161E Release code and Description T161S Release indicator T161G Assignment to release indicator T161F Prerequisites

Release strategy with classification

T16FG, T16FS as described above. T16FH description of the release group T16FT description of the release strategy T16FC Release code T16FD Description of the release code T16FV Prerequisites and actions T16FK Assignment to release indicator T16FB (purchasing documents), T161S(Purchase requisitions), T16FL(Service Entry sheet) is the release indicator T161U(requisition), T16FE(purchasing document), T16FM(service entry sheet) are the descriptions of the release indicator

How the game works

Basically the state engine for the release strategy with or without classification are the same, only the customizing layer differs. Therefore the discussion can be restricted to the case with classification. Given a release strategy T16FS, a set of release codes are defined there in fields FRGC1 through FRGC8 ( blocked, non-orthogonal database representation ). The code in FRGC1 becomes the logical number 1, the code in FRGC8 the logical number 8. These logical numbers are used from now on. Prerequisites/Actions for each group/strategy/code combination are defined in Table T16FV. Again we have a blocked structure with fields FRGA1 through FRGA8 with the same logical numbering as above. Each field FRGA? Can have three values: : the logical number is not in use X: when the release code of the current line releases, a X is written into the release state FRGZU of the business object at the corresponding logical position of the string +: the logical code of that position is the prerequisite of the release code of the line. The assignment to a release indicator is done via Table T16FK. Given a release state FRGZU and group/strategy of a business object: find an entry in T16FK which corresponds to the release state. The result is the desired release indicator.

1. 2. 3.

Release Procedure for Purchasing Documents

15.10.2002

With this very simple ( and very ugly ) pattern a very flexible release strategy determination can be carried out. The drawbacks of the game are obvious and causes customer complains from time to time: changes in customizing are fatal. Old strategy: prerequisites and all possible assignments to release states have to be maintained manually. Very error-prone.

State Transition: Old Style Transactions

Releasing in old style transactions is carried out via function modules ME_REL_SET and ME_REL_RESET in the case of release strategy with classification. In the case of strategy without classifications the functions modules are ME_SET_RELEASE and ME_RESET_RELEASE genious naming convention!

State Transition: Enjoy Transactions

Since the above function modules couldnt be extended to support a separation between business logic and presentation, a new function group has been made which contains all information on the release strategy configuration: MEREL. This strategy engine consists of public interfaces IF_RELEASE_STRATEGY_MANAGER_MM and IF_RELEASE_STRATEGY_MM and provides all information/services on a given strategy. Above interfaces are implemented as local classes in MEREL. As of release 4.7 this function group is also able to set or reset a release via method PROPAGATE_STATE and therefore the new Enjoy transactions ME29N and ME54N were possible.

Integration Aspects
Purchasing Documents
The release strategy determination takes place during the check. Form PRUEFEN calls form STRATEGIE_ERMITTELN(MM06EF0S_STRATEGIE_ERMITTELN) where the communication structure is build and function module ME_REL_STRATEGIE_EKKO is called. A modification of the messages have to be carried out after that (i.e. no output when release is active). The release process is carried out via ME28, ME35K, ME35L, ME45. form FRG_SET(FM06LFFR_FRG_SET) and FRG_RESET(FM06LFFR_FRG_RESET). Update takes place in form FRG_UPDATE_FB(FM06LFFR_FRG_UPDATE_FB). Technically function modules are used for that which are placed in function group EINI. When posting the documents, the check/update runs via pruefen/buchen of module pool SAPMM06E. Therefore one single update module is used for purchasing documents. Enjoy Transactions. Exactly as above. The interface to the release view is IF_RELEASABLE_MM which is implemented on header level in class CL_PO_HEADER_HANDLE_MM. As of release 4.7 this interface is also able to release Pos vio interface methods INITIATE_RELEASE. Also rejection of the document is possible via method REJECT.

Requisitions
Generally much more complicated since several programs exist and two release methods ( item and overall release) have to be supported.

Old style transactions ME51 ff

Item release strategy is determined in module FRGST on the detail screen. The leading accounting line is determined and passed together with the item to function module ME_REL_STRATEGY_REQUISITION which calls ME_REL_STRATEGIE_EBAN. Overall release determination gets called at the beginning of for BUCHEN.

Release Procedure for Purchasing Documents

15.10.2002

Set/Reset release (ME54) is done via forms OKCODE_SETF/OKCODE_DELF.for both, item and overall release.

Collective Release
Form UCOMM_BUFR sets the release and updates the requisition in a special branch of form AENDERN_BANFS.

External requisitions
Function group EBNE. Release strategy determination for item release in form GET_STRATEGY(LEBNEF0I). See note 322250. This is done when an item is processed via ME_REQUISITION_EXT Overall release via form GESAMTFREIGABE(LEBNEF0I). See note 111599. This is done during final checks via function module ME_CREATE_REQUISITION_EXT.

MRP generated requisitions

Release strategy determination is done via function module ME_REL_STRATEY_REQUISITION (item or overall) when MRP generates EBAN records or when a planned order is converted to a requisition. Form ERMITTELN_FRGST(LM61PF40) (planned order) or ERMITTELN_FRGST(LM61UF4R) (MRP run).

Enjoy transactions ME51Nff, ME54N

Item release in rule LCL_R_REALEASE(LMEREQF60) via ME_REL_STRATEGIE_EBAN Overall Release in rule LCL_R_HD_RELEASE(LMEREQF61) via ME_REL_GENERAL_STRATEGY_REQUISITION. Connection to view: interface IF_RELEASABLE_MM is implemented for both objects, requisition header (overall release, class LCL_REQ_HEADER and item (item release), class LCL_REQ_ITEM. As of release 4.7 an single release/reset release is possible. Same technique as for the PO header.

User Interface for Enjoy Transactions

The business logic for release strategies and the logic needed for state transitions is located in function group MEREL, as described above. The view is places in function group MERELVI. Thechnically this view inherites from class CL_MODEL_CONTROL_VIEW_MM which is able to any model an some UI control components ( a GRID control is used to display the release codes). The model of that view is, of course, a object which implements interface IF_RELEASABLE_MM. So PO headers, req headers and req items can be treated in exactly the same way.

Workflow Interface
BOR Integration
Events have to be defined on the level of the relevant BOR Object. BUS2105, for example stands for the purchase requisition header ( used for overall release) BU2014 is the RFQ etc. The following events are relevant for the release procedure system released reset releaseStepCreated significantlyChanged rejection_start rejection_stop Rejected 8 Released purchase requisition Not used Requisition release step generated Requisition changed significantly Requisition rejected Cancel rejection Release of purchase requisition refused. Old style

Release Procedure for Purchasing Documents event which is no longer used by Enjoy Transactions.

15.10.2002

Components Event creation

Events are created in the update module of the relevant business object. The following function modules are used for that ME_REL_EVENT_EBAN ME_REL_EVENT_GENERAL_EBAN ME_REL_EVENT_EKKO MEREL_PREPARE_WFC_EBAN MEREL_POST_WFC Events for business object BUS2009, requisition item. Old style transactions Events for business object BUS2105, overall release. Old style transactions Events for business object purchasing documents Enjoy transactions: Requisition header and item Update Module general WF Events

Check module
Terminating events for workflow instances have to be filtered because the workflow instance itself does not contain the release code, just the object key. The function module for that is ME_REL_CHECK_EVENT_PARAM

Role resolution
Role resolution is done via standard role which uses function module ME_REL_GET_RESPONSIBLE.

Customizing Purchasing
T16FC Release code. Field FRGWF monitors whether a standard role resolution has to be carried out ( via Table T16FW) or a user defined resolution via exit in function module ME_REL_GET_RESPONSIBLE has to be used Role resolution table for standard resolution

T16FW

Workflow System
Event Linkage SWE2 Instance Linkage SWE3 Workflow Templates Workflow components Connection Workflow and Events Configuration workflow instances against events. The check function module descrived above is very, very important here Make sure a proper user assignment to the workflow is correctly defined. Or make the workflow a general task Make sure that all relevant components have a proper user assignment. Or make the general.