Closed mskopp closed 2 years ago
My proposal:
Agreement to find a solution to use Party.
With Ontology 2.0.0 we can put this in
"https://onerecord.iata.org/BookingOption#parties" : [ {
"@type" : [ "https://onerecord.iata.org/Party" ],
"https://onerecord.iata.org/Party#otherIdentifiers" : [ {
"@type" : [ "https://onerecord.iata.org/OtherIdentifier" ],
"https://onerecord.iata.org/OtherIdentifier#identifier" : "SHP_ACCOUNT_NO_1234",
"https://onerecord.iata.org/OtherIdentifier#otherIdentifierType" : "AccountID"
} ],
..
"https://onerecord.iata.org/Party#partyRole" : "Shipper"
},
So issue could be closed from my point of view. Thanks
Yes and it is included in the ChangeLog for the v2.0.0 https://github.com/IATA-Cargo/ONE-Record/blob/master/May-2022-standard-forCOTBendorsement/Data-Model/IATA-1R-DM-ChangeLog-vCOTB-May2022.md
Thanks
(This question is from the XFWB-to-1R converter at https://onerecord.riege.com/ and results from uploading the example message https://onerecord.riege.com/888-11111111_XFWB.xml into the converter, warning message 'where to put address-account-number 'SHP_ACCOUNT_NO_1234', using OtherIdentifier with type 'carrier-account-number' as workaround')
Where to put address-account-numbers and which qualified/code should officially be used when storing in 1R OtherIdentifier?
The official code should be documented in Ontology.