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

[Stephen Green <stephengreenubl@gmail.com>]

OK, I've posted this text to the "Example Calculation Models"
UBL TC wiki page as a note
( http://wiki.oasis-open.org/ubl/Example_Calculation_Models )

Maybe it answers most of the question re a calculation model.
[WARNING: Of course the note isn't yet approved by UBL TC.]

"NOTE:
One invoice total, LineExtensionAmount, can be represented in terms of
the line amounts, while the other totals can be represented in terms
of eachother. LineExtensionAmount in LegalMonetaryTotal is the sum of
the LineExtensionAmounts for all of the invoice lines [*]. This total
plus any invoice charges and minus any invoice allowances equals the
total TaxExclusiveAmount. Add to this any taxes and you have the total
payable. Settlement charges and allowances are not a part of this
total as their amount depends on factors not known when the invoice
totals are calculated. Taxes at invoice line level are not always
shown, depending on country or region tax invoice rules so any totals
involving these are typically subject to such rules.

      * Note though too that LineExtensionAmount is arguably subject
to varying interpretations. The above calculation model is arguably
the normal practice and is that which is used in the UBL 2.0 standard
package invoice example. "

Best regards

Stephen D Green



2009/6/23 Stephen Green <stephengreenubl@gmail.com>:
> Hi Ken
>
> Unfortunately I just checked the next one, TaxInclusiveAmount,
> and I think this one is wrong too - at least in the statement
> "The TaxInclusiveAmount represents the sum of the
> total tax amount and the related taxable amount
> of the document."
> It must also include any non-taxable amounts. There may logically
> be more to it than Sum(Taxable amounts) + Sum(Taxes) +
> Sum(Non-taxable amounts), e.g. Sum(Non-taxable amounts) is not
> clear on the invoice (may involve some circular logic) and I'm not sure
> this is the best way to go about defining it. I think what you need
> is all the UBL definitions plus maybe some guarded, careful extra
> notes (careful about that) plus just in the main a set of assertions
> expressed in calculation form. Like it has now but with less words
> (to avoid risk of introducing extra, non-normative logic). Then these
> assertions should be first approved by UBL TC as conforming to
> the spec and as promoting conformance to the spec. Maybe the
> notes should be approved too. Hence best for all this to be done in
> UBL TC itself - e.g. on wiki then with TC approval/QA process.
>
> Maybe what is needed is a set of 'test assertions' as per TAG TC.
> This is what is going on with OIC TC to help sort out discrepancies
> over ODF spreadsheet formulas, etc. As in that case, the TC needs
> to approve the test assertions (or at least anything extra the TAs
> add to the normative statements of the specs/schemas). Else
> there will always be arguments over which assertions/calc model
> is correct and what authority a model has.
>
> Stephen D Green
>
>
>
> 2009/6/23 G. Ken Holman <gkholman@cranesoftwrights.com>:
>> I haven't yet transcribed the Danish OIO-UBL components into the calculation
>> model page, but I have been told in private correspondence that:
>>
>>  "I would like to point out that OIO has misunderstood the use of
>>   TaxExclusiveAmount."
>>
>> That happens to be the item you cited in your post ... have you found other
>> discrepancies?  It is this known error that I refer to in
>> http://wiki.oasis-open.org/ubl/Example_Calculation_Models when I cite the
>> OIOUBL PDF document.
>>
>> Please let me know if you can see other problems.
>>
>> BTW, I wasn't told what the misunderstanding is, so I look forward to your
>> edits to the wiki in this regard once I've transcribed things.
>>
>> Was it perhaps improper to base the deltas of calculation models on the
>> (corrected) OIO-UBL document?  I chose that as a starting point as it is the
>> only such document I know about.  If there is a more appropriate one then we
>> can use that as a basis for the example calculation models.
>>
>> Does anyone know which citation to use for the BII calculation model?
>>
>> . . . . . . . . . . Ken
>>
>> At 2009-06-23 17:06 +0100, Stephen Green wrote:
>>>
>>> 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
>>
>>
>> --
>> 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
>>
>>
>