E-Transaction

The E-Transaction Interface is the designed targeted at the future banking solution for the users who is having multiple bank accounts at the multiple banks. This interface integrates all existing banks and provides business solutions for both retail and corporate.

          This system acts as a standard interface between the clients and all the banks that register with the system and clients who maintains accounts in various banks don’t have to visit individual bank’s website to make money transactions instead he can directly log on to E-Transaction Interface and make any kind of request and get his work fulfilled and in the backend the system will take care of all the obligation required in order to carry on transaction smoothly

                          The main Vision of this project is to eliminate all the diversities amongst banks, which generally client faces at the time of any transaction. By doing so Client will used to only one Systematic Standard way of banking and there by they will be at ease using this interface.

              The kind of functionality it’s capable of providing also reveals the kind of banking facilities that a customer could get online. Of course, the bank that implements this solution decides the features available to customers.                     

Modules

1) Banker Module

This module deals with the Accounts Pending, Pending Transfers, and Reports regarding transactions.

2) Customer Module

This module a customer can register him self to the system, customer can login into the system. A customer can add a new account, view the account information, Transfer amount, A customer can also see the Transaction Reports.

3) Admin Module

The admin module will be used by the administrator of the site, The admin can accept or reject the request from the banker, and The admin can accept or reject the request from the user. The request are in the form of bank registration, customer registration.

Existing System:

Lets consider a condition when a bank customer is having bank accounts in more than one bank. The online banking system available at present is bank specific. Each bank is having its own interface to interact with the bank. A customer can login to the bank and make the transactions using the online banking provided by the bank. The way he interacts with different banks varies. The user must learn how to interact with each system.

DRAWBACKS OF EXISTING SYSTEM

A user requires accessing the system on the fly. The user interfaces designed by the different banks will confuse the user. He requires to learn how to use each and every user interface of the bank in which he is having accounts. This process may be time consuming and too irritating for the user also. When he transfers the accounts, He may probably prone to click the different action when shifting from one bank user interface to other.

Proposed System and its features:

The e-Transaction Interface provides the following system features.

1.      This system provides a Common User Interface for the customers to log on to any bank.

2.      Here the user interface is Graphical User Interface.

3.      This application is a Web based Application.

4.      Being a web based application it doesn’t require any client side installation.

5.      Any number of users can interact with the system simultaneously.

6.      Eradicates the time consumed to learn how to use all the user interfaces of every bank in which a customer is having account.

The transactions are secure

Number of Modules:

1) Admin Module

Only an Administrator can have access to this module, He must accept or reject the Banker who registered with the system. He performs the counter check on the banker who applied for registration with the system. He must also authorize the pending user requests also. If a user or banker registers with the system the administrator must authorize the user or banker to register with the system. Finally it calls the sign out button, which will take the administrator to the home page. The module will update the database after the administrator has authorized or declined the user requests.

2) Banker Module

Through this module the banker can accept the request for registering the account of a user with the system. And a banker can accept or decline any transaction from the user. If a user requires to transfer some amount to any other account. The user request was first sent to the banker. The banker verifies the request and then accepts or declines the transaction. If he accepts the transaction then the transfer of funds starts. If he clicks on decline then the request was rejected and notified to the user. In this module some special care should be taken after the baker accepts the request. The transaction must be obeying the ACID properties. All the commands in the transaction must be executed successfully else the entire process must be rolled back.

3) Customer Module

To become a customer to the system. The person must register with the system first. By clicking on the sign in a person can have access to the application form, which consists of the details about the person. Then the request is sent to the administrator. After the administrator accepted the request from the customer, The customer can login to this account. Then after logging in with the user name and password given by the administrator. The system verifies the username and password with the database stored and then it gives the access to the customer login page. The customer login page consists of select account; create a new account, back and home page buttons. If a user requires to register a new bank account. He clicks the new account and fills the particulars and click on submit button. The request was sent to the specified bank admin for acceptance. After acceptance the user can use the bank account for the funds transfer. The funds transfer screen displays the current account balance in the bank and amount to be transferred and the target account to which the funds to be transferred. The request is sent to the banker for verification and acceptance. The funds are successfully transferred if the banker accepts. The customer can also see the pending transfers. The present status of the transfer from his login.

HARDWARE AND SOFTWARE REQUIREMENTS

HARDWARE REQUIREMENTS                              

PROCESSOR    :  Intel 2.0 GHz or above

HARD DISK     :  80 GB

RAM                 :    512 MB RAM.

   SOFTWARE REQUIREMENTS

OPERATING SYSTEM                     : WINDOWS XP with SP2. 

LANGUAGE (FRONT END)   : JAVA (JDK1.5/1.6)

SERVER                                     : APACHE TOMCAT 5.5/6.0

WEB TECHNOLOGY              : HTML, JAVASCRIPT, CSS.

DATABASE (BACK END)        : ORACLE 10G.

ARCHITECTURE                      : 3-TIER ARCHITECTURE.

E-Shopping Management

Abstract:

 This project is developed for the automation process of  shopping through online i.e through web. In merchant  module adding the catogories,products,itemSales, giving orders, Stock maintenace , creating invoice(bill) for orders, shipping of items order given by customer. creation,  details , and other transactions like automatic increment,decrement of stock, paid invoice(amount),shipping invoice and all other transactions for large scale  whole sale or retail sales, very big shops, or organizations.

This project mainly contains 3 modules like Merchant module, Customer module, invoice module.

In customer module customers will give orders for items  which are being available in that shop. In our project that order is processed and details are stored in data  base. In invoice module total bill for ordered items will be created. In case if the ordered items are not being shipped at a time then the pending order details will be processed and the bill for the pending order will be created. In Marchant Module  products are being maintained in category wise and product wise, item wise and up to date stock will be maintained in computerized manner. And up to date order given by the customer through online web status will be shown with help of dynamic web pages by getting data from database.

EXISTING SYSTEM

In existing system every thing is manual like customer will go to shop manually and he/she selects items which are available in shop and the marchant will calculate the bill for products selected by the customer and then shipping process will take place.

Existing System is manual,every thing we have to do manuwally

i.e      displaying items

2.selecting items

3.billing process

4.shipping

Problems in present system

1. Could not synchronize the Outward information to shopping order details.
2. No track of the complaints and replaced goods after ordering
3. Order status is updated manually using Order Confirmation.
4. Very high levels of effort for preparing invoices and dispatch related documents and routing them to relevant departments or locations and high levels of clerical activity on account of applicability of different customers and products.
5. Increased levels of expectation from customers with respect to prompt delivery of items.
6. Inability to accurately judge changing patterns of fast and slow moving items on account of large volumes of data, and inability to track goods in transit.
7. Difficulties in handling customer queries pertaining to consignments in-transit and partial dispatches.
8. Important orders not discriminated from others since all orders since all orders were processed on a FIFO basis-hence need to be able to prioritize and process orders on a preferential basis (for high value orders or important customers), if required.
9. Increase in frequency of goods returned on account of damage leading to high stock levels of damaged goods in the factory.
10. Discrepancy between ordered and invoiced quantities on account of either partial availability of stocks or clerical oversights.
11. Insufficient checks in the current system for ensuring customer credit limits are not exceeded.
12. Sales data not analyzed properly to streamline production volumes. This is primarily on account of varying sales patterns across the year and high volumes of transaction.
13. Customers could communicate to the Sales people but no information is kept in track for future references.
14. Marchant or Management couldn’t not have any information regarding latest sales reports unless requested and taken it for Spreadsheet applications.

Merchant or Management requires the Quality information updates against the complaints and quality measures and metrics, which the current system couldn’t provide such facilities.

 

            The end user of this product is a departmental store where the application is hosted on the web and administrator maintains database.This application  which is deployed at the departmental store will automate the following process.

1.     the customer details are appended to the customer database.

2.     The details of the items are brought forward from the database for customer’s view based on the selection through the menu.

3.     Database of all the products are products are updated at the end of the each transaction.

1.MODULE

Merchant Module

Merchant will enter into the next form by entering username,password in this login page,after entering into  next page marchant  will add new products, categories, different different items what are all the items available in that store,and if he wants he will modify the things,he will delete things

And maintains everything by date wise.

(i.e) 1.Enhancing stores

        2.update stores

        3.delete from stores

Software and Hardware Requirements

            The following software and hardware are recommended for the company.

Hardware Requirements:

Processor            :                  Pentium

Speed                  :                 233 MHz

Monitor               :                  samtron

HardDisk            :                  4.2 GB

RAM                   :                  128 MB

            Software Requirements:

Operating            :               SystemWindows NT

Language             :               JAVA (JSP, JDBC).JDK 1.4

Backend              :               ORACLE

forestry managment ....

ABSTRACT

Iggesund Paperboard is one of the largest manufacturers of virgin fibre paperboard in Europe. The UK based operation is centred at a medium sized paper mill based at Workington in Cumbria. A key part of the Workington plants success is that it maintains and manages its own forests in Dumfries and Galloway, Perthshire and the Highlands. However, Iggesund only use the top two thirds of the Douglas fir and the Scots Pines which are grown in its Scottish forests. The remaining third is used to produce timber that is sold to local and national companies for use in construction and carpentry. It is this particular aspect of the company’s business process on which I would like to concentrate.

Each forest has its own manager who is responsible for the timber sales operation. For several years the managers of the forests have been wishing to upgrade their paper based filing system to a computerized system. This system is outlined below. Unfortunately, due to staff shortages in the company I.T. department they have been unable to find the time to develop a new system. Regrettably, the forestry manager’s budget is limited and he cannot afford to purchase an off-the-shelf package.

After brief discussions with a member of the I.T. department, and with the manager of the Forest of Ae (near Dumfries) I decided that I would to like to try and implement a system that would help the manager of the Forest of Ae keep track of his customers, contracts, orders, products and haulers. Due to the recent staff cut backs and existing projects the I.T. department have been unable to offer me any type of support or spend anytime with me to develop the system. However, they agreed it might be beneficial for me to develop a prototype system that then could be modified by them to suit the specific needs of the forest manager in the future.

The forestry manager only has basic I.T. knowledge as the company offers no formal I.T. training, but regularly uses a company laptop for word processing. He also has access to the company intranet, email system and the internet over a secure ISDN connection and he is familiar with online form systems used for ordering over the internet. He currently uses a paper based filing system to look after customer details, orders, contracts, product and hauler information. This system has become increasingly difficult to maintain, and become a burden on the manager’s time.

The Forest of Ae is over two hours drive from the Workington based I.T. department. It would be impractical to expect the forestry manager to maintain his own databases, as supporting users at this distance is a tricky business for the company I.T. department. Therefore, it was suggested by a member of the I.T. department that it would be sensible for the database to be located centrally, and maintained by the I.T. department.

 Modules

This section describes the current procedures that are followed by the forestry manager in the current system. Detailed understanding of these procedures was gained through several telephone conversations during September 2002.

Product Details

The forestry manager is provided with a given amount of timber each week from the logging contractors who work in conjunction with the manager. The majority of this timber is then transported to the Workington based plant for use in paperboard production. However, for some reason, the base of the tree is not appropriate of virgin fibre paperboard. The unwanted sections are transferred the forestry manager’s lumber yard, and this is the product which can then be sold on to wood mills, construction companies or carpenters. Product differentiation is relatively low, and at any one time, it is unlikely that there will be more than 6 different products in the yard. These products are usually given a product code, based on tree type, the age of the wood, and the geometry of the timber. The forestry manager currently maintains a word processed list of the products which is updated to add new products, or remove discontinued products. Sometimes, a product description is added to this word processed list to distinguish between similar products. Furthermore, there is always enough timber in the yard to meet customer demand, as the significantly more lumber is required for the paper making business.

Customer Details

The forestry manager has around 20 customers who he supplies regularly. Due to the nature of the business, he does not receive many new customers, but relies on the business of his existing customers. A paper file is created for the customer, recording their name and contact details and it is filed alphabetically by customer name. To locate a customer file, the right drawer in the filing cabinet must be searched. What’s more, if amendments need to be made to a particular customer’s details then he usually must fill in a fresh form. Obviously this is a time consuming process.

Contract Details

The forestry manager has contracts with the majority of his customers. That is, he provides them with either a weekly or monthly delivery of a fixed amount of timber on a given day of the week or date in a month. He receives correspondence regarding new contracts by telephone, or by fax. Occasionally he receives written correspondence, and some of his customers now place contracts by email. These contracts are then recorded on a standard contract form and then filed against appropriate day of the week for weekly contracts, or against the appropriate date if it is a monthly contract. In order to fulfil these contracts, the forestry manager has to search through his filing cabinets to locate the contracts due. When contracts are completed, they are removed from the filing system and discarded.

 Order Details

Orders are one off transactions, and are not repeated. They are requested by customers, usually in addition to contracts, to be delivered on a given date. Orders are placed using the same channels as the weekly and monthly contracts. They are recorded on a paper form and sorted by delivery date. If amendments need to be made a new order form must be filed out, and if the order is cancelled or completed the form is discarded.

Hauler Details

The forestry manager uses local haulers to delivery the lumber to his customers. Due to the nature of the business, haulers are highly specialized, and given the limited demand for transporting large amounts of timber it is unlikely that the forestry manager is likely to use any new haulers. In September 2002, the forestry manager was only using three different haulage companies to transport his goods. Consequently, their details are well known and only recorded on a notice board in his office.

Hardware

• Intel Pentium® 4 processor
• 1 GB Memory
• And other regular hardware devices

Software

• Microsoft Windows XP, 2000® Server

·         IBM Web Sphere Studio Application Developer 6.0

• MS SQL Server 2000