Matching our IIAs with the partner's IIAs

[demilatof]

Yesterday, with my IRO, I tried to simulate the match between our IIAs and the partner's IIA.
After some attempts we realized that they need an abacus to keep track of everything.
The question is that we all have our old internal system that implements an IIA with rules and models that are suitable for our internal needs.

For example, we reserve places for EQF 6 and for EQF 7; this fact brings us 2 mobilities. The partner may have only one for both EQF 6 and 7.
About this point we can modify our rules, but this is not the problem.
The problem is that it is quite difficult to have two identical IIA, as we could think when we talk about an "agreement".
They are not two piece of paper with identical cooperation conditions, but they are two different digital interpretations of the same agreement.

We discovered that we may have 2 or more agreements that map 3 or more partner's agreements.
I don't know who made the EWP analysis on this point and how they thought to solve the problem.
Because we can think to match everything (and we are not sure it's enough), that is our 2 IIAs and 3 partner's IIA, but finally we have 6 couples. And our partner should have the same.

6 couples to notify (IIA CNR), 6 couples to serve (IIA Get), and so on.
Because the partner cannot download a single couple of our IIA: our IIA has been bound with 3 other IIAs, therefore it makes sense only if considered with 3 different partner's IIA-IDs.

Presently we have not yet implemented this eventuality, but we think we should do.
We have stopped ourself because having multiple IIAs matches would be even more troublesome with the new functionalities, e.g. TERMINATE.
Here you are an example: we have an IIA that spans over A and B IIA-IDs, our partner has the same, but it spans over X, Y and Z IDs.
Therefore to make a full match, the master-master model requires:

AX, AY, AZ
BX, BY, BZ

We decide to terminate unilaterally the A IIA, not B IIA.
What happens to our partner? He has X, Y and Z that are tied both to a terminated agreement (A) and to a not terminated agreement.
What should it do?
The most flexible solution could be transforming each single mobility in an agreement (we already have an ID for each mobility, we could easily transform them in agreement appending their ID to IIA-Id, e.g.: #).

Therefore, it would be really easy to make the match 1:1 and to exclude only a piece of agreements.

Are we the only with this problem?
Have you faced and resolved a similar problem?
Switching to coupling the mobilities instead of the agreements could be a solution?

[janinamincer-daszkiewicz]

I think that a document on Mandatory Business Requirements on IIAs addresses some of these issues.
https://github.com/erasmus-without-paper/ewp-specs-api-iias/blob/stable-v6/resources/mandatory_business_requirements_IIA.pdf

Also, please, have a look at:

• Child renewal strategy #66
• https://github.com/erasmus-without-paper/ewp-specs-api-iias#important-rules

[demilatof]

Thanks a lot for sharing, but all the documents seems to represent an ideal world, not a real one.

I think that a document on Mandatory Business Requirements on IIAs addresses some of these issues. https://github.com/erasmus-without-paper/ewp-specs-api-iias/blob/stable-v6/resources/mandatory_business_requirements_IIA.pdf

The above PDF says:
"EWP does not aim to over-standardise the process to respect organisational diversity and practices as much as possible while fully complying with the requirements of the European Commission"

This brings to confusion; everyone does as it wants.
Therefore, when it says "The copy of the agreement stored in each partners' systems must be presented to each other via the IIAs API as exactly one IIA having the same number of corresponding cooperation conditions." it represents a scenario that doesn't exist in the real world.
We have not, and we cannot have, a perfect matching 1:1 between our IIA an the partner IIA.
Not if we aim to keep the existing IIA, signed before EWP.
A solution could be:

all the IIAs that cannot respect the 1:1 rule must come to an end with a.y. 2023/24 and must be rewritten (and approved) following the new rules: only an IIA with multiple cooperation conditions. No IIA can span over more partner's IIA

Also, please, have a look at:

* [Child renewal strategy #66](https://github.com/erasmus-without-paper/ewp-specs-api-iias/issues/66)

This is more interesting, it is a similar discussion.
But I don't see a solution; they only confirm that in the real world every HEI has mapped the same IIA in different manners and spanning over more than an IIA Id.
As you wrote " issue has been discussed during the Infrastructure Forum on 2022-04-06. Participants voted for the 1:1 logic and matching identifiers" but we haven't moved from there, and now our IROs have to operate with IIAs that span over several IIA-Ids.

What I understand reading the above discussion is that internally each one can represent an IIA as it wants, doesn't matter if its approach complicates the other party's job.
I'm wrong?

[janinamincer-daszkiewicz]

Your local data model is your local business. In the network all should behave according to mandatory business requirements.
@pleys Please, have a look here.

[demilatof]

Your local data model is your local business. In the network all should behave according to mandatory business requirements. @pleys Please, have a look here.

Yes, it's a good declaration of intents.
After that we have the real world where we need 2 IIAs to represent 3 IIAs exposed by the partner.
There must be a shared rule that explains what to chose:

1. We have to split our 2 IIAs in 3
2. The partner must join its 3 IIAs and then split the result in 2
3. Both us and the partner must make a single IIA with matching cooperation conditions

I have to explain to my IROs why they have to do extra work, otherwise they can think that their extra work is due to my implementation that lacks of functionalities

[janinamincer-daszkiewicz]

In the first place your IRO might try to agree on some version with the partner. This is what IROs do now, as to my knowledge. Business requirements say that the informal negotiations take place before sharing IIAs via EWP.

I hope, that the others will share their experience.

[demilatof]

This could be done for the new IIAs, where both partners know that they have to bring all the IIAs to a match.
But we have more or less 500 IIAs (and >3.000 mobilities) exchanged in the old fashion to bring to EWP format.
The problem is here, every HEI has its digital representation of something that, with paper, was well defined.

[janinamincer-daszkiewicz]

Discussion continues in erasmus-without-paper/ewp-specs-api-iias-approval#3.