SAP SD configuration: 2008

Evolution of ERP:

MRP: ERP started with Materials Requirement Planning (MRP). MRP catered to the two basic functions of Materials Management and Inventory Management and typically catered to a manufacturing organisation.

MRP-II: An upgrade over MRP was MRP-II. MRP-II provided for production Planning along with Materials Management and Inventory Management.

ERP: Enterprise Resource Planning. This package provided for the complete suite of applications ranging from Sales and distribution, Planning, Materials Management, Quality Management, Human Resources and Financial Accounting.

The keyword with ERP is "Integration".

ERP Vendors:

The following are the major ERP vendors locally and internationally. Local RAMCO : Marshall MASTEK : Mamis International SAP (Systeme Anwengdung Producte) BAAN PeopleSoft Oracle Mfg*Pro J.D.Edword

Technical Architecture

SAP is an ERP package, which caters to the key function of integration. It provides integrated functionality for finance, sales, materials management, production and human resources. SAP is DBMS transactional software written in ABAP/4. Various modules provide various functionalities. It can be configured to meet the business process logic through customisation. SAP is customisable software. The database in SAP can be either Oracle or Informix. Technical Architecture (refer diagram a) The technical architecture of SAP R/3 is as per the diagram. The Technical Architecture of SAP R/3 is a three-tier architecture. This means that the architecture can be broken down into three layers. First is the Data base Layer. The Database layer hosts the central database. The central database is a Relational Database Management System (RDBMS). The next layer is the application layer. The business logic processing occurs in the application layer. The presentation layer is the Graphic user interface or the GUI, which interacts with the user and receives inputs and gives output to the user. SAP recommends four concurrent Servers: To have better control over the production system, SAP recommends four different servers in a typical SAP implementation. These are: Development: All development work is carried out in the development server. Unit testing is done in the development server. Integration: The changes are then tested for their correctness by integration testing in the integration server Consolidation: The consolidation system consolidates all the changes before they are transported to the production environment. Production: The production system is the live system which contains all the current data. Technical Information - SAP SAP is a 32 Bit Client Server Application. SAP uses 4GL (4th Generation Language) called ABAP/4 for Front end Development ABAP/4- Advanced Business Application Programming Language Uses ALE (Application Link Enabling) Loose Coupling of Database Independent Servers SAP uses Messaging Mechanism to Synchronize database IDES - Integrated Documentation and Educational System. IDES contains example data for all transactions. OSS - Online Support System. This is an Online Support System provided by SAP. Modules in SAP SAP is divided into various modules that cater to different functionalities. The various modules of SAP are as follows: Sales and Distribution Project Management Materials Management Quality Management Finance and Controlling Human Resources Production Planning Plant Maintenance

Implementation Approaches

The following are the implementation approaches for ERP

Big Bang Approach

In this approach, ERP is implemented at one-go at all the offices of the organisation.

Pilot Rollout

In the Pilot rollout approach, one subsidiary business unit (SBU) is selected as the pilot and ERP is first implemented in that unit. Then it is rolled out to other business units in a phased out manner.

Functional Rollout

In the functional rollout approach, one function like finance or materials management is selected for implementation. Then one by one ERP is implemented for each of the functions in the organisation.

Cross-Develop Global Prototype
In the cross-develop global prototype, a prototype is first developed and tested. Once successful, the implementation is done for the entire organisation.

requirements for implementation of SAP at site.

VSAT: PAMA VSAT (preferably) or TDMA VSAT.

PC running NetWare or Router for Routing.

NetWare If a PC running Novell NetWare is used for routing then, the PC should have 2 NetWare Interface Cards (NIC), one NIC connected to the LAN and one NIC connected to the IDU of the VSAT. Both the NICs should have valid IP addresses assigned by LTITL.

Router If a Router is used for routing, then the router should have a serial port to connect to the IDU of the VSAT, and it should have one Ethernet port (NetWare interface card) to connect to the local area network.

Hardware One Personal Computer

Pentium 166MHz MMX / Pentium II with 32MB RAM 1.44MB FDD, 4 GB HDD

14" SVGA color monitor

VGA Card with 1MB RAM 101/102 keyboard Mouse Ethernet 32Bit Card SMPS,

2 serial & 1 Parallel Ports

Software MS-DOS 6.2, Windows 95 / Windows 98,MSOffice 97, SAP GUI 3.1H

Printer Printer connected to the LAN can be accessed.

To use the printer connected to the LAN,

1) Set the printer on the PC as the default printer

2) Select LOCL in the SAP print menu

Basis

BASIS provides administrative tools for SAP. It is a logical collection of R/3 software components. Basis is the layer between the hardware and R/3 system software.

BASIS provides for the following

Tools for administration:

Basis includes various administration tools for managing the system resources like hardware, software and printers. It includes tools for monitoring the system performance, monitoring user sessions, setting up alerts and deriving various statistics and graphs which give indications of the system performance.

User Administration:

This includes creating user ids, modifying user details and deleting users ids, viewing system users, sending messages to multiple users.

Runtime environment for the user:

The runtime environment for the user includes the default menu path for the user, the date format for the user, the default printer for the user, changing user’s password.

Provide Authorisations to the users:

In order to enable the user to access the various transactions, it is essential that the users have the correct set of authorisations. Setting of authorisations for the users based on their job roles. An authorisation tool is used to create the user authorisations. Once the authorisations have been created, profiles are created and the authorisations are attached to them. Each profile can have many such authorisations attached to them. The profiles are created based on the role definition of the user in the company. After the authorisations and profiles are created, user ids are created and the profiles are attached to the user profiles. Each user id could have multiple user profiles attached to them. For example, if we create a user profile for a business head, then that user id could have profiles relating to various departments / job definitions attached to it.

Printer Administration:

This includes installing the network printers and local and remote printers for the users, setting up printer queues, and managing printer spooler.

System Administration:

This includes starting and stopping the SAP service manager, diagnosing the system start-up, monitoring work processes, viewing transaction codes, clearing locked entries, monitoring system updates, transport of customising change requests and ABAP change requests at the OS level.

Database Administration (including Backup and Restore):

Database management including database backup and restore, database performance monitor, and analysing database activity.

Interfaces with non-SAP products:

BASIS also includes tools for interfacing with non-SAP products, which will continued to be in use in the organisation.

ABAP/4

ABAP is the development tool in SAP. All SAP Transactions and Reports are developed in ABAP/4. ABAP/4 aids in the development of new reports, batch conversion programs and data entry screens (module pool programs) and interfaces with third party standard software.

SAP software is totally transaction based. All the menu paths in SAP point to a particular transaction. A transaction is a four-letter alphanumeric code, which executes a program in SAP. Everything in SAP is a transaction. For e.g.- Creating a Purchase Order is a transaction, Changing the Purchase Order details is another transaction. Transactions are also used to run various reports. Each report has a unique transaction code. Each transaction code is unique in the SAP system.

ABAP/4 Reports

There are following types of ABAP/4 reports that can be developed.

Simple Lists:

ABAP/4 can be used to generate simple lists as well as interactive reports.

Interactive reports

Event Driven Reports: These reports are generated on click of a button.

Drill Down Reports: Reports are initially shown as simple upper level lists. If the user is interested in getting further details, then he can drill down on a particular item like material code or project number and get further details. Thus many levels can be incorporated into the report based on the user requirements.

Graphic Reports: Reports can be developed to provide a graphical representation of the data.

Layout Sets: ABAP also facilitates developing of various documents sent to external parties like customers and vendors. These documents require special formatting and printing of company logos. This can be done through ABAP Layout sets tool, which enables the programmer to specify various fonts, set the logo in the format and perform special formatting in the document.

ABAP/4 Batch Data Conversion

Batch Data Conversion programs are developed to import the data from legacy systems into SAP. Batch programs are written specifically for the particular transaction. For example, to upload all the purchase order data from the legacy system, a BDC for the purchase order transaction is developed.

Online or Scheduled: BDCs could be online or they could be scheduled to run at a particular time / date or after a particular other BDC has run.

ABAP/4 Job Scheduling: The user can schedule the running of reports / BDCs on a periodic basis (monthly / weekly).

ABAP Module Pool Programs: These are new data entry screens that can be developed in ABAP based on the user requirements.

ABAP Queries: ABAP Query is a quick and effective tool, which is used to create queries and generate simple lists.

ABAP Module Pool Programs: To build interactive data entry screens, Module Pool programs are developed in ABAP/4

SMARTFORMS

Steps to create a simple SMARTFORMS
Read the abap program in step 5 first to see how the data is begin pass to the internal table.
1. Create a new smartforms
2. Define looping process for internal table
3. Define table in smartforms
4. To display the data in the form
5. Calling SMARTFORMS from your ABAP program

1. Create a new smartforms
Transaction code SMARTFORMS
Create new smartforms call ZSMART
The followings screen format will appear :-
- Form ZSMART Form ZSMART
- Global settings Description New form
- Form attributes
- Form interface
- Global definitions General attributes Output Options
- Pages and windows
+ %PAGE1 New page
You can click at the Form Painter button to view the graphical display layout of your smartforms.

2. Define looping process for internal table
Pages and windows
First Page -> Header Window (Cursor at First Page then click Edit -> Node -> Create)
Here, you can specify your title and page numbering
&SFSY-PAGE& (Page 1) of &SFSY-FORMPAGES(Z4.0)& (Total Page)
Main windows -> TABLE -> DATA
In the Loop section, tick Internal table and fill in
ITAB1 (table in ABAP SMARTFORM calling function) INTO ITAB2

3. Define table in smartforms
Global settings :
Form interface
Variable name Type assignment Reference type
ITAB1 TYPE Table Structure
Global definitions
Variable name Type assignment Reference type
ITAB2 TYPE Table Structure

4. To display the data in Smartform
Make used of the Table Painter and declare the Line Type in Tabstrips Table
e.g. HD_GEN for printing header details,
IT_GEN for printing data details.
You have to specify the Line Type in your Text elements in the Tabstrips Output options.
Tick the New Line and specify the Line Type for outputting the data.
Declare your output fields in Text elements
Tabstrips - Output Options
For different fonts use this Style : IDWTCERTSTYLE
For Quantity or Amout you can used this variable &GS_ITAB-AMOUNT(12.2)&

5. Calling SMARTFORMS from your ABAP program
REPORT ZSMARTFORM.
* Calling SMARTFORMS from your ABAP program.
* Collecting all the table data in your program, and pass once to SMARTFORMS
* SMARTFORMS
* Declare your table type in :-
* Global Settings -> Form Interface
* Global Definintions -> Global Data
* Main Window -> Table -> DATA
*
* Written by : SAP Hints and Tips on Configuration and ABAP/4 Programming
* http://sapr3.tripod.com
*
TABLES: MKPF.
DATA: FM_NAME TYPE RS38L_FNAM.
DATA: BEGIN OF INT_MKPF OCCURS 0.
INCLUDE STRUCTURE MKPF.
DATA: END OF INT_MKPF.
SELECT-OPTIONS S_MBLNR FOR MKPF-MBLNR MEMORY ID 001.
SELECT * FROM MKPF WHERE MBLNR IN S_MBLNR.
MOVE-CORRESPONDING MKPF TO INT_MKPF.
APPEND INT_MKPF.
ENDSELECT.
* At the end of your program.
* Passing data to SMARTFORMS
call function 'SSF_FUNCTION_MODULE_NAME'
exporting
formname = 'ZSMARTFORM'
* VARIANT = ' '
* DIRECT_CALL = ' '
IMPORTING
FM_NAME = FM_NAME
EXCEPTIONS
NO_FORM = 1
NO_FUNCTION_MODULE = 2
OTHERS = 3.
if sy-subrc <> 0.
WRITE: / 'ERROR 1'.
* MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
* WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
endif.
call function FM_NAME
* EXPORTING
* ARCHIVE_INDEX =
* ARCHIVE_INDEX_TAB =
* ARCHIVE_PARAMETERS =
* CONTROL_PARAMETERS =
* MAIL_APPL_OBJ =
* MAIL_RECIPIENT =
* MAIL_SENDER =
* OUTPUT_OPTIONS =
* USER_SETTINGS = 'X'
* IMPORTING
* DOCUMENT_OUTPUT_INFO =
* JOB_OUTPUT_INFO =
* JOB_OUTPUT_OPTIONS =
TABLES
GS_MKPF = INT_MKPF
EXCEPTIONS
FORMATTING_ERROR = 1
INTERNAL_ERROR = 2
SEND_ERROR = 3
USER_CANCELED = 4
OTHERS = 5.
if sy-subrc <> 0.
MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
endif.

Application Link Enabling

What is ALE?

ALE stands for Application Link Enabling and is a remote connection technology allowing the decentralization of business processes by connecting decentralized systems together.

Using ALE, it is fairly easy to synchronize several SAP systems so that they contain the same data objects at anytime. These objects may be master data (customers, vendors, GL accounts, cost centers, ...) or transaction data (FI documents, purchase orders, ...). To enable the synchronization, ALE supports not only mass transfer of data between systems but also selective data transfers of objects changed since the last transfer.

How does it work?

Viewed from a high level perspective, the process is straight and simple: a sender system selects the data that needs to be distributed, packs it in a standard format and sends it to one or several receiving systems. When a receiving system gets the data, it unpacks the standard format and records the data.

In fact, 3 layers are involved in this process:
• An application layer which selects and records data in R/3.
• A distribution layer which filters and converts data.
• A communication layer which ensures the actual communication of records generated in a standard format.

The senders and receivers are determined thanks to a so-called distribution model which defines the transfer rules (who sends what to who?). The definition of the distribution model must be known by all systems involved (either as sender or receiver) and must consequently exist on all those systems.

The Intermediate Document (IDoc)

The data transferred using ALE must have a SAP standard format to be understood from all partners in the communication. This format is the Intermediate Document (IDoc) which represents an intermediary structure between raw SAP data and EDI formats. This structure is not constant, it depends on the data to be transferred and SAP provides the structures for most SAP standard objects such as customers master data, sales orders, ...

An IDoc with a specific structure is said to have a specific type. The IDoc type is nothing more than a version of a specific IDoc structure designed to contain data for a specific object type. For example, the IDoc type DEBMAS05 is the fifth version of a structure that represents a customer master data. The management of versions for IDocs structures is necessary because the objects evolve with time and tend to become more and more complex with new data fields or tables being added regularly.
The conversion of raw data forth (for the sender system) and back (for the receiver system) to the IDoc format is also ensured by SAP standard function modules as long as you transfer standard objects. For non standard objects (enhancements), you must define your own IDoc structure and write your own conversion function modules.
RFC connections

The data communication between the SAP servers may be done by several ways. The 2 most common ways are the transactional RFC and the file. The RFC connection is used to make a direct connection between servers while the file interface speaks for itself, it uses a file containing the IDocs from the sender system as input in the receiver(s) system(s).

The selection of a communication method is made though the ports configuration as we will see in the next section. For the purpose of this article, we are going to choose the most efficient method: the transactional RFC method. To set it up, we first need to define the RFC destinations of the partner systems.

An RFC destination may be seen as a set of settings necessary to connect to a system using the RFC protocol. These settings include the address and type of the partner system along with connection information such as the user ID and password to use.
The RFC destinations of all partners systems must be defined on all systems to include in the distribution model. The transaction to use for this purpose is SM59.
Definition of the communication ports

The communication ports determine the type of data communication that must occur between systems. When the communication is to use the RFC protocol, transactional RFC ports must be created specifying the RFC destinations of the partner systems. Use transaction WE21 for this purpose.
Partners profiles

In SAP, all partners systems involved in a distribution model have a profile. There exist several profile types such as customers profiles, vendors profiles, ... but this distinction between profiles is generally not necessary and you will create in most cases your partners profiles using a generic Logical System type.
Before entering the settings of the logical systems partners, you have to create them in customizing. Also, each system in the distribution model must be assigned in its own system its own logical system that represents it. This assignment is done at client level and not at system level. This is not easy to explain nor to understand so let's take a simple example. Let's consider we have a simple distribution model made up of a sender system (S01) and a receiver system (R01). We need to transfer data from S01 / client 100 to R01 / client 200. In both the systems, we will define the logical systems S01_100 and R01_200. But in sender system S01, the logical system S01_100 will be assigned to the client 100 while in the receiver system R01, it will be R01_200 that will be assigned to client 200. With such a configuration you see it is even possible to transfer data between two clients from the same system.
A partner profile is used to determine a lot of important settings that will be involved in the data transfer. These settings vary depending on the role of the partner system (sender / receiver) and are defined per message type. A message type is more or less a version independent IDoc type. It is mainly a convenient way of defining settings and identifying IDocs using a criterium independent of the partner system.
For a sender partner system (inbound parameters are filled in), following important settings are set per message type in the partner profile:
• A process code used to indicate which function module will be used to convert the IDoc data to SAP data.
• The time of input of the IDoc: as soon as the IDoc is created in the system or on request (using program RBDAPP01).
• The post processing agent who will have to treat the data input errors if need be. The post processing agent may be either a user or any other HR organizational unit.
For a receiver partner system (outbound parameters are filled in), following settings are specified in the partner profile:
• The receiver port to which the data will be sent.
• The sending method: one IDoc at a time or by packets.
• The IDoc type that will be sent to that partner. For a given message type, the IDoc type sent may vary depending on the receiver system. Indeed you may have different versions of SAP in your system landscape.
Definition of the distribution model and data filtering
We have already seen that the distribution model is used to decide who sends what to who. But, as you guessed, there is a little bit more to be said about it and the way to manage it.
The distribution model is maintained in a central transaction (BD64) which lets you access the most useful environmental settings necessary to set up the model. Before creating the model, you must first decide on which system you are going to create it. Indeed the model must exist in all partners systems and two possibilities exist to achieve this.
Either you create the model on each system manually (with the same model technical name), which is feasible only with few systems and/or simple models. Either you create it in a specific system (usually the source system) and distribute it to the other systems thanks to the distribution command in the BD64 transaction menu.
If we want to copy the customers master data from the production system to the other systems in the maintenance line for example, we may create the distribution model on the production system and distribute it to all partners systems.
The actual creation of the model requests that you mention a technical name for the model (unique identifier in the systems landscape), a sender system, a receiver system and message types to exchange between those systems. You may afterwards add more sending and receiving systems in the model as well as more message types.
For each message type defined between a sender and a receiver, you may set filters on specific fields of the message type so that IDocs be generated only when these specific values are matched. For example, you may decide to send only customers of a specific account group. These filters are set by selecting the 'no filter set' text under message types in BD64.
There exists also another kind of filters which are segments filters. They do not filter IDocs creation based on values like we have just seen but filter unconditionally segments of created IDocs which must be excluded from the transfer (transaction BD56).

Change and Transport System

The CTS is the central tool for managing changes to customizing and repository data that we make in the IMG
or ABAP workbench.

As we have discussed earlier, a transport request cab be either customizing request or ABAP workbench
request.

A customizing request can be created by the customizing tool IMG.

An ABAP workbench request can be created by ABAP workbench tool. Any changes or objects we develop
through ABAP workbench are stored in Repository tables of SAP database.

As an ABAP developer you will be working with ABAP workbench and thus you create work bench requests.

A functional consultant works with configuration tool IMG (SAP Implementation Guide) T-code SPRO, thus
creating customizing requests.

Transport organizer:

Transport organizer is the tool provided by SAP which records and documents all changes to objects in the
repository and customizing. The transaction code for transport organizer is SE10 or SE09.

Transport organizer is fully integrated with ABAP workbench and customizing tool IMG. That means you can
navigate in both directions from transport organizer to ABAP workbench and reverse also.

Development class:

Development classes are used to group similar work objects that are being developed in a project.

While creating development class we must assign it to the transport layer.

All the objects assigned to that development class can be transported according to the routes defined in the
transport layer.

Defining transport layer and routes is SAP BASIS administrator job. The transport layer defines transport
route between the systems included in system landscape.

The development classes are themselves objects in the ABAP workbench.

The development class of a development class is always itself.

Change Request:

Information source in the transport organizer that records and manages all changes made to repository
objects and customizing settings during a development project.

Task:

A task is assigned to a change request.

It is the information carrier in the transport organizer for entering and managing all changes to repository
objects and customizing settings performed by employees within a development project.

4.6c
In SE10, tick the followings :-
• Customizing requests
• Workbench requests
• Transport of copies
• Modifiable
• Released
• Hit Enter and a changed request lists will be displayed (click Releaseddirectly button or press F9)
STMS - Transport request from Developerto Production (depending on your company settings)
• Import Overview
• Double the Target System
• Select the request to transport and click Import request or Ctrl + F11

Relationship Matrix

Program Management

The implementation of the R/3 System in large multinational corporations is a more time-consuming and complicated process than for mid-sized companies. For this reason , corporations need to observe certain procedures in order to control costs and avoid the delays that a lengthy rollout might entail. The following graphic shows an example of how global templates can be used to carry out a rollout. On the global level, that is, at corporate headquarters, it is necessary to co-ordinate all activities carried out during implementation and the maintenance/support phase after implementation.

Within Global ASAP, program management is regarded not as a project, but as the providing of official channels of support for the further development of the template, the ongoing work on group-specific standards and the rollout of the corresponding system functionality. These global activities need to be carried out and clearly defined centrally for all local systems.

Figure xx: Projects to Complete a Group Rollout

When local project activities are carried out, the program team at the global level is not actually responsible for the productive start of any systems at the local sites. This is the main task of the local project teams. Here it is important to differentiate between tasks carried out at the global and local levels, as well as to differentiate between resources used for development and resources used in the rollout itself.

The developments described here contain a global implementation strategy based on global templates and distributed system topologies. This is where R/3 customers will reap the greatest benefit. Within Global ASAP, further release strategies and enhancements containing new contents and functions which apply to the Global ASAP Roadmap will follow.

Accelerated SAP ii

AcceleratedSAP is a comprehensive solution for the implementation of the R/3 System, comprising a proven methodology, tools and a range of services for the rapid implementation and ongoing optimization of R/3 installations.

The AcceleratedSAP Roadmap and accompanying Project Plan provide a standard implementation "how-to guide" that fills in the gaps of diverse methodologies and varying individual implementation skills and experiences.

The effectiveness of AcceleratedSAP has been demonstrated many times over at companies around the world. The Business Engineer plays a central role in AcceleratedSAP projects, being used for completion of configuration tasks.

Fig. XX: Breakdown of ASAP phases in the Implementation Assistant

The AcceleratedSAP Roadmap covers the different aspects and phases of an implementation. In the Roadmap, a detailed project plan is included for the five phases. The Roadmap provides a standard repeatable procedure for implementing the R/3 System, including project management, configuration of business processes, technical, testing and training aspects. The Roadmap serves as a backbone to AcceleratedSAP. It is located within the Implementation Assistant, a PC-based navigation tool that also contains the AcceleratedSAP accelerators.

The ASAP Accelerators represent a collection of descriptions, how-to's, templates and examples on all subjects relating to the implementation of the R/3 System. Some are short information texts on a particular subject, others are longer texts such as white papers. There are also a number of predefined and empty templates or forms which you can use when carrying out your implementation. The SAP Simplification Group's guidebooks are included. There are about 350 accelerators for AcceleratedSAP 4.0, and they can be accessed from an alphabetical list, as well as being linked to the individual roadmap How-to's.

There are four levels to the roadmap – phase, work package, activity, task. As you dig deeper into the levels, you will find more detailed information, from an overview description at the phase level down to a "how-to" procedure, role assignment, triggers, and tips and tricks.

It is essential that you create a project plan when starting your ASAP implementation project. Project plans have three parts:

The Budget Plan contains the projected costs by month, against the actual costs and calculates the variance.
The Resource Plan contains the resources assigned to the R/3 implementation. It displays the planned and actual number of workdays per month, as well as the variance between the two. It also contains a cumulative planned hours work sheet.
The Work Plan contains a detailed set of phases, work packages, activities, and tasks from the AcceleratedSAP Roadmap. This information is organized in a project management planning tool (MS-Project or Excel spreadsheet). A Gantt Chart is contained within this work plan to view schedules, dependencies and resources in MS-Project.

Three sample project plans are included for a six-month duration, a nine-month duration, and an upgrade project plan. If the Project Estimator is used during the sales cycle and Project Preparation Phase, your individual project plan is generated automatically, taking into consideration company-specific risk factors. The project plan makes sure that nothing is forgotten and that all activities can be tracked and managed. This means, for instance, that the planning for data transfer and the development and testing of interfaces is already included in the project plan.

It is now possible to implement more than one ASAP project at a time. During installation, Rel. 4.0 of ASAP asks you to specify a project name that will apply to the files being installed. In a multi-project environment a new Project Selector icon on your desktop allows you to set the active project, remove projects and review file locations.

You can select installed components such as the Implementation Assistant and Q&Adb in the respective projects as required. Each project is completely separate from the others, so in fact projects installed on the same server could be at different update levels.

AcceleratedSAP is a complete implementation solution. This means that in addition to the Roadmap, the AcceleratedSAP solution contains numerous tools and also references SAP education and services to ensure maximum time savings and a high quality implementation.

AcceleratedSAP uses the Business Engineer implementation tools at all relevant steps. In the figure below, for example, the conceptual design is based on the R/3 Reference Model in Phase 2 (Business Blueprint), whereas the Implementation Guide is accessed from ASAP Phase 3 (Realization).

Fig. 2: AcceleratedSAP Implementation Roadmap and R/3 Business Engineer

Service and Support

ASAP leverages SAP's service and support offering, that is, all the services relating to the SAP R/3 environment. EarlyWatch® Services, concept reviews, and GoingLive^TM checks are just part of the service palette which ensure total quality and let you effectively tune your R/3 System. At appropriate steps in the Roadmap, service products are mentioned and decision support is provided to determine whether you need a particular service. For example, if you have a high volume of transactions, certain tuning services can assist you in optimizing system performance.

Crucial to a fast and cost-effective R/3 implementation are well-trained project teams and highly competent consultants. SAP's innovative R/3 Info Database (InfoDB) ensures that customer and partner employees involved in implementing, servicing and using R/3 have all the qualifications they need. The InfoDB refers to a new training concept based on a new curriculum, which also includes multimedia courses.

Level 1 courses provide an overview of the R/3 environment.
Level 2 courses introduce you to fundamental business processes.
Level 3 courses focus on providing detailed information.

Organizational Change Management

The positive motivation of employees is a key factor in ensuring a successful implementation project. However, most organizations know, or will at least assume that the R/3 implementation will trigger wider changes in the organization. Left unmanaged, these expected impacts could be viewed negatively. Therefore, any change management program must minimize the implementation risks, acccelerate the implementation process, and align SAP with the customer's organization.

ASAP's Change Management is done via a risk assessment tool, by which assessments carried out will help a customer's team deal with issues of credibility, organizational impact, and individual impact of R/3 implementation. Implementing change management procedures involves accelerating the implementation by means such as a matrix that defines the degree to which jobs and responsibilities will be changed after R/3 implementation. The other aspect is to work with executive sponsors to redesign the organization's structure or reporting relationships, for example. The ASAP change management methodology enables you to review and revise the types and sequencing of change tasks, change activities, change packages and change accelerators.

A change task is a specific job or function to be completed by the change team.
Two or more change tasks roll up into a change activity.
A change package is a collection of change activities.
Change accelerators are the tools and/or materials that speed up the team's implementation of a processs, activity or task.

Knowledge Corner

The Knowledge Corner contains alphabetized information on all aspects of AcceleratedSAP as well as a lot of tips and tricks for configuration. The information provided here is very helpful during requirements gathering and configuration. The goals of the Knowledge Corner are:

To provide application consultants with detailed information and alternatives to configure and understand specific functionality within the R/3 System.
To provide detailed information about peripheral activities, such as support services and access to hotline activity.
To provide tips and tricks on R/3 implementation activities such as data conversion, authorization management, and forms development.

Some of the newer elements found in the Knowledge Corner are:

A link to the R/3 Interface Adviser, which provides a central pool of information to help you design and implement permanent interfaces between SAP R/3 components and non-SAP systems.
The R/3 Structure Modeler, which lets you graphically visualize the R/3 System organizational structures of your enterprise using the Structure Modeler Visio^® template. Please note, you must be a licensed Visio^® user to use this Accelerator.
The Report Navigator, which provides a directory of more than 2,000 operational reports available in standard R/3. The Operational Reports in R/3 help you pull and analyze critical transactional information regarding your business. You can use the R/3 Report Navigator to select the report that is optimal for the information you want to retrieve about your business transactions.

Available Languages

Primary components of AcceleratedSAP are available in German and English, as well as Spanish, French and Portuguese.

Accelerated Quality Review

SAP's Accelerated Quality Review provides an independent and objective management review of your R/3 implementation project and identifies any risks to the project goals. This service is standard in all TeamSAP projects. Among others, the benefits are early recognition of potential risk areas, improved adherence to project schedules, lower cost, and faster implementation times.

Fig. 7: Checking and quality tools around ASAP

The Quality Review program offered by SAP is not a review of the project for conformance to the ASAP tools and templates, but rather assists the executive management and project manager at customer sites in providing a second opinion of the implementation progress towards achieving the project goals. The scope of the review is to investigate the application, technical and project management areas of the implementation. The review looks for good implementation practices while following a prescribed methodology.

TeamSAP

TeamSAP refers to the coordinated network of people, processes and products from SAP and partners that delivers continuous, fast, integrated and assured solutions. AcceleratedSAP is the main process component of TeamSAP.

The people:

SAP employees and certified implementation partners providing leadership, project coordination and know-how to implement, maintain and support R/3 based on your requirements.
The processes:
AcceleratedSAP with the embedded Business Engineer functionality, as well as integrated support, services and training on all levels.
The products:
The R/3 System with its strategic product architecture and open interfaces, providing both scalability and flexibility in an ever-changing business environment. Also, hardware and software products from hundreds of complementary software partners and hardware providers certified by SAP.

Fig. 3: Elements of TeamSAP

TeamSAP supports the concept of business change as a continuum. The goal is to offer SAP customers a full complement of TeamSAP resources to enable rapid technology upgrades or change-outs for access to new functionality. With respect to ASAP, this means that TeamSAP partners are available to carry out implementations, as well as ASAP-certified partners to carry out "Powered by ASAP projects". TeamSAP projects refer to projects carried out by TeamSAP partners, the use of ASAP or Powered-By implementation methodology, Project Quality Review, the assignment of an SAP Coach, and SAP's support on the project's steering committee. All of these are factors contributing to a successful implementation.

The following key benefits will enable you to carry out a more effective R/3 implementation and make effective use of your available resources:

AcceleratedSAP helps to manage a "Big Bang" implementation strategy with the focus on essential business processes.
There is a high degree of planning accuracy (time, costs, resources) through the Project Estimator and the Business Blueprint.
AcceleratedSAP lays the foundation for continuous change and efficient reconfiguration when business or legal requirements change.
You have a uniform approach to R/3 implementations among partners and consultants worldwide.
There is an assured quality and know-how transfer during implementation.
You can reuse the results of your configuration for subsequent implementation projects.
You have reduced implementation costs and quicker ROI.

Accelerated SAP Introduction

Enterprise application software has to cover a broad spectrum of functionality, yet be configured flexibly enough to meet specific requirements, which can vary enormously. SAP’s answers to this challenge are AcceleratedSAP and the R/3 Business Engineer, providing a comprehensive solution for implementing R/3 quickly, easily, and according to your own needs even during productive operation.

Born out of the need to cost effectively configure R/3 to order, AcceleratedSAP and the Business R/3 Engineer support custom configuration of R/3. You can tailor the R/3 components, functions and organizational structures to your needs, hiding and/or deactivating those functions that are not required.

Fig. 1: The R/3 Business Engineer Complements ASAP

AcceleratedSAP (ASAP) is SAP's standard implementation methodology. It contains the Roadmap, a step-by-step guide that incorporates experience from many years of implementing R/3. Along with that, AcceleratedSAP contains a multitude of tools, accelerators and useful information to assist all team members in implementing R/3. Quality checks are incorporated at the end of each phase to easily monitor deliverables and critical success factors. ASAP is delivered as a PC-based package, so that - if required - an implementation project can begin prior to having an R/3 System installed.

The R/3 Business Engineer contains a set of configuration and implementation tools which enable you or your consultants to define and configure R/3 and also to adapt an existing configuration to new needs or changed circumstances. The Business Engineer is resident to R/3.

So that its customers can implement R/3 as quickly as possible, SAP has standardized the implementation procedure, simplified the way functions are presented and reduced the technical complexity of implementation.

AcceleratedSAP and the Business Engineer help you configure R/3 according to your own needs using proven, industry-specific business scenarios and processes. Whether implementing new processes in your enterprise or restructuring old ones, R/3 can release the full potential of change for you. AcceleratedSAP and the Business Engineer help you determine which of R/3’s proven processes are most suited to your business, and then help you configure to meet your specific needs. The benefit is obvious: Restructuring enterprise processes in the R/3 System leads to a rapid and efficient production startup, meaning a faster return on investment.

By simplifying configuration, ASAP and the Business Engineer make the power of R/3 more accessible, helping companies to lower their dependence on expensive specialists or outside consultants. The user-friendliness of ASAP and the Business Engineer make them particularly suitable for the following groups:

Business professionals who need to discuss, prototype and design their business blueprint (enterprise model)
IS departments of large enterprises who need to customize R/3 applications more efficiently and more rapidly
Small and medium-sized companies previously wary of implementing R/3 because of the perceived scale of such projects
Consultants and SAP partners looking for an efficient way of offering their customers configure-to-order or wishing to develop R/3-based solutions for niche markets

Together, AcceleratedSAP and the Business Engineer empower you to manage cost, time and quality without compromising on implementation requirements. Some of the features offered are:

 Reduced implementation times and faster return on investment through structured planning and preconfiguration

Intuitive understanding of the wide range of functions offered by R/3

Process optimization using proven scenarios, processes and value chains, illustrating clearly the software’s capabilities and offering practical help when you configure the R/3 System.

 High quality installations through comprehensive procedural guidelines

 Optimizing business processes using SAP Business Workflow, via process monitoring and automation of procedures

Continuous, dynamic adjustment and optimization of R/3 applications

The capability to copy configured areas, for example, by transferring existing settings to new organizational units.

AcceleratedSAP and the Business Engineer are designed for openness and new platforms, using HTML-based documentation. Compatibility with many third-party modeling tools and software packages, for example, Microsoft Excel, is ensured.

Available Tools

Embarking on an implementation project requires a lot of careful thought beforehand. You need to think about what you want to accomplish, the optimum sequence, and the business cases that are best suited to your needs. But SAP has already done a lot of the thinking for you and packaged its findings in the following tools. They are then described in more detail in the following chapters organized according to the corresponding AcceleratedSAP phases.

AcceleratedSAP (ASAP): A comprehensive solution for the introduction of the R/3 System in your enterprise. ASAP and most of its tools can be used independently of an R/3 installation.

The tools available for AcceleratedSAP are:

The Project Estimator, an internal SAP tool which enables SAP consultants to accurately gauge the required resources, the costs and the time frame of implementation. The Project Estimator takes into account the project scope and several project and risk factors.
The Concept Check Tool, a tool enabling you to carry out quality checks on the project preparation, technical infrastructure and R/3 configuration settings. This is done mainly during the first two implementation phases of the R/3 project. In this way you are alerted to potential data volume and configuration conflicts that could lead to performance issues if not addressed.
The Implementation Assistant: The ASAP navigation tool that accompanies you through the five phases of implementation down to the task level. It includes a description and a detailed "how-to" for each task in the Roadmap. Along with that, many tools, templates and documents are hyperlinked to the task. The Implementation Assistant contains the following elements:

ASAP Implementation Roadmap
and Project Plan. The Roadmap contains the five phases, from which you can drill down into work packages, activities and tasks. The Project Plan contains three components, a budget plan, a resource plan and a work plan. These are explained in more detail in the next chapter.

The ASAP Roadmap is the successor of the R/3-based Procedure Model, which was used until Rel. 3.1 in R/3 implementation projects.

Knowledge Corner
, containing tips and tricks for configuration from consultants, detailed documentation on SAP’s implementation services, information on technical tools, as well as simplification guidebooks and R/3 Customizing wizards.

Question and Answer Database (Q&Adb).
Using the R/3 Reference Model structure, the Q&Adb is used to assist in gathering requirements for business processes, conversions, reports, interfaces, enhancements and authorizations. The database provides useful questionnaires to help you define the process needs and also serves as a repository for all this information. Since it is a database, it allows for flexible reporting. The business requirements generated from the Q&Adb are collectively known as the Business Blueprint.

Business Process Master List
, to manage configuration, testing and the creation of end user documentation. The Business Process Master List is linked to pre-written Business Process Procedures (BPPs), detailled end-user documentation for R/3 transactions.
Issues Database
: supporting project management, this database supports the entering, monitoring and managing of issues that come up during the project.

R/3 Business Engineer:
The implementation tools for the high-quality configuration of the R/3 System are:

R/3 Reference Model: Comprehensive graphical process flows describing the R/3 functionality from different points of view. It contains scenarios, processes and functions, as well as components. The R/3 Reference Model can be viewed using SAP's Business Navigator and the Business Navigator Web, or using third-party modeling tools available from modeling partners.

Implementation Guide
(IMG): Used to configure all system parameters for the business processes in R/3. It contains project management functionality and a menu-driven view of all R/3 Customizing activities. Every activity can be documented in detail, and responsibilities and statuses can be assigned.

Preconfigured systems:

Preconfigured US and Canadian clients: Provides a head start on baseline configuration. It includes a preconfigured US/Canadian chart of accounts, print forms, account determination, units of measure, etc. The predefined test sequences that are included can be a starting point for integration testing.
Preconfigured industry systems: A number of complete preconfigured clients consisting of an industry-specific model and preconfigured business processes for the needs of a particular industry in R/3 are available. For more information on preconfigured systems, see the description of Phase 2, Business Blueprint or the information on the IDES System in this chapter.

Continuous Business Engineering

In today’s fast-moving, ever-changing business climate, companies are in a constant state of flux and their mission-critical applications must adapt and evolve at the same speed. If software cannot grow with the needs of a company, the company will quickly find itself in a straightjacket.

Furthermore, an ERP application needs to let you move forward fast, knowing that you can roll back changes without downtime.

An enterprise's organizational structure and the corresponding R/3 implementation created using the Business Engineer are not "set in concrete", they can be modified at any time. Examples of possible changes, which can be made rapidly include the following:

Addition or removal of entities within the organization structure (for example, business units, production plants, warehouses, etc.)
Introduction of new staff, promotion, reallocation of work tasks, and maintenance of authorization profiles

Changes to the reporting or cost/profit center structure

New and concurrent currencies

Accommodation of changed legal requirements (for example, new tax rates, new employment legislation)

Activation or deactivation of R/3 functions

Optimization of business processes

Support for new and multiple versions of R/3

In addition, SAP offers a range of services if you want support for some of these changes, for example, conversion services to support mergers and acquisitions. Standard Euro services are a further example of the available services.

AcceleratedSAP and R/3 Business Engineer take the hassle out of implementation procedures and change management. Modifications can be made at any time, and the compatibility of changes can be verified with other configuration decisions, thus supporting their smooth, trouble-free introduction into the productive system.

Issue free goods to selected Customers

Client wants to issue free goods to selected customers after the said customer buys a specified quantity of a good during the festive season starting 02 December to mid January. for example customer A buys 34 cartons of Corn Ice-cream, we offer him 12 free corns. this should then reflect as cost in our accounts. the rest of the system is already up and running and should not be inconvinienced. How do I set it up?

1.Run trans. VBN2 to first create master record for free goods as follows:

Enter following information in selection screen:
- Free goods type: NA00
- Sales org, distribution channel, customer # and execute.

Now in next screen create the record as follows:
- First select the exclusive button and verify that you are in exclusive view.
(that is if you want exclusive)
- Material#, Min qty - Say 34 cartons. (check in what units you want to manage)
From: 34 cartons
unit of measure:
Free goods: 12 Pcs
Unit of measure: Pcs
Calcualtion type: 1 or try the other options
Deliver control: Blank or any of the other options suitable to you.

Now save and exit.

Now run VA01 for 34 cartons and press enter. The system will automatically propose the free goods

item at no additional charge. Try higher order qtys and see if the free goods qty are scaling up.

If not adjust the calculation parameters in the master record screen

It should be transaction VBN1. Sorry for the error.
VBN2 is to change the record. VBN1 creates it.

Kris J

If you want to give free goods to some of the customers than

1. create a customer group say 99 for FREE GOODS

In Free Goods Menu:
2. add a feild catalog for CUSTOMER GROUP
3. create a condition table (free goods) say 555 only for customer group
4. create a sequence say FREE with condition table 555
5. create a condition type say FREE with
6. maintain pricing procedure say ZFREE with condition type FREE

Now assign:
7. Active Free goods Determination or Assign with your sales organisation this procedure ZFREE
8. Create free goods determination with transaction code /nvbn1 for FREE with Key Csuomer Group

99 for exclusive

Give customer Group say 99 and from 34 to 34 free 12

Sales and Distribution - Upload Condition Pricing

Sales Order Management Transactions

GENERAL ORDER MANAGEMENT
Reviewing Document Flow VA03
Searching for a Customer Sales Order by Serial Number ZV11
Order Inquiry ZV33

SALES ORDER PROCESSING
Creating Sales Order VA01
Maintaining a Sales Order VA02
Displaying a Sales Order VA03
Releasing an Order or Delivery from Credit Hold: Non-Flooring VKM1
Releasing an Order or Delivery from Flooring Hold ZKM1
Manually Pre-authorizing Blocked Credit Card Orders Z.14
Display List of RMAs by Customer VA05
Confirm RMA Goods Receipt VL02
Generate list of open return orders for deletion VA05
Display Customer returns eligibility MCSI
Removing a Billing Block (Approving Credit/Debit Requests) V.23

What is purpose of maintaining common distribution channels and common divisions?

Common Distribution Channel and Common Divison are maintained so that if any master data like customer or material maintained with respect to one distribution channel can be used in other DCh. It prevents the multiplication of master records.
Eg: A customer is created for say sales area 1000/20/00 then the same customer can be used in sales area 1000/30/00 if we maintain 20 as common distribution channel. Hence no need for extending the customers…the same for materials also.

M/SD: automatic transfer of cancellation billing document

In a subscription with amortization (delivery subscription or renewal subscription), posting occurs automatically when you cancel a billing procedure using the function “Function backdated.”
In the case of a collective transfer, separate intermediate payment data is created for the individual cancellation billing document, which is not desirable in FI.
Subsequent to this note, see Note 794764.

Solution
The constraint is removed so that a cancellation billing document is no longer posted automatically. The program change is available with the next Support Package.
A manual advance correction is attached to this note.

What is the difference between inbound and outbound delivery?

Inbound—material entered into plant (for stock purpose)

planned order 2- purchase order 3- production order
outbound—delivered from plant like all types of delivery process(through PGI)

What are the Steps for the End-user Training in SAP-sd module?

1. We will decide who the team members of end users are

2. Arrange one comman place for training

3. In a day with pre planned material and using development system with some hard copies of various transaction codes which will use by end users will distribute to them and ask them to practice

4. It is generally like an in house training which may remains for 2 daisies

5. After the training we will give them hard copies of list of transaction codes with narration which are relevant to their modules like SD related and PM related etc

What is the difference between ERB and ERU account keys?

ERB is the account key used for rebate processing and it is a sales deduction.ERU is the accurual key used in pricing for rebate processing it is used for difference in sales revenues.

ERB is sales deduction and ERU is the accrual amount. Both amts are same but posted to diff GL a/cs

What r the 5 imp fields to be maintained in a/c determination

Account Determination: Sales View, Sales Organization, Distribution Channel, Chart of Accounts, Account Assignment Group for Customer and Material and Account Keys.

User-Exits in the In- and Outbound Processing of IDocs

This document includes a list of user-exits, sorted by message type, which can be used in the in- and outbound processing of the corresponding IDoc.

You can download this document from the attachments section below.

How sales document is structured?

Sales Document is structured as three levels
1. Header Level
2. Item Level
3. Schedule line Level

Deleted deliveries

When you delete a document - It gets deleted from document flow also.

An easy way of finding it is go into va03 and enter any document which hasn't been deleted. Go in to Environment - Changes. Here, you change the document number that has been deleted. When you click execute button, you will be able to see all the changes and deletions as well.

Shipping Unit Tables in SD

Shipping Unit Tables in SD

VEKP - Shipping Unit Item (Content)

VEPO - Shipping Unit Header

Supplementary Invoice in SD

Have created one proforma invoice & transferred stock to my branch / depot at Delhi. This is my mother invoice with MRP, say, Rs. 100/-. Now the MRP is increased from date: 01.08.2007 with Rs. 107/-. I need to pass on the additional Excise duty for difference amount Rs. 7/-.
Is it possible to generate supplementary invoice in SAP SD module?
If yes, then how to create it? Please help me how could I resolve the problem.

To the best of my knowledge you cannot generate an excise invoice without reference to goods movement.
If you want to ensure the customer is debited for the relevant amount, please generate a credit memo and an excise JV to ensure that the relevant accounting entries are passed. However tracking is possible only through text fields.

Creating a Sales Document in SAP R/3

Various modules in SAP are based on the document concept. Every transaction in SAP can be traced back to a unique document number. While creating a sales document in SAP R/3, a user has to enter the following information in SAP:

- Document Type i.e. whether it is a quotation, sales order etc.
- Customer Details. This contains details such as sold-to-party, customer number etc.
- Sales Area. This includes Sales Organization, Sales Channel and Sales Division

Once all this information is entered in SAP, price is decided for the sales document depending upon the pricing determination procedure. In SAP, the steps which determine data appearing on the screen for e.g. price while document creation is called a determination procedure in SAP IMG. In SAP, one can choose from around 30 different types of price determination procedures defined. SAP also comes with over 100 standard condition types. Thus, creating a sales document is very easy provided it is done in a step by step manner

What and where types of copy controls we change

Copy Control: is basically meant so that Data is copied from preceding Document to subsequent one. What subsequent Document is required is to some extent determined by Customer Requirements as well as Document Types. e.g. In general case of Standard Order, it will be Copy Control (Order to Delivery) from OR to LF .

Avaialbility check 01 (Daily requirement) and 02 (Individual Requirement) in material master

01 and 02 are the checking group. Availability check is carried out with the help of these checking group and checking rule. Checking group 01 and 02 are maintained on the material master.

01 - Individual requirement -For this system generates transfers the requirement for each order to the MRP .So that MM can either produce or procure.

02- Collective requirement.-In this all the requirements in aday or in a wek are processed at a time. System stores all req and passes on to the MRP in MRP run.In this system performance is high however you can not do the backorder processing whereas in other you can do.

If we dont give the horizan period in dynamic credit check

It will become Static Credit Check. Simple Credit Check means the Risk category of the customer is not considered. In Static and Dynamic, risk category is considered, only difference between them being that Dynamic has a time horizon, meaning that it does not consider open sales orders and open deliveries intended to be delivered beyond this horizon date for calculating the customer's credit exposure.

Consolidation route and delivery routes

consolidation route :

consolidation route is defined between the development sytem (consolidated system ) and the quality system (integration system )

Delivery route :

Delivery route is the transport route that connects the integration system and the Delivery system ( Production system )

Defining Logon Groups :

we can do this though our GUI and allways make sure that saplogon.ini is backed up , that consists of all the logon data

Logon Load balancing :

It is used to identify the least loaded application server

Domain controller :

it is the central admin of the system

transport domain :

it is the place the transport layer and routes can be configured to access this transaction use stms

Display/change data in credit management

When you process blocked Sales & Distribution (SD) documents (VKM1), the accounting clerk has only the authorization for displaying (and not for changing) certain FI credit management data (authorization objects F_KNKA_MAN, F_KNKA_KKB). However, the Transaction 'Customer Credit Management Change' (FD32) is always called up via the menu option 'Environment'. Since the accounting clerk only has the authorization for displaying certain data, the corresponding error message is also generated correctly. For the display of data only, you must therefore always use a new mode for calling up the Transaction 'Customer Credit Management Display' (FD33).

Solution
If an accounting clerk has only the authorization for displaying credit management data (authorization objects F_KNKA_MAN, F_KNKA_KKB), after calling Transaction FD32 the system changes automatically from 'Blocked Sales & Distribution (SD) documents list' to the display Transaction FD33. As a result, a new mode becomes unnecessary. This solution only makes sense if the authorizations in the credit management Transactions (FD32, FD33) were restricted by the mentioned authorization objects. If a user has no authorization for Transaction FD32 the source code changes will not be successful, because the authorization check for a certain transaction (authorization object S_TCODE) is not performed in the called transaction, and therefore no reaction from the called transaction (like automatic calling up of the display transaction) can be expected.
We recommend to solve the problem as follows: You should not remove the authorization for Transaction FD32 from users, but restrict the authorizations in Transaction FD32 through usage of the mentioned authorization objects.

Line item: Header information is missing

The system does not display any header information on the line item list for the general ledger, vendors or customers.Data is missing which identify the account in particular, as well as the account number and name.

SAP delivers standard layout variants for line item displays (including a header layout).The names of the variants delivered begin with a number.
For example, the standard variant '1SAP' is always used for list view if you leave the field 'Display variant' blank on the selection screen.In the header area of the display, the account number and the account name then should be displayed.
However, there may be an error in the delivery causing the header layout to be missing for standard variants.

Solution
Transfer the files as specified in Note 13719 which you can find in directory /general/R3server/abap/note.0181697 of SAP servers SAPSERV3, SAPSERV4, SAPSERV5 and SAPSERV6 into your system. With this transport, the current standard variants are copied together with the headers for the line item into your system. Bear in mind that a corresponding target client is specified. Otherwise they would have to be imported manually:

Call Transactions: FBL1N, FBL3N and FBL5N:
1. Line items display
2. Menu: Settings -> Display variant -> Administration
3. Menu: Environment -> Import layout

Line item: incorrect account information in header

You are in the line item display for vendors or customers. On the selection screen, you have selected field "Vendor items" or "Customer items". In the headers for these items, information is either missing for the account or does not apply.

The corresponding vendor or customer account for the vendor or customer is defined in fields LFA1-KUNNR or KNA1-LIFNR. Starting from this account number, the system reads the master data for the incorrect account type. If the vendor and the customer account are identified with the same account number, then the system displays the master data of the vendor in the header for the customer account and vice versa. Otherwise, the fields usually remain blank in the header.

Solution
This error is corrected in Release 5.0. You can also implement the attached advance corrections.

saptutorials.in

deals of the day amazon

SAP SD Help

About Me

Blog Archive