[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [energyinterop] Registration and Party IDs
If Parties have a need to track their activities by setting up Accounts and Identifying Accounts to their counter parties then an Account is a useful construct as an alternative to multiple Party IDs for the same Party. That is all an Account provides. For example an owner of many buildings may want to an Account for all Power Purchases and Another for all Natural Gas Purchases. Or as a utility, I can create several Parties, such as PGE Generation, PG&E Electric Transmission, PGE Load Serving Entity, PG&E Trading, PG&E Gas Transmission, PG&E … Or I can have a Master Party ID, with Accounts to Identify Business Units, Divisions etc. Having both a Party and an Account gives Parties a choice on how to identify themselves to a registrar or to counterparties. What ESIs, meters, generators, virtual generator (DR) and transaction get associated with an Account of a Party is a separate issues. Edward G. Cazalet, Ph.D. 101 First Street, Suite 552 Los Altos, CA 94022 650-949-5274 cell: 408-621-2772 From: Gerald Gray [mailto:gerald.gray@guiding-principle.com] Is it possible for a Party to have more than 1 account? From: Toby Considine [mailto:tobyconsidine@gmail.com] On Behalf Of Toby Considine If a party is a business entity with an associated account, what is an account? Or is party what happens during [was registration, now identification? credentialing? Exposition?] An account is created (or associated) during [enrollment or registration] Resource associated with account during [registration or enrollment] "He who fights with monsters should look to it that he himself does not become a monster, and if you stare long into an abyss, the abyss also stares into you." - Fredrich Nietzche
From: Holmberg, David [mailto:david.holmberg@nist.gov] Updated definitions based on the discussions on the EI call yesterday. Below and attached (includes notes).
From: Holmberg, David A spreadsheet with some definitions for discussion.
From: Considine, Toby (Campus Services IT) [mailto:Toby.Considine@unc.edu] Some inconsistency here… If a Party is 1-1 with a VEN (if it is a VEN), and if a VEN is 1-1 with a Resource, why do we need a ResourceID? Can a resource be moved to a different VEN? Can a Resource be transferred to a different Party? Is it because a Resource can be resold by an aggregator? “You can’t have multiple Parties per customer” So are all Wallmarts in North America identified as the same PartyID? If so, Registration is primarily concerns with identifying your PartyId. tc "It is the theory that decides what can be observed." - Albert Einstein
From: Holmberg, David [mailto:david.holmberg@nist.gov] Toby, It seems you and EdC have a different perspective on Party. You seem to view it as equivalent to a resource, such that VEN is identified with a PartyID. EdC sees it as a customer with an account (or a customer with a SDP). This allows a Party to have multiple resources. Thus, a VEN has an associated PartyID, but a Party may have 0 to * Resources. Bill agrees with this, I think, or at least that a Party is not the same as a Resource. I think then that a Party is tied closely to a customer and you can’t have multiple Parties per customer. But a VEN and Resource are 1 to 1. Interesting question about VTN/VEN, buyer/seller. I think a customer has a PartyID, and enters into market transactions to either buy or sell some resource. If selling, there should be an indication of that role, but not a SellerID, and there will be an associated ResourceID (for the generator or DR resource). If buying, there will be an indication of that role, and no associated ResourceID. A VEN should have an associated PartyID, SDP (meter mRID maybe, premise location?), and URL. Whether something is acting as VEN or VTN is maybe simply a role that is also indicated in a service exchange. David From: Toby Considine [mailto:tobyconsidine@gmail.com] On Behalf Of Toby Considine Slight change of pace here – into the schemas We seem to be congealing around “Registration is how you get a Party ID” A VEN is identified by a PartyID A VTN is identified by a PartyID A Transactive [agent] is identified by a PartyID Several Parties may be part of some larger entity. If the Parties are acting as VENs, we may call that larger entity a Customer. - A Customer is the business entity behind 1-to-many VENs that have a common relationship to the entity behind a VTN , each identified by a PartyID. - Is there a common entity behind multiple VTNs that should have an ID as well? - Is there a common entity behind multiple [agents] as well? Parties have Roles: “Buyer” and “Seller”. Should we have a BuyerID and a SellerID instead of a CustomerID and “%%%”? The eiParty is an existing type. The type consists of a partyID, a partyName, and a partyRole. Is this correct? Does it line up with the narrative above? If so, then it implies that a party enrolling as both a VTN and as a VEN should have two PartyIDs. This does not feel correct. Where does the eiParty fit in the Transactive world? tc "He who fights with monsters should look to it that he himself does not become a monster, and if you stare long into an abyss, the abyss also stares into you." - Fredrich Nietzche
| |||||||||||||||||||||||||||||||
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]