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

[Tim McGrath <tim.mcgrath@documentengineeringservices.com>]

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
>
>
>
begin:vcard
fn:Tim McGrath
n:McGrath;Tim
org:Document Engineering Services Ltd.
email;internet:tim.mcgrath@documentengineeringservices.com
title:Managing Director
tel;work:+61 438352228
tel;cell:+61 438 352228
url:www.documentengineeringservices.com
version:2.1
end:vcard