> Kontinuierliche Prozessverbesserung > Kredit und Forderungsmanagement > NetSuite > Daten Template

Ihr Daten-Template für Kreditmanagement und Forderungseinzug

NetSuite

← Zurück zum Leitfaden zur Prozessverbesserung

Attribute für Kreditmanagement und Forderungseinzug (21) Aktivitäten im Kreditmanagement und Forderungseinzug (13) Anleitungen zur Datenextraktion (2)

Ihr Daten-Template für Kreditmanagement und Forderungseinzug

Dieses Template zeigt, welche Daten Sie für die Analyse Ihres Kreditmanagement- und Forderungseinzugsprozesses erfassen sollten. Es beschreibt die erforderlichen Attribute und Aktivitäten und gibt praktische Hinweise zur Datenextraktion, damit Sie schnell beginnen können. Mit diesen Empfehlungen bereiten Sie Ihre Daten für eine aussagekräftige Prozessanalyse und Verbesserungen vor.

Empfohlene Attribute für die Datenerfassung
Wichtige Aktivitäten für die Nachverfolgung
Hinweise zur Datenextraktion aus NetSuite

Neu bei Event Logs? Erfahren Sie, wie Sie ein Event Log für Process Mining erstellen.

Template herunterladen

Attribute für Kreditmanagement und Forderungseinzug

Diese Datenfelder sollten Sie in Ihr Event Log aufnehmen, um Ihren Kreditmanagement- und Forderungseinzugsprozess umfassend zu analysieren.

3 Erforderlich 5 Empfohlen 13 Optional

	Name	Beschreibung
	Aktivitätsname ActivityName	Bezeichnung der geschäftlichen Aktivität, die zu einem bestimmten Zeitpunkt stattgefunden hat.
Beschreibung Dieses Attribut beschreibt einen bestimmten Schritt oder ein Ereignis im Kredit- und Inkassoprozess, etwa „Rechnung erstellt“, „Zahlung eingegangen“ oder „Streitfall erfasst“. Die Analyse der Abfolge und Häufigkeit dieser Aktivitäten bildet den Kern von Process Mining. Sie macht den tatsächlichen Prozessablauf, Abweichungen und Engpässe sichtbar. Warum das wichtig ist Dieses Attribut bildet die Grundlage der Prozesslandkarte und ermöglicht die Visualisierung und Analyse des Prozessablaufs. Woher beziehen Dieses Feld wird in der Regel aus Statusänderungen von Transaktionsdatensätzen (z. B. „Invoice“, „Customer Payment“) oder aus verknüpften Datensätzen abgeleitet, etwa Systemnotizen, benutzerdefinierten Datensätzen zu Inkassoaktivitäten oder CRM-Aufgaben. Beispiele Rechnung erstelltZahlungserinnerung wegen Überfälligkeit gesendetZahlung eingegangenRechnung abgeschrieben
	Ereigniszeit EventTime	Timestamp, der angibt, wann die Aktivität stattgefunden hat.
Beschreibung Dieses Attribut erfasst Datum und Uhrzeit jeder Aktivität im Prozess genau. Es ist die Grundlage für alle zeitbezogenen Analysen, darunter die Berechnung von Zykluszeiten, Dauern und Wartezeiten zwischen Schritten. In NetSuite entspricht dieser Timestamp in der Regel dem Erstellungs- oder Änderungsdatum des betreffenden Datensatzes oder der Systemnotiz. Warum das wichtig ist Damit lassen sich alle zeitbezogenen Leistungskennzahlen berechnen, etwa Zykluszeiten und Engpässe, die für die Effizienzanalyse entscheidend sind. Woher beziehen Die Daten stammen aus Datumsfeldern verschiedener Datensätze. Für „Rechnung erstellt“ wird beispielsweise das Feld „Date Created“ des Rechnungsdatensatzes verwendet, für Statusänderungen der Timestamp einer Systemnotiz. Beispiele 2023-01-15T10:00:00Z2023-02-01T14:30:00Z2023-02-15T09:05:00Z
	Rechnungsnummer InvoiceNumber	Eindeutige Kennung jeder Kundenrechnung.
Beschreibung Die Rechnungsnummer dient als primäre Case-ID und verknüpft alle Aktivitäten, die zu einer bestimmten Forderung gehören. So lässt sich der gesamte Lebenszyklus analysieren, von der Rechnungserstellung über weitere Maßnahmen im Kreditmanagement bis hin zur Zahlung oder Klärung durch Inkasso. In NetSuite entspricht sie in der Regel der Transaction ID, wenn der Transaktionstyp „Invoice“ lautet. Warum das wichtig ist Sie ist der zentrale Schlüssel, um den Weg einer Rechnung von der Erstellung bis zum Ausgleich nachzuverfolgen und den Prozess durchgängig zu analysieren. Woher beziehen Dies ist in der Regel das Feld „Transaction ID“ (interne ID: tranid) des Rechnungsdatensatzes in NetSuite. Beispiele INV0012345INV0054321INV0098765
	Fälligkeitsdatum DueDate	Datum, bis zu dem die Rechnung bezahlt werden muss.
Beschreibung Das Fälligkeitsdatum ist der vertraglich vereinbarte Zahlungstermin. Anhand dieses Datums wird bestimmt, ob eine Zahlung pünktlich oder überfällig ist. Das Attribut ist wichtig für die Berechnung von Kennzahlen wie der Pünktlichkeitsquote bei Zahlungen und für das Auslösen von Mahnaktivitäten nach Ablauf des Zahlungstermins. Warum das wichtig ist Dient als zentraler Maßstab für die Pünktlichkeit von Zahlungen. Außerdem ist es entscheidend, um die Zahl der Verzugstage zu berechnen und die Einhaltung der Zahlungsbedingungen zu überwachen. Woher beziehen Dies ist das Feld „Due Date“ (interne ID: duedate) des Rechnungstransaktionsdatensatzes. Beispiele 2023-02-142023-03-312023-04-15
	Kunden-ID CustomerId	Eindeutige Kennung des Kunden, der mit der Rechnung verknüpft ist.
Beschreibung Dieses Attribut verknüpft eine Rechnung mit einem bestimmten Kunden in NetSuite. Es ist wichtig, um die Daten nach Kunden oder Kundengruppen aufzuschlüsseln und die Prozessleistung zu analysieren. So können Sie beispielsweise das Zahlungsverhalten oder die Beanstandungsquote strategischer Kunden mit denen kleiner Unternehmen vergleichen. Warum das wichtig ist Ermöglicht eine kundenbezogene Analyse, mit der Sie erkennen, welche Kunden häufig verspätet zahlen, Streitfälle melden oder von den Standardabläufen abweichen. Woher beziehen Dies ist das Feld „Customer“ (interne ID: entity) des Rechnungstransaktionsdatensatzes. Beispiele CUST001CUST002CUST003
	Kundensegment CustomerSegment	Klassifizierung des Kunden, beispielsweise nach Größe, Branche oder Region.
Beschreibung Das Kundensegment ordnet Kunden aussagekräftigen Gruppen zu, etwa „Enterprise“, „Mittelstand“ oder „Öffentlicher Sektor“. Dieses Attribut ist wichtig für das Dashboard „Leistung der Inkassostrategie nach Segment“, da sich damit die Wirksamkeit verschiedener Inkassomaßnahmen in den einzelnen Segmenten vergleichen lässt. So können Sie Strategien an das Verhalten der jeweiligen Gruppe anpassen. Warum das wichtig ist Ermöglicht gezielte Analysen, um festzustellen, ob bestimmte Prozessprobleme oder Zahlungsverhalten in einzelnen Kundengruppen gehäuft auftreten. Woher beziehen Häufig handelt es sich um ein benutzerdefiniertes Feld im Kundendatensatz von NetSuite. Die Daten müssen aus dem Kundendatensatz mit der Rechnungstransaktion verknüpft werden. Beispiele EnterpriseMittelstandSMB
	Rechnungsbetrag InvoiceAmount	Gesamtbetrag der Rechnung.
Beschreibung Gibt den gesamten fälligen Rechnungsbetrag an. Dieses wichtige Finanzattribut fließt in zahlreiche Analysen ein, etwa zur Ermittlung der finanziellen Auswirkungen verspäteter Zahlungen oder zur Analyse von Abschreibungen bei Rechnungen mit hohem Wert. Es liefert eine wichtige Grundlage, um Inkassomaßnahmen zu priorisieren. Warum das wichtig ist Liefert den finanziellen Kontext für den Prozess und ermöglicht Analysen nach Geldwert, etwa um Inkassomaßnahmen für überfällige Rechnungen mit hohem Betrag zu priorisieren. Woher beziehen Dies ist das Feld „Amount (Total)“ (interne ID: total) des Rechnungstransaktionsdatensatzes. Beispiele 1500.00250.5012500.75
	Rechnungsstatus InvoiceStatus	Aktueller Status der Rechnung in ihrem Lebenszyklus.
Beschreibung Gibt den aktuellen Status der Rechnung an, etwa „Offen“, „Vollständig bezahlt“ oder „Überfällig“. Damit können Sie gezielt aktive oder problematische Rechnungen filtern und analysieren. Das Dashboard „Überfällige Rechnungen: Alter und Status“ verwendet dieses Attribut, um einen Überblick über offene Forderungen zu geben. Warum das wichtig ist Ermöglicht es, die Analyse auf bestimmte Phasen des Rechnungslebenszyklus zu beschränken, etwa auf offene, überfällige oder beanstandete Rechnungen. Woher beziehen Dies entspricht dem Feld „Status“ (interne ID: status) des Rechnungstransaktionsdatensatzes. Beispiele OffenVollständig bezahltÜberfällig
	Automatisiert IsAutomated	Kennzeichnet, ob ein System eine Aktivität automatisch ausgeführt hat.
Beschreibung Dieses boolesche Attribut gibt an, ob ein automatisierter Workflow oder ein Benutzer eine Aktivität ausgeführt hat. Beispielsweise kann das Versenden einer Mahnung bei Zahlungsverzug automatisiert sein, während ein Anruf zum Forderungseinzug manuell erfolgt. Das Attribut ist wichtig für das Dashboard „Häufigkeit und Auswirkungen manueller Aktivitäten“. Damit lassen sich der Automatisierungsgrad ermitteln und weitere Automatisierungsmöglichkeiten erkennen. Warum das wichtig ist Damit lässt sich der Automatisierungsgrad des Prozesses ermitteln. Das unterstützt Maßnahmen, die den manuellen Aufwand verringern und die Effizienz steigern. Woher beziehen Dieses abgeleitete Attribut basiert auf dem Aktivitätstyp oder dem ausführenden Benutzer. Ist der Benutzer beispielsweise ein als „SYSTEM“ gekennzeichneter Benutzer, wird die Aktivität als automatisiert markiert. Beispiele truefalse
	Benutzer-ID UserId	Kennung des Benutzers, der die Aktivität ausgeführt hat.
Beschreibung Gibt an, welcher Mitarbeiter oder Systembenutzer für eine bestimmte Aktivität verantwortlich war, etwa für die Buchung einer Zahlung oder einen Inkassoanruf. So lassen sich die Arbeitsverteilung und die Teamleistung analysieren sowie Schulungsbedarf erkennen. Bei automatisierten Aktivitäten kann hier die ID eines Systembenutzers stehen. Warum das wichtig ist Ermöglicht die Analyse der Leistung einzelner Benutzer oder Teams. Außerdem hilft das Attribut, die Arbeitsverteilung zu verstehen und manuelle Eingriffe zu erkennen. Woher beziehen Stammt aus Feldern wie „Created By“, „Modified By“ oder einem bestimmten Feld „Owner“ in Transaktionen oder verknüpften Datensätzen, etwa dem Telefonanruf-Datensatz für Inkassoanrufe. Beispiele j.doea.smithSYSTEM
	Durchlaufzeit von der Rechnung bis zum Zahlungseingang InvoiceToCashCycleTime	Gesamtdauer von der Rechnungserstellung bis zum endgültigen Zahlungsausgleich.
Beschreibung Diese berechnete Kennzahl misst die Gesamtdauer zwischen den Aktivitäten „Rechnung erstellt“ und „Rechnung ausgeglichen“. Sie bildet die End-to-End-Leistung des gesamten Kreditmanagement- und Forderungseinzugsprozesses ab. Die Analyse dieser KPI hilft, systembedingte Verzögerungen zu erkennen und die Geschwindigkeit des Zahlungseingangs insgesamt einzuschätzen. Warum das wichtig ist Diese zentrale KPI auf übergeordneter Ebene misst die Effizienz des gesamten Prozesses von der Rechnung bis zum Zahlungseingang. Woher beziehen Diese Berechnung auf Case-Ebene erfolgt im Process-Mining-Tool: Timestamp('Rechnung ausgeglichen') - Timestamp('Rechnung erstellt'). Beispiele 32 Tage45 Tage91 Tage
	Geschäftseinheit BusinessUnit	Die Geschäftseinheit oder Tochtergesellschaft, die der Transaktion zugeordnet ist.
Beschreibung Bezeichnet die Geschäftseinheit, Abteilung oder Tochtergesellschaft, die die Rechnung ausgestellt hat. In NetSuite-OneWorld-Konten entspricht dies in der Regel dem Feld „Subsidiary“. So lässt sich der Prozess nach Organisationseinheiten aufschlüsseln. Dadurch können Sie die Leistung vergleichen und Probleme erkennen, die einzelne Bereiche betreffen. Warum das wichtig ist Die Prozessleistung lässt sich zwischen verschiedenen Organisationseinheiten vergleichen. So werden Unterschiede sichtbar, die möglicherweise unterschiedliche Managementansätze erfordern. Woher beziehen In NetSuite OneWorld ist dies das Feld „Subsidiary“. In anderen Konten kann es je nach Konfiguration „Department“ oder „Class“ sein. Beispiele US-WestenEMEA-ServicesAPAC-Produkte
	Grund der Beanstandung DisputeReason	Vom Kunden angegebener Grund für die Beanstandung einer Rechnung.
Beschreibung Wenn ein Kunde eine Rechnung beanstandet, erfasst dieses Attribut den Grund, etwa „Falsche Preisangabe“, „Beschädigte Ware“ oder „Doppelte Abrechnung“. Es ist wichtig für die Dashboards „Dauer bis zur Klärung von Rechnungsstreitigkeiten“ und „Ursachenanalyse für Rechnungsabschreibungen“. Damit lässt sich nachvollziehen, warum Streitfälle entstehen und welche Muster sich beheben lassen, um künftige Probleme zu vermeiden. Warum das wichtig ist Hilft, die Ursachen von Kundenbeanstandungen zu ermitteln. Die gewonnenen Erkenntnisse können dazu beitragen, vorgelagerte Prozesse wie die Auftragsabwicklung oder die Genauigkeit der Rechnungsstellung zu verbessern. Woher beziehen Wahrscheinlich handelt es sich um ein benutzerdefiniertes Feld im Rechnungsdatensatz oder in einem verknüpften benutzerdefinierten Datensatz zur Erfassung von Streitfällen. Es ist kein Standardfeld in NetSuite. Beispiele Falsche MengePreisabweichungBeschädigte Ware
	Land Country	Das Land der Rechnungsadresse des Kunden.
Beschreibung Dieses Attribut gibt das Land an, das der Rechnungsadresse des Kunden zugeordnet ist. Es dient dazu, geografische Unterschiede beim Zahlungsverhalten, bei der Wirksamkeit des Forderungseinzugs und bei Streitfällen zu analysieren. So können Sie Ihre Einzugsstrategien auf bestimmte Regionen abstimmen und die Auswirkungen lokaler wirtschaftlicher Bedingungen besser verstehen. Warum das wichtig ist Die geografische Aufschlüsselung des Prozesses macht regionale Unterschiede beim Zahlungsverhalten oder bei der Prozesseffizienz sichtbar. Woher beziehen Die Angabe stammt aus den Details der „Billing Address“ der Rechnungstransaktion und wird in der Regel aus dem Kundendatensatz übernommen. Beispiele USADeutschlandJapan
	Letzte Datenaktualisierung LastDataUpdate	Timestamp der letzten Datenaktualisierung aus dem Quellsystem.
Beschreibung Dieses Attribut gibt an, wann die Daten für diesen Prozess zuletzt extrahiert und im Process-Mining-Tool aktualisiert wurden. So können Benutzer die Aktualität der analysierten Daten einschätzen und Entscheidungen auf Grundlage aktueller Informationen treffen. Warum das wichtig ist Macht transparent, wie aktuell die Daten sind, und zeigt Benutzern, auf welchem Stand die Prozessanalyse ist. Woher beziehen Dieser Wert wird bei der Datenextraktion erzeugt und dem Datensatz hinzugefügt. Beispiele 2023-10-27T02:00:00Z
	Name des Inkassomitarbeiters CollectorName	Name des Inkassomitarbeiters, der für die Rechnung zuständig ist.
Beschreibung Gibt an, welcher Inkassomitarbeiter oder welche Ressource für die Bearbeitung einer überfälligen Rechnung zuständig ist. So können Sie die Leistung des Inkassoteams analysieren, die Arbeitsverteilung nachvollziehen und die Wirksamkeit einzelner Inkassomitarbeiter beurteilen. Das Attribut unterstützt Kennzahlen wie die Erfolgsquote bei Kundenkontakten im Inkasso. Warum das wichtig ist Ermöglicht die Leistungsmessung und den Ausgleich der Arbeitslast im Inkassoteam, indem Inkassoaktivitäten einzelnen Personen zugeordnet werden. Woher beziehen Häufig handelt es sich um ein benutzerdefiniertes Feld im Kunden- oder Rechnungsdatensatz. Einige NetSuite-Pakete für das Inkasso bieten diese Funktion. Beispiele Alice JohnsonRobert WilliamsNicht zugewiesen
	Quellsystem SourceSystem	System, aus dem die Daten extrahiert wurden.
Beschreibung Gibt das Ursprungssystem der Ereignisdaten an. In dieser Prozessansicht lautet der Wert immer „NetSuite“. Als Pflichtattribut ist er für die Data Governance erforderlich und hilft, Datenquellen in Umgebungen mit mehreren Systemen zu unterscheiden. Warum das wichtig ist Sichert Datenherkunft und Rückverfolgbarkeit. Das ist wichtig für die Datenvalidierung und Data Governance, insbesondere in Umgebungen mit mehreren integrierten Systemen. Woher beziehen Dies ist ein statischer Wert („NetSuite“), der während der Datentransformation hinzugefügt wird. Beispiele NetSuite
	Tage überfällig DaysOverdue	Anzahl der Tage, um die eine Rechnung nach ihrem Fälligkeitsdatum überfällig ist.
Beschreibung Diese berechnete Kennzahl ermittelt die Anzahl der Tage zwischen dem Fälligkeitsdatum der Rechnung und dem aktuellen Datum bei offenen Rechnungen oder dem Zahlungsdatum. Sie ist eine zentrale Kennzahl für den Forderungseinzug. Im Dashboard „Überfällige Rechnungen: Alter und Status“ dient sie dazu, Einzugsmaßnahmen zu kategorisieren und zu priorisieren. Ein Wert von null oder weniger bedeutet, dass die Rechnung nicht überfällig ist. Warum das wichtig ist Die Kennzahl misst unmittelbar, wie stark Zahlungen verspätet sind. Sie ist wichtig für Berichte zur Überfälligkeit und zur Priorisierung von Einzugsmaßnahmen. Woher beziehen Die Berechnung erfolgt bei der Datentransformation: (aktuelles Datum oder Zahlungsdatum) - Fälligkeitsdatum. Beispiele 1532090
	Verzögerung bei der Zahlungsbuchung PaymentPostingLag	Zeit zwischen dem Eingang einer Zahlung und ihrer Buchung im System.
Beschreibung Diese berechnete Dauer misst die Verzögerung zwischen der Aktivität „Zahlung eingegangen“ (Eingang der Mittel) und „Zahlung gebucht“ (Zuordnung der Zahlung zur Rechnung in NetSuite). Die Kennzahl ist zentral für das Dashboard „Analyse der Verzögerung bei der Zahlungsbuchung“. Sie macht interne Ineffizienzen bei der Zahlungszuordnung sichtbar, die die Übersicht über den Zahlungseingang beeinträchtigen können. Warum das wichtig ist Die Kennzahl zeigt interne Verzögerungen bei der Zahlungszuordnung. Diese können die Genauigkeit der Finanzberichterstattung und den Status von Kundenkonten beeinträchtigen. Woher beziehen Die Berechnung erfolgt im Process-Mining-Tool: Timestamp('Zahlung gebucht') - Timestamp('Zahlung eingegangen'). Beispiele 1 Tag4 Stunden3 Tage
	Zahlung fristgerecht IsOnTimePayment	Kennzeichnet, ob die Zahlung spätestens am Fälligkeitsdatum eingegangen ist.
Beschreibung Dieses berechnete boolesche Attribut prüft, ob die Aktivität „Zahlung eingegangen“ am oder vor dem Fälligkeitsdatum der Rechnung stattgefunden hat. Es vereinfacht die Berechnung der KPI „Anteil fristgerechter Zahlungen“ und ermöglicht eine einfache Filterung und Analyse fristgerechter und verspäteter Zahlungen. Das Ergebnis ist eindeutig: Die Zahlung erfolgte fristgerecht oder nicht. Warum das wichtig ist Die Kennzahl zeigt auf einfache, eindeutige Weise, ob Zahlungsbedingungen eingehalten wurden. So lässt sich der Anteil fristgerechter Zahlungen leicht berechnen und vergleichen. Woher beziehen Die Berechnung erfolgt bei der Datentransformation: TRUE, wenn (Zahlungsdatum <= Fälligkeitsdatum), andernfalls FALSE. Beispiele truefalse
	Zahlungsbedingungen PaymentTerms	Mit dem Kunden für die Rechnung vereinbarte Zahlungsbedingungen.
Beschreibung Dieses Attribut gibt an, unter welchen Bedingungen der Kunde die Rechnung bezahlen soll, etwa „Netto 30“ oder „Netto 60“. Es bildet die Grundlage für die Berechnung des Fälligkeitsdatums und ist wichtig für das Dashboard „Einhaltung und Abweichungen bei Zahlungsbedingungen“. Dieses analysiert, ob Kunden die vereinbarten Bedingungen einhalten. Warum das wichtig ist Liefert die vertragliche Grundlage für Zahlungspläne und ist entscheidend, um die Einhaltung zu analysieren und Abweichungen zu erkennen, die den Cashflow beeinträchtigen. Woher beziehen Dies ist das Feld „Terms“ (interne ID: terms) des Rechnungstransaktionsdatensatzes. Beispiele Netto 30Netto 60Fällig bei Erhalt

Erforderlich Empfohlen Optional

Aktivitäten im Kreditmanagement und Forderungseinzug

Erfassen Sie diese wichtigen Prozessschritte und Meilensteine in Ihrem Event Log, um Ihren Forderungseinzugs-Workflow zuverlässig zu entdecken und zu optimieren.

5 Empfohlen 8 Optional

	Aktivität	Beschreibung
	Rechnung abgeschrieben	Ein erfolgloser Abschluss des Rechnungslebenszyklus: Die Forderung gilt als uneinbringlich und wird aus den Forderungen aus Lieferungen und Leistungen ausgebucht. Das Ereignis wird erfasst, wenn eine Buchung für uneinbringliche Forderungen auf die Rechnung angewendet wird.
Warum das wichtig ist Dies ist ein wichtiger Endpunkt für einen Prozessfehler. Die Analyse der Abläufe, die zu Abschreibungen führen, hilft, Schwächen in der Kreditrichtlinie und der Inkassostrategie zu erkennen und uneinbringliche Forderungen zu verringern. Woher beziehen Abgeleitet aus der Anwendung einer „Journal Entry“-Buchung auf die Rechnung, die ausdrücklich der Abschreibung einer uneinbringlichen Forderung dient. Alternativ kann ein benutzerdefinierter Status verwendet werden. Erfassung Verwenden Sie das Datum der auf die Rechnung angewendeten Abschreibungsbuchung („Journal Entry“). Ereignistyp inferred
	Rechnung ausgeglichen	Der Rechnungslebenszyklus ist erfolgreich abgeschlossen, wenn der offene Betrag durch Zahlungen und angerechnete Gutschriften auf null sinkt. Das Ereignis wird abgeleitet, wenn sich der Rechnungsstatus in „Vollständig bezahlt“ ändert.
Warum das wichtig ist Dies ist das primäre erfolgreiche End-Event des Prozesses. Es liefert den letzten Datenpunkt für die Berechnung der durchgängigen Invoice-to-Cash-Zykluszeit. Woher beziehen Abgeleitet aus einer Änderung des Felds „Status“ der Rechnungstransaktion in „Paid In Full“. Als Timestamp kann das Datum der letzten Zahlung oder Gutschrift dienen, durch die die Rechnung ausgeglichen wurde. Erfassung Timestamp der letzten Zahlungszuordnung, durch die der Status auf „Paid In Full“ gesetzt wird. Ereignistyp inferred
	Rechnung erstellt	Kennzeichnet die offizielle Erstellung des Rechnungssatzes im System. Dieses Ereignis wird anhand des Erstellungsdatums der Rechnungstransaktion in NetSuite erfasst und markiert den Beginn des Rechnungslebenszyklus.
Warum das wichtig ist Dies ist das primäre Start-Event des Invoice-to-Cash-Prozesses. Es ist entscheidend für die Berechnung wichtiger Kennzahlen wie Days Sales Outstanding (DSO) und der gesamten Invoice-to-Cash-Zykluszeit. Woher beziehen Dieses explizite Ereignis wird anhand des Erstellungsdatums des Rechnungstransaktionsdatensatzes in NetSuite erfasst (Tabelle „Transaction“, wobei „Type“ den Wert „Invoice“ hat). Erfassung Verwenden Sie den Erstellungs-Timestamp des Rechnungstransaktionsdatensatzes. Ereignistyp explicit
	Zahlung eingegangen	Dieses Ereignis kennzeichnet den Zeitpunkt, zu dem eine Kundenzahlung erstellt und einer Rechnung zugeordnet wird. Es ist ein wichtiger Meilenstein und wird direkt anhand des Transaktionsdatensatzes „Customer Payment“ in NetSuite erfasst.
Warum das wichtig ist Diese Aktivität ist entscheidend für die Berechnung von DSO und der Pünktlichkeitsquote bei Zahlungen. Sie kennzeichnet den Zahlungseingang und ist eine wichtige Kennzahl für den Erfolg des Inkassos. Woher beziehen Erfasst anhand des Erstellungsdatums des Transaktionsdatensatzes „Customer Payment“. Die Unterliste „Apply“ dieses Datensatzes verknüpft die Zahlung mit einer oder mehreren Rechnungen. Erfassung Verwenden Sie das Transaktionsdatum des Datensatzes „Customer Payment“. Ereignistyp explicit
	Zahlungsziel überschritten	Ein berechnetes Ereignis, das eintritt, wenn das aktuelle Datum das Fälligkeitsdatum der Rechnung überschreitet und die Rechnung noch nicht vollständig bezahlt ist. Es kennzeichnet den Wechsel der Rechnung vom Status „Aktuell“ zu „Überfällig“.
Warum das wichtig ist Dieses Ereignis ist ein wichtiger Auslöser für alle Inkassoaktivitäten. Die Zeitspanne danach ist entscheidend für die Analyse der Inkassoeffizienz und der Wirksamkeit des Mahnwesens. Woher beziehen Dieses Ereignis wird berechnet, indem das aktuelle Datum mit dem Feld „Due Date“ des Rechnungstransaktionsdatensatzes verglichen wird. Als Ereignis-Timestamp dient das Fälligkeitsdatum selbst. Erfassung Der Timestamp entspricht dem Wert des Felds „Due Date“ der Rechnung. Ereignistyp calculated
	Gutschrift ausgestellt	Kennzeichnet die Erstellung einer Gutschrift, die auf die Rechnung angerechnet wird, häufig zur Korrektur eines Fehlers oder im Rahmen der Klärung eines Streitfalls. In NetSuite handelt es sich um eine explizite Transaktion.
Warum das wichtig ist Häufige Gutschriften können auf systematische Probleme wie Preisfehler oder Schwierigkeiten beim Versand hinweisen. Ihre Analyse hilft, die Ursachen von Umsatzverlusten zu ermitteln. Woher beziehen Dieses explizite Ereignis wird anhand des Erstellungsdatums des Gutschrift-Transaktionsdatensatzes erfasst, der mit der ursprünglichen Rechnung verknüpft ist. Erfassung Verwenden Sie den Erstellungs-Timestamp der Gutschrifttransaktion. Ereignistyp explicit
	Inkassoanruf durchgeführt	Eine manuelle Inkassoaktivität, bei der ein Inkassomitarbeiter den Kunden telefonisch kontaktiert. Das Ereignis wird anhand von durch Benutzer erstellten Telefonanruf-Aktivitätsdatensätzen im CRM-Modul von NetSuite erfasst.
Warum das wichtig ist Mit dieser Aktivität lässt sich der manuelle Aufwand im Inkassoprozess beziffern. Ihre Häufigkeit und Erfolgsquote sind wichtige Faktoren, wenn Sie den Ressourceneinsatz und den Automatisierungsgrad optimieren möchten. Woher beziehen Erfasst anhand des Erstellungsdatums eines Telefonanruf-Aktivitätsdatensatzes, bei dem der Kunde als zugehöriger Datensatz angegeben und die Rechnungsnummer in der Nachricht erwähnt ist. Erfassung Verwenden Sie den Timestamp des Telefonanruf-Aktivitätsdatensatzes im CRM. Ereignistyp explicit
	Mahnverfahren eingeleitet	Kennzeichnet den Beginn eines formellen Mahn- oder Inkassoverfahrens für eine überfällige Rechnung, das mehrere Schritte umfassen kann. Das Ereignis wird erfasst, wenn der Rechnung eine bestimmte Mahnstufe zugewiesen wird.
Warum das wichtig ist Die Erfassung des Beginns eines formellen Mahnverfahrens hilft, die Einhaltung und Wirksamkeit des Mahnprozesses zu messen. Dieser Meilenstein ist wichtig, um zu analysieren, wie sich unterschiedliche Mahnstrategien auf das Zahlungsverhalten auswirken. Woher beziehen Abgeleitet aus dem Datum, an dem das Feld „Dunning Level“ im Rechnungs- oder Kundendatensatz erstmals auf einen Wert ungleich null oder eine anfängliche Mahnstufe gesetzt wird. Erfassung Ermitteln Sie den Timestamp, zu dem sich der Wert des Felds „Dunning Level“ ändert. Ereignistyp inferred
	Rechnung an Kunden gesendet	Gibt an, wann die Rechnung an den Kunden übermittelt wurde, in der Regel per E-Mail. Das Ereignis wird häufig aus Systemprotokollen abgeleitet, in denen die ausgehende Kommunikation zur Rechnungstransaktion erfasst wird.
Warum das wichtig ist Mit dieser Aktivität lassen sich Verzögerungen zwischen der Rechnungserstellung und der Benachrichtigung des Kunden erkennen, die sich auf die Zahlungsdauer auswirken können. Sie gibt Aufschluss darüber, wie effizient die Kommunikation zur Rechnungsstellung abläuft. Woher beziehen Abgeleitet aus dem Datum einer E-Mail, die über den Rechnungssatz versendet wurde. Sie finden sie im Unterregister „Communication > Messages“ der Rechnungstransaktion. Erfassung Verwenden Sie den Timestamp des mit der Rechnung verknüpften „Message“-Datensatzes. Ereignistyp inferred
	Streitfall erfasst	Gibt an, dass ein Kunde die Rechnung formell beanstandet hat. Dadurch wird der reguläre Inkassoprozess unterbrochen. Das Ereignis wird in der Regel aus einer Änderung des Rechnungsstatus in „Beanstandet“ abgeleitet.
Warum das wichtig ist Dieses Ereignis markiert den Beginn der Messung der Dauer bis zur Klärung eines Streitfalls. Häufige Beanstandungen können auf grundlegende Probleme in der Rechnungsstellung oder im Vertrieb hinweisen. Woher beziehen Abgeleitet aus einem Systemprotokoll oder einer mit Timestamp versehenen Änderung eines benutzerdefinierten Felds „Invoice Status“ auf einen Wert wie „Disputed“ oder „In Dispute“. Erfassung Timestamp der Statusänderung, mit der ein Streitfall erfasst wird. Ereignistyp inferred
	Streitfall geklärt	Kennzeichnet die Klärung eines Kundenstreitfalls. Danach kann der Inkassoprozess fortgesetzt oder die Rechnung beglichen werden. Das Ereignis wird abgeleitet, wenn sich der Rechnungsstatus von „Beanstandet“ zurück in einen aktiven Status ändert.
Warum das wichtig ist Dieses Ereignis markiert das Ende der gemessenen Klärungsdauer. Eine effiziente Klärung von Streitfällen ist entscheidend für die Kundenzufriedenheit und einen schnelleren Cashflow. Woher beziehen Abgeleitet aus einem Systemprotokoll oder einer mit Timestamp versehenen Änderung des benutzerdefinierten Felds „Invoice Status“ von „Disputed“ in einen Wert wie „Open“ oder „Resolved“. Erfassung Timestamp der Statusänderung, mit der die Klärung erfasst wird. Ereignistyp inferred
	Zahlung gebucht	Gibt das Datum an, an dem die finanziellen Auswirkungen der Zahlung offiziell im Hauptbuch erfasst werden. Dieses Ereignis wird anhand des Buchungsdatums der Transaktion „Customer Payment“ erfasst.
Warum das wichtig ist Die Zeit zwischen „Zahlung eingegangen“ und „Zahlung gebucht“ macht administrative Verzögerungen sichtbar. Die Analyse dieser Zeitspanne ist wichtig für eine korrekte und zeitnahe Finanzberichterstattung. Woher beziehen Erfasst anhand der „Posting Period“ oder des Transaktionsdatums in der Hauptbuchauswirkung der Transaktion „Customer Payment“. Erfassung Verwenden Sie das Hauptbuch-Buchungsdatum der Transaktion „Customer Payment“. Ereignistyp explicit
	Zahlungserinnerung wegen Überfälligkeit gesendet	Der Kunde erhält eine erste, häufig automatisierte Erinnerung zu einer überfälligen Rechnung. Diese Aktivität wird in der Regel anhand der Erstellung eines Mahnschreibens oder eines protokollierten Kommunikationsereignisses im Mahnmodul von NetSuite erfasst.
Warum das wichtig ist Diese Aktivität ist der erste Schritt im Mahnprozess. Anhand ihrer Häufigkeit und ihrer Wirkung auf das Zahlungsverhalten lässt sich beurteilen, wie wirksam die ersten Inkassomaßnahmen sind. Woher beziehen Erfasst anhand des Erstellungsdatums eines mit der Rechnung verknüpften „Dunning Letter“-Datensatzes, der von der NetSuite Dunning SuiteApp erstellt wurde. Erfassung Verwenden Sie den Erstellungs-Timestamp des „Dunning Letter“-Datensatzes. Ereignistyp explicit

Anleitungen zur Datenextraktion

So exportieren Sie Ihre Daten aus NetSuite

Schritte

Melden Sie sich bei NetSuite an: Greifen Sie mit einer Rolle auf Ihr NetSuite-Konto zu, die Suchvorgänge erstellen und ausführen sowie die erforderlichen Transaktions- und Aktivitätsdatensätze anzeigen darf, zum Beispiel Rechnung, Kundenzahlung und Telefonanruf.
Öffnen Sie die gespeicherten Suchen: Navigieren Sie zu Reports > Saved Searches > All Saved Searches > New. Wiederholen Sie diesen Vorgang für mehrere separate Suchen, jeweils eine pro Ereignistyp.
Erstellen Sie die Basissuche für Rechnungen: Erstellen Sie zunächst eine Suche für das Ereignis „Rechnung erstellt“. Wählen Sie als Suchtyp „Transaktion“. Mit dieser Suche erfassen Sie die Rechnungserstellung.
Legen Sie die Suchkriterien fest: Legen Sie im Unterregister „Criteria“ die folgenden Filter fest:
- Typ ist Rechnung.
- Main Line ist true. So erhalten Sie einen Datensatz pro Rechnung und nicht einen pro Rechnungsposition.
- Date Created liegt im gewünschten Analysezeitraum, zum Beispiel in den letzten 6 Monaten.
Legen Sie die Suchergebnisse fest: Fügen Sie im Unterregister „Results“ die Spalten hinzu, die für das Event Log benötigt werden. Verwenden Sie benutzerdefinierte Bezeichnungen, die den erforderlichen Attributnamen entsprechen, zum Beispiel InvoiceNumber. Legen Sie das Feld ActivityName mithilfe von Formeln fest. Die detaillierten Feldzuordnungen finden Sie im Abfrageabschnitt.
Erstellen Sie Suchen für weitere Ereignisse: Erstellen Sie anhand der Konfigurationen im Abfrageabschnitt separate gespeicherte Suchen für weitere Aktivitäten, etwa Zahlungen, Gutschriften, Inkassoanrufe und Statusänderungen. Dafür können andere Datensatztypen wie „Phone Call“ oder eine Suche in „System Notes“ erforderlich sein.
Führen Sie die Suchen aus und exportieren Sie die Daten: Führen Sie jede gespeicherte Suche einzeln aus. Klicken Sie auf der Ergebnisseite auf das Symbol „Export - CSV“, um die Daten herunterzuladen. Vergeben Sie aussagekräftige Dateinamen, zum Beispiel invoice_generated.csv und payment_received.csv.
Erzeugen Sie Ereignisse für „Zahlungsfälligkeitsdatum überschritten“: Dieses Ereignis lässt sich nicht direkt exportieren. Berechnen Sie es nach dem Datenexport. Erstellen Sie in einem geeigneten Datenverarbeitungstool wie Python, Power Query oder einem ETL-Tool für jede noch nicht vollständig bezahlte Rechnung eine Zeile. Setzen Sie ActivityName auf „Zahlungsfälligkeitsdatum überschritten“ und EventTime auf das DueDate plus einen Tag.
Führen Sie die exportierten Dateien zusammen: Verwenden Sie ein externes Tool, um alle exportierten CSV-Dateien in einer gemeinsamen Datei zusammenzuführen. Achten Sie darauf, dass die Spaltenüberschriften in allen Dateien identisch sind.
Formatieren Sie die Daten abschließend: Prüfen Sie die zusammengeführte CSV-Datei. Stellen Sie sicher, dass EventTime ein einheitliches Timestamp-Format verwendet, zum Beispiel YYYY-MM-DD HH:MI:SS, und dass jede Zeile alle erforderlichen Spalten (InvoiceNumber, ActivityName, EventTime) enthält.
Laden Sie die Daten in ProcessMind hoch: Die zusammengeführte CSV-Datei kann nun als Event Log hochgeladen werden.

Konfiguration

Voraussetzungen: Sie benötigen eine Benutzerrolle mit Berechtigungen zum Erstellen, Bearbeiten und Exportieren gespeicherter Suchen. Außerdem ist Zugriff auf die folgenden Datensatztypen erforderlich: Transaktion (für Rechnungen, Zahlungen und Gutschriften), Phone Call (oder andere CRM-Aktivitätsdatensätze) und System Notes.
Datensatztypen: Für diese Suchen werden hauptsächlich die Datensatztypen Transaktion und Phone Call verwendet. Der Datensatz „System Note“ dient außerdem dazu, Statusänderungen und Mitteilungen zu erfassen, wenn keine direkten Transaktionsdatensätze verfügbar sind.
Filter für den Zeitraum: Wenden Sie in allen gespeicherten Suchen einen einheitlichen Datumsfilter an, zum Beispiel Date Created oder Last Modified Date. So bleibt die Leistung im gewünschten Rahmen und das Datenvolumen überschaubar. Für eine erste Analyse empfiehlt sich ein Zeitraum von 3 bis 6 Monaten.
Filter für Hauptzeilen: Verwenden Sie bei der Suche in Transaktionsdatensätzen das Kriterium Main Line is true, um nur Informationen auf Kopfebene zu erfassen. Dadurch werden Ereignisse nicht für jede einzelne Rechnungs- oder Zahlungsposition mehrfach gezählt.
Formeln verwenden: NetSuite-Formeln sind wichtig, um die standardisierte Spalte ActivityName zu erstellen. In Feldern vom Typ Formula (Text) können Sie den Aktivitätsnamen für jede Suche festlegen. Mit Formula (Date/Time) lassen sich bei Bedarf Timestamp-Felder vereinheitlichen.
Exportbeschränkungen: Der CSV-Export über die NetSuite-Benutzeroberfläche ist in der Regel auf 100.000 Zeilen pro Suche begrenzt. Bei größeren Datenmengen müssen Sie die Suchen möglicherweise für kürzere Zeiträume ausführen oder geplante Suchen verwenden, die Ergebnisse im File Cabinet ablegen.

a Beispielabfrage sql

/*
This configuration outlines the setup for multiple NetSuite Saved Searches. 
Each search is designed to extract a specific activity for the event log.
Create one Saved Search in the NetSuite UI for each block defined below.
*/

// Saved Search 1: Invoice Generated
{
  "SavedSearchName": "ProcessMind - Invoice Generated",
  "RecordType": "Transaction",
  "Criteria": [
    {"Field": "Type", "Operator": "is", "Value": "Invoice"},
    {"Field": "Main Line", "Operator": "is", "Value": "true"},
    {"Field": "Date Created", "Operator": "within", "Value": "[Your Date Range]"}
  ],
  "Results": [
    {"Column": "ActivityName", "Field": "Formula (Text)", "Formula": "'Invoice Generated'"},
    {"Column": "EventTime", "Field": "Date Created"},
    {"Column": "InvoiceNumber", "Field": "Document Number"},
    {"Column": "CustomerId", "Field": "Customer : Internal ID"},
    {"Column": "CustomerSegment", "Field": "Customer : Category"},
    {"Column": "InvoiceAmount", "Field": "Amount (Gross)"},
    {"Column": "DueDate", "Field": "Due Date"},
    {"Column": "InvoiceStatus", "Field": "Status"}
  ]
}

// Saved Search 2: Invoice Sent to Customer
{
  "SavedSearchName": "ProcessMind - Invoice Sent",
  "RecordType": "Transaction",
  "Criteria": [
    {"Field": "Type", "Operator": "is", "Value": "Invoice"},
    {"Field": "Main Line", "Operator": "is", "Value": "true"},
    {"Field": "System Notes : Field", "Operator": "is", "Value": "E-mailed"},
    {"Field": "System Notes : Date", "Operator": "within", "Value": "[Your Date Range]"}
  ],
  "Results": [
    {"Column": "ActivityName", "Field": "Formula (Text)", "Formula": "'Invoice Sent to Customer'"},
    {"Column": "EventTime", "Field": "System Notes : Date"},
    {"Column": "InvoiceNumber", "Field": "Document Number"},
    {"Column": "CustomerId", "Field": "Customer : Internal ID"},
    {"Column": "CustomerSegment", "Field": "Customer : Category"},
    {"Column": "InvoiceAmount", "Field": "Amount (Gross)"},
    {"Column": "DueDate", "Field": "Due Date"},
    {"Column": "InvoiceStatus", "Field": "Status"}
  ]
}

// Note: 'Payment Due Date Passed' is a calculated event, generated post-export.

// Saved Search 3: Overdue Reminder Sent & Dunning Procedure Initiated
{
  "SavedSearchName": "ProcessMind - Dunning Events",
  "RecordType": "Transaction",
  "Criteria": [
    {"Field": "Type", "Operator": "is", "Value": "Invoice"},
    {"Field": "Main Line", "Operator": "is", "Value": "true"},
    {"Field": "System Notes : Field", "Operator": "is", "Value": "[Your Dunning Status Field]"},
    {"Field": "System Notes : Date", "Operator": "within", "Value": "[Your Date Range]"}
  ],
  "Results": [
    {"Column": "ActivityName", "Field": "Formula (Text)", "Formula": "CASE WHEN {systemnotes.newvalue} = '[Your First Dunning Level]' THEN 'Dunning Procedure Initiated' ELSE 'Overdue Reminder Sent' END"},
    {"Column": "EventTime", "Field": "System Notes : Date"},
    {"Column": "InvoiceNumber", "Field": "Document Number"},
    {"Column": "CustomerId", "Field": "Customer : Internal ID"},
    {"Column": "CustomerSegment", "Field": "Customer : Category"},
    {"Column": "InvoiceAmount", "Field": "Amount (Gross)"},
    {"Column": "DueDate", "Field": "Due Date"},
    {"Column": "InvoiceStatus", "Field": "Status"}
  ]
}

// Saved Search 4: Collection Call Made
{
  "SavedSearchName": "ProcessMind - Collection Calls",
  "RecordType": "Phone Call",
  "Criteria": [
    {"Field": "Transaction : Type", "Operator": "is", "Value": "Invoice"},
    {"Field": "Date", "Operator": "within", "Value": "[Your Date Range]"}
  ],
  "Results": [
    {"Column": "ActivityName", "Field": "Formula (Text)", "Formula": "'Collection Call Made'"},
    {"Column": "EventTime", "Field": "Completed Date"},
    {"Column": "InvoiceNumber", "Field": "Transaction : Document Number"},
    {"Column": "CustomerId", "Field": "Company : Internal ID"},
    {"Column": "CustomerSegment", "Field": "Company : Category"},
    {"Column": "InvoiceAmount", "Field": "Transaction : Amount (Gross)"},
    {"Column": "DueDate", "Field": "Transaction : Due Date"},
    {"Column": "InvoiceStatus", "Field": "Transaction : Status"}
  ]
}

// Saved Search 5: Dispute Registered & Resolved
{
  "SavedSearchName": "ProcessMind - Dispute Status",
  "RecordType": "Transaction",
  "Criteria": [
    {"Field": "Type", "Operator": "is", "Value": "Invoice"},
    {"Field": "Main Line", "Operator": "is", "Value": "true"},
    {"Field": "System Notes : Field", "Operator": "is", "Value": "Status"},
    {"Field": "System Notes : Date", "Operator": "within", "Value": "[Your Date Range]"}
  ],
  "Results": [
    {"Column": "ActivityName", "Field": "Formula (Text)", "Formula": "CASE WHEN {systemnotes.newvalue} LIKE '%Disputed%' THEN 'Dispute Registered' WHEN {systemnotes.oldvalue} LIKE '%Disputed%' THEN 'Dispute Resolved' ELSE NULL END"},
    {"Column": "EventTime", "Field": "System Notes : Date"},
    {"Column": "InvoiceNumber", "Field": "Document Number"},
    {"Column": "CustomerId", "Field": "Customer : Internal ID"},
    {"Column": "CustomerSegment", "Field": "Customer : Category"},
    {"Column": "InvoiceAmount", "Field": "Amount (Gross)"},
    {"Column": "DueDate", "Field": "Due Date"},
    {"Column": "InvoiceStatus", "Field": "Status"}
  ]
}

// Saved Search 6: Credit Memo Issued
{
  "SavedSearchName": "ProcessMind - Credit Memos",
  "RecordType": "Transaction",
  "Criteria": [
    {"Field": "Type", "Operator": "is", "Value": "Credit Memo"},
    {"Field": "Main Line", "Operator": "is", "Value": "true"},
    {"Field": "Applied To Transaction : Type", "Operator": "is", "Value": "Invoice"},
    {"Field": "Date Created", "Operator": "within", "Value": "[Your Date Range]"}
  ],
  "Results": [
    {"Column": "ActivityName", "Field": "Formula (Text)", "Formula": "'Credit Memo Issued'"},
    {"Column": "EventTime", "Field": "Date Created"},
    {"Column": "InvoiceNumber", "Field": "Applied To Transaction : Document Number"},
    {"Column": "CustomerId", "Field": "Customer : Internal ID"},
    {"Column": "CustomerSegment", "Field": "Customer : Category"},
    {"Column": "InvoiceAmount", "Field": "Applied To Transaction : Amount (Gross)"},
    {"Column": "DueDate", "Field": "Applied To Transaction : Due Date"},
    {"Column": "InvoiceStatus", "Field": "Applied To Transaction : Status"}
  ]
}

// Saved Search 7: Payment Received & Posted
{
  "SavedSearchName": "ProcessMind - Payments",
  "RecordType": "Transaction",
  "Criteria": [
    {"Field": "Type", "Operator": "is", "Value": "Customer Payment"},
    {"Field": "Main Line", "Operator": "is", "Value": "true"},
    {"Field": "Date Created", "Operator": "within", "Value": "[Your Date Range]"}
  ],
  "Results": [
    // For 'Payment Received'
    {"Column": "ActivityName", "Field": "Formula (Text)", "Formula": "'Payment Received'"},
    {"Column": "EventTime", "Field": "Date Created"},
    // For 'Payment Posted'
    // {"Column": "ActivityName", "Field": "Formula (Text)", "Formula": "'Payment Posted'"},
    // {"Column": "EventTime", "Field": "[Your GL Posting Date Field]"},
    {"Column": "InvoiceNumber", "Field": "Applied To Transaction : Document Number"},
    {"Column": "CustomerId", "Field": "Customer : Internal ID"},
    {"Column": "CustomerSegment", "Field": "Customer : Category"},
    {"Column": "InvoiceAmount", "Field": "Applied To Transaction : Amount (Gross)"},
    {"Column": "DueDate", "Field": "Applied To Transaction : Due Date"},
    {"Column": "InvoiceStatus", "Field": "Applied To Transaction : Status"}
  ]
}

// Saved Search 8: Invoice Settled
{
  "SavedSearchName": "ProcessMind - Invoice Settled",
  "RecordType": "Transaction",
  "Criteria": [
    {"Field": "Type", "Operator": "is", "Value": "Invoice"},
    {"Field": "Main Line", "Operator": "is", "Value": "true"},
    {"Field": "Status", "Operator": "anyof", "Value": "Paid In Full"},
    {"Field": "Date Closed", "Operator": "within", "Value": "[Your Date Range]"}
  ],
  "Results": [
    {"Column": "ActivityName", "Field": "Formula (Text)", "Formula": "'Invoice Settled'"},
    {"Column": "EventTime", "Field": "Date Closed"},
    {"Column": "InvoiceNumber", "Field": "Document Number"},
    {"Column": "CustomerId", "Field": "Customer : Internal ID"},
    {"Column": "CustomerSegment", "Field": "Customer : Category"},
    {"Column": "InvoiceAmount", "Field": "Amount (Gross)"},
    {"Column": "DueDate", "Field": "Due Date"},
    {"Column": "InvoiceStatus", "Field": "Status"}
  ]
}

// Saved Search 9: Invoice Written Off
{
  "SavedSearchName": "ProcessMind - Invoice Written Off",
  "RecordType": "Transaction",
  "Criteria": [
    {"Field": "Type", "Operator": "is", "Value": "Journal Entry"},
    {"Field": "Main Line", "Operator": "is", "Value": "false"},
    {"Field": "Account", "Operator": "is", "Value": "[Your Bad Debt Expense Account]"},
    {"Field": "Date Created", "Operator": "within", "Value": "[Your Date Range]"}
  ],
  "Results": [
    {"Column": "ActivityName", "Field": "Formula (Text)", "Formula": "'Invoice Written Off'"},
    {"Column": "EventTime", "Field": "Date Created"},
    {"Column": "InvoiceNumber", "Field": "Created From : Document Number"},
    {"Column": "CustomerId", "Field": "Created From : Customer : Internal ID"},
    {"Column": "CustomerSegment", "Field": "Created From : Customer : Category"},
    {"Column": "InvoiceAmount", "Field": "Created From : Amount (Gross)"},
    {"Column": "DueDate", "Field": "Created From : Due Date"},
    {"Column": "InvoiceStatus", "Field": "Created From : Status"}
  ]
}

Schritte

Voraussetzungen: Stellen Sie sicher, dass Python 3.6 oder höher auf Ihrem System installiert ist. Außerdem benötigen Sie Zugangsdaten für NetSuite SuiteTalk, insbesondere für die Token Based Authentication (TBA): Account ID, Consumer Key, Consumer Secret, Token ID und Token Secret. Die zugehörige NetSuite-Rolle muss Zugriff auf alle erforderlichen Datensätze haben, darunter Transaktionen (Rechnungen, Zahlungen und Gutschriften), CRM-Aktivitäten (Telefonanrufe) und Kundendatensätze.
Installieren Sie die Python-Bibliotheken: Öffnen Sie die Befehlszeile oder das Terminal und installieren Sie die erforderlichen Python-Bibliotheken. Dazu gehören pandas für die Datenverarbeitung sowie requests und requests_oauthlib für API-Aufrufe. Alternativ können Sie eine spezielle NetSuite-Bibliothek verwenden. pip install pandas requests requests_oauthlib
Richten Sie die Authentifizierung ein: Suchen Sie im bereitgestellten Python-Skript den Abschnitt für die Zugangsdaten. Tragen Sie Ihre NetSuite Account ID, Ihren Consumer Key, Consumer Secret, Token ID und Token Secret in die vorgesehenen Platzhaltervariablen ein. Verwenden Sie dafür vorzugsweise Umgebungsvariablen oder einen sicheren Tresor, statt die Zugangsdaten direkt im Skript zu hinterlegen.
Konfigurieren Sie die Extraktionsparameter: Legen Sie im Skript die Variablen start_date und end_date für den gewünschten Zeitraum fest. Passen Sie bei Bedarf auch den Filter subsidiary_id an, um die Extraktion auf eine bestimmte NetSuite-Tochtergesellschaft zu begrenzen.
Machen Sie sich mit der Skriptlogik vertraut: Das Skript fragt jede der 13 erforderlichen Aktivitäten separat ab. Jede Abfrage ist eine eigene SuiteQL-Anweisung, die an den NetSuite-REST-API-Endpunkt gesendet wird. Die API-Paginierung übernimmt das Skript automatisch, sodass alle Datensätze für jede Abfrage abgerufen werden.
Führen Sie das Python-Skript aus: Starten Sie das Skript im Terminal mit dem Befehl python your_netsuite_extraction_script.py. Das Skript stellt eine Verbindung zu NetSuite her, führt die Abfragen nacheinander aus und gibt für jede abgerufene Aktivität Statusmeldungen in der Konsole aus.
Führen Sie die Daten zusammen und transformieren Sie sie: Nach dem Abruf der Rohdaten für jede Aktivität fügt das Skript mithilfe der Bibliothek pandas alle Einzelergebnisse zu einem einheitlichen DataFrame zusammen. Dieser DataFrame bildet das Event Log.
Prüfen und speichern Sie das Event Log: Das Skript speichert den fertigen DataFrame in einer CSV-Datei namens netsuite_collections_event_log.csv. Öffnen Sie die Datei und prüfen Sie, ob die Daten vollständig und korrekt sind.
Bereiten Sie den Upload vor: Stellen Sie sicher, dass die fertige CSV-Datei die erforderlichen Spaltenüberschriften InvoiceNumber, ActivityName und EventTime sowie alle empfohlenen Attribute enthält. Anschließend kann die Datei in ProcessMind hochgeladen werden.

Konfiguration

Authentifizierung: Das Skript verwendet die Token Based Authentication (TBA) von NetSuite. Sie müssen Account ID, Consumer Key, Consumer Secret, Token ID und Token Secret angeben. Die mit dem Token verknüpfte Rolle benötigt Lesezugriff auf die Datensätze Transaction, Customer, Phone Call und Message.
Datumsbereich: Die Variablen start_date und end_date im Skript legen den Extraktionszeitraum fest. Für eine erste Analyse empfiehlt sich ein Zeitraum von 3 bis 6 Monaten, um Datenvolumen und Leistung in Einklang zu bringen.
Filter für Tochtergesellschaften: Die Variable subsidiary_id dient dazu, die Daten auf eine bestimmte Geschäftseinheit zu begrenzen. Wenn Sie nur eine Tochtergesellschaft haben, können Sie den Filter weglassen.
API-Endpunkt: Das Skript greift auf den NetSuite-SuiteQL-REST-API-Endpunkt zu. Stellen Sie sicher, dass dieser für Ihr Konto aktiviert ist (/services/rest/query/v1/suiteql).
Paginierung: Das Skript enthält eine Funktion, die paginierte API-Antworten automatisch verarbeitet. page_size ist auf 1000 gesetzt, dem von der API zugelassenen Höchstwert. So wird die Anzahl der erforderlichen API-Aufrufe reduziert.
Benutzerdefinierte Felder: Für die Extraktion der Ereignisse „Streitfall erfasst“ und „Streitfall gelöst“ geht das Skript davon aus, dass die benutzerdefinierten Felder custbody_dispute_date und custbody_dispute_resolved_date verwendet werden. Passen Sie das Skript an die tatsächlichen Feld-IDs Ihrer NetSuite-Instanz an.

a Beispielabfrage python

import pandas as pd
import requests
from requests_oauthlib import OAuth1
import json
import os
from datetime import datetime

class=class="hl-string">"hl-comment"># --- Configuration Settings ---
class=class="hl-string">"hl-comment"># Best practice: Use environment variables instead of hardcoding credentials.
NS_ACCOUNT = os.getenv(class="hl-string">'NS_ACCOUNT', class="hl-string">'[Your NetSuite Account ID]')
NS_CONSUMER_KEY = os.getenv(class="hl-string">'NS_CONSUMER_KEY', class="hl-string">'[Your Consumer Key]')
NS_CONSUMER_SECRET = os.getenv(class="hl-string">'NS_CONSUMER_SECRET', class="hl-string">'[Your Consumer Secret]')
NS_TOKEN_ID = os.getenv(class="hl-string">'NS_TOKEN_ID', class="hl-string">'[Your Token ID]')
NS_TOKEN_SECRET = os.getenv(class="hl-string">'NS_TOKEN_SECRET', class="hl-string">'[Your Token Secret]')

class=class="hl-string">"hl-comment"># The base URL for the SuiteQL API endpoint
BASE_URL = fclass="hl-string">"https://{NS_ACCOUNT.replace('_', '-')}.suitetalk.api.netsuite.com/services/rest/query/v1/suiteql"

class=class="hl-string">"hl-comment"># --- Extraction Parameters ---
START_DATE = class="hl-string">'2023-01-01'
END_DATE = class="hl-string">'2023-12-31'
SUBSIDIARY_ID = class="hl-string">'[Your Subsidiary ID]' class=class="hl-string">"hl-comment"># Optional: filter by subsidiary

def execute_suiteql(query):
    class="hl-string">"""Executes a SuiteQL query and handles pagination."""
    all_results = []
    offset = 0
    limit = 1000

    oauth = OAuth1(
        client_key=NS_CONSUMER_KEY,
        client_secret=NS_CONSUMER_SECRET,
        resource_owner_key=NS_TOKEN_ID,
        resource_owner_secret=NS_TOKEN_SECRET,
        realm=NS_ACCOUNT,
        signature_method=class="hl-string">'HMAC-SHA256'
    )

    headers = {
        class="hl-string">'Content-Type': class="hl-string">'application/json',
        class="hl-string">'Prefer': class="hl-string">'transient'
    }

    while True:
        paginated_query = fclass="hl-string">"{query} LIMIT {limit} OFFSET {offset}"
        payload = json.dumps({class="hl-string">'q': paginated_query})
        
        try:
            response = requests.post(BASE_URL, headers=headers, data=payload, auth=oauth)
            response.raise_for_status() class=class="hl-string">"hl-comment"># Raise an exception for bad status codes
            data = response.json()
            
            if not data.get(class="hl-string">'items'):
                break

            all_results.extend(data[class="hl-string">'items'])
            
            if not data.get(class="hl-string">'hasMore', False):
                break
            
            offset += limit

        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"API Request Error: {e}")
            print(fclass="hl-string">"Response body: {response.text if 'response' in locals() else 'No response'}")
            return None

    return all_results

def main():
    class="hl-string">"""Main function to orchestrate the data extraction."""
    all_events = []
    
    class=class="hl-string">"hl-comment"># Common WHERE clause for filtering by date and subsidiary
    common_filter = fclass="hl-string">"WHERE T.trandate BETWEEN TO_DATE('{START_DATE}', 'YYYY-MM-DD') AND TO_DATE('{END_DATE}', 'YYYY-MM-DD') AND T.subsidiary = {SUBSIDIARY_ID}"

    class=class="hl-string">"hl-comment"># --- Define SuiteQL Queries for Each Activity ---
    queries = {
        class="hl-string">'Invoice Generated': fclass="hl-string">"""
            SELECT
                T.tranid AS InvoiceNumber,
                'Invoice Generated' AS ActivityName,
                TO_CHAR(T.createdDate, 'YYYY-MM-DD"T"HH24:MI:SS"Z"') AS EventTime,
                T.entity AS CustomerId,
                BUILTIN.DF(C.category) AS CustomerSegment,
                T.foreignTotal AS InvoiceAmount,
                TO_CHAR(T.dueDate, 'YYYY-MM-DD') AS DueDate,
                BUILTIN.DF(T.status) AS InvoiceStatus
            FROM
                Transaction AS T
                INNER JOIN Customer AS C ON T.entity = C.id
            WHERE
                T.type = 'CustInvc' AND T.voided = 'F' AND T.subsidiary = {SUBSIDIARY_ID}
                AND T.createdDate BETWEEN TO_TIMESTAMP('{START_DATE} 00:00:00', 'YYYY-MM-DD HH24:MI:SS') AND TO_TIMESTAMP('{END_DATE} 23:59:59', 'YYYY-MM-DD HH24:MI:SS')
        """,
        class="hl-string">'Invoice Sent to Customer': fclass="hl-string">"""
            SELECT
                T.tranid AS InvoiceNumber,
                'Invoice Sent to Customer' AS ActivityName,
                TO_CHAR(M.messageDate, 'YYYY-MM-DD"T"HH24:MI:SS"Z"') AS EventTime,
                T.entity AS CustomerId,
                BUILTIN.DF(C.category) AS CustomerSegment,
                T.foreignTotal AS InvoiceAmount,
                TO_CHAR(T.dueDate, 'YYYY-MM-DD') AS DueDate,
                BUILTIN.DF(T.status) AS InvoiceStatus
            FROM
                Transaction AS T
                INNER JOIN Message AS M ON T.id = M.transaction
                INNER JOIN Customer AS C ON T.entity = C.id
            WHERE
                T.type = 'CustInvc' AND T.voided = 'F' AND T.subsidiary = {SUBSIDIARY_ID}
                AND M.emailed = 'T' AND M.messageDate IS NOT NULL
                AND M.messageDate BETWEEN TO_TIMESTAMP('{START_DATE} 00:00:00', 'YYYY-MM-DD HH24:MI:SS') AND TO_TIMESTAMP('{END_DATE} 23:59:59', 'YYYY-MM-DD HH24:MI:SS')
        """,
        class="hl-string">'Payment Due Date Passed': fclass="hl-string">"""
            SELECT
                T.tranid AS InvoiceNumber,
                'Payment Due Date Passed' AS ActivityName,
                TO_CHAR(T.dueDate, 'YYYY-MM-DD"T"23:59:59"Z"') AS EventTime,
                T.entity AS CustomerId,
                BUILTIN.DF(C.category) AS CustomerSegment,
                T.foreignTotal AS InvoiceAmount,
                TO_CHAR(T.dueDate, 'YYYY-MM-DD') AS DueDate,
                BUILTIN.DF(T.status) AS InvoiceStatus
            FROM
                Transaction AS T
                INNER JOIN Customer AS C ON T.entity = C.id
            WHERE
                T.type = 'CustInvc' AND T.voided = 'F' AND T.subsidiary = {SUBSIDIARY_ID}
                AND T.status NOT IN ('CustInvc:B', 'CustInvc:A') -- Not Paid In Full or Pending Approval
                AND T.dueDate < CURRENT_DATE
                AND T.dueDate BETWEEN TO_DATE('{START_DATE}', 'YYYY-MM-DD') AND TO_DATE('{END_DATE}', 'YYYY-MM-DD')
        """,
        class="hl-string">'Overdue Reminder Sent': fclass="hl-string">"""
            SELECT
                T.tranid AS InvoiceNumber,
                'Overdue Reminder Sent' AS ActivityName,
                TO_CHAR(M.messageDate, 'YYYY-MM-DD"T"HH24:MI:SS"Z"') AS EventTime,
                T.entity AS CustomerId,
                BUILTIN.DF(C.category) AS CustomerSegment,
                T.foreignTotal AS InvoiceAmount,
                TO_CHAR(T.dueDate, 'YYYY-MM-DD') AS DueDate,
                BUILTIN.DF(T.status) AS InvoiceStatus
            FROM
                Transaction AS T
                INNER JOIN Message AS M ON T.id = M.transaction
                INNER JOIN Customer AS C ON T.entity = C.id
            WHERE
                T.type = 'CustInvc' AND T.voided = 'F' AND T.subsidiary = {SUBSIDIARY_ID}
                AND (M.subject LIKE '%Overdue%' OR M.subject LIKE '%Reminder%')
                AND M.messageDate BETWEEN TO_TIMESTAMP('{START_DATE} 00:00:00', 'YYYY-MM-DD HH24:MI:SS') AND TO_TIMESTAMP('{END_DATE} 23:59:59', 'YYYY-MM-DD HH24:MI:SS')
        """,
        class="hl-string">'Dunning Procedure Initiated': fclass="hl-string">"""
            SELECT
                T.tranid AS InvoiceNumber,
                'Dunning Procedure Initiated' AS ActivityName,
                TO_CHAR(SL.systemNoteDate, 'YYYY-MM-DD"T"HH24:MI:SS"Z"') AS EventTime,
                T.entity AS CustomerId,
                BUILTIN.DF(C.category) AS CustomerSegment,
                T.foreignTotal AS InvoiceAmount,
                TO_CHAR(T.dueDate, 'YYYY-MM-DD') AS DueDate,
                BUILTIN.DF(T.status) AS InvoiceStatus
            FROM
                Transaction AS T
                INNER JOIN Customer AS C ON T.entity = C.id
                INNER JOIN SystemNote AS SL ON T.id = SL.recordId
            WHERE
                T.type = 'CustInvc' AND T.voided = 'F' AND T.subsidiary = {SUBSIDIARY_ID}
                AND SL.field = 'custbody_dunning_level' AND SL.oldValue IS NULL -- Assumes a custom dunning level field
                AND SL.systemNoteDate BETWEEN TO_TIMESTAMP('{START_DATE} 00:00:00', 'YYYY-MM-DD HH24:MI:SS') AND TO_TIMESTAMP('{END_DATE} 23:59:59', 'YYYY-MM-DD HH24:MI:SS')
        """,
        class="hl-string">'Collection Call Made': fclass="hl-string">"""
            SELECT
                T.tranid AS InvoiceNumber,
                'Collection Call Made' AS ActivityName,
                TO_CHAR(PC.completedDate, 'YYYY-MM-DD"T"HH24:MI:SS"Z"') AS EventTime,
                T.entity AS CustomerId,
                BUILTIN.DF(C.category) AS CustomerSegment,
                T.foreignTotal AS InvoiceAmount,
                TO_CHAR(T.dueDate, 'YYYY-MM-DD') AS DueDate,
                BUILTIN.DF(T.status) AS InvoiceStatus
            FROM
                PhoneCall AS PC
                INNER JOIN Transaction AS T ON PC.transaction = T.id
                INNER JOIN Customer AS C ON T.entity = C.id
            WHERE
                T.type = 'CustInvc' AND T.voided = 'F' AND T.subsidiary = {SUBSIDIARY_ID}
                AND PC.title LIKE '%Collection%'
                AND PC.completedDate BETWEEN TO_TIMESTAMP('{START_DATE} 00:00:00', 'YYYY-MM-DD HH24:MI:SS') AND TO_TIMESTAMP('{END_DATE} 23:59:59', 'YYYY-MM-DD HH24:MI:SS')
        """,
        class="hl-string">'Dispute Registered': fclass="hl-string">"""
            SELECT
                T.tranid AS InvoiceNumber,
                'Dispute Registered' AS ActivityName,
                TO_CHAR(T.custbody_dispute_date, 'YYYY-MM-DD"T"HH24:MI:SS"Z"') AS EventTime,
                T.entity AS CustomerId,
                BUILTIN.DF(C.category) AS CustomerSegment,
                T.foreignTotal AS InvoiceAmount,
                TO_CHAR(T.dueDate, 'YYYY-MM-DD') AS DueDate,
                BUILTIN.DF(T.status) AS InvoiceStatus
            FROM
                Transaction AS T
                INNER JOIN Customer AS C ON T.entity = C.id
            WHERE
                T.type = 'CustInvc' AND T.voided = 'F' AND T.subsidiary = {SUBSIDIARY_ID}
                AND T.custbody_dispute_date IS NOT NULL -- Assumes a custom dispute date field
                AND T.custbody_dispute_date BETWEEN TO_DATE('{START_DATE}', 'YYYY-MM-DD') AND TO_DATE('{END_DATE}', 'YYYY-MM-DD')
        """,
        class="hl-string">'Dispute Resolved': fclass="hl-string">"""
            SELECT
                T.tranid AS InvoiceNumber,
                'Dispute Resolved' AS ActivityName,
                TO_CHAR(T.custbody_dispute_resolved_date, 'YYYY-MM-DD"T"HH24:MI:SS"Z"') AS EventTime,
                T.entity AS CustomerId,
                BUILTIN.DF(C.category) AS CustomerSegment,
                T.foreignTotal AS InvoiceAmount,
                TO_CHAR(T.dueDate, 'YYYY-MM-DD') AS DueDate,
                BUILTIN.DF(T.status) AS InvoiceStatus
            FROM
                Transaction AS T
                INNER JOIN Customer AS C ON T.entity = C.id
            WHERE
                T.type = 'CustInvc' AND T.voided = 'F' AND T.subsidiary = {SUBSIDIARY_ID}
                AND T.custbody_dispute_resolved_date IS NOT NULL -- Assumes a custom dispute resolved date field
                AND T.custbody_dispute_resolved_date BETWEEN TO_DATE('{START_DATE}', 'YYYY-MM-DD') AND TO_DATE('{END_DATE}', 'YYYY-MM-DD')
        """,
        class="hl-string">'Credit Memo Issued': fclass="hl-string">"""
            SELECT
                AppliedTo.tranid AS InvoiceNumber,
                'Credit Memo Issued' AS ActivityName,
                TO_CHAR(CM.trandate, 'YYYY-MM-DD"T"HH24:MI:SS"Z"') AS EventTime,
                CM.entity AS CustomerId,
                BUILTIN.DF(C.category) AS CustomerSegment,
                AppliedTo.foreignTotal AS InvoiceAmount,
                TO_CHAR(AppliedTo.dueDate, 'YYYY-MM-DD') AS DueDate,
                BUILTIN.DF(AppliedTo.status) AS InvoiceStatus
            FROM
                Transaction AS CM
                INNER JOIN TransactionLine AS CML ON CM.id = CML.transaction
                INNER JOIN Transaction AS AppliedTo ON CML.appliedToTransaction = AppliedTo.id
                INNER JOIN Customer AS C ON CM.entity = C.id
            WHERE
                CM.type = 'CustCred' AND CM.voided = 'F' AND CM.subsidiary = {SUBSIDIARY_ID}
                AND AppliedTo.type = 'CustInvc'
                AND CM.trandate BETWEEN TO_DATE('{START_DATE}', 'YYYY-MM-DD') AND TO_DATE('{END_DATE}', 'YYYY-MM-DD')
        """,
        class="hl-string">'Payment Received': fclass="hl-string">"""
            SELECT
                AppliedTo.tranid AS InvoiceNumber,
                'Payment Received' AS ActivityName,
                TO_CHAR(P.trandate, 'YYYY-MM-DD"T"HH24:MI:SS"Z"') AS EventTime,
                P.entity AS CustomerId,
                BUILTIN.DF(C.category) AS CustomerSegment,
                AppliedTo.foreignTotal AS InvoiceAmount,
                TO_CHAR(AppliedTo.dueDate, 'YYYY-MM-DD') AS DueDate,
                BUILTIN.DF(AppliedTo.status) AS InvoiceStatus
            FROM
                Transaction AS P
                INNER JOIN TransactionLine AS PL ON P.id = PL.transaction
                INNER JOIN Transaction AS AppliedTo ON PL.appliedToTransaction = AppliedTo.id
                INNER JOIN Customer AS C ON P.entity = C.id
            WHERE
                P.type = 'CustPymt' AND P.voided = 'F' AND P.subsidiary = {SUBSIDIARY_ID}
                AND AppliedTo.type = 'CustInvc'
                AND P.trandate BETWEEN TO_DATE('{START_DATE}', 'YYYY-MM-DD') AND TO_DATE('{END_DATE}', 'YYYY-MM-DD')
        """,
        class="hl-string">'Payment Posted': fclass="hl-string">"""
            SELECT
                AppliedTo.tranid AS InvoiceNumber,
                'Payment Posted' AS ActivityName,
                TO_CHAR(P.postingdate, 'YYYY-MM-DD"T"HH24:MI:SS"Z"') AS EventTime,
                P.entity AS CustomerId,
                BUILTIN.DF(C.category) AS CustomerSegment,
                AppliedTo.foreignTotal AS InvoiceAmount,
                TO_CHAR(AppliedTo.dueDate, 'YYYY-MM-DD') AS DueDate,
                BUILTIN.DF(AppliedTo.status) AS InvoiceStatus
            FROM
                Transaction AS P
                INNER JOIN TransactionLine AS PL ON P.id = PL.transaction
                INNER JOIN Transaction AS AppliedTo ON PL.appliedToTransaction = AppliedTo.id
                INNER JOIN Customer AS C ON P.entity = C.id
            WHERE
                P.type = 'CustPymt' AND P.voided = 'F' AND P.subsidiary = {SUBSIDIARY_ID}
                AND AppliedTo.type = 'CustInvc' AND P.posting = 'T'
                AND P.postingdate BETWEEN TO_DATE('{START_DATE}', 'YYYY-MM-DD') AND TO_DATE('{END_DATE}', 'YYYY-MM-DD')
        """,
        class="hl-string">'Invoice Settled': fclass="hl-string">"""
            SELECT
                T.tranid AS InvoiceNumber,
                'Invoice Settled' AS ActivityName,
                TO_CHAR(T.lastModifiedDate, 'YYYY-MM-DD"T"HH24:MI:SS"Z"') AS EventTime,
                T.entity AS CustomerId,
                BUILTIN.DF(C.category) AS CustomerSegment,
                T.foreignTotal AS InvoiceAmount,
                TO_CHAR(T.dueDate, 'YYYY-MM-DD') AS DueDate,
                BUILTIN.DF(T.status) AS InvoiceStatus
            FROM
                Transaction AS T
                INNER JOIN Customer AS C ON T.entity = C.id
            WHERE
                T.type = 'CustInvc' AND T.voided = 'F' AND T.subsidiary = {SUBSIDIARY_ID}
                AND T.status = 'CustInvc:B' -- Paid In Full
                AND T.lastModifiedDate BETWEEN TO_TIMESTAMP('{START_DATE} 00:00:00', 'YYYY-MM-DD HH24:MI:SS') AND TO_TIMESTAMP('{END_DATE} 23:59:59', 'YYYY-MM-DD HH24:MI:SS')
        """,
        class="hl-string">'Invoice Written Off': fclass="hl-string">"""
            SELECT
                AppliedTo.tranid AS InvoiceNumber,
                'Invoice Written Off' AS ActivityName,
                TO_CHAR(JE.trandate, 'YYYY-MM-DD"T"HH24:MI:SS"Z"') AS EventTime,
                JE.entity AS CustomerId,
                BUILTIN.DF(C.category) AS CustomerSegment,
                AppliedTo.foreignTotal AS InvoiceAmount,
                TO_CHAR(AppliedTo.dueDate, 'YYYY-MM-DD') AS DueDate,
                BUILTIN.DF(AppliedTo.status) AS InvoiceStatus
            FROM
                Transaction AS JE
                INNER JOIN TransactionLine AS JEL ON JE.id = JEL.transaction
                INNER JOIN Transaction AS AppliedTo ON JEL.entity = AppliedTo.entity -- A best-effort link via customer
                INNER JOIN Customer AS C ON JE.entity = C.id
            WHERE
                JE.type = 'Journal' AND JE.voided = 'F' AND JE.subsidiary = {SUBSIDIARY_ID}
                AND JEL.account = [Your Bad Debt Expense Account ID] -- Must configure your specific bad debt account
                AND AppliedTo.type = 'CustInvc'
                AND JE.trandate BETWEEN TO_DATE('{START_DATE}', 'YYYY-MM-DD') AND TO_DATE('{END_DATE}', 'YYYY-MM-DD')
                AND (JEL.memo LIKE '%' || AppliedTo.tranid || '%' OR JE.memo LIKE '%' || AppliedTo.tranid || '%') -- Best-effort link by checking memo field for invoice number
        """
    }

    for activity, query in queries.items():
        print(fclass="hl-string">"Fetching data for: {activity}...")
        results = execute_suiteql(query)
        if results:
            all_events.extend(results)
            print(fclass="hl-string">"  ...found {len(results)} events.")
        else:
            print(fclass="hl-string">"  ...no events found or an error occurred.")

    if not all_events:
        print(class="hl-string">"No data extracted. Exiting.")
        return

    class=class="hl-string">"hl-comment"># Convert to pandas DataFrame
    df = pd.DataFrame(all_events)
    
    class=class="hl-string">"hl-comment"># Data Cleaning and Formatting
    df[class="hl-string">'EventTime'] = pd.to_datetime(df[class="hl-string">'EventTime'])
    df = df.sort_values(by=[class="hl-string">'InvoiceNumber', class="hl-string">'EventTime'])
    df.rename(columns=lambda c: class="hl-string">''.join(c.split()).capitalize(), inplace=True)
    
    class=class="hl-string">"hl-comment"># Save to CSV
    output_file = class="hl-string">'netsuite_collections_event_log.csv'
    df.to_csv(output_file, index=False)
    print(fclass="hl-string">"\nEvent log successfully saved to {output_file}")

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

Möchten Sie beginnen?

Verwenden Sie dieses Template, um Ihre Datenaufbereitung zu vereinfachen und aussagekräftige Erkenntnisse zu Ihrem Kreditmanagement- und Forderungseinzugsprozess zu gewinnen. Verbessern Sie noch heute Ihren Cashflow.

Zurück zum Leitfaden zur Prozessverbesserung Template herunterladen

Optimieren Sie noch heute Kreditmanagement und Forderungseinzug!

Decken Sie Ineffizienzen auf, verkürzen Sie die Durchlaufzeit um 30 % und verbessern Sie Ihren Cashflow schnell.

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich. Die Einrichtung dauert nur wenige Minuten.

Ihr Daten-Template für Kreditmanagement und Forderungseinzug

Ihr Daten-Template für Kreditmanagement und Forderungseinzug

Attribute für Kreditmanagement und Forderungseinzug

Aktivitäten im Kreditmanagement und Forderungseinzug

Anleitungen zur Datenextraktion

Datenexport aus gespeicherten Suchen und Berichten in NetSuite

Schritte

Konfiguration

a Beispielabfrage sql

Datenextraktion mit Python über NetSuite SuiteTalk Web Services

Schritte

Konfiguration

a Beispielabfrage python

Möchten Sie beginnen?

Optimieren Sie noch heute Kreditmanagement und Forderungseinzug!

Ihr Daten-Template für Kreditmanagement und Forderungseinzug

Ihr Daten-Template für Kreditmanagement und Forderungseinzug

Attribute für Kreditmanagement und Forderungseinzug

Aktivitäten im Kreditmanagement und Forderungseinzug

Anleitungen zur Datenextraktion

Datenexport aus gespeicherten Suchen und Berichten in NetSuite

Schritte

Konfiguration

a Beispielabfrage sql

Datenextraktion mit Python über NetSuite SuiteTalk Web Services

Schritte

Konfiguration

a Beispielabfrage python

Möchten Sie beginnen?

Optimieren Sie noch heute Kreditmanagement und Forderungseinzug!

Der Schutz Ihrer Daten ist uns wichtig