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

[Stephen Green <stephengreenubl@gmail.com>]

OK, another risky subject.

Looking at the Danish model there are some glaring discrepancies with
the normal interpretation of the UBL tax-related entities' semantics (if
I might try inventing a bit of diplomatic language). In this case the matter
of whose rules apply - senders' or receivers' or others' is paramount. It
seems if I send an OIO-UBL document I need a different computation
system for a different calculation model than if I send what I would expect
to call a UBL-conformant document. Then I risk that document being
rejected because it is limited how much I can adapt the document
calculation model to meet the receivers' expectations: my own rules and
the design of my finance system might mean I have to call TaxExclusive
amount just that and use it to contain the payable total of the invoice
minus the tax (and debatably minus any settlement allowances/charges).
The sender's and reciever's expectations and rules might be mutually
incompatible. So whose apply? Good question. I guess the EU might have
to come up with some rules of their own or risk deadlock.

Stephen D Green



2009/6/23 Fulton Wilcox <fulton.wilcox@coltsnecksolutions.com>:
> 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
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
>
>