DETAILED DESCRIPTION OF SPECIFIC EMBODIMENTS

[0042] The present invention is directed to the modeling of supply chains. More specifically, the present invention is directed to the modeling and optimization of the means of determining the need for purchase, manufacture or sale of goods, the contract management, goods storage, transportation and inventory management, price and cost tracking, and the collaboration tools necessary to transport a good from its origin to its final point of sale, exchange or consumption.

[0043] 1. Overall Architecture

[0044] The architecture of the system 100 of the present invention is comprised of three inter-communicating layers: technical, business, and client. Each layer provides specific functionality pertaining to technical, business or client services. Further, each layer comprises other logical components that provide functional services. Each of the functional services can communicate with each other over a communication network. Alternatively, all of the functional services and/or layers can reside on one physical device. The communication is achieved through specific interfaces.

[0045] The present invention is composed of a set of objects, in the form of an object engine, that operate in a multi-tiered environment in order to implement business logic of various types. In the preferred embodiment of the present invention, the objects of the present invention provide various functions called business services and operate in the business services layer. Basic functionality for the objects of the present invention is provided by the technical services layer. Various user interfaces may be used to observer and/or control various aspects of the object engine, and those user interfaces are generally grouped together to form a client services layer.

[0046] FIG. 1 illustrates the overall application architecture. Specifically, the client services 102 has an integrated controls interface 104, an integrated forms interface 106, an external data inter-exchange interface 108, a data cache 110, and a preferences interface 112. The various interfaces and caches of the client services 102 communicate with the business services 120 via distributed object protocol 118. The business services 120 contains a trading aspect 122, a risk management aspect 124, a scheduling aspect 126, an accounting aspect 128, a route network aspect 130, an organization aspect 132, and a support aspect 134. The business services 120 derive or use elements of the technical services 140. For example, the technical services 140 include persistence capability 142, transaction support services 144, synchronization module 146, messaging module 148, history module 150, life cycle management module 152, security module 154, and scheduler 156. The above-described architecture is illustrative of the present invention. However, alternate architectures that employ some or all of the functionality listed above may be employed without departing from the spirit of the present invention. Moreover, additional services may be added, or existing services removed, from the present invention with a corresponding increase or decrease in the scope of the system to accommodate owner requirements.

[0047] The objects, aspects, modules, interfaces and services of the system 100 of the present invention can utilize various communication protocols and standards. For example, object-to-object communication may employ COM, DOM, CORBA, SOAP, XML, or any other protocol or combinations of communication protocols and techniques. The specific communication protocol is not important to the present invention. Instead, it is the structure and arrangement of the objects within the business services layer 120 that enables the present invention to accommodate and implement business logic that mirrors, controls and/or mimics a real-life supply chain.

[0048] The object engine within the business services layer 120 of the present invention is structured in a way that enables the implementation of business logic associated with supply chains. Not only do the objects of the business services layer 120 implement the business logic, but they are structured in such a way as to be re-configurable to accommodate any business logic—even during execution of the business processes. This enables the present invention to reconfigure ongoing processes to reflect and accommodate changes in the structure and operation of supply chains.

[0049] The present invention consists of a set of objects that are unique in their construction as well as their configuration. Typically, objects enrich behavior in accumulative fashions by means of polymorphism as well as aggregation. This accretive nature has been enhanced in the objects of the present invention objects by careful consideration to maintaining the autonomy of individual objects as well as incremental feature growth in total. This allows the unique capability of the present invention to deliver multi-faceted behavior from various objects in different contexts. Moreover, it enables the objects of the present invention to present an emergent behavior of the complete supply chain for observation by operators or other processes.

[0050] Aggregate objects usually combine the behavior of “dependent” member objects. However, a “dependent” member object in the present invention would generally be architected to deliver the aggregate behavior that is desired in that particular application, yet be able to effectively reuse the same “dependent” object in an entirely independent context. For example, if an entity consists of a parent and multiple line items, those line items (dependents) would be constructed such that they could be accessed and used regardless of any “parent” association.

[0051] Architectural object autonomy as described herein translates into a remarkable ability to reuse by combining and modifying object properties (data) and behavior (methods) dynamically. Coupled with a strict compartmentalized insulation between the business logic (e.g., server) and the presentation (e.g., client) layers, this permits the application to present a virtually infinite combination of incarnations and configurations. For every possible combination or variance of data needs, a new user-interface form can be assembled to meet those specific needs. Such user-interface forms would be nothing more than a presentation channel in the purest form. The actual work—the business logic and processing—would be handled by one consistent set of core business objects. The use of a consistent set of core business objects of the present invention permits different individuals to work from their customized views and to use the data model to best suit their needs.

[0052] Ease of feature accrual by the present invention lends itself to unparalleled capabilities in terms of enhancements and upgrades. When users request new features, the same set of core business objects can be combined in different configurations in an easy manner to add the incremental feature sets, and thus deploy the revised application quickly and with minimal debugging. The synergistic approach afforded by the object architecture of the present invention is important to solving the supply chain management problem in a virtual-reality setting, because the objects are meant to model reality closely. The architecture of the objects of the present invention permits the arbitrary addition of features and modules with the utmost of ease. Not only is the end to end supply chain addressed, but the present invention is able to accommodate any business domain challenge with minimal enhancement to the core business objects.

[0053] The present invention provides tools that assist in the simulation of supply chain models and the monitoring of real-life supply chain operations. Some of the unique features of this system that differentiates it from other systems are described below.

[0054] Automated Two-Way Feedback

[0055] Typically, simulation systems of any operational business process provide a mechanism to analyze the results of a simulation based on hypothetical model parameters. Generally, there is no real-time feedback mechanism that allows, in an automated fashion, to input real-life operational-model parameters into the simulation model and integrate them with hypothetical-model parameters. In contrast, the system 100 of the present invention allows for analysis of simulation models within the context of supply chain using real-life operational data as well as user-defined hypothetical data. Additionally, when real-life operational data changes, the present invention enables those data changes to be reflected in the simulated business model.

[0056] Process Independence

[0057] The present invention recognizes that business processes change dynamically, based upon business conditions and evolving organizational constraints. The present invention encompasses a system 100 that allows for the specification and the customization of business processes for atomic units and groups of business tasks. The present invention does not force the business processes to change based upon the system's implementation. Rather, the present invention allows for dynamic application of business processes and respective business rules that govern the processes to units of business tasks.

[0058] Cross-Functional Independence

[0059] The present invention is designed for cross-functional independence within the context of a supply chain. The cross-functional independence afforded by the present invention allows for the deployment of business functional components that are independent of each other so that the components can be used in conjunction as well as in an independent, stand-alone functionality. In addition, specific processes within the business functional components are also independent under the present invention. The independent style of object architecture enables the implementation of flexible business rules, yet, enforcing them when specified. For example, contracts can be initiated even when trade negotiations are not finalized while the import of such a trade cascades to other depended business tasks (if any). However, if the contract is not executed in time, the propagated impact is rolled back to the pre-implementation state.

[0060] Cross-Functional Integration

[0061] The present invention integrates with other inter/intra/extra-organizational business functions in order to ensure that changes in depended data are automatically reflected in user functions. Moreover, changes are validated based on user-defined business rules per atomic business tasks.

[0062] Integrating “Corridor” Conversations with Business Data

[0063] The present invention supports persistence and integration of any ad-hoc operational conversations that may impact one or more business units. The preferred embodiment of the system 100 of the present invention provides a communication interface that allows users to communicate and to share unformatted operational data. The communication interface of the present invention allows users to capture and to analyze business transactions that are based on both structured and unstructured data. Further, the communications associated with the business transactions can be attached to business tasks data for ready reference.

[0064] The architecture of the object engine of the present invention is capable of substantial rearrangement of both properties, methods, and organizational structure without departing from the ability to implement the business logic in a consistent manner, and to accommodate changes to that business logic in a dynamic manner. A detailed description of an illustrative embodiment of the system 100 of the present invention is provided below. It should be noted that numerous alternate embodiments of the present invention are possible, and that the following description is not meant to indicate an exhaustive list of possible equivalents that are within the scope and spirit of the present invention.

[0065] 2. Technical Services

[0066] Overview

[0067] Technical services 140 include infrastructure support for the business services 120 and the client services 102. The overall system 100 is designed and engineered to interface with any system that will provide the facilities and functions that are provided by the technical services components 142-156 . Some of the services that are provided by the technical services layer are as follows:

[0068] Persistence module 142 provides the functionality to save data for the business layer 120 and the client layer 102. The persistence module 142 can interface with any commercial relational database and enable the data to persist indefinitely. Additionally, the persistence module 142 preferably supports customizable query and editing functions.

[0069] Transaction Support module 144 provides support for transactions that are committed by the objects of the business layer 120. Transaction support preferably includes concurrency, consistency and integrity of the data.

[0070] Synchronization module 146 provides the synchronization of related data in order to represent a consistent view to the user. Transaction changes can cause cascading modification to other related object data. The synchronization module 146 ensures that transaction changes are applied in a consistent and timely manner.

[0071] Messaging module 148 provides infrastructure for notification delivery, message exchange, persistence, and tracking of messages over the communication network. The service provided by messaging module 148 is important because it supports the integration of real-time operational and system conversation.

[0072] History module 150 maintains object properties through the complete life cycle of the object. The services of the history module 150 can be configured such that only those properties and objects that are of historical importance are maintained.

[0073] Life Cycle Management module 152 provides services to manage the life cycle of objects within the system 100 of the present invention. Actions and methods that have to be executed before or after an object's life, or when changes are made to the object, can be specified within the life cycle management module 152. The life cycle management module 152 ensures that object actions are automatically executed based on life cycle parameters.

[0074] Security module 154 ensures that only valid client objects are allowed to change another object's data or to execute a method or action.

[0075] Scheduler module 156 provides a mechanism for setting the execution of scheduled server processes. The scheduled server processes are typically set and defined by business objects of the business layer 120. The scheduler module 156 improves efficiency of the system 100 by deferring processing to off peak times.

[0076] In order to achieve these goals effectively, the system 100 employs an open-system infrastructure that is constructed from layers of cooperating components. Each of the components and modules within each of the layers is specifically designed to accomplish its particular objectives.

[0077] Description of the Services within the Technical Layer

[0078] Messaging

[0079] Schedulers, Traders and other business entities communicate with each other during the deal capture and management process. These communications are generally unplanned and ad-hoc. However, they are important because they clarify and resolve issues between the parties. The messaging module 148 provides an electronic forum for “conversations” and delivery of notifications between objects that act as parties to a transaction. The messaging module 148 provides the following services:

[0080] Persistence: Messages or “conversations” between participants are logged in to the persistence module 142. Messages can be made to persist for a configurable number of periods. The persistence feature provides the user the ability to retrieve archived messages.

[0081] Filtering: Users can define filters that will automatically filter messages. This prevents the user's display from being clogged with messages and allows them to view or participate in “conversations” of particular interest. The users can set filters at various levels by type, sender or group.

[0082] Notifications: The messaging service is used by other business functions such as Trading 122, Scheduling 126, etc. in order to broadcast messages and notifications. For example, a trading object 122 interfaces with a scheduler object 124 that can automatically schedule the delivery of bulk messages during the off-peak usage time. The automatic scheduling capability conserves communication network resources during peak time-periods, and precludes the need to interrupt the user during peak work time. The automatic scheduling greatly increases the computing efficiency, as well as labor efficiency, of the system 100 of the present invention.

[0083] User Customizations: The user can customize the message delivery mechanism. The user can set filters, display options, subscribe to messages, etc. However, the system 100 does not users to filter system or administrative messages to ensure that all users receive important messages.

[0084] Group Memberships: The administrator of the messaging service 148 sets the user's profile and membership to groups. The system 100 allows for the definition and attachment of customizable rules for enforcing group memberships and policies.

[0085] 3. Business Services

[0086] Overview

[0087] The business services layer 120 contains the set of objects (the object engine) that implement the business logic of the supply chain. Various aspects of the object engine are exposed to the interfaces of the client services layer 102. Similarly, the objects of the business services layer derive services from the technical services layer 140. The object engine itself is a complete set of objects, but has discernable aspects that are amenable to identification. It should be noted, however, that the object engine within the business services layer 120 are a unified whole, and are not intended to be segregated. Segregating the objects within the business services layer 120 would impede the seamless integration of services that provide a serendipitous increase in performance over the disjoint systems of the prior art.

[0088] Trading

[0089] The trading aspect 122 provides full life cycle support for contract capture and generation. Embedded business logic is used for validation. The trading aspect 122 enforces business rules for contract approval process, yet the process itself can be configured to meet dynamic changes in a business environment. The trading aspect 122 supports the operational business processes by capturing trading data, and by maintaining the consistency and the integrity of that data across a distributed communication network. The trading aspect 122 also realizes the real-life situations of contract negotiations where contracts, once executed, may be modified or amended and those modifications or amendments prompt a separate cascade of changes throughout the system for such issues as Scheduling, Pricing, etc. Ease of data capture, flexibility, customizable intelligent user interface, and role-based security scheme, are the important features of the overall trading system.

[0090] Scheduling

[0091] The scheduling aspect 126 provides a suite of objects for the planning, the optimization, the tracking, the execution and the reporting of the movement of goods or commodities. The objects of the scheduling aspect 126 also provide the resulting dynamic positions and inventories throughout a route network from the time and place of purchase or acquisition to that of sale or distribution. The multi-user environment allows for a common and integrated data source which is populated with pertinent and timely information collected from the numerous individuals and the electronic data feeds that are typically involved in the scheduling process. The scheduling aspect 126 provides a highly efficient scheduling environment by simplifying and automating common tasks, including: generating and manipulating numerous records with a single user action; performing lengthy calculations, such as position and inventory; generating reports and distributing those reports electronically to internal or external parties; and maintaining the consistency and the integrity of large amounts of data.

[0092] Accounting

[0093] The accounting aspect 128 integrates with the trading aspect 122, the scheduling aspect 126, and other aspects of the business services layer 120 to derive and to manage accounts that are associated with managerial and financial accounting functions. The accounting aspect 128 may also interface with other processes, such as other accounting systems, that are external to the system 100 of the present invention. The goal of the accounting aspect 128 is to support planning, control, decision-making, and regulatory compliance activities as well as to generate financial entries into the user's financial accounting system. Financial statements or reports that are generated by the accounting aspect 128 are fed into other organizational accounting systems that are either internal or external to the system 100 of the present invention. Among other aspects, the accounting aspect 128 determines credit exposure, allocates premiums and discounts, generates the cost of supply, determines and books voyage, barge, rail, and truck, pipeline gains/losses, tracks exchange balances, generates invoices and notifications, etc. The system 100 of the present invention also supports the determination of forecasted cash receipts and disbursements. These various debits and credits are then used by the system 100 of the present invention to better estimate real-world costs, risks, and exposure.

[0094] Risk Management and Measurement

[0095] The risk management and measurement aspect 124 integrates with the physical trading aspect 122, the scheduling aspect 126, and the accounting aspect 128. Alternatively, the risk management aspect 124 could stand alone for pure trading activity. The risk management aspect 124 provides full life cycle support for deal capture, deal generation, and deal valuation utilizing embedded business logic that can be used to validate the deal. The risk management aspect 128 enforces business rules for the deal approval process, yet the deal approval process itself can be configured to meet dynamic changes in the business environment. The risk management aspect 128 supports the financial and the operational business processes by capturing trading data, maintaining the consistency and the integrity of data across at least one distributed communication network. All financial instrument types are captured by the present invention, including, but not limited to: swaps, basis swap, exchange futures, exchange futures options and over-the-counter options. Additionally, the present invention may also capture combination physical/financial instruments. Physical and financial positions are provided in any timeframe needed for decision making and financial reporting. The system includes market data in the form of a repository that maintains and tracks the latest market data for different commodities from various exchanges, publications and/or internally derived. The data can be viewed independently or referenced in a price formula for forward curves. Interest rates, volatility and other market data.

[0096] Route Network

[0097] The route network utility system 130 provides a suite of objects of general capability having no related or associated intent beyond that of support and reuse by other business and client service layer systems. The route network system 130 objects are designed to provide lightweight, standalone functional services.

[0098] Organization

[0099] The Organization function 132 within the business services 120 provides the capability to model organizational hierarchy within a company that interact with other business functions such as Trading 122, Scheduling 126, Accounting 128, etc. This allows for simulation of real life operation interactions of individuals and their business functions. The model components are configurable such that the temporal nature of job positions and person(s) fulfilling those positions can be modified easily. The organizational model simulates the abstract relationships between its constituents and integrates with other business functions

[0100] Description

[0101] Trading

[0102] FIG. 2 illustrates one common overall trading business process. Traders and analysts monitor external (market data) and internal (positions) as inputs to develop a strategy for commodity trades. Using that strategy, the trader initiates contract with other traders in the market. After the initial contact, a negotiation process that culminates in a “trade”. The present invention is structure in a way that accommodate the multitude of possible outcomes in contract negotiations. For example, the present invention can accommodate situations where the contract is not negotiated on the first try, and has to be modified and resubmitted multiple times. Should a trade result, the trader then captures all of the trade-related data in the system 100 of the present invention. If the trade includes a sale of a commodity, the system automatically interfaces with an internal or external credit approval process (that is available via the external data exchange interface 108) that displays credit and other related information about the other partyother party. The combination of the above strategy, and credit and commodity pricing (“REFER”) information, enables the trader to proceed with the trade or make modifications and/or renegotiate the contract. Note, the present invention is able to accommodate a human trader, as well as utilize an autonomous or semi-autonomous object or set of objects that represent a trader.

[0103] Once the credit for the trade is approved, the specific trade is persisted but not released to the scheduling aspect 126. However, if the trader determines that all of the relevant data pertaining to the commodity that was purchased was captured, then the contract is “released” to the scheduling aspect 126 for scheduling of the commodities through the route network 130. At this point in the life cycle, the trade is complete and the related contract data is captured in the system 100 of the present invention. However, the contract is not yet executed.

[0104] The contract will be both generated and distributed either by the party or by the other party. When the contract is to be prepared internally, the traders and the contract administrators use a contract generation tool 123 that allows them to add pre-defined or new legal content to the contract data. The contract generation tool 123 allows the users to generate any type of contract and apply business rules for approval processes. The contract generation tool 123 enables the users to create contracts by using one standard interface. During the life cycle management of the contract, other types of contracts, such as transportation contracts, can also be generated using the contract generation tool 123. It should be noted that the contract generation tool 123 may not need to reside within the trading aspect 122. Contract generation is a fairly generic necessity. If properly implemented, the contract generation tool 123 can reside in, for example, the technical services layer 140. Moreover, the contract generation tool 122 can be enabled to assemble any type of contract, and is not intended to be restricted to generating contracts for commodity trading. For example, transportation contracts are independent of commodity trading, yet, with the right data input from the transportation objects, a suitable contract can be generated. Additionally, unique approval requirements including approvals from Legal office, Traders, Schedulers, Contract Administrators, Managers, Title, and Contracts office can be specified on a per contract basis.

[0105] The contract document generation, and the process of approvals, may involve several iterations before the contract is finalized and sent to the other party for final execution. The system 100 of the present invention tracks the changes to the contract document made during each iteration. After the contract is sent for execution, the other party may want to make modifications to either the verbiage or the terms of the contract. The contract generation tool 123 is used to make modifications to the contract document, which may require approval from managers and legal office. When both parties approve the contract, the contract is then executed.

[0106] In the scenario where the contract is to be prepared by the other party, both parties agree to the number of days (the “waiting period”) within which the first party will receive the contract from the other party. The system 100 of the present invention tracks the receipt of the contract documents from the other party. If a contract document has not been received, and the waiting period has expired, then appropriate notifications are automatically sent to the involved parties by the system 100 of the present invention. Under these circumstance the party may decide to assume the responsibility of preparing the contract documents. The present invention provides the ability to dynamically switch the responsibility of preparing contracts between the party (internal) and other party (external) before or during negotiation. This switching is accompanied by the enforcement of respective business approval processes for a specific contract by the system 100 of the present invention.

[0107] Another feature of the trading aspect 122 is real-time communication between individuals and the system 100 using the supporting communication network. The messaging service (“REFER”) 148 is used to capture, persist and track any and all ad-hoc “conversations” that make up a final trade. Additionally, when changes are made, notifications are distributed proactively by the system to specific individual roles for action and/or for information.

[0108] A more detailed description of the trading method 200 of the present invention is illustrated in FIG. 2. The method starts generally at step 202. Thereafter, in step 204, the contract is negotiated. Once the contract has been negotiated, the contract data is entered into the system 100 of the present invention in step 206. Next, in step 208, a check is made to determine if credit approval is required for the specific contract in question. If credit approval is required (i.e., the result of step 208 is positive), then credit approval is sought and, in step 210, a check is made to determine whether such approval has been received. If credit approval has been received, or if credit approval is not required (i.e., the result of step 208 is negative), then step 212 is executed, wherein the contract is released to scheduling. At this point, the method splits into a parallel process, namely steps 214 and 216. In step 214, the process of scheduling the commodities (or other goods and services) is started, as well as the updating of inventory levels, etc. The present invention facilitates the concurrent processing of business processes. The system 100 of the present invention improves operational efficiencies by allowing business processes to occur concurrently, even if there are rules governing the sequence of the steps making up the particular process. For example, in case the contract is not generated or not executed, the impact on other systems (such as scheduling) is communicated to the affected objects, and updates to, for example, the inventory level and scheduling operations are made.

[0109] At the same time that the contract has been released to scheduling, execution of the method 200 moves to step 216, wherein a check is made to determine if the contract is to be prepared internally. If so, then the contract is prepared in step 218. If the contract was not to be prepared internally, i.e., the result of step 216 is negative, then a check is made in step 220 to determine if the contract has been received from the other party. If the contract has not been received, i.e., the result of step 220 is negative, then a check is made in step 238 to determine if a user-defined waiting period has expired. If the waiting period has not expired, then execution loops back to step 220, otherwise, execution moves to step 240 and the contract is designated to be prepared internally and execution moves back to step 216 for further processing.

[0110] If the contract has been received (i.e., the result of step 220 is positive), or if the contact document has been prepared in step 218, then execution moves to step 222, where a check is made to determine if manager approval is required. If manager approval is required, then execution moves to step 224, where a check is made to determine whether manager approval has been obtained. If manager approval is not required (i.e., the result of step 222 is negative), or if manager approval has been received (i.e., the result of step 224 is positive), then execution moves to step 226, where a check is made to determine whether or not legal approval is required. If legal approval (e.g., by a lawyer and/or government regulatory) is required, the execution is moved to step 228, where a check is made to determine if legal approval has been received. If legal approval has been received (i.e., the result of step 228 is positive), or if the result of step 226 is negative, then execution moves to step 230, wherein the contract is distributed to both parties. Thereafter, in step 232, a check is made to determine if both parties have approved of the contract. If so, then the contract is executed at step 234 and the method ends generally. However, if the contract has not been approved by both parties (i.e., the result of step 232 is negative), then execution moves to step 236, wherein a check is made to determine if changes are needed in the verbiage of the contract. If changes to the verbiage are required, then execution moves back to step 216. Otherwise, i.e., the result of step 236 is negative, then execution moves back to the negotiation stage of step 204, as illustrated in FIG. 2.

[0111] FIG. 2 also illustrates some of the activities of the trader/analyst 250. In addition to monitoring or participating in the negotiation of the contract, the trader 250 may also monitor market data (step 254) and monitor positions (step 252) either sequentially, or in parallel with the negotiation of the contract.

[0112] Trading Business Model

[0113] FIG. 3 illustrates the trading business model 300 and its relationship to other functions. The trading business method uses the credit approval system 302 in conjunction with pricing formulas object 304, positions objects 306, market data objects 308 and assumptions objects 312, in order to negotiate trades with other parties. Trade volumes and negotiations are finalized, based on integrated comprehensive information. The system 100 of the present invention provides multi dimensional views of data to assist the trader 250 in formulating appropriate and efficient trades. It should be noted that some of the objects mentioned above can be generated dynamically. For example, the positions object 306 can be a derived value from the scheduling aspect 126 that is calculated in real-time based on changes in inventories. Moreover, even thought the responsibility for calculating positions might rest with the facility object 408 (see FIG. 4), the system 100 of the present invention presents a multi-dimensional view of positions to users, based on a variety of factors such as location, commodity, etc. Other objects can be similarly generated dynamically to provide information to users and/or other processes, based on information kept within the present invention, and/or received by the present invention.

[0114] Other elements of the trading business model 300 are illustrated in the example model of FIG. 3. For example, the trader generates one or more contract objects 314. The contract object 314 can contain properties that distinguish the terms of one contract from another. The contract object 314 may also have methods that can be used to mimic the execution of the contract (by performing the services called for by the contract. The contract object 314 may also have relationships with other objects, such as the price formula object 304, the inventory buy/sell object 320 (that is normally part of the scheduling aspect 126), and the company object 310. Similarly, the inventory buy/sell object 320, which is maintained by the scheduler 322, has a relationship with the position object 306 (also part of the scheduling aspect 126). The position object 320, in turn, has relationships with the demand object 328 and the inventory build/draw object 330 (both of which are part of the scheduling aspect 126), The one or more demand objects 328 receive input from the production actors 324 and/or from the sales actor 326. The inventory build/draw object 330 also receives plans from the scheduler 322. All of the actors of the present invention, such as trader 250, scheduler 322, production 324, and sales 326, can be human operators and/or virtual processes that either autonomously, or semi-autonomously operate in the same capacity as the human operator. The autonomous or semi-autonomous processes can receive input directly from real-world sources in real-time, or they may respond to a pre-defined algorithm or set of data, such as a recorded set of parameters used for subsequent analysis.

[0115] The automated process 300 of the present invention enables the capture of contract data in real-time and also checks for the validity of contract data (e.g., the properties of the contract object 314), preferably based on domain specific rules. Flexibility is built into the system 100 of the present invention to accommodate exceptions. The automated process ensures capture of complete, accurate and consistent data. Modifications to the data, such as canceling or deleting a contract, are allowed and are based on integrated business rules. The contract capture data can then be shared among other processes within the overall context of trading, contract generation and scheduling. Captured contracts can then be viewed in a consolidated, comprehensive display. Additionally, the process 300 of the present invention allows for the capture of a contract in a phased manner over multiple times by providing the capability of “releasing” a contract. Only when the originator trader 250 releases a contract the contract is available for contract generation, execution, and sharing with other business system processes.

[0116] The trader 250 may work with many contracts, that are preferably all similar in content. The trader 250 typically wants to clone an existing contract rather than create a contract from scratch. However, there are always certain contract information elements that are unique to a contract and they will need to be captured. Cloning a contract will add to the efficiency of the contract capture process. The cloning process ensures that no inconsistencies or inaccuracies exist between contracts that are cloned. The cloned and the original contract are treated as separate contracts. However, pre-defined or dynamic business rules for validation are applied in the same manner as for the original source contract. The cloning logic allows for copying of the data from an existing contract to a new contract. However, certain contract information is not copied and the trader has to capture that information.

[0117] After a contract is captured, the contract can be edited, cancelled or amended. When changes are made to a contract the automated process ensures contract information consistency and optimizes enabling of changes.

[0118] A contract can be cancelled based on specific business reasons. Additionally, changes can be made to the contract and an amended contract is generated. A cancelled contract automatically results in a notification to the external parties. Additionally, notifications should be sent to entities within the organization so that one or more appropriate business steps could be initiated due to the changes or cancellation of a contract.

[0119] The system 100 of the present invention allows contracts to be edited, cancelled or amended. However, enabling of certain functions is dynamically set in real-time based upon business rules that pertain to that stage of the business process. For example, a contract that is already executed cannot be amended or modified without taking some other business steps. The intelligent checking and validation changes in real time ensure that business processes are strictly adhered.

[0120] In the preferred embodiment, traders would be able to determine quickly and easily whether the trader is long or short for any given commodity by examining the position. If short, the trader knows additional quantities must be purchased. If long, the trader knows additional quantities must be sold. Traders get this information by executing the position calculation. Reference can also be made to the corresponding position calculation for the scheduler. Note, receipts, deliveries, and inventory information results in a position. Schedulers apply one or more build or draw transactions, which are planned activities rather than an actual physical transfer of commodity, to obtain an effective position for schedulers. The traders then refer to the position as ascertained by the actual transactions as well as the schedulers' projected and planned transactions, along with production and demand (actual and forecast) in order to do their planning activities.

[0121] Traders or analysts enter plans to exchange commodities rather than execute a pure or outright purchase or sale. Handling exchanges are an essential element of the position calculation (refer scheduling position).

[0122] When one party agrees to sell or exchange a commodity to another party, the agreed upon price may be a simple fixed and flat value, or a complex, event based, formula involving many components. Many people require the ability to view and calculate prices e.g.: traders, schedulers, cost accounting, analysts (i.e., credit, economic, risk management, financial), operations coordinators, billing, and contract administrators.

[0123] The pricing aspect provides the capabilities to research historical pricing, input simple and complex pricing formulas, calculate the formula at a given point in time, utilize (i.e., in contracts, commodity valuation) and report the results. The system includes market data in the form of a repository that maintains and tracks the latest market data for different commodities from various exchanges. The data can be viewed independently or referenced in a price formula. Further pricing formulae in the form of libraries are supported to facilitate a price formula and enable reuse.

[0124] Trading business functions interface with the user's organizational structure to determine the roles of individuals who participate in the formulation of a trade. Trading business functions thus ensures that individual responsibilities are properly tracked and operational snags can be routed to the right individuals for resolution.

[0125] Route Network

[0126] FIG. 4 illustrates the route network model. Route network is an abstract collection of the Routes class of objects. This abstract collection allows the system 100 of the present invention to present a subset of routes that are based on user preferences, roles and security. Members of the Routes class may have one or more of the following properties or contain object instances of one of the classes described below. As with other object sets of the present invention, the objects of the route network can contain properties and methods. The properties can be either global, or local to the particular object. Moreover, the properties need not reside in any particular object, but may be rearranged for placement in other objects, or within one of the layers mentioned previously as a service for any process or sub-process of the present invention.

[0127] Objects of the present invention may be equipped with methods that provide a convenient way to manipulate information, such as property values, within the object (or global properties). The methods of the various objects may be called by the system 100 of the present invention and/or by object instances contained within, or external to, the system 100 of the present invention. The capability provides for the creation of a virtual environment within the system 100 of the present invention, wherein object instances can communicate with one another, or with external processes and devices, in order to enable those object instances to operate autonomously, in conjunction with other objects and processes, and/or under the direction of another process or object to form a complex adaptive system.

[0128] An example of the route network model 400 of the present invention is illustrated in FIG. 4. Central to this example of the route network model 400 is the route segment object 412. The route segment object 412 can obtain an origin and/or a destination from a facility object 408. The facility object 408 has a relationship with the storage unit object 410, and the location object 406. The location object 406, in turn, has a relationship with the state or province object 404 which, in turn, has a relationship with the country object 402.

[0129] The route segment object 412 also has a relationship with the transport object 414 and the route line item object 422. The route line item object 422 has a relationship with the route object 424 which, in turn, has a relationship with the route network object 426 as illustrated in FIG. 4. The transport object 414 has a relationship with the route line item object 422, the carrier object 418 and, for example, the vessel object 416. The carrier object 418 has additional relationships with the route line item object 422 and the company object 310 of FIG. 3.

[0130] Country

[0131] A country represents a recognized nation or political division of land, which needs to be tracked in the system (e.g., United States of America or Canada).

[0132] State or Province

[0133] A StateOrProvince property represents a recognized division within a country (e.g., Texas or Quebec). In some cases when a specific division of a country does not exist or is irrelevant to information requirements, the country's name is repeated for the state or province. This flexibility enables capturing only relevant data without enforcing geographical restrictions.

[0134] Location

[0135] A Location represents any abstract geographical location such as a city or an area in the Gulf Coast. Examples include Catlettsburg, Columbus, and South Pass Block 87. Location object is used for filtering facilities in the view. The Location properties are used primarily as identification points for tracking the supply and demand of a commodity and do not necessarily correspond to a physical location.

[0136] Facility

[0137] A Facility represents a physical site such, as a refinery or terminal. A value for the facility property generally indicates that a supply or demand for a commodity exists. A facility may span multiple locations and a location may contain multiple facilities or a single facility. A facility may contain multiple storage units and a single storage unit may span multiple facilities.

[0138] Storage Unit

[0139] A Storage unit represents a specific container (e.g., a tank, cavern, truck, or even a pipeline itself) that holds a commodity. The storage unit may or may not represent a physical entity within the transportation network. The system 100 of the present invention enables the user to include a virtual storage unit for planning purposes and review its impact on the overall plan. Later, an actual physical storage unit can be added or another storage unit reassigned to a facility. The system 100 of the present invention may include a multi-dimensional user view that is designed to display all of the information for location, facility, and storage unit combinations and permutations.

[0140] Route Segment

[0141] A RouteSegment is the smallest “trackable” segment that a transport mechanism can move a commodity from “point A to point B”. The route either does not split or join up with any other between the origin and destination points, or the user may simply not care to represent it. A RouteSegment is a valid, single-legged combination of a specific origin facility to a destination facility. A RouteSegment is directional.

[0142] Transport

[0143] A Transport is a physical mechanism by which a commodity is moved from point A to point B. The Transport has properties that identify various types of transport mechanisms. A Transport acts inherently as a storage container with the capability to transport a commodity. The system 100 of the present invention allows the modeling of any transportation type because the Transport contains commodity inventories that should to be included in the inventory calculations. A transport object may represent an actual pipeline, ship, barge, rail car, truck, or any other commodity transport vessel. The system 100 of the present invention enables the user to customize the level of detail used to record the movements of the transport object that represents the real world transportation mechanism. In addition, the transport object may be fitted with properties and methods that detail the capabilities of the transportation mechanism being modeled. For example, a “move” method could be added to the transport object that may receive a command to “move” the commodity being transported to a particular set of coordinates. The transport object of the present invention may thus contain objects that represent commodities and, on their behalf, deliver them to another location (i.e., change their respective location properties to indicate the new location of the commodity (either the actual location, or, in the case of an optimization model, a virtual location). The transport object can be equipped with logic that enables the transport object to find its own way to the specified destination, which would help decentralize management, provide for a more robust system, and enable autonomous optimization of the supply chain.

[0144] Vessel

[0145] Vessel is a specific type of transport. Additional information is maintained about the vessel (i.e., dead weight tonnage).

[0146] Carrier

[0147] A Carrier is a specific kind of company responsible for transporting commodities.

[0148] RouteLineItem

[0149] The Transportation network comprises of collection of route segments. A route between two pints can be designed using alternate paths. Additionally, each route segment could be part of multiple routes. The Route Line Item object sequences one or more route segments into a larger route concept. Note, the order of the route segments is significant. This system allows customization of route segments into a route during planning phase. For example, if “A to D” represents the route, then the underlying route segments might be specified as “A to B”, “B to C”, and finally “C to D”. Similarly, the route “A to D via B2” might use route segments “A to B”, “B to B2”, “B2 to C”, and “C to D”. Although the origins and destinations of these two examples were the same, the route was composed of a different set of route segments.

[0150] Route

[0151] Route is a user-named representation of an origin and destination pairing. Normally, the movement of a commodity from this origin and destination must traverse multiple route segments. The use of routes provides efficiencies for the user in creating movements that often times traverse the same sequence of route segments repeatedly.

[0152] Organization

[0153] FIG. 5 describes the model of organization function 500. An organization is persisted in the system as interacting and communicating objects of the type Company, Organization, Contact(s), Contact Info, Post and associated Responsibilities.

[0154] Referring to FIG. 5, the model 500 has a company object 502 that has a relationship with one or more contact info objects 504, and relationships with zero or more organization objects 506. A particular organization object 506 has additional relationship with the zero or more post object 514 and one or more contact info objects 504. The zero or more post objects 514 have relationships with zero or more responsibility objects 516 and zero or more contact objects 512. A particular contact object 512 has a relationship with one or more contact info objects 504. A particular contact info object 504 has a relationship with one or more contact info line item objects 508. A particular contact info line item object 508 has a relationship with zero or more address objects 510.

[0155] Company

[0156] The company object comprises of data and behaviors pertaining to different types of companies, such as an internal or an external company, and any associated parent company. The company object contains contact information needed to keep track of a company's mailing, billing and/or invoicing information. The Company object can also comprise other organizations. The recursive relationship between Company and Organization objects provides the ability to scale the model as organizations grow.

[0157] Organization

[0158] An organization is used to model the hierarchy of groups within a company. The organization object has properties that are used to specify the type of organization. Example organization types include department, section, region, etc. An organization can have sub-organizations and sub-organizations may themselves have sub-organizations.

[0159] The organization object enforces rules that restrict the relationships between the various types of organizations. For example, a department may consist of sections but sections cannot contain departments. These business rules are configurable based on real life hierarchical parental relationships between organizations and sub-organizations. Additionally, the organization object independent of its parent company or organization contains specific contact information.

[0160] ContactInfo

[0161] The ContactInfo object keeps track of all means of communicating other entities, which could be a person, company or organization. It is a general concept that applies to more than just individuals (people), companies and organizations. ContactInfo object encapsulates all contact information for an entity. ContactInfo object can include email addresses, telephone numbers, mobile telephone numbers, pager, facsimile numbers, telex addresses, physical and mailing addresses, and/or web URLs or other contact information. For example, a person's work and home contact information are saved in a single ContactInfo object. The ContactInfo object contains one line item for each set of contact information.

[0162] The system 100 of the present invention provides the flexibility to inter-link specific elements of information such that related contact information elements can be retrieved easily. However, the system 100 does not enforce dependencies. For example, an address can be captured without specifying a telephone number or vice-versa. This type of flexibility allows information to be captured, as it is available or even when it is incomplete, to be completed later as it is made available.

[0163] Address

[0164] This system treats the Address object independent of its ‘owner’. The address can be of varying formats based on location and other parameters.

[0165] Contact

[0166] The contact object is used to keep track of people within a company, organization or sub-organization. Each contact object is associated with respective contact information.

[0167] A contact is assigned to fill one or more posts Cob position) within a company organization. This allows the flexibility to keep the organization structure persistent and not change with the changing membership of individual participants.

[0168] Post

[0169] A post is used to define the job positions within an organization. This could be a trading desk or a specific scheduling job within an organization. Posts are filled by contacts (people) and a record of each contact's start date is maintained so that the system can identify who filled the post at any given time. The type of post is called the role. Examples of roles are: trader, scheduler, accountant, etc. The role is a general type of position while the post is a specific job position. A post contains a collection of responsibilities. That is the user can specify which location/facility and commodity combinations this job position is responsible for.

[0170] Contacts are not directly mapped to a company. Instead, contacts are mapped to a post within an organization that belongs to a company. The model is implemented in such a way that only a single organization and post need be used to keep track of all of the people within a company. In addition, the objects of the present invention support a method to add a contact to a company without having to associate a post.

[0171] The model of associating individuals with posts provides a user the ability to model situations where the post will not change but the person filling the post will change. In addition, a given post may have a multiple number of responsibilities. For example, trading desks may be responsible for certain combinations of location, facility and commodity. The system 100 of the present invention makes it easy to reassign the post to another person rather than having to reassign each of those responsibilities to another person directly.

[0172] Support

[0173] Units

[0174] The units system provides a set of objects for conversion of numeric values from one unit to another. FIG. 6 shows the class diagram 600 for the units system.

[0175] The class diagram 600 for the units system (part of the support aspect 134 of the business services layer 120 illustrated in FIG. 1) includes the unit manager 602 which uses the unit group 604 and the unit entry object 606. A particular unit group object 604 has a relationship with one or more unit entry objects 606. The unit field object 608 has relationship with the unit manager 602.

[0176] The objects include the UnitGroup, UnitEntry. and UnitManager. The UnitGroup defines groups of related units such as length, volume, mass, time, and temperature. The UnitEntry object represents specific units such as feet, meters, pounds, seconds and degrees Celsius. Every UnitEntry belongs to one and only one UnitGroup., Each UnitEntry object maintains a multiplier and an offset that, when applied by a unit manager, can be used to convert from one unit to another.

[0177] The units system is flexible in that unit groups and entries are maintained in the data store and can be dynamically added, modified or removed at any time. The UnitManager is responsible for reading, updating and otherwise maintaining the unit definitions in the data store and for carrying out the actual conversions. The unit system also provides the UnitField object, which represents a value, unit, start and end time and encapsulates logic for combination with other UnitField objects using simple arithmetic operations without requiring the user of the UnitField objects to be concerned with the unit conversion process. The arithmetic operations that are available to the UnitFile object include, but are not limited to, adding, clipping, splitting and joining based on the start and end times specified.

[0178] Scheduling

[0179] FIG. 7 illustrates the overall scheduling business process of the present invention. The system 100 of the present invention supports the various scheduling activities and enforces business rules that are found in a dynamic business environment. However, the system 100 does not confine or restrain the order in which those activities are performed.

[0180] Analysts and facility representatives specify demand for commodities at production or distribution facilities while schedulers specify plans to build or draw from the existing inventory. Commodities are acquired by traders or purchasing agents while the position is continually monitored by facility and or commodity. Schedulers perform an iterative cycle of planning, optimizing, generating, nominating and tracking the movements that transport the commodities from the point of purchase to the point of manufacturing or sale. The scheduling business process of the present invention is preferably iterative because carriers may require revisions to the nominations after having received and/or processed the original nominations that arrive from numerous shippers. In addition, the process is iterative because schedulers must handle unplanned, real-life situations such as delays and loss of materials occurring during transport and or the temporary or complete loss of a means of transport resulting from some catastrophic event. It should be noted that one of the features of the present invention is that it reduces the need for interactive supply chain operations and activities. Moreover, the structure of the objects of the present invention supports forecasting, planning, execution, and accuracy of supply chain information in comparison to prior art systems.

[0181] Referring to FIG. 7, input from the scheduler 322 and/or the facility representative 704 is fed into the accounting aspect 128 (see FIG. 1) as illustrated in FIG. 7. The accounting aspect 128 contains various functions and modules, specifically, the enter/modify demand function 710, the enter/modify planned inventory build or draw function 712, the enter/modify consumption function 714, the enter/modify production function 716, the enter/modify inventory buy or sell function 718, the link inventory buy or sell to contract function 720, the confirm inventory buy or sell function 722, the enter/modify net outs function 724, the enter/modify movement function 726, the generate transport contract function 728, the import batch schedules 730, the monitor FIFO function 732, the monitor position function 252 (see FIG. 2), and the monitor inventory function 736. After processing by the accounting aspect (typically by application of the input data to one or more of the above-mentioned functions) a check is made in step 740 to determine if a nomination is ready to be generated. If the nomination is not ready for generation, then execution loops back to the entry into the accounting aspect 128 as illustrated in FIG. 7. Otherwise (i.e., the result of step 740 was positive), execution moves to step 742 wherein the nomination is generated. Thereafter, a check is made in step 744 to determine if the nomination is ready. If not, execution moves back to the entry into the accounting aspect 128 as illustrated in FIG. 7. Otherwise (i.e., the result of step 744 was positive), execution moves to step 746, wherein the nomination is distributed to the interested parties/processes. Next, in step 748, a check is made to determine whether a carrier revised the nomination. If so, (i.e., the result of step 748 is positive), then the revised nomination is received by the carrier in step 750 and execution loops back to the input of the accounting aspect 128 for further processing as illustrated in FIG. 7. If the result of step 748 is negative (i.e., there were not changes made to the nomination, then the nomination is executed in step 749.

[0182] FIG. 8 illustrates the scheduling model of the present invention and its relationship to other functions. Facilities, storage units and routes that come from the route network system are central to the scheduling process. Each of the scheduling activities is applied to, or affects the state of, the facility or the storage unit.

[0183] The scheduling model 800 is illustrated in FIG. 8. The nomination description 802 has relationships with the carrier object 418 of the route network aspect 130 (see FIGS. 4 and 1, respectively), and with the nomination object 806 which is generated by the nomination description object 802 via the generate nomination method. The nomination description object 802 has relationships with one or more facility objects 408 (also from the route network aspect 130, see FIGS. 1 and 4). Each facility object 408 has relationships with zero or more demand objects 328 and with zero or more inventory build/draw objects 330 (see FIG. 3). The facility object 408 also has a relationship with the net out object 814. As was illustrated in FIG. 4, each facility object 408 has a relationship with zero or more storage unit objects 410. Each storage unit object 410 preferably has a relationship with zero or more inventory actual objects 818, zero or more inventory adjustment objects 820, zero or more consumption objects 822, zero or more production objects 824, zero or more inventory buy/sell objects 320 (see FIG. 3), and movement object 830. The movement object 830 has relationships with the route object 424 (see FIG. 4). Zero or more movement objects 830 are linked to zero or more contract objects 314 as illustrated in FIG. 8. The movement object 830 also has a utilization relationship with the transport object 414 (see FIG. 4). Each transport object 414 has a relationship with the storage unit object 410 as illustrated in FIG. 8. As was illustrated in FIG. 3, zero or one contract objects 314 generate zero or more inventory buy/sell objects 320. As was illustrated in FIG. 4, the route network object 426 has a relationship with one or more route objects 424. In the preferred embodiment of the present invention, various properties are accessible to some or all of the objects of the present invention. For example, the commodity property (illustrated in the various objects of FIG. 8) is accessible at the facility level, or at the location level (which is an aggregation of commodities at all facilities for that location).

[0184] Demand

[0185] At the facility level, traders, analysts, facility representatives and purchasing/sales personnel forecast the need for commodities for a specific time-period by creating records of demand. Demand does not impact inventory, rather it is a means of specifying what commodities are expected to be provided at a facility. Demand is an essential element of the position calculation (REFER). The demand projection is usually derived from past trends, surveys and or complex business simulations. The system 100 of the present invention provides the user with different views of the demand data including, but not limited to: listing the demand for all or a group of commodities at a single facility; and/or, listing the demand for a single commodity at all facilities throughout the route network. Additionally, the system automatically captures the state of the demand plan at different stages in the planning cycle enabling users to see how demand changed with time which can be particularly helpful during post-mortem studies.

[0186] Inventory Build or Draw

[0187] Demand can be met by purchasing, manufacturing, or drawing from existing inventory. Schedulers must manage the inventory throughout the route network, and they plan inventory changes at the facility level by creating inventory build or draw records. The inventory build or draw records specify targeted increases or decreases in inventory by commodity and by facility for a specific time-period. As with demand, inventory build or draw records do not impact inventory; they do not represent actual receipts or deliveries, rather they allow schedulers to define objectives and then to check whether or not they have met those objectives. The inventory build or draw records are a critical element of the position calculation (REFER).

[0188] Inventory Buy or Sell

[0189] In the case of a physical deal, traders arrange for the exchange of some quantity of one or more commodities. The contract object (refer) from the trading system records the details of the agreement and generates the legal document. However, the contract object does not directly record the details of what is actually traded nor does it in anyway directly impact inventory. Instead, the scheduling system provides inventory buy or sell objects to model and record the change of ownership of some quantity of a commodity with another party.

[0190] Inventory buy or sell objects represent scheduled and actual receipts or deliveries of a commodity and therefore do impact inventory. Inventory buy or sell objects can be linked with a contract so that the actual receipts and deliveries can be compared with the details specified by the contract. When a contract is released to scheduling, the scheduling system automatically generates inventory buy or sell records based on the information contained in the contract and links them to the contract. The scheduler will then update the inventory buy or sell record as details of the exchange become available.

[0191] Sometimes the quantity to be exchanged is not known at the time the agreement is established. In some instances, the exact quantity is it known for long after the contract has been established. For example, two parties may agree to exchange the crude oil produced by a lease. It is impossible to know in advance exactly how much crude oil will be produced each month. In these cases, historical data may provide a good estimate for future deliveries. Therefore the inventory buy/sell (“IBS”) mechanism of the present invention provides a method to forecast future quantities by averaging quantities from the three previous IBS's. The scheduler may choose to estimate the scheduled volume based on the forecast volume.

[0192] As the date of exchange approaches, scheduled quantities and dates are typically determined by agreement of the schedulers from both parties that are listed on the contract object. This process is called confirming the inventory buy or sell in the scheduling system. Schedulers can easily query for confirmed or unconfirmed inventory buy or sell records. In addition, if an inventory buy or sell record has been confirmed, but changes are made to the record after being confirmed, the system will automatically mark the record as not being confirmed.

[0193] Occasionally, traders inform schedulers of contracts they are working on but have not yet released to scheduling. This situation arises when most of the details of the deal are known or expected but the contract can't be created and released because some aspects of the deal are still being negotiated. The scheduler may want to begin the scheduling process prior to finalization of the deal. In those cases, the scheduling system allows schedulers to create inventory buy or sell records manually without associating it with a contract. Later, when the contract is completed and released to scheduling, the scheduler can manually link the inventory buy or sell record with the contract. The system facilitates the manual linking process by only listing those contracts which match the details of the IBS. Once an IBS is linked with a contract, the system will ensure that it is updated when changes are made to the contract.

[0194] At any given time, it is possible for one or more of the IBS's of a contract to be missing. This situation can arise because 1) schedulers can manually delete IBS's and 2) the scheduling system only generates IBS's one year in the future. In the latter case, additional IBS's must be generated as time passes if the contract is valid for more than one year. The scheduling system ensures that missing IBS's will be automatically generated any time a user queries for IBS's or performs an operation which depends on IBS's such as calculating inventory or generating nominations.

[0195] IBS's are an integral part of the commodity position calculation(refer) in that they are one of the means by which the demand for a commodity can be met. However, the point of possession generally differs from the point of demand and the commodity must be transported from one point to another. It is critical then to account for the time required to transport the commodity to the point for which the demand was entered when determining which IBS's should be included in the position calculation for any given planning period. The IBS object allows the schedulers to specify arrival times by specifying the run month.

[0196] Although, a contract may only list a single commodity and quantity to be bought or sold, the seller may meet the obligation by making several smaller deliveries until the total quantity has been delivered. Initially, the quantity and timing of the partial deliveries may not be known. The scheduler will want to enter the total quantity in the system to get an accurate forecast of the inventory. Then, when partial deliveries are scheduled, they too will be entered in the system. The scheduler must however, ensure that the total IBS volume remain unchanged as the partial deliveries are made. In addition, the scheduler will want to be able to easily determine the quantity remaining to be delivered. The IBS object will automatically manage this situation when the scheduler marks a single IBS line item to be adjusted in a manner consistent with maintaining a constant total IBS quantity while other line items are added, deleted or modified.

[0197] Movement

[0198] The scheduling system provides the movement object for the planning, tracking and optimizing of the redistribution of inventory across the route network. Movement of a commodity follows a pre-defined route in the route network from one storage unit to another storage unit at the same or a different facility and the commodity may pass through one or more intermediate storage units before arriving at the final destination.

[0199] The movement is executed by a carrier using some means of transport(refer)such as but not limited to a pipeline, barge, vessel, rail car, truck or airplane.

[0200] When viewing inventory history at a single facility or storage unit and examining a single receipt or delivery associated with a movement, the movement object enables the system to list the origin, destination or any intermediate facility associated with that receipt or delivery and the corresponding times of arrival and departure.

[0201] The movement object supports methods for merging one movement with another or for splitting a single movement into multiple movements. This can be particularly useful when separate schedulers are responsible moving commodities across different sections of the route network.

[0202] The scheduler must know how long it takes to move a commodity from one facility to another using the various means of transport when defining movements. Often, the transit-time is constant within a level of tolerance which is acceptable to the scheduler during the planning phase. Therefore, when a movement is created or modified, the transit-time for each leg of the movement is calculated using the specified departure and arrival times and then saved as information with the route object. The next time a movement is created or modified, the arrival times will be automatically defaulted based on the departure time and the previously calculated transit time.

[0203] Many schedulers must deal with large numbers of movements in any given planning cycle. Entering these movements into a system can be a time consuming task. The scheduling system provides the capability to quickly and easily specify and generate a large number of movements in an automated fashion. For example, the movement object supports a method of replication which produces a series of similar movements occurring in specified multiples at each instance of an equally spaced time intervals spanning an initial and final time as specified by the scheduler.

[0204] When a commodity is moved from one facility to another, the quantity being moved is typically measured at both ends of the movement as well as at any facilities the commodity may pass through along the way. Frequently, the measurements indicate the quantity originally shipped is not the same as the quantity which ultimately arrives at the final destination. This can be attributed to gains or losses that may occur during the movement or to inaccuracies in the measurement process.

[0205] The scheduling system calculates and maintains historical records of gains and losses that occur during movements. The gains and losses must be accounted for when figuring in-transit inventory. For example, if a vessel is completely unloaded, its inventory should then be zero. If measurements show that a larger quantity was loaded than unloaded, the difference is assumed to be a loss and will be subtracted from the vessel's inventory. Historical data can show that some transports typically have higher loss ratios than others. Action can then be taken to reduce the losses by consulting with the carrier or switching to another carrier.

[0206] The Scheduler may negotiate a transportation agreement with a transportation supplier and enter the resultant contract into the system. The scheduler may then link the associated movement with the contract for cross-referencing.

[0207] Inventory Adjustment

[0208] At times, the scheduler may find that the inventory calculated by the system does not agree with measured values or with statements obtained from other responsible parties. This situation may arise because one or more transactions were not properly entered in the system or because the values entered in the system were inaccurate. The scheduler may correct the discrepancy by either specifying an inventory actual (refer) or an inventory adjustment.

[0209] An inventory adjustment is a fictitious receipt or delivery of a commodity at a storage unit. The scheduler can size the inventory adjustment to give the desired or known inventory. The inventory adjustment object includes a place for the scheduler to add comments which fully document what is known about the discrepancy being corrected and on what the corrected values are based on.

[0210] Consumption and Production

[0211] A point of manufacturing converts one or more goods or commodities into a different product for sale or use elsewhere by applying one or more processes such as assembling, blending, combining, shaping or some other method. After successful manufacture of a good or commodity, the inventory of the produced good or commodity must be increased by the amount produced, and the inventory of the goods or commodities used as input to the manufacturing process must be decreased by the amounts used.

[0212] The scheduling system facilitates the entry and tracking of this information via the consumption and production objects where the consumption object is used to specify the inputs to the manufacturing process and the production object is used to specify the output or produced product.

[0213] The scheduling system is further capable of maintaining, recording and correlating, with other integrated scheduling subsystems, estimated and actual production figures for a commodity within a particular manufacturing facility. The system is able to generate per-day consumption and production estimates, given a lump sum amount, by applying algorithms to produce series of fixed-rate items that reflect the time span and rate of production, as specified by the scheduler. The rate of production for a given commodity can be estimated and/or actualized per day, per storage unit, thus allowing for a great deal of granularity in the resulting information set.

[0214] Net Out

[0215] A net out is the process of minimizing unnecessary commodity movements by optimizing the number of physical displacements of commodities that must take place in order to satisfy a set of trade agreements between various trading partners. This exercise results in net savings for each of the trading partners, since the cost of making redundant deliveries and/or accepting receipts is minimized or eliminated altogether. FIG. 9 shows an example of how a set of agreements may be netted out.

[0216] Referring to FIG. 9, the before net out configuration 900 is contrasted with the after net out configuration 900′. Company A 902 is under contract to deliver 3000 units of some commodity to company B 904. Company B must deliver 2000 units to company C 906 and finally company C must deliver 1000 units to company A 902. One possible net out arrangement 900′ would then be for company A 902 to deliver 2000 units to company B 904, company B 904 to deliver 1000 units to company C 906 and company C 906 makes no deliveries.

[0217] Since each company only has access to its own trades, individual companies can only identify a small subset of the possible net out arrangements. However, in some industries, independent organizations are established and granted access to trade information for each of the participating companies with the intent of identifying and establishing net out arrangements. The scheduling system provides the net out object whose purpose is to capture these arrangements and to ensure that the proper quantities are nominated (refer) to the carriers.

[0218] Nomination

[0219] A nomination is a report sent by a shipper to a carrier for the purpose of proposing a set of movements for a planning cycle. The carrier, after receiving the nominations from all shippers, develops and optimizes a schedule for carrying out all the movements for each shipper. Many times, the carrier will be unable to meet the requests of all the shippers and hence will send a revised schedule back to the shippers. The whole process is then repeated until both carriers and shippers have agreed upon a set of movements.

[0220] The scheduling system provides methods which collect the pertinent data, process it and generate the nomination in a format acceptable to the carrier. The system provides the nomination description object which defines the criteria for determining what information will be included in the nomination, the processing options, the format of the report and the recipient.

[0221] The Nomination object is used for persisting actual nomination reports. The nomination object supports revision tracking which is designed to allow for quick identification of modified report items while automatically managing report versions and associated maintenance. The customization of reports to specific recipients allows the data to be presented in the form most useful to that particular recipient.

[0222] Position Calculation

[0223] The facility object provides a method for calculating position. The information included in the position calculation may have come from several different sources including: production, sales, scheduling, trading and analysts. Typically, production sales or analysts enter the demand for a commodity. The demand is the forecasted or planned requirements for a given commodity for a specified time period.

[0224] Demand is entered by facility and by commodity but can be viewed in many different ways such as the total demand for a commodity at all facilities or the total demand of all commodities at a single facility.

[0225] Schedulers enter planned inventory build or draws when they plan to increase or decrease the inventory of a commodity at a specific facility. Traders or analysts enter trading Assumptions. An assumption is a plan to exchange one commodity for another rather than to purchase or sale that commodity outright. Assumptions are an essential element of the position calculation.

[0226] The position is determined for a commodity and time period by summing all the inventory buy or sell entries that have been generated from the contracts or that were manually entered by schedulers, subtracting all demands and planned inventory builds, adding all planned inventory draws and incorporating all trading assumptions. The position can be calculated by commodity or by commodity and facility.

[0227] Inventory Calculation

[0228] An important part of the scheduling process is managing the inventory. Schedulers must be able to determine how much of a given commodity is currently in inventory and where it is located. They must also be able to forecast how the inventory will look in the future and they must ensure that tank levels stay between minimum and maximum levels at all times.

[0229] The scheduling system allows the scheduler to display all receipts and deliveries coming into, or going out of a single storage unit or an entire facility along with the running inventory for a specifie