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

[<stephen_green@seventhproject.co.uk>]

Sylvia

I'd want to stick to the stated scope of course but beyond that
I must admit my lack of knowledge of North American laws in respect
to invoices. In Europe an invoice is usually a Tax invoice and so,
as far as I know, cannot be cancelled just by resending it with a
specific status code. It has to be credited so as to balance the tax
with the exact same amount but negative. That's about all I know but
it has repeatedly emphasised to me both in the UK and in Europe.
More than that I couldn't say without more research than I can do at
present. I'd like to hear more about the equivalent laws and practises
your side of the Atlantic/Pacific.

All the best

Steve


Sylvia Webb <swebb@gefeg.com> wrote on 07.09.2004, 19:10:35:
> 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à  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