HOW TO FIND USER EXIT IN SAP SD

SAP user exit can be found in number of ways:

1) To find user exit in SD module , goto object navigator(SE80) and select

development class from the list and enter VMOD in it. All of the userexits in SD are contained in the development class VMOD. Press

enter and you will find all the includes which contain userexits in SD for

different functions like PRICING, ORDER PROCESSING etc. Select the userexit according to the requirement and read the comment inserted in it

and start coding .

Some examples of userexits in SD(SALES & DISTRIBUTION ) are:

1)ADDING OF NEW FIELDS IN PRICING

In Pricing in SD the fields on the basis of which pricing is done are derived from the FIELD CATALOG which is a structure KOMG .This structure is used to transfer transaction data to the pricing procedure in SD and is also known as communication structure.This structure KOMG consists of two tables KOMK for Header related fields and KOMP for item related fields.

The fields which are not in either of the two tables KOMK and KOMP

cannot be used in pricing .Sometimes a need arises when the pricing

is to be based on some other criteria which is not present in the form of fields in either of the two tables.

This problem can be solved by using USEREXITS which are provided for pricing in SD.

Pricing takes place both when the SALES ORDER ( Transaction VA01) is created as well as when INVOICING ( Transaction VF01) is done.Hence SAP provides 2 userexits ,one for sales order processing which is

USEREXIT_PRICING_PREPARE_TKOMP or

USEREXIT_PRICING_PREPARE_TKOMK

Depending upon which table (KOMK or KOMP) the new fields were inserted we use either of the above two userexits.These userexits are found in include MV45AFZZ of the standard SAP sales order creation program SAPMV45A.

In the case of userexit which will be called when invoicing is done ,these

are provided in the include RY60AFZZ which is in the standard SAP

program SAPMV45A. The name of the userexits are same. i.e

USEREXIT_PRICING_PREPARE_TKOMP or

USEREXIT_PRICING_PREPARE_TKOMK

These userexits are used for passing the data from the communication structure to the pricing procedure, for this we have to fill the newely

created field in the communication structure KOMG for this we fill the code in the above userexit using the MOVE statement after the data that

has to be passed is taken from the database table by using the SELECT statement. The actual structure which is visible in these userexits and which is to be filled for that particular field is TKOMP or TKOMK.

Before the coding for these userexits is done ,it is necessary to create a new field in either of the two tables KOMK or KOMP .For this purpose

includes are provided in each of them .

To create the field in header data(KOMK) the include provided is KOMKAZ

and to create the field in item data(KOMP) the include provided is KOMPAZ.

One possible example for the need of creating new fields can be e.g. Frieght to be based upon transportation zone ,for this no field is available in field catalog and hence it can be created in KOMK and then above userexits can be used to fill the transportation data to it.

2)The other method of finding userexit is to find the word USEREXIT in the

associated program of the transaction for which we want to determine userexit using SE38.

3)The other method of finding userexits is to find the include in case of SD/MM applications where the userexits are located ,this can be found in the SAP reference IMG generally in the subfolder under SYSTEM MODIFICATION.

Some other examples of userexits in SD are:

USEREXIT_NUMBER_RANGE

This userexit is used to assign a different internal document number to the

sales order(VA01) when it is created depending on some criteria like a different SALES ORGANIZAION(VKORG) .

USEREXIT_SAVE_DOCUMENT_PREPARE

This userexit is used to insert the ABAP code which will be called when

the document (sales order VA01) is just about to be saved.This userexit is used generally for custom checks on different fields , to display some information before the order will be saved or for making changes to certain fields before the sales order will be saved.

Exits & Enhancements

There are mainly six types of EXITs in sap which have been collected in the form of enhancement packages and attached to standard code in SAP.

These are different from USEREXIT in the way that they are implemented

in the form of FUNCTIONs while in USEREXITS we use form routines for their implementation. These are also sometimes known as function exits .

These start from the word EXIT_ followed by the program name and then followed by a three digit number.

e.g. EXIT_SAPMV45A_002

This exit is found in SD in enhancement V45A0002.

TYPES OF EXITS

1)MENU EXITS

2)FUNCTION EXITS

3)TABLE EXITS

4)SCREEN EXITS

5)KEYWORD EXITS

6)FIELD EXITS

We use SAP transactions CMOD and SMOD to manage exits. Before implementing an exit , it is required to create the project by using CMOD

selecting the enhancement e.g. V45A0002 and selecting the component

(one which fulfills our need) i.e the exit which will be implemented in SMOD and after coding has been done the project has to be activated.

An exit can be coded only once.

FUNCTION EXITS

These are used to add functionality through ABAP code . These start from the word EXIT_programname_NNN ending in a 3 digit number. No access code is required to implement any tupe of exit including function exits.

The function exits are called from the standard SAP program in the form

of ABAP statement

CALL CUSTOMER-FUNCTION ‘NNN’

This is in contrast to USEREXITs where PERFORM statement is used to call

the required userexit.

To implement the FUNCTION EXITs first of all the project is created and a suitable enhancement package is selected and from its compnents the function exit to be implemented is selected and on double clicking it the exit code will appear in ABAP EDITOR(se38) where a Z include will be found and the customer code should be entered in this include.

e.g.

ADDING A DEFAULT SOLD-TO-PARTY in Sales Order Creation

To show a default sold-to-party in this field when the user creates a sales order (VA01) we can use a function exit .This function exit is located

in enhancement no V45A0002 . Before we can choose the exit we have to

create a project in CMOD after that enter V45A0002 in the enhancement field and click on the components . In the components you will see the

exit EXIT_SAPMV45A_002 . This exit is used for our purpose.

Double clicking on this exit will takes us to function builder (SE37) . This

function exit has one exporting parameters and two importing parameters, we are interested in exporting parameter which is E_KUNNR

of type KNA1-KUNNR i.e if we move the desired customer name to this

structure(E_KUNNR) it will be shown in the field as the default value when we create the sales order.

This function also contains a customer include ZXVVA04 . This include

will be used to write our custom code .

Double clicking on this include and it will prompt us that this include does not exists do you want to create this object ,select yes and the include will be created .In this include we can write our own code that will fill the field E_KUNNR.

e.g. E_KUNNR = 301.

Activate the include and Activate the project. Now when ever the SALES ORDER will be created , sold-to-party field will come up with a predefined

customer .

FIELD EXITS

The field exits are managed,created,activated through program RSMODPRF. The field exit is associated with a data element existing in ABAP dictionary and hence to the screen field using that data element.

The format of field exit is :

FIELD_EXIT_dataelement_A-Z or 0-9

If a particular screen and program name is not specified than the field exit will effect all the screens containing that data element.

The function module associated with field exit shows two parameters

INPUT and OUTPUT. Input parameter contains the data passed to the field exit when the field exit was invoked by the R/3 , We can write our own code to change the output parameter depending upon our requirements.

Before the field exit can have any effect the system profile parameter

ABAP/FIELDEXIT in all the application servers should be set to YES

ABAP/FIELDEXIT = YES.

As in sap.niraj.tripod.

SD REPORTS:
Reports: Reports consist of data, which is expected to be reveiwed or checked the transaction taken in said period. Reports are useful for analysis of decision taking for future activities.

Some of the standard reports for SD & its configuration guide is as under:
Standard SAP SD Reports:=

Statistic Group:
Purpose – To capture data for Standard Reports, we require to activate Statistic Group as under:
–> Item category (Configuration)
–> Sales document type (Configuration)
–> Customer (Maintain in Master data)
–> Material (Maintain in Master data)
When you generate statistics in the logistics information system, the system uses the combination of specified statistics groups to determine the appropriate update sequence. The update sequence in turn determines for exactly which fields the statistics are generated.

Configuration:
IMG –> Logistics Information System (LIS) –> Logistics Data Warehouse –> Updating –> Updating Control –> Settings: Sales –> Statistics Groups –>
1. Maintain Statistics Groups for Customers
2. Maintain Statistics Groups for Material
3. Maintain Statistics Groups for Sales Documents
4. Assign Statistics Groups for Each Sales Document Type
5. Assign Statistics Groups for each Sales Document Item Type…..

All Standard Reports which are available are as under:
SAP Easy Access: Information Systems -> Logistics -> Sales and distribution ->
1. Customer -> Incoming orders / Returns / Sales / Credit memos / Sales activities / Customer master / Conditions / Credit Master Sheet
2. Material -> Incoming orders / Returns / Sales / Credit memos / Material master / …
3. Sales organization -> Sales organization / Sales office / Sales employee
4. Shipping point -> Deliveries / Returns
5. SD documents -> Orders / Deliveries / Billing documents …
& so on.

Sales summary – VC/2
Display Customer Hierarchy – VDH2
Display Condition record report – V/I6
Pricing Report – V/LD
Create Net Price List – V_NL
List customer material info – VD59
List of sales order – VA05
List of Billing documents – VF05
Inquiries list – VA15
Quotation List – VA25
Incomplete Sales orders – V.02
Backorders – V.15
Outbound Delivery Monitor – VL06o
Incomplete delivery – V_UC
Customer Returns-Analysis – MC+A
Customer Analysis- Sales – MC+E
Customer Analysis- Cr. Memo – MC+I
Deliveries-Due list – VL04
Billing due list – VF04
Incomplete Billing documents – MCV9
Customer Analysis-Basic List – MCTA
Material Analysis(SIS) – MCTC
Sales org analysis – MCTE
Sales org analysis-Invoiced sales – MC+2
Material Analysis-Incoming orders – MC(E
General- List of Outbound deliveries – VL06f
Material Returns-Analysis – MC+M
Material Analysis- Invoiced Sales – MC+Q
Variant configuration Analysis – MC(B
Sales org analysis-Incoming orders – MC(I
Sales org analysis-Returns – MC+Y
Sales office Analysis- Invoiced Sales – MC-E
Sales office Analysis- Returns – MC-A
Shipping point Analysis – MC(U
Shipping point Analysis-Returns – MC-O
Blocked orders – V.14
Order Within time period – SD01
Duplicate Sales orders in period – SDD1

Concepts

Every organization’s Sales is structured in a certain way. This structure needs to be represented in SAP based on pre-defined organizational elements and combine them in a pre-defined way. This method of representing all the different organizational elements of the company in a structured way is called Enterprise Structure. Organizational elements or Org Units for short are a system representation of an actual company organizational unit. For example, an org unit in real life could be a particular product division , or a Sales Office in Seattle, or a manufacturing plant in Boston or a warehouse in Alabama. The following picture shows how an enterprise structure is created in SAP.

Instead of discussing the text book definitions of these organizational units, let’s take a company in real life and discuss the same. However, please do note the cardinality. For example, a company can be linked to multiple company codes as shown in the beginning of the picture above. Let’s take the example of General Electric Healthcare ( or GE Medicals ) and discuss the enterprise structure in detail. We have taken GE just as an example, and this enterprise structure in no way represents GE’s internal structure. In fact, GE Healthcare does not even use SAP as its ERP.

Before discussing the same, let’s look at another pictorial representation of the same picture as above – but with GE’s org units.

Configuration

The configuration for the enterprise structure is very simple. The Menu path is [ SPRO -> IMG -> Enterprise Structure ]

Definition:

The first step before doing the configuration is to assess the requirement as to how the company is organized and how best it can be represented in SAP. Each company is run in a different way. Since SAP’s enterprise structure is rigid, you might have to try different things to fit their organization’s model into SAP’s org structure. After you have fully understood the organizational units in the company, start by defining those in SAP. The following picture shows the path of the enterprise structure definition in IMG. While the Company and company codes are defined by FICO consultants, the ones highlighted in red below are absolutely necessary for the functioning of the SAP Sales & Distribution Module.

In normal practice, organization units are normally copied from 0001 . While creating a new organizational unit is easy, there are many associated links in the background that are normally not easy to understand. So it’s always best to copy from 0001. Let’s see an example of how to create a new sales organization.

Click on Define, copy, delete, check Sales Organization under the Sales and Distribution section. Choose the option highlighted below.

Enter the copy button and choose the “From” and “To” sales organizations.

Enter 0001 as the source and target for example is WEST. Thats it and you are done.

Organizational units can be defined in a similar way for the rest of them.

Assignment :

After defining the org elements, we have to assign them to each other to make a meaningful representation of the company’s organizational units. The menu path is [ SPRO -> IMG -> Enterprise Structure -> Assignment ]. Let’s set up a sales area by assigning a distribution channel and division to the sales organization, just as an example. Select “Set up Sales Area”. However, if you are trying to create a sales area with the combination of WEST sales organization that you just created along with a distribution channel of 01 and a division of 01, you will see an error as shown below. The reason being that when WEST sales organization was copied with reference to the sales organization 0001, the assignments were also copied. This is just one of the default assignment – there are many more. So to be on the safer side, its better to copy it and delete all the necessary assignments rather that start from scratch. Otherwise, this is how assignments are created. Assignments can be made similarly based on our first illustration to all other organizational units based on your requirements.

By: magnatraining.com

Introduction

Each document is either created on its own or created with reference to another document. For example, a sales order can be created with reference to the quotation, whereas the quotation itself can be created on its own. The following diagram illustrates all the possible document flows in SAP.

Transaction Codes Tip: The transaction codes can for the respective document flow configuration transactions can be easily identified by visualizing the picture below. If ‘A’ stands for Sales documents , ‘L’ stands for Deliveries and ‘F’ stands for Billing documents, then the transaction for configuring the Sales document to the delivery document is VTLA. So it is VTXY with X as the target document and Y as the source document.

Let’s see some examples of different types of document flow using examples of standard commonly used sales scenarios.

Sales-to-Sales Document Flow : For example you can create a Sales Order from a Contract or a Quotation.

Sales-to-Delivery Document Flow : For example you can create a standard or a rush delivery from an order. Similarly you can create a consignment delivery from a consignment.

Delivery-to-Billing Document Flow : A standard invoice is created with reference to a delivery.

Billing-to-Billing Document Flow : Invoice cancellations are typically done with respect to the original invoice.

Billing-to-Sales Document Flow : In case of debit memo requests or credit memo requests, the original invoice is used as a reference document.

Without going further, let’s dig a little deeper into the concept of “Reference”. Whenever we mean a document is referencing another document, this means that information is copied over from the previous document into the subsequent document. What is the need for information to be copied over..? There are many reasons for this. For example, this reduces burden on the person entering the subsequent document. Also, this ensures that information is accurately copied over without mistakes.

Let’s take an example. A customer has called us and asked for a quotation. Our sales force has responded with a quotation.

The quotation could contain a bunch of data like who the customer is, his/her internal number with us, date of the quotation, date valid until, prices, discounts, surcharges, taxes, materials, quantity etc.

The customer then places an order referring to the prices in the quote.

During the process of creating the order referring to the quotation a bunch of date needs to be copied. Example data could include prices, customer data, materials and quantity, discounts given etc. In order to do these efficiently copy control routines are used. Copy control configuration is also part of the document flow.

Configuration:

Let’s look at the configuration for a Quotation to a sales order. The rest of the configuration ( Order to delivery , delivery to billing etc ) are very similar.

Menu Path is SPRO -> IMG -> Sales and Distribution -> Sales -> Maintain Copy Control for Sales Documents

Double click on Sales to Sales copy controls.

Select the row corresponding to QT ( Quotation ) as the source document and OR ( Standard Order ) as the target document.

You will be presented with a screen that contains a bunch of numbers. These are either data transfer routines or copy requirements.

Data Transfer Routines : These routines are pieces of code that are either standard or custom written where the logic to transfer the data from the previous to the subsequent documents is placed. For example, Data transfer routine 101 is used to transfer Business Data of the document header from the source to the target document.

Copying Requirements : Copying requirements is again a piece of code that evaluates whether the copy of the data should happen or not. If the conditions in the code re not met, then the document flow is stopped. An example is checking for the same customer – Meaning the order should be placed for the same customer as the quotation has been created for.

Copy Item Number : This copies the line item numbers in the source document to the target document. So, line number 20 in the quotation will exactly be line number 20 in the sales document

DEMO

Let’s create a quotation and create an order with respect to the quotation to see how this works.

Step 1 : Creation Quotation for customer 1400 and with material M-01

Step 2 : Create a sales order referring this quotation No. 20000035. Enter the transaction [VA01] and click on the “Create with Reference” to enter the quotation with reference to which we wish to create the sales order.

Step 3 : Enter the Quotation Number in Quotation field of the pop-up. As you can see from the pop-up screen, you can create orders with reference to an inquiry, contract, scheduling agreement, a billing document etc.

Step 4 : After creating the quotation, if you want to track back and see with respect to which document the current order has been created, click on the document flow button.

Step 5 : The document flow will be displayed. If deliveries were created with respect to the order, they will also be shown.

By: magnatraining.com

Customer master is the primary master data in SAP SD. Typically SAP SD functional consultant will have to customize the customer master at least a little bit to suit the requirements of the project. Since this is very standard data and needs to be synced across systems ( For Example ECC CRM ), SAP allows very little customization to the customer master. Nevertheless, SAP allows full customization in the customer master in terms of fields (Hide, show, grey out fields, make fields mandatory etc)and external interfaces ( Interacting with external tax vendors like Vertex etc ) .

Configuration

Menu Path is [ SPRO -> IMG -> Logistics General -> Business Partner -> Customers -> Control ]

Configure Field Statuses in Customer Master

Step 1. - The control is defined at the customer account group level. So for a customer type of Sold-to – 0001 , the fields can be customized. Select the Customer Account Group. In this case we have selected the 0001 – Sold-to Party.

Step 2. - A customer master in standard R/3 can have multiple views – General view, company code view and the sales view. Double click on the corresponding text in the Field status tab to customize the specific view.

Step 4. - Fields in the customer master data are grouped into “Status Groups” or “Field Status Groups” . For example, the Address group contains all the fields related to the address data like the name, street name, zip code etc. Select the right field status group.

Step 5 .- Each field can have any of the following 4 statuses – These statuses are self-descriptive.

• Suppress – Do not show the field in the master data.
• Required Entry – Make this field mandatory.
• Optional Entry – Make this field an optional entry.
• Display – Gray out this field.

DEMO

Here is an example of the customer master “Name” field for the standard customer account group 0001- Sold to party. The little check mark in the name field signifies that the field is indeed mandatory.

Now change the radio button of the first field ( Name 1/Last name ) to Opt. entry.

If you create a new customer now, you can see that the name of the customer will be optional ( As is evident by the lack of the check mark in the Name field )

By: magnatraining

In SAP condition records store the pricing values. These records are stored in condition tables. Condition tables name has three digits. From 1 to 500 are reserved by SAP name space and from 501 to 999 are given to customer space. In the actual database a persistent data base table is created with “A” prefixed to the table number .i.e. condition table 980 creates a table with name A980.

During the condition table creation required fields can be selected. Only the fields present in the field catalogue are available for selection in the condition table. Fields present in the KOMG table can be added to the field catalogue. By default SAP does not add all the fields of KOMG to field catalogue. KOMG table is a union of KOMP, KOMK tables. KOMK table contains the header information of the document (Sales order or Billing), KOMP contains item level information of the document (Sales order / Billing). New fields can be added to the KOMP, KOMK structures. To add the new fields to these structures, an append structure should not be created. To add a field to KOMP structure, field should be added to KOMPAZ structure, which is an include in KOMP structure. Similarly fields should be added to KOMKAZ structure.

If it is required to create a condition table with a custom field the following steps should be followed.

1. Add the field in KOMKAZ or KOMPAZ structure. If the field is at the header level, add the field to KOMKAZ, and if the field is at the item level add to KOMPAZ structure. This step should be done SE11 transaction.
2. Activate the structure.
3. Add the new field to field catalog.
4. Create the condition table.

Adding the field to field catalog and condition table creation can be done VOK0 transaction.

At run time the custom field should be filled with the appropriate value. To to this the following user exits should be used.

USEREXIT_PRICING_PREPARE_TKOMK in RV60AFZZ .

USEREXIT_PRICING_PREPARE_TKOMP in RV60AFZZ.

Below is an example to add sales representative , who is a partner at item level to KOMP structure.

1. Go to Se11, and add the field WWSR1.

2. Open the program RV60AFZZ using SE38 transaction.

3. Add the field to field catalog. To do this go to VOK0 transaction. Then environment ? condition table ? field catalog.

4. Create the condition table. To do this goto VOK0 transaction. Goto environment-> condition table create. Enter the condition table number 980 .

Once the condition table is created, this table can be used in the access sequence. Access sequence is assigned to the condition type. Condition type is inserted in the required pricing procedure. Condition records can be created in VK11 transaction. All the condition records are created with reference to the condition type. As the condition type is linked to access sequence, and access sequence to condition table, system displays all the condition table assigned to access sequence , in the initial screen. User should select one table, and enter condition records.



By : magnatraining

In SAP all the entities who are involved in a business transaction are represented as partners. Ex :A carrier can be created as a partner on the sales order. This document describes the partner determination on the sales order. Partner function specifies the kind of the role the partner is playing in the document. A partner can play many roles in a business transaction. Example is sold to party customer can act as a payer , bill to party and ship to party. To enable this the roles played by this partner (partner functions) should be assigned to the account group. In this case the account group for sold to party which is 0001 in the standard system is assigned to partner function BP, PY and SH.

Partner source specifies what is the source for the partner in the business transaction. The source for the ship to customer is sold to party. In a scenario where a carrier should be determined based on the ship to location, the source for the carrier is ship to party.

An user exit is also available to determine the partner. With this user exit, partner can be determined based on multiple criteria. To enable the user exit, origin field on the partner determination procedure should contain X,Y or Z. In the below screen shot, partner type ZP has Y in the origin field i.e. this partner is determined through the user exit. The following is the sample code for partner determination user exit.

Data temp_werks like vbap-werks.

Data temp_parva like usr05-parva.

clear temp_werks.

clear temp_parva.

if FIF_HERTAB = ‘X’.

select single parva into temp_parva from usr05

where BNAME = sy-UNAME

and PARID = ‘WRK’.

*get parameter ID ‘WRK’ field temp_werks.

FET_DETERMINATED_PARTNERS = temp_parva.

append FET_DETERMINATED_PARTNERS.

FEF_NEW_PARTNERS = ‘X’.

endif.

clear temp_parva.

if FIF_HERTAB = ‘Y’.

select single parva into temp_parva from usr05

where BNAME = sy-UNAME

and PARID = ‘WRK’.

*get parameter ID ‘WRK’ field temp_werks.

FET_DETERMINATED_PARTNERS = temp_parva.

append FET_DETERMINATED_PARTNERS.

FEF_NEW_PARTNERS = ‘X’.

endif.

The above code extracts the value assigned to the parameter ‘WRK’ from the user master (SU3).

Partners can present at the header level and item level. The kind of partners present at the header or item level are controlled by partner determination procedure. At header level a partner determination procedure is assigned to order type, and at item level is is assigned to item category.

Configuration of partner determination

Here we will discuss configuration of the partner determination for sales order header.

1. Create Partner determination procedure.

Create new partner determination procedure.

Path : IMG->Sales and distribution ? Basic functions ? partner determination ? Sales order header

In this case ZETA is the new partner determination procedure. Select ZETA and press partner functions in procedure.

Assign all the partners required in the sales order. Check the mandatory field if the partner is mandatory in the transaction.

2. Assign the partner determination procedure to sales order type.

In the same transaction (step 1), press partner determination procedure assignment. Assign the newly created partner determination procedure to the sales order type. In this example ZETA partner determination procedure is assigned to sales order type ZEQN.

IF a new partner function is required, navigate to the partner functions tab (left pane).

Create the new partner function on this screen, by pressing new entries. Add the new partner function to the partner determination procedure as described in step 2. When a new partner function is created, the account group which can act as this partner should be specified. To do this navigate to “Account Groups – Function Assignment.

n the above screen the red arrow points to a line, it specifies that the account group Z001 can act as ship to partner. Similarly ZP partner function can be fulfilled by ZBCP account group partners.

By: magnatraining

What is the relation between CRM and SD?

The major difference between CRM & SD is as follows:

CRM- It is being customer relationship management, it mainly focuses on pre sales & post sale activities to improve on customer relationship.

CRM Sale, it uses Opportunities management for creation of opportunities available with prospective customers. there is also quotation management & order management available for order creation. But it is optional as it can be created in SD too.

CRM Marketing includes Lead creation, Campaign management for publishing material to customers or for lead generation, creation Target group of customers

CRM also uses Activity management by creation of customer interaction Activities with customer.

CRM service uses Complaints & returns, Warranty Management, i base management, Service Order management.

It also uses Account Management for managing vast data of customers & it is flexible compared to SD customer data.

CRM also offers Interaction center capabilities to handle call center activities which is not available with SD. Also, it offers internet Sales & Service for channel partner management & self service.

All these above functionalities are not in SD as SD mainly being logistic module it is mainly used for order & delivery management.

By: sap-img.com

When there is a temporarily stop of business with a customer, you can block new orders to be created for this customer. You can have the options of blocking all the work flow or let the delivery and billing to continue for any open orders.

VD05 – Block/Unblock Customer

OVAS – Sales Order Type Blocking reasons
OVAL – Blocking reasons links with Sales Order Type

OVZ7 – Delivery Blocking reasons
OVV3 – Billing Blocking reasons

In 4.6x, if you found that your Sales Order Billing Block is not working, it is because you need to build the Billing Block for the Billing Type.

SM30 – Table/View   V_TVFSP
By : sap-basis-abap.com