[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [ubl-dev] Invoice Type Code / Credit Note requirement
All, It occurred to me that we probably wouldn't have to wait for UBL 1.1 to get a CreditNote document with its own namespace and with (I'd guess) InvoiceDocumentReference and, perhaps, CorrectionReasonCode or CreditReasonCode. I reckon this could be produced quite quickly, reviewed and released at any stage after 1.0 is standardized, rather than there being a need to wait for a complete UBL 1.1 release. I hope this is accomplished but in the meantime Oriol's solution seems satisfactory. What I think probably does need the wait till a UBL 1.1 (or later?) is the addition of a UBL codelist Schema for the relevant values of the 1001 UN Codelist to use integrated with the InvoiceTypeCode. All the best Steve >>> Oriol Bausà <oriol@tradise.com> 08/09/04 09:50:23 >>> Thank you all for your answers and thoughts. Reviewing Jean-Luc 1001 codelist, I've seen that there is a 384 code for the Corrected Invoice. I think that feets my needs so I'll use that UN Code List in the InvoiceTypeCode. I will then use the Note to indicate the reason for the correction and the AdditionalDocumentReference to indicate the original Invoice ID. I'd rather prefer something like OriginalInvoiceReference because I know the problems of using a multiple cardinality field to indicate the Original Invoice Number, but that will probably be solved in a latter version. I'm not a financial expert but as long as I know, you cannot issue an invoice with negative values in Europe, when an error is made in an issued invoice, you have to issue a rectification (or maybe Corrected) invoice, that substitutes the original one, specifying the original invoice number, the new id of another serie and the reason of the correction, so I don't think we have to send negative invoices. Anyway, thanks again for your help. Best regards, Oriol -----Original Message----- From: Stephen Green [mailto:stephen_green@seventhproject.co.uk] Sent: dimecres, 8 / setembre / 2004 10:21 To: ubl-dev@lists.oasis-open.org Subject: Re: RE: [ubl-dev] Invoice Type Code David, Sylvia, Oriol, This to me looks a bit risky, to say the least, as far as UBL implementation goes, with UBL having no codelist defined for InvoiceTypeCode. In my opinion it might be best, since UBL does not yet cater for credit notes, to resort to paper or other means for credit notes now and to wait for UBL to produce a credit note document (and/or at least, perhaps in 1.1, to add a codelist Schema to the InvoiceTypeCode - though I'd prefer a credit note document due to the risk that the two or three character code for a credit might be ignored by the receiving party's application). IMHO, if in the meantime folk must implement something to handle this then I'd prefer to see an invoice issued with negative values in the amounts rather than relying on some obscure code in the InvoiceTypeCode. It rather depends though on how strong the trading partner links is. Back to Oriol's question, I think it might be adequate to use the AdditionalDocumentReference for the original invoice number, especially if, as I guess it might be (with doubts though) immaterial, in many circumstances, what the original invoice number was. If you have to be sure that the invoice number is understood by the receiving application then I think that AdditionalDocumentReference is perhaps too weak for the purpose (it has multiple cardinality so which instance of it holds the invoice number? etc). Here again UBL 1.1 should cater properly for credit notes, I think and perhaps in the meantime AdditionalDocumentReference is OK (between strongly linked trading partners with the means to agree and maintain all these issues and *maybe* for less strongly linked trading partners too) as long as one doesn't rely on that invoice number always being available. In the worst case Note could be used and/or some form of human intervention exception handling (e.g. when the InvoiceTypeCode is not understood or the amounts are negative or something is found in the Additional DocumentReference(s) or when, as I say, a Note is found). At the end of the day, UBL has no specification for credit notes so it is up to implementers. Then of course we have the problems surrounding such lack of standard - problems I hope UBL will help prevent with a CreditNote document or solution soon. Sorry this was a bit of a long answer. Best wishes. Steve ----- Original Message ----- From: <david.lyon@computergrid.net> To: <ubl-dev@lists.oasis-open.org> Sent: Wednesday, September 08, 2004 1:09 AM Subject: Re: RE: [ubl-dev] Invoice Type Code > Stephen, > > The credit note would usually be a positive amount > as it is traditionally a credit to the debtors account. > > The invoice is usually applied as a debit to an > account. So whilst being transmitted with a positive > value, it gets applied to the account in a subtractive > sense. > > It's rare to see a negative amount credit note. Won't > say never :-), but that would usually go on another > invoice. > > > Quoting Stephen Green <stephen_green@seventhproject.co.uk>: > > > David > > > > Thanks for this very helpful answer. I believe we might want to > > take this up in UBL to introduce this 'officially' as a much needed > > way to produce a credit note - thanks to Oriol and Sylvia for bringing > > it to the fore. I do agree with your use of the InvoiceTypeCode to > > designate a credit note (with typically negative values, though, as you > > say they could be positive if necessary). I wonder whether it would be > > best to see that the 1001 codelist is adopted into UBL (via a codelist > > Schema module - albeit with a subset of the full 1001 TRED codelist). > > Thanks too to Jean-Luc for confirming the use and role of this codelist. > > I hope this question can become part of the in-development UBL FAQ. > > > > All the best > > > > Stephen Green > > > > ----- Original Message ----- > > From: <david.lyon@computergrid.net> > > To: <ubl-dev@lists.oasis-open.org> > > Sent: Wednesday, September 08, 2004 12:24 AM > > 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 > > > > > > > > > Also Jean-Luc Champion wrote: > > > > ----- Original Message ----- > > From: Jean-Luc Champion > > To: ubl-dev@lists.oasis-open.org > > Sent: Tuesday, September 07, 2004 7:05 PM > > Subject: RE: [ubl-dev] Invoice Type Code > > > > > > Hi Oriol, > > > > > > > > 1.- Is there any codelist for the InvoiceTypeCode maintained for an > > international Agency? > > > > > > > > There is something similar in EDIFACT but as document name code (Data > > Element 1001) > > > > You can find the complete list of document name code on > > http://www.unece.org/etrades/download/downmain.htm#edifact > > > > Download the last version and in the zip file there a file named UNCL.ZIP > > (UN Code List) > > > > > > > > Kind regards, > > > > Jean-Luc Champion > > > > UN/CEFACT Forum TBG1 Chair > > > -------------------------------------------------------------------------- > > ------------------------------------------------------------------- > > > > This is an abstract: > > > > * 1001 Document name code [C] > > > > > > > > Desc: Code specifying the document name. > > > > > > > > Repr: an..3 > > > > > > > > 380 Commercial invoice > > > > Document/message claiming payment for goods or services > > > > supplied under conditions agreed between seller and > > > > buyer. > > > > > > > > 381 Credit note > > > > Document/message for providing credit information to the > > > > relevant party. > > > > > > > > 384 Corrected invoice > > > > Commercial invoice that includes revised information > > > > differing from an earlier submission of the same > > > > invoice. > > > > > > > > 385 Consolidated invoice > > > > Commercial invoice that covers multiple transactions > > > > involving more than one vendor. > > > > > > > > 386 Prepayment invoice > > > > An invoice to pay amounts for goods and services in > > > > advance; these amounts will be subtracted from the final > > > > invoice. > > > > > > > > 387 Hire invoice > > > > Document/message for invoicing the hiring of human > > > > resources or renting goods or equipment. > > > > > > > > 388 Tax invoice > > > > An invoice for tax purposes. > > > > > > > > 389 Self-billed invoice > > > > An invoice the invoicee is producing instead of the > > > > seller. > > > > > > > > 390 Delcredere invoice > > > > An invoice sent to the party paying for a number of > > > > buyers. > > > > > > > > 393 Factored invoice > > > > Invoice assigned to a third party for collection. > > > > > > > > 394 Lease invoice > > > > Usage of INVOIC-message for goods in leasing contracts. > > > > > > > > 395 Consignment invoice > > > > Commercial invoice that covers a transaction other than > > > > one involving a sale. > > Ori > > > > > > 396 Factored credit note > > > > Credit note related to assigned invoice(s). > > > > > > > > > > -------------------------------------------------------------------------- -- > > -- > > > > De : Oriol Bausà [mailto:oriol@tradise.com] > > Envoyé : mardi 7 septembre 2004 13:18 > > À : ubl-dev@lists.oasis-open.org > > Objet : [ubl-dev] Invoice Type Code > > > > > > > > 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? > > > > > > > > 2.- Should we use the AdditionalDocumentReference to enter the Original > > Invoice ID? > > > > > > > > Thanks for your help > > > > > > > > Oriol > > > > > > > > --Aviso-- > > > > Este mensaje se dirige exclusivamente a su destinatario y puede contener > > información privilegiada o confidencial y/o datos de carácter personal, cuya > > difusión está regulada por la Ley Orgánica de Protección de Datos y la Ley > > de Servicios de la Sociedad de la Información. Si usted no es el > > destinatario indicado (o el responsable de la entrega al mismo), no debe > > copiar o entregar este mensaje a terceros bajo ningún concepto. Si ha > > recibido este mensaje por error o lo ha conseguido por otros medios, le > > rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a > > su eliminación irreversible. Las opiniones, conclusiones y demás información > > incluida en este mensaje que no estén relacionadas con asuntos profesionales > > de Tradise no están respaldadas por la empresa. > > > > --Notice-- > > > > This e-mail message is solely intended for its addressee and may contain > > confidential information. If you are not the addressee of this e-mail you > > should know that it is forbidden to read it, copy or use it. Please, notify > > us of receipt immediately via e-mail and delete it. Opinions, and other > > informations included in this message not related with Tradise professional > > activity will not be endorsed. > > > > --Avís-- > > > > Aquest missatge electrònic es dirigeix només al seu destinatari. Pot > > contenir informació privilegiada o confidencial i/o dades de caràcter > > personal regulades per la Llei Orgànica de Protecció de Dades i la Llei de > > Serveis de la Societat de la Informació. Si Vostè no n'és el destinatari, ha > > de saber que la seva lectura, còpia i ús està prohibida. Li preguem que ens > > avisi immediatament per aquesta mateixa via i que procedeixi a la seva > > destrucció. Les opinions, conclusions i la resta d'informació inclosa en > > aquest missatge, que no estiguin relacionades amb assumptes professionals de > > Tradise, no estan recolzades per l'empresa. > > > > > > > > > > > > > ------------------------------------------------------- > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]