[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl-dev] Invoice Type Code
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à <oriol@tradise.com> 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]