RE: [ubl-tsc] TSC Action Item followup from TC

["Andrew M Schoka" <AMSchoka@comcast.net>]

Audun,
Thank you for your comments regarding cancellation. We should look forward
to a report from Peter regarding PSC's view on this topic.
Regards,
Andy


-----Original Message-----
From: Audun Vennesland [mailto:Audun.Vennesland@sintef.no] 
Sent: Friday, January 13, 2012 1:26 AM
To: Andrew M Schoka; roberto@javest.com
Cc: 'Peter L. Borresen'; ubl-tsc@lists.oasis-open.org; 'Tim McGrath'; 'G.
Ken Holman'; bosak@pinax.com
Subject: RE: [ubl-tsc] TSC Action Item followup from TC

I also like the idea from Roberto on the DocumentStatusCode. We have been
working on the idea of having a TransportExecutionPlanStatusCode as a BBIE
in the Transport Execution Plan document, but this could easily be replaced
by a more generically named DocumentStatusCode BBIE. In addition you might
want to include a DocumentStatusReasonCode and a DocumentStatusReason (Text)
to include the possibility of adding an explanation of the
DocumentStatusCode. 

Best regards,
Audun

-----Original Message-----
From: Andrew M Schoka [mailto:AMSchoka@comcast.net]
Sent: 12. januar 2012 05:30
To: roberto@javest.com
Cc: 'Peter L. Borresen'; ubl-tsc@lists.oasis-open.org; Audun Vennesland;
'Tim McGrath'; 'G. Ken Holman'; bosak@pinax.com
Subject: RE: [ubl-tsc] TSC Action Item followup from TC

Thank you Roberto for your comments. I like the idea of adding a BBIE in the
Status ABIE that allows a code with an entry of something like "This is a
cancellation of this containing document."
And do you know if EDIFACT has a cancellation message?
Andy

-----Original Message-----
From: Roberto Cisternino [mailto:roberto@javest.com]
Sent: Wednesday, January 11, 2012 6:04 PM
To: Andrew M Schoka
Cc: 'Peter L. Borresen'; ubl-tsc@lists.oasis-open.org;
audun.vennesland@sintef.no; Tim McGrath; G. Ken Holman; bosak@pinax.com
Subject: Re: [ubl-tsc] TSC Action Item followup from TC

The invoicing process has the credit note for full/partial cancellation.

Let's say that a simple cancellation message is not sufficient for legal
documents if they have been already processed by the receiver.

The cancellation is quite common for:
- Bookings (not just in the shipping industry)
- Bill of Ladings
- Orders

In sectors like shipping/transport the "override" concept is often adopted
because the partial modification of a previous instruction/document is not
always a simple thing from the implementation point of view (so here I am
not talking about the message itself but how to process it once received).
The override is pratically used to cancel and substitute a previous message.

Maybe we could provide any UBL message with the possibility to "cancel" or
"override" the whole document or just a set of line items.

The Purchase Order can be used as a sample by inspecting the cac:LineItem
which offers a cbc:LineStatusCode.

Using its default UBL code list we can assert that the line status is: 
"Line has been cancelled".

See UBL 2.0 code list under cl/gc/default/LineStatusCode-2.0.gc

All UBL documents using the LineItem ABIE are ready for cancelling a set of
line items or even all of them.

Probably we could add a similar BIE on the document root named "StatusCode"
and pointing to a similar code list but for the whole document.

For instance: DocumentStatusCode-2.1.gc

Hope this helps,

Roberto


> Peter,
>
>
>
> At the last TC call I got the action to provide TSC requirements for 
> cancellation.
>
>
>
> Within the UBL Transport domain there are two primary processes each 
> having a subset of Transport documents/messages.
>
> 1.       Intermodal Freight Management
>
> 2.       International Freight Management.
>
>
>
> Within the community employing Intermodal Freight Management messages, 
> the opinion is that message content drives the processes, not the 
> message as an entity.  While most of the message types in this domain 
> are queries regarding status (which would not really require
> cancellation) the primary message is the Transport Execution Plan 
> (TEP). As a collaborative document, the TEP would cycle among 
> appropriate parties to finalize freight movement requirements.  If 
> cancellation were required it would most likely be enabled within a 
> cycle of the TEP and with a transport specific code type BBIE 
> containing a "cancelled" value embedded in the TEP.
>
>
>
> Within the community employing International Freight Management 
> documents/messages, the opinion is not as clear. There may well be a 
> requirement for cancellation, but only for specific message types.
> Since there is a serial nature to the process and the 
> documents/messages employed, the first document in the series, the 
> Forwarding Instructions document/message, may well have to be 
> cancelled in particular circumstances.
> A question I might ask, "Does EDIFACT have cancellation messages?"
>
>
>
> I suggest that you explore with the PSC a possible  editorial note to 
> be included in the PRD03 text that addresses the subject of 
> cancellation and its implementation in a way the permits use if the 
> implementation of their processes see a need. I welcome the 
> opportunity to
participate.
>
>
>
> I also encourage others reading this to offer an opinion.
>
>
>
>
>
> Regards,
>
> Andy Schoka
>
>
>
>
>
>
>
>


--
* JAVEST by Roberto Cisternino
*
* Document Engineering Services Ltd. - Alliance Member
* UBL Italian Localization SubCommittee (ITLSC), co-Chair
* UBL Online Community editorial board member (ubl.xml.org)
* Italian UBL Advisor

  Roberto Cisternino

  mobile: +39 328 2148123
  skype:  roberto.cisternino.ubl-itlsc

[UBL Technical Committee]
    http://www.oasis-open.org/committees/ubl

[UBL Online Community]
    http://ubl.xml.org

[UBL International Conferences]
    http://www.ublconference.org

[UBL Italian Localization Subcommittee]
    http://www.oasis-open.org/committees/ubl-itlsc

[Iniziativa divulgativa UBL Italia]
    http://www.ubl-italia.org


-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.1901 / Virus Database: 2109/4736 - Release Date: 01/11/12

-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.1901 / Virus Database: 2109/4740 - Release Date: 01/13/12