[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl-dev] Rectification invoices
Stephan, Not only the tax people, but I think we all would like to discourage "mixed processes," especially when what is being mixed in is inefficient and symptomatic of a "cost of non-quality." In my view, invoice "kickouts" are merely a symptom of under-investment in data quality and process quality, especially with respect to their fitness for use in inter-entity processes. Given divergent "facts" and "rules," people end up doing what automated processes could do and then, certainly in the U.S., more people are needed to validate the exception handing processes on behalf of Messrs Sarbanes and Oxley. Success will come when the seller and buyer have converging "facts" and "rules" in their respective systems based on collaboration and synchronization. It probably will take some next generation eBusiness architectures (much more dynamic than document exchange) and some next generation attentiveness to inter-entity data quality to get past the need for human intervention. Probably the worst symptom of "mixed process" is the increasingly common case that customer companies "solve" data synchronization problems by having the vendors' staff key invoice data into customer-controlled portals. As a result, suppliers who have invested huge sums to implement highly efficient order to cash systems (and who probably support UBL or some industry-specific XML standards) are reduced to having their own employees key invoice data into someone else's "purchase to pay" supplier relationship web screens. The only justice is that the customer companies in turn are probably doing the equivalent manual keying into some of its customers' portals. I want to encourage UBL refinement to help reduce the substitution of inefficient process for efficient ones, but it is also worth a mention that you are touching on deeper problems that should be approached with caution, particularly if the proximate solution is to add complexity to UBL that can't be used until root cause problems are addressed. Fulton Wilcox Colts Neck Solutions LLC -----Original Message----- From: Stephen Green [mailto:stephen_green@seventhproject.co.uk] Sent: Thursday, October 06, 2005 5:45 AM To: ubl-dev@lists.oasis-open.org Subject: Re: [ubl-dev] Rectification invoices 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/ --------------------------------------------------------------------- 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/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]