I said I’d talk about the nomination key speedbumps “tomorrow.”  Well, “tomorrow” came a little later than I had intended, but here I am.

The nomination key, in NAESB’s 1.4.1 dataset causes so much confusion.  The key is defined in NAESB WGQ Standard 1.3.27 (Version 3.0, www.naesb.org, password protected) and, to those who help develop and maintain this list, it is very clear.  To those who read this list and try to apply it to the dataset, it becomes muddy quickly.

First of all – what is a key?  If you’re an IT developer, you may think that we’re talking about a DB key which is a system generated unique identifier for a row of data.  If you’re a business person, you may be looking at a key as the data that I need to find a nomination.  And you are both partially right!

“…The nomination key is the group of data elements in a nomination that, when a value in one or more elements is different, causes a new nomination to be created. It is important to understand the key and how it works in the nomination process. The list of elements that comprise the key are those that, when combined, create a unique line item of a nomination. When an element is not part of the key, then the value of that element does not contribute to the uniqueness of the nomination and may be changed without creating a new nomination. When an element is part of the key, then a change in the value of that element will result in a new nomination being created. (Contents Under Pressure – The Complete Handbook of Natural Gas Transportation)”

Okay – that’s simple enough.  Now go look at the list of data elements that comprise the key.  NAESB has a list in NAESB WGQ Standard 1.3.27 that contains 18 data elements.  Two of those elements are mandatory for a pipeline to support and for a shipper to send.  The remaining data elements are mandatory in certain conditions, optional in other conditions and not used in some conditions.  The pipeline will determine which of the elements will and can be used.  The shipper will have to apply the dataset conditions as well as any pipeline conditions to determine which of the pipeline elements to use and when.  There will never be a real scenario where only the two mandatory elements are used.  There are quite a few conditions dependent on nomination model type and direction of flow that cause either the receipt side information (Receipt Location, Upstream Party, etc.) or delivery side information (Delivery Location, Downstream Party, etc.) to be sent.  Most of these conditions are not determined by the sender of the information (the shipper), but are determined by the nomination model type being used, the direction of flow and the pipeline business requirements.

The Package ID is one example of an element that must always be supported by the pipeline but is always optional for the shipper to send.  The Package ID is used for the benefit of the shipper if they need it.  The pipeline may make other data elements such as Upstream Contract and Route optional or mandatory and the pipeline include use of elements such as Capacity Type Indicator as optional for the shipper.

You’ll notice that the key does not contain a nomination begin and end date.  That may seem strange, but it’s not strange at all.  NAESB WGQ Standard 1.3.7 establishes a rule that each nomination exists for a single day and when a multi-day nomination is submitted, each day of that date range is treated like a unique nomination.

The toughest part of the key is when you need to determine which value of one of the compound elements, such as Upstream Party or Delivery Location should contain to satisfy the key requirements (See previous blog at: https://contentsunderpressurebook.com/2015/08/04/those-picky-little-details-in-gas-system-design-that-can-cause-so-much-trouble/ for more information on this condition).

Understanding what is the key, what comprises the key and what is NOT part of the key is terribly important in implementing these NAESB transactions.  I’ll write next on what is NOT part of the key.  Stay tuned.