Inconsistencies with Regulation and incorrect nesting @ Criteria #7 and #8

[sakispantazis]

Criteria 7, 8 (i.e. the question asking if the EO has met all its obligations relating to the payment of taxes or social security contributions)

The Regulation’s stipulations for these criteria are:

In the current implementation of the regulated v.2.x ESPD taxonomy/structure
a) the question for this criteria differs compared to the question stipulated in the Regulation: “Has the economic operator breached its obligations relating to the payment of taxes, both in the country in which it is established and in Member State of the contracting authority or contracting entity if other than the country of establishment?”, which seeks for a negative answer instead of a positive one. We implemented this criterion accordingly to the current ESPD taxonomy/structure. Hopefully all implementers have changed the question’s wording to match the ESPD taxonomy/structure. However, the following issue arises: should we change the Regulation accordingly to match the ESPD taxonomy/structure or vice versa? If it was up to me, sending a notification eMail to all implementers to double check the wording, would be enough. However, since it might have legal implications and because lawyers are rather attached to the wording, we might have to change one or the other. Notice: Changing the ESPD taxonomy/structure, would have the consequence that all ESPD artifacts completed so far will show a wrong answer.

b) Subquestion (d) of this criterion should always appear along with (a), (b), (c). Now it appears only if you answered yes to the question “Has this breach of obligations been established by means other than a judicial or administrative decision?”

c) In the subquestion (c ), there is a similar issue/inconsistency between ESPD taxonomy/structure and the Regulation. Again this subquestion should have a a different wording, i.e. “Has this breach of obligations been established through a judicial or administrative decision?”, instead of “Has this breach of obligations been established by means other than a judicial or administrative decision?”. According to the Regulation, a positive response refers to the “judicial/administrative decision” and not to the “other means”.
Here goes the same again as before: We implemented this sub-question/criterion accordingly to the current ESPD taxonomy/structure. Hopefully all implementers have changed the question’s wording to match the ESPD taxonomy/structure. However, the following issue arises: should we change the Regulation accordingly to match the ESPD taxonomy/structure or vice versa? If it was up to me, sending a notification eMail to all implementers to double check the wording, would be enough. However, since it might have legal implications and because lawyers are rather attached to the wording, we might have to change one or the other. Notice: Changing the ESPD taxonomy/structure, would have the consequence that all ESPD artifacts completed so far will show a wrong answer.

[mireiaBM]

a) and c) --> The wording will not be modified, as the wording is an issue related to the application/UI and not to the ESPD data model per se.

b) --> This issue will be addressed in version 3.0.0 of the ESPD data model. A possible workaround for you in the meantime, is to do the update in your own system.

[jerouris]

Dear Mireia, some remarks on your answer:
Re: a) and c), as it is also discussed in #246, this is not only an application/UI issue. The Criterion Taxonomy dictates what description of the requirements and also their relation, stating when a criterion should be answered according to answers by previous requirements (see the indicators, on_true, on_false, on* in the ESPD Taxonomy)
Since the ESPD Taxonomy is part of the EDM and in order to maintain interoperability, any changes required to fix a) and c) must pass through the EDM.

Re: b) unfortunately we are not able to simply change our system. The change will break the EDM, and thus the artifacts produced will not be validated against the EDM schematrons.

[JosePRevenga]

a) & c): The questions will not be modified as the exclusion grounds are to be answered always negatively to confirm that there is no law offendance. That is, in the ESPD Exchange Data Model, all exclusion criteria need to be answered negatively in order to skip subgroups of questions. The ESPD-EDM was semantically aligned to the Regulation after consultation with legal experts, so the content of the sentences in the EDM match the spirit of the law.

b) The Criterion data structure can indeed be improved by moving the group (d) inside the one above that encompasses (a), (b) and (c). However, as Jerry says, we cannot do it in v2.1.1, as this would break the backwards compatibility and interoperability. Thus, it will be implemented in v3.0.0.

[hricolor]

After the discussion of the issue in the OUC (Wednesday 17 of June), the sub-questions (d) which is currently nested under the question (c), will be placed at the same level as (a), (b), and (c).

This issue will be fixed in the new version of ESPD.

[rantati7]

#7 How should threshold in #7 be implemented when there is / are no thresholds for paying taxes? In Finland all taxes have to be payed and there is no threshold for not paying taxes or social contributions? Can we just leave this out or should it be included with e.g. instructions for EO that they should not fill in anything in this field (the same would need to be shown to EU in ESPD response....)

screenshot from ESPD response (eo view when replying)

[ec-mcs]

In Lithuania the threshold is 50 EUR.

We have two use cases here:

1. The CA in FI creates and ESPD request. As the threshold does not apply, it is not necessary to show it even. What I suggest is that the system will automatically fill 0 EUR.
2. An FI EO participates in LT. Here your service should be able to show the threshold.

So your service should be able to treat it. For an FI CA and an FI EO participating in this procedure, this information could not be shown at all.

[psotofer]

Greetings,
after providing detail on how to implement this scenario and since we did not receive additional comments we proceed to close this issue.
In case you need further detail regarding this topic, please open a new issue referencing this one.