Four-score and seven years ago – okay, really – only one score of years ago – when the Pathed Non-threaded (PNT) Nomination Model was created it was an outlier model type used by one company. Today that model type is used by many companies and is becoming the source of a lot of interpretation.
There are problems with the way the model type is being implemented today and there are two factors contributing to this problem. We’ll look at them individually then pull them back together to find a solution.
The Service Requester Contract (SrK) is mandatory on the upstream and downstream nominations of the PNT model and it should not be. Kinder Morgan, Boardwalk and Iroquois have submitted a request to have this changed.
When the model type was created, for NGPL, the NGPL representative, Mike Schisler, explained that the shipper contract (NAESB term = Service Requester Contract) had no meaning on the upstream and downstream nominations of the PNT model. But the data set designers insisted that it remain. The compromise was that NGPL would fill that field with the service requester’s DUNS number. That solution has worked for NGPL for many years even though many of us in the industry as well as more recent implementers did not understand the real impact of the decision. The solution implemented by other pipelines varies, is inconsistent, and provides for unintended inconsistencies.
Note that I do not believe there is any documentation in the NAESB standards or implementation guides that specifically says the SrK should be filled with the service requester’s DUNS number. This was only an “understanding” – which adds an additional level of confusion and was not conveyed to other parties attempting to implement the model in the same way.
The Service Requester (SR) is defined as the shipper or their agent.
There is one field for a Service Requester on a nomination. My understanding has been that if the shipper is submitting their own nominations then they will provide their own identifier as the service requester. If the agent is submitting nominations for a shipper then the agent identifier will be used in the service requester field and the service requester contract will be used to distinguish shipper rights for that agent.
When we add these two factors together in the model type, you would think that we’d get 3 simple variations since both are mandatory. SrK used + SR Agent, SrK used + SR Shipper, SrK DUNS + SR. Not so! What we’ve seen in the industry is that we have 4 (rumor is that there may be a 5th) variations of how pipelines use these fields to define nominations for the upstream and downstream nominations of the PNT model.
Pipeline Scenario 1:
SR = Agent, SrK = agent DUNS
I have to admit – this is the way that I thought that the PNT model should work when an agent was engaged. I did not initially recognize the implication of this scenario. If I, idealistically, apply the definition of the SR and then use the rule of putting the SR’s DUNS into the SrK field then the result is this scenario.
However – if you consider a group of upstream nominations at a receipt location where all of them are designated for the agent, then how does the pipeline determine which transactions belong to which shipper and how is shipper-must-have-title rule being followed? This would be a plausible solution if the agent has asset-manager rights but not for a traditional shipper agent. This forces the agent into what I would call an agent-level aggregation where all of the agent’s transactions at a location are aggregated under that agent and not distinguishable by shipper.
Pipeline Scenario 2:
SR = Agent or Shipper, SrK = shipper DUNS
This scenario works the way that I believe the model type was originally intended but it has to abuse the data elements in order to make the model type work. In this scenario, all of the quantities for one shipper are aggregated at a location so that they can then be distributed among the threaded, contract-specific nominations on the other side of that same location.
If the shipper is the SR then this scenario is clean and easy, though the pipeline is still forced to repeat the shipper DUNS in the SrK field. When the agent is the SR is where the information becomes muddy and where it becomes obvious that an additional data element, to distinguish the agent from the shipper, is necessary.
Some pipelines have solved this scenario by using the EDI enveloping to identify the agent and, then, identifying the shipper in the SR field. This works, but it is another forced use of the data elements in a way they were not intended to be used.
Pipeline Scenario 3:
SR = Agent or shipper, SrK = shipper contract
If the pipeline has chosen to use the shipper contract on the upstream and downstream nominations then the issue of whether the party identified in the SR field is nullified. The level of nomination aggregation has been taken to a lower, contract level, and the contract for aggregation has been identified. This contract-level aggregation does not provide as much flexibility for the shipper, but all of the data needed to accomplish the task is included.
However, even though the SrK solves the problem, the solution should be consistent across all of the nomination models and model usages.
Pipeline Scenario 4:
Any of the above plus Threaded Nomination association
I am including this scenario because I have seen several companies implement the PNT model in this way even though the data in the transaction does not support this implementation! In this scenario, the upstream and downstream nominations are directly tied to a threaded nomination. This is essentially a pathed-nomination in most examples where a single upstream is tied to a single threaded nomination and a single downstream, but the implementation does allow for two or more upstream or downstream nominations to be tied to that middle threaded nomination. There is no aggregation at the contract or shipper level in this scenario because the upstream and downstream nominations are tied to an individual threaded nomination.
Again – the data in the dataset does not support this implementation. The implementer has to create an artificial connection to tie the various nominations together. The artificial solutions that I have seen are through tracking id’s, package id’s or through the use of a pipeline-managed database internal id that is not maintained by the shipper. This scenario would be impossible to implement using EDI in the existing dataset.
So where does this leave us?
We need a solution so that shippers know what to expect. We need a solution so that the implementations of the model type can be clean and consistent. We need to add and define the data in the dataset so that it fully supports the model type. We can continue to perpetuate some of our incorrect decisions, but, ultimately that does not buy any efficiency, it allows us to continue with bandaids as solutions.
Here are my suggestions:
1 Split the current “Service Requester” data element into two fields:
Service Holder or Shipper and
Service Holder/Shipper could either be mandatory in all cases, or conditional with a condition that it is mandatory except where a pipeline supports agent-level aggregation and the nominating party has provided an Agent DUNS. I would prefer mandatory and let the pipeline implementation determine how the shipper information is used.
Agent would be conditional – either an agent or service holder must always be provided and Agent is required if the party submitting the nomination is different than the party holding the service contract.
2 As Kinder Morgan, Boardwalk and Iroquois have requested, make the service requester contract a business conditional data element on the upstream and downstream nominations of the PNT model. It should remain mandatory for all other cases. It should only be used on the PNT model’s upstream and downstream nominations if the pipeline supports contract level aggregation. Otherwise, it is not used.
3 Make it clear in the nomination implementation guides that there are three levels of aggregation and that a pipeline will generally only support one of those levels. The three levels are Agent-level aggregation (give an example), Shipper level aggregation (give an example) and Contract level aggregation (give an example). If parties desire the dataset support additional levels of aggregation then those parties need to submit a request to NAESB for the requirements of that aggregation level to be supported.