Handling OUnits

[hwManSop]

Hello,

I'd like your input on how you handle OUnits in your IIAs.

We have the problem that in our IIA creation we allow the users to put OUnits in their partner element and also in their conditions (as available in the API). After releasing the IIA into the network our partner maps it but returns it without our OUnit Elements, because for example they aren't able to manage ounits in their system (for whatever reason).

The ounit-id element has the following description:

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: https://github.com/erasmus-without-paper/ewp-specs-api-iias/issues/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).

I don't quite understand the part where it says "If this official ID is not know by the server .... this element MUST be skipped". Does this mean that if the partner decides they don't save ounits - they in fact do not know them - that they then can just skip this element? For us it then looks like they have changed the IIA and we update our IIA accordingly - which is a problem for our customers.

Now my concrete question: Is the partner allowed to simply "not save" the ounit-id element and thus skip it in their version even if we provided it in the first place?

Does anyone else have this problem?

Thanks and best regards, Manuel

[kamil-olszewski-uw]

The ounit-id element should be used in rare cases where the unit is an official partner. And it's not just that all cooperation conditions apply to mobilities to and from this unit. This field should be filled in, for example, when such a unit is an autonomous branch of a university with its own IRO and a separate budget for mobilities.

The onunit-id element is not part of the cooperation conditions, so its presence in the partner copy of the agreement is not critical. If both parties agree that this is not a problem for them, then they can agree to this lack of organizational unit.

[umesh-qs]

Hello,

I'd like your input on how you handle OUnits in your IIAs.

We have the problem that in our IIA creation we allow the users to put OUnits in their partner element and also in their conditions (as available in the API). After releasing the IIA into the network our partner maps it but returns it without our OUnit Elements, because for example they aren't able to manage ounits in their system (for whatever reason).

The ounit-id element has the following description:

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).

I don't quite understand the part where it says "If this official ID is not know by the server .... this element MUST be skipped". Does this mean that if the partner decides they don't save ounits - they in fact do not know them - that they then can just skip this element? For us it then looks like they have changed the IIA and we update our IIA accordingly - which is a problem for our customers.

Now my concrete question: Is the partner allowed to simply "not save" the ounit-id element and thus skip it in their version even if we provided it in the first place?

Does anyone else have this problem?

Thanks and best regards, Manuel

How would it mean that they have changed the IIA. It is a change only if they change their copy vis a vis last version. It depends on you local implementation. This is not a problem for us or most of the service providers.

[jiripetrzelka]

I think the question was also about sending-ounit-id and receiving-ounit-id inside the cooperation conditions and this data is crucial for determining which unit can actually realize the mobility.

@kamil-olszewski-uw If the sending-ounit-id or receiving-ounit-id is missing in partner's IIA, should the counterparty interpret this as an indication that the mobility can be realized by any unit, i.e. that it is a university-wide agreement/specification? If not and the absence of this information can also have other meanings, such as unilateral decision to not store partners' or own ounits in the IIAs then I think that there should be a new attribute added in the IIA that would clearly distinguish these two scenarios and leave no room for ambiguity.

[umesh-qs]

I think the question was also about sending-ounit-id and receiving-ounit-id inside the cooperation conditions and this data is crucial for determining which unit can actually realize the mobility.

@kamil-olszewski-uw If the sending-ounit-id or receiving-ounit-id is missing in partner's IIA, should the counterparty interpret this as an indication that the mobility can be realized by any unit, i.e. that it is a university-wide agreement/specification? If not and the absence of this information can also have other meanings, such as unilateral decision to not store partners' or own ounits in the IIAs then I think that there should be a new attribute added in the IIA that would clearly distinguish these two scenarios and leave no room for ambiguity.

I think the question is more on how to handle this technically. But if it is what you say, then it is up to the partners to decide on how they want to proceed. They always have option to ask partner to make changes to the IIA before approving.

[kamil-olszewski-uw]

@kamil-olszewski-uw If the sending-ounit-id or receiving-ounit-id is missing in partner's IIA, should the counterparty interpret this as an indication that the mobility can be realized by any unit, i.e. that it is a university-wide agreement/specification? If not and the absence of this information can also have other meanings, such as unilateral decision to not store partners' or own ounits in the IIAs then I think that there should be a new attribute added in the IIA that would clearly distinguish these two scenarios and leave no room for ambiguity.

I think the question is more on how to handle this technically. But if it is what you say, then it is up to the partners to decide on how they want to proceed. They always have option to ask partner to make changes to the IIA before approving.

Yes, I think this matter is more business than technical. There are universities without a clear hierarchy (e.g. without faculties at all). There are also agreements for the entire university (although, in my experience, this applies more to non-Erasmus agreements, which often don't even include cooperation conditions). In fact, each case is individual and any ambiguities can be explained in "other-info-terms".

[jiripetrzelka]

Yes, I think this matter is more business than technical. There are universities without a clear hierarchy (e.g. without faculties at all). There are also agreements for the entire university (although, in my experience, this applies more to non-Erasmus agreements, which often don't even include cooperation conditions). In fact, each case is individual and any ambiguities can be explained in "other-info-terms".

This makes sense if partner's HEI has no clear hierarchy and we speak about partner unit ID inside both my and partner's IIA. But what if my HEI does have clear hierarchy and my IIA contains my unit ID? Can partner tell me that they won't insert my unit ID in their IIA? Some partners do this and the reason is that their provider has not implemented this option yet. Am I right that such a system is not fit for purpose?

[kamil-olszewski-uw]

This matter is a bit delicate. In this case, you can refuse to sign the agreement and require the partner to upgrade their system. But it can also be disadvantageous for you if you want to sign this agreement quickly. You can try to get around this by typing unit codes into other-info-terms as well. It can also be considered that such minor differences on both sides do not affect the rules of this IIA, because, for example, it doesn't really matter which partner unit the student comes from, as long as the mobility takes place within a specific ISCED field.

[demilatof]

The Important Rules state that "Regardless of whether a field is mandatory in the API, if it is present in the IIA of one HEI it is highly recommended to have it in the matched IIA of the partner HEI". Therefore, it should be better if the partner adds the OUnits.

But in any case we have the master-master model; this mean that you follow what you describe in your copy (and has been approved by your partner) and your partner follows what it has described in its copy. I think that if the partner's copy lacks the information about your OUnits you can manage your mobilities without problems anyway.