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

["Stephen Green" <stephen_green@seventhproject.co.uk>]

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