[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: RE: [ubl-dev] Invoice Type Code
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]