SAP SD tables

Here is the list of important tables used in SAP sales and distribution component. Tables for Sales documents

VBUK: Table contains Header Status and Administrative Data of sales documents VBAK: Table contains Sales Documents Header Data VBKD: Table contains Sales Documents Business Data VBUP: Table contains SD order item Status VBAP: This contains SD order item Data VBEP: Sales Document Schedule Line data VBEH: Sales Document Schedule Line history VBBE: Sales Requirements: Individual Records VBEX: SD document export control KANZ: Assignment of Sales Order Items Costing Objects VBFCL: Sales Document Flow Cluster VBLB: Sales Document: Release Order Data VEDA: Contract Data

Sales activities

NAST: Message status SADR: Company address management VBFA: SD Document Flow VBKA: Sales Activities VBPA: Sales documents Partners VBUK: Sales Document: Header Status and Administrative Data VBUV: Sales Document: Incompletion Log

Tables for billing documents

EIKP: table for Foreign Trade: Export/Import Header Data EIPO: Foreign Trade: Export/Import: Item Data FPLA: Billing Plan FPLT: Billing Plan: Dates FPLTC: Payment Cards: Transaction Data SD KOCLU: Cluster for Conditions in Purchasing and Sales NAST: Message Status

SADR: Address Management: Company Data VBFCL: Sales Document Flow Cluster VBPA: Sales Document: Partners VBRK: Billing Document: Header Data VBRL: SD Document: Invoice List VBRP: Billing: Item Data VBUK: Sales Document: Header Status and Administrative Data

Shipments

VTTK: Table contains Shipment documents Header data VTTP: Table contains Shipment documents Item data VTTS: Shipment document: Stages VTPA: Partner for shipment VTFA: Shipment document flow VEKP: SD document: Shipping unit header VEPO: SD document: Shipping unit item (contents)

Deliveries

LIKP: SD document: Delivery: Header data LIPS: SD document: Delivery: Item data

SAP ALE Tutorial

The full form of ALE is Application Link Enabling. ALE is the fundamental component of SAP for exchanging data between SAP system and non-SAP systems for business integration purpose. ALE is using

Synchronous/asynchronous

communication for reading data

and asynchronous

communication for writing data. The major advantages of ALE are Application data can be distributed between different SAP releases Data can continue to be exchanged after a release upgrade without requiring special maintenance

Customers can add their own enhancements Communication interfaces enable connections to non-SAP systems

IDOCs (Intermediate Documents) are used to transfer the data in ALE. These IDocs are created and dispatched in distributed systems using message types and BAPIs.So ALE distribution can be Distribution using BAPI or Distribution using message types.

Basic process flow of ALE

In Outbound system the IDOC containing data will be created and prepared for dispatch. Then this IDOC will send to the target system In target system inbound processing will start on IDOC and the data will be posted in application.

ALE System structure

Application layer ALE layer Communication Layer

Outbound and inbound processing is occurring at Application layer and ALE layer. Communication layer is responsible for transferring the data between system using trfc or EDI file interface. ALE provides various tools for Monitoring data transmission, Error Handling, Synchronization, Consistency checks etc for the communication between distributed application systems. Transaction code SALE can be used to view the basic ALE settings and description. To access the ALE tools choose the path Tools -> Business Framework -> ALE

SAP IDOC structure tutorial

What is SAP IDOC The full form of IDoc is Intermediate Document. Its a SAP standard document format for exchanging data between different application servers. The Idoc interface will contain the data structure and processing logic. The data structure is known as IDoc.Using IDoc different application servers can be connection via a message based interface. It has an extensive exception handling before the data is stored in the application server. Electronic Data Interchange (EDI) and Application Link Enabling (ALE) are the main techniques using IDoc to exchange data between systems. Segments are the basic building blocks of Idoc and store the actual data. SAP supplies some IDocs by default and they are known as basic types of idoc. We can add additional data to the existing basic types using reference segments. We can define our own IDoc types if the basic types wont fit for our requirements. Structure of an IDOC Every IDoc consist 3 records they are Control Record: It contains the general information about that IDoc. It stores the sender identification, receiver identification and IDoc type.Cotrol Records are stored in the data dictionary

table EDIDC and it can be views by transaction code SE11.Idoc type is the key information for IDoc processor to interpret the data containing in that IDoc. Important Fields containing in Control records are

Mestyp: (Logical message type) Idoctp: (Idoc type -Basic structure of the IDoc) Cimtyp: (Structure of customer extension) Rcvprt: (Partner type of the receiver) Rcvprn: (Partner number of the receiver) Rcvpfc: (Partner function of the receiver)

Data Records: It contains the actual data to process.Data records are stored in the data dictionary table EDIDD.Data records consists with two parts segment name and segment data. For each segment type of the IDoc structure, there is a DDIC structure with the same name. A field string with this structure is used for creating a data record. The application data is mapped to the field string. The segment type is written to the field SEGNAM, and the field string is written to the field SDATA. This data record is then included in the internal table with the structure edidd. The fields in data records are

Segnam: (Segment type) Sdata: (Actual data with maximum 1000 byte-long character)

Status Record: It stores the status of IDOC. The status records are stored in the data dictionary table EDIDS. The important fields in these records are

DOCNUM STATUS STATXT SEGNUM

Steps to create a basic type Idoc

Creation of a new basic type of IDOC consists of several steps. Here is the detail explanation and steps to do for that. Step 1: Creation of Segments Here are the steps to define segments

Enter Transaction code WE31 Select Utilities -> Requests (Organizer) Specify segment type and choose create Enter a short description of the segment and enter the corresponding field names and data elements associated with that segment.

Goto -> Documentation and describe the segment type Come back to segment editor Save and Enter the segment in a transport request

Step 2: Define a basic Idoc Type

Enter transaction code WE30 Enter a name for the basic IDoc type and mark basic type as the development object. And choose create

Enter a description for the basic Idoc type and choose tick mark button. Position the mouse on header and choose create button Enter the segments. Save

Step 3: Assigning Message types We need to create new message types only if the existing message not matching with our requirements. Steps to create a new message type

Enter Transaction WE81 Choose edit button and then new entries Enter the message type with description Save

Steps to assign basic Idoc type to message type

Enter transaction WE82 Choose edit button and then new entries Enter the message type, basic type and SAP release in their corresponding columns. Save data

Step 4: Create function Module for outbound processing The steps for creating a function module have been described in our earlier posts. Here is a brief about the steps.

Open the function builder to create our new function module Create the segments as global data and code the function module to pass the application data to the corresponding segments.

Activate the function module

Step 5: Maintaining the Attributes of a Function Module Use transaction code BD51 to maintaining the Attributes of a Function Module (Like the settings for dialog possible etc) Step 6: Assign function module to the basic Idoc Use Transaction code WE57 and then assign the function module to various objects as per our requirements. This step is the ALE registration for the function module. Step 7: Assigning a Process Code This step is used to assign a new process code to the new function module. This enables the function module to be identified from the partner profiles defined in the IDoc Interface when an IDoc of the new message type is received.

Enter transaction code WE42 Enter process code and a description. Choose the Processing with ALE and Processing by function module options and save your entries. In the maintenance screen assign the inbound function module to the process code.

Choose new entries In the detail screen enter Process code, Module fame, Idoc fame, Application Object fame etc

Save Enter transaction code WE42 again Go back to maintain the inbound process codes and choose the Logical message navigation. Choose change mode and select new entries Enter the message type and process code Save

Step 8: Defining a partner

The new basic type must be entered in the partner profiles before being used. Use transaction code WE20 to create partner profile. Partner number, partner type, Partner function, message type, permitted agent and process code are the important fields to maintain in inbound partner profiles.

These are the common steps involved in creating a new basic type Idoc. The other steps you need to do after this may be

Create Logical System Create RFC destination Using of test tool for IDOC

You will get more details about these in our other tutorials.

IDOC status codes

After the process of inbound function module and outbound function module the state of status will be recorded in the status record of IDOC.We can view the status by using transaction codes WE02, WE05 and WE07.Here is the list of main IDOC stats codes for Outbound and Inbound IDOC. Outbound IDOC status codes with status description.

01: IDoc generated 02: Error passing data to port (Its an error status) 03: Data passed to port OK 04: Error within control information of EDI subsystem 05: Error in translation 06: Translation successful. 07: Error on syntax check (Its an error status) 08: Syntax check successful 09: Error on interchange handling (Its an error status) 10: Interchange handling successful 11: Error on dispatch (Its an error status) 12: IDOC Dispatch successful 13: Retransmission successful 14: Interchange Acknowledgement positive 15: Interchange Acknowledgement negative (Its an error status)

16: Functional Acknowledgement positive 17: Functional Acknowledgement negative (Its a warning error status) 18: Triggering EDI subsystem successful 19: Data transfer for test successful 20: Error on triggering EDI subsystem (Its an error status) 21: Error on passing data for test (Its an error status) 22: Dispatch successful, acknowledgement still due 23: Error on retransmission (Its an error status) 24: Control information of EDI subsystem successful 25: Processing despite syntax error (Its a warning error) 26: Error during syntax check of IDoc (Its an error status) 27: Error in ALE dispatch level (Its an error status) 29: Error in ALE service (Its an error status) 30: IDoc is ready for dispatch in ALE service 31: IDOC is marked for deletion. 32: IDoc was edited 33: Original of an IDoc which was edited 34: Error in control record of IDoc (Its an error status) 35: IDoc reloaded from archive 36: Timeout error on Electronic signature not performed (Its an error status) 37: IDoc added incorrectly (Its an error status) 38: IDoc archived 39: Arrival of IDOC in target system confirmed 40: Application document not created in target system (Its an error status) 41: Application document created in target system

Inbound IDOC status codes with status description.

42: IDoc was created by test transaction 50: IDoc added 51: Application document not posted (Its an error status) 52: Application document partially posted (Its an error status) 53: Application document posted successfully. 54: Error during formal application check (Its an error status) 55: Formal application check successful

56: IDoc with errors added (Its an error status) 57: Test IDoc: Error during application check (Its an error status) 60: Syntax error on IDOC (Its an error status) 61: Processing despite syntax error (Its a warning error status) 62: IDoc passed to application 63: Error passing IDoc to application (Its an error status) 64: IDoc ready to be transferred to application 65: Error in ALE service (Its an error status) 66: IDoc is waiting for predecessor IDoc in serialization process 68: IDOC is marked for deletion. 69: IDoc was edited 70: Original of an IDoc which was edited 71: IDoc reloaded from archive 73: IDoc archived 74: IDoc was created by test transaction

Using the standard report RC1_IDOC_SET_STATUS we can change the status of an IDOC if we require for that. We can reprocess IDoc if we are getting errors.

ALE IDOC Transaction codes

Here is the list of important ALE IDOC transaction codes and its purposes for a quick reference. 1. SALE This transaction code is used for access IMG ALE Configuration root 2. WE05 IDoc overview 3. WE07 IDoc statistics 4. WE20 This transaction code is used for manually maintain partner profiles 5. WE21 This transaction code is used for Ports in Idoc processing 6. WE47 This transaction code is used for edit IDOC status values. (Real path: SALE -> SetUp System Monitoring -> IDoc Status Display -> Edit IDoc Status Values) 7. WE60 This transaction code is used for create IDoc documentation (IDOC header file) 8. SM59 This transaction code is used for Create RFC Destinations 9. SM58 Schedule RFC Failures

10. BD21 Create IDocs from change pointers 11. BD50 This transaction code is used for Activate Change Pointer for Message Type 12. BD52 This transaction code is used for Activate change pointer per change.doc object 13. BD53 This transaction code is used for Reduction of Message Types 14. BD55 This transaction code is used for Defining settings for IDoc conversion 15. BD56 This transaction code is used for Maintain IDOC Segment Filters 16. BD59 This transaction code is used for Allocation object type -> IDOC type 17. BD61 This transaction code is used for Activate Change Pointers Globally 18. BD62 This transaction code is used for Define rules 19. BD64 This transaction code is used for Maintain customer distribution model 20. BD71 This transaction code is used for Distribute customer distribution model 21. BD79 This transaction code is used for Maintain rules 22. BD82 This transaction code is used for Generate Partner Profiles 23. BD87 This transaction code is used for Status Monitor for ALE Messages (Real access path is Tools -> IDoc Interface/ALE -> Administration ->Monitoring -> IDoc Display ->Status Monitor ) 24. BD88 Outbound IDoc reprocessing 25. BDM2 IDoc Trace 26. BDM5 This transaction code is used for Consistency check 27. BDM7 IDoc Audit Analysis 28. WEDI This transaction code is used for ALE IDoc Administration 29. SARA This transaction code is used for IDoc archive administration 30. BALE ALE Distribution Administration

IDOC Reprocess reports

We can reprocess IDoc if we are getting errors. Several standard reports are available for this reprocessing. Here are some standard reports for reprocessing of IDOC.

Report RBDMANI2

We can execute this program for manual reprocess of IDOC.It can be used when we get the status 51 or status 63 errors for an inbound IDOC. Report RBDMANIN It used for Posting of inbound IDocs with Status 51. Report RBDMOIND It checks whether the communication with tRFC was successfully completed. If successfully completed, the status of the IDoc is changed. This reprocess program can be used for outbound IDOC with status codes from 03 to 12. Report RSEOUT00 For reprocessing outbound IDOC with status 30 Report RBDAPP01 For reprocessing inbound IDOC with status 64 Report RBDAGAIN It for reprocessing of incorrect outbound IDOC with statuses 02, 04, 05, 25 and 29 Report RBDAGAI2 It for reprocessing of IDOCs after ALE input error with statuses 56, 61, 63 and 65 Report RBDAGAIE It for reprocessing of Edited IDOCs with status 32 and 69

IDOC STATUS CODES:

After the process of inbound function module and outbound function module the state of status will be recorded in the status record of IDOC.We can view the status by using transaction codes WE02, WE05 and WE07.Here is the list of main IDOC stats codes for Outbound and Inbound IDOC. Outbound IDOC status codes with status [...]

SAP LSMW Tutorial with Steps to create

The full form of LSMW is Legacy System Migration Workbench. As the name specifies its a tool in SAP for migrating the legacy data to SAP system.LSMW is the transaction code used to start. Commonly used importing technology in LSMW are

Direct Input method Batch Input Recording BAPI Method IDOC method

In this tutorial we describes about the steps involved in creating an LSMW project for migrating the legacy data. In LSMW we are doing the things in a step by step procedure and the next step screen will be automatically displayed after very step. Here are the steps involved in LSMW. Here is the screen shot of LSMW initial screen

Step 1: Maintaining Object Attributes Here we are specifying about the project, subproject, object and importing technology (like batch input, IDOC etc.)

Choose maintain object attribute from the LSMW steps screen Choose Change Specify the Object

Specify the nature of data transfer that one time or periodic. Select the object type and import technique.

Step 2: Maintaining the source structures Here we define the structure of source.

Choose maintain the source structure from the LSMW steps screen Choose Change Point your mouse on Source Structures Choose Create Structure Enter the name and description for the structure Choose Continue

Step 3: Maintaining Source Fields After the creation of structure in step 2, in this step we are going to define each field in that structure.

Choose maintain source fields from the LSMW steps screen Choose Change Point your mouse on the Source Structure where we are going to add fields. Choose Create Field. Enter the field name, text, length and type Choose Continue

Step 4: Maintaining Structure Relationship Here we specify the relationship between the SAP structures and the source structures created in step 2.

Choose maintain structure relationship from the LSMW steps screen Choose Change Point your mouse on the SAP structure ID. Choose Relationship. Point your mouse on the corresponding source structure. Choose Continue Choose check for finding any errors in relationship.

Step 5: Maintaining Field mapping and Conversion Rules The mapping between SAP structure fields and source structure fields, and conversion rule is specifying in this step. Instead of manual mapping, auto field mapping option is also available.

Choose maintain field mapping and conversion rule from the LSMW steps screen Choose Change

Choose extras -> auto field mapping Choose the appropriate options

Step 6: Maintaining Fixed Values, Conversions and User-Defined Routines Specifying the conversion rules for processing data. Here we specify the fixed values etc.

Choose maintain field mapping and conversion rule from the LSMW steps screen Point the mouse on the field where we want to add rule Choose insert rule The rules list will display. Select the rule. Set the indicator Choose Continue

The normal available rules are 1. Initial 2. Constant 3. Transfer (MOVE) 4. Fixed Value (Reusable) 5. Translation (reusable) 6. Prefix 7. Suffix 8. Concatenation 9. Left trim 10. ABAP coding 11. User-defined routine Step 7: Specifying files In this step we will specify the files used for the migration.

Choose Specifying the files from the LSMW steps screen Enter file name, description and other settings

Step 8: Assigning files Here we assign the specified files to the corresponding source structure.

Choose Assign files from the LSMW steps screen Choose change Point the mouse on a structure Choose Assign file Select the corresponding file

Press Continue

Step 9: Importing Data In this step press execute to read the data from source. Step 10: Displaying Imported Data In this step choose continue to display the data that has been read. Step 11: Converting Data In this step choose execute to transfer the read to the file of converted data. Step 12: Display Converted Data In this step choose execute to display the converted data. Depending on the importing technology specifies in step 1. The next steps may have. Step 13: Create batch input session Step 14: Run batch Input Session. OR Step 13: Starting IDOC generation Step 14: Starting IDOC processing Step 15: Create an IDOC overview Step 16: Start IDOC post processing You will get more details about batch Input Session and IDOC in our other tutorials.

SAP BDC Tutorial

The full form of BDC is Batch Data Communication. Its a technique in SAP used for mass input of data or uploading data into SAP system (If particular BAPI is not available).BDC also known as Batch Input. There are two types of BDC are there

Call Transaction Using (using CALL TRANSACTION statement) Batch Input Session (using BDC_OPEN_GROUP, BDC_INSERT and

BDC_CLOSE_GROUP function modules)

ABAP programming is requires for any BDC methods. First we need to record a transaction and then embed this recording in our ABAP program. Then we will run this using Call Transaction using or BI session method. CALL TRANSACTION USING: This is the fastest method to transfer data.

Syntax: CALL TRANSACTION <tcode> USING <bdc_tab> MODE <mode> UPDATE <update>

Main Display Modes used A: Display all E: Display Errors only N : No Display

Main Updates modes S: Synchronous A: Asynchronous L : Local Update

While we doing CALL TRANSACTION USING method, first we will create a structure BDCDATA for the transaction. This structure is used in the USING addition of the CALL TRANSACTION statement. Batch Input Session In this method data is stored in a batch input session and later run this session. Here is the process flow of BI session method.

Use BDC_OPEN_GROUP function module to create a BI session. BDCDATA structure, enter the value for all screens and fields that must be processed in the transaction

Use BDC INSERT function module to transfer the transaction and the BDCDATA structure to the session

Use BDC_CLOSE_GROUP function module to close the batch input session.

Now this session will be in a batch input queue and we need to process it. The session processing can be two types

Manually using the batch input menu options (SM35 transaction). Use RSBDCSUB program to run the session in background.

http://www.freesaptutorial.com/category/smartforms/ What is Smartforms and its advantages SAP Smartform is a replacement solution for using SAPScripts. Smart Forms requires only half of the time for creating or maintaining the forms. We can create the forms without any programming skills. A good graphical interface is provided to create the forms. It supports fax, email, printer and internet as output Medias. When activating a smart form system creates a function module for this and this function module will process at run time. The program for data retrieval will pass the data to this function module. The smart form contains the entire form logic. Migrations from SAPscripts to Smart forms are also supported. A form painter tool and table painter tool are used for designing the page and table layout respectively. We can do drag and drop, cut and paste while creating the forms. We can insert static and dynamic tables in forms. It also supports the usage of images.

Structure of a Form A form contains pages, output areas (called windows), address, graphics and text data etc. In pages we specify the page layout and other general settings for the page. Windows are the output areas in a page. There are several types of windows used in a form page.

Main Window: Contains the main continuous data and supports page break. Secondary window: Output the data in a fixed size area. Final Window: A special type of secondary window used for output the data available only at the end of form processing

Copies Windows: A special type of secondary window used for marking the pages as copy or original.

We can use only one window as a main window in a form. It will have the same width in all pages. Its height can differ.

To call the Smart forms initial screen we can use the transaction code SMARTFORMS.

It contains a SAP Form builder to maintain a smart form, style builder to maintain form styles (can use the transaction code SMARTSTYLES) and text module maintenance (to create or modify reusable text).Sap form builder contains.

Form painter PC editor Navigation Tree Table painter Form Check

The supported Output formats for Smartforms are

OTF: Its the commonly used format for printing the forms. XSF: XML scheme contains the form contents without layout information HTML: Its containing the XSF with layout information ( for mainly interactive web forms). XDF: XML scheme containing only the application passed data.

SAP is a German Enterprise Application Software development company founded in 1972.The name SAP stands for Systems, Applications and Productions in Data Processing. The company has spread over 50 countries and has more than 109000 customers. SAP software Products

SAP ERP is the main product of the company which focused on Enterprise Resource Planning. SAP ERP coming with SAP Business Suite enterprise software. SAP Business Suite contains the following five major applications. 1. SAP CRM (Customer Relationship Management) 2. SAP ERP 3. SAP PLM (Product Lifecycle Management) 4. SAP SCM (Supply Chain Management) 5. SAP SRM (Supply Relationship Management)

Other major Enterprise Solutions are

SAP Manufacturing SAP Service and Asset Management Alloy Duet ( Its joint offering with Microsoft) Duet Enterprise Mobility solutions SAP BusinessObjects analytic solutions SAP BusinessObjects business intelligence solutions SAP BusinessObjects GRC solutions (Governance, Risk and Compliance) SAP BusinessObjects EPM solutions SAP Crystal solutions SAP solutions for auto-ID and item serialization SAP solutions for enterprise information management SAP solutions for sustainability Solution extensions

SAP Business One and Crystal solutions are some of the products for small size and mid size companies. The company also provides on demand and other rapid deployment solution products. SOA (Service-oriented architecture), SAP NetWeaver technology platform, In-Memory Computing technology and SAP BusinessObjects portfolio are the technologies and platforms provided by SAP for making the companies to implement and running the solutions faster and cost effective way. SAP is having a three tier architecture congaing Presentation Server, Application Serve and Database Server. The more details about this architecture cam be found in our later posts.ABAP and

Java are the programming languages used in SAP for customization ad other modification works as per the user requirement. You will get more details about that in our tutorials. There are several companies for implementing SAP for the companies planning to use their products. Trained SAP professionals are required for doing this job. The company also provides certification based on exams for the professionals.

Transaction codes

VS00: Tcode for Master data VC00: Tcode for Sales Support VA00: Tcode for Sales VL00: Tcode for Shipping VT00: Tcode for Transportation VF00: Tcode for Billing

See the other transaction codes

VA01, VA02 and VA03: Create , change and display order respectively. VA05: List of sales orders VA21, VA22 and VA23: Create, change and display quotations VD01, VD02 and VD03: Create , change and display customer respectively.

XD01, XD02 and XD03: Create, Change and display customer respectively.

VA11, VA12 and VA13: Create , Change and display inquiry respectively. VL01: Create outbound delivery with ref sales order VL04: Collective processing of delivery VF02: Change billing document VF11: Cancel Billing document VF04: Billing due list VL02N: Change delivery document VL04: Delivery due list VKM5: List of deliveries VL06G: List of outbound deliveries for goods issue VL06P: List of outbound deliveries for picking VL09: Cancel goods issue

VT02N: Change shipment VT70: Output for shipments FBL5N: Display Customer invoices by line FBL1N: Display Vendor invoices by line VKM3, VKM4: List of sales documents VKM1: List of blocked SD documents VD52: Material Determination VOV8: Define Sales documents type (header) OVLK: Define delivery types V/06: Pricing

CREDIT CHECK CONFIG REPORTS:

Using a test environment that is due for a refresh I run into credit limits when entering sales orders more than often. Manipulating the credit check for a customer in FD32 is not always sufficient. The following reports also are useful (if not essential): RVKRED06 - Background jobs for checking blocked credit management. If an order is no longer outside the horizon as defined in the dynamic credit check, (i.e. it is INSIDE the horizon) it can cause existing good orders to block. If you run this job every night, if you have your horizon set for 1 month it can cause a lot of blocks at beginning of month. Try to use W for weekly horizon status. RFDKLI10 Customers With Missing Credit Data RFDKLI20 Reset Credit Limit for Customers RVKRED77 Reorganize SD credit data When updating errors occur, it enables you to reorganize the open credit, delivery and billing document values. RVKRED08 Checking sales documents which reach the credit horizon You should runs this report periodically, usually at the start of a period. The report checks all the sales documents, which reach the dynamic credit check horizon. The period for the date of the next credit check is proposed from the current date, with the help of the period split for open sales order values