New API Proposal for Confirmation of Arrival/Departure

[sascoms]

There is a procedure of confirming the arrival/departure of the student in/from the host HEI either initiated by the host HEI or by the student.

And this procedure generally is done via a signed document which students need to get from the host IRO office and send it to their home HEI or directly sent to the home HEI by the host HEI.

It will be good to create a CNR API or a normal API which can convey the confirmation of the host HEI to the home HEI together with the student's arrival/departure date and basic student information.

Such API will remove all document/paper work and do this job with a matter of one or two clicks.

** This procedure is also related to the Certificate of Attendance and also can be planned in such new API.

[kamil-olszewski-uw]

This is opinion of IRO of Uniwersity of Warsaw:

Confirmation of Arrival is an individual decision of each university, i.e. the provisions of the Erasmus+ program do not indicate that the student must present such a document for the project documentation. Therefore the University of Warsaw does not oblige to send this document. The procedure is used if the student has given wrong dates in the agreement and would like to change them. In the past, some universities made the payment of the scholarship dependent on this document, but in Erasmus+ it should not happen, because it would be inconsistent with the rules of the program, i.e. with the need to pay the scholarship before the start of mobility. Of course, any meaningful computerization of any element is welcome.

[pleys]

Although I do agree with Kamil that it is not part of the official Erasmus documents in practice many universities are using this system so if we could have a solution via EWP to cater for this practice, that would further reduce the paperwork. I imagine that dates are being exchanged via the Incoming mobility API (& they are part of TOR) so we might not need have a separate API for this.

[jiripetrzelka]

I am in favor of adding at least the option to include file-id of the confirmation of study period in PDF (which the host university issues on student departure) into the Incoming Mobilities API. The file would then be accessible through the new File API. Adding the confirmation of arrival in PDF would also be a good idea.

[janinamincer-daszkiewicz]

The problem is that all these extra opions would make sense under the condition that providers would implement them. How many would implement new API which is not required? If that would not be a new API but additional optional parameter to the existing AP, the chances would be higher. Honestly I do not see the added value in getting PDF with two dates I already have in XML ;)

[jiripetrzelka]

I agree that from the technical point of view the PDFs are superfluous and creating a new version of the API just for them may not be ideal. But in case there would also be other reasons for creating version 2 of the Incoming Mobilities API (such as adding the dates of the virtual mobility) then I think that adding an optional field for this PDF would be similar to having an optional field for ToR PDF.

[janinamincer-daszkiewicz]

I agree, but on the other hand me might try to make users aware that easier solutions are possible and that extending support for PDF files (read: paper) is not the way to go. One extra parameter is not a big deal, but on the other hand it would be like telling the world that the idea 'wihout the paper' is nice 'idea' but in reality we cannot exist without the paper. I will ask experts from DG EAC about their opinion on that issue. Paul, you ask your BPO group, please.

[janinamincer-daszkiewicz]

After the internal discussion, taking into consideration opinion of BPOs, we decided to reject this change proposal.

[sascoms]

REF: [Your views on EWP: survey analysis]