Re: [ubl-dev] Test Assertions for UBL Calculation Model?

[Stephen Green <stephengreenubl@gmail.com>]

I guess what I was going to say about approach 2. below
was that we could write a rule to cater for all of the UBL 2
standard entities relating to the calculations of totals and
leave it to customisers to change these macroscopic
calculations. I think the danger/side effect that this would
add lots of complexity is too costly to warrant the benefit.
I'd prefer the 80:20 approach (although some might argue
that the whole of UBL is already 80:20, though I don't
agree): cater for entities participating in 80% of calculations
(an arbitrary general knowledge judgment I admit) and make
exceptional extra assertions to cover the corner cases. So
here we would say something in the TAs to the effect that
rules in TA Set invoice-total-001 apply UNLESS a) you have
PrepaidAmount in the invoice or b) ... or c) ...  This could be
done with a blanket prerequisite for that Test Assertion Set
(id = invoice-total-001). Another way is to use the existing
TAs (the rules below) and match them to a conformance
profile whose conformance clause includes the assertion
that the invoice does not include a PrepaidAmount (in effect
a subset profile).

---
Stephen D Green




2009/9/18 Stephen Green <stephengreenubl@gmail.com>:
> I've been thinking a bit about this:
>
> If we say a calculation is A = B + C + D - E
>
> then someone has a customisation which subsets out D
>
> we could do several things
>
> 1. let them rewrite the calculation (e.g. without D in it, though it
> may mean a more complex change than that)
>
> 2. leave it as it is
>
> 3. write into the calculation test assertion logic more prerequisites
> e.g. to say "if exists B and exists C and exists D and exists E
> or a more thorough way would be to split up the logic
> "if exists B and not exists C, D, E then A = B..."
> "if exists B and not exists C, D, E then A = {f(B)}"
> "if exists B, C and not exists D, E then A = {f(B, C)}"
> "if exists B, C, D and not exists E then A = {f(B, C, E)}"
> etc
>
> I think 3. is what is really needed but it means a lot more work.
> In practice there is not too much work because often some of
> A, B, C, D, etc are mandatory in the standard schema.
>
> My approach has been to make assumptions some of which
> I have to add as further prerequisites. I guess I've been assuming
> something like the Small Business Subset and letting other subset
> people write their own rules - but I need to look into this and make
> it explicit by enhancing the test assertion prerequisite(s), perhaps.
> I guess even that is useful though because most will be using
> something like the SBS and mainly concerned with the logic found
> in those most-important elements. If you are using other totals like
> PrepaidAmount then you need to build that into the calculation
> model you use. Perhaps suffice it to say, if you start with the model
> I've provided so far you 1. have to take it as is  and 2. need to assess
> how appropriate or otherwise it is in your situation. I do think it fits
> with the original intentions of the designers of UBL 1 whose design
> was mainly carried over as-is (I think) into UBL 2 (with additions).
> The UBL 1 ubset was hardly affected by UBL 2 (in fact we even
> gave up the considerable effort of getting the 2.0 SBS through to
> official committee spec stage because UBL 1 SBS mainly did the
> job.
>
>
> ---
> Stephen D Green
>
>
>
>
> 2009/9/18 Stephen Green <stephen.green@bristol.gov.uk>:
>> Thanks Oriol for looking at these in detail. I'll try to respond
>> in detail a bit later but in the meantime it kind of vindicates
>> the TC decision to not mandate just one calculation model as
>> people may need different models if their subsets include
>> different elements. Maybe what I have defined is a broader
>> model than you'd like. Maybe it does have errors though so I
>> will check. Maybe, too, we can have an agreed ubl-dev model
>> that would benefit a wide base of implementations.
>>
>> Regarding the rule/test assertion INVTOT002 it does kind of
>> show that the formal expression using the combination of
>> XPath and Test Assertion Markup Language (or equivalent)
>> 1. generally loses something in 'translation' into prose no
>> matter how much you try (by " invoice 'AllowanceCharge' "
>> I meant AllowanceCharge at document level)
>> 2. gives the expressiveness needed to state unambiguously
>> what is meant but that this isn't all that 'human-readable' so
>> prose may be needed too.
>> I would recommend referring to the XPath and the full logic
>> of the TA to get the actual, normative meaning rather than
>> the interpretation.
>>
>> Best regards
>>
>> Steve
>>
>>>>> Oriol Bausā <ORIOL@INVINET.ORG> 18/09/09 09:19 >>>
>> Hi Stephen,
>>
>> Some comments on the rules,
>>
>> El 17/09/2009, a las 14:54, Stephen Green escribiķ:
>>>
>>>
>>> Test Assertion ID: invoice-total-001.INVTOT002
>>>
>>> Rule: given that there is only one currency used in the invoice and
>>> that there is at least one invoice line with a line extension
>> amount,
>>> the 'TaxExclusiveAmount' in the invoice 'LegalMonetaryTotal' is
>>> equal to the sum of the 'LineExtensionAmount's in all of the invoice
>>> lines plus the sum of the invoice 'AllowanceCharge' charges minus
>>> the sum of the invoice 'AllowanceCharge' allowances
>>
>> There are AllowanceCharges at header and line level, which ones are
>> you referring to?
>>
>>>
>>> Test Assertion ID: invoice-total-001.INVTOT003
>>>
>>> Rule: given that there is only one currency used in the invoice and
>>> that there is at least one invoice line with a line extension
>> amount,
>>> the 'AllowanceTotalAmount' in the invoice 'LegalMonetaryTotal' is
>>> equal to the the sum of the invoice 'AllowanceCharge' allowances
>>> minus the sum of the invoice 'AllowanceCharge' charges
>>>
>>
>> Don't agree. There is a ChargeTotalAmount in the LegalMonetaryTotal.
>> AllowanceTotalAmount should be the total of allowances, and
>> ChargeTotalAmount the total of charges.
>>
>>> Test Assertion ID: invoice-total-001.INVTOT004
>>>
>>> Rule: given that there is only one currency used in the invoice and
>>> that there is at least one invoice line with a line extension
>> amount,
>>> in the invoice 'LegalMonetaryTotal' the 'LineExtensionAmount' is
>>> equal to the 'TaxExclusiveAmount' plus the 'AllowanceTotalAmount'
>>>
>>
>> I do not agree. The LineExtensionAmount equals the sum of
>> LineExtensionAmounts at line level, as per your first rule.
>>
>>> Test Assertion ID: invoice-total-002.INVTOT005
>>>
>>> Rule: [given that all test assertions in the test assertion set
>>> 'invoice-total-001' are passed],
>>> the 'PayableAmount' in the invoice 'LegalMonetaryTotal' is equal to
>>> the TaxExclusiveAmount (in the invoice 'LegalMonetaryTotal')
>>> plus the sum of the invoice total tax amounts (at invoice document
>>> level)
>>>
>>
>> I'd say that TaxInclusiveAmount equals TaxExclusiveAmount plus the
>> sum of the invoice total tax amounts.
>>
>> And PayableAmount is TaxInclusiveAmount minus the PrepaidAmount
>>
>> Regards, Oriol
>>
>>>
>>> These are expressed using XPath in the test assertions document:
>>>
>>> http://www.oasis-open.org/committees/download.php/34247/ubl-ta-
>>> draft-0-61.xml
>>>
>>> I'm short on time but hope to be able to add these to the UBL wiki
>>> if there aren't objections.
>>>
>>> Best regards
>>> ---
>>> Stephen D Green
>>>
>>>
>>>
>>>
>>> 2009/6/25 Stephen Green
>>> <stephen.green@documentengineeringservices.com>:
>>>> OK, now on [pause].
>>>>
>>>> I'll come back to this thread when I've got some test assertions
>>>> written
>>>> for the UBL calculation model.
>>>>
>>>> Best
>>>>
>>>>
>>>> Stephen D Green
>>>>
>>>>
>>>>
>>>> 2009/6/24 Stephen Green
>>>> <stephen.green@documentengineeringservices.com>:
>>>>> The other advantage of using XPath ...
>>>>>
>>>>> [ like one starting
>> doc("http://docs.oasis-open.org/ubl/...";)/...
>>>>> to say something about the
>>>>> schema (e.g. to extract a dictionary entry name if you really
>>>>> need one)
>>>>> or doc($instance)/Invoice/... to assert something about the
>> invoice
>>>>> (where another reference
>>>>> defines $instance), e.g. using a variable assignment element of
>> the
>>>>> xpath-profile test assertion ]
>>>>>
>>>>> ... is that you can make the assertion(s) executable. You can
>>>>> perhaps
>>>>> convert to Schematron
>>>>> for individual assertions or if you want to chain the assertions
>>>>> (make
>>>>> one dependant on the
>>>>> outcome of testing an invoice according to another) you can
>>>>> (eventually) use a test assertion
>>>>> xpath profile execution engine. For the latter you may need to
>> wait
>>>>> for tools to be in production
>>>>> or write your own but WS-I is doing the latter quite successfully
>>
>>>>> and
>>>>> I hope there will be tools
>>>>> soon, perhaps some free ones.
>>>>>
>>>>> The Balisage 2009 XML conference will feature a presentation on
>> this
>>>>> by Jacques Durand of
>>>>> Fujitsu US / WS-I / OASIS (TAG Chair, TAB, etc) which should be
>>>>> excellent (plus Ken and I
>>>>> both get a mention!).
>>>>>
>>>>> Stephen D Green
>>>>>
>>>>>
>>>>>
>>>>> 2009/6/24 G. Ken Holman <gkholman@cranesoftwrights.com>:
>>>>>> At 2009-06-24 19:36 +1000, jaymuz@optusnet.com.au wrote:
>>>>>>>
>>>>>>> Sorry to jump in gents but I was looking to build this myself
>>>>>>> however you
>>>>>>> gentleman know your way around these datasets better than I do
>>>>>>> and I am
>>>>>>> hoping you may already have same.
>>>>>>>
>>>>>>> Do we have a list of BBIE's that may play a role in calculating
>>
>>>>>>> the
>>>>>>> balance of an amount in an invoice?
>>>>>>
>>>>>> You can see that Stephen and I have started here:
>>>>>>
>>>>>>  http://wiki.oasis-open.org/ubl/Example_Calculation_Models/
>>>>>> Invoice_Tax_Total
>>>>>>
>>>>>> ... where you can see we are using "nsprefix:UBLName" and
>>>>>> definition,
>>>>>> assuming a documentary set (not required set) of namespace
>>>>>> prefixes listed
>>>>>> here:
>>>>>>
>>>>>>  http://wiki.oasis-open.org/ubl/Example_Calculation_Models#ns
>>>>>>
>>>>>>> I am talking all BBIE's that could form part of a calculation.
>>>>>>>
>>>>>>> This would include a price in a catelogue that may transfer to
>>>>>>> an order.
>>>>>>>
>>>>>>> This would not include the address of a supplier.
>>>>>>>
>>>>>>> A list that would be useful would be:
>>>>>>>
>>>>>>> UBL Name | Object Class | Property Term | Data Type | Definition
>>>>>>
>>>>>> Given that "nsprefix:UBLName" combination will uniquely find the
>>
>>>>>> other
>>>>>> information, and that applications will use "nsprefix:UBLName"
>>>>>> for access to
>>>>>> the information from programs or from stylesheets, I suspect our
>>
>>>>>> level of
>>>>>> detail is sufficient.
>>>>>>
>>>>>> One drawback to your proposed list is that it doesn't show
>>>>>> context (many UBL
>>>>>> business entities are used in multiple contexts), so I'm
>>>>>> proposing an XPath
>>>>>> pattern address to the item in question and then a relative
>>>>>> XPath address to
>>>>>> the components on which it is based.  The information you want
>>>>>> can be
>>>>>> derived unambiguously from the "nsprefix:UBLName" components
>>>>>> used in the
>>>>>> XPath addresses.
>>>>>>
>>>>>> For example, consider the common library entry:
>>>>>>
>>>>>>  TaxTotal | Tax Total. Tax Amount. Amount | The total tax amount
>>
>>>>>> for ...
>>>>>>
>>>>>> This has different contexts just in our first examples:
>>>>>>
>>>>>>  /in:Invoice/cac:TaxTotal/cbc:TaxAmount
>>>>>>  /in:Invoice/cac:InvoiceLine/cac:TaxTotal/cbc:TaxAmount
>>>>>>
>>>>>> ... so your level of granularity would not distinguish these two
>>
>>>>>> different
>>>>>> contexts.
>>>>>>
>>>>>>> If not I will try and build one myself.
>>>>>>
>>>>>> It would help if you could join the committee and contribute to
>>>>>> the work of
>>>>>> the HISC.  If not, then submitting your contributions through
>>>>>> the official
>>>>>> TC comment page is the way to have the committee formally
>>>>>> consider your
>>>>>> input:
>>>>>>
>>>>>>  http://www.oasis-open.org/committees/comments/form.php?
>>>>>> wg_abbrev=ubl
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> . . . . . . . . . . . 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
>>>
>>
>> ______________________________________________________________________
>> 'Do it online' with our growing range of online services -
>> http://www.bristol.gov.uk/services
>>
>> Sign-up for our email bulletin giving news, have-your-say and event
>> information at: http://www.bristol.gov.uk/newsdirect
>>
>> View webcasts of Council meetings at http://www.bristol.gov.uk/webcast
>>
>> ______________________________________________________________________
>> 'Do it online' with our growing range of online services - http://www.bristol.gov.uk/services
>>
>> Sign-up for our email bulletin giving news, have-your-say and event information at: http://www.bristol.gov.uk/newsdirect
>>
>> View webcasts of Council meetings at http://www.bristol.gov.uk/webcast
>>
>