Frequently Asked Questions

1) If a Market Participant opts to use the API as its main interface to the FasTrak tool, will there be one MP digital certificate used to authenticate the API requests or will each user requesting information via MP’s API need to have a username/password supplied within each request? Since the FasTrak API Interface is designed as a “programmatic” interface, there should only be one MP digital certificate Username/Password used to authenticate. Each MP will be assigned an API username. Only this username will have the permissions to interface via the API.

2) Can we have the business data requirements for ERCOT’s API made available? The business data requirements would be the application dependent information and structure needed to make the 5 major requests, (i.e. Create, Update, Request List, Request Info, and Bulk Insertion). The data requirements for the FasTrak API are contained in the XSDs (see attached).

FYI … the Bulk Insert process was included in the API Detail Design because the process will follow 80% of the same logic as the API XML documents. The key difference being how the information is made available to the Tibco process and how the response information is relayed back to the User.

3) Is the only option to upload attachments to use the “bulk insert” process via the web interface portal? The bulk insert is a GUI interface option that allows the user to create multiple issues by specifying a data file as the source. It facilitates the creating of multiple issues without the User having to create issues one at a time. Currently the only option (GUI, API, BULK) that allows data file attachments to issues is via GUI.

4) How will we view responses from the “bulk insert” process? The Bulk Insert process is designed as a “drop and go” process. It will expect the user to attach a source data file to an issue. Then later the User will pull a MIR report containing the create responses. This is outlined in the FasTrak Bulk Insert Detail Design document.

The Bulk Insert process was included in the API Detail Design because the process will follow 80% of the same logic as the API XML documents. The key difference being how the information is made available to the Tibco process and how the response information is relayed back to the User.

5) What are the differences between Request List and Request Information? API Request List will require search criteria in the Request and return a list of Issue numbers in the Response. API Request Information will require 1 Issue number in the Request and return the Issue details in the Response. Documentation corrections made. Sorry for the confusion

6) The XML response structure is not included in the API documentation : Process Design and Architecture for Project PR-50007 FasTrak (API and WebServices Interface). The XML provided was included only as an example. The included XSDs cover the Request and Response structure.

7) The XML provided does not map one to one to each business process. The XML provided was included only as an example. The included XSDs cover the Request and Response structure.

8) The API structure seems to be an internal ERCOT Business process and not an external API and Web Services interface. The API Detail Design is how ERCOT plans to build the API interface. The XSD details how an external MP would interface with the FasTrak API.

9) Would like examples on this process. ERCOT is currently in the process of creating some example FasTrak API XML interface Requests and Responses.

10) How will the new system handle tracking the MP responses to a DEV and the comments each Party may add to the issue? The system will capture the data values for the final agreement start date and final agreement stop date in addition to the requested start & stop date. All changes to these fields are captured in the system audit log. Comments entered by users will be captured as part of the item. The Userid and date/time of the comment will be captured and associated with the comment.

11) How will the new system handle the issue of disagreement of the submitting MP to a response from ERCOT/TDSP/MP to a submitted DEV? (I.E. we submit a DEV, ERCOT/CR/TDSP modifies, and we disagree with the modification.) The user has the ability to approve the update, indicate no agreement reached or make a modification and return to the previous MP.

12) Are ALL column inputs defined either as dropdown choices on GUI or as valid inputs in the API structure? No, there are many different types of fields within the DEV structure. These field types include: free form text fields (i.e. comments), date/time fields (i.e. Requested Start Date), drop down fields (i.e. Assignee) and binary fields (i.e. Assign to Group).

13) How will the system determine the status of a DEV issue? Who sets the status? ERCOT? TDSP? Last MP to touch issue? The status of an item is determined by the structure of the workflow. Each step in the process has a specified responsible MP (i.e. NEW with TDSP, In Progress with TDSP)

14) To facilitate training and internal testing is it possible to have a test region or a demo available prior to April 12th? ERCOT provided a product walk through at the meeting on February 20th. It is committed to providing a final product demo on April 12th. ERCOT can also provide another product walk through outlining the progress made in development prior to the April 12th meeting.

15) It appears that the development paths taken on the GUI and API are somewhat different. Can you speak to the technologies and make a comparison chart between the GUI and API such as what does the API support that is not in the GUI and what does the GUI support that the API does not support?

Basic FasTrak Functions API GUI Programmed interface, that can be automated to require little to no user participation X Allow attachments to Issue X External User Admin X Mass Update of same information to multiple Issues X Update of information to an Issue X X Mass transition of Issues from same State to next logical State X Transition of an Issue from current State to next logical State X X Mass Create of Issues Bulk Insert Creation of an Issue X X Execution of Public Reports X Execution of Adhoc Reports X Execution of Public Queries X Execution of Adhoc Queries X X Print Reports X Link to TML X Audit Log Updates X X Spell Checking of Text Fields X Apply Business Process Workflows X X Ensure data visibility to only the appropriate parties X X Apply Business Data Validation X X Access to ERCOT/FasTrak Rolodex X

16) Will market participants be involved in the developing user guides and other supporting documentation? ERCOT will be creating the user guides and training materials. ERCOT will review these materials with Market Participants prior to them being finalized.

17) What was the approval process for publishing and maintaining the current tool documentation? ERCOT or a market group including ERCOT creates and posts a redline document to the Pending Section of the current tool. A market notice is sent by RCS soliciting opinions and setting up a conference call in T + 10 days. If comments are received the conference call is used to re-redline the doc. In this case the 10 day process is repeated. If no comments are received in 10 days a market notice is sent indicating the call is cancelled and the document has been blacklined and moved from the pending to the in flight documentation due to a lack of input. An example is the recent change resulting from the creation of the Unretire ESIID process.

18) Need information on why the market requirement change was made from a parent child relationship to one to one. Would like a specific example on how ERCOT envisions this process to work for issues with 100+ ESI IDs (for both the submitter and receiver)? As stated in the December Requirements Delta Document, FasTrak Requirement D6 was deleted. It was determined by the ERCOT Development staff that the Issue (parent) level contributed little to nothing to the Row (child) definition/resolution. The only functional reason for the parent level was for child organization and grouping. Thus if ERCOT Development can devise a method of grouping children, the parent level could be removed. ERCOT Development did devise a grouping mechanism in the FasTrak tool that will allow each user type (Submitter, Assigned, ERCOT) to group children (now elevated to stand alone issues) as they want them group as opposed to how the Submitter grouped them. This added additional functionality, flexibility and organization to issue management. The new direction was presented and approved by ERCOT Business.

It was identified by ERCOT Business that ERCOT Initiated Load Profile Assignment Issues may contain 100s of thousands of ESIIDs. In this case, ERCOT will create an Issue with an attachment. The attachment file will contain the list of ESIIDs in question. To date, this is the only time an attachment should be used to detail the ESIIDs.

19) There is a lot of confusion surrounding the current API documentation it appears that information is missing or hard to understand in areas such as: a. Diagrams, required fields, and field lengths The API Detail Design contains a WSDL definition and the API zip contains a XSD. These 2 documents should detail all the information you should need to implement the FasTrak API. b. Possible query fields. See above. c. If we request to create a new issue and our request times out while waiting for a response, will the system rollback the creation of the issue if it was created? This situation shouldn’t occur because the processing times for the server to complete the request should be smaller than the configured time out for the client. However this process is an “asynchronous” process and if for some reason the client have a “slow” HTTP connection and is experiencing timeouts then, before trying to resubmit the failed issue, it would be recommended to run a query to determine if there was any Issue created during the waiting period. The system will not rollback the successfully created issues even in the case of a disconnection of the client. d. Do you have a list of the exception messages that they will be returning? The structure of the “exception” response is detailed also in the XSD. However at this point we don’t have an extensive list of all the possible exceptions that could be raised. A list will be compiled and provided once development has completed. e. Do you have a list of the data field attributes that we will be passing back and forth? See response above. f. Is there a limit on the number of Issue Creates that you can request with the Bulk Insert? No, at this time FasTrak does not impose any limitation on the number of issues that can be created using the Bulk Insert. However ERCOT believes there is a limit imposed by Excel of 65,536 rows. If the CSV file used in Bulk Insert is built using Excel, you should keep this maximum in mind. In the future, should ERCOT feel that the unlimited maximum is causing Issue “though put” problems, ERCOT reserves the right to impose a maximum should the need arise. g. The activity diagram in section 4.1.1.1 (and others) shows the Digital Certificate Validation being done in Site Minder. In section 5.1 it states that Digital Certificate validation will be done in the TIBCO Business Works Engine and not in Site Minder. Which is correct? The digital certificates will be validated either by SM or BW. No matter which implementation is selected, the client interface is not affected and a Digital Certificate will be required. h. Through the API will you be able to withdraw a submitted issue? In general, if the issue is in a state in the workflow that allows the issue to be withdrawn it can be, if not it cannot. If you submit an issue, as the submitter you have the ability to cancel/withdrawal that issue till another Market Participant accepts responsibility for that issue. i. How could mass update be handled in the FasTrak API? For example: 1. Market Participant creates an excel spreadsheet, each row of which contains the updated information for 1 row and all the fields required by the API for submitting an Issue Information Update. Previously the Market Participant has written a program to convert excel spreadsheets (csv file) to FasTrak API XML. 2. Read a spreadsheet row, the program converts to XML and (thru the program’s SOAP client) logs into FasTrak API (Digital Certificate) and submits the update. 3. FasTrak API responds with XML containing Success or Failure comments. 4. Return to step 2 till all Issue Update rows in spreadsheet sent thru FasTrak API. j. Under section 4.2 Update Issue in the API – Please explain the statement - “This interface will not support the ability to add attachments or notes to the issue”. Neither the API nor Bulk Insert supports the ability to attach files of any kind to Issue. The API will not support the ability to retrieve files of any kind attached to Issues. Attachments were determined by FasTrak Development and Business to be outside scope of the requirement. With the way the FasTrak application is designed, few if any Issue will require attachments.

20) For the Train the trainer session will ERCOT provide the materials? Yes, ERCOT will develop the training materials and provide them at the training sessions.

21) Is the Market Test both on the GUI and the API? It has been decided by TTPT the Market Test will only include the API.

22) Has the market been informed they are required to test? ERCOT is working with TTPT on coordinating and communicating the testing for the FasTrak project.

23) Will market participants (MP) be involved in the developing user guides and documentation? ERCOT will be developing the user guides and documentation for the new tool. ERCOT will review the user guides and documentation with Market Participants prior to them being finalized. Documentation for the new tool will leverage the tool’s help feature. The new tool has a very robust help feature.

24) Will MPs be able to preview the training materials? ERCOT will develop the training materials and provide them at the training sessions.

25) How will we distinguish between the old and the new FT issues? Legacy FasTrak Issues will not be migrated to the FasTrak replacement application. The tool cutover plan will be finalized prior to the implementation of the new tool. However, ERCOT is suggesting that June 16th be the final day new issues are entered into the old tool. Beginning June 17th all new issues will be entered into the new tool. The old tool will be available for updating and viewing issues for a period of time after the implementation date.

26) Is ERCOT going to keep the 10,000 FT creation limit per day? The FasTrak replacement application will not be imposing a 10,000 Issue creation limit per day.

27) For FT issue related to finding the REP of Record, currently the only item required is the ESIID, can we make the dates to be required as well? This is a possibility for any field level questions if it is deemed necessary or beneficial at the FasTrak meeting on Monday, March 6th or via a process that the market determines thereafter.

28) Appendix A of Mass Insert Document - For billing issues, make the time frame in question a required field. Please refer to the answer for question #27

29) Appendix A of Mass Insert Document - For 997 issues, make the ISA and NAESB transmission ID information required. Please refer to the answer for question #27

30) Are there any controls to remind the user if he/she forgets an attachment that has not been submitted? The FasTrak replacement application does not require Issue attachments (except Load Profile Issues), so no notifications or controls are planned.

31) Does the GUI have any IE specific requirements such as Java? A GUI user will only require access to the web, such as Microsoft Internet Explorer. Java is not required but for those users who do not have java enabled in their browsers we will need to change their Team Track profile to 'suppress java'.

32) When trying to upload multiple Global IDs that already exist, will you get a message alerting you that these Global IDs do exist and the FT numbers associated with them? Yes, you will be alerted that the Issue contains multiple global IDs. Please see requirement A10 and A11 in the FasTrak Requirement Detail Design Catalog.

33) How many MPs will be using the API? What are the performance standards you are aiming for? At this time, ERCOT cannot forecast the number of MPs that will be using the API. Any MP that wishes to use the API will have to successfully complete market testing. At this time ERCOT does not know the number or which Market Participants will be using the API. Our performance goal is not to exceed 3 seconds from API request to API response per API request.

34) Is the API going to be using the digital certificates that we currently use? The API will require a Digital Certificate. A specific User ID will be associated with that DC and will identify the user as using the API. Only 1 API DC will be issued to each Market Participant using the API. 35) Will an email notification be sent to notify the user that he/she needs to update an issue? No, at this time there is no requirement to implement any email notifications except for Issue Escalation.

36) When will Production API be published at ERCOT to allow MP to access ERCOT FasTrak database? Plans are to go production on 6/20/06. The API is planned to be available in CERT on 5/22/06.

37) When will the FasTrak GUI be available for MP to access and start learning the FasTrak capabilities? The FasTrak GUI is planned to be available in CERT on 5/22/06.

38) Is there a logical data model of the FasTrak database? Can a logical model be provided to allow MP see what data is available on FasTrak database for querying with API? At this time, ERCOT does not have plans to release the FasTrak database schemes. ERCOT is planning on releasing field definitions for all fields defined in the XSD.

39) Will the API to FasTrak allow submission of BULK quantities of DEV variances? Is there a limit to the number of variances that can be submitted at one time or a file size restriction for the API? The API will allow submission of D2D and DEV issues.

40) Does the FasTrak database have fields for the Status and Resolution for each DEV variance and can the MP query the FasTrak database for the DEV variance Status or Resolution? Can one determine, with out business rules or logic, the status of a DEV in the FasTrak database? I.E. is the status? Resolved? Rejected? In Process? Can one determine without business rules or logic, the resolution of a DEV variance in the FasTrak database? I.E. is the resolution? Agree? Disagree? Modify? etc? The user will be able to determine where the Issues are in the Workflow by obtaining the Issue Status and Comments (optional).

41) Does the FasTrak database support queries with "AS OF DATE"? I.E. return Status and Resolution changes since (Sysdate - 7). From the FasTrak GUI and API, a user can retrieve Issues given a date range. Please see Requirement G7 in FasTrak Requirement Detail Design Catalog.

42) When will Digital Certificates be available? At this time, it has not been decided when Digital Certificates will be available to Market Participants. As soon as ERCOT has more information about Digital Certificates, it will pass it along to Market Participants. 43) Will there be specific ones for the servers that will run the API logic? Yes, a specific User Digital Certificates will be issued for use by a Market Participant for the API. Each Market Participant will be issued 1 API DC. A Server DC for the FasTrak API will not be issued.

44) Will the certificates be compatible with multiple OS systems and server systems? (Sun Solaris, AIX, etc) See Web Interface User’s Guide

45) Will there be a limit to the number of server certificates distributed to handle multiple environment regions (Dev/Test/Prod)? Yes, each Market Participant using the API will require a CERT FasTrak API DC and a PROD FasTrak API DC. Market Participant Users will only require a PROD User DC.

46) How often will these certificates expire? The Digital Certificates will expire after one year.

47) Will there be a limit to the number of API connections made by any one user? The number of API connections made by any one user will be limited to the number of API connections available. The FasTrak API will only allow a limited number of DC connections.

48) What will the availability of the ERCOT test systems be for when we are trying to do our SIT/UAT testing for API development? Market testing for the API begins on May 22nd and continues through June 9th. During this testing period, ERCOT will support all Market Flight testing, which includes API testing for the FasTrak project. ERCOT test system availability for API testing will be communicated to Market Participants at a later date.

49) When will the connection information be available for configuring the API portion of our development? A WSDL and XSD was provided with the API Detail Design on 1/31/06. The WSDL and XSD provide all the information needed to connect to the API.

50) Will there be constraints on what types of information we will be able to retrieve from the API (excluding data that is obviously not within our TXUED role to see)? The API will not be able to upload or retrieve file attachments to Issues. You will be limited to the fields defined in the XSD.

51) Will the database schemes be released so that we can accurately design our queries for data retrieval? At this time, ERCOT has not plans to release the FasTrak database schemes. ERCOT is planning on releasing field definitions for all fields defined in the XSD. 52) When working through the API, it is being assumed that 1 digital certificate will be used for all requests. This implies that when a client initiates the request that the API will be working on behalf of that client. Where in the WSDL or XSD is that user information defined? In addition, I believe that it would need to be defined on all interfaces. In the meeting it was discussed that a password would also be required. Since we are already authenticated with the digital certificate, why would the Password of the User that we are working on behalf of be required? 1 DC per MP will be used for all API requests. The DC contains the User ID, Password, and Company Duns need for authentication. The Company Duns and User ID from the DC will be combined to create the FasTrak User ID. Tied to the FasTrak User ID are the roles and responsibilities the user can perform in FasTrak. Given this, an additional FasTrak User ID and Password are not required and will not appear in the XSD and WSDL.

53) Will the API allow the creation of duplicate issues for an ESI ID / Tran Id? In the GUI if this combination is already found you have to reconfirm that you want to create. During API Issue creation, it is the GUI Issue Creation Workflow that creates the API Issue. Hence the API Issue Creation will have all the Issue validation that a GUI Issue Create has. If duplicate Globals or ESIIDs are found during an API Issue Create, the Issue will be created and the warnings returned to the user via API response. If the user determines the API Issue is a duplicate, the user should submit an API Issue Cancel Transition on the newly created API Issue.

54) The MP will be responsible for user administration within the TeamTrack tool according to what we have heard today. What happens to the issues assigned to or opened by a specific user if we go in and revoke that user id because they left the company? The External Administration Manual will cover this situation. If the Market Participant’s External Admin (there should only be 1) disables a User ID because of severance from the Market Participant’s company, there will be no need to mass transition items since they are owned by the group (MP company) and viewable by all MPs involved. The current design does not utilize single user ownership for control of an issue. Please note: The field Last State Changer could reflect a deactivated User ID. This model is desired to protect change control history.

55) Can issues be assigned to a specific user via the API? If so, does it require the API to log in as that user? No, Issues will be created using the API User ID.

56) It would appear that the query functionality available via the API is very limited in comparison to the types of queries that you can run via the GUI. Are there plans to expand the API functionality? Will we have the capability via the API to query based on the status or state of an issue? I don’t currently see that field listed in the query XSD. Please see the XSD definition. A new XSD will be released shortly.

57) Where is the location (path) of the API interface for communication that market participations will use? There is no "location" for an API, there will be a "SOAP Address" defined for each service we are providing. These addresses are included in the WSDL files already delivered. This is an example:

58) Generally speaking, what is the estimated message size that you would expect to receive or send in a message? From 1KB to 4KB for each incoming SOAP Request.

59) Is the API traffic coming over the internet or over a dedicated ERCOT connection? Market Participants will be communicating over the WAN via an URL to the MarkeTrak API interface.

60) I’m little confused with the chart from question 15 above, I thought one of the API’s main purposes was to create/update mass quantities of issues at one time. The API cannot do Mass Update – the updating of more than 1 issue’s information from 1 request. The API’s mechanism is request/response of 1 issue update at a time. The GUI tool has the ability to run a report, select multiple issues from result set, and update all with same information from 1 request. The same applies to Mass Create. The API is still request/response of 1 issue create at a time. The GUI, thru Bulk Insert, has the ability to attach a file containing 1 or more issues to create and submit from 1 request.

Questions Added After 3/24/2006

61) If ERCOT FasTrak is designed and managed by ERCOT, why would the individual market participants need to design anything on their end? The reason some Market Participants require ERCOT’s design documents is because they are planning on either using the API functionality or integrating the MarkeTrak tool to their back end systems. If a Market Participant does not plan to do any integration then it is not necessary to review the design documents.

62) Can you setup more than one Administrator for MarkeTrak? No, each Market Participant (DUNS number) will only be allowed one administrator for MarkeTrak.

63) Please change call time from Tuesday at 10am to either Monday or Friday. Too many market meetings on Tuesday, Wednesday and Thursday. The weekly conference call has been changed to Monday at 3:30pm. The call-in number is 1-800-211-0633 and the password is 844736.

64) More ports are needed for the call. The new call-in number listed in question #60 should alleviate all port issues.

65) We need a daily method for addressing questions to a technical expert on the project that will be able to respond to a technical question without doubt. We would like the response to be within 24 hours of the request. The following process will be implemented to answer all technical questions related to the FasTrak project:  Questions should be emailed to Scott Egger ([email protected]) and Michael Taylor ([email protected])  Scott and Michael will contact the submitter within one business day to schedule a call so that the question can be discussed.  The question and answer will be posted to the website in the FAQ document for the project

66) Need final XSD’s and WSDL’s Final XSDs will be available to the market on 4/5/2006. Final WSDLs will available to the market on 4/7/2006

67) Need final “state” names. ERCOT development and business are putting together documentation that will contain final workflow “State” names. ERCOT plans to have this information available to the market on 3/31/2006.

68) Please have an update from TTPT on the call each week. Susan Munson from ERCOT’s Testing Team will provide a weekly TTPT update.

69) We need a commitment from ERCOT on a connectivity test date. The API connectivity test is scheduled for 5/10/2006. Details for the API connectivity test will be sent to all the MPs that volunteered for this test.

70) Detailed Required Field per subtype was not reviewed by the Market until March 6, 2006. In the market call on March 14th, we were informed that these changes would not go in. This will impact the timeliness to resolve issues. We will have to rely on the comments field which is optional to have adequate information to work the issue complete. Changes Discussed at Meeting: 3/6  Made Tran Type required for Cancellation w/Approval and Cancellation w/o Approval  Made Tran Type required for Missing TXNS (except for tran types 867_03, 810_02 or 867/810)  Made Tran Type required and default to 867_03, 810_02 or 867/810 for the Missing Usage/Billing Issues sub type  Changed Usage/Billing Issues sub type to Missing Usage/Billing Issues  Start Date was added and it is Optional for Missing Transactions, Rep of Record, Projects, Siebel Chg/Info and OTHER: Required for Missing usage/Billing issues  End Date was added and it is optional for Missing TXNS, Missing Usage/Billing Issues, Rep of Record, Projects, Siebel CHG/Info and OTHER  Made Comments Required on the Siebel CHG/Info sub type  Made Date of Txn Opt on the Missing Usage/Billing Issues sub type  Added ISA field and it is required for 997 Issues sub type; optional for Projects and OTHER The above items were a requirement by the Market, as noted in Enhancement A:2 (note: ERCOT developed the matrix without market input). ERCOT analyzed the proposed changes and determined that the changes will be beneficial; however, the impact to the project scheduled and budget is too large to implement in the June 17th release. These changes will have to be part of a future release.

71) The API should be able to create, assign, update and query issues assigned to an individual person. ERCOT development and business have worked together to add Assign Owner capability to MarkeTrak. Users can read about Assign Owner functionality in “FasTrak TeamTrack Detail Design 031506.doc”. Assign Owner will be available via the API. The API user will be able to assign, update and query Assign Owner. Please see final XSD.

72) I pull the “new” issues from MarkeTrak thru the API. I send an update back thru the API to assign the issue. I send another update with comments on the progress to resolve issue thru the API. With this being an Update request, can I send it with the group name? ERCOT will be adding Assign Owner capability, so the need to use Assign Grouping is not necessary. Given that, the API will function the same as the GUI. Currently in the GUI, the update of the issue and the Assigning of Owner are 2 different transitions. So via the API, the Market Participant will need to issue 2 separate “updates”. In addition, when a GUI issue is created in MarkeTrak, the Assigned Owner will default to the UserId that created it. When an API issue is created in MarkeTrak, the Assigned Owner will default to the alternate UserId.

73) Where can I find documentation on Grouping and Assign Owner? Users can read about Grouping and Assign Owner functionality in “FasTrak TeamTrack Detail Design 031506.doc” chapters 18 and 19.

74) In QueryRequest.xml document, when it refers to OtherMPDuns – my interpretation is that I will put another MP Duns and not my MP Duns. I am unclear why I would put another MP’s duns when I want to query for issues that are my MP duns’. Please clarify. Inherent to MarkeTrak, all users can only see and reference issues that their MP has involvement in, whether created by your MP duns or assigned (Assignee) to your MP duns. Thus, there is no need to add querying by you MP duns – you are only going to get issues your MP has permissions to access. OtherMPDuns allows the API to query for issues that their MP is an Assignee on.

75) If I specify a “FromDateTime” and a “ToDateTime” what is this querying against? It appears that it is not the “LastModified” information since there is a way to query for this. ERCOT Development found the same issue with the old XSD, the new XSD due out on 4/5/2006 should correct this issue. Namely the following XML fields will be added to the API query and IssueDetail response capability: LastModifiedFromDateTime LastModifiedToDateTime SubmitFromDateTime SubmitToDateTime LastStateChangeFromDateTime LastStateChangeToDateTime CloseFromDateTime CloseToDateTime At submit time, LastModified, LastStateChange and Submit date/time will match, till next update. At Close time, LastModifed, LastStateChange, and Close date/time will match, till next update. At any State change, both LastStateChange and LastModified date/time will match, till next update. When any update happens to an issue, LastModified date/time changes.

76) How do I tell WHO (Person and/or DUNS) changed the state? ERCOT Development found the same issue with the old XSD, the new XSD due out on 4/5/2006 should correct this issue. Namely the following XML fields will be added to the IssueDetail response capability: LastStateChanger

77) In the “Comments” element or “commentsDef” complexType, it has 3 fields defined: Duns, DateTime, CommentsText. Is it possible to know WHO created the comment? ERCOT Development found the same issue with the old XSD, the new XSD due out on 4/5/2006 should correct this issue. This was a typo. The 3 fields should be: UserId, DateTime, CommentsText. All MarkeTrak UserIds are composed of 3 parts: mpduns + “$” + dcusername. The dcusername comes from the user’s Digital Certificate. Thus, the UserId will identify which MP and which User.