[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl-tsc] TSC Action Item followup from TC
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]