> Folyamatos folyamatfejlesztés > Könyvelési tétel rögzítése és jelentéskészítés > BlackLine > Adatsablon

Adatsablon a Record to Report naplóbejegyzési folyamathoz

BlackLine

← Vissza a folyamatfejlesztési útmutatóhoz

A Record to Report naplóbejegyzési folyamat attribútumai(19) A Record to Report naplóbejegyzési folyamat tevékenységei(12) Útmutatók az adatok kinyeréséhez(2)

Adatsablon a Record to Report naplóbejegyzési folyamathoz

Ez a sablon útmutatást ad ahhoz, hogy milyen adatokat gyűjtsön a Record to Report naplóbejegyzési folyamat elemzéséhez. Bemutatja a szükséges attribútumokat, a követendő fő tevékenységeket, valamint azt, hogyan nyerheti ki ezeket az adatokat a BlackLine rendszerből. Használja az útmutatót, hogy minden szükséges adat rendelkezésre álljon a hatékony process mining elemzéshez.

Javasolt attribútumok
Követendő fő tevékenységek
Útmutató az adatok kinyeréséhez

Most ismerkedik az eseménynaplókkal? Tudja meg, hogyan készíthet process mining eseménynaplót.

Sablon letöltése

A Record to Report naplóbejegyzési folyamat attribútumai

Az alábbi adatmezőket javasoljuk az eseménynaplóban rögzíteni a Record to Report naplóbejegyzési folyamat részletes elemzéséhez.

5 Kötelező 6 Javasolt 8 Nem kötelező

	Név	Leírás
	Kezdés időpontja EventTime	A pontos időbélyeg, amely megmutatja, mikor történt egy adott tevékenység vagy esemény.
Leírás Az esemény időpontja rögzíti, hogy mikor történt az üzleti esemény. Ez adja a folyamat időrendi alapját, és meghatározza a tevékenységek sorrendjét, valamint időtartamát. Ez az időbélyeg minden időalapú process mining elemzéshez szükséges. Segítségével kiszámítható a ciklusidő, a várakozási idő és a tevékenységek közötti időtartam. Lehetővé teszi a szűk keresztmetszetek azonosítását, a teljesítmény időbeli elemzését és a szolgáltatási szintű megállapodások betartásának ellenőrzését. Miért fontos? Ez az időbélyeg alapozza meg a teljesítménymutatók, köztük a ciklusidő és a szűk keresztmetszetek elemzését, és lehetővé teszi a folyamat időrendi rekonstruálását. Hol szerezhető be? Ez az adat a BlackLine eseménynaplóinak vagy tranzakciós rekordjainak időbélyegmezőiben található. Példák 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:05:00Z
	Naplóbejegyzés-azonosító JournalEntryId	Egy naplóbejegyzés egyedi azonosítója, amely az életciklus követéséhez használt elsődleges esetazonosító.
Leírás A Journal Entry ID egyedileg azonosítja a főkönyvben rögzített pénzügyi tranzakciók egyes csoportjait. Ez a központi azonosító kapcsolja össze a bejegyzéshez tartozó tevékenységeket, például a létrehozást, az ellenőrzést, a jóváhagyást és a könyvelést. A process mining során ez az azonosító kapcsolja össze az egyetlen naplóbejegyzéshez tartozó eseményeket. Az azonosító alapján rekonstruálható a teljes folyamat az indítástól a végső egyeztetésig, így részletesen elemezhetők a ciklusidők, a szűk keresztmetszetek és a folyamat eltérései. Miért fontos? Ez az alapvető esetazonosító, amellyel nyomon követhető egy naplóbejegyzés teljes életciklusa és elemezhető a teljesítménye. Hol szerezhető be? Ez a BlackLine naplóbejegyzés-tábláinak vagy adatexportjainak egyik elsődleges kulcsa. A pontos mezőnévért tekintse meg a BlackLine dokumentációját. Példák JE2024-001234JE2024-001235JE2024-001236
	Tevékenység ActivityName	A naplóbejegyzés folyamatában egy adott időpontban bekövetkezett üzleti esemény neve.
Leírás Ez az attribútum a naplóbejegyzés életciklusának egy-egy lépését vagy feladatát írja le, például: „Journal Entry Created”, „Journal Entry Approved” vagy „Journal Entry Posted”. Minden tevékenység a folyamat egy külön eseménye. A tevékenységek sorrendjének elemzésével megjeleníthető és megérthető a folyamat menete. Ez alapvető a folyamatváltozatok feltárásához, a lépések közötti idő méréséhez és az újramunkálási körök azonosításához, például amikor egy naplóbejegyzést elutasítanak, majd ismét benyújtanak. Miért fontos? Meghatározza a folyamat lépéseit, így alapul szolgál a folyamattérkép megjelenítéséhez, a folyamatmenet elemzéséhez, valamint az eltérések és a szűk keresztmetszetek azonosításához. Hol szerezhető be? Általában a BlackLine eseménynaplóiból, státuszváltozási rekordjaiból vagy auditnaplóiból származik. Előfordulhat, hogy a rendszer státuszkódjait felhasználóbarát tevékenységnevekhez kell rendelni. Példák Naplóbejegyzés létrehozvaNaplóbejegyzés beküldveNaplóbejegyzés jóváhagyvaNaplóbejegyzés könyvelve
	Forrásrendszer SourceSystem	Az a nyilvántartó rendszer, amelyből a naplóbejegyzés adatait kinyerték.
Leírás Ez az attribútum azonosítja az eseményadatok forrásrendszerét. Ebben az esetben ez általában a „BlackLine”, de a folyamat indulhat egy korábbi ERP-rendszerben is, így annak adatai is szerepelhetnek. A forrásrendszer azonosítása fontos az adatirányítás és a folyamat környezetének megértése szempontjából, különösen akkor, ha több rendszer adatait egyesítik. Segít az adatbetöltési problémák elhárításában és az adatok eredetének ellenőrzésében. Miért fontos? Fontos információt ad az adatok eredetéről, biztosítja a nyomon követhetőséget, és segít a különböző platformok közötti adatintegráció kezelésében. Hol szerezhető be? Ez általában egy rögzített érték, amelyet az adatok kinyerése és átalakítása során adnak hozzá az adathalmaz forrásának megjelölésére. Példák BlackLineSAP S/4HANAOracle NetSuite
	Utolsó adatfrissítés LastDataUpdate	Az időbélyeg, amely megmutatja, mikor frissítették vagy nyerték ki utoljára az adatokat a forrásrendszerből.
Leírás Ez az attribútum jelöli a legutóbbi adatlekérés dátumát és időpontját. Megmutatja, mennyire frissek az elemzett adatok, így a felhasználók tisztában vannak azok aktualitásával. Ez fontos metaadat minden process mining dashboard és elemzés esetében. Tájékoztatja a felhasználókat arról, mennyire naprakészek az eredmények, és segít tisztázni, hogy a legutóbbi tranzakciók is megjelennek-e. Miért fontos? Átláthatóvá teszi az adatok frissességét, így a felhasználók megítélhetik, mennyire aktuális a folyamatelemzés. Hol szerezhető be? Ezt az időbélyeget az adatkinyerő eszköz vagy az ETL-folyamat hozza létre és adja hozzá az adathalmazhoz a futtatáskor. Példák 2023-11-01T02:00:00Z2023-11-02T02:00:00Z
	Elutasítás oka RejectionReason	Az indok, amelyet az ellenőrző megad a naplóbejegyzés elutasításakor.
Leírás Ha a naplóbejegyzést javításra visszaküldik, a jóváhagyó általában megadja az elutasítás okát. Ez az attribútum rögzíti az indokot, amely lehet előre meghatározott kód vagy szabad szöveg. Ez az attribútum nélkülözhetetlen az újramunkálás kiváltó okainak elemzéséhez. A leggyakoribb elutasítási okok vizsgálatával a vállalat feltárhatja a rendszerszintű problémákat, például a nem megfelelő képzést, a nem egyértelmű szabályzatokat vagy az alátámasztó dokumentumok hiányosságait. Közvetlenül támogatja a „Journal Entry Rejection & Rework Analysis” dashboardot, és segít csökkenteni az elutasítások arányát. Miért fontos? Nélkülözhetetlen a folyamat újramunkálásának kiváltó okait feltáró elemzéshez: megmutatja, miért utasítják el a naplóbejegyzéseket, és segít célzott fejlesztéseket indítani. Hol szerezhető be? Ezt az adatot általában megjegyzésként vagy indokkódként rögzítik, amikor a felhasználó a „Reject” műveletet választja a BlackLine-ban. Példák Hibás főkönyvi számlakódHiányzó alátámasztó dokumentációÉrtékhatár túllépéseDuplikált bejegyzés
	Felhasználó UserName	A tevékenységet végrehajtó felhasználó neve vagy azonosítója.
Leírás Ez az attribútum azonosítja, ki hajtott végre egy adott folyamatlépést, például ki nyújtotta be, ellenőrizte vagy hagyta jóvá a naplóbejegyzést. Az érték lehet név vagy egyedi felhasználói azonosító. A felhasználónkénti elemzés segít megérteni a munkaterhelés eloszlását és az egyéni teljesítményt, valamint feltárni a képzési igényeket. Választ adhat például arra, hogy egyenletesen oszlik-e meg a munka a csapatban, vagy mely felhasználóknál tart a legtovább a jóváhagyás. A megfelelés és az auditnyomvonal elemzéséhez is nélkülözhetetlen. Miért fontos? Lehetővé teszi a munkaterhelés elemzését, a csapattagok teljesítményének összehasonlítását, valamint az erőforrásokhoz kapcsolódó szűk keresztmetszetek és képzési igények feltárását. Hol szerezhető be? Ez az adat a BlackLine auditnaplóiban található, gyakran a „User ID” vagy „Changed By” mezőben, az egyes eseményekhez rendelve. Példák j.doea.smithr.joness.patel
	Naplóbejegyzés összege JournalEntryAmount	A naplóbejegyzés teljes pénzösszege, általában a tartozik tételek összege.
Leírás Ez az attribútum a naplóbejegyzés pénzügyi értékét mutatja. Segítségével felmérhető, milyen pénzügyi hatása van a folyamat hatékonysági problémáinak, például a nagy értékű bejegyzések könyvelési késedelmének. Az érték szerinti elemzés lehetővé teszi a lényegesség figyelembevételét. Például előnyben részesíthetők a nagy értékű bejegyzésekhez kapcsolódó folyamatfejlesztések, megvizsgálható, hogy ezek más jóváhagyási útvonalat követnek-e, vagy hosszabb-e a ciklusidejük. Ez fontos üzleti szemponttal egészíti ki a folyamatmenet elemzését. Miért fontos? Pénzügyi szemponttal egészíti ki az elemzést, így a lényegesség alapján rangsorolhatók a nagy értékű bejegyzések, és feltárhatók az értékhez kötődő folyamateltérések. Hol szerezhető be? Ez a BlackLine naplóbejegyzés-fejlécének számított vagy szabványos mezője, amely a tartozik vagy követel összegét mutatja. Példák 15000.00250.75125000.50500.00
	Naplóbejegyzés státusza JournalEntryStatus	A naplóbejegyzés aktuális státusza az életciklus során, például „In Progress”, „Approved” vagy „Posted”.
Leírás Ez az attribútum az adatkinyerés időpontjában mutatja a naplóbejegyzés aktuális állapotát. Pillanatképet ad arról, hol tart a bejegyzés a teljes folyamatban. A process mining a tevékenységek alapján rekonstruálja a folyamat menetét, de a végső státusz szűréshez és összesítő dashboardok készítéséhez is hasznos. Gyorsan azonosíthatók vele a jóváhagyásra váró vagy egy adott állapotban elakadt bejegyzések, ami segíti a hátralék elemzését. Miért fontos? Pillanatképet ad a bejegyzések aktuális állapotáról, ami segíti a hátralék elemzését és a folyamatban lévő munka áttekintését. Hol szerezhető be? Ez a BlackLine naplóbejegyzésének szabványos státuszmezője. Példák FolyamatbanJóváhagyásra várJóváhagyvaKönyvelveElutasítva
	Naplóbejegyzés típusa JournalEntryType	A naplóbejegyzés besorolása, például normál, ismétlődő vagy sztornózó.
Leírás A naplóbejegyzés típusa a bejegyzéseket jellegük vagy céljuk szerint csoportosítja. Gyakori típus a normál manuális bejegyzés, a rendszer által automatikusan létrehozott bejegyzés, a hónap végi elhatárolásokhoz használt ismétlődő bejegyzés, valamint a következő időszakban automatikusan sztornózódó bejegyzés. Ez az attribútum fontos a szegmentáláshoz és az összehasonlító elemzéshez. Segítségével összevethető a különböző típusú bejegyzések folyamatának teljesítménye, például a ciklusidő vagy az elutasítási arány. Így kiderülhet, hogy egyes típusok problémásabbak vagy kevésbé hatékonyak-e, ami célzott folyamatfejlesztést tesz lehetővé. Miért fontos? Szegmentált elemzést tesz lehetővé, így megállapítható, hogy a különböző típusú naplóbejegyzések eltérő útvonalon haladnak-e, vagy más teljesítményjellemzőkkel rendelkeznek-e. Hol szerezhető be? Ez a BlackLine naplóbejegyzés-fejlécének szabványos mezője. A pontos mezőnévért tekintse meg a BlackLine dokumentációját. Példák NormálIsmétlődőSztornózóElhatárolás
	Vállalati kód CompanyCode	Annak a jogi személynek vagy vállalatnak az egyedi azonosítója, amelyhez a naplóbejegyzés készül.
Leírás A vállalati kód egy vállalatcsoporton belüli jogi személyt jelöl. A pénzügyi könyvelés alapvető szervezeti egysége, amely biztosítja, hogy a tranzakciók a megfelelő jogi személyhez kerüljenek. A process mining során a vállalati kód fontos szűrési és összehasonlítási szempont. Lehetővé teszi a folyamat teljesítményének összevetését a különböző jogi személyek között, és segít feltárni a helyi szűk keresztmetszeteket, a megfelelés eltéréseit, valamint a folyamatok egységesítésének lehetőségeit. Közvetlenül támogatja az „Approval To Posting Delay Analysis” dashboardot. Miért fontos? Lehetővé teszi a teljesítmény összehasonlítását és a folyamatok egységesítését a különböző jogi személyek vagy üzleti egységek között. Hol szerezhető be? Ez a BlackLine naplóbejegyzés-fejlécének egyik fontos mezője, amelyet gyakran az alapul szolgáló ERP-rendszerrel szinkronizálnak. Példák 1000US01DE012500
	Automatizált IsAutomated	Jelző, amely megmutatja, hogy a naplóbejegyzést automatizált folyamat hozta-e létre vagy könyvelte-e le.
Leírás Ez a logikai attribútum megkülönbözteti a felhasználók által manuálisan létrehozott és feldolgozott naplóbejegyzéseket a rendszer által automatikusan előállítottaktól, például az ismétlődő bejegyzésektől vagy a rendszerintegrációkból származóktól. Az attribútum elemzése segít felmérni az automatizálás hatékonyságát. Közvetlenül összehasonlítható az automatizált és a manuális folyamatok ciklusideje, hibaaránya és költsége. Ez alapot ad a további automatizálás üzleti indoklásához, és segít mérni a meglévő kezdeményezések megtérülését. Miért fontos? Lehetővé teszi a manuális és automatizált folyamatok közvetlen összehasonlítását, ami nélkülözhetetlen az automatizálási kezdeményezések hatásának és megtérülésének méréséhez. Hol szerezhető be? A „Journal Entry Type” mezőből, például a „Recurring” értékből, vagy a „User” mezőből származtatható, ha az automatizált könyvelésekhez rendszerfelhasználókat, például „SYSTEM” vagy „BATCH” értéket használnak. Példák truefalse
	Dokumentum csatolva IsDocumentAttached	Jelző, amely megmutatja, hogy csatoltak-e alátámasztó dokumentációt a naplóbejegyzéshez.
Leírás Ez a logikai attribútum jelzi, hogy csatoltak-e egy vagy több alátámasztó dokumentumot, például számlát vagy számítást a naplóbejegyzéshez. A jóváhagyás gyakran csak ezek megléte esetén lehetséges. Ez a jelző fontos a „Journal Entry Documentation Compliance” dashboard és a dokumentumcsatolási arány KPI szempontjából. Segít megvizsgálni, hogy a hiányzó dokumentáció gyakran okoz-e elutasítást vagy késedelmet, és támogatja azokat a szabályokat, amelyek előírják a mellékletek csatolását az ellenőrzésre történő benyújtás előtt. Miért fontos? Közvetlenül méri a dokumentációs szabályok betartását, és segít feltárni a jóváhagyási késedelmek és elutasítások gyakori kiváltó okát. Hol szerezhető be? Ez valószínűleg származtatott mező: értéke annak ellenőrzésével számítható ki, hogy a benyújtási tevékenység előtt létezik-e mellékletrekord a JournalEntryId-hez. Példák truefalse
	Egyeztetett számla AccountReconciled	A naplóbejegyzéssel egyeztetett főkönyvi számla száma.
Leírás Ez az attribútum azonosítja a számlatükör érintett vagy egyeztetendő számláját. A naplóbejegyzések gyakran a számlaegyeztetési folyamat részei, ez az attribútum pedig összekapcsolja a bejegyzést az adott számlával. Ez az attribútum közvetlenül támogatja a „Journal Entry Reconciliation Cycle Time” dashboardot. A folyamat számlánkénti elemzésével megállapítható, hogy bizonyos számlák egyeztetése rendszeresen tovább tart-e, ami az adott számlákhoz kapcsolódó összetettségre vagy adatproblémákra utalhat. Miért fontos? Összekapcsolja a naplóbejegyzési folyamatot az egyeztetett számlákkal, így célzottan elemezhetők az egyeztetés szűk keresztmetszetei. Hol szerezhető be? Ez az adat a BlackLine naplóbejegyzésének tételsoraiban található. Ha egy bejegyzés több számlát érint, az adatot esetenként az eset szintjére kell összesíteni. Példák 101000210500400100550200
	Jóváhagyás és könyvelés közötti idő ApprovalToPostingLag	A végső jóváhagyás és a naplóbejegyzés tényleges könyvelése közötti időtartam.
Leírás Ez a mutató azt a késedelmet méri, amely a naplóbejegyzés teljes jóváhagyása és főkönyvi könyvelése között telik el. A „Journal Entry Approved” és a „Journal Entry Posted” tevékenység közötti idő különbségeként számítjuk ki. Ez fontos KPI a jóváhagyás utáni szűk keresztmetszetek feltárásához, amelyek jelentősen késleltethetik a pénzügyi zárást. Az „Approval To Posting Delay Analysis” dashboard ezzel a mutatóval vizsgálja, miért nem könyvelik le időben a jóváhagyott bejegyzéseket, és segít felgyorsítani a folyamat utolsó lépéseit. Miért fontos? Kifejezetten a jóváhagyás utáni hatékonyságot méri, és segít feltárni, majd megszüntetni a pénzügyi zárást késleltető tényezőket. Hol szerezhető be? Ezt a mutatót a process mining eszköz számítja ki az egyes esetek „Journal Entry Approved” és „Journal Entry Posted” eseményei közötti időtartam alapján. Példák P0DT1H10MP1DT2H0MP0DT0H5M
	Könyvelés dátuma PostingDate	Az a dátum, amikor a naplóbejegyzést hivatalosan lekönyvelik a főkönyvbe.
Leírás A könyvelés dátuma a tranzakció pénzügyi nyilvántartásokban érvényes dátuma. A számvitel szempontjából fontos, mert meghatározza, melyik pénzügyi időszakban kell elszámolni a tranzakciót. Az esemény időbélyege azt mutatja meg, mikor történt a könyvelési művelet, maga a könyvelés dátuma pedig fontos adatattribútum. A pénzügyi elemzés során ellenőrizhető vele, hogy a bejegyzések a megfelelő időszakba kerültek-e, és elemezhető a tranzakció dátuma, a jóváhagyás dátuma és a könyvelés dátuma közötti késedelem. Miért fontos? Ez a dátum fontos a pénzügyi beszámolók pontosságához, és segít ellenőrizni, hogy a bejegyzések a megfelelő számviteli időszakba kerülnek-e. Hol szerezhető be? Ez a BlackLine naplóbejegyzés-fejlécének szabványos dátummezője. Példák 2023-10-312023-11-012023-10-30
	Pénznem Currency	A naplóbejegyzésben megadott összeg pénznemkódja.
Leírás Ez az attribútum a naplóbejegyzés összegének pénznemét adja meg, például USD, EUR vagy GBP. A tranzakciók pénzügyi értékének helyes értelmezéséhez szükséges. A több országban működő vállalatok számára a pénznem szerinti elemzés hasznos kontextust adhat. Lehetővé teszi a folyamatelemzés adott pénznemekre szűrését, és szükséges minden olyan dashboardhoz, amely pénzügyi összegeket összesít. Miért fontos? Megadja a pénzügyi összegek értelmezéséhez szükséges kontextust, és lehetővé teszi a pénznem szerinti elemzést. Hol szerezhető be? Ez a BlackLine naplóbejegyzés-fejlécének szabványos mezője, amelynek neve általában „Document Currency” vagy ehhez hasonló. Példák USDEURGBPJPY
	Részleg Department	A naplóbejegyzéshez kapcsolódó üzleti részleg vagy költséghely.
Leírás Ez az attribútum azt a részleget, költséghelyet vagy funkcionális területet jelöli, amely elindította a naplóbejegyzést, vagy amelyhez a költségeket hozzárendelik. További szervezeti kontextust ad. A részlegenkénti elemzés megmutatja, hogyan használják a vállalat különböző területei a naplóbejegyzési folyamatot. Feltárhatja a hatékonyság, a megfelelés vagy az újramunkálási arány eltéréseit, és jelezheti, hol van szükség további támogatásra vagy a folyamatok egységesítésére. Miért fontos? Lehetővé teszi a folyamat teljesítményének összehasonlítását az üzleti részlegek között, és feltárja az eltéréseket, valamint az egységesítés lehetőségeit. Hol szerezhető be? Ez az adat általában a BlackLine naplóbejegyzésének tételsoraiban vagy fejlécében található, gyakran a főkönyvi számlához kapcsolva. Példák PénzügyMarketingÉrtékesítésMűködés
	Újramunkálás történt IsRework	Számított jelző, amely akkor igaz, ha a naplóbejegyzést legalább egyszer elutasították.
Leírás Ez a logikai jelző az újramunkáláson átesett naplóbejegyzéseket azonosítja. Általában akkor kap igaz értéket, ha az esetben szerepel „Journal Entry Rejected” tevékenység, amelyet „Corrected and Resubmitted” tevékenység követ. Az attribútummal egyszerűen szűrhetők az elutasítást tapasztalt esetek, így könnyebb elemezni az újramunkálást. Alapvető a naplóbejegyzések elutasítási arányának KPI-jához, valamint a „Journal Entry Rejection & Rework Analysis” dashboard részletes vizsgálataihoz, amelyek a minőségi problémák idő- és költséghatását tárják fel. Miért fontos? Egyszerűen azonosítja az újramunkálást igénylő eseteket, így könnyebb kiszámítani az elutasítási arányt és elemezni a minőségi problémák hatását. Hol szerezhető be? Ezt a jelzőt a process mining eszköz számítja ki az egyes esetek tevékenységsorrendje alapján. Példák truefalse

Kötelező Javasolt Nem kötelező

A Record to Report naplóbejegyzési folyamat tevékenységei

Az alábbi fő folyamatlépéseket és mérföldköveket rögzítse az eseménynaplóban, hogy pontosan feltárhassa és elemezhesse a naplóbejegyzési folyamatot.

6 Javasolt 6 Nem kötelező

	Tevékenység	Leírás
	Naplóbejegyzés beküldve	Ez a tevékenység akkor történik, amikor az előkészítő hivatalosan beküldi a naplóbejegyzést az ellenőrzési és jóváhagyási munkafolyamatba. A rendszer ezt általában állapotváltozásként rögzíti, például „Előkészítés alatt” állapotból „Beküldve” állapotba, időbélyeggel együtt.
Miért fontos? Ez jelzi az előkészítési szakasz végét és a jóváhagyási ciklus kezdetét. Fontos mérföldkő az előkészítési és a jóváhagyási szakasz időtartamának méréséhez. Hol szerezhető be? Az esemény valószínűleg a BlackLine naplóbejegyzési rekordjának állapotváltozásából következtethető ki. Az esemény időpontját az az időbélyeg jelzi, amikor az állapot „Jóváhagyásra beküldve” értékre vagy hasonló értékre változik. Rögzítés A naplóbejegyzés állapotmezőjének „Beküldve” vagy „Jóváhagyásra vár” értékre történő frissítésének időbélyegéből következtethető ki. Eseménytípus inferred
	Naplóbejegyzés egyeztetve	Azt jelzi, hogy a naplóbejegyzés életciklusa lezárult: bekerült egy véglegesített és hitelesített számlaegyeztetésbe. A BlackLine-ban ez annak az egyeztetésnek a hitelesítésének felel meg, amely a naplót tartalmazza.
Miért fontos? Ez a tevékenység jelenti a teljes folyamat végpontját. A „Journal Entry Posted” és a „Reconciled” közötti idő a pénzügyi zárás számlaegyeztetési szakaszának hatékonyságát méri. Hol szerezhető be? Ez egy következtetett esemény. Akkor azonosítható, amikor a megadott naplóbejegyzést tartalmazó számlaegyeztetés státusza „Certified” értékre vált a BlackLine Account Reconciliation moduljában. Rögzítés A naplóbejegyzést összekapcsoljuk a hozzá tartozó számlaegyeztetéssel, és rögzítjük az egyeztetés hitelesítésének dátumát. Eseménytípus inferred
	Naplóbejegyzés elutasítva	Ez a tevékenység azt jelzi, hogy egy ellenőr vagy jóváhagyó elutasította a naplóbejegyzést. Akkor rögzül, amikor a felhasználó az „Elutasítás” műveletet választja. Ekkor a bejegyzés állapota „Elutasítva” értékre változik, és a művelet bekerül az auditnaplóba.
Miért fontos? Ez a tevékenység fontos az ismételt munka, a minőségi problémák és a képzési igények feltárásához. A folyamatfejlesztés és az átfutási idő csökkentése szempontjából lényeges az elutasítások gyakoriságának, okainak és az utánuk következő javítási körnek az elemzése. Hol szerezhető be? Az esemény általában a naplóbejegyzés adatainak „Elutasítva” vagy „Javítás szükséges” állapotváltozásából következtethető ki. A BlackLine előzményei rögzítik az időbélyeget és az elutasítást végrehajtó felhasználót. Rögzítés A naplóbejegyzés állapotának „Elutasítva” értékre történő frissítésekor rögzített időbélyegből következtethető ki. Eseménytípus inferred
	Naplóbejegyzés jóváhagyva	Ez a tevékenység azt jelzi, hogy a naplóbejegyzés minden szükséges ellenőrzési és jóváhagyási lépésen átment. Akkor rögzül, amikor az utolsó jogosult felhasználó jóváhagyja a bejegyzést, és a státusz „Approved” értékre vált.
Miért fontos? Ez fontos mérföldkő, amely lezárja a jóváhagyási folyamatot. A „Journal Entry Submitted” eseménytől eddig eltelt idő a jóváhagyási ciklusidő, amely a munkafolyamat hatékonyságának fontos KPI-ja. Hol szerezhető be? Az eseményre a naplóbejegyzés rekordjának „Approved” státuszra váltásából következtetünk. A végső jóváhagyó felhasználói azonosítóját és a jóváhagyás időbélyegét általában a BlackLine auditelőzményei rögzítik. Rögzítés A naplóbejegyzés „Approved” státuszra váltásának időbélyegéből következtetünk rá. Eseménytípus inferred
	Naplóbejegyzés könyvelve	Azt a pontot jelöli, amikor a jóváhagyott naplóbejegyzés hivatalosan bekerül a főkönyvbe. Ez gyakran külön művelet a BlackLine-ban, amely után a bejegyzés státusza „Posted” értékre vált.
Miért fontos? Ez fontos mérföldkő, amelyet gyakran a folyamat működési lezárásának tekintenek. A „Journal Entry Approved” esemény és e tevékenység közötti idő fontos mutatója a jóváhagyás utáni hatékonyságnak. Hol szerezhető be? Erre általában a státusz „Posted” értékre váltásából következtetünk. Az esemény külön is szerepelhet a könyvelési előzményeket tartalmazó táblában vagy az auditnaplóban, a könyvelés dátumával és időbélyegével együtt. Rögzítés A naplóbejegyzés „Posted” státuszra váltásának időbélyegéből következtetünk rá. A könyvelés dátuma is releváns. Eseménytípus inferred
	Naplóbejegyzés létrehozva	Ez a tevékenység jelzi a naplóbejegyzés esetének kezdetét. Akkor rögzül, amikor egy felhasználó új naplóbejegyzést hoz létre a BlackLine-ban. Ekkor létrejön az egyedi Naplóbejegyzés-azonosító, és a rendszer rögzíti a létrehozás időpontját, valamint a felhasználót.
Miért fontos? Ez a folyamat elsődleges kezdő eseménye. Az ettől a tevékenységtől a többi tevékenységig eltelt idő elemzésével meghatározható a teljes átfutási idő, és feltárhatók a munkafolyamat legelején jelentkező késések. Hol szerezhető be? Ezt az eseményt a BlackLine naplóbejegyzési modulja kifejezetten rögzíti. Az esemény időpontja és a felhasználó adatai minden Naplóbejegyzés-azonosítóhoz kapcsolódnak a fő naplóbejegyzési táblában vagy az auditelőzményekben. Rögzítés A naplóbejegyzés rekordjához tartozó „Létrehozás dátuma” időbélyegből rögzítve. Eseménytípus explicit
	Alátámasztó dokumentáció csatolva	Azt jelzi, hogy a felhasználó egy vagy több alátámasztó dokumentumot csatolt a naplóbejegyzéshez. Az eseményt általában az auditnapló vagy a Naplóbejegyzés-azonosítóhoz kapcsolódó mellékletek táblája rögzíti.
Miért fontos? A tevékenység követése elengedhetetlen a megfelelés és a hatékonyság nyomon követéséhez. Segít megállapítani, hogy a jóváhagyás késését a hiányzó dokumentáció okozza-e, és adatot szolgáltat a „Dokumentumcsatolási arány” KPI-hoz. Hol szerezhető be? A BlackLine rendszerint kifejezett eseményként rögzíti ezt az auditnaplóban vagy a mellékletek naplójában. Az adatok között szerepel a Naplóbejegyzés-azonosító, a fájlt csatoló felhasználó és az időbélyeg. Rögzítés Az esemény a rendszer auditnaplójában vagy egy külön mellékletelőzmény-táblában rögzül, amikor fájlt töltenek fel egy naplóbejegyzéshez. Eseménytípus explicit
	Bejegyzés javítva és újra beküldve	A naplóbejegyzés elutasítása után történik, miután az előkészítő elvégezte a szükséges javításokat, majd ismét benyújtotta a bejegyzést. Ezt a státusz „Rejected” értékről „Submitted for Approval” értékre történő visszaváltása jelzi.
Miért fontos? Ez a tevékenység segít számszerűsíteni az újramunkálásra fordított időt és ráfordítást. A „Journal Entry Rejected” esemény és e között eltelt idő az újramunkálás időtartama, amely fontos mutató a hatékonyság elemzéséhez. Hol szerezhető be? A BlackLine-adatok státuszváltozásainak sorozatából következtetünk rá. Azt kell megfigyelni, hogy ugyanahhoz a Journal Entry ID-hez tartozó státusz „Rejected” értékről „Submitted” vagy „Pending Approval” értékre vált-e. Rögzítés A „Rejected” státusz „Submitted” vagy „Pending Approval” értékre váltásából következtetünk rá. Eseménytípus inferred
	Jóváhagyás visszavonva	Ez a tevékenység azt jelzi, hogy a jóváhagyó visszavonja a korábban megadott jóváhagyást, és a naplóbejegyzés visszakerül egy korábbi állapotba. Ezt az „Approved” státuszról egy korábbi, például „In Preparation” státuszra történő váltás jelzi.
Miért fontos? Ez a ritka, de fontos tevékenység a folyamat kivételeire és azokra a lehetséges problémákra hívja fel a figyelmet, amelyek a jóváhagyás után, de a könyvelés előtt derülnek ki. Adathibára vagy a bejegyzést érintő szabályzatváltozásra utalhat. Hol szerezhető be? Ez egy következtetett esemény: az „Approved” státuszról egy még nem könyvelt, szerkeszthető státuszra történő váltás alapján azonosítható. A műveletet a BlackLine részletes auditnaplói rögzítik. Rögzítés Az „Approved” státuszról egy korábbi, például „In Preparation” vagy „Submitted” státuszra történő váltás alapján azonosítható. Eseménytípus inferred
	Könyvelés ellenőrizve	Azt jelzi, hogy a könyvelt naplóbejegyzés sikeresen megérkezett a cél-ERP-rendszerbe, és ott rögzítették. Ez történhet automatikus rendszerkapcsolaton keresztül vagy manuális visszaigazolással.
Miért fontos? Ez a tevékenység lezárja a könyvelési lépést, és biztosítja a rendszerek közötti adatok egyezőségét. A „Posted” és „Verified” közötti idő integrációs problémákra vagy a rendszerek szinkronizálásának késésére hívhatja fel a figyelmet. Hol szerezhető be? Ez lehet a rendszerintegrációs naplóban szereplő külön esemény, vagy következtethetünk rá egy olyan státuszváltozásból, mint a „Posted and Verified”. Manuális ellenőrzés esetén a felhasználó módosítja a státuszt. Rögzítés A „Verified” státuszra váltásból vagy a cél-ERP-rendszertől kapott visszaigazoló jelzőből következtetünk rá. Eseménytípus inferred
	Naplóbejegyzés ellenőrizve	Ez a többszintű jóváhagyási folyamat kijelölt ellenőr által végrehajtott hivatalos ellenőrzési lépése. A rendszer általában állapotváltozásként vagy az ellenőr műveletét rögzítő külön naplóbejegyzésként tárolja.
Miért fontos? Azoknál a szervezeteknél, ahol az ellenőrzés és a jóváhagyás külön lépés, ez a tevékenység segít azonosítani a jóváhagyási lánc szűk keresztmetszeteit. Megmutatja, mennyi ideig várnak a bejegyzések az első ellenőrzésre, illetve a végső jóváhagyásra. Hol szerezhető be? A BlackLine munkafolyamataiban ez lehet kifejezett esemény a jóváhagyási előzmények naplójában, vagy kikövetkeztethető a „Ellenőrizve” vagy „Végső jóváhagyásra vár” állapotváltozásból. A rendszer rögzíti a felhasználót és az időbélyeget. Rögzítés A naplóbejegyzés állapotának az ellenőrzési szakasz befejezését jelző változásakor rögzített időbélyegből következtethető ki. Eseménytípus inferred
	Naplóbejegyzés sztornózva	Ez a tevékenység egy korábban könyvelt naplóbejegyzést sztornózó új bejegyzés létrehozását és könyvelését rögzíti. Általában akkor indítják el, ha az eredeti bejegyzés könyvelése után hibát találnak.
Miért fontos? Ez az esemény erősen utalhat a korábbi lépésekben keletkezett adatminőségi problémákra. A sztornók arányának követése segít mérni a könyvelés utáni korrekciók arányát, és feltárni, hol van szükség nagyobb pontosságra. Hol szerezhető be? Ez gyakran külön eseményként jelenik meg: a felhasználó a BlackLine-ban a már könyvelt naplón elindítja a „Reverse” műveletet. A rendszer létrehoz egy új, sztornózó bejegyzést, amely gyakran az eredeti Journal Entry ID-hez kapcsolódik. Rögzítés A „Reverse” művelet naplózásakor, vagy akkor rögzül, amikor új naplóbejegyzés jön létre sztornójelzővel és az eredeti naplóazonosítóra mutató hivatkozással. Eseménytípus explicit

Javasolt Nem kötelező

Útmutatók az adatok kinyeréséhez

Adatok kinyerése a BlackLine rendszerből

Lépések

Jelentkezzen be a BlackLine rendszerébe olyan felhasználói fiókkal, amely hozzáfér a pénzügyi jelentésekhez.
Nyissa meg a jelentéskészítő modult. Ez általában a „Reports” > „Standard Reports” menüpont alatt található.
Keresse meg és válassza ki a „Journal Entry & Services Report” jelentést, vagy a rendelkezésre álló standard jelentések közül egy hasonló, részletes naplóbejegyzési jelentést.
Állítsa be a jelentés paramétereit. Adja meg a kinyerni kívánt „Date Range” időszakot, amely megfelel az elemzés időtartamának. Első lépésként 3–6 hónapnyi adatot javaslunk.
Szűkítse az adatokat a szükséges szűrőkkel. Legalább az érintett „Company Code(s)” értékeket adja meg. A „Journal Status” mezővel az összes releváns állapotot kiválaszthatja a létrehozástól a könyvelésig.
A kimenethez válassza ki az összes elérhető oszlopot, hogy a jelentés tartalmazza az eseménynapló létrehozásához szükséges dátum-, felhasználó- és állapotmezőket. Fontos mező például a létrehozás, a beküldés, a jóváhagyás és a könyvelés dátuma, valamint a felhasználói szerepkör.
Futtassa a jelentést a BlackLine felületén. Ha elkészült, az „Export” vagy „Download” funkcióval mentse az adatokat CSV-fájlként. A fájl neve legyen „blackline_report.csv”.
Állítson be Python-környezetet a pandas könyvtárral. Ha még nincs telepítve, futtassa ezt a parancsot: pip install pandas.
Helyezze a megadott Python-szkriptet a letöltött „blackline_report.csv” fájllal azonos mappába.
Futtassa a Python-szkriptet. A szkript beolvassa a nyers CSV-jelentést, minden üzleti tevékenységhez külön sort hoz létre, majd a szükséges formátumban elkészíti az „event_log.csv” fájlt.
Feltöltés előtt ellenőrizze az „event_log.csv” fájl adatait és teljességét.
Töltse fel a végleges „event_log.csv” fájlt a ProcessMind rendszerébe elemzésre.

Konfiguráció

Jelentés neve: Journal Entry & Services Report. A pontos elnevezés a BlackLine beállításaitól függően eltérhet.
Időszak: Első elemzéshez 3–6 hónapnyi adat kinyerését javasoljuk. A jelentés dátumszűrője általában a naplóbejegyzés létrehozásának vagy könyvelésének dátumára vonatkozik. Ellenőrizze, melyik dátummező alapján szűr a rendszer, hogy a megfelelő adathalmazt kapja.
Fő szűrők:
- Company Code: Mindig adja meg az elemzendő vállalati kódokat. Így korlátozhatja az adatmennyiséget, és az elemzés a megfelelő körre összpontosít.
- Journal Status: Válassza ki az összes állapotot, például In Preparation, Submitted, Approved, Rejected és Posted, hogy a teljes folyamatot rögzítse.
- Journal Type: Ha az elemzés hatóköre indokolja, szűrjön meghatározott naplótípusokra, például Standard vagy Recurring.
Előfeltételek: A jelentést futtató felhasználói fióknak jogosultsággal kell rendelkeznie a naplóbejegyzések megtekintéséhez és a standard jelentések futtatásához a BlackLine rendszerében. Ehhez általában Accountant vagy Reporting User szerepkör szükséges.
Teljesítmény: A hosszú időszakra vagy sok vállalati kódra kiterjedő adatok exportálása jelentős erőforrást igényelhet, és sokáig tarthat a BlackLine felületén. Teljesítményprobléma vagy időtúllépés esetén futtassa a jelentést kisebb adagokban.

Példa-lekérdezés 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.")

Lépések

Előfeltételek és beállítás: Telepítse a Python 3.6-os vagy újabb verzióját. A szükséges könyvtárakat a pip segítségével telepítse: pip install requests pandas. Kérje el a BlackLine-adminisztrátortól az API-hitelesítő adatokat (Client ID, Client Secret, Refresh Token) és a szervezet BlackLine Base URL-címét.
A szkript változóinak beállítása: Nyissa meg a Python-szkriptet, és keresse meg a konfigurációs részt. Adja meg a Client ID, Client Secret, Refresh Token értékeket és a Base URL-címet. Az adatok kinyerési időszakát a START_DATE és END_DATE változókkal állítsa be, „YYYY-MM-DD” formátumban.
Hitelesítés: A szkript elsőként meghívja a get_access_token függvényt. Ez elküldi a hitelesítő adatokat a BlackLine hitelesítési végpontjára (/api/oauth/token), és lekéri a további API-kérésekhez szükséges ideiglenes hozzáférési tokent.
A naplóbejegyzések listájának lekérése: A szkript lapozott kéréseket küld a /api/v2/journals végpontra, a megadott létrehozási dátumtartományra szűrve. Végigmegy az oldalakon, és összegyűjti a hatókörbe tartozó naplóbejegyzések alapadatait.
Részletes eseménytörténet lekérése: Az előző lépésben összegyűjtött minden Journal Entry ID-hez a szkript további két API-hívást végez. Először lekéri a naplóbejegyzés előzményeit, például a /api/v2/journals/{id}/history végpontról, hogy részletes naplót kapjon az állapotváltozásokról, jóváhagyásokról és elutasításokról. Ezután meghívja a mellékletek végpontját, például a /api/v2/journals/{id}/attachments címen, hogy megállapítsa, mikor csatoltak alátámasztó dokumentumokat.
Adatok átalakítása eseménynaplóvá: A szkript feldolgozza az API JSON-válaszait. Végigmegy a naplóbejegyzéseken, valamint a hozzájuk tartozó előzmény- és mellékletrekordokon. Az adatokat strukturált eseménynaplóvá alakítja, és mind a 12 szükséges tevékenységhez külön sort hoz létre, például „Journal Entry Created”, „Journal Entry Submitted” és „Journal Entry Approved” eseményekhez.
Állapotváltozások hozzárendelése a tevékenységekhez: A szkript az előzményeket tartalmazó végpont adatai alapján hozza létre a fő tevékenységeket. Például a „Submitted” állapotba váltást jelző előzményelem a „Journal Entry Submitted” tevékenységnek felel meg. A szkript a különböző előzményesemény-típusokat a ProcessMind által elvárt egységes tevékenységnevekhez rendeli.
DataFrame-ek létrehozása: A szkript a pandas könyvtárral hoz létre DataFrame-eket. Először a naplóbejegyzések fő listájából állítja össze a „Created” esemény DataFrame-jét. Ezután egy másik DataFrame-be rendezi az előzmény- és mellékletnaplókból származó többi tevékenységet. Végül a kettőt egyetlen, teljes eseménynaplóvá egyesíti.
Metaadatok hozzáadása és az oszlopok egységesítése: Az adatok egyesítése után a szkript hozzáadja a szükséges metaadatokat, köztük a SourceSystem mezőt, amelynek értéke rögzítetten „BlackLine”, valamint a LastDataUpdate mezőt, amely a szkript futtatásának időpontját tartalmazza. Az oszlopokat a szükséges sémához igazítja, például az API id mezőjét JournalEntryId névre módosítja.
Exportálás CSV-fájlba: Végül a szkript blackline_journal_entry_event_log.csv néven exportálja az elkészült eseménynapló DataFrame-et. A fájl formátuma lehetővé teszi, hogy közvetlenül feltöltse a ProcessMind rendszerébe.

Konfiguráció

API-hitelesítő adatok: Érvényes Client ID, Client Secret és Refresh Token szükséges a BlackLine REST API használatához. Ezeket biztonságosan tárolja, és éles környezetben ne írja be közvetlenül a szkriptekbe.
Base URL: A szkriptnek szüksége van a szervezet BlackLine API-jának egyedi alap URL-címére, például https://api.blackline.com.
Időszak: A szkript a START_DATE és END_DATE változókkal állítja be az időszakot. Első elemzéshez az elmúlt 3–6 hónap adatait javasoljuk. Ez elegendő adatot biztosít anélkül, hogy túl nagy adathalmazt kellene feldolgozni.
Lapozási korlát: A LIMIT változó határozza meg, hány rekordot kér le az API egy hívással. Az alapérték általában 100. Ennek módosítása hatással lehet a teljesítményre, ezért csak akkor térjen el az ajánlott értéktől, ha a BlackLine ügyfélszolgálata ezt javasolja.
Szükséges jogosultságok: A hitelesítő adatokhoz tartozó API-felhasználónak jogosultsággal kell rendelkeznie a naplóbejegyzések, azok előzményei és mellékletei olvasásához az elemzésbe bevont vállalati kódok esetében.
Python-környezet: A szkript futtatásához működő Python 3.6-os vagy újabb környezet szükséges, telepített requests és pandas könyvtárakkal.

Példa-lekérdezés 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()

Kezdje el most?

Használja ezt a sablont az adatok előkészítésének egyszerűsítéséhez, és tárja fel a Record to Report naplóbejegyzési folyamat működését. Tegye meg az első lépést a hatékonyság és a megfelelés javítása felé még ma.

Vissza a folyamatfejlesztési útmutatóhoz

Sablon letöltése

Javítsa még ma a Record to Report naplóbejegyzési folyamatának hatékonyságát

Rövidítse 30%-kal a naplóbejegyzések átfutási idejét, és zárjon gyorsabban, pontosabban.

Indítsa el az ingyenes próbaverziót

Bankkártya nem szükséges • Beállítás néhány perc alatt

Adatsablon a Record to Report naplóbejegyzési folyamathoz

Adatsablon a Record to Report naplóbejegyzési folyamathoz

A Record to Report naplóbejegyzési folyamat attribútumai

A Record to Report naplóbejegyzési folyamat tevékenységei

Útmutatók az adatok kinyeréséhez

BlackLine Journal Entry & Services Report exportálása

Lépések

Konfiguráció

Példa-lekérdezés python

Adatok kinyerése Python-szkripttel a BlackLine REST API-n keresztül

Lépések

Konfiguráció

Példa-lekérdezés python

Kezdje el most?

Javítsa még ma a Record to Report naplóbejegyzési folyamatának hatékonyságát