WO2000021012A9 - Electronic catalog and shared electronic transaction system - Google Patents

Abstract

An electronic catalog and shared electronic systems (figure 1) which can be accessed over a computer network (figure 1). Various items of the catalog are stored in a database (figure 4) and can be selected by a user in accordance with user determined parameters.

Description

ELECTRONIC CATALOG AND SHARED ELECTRONIC TRANSACTION SYSTEM

PRIORITY TO PRIOR APPLICATION

This application claims priority to Provisional

Application Serial No. 60/102,967 filed October 2, 1998.

BACKGROUND OF THE INVENTION

The present invention generally relates to the field

of electronic databases and, more particularly, is directed

to an electronic catalog and shared electronic transaction

system which enables users of the system to retrieve

requested data conveniently and economically.

The present invention will be described m the context

of a government order processing system, but the novel and

unobvious features of the invention have application in a

wide variety of government and commercial (business- to-

busmess) environments where large amounts of information

must be cataloged and made available to users m an

expeditious manner. The invention is described for its use

on the World Wide Web part of the Internet. It should be

understood, however, that the benefits of the invention may

be realized with any computer network (LAN, etc.) that

supports multiple users. One of the most important requirements of an economy

is to bring buyer's wishing to buy products into contact

with sellers [having products to sell] . In an economy

driven by competition, there are often many competing

products from which a buyer can choose. Moreover, as modern

day communications make the world smaller and greatly

expand market territories, a buyer is often confronted with

a confusing array of considerations when making a

purchasing decision. Price, quality, suitability, and

delivery time are but a few of the many factors a purchaser

must consider when making a purchasing decision. Thus, an

informed purchasing decision often requires the purchaser

evaluate the offerings of several vendors. Doing so can be

time consuming and a busy purchaser may simply opt to make

a purchase without doing any real comparison shopping.

While making purchasing decisions m this manner may not be

detrimental for a small number of purchases, the potential

savings that result from a more careful purchasing

decision can mount substantially when large numbers of

purchases are involved. For example, federal, state and

local governments routinely make purchasing decisions

involving large numbers of items and large sums of money.

The ability to make purchasing decisions quickly while simultaneously ensuring the proper item is purchased at the

lowest cost is critical to maintaining the effectiveness of

a procurement system.

In addition, vendors also require an efficient and

cost- effective way of informing potential customers of

their wares. Traditionally, paper catalogs, advertisements

and personal sales calls have served this purpose. Each of

these methods has its inherent drawbacks. For example,

paper catalogs are expensive to print and distribute and

usually do not remain current for any significant length of

time. Advertising and personal sales calls also are

expensive and tradeoffs must be made over which products

will be promoted to which potential customers.

Accordingly, there is a great need for a system which

can effectively catalog large amounts of information such

as product description, prices and the like, make it

available to those m need of such information m the form

of multiple comparative shopping listings, and allow for

real-time purchase transactions, including credit facility

use, all in a secure electronic environment.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to meet this need, Applicant has invented an

electronic catalog and shared electronic transaction system. The novel features of the invention will be

understood more fully and clearly from the following

description of the invention as set forth m the

accompanying drawings m which:

Figure 1 is an illustration of the system architecture

of the present invention;

Figure 2 is an illustration of a product mapping

process in accordance with the present invention;

Figure 3 s an illustration of a 3 -step catalog search

m accordance with the present invention;

Figure 4 is an illustration of how transactions may be

shared in accordance with the present invention;

Figure 5 is an illustration of a process for printing

completed PDF forms using data entered into HTML forms m

accordance with the present invention; and

Figure 6 is a data flow of the interaction between a

buyer and a seller m accordance with the present

invention.

DESCRIPTION OF THE PREFERRED EMBODIMENT

As mentioned above, the present invention and

processes will be described m the context of a government

order processing system as implemented on the World Wide

Web and will be referred to as an "Electronic Catalog

Service." Figure 1 illustrates the system architecture. The invention and processes can also be applied in the

commercial setting.

Electronic Catalog Service

The Electronic Catalog Service is the common entry

point for all buyers and sellers. The supplier catalogs

with MSRP prices can be searched by anyone. Private

contract catalogs are only searched and used to create RFQs

(Request for Proposal) and purchase orders by authorized

buyers .

The Electronic Catalog Service provides the ability

for a governmental entity to post its term contracts,

schedule contracts, surplus property and other buying

vehicles that are available to multiple buying

jurisdictions, on an on-line, Internet environment.

This selective "electronic catalog" capability also

permits buyers to make their purchase selections on-line,

and have them converted into EDI or FAX purchase/release

orders for transmission to the catalog supplier. The buyer

vehicles are m themselves small "catalogs" that contain

items, part numbers, and previously negotiated or set

prices. These mini contract "catalogs" are maintained in

the private part of the catalog database where buyers can

access them through the Internet. Only those buyers that have the authority to make purchases off of a particular

contract can see items and prices. When a buyer has access

to multiple contracts covering the same products or a buyer

wants to check published MSRP prices from public catalogs,

he or she is able to compare the prices for the different

suppliers and manufacturers of similar items.

The backbone of the catalog holds three major types of

items that make up the products and services that the

buyers buy and the sellers sell, First there are the

generic items -- 175,000 covered by the NIGP 11 digit code

and over 6 million in the Federal Supply Catalog. Second,

each generic item is replicated 5 to 10 times with each

occurrence associated with a different manufacturer's part

number - over 20 million m the Federal Supply Catalog.

Third, these specific items can be replicated 10 to 20

times for the different contracts or catalogs that carry

them. These items carry the additional supplier's stock or

price list number.

Internet technology is rapidly evolving. As it

continues to improve, the catalog w ll become more

graphical and support multimedia presentations that will

surpass the quality of the message that suppliers make now

m their print catalogs. While links are routinely provided to supplier web-sites so that buyers can

investigate a particular product or service, many small

merchants will not want to build their own web site capable

of sending out streaming audio, video and animation feeds.

An integral part of the Electronic Catalog Service is

to work directly with site promotion services to ensure the

maximum and most appropriate visibility of Web site

facilities to Web search engines and other appropriate

points of publicity, including placement of animated "tile"

advertising on appropriate Web pages (e.g., the Netscape

Net Search page) and active promotion of reciprocal

hypertext linking with related Web sites.

Catalog Enhancements

A number of pre-existing databases make the service

offered by the present invention unique and much easier to

find items than services that just load contract items into

a database. Even before any contracts items are loaded

into the database, it is already filled with the following

databases : NIGP Code

The foundation of the procurement catalog data

management system of the present invention is the NIGP

Commodity code. Contract and open market catalog data is

mapped to the NIGP code as the common delineator so

familiar to public sector purchasing agents. The code is

licensed from NIGP.

The NIGP coding scheme provides familiar, visible

classifications that buyers will use to search for items to

purchase. The unique capability of the central catalog is

the neutral link and cross reference that it provides to

other major catalogs. Multi -vendor catalogs such as those

built by Granger, Sweets or Sears as well as those from

single manufacturers like Caterpillar whose catalog, though

proprietary, are completely replicated by independent

catalog companies .

Another enhancement to the catalog is to add tools

that assist the buyer m preparing RFQs for complex

products and services and that assist the seller m working

up their Bids. Using the latest Internet technology, these

tools are being converted into Java applets that run at the user's PC and work on data files linked to the product or

service being solicited.

Trade Services Catalogs

Trade Service Corporation is the recognized leader m

providing Benchmark Pricing to agencies throughout the

United States. As a neutral third party provider of data,

Trade Service gathers information from thousands of

manufacturers throughout the country. This information is

compiled into industry standard databases. The information

is massaged to ensure consistent output, and then

disseminated m multiple formats depending on user

requirements. The information is constantly updated to

reflect the manufacturers' latest suggested resale price,

as well as catalog number, UPC, unit of measure, etc.

Benchmark pricing, and electronic catalogs developed

around live information, generally results m deeper

discounts for agencies. This is due to the varied commodity

structures against which vendors are able to bid. Rather

than provide a single discount for commodities, the vendors

can provide multiple discounts against commodities, sub

commodities, manufacturer lines or single items. Bids can

be received against a fair fixed price for the life of the

contract, or allowed to float as economic changes occur. In this case, the negotiated discount is factored against the

changing list price. The database always remains current

reflecting negotiated contract pricing. Benchmark, or

neutral third party pricing benefits public sector agencies

throughout the solicitation, pre-and post -award processes.

Trade Service databases are used as a benchmark

throughout the bid process. Because the information is

neutral, containing Universal Product Codes (UPC's) and

manufacturer catalog numbers, rather than vendor specific

SKU numbers, all vendors can respond to solicitations with

the assurance that they are bidding against a level playing

field. Vendors provide discounts against the

manufacturer's list price, rather than the vendors' list

price. This streamlines the process for evaluating bids,

comparing responses, and awarding contracts; and ultimately

saves considerable time and taxpayer dollars.

The electronic catalog becomes a powerful tool for

ordering materials and auditing vendor invoices. Because

the database contains UPC's, it reflects the same schema as

vendors' internal systems making ordering consistent.

A central data repository managed by a neutral third

party data provider will improve the purchasing and

materials management functions. Improvements are through the reduction in data errors inherent in manual input,

accessibility to bar code and product identification

information, current contract pricing, and material safety

data sheets. Through the use of industry standard data

that utilizes universal product codes cross referenced to

manufacturer part/stock numbers, the jurisdiction can

expect reduced transaction costs, increased buying power

through aggregated purchasing, and streamlined contracting

processes .

Federal Supply Catalog

This catalog, built and maintained by the Department

of Defense over the last 50 years, provides over 6 million

National Stock Number (NSN) items that have been identified

as having unique form, fit and function and have been

classified by three coding schemes that will link to the

NIGP codes:

Federal Supply Class (FSC)

Federal Item Identification Guide (FUG)

Approved Items Name (AIN)

Once links have been made between the NIGP codes and

the NSNs, other valuable information can be made available,

such as :

Specific Manufacturer Part Numbers Prices for Previously Awarded Contracts

Searchable Technical Characteristics

Excess/Surplus Inventory Items

The service also has the capability for governmental

entities to advertise excess and surplus property on the

Internet. The advertisements are searchable by the NIGP

Code (both class 998 and the class-item for the item when

originally purchased; i.e. 070-06 for automobiles).

Advertising jurisdictions will have several options:

Restrict sale of the item to other units of

government; sale to be by electronic bid with a

specified bid opening date.

Permit the item to be sold to anyone,

including the general public; sale to be by

electronic bid with a specified bid opening date.

Offer the item for sale at a pre-established

price (restricted or unrestricted) .

Agencies are able to advertise upcoming auctions of

excess and surplus property. This information can be made

available on the Internet to the general public who could

search by commodity code or geographic location. Currently there is no established marketplace for

selling excess and surplus property that is unique to

government; such as voting machines, police radios, etc.

This capability provides a low cost method for creating an

electronic marketplace.

Product Mapping Process

Figure 2 illustrates how the product mapping process

occurs m accordance with the present invention. The system

administrator receives computer files from buyers and

vendors. These files contain lists of product names and

contract or manufacturer suggested prices for various

products. The contract prices are usually ones which have

been the subject of negotiation between the buyer and the

vendor and will remain m effect for some period of time.

The manufacturer suggested prices, on the other hand, are

prices which are available to the general public.

In addition to product prices, the computer files may

also contain manufacturer model numbers for each of the

products, products descriptions, the manufacturer's name,

quantity price breaks and may even include a graphical

representation of the product. In essence, the computer

file is an electronic equivalent of a conventional paper

catalog. The computer file, however, can be searched

electronically based on key words and various other search parameters and relationships.

The objective of the mapping process is to take

product catalog information from various buyers and vendors

which is often not consistent between catalogs and map it

to an existing reference catalog of product data (i.e., the

proprietary data structure illustrated m Figure 2) . The

reference catalog is created from a number of sources,

including industry codes such as the National Stock Number

("NSN"), the National Institute of Government Purchases

(NIGP) and the Universal Product Code ("UPC"). These codes

represent classifications for various products and are well

understood by the purchasing industry. A classification for

most products can be found m each of the codes. Many

states and local governments also have product coding

systems which the present invention may use as well.

In mapping the buyer and vendor catalog files, various

key words such as product name and model number are used to

find the proper classification m the reference catalog.

The process is greatly aided if the buyer and/or vendor

catalog files also include an NSN, NIGP or UPC code for

each product. If the buyer and vendor catalog files do not

include such a code, the file may be compared to a stored

database of invoices, purchase orders, bills of lading and the like m search of an NSN, NIGP or UPC code which

matches the product. Such purchasing records are available

from the Federal Government as well as other sources. If an

appropriate classification cannot be determined

automatically, a human operator can make the determination.

Once a classification for the product has been

determined, it is given a new reference code from the

reference catalog. Using the techniques of the present

invention, it has been found that a proper classification

can automatically be determined 85 percent of the time.

Product Catalog Search

Figure 3 is a flow chart of a 3 -step catalog search m

accordance with the present invention. For example, if an

end-user wishes to retrieve information on a particular

product, appropriate key words are used to find the product

classification. Once the classification is found, the

second step involves finding a particular sub-category for

the product .

This sub-category may well include several similar

products from different manufactures, thus enabling the

user to do product comparisons. The user then completes the

third step by making a product selection based on, for

example, manufacture and model number.

The steps involved m preparing and using the catalog for a state or local government purchasing offices are

described m the following sections:

Verify Catalogs & Set Up Contracts

Contract officers browse items m the Contract

Catalogs they received after they have been loaded or

updated by them or their suppliers. Contract officers also

set-up, confirm or change the prices and terms for each

contract they are administering. Larger suppliers can also

perform these same functions. Smaller suppliers using the

first level service cannot make changes to the catalog

items .

Browse Contract Catalogs

Buyers can search through items m the catalogs

limited to the catalogs from which they are authorized to

purchase and their product profiles. Both of these filters

can be easily modified for a particular session by turning

on and off specific contract and/or product groups. There

are two basic methods of locating an item. The keyword

method is a two step process with the first search

returning those product families that match the entered

keywords. Then the user picks the lowest level product

family to see the items available for purchase. The second

method of browsing the catalog database is to navigate down

a product family hierarchy that often has small pictures related to the type of product. When the lowest level

product family is reached, the user picks those he or she

wishes to purchase. The final list of actual items to

purchase can be filtered by manufacturer, price and keyword

in the product name.

Query Public Catalogs

If a buyer cannot find an item on the Contract

Catalogs issued to them by their Contract Administrator,

they can search the public Supplier Catalogs maintained at

the Catalog Service. This can be done at the same time as

the search of authorized contracts or separately by

modifying the catalog profile for that session. The Buyer

can do comparison shopping between the prices of items that

may appear on multiple private contracts or public

catalogs. The result is a list of similar items from

different manufacturers and different suppliers.

Electronic Procurement System

Figure 4 illustrates a business model for conducting

commerce m accordance with the present invention. The top

portion of Figure 4 shows the conventional manner m which

buyers and vendors interact. The arrows indicate the

exchange of purchase information m the form of request for

quotes, purchase orders, invoices, bill of sales, shipping

notices and the like. The exchange of each piece of information is in many cases only for the purpose of

creating a "paper trail" should reconciliation become

necessary. Creating this "paper trail" is, however,

expensive, time consuming, and is wasteful of resources.

The need to dispose of these paper records when they are no

longer needed poses additional concerns.

Applicant has discovered that a more efficient way of

tracking commercial transactions is to maintain them m a

shared database as illustrated m the bottom portion of

Figure 4. When a buyer wishes to submit, for example, a

purchase order, it is stored m the shared database and is

immediately available for review by a ve dor. Thus, there

is no reconciliation necessary because only one copy of the

transaction exists, i.e., the copy which is stored m the

shared database.

The Electronic Procurement System is for those

procurement offices that wish to maintain an electronic

link with their suppliers, but do not want to undergo the

time and expense to setup direct EDI links between

themselves and all their suppliers under contract. Using

a secure Internet browser, buyers can look at records of

all intermediate revisions or cancellations of purchase

orders, shipping notices and invoices that flow back on forth between them and the buyer. The electronic link on

the supplier side can be either through the Internet if

they are using the Bidder's Service or through their

established EDI VAN.

The introduction of "Purchasing Cards" has helped to

reduce overall administrative costs. The service accepts

these purchasing cards, along with other general purpose

credit cards.

Administer Buyers & Suppliers

Contract administrators set-up and assign Buyers who

are authorized to make purchases off of each contract

and/or if they can make purchases of public catalogs at

suggested retail prices. Contract administrators or the

Buyers themselves can also set up a product profile that

will be used to limit the items in the public catalogs or

private contract catalogs. Suppliers that do not have a

contract or public catalog loaded at the Catalog Service

can register themselves and maintain their own product

profiles for filtering RFQs that they are interesting in

bidding on.

Prepare RFQs or Purchase Orders

The Buyer selects the items they wish to purchase from

the private contract or public supplier catalogs on their

Internet Site. The Buyer has the following options as to how they would like to proceed when looking at a list of

similar items :

Pick specific items to put on Request For

Quotes to be sent to the appropriate

suppliers. In this case the item is known

and the supplier responds with their best

price .

Pick generic items without a Manufacturer

and Product Number to put on a Request for

Quote that is sent to the appropriate

Suppliers. In this case the Supplier

selects the specific item m their response.

Pick generic items without indicating a

Supplier. This is known as an un-addressed

RFQ that is addressed each night by the

Electronic Catalog Service according to

Supplier profiles. These requests are also

placed on the Electronic Bidder's Service

for Suppliers to search if they do not

received notice of the item due to their

product Profile.

Pick specific items with a manufacturer and

part number to put on purchase orders to be sent to the appropriate suppliers.

Buyer orders are immediately updated in the Electronic

Procurement System databases and are immediately available

for any Supplier that is a customer of the Bidder's

Service. For those that are not, the order is transmitted

through the EDI VAN service if the Supplier is registered

as EDI-capable. If not the order is sent either via e-mail

or fax depending on preference of the registered Suppliers.

Authorize Payment for Orders

If the user wants to pay for the order immediately

with a credit card, digital certificate smart card or

procurement card, the service takes control of the

operations to perform the payment and order fulfillment

processes . The exchanges between the browser and the

server are encrypted to insure confidentiality and

performed behind a firewall . The check-out procedure is as

follows .

After establishing a secure link with the browser, the

server receives the content of the shopping cart and

presents an order form to the buyer for collection of

secure personal information to complete the transaction.

The client then enters the requested personal information

(billing and shipping addresses, phone number, E-mail

address, etc.); chooses among the payment options offered; then enters the requested payment information, e.g. credit

card type, account number, etc.

All information that is captured m the above process

is recorded in a secure transaction database for subsequent

use m daily and monthly reports. The process also adds the

applicable taxes and shipping costs.

Review or Update Orders

The Supplier receives its orders from the Buyers either

immediately through the Catalog Service if the are a customer, or

via an EDI transmission, Fax or E-mail depending on their level

of service. The supplier then indicates f the order can be

shipped m full, or if one or more line items must be back

ordered.

When a supplier is an EDI customer or a Bidder's Service

customer, the buyer will receive acknowledgments, adjusted

purchase orders and intent to ship documents soon after the

supplier releases them. For any item on an order that is not yet

indicated as being shipped, the buyer can cancel or change and

re-submit it to the supplier.

Receive Shipping Notices and Invoices

Suppliers that are customers of the Bidders Service can

"turn-around" the Purchase Order into multiple Shipping Notices

or Invoices when they are ready to ship. The Supplier can

indicate that some items must be back-ordered and thus create partial Shipment Notices or Invoices by picking a subset of the

line items or by splitting the quantity ordered into shipped and

not-shipped quantities for individual line items.

EDI capable suppliers use their own internal system to

process the order and send it back to the Buyer through their EDI

VAN Service. Suppliers that received their orders either via Fax

or E-mail notify the Buyer of the intention to ship via

traditional means or via E-mail. In all cases, however, the

status of the order will simply be "PO Sent" until the Buyer

authorizes a payment for the purchase. Buyers will immediately

see these shipping notices and invoices if they are a customer of

the Order Management Service.

Update Order History

A copy of all sales invoices processed by the Catalog

Service or received by the VAN service are recorded by the Order

Management Service. These award notices can be kept as part of

the Contract Catalogs. Copies of all transactions processed by

the Catalog Service or sent through the VAN Service are kept m

the Order Management database for daily and monthly reporting.

Billing and Payment Methods

In order to complete the purchase cycle and capture

important data about the procurement process, an electronic

payment must be made. It can be by credit card and the

traditionally paper-based part of the transaction is over. But most business and governments would rather pay monthly bills and

only pay after goods have been received and inspected to be m

good condition. Converting this method of payment is a challenge

for everyone involved, now including the buyer's and seller's

bank. The service was the first to support a totally secure

environment including credit cards, and bank independent

Electronic Funds Transfer, m addition to providing a unique

capability to connect with suppliers using Electronic Data

Interchange (EDI) for managing and processing of orders and

invoices .

This system has a comprehensive payment and order

fulfillment capability. It includes a transaction server and many

back-office functions: processing credit card payments (Visa,

MasterCard, AMEX, Discover and all other popular cards) ; business

purchase cards for busmess-to-busmess transactions; tax

calculations; shipping method selection and billing; e-mail

confirmations; inventory verification and complete order

fulfillment including delivery of orders to multiple suppliers m

any format of choice - EDI, fax, e-mail or computer file. These

functions take place behind a "firewall" which prevents

unauthorized access to the back-office functions. The system

provides access to transactional and statistical information

pertaining to a customer purchases either on-line or as report f i l e s .

The system has integrated payment and order-processing

capabilities into its catalog web-site using Industry-standard

security software that supports Microsoft and Netscape Internet

browsers as well as the new Secure Electronic Transaction (SET)

protocol developed by MasterCard and Visa International.

State and local government purchasers can securely market

products and services, accept orders, process payments and

fulfill orders on the Internet. Delivery can be immediate m the

case of soft goods such as publication material, registrations

and software. In the case of hard goods, a transaction will be

transmitted to the suppliers and goods will be shipped m the

normal fashion.

The moment that the customer commits to make a purchase by

clicking on the prepare order button, the Catalog Service

completes the payment and order fulfillment process m a secure

back-office environment. The payment can be accompanied by a

remittance notice if the supplier is capable of receiving EDI

transactions .

Credit Card Transactions

An example illustrates the flow of information for a credit

card transactions. An on-line credit check with the appropriate

financial institution is made through the normal credit card

authorization process if the credit is authorized, the required funds for order settlement is temporarily held until it is

determined if the merchant is able to fulfill the order and the

customer is notified on-line of the status; if the credit request

is denied, the customer is notified on-line that his order can

not be accepted the order is sent to the supplier via the

Internet as an E-mail, fax or a computer file or m EDI format.

The supplier acknowledges receipt of order following an

inventory verification, an invoice confirmation is returned to

the Order Management Service by the supplier if the order can be

fulfilled; if the order can not be fulfilled, notification to

this effect is transmitted. The pending payment transaction is

processed through the financial institutions. Where the order is

fulfilled both the customer and the supplier are notified of the

outcome of the purchase request (e.g. by E-mail, or Fax) and the

customer receives a final invoice if the order is being

fulfilled, or a notification that the order cannot be fulfilled

m accordance with contract or delivery requirements.

Upon completion of the processing of an order, the Order

Management Service provides confirmation on the

acceptance/refusal of the order to the intervening parties. An

important feature of the service is that the system can accept

all popular credit cards for which the individual merchants have

been accredited, including VISA, Mastercard and American Express, while tne debiting of purchaser accounts and crediting cf

merchant accounts can take place with any financial institution.

Furthermore, the system will also accept a large number of

private credit cards, e.g. from retail organizations.

On-Account Transactions

In the case of a state and local jurisdiction, ordering from

a supplier under some form of blanket purchase agreement or

indefinite delivery contract, it is more common to pay on account

as opposed to use of a credit card as per the previous examples.

The supplier m this" case will have established terms of payment

with its clients, e.g. net 30 days.

The process for on-account payments is similar to the credit

card process with the following differences. The first step is to

confirm that the customer has a valid pre-established account

with the merchant . The order processing proceeds in the same

manner the order confirmation proceeds in the same manner with an

invoice being sent to the customer; however, there is no

immediate debiting of the customer account and crediting of the

merchant account, as was the case with credit card payments, as

payment will only be due at some future date as established

between the merchant and the customer the invoice can be paid on¬

line through the Internet at any time after receipt, with the

option of specifying the deferred date on which payment is to

be made . Procurement Card Transactions

These type of transactions are similar to the credit card

transactions m that an on-line check with the appropriate

financial institution is made.

Complete Transactions Reporting

A complete record of all buyer transactions is available,

made through the Catalog Service. In addition to the standard

transaction reporting, many other analysis type reports can be

generated for improved management information.

An example of a report is an open purchase order journal

produced on an ad-hoc basis including vendor order details and

order fulfillment status. The Order Management Service can also

provide information that helps to determine which products are

being frequently ordered that might be better purchased m

larger lot sizes.

Daily Transactions

This report gives a list of all transactions performed so

far during the current day. The information contained m the

report is:

Transaction number

Date and Time of transaction

Organization ID

Buyer ID

Seller ID Session ID (recorded sequentially for each buyer )

Contract ID

Payment Type

Sales Total

Shipping cost charged

State or Provincial sales Tax

Federal Sales Tax

Transaction Total (sum of sales amount + shipping +

sales taxes )

Seller' s Name

Seller's Address (excluding City, State/Region, Zip

and Country) .

Seller's City, State/Region, Zip and Country

Telephone number of Seller

E-mail Address of Seller

Shipping Name (Name appearing in shipping address)

Shipping Address (excluding City, State/Region, Zip

and Country) .

Shipping City, State/Region, Zip and Country

Billing Name (Name appearing in the billing address)

Billing Address (excluding City, State/Region Zip and

Country) .

Billing City, State/Region, Zip and Country Telephone number of Buyer

E-mail address of Buyer

Status code indicating the completion status of the

transaction.

Confirmation code (this is the credit acceptance code) .

Daily Transaction Detail

This report gives the details on the products involved in a

specific transaction. This report provides the information

contained m the transactions of the day listed above plus the

following product information (one line per product) :

Transaction number

Product number.

Quantity ordered.

Product description ( obtained from the catalog ) .

Unit price of the product.

Monthly Transactions

This report will list all products and services for all

transactions performed during a specified month. The information

given m this report is :

Transaction number

Date and Time of transaction

Product number

Quantity Product Description

Unit Price of product

Monthly Transaction Summary

The information provided m report summarizes the daily

transactions with the following information:

Total number of transactions during the period.

Total State or Provincial sales tax for the period

Total Federal sales tax for the period

Total shipping charge for the period

Total transaction amounts for the period.

The information is grouped by:

Completed transactions

Rejected transactions

Canceled transactions

Problem transactions

Product and Services Purchased Summary

A monthly file which contains a list of all products sold

during the month along with the class, name, supplier, purchase

amount, manufacturer and quantity (if applicable) sold for each

product and service.

HTML-PDF Forms

Figure 5 illustrates another concept m accordance with the

present invention related to business forms. There are many

situations known m the prior art wherein filling out a paper form is a prerequisite to obtaining a service or oenefi .

Insurance and medical forms readily come to mind. In most cases,

the service or benefit will not be rendered unless the proper

form is used and is completed m the proper way.

Applicant has discovered a novel way in which much of the

tedium can be eliminated when completing complex and cumbersome

forms. The invention builds on the advances m printing documents

made possible by the Adobe PDF technology. Although PDF

technology represents a major advance m printing complex

documents, there remained deficiencies m how the printed

information is compiled.

In accordance with the present invention, a process is

provided m which data for a printed form can be entered into,

for example, a user friendly HTML form. The data is then checked

for accuracy and/or a determination is made whether the entries

fall within predefined ranges. The user can then be alerted to

any errors and given an opportunity to correct them before

proceeding further. Once the HTML form is completed, the form

data is transferred to the corresponding PDF form for printing by

both the one filling out the form and also by the form recipient.

Because it is time consuming to convert a regular form to an

HTML form, Applicant has also invented a process to generate

automatically the HTML form, the CGI program that verifies and checks the user entries as well as automatically creates a

database for the form data.

It should be obvious from the above-discussed apparatus

embodiment that numerous other variations and modifications of

the present invention are possible, and such will readily occur

to those skilled in the art. Accordingly, the scope of this

invention is not to be limited to the embodiment disclosed, but

is to include any such embodiments as may be encompassed within

the scope of the claims.

Claims

WE CLAIM:

1. An electronic catalog system comprising:

memory means for storing a peramater of catalog items;

selection means for selecting one of said catalog items;

user input means for making said selection in accordance

with user determined peramaters; and

control means for controlling said selection process.