Academic years that span more than one programme period

[jiripetrzelka]

Some of the IIAs we get from partners start as far in the past as in 2008/2009 and some of the IIAs end as far in the future as in 2033/2034.

Examples:

• 2008/2009 - 2025/2026 (i.e. 2 previous programme periods + the current)
• 2017/2018 - 2022/2023 (i.e. 1 previous programme period + the current)
• 2023/2024 - 2033/2034 (i.e. the current programme period + the following)

What are the rules/recommendations for processing these proposals?

• Should server implementers allow their users to publish such IIAs in the EWP?
• Should client implementers report this to the Stats portal?
• Should client implementers disallow their users to approve any IIA which spans multiple programme periods?
• Should client IROs report it to the ESCI service desk?

Or should client IROs just keep reaching out to partners asking them to remove academic years from other programme periods? Or can client IROs accept this and approve an IIA for, for example 2017/2018 - 2025/2026 or 2023/2024 - 2033/2034?

[janinamincer-daszkiewicz]

I gathered such responses to your questions:

@kamil-olszewski-uw It's a business problem. Whatever business rules apply here, they should not be part of the EWP specification. That means, IT systems should not be obliged to check whether specific dates or academic years match the current edition of the Erasmus+ programme. In my opinion, everything should be up to the user - if they see "strange" data on the partner's side, they simply should not approve IIA in that form.

As for reporting such inappropriate data: On the one hand, it would be worth paying attention to some university that would notoriously use academic years from the distant past or the distant future. On the other, this is information that may change over time - e.g. due to force majeure, the duration of the program may be extended. One university will already know about it, the other will not, and false positive reports will appear.

Relationship Manager we discussed that systems are recommended to prevent such error by setting a boundary but there would not be an error message on the network level. This is because the programme period is always subject to change and therefore having hard restrictions on the network level would become outdated. So for this reason, I think the decision was to have things as they are currently in the specification?

[demilatof]

In my opinion, everything should be up to the user - if they see "strange" data on the partner's side, they simply should not approve IIA in that form.

But I think that if we accept this, we accept the fact that what is exposed on the network is not ready to be approved, as instead it has been repeated in the last months.

And it isn't only a question of academic years range: an HEI can expose two IIAs (one for the old period and one for the new) whilst the other one could expose a sum of the two IIAs that extends from the old period to the new one. This makes extremely difficult matching the two IIAs:

1. Who must change his IIAs? The one who needs to sum his IIAs or the one who has to split his IIA?
2. The cross check between two (or more) IIAs on one side and one (or more) on the other side to arrive to a single IIA on both sides is really cumbersome for the IROs

I think it could be useful a rule that compel to expose only the academic years starting from the incoming one (the one that hasn't yet any mobilities in effect). This rule, obviously, should be valid only until the IIAs are not mutually approved.

[jiripetrzelka]

Relationship Manager we discussed that systems are recommended to prevent such error by setting a boundary [...] So for this reason, I think the decision was to have things as they are currently in the specification?

Where exactly is this recommendation stated in the specification?

[janinamincer-daszkiewicz]

Relationship Manager we discussed that systems are recommended to prevent such error by setting a boundary [...] So for this reason, I think the decision was to have things as they are currently in the specification?

Where exactly is this recommendation stated in the specification?

I read the original statement as 'Let's keep the specification as it is'.

[jiripetrzelka]

I read the original statement as 'Let's keep the specification as it is'.

I too but considering that the first statement ("we discussed that systems are recommended to prevent such error by setting a boundary") is an indicative (i.e. not "we discussed that system would be recommended") it appears that the anonymous author of this statement thinks that this recommendation is already part of the specification and therefore no change is needed. So I ask - where is it?