Szablon danych Record to Report: księgowanie
Szablon danych Record to Report: księgowanie
- Zalecane atrybuty do zebrania
- Najważniejsze działania do śledzenia
- Wskazówki dotyczące pobierania danych z Oracle Fusion Financials
Atrybuty procesu Record to Report: księgowanie
| Nazwa | Opis | ||
|---|---|---|---|
|
Czas rozpoczęcia
EventTime
|
Znacznik czasu wskazujący, kiedy wystąpiła dana czynność lub zdarzenie. | ||
|
Opis
Ten znacznik czasu określa dokładną datę i godzinę wykonania czynności. W process mining służy przede wszystkim do ustalania kolejności zdarzeń i obliczania czasu między nimi. Dokładność czasu zdarzenia ma zasadnicze znaczenie dla wszystkich analiz opartych na czasie, w tym pomiaru czasu realizacji, wykrywania wąskich gardeł i monitorowania wyników względem umów o poziomie usług. Zapewnia chronologiczną kolejność potrzebną do odtworzenia rzeczywistego przebiegu procesu.
Dlaczego to ważne
Ten znacznik czasu jest niezbędny do ustalania kolejności zdarzeń, obliczania czasu trwania procesu i przeprowadzania analiz opartych na czasie.
Skąd pobrać
Te informacje są zwykle przechowywane w tabelach ścieżki audytu albo jako „Last Update Date” lub „Creation Date” w tabelach transakcyjnych, takich jak GL_JE_HEADERS i GL_JE_LINES, dla określonych zdarzeń.
Przykłady
2023-10-26T10:00:00Z2023-11-15T14:35:10Z2024-01-05T09:12:00Z
|
|||
|
Czynność
ActivityName
|
Nazwa konkretnego zdarzenia biznesowego lub zadania, które wystąpiło w danym momencie procesu obsługi zapisu księgowego. | ||
|
Opis
Nazwa czynności opisuje pojedynczy etap cyklu życia zapisu księgowego, na przykład „Utworzenie zapisu księgowego” lub „Zatwierdzenie zapisu księgowego”. Te dane są niezbędne do utworzenia mapy procesu i zrozumienia kolejności zdarzeń. Analiza czynności pozwala określić przebieg procesu, w tym standardowe ścieżki, odstępstwa i pętle poprawek. Śledzenie poszczególnych czynności umożliwia pomiar czasu spędzonego na konkretnych etapach, takich jak zatwierdzanie, oraz wskazanie najbardziej czasochłonnych lub podatnych na błędy kroków.
Dlaczego to ważne
Określa etapy procesu i stanowi podstawę mapy procesu, umożliwiając analizę przebiegu, wąskich gardeł i różnic.
Skąd pobrać
Ten atrybut jest zwykle wyznaczany na podstawie zmian statusu, dzienników zdarzeń lub tabel ścieżki audytu powiązanych z zapisami księgowymi w module księgi głównej.
Przykłady
Utworzono zapis księgowyPrzesłano zapis księgowy do akceptacjiZatwierdzenie zapisu księgowegoZapis zaksięgowany
|
|||
|
Identyfikator Journal Entry ID
JournalEntryId
|
Unikalny identyfikator pojedynczego zapisu księgowego, który łączy wszystkie powiązane z nim operacje finansowe. | ||
|
Opis
Journal Entry ID pełni funkcję głównego identyfikatora sprawy i jednoznacznie łączy wszystkie czynności dotyczące określonego zestawu transakcji finansowych. Umożliwia śledzenie pełnego cyklu życia pojedynczego zapisu, od rozpoczęcia do zaksięgowania, oraz sprawdzenie, czy uwzględniono wszystkie obciążenia i uznania. W process mining ten identyfikator jest niezbędny do odtworzenia pełnej ścieżki każdego zapisu księgowego. Łączy odrębne zdarzenia, takie jak „Utworzenie zapisu księgowego”, „Zapis przesłany do zatwierdzenia” i „Zapis zaksięgowany”, w spójny przebieg procesu. Dzięki temu można analizować czas realizacji, wąskie gardła i różnice w przebiegu procesu.
Dlaczego to ważne
To podstawowy identyfikator, który pozwala śledzić zapis księgowy od początku do końca i analizować pełny przebieg procesu dla każdej sprawy.
Skąd pobrać
To klucz główny występujący w podstawowych tabelach księgi głównej, takich jak GL_JE_HEADERS i GL_JE_LINES.
Przykłady
JE100523JE202311001882019
|
|||
|
Ostatnia aktualizacja danych
LastDataUpdate
|
Znacznik czasu ostatniego odświeżenia danych lub ich pobrania z systemu źródłowego. | ||
|
Opis
Ten atrybut wskazuje, kiedy ostatnio zaktualizowano zbiór danych. Informuje, jak aktualne są analizowane dane, co pozwala ocenić przydatność uzyskanych wniosków. W każdej analizie, a szczególnie na dashboardach operacyjnych, znajomość czasu ostatniej aktualizacji danych pomaga użytkownikom ocenić ich wiarygodność i podejmować świadome decyzje. Jasno określa też, do którego momentu uwzględniono dane w modelu process mining.
Dlaczego to ważne
Informuje o aktualności danych, dzięki czemu użytkownicy wiedzą, na jakim okresie opiera się analiza procesu, i mogą ocenić wiarygodność wniosków.
Skąd pobrać
Ta wartość jest generowana i zapisywana podczas pobierania i przekształcania danych. Zwykle jest to znacznik czasu zakończenia zadania ETL/ELT.
Przykłady
2023-11-20T08:00:00Z2023-11-21T08:00:00Z2023-11-22T08:00:00Z
|
|||
|
System źródłowy
SourceSystem
|
System lub moduł, z którego pochodzą dane. | ||
|
Opis
Ten atrybut wskazuje system źródłowy, z którego pobrano dane o procesie. W złożonym środowisku IT dane mogą pochodzić z wielu zintegrowanych systemów, a to pole pozwala je rozróżnić. Znajomość systemu źródłowego pomaga zrozumieć różnice w przebiegu procesu wynikające ze sposobu działania poszczególnych systemów. Ułatwia też weryfikację danych i rozwiązywanie problemów, ponieważ pozwala prześledzić ich pochodzenie.
Dlaczego to ważne
Wskazuje pochodzenie danych, co ma znaczenie dla zarządzania danymi, ich weryfikacji i analizy różnic w przebiegu procesu między systemami.
Skąd pobrać
Często jest to stała wartość ustawiana podczas pobierania danych albo pole w tabelach źródłowych wskazujące system, w którym wprowadzono zapis.
Przykłady
Oracle Fusion Financials CloudOracle EBS R12Fusion GL
|
|||
|
Dział użytkownika
UserDepartment
|
Dział lub zespół, do którego należy użytkownik wykonujący czynność. | ||
|
Opis
Ten atrybut zapewnia kontekst organizacyjny, łącząc czynność z konkretnym działem, na przykład „Finanse”, „Operacje księgowe” lub „Audyt wewnętrzny”. Zwykle jest pobierany z danych podstawowych użytkowników. Analiza według działu użytkownika pomaga wykrywać wąskie gardła między działami, porównywać wyniki zespołów i sprawdzać, jak przebieg procesu różni się w poszczególnych częściach organizacji. Ułatwia też przydzielanie zasobów i planowanie działań usprawniających.
Dlaczego to ważne
Zapewnia kontekst organizacyjny, umożliwia analizę wyników według zespołu lub działu i pomaga wykrywać nieefektywności na styku różnych funkcji.
Skąd pobrać
Tych danych zwykle nie ma w tabelach transakcyjnych. Należy je pobrać, łącząc UserName z tabelą danych podstawowych użytkowników lub danymi systemu HR.
Przykłady
Księgowość głównaSprawozdawczość finansowaZobowiązania
|
|||
|
Kategoria zapisu
JournalCategory
|
Kategoria zapisu księgowego, na przykład „Rozliczenie międzyokresowe”, „Korekta” lub „Reklasyfikacja”. | ||
|
Opis
Kategoria zapisu klasyfikuje zapisy według ich celu biznesowego. Umożliwia dokładniejszą analizę procesu, ponieważ poszczególne kategorie mogą mieć różny przebieg, zasady zatwierdzania lub czas realizacji. Na przykład korekty na koniec miesiąca mogą wymagać bardziej złożonej i pilnej obsługi niż standardowe rozliczenia międzyokresowe. Analiza według kategorii pozwala wykryć te różnice i dostosować usprawnienia do konkretnych typów zapisów.
Dlaczego to ważne
Pozwala podzielić proces według celu biznesowego zapisu i ujawnić różnice w przebiegu oraz wynikach dla poszczególnych typów zapisów.
Skąd pobrać
Dostępna w tabeli GL_JE_HEADERS, zwykle w polu JE_CATEGORY.
Przykłady
Rozliczenie międzyokresoweRęcznyKorektaPrzeszacowanie
|
|||
|
Kwota zapisu
JournalAmount
|
Łączna wartość pieniężna zapisu księgowego, zwykle suma obciążeń. | ||
|
Opis
Ten atrybut określa łączną wartość finansową transakcji ujętej w zapisie. Kwota może wpływać na przebieg procesu. Na przykład zapisy o wysokiej wartości mogą wymagać dodatkowych etapów zatwierdzania lub dokładniejszej weryfikacji. Analiza kwoty zapisu pozwala podzielić sprawy według wpływu finansowego i odpowiedzieć na pytania, takie jak „Czy zatwierdzanie zapisów o wysokiej wartości trwa dłużej?” lub „Czy zapisy przekraczające określony próg są częściej odrzucane?”. Dzięki temu przebieg procesu można ocenić w kontekście biznesowym.
Dlaczego to ważne
Zapewnia kontekst biznesowy do analizy wpływu finansowego i pomaga ustalić, czy zapisy o wysokiej wartości przebiegają innym procesem.
Skąd pobrać
Wartość jest zwykle obliczana jako suma obciążeń lub uznań z tabeli GL_JE_LINES dla danego zapisu księgowego.
Przykłady
5000.00125000.75750.50
|
|||
|
Przyczyna odrzucenia
RejectionReason
|
Opis tekstowy lub kod wyjaśniający, dlaczego zapis księgowy został odrzucony. | ||
|
Opis
Ten atrybut rejestruje przyczynę odrzucenia zapisu podczas procesu zatwierdzania. Może to być wcześniej zdefiniowany kod lub komentarz osoby zatwierdzającej. To jeden z najważniejszych atrybutów w analizie przyczyn nieefektywności procesu. Analiza najczęstszych przyczyn odrzucenia pozwala wskazać obszary wymagające poprawy, na przykład lepsze szkolenie osób przygotowujących zapisy, jaśniejsze wytyczne lub usprawnienie kontroli systemowych. Atrybut wspiera dashboard „Analiza odrzuceń zapisów księgowych”.
Dlaczego to ważne
Bezpośrednio wskazuje przyczyny poprawek i opóźnień w procesie, umożliwiając ukierunkowane działania ograniczające liczbę odrzuceń.
Skąd pobrać
Informacje te mogą być przechowywane w tabelach workflow lub ścieżki audytu powiązanych z procesem zatwierdzania albo w polu notatek nagłówka zapisu.
Przykłady
Nieprawidłowa kombinacja kontBrak wymaganej dokumentacji potwierdzającejPrzekroczenie budżetu
|
|||
|
Użytkownik
UserName
|
Użytkownik, który wykonał czynność, na przykład utworzył, zatwierdził lub zaksięgował zapis. | ||
|
Opis
Ten atrybut wskazuje pracownika lub użytkownika systemu odpowiedzialnego za wykonanie czynności. Pomaga analizować rozkład obciążenia i wyniki pracy oraz wykrywać wąskie gardła związane z poszczególnymi osobami. Atrybut UserName umożliwia filtrowanie procesów według użytkownika, porównywanie efektywności pracy i badanie przyczyn opóźnień lub błędów. Wspiera dashboardy, takie jak „Obciążenie i efektywność użytkowników w zespołach”, oraz KPI, takie jak „Wskaźnik wąskich gardeł w obsłudze zapisów przez użytkowników”.
Dlaczego to ważne
Przypisuje odpowiedzialność za poszczególne etapy procesu, umożliwiając analizę obciążenia użytkowników, indywidualnych wyników pracy i potrzeb szkoleniowych.
Skąd pobrać
Dane znajdują się w tabelach transakcyjnych, takich jak GL_JE_HEADERS (np. CREATED_BY, LAST_UPDATED_BY), oraz w powiązanych tabelach ścieżki audytu.
Przykłady
john.doesusan.smithautoprocess_user
|
|||
|
Źródło zapisu
JournalSource
|
Księga pomocnicza lub źródło, z którego pochodzi zapis księgowy, na przykład „Zobowiązania”, „Należności” lub „Ręczne”. | ||
|
Opis
Ten atrybut wskazuje źródło zapisu księgowego w systemie ERP. Zapisy mogą być wprowadzane ręcznie w księdze głównej lub generowane automatycznie przez księgi pomocnicze, takie jak zobowiązania, należności czy środki trwałe. Źródło zapisu jest ważnym atrybutem w analizie automatyzacji. Pozwala odróżnić zapisy ręczne od generowanych przez system i wspiera pomiar KPI „Odsetek zautomatyzowanych zapisów księgowych”. Procesy dotyczące zapisów z różnych źródeł często znacznie różnią się złożonością i efektywnością.
Dlaczego to ważne
Pozwala odróżnić zapisy ręczne od automatycznych, co ma znaczenie przy pomiarze poziomu automatyzacji i analizie różnic w przebiegu procesu.
Skąd pobrać
Dostępne w tabeli GL_JE_HEADERS, zwykle w polu JE_SOURCE.
Przykłady
RęcznyZobowiązaniaŚrodki trwałeNależności
|
|||
|
Czas zakończenia
EndTime
|
Znacznik czasu wskazujący, kiedy zakończono daną czynność. | ||
|
Opis
Czas zakończenia wskazuje, kiedy czynność dobiegła końca. Czas rozpoczęcia rejestruje jej początek, a czas zakończenia wyznacza koniec, co pozwala dokładnie obliczyć czas realizacji danego kroku. To niezbędne do pomiaru czasu realizacji czynności, który pomaga wykrywać wąskie gardła i oceniać efektywność wykorzystania zasobów. Na przykład różnica między czasem zakończenia a czasem rozpoczęcia czynności „Weryfikacja zapisu księgowego” pokazuje, ile czasu osoba weryfikująca faktycznie poświęciła na zadanie.
Dlaczego to ważne
Pozwala obliczyć rzeczywisty czas trwania lub realizacji poszczególnych czynności, co pomaga wykrywać problemy z efektywnością.
Skąd pobrać
Podobnie jak czas rozpoczęcia, często znajduje się w tabelach ścieżki audytu. Można go też wywnioskować z czasu rozpoczęcia kolejnej czynności w procesie.
Przykłady
2023-10-26T10:15:00Z2023-11-15T14:55:10Z2024-01-05T09:22:00Z
|
|||
|
Czy wymagało poprawek
IsRework
|
Obliczana flaga przyjmująca wartość prawda, jeśli zapis księgowy przeszedł cykl odrzucenia i poprawy. | ||
|
Opis
Ten atrybut logiczny jest obliczany w celu identyfikacji spraw wymagających poprawek. Zwykle otrzymuje wartość „true” dla każdej czynności po zdarzeniu „Zapis księgowy odrzucony”, na przykład „Zapis poprawiony i przesłany ponownie”. Atrybut „Czy wymagało poprawek” ułatwia analizę, ponieważ pozwala określić skalę i wpływ poprawek. Wspiera KPI „Średni odsetek zapisów wymagających poprawek” i pomaga porównywać przebieg oraz czas realizacji spraw poprawionych z tymi, które zostały prawidłowo obsłużone za pierwszym razem.
Dlaczego to ważne
Bezpośrednio oznacza sprawy, w których wystąpiła nieefektywna pętla poprawek, ułatwiając pomiar częstotliwości i wpływu problemów w procesie.
Skąd pobrać
Ten atrybut nie jest dostępny w systemie źródłowym. Oblicza się go w narzędziu process mining na podstawie sekwencji czynności dla każdej sprawy.
Przykłady
truefalse
|
|||
|
Czy zaksięgowano w terminie
IsOnTimePosting
|
Obliczana flaga przyjmująca wartość prawda, jeśli zapis zaksięgowano w docelowym terminie lub wcześniej. | ||
|
Opis
Ten atrybut logiczny jest wyznaczany przez porównanie znacznika czasu czynności „Zapis zaksięgowany” z docelową datą księgowania. Jeśli księgowanie nastąpiło w terminie lub wcześniej, wartością jest „true”. W przeciwnym razie jest to „false”. Atrybut ten bezpośrednio wspiera KPI „Odsetek zapisów zaksięgowanych w terminie”, upraszczając jego obliczanie. Ułatwia filtrowanie i analizę opóźnionych zapisów oraz ustalanie ich częstych przyczyn, takich jak określone kategorie zapisów lub osoby zatwierdzające.
Dlaczego to ważne
Jasno wskazuje, czy zapis zaksięgowano w terminie, ułatwiając analizę terminowości i przyczyn opóźnień.
Skąd pobrać
Ten atrybut oblicza narzędzie process mining. Wymaga atrybutu „TargetPostingDate” oraz znacznika czasu czynności „Zapis zaksięgowany”.
Przykłady
truefalse
|
|||
|
Docelowa data księgowania
TargetPostingDate
|
Ustalona z góry data, do której zapis księgowy powinien zostać zaksięgowany. | ||
|
Opis
Docelowa data księgowania to termin zaksięgowania zapisu w księdze głównej. Często wynika z umów o poziomie usług (SLA) lub harmonogramu zamknięcia miesiąca. Stanowi punkt odniesienia do pomiaru wyników. Ten atrybut jest niezbędny do obliczenia KPI „Odsetek zapisów zaksięgowanych w terminie”. Porównanie faktycznej daty księgowania z terminem pozwala automatycznie oznaczać zapisy jako zaksięgowane na czas lub z opóźnieniem. Dzięki temu można jasno ocenić, czy proces przebiega zgodnie z harmonogramem.
Dlaczego to ważne
Określa termin wynikający z umowy o poziomie usług lub harmonogramu księgowania, co pozwala obliczać KPI dotyczące terminowości.
Skąd pobrać
To pole może nie być dostępne standardowo. Można je wyznaczyć na podstawie reguł biznesowych uwzględniających datę utworzenia, okres obrachunkowy lub kategorię zapisu.
Przykłady
2023-10-312023-11-302024-01-05
|
|||
|
Łączny czas realizacji procesu
EndToEndCycleTime
|
Łączny obliczony czas od utworzenia zapisu księgowego do jego ostatecznego uzgodnienia. | ||
|
Opis
Ta miara określa łączny czas obsługi zapisu w całym procesie, od pierwszego zdarzenia „Utworzenie zapisu księgowego” do ostatniego zdarzenia „Zapis uzgodniony”. Pokazuje ogólne wyniki procesu. To podstawowy KPI służący do pomiaru ogólnej sprawności procesu. Dashboardy trendów wykorzystują go do śledzenia wpływu działań usprawniających w czasie. Stanowi też punkt odniesienia przy ocenie zmian w procesie.
Dlaczego to ważne
Zapewnia ogólną miarę sprawności i kondycji procesu, dlatego jest ważnym wskaźnikiem w raportach dla kadry kierowniczej.
Skąd pobrać
Platforma process mining oblicza tę miarę jako różnicę między znacznikami czasu pierwszego i ostatniego zdarzenia dla każdej sprawy.
Przykłady
10 dni, 5 godzinP4DT12HP22D
|
|||
|
Nazwa księgi
LedgerName
|
Nazwa księgi głównej, w której zarejestrowano zapis księgowy. | ||
|
Opis
Nazwa księgi wskazuje konkretną księgę, do której należy zapis. Organizacje prowadzące działalność w wielu podmiotach prawnych lub sporządzające różne rodzaje sprawozdań mogą korzystać z kilku ksiąg, na przykład głównej księgi do celów korporacyjnych i dodatkowych ksiąg na potrzeby lokalnej sprawozdawczości ustawowej. Ten atrybut pozwala filtrować i porównywać procesy między podmiotami prawnymi lub jednostkami biznesowymi. Zapewnia właściwy kontekst organizacyjny analizy, co jest szczególnie ważne w przypadku zgodności finansowej i sprawozdawczości.
Dlaczego to ważne
Pozwala filtrować i porównywać procesy między podmiotami prawnymi lub zasadami rachunkowości, co ma duże znaczenie w dużych organizacjach.
Skąd pobrać
Dostępna w tabeli GL_JE_HEADERS, zwykle przez pole LEDGER_ID, które można połączyć z tabelą GL_LEDGERS, aby pobrać nazwę księgi.
Przykłady
Główna księga dla USAKsięga ustawowa dla Wielkiej BrytaniiGlobalna księga konsolidacyjna
|
|||
|
Okres obrachunkowy
AccountingPeriod
|
Okres obrachunkowy, w którym zaksięgowano zapis, na przykład „sty-24”. | ||
|
Opis
Okres obrachunkowy określa okres finansowy, w którym ujmuje się transakcję. Jest to podstawowa informacja w sprawozdawczości i analizie finansowej. W process mining ten atrybut jest niezbędny do analizy trendów. Umożliwia porównywanie wyników procesu, takich jak czas realizacji lub odsetek odrzuceń, w różnych miesiącach i kwartałach. Pomaga wykrywać sezonowość, na przykład większe obciążenie podczas zamknięcia miesiąca, oraz mierzyć wpływ usprawnień w czasie.
Dlaczego to ważne
Umożliwia analizę trendów KPI w czasie, pomaga mierzyć usprawnienia procesu i wykrywać sezonowe obciążenia, takie jak zamknięcie miesiąca.
Skąd pobrać
Dostępny w tabeli GL_JE_HEADERS, zwykle w polu PERIOD_NAME.
Przykłady
Sty-24Lut-24Mar-24
|
|||
|
Status księgowania
PostingStatus
|
Bieżący status księgowania zapisu, na przykład „Nie zaksięgowano” lub „Zaksięgowano”. | ||
|
Opis
Ten atrybut wskazuje bieżący stan księgowania zapisu w księdze głównej. Pokazuje, na jakim etapie cyklu życia znajduje się zapis, szczególnie w przypadku spraw będących w toku. Status księgowania jest niezbędny na dashboardzie „Monitorowanie statusu zapisów księgowych w czasie rzeczywistym”, który przedstawia wszystkie aktywne zapisy. Pomaga monitorować zaległe zapisy i wykrywać opóźnienia na końcowych etapach procesu.
Dlaczego to ważne
Wskazuje bieżący stan zapisu, co ułatwia monitorowanie zaległości i śledzenie zapisów będących w toku.
Skąd pobrać
Dostępny w tabeli GL_JE_HEADERS, zwykle w kolumnie STATUS lub POSTING_STATUS.
Przykłady
ZaksięgowanoNie zaksięgowanoBłąd
|
|||
|
Waluta
CurrencyCode
|
Kod waluty kwoty zapisu księgowego, na przykład USD, EUR lub GBP. | ||
|
Opis
Kod waluty określa walutę kwot finansowych ujętych w zapisie. Jest to niezbędna informacja dla międzynarodowych organizacji, które przeprowadzają transakcje w wielu walutach. Ten atrybut zapewnia prawidłową interpretację wartości finansowych. Umożliwia filtrowanie według waluty i jest niezbędny w analizach porównujących lub sumujących kwoty pieniężne z różnych regionów.
Dlaczego to ważne
Zapewnia kontekst niezbędny do prawidłowej interpretacji kwot finansowych i umożliwia analizę według waluty.
Skąd pobrać
Dostępna w tabeli GL_JE_HEADERS, zwykle w polu CURRENCY_CODE.
Przykłady
USDEURGBPJPY
|
|||
|
Wskaźnik storna
ReversalIndicator
|
Flaga wskazująca, czy zapis księgowy stanowi storno innego zapisu. | ||
|
Opis
Ten atrybut logiczny identyfikuje zapisy utworzone w celu odwrócenia wcześniej zaksięgowanego zapisu. Storno to szczególny typ zapisu, który często przebiega według odrębnego, a czasem problematycznego procesu. Analiza tego wskaźnika wspiera dashboard „Wyniki procesu storna zapisów księgowych”. Pozwala wyodrębnić procesy storna i mierzyć ich częstotliwość, przyczyny oraz czas realizacji. Pomaga też wykrywać problemy w pierwotnych zapisach, które prowadzą do konieczności ich odwrócenia.
Dlaczego to ważne
Pozwala wyodrębnić i analizować proces storna, który często wskazuje na błędy lub problemy w pierwotnej transakcji.
Skąd pobrać
Może to być specjalna flaga w tabeli GL_JE_HEADERS, na przykład ACCRUAL_REV_FLAG, albo informacja wyznaczona na podstawie powiązania z pierwotnym zapisem, który jest odwracany.
Przykłady
truefalse
|
|||
Działania w procesie Record to Report: księgowanie
| Działanie | Opis | ||
|---|---|---|---|
|
Przesłano zapis księgowy do akceptacji
|
To zdarzenie występuje, gdy użytkownik formalnie przesyła ukończony zapis księgowy do workflow akceptacji. Zapis przechodzi ze stanu roboczego lub niekompletnego do oczekującego na akceptację. | ||
|
Dlaczego to ważne
To ważny etap, od którego mierzy się czas akceptacji i identyfikuje wąskie gardła. Oddziela wprowadzanie danych od weryfikacji i akceptacji.
Skąd pobrać
Zdarzenie można ustalić na podstawie zmiany statusu w tabeli GL_JE_HEADERS, a konkretnie zmiany wartości APPROVAL_STATUS_CODE na przykład na 'REQUIRED' lub 'INITIATED'. Może być również zapisana data i godzina przesłania.
Rejestrowanie
Zapisz znacznik czasu zmiany wartości APPROVAL_STATUS_CODE w GL_JE_HEADERS, która oznacza przesłanie zapisu.
Typ zdarzenia
inferred
|
|||
|
Utworzono zapis księgowy
|
To zdarzenie rozpoczyna proces obsługi zapisu księgowego. Oznacza utworzenie przez użytkownika nowego nagłówka zapisu i rozpoczęcie wprowadzania danych, zanim zapis zostanie przesłany do weryfikacji lub akceptacji. | ||
|
Dlaczego to ważne
To główne zdarzenie rozpoczynające proces. Pomiar czasu od tego momentu do kolejnych etapów pozwala ocenić sprawność wprowadzania danych i całkowity czas procesu.
Skąd pobrać
Zdarzenie to można zwykle ustalić na podstawie znacznika czasu utworzenia w tabeli GL_JE_HEADERS dla danego Journal Entry ID. Tabela zawiera również informację o użytkowniku, który utworzył rekord.
Rejestrowanie
Użyj wartości CREATION_DATE z tabeli GL_JE_HEADERS.
Typ zdarzenia
inferred
|
|||
|
Zapis uzgodniony
|
Zapis został dopasowany i rozliczony w ramach uzgadniania kont na koniec okresu. Potwierdza to zgodność transakcji z innymi danymi finansowymi, na przykład z wyciągami bankowymi. | ||
|
Dlaczego to ważne
Ta czynność stanowi faktyczny koniec cyklu życia zapisu. Czas od zaksięgowania do uzgodnienia to ważny KPI służący do oceny sprawności procesu zamknięcia finansowego.
Skąd pobrać
To zdarzenie jest zwykle rejestrowane w Oracle Financial Consolidation and Close Cloud Service (FCCS) lub Account Reconciliation Cloud Service (ARCS), a nie w samej księdze głównej. Można je wywnioskować ze zmiany statusu rekordu uzgodnienia powiązanego z zapisem.
Rejestrowanie
Powiąż dane zapisów z aktualizacjami statusu uzgodnienia w tabelach ARCS lub FCCS.
Typ zdarzenia
inferred
|
|||
|
Zapis zaksięgowany
|
Dane finansowe zapisu zostały prawidłowo zarejestrowane w księdze głównej. Obciążenia i uznania są już uwzględnione w saldach kont. | ||
|
Dlaczego to ważne
To ważny kamień milowy, który oznacza ujęcie zapisu w oficjalnej ewidencji finansowej. Pozwala mierzyć odsetek zapisów zaksięgowanych w terminie oraz łączny czas od utworzenia do zaksięgowania.
Skąd pobrać
Zdarzenie jest wnioskowane na podstawie zmiany statusu w tabeli GL_JE_HEADERS, gdzie pole STATUS przyjmuje wartość „P” (Posted). Tabela GL_JE_BATCHES zawiera również status księgowania.
Rejestrowanie
Śledź znacznik czasu zmiany wartości STATUS w GL_JE_HEADERS na „P”.
Typ zdarzenia
inferred
|
|||
|
Zatwierdzenie zapisu księgowego
|
Wyznaczona osoba zatwierdzająca formalnie zatwierdziła zapis księgowy, potwierdzając jego poprawność i zasadność. To ostatni etap workflow zatwierdzania, który umożliwia zaksięgowanie. | ||
|
Dlaczego to ważne
Ten kamień milowy oznacza koniec procesu zatwierdzania. Czas od przesłania do zatwierdzenia to ważny KPI, który pozwala mierzyć sprawność workflow i wykrywać wąskie gardła w procesie zatwierdzania.
Skąd pobrać
Zdarzenie jest wnioskowane na podstawie zmiany statusu w tabeli GL_JE_HEADERS, gdzie wartość APPROVAL_STATUS_CODE zmienia się na „APPROVED”. Tabele workflow zawierają dane osoby zatwierdzającej i znacznik czasu.
Rejestrowanie
Śledź znacznik czasu zmiany wartości APPROVAL_STATUS_CODE w GL_JE_HEADERS na „APPROVED”.
Typ zdarzenia
inferred
|
|||
|
Dołączono dokumentację pomocniczą
|
Oznacza dołączenie do zapisu księgowego dokumentów pomocniczych, takich jak faktury lub arkusze kalkulacyjne. Dokumenty te dostarczają kontekstu i potwierdzenia dla audytorów oraz osób akceptujących zapis. | ||
|
Dlaczego to ważne
Śledzenie tej czynności pomaga ustalić, czy opóźnienia wynikają z brakującej dokumentacji. Dostarcza też informacji o zgodności i kompletności zapisów przed przekazaniem ich do workflow akceptacji.
Skąd pobrać
Ustalenie tej czynności jako odrębnego zdarzenia może być trudne. Można ją wywnioskować ze znaczników czasu w tabelach załączników, takich jak FND_ATTACHED_DOCUMENTS, powiązanych z rekordem zapisu w GL_JE_HEADERS.
Rejestrowanie
Ustal zdarzenie na podstawie daty utworzenia rekordów w FND_ATTACHED_DOCUMENTS powiązanych z zapisem księgowym.
Typ zdarzenia
inferred
|
|||
|
Księgowanie storna przetworzone
|
Utworzono i zaksięgowano zapis korygujący, który odwraca wpływ finansowy pierwotnego zapisu w kolejnym okresie. Takie działanie często stosuje się w przypadku rozliczeń międzyokresowych. | ||
|
Dlaczego to ważne
Śledzenie storna pomaga ustalić, które typy zapisów są często odwracane, oraz przeanalizować sprawność samego procesu storna. Może to wskazywać na problemy z zarządzaniem rozliczeniami międzyokresowymi.
Skąd pobrać
Zdarzenie można wywnioskować, identyfikując nowy zapis księgowy jawnie powiązany z pierwotnym jako jego storno. Tabela GL_JE_HEADERS zawiera pola, takie jak REVERSAL_PERIOD i REVERSAL_FLAG, które pozwalają identyfikować i łączyć te zapisy.
Rejestrowanie
Ustal datę utworzenia i zaksięgowania nowego zapisu, którego nagłówek wskazuje pierwotny zapis jako odwracany.
Typ zdarzenia
inferred
|
|||
|
Księgowanie zweryfikowane
|
Po zaksięgowaniu użytkownik lub system sprawdza, czy zapis został zaksięgowany prawidłowo i czy salda są zgodne z oczekiwaniami. Często jest to ręczny etap kontroli. | ||
|
Dlaczego to ważne
Analiza tej czynności pokazuje, ile czasu zajmują ręczne kontrole i zapewnianie jakości po zaksięgowaniu. Może też wskazać możliwości automatyzacji weryfikacji.
Skąd pobrać
W Oracle Fusion prawdopodobnie nie ma jawnego zdarzenia odpowiadającego tej czynności. Trzeba je wywnioskować na podstawie innych działań, na przykład uruchomienia przez użytkownika określonego raportu lub aktualizacji niestandardowego pola statusu. Nie jest to standardowa funkcja.
Rejestrowanie
Wymaga niestandardowej logiki, na przykład śledzenia czasu uruchomienia raportów weryfikacyjnych lub aktualizacji opisowego pola elastycznego.
Typ zdarzenia
inferred
|
|||
|
Odrzucono zapis księgowy
|
Osoba akceptująca sprawdziła zapis księgowy i odrzuciła go z powodu błędów, braku dokumentacji lub naruszenia zasad. Zapis wraca do autora w celu poprawienia. | ||
|
Dlaczego to ważne
To zdarzenie ma zasadnicze znaczenie przy analizie powrotów do wcześniejszych etapów, odsetka odrzuceń i wskaźnika poprawności za pierwszym razem. Częste odrzucenia wskazują na problemy z jakością danych lub potrzebę dodatkowych szkoleń.
Skąd pobrać
Zdarzenie można ustalić na podstawie zmiany statusu w tabeli GL_JE_HEADERS, gdy wartość APPROVAL_STATUS_CODE zostaje zmieniona na 'REJECTED'. Historia workflow zapisuje użytkownika i znacznik czasu tej czynności.
Rejestrowanie
Zapisz znacznik czasu ustawienia wartości APPROVAL_STATUS_CODE w GL_JE_HEADERS na 'REJECTED'.
Typ zdarzenia
inferred
|
|||
|
Poprawiono i ponownie przesłano zapis księgowy
|
Po odrzuceniu zapisu księgowego jego autor wprowadza wymagane poprawki i ponownie przesyła go do akceptacji. Ta czynność rozpoczyna nowy cykl akceptacji tego samego zapisu. | ||
|
Dlaczego to ważne
Śledzenie poprawek jest niezbędne do oceny nieefektywności procesu. Zestawienie tej czynności ze zdarzeniem „Odrzucono zapis księgowy” pozwala zmierzyć czas i częstotliwość poprawek.
Skąd pobrać
To kolejne zdarzenie „Dziennik przesłany do zatwierdzenia” dotyczące dziennika, który wcześniej miał status „ODRZUCONY”. Zdarzenie jest identyfikowane na podstawie analizy sekwencji zmian statusu dla tego samego identyfikatora Journal Entry ID.
Rejestrowanie
Zidentyfikuj znacznik czasu przesłania, który występuje po odrzuceniu w ramach tej samej sprawy.
Typ zdarzenia
inferred
|
|||
|
Rozpoczęcie księgowania zapisu
|
Rozpoczęto księgowanie zatwierdzonego zapisu w księdze głównej. Ten etap może być zautomatyzowany lub wykonywany ręcznie. Zapis trafia do kolejki programu księgującego. | ||
|
Dlaczego to ważne
Ta czynność oddziela zatwierdzenie od technicznego procesu księgowania. Opóźnienie między zatwierdzeniem a rozpoczęciem księgowania może wskazywać na problemy z harmonogramem lub ograniczoną dostępność zasobów silnika księgującego.
Skąd pobrać
Zdarzenie można wywnioskować ze zmian statusu w tabeli GL_JE_BATCHES albo na podstawie czasu przesłania równoległego żądania księgowania powiązanego z partią zapisów.
Rejestrowanie
Ustal czas przesłania żądania uruchomienia programu księgowania księgi głównej dla danej partii zapisów.
Typ zdarzenia
inferred
|
|||
|
Sprawdzono zapis księgowy
|
Weryfikacja może odbywać się przed formalną akceptacją lub w jej ramach. Oznacza sprawdzenie zapisu przez współpracownika lub kierownika, który potwierdza jego poprawność i zgodność przed przekazaniem do osoby podejmującej ostateczną decyzję. | ||
|
Dlaczego to ważne
Wyodrębnienie tej czynności pozwala oddzielić czas wstępnej weryfikacji od czasu ostatecznej akceptacji. Może ujawnić ukryte wąskie gardła, jeśli nieformalna weryfikacja trwa długo.
Skąd pobrać
Może to być wyraźnie określony etap wieloetapowego workflow akceptacji, zapisany w tabelach historii workflow. Nieformalna weryfikacja nie jest rejestrowana. Można ją wywnioskować, jeśli przed ostateczną decyzją o akceptacji zapisano działanie konkretnego użytkownika.
Rejestrowanie
Przeanalizuj tabele historii workflow, aby znaleźć pośrednie etapy akceptacji lub weryfikacji przed nadaniem ostatecznego statusu 'Approved'.
Typ zdarzenia
inferred
|
|||
Instrukcje pobierania danych
Gotowi do rozpoczęcia?
Wykorzystaj ten szablon, aby przekształcić dane o księgowaniach z Oracle Fusion w użyteczne informacje i skrócić cykl Record to Report. Zacznij usprawniać operacje finansowe już dziś.
Usprawnij proces Record to Report: księgowanie już dziś
Skróć czas cyklu księgowania o 30% i usprawnij operacje finansowe.
Nie trzeba podawać danych karty kredytowej. Aktywuj okres próbny już teraz.