[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-dev] Test Assertions for UBL Calculation Model?
Absolutely. I agree.
---
Stephen D Green
2009/9/18 Roberto Cisternino <roberto@javest.com>:
>
>> Hi Stephen,
> Hi,
>
> just a short note.
>
> Roberto
>
>>
>> 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.
>
> The UBL Spec says:
>
> - LegalMonetaryTotal/LineExtensionAmount
> The total of Line Extension Amounts net of tax and settlement discounts,
> but inclusive of any applicable rounding amount.
>
> - LineExtensionAmount at the line level
> The total amount for the Invoice Line, including Allowance Charges but net
> of taxes.
>
> So firstly there is an issue in UBL 2.0 because at the line level
> Allowances/Charges are included but not in
> LegalMonetaryTotal/LineExtensionAmount.
>
> I think that the definiton for LegalMonetaryTotal/LineExtensionAmount is
> wrong and should be similar to the LineExtensionAmount in the line items.
>
> So, I agree with:
>
> [Sum of all LineExtensionAmounts at line level]
>
> .. but we should fix the above definition.
>
>>
>>> 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
>>>
>>
>>
>
>
> --
> * JAVEST by Roberto Cisternino
> *
> * Document Engineering Services Ltd. - Alliance Member
> * UBL Italian Localization SubCommittee (ITLSC), co-Chair
> * UBL Online Community editorial board member (ubl.xml.org)
> * Italian UBL Advisor
>
> Roberto Cisternino
>
> mobile: +39 328 2148123
> skype: roberto.cisternino.ubl-itlsc
>
> [UBL Technical Committee]
> http://www.oasis-open.org/committees/ubl
>
> [UBL Online Community]
> http://ubl.xml.org
>
> [UBL International Conferences]
> http://www.ublconference.org
>
> [UBL Italian Localization Subcommittee]
> http://www.oasis-open.org/committees/ubl-itlsc
>
> [Iniziativa divulgativa UBL Italia]
> http://www.ubl-italia.org
>
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]