> Amélioration continue des processus > Créances clients > NetSuite > Modèle de données

Votre modèle de données pour les comptes clients

NetSuite

Attributs des comptes clients (22) Activités des comptes clients (13) Guides d’extraction (3)

Votre modèle de données pour les comptes clients

Ce modèle fournit un plan détaillé pour représenter le cycle de facturation et de recouvrement dans NetSuite. Il répertorie les attributs essentiels et les activités du processus nécessaires à la création d’un journal d’événements de qualité, afin que vous disposiez de la visibilité requise pour optimiser votre trésorerie. En suivant ce guide, vous pouvez simplifier la préparation des données et réduire le délai moyen de paiement de vos clients.

Attributs NetSuite essentiels pour une analyse approfondie
Étapes clés normalisées pour le suivi des activités de comptes clients
Conseils d’extraction pour les systèmes NetSuite

Vous découvrez les journaux d’événements ? Découvrez comment créer un journal d’événements pour le Process Mining.

Télécharger le modèle

Attributs des comptes clients

Le tableau ci-dessous répertorie les champs de données et les attributs dimensionnels recommandés pour obtenir une vue complète du cycle de vie des factures dans NetSuite.

5 Obligatoire 7 Recommandé 10 Facultatif

	Nom	Description
	Activité Activity	L’événement ou l’action précise réalisée sur la facture.
Description Cet attribut correspond au nom d’une étape du processus, par exemple « Facture créée », « Paiement imputé » ou « Litige ouvert ». Dans NetSuite, il est généralement dérivé du champ `type` de la transaction pour les événements de création, ou de la table `SystemNote` pour les changements de statut et les modifications. Il joue un rôle central dans le Process Mining, car il définit les nœuds du graphe du processus. En analysant la séquence de ces activités, les analystes peuvent repérer les goulots d’étranglement, les boucles (par exemple, le traitement répété d’un litige) et les écarts par rapport au parcours nominal. Pourquoi est-ce important ? Définit les étapes du flux de travail et permet de construire le graphe du processus. Où trouver ces données Dérivé du champ 'type' de Transaction ou des champs 'field'/'value' de SystemNote Exemples Facture crééePaiement reçuAvoir émisLitige ouvert
	Horodatage de l’événement DateCreated	La date et l’heure exactes auxquelles l’activité a eu lieu.
Description Cet attribut indique le moment précis où un événement s’est produit. Pour la création de la facture, il s’agit du champ `datecreated` de la table Transaction. Pour les mises à jour ultérieures, il s’agit de l’horodatage figurant dans les tables `SystemNote` ou `Message`. Des horodatages exacts sont indispensables pour calculer les temps de cycle, comme le temps de cycle moyen entre la facturation et l’encaissement et le délai d’émission des factures. Ils permettent de remettre les événements dans le bon ordre et de repérer les délais entre les étapes du processus. Pourquoi est-ce important ? Indispensable pour ordonner les événements et calculer la durée entre les étapes du processus. Où trouver ces données Champ 'datecreated' de Transaction ou champ 'date' de SystemNote Exemples 2023-10-15T08:30:00Z2023-10-15T14:45:22Z2023-11-01T09:00:00Z
	Numéro de facture TranId	Le numéro de référence unique attribué à la facture dans NetSuite.
Description Cet attribut sert d’identifiant principal du cas pour le processus de gestion des créances clients. Dans NetSuite, le champ `tranid` contient généralement le numéro du document (par exemple, INV-10023), visible par les utilisateurs et les clients. Il relie à une obligation financière précise tous les événements ultérieurs, tels que les paiements, les litiges et les avoirs. Dans les analyses, cet identifiant permet de regrouper les événements individuels au sein d’un même cas de processus. Il permet de visualiser le cycle de la commande à l’encaissement de bout en bout et est indispensable pour joindre les données de différentes tables NetSuite, telles que `Transaction`, `TransactionLine` et `SystemNote`. Pourquoi est-ce important ? Il s’agit de la clé fondamentale pour suivre le cycle de vie d’une créance et calculer les temps de cycle. Où trouver ces données Table Transaction, champ 'tranid' Exemples INV-2023-001INV-998822CM-4022JE-10023
	Dernière mise à jour des données LastDataUpdate	L’horodatage de l’extraction des données ou de leur dernière actualisation.
Description Cet attribut indique la date à laquelle l’instantané des données a été extrait de NetSuite. Il permet d’évaluer l’actualité de l’analyse et de calculer l’ancienneté des cas ouverts par rapport à la date d’analyse. Dans les Dashboards, il aide les utilisateurs à savoir s’ils consultent des données en temps réel ou une extraction historique. Il sert de référence pour calculer la durée d’ouverture actuelle des factures qui ne sont pas encore soldées. Pourquoi est-ce important ? Indique clairement l’actualité des données et facilite le calcul de la durée d’ouverture des cas. Où trouver ces données Heure système au moment de l’extraction Exemples 2023-12-01T00:00:00Z2023-12-02T12:00:00Z
	Système source SourceSystem	Le système de référence à partir duquel les données ont été extraites.
Description Cet attribut indique l’origine des données, qui est ici « NetSuite ». Dans un environnement composé de plusieurs systèmes, où les données de gestion des créances clients peuvent être rapprochées de celles d’un CRM ou d’un système bancaire externe, ce champ garantit la traçabilité. Il permet aux analystes de filtrer ou de segmenter la vue du processus par source de données lorsque plusieurs ERP sont analysés simultanément. Il s’agit généralement d’une valeur statique ajoutée lors de l’extraction et de la transformation des données. Pourquoi est-ce important ? Assure la traçabilité des données et apporte du contexte aux analyses de processus menées sur plusieurs systèmes. Où trouver ces données Valeur statique « NetSuite » Exemples NetSuiteERP NetSuiteNetSuite OneWorld
	Date d’échéance DueDate	La date à laquelle le paiement est attendu selon les conditions convenues.
Description Cet attribut contient la date d’échéance prévue de la facture, indiquée dans le champ `duedate` de NetSuite. Elle sert de référence pour déterminer si un paiement est effectué à temps ou en retard. C’est la variable principale pour calculer le nombre moyen de jours de retard par rapport aux conditions de paiement et repérer les risques liés au recouvrement de montants élevés. La comparaison entre cette date et le champ `DateCreated` de l’événement de paiement révèle l’ampleur des retards et aide à mesurer le respect des conditions de crédit. Pourquoi est-ce important ? Sert de référence pour tous les calculs d’ancienneté, de retard et de conformité. Où trouver ces données Table Transaction, champ 'duedate' Exemples 2023-11-152023-12-012024-01-30
	Montant de la facture TotalAmount	Le montant total de la facture.
Description Cet attribut correspond au montant total de la facture, généralement indiqué dans le champ `foreignTotal` ou `total` de la table Transaction de NetSuite. Il représente la somme à recouvrer auprès du client. Cette métrique sert à analyser les montants qui circulent dans le processus de gestion des créances clients, à prioriser le recouvrement des sommes élevées et à calculer des indicateurs clés de performance comme la valeur des litiges en attente. Elle permet de filtrer les cas par tranche de montant afin de concentrer les efforts d’optimisation sur les transactions ayant le plus d’impact. Pourquoi est-ce important ? Indispensable pour mesurer l’impact financier des inefficacités du processus et prioriser le recouvrement. Où trouver ces données Table Transaction, champ 'foreignTotal' ou 'total' Exemples 1500.00250.5010000.00
	Nom du client Entity	Le nom du client ou de l’entité associé à la facture.
Description Cet attribut identifie le client chargé de régler la facture. Dans NetSuite, il renvoie à la table `Entity` (fiche client). Il est essentiel à toute analyse centrée sur les clients. Les analystes s’en servent pour comparer les résultats par client et repérer ceux qui paient souvent en retard, génèrent des litiges ou ne respectent pas les conditions de paiement habituelles. Il alimente les Dashboards de suivi du respect des conditions de crédit et de la productivité des agents de recouvrement. Pourquoi est-ce important ? Permet de comparer les résultats du processus selon le comportement et le profil de risque des clients. Où trouver ces données Table Transaction, champ 'entity' (joint à la table Entity/Customer) Exemples Acme CorpGlobex CorporationSoylent Corp
	Représentant commercial SalesRep	Le représentant commercial associé à la facture.
Description Cet attribut identifie le représentant commercial responsable du compte ou de la transaction. Dans NetSuite, il s’agit souvent du champ `salesrep` de l’enregistrement de transaction. Il permet de relier les problèmes de facturation ou les avoirs à des membres précis de l’équipe commerciale. Par exemple, le Dashboard sur les avoirs et les pertes de revenus s’en sert pour repérer les représentants dont les factures font plus souvent l’objet d’ajustements ultérieurs, ce qui peut révéler des problèmes de qualité en amont du processus commercial. Pourquoi est-ce important ? Relie les problèmes de gestion des créances clients aux responsables du processus commercial en amont. Où trouver ces données Table Transaction, champ 'salesrep' Exemples John SmithSarah ConnorKyle Reese
	Service Department	Le service interne responsable de la transaction.
Description Cet attribut correspond au segment NetSuite `department`, qui indique le domaine fonctionnel (par exemple, ventes, services ou informatique) à l’origine de la facture. Il permet d’analyser les résultats de la gestion des créances clients entre les différentes fonctions. En segmentant les données par service, les analystes peuvent repérer les domaines où les cycles de facturation sont plus longs ou les litiges plus fréquents, et ainsi cibler les améliorations du processus. Pourquoi est-ce important ? Identifie les responsables internes du processus et met en évidence les écarts d’efficacité de facturation. Où trouver ces données Table Transaction, champ 'department' Exemples Services professionnelsVentes de logicielsLivraison de matériel
	Statut de la facture Status	Le statut actuel de la facture dans le système.
Description Cet attribut indique l’état de la transaction dans NetSuite, par exemple « Ouverte », « Intégralement payée » ou « En attente d’approbation ». Il est généralement dérivé du champ `status` ou `statusRef`. L’attribut Activité retrace les événements passés, tandis que celui-ci indique l’état actuel. Il est essentiel pour filtrer le Dashboard sur les risques liés au recouvrement de montants élevés et n’afficher que les factures encore ouvertes et en retard. Pourquoi est-ce important ? Permet de voir immédiatement quels cas sont clôturés et lesquels nécessitent une intervention. Où trouver ces données Table Transaction, champ 'status' Exemples Intégralement payéeOuverteEn attente d’approbation
	Unité opérationnelle Subsidiary	La filiale ou l’unité opérationnelle à laquelle appartient la facture.
Description Dans les environnements NetSuite OneWorld, cet attribut identifie l’entité juridique ou la filiale qui a émis la facture. Il permet de comparer les différentes succursales ou divisions de l’entreprise. Cet attribut alimente le Dashboard sur l’efficacité de l’envoi des factures et permet d’examiner les résultats par unité opérationnelle. Il aide à déterminer si les problèmes de processus touchent toute l’organisation ou seulement certaines unités opérationnelles. Pourquoi est-ce important ? Indispensable pour comparer les résultats entre différentes entités de l’organisation. Où trouver ces données Table Transaction, champ 'subsidiary' Exemples Ouest des États-UnisOpérations EMEAVentes APAC
	Agent de recouvrement CollectionAgent	L’utilisateur chargé des activités de recouvrement liées à cette facture.
Description Cet attribut identifie l’employé chargé du recouvrement de la facture. Il peut s’agir du représentant commercial ou d’un spécialiste dédié à la gestion des créances clients. L’information figure souvent dans un champ personnalisé ou est déduite de l’utilisateur qui consigne les activités de relance de paiement. Cet attribut alimente le Dashboard sur la productivité des agents de recouvrement. Les responsables peuvent ainsi comparer les résultats de l’équipe et repérer les besoins de formation ou les déséquilibres de charge de travail. Pourquoi est-ce important ? Permet d’évaluer les résultats de chaque membre de l’équipe de recouvrement. Où trouver ces données Champ 'name' de SystemNotes pour les activités de recouvrement ou champ personnalisé Exemples Agent SmithSpécialiste de la facturation AÉquipe de recouvrement 1
	Catégorie de produit Class	La catégorie ou la classe des biens ou services vendus.
Description Cet attribut correspond au segment NetSuite `class`. Il classe les sources de revenus (par exemple, matériel ou conseil). La composition de l’offre est un élément important de l’analyse. Il permet d’analyser le Dashboard sur les avoirs et les pertes de revenus afin de déterminer si certaines gammes de produits sont davantage sujettes aux retours ou aux erreurs de facturation. Pourquoi est-ce important ? Permet de comparer les résultats du processus selon le type de produit ou de service vendu. Où trouver ces données Table Transaction, champ 'class' Exemples Revenus des licencesServices de conseilMatériel
	Code de devise Currency	La devise dans laquelle la facture a été émise.
Description Cet attribut indique le code de devise ISO (par exemple, USD ou EUR) de la transaction, figurant dans le champ `currency` de NetSuite. Il est nécessaire pour gérer correctement les environnements multidevises. Souvent utilisé en arrière-plan, il reste indispensable pour agréger `TotalAmount` sans additionner des montants exprimés dans des devises différentes sans conversion. Il apporte également un contexte aux écarts de résultats entre régions. Pourquoi est-ce important ? Indispensable pour agréger correctement les données financières dans les organisations internationales. Où trouver ces données Table Transaction, champ 'currency' Exemples USDEURGBP
	Conditions de paiement Terms	Les conditions de paiement convenues pour la facture.
Description Cet attribut précise les conditions de paiement associées à la facture, par exemple « Net 30 » ou « À réception ». Il figure dans le champ `terms` de l’enregistrement Transaction. Ces données servent à calculer la date de paiement prévue et à déterminer si les clients bénéficiant de conditions souples paient plus régulièrement que ceux soumis à des conditions strictes. Elles aident à réexaminer les politiques de crédit et à établir la référence pour l’indicateur clé de performance du nombre moyen de jours de retard par rapport aux conditions de paiement. Pourquoi est-ce important ? Définit le comportement attendu et le niveau de service pour le cycle de paiement du client. Où trouver ces données Table Transaction, champ 'terms' Exemples Net 30Net 60À réception2 % sous 10 jours, net à 30 jours
	Date promise de paiement PromiseDate	La date à laquelle le client s’est engagé à effectuer le paiement.
Description Cet attribut indique la date à laquelle le client s’est engagé à régler une facture en retard, généralement à la suite d’un échange avec un agent de recouvrement. Dans NetSuite, cette information est habituellement enregistrée dans la fiche « Phone Call » ou dans un champ personnalisé du corps de la transaction. Cette date est indispensable au Dashboard de suivi des engagements de paiement. En la comparant à la date réelle du paiement, l’organisation peut mesurer la fiabilité des engagements des clients et l’efficacité des appels de recouvrement. Pourquoi est-ce important ? Mesure la fiabilité des engagements des clients et l’efficacité du recouvrement. Où trouver ces données Enregistrement Task/Phone Call ou champ personnalisé Exemples 2023-11-202023-12-05
	En litige IsDisputed	Indique si la facture fait actuellement l’objet d’un litige ou en a déjà fait l’objet.
Description Cet attribut booléen indique si la facture a fait l’objet d’un litige. Il est déduit de la présence d’activités liées à un litige ou d’un indicateur de statut spécifique dans l’enregistrement de la facture. Il sert de filtre essentiel pour l’analyse du cycle de vie des litiges et permet de distinguer les factures litigieuses des factures sans problème lors du calcul du taux de recouvrement dès la première tentative. Pourquoi est-ce important ? Distingue les cas complexes des cas suivant le parcours nominal. Où trouver ces données Calculé selon la présence de l’activité « Litige ouvert » Exemples truefalse
	Jours de retard DaysOverdue	Le nombre de jours écoulés depuis la date d’échéance d’une facture ouverte.
Description Cet attribut calculé correspond à l’écart entre `DueDate` et la date d’analyse actuelle (ou la date de paiement si la facture est clôturée). Il fournit une mesure continue de l’ancienneté. Il sert principalement à répartir les factures par tranches d’ancienneté (par exemple, de 30 à 60 jours ou de 60 à 90 jours) dans le Dashboard sur les risques liés au recouvrement de montants élevés. Il permet de repérer immédiatement les retards les plus importants. Pourquoi est-ce important ? Métrique standard pour évaluer l’importance des retards de paiement. Où trouver ces données Calcul : (date actuelle - DueDate) Exemples 150-5
	Mémo de la facture Memo	Notes ou descriptions associées à l’en-tête de la facture.
Description Cet attribut contient la description en texte libre ou le mémo saisi sur la facture, dans le champ `memo`. Il comprend souvent des notes manuelles sur un traitement particulier ou un accord avec le client. L’analyse de ce texte peut révéler des causes non structurées de retards ou de litiges que les champs structurés ne font pas apparaître. Elle complète les données quantitatives du processus par des éléments qualitatifs. Pourquoi est-ce important ? Apporte du contexte et des informations qualitatives sur la transaction. Où trouver ces données Table Transaction, champ 'memo' Exemples Frais de service pour octobreCorrection de la facture n° 1002Conditions de paiement particulières appliquées
	Motif du litige DisputeReason	Le code ou la description indiquant pourquoi une facture fait l’objet d’un litige.
Description Cet attribut indique la raison précise pour laquelle un client refuse de payer ou demande une correction. Dans NetSuite, il s’agit souvent d’un champ personnalisé ou d’un enregistrement « Case » associé à la facture. Il est essentiel au Dashboard d’analyse du cycle de vie des litiges. Le regroupement par motif permet de repérer les causes profondes, comme une erreur de prix, des marchandises endommagées ou un bon de commande manquant. Des corrections systémiques en amont peuvent alors prévenir de nouvelles pertes de revenus. Pourquoi est-ce important ? Permet de repérer les causes profondes des impayés et des échanges administratifs répétés. Où trouver ces données Dossier d’assistance associé ou champ personnalisé du corps de la transaction Exemples Prix incorrectMarchandises non reçuesErreur de taxe
	Région Location	Le lieu ou la région associé à la transaction.
Description Dans NetSuite, le champ `location` désigne souvent un entrepôt, un bureau ou une région géographique. Cet attribut associe ce champ à une région à des fins d’analyse. Il sert dans la vue d’ensemble des résultats DSO à repérer les différences régionales de comportement en matière de paiement. Il aide à déterminer si les problèmes de recouvrement sont généralisés ou limités à certains territoires. Pourquoi est-ce important ? Permet de comparer les résultats de la gestion des créances clients par zone géographique. Où trouver ces données Table Transaction, champ 'location' Exemples Entrepôt d’Amérique du NordBureau de LondresSingapour

Obligatoire Recommandé Facultatif

Activités des comptes clients

Voici les principales étapes du processus et les jalons des transactions à consigner dans votre journal d’événements pour représenter fidèlement le flux de recouvrement.

6 Recommandé 7 Facultatif

	Activité	Description
	Avoir émis	Création d’une transaction Credit Memo imputée à la facture. Elle réduit le solde ouvert et signale souvent un retour ou une erreur de facturation.
Pourquoi est-ce important ? Met en évidence les pertes de revenus. Des avoirs fréquents peuvent révéler des défaillances systémiques dans les processus de vente ou de livraison. Où trouver ces données Table Transaction : enregistrement de type « CustCred » imputé à l’identifiant de facture via « appliedtotransaction ». Données à recueillir Enregistré lors de l’exécution de la transaction Credit Memo Type d’événement explicit
	Facture approuvée	Passage du statut de la facture de Pending Approval à Open. Cette étape est détectée à partir de System Notes ou des journaux d’historique du flux de travail associés à la facture.
Pourquoi est-ce important ? Indique le temps de traitement interne avant la facturation du client. Les retards à cette étape allongent le temps de cycle total sans apporter de valeur au client. Où trouver ces données System Notes : filtrer le champ « status » lors de son passage de « Pending Approval » à « Open ». Données à recueillir Comparer la valeur du champ de statut avant et après le changement Type d’événement inferred
	Facture créée	Création initiale de l’enregistrement de facture dans le système. Cette étape est extraite de la table Transaction lorsque le type d’enregistrement est Invoice.
Pourquoi est-ce important ? Marque le début du cycle de gestion des créances clients et sert de référence pour calculer l’ancienneté des créances. Indispensable au calcul du temps de cycle entre la facture et l’encaissement. Où trouver ces données Table Transaction : champ « trandate » ou « datecreated » pour les enregistrements de type « CustInvc ». Données à recueillir Enregistré lors de l’exécution de la transaction Invoice Type d’événement explicit
	Facture envoyée	Envoi de la facture au client par courriel, courrier ou fax. Cette étape est détectée à partir des enregistrements Message associés à la transaction Invoice concernée.
Pourquoi est-ce important ? Indispensable à l’indicateur de délai d’émission des factures. Repérer les retards à cette étape permet de mettre au jour les goulots d’étranglement administratifs qui empêchent un recouvrement rapide. Où trouver ces données Table Messages : joindre les enregistrements à l’aide de l’identifiant de transaction, avec « authoremail » interne et « recipientemail » externe. Données à recueillir Enregistré lors de l’exécution de la transaction Email Type d’événement explicit
	Facture réglée	Dernier changement du statut de la facture à « Paid In Full ». Cette étape marque la fin du processus pour les cas réglés.
Pourquoi est-ce important ? Nécessaire au calcul du temps de cycle moyen entre la facture et l’encaissement. Permet de distinguer les éléments ouverts des éléments clôturés dans les variantes du processus. Où trouver ces données System Notes : changement du statut de l’enregistrement Invoice à « Paid In Full ». Données à recueillir Comparer la valeur du champ de statut avant et après le changement Type d’événement inferred
	Paiement intégral reçu	Imputation d’un paiement client qui ramène le solde de la facture à zéro. Cette étape marque la fin effective du recouvrement.
Pourquoi est-ce important ? Horodatage de référence pour le calcul du délai moyen de paiement client et du nombre moyen de jours de retard par rapport aux conditions convenues. Il correspond à l’encaissement effectif du revenu. Où trouver ces données Table Transaction : type « CustPymt » imputé à une facture dont le statut passe à « Paid In Full ». Données à recueillir Enregistré lors de l’exécution de la transaction Payment Type d’événement explicit
	Créance irrécouvrable passée en perte	Suppression du solde de la facture au moyen d’une écriture de journal ou d’un type spécifique de Credit Memo pour les montants irrécouvrables. Cette étape signale un échec du processus de recouvrement.
Pourquoi est-ce important ? Distingue les revenus non recouvrés des paiements encaissés dans l’analyse. Important pour comprendre l’efficacité réelle du recouvrement. Où trouver ces données Journal Entry ou Credit Memo : filtrer selon les comptes du grand livre concernés (Bad Debt Expense) et associés à la facture. Données à recueillir Déduire l’étape à partir de l’utilisation des comptes du grand livre Type d’événement inferred
	Litige ouvert	Ouverture d’un litige concernant la facture, souvent déduite de l’existence d’un Support Case associé ou d’un statut personnalisé. Cette étape interrompt le flux de recouvrement standard.
Pourquoi est-ce important ? Indispensable au Dashboard d’analyse du cycle de vie des litiges. Un volume élevé à cette étape signale des problèmes de qualité en amont, liés à la livraison ou à la facturation. Où trouver ces données Enregistrement Support Case : joindre à Transaction lorsque la catégorie est « Billing Dispute », ou repérer le changement de statut de Transaction à « Disputed ». Données à recueillir Comparer le champ de statut ou la création d’un enregistrement associé Type d’événement inferred
	Litige résolu	Clôture d’un litige, qui permet à la facture de redevenir recouvrable ou entraîne l’émission d’un avoir. L’étape est détectée lorsque le statut de l’enregistrement Support Case associé passe à Closed.
Pourquoi est-ce important ? Nécessaire au calcul du délai moyen de résolution des litiges. Des délais de résolution longs ont un effet négatif sur le délai moyen de paiement client et la satisfaction des clients. Où trouver ces données Enregistrement Support Case : champ « dateclosed » des cas associés à la facture. Données à recueillir Comparer la valeur du champ de statut avant et après le changement Type d’événement inferred
	Paiement partiel enregistré	Imputation d’un paiement client qui réduit le solde de la facture sans le régler intégralement. Cette étape est extraite de la table Transaction Line.
Pourquoi est-ce important ? Permet d’analyser le flux de traitement des paiements partiels. Met en évidence les entrées de trésorerie fragmentées et les clients qui rencontrent des difficultés de liquidités. Où trouver ces données Table Transaction : type « CustPymt » imputé à une facture dont le champ « amountremaining » est supérieur à 0. Données à recueillir Enregistré lors de l’exécution de la transaction Payment Type d’événement explicit
	Paiement rapproché du relevé bancaire	Rapprochement de la transaction de paiement avec le flux du relevé bancaire. Cette étape est détectée à partir de « Match Bank Data » ou de l’historique de rapprochement.
Pourquoi est-ce important ? Suit le taux de rapprochement bancaire automatisé. Les retards à cette étape masquent la situation réelle de trésorerie et signalent des difficultés liées aux opérations administratives internes. Où trouver ces données Statut de Transaction : vérifier si le statut de la transaction Payment passe à « Deposited » ou si elle est marquée comme rapprochée. Données à recueillir Comparer la valeur du champ de statut avant et après le changement Type d’événement inferred
	Promesse de paiement reçue	Enregistrement indiquant que le client s’est engagé à payer avant une date donnée. L’information figure généralement dans User Notes ou dans un module spécialisé de gestion du recouvrement.
Pourquoi est-ce important ? Suit l’indicateur de respect des promesses de paiement. Aide à distinguer les clients coopératifs de ceux qui nécessitent une escalade. Où trouver ces données Enregistrement Note : rechercher « PTP » ou « Promise » dans le texte, ou consulter les champs spécifiques d’une Collections SuiteApp. Données à recueillir Déduire l’étape à partir de l’analyse du texte des notes Type d’événement inferred
	Relance de paiement envoyée	Courriel ou lettre de recouvrement généré et envoyé au client au sujet d’un paiement en retard. L’étape est détectée dans les journaux du module Dunning Letters ou dans les enregistrements Message associés à la facture.
Pourquoi est-ce important ? Mesure les efforts nécessaires au recouvrement et l’efficacité des stratégies de relance. Indispensable au Dashboard d’efficacité des relances de paiement. Où trouver ces données Enregistrement Message ou journal Dunning Bundle : rechercher des objets précis, par exemple « Reminder » ou « Overdue ». Données à recueillir Déduire l’étape à partir des schémas d’objet des messages Type d’événement inferred

Recommandé Facultatif

Guides d’extraction

Comment récupérer vos données depuis NetSuite

Étapes

Prérequis : Vérifiez que la fonctionnalité « SuiteAnalytics Workbook » est activée et que vous avez les autorisations nécessaires pour accéder aux transactions, aux notes système, aux messages et aux dossiers d’assistance.
Accéder à SuiteAnalytics : Accédez à Analytics > Workbooks > New Workbook.
Sélectionner l’enregistrement racine : Choisissez Transaction comme type d’enregistrement racine. Il servira de référence pour les données financières.
Stratégie de jeu de données : Comme il faut extraire diverses activités (approbations, messages, litiges) dans un seul journal d’événements reflétant la situation réelle, un jeu de données unique avec jointures dans l’interface produira des lignes très larges (produit cartésien). L’approche recommandée par les spécialistes consiste à utiliser SuiteQL, la fonctionnalité sous-jacente à SuiteAnalytics. Vous pouvez exécuter la requête ci-dessous au moyen de l’interface « SuiteAnalytics Connect » (ODBC/JDBC) ou d’un module « SuiteQL Query Tool » dans l’interface.
Exécuter la requête : Copiez le script SuiteQL complet fourni dans la section « Query ». Remplacez {{LastDataUpdate}} par l’horodatage de l’extraction et {{StartDate}} par la date de début de l’analyse (par exemple, '2023-01-01').
Vérifier les colonnes : Assurez-vous que toutes les colonnes sélectionnées (TranId, Activity, DateCreated, etc.) figurent dans le jeu de résultats.
Exporter les données : Exécutez la requête et exportez les résultats au format CSV.
Mise en forme : Ouvrez le fichier CSV. Vérifiez que la colonne « DateCreated » est au format YYYY-MM-DD HH:MM:SS. La colonne « TotalAmount » doit contenir uniquement des valeurs numériques, sans symbole monétaire.
Validation : Vérifiez qu’un même identifiant de facture (TranId) apparaît plusieurs fois avec différentes valeurs dans « Activité » (par exemple, Created, Approved, Payment Received).
Importation : Importez le fichier CSV dans ProcessMind. Associez « TranId » à « ID de cas », « Activity » à « Nom de l’activité » et « DateCreated » à « Horodatage ».

Configuration

SuiteAnalytics Connect : Cette fonctionnalité doit être activée dans Enable Features > Analytics pour exécuter des requêtes UNION complexes depuis un outil externe.
Autorisations : L’utilisateur doit disposer d’un accès en lecture aux transactions, aux notes système, aux dossiers d’assistance et aux messages.
Filtrage par date : Une période glissante de 12 mois est recommandée. Les extractions historiques volumineuses peuvent expirer. Vérifiez les limites de lignes (NetSuite limite souvent les résultats à 5 000-100 000 lignes selon l’interface ; ODBC est recommandé pour récupérer l’historique complet).
Contexte de filiale : Pour un compte OneWorld, vérifiez que l’utilisateur a accès à toutes les filiales visées ou filtrez sur t.subsidiary.
Performances : La table SystemNote est très volumineuse. Pour de bonnes performances, filtrez impérativement sur recordtype et date.

a Exemple de requête sql

/* SuiteQL Query for Accounts Receivable Process Mining */
/* Combined Event Log Extraction */

/* 1. Invoice Created */
SELECT
  t.tranid AS TranId,
  'Invoice Created' AS Activity,
  TO_CHAR(t.trandate, 'YYYY-MM-DD HH:MI:SS') AS DateCreated,
  t.foreigntotal AS TotalAmount,
  c.entityid AS Entity,
  t.duedate AS DueDate,
  s.name AS Subsidiary,
  emp.entityid AS SalesRep,
  t.status AS Status,
  'NetSuite' AS SourceSystem,
  SYSDATE AS LastDataUpdate
FROM
  Transaction t
  LEFT JOIN Customer c ON t.entity = c.id
  LEFT JOIN Subsidiary s ON t.subsidiary = s.id
  LEFT JOIN Employee emp ON t.salesrep = emp.id
WHERE
  t.type = 'CustInvc'
  AND t.trandate >= TO_DATE('2023-01-01', 'YYYY-MM-DD')

UNION ALL

/* 2. Invoice Approved (via System Notes) */
SELECT
  t.tranid AS TranId,
  'Invoice Approved' AS Activity,
  TO_CHAR(sn.date, 'YYYY-MM-DD HH:MI:SS') AS DateCreated,
  t.foreigntotal AS TotalAmount,
  c.entityid AS Entity,
  t.duedate AS DueDate,
  s.name AS Subsidiary,
  NULL AS SalesRep,
  t.status AS Status,
  'NetSuite' AS SourceSystem,
  SYSDATE AS LastDataUpdate
FROM
  Transaction t
  JOIN SystemNote sn ON sn.recordid = t.id
  LEFT JOIN Customer c ON t.entity = c.id
  LEFT JOIN Subsidiary s ON t.subsidiary = s.id
WHERE
  t.type = 'CustInvc'
  AND sn.recordtypeid = -30 /* Transaction Record Type */
  AND sn.standardfield = 'STATUS'
  AND sn.oldvalue = 'Pending Approval'
  AND sn.newvalue = 'Open'
  AND t.trandate >= TO_DATE('2023-01-01', 'YYYY-MM-DD')

UNION ALL

/* 3. Invoice Dispatched / 4. Payment Reminder (via Messages) */
SELECT
  t.tranid AS TranId,
  CASE 
    WHEN m.subject LIKE '%Reminder%' THEN 'Payment Reminder Sent'
    ELSE 'Invoice Dispatched'
  END AS Activity,
  TO_CHAR(m.messagedate, 'YYYY-MM-DD HH:MI:SS') AS DateCreated,
  t.foreigntotal AS TotalAmount,
  c.entityid AS Entity,
  t.duedate AS DueDate,
  s.name AS Subsidiary,
  NULL AS SalesRep,
  t.status AS Status,
  'NetSuite' AS SourceSystem,
  SYSDATE AS LastDataUpdate
FROM
  Transaction t
  JOIN Message m ON m.transaction = t.id
  LEFT JOIN Customer c ON t.entity = c.id
  LEFT JOIN Subsidiary s ON t.subsidiary = s.id
WHERE
  t.type = 'CustInvc'
  AND (m.subject LIKE '%Invoice%' OR m.subject LIKE '%Reminder%')
  AND t.trandate >= TO_DATE('2023-01-01', 'YYYY-MM-DD')

UNION ALL

/* 5. Dispute Opened / 6. Dispute Resolved (via Support Cases) */
SELECT
  t.tranid AS TranId,
  CASE 
    WHEN sc.status = 'Closed' THEN 'Dispute Resolved'
    ELSE 'Dispute Case Opened'
  END AS Activity,
  TO_CHAR(sc.createddate, 'YYYY-MM-DD HH:MI:SS') AS DateCreated,
  t.foreigntotal AS TotalAmount,
  c.entityid AS Entity,
  t.duedate AS DueDate,
  s.name AS Subsidiary,
  NULL AS SalesRep,
  t.status AS Status,
  'NetSuite' AS SourceSystem,
  SYSDATE AS LastDataUpdate
FROM
  Transaction t
  JOIN SupportCase sc ON sc.custevent_linked_invoice = t.id /* Adjust custom field name */
  LEFT JOIN Customer c ON t.entity = c.id
  LEFT JOIN Subsidiary s ON t.subsidiary = s.id
WHERE
  t.type = 'CustInvc'
  AND t.trandate >= TO_DATE('2023-01-01', 'YYYY-MM-DD')

UNION ALL

/* 7. Promise to Pay (via Notes) */
SELECT
  t.tranid AS TranId,
  'Promise to Pay Received' AS Activity,
  TO_CHAR(n.notedate, 'YYYY-MM-DD HH:MI:SS') AS DateCreated,
  t.foreigntotal AS TotalAmount,
  c.entityid AS Entity,
  t.duedate AS DueDate,
  s.name AS Subsidiary,
  NULL AS SalesRep,
  t.status AS Status,
  'NetSuite' AS SourceSystem,
  SYSDATE AS LastDataUpdate
FROM
  Transaction t
  JOIN Note n ON n.transaction = t.id
  LEFT JOIN Customer c ON t.entity = c.id
  LEFT JOIN Subsidiary s ON t.subsidiary = s.id
WHERE
  t.type = 'CustInvc'
  AND (n.title LIKE '%Promise%' OR n.note LIKE '%Promise%')
  AND t.trandate >= TO_DATE('2023-01-01', 'YYYY-MM-DD')

UNION ALL

/* 8. Credit Memo Issued */
/* Logic: Find Credit Memos applied to the Invoice */
SELECT
  inv.tranid AS TranId,
  'Credit Memo Issued' AS Activity,
  TO_CHAR(cm.trandate, 'YYYY-MM-DD HH:MI:SS') AS DateCreated,
  cm.foreigntotal AS TotalAmount,
  c.entityid AS Entity,
  inv.duedate AS DueDate,
  s.name AS Subsidiary,
  NULL AS SalesRep,
  inv.status AS Status,
  'NetSuite' AS SourceSystem,
  SYSDATE AS LastDataUpdate
FROM
  Transaction inv
  JOIN NextTransactionLineLink ntll ON ntll.previousdoc = inv.id
  JOIN Transaction cm ON ntll.nextdoc = cm.id
  LEFT JOIN Customer c ON inv.entity = c.id
  LEFT JOIN Subsidiary s ON inv.subsidiary = s.id
WHERE
  inv.type = 'CustInvc'
  AND cm.type = 'CustCred'
  AND inv.trandate >= TO_DATE('2023-01-01', 'YYYY-MM-DD')

UNION ALL

/* 9. Partial Payment / 10. Full Payment Received */
SELECT
  inv.tranid AS TranId,
  CASE
    WHEN (inv.foreigntotal - py.foreigntotal) <= 0 THEN 'Full Payment Received'
    ELSE 'Partial Payment Posted'
  END AS Activity,
  TO_CHAR(py.trandate, 'YYYY-MM-DD HH:MI:SS') AS DateCreated,
  py.foreigntotal AS TotalAmount,
  c.entityid AS Entity,
  inv.duedate AS DueDate,
  s.name AS Subsidiary,
  NULL AS SalesRep,
  inv.status AS Status,
  'NetSuite' AS SourceSystem,
  SYSDATE AS LastDataUpdate
FROM
  Transaction inv
  JOIN NextTransactionLineLink ntll ON ntll.previousdoc = inv.id
  JOIN Transaction py ON ntll.nextdoc = py.id
  LEFT JOIN Customer c ON inv.entity = c.id
  LEFT JOIN Subsidiary s ON inv.subsidiary = s.id
WHERE
  inv.type = 'CustInvc'
  AND py.type = 'CustPymt'
  AND inv.trandate >= TO_DATE('2023-01-01', 'YYYY-MM-DD')

UNION ALL

/* 11. Bad Debt Written Off */
SELECT
  t.tranid AS TranId,
  'Bad Debt Written Off' AS Activity,
  TO_CHAR(je.trandate, 'YYYY-MM-DD HH:MI:SS') AS DateCreated,
  t.foreigntotal AS TotalAmount,
  c.entityid AS Entity,
  t.duedate AS DueDate,
  s.name AS Subsidiary,
  NULL AS SalesRep,
  t.status AS Status,
  'NetSuite' AS SourceSystem,
  SYSDATE AS LastDataUpdate
FROM
  Transaction t
  JOIN NextTransactionLineLink ntll ON ntll.previousdoc = t.id
  JOIN Transaction je ON ntll.nextdoc = je.id
  LEFT JOIN Customer c ON t.entity = c.id
  LEFT JOIN Subsidiary s ON t.subsidiary = s.id
WHERE
  t.type = 'CustInvc'
  AND je.type = 'Journal'
  AND (je.memo LIKE '%Bad Debt%' OR je.memo LIKE '%Write Off%')
  AND t.trandate >= TO_DATE('2023-01-01', 'YYYY-MM-DD')

UNION ALL

/* 13. Invoice Cleared */
SELECT
  t.tranid AS TranId,
  'Invoice Cleared' AS Activity,
  TO_CHAR(sn.date, 'YYYY-MM-DD HH:MI:SS') AS DateCreated,
  t.foreigntotal AS TotalAmount,
  c.entityid AS Entity,
  t.duedate AS DueDate,
  s.name AS Subsidiary,
  NULL AS SalesRep,
  'Paid In Full' AS Status,
  'NetSuite' AS SourceSystem,
  SYSDATE AS LastDataUpdate
FROM
  Transaction t
  JOIN SystemNote sn ON sn.recordid = t.id
  LEFT JOIN Customer c ON t.entity = c.id
  LEFT JOIN Subsidiary s ON t.subsidiary = s.id
WHERE
  t.type = 'CustInvc'
  AND sn.standardfield = 'STATUS'
  AND sn.newvalue = 'Paid In Full'
  AND t.trandate >= TO_DATE('2023-01-01', 'YYYY-MM-DD')

Étapes

Prérequis et autorisations : Vérifiez que votre rôle dispose des autorisations « SuiteAnalytics Connect » ou « SuiteQL ». Pour l’authentification par REST, vous aurez besoin d’un identifiant de jeton et d’un secret de jeton valides, ou d’une connexion configurée avec un pilote ODBC.
Comprendre le schéma : Cette extraction s’appuie sur les tables Transaction, TransactionLine, SystemNote, Message, Note et SupportCase. NetSuite conserve l’historique des modifications de champs (comme les changements d’état) dans SystemNote, ce qui est essentiel pour dater les approbations et les changements d’état.
Définir le périmètre : Déterminez la filiale, la période et les types d’enregistrements nécessaires à l’analyse (généralement « CustInvc » pour les factures).
Configurer la requête SuiteQL : La requête fournie utilise UNION ALL pour réunir des données provenant de différentes tables dans un format de journal d’événements unique. SuiteQL ne prend pas en charge les instructions SQL procédurales complexes. La logique est donc répartie en blocs de sélection propres à chaque activité.
Stratégie d’exécution : Exécutez la requête à l’aide de l’API REST NetSuite /services/rest/query/v1/suiteql ou d’ODBC. Comme la table SystemNote peut être volumineuse, il est fortement recommandé d’effectuer l’extraction par lots, en segmentant les données selon trandate (par exemple, mois par mois).
Gestion de la pagination : L’API REST NetSuite limite généralement les réponses à 1 000 lignes. Votre script d’extraction doit gérer les décalages ou parcourir les en-têtes « Link » pour récupérer l’ensemble des données.
Transformation des données : La requête aligne tous les résultats sur un schéma standard (TranId, Activity, Date, etc.). Si la sortie SQL brute utilise un autre format régional, veillez à exporter les dates au format ISO 8601 (YYYY-MM-DD THH:MM:SS).
Logique des litiges et du recouvrement : La requête recherche les enregistrements SupportCase associés au client et les enregistrements Note correspondant à une promesse de paiement. Vérifiez si votre organisation utilise des champs personnalisés plutôt que les objets standard pour ces indicateurs, et adaptez les clauses WHERE en conséquence.
Validation : Comparez le nombre de factures créées dans le fichier extrait avec celui d’une recherche enregistrée dans NetSuite pour la même période, afin de vérifier que les données sont complètes.
Export final : Enregistrez le jeu de données obtenu dans un fichier CSV. Avant de l’importer dans ProcessMind, vérifiez que les en-têtes correspondent à la liste « Attributs à inclure » (TranId, Activity, DateCreated, etc.).

Configuration

Période : Filtrez sur trandate dans la table Transaction et sur date dans SystemNote. Pour les processus actifs, une période glissante de 12 mois est recommandée.
Filtre de filiale : Indispensable dans les environnements comportant plusieurs filiales. Ajoutez AND t.subsidiary = [Your Subsidiary ID] à toutes les clauses WHERE.
Types d’enregistrements : La requête porte sur CustInvc (facture), CustPymt (paiement), CustCred (avoir) et Journal.
Notes système : Cette table est très volumineuse. Pour de bonnes performances, filtrez impérativement sur recordtype = 'invoice'.
Association des états : Les états NetSuite sont des identifiants internes (par exemple, « A », « B »). La requête utilise BUILTIN.DF pour récupérer les noms affichés. Vérifiez qu’ils correspondent aux libellés de votre interface localisée.
Stratégie de jointure : La requête utilise des jointures standard sur transaction.id. Vérifiez que les liens « Applied To » sont conservés pour l’historique des paiements.

a Exemple de requête sql

/* 1. Invoice Created */
SELECT
  t.tranid AS TranId,
  'Invoice Created' AS Activity,
  TO_CHAR(t.createddate, 'YYYY-MM-DD HH24:MI:SS') AS DateCreated,
  'NetSuite' AS SourceSystem,
  TO_CHAR(SYSDATE, 'YYYY-MM-DD HH24:MI:SS') AS LastDataUpdate,
  t.foreigntotal AS TotalAmount,
  BUILTIN.DF(t.entity) AS Entity,
  TO_CHAR(t.duedate, 'YYYY-MM-DD') AS DueDate,
  BUILTIN.DF(t.subsidiary) AS Subsidiary,
  BUILTIN.DF(t.salesrep) AS SalesRep,
  BUILTIN.DF(t.status) AS Status,
  BUILTIN.DF(t.department) AS Department
FROM
  Transaction t
WHERE
  t.recordtype = 'invoice'
  AND t.trandate >= TO_DATE('2023-01-01', 'YYYY-MM-DD')

UNION ALL

/* 2. Invoice Approved (Detected via SystemNote status change to Open) */
SELECT
  t.tranid AS TranId,
  'Invoice Approved' AS Activity,
  TO_CHAR(sn.date, 'YYYY-MM-DD HH24:MI:SS') AS DateCreated,
  'NetSuite' AS SourceSystem,
  TO_CHAR(SYSDATE, 'YYYY-MM-DD HH24:MI:SS') AS LastDataUpdate,
  t.foreigntotal AS TotalAmount,
  BUILTIN.DF(t.entity) AS Entity,
  TO_CHAR(t.duedate, 'YYYY-MM-DD') AS DueDate,
  BUILTIN.DF(t.subsidiary) AS Subsidiary,
  BUILTIN.DF(t.salesrep) AS SalesRep,
  BUILTIN.DF(t.status) AS Status,
  BUILTIN.DF(t.department) AS Department
FROM
  Transaction t
  JOIN SystemNote sn ON sn.recordid = t.id
WHERE
  t.recordtype = 'invoice'
  AND sn.recordtypeid = -30 /* Invoice Record Type ID */
  AND sn.field = 'status'
  AND (sn.after LIKE '%Open%')
  AND t.trandate >= TO_DATE('2023-01-01', 'YYYY-MM-DD')

UNION ALL

/* 3. Invoice Dispatched (Email Sent) */
SELECT
  t.tranid AS TranId,
  'Invoice Dispatched' AS Activity,
  TO_CHAR(m.messagedate, 'YYYY-MM-DD HH24:MI:SS') AS DateCreated,
  'NetSuite' AS SourceSystem,
  TO_CHAR(SYSDATE, 'YYYY-MM-DD HH24:MI:SS') AS LastDataUpdate,
  t.foreigntotal AS TotalAmount,
  BUILTIN.DF(t.entity) AS Entity,
  TO_CHAR(t.duedate, 'YYYY-MM-DD') AS DueDate,
  BUILTIN.DF(t.subsidiary) AS Subsidiary,
  BUILTIN.DF(t.salesrep) AS SalesRep,
  BUILTIN.DF(t.status) AS Status,
  BUILTIN.DF(t.department) AS Department
FROM
  Transaction t
  JOIN Message m ON m.transaction = t.id
WHERE
  t.recordtype = 'invoice'
  AND m.subject LIKE '%Invoice%'
  AND t.trandate >= TO_DATE('2023-01-01', 'YYYY-MM-DD')

UNION ALL

/* 4. Payment Reminder Sent */
SELECT
  t.tranid AS TranId,
  'Payment Reminder Sent' AS Activity,
  TO_CHAR(m.messagedate, 'YYYY-MM-DD HH24:MI:SS') AS DateCreated,
  'NetSuite' AS SourceSystem,
  TO_CHAR(SYSDATE, 'YYYY-MM-DD HH24:MI:SS') AS LastDataUpdate,
  t.foreigntotal AS TotalAmount,
  BUILTIN.DF(t.entity) AS Entity,
  TO_CHAR(t.duedate, 'YYYY-MM-DD') AS DueDate,
  BUILTIN.DF(t.subsidiary) AS Subsidiary,
  BUILTIN.DF(t.salesrep) AS SalesRep,
  BUILTIN.DF(t.status) AS Status,
  BUILTIN.DF(t.department) AS Department
FROM
  Transaction t
  JOIN Message m ON m.transaction = t.id
WHERE
  t.recordtype = 'invoice'
  AND (m.subject LIKE '%Reminder%' OR m.subject LIKE '%Overdue%')
  AND t.trandate >= TO_DATE('2023-01-01', 'YYYY-MM-DD')

UNION ALL

/* 5. Dispute Case Opened (Linked Support Case) */
SELECT
  t.tranid AS TranId,
  'Dispute Case Opened' AS Activity,
  TO_CHAR(sc.createddate, 'YYYY-MM-DD HH24:MI:SS') AS DateCreated,
  'NetSuite' AS SourceSystem,
  TO_CHAR(SYSDATE, 'YYYY-MM-DD HH24:MI:SS') AS LastDataUpdate,
  t.foreigntotal AS TotalAmount,
  BUILTIN.DF(t.entity) AS Entity,
  TO_CHAR(t.duedate, 'YYYY-MM-DD') AS DueDate,
  BUILTIN.DF(t.subsidiary) AS Subsidiary,
  BUILTIN.DF(t.salesrep) AS SalesRep,
  BUILTIN.DF(t.status) AS Status,
  BUILTIN.DF(t.department) AS Department
FROM
  Transaction t
  JOIN SupportCase sc ON sc.company = t.entity
WHERE
  t.recordtype = 'invoice'
  AND sc.title LIKE '%Invoice%'
  AND sc.createddate >= t.createddate
  AND t.trandate >= TO_DATE('2023-01-01', 'YYYY-MM-DD')

UNION ALL

/* 6. Dispute Resolved */
SELECT
  t.tranid AS TranId,
  'Dispute Resolved' AS Activity,
  TO_CHAR(sc.lastmodifieddate, 'YYYY-MM-DD HH24:MI:SS') AS DateCreated,
  'NetSuite' AS SourceSystem,
  TO_CHAR(SYSDATE, 'YYYY-MM-DD HH24:MI:SS') AS LastDataUpdate,
  t.foreigntotal AS TotalAmount,
  BUILTIN.DF(t.entity) AS Entity,
  TO_CHAR(t.duedate, 'YYYY-MM-DD') AS DueDate,
  BUILTIN.DF(t.subsidiary) AS Subsidiary,
  BUILTIN.DF(t.salesrep) AS SalesRep,
  BUILTIN.DF(t.status) AS Status,
  BUILTIN.DF(t.department) AS Department
FROM
  Transaction t
  JOIN SupportCase sc ON sc.company = t.entity
WHERE
  t.recordtype = 'invoice'
  AND sc.status = 'Closed'
  AND sc.title LIKE '%Invoice%'
  AND t.trandate >= TO_DATE('2023-01-01', 'YYYY-MM-DD')

UNION ALL

/* 7. Promise to Pay Received */
SELECT
  t.tranid AS TranId,
  'Promise to Pay Received' AS Activity,
  TO_CHAR(n.notedate, 'YYYY-MM-DD HH24:MI:SS') AS DateCreated,
  'NetSuite' AS SourceSystem,
  TO_CHAR(SYSDATE, 'YYYY-MM-DD HH24:MI:SS') AS LastDataUpdate,
  t.foreigntotal AS TotalAmount,
  BUILTIN.DF(t.entity) AS Entity,
  TO_CHAR(t.duedate, 'YYYY-MM-DD') AS DueDate,
  BUILTIN.DF(t.subsidiary) AS Subsidiary,
  BUILTIN.DF(t.salesrep) AS SalesRep,
  BUILTIN.DF(t.status) AS Status,
  BUILTIN.DF(t.department) AS Department
FROM
  Transaction t
  JOIN Note n ON n.transaction = t.id
WHERE
  t.recordtype = 'invoice'
  AND (n.note LIKE '%Promise to Pay%' OR n.note LIKE '%PTP%')
  AND t.trandate >= TO_DATE('2023-01-01', 'YYYY-MM-DD')

UNION ALL

/* 8. Credit Memo Issued */
SELECT
  t.tranid AS TranId,
  'Credit Memo Issued' AS Activity,
  TO_CHAR(link_t.createddate, 'YYYY-MM-DD HH24:MI:SS') AS DateCreated,
  'NetSuite' AS SourceSystem,
  TO_CHAR(SYSDATE, 'YYYY-MM-DD HH24:MI:SS') AS LastDataUpdate,
  t.foreigntotal AS TotalAmount,
  BUILTIN.DF(t.entity) AS Entity,
  TO_CHAR(t.duedate, 'YYYY-MM-DD') AS DueDate,
  BUILTIN.DF(t.subsidiary) AS Subsidiary,
  BUILTIN.DF(t.salesrep) AS SalesRep,
  BUILTIN.DF(t.status) AS Status,
  BUILTIN.DF(t.department) AS Department
FROM
  Transaction t
  JOIN TransactionLine tl ON tl.doc = t.id
  JOIN Transaction link_t ON link_t.id = tl.transaction
WHERE
  t.recordtype = 'invoice'
  AND link_t.recordtype = 'creditmemo'
  AND t.trandate >= TO_DATE('2023-01-01', 'YYYY-MM-DD')

UNION ALL

/* 9. Partial Payment Posted */
SELECT
  t.tranid AS TranId,
  'Partial Payment Posted' AS Activity,
  TO_CHAR(link_t.createddate, 'YYYY-MM-DD HH24:MI:SS') AS DateCreated,
  'NetSuite' AS SourceSystem,
  TO_CHAR(SYSDATE, 'YYYY-MM-DD HH24:MI:SS') AS LastDataUpdate,
  t.foreigntotal AS TotalAmount,
  BUILTIN.DF(t.entity) AS Entity,
  TO_CHAR(t.duedate, 'YYYY-MM-DD') AS DueDate,
  BUILTIN.DF(t.subsidiary) AS Subsidiary,
  BUILTIN.DF(t.salesrep) AS SalesRep,
  BUILTIN.DF(t.status) AS Status,
  BUILTIN.DF(t.department) AS Department
FROM
  Transaction t
  JOIN TransactionLine tl ON tl.doc = t.id
  JOIN Transaction link_t ON link_t.id = tl.transaction
WHERE
  t.recordtype = 'invoice'
  AND link_t.recordtype = 'customerpayment'
  AND ABS(tl.foreignamount) < t.foreigntotal
  AND t.trandate >= TO_DATE('2023-01-01', 'YYYY-MM-DD')

UNION ALL

/* 10. Full Payment Received */
SELECT
  t.tranid AS TranId,
  'Full Payment Received' AS Activity,
  TO_CHAR(link_t.createddate, 'YYYY-MM-DD HH24:MI:SS') AS DateCreated,
  'NetSuite' AS SourceSystem,
  TO_CHAR(SYSDATE, 'YYYY-MM-DD HH24:MI:SS') AS LastDataUpdate,
  t.foreigntotal AS TotalAmount,
  BUILTIN.DF(t.entity) AS Entity,
  TO_CHAR(t.duedate, 'YYYY-MM-DD') AS DueDate,
  BUILTIN.DF(t.subsidiary) AS Subsidiary,
  BUILTIN.DF(t.salesrep) AS SalesRep,
  BUILTIN.DF(t.status) AS Status,
  BUILTIN.DF(t.department) AS Department
FROM
  Transaction t
  JOIN TransactionLine tl ON tl.doc = t.id
  JOIN Transaction link_t ON link_t.id = tl.transaction
WHERE
  t.recordtype = 'invoice'
  AND link_t.recordtype = 'customerpayment'
  AND ABS(tl.foreignamount) >= (t.foreigntotal - 1.00) /* Approx check for full payment allowing small variance */
  AND t.trandate >= TO_DATE('2023-01-01', 'YYYY-MM-DD')

UNION ALL

/* 11. Bad Debt Written Off */
SELECT
  t.tranid AS TranId,
  'Bad Debt Written Off' AS Activity,
  TO_CHAR(link_t.createddate, 'YYYY-MM-DD HH24:MI:SS') AS DateCreated,
  'NetSuite' AS SourceSystem,
  TO_CHAR(SYSDATE, 'YYYY-MM-DD HH24:MI:SS') AS LastDataUpdate,
  t.foreigntotal AS TotalAmount,
  BUILTIN.DF(t.entity) AS Entity,
  TO_CHAR(t.duedate, 'YYYY-MM-DD') AS DueDate,
  BUILTIN.DF(t.subsidiary) AS Subsidiary,
  BUILTIN.DF(t.salesrep) AS SalesRep,
  BUILTIN.DF(t.status) AS Status,
  BUILTIN.DF(t.department) AS Department
FROM
  Transaction t
  JOIN TransactionLine tl ON tl.doc = t.id
  JOIN Transaction link_t ON link_t.id = tl.transaction
WHERE
  t.recordtype = 'invoice'
  AND link_t.recordtype = 'journalentry'
  AND (link_t.memo LIKE '%Write off%' OR link_t.memo LIKE '%Bad Debt%')
  AND t.trandate >= TO_DATE('2023-01-01', 'YYYY-MM-DD')

UNION ALL

/* 12. Bank Statement Matched (via Payment Status) */
SELECT
  t.tranid AS TranId,
  'Bank Statement Matched' AS Activity,
  TO_CHAR(sn.date, 'YYYY-MM-DD HH24:MI:SS') AS DateCreated,
  'NetSuite' AS SourceSystem,
  TO_CHAR(SYSDATE, 'YYYY-MM-DD HH24:MI:SS') AS LastDataUpdate,
  t.foreigntotal AS TotalAmount,
  BUILTIN.DF(t.entity) AS Entity,
  TO_CHAR(t.duedate, 'YYYY-MM-DD') AS DueDate,
  BUILTIN.DF(t.subsidiary) AS Subsidiary,
  BUILTIN.DF(t.salesrep) AS SalesRep,
  BUILTIN.DF(t.status) AS Status,
  BUILTIN.DF(t.department) AS Department
FROM
  Transaction t
  JOIN TransactionLine tl ON tl.doc = t.id
  JOIN Transaction link_t ON link_t.id = tl.transaction
  JOIN SystemNote sn ON sn.recordid = link_t.id
WHERE
  t.recordtype = 'invoice'
  AND link_t.recordtype = 'customerpayment'
  AND sn.field = 'status'
  AND sn.after LIKE '%Deposited%'
  AND t.trandate >= TO_DATE('2023-01-01', 'YYYY-MM-DD')

UNION ALL

/* 13. Invoice Cleared (Final Status) */
SELECT
  t.tranid AS TranId,
  'Invoice Cleared' AS Activity,
  TO_CHAR(sn.date, 'YYYY-MM-DD HH24:MI:SS') AS DateCreated,
  'NetSuite' AS SourceSystem,
  TO_CHAR(SYSDATE, 'YYYY-MM-DD HH24:MI:SS') AS LastDataUpdate,
  t.foreigntotal AS TotalAmount,
  BUILTIN.DF(t.entity) AS Entity,
  TO_CHAR(t.duedate, 'YYYY-MM-DD') AS DueDate,
  BUILTIN.DF(t.subsidiary) AS Subsidiary,
  BUILTIN.DF(t.salesrep) AS SalesRep,
  BUILTIN.DF(t.status) AS Status,
  BUILTIN.DF(t.department) AS Department
FROM
  Transaction t
  JOIN SystemNote sn ON sn.recordid = t.id
WHERE
  t.recordtype = 'invoice'
  AND sn.recordtypeid = -30
  AND sn.field = 'status'
  AND (sn.after LIKE '%Paid In Full%')
  AND t.trandate >= TO_DATE('2023-01-01', 'YYYY-MM-DD')

Étapes

Prérequis et configuration des autorisations Vérifiez que vous disposez d’un accès administrateur au compte NetSuite. Accédez à Setup, Company, Enable Features. Dans l’onglet SuiteTalk, vérifiez que « REST Web Services » est activé. Accédez à Setup, Integration, Manage Integrations, puis créez une intégration nommée « ProcessMining_Extractor ». Activez « Token-based Authentication » et décochez « TBA : Authorization Flow » si vous utilisez la génération standard de jetons. Notez la clé consommateur et le secret consommateur.
Générer les jetons d’accès Accédez à Manage Access Tokens. Créez un jeton pour le rôle Administrator (ou pour un rôle spécifique disposant des autorisations nécessaires sur les transactions, les notes système et les listes). Copiez l’identifiant et le secret du jeton. Vous disposez alors des quatre clés requises pour OAuth 1.0a.
Préparer l’environnement Python Vérifiez que Python 3.x est installé. Installez les bibliothèques nécessaires avec pip : pip install requests requests-oauthlib pandas. Elles permettent de gérer l’échange OAuth 1.0a et le traitement des données.
Configurer les paramètres du script Ouvrez le script Python fourni. Remplacez les valeurs fictives de ACCOUNT_ID, CONSUMER_KEY, CONSUMER_SECRET, TOKEN_ID et TOKEN_SECRET par vos identifiants. Définissez TARGET_START_DATE en fonction de la période historique souhaitée (par exemple, '2023-01-01').
Comprendre la stratégie d’API Le script utilise le point de terminaison de l’API REST NetSuite /query/v1/suiteql. Il est possible de parcourir les enregistrements un par un, mais SuiteQL via l’API REST est nettement plus performant pour le Process Mining : cette méthode permet de joindre les tables Transaction, TransactionLine, Message et SystemNote en réduisant le nombre de requêtes HTTP.
Exécuter le script d’extraction Lancez le script depuis votre terminal ou votre IDE. Il effectue cinq extractions distinctes : le flux principal des factures, les paiements, les avoirs, les journaux de communication (messages) et les changements d’état du système (piste d’audit).
Suivre l’exécution Le script affiche la progression dans la console et indique le nombre d’enregistrements récupérés pour chaque type d’activité. Surveillez les erreurs HTTP 400 ou 500, qui signalent généralement un problème d’autorisation ou une syntaxe SuiteQL incorrecte.
Transformer et fusionner les données Le script transforme automatiquement les données. Il convertit le format de date propre à NetSuite en horodatage ISO 8601. Il normalise également les noms de champs, par exemple tranid en « ID de cas », et associe les types de transactions aux noms d’activité normalisés définis dans les exigences.
Appliquer les traitements après extraction Le script distingue « Paiement partiel comptabilisé » de « Paiement intégral reçu » en comparant le montant du paiement imputé au montant total de la facture d’origine. Il déduit également l’événement « Facture soldée » à partir du changement d’état final.
Vérifier le fichier de sortie Une fois l’extraction terminée, le script génère un fichier nommé netsuite_ar_event_log.csv. Ouvrez-le et examinez les premières lignes. Vérifiez que TranId est renseigné et que DateCreated respecte le format attendu.
Importer dans ProcessMind Le fichier CSV généré est formaté pour ProcessMind. Associez TranId à « ID de cas », Activity à « Activité » et DateCreated à « Horodatage ». Associez « Montant » et « État » aux attributs du cas.

Configuration

Méthode d’authentification : OAuth 1.0a (authentification par jeton). Il s’agit de la norme obligatoire pour sécuriser l’API REST NetSuite.
Point de terminaison de l’API : https://[AccountID].suitetalk.api.netsuite.com/services/rest/query/v1/suiteql. Le point de terminaison SuiteQL s’inscrit dans l’architecture REST et permet de filtrer et de joindre des notes système de manière avancée.
Gestion de la concurrence : NetSuite applique des limites de concurrence selon votre niveau de service (généralement de 5 à 20 threads simultanés). Ce script s’exécute sur un seul thread afin d’éviter les erreurs « 429 Too Many Requests ».
Format des dates : NetSuite permet de personnaliser les formats de date. Le script suppose que le format utilisé est le format ISO standard ou le format américain standard. Vous devrez peut-être adapter l’analyse des dates si votre instance utilise le format jour/mois/année.
Limites des requêtes : SuiteQL renvoie au maximum 1 000 lignes par page. Le script utilise une boucle while pour gérer les indicateurs hasMore et les décalages ou plages nécessaires à la pagination des grands jeux de données.
Autorisations requises : Le rôle utilisateur doit disposer d’autorisations de lecture pour les factures, les paiements clients, les avoirs, les écritures de journal, les dossiers d’assistance, les messages et les notes système.

a Exemple de requête python

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

class=class="hl-string">"hl-comment"># === CONFIGURATION ===
class=class="hl-string">"hl-comment"># Replace these with your actual NetSuite credentials
ACCOUNT_ID = class="hl-string">'123456_SB1'  class=class="hl-string">"hl-comment"># Use hyphens for sandbox, e.g., 123456-sb1
CONSUMER_KEY = class="hl-string">'your_consumer_key'
CONSUMER_SECRET = class="hl-string">'your_consumer_secret'
TOKEN_ID = class="hl-string">'your_token_id'
TOKEN_SECRET = class="hl-string">'your_token_secret'
TARGET_START_DATE = class="hl-string">'2023-01-01'

class=class="hl-string">"hl-comment"># NetSuite REST API Base URL (Format account ID correctly for URL)
class=class="hl-string">"hl-comment"># For URL, usually lowercase and hyphens: 123456-sb1
NS_ACCOUNT_URL_PART = ACCOUNT_ID.lower().replace(class="hl-string">'_', class="hl-string">'-')
BASE_URL = fclass="hl-string">'https://{NS_ACCOUNT_URL_PART}.suitetalk.api.netsuite.com/services/rest/query/v1/suiteql'

class=class="hl-string">"hl-comment"># Authentication
auth = OAuth1(CONSUMER_KEY, CONSUMER_SECRET, TOKEN_ID, TOKEN_SECRET, realm=ACCOUNT_ID)
headers = {
    class="hl-string">'Prefer': class="hl-string">'transient',
    class="hl-string">'Content-Type': class="hl-string">'application/json'
}

class=class="hl-string">"hl-comment"># === HELPER FUNCTION ===
def run_suiteql(query):
    all_rows = []
    offset = 0
    limit = 1000
    has_more = True
    
    print(fclass="hl-string">"Executing Query starting with: {query[:50]}...")
    
    while has_more:
        class=class="hl-string">"hl-comment"># Note: Pagination in SuiteQL via REST often involves ROWNUM logic or limits
        class=class="hl-string">"hl-comment"># Standard REST paging links are preferred, but for SuiteQL body, we iterate logic
        class=class="hl-string">"hl-comment"># For simplicity in this script, we assume the query returns < 100k or we would implement ID-based iteration.
        class=class="hl-string">"hl-comment"># Ideally, we inject LIMIT/OFFSET if supported or filter by ID ranges.
        class=class="hl-string">"hl-comment"># Here we use a robust wrapper handling the class="hl-string">'items' response.
        
        class=class="hl-string">"hl-comment"># Adjust query for paging if necessary, or rely on requests if result set is small.
        class=class="hl-string">"hl-comment"># For production large scale, add class="hl-string">'AND rownum between X and Y' logic.
        
        payload = {class="hl-string">"q": query}
        response = requests.post(BASE_URL, auth=auth, headers=headers, json=payload)
        
        if response.status_code == 200:
            data = response.json()
            items = data.get(class="hl-string">'items', [])
            all_rows.extend(items)
            
            class=class="hl-string">"hl-comment"># Check for generic SuiteTalk pagination links
            if len(items) < limit:
                has_more = False
            else:
                class=class="hl-string">"hl-comment"># In strict SuiteQL, you must handle offset manually in SQL
                class=class="hl-string">"hl-comment"># For this script, we assume strict date filtering keeps batches manageable
                has_more = False class=class="hl-string">"hl-comment"># Preventing infinite loop in this demo template
        else:
            print(fclass="hl-string">"Error {response.status_code}: {response.text}")
            has_more = False
            
    return all_rows

class=class="hl-string">"hl-comment"># === EXTRACTION LOGIC ===

events = []

class=class="hl-string">"hl-comment"># 1. INVOICES (Created, Due Date, Attributes)
print(class="hl-string">"Extracting Invoices...")
q_invoices = fclass="hl-string">"""
    SELECT 
        t.tranid,
        'Invoice Created' as activity,
        TO_CHAR(t.trandate, 'YYYY-MM-DD HH24:MI:SS') as event_time,
        t.foreignTotal as amount,
        e.entityid as customer,
        t.duedate,
        s.name as subsidiary,
        emp.entityid as salesrep,
        t.status,
        d.name as department
    FROM 
        transaction t
        LEFT JOIN entity e ON t.entity = e.id
        LEFT JOIN subsidiary s ON t.subsidiary = s.id
        LEFT JOIN employee emp ON t.salesrep = emp.id
        LEFT JOIN department d ON t.department = d.id
    WHERE 
        t.recordtype = 'invoice'
        AND t.trandate >= TO_DATE('{TARGET_START_DATE}', 'YYYY-MM-DD')
"""
invoices = run_suiteql(q_invoices)
for row in invoices:
    events.append({
        class="hl-string">'TranId': row.get(class="hl-string">'tranid'),
        class="hl-string">'Activity': row.get(class="hl-string">'activity'),
        class="hl-string">'DateCreated': row.get(class="hl-string">'event_time'),
        class="hl-string">'TotalAmount': row.get(class="hl-string">'amount'),
        class="hl-string">'Entity': row.get(class="hl-string">'customer'),
        class="hl-string">'DueDate': row.get(class="hl-string">'duedate'),
        class="hl-string">'Subsidiary': row.get(class="hl-string">'subsidiary'),
        class="hl-string">'SalesRep': row.get(class="hl-string">'salesrep'),
        class="hl-string">'Status': row.get(class="hl-string">'status'),
        class="hl-string">'Department': row.get(class="hl-string">'department'),
        class="hl-string">'SourceSystem': class="hl-string">'NetSuite'
    })

class=class="hl-string">"hl-comment"># 2. PAYMENTS (Partial, Full, Bank Match)
print(class="hl-string">"Extracting Payments...")
q_payments = fclass="hl-string">"""
    SELECT 
        inv.tranid as invoice_num,
        t.tranid as payment_ref,
        TO_CHAR(t.trandate, 'YYYY-MM-DD HH24:MI:SS') as event_time,
        tl.foreignAmount as payment_amt,
        inv.foreignTotal as invoice_total,
        t.status as payment_status
    FROM 
        transaction t
        JOIN transactionLine tl ON t.id = tl.transaction
        JOIN transaction inv ON tl.createdfrom = inv.id
    WHERE 
        t.recordtype = 'customerpayment'
        AND inv.recordtype = 'invoice'
        AND t.trandate >= TO_DATE('{TARGET_START_DATE}', 'YYYY-MM-DD')
"""
payments = run_suiteql(q_payments)
for row in payments:
    class=class="hl-string">"hl-comment"># Logic to distinguish Partial vs Full
    act = class="hl-string">'Partial Payment Posted'
    class=class="hl-string">"hl-comment"># Simple heuristic: if remaining amount is small or payment equals total
    class=class="hl-string">"hl-comment"># In a real scenario, we would check class="hl-string">'amountremaining' on the invoice
    try:
        if float(row.get(class="hl-string">'payment_amt', 0)) >= float(row.get(class="hl-string">'invoice_total', 0)):
            act = class="hl-string">'Full Payment Received'
    except:
        pass
        
    events.append({
        class="hl-string">'TranId': row.get(class="hl-string">'invoice_num'),
        class="hl-string">'Activity': act,
        class="hl-string">'DateCreated': row.get(class="hl-string">'event_time'),
        class="hl-string">'SourceSystem': class="hl-string">'NetSuite'
    })
    
    class=class="hl-string">"hl-comment"># Bank Match / Cleared Check
    class=class="hl-string">"hl-comment"># Assuming class="hl-string">'deposited' status or similar indicates bank matching
    if row.get(class="hl-string">'payment_status') == class="hl-string">'deposited':
        events.append({
            class="hl-string">'TranId': row.get(class="hl-string">'invoice_num'),
            class="hl-string">'Activity': class="hl-string">'Bank Statement Matched',
            class="hl-string">'DateCreated': row.get(class="hl-string">'event_time'), class=class="hl-string">"hl-comment"># Using payment date as proxy if match date unavailable
            class="hl-string">'SourceSystem': class="hl-string">'NetSuite'
        })

class=class="hl-string">"hl-comment"># 3. CREDIT MEMOS & BAD DEBT
print(class="hl-string">"Extracting Credit Memos...")
q_credits = fclass="hl-string">"""
    SELECT 
        inv.tranid as invoice_num,
        t.tranid as credit_ref,
        t.recordtype,
        TO_CHAR(t.trandate, 'YYYY-MM-DD HH24:MI:SS') as event_time,
        t.memo
    FROM 
        transaction t
        JOIN transactionLine tl ON t.id = tl.transaction
        JOIN transaction inv ON tl.createdfrom = inv.id
    WHERE 
        t.recordtype IN ('creditmemo', 'journalentry')
        AND inv.recordtype = 'invoice'
        AND t.trandate >= TO_DATE('{TARGET_START_DATE}', 'YYYY-MM-DD')
"""
credits = run_suiteql(q_credits)
for row in credits:
    act = class="hl-string">'Credit Memo Issued'
    if class="hl-string">'write off' in str(row.get(class="hl-string">'memo')).lower() or class="hl-string">'bad debt' in str(row.get(class="hl-string">'memo')).lower():
        act = class="hl-string">'Bad Debt Written Off'
        
    events.append({
        class="hl-string">'TranId': row.get(class="hl-string">'invoice_num'),
        class="hl-string">'Activity': act,
        class="hl-string">'DateCreated': row.get(class="hl-string">'event_time'),
        class="hl-string">'SourceSystem': class="hl-string">'NetSuite'
    })

class=class="hl-string">"hl-comment"># 4. MESSAGES (Dispatch, Reminders)
print(class="hl-string">"Extracting Messages...")
q_msgs = fclass="hl-string">"""
    SELECT 
        t.tranid as invoice_num,
        m.subject,
        TO_CHAR(m.messagedate, 'YYYY-MM-DD HH24:MI:SS') as event_time,
        m.authoremail
    FROM 
        message m
        JOIN transaction t ON m.transaction = t.id
    WHERE 
        t.recordtype = 'invoice'
        AND m.messagedate >= TO_DATE('{TARGET_START_DATE}', 'YYYY-MM-DD')
"""
msgs = run_suiteql(q_msgs)
for row in msgs:
    subj = str(row.get(class="hl-string">'subject')).lower()
    act = None
    if class="hl-string">'invoice' in subj and class="hl-string">'attached' in subj:
        act = class="hl-string">'Invoice Dispatched'
    elif class="hl-string">'reminder' in subj or class="hl-string">'overdue' in subj:
        act = class="hl-string">'Payment Reminder Sent'
        
    if act:
        events.append({
            class="hl-string">'TranId': row.get(class="hl-string">'invoice_num'),
            class="hl-string">'Activity': act,
            class="hl-string">'DateCreated': row.get(class="hl-string">'event_time'),
            class="hl-string">'SourceSystem': class="hl-string">'NetSuite'
        })

class=class="hl-string">"hl-comment"># 5. SUPPORT CASES (Disputes)
print(class="hl-string">"Extracting Support Cases...")
class=class="hl-string">"hl-comment"># Requires linking Case to Invoice (often custom field or text match)
class=class="hl-string">"hl-comment"># Here assuming generic link via Customer + Time logic or direct field if exists
class=class="hl-string">"hl-comment"># Using standard support case table
q_cases = fclass="hl-string">"""
    SELECT 
        c.casenumber,
        c.title,
        c.status,
        TO_CHAR(c.createddate, 'YYYY-MM-DD HH24:MI:SS') as create_time,
        TO_CHAR(c.lastmodifieddate, 'YYYY-MM-DD HH24:MI:SS') as close_time,
        t.tranid as invoice_num
    FROM 
        supportcase c
        JOIN transaction t ON c.company = t.entity -- Loose join by customer
    WHERE 
        t.recordtype = 'invoice'
        AND (c.title LIKE '%' || t.tranid || '%' OR c.incomingmessage LIKE '%' || t.tranid || '%')
        AND c.createddate >= TO_DATE('{TARGET_START_DATE}', 'YYYY-MM-DD')
"""
cases = run_suiteql(q_cases)
for row in cases:
    class=class="hl-string">"hl-comment"># Dispute Opened
    events.append({
        class="hl-string">'TranId': row.get(class="hl-string">'invoice_num'),
        class="hl-string">'Activity': class="hl-string">'Dispute Case Opened',
        class="hl-string">'DateCreated': row.get(class="hl-string">'create_time'),
        class="hl-string">'SourceSystem': class="hl-string">'NetSuite'
    })
    class=class="hl-string">"hl-comment"># Dispute Resolved (if closed)
    if class="hl-string">'closed' in str(row.get(class="hl-string">'status')).lower():
        events.append({
            class="hl-string">'TranId': row.get(class="hl-string">'invoice_num'),
            class="hl-string">'Activity': class="hl-string">'Dispute Resolved',
            class="hl-string">'DateCreated': row.get(class="hl-string">'close_time'),
            class="hl-string">'SourceSystem': class="hl-string">'NetSuite'
        })

class=class="hl-string">"hl-comment"># 6. SYSTEM NOTES (Approvals, Status Changes, Cleared)
print(class="hl-string">"Extracting System Notes...")
class=class="hl-string">"hl-comment"># This query can be heavy. Ensure proper filtering.
q_notes = fclass="hl-string">"""
    SELECT 
        t.tranid as invoice_num,
        sn.field,
        sn.oldvalue,
        sn.newvalue,
        TO_CHAR(sn.date, 'YYYY-MM-DD HH24:MI:SS') as event_time
    FROM 
        systemnote sn
        JOIN transaction t ON sn.recordid = t.id
    WHERE 
        sn.recordtypeid = -30 -- Transaction Record Type ID usually -30, verify in setup
        AND t.recordtype = 'invoice'
        AND sn.date >= TO_DATE('{TARGET_START_DATE}', 'YYYY-MM-DD')
"""
notes = run_suiteql(q_notes)
for row in notes:
    field = str(row.get(class="hl-string">'field')).lower()
    old_v = str(row.get(class="hl-string">'oldvalue')).lower()
    new_v = str(row.get(class="hl-string">'newvalue')).lower()
    
    if class="hl-string">'status' in field:
        if class="hl-string">'pending approval' in old_v and class="hl-string">'open' in new_v:
            events.append({class="hl-string">'TranId': row.get(class="hl-string">'invoice_num'), class="hl-string">'Activity': class="hl-string">'Invoice Approved', class="hl-string">'DateCreated': row.get(class="hl-string">'event_time'), class="hl-string">'SourceSystem': class="hl-string">'NetSuite'})
        elif class="hl-string">'paid in full' in new_v:
            events.append({class="hl-string">'TranId': row.get(class="hl-string">'invoice_num'), class="hl-string">'Activity': class="hl-string">'Invoice Cleared', class="hl-string">'DateCreated': row.get(class="hl-string">'event_time'), class="hl-string">'SourceSystem': class="hl-string">'NetSuite'})
            
    class=class="hl-string">"hl-comment"># Promise to Pay check (User Notes often appear in System Notes or separate Note table)
    class=class="hl-string">"hl-comment"># Assuming Note capture via System Note for context
    if class="hl-string">'note' in field: 
        events.append({class="hl-string">'TranId': row.get(class="hl-string">'invoice_num'), class="hl-string">'Activity': class="hl-string">'Promise to Pay Received', class="hl-string">'DateCreated': row.get(class="hl-string">'event_time'), class="hl-string">'SourceSystem': class="hl-string">'NetSuite'})

class=class="hl-string">"hl-comment"># === EXPORT ===
print(class="hl-string">"Generating CSV...")
df = pd.DataFrame(events)

class=class="hl-string">"hl-comment"># Deduplicate and Sort
df.drop_duplicates(inplace=True)
df[class="hl-string">'LastDataUpdate'] = datetime.now().isoformat()

class=class="hl-string">"hl-comment"># Save
df.to_csv(class="hl-string">'netsuite_ar_event_log.csv', index=False)
print(class="hl-string">"Done. File saved as netsuite_ar_event_log.csv")

Prêt à commencer ?

Commencez à améliorer votre cycle d’encaissement en appliquant ce modèle à votre environnement NetSuite. Notre équipe peut vous aider si vous avez besoin d’assistance pour l’association des données ou l’intégration technique.

Retour au guide d’amélioration Télécharger le modèle

Accélérez dès maintenant le cycle des comptes clients dans NetSuite

Réduisez de 15 à 20 jours le délai moyen de paiement de vos clients et comblez dès aujourd’hui les écarts de trésorerie.

Démarrez l’essai gratuit

Aucune carte bancaire requise. Configuration en 5 minutes.

Votre modèle de données pour les comptes clients

Votre modèle de données pour les comptes clients

Attributs des comptes clients

Activités des comptes clients

Guides d’extraction

Export de données NetSuite SuiteAnalytics Workbook

Étapes

Configuration

a Exemple de requête sql

Extraction des données de transactions NetSuite avec SuiteQL

Étapes

Configuration

a Exemple de requête sql

Script Python d’extraction via l’API REST SuiteTalk

Étapes

Configuration

a Exemple de requête python

Prêt à commencer ?

Accélérez dès maintenant le cycle des comptes clients dans NetSuite

Votre modèle de données pour les comptes clients

Votre modèle de données pour les comptes clients

Attributs des comptes clients

Activités des comptes clients

Guides d’extraction

Export de données NetSuite SuiteAnalytics Workbook

Étapes

Configuration

a Exemple de requête sql

Extraction des données de transactions NetSuite avec SuiteQL

Étapes

Configuration

a Exemple de requête sql

Script Python d’extraction via l’API REST SuiteTalk

Étapes

Configuration

a Exemple de requête python

Prêt à commencer ?

Accélérez dès maintenant le cycle des comptes clients dans NetSuite

Nous respectons votre vie privée

Prêt à commencer ?