[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-tsc] TSC Telecon 8 Jan 09 7pm EST
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]