Szablon danych Record to Report, zapisy księgowe
Szablon danych Record to Report, zapisy księgowe
- Zalecane atrybuty do zebrania
- Najważniejsze działania do śledzenia
- Jak pobrać dane z Microsoft Dynamics 365
Atrybuty procesu Record to Report - Journal Entry
| Nazwa | Opis | ||
|---|---|---|---|
|
Czas zdarzenia
EventTime
|
Dokładny znacznik czasu wskazujący, kiedy wystąpiła dana czynność lub zdarzenie. | ||
|
Opis
Czas zdarzenia określa datę i godzinę wykonania danej czynności w procesie księgowania zapisów dziennika. Dane chronologiczne są niezbędne do uporządkowania zdarzeń i obliczenia czasu między nimi. Podczas analizy znaczniki czasu służą do tworzenia osi czasu dla każdej sprawy. Jest to niezbędne do obliczania wszystkich miar czasu, takich jak całkowity czas procesu, czas przetwarzania i czas oczekiwania. Pozwala wykrywać opóźnienia między etapami oraz zasilać dashboardy dotyczące wąskich gardeł i zgodności z SLA.
Dlaczego to ważne
Ten znacznik czasu pozwala prawidłowo uporządkować zdarzenia i obliczyć wszystkie KPI oparte na czasie, takie jak całkowity czas procesu i opóźnienia w przetwarzaniu.
Skąd pobrać
Znaczniki czasu zdarzeń znajdują się zazwyczaj w dziennikach historii workflow, tabelach ścieżki audytu, na przykład SysDatabaseLog, lub w polach czasu utworzenia i modyfikacji powiązanych rekordów, takich jak LedgerJournalTable i LedgerJournalTrans.
Przykłady
2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:45:10Z
|
|||
|
Identyfikator zapisu dziennika
JournalEntryId
|
Unikalny identyfikator zapisu dziennika, używany jako główny identyfikator sprawy. | ||
|
Opis
Identyfikator zapisu dziennika jednoznacznie łączy wszystkie czynności i dane dotyczące pojedynczej transakcji. Umożliwia śledzenie całego cyklu życia zapisu, od utworzenia i weryfikacji po ostateczne zaksięgowanie w księdze głównej. W analizie process mining ten atrybut jest podstawą odtworzenia przebiegu procesu. Każdy unikalny identyfikator zapisu dziennika odpowiada jednej instancji procesu, co pozwala szczegółowo analizować warianty procesu, czas jego trwania i zgodność dla poszczególnych transakcji finansowych.
Dlaczego to ważne
To podstawowy identyfikator, który pozwala śledzić zapis dziennika od początku do końca i analizować przebieg całego procesu dla każdej sprawy.
Skąd pobrać
Ten identyfikator znajduje się zazwyczaj w tabeli nagłówków zapisów dziennika, takiej jak LedgerJournalTable, często w polu o nazwie JournalNum.
Przykłady
JRN-0012345JV-2023-08-156GENJ0000891
|
|||
|
Nazwa czynności
ActivityName
|
Nazwa konkretnego etapu procesu biznesowego lub zdarzenia, które wystąpiło. | ||
|
Opis
Ten atrybut opisuje pojedyncze zdarzenie lub zadanie w cyklu życia zapisu dziennika, na przykład 'Journal Entry Created', 'Journal Submitted For Approval' lub 'Journal Entry Posted'. Czynności te tworzą węzły na mapie procesu. Analiza kolejności i częstotliwości tych czynności jest podstawą process mining. Pokazuje rzeczywisty przebieg procesu, pomaga wykryć odstępstwa od standardowej procedury i wskazuje wąskie gardła, w których czynności trwają dłużej, niż powinny, lub są powtarzane.
Dlaczego to ważne
Ten atrybut określa etapy procesu. Tworzą one podstawę mapy procesu i umożliwiają analizę jego przebiegu oraz wariantów.
Skąd pobrać
To atrybut pojęciowy wyprowadzany ze zdarzeń systemowych, zmian statusu lub dzienników workflow w Microsoft Dynamics 365.
Przykłady
Utworzono zapis dziennikaPrzekazano zapis dziennika do zatwierdzeniaZatwierdzono zapis dziennikaZaksięgowano zapis dziennika
|
|||
|
Czas zakończenia zdarzenia
EventEndTime
|
Znacznik czasu wskazujący, kiedy zakończono czynność lub zdarzenie. | ||
|
Opis
Czas zakończenia zdarzenia wskazuje moment ukończenia danej czynności. StartTime określa jej początek, a EndTime jej koniec, co pozwala dokładnie obliczyć czas trwania zadania. W process mining dostępność czasu rozpoczęcia i zakończenia pozwala obliczyć czas wykonywania czynności, odrębny od czasu oczekiwania. Jest to ważne w dashboardach analizujących wydajność użytkowników i wskazujących konkretne zadania, a nie tylko przerwy między nimi, które zajmują najwięcej czasu.
Dlaczego to ważne
Pozwala dokładnie obliczyć czas trwania każdej czynności, co jest niezbędne do analizy wydajności użytkowników i wykrywania zadań wymagających dużego nakładu zasobów.
Skąd pobrać
Te dane mogą być jawnie zapisane w dziennikach workflow albo wymagać wyliczenia na podstawie StartTime kolejnej czynności w sekwencji.
Przykłady
2023-10-26T10:05:15Z2023-10-26T11:45:00Z2023-10-27T15:00:00Z
|
|||
|
Jednostka prawna
LegalEntity
|
Jednostka prawna lub kod firmy, dla której rejestrowany jest zapis księgowy. | ||
|
Opis
Jednostka prawna oznacza konkretną firmę lub jednostkę biznesową, dla której rejestrowana jest transakcja finansowa. To podstawowy wymiar organizacyjny w systemach finansowych. W process mining ten atrybut pozwala porównywać przebieg procesu księgowania w różnych częściach organizacji. Może ujawnić, które jednostki prawne działają sprawniej, mają więcej odrzuceń lub dłuższy czas realizacji. Dzięki temu można wskazać i upowszechnić dobre praktyki.
Dlaczego to ważne
Pozwala porównywać wyniki procesu w różnych firmach lub jednostkach biznesowych oraz wskazywać różnice i możliwości usprawnień.
Skąd pobrać
To podstawowe pole w Dynamics 365. Jest często dostępne w tabelach transakcyjnych, takich jak LedgerJournalTable, i zwykle powiązane z DataAreaId.
Przykłady
USMFDEMFGBSI
|
|||
|
Łączna kwota zapisu księgowego
JournalTotalAmount
|
Łączna wartość pieniężna zapisu księgowego, zwykle suma obciążeń. | ||
|
Opis
Ten atrybut określa łączną wartość finansową zapisu księgowego. Można na jego podstawie podzielić zapisy na przedziały wartości, na przykład niskie, średnie i wysokie. Analiza procesu według wartości finansowej może ujawnić istotne zależności. Na przykład zapisy o wysokiej wartości mogą wymagać dokładniejszego zatwierdzania, większej liczby kroków i dłuższego czasu realizacji. Atrybut ten jest potrzebny do analizy istotności oraz oceny finansowych skutków nieefektywności procesu.
Dlaczego to ważne
Pozwala analizować proces według wartości finansowej, która często wiąże się ze złożonością procesu, ryzykiem i przebiegiem zatwierdzania.
Skąd pobrać
Wartość może wymagać obliczenia przez zsumowanie kwot obciążeń z tabeli pozycji dziennika LedgerJournalTrans dla każdego zapisu księgowego.
Przykłady
1500.75125000.0050.25
|
|||
|
Nazwa użytkownika
UserName
|
Nazwa użytkownika, który wykonał daną czynność. | ||
|
Opis
Ten atrybut wskazuje pracownika lub użytkownika systemu odpowiedzialnego za wykonanie konkretnej czynności, na przykład utworzenie, zatwierdzenie lub zaksięgowanie zapisu dziennika. Łączy etapy procesu z osobami, które je wykonują. Analiza wyników poszczególnych użytkowników to jedna z możliwości process mining. Pozwala przygotować dashboard „Wydajność użytkowników w procesie księgowania zapisów dziennika” i porównać czas wykonywania czynności oraz przepustowość różnych użytkowników lub zespołów. Może wskazać osoby osiągające najlepsze wyniki, potrzeby szkoleniowe i możliwości lepszego rozłożenia pracy.
Dlaczego to ważne
Łączy czynności w procesie z konkretnymi osobami, umożliwiając analizę wydajności użytkowników, rozkładu obciążenia pracą i przydziału zasobów.
Skąd pobrać
Informacje o użytkowniku znajdują się zazwyczaj w polach createdBy lub modifiedBy w tabelach takich jak LedgerJournalTable albo w powiązanych dziennikach historii workflow.
Przykłady
Anna KowalskaJan Nowaksystem.batch
|
|||
|
Powód odrzucenia
RejectionReason
|
Powód podany przy odrzuceniu zapisu księgowego w trakcie procesu zatwierdzania. | ||
|
Opis
Osoba zatwierdzająca często podaje powód odrzucenia zapisu księgowego. Ten atrybut przechowuje tę informację, która jest niezbędna do analizy przyczyn źródłowych. To główny atrybut dashboardu „Analiza odrzuceń zapisów księgowych”. Klasyfikacja i analiza powodów odrzucenia pozwala wykryć powtarzające się problemy, takie jak nieprawidłowa dokumentacja, naruszenie zasad lub błędy przy wprowadzaniu danych. Na tej podstawie można zaplanować szkolenia lub usprawnić proces.
Dlaczego to ważne
Wyjaśnia przyczyny ponownego przetwarzania i pomaga ograniczyć liczbę odrzuceń oraz zwiększyć odsetek zapisów zatwierdzanych za pierwszym razem.
Skąd pobrać
Informacje te są zwykle zapisane w historii workflow lub w komentarzach przy kroku odrzucenia.
Przykłady
Brak wystarczającej dokumentacji potwierdzającejUżyto niewłaściwego kontaPrzekroczono próg wymagający zatwierdzeniaZduplikowany zapis
|
|||
|
Status zapisu księgowego
JournalStatus
|
Bieżący lub końcowy status zapisu księgowego. | ||
|
Opis
Ten atrybut wskazuje stan zapisu księgowego w danym momencie, na przykład „Roboczy”, „W trakcie weryfikacji”, „Zatwierdzony”, „Odrzucony” lub „Zaksięgowany”. Pokazuje, na jakim etapie cyklu życia znajduje się zapis. Analiza statusu pomaga zrozumieć wyniki spraw. Można filtrować zapisy odrzucone lub śledzić ich liczbę na określonym etapie. Atrybut ten dostarcza kontekstu do analizy przepustowości i statusów na wielu dashboardach.
Dlaczego to ważne
Pokazuje wynik dla każdego zapisu księgowego, co pozwala analizować odsetek zatwierdzeń i odrzuceń oraz liczbę zapisów na poszczególnych etapach.
Skąd pobrać
Status znajduje się zwykle w tabeli nagłówków zapisów LedgerJournalTable lub wynika ze statusu workflow.
Przykłady
RoboczyPrzesłanyZatwierdzonyZaksięgowanyOdrzucony
|
|||
|
Typ zapisu dziennika
JournalType
|
Klasyfikacja zapisu dziennika, na przykład dziennik główny lub rozliczenie międzyokresowe. | ||
|
Opis
Typ zapisu dziennika określa jego cel biznesowy, na przykład księgowanie dzienne, rozliczenia międzyokresowe, alokacje lub eliminacje. Podział na typy jest niezbędny do analizy różnych przebiegów i zachowań procesu. Ten atrybut pozwala filtrować proces i porównywać jego przebieg dla różnych typów zapisów. Jest niezbędny w dashboardzie „Liczba zapisów dziennika według typu”, który pomaga sprawdzić, czy określone typy zapisów częściej powodują opóźnienia, odrzucenia lub poprawki.
Dlaczego to ważne
Pozwala podzielić analizę według celu biznesowego i porównać procesy, które mogą różnić się przebiegiem, czasem trwania i wymaganiami dotyczącymi zatwierdzania.
Skąd pobrać
Ten atrybut jest zazwyczaj przechowywany w tabeli nagłówków zapisów dziennika LedgerJournalTable, w polu dotyczącym nazw lub typów zapisów, na przykład JournalName.
Przykłady
Dziennik głównyKorekta rozliczeń międzyokresowychTransfer międzyfirmowyLista płac
|
|||
|
Czy księgowanie jest automatyczne
IsAutomatedPosting
|
Wskaźnik określający, czy zapis księgowy został utworzony lub zaksięgowany automatycznie. | ||
|
Opis
Ten atrybut logiczny odróżnia zapisy księgowe utworzone ręcznie przez użytkownika od zapisów wygenerowanych automatycznie przez system lub podsystem, na przykład integrację systemową albo automatyczny proces alokacji. Analiza tego atrybutu pozwala porównać efektywność i liczbę błędów w procesach automatycznych i ręcznych. Może wskazać możliwości dalszej automatyzacji, pokazując, czy przy ręcznym wprowadzaniu częściej występują błędy, ponowne przetwarzanie lub opóźnienia.
Dlaczego to ważne
Rozróżnia procesy ręczne i automatyczne, umożliwiając porównanie ich efektywności, dokładności i zgodności.
Skąd pobrać
Może to wskazywać pole „Utworzył” (na przykład użytkownik systemowy lub wsadowy) albo specjalny wskaźnik w nagłówku zapisu lub konfiguracji typu.
Przykłady
truefalse
|
|||
|
Czy ponowne przetwarzanie
IsRework
|
Wskaźnik oznaczający działania należące do pętli ponownego przetwarzania lub korekty. | ||
|
Opis
Ten obliczany atrybut logiczny przyjmuje wartość true dla działań wykonanych po odrzuceniu, takich jak „Skorygowano zapis księgowy” lub ponowne „Przesłano zapis do zatwierdzenia”. Ułatwia wyodrębnienie i zmierzenie skali ponownego przetwarzania. Atrybut ten jest potrzebny do dashboardu „Pętle ponownego przetwarzania i korekt zapisów księgowych” oraz KPI „Wskaźnik ponownego przetwarzania”. Oznaczenie takich działań ułatwia wizualizację i pomiar częstotliwości oraz wpływu cykli korekt, które są jednym z głównych źródeł nieefektywności procesu.
Dlaczego to ważne
Bezpośrednio oznacza nieefektywne pętle ponownego przetwarzania, ułatwiając pomiar wpływu odrzuceń i korekt na łączny czas realizacji i koszty.
Skąd pobrać
To obliczany atrybut, wyznaczany podczas transformacji danych na podstawie sekwencji działań w ramach sprawy.
Przykłady
truefalse
|
|||
|
Czy zatwierdzono za pierwszym razem
IsFirstTimeRight
|
Wskaźnik określający, czy zapis księgowy zatwierdzono bez wcześniejszych odrzuceń. | ||
|
Opis
Ten atrybut logiczny na poziomie sprawy przyjmuje wartość true, jeśli zapis księgowy przechodzi od przesłania do zatwierdzenia bez działań „Odrzucono zapis księgowy” ani „Skorygowano zapis księgowy”. To ważna miara jakości procesu. KPI „Odsetek zatwierdzeń za pierwszym razem” jest obliczany bezpośrednio na podstawie tego atrybutu. Wysoki wynik oznacza sprawny proces o dobrej jakości. Niski może wskazywać na problemy systemowe z jakością danych, jasnością wymagań lub sposobem przesyłania zapisów.
Dlaczego to ważne
To ważna miara jakości procesu. Pokazuje, ile zapisów przechodzi przez zatwierdzanie bez ponownego przetwarzania.
Skąd pobrać
To obliczany atrybut na poziomie sprawy, wyznaczany przez analizę sekwencji działań dla każdego identyfikatora zapisu księgowego.
Przykłady
truefalse
|
|||
|
Data księgowania
PostingDate
|
Data zaksięgowania zapisu w księdze głównej. | ||
|
Opis
Data księgowania to oficjalna data, w której transakcja wpływa na salda księgi głównej. Ma zasadnicze znaczenie dla sprawozdawczości finansowej i zamknięcia okresów. Atrybut ten służy do analizy czasu od zatwierdzenia do zaksięgowania. Jest to podstawa KPI „Czas od zatwierdzenia zapisu do zaksięgowania”. Skrócenie tego czasu często pomaga przyspieszyć zamknięcie finansowe. Atrybut można też wykorzystać do analizy liczby księgowań w czasie.
Dlaczego to ważne
Niezbędna do obliczenia KPI dotyczącego czasu księgowania i analizy opóźnień między zatwierdzeniem a oficjalnym ujęciem transakcji w księdze.
Skąd pobrać
Data ta jest zwykle zapisana w tabeli nagłówków zapisów LedgerJournalTable lub w powiązanych tabelach zaksięgowanych transakcji.
Przykłady
2023-10-282023-11-012023-10-31
|
|||
|
Data ostatniej aktualizacji danych
LastDataUpdate
|
Znacznik czasu ostatniego odświeżenia danych z systemu źródłowego. | ||
|
Opis
Ten atrybut wskazuje datę i godzinę ostatniego wyodrębnienia danych z systemu źródłowego. Informuje, jak aktualne są dane uwzględnione w analizie. Wyświetlenie tej informacji na dashboardach pozwala użytkownikom ocenić aktualność danych i ustalić, jaki okres obejmuje bieżąca analiza procesu. To ważne metadane w każdym projekcie process mining.
Dlaczego to ważne
Informuje o aktualności danych, dzięki czemu użytkownicy wiedzą, jak bieżąca jest analiza procesu.
Skąd pobrać
Ten znacznik czasu jest generowany i zapisywany podczas procesu wyodrębniania, przekształcania i ładowania danych (ETL).
Przykłady
2023-10-27T02:00:00Z
|
|||
|
Dział
DepartmentName
|
Dział lub centrum kosztów powiązane z zapisem księgowym. | ||
|
Opis
Dział lub centrum kosztów wskazuje wewnętrzną jednostkę biznesową odpowiedzialną za transakcję finansową lub na nią wpływającą. To ważny wymiar raportowania zarządczego. Ten atrybut pozwala analizować proces księgowania według działów. Pomaga odpowiedzieć na pytania: które działy przesyłają najwięcej zapisów? Czy w niektórych działach częściej dochodzi do odrzuceń lub dłużej trwa zatwierdzanie? Informacje te można wykorzystać do ukierunkowanych usprawnień procesu.
Dlaczego to ważne
Pozwala analizować wyniki procesu według funkcji biznesowej i wskazywać wąskie gardła lub potrzeby szkoleniowe w poszczególnych działach.
Skąd pobrać
Informacje te znajdują się zwykle na poziomie pozycji dziennika (LedgerJournalTrans) jako wymiar finansowy.
Przykłady
SprzedażFinanseMarketingOperacje
|
|||
|
Kod waluty
CurrencyCode
|
Waluta kwoty zapisu księgowego. | ||
|
Opis
Ten atrybut określa walutę zapisu księgowego, na przykład USD, EUR lub GBP. Dostarcza niezbędnego kontekstu dla łącznej kwoty zapisu księgowego. Waluta nie zawsze służy do analizy samego przebiegu procesu, ale ma zasadnicze znaczenie w raportowaniu i analizie finansowej opartej na kwotach zapisów. Umożliwia prawidłowe sumowanie i porównywanie wartości, zwłaszcza w organizacjach międzynarodowych.
Dlaczego to ważne
Zapewnia kontekst potrzebny do analizy finansowej i ułatwia prawidłową interpretację kwot, szczególnie przy wielu walutach.
Skąd pobrać
Kod waluty jest zwykle dostępny w tabeli pozycji dziennika LedgerJournalTrans.
Przykłady
USDEURGBPJPY
|
|||
|
Poziom zatwierdzania
ApprovalLevel
|
Wskazuje bieżący lub zakończony etap wielopoziomowego workflow zatwierdzania. | ||
|
Opis
W przypadku zapisów księgowych wymagających kilku zatwierdzeń ten atrybut wskazuje, na którym poziomie hierarchii znajduje się zapis, na przykład „Zatwierdzenie przez kierownika” lub „Zatwierdzenie przez dyrektora”. Atrybut ten pomaga dokładniej analizować wąskie gardła w procesie zatwierdzania. Pozwala ustalić, czy opóźnienia regularnie występują na określonym poziomie, co może wskazywać na potrzebę zmiany procesu lub przesunięcia zasobów.
Dlaczego to ważne
Pokazuje przebieg wieloetapowego workflow zatwierdzania i pomaga wykrywać wąskie gardła na poszczególnych poziomach.
Skąd pobrać
Informacje te można uzyskać z dziennika historii workflow, śledząc zakończenie poszczególnych etapów zatwierdzania.
Przykłady
Poziom 1: kierownikPoziom 2: dyrektorPoziom 3: wiceprezes ds. finansów
|
|||
|
Status SLA zatwierdzania
ApprovalSlaState
|
Wskazuje, czy zatwierdzenie zapisu księgowego spełniło warunki umowy SLA. | ||
|
Opis
Ten atrybut klasyfikuje cykl zatwierdzania każdego zapisu księgowego w zależności od tego, czy zakończył się w czasie określonym w umowie SLA. Typowe wartości to „Dotrzymano” i „Przekroczono”. To główny wskaźnik dashboardu „Zgodność z SLA zatwierdzania zapisów księgowych”. Pokazuje w czytelny dla biznesu sposób, jak wyniki mają się do założeń. Ułatwia monitorowanie terminowości zatwierdzania i wskazuje obszary wymagające poprawy, gdy SLA jest często przekraczane.
Dlaczego to ważne
Przekłada surowe dane o czasie realizacji na czytelny wynik biznesowy („dotrzymano” lub „przekroczono”), ułatwiając monitorowanie realizacji założeń.
Skąd pobrać
To obliczany atrybut. Wymaga porównania obliczonego KPI czasu zatwierdzania z wcześniej określonym celem SLA.
Przykłady
DotrzymanoPrzekroczono
|
|||
|
System źródłowy
SourceSystem
|
System, z którego wyodrębniono dane. | ||
|
Opis
Ten atrybut wskazuje aplikację źródłową, z której pochodzą dane o zapisach dziennika. W tym procesie jego wartością jest zazwyczaj stała, na przykład 'Microsoft Dynamics 365'. W szerszej analizie, zwłaszcza w środowiskach z wieloma systemami ERP lub systemami zintegrowanymi, to pole pomaga rozróżniać procesy i źródła danych. Ułatwia ustalenie pochodzenia danych i wspiera zarządzanie nimi oraz ich weryfikację.
Dlaczego to ważne
Wskazuje pochodzenie danych, co ma znaczenie dla zarządzania nimi oraz analiz obejmujących wiele systemów przedsiębiorstwa.
Skąd pobrać
To stała wartość dodawana podczas procesu wyodrębniania, przekształcania i ładowania danych (ETL), która oznacza źródło zbioru danych.
Przykłady
Microsoft Dynamics 365D365 F&O
|
|||
Działania w procesie Record to Report - Journal Entry
| Działanie | Opis | ||
|---|---|---|---|
|
Odrzucono zapis dziennika
|
Osoba weryfikująca lub zatwierdzająca odrzuciła zapis dziennika, który wymaga poprawy. Zdarzenie jest rejestrowane jako zmiana statusu zapisu, na przykład na 'Rejected' lub 'Needs Correction'. | ||
|
Dlaczego to ważne
Śledzenie odrzuceń jest niezbędne do obliczania ich odsetka i ustalania przyczyn poprawek. Pozwala wykryć problemy z jakością danych, zgodnością lub szkoleniem użytkowników.
Skąd pobrać
Zdarzenie można wywnioskować ze zmiany pola statusu, na przykład ApprovalStatus na 'Rejected', w tabeli LedgerJournalTable albo z dziennika historii workflow.
Rejestrowanie
Ustal znacznik czasu, w którym status zapisu zmienia się na 'Rejected'.
Typ zdarzenia
inferred
|
|||
|
Przekazano zapis dziennika do zatwierdzenia
|
Oznacza formalne przekazanie kompletnego zapisu dziennika do workflow weryfikacji i zatwierdzania. Zdarzenie zazwyczaj można wywnioskować ze zmiany statusu nagłówka, na przykład z 'Draft' na 'In Review' lub 'Submitted'. | ||
|
Dlaczego to ważne
To ważny etap, który rozpoczyna cykl zatwierdzania. Pomiar czasu od przekazania do ostatecznego zatwierdzenia pomaga wykrywać wąskie gardła w procesie weryfikacji i monitorować zgodność z SLA.
Skąd pobrać
Zdarzenie można wywnioskować ze zmiany pola statusu, na przykład ApprovalStatus na 'InReview', w tabeli LedgerJournalTable albo z historii workflow powiązanej z zapisem.
Rejestrowanie
Ustal znacznik czasu, w którym status zapisu zmienia się na 'submitted' lub 'in review'.
Typ zdarzenia
inferred
|
|||
|
Utworzono zapis dziennika
|
To zdarzenie oznacza rozpoczęcie pracy nad nowym zapisem dziennika. Jest rejestrowane, gdy użytkownik tworzy w systemie nowy nagłówek zapisu. Powstaje wtedy unikalny identyfikator zapisu dziennika, który służy jako identyfikator sprawy w analizie procesu. | ||
|
Dlaczego to ważne
To główne zdarzenie rozpoczynające proces. Pomiar czasu od tego momentu do zaksięgowania pozwala obliczyć czas całego procesu i wykryć opóźnienia na etapie wprowadzania danych.
Skąd pobrać
Zdarzenie jest rejestrowane na podstawie znacznika czasu utworzenia nagłówka zapisu w encji GeneralJournalEntry lub LedgerJournalTable. Zazwyczaj odpowiada jawnemu zdarzeniu utworzenia rekordu.
Rejestrowanie
Użyj pola 'createdDateTime' w tabeli GeneralJournalEntry lub LedgerJournalTable.
Typ zdarzenia
explicit
|
|||
|
Zaksięgowano zapis dziennika
|
To zdarzenie oznacza pomyślne zaksięgowanie zapisu dziennika w księdze głównej, dzięki czemu staje się on oficjalnym zapisem finansowym. Jest rejestrowane, gdy status nagłówka zmienia się na 'Posted'. | ||
|
Dlaczego to ważne
To główne zdarzenie kończące proces powodzeniem. Służy do obliczenia całkowitego czasu procesu i czasu od zatwierdzenia do zaksięgowania, które wskazują sprawność zamknięcia finansowego.
Skąd pobrać
Zdarzenie jest rejestrowane na podstawie zmiany pola statusu, na przykład JournalStatus na 'Posted', w tabeli LedgerJournalTable oraz utworzenia odpowiadających mu wpisów w tabeli GeneralJournalAccountEntry.
Rejestrowanie
Ustal znacznik czasu, w którym status zapisu zmienia się na 'Posted'.
Typ zdarzenia
inferred
|
|||
|
Zatwierdzono zapis dziennika
|
Upoważniona osoba zatwierdziła zapis dziennika, kończąc ostatni etap workflow zatwierdzania. Zdarzenie zazwyczaj jest rejestrowane jako zmiana statusu nagłówka zapisu na 'Approved'. | ||
|
Dlaczego to ważne
To ważny etap, który kończy proces zatwierdzania i umożliwia zaksięgowanie zapisu. Jest niezbędny do obliczenia czasu zatwierdzania, czasu od zatwierdzenia do zaksięgowania oraz wskaźnika poprawności za pierwszym razem.
Skąd pobrać
Zdarzenie można wywnioskować ze zmiany pola statusu, na przykład ApprovalStatus na 'Approved', w tabeli LedgerJournalTable albo z rekordu w tabeli historii workflow wskazującego ostateczne zatwierdzenie.
Rejestrowanie
Ustal znacznik czasu, w którym status zapisu zmienia się na 'Approved'.
Typ zdarzenia
inferred
|
|||
|
Dodano pozycję dziennika
|
To zdarzenie oznacza dodanie pozycji debetowej lub kredytowej do zapisu dziennika. Jest rejestrowane za każdym razem, gdy powstaje nowa pozycja transakcji powiązana z nagłówkiem zapisu. | ||
|
Dlaczego to ważne
Śledzenie tworzenia pozycji pozwala ocenić złożoność i nakład pracy związany z wprowadzaniem danych dla różnych typów zapisów. Może też ujawnić opóźnienia między utworzeniem nagłówka a uzupełnieniem pozycji.
Skąd pobrać
Zdarzenie jest rejestrowane na podstawie znacznika czasu utworzenia rekordu w encji LedgerJournalTrans, powiązanego z nagłówkiem zapisu. Utworzenie każdej pozycji jest osobnym zdarzeniem.
Rejestrowanie
Użyj pola 'createdDateTime' dla każdego rekordu w tabeli LedgerJournalTrans.
Typ zdarzenia
explicit
|
|||
|
Odwrócono zapis dziennika
|
Oznacza zakończenie procesu odwracania zapisu dziennika, gdy zapis odwracający zostaje pomyślnie zaksięgowany. Jest to alternatywny punkt końcowy cyklu życia błędnego zapisu. | ||
|
Dlaczego to ważne
To zdarzenie zamyka proces korekty i pomaga ocenić łączny nakład pracy związany z korektami po zaksięgowaniu, które wpływają na sprawność całego procesu.
Skąd pobrać
Zdarzenie jest rejestrowane, gdy nowy zapis odwracający otrzymuje status 'Posted'. Powiązanie z oryginalnym zapisem jest przechowywane w polu referencyjnym.
Rejestrowanie
Wykryj zdarzenie statusu 'Posted' dla powiązanego zapisu odwracającego.
Typ zdarzenia
inferred
|
|||
|
Podjęto próbę zaksięgowania zapisu dziennika
|
To zdarzenie oznacza, że użytkownik rozpoczął księgowanie zatwierdzonego zapisu dziennika. Może być rejestrowane wprost, jeśli system zapisuje rozpoczęcie zadania księgowania. | ||
|
Dlaczego to ważne
Rozróżnienie próby księgowania od pomyślnego zaksięgowania pomaga diagnozować problemy z wydajnością systemu lub opóźnienia zadań wsadowych, które wpływają na zamknięcie finansowe.
Skąd pobrać
Zdarzenie może być jawnie zapisane w tabeli historii zadań wsadowych albo wywnioskowane ze zmiany statusu w tabeli LedgerJournalTable na 'Posting in progress'.
Rejestrowanie
Wymaga analizy dzienników zadań wsadowych lub dzienników systemowych związanych z procedurą księgowania w księdze głównej.
Typ zdarzenia
explicit
|
|||
|
Ponownie przekazano zapis dziennika do zatwierdzenia
|
Poprawiony zapis dziennika wraca do workflow zatwierdzania, aby rozpocząć nowy cykl weryfikacji. Zdarzenie można wywnioskować ze zmiany statusu z 'Rejected' lub 'Draft' na 'In Review' lub 'Submitted'. | ||
|
Dlaczego to ważne
To zdarzenie rozpoczyna cykl poprawek. Zliczenie takich zdarzeń pozwala określić odsetek zapisów wymagających poprawek i średnią liczbę cykli zatwierdzania dla jednego zapisu.
Skąd pobrać
Zdarzenie można wywnioskować z historii workflow lub śledząc zmiany statusu w tabeli LedgerJournalTable, gdy status zmienia się z odrzuconego na zgłoszony.
Rejestrowanie
Wykryj zdarzenie statusu 'Submitted', które występuje po zdarzeniu statusu 'Rejected' dla tego samego zapisu dziennika.
Typ zdarzenia
inferred
|
|||
|
Poprawiono zapis dziennika
|
To zdarzenie oznacza, że użytkownik zmodyfikował wcześniej odrzucony zapis dziennika. Zazwyczaj można je wykryć, sprawdzając, czy po zarejestrowaniu statusu 'Rejected' zmodyfikowano nagłówek zapisu lub jego pozycje. | ||
|
Dlaczego to ważne
To zdarzenie wskazuje na konieczność ponownej pracy. Analiza częstotliwości i czasu trwania cykli poprawek pomaga usprawnić proces i ograniczyć ręczną pracę.
Skąd pobrać
Zdarzenie można wywnioskować, śledząc pola 'modifiedDateTime' i 'modifiedBy' w tabelach LedgerJournalTable lub LedgerJournalTrans po wystąpieniu zdarzenia 'Journal Rejected'.
Rejestrowanie
Porównaj znacznik czasu zmiany statusu na 'Rejected' z późniejszymi znacznikami czasu modyfikacji dokonanych przez osobę tworzącą zapis.
Typ zdarzenia
inferred
|
|||
|
Rozpoczęto odwracanie zapisu dziennika
|
To zdarzenie oznacza rozpoczęcie procesu odwracania wcześniej zaksięgowanego zapisu dziennika. Jest rejestrowane, gdy użytkownik rozpoczyna odwracanie w systemie. | ||
|
Dlaczego to ważne
Śledzenie odwróceń pozwala ustalić, jak często i z jakich powodów korygowane są zaksięgowane zapisy. Może to wskazać problemy na wcześniejszych etapach wprowadzania danych lub zatwierdzania.
Skąd pobrać
Zazwyczaj jest to jawne działanie użytkownika, które można wykryć w ścieżce audytu lub na podstawie utworzenia nowego zapisu odwracającego, powiązanego z oryginalnym.
Rejestrowanie
Użyj zdarzenia utworzenia nowego zapisu dziennika oznaczonego jako odwrócenie zaksięgowanego zapisu.
Typ zdarzenia
explicit
|
|||
|
Rozpoczęto weryfikację zapisu dziennika
|
To zdarzenie oznacza moment, w którym osoba weryfikująca rozpoczyna pracę nad przekazanym zapisem dziennika. Można je wywnioskować z przypisania zapisu do weryfikującego lub z pierwszego otwarcia rekordu w celu jego sprawdzenia. | ||
|
Dlaczego to ważne
To zdarzenie pozwala zmierzyć czas przekazania do weryfikacji, czyli opóźnienie między zgłoszeniem a rozpoczęciem sprawdzania. Może ujawnić problemy z przydziałem zasobów lub powiadomieniami.
Skąd pobrać
To zdarzenie często nie jest rejestrowane wprost. Można je wywnioskować z dzienników przypisań workflow albo porównać znacznik czasu zgłoszenia z czasem pierwszej modyfikacji dokonanej przez użytkownika weryfikującego.
Rejestrowanie
Wymaga analizy dzienników przypisań użytkowników w workflow lub dzienników aktywności użytkowników, które mogą nie być dostępne standardowo.
Typ zdarzenia
inferred
|
|||
Instrukcje pobierania danych
Jak zacząć?
Ten szablon zawiera informacje potrzebne do rozpoczęcia usprawniania procesu Record to Report - Journal Entry. Wykorzystajcie Państwo dane, aby zwiększyć efektywność i skrócić cykl sprawozdawczości finansowej.
Usprawnij Journal Entry w Dynamics 365 i szybciej przygotowuj raporty
Usuń wąskie gardła i skróć cykl R2R Journal Entry o 30%.
Karta kredytowa nie jest potrzebna. Rozpoczęcie zajmuje kilka minut.