F.09 Trades & Auctions First Gas GTAC Transaction Management System. Version 2.0A

Transcription

1 F.09 Trades & Auctions First Gas GTAC Transaction Management System Version 2.0A

2 Table of Contents 1. F Trade of Gas (Prearranged) Process Request Trade Update Trade Trade Request Pending / To Do List Review Trade Accept Trade / Calculate Mismatches Reject Trade / Trade Request Rejected Calculations Business Functions GD.0033 Daily Contract Location Inventory - Swap PA.0005 Todo List Reports Schedules Interfaces OB Send Trade Pending Request Notification SMS OA Send Pending Request Notification OB Send Trade Request Rejected Notification SMS OA Send Trade Request Rejected Notification F Trade of Gas (EMS) Process Place Sell / Buy Order; Match and finalise trades Push data to FG / Trade Data Review EMS trades Trade Date Published Trade is adjusted / voided; Update trade in EC Calculations Business Functions GD.0032 Daily Contract Location Inventory Reports Schedules Interfaces ID EMS Trade to Energy Components 15 2 of 32

3 3. F Trade of Priority Rights (Prearranged) Request Trade Update Trade Trade Request Pending / To Do List Review Trade Accept Trade Reject Trade / Trade Request Rejected Calculations Business Functions GD.0033 Daily Contract Location Inventory Swap PA.0005 Todo List Reports Schedules Interfaces F Conduct Priority Rights Auction Process Create Priority Rights Set Auction Terms Review Auction Terms Cancel Auction Issue Notification Submit Bid Award Bids Issue Notification Review Auction Results Calculations Business Functions CO.2044 Contract Capacity GD.0054 Maintain Capacity Release GD.0055 Maintain Capacity Release Details GD.0056 Maintain Capacity Bid GD.0058 Capacity Release - Internal GD.0059 Capacity Release Result Reports Schedules 30 3 of 32

4 4.6 Interfaces OB Send Auction Notification SMS OA Send Auction Notification OB Send Auction Result Notification SMS OA Send Auction Result Notification of 32

5 1. F Trade of Gas (Prearranged) 1.1 Process F.09.1 Trade of Gas (Prearranged) Party A Energy Components Party B Request Trade Daily Contract Location Inventory - Swap GD.0033 Send Trade Pending Request SMS OA OB Changes required? To Do List DS.0001 Review Trade Yes Update Trade Accept? Yes No No Trade Date published? Daily Contract Location Inventory - Swap GD.0033 Accept Trade Yes Update Running Mismatch CALC-03 Alloc (Washup) CALC-02 SMS OA OB Send Trade Request Rejected Daily Contract Location Inventory - Swap GD.0033 Reject Trade Request Trade Parties may agree to sell, purchase or transfer gas from time to time, and these traded quantities must be recorded in EC as it will impact the calculation of mismatches for the relevant parties. Parties that may trade gas include Shippers with TSA agreements, Interconnect Parties with OBA agreements, and First Gas (under a TSA agreement) Party A (noting this may be the seller or buyer) will Request a Trade by creating a new record on the Daily Contract Location Inventory Swap screen: 5 of 32

6 Contract Inventory (Mandatory, Navigator) o Value: Gas From Contract (Mandatory, Navigator) o Value: TSA or OBA contract belonging to Party A To Contract (Mandatory, Editable) o Value: TSA or OBA contract Trade Quantity (Mandatory, Editable) o Value: Quantity of GJ o Only whole numbers allowed o Positive Value is Purchase by Party A from Party B o Negative Value is Sale from Party A to Party B Requested Trade Date (Mandatory, Editable) o Value: Date and Time When the user saves the record, the following is updated: Requested Trade Date (Mandatory, Editable) o If entered value is for future date, update time to be 0100 o If entered on today s date, update time to be next consecutive hour Status o Value: Provisional When the user has filled in all relevant details, they can Submit the request via a context menu, and the following fields are updated: Status o Value: Requested Submitted Timestamp (Mandatory, Not Editable) o System generated timestamp of when Party A submits the release When the release is submitted, validation must be taken to ensure that both parties contracts are valid at the Requested Trade Date Update Trade If Party A needs to make changes after the trade is submitted, they must update the status to Provisional, make the required changes, and resubmit via a context menu Trade Request Pending / To Do List When a new trade is submitted, the system will: Generate a notification Trade Request Pending to be sent to Party B by or SMS o The will include a link to the Daily Contract Location Inventory Swap screen for Party B to review the trade request Add an item to Party B s To Do List which is visible on their Dashboard 6 of 32

7 1.1.4 Review Trade Party B can review the record on the Daily Contract Location Inventory Swap screen and either accept or reject the trade via a context menu. The Trade Status will be updated accordingly (Accepted or Rejected) Accept Trade / Calculate Mismatches If Party B accepts the bid, neither Party A or B will be able to edit the record. First Gas system administrator will be able to edit record if necessary. If the Requested Trade Date is for a day that has not been published by First Gas, the trade will be included when calculating the running mismatch and the official daily mismatch for both Party A and Party B. If the Requested Trade Date is for a day that has been published by First Gas, the trade quantities will be included in the Allocation (Washup) process. As this is market sensitive data, only daily figures (traded, starting position) for a shipper should be made public, or hourly figures for all shippers aggregated Reject Trade / Trade Request Rejected If Party B rejects the bid, neither Party A or B will be able to edit the record. First Gas system administrator will be able to edit record if necessary. The system will generate a notification Trade Request Rejected to be sent to Party A by or SMS. 1.2 Calculations N/a 7 of 32

8 1.3 Business Functions GD.0033 Daily Contract Location Inventory - Swap Screenshot Description This business function is used to swap inventory on a contract or between contracts. Many pipeline operators allow the Shippers to store part of their gas in the pipeline itself. If they do that the shipper have an inventory on the pipeline. This can be achieved in different ways, but the most common one is to deliver more into the pipeline that what is taken out. Another way of getting an increase or decrease in the inventory is to trade or swap inventory. The process trading/swapping is often individual to each pipeline. Validation n/a 8 of 32

9 1.3.2 PA.0005 Todo List Screenshot Description This screen is personal to the current user and list all manual task assigned to this user either by the username or one of the roles mapped to the user. A manual task might be configured to include variables that should be applied to the execution context. Manual tasks are only created by a process definition through an active process instance. So there is no insert functionality in this screen. The tasks are categorized into: Available: All on going tasks pre-assigned or assigned to current user, or pre-assigned to a role the current user has. Completed: All tasks completed by current user. Note it only shows completed tasks in active process instances. Exceptional: All exceptional tasks assigned to current user. Exceptional tasks includes failed, error, exited and obsolete tasks. Validation n/a 1.4 Reports n/a 1.5 Schedules n/a 9 of 32

10 1.6 Interfaces OB Send Trade Pending Request Notification SMS This interface provides the messaging through MHM to First Gas SMTP Server. First Gas SMTP Server will then base on its Distribution List to send out SMS request through another 3 rd part SMS broadcasting service to the targeted receiver. Interface Details ID Data Flow Name Producer Consumer Interface Pattern Trigger Frequency Comment OB Send trade pending request Notification SMS Energy Components Party B OB Outgoing Notification SMS Upon received request Event OA Send Pending Request Notification This interface provides the messaging through MHM to First Gas SMTP Server. First Gas SMTP Server will then base on its Distribution List to send out the Notification to the targeted receiver. Interface Details ID Data Flow Name Producer Consumer Interface Pattern Trigger Frequency Comment OA Send Pending Request Notification Energy Components Party B OA Outgoing Notification Upon received request Event OB Send Trade Request Rejected Notification SMS This interface provides the messaging through MHM to First Gas SMTP Server. First Gas SMTP Server will then base on its Distribution List to send out SMS request through another 3 rd part SMS broadcasting service to the targeted receiver. Interface Details ID Data Flow Name Producer Consumer Interface Pattern Trigger Frequency Comment OB Send trade request rejected Notification SMS Energy Components Party A OB Outgoing Notification SMS Upon rejected request Event 10 of 32

11 1.6.4 OA Send Trade Request Rejected Notification This interface provides the messaging through MHM to First Gas SMTP Server. First Gas SMTP Server will then base on its Distribution List to send out the Notification to the targeted receiver. Interface Details ID Data Flow Name Producer Consumer Interface Pattern Trigger Frequency Comment OA Send trade request rejected notification Energy Component Party A OA Outgoing Notification Upon rejected request Event 11 of 32

12 2. F Trade of Gas (EMS) 2.1 Process F.09.1 Trade of Gas (EMS) TSA / OBA / FG Energy Components emstradepoint Place Sell/ Buy Order Match and finalise trades Trade Data IC Yes Push data to FG? Review EMS trades Daily Contract Location Inventory GD.0032 Trade Date published? Yes No Update Running Mismatch CALC-03 Daily Contract Location Inventory GD.0032 Alloc (Washup) CALC-02 Trade is adjusted / voided? Yes Update trade in EC Trade Date published? Yes No Update Running Mismatch CALC-03 Alloc (Washup) CALC Place Sell / Buy Order; Match and finalise trades emstradepoint is an exchange providing electronic trading, settlement and market information for NZ natural gas industry participants. Parties that may trade gas include 12 of 32

13 Shippers with TSA agreements, Interconnect Parties with OBA agreements, and First Gas As this is market sensitive data, only daily figures (traded, starting position) for a shipper should be made public, or hourly figures for all shippers aggregated Push data to FG / Trade Data emstradepoint proposes to send trade data to Energy Components periodically to ensure that shipper, OBA and FG mismatches take into consideration quantities traded in the market. This is subject to consultation with market participants. If market participants do not agree that trade data can be sent to First Gas all trades will need to be entered manually by market participants. emstradepoint functionality is being built on the assumption that shippers will agree to data exchange Review EMS trades EC will process the incoming interface and display the data on the Daily Contract Location Inventory Swap screen for users to review: Contract Inventory (Mandatory, Navigator) o Value: Gas Trade ID (Optional, Editable) o Value: Trade ID received from EMS (string) Contract (Mandatory, Navigator value) o Value: TSA or OBA contract belonging to trading party Trade Quantity / Day (Mandatory, Editable) o Value: Quantity of GJ o Only whole numbers allowed o Positive Value is Purchase o Negative Value is Sale Trade Price (Optional, Editable) o $NZ / GJ o Prices will only be provided for First Gas trades Trade Start Date (Mandatory, Editable) o Value: Date and Time o Inclusive dates Trade End Date (Mandatory, Editable) o Value: Date and Time o Inclusive dates Reason (Optional, Editable) o First Gas will need to label FG trades with different reasons, to indicate when quantities purchased from the market are to be included in invoicing calculations. Status o Value: Received 13 of 32

14 2.1.4 Trade Date Published For each day of a trade: If the day has not been published by First Gas, the trade will be included when calculating the running mismatch and the official daily mismatch for the relevant parties. If the day has been published by First Gas, the trade quantities will be included in the Allocation (Washup) process Trade is adjusted / voided; Update trade in EC It is possible that a trade will be voided or adjusted in emstradepoint after the initial data has been sent to Energy Components. In these rare cases, a user from emstradepoint will be able to log into Energy Components and adjust or void trades. User can void a trade via a context menu onscreen, and the record status will be Voided User can adjust the trade quantity or date range and, on saving, the record status will be Adjusted 2.2 Calculations n/a 2.3 Business Functions GD.0032 Daily Contract Location Inventory Screenshot Description This business function is used to view different types of inventory and transaction on inventory for Contracts. In a dispatching environment, there can be several types of inventory for Contracts with transportation rights on a pipeline. 14 of 32

15 In the navigator, the user selects a level in the navigation model and the inventory type. It is optional to filter on location. The first tab shows a tabular view on the inventory level for each day in selected period in the navigator. The second tab will show the same data, but it will be displayed as a graph. The second data section in the first tab list all transaction on the inventory for selected day. Transactions can be several types like trading or swapping of imbalance. Validation N/A 2.5 Reports n/a 2.6 Schedules n/a 2.7 Interfaces ID EMS Trade to Energy Components This interface provides the data required for EC to capture any Trading done out of EC using EMS. The provided data consists of both parties that completed the Trade on EMS. It is assumed that Trade Confirmation submitted by EMS has not been validated. Once uploaded into EC, the Business Function validation will be triggered and show any warning/error information on the User Dashboard. It is under the assumption that First Gas is responsible for keeping the master code in sync between any external system codes in correlate to EC codes. This Interface will use EC Web Service RESTful API with JSON. In this configuration, EMS will push data into EC staging area, where it can be checked and pushed on into the EC classes. Interface Details ID Data Flow Name Producer Consumer Interface Pattern EC Class Trigger Frequency Comment ID EMS Trade to Energy Components EMS Energy Components ID RESTful API ZV_TRADE Upon received request Event Trade Information Attribute Type Description TRADE_ID VARCHAR(30) EMS unique Trade ID PARTY VARCHAR(30) Either Seller or Buyer of this trade PRICE NUMBER This is applicable where FG is one party CREATION_DATE DATE This is the time when the trade has been matched up in EMS 15 of 32

16 START_DATE DATE This is the start date when this trade is in effect (inclusive) END_DATE DATE This is the end date when this trade is in effect (inclusive) QTY NUMBER This is the quantity (in GJ), ve representing SELL, +ve representing BUY TOT_QTY NUMBER This is the total qty (in GJ) for the period Notes: Basic validation: There will be always 2 records per EMS TRADE_ID. The sample data below depicts a scenario where Party ABC sells 100 for 4 days starting from until , and party X and Y buy different quantities. There are 2 trade IDs created in EMS and the data will be sent across to EC as below: EMS1235,Party ABC,1.234, "T"17:09:59, , ,-75,-300 EMS1236,Party ABC,1.567, "T"17:09:59, , ,-25,-100 EMS1235,Party X,1.234, "T"17:09:59, , ,75,300 EMS1236,Party Y,1.567, "T"17:09:59, , ,25, of 32

17 3. F Trade of Priority Rights (Prearranged) 3.1 Process F.09.2 Trade of PR (Prearranged) Party A Energy Components Party B Request Trade Daily Contract Location Inventory - Swap GD.0033 Send Trade Pending Request SMS OA OB Changes required? To Do List DS.0001 Review Trade Yes Update Trade Accept? No Yes Daily Contract Location Inventory - Swap GD.0033 Accept Trade SMS OA OB Send Trade Request Rejected Daily Contract Location Inventory - Swap GD.0033 Reject Trade Request Trade Parties may agree to sell, purchase or transfer Priority Rights after an auction has occurred, and these traded quantities must be recorded in EC. Only after the trades have been approved (accepted or rejected by the counter party) the records will become available for the whole public. Party A (noting this may be the seller or buyer) will Request a Trade by creating a new record on the Daily Contract Location Inventory Swap screen: Contract Inventory (Mandatory, Navigator) o Value: Priority Rights From Contract (Mandatory, Navigator) o Value: TSA contract belonging to Party A To Contract (Mandatory, Editable) o Value: TSA contract Trade Quantity (Mandatory, Editable) o Value: Quantity of PR o Only whole numbers allowed o Positive Value is Purchase by Party A from Party B 17 of 32

18 o Negative Value is Sale from Party A to Party B Trade Price (Mandatory, Editable) o Value: Price Requested Trade Date (Mandatory, Editable) o Value: Date and Time Status o Value: Provisional When the user has filled in all relevant details, they can Submit the request via a context menu, and the following fields are updated: Status o Value: Requested Submitted Timestamp (Mandatory, Not Editable) o System generated timestamp of when Party A submits the release When the release is submitted, validation must be taken to ensure that both parties contracts are valid at the Requested Trade Date Update Trade If Party A need to make changes after the trade is submitted, they must update the status to Provisional, make the required changes, and resubmit via a context menu Trade Request Pending / To Do List When a new trade is submitted, the system will: Generate a notification Trade Request Pending to be sent to Party B by or SMS o The will include a link to the Daily Contract Location Inventory Swap screen for Party B to review the trade request Add an item to Party B s To Do List which is visible on their Dashboard Review Trade Party B can review the record on the Daily Contract Location Inventory Swap screen and either accept or reject the trade via a context menu. The Trade Status will be updated accordingly (Accepted or Rejected) Accept Trade If Party B accepts the bid, neither Party A or B will be able to edit the record. First Gas system administrator will be able to edit record if necessary Reject Trade / Trade Request Rejected If Party B rejects the bid, neither Party A or B will be able to edit the record. First Gas system administrator will be able to edit record if necessary. The system will generate a notification Trade Request Rejected to be sent to Party A by or SMS 3.2 Calculations n/a 18 of 32

19 3.3 Business Functions GD.0033 Daily Contract Location Inventory Swap See previous section PA.0005 Todo List See previous section 3.4 Reports n/a 3.5 Schedules n/a 3.6 Interfaces n/a 19 of 32

20 4. F Conduct Priority Rights Auction 4.1 Process F.09.2 Conduct Priority Rights Auction First Gas Energy Components Shippers Create Priority Rights Contract Capacity CO.2044 No Set Auction Terms Cancel Auction? Maintain Capacity Release x days prior to Auction Start GD.0054 Capacity Release Details GD.0055 Review Auction Terms Yes Cancel Auction Maintain Capacity Release GD.0054 Issue Notification Auction Start Maintain Capacity Bid GD SMS OA OB Submit Bid Auction End Award Bids Capacity Release - Internal GD.0058 Issue Notification SMS OA OB Capacity Release Result GD.0059 Review Auction Results Create Priority Rights First Gas will create a contract capacity on the Contract Capacity screen as follows: Contract Capacity Code (Mandatory, Editable) o Value: A meaningful, unique code e.g. PR_2019_ZONEA Contract Capacity Name (Mandatory, Editable) o Value: A meaningful name e.g. PR 2019 Zone A Start Date (Mandatory, Editable) o Value: The date when the PR will be effective from 20 of 32

21 End Date (Optional, Editable) o Value: The date when the PR will be effective to Contract Name (Mandatory, Editable) o Value: Select First Gas contract from list Location Name (Mandatory, Editable) o Value: Select location from list of Delivery Points Capacity Type (Optional, Editable) o Value: Priority Rights Location Name (Mandatory, Editable) o Value: Select location from list of Delivery Points Default Reserved Capacity (Optional, Editable) o Value: Quantity of Priority Rights Set Auction Terms First Gas will create a new Capacity Release for the Priority Auction on the Maintain Capacity Release screen as follows: Releasing Company (Mandatory, Navigator) o Value: First Gas Start Date (Mandatory, Editable) o Value: Start of Auction End Date (Mandatory, Editable) o Value: End of Auction Releasing Contract (Mandatory, Editable) o Value: First Gas Contract Releasing Type (Optional, Editable) o Value: PR Auction When the user saves to record, the Release Status is updated to Provisional and the user may enter additional details as follows: General Terms Tab: Biddable (Optional, Editable) o Value: Yes General Terms Tab: Allow Re-release (Optional, Editable) o Value: Yes Contract Capacity Tab: Contract Capacity (Optional, Editable) o Value: PR Contract Capacity that has been created Contract Capacity Tab: Max Qty (Optional, Editable) o Value: Quantity of Priority Rights for Auction Rate Tab: Min Rate (Optional, Editable) o Value: Reserve Price Recall/Reput Tab: Recall / Reput Method (Optional, Editable) o Value: Recallable and Reputable When all relevant details are completed, the user will submit the release and EC will perform the following validation checks: Auction duration should be no longer than 1 month 21 of 32

22 Auction start date should be the first business day in the month prior to the start of the PR Term If any check fail, the status will show Rejected and the user will need to update terms and resubmit. If all checks pass, the status will show Submitted and it will be visible to other users Review Auction Terms All users can see the terms of a submitted capacity release on the Capacity Release Details screen Cancel Auction If necessary, First Gas may cancel the auction on the Maintain Capacity Release screen: The Release Status will show Withdrawn Issue Notification EC will send a notification to all relevant parties x days prior to the Start of Auction. Relevant parties are all Shippers and the Interconnect Party for the delivery point The default timing for this notification is 20 business days, but may be shorter in exceptional circumstances Submit Bid To submit a bid, the user creates a record on screen and selects the Release to bid against. The initial status will be Provisional. Then the user can update details as follows: Rate Tab: Bid Quantity (Optional, Editable) o Value: Bid Quantity Rate Tab: Bid Rate (Optional, Editable) o Value: Bid Rate When all relevant details are completed, the user will submit the bid and EC will perform the following validation checks: Each shipper may submit up to 5 bids per PR Auction Each bid must be a different price (equal to or higher than the reserve price) If any check fail, the status will show Rejected and the user will need to update terms and resubmit. If all checks pass, the status will show Submitted and it will be visible to other users Award Bids After the auction has ended, First Gas can award bids on the Capacity Release Internal screen Issue Notification EC will send a notification to all relevant parties once First Gas has awarded bids. 22 of 32

23 Relevant parties are all Shippers and the Interconnect Party for the delivery point Review Auction Results After the auction has ended and bids have been awarded, all users can see the auction results on the Capacity Release Result screen. 4.2 Calculations n/a 4.3 Business Functions CO.2044 Contract Capacity Screenshot Description This business function is used to create and maintain contract capacity objects. For the First Gas implementation, the Priority Rights will be configured in EC as contract capacities. Each priority right will be configured to a specific location (delivery stream). Validation N/A 23 of 32

24 4.3.2 GD.0054 Maintain Capacity Release Screenshot Description This business function is used to create and maintain Priority Rights auction for shippers with transportation contracts on a location (delivery stream). The Priority Rights auction will be configured in EC as a capacity release. The capacity release can be prearranged, meaning the deal took place outside the system. But a capacity release can alternatively be made available to shippers for bidding. All bids are recorded in Maintain Capacity Bid (GD.0056). In the first data section a user can see all capacity releases for a selected period, Company (Shipper) and Contract (optional). In the bottom part the tabs represent different groups of data associated with the release. A capacity release follows a capacity release process where the release status tells the user where the release is at any given point in time. The release statuses available are (Note that these statuses are examples only) Provisional Not yet submitted. User able to update the release Submitted The release is validated and made visible to other users. The release is open Awarded The release is validated and completed. The release is closed Withdrawn The release is no longer valid. The release is closed. When a release is recalled it will get this status. Rejected The release has failed validation. User able to update release Expired The release did not get any bids or the bid(s) where not above minimum value. By pressing the new button, a new capacity release will be created. The first data section will then be made available for input. The release becomes provisional as soon as it is saved. Some validation 24 of 32

25 is done on save, but it is first when the release is submitted that a full validation is done. Based on the details on the release the validation can differ from release to release. If validation fails, the release will be rejected, and the validation error can be seen in the status description attribute. The user has to fix the problem and resubmit the release. If it is a prearranged release, the submit process will create the bid. The bid can be seen (and confirmed) in Maintain Capacity Bid (GD.0056). The user is only allowed to update or delete a release if it has status provisional or rejected. The exception is the recall/reput tab where the user can change the values after the release is submitted. To prevent other users from viewing release before they are submitted, row level security can be used. In the Location tab the locations popup can be limited to only show objects of specific interface classes. Validation N/A 25 of 32

26 4.3.3 GD.0055 Maintain Capacity Release Details Screenshot Description This business function is used to view details on Submitted Priority Right auctions (or capacity releases in EC). This is very similar to the Maintain Capacity Release (GD.0055) business function. But if the Maintain Capacity Release business function has row level security, this business function should not. Meaning, that data in this business function will be accessible for all users. It will only list releases that are submitted. Since this is a view only business function it will not be possible to insert, update or delete a capacity release. Validation N/A 26 of 32

27 4.3.4 GD.0056 Maintain Capacity Bid Screenshot Description This business function is used to create and maintain bids on submitted and biddable Priority Rights (capacity release(s) in EC) on a location (delivery stream). For more information on capacity release see Maintain Capacity Release (GD.0055). When a capacity release is available for auctioning (Submitted and biddable flag set), other users can create a bid against that capacity release. The bid must in general match the capacity release, but a bid can if possible have its own terms and conditions. In the first data section a user can see all bid(s) for the selected period, company and bid status (optional). The first data section gives the user a quick overview of the bid and by selecting a bid, more details about the bid will be visible in the next data section. Further individual terms and conditions about the bid can be seen in the tab control section at the bottom. A bid follows a bid process where the bid status tells the user where the bid is at any given point in time. The following bid statuses are available (Note that these statuses are examples only) Provisional Not yet submitted. User able to updated bid Pending Validation successful, but manual interaction is required The user needs to be checked if it is credit worthy Bid value must be calculated manually When a capacity release is prearranged the replacement company needs to confirm Submitted The bid is validated and made visible to other users. Awarded The trade period is over and this bid was awarded. Other users can see this bid 27 of 32

28 Closed The trade period is over and this bid was not awarded Rejected Validation failed on submit or rejected by user. User able to updated bid To create a new bid the user must press the new button. The form section will then be made available for input. The bid becomes provisional as soon as it is saved. No validation is done on save. When the user is ready to submit the bid he/she should press the submit button. The submit process will validate the bid and different bids can have different validation. If validation fails, the bid will be rejected and the validation error can be seen in the status description attribute. The user has to fix the problem and resubmit the bid. The submit process will also know if a bid is a matching bid. When it is a prearranged capacity release the releasing company would normally enter the bid into the system. When this is done the replacement company must confirm the bid by clicking the confirm button. To prevent users from viewing bid details for other users, row level security can be used. The user is only allowed to update or delete a bid if it has status provisional or rejected. The locations popup, in the location tab, can be limited to only show objects of specific interface classes. Validation N/A 28 of 32

29 4.3.5 GD.0058 Capacity Release - Internal Screenshot Description This business function is intended for awarding bids on Priority Rights auctions (configured as capacity releases in EC). The first data section will list all PR auctions for the selected period. By selecting a capacity release the next data section will list all bids for the selected release. The bid value is calculated when the bid is submitted and can be seen here. If it was not possible to calculate the bid value by the system, a user can manually enter a calculated value. A calculated value can also be adjusted if required. When the bid status is pending user interaction may be required: The shipper must be validated if it is credit worthy. Sometime terms and condition, on a release or a bid, makes is impossible for the system to calculate a bid value. This business function then allows a user to enter the bid value. Confirming a prearranged trade can only be done in the bid business function. The award process can be manually triggered from this business function by selecting a release and press the Award button. Additionally, a release can be cancelled by pressing the Cancel button. Validation N/A 29 of 32

30 4.3.6 GD.0059 Capacity Release Result Screenshot Description This business function is used to see the results of the award process on Priority Right auctions (configured as capacity releases in EC). As long as a PR auction is open, the bids are anonymous. As soon as the PR auction is over, and bid(s) are awarded, the winning bid(s) become public. The other bids are still anonymous. The first data section lists all priority right auctions that have been awarded for the selected period in the navigator. The second data section lists the details of the winning bid(s). Validation N/A 4.4 Reports n/a 4.5 Schedules n/a 30 of 32

31 4.6 Interfaces OB Send Auction Notification SMS This interface provides the messaging through MHM to First Gas SMTP Server. FirstGas SMTP Server will then base on its Distribution List to send out the Notification to the targeted receiver. Interface Details ID Data Flow Name Producer Consumer Interface Pattern Trigger Frequency Comment OB Send Auction Notification SMS Energy Components Shippers and ICP for the delivery point OB Outgoing Notification SMS Upon confirmation of auction Event OA Send Auction Notification This interface provides the messaging through MHM to First Gas SMTP Server. FirstGas SMTP Server will then base on its Distribution List to send out the Notification to the targeted receiver. The message body should include Del Points, Eff Date, Terms, Est Available Operational Capacity, Amount of PR to be auctioned, Reserve Price. Interface Details ID Data Flow Name Producer Consumer Interface Pattern Trigger Frequency Comment OA Send Auction Notification Energy Components Shippers and ICP for the delivery point OA Outgoing Notification Upon confirmation of auction Event OB Send Auction Result Notification SMS This interface provides the messaging through MHM to First Gas SMTP Server. First Gas SMTP Server will then base on its Distribution List to send out SMS request through another 3 rd part SMS broadcasting service to the targeted receiver. Interface Details ID Data Flow Name Producer Consumer Interface Pattern Trigger Frequency Comment OB Send Auction Result Notification SMS Energy Components Shippers and ICP for the delivery point OB Outgoing Notification SMS Upon confirmation of austion s result Event 31 of 32

32 4.6.4 OA Send Auction Result Notification This interface provides the messaging through MHM to First Gas SMTP Server. First Gas SMTP Server will then base on its Distribution List to send out the Notification to the targeted receiver. Interface Details ID Data Flow Name Producer Consumer Interface Pattern Trigger Frequency Comment OA Send Auction Result Notification Energy Component Shippers and ICP for the delivery point OA Outgoing Notification Upon confirmation of auction s result Event 32 of 32