Document

Vendor Report Introduction

1

AVANTHI INSTITUTE OF ENGINEERING & TECHNOLOGY

Department Of Information Technology

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


2



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


3



<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


4



Error Handling/Reprocessing Method

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

Post Execution Notification Details

Did the batch job trigger as scheduled? If not, send an email notification.

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


5



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


6



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.


7



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.


8



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).


9



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


10



Microsoft Windows releases versions

Release Release

date End of life Features

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

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

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

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

3.0 – – Table control introduced; icons added to buttons

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

4.0 – – Screens contain more information to reduce navigation

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

4.6D July 2000

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

6.10 July 2001

– –


11



6.20 March 2002

– –

6.40 June 2004

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

7.10 February

2007 12/04/2011

Support for Microsoft Vista and Office 2007; new "Tweak SAP GUI" tool; new ABAP front-end editor

7.20 April 2010

-

Support for Windows XP; Windows 2003 Server; Windows Vista; Windows 2008 Server; Windows 7 and 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


12



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


13



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


14



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,


15



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


16



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.


17



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.


18



� 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.

Vendor Report Requirement Software Specifications

19



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.


20



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


21



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


22





23




Vendor Report Design

24



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:


25



� 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.


26



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


27



Selection criteria

Field

Description

Technical Name Data Type

(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.


28



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


29




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

Vendor Report Implementation

30



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


31



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


32



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


33



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


34



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


35



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


36



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


37



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


38



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


39



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


40



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


41



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.


42




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


43



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


44



Fig 4.2.1 screen to add buttons


45



Fig 4.2.2 screen to add function to buttons


46



Fig 4.2.2 screen to create short cut keys to buttons

Vendor Reports Testing

47



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.


48



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


49



• 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


50



Test Script(s)

Step Test

Description

Test Inputs

(Attach Screenshot)

Expected Result

(Attach screenshot)

Actual Result

(Attach screenshot)

Pass/Fail

1 One Company

code

Company code 1014

period 10, fiscal

year 2011 as

selection criteria

Compare the

balances with FBL3N

balances

Pass

2 Multiple

Company

Codes

Company code 1014

to AR01 with period

10, fiscal year 2011

as selection criteria

Compare the

balances with FBL3N

balances

Pass

Sign-Off

Date

Signed By


51



5.3 Screen Shots

Fig 5.3.1 Selection screen


52



Fig 5.3.2 vendor detail in alv


53



Fig 5.3.3 detail view of single record


54



Fig 5.3.4 sorting screen to sort rows


55



Fig 5.2.5. filtering screen to filter the data


56



Fig 5.3.6 filtering step 2nd screen to filter the data


57



Fig 5.3.7 help screen for filter


58



Fig 5.3.8 screen to select file format


59



Fig 5.3.8 screen to select downloading path


60



Fig 5.3.10 screen to select for print preview


61



Fig 5.3.12 screen to mail up


62



Fig 5.3.13 screen to change layout


63



Fig 5.3.14 screen to change settings of layout


64



Fig 5.3.15 screen performed addition operation


65



Fig 5.3.16 screen performed addition operation based on line no


66



Fig 5.3.17 screen displays graph


67



Fig 5.3.16 screen for scale settings


68



Fig 5.3.18 screen performs Analysis


69



Fig 5.3.19 output txt file


70



Fig 5.3.20 output excel sheet file

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