Party Harmonization Sample: Initial Draft 0.1


PartyType

Comment: Is the name of this thing 'PartyType' or 'PartyDetails'. Check with naming rules. The CC rules have no concept of type, per se, so my understanding is that if it's an element, it gets '_____Details', and if a global type, then it gets '_____Type' - so, BuyerPartyDetails of type PartyType. Right?


IdentifierType

Comment: Do we need to add a "ListOfIdentifier" here, or can we get away with only one? xCBL provides a primary one, and then a list. Also, what is up with the name? This is a weird, crappy name, but I don't quite get hos this works. See comment from Party, above.


AgencyType


NameAddressType


POBoxType


RegionType


CountryType


TimeZoneType


NameAddressTypeType


ContactType


ContactFunctionType


ListOfContactNumberType


ContactNumberType


CorrespondenceType

Comment: This object was invented to carry the xCBL "CorrespondenceLanguage" element. Without an object to attach that attribute to, we will not be observing the object relations implied in the naming conventions. I think we should discuss this interplay, as it could lead to some rules about structuring of data that will provide great excess verbosity and increased consistency. Which do we want?


LanguageType


AgencyCode

Comment: Note that this code list was taken directly from xCBL, which derived it from EDIFACT 3055 (Code list responsible agency code) and X12 559 (Agency Qualifier Code).


CodeListIdentifierCode

Comment: Since CC doesn't specify codelist values, we have taken them from xCBL. This code identifies the code list used. This code list is derived from EDIFACT 1131 (Code list identification code) and X12 1270 (Code list identifier code)


RegionCode

Comment: Code values from xCBL for Region. This code list is derived from ISO 3166/1998 (Country code subdivision code, UN/LOCODE 2000)


CountryCode

Comment: Country codes. This code list is derived from ISO 3166-1997

Comment: Values from xCBL. We may be able to describe this better using regular expressions, which didn't exist in SOX, and are therefore not in xCBL. This is not standard codelist, but merely an obvious expression of the possibilities created in cooperation with SAP.


TimezoneCode


AddressTypeCode

Comment: Taken from xCBL, this code identifies the type of address. This codelist is derived from EDIFACT 3035 (Party Function Code Qualifier)


ContactFunctionCode

Comment: This is taken from xCBL. This code list is derived from EDIFACT 3139 (Contact function code) and X12 366 (Contact function code)


ContactNumberTypeCode

Comment: This is a non-standard code.


LanguageCode

Comment: from xCBL. This code identifies the language being used. This code list is derived from ISO 639-1998


LocaleCode