Re: [ubl-tsc] TSC Telecon 8 Jan 09 7pm EST

[Hendry <ahendry@pacbell.net>]

Thanks, Tim.

Yes, looking at the spreadsheet for Rec 28 rather than the pdf document, 
I now see that it contains a second part.
For the COO, I thought as much since it didn't make sense to have both 
documents if they didn't meet up somewhere.  Still have to decide what 
to do with the aspects of COOA that have no mapping in CCL, which turn 
out to be most of them.

Will talk more about this in the meeting, then, so we can move on to 
mapping the rest of the library.

-A

Tim McGrath wrote:
> Sorry it took a while to finally get onto this.  Hopefully it gives us 
> something to talk about next week!
>
> Andrew Schoka wrote:
>>
>> Hi Andy,
>>
>> Great talking to you again today.  I think we're making great 
>> progress!   It will be nice to have some completion on these items 
>> and be able to move on to other submissions.
>>
>> Below are the questions I have for Tim from our conversation on the 
>> CCL alignment this morning for the area I was working on.
>>
>> Let me know if you have any questions on this.  I think it's not 
>> necessary to put these into spreadsheet or any other more formal 
>> format since hopefully they will be answered and disposed of rather 
>> quickly.
>>
>> -------------------------------------------------------------------------------------------------------------------------------- 
>>
>>
>> _*For Shipment Stage:*_
>>
>> -- Transport Means. Type. Code and Transport Movement. Mode. Code 
>> essentially have the same values when you look at their code lists as 
>> documented in CCL.  Mode points to UNCL Rec 19 and Means points to 
>> UNCL Rec 28.  However, 28 is a subset of 19.  They both have values 
>> such as 'Maritime', 'Road', 'Rail', 'Air', etc. which is fine for 
>> 'Mode', but 'Means' should be more of the type of transportation 
>> vehicle information (type of means of transport for any of those 
>> modes).  Therefore I believe the CCL note on Rec 28 might be 
>> incorrect.  I don't see any other pointer to a code that is more 
>> aligned with 'Means', though.  At least the name is reasonable even 
>> if their example is not so we can leave that as is if you agree.
>>
> Rec 28 is not really a subset of 19.  It contains the codes from Rec 
> 19 to denote what modes of transport apply to each means (like country 
> codes appear in currency and port codes).  So the qualified code types 
> for the CCL are correct.  In UBL we only use the qualified data type 
> for Transport Mode. This uses Rec 19 (although we have a typo in the 
> QDT definition and genericode file that says it is Rec 16).  We have 
> flagged this as an issue for repair in UBL 2.1
>> -- For the Shipment Stage 'PortLocation' associations, the first two 
>> had almost identical 'port' entities in CCL denoted in the name.  
>> However, the last one (transshipport), when in CCL, does not contain 
>> the word 'port'.  How is 'port' being used in UBL here -- does it 
>> mean a sea/water port, or any place of transfer of a 
>> shipment/consignment (and I suppose at this point I should ask what 
>> is the difference between 'shipment' and 'consignment')?
>>
> a Port is any place that has a role in cargo movements.  generally 
> these are airports, sea ports, freight terminals, customs ports of 
> entry or mail exchanges.  Not sure why CCL does not call transhipment 
> ports, 'ports', but they will be.
>
> A shipment is how the commercial operators of a delivery see the 
> goods.  It is the seller/buyer's view of the event.  A consignment is 
> how the consignee/consignors and freight handlers see the event.  We 
> have spent a long time defining these.  Officialy UBL uses the 
> following definitions ...
>
> Shipment: An identifiable collection of one or more goods items to be 
> transported between the seller party and the buyer party. This 
> information may be defined within a commercial contract. A shipment 
> can be transported in different consignments (e.g., split for 
> logistical purposes).
>
> Consignment: An identifiable collection of one or more goods items to 
> be transported between the consignor and the consignee. This 
> information may be defined within a transport contract. A  consignment 
> may comprise more than one shipment (e.g., when consolidated by a 
> freight forwarder).
>>
>> _*For CertificateofOriginApplication:*_
>>
>> -- In CCL, there is a generic 'document' associated with each 
>> 'consignment', and also with each 'consignment item'.  Can there be a 
>> different COO (and possibly therefore COO Application) for different 
>> items in a consignment?
> yes, a consignment may contain items that have different origins and 
> therefore different certificates of origin.
>>
>> -- In CCL, there is nothing at all that seems to deal with COO other 
>> than a code that lets you specify that the 'document' associated with 
>> a 'consignment' or 'consignment item' is a COO (through UN CL 1001, 
>> 'Document Name Code' as the noted code list for 'Document. Type. 
>> Code).  If I can relate the CCL 'Document' to the 
>> CertificateOfOriginApplication then I can probably get relationships 
>> for a few of the COOApplication elements (status, issuer, etc), but 
>> not more specific items such as JobID, or even ApplicationStatusCode 
>> (I can get the 'document' status, but not the 'application' status, 
>> which would be different).
>>
> The CCL is not covering 'document types' as we know them.  It only has 
> Core Components.  CEFACT see document types as something else.  So we 
> should not expect to find ACCs for each document type.
>
> UBL does not have a document type called Certificate of Origin 
> Application. the UBL document type is Certificate of Origin.  This 
> contains an ABIE for Certificate of Origin Application.
>> -- This all leads me to wonder if COOApplication s/b a top level 
>> message, since it is the beginning of a transaction of document 
>> exchange, similar to initiating a procurement process with a PO.  
>> Then what you'd get back as a response, in the end, would contain the 
>> COO (or the COO would follow the culmination of a COOApplication 
>> exchange).  Does that make sense -- looking at the spec I would add 
>> the COOApplication document to the COO process map, because if it's 
>> important enough to track then it seems we should represent it 
>> somewhere?  I'm sure you guys have hashed this out already quite a 
>> bit, but just trying to figure out what the thinking was and how to 
>> map to CLL.  I looked for something that might have been a recent 
>> version of a COO requirements paper, but haven't found anything on 
>> line or in the distribution.  I do have something from Crimson Logic 
>> from 2004.  In there, they don't have an Application document either, 
>> but then they also don't have an Application Status, they have a COO 
>> Response.  Perhaps COO doc and COOA doc are one and the same, and we 
>> just might need to tighten up the terminology?  Could really use your 
>> guidance here!
>>
> If you look at the process diagrams there is no Certificate of Origin 
> Application.  There is always one Certificate of Origin Application in 
> each Certificate of Origin Document.  In effect they are one and the 
> same.  They are not separate document, as an application is endorsed 
> it becomes a certificate.
>> -- Last but not least, there appears to be a disconnect (or we could 
>> not find the connection) between the model of the relationship of 
>> COOApplication, EndorserParty, and Endorsement.  In the UML diagram 
>> for the Transportation Library, COOA is associated with 
>> EndorserParty, and EndorserParty is associated with Endorsement.  
>> However, in the spreadsheet model, while COOA contains an association 
>> with EndorserParty, EndorserParty does not contain an association 
>> with Endorsement.  Nothing does.  It's the other way around 
>> (Endorsement contains an association with EndorserParty).  Should 
>> COOA contain an association with Endorsement rather than 
>> EndorserParty?  Otherwise we're not understanding the linkage between 
>> Endorsement and the COOA or EndorserParty.
> The arrows in the UML give the answer.  'Containership' is only in the 
> direction the arrows point. So Endorser Party will not contain 
> Endorsement, but Endorsement will contain Endorser Party.  The reason 
> this is complex is because some Endorser Parties (Issues, embassy and 
> insurance) may also sign their endorsements.
>>
>>
>> That's it until we get past these few questions.
>>
> The problems with COO is that the CCL does not deal with it, so many 
> of these concepts are not in CCL yet.
>> Thanks for all your help!
>>
>> -Anne
>>
>>
>>