Himanshu Report

7/30/2019 Himanshu Report

1/70

SUMMARY OF THE PROJECT

OBJECTIVE

The sole purpose of this software moduleP2C Process Implementation is a platform where

the employees enter the order details of the customers which they receive in the form of a

purchase order and the whole transaction is managed till the payment is received from the

customer. This is an integrated module comprising of Sales Distribution (SD), Material

Management (MM), Production Planning (PP), Logistics, Finance (FI) modules of SAP. The

various groups and departments handle the order at various stages. All the functionality is

supported by database, thus making the whole system reliable.

It support for inventory management helps you record and track materials on the basis of both

quantity and value. It improves cash flow, visibility, and decision making.

For warehouse management, you can track quantity and value of all your materials, perform

physical inventory, and optimize your warehouse resources

FLOW OF PROCESS:

1. Order Received From Customer

2. Order entry into the system by Central Order Processing Group (COPG)

3. Order verification in terms of commercial terms by COPG

4. Order cleared by COPG

5. Scheduling of order by Production Planning Group (PPC )

6. Shipment of material by Shipment Department (SD)

7. Invoice Generation / Printing by Accounts Department (AD)

8. Machine installation by Installation Group (NIG)

9. Payment received by Commercial Department (CD)

1


2/70

Result

Project is in progressive mode with every aspect of coding and connectivity with thedatabase

We have tried to present simple and comprehensive user interface.

2


3/70

COMPANY PROFILE

HCL Infosystems Ltd is one of the pioneers in the Indian IT market, with its origins in 1976. For

over quarter of a century, we have developed and implemented solutions for multiple market

segments, across a range of technologies in India. We have been in the forefront in introducing

new technologies and solutions. HCL is a leading global Technology and IT Enterprise with

annual revenues of US$ 5 billion. The HCL Enterprise comprises two companies listed in India,

HCL Technologies ( www.hcltech.com ) and HCL Infosystems (www.hclinfosystems.in).

The 3 decade old enterprise, founded in 1976, is one of India's original IT garage startups. Its

range of offerings span R&D and Technology Services, Enterprise and Applications Consulting,

Remote Infrastructure Management, BPO services, IT Hardware, Systems Integration and

Distribution of Technology and Telecom products in India. The HCL team comprises 60,000

professionals of diverse nationalities, operating across 23 countries including 500 points of

presence in India. HCL has global partnerships with several leading Fortune 1000 firms,

including several IT and Technology majors. The highlights of the HCL saga are summarized

below:

Annual Review

HCL Infosystems (HCLI) draws its strength from 30 years of experience in handling the

ever changing IT scenario , strong customer relationships , ability to provide the cutting

edge technology at best-value-for-money and on top of it, an excellent service & support-

infrastructure.

Today HCL is country's premier information enabling company. It offers one-stop-shop

convenience to its diverse customers having an equally diverse set of requirements. Be it a

large multi-location enterprise, or a small/medium enterprise, or a small office or a home,

HCLI has a product range, sales & support capability to service the needs of the customer.

Last 30 years apart from knowledge & experience have also given us continuity in

relationship with the customers, thereby increasing the customer confidence in us.

3
http://www.hclinfosystems.in/http://www.hclinfosystems.in/


4/70

Awards

Corporate Awards

India's Most Preferred Personal Computer Brand by CNBC AWAAZ Consumer Award

2007.

India's 'No. 1 PC Vendor' consecutively for six years.

HCL among the Top 3 IT companies for the last 3 years, DQ & IDC, Best Employer Survey,

' Best employer 2005' with Five Star Ratings

'Top 50 in ET Top 500 Companies' Listings for 2006

Top 21 companies in Business Standard 1000 Ranking 2006

Top 50 Fastest Growing Technology Companies in India & 'Top 500 Fastest Growing

Technology Companies in Asia Pacific' by 'Deloitte & Touch

'The Most Responsive Company 2005' - IT Hardware Category by The Economic Times -

Avaya Global Connect

'7th IETE - Corporate Award 2005' for performance excellence in the field of Computer &

Telecommunications Systems

Global Recognition

Cover story on HCL in Forbes Asia in June 2007

'The world's most modern management " with reference to Employee First

HCL Technologies ranks 76 in the list of Fastest Growing Global Technology

Companies

Case study on HCL is now taught at Harvard.

The case study focuses on HCL's unique transformation over the last 2 years, and

highlights HCL's Employee First philosophy.

4
http://www.hcl.in/files/Business_Legend_Shiv_Nadar_Moneycontrol.pdfhttp://www.hcl.in/files/Business_Legend_Shiv_Nadar_Moneycontrol.pdfhttp://www.hcl.in/files/Business_Legend_Shiv_Nadar_Moneycontrol.pdfhttp://www.hcl.in/files/Business_Legend_Shiv_Nadar_Moneycontrol.pdf


5/70

The TIME magazine has referred to HCL as an "intellectual clean room where its

employees could imagine endless possibilities."

5


6/70

INTRODUCTION TO DEVELOPMENT ENVIRONMENT

INTRODUCTION

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. ABAP was one of the first languages to include the concept ofLogical Databases (LDBs), which provides a high level of abstraction from the basic database

level.

The ABAP programming language was originally used by developers to develop the SAP R/3

platform. It was also intended to be used by SAP customers to enhance SAP applications

customers can develop custom reports and interfaces with ABAP programming. The language is

fairly easy to learn for programmers but it is not a tool for direct use by non-programmers. Good

programming skills, including knowledge of relational database design and preferably also of

object-oriented concepts are required to create ABAP programs.

ABAP remains the language for creating programs for the client-serverR/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 most recent development platform,Net Weaver, supports both ABAP and Java.

6
http://en.wikipedia.org/wiki/Fourth-generation_programming_languagehttp://en.wikipedia.org/wiki/SAP_R/2http://en.wikipedia.org/wiki/SAP_R/3http://en.wikipedia.org/wiki/SAP_R/3http://en.wikipedia.org/wiki/NetWeaverhttp://en.wikipedia.org/wiki/Java_(programming_language)http://en.wikipedia.org/wiki/Fourth-generation_programming_languagehttp://en.wikipedia.org/wiki/SAP_R/2http://en.wikipedia.org/wiki/SAP_R/3http://en.wikipedia.org/wiki/SAP_R/3http://en.wikipedia.org/wiki/NetWeaverhttp://en.wikipedia.org/wiki/Java_(programming_language)


7/70

Where does the ABAP program run?

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 byte code. 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). 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 frequently accessed data in

the local memory of the application server.

SAP has three different layers as presentation layer (GUI), application layer (programs run on

this) and data base layer where all data is stored and retrieved from user driven conditions,

commands given by end user programmer through presentation layer.

SAP Basis

The ABAP language environment, including the syntax checking, code generation and runtime

system, is part of the SAP Basis component. 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 "operating system"

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 executable

("SAP kernel") running directly on the underlying operating system, transactions developed in

ABAP, or Web-based interfaces.

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.

7
http://en.wikipedia.org/wiki/Java_(Sun)http://en.wikipedia.org/wiki/Kernelhttp://en.wikipedia.org/wiki/GUIhttp://en.wikipedia.org/wiki/SAP_Web_Application_Serverhttp://en.wikipedia.org/wiki/Java_(Sun)http://en.wikipedia.org/wiki/Kernelhttp://en.wikipedia.org/wiki/GUIhttp://en.wikipedia.org/wiki/SAP_Web_Application_Server


8/70

SAP Basis currently runs on UNIX (AIX, HP-UX,Solaris, Linux), Microsoft Windows, i5/OS

on IBM System i (formerly iSeries, AS/400) and z/OS on IBM System z (formerly zSeries,

S/390). Supported databases are DB2, Informix, MaxDB, Oracle and Microsoft SQL Server

(support for Informix was discontinued in SAP Basis release 7.00).

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. An 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 theWeb 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),

which is responsible for concurrency control (e.g. preventing two developers from changing thesame code at the same time), version management and deployment of programs on the QA and

production systems.

The Web Application Serverconsists of three layers: the database layer, the application layer

and the presentation layer. These layers may run on the same or on different physical machines.

The database layer contains the relational database and the database software. The application

layer contains the instance or instances of the system. All application processes, including the

business transactions and the ABAP development, run on the application layer. The presentation

layer handles the interaction with users of the system. Online access to ABAP application

servers can go via a proprietary graphical interface, the SAPGUI, or via a Web browser.

8
http://en.wikipedia.org/wiki/UNIXhttp://en.wikipedia.org/wiki/IBM_AIX_(operating_system)http://en.wikipedia.org/wiki/HP-UXhttp://en.wikipedia.org/wiki/Solaris_(operating_system)http://en.wikipedia.org/wiki/Solaris_(operating_system)http://en.wikipedia.org/wiki/Linuxhttp://en.wikipedia.org/wiki/Microsoft_Windowshttp://en.wikipedia.org/wiki/I5/OShttp://en.wikipedia.org/wiki/System_ihttp://en.wikipedia.org/wiki/Z/OShttp://en.wikipedia.org/wiki/System_zhttp://en.wikipedia.org/wiki/DB2http://en.wikipedia.org/wiki/Informixhttp://en.wikipedia.org/wiki/MaxDBhttp://en.wikipedia.org/wiki/MaxDBhttp://en.wikipedia.org/wiki/Oracle_databasehttp://en.wikipedia.org/wiki/Oracle_databasehttp://en.wikipedia.org/wiki/Microsoft_SQL_Serverhttp://en.wikipedia.org/wiki/SAP_Web_Application_Serverhttp://en.wikipedia.org/wiki/SAP_Web_Application_Serverhttp://en.wikipedia.org/wiki/SAP_Web_Application_Serverhttp://en.wikipedia.org/wiki/SAP_Web_Application_Serverhttp://en.wikipedia.org/wiki/UNIXhttp://en.wikipedia.org/wiki/IBM_AIX_(operating_system)http://en.wikipedia.org/wiki/HP-UXhttp://en.wikipedia.org/wiki/Solaris_(operating_system)http://en.wikipedia.org/wiki/Linuxhttp://en.wikipedia.org/wiki/Microsoft_Windowshttp://en.wikipedia.org/wiki/I5/OShttp://en.wikipedia.org/wiki/System_ihttp://en.wikipedia.org/wiki/Z/OShttp://en.wikipedia.org/wiki/System_zhttp://en.wikipedia.org/wiki/DB2http://en.wikipedia.org/wiki/Informixhttp://en.wikipedia.org/wiki/MaxDBhttp://en.wikipedia.org/wiki/Oracle_databasehttp://en.wikipedia.org/wiki/Microsoft_SQL_Serverhttp://en.wikipedia.org/wiki/SAP_Web_Application_Serverhttp://en.wikipedia.org/wiki/SAP_Web_Application_Server


9/70

Transactions

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, SE80 is the code

for the ABAP workbench). Transactions can be accessed via system-defined or user-specific,

role-based menus. They can also be started by entering their transaction code (a mnemonic name

of up to 20 characters) in the special 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. Transaction codes can also be linked to

screen elements or menu entries. Selecting such an element will start the 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 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 but is there called a LUW (Logical Unit ofWork). In the course of one transaction (program execution), there can be different LUWs.

The different kind of transactions:

Dialog transaction

Parameter transaction

Variant transaction

Report transaction

Object Oriented transaction

ABAP workbench

The ABAP Workbench contains different tools for editing Repository objects. These tools

provide you with a wide range of assistance that covers the entire software development cycle.

The most important tools for creating and editing Repository objects are:

ABAP Editor for writing and editing program code.

ABAP Dictionary for processing database table definitions and retrieving global types

Menu Painter for designing the user interface (menu bar, standard toolbar, application toolbar,

Screen Painter for designing screens (dynamic programs) for user dialogs.

Function Builder for displaying and processing function modules (routines with defined

9


10/70

interfaces that are available throughout the system).

Class Builder for displaying and processing ABAP Objects classes.

The ABAP dictionary

The ABAP Dictionary is a fully integrated data environment controlling facility. It contains all

definitions for Domains, Data Elements, Structures, Tables, Views, Search Helps, Lock Objects,

Match code Objects, The Table Maintenance Generator, and the Table Description Generator.

With these objects in its repository, the ABAP Dictionary:

Enforces data integrity

Manages data definitions without redundancy

Is tightly integrated with the rest of the ABAP/4 Development Workbench.

Enforcing data integrity is the process of ensuring that data entered into the system is logical,

complete, and consistent. When data integrity rules are defined in the ABAP/4 Dictionary, the

system automatically prevents the entry of invalid data. Defining the data integrity rules at the

dictionary level means they only have to be defined once, rather than in each program that

accesses that data.

The following are examples of data lacking integrity:

A date field with a month value of 13

An order assigned to a customer number that doesnt exist

An order not assigned to a customer

Managing data definitions without redundancy is the process of linking similar information to

the same data definition. For example, a customer database is likely to contain a customers ID

number in several places. The ABAP Dictionary provides the capability of defining the

characteristics of a customer ID number in only one place. That central definition then can be

used for each instance of a customer ID number.

The ABAP Dictionarys integration with the rest of the development environment enables

ABAP programs to automatically recognize the names and characteristics of dictionary objects.

10


11/70

Additionally, the system provides easy navigation between development objects and dictionary

definitions. For example, as a programmer, you can double-click on the name of a dictionary

object in your program code, and the system will take you directly to the definition of that object

in the ABAP/4 Dictionary.

When a dictionary object is changed, a program that references the changed object will

automatically reference the new version the next time the program runs. Because ABAP is

interpreted, it is not necessary to recompile programs that reference changed dictionary objects.

Unique concept of internal table in ABAP

Internal tables provide a means of taking data from a fixed structure and storing it in working

memory in ABAP. The data is stored line by line in memory, and each line has the same

structure. In ABAP, internal tables fulfill the function of arrays. Since they are dynamic data

objects, the programmer is saved the task of dynamic memory management in his or her

programs. Internal tables should be used whenever there is a need to process a dataset with a

fixed structure within a program. A particularly important use for internal tables is for storing

and formatting data from a database table within a program. They are also a good way of

including very complicated data structures in an ABAP program.

Types of ABAP programs

In ABAP, there are two different types of programs:

Report programs

Report programs 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 output from the reportprogram is interactive because it is not a passive display; instead it enables the user, through

ABAP language constructs, to obtain a more detailed view on specific data records via drill-

down functions, or to invoke further processing through menu commands, for instance to sort

the data in a different way or to filter the data according to selection criteria

11


12/70

Online programs

Online programs (also called module pools) do not produce lists. These programs define more

complex patterns of user interaction using a collection of screens. The term screen refers to

the actual, physical image that the users see. Each screen also has flow logic; this refers to the

ABAP code invoked by the screens, i.e. the logic that initializes screens, responds to a users

requests and controls the sequence between the screens of a module pool. 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.

Online programs are not invoked directly by their name, but are associated with a transaction

code. Users can then invoke them through customizable, role-dependent, transaction menus.

Apart from reports and online programs, it is also possible to develop sharable code units such

as class libraries, function libraries and subroutine pools.

ABAP Dictionary

Purpose

Data definitions (metadata) are created and managed in the ABAP Dictionary. The ABAP

Dictionary permits a central description of all the data used in the system without redundancies.

New or modified information is automatically provided for all the system components. This

ensures data integrity, data consistency and data security.

You can create the corresponding objects (tables or views) in the underlying relational database

using these data definitions. The ABAP Dictionary therefore describes the logical structure of

the objects used in application development and shows how they are mapped to the underlying

relational database in tables or views.

The ABAP Dictionary also provides standard functions for editing fields on the screen, forexample for assigning a screen field an input help.

What Information is Stored in the ABAP Dictionary?

The most important object types in the ABAP Dictionary are tables, views, types, domains,

search helps and lock objects.

12


13/70

Tables are defined in the ABAP Dictionary independently of the database. A table having the

same structure is then created from this table definition in the underlying database.

Views are logical views on more than one table. The structure of the view is defined in the

ABAP Dictionary. A view on the database can then be created from this structure.

Typesare used in ABAP programs. The structure of a type can be defined globally in ABAP

programs. Changes to a type automatically take effect in all the programs using the type.

Lock objectsare used to synchronize access to the same data by more than one user. Function

modules that can be used in application programs are generated from the definition of a lock

object in the ABAP Dictionary.

Different fields having the same technical type can be combined in domains. A domain defines

the value range of all table fields and structure components that refer to this domain.

The ABAP Dictionary also contains the information displayed with the F1 and F4 help for a

field in an input template. The documentation about the field is created for a data element that

describes the meaning of the contents of a table field. The list of possible input values that

appears for the input help is created by a foreign key or asearch help.

Integration in the ABAP Workbench

The ABAP Dictionary is completely integrated in the ABAP Workbench. The SAP System

works interpretatively, permitting the ABAP Dictionary to be actively integrated in the

development environment. Instead of the original objects, the interpreters see only internal

representations of these objects.

These internal representations are adjusted automatically when the system finds that changes

have been made in the ABAP Dictionary. This ensures that the screen and ABAP interpreters,

input help, database interface, and development tools always access current data.

The following ABAP program lists the airline carriers (see Flight model) and carrier IDs

contained in table SCARR.

DATA: SCARR_TAB TYPE SCARR.

SELECT * INTO SCARR_TAB FROM SCARR.

WRITE: / SCARR_TAB-CARRID, SCARR_TAB-CARRNAME.

ENDSELECT.

Only structure SCARR_TAB is declared in the program. All the information about this

structure, such as the field names, data types and field lengths, are copied from table SCARR,

13
http://help.sap.com/saphelp_nw04/helpdata/en/cf/21ea43446011d189700000e8322d00/content.htmhttp://help.sap.com/saphelp_nw04/helpdata/en/cf/21ec5d446011d189700000e8322d00/content.htmhttp://help.sap.com/saphelp_nw04/helpdata/en/90/8d72fbb1af11d194f600a0c929b3c3/content.htmhttp://help.sap.com/saphelp_nw04/helpdata/en/cf/21eea5446011d189700000e8322d00/content.htmhttp://help.sap.com/saphelp_nw04/helpdata/en/cf/21eea5446011d189700000e8322d00/content.htmhttp://help.sap.com/saphelp_nw04/helpdata/en/cf/21ede5446011d189700000e8322d00/content.htmhttp://help.sap.com/saphelp_nw04/helpdata/en/cf/21ede5446011d189700000e8322d00/content.htmhttp://help.sap.com/saphelp_nw04/helpdata/en/90/8d72feb1af11d194f600a0c929b3c3/content.htmhttp://help.sap.com/saphelp_nw04/helpdata/en/90/8d72feb1af11d194f600a0c929b3c3/content.htmhttp://help.sap.com/saphelp_nw04/helpdata/en/cf/21ea77446011d189700000e8322d00/content.htmhttp://help.sap.com/saphelp_nw04/helpdata/en/cf/21ee2b446011d189700000e8322d00/content.htmhttp://help.sap.com/saphelp_nw04/helpdata/en/cf/21ee2b446011d189700000e8322d00/content.htmhttp://help.sap.com/saphelp_nw04/helpdata/en/cf/21f304446011d189700000e8322d00/content.htmhttp://help.sap.com/saphelp_nw04/helpdata/en/cf/21ea43446011d189700000e8322d00/content.htmhttp://help.sap.com/saphelp_nw04/helpdata/en/cf/21ec5d446011d189700000e8322d00/content.htmhttp://help.sap.com/saphelp_nw04/helpdata/en/90/8d72fbb1af11d194f600a0c929b3c3/content.htmhttp://help.sap.com/saphelp_nw04/helpdata/en/cf/21eea5446011d189700000e8322d00/content.htmhttp://help.sap.com/saphelp_nw04/helpdata/en/cf/21ede5446011d189700000e8322d00/content.htmhttp://help.sap.com/saphelp_nw04/helpdata/en/90/8d72feb1af11d194f600a0c929b3c3/content.htmhttp://help.sap.com/saphelp_nw04/helpdata/en/cf/21ea77446011d189700000e8322d00/content.htmhttp://help.sap.com/saphelp_nw04/helpdata/en/cf/21ee2b446011d189700000e8322d00/content.htmhttp://help.sap.com/saphelp_nw04/helpdata/en/cf/21f304446011d189700000e8322d00/content.htm


14/70

which is defined in the ABAP Dictionary. This information about table SCARR is called from

the ABAP Dictionary when the program is generated.

This means that the source text of the program need not be adjusted when a change is made to

table SCARR, for example when the length of a table field is changed. The next time the

program is called, the system automatically determines that the structure of table SCARR has

changed. The program is simply regenerated, thereby retrieving up-to-date information abouttable SCARR from the ABAP Dictionary.

When you work on development projects, objects of the ABAP Dictionary can be changed any

number of times before being activated and made available to the operative components of the

system. Objects can have both an active and an inactive version in the ABAP Dictionary at the

same time.

Inactive ABAP Dictionary objects have no effect on the runtime system (ABAP processor,

database interface). This permits greater changes to several objects without impairing the

executability of the system. The objects can only be activated together when they have all been

changed.

Using the ALV Grid in SAP Reports

14
http://help.sap.com/saphelp_nw04/helpdata/en/cf/21f1fe446011d189700000e8322d00/content.htmhttp://help.sap.com/saphelp_nw04/helpdata/en/cf/21f1fe446011d189700000e8322d00/content.htm


15/70

After a report has been generated, there are many options available for customizing the data

within the ALV grid. The sections below give more information for using the available options.

Modifying Columns

There are many options for manually modifying columns, including resizing, moving, freezing,

sorting, hiding, and calculating.

Resize Columns

To resize a column, place your cursor over the line between column headers. When it turns into

a cross, click and drag the edge of the column.

Move Columns

To move a column, click the column header once to select it. Then click and drag the column

header to a new location.

Freeze Columns

To freeze a column, right-click the column header and select Freeze to Column. The column

will not move when you scroll.

To unfreeze the column, right-click the column header and select Unfreeze Columns.

Sort Columns

To sort a column, select a column header then click the appropriate sort icon. The icon sorts a

column in ascending order. The icon sorts a column in descending order.

Hide Columns

To hide a column, right-click the column header and select Hide.Calculate Columns

If a column is totaled, the mean, minimum, or maximum value can be determined by

following the menu path

Edit > Calculate and then selecting the desired option. The calculated value replaces the

total at the end of the report.

Dialog Programs

Dialog-driven programs, or any program started using a transaction code, are known as SAP

transactions, or just transactions. The term "transaction" is used in several different contexts in

the IT world. In OLTP (Online Transaction Processing), where several users are working in one

15


16/70

system in dialog mode, the term "transaction" stands for a user request. In conjunction with

database updates, it means a change in state in the database.

Programs with type M can only be started using a transaction code, in which an initial screen is

defined. Programs with type 1 can be started either using a transaction code, or by entering the

program name in one of the transactions SE38 or SA38. Screens call dialog modules in the

associated ABAP program from their flow logic. Type M programs serve principally as

containers for dialog modules, and are therefore known as module pools. Type 1 programs, or

function modules can also switch to dialog mode by calling screens using the CALL SCREEN

statement. The program code of the corresponding executable program or function pool must

then contain the corresponding dialog modules. Programs that are partially or wholly dialog-

driven cannot be executed in the background. They are therefore sometimes referred to As

Dialog Programs.

A dialog-driven program consists of the following basic components:

Transaction code

16
http://help.sap.com/saphelp_nw04/helpdata/EN/41/7af4b6a79e11d1950f0000e82de14a/content.htmhttp://help.sap.com/saphelp_nw04/helpdata/EN/41/7af4b6a79e11d1950f0000e82de14a/content.htm


17/70

The transaction code starts a screen sequence. You create transaction codes in the

Repository Browser in the ABAP Workbench or using Transaction SE93. A transaction

code is linked to an ABAP program and an initial screen. As well as using a transaction

code, you can start a screen sequence from any ABAP program using the CALL

SCREEN statement.

Screens

Each dialog in an SAP system is controlled by one or more screens. These screens

consist of a screen mask and its flow logic. Since the flow logic influences the program

flow, screens are sometimes referred to as "dynamic programs". You create screens

using the Screen Painter in the ABAP Workbench. Each screen belongs to an ABAP

program.

The screen has a layout that determines the positions of input/output fields and other

graphical elements such as checkboxes and radio buttons. The flow logic consists of two

parts:

o Process before Output (PBO). This defines the processing that takes place before

the screen is displayed.

o Process after Input (PAI). This defines the processing that takes place after the

user has chosen a function on the screen.

All of the screens that you call within an ABAP program must belong to that program. The

screens belonging to a program are numbered. For each screen, the system stores the number of

the screen which is normally displayed next. Thisscreen sequence can be either linear or cyclic.

Main Components of a Dialog Program

17
http://help.sap.com/saphelp_nw04/helpdata/EN/e4/2adbef449911d1949c0000e8353423/content.htmhttp://help.sap.com/saphelp_nw04/helpdata/EN/9f/dbab0235c111d1829f0000e829fbfe/content.htmhttp://help.sap.com/saphelp_nw04/helpdata/EN/9f/dbab0235c111d1829f0000e829fbfe/content.htmhttp://help.sap.com/saphelp_nw04/helpdata/EN/e4/2adbef449911d1949c0000e8353423/content.htmhttp://help.sap.com/saphelp_nw04/helpdata/EN/9f/dbab0235c111d1829f0000e829fbfe/content.htm


18/70

The Screen Painter and the Menu Painter to create and design screen templates and

screen programs.

The processing logic in an ABAP/4 program (module pool).

Data structures are defined in the ABAP/4 Dictionary. You can access these structures

from the ABAP/4 program and when defining screen fields.

The dialog processor controls the flow of your dialog program.

A dialog program consists of the following basic components:

Screens (dynpro)

Each dialog in an SAP system is controlled by dynpro. A dynpro (Dynamic Program)

consists of a screen and its flow logic and controls exactly one dialog step. The flow

logic determines which processing takes place before displaying the screen (PBO-

Process before Output) and after receiving the entries the user made on the screen (PAI-

Process after Input).

The screen layout fixed in the Screen Painter determines the positions of input/output

fields, text fields, and graphical elements such as radio buttons and checkboxes. In

18


19/70

addition, the Menu Painter allows storing menus, icons, pushbuttons, and function keys

in one or more GUI statuses. Dynpro and GUI statuses refer to the ABAP/4 program that

controls the sequence of the dynpros and GUI statuses at runtime.

ABAP/4 module pool

Each dynpro refers to exactly one ABAP/4 dialog program. Such a dialog program is

also called a module pool, since it consists of interactive modules. The flow logic of a

dynpro contains calls of modules from the corresponding module pool. Interactive

modules called at the PBO event are used to prepare the screen template in accordance to

the context, for example by setting field contents or by suppressing fields from the

display that are not needed. Interactive modules called at the PAI event are used to check

the user input and to trigger appropriate dialog steps, such as the update task.

All dynpro to be called from within one transaction refer to a common module pool. The

dynpros of a module pool are numbered. By default, the system stores for each dynpro

the dynpro to be displayed next. This dynpro sequence or chain can be linear as well as

cyclic. From within a dynpro chain, you can even call another dynpro chain and, after

processing it, return to the original chain.

A dialog program consists of the following basic components

Screens (dynpros)

Each dialog in an SAP system is controlled by dynpros. A dynpro (Dynamic Program)

consists of a screen and its flow logic and controls exactly one dialog step. The flow

logic determines which processing takes place before displaying the screen (PBO-

Process before Output) and after receiving the entries the user made on the screen (PAI-

Process after Input).

The screen layout fixed in the Screen Painter determines the positions of input/output

fields, text fields, and graphical elements such as radio buttons and checkboxes. In

addition, the Menu Painter allows storing menus, icons, pushbuttons, and function keys

in one or more GUI statuses. Dynpros and GUI statuses refer to the ABAP/4 program

that controls the sequence of the dynpros and GUI statuses at runtime.

19


20/70

ABAP/4 module pool

Each dynpro refers to exactly one ABAP/4 dialog program. Such a dialog program is

also called a module pool, since it consists of interactive modules. The flow logic of a

dynpro contains calls of modules from the corresponding module pool. Interactive

modules called at the PBO event are used to prepare the screen template in accordance to

the context, for example by setting field contents or by suppressing fields from the

display that are not needed. Interactive modules called at the PAI event are used to check

the user input and to trigger appropriate dialog steps, such as the update task.

All dynpros to be called from within one transaction refer to a common module pool.

The dynpros of a module pool are numbered. By default, the system stores for each

dynpro the dynpro to be displayed next. This dynpro sequence or chain can be linear as

well as cyclic. From within a dynpro chain, you can even call another dynpro chain and,

after processing it, return to the original chain.

Dynpro

20


21/70

Each screen contains fields used to display or request information. Fields can be text strings,

input or output fields, radio buttons, checkboxes, or pushbuttons. The screen of Transaction

TZ10 contains only texts and input/output fields.

An SAP dynpro consists of several components:

Flow logic: Calls of the ABAP/4 modules for a screen.

Screen layout: Positions of the texts, fields, pushbuttons, and so on for a screen.

Screen attributes: Number of the screen, number of the subsequent screen, and others.

Field attributes: Definition of the attributes of the individual fields on a screen.

You create and edit all components of a dynpro in the Screen Painter. To call the Screen Painter,

create a dynpro in the Object Browser or double-click on an existing dynpro. The Object

Browser then calls the Screen Painter. There, you can enter the flow logic of the new dynpro. By

pressing the corresponding pushbutton you can maintain the Screen attributes, branch to the Full

Screen-Editor or you choose the pushbutton Field list and change the attributes of fields. For

more information on the Screen Painter, see the documentation ABAP/4 Development

Workbench: Tools.

21


22/70

Screen Painter ABAP/4

To create a screen, take the following steps:

1. Define the basic features of a screen (screen attributes)

2. Design the screen layout (in the full screen editor)

3. Define the field attributes (field list)

4. Write the screen flow logic

The most important ABAP/4 program components are found in the following objects:

Global data or Dictionary structures in the TOP include program (data declarations)

PBO (Process Before Output) module

PAI (Process After Input) module

Subroutines (if required)

22


23/70

PROJECT

Problems In existing system

As we know manual system are quite tedious, time consuming and less efficient and accurate in

comparison to the computerized system.

So following are some disadvantages of the old system:

1. Time consuming

2. Less accurate

3. Less efficient

4. Lot of paper work

5. Slow data processing

6. Not user friendly environment

Scope of Proposed System

The scope of this system is to provide user efficient working environment and more output can

be generated through this. This module provides user friendly interface resulting in knowing each

and every usability features of the system.

This system helps in tracking records so that past records can be verified through them and one

can make decisions based on the past records. This system completes the work in a very less

time resulting in less time consumption and high level of efficiency.

This module is developed in such a way that even a nave user can also operate the system

easily. The calculations are made very quickly and the records are directly saved into ABAP

Tables and the databases can be maintained for a longer period of time. Each record can be

retrieved and can be verified for the future transactions.

23


24/70

ACRONYMS AND ABBREVIATIONS

COPG central order processing group

PPG production planning group

SD shipment department

AD accounts department

MIG machine installation group

CG commercial group

BLOC order status, order entry into the system done

REVD order status, order verified by COPG

CLRD - order status, order cleared by COPG

SCHD - order status, order scheduled by PPG

SHIP - order status, order shipped by SD

INVG - order status, invoice generated by AD

MACI - order status, machine installed by MIG

PYMR - order status, payment received from the customer

Description:

The aim of the software is to regulate a smooth transaction from the point the order is booked

into the company records until the payment is collected from the client.

There are 5 departments integrated into this single module:

1) Central Order Processing Group.

2) Shipment Department

3) Invoice Generation

4) Machine Installation

5) Finance and Commercial Module

24


25/70

All these groups have their respective roles and responsibilities to follow. The COPG group

views data which has been ordered and then decides whether to receive it or not. If the order

gets received, the status of the order is changed from BLOC to REVD.

Once the order is cleared by COPG the status is again changed to CLRD.

Similarly, whether to ship or not to ship an order depends on the shipment department. An order

can only be shipped if the stock quantity exists. So once the order is shipped the status is

changed from SCHD to SHIP.

Once shipped, its now time for the invoice generation. Here invoice is generated which

contains the order value and an invoice unique number gets created. This invoice number is

unique and is used to correctly identify the invoice for the respective order. Here the status of

the order gets changed from SHIP to INVG.

After this, once the products and its spare parts have reached a particular destination like an

export processing zone. It is now time for the spare parts to be installed at the clients place.

Once this is done, the status of the order gets changed from INVG to MACI.

So, once the parts have been installed at the client place its high time to collect the payment.

Once the payment is received the status gets changed from MACI to PYMR.

SYSTEM REQUIREMENT

The specific requirements basically mentions the minimum hardware & software requirements

with the help of which the software works.

Minimum Hardware Specification

HARDWARE SPECIFICATION

CPU Speed 1.0 GHz recommended or higher

Processor Pentium III or above

Memory/RAM: 1GB minimum,2GB recommended or higher

Display Properties Greater than 256 color depth

Screen Resolution 1024x768 recommended or higher at Normal

Size (96dpi)

25


26/70

Size of Hard Disk 40GB Minimum

Software Requirements

1. System has SAP GUI installed on it.

2. SAP Framework 7.2 installed on it.

SOFTWARE DETAILS

Operating System Microsoft Windows XP2 or higher

Development Platform SAP

Database ORACLE

User Requirements

FUNCTIONAL REQUIREMENTS

A. PROCESSING

1. The module should automatically generate the bill.

2. The module should inform the pending order and make changes if the order is dispatched.

B. ERROR HANDLING

1. Should report any errors on duplicate primary keys.

2. Should report any Out of Range values on numeric fields

3. Should report any data type mismatches any field on the forms.

4. Should report on any Invalid dates.

5. Should report any violation of authorization of rights.

6. Should report any Invalid Login errors.

26


27/70

Non Functional Requirements

Reliability:

This module is very reliable for both user as well as the developer. System failure is kept

minimum in it and it is taken into consideration that it provides correct output for which it isbeing designed.

Flexibility and Maintainability: This software is flexible i.e. changes can be made

according to user requirement maintaining its verifiability and correctness and

consistency.

DATABASE TABLES USED

Master tables to be created:

1) User Table

Column Name Data Type Size DescriptionUSERNAME(PK) CHAR 50 Username of the Operator.

PASSWORD CHAR 50 Password of the Operator.

27


28/70

2) Customer_master (Customer Details Table)

Column Name Data Type Size Description

Cust_initial(PK) Char 1 Customer initial Code

Cust_slno(PK) Num 6 Customer Code

Cust_name Char 40 Customer Name

Cust_add1 Char 40 Customer 1st Address

Cust_add2 Char 40 Customer 2nd Address

Cust_add3 Char 40 Customer 3st Address

Cust_pincode Char 10 Pin code Number

Cust_city Char 20 City Name

Contact_person_name Char 40 Name of Other Contact Person

Contact_person_number Char 20 Number of Contact person

State_code(PK,FK) Char 2 State Code

3) State_master


State_code(PK) Char 2 State Code

State_Description Char 40 State Name

4) Material_master (Material master)


Material_code(PK) Char 10 Material Code

Material_description Char 100 Material Description

Shipping_plant Char 4 Code of Shipping Plant

Material_price Number 11 Material price

5) Plant_master (Plant Master)


plant_name(PK) Char 40 plant Name

plant_add1 Char 40 Plant 1st Address

plant_add2 Char 40 Plant 2nd Address

plant_add3 Char 40 Plant 3st Address

plant_pincode Char 10 Pin code Number

28


29/70

plant_city Char 20 City Name

6) Status_master (Order Status Master)


Order_status(PK) Char 4 Order Status Abbreviation

Description Char 40 Order Description

7) Order_detail (Order Detail Information Table)


Order_no(PK,FK) Int 8 Order number

Material_code(PK,FK) Char 10 Material code

Item_qty(PK) Int 6 Item quantity

Item_value Int 11 Item value

8) Order_header (Order Header Information Table)


Order_no(PK) Int 8 Order Number

Order_creation_date Dats 8 Order creation date

Order_status(FK) Char 4 Order status

Customer_ref_no Char 40 Customer Reference Number Customer_ref_date Dats 8 Customer Reference Date

Order_value Int 11 Order amount

Material_ref_date Dats 8 Material required date

Customer_initial(FK) Char 1 Customer initial Code

Customer_slno Int 6 Customer code

Delivary_challan_no(PK) Int 8 Delivery challan number

Shipment_date Dats 8 Shipment Date

29


30/70

Invoice_number Int 8 Invoice Number

Invoice_date Dats 8 Invoice Date

Transporter_name Char 40 Transporter Name

Plant_code(FK) Char 4 Plant Code

Machine_installed_by Char 40 Installation Engineer Name

Cheque_no Char 15 Cheque number

Bank_name Char 15 Bank name

9) Item Stock Master (stock_master)


Material_code(PK,FK) Char 10 Material Code

Plant_code(PK,FK) Char 4 Plant_Code

Stock_qty(PK) Int 6 Stock_qty

10) Order_tracking (Order Status Tracking Table)


Order_no(PK,FK) Int 8 Order number

Order_status(PK,FK) Char 4 Order status

Order_crea_date(PK) Dats 8 Order creation date

30


31/70

SCREENSHOTS OF THE PROJECT

MAIN Page:

This is the first Screen that pops up when the user enters the transaction code into the command

Field.It asks for User Authentication

31


32/70

32


33/70

33


34/70

SHIPMENT DEPARTMENT SCREEN:

34


35/70

35


36/70

ACCOUNT SCREEN

36


37/70

MACHINE INSTALLATION SCREEN:

37


38/70

PAYMENT RECEVING SCREEN

38


39/70

ALV REPORTS:

39


40/70

ORDER ANALYSIS REPORTS:

40


41/70

PAYMENT BALANCE REPORT:

41


42/70

The Total amounts of all the Order Values are shown.

42


43/70

INVOICE GENERATION THROGH SMARTFORMS AND SAPSCRIPTS

Driver Program for the Invoice Generation.Its creates Invoice for the corresponding

Order Number.

43


44/70

Invoice Generated Page 1

44


45/70

Invoice Generated Page 2

45


46/70

Snapshots Explanation

Start Up screen

The first item of the module screen is transaction screen

1. The first Screen that pops up is Login Screen.

Order Entry

2. Once the user is logged in, the screen is activated and order no., order creation date and order

status are auto generated by the system. The User cans Click F4 Help to select the Customer

Code. Along with the Customer Code, its relevant details are shown. The user has to select acustomer reference number according to it.

3. Once customer details are entered, the user click Next button .This will display the order

detail screen where order no and the relevant details of the customer such as its name, code,

Address and other details are displays. The user has to enter the Shipping Plant. The F4 help is

also provided for this, which shows all the relevant Plant.

4. The User has to enter the Order Quotation value.

5. Then the user enters the Material Code. He press F4 button on the Table Control, a help pops

up displaying all the Material code, its price and Details. The User has to select an item. The

User then enters the quantity which is internally checked with the database at the runtime only

and the total Price is displayed on the 3 rd Coolum dynamically.

6. The total cost of all the products should match with the order quotation.

7. The order is validated and the user is logged out of the screen.

46


47/70

Shipment Details

8. The shipment details are already auto filled by the system operator has to provide the

transporter name only. He has to select an Order. The User is shown only those orders that have

their status as SHIP. All the rest orders are hidden from the User. The Delivery Challan Number

is auto generated

Accounts Department

8. This Screen consists of only two fields i.e. the Order Number and the Order Delivery Challan

Number. The user selects an order Number of status SHIP available in the list. The Delivery

challan Number is auto populated in the next field.

9. The User is taken to the next screen where all the order details are displayed such as order

number, Invoice value, invoice number is auto generated. After verifying all the details the

employee activates the order and passes this order on the Machine Department.

Machine Installation Department (NIG)

10. Next screen is machining installation here the engineer who going to install the machine is to

be given by the employee. The order Number shown to the User has the Status as INVG only.The employee activates the Order and passes the order to the Commercial Department.

Commercial Group

11. In commercial group screen all the payment details are to be filled accordingly

once customer makes the payment.

12. Thus the records have been created.

47


48/70

DESIGN PHASE

Entity Relationship Diagram (ERD)An Entity Relationship Diagram (ERD) is a snapshot of data structures. ERDs show entities in

a database and relationships between tables within that database. It is essential to have one of

these if you want to create a good database design. The patterns help focus on how the database

actually works with all of the interactions and data flows, although another useful tool is a Data

Flow Diagram (DFD) which more directly describes this.

Entity Relation Model

We use an Entity Relation Model (ERM) to create a data model of a system and its

requirements in a top-down approach. This is frequently the approach utilized in database

design. The diagrams which emerge from this methodology are called ER diagrams.

Structured data is represented by an Entity Relationship Model (ERM). Entity-Relationship

Modeling is the model-generating process. The end-product of the modeling process is an

entity-relationship diagram (ERD) or ER diagram, a type ofConceptual Data Model or

Semantic Data Model.

Information Engineering Style of Representing Cardinality

48


49/70

E-R Diagram

49


50/70

DATA FLOW DIAGRAM

A data flow diagram (DFD) is a graphical representation of the "flow" of data through an

information system. A data flow diagram can also be used for the visualization of data

processing (structured design). It is common practice for a designer to draw a context-level

DFD first which shows the interaction between the system and outside entities. This context-

level DFD is then "exploded" to show more detail of the system being modeled.

The four components of a data flow diagram (DFD) are:

DATA FLOW DIAGRAM NOTATION

External Entities/Terminators are outside of the system being modeled. Terminators

(also referred to as sources or sinks, depending on whether data flows from or into them)

represent where information comes from or where it goes. In designing a system, we have no

idea about what these terminators do or how they do it.

Processes modify the inputs in the process of generating the outputs

Data Stores represent a place in the process where data comes to rest. A DFD does not say

anything about the relative timing of the processes, so a data store might be a place to

accumulate data over a year for the annual accounting process.

50
http://en.wikipedia.org/wiki/Image:DFD_Shapes.png


51/70

Data Flows are how data moves between terminators, processes, and data stores (those that

cross the system boundary are known as IO or Input Output Descriptions)

CONTEXT DIAGRAM:

51


52/70

LEVEL 1 DATA FLOW DIAGRAM:

52


53/70

LEVEL 2 DATA FLOW DIAGRAMS:1. ORDER ENTRY SCREEN:

53


54/70

2. SHIPMENT SCREEN:

54


55/70

3. INVOICE GENERATION SCREEN:

55


56/70

56


57/70

4. MACHINE INSTALLATION SCREEN:

57


58/70

5. PAYMENT RECEIVED SCREEN:

58


59/70

WORK PROGRAM

1st Month

59


60/70

The initial days at the office were mainly used up in adjusting to the new environment of the

Office. We were given sample word Documents and other tutorials for learning / revising our

basic concepts such as encapsulation, object oriented programming etc.

After 15 days or so I was given a login on SAP ECC 6.0.I was told to learn ABAP (Advanced

Business Application Programming) on the Software. I was provided with guidance from the

core MIS Team and several books and tutorial was issued to me.

2nd Month

The first half of the month went for studying and implementing new concepts of ABAP on SAP

many difficulties were faced during the period which took some time to be resolved.

Many new concepts were learnt such as Internal Data Dictionary, Abap Tables, Module Pool

Programming, use of Screen Painter, Selection Screen Programming etc.

3rd Month

In the initial days of the month, the module Implementation of P2C Cycle was allotted. The

same was going to be implemented for the MIS division on the SAP ERP.The user requirement

was explained and then after several discussions and meetings with the core team the

requirements were finalized. The designing of the database tables started towards the end of the

month.

4rd MonthAfter designing of the Database Tables, the analysis of the project was in full force. Several

diagrams were drawn to depict the correct picture such as Sequence Diagram and Activity

Diagram. The Screen Designing also started at the same time using the Screen Painter Software

present in the parent software only. The flow logic was written for the same.

5th Month

60


61/70

The flow logic between the screens was written and completed.ALV (Advanced List Viewer)

was developed for the same module only. Three types of ALV reports were generated for the

analysis of the current sales.

1) Order Booking/Pending Report-This report show all the orders that were booked/Billed

during a specified period.

2) Order Analysis Report: This report shows the details of various orders that were filed during

the period.

3) Payment Balance report: This report shows the payment details for the Orders the Data was

integrated from the Commercial Department.

Various invoice were also created .They were firstly created in SAPSCRIPTS but afterwards,

owing to the requirement of the Division,the same were also build in smart forms.

6th Month:

The module is currently under Testing. The Software team is currently performing testing on it

on the Quality Server.

The module is currently under implementation.

61


62/70

TESTING

Introduction

Testing presents an interesting anomaly for the software engineer. During earlier software

engineering activities, the engineer attempts to build software from an abstract concept to a

tangible product. Now comes testing. The engineer creates a series of test cases that are intended

to demolish the software that has been built. In fact, testing is the one step in the software

process that could be viewed (psychologically, at least) as destructive rather than constructive.

Software engineers are by their nature constructive people. Testing requires that the developer

discard preconceived notions of the correctness of software just developed and overcome a

conflict of interest that occurs when errors are uncovered.

If testing is conducted successfully (according to the objectives stated previously), it will

uncover errors in the software. As a secondary benefit, testing demonstrates that software

functions appear to be working according to specification, that behavioral and

performance requirements appear to have been met. In addition, data collected as testing is

conducted provide a good indication of software reliability and some indication of software

quality as a whole. But testing cannot show the absence of errors and defects, it can show

Only that software errors and defects are present. It is important to keep this (rather gloomy)statement in mind as testing is being conducted.

Testing principles

Before applying methods to design effective test cases, a software engineer must understand the

basic principle that guide software testing:

All tests should be traceable to customer requirements

Tests should be planned long before testing begins

80 percent of all errors uncovered during testing will likely be traceable to 20 percent of all

program components. The problem, of course, is to isolate these suspect components and to

thoroughly test them.

Testing should being in the small and progress toward testing in the Large.

62


63/70

Exhaustive testing is not possible.

To be most effective an independent third party should conduct testing a rich variety of test case

design methods have evolved for software. These methods provide the developer with a

systematic approach to testing. More important, methods provide a mechanism that can help to

ensure the completeness of tests and provide the highest likelihood for uncovering errors in

software.

Any engineered product (and most other things) can be tested in one of

Two ways:

Knowing the specified function that a product has been designed to perform, tests can be

conducted that demonstrate each function is fully operational While at the same time searching

for errors in each function; (2) knowing the internal Working of a product, tests can be

conducted to ensure that all gears mesh, that is, internal operations are performed

according to specifications and all internal components have been adequately exercised. The

first test approach is called black box testing and the second, white-box testing.

Test Cases:

Case

no.

Scenario Sr.no Action Expected

Output

Actual

Output

Result

1Login A User

forgets toenter theusername/password

MessagewindowsayingPlease enterthe username/password

Messagewindowsaying Pleaseenter theusername/password

PASS

B Userenterswrongusername/password

MessagewindowsayingWrongusername/

password

MessagewindowsayingWrongusername/

password

PASS

C Userenterscorrectusername/password

Takes user toCorresponding Page

Takes user toCorrespondingPage

PASS

63


64/70

Case

no.


Output

Actual

Output

Result

2 PlacingOrder

A User enterswrongcustomercode

MessagewindowsayingCustomer

Does notexist

MessagewindowsayingCustomer

Does notexist

PASS

B User doesnot entersSomerecorde.g. name

MessagewindowsayingNameShould Notbe null

MessagewindowsayingNameShould Notbe null

PASS

C User Enterswrong

plant code

Messagewindow

sayingInvalidcode

Messagewindow

sayingInvalidcode

PASS

D UsersEnterswrongmaterialCode

MessagewindowsayingInvalidcode

MessagewindowsayingInvalidcode

PASS

OrderQuotation andTotal Value

does notmatch

E User entertheQuotation

andMaterial

Error isshownValues

DontMatch

Error isshownValues

DontMatch

PASS

64


65/70

Case

no.

Scenari

o

Sr.no Action Expected

Output

Actual

Outpu

t

Result

3 ShippingScreen

A User enterwrongOrderNumber

Error isShown thatOrder Numdoes notExist.


PASS

B User doesnot enter TransporterName

Error isshown:EnterTransporterName

Error isshown:EnterTransporterName

PASS

Case

no.


Output

Actual

Outpu

t

Result

4 AccountsDepartmentScreen

A UserenterwrongOrderNumber



PASS

B User doesenterwrongDeliveryChallanNumber

Name

Error isshown :DelChallanNumberDoes notExist


PASS

65


66/70

Case

no.


Output

Actual

Outpu

t

Result

5 MachineInstallation

Screen

A User enterwrong

OrderNumber

Error isShown that

Order Numdoes notExist.

Error isShown that

Order Numdoes notExist.

PASS

B User doesenterwrongDeliveryChallanNumberName



PASS

C User does

not enterCustomerEngineerName

Error is

shown:EnterCustomerEngineerName

Error is

shown:EnterCustomerEngineerName

PASS

Case

no.


Output

Actual

Outpu

t

Result

6 CommercialDepartmentScreen

A User enterwrongOrderNumber



PASS

66


67/70

67

Snapshots showing Error Messages: Enter Order Number and

Total Value and Order Value do not match.


68/70

ABAP DEBUGGER

68


69/70

Conclusi on

Project is in progressive mode with every aspect of coding and connectivity with the

database

We have tried to present simple and comprehensive user interface. ..

But there are certain features that could have been included but are not due to shortage oftime and is work of future.

The result is a better application which will help in better development of an organization. The

main approach behind our project is that it can easily track record of orders and payment

whenever required and at the same time assist its user.

69


70/70

Fut ure Scope

The scope of the project includes that what all future enhancements can be done in this

system to make it more feasible to use Databases for different products range and storage can

be provided. Multilingual support can be provided so that it can be understandable by the

person of any language. More graphics can be added to make it more user-friendly and

understandable. A ticket System has been proposed to alert the plant manager about the

vanished goods.