Re: [ubl-dev] Invoice Type Code

[<stephen_green@seventhproject.co.uk>]

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