U.S. patent application number 10/244955 was filed with the patent office on 2003-06-19 for e-commerce transaction facilitation system and method.
Invention is credited to Astill, Craig A., Feaver, Donald P., Wilson, Kenneth G..
Application Number | 20030115129 10/244955 |
Document ID | / |
Family ID | 3820386 |
Filed Date | 2003-06-19 |
United States Patent
Application |
20030115129 |
Kind Code |
A1 |
Feaver, Donald P. ; et
al. |
June 19, 2003 |
E-commerce transaction facilitation system and method
Abstract
A method of facilitating an e-commerce transaction, the method
including: providing a set of trading parameters; accepting in
respect of a first entity (3) a desired trading profile including
desired values or ranges of multiple of said trading parameters;
and accepting in respect of said first entity (3) one or more
further trading profiles including values or ranges of multiple of
said trading parameters; establishing one or more functional
relationships between variations in a key trading parameter and one
or more other of said trading parameters; wherein each of said
further trading profiles are equivalent in desirability or expected
value to said desired trading profile, and said functional
relationship can be used to determine a set of equivalent trading
profiles having substantially desirability equal expected values
equivalent to said desired trading profile and said further trading
profiles.
Inventors: |
Feaver, Donald P.;
(Brighton, AU) ; Wilson, Kenneth G.; (Camberwell,
AU) ; Astill, Craig A.; (Brighton, AU) |
Correspondence
Address: |
SHELDON & MAK
9th Floor
225 South Lake Avenue
Pasadena
CA
91101
US
|
Family ID: |
3820386 |
Appl. No.: |
10/244955 |
Filed: |
September 16, 2002 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10244955 |
Sep 16, 2002 |
|
|
|
PCT/AU01/00299 |
Mar 16, 2001 |
|
|
|
Current U.S.
Class: |
705/37 |
Current CPC
Class: |
G06Q 30/06 20130101;
G06Q 40/04 20130101 |
Class at
Publication: |
705/37 |
International
Class: |
G06F 017/60 |
Foreign Application Data
Date |
Code |
Application Number |
Mar 16, 2000 |
AU |
PQ6289 |
Claims
1. A method of facilitating an e-commerce transaction, the method
including: providing a set of trading parameters; accepting in
respect of a first entity a desired trading profile including
desired values or ranges of multiple of said trading parameters;
and accepting in respect of said first entity one or more further
trading profiles including values or ranges of multiple of said
trading parameters; establishing one or more functional
relationships between variations in a key trading parameter and one
or more other of said trading parameters; wherein each of said
further trading profiles are equivalent in desirability or expected
value to said desired trading profile, and said functional
relationship can be used to determine a set of equivalent trading
profiles having substantially desirability equal expected values
equivalent to said desired trading profile and said further trading
profiles.
2. A method according to claim 1, wherein said first entity is a
seller and said trading profile relates to the trading parameters
desired by a seller.
3. A method according to claim 2, and further including: comparing
a submitted trading profile accepted from a second entity against
equivalent trading profiles of said first entity to determine
whether the submitted trading profile is more favourable to the
first entity than said desired trading profile.
4. A method according to claim 3, wherein trading profiles are
generated by or on behalf of said first and second entities with an
intention to conduct a commercial transaction, and are generated at
least with a view to determining market demand or supply for a
product or service to which said trading parameters of said trading
profiles relate.
5. A method according to claim 1, wherein the second entity is a
buyer.
6. A method according to claim 1, wherein said trading parameters
include one or more of: price, volume, payment terms, credit terms
and credit rates of interest.
7. A method according to claim 1, wherein said key trading
parameter is price.
8. A method according to any one of claims 3 to 7, wherein when
said submitted trading profile is more favourable than said desired
trading profile, a transaction between said first and second
entities is initiated.
9. A method according to claim 8, wherein profile which has trading
parameter values which are derived from said submitted trading
profile, and/or one of said equivalent trading profiles.
10. A method according to claim 9, wherein said one of said
equivalent trading profiles is said desired trading profile, or an
equivalent trading profile which is closest on a minimum squared
distance measure or equivalent measure from said submitted trading
profile.
11. A method according to claim 9, wherein said transaction trading
profile represents a compromise between terms of the desired
trading profile, and terms of the submitted trading profile.
12. A method according to any one of claims 3 to 7, wherein when
said submitted trading profile is less favourable to said first
entity than said desired trading profile, steps are performed to
establish a submitted trading profile and a desired profile that
are compatible.
13. A method according to claim 12, wherein the steps performed
involve a modification of the values or ranges of said trading
parameters of said submitted trading profile and/or said desired
trading profile.
14. A method according to claim 13, wherein either or both of said
first and second entities are suggested what changes could be made
to their respective trading entities to establish compatible
trading profiles.
15. A method of facilitating an e-commerce transaction, the method
including: providing a set of trading parameters; accepting in
respect of a first entity a desired trading profile including
desired values or ranges of one or more of said trading parameters;
and generating a metric representative of the desired trading
profile; wherein said metric can be used as the basis for comparing
said desired trading profile with a proposed trading profile.
16. A method according to claim 15, and further including:
generating a metric representing the expected value of the desired
trading profile.
17. A method according to claim 15, and further includes accepting
from said at least one party multiple desired trading profiles
having equal or substantially equal expected values.
18. A method according to claim 17, wherein in each of the equal or
substantially equal desired trading profiles, at least the trading
parameter of price is different in each profile.
19. A method according to claim 17, wherein in each of the equal or
substantially equal desired trading profiles, changes in price are
indexed against each of the other trading parameters besides
price.
20. A method according to claim 17, wherein in each of the equal or
substantially equal desired trading profiles, the sensitivity of
the trading parameter of price is quantified against each of the
other trading parameters.
21. A method according to claim 20, wherein this relationship is
quantified by an approximate mathematical expression.
22. A method according to claim 20, wherein the sensitivity of
price against each of the other trading parameters is independently
quantified.
23. A method according to any one of claims 15 to 22, wherein
parties to the transaction include a seller and one or more
buyers.
24. A method according to any one of claims 15 to 22, and further
including: performing calculations to determine one or more sets of
trading terms which agree with the desired values/ranges of the at
least two parties.
25. A method according to any one of claims 15 to 22, wherein the
prospective buyer and the prospective seller are respectively
identified by a search based on a product and/or service
classification code.
26. A method of identifying prospective partners in an e-commerce
transaction, the method including: providing a product and/or
service classification code; providing a database of records
relating to respective business entities, said records including
information, indexed according to said classification code,
recording at least one product or service provided by or required
by said entity and at least one desired trading profile in relation
to said at least one product or service; performing, in response to
supplied search information including at least one classification
code, and at least one submitted trading profile, a search of said
database for entities having a desired trading profile at least
compatible with said submitted trading profile.
27. A method according to claim 26, wherein the classification code
is organised in an hierarchical manner, so that search information
of variable specificity or granularity can be provided.
28. A method according to claim 26, wherein said classification
code is, or is based on or derived from, an internationally
recognised product and/or service classification code.
29. A method according to claim 28, wherein the classification code
is the Harmonised Tariff Code, or HTC.
30. A method according to claim 26, wherein the search information
includes supplementary information specific to business
organisations, such as geographic region, desired trading terms,
and credit profile.
31. A method according to any one of claims 26 to 30, and further
including: ranking the results of the search by one or
predetermined criteria.
32. A method according to any one of claims 26 to 30, wherein a
number of search fields can be specified in the search information
to increase the specificity of the results of the search.
33. A method according to any one of claims 26 to 30, wherein the
search is performed by a particular user, and search information
preferences specific to that particular user are taken into account
when conducting the search.
34. An e-commerce transaction facilitation system, including: at
least a first enterprise resource planning system operatively
connected to a first sales module; and at least a second enterprise
resource planning system operatively connected to a first
procurement module; wherein one or both of the modules are each
implemented by a processing unit and associated memory unit
maintaining computer program code for causing a method according to
claim 1 to be carried out.
35. An e-commerce transaction facilitation system according to
claim 34, and further including a search/directory module
connectable to the first sales module and the first procurement
module by a communications network; wherein the search/directory
module is implemented by a processing unit and associated memory
unit maintaining computer program code for causing a method
according to claim 26 to be carried out.
36. An e-commerce transaction facilitation system according to
either one of claims 34 or 35, and further including: a second
sales module operatively connected to the second enterprise
resource planning system.
37. An e-commerce transaction facilitation system according to
either one of claims 34 or 35, and further including: a second
procurement module operatively connected to the first enterprise
resource system.
Description
[0001] The invention relates to the facilitation of commercial
transactions, and relates particularly to the facilitation of
commercial transactions using electronic communications networks,
otherwise known as e-commerce transactions. The invention relates
to the facilitation of activities that occur within a real economic
trading system by providing a mechanism by which the structure,
dynamics and business process requirements of `real` economic
processes and emulated and thereby contributing to efficiently
functioning markets and optimal transactional outcomes.
[0002] Globalisation of the world economy and the increasing
ubiquity of Internet usage has resulted in product markets becoming
increasingly more competitive and immediate than ever before.
Despite the immense interest in facilitation of
business-to-business (B2B) transactions using e-commerce, a
cost-effective and easily implemented B2B solution that provides
comprehensive e-enablement for market search, e-procurement and
e-sales functions that integrate with/to enterprises' back-office
software systems is not generally in use.
[0003] A model for economic interaction in the form of a
computer-based system does not exist that provides a comprehensive
solution that enables business enterprises to use the
communications infrastructure of the internet to transact online
within an economic environment/framework that possesses the
structural characteristics of `real` economic processes that are
essential to producing optimal transactional outcomes. Moreover,
existing tools are particularly inadequate to address the
complexity associated with international transactions where the
trade amounts are often significant.
[0004] To date, Internet-based business systems that cater to
facilitating commercial transactions between business enterprises
(B2B) have been developed using economic frameworks that are
seriously flawed. Numerous different models or configurations of
so-called "digital marketplaces" have emerged in recent years.
These existing models would appear to be based on an imprecise
understanding and/or use of the technology that results in a
distortion of fundamental economic principles.
[0005] For example, the existing e-commerce models emphasise the
notion of creating digital marketplaces. Two predominant models are
the "business portal" that provides a centralised multi-product
"retail or end-user" style model; or the "industry-specific
marketplace" model. Although both purport to create digital
marketplaces, these models represent an electronic environment in
which business contacts may be established that may lead to the
eventual transaction of business. However, neither of these models
are capable of capturing the subtle complexity of the dynamics
underlying well-functioning markets.
[0006] Until now, B2B e-commerce business systems have neglected to
deal with the subtle, distinctions that exist between the concepts
of markets, industries, firms and products. The failure to properly
configure the processes that flow from the inter-relationship
between these concepts has had the effect of creating artificial
business environments rather than extending existing product
markets.
[0007] Instead, efficient and well-functioning digital markets must
be configured within an economic framework that enhances and
extends, rather than distorts, the competitive dynamics and
structural relationships of existing patterns of economic activity
and behaviour.
[0008] The economic dimensions of commercial processes are complex
and operate at many different levels. In a conventional context,
the economic inter-relationships that combine to produce well
functioning markets and resource-efficient business transactions
arise from signals and feedbacks between buyers and sellers that
are channelled through multiple forms of information networks. The
Internet has challenged the conventional forms of information
signals and feedbacks as the information network is capable of
consolidation within a single medium.
[0009] A consequence of the unification of information delivery
within a single dynamic medium is the mistaken belief that a change
in information network structure has the potential to change the
principles underlying fundamental economic behaviour and
relationships. This belief, however, is not accurate. In order for
an economically-based business system to function consistent with
first best principles of efficiency, systems must be designed to be
consistent with, and enhance, economic structures and processes in
order to deliver efficient market and transactional outcomes.
[0010] In order to construct an efficient commercial delivery
process within the parameters of electronic business networks, the
Applicant has determined that it would be desirable for there first
to be an identification and understanding of the structural
inter-relationships between prevailing economic concepts/conditions
that must be present within an economic system in order to generate
efficiently functioning markets and optimal transactional outcomes.
Second, it would be desirable for the business process related
transactional flows within and between information channels within
the system to be clarified.
[0011] Table 1 is a table of factors to help explain the conditions
that the Applicant has determined to be desirable to embed within
the structure of an efficiently functioning economic system. An
optimised electronic B2B model should be capable of emulating the
most critical of the subtle economic interactions that
spontaneously occur under conventional circumstances. This has not
yet been built into current electronic B2B models because no one
has adequately articulated the composition of a unifying economic
framework that could provide the system infrastructure for an
electronic economic system.
[0012] The foundation of the electronic economic system developed
by the Applicant is based upon an inter-related set of three
parametric conditions. Each parametric condition provides an
ingredient required in order for the `economic process` to function
properly. The three system parameters are the:
[0013] equilibrium condition/force
[0014] optimisation condition/force
[0015] maximisation condition/force
[0016] In an e-commerce applications context, each of the three
parameters corresponds to an important systemic function that
transpires within the framework. In order to simplify the arguments
that will follow, Table 1 identifies the key relationships that
will be discussed further below:
1TABLE 1 Parametric Dimensional Functional Application Condition
Characteristics Attributes Purposes Equilibrium Structural The
macroeconomic Firm to market, mechanics (market) to firm to firm
microeconomic connectivity (firm) inter- and data relationship
communication channels Optimisation Competitive Convergence of User
(strategic) dynamics demand and supply behaviour-- forces/tensions
signals and feedbacks Maximisation Process Internal resource Task
handling efficiency utilisation and and management allocation
decision-making
[0017] In broad terms, an `economic system` is the sum of a series
of inter-connected sub-system relationships. The sub-systems are
the generators of dynamic forces that each sub-system both injects
into, and extracts from, the system in order to execute a `core
business process`. Each sub-system, in turn, is comprised of a
consolidation of task-oriented business processes that influence
(feed into) the characteristics of the sub-system level
process.
[0018] The inter-relationship among the three above-referenced
system parametric forces to be captured within an e-commerce model
can be succinctly contextualised as follows. At the system level
the predominant force is the well-functioning system's tendency
towards equilibrium (i.e., the balancing of opposing dynamic
(supply and demand) forces. At the sub-system level, the
predominant function is to reach optimal demand-side or supply-side
oriented transactional outcomes (the exchange function). The
optimisation process, in general terms, is a function of the
enterprise's business process driven tendency towards maximising
resource (demand-side expenditure or supply-side revenue gains)
relative to the market (equilibrium) benchmark.
[0019] In a business process/transactional context, Table 2 is a
table of factors that have a subtle, business process
inter-relationship. The Applicant has developed a particular
configuration of the direct and indirect economic relationships
between these structural factors, that is implemented in a manner
that, within the context of the medium, efficiently channels
information flows to optimise the business process outcomes that
correspond to those relationships.
2 TABLE 2 Market Focus and Functions Transaction Focus and
Functions Buyer Seller Demand Supply Industry Firms Product market
Products
[0020] From a business process perspective, the commercial process
can be viewed as having two discrete stages. First is a
"market-oriented" dimension. Second, this orientation subsequently
shifts at a critical point in the commercial process to a specific
"transactional focus". A feature that distinguishes the two are the
subset of factors which represent the dominant forces that
influence the discrete outcomes occurring at the evolving stages of
a commercial process.
[0021] The origin of a transaction begins with a buyer. Buyers, in
economics, equate with a "demand" or the desire to satisfy a
material need. In order to satisfy this need, the buyer conducts a
vertical "drilling-down" or information gathering process that
begins at a general level and moves to increasing degrees of
specificity in identifying:
[0022] the product it wants more precisely (for example, a boat or
a automobile; that is, what general industry);
[0023] where, or the source, from which the product can be obtained
(for example, which firm supplies the product);
[0024] comparative product characteristics; ie, price, quality
availability etc.
[0025] At this stage, the information gathering process is driven
by, and conforms most closely with neoclassical demand theory.
Within the context of competitive dynamics, the process explains
how buyer-led demand-side forces are the predominant influence
affecting the progress of the search from a general to specific
refinement process.
[0026] At the broadest level, a buyer will conduct a search within
more general parameters--at the industry level. An industry,
however, is most easily defined as a categorisation, typology, or
grouping of firms that consists of those firms that operate
processes of a sufficiently similar kind and could produce products
that are close substitutes. Some firms within an industry will
produce certain products, while other firms belonging to the same
industry may produce an entirely different range of products.
Although there will be a "market" for all products produced by the
industry, clearly, there is no such thing as a single "industry
market".
[0027] The forum, or institutional environment in which the buyer
exercises its demand-side influence takes the form of what is
described as a "product market". However, a precise definition of
what constitutes a "product market" is among one of the more
elusive concepts in economics. In fact, there exists no single
concept of exactly what is a market. One definition (the
Lancastrian definition) asserts that markets should be thought of
as being made up of "products having similar characteristics". A
combination of these above definitions results in a concept that
markets are a notional forum in which products having similar
characteristics are exchanged.
[0028] At a particular point in the buyer's decision-making
process, a fundamental event in the spatial orientation of the
demand-side processes occur. At the moment the buyer decides upon
the specific type of product it is seeking, the decision-making
process ceases to be vertical, and shifts to a horizontally
oriented comparative analysis between like goods.
[0029] The predominant demand-side function influencing this stage
of the transaction is the comparative analysis conducted between
products having the same or similar characteristics. If the
Lancastrian definition of what constitutes a "product market" is
used, it is at this point the buyer truly enters the "product
market".
[0030] As a consequence of the comparative analysis among goods
which are close substitutes, the buyer will eventually select a
particular product that most closely conforms to its demand
requirements relative to the price it is prepared to pay for that
good. In this way, the "selection-decision" is made.
[0031] The relational configuration of a buyer seeking information
and product specificity is a one (buyer) to many (sellers) (1:M)
relationship. Therefore, buyer-led market activity takes the form
of a buyer using the medium to identify sellers, compare the
characteristics of the products they offer relative to the price
indicated (signalled). Properly designed Internet demand-oriented
mechanisms have the potential to increase the speed and efficiency
with which the buyer conducts search, identification and comparison
activities. Business system applications that emulate efficient
"market activities" should be directed towards enhancing the
search, identification and comparison functions.
[0032] A search mechanism that links one buyer to many sellers
through a centralised "portal" configuration is appropriate
provided that the scope of the search is sufficiently comprehensive
to identify and locate a wide enough number of suppliers and,
ultimately, products to give the buyer a good approximation of the
comparative characteristics of the products offered.
[0033] However, existing e-commerce models utilise economic
frameworks that create distorted and dysfunctional markets as a
result of two errors of structural logic.
[0034] First, centralised "portal" style models include within the
market only those products that sellers choose to offer for sale
within the system. This configuration resembles more an agency,
distribution or retail sale arrangement rather than an extension of
existing markets. Goods are placed in an artificial environment in
a retail sale style arrangement rather than reflecting
cross-comparative attributes characteristic of true markets.
[0035] Another structurally unsound attribute of the existing
models is that the centralised market place which purport to
facilitate sales create a shift from vertical to horizontal spatial
functions at the wrong structural dimension. The mechanical
implications of this occurrence is that it becomes impossible to
optimally integrate subsequent functions which occur in the
business process and which are discussed below.
[0036] The selection decision described above ceases the vertical
movement of market-oriented activities from general to specific. It
also ceases the 1:M buyer to supplier relationship. The importance
of this change is that another fundamental shift occurs by
implication. Rather than having a "market" focus, the business
process takes on a "transactional" focus.
[0037] The focal point for this analysis alters in that previously
it was a buyer:market relationship. Now by implication of the
organisational structures of production, the focal point is the
buyer:selling firm relationship.
[0038] In order to make a sale, the buyer must meet the seller's
terms and enter the transaction process. A question now arises as
to how to optimally configure the most efficient transaction
process by building on, or extending from the vertical market
functions described above.
[0039] Transactional outcomes can be well-explained using classical
and modern theories of the firm and neo-classical price theory. In
addition, a horizontal supply-side transactional orientation is
also consistent with concepts of supply-chain efficiency and
efficient internal management structures.
[0040] A organisational concept that is central to both theoretical
principles is the concept of control of key supply-side
functions.
[0041] One view is that firms or business enterprises exist because
they are an institutional structure that constitute an optimal
mechanism for organising production, on the one hand, and exchange
on the other. Both functions involve the generation of "transaction
costs". In this regard, the firm can be seen as a form of interface
between the production and exchange functions that exists because
it is the structure best capable of most efficiently internalising
transaction costs.
[0042] An optimal organisational structure minimises the
transaction costs of production and exchange. In this lies a very
strong argument that business transactions can be most efficiently
conducted where the control and conduct of the transaction rests
with the seller.
[0043] The mechanics of this assertion relate back to the close
relationship between signals and feedbacks. Firms formulate signals
in response to feedbacks. However, signals can only be seen by the
market to be adjusted at an external level where the firm has made
some internal adjustment as a consequence of feedbacks.
[0044] The product pricing decision is among one of the most
fundamental decisions a firm makes. Price is a key market signal
that can be quickly adjusted in the short-run, and can be used to
indicate many messages ranging from product quality to the
efficiency of the firm itself.
[0045] A notable difference exists between the signal, or asking
price, of a product. The ultimate selling price of a product is
dictated by a number of closely related factors that are determined
by circumstantial conditions. For example, the negotiation of a
contractual price will be subject to, among other things:
[0046] volume discounts
[0047] payment risks
[0048] payment time
[0049] country risk
[0050] transport arrangements
[0051] In brief, price negotiations are conducted in a manner that
balances the relative influence of the price-related factors in
determining a final sale price.
[0052] Present e-commerce systems do not emulate real markets. Most
can be classified as either being buyer (price-maker auction sites)
or seller driven (fixed price-taker sites) that generate artificial
or distorted market outcomes. In order to provide efficient and
relevant e-commerce tool, transaction hubs cannot be restricted to
a fixed-time, lot by lot sales process. Similarly, fixed priced
sales mechanisms do not allow for rapid and dynamic adjustment of
price relative to short-run seller strategies or price influencing
factors such as those described above.
[0053] In summary, the Internet is a communications network that
possesses media and computational attributes that allow for the
unification of information distribution and processing functions
that conventionally occur using numerous information distribution
and processing channels.
[0054] The market-related functions of the business process are
demand-side led and involve a one to many relationship where the
buyer's demands are met through an information gathering and
analysis process that involves a vertical drilling down from a
general to specific level.
[0055] The Internet is capable of handling such functions through a
centralised information gathering, categorising and sorting
mechanism. To ensure the accuracy of information, it is desirable
to take the information sought directly from the seller.
[0056] Where the buyer identifies a specific product type it wants,
it stops gathering information in a vertically flow and a spatial
shift to a horizontal product-level comparison takes place.
[0057] The selection decision is the critical point at which the
buyer, by implication, enters a 1:1 relationship with a firm.
Buyer-led, demand-side market related activities cease and
supply-side forces begin to drive the business process. The process
takes on a transactional orientation rather than market
orientation.
[0058] The institutional focal point for supply-side activities is
the firm. The firm is an interface between markets and production
that exists because it is the institutional structure that is most
efficiently able to internalise transaction costs associated with
market-related and production-related activities.
[0059] In order to manage the inter-relationship between
market-side and production-side functions, firms must control the
signal/feedback process. Feedbacks are used to make internal
adjustments. This, in turn, allows long-run adjustment of signals.
In the short-run, the seller must control the pricing and
negotiation processes in order to maximise flexibility in the
pricing decision arising from strategic competitive decisions or
the negotiated adjustment to factors affecting a final price
outcome.
[0060] Finally, horizontal control of the transaction process
allows for supply chain fluidity and consistency. A horizontal
distribution of transactional information flows allows for
efficient integration of transaction outcomes across the
supply-chain.
[0061] The Applicant has determined that the implications for
e-commerce of these considerations are that `market-related`
functions are best suited to take place within centralised search
and consolidation configurations. By contrast, real product markets
exist as extensions to firms in that they are institutional
structures that produce and place goods in product markets. The
nature of the supply-side transactional aspects of the business
process are made most efficient, and conform most closely to
economic theory, where the key supply-side functions are controlled
in a decentralised format by firms themselves.
[0062] In order to provide the infrastructure for efficient market
and transactional functions to take place, tools such as dynamic
negotiating devices and fluid and comprehensive supply-chain
integration processes are required from e-commerce business
software. To date, no such tools are known to exist.
[0063] Accordingly, there currently exists a need to address one or
more of the various shortcomings of the existing systems and
methods available for facilitating e-commerce transactions.
[0064] The Applicant has recognised that commercial transactions
can be advantageously facilitated within a systemic framework that
is designed to emulate economic processes thereby providing a
method by which business process activities can occur within a
system structure that coordinates, communicates and facilitates
timely and appropriate exchange of specific information to
appropriate recipients, at various stages of the transaction
process, results in efficiently functioning markets that promote
optimal transactional outcomes, that is configured to accommodate
international, intra-firm and domestic transactions which
transactions are managed from pre-transaction through to
post-transaction execution stages conforming to the transaction
parameters.
[0065] In particular, the Applicant has developed an economic
system that enables an exchange/transaction process to occur within
a framework that emulates real economic processes. The invention
provides the basis for a system structure that is capable of
achieving dynamic equilibrium. The equilibrium state is derived
from a structural configuration that facilitates a balance through
the interaction and alignment of `near` equivalent dynamic supply
(emanating from supply module) and demand forces (emanating the
procurement module). The matching of supply and demand forces is
further facilitated by business process activities that support the
execution and management of exchange transactions by providing
mechanisms that expedite the matching process.
[0066] The structure of the system enables the matching of a firm's
procurement requirements with suppliers of product items having
information about those products located within markets, or
supplied directly by other firms within the system or by firms that
are not part of the system but are given access to the system for
the purposes of placing products within it.
[0067] Preferably, the mechanism by which the matching of the first
firm's procurement requirements with the product's offered for sale
by a second firm is performed by a computer-based device that
remains within the control of the respective firms. The respective
matching mechanisms represent the procurement and sales modular
components of a single device performing separate, but
complimentary, buy and/or sell related functions. The procurement
and sales components may interact with a third search/directory
component that performs `market-related` functions.
[0068] In particular, the Applicant has recognised that commercial
transactions are advantageously facilitated by obtaining
information from one or more of the multiple parties involved in a
commercial transaction to determine one or more possible sets of
trading parameters that may be acceptable to the parties. Moreover,
the Internet is a vast communications network which a large numbers
of business enterprises can use to conduct business transactions.
In this respect, the Internet is a powerful tool of communication
that consolidates within a single medium, the ability of an
organisation to transmit "outward" messages or signals to attract
potential partner organisations to a business transaction while
simultaneously permitting organisations to receive and act upon
"inward" responses, or feedbacks, from external organisations.
[0069] It is emphasised that the Internet is a tool that can
directly enhance firms' "exchange" related functions (ie,
interaction with markets and buyers) but indirectly enhances
"internal production and supply" functions. In a direct sense, the
Internet is capable of enhancing the "price and product" signals it
sends to the market (in general) and buyers (in particular). The
feedbacks from these signals can be used and interpreted to alter
or adjust:
[0070] further external signals in the form of price relative to
quality to assist in increasing and optimising market efficiency
consistent with neo-classical price theory
[0071] operations of the firm to further improve process efficiency
to further reduce unnecessary transaction costs.
[0072] It is important that a firm is in an organisational position
to receive and be sensitive to feedbacks. Here, there is a long-run
and short-run adjustment dimension that must be considered. Over
the longer run, firms use feedbacks to make internal decisions and
organisational adjustments that can then be efficiently signalled
back to the market. In the short-run, firms can internalise
feedbacks that may alter most powerful market signal--the pricing
decision. It is at this point price theory plays an appropriate
role in understanding business process.
[0073] In order to emulate efficient, well-functioning markets, the
pricing and negotiation decisions are preferably placed within the
control of the seller. Since the price decision is a short-run
decision, it is one that cannot be easily transferred to a third
part to control on behalf of most sellers. Accordingly, any
automated price-related tool is desirably within the seller's
direct control for rapid adjustment response purposes, and is both
dynamic and multi-parametric.
[0074] From a supply-side perspective, and at the product market
level of transactional specificity, the supply-chain moves
horizontally from a firm's externally oriented market activities
into its internal organisational and production oriented structures
and functions.
[0075] In order to optimise efficiency in the form of maximising
price and quality signals to the market while simultaneously
seeking to minimise transaction costs, it is preferable that a firm
should control key functions of pricing signals (in the product
catalogue), negotiation (transaction hub) and transaction
management (post-transaction consolidation) and supply-chain
responses (back-end internal integration into ERP systems).
[0076] Accordingly, in a first aspect, the invention provides a
method of facilitating a commercial transaction, the method
including:
[0077] providing a set of trading parameters;
[0078] accepting in respect of a first entity a desired trading
profile including desired values or ranges of multiple of said
trading parameters; and
[0079] accepting in respect of said first entity one or more
further trading profiles including values or ranges of multiple of
said trading parameters;
[0080] establishing one or more functional relationships between
variations in a key trading parameter and one or more other of said
trading parameters;
[0081] wherein each of said further trading profiles are equivalent
in desirability or expected value to said desired trading profile,
and said functional relationship can be used to determine a set of
equivalent trading profiles having substantially desirability equal
expected values equivalent to said desired trading profile and said
further trading profiles.
[0082] Preferably, said first entity is a seller and said trading
profile relates to the trading parameters desired by a seller.
[0083] Preferably, a submitted trading profile accepted from a
second entity can be compared against said equivalent trading
profiles of said first entity to determine whether the submitted
trading profile is more or less favourable to the first entity that
said desired trading profile.
[0084] Preferably, trading profiles are generated by or on behalf
of said first and second entities with an intention to conduct a
commercial transaction, are generated at least with a view to
determining market demand or supply for a product or service to
which said trading parameters of said trading profiles relate.
Preferably, the first and second entities are respectively a seller
and buyer, though in other embodiments these roles may be
reversed.
[0085] Preferably, said trading parameters include one or more of:
price, volume, payment terms, credit terms, credit rates of
interest. Preferably, said key trading parameter is price.
[0086] Preferably, when said submitted trading profile is more
favourable than said desired trading profile, a transaction between
said first and second entities is initiated. Preferably, the terms
of said transaction are based on a transaction trading profile
which has trading parameter values which are derived from said
submitted trading profile, and/or one or said equivalent trading
profiles.
[0087] Preferably, said one of said equivalent trading profiles is
said desired trading profile, or an equivalent trading profile
which is "closest" on a minimum squared distance measure or
equivalent measure from said submitted trading profile. In other
embodiments, said transaction trading profile is "between" said
desired trading profile and said submitted trading profile, in the
sense that the transaction trading profile may represent a
compromise between terms of the desired trading profile, and terms
of the submitted trading profile.
[0088] Preferably, when said submitted trading profile is less
favourable to said first entity than said desired trading profile,
steps are preferably performed with a view to establishing a
submitted trading profile and a desired profile that are compatible
(ie said submitted trading profile being more favourable than said
desired trading profile). This may involve a modification of the
values or ranges of said trading parameters of said submitted
trading profile and/or said desired trading profile. In such cases,
it is preferably suggested to either or both of said first and
second entities what changes could be made to their respective
trading entities to establish compatible trading profiles.
[0089] In a further aspect, the invention provides a method of
facilitating a commercial transaction, the method including:
[0090] providing a set of trading parameters;
[0091] accepting in respect of a first entity a desired trading
profile including desired values or ranges of one or more of said
trading parameters; and
[0092] generating a metric representative of the desired trading
profile;
[0093] wherein said metric can be used as the basis for comparing
said desired trading profile with a proposed trading profile.
[0094] Preferably, the method further includes generating a metric
representing the expected value of the desired trading profile.
Preferably, the method further includes accepting from said at
least one party multiple desired trading profiles having equal or
substantially equal expected values.
[0095] Preferably, in each of the equal or substantially equal
desired trading profiles, at least the trading parameter of price
is different in each profile. Preferably, in each of the equal or
substantially equal desired trading profiles, changes in price are
indexed against each of the other trading parameters besides
price.
[0096] Preferably, in each of the equal or substantially equal
desired trading profiles, the sensitivity of the trading parameter
of price is quantified against each of the other trading
parameters. Preferably, this relationship is quantified by an
approximate mathematical expression. This relationship may be
linear or nonlinear in one or more of the trading parameters.
Preferably, the sensitivity of price against each of the other
trading parameters is independently quantified. Preferably, parties
to the transaction at least include a buyer and a seller. In some
embodiments, the parties to the transaction include a seller and
multiple prospective buyers. In this case, the method may further
include auction-based techniques.
[0097] Advantageously, calculations are performed to determine one
or more sets of trading terms which agree with the desired
values/ranges of the at least two parties.
[0098] Preferably, the prospective buyer and the prospective seller
are respectively identified by a search based on a product and/or
service classification code.
[0099] In a another aspect, the invention provides a method of
identifying prospective partners in a commercial transaction, the
method including:
[0100] providing a product and/or service classification code;
[0101] providing a database of records relating to respective
business entities, said records including information, indexed
according to said classification code, recording at least one
product or service provided by or required by said entity and at
least one desired trading profile in relation to said at least one
product or service;
[0102] performing, in response to supplied search information
including at least one classification code, and at least one
submitted trading profile, a search of said database for entities
having a desired trading profile at least compatible with said
submitted trading profile.
[0103] Preferably, said classification code is organised in an
hierarchical manner, so that search information of variable
specificity or granularity can be provided. Preferably, said
classification code is, or is based on or derived from an
internationally recognised product and/or service classification
code. Preferably, the classification code is, for example, the
Harmonised Tariff Code, or HTC.
[0104] Preferably, the search information optionally includes
supplementary information specific to business organisations, such
as geographic region, desired trading terms, credit profile
etc.
[0105] Preferably, the results of the search can be ranked by one
or more predetermined criteria.
[0106] Preferably, a number of search fields can be optionally
specified in the search information to increase the specificity of
the results of the search.
[0107] Preferably, the search is performed by a particular user,
and search information preferences specific to that particular user
are taken into account when conducting the search.
[0108] In particular, the search and negotiation stages of the
transaction may provide a configuration of trading parameters that
set the terms of an executable sales contract. The configuration
choices made by system users can result in a series of permutations
and combinations of business process tasks that must be completed
before the transaction will qualify as being executed. The business
process tasks must be executed conforming to the transaction
outcome requirements.
[0109] Preferably, the contract execution process involves the
satisfaction of any one or more of transport and logistic
functions, banking or financial functions, insurance and inspection
functions, and the adjustment of production, planning and inventory
functions within the selling firm.
[0110] In a further aspect the present invention provides an
e-commerce transaction facilitation system including:
[0111] at least a first enterprise resource planning system
operatively connected to a first sales module; and
[0112] at least a second enterprise resource planning system
operatively connected to a first procurement model;
[0113] wherein one or both of the modules are each implemented by a
processing unit and a associated memory unit maintaining computer
program cover for causing a method according to any one of claims 1
to 25 to be carried out.
[0114] The coordination of the execution of these functions may be
conducted in a manner whereby each step in the execution process
contract execution process must be satisfied in a stepwise manner
in order to minimise use of resources and risk associated with
contractual non-performance or failure on the part of either party
to the contract.
[0115] Embodiments of various aspects of the invention are
advantageously implemented in computer software enabled devices and
systems. Further, it is highly desirable that embodiments of
various aspects of the invention are implemented with the
assistance of a communications network, such as the Internet.
[0116] In order to assist in arriving at an understanding of the
invention, a preferred embodiment is illustrated in the attached
drawings. However, it should be understood that the following
description is illustrative only and should not be taken in any way
as restricting the generality of the invention.
[0117] In the drawings:
[0118] FIG. 1 is a schematic diagram representing a macro view of
the system architecture showing the main modules of the system as
well as access to the system;
[0119] FIG. 2 is a schematic diagram representing the communication
flow from the sales module of the system to the search/directory
module;
[0120] FIG. 3 is a schematic diagram representing the communication
flow from the search directory module to the procurement
module;
[0121] FIG. 4 is a schematic diagram representing the communication
flow between the sales module and the procurement module;
[0122] FIG. 5 is a schematic diagram representing the general
relationship among search parameters;
[0123] FIG. 6 is a schematic diagram representing a generalisation
of the direct stock procurement functions;
[0124] FIG. 7 is a schematic diagram representing a generalisation
of the indirect stock (non-stock) procurement functions;
[0125] FIG. 8 is a schematic diagram representing the relationship
among the different aspects of the sales module and the procurement
module;
[0126] FIG. 9 is a schematic diagram representing the relationship
between the procurement module and the sales module in respect of
the purchase/sales order processing functions; and,
[0127] FIG. 10 is a schematic diagram representing a
post-negotiation function of an embodiment of the invention.
[0128] Referring now to FIG. 1, there is shown generally an
embodiment of a system 1 for facilitating e-commerce transactions.
The system has three complementary components 2 to 4 that operate
independently but co-operatively to streamline of the
establishment, negotiation and execution of commercial
transactions. FIGS. 1-5 are schematic drawings representing an
overview of these three complimentary components, the contents of
which will be clearer in view of the description explanation of the
respective components below.
[0129] The described embodiment is particularly well suited to
improving the efficiency with which complex international,
intra-firm and domestic commercial transactions can be conducted.
The three complementary components mentioned above and each in turn
described in greater detail below, and are for the sake of
convenience referred to as:
[0130] Macro/market search/directory
[0131] Micro/Sales module
[0132] Micro/Procurement module
[0133] The first component, a macro/market search/directory module
2, provides a mechanism by which signals originating from separate
enterprises are aggregated. The second component, a sales module 3
(supply-side communications module) is a mechanism by which each
enterprise controls signals sent to both the macro/market module 2
and/or other enterprises' procurement module. The third component,
the procurement module 4 is the mechanism by which the sales module
signals can be captured from either the macro/market
search/directory 2 or separate micro/sales modules 3.
[0134] The three components provide the structure in which a
business process activities can occur that includes:
[0135] product search/selection
[0136] negotiation
[0137] post-negotiation
[0138] The first business process activity, product
search/selection, involves an identification of prospective
partners to a commercial transaction. The negotiation step
facilitates the negotiation or bargaining between multiple parties
as to the terms of a proposed commercial transaction. The
post-negotiation function assists in the execution of the
transaction management and logistical functions that are necessary
to be performed to execute any contract which is established
between parties as a result of a successful outcome of the
negotiation function.
[0139] The inter-relationship between the configuration of the
three components and the business process activities that occur
within the system is important. The structural mechanics of the
components provide the foundation of the model, and is designed in
a manner to achieve a system-wide equilibrium by providing a
balancing of dynamic forces (the second dimension condition), while
simultaneously seeking to maximise the efficiency of the user and
data inter-relationships in relation to `user to system` and `user
to user` contexts (the third, business process dimension
condition).
[0140] In practical terms, the equilibrium condition (at the most
basic level) is satisfied by means of constructing the structure
having the following mechanical characteristics:
[0141] open and decentralised entry and exit for all system
actors
[0142] decentralised distribution of key sub-system data processing
and management functions
[0143] instantaneous information and process data distribution
mechanisms
[0144] dynamic exchange/adjustment mechanisms
[0145] In the first respect, FIG. 1 illustrates how, in broad
terms, the system satisfies the open access requirement. The
search/directory module 2 includes a search/directory component 5
together with a administration component 6 and a requisitions
component 7. The functionality of at least part of the
search/directory module 2 is provided by an Application Service
Provider (ASP) connectable to the sales module 3 and procurement
module 4 by a communications network, such as the Internet.
[0146] The sales module 3 includes a catalogue/search requisition
component 10, a registration component 11, a contract quotation
component 12, a transport logistics services quote component 13, a
negotiation component 14, a quote manager component 15, and sales
order management and tracking component 16. An order communications
component 17 and ERP communications component 18 enable
communication between the sales module 3 and an enterprise resource
planning (ERP) system 19 or like electronic data source.
[0147] Similarly, the procurement module 4 includes a reverse
tender/quotation component 30, a micro-chain external item data
matching component 31, a non-stock component 32, a stock component
33 and a purchase order management and tracking component 34. An
order communications component 35 and ERP communications component
36 act to interconnect the procurement module 4 and a further ERP
system 37.
[0148] The sales module 3 and procurement module 4 are realised by
conventional computing apparatus and communication devices each
including a processing unit and associated memory storage unit
maintaining computer program code for causing the computing
apparatus to execute the required functionality.
[0149] In this example, each of the sales module 3 and the
procurement module 4, and associated ERP systems, are located on
the premises of separate selling and buying entities. In other
embodiments, one or more of the entities may include both a sales
module 3 and a procurement module 4 depending upon the commercial
activities of that entity.
[0150] All modules 2 to 4 of the system 1 interact with each other
at a system component to system component level; ie., buy to sell,
sell to buy, sell to market, market to sell, buy to market, market
to buy. In that regard, each of the modules 2 to 4 includes a
communications gateway, respectively referenced 50 to 52, to
facilitate communication between the modules 2 to 4. In addition,
where a buyer or a seller does not possess software to permit
module to module communication, buyers and seller can access each
of the modules 2 to 4 via a standard Internet browser by use of
browser access clients, respectively referenced 60 to 62. A browser
access client can perform market/search, buy and sell functions by
communicating directly with a particular component; ie., a
market/search, buy or sell component.
[0151] FIGS. 2-4 illustrate how the configuration of the system 1
encompasses the relationships that exist between the system's
`market-related` business process activities (the vertical firm to
market business relationships) and the system's firm to firm
business process activities (the horizontal firm to firm business
process axis). The juxtaposition of the two provides the basis for
the spatial relationships that occur between:
[0152] markets
[0153] industries
[0154] firms, and
[0155] products at the three stages (search, negotiation and
post-transaction management) in a commercial/transactional
process.
[0156] The configuration of these parameters encapsulate the
fundamental business process relationships that make-up a `virtual
`supply-chain`; i.e., the structure is capable of overcoming
information asymmetries in order to seek and manage
supplier-customer relationships among browser to system as well as
system to system purchase and sale interactions. The practical
implications of this are that a correct identification and control
of these relationships permits the construction of electronic
systems that are capable of generating predictable events resulting
in expected and rational outcomes that are in dynamic equilibrium
(optimal outcomes).
[0157] FIG. 2 illustrates the data flow from illustrative
supply/sales modules 70 to 72 to a market/search module 73. (Each
entry in this figure also includes a procurement module,
respectively 74 to 76, and an ERP system, respectively 77 to 79).
This data flow represents a micro (1) to macro (many) data
relationship. The data originates from each firm's enterprise
resource planning (ERP) system 77 to 79 or other equivalent
electronic data source. Each supply/sales module 70 to 72 selects
appropriate data and converts that data into a content/form that
can be used by the market/search module 73.
[0158] This function provides the infrastructure for the
market/search module 73 to receive firm derived supplier/product
information including data updates/refresh on a regular basis. The
data flow and content is determined by a sales module based data
direction/control function, as will be explained below.
[0159] The principle device that controls product/itemdata flow to
the search/directory module 2 is situated in the sales module 3.
The control issues relating to outbound data transmission turn upon
solving for the broad parameters:
[0160] What data (ie., which product items)
[0161] Where that data is to be sent
[0162] How often
[0163] FIGS. 3 and 4 illustrate how a firm's product/sales item
information (what) is sent to two classes of receiver. FIG. 3 shows
data flowing to components having a one to many (1:M) data
relationship, ie., search/directories and marketplaces. FIG. 4
shows data being transmitted directly to other firms being a one to
one (1:1) data relationship.
[0164] The data transmission functions of each sales module 70 to
72 include controlling mechanisms that allow sellers to restrict
the data content transmitted to different receivers. For example,
sellers will wish to send a large number of their sales product
items to marketplaces. By contrast, only selected items may wish to
be transmitted to discrete buyers.
[0165] Control issues include the frequency of catalogue updates
and will vary according to destination type. Search/marketplace
data updates may be required on a real-time basis because data will
be viewed frequently by large numbers of viewers. On the other
hand, product item updates sent to buyers (to refresh their
supply-chain catalogues), will be much more restricted in
scope.
[0166] FIG. 3 is an extension of FIG. 2 and illustrates the
movement of discrete data from the search/marketplace 73 to the
buyer's modules 74 to 76. The purpose of this function is to
provide a data saving mechanism whereby a prospective buyer can
build a customised catalogue of numerous items selected from a
search/marketplace module 2.
[0167] FIG. 4 also illustrates the transmission flow of an
electronic transportation function. The transportation function
involves the movement of a buyer from a search/marketplace module
to a discrete firm's sales module. For example, upon selecting an
item listed in the marketplace directory module 2, a buyer that
wishes to purchase the item(s) can elect to be transported (with
data content) to a sales module. The data content that is
transported with the buyer is derived from products it has located
in the marketplace/directory and appropriated to electronic
requisitions.
[0168] As the buyer may be looking at products from more than one
seller, this may require the creation of multiple simultaneous
requisitions. Therefore, simultaneous transport to multiple sales
modules of different seller is possible.
[0169] Both the procurement and search/marketplace modules make use
of the search module 2 to provide a buyer with functionality that
assists it in making a selection decision. The primary search
mechanism of the search module 2 is the search/directory component
5, which is designed to select, group and list search results
according to a user-selected configuration of industry index,
product classification, company/firm and geographical locator
codes. All of the generic (non-product or firm specific variables)
indices and coding systems used are derived from standard indices
recognised and administered by the United Nations Statistical Data
Division and private and public statistical agencies.
[0170] The search/directory component 5 functions by searching
mandatory and optional parameters which the user must
specify/select in defining the search criteria. The
search/directory component 5 configures the user's selection
mandatory and optional search criteria. It produces a simple
algorithm that formats the breadth of the search to conform to the
governing algorithm.
[0171] The search process functions by having the cross-relational
algorithm link classes of information. Some of the classes
correspond to an existing indexing system, other data classes do
not. The data classes and corresponding indices are as follows:
3 Data Class Index Industry (Broad) ISIC (2 digit level) Product
goods HS (4, 6, 10 digit level) services CPC (3, 5 digit level)
Brand Company Name parent subsidary Region 13 Category Region Code
Country UN 2 alpha code State/Province UN intra-country code
ISDN--telephone area code Internat. ISDN code Port--Air/Sea/Inland
UN Port Codes
[0172] Each specific product or service entered into the directory
will have a separate and unique identifier tag that is derived from
the configuration algorithm. The search configuration algorithm
distinguishes between companies, products and brands having the
same or similar attributes by arranging the relationships between
attributes of the governing classes.
[0173] For example; numerous similar products (good or service) may
fall within the same CPC or HS classification categories. Each
particular product item listed in the directory will inherit a
unique identifier tag that it derives from the totality of the
classification attributes listed in the table above. Even if a
product is tagged to a particular manufacturing or service
providing enterprise operating across several distribution points,
the same product offered across multiple outlets will take on an
unique identifier tag for each sale unit.
[0174] Accordingly, in order to identify the precise origin of a
product, geographical location identifiers can be attached to the
product. These can be further cross-referenced to other important
geographical identifiers such as nearest ports, airports or
distribution hubs all identified by their respective
international/domestic classification codes.
[0175] FIG. 5 illustrates how the search mechanism of the
search/directory module 5 drills down across four levels of
organisational form, namely, Industry 80, Product 81, Company 82,
and Brand 83.
[0176] The cross-relational attributes of the item identifier
criteria means that items can be gathered together at various
levels of aggregation and disaggregation. Users can therefore enter
the system and search either by broad product descriptors 84,
industry classification, brand 83, firm 85 or location 86 or any
combination of these fields. It is therefore possible for the
search mechanism to generate directories and lists by any of these
descriptors and classifications.
[0177] Moreover these lists or directories can be reported either
by location, firm, brand and or industry. In addition
cross-comparison of products is straight-forward. Having generated
the list of products in the appropriate catalogue, all the
information about the products can be readily compared, including
reserve price, volume, product characteristics and
specifications.
[0178] Internet search engines cannot by their very nature perform
searches which are able to most accurately and expediently identify
prospective commercial trading partners--either sellers and buyers.
At present most organizations will conduct searches having a
particular type or class of product in mind. Given the number of
different types of information and products that may fall within
the scope of a general search term, an organisation conducting a
search for prospective business partners typically ends up wasting
a great deal of time sifting and sorting among relevant and
irrelevant search results.
[0179] The search/directory module 2 provides the ability to narrow
the scope of the search considerably using a mechanism that is
capable of reducing the search criteria to a level of specificity
that accurately reflects the product being searched, and
subsequently ranking these result criteria.
[0180] To improve this level of specificity a more precise means of
conducting a product search is required for having a high degree of
precision is by means of a search mechanism that conducts a
database search for business enterprises that sell products falling
into a product's appropriate Harmonised Tariff Classification (HTC)
Code.
[0181] The HTC system is a classification index that is
internationally recognised and used by customs authorities around
the world for the classification of outgoing and incoming goods
crossing international or national borders.
[0182] The HTC System operates as follows:
4 4 digits represent the specific industry +2 digits represent 6
broad product class +2 digits represent 8 specific product class +2
digits represent 10 specific products
[0183] The search/directory module 2 provides prospective buyers
with the ability to look up the HTC Code corresponding to the
product type (general or specific) of the product they wish to
search. Each database search by HTC Code is cross-referenced to
industry level. For example, the Standard International Trade
Classification system (SITC) and business enterprise name criteria
enables the searcher to further narrow the search criteria.
Conversely, all searches by business enterprise name or general
product description will be cross-reference to the HTC Code.
Therefore, the common search criteria of all products contained in
the product search database are each product's discrete HTC Code.
Thus we will build the first product search engine based upon the
HTC Code.
[0184] The search/directory module 2 uses the HTC system as well as
other overlaying parameters built into the search mechanism, thus
creating increased levels of functionality and dynamism. The
results are to be categorised by a ranking system based upon
preferential outcomes selected by the user.
[0185] The search/directory module 2 is preferably case sensitive
and requires at least one field to contain data before the search
can be activated. Once the search criteria are completed the user
ranks the search numerically. This ranking of search parameters
creates dynamic outcomes not available with current search
mechanisms. A cross referencing mechanism matches procurement
requirements with search items based on product type, price,
volume, payment terms, geographical location
[0186] Additional flexibility may be built into this search
mechanism whereby no fields require mandatory inputs. Additional
fields can be nominated/included at the time of the search to
create a increased spectrum of result criteria. This increased
level of dynamism with the search provides for the user the optimum
outcome. This may result in unexpected outcomes based upon expected
values.
[0187] The greater the specificity of the search criteria
ultimately provides expanded search results generated from the
flexibility created from within the search mechanism.
[0188] The search function can be supplemented by expert system
functionality able to categorise and rank search outcomes according
to the user's preferences.
[0189] The procurement module 4 is a processing mechanism that
handles the demand-oriented procurement requirements of a single
firm. It matches the firm's demand requirements with product and
service items that it must obtain from sources external to the
firm. The search/directory functions of the search/directory module
2, operating in conjunction with procurement module functions of
the procurement module 4, provides the specific sources of products
and services that the firm can procure.
[0190] Procurement items are obtained from three sources of supply
within the system:
[0191] Items saved from the marketplace/directory searches
[0192] Items saved from sales modules searches or transmission
[0193] Items entered directly into the procurement module by
non-system browser access clients
[0194] These three external sources of items provide the pool
(supply) of potential items for purchase by the firm that may be
used to satisfy the demand requirements of the firm.
[0195] However, a firm's procurement requirements are derived from
factors internal to the firm arising from its operating and
production activities. The procurement module 4 distinguishes
between two broad types of procurement requirements, namely stock
items and non-stock items, respectively handled by the stock
component 33 and the non-stock component 32.
[0196] Stock item requisitions are made as a result of the
depletion of product items (inventory) that a firm uses direct
result its manufacturing or production activities; ie., are items
that are transformed and/or undergo a value-adding process in the
course of producing another product. Non-stock items are products
that a firm consumes as an indirect result of its daily activities.
Non-stock items include maintenance, repair and overhead (MRO)
items such as stationary, computer support items etc.
[0197] In addition, the procurement module 4 handles two broad
types of purchase orders:
[0198] Blanket (or standing) purchase orders
[0199] One-off (or standard) purchase orders
[0200] The procurement module 4 coordinates the firm's internal
demand requirements and provides a mechanism by which these
internal demand requirements can be matched with the externally
acquired pool of required items.
[0201] FIG. 6 is a diagram of the general process flow of the
direct stock procurement process. The demand for stock items is
derived at step 100 from processes that occur within a firm's
back-office systems (usually an ERP system 101). The ERP contains a
list of direct-stock product items and indicates when stock must be
replenished. The procurement module 4 functions by matching the
firm's direct-stock product item requirements with:
[0202] items supplied by current suppliers
[0203] items supplied by potential suppliers
[0204] The method and source of the matching process depends upon
whether
[0205] an existing blanket purchase order is to be extended
[0206] a new blanket purchase order is to be created
[0207] a one-off purchase order is to be created
[0208] Additional functionality permits the procurement requisition
to be fulfilled to conform to business process requirements as to
whether:
[0209] a quotation price is required
[0210] a tender process must be followed
[0211] and whereby inbound quotes and tenders are determined on the
basis of a dynamic, reverse negotiating process.
[0212] The supply of stock items is derived from the three external
sources identified above. The method of matching is dependant upon
the business process functions which are required to be met under
the particular circumstances of the specific procurement
requirements. Once the purchase order is made at step 102, sent and
confirmed by suppliers 103 and 104, its confirmation is processed
back into the ERP system 100.
[0213] FIG. 7 is a diagram of the general process flow of the
indirect or non-stock procurement process. The demand for non-stock
items is derived from processes that occur as a result of
consumption as a result of organizational and operational factors
within a firm. It is frequently the case that inventory management
of consumption of non-stock items are not as sensitive and accurate
as is the case with stock-items. The demand for non-stock items is
derived from specific operating units 110 to 112 within the firm.
The list of non-stock product items within the ERP 101 is
generalized to product type and category rather than at a highly
specific level as it is with stock items.
[0214] Demand for non-stock items is derived from members of the
firm who recognize replenishment is required. Requisition of
non-stock items is usuall initiated by the member rather than the
ERP or back-office functions (but is may be the case that the ERP
initiates some purchase requirements).
[0215] The procurement module 4 provides a mechanism by which a
non-stock requisition can be created at step 113 by the initiating
member. The requisition is formed according to the results of a
matching of the requisition product item requirements with:
[0216] items supplied by current suppliers
[0217] items supplied by potential suppliers
[0218] Additional functionality permits the procurement requisition
to be fulfilled to conform to business process requirements as to
whether:
[0219] a quotation price is required
[0220] a tender process must be followed
[0221] and whereby inbound quotes and tenders are determined on the
basis of a dynamic, reverse negotiating process.
[0222] The supply of non-stock items is derived from the three
external sources identified above. The method of matching is
dependant upon the business process functions which are required to
be met under the particular circumstances of the specific
procurement requirements.
[0223] Once the purchase order is made, sent and confirmed by the
supplier, its confirmation is processed back into the ERP
(back-office) systems.
[0224] FIG. 8 is a diagram illustrating the operation of the sales
module 3 shown in FIG. 1. The sales module 3 is a device that
performs supply-side functions that either `stand-alone` to
configure and execute a sales transaction; or function in concert
with a procurement module to provide an increased level of
automated transaction processing. A buyer can be transported to the
sales module 3 via the transportation mechanism from a
search/directory module 2 or procurement module 4; alternatively, a
buyer can enter the sales module via direct browser access.
[0225] In all cases, the buyer-client selects a list of items
according to a series of business case rules or navigational
choices and creates a product requisition form. The item selection
process will, by implication, generate a list of items that the
buyer-client configures according to its requirements. If
transported from a procurement module 4 or search/directory module
2, the buyer will have a partially configured a requisition. The
requisition contains data to be used for the purposes of obtaining
a quotation, demonstration order or outright purchase
(negotiation).
[0226] The item selection list, by implication, is the same data
that will be contained in a sales order invoice. The sales order is
the configuration of data that will be processed as the final sales
terms and conditions between the buyer and seller. The sales order
is also processed in the ERP as a discrete transactional
outcome.
[0227] The population of item data within the sales module is
derived directly from data obtained from the ERP (thus avoiding
data duplication).
[0228] Upon completing a requisition, a registration process must
occur before the buyer can proceed with the transaction. If the
buyer has been transported from a procurement or search/directory
module, registration is automatic. The registration data is matched
to customer/sales related data in the seller-firm's ERP consistent
with, and to be used for, customer relations management (CRM)
functions/purposes.
[0229] At this stage, the requisition is made according to an
unadjusted order price. This is the base price upon which further
price-related adjustments will be made subject to the functions
described below. A provisional sales order number is allocated to
the requisition (now becoming a provisional sales order).
[0230] The provisional sales order is provisional for several
reasons. One reason is that its initial purpose is derived from
that fact that the buyer-client may wish to obtain a quotation
only. The seller's quotation price must be competitive, but not be
the last price-related say; ie., further price adjustments may be
made at a later step in the process; ie., final negotiation.
[0231] At the quotation stage system generated adjustments for:
[0232] volume purchases (ERP data)
[0233] customer status discounts--ie., if the customer is known and
good--a discount may apply
[0234] The system computes the quotation price by taking the
unadjusted provisional sales order price and then deducting
appropriate rebates.
[0235] No price adjustment is mandatory--only occurs if volume and
customer class rebates apply. The system computes the quotation
price. A quotation number is generated by the system and the
provisional sales order is stored in the system under the system
assigned quotation number.
[0236] The buyer is provided with the quotation number and the
quotation details and the quotation amount. The should be able to
leave and access the system calling up the provisional sales order
at a later time by inputting a password and sales order number.
[0237] The buyer may, before or after viewing the quote, change
their mind and wish to re-configure their order. Functionality
allowing the buyer to add/delete items in the sales order list is
provided.
[0238] If a buyer selects a request for quotation, a second,
parallel, quotation function is set in motion being a quotation for
ancillary service contracts such as transport/logistics, insurance,
finance and inspection.
[0239] The services contract quotations are calculated using system
data derived from the core sales contract plus:
[0240] shipment details, including price, etc.
[0241] cargo type
[0242] cargo weight and volume data, etc,
[0243] The sales module automatically determines whether the sales
contract is domestic or international by conducting a cross-check
between country of origin (ie., seller's location) and country of
destination.
[0244] The buyer (or ERP) will fill in the additional required
information.
[0245] Place of loading (domestic)
[0246] Place of discharge (domestic)
[0247] Port of loading (international)
[0248] Port of discharge (international)
[0249] Inland freight required from port to plant (if sea or
air)
[0250] Container type--general or refrigerated (if sea)
[0251] Estimated time of departure (ERP lead-time+one week)
[0252] The buyer will check the information and select the send
quote to shipping agent or forwarder. The shipping agent will be
sent an email notifying him that a new RFQ has been posted to his
URL/access site.
[0253] The vast majority of international and domestic commercial
transactions undertaken between business entities (B2B
transactions) fall into the category of intermediate goods trade.
Intermediate goods trade refers to B2B trade of primary, or
secondary non-finished goods requiring further processing to create
a marketable finished product.
[0254] International and domestic intermediate goods trade is
dominated by the pricing decision. The pricing-decision is the core
decision of the transaction process. It involves a price-setting
decision on the part of the seller, and a price-bidding decision on
the part of the buyer. The ultimate buyer will undertake a
comparative and competitive market analysis and, subsequently, make
a conscious and calculated pricing decision. A seller, on the other
hand, will set an indicative price, which, under typical
circumstances is broadly calculated on a cost plus profit basis.
The price spread between the seller's preferred selling price and
the buyer's offer price is the negotiable margin.
[0255] However, in addition to price, intermediate goods
transactions are frequently complex and additional factors are part
of any transaction. These factors include, for example:
[0256] volume
[0257] the method of payment, ie,
[0258] pre-payment
[0259] letter of credit
[0260] documentary collections
[0261] open account;
[0262] credit terms; ie,
[0263] 30, 60, 90, 120, 180 or more days
[0264] credit rates of interest
[0265] transport and logistics charges
[0266] insurance charges
[0267] inspection charges
[0268] banking and finance related charges
[0269] country and credit risk adjustments
[0270] In an international trade negotiation buyers and sellers
effectively negotiate a transaction involving multiple factors,
which generally include the following variables, though may include
several others:
[0271] Price
[0272] Volume
[0273] Payment Method
[0274] Time terms
[0275] Credit terms
[0276] Additional negotiating terms can be either added or excluded
from the negotiation depending on whether the transaction is an
international, domestic or intra-firm (international or domestic)
negotiation. The transaction embodiment provides the ability to
negotiate over a range of variables. It operates in real-time and
is capable of being used by multiple users simultaneously. All
functions are conducted in a systematic manner that is consistent
with the well-known international standards Incoterms 2000 and the
CP 500 requirements.
[0277] The system 1 provides a mechanism by which buyers and
sellers can negotiate an agreed set of contractual outcomes
covering price and all price-related aspects of the contract.
[0278] A feature of the system 1 is that it can operate at three
levels:
[0279] As a multi-buyer and/or multi seller multiparametric
auction
[0280] As a single buyer to single seller multiparametric
negotiation game.
[0281] As a simultaneous combination of the multiparametric auction
and the multiparametric negotiation game.
[0282] The auction aspect of the system 1 may use any one of the
standard auction design rules, which will be chosen by the seller
in advance. For instance the seller may choose to sell the product
using the rules of any one of the "English" auction, the "Dutch"
auction, the "sealed-bid" auction or the "Vickrey" auction. The
type of auction will be chosen by the seller and communicated to
the buyers in advance. However, the major original method by which
the auction is instigated in the transaction hub comes from the
method by which sell offers and buy bids are entered and resolved
and the number of variables included in the auction process.
[0283] (a) Setting the Seller's Reserve Offer
[0284] In order for the system 1 to begin to perform its
operations, the seller specifies values for the relevant trading
parameters over which it has influence in an international trade
negotiation. In an international trade transaction the seller is
not only interested in price, but also the following additional
variables: volume; payment method; time terms; and credit terms (as
well as, perhaps, several others).
[0285] For example, a seller may be prepared to accept a lower
price if the seller can sell a greater volume or get more
favourable payment terms. Therefore, it is usual for a seller,
during the course of a negotiation, to make expected value
calculations over a wide range of different combinations of these
variables. The system 1 provides an automated process of preference
calculation by allowing sellers to transparently reveal to
themselves the values placed on the various components of any offer
and then to verify that their preference ordering is consistent and
non-reflexive.
[0286] In determining the final outcome of the negotiation, it is
possible that the computer optimising algorithm used in the system
1 will generate a combination of price, payment methods, credit
terms, credit rates of interest etc that was not be anticipated or
thought of by the human being who sets the parameter values for the
sell offer. Because there are many thousands of possible
combinations and permutations, a partly or completely non-reflexive
preference ordering over all preferences may be generated. The
seller (with the aid of the computer) identifies all those possible
combinations of the parameter value that are of equal expected
value, most particularly those covering the reserve offer. That is,
once the seller has chosen one combination of parameter values that
represent the preferred reserve offer (O.sub.1), the seller should
then be able to identify readily other parameter values that
generate an identical expected value calculation such that a second
reserve offer (O.sub.2), third reserve offer (O.sub.3), and other
reserve offers are of equivalent value?
[0287] Step 1:
[0288] Seller enters values for all variables of its most preferred
reserve offer (O.sub.1). This is the offer that the seller would be
happy to accept if it were offered by any buyer.
[0289] The seller is required to enter a value for each of the
following, where they apply:
[0290] price
[0291] volume and volume price reductions, where they apply
[0292] the method of payment, ie,
[0293] pre-payment
[0294] letter of credit
[0295] documentary collections
[0296] open account;
[0297] credit terms; ie,
[0298] 30, 60, 90, 120, 180 or more days
[0299] credit rates of interest
[0300] transport and logistics charges
[0301] insurance charges
[0302] inspection charges
[0303] banking and finance related charges
[0304] country and credit risk adjustments
[0305] As part of this initial value setting, the seller indicates
the precise fractional relationship between the change in price and
change in each of the variables that directly (in either a linear
or non-linear relationship) affect the determination of price:
[0306] volume;
[0307] The seller indicates the percentage volume discount on price
for a range of different volumes, all other variables held constant
(this will generate a simple linear or non-linear function of price
change as a function of volume)
[0308] method of payment;
[0309] The seller indicates the percentage price increase, from the
base price, contained in O.sub.1, associated with each payment
method beyond pre-payment such as letter of credit, documentary
collections open account, all other variables-held constant (this
will generate a linear or non-linear function of price change as a
function of payment method)
[0310] credit terms;
[0311] The seller indicates the percentage increase in price
associated with the increase of time beyond 0 days such as 30, 60,
90, 120, 180 or more days, all other variables held constant (this
will generate a simple linear or non-linear function of price
change as a function of time terms)
[0312] credit rates of interest;
[0313] The seller indicates the percentage increase in price
associated with interest penalties over time, all other variables
held constant (this will generate a simple linear or non-linear
function of price change as a function of interest premiums).
[0314] The system 1 then determines an expected value for this sell
offer, say v.sub.1. At the conclusion of step 1 the seller has
specified information on the preferred reserve offer and the way
important price-related variables such as volume and method of
payment impact upon price change. With this revealed preference
information, the system 1 is able to generate all possible
combinations of the parameters that will generate offers of equal
expected value using a standard maximum likelihood algorithm.
[0315] Step 2:
[0316] The system 1 now gives the seller a chance to check revealed
preferences by allowing the seller to enters values for all
relevant variables, but with a slightly higher price and altered
values, where relevant, for other terms, say for example less
favourable payment terms, representing an alternative offer,
(O.sub.2) which is identical in expected value to
v.sub.1=O.sub.1=O.sub.2. Importantly this offer is considered to be
of equal value in the sense that the seller is no worse off than in
the case of O.sub.1.
[0317] Using the maximum likelihood algorithm the computer is able
to check the new values against the preferences revealed in Step 1
for consistency. The system 1 will indicate to the seller if there
are any inconsistencies and allow the seller the chance to correct
inconsistent values. After repeating this exercise a small number
of times, the computer maximum likelihood algorithm will generate a
complete set of non-reflexive preference orderings.
[0318] Step 3:
[0319] Seller now repeats Step 2 and enters values for all relevant
variables, but with a slightly higher price and altered values for
other terms representing an alternative offer, (O.sub.3) which is
identical in expected value to v.sub.1=O.sub.1=O.sub.2=O.sub.3.
[0320] Once this process is completed, the seller has effectively
established a system of functional relationships between variations
in a key trading parameter and one or more other trading parameters
which may be represented as a system of simultaneous equations
whereby price is a function of a range of variables and changes in
price are functions of a range of other, but related variables.
Using any one of a number of standard maximum likelihood techniques
such as Newton-Raphson or the Genetic algorithm parameter approach,
a matrix of equivalent value calculations can be generated for
every possible permutation or combination of the variables included
in the sell offer process. This means that the complete equivalence
of value will be revealed for every possible combination of price
and the various other terms identified above as part of this
reserve offer calculation.
[0321] At the end of this process we have a complete set of seller
offers O.sub.1, . . . O.sub.n, covering all possible combinations
of the trade variables that generate offers that are equivalent in
value, v.sub.1. This means that it is relatively straight forward
by essentially interpolating between O.sub.1, . . . O.sub.n in a
multi-dimensional space, to compare any bid from any buyer and
determine whether it is above the seller's reserve offer,
v.sub.2>v.sub.1, or below the reserve offer, v.sub.2<v.sub.1,
irrespective of the composition of the offer.
EXAMPLE
[0322] Consider a simple hypothetical example. Assume that a seller
enters initial values for the preferred reserve offer which include
a price of $10 per unit, to be paid by letter of credit on 60 days
at an effective credit rate of interest of 10%. As part of the
initial value setting the seller also indicates the percentage
price increase required if the payment method is not letter of
credit but rather documentary collections or open account, or if
the payment is by letter of credit but on less favourable time
terms such as 90 days. With this revealed information the system 1,
using a maximum likelihood estimator, is able to identify other
equivalent reserve offers which, for example, might be a price of
$11 per unit by letter of credit on 90 days at an effective
interest rate of 12%. In other words the computer is able to
determine different combinations of price, payment method, time
terms etc that are of equivalent value to the seller's initial
reserve offer and all combinations of the variables that are
superior and inferior to the reserve offer.
[0323] Once the seller has completed the exercise of determining
its reserve offers, the seller may now choose to indicate that it
has product to offer for auction, or sale and may begin negotiating
directly with a potential buyer, or do both.
[0324] The Single Seller Auction Scenario
[0325] Having specified that it is has product to sell and it
wishes to proceed with an auction, the seller now posts this
information to the product catalogue.
[0326] Step 1: Seller Indicates the Type of Auction and Auction
Rules
[0327] The seller may choose to sell the product using any of the
"English" auction, the "Dutch" auction, the "sealed-bid" auction or
the "Vickrey" auction rules.
[0328] Step 2: Bids Come in from Buyers
[0329] The auction remains open for a specified time or until there
is a bid of value V.sub.n.gtoreq.v.sub.1. In the same way that the
seller specifies values for the variables: volume; Payment Method;
Time terms; and Credit terms, etc., the buyer must also enter a bid
that indicates values for each of the relevant terms to an
international transaction. Depending upon the rules of the auction,
certain information will be revealed to all market participants.
However, as each unsuccessful bid comes in, the owner of that bid
will receive feedback about their bid and what they might change,
or increase in order to make the bid closer to the reserve offer of
the seller. For example a buyer might receive advice to either
reduce-time terms from say 90 days to 60 days or slightly increase
price or some combination of the two.
[0330] Note, the reserve offer of the seller is not revealed to the
bidders. At the end of this process, the product will be sold to
the highest bidder measured by the extent to which the winning bid
exceeds the reserve offer. Where there are two identical winning
bids the bid received first will be the successful bid. or the
market did not clear. When the market does not clear then the
seller has the choice of beginning the process over again or,
alternatively, to begin negotiating directly with one or more of
the potential buyers.
[0331] The Single Seller-Single Buyer Negotiation Scenario
[0332] In many real world trade situations the buyer and seller are
well known to each other and often have a long-standing trading
relationship. In these cases they may wish to begin to negotiate
directly with each other. The system 1 designed to deal with just
such situations. In this sense the system 1 provides the mechanism
to undertake a bilateral bargaining game. The bilateral bargaining
game may take one of several forms and again the rules covering the
negotiation would be agreed in advance of the formal commencement
of the bargain. Importantly, in the bargaining games/negotiation
scenario, the buyer may reveal bids in a manner similar to the way
the seller reveals preferences. In the transaction hub the
bargaining/negotiation game may take one of the following
forms:
[0333] an alternating-offer bargaining game instigated by the buyer
(requiring real time on-line access by both buyer and seller)
[0334] an alternating-offer bargaining game instigated by the
seller (requiring real time on-line access by both buyer and
seller)
[0335] a single-offer bargaining game instigated by the buyer
(requiring real time on-line access by the seller only)
[0336] a single-offer bargaining game instigated by the seller
(requiring real time on-line access by the buyer only)
[0337] a cooperative game instigated by either party and with an
agreed arbitrator (the transaction hub via the computer
itself).
[0338] In these bargaining games, an international trade
transaction operates by means of a multiparametric negotiation, as
explained above. The bargaining is not constrained to a single
variable, price, but rather embraces all the variables relevant to
an international trade transaction. In this case, though, the
bargaining framework involves a cooperative game instigated by
either party and with an agreed arbitrator, whereas the transaction
hub is both the vehicle through which the negotiation occurs and
the arbitrator to the negotiation.
[0339] In the bargaining/negotiation games buyers and sellers can
negotiate over the whole range of international trade terms
identified above. The process may begin with either the seller, who
has set the reserve offers O.sub.1 to O.sub.n with equivalent
value, v.sub.1, or with the buyer, who undertakes a similar process
to the seller, in order to specify maximum bids, B.sub.1 to B.sub.n
with equivalent value, v.sub.k beyond which the buyer is not
prepared to go. As long as v.sub.k.gtoreq.v.sub.1 then a bargain
can occur and there is room for negotiation.
[0340] Where v.sub.k.gtoreq.v.sub.1 then a bargain/negotiation may
take place and the computer will feed back to both sides the need
to change values. For example, hypothetically, the computer may
indicate to the seller to slightly lower price and the buyer to
slightly improve payment time terms from say 90 days to 60 days.
That is, the
[0341] The buyer and seller may bargain themselves, with advice
from the computer, or let the transaction hub assist them to come
up with a satisfactory solution that is at least no worse than the
outcome they would have achieved bargaining on their own, and most
likely to be more favourable to both parties, all other things held
equal.
[0342] In order to assist in the arbitration process, the seller
and the buyer each reveal some additional information relating to
the terms over which they are negotiating.
[0343] Both the seller and buyer will each have to allocate simple
arithmetic weights to each of the terms over which they are
negotiating. Consider the following simple example:
5 Payment Credit Time Interest Price Method Terms Terms .SIGMA. A b
c D 1
[0344] The weights a+b+c+d=1. This information, plus the
information revealed by the seller and buyer when specifying their
respective pricing functions will be used by the system 1, using a
genetic algorithm parameter framework, to find the most favourable
outcome over price and all related terms to the negotiation. It is
possible for there to be more than one outcome. Where there are
several outcomes of equivalent expected value then the computer
will choose one at random.
[0345] Once the system 1 has been in use for some time and has
built up a profile of previous successful transactions this
information can be interrogated to assist in facilitating further
successful transactions. Desirably, neural network functionality is
used to augment the optimisation process.
[0346] It will also be possible for the seller to undertake both an
auction and a negotiation simultaneously, and to undertake multiple
negotiations simultaneously.
[0347] Post-Negotiation Transaction Processing
[0348] Direct Purchase and Sales Order Processing
[0349] This section describes the process flow and data
specifications for the configuration and transmission of purchase
order and corresponding sales order data between a buyer's
procurement and seller's sales modules.
[0350] These functions originate from mechanisms contained within
the procurement module 4 and sales module 3. After a purchase order
(PO) draw-down (for a one-off or blanket purchase order (BPO)) has
occurred within the ERP 37 (or is manually interfaced), the PO
details appear in the procurement module 4 ready for processing.
This outbound PO is to be delivered from the originating
procurement to the appropriate sales module.
[0351] The procurement module 4 recognizes and distinguishes
between outbound PO's to be delivered to suppliers that do not have
a sales module as well as outbound PO's to be delivered to a sales
module.
[0352] The buy-side administrator will receive the PO (in the
normal course of events, which will appear in the buy-side outbound
PO interface). The administrator will check the order (ie.,
requisitioned items) and seller details. If all appear to be
correct and no critical data has been omitted from the order, the
administrator selects the `process order` function.
[0353] The `process order` function will activate a process whereby
the PO data will then be transmitted to the appropriate sell-side
platform where it will be received and processed (on the sell-side
platform) in a manner described below.
[0354] The sales module 3 contains functionality that enables the
receipt of inbound purchase orders in the form of inbound
sales-order administration functions. Inbound PO's (ie., on the
sell-side) are presented to the system administrator via the
inbound sales order screen. The system administrator performs an
order approval process. The sell-side administrator checks the
order details and seller details. If all appear to be correct and
no critical data has been omitted from the order, the administrator
selects the `process order` function. If the order appears to be
correct, it can be processed to the ERP. A sales order confirmation
will then be transmitted back to the buyer.
[0355] The confirmation will be communicated back to the buyer as
an order status code. For example;
[0356] accepted orders=status code 1
[0357] amended orders=status code 2
[0358] rejected orders=status code 3
[0359] If the order is not accepted, the functionality below will
be required. In some circumstances, the seller may not be able to
fulfill the order as presented. The seller/administrator has two
options:
[0360] amend the order
[0361] reject the order
[0362] Functionality to permit the seller/administrator to
change/amend the volume requested by the buyer in the original PO
is provided. The seller/administrator will select the `amend order`
button. Selection will enable the volume field to be changed. If
the order volume is changed, the amended order volume change must
be communicated back to the buyer's procurement module.
[0363] The data, therefore to be communicated back to the buyer's
procurement module is the changed volume and status code 2 data.
Once received by the buyer, existing functionality already
contained in the buy-side system is activated.
[0364] If the order is to be rejected, the seller/administrator
will select the `reject order` button. Selection will terminate the
transaction. This is communicated back to the buyer.
[0365] The data flows inherent in the order rejection function are
straight-forward. It requires that the appropriate status code;
ie., 3, be transmitted back to the buyer's procurement module.
[0366] Messages back to the buyer's procurement module 4 appear as
inbound PO confirmation functions. An order that has been accepted
by a sales module is communicated back to a procurement module as
an order having a status code=1, being a straight acceptance. The
buy-side administrator can view the order details and then proceed
with the `process order` function which will process the order back
into the buyer's ERP 37.
[0367] An amended order will be communicated back to the
procurement module as:
[0368] a status code 2 and
[0369] including the amended volume data
[0370] The amended order is communicated to the buyer/administrator
in the buyer-side `inbound notifications` screen as an `amended
purchase order` in the `inbound notifications` interface of the
procurement module. The buy-side administrator can view the order
details:
[0371] proceed with the `process order` function (which will
process the order back into the buyer's ERP), or;
[0372] terminate the order (and begin conventional non-online
discussions with supplier--this may involve breach of contract at
this stage and require manual intervention.
[0373] A rejected order will be communicated back to the buy-side
platform as a status code 3 rejection. The rejected order is
communicated to the buyer/administrator via the buyer-side `inbound
notifications` screen as a `a rejected purchase order`.
[0374] This will constitute a breach of contract and require manual
intervention.
[0375] Post-negotiation
[0376] In the post negotiation phase of the transaction, as
illustrated in FIG. 10 various ancillary transaction pre-conditions
and requirements must be satisfied before the core contract is
executed. Negotiated contract requirements must be co-ordinated and
performed before the movement of goods can occur.
[0377] The core contract has terms and conditions negotiated
between the parties to a sales contract. These may include:
[0378] parties to the contract,
[0379] description of the goods,
[0380] volume
[0381] price
[0382] payment terms
[0383] The terms upon which payment is to be made from the buyer to
the seller is the link between the core contract and several
related contracts are likely to be made with third parties.
Although these related sub-contracts facilitate the ultimate
execution of the core contract, this core contract is of course
executed according to the payment terms specified in the core
contract. In essence, proper execution of the sub-contracts
effectively act as "conditions" to the core contract, and must be
satisfied by the appropriate party.
[0384] These appropriate parties are respectively involved in
various post-negotiation functions. These include:
[0385] transport and shipping
[0386] insurance
[0387] inspection
[0388] credit and banking
[0389] In a mechanistic sense, if the satisfaction of the core
conditions which correspond to each of the sub-contracts is
incorporated within an automated business process in a logical
manner, the sequential satisfaction of the sub-contracts can be
viewed as a lock-and-key mechanism. This sequence can be formatted
in a manner to ensure that the automated process does not occur
without the proper checks and balances having taken place.
[0390] The lock and key logic underlying the automation of the
post-transaction consolidation process is also critical to
establishing the precise point at which the risk of loss, ownership
title and payment obligations pass from the seller to the
buyer.
[0391] Taken one step further this is also the precise point in the
automation process at which a direct interface with external
"digital" banking systems can be established and, in accordance
with contractual terms, instructions to shift funds from the buyer
to the seller can occur.
[0392] Finally, the above also implies that it is this point in the
business process at which financial data can be allocated within
the business process back into the buyer and seller's internal
financial management and accounting systems.
[0393] Prior to the negotiation, the buyer inputs information
relating to its identity. In addition, by selecting a product, key
product information is identified by the system relating to the
precise identification and description of the goods the buyer
wishes to purchase. At the conclusion of the transaction
negotiation, offers submitted by the buyer will be either rejected
or accepted by the program. An offer that is accepted by the
program will contain all the core terms of the sales contract
being:
[0394] identities of the parties to the contract
[0395] identification of the subject matter of the contract
[0396] price, volume and payment terms
[0397] This information will be consolidated and form the content
of a proforma Invoice which the seller sends to the buyer to
confirm receipt of the order and acceptance of the terms offered.
All data is already stored or generated within the system.
[0398] At this point in the process, the core contract is concluded
and the influence of the several sub-contracts (mentioned above)
come into play.
[0399] As mentioned above, each of the sub-contracts performs an
important role and functions as "conditions" which must be
satisfied in the course of executing the terms of the core
contract.
[0400] In order to automate and coordinate the sequencing of
pre-shipment contractual requirements, embodiments of the invention
involve a post-transaction processing mechanism. The described
embodiment coordinates, integrates and sequences the consolidation,
generation and respective submission of a purchase order by the
buyer to the seller, and the issue of an invoice from the seller to
the buyer.
[0401] Under the rules of commercial trade (such as Incoterms 1990
and 2000 and the UCP 500), these conditions can also be arranged in
a sequential fashion. If these conditions are automated within a
process the proceeds in a stepwise fashion, the entire
post-transaction execution process can be logically and
systematically managed over time.
[0402] Unlike the transaction negotiation that can occur
instantaneously, a time element is introduced into the
post-transaction management functions. Each of the conditions can
be configured such that, in a stepwise fashion, the proper
satisfaction of each condition over time ensures that the core
contract conditions are recognised as having been systematically
satisfied by the system.
[0403] A post-transaction management system assists the user to
monitor the progress of the functions as they are entered or
activated within the system.
[0404] The post-negotiation process incorporates coordination
functions that are governed by:
[0405] the estimated time of departure (shipment of the product
from the contracted port or point of loading/shipment)
[0406] logistical aspects of the transaction must be coordinated
with the execution of agreed financing terms based on Incoterms
2000 and/or UCP 500.
[0407] The relationship between the logistics and shipping (by any
relevant mode of transport) and the connectivity with the payment
of that shipping function is the "trade trigger". The trade trigger
is of critical importance to both the seller and buyer, as it
determines the point in time within the contracted transaction
process in which title to the goods (and thus risk exposure) passes
from one party to another.
[0408] Depending on the terms of the core contract negotiated
between the parties, the fundamental conditions which may require
to be satisfied may include:
[0409] credit and finance
[0410] transport
[0411] insurance
[0412] inspection
[0413] FIG. 9 is a schematic diagram representing the relationship
between the procurement module 4 and the sales module 3 in respect
of purchase/sales order processing functions. This figure
illustrates the main categories of conditions which may require
satisfaction before execution of the core contract can be seen as
proceeding within the scope of the agreement.
[0414] Each of the oval figures in the diagram represents a
sub-contract condition which must be satisfied in the post
transaction phase of the process managed by the search module 2,
sales module 3 and processing module 4 of the system 1. Each of
these conditions, in turn, can be viewed as a "trigger". When
appropriate data is interfaced into the process, a condition is
satisfied which, in turn triggers the process to proceed to the
next condition.
[0415] The final step in the transaction execution process links
the sub-contract execution functions to a banking function. An
important step in the process is the issuance of the official
shipping document, the bill of lading or air weigh-bill. These
documents are viewed in law as being documents of title which
regulate the time at which risk of loss and passage of title to the
property occur relative to the terms of the core contract.
[0416] Passage of these documents between the shipper, seller and
buyer take on the added function of signalling the time at which
the right of the seller to receive payment from the buyer occurs.
The most important date is the date of issuance of the relevant
shipping document.
[0417] The point in the business process at which the actual
issuance time is entered into the system also represents that point
at which the buyer becomes legally obligated to make payment to the
seller (either now or at a future time). This importance of this
event is that automated banking functions can now be activated.
[0418] Each of the oval figures in the diagram represents a
sub-contract condition which must be satisfied in the post
transaction phase of the process. Each of these conditions, in
turn, can be viewed as a `trigger`. When appropriate data is
interfaced into the process, a condition is satisfied which, in
turn triggers the process to proceed to the next condition.
[0419] Data interfacing and integration is a central function of
the post-negotiation aspect of the described embodiment. The system
1 has been designed to reflect a logic that is influenced by two
underlying principles:
[0420] simple logic structures in order to permit easy data
manipulation and technical programming; while at the same time,
[0421] maximising process efficiency and accuracy.
[0422] The system functions by:
[0423] coordinating and combining data from internal and external
sources
[0424] processing data combinations and generating new data
[0425] consolidating simple data with generated outcomes
[0426] sequencing the data manipulation and coordination functions
according to time and other conditional factors
[0427] The system 1 performs the data interfacing and integration
functions described above by means of a central coordinating device
that controls data interface and data distribution timing and
sequencing. This device, in effect, controls the logic that drives
the system's internal functions as well as external systems and
users. Although the overall system 1 performs a number of discrete
operations, these operations are prompted or controlled by the
central coordinating mechanism which is, in turn, tied to data
interfacing.
[0428] In order for the overall system 1 to function properly, it
should ideally perform systematic data retrieval and storage
functions. These functions are made more complex given the
differing sources of data. The data used includes:
[0429] simple data which is not manipulated or transformed, but is
necessary to the transaction
[0430] system generated data (originating from simple data that is
transformed)
[0431] This data is entered from several system interfaces (or
sources). The data input via all interface sources is either stored
in database form (and is used at some future time) or is used in an
immediate processing function.
[0432] The sources of data are:
[0433] real-time data originating from user interfaces
[0434] system generated data originating from a
processing/computation function
[0435] data originating from interface with intranet systems
[0436] external data originating from interfacing with other
Internet sources
[0437] Given the various sources of data and the differing time
requirements for its use, the system performs and coordinates
numerous data prompting, retrieval and allocation functions. This
provides a foundation for the more complex integration functions
which are described below.
[0438] Whereas data sourcing and distribution is one
integration-related function, the system performs integration
functions that proceed at a higher level of complexity. At this
level, an underlying systems logic is used to combine technical
simplicity in the data configuration processes (described above)
with process efficiency considerations. It is at this level of the
integration process where business transaction logic is combined
with the invention's data logic.
[0439] Enterprise resource planning (ERP) systems are computer and
database management systems. ERP systems assist business
organizations by improving internal process efficiency by linking
databases that contain an organizations supply chain related
activities what the organisation's manufacturing planning, finance
and administration functions.
[0440] ERP systems do not allow for integration of information
relating to external business transactions.
[0441] The described embodiment of the system 1 includes an
interface mechanism that allows for the coordination of information
between "back-end" computing systems and "front-end" marketing and
transactional activities.
[0442] The interface component uploads relevant data from the host
systems:
[0443] product item master database
[0444] customer master database
[0445] manufacturing and planning master database
[0446] This uploaded data is consolidated and distributed to the
appropriate Internet modules; that is, product inventory/display
modules, transaction hub module.,
[0447] Further, the described embodiment of the system 1
consolidates and distributes data and information generated from
Internet functions including other support services.
[0448] In a business transactional sense, concluding a business
transaction can be viewed as a sequential process of satisfying a
series of inter-related, but necessary conditions. In a mechanical
sense, the process of achieving or satisfying the conditionality
requirements requires a stepwise and simultaneous:
[0449] generation of new data by the system's internal functions;
or the
[0450] selection and re-configuration of existing data;
[0451] which is then entered into the system in an appropriate and
logical time sequence to satisfy the necessary contractual
pre-conditions.
[0452] Although stated in simplistic terms above, this function
requires the integration of data from multiple data sources, a
transformation of some of that data as well as a re-ordering of
re-configured untransformed data with newly generated data
outcomes.
[0453] A third level of systems logic is now described. The two
stages described above involve data inputting and processing. The
results of these processes creates a new series of values
representing variables influencing new equilibrium conditions in
the post transaction stages of the process.
[0454] The new equilibrium conditions are reflected as data outputs
which must be properly allocated:
[0455] internally of the system
[0456] externally of the system but internally within a firm's
intranet systems
[0457] externally to other Internet systems
[0458] The timing and sequencing of the data output distribution
and allocation process is, in turn, influenced by functions
described as part of data interfacing, processing and integration
which simultaneously occur, or have already occurred.
[0459] It will be understood that the invention disclosed and
defined in this specification extends to all alternative
combinations of two or more of the individual features mentioned or
evident from the text or drawings. All of these different
combinations constitute various alternative aspects of the
invention.
* * * * *