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

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

At 2009-06-23 10:44 -0400, Fulton Wilcox wrote:
>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.

Absolutely!  My efforts in this area are for describing which 
information is meant to go in which fields so that prospective users 
of UBL can recognize which of their application data points fit where 
in the XML structure.

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

And UBL documents will only be translated faithfully when both 
parties agree which data points go where in the structure.

Because UBL is only scaffolding that holds the values, presentation 
processes like stylesheets are explicitly not responsible for any 
kinds of calculations.

By fully documenting candidate calculation models, two trading 
partners can document that model that expresses the kinds of data 
expected to be interchanged.  Then each party can know how to map the 
values from and to their respective systems.

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

I don't see that happening at the syntax level of UBL document 
validation.  Once the document structure has been used to convey the 
information, an application's own validation processes can be used to 
confirm the numbers that were conveyed.

I see UBL's role only to deal with things like syntax:  structural 
and lexical issues addressed by the schema and code list values 
expressed by value validation.

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

Totally agree at the semantic value analysis level ... but with XML 
there is still the opportunity at the syntax level to mandate that 
certain information be present and that that information conforms to 
the expectations of applications.  This unburdens applications of a 
certainly level of commonly-agreed syntactic checks.  It can focus on 
what the values and codes mean rather than how they are expressed.

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

I totally agree.  And I apologize if my focus on the calculation 
model has left the impression that I think such aspects are the 
responsibility of intermediary processes between sender and 
receiver.  UBL, like most XML vocabularies, is just dumb scaffolding 
arranging sender system information in a structure in which the 
receiver can expect to find what it needs to satisfy its system.

My objective in writing these things up is to address exactly the 
kinds of questions raised by jaymuz of "what do I put where in a UBL 
instance?" and document representative examples of what a community 
of users or a pair of trading partners might agree upon.  Notice that 
his question isn't "what does UBL do with these numbers?" but "what 
do I do with these numbers?" ... at least that is how I read his 
question.  He gave me his data and I responded with a candidate UBL 
instance (that Stephen repaired).

I hope this clarifies my efforts in this regard.

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