Party Types

[Oriol Bausą <oriol@tradise.com>]

As stated in the UBL_11 sheet of the issues.xls from Jon Bosak, there is a
proposed addition to 1.1 in the Party types item.

The requirement appears when developping interfaces between UBL and EDIFACT
systems. We realized that in EDIFACT environments they are using party types
in the Order and in the Invoice main documents others than the ones defined
in UBL. They are using the NAD segments and they can qualify them with a
Code which semantically qualifies each party.

The real use in Spain shows that not all of those defined parties are used
in the studied industry, but there are some of them that we think that need
to be addressed. 

The code list that can qualify the NAD segments is huge. However, here you
have an extract of that code list with probably the most used in the
order-to-invoice procurement cycle:

BCO	Buyer's corporate office
SCO	Supplier's corporate office
SU	Supplier 
BY	Buyer
II	Issuer of invoice
IV	Invoicee
PR	Payer
DP	Delivery party
PE	Payee
WH	Warehouse keeper
PW	Despatch party

In xCBL, there is a Party Scheme where there are also parties other than the
Seller and the Buyer. In that case, you have the following parties defined:

BuyerParty - contains the information for the party purchasing the goods.
SellerParty - identifies the party selling the goods. 
ShipToParty - contains the information for the party which the items are to
be shipped.
BillToParty - contains the information for the party that will receive the
bill for the goods.
RemitToParty - contains the information for the party to be paid. 
ShipFromParty - contains party information identifying the location from
which the items are to be shipped.
WarehouseParty - contains party information identifying the warehouse from
which the items are to be shipped.
SoldToParty  - contains party information identifying the location where the
items were sold.  
ManufacturingParty - contains the party information identifying the location
where the item is to be or is being manufactured.
MaterialIssuer contains the information identifying the location that is
issuing the request for the material. 
ListOfPartyCoded - is a collection of all other party information not
explicitly stated as the content of another element.
BuyerTax - identifies the tax levy information for the party buying the
goods.
RemitToTax - identifies the tax levy information for the party that is to be
paid.
Carrier - identifies the carrier for the ASN, in cases when only one carrier
is used for the entire ship notice.
SenderParty - contains information for the party originating the
InventoryReport document. PartyRoleCoded is used to specify the relationship
between the sender and receiver and identify the role that the sender plays
with respect to the receiver. The PartyRoleCoded value can be any valid role
code value. For example, values such as Seller, Buyer, ThirdParty, or
Warehouse could be used here.
ReceiverParty - contains information for the party receving the
InventoryReport document. PartyRoleCoded is used to specify the relationship
between the sender and receiver and identify the role that the receiver
plays with respect to the sender. The PartyRoleCoded value can be any valid
role code value. For example, values such as Seller, Buyer, ThirdParty, or
Warehouse could be used here.

So the first point is that we think that the UBL maindocs needs to be
extended to be able to integrate some of those new party figures.

And we think we have basically two ways to resolve that issue:

1.- Through customization, you can extend the UBL model to fit your
customer's requirements, and implement the additional parties they need, for
instance adding the ShipToParty and BillToParty in the Invoice.

2.- Implementing the AdditionalParty qualified and with infinite cardinality
in order that every single party required in any customer invoicing scenario
should be placed there with the proper qualifying code.

The first approach is used in xCBL. In the case we choose that way, we
should agree with the parties we need in the different main documents in
order to prevent their automatic extension by the different implementors,
and trying to prevent huge main documents.

The second approach is the EDI style, so probably is old-fashioned, but the
implementor never needs to extend the model and the document does not
increase its tag count size. However, in that case you need to maintain a
Party Qualifier code list.

I've thought about the second approach because it is a mechanism still used
in UBL (AdditionalReferenceDocument or AdditionalAccountID), but probably
the best way is the first one because you maintain the semantics inside the
document. In that case we need to agree in the partys we should implement in
UBL 1.1.

Regards,

Oriol Bausą
Tradise
ESLSC co-chair