list of user exits

[Former Member]

hai gurus,

can any body send me list of user exits used in sales and distribution and process ie how can we use them in application. points will be rewarded

thanks in advance,

[former_member204513 · Accepted solution]

Hi Bala,

Please go through this IMG path you can find the SD related user exits

SPRO>Sales and Distribution>System Modifications-->Use Exits here you can find all User Exits For SD area wise.

I hope it will help you,

Regards,

Murali.

[SmileZhang]

Dear Bala,

Up to now in sales processing you have been provided with user exits

in the form of Includes, which are no longer changed by SAP through

upgrades or Support Package imports. The Includes contain empty FORM

routines, which are called from within different points in delivery

processing. You can fill the FORM routines with your own source code to

process additional own data or to change sales data.

This note provides an overview of the call and the function of the

individual user exits. Bear in mind that only general recommendations

for the correct implementation of the user exits can be given here and

that SAP cannot assume any responsibility for the effects of the

implementation. If you need support, contact an experienced consultant

or contact the SAP Remote Consulting Service.

Carry out thorough tests of any of your own developments in user exits

before implementing them in your production system. Also check whether

your own developments have incorrect effects on less obvious functions

in the sales order such as the update of the statistics and change

documents or the structure of index tables such as VAKPA,VAPMA. Even if

the data of the sales document which is written to the database seems to

be correct, inconsistent internal tables can result in errors in the

update of the mentioned worklists.

Only use local structures for the selection result for database accesses

in the user exits. The use of the global structures defined in the sales

processing with TABLES can result in errors that are far-reaching and

that are difficult to understand.

General information on the internal tables of sales processing -

The most important data of the sales document is managed in coupled

internal tables: The internal table whose name starts with an X contains

the current data, including the last changes made by the user. Generally

the table with Y as the first letter of the name contains the database

status before the change. It is only significant in the change mode of

the sales document.

In general, the change indicator (UPDKZ) of the X or Y table states

whether the record is to be inserted (UPDKZ = 'I'), updated ('U') or

deleted ('D') in the database.

The following list is an overview on the most important internal tables

and structures of the delivery:

VBAK and XVBAK are the header lines of the current sales document. In

dialog processing, only structure VBAK contains the current status up to

the start of saving.

When saving, indicator XVBAK-UPDKZ states for each individual table

entry whether the respective header is to be inserted (UPKDZ = 'I'),

changed ('U') or deleted ('D'). The change indicator is SPACE if no

changes were made. Indicator XVBAK-UPDKZ is filled with 'U' when the

header is changed.

Structure YVBAK contains the database status of the sales header in

change mode. As of Release 4.6, table YVBAK is also filled in this case.

The internal table XVBAP contains the current status of the sales items.

The change indicator (XVBAP-UPDKZ) states whether the item is to be

inserted, changed or deleted (see above).

Items that were deleted or changed in change mode also appear in

table YVBAP, which represents the database status of the respective

items.

The item status of the individual delivery items is stored in internal

table XVBUP. The table also contains a change indicator in accordance

with the above-mentioned logic, however, entries to be deleted are

always removed directly from the table. Hence, change indicator 'D' does

not occur in XVBUP.

The original status of the item status data is stored in change mode in

table YVBUP. You can recognize items to be deleted by change indicator

YVBUP-UPDKZ = 'D'.

Similar to the item status, tables XVBUK and YVBUK contain the header

status information. The change indicator is used in accordance with the

same logic as for XVBUP and YVBUP so that change indicator 'D' does not

occur in table XVBUK either. Bear in mind that the header and item

status tables can also contain the status information of the supplied

preceding documents!

The document flow for the Sales order is stored in tables XVBFA and

YVBFA. Generally the document flow table also contains data from the

preceding documents.

The partners are stored in tables XVBPA and YVBPA. The change indicator

is managed like the status tables (no change indicator 'D' in XVBPA).

Determination of the processing status of the sales document:

Often it is necessary to distinguish between the different processing

statuses of the sales document because the exit is processed both during

the creation of sales documents and during changes. You can use the

following indicators to determine the processing status of the sales order:

Create, change or display?

Field T180-TRTYP has value 'H' in change mode, value 'V' when changing

and characteristic 'A' in display mode.

-

---

FORM routine USEREXIT_REFRESH_DOCUMENT (Include MV45AFZA)

Purpose

FORM routine USEREXIT_REFRESH_DOCUMENT is used for the initialization

of your own data areas before the processing of a new sales document.

Call

The routine is called from within the standard routine

BELEG_INITIALISIEREN(SAPMV45A).

Basically the data initialization is called on the following

occasions:

After sales documents have been saved .

In the dialog before the return to the initial screen with

functions 'Back' or 'Cancel' .

Data access

During the document initialization, the access to sales data may have

undefined results.

Output of messages

The output of error messages during the document initialization does

not make sense.

FORM routine USEREXIT_DELETE_DOCUMENT (Include MV45AFZZ)

Purpose

When a sales documentis deleted, you can delete your own dependent

data using this FORM routine.

Call

The FORM routine is called from FORM routine BELEG_LOESCHEN (SAPMV45A)

when the document can be deleted completely. Immediately after FORM

routine USEREXIT_DELETE_DOCUMENT is called, the document backup is

called for which the logically deleted sales document is removed from

the database.

Data access

You can access the sales document data that has already been deleted

logically within the FORM routine:

Structure VBAK contains the delivery header to be deleted.

The internal table XVBAP contains the current status of the

items to be deleted, including the last changes made by the user

before the deletion. All items have change indicator 'D'.

The internal table YVBAP contains the database status of all sales items

in this special case.

The internal table for item status XVBUP no longer contains any

items of the current sales document, the database status of the

item status can only be determined from internal table YVBUP.

In the internal table for the header status of sales document

XVBUK the entry still exists at this point but YVBUK has been

cleared .

The internal table with partner data XVBPA is also empty. The

database status of the partner data is in internal table YVBPA.

The internal tables of sales document processing must not be

manipulated in this exit under any circumstances so as to avoid

data inconsistencies.

Output of messages

The output of error messages and user dialogs is only possible with

restrictions in FORM routine USEREXIT_DELETE_DOCUMENT. No messages of

type E or W can be output. This results in runtime error

DYNPRO_MSG_IN_HELP as of Release 4.0.

Other notes

The deletion of the sales document can no longer be prevented at this

point by returning to the dialog, since all the sales data has already

been deleted logically. If the deletion of the sales document has to

be prevented by the user for certain reasons, an error message of type

A should be output.

FORM routine USEREXIT_READ_DOCUMENT (Include MV45AFZZ)

Purpose

The exit is intended to make your own data available for processing in

the sales document.

Call

The routine is processed exactly once after the sales document data

is read in the change or display mode of the document.

Data access

Within the exit you have full access to all the data of the delivery

that has just been imported. In principle it is possible for you in

this exit to already change the imported sales document data. For

this, consult the recommendations on changing document data in the

description of userexit USEREXIT_SAVE_DOCUEMENT_PREPARE.

Output of messages

There are no restrictions placed on the output of error messages and

user dialogs in this exit. However, consider that the exit is also

processed in the background:

FORM routine USEREXIT_MOVE_FIELD_TO_VBAK (Include MV45AFZZ)

Purpose

The exit is intended to supply your own additional fields of header

table VBAK with data.

Call

The FORM routine is processed exactly once during the creation of a

new document. FORM routine USEREXIT_MOVE_FIELD_TO_VBAK is always

called at the end of routines VBAK_FUELLEN (SAPMV45A);

Within the FORM routine you cannot yet access other data of the sales

document since this data is not yet available at that time.

However, when creating new sales documents with order reference, you

can access the data of the supplied order via internal tables CVBAK

(order header), CVBAP (order item), CVBPA (order partner) and CVBEP

(delivery schedules). When importing data from these tables, make sure

that the current header lines of the tables are not changed! Use local

structures instead.

If standard fields of structure VBAK are changed, determinations and

checks that have already been performed on these fields might have to be

carried out once again to avoid data inconsistencies.

Therefore analyze the dependencies before you change standard fields in

table VBAK in this exit.

Data from preceding documents should be transferred with preference via

the copy control.

You are advised against using the exit for manipulating other sales

document data, for instance for creating your own partners, since this

can have negative effects on the data consistency and the correct

functioning of the collective availability check.

Output of messages

The exit must not be used for the direct output of error messages.

However, messages of type I and E can be included in the sales document

creation log via FORM routine MESSAGE_HANDLING (main program SAPMV45A).

(If this routine is processed in change mode, messages are not output

directly but collected in the log). Messages of type W are not written

to the log.

FORM routine USEREXIT_MOVE_FIELD_TO_VBAP(Include MV45AFZZ)

Purpose

The routine is intended to supply your own additional fields of table

VBAP with data.

Call

The routine is processed exactly once per item during the creation of

sales document items. FORM routine USEREXIT_MOVE_FIELD_TO_VBAP is always

called at the end of routines VBAP_FUELLEN (creation of items with

predecessor reference) and VBAP_FUELLEN_OR (creation of items without

predecessor reference and creation of additional items in the delivery

such as batch split items or packaging items). When you create items

with predecessor reference, the routines of the copy control are called

before and after this user exit.

Data access

Within the exit you have access to the corresponding sales header

data (structure VBAK) and partner data of the sales doc. (XVBPA). No

status information is available yet for the new items. If, prior to the

current item, other items were already supplied in the same sales

document, you can access the header status of the sales doc. via table

XVBUK. The status of the items which were generated in the same

transaction or which already existed in the sales document can be read

from table XVBUP.

When you change standard fields of the item, note that checks and

determinations with reference to these fields may have already been

carried out and unchecked changes to these fields may result in data

inconsistencies. Therefore, analyze any possible dependencies before

making any changes to standard fields.

Note that the item number for the new item is already only assigned for

items without predecessor reference during the call of the exit.

It does not make sense to change other data of the sales document in

this exit. Here you should only access other data of the sales document

in read mode. Make sure that the current header lines of the internal

tables are not changed. Define local structures to read data from your

own internal sales documenty tables.

Output of messages

The direct output of messages is not allowed in this exit because this

can result in document inconsistencies. Instead, use FORM routine

MESSAGE_HANDLING (main program SAPMV45A), which, in change mode,

transfers messages of type E or I to the delivery processing log.

FORM routine USEREXIT_SAVE_DOCUMENT_PREPARE (Include MV45AFZZ)

Purpose

This routine is the most powerful exit in sales document processing and

can be used for the final change of all sales data. At the time of the

call, the sales document is complete and consistent, only the document

number has not yet been determined in the creation case. Therefore,

changes to the sales document at this time must be made with particular

care because no subsequent checks can prevent possible data

inconsistencies.

Call

This exit is called from routine BELEG_SICHERN (SAPMV45A) before sales

documents are saved .

Data access

Since the sales document is about to be saved, all relevant sales data

can be accessed. The current document status is to be found in the X

tables and the previous database status is to be found in the

corresponding Y tables. Take into account the following during the data

access:

The header lines of the internal tables may be changed in this exit.

Hence standard routines, which require a previous correct positioning of

the work areas, can also be called for processing.

Output of messages

With the output of messages or user dialogs you must make sure that this

exit can be processed both in the dialog and in the background.

FORM routine USEREXIT_SAVE_DOCUMENT (Include MV45AFZz)

Purpose

The routine is used to save your own data when saving sales documents.

Sales data cannot be changed here anymore since it has already been

transferred to the update.

Call

It is called when the document is saved (routine BELEG_SICHERN, program

SAPMV45A) immediately before the COMMIT WORK statement.

Data access

As in routine USEREXIT_SAVE_DOCUMENT_PREPARE, you can access all the

global data of the sales document. When you create the sales document,

the number of the sales document is now also known.

Never use your own COMMIT WORK or ROLLBACK WORK statements!

Output of messages

The output of messages or user dialogs is generally not allowed since a

COMMIT WORK is sent implicitly here. In serious cases processing can be

cancelled with a message of type 'A'.

You could also check it in IMG. By ctrl+F and entering User exits,you can check the userexits for all the process.

Hope it helps.

Regards,

Smile

[Former Member]

Hi Bala Krishna,

Please find below the complete stuff on Userexits:

Introduction

EXIT s are nothing but the R/3 Enhancements which allows you to add your own functionality to SAP’s standard business applications without having to modify the original applications.

1)Purpose

2)Use

3)Challenges

Purpose

To introduce the techniques of enhancement in standard SAP system. SAP creates customer exits for specific programs, screens, and menus within standard R/3 applications. These exits do not contain any functionality. Instead, the customer exits act as hooks. You can hang your own add-on functionality onto these hooks.

Use

They do not affect standard SAP source code.

When you add new functionality to your SAP System using SAP’s exits, you do not alter the source code of standard SAP programs in any way. The code and screens you create are encapsulated as separate objects. These customer objects are linked to standard applications, but exist separately from SAP’s standard software package.

They do not affect software updates.

When you add new functionality to your SAP System using SAP’s exits, your objects (called customer objects) must adhere to strict naming conventions. When it comes time to upgrade a to a new software release, customer objects’ names ensure that they will not be affected by any changes or new additions to the standard software package.

Challenges

Customer exits are not available for all programs and screens found in the SAP System.

What are modifications?

Any change made to an SAP object in a customer system is called a modification. Customers usually modify their systems for one of two reasons. Either they make changes to the SAP standard in order to adjust the R/3 System to their specific business needs (actual modifications), or they alter individual SAP objects in order to correct an error (as recommended in an SAP error note).

You should only modify the SAP standard if the modifications you want to make are absolutely necessary for optimizing work flow in your company. Be aware that good background knowledge of application structure and flow are important prerequisites for deciding what kind of modifications to make and how these modifications should be designed.

ABAP DICTIONARY

Table Enhancements: There are two ways that you can add additional fields to tables without modifying your system.

Append Structures:

Append structures allow you to enhance tables by adding fields to them that are not part of the standard. With append structures, customers can add their own fields to any table or structure they want.

Append structures are created for use with a specific table. However, a table can have multiple append structures assigned to it.

Customizing Includes:

If customers know in advance that one of the tables or structures delivered to them by SAP needs to have customer-specific fields added to it, an SAP application developer can include these fields in the table using a Customizing include statement.

The same Customizing include can be used in multiple tables or structures. This provides for consistency in these tables and structures whenever the itself include is altered.

Append structures allow you to attach fields to a table without actually having to modify the table itself.

Append structures may only be assigned to a single table. A table may, however, have several append structures attached to it. Whenever a table is activated, the system searches for all active append structures for that table and attaches them to the table. If an append structure is created or changed and then activated, the table it is assigned to is also activated, and all of the changes made to the append structure take effect in the table as well.

You can use append structures in ABAP programs just as you would any other structure.

Note: When you copy tables that have append structures attached to them, the fields that were found in the append structure of the original table become part of the actual body of the target table.

Some of the tables and structures delivered with the R/3 standard contain special include statements calling Customizing includes. These are often inserted in those standard tables that need to have customer-specific fields added to them.

In contrast to append structures, Customizing includes can be inserted into more than one table. This provides for data consistency throughout the tables and structures affected whenever the include is altered.

Customizing include programs are part of the customer namespace: all of their names begin with 'CI_'. This naming convention guarantees that nonexistent Customizing includes do not lead to errors. No code for Customizing includes is delivered with the R/3 standard.

You create Customizing includes using special Customizing transactions. Some are already part of SAP enhancements and can be created by using project management (see the unit on 'Enhancements using Customer Exits').

The Customizing include field names must lie in the customer namespace just like field names in append structures. These names must all begin with either 'YY' or 'ZZ'.

When adding the fields of a Customizing include to your database, adhere to same rules you would with append structures.

Field Exits:

Field exits take you from a screen field with a data element reference to a function module. Field exits can be either global or local.

Field exit function modules adhere to the following naming convention:

prefix: FIELD_EXIT_

name: <data element name>_

suffix (optional): 0 to 9, A to Z

Global field exits are not limited to a particular screen. If a global field exit's data element is used on multiple screens, you will branch to a function module from all of these screens once the exit has been activated. Here you can, for example, edit the contents, force a new entry to be made by outputting an error message, or prohibit certain users from proceeding further.

Local field exits are valid for one screen only. If you assign a screen from a specific program to the data element, then you will only branch to a function module from this screen once the exit has been activated. To be able to allow different functionality on different screens referring to the same data element, you can assign exit numbers to data elements. Each exit number refers to a different function module.

Text Enhancements:

Possible text enhancements include customer keywords and customer documentation of data elements.

Text enhancements differ from other application enhancements in that they take effect globally in all related SAP applications after activation (global enhancements).

Possible text enhancements include customer keywords and customer documentation of data elements.

Text enhancements differ from other application enhancements in that they take effect globally in all related SAP applications after activation (global enhancements).

Use the project management function to edit text enhancements.

Just as with field exits, use the menu entry Global enhancements to access the enhancement functions for keywords and data element documentation

SAP application programmers define keywords in different lengths and a short description for each data element. Use the project management function (transaction CMOD) to change these keywords and short texts.

All screen fields that use the keyword text of data elements can be renamed in this manner.

A new short text in a data element will show up in the F1 help of the screen field.

In order for keyword changes to take effect on a screen, SAP application programmers have to maintain the MOD attribute (keyword modification indicator) of the affected field accordingly in the Screen Painter field list.

The MOD attribute must have one of the following values:

SPACE: the keyword that best fits the field length 1: short keyword 2: medium keyword 3: long keyword 4: keyword for header V: variable text transfer from the ABAP Dictionary F: fixed, no text transfer

If the attribute contains an 'F', it is fixed on the screen and cannot be modified. In all other cases, screens that refer to that particular data element will show the changed keyword.

Application enhancements allow customers to enhance their application functions. Customer exits are preplanned by SAP and generally consist of several components.

Application enhancements are inactive when delivered and can be completed and activated by customers as they are needed.

Application enhancement characteristics:

Each enhancement provides you with a set of preplanned, precisely defined functions.

Each interface between SAP and customer functions is clearly defined.

As a customer, you do not need in-depth knowledge of how to implement SAP applications.

You do not need to adjust enhancements at upgrade because of new functions that SAP has developed.

Customer Enhancement Projects

SAP application programmers create SAP enhancements in transaction SMOD using function module exits, menu exits, and screen exits.

Customers are given a catalog containing an overview of existing SAP enhancements. They can then combine the SAP enhancements they want into an enhancement project using transaction CMOD.

SAP enhancements are made up of component parts. These components include function module exits, menu exits, and screen exits. A specific component may be used only once in a single SAP enhancement (this guarantees the uniqueness of SAP enhancements).

Customer enhancement projects consist of SAP enhancements. Each individual SAP enhancement may be used only once in a single customer enhancement program (this guarantees the uniqueness of a customer project).

SAP application programmers preplan function module exits, menu exits, and screen exits for their applications and combine them to create useful enhancements for the R/3 System.

Customers create their own enhancement projects for their systems using SAP enhancements. You can customize the individual components of an enhancement project by creating your own include programs (for function module exits), texts (for menu exits), and subscreens (for screen exits).

Customer Exits

1)Function Module Exits

2)Menu Exits

3)Screen Exits

Function Module Exits

Function module exits add functions to R/3 applications. Function module exits play a role in both menu and screen exits. When you add a new menu item to a standard pull down menu, you use a function module exit to define the actions that should take place once your menu is activated. Function module exits also control the data flow between standard programs and screen exit fields.

Menu Exits

Menu exits add items to the pull down menus in standard SAP applications. You can use these menu items to call up your own screens or to trigger entire add-on applications.

SAP creates menu exits by defining special menu items in the Menu Painter. These special entries have function codes that begin with "+" (a plus sign). You specify the menu item’s text when activating the item in an add-on project.

Screen Exits

Screen exits add fields to screens in R/3 applications. SAP creates screen exits by placing special sub screen areas on a standard R/3 screen and calling a customer sub screen from the standard screen’s flow logic.

Implementation of Enhancement in Customer System

First, use the project management function to choose the SAP enhancements that you want and create an enhancement project.

Next, edit your individual components using the project management function and document the entire enhancement project.

Finally, activate the enhancement project (this activates all of the project's component parts).

Start the project management function (transaction CMOD) and give your enhancement project a name. SAP recommends that you think up a naming convention for all of your projects. You can, for example, include the project's transaction or module pool in its name. All enhancement project names must be unique. Next, branch to the project's attributes and enter a short text describing the enhancenent project. The system inserts all of the project's other attributes (such as created by, created on, or status).

Assigning SAP Enhancement to customer projects

Use the project management function (transaction CMOD) to assign SAP enhancements to customer enhancement projects. Enter the names of the SAP enhancements you want to use on the appropriate screen.

The search function gives you a catalog-like overview of existing SAP enhancements. From there you can select those enhancements that are of interest to you.

Editing Components

Activating Enhancement Projects

Use the product management function to edit the components of your enhancement project.

Depending on whether the component you are editing is a function module, a menu entry, or a subscreen, you branch to either the Function Builder, a dialog box for entering menu entries, or to the Screen Painter.

Activation of an enhancement project affects all of its components. After successful activation, the project has the status active.

During activation, all programs, screens, and menus containing components that belong to the project are regenerated (programs at the time they are executed). After activation, you can see the enhancements in your application functions.

The Deactivate function allows you to reset an enhancement project's status to inactive.

Business Transaction Events

It is also called as Open FI enhancement technique which is based on the following principle:

Application developers must define their interface in a function module. An assignment table is read in the corresponding (generated) code, and the customer modules assigned are called dynamically.

This technique differentiates between enhancements that are only allowed to have one implementation and enhancements that can call multiple implementations in any sequence desired. Both industry-specific and country-specific enhancements may be defined.

Enhancement Framework

The new enhancement concept of the ABAP Workbench enables the integration of different concepts for modifying and enhancing development objects. The enhancement concept is supported by the Enhancement Builder tool and ABAP language elements.

The objective of the Enhancement Framework is to provide a technology to create modification-free enhancements and to unify all possible ways of modifying or enhancing Repository objects.

Multilayer Support

In contrast to modifications with enhancements it becomes possible to have

enhancements on different development levels, e.g.

u2022 Core development

u2022 Application development

u2022 Add on development

u2022 Customer development

It is possible to create multiple enhancement implementations on different layers or

to replace an enhancement implementation.

Enhancement Spots

Enhancement Spots can only be of type source code Enhancement or BAdI.

Enhancement Spots manage explicit Enhancement Options

While implicit enhancement options always exist and do not require any special management, explicit enhancement options created in an initial system must be made known to developers in target systems via Enhancement Spots.

Enhancement Implementations

Enhancement implementations manage their enhancements.

Enhancements made by developers in follow-on systems are managed as Enhancement Implementations. This applies to all enhancement options, both explicit and implicit

User exits (Function module exits) are exits developed by SAP. The exit is implementerd as a call to a functionmodule. The code for the function module is writeen by the developer. You are not writing the code directly in the function module, but in the include that is implemented in the function module.

The naming standard of function modules for functionmodule exits is:

EXIT_<program name><3 digit suffix>

The call to a functionmodule exit is implemented as:

CALL CUSTOMER.-FUNCTION ❤️ digit suffix>

Example:

The program for transaction VA01 Create salesorder is SAPMV45A

If you search for CALL CUSTOMER-FUNCTION i program

SAPMV45A you will find ( Among other user exits):

CALL CUSTOMER-FUNCTION '003'

exporting

xvbak = vbak

xvbuk = vbuk

xkomk = tkomk

importing

lvf_subrc = lvf_subrc

tables

xvbfa = xvbfa

xvbap = xvbap

xvbup = xvbup.

The exit calls function module EXIT_SAPMV45A_003

2. How to find user exits?

Display the program where you are searching for and exit and search for CALL CUSTOMER-EXIT

If you know the Exit name, go to transaction CMOD.

Choose menu Utillities->SAP Enhancements. Enter the exit name and press enter.

You will now come to a screen that shows the function module exits for the exit.

3. Using Project management of SAP Enhancements, we want to create a project to enahance trasnaction VA01 .

u2022 Go to transaction CMOD

u2022 Create a project called ZVA01

u2022 Choose the Enhancement assign radio button and press the Change button

In the first column enter V45A0002 Predefine sold-to party in sales document.

Note that an enhancement can only be used in 1 project. If the enhancement is already in use, and error message will be displayed

Press Save

Press Components. You can now see that enhancement uses user exit EXIT_SAPMV45A_002. Double click on the exit.

Now the function module is displayed. Double click on include ZXVVAU04 in the function module

Insert the following code into the include: E_KUNNR = '2155'.

Activate the include program. Go back to CMOD and activate the project.

Goto transaction VA01 and craete a salesorder.

Note that Sold-to-party now automatically is "2155"

Following list will be useful to you.

Sales realated exits

SDTRM001 Reschedule schedule lines without a new ATP check

V45A0001 Determine alternative materials for product selection

V45A0002 Predefine sold-to party in sales document

V45A0003 Collector for customer function modulpool MV45A

V45A0004 Copy packing proposal

V45E0001 Update the purchase order from the sales order

V45E0002 Data transfer in procurement elements (PRreq., assembly)

V45L0001 SD component supplier processing (customer enhancements)

V45P0001 SD customer function for cross-company code sales

V45S0001 Update sales document from configuration

V45S0003 MRP-relevance for incomplete configuration

V45S0004 Effectivity type in sales order

V45W0001 SD Service Management: Forward Contract Data to Item

V46H0001 SD Customer functions for resource-related billing

V60F0001 SD Billing plan (customer enhancement) diff. to billing plan

V46H0001 SD Customer functions for resource-related billing

V45W0001 SD Service Management: Forward Contract Data to Item

V45S0004 Effectivity type in sales order

V45S0003 MRP-relevance for incomplete configuration

V45S0001 Update sales document from configuration

V45P0001 SD customer function for cross-company code sales

V45L0001 SD component supplier processing (customer enhancements)

V45E0002 Data transfer in procurement elements (PRreq., assembly)

V45E0001 Update the purchase order from the sales order

V45A0004 Copy packing proposal

V45A0003 Collector for customer function modulpool MV45A

V45A0002 Predefine sold-to party in sales document

V45A0001 Determine alternative materials for product selection

SDTRM001 Reschedule schedule lines without a new ATP check

SDAPO001 Activating Sourcing Subitem Quantity Propagation

Billing related exits

SDVFX007 User exit: Billing plan during transfer to Accounting

SDVFX008 User exit: Processing of transfer structures SD-FI

SDVFX009 Billing doc. processing KIDONO (payment reference number)

SDVFX010 User exit item table for the customer lines

SDVFX011 Userexit for the komkcv- and kompcv-structures

V05I0001 User exits for billing index

V05N0001 User Exits for Printing Billing Docs. using POR Procedure

V60A0001 Customer functions in the billing document

V60P0001 Data provision for additional fields for display in lists

V61A0001 Customer enhancement: Pricing

Delivery related exits

V50PSTAT - Delivery: Item Status Calculation

V50Q0001 - Delivery Monitor: User Exits for Filling Display Fields

V50R0001 - Collective processing for delivery creation

V50R0002 - Collective processing for delivery creation

V50R0004 - Calculation of Stock for POs for Shipping Due Date List

V50S0001 - User Exits for Delivery Processing

V53C0001 - Rough workload calculation in time per item

V53C0002 - W&S: RWE enhancement - shipping material type/time slot

V53W0001 - User exits for creating picking waves

VMDE0001 - Shipping Interface: Error Handling - Inbound IDoc

VMDE0002 - Shipping Interface: Message PICKSD (Picking, Outbound)

VMDE0003 - Shipping Interface: Message SDPICK (Picking, Inbound)

VMDE0004 - Shipping Interface: Message SDPACK (Packing, Inbound)

V02V0001 - Sales area determination for stock transport order

V02V0002 - User exit for storage location determination

V02V0003 - User exit for gate + matl staging area determination (headr)

V02V0004 - User Exit for Staging Area Determination (Item)

User Exits For Price Determination

USEREXIT_PRICING_PREPARE_TKOMK (module pool SAPLV60A, program RV60AFZZ)

This user exit allows you to copy additional fields for pricing in the TKOMK communication structure (header fields), which have not been provided in the standard SAP system. These fields can also be used for pricing in the billing document.

This user exit is described in detail in the "New fields in pricing" section.

USEREXIT_PRICING_PREPARE_TKOMP (module pool SAPLV60A, program RV60AFZZ)

This user exit allows you to copy additional fields for pricing in the TKOMP communication structure (item fields), which have not been provided in the standard SAP system. These fields can also be used for pricing.

This user exit is described in detail in the "New fields in pricing" section.

USEREXIT_FIELD_MODIFICATION (module pool SAPMV61A, program MV61AFZA)

You can use this user exit to adjust the display of individual lines in the condition screen by changing the display attributes of the screen fields. This does not include the display of subtotals.

This user exit is also used in order processing.

USEREXIT_FIELD_MODIFIC_KZWI (module pool SAPMV61A, program MV61AFZB)

You can change the display of subtotals in the condition screen by changing the display attributes of the screen fields.

This user exit is also used in order processing.

USEREXIT_FIELD_MODIFIC_KOPF (module pool SAPMV61A, program MV61AFZB)

You can adjust the display of subtotals in the condition screen to your requirements by changing the display attributes of the screen fields.

This user exit is also used in order processing.

USEREXIT_FIELD_MODIFIC_LEER (module pool SAPMV61A, program MV61AFZB)

You can adjust the display of blank lines in the condition screen to your requirements by changing the display attributes of the screen fields.

This user exit is also used in order processing.

USEREXIT_PRICING_CHECK (module pool SAPMV61, program MV61AFZA)

You can install additional checks to the standard checks of condition lines (e.g. maximum/minimum value).

USEREXIT_PRICING_RULE (module pool SAPLV61A, program RV61AFZA)

In the standard SAP system, it is predefined which condition categories and classes can be copied or recalculated per pricing type. You can change the predefined standard procedure for each pricing type.

USEREXIT_CHANGE_PRICING_RULE (module pool SAPMV61A, program MV61AFZA)

You can use this user exit to change the pricing type that has been predefined in the copying control table in billing.

USEREXIT_XKOMV_BEWERTEN_INIT (module pool SAPLV61A, program RV61AFZB)

This field is used in the formulas and therefore initialized before the loop for the pricing procedure starts.

USEREXIT_XKOMV_BEWERTEN_END (module pool SAPLV61A, program RV61AFZB)

Within a loop for the price components during pricing, specific values can be transferred into the communication structures in pricing to be further processed.

USEREXIT_XKOMV_ERGAENZEN (module pool SAPLV61A, program RV61AFZB)

In change mode, you can change the dynamic part of the condition record (KONVD) that is always redetermined (i.e. it is not stored in database table KONV).

USEREXIT_XKOMV_ERGAENZEN_MANU (module pool SAPLV61A, program RV61AFZB)

You can use this user exit to change the ready-for-input fields of the manually entered condition record in add mode in the condition screen.

USEREXIT_XKOMV_FUELLEN (module pool SAPLV61A, program RV61AFZB)

This user exit is always called up during a redetermination of all or individual price components. You can change the work fields of the condition line. However, this only applies to conditions that have been determined via a condition record.

USEREXIT_XKOMV_FUELLEN_O_KONP (module pool SAPLV61A, program RV61AFZB)

This user exit is always called up during a redetermination of all or individual price components. You can change the work fields of the condition line. However, this only applies to conditions that have been determined via a condition record. This may include subtotals, manually entered conditions or conditions that have been calculated with a formula.

USEREXIT_PRICING_COPY (module pool SAPLV61A, program RV61AFZA)

You can change the KONV fields for copied price components.

User Exits for Partner Determination

Partner determination contains the following user exits for your use:

EXIT_SAPLV09A_001

You can use this user exit to control whether an address that was entered manually and has already been used in other documents (referenced), should be referenced again if it changes or whether a new address shold be created (duplicated).

EXIT_SAPLV09A_002

Call up this user exit if a customer has not been maintained in the current sales area.

EXIT_SAPLV09A_003

Use this user exit to control the origin of partners in the partner determination procedure (origin X, Y or Z). If X, Y, or Z has been entered in the Origin field, this user exit is automatically called up during partner determination.

EXIT_SAPLV09A_004

Use this user exit to integrate your own check in a program, that runs before the partner is saved in the document.

For more detailed information, see the program documentation for each ofthe user exits.

User Exits For Credit Checks And Risk Management

Credit Check

If you want to carry out your own individual credit checks, that differ from those in the standard system, you must define them in the following user exits:

LVKMPTZZ

LVKMPFZ1: USER_CREDIT_CHECK1

LVKMPFZ2: USER_CREDIT_CHECK2

LVKMPFZ3: USER_CREDIT_CHECK3

User exit for availability check

User exit USEREXIT_AVAIL_CHECK_CREDIT exists in Include MV45AFZF.

This user exit allows you to determine whether the system should or should not carry out an availability check after a blocked document has been released or after a new credit check.

Risk Management for Receivables

RVKMPUS2

Please Reward If Relly Helpful

Thanks and Regards

Sateesh.Kandula