> Kontinuierliche Prozessoptimierung > Order to Cash Fakturierung & Rechnungsstellung > Microsoft Dynamics 365 > Datenvorlage

Ihr Order to Cash - Fakturierungs- & Rechnungsstellungs-Data Template

Microsoft Dynamics 365

← Zurück zum Optimierungsleitfaden

Order to Cash - Fakturierungs- & Rechnungsstellungsattribute (18) Order to Cash - Fakturierungs- & Rechnungsstellungsaktivitäten (12) Extraktionsleitfäden (2)

Ihr Order to Cash - Fakturierungs- & Rechnungsstellungs-Data Template

This Template provides a clear Roadmap für collecting the essential Data Points needed to analyze Ihre Order to Cash - Fakturierungs- & Rechnungsstellungsprozess. You will find recommended Attributes to include in Ihrem Event Log, Key Activities to track, und Practical Guidance on extracting these Information. Es ist designed to help you quickly set up Ihre Data für insightful Process Mining.

Empfohlene Attribute zur Erfassung
Wichtige Aktivitäten zur Verfolgung
Extraktionsanleitung für Microsoft Dynamics 365

Neu bei Event-Logs? Erfahren Sie wie Sie ein Process-Mining-Event-Log erstellen.

Vorlage herunterladen

Order to Cash - Fakturierungs- & Rechnungsstellungsattribute

These are the recommended Data Fields to include in Ihrem Event Log für comprehensive Order to Cash - Fakturierungs- & Rechnungsstellungsprozessanalyse.

3 Erforderlich 6 Empfohlen 9 Optional

	Name	Beschreibung
	Rechnungsnummer InvoiceNumber	Der Unique Identifier für jede Customer Invoice, serving as the Primary Case Identifier für the Billing Process.
Beschreibung Die Invoice Number ist der central Key that groups all Activities related to a single Billing Document. Es allows für a complete, end-to-end Analysis des Invoice Lifecycle, from Generation und Approval to Customer Payment und Final Closure. By using this as the Case ID, every Event Log Entry corresponds to a specific Invoice, enabling detailed Variant Analysis, Cycle Time Calculation und Performance Monitoring für each Billing Transaction. Bedeutung This Attribute ist essential für tracking the entire Lifecycle einer Invoice, enabling the Analysis von Process Efficiency, Bottlenecks und Deviations für each individual Billing Document. Datenquelle This ist typically found in the Sales und Marketing Module, within Tables like CustInvoiceJour (Field InvoiceId) oder exposed through Data Entities like SalesInvoiceHeaderV2. Beispiele CIV-001254INV-2023-9876US-004321
	Aktivitätsname ActivityName	Der Name der Geschäftsaktivität oder des Events, das zu einem bestimmten Zeitpunkt im Rechnungslebenszyklus aufgetreten ist.
Beschreibung This Attribute describes a specific Step oder Milestone within the Billing Process, such as 'Invoice Generated', 'Invoice Approved', oder 'Customer Payment Received'. The Sequence dieser Activities forms the Process Flow. Analyzing the Activities ist fundamental für Process Mining, as es allows für the Discovery von Process Models, Identification von Variants und Measurement of Performance between different Steps. Bedeutung Es definiert die Steps im Process, allowing für die Visualization von Process Maps, Analysis von Process Variants und Identification von Bottlenecks oder Deviations vom Standard Procedure. Datenquelle This Attribute ist typically derived from multiple Sources, such as Status Change Fields (z.B. DocumentState), specific Date Fields being populated, oder Workflow History Logs within Microsoft Dynamics 365. Beispiele Rechnung erstelltRechnung freigegebenKundenzahlung eingegangenGutschrift ausgestellt
	Ereigniszeit EventTime	Der genaue Zeitstempel, der angibt, wann eine spezifische Aktivität oder ein Ereignis stattfand.
Beschreibung `Event Time`, auch bekannt als der `timestamp`, `records` das `exact date and time` für jede `activity` im `process`. Diese `data` sind `critical` für alle `time-based process mining analyses`. Es wird verwendet, um `cycle times between activities` zu berechnen, die `total duration` eines `case` zu `measure` und `process performance over time` zu `understand`. `Accurate and reliable timestamps` sind die `foundation` für `KPIs` wie `Days Sales Outstanding` und `Invoice Generation Time`. Bedeutung This ist the Foundational Attribute für all Performance und Time-Related Analysis, enabling the Calculation von Cycle Times, Durations und Throughput to measure Process Efficiency. Datenquelle Timestamps are sourced from various Date und Time Fields across different Tables in Dynamics 365, such as CreatedDateTime on the CustInvoiceJour Table für Invoice Generation, oder specific Workflow History Timestamps. Beispiele 2023-04-15T10:22:15Z2023-05-01T14:05:00Z2023-05-10T09:00:30Z
	Abteilung Department	Die Business Department associated mit dem User oder der Activity.
Beschreibung This Attribute assigns an Activity oder User zu a specific Organizational Department, such as 'Accounts Receivable' oder 'Sales'. Es allows für a higher-level View of Process Performance than the individual User Level. Analyzing by Department helps in understanding Cross-Functional Handoffs, comparing Efficiency between Teams, und identifying Department-Level Bottlenecks, as required by the 'Billing Department Activity Load' Dashboard. Bedeutung Ermöglicht eine `Performance`-Analyse auf Organisationsebene, vergleicht die Effizienz verschiedener `teams` und versteht, wie `inter-departmental handoffs` den Prozess beeinflussen. Datenquelle This ist typically not a direct Field on the Invoice Transaction. Es ist derived by joining the UserResponsible ID mit the Employee oder User Directory which contains Department Information. Beispiele ForderungsmanagementFinanzenAbrechnungsvorgänge
	Kundenname CustomerName	Der Name des Customers, to whom the Invoice was issued.
Beschreibung Der Customer Name provides a human-readable Identifier für the Business oder Individual being billed. In Process Mining Analysis, this allows für Segmenting the Billing Process by Customer. This can reveal which Customers consistently pay on Time, which ones are frequently late, oder if certain Customer Groups experience unique Process Variations oder Delays. Es ist Key für Dashboards related to Customer Payment Behavior und Days Sales Outstanding Analysis. Bedeutung This allows für Process Analysis to be segmented by Customer, helping to identify Customer-Specific Behaviors, Payment Patterns, oder Process Issues. Datenquelle These Information ist retrieved by joining the Invoice Data mit the Customer Master Data Table, typically CustTable, based on the Customer Account Number. Beispiele Contoso GmbHFabrikam, Inc.Northwind Traders
	Rechnungsbetrag InvoiceAmount	Der monetäre Gesamtwert der Rechnung.
Beschreibung This Attribute represents the Total Amount Due on the Invoice. Es ist a critical Metric für Financial Analysis, allowing für the Segmentation von Invoices by Value. For example, Analysts can focus on High-Value Invoices to understand their Payment Behaviors oder identify if larger Invoices face longer Approval Times. Es ist also fundamental für calculating the Total Value of Outstanding Invoices und für DSO Calculations. Bedeutung Es ermöglicht eine Financial Impact Analysis, allowing Ihnen, Processes nach Monetary Value zu filtern und zu segmentieren, um High-Value Invoices zu priorisieren und ihre specific Process Behaviors zu verstehen. Datenquelle Findet sich in der `CustInvoiceJour table`, typischerweise in einem `field` wie `InvoiceAmount`. Auch in `related transaction tables` verfügbar. Beispiele 5430.5012500.00750.25
	Rechnungsstatus InvoiceStatus	Der current Status der Invoice in ihrem Lifecycle (z.B., Open, Paid, Canceled).
Beschreibung This Attribute provides a Snapshot of where the Invoice currently stands. Es indicates whether an Invoice ist still awaiting Payment, has been fully paid, ist overdue, oder has been canceled via a Credit Note. This ist useful für filtering Cases to analyze only Open Invoices oder to confirm the Final Outcome of a Closed Invoice. Es helps in understanding the current Workload und the Financial State of Receivables. Bedeutung Provides a quick Snapshot des Invoice's current State, which ist useful für Filtering Cases und Understanding the Outcomes von different Process Variants. Datenquelle Dies kann aus dem Payment Status der Invoice abgeleitet werden, often by checking if the Balance on the related CustTrans Record ist zero. There isn't always a single 'Status' Field. Beispiele OffenBezahltÜberfälligStorniert
	Verantwortlicher Benutzer UserResponsible	Der User oder Employee responsible für executing a specific Activity.
Beschreibung This Attribute identifies the Individual who performed a particular Task im Billing Process, such as approving an Invoice oder applying Cash. Es ist crucial für Workload Analysis, Performance Comparison und identifying Training Needs. For example, the 'Billing Department Activity Load' Dashboard relies on this Attribute to see if Work ist distributed evenly oder if certain Users are Bottlenecks. Es also helps in understanding Resource Allocation und Efficiency. Bedeutung Es enables Resource-Level Analysis, helping to identify Bottlenecks, measure individual or Team Performance, und analyze Workload Distribution across the Billing Department. Datenquelle Dies kann sourced werden from Workflow History Logs (z.B. WorkflowTrackingStatusTable) oder Ownership Fields like Owner oder ModifiedBy on relevant Tables. Beispiele John SmithAlicia BakerSystemadministrator
	Zahlungsfälligkeitsdatum PaymentDueDate	Das Date by which the Customer expected ist, to pay the Invoice.
Beschreibung The Payment Due Date ist ein critical Date Field calculated based on the Invoice Date und the Customer's Payment Terms. Es serves as the Baseline für measuring Payment Timeliness. This Attribute ist essential für the 'Payment Terms Adherence Analysis' Dashboard und für calculating KPIs like 'On-Time Payment Rate' und 'Days Sales Outstanding'. Comparing this Date mit the actual Payment Date reveals Customer Payment Behavior und the Effectiveness des Collections Process. Bedeutung This ist the Benchmark für measuring Payment Performance. Es ist essential für calculating On-Time Payment Rates und analyzing Adherence to Customer Payment Terms. Datenquelle This ist typically found in der CustInvoiceJour Table in einem Field like DueDate. Beispiele 2023-05-152023-06-302023-07-01
	`Verkaufsauftragsnummer` SalesOrderNumber	Der Identifier des Sales Order that originated the Invoice.
Beschreibung The Sales Order Number links the Billing Process back to the preceding Sales Process. This Connection ist invaluable für broader, end-to-end Order-to-Cash Analysis. Es allows Analysts to investigate how Issues in the Sales und Fulfillment Process, such as Order Changes oder Shipping Delays, might impact the Billing Cycle. For example, es can help answer Questions like 'Do Invoices from complex Sales Orders take longer to get paid?'. Bedeutung This Attribute connects the Billing Process to the upstream Sales Process, enabling a more comprehensive end-to-end Order-to-Cash Analysis to identify Root Causes von Billing Issues. Datenquelle Findet sich im `invoice header` oder `line details`, `linking back` zu `the sales order`. Suchen Sie nach einem `field` wie `SalesId` in der `CustInvoiceJour table`. Beispiele SO-009876SO-010234US-SO-00543
	Days Sales Outstanding DaysSalesOutstanding	Die Number of Days between Invoice Generation und Receiving Customer Payment.
Beschreibung `Days Sales Outstanding (DSO)` ist eine zentrale `financial metric`, die die `average number of days` misst, die ein `company` benötigt, um `payment` nach einem `sale` einzuziehen. Dieses `calculated attribute` berechnet diese `duration` für jede `individual invoice`. Es ist die primäre `metric` für das `Dashboard` „Days Sales Outstanding Trend Analysis“ und den `DSO` `KPI`. Die Analyse des `DSO` hilft bei der Verwaltung des `Cashflows` und der `evaluation` der `efficiency` der `credit and collections function`. Bedeutung This ist ein critical KPI für measuring the Health einer Company's Cash Flow und the Efficiency ihres Collections Process. Es quantifies how quickly Revenue ist converted to Cash. Datenquelle This Attribute ist not im Source System. Es ist calculated als the Duration between the 'Invoice Generated' Activity und the 'Customer Payment Received' Activity. Beispiele 284592
	Erfordert manuelles Eingreifen RequiresManualIntervention	Ein `flag`, das anzeigt, ob eine `payment` während der `cash application` eine manuelle Anpassung erforderte.
Beschreibung This Boolean Attribute flags Payments that needed Manual Intervention oder Correction during the Cash Application Process. This ist Key für the 'Cash Application Discrepancy Rate' KPI, as es helps quantify the Accuracy und Automation Level of Payment Posting. Identifying the Reasons für Manual Intervention, such as missing Remittance Information oder Payment Discrepancies, can lead to Process Improvements that increase Straight-Through Processing Rates. Bedeutung This Attribute helps identify Process Friction und Inaccuracies in the Cash Application Step, which ist crucial für improving Automation und reducing Manual Effort. Datenquelle This Information might be inferred from the User who posted the Payment (if it's not a System User) oder from specific Reason Codes used during Payment Reconciliation. Consult Microsoft Dynamics 365 Documentation. Beispiele truefalsch
	Ist Nacharbeit IsRework	Ein `flag`, das anzeigt, ob der `invoice process` `rework activities` wie multiple `approvals` umfasste.
Beschreibung This ist a Calculated Boolean Attribute that flags Invoices that have undergone Rework. Rework can be defined als having multiple 'Invoice Approved' Events oder Reversals von Payments. This Attribute ist specifically designed to support the 'Invoice Rework Analysis' Dashboard und the 'Invoice Rework Rate' KPI. By isolating these Cases, Analysts can investigate the Root Causes of Rework, which often point to Process Inefficiencies, Data Quality Issues, oder Training Gaps. Bedeutung This Flag directly quantifies Process Inefficiency by identifying Cases mit Repetitive oder Corrective Actions, helping to pinpoint Root Causes of Waste und Delay. Datenquelle This Attribute ist not available im Source System. Es ist calculated in der Data Transformation Layer by checking für repeated Activities oder specific Rework Patterns within a Case. Beispiele truefalsch
	Ist pünktliche Zahlung IsOnTimePayment	Ein `flag`, das anzeigt, ob die `customer payment` am oder vor dem `due date` eingegangen ist.
Beschreibung This Calculated Boolean Attribute compares the 'Customer Payment Received' Timestamp mit the 'Payment Due Date'. Es flags each Invoice als either paid on Time oder late. This ist the Core Component für calculating the 'On-Time Payment Rate' KPI und ist used heavily in the 'Payment Terms Adherence Analysis' Dashboard. Es provides a clear, binary Outcome für Payment Performance, simplifying Analysis und Reporting. Bedeutung Misst direkt die `customer adherence` zu `payment terms` und ist die `basis` für den `On-Time Payment Rate KPI`, `simplifying` die `analysis` von `collection effectiveness`. Datenquelle This Attribute ist not im Source System. Es ist calculated during Data Transformation by comparing the Payment Date to the PaymentDueDate. Beispiele truefalsch
	Letzte Datenaktualisierung LastDataUpdate	Der `Timestamp`, der den Zeitpunkt der letzten Aktualisierung der Daten dieses `Events` aus dem Quellsystem angibt.
Beschreibung This Attribute records when the Data was last extracted oder updated from Microsoft Dynamics 365. Es ist a Metadata Field that ist crucial für understanding the Freshness der Data being analyzed. This helps Analysts und Business Users know if they are looking at the most current Information und ist vital für managing Data Refresh Schedules und ensuring the Reliability der Analysis. Bedeutung Es ensures Users understand the recency of the Data, which ist critical für Data Governance, Dashboard Refresh Management und trusting the timeliness der Erkenntnisse. Datenquelle This Attribute ist generated und stamped onto the Dataset during the Data Extraction, Transformation und Loading (ETL) Process. Beispiele 2023-06-20T05:00:00Z2023-06-21T05:00:00Z
	Quellsystem SourceSystem	Das System, aus dem die Daten extrahiert wurden.
Beschreibung This Attribute identifies the Origin der Process Data. In this Context, es specifies that the Data comes from Microsoft Dynamics 365. This ist important in Multi-System Environments to differentiate Data Sources und ensure Data Lineage ist clear, which aids in Data Validation und Troubleshooting. Bedeutung Es provides crucial Context about Data Origin, which ist essential für Data Governance, Validation und wenn Merging Data from multiple Enterprise Systems. Datenquelle Dies ist ein statischer Wert, der während des Datenextraktions- und Transformationsprozesses hinzugefügt wird, um den Ursprung des Datensatzes zu kennzeichnen. Beispiele Microsoft Dynamics 365 FinanceD365 F&O
	Währung Currency	Der Währungscode für den Rechnungsbetrag (z.B. USD, EUR).
Beschreibung This Attribute specifies the Currency in which the Invoice Amount ist denominated. Es ist essential für Multi-National Organizations that deal mit different Currencies. Without this Context, aggregating oder comparing Invoice Amounts would be meaningless. Es allows für proper Currency Conversion und accurate Financial Reporting und Analysis across different Regions. Bedeutung Es provides essential Context für any Financial Metrics like Invoice Amount, preventing incorrect Aggregations und enabling accurate Analysis in Multi-Currency Environments. Datenquelle Findet sich in der `CustInvoiceJour table`, typischerweise in einem `field` wie `CurrencyCode`. Beispiele USDEURGBP
	Zahlungsbedingungen PaymentTerms	Die agreed-upon Conditions für Invoice Payment (z.B., Net 30, Net 60).
Beschreibung Payment Terms define the Rules für wann ein Customer erwartet wird, eine Invoice zu payen. This Attribute ist used to calculate the Payment Due Date und ist a Key Dimension für analyzing Payment Behavior. The 'Payment Terms Adherence Analysis' Dashboard uses this Attribute to group Customers und Invoices to see if certain Payment Terms are more oder less effective oder are associated mit higher Rates von Late Payments. Bedeutung Es provides Context für warum eine Invoice Due auf einem certain Date ist und allows für Segmenting Analysis, um zu sehen, ob certain Payment Terms correlate mit Late Payments. Datenquelle This ist typically stored on the Customer Master Record but copied to the Invoice Header. Look for a Payment oder PaymTermId Field on the CustInvoiceJour Table. Beispiele Netto 30Netto 60Zahlbar bei Erhalt

Erforderlich Empfohlen Optional

Order to Cash - Fakturierungs- & Rechnungsstellungsaktivitäten

Dies sind die wichtigsten Prozessschritte und Meilensteine, die Sie in Ihrem `Event Log` erfassen sollten, um eine präzise `Process Discovery` und Analyse zu ermöglichen.

7 Empfohlen 5 Optional

	Aktivität	Beschreibung
	Geld auf Rechnung gebucht	Represents the Settlement eines Customer Payments against a specific Invoice, reducing the Invoice's Outstanding Balance. This ist a distinct Step in Dynamics 365 that links the Payment Transaction to the Invoice Transaction.
Bedeutung This ist a critical Milestone für accurately calculating DSO und understanding the Efficiency des Cash Application Team. Es marks the Point where the Payment ist fully reconciled mit what was billed. Datenquelle Recorded in der CustSettlement Table. The Settlement Date Field on this Table provides the Timestamp für wann a specific Payment was applied to a specific Invoice Transaction. Erfassen Use the TransDate oder CreatedDateTime from the CustSettlement Table. Ereignistyp explicit
	Kundenzahlung eingegangen	This Activity marks the Creation eines Journal Entry to record a Payment Received from a Customer. Es signifies that Cash has been Received, but es has not yet been applied to a specific Invoice.
Bedeutung This ist the Starting Point für measuring the Cash Application Lead Time. Es differentiates between receiving the Money und actually reconciling it against Outstanding Invoices. Datenquelle Erfasst aus der `creation` oder `posting` eines `customer payment journal`. Dies wird in `tables` wie `LedgerJournalTrans` aufgezeichnet, die dann bei der `posting` eine `customer transaction` in `CustTrans` erstellt. Erfassen Use the Posting Timestamp des Customer Payment Journal from LedgerJournalTable. Ereignistyp explicit
	Rechnung abgeschlossen	This Activity marks the Final State einer Invoice, where its Balance ist zero als es has been fully paid oder settled mit Credit Notes. This ist not a direct Transaction but an inferred State based on the Invoice's Financial Status.
Bedeutung This Event signifies the Successful Completion des Order to Cash Cycle für eine single Invoice. The Time taken to reach this State ist a Primary Measure des Process's overall Efficiency. Datenquelle Abgeleitet durch Prüfung, ob die Invoice Transaction in der CustTrans Table einen verbleibenden Saldo von null aufweist. Dies wird durch den Vergleich des Rechnungsbetrags mit dem gesamten darauf verrechneten Betrag ermittelt. Erfassen Ableiten aus `CustTrans` `records`, wo `AmountCur` gleich `SettleAmountCur` ist. Der `timestamp` ist das `date` der letzten `settlement`. Ereignistyp inferred
	Rechnung an Kunden gesendet	This Activity represents the Moment the Invoice was transmitted to the Customer, either electronically oder physically. In Dynamics 365, this can be an explicit Event if sent via System Email, oder inferred to occur at the Time of Posting if no specific Tracking ist enabled.
Bedeutung Measures the Efficiency des Invoice Delivery Process. Ein Delay zwischen Approval und Sending the Invoice unnecessarily extends the Payment Cycle. Datenquelle Kann explizit aus E-Mail-`Logs` wie `SysOutgoingEmailTable` erfasst werden, wenn die E-Mail-`capabilities` von D365 genutzt werden. Andernfalls wird oft angenommen, dass es der `invoice posting time` von `CustInvoiceJour` entspricht. Erfassen Use Email Log Timestamp if available; otherwise, use the Invoice Posting Timestamp. Ereignistyp inferred
	Rechnung erstellt	Represents the Creation und Posting des Sales Invoice Document im System. This ist an explicit Transaction in Dynamics 365 that creates a Legal Document und Financial Entries in the Accounts Receivable Subledger.
Bedeutung This ist the Official Start des Billing Lifecycle für eine Invoice. Es ist a critical Event für tracking Days Sales Outstanding (DSO) und overall Process Duration. Datenquelle Erfasst vom `creation timestamp` des `posted sales invoice record` in der `CustInvoiceJour table`. Die entsprechenden `financial transactions` werden bei der `posting` in den `GeneralJournalEntry` und `LedgerEntry tables` erstellt. Erfassen Use the CreatedDateTime Field from the CustInvoiceJour Table für the Posted Invoice. Ereignistyp explicit
	Rechnung freigegeben	Marks the Completion des Internal Review Process, where the Invoice formal approved ist. This Event ist logged by the Dynamics 365 Workflow System und signifies that the Invoice ready ist, to be sent to the Customer.
Bedeutung This ist a Key Milestone für measuring the Approval Cycle Time. Delays at this Stage can directly increase the Overall Time to receive Payment from the Customer. Datenquelle Recorded in den Workflow History Tables, such as WorkflowTrackingStatusTable, als a Completion oder Approval Step für the specific Invoice Workflow Instance. Erfassen Extrahieren Sie `workflow event logs`, bei denen der `status` „Approved“ oder „Completed“ ist. Ereignistyp explicit
	Zahlungsfälligkeitsdatum erreicht	Ein berechnetes `Event`, das eintritt, wenn das `due date` der `invoice` erreicht wird, ohne dass eine `payment` vollständig angewendet wurde. Diese `activity` entspricht keiner `transaction` im `system`, sondern wird aus vorhandenen `data` abgeleitet.
Bedeutung This Event ist crucial für analyzing On-Time Payment Rates und identifying Invoices that are becoming Overdue. Es acts als a Trigger Point für Collection und Dunning Activities. Datenquelle This ist not recorded als an Event. Es ist calculated by using the DueDate Field from the CustInvoiceJour Table. The Event Timestamp ist the Due Date itself. Erfassen Erstellen Sie ein `Event`, dessen `timestamp` der `value` des `CustInvoiceJour.DueDate field` ist. Ereignistyp calculated
	Gutschrift ausgestellt	Represents the Creation of a Credit Note oder Credit Memo, typically to correct a Billing Error, grant a Price Adjustment, oder Account for Returned Goods. A Credit Note ist essentially a Negative Invoice.
Bedeutung Häufige `credit notes` können `systemic issues` in der `order fulfillment` oder `billing process` anzeigen. `Analyzing why credit notes` ausgestellt werden, ist `key` zu `process improvement` und `reducing revenue leakage`. Datenquelle This ist an explicit Transaction, recorded als a new Posted Invoice mit einem Negative Amount in the CustInvoiceJour Table. Es ist often linked to the Original Invoice via a Reference Field. Erfassen Einträge in CustInvoiceJour mit negativem Gesamtbetrag identifizieren und mit der ursprünglichen Rechnung verknüpfen. Ereignistyp explicit
	Kundenauftrag erfüllt	This Activity marks the Point where Goods have been shipped oder Services rendered für a Sales Order, triggering the Billing Process. Es ist typically inferred from the Posting eines Packing Slip oder Delivery Note in Microsoft Dynamics 365, which changes the Status der related Sales Order Lines.
Bedeutung This Event serves as the Starting Point für measuring the Invoice Generation Cycle Time. Understanding the Delay between Fulfillment und Invoicing helps identify Administrative Bottlenecks that can impact Cash Flow. Datenquelle Abgeleitet vom Creation Date eines Packing Slip Journal Entrys, das mit dem Sales Order verknüpft ist. Dies umfasst Tables wie CustPackingSlipJour und CustPackingSlipTrans, die mit dem Sales Order in Verbindung stehen, auf dem die Rechnung basiert. Erfassen Das neueste Buchungsdatum des Lieferscheins für den mit der Rechnung verknüpften Kundenauftrag ermitteln. Ereignistyp inferred
	Rechnung zur Genehmigung eingereicht	This Activity indicates that a generated Invoice has been submitted into a formal Approval Workflow. This ist common in Organizations mit Controls requiring Management Review before an Invoice ist sent to a Customer. This ist logged als a specific Step in the D365 Workflow Engine.
Bedeutung Tracking Submission für Approval helps separate the Invoice Creation Time from the Approval Waiting Time. Es ist the First Step in Analyzing the Efficiency des Internal Review und Control Processes. Datenquelle Erfasst aus den `workflow history tables`, wie `WorkflowTrackingStatusTable`, durch Filtern nach dem `submission event`, das sich auf das `invoice document` bezieht. Erfassen Extrahieren Sie `workflow event logs`, bei denen der `status` „Submitted“ ist. Ereignistyp explicit
	Zahlung rückgängig gemacht	This Activity signifies the Reversal of a previously Posted Customer Payment. This occurs due to Errors such as incorrect Posting, non-sufficient Funds, oder other Payment Failures.
Bedeutung Payment Reversals highlight Operational Errors oder Issues mit Customer Payments. Analyzing ihrer Frequency helps identify Root Causes und improve the Accuracy des Cash Application Process. Datenquelle Erfasst als `transaction reversal` im `general ledger`. Ein `reversed journal` kann in `GeneralJournalEntry` identifiziert werden, oft mit einem spezifischen `flag` oder durch seine `relationship` zur `original transaction`. Erfassen Identifizieren Sie `journal entries` mit einem `reversal flag` oder einem `reference` zu einer `reversed transaction`. Ereignistyp explicit
	Zahlungserinnerung gesendet	Represents the Sending eines Dunning Letters oder Collection Notice to a Customer regarding an Overdue Invoice. Dynamics 365 has a Formal Dunning Process that generates und logs these Communications.
Bedeutung Tracking Reminders helps evaluate the Effectiveness des Dunning Process. Es allows für Analysis of how many Reminders are needed before a Payment ist Received. Datenquelle This ist an explicit Event captured from the Creation Date des Collection Letter Journal in the CustCollectionLetterJour Table, which ist linked to the Overdue Invoice Transaction. Erfassen Use the Creation Timestamp from the CustCollectionLetterJour Table. Ereignistyp explicit

Extraktionsleitfäden

So rufen Sie Ihre Daten aus Microsoft Dynamics 365 ab

Schritte

Zum Data Management Workspace navigieren: Melden Sie sich bei Microsoft Dynamics 365 Finance and Operations an. Verwenden Sie die Suchleiste, um den Data Management Workspace zu finden und dorthin zu navigieren. Dies ist die zentrale Anlaufstelle für alle Datenimport- und -exportvorgänge.
Neues Exportprojekt erstellen: Im Data Management Workspace klicken Sie auf die Export-Kachel, um ein neues data export project zu erstellen. Geben Sie dem project einen aussagekräftigen Namen, z.B. ProcessMind_O2C_Billing_Export, und eine description.
Zieldatenformat auswählen: In der project configuration geben Sie das Target data format an. Für die Kompatibilität mit den meisten data transformation tools wählen Sie CSV. Konfigurieren Sie die format options nach Bedarf und stellen Sie einen gängigen delimiter und text qualifier sicher.
Erforderliche Data Entities hinzufügen: Dies ist der kritischste Schritt. Sie werden mehrere Standard-Data Entities zu Ihrem project hinzufügen, um alle erforderlichen activities zu erfassen. Klicken Sie für jede entity auf Add entity und suchen Sie nach dem im Abschnitt Query/Script aufgeführten entity name. Fügen Sie jede der folgenden entities zu Ihrem project hinzu: Sales invoice headers V2, Sales packing slip headers, Workflow tracking status table, CustPaymentJournalLineEntity, Customer settlement und Dunning history letters.
Entity Filters anwenden: Um die data auf einen relevanten scope zu beschränken, wenden Sie filters auf Ihre entities an. Filtern Sie mindestens Sales invoice headers V2 nach InvoiceDate für einen spezifischen period, zum Beispiel die letzten 6 Monate. Filtern Sie auch nach den spezifischen juristischen Personen (companies), die Sie analysieren möchten.
Export Job ausführen: Nachdem alle entities hinzugefügt und filters angewendet wurden, klicken Sie im action pane auf die Export-Schaltfläche. Das system erstellt ein job package und beginnt mit der Hintergrundverarbeitung der data extraction.
Data überwachen und downloaden: Sie können den job's progress im Abschnitt Job history überwachen. Sobald der job erfolgreich abgeschlossen ist, können Sie das exportierte data package downloaden. Das package wird eine ZIP-Datei sein, die separate CSV files für jede data entity enthält.
Paket entpacken: Extrahieren Sie den contents der downloaded ZIP file in einen lokalen folder. Sie haben nun mehrere CSV files, eine für jede entity.
Data transformieren und kombinieren: Die raw files müssen in ein einziges Event Log umgewandelt werden. Verwenden Sie ein data preparation tool wie Power Query, Python oder einen database staging area. Für jede source file erstellen Sie die erforderlichen columns: InvoiceNumber (Case ID), ActivityName (ein hardcoded value, der das Event darstellt, wie 'Invoice Generated') und EventTime (das relevante date field aus der source file). Map andere attributes wie InvoiceAmount und CustomerName.
Union All Transformed Data: Kombinieren Sie die transformierten data aus allen source files in eine einzige table mithilfe einer union oder append operation. Dies erstellt das endgültige, vereinheitlichte Event Log, wobei jede row eine activity im invoice lifecycle darstellt.
Final Formatting for Upload: Stellen Sie sicher, dass die endgültige CSV-Datei die korrekten Spaltenüberschriften (InvoiceNumber, ActivityName, EventTime usw.) aufweist und dass die EventTime-Spalte in einem konsistenten Timestamp-Format (z.B. YYYY-MM-DD HH:MI:SS) vorliegt. Diese Datei ist nun bereit für den Upload in ProcessMind.

Konfiguration

Data Entities: Die Extraktion basiert auf einer Reihe von Standard-D365-Data Entities. Zu den Schlüsselentitäten gehören Sales invoice headers V2 (für Rechnungen und Gutschriften), Sales packing slip headers (für die Auftragserfüllung), CustPaymentJournalLineEntity (für Zahlungen), Customer settlement (für die Cash Application) und Workflow tracking status table (für Genehmigungen).
Export Format: Das empfohlene Zieldatenformat ist CSV aufgrund seiner breiten Kompatibilität mit Data Transformation-Tools.
Date Range Filtering: Es ist entscheidend, einen Datumsbereichsfilter auf die primären Entitäten anzuwenden, insbesondere Sales invoice headers V2 auf das Feld InvoiceDate. Ein Bereich von 3 bis 6 Monaten wird empfohlen, um den Export überschaubar zu halten und gleichzeitig genügend data für die Analyse bereitzustellen.
Company Filtering: Der Export sollte nach der spezifischen juristischen Person oder dem Firmencode gefiltert werden, die Sie analysieren, um die data-Relevanz zu gewährleisten und die Exportgröße zu reduzieren.
Data Staging and Transformation: Ein Nachbearbeitungsschritt außerhalb von Dynamics 365 ist erforderlich. Die exportierten Dateien müssen kombiniert und in ein einziges Event Log-Format umgewandelt werden. Dies erfolgt typischerweise mit Tools wie Power BI (Power Query), Python oder SQL.
Prerequisites: Der Benutzer, der den Export ausführt, muss über entsprechende Sicherheitsrollen in Dynamics 365 verfügen, typischerweise eine Rolle mit Berechtigungen für den Data management Workspace und Zugriff auf die erforderlichen Data Entities.

a Beispielabfrage config

The following configuration outlines the data entities and field mappings required for the export project within the Dynamics 365 Data Management Framework. A post-processing script or tool is required to union these outputs into a single event log.

**1. Activity: Sales Order Fulfilled**
*   **Entity Name:** `Sales packing slip headers`
*   **Mapping:**
    *   `InvoiceNumber`: Use `SalesOrderNumber` as a key to later join to the invoice data and find the corresponding `InvoiceNumber`.
    *   `ActivityName`: 'Sales Order Fulfilled' (Hardcoded Value)
    *   `EventTime`: `DeliveryDate`
    *   `UserResponsible`: `CreatedBy`

**2. Activity: Invoice Generated**
*   **Entity Name:** `Sales invoice headers V2`
*   **Filter:** `InvoiceType` is not 'CreditNote'.
*   **Mapping:**
    *   `InvoiceNumber`: `InvoiceNumber`
    *   `ActivityName`: 'Invoice Generated' (Hardcoded Value)
    *   `EventTime`: `InvoiceDate` and `CreatedTime`
    *   `InvoiceAmount`: `TotalInvoiceAmount`
    *   `CustomerName`: `InvoiceCustomerName`
    *   `UserResponsible`: `CreatedBy`
    *   `PaymentDueDate`: `DueDate`
    *   `InvoiceStatus`: `DocumentState`

**3. Activities: Invoice Submitted for Approval & Invoice Approved**
*   **Entity Name:** `Workflow tracking status table`
*   **Filter:** `ContextTableName` is 'CustInvoiceJour'.
*   **Mapping:**
    *   `InvoiceNumber`: Join `ContextRecId` to `RecId` from `Sales invoice headers V2` to get the `InvoiceNumber`.
    *   `ActivityName`: Use a conditional rule, if `TrackingStatus` is 'Submitted', set to 'Invoice Submitted for Approval'; if 'Approved', set to 'Invoice Approved'.
    *   `EventTime`: `CreatedDateTime`
    *   `UserResponsible`: `User`

**4. Activity: Invoice Sent to Customer**
*   **Note:** This is an inferred event. The posting date is used as a proxy.
*   **Entity Name:** `Sales invoice headers V2`
*   **Mapping:**
    *   `InvoiceNumber`: `InvoiceNumber`
    *   `ActivityName`: 'Invoice Sent to Customer' (Hardcoded Value)
    *   `EventTime`: `PostedDateTime` (or equivalent posting timestamp)

**5. Activity: Payment Due Date Reached**
*   **Note:** This is a calculated event generated during post-processing.
*   **Source Entity:** `Sales invoice headers V2`
*   **Logic:** For each invoice where the `DueDate` has passed and the invoice is not fully settled.
*   **Mapping:**
    *   `InvoiceNumber`: `InvoiceNumber`
    *   `ActivityName`: 'Payment Due Date Reached' (Hardcoded Value)
    *   `EventTime`: `DueDate`

**6. Activity: Payment Reminder Issued**
*   **Entity Name:** `Dunning history letters`
*   **Mapping:**
    *   `InvoiceNumber`: Join from the dunning history to the customer transactions to find the related `InvoiceNumber`.
    *   `ActivityName`: 'Payment Reminder Issued' (Hardcoded Value)
    *   `EventTime`: `DunningLetterDate`
    *   `UserResponsible`: `CreatedBy`

**7. Activity: Customer Payment Received**
*   **Entity Name:** `CustPaymentJournalLineEntity`
*   **Mapping:**
    *   `InvoiceNumber`: The `Invoice` field may be populated, but often settlements are needed to link payments to invoices. This might require staging the payment data first.
    *   `ActivityName`: 'Customer Payment Received' (Hardcoded Value)
    *   `EventTime`: `ReceivedDate` or `DocumentDate`
    *   `UserResponsible`: `CreatedBy`

**8. Activity: Cash Applied to Invoice**
*   **Entity Name:** `Customer settlement`
*   **Mapping:**
    *   `InvoiceNumber`: `OffsetInvoice`
    *   `ActivityName`: 'Cash Applied to Invoice' (Hardcoded Value)
    *   `EventTime`: `TransDate`
    *   `UserResponsible`: `CreatedBy`

**9. Activity: Payment Reversed**
*   **Source Entity:** `Customer settlement`
*   **Logic:** Filter for transactions where a settlement was later reversed. This may require looking for cancellation markers.
*   **Mapping:**
    *   `InvoiceNumber`: `OffsetInvoice`
    *   `ActivityName`: 'Payment Reversed' (Hardcoded Value)
    *   `EventTime`: Reversal transaction timestamp.

**10. Activity: Credit Note Issued**
*   **Entity Name:** `Sales invoice headers V2`
*   **Filter:** `InvoiceType` is 'CreditNote'.
*   **Mapping:**
    *   `InvoiceNumber`: `InvoiceNumber`
    *   `ActivityName`: 'Credit Note Issued' (Hardcoded Value)
    *   `EventTime`: `InvoiceDate`
    *   `InvoiceAmount`: `TotalInvoiceAmount` (will be negative)
    *   `CustomerName`: `InvoiceCustomerName`
    *   `UserResponsible`: `CreatedBy`

**11. Activity: Invoice Closed**
*   **Note:** This is an inferred event based on settlement data.
*   **Source Entity:** `Customer settlement`
*   **Logic:** Use the latest `TransDate` for an invoice from the settlement data where the invoice balance becomes zero.
*   **Mapping:**
    *   `InvoiceNumber`: `OffsetInvoice`
    *   `ActivityName`: 'Invoice Closed' (Hardcoded Value)
    *   `EventTime`: The latest `TransDate` that resulted in the invoice being fully settled.

Schritte

Prerequisites: Stellen Sie sicher, dass Sie Python 3.6+ mit den Bibliotheken requests und pandas installiert haben. Sie benötigen außerdem Anmeldeinformationen für einen Service Principal (App Registration) in Azure Active Directory, dem Zugriff auf die Dynamics 365 Finance & Operations Umgebung gewährt wurde.
Application Registration: Registrieren Sie in Azure AD eine neue Application. Erstellen Sie ein Client Secret und notieren Sie sich die Application (client) ID, Directory (tenant) ID und das Client Secret. Fügen Sie in Dynamics 365 diese Application ID unter System administration > Setup > Azure Active Directory applications hinzu und weisen Sie ihr entsprechende Benutzerrechte zum Lesen der erforderlichen Data Entities zu.
Skript konfigurieren: Öffnen Sie das bereitgestellte Python-Skript. Füllen Sie die Configuration Variables am Anfang des Skripts aus, einschließlich d365_url, tenant_id, client_id, client_secret, company, start_date und end_date. Die d365_url sollte die Basis-URL Ihrer Dynamics 365 Umgebung sein, z.B. https://your-d365-instance.operations.dynamics.com.
Authentifizierung: Das Skript enthält eine Funktion get_access_token, die Ihre credentials automatisch verwendet, um ein OAuth2 access token von Microsofts Identity Platform anzufordern. Dieses Token ist erforderlich, um nachfolgende API Calls zu autorisieren.
Data Extraction: Führen Sie das Skript von Ihrem Terminal aus mit python your_script_name.py aus. Das Skript wird damit beginnen, alle gebuchten Sales Invoices (CustInvoiceJour) innerhalb des angegebenen date range abzurufen. Für jede invoice werden dann zusätzliche API Calls ausgeführt, um verwandte data für activities wie payments, settlements, credit notes und workflow history abzurufen.
Activity Generation: Das Skript verarbeitet die raw data von mehreren API Endpoints. Es generiert explizit eine row für jede der 12 erforderlichen activities. Zum Beispiel verwendet es die CustInvoiceJour entity für das Event „Invoice Generated“ und fragt die CustSettlement entity ab, um „Cash Applied to Invoice“ Events zu erstellen.
Calculated Events: Beachten Sie, dass Events wie „Payment Due Date Reached“ und „Invoice Closed“ keine direkten Transaktionen in Dynamics 365 sind. Das Skript leitet diese Events basierend auf dem due date, status und der settlement history einer invoice ab und erstellt entsprechende Einträge im Event Log.
Handhabung der Pagination: Die fetch_all_data helper function ist so konzipiert, dass sie die pagination automatisch handhabt. Dynamics 365 OData APIs geben eine begrenzte Anzahl von records pro page zurück, daher folgt diese function dem im API response bereitgestellten @odata.nextLink, um den vollständigen dataset abzurufen.
Data Transformation und Output: Nach dem Sammeln aller Events kompiliert das Skript sie in eine einzige list, konvertiert sie in ein pandas DataFrame und standardisiert die column names zu InvoiceNumber, ActivityName, EventTime und anderen erforderlichen Attributes.
Export nach CSV: Schließlich speichert das Skript das resultierende DataFrame in einer CSV-Datei mit dem Namen d365_billing_event_log.csv. Diese Datei ist formatiert und bereit für den Upload in ProcessMind oder ein anderes Process Mining-Tool.

Konfiguration

D365 URL: Die Basis-URL Ihrer Dynamics 365 Finance & Operations Instanz. Dies ist der primäre Endpunkt für alle API-Aufrufe.
Azure AD Credentials: Ein client_id, client_secret und tenant_id sind für die Authentifizierung erforderlich. Diese sollten zu einer Anwendung mit Lesezugriff auf die relevanten D365-Entitäten gehören.
Company: Geben Sie die DataAreaId an, die der juristischen Person in Dynamics 365 entspricht, aus der Sie Daten extrahieren möchten (z.B. 'USMF').
Date Range: Definieren Sie ein start_date und end_date, um den Extraktionsumfang zu begrenzen. Für eine erste Analyse wird ein Zeitraum von 3 bis 6 Monaten empfohlen, um eine überschaubare Dataset-Größe zu gewährleisten und gleichzeitig genügend Prozessvarianten zu erfassen.
Key OData Entities: Das Skript fragt hauptsächlich die folgenden Entitäten ab: CustInvoiceJours, CustSettlements, CustTrans, CustCollectionLetterJours und WorkflowTrackingStatusTables. Stellen Sie sicher, dass der konfigurierte Benutzer über die Berechtigungen zum Lesen aus all diesen Entitäten verfügt.
Performance: Das Extrahieren von data über einen langen Zeitraum oder aus einem sehr großen Unternehmen kann aufgrund der Natur mehrerer sequentieller API Calls langsam sein. Es ist ratsam, das Skript außerhalb der Spitzenzeiten auszuführen und mit einem kleineren Datumsbereich zu beginnen, um die geschätzte Gesamtausführungszeit zu ermitteln.

a Beispielabfrage python

import requests
import pandas as pd
from datetime import datetime, timezone

class=class="hl-string">"hl-comment"># --- Configuration ---
d365_url = class="hl-string">"https://[your-d365-instance].operations.dynamics.com" class=class="hl-string">"hl-comment"># Your D365 F&O URL
tenant_id = class="hl-string">"[Your Tenant ID]"
client_id = class="hl-string">"[Your Client ID]"
client_secret = class="hl-string">"[Your Client Secret]"
company = class="hl-string">"[Your Company DataAreaId, e.g., USMF]"
start_date = class="hl-string">"2023-01-01"
end_date = class="hl-string">"2023-12-31"

class=class="hl-string">"hl-comment"># --- Authentication ---
def get_access_token():
    url = fclass="hl-string">"https://login.microsoftonline.com/{tenant_id}/oauth2/v2.0/token"
    payload = {
        class="hl-string">'grant_type': class="hl-string">'client_credentials',
        class="hl-string">'client_id': client_id,
        class="hl-string">'client_secret': client_secret,
        class="hl-string">'scope': fclass="hl-string">"{d365_url}/.default"
    }
    response = requests.post(url, data=payload)
    response.raise_for_status()
    return response.json()[class="hl-string">'access_token']

class=class="hl-string">"hl-comment"># --- OData Helper ---
def fetch_all_data(access_token, resource_path):
    headers = {
        class="hl-string">'Authorization': fclass="hl-string">'Bearer {access_token}',
        class="hl-string">'Content-Type': class="hl-string">'application/json'
    }
    full_url = fclass="hl-string">"{d365_url}/data/{resource_path}"
    results = []
    while full_url:
        response = requests.get(full_url, headers=headers)
        response.raise_for_status()
        data = response.json()
        results.extend(data[class="hl-string">'value'])
        full_url = data.get(class="hl-string">'@odata.nextLink')
    return results

class=class="hl-string">"hl-comment"># --- Main Extraction Logic ---
def main():
    print(class="hl-string">"Acquiring access token...")
    token = get_access_token()
    event_log = []
    today = datetime.now(timezone.utc).date()

    print(class="hl-string">"Fetching Invoices and Credit Notes...")
    invoice_filter = fclass="hl-string">"$filter=InvoiceDate ge {start_date} and InvoiceDate le {end_date}"
    invoice_fields = class="hl-string">"$select=InvoiceNumber,InvoiceDate,SalesOrderNumber,InvoiceAmount,CustomerAccount,Due_Date,WorkerSalespersonName,createdDateTime,RecId,SalesInvoiceHeader_SalesStatus"
    invoices = fetch_all_data(token, fclass="hl-string">"CustInvoiceJours?cross-company=true&{invoice_filter}&{invoice_fields}")

    class=class="hl-string">"hl-comment"># Create a lookup for invoice RecIds for workflow queries
    invoice_recid_map = {inv[class="hl-string">'RecId']: inv[class="hl-string">'InvoiceNumber'] for inv in invoices}

    for inv in invoices:
        case_id = inv[class="hl-string">'InvoiceNumber']
        invoice_amount = inv[class="hl-string">'InvoiceAmount']
        customer_name = inv.get(class="hl-string">'CustomerAccount', class="hl-string">'') class=class="hl-string">"hl-comment"># Placeholder, join to CustTable for name
        user_responsible = inv.get(class="hl-string">'WorkerSalespersonName', class="hl-string">'System')
        due_date = inv.get(class="hl-string">'Due_Date')
        invoice_status = inv.get(class="hl-string">'SalesInvoiceHeader_SalesStatus', class="hl-string">'Open')

        class=class="hl-string">"hl-comment"># Activity: Invoice Generated / Credit Note Issued
        activity_name = class="hl-string">'Credit Note Issued' if invoice_amount < 0 else class="hl-string">'Invoice Generated'
        event_log.append({
            class="hl-string">'InvoiceNumber': case_id,
            class="hl-string">'ActivityName': activity_name,
            class="hl-string">'EventTime': inv[class="hl-string">'createdDateTime'],
            class="hl-string">'InvoiceAmount': invoice_amount,
            class="hl-string">'CustomerName': customer_name,
            class="hl-string">'UserResponsible': user_responsible,
            class="hl-string">'Department': class="hl-string">'[Configure based on your system]',
            class="hl-string">'PaymentDueDate': due_date,
            class="hl-string">'InvoiceStatus': invoice_status
        })

        class=class="hl-string">"hl-comment"># Activity: Invoice Sent to Customer (proxy)
        event_log.append({
            class="hl-string">'InvoiceNumber': case_id,
            class="hl-string">'ActivityName': class="hl-string">'Invoice Sent to Customer',
            class="hl-string">'EventTime': inv[class="hl-string">'InvoiceDate'],
            class="hl-string">'InvoiceAmount': invoice_amount,
            class="hl-string">'CustomerName': customer_name,
            class="hl-string">'UserResponsible': user_responsible,
            class="hl-string">'Department': class="hl-string">'[Configure based on your system]',
            class="hl-string">'PaymentDueDate': due_date,
            class="hl-string">'InvoiceStatus': invoice_status
        })
        
        class=class="hl-string">"hl-comment"># Activity: Sales Order Fulfilled (proxy via invoice date, complex to get actual packing slip date)
        class=class="hl-string">"hl-comment"># A more accurate query would trace SalesInvoiceLinesV2 -> SalesOrderLines -> CustPackingSlipJour
        event_log.append({
            class="hl-string">'InvoiceNumber': case_id,
            class="hl-string">'ActivityName': class="hl-string">'Sales Order Fulfilled',
            class="hl-string">'EventTime': inv[class="hl-string">'InvoiceDate'], class=class="hl-string">"hl-comment"># Using InvoiceDate as a proxy
            class="hl-string">'InvoiceAmount': invoice_amount,
            class="hl-string">'CustomerName': customer_name,
            class="hl-string">'UserResponsible': user_responsible,
            class="hl-string">'Department': class="hl-string">'[Configure based on your system]',
            class="hl-string">'PaymentDueDate': due_date,
            class="hl-string">'InvoiceStatus': invoice_status
        })

        class=class="hl-string">"hl-comment"># Activity: Payment Due Date Reached (calculated)
        if due_date and pd.to_datetime(due_date).date() < today and invoice_status != class="hl-string">'Paid':
            event_log.append({
                class="hl-string">'InvoiceNumber': case_id,
                class="hl-string">'ActivityName': class="hl-string">'Payment Due Date Reached',
                class="hl-string">'EventTime': due_date,
                class="hl-string">'InvoiceAmount': invoice_amount,
                class="hl-string">'CustomerName': customer_name,
                class="hl-string">'UserResponsible': class="hl-string">'System',
                class="hl-string">'Department': class="hl-string">'Finance',
                class="hl-string">'PaymentDueDate': due_date,
                class="hl-string">'InvoiceStatus': invoice_status
            })

    print(class="hl-string">"Fetching Settlements for Cash Applied and Invoice Closed events...")
    settlement_filter = fclass="hl-string">"$filter=InvoiceDate ge {start_date} and InvoiceDate le {end_date}"
    settlement_fields = class="hl-string">"$select=InvoiceNumber,SettlementDate,OffsetTransactionVoucher,OffsetRecId,CanBeReversed"
    settlements = fetch_all_data(token, fclass="hl-string">"CustSettlements?cross-company=true&{settlement_filter}&{settlement_fields}")

    class=class="hl-string">"hl-comment"># Group settlements by invoice
    settlements_by_invoice = pd.DataFrame(settlements).groupby(class="hl-string">'InvoiceNumber')

    for case_id, group in settlements_by_invoice:
        last_settlement = group.sort_values(class="hl-string">'SettlementDate').iloc[-1]

        for _, settlement in group.iterrows():
            class=class="hl-string">"hl-comment"># Activity: Cash Applied to Invoice
            event_log.append({
                class="hl-string">'InvoiceNumber': case_id,
                class="hl-string">'ActivityName': class="hl-string">'Cash Applied to Invoice',
                class="hl-string">'EventTime': settlement[class="hl-string">'SettlementDate'],
                class="hl-string">'UserResponsible': class="hl-string">'System',
                class=class="hl-string">"hl-comment"># Add other attributes from original invoice if needed
            })

            class=class="hl-string">"hl-comment"># Activity: Customer Payment Received (date of original payment)
            class=class="hl-string">"hl-comment"># This requires a second hop to CustTrans using OffsetRecId
            class=class="hl-string">"hl-comment"># For simplicity, we use settlement date as a proxy. A full implementation would query CustTrans.
            event_log.append({
                class="hl-string">'InvoiceNumber': case_id,
                class="hl-string">'ActivityName': class="hl-string">'Customer Payment Received',
                class="hl-string">'EventTime': settlement[class="hl-string">'SettlementDate'], class=class="hl-string">"hl-comment"># Proxy timestamp
                class="hl-string">'UserResponsible': class="hl-string">'System',
            })

            class=class="hl-string">"hl-comment"># Activity: Payment Reversed (if applicable)
            if settlement[class="hl-string">'CanBeReversed']: class=class="hl-string">"hl-comment"># A simplistic check, real logic is more complex
                 event_log.append({
                    class="hl-string">'InvoiceNumber': case_id,
                    class="hl-string">'ActivityName': class="hl-string">'Payment Reversed',
                    class="hl-string">'EventTime': settlement[class="hl-string">'SettlementDate'], class=class="hl-string">"hl-comment"># Reversal date would be different in reality
                    class="hl-string">'UserResponsible': class="hl-string">'System',
                 })
        
        class=class="hl-string">"hl-comment"># Activity: Invoice Closed (inferred from last settlement)
        class=class="hl-string">"hl-comment"># This logic assumes the invoice is fully paid by the last settlement. A robust check would sum amounts.
        event_log.append({
            class="hl-string">'InvoiceNumber': case_id,
            class="hl-string">'ActivityName': class="hl-string">'Invoice Closed',
            class="hl-string">'EventTime': last_settlement[class="hl-string">'SettlementDate'],
            class="hl-string">'UserResponsible': class="hl-string">'System',
        })

    print(class="hl-string">"Fetching Payment Reminders...")
    reminder_filter = fclass="hl-string">"$filter=CollectionLetterDate ge {start_date} and CollectionLetterDate le {end_date}"
    reminders = fetch_all_data(token, fclass="hl-string">"CustCollectionLetterJours?cross-company=true&{reminder_filter}")
    for rem in reminders:
        class=class="hl-string">"hl-comment"># Linking reminders to invoices can be complex. This is a simplified approach.
        if rem.get(class="hl-string">'InvoiceNum'):
            event_log.append({
                class="hl-string">'InvoiceNumber': rem[class="hl-string">'InvoiceNum'],
                class="hl-string">'ActivityName': class="hl-string">'Payment Reminder Issued',
                class="hl-string">'EventTime': rem[class="hl-string">'CollectionLetterDate'],
                class="hl-string">'UserResponsible': rem.get(class="hl-string">'UserId', class="hl-string">'System'),
            })

    print(class="hl-string">"Fetching Workflow History...")
    class=class="hl-string">"hl-comment"># This is a complex query. It requires knowing the TableId for CustInvoiceJour (e.g., 523)
    class=class="hl-string">"hl-comment"># The filter below is illustrative and needs to be adapted for your specific workflow setup.
    workflow_filter = fclass="hl-string">"$filter=createdDateTime ge {start_date}T00:00:00Z"
    wf_history = fetch_all_data(token, fclass="hl-string">"WorkflowTrackingStatusTables?cross-company=true&{workflow_filter}")
    for item in wf_history:
        if item.get(class="hl-string">'ContextRecId') in invoice_recid_map:
            case_id = invoice_recid_map[item[class="hl-string">'ContextRecId']]
            activity_name = None
            if item[class="hl-string">'TrackingStatus'] == class="hl-string">'Submitted':
                activity_name = class="hl-string">'Invoice Submitted for Approval'
            elif item[class="hl-string">'TrackingStatus'] == class="hl-string">'Approved':
                activity_name = class="hl-string">'Invoice Approved'
            
            if activity_name:
                event_log.append({
                    class="hl-string">'InvoiceNumber': case_id,
                    class="hl-string">'ActivityName': activity_name,
                    class="hl-string">'EventTime': item[class="hl-string">'createdDateTime'],
                    class="hl-string">'UserResponsible': item.get(class="hl-string">'User', class="hl-string">'System'),
                })

    print(fclass="hl-string">"Total events extracted: {len(event_log)}")
    if not event_log:
        print(class="hl-string">"No events found for the given criteria.")
        return

    df = pd.DataFrame(event_log)
    df = df.sort_values(by=[class="hl-string">'InvoiceNumber', class="hl-string">'EventTime'])
    df.to_csv(class="hl-string">'d365_billing_event_log.csv', index=False)
    print(class="hl-string">"Event log saved to d365_billing_event_log.csv")

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

Ihr Order to Cash - Fakturierungs- & Rechnungsstellungs-Data Template

Ihr Order to Cash - Fakturierungs- & Rechnungsstellungs-Data Template

Order to Cash - Fakturierungs- & Rechnungsstellungsattribute

Order to Cash - Fakturierungs- & Rechnungsstellungsaktivitäten

Extraktionsleitfäden

Microsoft Dynamics 365 Data Entity Export

Schritte

Konfiguration

a Beispielabfrage config

Python Script using Dynamics 365 OData Web API

Schritte

Konfiguration

a Beispielabfrage python

Bereit, um loszulegen?

Abrechnungsverzögerungen beenden: Order-to-Cash & Fakturierung heute optimieren

Ihr Order to Cash - Fakturierungs- & Rechnungsstellungs-Data Template

Ihr Order to Cash - Fakturierungs- & Rechnungsstellungs-Data Template

Order to Cash - Fakturierungs- & Rechnungsstellungsattribute

Order to Cash - Fakturierungs- & Rechnungsstellungsaktivitäten

Extraktionsleitfäden

Microsoft Dynamics 365 Data Entity Export

Schritte

Konfiguration

a Beispielabfrage config

Python Script using Dynamics 365 OData Web API

Schritte

Konfiguration

a Beispielabfrage python

Ihre Privatsphäre ist uns wichtig

Bereit, um loszulegen?

Abrechnungsverzögerungen beenden: Order-to-Cash & Fakturierung heute optimieren