1 / 80

MarkeTrak Enhancements Conceptual Design Review

MarkeTrak Enhancements Conceptual Design Review. Presented By ERCOT. PR70007_01: ERCOT Conceptual Design Overview. Overview: The ERCOT Conceptual Design Overview provides high-level details for the conceptual design approach with system and user impacts identified. Objective:

doli
Télécharger la présentation

MarkeTrak Enhancements Conceptual Design Review

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. MarkeTrak EnhancementsConceptual Design Review Presented By ERCOT

  2. PR70007_01: ERCOT Conceptual Design Overview Overview: The ERCOT Conceptual Design Overview provides high-level details for the conceptual design approach with system and user impacts identified. Objective: The objective of the Conceptual Design Overview is to confirm consensus between ERCOT and Market Participants on conceptual design approach and provide system and user impacts to aide in planning of resources and schedules necessary for implementation.

  3. Requirement 1 Description: Make the order of all buttons consistent on all sub-types GUI • Changes: • Update will be made to put all buttons in the same order across all sub-types. Any button not active for the given state (workflow) will not appear. Buttons will display in the following order as determined by the Task Force: • Positive • Negative • System • User Impacts: • Push Buttons may appear in a different order than prior to implementation of MarkeTrak Phase 2 API – No changes Bulk Insert – No changes

  4. Requirement 2 Description: Create a Parent Project Type for DEV Issues GUI • Changes: • A new “DEV” parent project type will be added • User Impacts: • When a user goes to build a listing report in MarkeTrak, the Report Project field will list/show “DEV” as a parent to all the DEV issue types/sub-types. Selecting “DEV” in the Report Project field will allow the user to build a report against all DEV issue types/sub-types. API – No Change Bulk Insert – No Change

  5. Requirement 3 Description: Make all transitions consistent within MarkeTrak GUI • Changes: • Update workflows to consistently Implement the “Accept” and “Complete” Transitions • User Impacts: • Push button names will change to “Accept”, if not already named “Accept”, when transitioning from “Unexecutable (PC)” state to the “Complete” state. • Push button names will change to “Complete”, if not already named “Complete”, when transitioning from any “Pending Complete” state to “Complete” state.

  6. Requirement 3 - continued Description: Make all transitions consistent within MarkeTrak API • Changes • No change because transition is already in acceptable transition name permitted values. • User Impacts • Backend system may need to be updated to use the correct transition name when transitioning between “Unexecutable (PC)” and “Complete” states and any “Pending Complete” and “Complete” states Bulk Insert – No change

  7. Requirement 4 Description: Create Bulk Insert Templates and default Submit Validation Flags for API and Bulk Insert to “Off” GUI – No change API • Changes: • Update the validation flag elements of the API WSDL • User Impacts: • The API WSDL will assume “false” if any of these validation flags are null.

  8. Requirement 4 - continued Description: Create Bulk Insert Templates and default Submit Validation Flags for API and Bulk Insert to “Off” Bulk Insert • Changes: • Create Bulk Insert Templates and post to ERCOT website • Update processing flags to default to “Off” • User Impacts: • If any processing flag is “blank” the processing will assume validation is “Off”

  9. Requirement 5 Description: Add Bulk Insert Number to Issues GUI • Changes: • A new field will be added to all MarkeTrak workflows to provide the “Bulk Insert Parent Issue ID” • User Impacts: • A new read only field will appear in the Issue Information Section • If a user is looking at a “child” issue built via Bulk Insert, the field will be populated with the parent Bulk Insert Issue ID. • The field will be available for use in Report criteria and Report results.

  10. Requirement 5 - continued Description: Add Bulk Insert Number to Issues API • Changes: • Update API WSDL to support new field • User Impacts: • New field, BIParentIssue will appear in the QueryResponseIssuetype complex element of the API WSDL • Market Participant’s API backend systems may need to be modified to map the new element on Query Detail Response • Bulk Insert • No impact to the Bulk Insert process for Market Participants

  11. Requirement 6 Description: Modify Search Arrow next to ID Search GUI • Changes: • Modify the search arrow changing the color from grey to black • User Impacts: • The arrowhead icon to the right of the ID Search prompt window will now appear as a heavy black arrowhead. API – No change Bulk Insert – No change

  12. Requirement 7 Description: Do not allow changes to the Title Field on MarkeTrak Issues GUI • Changes: • Update the Create transition on all MarkeTrak workflow transitions to ensure the Title Field is “Read Only”. • User Impacts: • The user will no longer have the opportunity to change the default Issue type/sub-type text automatically populated into the Title field during Issue Create

  13. Requirement 7 - continued Description: Do not allow changes to the Title Field on MarkeTrak Issues API • Changes: Update API WSDL to remove the Title element on Submit Request and recompile with the updated WSDL • User Impacts: • User will no longer have the ability to send the Title element on Issue Submit Requests • Market Participant’s backend system may need to be modified to not map the deleted element on submit and update requests. Bulk Insert • Changes: Title field will be removed from all Bulk Insert Templates • User Impacts: Bulk Insert CSV files will no longer contain the Title field column. This will change the row length and number of fields.

  14. Requirement 8 Description: Do not capture Non-ERCOT Owner during “Begin Working” unless the owner field is empty GUI • Changes: • Script will be updated to assign non-ERCOT owner if the Issue’s current owner is zero. • User Impacts: • No functionality changes when a Company first hits the “Begin Working” transition. • Upon the second execution of the “Begin Working” transition by a Company User, the Company Owner will not change.

  15. Requirement 8 - continued Description: Do not capture Non-ERCOT Owner during “Begin Working” unless the owner field is empty API • Changes: • No changes • User Impacts: • Company Owner will not change upon any subsequent executions of “Begin Working” transition. • API using MP’s backend systems may need to be modified to not send “Assign Owner” transactions following subsequent “Begin Working” transitions. Bulk Insert – No change

  16. Requirement 9 Description: Require comments for Siebel Chg/Info Sub-types GUI • Changes: • Update the workflow to require comments • User Impacts: • When a user creates a Siebel Chg/Info issue in MarkeTrak, they will be required to enter comments before the Issue will successfully create. • An error message will appear if the user does not enter comments. API • Changes: Update API WSDL • User Impacts: • MP’s API backend systems may need to be modified to map the required field • Will require a recompile with the new WSDL

  17. Requirement 9 - continued Description: Require comments for Siebel Chg/Info Sub-types Bulk Insert • Changes: • Update the new Bulk Insert Templates to change comments to required • User Impacts: • Comments will be required and rows will fail if Comments are not populated • User will see Bulk Insert Validation errors if field is not populated

  18. Requirement 10 Description: Add Service Period Start/Stop Date Field to D2D Sub-types GUI • Changes: • Update the Missing Transaction, Projects, Siebel Chg/Info and Other workflows to add Service Period Start Date • Update Rep of Record and Usage to add Service Period Start Date and Service Period Stop Date • User Impacts: • User sees the Service Period Start Date on all above mentioned issue sub-types • Optional for Missing Tran, Projects, Siebel Chg/Info and Other • Required for Rep of Record and Usage/Billing • User sees the Service Period Stop Date for Rep of Record and Usage/Billing sub-types • optional fields • Help text will be provided for Stop Time

  19. Requirement 10 - continued Description: Add Service Period Start/Stop Date Field to D2D Sub-types API • Changes: • Update MarkeTrak API WSDL • User Impacts: • API Backend systems may need to be modified to map the new required/optional elements on submit and responses. • System will require recompile with the new WSDL. Bulk Insert • Changes: • Add 2 new columns to the D2D Bulk Insert Template with appropriate required/optional designations • User Impacts: • Rows will fail without required information • New templates will need to be incorporated into systems

  20. Requirement 11 Description: Add ISA field to Submit for 997, Projects, and Other sub-types GUI • Changes: • Update workflows in include new field • Optional for Projects and Other • Required for 997 • User Impacts: • User will see the ISA Number field and will have the option of populating it for Projects and Other but will be required to populate for 997 issues.

  21. Requirement 11 - continued Description: Add ISA field to Submit for 997, Projects, and Other sub-types API • Changes: • Update WSDL to support new field • User Impacts: • New ISA may appear in QueryResponseIssuetype complex element of the API WSDL • New field, ISA Num IssueSubmitRequest may appear as required/optional in the complex element of the API WSDL • MP’s API backend systems may need to be modified to map the new element on Query Detail Response and/or Issue Submit Request.

  22. Requirement 11 - continued Description: Add ISA field to Submit for 997, Projects, and Other sub-types Bulk Insert • Changes: • Add new column to the D2D Bulk Insert Template and make appropriate optional/required designations • Add validation for new field • User Impacts: • Templates will reflect new field • 997 rows will fail if the ISA Number is not populated • User will need to either modify their Bulk Insert file building programs or use the new templates to account for the new field

  23. Requirement 12 Description: Add new required field to the Reject Sub-type to provide Reject Reason GUI • Changes: • Update Reject Transaction workflow to add new required field • Change the comment field from optional to required • User Impacts: • User will be required to select reject code from a drop down list API • Changes: • Update WSDL to support new field • User Impacts: • New field will appear in QueryResponseIssuetype complex element of WSDL • Reject code and comments will be required in the IssueSubmitRequest complex element of the WSDL • MP’s backend system may need to be modified to map new element

  24. Requirement 12 - continued Description: Add new required field to the Reject Sub-type to provide Reject Reason Bulk Insert • Changes: • Add new column to the template to incorporate new field • Update to validation • Change comments column to required • User Impacts: • Row will fail without population of the Reject Code or Comments • Users will need to either modify their Bulk Insert file building programs or use the new templates to account for the new field on the D2D Bulk Insert type.

  25. Requirement 13 Description: Update Transaction Types during “Submit” and Add new Required Tran Type during “Re-assign” for Missing Transaction GUI • Changes: • Modify Missing Transaction Workflow to limit Tran Type choices as dictated by Market • Modify Re-assign transition to allow user to update Tran Type • User Impacts: • User will be restricted to limited Tran Type choices • User will be able to modify Tran Type during re-assign transition • User will be required to enter the Tran ID on the Complete transition • Help language will be provided for Original Tran ID

  26. Requirement 13 - continued Description: Update Transaction Types during “Submit” and Add new Required Tran Type during “Re-assign” for Missing Transaction API • Changes: • Modify WSDL to incorporate changes to Tran Type • User Impacts: • When creating a new Missing Tran sub-type issue, the API user will be limited by the valid values for Tran Type. • Backend API systems may need to be reviewed to insure all Tran Types are valid and that Tran ID is sent on “Complete” transition

  27. Requirement 13 - continued Description: Update Transaction Types during “Submit” and Add new Required Tran Type during “Re-assign” for Missing Transaction Bulk Insert • Changes: • Update to validations for Tran Types • User Impacts: • User may see new validation error regarding permitted values • User may need to modify Bulk Insert file building program to ensure proper use of permitted Tran Types

  28. Requirement 14 Description: Add columns to Escalation Email Attachment Other • Changes: • Add new output columns and column headings • User Impacts: • Companies Primary and Secondary Escalation contacts per sub-type will see the addition of 6 new columns on the Escalation email Escalation report. • Columns will be left blank if no Owner is assigned or if the owner field is not applicable to the row’s Issue sub-type.

  29. Requirement 15 Description: Validate ESI ID/TDSP Association GUI and API • Changes: • Add validation to verify TDSP/ESI ID association on issues • User Impacts: • Users during Issue Submit may be presented with a new warning message if the TDSP returned from ERCOT’s Registration System for the ESI ID involved does not match the TDSP on the Issue being submitted. Bulk Insert • Changes: • Update Bulk Insert Template to incorporate validation • User Impacts: • Bulk insert will assume validation is “off” • Users will need to either modify their Bulk Insert file building programs or use the new templates to account for the new field.

  30. Requirement 16 Description: Changes to Usage and Billing Sub-type GUI • Changes/User Impacts: • Users will be limited to the pre-designated drop down list of “Tran Type” during submit • User will be required to select IDR or NIDR from drop down during Submit • Original Tran ID will be Optional except for 867_03 Finals • Error will be returned if not populated for “867_03 Final” • Add help language to Original Tran ID • User will be required to select Dispute or Missing from drop down during Submit (Cont.)

  31. Requirement 16 - continued Description: Changes to Usage and Billing Sub-type GUI • Changes/User Impacts: (Cont.) • User will be required to populate Transaction Date Required • User will be required to populate new “Tran ID” field on “Complete” transition for Missing • User will be required to populate new “Tran ID” field on “Submit” for Dispute API • Changes: • Modify WSDL to incorporate all field changes • User Impacts: • Backend API Systems may need to be reviewed to ensure compliance with all field changes

  32. Requirement 16 - continued Description: Changes to Usage and Billing Sub-type Bulk Insert • Changes: • Bulk Insert Templates will be updated to incorporate all changes • User Impacts: • Rows will fail if required or valid information not provided according to field changes

  33. Requirement 17 Description: Reporting Improvements GUI • Changes: • Design process flow, similar to Bulk Insert’s, that will allow user to select, from a drop down list, a report to be executed. • Once User selects the report, enters any report parms and hits submit, the report request will be passed to a backend system • Backend system will execute the report and generate results in a CSV format that will be written to a file and sent to MID/MIR for posting to TML. • A URL link will be added to the Report Issue that will link to TML’s Report Explorer. This will be added to Bulk Insert also • User Impacts: • If a user wants to view all rows of a report greater than 3,000 rows, the user should use the “Background Report” workflow type in MarkeTrak

  34. Requirement 18 Description: Standardize Sub-type names within DEV LSE Issues GUI • Changes/User Impacts: • User will see “LSE in MP sys no ERCOT: De-engz” in Project names lists instead of “LSE in MP sys not ERCOT: inactiv” • All new “LSE in MP sys not ERCOT: De-engz” issues will have a default title field of “LSE Relationship record present in MP System, not in ERCOT: De-energized” API • Changes/User Impacts: • Update to WSDL • Users will see new Sub Type name returned with Issue Detail responses Bulk Insert • Changes/User Impacts: • User will be presented with “de-energized” sub-type names instead of “inactive” sub-type names on the Create Issue screen

  35. Requirement 19 Description: Populate ERCOT Owner and Siebel Status/Sub-status on ERCOT Initiated Issues GUI • Changes/User Impacts: • Users will see new fields: “Siebel Status”, “Siebel Substatus”, “Last Siebel Status Retrieval Date” and “ERCOT Owner” in ERCOT Initiated Issue Information section. • Users will see a new push button called “Update Siebel Status/Substatus” on ERCOT Initiated Issues, that when (ESIID and Original Tran ID are populated) executed will retrieve the Issue Global ID’s Siebel Status/Substatus. API • User Impacts: • Users will see new fields: “Siebel Status”, “Siebel Substatus”, “Last Siebel Status Retrieval Date” and “ERCOT Owner” returned on ERCOT Initiated Issue Detail responses. Bulk Insert – No change

  36. Requirement 20 Description: Provide “First Touched Date” GUI • Changes/User Impacts: • “First Touched Date” will be added to all workflows and user will see this field in the Issue Information Section. • This field will either be blank or contain the date the Issue performed it’s first “Begin Working” transition API • Changes/User Impacts: • Update WSDL to support the new field • New field will appear in the QueryResponseIssuetype complex element • MP’s API backend systems may need to be modified to map the new element on Query Detail Response. Bulk Insert – No change

  37. Requirement 21 Description: Siebel Status/Sub-status Auto Update Upon Completion GUI • Changes: • Update “Complete” transition from “In Progress (Assignee)” state on Siebel Chg/Info and ERCOT initiated workflows to add auto Siebel Status update • User Impacts: • Users will see that the “Last Siebel Status Retrieval” date has changed to current date, when the ERCOT user transitioned the Siebel Chg/Info or ERCOT Initiated Issue from “In Progress (Assignee)” using the “Complete” transition. API – No change Bulk Insert – No change

  38. Requirement 22 Description: Validation of CR for Siebel Change Issues GUI • Changes • MarkeTrak will validate that the issue submitter or assignee is the CR associated with the ESI ID in the ERCOT Registration Database • User Impacts: • During Submit users will receive error if CR requested to be involved in the issue differed from what ERCOT’s Registration System has as the CR involved with the GlobalID and issue will not be submitted

  39. Requirement 22 - continued Description: Validation of CR for Siebel Change Issues API • Changes: • Update to WSDL • User Impacts: • Error returned • API Users will only see error if ValidateCRAssociation is turned on – defaults to “False” if blank. Bulk Insert • Changes: • Bulk Insert Templates will be updated to incorporate validation • User Impacts: • Bulk Insert Siebel Change rows will fail if the CR Validation flag is “true” and ERCOT’s Registration System doesn’t match chosen CR Issue DUNS.

  40. Requirement 23 Description: Add ability to turn on/off Automation for IAG and DEV • Changes: • ERCOT will be able to turn off Adapter calls and workflow automation if necessary. • User Impacts: • No Market User impact.

  41. Requirement 24 Description: Change the layout of the DEV Analysis Fields on GUI Screen for applicable DEV LSE Sub-types GUI • Changes: • Changes made to the layout of DEV Analysis fields • User Impacts: • User may notice field order changes on DEV LSE sub-types • Users will now see the following fields on DEVLSE sub-types in ERCOT Systems not MP • “Usage Matches Date Requested” instead of “Row Exists at ERCOT” • “Usage Loaded for Date Requested” instead of “Usage Exists for Time Period” • Users should use “Usage Matches Date Requested” instead of “Row Exists at ERCOT” and “Usage Loaded for Date Requested” instead of “Usage Exists for Time Period” on all “DEV LSE in ERCOT system not MP” Issue reports.

  42. Requirement 24 - continued Description: Change the layout of the DEV Analysis Fields on GUI Screen for applicable DEV LSE Sub-types API • Changes: • User Impacts: • Backend systems should expect “RowExistsERCOT” and “UsageExistsForTimePeriod” to now appear in “UsageLoadedDateReq” field on all “DEV LSE in ERCOT system not MP” Issue Responses. • Backend systems should not use “RowExistsERCOT” field and “UsageExistsForTimePeriod” field, but use “UsageMatchesDateReq” field and “UsageLoadedDateReq” field (respectively) on all “DEV LSE in ERCOT system not MP” Issue Updates (if applicable to Issue Update request). Bulk Insert – No change

  43. Requirement 25 Description: Inadvertent Gain GUI • Changes: • Two new workflows will be added to the MarkeTrak Submit Tree under the D2D Parent to accommodate changes requested in this requirement. • Inadvertent Gains – Losing • Inadvertent Gains – Gaining • Multiple new fields and transitions as outlined in Requirement 25 • User Impacts: • Inadvertent Switch workflow will not be in the Submit Tree • Users will not be able to submit new Issues but will only be able to work existing Issues • Users will see the two new workflows • Users will see new fields and new transitions as outlined in Requirement 25

  44. Requirement 25 - continued Description: Inadvertent Gain API • Changes: • Modify WSDL to incorporate new fields and transitions • User Impacts: • Users will have two new IAG workflows, new fields to map and new transitions to code • Users will not be able to submit new Inadvertent Switch Issues • Users may see new validation error messages

  45. Requirement 25 - continued Description: Inadvertent Gain Bulk Insert • Changes: • Templates will be created to accommodate new workflows • User Impacts: • Users will see two new D2D sub-types on the D2D Bulk Insert submit table and table will no longer contain Inadvertent Switch • If Users backend systems generate Inadvertent Switch Issues they will need to be converted to generate Inadvertent Gain – Losing and Inadvertent Gain – Gaining

  46. Requirement 25 - continued Description: Inadvertent Gain Other • Changes: • Make changes to Escalations as stated in Requirement 25 • Add Auto Close to IAG Issues • User Impacts: • Responsible MP Primary and Secondary Inadvertent Escalation Contacts will see escalations on new IAG Issues according to rules defined in Requirement 25 • New IAG Issues will Auto Close as stated in Requirement 25

  47. Requirement 26 Description: Premise Type Field GUI • Changes: • Update MarkeTrak workflows to automatically populate the Premise Type when an ESI ID is provided on an issue • User Impacts: • All workflows with an ESI ID defined will now automatically populate and display the “Premise Type” • Any workflow that required “Premise Type” is now not applicable • Any workflow allowing input of Premise Type will now enforce permitted values (ERCOT Initiated and Premise Type (Req. 37)

  48. Requirement 26 - continued Description: Premise Type Field API • Changes: • Update WSDL • User Impacts: • Users should ensure that their API backend systems do not send Premise Type on Issues Submit. • API backend systems should also be prepared to receive Premise Type in API responses of Issues that contain an ESI ID Bulk Insert • Changes/User Impacts: • Templates will no longer be available on the DEV Existence Bulk Insert Table • Premise Type field will be validated against permitted values in ERCOT Initiated and Premise Type Issues

  49. Requirement 27 Description: Add Close capability for Submitting MP for the Day to Day and Inadvertent Gain Workflows GUI • Changes: • Update workflows to incorporate “Close” transition and “Closed by Submitter” state • Add new transitions of “Complete” and “Unexecutable” to the “In Progress” State • User Impacts: • User will see new transition buttons on D2D and IAG Issues API • Changes: • Update WSDL • User Impacts: • User backend systems may need to be updated to enable the sending of the “Close” transition Bulk Insert – No change

  50. Requirement 28 Description: Various Changes to Cancel with Approval GUI • Changes/User Impacts: • Users will be presented with new fields, updated/new transitions, and warning messages as outlined in Requirement 28 API • Changes: • Update to WSDL • User Impacts: • Users may see error messages returned if validations are turned on • Backend systems may need to be reviewed to ensure they have the ability to send the new field and updated transition, if desired. • Backend systems may need to be updated to handle the addition of “Priority” and “SMRD” fields returned.

More Related