[no subject]

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
> 




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