OPI PIB wspólnie z Ministerstwem podjęło decyzję, że uczelnie, które nie przeprowadziły samodzielnie uporządkowania problemu migracyjnego mogą zostać objęte automatycznym procesem porządkowym przez OPI PIB – pod warunkiem dokonania stosownego zgłoszenia. Więcej na ten temat przeczytasz tutaj.

Natomiast  procedura opisana w poniższym wpisie jest skierowana do tych uczelni, którą mają zamiar dokonać uporządkowania warunków zatrudnienia w zakresie siatki stanowisk samodzielnie – w szczególności, jeśli chcą, aby przejście na nową siatkę stanowisk miało datę inną niż 1 października 2018 r.

Poniżej przedstawiamy szczegółowy opis strategii 2 rozwiązania problemu migracyjnego dotyczącego siatki stanowisk w module Pracownicy – usługi podziału przekonwertowanych warunków zatrudnienia.

Wyjaśnienie istoty problemu migracyjnego, jakie oferujemy usługi służące rozwiązaniu tego problemu i do kogo są one skierowane znajdziesz tutaj.

Na temat strategii 1 przeczytasz tutaj.

Cel i opis usługi

Celem usługi dostępnej w ramach strategii 2 jest kompleksowe uprządkowanie warunków zatrudnienia, które dotknął problem migracyjny, za pomocą tzw. daty „przecięcia” warunków zatrudnienia.

Usługa obejmuje swoim działaniem jedynie warunki zatrudnienia, które przeszły przez proces migracji. Jeśli warunki zatrudnienia zostały zarejestrowane dopiero w systemie POL-on 2.0, to funkcja ta nie obejmie ich swoim działaniem.

Wywołanie usługi zawsze obejmuje swoim zasięgiem wszystkie stanowiska wymienione we wstępie dokumentu. Nie można wybrać tylko jednego rodzaju stanowiska.

Usługa obejmuje swoim działaniem jedynie stanowiska wymienione wyżej w dokumencie (w opisie strategii 1) trwające na dzień 2018-10-01 (w tym zakończone lub rozpoczęte w tym dniu).

Uwaga! Zaleca się wykonanie usługi najpierw na maszynie DEMO, a dopiero później na maszynie PROD.

Parametryzacja i działanie

Usługa posiada jeden parametr daty, który pozwala dostosować podział stanowiska w zależności od statutów przyjętych w ramach uczelni.

Wywołanie funkcji realizuje następujące scenariusze:

  1. Ustawienie daty na dzień „2018-10-01”.
    • Warunek taki może zostać podzielony na dwa warunki w przypadku, kiedy jego część rozpoczynała się przed 2018-10-01 (pierwotny warunek zniknie z systemu i pozostanie tylko jako historia techniczna):
      • Pierwszy warunek trwający do dnia 2018-09-30 zostanie zapisany na stanowisku, które obowiązywało do dnia 2018-09-30 (stara siatka).
      • Drugi warunek trwający od dnia 2018-10-01 zostanie zapisany na stanowisku, które obowiązywało od dnia 2018-10-01 (nowa siatka).
    • Warunek taki nie zostanie objęty mechanizmem porządkowym i pozostanie z aktualną wartością stanowiska (stanowisko nowe), jeśli warunek rozpoczynał się w dniu 2018-10-01 lub później.
  2. Ustawienie daty na dzień późniejszy niż 2018-10-01, np: 2019-10-01.
    • Warunek może zostać podzielony na dwa warunki, jeśli warunek taki trwał na podaną datę (czyli w podanym wypadku na dzień 2019-10-01):
      • Pierwszy warunek trwający do dnia 2019-09-30 zostanie zapisany na stanowisku, które obowiązywało do dnia 2019-09-30 (stara siatka).
      • Drugi warunek trwający od dnia 2019-10-01 zostanie zapisany na stanowisku, które obowiązywało od dnia 2019-10-01 (nowa siatka).
    • Warunek taki może mieć zmienione jedynie stanowisko na pierwotne (stara siatka), jeśli warunek zakończył się przez datą podaną w parametrze (w podanym wypadku 2019-10-01).
    • Warunek taki nie zostanie objęty mechanizmem porządkowym i pozostanie z aktualną wartością stanowiska (stanowisko nowe), jeśli warunek rozpoczynał się w dniu 2019-10-01 lub później.

Wywołanie usługi podziału warunków zatrudnienia

W poniższym przykładzie użyto daty innej niż 2018-10-01, aby pokazać, iż można uzyskać podział w innej dacie niż 2018-10-01.

Adres usługi:  adres_serwera/employees-api/splitConditionsOnDate/{split_date},

np. POST https://polon2-demo.opi.org.pl/employees-api/splitConditionsOnDate/2018-12-01.

(wersja dla środowiska produkcyjnego: POST https://polon2.opi.org.pl/employees-api/splitConditionsOnDate/2018-12-01.)

Opis wywołania usługi w programie POSTMAN:

  • Uzupełniamy sekcję Headers jak na screenie:
    Content-Type – application/hal+json;charset=UTF-8
    Institution – wklejamy id instytucji wyciągniętej z bazy w punkcie 1
    Authorization  – wpisujemy Bearer i po spacji wklejamy aktualny access_token z punktu 3.

  • W sekcji Body zaznaczamy tylko form-data.

  • Tak przygotowany request wysyłamy.

  • W odpowiedzi dostaniemy identyfikator joba, którego możemy użyć, aby podejrzeć, jaki jest status przetwarzania.

Podgląd statusu usługi

Adres usługi: adres_serwera/employees-api/jobStatus/{ jobExecutionId },

np: GET https://polon2-demo.opi.org.pl/employees-api/jobStatus/61

(wersja dla środowiska produkcyjnego: GET https://polon2.opi.org.pl/employees-api/jobStatus/61 )

W konfiguracji uzupełniamy tylko sekcję Headers z aktualnym access_tokenem i wysyłamy.

Po jakimś czasie (w skrajnych przypadkach może to trwać nawet 1 godzinę, jeśli instytucja ma dużo warunków do podziału) status powinien zmienić się na COMPLETED.

Dokument do pobrania

Pełen dokument dotyczący procedury rozwiązania problemu migracyjnego wraz ze szczegółowymi opisami usług w ramach obydwu dostępnych strategii możesz pobrać tutaj: Procedury rozwiązania problemu migracyjnego_11.12.2020.

Zobacz też:

Siatka stanowisk