Szablon danych Record to Report: księgowanie

Oracle Fusion Financials
Szablon danych Record to Report: księgowanie

Szablon danych Record to Report: księgowanie

Ten szablon zawiera wskazówki dotyczące pobierania i porządkowania danych o księgowaniach z Oracle Fusion Financials. Opisuje najważniejsze atrybuty do zebrania i działania do śledzenia, aby zgromadzić informacje potrzebne do analizy procesu. Zawiera też praktyczne wskazówki, jak pobrać te dane bezpośrednio z systemu.
  • Zalecane atrybuty do zebrania
  • Najważniejsze działania do śledzenia
  • Wskazówki dotyczące pobierania danych z Oracle Fusion Financials
Pierwszy raz spotykają się Państwo z dziennikiem zdarzeń? Dowiedz się jak utworzyć dziennik zdarzeń na potrzeby process mining.

Atrybuty procesu Record to Report: księgowanie

Poniżej przedstawiono zalecane pola danych, które warto uwzględnić w dzienniku zdarzeń, aby kompleksowo analizować proces Record to Report: księgowanie.
5 Wymagane 6 Zalecane 10 Opcjonalne
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
Wymagane Zalecane Opcjonalne

Działania w procesie Record to Report: księgowanie

Poniżej przedstawiono najważniejsze kroki i punkty kontrolne, które warto rejestrować w dzienniku zdarzeń, aby prawidłowo odkrywać przebieg procesu księgowania.
5 Zalecane 7 Opcjonalne
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
Zalecane Opcjonalne

Instrukcje pobierania danych

Jak pobrać dane z Oracle Fusion Financials

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.

Rozpocznij bezpłatny okres próbny

Nie trzeba podawać danych karty kredytowej. Aktywuj okres próbny już teraz.