OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: Re: [ubl-dev] Basic Invoice Exploration


Two points:

1. What is the system of record and who maintains its business rules?

If one reads through the Danish document, most if not all of the rules it
prescribes should be internalized within the selling and buying parties'
respective ERPs or financial systems, not within the eBusiness translator
nodes. An invoicing process creates not only an "invoice," but many
associated internal transactions and data base updates, and any change to
the invoice done externally to the invoice process may silently corrupt all
that associated data.

Consequently, it is risky to have the eBusiness node do more than faithfully
translate UBL documents. 

2. What inbound node has reject rights?

The matter of computations came up on the UBL discussion group in connection
with editing inbound UBL documents, such as detecting arithmetic mistakes or
other sorts of payload content errors in invoices. 

The obvious but often incorrect answer to my question is to reject the
apparently flawed transaction at the translator level or even a preprocessor
level in front of the translator. The problem is that the buyer party often
has not synchronized business rules and data validation rules between the
ERP node level (the system of record) and the "translator" node. Indeed,
accomplishing that synchronization might require the addition or invocation
of huge amounts of logic and data from the ERP to the eBusiness node,
creating enormous scope creep.

Editing in the absence of adequate synchronization may generate 1) false
positives, with "bad" transactions passing through the ebusiness node edits,
or 2) false negatives, which causes the eBusiness node to reject good
transactions back to the sender to be fixed. False positives are usually not
that consequential, because the ERP edits catch them, but false negatives
are deadly, because rejects interrupts the process, blinds ERP users to the
existence of the rejected transaction and drags the other party into fixing
something that "ain't broke." 

As an example of a false negative, many eBusiness nodes have been configured
to support only two decimal place unit pricing even though many commodities
(e.g., electric power, some chemicals, variable length products such as
wire)are priced in, for example, mils (four decimal places). The eBusiness
node's rules may have been configured to deal with office supplies or other
"low hanging" fruit, but those edits may subsequently become a source of
false negatives when implementation moves on to more complex commodities and
services. If the translation process has been outsourced, false negatives
are even more undesirable because more parties are involved.

In some future incarnations, internal systems may "speak" UBL natively, but
in our present two layer (or more) process it is important to maintain crisp
boundaries between what the internal system of record does and what the
translator layer does.



						Fulton Wilcox
						Colts Neck Solutions LLC







-----Original Message-----
From: G. Ken Holman [mailto:gkholman@CraneSoftwrights.com] 
Sent: Tuesday, June 23, 2009 8:45 AM
To: ubl-dev@lists.oasis-open.org
Subject: Re: Re: [ubl-dev] Basic Invoice Exploration

At 2009-06-23 13:32 +0100, Stephen Green wrote:
>As a UBL TC member (albeit inactive) I've sent a comment to the UBL TC

Thank you for that, Stephen.

Based on this discussion and the value it has for HISC to create a 
guidelines document with example calculation models, I have started a 
TC committee wiki page here:

   http://wiki.oasis-open.org/ubl/Example_Calculation_Models

Nothing is filled in yet because I am distracted with other 
responsibilities for a couple of weeks (including other TC 
responsibilities), but nevertheless the framework is there for 
getting filling in.

Would you like to see a separate section for UK added to this page, 
or would the European differences be sufficient?

Thanks again for your analysis, Stephen.

. . . . . . . . . . . Ken


--
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/u/
Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video
Video lesson:    http://www.youtube.com/watch?v=PrNjJCh7Ppg&fmt=18
Video overview:  http://www.youtube.com/watch?v=VTiodiij6gE&fmt=18
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Male Cancer Awareness Nov'07  http://www.CraneSoftwrights.com/u/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal


---------------------------------------------------------------------
To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]