Harmonogramy - Konfiguracja zdarzeń harmonogramów

Automat po włączeniu sprawdza ostatnie czasy komunikacji aktywnych urządzeń, KTÓRYCH dane pobiera aplikacja typu PVD Aggregator. W trakcie przesyłania statusów komunikacyjnych z poszczególnymi urządzeniami np. licznikami na magistrali komunikacyjnej, falownikami, urządzeniami z protokołem MODBUS aplikacja PVD przesyła również czas ostatniej poprawnej komunikacji z tym urządzeniem.

Tylko jeden parametr konfiguracyjny dla tego automatu. Za pomocą failureThreshold podanego w sekundach możemy podać punkt alertu. Jeśli komunikacja z którymkolwiek aktywnym urządzeniem w dowolnym agregatorze nastąpiła wcześniej niż X sekund od teraz, to zostanie wygenerowany alert typu SCHEDULED dla systemu zarządzania zdarzeniami (Events). W nim istnieje możliwość zdefiniowania reakcji na ten komunikat (wysłanie powiadomienia, maila, sms).

Automat po włączeniu sprawdza ostatnie czasy komunikacji aktywnych urządzeń typu PVD Aggregator. Każde z tych urządzeń wysyła do centralnego systemu tzw. heartbeat czyli potwierdzenie, że działa i komunikacja jest poprawna. Na podstawie tych informacji system potrafi sprawdzić i wygenerować ostrzeżenie dla wybranych użytkowników w przypadku, gdy czas ostatniej komunikacji z aktywnymi agregatorami jest większy niż parametr konfiguracyjny.

Tylko jeden parametr konfiguracyjny dla tego automatu. Za pomocą failureThreshold podanego w sekundach możemy podać punkt alertu. Jeśli komunikacja z którymkolwiek aktywnym agregatorem nastąpiła wcześniej niż X sekund od teraz, to zostanie wygenerowany alert typu SCHEDULED dla systemu zarządzania zdarzeniami (Events). W nim istnieje możliwość zdefiniowania reakcji na ten komunikat (wysłanie powiadomienia, maila, smsa).

Automat sprawdzający czasy ostatniej komunikacji poprzez interfejs API. Czasami może nam zależeć na wiedzy, czy zewnętrzny system przesyła dane w sposób ciągły do systemu AMAGE. W przypadku każdej transmisji zapisywana jest w bazie danych ostatnia data/czas wykonania takiej komunikacji dla danego klucza API.

Za pomocą tego automatu, możemy wygenerować zdarzenie typu email alertujące, że dany klucz API nie był wykorzystywany w ostatnich X sekundach. Za pomocą parametru deviceFailureThreshold definiujemy czas od ostatniej komunikacji, apiAccessKeyUuid podajemy klucz, który chcemy monitorować, za pomocą tagów language, emails, email_topic, email_content możemy określić adresatów email’a, tytuł oraz treść wiadomości.

Dostępność: AMAGE Web

Integracja z systemem wagowym GS Software. Pozwala pobrać informacje o ważeniach w systemie GS Software oraz wpisać do odpowiednich parametrów produkcyjnych systemu. Konfiguracja danych dostępowych realizujemy przez zmienne db_url, db_login, db_password. Włączenie pobierania danych o poszczególnych ważeniach ustawiamy za pomocą opcji fetch_car_weight. Ważenie z chwytaków realizowane za pomocą osobnego interfejsu włączamy poprzez opcję fetch_grapple_weight i należy określić kod parametru produkcyjnego, do którego zostanie wpisana wartość poprzez fetch_grapple_item_code. Ignorowane kody z systemu GS Software można wpisać do zmiennej ignored_codes. Dane te nie będą przepisywane do systemu. Automat domyślnie analizuje aktualny miesiąc i pobiera dane od początku aktualnego miesiąca do dnia wykonania operacji. Można ten okres rozszerzyć poprzez określenie liczby miesięcy wstecz, które system ma analizować poprzez zmienną month_before_count.

Integracja z systemem Xpertis. Dane bazy danych pozwalają na dostęp ODBC do systemu Xpertis. Osobno należy skonfigurować połączenie ODBC do systemu z takim aliasem połączenia. Dodatkowo określamy UUID stanu zdarzeń serwisowych (finished_state_uuid), który traktowany jest jako stan, w którym dane zdarzenie powinno zniknąć z systemu Xpertis (controling kosztów). W celu powiązania kosztów magazynu oraz faktur w systemie Xpertis podajemy UUID usług, które traktowane są jako koszty magazynowe oraz koszty zewnętrzne faktur (service_item_warehouse_type_uuid, oraz service_item_invoice_type_uuid). Dla kosztów magazynowych usługa musi być najpierw utworzona w AMAGE i mieć wpisany numer dokumentu taki jak w systemie Xpertis. Scheduler automatycznie zaktualizuje koszty danego dokumentu. W przypadku faktur scheduler UTWORZY nowe wpisy w danym zdarzeniu serwisowym z kosztami faktur, które zostały zadekretowane do danego zdarzenia serwisowego.

Zadanie wysyła email z wygenerowanym raportem PDF reklamacji do dostawcy powiązanego przez zamówienie z daną reklamacją. Zadanie jest aktywowane dla danej reklamacji, jeśli jej stan jest określony parametrem complaint_begin_state_name. Adres email pobierany jest z danych kontrahenta jako główny email firmy. Dodatkowe adresy email podajemy w zmiennej config.emails. Po wysłaniu email’a zmienia stan reklamacji na podany w parametrze complaint_end_state_name. Raport generowany jest w locale podanym w parametrze language. Tytuł i treść emaila zostają określone w parametrach email_topic, email_content. Można wykorzystać też parametr email_portal_url, do którego zostanie skierowany dostawca, aby skomentować reklamację. W nim można wykorzystać pole %token% do określenia tokenu identyfikującego reklamację.

Zadanie wysyła email z wygenerowanym raportem PDF dostrawy/zwrotu do dostawcy powiązanego z daną dostawą. Zadanie jest aktywowane dla danej dostawy, jeśli jego stan jest określony parametrem delivery_begin_state_name oraz dostawa jest typu delivery_type. Email wysyłany jest, tylko jeśli dany kontrahent ma oznaczoną flagę "wysyłaj automatycznie zamówienia email’em" w definicji kontrahenta dla kontraktu. Adres email pobierany jest z danych kontrahenta jako główny email firmy. Po wysłaniu email’a zmieniany jest stan dostawy na podany w parametrze delivery_end_state_name. Dokument dostawy generowany jest, tylko jeśli ustawiona jest flaga send_document (domyślnie wyłączony). Raport generowany jest w locale podanym w parametrze language. Tytuł i treść emaila zostają określone w parametrach email_topic, email_content. Dodatkowe adresy email podajemy w config.emails.

Można wykorzystać też parametr email_portal_url, do którego zostanie skierowany dostawca, aby potwierdzić zamówienie. W nim można wykorzystać pole %token% do określenia tokenu identyfikującego zamówienie.

W przypadku, gdy dostawa posiada przypisane zlecenie pracy i to zlecenie posiada określoną lokalizację z punktem ma mapie, to można wykorzystać opcje w formaterze: %location_url% oraz %placeofwork_url%, które będą zawierać link do strony z lokalizacją na mapie. Aby to umożliwić pojawia się parametr konfiguracyjny config.email_location_url, w którym podaje się link do strony z geolokalizacją. Wykorzystujemy tam szablony %lat% oraz %lon% do wskazania szerokości i długości geograficznej w formie cyfrowej np. 23.4234.

Zadanie wysyła email z wygenerowanym raportem PDF zamówienia do dostawcy powiązanego z danym zamówieniem. Zadanie jest aktywowane dla danego zamówienia, jeśli jego stan jest określony parametrem order_begin_state_name. Email wysyłany jest tylko jeśli dany kontrahent ma oznaczoną flagę "wysyłaj automatycznie zamówienia emailem" w definicji kontrahenta dla kontraktu. Adres email pobierany jest z danych kontrahenta jako główny email firmy. Po wysłaniu email’a zmienia stan zamówienia na podany w parametrze order_end_state_name. Raport generowany jest w locale podanym w parametrze language. Tytuł i treść emaila zostają określone w parametrach email_topic, email_content. Dodatkowe adresy email podajemy w config.emails.

Można wykorzystać też parametr email_portal_url, do którego zostanie skierowany dostawca aby potwierdzić zamówienie. W nim można wykorzystać pole %token% do określenia tokenu identyfikującego zamówienie.

W przypadku, gdy zamówienie posiada przypisane zlecenie pracy i to zlecenie posiada określoną lokalizację z punktem ma mapie, to można wykorzystać opcje w formaterze: %location_url% oraz %placeofwork_url%, które będą zawierać link do strony z lokalizacją na mapie. Aby to umożliwić pojawia się parametr konfiguracyjny config.email_location_url, w którym podaje się link do strony z geolokalizacją. Wykorzystujemy tam szablony %lat% oraz %lon% do wskazania szerokości i długości geograficznej w formie cyfrowej np. 23.4234.

Automat generujący rozliczenie obecności pracownika. Wykorzystuje rejestracje obecności (wejścia/wyjścia) do wyliczenia czasu obecności. Rejestracje obecności można wykonać za pomocą wbudowanej aplikacji mobilnej do rejestracji obecności za pomocą kart zbliżeniowych na telefonie z systemem Android. Dane te też mogą pochodzić z zewnętrznego systemu RCP/KD jako odczyty rejestracji wejścia/wyjścia.

Konfiguracja automatu pozwala na definicję okresu czasu dla którego wykonywane są obliczenia, czy jest to też ten miesiąc czy poprzedni miesiąc kalendarzowy. Za pomocą parametru language definiujemy treść komunikatów zapisywanych w systemie po wykonaniu poprawnym/niepoprawnym obliczeń danych.

Szczegółowe informacje o wygenerowanych danych znajdują się w logu zdarzeń dla modułu automatów (schedulerów).

Generowanie harmonogramu dla pracowników na określoną liczbę miesięcy. Pozwala automatycznie uzupełniać generowanie nowego (na kolejny) miesiąc harmonogramu w czasie uruchomienia harmonogramu. Opcja generateMonthCount określa liczbę miesięcy, które mają być generowane. W przypadku, gdy jest to 1, to generowany jest tylko harmonogram na kolejny miesiąc. W przypadku, gdy jest to 2, to generowany jest harmonogram na kolejny miesiąc oraz na kolejny po nim. W przypadku, gdy jest to 3, to generowany jest harmonogram na kolejny miesiąc, na kolejny po nim oraz na kolejny po nim itd. Zawsze generujemy harmonogram, zaczynając od kolejnego miesiąca od aktualnego.

Zadanie analizuje termin upływu ważności kompetencji pracowników w podanym zakresie dni (from_today_start do from_today_end) np. 7-14 to następny tydzień. Jeśli w danym okresie upływa termin ważności kompetencji pracownika, to jest to dodawane do treści email’a. Konfiguracja zawartości email’a realizowana jest przez tytuł, nagłówek treści oraz linie jednej ważności kompetencji (dla wielu będzie to lista składająca się z tych linii). Można wykorzystać zmienne podane w przykładach.

Automat generujący powiadomienia o nadchodzących terminach przeglądów CRO. Jeśli włączona jest opcja notification_enable powiadomienia trafiają do paska powiadomień w aplikacji Web. Jeśli włączona jest flaga email_enable zostanie wysłany email. Treść komunikatów definiowana jest w pozostałych opcjach.

Automat, który generuje informację przypominającą o wymaganych i oczekiwanych pomiarach monitoringu emisji. W ramach definicji monitoringu emisji określamy na jaki typ zdarzenia (pobranie próbki, otrzymanie raportu, wysłanie powiadomienia) chcemy otrzymać powiadomienie mailowe oraz ile dni przed wykonaniem tej czynności ma to być wykonane.

W schedulerze definiujemy tylko informacje, które mają znaleźć się w nagłówki, tytule i opisie poszczególnych elementów powiadomień. Za pomocą opcji language określamy język użyty w emailu. Za pomocą opcji topic określamy tytuł emaila, a za pomocą email_header określamy treść nagłówka głównego maila (w treści). Każdy z elementów powiadomienia określamy za pomocą email_item_template.

System generuje informacje o:

Automat generujący powiadomienia o nadchodzących terminach umów. Jeśli włączona jest opcja notification_enable powiadomienia trafiają do paska powiadomień w aplikacji Web. Jeśli włączona jest flaga email_enable zostanie wysłany email. Treść komunikatów definiowana jest w pozostałych opcjach.

Automat generujący powiadomienia o nadchodzących terminach decyzji. Jeśli włączona jest opcja notification_enable powiadomienia trafiają do paska powiadomień w aplikacji Web. Jeśli włączona jest flaga email_enable zostanie wysłany email. Treść komunikatów definiowana jest w pozostałych opcjach.

Automat generujący powiadomienia o nadchodzących terminach raportowania. Jeśli włączona jest opcja notification_enable powiadomienia trafiają do paska powiadomień w aplikacji Web. Jeśli włączona jest flaga email_enable zostanie wysłany email. Treść komunikatów definiowana jest w pozostałych opcjach.

Automat generujący planowany harmonogram podziału produkcji energii w zakładach kogeneracji energii. System na podstawie wybranego za pomocą parametru energy_prices_type źródła danych pobiera informacje o cenach energii. Na podstawie tych danych generuje plan produkcji energii elektrycznej i cieplnej. Wartości minimalne, średnie i maksymalne generacji energii określamy za pomocą parametrów min_heat_generation, mean_heat_generation, mean_electric_generation, max_electric_generation. System stara się zmaksymalizować zyski z produkcji energii. Algorytm następnie przedstawiany jest w analizach i raportach.

Zadanie sprawdza dwie poprzednie wartości dostarczanej energii w kwantach kwadransowych (15 minutówki). W przypadku, gdy ostatnia wartość dostarczonej energii spadnie poniżej wartości progowej (w tysiącach kW) zostanie wysłany email z komunikatami o wartościach "below". W przypadku gdy dla dwóch ostatnich wartości generacja wróci powyżej wartości granicznej wygenerowany zostanie kolejny email o wartościach "over".

Generacja informacji o produkcji energii. Generuje plik do wykorzystania przez systemy wizualizacji. Zawiera dane o produkcji elektrycznej i cieplnej. Generujemy co trzy godziny. Plik docelowy opisany przez zmienną. Generujemy plik o kolumnach: data [yyyy-MM-dd]; godzina [0-23]; energia dostarczona [MWh]; energia wygenerowana [MWh]; energia cieplna dostarczona [GJ]

Algorytm pobiera dane z rejestracji energii. Podajemy identyfikatory parametrów, które chcemy pobrać. W przypadku braku danych w systemie, algorytm generuje informację o braku danych. W przypadku, gdy dane są dostępne, algorytm generuje informację o pobranych danych. Parametry odpowiadają identyfikatorom parametrów produkcyjnych w systemie i oznaczają energy_prices_type typ wyboru źródła danych o cenach energii. Pozostałe parametry to identyfikatory parametrów produkcyjnych, które chcemy pobrać.

Generator pobiera informacje o wartościach ceny za 1GJ energii cieplnej dostarczanej do sieci. W początkowej implementacji posiada statyczną konfigurację z pojedynczą ceną.

Generator pobiera informacje ze źródła PSE dla rynku bilansującego i wprowadza dane do systemu. Konfiguracja zawiera informacje o adresie z którego pobieramy dane.

Generator pobiera informacje ze źródła TGE dla rynku dnia następnego i wprowadza dane do systemu. Konfiguracja zawiera informacje o adresie z którego pobieramy dane.

Przykładowa pliku konfiguracyjnego (wykonanie o 0:00 trzeciego dnia każdego miesiąca, opóźnienie uruchomienia 30 sekund, zadanie aktywne). Sprawdzamy poprzedni miesiąc i jeśli dla aktywnych danych produkcyjnych nie zostały wprowadzone dane za tamten miesiąc, to tworzone są emaile dla każdej osoby odpowiedzialnej za dane i wysyłany jest email do niego z listą danych produkcyjnych.

Analizator danych produkcji energii. W przypadku wykrycia listy parametrów o przekroczonej w danym roku sumie wartości, generuje email z listą podzieloną na przekroczenia krytyczne i ostrzeżenia zgodnie z definicją w parametrach. W elementach tekstu można używa szablonów zgodnie z przykładem. Tylko limity parametrów z wyłączoną flagą "nie powiadamiaj" są uwzględniane na liście. Jeśli flaga notification_enable będzie ustawiona na 'true' to każdej osobie odpowiedzialnej zostanie wygenerowana notyfikacja w systemie z komunikatem w szablonie notification_template.

Generator, który tworzy nowe wpisy w danych produkcyjnych dla danego miesiąca. Powinien być uruchamiany raz w miesiącu na początku miesiąca. Utworzy wtedy nowy wpis do wprowadzania danych produkcyjnych. Uruchomienie wielokrotnie w ciągu danego miesiąca nie spowoduje żadnych akcji. Nie posiada dodatkowych parametrów konfiguracyjnych.

Automat generuje nowe limity dla parametrów produkcyjnych. W przypadku zaznaczenia odpowiednich opcji generuje nowy limit jako kopię poprzedniego limitu dla danego okresu.

Planer inspekcji. Na podstawie zdefiniowanych planów inspekcji generowane są wykonania inspekcji. W szablonie planu inspekcji można włączyć automatyczne generowanie wykonań inspekcji X dni przed koniecznością wykonania takiej inspekcji. Automat zajmuje się generowaniem takich danych. Dla użytkownika generowana jest notyfikacja w systemie, że został przypisany do danej inspekcji jako wykonawca. Jeśli zdefiniujemy UUID zlecenia pracy, to automat automatycznie przypisze wykonanie inspekcji do danego zlecenia pracy.

Automat generujący email do listy użytkowników z informacjami dotyczącymi planu niezbędnych inspekcji w wybranym okresie. Podawana jest liczba dni od dnia wykonania skryptu, które mają być brane pod uwagę do analizy. Lista docelowa adresów email oraz tytuł, nagłówek wiadomości oraz pojedynczy element tekstu wiadomości (pojedyncze urządzenie) są możliwe do modyfikacji.

Automat generujący raporty PDF wykonanych i sprawdzonych inspekcji. Po włączeniu możemy określić, czy plik wygenerowanego raportu ma mieć flagę Publiczny tj. być dostępny np. przez Portal Klienta. Czy wygenerowany raport zapisać w zleceniu pracy, do którego podpięta jest inspekcja. Czy zapisać w zasobie, którego dotyczy inspekcja oraz jaką kategorię nadać dołączanemu plikowi.

W trakcie wykonywania automatu sprawdzane są protokoły, które są wykonane, są sprawdzone, ale nie posiadają wygenerowanego raportu. Po wykonaniu akcji i zapisaniu raportów ustawiana jest dla inspekcji flaga Wygenerowano raport.

Automat, który automatycznie wprowadzi zapis stanu nadzoru do zasobu połączonego z inspekcją po jej wykonaniu. Pozwala to na powiązanie między sobą inspekcji oraz nadzoru danego zasobu. Dla przykładu po wykonaniu inspekcji automat może automatycznie wprowadzić stan "Wykonano inspekcję" dla nadzoru "Nadzór nad montażem" danego zasobu. Automatyzuje i łączy dwa moduły - Inspekcji i Nadzoru.

Konfiguracja pozwala na wskazanie identyfikatora szablonu inspekcji, której dotyczy automat inspection_template_uuid. Wskazania, które flagi wywołają akcję inspection_executed oraz inspection_checked. Następnie podajemy identyfikator szablonu nadzoru supervision_template_uuid oraz konkretnego stanu nadzoru supervision_template_state_uuid. Wszystkie te dane możemy uzyskać w interfejsie użytkownika.

Powiadamianie o inspekcjach oczekujących na sprawdzenie. Inspekcje, które zostały wykonane w okresie od from_today_start do from_today_end jako liczba dni od dziś posiadają flagi ukończone oraz nie posiadający flagi sprawdzone. Email zostanie wygenerowany zbiorczo dla osób, które są wskazane do weryfikacji inspekcji. Treść emaila i tytuł definiowany w opcjach.

Sprawdzamy obchody o UUID podane w liście. Jeśli czas od ostatniego wykonania > 48 h to wysyłamy komunikat na podane emaile.

Zadanie wysyła email z przypomnieniem w końcu realizacji danej dzierżawy w określonym w parametrze reminder_days_before_end dni przed zakończeniem czasu wykonania. Konieczne jest określenie UUID (lista) kontraktów, których dotyczy ten scheduler. W polach email_topic i email_content zawieramy tytuł i treść emaila. Można wykorzystać podane znaczniki, które zostaną zamienione na aktualną datę oraz nazwę zlecenia pracy. Przykładowa pliku konfiguracyjnego (wykonanie o 6:15, 14:15, 22:15, opóźnienie uruchomienia 30 sekund, zadanie aktywne).

Automat pozwala na automatyczną zmianę stanu rejestru ISO dotyczącego działań korygujących. Automat po włączeniu monitoruje zadania przypięte do danego działania korygującego i po wykryciu zakończenia wszystkich zadań automatycznie zmienia stan danego działania korygującego na wybrany a następnie przesyła wiadomości do osób tworzących/odpowiedzialnych za dany rejestr. Dodatkowo jeśli pojawią się jakieś nowe, niezakończone zadania lub zadania zmienią swój stan na niewykonany to system automatycznie przywróci stan początkowy danego rejestru.

Konfiguracja pozwala na wskazanie UUID stanu początkowego config.begin_state_uuid oraz UUID stanu końcowego config.final_state_uuid. Automat sprawdza obydwa stany i wykonuje odpowiednie akcje w zależności od stanu zadań. Do użytkowników wysyłane są komunikaty, które można dostosować za pomocą opcji config.text_finish_state oraz config.text_begin_state.

Automat pozwala na automatyczną zmianę stanu rejestru ISO dotyczącego wniosków racjonalizatorskich. Automat po włączeniu monitoruje zadania przypięte do danego rejestru i po wykryciu zakończenia wszystkich zadań automatycznie zmienia stan danego wniosku na wybrany a następnie przesyła wiadomości do osób tworzących/odpowiedzialnych za dany rejestr. Dodatkowo jeśli pojawią się jakieś nowe, niezakończone zadania lub zadania zmienią swój stan na niewykonany to system automatycznie przywróci stan początkowy danego rejestru.

Konfiguracja pozwala na wskazanie KODU stanu początkowego config.begin_state_name oraz KODU stanu końcowego config.final_state_name. Automat sprawdza obydwa stany i wykonuje odpowiednie akcje w zależności od stanu zadań. Do użytkowników wysyłane są komunikaty, które można dostosować za pomocą opcji config.text_finish_state oraz config.text_begin_state.

Automat pozwala na automatyczną zmianę stanu rejestru ISO dotyczącego rejestru ryzyk/szans. Automat po włączeniu monitoruje zadania przypięte do danego rejestru i po wykryciu zakończenia wszystkich zadań automatycznie zmienia stan danego wniosku na wybrany a następnie przesyła wiadomości do osób tworzących/odpowiedzialnych za dany rejestr. Dodatkowo jeśli pojawią się jakieś nowe, niezakończone zadania lub zadania zmienią swój stan na niewykonany to system automatycznie przywróci stan początkowy danego rejestru.

Konfiguracja pozwala na wskazanie KODU stanu początkowego config.begin_state_name oraz KODU stanu końcowego config.final_state_name. Automat sprawdza obydwa stany i wykonuje odpowiednie akcje w zależności od stanu zadań. Do użytkowników wysyłane są komunikaty, które można dostosować za pomocą opcji config.text_finish_state oraz config.text_begin_state.

Automat sprawdzający zewnętrzne źródła dokumentów legislacyjnych. W przypadku wykrycia nowych dokumentów, które nie są w systemie. System obsługuje API Sejmu RP i możliwość pobierania danych z Dziennika Ustaw oraz/lub Monitora Polskiego. Tagi tag1, tag2, tag3 są wykorzystywane do filtrowania dokumentów. W przypadku wykrycia nowych dokumentów automat generuje email z listą nowych dokumentów. W treści emaila można wykorzystać zmienne %date%, %labels%, %number%, %title%, %address%, %displayAddress%, %link%. Wartość %address% jest wykorzystywana do generowania linków do dokumentów.

Automat generuje powiadomienie mailowe o zbliżających się terminach legislacyjnych. System automatycznie o określonej w schedulerze porze wyśle powiadomienia przypisane do danego dnia.

System AMAGE ma możliwość generacji notyfikacji dla użytkowników. Notyfikacje pojawiają się w systemie w komunikatach dla użytkownika dostępnych w menu systemowym ikona "dzwonka". System może określić termin ważności notyfikacji tj. znikną z powiadomienia np. po 48 godzinach jeśli użytkownik tego nie zatwierdzi jawnie. Scheduler pozwala na wyłączanie tych notyfikacji po upłynięciu tego czasu. Włączenie schedulera bez dodatkowych opcji pozwala na wyłączanie notyfikacji, które mają włączony czas ważności.

Dodatkowo niektóre notyfikacje pozwalają na wyświetlanie bez terminu ważności. Czasami zdarza się, że użytkownicy nie potwierdzają tych wiadomości i kolejkują się one cały czas dla użytkowników.

Scheduler pozwala na zamknięcie takich notyfikacji po określonym czasie od ich publikacji. Po włączeniu schedulera można w konfiguracji określić dodatkowe opcje, które będą zamykały notyfikacje bez terminu ważności. Należy ustawić opcję config.close_notification_without_expiration na true oraz ustawić czas (dni), po którym notyfikacje te znikną z pola powiadomień użytkownika. Wartość ustawiamy w zmiennej config.close_notification_age_days

Generator raportów w formie PDF. Generujemy raport na podstawie listy UUID zakładek raportu a następnie wysyłamy wynik na adresy e-mail. Zostanie wysłany jeden email z tyloma raportami ile wybranych zakładek. Nazwy plików to nazwy zakładek. W parametrach określamy listę emaili, na które ma być wysłany raport, temat emaila oraz treść emaila. Można użyć zmiennej %date% do wprowadzenia informacji kontekstowych do treści i tytułu emaila. Można określić język generowanego raportu poprzez zmienną language. W przypadku braku podania zmiennej ustawiany domyślny język serwera, na którym uruchamiany jest serwer synchronizacji.

Zadanie weryfikuje czas ostatniej aktualizacji zdarzenia serwisowego w określonym stanie. Dla wszystkich zdarzeń serwisowych w stanie <state.uuid> lub <config.states_uuid> zadanie sprawdza czas ostatniej modyfikacji zadania. Jeśli nie podano stanów, to system wyszukuje wszystkie zgłoszenia serwisowe, których aktualny stan nie ma ustawionego stanu publicznego jako Rozwiązany.

Następnie sprawdzany jest czas modyfikacji. Jeśli czas jest większy (starszy) niż podana w konfiguracji liczba minut <state.stalled_minutes> to jest wysyłany email z tytułem <config.email_topic> o treści <config.email_content> do adresatów <config.email_recipents> (adresy oddzielone spacjami). W treści i tytule można zamienić pola aktualnej daty, stanu zdarzenia oraz listy numerów zgłoszeń, które są przeterminowane. Ograniczenie typów zdarzeń serwisowych realizujemy przez podanie listy UUID typów, które mają być wybranego do tego automatu. Dodatkowo można wybrać opcję aby wysyłać powiadomienie osobno dla osoby przypisanej do zdarzenia <config.email_assigned> jako tworzący je lub do osoby aktualnie przypisanej < config.email_creator>.

Zadanie zmienia stan zdarzenia serwisowego z stanu początkowego na końcowy. W trakcie zmiany stanu dodaje zapis (komentarz do zgłoszenia) wskazujący mechanizm zmiany oraz wskazuje stan końcowy na który zmieniło. W konfiguracji należy podać początkowy i końcowy UUID stanu zgłoszenia serwisowego. Ograniczenie typów zdarzeń serwisowych realizujemy przez podanie listy UUID typów, które mają być wybranego do tego automatu.

Generacja raportów PDF z protokołów serwisowych.

Generuje plik PDF z protokołu serwisowego, który posiada flagi: WYKONANE i SPRAWDZONE ale nie posiada flagi RAPORT_WYGENEROWANO. Dla takich raportów generowany jest protokół na formacie zdefiniowanym w zakładce raportu o podanym UUID w parametrze 'report_bookmark_uuid'. Jeśli nie podano UUID zakładki, generowany jest domyślny wygląd raportu. Po wygenerowaniu plik zapisywany jest do nadrzędnego zgłoszenia serwisowego jeśli jest ustawiona flaga 'store_in_serviceevent'. Plik otrzymuje kategorię (opcjonalne) o UUID w parametrze 'attachment_category_uuid' oraz flagę publiczną jeśli ustawiona jest flaga 'public_files'. Włączenie opcji send_email_to_representative umożliwia przesłanie email’a do osoby wskazanej jako reprezentant ze strony zgłaszającego.

Zadanie analizuje termin upływu ważności sprawdzania wyposażenia w podanym zakresie dni (from_today_start do from_today_end) np. 7-14 to następny tydzień. Jeśli w danym okresie upływa termin ważności kalibracji urządzenia, to jest to dodawane do treści email’a. Konfiguracja zawartości email’a realizowana jest przez tytuł, nagłówek treści oraz linie jednej ważności kompetencji (dla wielu będzie to lista składająca się z tych linii). Można wykorzystać zmienne podane w przykładach.

Sprawdza obiekty inwentaryzacji i jeśli może powiązać wszystkie parametry do produktu, to automatycznie tworzy produkt w strukturze na podstawie inwentaryzacji. Dodatkowym parametrem jest wskazanie grupy produktów, do której dołączany będzie nowy produkt. W przypadku włączenia opcji product_subgroup_time automatycznie będzie tworzona podrzędna grupa produktów z aktualną datą. Pozwala to na umieszczanie nowych produktów w strukturze z datami wprowadzenia ich do tej struktury. W przypadku włączenia opcji product_subgroup_delivery_number dla obiektów inwentaryzacji pochodzących z dostaw nazwa grupy będzie miała numer dokumenty dostawy.

Inicjalizator nadzoru, który posiada dane dotyczące nadzoru określone w ramach wewnętrznej konfiguracji. Różnica w stosunku do uniwersalnego inicjalizatora jest możliwość podania grupy produktów (i podrzędnych grup) dla których zostanie zainicjalizowany nadzór.

Automat wykonuje następujące prace:

Automat w konfiguracji pozwala na włączenie notyfikacji dla wybranych użytkowników notification_user_logins. Do nich generowane są notyfikacje informujące o utworzeniu typów nadzoru oraz o utworzeniu nowych nadzorów dla nowych zasobów.

Automat, który po osiągnięciu przez dany zasób określonego stanu w nadzorze, automatycznie generuje określoną inspekcję. Pozwala to na automatyczne utworzenie inspekcji dla jakiegoś nadzoru w przypadku, gdy zostanie osiągnięty jakiś stan nadzoru.

Dla przykładu - jeśli status montażu jakiegoś urządzenia osiągnie stan "podłączone i gotowe" to system może automatycznie wygenerować inspekcję dla tego zasobu o szablonie "Sprawdzenie końcowe urządzenia" i przydzielić ją do brygadzisty wraz ze zleceniem pracy.

Dane konfigurujemy w opcjach automatu. Określamy szablon inspekcji, jaki zostanie wykorzystany do generacji inspekcji inspection_template_uuid. Określamy szablon nadzoru supervision_template_uuid oraz konkretny stan nadzoru supervision_template_state_uuid, który wyzwoli generację tej inspekcji. Podczas generacji inspekcji przydzielamy ją do użytkownika responsible_user_uuid i przypisujemy ją do zlecenia pracy work_order_uuid.

Inspekcje zostaną utworzone tylko dla zasobów w grupie produktów root_group_uuid (oraz podrzędnych) oraz tylko dla zasobów o typach kategorii type_categories

Po wygenerowaniu inspekcji, dla użytkownika zostanie wygenerowana notyfikacja z określonym tekstem.

Uniwersalny inicjalizator nadzoru bazujący na ustawieniach nadzoru w interfejsie użytkownika. Po jego włączeniu zgodnie z harmonogramem automat przegląda dane i wykonuje następujące czynności:

Automat w konfiguracji pozwala na włączenie notyfikacji dla wybranych użytkowników notification_user_logins. Do nich generowane są notyfikacje informujące o utworzeniu typów nadzoru oraz o utworzeniu nowych nadzorów dla nowych zasobów.

Automat weryfikuje ilości zadeklarowane w magazynie i porównuje je z ilościami wynikającymi z dokumentów magazynowych. W przypadku wykrycia nieścisłości generuje powiadomienie mailowe.

Automat pozwala na wysyłanie dokumentów magazynowych na adresy email. W konfiguracji można określić typy dokumentów, które mają być wysyłane, odbiorców, język, treść emaila oraz załączniki. Algorytm tożsamy z wysyłaniem dokumentów zamówień.

Automat generuje raport zbiorczy stanów minimalnych na magazynie. W trakcie wykonania analizowane są wszystkie magazyny i generowany jest email zbiorczy do listy adresatów określonych w parametrze automatu. Treść nagłówka, tytułu i poszczególnych elementów można modyfikować dodatkowymi parametrami.

Automat pozwala na automatyczne zatrzymywanie zleceń pracy na koniec dnia roboczego. W konfiguracji można określić język, czas zakończenia pracy, szablon pracy oraz szablon powiadomienia. W przypadku zatrzymania zlecenia pracy automat dodaje komentarz do zlecenia z informacją o automatycznym zatrzymaniu zlecenia.

Automat pozwala na przesyłanie emaili do osób z przypomnieniem o rozpoczynających się zadaniach lub takich, które są bliskie terminu zakończenia. Za pomocą odpowiednich opcji możemy definiować czas, w którym dana informacja zostanie wysłana, do jakich adresatów oraz jaka jest jej treść. Automat bazuje na terminach oczekiwanego rozpoczęcia i oczekiwanego zakończenia zadań.

W konfiguracji możemy określić za pomocą opcji config.expected_start_notify liczbę dni od daty oczekiwanego rozpoczęcia, kiedy zostanie wysłany email. Może to być np. -5 czyli 5 dni przed lub 5 czyli pięć dni po danym terminie. To samo dotyczy opcji zakończenia zadania w parametrze config.expected_deadline_notify. Za pomocą opcji config.email_assigned określamy, czy wysłać email do osoby przypisanej do zadania a za pomocą config.emails określamy dodatkowe adresy email, na które ma być wysłane powiadomienie.

Treść emaila określamy za pomocą elementów config.email_topic, config.email_header. Każde z zakresów możemy poprzedzić tekstami odpowiednio config.email_topic_item_start oraz config.email_topic_item_deadline. Każde z zadań zostanie wyświetlone w liście (zbiorczo), gdzie każdy rząd definiujemy za pomocą config.email_item_template.

Automat, który pozwala na powiadomienie wybranych użytkowników o braku zmiany wartości parametru w czasie lub braku nowych wartości parametru w czasie. Taki automat pozwala na wykrycie braku komunikacji z wybranymi urządzeniami lub zewnętrznymi systemami, które powinny dostarczać informacji na bieżąco. Pozwala również na szybką reakcję na brak danych, co może być kluczowe w przypadku monitorowania ważnych parametrów.

Parametr language pozwalają na określenie języka powiadomień dla tekstów wbudowanych w aplikację. Parametr parameter_setting_uuid definuje UUID parametru, który monitorujemy. config_no_entry włącza powiadomienie przy braku zapisów historii parametru. notify_no_entry_minutes definuje czas, po którym powiadomienie zostanie wysłane. notify_no_entry_template pozwala na określenie treści powiadomienia. Analogicznie dla notify_no_value_change, notify_no_value_change_minutes oraz notify_no_value_change_template, które określają powiadomienie dla braku zmiany wartości parametru. Opcje application_notify oraz email_notify pozwalają na określenie, czy powiadomienie ma być wysłane do użytkowników aplikacji w ramach powiadomień lub na adresy email. W przypadku emaili można określić dodatkowe parametry takie jak emails, email_topic, email_header. Dla powiadomień w aplikacji należy określić dodatkowe parametry takie jak application_notify_logins, które definuje listę loginów użytkowników, którzy mają otrzymać powiadomienie. W przypadku braku podania języka w konfiguracji, automat korzysta z języka serwera, na którym uruchomiony jest serwer synchronizacji.

Automat, który pozwala na transformację wartości jednego parametru do innego parametru lub do danej produkcyjnej. Automat pozwala na przykład przepisać dane z parametru pobieranego ciągle z jakiegoś urządzenia (wartość licznika energii) lub danych z zewnętrznych systemów IT przechowywanych w ustawieniach parametrów do danej produkcyjnej pod koniec miesiąca wykorzystując dodatkowe działania i agregację.

Za pomocą parametru language ustawiamy język komunikatów zapisanych na stałe w systemie. parameter_setting_uuid określa UUID parametru, który będzie przetwarzany. Następnie wybieramy albo UUID danej produkcyjnej, albo UUID innego ustawienia parametru, który będzie celem transformacji. Za pomocą target_value_equation mamy możliwość dodatkowego przetwarzania wartości z parametru za pomocą dodatkowego mechanizmu równań (podzielenie, wymnożenie itp.). Dodatkowo za pomocą operation_type możemy określić wartość parametru, który przetwarzamy. CURRENT określa aktualną wartość parametru. LAST - poprzednią wartość parametru. SUM - wykona sumę zapisów ustawień parametru w określonym czxasie, DIFFERENCE/MEAN - odpowiednio różnicę i wartość średnią arytmetyczną z wartości pomiarów w danym zakresie. Zakres dat określamy za pomoc operation_interval_type oraz operation_interval_value.

Dodatkowo możemy określić, czy powiadomienie ma być wysłane do użytkowników aplikacji za pomocą application_notify, application_notify_logins, application_notify_template oraz czy ma być wysłane na adresy email za pomocą email_notify, emails, email_topic, email_header, email_item_template.

Automat pozwalający na synchronizację dokumentów magazynowych systemu Merit z AMAGE. Automat pobiera określone dokumenty magazynowe z systemu Merit a następnie tworzy odpowiednie dokumenty magazynowe w systemie AMAGE wraz z zapisami stanów na magazynie/miejscu składowania oraz utworzeniu typów elementów w przypadku ich braku w systemie. Za pomocą opcji db_alias, db_login oraz db_password podajemy konfigurację dostępu do bazy danych poprzez interfejs ODBC. Opcja documents_type wskazuje typy dokumentów, które należy pobrać do systemu AMAGE. Opcja area_numbers podaje numery obszarów (sekcji) z systemu Merit, których dokumenty będą podlegały synchronizacji. Za pomocą measurement_unit_map definiujemy nazwy jednostek w systemie Merit i odpowiednie kody jednostek w systemie AMAGE, aby odpowiednio zsynchronizować ten typ danych. Za pomocą default_supplier_uuid podajemy UUID identyfikator domyślnego dostawcy w przypadku konieczności utworzenia nowych typów materiału (system Merit nie udostępnia tych danych). Za pomocą default_warehouse_uuid oraz default_warehouse_place_uuid podajemy identyfikatory magazynu i miejsca składowania, do którego będą synchronizowane dokumenty. Za pomocą receive_documents_months określamy ilość miesięcy, w których mają być pobierane dokumenty z systemu Merit. Z czego wartość = 1 oznacza aktualny miesiąc, wartość 2 aktualny i poprzedni itp.

System synchronizuje dane i wykrywa istniejące dokumenty po ich numeracji. Jeśli je wykryje, to nie są przetwarzane ponownie.