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

[<stephen_green@seventhproject.co.uk>]

This may be of more relevance to UBL than to Oriol's question.

I believe the TRED codelist 1001 may be the one for invoice type code
http://www.unece.org/trade/untdid/d01a/tred/tred1001.htm
Document name code                                      

However it covers far more than just invoices so a subset would probably
be required. 

There is also a short codelist in EDIFICE which includes self-billing, 
credits and the like:
http://www.edifice.org/REP1/sbibim2.pdf
Against 1001 they have:
"389 = Self-billed invoice
ZCR = Customer issued credit note (*)
Document/message for providing credit
information to the relevant party.
ZDR = Customer issued debit note (*)
Document/message for providing debit
information to the relevant party.
ZSC = Consignment self-billed invoice (*)
Used for consignment
ZSR = Self-billing Invoice Withdrawal
Message (*)
Message issued by the customer to
replace an incorrect SB Invoice which
has been withdrawn in a previous SB
Invoice Withdrawal Message in
accordance with the SB correction
procedure.
ZSW = Self-billing Invoice Withdrawal
Message (*)
Message issued by the customer to
withdraw a previous incorrect SBI in
accordance with the SB correction
procedure.
(*) EDIFICE code"



All the best

Steve




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