> Ciągłe doskonalenie procesów > Record to Report: księgowanie zapisów dziennika > BlackLine > Szablon danych

Szablon danych dla procesu Record to Report, zapisy księgowe

BlackLine

← Wróć do przewodnika ulepszania procesów

Atrybuty procesu Record to Report, zapisy księgowe(19) Czynności w procesie Record to Report, zapisy księgowe(12) Instrukcje ekstrakcji danych(2)

Szablon danych dla procesu Record to Report, zapisy księgowe

Ten szablon zawiera wskazówki dotyczące gromadzenia danych potrzebnych do analizy procesu Record to Report, zapisy księgowe. Opisuje najważniejsze atrybuty, czynności do śledzenia oraz praktyczny sposób pobierania tych informacji z BlackLine. Dzięki niemu można przygotować dane potrzebne do skutecznego process mining.

Zalecane atrybuty do zebrania
Najważniejsze czynności do śledzenia
Wskazówki dotyczące ekstrakcji danych

Pierwszy raz spotykają się Państwo z dziennikiem zdarzeń? Dowiedz się jak utworzyć dziennik zdarzeń na potrzeby process mining.

Pobierz szablon

Atrybuty procesu Record to Report, zapisy księgowe

Poniżej przedstawiono zalecane pola danych, które warto uwzględnić w dzienniku zdarzeń, aby dokładnie analizować proces Record to Report, zapisy księgowe.

5 Wymagane 6 Zalecane 8 Opcjonalne

	Nazwa	Opis
	Czas rozpoczęcia EventTime	Dokładny znacznik czasu wskazujący, kiedy wystąpiła dana czynność lub zdarzenie.
Opis Czas zdarzenia określa datę i godzinę wystąpienia zdarzenia biznesowego. Wyznacza chronologię procesu, czyli kolejność i czas trwania wszystkich czynności. Ten znacznik czasu jest niezbędny w analizach process mining opartych na czasie. Służy do obliczania czasów cyklu, oczekiwania i trwania poszczególnych czynności. Ułatwia wykrywanie wąskich gardeł, analizę wyników w czasie i ocenę zgodności z umowami SLA. Dlaczego to ważne Ten znacznik czasu stanowi podstawę wszystkich wskaźników efektywności, w tym czasu cyklu i analizy wąskich gardeł. Pozwala odtworzyć chronologiczny przebieg procesu. Skąd pobrać Informacje te są zapisane w polach znaczników czasu w dziennikach zdarzeń lub rejestrach transakcji w BlackLine. Przykłady 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:05:00Z
	Czynność ActivityName	Nazwa konkretnego zdarzenia biznesowego, które wystąpiło w danym momencie procesu obsługi zapisu księgowego.
Opis Ten atrybut opisuje pojedynczy etap lub zadanie w cyklu życia zapisu księgowego, na przykład „Journal Entry Created”, „Journal Entry Approved” lub „Journal Entry Posted”. Każda czynność odpowiada odrębnemu zdarzeniu w procesie. Analiza kolejności czynności pozwala zobrazować i zrozumieć przebieg procesu. Jest niezbędna do wykrywania różnic w przebiegu, mierzenia czasu między etapami i identyfikowania pętli poprawek, na przykład gdy zapis księgowy zostaje odrzucony i przesłany ponownie. Dlaczego to ważne Określa etapy procesu, co pozwala przedstawić mapę procesu, analizować jego przebieg oraz wykrywać odstępstwa i wąskie gardła. Skąd pobrać Zwykle dane pochodzą z dzienników zdarzeń, rejestrów zmian statusu lub ścieżek audytu w BlackLine. Może być konieczne przypisanie kodów statusu systemowego do zrozumiałych nazw czynności. Przykłady Utworzono zapis księgowyPrzekazano zapis księgowyZatwierdzenie zapisu księgowegoZaksięgowanie zapisu księgowego
	Identyfikator zapisu księgowego JournalEntryId	Unikatowy identyfikator pojedynczego zapisu księgowego, używany jako główny identyfikator sprawy do śledzenia jego cyklu życia.
Opis Identyfikator zapisu księgowego jednoznacznie wskazuje każdy zestaw transakcji finansowych ujętych w księdze głównej. Jest głównym kluczem łączącym powiązane działania, takie jak utworzenie, weryfikacja, zatwierdzenie i zaksięgowanie. W process mining ten identyfikator jest niezbędny do powiązania wszystkich zdarzeń dotyczących pojedynczego zapisu księgowego. Analiza przebiegu procesu na podstawie tego identyfikatora pozwala odtworzyć całą ścieżkę, od rozpoczęcia do końcowego uzgodnienia, oraz szczegółowo analizować czasy cyklu, wąskie gardła i różnice w przebiegu procesu. Dlaczego to ważne To podstawowy identyfikator sprawy, który pozwala prześledzić cały cykl życia pojedynczego zapisu księgowego i analizować jego przebieg. Skąd pobrać To klucz główny w tabelach zapisów księgowych BlackLine lub eksportowanych danych. Dokładną nazwę pola można znaleźć w dokumentacji BlackLine. Przykłady JE2024-001234JE2024-001235JE2024-001236
	Ostatnia aktualizacja danych LastDataUpdate	Znacznik czasu wskazujący, kiedy ostatnio odświeżono dane lub pobrano je z systemu źródłowego.
Opis Ten atrybut określa datę i godzinę ostatniego pobrania danych. Informuje, jak aktualne są analizowane dane. To ważne metadane każdego dashboardu lub analizy process mining. Pokazują, na ile aktualne są wyniki, i pozwalają ocenić, czy widok obejmuje najnowsze transakcje. Dlaczego to ważne Informacja ta zapewnia przejrzystość co do aktualności danych i pozwala ocenić, jak aktualna jest analiza procesu. Skąd pobrać Narzędzie do pobierania danych lub proces ETL generuje ten znacznik czasu i dodaje go do zbioru danych podczas uruchomienia. Przykłady 2023-11-01T02:00:00Z2023-11-02T02:00:00Z
	System źródłowy SourceSystem	System ewidencyjny, z którego pobrano dane dotyczące zapisu księgowego.
Opis Ten atrybut wskazuje system źródłowy danych o zdarzeniach. W tym przypadku będzie to zwykle „BlackLine”, ale mogą się tu znaleźć również dane z nadrzędnego systemu ERP, jeśli proces rozpoczyna się w tym systemie. Identyfikacja systemu źródłowego jest ważna dla zarządzania danymi i zrozumienia kontekstu procesu, zwłaszcza gdy łączone są dane z wielu systemów. Pomaga rozwiązywać problemy z pobieraniem danych i weryfikować ich pochodzenie. Dlaczego to ważne Informacja ta wskazuje pochodzenie danych, zapewnia ich identyfikowalność i ułatwia zarządzanie integracją danych z różnych platform. Skąd pobrać Zwykle jest to stała wartość dodawana podczas pobierania i przekształcania danych, aby oznaczyć źródło zbioru danych. Przykłady BlackLineSAP S/4HANAOracle NetSuite
	Kod jednostki gospodarczej CompanyCode	Unikatowy identyfikator podmiotu prawnego lub spółki, dla której sporządzany jest zapis księgowy.
Opis Kod jednostki gospodarczej oznacza konkretny podmiot prawny w ramach grupy kapitałowej. To podstawowa jednostka organizacyjna w rachunkowości finansowej, która zapewnia przypisanie transakcji do właściwego podmiotu. W process mining kod jednostki gospodarczej jest przydatnym wymiarem filtrowania i porównań. Pozwala analizować przebieg procesu w różnych podmiotach, wykrywać regionalne lub jednostkowe wąskie gardła, różnice w zgodności oraz możliwości ujednolicenia procesów w całej organizacji. Wspiera bezpośrednio dashboard „Approval To Posting Delay Analysis”. Dlaczego to ważne Umożliwia porównywanie wyników i ujednolicanie procesów w różnych podmiotach prawnych lub jednostkach biznesowych. Skąd pobrać To ważne pole w nagłówku zapisu księgowego w BlackLine, często synchronizowane z bazowym systemem ERP. Przykłady 1000US01DE012500
	Kwota zapisu księgowego JournalEntryAmount	Łączna wartość pieniężna zapisu księgowego, zwykle suma obciążeń.
Opis Ten atrybut określa wartość finansową zapisu księgowego. Pozwala ocenić finansowe skutki nieefektywności procesu, na przykład opóźnień w księgowaniu zapisów o wysokiej wartości. Analiza procesu według wartości zapisu pozwala uwzględnić istotność kwot. Można na przykład w pierwszej kolejności usprawniać obsługę zapisów o wysokiej wartości, sprawdzić, czy przechodzą inną ścieżkę zatwierdzania, lub ustalić, czy ich czas cyklu jest dłuższy. Dzięki temu przebieg procesu zyskuje kontekst biznesowy. Dlaczego to ważne Zapewnia kontekst finansowy i pozwala uwzględnić istotność kwot, na przykład nadać priorytet zapisom o wysokiej wartości lub wykrywać odstępstwa w procesie zależne od wartości. Skąd pobrać To pole obliczane lub standardowe w nagłówku zapisu księgowego w BlackLine, określające łączną kwotę obciążeń lub uznań. Przykłady 15000.00250.75125000.50500.00
	Powód odrzucenia RejectionReason	Powód podany przez osobę weryfikującą po odrzuceniu zapisu księgowego.
Opis Gdy zapis księgowy zostaje odesłany do poprawy, osoba zatwierdzająca zwykle podaje powód odrzucenia. Ten atrybut przechowuje tę informację w postaci kodu lub tekstu. To ważny atrybut w analizie przyczyn poprawek. Analiza najczęstszych powodów odrzucenia pozwala wykryć problemy systemowe, takie jak niewystarczające przeszkolenie, niejasne zasady lub braki w dokumentach potwierdzających. Atrybut ten bezpośrednio wspiera dashboard „Journal Entry Rejection & Rework Analysis” i pomaga ograniczyć odsetek odrzuceń. Dlaczego to ważne Jest niezbędny do analizy przyczyn poprawek w procesie. Pomaga ustalić, dlaczego zapisy księgowe są odrzucane, i zaplanować ukierunkowane usprawnienia. Skąd pobrać Dane te są zwykle zapisywane w polu komentarza lub kodu przyczyny, gdy użytkownik wybiera w BlackLine działanie „Reject”. Przykłady Nieprawidłowy kod kontaBrak dokumentów potwierdzającychPrzekroczono limitZduplikowany zapis
	Status zapisu księgowego JournalEntryStatus	Bieżący status zapisu księgowego w jego cyklu życia, na przykład „In Progress”, „Approved” lub „Posted”.
Opis Ten atrybut wskazuje bieżący stan sprawy dotyczącej zapisu księgowego w chwili pobrania danych. Pokazuje, na jakim etapie całego procesu znajduje się zapis. Process mining odtwarza przebieg na podstawie czynności, ale końcowy status przydaje się do filtrowania i tworzenia dashboardów podsumowujących. Ułatwia szybkie wskazanie zapisów oczekujących na zatwierdzenie lub zatrzymanych na określonym etapie, co pomaga analizować zaległości. Dlaczego to ważne Pokazuje bieżący stan zapisów, co pomaga analizować zaległości i pracę w toku. Skąd pobrać To standardowe pole statusu zapisu księgowego w BlackLine. Przykłady W tokuOczekuje na zatwierdzenieZatwierdzonoZaksięgowanoOdrzucono
	Typ zapisu księgowego JournalEntryType	Klasyfikacja zapisu księgowego, na przykład standardowy, cykliczny lub odwracający.
Opis Typ zapisu księgowego określa jego charakter lub przeznaczenie. Typowe kategorie to standardowe zapisy ręczne, zapisy generowane automatycznie przez system, zapisy cykliczne dotyczące rozliczeń na koniec miesiąca oraz zapisy odwracające, które są automatycznie odwracane w kolejnym okresie. Ten atrybut umożliwia podział danych i porównania. Pozwala porównywać przebieg procesu, na przykład czasy cyklu lub odsetek odrzuceń, dla różnych typów zapisów. Dzięki temu można ustalić, które typy zapisów sprawiają więcej problemów lub są obsługiwane mniej efektywnie, a następnie odpowiednio usprawnić proces. Dlaczego to ważne Pozwala analizować poszczególne grupy zapisów i sprawdzić, czy różne typy zapisów księgowych przebiegają innymi ścieżkami lub mają odmienne wyniki. Skąd pobrać To standardowe pole w nagłówku zapisu księgowego w BlackLine. Dokładną nazwę pola można znaleźć w dokumentacji BlackLine. Przykłady StandardowyCyklicznyOdwracającyRozliczenie międzyokresowe
	Użytkownik UserName	Imię i nazwisko lub identyfikator użytkownika, który wykonał daną czynność.
Opis Ten atrybut wskazuje osobę odpowiedzialną za wykonanie danego etapu procesu, na przykład osobę, która przesłała, zweryfikowała lub zatwierdziła zapis księgowy. Może to być imię i nazwisko albo unikatowy identyfikator użytkownika. Analiza czynności według użytkownika pomaga zrozumieć rozkład obciążenia pracą i wyniki poszczególnych osób oraz wskazać potrzeby szkoleniowe. Pozwala odpowiedzieć na pytania: „Czy praca jest równomiernie rozdzielona w zespole?” lub „Którzy użytkownicy najdłużej zatwierdzają zapisy?”. Jest też ważna przy analizie zgodności i ścieżki audytu. Dlaczego to ważne Umożliwia analizę obciążenia pracą i porównanie wyników członków zespołu, a także pomaga wykrywać wąskie gardła związane z zasobami i określać potrzeby szkoleniowe. Skąd pobrać Informacje te są dostępne w dziennikach audytu BlackLine, często w polach „User ID” lub „Changed By” przypisanych do poszczególnych zdarzeń. Przykłady j.doea.smithr.joness.patel
	Czy wymagał poprawek IsRework	Obliczana flaga przyjmująca wartość prawda, jeśli zapis księgowy został odrzucony co najmniej raz.
Opis Ta flaga logiczna wskazuje zapisy księgowe, które wymagały poprawek. Zwykle przyjmuje wartość prawda, jeśli sprawa obejmuje czynność „Journal Entry Rejected”, po której następuje „Corrected and Resubmitted”. Atrybut ten ułatwia analizę poprawek, ponieważ pozwala szybko filtrować wszystkie sprawy, w których wystąpiło odrzucenie. Jest niezbędny do obliczania KPI „Journal Entry Rejection Rate” oraz szczegółowej analizy kosztów i wpływu problemów z jakością w dashboardzie „Journal Entry Rejection & Rework Analysis”. Dlaczego to ważne Ułatwia wskazywanie spraw wymagających poprawek, obliczanie odsetka odrzuceń i analizę skutków problemów z jakością. Skąd pobrać Flaga jest obliczana w narzędziu process mining na podstawie kolejności czynności w każdej sprawie. Przykłady truefalse
	Czy zautomatyzowano IsAutomated	Flaga wskazująca, czy zapis księgowy został utworzony lub zaksięgowany automatycznie.
Opis Ten atrybut logiczny odróżnia zapisy księgowe tworzone i obsługiwane ręcznie przez użytkowników od zapisów generowanych automatycznie przez system, na przykład zapisów cyklicznych lub pochodzących z integracji systemowych. Analiza tego atrybutu pomaga ocenić skuteczność automatyzacji. Umożliwia bezpośrednie porównanie czasów cyklu, odsetka błędów i kosztów procesów automatycznych i ręcznych. Jest to ważne przy uzasadnianiu dalszej automatyzacji i pomiarze zwrotu z już wdrożonych rozwiązań. Dlaczego to ważne Umożliwia bezpośrednie porównanie procesów ręcznych i automatycznych, co jest niezbędne do pomiaru efektów i zwrotu z inwestycji w automatyzację. Skąd pobrać Wartość można ustalić na podstawie pola „Journal Entry Type” (na przykład „Recurring”) lub pola „User”, jeśli do automatycznego księgowania używane są konta systemowe, takie jak „SYSTEM” lub „BATCH”. Przykłady truefalse
	Data księgowania PostingDate	Data oficjalnego zaksięgowania zapisu w księdze głównej.
Opis Data księgowania to data obowiązywania transakcji w dokumentacji finansowej. Ma zasadnicze znaczenie dla rachunkowości, ponieważ określa okres obrachunkowy, w którym transakcja zostanie ujęta. Znacznik czasu zdarzenia wskazuje, kiedy nastąpiło księgowanie, natomiast sama data księgowania jest ważnym atrybutem danych. Służy do sprawdzania, czy zapisy zaksięgowano we właściwym okresie, oraz do analizy opóźnień między datą transakcji, zatwierdzenia i księgowania. Dlaczego to ważne Ta data ma zasadnicze znaczenie dla poprawności sprawozdawczości finansowej i pomaga sprawdzić, czy zapisy są księgowane we właściwym okresie obrachunkowym. Skąd pobrać To standardowe pole daty w nagłówku zapisu księgowego w BlackLine. Przykłady 2023-10-312023-11-012023-10-30
	Dołączono dokument IsDocumentAttached	Flaga wskazująca, czy do zapisu księgowego dołączono dokumenty potwierdzające.
Opis Ten atrybut logiczny wskazuje, czy do zapisu księgowego dołączono co najmniej jeden dokument potwierdzający, na przykład fakturę lub wyliczenie. Często jest to warunek zatwierdzenia. Flaga ta jest istotna dla dashboardu „Journal Entry Documentation Compliance” i KPI „Documentation Attachment Rate”. Pomaga sprawdzić, czy brak dokumentów często powoduje odrzucenia lub opóźnienia, oraz egzekwować zasady wymagające załączników przed przekazaniem zapisu do weryfikacji. Dlaczego to ważne Bezpośrednio mierzy zgodność z zasadami dotyczącymi dokumentacji i pomaga wykryć częstą przyczynę opóźnień oraz odrzuceń podczas zatwierdzania. Skąd pobrać To prawdopodobnie pole pochodne, obliczane przez sprawdzenie, czy przed przesłaniem zapisu istnieje powiązany z nim rekord załącznika dla identyfikatora JournalEntryId. Przykłady truefalse
	Dział Department	Dział lub centrum kosztów powiązane z zapisem księgowym.
Opis Ten atrybut określa dział, centrum kosztów lub obszar funkcjonalny, który zainicjował zapis księgowy albo któremu przypisano koszty. Dostarcza dodatkowego kontekstu organizacyjnego. Analiza procesu według działów pomaga zrozumieć, jak poszczególne części firmy korzystają z procesu obsługi zapisów księgowych. Może ujawnić różnice w efektywności, zgodności lub odsetku poprawek między działami oraz wskazać obszary wymagające dodatkowego wsparcia lub ujednolicenia procesu. Dlaczego to ważne Pozwala porównywać przebieg procesu w różnych działach firmy, wykrywać różnice i wskazywać możliwości ujednolicenia. Skąd pobrać Informacje te znajdują się zwykle w danych pozycji lub nagłówka zapisu księgowego w BlackLine i często są powiązane z kontem księgi głównej. Przykłady FinanseMarketingSprzedażOperacje
	Opóźnienie między zatwierdzeniem a księgowaniem ApprovalToPostingLag	Obliczony czas między końcowym zatwierdzeniem a faktycznym zaksięgowaniem zapisu księgowego.
Opis Ten wskaźnik mierzy opóźnienie między pełnym zatwierdzeniem zapisu księgowego a jego zaksięgowaniem w księdze głównej. Oblicza się go jako różnicę czasu między czynnościami „Journal Entry Approved” i „Journal Entry Posted”. To ważny KPI służący do wykrywania wąskich gardeł po zatwierdzeniu, które mogą znacznie opóźnić zamknięcie finansowe. Dashboard „Approval To Posting Delay Analysis” wykorzystuje ten wskaźnik do badania przyczyn opóźnień w księgowaniu zatwierdzonych zapisów i usprawniania końcowych etapów procesu. Dlaczego to ważne Mierzy efektywność działań po zatwierdzeniu i pomaga wykrywać oraz eliminować opóźnienia wpływające na tempo zamknięcia finansowego. Skąd pobrać Wskaźnik oblicza się w narzędziu process mining, mierząc dla każdej sprawy czas między zdarzeniami „Journal Entry Approved” i „Journal Entry Posted”. Przykłady P0DT1H10MP1DT2H0MP0DT0H5M
	Uzgodnione konto AccountReconciled	Numer konta księgi głównej uzgadnianego za pomocą zapisu księgowego.
Opis Ten atrybut wskazuje konkretne konto w planie kont, którego dotyczy zapis lub które jest uzgadniane. Zapisy księgowe często są częścią procesu uzgadniania kont, a ten atrybut łączy zapis z konkretnym kontem. Atrybut ten bezpośrednio wspiera dashboard „Journal Entry Reconciliation Cycle Time”. Analiza procesu dla poszczególnych kont pozwala ustalić, czy uzgadnianie niektórych kont regularnie trwa dłużej, co może wskazywać na ich złożoność lub problemy z danymi. Dlaczego to ważne Łączy proces obsługi zapisu księgowego z uzgadnianymi kontami, umożliwiając ukierunkowaną analizę wąskich gardeł w uzgadnianiu. Skąd pobrać Informacje te znajdują się w szczegółach pozycji zapisu księgowego w BlackLine. Jeśli zapis dotyczy wielu kont, może być konieczne zagregowanie danych na poziomie sprawy. Przykłady 101000210500400100550200
	Waluta Currency	Kod waluty kwoty podanej w zapisie księgowym.
Opis Ten atrybut określa walutę kwoty zapisu księgowego, na przykład USD, EUR lub GBP. Jest niezbędny do prawidłowej interpretacji wartości transakcji. W organizacjach międzynarodowych analiza według waluty dostarcza przydatnego kontekstu. Pozwala filtrować analizę procesu według waluty i jest niezbędna na każdym dashboardzie, który sumuje kwoty finansowe. Dlaczego to ważne Zapewnia niezbędny kontekst dla kwot finansowych, ułatwia ich prawidłową interpretację i umożliwia analizę według waluty. Skąd pobrać To standardowe pole w nagłówku zapisu księgowego w BlackLine, zwykle nazwane „Document Currency” lub podobnie. Przykłady USDEURGBPJPY

Wymagane Zalecane Opcjonalne

Czynności w procesie Record to Report, zapisy księgowe

To najważniejsze etapy i kamienie milowe, które należy uwzględnić w dzienniku zdarzeń, aby prawidłowo odkrywać i analizować proces obsługi zapisów księgowych.

6 Zalecane 6 Opcjonalne

	Działanie	Opis
	Odrzucono zapis księgowy	To działanie oznacza odrzucenie zapisu księgowego przez osobę weryfikującą lub zatwierdzającą. Jest rejestrowane, gdy użytkownik wybiera opcję „Odrzuć”, co zmienia status zapisu na „Odrzucony” i zostaje zapisane w dzienniku audytowym.
Dlaczego to ważne To ważne działanie przy wykrywaniu ponownej pracy, problemów z jakością i potrzeb szkoleniowych. Analiza częstotliwości i przyczyn odrzuceń oraz późniejszej pętli poprawek pomaga usprawnić proces i skrócić czas cyklu. Skąd pobrać Zdarzenie jest zwykle ustalane na podstawie zmiany statusu zapisu księgowego na „Odrzucony” lub „Wymaga poprawy”. Historia BlackLine zawiera znacznik czasu i dane użytkownika, który odrzucił zapis. Rejestrowanie Ustalane na podstawie znacznika czasu zmiany statusu zapisu księgowego na „Odrzucony”. Typ zdarzenia inferred
	Przekazano zapis księgowy	To działanie ma miejsce, gdy osoba przygotowująca zapis formalnie przekazuje go do weryfikacji i zatwierdzenia. Zwykle jest rejestrowane jako zmiana statusu, na przykład z „W przygotowaniu” na „Przekazany”, wraz ze znacznikiem czasu.
Dlaczego to ważne To działanie kończy etap przygotowania i rozpoczyna cykl zatwierdzania. Jest ważnym punktem pomiaru czasu trwania obu etapów. Skąd pobrać Zdarzenie jest najprawdopodobniej ustalane na podstawie zmiany statusu zapisu księgowego w BlackLine. Czas zdarzenia wyznacza znacznik czasu zmiany statusu na „Przekazany do zatwierdzenia” lub podobny. Rejestrowanie Ustalane na podstawie znacznika czasu aktualizacji pola statusu zapisu księgowego na „Przekazany” lub „Oczekuje na zatwierdzenie”. Typ zdarzenia inferred
	Utworzono zapis księgowy	To działanie rozpoczyna obsługę zapisu księgowego. Jest rejestrowane, gdy użytkownik tworzy nowy zapis w BlackLine. System nadaje mu unikatowe ID zapisu księgowego oraz zapisuje znacznik czasu utworzenia i dane użytkownika.
Dlaczego to ważne To główne zdarzenie rozpoczynające proces. Analiza czasu od tego działania do kolejnych etapów pokazuje całkowity czas cyklu i pomaga wykryć opóźnienia na samym początku workflow. Skąd pobrać Zdarzenie jest jawnie rejestrowane w module zapisów księgowych BlackLine. Pochodzi ze znacznika czasu utworzenia i danych użytkownika powiązanych z każdym ID zapisu księgowego w głównej tabeli zapisów lub historii audytowej. Rejestrowanie Na podstawie znacznika czasu „Data utworzenia” przypisanego do zapisu księgowego. Typ zdarzenia explicit
	Uzgodnienie zapisu księgowego	Oznacza zakończenie cyklu życia zapisu księgowego, który został uwzględniony w sfinalizowanym i zatwierdzonym uzgodnieniu konta. W BlackLine odpowiada to zatwierdzeniu uzgodnienia zawierającego ten zapis.
Dlaczego to ważne To końcowy etap całego procesu. Czas od zdarzenia „Journal Entry Posted” do „Reconciled” mierzy efektywność uzgadniania kont w ramach zamknięcia finansowego. Skąd pobrać To zdarzenie można wywnioskować. W module Account Reconciliation w BlackLine należy ustalić, kiedy status uzgodnienia konta zawierającego dany zapis księgowy zmienił się na „Certified”. Rejestrowanie Zdarzenie wywnioskowane przez powiązanie zapisu księgowego z odpowiednim uzgodnieniem konta i pobranie daty zatwierdzenia tego uzgodnienia. Typ zdarzenia inferred
	Zaksięgowanie zapisu księgowego	To moment, w którym zatwierdzony zapis księgowy zostaje oficjalnie ujęty w księdze głównej. W BlackLine często wymaga to jawnego działania, po którym status zapisu zmienia się na „Posted”.
Dlaczego to ważne To ważny etap, często uznawany za operacyjne zakończenie procesu. Czas od zdarzenia „Journal Entry Approved” do tego zdarzenia wskazuje efektywność działań po zatwierdzeniu. Skąd pobrać Zdarzenie zwykle można wywnioskować ze zmiany statusu na „Posted”. Może też być jawnie zapisane w tabeli historii księgowań lub ścieżce audytu wraz z datą i znacznikiem czasu księgowania. Rejestrowanie Zdarzenie wywnioskowane ze znacznika czasu, w którym status zapisu księgowego zmieniono na „Posted”. Znaczenie ma również pole daty księgowania. Typ zdarzenia inferred
	Zatwierdzenie zapisu księgowego	To zdarzenie oznacza, że zapis księgowy przeszedł wszystkie wymagane etapy weryfikacji i zatwierdzania. Jest rejestrowane, gdy ostatnia upoważniona osoba zatwierdzi zapis, zmieniając jego status na „Approved”.
Dlaczego to ważne To ważny etap, który kończy proces zatwierdzania. Czas od zdarzenia „Journal Entry Submitted” do tego zdarzenia to czas cyklu zatwierdzania, istotny KPI do pomiaru efektywności workflow. Skąd pobrać Zdarzenie można wywnioskować ze zmiany statusu zapisu księgowego na „Approved”. Identyfikator użytkownika, który zatwierdził zapis, oraz znacznik czasu zatwierdzenia są zwykle zapisane w historii audytu BlackLine. Rejestrowanie Zdarzenie wywnioskowane ze znacznika czasu, w którym status zapisu księgowego zmieniono na „Approved”. Typ zdarzenia inferred
	Cofnięcie zatwierdzenia	To zdarzenie oznacza, że osoba zatwierdzająca cofa wcześniej udzieloną zgodę, przywracając zapis księgowy do poprzedniego stanu. Rozpoznaje się je po zmianie statusu z „Approved” na wcześniejszy, na przykład „In Preparation”.
Dlaczego to ważne To rzadkie, ale istotne zdarzenie wskazuje wyjątki w procesie i potencjalne problemy wykryte po zatwierdzeniu, ale przed zaksięgowaniem. Może sygnalizować błędy danych lub zmiany zasad dotyczących zapisu. Skąd pobrać To zdarzenie można wywnioskować ze zmiany statusu z „Approved” na status umożliwiający edycję, który nie oznacza jeszcze zaksięgowania. Działanie to powinno być odnotowane w szczegółowych dziennikach audytu BlackLine. Rejestrowanie Zdarzenie rozpoznaje się po zmianie statusu z „Approved” na wcześniejszy, na przykład „In Preparation” lub „Submitted”. Typ zdarzenia inferred
	Dołączono dokumentację potwierdzającą	Oznacza dołączenie przez użytkownika co najmniej jednego dokumentu potwierdzającego do zapisu księgowego. Zdarzenie jest zwykle rejestrowane w dzienniku audytowym lub powiązanej tabeli załączników, która zawiera ID zapisu księgowego.
Dlaczego to ważne Śledzenie tego działania jest ważne przy monitorowaniu zgodności i sprawności procesu. Pomaga ustalić, czy opóźnienia w zatwierdzaniu wynikają z brakującej dokumentacji, i wspiera pomiar KPI „Odsetek zapisów z dołączoną dokumentacją”. Skąd pobrać Zwykle jest to jawne zdarzenie w BlackLine, zapisywane w ścieżce audytowej lub dzienniku załączników. Dane obejmują ID zapisu księgowego, użytkownika, który dołączył plik, oraz znacznik czasu. Rejestrowanie Zdarzenie jest zapisywane w ścieżce audytowej systemu lub dedykowanej tabeli historii załączników za każdym razem, gdy plik zostaje przesłany do zapisu księgowego. Typ zdarzenia explicit
	Poprawiono i ponownie przekazano zapis księgowy	Występuje po odrzuceniu zapisu księgowego, gdy osoba przygotowująca wprowadzi wymagane poprawki i ponownie go prześle. Zdarzenie rozpoznaje się po zmianie statusu z „Rejected” na „Submitted for Approval”.
Dlaczego to ważne To zdarzenie pozwala określić czas i nakład pracy związane z poprawkami. Czas między zdarzeniami „Journal Entry Rejected” i tym zdarzeniem odpowiada czasowi potrzebnemu na poprawienie zapisu. Jest to ważny wskaźnik efektywności. Skąd pobrać Zdarzenie można wywnioskować z sekwencji zmian statusu w danych BlackLine. Chodzi o zmianę statusu z „Rejected” na „Submitted” lub „Pending Approval” dla tego samego identyfikatora zapisu księgowego. Rejestrowanie Zdarzenie wywnioskowane ze zmiany statusu z „Rejected” na „Submitted” lub „Pending Approval”. Typ zdarzenia inferred
	Przetworzenie storna zapisu księgowego	To zdarzenie obejmuje utworzenie i zaksięgowanie nowego zapisu księgowego, który odwraca wcześniej zaksięgowany zapis. Zwykle następuje po wykryciu błędu już po zaksięgowaniu pierwotnego zapisu.
Dlaczego to ważne To zdarzenie wyraźnie wskazuje na problemy z jakością danych na wcześniejszych etapach. Śledzenie liczby storna pozwala mierzyć wskaźnik korekt po zaksięgowaniu i wskazywać obszary wymagające większej dokładności. Skąd pobrać Często jest to jawne zdarzenie: użytkownik wybiera w BlackLine działanie „Reverse” dla zaksięgowanego zapisu. System tworzy nowy zapis odwracający, zwykle powiązany z pierwotnym identyfikatorem zapisu księgowego. Rejestrowanie Zdarzenie jest rejestrowane po zapisaniu działania „Reverse” albo po utworzeniu nowego zapisu z flagą storna i odnośnikiem do identyfikatora pierwotnego zapisu. Typ zdarzenia explicit
	Weryfikacja zaksięgowania	To potwierdzenie, że zaksięgowany zapis księgowy został prawidłowo odebrany i zarejestrowany w docelowym systemie ERP. Może to być automatyczna wymiana potwierdzeń między systemami lub ręczny etap potwierdzenia.
Dlaczego to ważne To zdarzenie zamyka etap księgowania i pomaga zapewnić spójność danych między systemami. Czas od „Posted” do „Verified” może wskazywać problemy z integracją lub opóźnienia w synchronizacji systemów. Skąd pobrać Może to być jawne zdarzenie z dziennika integracji systemów albo zdarzenie wywnioskowane ze zmiany statusu na przykład na „Posted and Verified”. Jeśli potwierdzenie jest ręczne, użytkownik zmienia status. Rejestrowanie Zdarzenie wywnioskowane ze zmiany statusu na „Verified” lub z flagi potwierdzenia otrzymanej z docelowego systemu ERP. Typ zdarzenia inferred
	Zweryfikowano zapis księgowy	Oznacza formalny etap weryfikacji w wieloetapowym procesie zatwierdzania, przeprowadzany przez wyznaczoną osobę. Zwykle jest rejestrowany jako zmiana statusu lub wpis w dzienniku wskazujący działanie weryfikującego.
Dlaczego to ważne W organizacjach, w których weryfikacja i zatwierdzanie są odrębnymi etapami, to działanie pomaga wskazać wąskie gardła w łańcuchu zatwierdzania. Pokazuje, jak długo zapisy czekają na wstępną weryfikację, a jak długo na ostateczne zatwierdzenie. Skąd pobrać W workflow BlackLine może to być jawne zdarzenie w dzienniku historii zatwierdzania lub zdarzenie ustalone na podstawie zmiany statusu na „Zweryfikowany” albo „Oczekuje na ostateczne zatwierdzenie”. Rejestrowane są użytkownik i znacznik czasu. Rejestrowanie Ustalane na podstawie znacznika czasu zmiany statusu zapisu księgowego wskazującej zakończenie etapu weryfikacji. Typ zdarzenia inferred

Zalecane Opcjonalne

Instrukcje ekstrakcji danych

Jak pobrać dane z BlackLine

Kroki

Zaloguj się do instancji BlackLine na konto użytkownika z uprawnieniami do raportowania finansowego.
Przejdź do modułu raportowania. Zwykle znajduje się on w menu „Reports” > „Standard Reports”.
Znajdź i wybierz raport „Journal Entry & Services Report” lub podobny, szczegółowy raport zapisów księgowych z listy dostępnych raportów standardowych.
Skonfiguruj parametry raportu. Określ „Date Range” dla ekstrakcji, obejmujący analizowany okres. Na początek zaleca się zakres od 3 do 6 miesięcy.
Zastosuj filtry, aby zawęzić dane. Co najmniej wybierz odpowiednie „Company Code(s)”. Można też filtrować według „Journal Status”, uwzględniając wszystkie statusy od utworzenia do zaksięgowania.
Wybierz wszystkie dostępne kolumny, aby raport zawierał niezbędne pola dat, użytkowników i statusów do utworzenia dziennika zdarzeń. Ważne pola to data utworzenia, data przesłania, data zatwierdzenia, data księgowania i role użytkowników.
Uruchom raport w interfejsie BlackLine. Po jego wygenerowaniu użyj funkcji „Export” lub „Download”, aby zapisać dane jako plik CSV. Nazwij go „blackline_report.csv”.
Skonfiguruj środowisko Python z zainstalowaną biblioteką pandas. Jeśli nie jest dostępna, zainstaluj ją poleceniem: pip install pandas.
Umieść dostarczony skrypt Python w tym samym katalogu co pobrany plik „blackline_report.csv”.
Uruchom skrypt Python. Odczyta on surowy raport CSV, przekształci dane, tworząc osobny wiersz dla każdej czynności biznesowej, i zapisze nowy plik „event_log.csv” w wymaganym formacie.
Przed przesłaniem sprawdź plik „event_log.csv”, aby potwierdzić jakość i kompletność danych.
Prześlij gotowy plik „event_log.csv” do ProcessMind w celu analizy.

Konfiguracja

Nazwa raportu: Journal Entry & Services Report. Dokładna nazwa może zależeć od konfiguracji BlackLine.
Zakres dat: Na potrzeby wstępnej analizy zaleca się pobranie danych z okresu od 3 do 6 miesięcy. Filtr dat w raporcie zwykle dotyczy daty utworzenia lub zaksięgowania zapisu. Należy sprawdzić, które pole daty jest używane, aby pobrać właściwy zestaw danych.
Najważniejsze filtry:
- Company Code: Zawsze określ kody spółek objętych analizą, aby ograniczyć ilość danych i skupić analizę na właściwym zakresie.
- Journal Status: Wybierz wszystkie statusy, np. In Preparation, Submitted, Approved, Rejected i Posted, aby uwzględnić cały proces.
- Journal Type: W razie potrzeby ogranicz dane do wybranych typów zapisów, np. Standard lub Recurring, zgodnie z zakresem analizy.
Wymagania wstępne: Konto użytkownika uruchamiającego raport musi mieć uprawnienia do wyświetlania danych zapisów księgowych i uruchamiania raportów standardowych w BlackLine. Zwykle wymagana jest rola taka jak „Accountant” lub „Reporting User”.
Wydajność: Eksport dużego zestawu danych obejmującego długi okres lub wiele kodów spółek może wymagać znacznych zasobów i długo trwać w interfejsie BlackLine. W razie problemów z wydajnością lub przekroczenia limitu czasu warto uruchamiać raport w mniejszych partiach.

Przykładowe zapytanie python

import pandas as pd
import numpy as np
import datetime

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Define the input file name from BlackLine
input_filename = class="hl-string">'blackline_report.csv'
class=class="hl-string">"hl-comment"># Define the output file for ProcessMind
output_filename = class="hl-string">'event_log.csv'

class=class="hl-string">"hl-comment"># --- Column Mapping ---
class=class="hl-string">"hl-comment"># Map the BlackLine report column names to the required event log attribute names.
class=class="hl-string">"hl-comment"># Adjust the keys in this dictionary to match the exact column headers in your CSV export.
column_mapping = {
    class="hl-string">'Journal ID': class="hl-string">'JournalEntryId',
    class="hl-string">'Journal Type': class="hl-string">'JournalEntryType',
    class="hl-string">'Company': class="hl-string">'CompanyCode',
    class="hl-string">'Amount': class="hl-string">'JournalEntryAmount',
    class="hl-string">'Current Status': class="hl-string">'JournalEntryStatus',
    class="hl-string">'Rejection Reason': class="hl-string">'RejectionReason',
    class="hl-string">'Preparer': class="hl-string">'PreparerUserName',
    class="hl-string">'Submitter': class="hl-string">'SubmitterUserName',
    class="hl-string">'Reviewer': class="hl-string">'ReviewerUserName',
    class="hl-string">'Approver': class="hl-string">'ApproverUserName',
    class="hl-string">'Poster': class="hl-string">'PosterUserName',
    class="hl-string">'Verifier': class="hl-string">'VerifierUserName',
    class="hl-string">'Reverser': class="hl-string">'ReverserUserName',
    class="hl-string">'Reconciler': class="hl-string">'ReconcilerUserName',
    class="hl-string">'Creation Date': class="hl-string">'CreationTimestamp',
    class="hl-string">'Attachment Date': class="hl-string">'AttachmentTimestamp',
    class="hl-string">'Submission Date': class="hl-string">'SubmissionTimestamp',
    class="hl-string">'Review Date': class="hl-string">'ReviewTimestamp',
    class="hl-string">'Rejection Date': class="hl-string">'RejectionTimestamp',
    class="hl-string">'Resubmission Date': class="hl-string">'ResubmissionTimestamp',
    class="hl-string">'Approval Date': class="hl-string">'ApprovalTimestamp',
    class="hl-string">'Rescind Date': class="hl-string">'RescindTimestamp',
    class="hl-string">'Posting Date': class="hl-string">'PostingTimestamp',
    class="hl-string">'Verification Date': class="hl-string">'VerificationTimestamp',
    class="hl-string">'Reversal Date': class="hl-string">'ReversalTimestamp',
    class="hl-string">'Reconciliation Date': class="hl-string">'ReconciliationTimestamp'
}

class=class="hl-string">"hl-comment"># --- Data Loading ---
try:
    df_raw = pd.read_csv(input_filename)
except FileNotFoundError:
    print(fclass="hl-string">"Error: The file {input_filename} was not found. Please ensure it's in the same directory as the script.")
    exit()

class=class="hl-string">"hl-comment"># Rename columns based on the mapping
df = df_raw.rename(columns=column_mapping)

class=class="hl-string">"hl-comment"># Ensure all required timestamp columns exist, fill with NaT if not
for col in column_mapping.values():
    if class="hl-string">'Timestamp' in col and col not in df.columns:
        df[col] = pd.NaT

class=class="hl-string">"hl-comment"># Convert date columns to datetime objects, coercing errors to NaT (Not a Time)
date_cols = [col for col in df.columns if class="hl-string">'Timestamp' in col]
for col in date_cols:
    df[col] = pd.to_datetime(df[col], errors=class="hl-string">'coerce')

all_events = []
last_data_update = datetime.datetime.now()

class=class="hl-string">"hl-comment"># --- Activity Extraction ---

class=class="hl-string">"hl-comment"># 1. Journal Entry Created
event_created = df[df[class="hl-string">'CreationTimestamp'].notna()].copy()
event_created[class="hl-string">'ActivityName'] = class="hl-string">'Journal Entry Created'
event_created[class="hl-string">'EventTime'] = event_created[class="hl-string">'CreationTimestamp']
event_created[class="hl-string">'UserName'] = event_created.get(class="hl-string">'PreparerUserName')
all_events.append(event_created)

class=class="hl-string">"hl-comment"># 2. Supporting Documentation Attached
if class="hl-string">'AttachmentTimestamp' in df.columns:
    event_attached = df[df[class="hl-string">'AttachmentTimestamp'].notna()].copy()
    event_attached[class="hl-string">'ActivityName'] = class="hl-string">'Supporting Documentation Attached'
    event_attached[class="hl-string">'EventTime'] = event_attached[class="hl-string">'AttachmentTimestamp']
    class=class="hl-string">"hl-comment"># Assuming the submitter or preparer attached the document
    event_attached[class="hl-string">'UserName'] = event_attached.get(class="hl-string">'SubmitterUserName', event_attached.get(class="hl-string">'PreparerUserName'))
    all_events.append(event_attached)

class=class="hl-string">"hl-comment"># 3. Journal Entry Submitted
event_submitted = df[df[class="hl-string">'SubmissionTimestamp'].notna()].copy()
event_submitted[class="hl-string">'ActivityName'] = class="hl-string">'Journal Entry Submitted'
event_submitted[class="hl-string">'EventTime'] = event_submitted[class="hl-string">'SubmissionTimestamp']
event_submitted[class="hl-string">'UserName'] = event_submitted.get(class="hl-string">'SubmitterUserName')
all_events.append(event_submitted)

class=class="hl-string">"hl-comment"># 4. Journal Entry Reviewed
if class="hl-string">'ReviewTimestamp' in df.columns:
    event_reviewed = df[df[class="hl-string">'ReviewTimestamp'].notna()].copy()
    event_reviewed[class="hl-string">'ActivityName'] = class="hl-string">'Journal Entry Reviewed'
    event_reviewed[class="hl-string">'EventTime'] = event_reviewed[class="hl-string">'ReviewTimestamp']
    event_reviewed[class="hl-string">'UserName'] = event_reviewed.get(class="hl-string">'ReviewerUserName')
    all_events.append(event_reviewed)

class=class="hl-string">"hl-comment"># 5. Journal Entry Rejected
if class="hl-string">'RejectionTimestamp' in df.columns:
    event_rejected = df[df[class="hl-string">'RejectionTimestamp'].notna()].copy()
    event_rejected[class="hl-string">'ActivityName'] = class="hl-string">'Journal Entry Rejected'
    event_rejected[class="hl-string">'EventTime'] = event_rejected[class="hl-string">'RejectionTimestamp']
    event_rejected[class="hl-string">'UserName'] = event_rejected.get(class="hl-string">'ReviewerUserName', event_rejected.get(class="hl-string">'ApproverUserName'))
    all_events.append(event_rejected)

class=class="hl-string">"hl-comment"># 6. Entry Corrected and Resubmitted
if class="hl-string">'ResubmissionTimestamp' in df.columns:
    event_resubmitted = df[df[class="hl-string">'ResubmissionTimestamp'].notna()].copy()
    event_resubmitted = event_resubmitted[event_resubmitted[class="hl-string">'ResubmissionTimestamp'] > event_resubmitted.get(class="hl-string">'RejectionTimestamp', pd.NaT)]
    event_resubmitted[class="hl-string">'ActivityName'] = class="hl-string">'Entry Corrected and Resubmitted'
    event_resubmitted[class="hl-string">'EventTime'] = event_resubmitted[class="hl-string">'ResubmissionTimestamp']
    event_resubmitted[class="hl-string">'UserName'] = event_resubmitted.get(class="hl-string">'SubmitterUserName')
    all_events.append(event_resubmitted)

class=class="hl-string">"hl-comment"># 7. Journal Entry Approved
event_approved = df[df[class="hl-string">'ApprovalTimestamp'].notna()].copy()
event_approved[class="hl-string">'ActivityName'] = class="hl-string">'Journal Entry Approved'
event_approved[class="hl-string">'EventTime'] = event_approved[class="hl-string">'ApprovalTimestamp']
event_approved[class="hl-string">'UserName'] = event_approved.get(class="hl-string">'ApproverUserName')
all_events.append(event_approved)

class=class="hl-string">"hl-comment"># 8. Approval Rescinded
if class="hl-string">'RescindTimestamp' in df.columns:
    event_rescinded = df[df[class="hl-string">'RescindTimestamp'].notna()].copy()
    event_rescinded[class="hl-string">'ActivityName'] = class="hl-string">'Approval Rescinded'
    event_rescinded[class="hl-string">'EventTime'] = event_rescinded[class="hl-string">'RescindTimestamp']
    event_rescinded[class="hl-string">'UserName'] = event_rescinded.get(class="hl-string">'ApproverUserName')
    all_events.append(event_rescinded)

class=class="hl-string">"hl-comment"># 9. Journal Entry Posted
event_posted = df[df[class="hl-string">'PostingTimestamp'].notna()].copy()
event_posted[class="hl-string">'ActivityName'] = class="hl-string">'Journal Entry Posted'
event_posted[class="hl-string">'EventTime'] = event_posted[class="hl-string">'PostingTimestamp']
event_posted[class="hl-string">'UserName'] = event_posted.get(class="hl-string">'PosterUserName')
all_events.append(event_posted)

class=class="hl-string">"hl-comment"># 10. Posting Verified
if class="hl-string">'VerificationTimestamp' in df.columns:
    event_verified = df[df[class="hl-string">'VerificationTimestamp'].notna()].copy()
    event_verified[class="hl-string">'ActivityName'] = class="hl-string">'Posting Verified'
    event_verified[class="hl-string">'EventTime'] = event_verified[class="hl-string">'VerificationTimestamp']
    event_verified[class="hl-string">'UserName'] = event_verified.get(class="hl-string">'VerifierUserName')
    all_events.append(event_verified)

class=class="hl-string">"hl-comment"># 11. Journal Entry Reversal Processed
if class="hl-string">'ReversalTimestamp' in df.columns:
    event_reversal = df[df[class="hl-string">'ReversalTimestamp'].notna()].copy()
    event_reversal[class="hl-string">'ActivityName'] = class="hl-string">'Journal Entry Reversal Processed'
    event_reversal[class="hl-string">'EventTime'] = event_reversal[class="hl-string">'ReversalTimestamp']
    event_reversal[class="hl-string">'UserName'] = event_reversal.get(class="hl-string">'ReverserUserName')
    all_events.append(event_reversal)

class=class="hl-string">"hl-comment"># 12. Journal Entry Reconciled
if class="hl-string">'ReconciliationTimestamp' in df.columns:
    event_reconciled = df[df[class="hl-string">'ReconciliationTimestamp'].notna()].copy()
    event_reconciled[class="hl-string">'ActivityName'] = class="hl-string">'Journal Entry Reconciled'
    event_reconciled[class="hl-string">'EventTime'] = event_reconciled[class="hl-string">'ReconciliationTimestamp']
    event_reconciled[class="hl-string">'UserName'] = event_reconciled.get(class="hl-string">'ReconcilerUserName')
    all_events.append(event_reconciled)


class=class="hl-string">"hl-comment"># --- Final Assembly ---
if all_events:
    event_log = pd.concat(all_events, ignore_index=True)

    class=class="hl-string">"hl-comment"># Add required constant value attributes
    event_log[class="hl-string">'SourceSystem'] = class="hl-string">'BlackLine'
    event_log[class="hl-string">'LastDataUpdate'] = last_data_update

    class=class="hl-string">"hl-comment"># Select and order columns for the final output
    final_columns = [
        class="hl-string">'JournalEntryId',
        class="hl-string">'ActivityName',
        class="hl-string">'EventTime',
        class="hl-string">'SourceSystem',
        class="hl-string">'LastDataUpdate',
        class="hl-string">'UserName',
        class="hl-string">'JournalEntryType',
        class="hl-string">'CompanyCode',
        class="hl-string">'JournalEntryAmount',
        class="hl-string">'JournalEntryStatus',
        class="hl-string">'RejectionReason'
    ]

    class=class="hl-string">"hl-comment"># Filter for only the columns that exist in the dataframe to avoid errors
    existing_columns = [col for col in final_columns if col in event_log.columns]
    event_log = event_log[existing_columns]

    class=class="hl-string">"hl-comment"># Sort the event log
    event_log = event_log.sort_values(by=[class="hl-string">'JournalEntryId', class="hl-string">'EventTime'])

    class=class="hl-string">"hl-comment"># Save to CSV
    event_log.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%d %H:%M:%S')
    print(fclass="hl-string">"Successfully created event log: {output_filename}")
else:
    print(class="hl-string">"No events were generated. Please check your input file and column mappings.")

Kroki

Wymagania wstępne i konfiguracja: Upewnij się, że zainstalowano Python w wersji 3.6 lub nowszej. Zainstaluj wymagane biblioteki poleceniem pip: pip install requests pandas. Uzyskaj od administratora BlackLine dane dostępowe do API (Client ID, Client Secret, Refresh Token) oraz bazowy adres URL BlackLine w organizacji.
Konfiguracja zmiennych skryptu: Otwórz skrypt Python i znajdź sekcję konfiguracji. Wprowadź Client ID, Client Secret, Refresh Token i bazowy adres URL. Ustaw okres ekstrakcji, podając zmienne START_DATE i END_DATE w formacie „YYYY-MM-DD”.
Uwierzytelnianie: Skrypt rozpoczyna działanie od wywołania funkcji get_access_token. Funkcja przesyła dane dostępowe do punktu uwierzytelniania BlackLine (/api/oauth/token) i pobiera tymczasowy token dostępu, wymagany do kolejnych żądań API.
Pobranie początkowej listy zapisów: Skrypt wysyła stronicowane żądania do punktu końcowego /api/v2/journals, filtrując dane według podanego zakresu dat utworzenia. Przechodzi przez kolejne strony wyników i zbiera podstawowe informacje o zapisach księgowych objętych zakresem.
Pobranie szczegółowej historii zdarzeń: Dla każdego zebranego w poprzednim kroku identyfikatora Journal Entry ID skrypt wykonuje dwa dodatkowe wywołania API. Najpierw odpytuje punkt końcowy historii zapisu (np. /api/v2/journals/{id}/history), aby pobrać szczegółowy ślad audytowy zmian statusu, zatwierdzeń i odrzuceń. Następnie wywołuje punkt końcowy załączników (np. /api/v2/journals/{id}/attachments), aby ustalić, kiedy dodano dokumenty potwierdzające.
Przekształcenie danych w dziennik zdarzeń: Skrypt przetwarza odpowiedzi JSON z API. Przechodzi przez każdy zapis oraz powiązane z nim wpisy historii i załączników. Przekształca surowe dane do uporządkowanego formatu dziennika zdarzeń, tworząc osobny wiersz dla każdej z 12 wymaganych czynności, takich jak „Journal Entry Created”, „Journal Entry Submitted” i „Journal Entry Approved”.
Mapowanie zmian statusu na czynności: Najważniejsze czynności są określane na podstawie danych z punktu końcowego historii. Na przykład wpis historii wskazujący zmianę statusu na „Submitted” jest mapowany na czynność „Journal Entry Submitted”. Skrypt przyporządkowuje różne typy zdarzeń z historii do standardowych nazw czynności wymaganych przez ProcessMind.
Tworzenie DataFrame: Skrypt używa biblioteki pandas do tworzenia DataFrame. Najpierw tworzy DataFrame dla zdarzenia „Created” na podstawie głównej listy zapisów. Następnie tworzy kolejny DataFrame z pozostałymi czynnościami, wynikającymi z historii i rejestru załączników. Na końcu łączy je w jeden dziennik zdarzeń.
Dodanie metadanych i ujednolicenie kolumn: Po połączeniu danych skrypt dodaje wymagane kolumny metadanych, w tym SourceSystem (ustawione na stałe jako „BlackLine”) i LastDataUpdate (ustawione na czas uruchomienia skryptu). Zmienia też nazwy kolumn, aby odpowiadały wymaganemu schematowi, na przykład mapuje pole API id na JournalEntryId.
Eksport do CSV: Na koniec skrypt eksportuje gotowy DataFrame dziennika zdarzeń do pliku CSV o nazwie blackline_journal_entry_event_log.csv. Plik jest sformatowany i gotowy do przesłania bezpośrednio do ProcessMind.

Konfiguracja

Dane dostępowe do API: Wymagane są prawidłowe Client ID, Client Secret i Refresh Token do BlackLine REST API. Należy je bezpiecznie przechowywać i nie wpisywać na stałe do skryptów używanych produkcyjnie.
Bazowy adres URL: Skrypt wymaga bazowego adresu URL API właściwego dla organizacji, np. https://api.blackline.com.
Zakres dat: Skrypt korzysta ze zmiennych START_DATE i END_DATE. Do wstępnej analizy zaleca się zakres obejmujący ostatnie 3 do 6 miesięcy, aby zebrać wystarczającą ilość danych bez nadmiernego zwiększania ich objętości.
Limit stronicowania: Zmienna LIMIT określa liczbę rekordów pobieranych w jednym wywołaniu API. Wartość domyślna wynosi zwykle 100. Zmiana może wpłynąć na wydajność, dlatego najlepiej pozostawić zalecaną wartość, chyba że pomoc techniczna BlackLine zaleci inaczej.
Wymagane uprawnienia: Użytkownik API powiązany z danymi dostępowymi musi mieć uprawnienia do odczytu zapisów księgowych, ich historii i załączników dla analizowanych kodów spółek.
Środowisko Python: Do uruchomienia skryptu wymagane jest działające środowisko Python 3.6 lub nowsze z zainstalowanymi bibliotekami requests i pandas.

Przykładowe zapytanie python

import requests
import pandas as pd
from datetime import datetime
import time

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your BlackLine API credentials and base URL
CLIENT_ID = class="hl-string">'[Your Client ID]'
CLIENT_SECRET = class="hl-string">'[Your Client Secret]'
REFRESH_TOKEN = class="hl-string">'[Your Refresh Token]'
BASE_URL = class="hl-string">'[Your BlackLine API Base URL, e.g., https://api.blackline.com]'

class=class="hl-string">"hl-comment"># --- Extraction Parameters ---
START_DATE = class="hl-string">'2023-01-01' class=class="hl-string">"hl-comment"># Format: YYYY-MM-DD
END_DATE = class="hl-string">'2023-12-31'   class=class="hl-string">"hl-comment"># Format: YYYY-MM-DD
LIMIT = 100 class=class="hl-string">"hl-comment"># Records per page

def get_access_token():
    class="hl-string">"""Authenticates with BlackLine to get an access token."""
    auth_url = fclass="hl-string">"{BASE_URL}/api/oauth/token"
    payload = {
        class="hl-string">'grant_type': class="hl-string">'refresh_token',
        class="hl-string">'client_id': CLIENT_ID,
        class="hl-string">'client_secret': CLIENT_SECRET,
        class="hl-string">'refresh_token': REFRESH_TOKEN
    }
    response = requests.post(auth_url, data=payload)
    response.raise_for_status() class=class="hl-string">"hl-comment"># Raise an exception for bad status codes
    return response.json()[class="hl-string">'access_token']

def main():
    class="hl-string">"""Main function to extract, transform, and save journal entry event data."""
    print(class="hl-string">"Starting BlackLine Journal Entry extraction...")
    
    try:
        access_token = get_access_token()
        headers = {class="hl-string">'Authorization': fclass="hl-string">'Bearer {access_token}'}
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Authentication failed: {e}")
        return

    events = []
    last_data_update = datetime.utcnow().isoformat() + class="hl-string">'Z'

    class=class="hl-string">"hl-comment"># 1. Fetch all journals within the date range
    print(fclass="hl-string">"Fetching journals created between {START_DATE} and {END_DATE}...")
    journals = []
    offset = 0
    while True:
        journals_url = fclass="hl-string">"{BASE_URL}/api/v2/journals"
        params = {
            class="hl-string">'createdStartDate': START_DATE,
            class="hl-string">'createdEndDate': END_DATE,
            class="hl-string">'limit': LIMIT,
            class="hl-string">'offset': offset
        }
        try:
            response = requests.get(journals_url, headers=headers, params=params)
            response.raise_for_status()
            data = response.json()
            journals.extend(data.get(class="hl-string">'data', []))
            if class="hl-string">'nextLink' not in data or not data.get(class="hl-string">'data'):
                break
            offset += LIMIT
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching journals: {e}")
            break

    print(fclass="hl-string">"Found {len(journals)} journals. Now fetching detailed events for each...")

    class=class="hl-string">"hl-comment"># 2. For each journal, fetch history and attachments
    for journal in journals:
        journal_id = journal.get(class="hl-string">'id')
        if not journal_id:
            continue

        class=class="hl-string">"hl-comment"># --- Activity: Journal Entry Created ---
        events.append({
            class="hl-string">'JournalEntryId': journal_id,
            class="hl-string">'ActivityName': class="hl-string">'Journal Entry Created',
            class="hl-string">'EventTime': journal.get(class="hl-string">'createdDate'),
            class="hl-string">'UserName': journal.get(class="hl-string">'createdBy', {}).get(class="hl-string">'username'),
            class="hl-string">'JournalEntryType': journal.get(class="hl-string">'type'),
            class="hl-string">'CompanyCode': journal.get(class="hl-string">'companyCode'),
            class="hl-string">'JournalEntryAmount': journal.get(class="hl-string">'totalDebit'),
            class="hl-string">'JournalEntryStatus': journal.get(class="hl-string">'status'),
            class="hl-string">'RejectionReason': None
        })

        class=class="hl-string">"hl-comment"># Fetch history for other activities
        try:
            history_url = fclass="hl-string">"{BASE_URL}/api/v2/journals/{journal_id}/history"
            history_response = requests.get(history_url, headers=headers)
            history_response.raise_for_status()
            history_items = history_response.json().get(class="hl-string">'data', [])
            
            for item in history_items:
                activity_name = None
                rejection_reason = None
                
                class=class="hl-string">"hl-comment"># This mapping requires knowledge of your specific BlackLine history event descriptions
                class=class="hl-string">"hl-comment"># The following are common examples. Adjust them based on your BlackLine configuration.
                event_description = item.get(class="hl-string">'description', class="hl-string">'').lower()
                if class="hl-string">'submitted' in event_description:
                    activity_name = class="hl-string">'Journal Entry Submitted'
                elif class="hl-string">'reviewed' in event_description:
                    activity_name = class="hl-string">'Journal Entry Reviewed'
                elif class="hl-string">'rejected' in event_description:
                    activity_name = class="hl-string">'Journal Entry Rejected'
                    rejection_reason = item.get(class="hl-string">'comment') class=class="hl-string">"hl-comment"># Assuming comment contains the reason
                elif class="hl-string">'resubmitted' in event_description:
                    activity_name = class="hl-string">'Entry Corrected and Resubmitted'
                elif class="hl-string">'approved' in event_description and class="hl-string">'final' in event_description: class=class="hl-string">"hl-comment"># Example for final approval
                    activity_name = class="hl-string">'Journal Entry Approved'
                elif class="hl-string">'approval rescinded' in event_description:
                    activity_name = class="hl-string">'Approval Rescinded'
                elif class="hl-string">'posted' in event_description:
                    activity_name = class="hl-string">'Journal Entry Posted'
                elif class="hl-string">'posting verified' in event_description:
                     activity_name = class="hl-string">'Posting Verified'
                
                if activity_name:
                    events.append({
                        class="hl-string">'JournalEntryId': journal_id,
                        class="hl-string">'ActivityName': activity_name,
                        class="hl-string">'EventTime': item.get(class="hl-string">'eventDate'),
                        class="hl-string">'UserName': item.get(class="hl-string">'user', {}).get(class="hl-string">'username'),
                        class="hl-string">'JournalEntryType': journal.get(class="hl-string">'type'),
                        class="hl-string">'CompanyCode': journal.get(class="hl-string">'companyCode'),
                        class="hl-string">'JournalEntryAmount': journal.get(class="hl-string">'totalDebit'),
                        class="hl-string">'JournalEntryStatus': journal.get(class="hl-string">'status'),
                        class="hl-string">'RejectionReason': rejection_reason
                    })
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Could not fetch history for Journal ID {journal_id}: {e}")

        class=class="hl-string">"hl-comment"># Fetch attachments
        try:
            attachments_url = fclass="hl-string">"{BASE_URL}/api/v2/journals/{journal_id}/attachments"
            attachments_response = requests.get(attachments_url, headers=headers)
            attachments_response.raise_for_status()
            attachments = attachments_response.json().get(class="hl-string">'data', [])
            for attachment in attachments:
                events.append({
                    class="hl-string">'JournalEntryId': journal_id,
                    class="hl-string">'ActivityName': class="hl-string">'Supporting Documentation Attached',
                    class="hl-string">'EventTime': attachment.get(class="hl-string">'uploadedDate'),
                    class="hl-string">'UserName': attachment.get(class="hl-string">'uploadedBy', {}).get(class="hl-string">'username'),
                    class="hl-string">'JournalEntryType': journal.get(class="hl-string">'type'),
                    class="hl-string">'CompanyCode': journal.get(class="hl-string">'companyCode'),
                    class="hl-string">'JournalEntryAmount': journal.get(class="hl-string">'totalDebit'),
                    class="hl-string">'JournalEntryStatus': journal.get(class="hl-string">'status'),
                    class="hl-string">'RejectionReason': None
                })
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Could not fetch attachments for Journal ID {journal_id}: {e}")

        class=class="hl-string">"hl-comment"># --- Activities based on journal fields (may need customization) ---
        if journal.get(class="hl-string">'isReversed'):
            events.append({
                class="hl-string">'JournalEntryId': journal_id,
                class="hl-string">'ActivityName': class="hl-string">'Journal Entry Reversal Processed',
                class="hl-string">'EventTime': journal.get(class="hl-string">'[reversalDate]'), class=class="hl-string">"hl-comment"># Placeholder for reversal date field
                class="hl-string">'UserName': journal.get(class="hl-string">'[reversalUser]'), class=class="hl-string">"hl-comment"># Placeholder for user field
                class="hl-string">'JournalEntryType': journal.get(class="hl-string">'type'),
                class="hl-string">'CompanyCode': journal.get(class="hl-string">'companyCode'),
                class="hl-string">'JournalEntryAmount': journal.get(class="hl-string">'totalDebit'),
                class="hl-string">'JournalEntryStatus': class="hl-string">'Reversed',
                class="hl-string">'RejectionReason': None
            })

        if journal.get(class="hl-string">'reconciliationId'): class=class="hl-string">"hl-comment"># Assuming this indicates reconciliation
            events.append({
                class="hl-string">'JournalEntryId': journal_id,
                class="hl-string">'ActivityName': class="hl-string">'Journal Entry Reconciled',
                class="hl-string">'EventTime': journal.get(class="hl-string">'[reconciliationCertifiedDate]'), class=class="hl-string">"hl-comment"># Placeholder for certified date
                class="hl-string">'UserName': journal.get(class="hl-string">'[reconciliationCertifier]'), class=class="hl-string">"hl-comment"># Placeholder for certifier user
                class="hl-string">'JournalEntryType': journal.get(class="hl-string">'type'),
                class="hl-string">'CompanyCode': journal.get(class="hl-string">'companyCode'),
                class="hl-string">'JournalEntryAmount': journal.get(class="hl-string">'totalDebit'),
                class="hl-string">'JournalEntryStatus': journal.get(class="hl-string">'status'),
                class="hl-string">'RejectionReason': None
            })
        class=class="hl-string">"hl-comment"># Introduce a small delay to respect API rate limits
        time.sleep(0.1)

    if not events:
        print(class="hl-string">"No events were generated. Please check your date range and API access.")
        return

    class=class="hl-string">"hl-comment"># 3. Create DataFrame and save to CSV
    print(class="hl-string">"Transforming data and saving to CSV...")
    df = pd.DataFrame(events)

    class=class="hl-string">"hl-comment"># Add metadata columns
    df[class="hl-string">'SourceSystem'] = class="hl-string">'BlackLine'
    df[class="hl-string">'LastDataUpdate'] = last_data_update
    
    class=class="hl-string">"hl-comment"># Ensure required columns are present
    final_columns = [
        class="hl-string">'JournalEntryId', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
        class="hl-string">'UserName', class="hl-string">'JournalEntryType', class="hl-string">'CompanyCode', class="hl-string">'JournalEntryAmount', class="hl-string">'JournalEntryStatus', class="hl-string">'RejectionReason'
    ]
    for col in final_columns:
        if col not in df.columns:
            df[col] = None
            
    df = df[final_columns] class=class="hl-string">"hl-comment"># Order columns

    output_filename = class="hl-string">'blackline_journal_entry_event_log.csv'
    df.to_csv(output_filename, index=False)
    print(fclass="hl-string">"Extraction complete. Event log saved to {output_filename}")

if __name__ == class="hl-string">"__main__":
    main()

Gotowi do rozpoczęcia?

Skorzystaj z tego szablonu, aby usprawnić przygotowanie danych i lepiej poznać proces Record to Report, zapisy księgowe. Rozpocznij analizę, by poprawić efektywność i zgodność.

Wróć do przewodnika ulepszania procesów

Pobierz szablon

Już dziś usprawnij proces obsługi zapisów księgowych w Record to Report

Skróć cykl obsługi zapisów księgowych o 30% i szybciej zamykaj okresy, zachowując dokładność.

Rozpocznij okres próbny

Karta kredytowa nie jest wymagana • Konfiguracja zajmuje kilka minut

Szablon danych dla procesu Record to Report, zapisy księgowe

Szablon danych dla procesu Record to Report, zapisy księgowe

Atrybuty procesu Record to Report, zapisy księgowe

Czynności w procesie Record to Report, zapisy księgowe

Instrukcje ekstrakcji danych

Eksport raportu Journal Entry & Services z BlackLine

Kroki

Konfiguracja

Przykładowe zapytanie python

Ekstrakcja danych za pomocą skryptu Python i BlackLine REST API

Kroki

Konfiguracja

Przykładowe zapytanie python

Gotowi do rozpoczęcia?

Już dziś usprawnij proces obsługi zapisów księgowych w Record to Report