SOBRE DSD65 Enhancements Sd

April 12, 2019 | Author: Pablo Barrio | Category: Subroutine, Control Flow, Databases, Sales, Software Development
Share Embed Donate


Short Description

sd...

Description

SOBRE DSD65 enhancements sd

Sales Order Management Enhancement – Best Practice Skip to end of metadata •



Added by Sridhar Srirama, Srirama, last edited by Sridhar Srirama on Srirama on Apr 29, 2014

Go to start of metadata

Purpose This document provides some best practices which can be used for sales order enhancement implementation

Overview In an SAP implementation for the client, there could be multiple implementation of the same user exit for different purpose; multiple implementations could refer to same master data. The typical problems faced in such scenarios are 1)

Same master data is fetched from data base tables multiple times in different implementation

2) Unnecessary data fetches for master data like material, sales organization, company code details which are available as structure in standard program SAPMV45A. 3)

Multiple loops on sales order item, schedule item in each implementation.

4) Fetching of master data at incorrect place which leads to execution of the select query multiple times to fetch the same data 5) Incorrectly updating of Update indicator for sales item and and schedule schedule item might might cause cause inconsistency inconsistency in sales order transaction. 6) Triggering of subsequent document creation on save of sales sales order is performed at at same same LUW which takes additional time to save the sales order.

This document is intended to solve these problems by providing few tips which will help us improving performance as well make the code look neat and maintainable

User Exits in Sales order Management The user should have background of user exits which can be implemented to achieve custom functionality in sales order management

The standard Include MV45AFZZ contains the FORM routines which can be used to have write custom code to implement custom logic in sales order management. The user exits which you can use for modifications in sales document processing are listed below.

Listing few user exit routines which is mostly used by developer during sap implementation

USEREXIT_DELETE_DOCUMENT This user exit can be used for deleting data which was stored in a separate table during sales document creation, for example, if the sales document is deleted. For example, if an additional table is filled with the name of the person in charge (ERNAM) during order entry, this data can also be deleted after the sales order has been deleted. The user exit is called up at the end of the FORM routine BELEG_LOESCHEN shortly before the routine BELEG_SICHERN.

USEREXIT_MOVE_FIELD_TO_VBAK Use this user exit to assign values to new fields at sales document header level. It is described in the section "Transfer of the customer master fields into the sales document". The user exit is called up at the end of the FORM routine VBAK_FUELLEN.

USEREXIT_MOVE_FIELD_TO_VBAP Use this user exit to assign values to new fields at sales document item level. It is described in the section "Copy customer master fields into the sales document". The user exit is called up at the end of the FORM routine VBAP_FUELLEN.

USEREXIT_MOVE_FIELD_TO_VBEP Use this user exit to assign values to new fields at the level of the sales document schedule lines. The user exit is called up at the end of the FORM routine VBEP_FUELLEN.

USEREXIT_MOVE_FIELD_TO_VBKD Use this user exit to assign values to new fields for business data of the sales document. It is described in the section "Copy customer master fields into sales document" .The user exit is called up at the end of the FORM routine VBKD_FUELLEN.

USEREXIT_NUMBER_RANGE Use this user exit to define the number ranges for internal document number assignment depending on the required fields. For example, if you want to define the number range depending on the sales organization (VKORG) or on the selling company (VKBUR), use this user exit. The user exit is called up in the FORM routine BELEG_SICHERN.

USEREXIT_PRICING_PREPARE_TKOMK Use this user exit if you want to include and assign a value to an additional header field in the communication structure KOMK taken as a basis for pricing.

USEREXIT_PRICING_PREPARE_TKOMP Use this user exit if you want to include or assign a value to an additional item field in the communication structure KOMP taken as a basis for pricing.

USEREXIT_READ_DOCUMENT You use this user exit if further additional tables are to be read when importing TA01 or TA02. The user exit is called up at the end of the FORM routine BELEG_LESEN.

USEREXIT_SAVE_DOCUMENT Use this user exit to fill user-specific statistics update tables. The user exit is called up by the FORM routine BELEG-SICHERN before the COMMIT command.

USEREXIT_SAVE_DOCUMENT_PREPARE Use this user exit to make certain changes or checks immediately before saving a document. It is the last possibility for changing or checking a document before posting. The user exit is carried out at the beginning of the FORM routine BELEG_SICHERN.

Modularization When we have multiple Implementations for each user exit, it becomes very important to maintain the modularization for each implementation to keep the functionality separate and loosely coupled.  Create a Master Z Include in MV45ATZZ which will have Custom Includes for each implementation. Each enhancement implementation will be encapsulated in subroutine in each of these custom include. Each logical unit of processing should be written in subroutine which can be reused by other implementations if required. For example Currency conversion, quantity conversion. MV45ATZZ Z_MAIN_INCLUDE - Define global data declaration and common subroutines. Contains implementation specific subroutines Z_INCLUDE_IMP1  

Z_INCLUDE_IMP2

 

Z_INCLUDE_IMP3

Data Fetch Master data like sales organization, company code, material, reference order details are available in the standard program SAPMV45A. We don’t need to fetch this data from the database table again.

For example: 1)

TVKO-BUKRS contains the company code details

2) CVBAK, CVBAP, CVBEP contains the reference order , item and schedule line details respectively 3) VBAK, VBAP. VBEP structure contains the current order header, item schedule details respectively. 4) The Internal tables XVBAK, XVBAP, XVBEP contains the header, item , schedule line details of the order 5) The Internal tables YVBAK, YVBAP, YVBEP contains the old values of the header, item, schedule line details of the order. Note these tables have values only when corresponding original data is changed. 6) The Internal table XVBPA, YVBPA contains the partner function details of sales order (Current and Old value).

To get list of all the available global data in the program SAPMV45A, go in debugging mode and select ‘Global’ Tab Check whether the required data is available in SAPMV45A program. Only when the data is not available, do a database select to fetch the required data.  Check whether the selection condition values for database select are present at header Exit USEREXIT_MOVE_FIELD_TO_VBAK and try to fetch required data in this user exit. Try avoiding data select in user exits USEREXIT_MOVE_FIELD_TO_VBAP and USEREXIT_MOVE_FIELD_TO_VBEP because these perform are called for each line item and schedule item respectively. Performing database select is these routines are equivalent to select in a loop.  Always make a practice to check whether the data required for your enhancement is already fetched in other enhancement by checking main Include to avoid selecting same data again.  If the same processing /checks are required in sales order processing and during save of sales order, fetch the required data and store it in global variables and use it in user exit called during save of sales order. If the global variables are initial, then fetch the data from database.  Identify all the TVARVC entry to be fetched and have only one select from TVARVC in the user exit USEREXIT_MOVE_FIELD_TO_VBAK. Each enhancement implementation will read its corresponding entry from the internal table instead of own select on TVARVC.

Sales item and schedule line processing Generally we have requirements around processing some logic for each sales order item and schedule line items using the user exit USEREXIT_MOVE_FIELD_TO_VBAP, USEREXIT_MOVE_FIELD_TO_VBEP and USEREXIT_SAVE_DOCUMENT_PREPARE.

1) Avoid the nested loops on sales item and schedule line .If not possible use parallel cursor method to improve the performance .Copy the XVBAP and XVBEP internal table to local copy and sort the data by sales order number and sales item number. If ITAB1 has n1 entries and ITAB2 has n2 entries, the time needed for. The nested loop with the straightforward algorithm is O (n1 * n2), whereas the parallel cursor approach takes only O (n1 + n2) time. 2) Do not loop at item and schedule line table for each implementation, instead loop at these tables once and have subroutines for each implementation.

General Practice

LOOP AT XVBAP INTO LS_VBAP WHERE UPDKZ NE ‘D’ PERFORM IMPLEMENTATION 1 ENDLOOP

Good practice

LOOP AT XVBAP INTO LS_VBAP WHERE UPDKZ NE ‘D’ PERFORM IMPLEMENTATION 1 PERFORM IMPLEMENTATION 2

LOOP AT XVBAP INTO LS_VBAP WHERE UPDKZ NE ‘D’

PERFORM IMPLEMENTATION 3 ENDLOOP

PERFORM IMPLEMENTATION 2 ENDLOOP

3) When processing the internal table entries make sure you don’t process the entry which is marked for deletion. Generally in standard transaction, the data which is deleted from screen is not deleted from internal table. The record is marked with update indicator as ‘D’. Processing deleted records might cause inconsistency in the sap transaction.

4) Setting the update indicator: Generally when any data in these tables are changed due to custom logic for example XVBAP, we need to set the indicator as ‘U’, so that standard update knows that there has been some change in data and data has to be updated. Make sure to check whether the data exist in its corresponding Y structure (In this example YVBAP) before setting the indicator as ‘Update’. Incorrectly setting the value might cause inconsistency in sales order

Checking Transaction code

To perform certain logic for create /change mode of sales order, don’t check the sy-tcode with values ‘VA01’ or ‘VA02’. Use the following standard screen control structure T180. T180-TRTYP = ‘H’ means create mode T180-TRTYP = ‘V’ means change mode.

Capturing Custom message in BAPI Whenever we are adding the custom message in standard sales order processing, if the same message has to be captured in the BAPI return table we need to add the following code.

IF call_bapi = abap_true. PERFORM message_vbfs_aufbauen(sapfv45l) USING sy-msgid  

sy-msgno

 

sy-msgty

 

sy-msgv1

 

sy-msgv2

 

sy-msgv3

 

Space.

  ENDIF.

Parallel Processing Generally to automate the certain process with Sales order process we generally implement the user exit USEREXIT_SAVE_DOCUMENT_PREPARE to create subsequent documents during save of sales order. Calling the subsequent document creation in same LUW as sales order save will cause additional time in saving the sales order. To make the process independent of save of sales order, we can call the subsequent document creation in FM with BACKGROUND TASK or NEW TASK. The document creation will be called in different session independent of save of sales order. The application log can be updated to notify whether there was any error in creation of subsequent document creation.

Deleting a sales line item To delete a line item in the sales order, generally we update the indicator as ‘Delete’ in the table XVBAP. This could cause inconsistency because corresponding all other tables will not be updated accordingly. The standard routine XVBAP_LOESCHEN in program SAPFV45P can be called to delete the line item; this will take care of updating all the relevant structures and tables in sales order.

Adding Partner Function To add a partner function to the sales order, generally we update the table XVBPA table in user exit USEREXIT_MOVE_FIELD_TO_VBAP. This could cause issue sometimes if the update indicator is not updated correctly. Instead of manually inserting the entry in XVBPA [], we can use the FM used by standard to create/update partner function in sales order management. Standard FM SD_PARTNER_SINGLE_MODIFY and SD_PARTNER_DATA_GET can be called to update/insert partner function details. FM SD_PARTNER_SINGLE_MODIFY adds /updates the partner details to global memory GVT_LOCAL_MEMORY-XVBPA.FM SD_PARTNER_DATA_GET updates XVBPA from GVT_LOCAL_MEMORY-XVBPA

View more...

Comments

Copyright ©2017 KUPDF Inc.
SUPPORT KUPDF