0% found this document useful (0 votes)
216 views20 pages

SD Preparation

The document describes the process for handling third-party sales in SAP. When a customer places an order, a sales order is created which then automatically generates a purchase requisition. The vendor receives the purchase order and ships goods directly to the customer. The vendor's invoice is entered and an invoice is created for the customer based on the original sales order. Key aspects of the third-party process in SAP include automatic/manual item category determination, use of item category TAS, and schedule line category CS.

Uploaded by

Ramesh Kumar B
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
216 views20 pages

SD Preparation

The document describes the process for handling third-party sales in SAP. When a customer places an order, a sales order is created which then automatically generates a purchase requisition. The vendor receives the purchase order and ships goods directly to the customer. The vendor's invoice is entered and an invoice is created for the customer based on the original sales order. Key aspects of the third-party process in SAP include automatic/manual item category determination, use of item category TAS, and schedule line category CS.

Uploaded by

Ramesh Kumar B
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 20

SD Tickets Handling:

Excellent explanation. But as a consultant we don't have access to production server. once the issue
raised by the end user if that issue is assigned to us we go to pre-production server and will do the
same transaction...at that time we should get the same error like end user. Because pre-production
server is the mirror image of production server. Once we get the error in the pre-production server
we will go to the development server and will do some necessary configuration and will generate the
request for that issue. BASIS consultant will transport that request to Quality server have mentioned
that end users will test the issue in quality server, but end users don't have access to quality server.
After transporting the request to quality server we send this to CORE-USER to test it and for the
approval purpose. Once the approval is made then BASIS will transport the request to production
server. Hence the status of the issue is closed.

Business Scenario:

Difference between User Exit and


Routines
 05 Feb 2008 7:37 am ||  0

Routines vs User Exit in SAP


User exit
In this step, you can implement the user exits listed below.

You should carry out this step only if both of the followings apply:

1. The SAP standard processes does not suit your needs.


2. You are a competent ABAP/4 programmer.

User Exit Replaces


PBEN0001 Feature BAREA
PBEN0002 Feature BENGR
PBEN0003 Feature BSTAT
PBEN0004 Feature CSTV1
PBEN0005 Feature CRDV1
PBEN0006 Feature ELIGR
PBEN0007 Feature TRMTY
PBEN0008 Function HR_BEN_CALC_BENEFIT_COST
PBEN0009 Function HR_BEN_CALC_BENEFIT_CREDIT
PBEN0010 Function HR_BEN_CALC_BENEFIT_SALARY
PBEN0011 Function HR_BEN_CALC_COVERAGE_AMOUNT
PBEN0012 Form CALC_ELIG_DATE
PBEN0013 Form CALC_TERM_DATE
PBEN0014 Function HR_BEN_CALC_SAVE_ER_CONTRIB
PBEN0015 Form CHECK_ELIG_SERVICE
PBEN0016 Function HR_BEN_CALC_PARTICIPATION_DATE
PBEN0017 Feature EVTGR
PBEN0018 Feature COVGR
PBEN0019 Feature EECGR
PBEN0020 Feature ERCGR
PBEN0021 Funtionmodule HR_BEN_CALC_SPEN_ER_CONRIB
PBEN0022 Function HR_BEN_GET_PROCESS_DATES
PBEN0023 Function HR_BEN_CALC_CUTOFF_AGE
PBEN0024 Function HR_BEN_CALC_CUTOFF_LOS
PBEN0025 Function HR_BEN_CALC_CUTOFF_SAL
PCOB0001 COBRA Letter
PCOB0004 Form HR_BEN_COB_GET_TOTAL_COSTS

If you need to implement any of these User exits, you first create a
project for the user exit, then assign the user exit(s) to your project. Then
you write the coding for the user exit, and finally activate the project.

For general information about user exits, in the R/3 Library, go to Basis
components and look at the Enhancements section. In addition, there is
detailed information about each user exit that you can access when you
assign it to your project (see below).

Activities

Start by creating your project.

1. Enter a name for your project.

2. Select Modification -> Create.

3. Enter a short text for your project and select save.

Next assign the user exit to your project.

4. Select Components.

5. Enter the name(s) of the user exits you want to implement.

6. Select SAP documentation, if you want detailed information on this


user exit.

7. Select save.
8. Select back.

Next make your coding modifications.

9. Select enhancement components.

10. Select change.

11. Select the user exit you want to write code for.

12. Select the include zxpbco01.

The system will then prompt you to create this include, and you can
continue to write your coding in it.

Next activate your project.

13. Return to the initial screen and select activate project.

Routines
Routines are short sub-programs that carry out various checks during
document processing. In the SD module, you can create and process
routines for copying requirements, data transfer, requirements and
formulas using transaction VOFM. Besides the routines delivered to you
with the system, you can create your own individual routines.

Transaction VOFM allows you to follow a standardized procedure for


creating routines. The name ranges are predefined for routines delivered
to you with the system and for routines created by the customer. This
name convention guarantees that your own routines are not overwritten
during a Release upgrade.

Copying requirements and data transfer

The routines for coying requirements and data transfer are defined for the
document types sales orders, deliveries, billing documents, sales
activities, as well as for texts. You specify copying requirements and the
data transfers when defining the document flow for each document type.
You enter the routines for texts in the access sequences for texts.

 Copying requirements determine which data is copied during the


copying of documents. A copying requirement could define, for
example, that the same customer must appear in the document
header when you copy an inquiry to a quotation.
 Routines for data transfer make a detailed control of the copying of
fields possible. A data transfer could define, for example, that
particular item fields can only be copied in combination with other
particular fields and can only be copied into contracts or credit and
debit memos.

Requirements and formulas

Routines for requirements and formulas are used for functions using
the condition technique. You enter these routines in the pricing
procedure or the condition types. Requirements are also used for
statistics.

 A requirement in pricing can determine that an access is dependent


on a particular precondition. It can carry out a check of the
document currency, for example, and, depending on whether it is a
foreign or the local currency, allow or deny the access.
 Formulas are used in pricing to define various factors for pricing.
Formulas are defined for scale base value, condition base value,
condition amount, group key, and rounding rules. The formula for a
rounding rule could define, for example, that all calculated amounts
are rounded to two places behind the decimal point during a price
change of the condition record. The formula for a condition base
value could define, that the header discount is distributed among
the order items according to volume an not value of the item, as is
the case in the standard SAP R/3 System.

Creating routines

There are two methods to create a routine

1. Creating by overwriting

When using this method, a note appears as a commentary in the routine


to be newly created.

2. Creating

When creating a new routine, an ABAP with internal number assignment


is created.

You always have to activate a new routine before using it. Each routine
for requirements and formulas, copying requirements and data transfers
is stored in a separate program. For each new routine an entry is added in
table TFRM and TFRMT. For each routine, a long text can be stored as a
text module.

Most routines must be changed in client 000. Transaction VOFM can be


transported as XPRAs, which means that after the import all routines can
be activated.
Name ranges for routines

 The standard routines are to be within the number range 001-599


(for 2 digit formula numbers, 01-49)
 The user routines are to be within the number range 600-999 (for 2
digit formula numbers, 50-99).

Interface to the transport system

For technical reasons, an interface to the transport system is not possible


at the moment. Until up to and including Release 3.0, developments have
to be transported manually using correction numbers and transport
requests.

Read Here for More

Business Process:

1.Third-party process overview


73 Likes 125,129 Vie ws  36 Comments

In third-party process the delivery of the goods required by the customer is not done by sales
organization where customer orders. Instead, the request of the goods is forwarded to an
external vendor who sends the material directly to the customer.

Here is what happens in third-party process:

1. Customer orders goods and a sales order is created in a sales organization


2. Purchase requisition is created automatically when sales order is saved.
3. Purchase order is created at the vendor in the MM purchasing application (manually or
automatically)
4. If the vendor does the outbound delivery to the customer, the goods receipt can be
posted in the system
5. Invoice receipt is created (invoice from vendor)
6. Invoice to customer is created (order based invoice)

SALES ORDER

Third-party process is triggered when the sales order with third-party item is created. Depending
on settings done in customization third-party item categories can be automatically determined by
the system (automatic third-party processing) or they can be changed from standard item to
third-party item category in sales order (manual third-party processing).

Sales order type used for third-party – OR (standard order)

Item category for third-party – TAS

Schedule line category for third-party – CS


Let’s look deeper into the settings in the system done for automatic and standard third-party
process:

ITEM CATEGORY TAS:

Create PO Automatic indicator is not marked in TAS. ALES is an item category for third-party
processing where this indicator is marked.

ITEM CATEGORY DETERMINATION

Item category TAS will be determined automatically for standard order (OR) and item category
group BANS (third-party item). Item category group can be found in material master, Sales:
Sales org.2 view.

SCHEDULE LINE CATEGORY CS


Data: Order type = NB, Item Category = 5 and Acct.AssgntCat  = X is the data for Purchase
requisition. If it is filled like above the purchasing requisition will be created automatically as
standard purchasing requisition (NB), with item category S and acc.assign cat X. The mapping of
item category (from 5 to S) can be found in IMG:  MM->Purchasing->Define External
Representation of item categories. The definition of account assignment category can be found
in IMG: MM->Purchasing->Account assignment->Maintain acc.***. categories

SCHEDULE LINE CATEGORY DETERMINATION  

THIRD-PARTY PURCHASE REQUISITION

After saving sales order with item category TAS the purchase requisition is automatically created.
In order to see the document go to: Environment -> Status overview and expand data for item,
then expand data for purchase requisition as well:
Double click on the requisition number and you will be taken to the purchase requisition
document. The other way is to go to schedule line where you can find the purchase requisition
number.

If third-party item has more than one schedule line with confirmed quantity > 0, then purchase
requisition is created for each schedule line.

It is wise to have the vendor determined in source of supply at this stage of the process (i.e.
source list)

MANUAL PURCHASE ORDER

The purchase requisition needs to be converted into purchase order in MM (t-code me21n). The
purchase order document type is NB (standard order), item category S, that must be assigned to
account. Thus account assignment category needs to be given. In this example it is X
(automatically taken during conversion from purchase requisition, as it was defined in item
category CS).

The definition of acct assignment category can be found in IMG: MM->Purchasing->Account


assignment->Maintain acc.***. categories:

Note: There is also a third-party account assignment category created in the system and its
definition looks as follows:
The mapping of item categories: IMG:  MM->Purchasing->Define External Representation of
item categories:

AUTOMATIC PURCHASE ORDER

As it was written before – the purchase requisition is created automatically when sales order is
saved. It is possible to automatize the next step, the creation of purchase order, as well. The ALE
function is used for that purpose.  The indicator for the automatic creation of purchase order is
not set for TAS item category. However, there is a special item category – ALES which can be
used instead in third-party process. The indicator for the automatic creation of purchase order is
marked in ALES by default.

Prerequisites for the automatic creation of purchase order are as follows:

 The indicator automatic purchase order needs to be marked in item category definition


(item category ALES has it by default)
 Unique source of supply needs to exist for third-party item
 At least the document type for the purchase order must be assigned for Sales
organization in customizing under Enterprise structure->Definition->SD->Define, copy,
delete, check sales organization
If all above prerequisites are set up correctly, purchase order will be created when sales order is
saved. Then, it can be found in document flow in sales order.

GOODS RECEIPT

Since during third-party processing goods are moved directly from the vendor to the customer,
inventory management is not affected by this event. However, if sales department would like to
document and enter delivery to the customer in the system it is possible depending on settings in
customization. If account assignment category 1 is used in item category definition, goods receipt
is not possible, as the goods receipt indicator is not set for this account assignment cat. If
account assignment category X is used, goods receipt is possible.

The goods receipt posting (t-code migo) would have the following effects:

 The warehouse stock is not updated


 The goods receipt is posted directly to consumption and the consumption quantity is
updated
 The order value is posted to a GR/IR clearing account for invoice verification purposes
 The goods receipt can be traced in the purchase order history

The goods receipt posting should happen when the vendor reports that outbound delivery was
executed or customer confirms that delivery arrives.

Since no flow of goods occurs in the enterprise, the goods receipt posting results in updates on
value basis.

INVOICE RECEIPT

The invoice verification with reference to purchase order needs to be created when invoice from
vendor arrives to enterprise (t-code miro). The value and, if goods receipt was done earlier, the
quantity are proposed by the system. When the incoming invoice is posted following are updated:

 Purchase order history


 G/L  accounts
 The vendor account in subledger accounting, as well as the liabilities account (general
ledger)
CUSTOMER BILLING DOCUMENT

Once invoice receipt has been entered, the customer can be billed as well (t-code vf01). Since
an outbound delivery doesn’t exist for the third-party the invoicing will be order based. In the item
category TAS definition, the billing relevance indicator is set to F by default. That means: relevant
for order-related billing document: status according to invoice receipt quantity. That is, the
system allows invoicing the order only when vendor’s invoice has been processed in invoice
verification.

The customer invoice is created for the quantity specified in the vendor invoice. The setting in the
copy control for the third-party item category from sales document to billing document specifies
that the quantity from the invoice receipt is transferred to the billing document instead of the
order quantity (billing quantity indicator in copy control is F)

2.STO

Large companies having many plants in different geographical locations


commonly require stock movement from one plant to another. For this purpose, SAP
ERP has a special process with SAP stock transport order (STO) that enables to
move stock from one plant to another or between different storage locations of
plants.

For example, in one of my trading client, we used to import materials from abroad in
big containers and then those containers were unloaded into one big branch (plant)
as it was cost efficient to import materials in bulk to one location. Next, other smaller
branches (plans) raised SAP stock transport order (STO) to purchase stock from big
branch for the quantity required. The big branch dispatched the quantity against the
STO on the mentioned delivery dates.

In the below screenshot, you can see a diagram illustrating the stock transfer
process. STO is raised by a receiving plant and sent to a supplying plant. The
supplying plant then delivers the material, which in the SAP system will be shown as
stock in transit. When the receiving plant receives the material, goods receipt takes
place at the receiving plant. There is no invoicing, as the stock is
transferred between plant that are part of the same company.
Stock Transfer with SAP Stock Transfer Order (Example)

How to Create SAP Stock Transport Order?


To create a stock transport order in SAP, please follow the steps described below.
First, either start the transaction ME21N or navigate to the following path in SAP
menu: Logistics – Materials Management – Purchasing – Purchase Order – Create –
ME21N – Vendor/Supplying Plant Known.
Menu
Path for ME21N Transaction

Stock transfer process uses the standard transaction ME21N for creating purchase


orders (PO), where we trigger STO process by selecting document type = Stock
Transport Order as shown on the screenshots below.
ME

21N – Create a Purchase Order Select Stock Transport Order as the


Document Type

Here you need to provide your supplying plant. As mentioned above, the supplying
plant in our example is the big branch which imported the stock and has stock
available. You also have to provide your purchase organization, purchase group and
company code as show on the screenshot below. Our tutorials about SAP MM
organizational structure should be helpful in learning more about purchasing
organization and other MM organizational units.

Enter Supplying Plant, Purchasing Organization, and Company Code in STO


In the item overview screen below, you need to provide the material that you would
like to procure from the supplying plant along with the plant number which is ordering
this material, quantity, storage location and delivery dates as shown below:

Items of Stock Transport Order

If you have any additional charges which needs to be added to the cost of the
material, you should provide the details in the conditions tab. For instance, it is
possible to add freight charges as shown below:

Pricing Conditions of Stock Transport Order

Now, your stock transport order is ready and to cross check for any errors in your
STO, click on   button which will tell you if everything is correct in your document.
If not, then a red button will come up notifying you about error(s) in the document
that needs to be fixed before you can save the document. Once all issues are fixed,
you click the   button, which will save the document. The SAP system will provide
you with SAP generated document number as shown below notifying that the
document has been created.

SAP Stock Transport Order has been


Created

Goods Issue Against SAP Stock Transport Order


Once the STO is created, the next step is to do a goods issue against the STO
raised above. Go to the transaction MIGO or navigate to the following path in SAP
menu: Logistics – Materials Management – Inventory Management – Goods
Movement – MIGO.
MIGO Transaction in SAP Menu

In MIGO, it is necessary to do goods issue against a purchase order, with a


movement type 351 which is used for moving materials from supplying plants to
stock in transit of receiving plants.

Goods Issue in MIGO Transaction

Here you need to enter the number of STO, set OK checkbox for the item and then
click on Post button which will post your goods issue and provide you a message
that a material document was created (see screenshots below).
Set OK Checkbox for the Item A Material Document for
Goods Issue against SAP Stock Transport Order was Created

Goods Receipt Against SAP Stock Transport Order


Now, the last step is to do goods receipt in the receiving plant when the goods
physically arrive there. Goods receipt is also done in MIGO transaction. It is
necessary to perform goods receipt against a purchase order using the movement
type 101 as shown below. Then, set the OK checkbox next to the material item and
finally post the document by pressing Post button. The system will provide you a
message that the material document was posted.
Goods Receipt against STO A Material Document for
Goods Receipt against SAP Stock Transport Order was Created

Did you like this SAP MM tutorial? Have any questions or comments? We would love
to hear your feedback in the comments section below. It’d be a big help for us, and
hopefully it’s something we can address for you in improvement of our free SAP MM
tutorials.

3.
Inter Company Sales Process

Explain the Inter Company Sales Process.

In SAP sales & distribution module, an intercompany sales occurs when the selling
organization belongs to a different company code than the delivering plant. The
transaction path for accessing intercompany sales billing is:

IMG >> Sales and distribution >> Billing >> Intercompany billing

Let us take an example to understand intercompany sales better. Suppose there are
two company codes namely 1000 and 2000. A customer may place an order for
goods in sales organization belonging to company code 3000. However, the goods
may be manufactured by a delivering plant belonging the company code 1000. A
sales order is created indicating delivering plant of company code 1000. The sales
organization then invoices the customer for the materials purchased. SAP R/3
automatically creates an intercompany billing document at the same time as the
customer’s billing document is created. This intercompany invoice is sent from the
delivering plant to the selling sales organization. 
As a rule of thumb, when dealing with different company codes, one may find a
need to transfer stock between two different company codes. However, if the stock
be transferred within the same company code, there is no need for an intercompany
transaction. But in case the stock is transferred between different company codes, a
transfer of value occurs and is an intercompany sale.

---

In inter- company sales process, no PO will raise.

While creating sales order, if the end user knows there is no stock on their plant,
they request for their sister concern company to deliver these ordered goods to the
customer directly, after delivery they will receive intercompany invoice from the
delivering company code, that’s the reason you enter delivering plant while
creating sales order.

Below is the inter-company check list:

Check all your settings once again for creating inter-company billing:

- Material should exist in both plants.

- Stock will be maintained in D-Plant (Delivering).

- Now Plant - R (Receiving) become the customer of Plant-D.  So create a dummy


customer in Plant-D's company code and sales area. 

- Assign this customer number to Plant -R's details & its selling sales area.

- Maintain the intercomapny billing type (IV) in ur sales doc type (OR).

- Assign the Plant-D to selling sales org+ dbt channel.

- Maintain relevant copy controls between documents.

- Determine pricing procedure for Standard (RVAA01) as well as Intercompany


(ICAA01)
(Note: Dummy customer's CPP, IV doc's DPP along with Delivering plant's sales
area)

- Maintain the condition records for Condition type PI01- VK11 


(Note: In ICAA01, you won't find any PI01 Ctype, but you'll find IV01-, if you
observe the details of IV01 C.type in V/06, it has the ref Ctype as "PI01" , through
which the condition record of PI01 is shared to IV01 also..)
- Now create VA01, enter the required fields, in delivering plant -enter Plant-D, @
item level as well as @ header level, and save,

- Create Delivery VL01n, with ref to SO,

- Create Billing VF01 (with ref to DEL)--- observe bill type-F2,

- Create Billing VF01 (with ref to DEL again)--observe the bill type-IV.

3. Business process Flow chart:

1.Sales order for Retail=IN-QT-Sales order-Delivery(Picking,Packing & PGI)-Billing-Invocie-AR


Processing-invoice
2.MTO=IN-QT-Sales Order- Delivery(Picking,Packing & PGI)-Billing-Invocie-AR Processing-
invoice
3.Project Sales=IN-QT-Sales order- project will get created and shipping and billing activities
will be carried thorugh project system-Delivery & PGI-Invoce
4.Third party=IN-QT-Sales order-Purchase order-Logical Goods Receipt-Invocie
5.Consignment process=IN-Sales order-Delivery & PGI
6.Free of charge Delivery=IN-Sales order-Delivery & PGI-Invoice
7.Return order=Previously Created invoice-Sales order return w.r to invoice-Delivery & PGI-
Credit Memo
8.Stock Transport order= Stock transport order creation by receiving plant- Delivery of
products from supplying plant-Proforma Invoice
9.Export Sales order=sales order processing for MTO-IN-QT-Negotiations / Customer
acceptance(PO)-Sales order-Delivery,Picking,PGI-Billing-Invoice-AR-Invoice
10.Customer Subcontracting-Sales order-Delivery-Invoice
11.Deemed Export sales=IN-QT-Sales order-Delivery-ARE-3 doc(Doc for excise exemption)-
Billing-Invoice

You might also like