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

Ihre Order-to-Cash – Rechnungsstellungs- und FakturierungsDatenvorlage

Microsoft Dynamics 365

← Zurück zum Optimierungsleitfaden

Order-to-Cash-Attribute – Fakturierung & Abrechnung (18) Order-to-Cash-Aktivitäten – Fakturierung & Abrechnung (12) Extraktionsanleitungen (2)

Ihre Order-to-Cash – Rechnungsstellungs- und FakturierungsDatenvorlage

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

Empfohlene Attribute zur Erfassung
Wichtige Aktivitäten für das Tracking
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-Attribute – Fakturierung & Abrechnung

These are the recommended Daten 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 Identifikator für jede Customer Invoice, serving as the Primary Case-ID für the Billing Process.
Beschreibung Die Invoice Number ist der central Key that groups all Aktivitäten related to a single Billing Document. Es allows für a complete, end-to-end Analysis des Invoice Lebenszyklus, 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, Durchlaufzeit Calculation und Leistungsfähigkeit Monitoring für each Billing Transaction. Bedeutung This Attribute ist essential für tracking the entire Lebenszyklus einer Invoice, enabling the Analysis von Process Efficiency, Engpässe 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 Daten Entities like SalesInvoiceHeaderV2. Beispiele CIV-001254INV-2023-9876US-004321
	Aktivitätsname ActivityName	Der Name der Geschäftsaktivität oder den Antrag bearbeitet.es Ereignisse, das zu einem bestimmten Zeitpunkt im RechnungsLebenszyklus aufgetreten ist.
Beschreibung Dieses Attribut beschreibt einen spezifischen Schritt oder Meilenstein innerhalb des Abrechnungsprozesses, wie z. B. 'Rechnung erstellt', 'Rechnung freigegeben' oder 'Zahlung erhalten'. The Sequence dieser Aktivitäten forms the Prozessfluss. Analyzing the Aktivitäten ist wesentlich für Process Mining, as es allows für the Discovery von Prozessmodells, Identification von Variants und Measurement of Leistungsfähigkeit between different Steps. Bedeutung Es definiert die Steps im Process, allowing für die Visualization von Prozessdarstellung (Process Map)s, Analysis von Prozessvarianten und Identification von Engpässe 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 Änderungsprotokolls 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 `Zeitstempel`, `records` das `exact date and time` für jede `Aktivität` im `process`. Diese `data` sind `critical` für alle `time-based Process Mining analyses`. Es wird verwendet, um `Durchlaufzeiten between activities` zu berechnen, die `total duration` eines `case` zu `measure` und `process performance over time` zu `understand`. `Accurate and reliable Zeitstempel` sind die `foundation` für `KPIs` wie `Days Sales Outstanding` und `Invoice Generation Time`. Bedeutung This ist the Foundational Attribute für all Leistungsfähigkeit und Time-Related Analysis, enabling the Calculation von Durchlaufzeits, Dauers und Throughput to measure Process Efficiency. Datenquelle Zeitstempels 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 Zeitstempels. Beispiele 2023-04-15T10:22:15Z2023-05-01T14:05:00Z2023-05-10T09:00:30Z
	Abteilung Department	Die Business Department associated mit dem Benutzer oder den Antrag bearbeitet.er Activity.
Beschreibung This Attribute assigns an Activity oder Benutzer zu a specific Organizational Department, such as 'Accounts Receivable' oder 'Sales'. Es allows für a higher-level View of Process Leistungsfähigkeit than the individual Benutzer Level. Analyzing by Department helps in understanding Cross-Funktional Übergaben, comparing Efficiency between Teams, und identifying Department-Level Engpässe, as required by the 'Billing Department Activity Load' Dashboard. Bedeutung Ermöglicht eine `Leistungsfähigkeit`-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 BenutzerResponsible ID mit the Employee oder Benutzer Directory which contains Department Information. Beispiele Debitorenbuchhaltung (Accounts Receivable) (AR)FinanzenAbrechnungsvorgänge
	Kundenname CustomerName	Der Name des Kunden, an den die Rechnung ausgestellt wurde.
Beschreibung Der Customer Name provides a human-readable Identifikator 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 Verzögerungen. Es ist Key für Dashboards related to Customer Payment Behavior und Days Sales Outstanding Analysis. Bedeutung This allows für Prozessanalyse 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 Daten mit the Customer Master Daten Table, typically CustTable, based on the Customer Account Number. Beispiele Contoso GmbHFabrikam, Inc.Northwind Traders
	Rechnungsbetrag InvoiceAmount	Der Gesamtbetrag 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 wesentlich für calculating the Total Value of Outstanding Invoices und für DSO Calculations. Bedeutung Es ermöglicht eine Financial Impact Analysis, allowing Sie, 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`, in der Regel 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 Lebenszyklus (z.B., Open, Paid, Abbrechened).
Beschreibung Dieses Attribut liefert eine Momentaufnahme des aktuellen Rechnungsstatus. 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 Fälle to analyze only Open Invoices oder to confirm the Final Ergebnisse of a Closed Invoice. Es helps in understanding the current Workload und the Financial State of Receivables. Bedeutung Provides a quick Momentaufnahme des Invoice's current State, which ist useful für Filterung Fälle und Understanding the Resultate von different Prozessvarianten. Datenquelle Dies kann aus dem Payment Status der Invoice abgeleitet werden, often by checking if the Balance on the related CustTrans Datensatz ist zero. There isn't always a single 'Status' Field. Beispiele OffenBezahltÜberfälligStorniert
	Verantwortlicher Benutzer UserResponsible	Der Benutzer oder Employee responsible für executing a specific Activity.
Beschreibung This Attribute identifies the Individual who performed a particular Aufgabe im Billing Process, such as approving an Invoice oder applying Cash. Es ist crucial für Workload Analysis, Leistungsfähigkeit Comparison und identifying Schulungsbedarf. For example, the 'Billing Department Activity Load' Dashboard relies on this Attribute to see if Work ist distributed evenly oder if certain Nutzer are Engpässe. Es also helps in understanding Resource Allocation und Efficiency. Bedeutung Es enables Resource-Level Analysis, helping to identify Engpässe, measure individual or Team Leistungsfähigkeit, und analyze Workload Distribution across the Billing Department. Datenquelle Dies kann sourced werden from Workflow Änderungsprotokolls (z.B. WorkflowTrackingStatusTable) oder Eigentumsrechte Fields like Owner oder ModifiedBy on relevant Tables. Beispiele John SmithAlicia BakerSystemadministrator
	Zahlungsfälligkeitsdatum PaymentDueDate	Das Datum, bis zu dem der Kunde die Rechnung voraussichtlich bezahlen soll.
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 Leistungsfähigkeit. 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
	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 Quellsystem. Es ist calculated als the Dauer 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 Automatisierung 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 Automatisierung und reducing Manual Effort. Datenquelle This Information might be inferred from the Benutzer who posted the Payment (if it's not a System Benutzer) oder from specific Reason Codes used during Payment Reconciliation. Consult Microsoft Dynamics 365 Documentation. Beispiele JaNein
	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' Ereignisse 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 Fälle, Analysts can investigate the Root Causes of Rework, which often point to Process Inefficiencies, Daten Quality Issues, oder Training Gaps. Bedeutung This Flag directly quantifies Process Inefficiency by identifying Fälle mit Repetitive oder Corrective Actions, helping to pinpoint Root Causes of Waste und Delay. Datenquelle This Attribute ist not available im Quellsystem. Es ist calculated in der Daten Transformation Layer by checking für repeated Aktivitäten oder specific Rework Patterns within a Case. Beispiele JaNein
	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' Zeitstempel 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 Ergebnisse für Payment Leistungsfähigkeit, 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 Quellsystem. Es ist calculated during Daten Transformation by comparing the Payment Date to the PaymentDueDate. Beispiele JaNein
	Letzte Datenaktualisierung LastDataUpdate	Der Zeitstempel, der den Antrag bearbeitet.en Zeitpunkt der letzten Aktualisierung der Daten dieses Ereignisse aus dem Quellsystem angibt.
Beschreibung This Attribute records when the Daten was last extracted oder updated from Microsoft Dynamics 365. Es ist a Metadatenfeld that ist crucial für understanding the Freshness der Daten being analyzed. This helps Analysts und Business Nutzer know if they are looking at the most current Information und ist vital für managing Daten Refresh Schedules und ensuring the Reliability der Analysis. Bedeutung Es ensures Nutzer understand the recency of the Daten, which ist critical für Daten Governance, Dashboard Refresh Management und trusting the timeliness der Erkenntnisse. Datenquelle This Attribute ist generated und stamped onto the Datenset during the Daten Extraktion, 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 Daten. In this Context, es specifies that the Daten comes from Microsoft Dynamics 365. This ist important in Multi-System-Umgebungen to differentiate Datenquelles und ensure Daten Lineage ist clear, which aids in Daten Validierung und Fehlerbehebung. Bedeutung Es provides crucial Context about Daten Origin, which ist essential für Daten Governance, Validierung und wenn Merging Daten from multiple Unternehmenssysteme. 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
	Verkaufsauftragsnummer SalesOrderNumber	Die Kennung des Kundenauftrags, der den Antrag bearbeitet.ie Rechnung ausgelöst hat.
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 Verzögerungen, 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
	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`, in der Regel 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 nutzt dieses Attribut 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 Datensatz 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-Aktivitäten – Fakturierung & Abrechnung

Dies sind die wichtigsten Prozessschritte und Meilensteine, die Sie in Ihrem `Event Log` erfassen sollten, um eine präzise `Prozessanalyse (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 markiert das Ende des Prozesses.ks the Point where the Payment ist fully reconciled mit what was billed. Datenquelle Datensatzed in der CustSettlement Table. The Settlement Date Field on this Table provides the Zeitstempel 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 Zeitstempel 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 `Zeitstempel` 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 E-Mail, 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 `SysOutgoingE-MailTable` erfasst werden, wenn die E-Mail-`capabilities` von D365 geverwendet werden. Andernfalls wird oft angenommen, dass es der `invoice posting time` von `CustInvoiceJour` entspricht. Erfassen Use E-Mail Log Zeitstempel if available; otherwise, use the Invoice Posting Zeitstempel. 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 Lebenszyklus für eine Invoice. Es ist a critical Event für tracking Days Sales Outstanding (DSO) und overall Process Dauer. Datenquelle Erfasst vom `creation Zeitstempel` 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 Durchlaufzeit. Verzögerungen at this Stage can directly increase the Overall Time to receive Payment from the Customer. Datenquelle Datensatzed 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 `Aktivität` 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 Aktivitäten. Datenquelle This ist not erfasst als an Event. Es ist calculated by using the DueDate Field from the CustInvoiceJour Table. The Event Zeitstempel ist the Due Date itself. Erfassen Erstellen Sie ein `Event`, dessen `Zeitstempel` 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 Fehler, 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, erfasst 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 Dienste 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 Linien.
Bedeutung This Event serves as the Starting Point für measuring the Invoice Generation Durchlaufzeit. Understanding the Delay between Fulfillment und Invoicing helps identify Administrative Engpässe 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 Wartezeit. 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 Fehlers such as incorrect Posting, non-sufficient Funds, oder other Payment Failures.
Bedeutung Payment Reversals highlight Operational Fehlers 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 den Antrag bearbeitet.urch seine `relationship` zur `original transaction`. Erfassen Identifizieren Sie `journal entries` mit einem `reversal flag` oder einem `reference` zu einer `reversed transaction`. Ereignistyp explicit
	Zahlungserinnerung versandt	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 Zeitstempel from the CustCollectionLetterJour Table. Ereignistyp explicit

Extraktionsanleitungen

So rufen Sie Ihre Daten aus Microsoft Dynamics 365 ab

Schritte

Zum Daten Management Workspace bewältigen: Melden Sie sich bei Microsoft Dynamics 365 Finance and Operations an. Verwenden Sie die Suchleiste, um den Daten Management Workspace zu finden und dorthin zu bewältigen. Dies ist die zentrale Anlaufstelle für alle Datenimport- und -exportvorgänge.
Neues Exportprojekt erstellen: Im Daten 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 Daten Entities hinzufügen: Dies ist der kritischste Schritt. Sie werden mehrere Standard-Daten 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 analysierenn 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 Datenextraktion.
Daten ü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.
Daten modernisieren und kombinieren: Die raw files müssen in ein einziges Event Log umgewandelt werden. Verwenden Sie ein Datenaufbereitung 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 den Antrag bearbeitet.as Event darstellt, wie 'Invoice Generated') und Ereigniszeitpunkt (Event Time) (das relevante date field aus der source file). Map andere attributes wie InvoiceAmount und CustomerName.
Union All Transformed Daten: 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 Aktivität im invoice lifecycle darstellt.
Final Formatting for Upload: Stellen Sie sicher, dass die endgültige CSV-Datei die korrekten Spaltenüberschriften (InvoiceNumber, ActivityName, Ereigniszeitpunkt (Event Time) usw.) aufweist und dass die Ereigniszeitpunkt (Event Time)-Spalte in einem konsistenten Zeitstempel-Format (z.B. YYYY-MM-DD HH:MI:SS) vorliegt. Diese Datei ist nun bereit für den Upload in ProcessMind.

Konfiguration

Daten Entities: Die Extraktion basiert auf einer Reihe von Standard-D365-Daten 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 Daten Transformation-Tools.
Date Range Filterung: Es ist maßgeblich, 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 Filterung: Der Export sollte nach der spezifischen juristischen Person oder den Antrag bearbeitet.em Firmencode gefiltert werden, die Sie analysierenn, um die data-Relevanz zu sicherstellen und die Exportgröße zu reduzieren.
Daten 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 in der Regel mit Tools wie Power BI (Power Query), Python oder SQL.
Prerequisites: Der Benutzer, der den Antrag bearbeitet.en Export ausführt, muss über entsprechende Sicherheitsrollen in Dynamics 365 verfügen, in der Regel eine Rolle mit Berechtigungen für den Daten management Workspace und Zugriff auf die erforderlichen Daten 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 AnmeldeHinweisrmationen 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: Jetzt 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 Daten 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.
Daten Extraktion: 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“ Ereignisse zu erstellen.
Calculated Ereignisse: Beachten Sie, dass Ereignisse wie „Payment Due Date Reached“ und „Invoice Closed“ keine direkten Transaktionen in Dynamics 365 sind. Das Skript leitet diese Ereignisse 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 ODaten 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 Datensatz abzurufen.
Daten Transformation und Output: Nach dem Sammeln aller Ereignisse kompiliert das Skript sie in eine einzige list, konvertiert sie in ein pandas DatenFrame und standardisiert die column names zu InvoiceNumber, ActivityName, Ereigniszeitpunkt (Event Time) und anderen erforderlichen Attributes.
Export nach CSV: Schließlich speichert das Skript das resultierende DatenFrame 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 DatenAreaId 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 Datenset-Größe zu sicherstellen und gleichzeitig genügend Prozessvarianten zu erfassen.
Key ODaten 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.
Leistungsfähigkeit: 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()

Ihre Order-to-Cash – Rechnungsstellungs- und FakturierungsDatenvorlage

Ihre Order-to-Cash – Rechnungsstellungs- und FakturierungsDatenvorlage

Order-to-Cash-Attribute – Fakturierung & Abrechnung

Order-to-Cash-Aktivitäten – Fakturierung & Abrechnung

Extraktionsanleitungen

Microsoft Dynamics 365 Daten Entity Export

Schritte

Konfiguration

a Beispielabfrage config

Python Script using Dynamics 365 ODaten Web API

Schritte

Konfiguration

a Beispielabfrage python

Bereit, um loszulegen?

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

Ihre Order-to-Cash – Rechnungsstellungs- und FakturierungsDatenvorlage

Ihre Order-to-Cash – Rechnungsstellungs- und FakturierungsDatenvorlage

Order-to-Cash-Attribute – Fakturierung & Abrechnung

Order-to-Cash-Aktivitäten – Fakturierung & Abrechnung

Extraktionsanleitungen

Microsoft Dynamics 365 Daten Entity Export

Schritte

Konfiguration

a Beispielabfrage config

Python Script using Dynamics 365 ODaten 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