Re: [ubl-dev] Rectification invoices

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

Folks

Just to note, a CreditAdvice and DebitAdvice are to be included in
UBL 2.0. Likely to enter a public review period in December this year
these might, we hope, be available for use a year or so from now.
In the meantime I agree, personally, that it is best to correct over- and
underpayments in some other way than overloading the UBL 1.0
Invoice, perhaps using paper processes if the UBL Invoice itself has
been implemented to replace a paper process. However, I get the
impression in my own country (UK) that the tax people (VAT C&E)
strongly discourage 'mixed-processes' so maybe one might want to consider
if mixing paper corrections with processing of electronic invoices
is 'allowed' - just an opinion (no liability accepted if enquiries made
cause more trouble than they solve).

Stephen Green

----- Original Message ----- 
From: "Fulton Wilcox" <fulton.wilcox@coltsnecksolutions.com>
To: "'Jorge Ortiz Claver'" <jorge.ortiz@tirea.es>
Cc: <ubl-dev@lists.oasis-open.org>
Sent: Thursday, October 06, 2005 3:29 AM
Subject: RE: [ubl-dev] Rectification invoices



Jorge:

In my experience, typically the seller's system would issue a new invoice
with a new document identity, while reversing the erroneous invoice with a
credit. From an eBusiness perspective/UBL perspective, the replacement
invoice would merely be another invoice instance, with perhaps "replacement"
referenced in a comment field. It would therefore not require a new document
type/variant.

On the buy side, electronic payables entities (e.g., I have in mind several
major auto companies) typically will not accept either electronic credit
transactions nor "change" invoices (i.e., a corrected invoice with the same
document identity as its predecessor). Indeed, for all practical purposes
credits and adjustments have to be handled offline, because of the many
process complexities in their payables process.

There is one U.S. automobile manufacturer that will accept replacement
invoices - i.e., they pay the last version received, and in that scenario
there is no need for a different UBL document or variant.

I'm not sure that adding to UBL would address these back office issues.
Indeed, if anyone is thinking about implementing a Six Sigma error
minimization program, invoicing is a great place to start, because backing
out bad invoice data is an ugly job.


Regards,

Fulton Wilcox
Colts Neck Solutions LLC




-----Original Message-----
From: Jorge Ortiz Claver [mailto:jorge.ortiz@tirea.es]
Sent: Tuesday, October 04, 2005 4:27 AM
To: ubl-dev@lists.oasis-open.org
Subject: [ubl-dev] Rectification invoices

Hi,

The third-party billing system Iīm working in itīs supposed to work with
UBL standards. Everything is fine till I need to generate rectification
invoices. Iīve been reading in ubl-dev forum some threads (November
2004) where this issue is discussed  but I canīt find which was the
final resolution for this problem.

Someone said the AdditionalDocumentReference can be used in order to
reference the original invoice ID and that the InvoiceTypeCode should
specify the invoice is a rectification of a previous one. Someone
purposed to include a CorrectionReasonCode and CreditReasonCode tags but
it seems like there werenīt include in final 1.0 release.

Which is the better way to emit this kind of invoices? Will it be
supported in 1.1/2.0? In that case, when will that version be available?

Regards,
Jorge



---------------------------------------------------------------------
This publicly archived list supports open discussion on implementing the UBL
OASIS Standard. To minimize spam in the
archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Alternately, using email: list-[un]subscribe@lists.oasis-open.org
List archives: http://lists.oasis-open.org/archives/ubl-dev/
Committee homepage: http://www.oasis-open.org/committees/ubl/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
Join OASIS: http://www.oasis-open.org/join/


---------------------------------------------------------------------
This publicly archived list supports open discussion on implementing the UBL
OASIS Standard. To minimize spam in the
archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Alternately, using email: list-[un]subscribe@lists.oasis-open.org
List archives: http://lists.oasis-open.org/archives/ubl-dev/
Committee homepage: http://www.oasis-open.org/committees/ubl/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
Join OASIS: http://www.oasis-open.org/join/