Availability check

Configuring Availability Check

By Santosh
Availability check
1. Availability check is an integral part of the business process that determines if the
required delivery quantity can be met on a required delivery date. For this purpose the
system takes into account pre-delivery activities such as scheduling for picking or
packing times and the time taken to produce or obtain the material. It also performs
several background functions such as Backorder processing, rescheduling and ATP
quantities.

2. Backorder processing: processing of a sales order that has not been fully confirmed or
not confirmed at a certain delivery date.
3. Rescheduling: is a proposal of how confirmed quantities already assigned to a sales
order can be reassigned to other sales orders that have a higher priority.
4. Available to promise (ATP): is a process of checking the available quantities of a
material. The ATP quantity consists of warehouse stock + planned receipts (incoming
stock) planned issues (outgoing stock). to examine stock on hand (CO09) proceed to
logistics sales & distribution sales environment availability overview.
5. Replenishment lead time (RLT): is the time taken for the material to become available
either internally (in house production) or externally (from a vendor). The most important
things to consider during an external procurement are purchasing and MRP2
(procurement) views of MMR where the processing time for purchasing, planned delivery
time and goods receipt processing time are taken into account. On the other hand
internal procurement is based on in house production time (MRP 2 view) goods receipt
processing time or alternatively RLT time, which is found on MRP 3 view.

6. RLT (Replenishment Lead Time) is the time taken for the material to become
available. RLT is only used when doing an ATP check (Available To Promise). The value of
RLT for a material is specified on material master record.
7. There are three types of availability checks
* Check on basis of ATP quantities.
* Check against product allocation.
* Check against planning.

Configuring Availability check through Checking Groups

1. The checking group + checking rule determine how the availability check is to be
performed.
2. The checking group determines whether and how the system checks the stock
availability and generates requirements for material planning. The checking group
defines what type of requirements will be passed on i.e. summarized requirements
(daily/weekly) or individual requirements for each sales order.
3. The checking rule applies to how the availability check is to be carried out at the
transaction level. Note that you must define checking rules for each individual
application such as for production orders for example. In Sales and Distribution, the
checking rule is specified internally within the system and cannot be changed.
4. The checking rule, in conjunction with the checking group, determines the scope of
the availability check for every business operation; that is, which stocks, receipts and
issues are to be included in the availability check and whether the check is to be carried
out with or without the replenishment lead time.
5. Briefly explaining the above checking group determines which type of requirement
to be passed on to MRP whether it be individual or summarized and checking rule which
is at the transaction level and can be configured independently for each application
module, determines which stocks, receipts and issues to be taken into account. For
performing an availability check checking group has to work in conjunction with
checking rule.
6. Advantages of individual processing over summarized processing Backorder
processing is possible. You can access (MD04) order, line and schedule line individually
which gives a greater control on available stock and requirements placed on stock.
The system automatically uses individual requirements in case of special stock items.
7. Required data for the Availability check to be carried out
The Availability check must be switched on at the requirement class level.
The Availability check must be set at the schedule line level.
A requirements type must exist by which the requirements class can be found.
A plant must be defined in the sales order for each schedule line item (in other words
plant must be defined for every material in MMR).
A checking group must be defined in the material master record in the MRP3 screen in
the availability check field.

8. Configuring Availability check and defining Checking Groups

Checking groups are introduced into the sales order based on the setting in the material
master
record.
SAP standard checking groups are 01 summarized requirements and 02 individual
requirements or you can create your own by copying the standard ones.
Total sales and total deliveries columns are there to configure a checking rule to sum up
requirements to post to MRP either individually or by day or week.
Block quantity required can be set if you want several users to be able to process the
material simultaneously in different transactions without blocking each other.
The no check indicator is CHECKED when you DO NOT want the system to carry out ATP
check.

9. Defining material block for other users the block check box is an indicator that
enables you to block material master records of a particular material during the
availability check and restrict other users from accessing same master record and
reserve the material. If the block is not set, two users can confirm the same material at
the same time for two different orders, not knowing if the stock is available or not. If you
select this field, the material is blocked during the availability check and other users
cannot: a) Make changes in the material master record. b) Create purchase orders for
the material. C) Create orders for the material.

10. Defining default values for checking groups - Checking groups are introduced into
the sales order based on the setting in the material master record.
However if there is no entry present in the material master record for the checking
group, a default value can be set here, depending on material type and plant.
This default value will be used by the system depending on the material type mentioned
in MMR and plant in sales order. If an entry exists, this default value is over written by
MMR.
11. Controlling Availability Check in this section, you tell the system what stock on
hand and what inward and outward movements of stock it must take into account when
performing the availability check in addition to whether or not to consider the
replenishment
lead
time.

12. These settings are based on the checking group that is assigned to the material
master record and the checking rule that is predefined and assigned to the sales and
distribution
transaction.

13. These settings carry out control both for sales order and delivery as well. This is due
to the fact that you may want to include specific stock or incoming stock for the sales
order, yet at the time of the delivery only include physical stock on hand waiting to be

shipped.

14. It is possible to indicate to the system that you would like the availability check NOT
TO CHECK the stock at the storage location level. This indicator is used to set the scope
of
the
availability
check.

15. It is used to switch off the check at storage location level. You create a reservation
for a particular storage location. However, the scope of the availability check is set in
such a way as to exclude the storage location. In this case, the system carries out the
check at plant level only and does not take the storage location into account that is
specified
in
the
reservation.
16. Should you not want the system to automatically check RLT, you may indicate so
here. RLT is the time taken for a material to become available. It is only used when
doing an ATP check and is taken from MMR.

17. defining the elements in the availability check entirely depends on the business
needs, but a few tips are given under

When controlling the Availability check at the time of the sales order, a purchase
requisition does not necessarily indicate by it is going to come into the plant.
A shipping notification on the other hand - a confirmed purchase order is a good
indicator of receiving stock on a specified date. It is always recommended not to select
the shipping notifications for the delivery requirements type as you may not actually
receive the stock into plant or warehouse for which you are creating a delivery.

Flow of Billing Document

Checking the Flow of Billing Documents
Use
You can use this function to compare the actual data in CO-PA to the corresponding
postings made in Financial Accounting (FI). This makes it possible to analyze the flow of
values from billing documents in Sales and Distribution (SD) to CO-PA and understand
how any differences arose between the different applications.
You can find this function in Customizing in the Tools Analysis section and in the
application menu under Tools Analyze Value Flows.
Functions
Values in billing documents are assigned to condition types in SD, accounts in FI and
value fields in CO-PA. This function shows you a list of the values posted in CO-PA value
fields, along with those posted in FI (profit and loss accounts) and SD (condition types).
It also shows any differences between the values in CO-PA and SD (Delta CO-PA/SD) and
between SD and FI (Delta SD/FI). If there is a difference, you can drill down to the
respective
billing
documents.
Statistical condition types (that do not lead to accrual postings) are marked as such and
are included in the SD value. This makes it possible to compare the SD value with the
CO-PA value. Since these condition types do not lead to FI postings, their values are not
taken into account in the comparison between SD and FI. The delta between SD and FI
therefore may not be the same as the actual difference between the SD and FI values.
List Structure
The list is arranged in blocks, each of which contains logically related, hierarchically
structured information. Each block typically contains a value field, the condition types
assigned to it, and the profit and loss accounts linked to these condition types.
If two condition types post to the same account, they appear together with the
corresponding value fields and accounts in one block. At the top of this block, you see a
separate total for all the values in that block. Accounts that receive postings from more
than one condition type are listed separately again at the end of the block. Wherever
possible, the system lists a CO-PA value, an SD value and an FI value for each value
field, condition type, or account.
The goods issue posting for a billing document is assigned to the condition type of the
category G (such as condition type VPRS). Condition types of this category are specially
marked as such. At the account level below condition types of the category G, you can

see the accounts of the goods issue postings, and any categories of billing documents
that do not require a goods issue are shown without an FI value.
Under Additional condition types you can find the following values:
* Condition types that are not assigned to a value field (the corresponding accounts
appear under Additional accounts)
* Non-statistical conditions that are not posted to an account with cost element type 11
or 12 are not transferred to CO-PA.
Under Goods issue, you can see goods issue postings for which the billing document
does not contain a condition type of the category G.
For the purposes of reconciliation, two values are shown. These principally cause
discrepancies between CO-PA and FI. If you restrict the billing date in the selection
screen (for example, to a period),then the following values are displayed:
* Goods issue in earlier periods: These are the goods issue values for billing documents
that have a billing date falling within the selection interval but for which goods issue
precedes the selection interval. These values were therefore posted in CO-PA in the
current period but were posted in FI in an earlier period.
* Nonbilled goods issue: This applies to goods issue values that, firstly, have a goods
issue date falling within the selection interval, but, secondly, that were not billing at the
end of the interval (or were not billed at all). These values were therefore posted in FI
but
not
until
later
in
CO-PA,
if
at
all.
Signs
The signs of the SD values are changed to match those of the CO-PA values so that you
can easily compare the values directly with one another.

The values for these SD condition types consequently need to have their signs reversed
again before they can be compared with the FI values. Any change in sign is shown at
each level of the hierarchy with a "+" or "-".
In some Customizing constellations it may not be possible to compare two hierarchical
levels that lie below the same level.

Pricing Procedure Configuration

In SD, the steps to configure Pricing procedure are as under:
Step 1:
Condition table: If existing condition table meets the requirement, we need not create a
new condition table. Considering the requirement for new condition table, the
configuration will be done in SPRO as follows: IMG --> Sales & Distribution --> Basic
Function --> Pricing Control --> Condition Table (select the required fields combination,
which
will
store
condition
record).

Step 2:
Access Sequence: If existing access sequence meets the requirement, we need not
create a new access sequence. Considering the requirement for new sequence, the
configuration will be done in SPRO as follows: IMG --> Sales & Distribution --> Basic
Function --> Pricing Control --> Access Sequence (Access sequence is made up of
Accesses (Tables) & the order of priority in which it is to be accessed. Here we assign
the
condition
table
to
access
sequence.

Step 3:
Condition Type: If existing condition type meets the requirement, we need not create a
new condition type. Considering the requirement for new condition type, the
configuration will be done in SPRO as follows: IMG --> Sales & Distribution --> Basic
Function --> Pricing Control --> Condition Type. It is always recommended to copy an
existing similar condition type & make the necessary changes. Here we assign Access
sequence to Condition type.
Step 4:
Pricing Procedure: It is recommended to copy a similar pricing procedure & make the
necessary changes in new pricing procedure. Pricing Procedure is a set of condition type
& arranged in the sequence in which it has to perform the calculation. Considering the
requirement for new Pricing Procedure, the configuration will be done in SPRO as
follows: IMG --> Sales & Distribution --> Basic Function --> Pricing Control --> Pricing
Procedure
-->
Maintain
Pricing
Procedure.
b. Pricing Procedure: After maintaining the pricing procedure the next step will be
determination of pricing procedure. Configuration for determining pricing procedure in
SPRO is as follows: IMG --> Sales & Distribution --> Basic Function --> Pricing Control -->
Pricing Procedure --> Determine Pricing Procedure.
Step 5:

Condition record: Condition record is a master data, which is required to be maintained

by Core team / person responsible from the client. During new implementation, the
condition records can be uploaded using tools like SCAT, LSMW, etc.

Steps to transport a Configuration Request

1) You carry out config. changes in "Golden Master" client , (say100) in DEV server.
2) When you save, system prompts a Transport request dialogue, which is generally, saved by
input of a description that identifies the Kind of Config carried out. User name appears by
default
with
the
Config
request
description
when
saved.
3) This is required to be tested in (Unit) Test Client say 120, by Client Copy of the Request using
Tcode - SCC1.
4) On successful test results, we need to release the request (Tcode = SE01 or SE10). Here
Collapse the request line once. Then click on Sub-task and press Transport button.. Then, Click
on Main task and again press Transport button System gives success message.
5) Subsequently the BASIS Guy can transport the request to QUALITY and PRODUCTION
Clients

Third Party Sales

Process Flow for 3rd Party Sales
Customize the third party sales in summary:
1. Create Vendor XK01
2. Create Material Material Type as "Trading Goods". Item category group as "BANS".
3. Assign Item Category TAS to Order type that you are going to use.
4. A sale order is created and when saved a PR is generated at the background
5. With reference to SO a PO is created (ME21N). The company raises PO to the vendor.
6. Vendor delivers the goods and raises bill to company. MM receives the invoice MIRO
7. Goods receipt MIGO
8. Goods issue
9. The item cat TAS or Schedule line cat CS is not relevant for delivery which is evident
from the config and, therefore, there is no delivery process attached in the whole
process of Third party sales.
10. Billing *-- Seema Dhar

SD - 3rd party sales order Create Sales Order

VA01
Order Type
Sales org, distr chnl, div
Enter
Sold to
PO #
Material
Quantity
Enter
Save
SD - 3rd party sales order View the PR that is created with a third party sales order
VA01
Order Number

Goto Item Overview

Item ->Schedule Item
SD - 3rd party sales order View the PR that is created
ME52N
Key in the PR number
Save
SD - 3rd party sales order Assign the PR to the vendor and create PO
ME57
Key in the PR number
Toggle the "Assigned Purchase Requisition"
Execute
Check the box next to the material
Assign Automatically button
Click on "Assignments" button
Click on "Process assignment"
The "Process Assignment Create PO" box , enter
Drag the PR and drop in the shopping basket
Save
SD - 3rd party sales order Receive Goods
MIGO_GR
PO Number
DN Number
Batch tab , click on classification
Serial Numbers tab
Date of Production
Flag Item OK
Check, just in case
Post
Save
SD - 3rd party sales order Create Invoice
MIRO
Invoice Date
Look for the PO , state the vendor and the Material
Check the box
Clilck on "Copy"
Purchase Order Number (bottom half of the screen)
Amount
State the baseline date
Simulate & Post
Invoice Number
*Invoice blocked due to date variance

SD - 3rd party sales order Create a delivery order

VL01N
In the order screen , go to the menu Sales Document , select "Deliver"
Go to "picking" tab
State the qty and save
SD - 3rd party sales order Create a billing document
VF01
Ensure that the delivery document is correct in the
Enter
Go to edit -> Log
Save

MMBE CREATE STOCK

MM60 MATERIAL LIST
VD06 FLAG FOR DELETION
VK11 MAINTAINING PRICING
VK0A ASSIGN G/L ACCOUNT GENERAL
VOK0 PRICING
VOR1 DEF COMMON DIST CHANEL
VOR2 DEF COMMON DIV
VOV6 DEFINE SCHEDULE LINES
VOV8 DEFINE SALES DOC TYPE
VOFA CREATE/OR CHANGE BILLING TYPES CONFIGURATION
V129 DEFINE INCOMPLETENESS SCHEMAS FOR FOREIGN TRADE
V149 ASSIGN INCOMPLETENESS SCHEMAS FOR COUNTRY CODE
CA01 CREATE ROUTING
CA02 EDIT ROUTING
CA03 DISPLAY ROUTING
CS01 CREATE BOM
CS02 CHANGE BOM
CS03 DISPLAY BOM
OVK1 DEFINE TAX DET RULES
OVK3 DEF TAX REL OF MASTER RECORDS CUSTOMER TAXES
OVK4 DEF TAX REL OF MASTER RECORDS MATERIAL TAXES
OVR6 DEF LEGAL STATUSES
OVS9 DEF CUSTOMER GRP
OVRA MAINT STATISTICS GRPS FOR CUSTOMERS
OVRF MAINT STATISTICS GRPS FOR MATERIAL
OVXC ASSIGN SHIIPING POINT TO PLANT
OVX6 ASSIGN PLANT TO S.O AND DIST CHANEL
OVLK DEFINE DELIVERY TYPE
OVSG DEFINE INCOTERMS
OVLH DEFINE ROUTES
OVXM ASSIGN SALES OFF TO SALES AREA
OVXJ ASSIGN SALES GRP TO SALES OFFICE
OMS2 MATERAIL UPDATE
OVLP DEFINE ITEM CATEGORY FOR DELIVERY
OX10 ASSIGN DEL PLANTS FOR TAX DET
O/S2 DEFINE SERIAL NO PROFILE
O/S1 DEFINE CENTRAL CONTROL PARAMETERS FOR SR NO
OBB8 DEFINE TERMS OF PAYMENT
OKKP ACTIVATION OF COMPONENETS
VC/1 CUSTOMER LIST - Program RVKUSTA1
VC/2 CREATE SALES SUMMARY
VDH2 DISPLAY CUSTOMER HIERARCHY
VF07 DISPLAY FROM ARCHIVE
VF11 CANCEL BILL
VFX3 BLOCKED BILLING DOC

VFRB RETRO BILLING

VF04 MAINTAIN BILL DUE LIST
VF06 BACKGROUND PROCESSING
VF44 MAINT REVENUE LIST
VF45 REVENUE REPORTS
VF46 MAINT CANCELLATION LIST
VF31 ISSUE BILLING DOC
VFP1 SET BILLING DATE
VARR ARCHIVE DOCUMENTS
V/08 TO CHANGE CONDITION (PR PROCEDURE)
V/30 DEFINE PRINT PARAMETERS
FD32 SETTING CREDIT LIMIT FOR CUSTOMER
SM12 TO REMOVE LOCK ENTRY
SM30
VD59 LIST CUSTOMER MATERIAL INFO
VB0F UPDATE BILL DOC

Define Sales Document Types

This configuration setting enables creation or modification of sales document type.
Sales document type is an indicator which enables system to process different business
transactions in different ways. Various document types are pre-configured in system and
can be used for various scenarios. There are three options for configuring new sales
document types: Change existing sales document type Copy existing sales
document type and change it to new requirements. Create a new sales document
type. Definition and configuration of sales document type can be divided in three parts
1. Definition of Sales document type itself (with key e.g. QT etc.)
2.
Definition
of
additional
sales
functions
(like
number
ranges
etc.)
3. Configuration for general SD functions (like pricing etc.) We will study the
configuration of SAP provided sales document type for standard order OR. Instructions
Follow Menu Path: IMG Sales and Distribution Sales Sales Documents Sales
Document Header Define Sales Document Type 1. Click Here the three options
explained in background are applicable. d. If existing Sales document type is to be
modified, choose the document type from list and click on to get into details e. For
copying existing sales document type to new one select the sales document type to be
copied and click on or F2. f. For creating a new sales document type click on
Here we will follow option a and select order type OR and click on. To search for
correct order type click on and enter the key. Following screen is displayed The controls
are grouped in various blocks like Number Systems, General Control, Transaction flow
etc. 2. Maintain the fields as explained below: The explanation is provided block wise
Field Name Field Description and Value Sales Document Type 4 character key for the
sales document type. Description is next to it SD document categ. Classification of
different types of documents in SD, used by system to determine how processing is to
be carried out. Predefined following entries exist Indicator Sales document indicator for
further classification if required. Sales document block Determines if sales order is
blocked for creation or allows only automatic creation. Key fields are explained below:
Field Name Field Description and Value No Range int. assgnt No range to be used for
sales
document numbers if assigned internally No Range ext. assg. No range to be used for
sales
document numbers if assigned externally Item no. increment Increment of item no in
sales
order like 10, 20 etc. Sub-item increment Increment of item no automatically by system
Key fields are explained below: Field Name Field Description and Value Reference
mandatory Control if reference is mandatory while creating sales document. Leave
blank Check division Control on check if division differs at item & header level. Leave
blank Probability Probability of customer confirming inquiry or quotation in sales order.

Check Credit Limit Specifies if system runs credit check and behavior. Credit group
Assignment
of
credit
group
defined
in
credit
management
Output Application Normally V1 for sales Material entry type Control on material entry in
sales order. Item division Check this if division is to be determined from material master
record at item level Read Info record Check this if Customer material info records are to
be read. Check purch order no. If Customer purchase order no is to be checked for
duplication maintain A Key fields explained below, rest are system copied. Field Name
Field Description and Value Transaction group Grouping that controls certain
characteristics of sales doc processing. Doc. pric. Procedure Key specifying pricing proc
for sales document type. Input for pricing procedure determination Quotation messages
Control to check if system should check for existing open quotations.
Outline agrmt messages Control to check if system should check for open agreements
like contracts. Key fields explained below: Field Name Field Description and Value
Delivery type Default delivery type for this sales document type Delivery block Default
Delivery block for sales document Shipping conditions Default shipping condition for
sales document type. Maintained if it is different from customer master record.
Immediate delivery To be flag X if immediate delivery is required after sales order is
saved. Example - In Cash Sales and Rush order scenarios. Key fields explained below:
Field Name Field Description and Value Delivery rel. billing type Default billing type that
system proposes while creating billing documents from delivery Order-related billing
type Default billing type that system proposes while creating billing documents from
order Inter-company billing type Default billing type that system proposes while creating
billing documents for inter-company. Billing block To Default billing block in sales order
like Credit memo etc. Billing plan type Billing plan type if used like Milestone or Periodic
billing Paymt guarant. proc Procedure type for payment guarantee Paymt card plan type
Payment plan type for payment cards Checking group Checking group for payment
cards Key fields explained below: Field Name Field Description and Value Lead time in
days
No
of
days
from
current
date
for
proposal of requested delivery date of items. Propose deliv. Date Check box controls if
current date is to be proposed as delivery date. Other controls like Scheduling
agreement and Contract are relevant for only those sales document types and not
explained here. Effect of Configuration Sales document type configured here would be
used for creating sales order in specific scenario.

Six Common Job-Interview Questions

One of the easiest ways to build confidence before a job interview is
to questions you might be asked. Whether you're applying for a
programmer, accountant, or legal secretary, interviewers often
questions to assess candidates, so you'll increase your chances
prepare
for
them
in

to prepare answers
position as a web
use some general
for success if you
advance.

Six common questions are listed below, along with insights from several recruitment
professionals about how to answer. As part of your interview preparation, take the time
to formulate answers to each question, focusing on specific tasks and accomplishments.
"What are your strengths and weaknesses?"

This is one of the most well-known interview questions, and interviewers often ask it
indirectly, as in, "What did your most recent boss suggest as areas for improvement in
your
last
performance
review?"
Lindsay Olson, founder of Paradigm Staffing Solutions, a firm specializing in hiring public
relations professionals, suggests tailoring your "strengths" answer to skills that will
benefit the prospective employer. Though you may have a knack for building
gingerbread houses, it might be of little value for the job at hand.

When it comes to weaknesses, or areas of growth, Olson recommends building on your

answer to include "how you have improved, and specifics on what you have done to
improve
yourself
in
those
areas."
"Why did you leave your last position?"

"Interviewers will always want to know your reasoning behind leaving a company ?
particularly short stints," says Olson. "Be prepared to tell the truth, without speaking
negatively
about
past
employment."
"Can you describe a previous work situation in which you ... ?"

This question comes in many forms, but what the interviewer is looking for is your
behavior on the job. Your answer could focus on resolving a crisis, overcoming a
negotiation deadlock, handling a problem coworker, or juggling multiple tasks on a
project.
The theory behind this type of question is that past behavior is the best predictor of
future behavior, according to Yves Lermusi, CEO of Checkster, a company that offers
career and talent checkup tools. "The key to responding well is preparing real job

examples, describing your behavior in specific situations that demonstrate important

skills
that
the
job
requires."
"What is your ideal work environment?"

This question is not about whether you prefer a cubicle or an office, so think broadly to
include ideas about supervision, management styles, and your workday routine.
Bob Hancock, senior recruiter for video game publisher Electronic Arts, says that he
uses this question with candidates because it can give "a sense of their work habits,
how flexible they are with their schedules, and how creative they are."
"How do you handle mistakes?"

The best strategy for this general question is to focus on one or two specific examples in
the past and, if possible, highlight resolutions or actions that might have relevance to
the job you're interviewing for.

"Employers want to know they're hiring someone with the maturity to accept
responsibility and the wherewithal to remedy their own mistakes," says Debra
Davenport, a master professional mentor and columnist for the Business Journal in
Phoenix.
"What is your most notable accomplishment?"

Paradigm Staffing's Olson suggests that candidates think of three or four

accomplishments and quantify what their actions meant in terms of increasing
revenues, saving resources, or improving resources."Being able to quantify your
achievements in your career will launch you ahead of the rest," she says, "and
demonstrate your ability to do the same as a future employee."

Interview tips
Important Tips for Interview for SAP SD
Let me share some important tips for interview for SAP SD:
1. Please be through with the projects you have mentioned in your resume.
2. Remember all the versions you have worked upon.
3. If your projects are in Indian scenario be thorough with CIN/Excise VAT and pricing
procedure.
4 For offshore client specially in Europe and NASA prepare yourself for Warehouse/Lean
warehouse
5. Third party billing / Intercompany / Make to order are important topics.
6. Cost booking that is accounting enteries after PGI and Billing should be known to
you.
7. Mug up all the determinations.
8. Remember your last ticket.
9. Have general awareness about ALE/EDI/IDOC, as this provides added advantage. (not
very tough)
10. Please be through with your basics, the process, the pricing and the master data.
11. People who are thorough with route, transportation, shipping always have an added
advantage.

The MOST IMPORTANT THING:

Do not try to fool your interviewer, say exactly and only what is asked do not show your
excitement and do not speak too much if you know the topic too well, and say a straight
NO if you have not worked on something, or don't know about something, pls pls pls
don't not go for flukes otherwise you will end up in soup.

What I understand is most of the companies especially in the US are looking for a
candidates
with
1) good communication skills (SAP is all about interacting with the client, users and
team)
2) good business knowledge
3) are you able to convince the client

That comes in next round when you are interviewed to be deputed for any US/Europe
project, in this round take care of the following:

1. Speak slow, I mean normal, because usually Indians speak english too fast.

2. Listen to them carefully, if you are not able to understand their question request
them to repeat it, rather than assuming it to be something else and giving a wrong
reply.
3. Again I should repeat prepare yourself for warehouse, I mean even general
knowledge
will
help.
4. Say a straight no when you don't know or have not worked on the topic.
5. Always be strong on SD MM FI integrations

What the job responsibilites would be for the Support Consultant? If the Consultant is
working in Offshore Support, How the business interaction would be there between the
Consultant and Customer? How the Customer Queries were handled successfully sitting
from
his
location.
Job responsibility of a Support consultants is to handle routine tickets, which can be
incident (routine problems), change tickets (need configuration change, therefore a
change request), normally a support consultant can only advice a change but can't do it
, because there is always a change advisory board on client end to evaluate and
implement
the
adviced
change.
Business intercation between users and customer can be through mail box utilities,
outlook, even telecons and some companies also allow chat.

Usually the customer provides with the number of the document and client/company
code and other necessary info. about the process which is facing problem, the
consultant tracks the project by logging in to development server and search out for
causes, the solution is then sent to user, maybe with snapshot if required.

For those people who asks for for tickets:

1.
Tickets
are
normally
raised
by
end
user
and
carry
a
priority.
2. Those who are asking SAP gurus to tell them about tickets, pls note that most of the
problems except for the basic questions discussed in this group are the tickets
themselves, tickets are nothing but the routine incidents the SAP consultants get, if you
regularly read the mails in the group you will soon start recognizing tickets.

And the most important thing "Believe in yourself and God, as there is always somebody
there to help you".

Tips by : Nitin

What is the team size? Duration of the project.

Hardly the team of the sd will be 4 to 5 and entire team of the project will be around 2024 (all modules like fi/co, sd, mm, pp, hr, qm, pm). If its big project, it will be around 40.
Team size means the employees who you are working on sap r/3 implementation.
For the project completion it will take around 8-10 months to get into golive. After that,
post implementation for 3 months. After that supporting it depends as project time line
for every company is different.

SAP SD resume
As an SAP SD Consultant, you need to include the following in your SAP SD Resume.
(SAP Sales & Distribution)
1. Organizational Structures (+)
Organizational Units and
Organizational Structures in Sales, Shipping and Billing
2. Master Data (+)
Customer Master
Material Master
Field Control for Customer and Material Master
Customer-Material Info Record
3. Sales (+++)
Sales Document Processing - Basics
Sales Document Types
Item Categories and Schedule Line Categories
Copy Control
Partner Control
Availability Check - Basics
Outline Agreements
Special Business Transactions
Incompleteness Control
Free Goods and Free-of-Charge Items
Material Determination, Listing and Exclusion
Reporting - Basics
4. Shipping (++)
Delivery Processing - Basics
Delivery Types and Item Categories
Picking, Packaging and Goods Issue
Scheduling
Routing and Route Determination
5. Pricing (++)
Pricing Processing - Basics
Condition Technique
Condition Records
Bonus Processing
6. Billing (++)
Billing - Basics
Billing Types
Complaint Documents

 Billing Plan
Account Determination
Interface SD/FI
7. Cross-Application Customizing in SD (+)
Text Processing
Output Control
Interface Personalization
8. Solution Manager (+)
Solution Manager Overview
9. Experience from Implementation (Case Study or Project)* (+)
Construction of Business Structures (Organizational Units in mySAP.com)
Integration and Dependencies
SAP FI Resume
There are many things that make an SAP Resume stand out. When you are doing up
your resume, you need to indicate the following to let the hiring manager take notice of
your resume. If you are a certified SAP Consultant, it is important that you include the
SAP logo on your resume or cv. If you don't indicate the SAP logo on your resume, you're
losing out big time.
There are a number of things that HR Executive or Hiring Manager looks out in your SAP
Resume. You need to indicate the following:
* How many years experience you have on SAP
* Which modules of SAP have you worked on
* Have you been working as a SAP Consultant doing configurations and implementation,
or taking on the role of SAP support.
* Are you a SAP Certified Consultant?
* Are you a SAP Consultant, SAP Technical Consultant or an SAP Techno-Functional
Consultant?
* Are you a SAP Implementer, SAP Team Lead, SAP Project Manager doing SAP Project
Implementations?
* How many SAP project life cycles have you completed. Are they full SAP
implementation cycles or just partial SAP modules.
* Have you implemented SAP Rollouts for the region. SAP Rollout means implementing
similar SAP modules & configurations for other countries.
* What are the projects that you were involved in?
* For each individual project, indicate the number of SAP Consultants involved and your
role in the SAP project
* Where was the project delivered
* Which SAP modules are you trained and certified in
* Which SAP modules are you competent in
* Which version of SAP, is it SAP 3xx, SAP 4.0, SAP 4.1, SAP 4.6A, SAP 4.6B, SAP 4.6C,
SAP 4.70, mySAP CRM, mySAP ERP, mySAP FIN ...etc

* SAP modules involved in each project. E.g SAP MM, SAP SD, SAP FICO with SAP ABAP,
SAP Basis, SAP BW.
* Most SAP projects are implemented by SAP Consulting firms, therefore it is also
important to indicate which company were you working with. (E.g. I was working as a
SAP HR Consultant and was tasked to do implementaion for Unilever for their SAP
Rollout).
SAP FI Resume
Other SAP Resumes

SAP Resumes
* SAP FI Resume | SAP FI Resumes
* SAP CO Resume | SAP CO Resumes
* SAP FICO Resume | SAP FICO Resumes
* SAP SD Resume | SAP SD Resumes
* SAP MM Resume | SAP MM Resumes
* SAP HR Resume | SAP HR Resumes
* SAP PP Resume | SAP PP Resumes
* SAP APO Resume | SAP APO Resumes
* SAP ABAP Resume | SAP ABAP Resumes
* SAP Basis Resume | SAP Basis Resumes
* SAP BW Resume | SAP BW Resumes
* SAP PM Resume | SAP PM Resumes
* SAP WM Resume | SAP WM Resumes
* SAP Project System Resume | SAP Project System Resumes
* SAP Life Cycle Asset Management Resume | SAP Life Cycle Asset Management
Resumes
* mySAP SRM Resume | mySAP SRM Resumes
* mySAP ERP Financials Resume | mySAP ERP Financials Resumes
* SAP Mendocino Resume | SAP Mendocino Resumes

Complete SAP Modules:

SAP Basis
*
*
*
*
*
*

Remote Function Calls (RFC)

Common Program Interface Communications (CPI-C)
Electronic Data Interchange (EDI)
Object Linking and Embedding (OLE)
Application Link Enabling (ALE)
Customising (BC-CUS)

*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*

Client Server Technology (BC - CST)

Network Integration (BC - NET)
ABAP Programming and Runtime Environment (BC - ABA)
Basis Services/ Communication Interfaces (BC - SRV)
Computing Center Management System (BC - CCM)
Upgrade General (BC - UPG)
Change and Transport System (BC - CTS)
Operating System Platform(BC - OP)
Database Interface, database platforms (BC - DB)
Front End Services (BC - FES)
ABAP Workbench (BC - DWB)
Documentation and Translation Tools (BC - DOC)
Security (BC - SEC)
Controls and Control Framework (BC - CI)
Business Management (BC - BMT)
Middleware (BC - MID)
Computer Aided Test Tool (BC - CAT)
Ready to Run R/3 (BC - BRR)
Authorisations System Monitoring with CCMS Workload Alert Monitor

SAP Hardware
*
*
*
*
*
*
*
*
*

AS400
AT&T
Bull
Compaq Digital
HP
IBM
Sequent
SNI
Sun

SAP Database
*
*
*
*
*
*
*
*

Adabas D
DB2 for AIX
DB2/400
Informix
MS SQL
My SQL
Oracle
Sybase

Operating System

*
*
*
*
*
*

AIX
HP UX
MS Windows NT OS/400
Sinux
Solaris
Unix

ABAP/4 Programming
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*

SAP Script
Business Workflow (BC - WF)
ALE
EDI
Business Connector
Business Server Pages
Internet Application Server
Mercator Report Painter
Dialog Programming
Repository Information System
Menu Painter
ABAP 00
IDOCS
LSMW
Smartforms
EBP
ASAP methodology
ALV reporting
Report writer
ABAP Query
Data Dictionary
Screen Painter

SAP FI (Financial Accounting)

*
*
*
*
*
*
*

Accounts Payable (FI- AP)

Accounts Receivable (FI - AR)
Asset Accounting (FI - AA)
General Ledger Accounting (FI - GL)
Special Ledger (FI - SL)
Funds Management (FI - FM)
Travel Management (FI-TM)

SAP TR (Treasury)
* Cash Management (TR - CM)

*
*
*
*
*

Treasury Management (TR - TM)

Loans Management (TR - LM)
Funds Management (TR - FM)
Market Risk Management (TR - MRM)
Information System

SAP CO (Controlling)
*
*
*
*
*
*

Cost Centre Accounting (CO - CCA)

Overhead Cost Controlling (CO - OM)
Activity Based Coding (CO - ABC)
Product Cost Controlling (CO - PC)
Profitability Analysis (CO - PA)
Material Ledger (CO - ML)

SAP EC (Enterprise Controlling)

*
*
*
*

Consolidation (EC - CS)

Profit Center Accounting (EC - PCA)
Executive Information System (EC-EIS)
Business Planning and Budgeting

SAP IM (Investment Management)

*
*
*
*
*
*
*

Investment Programmes
Investment Measures (orders/products)
Appropriation Requests
Corporation Wide Budgeting
Depreciation Forecast
Automatic Settlement of Fixed Assets
Information System

SAP HR (Human Resource)

*
*
*
*
*
*
*
*
*
*
*

Personnel Administration
Benefits Administration
Compensation Management
Recruitment
Travel Management
Personnel Development
Organisational Management
Training and Events Management
Personnel Planning
Time Management
Incentive

*
*
*
*
*

Wages
Workflow
Internet Scenarios
Payroll
Information System

SAP SMB
* SAP SMB
SAP BW
*
*
*
*
*
*
*

Data Warehousing
BI Platform
BI Suite - Business Explorer
Development Technologies
ODS Structures
Info Cube
Design Build

SAP IS (Industry Solutions) / SAP for Industries

*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*

Aerospace & Defence

Retail
Consumer Products
Defence & Security
Insurance
Industrial Machinery & Components
Logistics Service Providers
Mill Products
Higher Education & Research
Automotive
Banking
Telecoms
Chemicals
Pharmaceuticals
Life Sciences
Mining
Media
Public Sector
Service Provider
Utilities
Healthcare
Oil & Gas
Postal Services

SAP SD (Sales and Distribution)

*
*
*
*
*
*
*
*
*
*
*
*
*

Master Data
Sales
Special Business Transactions
Shipping
Billing
Credit Control
Sales Support
QM in SD
Internet
Transportation
Foreign Trade
Sales Information System
Electronic Data Interchange

SAP Logistics Information System

*
*
*
*
*
*
*

Sales Information System

Purchasing Information System
Inventory Controlling
Production Planning and Control Information System
Plant Maintenance Information System
Project Information System
Retail Information System

SAP QM - Quality Management

*
*
*
*
*
*
*

Planning
Inspections
Control
Notifications
Certificates
Test Equipment Management
QM-IS

SAP MM (Materials Management)

*
*
*
*
*
*

Logistics (General)
Logistics Information System
Purchasing
Inventory Management
Invoice Verification
Inventory / Valuations

*
*
*
*
*

Materials Planning
Workflow
External Services Management
QM in MM
Warehouse Management

SAP PM (Plant Maintenance)

*
*
*
*
*
*
*
*
*
*
*
*

Preventative Maintenance
Service Management
Maintenance Order Management
Maintenance Projects
Equipment and Technical Objects
Structuring Technical Systems
Maintenance Planning
PM Processing
Work Clearance Management
Internet Scenarios
Customising
Information System

SAP CS (Customer Service)

*
*
*
*

Service Processing
Service Contracts
Controlling
Workflow in Customer Service

SAP PP (Production Planning)

*
*
*
*
*
*
*
*
*
*
*
*
*
*

Make to Order (CR)

Make to Order (PIR)
Repetitive Manufacturing
PP for Process Industries (PP - PI)
PP - Processes
Sales and Operations Planning
Master Planning
Capacity requirements
KANBAN
Production Orders
Product Cost Planning
Assembly Orders
Plant Data Collection
Information System

SAP CA (Cross Application Components)

* Application Link Enabling (ALE)
* SAP Business Workflow
SAP PS (Project Systems)
*
*
*
*
*
*
*

Basic Data
Operational Structures
Project Planning
Approval
Project Execution and Integration
Information System
Work Breakdown Structure

mySAP SRM (Supplier Relationship Management)

*
*
*
*
*
*

Self Service Procurement

Service Procurement
Plan Driven Procurement
Spend Analysis
Strategic Sourcing
Catalogue Content Management

mySAP SEM
*
*
*
*
*

Business Consolidation (SEM-BCS)

Business Information Collection (SEM-BIC)
Business Planning and Simulation (BW-BPS)
Corporate Performance Monitor (SEM-CPM)
Stakeholder Relationship Management (SEM-SRM)

mySAP CRM (Customer Relationship Management)

*
*
*
*
*
*

CRM Enterprise
Field Applications
E-Commerce
Interaction Center
Channel Management
Industry Specific CRM

mySAP Product Life Cycle Management

* Document Management
* Enterprise Content Management

* Engineering Change Management

* Classification
* Basic Data for Process Manufacturing
SAP SCM (SAP Supply Chain Management)
*
*
*
*
*
*

SCM Process and Business Scenarios

SAP Advance Planning and Optimization (SAP - APO)
SAP Forecasting and Replenishment
SAP Inventory Collaboration Hub (SAP - OCH)
SAP Event Management (SAP - EM)
SCM Basis

SAP Netweaver
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*

SAP Masterdata Management

Portal Content
Information Integration
Process Integration
Life Cycle Management
Knowledge Management
SAP Visual Composer
SAP Business Intelligence
People Integration
Application Platform
Security
SAP Web Application Server
SAP Business Information Warehouse
SAP Enterprise Portal
SAP Solution Manager
SAP Mobile Engine

How to restrict users for not changing some fields in T-code va02?
There are two ways to do this:
- Make a transaction variant thru SHD0 and assign it to your sales doc. While creating the variant you can
place non-changeability ticks on specific fields. Next allow those users only to work with your transaction
variant but not with the original transaction.
- You could make use of user-exit FORM USEREXIT_FIELD_MODIFICATION in include MV45AFZZ (via
authorization objects, which you can assign in role customizing).
The latter is more flexible but it is not feasible if you want to place restrictions to a large amount of fields.

The following are the T-codes for central creation of customer master.
XD01
XD02
XD03
XD04
XD05
XD06
XD07
XD99
XDN1

Create Customer (Centrally)

Change Customer (Centrally)
Display Customer (Centrally)
Customer Changes (Centrally)
Block customer (centrally)
Mark customer for deletion (centr.)
Change Customer Account Group
Customer master mass maintenance
Maintain Number Ranges (Customer)

You can create a customer based on 3 views:

1. For Account purpose
FD01/FD02/FD03 etc
2. Sales purpose
XD01/XD02/XD03 etc.
3. Centrally
VD01/VD02/VD03 etc.

Two-step movement Plant to Plant

Within SAP Inventory Management, there are two methods how stock are moved
between plants using a 2-step process:

Stock Transport Orders (UB)

Transfer Posting

What does 2-step mean?

Example: Lets assume stock is moving from Plant A (Storage Location 0001) to Plant B
(storage location 0002).
Two step means that two transactions will be used to move the stock. After the first
transaction, stock has left plant A but it is not yet available at Plant B. Only after the
second transaction is it available for use in Plant B.Some reasons for using 2-step
movements (and not 1 step):
Long time span between leaving Plant A and arriving at Plant B. Need to control when
goods leave plant A but not received at plant B
Using Stock Transport Orders (STO)Steps:

Create a Stock Transport Order (ME21N, Purchase Order doc type UB)

Process Goods Issue against STO (MIGO > Goods Issue > PO) movement type
351

Process Goods Receipt against STO (MIGO > Goods Receipt > PO) movement
type 101

The use of Planned Orders and Purchase Requisitions are optional.

Using Transfer Postings (TP)Steps:

Process a Transfer Posting (MIGO > Transfer Posting) movement type 303

Process a Transfer Posting (MIGO > Transfer Posting) movement type 305

The Transfer Posting can be done with reference to a Reservation. Although this is not
used a lot. Similarities between Stock Transport Orders (STO) and Transfer Postings (TP)
Both use transaction MIGO for both steps
After first step, goods are already reflected in receiving plant and not
availableDifferences between Stock Transport Orders (STO) and Transfer Postings (TP)
Movement types are different351 & 101 for STO303 & 305 for TP
Stock types at receiving plants are different- In Transfer (MARC-UMLMC) for TP- Stock in
Transit (MARC-TRAME)for STO

For STO, 351 and 101 is group together where for TP there is no link between 303 and
305
STO requires more transactions than TP
STO must be configured for the sending plant / receiving plant where no plant specific
configuration exists for TP
STO is based on Stock Transport Order (type of Purchase Order). Where no purchasing
document is used for TP
STO can be initiated with a Planned Order or Purchase Requisition
Planning (MRP) can be used to initiate movements, but only STOsConfiguration required
to use STOConfig: MM > Purchasing > Purchase Order > Set up Stock Transport Order >
Assign Document Type, One-Step Procedure, Underdelivery Tolerance
Here the source plant, destination plant and allowed STO document type is specified.

Item category is determined automatically by the system based on the following

criteria:
Item category = Sales Document type + Item category group (in material master) +
Usage indicator (ABAP) + High Level I.Cat
It can be changed manually (if configured).
Sales Document types are configured atIMG: Sales and Distribution > Sales > Sales
Documents > Sales Document Item > Define Item Categories -- transaction VOV7

Configuration of Sales Document Schedule Lines

SAP version used in this post: SAP ERP Central Component (ECC) 5.0
Schedule Line catagory is automatically determined in an order (but may be changed
manually if set up) based on the following: Schedule Line category = Item category +
MRP Type of material.
Example: If Item category is TAN and MRP Type is VB, then the Schedule Line category is
CV

Schedule Line Categories are configured at:IMG: Sales and Distribution > Sales > Sales
Documents > Schedule Line > Define Schedule Line Categories - transaction VOV6

Lets look at Schedule Line Category CV

The key fields here are:

Movement Type (601): This is the movement type that will take place when a
Goods Issue is done.

Req. Assembly: Requirement visible in MM (example in tcode MD04)

Availability: Availability check to take place

User Exits in SAP SD

Suppose we want to see the available sales module user exits. Go to transaction SE81.
Click on SD, then click "edit" on the menu bar and choose select subtree. Click on
"information system," Open Environment node, customer exits, and enhancements.
Press F8 to get all the user exits for that module. In brief: SE81->SD->Select subtree>Information System->Envir->Exit Techniques->Customers exits->enhancements>Execute(F8)

USEREXIT
Userxits allow us to add our own functionality to SAP standard program
without modifying it . These are implemented in the form of subroutines and hence are
also known as FORM EXITs. The userexits are generally collected in includes and
attached to the standard program by the SAP.
All Userexits start with the word USEREXIT_...
FORM USEREXIT_..
z..
ENDFORM.
The problem lies in finding the correct userexit and how to find it if one exists for the
purpose. Once the correct userexit is found the necessary customer code is inserted in
the customer include starting with the z.. in the form routine.
e.g. USEREXIT_SAVE_DOCUMENT_PREPARE

Certain application like SD still provide this form of enhancement using userexit but this
practice is no longer being followed for newer extensions
instead they are using EXITs which come bundeled in enhancement packages .
Neverthiless existing USEREXITS will be supported by SAP an all the newer versions of
SAP.
HOW TO FIND USEREXITS
Userexits can be found in number of ways:
1) To find userexits 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 RV60AFZZ 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.

Difference between user exits & customer exits:

User exit - A user exit is a three character code that instructs the system to access a
program during system processing.
SXX: S is for standard exits that are delivered by SAP. XX represents the 2-digit exit
number.
UXX: U is for user exits that are defined by the user. XX represents the 2-digit exit
number
Customer exit - The R/3 enhancement concept allows you to add your own functionality
to SAPs standard business applications without having to modify the original
applications. 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. *-- Mani
The following document is about exits in SAP :The R/3 enhancement concept allows you to add your own functionality to SAPs
standard business applications without having to modify the original applications.
SAP creates user 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.
Types of Exits There are several different types of user exits. Each of these exits acts as
hooks where you can attach or "hang" your own add-ons.
Menu Exits Menu exits add items to the pulldown 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 items 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 subscreen areas on a standard R/3 screen and calling a
customer subscreen from the standard screens flow logic.
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. SAP application developers create function module exits by writing calls to
customer functions into the source code of standard R/3 programs.
These calls have the following syntax:
CALL CUSTOMER-FUNCTION 001.
Field Exits Field exits allow you to create your own programming logic for any data
element in the Dictionary. You can use this logic to carry out checks, conversions, or
business-related processing for any screen field. Example: The data element BBBNR
identifies a companys international location number. You might want to set up your R/3
System so that all international location numbers are larger than 100.
The field exit concept lets you create a special function module that contains this logic.
You assign the special function module to the data element BBBNR. You then assign the
module to any programs and screens in which users can add new international location
numbers. When you activate your field exit, the system automatically triggers your
special routine whenever a user enters a company location number.
In 4.6c, you can use "RSMODPRF" program to create field exits.
An example of a user exits :MODULE user_exit_0001
INPUT CASE okcode.
WHEN 'BACK OR EXIT'.
CASE sy-dynnr.
WHEN '100'.
SET SCREEN 0.
LEAVE SCREEN. WHEN '200'.
**Note that you can write any code that satisfy your needs. But in this case, this was
wrote as a sample code for reference sake. And you can test it. ****
SET SCREEN 100.
LEAVE SCREEN.
ENDCASE.
ENDCASE.