Dotyczy wersji 2020.1.3.x; autor: Agnieszka Burda
Wstęp
Poniższy artykuł stanowi rozszerzenie dla artykułu Lunchtime – zamawianie posiłków dostępnego pod adresem: https://kb.webcon.pl/download/lunchtime-zamawianie-posilkow/.
Aplikacja Lunchtime została wzbogacona o pomocnicze procesy słownikowe, które dają możliwość płacenia za posiłek pieniędzmi wcześniej wpłaconymi na osobiste konto.
- [LT Account] – słownik przechowujący informacje o koncie pracownika
- [LT Transactions] – słownik przechowujący informacje o przeprowadzonych transakcjach, podzielony na 4 typy formularza, odpowiadające 4 typom transakcji, jakie można przeprowadzić na danym koncie:
- Deposit – do wpłacania pieniędzy na konto
- Refund – do zwracania pieniędzy wpłaconych na konto
- Payment – do dokonywania opłat za posiłki
- Repayment – do zwracania pieniędzy za niezrealizowane zamówienia
Witryna aplikacji
Strona aplikacji w dalszym ciągu składa się z dwóch dashboardów:
- Lunchtime
Rys. 1 – Strona główna aplikacji
- Lunchtime administration
Rys. 2 – Lunchtime administration
Pierwszy z nich został rozszerzony o sekcję Balance, widoczną w prawej górnej części, która pokazuje aktualny stan konta użytkownika. W tym celu utworzono raport ze stanem konta dla aktualnie zalogowanego użytkownika. Następnie na dashboardzie osadzono element Raport Tile, który przedstawia jedną kolumnę z wybranego raportu.
Rys. 3 – Konfiguracja Raport Tile – Account
Ponadto na dashboardzie Lunchtime dodany został raport My transactions, który zawiera wszystkie transakcje przeprowadzone na danym koncie.
Do drugiego dashboardu dodane zostały raporty nowych słowników Transactions – zawierające wszystkie transakcje pracowników i Account – zawierający wszystkie utworzone konta. Raporty zostały podzielone na widoki Active i Inactive. Na raporcie Account na kolor czerwony zaznaczone są kwoty pracowników, których stan konta jest równy 0.
Słownik Account
Nowe konta można utworzyć z poziomu dashboardu Lunchtime administration za pomocą przycisku New widocznego na raporcie Account.
Rys. 4 – Przycisk New do tworzenia nowych kont
Po wciśnięciu przycisku zostanie otworzona nowa instancja słownika Account, na której widoczne są pola:
- Employee – pole typu osoba, pobierające dane z powiązanego AD,
- Registration date – pole w trybie tylko do odczytu z aktualną datą,
- Balance – pole w trybie tylko do odczytu z aktualnym stanem konta,
- Active – checkbox informujący o tym, czy konto jest aktywne, czy nieaktywne.
W celu zarejestrowania konta należy uzupełnić wymagane pole Employee i przejść ścieżką Save.
Rys. 5 – Nowa instancja słownika Account
Co ważne, nie ma możliwości utworzenia nowego konta dla pracownika, który takie konto już posiada. W takim wypadku na przejściu ścieżką Save zostanie wyświetlony odpowiedni komunikat.
Po przejściu ścieżką zostanie utworzone konto użytkownika. Wyłącznie z tego poziomu można na nie dodać pieniądze lub dokonać z niego zwrotu. Służą do tego widoczne na górnej belce przyciski New Deposit i New Refund.
Rys. 6 – Słownik Account
Od strony konfiguracyjnej są to globalne akcje typu hiperłącze.
Rys. 7 – Konfiguracja przycisku New Deposit
Jedynym przekazywanym parametrem jest login użytkownika.
Rys. 8 – Konfiguracja hiperlinku do startowania elementu
W analogiczny sposób wygląda konfiguracja akcji New Refund.
Słownik Transactions
Za pomocą słownika Transactions można zmieniać stan konta pracownika. Jest on powiązany ze słownikiem Account po loginie pracownika. Wydzielono w nim 4 typy formularza: Deposit, Payment, Refund i Repayment. Wszystkie typy formularza korzystają z tego samego obiegu, który składa się z jednego kroku z jedną ścieżką przejścia Save. Od strony konfiguracji, na przejściu ścieżką Save, która zapisuje wszelkie przeprowadzane transakcje, znajdują się 3 akcje. Pierwsza z nich, to akcja walidacyjna, która dla każdego typu formularza sprawdza, czy podana kwota jest dodatnia.
Rys. 9 – Konfiguracja akcji walidacyjnej
Druga z akcji to zmiana wartości pola, która w zależności od typu formularza, ustawia wartość w polu Transaction jako ujemną lub dodatnią. Jest to związane z tym, że w przypadku wypłacania pieniędzy pracownikowi lub opłat za lunch, stan konta zmniejsza się, natomiast w przypadku wpłacania lub zwracania pieniędzy na konto – stan zwiększa się. W teorii możliwe jest wykorzystanie w tym celu jednego pola do wszystkich rodzajów transakcji, jednak przeprowadzone testy wykazały, że dla użytkowników bardziej intuicyjne jest wpisywanie wartości dodatniej dla każdego typu transakcji.
Rys. 10 – Konfiguracja akcji zmiany wartości pola
Ostatnia z akcji to przesunięcie zależnego obiegu Account w celu aktualizacji kwoty w polu Balance.
W oknie konfiguracji w zakładce Parameters podawana jest ścieżka techniczna _Update, która przesuwa obieg.
Rys. 11 – Konfiguracja akcji przesuń obieg Account
W zakładce Data utworzone jest zapytanie SQL, które do aktualnej wartości w polu Balance dodaje nową wartość z pola Transaction. Tym samym stan konta pracownika zostaje powiększony lub pomniejszony o podaną kwotę.
Rys. 12 – Edycja zapytania do przesunięcia obiegu Account
W kolejnej części artykułu omówione zostaną poszczególne typy transakcji, jakie można przeprowadzić na koncie.
Deposit
Wyobraźmy sobie sytuację, że do administratora aplikacji Lunchtime zgłasza się pracownik z chęcią wpłacenia pieniędzy na swojego konto pre-paid. Po utworzeniu takiego konta (sposób zaprezentowany w rozdziale 3) należy utworzyć transakcję wpłacania pieniędzy przez pracownika. W tym celu trzeba wybrać przycisk New Deposit, co pozwoli utworzyć nową instancję tego słownika.
Rys. 13 – Deposit – nowa instancja
W polu Deposit należy wpisać kwotę, którą przekazał pracownik. Pozostałe pola są w trybie tylko do odczytu. Po przejściu ścieżką Save stan konta użytkownika na koncie użytkownika zostanie zwiększona o podaną kwotę.
Wprowadzona zmiana jest widoczna dla pracownika z poziomu dashboardu głównego w dwóch miejscach:
- Nowa kwota widoczna w sekcji Balance
- Nowa transakcja widoczna na raporcie Transaction
Również z poziomu słownika Account administrator ma możliwość wglądu do przeprowadzonej transakcji. Wartość w polu Balance została zaktualizowana oraz pojawił się nowy wiersz w tabeli Transactions.
Rys. 14 – Konto po transakcji Deposit
Refund
Jeżeli z jakichś względów pracownik chciałby odzyskać pieniądze, które wpłacił na konto pre-paid należy wykorzystać przycisk New Refund. Po wybraniu go otworzona zostanie nowa instancja dla tego słownika. W polu Refund podaje się kwotę, którą chce się zwrócić pracownikowi. Należy pamiętać o tym, że wartość w tym polu musi być dodatnia. Pozostałe pola są w trybie tylko do odczytu.
Rys. 15 – Refund – nowa instancja
Po przejściu ścieżką Save stan konta pracownika zostanie zaktualizowany, co będzie widoczne w tych samych miejscach, jak w przypadku depozytu.
Payment
Nie ma możliwości ręcznego wystartowania instancji dla tego typu formularza. Jest on startowany automatycznie z poziomu obiegu Lunchtime. Wszelkie potrzebne informacje na temat tworzenia takiego obiegu znajdują się w artykule wspomnianym we wstępie.
Przechodząc do etapu, gdzie obieg Lunchtime znajduje się na kroku Food choices, użytkownik ma możliwość złożenia zamówienia. Na liście pozycji Today’s order dodaje nowy wiersz i zaznacza checkbox Pre-paid. Jak można zauważyć przycisk Paid Up jest w trybie tylko do odczytu i zaznaczony jest na kolor czerwony.
Rys. 16 – Składanie zamówienia z pre-paidem
Po zaakceptowaniu zamówienia, na kroku Final Call, na przejściu ścieżką Finish Collecting Orders wykonywane są 3 akcje. Pierwsza z nich odznacza checkbox Paid Up w zamówieniach pracowników, którzy chcieli zapłacić za pomocą prepaida, ale kwota jaką mają na koncie jest niewystarczająca do opłacenia zamówienia. W tym celu wykorzystano akcję zmiany wartości listy pozycji.
Rys. 17 – Konfiguracja akcji odznaczającej checkbox Pre-paid
Druga akcja dla każdego wiersza, w którym zaznaczono checkbox Pre-paid, tworzy nową instancję słownika Transactions z typem formularza Payment. W celu utworzenia transakcji paymentu wykorzystano akcję startowania podobiegu (SQL). W konfiguracji akcji, w zakładce Basic podany został odpowiedni proces wraz z typem formularza i ścieżką, którą powinien przejść obieg.
Rys. 18 – Startowanie nowej transakcji Payment
W zakładce Data utworzone zostało zapytanie SQL, które przepisuje odpowiednie wartości z listy pozycji Today’s Order, gdzie zaznaczony został checkbox Pre-paid do nowo startowanej transakcji.
Rys. 19 – Startowanie transakcji Payment zapytanie SQL
Po wykonaniu się akcji, na koncie użytkownika widać zrealizowaną transakcję. Kwota w polu Balance została zmniejszona o kwotę złożonego zamówienia (w tym przypadku 18 zł) oraz pojawił się nowy wiersz w tabeli Transactions.
Rys. 20 – Konto po transakcji Payment
Ostatnia akcja wykonywanych na tej ścieżce to zmiana wartości listy pozycji, która automatycznie zaznacza zamówienia jako opłacone (checbox Paid Up), jeśli zaznaczony jest checbox Pre-paid.
Rys. 21 – Konfiguracja akcji aktualizujacej listę Today's Order
Po przejściu ścieżką kolumna Paid Up zostaje zaktualizowana. Na kolor zielony oznaczone zostają już opłacone zamówienia. Ponadto nad listą Today’s Order wyświetlona zostaje lista Debtors z pracownikami, którzy zalegają z opłatami za posiłek wraz z sumowaną kwotą, jaką powinni zapłacić za złożone zamówienie.
Rys. 22 – Lista dłużników
Gdy pracownicy dokonają opłaty za posiłek należy zaznaczyć checkboxa Paid Up i zapisać formularz, a ich nazwiska znikną z listy dłużników.
Repayment
W przypadku, gdy z konta użytkownika zostaną pobrane pieniądze za lunch, jednak z jakichś względów nie dotrze on do firmy i trzeba anulować zamówienie, konieczny jest zwrot poniesionych przez pracownika kosztów. W tym celu przygotowany jest ostatni z typów transakcji – Repayment.
W procesie Lunchtime ścieżka Cancel widoczna jest na krokach Ordering i Awaiting Delivery. W oby dwóch miejscach utworzona została akcja tworząca transakcję Repayment.
W celu utworzenia transakcji repaymentu wykorzystano akcję startowania podobiegów (SQL). W konfiguracji akcji, w zakładce Basic uzupełniono pola dotyczące procesu, typu formularza i ścieżki przejścia.
Rys. 23 – Konfiguracja startowania Repaymentu
W zakładce Data znajduje się zapytanie SQL, które, podobnie jak w przypadku transakcji Payment, przepisuje odpowiednie pola z listy pozycji Today’s order do odpowiednich pól w nowo tworzonej transakcji.
Rys.24 – Zapytanie SQL do startowania Repaymentu
Po wykonaniu akcji na konto pracowników zwrócone zostaną uprzednio pobrane pieniądze, a w tabeli Transactions pojawi się kolejny wiersz.
Rys. 25 – Account po dokonaniu Repaymentu
Podsumowanie
Rozszerzenie aplikacji Lunchtime o funkcję pre-paid jest dobrym rozwiązaniem dla osób, które chcą uniknąć każdorazowego płacenia za dostarczane jedzenie. Jest to także duże ułatwienie dla osoby, która zarządza takim obiegiem. Z użyciem pre-paida można cieszyć się z codziennych posiłków bez konieczności pamiętania o płatności. Wystarczy raz na czas wpłacić na konto większą sumę i nie martwić się o nic więcej. Co ważne, każda transakcja, jaka miała miejsce jest rejestrowana w systemie.
Co więcej, rozwiązanie pre-paid może być stosowane także do innych obiegów działających w firmie. Wszędzie, gdzie pojawia się konto pracownika i dokonywanie wpłat, tradycyjny sposób, można zastąpić pre-paidem.
