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

[david.lyon@computergrid.net]

Sure. Happens every day.

Quoting Sylvia Webb <swebb@gefeg.com>:

> David,
> 
> I agree with you with one exception.  Many accounting software packages for
> small business, and a few well known ones, in the US allow you to delete an
> invoice and resend it and this feature is used. Regardless of best
> practices, small business entrepreneurs and non-public companies cancel
> invoices and resend them. There are no US laws that I am aware of that
> prevent this practice.  
> 
> Regards,
> Sylvia
> 
> -----Original Message-----
> From: david.lyon@computergrid.net [mailto:david.lyon@computergrid.net] 
> Sent: Tuesday, September 07, 2004 4:24 PM
> To: ubl-dev@lists.oasis-open.org
> Subject: Re: RE: [ubl-dev] Invoice Type Code
> 
> 
> Sylvia,
> 
> From my experience in business, I would suggest that corrections are
> traditionally sent in the form of a "Credit Note" document.
> 
> Credit note amounts can be negative and positive.
> 
> These are seperate paper documents from the invoice and show 
> which invoice and have the invoice that they refer 
> to in their header.
> 
> When the account is totalled in the statement, credit notes, payments,
> invoices, journals, are all summed to give the balance.
> 
> Forgive this if it sounds quite simplistic.
> 
> If there isn't a Credit Note in UBL, I would use the Invoice document as the
> base and just change the Invoice Type code.
> 
> David
> 
> Quoting 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
> > 
> 
> 
> 
> 
> -------------------------------------------------------
> 
> 
> 
> 




-------------------------------------------------------