SD Life cycle

SAP SD Flow:
Inquiry -> Quotation ->Sales Order ->Delivery ->Invoice -> Return -> Credit memo

Transaction Codes
VA01 Create Sales/Returns Order
VA02 Change Order
VA03 Display Sales Order

VA11 Create Inquiry
VA12 Change Inquiry
VA13 Display Inquiry

VA21 Create Quotation
VA22 Change Quotation
VA23 Display Quotation

VA41 Create Contract
VA41 Change Contract
VA43 Display Contract

VF01 Create Billing Document
VF02 Change Billing Document
VF03 Display Billing Document
VF11 Cancel Billing Document

VF21 Create Invoice List
VF22 Change Invoice List
VF22 Display Invoice List

VK11 Maintain Pricing
VK15 Create Condition Records(Transaction used to enter multiple sales conditions)

VL01N Create Delivery
VL02N Change Delivery
VL03N Display Delivery

Inquiry

quotation

contrancts and Scheduling agreements
(Value contract or quantity contract)

Sales order

Delivery - Pick - pack - shipment

Post goods issue

Billing - release to accounting

[Check the document flow in table VBFA ]


SD important tables are

VBFA Document flow (alg.)
VTFA Flow shipping documents

Sales order :
VBAK Header data
VBAP Item data
VBPA Partners in sales order
VBKD Sales district data
VBEP Data related to line items, delivery lines

Billing document :
VBRK header data
VBRP Item data

Shipping :
VTTK Shipment header
VTTP Shipment item
VTTS Stage in transport
VTSP Stage in transport per shipment item
VTPA Shipment partners
VEKP Handling Unit - Header Table
VEPO Packing: Handling Unit Item (Contents)

Delivery :
LIKP Delivery header
LIPS Delivery item

Pricing :
KONH Conditions header
KONP Conditions items
KONV Procedure ( billing doc or sales order)
KOND

Contracts :
VEDA Contract data


http://www.businessworks.co.in/

Change Pointers in SAP

Change pointers are R/3 objects that mark changes to SAP master data. Change pointers are managed by mechanisms in a Shared Master Data (SMD) tool and are based on Change Document (CD) objects. CD objects record the changes occurring to master data at a field level. These changes are stored in tables CDHDR (header table) and CDPOS (detail table).
ALE configuration provides a link between CD objects and change pointers. Internal mechanisms update tables BDCP and BDCPS, which host the change pointers. While CD objects are application-data-specific, the processing status of change pointers is message-type-specific. Also, the ALE change pointers are activated first at a general level and then at the message-type level.
ALE provides powerful capabilities to capture changes occurring to master data and to distribute them via the IDOC interface. This feature can be used to keep two or more systems synchronized with respect to master data.

Steps to configure change Pointers:
1. BD61 - Activate the change pointers globally
2. BD50 - Activate the change pointers for individual message types(BD50)
3. RBDMIDOC - Schedule the program RBDMIDOC to run periodically on the sending system.

For Delete Change pointers Tcode BD22 and the standard program is RBDCPCLR
Reduction tool(reduced message types) using Tcode BD53

See the check box in Further characteristics tab of the data element for change document.SE11-->enter data element-->Further characteristics tabThe check box is to be checked to trigger change pointers.
The change pointer tables (BDCP & BDCPS) should be as small as possible. Use as few change pointers as possible and delete change pointers which you no longer need.

Activities - Keep it limited
1. Do you really need change pointers?You need change pointers to distribute changes with the ALE SMD tool. If you do not use this tool, you do not need to write change pointers.You can deactivate change pointers and activate them again with the transaction BD61.

2. Do you really need to activate change pointers for this messages type?
If some messages types are no longer to be distributed by change pointers, you can deactivate change pointers for this messages type.You can deactivate change pointers for the message type and reactivate them again.For reduced message types, deactivate the change pointer with the Reduction tool (Tcode BD53).

3. Are there still too many change pointers to be processed?
The change pointers are analyzed with the transaction BD21 or the report RBDMIDOC in ALE and flagged as processed. If the change pointers are created periodically, this report should also run periodically.

4. Are no longer required change pointers reorganized in time?
The report RBDCPCLR (transaction BD22) to reorganize the change pointer should run periodically. Depending on how many change pointers are created or processed, you can schedule the background job hourly, daily or weekly. You should delete all obsolete and processed change pointers. You can also use this report for specified message types

SAP SD Integration points

Sales order –
Integration points - Module
• Availability check - MM
• Credit check - FI
• Costing - CO/MM
• Tax Determination - FI
• Transfer of Requirements - PP/MM

Delivery & goods Issue-
Integration points - Module
• Availability check - MM
• Credit check - FI
• Reduces stock - MM
• Reduces Inventory $ - FI/CO
• Requirements Eliminated - PP/MM

Billing –
Integration points - Module
• Debit A/R - FI/CO
• Credit Revenue - FI/CO
• Update G/L - FI/CO
(Tax, discounts, surcharges, etc)
• Milestone Billing - PS

Return Delivery & credit memo-
Integration points - Module
• Increases Inventory - MM
• Update G/L - FI
• Credit Memo - FI
• Adjustment to A/R - FI
• Reduces revenue - FI

SAP - Some Useful transactions(TCode)

S.No. Requirement Solution(TCode)
1 Generate All SAP Programs SGEN
2 Data transfer workbench SXDA
3 Maintain Tasks PFTC
4 SAPscript: Standard Texts SO10
5 CHANGE the subcon STOCK MIGO
6 Please specify your working directory SO21
7 demo/examples DWDM
8 Report Tree Display SARP
9 Structure for passing print parameters PRI_PARAMS
10 Create Message Class/ID SE91
11 Standard Text SO10
12 Auto Generate the Sequence NUMBER_GET_NEXT
13 Update charcterstics of material CL03
14 Value range for characterstics CT04
15 Creation of Quote MEQ1

Customization Settings:
SWU3 - Automatic Customizing Workflow
SCOT - SAP to mail server Configuration
SU01 - User Maintenance
Workflow Design:
SE37 - Function Builder
SE38 - ABAP Editor
SWO1 - Business Object Builder
PFTC - Task Maintain
SWDD - Workflow Builder

Runtime Behavior/Analysis:
SBWP - Business Workplace
SWUD - Workflow Diagnosis
SWU_OBUF - Synchronize Runtime Buffer
SWPR - Workflow Restart after Error

Enter your search terms Submit search form

Basics for IDoc processing

::Initials/Basics for IDoc processing::
Message Type :: The message type defines the semantic context of an IDoc. The message type tells the processing routines, how the message has to be interpreted. The same IDoc data can be sent with different message types.

IDoc Type :: An IDoc type defines the syntax of the IDoc data. It tells which segments are found in an Idoc and what fields the segments are made of.

Processing Code :: The processing code is a logical name that determines the processing routine. This points usually to a function module, but the processing routine can also be a workflow or an event. The use of a logical processing code makes it easy to modify the processing routine for a series of partner profiles at once.

Partner profile :: Every sender-receiver relationship needs a profile defined. This one determines * The processing code * The processing times and conditions * In the case of outbound IDoc 1. The media port used to send the IDoc and 2. Triggers used to send the IDoc

Partner Type :: The IDoc partners are classified in logical groups. Such as : LS, KU, LI. LS - Logical Systems : It is meant to be a different computer and was primarily introduced for use with the ALE functionality. KU - Customer : The partner type customer is used in classical EDI transmission to designate a partner, that requires a service from your company or is in the role of a debtor with respect to your company, e.g. the payer, sold-to-party, ship-to-party. LI - Supplier : The partner type supplier is used in classical EDI transmission to designate a partner, that delivers a service to your company.

ALE comprises three layers:
• the applications services,
• the distribution services,
• the communications services

Steps to configuration(Basis) >>
1. Create Logical System (LS) for each applicable ALE-enabled client
2. Link client to Logical System on the respective servers
3. Create background user, to be used by ALE(with authorizaton for ALE postings)
4. Create RFC Destinations(SM59)
5. Ports in Idoc processing(WE21)
6. Generate partner profiles for sending system

The functional configuration(Tcode: SALE)
• Create a Customer Distribution Model (CDM);
• Add appropriate message types and filters to the CDM;
• Generate outbound partner profiles;
• Distribute the CDM to the receiving systems; and
• Generate inbound partner profiles on each of the clients.

Steps to customize a new IDoc >>>
1. Define IDoc Segment (WE31)
2. Convert Segments into an IDoc type (WE30)
3. Create a Message Type (WE81)
4. Create valid Combination of Message & IDoc type(WE82)
5. Define Processing Code(WE41 for OUT / WE42 for IN)
6. Define Partner Profile(WE20)

ProgramsRBDMIDOC – Creating IDoc Type from Change PointersRSEOUT00 – Process all selected IDocs (EDI)RBDAPP01 - Inbound Processing of IDocs Ready for TransferRSARFCEX - Execute Calls Not Yet ExecutedRBDMOIND - Status Conversion with Successful tRFC ExecutionRBDMANIN - Start error handling for non-posted IDocsRBDSTATE - Send Audit Confirmations

01 Error --> Idoc Added
30 Error --> Idoc ready for dispatch(ALE Service)then goto SE38 --> Execute the Program RBDMIDOC
29 Error --> ALE Service Layer then goto SE38 --> Execute the Program RSEOUT00
03 Error --> Data Passed to Port okthen goto SE38 --> Execute the Program RBDMOIND
12 Error --> Dispatch ok

Good Luck :)