SUMMARY OF THE PROJECT OBJECTIVE The sole purpose of this software module P2C 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. 2. 3. 4. 5. 6. 7. 8. 9. Order Received From Customer Order entry into the system by Central Order Processing Group (COPG) Order verification in terms of commercial terms by COPG Order cleared by COPG Scheduling of order by Production Planning Group (PPC ) Shipment of material by Shipment Department (SD) Invoice Generation / Printing by Accounts Department (AD) Machine installation by Installation Group (NIG) Payment received by Commercial Department (CD)

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

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 & supportinfrastructure. 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.

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

The TIME magazine has referred to HCL as an "intellectual clean room where its employees could imagine endless possibilities."

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 of Logical 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-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 most recent development platform, Net Weaver, supports both ABAP and Java.

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.

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 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), which is responsible for concurrency control (e.g. preventing two developers from changing the same code at the same time), version management and deployment of programs on the QA and production systems. The Web Application Server consists 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.

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 of Work). 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 Editor tools for for creating and and editing Repository objects are: code. ABAP writing editing program

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

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

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 report program 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 drilldown 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

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, for example 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

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. Types are 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 objects are 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 a search 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

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 about table 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

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

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 dialogdriven 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

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. 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. This screen sequence can be either linear or cyclic. Main Components of a Dialog Program

17

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 (PBOProcess before Output) and after receiving the entries the user made on the screen (PAIProcess 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

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 (PBOProcess before Output) and after receiving the entries the user made on the screen (PAIProcess 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

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

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

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

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

ACRONYMS AND ABBREVIATIONS 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 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

24

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 CPU Speed Processor Memory/RAM: Display Properties Screen Resolution SPECIFICATION 1.0 GHz recommended or higher Pentium III or above 1GB minimum,2GB recommended or higher Greater than 256 color depth 1024x768 recommended or higher at Normal Size (96dpi)
25

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 Operating System Development Platform Database

DETAILS Microsoft Windows XP2 or higher SAP 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

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 is being 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 USERNAME(PK) PASSWORD Data Type CHAR CHAR Size 50 50 Description Username of the Operator. Password of the Operator.

27

2) Customer_master (Customer Details Table) Column Name Cust_initial(PK) Cust_slno(PK) Cust_name Cust_add1 Cust_add2 Cust_add3 Cust_pincode Cust_city Contact_person_name Contact_person_number State_code(PK,FK) Data Type Char Num Char Char Char Char Char Char Char Char Char Size 1 6 40 40 40 40 10 20 40 20 2 Description Customer initial Code Customer Code Customer Name Customer 1st Address Customer 2nd Address Customer 3st Address Pin code Number City Name Name of Other Contact Person Number of Contact person State Code

3) State_master Column Name State_code(PK) State_Description Data Type Char Char Size 2 40 Description State Code State Name

4) Material_master (Material master) Column Name Material_code(PK) Material_description Shipping_plant Material_price Data Type Char Char Char Number Size 10 100 4 11 Description Material Code Material Description Code of Shipping Plant Material price

5) Plant_master (Plant Master) Column Name plant_name(PK) plant_add1 plant_add2 plant_add3 plant_pincode
28

Data Type Char Char Char Char Char

Size 40 40 40 40 10

Description plant Name Plant 1st Address Plant 2nd Address Plant 3st Address Pin code Number

plant_city

Char

20

City Name

6) Status_master (Order Status Master) Column Name Order_status(PK) Description Data Type Char Char Size 4 40 Description Order Status Abbreviation Order Description

7) Order_detail (Order Detail Information Table) Column Name Order_no(PK,FK) Material_code(PK,FK) Item_qty(PK) Item_value Data Type Int Char Int Int Size 8 10 6 11 Description Order number Material code Item quantity Item value

8) Order_header (Order Header Information Table) Column Name Order_no(PK) Order_creation_date Order_status(FK) Customer_ref_no Customer_ref_date Order_value Material_ref_date Customer_initial(FK) Customer_slno Delivary_challan_no(PK) Shipment_date
29

Data Type Int Dats Char Char Dats Int Dats Char Int Int Dats

Size 8 8 4 40 8 11 8 1 6 8 8

Description Order Number Order creation date Order status Customer Reference Number Customer Reference Date Order amount Material required date Customer initial Code Customer code Delivery challan number Shipment Date

Invoice_number Invoice_date Transporter_name Plant_code(FK) Machine_installed_by Cheque_no Bank_name

Int Dats Char Char Char Char Char

8 8 40 4 40 15 15

Invoice Number Invoice Date Transporter Name Plant Code Installation Engineer Name Cheque number Bank name

9) Item Stock Master (stock_master) Column Name Material_code(PK,FK) Plant_code(PK,FK) Stock_qty(PK) Data Type Char Char Int Size 10 4 6 Description Material Code Plant_Code Stock_qty

10) Order_tracking (Order Status Tracking Table) Column Name Order_no(PK,FK) Order_status(PK,FK) Order_crea_date(PK) Data Type Int Char Dats Size 8 4 8 Description Order number Order status Order creation date

30

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

33

SHIPMENT DEPARTMENT SCREEN:

34

35

ACCOUNT SCREEN

36

MACHINE INSTALLATION SCREEN:

37

PAYMENT RECEVING SCREEN

38

ALV REPORTS:
39

ORDER ANALYSIS REPORTS:

40

PAYMENT BALANCE REPORT:

41

The Total amounts of all the Order Values are shown.

42

INVOICE GENERATION THROGH SMARTFORMS AND SAPSCRIPTS

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

43

Invoice Generated Page 1

44

Invoice Generated Page 2

45

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 a customer 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 3rd 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

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

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 of Conceptual Data Model or Semantic Data Model. Information Engineering Style of Representing Cardinality

48

E-R Diagram

49

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 contextlevel 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

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

LEVEL 1 DATA FLOW DIAGRAM:

52

LEVEL 2 DATA FLOW DIAGRAMS:

1. ORDER ENTRY SCREEN:

53

2. SHIPMENT SCREEN:

54

3. INVOICE GENERATION SCREEN:

55

56

4. MACHINE INSTALLATION SCREEN:

57

5. PAYMENT RECEIVED SCREEN:

58

WORK PROGRAM
1st Month
59

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 Month After 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

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

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 functions appear to be working according that software 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

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 according to specifications is, internal operations are performed 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 Message window saying Please enter the username/ password Message window saying Wrong username/ password Takes user to Correspondin g Page Actual Output Message window saying Please enter the username/ password Message window saying Wrong username/ password Takes user to Corresponding Page Result

Login 1

User forgets to enter the username / password User enters wrong username/ password User enters correct username/ password

PASS

PASS

PASS

63

Case no. 2

Scenario

Sr.no

Action

Expected Output Message window saying Customer Does not exist

Actual Output Message window saying Customer Does not exist Message window saying Name Should Not be null Message window saying Invalid code Message window saying Invalid code Error is shown Values Dont Match

Result

Placing Order

User enters wrong customer code

PASS

User does not enters Some record e.g. name

Order Quotation and Total Value does not match

Message window saying Name Should Not be null User Enters Message wrong window plant code saying Invalid code Users Message Enters window wrong saying material Invalid Code code User enter Error is the shown Quotation Values and Dont Material Match

PASS

PASS

PASS

PASS

64

Case no. 3

Scenari o Shipping Screen

Sr.no A

Action User enter wrong Order Number User does not enter Transporter Name

Expected Output Error is Shown that Order Num does not Exist. Error is shown :Enter Transporter Name Expected Output Error is Shown that Order Num does not Exist. Error is shown :Del Challan Number Does not Exist

Actual Outpu t Error is Shown that Order Num does not Exist. Error is shown :Enter Transporter Name Actual Outpu t Error is Shown that Order Num does not Exist. Error is shown :Del Challan Number Does not Exist

Result PASS

PASS

Case no. 4

Scenario Accounts Department Screen

Sr.no A

Action User enter wrong Order Number User does enter wrong Delivery Challan Number Name

Result PASS

PASS

65

Case no. 5

Scenario Machine Installation Screen

Sr.no A

Action User enter wrong Order Number

Expected Output

Error is Shown that Order Num does not Exist. User does Error is enter shown :Del wrong Challan Delivery Number Challan Does not Number Exist Name User does Error is not enter shown Customer :Enter Engineer Customer Name Engineer Name

Actual Outpu t Error is Shown that Order Num does not Exist. Error is shown :Del Challan Number Does not Exist Error is shown :Enter Customer Engineer Name

Result PASS

PASS

PASS

Case no. 6

Scenario Commercial Department Screen

Sr.no A

Action User enter wrong Order Number

Expected Output Error is Shown that Order Num does not Exist.

Actual Outpu t Error is Shown that Order Num does not Exist.

Result PASS

66

Snapshots showing Error Messages: Enter Order Number and Total Value and Order Value do not match.

67

ABAP DEBUGGER

68

Conclusion

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 of time 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 whenever required and at the same time assist its user. record of orders and payment

69

Future

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.

70