OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


I am no expert, but it sounds as if we need a "Cancel Invoice" code with
negative amounts that exactly matches it's related invoice, a "Corrected
Invoice" code with only positive amounts and a "Credit Memo" which may or
may not be an invoice (depends on how good the 'fit' is for those who use
it).

-- Jeffrey
----- Original Message ----- 
From: <david.lyon@computergrid.net>
To: <swebb@gefeg.com>
Cc: <ubl-dev@lists.oasis-open.org>
Sent: Wednesday, September 08, 2004 12:05 AM
Subject: RE: RE: [ubl-dev] Invoice Type Code


>
> 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
> > >
> >
> >
> >
> >
> > -------------------------------------------------------
> >
> >
> >
> >
>
>
>
>
> -------------------------------------------------------



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]