Re: [ubl-lcsc] UBL 1.0 draft 4 models in hand

[Tim McGrath <tmcgrath@portcomm.com.au>]

Stephen Green wrote:

>Greetings
>
>Sorry I was out of touch yesterday. The models are in hand. I've made the necessary changes to the GUID. I have only changed the Rep' term to 'Globally Unique Identifier' and changed the formula for column A to 
>
>=SUBSTITUTE(SUBSTITUTE(CONCATENATE(E5;F5;IF(G5<>K5;G5;"");CONCATENATE(H5;IF(I5="Identifier";"ID";IF(I5="Text";"";IF(I5="GloballyUniqueIdentifier";"GUID";I5)))));" ";"");"'";"")
>
>I've a few questions - the last of which is the most important:
>
>1) Should I change the formula for column K? It is currently:
>=IF(AND(OR(G6="Identification";G6="ID");I6="Identifier");G6;IF(AND(OR(G6="Time";G6="Date");I6="Date Time");G6;I6))
>2) In line with 1) I wondered if there might be an error in OrderCancellation where we have Date Time used. Here the data type still says 'Date', not Date Time (column K)
>
your questions have made me realise that the formula for columns J and K 
(Data Type Qualifier and Data Type) are now out of date.  

The purpose of these columns (J&K) is to map the names of CCTS types to 
our CoreComponentTypes.xsd names.  Now we have the additional 
supplementary Core Component Types we do not need to do anything as 
there is now a one-to-one mapping.  The only thing we have to do is 
remove the embedded spaces from the Representation term.  In fact, we 
may decide this need not be in the spreadsheet at all and the script can 
map them.

Furthermore, i then noticed that if we are prepared to sacrifice the use 
of the Property Term Noun 'Identification' and make it 'Identifier' 
(which it once was!) - the other formulaes are much simpler.  That is 
because this is now the only case of not-quite duplication of Property 
Term Noun and Representation term names (ie it generates Identification. 
Identifier).  See my attached example using the Order Cancellation model.

i think it is beneficial to go down this path - but i want us to discuss 
this on tuesday's call before making the changes.

>
>3) The most important matter is concerning the codelists again. Because of our mechanism (or perhaps just the nature of codelists themselves, to be more analytical) we have, it seems, to have a unique UBL name for each Code using a particular codelist. For example, we have different TypeCode entities, each using a separate codelist but they should have separately unique UBL Names so I feel I must try to qualify say 'CardAccount. TypeCode' to distinguish it from, say, 'TaxScheme. TypeCode'. Otherwise, there would be more than one TypeCode to reference in the reusable schema which isn't possible. They would end up as having the same codelist for each TypeCode which would obviously be wrong. Now the matter is not helped by our naming rules which do not seem to allow duplications of name parts. So I have to find a qualifier for 'CardAccount. TypeCode' other than 'Card' or 'Account' or we would have 'CardAccount. CardTypeCode' for te new name 'CardTypeCode'. Would the latter be OK? 
>
>For now I will just do my best with qualifiers.  
>  
>
i am not comfortable with inventing property term qualifiers just for 
this purpose.

isn't the solution here to use the ABIE/object class as well as the 
Property Term (both adjective and noun)?  this is safe and predictable.  
remember dictionary entry names (of which this is a derivation) are 
always unique, UBLNames are not. so the two examples you have would be: 
CardAccountTypeCode and TaxSchemeTypeCode.

>Beyond this I hope we have time to re-examine how our Order/OrderResponse system is working and get it sorted. Tim: I'm wondering why we seem to have no Acceptance or Rejection codes or indicators in the complex response when we have them in the simple.
>  
>
my understanding of the Order Response (Complex) is that it is a 
complete replacement of the original Order.  It does not need to accept 
or reject anything because it states what the seller will accept as the 
entire order.  the idea is that  this document is an unambiguous 
description of the entire state of the order transaction.  It has no 
history in it, except by reference to the original Order.  also, the 
seller has the option of offering substitute and/or replacement order 
items if they want to.  i think we decided that providing 
rejection/acceptance codes and reasons, plus the complex partial 
fulfillment/back ordering, etc. values all gets too hard.  

i seem to remember an argument that is EDI experience this was seen as 
the 80% solution - with the other 20% taking 200% more effort. 
 Unfortunately, Bill was the man of the hour for this baby so I may have 
missed the point.  if anyone else has some input then lets raise it soon 
as we need to decide this week.

>All the best
>
>Steve
>
>
>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/ubl-lcsc/members/leave_workgroup.php.
>
>  
>

-- 
regards
tim mcgrath
phone: +618 93352228  
postal: po box 1289   fremantle    western australia 6160

UBL-OrderCancellation-1.0-alpha-draft-4-newformulae.sxc