Account settlement and financing in an e-commerce environment6629081Abstract A system, method and article of manufacture are provided for account settlement utilizing a network. First, a buyer is allowed to select from a group of options in order to settle an account utilizing a network. The options include settling a minimum balance, partially settling, settling a full balance, and applying for an import loan on payment due date. The selected option is then received utilizing the network. Finance interest may then be booked against the buyer for an unpaid portion of the account if the selected option includes either settling a minimum balance or partially settling. If the selected option includes settling a full balance, the account may be reconciled. On the other hand, if the selected option includes applying for an import loan on payment due date, an import loan may be booked and a credit line may be transferred to a trade loan line. Claims What is claimed is: Description FIELD OF THE INVENTION
TABLE 1
Trade Finance (Letters of Credit) VTrade
Buyer and seller trade settlement Buyer and seller trade settlement
through multiple intermediating through buyer's bank only
banks Document checking performed by
Heavily centered around documentary buyer, payment will be faster using
checking by multiple banks which VTrade Rules. Discrepancies will
slows down payment turnaround. be greatly reduced with trade
80% of trade documents are facilitation methods like electronic
"discrepant" and average order POPI and Document Checklist
to payment is around 9 months Process more streamlined because
Processes are cumbersome because POPI terms are simpler
letters of credit are more Cheaper because of
sophisticated disintermediation and streamlined
More expensive due to more parties processes
involved (more than 2 banks) and Payment through Visanet, which is
cumbersome processes cheaper
Payment is through SWIFT and other
more expensive payment network
Some of the benefits that the VTrade system offers an exporter include: Costs less than the traditional bank letter of credit product. Traditional banks LC cost the exporter from 25-50 basis points of the LC amount. VTrade eliminates amendment fees, discrepancy fees, SWIFT fees and Telex fees Reduces internal costs through a decrease in the use of paper, mail, and messenger/courier expenses. VTrade simply eliminates paper thereby streamlining the flow of the trade process Increases cash flow through faster payments. VTrade is integrated with banks to guarantee payments are transferred exactly according to the buyer/seller contract. Provides the potential to obtain better foreign exchange rates Assures greater accuracy, efficiency and information flows. VTrade connects all parties to a transaction thereby facilitating communication and information sharing. Increase sales potential through more competitive product pricing Permits direct control over trade process without an intermediary. VTrade allows the importer and the exporter to set the terms of their contract and control their own transaction VTrade allows the importer and the exporter to set the terms of their contract and control their own transaction. Some of the benefits that the VTrade system offers an importer include: Costs less than the traditional bank letter of credit product. Traditional bank LC cost 25-50 basis points of the LC amount Reduces internal costs through a decrease in the use of paper, mail, and messenger/courier expenses. VTrade simply eliminates paper thereby streamlining the flow of the trade process. Decreases turn-around-time (order-shipment-delivery) VTrade connects all parties to a transaction thereby facilitating communication and information sharing. Provides the potential to negotiate lower cost of goods from the exporter, since payment risks are eliminated. Permits direct control over the trade process without an intermediary. VTrade allows the importer and the exporter to set the terms of their contract and control their own transaction. FIG. 1 is a general depiction of a VTrade environment 100 based on Internet 102 utilization. A hub 104 controls and/or monitors operations and transactions in the environment, and particularly across the trade platform 106 between buyers 108 and sellers 110. Also included is a payment network 112. FIG. 2 is a diagram of the trade platform 106 over which buyer and seller processes take place in real time. In the VTrade enterprise 200, supply 202 is integrated with demand 204 to facilitate interaction and transaction between the buyer 108 and seller 110. FIG. 3 illustrates several eCommerce capabilities of the VTrade system, including eInformation Convergence 300, eProcurement 302, eBilling and eInvoicing 304, and eAuctioning 306. The general steps to set up the VTrade system are as follows: 1. Buyer registers and subscribes to VTrade 2. Credit Provider will assess the credit worthiness of the buyer and grant the appropriate trade finance credit line to the buyer 3. Buyer will receive the necessary security access to transact in VTrade 4. Register the buyer's suppliers with VTrade 5. Sellers will receive the necessary security access to transact in VTrade The general steps of a transaction in the VTrade system are: 1. Buyer and Seller negotiate terms 2. Buyer submit purchase order with the delivery, payment and other trade terms as agreed with the seller 3. Transaction routed to credit provider for credit approval if approval is required 4. Confirmation sent to Seller 5. Goods Shipped to Buyer 6. Buyer accepts goods. Payment released to Seller according to payment terms and debt is owed to the credit provider where credit is involved Table 2 illustrates the general roles of the parties in the VTrade system.
TABLE 2
Party Roles
Credit Provider Market VTrade to organisation which large
importers
Provide credit financing
Guarantee importer's credit worthiness
Syndicate credit requirements
Negotiate exporters' receivables
Provide FX services
Syndicate VTrade to insurance and shipping
companies
Syndicate VTrade to other banks
VTrade Enterprise Establish the VTrade Processing HUB and
business capability
Provide a secured environment for
transacting
Operate the VTrade Processing HUB
Develop the necessary infrastructure to
support the VTrade Processing
Market solution to Credit Provider
Assist Credit Provider in the marketing
process to importer, exporter, insurance
companies, shipping companies and etc
Provide Support parties in VTrade
Importer Subcribe to VTrade and transact all
intermediated trade transaction through
VTrade
Exporter Subcribe to VTrade and transact all
intermediated trade transaction through
VTrade
A preferred embodiment of a system in accordance with the present invention is preferably practiced in the context of a personal computer such as an IBM compatible personal computer, Apple Macintosh computer or UNIX based workstation. A representative hardware environment is depicted in FIG. 4, which illustrates a typical hardware configuration of a workstation in accordance with a preferred embodiment having a central processing unit 410, such as a microprocessor, and a number of other units interconnected via a system bus 412. The workstation shown in FIG. 4 includes a Random Access Memory (RAM) 414, Read Only Memory (ROM) 416, an I/O adapter 418 for connecting peripheral devices such as disk storage units 420 to the bus 412, a user interface adapter 142 for connecting a keyboard 424, a mouse 426, a speaker 428, a microphone 422, and/or other user interface devices such as a touch screen (not shown) to the bus 412, communication adapter 424 for connecting the workstation to a communication network (e.g., a data processing network) and a display adapter 426 for connecting the bus 412 to a display device 428. The workstation typically has resident thereon an operating system such as the Microsoft Windows NT or Windows/95 Operating System (OS), the IBM OS/2 operating system, the MAC OS, or UNIX operating system. Those skilled in the art will appreciate that the present invention may also be implemented on platforms and operating systems other than those mentioned. A preferred embodiment is written using JAVA, C, and the C++ language and utilizes object oriented programming methodology. Object oriented programming (OOP) has become increasingly used to develop complex applications. As OOP moves toward the mainstream of software design and development, various software solutions require adaptation to make use of the benefits of OOP. A need exists for these principles of OOP to be applied to a messaging interface of an electronic messaging system such that a set of OOP classes and objects for the messaging interface can be provided. OOP is a process of developing computer software using objects, including the steps of analyzing the problem, designing the system, and constructing the program. An object is a software package that contains both data and a collection of related structures and procedures. Since it contains both data and a collection of structures and procedures, it can be visualized as a self-sufficient component that does not require other additional structures, procedures or data to perform its specific task. OOP, therefore, views a computer program as a collection of largely autonomous components, called objects, each of which is responsible for a specific task. This concept of packaging data, structures, and procedures together in one component or module is called encapsulation. In general, OOP components are reusable software modules which present an interface that conforms to an object model and which are accessed at run-time through a component integration architecture. A component integration architecture is a set of architecture mechanisms which allow software modules in different process spaces to utilize each others capabilities or functions. This is generally done by assuming a common component object model on which to build the architecture. It is worthwhile to differentiate between an object and a class of objects at this point. An object is a single instance of the class of objects, which is often just called a class. A class of objects can be viewed as a blueprint, from which many objects can be formed. OOP allows the programmer to create an object that is a part of another object. For example, the object representing a piston engine is said to have a composition-relationship with the object representing a piston. In reality, a piston engine comprises a piston, valves and many other components; the fact that a piston is an element of a piston engine can be logically and semantically represented in OOP by two objects. OOP also allows creation of an object that "depends from" another object. If there are two objects, one representing a piston engine and the other representing a piston engine wherein the piston is made of ceramic, then the relationship between the two objects is not that of composition. A ceramic piston engine does not make up a piston engine. Rather it is merely one kind of piston engine that has one more limitation than the piston engine; its piston is made of ceramic. In this case, the object representing the ceramic piston engine is called a derived object, and it inherits all of the aspects of the object representing the piston engine and adds further limitation or detail to it. The object representing the ceramic piston engine "depends from" the object representing the piston engine. The relationship between these objects is called inheritance. When the object or class representing the ceramic piston engine inherits all of the aspects of the objects representing the piston engine, it inherits the thermal characteristics of a standard piston defined in the piston engine class. However, the ceramic piston engine object overrides these ceramic specific thermal characteristics, which are typically different from those associated with a metal piston. It skips over the original and uses new functions related to ceramic pistons. Different kinds of piston engines have different characteristics, but may have the same underlying functions associated with it (e.g., how many pistons in the engine, ignition sequences, lubrication, etc.). To access each of these functions in any piston engine object, a programmer would call the same functions with the same names, but each type of piston engine may have different/overriding implementations of functions behind the same name. This ability to hide different implementations of a function behind the same name is called polymorphism and it greatly simplifies communication among objects. With the concepts of composition-relationship, encapsulation, inheritance and polymorphism, an object can represent just about anything in the real world. In fact, one's logical perception of the reality is the only limit on determining the kinds of things that can become objects in object-oriented software. Some typical categories are as follows: Objects can represent physical objects, such as automobiles in a traffic-flow simulation, electrical components in a circuit-design program, countries in an economics model, or aircraft in an air-traffic-control system. Objects can represent elements of the computer-user environment such as windows, menus or graphics objects. An object can represent an inventory, such as a personnel file or a table of the latitudes and longitudes of cities. An object can represent user-defined data types such as time, angles, and complex numbers, or points on the plane. With this enormous capability of an object to represent just about any logically separable matters, OOP allows the software developer to design and implement a computer program that is a model of some aspects of reality, whether that reality is a physical entity, a process, a system, or a composition of matter. Since the object can represent anything, the software developer can create an object which can be used as a component in a larger software project in the future. If 90% of a new OOP software program consists of proven, existing components made from preexisting reusable objects, then only the remaining 10% of the new software project has to be written and tested from scratch. Since 90% already came from an inventory of extensively tested reusable objects, the potential domain from which an error could originate is 10% of the program. As a result, OOP enables software developers to build objects out of other, previously built objects. This process closely resembles complex machinery being built out of assemblies and sub-assemblies. OOP technology, therefore, makes software engineering more like hardware engineering in that software is built from existing components, which are available to the developer as objects. All this adds up to an improved quality of the software as well as an increased speed of its development. Programming languages are beginning to fully support the OOP principles, such as encapsulation, inheritance, polymorphism, and composition-relationship. With the advent of the C++ language, many commercial software developers have embraced OOP. C++ is an OOP language that offers a fast, machine-executable code. Furthermore, C++ is suitable for both commercial-application and systems-programming projects. For now, C++ appears to be the most popular choice among many OOP programmers, but there is a host of other OOP languages, such as Smalltalk, Common Lisp Object System (CLOS), and Eiffel. Additionally, OOP capabilities are being added to more traditional popular computer programming languages such as Pascal. The benefits of object classes can be summarized, as follows: Objects and their corresponding classes break down complex programming problems into many smaller, simpler problems. Encapsulation enforces data abstraction through the organization of data into small, independent objects that can communicate with each other. Encapsulation protects the data in an object from accidental damage, but allows other objects to interact with that data by calling the object's member functions and structures. Subclassing and inheritance make it possible to extend and modify objects through deriving new kinds of objects from the standard classes available in the system. Thus, new capabilities are created without having to start from scratch. Polymorphism and multiple inheritance make it possible for different programmers to mix and match characteristics of many different classes and create specialized objects that can still work with related objects in predictable ways. Class hierarchies and containment hierarchies provide a flexible mechanism for modeling real-world objects and the relationships among them. Libraries of reusable classes are useful in many situations, but they also have some limitations. For example: Complexity. In a complex system, the class hierarchies for related classes can become extremely confusing, with many dozens or even hundreds of classes. Flow of control. A program written with the aid of class libraries is still responsible for the flow of control (i.e., it must control the interactions among all the objects created from a particular library). The programmer has to decide which functions to call at what times for which kinds of objects. Duplication of effort. Although class libraries allow programmers to use and reuse many small pieces of code, each programmer puts those pieces together in a different way. Two different programmers can use the same set of class libraries to write two programs that do exactly the same thing but whose internal structure (i.e., design) may be quite different, depending on hundreds of small decisions each programmer makes along the way. Inevitably, similar pieces of code end up doing similar things in slightly different ways and do not work as well together as they should. Class libraries are very flexible. As programs grow more complex, more programmers are forced to reinvent basic solutions to basic problems over and over again. A relatively new extension of the class library concept is to have a framework of class libraries. This framework is more complex and consists of significant collections of collaborating classes that capture both the small scale patterns and major mechanisms that implement the common requirements and design in a specific application domain. They were first developed to free application programmers from the chores involved in displaying menus, windows, dialog boxes, and other standard user interface elements for personal computers. Frameworks also represent a change in the way programmers think about the interaction between the code they write and code written by others. In the early days of procedural programming, the programmer called libraries provided by the operating system to perform certain tasks, but basically the program executed down the page from start to finish, and the programmer was solely responsible for the flow of control. This was appropriate for printing out paychecks, calculating a mathematical table, or solving other problems with a program that executed in just one way. The development of graphical user interfaces began to turn this procedural programming arrangement inside out. These interfaces allow the user, rather than program logic, to drive the program and decide when certain actions should be performed. Today, most personal computer software accomplishes this by means of an event loop which monitors the mouse, keyboard, and other sources of external events and calls the appropriate parts of the programmer's code according to actions that the user performs. The programmer no longer determines the order in which events occur. Instead, a program is divided into separate pieces that are called at unpredictable times and in an unpredictable order. By relinquishing control in this way to users, the developer creates a program that is much easier to use. Nevertheless, individual pieces of the program written by the developer still call libraries provided by the operating system to accomplish certain tasks, and the programmer must still determine the flow of control within each piece after it's called by the event loop. Application code still "sits on top of" the system. Even event loop programs require programmers to write a lot of code that should not need to be written separately for every application. The concept of an application framework carries the event loop concept further. Instead of dealing with all the nuts and bolts of constructing basic menus, windows, and dialog boxes and then making these things all work together, programmers using application frameworks start with working application code and basic user interface elements in place. Subsequently, they build from there by replacing some of the generic capabilities of the framework with the specific capabilities of the intended application. Application frameworks reduce the total amount of code that a programmer has to write from scratch. However, because the framework is really a generic application that displays windows, supports copy and paste, and so on, the programmer can also relinquish control to a greater degree than event loop programs permit. The framework code takes care of almost all event handling and flow of control, and the programmer's code is called only when the framework needs it (e.g., to create or manipulate a proprietary data structure). A programmer writing a framework program not only relinquishes control to the user (as is also true for event loop programs), but also relinquishes the detailed flow of control within the program to the framework. This approach allows the creation of more complex systems that work together in interesting ways, as opposed to isolated programs, having custom code, being created over and over again for similar problems. Thus, as is explained above, a framework basically is a collection of cooperating classes that make up a reusable design solution for a given problem domain. It typically includes objects that provide default behavior (e.g., for menus and windows), and programmers use it by inheriting some of that default behavior and overriding other behavior so that the framework calls application code at the appropriate times. There are three main differences between frameworks and class libraries: Behavior versus protocol. Class libraries are essentially collections of behaviors that you can call when you want those individual behaviors in your program. A framework, on the other hand, provides not only behavior but also the protocol or set of rules that govern the ways in which behaviors can be combined, including rules for what a programmer is supposed to provide versus what the framework provides. Call versus override. With a class library, the code the programmer instantiates objects and calls their member functions. It's possible to instantiate and call objects in the same way with a framework (i.e., to treat the framework as a class library), but to take full advantage of a framework's reusable design, a programmer typically writes code that overrides and is called by the framework. The framework manages the flow of control among its objects. Writing a program involves dividing responsibilities among the various pieces of software that are called by the framework rather than specifying how the different pieces should work together. Implementation versus design. With class libraries, programmers reuse only implementations, whereas with frameworks, they reuse design. A framework embodies the way a family of related programs or pieces of software work. It represents a generic design solution that can be adapted to a variety of specific problems in a given domain. For example, a single framework can embody the way a user interface works, even though two different user interfaces created with the same framework might solve quite different interface problems. Thus, through the development of frameworks for solutions to various problems and programming tasks, significant reductions in the design and development effort for software can be achieved. A preferred embodiment of the invention utilizes HyperText Markup Language (HTML) to implement documents on the Internet together with a general-purpose secure communication protocol for a transport medium between the client and the Newco. HTTP or other protocols could be readily substituted for HTML without undue experimentation. Information on these products is available in T. Berners-Lee, D. Connoly, "RFC 1866: Hypertext Markup Language--2.0" (November 1995); and R. Fielding, H, Frystyk, T. Berners-Lee, J. Gettys and J. C. Mogul, "Hypertext Transfer Protocol--HTTP/1.1: HTTP Working Group Internet Draft" (May 2, 1996). HTML is a simple data format used to create hypertext documents that are portable from one platform to another. HTML documents are SGML documents with generic semantics that are appropriate for representing information from a wide range of domains. HTML has been in use by the World-Wide Web global information initiative since 1990. HTML is an application of ISO Standard 8879; 1986 Information Processing Text and Office Systems; Standard Generalized Markup Language (SGML). To date, Web development tools have been limited in their ability to create dynamic Web applications which span from client to server and interoperate with existing computing resources. Until recently, HTML has been the dominant technology used in development of Web-based solutions. However, HTML has proven to be inadequate in the following areas: Poor performance; Restricted user interface capabilities; Can only produce static Web pages; Lack of interoperability with existing applications and data; and Inability to scale. Sun Microsystem's Java language solves many of the client-side problems by: Improving performance on the client side; Enabling the creation of dynamic, real-time Web applications; and Providing the ability to create a wide variety of user interface components. With Java, developers can create robust User Interface (UI) components. Custom "widgets" (e.g., real-time stock tickers, animated icons, etc.) can be created, and client-side performance is improved. Unlike HTML, Java supports the notion of client-side validation, offloading appropriate processing onto the client for improved performance. Dynamic, real-time Web pages can be created. Using the above-mentioned custom UI components, dynamic Web pages can also be created. Sun's Java language has emerged as an industry-recognized language for "programming the Internet." Sun defines Java as: "a simple, object-oriented, distributed, interpreted, robust, secure, architecture-neutral, portable, high-performance, multithreaded, dynamic, buzzword-compliant, general-purpose programming language. Java supports programming for the Internet in the form of platform-independent Java applets." Java applets are small, specialized applications that comply with Sun's Java Application Programming Interface (API) allowing developers to add "interactive content" to Web documents (e.g., simple animations, page adornments, basic games, etc.). Applets execute within a Java-compatible browser (e.g., Netscape Navigator) by copying code from the server to client. From a language standpoint, Java's core feature set is based on C++. Sun's Java literature states that Java is basically, "C++ with extensions from Objective C for more dynamic method resolution." Another technology that provides similar function to JAVA is provided by Microsoft and ActiveX Technologies, to give developers and Web designers wherewithal to build dynamic content for the Internet and personal computers. ActiveX includes tools for developing animation, 3-D virtual reality, video and other multimedia content. The tools use Internet standards, work on multiple platforms, and are being supported by over 100 companies. The group's building blocks are called ActiveX Controls, small, fast components that enable developers to embed parts of software in hypertext markup language (HTML) pages. ActiveX Controls work with a variety of programming languages including Microsoft Visual C++, Borland Delphi, Microsoft Visual Basic programming system and, in the future, Microsoft's development tool for Java, code named "Jakarta." ActiveX Technologies also includes ActiveX Server Framework, allowing developers to create server applications. One of ordinary skill in the art readily recognizes that ActiveX could be substituted for JAVA without undue experimentation to practice the invention. FIG. 5 illustrates a process 500 for affording a virtual trade financial framework. First, in operation 502, an agreement is established between a buyer and a seller for trading purposes. In operation 504, initiation and payment documents are received utilizing a network. Also received, in operation 506, are secondary documents such as an insurance certificate, inspection certificate, certificate of origin, invoice/declaration, counselor's invoice, sanction and boycott declaration, packing list, weight list, lab test report, and/or beneficiary certificate. Thereafter, the secondary documents are sent to a bank to be checked in operation 508. When operating, the buyer accesses the secondary documents via the bank. FIG. 6 illustrates a variation of the process of FIG. 5. In one embodiment of the present invention, the secondary documents are received via a facsimile transmission. Further, the initiation and payment documents may include a combined purchase order proforma invoice. As an option, the secondary documents may be stored, indexed and matched. In another embodiment of the present invention, the secondary documents include an insurance certificate, inspection certificate, certificate of origin, invoice/declaration, counselor's invoice, sanction and boycott declaration, packing list, weight list, lab test report, and beneficiary certificate. FIG. 7 illustrates operation of a virtual trade financial framework 700. At 702, a buyer 704 applies for a line of credit through the buyer's bank 706. The buyer and seller 708 get together and agree to trade on VTrade at 710. At 712, the buyer creates an electronic sales agreement. At 714, the buyer and seller agree on the sales agreement. VTrade stores transmitted documents, such as emails, presentation, and facsimiles, at 716. At 718, VTrade facilitates payment release through a payment network. The buyer's bank consolidates a bill and bills the buyer at 720. FIG. 8 depicts optional enhancements that may be offered and performed during operation of the virtual trade financial framework 700 of FIG. 7. Such enhancements can include allowing online auctions 800, integration to third parties 802, and linkages to online procurement sites 804. Online credit applications 806 may be permitted, as may integration to other payment network(s) 808. FIG. 9 illustrates several areas which VTrade will fulfill in the eCommerce value chain. Such areas include provider access 900, customer service 902, market making 904, buyer agency 906, customer access 908, risk management 910, and fulfillment 912. FIG. 10 depicts a process flow of the VTrade framework. At 1000, the buyer creates an electronic purchase order, which is used to create a combined purchase order proforma invoice. The buyer and seller approve the combined purchase order proforma invoice at 1002. As an option, the seller may contract for carriers, providers, etc. for aspects relating to the goods being traded. At 1006, the trade documents are sent to VTrade, which are then stored and indexed at 1008. A check of the documents may also be made to ensure that all necessary documentation has arrived, etc. At 1010, the buyer can check the documents online. The buyer's bank pays for the goods over an interface with VTrade at 1012 and sends a consolidated statement to the buyer at 1014, after which the buyer pays the bank at 1016. FIG. 11 illustrates a process for application of a line of credit and access to the VTrade system for a buyer. In operation 1100, the buyer's (applicant) application for credit is sent to the bank. In operation 1102, the application is processed at the credit provider (bank). The new credit and VTrade enrollment information is registered and sent to the buyer in operations 1104 and 1106, respectively. In operation 1108, a VTrade card is sent to the buyer, as is acknowledgement of enrollment and receipt of the credit information in operation 1110. FIG. 12 illustrates a process for application for access to the VTrade system by a seller/merchant 1200. Numbers 1-7 enumeration the steps of the process. FIG. 13 is a flowchart of a process 1300 for initiating bidding in a virtual trade financial environment. In operation 1302, a form is submitted to a plurality of buyers providing details on products or services available from a plurality of sellers. This is to prompt the submission of bids on the products or services. Such forms can include paper documents, facsimiles, emails, etc. The bids are then received from the buyers 1304 utilizing a network. Thereafter, in operation 1306, the bids are categorized based on a predetermined criteria. The categorized bids are subsequently sent to the sellers in operation 1308 utilizing the network. In operation 1310, offers are received from the sellers in response to the bids utilizing the network. The offers are displayed to the buyers in operation 1312 and the transactions between the buyers and the sellers are closed in operation 1314. In one embodiment of the present invention, an identity of the buyers is authenticated prior to submitting the form thereto. The identity is authenticated by requiring the submission of an identifier and a password. As an option, the step of categorizing the bids may include ranking or segmenting the bids. In another embodiment of the present invention, the criteria may include a geography and/or product category. Further, the bids and offers may be displayed on a site on the network. FIG. 14 expands on the bidding process of the VTrade system discusses above with reference to FIG. 13. In operation 1400, VTrade bid forms are sent to buyers to invite bids. The bids received from the buyers are captured and sorted in operation 1402. In operation 1404, interested sellers are permitted to receive the bid forms online and view them and then, in operation 1406, are allowed to submit competitive bid offers. These bid offers are captured in operation 1408 and sent to the appropriate buyers. Operations 1402 through 1408 can be repeated until a buyer or seller accepts a bid. After the buyers review the sellers' offers, interested buyers' manifestations of intent to transact are captured and transmitted to the sellers in operations 1410 and 1412, which closes the bidding. FIG. 15 is a flowchart illustrating a process 1500 for initiating a transaction in a virtual trade financial framework. In operation 1502, an agreement between a buyer and a seller is established for trading purposes. A form is then received in operation 1504 indicating terms or conditions of the buyer. In response to the receipt of the form, a credit of the buyer is checked using a third party in operation 1506. The credit check is performed based on the form. In operation 1508, the seller is provided with the form and an indication as to the sufficiency of the credit of the buyer. A response to the form and indication is subsequently received from the seller in operation 1510. Such response of the seller is forwarded to the buyer in operation 1512. In one embodiment, the agreement between the buyer and the seller may include payment terms. Further, an identity of the buyer may be authenticated prior to receiving the form. As an option, the identity may be authenticated by requiring the submission of an identifier and a password. In another embodiment, the seller may be requested to become a registered member of the framework. As an option, the agreement may be finalized after forwarding the response of the seller to the buyer. FIG. 16 is a flow diagram which expands on the process of FIG. 15. In operation 1600, it is determined that a buyer and seller have agreed to transact on VTrade. In operation 1602, an invoice, in this example a purchase order proforma invoice (POPI), is received from the buyer and authenticated before being sent to the seller. See the discussion of FIGS. v23 and 21 below for a description of the POPI. A request for a credit check is sent to the bank (or credit provider) in operation 1604. The buyer's credit line is also earmarked in operation 1606 to indicate the amount of the purchase order to prevent the buyer from exceeding the maximum amount of credit. In operation 1608, the seller is alerted to start negotiating on the invoice. The initiation of negotiation is confirmed in operation 1610. The buyer is alerted that the seller acknowledges the transaction in operation 1612. In operation 1614 and 1616, a negotiation about the invoice is facilitated and, when negotiations cease, the invoice is finalized. FIG. 17 is a flow diagram for initiation of a transaction between a buyer 1700 and seller 1702 using combined purchase order proforma invoice submission. Numerals 1-8 set forth the order of the process. FIG. 18 illustrates a process for a payment transaction during a trade. In operation 1800, trade documents are received from the seller. In operation 1802, goods are shipped for the seller. The documents from the seller are stored and indexed online and made available for the buyer to view in operation 1804. Upon receiving a request from the buyer, the documents are displayed to the buyer in operation 1806. Payment authorization is also received from the buyer, upon which, in operation 1808, a diligence check is made or requested in order to initiate payment. The amount of the payment is calculated in operation 1810. In operation 1812, proceeds from a credit drawdown are sent to the seller. All trade documents are released to the buyer in operation 1814 and the buyer is allowed to take delivery of the goods in operation 1816. FIG. 19 illustrates a payment process when there is no disagreement on the terms of the documents. Reference numerals 1-7 provide the order of the steps of the process. FIG. 20 depicts a payment process when there is a disagreement on the terms of the documents. Reference numerals 1-7 provide the order of the steps of the process. FIG. 21 depicts a process for account settlement and/or financing for a buyer (importer) in the VTrade system. Reference numerals 1-5 provide the order of the steps of the process. FIG. 22 illustrates a payment process when a direct transfer of funds is available. Numbers 1-6 set forth the order of the steps of the process. FIG. 23 is a flowchart illustrating a process 2300 for completing a purchase order/invoice. In operation 2302, an initial version of a form is received from the buyer indicating at least one requirement for the seller to fulfill. The seller is then allowed to amend the form in operation 2304 thus generating a revision of the form. Such version of the form that is received by the seller is then saved in operation 2306. Likewise, the buyer is then allowed to amend the form in operation 2308 thus generating a revision of the form. Such version of the form that is received by the buyer is then saved in operation 2310. In operation, the various versions of the form are made available for editing and use until there are no further amendments, and the purchase order/invoice is complete. See operations 2312,2314. In one embodiment, the amendments include changing terms of the form. Further, the form may include a combined purchase order proforma invoice. As an option, the form may include a first section indicating a plurality of terms, a second section indicating requirements of the buyers with respect to the terms, and a third section indicating requirements of the sellers with respect to the terms. In another embodiment of the present invention, the form is automatically sent to a database utilizing a network in response to the buyer and seller signing the form. As an option, commercial shipping documents may be created utilizing input from the seller. FIGS. 24A and 24B illustrate an illustrative Purchase Order Performa Invoice (POPI) v2300. The Purchase Order Proforma Invoice allows a buyer to submit an application to initiate a transaction in VTrade electronically on VTrade Web. The Buyer indicates the performance by seller or requirement for seller to fulfill via POPI. The buyer submits the POPI to VTrade after completing all terms/performance required of the seller. Buyer's bank checks and earmarks buyer's VTrade line of credit (LOC). Once the LOC is earmarked by the bank, confirmation is sent to seller by VTrade. A confirmed/interested seller will negotiate sales/purchase terms with buyer using the POPI. The seller will indicate fulfillment of the buyer's requirements on a Combined Purchase Order Proforma Invoice. If the seller cannot fulfill the buyer's requirement, the buyer and seller will amend the POPI until agreeable terms are achieved. The buyer and seller can submit each amendment on POPI via the submit pushbutton v2302,v2304. Each amendment by trading parties on POPI will be reflected as a new version. The VTrade Web allows old versions of amendments to be stored and viewed. Once the POPI is finalized, the buyer and seller signs agreement on overall terms and conditions of POPI which automatically triggers POPI to be sent to VTrade. The seller then proceeds to prepare commercial/trade documents for payment. FIG. 25 depicts a combined Purchase Order Performa Invoice 2500. The Combined Purchase Order Proforma Invoice allows buyer to submit application to initiate transaction in VTrade over VTrade Web. The buyer indicates a requirement for the seller to fulfill on the Combined Purchase Order Proforma Invoice. The buyer submits Combined Purchase Order Proforma Invoice to VTrade after completing requirements. VTrade checks and earmarks buyer's line of credit. Once the line is earmarked by bank, confirmation is sent to the seller. The seller will indicate fulfillment of the buyer's requirements on the Combined Purchase Order Proforma Invoice. If the seller cannot fulfill the buyer's requirement, the buyer and seller will amend the Combined Purchase Order Proforma Invoice until agreeable terms are achieved. Each amendment by the trading parties on Combined Purchase Order Proforma Invoice will be reflected as a new version. VTrade Web allows old versions of amendments to be viewed. Once agreement is reached on the Combined Purchase Order Proforma Invoice, the buyer and seller sign the agreement on overall terms and conditions of the Purchase Order Proforma Invoice which automatically triggers a purchase order to be sent to VTrade. The seller then proceeds to prepare commercial shipping documents (option of using VTrade Electronic Document Creator). FIG. 26 is a flowchart depicting a process 2600 for creating a finalized document relating to a transaction. In operation 2602, a buyer and a seller are allowed to negotiate terms of an agreement. A form detailing the negotiated terms is displayed in operation 2604. The buyer and seller may digitally sign the form in operation 2606. Documents supporting the form are organized and stored in operation 2608. In operation 2610, payment to the seller is initiated only after receiving a verification of credit of the buyer. In one embodiment of the present invention, the form may include a first section indicating the terms, a second section for allowing the buyer to sign off on the terms, and a third section for allowing the buyer to sign off on the terms. As an option, the form may be displayed after the negotiation of the terms in response to the selection of an icon. In another embodiment, the documents supporting the form may be displayed. As an option, the form may be automatically sent to a database utilizing a network in response to the buyer and seller finishing the signing of the form. Further, the payment may be completed only after checking the form and the receipt of payment authorization from the buyer. FIG. 27 illustrates the Main Menu Page of an electronic document checklist 2700 which may be used during the process of FIG. 26. The Electronic Document Creator (Main Menu) is the front page for the VTrade Electronic Document Creator. It is essentially a deal sheet for the buyer and seller to sign on once agreement is reached on all documents. The buyer and seller negotiate on terms of a transaction using the document creator. By pressing on the icon 2702 next to the documents indicated, buyer/seller is linked to the next layer which is the Electronic Document Creator (Document Page). Once there is agreement on the terms of a particular document (refer Document Creator), buyer and seller `digitally signs` by selecting an icon 2704 next to the related document on the main menu page. The Document Creator (Main Menu) also help track receipt of other related physical documents outside VTrade. Scan or `mirror copies` of these documents can be viewed but they are not checked by VTrade Once agreement is reached on all documents between buyer and seller, both sign an agreement on overall terms and conditions of the Document Creator before submission to VTrade. The VTrade Enterprise digitally checks that all electronic documents submitted are collected and waits for payment authorization from the bank/buyer before using the payment interface to contact Visanet for payment to seller. FIG. 28 is a flowchart illustrating a process 2800 for creating a financial transaction-related document. In operation 2802, a buyer is allowed to select among a plurality of documents associated with a proposed transaction. In operation 2804, the buyer is permitted to indicate requirements of trade terms relating to the selected documents. A seller may agree or amend the terms on an electronic document platform in operation 2806. Upon each amendment, a new version of a form delineating the trade terms is generated in operation 2808. In operation 2810, each of the versions maybe viewed. In one embodiment of the present invention, the trade terms may include shipping related terms. As an option, the terms of the form may be filtered, so that the form may be outputted with only the terms included after filtering for various purposes. As an option, standard documents associated with the form may be generated to be used with the form during the transaction. In another embodiment, the form may include a first section indicating a plurality of shipping terms, a second section indicating requirements of the buyers with respect to the terms, and a third section indicating fulfillment of the terms by the seller. FIG. 29 illustrates a Document Page 2900 of an electronic document creator. The Electronic Document Creator provides the seller with the option of creating commercial shipping documents electronically. The document creator allows buyer to indicate the requirements of the trade terms and seller to agree or amend the terms on an electronic document platform. Both buyer and seller can access Document Page from the Menu page. The buyer and seller will negotiate only on the documents selected by the buyer on the VTrade Document Creator (Main Menu). The VTrade document creator will have defined parameters and structured format within which only the most common trade requirements and information are included. Each amendment for the document creator will be captured on a new version. Document Creator allows for old versions to be viewed. Once terms and conditions is agreed on the document-level, buyer and seller will sign-off on the icon next to the respective document on the Document Creator (Main Menu) page. The VTrade Document Creator will allow creation of standardized documents (which could mirror the Generic Electronic Credit Instrument guideline currently being developed by the ICC Working Party). FIG. 30 depicts an electronic Documents Checklist 3000. The Document Checklist is an online document checking facilitation list which allows the buyer to view and check the trade documents submitted by seller on-line via the VTrade Web. By pressing on the icon 3002 next to the documents indicated, the buyer is linked to the next layer which is the stored documents submitted to VTrade. Once an agreement is reached on all documents, the buyer signs agreement on overall terms and conditions of Document Checklist. If discrepancies are found by buyer, it is to be noted on the discrepancies column 3004 next to the respective documents in which the corresponding discrepancies are found. The buyer will sign on the checklist once all documents are checked. FIG. 31 illustrates a VTrade compliance engine 3100. The compliance engine has a fully-automated compliance checking capability built into the VTrade Web solution, which comprises the VTrade Web front page, the front-end Combined Purchase Order Proforma Invoice and the Electronic Document Creator, all linked to bank and customer's back-end processing systems. An automatic check is triggered once Seller and Buyer signs off digitally on Main Menu of Document Creator for overall agreement (all terms of documents required by Buyer is agreed, including physical documents checked outside of VTrade). Two types of automated compliance check are performed simultaneously: i) Combined Purchase Order Proforma Invoice 3102 against transportation document (Bill of Lading, Airwaybill, Truck BL) ii) Cross commercial shipping documents check The compliance checking is performed through data validation on defined parameters of structured formats for text. Once the compliance engine finds all structured fields/tag are in compliance (clean), an automatic signal is sent to the bank/buyer for payment authorization. When payment authorization is received, the signal will prompt Visanet to credit the seller's account. Anytime the value of the data falls outside the parameter of the structured field, it is rejected as `discrepant.` The rejection will be automatically sent and highlighted to both buyer and seller electronically. Only upon the completion of all checks of structured fields will discrepancy signal be sent to buyer and seller, who will renegotiate on the highlighted discrepancies on VTrade Web's electronic platform FIG. 32 illustrates a first option of documentary compliance in a VTrade system. Here, only VTrade 3200 checks the electronic documents. (Assume only Combined Purchase Order Proforma Invoice and transportation documents require checking.) FIG. 33 illustrates a second option of documentary compliance in which the Bank 3300 checks physical documents while VTrade 3302 checks electronic documents. FIG. 34 illustrates a third option of documentary compliance in which the buyer 3400 checks physical documents while VTrade 3402 checks electronic documents. FIG. 35 illustrates a general architecture of the VTrade system, including a buyer station 3500, a seller station 3502, a processing hub 3504, and a credit provider system 3506. FIG. 36 illustrates an exemplary technical framework for a VTrade system. As shown, the VTrade enterprise 3600 is connected to the external world 3602, which is where the buyers and sellers are located. The enterprise is also connected to the payment system 3604. FIG. 37 illustrates several potential security threats, including viruses 3700, and internal attacks 3702. FIG. 38 illustrates security features which may be used with the technical framework of the VTrade system. Such features include encryption 3800, authentication 3802, and firewalls 3804. FIG. 39 illustrates several security principles 3900 and the services 3902, 3904, 3906 which provide them. A VTrade system should provide the following security features: Authentication--No one can pretend to be someone else Privacy--Only authorised people and systems can access information. This includes privacy both during transport on the network and against unauthorised insiders Non-repudiation--Users are prevented from denying that they authorised the transaction Transaction Integrity--This ensures that stored or transmitted information in VTrade is unaltered Non-refutability--This ensures that users can verify that the actual exchange took place by providing a digital receipt or similar proof of payment Time stamping--This is especially important for responding to duties with a actionable deadline Security Components: Signature/validation: allow the sender to sign its message before sending them and to validate its signature Encryption/decryption of on-line transaction: allow the sender to encrypt the messages he wants to send in order to keep its content secret Authentication: confirming the identity of parties involved in the transaction Firewall and network security: establishing a barrier between the VTrade corporate network (secure network) and the external Internet (untrusted network). Only VTrade Members is granted access from outside based on user names and passwords, Internet IP address, or domain name Integrity: confirmation that the content of a message has not been altered Non-repudiation: the signer cannot deny the signing of the message Confidentiality: relevant information is kept secret, only the receiver is able to decode the encrypted message in the original plain text Interoperability with other eCommerce Operating Models Participation in a world-wide certification hierarchy Cross certification with other certification authorities Security deployment on the Internet Exchange of third party services on transactions VTrade should operate under some group of recognized rules, preferably rules that are enforceable in foreign countries. FIG. 40 illustrates an embodiment of the present invention in which VTrade operates under applicable Visa Card and international commerce rules 4000,4002, with an avenue for dispute resolution via the ICC international court for arbitration. FIG. 41 illustrates a legal framework 4100 when the rules are set by the VTrade Enterprise. These rules may apply to both the buyer and seller. All legal contracts outside the VTrade rules should also be established between parties. FIG. 42 depicts the legal responsibilities of VTrade 4200 and the Bank 4202. FIG. 43 illustrates the legal responsibilities of the buyer 4300 and seller 4302. VTrade may provide a forum for buyers and sellers to settle unresolved disputes through VTrade Rules. The handling of disputes under Traditional Trade Finance can be governed by rules in UCP 500 and URC 522 issued by the International Chamber of Commerce (ICC). Both UCP 500 and URC 522 contain a complex set of rules relating the documents in International Trade. VTrade, may have its own set of rules which govern the underlying goods similar to how credit card rules for retail transactions. In traditional trade finance, disputes can be settled bringing the case to the ICC International Court of Arbitration or to the courts under the normal law of contracts. Similarly, VTrade can provide a similar avenue of resolving disputes under VTrade rules. Under traditional Trade Finance, the process of refusal of acceptance occurs when the importer refuses acceptance of the document giving him rights to the title of the goods. This can happen under two different situations: (1) Where the LC is confirmed by the exporter's bank The confirming bank will pay the exporter as it had confirmed that the documents were in order. The confirming bank will then settle the disputes with the importer through the issuing bank. Failing which, the confirming bank will take the case to either the International Court of Arbitration or the courts. (2) Where the LC is not confirmed. The exporter will seek redress from the issuing bank. Failing which the exporter will take the case to the International Court of Arbitration or the court with the issuing bank and the importer as defendants. Under VTrade, the process of refusal of acceptance occurs when the importer refuses acceptance of the goods. The exporter will seek redress from the Credit Provider who provided the guarantee that payment will made when the goods are shipped according to the purchase order. The exporter can bring the case to the International Court of Arbitration to decide whether the exporter had met the terms of the purchase order. If the International Court of Arbitration holds judgment for the exporter, the Credit Provider will make payment to the exporter and seek recourse from the importer. FIGS. 44-52 depict an illustrative process flow for operation of the VTrade system with the steps organized in columns associated with the party performing or directing the step, i.e., a buyer 4400, buyer's bank 4402, VTrade 4404, seller's bank 4406, and a seller 4408. FIG. 44 shows a process for credit application and access, which continues at A in FIG. 45. FIG. 46 depicts a process for initiation of bidding. FIGS. 47 and 48 illustrate a process for submission of a VTrade POPI. FIG. 49 depicts a process for negotiation and finalization of the POPI. FIGS. 50 and 51 illustrate a process for facilitation of document checking during payment. FIG. 52 illustrates a process for account billing and VTrade account management. As such, the embodiments set forth above allow business-to-business commerce and eMarkets. Several factors that are driving the adoption of business to business commerce are: Increasing Competition and Globalization Global search for inexpensive goods and services extends beyond traditional boundaries Internet enables procurement on global scaleGrowing Interactivity Internet spurs growing interactivity among companies and their trading partners Access to, and free flow of, information allows more informed decisionsFinancial Opportunity Growing trade creates lucrative opportunity for eMarket makers and infrastructure enablers Efficiencies and Cost Savings Online markets reduce transaction times and costs Reduces "paid/get paid" cycle time Extended Market and Customer Reach Access to buyers/sellers outside traditional trading circles and geographic reach Real-time Solutions Online markets mimic true supply and demand for goods/services Allows for dynamic, active management of business needs and resources Regulatory and Taxation Issues Markets are currently not heavily regulated or taxed by the federal government eMarketplaces offer buyers and sellers a new way to locate, engage, and transact online as traditional trading practices give way to new business models. Comparing eMarketplaces to traditional methods: eMarketplacesRestrictive vendor/supplier relationships Maintain (or even shrinks) trading base Focuses on historical experience Limited to physical reach of supply chain and partners Drive out proprietary supply chain inefficiencies Drive price transparency and product standardization with exclusive trading partners Exciting methods are mostly virtualization of traditional practices Examples Extranets VANs (Value-added Networks) EDI Intermediaries (middlemen) Traditional MethodsBring together large numbers of buyers and sellers Expand current trading base Identify new markets for products Cross/expand geographic and supply chain boundaries Drive out market and industry wide inefficiencies Drive price transparency and product standardization Force new business models on the Web Examples Aggregators Auctions Exchanges As shown in FIG. 53, eMarketplaces can take three basic forms which intend to serve different market functions. These forms are: Aggregator 5300: A one-stop shopping venue. It streamlines purchasing by concentrating many product catalogs for buyer groups Examples: Arbinet, Chemdex, MetalSite, NetBuy, PlasticsNet, ProcurementNet, TPN Register "Can help me procure supplies at the lowest price" Auction 5302: A mechanism for liquidating surplus at best possible prices. It enables a wide range of potential buyers to bid competitively for products at below market prices. Reverse auctions (Bids) can also exist where buyers post or submit product needs and sellers bid for that sale Examples: iMark, FastParts, Inventory Locator Service, Manheim Online, ONSALE "Can help me unload excess inventory at the best price" Exchanges 5304: An industry spot market for commodity-like products where price and quality are known between counterparties. It fills last minute needs for a small group of industry players with preexisting trading relationships Examples: Altra Energy, Marex, QuickTrade, RateXchange, ChemConnect "Can help me meet immediate needs in commoditized products" The three emerging online marketplaces serve the basic functions of bringing buyers and sellers together online to easily exchange value, provide content, and form a community. As shown in FIG. 54, these three marketplaces may be brought together to create an eMarketplace 5400. eMarketplaces can target either vertical market segments or horizontal market needs. Vertical Description Provide deep industry-specific content Provide domain-specific relationships and contacts Community focus oriented Characteristics Usually founded or backed by experienced industry personnel Usually found in inefficient supply chains where many intermediaries exist Early movers win as key suppliers are locked up early Offer discussion forums and chat rooms CattleOfferings.com (agriculture) Horizontal Description Spans across industry segments Product focus orientation Characteristics Created by individuals with deep process knowledge or work-flow automation experience Multiple product offerings Usually found where high degrees of process standardization has occurred Have diverse revenue sources and opportunities The present invention is preferably practice in the context of a vertical market. Players with common needs will naturally look to deep vertical eMarketplaces that cater to their specific needs. Therefore, horizontal hubs will be challenged to directly provide members with targeted industry knowledge and focused offerings. Further, fast movers will lock up key suppliers early making room in many market segments for only one player Characteristics of a dynamic eMarketplace include: Liquid market Transparent pricing Detailed product information Efficient, cost effective transaction capability Information on members and counterparties Clear and detailed rules and policies Transactions initiated and consummated online As shown in FIG. 55, an eMarket 5500 is supported by a technical infrastructure 5502. To reach their potential, electronic markets must offer key capabilities that span from "making the market" to supporting the infrastructure. FIG. 56 is a table setting forth descriptions of elements of the infrastructure including software/solutions 5600, IT 5602, fulfillment 5604, and financial services/risk management 5606. In addition to having attractive forums of exchange, electronic exchanges must also provide content and support the creation of communities. Content includes developing information which allows users to develop a strong understanding of what they're trading and with whom. Examples include historical price/volume data, product/service information, and buyer/seller credit ratings. Community includes providing information about related subject areas to members and allow them to exchange experiences. Examples include chat room, industry news, how-to's, and community contacts Commerce includes creating a regulated forum for trade. Examples include open/closed trading rooms, multi-dimensional tradeoffs (price/time), and real-time order matching or auction. Electronic exchanges must also provide support services to facilitate trading. These are preferably part of the infrastructure. Several needs should be addressed in order to offer a complete eMarketplace. FIG. 57 is a table setting forth a process to create solutions to specific needs during a buy and sell process. In operation 5700, the needs of the buyer and seller are identified and evaluated. In operation 5702, options are weighed. Negotiation and contract trading are allowed in operation 5704. Finally, a settlement is managed in operation 5706. FIG. 58 illustrates another embodiment of the process for creating solutions to specific needs during a buy and sell process. In operation 5800, the needs of the buyer and seller are identified and evaluated. In operation 5802, options are weighed. Negotiation and contract trading are allowed in operation 5804. Finally, a settlement is managed in operation 5806. One embodiment of the present invention offers an integrated package of eEnabled financial services products in one or more of the five categories shown in FIG. 59. These categories are: reputation assessment 5900, financing 5902, risk management 5904, ePayments 5906, and information 5908. FIG. 60 illustrates a TradeDirect system 6000 in accordance with one embodiment of the present invention. TradeDirect includes an infrastructure 6002 which can be utilized by any number of business to business eMarketplaces. TradeDirect also provides online counterparty reputation assessment tools, financing, risk management tools, an ePayments facility, and information sources. TradeDirect automates research, contracting, and fulfillment in business to business eMarketplaces. FIG. 61 illustrates how TradeDirect may connect to outside firms to provide a wide breadth of services, such as those found in FIG. 62. Referring to FIG. 61, TradeDirect 6100 is connected to a plurality of eMarkets 6102, and may be connected to a payments network 6104, credit rating agency 6106, and a technology enabler 6108. TradeDirect should offer products in one or more of the areas of FIG. 62 to support business to business exchanges. The areas include: credit ratings and reporting 6200, trade financing 6202, risk management 6204, settlement 6206, and information 6208. TradeDirect will allow corporate customers to gain comfort regarding the quality of their counterparties before engaging in online business to business trades. FIG. 63 illustrates a process 6300 for affording credit rating and reporting utilizing a network. In operation 6302, transactions between a plurality of buyers and sellers are facilitated by offering a plurality of services. Such services may include allowing the buyers and the sellers to negotiate terms of the transactions via a site on a network, exchanging forms indicating the negotiated terms utilizing the network, assessing a credit of the buyers by interfacing banks associated with the buyers, and/or initiating payment from the buyers to the sellers. During the delivery of such services, a history associated with the transactions is generated in operation 6304. The history associated with the transactions is stored in a database in operation 6306. In operation 6308, the identity of the buyers and the sellers may be authenticated utilizing the network, which allows the buyers and the sellers to access to the history of other buyers and sellers in operation 6310. In one embodiment of the present invention, the history may be supplemented with information on the buyers and sellers received from third parties. As an option, the history of the buyers and the sellers may include ratings received from other buyers and sellers. Further, the history of the buyers and the sellers may incorporate records of problems occurring during the delivery of the services. Optional credit rating and reporting services which may be offered include: Bank credit rating TradeDirect will compile credit ratings of member firms through the banks which are part of the TradeDirect network Member posted ratings TradeDirect will allow firms to post ratings of the counterparties they have dealt with TradeDirect credit history TradeDirect will compile a credit history of firms which have used the TradeDirect system Third party credit rating TradeDirect will draw data from third party providers of credit ratings Authentication TradeDirect will authenticate participants using digital certificates Some of the benefits these services will provide for buyers, sellers, and for transacting, include: Buyers Gain comfort regarding the products ordered Increase confidence in counterparty Sellers Gain comfort regarding the receipt of payment Increase confidence in counterparty Exchanges Increase volume because barrier to usage is diminished Potentially increase revenues through service charge Pre-approved lines of credit and online decisioning will streamline financing and guarantee payment. FIG. 64 is a flowchart of a process 6400 for approving a line of credit of a buyer utilizing a network. In operation 6402, requests are received from a plurality of buyers for credit approval utilizing a network. In response to the requests, the credit of the buyers are assessed in operation 6404 by interfacing banks associated therewith. A predetermined amount of credit is awarded to the buyers in operation 6406. In operation 6408, the buyers are allowed to negotiate terms of transactions with a plurality of sellers utilizing the network. Thereafter, in operation 6410, payment is initiated from the buyers to the sellers. In operation 6412, the sellers are provided with a guarantee on the payment up to the predetermined amount of credit. In one embodiment of the present invention, the sellers are provided with the credit assessment when the terms of the transactions are being negotiated by the buyer and the seller. As an option, during the negotiation of the terms of the transactions, request may be received from the buyers for an increase in credit utilizing the network. The credit of the buyers may be again assessed by interfacing banks associated therewith in response to the requests. Further, an increased predetermined amount of credit may be granted to the buyers. The sellers are then provided with a guarantee on the payment up to the increased predetermined amount of credit. In another embodiment of the present invention, forms indicating the negotiated terms may be exchanged utilizing the network. Further, the buyers may be optionally allowed to negotiate terms of the transactions with the sellers utilizing a site on the network. Optional trade finance services which may be offered include: Buyer financing Purchasing cards and lines of credit to provide pre-approved credit to accepted applicants Inventory and lease financing Seller financing Factoring to finance short-term receivables Forfeiting for non-recourse financing of longer-term receivables Real-time credit decisioning Real-time credit decisions will allow financing offer to be made at the point of need Some of the benefits these services will provide for buyers, sellers, and for transacting, include: Buyers Save time with pre-approved financing Save money with lower financing costs than letters of credit Potentially negotiate lower cost of goods from seller since payment is guaranteed Sellers Reduce credit risk because payment is guaranteed Easily manage cash flow as required Exchanges Increase volume because barrier to usage is diminished Increases member entanglement Potential referral revenue TradeDirect may provide products with which buyers and sellers can minimize the risk of trading. Optional risk management services which may be offered include: Foreign exchange TradeDirect will exchange currencies at rates better than those available to most members Insurance Insurance will be offered for shipping, warehousing, etc. Hedging instruments Derivatives and options will be offered on foreign exchange rates, commodity prices, etc. Some of the benefits these services will provide for buyers, sellers, and for markets, include: Buyers Save time setting up ancillary agreements on-line from one source Reduce direct expenses due to purchasing power of TradeDirect Sellers Save time setting up ancillary agreements on-line from one source Reduce direct expenses due to purchasing power of TradeDirect eMarketplaces Potentially increase revenues through referral income Increase member entanglement TradeDirect may automate most elements of payments and trade settlement. FIG. 65 is a flowchart illustrating a process 6500 for affording a settlement function utilizing a network. In operation 6502, a buyer and a seller are allowed to negotiate terms of a transaction via a site on a network. The terms include an amount of payment and a time frame thereof. Forms indicating the negotiated terms are then exchanged between the buyer and the seller in operation 6504 utilizing the network. By interfacing a bank associated with the buyer, a credit of the buyer is assessed in operation 6506. If the credit assessment is successful, payments are periodically executed from the buyer to the seller in operation 6508 per the terms of the transaction. The payments are executed automatically by accessing the bank associated with the buyer and authorizing payments to the seller. Upon each execution of a payment, the buyer is sent electronic receipts via the network in operation 6510. In one embodiment, evidence of the periodically executed payments is stored for later verification. Further, the seller may be sent electronic notices via the network upon each execution of a payment. As an option, risk associated with the transaction may be reduced by offering insurance. Optional settlement services which may be offered include: ePayments TradeDirect will provide a seamless global ePayment capability by leveraging an existing payments network; offerings include payment cards, ACH, SWIFT, and wire transfer Straight through processing Enable "straight-through processing" through integration with seller's accounts receivable and buyer's accounts payable systems Electronic bill presentment Bills will reliably be presented and paid in the agreed time frame electronically and in full Electronic shipping documentation Document management will be carried out digitally Some of the benefits these services will provide for buyers, sellers, and for exchanges, include: Buyers Receive goods more quickly due to faster turnaround time Eliminate time consuming paper handling Reduce transaction costs and time required to complete payment processing Increase accuracy of document processing Sellers Receive payment more quickly Eliminate time consuming paper handling Reduce transaction costs and time required to complete payment processing Increase accuracy of document processing Exchanges Higher volume due to increased attractiveness of exchange trading Potentially increase referral income One embodiment of the present invention makes information available online to help buyers and sellers make informed decisions, negotiate contracts, and structure these in accordance with relevant negotiations. According to this embodiment, FIG. 66 is a flowchart that illustrates a process 6600 for affording information services while facilitating a transaction between a buyer and a seller utilizing a network. A buyer and a seller are first allowed to negotiate payment terms of a transaction involving goods via a site on a network in operation 6602. In operation 6604, the payments terms and goods are compared with other payments terms and goods utilizing the network. Such comparison is also displayed. In operation 6606, access may also be had to a database of forms utilizing the network. The buyer and seller are allowed to complete the forms to reflect the negotiated terms utilizing the network in operation 6608. Rules and regulations relating to the goods may also be displayed in operation 6610. In order to further the transaction, in operation 6612 payment is initiated from the buyer to the seller utilizing the network. In one embodiment of the present invention, information may be displayed on procedures involving the goods utilizing the network. Information may also be displayed on current events involving the goods utilizing the network. As an option, risk associated with the transaction may be reduced by offering insurance. In another embodiment of the present invention, the buyer and the seller may be allowed to negotiate other terms of the transaction such as the volume of goods, delivery window, delivery location, and delivery mode. Optional information services which may be offered include: Payments and trade information Regional and product-specific trade rules and regulations will be available on-line Decision support tools Tools will be available online to compare product offerings and payment terms Contracts Purchase orders and proforma invoice templates will be available online Some of the benefits these services will provide for buyers, sellers, and for exchanges, include: Buyers Save time researching needed information Enables more informed decisions Provides help regarding specific procedures which must be followed Sellers Compare offers more quickly and accurately Exchanges Increase volume because barrier to usage is diminished Potentially increase revenues through referral income FIG. 67 is a flowchart depicting a process 6700 for contracting and fulfilling a business to business trade utilizing a network according to one embodiment of the present invention. In operation 6702, a buyer and a seller are allowed to negotiate terms of a transaction via a site on a network until an agreement is reached. hi operation 6704, the buyer and the seller are prompted to confirm a form reflecting the negotiation terms of the transaction that have been agreed upon. Such confirmed form is stored in a database. Documents which support the transaction are received in operation 6706 utilizing the network. Such documents are stored in the database in operation 6708. The form and the documents in the database may be checked in operation 6710 based on a predetermined set of rules using a rule-based engine. Further, in operation 6712, funds may be released to the seller upon the form and the documents being successfully checked. In one embodiment of the present invention, the form is a combined purchase order proforma invoice. As an option, a freight shipper and/or an insurer may be contracted to become involved in the transaction. In another embodiment of the present invention, authorization may be received from the buyer before the funds are released. Further, a consolidated statement may be sent to the buyer. FIG. 68 illustrates a process for allowing buyers 6800 and sellers 6802 to gather information about each other. Reference numerals 1-4 set forth the order of the operations of the process. FIG. 69 is a flowchart that depicts a process 6900 for a credit application process. In operation 6902, a credit application is received from a buyer utilizing a network. In response to the receipt of the credit application, the credit application is sent to a bank via the network in operation 6904. This is for assessing the credit of the buyer based on the credit application. If the credit is approved, the buyer is registered in operation 6906 by assigning an identifier thereto. Next, in operation 6908, a password is generated for the buyer. The identifier and the password are then stored in a database in operation 6910. Thereafter, in operation 6912, the buyer is sent the password utilizing the network. In operation, the buyer may use the password and identifier to initiate transactions on the network. In operation 6914, the buyer is issued a card reflecting the identifier. In one embodiment, the card is delivered to the buyer by courier. A notice is then sent to the bank upon receipt of the card by the buyer. As an option, the credit application may include financial statements of the buyer. Further, the step of assessing the credit of the buyer may include approving a credit limit, and setting up a line of credit. FIG. 70 illustrates a process for screening a buyer 7000 before credit is given to the buyer by a credit provider 7002. The operations which carry out the process are enumerated in order by numerals 1-6. FIG. 71 depicts a process for allowing a company to guard against risk before entering into a trade by allowing purchase of a risk management product. The operations which carry out the process are enumerated in order by numerals 1-5. FIG. 72 is a flowchart illustrates a process 7200 for initiation of an agreement utilizing a network. In operation 7202, a buyer and a seller are allowed to negotiate terms of trade utilizing a network. A form is received from the buyer in operation 7204 indicating the terms of trade utilizing the network. Also received utilizing the network in operation 7206 is an identifier of the buyer. Thereafter, the form is sent to a bank in operation 7208 for assessing the credit of the buyer utilizing the network. The bank to which the credit application is sent is based on the identifier. Next, in operation 7210, the form is forwarded to a seller along with the assessment of the credit of the buyer. In operation 7212, the seller is permitted to digitally sign the form utilizing the network. The digitally signed form is received from the seller in operation 7214 utilizing the network, after which a notice is sent to the buyer in operation 7216 indicating that the digitally signed form has been received from the seller, thus initiating the agreement. In one embodiment of the present invention, an identity of the buyer is authenticated prior to sending the form to the bank. Such identity may be authenticated by requiring the submission of an identifier and a password. In another embodiment of the present invention, the credit of the seller may be verified. As an option, the form may include a combined purchase order proforma invoice. FIG. 73 illustrates a process for initiating a transaction which includes an ePayment. The operations which carry out the process are enumerated in order by reference numerals 1-6. FIG. 74 illustrates a process 7400 for order fulfillment utilizing a network. In operation 7402, a buyer and a seller are permitted to negotiate terms of a transaction utilizing a network. In operation 7404, a form is received from the seller or the buyer utilizing the network. Such form is created based on the transaction terms and identifies a forwarding agent that receives a product associated with the transaction from the seller for the purpose of delivering the same to the buyer. Payment is then initiated to the seller for the product in operation 7406. This is accomplished by interfacing a bank utilizing the network. A notice is sent to the forwarding agent in operation 7408 upon the finalization of the payment for the purpose of releasing the product to the buyer. In one embodiment, a plurality of documents which support the transaction are received from the buyer. As an option, at least a portion of the documents may be forwarded to the bank for payment authorization purposes. Further, it may be confirmed that the documents are received within a predetermined time period. Still yet, the documents may be forwarded to the bank for facilitating the finalization of the payment. Optionally, the documents may be scanned and forwarded to the bank utilizing the network. FIG. 75 illustrates a process for a transaction in which a buyer 7500 sends an ePayment sent through TradeDirect. The operations which carry out the process are enumerated in order by reference numerals 1-6. FIG. 76 is a flowchart of a process 7600 for performing a direct fund transfer utilizing a network. In operation 7602, a buyer and a seller are allowed to negotiate payment terms of a transaction utilizing a site on a network after which the seller ships goods associated with the transaction to the buyer. In operation 7604, an identity of the buyer is authenticated utilizing the network after which, in operation 7606, an indication is received from the buyer to pay the seller for the goods on the network. Thereafter, in operation 7608, a database is queried in order to retrieve payment information related to the buyer. The present invention then interfaces a bank in operation 7610 utilizing the network for effecting payment to the seller based on the payment information and the payment terms. In one embodiment, the payment information may include an identifier for the bank and an associated account identifier. As an option, the direct fund transfer may be carried out by a party separate from the bank, the buyer, and the seller. In another embodiment, the buyer and the seller are allowed to negotiate payment terms of a transaction using a chatroom. Further, the identity of the buyer may be authenticated using a password. FIG. 77 illustrates a process for open accounts information in accordance with an embodiment of the present invention. Reference numerals 1-6 set forth the order of the operations of the process. FIG. 78 is a flowchart illustrating a process 7800 for account settlement utilizing a network. In operation 7802, a buyer is allowed to select from a group of options in order to settle an account utilizing a network. The options include settling a minimum balance, partially settling, settling a full balance, and applying for an import loan on payment due date. The selected option is then received in operation 7804 utilizing the network. In operation 7806, finance interest may be booked against the buyer for an unpaid portion of the account if the selected option includes either settling a minimum balance or partially settling. If the selected option includes settling a full balance, the account may be reconciled in operation 7808. On the other hand, if the selected option includes applying for an import loan on payment due date, an import loan may be booked and a credit line may be transferred to a trade loan line. In one embodiment of the present invention, ownership of goods may be released to the buyer by transferring title thereto if the selected option includes either settling a minimum balance or partially settling. As an option, a consolidated card statement may be sent to the buyer utilizing the network. In another embodiment of the present invention, a third party who reconciles the account may be engaged if the selected option includes settling a full balance. FIG. 79 illustrates a process for financing or settling an account according to one embodiment of the present invention. Reference numerals 1-5 set forth the order of the operations of the process. FIG. 80 illustrates a process for procuring information during the course of a transaction in accordance with an embodiment of the present invention. Reference numerals 1-4 set forth the order of the operations of the process. Development Framework (IDEA) FIG. 81 is an illustration of the Integrated Development Environment Architecture (IDEA) that may be used to create a system for implementing the foregoing embodiments. The Integrated Development Environment Architecture provides a development environment framework and associated guidelines that reduce the effort and costs involved with designing, implementing, and maintaining an integrated development environment. IDEA takes a holistic approach to the development environment by addressing all three Business Integration components: organization, processes, and tools. The development environment is a production environment for one or several systems development projects as well as for maintenance efforts. It requires the same attention as a similarly sized end-user execution environment. The purpose of the development environment is to support the tasks involved in the analysis, design, construction, and maintenance of business systems, as well as the associated management processes. The environment should adequately support all the development tasks, not just the code/compile/test/debug cycle. Given this, a comprehensive framework for understanding the requirements of the development environment can be used. Another reason for the comprehensive framework is that it is important to get the development environment right the first time. Changing the development environment when construction is fully staffed entails serious disruptions and expensive loss of productivity. Experience has shown that within the same medium- to large-size project, with the same people, moving from a poor to a good development environment, productivity is improved by a factor of ten for many tasks. The improvements come in two categories: The elimination of redundant and non value-added tasks The streamlining of useful tasks While it seems intuitive that most tasks can be streamlined, the following list gives a few examples of redundant tasks that must be eliminated: Analysis to determine how to merge the uncoordinated changes applied by two programmers to the same module Re-entry of the source code and retesting of a module, which was accidentally deleted Recurring discussions about "what a design packet should contain" or "what constitutes good programming style in a particular context" Repeated design, coding, testing, and maintenance of very similar logic (for example, error handling, date conversion and manipulation, main structure of a module) Searching for the manuals of a particular productivity tool to find information Remigration to system test of a cycle, because the impact analysis for a change request was incomplete Requesting support from another team (for example, environment support, information management) and waiting unnecessarily for a response On a smaller project, these problems can be solved using a brute force approach. This becomes very expensive as the project grows, and finally impossible. A well-designed development environment becomes important as the project team reaches 20-30 people and is absolutely critical with a project size of more than 50 people. The investment required to design, set up, and tune a comprehensive, good development and maintenance environment is typically several hundred development days. Numbers between 400 and 800 days are commonly seen, depending on the platforms, target environment complexity, amount of reuse, and size of the system being developed and maintained. Development Organization Framework FIG. 82 is an illustration showing a Development Organization Framework in accordance with one embodiment of the present invention. When designing a business application, it is crucial to keep in mind the organization that will use the system. The same is true of the development environment. The development organization's size, structure, experience, and maturity should strongly influence the choice of tools and the way the tools are integrated. If this link is not understood, the benefit of tool support will be minimal in many areas, and may significantly reduce productivity. In the same way, when a new business capability is introduced, it is crucial to keep in mind the needs for training and organizational change that which may accompany the technical change. This is also true of the development environment. When a new development environment is put in place, the developers need to learn not only how each individual tool works (for example, how to use the compiler), but also how the tools work together to support the organization as it performs well defined processes. T | ||||||
