[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-lcsc] For Review: Code List Defaults
Anne
I think we should probably change in ChannelCode "text" to "SMS" but maybe we would then need to add SMS to NDRSC's abbreviations list (I'd say a code should qualify for naming rules similary, though perhaps not identically, to a BIE).
I've some reservations about ChannelCode since it would seem that it limits the reusability of the Communications ABIE. We are presently only using it to supplement a few Contacts BBIEs for e-mail, phone and the like. However, on the one hand, to prevent multiple ways of providing an e-mail address, say,
one should only have e-mail as either a BIE or a code value but not both, while on the other hand one would want the ChannelCode list to be complete (e.g. e-mail, fax, phone and SMS as a core set of values) to allow reuse without the need for those BIE's. These two are obviously mutually exclusive. One resolution would be to drop the BIE's from Contact and just have the code/codelist while adding the BIE values to the codelist. Another would be to accept that reusability would be limited to other ABIEs which have BIEs similar to Contact. I guess we are heading for the second. It might be seen as an advantage of the latter that one isn't so tied to using the codelist. Otherwise the adding of e-mail, phone and fax to the codelist and the dropping of the BIEs from Contact would seem to have advantages too in better reuse for the UBL library of BIEs provided one is happy with the codelist.
I do wonder whether using codelists might in any way preclude some of the advantages of the Core Component architecture - is the latter as supportive of code values as it is ofBIEs? If not, one might be losing something by not finding BIE alternatives to codes (e.g. by using Identifiers where possible instead as with the AllowanceCharge.ChargeIdentifier replacing an AllowanceCharge.AllowanceChargeCode) wherever possible. I'd question whether the cost of using codes is a reduction in interoperability as would have better been enabled with BIEs based on Core Components. Perhaps this can be offset with DataType use though - I look forward to finding out.
All the best
Stephen Green
>>> "Stephen Green" <stephen_green@bristol-city.gov.uk> 10/21/03 21:31 PM >>>
Anne
As far as DocumentStatusCode and LineStatusCode are concerned, for now all I would want to see is four values for each codelist, actually the same in each codelist (why two codelists then? ...)
(Values were loosely made similar to a small subset of 4405 names.
Descriptions are given in square brackets and values in quotes.)
DocumentStatusCode[Identifies the status of the document with regard to its original state.]:
"Revised"[a revision has occurred to all or part of the document from its original state], "No Status"[no change to the document has occurred with regard to its original state], "Cancelled"[the document has been cancelled in its entirety], "Disputed"[the document or part of it is in dispute with regard to its original state]
LineStatusCode[Identifies the status of the line with regard to its original state.]:
"Revised"[change has occurred to the line from its original state], "No Status"[no change to the line has occurred with regard to its original state], "Cancelled"[the line has been cancelled], "Disputed"[the line is in dispute with regard to its original state]
The descriptions added to the codes and codelists are in the format for the Catalogue spreadsheet as was agreed on the call today.
The looseness with which these code values have been aligned with or made similar to UNCL code names is partly due to the perceived difference of purpose and/or maning between the UBL StatusCode and the that of the UNCL codelist(s). The former has the purpose of providing data about the business data held in the document either at document level or at ine level with regard to chnages that may have been made to the content of that data, in particular since a previous issuing of that data (whether in the same document type as with a receipt advice that might have needed correction say or in another document type such as an order when the StatusCode is part of an order change).
General Note Following LCSC Call
LCSC has discussed that while we should endevour to use the UNCL codelists (even if just the names rather than the numeric values) we can only do so when we are sure that there is sufficient closeness of both meaning and purpose. Otherwise, when the codes concerned are critical to the basic functioning of UBL or obviously require consistency of meaning and use across general implementations (rather than within specific trading-partner agreements), then UBL will create its own code values, perhaps in as similar as possible a to way to that by which it has created its BIEs.
In the case of the latter, it was decided:
1) that descriptions will be required to supplement those code values, similarly to the fact that descriptions accompany the BIEs. How this is implemented is still to be considered.
2) The values themselves will be provided in upper camel case.
3) It is hoped that they will as extensible as the rest of the models and schemas.
All the best
Steve
>>> "Stephen Green" <stephen_green@bristol-city.gov.uk> 10/21/03 13:19 PM >>>
Anne
AllowanceChargeReasonCode, CancellationReasonCode and OrderRejectionReasonCode:
We have to distinguish the reason codes from codes specifying whether something is this or that - i.e. a few of the codes aren't there to say 'whether' but 'why'. For this reason I'd reject 5463 for the allowance code (it states whether we have allowance or charge and UBL has an indicator for that) - what we need i a set of reasons for say, discount (allowance) e.g. 'trade discount' and combined with the same codelist a set of reasons for a charge. http://www.unece.org/trade/untdid/d96a/uncl/uncl5189.hm may suffice, perhaps, for charge reasons but seems very weak for allowances (discounts, etc.). I'd suggest perhaps 4465 which at least has things like 'cash discount' and a relevant codelist name
I wouldn't like 4343 for reasons for cancellation or for OrderRejectionReason - it specifies the 'whether' rather than the 'why'. Perhaps 4405 is OK but i'd need more time to consider it. It has some very funny members like "Tooth wedged between another tooth and the jaw". It might have relevance to the Status Codes but I think we'd have to be careful and it would take some time to select the right subset.
Now I look again at 4465 I'd say it would be good for AllowanceChargeReasonCode,
CancellationReasonCode and OrderRejectionReasonCode and *joy* I reckon we can take the whole list!
How's that - if you're happy and the SC is too - I'd say we go for TRED 4465 http://www.unece.org/trade/untdid/d03a/tred/tred4465.htm for the three codes AllowanceChargeReasonCode, CancellationReasonCode and OrderRejectionReasonCode.
I'll need more time to look at the others, e.g. status codes.
All the best
Steve
>>> Anne Hendry <anne.hendry@sun.com> 21/10/03 02:43:15 >>>
Hello Stephen,
Thanks very much for this list. Here is what I've come up with:
For AllowanceCharge:
Reference in the aggregate 'Allowance or Charge Code Qualifier'
(http://www.unece.org/trade/untdid/d96a/trsd/trsdalc.htm) are
5463 and 5189. I tend to think 5189 is best suited to what you're
trying to accomplish with the message, but take a look and see what
you think. I'll pull the values from whichever one you think is
best suited,
http://www.unece.org/trade/untdid/d96a/uncl/uncl5463.htm
or http://www.unece.org/trade/untdid/d96a/uncl/uncl5189.htm)
For CancellationReasonCode"
For both of these Sue has a UNCL 433
(http://www.unece.org/trade/untdid/d96a/uncl/uncl4343,
code listed in the Catalogue, but she has also has a question mark
after it and the values in the 'actual values' column arenot in
that code, and I can't see any values in it that might suffice for
these codes, so in looking for something we can use I've come back
to 4405 (http://www.unece.org/trade/untdid/d03a/tred/tred4405.htm
or http://www.unece.org/trade/untdid/d96a/uncl/uncl4405.htm
depending on your viewpoint) which is in a lot of these Composite
code classifications and has "Order or Request Cancelled" and
along with many other values that could be utilized, depending
on our context. Please take a look a both of these, though,
and let me know which is most useful to you at this time.
For CountryIdentificationCode:
ISO 3166. Done by Jon. Should this be changed to "Standard"?
For CountrySubentityCode:
In the Catalogue, this item is noted as being ISO 3166 as well.
However, I'm not sure if this would be what was intended.
Problem is that there is nothing I've seen that has the term
"Subentity" in ISO 3166.
What there is under the UN LOCODEs are:
- "Subdivision"s, which for the U.S., for example, would be
states (eg. California) and for the U.K. would be,
for example, Essex
and
- "Location"s, which seems to contain cities
(eg. San Francisco, London).
When we use "Subentity", to which of these might we be referring?
For CurrencyCode:
Provided by Jon.
Now, there was a discussion beginning with Tim's email on 5 October
on which source to use for these, and the Catalogue currently says
'UNECE 9', which can be found at
http://www.unece.org/cefact/rec/rec09/rec09/1996_ecetrd203.pdf
or http://www.unece.org/cefact/rec/cocucod.htm and seem slightly
different than what Jon has posted from BSI/ISO. At this point
I'm assuming we will update the Catalogue rather than the lists.
Is this a concensus?
Jons earlier email he suggested the three codes above be used
as the raw material for "Stock" codes (rather than "Standard").
Right now the Catalogue also shows them as being "External Placebo".
Let me know if these should be anything other than "Standard".
For OrderRejectionReasonCode:
I assume there this is rejection by the Seller of the Order
rather than by the Buyer? Now here I would go back to UNCL 1229,
http://www.unece.org/trade/untdid/d03a/tred/tredi1229.htm (which we
discussed
earlier as Sue had it noted for the LineItemStatusCode) or even
4465 (see next bullet below) rather than 4343, as currently
indicated in the Catalogue (albeit with a question mark).
But take a look at these and let me know what you think.
I just don't see anything in 4343 that seems like it would work
and the values that Sue has listed in the "Actual Values" column
for this code are not availablel in 4343.
What is available in 1229, though, that seems useful, are codes
such as "Cancelled", "Replaced", and even "Not Accepted - This
line item is not accepted by the Seller", as a fallback.
Also, 4465 (below) seems mainly from the Buyer's point of view,
or it would work as well. If this is not a Seller-only rejection
possibility, then you might consider 4465 as noted below.
Also, please take a look at "Adjustment Reason Code", as it may
suffice for a couple of these. This is where it gets a bit scary,
though, as you can see between the two URLs below that UNCL is
truly under construction. The two pages, both named 4465, and
obviously the same code list, but they have different descriptions
so far, as it appears the UNCL one is just being populated:
(http://www.unece.org/trade/untdid/d96a/uncl/uncl4465 and
http://www.unece.org/trade/untdid/d03a/tred/tred4465.htm).
This is also the case for 1229. Because of this I will keep
the URL references to the tred site URLs for now.
For DocumentStatusCode:
4405: "No Statu" (45)
"Revised" (36)
"Withdrawn" (40) | "Order or request Cancelled" (64) |
"Terminated" (105)
"Disputed" (90)
or
1225: "Change" (4)
"Replace" (5)
"Cancel, to be reissued" (17)
For LineItemStatusCode:
4405: "Revised" (36)
"No Status" (45)
"Withdrawn" (40)
[Not sure if you need "Disputed" at line level.]
or
1229: "Added" (1)
"Deleted" (2)
"Changed" (3)
Caveat:
There is a high likelihood, given that the UNCL codes are
under development, that some of this may end up changing
in the future if we move to support UNCL-only codes,
since it seems that the TRED codes are not being adopted
wholesale by UNCL, but the UNCL codes are in flux. If the
UNCL codes were to be completed before FCS, we may want to
revise some of these codes to align competely with UNCL.
That is just not possible at the moment given the state
of the UNCL lists.
Version information:
As we discussed in the last call, the UNECE codes
(unece.org/trade/untdid/...) do not have version information
attached to the documents. Tim mentioned that the versions
are embedded in the URL. Should we add this info to the
'Version' column, then? If so, I need to be able to know
how this is represented in the URL and we should prossibly
explain this somewhere as it could be automatically generated,
if that is the case (that there is a predictable pattern to it).
Interesting note:
http://www.unece.org/trade/untdid/d96a/uncl/uncl3055.htm holds
a large list of acronyms for organizations. Is this something
that we would take in to UBL as part of the acronym list?
-A
Stephen Green wrote:
>Hi
>
>The following are codelists for which I would like to see either default (preferably) or stock (with placebo default) given values:
>
>AllowanceChargeReasonCode
>CancellationReasonCode
>CountryIdentificationCode
>CountrySubentityCode
>CrrencyCode
>OrderRejectionReasonCode
>
>The reason in most cases is that these are codes
>needed for basic use of UBL, not for specialised
>uses particulrly. For instance, it would be fairly essential for the use of the Order Cancellation to
>have values for the Cancellation Code. Similarly the
>OrderRejectionReasonCode.
>
>The following should revert to 'Standard' now since
>the reason for their being made placebo or stock is less appropriate. This is so that their values can be
>kept consistent across utilisations / implementations of UBL, essential to their effective use.
>
>DocumentStatusCode
>LineStatusCode
>
>All the best
>
>Stephen Green
>
>
>
>>>>Anne Hendry <anne.hendry@sun.com> 10/17/03 18:38 PM >>>
>>>>
>>>>
>Hello,
>
>Here is a file containing just the codelist Namespace name,
>Definition Default value, and its Ownership, taken from the
>current Code List Catalogue.
>
>The AI from today's meeting is to review these items to determine
>which of them should be designated as "Standard" for the Definiton
>Default. The description of "Standard" and the other possible
>options ("Placebo", "Stock", and "Private-Use") are at the end
>of the list.
>
>Please send comments to the LCSC list.
>
>Thanks,
>Anne
>
>
>
>
>
>
>
>
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.
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]