Szablon danych do analizy naliczania wynagrodzeń
Szablon danych do analizy naliczania wynagrodzeń
- Ujednolicone atrybuty danych do analizy wynagrodzeń
- Najważniejsze etapy procesu do śledzenia w UKG Pro
- Wskazówki techniczne dotyczące ekstrakcji i integracji danych
Atrybuty procesu naliczania wynagrodzeń
| Nazwa | Opis | ||
|---|---|---|---|
|
Data ostatniej aktualizacji
LastUpdateDate
|
Znacznik czasu ostatniej modyfikacji wiersza danych. | ||
|
Opis
Ten atrybut wskazuje, kiedy rekord został ostatnio zmieniony w bazie danych. Podobnie jak znacznik czasu zdarzenia, służy jednak przede wszystkim do przyrostowego ładowania danych i kontroli ich integralności. Dzięki niemu model process mining uwzględnia aktualny stan rekordu płacowego, w tym późniejsze korekty i zmiany wsteczne wprowadzone przez specjalistów ds. płac.
Dlaczego to ważne
Wymagany atrybut do przyrostowego odświeżania danych.
Skąd pobrać
Kolumny metadanych systemowych, takie jak LastModifiedDate
Przykłady
2023-10-05T17:00:00Z2023-10-06T09:00:00Z
|
|||
|
Działanie
ActivityName
|
Zdarzenie lub krok wykonany w procesie płacowym. | ||
|
Opis
Ten atrybut określa nazwę kroku w workflow płacowym, na przykład przesłanie karty czasu pracy, obliczenie wynagrodzenia brutto lub realizację płatności. Wyznacza przebieg procesu na mapie. Wartości pochodzą zwykle z dzienników audytowych, tabel zmian statusu w systemie lub oznaczonych znacznikami czasu aktualizacji transakcji w UKG Pro. Podczas transformacji danych stosuje się spójne nazewnictwo, aby mapa procesu była czytelna.
Dlaczego to ważne
To wymagany atrybut Activity, który określa węzły na mapie procesu.
Skąd pobrać
Dzienniki audytowe systemu, historia workflow lub kolumny ze znacznikami czasu transakcji
Przykłady
Przesłanie karty czasu pracyObliczenie wynagrodzenia bruttoRealizacja wypłaty
|
|||
|
Rekord płacowy
PayrollRecordId
|
Unikalny identyfikator konkretnego pracownika w danym okresie rozliczeniowym. | ||
|
Opis
Rekord płacowy pełni funkcję głównego identyfikatora sprawy w analizie process mining. Tworzy się go przez połączenie identyfikatora pracownika z datą końca okresu rozliczeniowego lub identyfikatorem grupy płacowej. Dzięki temu każdy cykl płacowy danego pracownika jest osobną sprawą, co pozwala analizować powtarzające się procesy w czasie. W UKG Pro jest to zwykle klucz złożony, utworzony na podstawie tabeli Payroll Header lub podobnych rekordów transakcyjnych. Grupowanie według tego identyfikatora pozwala odtworzyć cały przebieg procesu: od przesłania karty czasu pracy po wypłatę i złożenie deklaracji podatkowych.
Dlaczego to ważne
To wymagany identyfikator sprawy, który łączy wszystkie działania płacowe w jedną instancję procesu.
Skąd pobrać
Pochodzi z tabel Payroll Header lub Employee Pay History w UKG Pro
Przykłady
EMP001-20231015EMP492-20231031EMP883-20231115
|
|||
|
System źródłowy
SourceSystem
|
System, w którym przechowywane są dane. | ||
|
Opis
Ten atrybut wskazuje źródło rekordu danych. W tym przypadku jego wartość jest ustawiona na UKG Pro lub nazwę konkretnej instancji, jeśli jest ich kilka. Ma to znaczenie w analizie process mining obejmującej wiele systemów, gdy dane płacowe są łączone na przykład z danymi księgi głównej z systemu ERP. Analitycy mogą filtrować widoki, aby wyświetlać tylko kroki pochodzące z platformy płacowej, a nie te zintegrowane z zewnętrznych systemów ewidencji czasu pracy.
Dlaczego to ważne
Wymagany atrybut do śledzenia pochodzenia danych i analizy obejmującej wiele systemów.
Skąd pobrać
Wartość stała lub tabela konfiguracji systemu
Przykłady
UKG ProUltiPro LegacySystem zarządzania czasem pracy
|
|||
|
Znacznik czasu
EventTimestamp
|
Data i godzina wykonania działania. | ||
|
Opis
Ten atrybut zapisuje dokładny moment wykonania działania. Jest niezbędny do prawidłowego uporządkowania zdarzeń i obliczania czasu między kolejnymi krokami. Warto używać znaczników czasu o wysokiej precyzji, aby rozróżnić automatyczne kroki wykonywane w krótkich odstępach. W procesie płacowym dane te służą do analizy rozkładu czasu cyklu i zgodności z SLA na dashboardzie. Bez dokładnych znaczników czasu nie można zmierzyć tempa obliczania wynagrodzenia brutto i netto ani opóźnień w zatwierdzaniu kart czasu pracy.
Dlaczego to ważne
To wymagany atrybut StartTime, potrzebny do uporządkowania zdarzeń.
Skąd pobrać
Kolumny daty i godziny powiązane ze zmianami statusu transakcji
Przykłady
2023-10-01T09:15:00Z2023-10-01T14:30:45Z2023-10-03T08:00:00Z
|
|||
|
Centrum kosztów
CostCenter
|
Kod centrum kosztów używany do alokacji finansowej. | ||
|
Opis
Atrybut Cost Center określa, do której jednostki księgi głównej przypisywany jest koszt wynagrodzeń. Jest podobny do atrybutu działu, ale często zapewnia bardziej szczegółowy obraz finansowy. Na dashboardzie skuteczności zatwierdzania ewidencji czasu pracy atrybut ten pomaga wykryć centra kosztów, w których zatwierdzanie trwa dłużej. Ułatwia też sprawdzenie, czy koszty wynagrodzeń trafiają do właściwych pozycji finansowych podczas obliczania wynagrodzenia brutto i netto.
Dlaczego to ważne
Wspiera analizę finansową i pomaga wykrywać wąskie gardła w jednostkach budżetowych.
Skąd pobrać
Tabele Employee Job lub Allocation
Przykłady
CC-5001CC-9002Overhead-Corp
|
|||
|
Data końca okresu rozliczeniowego
PayPeriodEndDate
|
Ostatni dzień przetwarzanego okresu rozliczeniowego. | ||
|
Opis
Ten atrybut wskazuje datę zakończenia cyklu płacowego. Jest punktem odniesienia przy ustalaniu, czy zgłoszenia wpłynęły z opóźnieniem. W połączeniu z atrybutem StartTime działania Time Sheet Submitted pozwala obliczyć opóźnienia. Służy też do grupowania danych na dashboardzie rozkładu czasu cyklu płacowego.
Dlaczego to ważne
Punkt odniesienia w czasie dla cyklu płacowego.
Skąd pobrać
Payroll Header lub konfiguracja okresu rozliczeniowego
Przykłady
2023-09-302023-10-15
|
|||
|
Dział
DepartmentCode
|
Kod działu przypisany do pracownika. | ||
|
Opis
Ten atrybut łączy rekord płacowy z konkretną jednostką organizacyjną. Jest potrzebny do analizy wyjątków audytowych i trendów korekt na dashboardzie. Organizacja może dzięki niemu sprawdzić, które działy regularnie generują błędy lub wymagają ręcznej interwencji. Podział danych według działu pozwala ustalić, czy wybrani kierownicy potrzebują szkolenia z zatwierdzania kart czasu pracy albo czy w niektórych jednostkach złożone zasady wynagradzania opóźniają obliczenia.
Dlaczego to ważne
Niezbędny do podziału danych według struktury organizacyjnej i analizy przyczyn źródłowych.
Skąd pobrać
Tabele Employee Master lub Job History
Przykłady
DEPT-100FINANCE-01OPS-WEST
|
|||
|
Grupa płacowa
PayGroup
|
Grupa pracowników wyodrębniona na potrzeby obsługi płac. | ||
|
Opis
Pay Group to podstawowe ustawienie w UKG Pro, które określa częstotliwość wypłat, na przykład co tydzień lub co dwa tygodnie, oraz zasady obsługi danej grupy pracowników. Pełni funkcję głównego identyfikatora partii. Atrybut ten jest niezbędny do analizy rozkładu czasu cyklu płacowego na dashboardzie. Pozwala porównać sprawność obsługi różnych grup, na przykład kadry kierowniczej i pracowników godzinowych zakładu, oraz sprawdzić, czy określone ustawienia powodują systemowe opóźnienia.
Dlaczego to ważne
Podstawowy wymiar grupowania i porównywania sprawności obsługi płac.
Skąd pobrać
Tabela Payroll Header lub Pay Group Configuration
Przykłady
US-BiWeeklyCA-WeeklyExec-Monthly
|
|||
|
Jurysdykcja podatkowa
TaxJurisdiction
|
Główny stan lub obszar lokalny, w którym składana jest deklaracja podatkowa. | ||
|
Opis
Ten atrybut wskazuje główną jurysdykcję podatkową powiązaną z rekordem płacowym. Jest niezbędny do analizy terminów składania deklaracji podatkowych w wielu stanach na dashboardzie. Analiza przebiegu procesu według jurysdykcji podatkowej pozwala zespołom ds. zgodności sprawdzić, czy w niektórych stanach deklaracje są regularnie składane z opóźnieniem oraz czy pracownicy rozliczani w wielu stanach częściej powodują wyjątki audytowe niż osoby rozliczane w jednym stanie.
Dlaczego to ważne
Niezbędny do monitorowania zgodności i analizy geograficznej.
Skąd pobrać
Tabele Tax Location lub Employee Tax
Przykłady
CANYTX
|
|||
|
Naruszono SLA
IsSlaBreached
|
Flaga wskazująca, czy płatność zrealizowano po terminie. | ||
|
Opis
Ten atrybut logiczny jest obliczany przez porównanie znacznika czasu działania Payment Executed z terminem SLA. Bezpośrednio wpływa na KPI dotyczący terminowości wypłat względem SLA. Wstępne obliczenie tej wartości pozwala od razu filtrować dashboard i wyświetlać tylko problematyczne sprawy. Ułatwia też analizę przyczyn niedotrzymania terminów.
Dlaczego to ważne
Wskaźnik KPI używany do monitorowania zgodności.
Skąd pobrać
Obliczane: PaymentTime > SlaDeadline
Przykłady
truefalse
|
|||
|
Poza standardowym cyklem
IsOffCycle
|
Flaga wskazująca, czy wypłata odbywa się poza standardowym harmonogramem. | ||
|
Opis
Ten atrybut logiczny wskazuje, czy rekord płacowy należy do wypłaty poza standardowym cyklem. Służy do obliczania KPI dotyczącego liczby takich wypłat. Wypłaty poza standardowym cyklem są zwykle droższe i wymagają więcej pracy ręcznej. Filtrowanie dashboardu analizy wariantów procesu według tej flagi pozwala zobaczyć niestandardowe ścieżki stosowane przy poprawianiu błędów lub realizacji doraźnych płatności.
Dlaczego to ważne
Przydatny filtr do analizy odchyleń od procesu i ponownej pracy.
Skąd pobrać
Logika porównująca pola Check Date i Period End Date w Payroll Header
Przykłady
truefalse
|
|||
|
Specjalista ds. listy płac
PayrollSpecialist
|
Identyfikator lub nazwa użytkownika przetwarzającego rekord. | ||
|
Opis
Ten atrybut wskazuje administratora lub specjalistę ds. płac odpowiedzialnego za zatwierdzenie rekordu, korektę danych lub realizację wypłaty. Jest mapowany na atrybut Generic User. Dane te są potrzebne do analizy obciążenia pracą specjalistów i przepustowości na dashboardzie. Pozwalają kierownictwu sprawdzić, jak praca rozkłada się w zespole, oraz wykryć osoby nadmiernie obciążone lub powodujące wąskie gardło na etapie zatwierdzania.
Dlaczego to ważne
Umożliwia analizę zasobów i ocenę równomiernego rozłożenia obciążenia pracą.
Skąd pobrać
Dzienniki audytowe lub kolumny ModifiedBy w tabelach transakcyjnych
Przykłady
jsmithmdoesystem_admin
|
|||
|
Termin SLA
SlaProcessingDeadline
|
Docelowa data i godzina zakończenia realizacji płatności. | ||
|
Opis
Ten atrybut określa wewnętrzny lub zewnętrzny termin zakończenia procesu płacowego, który pozwala zrealizować przelewy bankowe na czas. Jest podstawą dashboardu do monitorowania terminów i zgodności z SLA. Porównanie rzeczywistego znacznika czasu działania Payment Executed z tym terminem pozwala obliczyć odsetek płatności zrealizowanych na czas i wskazać rekordy zagrożone opóźnieniem.
Dlaczego to ważne
Punkt odniesienia przy obliczaniu zgodności z SLA.
Skąd pobrać
Kalendarz płacowy lub termin wyliczony przez odjęcie dni przetwarzania bankowego od daty wypłaty
Przykłady
2023-10-13T16:00:00Z2023-10-28T16:00:00Z
|
|||
|
Wynagrodzenie brutto
GrossPayAmount
|
Łączna kwota wynagrodzenia przed potrąceniami i podatkami. | ||
|
Opis
Ten atrybut określa kwotę wynagrodzenia brutto obliczoną dla rekordu. Jest mapowany na ActivityAmount, co umożliwia analizę procesu pod kątem kosztów. Analiza kwoty wynagrodzenia brutto wspiera dashboard pokazujący tempo obliczania wynagrodzenia brutto i netto. Dashboard mierzy przede wszystkim czas, ale zestawienie go ze złożonością i wartością płatności może ujawnić, czy problemy z wydajnością wynikają z wysokich kwot lub skomplikowanych prowizji.
Dlaczego to ważne
Umożliwia analizę przepływu wartości i wykrywanie wartości odstających.
Skąd pobrać
Tabele Payroll Result lub Pay Register
Przykłady
2500.0010500.50480.00
|
|||
|
Wystąpił wyjątek audytowy
HasAuditException
|
Flaga wskazująca, czy wystąpił wyjątek audytowy. | ||
|
Opis
Ten atrybut logiczny wskazuje, czy w danej sprawie wystąpiło działanie Audit Exception Flagged. Wspiera KPI dotyczący odsetka poprawnych wypłat za pierwszym razem. Pozwala szybko oddzielić sprawy bez zastrzeżeń od tych, które wymagały interwencji, i ułatwia analizę przyczyn ponownej pracy na dashboardzie wyjątków audytowych i trendów korekt.
Dlaczego to ważne
Wskazuje sprawy wymagające interwencji.
Skąd pobrać
Wyznaczany na podstawie wystąpienia działania Audit Exception Flagged
Przykłady
truefalse
|
|||
|
Kategoria korekty
CorrectionCategory
|
Rodzaj wprowadzonej korekty danych, na przykład czasu pracy, stawki lub potrącenia. | ||
|
Opis
Gdy występuje działanie Data Correction Performed, ten atrybut określa rodzaj wprowadzonej poprawki. Jest niezbędny do obliczania KPI dotyczącego odsetka ręcznych korekt danych. Informacja, czy korekty dotyczą głównie ewidencji czasu pracy, czy potrąceń na świadczenia, pozwala wskazać systemy lub zespoły, które warto objąć działaniami usprawniającymi.
Dlaczego to ważne
Pozwala szczegółowo analizować przyczyny ponownej pracy.
Skąd pobrać
Kolumna Field Changed w dzienniku audytowym
Przykłady
Korekta ewidencji czasu pracyWynagrodzenie z mocą wstecznąAktualizacja kodu podatkowego
|
|||
|
Rodzaj pracownika
EmployeeType
|
Kategoria pracownika, na przykład pełnoetatowy, niepełnoetatowy lub wykonawca. | ||
|
Opis
Ten atrybut określa kategorię osoby powiązanej z rekordem płacowym. Jest używany na dashboardzie skuteczności zatwierdzania ewidencji czasu pracy. Pracownicy różnych kategorii często inaczej przesyłają karty czasu pracy i korzystają z odmiennych workflow zatwierdzania. Podział danych według tego atrybutu pomaga odróżnić problemy systemowe od zachowań typowych dla określonych grup pracowników.
Dlaczego to ważne
Pozwala analizować dane według kategorii pracowników.
Skąd pobrać
Tabela Employee Master
Przykłady
Pełny etatNiepełny etatWykonawca
|
|||
|
Źródło danych o premiach
IncentiveSource
|
Źródło danych o premiach, na przykład Salesforce lub import z Excela. | ||
|
Opis
Ten atrybut wskazuje źródło danych o premiach lub prowizjach zaimportowanych do rekordu płacowego. Wspiera dashboard dokładności importu danych o premiach. Zestawienie tego atrybutu z KPI dotyczącym częstotliwości ponownej pracy nad danymi o premiach pozwala ustalić, czy określone pliki źródłowe, na przykład raport sprzedaży regionu północno-wschodniego, regularnie zawierają błędy formatowania lub problemy z jakością danych.
Dlaczego to ważne
Pozwala powiązać problemy z jakością danych z ich zewnętrznymi dostawcami.
Skąd pobrać
Nazwa pliku w dzienniku importu lub opis identyfikatora partii
Przykłady
Plik z danymi o prowizjach od sprzedażyRęczne przesłanie danych o premiachSystem wynagrodzeń kadry kierowniczej
|
|||
Działania w procesie naliczania wynagrodzeń
| Działanie | Opis | ||
|---|---|---|---|
|
Realizacja wypłaty
|
Data realizacji lub faktyczne przekazanie środków pracownikowi. Oznacza spełnienie zobowiązania do wypłaty wynagrodzenia. | ||
|
Dlaczego to ważne
Służy do weryfikacji zgodności z SLA i potwierdzenia, że pracownicy otrzymują wynagrodzenie w ustalonym terminie.
Skąd pobrać
Użyj pola „Check Date” lub „Advice Date” w sfinalizowanym rekordzie Pay Header.
Rejestrowanie
Rejestrowane po wykonaniu transakcji payment_post
Typ zdarzenia
explicit
|
|||
|
Utworzenie rekordu płacowego
|
Utworzenie pozycji płacowej dla pracownika w nowej instancji grupy płacowej. Oznacza, że pracownik jest aktywny i przypisany do bieżącego cyklu przetwarzania. | ||
|
Dlaczego to ważne
Wyznacza oficjalny początek przetwarzania płac w głównym systemie. Pozwala odróżnić czas rejestrowania godzin od czasu faktycznego naliczania wynagrodzeń.
Skąd pobrać
Ustal znacznik czasu wstawienia rekordu do tabeli Employee Pay lub Check Header dla określonej daty wypłaty.
Rejestrowanie
Rejestrowane po wykonaniu transakcji pay_period_create
Typ zdarzenia
explicit
|
|||
|
Zatwierdzenie rekordu płacowego
|
Ostateczne zatwierdzenie pojedynczego rekordu lub całej grupy płacowej. Blokuje dalsze zmiany w rekordzie i dodaje go do kolejki generowania wypłat. | ||
|
Dlaczego to ważne
Ważny etap oddzielający pracę nad rekordem od jego finalizacji. Służy do obliczania wskaźnika „Bank Transfer File Lead Time”.
Skąd pobrać
Pobierz z tabeli Pay Period Control zmianę statusu grupy płacowej lub pojedynczego rekordu Check na „Approved” lub „Locked”.
Rejestrowanie
Rejestrowane po wykonaniu transakcji approve_pay_group
Typ zdarzenia
explicit
|
|||
|
Złożenie deklaracji podatkowej
|
Pomyślne przekazanie danych podatkowych do właściwych jurysdykcji: federalnych, stanowych i lokalnych. Często następuje po wypłacie. | ||
|
Dlaczego to ważne
Ten etap jest niezbędny, aby dashboard „Multi State Tax Filing Timelines” pomagał monitorować zgodność z przepisami i unikać kar.
Skąd pobrać
Pobierz z interfejsu składania deklaracji podatkowych lub dziennika Payment Services aktualizację statusu na „Filed” lub „Accepted”.
Rejestrowanie
Rejestrowane po wykonaniu transakcji tax_file_transmit
Typ zdarzenia
explicit
|
|||
|
Import danych o premiach i prowizjach
|
Wczytanie zewnętrznych danych o składnikach wynagrodzenia, takich jak prowizje, premie lub jednorazowe wypłaty. Dane te różnią się od standardowych godzin pracy i często są przesyłane w plikach zbiorczych. | ||
|
Dlaczego to ważne
Duża liczba błędów lub konieczność ponownej pracy po tej czynności wskazują na problemy z mapowaniem danych lub jakością plików zewnętrznych. To częsta przyczyna opóźnień w wypłatach.
Skąd pobrać
Pobierz dane z dziennika systemowego lub historii importu zbiorczego, w której typ pliku dotyczy „Incentives” lub „Additional Pay”.
Rejestrowanie
Rejestrowane po wykonaniu transakcji import_batch_data
Typ zdarzenia
explicit
|
|||
|
Korekta danych
|
Ręczna zmiana rekordu płacowego, na przykład korekta godzin lub nadpisanie danych podatkowych, po pierwszym obliczeniu, ale przed ostatecznym zatwierdzeniem. | ||
|
Dlaczego to ważne
To podstawowa miara ponownej pracy. Jej monitorowanie pozwala obliczyć KPI „Manual Data Correction Rate”.
Skąd pobrać
Pobierz z dziennika audytowego aktualizacje tabel Employee Pay Detail lub Deduction, w których User ID nie ma wartości „System”.
Rejestrowanie
Rejestrowane po wykonaniu transakcji update_pay_detail
Typ zdarzenia
explicit
|
|||
|
Naliczanie potrąceń na świadczenia
|
System nalicza od wynagrodzenia brutto przed- i poopodatkowane potrącenia na świadczenia, takie jak ubezpieczenie zdrowotne i 401k. Zwykle odbywa się to bezpośrednio po ustaleniu wynagrodzenia brutto. | ||
|
Dlaczego to ważne
Błędy na tym etapie często wymagają ręcznych korekt. Wyodrębnienie tej czynności pomaga ustalić, czy opóźnienia wynikają z działania modułu świadczeń, czy z problemów z konfiguracją.
Skąd pobrać
Ustal na podstawie znacznika czasu obliczeń zbiorczych lub znaczników czasu utworzenia w tabeli Employee Deduction History.
Rejestrowanie
Ustal przez porównanie pola calculation_stage
Typ zdarzenia
inferred
|
|||
|
Obliczenie podatków
|
Końcowy etap działania silnika obliczeniowego, w którym stosowane są reguły podatkowe dla wielu stanów, aby ustalić wynagrodzenie netto. Kończy automatyczne obliczenia. | ||
|
Dlaczego to ważne
Kończy sekwencję „Gross to Net”. Długi czas na tym etapie może wskazywać na problemy z wydajnością silnika podatkowego lub złożoną konfigurację wielu jurysdykcji.
Skąd pobrać
Ustal na podstawie pola „End Time” procesu obliczeń zbiorczych w dzienniku zadań systemowych lub znacznika czasu w tabeli Employee Tax.
Rejestrowanie
Porównaj pole statusu przed zakończeniem zadania obliczeniowego i po nim
Typ zdarzenia
inferred
|
|||
|
Obliczenie wynagrodzenia brutto
|
Pierwsze obliczenie, podczas którego system ustala łączne zarobki na podstawie przepracowanych godzin, stawek i danych o premiach. Następuje przed naliczeniem potrąceń i podatków. | ||
|
Dlaczego to ważne
Pomiar czasu od tego etapu do „Taxes Calculated” pozwala obliczyć wskaźnik „Gross to Net Calculation Velocity”, używany do analizy wydajności systemu.
Skąd pobrać
Ustal na podstawie pola „Start Time” procesu obliczeń zbiorczych w dzienniku zadań systemowych.
Rejestrowanie
Porównaj pole statusu przed rozpoczęciem zadania obliczeniowego i po nim
Typ zdarzenia
inferred
|
|||
|
Podgląd wyniku naliczenia wynagrodzeń
|
Użytkownik otwiera rejestr płacowy lub raport podglądu, aby sprawdzić obliczone wyniki. Oznacza to przejście od automatycznego przetwarzania do weryfikacji przez człowieka. | ||
|
Dlaczego to ważne
Oznacza początek etapu weryfikacji. Długa przerwa między obliczeniami a podglądem może wskazywać na brak dostępnych zasobów.
Skąd pobrać
Pobierz dane z dziennika audytowego dotyczące otwarcia przez użytkownika raportu „Payroll Register” lub „Pre-Check”.
Rejestrowanie
Rejestrowane po wykonaniu transakcji report_view_preview
Typ zdarzenia
explicit
|
|||
|
Przesłanie karty czasu pracy
|
Zdarzenie, w którym pracownik lub menedżer przesyła kartę czasu pracy za dany okres płacowy. Oznacza wprowadzenie surowych danych o przepracowanych godzinach do workflow płacowego. Karta może powstać w module Time Management, a następnie trafić do głównego modułu Payroll. | ||
|
Dlaczego to ważne
Wyznacza najwcześniejszy znacznik czasu w całym cyklu płacowym. Jest niezbędny do pomiaru czasu od wykonania pracy do wprowadzenia danych płacowych do systemu.
Skąd pobrać
Pobierz dane z dziennika audytowego Time Management lub tabeli historii kart czasu pracy, w której pole Status zmienia się na „Submitted”.
Rejestrowanie
Rejestrowane po wykonaniu transakcji time_card_submit
Typ zdarzenia
explicit
|
|||
|
Udostępnienie paska płacowego
|
Pasek płacowy staje się dostępny dla pracownika w portalu samoobsługowym. Kończy to przekazywanie informacji o wypłacie. | ||
|
Dlaczego to ważne
Choć nie jest to techniczny warunek realizacji wypłaty, późne udostępnienie paska zwiększa liczbę zgłoszeń do helpdesku i obniża zadowolenie pracowników.
Skąd pobrać
Ustal na podstawie pola „Check Date” lub ustawienia „Self Service Release Date” w konfiguracji grupy płacowej.
Rejestrowanie
Ustal przez porównanie pola check_date z release_policy
Typ zdarzenia
inferred
|
|||
|
Wygenerowanie pliku przelewów bankowych
|
Techniczne wygenerowanie pliku NACHA lub pliku przelewów bezpośrednich do wysłania do banku. Przygotowuje środki do przekazania. | ||
|
Dlaczego to ważne
Opóźnienia na tym etapie mogą spowodować niedotrzymanie bankowych godzin granicznych. Dane z tego etapu zasilają dashboard „Bank Transfer Generation Speed”.
Skąd pobrać
Pobierz z dziennika zadań systemowych znacznik czasu zakończenia zadania tworzącego plik ACH lub plik przelewów bezpośrednich.
Rejestrowanie
Rejestrowane po wykonaniu transakcji create_ach_file
Typ zdarzenia
explicit
|
|||
|
Wykrycie wyjątku audytowego
|
System lub użytkownik wykrywa niezgodność, na przykład ujemne wynagrodzenie, brak kodów podatkowych lub ostrzeżenie o SLA. Rekord wymaga wtedy sprawdzenia. | ||
|
Dlaczego to ważne
Dane z tego etapu zasilają dashboard „Audit Exception and Correction Trends”. Duża liczba wyjątków wskazuje na problemy z jakością danych na wcześniejszych etapach.
Skąd pobrać
Wskaż rekordy w dzienniku ostrzeżeń systemowych lub tabeli komunikatów okresu płacowego powiązane z konkretnymi identyfikatorami pracowników.
Rejestrowanie
Rejestrowane po utworzeniu transakcji validation_warning
Typ zdarzenia
explicit
|
|||
|
Zatwierdzenie karty czasu pracy
|
Menedżer zatwierdza przesłane godziny i potwierdza ich poprawność do rozliczenia. Ten etap udostępnia dane do importu do silnika obliczającego wynagrodzenia. | ||
|
Dlaczego to ważne
Analiza wąskich gardeł na tym etapie ujawnia opóźnienia związane z weryfikacją przez kadrę zarządzającą. Bezpośrednio skracają one czas, jaki pozostaje specjalistom ds. płac na przetwarzanie danych.
Skąd pobrać
Pobierz dane z historii Time Management, w której pole Status zmienia się na „Approved” lub „Signed Off”.
Rejestrowanie
Rejestrowane po wykonaniu transakcji time_card_approve
Typ zdarzenia
explicit
|
|||
Instrukcje ekstrakcji danych
Gotowi do rozpoczęcia?
Skorzystaj z tego szablonu, aby przekształcić surowe dane z UKG Pro w wizualną mapę procesu. Jeśli konfiguracja ekstrakcji w złożonym środowisku płacowym sprawia trudności, można skontaktować się z naszym zespołem wsparcia.
Już teraz usprawnij naliczanie wynagrodzeń w UKG Pro
Skróć cykl wypłat o 30% i wyeliminuj wąskie gardła.
Karta kredytowa nie jest wymagana, konfiguracja zajmuje 5 minut