Re: Re: [ubl-dev] Invoice Type Code

[<stephen_green@seventhproject.co.uk>]

Sorry, I must add that the invoice type code from X12 is obviously
not semantically the same as that in the UBL invoice and the codelist
is irrelevant to the UBL invoice usage. I would say that the UBL invoice
type code refers to such things as 'purchase', 'sale or return', 'hire'
and the like and, if it were in scope 'credit note' and 'self-billing'
so to find a codelist with these sorts of values (e.g. a Google search
with the values and 'codelist tred' or just 'codelist') might help.

Steve




stephen_green@seventhproject.co.uk wrote on 07.09.2004, 18:26:01:
> 
> Oriol
> 
> Oriol Bausà  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