WO2002101510A2 - System architecture and method for energy industry trading and transaction management - Google Patents
System architecture and method for energy industry trading and transaction management Download PDFInfo
- Publication number
- WO2002101510A2 WO2002101510A2 PCT/US2002/018781 US0218781W WO02101510A2 WO 2002101510 A2 WO2002101510 A2 WO 2002101510A2 US 0218781 W US0218781 W US 0218781W WO 02101510 A2 WO02101510 A2 WO 02101510A2
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- layer
- system architecture
- business logic
- business
- server
- Prior art date
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/06—Buying, selling or leasing transactions
- G06Q30/08—Auctions
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/10—Office automation; Time management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
Definitions
- existing products suffer from a number of limitations.
- the limitations include an inability to readily adapt to a changing business environment, for example, with respect to hourly, regulatory compliance.
- existing products suffer from limited extensibility.
- the traditional gas marketing software model couples contracts and deals with accounting via multiple separate operations for purchase, pooling, transportation, imbalance, sale, storage, and inventory.
- a system architecture for energy industry trading and transaction management includes a business logic server-based layer and a database layer.
- the business logic server- based layer includes a parameter-based configuration of at least one business logic service.
- the business logic service is configurable to enable a deployment of the system to be compatible with a respective business practice of at least one client customer.
- the at least one business logic service is configured to support energy trading and transaction management and to utilize business rules operable on an event basis for processing via an API at least one of energy trading and transaction management data, including data specific to the at least one client customer.
- the database layer operatively connects to the business logic layer for storing the data processed by the business logic layer in a database.
- Fig. 1 is a block diagram view of the system architecture according to one embodiment of the present disclosure
- Fig. 2 is a block diagram view of the system architecture according to one embodiment of the present disclosure
- Fig. 3 is a detailed block diagram view of the system architecture according to one embodiment of the present disclosure
- Fig. 4 is a diagram view illustrating an embodiment of a SOAP packet
- Fig. 5 is a diagrammatic view of an ActiveX component contained within an HTML component as implemented according to one embodiment of the present disclosure
- Fig. 6 is a table definition for a remote method call according to an embodiment of the present disclosure
- Fig. 7 is a table definition for a remote method call response according to an embodiment of the present disclosure
- Fig. 8 is a table definition for creating a remote object according to an embodiment of the present disclosure.
- Fig. 9 is a table representation of an EJB layer divided into two classes;
- Fig. 10 illustrates various header tables of deal objects according to an embodiment of the present disclosure
- Fig. 11 illustrates a flow diagram view of a Gas Marketing Business Process, according to one embodiment of the present disclosure
- Fig. 12, 13, 14, 15 are exemplary screen views of various modules of the Gas Marketing Business Process according to one embodiment of the present disclosure
- Fig. 16 is a diagrammatic view of an inter-facility single leg path
- Fig. 17 is a diagrammatic view of intra-facility multi-leg paths
- Fig. 18 is a diagrammatic view for nomination and re-nomination capability at a point level
- Fig. 19 is a table view of fuel based on receipt for use in illustrating net effect of a negative fuel rate
- Fig. 20 is a diagrammatic view for use in illustrating point level capacity netting
- Fig. 21 is a flow diagram view of a nomination processing use case diagram according to an embodiment of the present disclosure.
- Fig. 22 is an exemplary screen view of an operations screen layout for nomination planning according to one embodiment of the present disclosure
- Fig. 23 is a screen view of an operations screen for nomination planning according to an embodiment of the present disclosure
- Fig. 24 is a screen view of the operations screen in further detail
- Fig. 25 is a screen view of the operations screen in further detail
- Figs. 26, 27, 28 include a screen view of the operations screen of Fig. 25 in further detail
- Fig. 29 is a screen view of the operations screen of Fig. 25 in further detail;
- Fig. 30 is a screen view of the operations screen of Fig. 25 showing additional nominations detail
- Fig. 31 is a screen view of the operations screen of Fig. 25 showing additional nominations detail
- Fig. 32 is a screen view of the operations screen of Fig. 25 showing additional nominations detail
- Fig. 33 is a screen view of the operations screen of Fig. 25 showing additional nominations detail
- Fig. 34 is a screen view of the operations screen of Fig. 25 showing additional nominations detail
- Fig. 35 is a screen view of a whiteboard detail, for nomination planning according to one embodiment of the present disclosure
- Fig. 36 is a further screen view of the whiteboard detail of Fig. 35;
- Fig. 37 is a further screen view of the whiteboard detail of Fig. 35;
- Fig. 38 is a view of an embodiment of a language translation table
- Fig. 39 is a view of an embodiment of user language profile table
- Fig. 40 illustrates a price index attribute table according to an embodiment of the present disclosure
- Fig. 41 is a table view of a number of deal quantities produced using the Deals Quantity Use Case, according to one embodiment of the present disclosure.
- a system architecture for addressing energy trading, transaction processing, risk management, and decision support is based upon open standards, such as SOAP and J2EE.
- the system architecture includes having built-in ties into ente ⁇ rise messaging systems. Accordingly, the architecture allows nearly any client, including Visual Basic, to talk to the architecture, and allows the architecture's engine to run on ente ⁇ rise class UNIX hardware.
- the architecture includes built-in messaging configured to permit seamless integration with existing systems.
- the architecture provides for extensibility, scalability, integration, performance, and rapid development for meeting the changing requirements in energy markets.
- extensibility the architecture accommodates one or more sets of business rules of various customers. That is, the architecture is configured to allow default system logic and logic modules, which are subject to being customized by one or more customers, to be easily swapped out with logic customized by the one or more customers. Accordingly, the architecture is configured to allow customization of business logic that does not lock respective ones of the users into a particular language or protocol.
- the architecture of the present disclosure is configured to link its energy market software application with other third party applications. Accordingly, the architecture is configured to tie its functionality into the capabilities of other systems.
- the architecture is further adapted to have one or more entire sub-applications or modules within the architecture be replaceable with applications that are developed by a third party. As a result, the architecture enables a "plug-and-play" swapping of components and subsystems that requires minimal reconfiguring, and without re-coding.
- the architecture addresses both vertical and horizontal scalability.
- the system architecture provides an ability for its energy market software application to run on large, ente ⁇ rise strength hardware. That is, the software application and system architecture provide a cross platform to the extent that the software application and system architecture run on commercially available hardware, for example, UNIX mainframes from Sun MicrosystemsTM or IBMTM, without the necessity of re- coding.
- the system architecture and its energy market software application provide for an ability to operate on several smaller machines for load balancing and fail-over.
- the system architecture handles management of load balancing by keeping the various units of hardware synchronized.
- the system architecture handles session fail-over in the event that one of the hardware units crashes.
- the system architecture facilitates integration of a multitude of disparate systems. While the system architecture and energy market software application can provide a gas management system of choice, many companies may want to run some portions of the gas management system software with different software applications, for example, a Risk Management, Accounting, or Customer Relationship Management (CRM) system. For an application's value to be maximized, all of the various systems should be configured to talk to each other.
- CRM Customer Relationship Management
- the system architecture of the present disclosure utilizes ente ⁇ rise messaging systems for its integration. For example, all business logic can be called through messaging and all requests coming from a client can be routed through messaging to be pre-processed, redirected or transformed. In addition, as data gets changed within the system architecture, subsequent messaging messages can be sent out with the new data information.
- the system architecture includes TIBCOTM messaging for facilitating an operation of the energy market software application.
- the messaging system may also include WebMethodsTM.
- the system architecture and its energy market software application can be configured to handle business for one or more energy related companies. Accordingly, stability is built into the system architecture and energy market software application. Besides the goal of not crashing or corrupting data, the architecture supports on-the-fly re-configuring, along with isolation of various systems making up the architecture, so as to prevent a problem arising in one area of the architecture from affecting or bringing down the entire system.
- the system architecture and energy market software application are also configured to provide for an acceptable performance, for example, in terms of speed.
- the system architecture can be configured to render a typical response within a few seconds.
- the architecture is necessarily complex, its design facilitates rapid development by software application developers and for operation with respect to a given energy market application.
- a system architecture 10 for energy industry trading and transaction management includes an application server 12 and a database server 14.
- the application server 12 is configured as a business logic server-based layer.
- the business logic layer includes a parameter-based configuration of at least one business logic service configurable to enable a deployment of the system to be compatible with a respective business practice of at least one client customer.
- the applications server 12 includes a Java 2 Platform, Ente ⁇ rise Edition architecture making use of EJB Session Beams 16, as discussed herein.
- the at least one business logic service is configured to support energy trading and transaction management and utilize business rules operable on an event basis for processing at least one of energy trading and transaction management data, via an API, including data specific to the at least one client customer.
- An event may include at least one of a client customer request, a transaction event, a third party event, and a system event.
- the business logic layer further includes a standard API for use per data object of the energy trading and transaction management data.
- the database layer is operatively connected to the business logic
- the applications server 12 is separate from the database server 14.
- the business logic layer is configured to provide flexibility, scalability, and extensibility with the use of parameter driven business rules.
- the business logic layer is further implemented as a hosted application service provider (ASP).
- ASP hosted application service provider
- the system architecture 10 is an open architecture configured for an ease of integration with a client system.
- ASP capability enables multiple customers to utilize the single database via single instances without having access to data of other customers.
- a resource identifier is included with corresponding data in the database. Data is characterized by system level data and customer specific data. Each customer is required to login to the system and accordingly each customer is assigned an ASP Customer ID. In this manner, the system architecture provides a security mechanism based upon the ASP Customer ID.
- the parameter-based configuration of the system architecture 10 includes base data attributes that are date effective.
- the base data may include one or more of a business associate, facility, point, and accounts.
- the base data may further include one or more of contract party data, deal party data, and transactional data that are rendered date effective.
- the database server 14 of the system architecture 10 further includes security features for partitioning data within the database.
- the applications server 12 is configured to communicate to the database server 14 through database connectivity drivers.
- Data layer (DL) objects 18 (FIG. 3) contained within a module 20 of the applications server 12 can be configured to communicate data to and from the database via database 14 connectivity drivers.
- the business logic layer further includes an object-relational mapping tool 22 configured to provide access between the business logic layer and the database layer.
- the object-relational mapping tool is configured to map objects to database tables 24 (FIG. 3) in the database. Objects created by the object-relational mapping tool are used to query data in the database and to get query results back.
- the system architecture 10 further includes a security layer implemented via one or more of a security server 26, LDAP Security Database 28, and security agents 30 (FIG. 3).
- the security layer operatively connects the configurable business logic server-based layer and is configured to filter requests to the configurable business logic layer according to a system security.
- the security layer is further configured to provide a secure access to the configurable business logic server-based layer, and wherein the business logic server-based layer is further configured to provide security at an object and client company level within the system architecture.
- security can also be provided on a per module (or data object) basis, rendering a finer grain security to the overall system.
- the security implementation provides a secure access to each module according to a user access listing of userids having rights to access and use a respective module (or data object).
- the system architecture 10 further includes a messaging layer 32 operatively connected to the business logic layer.
- the messaging layer is configured to facilitate an XML-based interchange and open messaging transport communication link between the business logic layer and another layer.
- the system architecture 10 still further includes a presentation layer 34 configured to receive at least one of a client request 36, a reporting request 38, a migration request 40, and a third party request 42.
- the messaging layer operatively connects between the presentation layer and the business logic layer. Accordingly, the messaging layer is configured to facilitate an XML-based interchange and open messaging transport communication link between the presentation layer and the business logic layer.
- the system architecture further includes a simple object application protocol (SOAP) server 44 operatively connected to the presentation layer 34 and the messaging layer 32.
- SOAP simple object application protocol
- the simple object application protocol server 44 is configured to provide a message based protocol to carry an XML based payload for accessing the business logic layer 12.
- SOAP provides a means for communicating between the web server 34 and the API's of the application server 12 via XML documents.
- Each module (20 a,b,c,d) of the application server 12 has its own class factory (i.e., each module builds it own classes).
- the class factories and configuration files determine a dynamic direction of a request, whether to the application server or a message. Accordingly, a dynamic proxy is created.
- class factories and configuration files of the web server 34 provide a dynamic proxy applicable to the JSP's and messages.
- the class factory of Base Module 20a is indicated by the reference numeral 46 in FIG. 3.
- the configuration file of the application server 12 is generally indicated by reference numeral 48 of FIG. 3.
- the presentation layer includes a browser based web server 34 presentation layer configured to construct Java Server Pages, handle JSP requests, and provide a functional graphical user interface for handling web requests via JSP controller 50 and JSP view 52 of Figs. 1-3.
- the presentation layer further includes a class factory 54 and a configuration file 56 (FIG. 3).
- the class factory 54 is configured to establish a category of objects defined by common properties of different objects that belong to the class, wherein a path of an incoming request to the business logic layer is dynamically determined as a function of the configuration file and the class factory.
- the path includes either a direct call from the web server 34 to the applications server 12 or a proxy call from the web server 34, through the messaging layer 32, to the applications server 12.
- SOAP SOAP
- the system architecture 10 utilizes SOAP server 44 and configuration file 58 (Fig. 3) for enabling simple object access protocol (SOAP) for communication between software components of the architecture, as disclosed herein.
- SOAP is based on extensible markup language (XML), and is configured for accessing remote objects over a network. Accordingly, SOAP allows access to services, objects, and servers in platform independent environments, thus acting as the common link between heterogeneous software components.
- SOAP is configured to use hypertext transfer protocol (HTML) for transport and XML for data encoding.
- HTML hypertext transfer protocol
- SOAP provides numerous benefits.
- SOAP is a standard protocol and complies with established Internet standards. SOAP is also configured to be language and platform independent.
- SOAP integrates well with Microsoft development tools. Accordingly, SOAP provides simplicity and extensibility.
- FIG. 4 provides a diagram view depicting the structure of a SOAP packet 60.
- the SOAP packet 60 includes an HTTP header 62, a SOAP Action 64, SOAP-ENV: Envelop 66, and SOAP-ENV:Body 68.
- the SOAP-ENV: Envelope includes one or more header elements.
- the SOAP-ENV:Body includes one or more objects, methods, or parameters.
- Operation of SOAP can be described generally as follows.
- a client executes a single method of a function call (limited to one method or function call per HTTP request).
- a server executes the method or the function call and transmits a response.
- the client receives the response including data, and then processes the data.
- the client transmits the data (updated) back to the server in another remote call.
- the client includes a software process for building the SOAP request.
- the software process for the SOAP request may include XML statements.
- the client may also include software processes developed using tools such as Visual Basic (VB), Microsoft SOAP toolkit, and Jscript.
- the server includes a software process for handling the SOAP request, performing the requested method or function, creating the SOAP response, and transmitting the response back to the client.
- the server's software process may include a Java servlet, an active server page (ASP) script code, a
- the client written in Java Server Pages (JSP) may include a GET or a
- the GET method may include the following statement, for example:
- the client executes a GET request to the server.
- the search also returns an XML data set to display in a data grid.
- the server calls EJB objects and the specified method. If the request is successfully handled, then the server translates and formats the data, and returns the data set to the client. If the request is not successfully handled, then an error string is returned to the client.
- the POST method may be invoked by the following statement, for example:
- the browser based web server presentation layer of the system architecture 10 is further configured to deploy at least one item of web browser page content in a manner wherein the deployment of the content mimics a client/server operation.
- Deployment of the at least one item includes placing the at least one item into an ActiveX component 70 within an HTML component 72, as shown in FIG. 5 and as further discussed herein.
- the messaging layer 32 is configured for enabling one or more of the following.
- the messaging layer 32 can be configured to enable an integration of an existing 3 rd party application or business system 42 into the system architecture 10 (Figs. 1,2).
- the messaging layer can be configured to process at least one of a client request 36 and a system request 12, wherein processing the request includes at least one of capturing the request, transforming the request, and routing the request to at least one destination 74 selected from the group consisting of a legacy system destination and a system architecture destination 12.
- the messaging layer 32 may further be configured to implement a client specified business rule prior to accessing core business functionality within the business logic layer.
- the messaging layer 32 may still further be configured to enable bi-directional communication between incompatible ente ⁇ rise applications 74 of a third party (FIG. 3) and the system architecture via messages across a common platform.
- the messaging layer may be configured to enable bi-directional communications between ente ⁇ rise java beans
- EJBs 76 of the business logic layer and an external application 74.
- the system architecture further includes a security layer operatively connected to the presentation layer and the business logic layer for providing a secure access to the presentation layer and the business layer.
- the security layer can include an LDAP compliant database 28 server-based security layer configured to manage userids, passwords, and roles in the system.
- the business logic layer includes a J2EE applications server 12, and wherein the database layer includes a database server 14 separate from the application server.
- the security layer further includes a means for handling EJB security, the security means including for example a security agent 30 operatively connected to the J2EE applications server for filtering requests to the J2EE application server.
- the security layer still further including an application level security means configured to render method level security on objects processed within the applications server for example, via APIs and data bound objects, as further discussed herein.
- system architecture further includes a secure sockets layer connection operatively connected between a client browser and a presentation layer GUI.
- the secure SSL connection creates a unique session id and wherein the messaging layer is further configured to call an appropriate
- the business logic layer of the system architecture includes a Java 2 Platform, Ente ⁇ rise Edition applications server configured for running an applications program of a hierarchy of modules.
- the applications server 12 further includes a configuration file 48 (Figs. 2 and 3) adapted to configure the hierarchy of modules for use in the parameter-based configuration of the at least one business logic service.
- the hierarchy of modules includes a base module 20a, a deals module 20b, an operations module 20c, and an accounting module 20d.
- the system architecture further comprises: (1) a presentation layer configured to receive at least one of a client request 42, a reporting request 38, a migration request 40, and a third party request 42 (FIG.
- the business logic layer includes the applications server for running an applications program of a hierarchy of modules 20a, 20b, 20c, and 20d (Figs. 2 and 3).
- the applications server includes a configuration file 48 adapted to configure the hierarchy of modules for use in the parameter-based configuration of at least one business logic service.
- the hierarchy of modules includes at least a base module 20a.
- the base module 20a is configured to maintain information about baseline data required by the system architecture, including at least one selected from the group consisting of counter-parties, pipelines, nomination points, meters, and units.
- a next module in the hierarchy of modules includes a deals module 20b.
- the deals module 20b includes a contract sub-module configured to maintain information about at least one selected from the groups consisting of buy/sell, transportation, storage, pooling, and capacity release contracts that a client has with the client's customers; contracts and custody contracts containing base agreement information; specifications representing terms, points, quantities, and pricing details that are used for billings and payments; and pricing indices.
- the deals module can further include a deal making sub-module configured to maintain information about transactions and deals of a client, the transactions and deals including at least one selected from the groups consisting of buy and sell deals, broker commissions, multiple pipelines, point-level pricing, multi- component formula-base price calculations, and deal points, quantities and pricing details used for invoices and remittances.
- a deal making sub-module configured to maintain information about transactions and deals of a client, the transactions and deals including at least one selected from the groups consisting of buy and sell deals, broker commissions, multiple pipelines, point-level pricing, multi- component formula-base price calculations, and deal points, quantities and pricing details used for invoices and remittances.
- a further module in the hierarchy of modules includes an operations module 20c (Figs. 2 and 3).
- the operations module 20c includes a nomination sub-module configured to receive and/or create transportation, storage, pooling, and interconnection nominations, and to perform pool-to-pool transfers, the nomination sub- module further configured to process various nomination models, including at least one of GISB and international requirements.
- the operations module 20c may further include a capacity management and confirmations sub-module configured to perform at least one selected from the groups consisting of schedule pipeline capacity and prioritize contractual volumes based on parameter driven scheduling and curtailment rules; enable a user to model a pipeline and to set constraint points and other criteria that permit tariff compliant reduction of flowing volumes; and obtain confirmation of nominated and/or scheduled quantities at the nomination point level by operator, agent, or shipper.
- the operations module 20c may further include an allocations and balancing sub-module configured to perform at least one selected from the groups consisting of maintain allocations information including configurations of tiers, PDA Rules, and rules; and accept meter and point information and calculate imbalances and point variances based on nominated, scheduled, and measured volumes.
- a yet further module in the hierarchy of modules includes an accounting module 20d.
- the accounting module includes an accounting and settlement module configured to provide at least one selected from the groups consisting of provide necessary processing to consolidate all the contracts, deals, scheduling and allocations information for generating invoices and/or remittances for a client; support external penalty calculations configurable for differing pipeline tariffs; specify override rates and prices, process prior month adjustments, and calculate taxes; G/L account assignment, calculation of accruals for business not yet finalized, and support of interfaces to external General Ledger and Accounts Receivable systems.
- At least one module of the hierarchy of modules includes (i) a class factory and (ii) one or more of (a) an API ente ⁇ rise java bean component 76 operatively connected to an object-relational mapping tool 22 and (b) an API ente ⁇ rise java bean component operatively connected to (bl) an EJB ente ⁇ rise java bean object 78, (b2) a data layer (DL) object 18, and (b3) one or more of a class factory and an API ente ⁇ rise java bean component of another of the modules in the hierarchy of modules.
- the class factory is configured to establish for a respective module a category of objects defined by common properties of different objects that belong to the class.
- the class factory 46 includes a base class factory configured to establish a category of base objects defined by common properties of different objects that belong to the base class.
- the base objects may include one or more of counter-parties, pipelines, nomination points, meters, and units.
- the respective class factory includes a deals class factory configured to establish a category of deals objects defined by common properties of different objects that belong to the deals class.
- the deals objects may include one or more of contracts, pricing, deal making, and transactions.
- the respective class factory includes an operations class factory configured to establish a category of operations objects defined by common properties of different objects that belong to the operations class.
- the operations objects may include one or more of nominations, capacity management, capacity confirmations, allocations, and balancing.
- the respective class factory includes an accounting class factory configured to establish a category of accounting objects defined by common properties of different objects that belong to the accounting class.
- the accounting objects may include one or more of invoices and remittances.
- the customer may choose to implement the customer's own accounting module and operations module.
- the API ente ⁇ rise java bean component 76 is configured to establish a common interface of EJB ente ⁇ rise java bean components 78.
- the API ente ⁇ rise java bean component 76 is further configured to execute an entity validation utility for validating incoming data prior to routing the data to an EJB ente ⁇ rise java bean component 78.
- the application server 12 further includes a method for validating data received via the messaging layer 32, prior to placing the data into the database 14. Accordingly, the application server 12 provides a means for performing entity validation as a standard method to do validation and provide consistent error messages.
- the EJB ente ⁇ rise java bean component 78 is further configured to act as a remote object to a calling API ente ⁇ rise java bean component 76.
- the EJB ente ⁇ rise java bean component 78 is further configured to carry out a parameter based business rule for a respective class.
- the configuration file 48 contains configuration information for the applications program. Responsive to an execution of the applications program, the applications program accesses the configuration file 48 to identify parameters that are in effect for the at least one business logic service.
- the business logic layer includes at least one module for performing the at least one business logic service.
- the business logic service includes a parameter based configuration.
- the parameter based configuration includes date and time effective attributes.
- the web server 34 includes templates 53 for building the GUIs for the various screen views of the applications.
- the templates are configured to provide a look and feel like that of separate applications.
- XSDs XML Schema Documents
- the XSDs include tree level structures, for example, Deal includes Price, Volume, Counte ⁇ arty [0-n], and Location (an object), further wherein each Counte ⁇ arty includes legal name, and each Location includes a name. All data includes data bound objects.
- the deployed web pages of an application are configured to run as a client/server environment. Accordingly, the applications implemented via the GUIs appear more responsive, that is, handling incremental changes within a web page without having to perform an entire refresh of the web page.
- the application may require serving up different languages and data sets for translation.
- Implementation of the translation can include use of term tables having, for example, term_id, termset_id, language, and term. Implementation may further include filtering data, formatting data, and translating data via the GUI front-end.
- ActiveX components are contained within an HTML component (HTC) as discussed with respect to Fig. 5. This simplifies the building of web pages, creating a layer of abstraction by substituting out code.
- tags are customized for a given control function. For example, tags may include ⁇ JSP: grid> or ⁇ JSP: combo box> for dynamic insertion of appropriate data into a corresponding location on a GUI screen.
- the data for the tags may be saved, for example, as a user preference.
- the architecture can be divided into five different layers.
- the layers include a presentation layer, a security layer, a messaging layer, a business logic layer, and a database layer.
- Each of the layers is loosely coupled to the other layers.
- any one or more of the layers may be swapped out and replaced by a custom layer to meet the needs of a particular energy management application and/or customer.
- the architecture's presentation layer is browser based.
- a web server 34 constructs pages using Java Server Pages (JSPTM) on the web server.
- JSPTM Java Server Pages
- the presentation layer also follows W3CTM standards for HTML and JavaScriptTM code, as may be appropriate for a particular implementation.
- a browser implementation for use in connection with the presentation layer can include Microsoft Internet ExplorerTM version 5.5 or higher, available from MicrosoftTM Co ⁇ oration.
- GUI graphical user interface
- a web tier implements the presentation layer.
- the web tier is configured to handle web and JSP requests, for example via a server running on a WindowsTM 2000 Server operating system. Alternatively, SolarisTM, AIXTM, and LinuxTM may also be used to support the web tier.
- the application server may include an Orion, BEA Weblogic IntegrationTM, or IBM's WebSphereTM, or other suitable server, for example.
- Business Logic Layer According to one embodiment, the business logic is written in JavaTM and contained in stateless session beans running in a J2EETM environment on an application server. Data access is handled through TopLinkTM mapped objects. Top level objects follow the naming convention of ⁇ DomainObject>API.
- the stateless session beans are designed to manipulate complex data structures and run processing logic. Data is passed into them using an XML mapped object.
- the XML mapped object is automatically constructed from XML within the SOAP server before being passed to the bean. All of the system's XML bound objects have an attribute that controls it's processing (CREATE.UPDATE.DELETE). Accordingly, a single method (“process(DataObject)”) is generally used for all data processing requests.
- a Lightweight Directory Access Protocol (LDAP) compliant database manages user id's, passwords, and roles in the system. Accordingly, the system architecture is configured to integrate with existing security architectures, such as MicrosoftTM Windows NTTM Domain servers, or NetscapeTM LDAP servers.
- a third party security product for example, EnTegrityTM, is configured to handle security for EJBs and is operatively connected to the web server, filtering all requests coming in.
- Application level security is handled through a built-in mechanism in J2EE that allows for very granular security down to the method level on all objects.
- SSL Secure Sockets Layer
- -87/39 terminates upon a timeout of 30 minutes of inactivity, the timeout being configurable by the system administrator, for example.
- a user id, password, and session id are sent to the messaging layer so that the messaging layer can call the appropriate ente ⁇ rise beans under the correct credentials.
- the messaging layer offers a simple way to integrate existing business systems seamlessly into the architecture of the present disclosure. Since all work requests from a client pass through the messaging layer, the architecture is configured to capture, transform and route requests to different destinations.
- the architecture directs accounting requests over to the legacy system.
- the messaging layer can be configured to direct a copy of the corresponding accounting requests/messages to the relevant accounting system of the system architecture, as well as, over to the company's legacy system.
- the messaging can be configured to enable the particular workflow procedure to take place.
- the message to create a new order can be captured, routed to the supervisor, then forwarded onto the Ente ⁇ rise JavaBeansTM layer when approved, without having accessed the core business functionality.
- the messaging layer facilitates the creation of a very extensible architecture. While every customer may not require or need the flexibility offered by the messaging layer, the API's used to access backend services can be switched to go directly to the Ente ⁇ rise JavaBeans layer. This can be accomplished by making a configuration change and then re-starting the web server. If a customer's particular business requirements are to go directly to the Ente ⁇ rise JavaBeans layer, then the customer has an option to extend the application via suitable Java code for implementing the interfaces of the system architecture.
- the messaging layer is implemented with the use of commercially available messaging technology middleware, for example, available from TIBCO or WebMethods.
- the messaging layer includes messaging software configured to enable bi-directional communications between incompatible ente ⁇ rise applications by transporting messages between the applications across a common platform.
- the messaging layer enables bi-directional communications between EJBs and other applications.
- the interface into the messaging layer is configured in a manner so that supporting other middleware protocols is possible with relatively minimal effort.
- the database is run on a separate server from the application server and web server.
- the database layer can be implemented to run on OracleTM 8i and Microsoft SQL-Server 2000.
- the installation of the database is configured to run in an ASP (Application Service Provider) mode, the database preferably including additional security features for partitioning data.
- the application server communicates to the database through JDBCTM drivers.
- the database uses an Oracle JDBC-OCI driver.
- the Microsoft SQL-Server 2000 uses a pure Java JDBC driver.
- the architecture's database access is handled through an Object-Relational mapping tool, such as TopLink, which is commercially available from WebGain Inc. of Santa Clara, CA.
- TopLink is commercially available from WebGain Inc. of Santa Clara, CA.
- objects created from the mapping tool are used to both query the data and get the results back.
- Java objects mapped to database tables are transparently stored in the relational database without SQL coding. Accordingly, rather than using entity beans, the same effect is achieved through the mapping tool in a much lighter weight and more flexible fashion.
- the presentation layer is configured to utilize a web browser or graphical user interface (GUI).
- GUI graphical user interface
- the web browser can include Microsoft Internet Explorer (IE) or any other suitable browser.
- IE Microsoft Internet Explorer
- the GUI is made W3C compliant, as much as possible, and may include a number of advanced IE features. Specifically, IE behaviors are used to create client-side components, and data binding is used to display XML data in tables. All color, font, and style details are stored in a separate CSS (Cascading Style Sheet) file so that any changes and customizations can be easily handled without having to modify the JSP code of the presentation layer.
- CSS CSS
- GUI is configured to be highly responsive to a system user. From the users perspective, the GUI acts and feels like a stand-alone application, rather than a web page.
- the GUI accomplishes this through rich controls, such as popup menus, calendar components, and simple form validation used within the browser.
- client side scripting is done in JavaScript.
- the controls are created using ActiveXTM to provide a desired performance and functionality.
- the controls are wrapped by an HTML component (HTC) so that existing terms will not have to change.
- the controls include, for example, a grid control, a combo box control, and a date picker control.
- the client application is written in Java Server Pages (JSP).
- JSP Java Server Pages
- the client application provides for a clean separation of the business logic and the HTML results.
- a "controller" servlet/jsp page handles an initial request from a client or system user.
- the "controller" servelet/jsp page takes the appropriate business actions, stores the results in a request variable, then forwards the results to a view page.
- the view page creates the HTML needed to display the results back to the client, via the web browser.
- the benefits of the above-described client application include an ability to cleanly break the client interface into graphical user interfaces (GUI's), separate from business rules and work flow, without having the business rules and work flow be concerned about the client display.
- GUI graphical user interfaces
- the client application is configured to the system architecture to substitute different views dynamically based upon the particular client request. For example, if static pages were created containing different language settings, a controller servlet/jsp page could automatically route the results to the correct language page based on the client's local
- an automated system might want to submit a request to a web page and get the results back as XML.
- a separate jsp page could be created to format an XML response, instead of the normal HTML response. This can be accomplished without having to change the business logic flow of the controller.
- user profiles and customization can be stored in the database and loaded into a session variable after a user logs into the system. Access to the user profiles and customization can be accomplished through a design pattern similar to other database data (i.e., XmlRowsets returned from a session bean). Controller Responsibilities
- the controller is responsible for and configured to collect all information required by a view, as well as to ensure that the information required for the action is present.
- the controller is further responsible for ensuring that the user is properly logged on.
- the controller is still further responsible for creating a connection to the "business abstraction layer"; calling the remote methods to execute the business logic; and making a call to a bean to accomplish a particular action.
- the information may include data for drop down lists, information for grids, etc. Ensuring that the information required for the action is present may refer, for example, to checking to ensure that the user did not forget to enter any critical fields. Note, however, the controller is only responsible for ensuring the information is there and that it can be parsed into the correct data type. The controller is not responsible for the validity of the information.
- business abstraction layer can be created by a remote interface to an ente ⁇ rise bean in a pure J2EE application, or to the messaging system.
- calls across to the ente ⁇ rise beans are course grained.
- the controller should be able to make one call to a bean to accomplish an action - not a separate call for each step.
- the view JSP pages are responsible for the formatting of results according to needs of a corresponding client, managing display level security, handling client side business logic, handling language translation and unit conversion, and configuring the GUI based on user preferences and security settings.
- Fonnatting the results according to the way the client wants them may include, for example, creating HTML or XML to output to the client.
- Managing display level security may include restricting a user to a subset of buttons or menu choices for a particular GUI.
- Client side business logic includes JavaScript on the client computer.
- JSP taglibs are configured to handle unit conversion, date/time localization, language translation and number formatting.
- the client presentation layer is written in JSP with an emphasis on keeping embedded Java code to a minimum, as much as possible.
- the view pages are designed to fit within a template based upon the pinpose of the screen or view. Accordingly, a page type is characterized by a corresponding template. Each individual page puts different content within a series of defining tags, which the template is responsible for rendering. This allows the entire look and feel of the application to change simply by modifying the template.
- the pages of the present architecture are designed to allow a user to submit changes and requests without requiring a reloading of the page. This is accomplished through the SOAP interface and Javascript. All of the grids on the screen are populated post-load from a URL, for example, via a modified SOAP call. Combo Boxes can be populated either pre-load on the JSP side or post- load through a URL the same way the grid controls are.
- Complex information is submitted to the EJB layer by embedding XML within a SOAP call.
- most of the business objects in the system are modeled in XML and defined in a schema document. As a result, this XML is configured as a primary means of manipulating data within the system.
- a mediator is created to sit between the web page and the EJB side.
- the mediator is a standard Java class 80 that runs locally on the webserver box 34 and is accessed through SOAP 44 (Fig. 3).
- This Java class has access to the user's session object, which is used to store intermediate data.
- the pu ⁇ ose of the mediator is to allow the user to manipulate complex data in an environment that is isolated to him, then submit the changes all at once to the EJBs. It also allows the view of the data to be customized without having to change the EJBs feeding that data. User preferences for such things as grid column sizing and placement will be handled through a custom JSP tag.
- the system architecture includes a J2EE application running on a
- the J2EE application is made up of the following file types: java, .class, jar, jsp, jpx, and .ejbg ⁇ .
- the file type java are Java language code files. These Java language code files are compiled to .class files. The .class are then used to create jar files. The jar files contain compiled source code (.class files). The jar files are similar to Zip files. The jsp files are used to generate the web pages and require no compilation.
- the jpx files contain a JBuilder project and will typically reference one or more .ejbg ⁇ files.
- the .ejbg ⁇ files represent a deployable entity that contains one or more Ente ⁇ rise Java Beans.
- the .ejbg ⁇ files also contain deployment descriptors that are used by an EJB server to run. Furthermore, the .ejbgrp files can be selected to generate jar files.
- Application Level Security on the client side includes deciding which pages a user can view, and what options the user has on the pages the user can view. According to one embodiment, all security configurations are formulated within the scope of a user's role. On the JSP page, configuration fragments are wrapped within a taglib entry. Everything between the tags are included if the user has the proper role. A more permission based security approach may also be used.
- Integration is the ability to tie the system of the present embodiments with other systems, including pre-existing systems.
- a client company may have its own accounting system that the client wants to use in place of the accounting system running on the system of the present disclosure.
- Another scenario may include the client company having an accounting system that handles its co ⁇ orate books that the client desires to keep updated with information from the gas accounting system of the system according to another embodiment.
- the client company substitutes one system for the other.
- the client company uses the accounting system of one embodiment of the present disclosure, while comparing the calls in real-time to drive a second system. In either instance, it is an entire subsystem that is being affected.
- API Program Interface
- Extension and customization of the system architecture of the present disclosure is accomplished through standard EJB means. This involves writing a class in Java that either extends the system bean, or implements the system's remote interface, and then configuring the ejb-jar.xml to point to the new bean. While in theory this could be accomplished in the messaging layer, that technique is much more complicated, the performance is slower and maintenance is complex. While there are some disadvantages to limiting extensions and customizations to the EJB layer (i.e., coding is in Java, make upgrades slightly more complex), march the advantages far outweigh them.
- a class factory provides all access to the Ente ⁇ rise Java Beans.
- a separate class factory is provided for every module in the system. All modules have an abstract factory class that serves as the interface to the create functions and an EJB and Proxy implementation of the class.
- a runtime property with the name of the abstract class defines which implementation is actually returned when a class factory is requested.
- the base module there is an abstract class named "com.altra.base.BaseClassFactory.”
- JNDI Java Naming and Directory Interface
- Every Ente ⁇ rise JavaBean includes a Proxy object that implements the bean's remote interface and extends BaseProxy.
- the Proxy packages the parameters up as an array of objects and calls a method in the base class to send the message and wait for the results.
- the object name is dynamically detennined by the base class function getObjectNameForMessage().
- the pmpose of messaging is integration, as opposed to extensibility.
- ACID transactions are only supported with straight EJB calls (or possibly to CORBATM services depending on the application service provider).
- ACID is an acronym used to describe the four properties of an ente ⁇ rise level transaction, i.e., atomicity, consistency, isolation, and durability.
- the override is preferably done within the EJB space.
- a properties file informs the client which network to connect to and which subject prefix to use when publishing messages.
- the properties file is located under a directory in which a middleware proxy application (i.e., the MiddlewareProxyApp) is started.
- the subjectPrefix parameter is the prefix that will be pre-pended to all published TIBCO messages and allows different levels such as development, QA, Production, etc. to exist on the same network bus. For example, “JEDIJD” can be used for development, "JEDI Q” for QA, and "JEDI” for production.
- the application listens only for messages that begin with the subjectPrefix stated in its property file.
- the Middleware Proxy App is a stand-alone application that listens for messages from the client, makes the requested EJB call for the client, and then returns the results.
- the middleware proxy app is multithreaded and employs bean caching for all stateless session beans.
- the application also supports stateful session beans through the object ID parameter ("oid"). If the client desires to create a stateful session bean, the client can do so by sending a "CREATE_OBJECT" message to the middleware proxy app. This can be accomplished by using a remote caller to create a remote object (i.e., RemoteCalIer.createRemoteObject()).
- the middleware creates the object and returns an object id to the client.
- a bat file is created and run.
- API Message Protocol Regardless of which vendor messaging system is selected for implementing messaging, the messages passed between objects should contain the same information.
- the format for these definitions assumes a "Publish/Subscribe" metaphor where the client publishes the request to a subject defined by a string. It is assumed in all these API calls that the given subject is prefixed by a string that identifies which system it should be running on (for example, "CAMINUS.ETM").
- the API calls include a REMOTE METHOD CALL, a REMOTE METHOD
- the REMOTE METHOD CALL defines a message indicative that the client wants to execute a remote method, with RPC as the subject.
- the REMOTE METHOD CALL RESPONSE defines a message returned by the middleware to the calling client.
- the CREATE REMOTE OBJECT defines a message indicative that the client desires to create a remote object that requires conversational support, for example, StatefuU session beans.
- the reply message will be the same as the RPC call, with the result field being a string that contains the remote ObjectlD. See, for example, Figures 6, 7, and 8 containing additional detail.
- all communications end up going through a messaging layer, and only simple Java types are supported for method parameters and return types.
- Simple types include String, Long,
- the com.altra.common.XmlRowSet provides a standard data passing mechanism for all return types requiring complex data. In the straight EJB implementation, this is passed around as a CachedRowSet with all the data stored internally. If the CachedRowSet is used throughout messaging, it is converted into an XML string before being returned to the client.
- the base class includes methods for obtaining database connections, getting user information and handling logging.
- the EJB layer is divided into two classes - a Base class which only contains generated code and the actual bean class which extends the Base class.
- the naming convention for this layer can include RemotelnterfaceBase and RemotelnterfaceEJB, for example.
- Figure 9 illustrates one embodiment of the EJB layer divided into two classes.
- a separate object handles the database interaction. While the data layer includes similar method names as the EJB layer, the methods have different responsibilities. The EJB layer is responsible for all validations of the data and the DL layer is responsible for actually putting the data in the database.
- the data layer like the EJB layer is split into two classes.
- a BeanDLBase is generated from the code generator and contains constants for the tables and columns used by the bean, as well as a default implementation of all the data access functions.
- a second class BeanDL extends BeanDLBase and is where custom code and method overrides occur. Modifying code in the DL layer alone enables regeneration of the underlying code.
- the system is configured to manipulate the data as objects instead of just RowSets.
- the use of Entity beans may be insufficient.
- Container managed beans may lack necessary capabilities and Bean managed beans may be too slow for the large volume data queries needed.
- manipulation of the data as objects can be accomplished with the use of the TopLink relational mapping tool to manage O-R mapping and data management.
- O-R mapping can be accomplished through the TopLink graphical mapping tool, then encoded into a Java class (e.g., etmProject.java).
- a Java class e.g., etmProject.java
- header tables in the system architecture are configured to provide a unique master ID key for an associated detail table.
- the respective header tables have no corresponding EJB component. Rather, these header tables only have a Data Access Layer component. Accordingly, the DL component is called by the detail table's data access layer alone.
- the EJB layer "create” method is called to create a detail record.
- the header table's Data Access Layer “create” method is called to generate a new header record.
- the detail table's EJB Layer “create” method will call the EJB Layer “create” method with the ID key of the header record created.
- the detail table's EJB Layer “create” method will also return the ID key of the header record created.
- the detail table's EJB Layer “remove” method is called to remove all detail records for the corresponding header record.
- the header table's Data Access Layer “remove” method is called to delete the corresponding header record. This occurs after the records have been deleted from the detail table. Note that some header tables will contain information other than an ID key for detail records.
- these other header tables will have a corresponding EJB component.
- header tables gain more importance once they represent the foreign key that all children point to. Every table in the database will eventually be mapped to an object, including header tables.
- the data tree can either be built to flow down the hierarchy (child has foreign key to parent) or up the hierarchy (parent has foreign key to child) based on the domain object. For most objects, the flow is down. For example, consider the tables of FIG. 10.
- the object tree resembles the following:
- the energy market trading system, software, and method are directed to energy marketing and trading, and in particular, marketing deals and nominations.
- the energy market trading system provides a real-time system configured for use by traders, schedulers, and other system users.
- the system matches a workflow for system users and includes a number of usability features, as further discussed herein.
- the energy market trading system is adaptable to meet a customer's business needs and requirements.
- the system includes software and hardware modules configured to provide a high degree of flexibility, scalability, and extensibility, for example, with the use of parameter driven business rules.
- the system also provides extensive hourly and sub-hourly capabilities.
- System modules handle one or more of multi-currency, multi-unit, and multi-commodity energy marketing and trading requirements.
- the system modules further provide for a multi-language support. Implementation of the system can be accomplished via a hosted ASP or be locally deployable.
- the system is
- the energy market trading system, software, and method embodiments of the present disclosure provide a model for coupling a) contracts and deals with b) accounting via a single operations model architecture. That is, the system model operations architecture processes one or more of purchase, pooling, transportation, imbalance, sale, storage, and inventory between a) contract and deals and b) accounting.
- Functional examples of the operations model architecture include date effectiveness, deal entry, a pricing model, position management, inventory accounts, and nominations, as further discussed below.
- the architecture is configured to include base data attributes that are date effective.
- base data corresponding to business associates, facilities, points, and accounts are configured to include date effective attributes.
- Date effective attributes enable tracking of changes in base data according to corresponding attributes over time. For example, a company name may change on a particular date, as indicated via a date effective attribute. Accordingly, on any given date, the energy trading and marketing system identifies the company by its most current name, as per the date effective attribute.
- the base data attributes enable the energy trading and marketing system to maintain accurate, reproducible results.
- the energy trading and marketing system In addition to base data attributes, contract and deal parties are rendered date effective. Accordingly, the energy trading and marketing system supports mergers, acquisitions, and reassignments. Furthermore, with the system, all transactional data is time based. Accordingly, the system can perform auditing for all transactional data via the date effective attributes associated with transactional data.
- deal entry the energy trading and marketing system addresses and supports a number of deal types, including physical gas deal types, financial gas deal types, and scratchpad deals.
- the physical gas deal types can include one or more of purchase, sales, transportation, capacity release, and storage.
- the financial gas deal types can include one or more of swaps, futures, and options.
- the scratchpad deals provides a workspace for one or more partial deals, pending deals, and "what if deals. In addition to supporting different deal types, the system facilitates quick deal entry via its usability.
- the system provides quick deal entry with the use of multiple sets of preferences by user (search, displays, defaults), templates, price packages, profiles/patterns, and duplicate functionality.
- System time intervals include at least one of monthly, daily, hourly, sub-hourly, and patterns/profiles.
- the system further provides support for deals at trading locations, as well as a portfolio/book structure for deal entry.
- the pricing model the system includes a common logic model that applies across the entire application, including one or more of contracts, deals, purchases, sales, transportation, storage, imbalance penalties, cash in, cash out, and inventory valuation, in any combination.
- the system applies pricing with the pricing model in connection with contract, deal, and location, as well as with defaults, overrides, and best fit logic. Accordingly, the pricing model offers flexibility and consistency. With respect to flexibility, the pricing model includes price formulas and quantity formulas, as well as extensive tier-ing scenarios. The pricing model utilizes any quantity type within the system. Furthermore, the pricing model offers flexibility in price packages and templates.
- the pricing model offers familiarity and consistency for users across the system.
- the pricing model includes a single pricing engine for generation of consistent results. Furthermore, a single price resolution mechanism of the pricing model provides for easy reporting.
- the pricing engine includes a computer program configured to execute instructions according to various functionalities of the pricing model, as discussed herein, using programming techniques known in the art.
- the system architecture provides tracking of a deal by one or many positions. Positions are the foundation for managing exposure in cash and future periods.
- the system architecture is configured to split positions across multiple books/portfolios.
- the system architecture also provides support for transferring positions between books/portfolios.
- the system architecture is configured to enable viewing of exposures by point, trading location, point groups, books and portfolios.
- the system architecture includes a configurable grouping mechanism for transactions.
- the configurable grouping mechanism supports one or more of balance calculations, imbalance management, cash in/cash out, imbalance trading, storage balances, interconnect balances, pool balances, inventory valuation, and inventory penalties.
- the system architecture provides support for grouping of inventory accounts for roll up pu ⁇ oses.
- the grouping mechanism utilizes price structures for penalties, valuation, cash in, and cash out.
- the system architecture includes a full featured nominations interface.
- the nominations interface is configured to optimize scheduler's workflow.
- the nominations interface provides support for partial nominations (e.g., in progress), duplicate functionality, support for hourly and sub-hourly nomination, profile/pattern support, and focuses on usability and optimizing schedulers' workflow.
- the nominations interface is configured to track movements between deals and/or inventory accounts.
- Details inco ⁇ orated into the system architecture of the embodiments of the present disclosure include an object oriented design, a fully web enabled user interface, extensibility via plug in modules, use of published API's, security at the object and client company level, as well as, audit capabilities for all transactional data. Extensibility via the plug in modules provides an ability to readily adapt custom requirements into the base portion of the system architecture.
- the published API's provide a standardized mechanism for information exchange within the system architecture and with external applications as well.
- the system modules communicate with one another via API's.
- the API's insulate the graphical user interface (GUI), reports, interface and custom applications from the architecture's database and any database changes.
- GUI graphical user interface
- the API's use an XML-based interchange and open messaging transport. Accordingly, the API's facilitate real-time integration with other systems, such as, Risk, Exchange, and similar systems.
- the modules of the system architecture can be extended and/or replaced if desired for a particular implementation, via the API.
- the system architecture according to one embodiment of the present disclosure includes a single multi-tiered architecture for operatively connecting different client systems into an integrated system utilizing a common interface method.
- the system architecture further provides for data migration from a source database to a target database of the system architecture using a data preparation application, a staging preparation database, and a
- the migration application is operatively connected to the messaging layer.
- Messaging and business layer logic exercises the API and provides validated database entities on the target database.
- the international pipeline and gas marketing market is following the U.S. market in its movement towards a deregulated and unbundled marketplace. This presents the need to address non-U.S. pipeline requirements, while maintaining GISB-compliance to address US market requirements. Accordingly, the system architecture provides a flexible product in support of the international market, further to provide international software that can easily handle regional settings and languages.
- the system architecture of the present disclosure provides a highly scalable product that can perform satisfactorily in both small and large implementations.
- the system architecture also provides a flexible product that can be functionally configured to address the varied requirements of small and large pipelines alike.
- the system of the present disclosure can be adapted to serve at least some of the business needs of the local distribution companies. These companies will need highly flexible systems that can effectively work with other systems and the somewhat unique requirements of the localities they serve.
- the system of the present disclosure can be applied for use in the upstream production and gathering areas of the gas marketplace, in that the system can be configured and tailored to satisfy their needs.
- the system of the present disclosure offers integration, flexibility and extensibility to allow for the inco ⁇ oration of the most advanced analytics and optimization tools available in support of front office analytics and optimizations techniques of energy marketing and trading companies.
- the system further provides a web-based product to support a variety of clients and that can be accessed through multiple browsers and platforms.
- system architecture integrates open browser support, e-mail, fax, instant messaging and integration with external systems to meet the needs of increasing growth of B2B (business to business) commerce.
- the system also provides a highly scalable and configurable architecture with enhanced security and access services to meet growing demand for an Application Service Provider system solution.
- the system architecture of the present disclosure provides reater flexibility in structuring deals. Capabilities include support for deals spanning multiple pipelines, more sophisticated deal pricing capabilities, deal pricing at the transaction point level and user specifiable rounding techniques.
- a key aspect of a good gas pipeline and marketing system is demonstrated in how meter and station level information is entered and maintained.
- the system architecture of the present disclosure distinguishes between stations of a gas pipeline and marketing system, which are logical nomination points, and meters, which are physical measurement devices. Furthermore, certain station information, such as zone, maximum daily capacity, taxing jurisdiction, etc. are date-sensitive in the system architecture. To meet these growing needs of the domestic and international gas pipeline market, the system architecture restructures the way meter and station data is retained and managed.
- the system architecture supports hourly changes to nominations and is configured to comply with GISB intra-day nomination change requirements.
- the system architecture recognizes aspects of hourly business, such as individual hourly nominations, measurement, allocations or settlement.
- the system architecture is further configured to measure, allocate and calculate penalties for hourly variances.
- the system architecture also contemplates future hourly pipeline services that are likely to include hourly (or time of day) service rates and invoice settlements.
- the system architecture provides support to manage customer business cycle intervals other than on a calendar month basis. For example, using time effective base data, the system provides the functional capability to invoice on a semi-monthly, quarterly or annual basis, as well as, on a non-calendar month business cycle basis.
- the system implements a multi-tier system architecture with clean logical componentization and parameterization, thus providing the larger pipeline market with a highly scalable, functional and flexible energy market trading and transaction product.
- the system architecture facilitates easy external customization through applications programming interfaces (APIs) that can be configured to handle the unique needs of a particular pipeline (such as penalty calculations).
- APIs applications programming interfaces
- the gas and pipeline marketing and transaction management solution of the present disclosure addresses new and enhanced functionality as described herein as well as having an ability to address the emerging domestic and international requirements. A brief discussion of some of the functionality of the gas and pipeline marketing and transaction management solution are provided below.
- the base information module maintains information about baseline data required by the rest of the system, such as, Counter-Parties, Pipelines, Nomination Points, Meters, Units, Currencies, Rates etc.
- the contracts module maintains information about buy/sell, transportation, storage, pooling and capacity release contracts that the marketer or pipeline has with its customers.
- the contracts module includes Title Contracts and Custody Contracts containing base agreement information, and specifications representing terms, points, quantities and pricing details that are used for billings and payments. Additionally, pricing indices are maintained within the contracts module.
- the Deal Making module maintains information about the transactions and deals that marketers are involved in.
- the module includes Buy and Sell deals along with other applicable transactions such as broker commissions. Provisions for multiple pipelines and point-level pricing are included along with complex multiple-component formula-based price calculations. Deals points, quantities and pricing details are used for invoices and remittances.
- the Nomination module is configured to receive and/or create transportation, storage, pooling and interconnect nominations, and to perform pool-to-pool transfers.
- the module provides the capability to handle various nomination models, including GISB and international requirements.
- the capacity management and confirmations module is configured to enable scheduling of pipeline capacity and prioritize contractual volumes based on parameter-driven scheduling and curtailment rules.
- the function of the capacity management and confirmation module allows the user to model a pipeline and to set constraint points and other criteria that permit tariff compliant reduction of flowing volumes.
- the module is
- -74/39 also configured to provide confirmation of nominated and/or scheduled quantities at the nomination point level by operator, agent or shipper.
- the allocations and balancing module maintains allocations information including configurations of tiers, PDA Rules, and rules.
- the module accepts meter and point infonnation and calculates imbalances and point variances based on nominated, scheduled and measured volumes.
- the accounting and settlement module provides suitable processing to consolidate all contracts, deals, scheduling and allocations information for generating invoices and/or remittances for the marketer or pipeline customers.
- the module also supports external penalty calculations to be configurable with differing pipeline tariffs. Other capabilities include specification of override rates and prices, processing of prior month adjustments, and calculation of taxes.
- the accounting and settlement module also includes G/L account assignment, calculation of accruals for business not yet finalized, and support of interfaces to external General
- Imbalance Cashln CashOut is related to the requirements of Charge Processing, Charge Management, and Inventory Account Management, which describe the balance levels and the rules surrounding the calculation of the imbalance quantity.
- the process of Cashln and CashOut involves the increase or reduction of the imbalance quantity and creating an associated charge.
- a Cashln is usually from the aspect of increasing or establishing an imbalance quantity.
- a CashOut is usually from the aspect of decreasing or removing an imbalance quantity.
- these requirements do not limit the direction of imbalance adjustment.
- Auto CashOut uses user defined cashout rules associated with an Inventory Account of Imbalance that will control the creation of charges and adjustment of imbalance based on desired rules.
- Manual CashOut /Cashln requires the user to enter the quantity and the price for each increase or reduction.
- Prior Period Adjustments of imbalance are supported. The effect of these prior period adjustments can cascade through many periods of imbalance. Any charges or penalty-based charges can be reversed and adjusted.
- Charge Management is related to the requirements of Charge Processing and Accounting Requirements.
- the main business requirements related to managing generated charges are: viewing charges, approving charges, updating charges, managing charge statuses, and finalizing charges as outlined below.
- a user can go to one screen to accomplish one or more of these functions.
- Charge Processing is related to the requirements of Price Management, Deal Maker, Accounts, Contract Administration, Imbalance Cashln/CashOut and Gas Control.
- Charges produced by the Energy Transaction Accounting System represent the types of activities priced at any of the defined objects.
- Various types of charge calculations can be performed and business charges generated. The calculation methods or algorithms can be user supplied which offers flexibility in charge production.
- Taxes are significantly different from regular charges in their timing and application. Multiple jurisdictions can apply to a location with each having multiple tax types and multiple exemptions. Margins. Volume Reconciliation and Valuations
- Margin Analysis and Volume Reconciliation are business activities that provide summarized information on quantities and dollars. Margin analysis places emphasis on the dollars, while volume reconciliation places the emphasis on the quantities.
- Margin analysis includes operating P&L and Balance Sheet views. These views provide summarization and comparison of revenues vs. expenses and balance sheet items in order to estimate or analyze the margin, assets, and liabilities of the organization. Organizations use different methods to calculate their margin and deferrals, so there must be flexibility in defining charges as revenue, expense, asset or liability.
- Statement Management Statement Management relates to the requirements of Charge Management and introduces the requirements of statement generation separately from charge generation and management. Subsequent statement generation will be using grouped charges to produce a statement.
- Charges will default to be grouped by Account and manual grouping (overriding the Account) can occur if required. Only those charges that have been approved/updated are available for the statement generation process unless a parameter has been defined stating approval of charges is not required. Once charges are processed for statement generation, records are written to the statement table.
- the print process can be separate and external to the statement generation function found in the system.
- the capability to view charges is provided from the perspective of statement generation if needed for an external process.
- the statement data is one of the sources for sub-ledger or GL interfaces.
- Accounting Support Management has functions that will precede charge process (i.e. Price Component definition, Tax Rate Management) while others can follow charge production (i.e. Accrual Management or Accounting Close). Many of these functions are optional depending on the business rules to be enforced within a company.
- Account Management is an integral part of the overall accounting process and requires familiarity with the requirements for Business Associates Management.
- An Account is a grouping of charges for settlement and will be used for statement generation and processing parameters. Accounts provide the ability to group or segregate charges. Grouping all Purchase and Sales activities on one statement will support a statement-netting requirement and can separate the statements by activity type.
- Account Groups supports the linking of multiple Accounts. Account Groups allow flexibility in determining which Business Associate(s) are responsible for the accounting and which get copies only of the statements. Pricing may be at the Account level, as opposed to the Contract or Deal level. For example, Broker
- Fees or Subscription Fees may apply to a Business Associate, regardless of any trading or contractual activity that may occur.
- the Account information may include, for example, one or more of: Entity; Business Associate; Type of Account; Language to be used for the Statement; Currency; or Statement Terms.
- a Business Associate is defined as any party with whom the owner of the system is doing business or tracking transactions and may be a co ⁇ oration, company, or an individual.
- Business Associate Management includes the maintenance of all information that is associated with a Business Associate. Most of the information will be maintainable on a date effective basis, due to the high number of mergers, acquisitions, and name changes. The Business Associate Information change history will be readily accessible to users.
- Business Associate Management also includes the maintenance of Entity information - who is the 'owner' of the information contained within the system, who generates statements for the customers, etc.
- System users may have an interest in maintaining contact information, which is an integral part of Business Associate Management, however that function may be limited to a group of users who will be responsible for managing the bulk of the Business Associate information.
- the EDI agreements which are critical for Interstate Pipelines, are managed as a function of Business Associate Management. This information includes the terms of the agreement and the data sets that are included within the agreement.
- Credit Management consists of several key areas. Typically, the credit management team within an organization will assume the responsibility of monitoring the outstanding credit exposures, receiving notification when credit limits are exceeded, and setting and maintaining the credit limits for their Business Associates. Available Credit is defined as the Credit Limit(s) less any outstanding
- Credit exposure is calculated for all Contracts and Deals that are managed within the system. In addition, it is a requirement to allow credit exposure to be effected by transactions outside of the system, whether they are manually entered or processed through an API. The impact of the Contract or Deal credit exposure can also be overridden if more accurate information is available.
- Credit checking will be a requirement within Credit Management, Contract Administration, Deal- Making, Capacity Release, and Account Management. For each business activity that has pricing associations, the credit implications must be reviewed. If the value of the deal, contract, or other credit-related business activity exceeds the credit limit for the Business Associate, Credit Management will either need to extend the credit limit, or the business activity will be rejected.
- Credit Management determines the action to be taken when the credit limit is exceeded by business activities. These actions are set at the entity level, but may be over-ridden at the Business Associate level.
- Facilities and Points management is a critical area of operational information, both from a Marketer's perspective and a Facility Operator's perspective. Nomination, Confirmation, and Scheduling transactions are based on facilities and points.
- a Facility is a representation of either a logical or physical operational grouping of points. Examples of facilities are Pipelines, Gathering Systems, Storage Systems, and Power Transmission Facilities.
- Points are defined as a place to capture physical or conceptual business transactions within a facility. Points are used extensively within all functional areas of an organization including Contract Administration,
- the Facility information may include, one or more of: Type of Facility (Pipeline, Gathering System);
- FEC Regulatory Agency
- Operational Business Activities that a Facility performs Nominations, Confirmations, Scheduling, Allocations
- Cycles for the Business Activities Groupings within a Facility (Zones); Segmentation of a Facility; and/or Defaults to be used for Facility Management.
- the Point Management information may include, one or more of: Type of Point (Transmission, Interconnect, Pool); Defaults to be used for Point Management; Relationships of Points to each other (for Interconnects, Hubs, etc.); Capacities of the Points; Business Associates who have an interest in the Point; and/or Analysts who are responsible for the Point. Inventory Account Management
- An Inventory Account is a transaction grouping mechanism, combined with a set of rules and parameters, to be used in Balancing as well as in Imbalance Trading, Cash-out, and Imbalance Valuation.
- the operational transactions are aggregated based on the Inventory Account assignments.
- the Inventory quantity is calculated as the Receipts for the aggregated transactions, less any Fuel and less the Deliveries.
- An association is established between Accounts and business objects to allow the accurate calculation of Inventory Quantities.
- An Inventory Account may be associated with the Shipper, Contract, Contract Service, Contract Path, and/or Contract Point. The resulting aggregation is then available to other processes that are dependent upon the Inventory Quantity.
- Imbalance Trading, Cash-out, Penalties, and Valuation are all dependent upon a set of rules associated with an Inventory Account.
- the type of rule, the granularity, and a price structure to be used for valuation, cash-out, and penalties are specified.
- Business Associates may wish to provide customers with the capability to have these activities at different levels of granularity (for example, Daily Cash-out but Monthly Trading, or Hourly Penalties and Daily Cash-out and Trading), the rules for each activity may be at different levels. It is also possible that a customer may not wish to offer all of the activities.
- the regulated pipelines will be more likely to have Cash-out and Trading, while the unregulated pipelines may only need the Inventory Accounts penalties.
- Any balance left in an Inventory Account may be valued as inventory rather than cashed-out completely.
- Inventory Statement that is generated to reflect the starting position, the activity, and the resulting position.
- the Shipper and Operator Imbalance Inventory Accounts can be associated to any one of the following: Shipper; Contract; Contract Service; Contract Point; and/or Contract Path.
- Points (logical or physical): The association of the Inventory Account to one of the items listed above will dictate how the Imbalance quantities for operational transactions are to be aggregated and a shipper may have multiple Inventory Accounts. In addition to the multiple and flexible aggregation levels, this approach allows the user to establish the rules at the Inventory Account level and to use those rules multiple times without having to restate the rules each time.
- -69/39 Shippers may need to group Inventory Accounts together for roll-up pmposes. For example, a Shipper may do cash-out at a Contract/Account level, but may do Imbalance Trading at a Shipper/Account level. If a roll-up Inventory Account is used, the distribution order must be stated so that if activity occurs at a roll-up Inventory Account it can accurately be distributed to the other Inventory Accounts. Multiple types of Inventory Accounts will be supported. Each of the Inventory Account types will have processing and validation rules that are specific to the type. Inventory Accounts to be supported includes at least one of the following: Shipper Imbalance; Operator Imbalance; Storage; Interconnect; and Pooling.
- the Inventory Accounts for the Shipper in the above example are: Account 1 - includes all activity for Contract A, and all activity for Path 1 on Contract B; Account 2 - includes all activity for Contract B except for Path 1 ; and Account 3 - is a Shipper Roll-up Inventory Account (note, if there were additional contract activities for the Shipper which were not defined to a different Inventory Account, the other activities would also rolled into Inventory Account 3).
- Account 1 would be -8 (600 - 60 - 548).
- Account 2 would be +30 (700 - 70 - 600).
- Account 3 would be 22 ( -8 + 30).
- a shipper has two Inventory Accounts, both with a type of 'Shipper Imbalance'.
- the rules for all imbalance quantities associated with Inventory Account 1 which covers 3 of his contracts, with the first 50% of the Imbalance Quantity is cashed out at $2.00.
- the remaining 50% of the Imbalance Quantity is held in inventory and valued at $1.50.
- the shipper is not allowed to trade any of his Imbalance Quantity on these 3 contracts.
- the rules for Inventory Account 2 which cover all remaining contracts for the shipper, say that all quantities associated with Inventory Account 2 are eligible for Imbalance Trading, and that all of the quantity remaining after the Imbalance Trade window is closed is cashed out at $5.00.
- the Inventory Account information may include, at least one of the following: Entity; Business Associate; Indication of whether the Inventory Account is Volume-based or Value-based; and method to use for valuing Accumulated transactions (LIFO, FIFO, Pro-Rata);
- the rules are specified.
- the rules information may include, the following: Indication of whether the rule is a Cash-Out, Trade, Penalty, or Valuation Rule; Granularity for the rule (hourly, daily, monthly); and Price Structure to be used.
- Inventory Accounts may be grouped together for roll-up pu ⁇ oses.
- the group information may include, at least one of the following: Indication of which Inventory Account is the Roll-up Inventory
- Distribution parameters for the other Inventory Accounts if activity occurs at the roll-up Inventory Account, how does the user wish to allocate the effects of that activity to the other Inventory Accounts).
- Resolution is solving a pricing formula or quantity formula.
- the resolved price or quantity can then be used for display or charge processing.
- Deal Maker, Contract Administration and Price Management are related in connection with resolving prices and quantities.
- the Price Structure contains two elements for formulas, the Price Formula and the Quantity Formula.
- the user can specify simple to complex algebraic algorithms to determine a price with the Price Formula.
- the Price Structure itself contains a multiplier and increment, which can adjust the resolved price or fixed price, and is entered by the user.
- the Quantity Formula provides a means to reference a specific quantity on which to base a charge or build a complex algebraic algorithm if necessary.
- a quantity formula is also used to specify a TierLevel Quantity by reference. The formulas provide flexibility and extensibility.
- a Price Formula can be specified on the price structure associated to an object (for example:
- the user can specify a fixed price or specify a pricing formula.
- a pricing formula can be comprised of an index reference, formula or complex formula set.
- the pricing formula allows for a series of algebraic commands, multiplier, increments and combinations of indexes.
- a Quantity Formula can be specified on the price structure associated to an object (for example: Contract, Deal, Deal Point, Path, etc.).
- the customer can specify a reference to a quantity type and build an algebraic relationship between various quantities.
- the quantity formula allows for multipliers and specification of minimum or maximum quantities.
- the quantity formula is used to determine the Billable Quantity on which a charge can be based. It can also be used to specify a Tier
- Pricing is an integral part of the overall accounting process and is related to the requirements for Confracts, Deals, Business Associates, and Accounts.
- the requirements of pricing are capturing pricing information, grouping pricing information into packages for easy re-use, and maintaining indexes and formulas.
- a price structure is the mechanism used to associate a price with the above objects. Multiple price structures can be associated with a single object.
- the word 'object' in this document refers to an item that has its own identity in the system and to which items can be attached.
- a price structure also captures the information required to generate a charge.
- the Pricing information may include, one or more of: Price/Rate Information: defines the method for determining the price (fixed value, index, formula, tiers, etc.); Quantity Information: defines the method for
- Price structures for transactions related to purchases and sales and price structures for transactions related to service contracts.
- Price structures for these transactions can be associated to one or more of: Account; Contract; Deal; and Point.
- Price structures for these transactions can be associated to one or more of: Account; Contract; Path; and Point.
- Capacity Administration is related to the requirements of the Business Associates, and Facilities and Points Management requirement documents. Contract Administration is the managing of all contractual information that is needed by operational or accounting processes. A Contract is the legally binding agreement between parties to provide goods or services. A Contract Service is the definitive structure within a contract that defines the rules and requirements for further processing.
- the Contract information may include, one of the following: Type of Contract (Commodity, Service.); Contract Parties (Counter-party, Shipper); and Contract Dates (Start, End).
- the Contract Service information may include, one of the following: Type of Service (Transportation, Purchase, Sales); Level of Service (Firm, Spot, Term); Quantities; Capacities; Points; and Paths.
- Contracts that are supported include: Commodity, Service, and Master Agreements.
- Commodity contracts are used for sales or purchases of a commodity or commodities.
- Service contracts are used in performance of a service.
- Master Agreements are used to manage Capacity Release agreements.
- Commodity Contract Services can include: Spot Purchase; Term Purchase; Spot Sale; and Term Sale.
- Service Contract Services can include: Firm Transportation; Interruptible Transportation; Firm Transmission; Non-Firm Transmission; Firm Storage; Interruptible Storage; Gathering; Parking and Lending; and Balancing.
- Capacity Management includes all activities that a facility's personnel or a marketer's personnel perform on a regular basis.
- the facility operation's activities will include analyzing the capacity, managing the capacity release, and managing the facility capacity auction.
- the marketer's activities will include analyzing the capacity, releasing and acquiring firm capacity, and participating in facility auctions.
- Capacity Management is related to the requirements for Contract Administration and Pricing Management.
- a facility's capacity is the amount of space available on the facility. The capacity can be determined for the entire pipeline, a portion or segment of the pipeline, and for specific points.
- a firm transportation contract grants capacity to a service requester at one or more points along a pipeline. Capacity is either specific to location (point) and quantity or is general to location and specific as to quantity.
- a firm transportation contract gives a service requester the right to cause a transportation service provider to receive a specific quantity of gas from that service requester at a point and/or deliver a specific quantity of gas to that service requester at point over a specific time period.
- Capacity Release is the mechanism that has been established to allow shippers the ability to release their excess capacity to another shipper. This is an offer, bid, and award process that can be accomplished either on the Internet or through EDI datasets.
- the FERC required pipelines to openly post the deals that their service requesters were seeking to transact.
- the Commission set up a process whereby all releases would, at a minimum, be posted for informational pu ⁇ oses. If the release was for more than one calendar month, the release was required to be at "Maximum Rate" or to be available for open bidding by all prospective service requesters.
- the FERC required each pipeline to establish an elecfronic bulletin board (EBB) through which capacity being released could be posted and offered for sale and upon which prospective service requesters could bid, on-line, for such capacity.
- EBB elecfronic bulletin board
- Capacity Auction is the mechanism that has been established to allow pipelines the ability to auction their excess pipeline capacity. This is an offer, bid, and award process that can be accomplished on the Internet.
- Capacity Analysis is the process that either the shipper or the pipeline uses to determine their capacity availability and requirements. Under-utilized capacity or over-subscribed capacity could result in a pipeline
- Deal Management The major business requirements of Deal Management are deal capture, confirmations, bid/offer tracking, position management and credit checking. Deal Management is related to the requirements of the Contracts, Business Associates, and Accounts requirement documents.
- a deal is an agreement between two parties to exchange assets or provide a service.
- the types of deals include physical and financial transactions for natural gas and power and deals such as purchases, sales, transmission, transportation, storage, and capacity release.
- the general information captured for a deal include:
- Deal information - contains the basic information for the deal including the counter-parties, broker(s), and, if applicable, term/dates, contacts, contract relationship, confirmation status/date, etc.
- Deal service(s) - the deal may contain one or more services which represent the deal type, location, service type (gas purchase, physical option, etc.), service level, term, etc.
- Deal Point(s) the deal point provides detailed information related to the physical delivery of the commodity associated with the deal.
- the deal may contain one or more transportation/transmission paths, which represent the capacity associated with the deal.
- the deal path will be based on the facility from which the service is provided.
- Storage - for storage deals (including parking and lending), this will contain information related to the storage capacity, injection/withdrawal quantities, etc.
- the types of deals which are supported include:
- Example 1 A fixed price physical gas sale between XYZ Marketer and ABC LDC for $4.10 with a 6- month term January- June 2001 for 10,000 MMBTU/Day for delivery at Transco Station 65 would be:
- Example 2 A fixed price physical power purchase between XYZ Marketer and ABC Power Marketer brokered by 123 Broker for $50.00 per MWh with a 6 month term January-June 2001 for 50 MW/hour on a 5x16 excluding NERC holidays for delivery at Palo Verde would be:
- Example 3 XYZ Marketer acquires 5,000 MMBTU/Day of transportation capacity from ACME Pipeline from Zone 1 to Zone 3 for $0.15 per MMBTU demand charge and $0.05 per MMBTU commodity charge:
- Division of Interest Processing Division of Interest Processing is related to the requirements for Contract Administration.
- Interest Ownership of a wellhead is managed through the Division of Interest assignment.
- Three types of interest owners are specified - Working Interest Owners, Royalty Interest Owners, and Equity Interest Owners.
- the Working Interest is specified at the Point level and may be specified for any Contract Service.
- the percentage of interest for a Working Interest Owner is used to calculate the quantity that the owner is entitled.
- the measured quantity is multiplied by the interest percentage, resulting in the allocated quantity to the Working Interest Owner.
- a wellhead may have multiple Working Interest Owners, but the ownership
- the Royalty Interest is specified at the Point level and may be specified for any Business Associate.
- the Royalty Interest Owners are those who share in production free of costs if and when there is production.
- the Operator of the Point is responsible for providing the Royalty Interest Ownership breakdown and the Over-riding Royalty Interest Owners must be identified.
- Gas Quality Rules Processing is related to the requirements for Contract Administration, Measurement and Sampling Management, and Pricing Management.
- Contracts (Service and Commodity) or Contract Services may have clauses to allow for penalties and charges if the gas that is being measured is not accordmg to specifications set forth in the contract. These clauses, or rules, are specified at the Confract, Contract Service, or Contract Service Point level.
- the value of the measured sample is compared to the Gas Quality Rule for pricing. If the measured sample value falls outside of the terms of the gas quality rule additional charges for the Contract, Contract Service, or Contract Service Point must be created.
- Heat Content Rules Processing Heat Content Rules Processing is related to the requirements for Contract Administration and
- Contracts Service and Commodity
- Contract Services may stipulate the use of a Heat Content type. This type may be different from the default Heat Content type used in converting a volumetric quantity to energy, or an energy quantity to volume. These clauses, or rules, are specified at the Contract, Contract Service, or Contract Service Point level.
- the Heat Content Types and their associated values are received as a function of measurement sampling. When a volumefric quantity is nominated, scheduled, confirmed, or allocated, the appropriate Heat Content type is critical for converting from volume to energy or energy to volume for quantity maintenance.
- the hierarchy for determining the correct Heat Content value to use is Contract Service Point, Contract Service, and then Contract. If no Heat Content rule has been specified at any of those levels, the Heat
- Heat Content of the point should be used.
- the default facility Heat Content should be used if there is no Heat Content at the point.
- Allocations Processing is related to the requirements for the overall process of providing transportation services and/or utilizing transportation services and Nomination Processing, Confirmation Processing, Scheduling Processing and Measurement/Sampling Management.
- Allocation Processing includes all allocation-related activities that a facility's operations personnel perform on a regular basis. These activities include pre-determined allocation (PDA) rules maintenance, performing validations on PDA's and allocation processing, and reviewing the allocated quantities before publishing the allocation information to other operational areas, other facilities or marketers.
- PDA pre-determined allocation
- the allocation requirements for business processes define facilities (regulated or non-regulated) that require nominations from their shippers prior to gas flow and non-regulated facilities that utilize Division of Interest (DOI) percentages for allocating quantities at points.
- DOI Division of Interest
- Allocation - Allocation is defined as the systematic distribution of measured quantities at a point that can involve nominations, purchase and sales confracts, logical points, entities, and other objects.
- Pre-Determined Allocation (PDA) Actual flow of natural gas is allocated to the parties involved in the transaction. These parties can include producers, operators, transporters and shippers using various methodologies to allocate actual quantities. In order to manage the impact of actual quantities varying from scheduled quantities, the specification of the method to be used in allocating actual quantities prior to gas flow is imperative. PDA's accomplish this goal by securing the agreement of the allocating—and allocated-parties on the method to be used for computing the allocation, i.e. relating scheduled quantities to actual physical flow. The implementation of a PDA clarifies all parties' expectations and responsibilities prior to gas flow. The list of allocation methodology types from which two parties may agree is Ranked, Pro Rata, Percentage, Swing and Operator Provided Value.
- Pro Rata The total quantity to be allocated is multiplied by the ratio established by taking each individual scheduled line item and dividing it by the total of all scheduled line items applicable to the quantity to be allocated.
- Percentage The allocation is derived by taking the total quantity to be allocated at a location and multiplying it by the percentage(s) provided. When percentage is the only methodology provided the percentages should total 100.
- Swing - One or more of the scheduled line items, or a separate contract, is designated as the "swing". All other scheduled line items are allocated the scheduled quantity.
- the line item(s) identified as "swing” are allocated the remaining difference between total quantity to be allocated and quantities allocated to non-swing line items, in accordance with instructions provided with the PDA. If the swing line items(s)/contract(s)are not permitted to be allocated a quantity which would result in a negative number, the negative quantity is allocated to the remaining scheduled line items.
- Balance and Imbalance Calculation are related to the requirements for Nominations, Scheduling, Allocations Processing, and Inventory Account Management.
- the terms Balance and Imbalance are often interchanged within the industry.
- Balance will be used to define the difference or an out-of-balance condition between two numbers and will have to be resolved (or not) according to other requirements.
- a Balance is calculated for processing pu ⁇ oses, but never stored.
- An Imbalance defines the difference between receipt, fuel, and delivery quantities. The Imbalance will be resolved according to other requirements, i.e., Imbalance trading and Cash-out. Starting, current, and ending quantities are associated with Imbalances.
- Balance and Imbalance Calculations identify the different types and levels of imbalance and balance calculations required throughout the project. Several of the other requirement definitions make reference to "Balance and Imbalance Calculation" and each has different requirements on what to do with the difference identified. Terminology
- Shipper Imbalance The difference between receipt quantities, less fuel quantities, less delivery quantities. Imbalance can be at different levels i.e. path, contract, shipper, agent, etc.
- Point Balance (Quantity vs. quantity) - The difference between two quantity statuses at a point.
- One example would be the difference between the scheduled or nominated and allocated measured quantity.
- Another example would be the difference between the deal quantity and the nominated quantity.
- Point Balance is the difference between the receipts and deliveries at a point with the same quantity status. An example of this would be the difference between the receipt and delivery nominations at a pooling point.
- Nomination Balance The difference between the path quantities and point quantities that are inherent in pathed non-threaded nominations model types.
- the quantities could be nominated, confirmed, scheduled or allocated volumes.
- Interconnect Balance The difference between the quantities into and out of an interconnect.
- An interconnect is a relationship between multiple points.
- Confirmations Processing is related to the requirements for the overall process of providing transportation services and/or utilizing transportation services and Nomination Processing.
- Confirmation processing includes all confirmation-related activities that a facility's operations personnel perform on a regular basis. These activities include maintaining the rules for confirmation methodologies, processing confirmation requests, performing validations on confirmations, acknowledging confirmation responses, updating quantity statuses and reviewing the confirmed quantities before publishing the information to other operational areas for scheduling.
- Confirmation Requester A Service Provider (including a Point Operator) which is seeking to confirm a quantity of gas via the information outlined in GISB Standard 1.4.3 with another Service Provider (the Confirming Party) with respect to a nomination at a location.
- Confirming Party A Service Provider (including a Point Operator) which is seeking to confirm a quantity of gas via the information outlined in GISB Standard 1.4.3 with another Service Provider (the Confirming Party) with respect to a nomination at a location.
- a Service Provider (including a Point Operator) which provides a confirmation for a quantity of gas via the information outlined in GISB Standard 1.4.4 to another Service Provider (the Confirmation Requester) with respect to a nomination at a location.
- Confirming Parties Refers to the Confirmation Requester and the Confirming Party. Confirmation by Exception ("CBE") - The Confirming Parties agree that one party deems that all requests at a location are confirmed by the other party (the CBE party) without response communication from that party. The CBE party can take exception to the request by so informing the other party within a mutually agreed upon time frame. Elapsed-prorated-scheduled quantity The portion of the scheduled quantity that would have theoretically flowed up to the effective time of the intraday nomination being confirmed, based upon a cumulative uniform hourly quantity for each nomination period affected. Forecasting
- Pipeline Forecasting is related to the requirements for Scheduling, Deal Management, and Allocations Processing. Forecasting is the process by which pipelines and marketers predict information that will affect future operations, either near-term or long-term.
- Pipeline Forecasting has defined three required operating modes; Short-Term Capacity Utilization, Short-Term Capacity Availability, and Long-Term Investment Analysis.
- Short-Term Capacity Utilization involves predicting the pipeline's capacity to handle the current nomination load under impending reductions in service capacity.
- Short-Term Capacity Availability is used to determine where the pipeline is currently being under-utilized and where additional capacity sales opportunities exist.
- Long-Term Investment Analysis is used to perform screening studies concerning future expansion investments for handling predicted increases in demand for pipeline capacity.
- Pipeline Forecasting for commercial operations has defined two required operating modes; to predict demand patterns of end users and load forecasting.
- Pipeline Forecasting assumes that the user is familiar with the contents of the following: Scheduling; Deal Making; and Allocations Processing. Imbalance Trading
- Imbalance trading is an imbalance management mechanism. Imbalance trading can be done throughout the month on the operational imbalances and at the end of the month on the actual accounting imbalance. This process must enable shippers to trade among each other in an effort to reduce their overall imbalance.
- the pipeline will determine the operational areas on their pipeline and the level that they will allow shippers to trade imbalances. This will be similar to other offer/bid processes where shippers post imbalances and other shippers bid or trade that imbalance. The result will be an increase or reduction in each shipper's imbalance.
- Imbalance Trading is related to the requirements for Nominations, Scheduling, Allocations, Imbalance Accounts and Balancing.
- Imbalance Trading includes all activities that a facility's personnel or a marketer's personnel perform on a regular basis.
- the facility operation activities include managing the imbalance on a monthly, daily, hourly, and sub-hourly basis and provide a mechanism for the shipper to trade their imbalances.
- a marketer's activities include monitoring the imbalance on an hourly, daily, and monthly basis and trading and offsetting those imbalances.
- Natural gas flows from source points to disposition points in accordance with the scheduled nominations made by various parties.
- the actual flow of gas is then allocated among the various parties to transactions, in accordance with pre-determined allocation methodologies.
- a shipper nominates a quantity of gas at a receipt point and contracts with a pipeline to transport this quantity of gas to a delivery point.
- Allocated quantities at the receipt point and delivery point may not be the same, i.e., with reductions for fuel quantities, over-delivery by the transportation service provider at the delivery point, or under delivery by the transportation requester at the receipt point, the quantities at the receipt point and delivery point may not be the same.
- the resulting difference is referred to as an imbalance.
- Imbalances are reported by the allocating party to the affected parties involved in the transportation transaction. Imbalances may be reported on an hourly, daily or monthly basis and may be resolved in a number of different ways.
- the nomination starts the procedure, after which the allocation takes place.
- Gas is allocated at a location level and contract level.
- the imbalance data set provides contract allocation information and can be calculated using this information. This information can be a daily or a multi-day function, or it can be final closing data for an accounting period.
- the monthly imbalance should be monitored throughout the month, so the imbalance may be minimized.
- pipelines will be required to provide imbalance management services, like parking and loaning service, and greater information about the imbalance status of shippers and the system, to make it easier for shippers to remain in balance in the first place. Pipelines also will be required to permit third parties to offer imbalance management services that will allow shippers to avoid imbalances.
- Third parties are defined as companies that do not have a transportation contract with the pipeline, but are allowed to trade imbalances. Some type of contract and contract service will need to be established for these business associates. There will be no transportation or commodity charges associated with these contracts or trades. Measurement & Sampling Management
- Measurement and Sampling Management supports the requirements for maintaining the measurement data as well as other measurement information about the measurement facilities. Service providers will regularly record measurement information for downstream processing. The measured quantities are generally the source for Point Allocations. The measured samples will effect pricing.
- a meter is a representation of a physical device that is used to record the data related to flowing gas for a facility.
- measurement data is often collectively referred to as measurement data, and as such may include not only volumetric quantity information, but also sampling information in the form of quality or component specifications. Accurate and timely recording and processing of measurement data is critical because of the downstream processes.
- the measured quantity is the source for point allocations and a statement is typically based on allocated quantities, the receipt of the measured quantity has a direct economic impact on the facility.
- the recording and processing of the measured samples also has a financial impact on both the facility and its customers.
- Meters are associated directly with a transactional point for a facility.
- a point may have one or more measurement meters associated with it - the quantity recorded for each of the measurement meters is summed up to the point quantity for allocation pu ⁇ oses. Information captured for the meter(s) will determine how the best available quantity for the point is determined. Nominations Processing
- Nominations Processing requires familiarity with the requirements for the overall process of providing transportation services and/or utilizing transportation services.
- Nominations processing includes all nomination-related activities that a facility's operations personnel or a marketer's scheduling personnel perform on a regular basis. These activities will differ depending on the role.
- the facility operation activities include maintaining the rules for nomination acceptance for different types of nominations or services, performing required validations on the nominations, and reviewing the nominations before publishing the nomination information to other operational areas for scheduling or confirmation.
- a marketer's activities include creating and maintaining the nominations and submitting the nominations to the appropriate facility for further processing.
- Scheduling is related to the requirements for Facilities and Points Management, Confract Administration and Nomination Processing. Scheduling is the process that occurs at a facility (Pipelines, Gathering Systems, Storage Systems, and Power Transmission Facilities) to determine if requested nominations individually meet pipeline nomination requirements, and, if taken as a whole, can physically be handled by the facility.
- scheduling mode the process is run using planned operations, usually for the next day or cycle, based upon actual transportation requested by the shippers.
- Forecasting mode uses predictions of needs ranging from days to years in the future.
- Storage Processing requires familiarity with the requirements of providing storage services and/or utilizing storage services and Facilities and Points Management, Contract Admin, Balancing and Imbalance Calculation, Inventory and Imbalance Management and Nominations.
- Storage processing is applicable to a facility that operates a pipeline facility as well as a storage facility, an independent third party storage service provider and a marketer who contracts with a storage service provider for the right to store gas.
- Storage processing includes all storage-related activities that a facility's operations personnel or a marketer's scheduling personnel perform on a regular basis. These activities will differ depending on the role.
- the storage facility operation activities include maintaining the rules for storage injection/withdrawal and tracking inventory quantity before publishing the nomination information to other operational areas for scheduling or confirmation.
- a marketer's activities include requesting storage injection/withdrawal and inventory quantity exchange services and tracking inventory quantity and valuation.
- Terminology used in connection with storage processing can include the following.
- a facility refers to a storage facility.
- Storage transactions include injection, withdrawal and transfer services.
- Storage fields refer to facilities that are usually natural geological reservoirs such as depleted oil or gas fields or waterbearing sands sealed on the top by an impermeable cap rock.
- the facilities may be man-made or natural caverns.
- No Notice Service refers to a transportation service pursuant to which firm shippers can receive delivery of gas on demand up to their firm entitlements on a daily basis without incurring balancing and scheduling penalties.
- This "no-notice" service will enable pipeline customers (i.e. firm shippers) to continue to receive unnominated volumes to meet unexpected requirements caused, i.e., by unexpected changes in temperature.
- Pipeline customers i.e. firm shippers
- Facility Operator Transfers refer to the exchange of storage quantities between contracts of the same service subscriber or between confracts of different service subscribers.
- Marketers Transfers refer to the exchange of storage quantities between its own storage confracts or the purchase/sale of storage quantities between one or more service subscribers.
- Gas Marketing Business Process In Figure 12, a sample screen view of for Trading, Make Deal, module is shown. From the Trading,
- Make Deal screen access to one or more of the following is available: make deal, manage deal, contract administration, confirm deals, cash position, pricing, portfolio, and service type.
- the various deals formulated via a Make Deal module can be saved in one or more portfolios.
- the Make Deal screen includes at least a column of Deal Group, Deal, Status, Begin Date, End Date, Type, and Level.
- the Make Deal screen further includes an area for a quick deal entry, configured to receive information relating to a Deal Group, Type, Level, Term Code, Accounting Company, Trader, Begin Date, End Date, Counte ⁇ arty, Contact, Contract, Price, Price Units, Facility, Location, Point, Quantity, Quantity Unit, Broker, Broker Contact, Region, Broker Fee, Fee Units, and Classification.
- User options for the Make Deal module include Full Create, Save As New, Save, and New.
- FIG. 13 a sample screen view of for Trading, Price Formula, module is shown.
- User options for the Price Formula module include Add, Delete, Save, and Export. From the Price Formula screen, access to one or more of the following is available: make deal, manage deal, contract administration, confirm deals, cash position, pricing, portfolio, and service type.
- the Price Formula module includes input for a formula name, formula, referenced price formula, index short name, and index long name. In addition, a more detailed display of existing formulas per formula name, formula, frequency, display flag, and currency is provided.
- the Trading, Price Formula, screen includes a formula entry box, with user selectable options of Insert Formula, Validate, and Test.
- the Trading, Price Formula, screen display further includes a calculator.
- Figure 14 illustrates an exemplary screen display of an Operations, Nomination module. In this embodiment, regions are provided for Supply, Services, Location, Inventory Accounts, Market, Facility
- the information includes at least one of Deal, Supplier, Facility, Receipt Location, Up Ref, Rnk, Deal QTY, Avail QTY.
- the Services include at least one of counte ⁇ arty, service, level, and balance.
- For Locations an option for selecting Receipt and Delivery Location is provided. Locations further include at least one of Facility, Type, Location, and Balance.
- For Inventory Accounts an option for selecting Receipt and Delivery is provided. Inventory Accounts further include at least one of Account, Location, Available, and Balance.
- the information includes at least one of Avail QTY, Deal QTY, Rnk, Down Ref, Delivery Location, Facility, Marketer, and Deal.
- the Facility Upstream information includes at least one of Counte ⁇ arty, Reference, Rnk, Pkg ID, and Quantity.
- a Marketer Upstream information includes at least one of Deal/Inventory, Location, Rnk, and Quantity.
- information includes at least one of Receipt Quantity, Receipt Point, Receipt Rnk, Facility, Service Contract, Nom Trans Type, Adj.
- the Facility Downstream information includes at least one of Quantity, Pkg ID, Rnk, Reference, and Counte ⁇ arty.
- Marketer Downstream information includes Quantity, Rnk, Location, and Deal/Inventory.
- User selectable options for the Nomination screen include Save, or Cancel. Additional detail of alternate embodiments of the nominations screen are provided herein.
- FIG. 15 a sample screen view of for an Accounting, Charge Detail, module is shown. From the Accounting, Charge Detail screen, access to one or more of the following is available: Quantities, Inventory, Charges, and Statements.
- the Charge Detail screen includes at least a column of Facility, Business Associate, Transaction Type, Production Period, Deal, Deal Location, Source Location, Disposition Location, Net Out Flag, and Price Component.
- the Charge detail screen further includes a pop-up display for a quick access to charge detail, manage charge status, generate statement, remove charge from statement, statement detail, statement account information, price structure info, add manual charge, maintain comments, update charge quantity.
- User selectable options on screen may also include manage charge status, remove charge from statement, add manual charge, and export. NOMINATIONS Adding Nominations
- the system architecture is configured to support GISB standards version 1.4 for North American FERC Regulated Facilities. This includes the Pathed Threaded, Pathed Non- Threaded and Non-Pathed nomination model types.
- the system architecture is further configured to support EDIGas standards for sending and receiving operation data and messages utilized by European shippers and facilities. While the EDIGas Standards are different from the GISB
- Time Period for Nominations includes the capability of adding/updating multiple day hourly nominations without the use of profiles. For example, a nomination effective from 9:00 am to 10:00 am could be added/updated for days 1 through 15.
- Support for the capability of nominating paths on the same transportation contract using different time periods includes providing a rule requiring that the time period for the nomination is no less than the lowest level of granularity defined in the contract. That is, for a contract defined at a daily level, daily is lowest level that can be nominated. It could have two paths; one nominated at a daily level and the other at a weekly, bi-weekly or monthly level but not hourly. The weekly, bi-weekly or monthly begin/end date/times are based upon user defined business processing needs.
- the system provides an ability to create/maintain transportation (path/point level and pooling) and storage nominations on a monthly, weekly, daily, hourly and period basis.
- the system also supports the use of cycles for whatever period is defined. If for example, one side of a nomination at an interconnect has an hourly pattern but the other does not, the side without the hourly pattern will assume a pattern pro rated to the hourly side. While it is not a requirement that non-hourly nominations must be stored at an hourly level, it is a rule to address a specific business condition that exists for International users.
- Steps in auto pooling involve creating relationships (links) between individual points/locations to a specified pooling point for both receipts (deliveries) and deliveries (redeliveries).
- the supply or supplies are "pooled” and used to satisfy a sale or sales.
- Auto pooling allows users to create multiple nominations simultaneously thereby reducing manual intervention.
- Support for providing an ability to label, store and retrieve Nomination Profiles includes defining a profile as a pre-determined pattern of quantities that may be used in nominations over a specified time period.
- the profiles can be configured to support one or more of user defined time intervals; be date/time effective; support energy values, volumetric quantities or both; be available on any type of nomination (point-to-point, pool, storage, park and loan, title transfer); and provide a user's ability to generate an hourly profile from a daily nomination. In the last instance, this would allow an hourly profile to be created from a 24 hour or daily nomination when there is no hourly variation in that nomination.
- a profile could be that for a given time period, time periods 1 - 3 are nominated at 10,000 units per period for a specific path and time periods 4 - 7 should be nominated at 8,000 units per period. There could be numerous possibilities and combinations.
- Support for auto pathing/nominating on a higher level than the Nomination Period includes, for example, providing the capability of pathing daily using hourly profiles and reduce keystrokes by eliminating the need to create 24 individual hourly nominations. This requires that transportation confracts and points provide the necessary flexibility to allow for nominations to be added/updated hourly on a daily facility that has some hourly points. Conversely, the system can be configured to provide similar flexibility to allow for daily nominations on an hourly facility that has some daily points in order to accommodate various business models.
- the system is further configured to support a user defined capability to specify a Nomination Period other than the Default Nomination Period at a facility or entity level (marketer and facility).
- gas quality and contact information are included as part of the nomination using the system architecture of the present disclosure.
- the system further supports add-nomination capabilities for European capacity releasors and releasees. In Europe when a capacity holder releases capacity (releasor), the pipeline facility is not involved. The facility still requires the original capacity holder to submit nominations for all the capacity (including what was released to a third party - releasee).
- system architecture can be configured to transfer nominations from releasee to releasor, provide a mechanism for releasor to automatically and/or manually receive and input nominations from releasee, and provide automatic and/or manual mechanisms for combining releasee and releasor nominations.
- Support for emergency override of facility's nomination period includes allowing the flexibility for a daily facility to conduct business on an hourly basis in the event of an emergency (i.e. a kind of "switch").
- Support for the capability of adding nominated quantities based upon temperature includes allowing the user to input a temperature for the gas day being nominated. Depending on that temperature, a nominated quantity will be determined based upon deal quantities and that nomination's corresponding temperature level or tiers.
- Support capability of nominating payback at receipt (delivery) or delivery (re-delivery) points are included by supporting one or more of physical points, logical points or pools, and supporting a capability of including or excluding payback from Rate generation, Imbalance calculation, and Fuel calculation.
- the system architecture is further configured to support user defined rounding and normalization mechanisms.
- a daily quantity is required to be nominated as an hourly pattern and there is a remainder after dividing the daily quantity by 24 hours.
- users should be able to determine how to distribute the remainder (e.g. add to last hour, first hour, etc.).
- rounding assume fuel is calculated on a monthly basis. A daily-nominated quantity of 20 per day is created with a 2% per month fuel rate. On day 1, the fuel quantity is .4 (20 x 2%). If the proper rounding and nonnalization rule(s) are not in place, the fuel for that (and subsequent) day could be 0 thereby not capturing the correct fuel quantity.
- the system architecture supports Multiple Nomination Units (marketer and facility) in the one or more of the following: select a facility and have that facility's nomination unit be the default unit; capture both volumetric and energy quantities on a nomination, including being able to input either quantity and have the other automatically calculated or have the ability to override the automatic calculation; and have the option of being able to nominate using any other unit.
- the system is configured to support situations where a nomination is created in unit X and is automatically converted prior to sending to a facility utilizing unit Y.
- the system is configured to support situations where a Marketer sends in a nomination in unit A and it is automatically converted to unit B (e.g., what the Facility uses). Conversion issues resulting from going to/from different units are addressed by the rounding and normalization requirements described above.
- the system architecture supports adding of nominations with user configurable Save capability (Marketers and Facilities) by one or more of the following : a) Allowing adding of nominations with capability of placing in "hold” queue. Hold queue is defined as stored but not used in production except for real time calculation of available quantity on a contract, path or point. b) Allowing for Update and Delete while in "hold” queue. Only real time calculation of available quantity on a contract, path or point would be affected. A potential capacity releasor that has a nomination in the hold queue would not have that capacity available to release until a final determination is made that the nomination is not needed and will not be used. c) Providing capability to send either all or only selected nominations that are in the hold queue into production for further processing (i.e.
- the system architecture further provides an ability for a facility operator to have the capability to manually add nominations received from its shippers, according to one or more of the following: a) For pools that are supported or sanctioned by the facility (i.e. not logical pools created by and for shipper use only), a manual add capability is provided. Facilities often designate pools by zone, segment or point thus allowing many pools to be setup. Points within those designated zones or segments are the only ones allowed for pool nomination pmposes. Therefore a facility must input such a nomination for its shipper, and the system architecture allows the facility to have the same ease of adding a nomination.
- the system architecture is further configured to provide additional data element requirements for non-regulated facilities. These include one or more of deals and deal points, interconnects/hubs, pools and pooling points, volume requirements, storage data, nominated quantity Status (Nominated, Confirmed, Scheduled), allocated, and hold. These additional data elements form the basis for a non-regulated facilities' nomination.
- Support for Cross Confract Ranking when adding a nomination (marketer and facility), includes configuring the system architecture with capability to set ranks on nominations across multiple transportation contracts on all nomination model types at a single point. This further includes configuring the system architecture to support adding nominations across multiple points and or facilities through interconnects for Marketers.
- a user is able to create pre-defined (or as needed) Inter-Facility single leg paths, including pools such as from Facility A Point 1 to Facility B Point 2, such as shown in Figure 16.
- the system architecture is configured to enable a user to create pre-defined (or as needed) Infra- Facility multi-leg paths (this is sometimes referred to as a "Meter Bounce” or “Bumping") including pools such as shown in Figure 17.
- a "Meter Bounce” nomination would result when a quantity is nominated for transportation from Point 3 to Point 4 on confract X. At Point 4 the quantity would then be transported from Point 4 on contract Y for delivery to Point 5. This same approach could be used to create pooling nominations across multiple facilities.
- FIG 18 For International customers, a second type of bounce or bump is as shown in Figure 18.
- the business scenario shown in Figure 18 pertains to a situation where gas is flowing on Facility 2 with the physical capability of flowing or not flowing into Facility 1. If bumping (per International usage) is allowed, then the gas flow on Facility 2 only "bumps" I/C 2, continues down that facility and does not flow through I/C 1 into Facility 1. If bumping is not allowed then the gas flow on Facility 2 must flow through I/C 2 to I/C 1.
- the system architecture further provides support for nomination and re-nomination capability at a point level for International users to a) specify whether or not bouncing or bumping is allowed at I/C 2, and b) if bumping is not allowed then the gas flow on facility 2 must go through I/C 2 to I/Cl . That quantity should automatically be available at I/C 1 (See Figure 18).
- the system architecture also supports contract selection for the preceding scenarios by allowing for default contracts to be defined at each point or allowing for selection of other contracts at each point.
- the system further allows for configuration so paths could be created to/from unregulated and regulated facilities (marketer).
- the architecture is configured to support adding Marketer Nominations at Hubs.
- a hub is defined as a group of multiple facilities that interconnect with each other and allow for flow across one or more of the facilities.
- a user should be able to nominate on a facility for delivery to a hub. For example, a nominated quantity on facility A should be available for pathing on any of the facilities that fall within the grouping of hub B. Another example is where a user would be able to specify what quantity is available on multiple facilities.
- a pre-requisite is the setup of hubs in facilities management.
- the architecture further supports adding of Title Transfer Tracking to Nominations (marketer and facility). This is accomplished by providing capability of adding purchase and sales quantity transfers at a point. Title Transfer is the change of ownership of gas between parties at a location. As such, this will become part of the chain of business activities that will need to be nominated at a point for FERC regulated, non- regulated, and International facilities that require this type of information.
- Support for adding Storage Nomination Transfers for Facility Operators (Pipeline) and Marketers includes configuring the system to support a Facility Operator (Pipeline) in one or more of the following: a) between storage contracts of the same business associate and b) between storage contracts of different business associates.
- the system can be further configured to support Marketers: a) between storage confracts of the same business associate; b) between storage contracts of different business associates; c) transfer volumes from a storage contract to a sales commitment; and d) transfer from a purchase commitment to a storage contract.
- the system is configured to provide adding of Storage Nominations for marketer and facility where storage nominations are added directly on a storage contract without using a transportation confract and a nomination is added into/from storage using a transportation contract.
- the system is configured to support the following parameters for adding Storage Nomination (marketer and facility): Storage Contract; Direction; Transaction Type; Model Type; Upstream Downstream Contract; Upstream/Downstream Entity; Upstream/Downstream Pkg Id; Upstream/Downstream Transaction Type; and Date/Time Effective Nomination Range.
- Storage Nomination marketer and facility
- the system architecture is configured to support the capability for marketers to transfer pool imbalances to transportation contracts. Users should be able link a pool with a transportation agreement and automatically transfer an imbalance.
- the system architecture is further configured to support a Copy/Paste function for adding nominations and profiles (marketer and facility) by allowing users to: select a single nomination or a group of nominations and be able to copy/paste the information; have same capabilities for viewing/editing, etc., as would a nomination added completely from start to finish; and specify what data is copied from which day(s). For example, day 31 quantities could be copied or rolled and used to create nominations for all or a portion of the days of the following month. Day seven's hourly profile could be used to establish hourly profiles for all or a portion of the days in the following month. In an alternate embodiment, a "roll" process could also be used instead of or in addition to copy/paste.
- the system architecture further supports a complete audit history of nominations for marketer and facility. Original nominations and all changes can be maintained.
- the system architecture is further configured to support the capability to allow marketers the option to add/update a point on a deal from within nominations and also have the deal updated to reflect the change.
- Three possible scenarios could include: a) Allow for changing the point on the deal from X to Y; b) Not require the deal creator to designate a point and have the deal show up in the nominations area (User would select the point anytime prior to pathing); and c) Adding point Y but retaining point X.
- the system architecture is further configured to support the ability for facilities to identify where points are over-nominated on contracts prior to confirmation or scheduling processing. Updating Nominations
- the system provides the manual capability for a facility operator to update nominations received from its shippers.
- the system architecture is configured to provide Marketers the capability of updating nominations for items such as quantity, package id, upstream/downstream entity (i.e. all fields that were initially user input/selected should be editable including all upstream/downstream information - non-threaded portion of pathed non-threaded model type).
- upstream/downstream entity i.e. all fields that were initially user input/selected should be editable including all upstream/downstream information - non-threaded portion of pathed non-threaded model type.
- upstream/downstream entity i.e. all fields that were initially user input/selected should be editable including all upstream/downstream information - non-threaded portion of pathed non-threaded model type.
- upstream/downstream entity i.e. all fields that were initially user input/selected should be editable including all upstream/downstream information - non-threaded
- the system architecture is further configured to support update nomination capabilities for European capacity releasors and releasees; support capability of marketer to update scheduled and allocated quantities on nominations; and support Cross Contract Ranking when updating a nomination (marketer). Users are provided the capability to update ranks on nominations across multiple transportation contracts on all nomination model types.
- the system architecture is still further configured to support updating user defined paths across multiple facilities for Marketers.
- a user is able to update pre-defined paths.
- the system is configured so paths can be updated to/from unregulated and regulated facilities.
- the system enables a user to be able to nominate on a facility for receipt (delivery) from to delivery (re-delivery) to a hub.
- the system architecture is configured to support updating of Title Transfer Tracking on Nominations for marketer and facility, by providing capability of updating purchase and sales quantity transfers at a point.
- the system architecture supports updating of nominations in the "hold" queue for marketer and facility; supports user configurable capability for a marketer to update a nomination when that nomination's deal quantity is changed; and supports user configurable capability for a marketer to update a deal quantity if a nominated quantity is changed. Deleting Nominations
- the system architecture supports deleting Nominations added by a Facility or a Marketer. For Nominations added by a Facility on behalf of Shipper the system architecture supports deleting of nominations while in the process of adding; and supports deleting of nominations when in "hold" queue but prior to downstream processing (i.e. confirmation, scheduling). However, the system does not allow deleting after nominations have been used in downstream processing (i.e. confirmation, scheduling, accounting, etc.).
- the system apparatus supports deleting of nominations while in the process of adding; and supports deleting of nominations when in "hold" queue but prior to downsfream processing (i.e. actualizing, statement generation). However, the system does not allow deleting after nomination has been used in downsfream processing including sending to facility.
- the system further supports user defined choice of allowing deletion of some, all or none of the non-threaded portion of the pathed non-threaded model type (i.e. upstream/downstream designations) and allows user choice of retaining or reversing deal point update during deletion Supporting Fuel Calculations
- the system is configured to enable a user to specify fuel rates down to an hourly level.
- the system is further configured to support Fuel Componentization (marketer and facility). Fuel componentization provides the flexibility of assigning multiple fuel charges to a quantity. This allows fuel charges to be captured at the level at which it is incurred, for example, with respect to mainline transportation fuel, plant fuel, and gathering fuel; as well as loss and unaccounted for, often embedded in a facility's fuel rates but could not be expressed as a separate component.
- While supporting fuel calculations may be initially defined at the contract/path level, the system can be configured to provide users with the capability of adding or editing the fuel rate by component on the nomination itself.
- the system is further configured to support Matrix Level Fuel Charges (marketer and facility).
- the system architecture is further configured to support Negative Fuel Charges. Due to a combination of business processes, there is a need to manage negative fuel charges. A possible explanation for this is a case where a shipper supplies gas with a higher heating value than what the facility delivers. The net effect is that even though there is a positive energy fuel charge, the shipper receives more volume than what was delivered to the facility, in effect resulting in a negative fuel rate based upon volume. See for example, fuel based on receipt, as shown in Figure 19.
- the system architecture further is configured to support user choice of Netting Fuel Charges at the path level.
- Some International pipelines charge fuel based upon "Net Flow". "Net Flow" can best be defined using an example. If a shipper sends 100 units of gas from point A to point B, and 80 units from point B to point A, the fuel charge will only be based upon the net of 20 units of gas. The fuel charge is based on the net movement.
- the system is configured to provide a notification to users when adding or updating a nomination that results in exceeding the contract, path and/or point MPQ.
- a User can configure by facility to: Ignore when exceeding MPQ; Require nomination to be reduced; Require excess nominated separately (i.e. require new nomination); and Issue only a warning to user and allow to continue. This can be further defined so that only certain users have this right.
- the system architecture is further configured to support nominations above contract quantity with user-defined percent or volume limitations, or without percent or volume limitations at one or more of: Contract point level; Zone level; and Segment level.
- the system architecture further supports validation that alerts user when nominations are in the "hold queue" prior to nomination processing. In this instance, the User has a capability of ignoring and continuing process; or accepting, rejecting or deleting nomination.
- User configurable validation includes providing a warning that deal quantities exceed transportation quantities at one or more of Contract level; Path level; Point level; or All levels.
- the system architecture is configured to support validation for ramp rates.
- Ramp rates are needed to prevent changes to a nomination beyond certain pre-determined limits (either plus or minus) because flow rates through a point/meter cannot always be changed (increased or decreased) at will on an hourly basis for example.
- Ramping should support methodologies based upon a percentage of Maximum Period Quantity
- ramp rates are defined for a facility. It has since been determined that ramp rates will not need to be enforced at nomination time. Ramp rates will only be used (optionally) at scheduling time.
- the system is configured to notify Users when ramp rates have been violated.
- the system architecture further includes rules that will determine if the user will be allowed to override the ramp rates in adjacent time periods.
- a validation for lead time may result from a business rule that says adds or updates to nominations must be done within a pre-determined amount of time prior to processing. For example, a new hourly nomination must be submitted 4 hours prior to gas flow to allow for physical constraints of the facility. This allows a notification of users that the time frame for using the nominations process (adding or updating) is not within pre-determined time limits.
- the system is configured to support validation for lead time at the facility, point and contract levels.
- the system is further configured to support for rules that will determine if the user will be allowed to override the lead-time rule. A pre-requisite would be that lead time rules are defined for a facility.
- the system architecture is configured to support validation for nomination profiles which requires that quantities for profiles are equivalent in total between different time intervals. The sum of 24 hourly profiles will need to equal a daily profile or the sum of seven daily profiles equals one week's profile.
- Validation of Storage Nominations The system architecture is configured to provide support for validation of storage nominations in relation to storage Ratcheting Levels. Ratchet levels (based on time and storage level) are parameters (set by the facility) on storage confracts that limit the withdrawal and injection quantities of marketers. Setup of ratchet levels should be on storage contract; be date/time effective; and allow for tiered level (volume and percentage) penalty calculations. If a nomination violates a ratchet level; then the system is configured to either require nomination within acceptable ratchet levels; or allow override of ratchet level.
- the system architecture is configured to support validation for deleting nominations by not allowing deletion of nominations when the nomination has been used in downstream processing, and allowing deletion of nominations if the nomination has not been used in downstream processing.
- the system architecture is configured to support Reviewing of Contracts Available for Nomination by Date/time range; Facility; Points; and Quantities.
- Quantities supported include one or more of: Total quantity; Released quantity (approved and pending statuses); Available quantity (i.e. available for nomination); Path quantity; and Quantity by priority (primary to primary, secondary to primary, secondary to secondary, etc.).
- the system architecture further provides support for viewing of contract, path and point quantities in real time. As a user is adding or updating a nomination the contract quantity information described in the preceding section can be updated in real time.
- the system architecture further provides Users capability of viewing available contract quantity at the same level at which the contract was defined, as well as, any other user defined time intervals such as: Sub- hourly; Hourly; Daily; Weekly; Monthly; Seasonally; Yearly; and Life of Contract.
- the system architecture further supports reviewing of nominated detail contract activity by Marketer and Facility. With respect to Marketer and Facility reviewing of the nominated detail contract can occur in any one of the following manners. Filtering capabilities should be provided that allows selection at virtually any single or group of data elements in a nomination.
- a User may need to review a history of a nomination or selected group of nominations. Support for the capability of automatically identifying at the end of a user defined time period, any changes to end of day quantities that took place during that hour can also be provided.
- the system is configured to support filtering capability to review nominations by: shipper (all confracts & their nominations); shipper/contract (all nominations); pool(s) (all pools, pools by shipper, pools by facility, pools by entity); all nominations at a point; specific shipper nominations at a point; and entity.
- the system architecture is further configured to support Reviewing charges for contracts for marketer and facility considering the following: Nominated confracts, unused contracts, and user defined begin/end date/times.
- Nominated Contracts either partially or wholly
- a capability to view total charges by facility or entity is provided.
- the system supports user defined begin/end date/times. There should be a business rule in place that states if a firm transportation contract has been nominated on (even if only partially), then any fixed charge should be reflected as a "Nominated Contract”.
- the system architecture is further configured to support Rate Overrides at whatever charge methodology is used by a respective facility (i.e. contract, contract/path, point, segment, zone, facility or entity, etc.).
- the system further supports deleting of manual rate overrides. If system generated rate charges are overridden manually, users should be able to delete the manual override and allow system-generated rates to be re-instated. Support for reviewing of a nominated contract summary considers the following: Beginning Balance
- Support for Reviewing of Interconnect Balances, Hubs and Pools is provided via support user defined selection of: Begin/end date/times; Some or all of interconnecting points, hubs between 2 facilities; Some or all of pools on a facility; Hubs and their interconnecting points across multiple facilities; Contracts between two or more interconnecting facilities with related upstream/downstream information; Upstream/downstream information from the respective delivering or receiving entity's point of view for interconnects, hubs and pools.
- the system architecture is further configured to support Reviewing of Time Period for Marketer's Deal. User must be able to identify the time period of a deal (i.e. sub-hourly, hourly, daily, etc.) Nomination Balancing
- Non-pathed Nominations to be either balanced or un-balanced at a contract level; allow for pools to be out of balance with the choice of allowing the pool to remain out of balance or allowing the fransportation contract to be out of balance; when operational and business conditions permit, some facilities will permit pools to be out of balance (usually on a temporary basis) as a convenience to shippers (For instance, this would allow shippers time to secure additional supply or market in order to rectify pool imbalances and not force shippers to adjust supplies or markets immediately); and support user defined methods of balancing nominations with date range capability. Manually and Automatically (i.e.
- the system architecture is configured to support the capability of being able to view the nominated, confirmed, scheduled and allocated quantities simultaneously at the same level at which the contract was nominated as well as various other levels (sub-hourly, hourly, daily, weekly, monthly, etc.).
- the system architecture is configured to support the capability of sending confirmed, scheduled and allocated quantities to business associates, such as: EDI for FERC Regulated facilities; EDIGas for European facilities; Caminus WebTM; Downloaded reports; Internet; Auto Fax; and/or Email
- business associates such as: EDI for FERC Regulated facilities; EDIGas for European facilities; Caminus WebTM; Downloaded reports; Internet; Auto Fax; and/or Email
- the system architecture is configured to support the capability of receiving confirmed, scheduled and allocated quantities from facilities.
- a marketer must be able to receive and merge it with their original data. The data should not overlay existing data so that a proper audit trail can be maintained.
- Facility API parameters of the system architecture are supported for exporting: Date/time range designation for nom period; Nom type designation (transport, storage, park and loan, all); Support batch processing/time schedule; and/or Data storage mechanism designation (table, comma delimited file, Excel, Access).
- Facility communications of the system architecture support: CaminusWeb; Email; Fax; Marketer's web page; and/or Instant messaging.
- Facility contact groups supported include: Facility level; Meter/point level; Contract level;
- Agent/shipper level and/or Nominating Party level.
- a nominating party is defined as an entity that prepares, updates and sends nomination information either on its own behalf and or on behalf of third parties. This user- defined level could be used if and when nominating parties are not designated or identified as either "agent" or "shipper”.
- Marketer API Parameters of the system architecture are supported for exporting: Date/time range designation for nom period; Nom type designation (transport, storage, park and loan, all); Support batch processing/time schedule; and/or Data storage mechanism designation (table, comma delimited file, Excel, Access).
- Marketer Communications of the system architecture are supported using: CaminusWeb; Email; Fax; Marketer's web page; and/or Instant messaging.
- the system architecture is configured to provide Marketer Contact Support for user defined groups such as: Facility level; Meter/point level; Contract level; Agent/shipper level; and/or Nominating Party level.
- a nominating party is defined as an entity that prepares, updates and sends nomination information either on its own behalf and or on behalf of third parties. This user-defined level could be used if and when nominating parties are not designated or identified as either "agent" or "shipper".
- the model type may be pathed, non-pathed or pathed non-threaded.
- the model type used affects the data required for a single transaction line item. All data elements required in the nomination standards are utilized for each of the model types. The placement and number of occurrences of the required elements may vary by model type.
- the transportation service provider specifies which model (or models) is used to nominate.
- the pathed model (model type 'P') expresses a transaction from a receipt location to a delivery location. This pathed line item depicts a single requested receipt or delivery quantity of gas for the path and date combination.
- the non-pathed model expresses a transaction at a receipt location or a delivery location.
- the non-pathed transaction (line item) varies with the location of the quantity. If the quantity is a receipt quantity, then a line item may be defined by a contract, receipt location, upstream identifier and contract, rank (two are available), quantity type, capacity type indicator and package id for a specified effective date range. If the quantity is a delivery quantity, the line item may be defined by a contract, delivery location, downstream identifier and contract, rank (two are available), quantity type, capacity type indicator and package for a specified effective date range.
- the non-pathed line item depicts a single requested receipt or delivery quantity of gas for the location and date combination.
- the pathed non-threaded model consists of two components.
- the components are the threaded segment (model type 'T') and the unthreaded segment (model type 'U').
- the threaded segment defines the receipt location to delivery location path of gas, with its associated contract, receipt and delivery location, quantity type and package id for a specified effective date range.
- the unthreaded segment functions similar to the non-pathed model above with the exception of the usage of ranks. In the unthreaded segment, the upstream and downstream ranks are sender's option and the receipt and delivery ranks are not used, while in the non-pathed model the receipt and delivery ranks are sender's option and the upstream and downsfream ranks are mutually agreed upon.
- the beginning date, ending date, and ending time are required data elements for all nominations.
- a Transportation Service Provider may also require the beginning time in nominations. When a nomination is submitted to request transportation of gas beginning with the start of the gas day and stopping at the end of the gas day, the beginning time and ending time may be defaulted to the standard. In this case, the service requester would include the beginning date and ending date for a nomination without the beginning time and ending time.
- a single line item is referenced by the nominator's tracking id. This data element accompanies every line item in the nomination transaction set. .
- the line items are referenced using the nominator's tracking id. This number facilitates a quick and consistent means of tying originating line items to their corresponding response fransaction.
- the service provider's activity code is assigned by the transportation service provider to identify a combination of nomination data elements specified by the fransportation service provider. It is used within the nomination process to represent a portion of the nomination components as specified by the fransportation service provider.
- the quantity type indicator is required.
- the quantity may be a receipt quantity or delivery quantity or may be designated as the quantity for both the receipt and delivery point ('both').
- both the sender and receiver of the nomination can derive the corresponding receipt or delivery quantity when one quantity is provided.
- the quantity in a nomination is always expressed as a daily (gas day) quantity, even for intraday nominations. This holds true regardless of the model type or quantity type indicator. Thus in the case of intraday nominations, the quantity expressed is always a daily quantity, even if the gas will not be scheduled to flow over an entire gas day.
- the transaction type is utilized to distinguish types of transactions such as fuel, overrun or payback.
- the package ID may be utilized by the service requester to make a single nomination line item different from another nomination line item when two or more line items are otherwise identical.
- a pathed nomination line item may be for the same contract, receipt and delivery location, and upstream and downstream parties, but the service requester needs the transactions to be unique for internal reasons.
- the package ID could be used by the service requester to distinguish between the two transactions and keep them unique.
- the service provider is not obligated to validate the package id, and should return the package id as received as applicable in the dataset(s) transmitted to the service requester. When combined with all of the other components of a nomination line item, it is used to determine if a nomination line item is unique. Nominations - GUI
- a gas controller can possess access to a number of modules according to a given security access, such as provided by a system administrator.
- the modules can include one or more of: Describe Nomination Plan, Describe Pipeline Templates, Describe Pipeline Configuration, and Create Pipeline Nomination.
- the Describe Nomination Plan module receives input from a Maintain Nomination module and a Describe Nom Plan Reference Information Module.
- the Describe Nomination Plan module is configured for describing a nomination plan.
- the Describe Nomination Plan provides an output to a Manage Best Available Quantity module.
- the Describe Nom Plan Reference Information provides input to the Describe Deal Location module.
- Describe Nom Plan Reference Information and the Describe Deal Location module provide input to a Manage Deal module.
- the Create Pipeline Nomination module receives input from the Gas Controller, as well as the Describe Pipeline Templates module, Describe Pipeline Configuration module, a View Pipeline EBB View, and a Send Pipeline Nomination module. In response to the input, the Create Pipeline Nomination module is configured to create a pipeline nomination.
- Figure 22 is an exemplary screen view of an Operations screen layout for nomination planning according to one embodiment of the present disclosure.
- the Operations screen layout includes a title bar, a permanent display area, search criteria area, supply, services, inventories, market, and nomination plan areas.
- Inventories includes pool points, storage points, and interconnects.
- Figure 23 is a screen view of an Operations screen layout for nomination planning including an example of content for the permanent display area.
- the permanent display area includes identification/information relating to an accounting company, facility, nomination period, flow period, unit of measure, and options for creating aggregate or single connections.
- the search criteria area includes an input box for entering a desired text to be searched and a search execution option.
- Figure 24 is a screen view of the Operations screen layout for nomination planning showing further detail of exemplary search criteria.
- the search criteria can be saved for subsequent usage or set as a default. Searching is available in one or more combinations of supply, market, services, inventories, and nomination plan.
- Supply atfributes include Deal ID, Supplier, Facility, Group Definition, Group Name, Receipt Location, Upsfream Reference, and Available Quantity.
- Market attributes include Deal ID, Market, Facility, Group
- Services attributes include Counte ⁇ arty, Facility, Service Agreement, Group Definition, Group Name, and Nomination Plan Quantity including receipt, delivery, and balance.
- the Inventories attributes include Facility, Pooling, Storage, and Interconnect.
- the atfributes include Point, Receipt Quantity, Delivery Quantity, and Balance.
- the attributes include Point, Receipt Quantity, Delivery Quantity, and Balance.
- the attributes include Receipt Quantity, Delivery Quantity, and Balance.
- the atfributes include Facility, Service Agreement, Supplier, Upstream Reference, Upstream Pkg ID, Receipt Location, Counte ⁇ arty, Nomination Transaction Type, Path Pkg ID, Delivery Location, Downstream Pkg ID, Downsfream Reference, and Market.
- Figure 25 is a screen view of the Operations screen layout for nomination planning showing further exemplary detail.
- the screen layout illustrates nomination planning for the accounting company Company XYZ having a nomination period of 4/1/2001 to 4/30/2001, and with a unit of measure MMBtu.
- the supply area indicates three deals, ID 1, ID 2, and ID 3.
- Each deal can be characterized by one or more of a Start, End, Term Ind, Supplier, Facility, Receipt Location, Rank, Deal Quantity, and Available Quantity.
- the Services area includes for one or more Facility, Service Confract, a Receipt, Delivery, and Balance.
- the Inventory Area includes Pool Points, Storage Points, and Interconnects, including one or more of Counte ⁇ arties, Type, Receipt, Delivery, and Balance.
- the Market area indicates four deals, ID 5, ID6, ID7, and ID8. Each deal can be characterized by one or more of an Available Quantity, Deal Quantity, Rank, Delivery Location, Facility, Market, Term Ind, Start, and End.
- an Upsfream Information area is provided in the lower left hand region of the Operations. Nomination Planning, screen view.
- the Upstream information includes one or more of supplier, reference, Pkg ID, Rank and Quantity.
- a Nomination Plan area is provided in a lower central region of the Operations.
- the nomination plan includes a receipt total and a delivered total.
- Each line of the nomination plan table can include one or more of Receipt Quantity, Receipt Location, Receipt Rank, Facility, Service Contract, Type, Fuel %, Fuel Quantity, Path PkgID, Delivered Rank, Delivered Location, and Delivered Quantity.
- a Downstream Information area is provided in the lower right hand region of the Operations, Nomination Planning, screen view.
- the Downstream information includes one or more of Quantity, Rank, Pkg ID, Reference, and Market.
- the Receipt Location information includes further detail for receipt location Rec2, corresponding to Upsfream Information Up3. Additional upstream information can be provided in the upsfream information area of the display, as indicated by an arrow.
- the Receipt Location information includes further detail for receipt location Rec5, corresponding to Upstream Information Up4 and Up5. Additional receipt location information can be provided in the nomination plan information area of the display, as indicated by an arrow.
- the Delivery Location information includes further detail for delivery location Dell.
- Dell includes Dnl, Dn2, and Dn3, as well as respective available quantities, deal quantities, and ranks.
- Additional downsfream information can be provided in the downsfream information area of the display, as indicated by an arrow.
- the Delivery Location information includes further detail for delivery location Del5, corresponding to Downstream Information Dn4 and Dn5.
- Additional delivery location information can be provided in the nomination plan information area of the display, as indicated by an arrow.
- the screen view of the Operations, Nomination Planning shows additional exemplary services information in the service contract column of the nomination plan information area of the display, as indicated by an arrow.
- the screen view of the Operations, Nomination Planning shows additional Inventory information in the receipt and delivery columns of the nomination plan information area of the display, as indicated by arrows.
- the respective screen views of the Operations, Nomination Planning, display of Figure 25 are shown in further exemplary detail.
- one set of reference information is shown depending upon which delivery or receipt location is highlighted, as indicated by the arrows.
- additional nominations detail is shown in the nomination plan area of the display, as well as upsfream and downstream information.
- the additional nominations detail includes upstream information and a corresponding nomination plan.
- the additional nominations detail includes a nomination plan and corresponding downstream information.
- upstream information, a nomination plan, and corresponding downstream information are shown.
- the whiteboard detail enables a system user to evaluate various deal scenarios for potential use in a given nomination plan or plans.
- the whiteboard detail includes a region for Purchase, including Deal ID, Price, Quantity and Flow Unit.
- a region for Sales includes Flow Unit, Quantity, Price, and Deal ID.
- a central region is provided for Converted data, corresponding to respective purchase and sales deals.
- a Deal Sub Total is provided, as well as Interconnect Sub Total, and a respective Total Purchases/Total Sales. Any difference between the total purchases and total sales is provided as a Difference variable.
- Figure 36 provides a further screen view of the whiteboard detail of Figure 35 according to another embodiment of the present disclosure, including Deal ID, Volume, Flow Unit, Currency, Price/Index, Current Unit, Points, Area, Region, Service, and Spot/Term Dealmaker.
- Figure 37 provides a further screen view of the whiteboard detail of Figure 35 according to another embodiment of the present disclosure, for example, a whiteboard summary including for each respective pipeline, a total difference, and a purchase, sales, and difference for a baseload, a swing, and an interconnect.
- STANDARD API FOR DATE RANGE RECORDS STANDARD API FOR DATE RANGE RECORDS
- validation patterns are used in connection with the database tables (entities).
- An exemplary table of terms, definitions, and respective database mappings is provided in the table below.
- the terms “table”, “column” and “row” are used when referring to validations derived from the data model.
- Non-Date Range The Physical Key for the class uniquely represents a single object.
- the class may have attributes for a begin and end date that represents the active range of that object, but the begin and end dates are not part of the logical key of the class. There is no way to represent an object that has different atfributes for different date ranges on this class.
- An example of a Non-Date Range table with begDate and endDate attributes is the CodeValue class.
- Date-Range The class is used to represent a Date-Range Object. It has different attributes for different date ranges.
- the class will contain a master ID attribute that represents a single object.
- the Physical Key for the class does NOT uniquely represent a single object, but rather the definition of that object for a date-range.
- the class must have atfributes for a begin and end date that represents the definition of an object for that active range.
- the logical key for the class must include the begin and end dates.
- An example of a Date Range table is the Facility class.
- Classes that use a Business Object Class may include the following.
- the physical key of the class is generated from the BusinessObject class.
- the class is assigned a unique ID in the BusinessObjectType Class.
- the classes that use the BusinessObject Class can either be Date-Range, or Non-Date Range classes.
- An example of a class that uses the Business Object table is the Facility class.
- the system architecture includes a standard API that is designed to be used to select, create, update, and delete date-range records.
- Several tables have been created that serve only to generate Master ID keys for a related date-range table. Examples of these tables are the point and pointHeader tables.
- the pointHeader table contains a primary key,
- the findByVariableFilter method allows any combination of selects using any of the attributes on an entity, and the following allowed operations:
- An insert of a new date-range record is straightforward affair.
- the calling process sends the attributes of the entity and a date-range.
- the information is validated and inserted. If any validation errors are found, a compiled list of validation messages is sent to the calling process.
- Updates An update of an existing date-range object requires a MasterJD attribute to uniquely identify the object to be updated.
- the calling process also sends the new atfributes of the object and a date-range.
- the information is validated and inserted. If any validation errors are found, a compiled list of validation messages is sent to the calling process.
- old records are checked to see if they overlap. They must then be resolved. This process assures that no overlapping records are created when an update occurs.
- the calling process sends the master lD only. Validations are done against deleting all for that master TJ. If the deletion passes the validations, then all records with the master ID are deleted. If any validation errors are found, a compiled list of validation messages is sent to the calling process.
- Date-Range entities where no gaps are allowed will have additional functionality to deal with "Lifespans".
- a lifespan represents the logical beginning and ending date of a Date-Range Entity Instance.
- Every date-range entity that allows no gaps, and that has a logical end date would have the following method:
- the calling process would call "ChangeLifespan" to change the lifespan of a record.
- the newBeginDate or NewEndDate parameters could be null, indicating no change on that date. If validateDateLoss is True, then a validation occurs whether any rows of data will be deleted when the date range is changed. If any rows of data would be deleted, then an error message is sent to the calling process.
- Every date-range entity that allows no gaps, and that has NO logical end date would have the following method:
- the calling process would call "ChangeLifespan" to change the lifespan of a record. If validateDateLoss is True, then a validation occurs whether any rows of data will be deleted when the date range is changed. If any rows of data would be deleted, then an error message is sent back to the calling process. Delete Range
- Date-Range entities where gaps are allowed will have additional functionality to deal with deleting specific ranges. These will typically be transactional records that have no single lifespan. They can go in and out of existence.
- Example : Nomination #1 might have the following date-range records:
- an update of one or more atfributes independent of the existing date range records can be accomplished as follows. Several modes are identified for this.
- Selected Date Range - Update atfributes from the selected begin date, to the selected end date.
- EndDate The calling process sends in null values for Atfributes that have not changed.
- the calling process sends in the changed values for the atfributes that have changed. If an attribute is needed to be set to null, then the corresponding "setAtfributeXNull" parameter is set to true.
- the "SetAttrbuteXNull parameters are only included if the corresponding database column is nullable.
- the BegDate and EndDate parameters have the following logic: If the begDate parameter is null, then the lifespan begin date will be used for the begin date.
- the lifespan end date will be used for the date range. This allows for the following types of calls to be done:
- a validation is done to test for any gaps between the begin and end date of the update. If there are any gaps where records don't exist, then the update will fail, and a validation message will be returned.
- the business layer utilizes API's that model a respective domain and not the underlying data model.
- each API interface is made to be more object or semantic oriented rather than data centric.
- the location of methods for each API design is made to be intuitive. For example, all finds for facilities are on the facility API and any code values associated with a facility come from the facility API.
- the business layer API is also made to be non-screen centric. That is, the API does not focus on screens, although the primary consumer is the GUI. Rather the API accommodates the needs of the screens while providing an API that can be used for other applications, such as reporting, conversion, and voice response units.
- a GUI Screen may call several API classes, each API class mapping to a business object that the GUI needs to communicate with. API Standards
- API classes With respect to API classes, they represent domain objects that hide the physical storage in the database. API's are not mapped to screens but to domain models. All external calls go through an API bean. The Non-API business layer beans are not called directly from a GUI.
- An API has been created for selecting lists of code values.
- the class is called "SystemAPI". It contains a method referred to as findCodeValuesByCodeType. This allows for any list of code values to be selected back, as long as the calling process can specify the constant for the associated code type.
- Other API classes would only be required to provide "find" methods for code values if there is a business requirement to filter the code values that are sent back.
- Find methods on the API's are designed to return all columns from a database table, when selecting from a single table. The calling process, however, can ignore any unneeded columns. Standard findByVariableFilter methods provided on the Entity EJB's are used when selecting data from a single database table.
- MasterJQD keys are used instead of physical keys to uniquely reference a business object.
- the Master JD key is often related to a header, instead of the business object itself.
- a "facility" object is uniquely identified by a "FacilityHeaderJTJ” value.
- GUI to API Interface Design Sequence dia rams are useful for mapping combos, list boxes, and grids of a GUI to the corresponding methods of an API class. They serve two pu ⁇ oses. First, the sequence diagrams can provide documentation so that a GUI designer can verify that there is an existing interface for all of a respective screen's requirements. Secondly, the diagrams can provide documentation to the GUI developer so that the developer knows which method on which API class to call for each screen element on a particular GUI.
- API classes are defined with respect to functional areas.
- a single API class may be used in multiple sequence diagrams across different functional areas. Sequence diagrams concentrate on the unique needs of a specific GUI.
- Sequence and activity diagrams can be used to document business processes that occur underneath the API class. For example, sequence diagrams can be used to show what other classes are being called by the API class. Activity diagrams can be used to show the logical flow of complex business processes Coding API's for Domain objects
- Each domain object identified in the system is associated with an API class.
- the particular class is a stateless session bean and provides a set of methods for manipulating the domain object and all of its associated details.
- the methods for creating or updating a domain object may require XML-Bound classes to allow a calling process the ability to send in a complex structure of data.
- This structure may contain collections of domain detail information.
- the API class will be in charge of brokering the domain detail information to the "Entity" EJB's that it relates to. Shared Domain Detail Objects that have their own API's.
- Some Domain Detail Objects are shared by more than one Domain Object.
- An example would be "Groups.” Many Domain Objects have groups of other Objects.
- a Groups API hides the complexity of dealing with groups.
- a calling process calls a Domain Object's API to get a list of it's detail groups. The Domain Object would then call the Groups API. If a Domain Object has Detail Objects that have their own API's, the Domain Object can be used as a broker for looking up existing details.
- a Domain Object can contain methods to manipulate (create/update/delete) a Domain Detail Object, but this should be limited to the scope of the Domain Object.
- a PointAPI bean could allow functionality where points can be added to or removed from existing groups of points. This would involve the PointAPI bean calling the GroupAPI bean. If, however, the calling process wanted to create a new group, or a new type of group, a Generic Group Screen is provided that calls the Group API directly.
- the system architecture includes a number of System- Wide Utilities, several of which are presented below.
- a class factory creates a corresponding class.
- Utility Factory Class
- the factory class is com.alfra.common.util.UtilityFactory.
- the class factory contains a set of static create methods for use to create a utility that implements a utility interface.
- the utility may be different depending on the parameter(s) sent into the create method.
- the create method will only accept an ASP Customer ID as a parameter which allows for different utilities to be instantiated for different customers.
- the utility factory creates the correct rounding utility according to the
- UtilityFactory.createRoundingUtility (Integer ASPCustomerJD). As this is a static method, the system does not instantiate the factory class.
- UtilityFactory.createRoundingUtility(getCallContext().getAspID()); double result iRoundingUtility .round(value, decimalPrecision); Documentation for the iRoundingUtility .round method is as follows: parameter value Contains the value to round, parameter decimalPrecision Contains the decimal place to round. Based on the power of 10.
- DATEJ3EGINNING_OF_TIME and DATEJ3ND_OF_TIME can be declared in a
- Date Constants file such as, com.altta.common.date.DateConstants.
- Bound Data Objects are business objects that can be marshaled through the system architecture of the present embodiments. They are designed to support a configurable object state (i.e. ADD, UPDATE,
- DELETE DELETE
- XML Schema file a file similar to the one below is created. An explanation of this file structure is provided subsequently. The text in bold will be explained.
- the file structure of .xsd files is kept the same for various schemas of the present embodiments, except for the ⁇ element> elements (in box), which contain the information about the XML-Bound Objects to generate.
- XML-Bound Data Objects are used by an API whenever the calling process needs to send collections of data, or structures of data through the API's method parameters. Process Methods for XML Bound Data Objects
- API's that allow the calling process to do creates, updates, and removes through XML-Bound Objects have a single method, "process".
- the method uses a "getCmd” method on every item in the XML-Bound object to determine whether a Create, Update, or Remove action should be performed on that item.
- the process method can return an "int" value. On a create, the "int" value can be the ID Key of the first row created. On an update or remove, a zero value can be returned.
- XML-Bound objects often either contain collections of other XML-Bound Object, or are collections of XML-Bound Objects. Collections are iterated through and each item in that collection is checked to see if it is marked for a Create, Update, or a Remove action. If the item is not marked for any of these actions, it is ignored. It is possible that an XML-Bound object could contain a header item which is marked for no action, and one or more detail items that are marked for some action. In this case, the header item is ignored, and the detail items are processed.
- XML-Bound Object being processed is a related object, then the method would include "Process ⁇ Object>", where ⁇ Object> is the name of the business object that is being changed. Create. Update, and Remove methods. APIs that are not using XML Bound Objects to perform creates, updates and removes utilize "create",
- the "create”, “update” and “remove” methods that manipulate a domain object can be named, “create”, “update” and “remove”.
- PointAPI.create() can be used to create a new point.
- the "create”, “update” and “remove” methods that manipulate a detail of the domain object can be named, “create ⁇ OBJECT>”, “update ⁇ OBJECT>” and “remove ⁇ OBJECT>” where ⁇ OBJECT> is the name of the domain detail object.
- PointAPLcreateAliasO can be used to create a new alias for a point. Lifespan Functionality
- Some GUI's require lifespan functionality for certain business objects. These business objects are date-range objects that are considered to have lifespans. This means that the business object is not transactional and that it could not go in and out of existence.
- the API for the related business object can include public methods that correspond to the following methods, for example: findLifespan - Returns the absolute begin and end dates for a date-range object. updateLifespan - Changes the absolute begin and end dates for a date-range object. findByDates - Returns all of the date-range records for a specific date-range object.
- the findLifespan and updateLifespan methods call the same methods on the related DL class.
- the DL Class inherits the findLifespan and updateLifespan methods from a BaseDateRageDL class.
- the findByDates method can be defined as follows: public XmlRowSet findByDates ( Integer master ID, java.util.Date begDate, java.util.Date endDate, String orderBy) throws RemoteException;
- the findByDates method can be implemented, for example, by calling a findByVariableFilter method on a related "Entity" class. Deletion by Date Range
- Some API's may require the ability to remove the definition of a business object for a date range. These business objects are date-range object that are considered to not have lifespans. This means that the business object is transactional and that it could go in and out of existence.
- the API for the related business object can include a public method, for example, that corresponds to the following: RemoveForDateRange. This API method can be configured to call the same method on the related DL class. Validation Logic Vs. Business Logic
- validation logic is placed in the "Entity" EJB's (as opposed to the API EJB's) to enforce data integrity. This accomplishes two things. First, validations are processed if the calling process circumvents the API and calls the Entity EJB directly. Secondly, by having all of the validations in the "Entity" EJB's, all validations can be done and returned to the calling process as a package.
- TranslationAPI.createLanguageDefinition method is called. Inside this method the following "Entity" EJB's are called: I. TermEJB - Store the name and description of the language in the term table. Language names can be translated to other languages.
- the API may get remove requests that require cascading deletes. Cascading deletes are handled inside the main "Entity” EJB's remove method. Deletes on dependant business objects are done through the corresponding "Entity” EJB's standard remove method. Accordingly, this assures that whatever validation logic is placed into the "Entity” EJB for removes gets called.
- an API DL class is created and the custom find method is placed in the API DL class.
- the API DL class extends the com.alfra.common.ejb.BaseDL class.
- the file is named ⁇ Domain Object>APIDL.java, where ⁇ Domain Object> is the same name used in the name of the API bean.
- the API class should instantiate the DL class through the "DLClassFactory" class for the package.
- an API class can be configured to directly call another DL class' find methods. Accordingly, an API class is able to call another DL class directly for invoking a find method.
- a domain object describes a single person, place, thing, or concept.
- the domain object contains sufficient detail information with it to have meaning on it's own, without the necessary association with other domain objects.
- a Domain Object keeps a consistent identity, regardless of the changes to it's associated detail information. Domain objects may also be referred to as Business objects.
- a Domain Object Detail is a piece of information, or attribute, that is needed to flesh out the details of the domain object.
- a Domain Object Detail is ambiguous on it's own, unless associated with a domain object. Domain Object Detail information can have date-ranges associated with it, that give a Domain Object different attributes on different dates.
- a Domain Object Detail comprises a small number of attributes, and is tightly bound to a single Domain Object. If a Domain Object Detail has a significant number of atfributes and can be related to more than one domain object, then the Domain Object Detail is considered as a separate Domain Object.
- Point An example of an object that has both Domain and detail characteristics includes a Point.
- a Point might be considered to be a detail of a Facility. Because it can also be thought of as a detail of Confracts and Nominations and Deals, Point is treated as an independent Domain Object, with relationships to Facilities,
- Determining which are the domain objects can be established by whether the object can be "Pictured" or conceptualized without any association to another domain object. Determining which are the Domain Object Details can be established by whether the object seems more like the attribute of a domain object, and whether the object doesn't make sense unless associated with a domain object.
- a facility will have significant detail information associated with it and only it. It can be conceptualized as an object based on information that is only associated with it. A contract, point and nomination can also be described as domain objects under this same criteria.
- a termination date, point of view, latitude, longitude, or quantity have ambiguous meanings unless associated with some domain object. This makes the several items more like attributes than Domain objects, and therefore should be considered Domain Object Details.
- An illustrative example of an ambiguous Domain Object/Detail determination is an Address. Is it a
- An address can have significant detail information associated with it. It can have street name, street number, city, state, and zip code information associated with it. It can be conceptualized as uniquely identifying a certain spot in the world. It can also be thought of as being ambiguous until associated with a person, place, or thing. It is certainly a necessary atfribute of many possible domain objects (House, Restaurant, Hospital, etc.).
- an address can be treated as a domain object if more than one domain object would be allowed to have an associated address.
- a single repository or set of tables can be used for all addresses, with foreign keys to relate the addresses to one or more types of domain objects (such as Domain Parties and Facilities).
- more than one domain object can be made to share the same address object, however, this would make a change to the address object effect all related domain objects.
- An address could be also be treated as a domain object detail, if addresses are restricted to a single domain object. If only Domain Parties can have addresses, then it might make sense to think of addresses as a detail of the Domain Party object. Even in this case, an address has a rich enough set of detail information associated with it alone to be considered a Domain Object.
- DYNAMIC LABELING Dynamic labeling allows the user to modify form titles, form labels, system messages, and certain system code data fields. This option is required for both multiple language support as well as for different ways to refer to the same object in the same language. For example, this function can be used if a label is displayed in English and the user wishes for that label be displayed in French. Another example of the use of this function will be if one English user wishes to see the point where gas enters a pipeline referred to as "Receipt Point", and another wants to call it "Delivery Point”, while a third wants to call it "Entry Point.”
- the system generates messages to the user, usually in the form of a pop-up window. These messages can be informative (i.e. "2 Nominations Added - OK"), warnings (i.e. "Nomination Point will be deleted - OK - Cancel”), system errors (i.e. "Statement i.d. was not set. Invoice cannot be generated - OK”), or foundation software messages (i.e.
- the system architecture is further configured with a facility to provide for translation of these fields into multiple languages.
- a language variation is different from a new language in the fact that, for a variation, the vast majority of text strings are identical.
- a special methodology for generating these variations is provided. One method is to generate table entries of only the variations. Another method involves the "copying" of one language to the variation, and then modifying the entries that are different, the method being configured for assuring that the unmodified fields remain synchronized.
- Provide Facility for Selecting a Language for Each User - Language will be selected by each individual user, not established for all users of a database. This allows a company that has users in multiple countries, who speak different languages, to provide each user with a system in their preferred language. The system allows changing the language to which each user is assigned. In one embodiment, a user can select his own language without having to rely on the system administrator to select it for him or her.
- Provide Facility for Allowing a User to Override his Translation for Individual Items -
- the system is configured to provide ability for individual users to override the presentation of a sfring.
- Provide Identification Facility for Forms, Reports, Fields, and Messages - When all of the text fields are translated into a different language, it may be difficult to identify which item a user is referring to when he or she calls customer service with a question or problem. Accordingly, numbers, codes, or other suitable means are employed to provide positive identification of the items to which the caller is referring.
- the system includes a tool provided to help facilitate this onerous task.
- One way to do this is to provide a display with the base system string on one side and a slot for entering the new sfring on the other.
- a more sophisticated implementation could display the screen or report that contains the string, highlight the sfring to be franslated, and provide a slot to enter the translated string.
- the system is configured to bypass strings that the user does not need to translate. For example, if the translation is intended only for a pipeline, there is no need to translate sfrings that only occur in items dealing with purchase or sales deals.
- Provide Facility for Maintaining Each Language After the new language is generated, the system is further configured to allow the user to maintain their new language. This may involve situations where the user just wants to change a translation or when additional items must be added.
- the system is further configured to provide such a facility.
- the system includes a single dictionary of American English versions of the strings.
- Allow Users to Define Additional Sfrings in Their Own Language - Users are encouraged to, and will, develop their own custom applications to work with the system software and database. In most cases they will likely hard-code the text strings in their normal language. But in some cases they may wish to have users in different countries see these screens in different languages. Accordingly, the system is configured to provide them the ability to use the multi-language facility of the system. This involves giving them the ability to enter their own entries in the tables, with some ability to differentiate their entries from base system entries so database updates will not interfere with user-defined strings.
- the system is configured to identify duplicate sfrings so that they can be eliminated.
- the system includes a suitable routine necessary to differentiate between sfrings that are part of the base system from strings that have been entered by the user.
- the system is configured to provide a facility to identify untranslated strings.
- the system is configured to provide a facility that automatically generates comments in the code with the text representation of each field that is generated from the dictionary.
- the system provides a suitable tool generated to assist with this task.
- One tool for achieving this could be the generation of a cross-reference showing where each dictionary entry is used. For example, suppose a programmer replaces a string on a screen with a different one, or if he deletes a string or even an entire form. A decision has to be made whether the deleted sfring should be removed from the dictionary, or whether it must be retained because it is being used elsewhere. In another case, if a sfring is changed on one screen it may be desirable to also change it on certain other screens but not all other screens. Having a cross- reference available can help make these decisions and can also do a great job of keeping the dictionary clean.
- the application is configured to be able to know one customer from another from both a deployable and hosted perspective.
- a customer will have a default language — a user may also have a different default language. This information will be used to determine which language to display the application if no user profile has been set up for the user currently logged into the application.
- Language Maintenance Information
- the System does not support the translation of user-entered data from one language to another except for a few exception system value codes such as "Receipt'V'Delivery", "Entry'V'Exit", "Yes'V'No", etc.
- the default language for the system is English and the users can create/maintain any other language desired.
- ASP IMPLEMENTATION According to one embodiment, multiple ASP Customers can exist in the same database of the system architecture of the present disclosure. Accordingly, the system architecture further includes an ASP function to support a number of ASP Customers within a single database. Security is provided to prevent one ASP customer from being able to see any data from another ASP customer, even if they are using the same database.
- database tables are created to include an attribute to designate an ASP Customer ("ASPCustomer").
- ASPCustomer ASP Customer
- the ASP implementation of the system architecture of the present disclosure can be accomplished, for example, using a database server, such as commercially available from Oracle.
- a database server such as commercially available from Oracle.
- the system takes advantage of a security feature on the database server that allows the system architecture to automatically limit every userid to only access table rows that are assigned to the "System” or to that user's company. In this way, no special coding is required for the "ASPCustomer” fields - and none can be accidentally overlooked. Also, it will function regardless of the method the user uses to access the database. While the "ASPCustomer" attribute will not be functional for a SQL Server, having this field in the SQL Server tables will allows consistent table structures for both DBMSs.
- All system-supplied data is labeled with a standard "ASPCustomer" code of 0. All user-supplied data is labeled with a non-zero code assigned to that ASP Customer. Accordingly, using a database security feature, each user can access rows that contain an "ASPCustomer" of either zero or their respective assigned code.
- Any new items added by an ASP customer to a list of system-supplied data is stored with their "ASPCustomer" code, and the security will simply retrieve both system and user data as a cohesive set. If an ASP Customer needs to change certain system data, then that data can be converted into customer data for that particular customer or all ASP customers using the particular database.
- For Language-TermSet data all ASP Customers will have access to any base language in the database. Each TermSet, however, is maintained and accessed only by a single ASP Customer. This can be accomplished by loading all Language-Base TermSet data with an "ASPCustomer" code of zero. Other TermSets will have the "ASPCustomer" code of the user adding the respective TermSet.
- the system architecture includes language franslation.
- a function of the language translation is to translate labels and grid headers which appear in user interfaces from a first language to a second language.
- the presentation layer is configured to perform functions related to translating labels or header column names in the hyper text markup language ("HTML") information generated by the system architecture.
- the business layer is configured to perform functions related to translating standard system messages generated by the system architecture.
- the language franslation may be configured to include a dictionary.
- the dictionary may be stored within a web server application variable.
- the dictionary may be implemented as a hash table. EJB Dictionary Generator
- Ente ⁇ rise Java Bean may be used.
- An example embodiment of the logic configured to load the hash table is shown below: From each row of a language translation table, generate a key and an element.
- the key will be of type Sfring, made up of:
- the element will be the contents of the franslation column.
- the dictionary when the dictionary is either created or refreshed, it will be completely recreated and loaded from the language franslation table. The entire content of the language transaction table will be loaded.
- the dictionary may be initialized with the number of rows from the language franslation table, because that will allow allocation of memory resources to be more efficient.
- Language translation may be configured to allow refreshes to be done manually through an "apply” button in a "language translation setup” window.
- the "apply” button signals an EJB to create a new language franslation dictionary, to replace the current dictionary stored in the web server application variable.
- dictionary is configured to be thread-safe, the replacement of the current dictionary with a newly created dictionary may occur dynamically.
- EJB may create a new dictionary concurrently while the current dictionary continues to handle translations.
- the synchronization may be performed using an application lock. An example of embodiment of this process is shown below:
- Login process is configured to assign two session variables to users.
- the session variables are configured to provide information specific to each user in language translation.
- the session variables are configured to represent the language and the term set that a specific user prefers.
- the language and the term set may be selected from the userLanguageProf ⁇ le table, based on the userlD for the user.
- Login process is configured to set the languagelD to 1 and the termSetID to 0 If the language and the term set are not found for the userlD in the userLanguageProfile table.
- An example embodiment of the session variables is shown below: int termSetID Uniquely defines the term set used to do translation int languagelD Uniquely defines the language used to do translation Language Translation Serylet
- the system architecture includes a language translation servlet.
- the servlet is configured to perform the function of language franslation.
- the servlet is configured to access the dictionary stored in the web server application variable.
- the servlet will be passed parameter to facilitate the translation function. For example, following parameters may be passed to the servlet:
- ItemlD uniquely defines a label, header, or a message to be translated.
- the dictionary is implemented as a hash table.
- a combined key of itemlD, languagelD, and termSetID are sent to the hash table.
- itemlD will be returned as a sfring. This indicates to users that there was a problem with the language translation. The problem may be that either the itemlD value is not defined or the hash table was not stored correctly.
- the system architecture includes price structures adapted to handle all types of pricing and valuation occurring within the system architecture.
- the objective of price structures is to provide a single mechanism for capturing all possible prices within the system architecture, thereby allowing all prices and valuations to be resolved using common routines. Complexities of price structures are masked from users by graphic user interfaces, reducing the amount of data entry and the amount of information communicated to users.
- price structures are configured to allow users (such as data administrators) and application programming interface (“API”) to add, edit, and delete a price structure.
- API application programming interface
- a function of price structures is to provide an association mechanism. Another function of price structures is to provide flexibility in defining quantities, prices and how they relate to each other. Price structures are further configured to provide the system architecture with sufficient infonnation to calculate prices and valuations.
- price structures are configured to allow users to either associate a price structure directly with the object to which it will be applied, or associate it with an object that is at a higher level than the object for which the price structure information is being entered.
- the association mechanism reduces the amount of user data entry required, and is especially advantageous in business scenarios where one price structure applies to multiple items.
- the flexibility is achieved by price structures' including quantity formulas, price formulas, patterns, and multiple tiers of the same.
- the quantity formulas may be configured to facilitate derivation of total billable quantity for a price structure.
- Quantity fonnulas may be previously defined and preloaded in the system architecture or configured for user definition.
- Quantity formulas may also be configured to allow users and API's to add, edit, and delete a quantity formula.
- Price formulas may be configured to reference indexes, other formulas, and fixed prices. Price formulas may also be configured to perform operations including addition, subfraction, multiplication, and division, and functions including minimum (Min), maximum (Max), and average (Avg). Price formulas may be further configured to allow users and API's to add a price formula, edit a price formula, edit a search criteria, and delete a price formula.
- Patterns provide additional definition for price structures, thereby allowing prices to be defined for specific blocks of time within a price structure's effective date range. Patterns provide a more efficient method of capturing time specific information than manually entering the date range for a price structure.
- price structures also include price components.
- Price components may be configured to provide distinctive names for identifying charges associated with objects in the system architecture.
- Price components may include information which determine where within a price structure a price component may be used.
- Price components may also include information which determine how charges will appear on statements, and what processes will consider the charges for a specified price component.
- Price components may also be configured to allow users and API's to add, edit and delete a price component.
- price structures further include price indexes.
- Price indexes may be configured to maintain information used in price structures.
- Price indexes may also be configured to allow users and API's to add, edit, and delete a price index.
- Price indexes may be associated with index prices, which may also be configured to allow users and API's to add, edit, and delete an index price.
- FIG. 40 is a table describing information included by price indexes. Although entries included by other modules (price component, price formula, etc.), may differ for each of the categories ("attribute name", “required”, etc.), FIG. 40 is representative of the type of information included in the various modules.
- modules may be associated with one or more tables describing information included by each of the modules. As discussed above, all modules are configured to allow users and API's to at least add, edit, and delete objects for each module. These operations modify information as described by various tables associated with each of the modules. PLUG-IN FUNCTIONALITY
- a Plug-In generally refers to a component that can override base functionality.
- the plug-in implements a specific interface, and will be called on by a specific event.
- An Interface generally refers to a definition that dictates the format of a component's inputs and outputs. The interface is an agreement between a calling process and a component that the component will support certain inputs and outputs. The interface does not restrict the internal activities inside a component.
- An event generally refers to an activity that the system guarantees can be intercepted by a Plug-In component.
- the plug-in component that will be picked to intercept and process the event will be determined by the best-fit rules associated with the event. Best-fit rules refer to the criteria that is used to determine which Plug-In will be used to process an event. The criteria are established at design time, along with the interface definition.
- the best fit rules for rounding are determined by the ASP Customer who the rounding is being done for, and no other criteria.
- the Interface for rounding includes:
- the interface for the plug-in must be defined; the data required to resolve the Best Fit rules must be defined, and the system must be written so that whenever an event (such as rounding) occurs, that: a) the system has available in memory the data required to resolve the correct Plug-In according to the Best Fit rules and in the case of rounding, it must have access to the ASP Customer ID associated with the data being rounded; and b) the system must find the correct plug-in according to best fit logic.
- the plug-in must implement the expected interface.
- the system must call the plug-in and get a successful result back.
- Plug-In Functionality that needs to be overridable at a Product level. If there is a need to override base functionality at a Product or system level, then this can be done through the switching out of Ente ⁇ rise Java Beans within the EBJ Server environment. A change done using this technique requires no database tables or special logic. When this change is done to a local installation, it would be across the entire system, regardless of ASP customers. While overriding a base functionality can be accomplished through a switchout of an EJB, it would be technically feasible to replace a component, and then get that component to broker out work to other components based on ASP customer information or other information available to that component.
- a coding technique called "Factory Classes" is used to provide plug-in functionality at an ASP customer level. This requires the hard coding of the ASP Customer number inside the factory class for specific ASP customers that require a custom plug-in, instead of a default plug-in.
- Several plug-in components that have been created using this coding technique, include prorating, rounding, and rounding resolution. Rounding resolution resolves rounding errors that occur as a result of prorating. Implementing Plug-In Functionality that should be overridable according to Best-Fit Pattern logic.
- Plug-in functionality requires best-fit logic beyond the ASP Customer ID, then it will be necessary to store information about the plug-in to a set of database tables.
- the database tables should hold: the name of the plug-in; associated best-fit information (This information will be used to determine when the plug-in should be used); a reference to the standard best-fit logic tables; and an association to the event that the plug-in should be associated with.
- the implementation of the plug-in functionality can take into account information about existing System-Defined events, such as: the interface that a plug-in must implement to be used by the event; the data required to resolve the best-fit logic pattern; and the functionality of the default plug-in that will be called if no other plug-ins are provided, or if best-fit rules find no overriding plug-in.
- Implementing Plug-In that can be added through messaging.
- One advantage of using a messaging layer is to be able to tie functionality into events associated with calls to the ente ⁇ rise java bean methods. These will include the creation, updating, and removal of data. This can also include methods that kick off business processes, such as generating a Nomination Plan, or an
- a module configured according to a Describe Deal Use Case Specification (UCS) allows a Marketer's Dispatcher, Gas Scheduler or Gas Controller (collectively referred to as "User”) to maintain Deal Reference (Reference Information).
- UCS Describe Deal Use Case Specification
- Reference Information refers to Upsfream/Downsfream information (i.e. Confract, Quantity, and Ranks) associated to the Deal Location/Point.
- the reference information is primarily used for Confirmation pu ⁇ oses with the Facility/Pipelines.
- the required and optional Upstream Downstream information will vary by Facility and is always associated to a Deal Location that is a point. Regardless of what is required, the User must be able to access a user interface and maintain this information from different places within the system.
- the Reference Information is sometimes gathered by the User, may be provided to the User by the Trader, obtained from an external third party(ies) or a combination thereof.
- the Describe Deal UCS is a prime candidate for a "Configuration Manager". That would allow Users the capability to designate by Facility the required and optional attributes.
- the Describe Deal use case starts when the User wishes to add, edit and/or delete Reference Information in the system. 1.
- the User specifies the function to perform (either Add, Edit, or Delete Reference Information).
- the User enters or selects the Reference Information.
- the system refrieves and displays the applicable Reference information, if any.
- the system validates the Reference Information per a Reference Information Attribute Table. 6.
- a Business Rules Validation alternative flow is executed.
- the User makes the desired changes or additions to Reference Information.
- the system prompts the user to confirm deletion of the Reference Information.
- the system deletes the Reference Information from the system.
- a Describe Deal Quantity use case allows a Trader, Deal Administrator, Gas Scheduler or API Interface (collectively referred to as "User") to maintain Deal Quantities.
- Describe Deal Quantity can be as simple as entering a quantity or a more complex process of identifying ranges, tolerances, patterns, temperatures, percentages, multiple quantity types, etc.
- Deal Quantities may be defined and associated to Deal Components, Deal Component Points and Deal Component Path. The Describe Deal Quantity use case will always be invoked by another use case or via an API.
- a precondition to the Describe Deal Quantity use case is that the User has identified the Object Type and specific Object (Deal Component, Deal Component Point or Deal Component Path) for which they intend to manage Deal Quantities.
- the user has identified the quantity information to be entered. This information is expected to be available via User Profiles and Configuration Parameters.
- the quantity information can include, but is not limited to, the following: a) what classification of quantities are being entered - (e.g., Volume, Energy, Heating Value); b) the default Units of Measure to use with each quantity classification; c) the Pressure Base information for which quantities are being recorded; and d) quantity Type to use as a default (i.e., Deal Max Daily Quantity).
- a basic flow of the Describe Deal Quantity use case includes:
- the system will determine the required default atfributes required for Deal Quantity; 3. System validates the Deal Quantity information per the attribute tables; and
- the Entered Deal Quantity is added, edited or deleted from the system; the Calculated Deal Quantity is added, edited, or deleted from the system (the Calculated Quantity will be used in downsfream processing.); message is sent to the Charge Calculation queue; and message is sent to the initiating use case indicating that the Deal Quantity was successfully added, updated or deleted. If the Deal Quantity was updated, the message should specify what changed.
- An advanced edit deal quantity use case starts when the user wants to enter more than a simple quantity.
- the flow includes:
- System validates the Deal Quantity information per atfribute tables. A Business Rules Validation alternative flow is executed. System saves the new or modified Deal Quantity information. The use case ends. To edit a Deal Quantity the user makes the desired changes or additions to the Deal Quantity information.
- the system prompts the user to confirm deletion of the Deal Quantity; the user verifies the deletion; Delete Rules Validation alternative flow is executed; the system deletes the Deal Quantity from the system (Display UCS Message #2); and the use case ends.
- Quantity Type some system, and some user-defined code values that describe the type of quantity that can be added to a Deal Component, Deal Point or Deal Path.
- Quantity Unit- Coupled with Flow Rate describes the rate of flow of energy for a deal, nomination, etc.
- Example is 100 Dth per Day, where Dth is the Quantity Unit.
- Flow Rate - Coupled with Quantity Unit describes the rate of flow of energy for a deal, nomination, etc.
- Example is 100 Dth per Day, where Day is the Flow Rate.
- Minimum Granularity An indicator of the frequency for which the quantity may change during the period. Will often be equal to Flow Rate.
- Pattern An identifier of the pattern of flow of energy commodity within the date range of the obj ect. This could mean the energy commodity flows only on certain days of the week, or certain hours of the day, defined by the Pattern Details.
- Pattern Detail The details of the Pattern that indicate which weekdays and which hours of the day that the energy commodity is to flow.
- Minimum Temperature - For temperature tiers (often called weather options), this defines the minimum contractual temperature for the band of temperatures applicable for a quantity.
- Temperature Unit For temperature tiers (often called weather options), this defines the units of measurement for temperature for contractual parameters specifying the band of temperatures.
- Load Factor Type - Indicates whether the Load Factor percentage is a minimum (“MIN”) or a maximum (“MAX”) under the contract.
- Load Factor Percent describes the minimum percentage of the Maximum Quantity that must be fransacted under the confract, if maximum, describes the maximum percentage of the Maximum Quantity that must be fransacted under the confract.
- Figure 41 illustrates a number of examples of deal quantities produced using the Deals Quantity Use case.
- the quantity type EXP (“Expected") identifies a particular quantity for position/risk management, where the contractual Min and Max differ.
- RTC indicates Round The Clock to denote all hours and all days.
Landscapes
- Business, Economics & Management (AREA)
- Engineering & Computer Science (AREA)
- Strategic Management (AREA)
- Accounting & Taxation (AREA)
- Finance (AREA)
- General Business, Economics & Management (AREA)
- Theoretical Computer Science (AREA)
- Economics (AREA)
- Entrepreneurship & Innovation (AREA)
- Physics & Mathematics (AREA)
- Marketing (AREA)
- General Physics & Mathematics (AREA)
- Development Economics (AREA)
- Human Resources & Organizations (AREA)
- Technology Law (AREA)
- Data Mining & Analysis (AREA)
- Operations Research (AREA)
- Quality & Reliability (AREA)
- Tourism & Hospitality (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Stored Programmes (AREA)
Abstract
Description
Claims
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/480,335 US8065219B2 (en) | 2001-06-13 | 2002-06-13 | System architecture and method for energy industry trading and transaction management |
AU2002322090A AU2002322090A1 (en) | 2001-06-13 | 2002-06-13 | System architecture and method for energy industry trading and transaction management |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US29774501P | 2001-06-13 | 2001-06-13 | |
US60/297,745 | 2001-06-13 |
Publications (3)
Publication Number | Publication Date |
---|---|
WO2002101510A2 true WO2002101510A2 (en) | 2002-12-19 |
WO2002101510A3 WO2002101510A3 (en) | 2003-10-30 |
WO2002101510B1 WO2002101510B1 (en) | 2003-11-27 |
Family
ID=23147578
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/US2002/018781 WO2002101510A2 (en) | 2001-06-13 | 2002-06-13 | System architecture and method for energy industry trading and transaction management |
Country Status (3)
Country | Link |
---|---|
US (1) | US8065219B2 (en) |
AU (1) | AU2002322090A1 (en) |
WO (1) | WO2002101510A2 (en) |
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2004057825A2 (en) * | 2002-12-23 | 2004-07-08 | Sema | Method for communication between servers with data format conversion and device therefor |
CN1308880C (en) * | 2003-03-31 | 2007-04-04 | 台湾积体电路制造股份有限公司 | Technology main file document hold-down bar structure management system and method and semiconductor product and its mangment method |
GR20060100249A (en) * | 2006-04-27 | 2007-11-15 | Βασιλειος Γεωργιου Νικολοπουλος | Web-based energy search machine and method for decision making on the optimal management and pricing evaluation of energy resources. |
US7483757B2 (en) | 2005-07-22 | 2009-01-27 | Honeywell International, Inc. | Control system migration |
WO2016135771A1 (en) | 2015-02-23 | 2016-09-01 | Nec Corporation | Electric energy adjustment apparatus, system, method and program |
US10275291B2 (en) | 2003-11-24 | 2019-04-30 | Ebay Inc. | API and business language schema design framework for message exchanges |
US20210312547A1 (en) * | 2020-04-01 | 2021-10-07 | Xi'an Jiaotong University | Multi-energy trading and management platform based on blockchain |
CN116542698A (en) * | 2023-07-06 | 2023-08-04 | 厦门美契信息技术有限公司 | Enterprise customized intelligent development management platform |
Families Citing this family (123)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10586282B2 (en) | 1996-03-25 | 2020-03-10 | Cfph, Llc | System and method for trading based on tournament-style events |
US20040015578A1 (en) * | 2002-02-22 | 2004-01-22 | Todd Karakashian | Web services runtime architecture |
US7769825B2 (en) | 2002-02-22 | 2010-08-03 | Bea Systems, Inc. | System and method for web services Java API-based invocation |
US7412495B2 (en) * | 2002-04-26 | 2008-08-12 | Sun Microsystems, Inc. | Method, system, and article of manufacture for a server side application |
US20030225474A1 (en) * | 2002-05-31 | 2003-12-04 | Gustavo Mata | Specialization of active software agents in an automated manufacturing environment |
US7813993B1 (en) * | 2002-08-30 | 2010-10-12 | Advanced Micro Devices, Inc. | Method and apparatus for scheduling a resource |
US7617504B1 (en) * | 2002-09-12 | 2009-11-10 | Sprint Communications Company L.P. | Computer method and system for integrating enterprise JavaBeans into non-Java environments |
US7263517B2 (en) * | 2002-10-31 | 2007-08-28 | Biomedical Objects, Inc. | Structured natural language query and knowledge system |
EP1420340A1 (en) * | 2002-11-15 | 2004-05-19 | Hewlett-Packard Company | Remote object invocation system and method |
US7707544B2 (en) * | 2002-12-05 | 2010-04-27 | Bea Systems, Inc. | System and method for generating and reusing software application code with source definition files |
US7783557B2 (en) * | 2003-03-25 | 2010-08-24 | Future Freight Corporation | Computer-implemented display to facilitate trading in multi-modal freight shipment derivatives |
US20060200756A1 (en) * | 2003-03-25 | 2006-09-07 | Unisys Corporation | Publishing system including front-end client links to workflow engine and communication protocol schema |
US8353763B2 (en) | 2003-03-31 | 2013-01-15 | Cantor Index, Llc | System and method for betting on a participant in a group of events |
US7366722B2 (en) * | 2003-05-15 | 2008-04-29 | Jp Morgan Chase Bank | System and method for specifying application services and distributing them across multiple processors using XML |
US7890852B2 (en) * | 2003-06-26 | 2011-02-15 | International Business Machines Corporation | Rich text handling for a web application |
US20050010481A1 (en) * | 2003-07-08 | 2005-01-13 | Lutnick Howard W. | Systems and methods for improving the liquidity and distribution network for illiquid items |
US7261239B2 (en) * | 2003-12-17 | 2007-08-28 | Bindu Rama Rao | Questionnaire network for mobile handsets and a trading system for contracts on user commitments to answer questionnaires |
US7698184B2 (en) * | 2004-01-16 | 2010-04-13 | Bgc Partners, Inc. | System and method for trading a financial instrument indexed to entertainment revenue |
US20100114753A1 (en) * | 2004-07-12 | 2010-05-06 | Rosenthal Collins Group, L.L.C. | Method and system for automatic commodities futures contract management and delivery balancing |
US7742974B2 (en) * | 2004-10-18 | 2010-06-22 | Trading Technologies International Inc. | Flexible system and method for electronic trading |
US20080275582A1 (en) * | 2004-11-19 | 2008-11-06 | Nettles Steven C | Scheduling AMHS pickup and delivery ahead of schedule |
US7694065B2 (en) * | 2004-12-28 | 2010-04-06 | Sap Ag | Distributed cache architecture |
US8015561B2 (en) * | 2004-12-28 | 2011-09-06 | Sap Ag | System and method for managing memory of Java session objects |
US7539821B2 (en) * | 2004-12-28 | 2009-05-26 | Sap Ag | First in first out eviction implementation |
US7971001B2 (en) * | 2004-12-28 | 2011-06-28 | Sap Ag | Least recently used eviction implementation |
US20060143256A1 (en) | 2004-12-28 | 2006-06-29 | Galin Galchev | Cache region concept |
US8281014B2 (en) * | 2004-12-28 | 2012-10-02 | Sap Ag | Session lifecycle management within a multi-tiered enterprise network |
US8204931B2 (en) | 2004-12-28 | 2012-06-19 | Sap Ag | Session management within a multi-tiered enterprise network |
US20120239587A1 (en) * | 2005-03-10 | 2012-09-20 | Dickman Craig S | Method for shippers to manage fuel costs |
US7729998B2 (en) * | 2005-03-10 | 2010-06-01 | Dickman Craig S | Method for shippers to manage fuel costs |
US8190533B2 (en) * | 2005-03-10 | 2012-05-29 | Dickman Craig S | Method for shippers to manage fuel cost |
US20060248283A1 (en) * | 2005-04-29 | 2006-11-02 | Galin Galchev | System and method for monitoring threads in a clustered server architecture |
US8024566B2 (en) * | 2005-04-29 | 2011-09-20 | Sap Ag | Persistent storage implementations for session data within a multi-tiered enterprise network |
US7853698B2 (en) * | 2005-04-29 | 2010-12-14 | Sap Ag | Internal persistence of session state information |
US20060248199A1 (en) * | 2005-04-29 | 2006-11-02 | Georgi Stanev | Shared closure persistence of session state information |
US7761435B2 (en) * | 2005-04-29 | 2010-07-20 | Sap Ag | External persistence of session state information |
US8762547B2 (en) * | 2005-04-29 | 2014-06-24 | Sap Ag | Shared memory implementations for session data within a multi-tiered enterprise network |
US8589562B2 (en) * | 2005-04-29 | 2013-11-19 | Sap Ag | Flexible failover configuration |
US7966412B2 (en) * | 2005-07-19 | 2011-06-21 | Sap Ag | System and method for a pluggable protocol handler |
US8200563B2 (en) * | 2005-09-23 | 2012-06-12 | Chicago Mercantile Exchange Inc. | Publish and subscribe system including buffer |
US7831027B2 (en) * | 2006-01-25 | 2010-11-09 | Accenture Global Services Limited | Configurable charging system for a telecommunications service provider |
US7702770B1 (en) * | 2006-01-27 | 2010-04-20 | Sprint Communications Company L.P. | Web services enterprise integration with service oriented architecture |
US7757161B2 (en) * | 2006-03-15 | 2010-07-13 | Business Objects Software Ltd | Apparatus and method for automatically sizing fields within reports |
US20070255685A1 (en) * | 2006-05-01 | 2007-11-01 | Boult Geoffrey M | Method and system for modelling data |
US8059635B1 (en) * | 2006-05-05 | 2011-11-15 | Workday, Inc. | Non-destructive data storage |
US20080052145A1 (en) * | 2006-08-10 | 2008-02-28 | V2 Green, Inc. | Power Aggregation System for Distributed Electric Resources |
US10803474B2 (en) | 2006-11-22 | 2020-10-13 | Qualtrics, Llc | System for creating and distributing interactive advertisements to mobile devices |
US8700014B2 (en) | 2006-11-22 | 2014-04-15 | Bindu Rama Rao | Audio guided system for providing guidance to user of mobile device on multi-step activities |
US8478250B2 (en) | 2007-07-30 | 2013-07-02 | Bindu Rama Rao | Interactive media management server |
US11256386B2 (en) | 2006-11-22 | 2022-02-22 | Qualtrics, Llc | Media management system supporting a plurality of mobile devices |
US20080163063A1 (en) * | 2006-12-29 | 2008-07-03 | Sap Ag | Graphical user interface system and method for presenting information related to session and cache objects |
US7882500B2 (en) * | 2007-01-02 | 2011-02-01 | International Business Machines Corporation | Method and a system for composing an optimally-grained set of service functions |
US8650057B2 (en) * | 2007-01-19 | 2014-02-11 | Accenture Global Services Gmbh | Integrated energy merchant value chain |
US20080228518A1 (en) * | 2007-03-01 | 2008-09-18 | Braziel E Russell | System and method for computing energy market models and tradable indices including energy market visualization and trade order entry to facilitate energy risk management |
US7853499B2 (en) * | 2007-03-29 | 2010-12-14 | Board Of Trade Of The City Of Chicago | System and method of allocating an incoming order to standing orders |
WO2008131010A1 (en) | 2007-04-16 | 2008-10-30 | Cfph, Llc | Box office game |
US8527577B2 (en) * | 2007-05-22 | 2013-09-03 | Oracle International Corporation | System and method for configuration-driven deployment |
US20090182816A1 (en) * | 2008-01-10 | 2009-07-16 | Jean Xu Yu | Method and system for managing j2ee and .net interoperating applications |
US8290834B2 (en) * | 2008-04-25 | 2012-10-16 | Oracle International Corporation | Ad-hoc updates to source transactions |
US8103610B2 (en) * | 2008-05-30 | 2012-01-24 | Computer Associates Think, Inc. | Dynamic categorization of rules in expert systems wherein a profile definition yields classification data that classifies rules and allows for rules to be searchable |
US8386541B2 (en) * | 2008-09-16 | 2013-02-26 | Bank Of America Corporation | Dynamic change data capture process |
US8732062B2 (en) * | 2008-10-07 | 2014-05-20 | Chicago Mercantile Exchange Inc. | System and method for matching one or more incoming order to a standing order based on multi-level allocation |
US20100088213A1 (en) * | 2008-10-07 | 2010-04-08 | Czupek Andrew P | System and method for matching one or more incoming order to a standing order based on multiple order priority |
US8566218B2 (en) * | 2008-10-07 | 2013-10-22 | Chicago Mercantile Exchange Inc. | Systems and methods for matching one or more incoming order to a standing order as a function of an inner market parameter |
US20100088215A1 (en) * | 2008-10-07 | 2010-04-08 | Czupek Andrew P | System and method for matching one or more incoming order to a standing order based on multiple order priority allocation |
US20100088216A1 (en) * | 2008-10-07 | 2010-04-08 | Czupek Andrew P | System and method for matching one or more incoming order to a standing order based on time order priority allocation |
US8751284B2 (en) | 2009-04-30 | 2014-06-10 | United Parcel Service Of America, Inc. | Systems and methods for a real-time workflow platform using Petri net model mappings |
US8332811B2 (en) * | 2009-04-30 | 2012-12-11 | United Parcel Service Of America, Inc. | Systems and methods for generating source code for workflow platform |
US9182981B2 (en) * | 2009-11-23 | 2015-11-10 | University Of Washington | Systems and methods for implementing pixel-based reverse engineering of interface structure |
US20120084110A1 (en) * | 2010-10-05 | 2012-04-05 | M3 Technology, Inc. | System and method for smart oil, gas and chemical process scheduling |
US10140320B2 (en) | 2011-02-28 | 2018-11-27 | Sdl Inc. | Systems, methods, and media for generating analytical data |
US9984054B2 (en) | 2011-08-24 | 2018-05-29 | Sdl Inc. | Web interface including the review and manipulation of a web document and utilizing permission based control |
US8751291B2 (en) * | 2012-01-05 | 2014-06-10 | General Electric Comany | Economic analysis of grid infrastructure |
US20140324662A1 (en) * | 2013-03-15 | 2014-10-30 | Open Access Technology International, Inc. | Systems and Methods for Trading Electrical Power |
US20140330602A1 (en) * | 2013-05-01 | 2014-11-06 | Ilya William Slutsker | Method for Multi Entity Scheduling Object Visibility and Control |
WO2014201459A1 (en) * | 2013-06-14 | 2014-12-18 | Aquilon Energy Services, Inc. | Energy collaboration platform |
JP6461167B2 (en) | 2014-01-21 | 2019-01-30 | オラクル・インターナショナル・コーポレイション | System and method for supporting multi-tenancy in an application server, cloud or other environment |
US10803054B2 (en) | 2014-02-03 | 2020-10-13 | Oracle International Corporation | Dynamically building a database query by combining a static query clause with a user-specified filter |
US10503713B1 (en) | 2014-05-19 | 2019-12-10 | Amazon Technologies, Inc. | Criterion-based retention of data object versions |
US10528536B1 (en) | 2014-05-19 | 2020-01-07 | Amazon Technologies, Inc. | Managing data object versions in a storage service |
US10152605B2 (en) * | 2014-05-21 | 2018-12-11 | Siddharth Shetye | Systems and methods for front-end and back-end data security protocols |
US10318280B2 (en) | 2014-09-24 | 2019-06-11 | Oracle International Corporation | System and method for supporting patching in a multitenant application server environment |
EP3198431A1 (en) | 2014-09-24 | 2017-08-02 | Oracle International Corporation | System and method for supporting patching in a multitenant application server environment |
US9930129B2 (en) * | 2014-09-24 | 2018-03-27 | Oracle International Corporation | System and method for java EE and java SE proxy data sources in a multitenant application server environment |
US10250512B2 (en) | 2015-01-21 | 2019-04-02 | Oracle International Corporation | System and method for traffic director support in a multitenant application server environment |
IN2015CH01314A (en) * | 2015-03-17 | 2015-04-10 | Wipro Ltd | |
US10460015B1 (en) * | 2015-03-27 | 2019-10-29 | Open Text Corporation | Assimilation in multi model webpage composition |
AU2015201823A1 (en) * | 2015-04-10 | 2016-10-27 | Energy One Limited | A system and method for facilitating management of business operations |
US11164248B2 (en) | 2015-10-12 | 2021-11-02 | Chicago Mercantile Exchange Inc. | Multi-modal trade execution with smart order routing |
US11288739B2 (en) | 2015-10-12 | 2022-03-29 | Chicago Mercantile Exchange Inc. | Central limit order book automatic triangulation system |
US11086751B2 (en) | 2016-03-16 | 2021-08-10 | Asg Technologies Group, Inc. | Intelligent metadata management and data lineage tracing |
US11847040B2 (en) | 2016-03-16 | 2023-12-19 | Asg Technologies Group, Inc. | Systems and methods for detecting data alteration from source to target |
US11775136B2 (en) | 2016-04-27 | 2023-10-03 | Coda Project, Inc. | Conditional formatting |
US10545952B2 (en) * | 2017-01-31 | 2020-01-28 | Xactly Corporation | Multitenant architecture for prior period adjustment processing |
US11057500B2 (en) | 2017-11-20 | 2021-07-06 | Asg Technologies Group, Inc. | Publication of applications using server-side virtual screen change capture |
US10812611B2 (en) | 2017-12-29 | 2020-10-20 | Asg Technologies Group, Inc. | Platform-independent application publishing to a personalized front-end interface by encapsulating published content into a container |
US11611633B2 (en) | 2017-12-29 | 2023-03-21 | Asg Technologies Group, Inc. | Systems and methods for platform-independent application publishing to a front-end interface |
US10877740B2 (en) | 2017-12-29 | 2020-12-29 | Asg Technologies Group, Inc. | Dynamically deploying a component in an application |
CN109032566B (en) * | 2018-06-22 | 2022-04-26 | 深圳探科技术有限公司 | Decoupling method and device of software logic layer and communication layer |
CN108961039B (en) * | 2018-07-02 | 2023-03-31 | 创新先进技术有限公司 | Transaction processing method, device and system |
US11159046B1 (en) | 2018-12-21 | 2021-10-26 | Smart Wires Inc. | Dynamic computation and control of distributed assets at the edge of a power grid |
US11762634B2 (en) * | 2019-06-28 | 2023-09-19 | Asg Technologies Group, Inc. | Systems and methods for seamlessly integrating multiple products by using a common visual modeler |
US20210065317A1 (en) | 2019-08-30 | 2021-03-04 | EnergyXchain, LLC | Managing energy transactions using distributed ledger technology |
US11941137B2 (en) | 2019-10-18 | 2024-03-26 | Asg Technologies Group, Inc. | Use of multi-faceted trust scores for decision making, action triggering, and data analysis and interpretation |
US11269660B2 (en) | 2019-10-18 | 2022-03-08 | Asg Technologies Group, Inc. | Methods and systems for integrated development environment editor support with a single code base |
US11055067B2 (en) | 2019-10-18 | 2021-07-06 | Asg Technologies Group, Inc. | Unified digital automation platform |
US11886397B2 (en) | 2019-10-18 | 2024-01-30 | Asg Technologies Group, Inc. | Multi-faceted trust system |
US11693982B2 (en) | 2019-10-18 | 2023-07-04 | Asg Technologies Group, Inc. | Systems for secure enterprise-wide fine-grained role-based access control of organizational assets |
CN110992175A (en) * | 2019-10-30 | 2020-04-10 | 成都摩宝网络科技有限公司 | Asynchronous accounting and transaction separation method and system based on message middleware |
US11563563B2 (en) * | 2019-11-07 | 2023-01-24 | Sap Se | SQL extension for secure encryption key transfer |
US11030299B1 (en) | 2020-01-27 | 2021-06-08 | Capital One Services, Llc | Systems and methods for password managers |
US20210256635A1 (en) | 2020-02-17 | 2021-08-19 | EnergyXchain, LLC | Creating, monitoring, and updating energy transactions using distributed ledger technology and contract codex |
WO2021167985A1 (en) * | 2020-02-17 | 2021-08-26 | EnergyXchain, LLC | Creating, monitoring, and updating energy transactions using distributed ledger technology and contract codex |
CN111369221B (en) * | 2020-03-09 | 2023-07-04 | 浙江大学 | Intelligent contract monitoring method and system for block chain supervision |
WO2022081476A1 (en) | 2020-10-13 | 2022-04-21 | ASG Technologies Group, Inc. dba ASG Technologies | Geolocation-based policy rules |
CN112860454B (en) * | 2021-02-05 | 2024-04-19 | 百果园技术(新加坡)有限公司 | Service processing system and method |
US20230032090A1 (en) * | 2021-07-29 | 2023-02-02 | International Business Machines Corporation | Data traffic prioritization based on content |
CN113628025B (en) * | 2021-08-26 | 2024-04-09 | 深圳市易流科技股份有限公司 | Bill generation method and device, computer equipment and storage medium |
US20230108202A1 (en) * | 2021-10-05 | 2023-04-06 | Saudi Arabian Oil Company | Optimization tool for sales gas supply, gas demand, and gas storage operations |
WO2023183380A1 (en) * | 2022-03-23 | 2023-09-28 | Schlumberger Technology Corporation | System and method for excess gas utilization |
CN114780064B (en) * | 2022-04-12 | 2024-04-16 | 四三九九网络股份有限公司 | Form design method of zero code platform |
CN114827065B (en) * | 2022-04-28 | 2024-02-23 | 抖动科技(深圳)有限公司 | Real-time communication method based on unified communication channel and related equipment |
CN115098755A (en) * | 2022-06-20 | 2022-09-23 | 国网甘肃省电力公司电力科学研究院 | Scientific and technological information service platform construction method and scientific and technological information service platform |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5457797A (en) * | 1993-08-03 | 1995-10-10 | Forte Software, Inc. | Flexible multi-platform partitioning for computer applications |
US5794212A (en) * | 1996-04-10 | 1998-08-11 | Dominion Resources, Inc. | System and method for providing more efficient communications between energy suppliers, energy purchasers and transportation providers as necessary for an efficient and non-discriminatory energy market |
US5893079A (en) * | 1994-12-13 | 1999-04-06 | Fs Holdings, Inc. | System for receiving, processing, creating, storing, and disseminating investment information |
US6115698A (en) * | 1995-08-18 | 2000-09-05 | Continental Power Exchange, Inc. | Apparatus and method for trading electric energy |
US6236977B1 (en) * | 1999-01-04 | 2001-05-22 | Realty One, Inc. | Computer implemented marketing system |
Family Cites Families (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7340426B1 (en) * | 1999-07-30 | 2008-03-04 | Computer Sciences Corporation | Event-triggered transaction processing for electronic data interchange |
US20020019802A1 (en) * | 2000-08-07 | 2002-02-14 | Ross Malme | System and methods for aggregation and liquidation of curtailment energy resources |
-
2002
- 2002-06-13 US US10/480,335 patent/US8065219B2/en active Active
- 2002-06-13 AU AU2002322090A patent/AU2002322090A1/en not_active Abandoned
- 2002-06-13 WO PCT/US2002/018781 patent/WO2002101510A2/en not_active Application Discontinuation
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5457797A (en) * | 1993-08-03 | 1995-10-10 | Forte Software, Inc. | Flexible multi-platform partitioning for computer applications |
US5893079A (en) * | 1994-12-13 | 1999-04-06 | Fs Holdings, Inc. | System for receiving, processing, creating, storing, and disseminating investment information |
US6115698A (en) * | 1995-08-18 | 2000-09-05 | Continental Power Exchange, Inc. | Apparatus and method for trading electric energy |
US5794212A (en) * | 1996-04-10 | 1998-08-11 | Dominion Resources, Inc. | System and method for providing more efficient communications between energy suppliers, energy purchasers and transportation providers as necessary for an efficient and non-discriminatory energy market |
US6236977B1 (en) * | 1999-01-04 | 2001-05-22 | Realty One, Inc. | Computer implemented marketing system |
Cited By (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2004057825A3 (en) * | 2002-12-23 | 2004-09-16 | Sema | Method for communication between servers with data format conversion and device therefor |
WO2004057825A2 (en) * | 2002-12-23 | 2004-07-08 | Sema | Method for communication between servers with data format conversion and device therefor |
CN1308880C (en) * | 2003-03-31 | 2007-04-04 | 台湾积体电路制造股份有限公司 | Technology main file document hold-down bar structure management system and method and semiconductor product and its mangment method |
US10678607B2 (en) | 2003-11-24 | 2020-06-09 | Ebay Inc. | API and business language schema design framework for message exchanges |
US11556397B2 (en) | 2003-11-24 | 2023-01-17 | Ebay Inc. | API and business language schema design framework for message exchanges |
US10275291B2 (en) | 2003-11-24 | 2019-04-30 | Ebay Inc. | API and business language schema design framework for message exchanges |
US7483757B2 (en) | 2005-07-22 | 2009-01-27 | Honeywell International, Inc. | Control system migration |
GR20060100249A (en) * | 2006-04-27 | 2007-11-15 | Βασιλειος Γεωργιου Νικολοπουλος | Web-based energy search machine and method for decision making on the optimal management and pricing evaluation of energy resources. |
US10417719B2 (en) | 2015-02-23 | 2019-09-17 | Nec Corporation | Electric energy adjustment apparatus, system, method and program |
WO2016135771A1 (en) | 2015-02-23 | 2016-09-01 | Nec Corporation | Electric energy adjustment apparatus, system, method and program |
US20210312547A1 (en) * | 2020-04-01 | 2021-10-07 | Xi'an Jiaotong University | Multi-energy trading and management platform based on blockchain |
CN116542698A (en) * | 2023-07-06 | 2023-08-04 | 厦门美契信息技术有限公司 | Enterprise customized intelligent development management platform |
CN116542698B (en) * | 2023-07-06 | 2023-09-08 | 厦门美契信息技术有限公司 | Enterprise customized intelligent development management platform |
Also Published As
Publication number | Publication date |
---|---|
AU2002322090A1 (en) | 2002-12-23 |
WO2002101510A3 (en) | 2003-10-30 |
WO2002101510B1 (en) | 2003-11-27 |
US8065219B2 (en) | 2011-11-22 |
US20060036448A1 (en) | 2006-02-16 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8065219B2 (en) | System architecture and method for energy industry trading and transaction management | |
US11636413B2 (en) | Autonomic discrete business activity management method | |
US8032461B2 (en) | Method and system for facilitating, coordinating and managing a competitive marketplace | |
US7693854B2 (en) | Two-pass harmonized tariff schedule classification | |
US8060553B2 (en) | Service oriented architecture for a transformation function in a data integration platform | |
US7814470B2 (en) | Multiple service bindings for a real time data integration service | |
US8041760B2 (en) | Service oriented architecture for a loading function in a data integration platform | |
US7814142B2 (en) | User interface service for a services oriented architecture in a data integration platform | |
US20050187866A1 (en) | Method and system for executing financial transactions via a communication medium | |
AU2002258901B2 (en) | System and method for travel carrier contract management and optimization | |
US20060010195A1 (en) | Service oriented architecture for a message broker in a data integration platform | |
US20050223109A1 (en) | Data integration through a services oriented architecture | |
US20050240592A1 (en) | Real time data integration for supply chain management | |
US20050228808A1 (en) | Real time data integration services for health care information data integration | |
US20050222931A1 (en) | Real time data integration services for financial information data integration | |
US20050262189A1 (en) | Server-side application programming interface for a real time data integration service | |
US20060069717A1 (en) | Security service for a services oriented architecture in a data integration platform | |
US20050240354A1 (en) | Service oriented architecture for an extract function in a data integration platform | |
US20050232046A1 (en) | Location-based real time data integration services | |
US20050234969A1 (en) | Services oriented architecture for handling metadata in a data integration platform | |
US20050262190A1 (en) | Client side interface for real time data integration jobs | |
US20050235274A1 (en) | Real time data integration for inventory management | |
US20070265862A1 (en) | Software model business process variant types | |
US7970731B2 (en) | Enhanced trade compliance system: country of origin certifications | |
US7987209B2 (en) | Enhanced trade compliance system: mass amendment |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AK | Designated states |
Kind code of ref document: A2 Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PH PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW |
|
AL | Designated countries for regional patents |
Kind code of ref document: A2 Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG |
|
121 | Ep: the epo has been informed by wipo that ep was designated in this application | ||
B | Later publication of amended claims |
Free format text: 20030606 |
|
REG | Reference to national code |
Ref country code: DE Ref legal event code: 8642 |
|
122 | Ep: pct application non-entry in european phase | ||
ENP | Entry into the national phase |
Ref document number: 2006036448 Country of ref document: US Kind code of ref document: A1 |
|
WWE | Wipo information: entry into national phase |
Ref document number: 10480335 Country of ref document: US |
|
WWP | Wipo information: published in national office |
Ref document number: 10480335 Country of ref document: US |
|
NENP | Non-entry into the national phase |
Ref country code: JP |
|
WWW | Wipo information: withdrawn in national office |
Country of ref document: JP |