[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Test Assertions for UBL Calculation Model? Re: Re: [ubl-dev] Basic Invoice Exploration
I added to wiki what could be a possible start on which entities need the calculation assertions http://wiki.oasis-open.org/ubl/Example_Calculation_Models?action=diff&rev2=21&rev1=20 I realise it's a little different to your proposed way forward Ken. I'm more inclined to think the way to go is to set up a project for assertions about the calculation model which feeds directly into the UBL TC and its process for authoritative approval rather than start with a more distant model like the OIO-UBL one which might be seen as a customisation model rather than official UBL TC one. This is taking into account advice I was getting about the authoring of test assertions in support of a spec from the Java spec/conformance guys from Sun and the JCP in the OASIS Test Assertions Guidelines TC. I actually think the lessons of software engineering are applicable to documents too and that conformance and quality assurance for interoperability, etc can be improved in document standards the same way they can in software (and other engineering) standards like Java - by the kinds of steps we outlined in the Test Assertions Guidelines http://lists.oasis-open.org/archives/tag/200906/msg00000.html (now voted suitable for public review) TestAssertionsGuidelines-draft-1-0-5.pdf Latest draft link updated here http://wiki.oasis-open.org/tag/TestAssertionGuidelines We are close to having a usable markup for this which for a document standard like UBL could even be written so as to be executable as a test suite for conformance and/or interoperability http://www.oasis-open.org/apps/group_public/download.php/33024/TestAssertionMarkup-0-3.zip Maybe I could even get some funding from somewhere to help as I think it could take a fair bit of time to produce the test assertions for a calculation model for UBL (maybe months) - and to pass comments regarding ambiguities and gaps back to the UBL TC along with seeking their approval of test assertions and supporting comments. Best regards Steve Stephen D Green Document Engineering Services Ltd 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 >> >> > -- Stephen D Green
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]