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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

[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]