Financial Offer Value

[JachymHercher]

In the ontology, the definition of "Financial offer value" is "Monetary amount for which the tenderer commits to fulfil a given part of the tender."

Why does this class exist? Shouldn't rather "Tender Lot" "have" "Price" ?

[muricna]

Further discussion is also required on the the relation of Financial Offer Value and Financial Tender document classes. WG 06/06/2019

[paulakeen]

The rationale for having it as a class Financial Offer Value is:

1. We need more than one attibute, not just "a price": Total Amount Without VAT, Total VAT Amount, Other charges, etc.
2. As these attributes are also needed for other purposes, e.g. for the "Procurement Value" we decided to separate them into a base class than can be reused by several other sub-classes.

If we had these attributes inside the Tender Lot we'd have to duplicate them in other places, which in our modelling philosophy/method is a anti-pattern.

See the diagram "Values" in the EAP file:

[JachymHercher]

I'm not sure I understand. "A price" also needs a VAT, a currency, etc.? It is clear that having a reusable class called something like "Monetary Value" which would have the properties of "value", "currency", some fields on VAT, etc. is reasonable. But in the diagram above:

1. What are "Charges"?
2. Why does "Procurement Value" contain "Tax Included Indicator"? Shouldn't that be obvious from "Value" either having some data in "Total Vat Amount" or not?
3. Why does "Procurement Value" contain "Overall Amount"? It seems as a duplication of a sum of the first two properties of "Value". If not, why isn't it in Value?
4. Shouldn't there be a currency codelist?

5. It's just a feeling, but it seems strange to have one instance of "Value" potentially containing three different numbers - overall, minimum, maximum. In that case, one instance of Procurement Value would need to point to three instances of Value.

   Wouldn't it be better to have a "Value Type" codelist, where you specify whether a value is minimal, maximal, final, etc.? Or, rather, taking into account https://github.com/eprocurementontology/eprocurementontology/issues/137#issuecomment-509648171, shouldn't this be expressed as predicates, i.e. "has value", "has minimal value", "has maximal value" etc.? This could also distinguish properties such as "has estimated value" vs. "has value".

[paulakeen]

0: About your first introductory sentence:

• Your suggestion of naming the class "Monetary Value" instead of "Value" make sense, because all the attributes of this class are Amounts. In any case we wouldn't call it "Price" (it was decided not to);
• In the ePO we made the decision of modelling Amounts using the ISO 15000-5:2016 (UN/CEFACT CCTS) types. The component "AmountType" has the attribute "currencyID" which is used to indicate what currency this amount is referred to. So there's no need to add new things to the class "Monetary Value" (if we end up calling it like that, following your proposal);
• VATs are also amount, therefore they need to be an attribute of the class together with its own metadata (i.e. the currency of the amount representing the VAT);

1: About "Charges": this attribute (an Amount, too) was suggested by Andrea, the CEN Chairman, and Cécile, as it is used also in eInvoicing. Apparently some Monetary Values are charged not only with VAT but sometimes also with one unspecified "other charges" amount. In Italy and Spain, for instance, the publication of the procurement documents (including all the notices and everything) in the official gazettes are charged to the winner.

2: About the need for the VAT Indicator in Procurement Value: a 0% value in the class "Monetary Value" does not entail that there's not VAT defined. Think of situations where the VAT exists and is of type "0%", for example. In Spain, at least, that is the case for educational services (teaching is charged with 0% VAT type).

3. If it was in Value (Monetary Value) then all the descendant classes would inherit it, and it is not need it for all descendants, e.g. the tenderer Financial Offer Value does not need this OverallAmount property.

4. Yes, it should. And we have it. It's named "currency", but it was difficult to represent it in the diagram as it is connected to the "attribute" currencyID of each "attribute" Amount...we'll workaround this representational issue in the Diagrams (see figure below).

5. Your suggestion of having three "object properties" (links) between the class "Procurement Value" and "Monetary Value" is perfectly aligned to the design rule of not having them as "data properties" inside the class when possible. YOU UNDERSTOOD VERY WELL OUR DESIGN METHODOLY, in this case!!! Thank you. So we've changed this in our diagram. This means that, as you point out in your bullet Nº 5, three differents instances of Monetary Value will be necessary as the "ranges" of the new object properties "hasOverallAmount", "hasMinimumAmount" and "hasMaximumAmount".

WG Approval 11/07/2019

[JachymHercher]

0 & 1 & 4 - Clear, thank you. 2 Clear. (This could perhaps be distinguished by "missing" vs. "0", but indeed, it's better to do it explicitly.) 3 Not clear, yet. May I ask what is the definition or use case of "OverallAmount"? 5 What about estimated value? (In eForms, this essentially means "a value estimated when publishing the call for competition") What about any combinations (e.g. estimated value; estimated maximum; estimated minimum),

[JachymHercher]

(May I ask you to reopen the issue, please? Just not to forget about it.)

[eprocurementontology]

Financial Offer Value no longer exists in the ontology but we are revisiting how amounts and values are to be treated.

[andreea-pasare]

In ePO v4.0.0-rc.1 the Monetary Value is modeled as depicted below:

This is just one of the monetary values diagrams. For further diagrams you can consult the specific folder from the release: