> Continue procesverbetering > Record to report Journaalboekingen > BlackLine > Datatemplate

Uw Record to report - Journaalboekingens `datatemplate`

BlackLine

Record to report - `Attributen` Journaalboekingen (19) Record to report - Activiteiten Journaalboekingen (12) Extractiegidsen (2)

Uw Record to report - Journaalboekingens `datatemplate`

Deze template biedt een volledige gids voor het verzamelen van de juiste `data` voor het analyseren van je Record to report - Journaalboekingensproces. Het schetst essentiële `attributen` om te verzamelen, belangrijke activiteiten om te volgen, en praktische richtlijnen voor het extraheren van deze Informatie uit BlackLine. Gebruik deze `bron` om ervoor te zorgen dat je 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 - `Attributen` Journaalboekingen

Dit zijn de aanbevolen `data`velden om op te nemen in uw `event log` voor grondige analyse van uw Record to report - Journaalboekingensproces.

5 Verplicht 6 Aanbevolen 8 Optioneel

	Naam	Beschrijving
	Activiteit ActivityName	De naam van de specifieke bedrijfs `gebeurtenis` die op een bepaald moment in het journaalboekingsproces plaatsvond.
Beschrijving Dit `attribuut` 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 `gebeurtenis` in het proces. Het analyseren van de volgorde van deze activiteiten maakt de visualisatie en het begrip van de processtroom mogelijk. Het is onmisbaar voor het bekijken van procesvariaties, het meten van overgangstijden tussen stappen, en het vinden van herstelwerkloops, zoals wanneer een journaalboeking wordt afgewezen en opnieuw wordt ingediend. Waarom het belangrijk is Het definieert de stappen in het proces, wat belangrijk is voor het visualiseren van de proceskaart, het analyseren van de flow en het vinden van afwijkingen of knelpunten. Waar te verkrijgen Dit wordt doorgaans afgeleid uit `event logs`, statuswijzigings of `audit trails` binnen BlackLine. Het kan vereisen dat systeemstatuscodes worden toegewezen aan gebruikersvriendelijke activiteitsnamen. Voorbeelden Journaalboekingen aangemaaktJournaalboekingen ingediendJournaalboekingen goedgekeurdJournaalboekingen geboekt
	Journaalboekingen ID JournalEntryId	De unieke ID voor een enkele journaalboeking, die dient als de primaire `case`-ID voor het volgen van de levenscyclus ervan.
Beschrijving Het `Journal Entry ID` identificeer jeniek 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 belangrijk voor het correleren van alle `gebeurtenissen` die bij één journaalboekings `case` horen. Het analyseren van de processtroom op basis van deze ID 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. Waarom het belangrijk is Dit is de fundamentele `case`-ID, die het mogelijk maakt de volledige levenscyclus van een enkele journaalboeking te traceren en de prestaties ervan te analyseren. Waar te verkrijgen Dit is een primary key 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 gebeurtenis heeft plaatsgevonden.
Beschrijving De `Event Time` registreert de `data` en `time` waarop een business `gebeurtenis` plaatsvond. Het is de chronologische basis van het proces, en bepaalt de volgorde en duur van alle activiteiten. Deze `timestamp` is belangrijk voor alle tijdgebonden `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. Waarom het belangrijk is Deze `timestamp` is de basis voor alle prestatiestatistieken, inclusief cyclustijd- en `knelpuntanalyse`, waardoor een chronologische reconstructie van het proces mogelijk is. Waar te verkrijgen Deze Informatie wordt vastgelegd in de `timestamp`velden van `event logs` of transacpakketecords 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 opgehaald.
Beschrijving Dit `attribuut` identificeert het bronsysteem voor de `gebeurtenis 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 vinden 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`. Waarom het belangrijk is Het biedt belangrijke context voor herkomst van de data, waarborgt traceerbaarheid en helpt bij het beheren van data-integratie van verschillende platforms. Waar te verkrijgen Dit is meestal een statische waarde die je toevoegt tijdens het data-extractie- en transformatieproces om de herkomst van de dataset te labelen. Voorbeelden BlackLineSAP S/4HANAOracle NetSuite
	Tijdstip van extractie LastDataUpdate	De timestamp die aangeeft wanneer de data voor het voor het laatst is bijgewerkt of opgehaald uit het bronsysteem.
Beschrijving Dit `attribuut` markeert de `data` en `time` van de meest recente `data-extractie`. Het biedt een referentiepunt voor de relevantie van de geanalyseerde `data`, zodat gebruikers op de hoogte zijn van de relevantie van de `data`. Dit is een belangrijk stuk `metadata` voor elk `process mining dashboard` of analyse. Het Informapakketmeert gebruikers door de tijd heenigheid van de inzichten en helpt verwachtingen te managen over de vraag of de allernieuwste transacties in de weergave zijn opgenomen. Waarom het belangrijk is Het waarborgt transparantie over de relevantie van data, waardoor gebruikers begrijpen hoe actueel de procesanalyse is. Waar te verkrijgen 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 ID voor de juridische entiteit of het bedrijf waarvoor de journaalboeking wordt opgesteld.
Beschrijving De `Company Code` vertegenwoordigt een specifieke juridische entiteit binnen een bedrijvengroep. Het is een fundamentele onderdeel in financiële boekhouding, die ervoor zorgt dat transacties op de juiste entiteit worden geboekt. In `process mining` is `Company Code` een waardevolle factor voor filtering en vergelijking. Het maakt analyse van procesprestaties over verschillende entiteiten heen mogelijk, helpt bij het vinden 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`. Waarom het belangrijk is Het maakt prestatiesvergelijking en processtandaardisatie-inspanningen mogelijk over verschillende juridische entiteiten of bedrijfsonderdelen. Waar te verkrijgen Dit is een sleutelveld op de journaalboekingsheader in BlackLine, vaak gesynchroniseerd vanuit het onderliggende ERP-systeem. Voorbeelden 1000US01DE012500
	Gebruiker UserName	De naam of het ID van de gebruiker die de activiteit uitvoerde.
Beschrijving Dit `attribuut` 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 belangrijk voor het begrijpen van de werkverdeling, individuele prestaties en het vinden 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 belangrijk voor `compliance` en `audit trail`-analyse. Waarom het belangrijk is Het maakt werklastanalyse, prestatiesvergelijking tussen teamleden mogelijk en helpt bij het vinden van brongerelateerde knelpunten of trainingsbehoeften. Waar te verkrijgen Deze Informatie is beschikbaar in de `auditlogs` van BlackLine, vaak opgeslagen als velden 'Gebruiker ID' of 'Changed By' geassocieerd met elke `gebeurtenis`. Voorbeelden j.doea.smithr.joness.patel
	Journaalboekingenbedrag JournalEntryAmount	De totale financiële waarde van de journaalboeking, doorgaans de som van de debetposten.
Beschrijving Dit `attribuut` 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 hoogwaardige. Het analyseren van het proces op basis van de waarde van de boeking maakt een materialiteitsanalyse mogelijk maken. U kunt bijvoorbeeld procesverbeteringen prioriteren voor boekingen met hoogwaardige, onderzoeken of ze een ander goedkeuringspad volgen, of bepalen of hun cyclustijden langer zijn. Dit voegt een belangrijke zakelijke context toe aan de processtroom. Waarom het belangrijk is Het biedt financiële context, wat analyse op basis van materialiteit mogelijk maakt, zoals het prioriteren van hoogwaardige posten of het vinden van waarde-gebaseerde procesafwijkingen. Waar te verkrijgen Dit is een berekend of standaardveld op de journaalboekingsheader in BlackLine, dat het totale debet- of creditbedrag vertegenwoordigt. Voorbeelden 15000.00250.75125000.50500.00
	Journaalboekingenstatus JournalEntryStatus	De huidige status van de journaalboeking in zijn levenscyclus, zoals 'In Progress', 'Approved' of 'Posted'.
Beschrijving Dit `attribuut` 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 vinden van alle boekingen die momenteel wachten op goedkeuring of vastzitten in een bepaalde status, wat waardevol is voor `backlog`-analyse. Waarom het belangrijk is Het biedt een momentopname van de huidige status van posten, wat nuttig is voor backlog-analyse en het begrijpen van work-in-progress. Waar te verkrijgen Dit is een standaard statusveld op de journaalboeking in BlackLine. Voorbeelden In uitvoeringIn afwachting van goedkeuringGoedgekeurdGeboektAfgewezen
	Journaalboekingentype JournalEntryType	De classificatie van de journaalboeking, zoals standaard, terugkerend of tegenboeking.
Beschrijving Het Journaalboekingentype 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 attribuut is belangrijk voor segmentatie en vergelijkende analyse. Het stelt je in staat om procesprestaties, zoals doorlooptijden of afwijzingspercentages, te vergelijken tussen verschillende typen posten. Dit helpt te vinden of bepaalde typen posten problematischer of inefficiënter zijn dan andere, wat leidt tot gerichte procesverbeteringen. Waarom het belangrijk is Het maakt gesegmenteerde analyse mogelijk om te begrijpen of verschillende typen journaalposten verschillende paden volgen of verschillende prestaties kenmerken hebben. Waar te verkrijgen 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.
Beschrijving Wanneer een journaalboeking wordt teruggestuurd voor correcties, geeft de goedkeurder doorgaans een reden voor de afwijzing op. Dit `attribuut` legt die reden vast, wat een vooraf gedefinieerde code of vrije tekst kan zijn. Dit is een belangrijk `attribuut` voor grondoorzaakanalyse van herstelwerk. Door de meest voorkomende afwijzingsredenen te analyseren, kan een bedrijf systemische problemen vinden, 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. Waarom het belangrijk is Het is belangrijk voor oorzaakanalyse van proces-herstelwerk, en helpt te vinden waarom journaalposten worden afgewezen en maakt gerichte verbeteringen mogelijk. Waar te verkrijgen 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.
Beschrijving Dit `attribuut` 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 zichtbaar maken, waardoor gebieden worden belicht die extra ondersteuning of processtandaardisatie nodig hebben. Waarom het belangrijk is Dit maakt het mogelijk om procesprestaties te vergelijken tussen verschillende bedrijfsafdelingen, wat variaties en mogelijkheden voor standaardisatie onthult. Waar te verkrijgen 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.
Beschrijving De `Posting Date` is de effectieve datum van de transactie in de financiële administratie. Het is een belangrijke datum voor de boekhouding, aangezien het de fiscale periode bepaalt waarin de transactie wordt erkend. Hoewel de `gebeurtenis timestamp` bijhoudt wanneer de boekingsactiviteit plaatsvond, is de `Posting Date` zelf een belangrijk `data attribuut`. 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. Waarom het belangrijk is Deze datum is belangrijk voor de nauwkeurigheid van financiële rapportages en helpt analyseren of boekingen in de juiste boekingsperiode worden geboekt. Waar te verkrijgen 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.
Beschrijving Dit booleaanse `attribuut` 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 belangrijk 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. Waarom het belangrijk is Het meet direct de naleving van documentatiebeleid en helpt een veelvoorkomende grondoorzaak voor goedkeuringsvertragingen en afwijzingen te diagnosticeren. Waar te verkrijgen 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
	Is Geautomatiseerd IsAutomated	Een flag die aangeeft of de journaalpost is gecreëerd of geboekt door een geautomatiseerd proces.
Beschrijving Dit booleaanse `attribuut` 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 `attribuut` helpt bij het ewaarderen van de effectiviteit van automatisering. Het maakt een directe vergelijking mogelijk van cyclustijden, foutpercentages en kosten tussen geautomatiseerde en handmatige processen. Dit is belangrijk voor het opbouwen van een `business case` voor verdere automatisering en het meten van de ROI van bestaande initiatieven. Waarom het belangrijk is Het maakt een directe vergelijking mogelijk tussen handmatige en geautomatiseerde processen, wat belangrijk is voor het meten van de impact en ROI van automatisering-initiatieven. Waar te verkrijgen Dit kan worden afgeleid van het 'Journal Entry Type' (bijv. 'Recurring') of van het veld 'Gebruiker' 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.
Beschrijving Deze booleaanse vlag wordt berekend om journaalboekingen te vinden 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 `attribuut` vereenvoudigt de analyse van herstelwerk door gebruikers in staat te stellen gemakkelijk te filteren op alle `cases` die afwijzing hebben ervaren. Het is onmisbaar 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. Waarom het belangrijk is Het identificeert eenvoudig cases met herstelwerk, wat de berekening van afwijzingspercentages en de analyse van de impact van kwaliteitsproblemen vereenvoudigt. Waar te verkrijgen 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.
Beschrijving Dit `attribuut` identificeert de specifieke rekening in het grootboek die wordt beïnvloed of afgestemd. Journaalboekingenen maken vaak deel uit van het rekeningafstemmingsproces, en dit koppelt de boeking aan die specifieke rekening. Dit `attribuut` ondersteunt direct het 'Journal Entry Reconciliation Cycle Time' `dashboard`. Door het proces per rekening te analyseren, is het mogelijk te vinden of afstemmingen voor bepaalde rekeningen consequent langer duren, wat duidt op complexiteit of `data`problemen gerelateerd aan die specifieke rekeningen. Waarom het belangrijk is Het koppelt het journaalpostproces aan de specifieke accounts die worden afgestemd, wat gerichte analyse van afstemmingsknelpunten mogelijk maakt. Waar te verkrijgen 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.
Beschrijving Dit `attribuut` specificeert de valuta van het `Journal Entry Bedrag`, zoals USD, EUR of GBP. Het is belangrijk 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. Waarom het belangrijk is Dit biedt de nodige context voor de financiële bedragen, wat een correcte interpretatie waarborgt en analyses per valuta mogelijk maakt. Waar te verkrijgen Dit is een standaardveld op de journaalboekingsheader in BlackLine, meestal genaamd 'Document Valuta' of vergelijkbaar. Voorbeelden USDEURGBPJPY
	Vertraging tussen goedkeuring en boeking ApprovalToPostingLag	De berekende duur tussen de definitieve goedkeuring en de feitelijke boeking van de journaalboeking.
Beschrijving 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 vinden 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 optimaliseren van de laatste stappen van het proces. Waarom het belangrijk is Het meet specifiek de efficiëntie na goedkeuring, en helpt vertragingen te vinden en elimineren die de snelheid van de financiële afsluiting beïnvloeden. Waar te verkrijgen Deze metriek wordt berekend binnen de `process mining` tool door de duur te vinden tussen de `gebeurtenissen` 'Journal Entry Approved' en 'Journal Entry Posted' voor elke `case`. Voorbeelden P0DT1H10MP1DT2H0MP0DT0H5M

Verplicht Aanbevolen Optioneel

Record to report - Activiteiten Journaalboekingen

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

6 Aanbevolen 6 Optioneel

	Activiteit	Beschrijving
	Journaalboekingen 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.
Waarom het belangrijk is Dit is de primaire start `gebeurtenis` 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 vinden. Waar te verkrijgen Deze `gebeurtenis` 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
	Journaalboekingen afgestemd	Markeert de voltooiing van de levenscyclus 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.
Waarom het belangrijk is 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. Waar te verkrijgen Dit is een afgeleide `gebeurtenis`. Het wordt afgeleid door te vinden 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
	Journaalboekingen 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.
Waarom het belangrijk is Dit is een belangrijke activiteit voor het vinden van herstelwerk, kwaliteitsproblemen en trainingsbehoeften. Het analyseren van afwijzingsfrequentie, redenen en de daaropvolgende `herstelwerk loop` is belangrijk voor procesverbetering en het verminderen van cyclustijden. Waar te verkrijgen 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
	Journaalboekingen 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'.
Waarom het belangrijk is Dit is een belangrijke 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. Waar te verkrijgen Dit wordt doorgaans afgeleid uit een statuswijziging naar 'Posted'. De `gebeurtenis` 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
	Journaalboekingen 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.
Waarom het belangrijk is Dit is een belangrijke mijlpaal die het goedkeuringsproces afsluit. De tijd van 'Journal Entry Submitted' tot deze `gebeurtenis` is de 'Approval Cycle Time', een kritische KPI voor het meten van `workflow`-efficiëntie. Waar te verkrijgen Deze `gebeurtenis` 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
	Journaalboekingen 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`.
Waarom het belangrijk is 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. Waar te verkrijgen 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 `gebeurtenis 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.
Waarom het belangrijk is 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 inzichtelijk maken. Waar te verkrijgen Dit kan een expliciete `gebeurtenis` 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'.
Waarom het belangrijk is Deze zeldzame maar belangrijke activiteit belicht procesuitzonderingen en potentiële problemen die na goedkeuring maar vóór boeking worden bekijkt. Het kan duiden op `data`fouten of beleidswijzigingen die de boeking beïnvloeden. Waar te verkrijgen Dit zou een afgeleide `gebeurtenis` zijn, geïdentificeerd door een statuswijziging van 'Approved' naar een niet-geboekte, bewerkbare status. Deze actie zou worden vastgelegd in de gedetailleerde `auditlogs` van BlackLine. Vastleggen Geïdentificeerd door een statuswijziging van 'Goedgekeurd' terug naar een voorafgaande status zoals 'In voorbereiding' of 'Ingediend'. Gebeurtenistype inferred
	Journaalboekingen 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 bekijkt nadat de oorspronkelijke boeking was geplaatst.
Waarom het belangrijk is Deze `gebeurtenis` 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. Waar te verkrijgen Dit is vaak een expliciete `gebeurtenis` 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 herkomstele journal ID. Gebeurtenistype explicit
	Journaalboekingen 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.
Waarom het belangrijk is 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. Waar te verkrijgen In BlackLine workflows kan dit een expliciete gebeurtenis 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 `gebeurtenis` wordt doorgaans vastgelegd in een auditlogboek of een gerelateerde bijlagentabel gekoppeld aan het `Journal Entry ID`.
Waarom het belangrijk is Het volgen van deze activiteit is belangrijk 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. Waar te verkrijgen Dit is doorgaans een expliciet gebeurtenis 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'.
Waarom het belangrijk is Deze activiteit helpt de tijd en moeite die aan rework zijn besteed, te kwantificeren. De duur tussen 'Journal Entry Rejected' en deze `gebeurtenis` vertegenwoordigt de herstelwerktijd, een belangrijke maatstaf voor efficiëntie-analyse. Waar te verkrijgen 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

Extractiegidsen

Hoe u je 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 'gebeurtenis_log.csv' in het vereiste formaat.
Voer validatiecontroles uit op het 'gebeurtenis_log.csv' bestand om de datakwaliteit en volledigheid te waarborgen voordat u uploadt.
Upload het definitieve 'gebeurtenis_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 opgehaald.
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.
Verplichten: 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 bron-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

Verplichten 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 het inloggen-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 Journaalboekingen 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 vinden 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 'Journaalboekingen Gecreëerd', 'Journaalboekingen Ingediend' en 'Journaalboekingen 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 'Journaalboekingen Ingediend'. Het script bevat logica om verschillende history gebeurtenis 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' gebeurtenis 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, volledige event log.
Voeg Metadata toe en Standaardiseer Kolommen: Na het combineren van de data voegt het script vereiste metadata-kolommen toe, waaronder Bronsysteem (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_gebeurtenis_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.
Verplichte 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 - Journaalboekingens `datatemplate`

Uw Record to report - Journaalboekingens `datatemplate`

Record to report - `Attributen` Journaalboekingen

Record to report - Activiteiten Journaalboekingen

Extractiegidsen

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 - Journaalboekingens datatemplate

Uw Record to report - Journaalboekingens datatemplate

Record to report - Attributen Journaalboekingen

Record to report - Activiteiten Journaalboekingen

Extractiegidsen

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 - Journaalboekingens `datatemplate`

Uw Record to report - Journaalboekingens `datatemplate`

Record to report - `Attributen` Journaalboekingen