Queries on the mandatory business requirements document

[ipnreddy]

In the Mandatory business requirements (https://github.com/erasmus-without-paper/ewp-specs-api-iias/pull/104/files), certain items require further clarification. Can anyone help answer these?

1. In page 7, it is mentioned that partners should be informed when Factsheet changes, but there's no Factsheet CNR. Is there a plan to introduce this?
2. In page 8, it is mentioned that when an agreement is approved by both partners, one or the other can modify it. This contradicts what was mentioned about "It may happen that in time the signed IIA needs to be terminated, extended or modified for good reasons. Future changes in specifications will support such needs." There is currently no specification against modification of the IIAs once both have been approved. So, how should we interpret this? Should we not allow IIAs to be modified once both have been approved until a specific field or option is added in the IIA? 
3. In page 9, it is mentioned that it is possible to renegotiate/expand/pause the agreement. Will this be a new change in the specification?
4. In page 9, it is mentioned that both linked IIAs must have the same number of cooperation conditions. This seems to be a new change. Is this a new validation that must be implemented?
5. In page 10, it is mentioned that agreement duration shouldn't be more than the duration of the Erasmus+ programme. There is no such validation in the specification. Is this something we have to implement?

[janinamincer-daszkiewicz]

ad. 1 Please read https://github.com/erasmus-without-paper/ewp-specs-api-factsheet/issues/2.

ad. 2 and 3 The discussion on these changes goes on during the Infrastructure Forum meetings and in GitHub issues (e.g. https://github.com/erasmus-without-paper/ewp-specs-api-iias/issues/99). We should come to a conclusion soon.

ad. 4 See https://github.com/erasmus-without-paper/ewp-specs-api-iias#important-rules

ad. 5 I think so

[umesh-qs]

ad. 1 Please read erasmus-without-paper/ewp-specs-api-factsheet#2.

ad. 2 and 3 The discussion on these changes goes on during the Infrastructure Forum meetings and in GitHub issues (e.g. #99). We should come to a conclusion soon. @janinamincer-daszkiewicz if it is not finalized why is it part of important rules?

ad. 4 See https://github.com/erasmus-without-paper/ewp-specs-api-iias#important-rules

@janinamincer-daszkiewicz these are added recently and unilaterally. There has been no voting/consensus taken from the community

ad. 5 I think so

[janinamincer-daszkiewicz]

if it is not finalized why is it part of important rules?

It is part of business requirements which came first

[umesh-qs]

We should come to a conclusion soon.

You never stop to amuse me. On one hand you say "We should come to a conclusion soon." and on other hand you publish new rules by saying "It is part of business requirements which came first".

[janinamincer-daszkiewicz]

Business Requirement Documents are not new, they have been created as part of the Action Plan some time ago, approved by DG EAC, announced (as I remember) for the first time during the technical workshops in September (@pleys was presenting them remotly), presented during the Infrastructure Forum (e.g. 2022-11-16), uploaded to GitHub.

[umesh-qs]

Business Requirement Documents are not new, they have been created as part of the Action Plan some time ago, approved by DG EAC, announced (as I remember) for the first time during the technical workshops in September (@pleys was presenting them remotly), presented during the Infrastructure Forum (e.g. 2022-11-16), uploaded to GitHub.

@janinamincer-daszkiewicz again random reply. Let me ask this in some other way. Are you saying that you are 100% sure that final outcome of the discussion will be that changes in the approved IIA will not be allowed.

[pleys]

At the last IF meeting DG EAC clearly explained how changes to the APIs are prioritised based on programme rules & mandatory business requirements. Hence the elaborate discussions at various IF meetings about modificaitons of approved IIAs, deletion of non-approved IIAs & termination that are not yet (fully) supported by the current version of the API.

[umesh-qs]

At the last IF meeting DG EAC clearly explained how changes to the APIs are prioritised based on programme rules & mandatory business requirements. Hence the elaborate discussions at various IF meetings about modificaitons of approved IIAs, deletion of non-approved IIAs & termination that are not yet (fully) supported by the current version of the API.

Hi @pleys, in the last IF meeting it was decided that will not make changes to the specifications regarding introducing new/better ways of handling this. It does not mean that it will not be allowed as it is being done currently by some/many providers.

[umesh-qs]

At the last IF meeting DG EAC clearly explained how changes to the APIs are prioritised based on programme rules & mandatory business requirements. Hence the elaborate discussions at various IF meetings about modificaitons of approved IIAs, deletion of non-approved IIAs & termination that are not yet (fully) supported by the current version of the API.

Hi @pleys, in the last IF meeting it was decided that will not make changes to the specifications regarding introducing new/better ways of handling this. It does not mean that it will not be allowed as it is being done currently by some/many providers.

@pleys looks like you and Janina are not on same page. You say it is already decided in last IF meeting and Janina is saying it is under discussion.

[pleys]

Hello @umesh-qs Where do I say it is already decided in last IF meeting? I just refer to the DG EAC clarification about priorities

[umesh-qs]

@pleys Ok then it is the same question to you. If it is not decided then how can it be added in the specifications. This conversation is about what is added in the specification. I am not sure what difference it makes to this discussion when you say "I just refer to the DG EAC clarification about priorities".

[ipnreddy]

Regarding the number of cooperation conditions being the same - can we assume that this check is to be made only at the time of approval? Second, on the program duration - Should we only allow academic years from 2021 to 2027 which is the current programme duration? Currently, this might be possible, but in future, how do we deal with it? For example - in the year 2027, will we allow only agreements made for that year? I would assume that universities might want to start creating agreements for the next programme a year or so before the programme start date. Please suggest how we can implement this. Thanks.

[pleys]

Hello @ipnreddy, the inter-institutional agreements are always valid for a given programme period. See the official IIA template for eligible duration of the current IIAs. In 2028 instititutions need to renew/create new agreements for the next programme period. So today it is not possible to have and IIA for 2023 - 2033.

[ipnreddy]

@pleys - I understand that the agreements will not be valid. My question however, was how to implement that in a software. Q1: When we say 2027, does it mean academic year 2026-27 or 2027-28? Q2: How do we handle agreements for future Erasmus periods? As an example, University A creates an IIA for the period 2023-24 to 2026-27 - This is accepted. A tries to create a new IIA 2025-26 to 2030-31 - Since one of the years is in the current Erasmus period, this is not valid. Finally A tries to create a new IIA 2028-29 to 2030-31. Since both years are within the next Erasmus period - will this be a valid agreement? Q3: How do you propose to implement this restriction in the API? Especially considering that we have a list of years rather than a start/end year, this might be tricky. I hope that made sense. Thanks.

[jiripetrzelka]

In determing the accepted set of academic years for the current programme period, I use the Editable bilateral agreement (intra-European mobility) link at https://erasmus-plus.ec.europa.eu/resources-and-tools/inter-institutional-agreement

The first accepted academic year is therefore 2021/2022 and the last accepted academic year is 2028/2029. I therefore assume that the first accepted academic year of the next programme period will be 2029/2030.

@ipnreddy So an IIA for the period 2028/2029 - 2030/2031 is not valid because its spans two programme periods.

@pleys Please confirm whether this is correct.

[umesh-qs]

@jiripetrzelka thanks for digging in providing these details. Will have to wait for confirmation from @pleys on this and other points. Sooner we have clarity better it is for the network and less problems for the users later on.