Dashboard/OLA allows more than 1 LA to be created for 1 mobility?

[sascoms]

Dear friends,

OLA/Dashboard seems to allow students to create more than one LA for the same mobility.

Can the EWP technical team please confirm this from the Dashboard team?

We confirm this from our side as we receive more than one LA for the same student for the same mobility.

As we have consulted the EWP technical management team in the near past, their response was "1 LA for 1 mobility".

Now, the questions are:

• Is this rule/principle respected by all providers including Dashboard/OLA, as they are also a provider?
• Which LA record shall we regard as the latest and active LA of the student?

What can be done to prevent this and such problems in the future?

Thanks,

[skishk]

we are facing the same problem...
hope someone can answer to us and fix it.

we think 1 mobility could have 1 LA but it could change with new change proposal... as written in the specification.

[umesh-qs]

Dear friends,

OLA/Dashboard seems to allow students to create more than one LA for the same mobility.

Can the EWP technical team please confirm this from the Dashboard team?

We confirm this from our side as we receive more than one LA for the same student for the same mobility.

As we have consulted the EWP technical management team in the near past, their response was "1 LA for 1 mobility".

Now, the questions are:

• Is this rule/principle respected by all providers including Dashboard/OLA, as they are also a provider?
• Which LA record shall we regard as the latest and active LA of the student?

What can be done to prevent this and such problems in the future?

Thanks,

I am curious to know how anyone can send 2 mobility ID for same LA? LA is driven by mobility ID. If I call a LA get, I need to use mobility ID.

[skishk]

I am curious to know how anyone can send 2 mobility ID for same LA? LA is driven by mobility ID. If I call a LA get, I need to use mobility ID.

what we saw in production is: 1 mobility has 1 LA. if the student want to change something he send a new mobility with a new LA.
but you are working on the first mobility and then you find some different mobilities for the same student... here start the problems...

[skishk]

Dear @janinamincer-daszkiewicz,

this problema seems it is ignored from August 2023, that scares me quit a bit...

for us it's creating serious problems in production, i already reported it last March during the Workshop in Thessaloniki, but in an informal way.

now i reported it on tkt ESCI-12413 and I'm getting unacceptable responses i prefer to not share the content of the responses, i can just say that clear that they don't want to manage this problem.
If you could do something we would be grateful, if there is no solution probably we have to find a new way to report serious problems like this.

Thank you

[janinamincer-daszkiewicz]

I will look into the ticket.

[skishk]

I will look into the ticket.

i saw you linked the github issue in our tkt, but do you agree or accept their response in the tkt?

[janinamincer-daszkiewicz]

Give us some time, for internal talks.

[umesh-qs]

I will look into the ticket.

i saw you linked the github issue in our tkt, but do you agree or accept their response in the tkt?

Curious to know what is your expectation? What problem are you facing if the content of LA is changed on same mobility?

[skishk]

Curious to know what is your expectation? What problem are you facing if the content of LA is changed on same mobility?

I think the colleague mean different Omobility-id for the same student.
the colleague asking: "Which LA record shall we regard as the latest and active LA of the student?"

Student A has just one mobility in our university and we receive 5/6 differente LA on different OMobility-id this rise different problems, specially if you already approved the first one.

[umesh-qs]

Curious to know what is your expectation? What problem are you facing if the content of LA is changed on same mobility?

I think the colleague mean different Omobility-id for the same student. the colleague asking: "Which LA record shall we regard as the latest and active LA of the student?"

Student A has just one mobility in our university and we receive 5/6 differente LA on different OMobility-id this rise different problems, specially if you already approved the first one.

How is it a specification issue? If the mobility is duplicate then the user of the system must deactivate one of them. Where is the role of tool provider here?

[skishk]

How is it a specification issue? If the mobility is duplicate then the user of the system must deactivate one of them. Where is the role of tool provider here?

in my opinion if the student has just one mobility, can't create a new one... if the student needs to make a change in the existing LA we expect a new change proposal... but we receive new Omobility-ids and then we have one LA already approved and other LAs for the same student with different OMobility-ids...

[umesh-qs]

How is it a specification issue? If the mobility is duplicate then the user of the system must deactivate one of them. Where is the role of tool provider here?

in my opinion if the student has just one mobility, can't create a new one... if the student needs to make a change in the existing LA we expect a new change proposal... but we receive new Omobility-ids and then we have one LA already approved and other LAs for the same student with different OMobility-ids...

ok so provider systems should not allow creating 2 mobilities for the same student? And this is not specific to EWP? Btw, what is the 100% full proof way to identify duplicate mobility?

[skishk]

in general there is the possibility that the student could have 2 (or more) mobilities to the same partner in the same year, but they are different on different agreements, we manage this scenario but as we seen others no... so 1 mobility = 1 Omobility-id with one LA and if needed we use change proposal on the same mobility so same Omobility-id.

to try answering to your request "100% full proof way to identify duplicate mobility?" i think actually i don't have a 100% full proof but we saw these different mobilities have the same anagrafical data of the student, same email, same ESI ... but different Omobility-id.

[umesh-qs]

in general there is the possibility that the student could have 2 (or more) mobilities to the same partner in the same year, but they are different on different agreements, we manage this scenario but as we seen others no... so 1 mobility = 1 Omobility-id with one LA and if needed we use change proposal on the same mobility so same Omobility-id.

to try answering to your request "100% full proof way to identify duplicate mobility?" i think actually i don't have a 100% full proof but we saw these different mobilities have the same anagrafical data of the student, same email, same ESI ... but different Omobility-id.

And this is the reason I mentioned earlier that it doesn't sounds a technical issue. Partner should talk to each other and remove any unintentional duplicate.

[skishk]

the technical issue is allow that when the student has just one mobility...
if the system allow every student to create infinite number of Mobilities where is the facilities to IROs? spending their life to delete all the wrong Mobilities the partner sent? we are talking about thousands students not 5 students...

[umesh-qs]

the technical issue is allow that when the student has just one mobility... if the system allow every student to create infinite number of Mobilities where is the facilities to IROs? spending their life to delete all the wrong Mobilities the partner sent? we are talking about thousands students not 5 students...

You are taking the discussion in a totally different direction. There are multiple examples of rework in EWP network for various reasons. Please suggest how do you want to restrict it from specifications perspective? Do you want the EWP specs owners to add a point in specifications that duplicate mobilities should not be allowed in EWP network. If yes, please send your proposal to the EWP specs owner by specifying definition of duplicate.

[skishk]

it's easy: how many nomination/application the student has? 1, so just one mobility.
each institution know if his student has one or more mobilities to the same partner.

the main scope of the project is to simplify the process to the students and IROs that means the system must allow what is allowed for the student and not create garbage in the network.

your question make me think you have no controll on mobilities... you don't know the nomination that you sent?! how many students are outgoing to a specific partner?
if i have 30 students are going for studies mobility to a specific partner i'll create 30 mobilities, on each mobility there is only one LA. if changes on a specific LA needed we send a change proposal of that mobility without create new OMobility-id.

only in that way everything is clear for each user (students or IROs).

[umesh-qs]

@skishk We are not facing such issue. So it doesn't matter what we are doing. You will not get anything out of selective targeting.

Please read my previous comments again. Send your easy suggestion for easy implementation in the specification.

[skishk]

i just reported a technical problem that system allow students to create all the mobilities they want... probably the students don't know they creating new mobilities... they think just sending a LA with changes. it is not their fault but system fault.
In your opinion everything is good? so you have to ask to IROs if this process is correct.

[janinamincer-daszkiewicz]

What we know:

1. MBR, chapter 7:
   Only one LA per mobility can be exchanged via EWP. This LA can have many versions.
2. Comprehensive User Guide for Digital Erasmus+ Learning Agreements, Page 5, in bold:
   https://erasmus-plus.ec.europa.eu/sites/default/files/2023-10/User-Guide-Erasmus-Digital-LA_en.pdf
   Only one learning agreement for studies per mobility should be shared with the partner via the EWP network.
3. Current specs:
   https://github.com/erasmus-without-paper/ewp-specs-api-omobility-las/blob/stable-v1/endpoints/get.md
   Each outgoing mobility should have at most one learning agreement. Extensions to a learning agreement should be handled by its modification.

What we need to consider: are there business needs to have more than one mobility per academic term (academic year, semester, trimester).

We will come back to you with the answer.

[skishk]

probably we need to improve the specification (in the quickest way because the problem is in production and it is growing everyday) and explain what is Omobility-id and what it means... and which link have with other API because i'm afraid we lost the scope of the EWP project, everyone is focused on one API separately.

What we need to consider: are there business needs to have more than one mobility per academic term (academic year, semester, trimester).

is that a question? because it is a business requirement, yes for sure without any doubt, but this must be clear to all and how manage it.... we could not leave the student create innumerable mobility.
we all manage different mobility for the same student... it is not a new business requirement. and it is possible to manage it on EWP network too.

we will wait for the answer but i want to remember that the problem is in production and is growing every day.

[janinamincer-daszkiewicz]

is that a question? because it is a business requirement, yes for sure without any doubt, but this must be clear to all and how manage it.... we could not leave the student create innumerable mobility.

Yes, it is a business requirement and we have to make sure what is exactly the business need in that respect.

we will wait for the answer but i want to remember that the problem is in production and is growing every day.

I know, this is why I push to get the answer as soon as possible.

Anyway, it is crystal clear that never ever the system should allow to create a new mobility just to avoid modification of the existing one.

It is easier to achieve in the in-house solution like ours (and also probably yours) where we first nominate a student for the outgoing mobility and only when we already know who is going where a local coordinator starts LA for the (already existing and verified) mobilities. Then LA is edited by the student and the coordinator until they both agree that this is what they want to have.

[skishk]

It is easier to achieve in the in-house solution like ours (and also probably yours) where we first nominate a student for the outgoing mobility and only when we already know who is going where a local coordinator starts LA for the (already existing and verified) mobilities. Then LA is edited by the student and the coordinator until they both agree that this is what they want to have.

i agree with you, but this is the normal process for all not only for us.

[janinamincer-daszkiewicz]

i agree with you, but this is the normal process for all not only for us.

Not so easy to implement in third-party hubs.

[sascoms]

The problem again arises from Dashboard OLA's implementation.

If not mistaken, students can delete their LAs and create new ones.
Or even worse, they can create new LA without deleting the previous.

We made sure about this situation when one of our HEIs switched from Dashboard to ErasmusJET.

They wanted to backup their students' LAs as PDFs on Dashboard.*
We saw that most of the LAs were duplicates.

Now back to the past, we asked this and EWP management confirmed the rule: "1 mobility => only 1 LA"

Even about the extensions, we tried hard to convince our HEIs that there can be only one LA and the extension courses should be added to the same LA as changes version.

I hope Dashboard team (and if there are other providers following the same workflow) will step forward and solve this issue in OLA and it will not allow more than 1 LA to be created for the same mobility.

And also they should not allow IROs or coordinators to create another mobility record for the same student unless it is really a different mobility.

[@janinamincer-daszkiewicz Maybe mentioning Kostas to the thread and receving his attention might help for a quick solution.]

Besides:
We should note that the rule of "1 mobility => only 1 LA" is broken by the EWP management itself.

As you know, there can be only one academic year in the LA document.

However, in our HEIs some students extend their mobility to the next academic year.

Upon such issues, we asked EWP Relationship managers what to do in such situations.

And their responce was that there should be separate LAs for each academic year.

So this seems the only exception for the rule "1 mobility => only 1 LA" but this both breaks it and also just a very bad solution.

Instead a simple solution such as specs allowing min 1 academic year, max 2 academic years in the LA would be better.

Or maybe the DG EAC and NAs should not allow extentions to the next academic years.

Now to summarize, what we recommend

• the principle of 1 mobility = 1 LA should continue.
• providers should only allow one LA to be created for a mobility.
• providers should not allow duplicate mobility records to be created for the same real mobility.
• extensions to the next academic year should not be solved with second LA, but instead the specs should allow 2 academic years to be given.
• Fake ESIs should be prevented and the element names should be consistent in all APIs (global id vs esi, etc..)
• The business process owners is not the # 1 and sole consultation point and reference.**
  Neither DG EAC, nor EWP technical management on itself alone.

**We as a provider (and many providers I guess) have been at least 15 years in the market and working in the Erasmus kitchen very closely with the IROs.
Thousands of students, LAs, IIAs, Erasmus experts, etc.

*why providers do not provide APIs for data exports in EWP format and/or for provider switching and data migration?

[janinamincer-daszkiewicz]

What you recommend is already expressed in the specification. One clarification:

extensions to the next academic year should not be solved with second LA, but instead the specs should allow 2 academic years to be given.

It should not be solved by the second LA, but by the second mobility. This is the decision of the BPOs, as I understand it. Of course we can ask Harpa for confirmation.

[sascoms]

So what about the quotas of the next academic year?

And do BPOs know everything and consider all details perfectly? or sometimes just the easiest but the not good solution?

That is also one of the reasons why providers left contributing to the improvement and development of EWP.
Again, pity.

[janinamincer-daszkiewicz]

So what about the quotas of the next academic year?

HEI decides about the quotas with the partner. It's their decision.

And do BPOs know everything and consider all details perfectly? or sometimes just the easiest but the not good solution?

They are in charge of the business process.

[skishk]

I remember after V7 went online in the network everyone (EWP managers) said: "now the focus is on Learning Agreements".
the problem mentioned in this issue is here from the year ago and until now the problem is present and creating extra work for each user in this workflow.
If i remember well the scope of the project is to simplify... am I wrong?