Do we need ounit on the IIA level?

[janinamincer-daszkiewicz]

As mentioned at the Infrastructure Forum meeting on 2023-05-17 we consider removal of ounit on the IIA level, i.e.
https://github.com/erasmus-without-paper/ewp-specs-api-iias/blob/83a208eb83bb6a93525f8e8b036d41a5e406484a/endpoints/get-response.xsd#L83

According to Kamil (UW)
Organizational unit on IIA level was added some years ago by special request. Quoting the description of the "ounit-id" element in the API: "Optional organizational unit surrogate ID. If given, then it refers to the unit within the partner HEI's organizational structure, which is the actual partner of this agreement. Agreements can be signed between units, not only between HEIs: #11".

Maybe someone will actually use it for this purpose, but I have not encountered such a situation. Most often, users (incorrectly) enter here the unit that exclusively appears in cooperation conditions, instead of leaving it blank. It's very hard to explain to them what it's really about. So maybe we should get rid of this field or change its use so that it doesn't just apply to "current partners of agreement"?

I have never come across a situation where this field indicated that one of the partners is part of a larger consortium or an autonomous branch of the university. However, with whom you would not test, they use this field to show that the terms of cooperation apply to the exchange with only one faculty.

We could add more explanation on how not to use this field, but do we really need it?
We propose to remove. Please let us know if you think that this is not a good idea.

See also #71.

[spinho-uporto]

In UPorto, we are using ounit on the IIA level.

"...unit within the partner HEI's organizational structure, which is the actual partner of this agreement. Agreements can be signed between units, not only between HEIs: "

"...they use this field to show that the terms of cooperation apply to the exchange with only one faculty."

That is precisely our case. Each Faculty manage their IIAs. The cooperation conditions are all for the same ounit indicated in the IIA level.

[demilatof]

We propose to remove. Please let us know if you think that this is not a good idea.

I'm afraid that if we remove this element, we'll go in trouble with some HEIs.
As @spinho-uporto said, there are situation where we really need this information to avoid other problems.

If you wish, I may list you HEIs that in our old architecture we have had to identify with a sub-code because they have the same Erasmus Code but several institutions that are involved in the signing process.
If you can assure that every HEIs has only a central office that signs the IIA, we may remove this information, otherwise it could be better to keep it.

[janinamincer-daszkiewicz]

If you wish, I may list you HEIs that in our old architecture we have had to identify with a sub-code because they have the same Erasmus Code but several institutions that are involved in the signing process.

This is something to talk about with DG EAC. Hopefully they can help us in resolving such issues. We should know if the Erasmus+ programme allows such situations.

[spinho-uporto]

I didn't say we are more than one institution with only one Erasmus Code.
We are only one institution with one Erasmus Code. What happens is that each of the Faculties manages their agreements and makes the negotiation with partners.

[demilatof]

I didn't say we are more than one institution with only one Erasmus Code.
We are only one institution with one Erasmus Code. What happens is that each of the Faculties manages their agreements and makes the negotiation with partners.

My bad; to explain better what I meant I need to describe the origin of our solution.
In our implementation, we initially had only institutions; when we realized that there were more faculties involved in the signing process, we have had to add them as if they were institutions (because our internal primary key is Erasmus Code).
Therefore, internally we call institutions what are faculties as a matter of fact.

[georgschermann]

we have lots of HEIs where the faculties manage and sign the IIAs autonomously. Consortia are usually not an issue here, since every HEI of the consortia has their own schac. We also have several HEIs where different faculties have their own IOs using different EWP providers.

[janinamincer-daszkiewicz]

@spinho-uporto How should your partner treat an XML where on a global level you have faculty X, an among ounits on a CC level you have a mix of ounits, not only X but also Y?

[demilatof]

We also have several HEIs where different faculties have their own IOs using different EWP providers.

@georgschermann I don't fully understand this point.
Do you mean that you have an HEI MASTER, with fac1, fac2, fac3 where fac1 has provider1, fac2 provider2, and so on?
What HEI ID they use?
How can different providers use the same HEI ID for the same APIs?

[demilatof]

@spinho-uporto How should your partner treat an XML where on a global level you have faculty X, an among ounits on a CC level you have a mix of ounits, not only X but also Y?

I don't see any problem in this case.
The specifications don't say that we have to use the same ounit everywhere in the get-response.
We may have the O1 onit in the partner section, O2 in the first mobility, O3 in the third and so on.
It's up to the local implementation to address the IIA to O1 and be sure that O1 has the authority over O2 and O3 for signing/managing IIAs

[georgschermann]

@spinho-uporto How should your partner treat an XML where on a global level you have faculty X, an among ounits on a CC level you have a mix of ounits, not only X but also Y?

this would lead to interesting problems in our case since the iia would be managed by the faculty in the partner block and in many cases it would only be able to manage its own faculty, rendering it unable to manage the CCs for other faculties.
for different ounits on the partner side, there may be minor issues with importing, choosing, assigning the correct facutlies to the CCs

We also have several HEIs where different faculties have their own IOs using different EWP providers.

@georgschermann I don't fully understand this point. Do you mean that you have an HEI MASTER, with fac1, fac2, fac3 where fac1 has provider1, fac2 provider2, and so on? What HEI ID they use?

this is a common case and was in fact identified during the inital design of the APIs here also already identifying the exact challenges we face now

How can different providers use the same HEI ID for the same APIs?

thats the neat part, they can't.
This is already in discussion with the EWP team, but I have to check if there is an open issue for it. Basically we need the possibility for manifests on a faculty level, or "sub-schac-codes". Until the registry was checked against the ECHE list and checked for Erasmus Code duplicates we had some HEIs with multiple faculties listed in the registry [].
We also provide the possibility to only manage in/out learning agreements and have some internal API-proxies, but these only work across our own systems.

[spinho-uporto]

@janinamincer-daszkiewicz

@spinho-uporto How should your partner treat an XML where on a global level you have faculty X, an among ounits on a CC level you have a mix of ounits, not only X but also Y?

I think this has to be specified. In particular, what is the meaning in such cases.
Our XML has our unit only at iia level. I don't know in what cases happens the situation you expose, or if they exists.

[janinamincer-daszkiewicz]

I am still not convinced that we really need ounit on a global level, especially because it can add to the confusion. But let's continue. Is such statement true:

1. Ounit on a global level is the one in charge, the real 'signer'.
2. Ounits on a CCs level are the units which handle the organizational aspect of the agreement.
3. There is no correlation between (1) and (2).

[demilatof]

I am still not convinced that we really need ounit on a global level, especially because it can add to the confusion. But let's continue. Is such statement true:

1. Ounit on a global level is the one in charge, the real 'signer'.

2. Ounits on a CCs level are the units which  handle the organizational aspect of the agreement.

3. There is no correlation between (1) and (2).

In my opinion, this is correct; as concern point 2, in our implementation the ounits are our departments and we also use them to filter the application of outgoing students (they can apply for a place only if it is associated to their department).

[janinamincer-daszkiewicz]

So instead of removing we may try to better explain in the specification the role of this parameter. Do you have any concrete proposal?

[demilatof]

So instead of removing we may try to better explain in the specification the role of this parameter. Do you have any concrete proposal?

As in other situation, the response explains better requirements than the description page.
We can use the sentences in the response.xsd:

Optional organizational unit surrogate ID. If given, then it refers to the unit
within the partner HEI's organizational structure, which is the actual partner
of this agreement. Agreements can be signed between units, not only between
HEIs: #11

If provided, then it MUST have the value of the "official" ounit-id, exactly as
it has been assigned by the partner HEI in its Organizational Units API. If
this official ID is not known by the server (and it often isn't), then this
element MUST be skipped. This is a surrogate ID, so it SHOULD NOT be displayed
to the user (use ounit-code for that).

What I don't understand is the link to #11 , it doesn't seem too much pertinent.