OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-lcsc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ubl-lcsc] Code sets for Document and LineItem Status


Hi Tim,

In the Catalogue, Sue has put integers in the "Example Values" column,
and then strings in the "Actual Values" column.  I'm not sure how to
interpret this.  I do agree that using numeric is more portable.

I just found, in Sue's spreadsheet, pointers to two other code lists for the
Document and Line Status(es) (I just sent this info separately to Stephen).
I didn't notice these at first because they were not marked as "standard"
in either spreadsheet.  I should have looked more closely.

 From http://www.unece.org/trade/untdid/d03a/tred/tredi2.htm check out
1225 (Message Function Code) and 1229 (Actrion Request Notification
Description Code).  Sue has designated the former for the DocumentStatus
and the latter for the LineStatus.

This system seems a bit obscure, though.  The title of 1229 would never have
led me to believe that this was to be used for line items.  The 
organization is
also rather circular.  Note that the codes listed at the aboove url can 
also be
accessed from the link http://www.unece.org/trade/untdid/d96a/uncl/uncl1225)
but some of the codes on the latter ulr are named differently than the index
file has them listed on the '.../tred/tredi2.htm' site (eg 8339).  I 
have the
feeling that the system is a bit fragile, but perhaps it's just in a 
transition period.

At any rate, we now have a few other candidates for values if we want
to consider these: "Change (4)", "Replace (5)" or "Reissue (18)", and
"Cancellation (1)" for DocumentStatus.  There's also 'Seller Initiated
Change', 'Change in header', or 'Change in detail'.  Sue has listed
'Unchanged', but I can't find that in either of these two code lists.

For LineItemStatus there is "No Action(4)", "Added (1)", "Deleted (2)",
and "Changed (3)".

Feel free to use any of the others in the code list though.
FYI, these are different than the values in the current Catalogue.
For some reason, the values currently in the Catalogue do not match
values in either of these given code lists.

-A

Tim McGrath wrote:

> So do we use...
>
>'No Status'
>'Revised'
>'Withdrawn' 
>(but I'd rather 'Cancelled' which we don't seem to have here) 
>and
>'Disputed'
>
>or  their corresponding numeric codes?
>
>"16"
>"36"
>"40"
>and
>"90"
>
> If we use the numeric codes it fixes your concern about 
> Withdrawn/Cancelled and allows for language independent mapping of 
> descriptions.  I suspect that is why the UN/EDIFACT does it that way.
>
> Stephen Green wrote:
>
>>Hi
>>
>>I agree that 1373 isn't appropriate to what we are calling DocumentStatusCode, despite the name similarity - the 1373 is obviously for use in refering in one document to a second document (say for 'InvoiceDocumentStatusCode' in a despatch advice so that the sending can inform the recipient that the invoice will be sent on paper). We however are using a status code to give information about either the document or line that actually contains the code or about a refernced document (or a line in it) that was already sent. So I'd say we could use 4405 but we'd have to carefully restrict the values used. A typical use would be to distinguish in an OrderChange between changed and unchanged lines or to say that the document was chnaged at document / not line level. For this we would need just 'No Status', 'Revised' (or 'Replaced' but preferably just one or the other) and, for the nearest thing perhaps to Cancelled, 'Withdrawn'. [Any more and developers might be at a loss to decide w
>>hat to do with each case, adding to the cost of development and falling short of our 80:20 goal.] These few should cover the main needs of the status codes in a despatch advice. We needn't add rejected for recipt advice since we already have an indicator for that. 'Disputed' would be useful though. 
>>
>>I'd suggest just 
>>
>>'No Status'
>>'Revised'
>>'Withdrawn' 
>>(but I'd rather 'Cancelled' which we don't seem to have here) 
>>and
>>'Disputed'
>>
>>from UN/CL 4405
>>
>>All the best
>>
>>Steve
>>
>>  
>>
>>>>>Tim McGrath <tmcgrath@portcomm.com.au> 10/15/03 16:51 PM >>>
>>>>>        
>>>>>
>>I am promoting this thread to the list as it may interest several others.
>>
>>Anne endry wrote:
>>
>>  
>>
>>>Well, this is very interesting.  UN Code 1373 seems to me to be 
>>>somewhat limited.
>>>It does fullfill the base requirements, but if we wanted to expand the 
>>>values, are the
>>>ones listed there ones we would consider to be useful in our (even 
>>>limited) context?
>>>
>>>What about 4405 (Status Description Code), also available at that site 
>>>(the second
>>>URL in the email below) which has many more choices such as "Started", 
>>>"Revised",
>>>"Approved", "Withdrawn", "Replaced", "No Status", "Draft Version", 
>>>"Not Accepted",
>>>"Confirmed", "Adjusted", "Disputed", "Active", "Partial", "Adjusted", 
>>>"Complete",
>>>"Started", as well as "Ratified" and "Contracted", "Settled" (so has 
>>>legal states as well) etc.
>>>(Of course, then you also have to deal with "Washed" and "Unwashed"! 
>>>:) But it's
>>>certainly no scrappier than 1373, and at least the relevant choices 
>>>are greater.
>>>
>>>Is this moving in a direction that would be frowned upon, though?  I 
>>>mean if there
>>>is a code whose title specifically relates it to a document process, 
>>>how important
>>>is it to only use those?  I'm not sure what the difference was in 
>>>intent when creating
>>>the "Document Status Code" vs. the "Status Description Code".  It 
>>>seems that the
>>>latter is more general, and could be more easily used for line items, 
>>>as it talks about
>>>"items" in some of the descriptions, such as "Withdrawn" and 
>>>"Rejected", whereas
>>>1373 seems to be dealing more with a physical documents.  
>>>    
>>>
>>
>>i agree that the generic Status Description Code may be more useful. The 
>>term Doucment does refer to the printed version (rather than the 
>>transaction).  In which case we may end using the same code set values 
>>(4405) for two UBL code sets (DocumentStatus and LineItemStatus).  i 
>>dont think this is a problem.
>>
>>  
>>
>>>Or possibly the "Document"
>>>code list was derived as a constraint on the more general status 
>>>codes, but that they
>>>wern't fully fleshed out?  Or that they were early codes (note 4 and 
>>>6 - sent by
>>>EDI means, not sent by EDI means) and not used as much now?  How is 
>>>one to
>>>tell which of these is the more common set in use?
>>>    
>>>
>>
>>voodoo - the web site show has a cross reference table showing the 
>>components that use these codes.  4405 wins  in its number of 
>>appearances, though that doesn't guarantee usage.
>>
>>  
>>
>>>FYI, the only code dealing specifically with an individual line item 
>>>(other than the
>>>codes in 4405) is "Document Line Action Code", which only has two values
>>>"Included" and "Excluded".
>>>    
>>>
>>
>>i noted that and dont see it as relevant.  again, we have to be careful 
>>about the names used here and the UBL names we use.  we should not be 
>>too tied into the code name, rather its values.
>>
>>  
>>
>>>BTW, there are a few line status codes that have been developed by others
>>>(found on the web) so we could cop those if nothing here suits that 
>>>application.
>>>The beauty of 4405 is that I think it could be applied to lines 
>>>equally as well
>>>as to documents.
>>>    
>>>
>>
>>i dont want to stray from the UN CL path too far.  You have put up a 
>>good argument for 4405.  i suspect Sue would agree.  So if Stephen is 
>>happy then lets run with that.
>>
>>  
>>
>>>Let me know what you think of this.
>>>
>>>-A
>>>
>>>Tim McGrath wrote:
>>>
>>>    
>>>
>>>>I think they should be set back to 'Standard'.  We now have sources 
>>>>for these.
>>>>
>>>>As far as i can see the code set values we can get from the UN CL are 
>>>>at...
>>>>
>>>>http://www.unece.org/cefact/trafix/bdy_code.htm - these should be 
>>>>'standard'
>>>>
>>>>For the other 'standards' that we believe are essential, we can use 
>>>>the UN recommendations that are built into the EDIFACT library (the 
>>>>latest version is at 
>>>>http://www.unece.org/trade/untdid/d03a/tred/tredi2.htm ).  These 
>>>>should be our starting point.
>>>>
>>>>For example, our Document Status Code (and possibly Line Status Code) 
>>>>should be based on UN code 1373 (Document Status Code). 
>>>>However,as we see from this list, it is a fairly crappy mixture of 
>>>>all sorts of Document Status's (or is that Document Statii?)
>>>>
>>>>    1     Accepted
>>>>             The specified document is accepted.
>>>>    2     Accompanying goods
>>>>             Notice that a specific document will be accompanying the
>>>>             goods.
>>>>    3     Conditionally accepted
>>>>             The specified document is conditionally accepted.
>>>>    4     To arrive by separate EDI message
>>>>             Notice that a specific document/message will be
>>>>             transmitted via a separate EDI message.
>>>>    5     Information only
>>>>             Notice that the specific document or message is for
>>>>             information only.
>>>>    6     To arrive by manual means
>>>>             Notice that a specific document or message will not be
>>>>             sent via EDI.
>>>>    7     To be raised and sent
>>>>             Request for a specific message to be formatted and
>>>>             transmitted or a request for a specific document to be
>>>>             raised and sent.
>>>>    8     Rejected
>>>>             The specified document is rejected.
>>>>    9     To be printed
>>>>             The document or message is to be printed.
>>>>    10    Document currently valid
>>>>             Specific document is currently valid.
>>>>    11    Document not available
>>>>             Specified document is not available.
>>>>    12    Document exhausted by declaration and attached
>>>>             Customs declaration to which the document is related
>>>>             completed or exhaust the allowance stated on the
>>>>             document. The document is attached to the Customs
>>>>             declaration.
>>>>    13    Document not exhausted by declaration and attached
>>>>             Customs declaration to which the document is related
>>>>             does not complete or exhaust the allowance stated on the
>>>>             document . The document is not attached to the
>>>>             declaration bu has already been lodged in the Customs
>>>>             station.
>>>>    14    Document exhausted by declaration and previously lodged
>>>>             Customs declaration to which the document is related
>>>>             completed or exhaust the allowance stated on the
>>>>             document. The usage of the document is complete. The
>>>>             document is not attached to the declaration but has
>>>>             already been lodged in the Customs station.
>>>>    15    Document not exhausted by declaration and previously lodged
>>>>             Customs declaration to which the document is related
>>>>             does not complete or exhaust the allowance stated on the
>>>>             document. The document can continue to be used for
>>>>             future declarations until the allowance is exhausted.
>>>>             The document is not attached to the declaration but has
>>>>             already been lodged in the Customs station.
>>>>    16    Document not attached
>>>>             Specified document is not or cannot be attached.
>>>>    17    Document with the goods
>>>>             Document not attached to the Customs declaration but is
>>>>             attached to the goods.
>>>>    18    Document attached, to be returned after endorsement
>>>>             Specified document is attached to the Customs
>>>>             declaration and will be required to be returned to the
>>>>             declarant after Customs endorsement.
>>>>    19    Document applied for
>>>>             Application has been submitted for that document.
>>>>    20    Received for shipment
>>>>             Indicates that the document has legal validity from the
>>>>             date of receival of the cargo.
>>>>    21    Shipped on board
>>>>             Indicates that the document has legal validity from the
>>>>             date that cargo is loaded on board a vessel.
>>>>    22    Status 0
>>>>             Message is at status 0.
>>>>    23    Status 1
>>>>             Message is at status 1.
>>>>    24    Status2
>>>>             Message is at status 2.
>>>>    25    Message under development
>>>>             Message is under development.
>>>>    26    Document not freighted
>>>>             Document not to include freight figures.
>>>>    27    Document freighted
>>>>             Document to include freight figures.
>>>>    28    Archived
>>>>             The document or message has been archived.
>>>>    29    Provisional
>>>>             The document or message has no official status.
>>>>    30    Documents enclosed in the first transmission
>>>>             The documents are enclosed in the first transmission.
>>>>    31    Documents enclosed in the second transmission
>>>>             The documents are enclosed in the second transmission.
>>>>    32    Document not required, waiver issued
>>>>             The document is not required, waiver of requirement has
>>>>             been issued.
>>>>    33    Already on file with receiver of this message
>>>>             The document is already on file with the party receiving
>>>>             the message.
>>>>    34    Retained by sender of this message, or by sender's agent or
>>>>          representative
>>>>             The document is in the possession of the sender or
>>>>             sender's agent or representative.
>>>>    36    Document previously submitted
>>>>             The document has already been submitted.
>>>>
>>>>So for the minimum Stephen requires we would use...
>>>>
>>>>    1     Accepted
>>>>             The specified document is accepted.
>>>>    3     Conditionally accepted
>>>>             The specified document is conditionally accepted.
>>>>    8     Rejected
>>>>             The specified document is rejected.
>>>> 
>>>>
>>>>I realise that  '3' is not terribly intuitive or even precisely what 
>>>>we mean by 'Revision', but that is the price of international 
>>>>alignment.  international in the sense that the language is not 
>>>>significant and alignment  in that we may need to compromise on the 
>>>>wording.
>>>>
>>>>Fortunately, I thinkwe have some flexibility here.  With these 
>>>>EDIFACT codes, we can be 'based upon' .  So a middle ground would be 
>>>>to use the 'short description' e.g. the words 
>>>>"Accepted","Conditionally Accepted" and "Rejected".  I think this is 
>>>>better than inventing our own terms.
>>>>
>>>>I suggest we delegate these case-by-case decisions to Stephen and 
>>>>Anne, but they are welcome to sound out the list for opinions if they 
>>>>want to.
>>>>
>>>>
>>>>
>>>>Stephen Green wrote:
>>>>
>>>>      
>>>>
>>>>>I'd better quickly point out that I changed those codes for which 
>>>>>Sue had suggested UN Lists which were previously Standard to 
>>>>>Placebo, because of the argument that these should use the external 
>>>>>lists but that we couldn't necessarily (at the time) provide values 
>>>>>or external codelists for these. Idealy of course they should be 
>>>>>Standard and we should provide values or an external codelist. This 
>>>>>certainly applies to DocumentStatusCode and LineStatusCode (I really 
>>>>>need values for the latter -at least 'Unchanged' 'Revision' and 
>>>>>'Cancellation' if we can get no 'official' values) and ChannelCode.
>>>>>
>>>>>Steve
>>>>> 
>>>>>
>>>>>        
>>>>>
>>>>>>>>Chin Chee-Kai <cheekai@softml.net> 10/14/03 18:07 PM >>>
>>>>>>>>      
>>>>>>>>              
>>>>>>>>
>>>>>Anne, for your processing.
>>>>>
>>>>>Bill, for your checking-in.
>>>>>
>>>>>Stephen, Tim, FYI pse.
>>>>>
>>>>>Thanks.
>>>>>
>>>>>
>>>>>
>>>>>Best Regards,
>>>>>Chin Chee-Kai
>>>>>SoftML
>>>>>Tel: +65-6820-2979
>>>>>Fax: +65-6743-7875
>>>>>Email: cheekai@SoftML.Net
>>>>>http://SoftML.Net/
>>>>>
>>>>>
>>>>> 
>>>>>
>>>>>        
>>>>>
>>>>-- 
>>>>regards
>>>>tim mcgrath
>>>>phone: +618 93352228  postal: po box 1289   fremantle    western 
>>>>australia 6160
>>>> 
>>>>
>>>>
>>>>      
>>>>
>>>    
>>>
>>
>>  
>>
>
>-- 
>regards
>tim mcgrath
>phone: +618 93352228  
>postal: po box 1289   fremantle    western australia 6160
>  
>
>




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]