> Continue verbetering > Record to Report Journaalboeking > BlackLine > datatemplate

Uw Record to Report - Journaalboekings `Data Template`

BlackLine

Record to Report - `Attributes` Journaalboeking (20) Record to Report - Activiteiten Journaalboeking (12) Extractie Guides (2)

Uw Record to Report - Journaalboekings `Data Template`

Deze `template` biedt een uitgebreide gids voor het verzamelen van de juiste `data` voor het analyseren van uw Record to Report - Journaalboekingsproces. Het schetst essentiële `attributes` om te verzamelen, belangrijke activiteiten om te volgen, en praktische richtlijnen voor het extraheren van deze informatie uit BlackLine. Gebruik deze `resource` om ervoor te zorgen dat u alle benodigde `data` vastlegt voor effectieve `process mining`.

Aanbevolen attributen om vast te leggen
Belangrijkste activiteiten om te volgen
Richtlijnen voor data-extractie

Nieuw met event logs? Leer hoe je een process mining event log creëert.

Template downloaden

Record to Report - `Attributes` Journaalboeking

Dit zijn de aanbevolen `data`velden om op te nemen in uw `event log` voor uitgebreide analyse van uw Record to Report - Journaalboekingsproces.

5 Verplicht 6 Aanbevolen 9 Optioneel

	Naam	Omschrijving
	Activiteit ActivityName	De naam van de specifieke bedrijfs `event` die op een bepaald moment in het journaalboekingsproces plaatsvond.
Omschrijving Dit `attribute` beschrijft een enkele stap of taak die wordt uitgevoerd binnen de levenscyclus van de journaalboeking, zoals 'Journal Entry Created', 'Journal Entry Approved' of 'Journal Entry Posted'. Elke activiteit vertegenwoordigt een afzonderlijke `event` in het proces. Het analyseren van de volgorde van deze activiteiten maakt de visualisatie en het begrip van de processtroom mogelijk. Het is fundamenteel voor het ontdekken van procesvariaties, het meten van overgangstijden tussen stappen, en het identificeren van herstelwerkloops, zoals wanneer een journaalboeking wordt afgewezen en opnieuw wordt ingediend. Het belang Het definieert de stappen in het proces, wat essentieel is voor het visualiseren van de proceskaart, het analyseren van de flow en het identificeren van afwijkingen of knelpunten. Vindplaats Dit wordt doorgaans afgeleid uit `event logs`, statuswijzigingsrecords of `audit trails` binnen BlackLine. Het kan vereisen dat systeemstatuscodes worden toegewezen aan gebruikersvriendelijke activiteitsnamen. Voorbeelden Journaalpost aangemaaktJournaalpost ingediendJournaalpost goedgekeurdJournaalpost geboekt
	Journaalpost ID JournalEntryId	De unieke identificatiecode voor een enkele journaalboeking, die dient als de primaire `case`-identificatiecode voor het volgen van de levenscyclus ervan.
Omschrijving Het `Journal Entry ID` identificeert uniek elke set financiële transacties die in het grootboek is vastgelegd. Het fungeert als de centrale sleutel die alle gerelateerde activiteiten koppelt, zoals creatie, beoordeling, goedkeuring en boeking. In `process mining` is dit ID essentieel voor het correleren van alle `events` die bij één journaalboekings `case` horen. Het analyseren van de processtroom op basis van deze identificatiecode maakt de reconstructie van het end-to-end traject mogelijk, van initiatie tot definitieve afstemming, waardoor gedetailleerde analyse van cyclustijden, `knelpunten` en procesvariaties mogelijk is. Het belang Dit is de fundamentele `case`-identificatiecode, die het mogelijk maakt de volledige levenscyclus van een enkele journaalboeking te traceren en de prestaties ervan te analyseren. Vindplaats Dit is een primaire sleutel in de journaalboekingsstabellen of `data`-exports van BlackLine. Raadpleeg de BlackLine-documentatie voor de specifieke veldnaam. Voorbeelden JE2024-001234JE2024-001235JE2024-001236
	Starttijd EventTime	De precieze timestamp die aangeeft wanneer een specifieke activiteit of event heeft plaatsgevonden.
Omschrijving De `Event Time` registreert de `data` en `time` waarop een business `event` plaatsvond. Het is de chronologische ruggengraat van het proces, en bepaalt de volgorde en duur van alle activiteiten. Deze `timestamp` is cruciaal voor alle tijdgebaseerde `process mining`-analyses. Het wordt gebruikt om cyclustijden, wachttijden en duur tussen activiteiten te berekenen. Het maakt de identificatie van `knelpunten`, de analyse van prestaties over tijd, en de beoordeling van de naleving van `service level agreements` mogelijk. Het belang Deze `timestamp` is de basis voor alle prestatiestatistieken, inclusief cyclustijd- en `knelpuntanalyse`, waardoor een chronologische reconstructie van het proces mogelijk is. Vindplaats Deze informatie wordt vastgelegd in de `timestamp`velden van `event logs` of transactierecords in BlackLine. Voorbeelden 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:05:00Z
	Bronsysteem SourceSystem	Het bronsysteem waaruit de journaalboekings `data` werd geëxtraheerd.
Omschrijving Dit `attribute` identificeert het bronsysteem voor de `event data`. In deze context zal het doorgaans 'BlackLine' zijn, maar het kan ook `data` van een `upstream` ERP-systeem bevatten als het proces daar begint. Het identificeren van het bronsysteem is belangrijk voor `data governance` en voor het begrijpen van de context van het proces, vooral in omgevingen waar `data` van meerdere systemen wordt gecombineerd. Het helpt bij het oplossen van problemen met `data`-inname en het verifiëren van `data lineage`. Het belang Het biedt cruciale context voor data-oorsprong, waarborgt traceerbaarheid en helpt bij het beheren van data-integratie van verschillende platforms. Vindplaats Dit is doorgaans een statische waarde die wordt toegevoegd tijdens het data-extractie- en transformatieproces om de herkomst van de dataset te labelen. Voorbeelden BlackLineSAP S/4HANAOracle NetSuite
	Laatste data-update LastDataUpdate	De timestamp die aangeeft wanneer de data voor het laatst is ververst of geëxtraheerd uit het bronsysteem.
Omschrijving Dit `attribute` markeert de `data` en `time` van de meest recente `data pull`. Het biedt een referentiepunt voor de actualiteit van de geanalyseerde `data`, zodat gebruikers op de hoogte zijn van de actualiteit van de `data`. Dit is een cruciaal stuk `metadata` voor elk `process mining dashboard` of analyse. Het informeert gebruikers over de tijdigheid van de inzichten en helpt verwachtingen te managen over de vraag of de allernieuwste transacties in de weergave zijn opgenomen. Het belang Het waarborgt transparantie over de actualiteit van data, waardoor gebruikers kunnen begrijpen hoe actueel de procesanalyse is. Vindplaats Deze `timestamp` wordt gegenereerd en toegevoegd aan de `dataset` door de `data`-extractietool of het ETL-proces op het moment van uitvoering. Voorbeelden 2023-11-01T02:00:00Z2023-11-02T02:00:00Z
	Bedrijfscode CompanyCode	De unieke identificatiecode voor de juridische entiteit of het bedrijf waarvoor de journaalboeking wordt opgesteld.
Omschrijving De `Company Code` vertegenwoordigt een specifieke juridische entiteit binnen een bedrijvengroep. Het is een fundamentele organisatorische eenheid in financiële boekhouding, die ervoor zorgt dat transacties op de juiste entiteit worden geboekt. In `process mining` is `Company Code` een krachtige dimensie voor filtering en vergelijking. Het maakt analyse van procesprestaties over verschillende entiteiten heen mogelijk, helpt bij het identificeren van regionale of entiteitsspecifieke `knelpunten`, variaties in `compliance`, en mogelijkheden om processen wereldwijd te standaardiseren. Het ondersteunt direct het 'Approval To Posting Delay Analysis' `dashboard`. Het belang Het maakt performancevergelijking en processtandaardisatie-inspanningen mogelijk over verschillende juridische entiteiten of bedrijfsonderdelen. Vindplaats Dit is een sleutelveld op de journaalboekingsheader in BlackLine, vaak gesynchroniseerd vanuit het onderliggende ERP-systeem. Voorbeelden 1000US01DE012500
	Gebruiker UserName	De naam of `ID` van de `user` die de `activity` uitvoerde.
Omschrijving Dit `attribute` identificeert de persoon die verantwoordelijk is voor het uitvoeren van een specifieke processtap, zoals degene die een journaalboeking heeft ingediend, beoordeeld of goedgekeurd. Het kan een naam of een unieke gebruikers-ID zijn. Het analyseren van activiteiten per gebruiker is essentieel voor het begrijpen van de werkverdeling, individuele prestaties en het identificeren van trainingsmogelijkheden. Het helpt vragen te beantwoorden zoals 'Is het werk gelijkmatig verdeeld over het team?' of 'Welke gebruikers hebben de langste goedkeuringstijden?'. Het is ook cruciaal voor `compliance` en `audit trail`-analyse. Het belang Het maakt werklastanalyse, performancevergelijking tussen teamleden mogelijk en helpt bij het identificeren van resource-gerelateerde knelpunten of trainingsbehoeften. Vindplaats Deze informatie is beschikbaar in de `audit logs` van BlackLine, vaak opgeslagen als velden 'User ID' of 'Changed By' geassocieerd met elke `event`. Voorbeelden j.doea.smithr.joness.patel
	Journaalpostbedrag JournalEntryAmount	De totale monetaire waarde van de journaalboeking, doorgaans de som van de debetposten.
Omschrijving Dit `attribute` vertegenwoordigt de financiële waarde van de journaalboeking. Het kan worden gebruikt om de financiële impact van procesinefficiënties te begrijpen, zoals vertragingen bij het boeken van boekingen met hoge waarde. Het analyseren van het proces op basis van de waarde van de boeking maakt een materialiteitsanalyse mogelijk. U kunt bijvoorbeeld procesverbeteringen prioriteren voor boekingen met hoge waarde, onderzoeken of ze een ander goedkeuringspad volgen, of bepalen of hun cyclustijden langer zijn. Dit voegt een cruciale zakelijke context toe aan de processtroom. Het belang Het biedt financiële context, wat analyse op basis van materialiteit mogelijk maakt, zoals het prioriteren van hoogwaardige posten of het identificeren van waarde-gebaseerde procesafwijkingen. Vindplaats Dit is een berekend of standaardveld op de journaalboekingsheader in BlackLine, dat het totale debet- of creditbedrag vertegenwoordigt. Voorbeelden 15000.00250.75125000.50500.00
	Journaalpoststatus JournalEntryStatus	De huidige status van de journaalboeking in zijn levenscyclus, zoals 'In Progress', 'Approved' of 'Posted'.
Omschrijving Dit `attribute` geeft de huidige staat van een journaalboekings `case` aan ten tijde van `data`-extractie. Het biedt een momentopname van waar de boeking zich in het algehele proces bevindt. Hoewel `process mining` de stroom van activiteiten reconstrueert, is het hebben van de uiteindelijke status nuttig voor filtering en het creëren van overzichtelijke `dashboards` op hoog niveau. Het helpt bij het snel identificeren van alle boekingen die momenteel wachten op goedkeuring of vastzitten in een bepaalde status, wat waardevol is voor `backlog`-analyse. Het belang Het biedt een snapshot van de huidige status van posten, wat nuttig is voor backlog-analyse en het begrijpen van work-in-progress. Vindplaats Dit is een standaard statusveld op de journaalboeking in BlackLine. Voorbeelden In uitvoeringIn afwachting van goedkeuringGoedgekeurdGeboektAfgewezen
	Journaalposttype JournalEntryType	De classificatie van de journaalboeking, zoals standaard, terugkerend of tegenboeking.
Omschrijving Het Journaalposttype categoriseert posten op basis van hun aard of doel. Veelvoorkomende typen omvatten standaard handmatige posten, geautomatiseerde systeemgegenereerde posten, terugkerende posten voor maandafsluitingen of omgekeerde posten die automatisch in de volgende periode worden omgekeerd. Dit attribute is cruciaal voor segmentatie en vergelijkende analyse. Het stelt u in staat om procesperformance, zoals cycle times of afwijzingspercentages, te vergelijken tussen verschillende typen posten. Dit helpt te identificeren of bepaalde typen posten problematischer of inefficiënter zijn dan andere, wat leidt tot gerichte procesverbeteringen. Het belang Het maakt gesegmenteerde analyse mogelijk om te begrijpen of verschillende typen journaalposten verschillende paden volgen of verschillende performance kenmerken hebben. Vindplaats Dit is een standaardveld op de journaalboekingsheader in BlackLine. Raadpleeg de BlackLine-documentatie voor de exacte veldnaam. Voorbeelden StandaardTerugkerendTegenboekenAccrual
	Reden van afwijzing RejectionReason	De reden die een beoordelaar geeft wanneer een journaalboeking wordt afgewezen.
Omschrijving Wanneer een journaalboeking wordt teruggestuurd voor correcties, geeft de goedkeurder doorgaans een reden voor de afwijzing op. Dit `attribute` legt die reden vast, wat een vooraf gedefinieerde code of vrije tekst kan zijn. Dit is een cruciaal `attribute` voor grondoorzaakanalyse van herstelwerk. Door de meest voorkomende afwijzingsredenen te analyseren, kan een bedrijf systemische problemen identificeren, zoals onvoldoende training, onduidelijk beleid of problemen met ondersteunende documentatie. Dit ondersteunt direct het 'Journal Entry Rejection & Rework Analysis' `dashboard` en helpt het totale afwijzingspercentage te verminderen. Het belang Het is essentieel voor root cause analysis van proces-rework, en helpt te identificeren waarom journaalposten worden afgewezen en maakt gerichte verbeteringen mogelijk. Vindplaats Deze `data` wordt doorgaans vastgelegd in een opmerkingen- of reden-codeveld wanneer een gebruiker de actie 'Reject' uitvoert in BlackLine. Voorbeelden Incorrecte rekeningcodeOntbrekende ondersteunende documentatieOverschrijdt drempelDubbele post
	Afdeling Department	De bedrijfstak of de kostenplaats die is gekoppeld aan de journaalboeking.
Omschrijving Dit `attribute` specificeert de afdeling, kostenplaats of functioneel gebied dat de journaalboeking heeft geïnitieerd of waaraan de kosten worden toegewezen. Het biedt een extra laag van organisatorische context. Het analyseren van het proces per afdeling helpt te begrijpen hoe verschillende onderdelen van het bedrijf het journaalboekingsproces gebruiken. Het kan variaties in efficiëntie, `compliance` of herstelwerkpercentages tussen afdelingen onthullen, waardoor gebieden worden belicht die extra ondersteuning of processtandaardisatie nodig hebben. Het belang Dit maakt het mogelijk om procesprestaties te vergelijken tussen verschillende bedrijfsafdelingen, wat variaties en mogelijkheden voor standaardisatie onthult. Vindplaats Deze informatie maakt meestal deel uit van de journaalboekings `line item data` of `header data` in BlackLine, vaak gekoppeld aan de GL-rekening. Voorbeelden FinanciënMarketingVerkoopOperationele taken
	Boekingsdatum PostingDate	De datum waarop de journaalboeking officieel in het grootboek wordt geboekt.
Omschrijving De `Posting Date` is de effectieve datum van de transactie in de financiële administratie. Het is een cruciale datum voor de boekhouding, aangezien het de fiscale periode bepaalt waarin de transactie wordt erkend. Hoewel de `event timestamp` bijhoudt wanneer de boekingsactiviteit plaatsvond, is de `Posting Date` zelf een belangrijk `data attribute`. Het wordt gebruikt in financiële analyse om ervoor te zorgen dat boekingen in de juiste periode worden geboekt en kan worden gebruikt om vertragingen te analyseren tussen transactiedatum, goedkeuringsdatum en boekingsdatum. Het belang Deze datum is cruciaal voor de nauwkeurigheid van financiële rapportages en helpt analyseren of boekingen in de juiste boekingsperiode worden geboekt. Vindplaats Dit is een standaard datumveld op de journaalboekingsheader in BlackLine. Voorbeelden 2023-10-312023-11-012023-10-30
	Document Bijgevoegd IsDocumentAttached	Een flag die aangeeft of ondersteunende documentatie is bijgevoegd bij de journaalpost.
Omschrijving Dit booleaanse `attribute` geeft aan of één of meerdere ondersteunende documenten, zoals facturen of berekeningen, aan de journaalboeking zijn gekoppeld. Dit is vaak een vereiste voor goedkeuring. Deze vlag is cruciaal voor het 'Journal Entry Documentation Compliance' `dashboard` en de 'Documentation Attachment Rate' KPI. Het helpt analyseren of ontbrekende documentatie een veelvoorkomende oorzaak is voor afwijzingen of vertragingen en helpt beleid af te dwingen dat bijlagen vereist vóór indiening ter beoordeling. Het belang Het meet direct de compliance met documentatiebeleid en helpt een veelvoorkomende grondoorzaak voor goedkeuringsvertragingen en afwijzingen te diagnosticeren. Vindplaats Dit zou waarschijnlijk een afgeleid veld zijn, berekend door te controleren op het bestaan van een `attachment record` gekoppeld aan de `JournalEntryId` voordat de `submission activity` plaatsvindt. Voorbeelden truefalse
	Doorlooptijd per case CaseCycleTime	De totale duur van de journaalboekings `case` van creatie tot definitieve boekingsverificatie.
Omschrijving Dit `attribute` is een berekende metriek die de totale verstreken tijd vertegenwoordigt die een journaalboeking nodig heeft om door zijn gehele levenscyclus te gaan. Het wordt berekend als het verschil tussen de `timestamp` van de eerste activiteit (bijv. 'Journal Entry Created') en de laatste activiteit (bijv. 'Posting Verified' of 'Journal Entry Reconciled'). Dit is een primaire KPI voor het meten van de algehele procesefficiëntie. Het wordt in bijna elk `dashboard` gebruikt om een overzicht op hoog niveau van de prestaties te bieden, langlopende `cases` te identificeren en efficiëntieverbeteringen in de loop van de tijd te volgen. Het ondersteunt direct de KPI 'Average Journal Entry Cycle Time'. Het belang Dit is een fundamentele KPI voor het meten van `end-to-end` procesefficiëntie en het volgen van prestaties ten opzichte van doelen. Vindplaats Deze metriek wordt berekend binnen de `process mining` tool door de minimale `StartTime` af te trekken van de maximale `StartTime` voor elke `JournalEntryId`. Voorbeelden P2DT4H30MP0DT8H15MP5DT12H0M
	Is Geautomatiseerd IsAutomated	Een flag die aangeeft of de journaalpost is gecreëerd of geboekt door een geautomatiseerd proces.
Omschrijving Dit booleaanse `attribute` onderscheidt journaalboekingen die handmatig door gebruikers worden aangemaakt en verwerkt, en die automatisch door het systeem worden gegenereerd, zoals terugkerende boekingen of systeemintegraties. Het analyseren van dit `attribute` helpt bij het evalueren van de effectiviteit van automatisering. Het maakt een directe vergelijking mogelijk van cyclustijden, foutpercentages en kosten tussen geautomatiseerde en handmatige processen. Dit is cruciaal voor het opbouwen van een `business case` voor verdere automatisering en het meten van de ROI van bestaande initiatieven. Het belang Het maakt een directe vergelijking mogelijk tussen handmatige en geautomatiseerde processen, wat cruciaal is voor het meten van de impact en ROI van automation-initiatieven. Vindplaats Dit kan worden afgeleid van het 'Journal Entry Type' (bijv. 'Recurring') of van het veld 'User' als systeemgebruikers (bijv. 'SYSTEM' of 'BATCH') worden gebruikt voor geautomatiseerde boekingen. Voorbeelden truefalse
	Is herstelwerk IsRework	Een berekende flag die true is als de journaalpost minstens één keer is afgewezen.
Omschrijving Deze booleaanse vlag wordt berekend om journaalboekingen te identificeren die herstelwerk hebben ondergaan. Het wordt doorgaans op 'waar' gezet als een `case` een activiteit 'Journal Entry Rejected' bevat, gevolgd door een activiteit 'Corrected and Resubmitted'. Dit `attribute` vereenvoudigt de analyse van herstelwerk door gebruikers in staat te stellen gemakkelijk te filteren op alle `cases` die afwijzing hebben ervaren. Het is fundamenteel voor het berekenen van de KPI 'Journal Entry Rejection Rate' en voor `deep dives` in het 'Journal Entry Rejection & Rework Analysis' `dashboard` om de kosten- en tijdimpact van kwaliteitsproblemen te begrijpen. Het belang Het identificeert eenvoudig cases met rework, wat de berekening van afwijzingspercentages en de analyse van de impact van kwaliteitsproblemen vereenvoudigt. Vindplaats Deze vlag wordt berekend in de `process mining` tool door de volgorde van activiteiten voor elke `case` te controleren. Voorbeelden truefalse
	Rekening afgestemd AccountReconciled	Het grootboekrekeningnummer dat wordt afgestemd door de journaalboeking.
Omschrijving Dit `attribute` identificeert de specifieke rekening in het grootboek die wordt beïnvloed of afgestemd. Journaalboekingen maken vaak deel uit van het rekeningafstemmingsproces, en dit koppelt de boeking aan die specifieke rekening. Dit `attribute` ondersteunt direct het 'Journal Entry Reconciliation Cycle Time' `dashboard`. Door het proces per rekening te analyseren, is het mogelijk te identificeren of afstemmingen voor bepaalde rekeningen consequent langer duren, wat duidt op complexiteit of `data`problemen gerelateerd aan die specifieke rekeningen. Het belang Het koppelt het journaalpostproces aan de specifieke accounts die worden afgestemd, wat gerichte analyse van afstemmingsknelpunten mogelijk maakt. Vindplaats Deze informatie maakt deel uit van de journaalboekings `line item` details in BlackLine. Het moet mogelijk worden geaggregeerd naar `case`-niveau als een boeking meerdere rekeningen beïnvloedt. Voorbeelden 101000210500400100550200
	Valuta Currency	De valutacode voor het bedrag gespecificeerd in de journaalboeking.
Omschrijving Dit `attribute` specificeert de valuta van het `Journal Entry Amount`, zoals USD, EUR of GBP. Het is essentieel voor een correcte interpretatie van de financiële waarde van de transacties. Voor multinationale organisaties kan analyse per valuta nuttige context bieden. Het maakt het mogelijk de procesanalyse te filteren op specifieke valuta's en is een noodzakelijk veld voor elk `dashboard` dat financiële bedragen aggregeert. Het belang Dit biedt de nodige context voor de financiële bedragen, wat een correcte interpretatie waarborgt en analyses per valuta mogelijk maakt. Vindplaats Dit is een standaardveld op de journaalboekingsheader in BlackLine, meestal genaamd 'Document Currency' of vergelijkbaar. Voorbeelden USDEURGBPJPY
	Vertraging tussen goedkeuring en boeking ApprovalToPostingLag	De berekende duur tussen de definitieve goedkeuring en de feitelijke boeking van de journaalboeking.
Omschrijving Deze metriek meet de vertraging die optreedt nadat een journaalboeking volledig is goedgekeurd, maar voordat deze in het grootboek wordt geboekt. Het wordt berekend als het tijdsverschil tussen de activiteit 'Journal Entry Approved' en de activiteit 'Journal Entry Posted'. Dit is een kritische KPI voor het identificeren van `knelpunten` na goedkeuring, die het financiële afsluitingsproces aanzienlijk kunnen vertragen. Het 'Approval To Posting Delay Analysis' `dashboard` gebruikt deze metriek om te onderzoeken waarom goedgekeurde boekingen niet tijdig worden geboekt, wat helpt bij het stroomlijnen van de laatste stappen van het proces. Het belang Het meet specifiek de efficiëntie na goedkeuring, en helpt vertragingen te identificeren en elimineren die de snelheid van de financiële afsluiting beïnvloeden. Vindplaats Deze metriek wordt berekend binnen de `process mining` tool door de duur te vinden tussen de `events` 'Journal Entry Approved' en 'Journal Entry Posted' voor elke `case`. Voorbeelden P0DT1H10MP1DT2H0MP0DT0H5M

Verplicht Aanbevolen Optioneel

Record to Report - Activiteiten Journaalboeking

Dit zijn de belangrijkste processtappen en mijlpalen om vast te leggen in uw `event log` voor nauwkeurige ontdekking en analyse van uw journaalboekingsproces.

6 Aanbevolen 6 Optioneel

	Activiteit	Omschrijving
	Journaalpost aangemaakt	Deze activiteit markeert de start van een journaalboekings `case`. Het wordt vastgelegd wanneer een gebruiker een nieuw journaalboekingsrecord aanmaakt in BlackLine, wat een uniek `Journal Entry ID` genereert en de aanmaak `timestamp` en gebruiker vastlegt.
Het belang Dit is de primaire start `event` voor het proces. Het analyseren van de tijd van deze activiteit tot andere onthult de totale procescyclustijd en helpt vertragingen aan het begin van de `workflow` te identificeren. Vindplaats Deze `event` wordt expliciet vastgelegd in de journaalboekingsmodule van BlackLine. Het wordt vastgelegd vanuit de aanmaak `timestamp` en gebruikersdetails gekoppeld aan elk `Journal Entry ID` in de hoofdtabel voor journaalboekingen of de `audit history` ervan. Vastleggen Vastgelegd vanuit de 'Create Date' timestamp die is gekoppeld aan de journaalpostrecord. Gebeurtenistype explicit
	Journaalpost afgestemd	Markeert de voltooiing van de lifecycle waarbij de journaalpost is opgenomen in een gefinaliseerde en gecertificeerde rekeningafstemming. In BlackLine komt dit overeen met de certificering van de afstemming die deze journaalpost bevat.
Het belang Deze activiteit dient als het laatste eindpunt voor het `end-to-end` proces. De tijd van 'Journal Entry Posted' tot 'Reconciled' meet de efficiëntie van het rekeningafstemmingsgedeelte van de financiële afsluiting. Vindplaats Dit is een afgeleide `event`. Het wordt afgeleid door te identificeren wanneer de rekeningafstemming die de specifieke journaalboeking bevat, de status 'Certified' krijgt binnen de Account Reconciliation module van BlackLine. Vastleggen Afgeleid door de journaalpost te koppelen aan de bijbehorende rekeningafstemming en de certificeringsdatum van die afstemming vast te leggen. Gebeurtenistype inferred
	Journaalpost afgewezen	Deze activiteit markeert de afwijzing van een journaalboeking door een beoordelaar of goedkeurder. Het wordt vastgelegd wanneer een gebruiker de actie 'Reject' uitvoert, wat de status van de boeking bijwerkt naar 'Rejected' en wordt vastgelegd in het auditlogboek.
Het belang Dit is een cruciale activiteit voor het identificeren van herstelwerk, kwaliteitsproblemen en trainingsbehoeften. Het analyseren van afwijzingsfrequentie, redenen en de daaropvolgende `rework loop` is essentieel voor procesverbetering en het verminderen van cyclustijden. Vindplaats Dit wordt doorgaans afgeleid uit een statuswijziging naar 'Rejected' of 'Needs Correction' in de journaalboekings `data`. De `timestamp` en gebruiker die de afwijzing heeft uitgevoerd, worden vastgelegd in de historie van BlackLine. Vastleggen Afgeleid van de timestamp wanneer de status van de journaalpost wordt bijgewerkt naar 'Afgekeurd'. Gebeurtenistype inferred
	Journaalpost geboekt	Vertegenwoordigt het moment waarop de goedgekeurde journaalboeking officieel wordt vastgelegd in het grootboek. Dit is vaak een expliciete actie in BlackLine, die vervolgens de status van de boeking bijwerkt naar 'Posted'.
Het belang Dit is een cruciale mijlpaal, vaak beschouwd als de operationele conclusie van het proces. De vertragingstijd van 'Journal Entry Approved' tot deze activiteit is een belangrijke indicator voor de efficiëntie na goedkeuring. Vindplaats Dit wordt doorgaans afgeleid uit een statuswijziging naar 'Posted'. De `event` kan ook expliciet worden vastgelegd in een boekingshistorie tabel of `audit trail` met een specifieke boekingsdatum en `timestamp`. Vastleggen Afgeleid van de timestamp wanneer de status van de journaalpost wordt bijgewerkt naar 'Geboekt'. Het boekingsdatumveld is ook relevant. Gebeurtenistype inferred
	Journaalpost goedgekeurd	Deze activiteit geeft aan dat de journaalboeking alle vereiste beoordelings- en goedkeuringsstappen heeft doorlopen. Het wordt vastgelegd wanneer de uiteindelijk geautoriseerde gebruiker de boeking goedkeurt, wat een statuswijziging naar 'Approved' teweegbrengt.
Het belang Dit is een belangrijke mijlpaal die het goedkeuringsproces afsluit. De tijd van 'Journal Entry Submitted' tot deze `event` is de 'Approval Cycle Time', een kritische KPI voor het meten van `workflow`-efficiëntie. Vindplaats Deze `event` wordt afgeleid uit een statuswijziging naar 'Approved' in het journaalboekingsrecord. De gebruikers-ID van de definitieve goedkeurder en de goedkeurings `timestamp` worden doorgaans vastgelegd in de `audit history` van BlackLine. Vastleggen Afgeleid van de timestamp wanneer de status van de journaalpost wordt bijgewerkt naar 'Goedgekeurd'. Gebeurtenistype inferred
	Journaalpost ingediend	Deze activiteit vindt plaats wanneer de opsteller de journaalboeking formeel indient voor de beoordelings- en goedkeurings `workflow`. Dit wordt doorgaans vastgelegd als een statuswijziging, bijvoorbeeld van 'In Preparation' naar 'Submitted', samen met een `timestamp`.
Het belang Dit markeert het einde van de voorbereidingsfase en het begin van de goedkeuringscyclus. Het is een belangrijke mijlpaal voor het meten van de duur van zowel de voorbereidings- als de goedkeuringsfase. Vindplaats Dit wordt waarschijnlijk afgeleid uit een statuswijziging in het journaalboekingsrecord in BlackLine. De `timestamp` van de statuswijziging naar 'Submitted for Approval' of een vergelijkbare waarde markeert de `event time`. Vastleggen Afgeleid van de timestamp wanneer het statusveld van de journaalpost wordt bijgewerkt naar 'Ingediend' of 'In afwachting van goedkeuring'. Gebeurtenistype inferred
	Boeking geverifieerd	Vertegenwoordigt de bevestiging dat een geboekte journaalboeking succesvol is ontvangen en vastgelegd in het doel-ERP-systeem. Dit kan een geautomatiseerde systeem `handshake` of een handmatige bevestigingsstap zijn.
Het belang Deze activiteit geeft finaliteit aan de boekingsstap, en zorgt voor `data`-integriteit tussen systemen. De duur van 'Posted' tot 'Verified' kan integratieproblemen of vertragingen in systeemsynchronisatie aan het licht brengen. Vindplaats Dit kan een expliciete `event` zijn vanuit een systeemintegratie `log` of afgeleid uit een statuswijziging naar een waarde zoals 'Posted and Verified'. Indien handmatig, zou het een gebruikersgestuurde statusupdate zijn. Vastleggen Afgeleid van een statusupdate naar 'Geverifieerd' of van een confirmation flag ontvangen van het doel ERP-systeem. Gebeurtenistype inferred
	Goedkeuring ingetrokken	Deze activiteit vertegenwoordigt een goedkeurder die een eerder verleende goedkeuring intrekt, waardoor de journaalboeking terugkeert naar een eerdere status. Dit wordt vastgelegd door een statuswijziging van 'Approved' terug naar een eerdere status zoals 'In Preparation'.
Het belang Deze zeldzame maar belangrijke activiteit belicht procesuitzonderingen en potentiële problemen die na goedkeuring maar vóór boeking worden ontdekt. Het kan duiden op `data`fouten of beleidswijzigingen die de boeking beïnvloeden. Vindplaats Dit zou een afgeleide `event` zijn, geïdentificeerd door een statuswijziging van 'Approved' naar een niet-geboekte, bewerkbare status. Deze actie zou worden vastgelegd in de gedetailleerde `audit logs` van BlackLine. Vastleggen Geïdentificeerd door een statuswijziging van 'Goedgekeurd' terug naar een voorafgaande status zoals 'In voorbereiding' of 'Ingediend'. Gebeurtenistype inferred
	Journaalpost Annulering Verwerkt	Deze activiteit omvat het creëren en boeken van een nieuwe journaalboeking die een eerder geboekte boeking terugdraait. Dit wordt doorgaans geïnitieerd als reactie op een fout die is ontdekt nadat de oorspronkelijke boeking was geplaatst.
Het belang Deze `event` is een sterke indicator van `upstream data`kwaliteitsproblemen. Het volgen van het aantal tegenboekingen helpt bij het meten van de 'Post-Posting Adjustment Rate' en identificeert gebieden die behoefte hebben aan verbeterde nauwkeurigheid. Vindplaats Dit is vaak een expliciete `event` waarbij een gebruiker een 'Reverse'-actie initieert in BlackLine op een geboekt journaal. Het systeem creëert een nieuwe tegenboeking, vaak gekoppeld aan het oorspronkelijke `Journal Entry ID`. Vastleggen Vastgelegd wanneer een 'Reverse'-actie wordt gelogd, of wanneer een nieuwe journaalpost wordt gecreëerd met een reversal flag en een link naar de originele journal ID. Gebeurtenistype explicit
	Journaalpost beoordeeld	Vertegenwoordigt een formele beoordelingsstap in een goedkeuringsproces met meerdere niveaus, uitgevoerd door een aangewezen beoordelaar. Dit wordt doorgaans vastgelegd als een statuswijziging of een specifieke logboekvermelding die de actie van de beoordelaar aangeeft.
Het belang Voor organisaties met onderscheidende review- en goedkeuringsstappen helpt deze activiteit knelpunten binnen de goedkeuringsketen te isoleren. Het toont hoe lang posten wachten op initiële review versus definitieve goedkeuring. Vindplaats In BlackLine workflows kan dit een expliciete event zijn in het approval history log of afgeleid worden van een statuswijziging naar 'Gereviewd' of 'In afwachting van definitieve goedkeuring'. De user en timestamp worden vastgelegd. Vastleggen Afgeleid van de timestamp wanneer de status van de journaalpost verandert om de voltooiing van de reviewfase te reflecteren. Gebeurtenistype inferred
	Ondersteunende documentatie bijgevoegd	Vertegenwoordigt de actie van een gebruiker die één of meerdere ondersteunende documenten aan de journaalboeking koppelt. Deze `event` wordt doorgaans vastgelegd in een auditlogboek of een gerelateerde bijlagentabel gekoppeld aan het `Journal Entry ID`.
Het belang Het volgen van deze activiteit is cruciaal voor het monitoren van `compliance` en efficiëntie. Het helpt analyseren of vertragingen in het goedkeuringsproces worden veroorzaakt door ontbrekende documentatie en ondersteunt de 'Documentation Attachment Rate' KPI. Vindplaats Dit is doorgaans een expliciet event in BlackLine, vastgelegd in een audit trail of bijlagenlogboek. De data bevat de Journal Entry ID, de gebruiker die het bestand heeft geüpload en een timestamp. Vastleggen Event wordt gelogd in het audit trail van het systeem of een speciale attachment history table wanneer een bestand wordt geüpload tegen een journaalpost. Gebeurtenistype explicit
	Post gecorrigeerd en opnieuw ingediend	Treedt op nadat een journaalboeking is afgewezen en de opsteller de nodige correcties heeft aangebracht en deze opnieuw heeft ingediend. Dit wordt vastgelegd door een statuswijziging van 'Rejected' terug naar 'Submitted for Approval'.
Het belang Deze activiteit helpt de tijd en moeite die aan herstelwerkzaamheden zijn besteed, te kwantificeren. De duur tussen 'Journal Entry Rejected' en deze `event` vertegenwoordigt de herstelwerktijd, een belangrijke maatstaf voor efficiëntie-analyse. Vindplaats Dit wordt afgeleid door een reeks statuswijzigingen in de BlackLine `data` te observeren, specifiek een overgang van een 'Rejected' status terug naar een 'Submitted' of 'Pending Approval' status voor hetzelfde `Journal Entry ID`. Vastleggen Afgeleid van een statuswijziging van 'Afgekeurd' naar 'Ingediend' of 'In afwachting van goedkeuring'. Gebeurtenistype inferred

Aanbevolen Optioneel

Extractie Guides

Hoe u uw data uit BlackLine haalt

Stappen

Log in op uw BlackLine-instantie met een gebruikersaccount dat de benodigde rechten heeft om financiële rapportage te benaderen.
Navigeer naar de rapportagemodule. Dit vindt u doorgaans onder een menu zoals 'Rapporten' > 'Standaardrapporten'.
Zoek en selecteer het 'Journal Entry & Services Report' of een soortgelijk genoemd uitgebreid journaalpostrapport uit de lijst met beschikbare standaardrapporten.
Configureer de rapportparameters. Specificeer het gewenste 'Datumbereik' voor de extractie, wat overeenkomt met de periode die u wilt analyseren. Een periode van 3 tot 6 maanden wordt aanbevolen om mee te beginnen.
Pas de nodige filters toe om de data te verfijnen. Filter minimaal op de relevante 'Bedrijfscode(s)'. U kunt ook filteren op 'Journaalstatus' om alle relevante statussen van creatie tot boeking op te nemen.
Selecteer alle beschikbare kolommen voor de uitvoer om ervoor te zorgen dat het rapport alle benodigde datum-, gebruikers- en statusvelden bevat voor event log-generatie. Belangrijke velden zijn onder andere de creatiedatum, indieningsdatum, goedkeuringsdatum, boekingsdatum en gebruikersrollen.
Voer het rapport rechtstreeks uit in de BlackLine UI. Zodra het rapport is gegenereerd, gebruikt u de functie 'Exporteren' of 'Downloaden' om de data op te slaan als een CSV-bestand. Noem het 'blackline_report.csv'.
Zet een Python-omgeving op met de pandas library geïnstalleerd. Als u deze niet heeft, installeer deze dan met het commando: pip install pandas.
Plaats het meegeleverde Python-script in dezelfde map als uw gedownloade 'blackline_report.csv' bestand.
Voer het Python-script uit. Het script leest het ruwe CSV-rapport, transformeert de data door een afzonderlijke rij voor elke bedrijfsactiviteit te creëren, en genereert een nieuw bestand genaamd 'event_log.csv' in het vereiste formaat.
Voer validatiecontroles uit op het 'event_log.csv' bestand om de data quality en volledigheid te waarborgen voordat u uploadt.
Upload het definitieve 'event_log.csv' bestand naar ProcessMind voor analyse.

Configuratie

Rapportnaam: Journal Entry & Services Report. De exacte naam kan variëren afhankelijk van uw BlackLine-configuratie.
Datumbereik: Het wordt aanbevolen om 3-6 maanden aan data te extraheren voor een initiële analyse. Het datumfilter in het rapport is doorgaans van toepassing op de creatiedatum of boekingsdatum van de journaalpost. Verduidelijk welk datumveld wordt gebruikt voor filtering om ervoor te zorgen dat de juiste dataset wordt geëxtraheerd.
Belangrijke Filters:
- Bedrijfscode: Specificeer altijd de bedrijfscodes die u wilt analyseren om het datavolume te beperken en de analyse te focussen.
- Journaalstatus: Selecteer alle statussen (bijv. In voorbereiding, Ingediend, Goedgekeurd, Afgewezen, Geboekt) om het complete end-to-end proces vast te leggen.
- Journaaltype: Filter op specifieke journaaltypen (bijv. Standaard, Terugkerend) indien nodig voor de analyse.
Vereisten: Het gebruikersaccount dat het rapport uitvoert, moet rechten hebben om journaalpostdata te bekijken en standaardrapporten binnen BlackLine uit te voeren. Dit vereist doorgaans een rol zoals 'Accountant' of 'Rapportagegebruiker'.
Prestatieoverwegingen: Het exporteren van een grote dataset over een lange periode of talrijke bedrijfscodes kan resource-intensief zijn en kan aanzienlijk veel tijd kosten om te genereren in de BlackLine UI. Overweeg het rapport in kleinere batches uit te voeren als u prestatieproblemen of timeouts ondervindt.

a Voorbeeldquery config

import pandas as pd
import numpy as np
import datetime

# --- Configuration ---
# Define the input file name from BlackLine
input_filename = 'blackline_report.csv'
# Define the output file for ProcessMind
output_filename = 'event_log.csv'

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

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

# Rename columns based on the mapping
df = df_raw.rename(columns=column_mapping)

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

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

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

# --- Activity Extraction ---

# 1. Journal Entry Created
event_created = df[df['CreationTimestamp'].notna()].copy()
event_created['ActivityName'] = 'Journal Entry Created'
event_created['EventTime'] = event_created['CreationTimestamp']
event_created['UserName'] = event_created.get('PreparerUserName')
all_events.append(event_created)

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

# 3. Journal Entry Submitted
event_submitted = df[df['SubmissionTimestamp'].notna()].copy()
event_submitted['ActivityName'] = 'Journal Entry Submitted'
event_submitted['EventTime'] = event_submitted['SubmissionTimestamp']
event_submitted['UserName'] = event_submitted.get('SubmitterUserName')
all_events.append(event_submitted)

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

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

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

# 7. Journal Entry Approved
event_approved = df[df['ApprovalTimestamp'].notna()].copy()
event_approved['ActivityName'] = 'Journal Entry Approved'
event_approved['EventTime'] = event_approved['ApprovalTimestamp']
event_approved['UserName'] = event_approved.get('ApproverUserName')
all_events.append(event_approved)

# 8. Approval Rescinded
if 'RescindTimestamp' in df.columns:
    event_rescinded = df[df['RescindTimestamp'].notna()].copy()
    event_rescinded['ActivityName'] = 'Approval Rescinded'
    event_rescinded['EventTime'] = event_rescinded['RescindTimestamp']
    event_rescinded['UserName'] = event_rescinded.get('ApproverUserName')
    all_events.append(event_rescinded)

# 9. Journal Entry Posted
event_posted = df[df['PostingTimestamp'].notna()].copy()
event_posted['ActivityName'] = 'Journal Entry Posted'
event_posted['EventTime'] = event_posted['PostingTimestamp']
event_posted['UserName'] = event_posted.get('PosterUserName')
all_events.append(event_posted)

# 10. Posting Verified
if 'VerificationTimestamp' in df.columns:
    event_verified = df[df['VerificationTimestamp'].notna()].copy()
    event_verified['ActivityName'] = 'Posting Verified'
    event_verified['EventTime'] = event_verified['VerificationTimestamp']
    event_verified['UserName'] = event_verified.get('VerifierUserName')
    all_events.append(event_verified)

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

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


# --- Final Assembly ---
if all_events:
    event_log = pd.concat(all_events, ignore_index=True)

    # Add required constant value attributes
    event_log['SourceSystem'] = 'BlackLine'
    event_log['LastDataUpdate'] = last_data_update

    # Select and order columns for the final output
    final_columns = [
        'JournalEntryId',
        'ActivityName',
        'EventTime',
        'SourceSystem',
        'LastDataUpdate',
        'UserName',
        'JournalEntryType',
        'CompanyCode',
        'JournalEntryAmount',
        'JournalEntryStatus',
        'RejectionReason'
    ]

    # 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]

    # Sort the event log
    event_log = event_log.sort_values(by=['JournalEntryId', 'EventTime'])

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

Stappen

Vereisten en Setup: Zorg ervoor dat u Python 3.6 of nieuwer hebt geïnstalleerd. Installeer de benodigde libraries met pip: pip install requests pandas. Verkrijg API credentials (Client ID, Client Secret, Refresh Token) en de BlackLine Base URL van uw organisatie via uw BlackLine-administrator.
Configureer Script Variabelen: Open het Python script en zoek het configuratiegedeelte. Voer uw Client ID, Client Secret, Refresh Token en de Base URL in. Definieer de extractieperiode door de variabelen START_DATE en END_DATE in te stellen in het formaat 'YYYY-MM-DD'.
Authenticatie: Het script begint met het aanroepen van de functie get_access_token. Deze functie stuurt uw credentials naar het BlackLine authenticatie-endpoint (/api/oauth/token) en haalt een tijdelijke access token op die nodig is voor alle volgende API-aanvragen.
Haal Initiële Journaallijst op: Het script doet een gepagineerde aanvraag naar het /api/v2/journals endpoint, filterend op het opgegeven creatiedatumbereik. Het doorloopt de pagina's en verzamelt de primaire details voor alle journaalposten die binnen het bereik vallen.
Haal Gedetailleerde Event History op: Voor elke Journaalpost ID die in de vorige stap is verzameld, doet het script twee aanvullende API-aanroepen. Ten eerste bevraagt het het history-endpoint van de journaalpost (bijv. /api/v2/journals/{id}/history) om een gedetailleerd audit trail van statuswijzigingen, goedkeuringen en afwijzingen te verkrijgen. Ten tweede roept het het attachments-endpoint aan (bijv. /api/v2/journals/{id}/attachments) om te identificeren wanneer ondersteunende documenten zijn toegevoegd.
Transformeer Data naar een Event Log: Het script verwerkt de JSON-responses van de API. Het itereert door elke journaalpost en de bijbehorende history- en attachment-records. Het mapt de ruwe data naar een gestructureerd event log-formaat, waarbij een afzonderlijke rij wordt gecreëerd voor elk van de 12 vereiste activiteiten, zoals 'Journaalpost Gecreëerd', 'Journaalpost Ingediend' en 'Journaalpost Goedgekeurd'.
Map Statuswijzigingen naar Activiteiten: Belangrijke activiteiten worden gegenereerd door de data van het history-endpoint te interpreteren. Een history-item dat een statuswijziging naar 'Submitted' aangeeft, wordt bijvoorbeeld de activiteit 'Journaalpost Ingediend'. Het script bevat logica om verschillende history event types te mappen naar de gestandaardiseerde activiteitsnamen die door ProcessMind vereist zijn.
Construeer DataFrames: Het script gebruikt de pandas library om DataFrames te bouwen. Eerst creëert het een DataFrame voor de 'Created' event uit de hoofdlijst van journaalposten. Vervolgens creëert het een ander DataFrame dat alle andere activiteiten bevat die zijn afgeleid van de history- en attachment logs. Deze worden vervolgens gecombineerd tot een enkele, uitgebreide event log.
Voeg Metadata toe en Standaardiseer Kolommen: Na het combineren van de data voegt het script vereiste metadata-kolommen toe, waaronder SourceSystem (hardcoded als 'BlackLine') en LastDataUpdate (ingesteld op de uitvoeringstijd van het script). Het hernoemt ook kolommen om te matchen met het vereiste schema, bijvoorbeeld door het id-veld van de API te mappen naar JournalEntryId.
Exporteer naar CSV: Tot slot exporteert het script de voltooide event log DataFrame naar een CSV-bestand genaamd blackline_journal_entry_event_log.csv. Dit bestand is geformatteerd en klaar voor directe upload naar ProcessMind.

Configuratie

API Credentials: U moet een geldige Client ID, Client Secret en Refresh Token hebben voor de BlackLine REST API. Deze moeten veilig worden opgeslagen en niet rechtstreeks in productiescripts worden hardcoded.
Base URL: Het script vereist de specifieke BlackLine API basis-URL van uw organisatie, bijvoorbeeld https://api.blackline.com.
Datumbereik: Het script is geconfigureerd met de variabelen START_DATE en END_DATE. Voor een initiële analyse wordt een datumbereik van de laatste 3 tot 6 maanden aan activiteit aanbevolen om voldoende data te bieden zonder overmatig groot te zijn.
Pagination Limit: De variabele LIMIT bepaalt hoeveel records per API-aanroep worden opgehaald. De standaardwaarde is doorgaans 100. Het aanpassen hiervan kan prestatie-implicaties hebben, dus het is het beste om het op de aanbevolen waarde te laten, tenzij anders geadviseerd door BlackLine support.
Vereiste Rechten: De API-gebruiker die aan de credentials is gekoppeld, moet voldoende rechten hebben om journaalposten, journaalhistorie en bijlagen te lezen voor de bedrijfscodes die u wilt analyseren.
Python Omgeving: Een functionele Python 3.6+ omgeving met de geïnstalleerde requests en pandas libraries is een vereiste voor het uitvoeren van het script.

a Voorbeeldquery 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()

Uw Record to Report - Journaalboekings `Data Template`

Uw Record to Report - Journaalboekings `Data Template`

Record to Report - `Attributes` Journaalboeking

Record to Report - Activiteiten Journaalboeking

Extractie Guides

BlackLine Journal Entry & Services Report Export

Stappen

Configuratie

a Voorbeeldquery config

Python-scriptextractie via BlackLine REST API

Stappen

Configuratie

a Voorbeeldquery python

Klaar om te starten?

Optimaliseer vandaag nog de efficiëntie van Record to Report-journaalboekingen

Uw Record to Report - Journaalboekings Data Template

Uw Record to Report - Journaalboekings Data Template

Record to Report - Attributes Journaalboeking

Record to Report - Activiteiten Journaalboeking

Extractie Guides

BlackLine Journal Entry & Services Report Export

Stappen

Configuratie

a Voorbeeldquery config

Python-scriptextractie via BlackLine REST API

Stappen

Configuratie

a Voorbeeldquery python

Wij hechten veel waarde aan je privacy

Klaar om te starten?

Optimaliseer vandaag nog de efficiëntie van Record to Report-journaalboekingen

Uw Record to Report - Journaalboekings `Data Template`

Uw Record to Report - Journaalboekings `Data Template`

Record to Report - `Attributes` Journaalboeking