Do I need to apologize first for this post?  This post gets deep in the weeds of data interaction on the nomination transaction.  But somewhere, somehow, someone has to get down in the weeds to explain why people keep tripping over transaction types.  It has to be said! So here it comes.

Transaction Types are data values on nominations that indicate the shipper’s usage for the quantity that is being requested.  That’s Sylvia’s definition and it assumes you know what a nomination is and who is a shipper.

The standard default transaction type in nominations is ’01 – Current Business’, meaning that this transaction uses the general terms of the contract.  There are over 100 transaction types available in the North American Energy Standards Board (NAESB) Nomination dataset, but a single pipeline will usually support only 5-10 of those types.

Okay – that’s easy – what’s the big deal?  There are, actually, two big deals.  The first is that the transaction type can occur on each nomination in each model type and this opens the door for confusion and varied interpretations.  The second is that there are three different transaction types – Transaction Type, Upstream Transaction Type and Downstream Transaction Type – and people tend to make assumptions regarding their meaning.

The first issue:

A pathed nomination uses one nomination line item to transact business and, therefore, one transaction type.  Easy.

A non-pathed nomination uses two nomination line items to transact business and, therefore, two transaction types.  So we need to have rules in place on what transaction types are used in which situation and how they are balanced.

Then we get to the pathed non-threaded nomination and see that it uses three nomination line items to transact business and three transaction types.  Now things are starting to look complicated.

Let’s look at a few of the most commonly referenced transaction types.  These would be the ’03 – Imbalance Payback from TSP’ and ’04 – Imbalance Payback to TSP’.  Note that TSP in this case stands for Transportation Service Provider.

If you are submitting a pathed nomination and want to use ‘03’ to receive 500 DTH of gas back from the TSP then you’ll submit a nomination with zero as the receipt quantity and 500 as the delivery quantity.  Clear and easy.

If you are submitting a non-pathed nomination then you won’t need to enter an upstream nomination but you’ll enter a downstream nomination with ‘03’ transaction type and 500 DTH as the quantity.  In this case the payback is coming from the pipeline’s linepack volume and there is no need for a receipt type nomination to balance the transaction.  Still clear and easy.

So what happens if you are submitting a pathed non-threaded nomination?  My first choice would be for you to enter a downstream non-pathed nomination with ‘03’ as the transaction type and the quantity of 500 DTH on the downstream non-pathed nomination.  The corresponding pathed nomination and the upstream non-pathed nomination would be with ’01 – Current business’ as the transaction type and would contain either zero or the quantity that needs to be transported.  This seems pretty clean because the shipper is only telling the pipeline where the payback gas needs to be taken off the pipeline, without association to any transportation or supply of gas.  The second choice that I have seen in implementations is to create, essentially, a whole path of gas for this ‘03’ transaction type.  In this implementation, the shipper would create an upstream non-pathed nomination with a quantity of zero, a pathed nomination with a receipt quantity of zero and a delivery quantity of 500, and a third nomination as the downstream non-pathed with a quantity of 500.  All three of these nominations would have the transaction type of ‘03’.  This second choice is technically correct and do-able, but it puts a lot of extra work on the shipper and unnecessarily ties the payback transaction to a path of gas that is not needed.

There are other transaction types which cause these same scenarios, but NAESB and most pipelines do not give clear instructions on how they are used.  This leaves room for interpretation – a dangerous game.  Interpretation results in different pipelines solving the same problem in different ways and  different shippers trying solutions that the pipeline doesn’t expect.  This makes it hard for everyone involved to get the results they expect.

The second issue:

There are three (3!) different transaction types available on the model types.  For a long, long time there was only one transaction type and it was called Transaction Type.  As NAESB standards progressed, pipelines asked for an Upstream Transaction Type and Downstream Transaction Type to be added for the confirmations process.  The Upstream and Downstream Transaction Types, if you look up the NAESB definition, do NOT refer to the business being conducted on the current pipeline. The Upstream Transaction Type refers to the transaction type on the pipeline Upstream of the current pipeline. The Downstream Transaction Type refers to the transaction type on the pipeline Downstream of the current pipeline.  Interestingly, people look at the name and think that the Upstream Transaction Type must go on the Upstream Nomination in the Non-Pathed and Pathed Non-Threaded Model types but this just isn’t so.  The Upstream Transaction Type can go on the Pathed or Non-Pathed Model but NAESB clearly states that it is referring to the transaction type of the nomination on the upstream pipeline.  All of the same logic/rules apply to the Downstream Transaction Type, of course.  And, the Upstream and Downstream Transaction Types do not exist on the Pathed Non-Threaded Model Type at all!

Clearly looking at the definition of data elements is essential before assuming their meaning or intent because the name is not always the only indicator of the purpose.  Nominations are complex transactions.