[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: RE: [ubl-dev] Invoice Type Code
I have been watching this list since inception with some interest, as I believe it holds a lot of long term potential. We have not had a requirement to study UBL in-depth, so have not attempted to have any input to what seems to be a fairly expert technical group. However, there does seem to be some confusion over the issue of various document types, so I thought I might provide input from 25 years of developing accounting and business solutions. I will try to be brief Document types The ones we have come across are invoice, credit note or credit memo, debit note or debit memo, journal, balance or balance forward. Negative documents are not, in my opinion, an acceptable means of producing commercial documents. However, we have encountered negative invoices in one case where we were converting data from another application to our software. Signed numerics I don't believe there is any standard for accounting systems in this case. Some systems hold credit note amounts as positives and subtract these from the invoices to arrive at an account balance, so the maths requires different operations for different document types; e.g. invoice + invoice + debit note - credit note = account balance. Other systems hold the credit amounts as signed so the mathematical operation is always add; e.g. invoice + invoice + debit note + credit note = account balance. A significant issue with any interchange/conversion of data between accounting systems is the definition of what is signed and what is not signed. Difference in document types The data for the various document types is fairly much the same. There can be some additional reference information specified for invoice vs credit note, but there is probably a 90% similarity between various document types specified above. Numeric sign on invoice/credit note lines All of the above relates to the document totals. Negative values on individual lines within an invoice are of course permissible. An example is discount or rebate for a purchase, which could appear as a negative line on an invoice Re-issue of invoices This is a vexed question. As has been stated, a number of low-end accounting systems allow data to be changed and re-printed with scant regard for the consequences. For a supplier to simply re-issuing and invoice would not for import into our accounting system, as it does not allow the same document to be processed twice, irrespective of whether it has any sort of status attached to it or not. If you take an example where an invoice number 1201 is issued for $100, we would load it into our system at $100. If the invoice number 1201 is then re-issued as $120, we would not process it. The processing options which could be considered in this case are: (a) Change the invoice value in the creditors system and figure out which lines were different so the general ledger, purchase analysis, etc can be adjusted. Messy from all sorts of perspectives, including audit, user comprehension of what has happened and also supporting documentation for the transaction(s) (b) Create a system generated reversal of the original transaction and process the replacement invoice as a new transaction. Multiple issues with this solution, including no supporting documentation for the reversal (c) Insist on credit note being issued to reverse the original invoice and a new invoice issued. I believe this would be the accepted accounting process in most of the world. However, it does not suit the enormous number of low end accounting systems run by small businesses with minimal in-house accounting expertise. Hope this is of some help and sorry I can't provide a silver bullet. David Field Director Landmark Software Pty Ltd 349 Moray Street South Melbourne VIC 3205 Phone: +61 3 9682 7777 Fax: +61 3 9686 4141 Email: mailto:david@landmarksoftware.com.au Web: http://www.landmarksoftware.com.au -----Original Message----- From: Oriol Bausà [mailto:oriol@tradise.com] Sent: Wednesday, 8 September 2004 6:50 PM To: ubl-dev@lists.oasis-open.org Subject: RE: RE: [ubl-dev] Invoice Type Code 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. > > > > > > > > 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]