Level of details of the class "Value"

[eprocurementontology]

Claude Schmit asked what represents the "value" class ? The total amount of an invoice ? This level of detail is probably sufficient in this first phase, but the ultimate goal is to provide transparency up to the lowest level of detail. For instance, the notion of "invoice line" does not exist. There is always a "price schedule" per "contract" which can be complex. An invoice always regroups 1..n "line" x quantity based on the price schedule.

[JachymHercher]

I would say this is not a problem with the value class, which should simply be a universal class for monetary values. It's rather a problem of missing classes linked to the invoice class (e.g. invoice line).

[makxdekkers]

In the latest version of the conceptual model (to be provided ahead of the WG meeting of 24 May 2017) the class 'Invoice' was renamed 'Monetary Value' which is the object of both the properties 'has net value' and 'has VAT' and refers to an decimal amount and a currency. For the 'invoice line', there is a note in the definition of Invoice: "it may be necessary to define smaller parts of Invoices in cases where an invoice contains ‘invoice lines’ related to specific items."
This issue should be further discussed by the Working Group.

[muricna]

I would tend to say you need both a monetary value (for the value of the contract - either estimated or actual) and another one for invoices which could be equal to the value of the contract or part values of the contract value

[makxdekkers]

Both Contract and Invoice are indeed related to the Monetary Value in the model:

• Contract "has net value" Monetary Value
• Invoice "has net value" Monetary Value
  Invoice also has a second relationship with Monetary Value for the VAT:
• Invoice "has VAT" Monetary Value

The relationship between the amounts on invoices and the amount for the contract can be found by selecting all invoices for a specific contract, then sum the net values on the invoices and compare with the net value of the contract.

[JachymHercher]

Contract can also have a VAT Monetary Value. In fact, generally speaking, pretty much everything in procurement can have both a VAT and a net value.

By the way, I only now realized that we could model anything either using relationships ("has net value", "has VAT value", "has Euro value", "has Sterling value") or using classes ("value" includes "VAT"; "value" has "currency"). Is there any difference we should keep mind when choosing one or the other?

[makxdekkers]

One of the issues to consider may be how many elements an approach requires. For example, the way monetary values are defined in the current model: one class Monetary Value with two properties (amount, currency), two properties that link to the class (net value, VAT). With that construct, any value in any currency can be expressed. With properties like euroValue, sterlingValue, you need to create properties for every currency. Of course, we could think of other arguments and thus can be further discussed.

[ocorcho]

In the case of PPROC, this is described as follows, using GoodRelations (just in case that it is useful in this discussion):

ex:contract_A/CEC/budget

rdf:type pproc:BundlePriceSpecifications ;

gr:hasCurrencyValue "50000.0"^^xsd:float ;

gr:valueAddedTaxIncluded "false"^^xsd:boolean ;

gr:hasCurrency "EUR"^^xsd:string .

[eprocurementontology]

On developing the ontology the contract has a procurement value which will needed to be reused/renamed when we come to the invoice. We could already discuss this now in one of our meetings.