[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Party Types
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]