OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ubl-dev] Test Assertions for UBL Calculation Model? Re: Re: [ubl-dev] Basic Invoice Exploration


Just about to start making such a list.

I don't think it is very complex at all, except for the
'corner cases'. I expect mostly for tax it will be
the totals and the line extension amounts and maybe
the payment terms (for settlement allowances/charges).
The complex bits are, like Fulton alluded, in the systems
sending the documents.

I don't think price comes into it (that is hidden behind
line extension amount which doesn't have show how
it was calculated).

Stephen D Green



2009/6/24  <jaymuz@optusnet.com.au>:
> 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?
>
> 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
>
> If not I will try and build one myself.
>
>
>> Stephen Green <stephen.green@documentengineeringservices.com> wrote:
>>
>> 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&rev
>> 2=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/TestAssert
>> ionMarkup-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
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
>> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]