http://www.contentsunderpressurebook.com

We’ve all encountered them – those times when you know you have everything nailed down perfectly in your system design.  Then, three weeks into production, you hit that “gotcha” moment where you realize that you didn’t know all that there was to know about some of the details.

There are plenty of those that we can look at, but today will be about one my personal favorites – the business party name.  In NAESB-speak, there are four business parties in a nomination.  Let’s focus on that one transaction set.  There’s the Pipeline (aka Transportation Service Provider or TSP), the Shipper (aka Service Requester or SR), the Upstream Party and Downstream Party.  Each of these is identified by a high level grouping such as Transportation Service Provider Data, Service Requester Data, etc.

This high level grouping identifies three data elements in each grouping. The name, the common code (NAESB uses the DUNS number), and the proprietary code.  There are, then, conditions and standards to provide instructions on when to use each one. The pattern is very consistent.  Names are required on web sites but not in EDI or flat file formats.  Common codes are always required but the proprietary code is required if the common code is not available.  This means that you can send the data without a common code if you have the pipeline’s proprietary code instead.

The solution providers, the IT guys, have to know which data element to put where and how to properly label it.  It isn’t impossible to determine, but it does take thought and planning and cannot be just plopped into the dataset.

Okay, that sounds easy enough, so what’s the big deal?

The big deal comes into play when you realize that the Upstream Party and Downstream Party are part of the nomination key.  The nomination key is that set of data, defined by NAESB that, when put together, distinguishes uniqueness between nomination line items.  The reference to Upstream Party does not select the DUNS number or Name or Proprietary Code.  It references the grouping.  And since there are a whole set of rules to determine which one is used and when, this means logic must be created that determines the key in chorus with these mutually exclusive fields of data.

For instance, if I am sending a nomination via flat file and I do not have a DUNS number then the proprietary code is the code that I will use to identify my Upstream Party and that value will become part of the key. However, if I am sending a nomination via a web site (EBB application) and I have a DUNS number then the DUNS number will be part of the key.  In either case, the expectation is that the pipeline will always receive either a DUNS or proprietary code and not just a name.  Unless that name is all that the shipper can provide, which happens!  So the logic to determine the key must take into account the entire set of conditions and determine whether the conditions of the key are met in this line item.

It’s not looking so obvious any more, is it?  And these aren’t the only two data elements where this can occur. It can also happen on the locations and there are four possible locations in the dataset.

Now that we’re talking about the nomination key, there are a couple of other places where you can hit a speed-bump in development.  I’ll provide more on those tomorrow.  Have a great day!