Ihr Daten-Template für Kreditorenzahlungen
Ihr Daten-Template für Kreditorenzahlungen
- Prozessspezifische Attribute für die Finanzanalyse
- Wichtige Aktivitätsmeilensteine für die Zahlungsverfolgung
- Detaillierte Anleitung zum Datenexport aus Dynamics 365
Attribute für die Kreditorenzahlungsabwicklung
| Name | Beschreibung | ||
|---|---|---|---|
| Aktivität Activity | Die konkrete Aufgabe oder Statusänderung, die stattgefunden hat. | ||
| Beschreibung Dieses Attribut beschreibt das Ereignis oder den Prozessschritt, etwa „Rechnung erstellt“, „Rechnung freigegeben“ oder „Zahlung gebucht“. Es macht aus technischen Transaktionstypen und Workflow-Statusänderungen verständliche Geschäftsereignisse. In Dynamics 365 werden Aktivitäten häufig aus einer Kombination von Tabelleneinträgen abgeleitet, etwa einem neuen Datensatz in Warum das wichtig ist Legt den Prozessablauf und die Ereignisfolge in der Prozessübersicht fest. Woher beziehen Aus verschiedenen Transaktionstabellen und Workflow-Verlaufsprotokollen abgeleitet Beispiele Rechnung erstelltRechnung freigegebenZahlung erstellt | |||
| Ereigniszeitpunkt EventTime | Der Timestamp, zu dem die Aktivität stattgefunden hat. | ||
| Beschreibung Dieses Attribut erfasst Datum und Uhrzeit einer bestimmten Aktivität. Es dient dazu, Ereignisse chronologisch zu ordnen und Zeitspannen zwischen Prozessschritten zu berechnen. In Dynamics 365 stammt der Wert je nach abgefragter Tabelle üblicherweise aus Warum das wichtig ist Unverzichtbar für die Berechnung von Zyklus- und Durchlaufzeiten sowie für die Ermittlung von Engpässen. Woher beziehen Systemfelder CreatedDateTime oder ModifiedDateTime in Transaktionstabellen Beispiele 2023-10-01T08:30:00Z2023-10-01T14:15:22Z2023-10-05T09:00:00Z | |||
| Rechnungsnummer InvoiceNumber | Eindeutige Kennung der Lieferantenrechnung. | ||
| Beschreibung Die Rechnungsnummer ist die eindeutige Case-ID für diese Prozessansicht. Sie fasst alle Ereignisse zu einer einzelnen Lieferantenrechnung zusammen und ermöglicht eine umfassende Analyse ihres Wegs vom Eingang bis zum Ausgleich. In Microsoft Dynamics 365 entspricht sie üblicherweise dem Feld Warum das wichtig ist Sie ist der zentrale Schlüssel, um getrennte Aktivitäten der Kreditorenbuchhaltung zu einer einzelnen Prozessinstanz zusammenzuführen. Woher beziehen Tabelle: VendInvoiceJour, Feld: InvoiceId Beispiele INV-2023-00198223344ACME-OCT-22 | |||
| Letzte Datenaktualisierung LastDataUpdate | Der Timestamp der Datenextraktion oder -aktualisierung. | ||
| Beschreibung Gibt an, wie aktuell die für die Analyse verwendeten Daten sind. So können Benutzer erkennen, ob sie Echtzeitdaten oder einen Datenstand aus einem früheren Zeitraum betrachten. Dieser Wert wird üblicherweise vom ETL-Prozess (Extract, Transform, Load) erzeugt und nicht in Dynamics 365 selbst gespeichert. Warum das wichtig ist Entscheidend für das Vertrauen in Dashboards und KPIs. Woher beziehen Vom Extraktionsskript erzeugt Beispiele 2023-10-25T12:00:00Z2023-11-01T06:00:00Z | |||
| Quellsystem SourceSystem | Der Name des Systems, aus dem die Daten stammen. | ||
| Beschreibung Gibt die Quellsoftware oder -umgebung an, aus der die Prozessdaten extrahiert wurden. In diesem Fall ist dies immer die Microsoft-Dynamics-365-Instanz. Das ist besonders hilfreich in Umgebungen mit mehreren Systemen, in denen Daten aus ERP-Systemen und externen Scanlösungen zusammengeführt werden. Warum das wichtig ist Sichert die Datenherkunft und Nachverfolgbarkeit bei Analysen über mehrere Systeme hinweg. Woher beziehen Bei der Extraktion fest codiert oder konfiguriert Beispiele Dynamics 365 F&OD365 PRODMicrosoft Dynamics | |||
| Abteilung Department | Die Abteilung, der die Kosten zugeordnet sind. | ||
| Beschreibung Die Finanzdimension, die die interne Abteilung angibt. In Dynamics 365 werden Dimensionen dynamisch gespeichert, häufig in Dieses Attribut wird in der Ansicht „Komplexität der Lieferantenbeziehungen“ verwendet, um zu ermitteln, welche internen Abteilungen das größte Kreditorenrechnungsvolumen verursachen. Warum das wichtig ist Ermöglicht eine detaillierte Analyse nach Organisationseinheit und der jeweiligen Verantwortlichkeit. Woher beziehen Tabelle: VendInvoiceJour, Feld: DefaultDimension (erfordert die Ansicht DimensionAttributeLevelValue) Beispiele ITFinanzenBetrieb | |||
| Benutzer-ID UserId | Die Kennung des Benutzers, der die Aktivität ausgeführt hat. | ||
| Beschreibung Gibt an, welcher Systembenutzer für eine bestimmte Aktivität verantwortlich war, etwa für die Freigabe einer Rechnung oder die Buchung einer Zahlung. Die Daten stammen aus den Feldern In der Analyse „Zahlungssperren und Prozesshindernisse“ lässt sich damit prüfen, ob bestimmte Bearbeiter häufiger Sperren auslösen als andere. Warum das wichtig ist Ermöglicht die Analyse des Benutzerverhaltens und der Funktionstrennung. Woher beziehen Systemfelder CreatedBy/ModifiedBy in Transaktions- und Verlaufstabellen Beispiele jdoeadminworkflow_sys | |||
| Bestellnummer PurchaseOrderNumber | Die Referenznummer der zugehörigen Bestellung. | ||
| Beschreibung Verknüpft die Rechnung mit dem ursprünglichen Einkaufsbeleg. In Dynamics 365 ist dies das Feld Dieses Attribut unterstützt das Dashboard „Abgleich von Bestellungen und Abweichungstrends“, indem es Rechnungen mit und ohne Bestellbezug unterscheidet. Warum das wichtig ist Unverzichtbar für die Analyse der Abgleichquote im Beschaffungs- und Zahlungsprozess. Woher beziehen Tabelle: VendInvoiceJour, Feld: PurchId Beispiele PO-000455000342PO-22-998 | |||
| Fälligkeitsdatum DueDate | Das Datum, bis zu dem die Rechnung bezahlt werden sollte. | ||
| Beschreibung Der vertraglich vereinbarte Termin, bis zu dem die Zahlung erfolgen muss, um Strafgebühren zu vermeiden. In Dynamics 365 wird dieses Datum als Es ist die maßgebliche Grundlage für die KPI „Pünktliche Zahlungsquote“ und hilft dabei, die Arbeit in der Ansicht „Durchsatz und Volumen im Kreditorenprozess“ zu priorisieren. Warum das wichtig ist Der Maßstab zur Messung der Pünktlichkeit von Zahlungen. Woher beziehen Tabelle: VendInvoiceJour oder VendTrans, Feld: DueDate Beispiele 2023-11-302023-12-15 | |||
| Lieferantenkonto VendorAccount | Die eindeutige Kontonummer des Lieferanten. | ||
| Beschreibung Die eindeutige Kennung des an der Transaktion beteiligten Lieferanten. In Dynamics 365 entspricht sie dem Feld Dieses Attribut ist zentral für die Ansicht „Komplexität der Lieferantenbeziehungen“. Damit lassen sich Leistung und Reibungspunkte für einzelne Lieferantenbeziehungen analysieren. Warum das wichtig ist Ermöglicht die Segmentierung der Prozessleistung nach Lieferant. Woher beziehen Tabelle: VendInvoiceJour, Feld: InvoiceAccount oder OrderAccount Beispiele US-101V000452001 | |||
| Lieferantenname VendorName | Der Name des Lieferantenunternehmens. | ||
| Beschreibung Der ausgeschriebene Name des Lieferanten. In D365 verweist das Lieferantenkonto als Fremdschlüssel auf das globale Adressbuch ( Lesbare Namen erleichtern die Nutzung der Ansicht „Komplexität der Lieferantenbeziehungen“ und machen Dashboards auch für Fachanwender zugänglich. Warum das wichtig ist Ergänzt die Lieferantenkontonummer um den Namen des Lieferanten. Woher beziehen Tabelle: DirPartyTable (über VendTable), Feld: Name Beispiele Contoso-BürobedarfFabrikam-ElektronikLitware Inc. | |||
| Rechnungsbetrag InvoiceAmount | Der Gesamtbetrag der Rechnung. | ||
| Beschreibung Der Gesamtbetrag der Rechnung in der Transaktionswährung. In Dynamics 365 ist dieser Wert in Feldern wie Wird im Dashboard zur Erkennung des Risikos doppelter Zahlungen verwendet, um Beträge mit Lieferantendaten abzugleichen. Warum das wichtig ist Entscheidend für die Analyse des Ausgabenvolumens und finanzieller Risiken. Woher beziehen Tabelle: VendInvoiceJour, Feld: InvoiceAmount Beispiele 1500.00245.5010000.00 | |||
| Rechnungsdatum InvoiceDate | Das auf der Rechnung angegebene Belegdatum. | ||
| Beschreibung Das auf der Lieferantenrechnung aufgedruckte Datum. In Dynamics 365 ist dies das Feld Wird in der „End-to-End-Durchlaufzeitanalyse“ verwendet, um den gesamten Prozess aus Sicht des Lieferanten zu messen. Warum das wichtig ist Legt den Beginn des Alterungszeitraums der Rechnung fest. Woher beziehen Tabelle: VendInvoiceJour, Feld: InvoiceDate Beispiele 2023-10-012023-10-15 | |||
| Unternehmenscode CompanyCode | Die Kennung der juristischen Person oder Tochtergesellschaft. | ||
| Beschreibung Gibt die juristische Person innerhalb der Organisation an, in der die Rechnung bearbeitet wird. In Microsoft Dynamics 365 wird sie über das Systemfeld Dieses Attribut ist für die Analyse der Gesamtdurchlaufzeit wichtig. Es ermöglicht Vergleiche zwischen Tochtergesellschaften und geografischen Einheiten. Warum das wichtig ist Ermöglicht Vergleiche zwischen verschiedenen Geschäftseinheiten oder Ländern. Woher beziehen Tabelle: VendInvoiceJour, Feld: DataAreaId Beispiele USMFDEMFGBSI | |||
| Belegnummer VoucherNumber | Die zur Transaktion gehörende Hauptbuch-Belegnummer. | ||
| Beschreibung Die interne Kennung des Hauptbuchs für den Buchungssatz. In Dynamics 365 verknüpft das Feld Die Kennung ist zwar technischer Natur, hilft aber bei der „Prüfung von Prozesspfad und Compliance“, Buchungen für den Abgleich bis ins Hauptbuch zurückzuverfolgen. Warum das wichtig ist Wichtige Kennung für Finanzprüfungen und den Abgleich. Woher beziehen Tabelle: VendInvoiceJour, Feld: LedgerVoucher Beispiele VOU-10023INV-ACC-992 | |||
| Skontofrist CashDiscountDate | Der Termin, bis zu dem die Zahlung erfolgen muss, damit ein Skonto gewährt wird. | ||
| Beschreibung Die Frist, bis zu der Skontovorteile in Anspruch genommen werden können. In Dynamics 365 ist dies das Feld Dieses Attribut bildet die Grundlage für das Dashboard „Nutzung von Skonti“ und zeigt, welche Einsparmöglichkeiten ungenutzt bleiben. Warum das wichtig ist Wirkt sich direkt auf die KPI zur finanziellen Effizienz des Prozesses aus. Woher beziehen Tabelle: VendInvoiceJour oder VendTrans, Feld: CashDiscDate Beispiele 2023-10-102023-10-20 | |||
| Währung Currency | Der Währungscode der Rechnung. | ||
| Beschreibung Der ISO-Code der Währung, in der die Rechnung ausgestellt wurde. In Dynamics 365 ist dies das Feld Wichtig für die Vereinheitlichung von Beträgen bei der Zuordnung von „Aktivitätsbetrag“, wenn Beträge aus verschiedenen Währungen umgerechnet werden müssen. Warum das wichtig ist Notwendiger Kontext für die Interpretation von Finanzwerten. Woher beziehen Tabelle: VendInvoiceJour, Feld: CurrencyCode Beispiele USDEURGBP | |||
| Zahlung gesperrt IsPaymentBlocked | Kennzeichnet, ob die Rechnung derzeit für die Zahlung gesperrt ist. | ||
| Beschreibung Ein boolescher Wert, der angibt, ob die Rechnung zurückgestellt ist. In Dynamics 365 wird dieser Wert häufig aus dem Status Dieser Wert ist die zentrale Grundlage für die Analyse „Zahlungssperren und Prozesshindernisse“ und macht Unterbrechungen im Prozess sichtbar. Warum das wichtig ist Macht unmittelbare Hindernisse und manuelle Eingriffe sichtbar. Woher beziehen Tabelle: VendTrans, Feld: Approved (invertiert) oder spezielle Sperrfelder Beispiele truefalse | |||
| Zahlungsbedingungen PaymentTerms | Der Code für die vereinbarten Zahlungsbedingungen. | ||
| Beschreibung Der Konfigurationscode, der Fälligkeitstermine und Skonti festlegt, zum Beispiel Net30. In Dynamics 365 ist dies das Feld Wird zusammen mit der „Zykluszeit“ analysiert, um festzustellen, ob Prozessverzögerungen gegen die vereinbarten Bedingungen verstoßen. Warum das wichtig ist Liefert den Kontext für die Berechnung des Fälligkeitstermins. Woher beziehen Tabelle: VendInvoiceJour, Feld: PaymTermId Beispiele Net302%10Net30COD | |||
| Zahlungsmethode PaymentMethod | Die Methode, mit der die Rechnung bezahlt wird, zum Beispiel per Scheck, Überweisung oder EFT. | ||
| Beschreibung Legt fest, wie die Gelder an den Lieferanten überwiesen werden. In Dynamics 365 ist dies das Feld Dieses Attribut wird im Dashboard „Durchlaufzeiten der Zahlungsausführung“ verwendet, um die Effizienz verschiedener Zahlungsläufe zu bewerten. Warum das wichtig ist Erklärt Abweichungen in der Phase der Zahlungsausführung. Woher beziehen Tabelle: VendInvoiceJour (verknüpft mit den PaymMode-Informationen) oder VendTrans Beispiele ScheckACHÜberweisung | |||
Aktivitäten bei der Kreditorenzahlungsabwicklung
| Aktivität | Beschreibung | ||
|---|---|---|---|
| Rechnung erstellt | Im System wird ein offener Datensatz für eine Lieferantenrechnung angelegt. Damit gelangt die Rechnung in den Workflow von Dynamics 365, entweder durch manuelle Erfassung oder durch den Import einer Datenentität. | ||
| Warum das wichtig ist Legt den Startzeitpunkt für die Berechnung der Prozessdurchlaufzeit fest. So können Organisationen messen, wie lange Rechnungen im System liegen, bevor sie bearbeitet oder gebucht werden. Woher beziehen Zeitstempel der Erstellung von VendInvoiceInfoTable.CreatedDateTime oder VendInvoiceInfoTable.RecId. Dieser Wert bezieht sich auf den Kopf der offenen Lieferantenrechnung. Erfassung Wird protokolliert, wenn ein Datensatz in VendInvoiceInfoTable erstellt wird Ereignistyp explicit | |||
| Rechnung freigegeben | Die Workflow-Instanz der offenen Rechnung erreicht den Status „abgeschlossen“ oder „freigegeben“. Die Rechnung kann nun im Hauptbuch gebucht werden. | ||
| Warum das wichtig ist Berechnet die durchschnittliche Freigabedurchlaufzeit. Verzögerungen in dieser Phase wirken sich direkt darauf aus, ob Skonti für frühzeitige Zahlungen genutzt werden können. Woher beziehen WorkflowTrackingStatusTable.CreatedDateTime, wenn TrackingStatus Completed lautet. Alternativ gilt VendInvoiceInfoTable.RequestStatus gleich Approved. Erfassung Wird protokolliert, wenn eine Workflow-Instanz abgeschlossen wird Ereignistyp explicit | |||
| Rechnung gebucht | Die Rechnung wird im Hauptbuch gebucht und als Verbindlichkeit im System erfasst. Der Datensatz wechselt aus den Tabellen für offene Rechnungen in die Tabellen für gebuchte Transaktionen. | ||
| Warum das wichtig ist Ein wichtiger Meilenstein, der die bilanzielle Erfassung der Verbindlichkeit markiert. Ab diesem Zeitpunkt kann die Rechnung für eine Zahlung ausgewählt werden. Woher beziehen Erstellung eines Datensatzes in VendInvoiceJour und VendTrans. TransDate gibt das Buchungsdatum an. Erfassung Wird protokolliert, wenn Transaktion X ausgeführt wird Ereignistyp explicit | |||
| Rechnung mit Bestellung abgeglichen | Das System verknüpft die Rechnungszeile erfolgreich mit einer Bestellung oder einem Wareneingang. Diese Aktivität zeigt, dass die Rechnung mit der Beschaffungsbestellung abgeglichen wurde. | ||
| Warum das wichtig ist Entscheidend für die KPI „Abgleichsquote mit Bestellung im ersten Durchlauf“. Die Kennzahl unterscheidet zwischen einer Verarbeitung ohne manuelle Eingriffe und Rechnungen, die manuell bearbeitet werden müssen. Woher beziehen VendInvoiceInfoLine.PurchId und VendInvoiceInfoTable.MatchStatus. Wird abgeleitet, wenn sich MatchStatus in Passed ändert. Erfassung MatchStatus-Feld vorher und nachher vergleichen Ereignistyp inferred | |||
| Zahlung erstellt | Das System erstellt die Zahlungsdatei (EFT, ISO20022) oder druckt Schecks. Der Zahlungsstatus der Journalzeile wird auf Sent oder Generated gesetzt. | ||
| Warum das wichtig ist Unterstützt die KPI zur Verzögerung zwischen Freigabe und Ausführung. Bestätigt, dass der Zahlungsauftrag erstellt wurde. Woher beziehen LedgerJournalTrans.PaymentStatus ändert sich in Sent/Recieved. Häufig wird die Aktivität anhand von Aktualisierungen der Zeile abgeleitet. Erfassung PaymentStatus-Feld vorher und nachher vergleichen Ereignistyp inferred | |||
| Zahlung gebucht | Das Zahlungsjournal wird im Hauptbuch gebucht. Damit wird die Rechnung ausgeglichen und der Lieferantensaldo beglichen. Der Finanzprozess ist damit abgeschlossen. | ||
| Warum das wichtig ist Die letzte Aktivität für die durchschnittliche Durchlaufzeit von Rechnung bis Zahlung. Sie bestätigt, dass die Buchungen zur Verringerung des Kassenbestands abgeschlossen sind. Woher beziehen LedgerJournalTrans wird gebucht. VendTrans wird aktualisiert, um den Ausgleich anzuzeigen. Das tatsächliche Ereignis ist die Buchung des Journals. Erfassung Wird protokolliert, wenn Transaktion X ausgeführt wird Ereignistyp explicit | |||
| Zahlungsjournal erstellt | Die Rechnung wird ausgewählt und einer Zeile im Zahlungsjournal hinzugefügt. Das zeigt die Zahlungsabsicht an und startet üblicherweise den Workflow zur Zahlungsprüfung. | ||
| Warum das wichtig ist Markiert den Übergang von der Verbindlichkeit zur Zahlungsabwicklung. Dient zur Messung der Durchlaufzeiten bei der Zahlungsausführung. Woher beziehen LedgerJournalTrans.CreatedDateTime. Die Rechnung wird über das Feld MarkedInvoice oder über Abrechnungstabellen verknüpft. Erfassung Wird protokolliert, wenn ein Datensatz in LedgerJournalTrans erstellt wird Ereignistyp explicit | |||
| Rechnung aktualisiert | Erfasst Änderungen am Rechnungskopf oder an den Rechnungszeilen vor der Buchung. Häufige Aktualisierungen können auf Probleme bei der Datenextraktion oder auf manuelle Korrekturen während der Validierung hindeuten. | ||
| Warum das wichtig ist Häufige Aktualisierungen deuten auf Nacharbeitsschleifen oder eine schlechte Datenqualität in der Quelle hin, etwa durch OCR-Fehler. Diese Aktivität unterstützt den Monitor für Nacharbeit und Datengenauigkeit. Woher beziehen Datenbankprotokoll (SysDatabaseLog) für VendInvoiceInfoTable, sofern aktiviert. Alternativ lässt sich die Aktivität anhand von Änderungen an ModifiedDateTime ableiten, wenn die Abfrage häufig genug erfolgt. Erfassung ModifiedDateTime in aufeinanderfolgenden Extraktionen vergleichen Ereignistyp inferred | |||
| Rechnung zur Freigabe eingereicht | Die offene Rechnung wird zur Prüfung an die Workflow-Engine übermittelt. Damit beginnt nach der Datenerfassung und dem Abgleich die Freigabephase. | ||
| Warum das wichtig ist Markiert den Beginn der Freigabezykluszeit. Unverzichtbar für die Analyse der Effizienz interner Hierarchien. Woher beziehen WorkflowTrackingStatusTable.CreatedDateTime, wenn ContextTableId der ID von VendInvoiceInfoTable entspricht und der Status Submitted lautet. Erfassung Wird protokolliert, wenn eine Workflow-Instanz gestartet wird Ereignistyp explicit | |||
| Rechnungsabgleich fehlgeschlagen | Beim Abgleich wird eine Abweichung zwischen Rechnung und Bestellung oder Wareneingang festgestellt, etwa beim Preis oder bei der Menge. Häufig wird der Prozess angehalten, bis die Abweichung geklärt ist. | ||
| Warum das wichtig ist Zeigt konkrete Reibungspunkte beim Abgleich. Unterstützt das Dashboard für Bestellabgleich und Abweichungstrends. Woher beziehen VendInvoiceInfoTable.MatchStatus ändert sich in Failed oder Discrepancy. Abweichungen sind auch in den Abgleichsdaten von VendInvoiceInfoLine sichtbar. Erfassung MatchStatus-Feld vorher und nachher vergleichen Ereignistyp inferred | |||
| Zahlungsjournal freigegeben | Der Workflow des Zahlungsjournals wird freigegeben und damit die Erstellung der Zahlungen autorisiert. Dies ist die letzte Prüfung, bevor die Mittel für die Überweisung bereitgestellt werden. | ||
| Warum das wichtig ist Trennt die administrative Vorbereitung von Zahlungen vom Engpass bei der Freigabe. Woher beziehen WorkflowTrackingStatusTable mit Verknüpfung zur ID der LedgerJournalTable (Kopf). Der Status lautet Completed. Erfassung Wird protokolliert, wenn eine Workflow-Instanz abgeschlossen wird Ereignistyp explicit | |||
| Zahlungssperre gesetzt | Die Lieferantentransaktion wird gesperrt und kann dadurch nicht in einen Zahlungsvorschlag aufgenommen werden. Das geschieht häufig manuell bei Streitfällen. | ||
| Warum das wichtig ist Unterstützt die Analyse von Zahlungssperren und Reibungspunkten. Macht manuelle Eingriffe sichtbar, die den Mittelabfluss verzögern. Woher beziehen Das Flag VendTrans.Approved wird auf No gesetzt oder bestimmte Statusfelder für OnHold werden befüllt. Dafür müssen Aktualisierungen an VendTrans nachverfolgt werden. Erfassung Statusfeld vorher und nachher vergleichen Ereignistyp inferred | |||
Anleitungen zum Datenexport
Schritte
Datenverwaltungsarbeitsbereich öffnen: Melden Sie sich bei Ihrer Microsoft-Dynamics-365-Finance-Umgebung an. Navigieren Sie zu „Arbeitsbereiche“ und wählen Sie „Datenverwaltung“. Hier konfigurieren Sie Datenexportprojekte.
Exportprojekt erstellen: Klicken Sie auf die Kachel „Export“, um ein neues Datenprojekt anzulegen. Geben Sie einen aussagekräftigen Namen ein, zum Beispiel ProcessMining_AP_Export. Wählen Sie im Feld „Zieldatenformat“ das Zielformat aus, etwa Azure SQL DB für BYOD oder CSV für einen dateibasierten Export.
Datenentitäten hinzufügen: Fügen Sie dem Projekt nacheinander die folgenden Standarddatenentitäten hinzu: VendorInvoiceHeaderEntity (ausstehende Rechnungen), VendorInvoiceLineEntity (Rechnungspositionen), VendorInvoiceJournalHeaderEntity (gebuchte Rechnungen), VendorPaymentJournalLineEntity (Zahlungen) und WorkflowHistoryEntity (Freigabeprotokolle). Falls WorkflowHistoryEntity nicht standardmäßig verfügbar ist, müssen Sie möglicherweise eine benutzerdefinierte Entität oder eine für den Export bereitgestellte Systementität aktivieren.
Entitätsfilter konfigurieren: Klicken Sie bei jeder Entität auf das Filtersymbol. Beschränken Sie die Daten auf die relevante CompanyInfo (DataAreaId) und legen Sie im Feld CreatedDateTime oder InvoiceDate einen Zeitraum fest, damit nur Daten aus dem gewünschten Analysezeitraum exportiert werden, zum Beispiel der letzten 12 Monate.
Wiederkehrenden Export einrichten: Richten Sie einen wiederkehrenden Datenauftrag ein, damit das Event Log aktuell bleibt. Legen Sie die Häufigkeit fest, zum Beispiel täglich oder stündlich, und aktivieren Sie, sofern verfügbar, Incremental push. Dadurch werden nur geänderte Datensätze exportiert und die Systemlast sinkt.
Ersten Export ausführen: Starten Sie das Projekt zunächst manuell, indem Sie auf „Jetzt exportieren“ klicken. Prüfen Sie die Ausführungsübersicht und stellen Sie sicher, dass alle Datensätze fehlerfrei exportiert wurden.
Daten transformieren: Sobald die Daten am Zielort (Azure SQL oder Dateien) vorliegen, führen Sie die Tabellen mit dem SQL-Skript aus dem Abschnitt „Abfrage“ zusammen. Die Transformationslogik führt die Datensätze aus den einzelnen Entitäten zu einem chronologischen Event Log zusammen.
Attribute zuordnen: Ordnen Sie im resultierenden Datensatz InvoiceNumber der Case-ID, EventTime dem Timestamp und Activity der Aktivität zu, wie es das Process-Mining-Tool erfordert.
Daten prüfen und hochladen: Führen Sie die unten aufgeführten Prüfungen durch, um die Datenqualität zu bestätigen. Exportieren Sie das geprüfte Ergebnis anschließend als CSV- oder Parquet-Datei und laden Sie es in ProcessMind hoch.
Konfiguration
- Entitätsauswahl: Verwenden Sie VendorInvoiceHeaderEntity und VendorInvoiceLineEntity für Prozessschritte vor der Buchung. Verwenden Sie VendorInvoiceJournalHeaderEntity für das rechtsgültige, gebuchte Dokument und VendorPaymentJournalLineEntity für die Zahlungsverfolgung.
- Incremental Push: Aktivieren Sie diese Einstellung im Datenverwaltungsprojekt, damit nach dem ersten vollständigen Ladevorgang nur neue oder geänderte Datensätze exportiert werden. Das ist wichtig für die Leistung.
- Datumsbereiche: Filtern Sie nach InvoiceDate >= [Start Date]. Vermeiden Sie Exporte ohne Begrenzung, da sie wegen einer Zeitüberschreitung abbrechen können.
- Unternehmensfilter: D365 unterstützt mehrere Rechtseinheiten. Filtern Sie immer nach DataAreaId, damit Daten verschiedener Rechtseinheiten nicht vermischt werden, es sei denn, Sie möchten unternehmensübergreifend analysieren.
- Workflow-Verlauf: Standardentitäten für den Workflow-Verlauf können umfangreiche Daten enthalten. Exportieren Sie nur den Verlauf zu VendInvoice-Typen, damit das Datenvolumen überschaubar bleibt.
a Beispielabfrage sql
/*
SQL Transformation Script for D365 Finance AP Process
Assumes data is loaded into Staging tables in a SQL environment (BYOD/Data Lake)
*/
SELECT
I.InvoiceNumber AS [InvoiceNumber],
'Invoice Created' AS [Activity],
I.CreatedDateTime AS [EventTime],
I.DataAreaId AS [CompanyCode],
I.InvoiceAccount AS [VendorAccount],
I.InvoiceAmount AS [InvoiceAmount],
I.CurrencyCode AS [Currency],
'D365 FO' AS [SourceSystem],
GETDATE() AS [LastDataUpdate]
FROM Staging_VendorInvoiceHeaderEntity I
UNION ALL
/* Capture updates to invoice headers */
SELECT
I.InvoiceNumber,
'Invoice Updated',
I.ModifiedDateTime,
I.DataAreaId,
I.InvoiceAccount,
I.InvoiceAmount,
I.CurrencyCode,
'D365 FO',
GETDATE()
FROM Staging_VendorInvoiceHeaderEntity I
WHERE I.ModifiedDateTime > I.CreatedDateTime
UNION ALL
/* Invoice Matching Activities */
SELECT
I.InvoiceNumber,
'Invoice Matched to PO',
I.ModifiedDateTime,
I.DataAreaId,
I.InvoiceAccount,
I.InvoiceAmount,
I.CurrencyCode,
'D365 FO',
GETDATE()
FROM Staging_VendorInvoiceHeaderEntity I
WHERE I.MatchStatus = 'Matched' -- Adjust value based on system config
UNION ALL
SELECT
I.InvoiceNumber,
'Invoice Match Failed',
I.ModifiedDateTime,
I.DataAreaId,
I.InvoiceAccount,
I.InvoiceAmount,
I.CurrencyCode,
'D365 FO',
GETDATE()
FROM Staging_VendorInvoiceHeaderEntity I
WHERE I.MatchStatus = 'Failed'
UNION ALL
/* Workflow Activities */
SELECT
RelatedContext AS InvoiceNumber,
CASE
WHEN Status = 'Submitted' THEN 'Invoice Submitted for Approval'
WHEN Status = 'Approved' THEN 'Invoice Approved'
ELSE 'Workflow Activity'
END AS [Activity],
CreatedDateTime AS [EventTime],
DataAreaId,
NULL AS [VendorAccount],
NULL AS [InvoiceAmount],
NULL AS [Currency],
'D365 FO',
GETDATE()
FROM Staging_WorkflowHistoryEntity
WHERE ContextTableId = 12345 -- Replace with TableId for VendInvoiceInfoTable
AND Status IN ('Submitted', 'Approved')
UNION ALL
/* Invoice Posted */
SELECT
J.InvoiceNumber,
'Invoice Posted',
J.PostedDateTime,
J.DataAreaId,
J.InvoiceAccount,
J.InvoiceAmount,
J.CurrencyCode,
'D365 FO',
GETDATE()
FROM Staging_VendorInvoiceJournalHeaderEntity J
UNION ALL
/* Payment Block */
SELECT
I.InvoiceNumber,
'Payment Block Applied',
I.ModifiedDateTime,
I.DataAreaId,
I.InvoiceAccount,
I.InvoiceAmount,
I.CurrencyCode,
'D365 FO',
GETDATE()
FROM Staging_VendorInvoiceJournalHeaderEntity I
WHERE I.OnHold = 'Yes'
UNION ALL
/* Payment Activities */
SELECT
J.InvoiceId AS [InvoiceNumber],
'Payment Journal Created' AS [Activity],
P.CreatedDateTime AS [EventTime],
P.DataAreaId,
P.AccountDisplayValue AS [VendorAccount],
P.DebitAmount AS [InvoiceAmount],
P.CurrencyCode,
'D365 FO',
GETDATE()
FROM Staging_VendorPaymentJournalLineEntity P
JOIN Staging_VendorInvoiceJournalHeaderEntity J ON P.InvoiceId = J.InvoiceNumber AND P.DataAreaId = J.DataAreaId
UNION ALL
SELECT
J.InvoiceId AS [InvoiceNumber],
'Payment Journal Approved' AS [Activity],
P.ModifiedDateTime AS [EventTime],
P.DataAreaId,
P.AccountDisplayValue,
P.DebitAmount,
P.CurrencyCode,
'D365 FO',
GETDATE()
FROM Staging_VendorPaymentJournalLineEntity P
JOIN Staging_VendorInvoiceJournalHeaderEntity J ON P.InvoiceId = J.InvoiceNumber AND P.DataAreaId = J.DataAreaId
WHERE P.PaymentStatus = 'Approved'
UNION ALL
SELECT
J.InvoiceId AS [InvoiceNumber],
'Payment Generated' AS [Activity],
P.ModifiedDateTime AS [EventTime],
P.DataAreaId,
P.AccountDisplayValue,
P.DebitAmount,
P.CurrencyCode,
'D365 FO',
GETDATE()
FROM Staging_VendorPaymentJournalLineEntity P
JOIN Staging_VendorInvoiceJournalHeaderEntity J ON P.InvoiceId = J.InvoiceNumber AND P.DataAreaId = J.DataAreaId
WHERE P.PaymentStatus = 'Sent'
UNION ALL
SELECT
J.InvoiceId AS [InvoiceNumber],
'Payment Posted' AS [Activity],
P.PostedDate AS [EventTime],
P.DataAreaId,
P.AccountDisplayValue,
P.DebitAmount,
P.CurrencyCode,
'D365 FO',
GETDATE()
FROM Staging_VendorPaymentJournalLineEntity P
JOIN Staging_VendorInvoiceJournalHeaderEntity J ON P.InvoiceId = J.InvoiceNumber AND P.DataAreaId = J.DataAreaId
WHERE P.IsPosted = 'Yes' Schritte
BYOD-Verbindung prüfen: Stellen Sie sicher, dass SQL Server Management Studio (SSMS) oder ein vergleichbares Tool installiert ist und Sie eine Verbindung zur Azure-SQL-Datenbank herstellen können, die in Ihrer Dynamics-365-Finance-&-Operations-Umgebung als BYOD-Ziel (Bring Your Own Database) eingerichtet ist.
Entitätsexport überprüfen: Öffnen Sie in Dynamics 365 den Arbeitsbereich Datenverwaltung. Prüfen Sie, ob die folgenden Entitäten oder die zugrunde liegenden Tabellen für den Export in die BYOD-Datenbank konfiguriert sind:
VendInvoiceInfoTable(ausstehende Rechnungen),VendInvoiceInfoLine(ausstehende Rechnungspositionen),VendInvoiceJour(gebuchte Rechnungen),VendTrans(Kreditorentransaktionen),LedgerJournalTrans(Journalzeilen),LedgerJournalTable(Journalüberschriften) undWorkflowTrackingStatusTable(Workflow-Verlauf).Exportauftrag konfigurieren: Falls diese Tabellen noch nicht exportiert werden, erstellen Sie einen neuen Exportauftrag. Legen Sie Ihre BYOD-SQL-Datenbank als Zieldatenformat fest. Wählen Sie Incremental Push, damit die Daten ohne vollständigen erneuten Export synchronisiert werden. Führen Sie den Auftrag aus, um die Tabellen zu befüllen.
SQL-Umgebung vorbereiten: Öffnen Sie SSMS und stellen Sie eine Verbindung zur BYOD-Azure-SQL-Datenbank her. Öffnen Sie ein neues Abfragefenster.
Parameter festlegen: Suchen Sie im bereitgestellten Skript oben nach den Variablendeklarationen. Passen Sie die Variablen
@StartDateund@EndDatean den gewünschten Analysezeitraum an. Wenn Sie nach einer bestimmten Rechtseinheit filtern möchten, ändern Sie die Filterbedingungen fürDATAAREAID.Skript ausführen: Führen Sie das vollständige T-SQL-Skript aus. Es verwendet
UNION ALL, um Daten aus mehreren Tabellen in einem standardisierten Event-Log-Format zusammenzuführen.Daten prüfen: Prüfen Sie, ob die Spalten
InvoiceNumberoderEventTimeNullwerte enthalten. Stellen Sie sicher, dass sowohl gebuchte Rechnungen ausVendInvoiceJourals auch ausstehende Rechnungen ausVendInvoiceInfoTableenthalten sind.Ergebnis exportieren: Klicken Sie in SSMS mit der rechten Maustaste auf das Ergebnisraster und wählen Sie Ergebnisse speichern unter.... Speichern Sie die Datei als CSV-Datei (durch Trennzeichen getrennt).
Für den Upload formatieren: Öffnen Sie die CSV-Datei in Excel oder einem Texteditor und prüfen Sie, ob die Datumsangaben dem ISO-8601-Format (YYYY-MM-DD HH:MM:SS) entsprechen, sofern ProcessMind dies erfordert. Wenn das Skript erfolgreich ausgeführt wurde, sind keine weiteren Transformationen nötig.
In ProcessMind hochladen: Importieren Sie die CSV-Datei in ProcessMind. Ordnen Sie die Spalten
InvoiceNumberder Case-ID,Activityder Aktivität undEventTimedem Timestamp zu.
Konfiguration
- Exportstrategie: Verwenden Sie für Tabellen mit hohem Datenvolumen wie
LedgerJournalTransundVendTransIncremental Push, um die BYOD-Last zu verringern. Verwenden Sie Full Push nur, wenn Sie Inkonsistenzen in den Daten vermuten. - Zeitzonen: Dynamics 365 speichert Daten in UTC. Das Skript geht von UTC aus. Wenn Sie Ortszeit analysieren möchten, ergänzen Sie das Skript oder den ProcessMind-Import um eine
DATEADD-Anpassung. - Unternehmensfilter: Die Spalte
DataAreaIdsteht für die Rechtseinheit. Standardmäßig extrahiert das Skript Daten aus allen Rechtseinheiten. Ergänzen SieWHERE DataAreaId = 'usmf'(Beispiel), um nach einer bestimmten Tochtergesellschaft zu filtern. - Workflow-Verlauf: Die Tabelle
WorkflowTrackingStatusTableenthält wichtige Zeitstempel für Freigaben. Nehmen Sie sie in die BYOD-Exportkonfiguration auf, da sie standardmäßig häufig nicht enthalten ist. - Datenaufbewahrung: Beachten Sie Bereinigungsroutinen in D365, die abgeschlossene Workflow-Verläufe oder gebuchte Journalzeilen löschen können. Dadurch wird der Zeitraum begrenzt, der für die Process-Mining-Analyse zur Verfügung steht.
a Beispielabfrage sql
/* T-SQL Extraction Script for D365 AP Payment Processing */
/* Tables required: VendInvoiceInfoTable, VendInvoiceInfoLine, VendInvoiceJour, VendTrans, LedgerJournalTrans, LedgerJournalTable, WorkflowTrackingStatusTable */
DECLARE @StartDate DATETIME = '2023-01-01 00:00:00';
DECLARE @EndDate DATETIME = GETDATE();
WITH RawData AS (
/* 1. Invoice Created: Pending Invoice Header Creation */
SELECT
T1.Num AS InvoiceNumber,
'Invoice Created' AS Activity,
T1.CreatedDateTime AS EventTime,
'D365 FO' AS SourceSystem,
GETDATE() AS LastDataUpdate,
T1.InvoiceAccount AS VendorAccount,
T1.DataAreaId AS CompanyCode,
CAST(T1.InvoiceAmount AS DECIMAL(18,2)) AS InvoiceAmount,
T1.DueDate AS DueDate,
T1.PurchId AS PurchaseOrderNumber,
T1.CreatedBy AS UserId,
T1.VendorName AS VendorName,
T1.DocumentDate AS InvoiceDate,
'Unknown' AS Department
FROM dbo.VendInvoiceInfoTable T1
WHERE T1.CreatedDateTime BETWEEN @StartDate AND @EndDate
UNION ALL
/* 2. Invoice Updated: Modifications to Pending Invoice */
SELECT
T1.Num AS InvoiceNumber,
'Invoice Updated' AS Activity,
T1.ModifiedDateTime AS EventTime,
'D365 FO' AS SourceSystem,
GETDATE() AS LastDataUpdate,
T1.InvoiceAccount AS VendorAccount,
T1.DataAreaId AS CompanyCode,
CAST(T1.InvoiceAmount AS DECIMAL(18,2)) AS InvoiceAmount,
T1.DueDate AS DueDate,
T1.PurchId AS PurchaseOrderNumber,
T1.ModifiedBy AS UserId,
T1.VendorName AS VendorName,
T1.DocumentDate AS InvoiceDate,
'Unknown' AS Department
FROM dbo.VendInvoiceInfoTable T1
WHERE T1.ModifiedDateTime BETWEEN @StartDate AND @EndDate
AND T1.ModifiedDateTime > T1.CreatedDateTime
UNION ALL
/* 3. Invoice Matched to PO: Line Matching Success */
SELECT
H.Num AS InvoiceNumber,
'Invoice Matched to PO' AS Activity,
L.ModifiedDateTime AS EventTime,
'D365 FO' AS SourceSystem,
GETDATE() AS LastDataUpdate,
H.InvoiceAccount AS VendorAccount,
H.DataAreaId AS CompanyCode,
CAST(H.InvoiceAmount AS DECIMAL(18,2)) AS InvoiceAmount,
H.DueDate AS DueDate,
H.PurchId AS PurchaseOrderNumber,
L.ModifiedBy AS UserId,
H.VendorName AS VendorName,
H.DocumentDate AS InvoiceDate,
'Unknown' AS Department
FROM dbo.VendInvoiceInfoLine L
JOIN dbo.VendInvoiceInfoTable H ON L.TableRefId = H.TableRefId AND L.DataAreaId = H.DataAreaId
WHERE L.MatchStatus = 1 /* 1 usually denotes Matched/Passed in enum */
AND L.ModifiedDateTime BETWEEN @StartDate AND @EndDate
UNION ALL
/* 4. Invoice Match Failed: Line Matching Discrepancy */
SELECT
H.Num AS InvoiceNumber,
'Invoice Match Failed' AS Activity,
L.ModifiedDateTime AS EventTime,
'D365 FO' AS SourceSystem,
GETDATE() AS LastDataUpdate,
H.InvoiceAccount AS VendorAccount,
H.DataAreaId AS CompanyCode,
CAST(H.InvoiceAmount AS DECIMAL(18,2)) AS InvoiceAmount,
H.DueDate AS DueDate,
H.PurchId AS PurchaseOrderNumber,
L.ModifiedBy AS UserId,
H.VendorName AS VendorName,
H.DocumentDate AS InvoiceDate,
'Unknown' AS Department
FROM dbo.VendInvoiceInfoLine L
JOIN dbo.VendInvoiceInfoTable H ON L.TableRefId = H.TableRefId AND L.DataAreaId = H.DataAreaId
WHERE L.MatchStatus = 2 /* 2 usually denotes Failed in enum */
AND L.ModifiedDateTime BETWEEN @StartDate AND @EndDate
UNION ALL
/* 5. Invoice Submitted for Approval: Workflow Submission */
SELECT
T1.Num AS InvoiceNumber,
'Invoice Submitted for Approval' AS Activity,
W.CreatedDateTime AS EventTime,
'D365 FO' AS SourceSystem,
GETDATE() AS LastDataUpdate,
T1.InvoiceAccount AS VendorAccount,
T1.DataAreaId AS CompanyCode,
CAST(T1.InvoiceAmount AS DECIMAL(18,2)) AS InvoiceAmount,
T1.DueDate AS DueDate,
T1.PurchId AS PurchaseOrderNumber,
W.User AS UserId,
T1.VendorName AS VendorName,
T1.DocumentDate AS InvoiceDate,
'Unknown' AS Department
FROM dbo.WorkflowTrackingStatusTable W
JOIN dbo.VendInvoiceInfoTable T1 ON W.ContextRecId = T1.RecId
WHERE W.TrackingStatus = 1 /* Submitted */
AND W.ContextTableId = 1425 /* TableId for VendInvoiceInfoTable, adjust if different in version */
AND W.CreatedDateTime BETWEEN @StartDate AND @EndDate
UNION ALL
/* 6. Invoice Approved: Workflow Completion */
SELECT
T1.Num AS InvoiceNumber,
'Invoice Approved' AS Activity,
W.CreatedDateTime AS EventTime,
'D365 FO' AS SourceSystem,
GETDATE() AS LastDataUpdate,
T1.InvoiceAccount AS VendorAccount,
T1.DataAreaId AS CompanyCode,
CAST(T1.InvoiceAmount AS DECIMAL(18,2)) AS InvoiceAmount,
T1.DueDate AS DueDate,
T1.PurchId AS PurchaseOrderNumber,
W.User AS UserId,
T1.VendorName AS VendorName,
T1.DocumentDate AS InvoiceDate,
'Unknown' AS Department
FROM dbo.WorkflowTrackingStatusTable W
JOIN dbo.VendInvoiceInfoTable T1 ON W.ContextRecId = T1.RecId
WHERE W.TrackingStatus = 2 /* Completed/Approved */
AND W.ContextTableId = 1425
AND W.CreatedDateTime BETWEEN @StartDate AND @EndDate
UNION ALL
/* 7. Invoice Posted: Creation of VendInvoiceJour */
SELECT
J.InvoiceId AS InvoiceNumber,
'Invoice Posted' AS Activity,
J.CreatedDateTime AS EventTime,
'D365 FO' AS SourceSystem,
GETDATE() AS LastDataUpdate,
J.InvoiceAccount AS VendorAccount,
J.DataAreaId AS CompanyCode,
CAST(J.InvoiceAmount AS DECIMAL(18,2)) AS InvoiceAmount,
J.DueDate AS DueDate,
J.PurchId AS PurchaseOrderNumber,
J.CreatedBy AS UserId,
J.InvoicingName AS VendorName,
J.InvoiceDate AS InvoiceDate,
'Unknown' AS Department
FROM dbo.VendInvoiceJour J
WHERE J.CreatedDateTime BETWEEN @StartDate AND @EndDate
UNION ALL
/* 8. Payment Block Applied: Updated on VendTrans */
SELECT
J.InvoiceId AS InvoiceNumber,
'Payment Block Applied' AS Activity,
VT.ModifiedDateTime AS EventTime,
'D365 FO' AS SourceSystem,
GETDATE() AS LastDataUpdate,
J.InvoiceAccount AS VendorAccount,
J.DataAreaId AS CompanyCode,
CAST(J.InvoiceAmount AS DECIMAL(18,2)) AS InvoiceAmount,
J.DueDate AS DueDate,
J.PurchId AS PurchaseOrderNumber,
VT.ModifiedBy AS UserId,
J.InvoicingName AS VendorName,
J.InvoiceDate AS InvoiceDate,
'Unknown' AS Department
FROM dbo.VendTrans VT
JOIN dbo.VendInvoiceJour J ON VT.Invoice = J.InvoiceId AND VT.AccountNum = J.InvoiceAccount AND VT.DataAreaId = J.DataAreaId
WHERE VT.Approved = 0 /* 0 indicates Not Approved/Blocked */
AND VT.ModifiedDateTime BETWEEN @StartDate AND @EndDate
UNION ALL
/* 9. Payment Journal Created: Line added to Journal */
SELECT
LJT.Invoice AS InvoiceNumber,
'Payment Journal Created' AS Activity,
LJT.CreatedDateTime AS EventTime,
'D365 FO' AS SourceSystem,
GETDATE() AS LastDataUpdate,
LJT.AccountNum AS VendorAccount,
LJT.DataAreaId AS CompanyCode,
CAST(LJT.AmountCurCredit AS DECIMAL(18,2)) AS InvoiceAmount,
NULL AS DueDate,
NULL AS PurchaseOrderNumber,
LJT.CreatedBy AS UserId,
NULL AS VendorName,
LJT.TransDate AS InvoiceDate,
'Unknown' AS Department
FROM dbo.LedgerJournalTrans LJT
WHERE LJT.AccountType = 2 /* Vendor */
AND LJT.Invoice IS NOT NULL AND LJT.Invoice <> ''
AND LJT.CreatedDateTime BETWEEN @StartDate AND @EndDate
UNION ALL
/* 10. Payment Journal Approved: Workflow on Journal Header */
SELECT
LJT.Invoice AS InvoiceNumber,
'Payment Journal Approved' AS Activity,
LJH.ModifiedDateTime AS EventTime,
'D365 FO' AS SourceSystem,
GETDATE() AS LastDataUpdate,
LJT.AccountNum AS VendorAccount,
LJT.DataAreaId AS CompanyCode,
CAST(LJT.AmountCurCredit AS DECIMAL(18,2)) AS InvoiceAmount,
NULL AS DueDate,
NULL AS PurchaseOrderNumber,
LJH.ModifiedBy AS UserId,
NULL AS VendorName,
LJT.TransDate AS InvoiceDate,
'Unknown' AS Department
FROM dbo.LedgerJournalTable LJH
JOIN dbo.LedgerJournalTrans LJT ON LJH.JournalNum = LJT.JournalNum AND LJH.DataAreaId = LJT.DataAreaId
WHERE LJH.WorkflowApprovalStatus = 2 /* Approved */
AND LJT.AccountType = 2
AND LJT.Invoice IS NOT NULL AND LJT.Invoice <> ''
AND LJH.ModifiedDateTime BETWEEN @StartDate AND @EndDate
UNION ALL
/* 11. Payment Generated: Payment Status Changed to Sent */
SELECT
LJT.Invoice AS InvoiceNumber,
'Payment Generated' AS Activity,
LJT.ModifiedDateTime AS EventTime,
'D365 FO' AS SourceSystem,
GETDATE() AS LastDataUpdate,
LJT.AccountNum AS VendorAccount,
LJT.DataAreaId AS CompanyCode,
CAST(LJT.AmountCurCredit AS DECIMAL(18,2)) AS InvoiceAmount,
NULL AS DueDate,
NULL AS PurchaseOrderNumber,
LJT.ModifiedBy AS UserId,
NULL AS VendorName,
LJT.TransDate AS InvoiceDate,
'Unknown' AS Department
FROM dbo.LedgerJournalTrans LJT
WHERE LJT.PaymentStatus = 2 /* Sent/Generated */
AND LJT.AccountType = 2
AND LJT.Invoice IS NOT NULL AND LJT.Invoice <> ''
AND LJT.ModifiedDateTime BETWEEN @StartDate AND @EndDate
UNION ALL
/* 12. Payment Posted: Journal Line Posted */
SELECT
LJT.Invoice AS InvoiceNumber,
'Payment Posted' AS Activity,
LJT.ModifiedDateTime AS EventTime,
'D365 FO' AS SourceSystem,
GETDATE() AS LastDataUpdate,
LJT.AccountNum AS VendorAccount,
LJT.DataAreaId AS CompanyCode,
CAST(LJT.AmountCurCredit AS DECIMAL(18,2)) AS InvoiceAmount,
NULL AS DueDate,
NULL AS PurchaseOrderNumber,
LJT.ModifiedBy AS UserId,
NULL AS VendorName,
LJT.TransDate AS InvoiceDate,
'Unknown' AS Department
FROM dbo.LedgerJournalTrans LJT
WHERE LJT.Posted = 1 /* Posted */
AND LJT.AccountType = 2
AND LJT.Invoice IS NOT NULL AND LJT.Invoice <> ''
AND LJT.ModifiedDateTime BETWEEN @StartDate AND @EndDate
)
SELECT *
FROM RawData
WHERE InvoiceNumber IS NOT NULL AND InvoiceNumber <> ''
ORDER BY InvoiceNumber, EventTime; Möchten Sie loslegen?
Verwenden Sie dieses Template als Grundlage für Ihre Daten und beginnen Sie noch heute damit, Ihre Zahlungsworkflows zu optimieren. Wenn Sie Hilfe bei der Zuordnung Ihrer Dynamics-365-Tabellen benötigen, unterstützt Sie unser Team gern.
Optimieren Sie jetzt Ihre Kreditorenzahlungsabwicklung
Verkürzen Sie die Zykluszeiten um 30 Prozent und vermeiden Sie Verzögerungen in D365.
Keine Kreditkarte erforderlich. In fünf Minuten eingerichtet.