RE: [ubl-dev] Invoice Type Code

["Sylvia Webb" <swebb@gefeg.com>]

Stephen,

Do you interpret the scope of the UBL Invoice to exclude the ability to send
corrections? A correction may not involve a debit or credit. In this
instance, you would want to reference the original incorrect invoice number.

Thanks,
Sylvia 


-----Original Message-----
From: stephen_green@seventhproject.co.uk
[mailto:stephen_green@seventhproject.co.uk] 
Sent: Tuesday, September 07, 2004 9:26 AM
To: ubl-dev@lists.oasis-open.org
Subject: Re: [ubl-dev] Invoice Type Code



Oriol

Oriol Bausà <oriol@tradise.com> wrote on 07.09.2004, 13:17:43:
> We are implementing different UBL Invoice instances in an ERP system. 
> We have the commercial invoice, but we also need to implement the 
> rectification invoice and the selfinvoice. For the rectification 
> invoice you need to state the original invoice number and the reason 
> why it’s necessary the rectification. So there are two questions about 
> that:
> 
>  
> 
> 1.- Is there any codelist for the InvoiceTypeCode maintained for an 
> international Agency?
> 


Though not an expert (I have to look these things up) I believe you need the
X12 codelist for Invoice Type Code in an order document. UBL inherited
invoice type code partly from xCBL, which seems to refer to X12 and another
invoice type code in EDIFACT. The latter does not seem to have a special
codelist defined but X12 does. The X12 invoice type code is in the order
document 850 and the invoice type code is segment BEG08 / element type 1019.
The codelist used with it seems to be that which in e.g.
http://www.uig.org/download.asp?f=guidelines/850v41S100799.pdf
is defined with three values
IBM = Invoice By Mail
IEL = Invoice Electronically
INH = Invoice Not Required

>  
> 
> 2.- Should we use the AdditionalDocumentReference to enter the 
> Original Invoice ID?
> 

The index.html file which introduces UBL 1.0 states:

"The Invoice does not cover Debit and Credit Notes, nor does the process
include a Customer Account Statement that summarises Invoices, Credit Notes,
and Debit Notes to be paid."

The invoice scope does include, quote:
"Prepayment invoice (payment expected)
Pro-forma invoice (pre advice, payment not expected)
Normal Invoice, on despatch for despatched items
Invoice after return of ReceiptAdvice"

A type of invoice which replaces another invoice which UBL 1.0 does include
(seek to properly cater for) is a second invoice with the same reference as
the first but with one of the line status code values which show that the
line either replaces a line of a previous invoice or cancels it or the like.
This may be a mistake though since in these cases it might be a legal
requirement that, rather than a cancellation, a credit note be sent - so I'd
be wary of using the line status code in an invoice perhaps. I remember the
modelling team avoided the document status code in an invoice for the same
reason but may have had to keep the line status code for other reasons or
perhaps just forgot to remove it. Either way, thinking about it a little
now, I'm not sure it should be there or at least I think care should be
taken how it is used. This leaves a problem of how to cater for the
reissuing of an invoice when UBL does not have a credit note, *yet* (one is
probably on the way, perhaps, I hope, with 1.1). If you are willing to
implement UBL outside of its intended scope then I'd suggest using the
AdditionalDocumentReference as you say. The problem will then be how to make
it unambiguous what you are doing. I'd say this is only sensible between
known, limited trading partners where such features can be clearly specified
in a TPA. Otherwise you might just have to wait for any such new documents
in UBL 1.1 (perhaps a year away?). It seems there are others doing this. 

Sorry I can't be more helpful. Hopefully others have helpful views on this.

All the best

Stephen Green