Supporting changes to an IIA

[BavoNootaert]

Some of the elements of an IIA are allowed to change in the course of the agreement, such as mobilities-per-year.

Such changes could be added as amendments to the agreement. In this proposal we will try to stay as close as possible to the current model, that the IIAs are read-only and distributed, and discussion on changes is done through some other medium, e.g. telephone or e-mail. However, miscommunication is always a possibility and errors may need to be corrected. The API must allow for such corrections.

Each amendment has a validity period, and some changes.

The element amendment would not contain all the elements from student-studies-mobility-spec, but only those that are allowed to be changed.

Approval can be supported by the same method as approving the entire IIA as proposed here. E.g. choosing method I from this issue, approval can be supported by including a status associated with the SCHAC-code of the approving partner. Initially one HEI would send a notification to the partner that the IIA has changed. The partner retrieves the IIA with the new amendment, already approved by the initiating partner. If the other partner agrees, it adds an approval element with its own SCHAC-code and sends a notification. If it does not approve, it discussed with the partner (e-mail or telephone), and eventually a new amendment may be added.

There can be several amendments, for different academic years. If there are conflicting amendments for the same year, these need to be resolved by one of the partners rejecting one of the amendments. An id facilitates identifying an amendment. This can be anything, but prefarably a UUID. It is not allowed to change approved amendments otherwise than rejecting it. Only new ones can be added, possibly overriding a previous one, which must be rejected.

Early termination of the agreement would be accomodated by reducing the mobilities-per-year to 0 for the remaining years.

In xml this proposal would look like this (only showing the relevant elements, using method I from the proposal for supporting status

<iaa>
    <partner>
        <hei-id>uw.edu.pl</hei-id>
    </partner>
    <partner>
        <hei-id>ugent.be</hei-id>
    </partner>
    <cooperation-conditions>
        <student-studies-mobility-spec>
            <receiving-academic-year-id>2014/2015</receiving-academic-year-id>
			<receiving-academic-year-id>2015/2016</receiving-academic-year-id>
			<receiving-academic-year-id>2016/2017</receiving-academic-year-id>
			<receiving-academic-year-id>2017/2018</receiving-academic-year-id>
			<receiving-academic-year-id>2018/2019</receiving-academic-year-id>
			<receiving-academic-year-id>2019/2020</receiving-academic-year-id>
            <receiving-academic-year-id>2020/2021</receiving-academic-year-id>
            <mobilities-per-year>2</mobilities-per-year>
         </student-studies-mobility-spec>
    </cooperation-conditions>
    <amendments>
        <amendment id="152929a8-e487-4b59-ad90-35c22985668e">
			<receiving-academic-year-id>2016/2017</receiving-academic-year-id>
            <mobilities-per-year>10</mobilities-per-year>
            <current-status>
                <partner-id>uw.edu.pl</parnter-id>
                <status>APPROVED</status>
            </current-status>
            <current-status>
                <partner-id>ugent.be</parnter-id>
                <status>APPROVED</status>
            </current-status>
        </amendment>
        <amendment id="42a238a1-f08c-4b92-b3e6-bea0e31b84ab">
			<receiving-academic-year-id>2017/2018</receiving-academic-year-id>
            <mobilities-per-year>5</mobilities-per-year>
            <current-status>
                <partner-id>ugent.be</parnter-id>
                <status>APPROVED</status>
            </current-status>
        </amendment>
    </amendments>
</iia>

[janinamincer-daszkiewicz]

The problem with this proposal is that in fact we do not know how the IIAs are stored in the local databases. For example in Warsaw we do not keep the history of changes in IIAs so we would not be able to send information as described in the example. We would just split the period, let say 2012-2015, into two periods with different numbers of mobilities, loosing the infomrmation, that before the change the number for the second period was different.
I do not say that this is a good solution but it is like that at the moment. And we are just one of the many institutions which might have their own local peculiar way of modeling data. This is one of the reasons Wojtek decided to specify the solution which is as generic as possible.

So the first question is - does every partner is supposed to keep all previous versions? Is this a formal requirement? Couldn't we just send the new version of the IIA?

[georgschermann]

The example would result in the more or less equivalent IIA:

<iaa>
    <partner>
        <hei-id>uw.edu.pl</hei-id>
    </partner>
    <partner>
        <hei-id>ugent.be</hei-id>
    </partner>
    <cooperation-conditions>
        <student-studies-mobility-spec>
            <receiving-academic-year-id>2014/2015</receiving-academic-year-id>
			<receiving-academic-year-id>2015/2016</receiving-academic-year-id>
<!--
			<receiving-academic-year-id>2016/2017</receiving-academic-year-id>
			<receiving-academic-year-id>2017/2018</receiving-academic-year-id>
-->
			<receiving-academic-year-id>2018/2019</receiving-academic-year-id>
			<receiving-academic-year-id>2019/2020</receiving-academic-year-id>
            <receiving-academic-year-id>2020/2021</receiving-academic-year-id>
            <mobilities-per-year>2</mobilities-per-year>
         </student-studies-mobility-spec>
    </cooperation-conditions>
    <cooperation-conditions>
        <student-studies-mobility-spec>
            <receiving-academic-year-id>2016/2017</receiving-academic-year-id>
            <mobilities-per-year>10</mobilities-per-year>
        </student-studies-mobility-spec>
    </cooperation-conditions>
    <cooperation-conditions>
        <student-studies-mobility-spec>
            <receiving-academic-year-id>2017/2018</receiving-academic-year-id>
            <mobilities-per-year>5</mobilities-per-year>
         </student-studies-mobility-spec>
    </cooperation-conditions>
</iia>

These changes could change the status of the whole IIA or we could use a status for each cooperation condition.
Different status for different cooperation-conditions with overlapping duration would be possible, but only one 'approved' coop-condition, so the moment the amendment would become approved it would replace the initial coop-condition.
Currently we don't have any means to store different versions of agreements in our database. We have a local and a remote representation of the agreement and the moment the remote version is accepted/rejected/merged the remote version ceases to exist and the local version is changed. During this process the IO staff decides if the agreement changes status and needs to be resigned, etc.
So I suggest to keep the coop-conditions and maybe mark the whole IIA or coop-conditions as changed/proposal/suggestion/amendment.

[janinamincer-daszkiewicz]

Let me remind you that the basic general assumption is that the discussion about the details is carried outside the EWP system. To tell the truth, we still do not understand why the simplest approach, where after this discussion one of the partner sends the new version of the agreement and asks the other partner for approval, is not sufficient?

@BavoNootaert , @pleys , could you tell us where and why exactly in your system this extra amendment is necessary?

[pleys]

We can forget about the functionality for changing an approved agreement. Given the digital infrastructure that EWP offers, institutions can easily create a new agreement via EWP