[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl] Approach to reporting scemantic errors on an invoice. Any advice?
Just to clarify; "Messaging protocol signal" = something to do with transport & routing and the quality of service that goes with that. ebXML MS ack is an example of that. At the highest level, messaging provides routability, reliability, & security but NOT business state alignment. "Business protocol signal" = something that sits above the messaging layer but is independent of the specific business process (eg invoicing, ordering, etc). To the message handler it looks just like any other business document. The purpose of this message is transaction and/or collaboration state alignment. BPSS provides examples of three types of "business signal" - receipt acknowledgement, acceptance acknowledgement, exception. These are all to do with aligning state at both ends. In the Danish case, what is needed is a way to communicate a semantic failure for an invoice transaction. Typically because some data in the invoice is not valid (eg account number not known...). The thing about business signals is that they do not depend on the process - a receipt acknowledgement signal is the same whether it is used to acknowledge a PO or an invoice. "Business Document" = something that carries business data to change the state of an entity. Eg a UBL invoice. "Business Transaction" = a request document and an option response document that together form an atomic (either completes or does not) business activity. It is commonly accepted that all possible transaction fall into one of 6 "patterns". "Business Collaboration" = a long running collaborative process that includes one or more transactions to complete a process between two or more parties. My understanding is that Mikkel needs a way to complete the invoice transaction with either a positive or negative outcome that is understood by both parties. To my mind that is a single transaction of the "notification" pattern that requires a single request document (the invoice) plus a receipt acknowledgement business signal and then either an acceptance acknowledgement signal or an exception signal. Other business documents like a "statement" or a "debit note" or a "remittance advice" should not be used to indicate rejection of a single invoice because they are really part of a separate transaction. There is no 1:1 correlation between an invoice and a statement ore remittance. If my understanding of the requirements is right then what is needed is a "business transaction protocol" layer above the messaging layer and below the collaboration layer. If so then Mikkel needs to look to a specification like ebXML BPSS and not to UBL for a new document. Regards, Steve Capell Red Wahoo www.redwahoo.com p: + 61 2 9438 3700 m:+ 61 410 437854 f: + 61 2 9439 2738 This email message and any accompanying attachments may contain information that is confidential and is subject to legal privilege. If you are not the intended recipient, do not read, use, disseminate, distribute or copy this message or attachments. If you have received this message in error, please notify the sender immediately, and delete this message. Any views expressed in this message are those of the individual sender, except where the sender expressly, and with authority, states them to be the views of Red Wahoo Pty. Ltd. Before opening any attachments, please check them for viruses and defects. We do not accept any liability for loss or damage which may arise from your receipt of this e-mail. -----Original Message----- From: Tim McGrath [mailto:tmcgrath@portcomm.com.au] Sent: Wednesday, 13 April 2005 6:04 PM To: Mikkel Hippe Brun Cc: 'ubl@lists.oasis-open.org' Subject: Re: [ubl] Approach to reporting scemantic errors on an invoice. Any advice? I agree with Steve Capell - the requirement is not completely clear. But if we were to assume that what you need is another UBL document type and not a messaging protocol signal then there is currently a proposal to introduce several additional document types for UBL 1.1 Billing process. The European Government Agency's UBL collaboration group has had a long discussion about the value of an Invoice Response document type. They currently recommended not introducing this document because of the commercial complexities (and taxation issues) that may result. I guess it is not as simple as the Order-Order Response pattern. Rather they recommend using a Debit Note sent from the Buyer to the Seller, stating that Buyer has deducted amounts from a Sellers Invoice. In situations where a Buyer and Seller have agreed to the use of a Debit Note, a Debit Note obviates the need for the Seller to create a Credit Note. My interpretation of this is that the Debit Note forms a kind of business-level negative acknowledgement. It is used to communicate variance between what was Invoiced and what the payee intends to pay. Its key advantage is that is a recognized VAT document. However, I am only an observer of this debate so others may have more to add. The UBL 1.1 process model also introduces a Statement document type which could provide further reconciliation if necessary. For the complete model see the notes attached to... http://lists.oasis-open.org/archives/ubl/200503/msg00038.html The models for these new document types are being rationalized over the next few weeks so it would be useful to get you input into their suitability for your requirement. Hope that helps. Mikkel Hippe Brun wrote: >Dear TC, > >As you may know - we have implemented the UBL invoice based on 0p7 in the >public sector. More than one million invoices has been exchanged since >February 1th. The technical infrastructure is based on a VANS-network (5 >operators). The addressing mechanism is using EAN-location numbers. > >The VANS network operates with a primitive "Acknowledgment Message". It is >similar to the functionality of ebMS "AckRequested" and "Acknowledgment" >between message handlers. We will now implement most of ebMS in the VANS >network. > >My problem is that we lack a mechanism to report scemantic errors and other >kinds of rejects to the invoice. It seems like ebMS is not suitable and >should not be used for "business-level acknowledgments". We need an >InvoiceResponse type message. Any advice to what path we should follow? > >Best regards > >Mikkel Hippe Brun >Chief Consultant, M.Sc. >Phone: +45 3337 9220 >Cell: +45 2567 4252 >E-mail: mhb@itst.dk > >National IT and Telecom Agency >Office of IT Strategy >Holsteinsgade 63 >DK-2100 Copenhagen Ø >Denmark >Phone: +45 3545 0000 >Fax: +45 3545 0010 >www.itst.dk >itst@itst.dk > >--------------------------------------------------------------------- >To unsubscribe from this mail list, you must leave the OASIS TC that >generates this mail. You may a link to this group and all your TCs in OASIS >at: >https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > -- regards tim mcgrath phone: +618 93352228 postal: po box 1289 fremantle western australia 6160 DOCUMENT ENGINEERING: Analyzing and Designing Documents for Business Informatics and Web Services (coming soon from MIT Press) http://mitpress.mit.edu/catalog/item/default.asp?sid=632C40AB-4E94-4930-A94E -22FF8CA5641F&ttype=2&tid=10476 --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]