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


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]