Document

Vendor Report Introduction

INTRODUCTION
1.1 Function Specification

1. Justification

Background Information
This report displays Vendor details for the given vendor range. The report is
displayed in the ALV format. Here user can specify the above selection criteria i.e. vendor
range. User can specify whether to download or to view the details. The download path is
specified for the user to download the vendor details, not only the download path but also
the format of the file like word document, excel document, text document, pdf or mail it up.

1.1 Requirement Summary and Overview of Conceptual Design

Prior to

1.2 Justification

Providing vendor details for the given vendor range. The report is displayed in the ALV
format. Provides navigation among reports

1.3 Related Development Specifications

N/A

1.4 Solution Options Considered Pros
Cons

• Option 1: displaying vendor details

• Option 2: navigation among report

1.5 Recommendation

Option 2 shall be considered. This will ‘called’ the process. (button click)

1.6 Key Decisions

1
AVANTHI INSTITUTE OF ENGINEERING & TECHNOLOGY
Department Of Information Technology


We are providing buttons to click for navigation

1. Functional Specification – High Level Requirements

2.1 Functionality

To minimize the human action or avoid the human interaction to improve the
transparency and accuracy we can run this report by scheduling the job in the background
periodically or daily depends on the client requirement.

Display’s all vendor details in a report by using supplies code and shipment data. Details
can be viewed or can be downloaded. User can specify download path and download
format. Provides navigation among reports to view further details. Data can’t be changed by
entering manual data. Reports will be user-friendly.

2.2 Assumptions

Now a day’s reports are developed in Excel sheets. There is a chance to edit the data
by entering manual data which causes fraud. A1 business never prefers the human
interaction. We can’t schedule it for automatic business process. Not User friendly. Even
reports in .NET and JAVA application are not human intractable and non user friendly.

2.3 Constraints

2.4 Performance Criteria

• The interface will trigger on a call transaction.

• Navigation among records.

It is expected to have transactional volume of approximately 1000 records per day

2.5 Applications Affected

2


<Identify the Applications impacted whether it is SAP or Non-SAP Systems.>

SAP System Impact/ Change Description

SAP FI module and AP sub-
module

Non- SAP System Impact/ Change Description

2. Functional Specification – Detailed Specifications

3.2 Specification for Interfaces & Enhancements

3.2.1 General

Interfaces:

• Inbound/Outbound Outbound

• Source System SAP ECC

• Target System

• Trigger FTP sweep/pull from SAP server directory.

• Frequency Call

• Volume Around 1000 Checks per click

• Archiving Requirements N/A

• Method of Execution Asynchronous

Enhancement/User Exit:

• User Exit Name N/A

• Processing Logic N/A

3


Error Handling/Reprocessing Error log to be created for unprocessed transactions if
Method PI does not reprocess the errors.

Did the batch job trigger as scheduled? If not, send an
email notification.
Post Execution Notification
Details Did it post? If not, send an email notification.

Do we have errors? If yes, send an email notification.

Transaction Codes SE11, SE38

Menu Path SE41

Required Screens N/A

Existing Development Object System : Object Name:

3.2.2 Mapping

Interfaces/Enhancements

3. Additional Information

4.1 Test Plan

4.1.1 Related Business Scenario and Business Transactions

4.2 Backup/ Recovery

<This section should define the general recovery strategy for this design (Only required
for interfaces & conversions)>

4.3 Security Profile & Authorization

4.4 Related/ Referenced Documents

4


Document Name Version Brief Description

4.5 Cross-Functional Impact

Task Force Team Impact Individual Notified/Date

4.6 Attachments

Document Name Version Brief Description

5


1.2 Literature

ABAP
ABAP (Advanced Business Application Programming) is a high level programming
language created by the German software company SAP. It is currently positioned as the
language for programming SAP’s Wed Application Server, part of its NetWeaver platform
for building business application. Its syntax is somewhat similar to COBAL

ABAP is one of the many application-specific fourth-generation languages (4GLs) first
developed in the 1980s. It was originally the report language for SAP R/2, a platform that
enabled large corporations to build mainframe business applications for materials
management and financial and management accounting. ABAP used to be an abbreviation
of Allgemeiner Berichtsaufbereitungsprozessor, the German meaning of "generic report
preparation processor", but was later renamed to Advanced Business
Application Programming.

The language is fairly easy to learn for programmers but it is not a tool for direct use by
non-programmers. Knowledge of relational database design and preferably also of object-
oriented concepts is necessary to create ABAP programs. ABAP remains as the language
for creating programs for the client-server R/3 system, which SAP first released in 1992.
As computer hardware evolved through the 1990s, more and more of SAP's applications
and systems were written in ABAP. By 2001, all but the most basic functions were written
in ABAP. In 1999, SAP released an object-oriented extension to ABAP called ABAP
Objects, along with R/3 release 4.6. SAP's current development platform NetWeaver
supports both ABAP and Java.

ABAP was one of the first languages to include the concept of Logical Databases (LDBs),
which provides a high level of abstraction from the basic database level(s). The ABAP
programming language was originally used by developers to develop the SAP
R/3 platform.

6


All ABAP programs reside inside the SAP database. They are not stored in separate
external files like Java or C++ programs. In the database all ABAP code exists in two
forms: source code, which can be viewed and edited with the ABAP Workbench tools, and
generated code, a binary representation somewhat comparable with Java bytecode. ABAP
programs execute under the control of the runtime system, which is part of the SAP kernel.

The runtime system is responsible for processing ABAP statements, controlling the flow
logic of screens and responding to events (such as a user clicking on a screen button); in
this respect it can be seen as a Virtual Machine comparable with the Java VM. A key
component of the ABAP runtime system is the Database Interface, which turns database-
independent ABAP statements ("Open SQL") into statements understood by the underlying
DBMS ("Native SQL"). The database interface handles all the communication with the
relational database on behalf of ABAP programs; it also contains extra features such as
buffering of tables and frequently accessed data in the local memory of the application
server.

7


SAP Basis
The ABAP language environment, including the syntax checking, code generation and
runtime system, is part of the SAP Basis component/layer. SAP Basis is the technological
platform that supports the entire range of SAP applications, now typically implemented in
the framework of the SAP Web Application Server. In that sense SAP Basis can be seen as
the virtual machine on which SAP applications run. Like any operating system, SAP Basis
contains both low-level services (for example memory management, database
communication or servicing Web requests) and high-level tools for end users and
administrators. These tools can be executables ("SAP kernel") running directly on the
underlying operating system, transactions developed in ABAP, or Web-based programs.

SAP Basis also provides a layer of abstraction between the business applications and the
operating system and database. This ensures that applications do not depend directly upon a
specific server or database platform and can easily be ported from one platform to another.

SAP systems and landscapes
All SAP data exists and all SAP software runs in the context of an SAP system. A system
consists of a central relational database and one or more application servers ("instances")
accessing the data and programs in this database. A SAP system contains at least one
instance but may contain more, mostly for reasons of sizing and performance. In a system
with multiple instances, load balancing mechanisms ensure that the load is spread evenly
over the available application servers.

Installations of the Web Application Server (landscapes) typically consist of three systems:
one for development, one for testing and quality assurance, and one for production. The
landscape may contain more systems, e.g. separate systems for unit testing and pre-
production testing, or it may contain fewer, e.g. only development and production, without
separate QA; nevertheless three is the most common configuration. ABAP programs are
created and undergo first testing in the development system. Afterwards they are
distributed to the other systems in the landscape. These actions take place under control of
the Change and Transport System (CTS).

8


SAP ERP

SAP (Systems, Applications and Products in Data Processing) started operations in
Germany in 1972. It is the world’s largest vendor of standard application software, the
fourth largest software vendor in the world, and the market leader in enterprise applications
software. The most current version of R/3 utilizes client server technology and contains
over 30,000 relational data tables that enable a company to link its business processes in a
real-time environment. Each instance (installation) of SAP can be distinctively configured
to fit the needs and requirements of customer operations (within limits).

SAP is a German company that develops business software. ERP stands for Enterprise
Resource Planning, and is the term used to describe an integrated software solution that
incorporates the key functions of an organisation.

Advantages

Allows easier global integration (barriers of currency exchange rates, language, and
culture can be bridged automatically)
Updates only need to be done once to be implemented company-wide
Provides real-time information, reducing the possibility of redundancy errors
May create a more efficient work environment for employees
Vendors have past knowledge and expertise on how to best build and implement a
system

Disadvantages

Locked into relationship by contract and manageability with vendor - a contract can
hold a company to the vendor until it expires and it can be unprofitable to switch
vendors if switching costs are too high
Inflexibility - vendor packages may not fit a company's business model well and
customization can be expensive
Return on Investment may take too long to be profitable
Implementations have a risk of project failure

9


Microsoft Windows releases versions

Release
Release End of life Features
date

First "GUI" for SAP software; no graphical elements like
1.0 – –
checkboxes, radiobuttons and icons

Field length indicated by background colors; fast paths in
1.1 – –
menus

New GUI for Windows 3.1; System and Application
2.0 – –
Toolbar added; icons in System Toolbar

New graphical elements: checkboxes, radiobuttons, group
2.1 – –
boxes and push buttons on screen

3.0 – – Table control introduced; icons added to buttons

Windows95-look with flat buttons; tabstrip control and
3.1 1996 –
ABAP List Viewer (ALV) introduced

4.0 – – Screens contain more information to reduce navigation

Active X elements introduced; ALV is now based on grid
4.5 – –
control

July GUI is re-designed; multiple-areas are introduced to
4.6D –
2000 reduce need for screen changes

July
6.10 – –
2001

10


March
6.20 – –
2002

June Unicode support extended; accessibility and usability
6.40 31/12/2010
2004 improved

February Support for Microsoft Vista and Office 2007; new "Tweak
7.10 12/04/2011
2007 SAP GUI" tool; new ABAP front-end editor

Support for Windows XP; Windows 2003 Server;
April Windows Vista; Windows 2008 Server; Windows 7 and
7.20 -
2010 Office 2010; Built with Visual Studio 2008; current patch
level is 11

CLIENT
We have the concept of a SAP instance, and that instance has a database which contains
thousands of tables which contain a whole bunch of rows. After SAP is installed, these
tables need to have some base data in order for customization and configuration to
begin. Like state abbreviations, country codes, HR titles, etc.
SAP provides a subset of this data so that the Basis team can get in the new instance, add
themselves a user ID in client 000 – “our” client - and start the real work. We don’t want to
mess this subset of data up so we need to populate it to a “work” place for the Functional
Team to do their work. Or several work places.
The base SAP instance comes with two clients: 000 and 066. Forget client 066, it is used
by SAP when you get close to GoLive and you want an EarlyWatch report. This is optional
and I believe a fee is involved for this service.
All the base or subset data is contained in client 000. Also, client 000 is where the Basis
Team does a lot of its maintenance like patching. The Basis Team people are the only
implementation members who will ever have access to client 000. You can think of client

11


000 as the owner of all the client independent data in the SAP instance. Explanation in a
minute.
So, in order to let the Functional Team do their own thing without screwing anything up,
we create a new client for them. Think of a client as a view of the database. If you log into
client 000, you can see all client independent data – like the ABAP programs – and all the
data that is dependent on client 000 only.If you log into client 100, you see all client
independent data – like the ABAP programs – and all the data that is dependent on client
100. You can’t see the data that is dependent on client 110 while you are logged on to
client 100.
Thus the concept of client dependent and client independent data. All rows in some tables
are accessible from any client like T000, the Data Dictionary tables, tables that contain the
ABAP programs, printers, etc. These are said to be client independent. Data like users,
companies, vendors, customers, etc. are client dependent. You have to go into a specific
client in order to see this data.

R/3 Architecture

The term SAP R/3 stands for runtime system three and the client-server environment
provides a set of business application for the system. The R/3 architecture allows
distribution of the workload to multiple PC's connecting in a network. The SAP runtime
system is designed in such a way that it distributes the presentation, application logic and
the data management to different computers.

The presentation components are responsible for the interaction between the R/3 system
and the user as well as for desktop component integration (such as word processing and
spreadsheets).

SAP R/3 architecture is based on a three-tier client/server model:

Presentation Server
Application Server
Database Server

12


Though it is a three-tier architecture model, it is not restricted only in three-tier; it can go
up to multi-tier client-server system. In SAP the software components are arranged in tiers
and function depending on their position. SAP R/3 must have at least one presentation
server, one application server and exactly one database server.

Presentation Server

Out of the three-tie, presentation server is the one which runs on user workstation. The
SAP graphical user interface (SAP GUI) is run on this layer. No application logic is
processed in this layer. SAP GUI does not adhere to the style guidelines of its host system.
The layer contains the software component that makes up the SAP GUI (graphical user
interface). This layer is the interface between the R/3 system and its users. The SAP R/3
uses the SAP GUI to provide intuitive graphical user interface for entering and displaying

13


data. The Presentation layer sends the user’s input to the application server and receives
data for display from it. While a SAP GUI component is running, it remains linked to
user’s terminal session in the R/3 system.

Application Server

Another tier in the SAP R/3 system is the application server where the actual business
logic is being executed. It sends the data to be presented to the user, to the Presentation
layer. It comprises the business administration "know-how" of the system and processes
pre–defined and user–defined application programs, such as OLTP and the implementation
of decision support queries. Application servers are usually connected via a local area
network with the database server.

The Application layer consists of one or more application servers and a message server.
Each application server contains a set of services used to run the R/3 system. Not practical,
you only need one application server to run an R/3 system. But in practice, the services are
distributed across more than one application server. This means that not all application
servers will provide the full range of services. The message server is responsible for
communication between the application servers. It passes requests from one application
server to another within the system. It also contains information about application server
groups and the current load balancing within them. It uses this information to choose an
appropriate server when a user logs onto the system.

Database Server

The next tier is the database server where the actual RDBMS lies. This layer holds the
system – wide database and the central booking process of the SAP R/3 architecture. The
Database layer is comprised of a central database system, which contains all the data in the
R/3 system. The database system has two components – the database management system
(DBMS) and the database itself. The R/3 support the database system from the suppliers,
such as ADABAS D, DB2/400 (on AS/400), DB2 Common Server, DB2/MVS,

14


INFORMIX, Microsoft SQL Server, ORACLE, and ORACLE Parallel Server; SAP does
not manufacture its own database.

The database not only contains the master data and transaction data from your business
applications, but also the data for the entire R/3 system is stored here.

Authentication into ABAP systems
There are four common approaches for authentication into ABAP systems:

• Usernames and passwords
• SAP Logon Ticket
• Secure Network Communications
• Single Sign-On
Types of ABAP programs

As in other programming languages, an ABAP program is either an executable unit or a
library, which provides reusable code to other programs and is not independently
executable.

ABAP distinguishes two types of executable programs:

• Report
• Module pools

Reports follow a relatively simple programming model whereby a user optionally enters a
set of parameters (e.g. a selection over a subset of data) and the program then uses the
input parameters to produce a report in the form of an interactive list. The term "report"
can be somewhat misleading in that reports can also be designed to modify data; the reason
why these programs are called reports is the "list-oriented" nature of the output they
produce.

Module pools define more complex patterns of user interaction using a collection of
screens. The term “screen” refers to the actual, physical image that the user sees. Each
screen also has a “flow logic”, which refers to the ABAP code implicitly invoked by the
15


screens. Each screen has its own flow logic, which is divided into a "PBO" (Process
Before Output) and "PAI" (Process After Input) section. In SAP documentation the term
“dynpro” (dynamic program) refers to the combination of the screen and its flow logic.

We present platypus, an authenticated source routing system routing system built
around the concept of network capabilities, which allow for accountable, fine-grained
path selected by cryptographically attesting to policy compliance at each hop along a
source route. Platypus policy framework that can be used to address several issues in
wide-area routing at both the edge and the core, and evaluate its performance and
security. Our result show that incremental deployment of platypus can achieve immediate
gains.

Oricale
Oracle leads the market for databases supporting enterprise business applications such as
the SAP Business Suite. More than two-thirds of all midsize to high-end SAP customers
in every industry entrust their application deployments to Oracle databases.

Organizations are running SAP applications with Oracle databases on the same code base
on Unix, Linux, Windows, and the Oracle Solaris operating system. And with the release
of Oracle Database 11gRelease 2, SAP customers are benefitting from innovative
features such as self-tuning database components, sophisticated partitioning schemes, and
data compression that enables high performance, greater scalability, and optimal use of
hardware resources for enterprise applications. Oracle Database 11g Release 2 is now
certified for use in an SAP environment on Unix, Linux, and Windows platforms.

Oricale with SAP
The Oracle Database is the #1 database among SAP customers around the globe. This
very large and growing customer base gains a cost benefit from the two companies’
technologies in the long term and receives first-class database support from both Oracle
and SAP.

16


SAP R/3 was originally developed on Oracle, and the companies have a deep relationship
at the technical level. Subsequent SAP products, such SAP Business Information
Warehouse (BW) have also been developed using the Oracle database. Oracle's assistance
during incorporation of new database features, performance testing, bug fixing, and
customer problem escalations has been invaluable to the large number of SAP customers
running on Oracle.

Oracle deploys a significant amount of resources at SAP locations around the world to
deliver safe, reliable, and scalable DB technology and round-the-clock services with a
dedicated, long-term commitment to the mutual customer base.

Oracle Database 11g Release 2 Enterprise Edition delivers industry leading performance,
scalability, security and reliability on a choice of clustered or single-servers, running
Windows, Linux, and UNIX. It provides comprehensive features to easily manage the
most demanding transaction processing, business intelligence, and content management
applications. Oracle Database 11g Release 2 Enterprise Edition comes with a wide range
of options to extend the world’s #1 database to help grow your business and meet your
users performance, security and availability service level expectations.

SAP has certified Oracle Database 11g Release 2 with the following details:

Only SAP products based on SAP Kernel 6.40_EX2, 7.x and higher are certified with
Oracle Database 11.2.
A general release of Oracle Database 11g Rel. 2 is not provided for earlier SAP
releases (SAP R/3
3.1I up to and including SAP R/3 4.6C). Similar to Oracle Database Version 10.2, there
is only a temporary 11.2 release in direct connection with an SAP upgrade project for
these older SAP versions.
The SAP release of Oracle Real Application Clusters (RAC) 11g Release 2 occurred at
the same time as the general release of Oracle Database 11g Release 2 in the SAP
environment. For information about Oracle RAC support, (see SAP Note 527843). It
contains important details about the released RAC configurations.

17


As of Oracle 11g Database version 11.2.0.2, SAP fully supports Oracle Automatic
Storage Management Oracle (ASM) and its extended functionality to manage ALL
data: Oracle Database files, Oracle Cluster ware files and non-structured general
purpose data such as Oracle and SAP kernel binaries, external files and text files.
Oracle ASM simplifies, automates and reduces cost and overhead by providing a
unified and integrated solution stack for all file management needs, eliminating the
need for 3rd party volume managers, file systems and clusterware platforms. Oracle
ASM has two major enhancements that are important for running SAP.
Oracle Cluster Repository (OCR) and voting files can be stored on Oracle ASM.
Oracle RDBMS Home can be stored on Oracle’s new cluster file system ACFS.

This makes Oracle ASM the preferred storage platform for SAP running on Oracle Real
Application Clusters as well as for SAP systems running on a single instance Oracle
Database. Oracle Database 11g Release 2 provides customers more benefits: saving disk
space with lower hardware costs, more performance, higher security, better manageability,
exceeding productivity and at least in an outstanding high availability/disaster recovery for
SAP applications. The following provides a list of important features available for SAP
customers today and many of them are unique to Oracle.

18

Vendor Report Requirement Software Specifications

Software Requirement Specifications

2.1 Existing System

Now a day’s reports are developed in Excel sheets. There is a chance to edit the data by
entering manual data which causes fraud. A1 business never prefers the human interaction.
We can’t schedule it for automatic business process. Not User friendly. Even reports in .NET
and JAVA application are not human intractable and non user friendly.

2.2 Proposed System

To minimize the human action or avoid the human interaction to improve the transparency
and accuracy we can run this report by scheduling the job in the background periodically or
daily depends on the client requirement.

Display’s all vendor details in a report by using supplies code and shipment data. Details can
be viewed or can be downloaded. User can specify download path and download format.
Provides navigation among reports to view further details. Data can’t be changed by entering
manual data. Reports will be user-friendly.

2.3 Systems Requirements

Software Requirements
Operating system : Windows 2003.
Front End : SAP-GUI.
Programming Language : ABAP-CA/4.
Back End : Oracle.

19


Hardware Requirements

SYSTEM : Intel core-duo.
HARD DISK : 500 GB.
RAM : 4 GB.

2.4 System Architecture

Fig.2.5.1 System architecture for project

20


2.5 Functional Diagrams Modules description
A data flow diagram (DFD) is a graphical representation of the "flow" of data through
an information system, modeling its process aspects. Often they are a preliminary step
used to create an overview of the system which can later be elaborated. DFDs can also be
used for the visualization of data processing (structured design). A DFD shows what
kinds of data will be input to and output from the system, where the data will come from
and go to, and where the data will be stored.

Fig.2.4.1 Data flow diagram

21



22



23

Vendor Report Design

Design
3.1 Pre-coding phase
Before coding starts, and sometimes as part of technical review, the Developer will:

Identify similar programs, functions, etc.
Identify tables to be used as a source of the information.
Advise DBAs if new tables or indexes must be created.
Decide whether to copy an existing program or create brand-new.
Define names for new programs, tables, etc.
For update or conversion programs, determine what the best update method is (call
transaction or batch input sessions or inserts). Volume is an important factor in this
decision.
Decide what development class to use (see Naming Standards document).
If this is a one-time-only program for DIS or RIS modules, then consider saving it in
the conversion development class (ZDTP_DIS or ZRTP_RIS).

To identify similar program or functions, one should review the existing functions or
reports. Since this should be part of the Analyst’s preliminary investigation, the Analyst
should be able to provide this information to the Developer.

SAP reports can be found via reporting application-specific trees or area menus. To
identify what tables to be used as a source of the information, the Developer should use
following resources:

ask the Analyst,
for FM reports see FM Data Architecture document,
check SAP logical databases,
debug or SQL-trace SAP programs,
use Repository Browser.

Similar programs or functions should be used to cut down on development time and
debugging. Appendix B provides “common” function modules, includes, search helps
and views. New development objects could be:
24


programs
tables
data elements
domains
structures
lock objects
change documents
function modules
screens
search help
SAPsript layout sets
Includes
Transactions
Number ranges
Messages

If new objects are to be developed, one must use naming conventions as described in
Naming Standards document (see Appendix A). If there is no convention for the new
object, the Developer must contact the Manager of Technical Services.

Following should be noted: if SAP code is copied, prefix copied SAP programs with ‘z’
and a letter denoting the module (e.g. ‘ZR_’) -- this will make it easier to identify the
module to which the program belongs.

Whenever new tables or indexes are being created, the DBAs and/or the data architect
must be notified and consulted. The following information should be provided to them:

Table name
Indexes
Estimated number of rows
Growth pattern
How often accessed
Buffered or unbuffered.
25


Note that Z* and Y* tables should be created using data class USER or USER1 and that
USER8 and USER9 classes should not be used. For DIS and RIS modules the data model
should also be updated when data dictionary changes are made.

One of the tasks that developer often has to do is to apply SAP OSS note(s). Note
Assistant should be used for implementing SAP notes (transaction code SNOTE).

3.2 Technical Specification

Description/ Background

This report displays Vendor details for the given vendor range. The report is
displayed in the ALV format. Here user can specify the above selection criteria i.e.
vendor range. User can specify whether to download or to view the details. The
download path is specified for the user to download the vendor details, not only the
download path but also the format of the file like word document, excel document, text
document, pdf or mail it up.

Object Code

Object Name Zvendor_details

Object description LC Vendor Details

Reference Object

Transaction ZLCVR

26


Selection criteria

Field Technical Name Data Type
Description (Length) Remarks

Vendor details EKKO-EBELN CHAR (10) where EKKO-EBELN
= EBELNS

Selection Screen
When the program is executed, user can specify the vendor range. Details of vender
are displayed in ALV grid view.

Program logic
Include zinclude for data declarations.

Select data from lfa1,ekko,vbak,ekpo tables and pass it into internal table gi_output.

The vendor details is displayed in ALV format.

The download option is given for the user to download vendor details.

Output
Display vendor details using ALV grid view. User can view customer details of
selected vendor(s). By using single selection or multiple selections we can view vendor
account details.

27


Output details

Column Description Feed Rule

EKKO-EBELN PO no.

EKKO-AEDAT Date.

EKKO-BUKRS Company code

EKKO-BSART Document type

EKKO-LIFNR Vendor ac no


EKPO-EBELN PO no.

EKPO-EBELP Line no

EKPO-MATNR Material no

EKPO-MENGE Quantity

EKPO-MEINS UOM

EKPO-NETPR Price

EKPO-BUKRS Company code

28



KNA1-KUNNR Customer no.

KNA1-LAND1 Land1

KNA1-NAME1 Name1

KNA1-PSTLZ Pin code

KNA1-STRAS House no

KNA1-TELF1 Telephone number

KNA1-TELFX Fax number

Object List

Object Type Name Description

PROG ZVENDOR_REPORT LC Vendor report

TRAN ZLCVR LC vendor report

TABL GT_EKKO For ALV output structure

TABL GT_EKPO For ALV output structure

TABL GT_KNA1 For ALV output structure

TABL GT_LFA1 For ALV output structure

DTEL EBELNS Vendor range

29

Vendor Report Implementation

IMPLEMENTATION

4.1 IMPORTANT METHODS IN CODING

The implementation is the final and important phase. It involves User training, system
testing and successful running of the development system. The users test the developed
system when changes are made according to the needs. The testing phase involves the
testing of the developed system using various kinds of data. An elaborate testing of data
is prepared and system is tested using the tests data.

Implementation is the stage where theoretical design turned into a working system.
Implementation is planed carefully to propose system to avoid unanticipated problems.
Many preparations involved before and during the implementation of proposed system.
The system needed to be plugged into organization’s network then it could be accessed
from anywhere, after logins into portal. The tasks that had to be done to implement the
system were to create the database domain. Then the administrator was granted his role
so that the system could be accessed. The next phase in the implementation was to
educate the system. They are,

Shamir’s IBS scheme
Pairing Based scheme
Key redistributions & IDS,IDE methods

A transaction in SAP terminology is the execution of a program. The normal way of
executing ABAP code in the SAP system is by entering a transaction code (for instance,
VA01 is the transaction code for "Create Sales Order"). Transactions can be called via
system-defined or user-specific, role-based menus. They can also be started by entering
the transaction code directly into a command field, which is present in every SAP
screen. Transactions can also be invoked programmatically by means of the ABAP
statements CALL TRANSACTION and LEAVE TO TRANSACTION.

The term "transaction" must not be misunderstood here; in the context just described, a
transaction simply means calling and executing an ABAP program. In application

30


programming, "transaction" often refers to an indivisible operation on data, which is
either committed as a whole or undone (rolled back) as a whole. This concept exists in
SAP and is called as a LUW (Logical Unit of Work). In the course of one transaction
(program execution), there can be different LUWs. Transaction for ABAP Workbench
could be invoked using transaction code SE80 to work on all ABAP related activities

4.2 CODING

Code to declaring KNA1 internal tables

TYPES: BEGIN OF TY_KNA1,
select TYPE c,
KUNNR LIKE KNA1-KUNNR,
LAND1 LIKE KNA1-LAND1,
NAME1 LIKE KNA1-NAME1,
PSTLZ LIKE KNA1-PSTLZ, "PIN CODE
STRAS LIKE KNA1-STRAS, "HOSE NO
TELF1 LIKE KNA1-TELF1, "telephone number
TELFX LIKE KNA1-TELFX, "FAX NUMBER
line_color(4) type c,
END OF TY_KNA1.
TYPES: TT_KNA1 TYPE STANDARD TABLE OF TY_KNA1.
DATA: GS_KNA1 TYPE TY_KNA1,
GT_KNA1 TYPE TT_KNA1.
.

Table 4.2.1 code to declaring KNA1internal table

31


Code to declaring EVENT and FIELDCATLOG internal table

DATA: IT_EVENTS TYPE SLIS_T_EVENT, "EVENTS TABLE
WA_EVENTS TYPE SLIS_ALV_EVENT,
IT_FIELDCAT TYPE SLIS_T_FIELDCAT_ALV,
WA_LAYOUT TYPE SLIS_LAYOUT_ALV,
LIST_LAYOUT TYPE SLIS_LAYOUT_ALV,
GS_KEYINFO TYPE SLIS_KEYINFO_ALV,
GT_FIELDCAT TYPE SLIS_T_FIELDCAT_ALV,
GS_FIELDCAT TYPE SLIS_FIELDCAT_ALV.

Table 4.2.2 code to declaring EVENT and FIELDCATLOG internal table

Code to declaring EKKO internal table

TYPES: BEGIN OF ty_EKKO,
select TYPE c,
EBELN LIKE EKKO-EBELN,
AEDAT LIKE EKKO-AEDAT,
BUKRS LIKE EKKO-BUKRS,
BSART LIKE EKKO-BSART,
LIFNR LIKE EKKO-LIFNR,
END OF ty_EKKO.
TYPES: TT_EKKO TYPE STANDARD TABLE OF TY_EKKO.
DATA: GS_EKKO TYPE TY_EKKO,
GT_EKKO TYPE TT_EKKO.

Table 4.2.3 code to declaring EKKO internal table
32


Code to declaring EKKO internal table

TYPES: BEGIN OF TY_EKPO,
select TYPE c,
EBELN LIKE EKPO-EBELN,
EBELP LIKE EKPO-EBELP,
MATNR LIKE EKPO-MATNR,
MENGE LIKE EKPO-MENGE,
MEINS LIKE EKPO-MEINS,
NETPR LIKE EKPO-NETPR,
BUKRS LIKE EKPO-BUKRS,
END OF TY_EKPO.

TYPES: TT_EKPO TYPE STANDARD TABLE OF TY_EKPO.
DATA: GS_EKPO TYPE TY_EKPO,
GT_EKPO TYPE TT_EKPO.

Table 4.2.4 Code to declaring EKPO internal table

33


Query to database to retrieve EKKO table

SELECT EBELN
AEDAT
BUKRS
BSART
LIFNR
INTO CORRESPONDING FIELDS OF TABLE GT_EKKO
FROM EKKO WHERE EBELN IN EBELNS.
*color the rows
LOOP AT GT_EKKO INTO GS_EKKO.
LD_COLOR = LD_COLOR + 1.
IF LD_COLOR = 8.
LD_COLOR = 1.
ENDIF.
CONCATENATE 'C' LD_COLOR '10' INTO GS_EKKO-LINE_COLOR.
MODIFY GT_EKKO FROM GS_EKKO.
ENDLOOP.

Table 4.2.5 Query to database to retrieve EKKO table

34


Code for ‘ACCOUNT’ user command


IF GS_EKKO-SELECT EQ 'X'.

GS_EKKO_OUT-EBELN = GS_EKKO-EBELN.
GS_EKKO_OUT-AEDAT = GS_EKKO-AEDAT.
GS_EKKO_OUT-BUKRS = GS_EKKO-BUKRS.
GS_EKKO_OUT-BSART = GS_EKKO-BSART.
GS_EKKO_OUT-LIFNR = GS_EKKO-LIFNR.
APPEND GS_EKKO_OUT TO GT_EKKO_OUT.

ENDIF.

ENDLOOP.

SELECT * FROM LFA1
INTO CORRESPONDING FIELDS OF TABLE GT_LFA1
FOR ALL ENTRIES IN GT_EKKO_OUT
WHERE LIFNR EQ GT_EKKO_OUT-LIFNR.
PERFORM DIS.

Table 4.2.6 code for ‘ACCOUNT’ user command

35


Code for ‘PONO’ user command


ENDIF.

ENDLOOP.

SELECT EBELN EBELP MATNR MENGE MEINS NETPR BUKRS
FROM EKPO INTO CORRESPONDING FIELDS OF TABLE
GT_EKPO FOR ALL ENTRIES IN GT_EKKO_OUT
WHERE EBELN EQ GT_EKKO_OUT-EBELN.

LOOP AT GT_EKPO INTO GS_EKPO.
IF LD_COLOR = 8.
LD_COLOR = 1.
ENDIF.
CONCATENATE 'C' LD_COLOR '10' INTO GS_EKPO-LINE_COLOR.
MODIFY GT_EKPO FROM GS_EKPO.
ENDLOOP.
PERFORM BUILD_FIELDCATLOG_EKPO.
PERFORM DISPLAY_EXPO.
Table 4.2.7 code for ‘PONO’ user command

36


Code for ‘DISPLAY’ user command




ENDIF.

ENDLOOP.

CALL FUNCTION 'REUSE_ALV_GRID_DISPLAY'
EXPORTING
I_CALLBACK_PROGRAM = SY-CPROG
I_CALLBACK_USER_COMMAND = 'VALIDATE_COMMAND'
IS_LAYOUT = WA_LAYOUT
IT_FIELDCAT = GT_FIELDCAT[]
IT_EVENTS = IT_EVENTS
TABLES
T_OUTTAB = GT_EKKO_OUT

Table 4.2.7 code for ‘DISPLAY’ user command

37


Code for ‘COMPANY’ user command

ENDIF.
ENDLOOP.

SELECT BUKRS KUNAG FROM VBRK INTO TABLE GT_VBRK FOR
ALL ENTRIES IN GT_EKKO_OUT WHERE BUKRS = GT_EKKO_OUT-
BUKRS.
SELECT KUNNR LAND1 NAME1 PSTLZ STRAS TELF1 INTO
CORRESPONDING FIELDS OF TABLE GT_KNA1 FROM KNA1 FOR ALL
ENTRIES IN GT_VBRK WHERE KUNNR = GT_VBRK-KUNAG.

LOOP AT GT_KNA1 INTO GS_KNA1.
IF LD_COLOR = 8.
LD_COLOR = 1.
ENDIF.
CONCATENATE 'C' LD_COLOR '10' INTO GS_KNA1-LINE_COLOR.
MODIFY GT_KNA1 FROM GS_KNA1.
ENDLOOP.
PERFORM BUILD_FIELDCATLOG_KNA1.
PERFORM DISPLAY_KNA1.
Table 4.2.7 code for ‘COMPANY’ user command

38


Code for mouse click navigation

FIELD = RS_SELFIELD-FIELDNAME.

IF FIELD = 'LIFNR'.

READ TABLE GT_EKKO INTO GS_EKKO INDEX RS_SELFIELD-
TABINDEX.
SELECT * FROM LFA1 INTO CORRESPONDING FIELDS OF TABLE
GT_LFA1 WHERE LIFNR = GS_EKKO-LIFNR.
PERFORM FILL_EVENTS_ACCOUNT.
PERFORM DIS.

ELSEIF FIELD = 'EBELN'.

READ TABLE GT_EKKO INTO GS_EKKO INDEX RS_SELFIELD-
TABINDEX.
SELECT EBELN EBELP MATNR MENGE MEINS NETPR BUKRS FROM
EKPO INTO CORRESPONDING FIELDS OF TABLE GT_EKPO WHERE
EBELN = GS_EKKO-EBELN.
PERFORM BUILD_FIELDCATLOG_EKPO.
PERFORM FILL_EVENTS_VENDOR.
PERFORM DISPLAY_EXPO.

ELSEIF FIELD = 'BUKRS'.

READ TABLE GT_EKPO INTO GS_EKPO INDEX RS_SELFIELD-
TABINDEX.
SELECT BUKRS KUNAG FROM VBRK INTO TABLE GT_VBRK
WHERE BUKRS = GS_EKPO-BUKRS.
SELECT KUNNR LAND1 NAME1 PSTLZ STRAS TELF1 INTO

39


CORRESPONDING FIELDS OF TABLE GT_KNA1 FROM KNA1 FOR
ALL ENTRIES IN GT_VBRK WHERE KUNNR = GT_VBRK-KUNAG.
PERFORM BUILD_FIELDCATLOG_KNA1.
PERFORM FILL_EVENTS_COMPANY.
PERFORM DISPLAY_KNA1.
LOOP AT GT_KNA1 INTO GS_KNA1.
IF LD_COLOR = 8.
LD_COLOR = 1.
ENDIF.
CONCATENATE 'C' LD_COLOR '10' INTO GS_KNA1-LINE_COLOR.
MODIFY GT_KNA1 FROM GS_KNA1.
ENDLOOP.
ENDIF.
Table 4.2.7 code for mouse click navigation

Code for multiple selections

FORM BULID_LAYOUT.

WA_LAYOUT-BOX_FIELDNAME = 'SELECT'.
WA_LAYOUT-COLWIDTH_OPTIMIZE = 'X'.
WA_LAYOUT-NO_INPUT = 'X'.
WA_LAYOUT-TOTALS_TEXT = 'TOTALS'(201).
WA_LAYOUT-INFO_FIELDNAME = 'LINE_COLOR'.

ENDFORM.

Table 4.2.7 code for multiple selections

40


Code for passing FIELDCATLOG

FORM BUILD_FIELDCATLOG.
CLEAR GS_FIELDCAT.

GS_FIELDCAT-TABNAME = 'GT_EKKO'.
GS_FIELDCAT-FIELDNAME = 'EBELN'.
GS_FIELDCAT-SELTEXT_M = 'PO NO'.
GS_FIELDCAT-HOTSPOT = 'X'.
APPEND GS_FIELDCAT TO GT_FIELDCAT.
CLEAR GS_FIELDCAT.

GS_FIELDCAT-FIELDNAME = 'AEDAT'.
GS_FIELDCAT-SELTEXT_M = 'DATE'.
CLEAR GS_FIELDCAT.

GS_FIELDCAT-FIELDNAME = 'BUKRS'.
GS_FIELDCAT-SELTEXT_M = 'COMPANY CODE'.
CLEAR GS_FIELDCAT.

GS_FIELDCAT-FIELDNAME = 'BSART'.
GS_FIELDCAT-SELTEXT_M = 'DOCMENT TYPE'.
CLEAR GS_FIELDCAT.

41


GS_FIELDCAT-FIELDNAME = 'LIFNR'.
GS_FIELDCAT-SELTEXT_M = 'VENDOR AC NO'.
CLEAR GS_FIELDCAT.

ENDFORM. "BUILD_FIELDCATLOG
Table 4.2.7 code for passing FIELDCATLOG

Code for filling EVENTS

FORM FILL_EVENTS_COMPANY.

CLEAR IT_EVENTS.
CLEAR WA_EVENTS.
WA_EVENTS-NAME = 'TOP_OF_PAGE'.
WA_EVENTS-FORM = 'PRINT_HEADING_COMPANY'.
APPEND WA_EVENTS TO IT_EVENTS.
* PF-STATUS_SET
CLEAR WA_EVENTS.
WA_EVENTS-NAME = 'PF_STATUS_SET'.
WA_EVENTS-FORM = 'ATTATCH_STATUS_COMPANY'.
APPEND WA_EVENTS TO IT_EVENTS.

ENDFORM. "FILL_EVENTS_COMPANY
Table 4.2.7 code for filling EVENTS

42


Code for selection screen & Include

INCLUDE ZINCLUDE.

DATA EBL TYPE EBELN.
SELECT-OPTIONS EBELNS FOR EBL.
INITIALIZATION.
EBELNS-LOW = 3000000000.
EBELNS-HIGH = 5000000000.
EBELNS-OPTION = 'BT'.
EBELNS-SIGN = 'I'.

APPEND EBELNS.

START-OF-SELECTION.

PERFORM BULID_LAYOUT.
PERFORM BUILD_FIELDCATLOG.
PERFORM FILL_EVENTS_TABLE.

END-OF-SELECTION.

PERFORM READ_DATA_FROM_EKKO.
PERFORM DISPLAY_DTA_USING_ALV.

Table 4.2.7 code for selection screen & Include

43


Fig 4.2.1 screen to add buttons

44


Fig 4.2.2 screen to add function to buttons

45


Fig 4.2.2 screen to create short cut keys to buttons

46

Vendor Reports Testing

TESTING

Software testing is a critical element of software quality assurance and
represents the ultimate review of specification, design and coding. Testing is the exposure of
the system to trial input to see whether it produces correct output.

5.1 Levels of Testing

• Unit Testing:
Unit testing is essentially for the verification of the code produced during the
coding phase and the goal is test the internal logic of the module/program. In the Generic
code project, the unit testing is done during coding phase of data entry forms whether the
functions are working properly or not. In this phase all the drivers are tested they are rightly
connected or not.

• Integration Testing:
All the tested modules are combined into sub systems, which are then tested.
The goal is to see if the modules are properly integrated, and the emphasis being on the
testing interfaces between the modules. In the generic code integration testing is done mainly
on table creation module and insertion module.

• System Testing:
It is mainly used if the software meets its requirements. The reference
document for this process is the requirement document.

Acceptance Testing:

It is performed with realistic data of the client to demonstrate that the software
is working satisfactorily. In the Generic code project testing is done to check whether the
Creation of tables and respected data entry was working successfully or not.

47


Testing Methodologies:

Testing is a process of executing a program to find out errors. If testing is
conducted successfully, it will uncover all the errors in the software. Any testing can be done
basing on two ways:

• White Box Testing:
It is a test case design method that uses the control structures of the
procedural design to derive test cases. Using this testing a software Engineer can derive the
following test cases: Exercise all the logical decisions on either true or false sides. Execute
all loops at their boundaries and within their operational boundaries. Exercise the internal
data structures to assure their validity.

• Black Box Testing:
It is a test case design method used on the functional requirements of the
software. Black Box testing attempts to find errors in the following categories:

o Incorrect or missing functions
o Interface errors
o Errors in data structures
o Performance errors
o Initialization and termination errors

• Test Approach:

Testing can be done in two ways:

o Bottom up approach
o Top down approach

48


• Bottom up approach:

Testing can be performed starting from smallest and lowest level modules and
proceeding one at a time. For each module in bottom up testing a short program executes the
module and provides the needed data so that the module is asked to perform the way it will
when embedded within the larger system..

• Top down approach:

This type of testing starts from upper level modules. Since the detailed
activities usually performed in the lower level routines are not provided stubs are written. A
stub is a module shell called by upper level module and that when reached properly will
return a message to the calling module indicating that proper interaction occurred.

5.2 Test table

Object details
RICEWAMU ID
Description

Technical Specification Name Testing
Object Type Report
Object Name Zvendor_report
SAP/Custom Transaction Code Z
Developer Name

49


Test Script(s)

Step Test Test Inputs Expected Result Actual Result Pass/Fail
Description (Attach Screenshot) (Attach screenshot) (Attach screenshot)
1 One Company Company code 1014 Compare the Pass
code period 10, fiscal balances with FBL3N
year 2011 as balances
selection criteria

2 Multiple Company code 1014 Compare the Pass
Company to AR01 with period balances with FBL3N
Codes 10, fiscal year 2011 balances
as selection criteria

Sign-Off
Date

Signed By

50


5.3 Screen Shots

Fig 5.3.1 Selection screen

51


Fig 5.3.2 vendor detail in alv

52


Fig 5.3.3 detail view of single record

53


Fig 5.3.4 sorting screen to sort rows

54


Fig 5.2.5. filtering screen to filter the data

55


Fig 5.3.6 filtering step 2nd screen to filter the data

56


Fig 5.3.7 help screen for filter

57


Fig 5.3.8 screen to select file format

58


Fig 5.3.8 screen to select downloading path

59


Fig 5.3.10 screen to select for print preview

60


Fig 5.3.12 screen to mail up

61


Fig 5.3.13 screen to change layout

62


Fig 5.3.14 screen to change settings of layout

63


Fig 5.3.15 screen performed addition operation

64


Fig 5.3.16 screen performed addition operation based on line no

65


Fig 5.3.17 screen displays graph

66


Fig 5.3.16 screen for scale settings

67


Fig 5.3.18 screen performs Analysis

68


Fig 5.3.19 output txt file
69


Fig 5.3.20 output excel sheet file

70

Conclusions & Enhancements

Here we can conclude that this report displays Vendor details for the given supplier
code, factory code and shipment date. The report is displayed in the ALV format. Here user
can specify the above selection criteria i.e. supplier code, factor code and shipment code. The
download path is specified for the user to download the vendor details. User can specify
whether to download or to view the details. The download path is specified for the user to
download the vendor details, not only the download path but also the format of the file like
word document, excel document, text document, pdf or mail it up.

Here we had limited this project to use the data which is already predefined or which
is updated by the Administrator (BASIS Administrator), but by enhancing this project we can
provide the facility of uploading our own files of data, so that we can update it directly to the
database from non-SAP format to SAP format.

By enhancing this project we can also schedule different programs (parts of project)
to get executed at regular interval of time. This scheduled process can also be called as the
automated process.

BIBLIOGRAPHY

Good Teachers are worth more than thousand books, we have them in Our Department

REFERENCES
BOOKS
ABAP Basics Authors Günther Färber and Julia Kirchnes 2nd edition.

WEB
[1] For SAP Portal
http://www.sap.com

[2] SAP Help Portal

http://help.sap.com/

[3] ABAP Development discussions, blogs, documents and videos on the SAP Community
Network (SCN)

http://scn.sap.com/community/abap

http://scn.sap.com/welcome

[4] ABAP Objects

http://help.sap.com/saphelp_nw2004s/helpdata/en/ce/b518b6513611d194a50000e8353423/fra
meset.htm

[5] ABAP at the Open Directory Project

http://en.wikipedia.org/wiki/ABAP

http://en.wikipedia.org/wiki/ABAP#SAP_Basis

http://www.sts.tu-harburg.de/teaching/sap_r3/ABAP4/abapindx.htm

Document

Recommended

Recommended

More Related Content

What's hot

What's hot (18)

Viewers also liked

Viewers also liked (20)

Similar to Document

Similar to Document (20)

Recently uploaded

Recently uploaded (20)

Document