> Amélioration continue des processus > Traitement des paiements fournisseurs > NetSuite > Modèle de données

Votre modèle de données pour le traitement des paiements fournisseurs

NetSuite

Attributs du traitement des paiements fournisseurs(21) Activités du traitement des paiements fournisseurs(14) Guides d’extraction(3)

Votre modèle de données pour le traitement des paiements fournisseurs

Ce modèle fournit un cadre complet pour cartographier les flux de travail de vos comptes fournisseurs dans NetSuite. Il présente les principaux attributs de données, les activités essentielles du processus et des consignes d’extraction détaillées afin que votre analyse soit précise et exploitable.

Attributs recommandés pour une analyse approfondie
Jalons essentiels du processus à suivre
Consignes d’extraction propres à 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 du traitement des paiements fournisseurs

Voici les champs de données recommandés à inclure dans votre journal d’événements pour analyser en détail le traitement des paiements fournisseurs dans votre environnement NetSuite.

5 Obligatoire 10 Recommandé 6 Facultatif

	Nom	Description
	Activité Activity	Nom de l’étape ou de l’événement du processus.
Description Cet attribut consigne l’action précise ou le changement d’état survenu à un moment donné. Exemples : « Facture créée », « Statut d’approbation modifié » ou « Paiement traité ». Ces données sont indispensables pour reconstituer la carte du processus. En ordonnant chronologiquement les activités de chaque numéro de facture, l’outil de Process Mining visualise le flux de travail réel et repère les boucles, les reprises et les écarts par rapport au parcours nominal. Pourquoi est-ce important ? Définit les étapes de la carte du processus et est obligatoire pour toute analyse de Process Mining. Où trouver ces données System Notes ou journaux d’historique des flux de travail Exemples Facture crééeFacture approuvéePaiement planifiéPaiement compensé par la banque
	Dernière mise à jour des données LastDataUpdate	Horodatage de l’extraction ou de l’actualisation des données.
Description Indique la date de la dernière extraction des données depuis le système source vers la plateforme de Process Mining. Les utilisateurs peuvent ainsi savoir si l’analyse repose sur des données récentes. Cette information permet de déterminer si les données affichées dans les Dashboards reflètent la situation en temps réel ou un instantané d’une période antérieure. Elle est essentielle pour se fier aux calculs du nombre de jours de retard. Pourquoi est-ce important ? Obligatoire pour connaître la fraîcheur des données et l’état de la synchronisation. Où trouver ces données Horodatage ETL Exemples 2023-11-01T00:00:00Z
	Heure de l’événement EventTime	Horodatage de l’activité.
Description Date et heure précises auxquelles une activité a eu lieu. Elles servent à ordonner les événements et à calculer la durée entre les étapes. Des horodatages exacts sont essentiels pour repérer les goulots d’étranglement. Ils permettent de calculer les temps de cycle, par exemple le temps nécessaire à une approbation ou la durée pendant laquelle une facture reste bloquée. Pourquoi est-ce important ? Obligatoire pour ordonner les événements et calculer tous les indicateurs fondés sur le temps. Où trouver ces données Champ 'date' de System Notes Exemples 2023-10-01T14:30:00Z2023-10-02T09:15:00Z
	Numéro de facture InvoiceNumber	Identifiant unique de la facture fournisseur.
Description Cet attribut correspond au numéro de référence unique attribué à une facture fournisseur dans NetSuite. Il sert d’identifiant de cas pour le processus des comptes fournisseurs et regroupe toutes les activités liées à une obligation de paiement donnée. Dans l’analyse, ce champ sert de clé principale pour les instances du processus. Il permet de suivre le cycle de vie complet d’un passif, depuis la réception et l’enregistrement de la facture jusqu’à la confirmation du paiement par la banque. Les variantes sont regroupées à partir de cet identifiant afin de déterminer les parcours les plus fréquents. Pourquoi est-ce important ? Il s’agit de l’ID de cas obligatoire qui relie tous les événements pour constituer un cas de processus. Où trouver ces données Table des transactions, champ 'tranid' lorsque le type est 'Vendor Bill' Exemples INV-2023-001VB-99822ACME-10299982311
	Système source SourceSystem	Nom du système d’origine des données.
Description Identifie l’application logicielle dont proviennent les données d’événement. Dans ce contexte, la valeur est généralement fixe, par exemple 'NetSuite'. Cet attribut est utile dans les environnements comportant plusieurs systèmes, car il permet de suivre la provenance des données. Même si cette vue porte uniquement sur NetSuite, conserver ce champ garantit la compatibilité avec les modèles de données de l’entreprise. Pourquoi est-ce important ? Obligatoire pour assurer la traçabilité des données et les distinguer dans les environnements multi-systèmes. Où trouver ces données Renseigné en dur lors de l’extraction Exemples NetSuiteNetSuite OneWorld
	Date d’échéance DueDate	Date limite à laquelle le fournisseur doit être payé.
Description Cet attribut indique la date limite de paiement prévue par les conditions de la facture. Il sert de référence pour calculer le taux de paiement dans les délais. Ce champ est au cœur de l’indicateur clé de performance « Taux de paiement dans les délais ». En comparant la date de l’activité « Paiement exécuté » à cette date, le système signale les retards et aide à estimer les pénalités éventuelles. Pourquoi est-ce important ? Fondamental pour calculer le taux de paiement dans les délais et repérer les dettes réglées en retard. Où trouver ces données Champ « duedate » de la transaction Exemples 2023-11-152023-12-01
	Date de paiement PaymentDate	Date à laquelle le paiement a été exécuté.
Description Date enregistrée dans la transaction de paiement fournisseur associée à la facture. Elle marque la fin du cycle fournisseurs. Elle permet de calculer les « Durées de cycle de paiement de bout en bout ». La comparaison de cette date avec la date de facture donne la durée totale du processus. Pourquoi est-ce important ? Horodatage de fin du cycle principal du processus. Où trouver ces données Date de la transaction de paiement fournisseur associée Exemples 2023-11-202023-12-05
	Département Department	Département interne associé à la facture.
Description Classe la facture selon le centre de coûts ou le département interne (par exemple, informatique ou marketing) auquel la dépense est imputée. Cet attribut permet de comparer les temps de cycle par département. Il aide à repérer ceux qui mettent plus de temps à coder ou à approuver les factures, afin de cibler les améliorations du processus. Pourquoi est-ce important ? Permet d’analyser l’efficacité du processus par unité de l’organisation. Où trouver ces données Champ « department » de la transaction Exemples InformatiqueMarketingProduction
	Filiale Subsidiary	Filiale ou entité juridique de l’entreprise qui reçoit la facture.
Description Dans les environnements NetSuite OneWorld, cet attribut identifie l’entité juridique (filiale) à laquelle la facture est rattachée. Il permet de comparer les différentes entités de l’organisation. Cet attribut alimente le Dashboard « Durées de cycle de paiement de bout en bout » et permet de comparer l’efficacité des différentes unités opérationnelles. Il aide à repérer les régions ou entités dont les performances sont insuffisantes. Pourquoi est-ce important ? Essentiel aux organisations comptant plusieurs entités qui souhaitent comparer les performances de leurs unités opérationnelles. Où trouver ces données Champ « subsidiary » de la transaction Exemples Est des États-UnisSiège EMEAVentes APAC
	Montant de la facture InvoiceAmount	Montant total de la facture.
Description Montant total de la facture fournisseur, généralement exprimé dans la devise de référence ou dans la devise de la transaction. Cette métrique permet d’analyser l’impact financier. Elle est utilisée dans le Dashboard « Suivi des retards de paiement et des pénalités » pour quantifier le risque que les retards font peser sur la trésorerie. Elle permet également de prioriser les factures de montant élevé nécessitant une intervention manuelle. Pourquoi est-ce important ? Nécessaire pour quantifier l’impact financier des inefficacités du processus. Où trouver ces données Champ « usertotal » ou « foreignamount » de la transaction Exemples 1500.00250.5010000.00
	Nom du fournisseur VendorName	Nom du fournisseur qui a émis la facture.
Description Cet attribut indique le nom de l’entité associée à la facture fournisseur. Il est essentiel pour analyser les performances tout au long de la chaîne d’approvisionnement. Dans les analyses, ce champ alimente le Dashboard « Écart du cycle de paiement par fournisseur ». Les analystes peuvent regrouper les dossiers par fournisseur afin de repérer ceux qui provoquent régulièrement des écarts de rapprochement ou appliquent des conditions de paiement non standard. Pourquoi est-ce important ? Essentiel pour regrouper les analyses par fournisseur et repérer les goulots d’étranglement qui lui sont propres. Où trouver ces données Champ « entity » de la transaction, associé à l’enregistrement du fournisseur Exemples Office DepotOracleFedEx
	Numéro de commande d’achat PurchaseOrderNumber	Numéro de référence de la commande d’achat associée.
Description Associe la facture fournisseur à la commande d’achat (PO) à l’origine de la transaction. Si ce champ est vide, la facture est considérée comme une facture sans commande d’achat. Cet attribut est essentiel au Dashboard « Vitesse de traitement des factures sans commande d’achat ». Il permet de distinguer les variantes du processus selon qu’elles concernent des factures avec commande d’achat ou des factures FI sans commande d’achat, afin d’en comparer l’efficacité et la conformité. Pourquoi est-ce important ? Nécessaire pour distinguer le traitement des factures avec commande d’achat de celui des factures sans commande d’achat. Où trouver ces données Champ « createdfrom » de la transaction Exemples PO-8821PO-1002null
	Sans commande d’achat IsNonPO	Indique si la facture n’est pas associée à une commande d’achat.
Description Attribut booléen déduit de l’absence de commande d’achat associée. Il distingue les factures liées à une commande d’achat des factures FI directes. Utilisé dans le Dashboard « Vitesse de traitement des factures sans commande d’achat », il met en évidence les inefficacités du traitement manuel par rapport au processus de rapprochement à trois voies. Pourquoi est-ce important ? Segment général permettant d’analyser les variantes du processus. Où trouver ces données Déduit de la valeur nulle de « PurchaseOrderNumber » Exemples truefalse
	Statut d’approbation ApprovalStatus	État actuel de l’approbation de la facture dans le flux de travail.
Description Indique si la facture est en attente d’approbation, approuvée ou rejetée. Cet état détermine les transitions du flux de travail. Ce champ est au cœur de l’« Audit de conformité du flux d’approbation ». Les changements de statut génèrent des événements d’activité, et le statut final indique si la facture peut être payée. Pourquoi est-ce important ? Suit l’avancement de la facture dans le circuit d’approbation. Où trouver ces données Champ « approvalstatus » de la transaction Exemples En attente d’approbationApprouvéRejeté
	Utilisateur User	Employé ayant réalisé l’activité.
Description Identifie la personne responsable d’un événement donné, par exemple l’approbation d’une facture ou la levée d’un blocage de paiement. Cet attribut est utilisé dans le Dashboard « Suivi des goulots d’étranglement du flux d’approbation » pour repérer les retards liés à certaines ressources. Il aide les responsables à répartir la charge de travail et à déterminer les besoins de formation de certains membres de l’équipe. Pourquoi est-ce important ? Nécessaire pour analyser les ressources et repérer les goulots d’étranglement au niveau des utilisateurs. Où trouver ces données Champ « name » des notes système ou champ « employee » de la transaction Exemples John DoeAdministrateur financierSystème
	Blocage du paiement PaymentHold	Indique si le paiement de la facture est actuellement bloqué.
Description Indicateur ou statut signalant qu’un blocage de paiement a été appliqué à la facture, qui ne peut alors pas être incluse dans les campagnes de paiement. Cet attribut alimente le Dashboard « Analyse de l’impact des blocages de paiement ». L’analyse de la durée pendant laquelle ce champ est défini sur « true » met en évidence les retards de traitement dus à des litiges ou à des informations manquantes. Pourquoi est-ce important ? Essentiel pour comprendre pourquoi des factures sont bloquées ou retardées. Où trouver ces données Champ « paymenthold » de la transaction Exemples truefalse
	Conditions de paiement PaymentTerms	Conditions convenues qui définissent les délais de paiement et les remises.
Description Précise les conditions de paiement, par exemple « Net 30 » ou « 2 % 10 Net 30 ». Ces informations permettent d’expliquer la date d’échéance et les éventuelles remises pour paiement anticipé. Cet attribut est utilisé dans le Dashboard « Taux de récupération des remises pour paiement anticipé ». Il permet de repérer les factures ouvrant droit à une remise et de mettre en relation les remises perdues avec certaines conditions restrictives. Pourquoi est-ce important ? Permet de comprendre la date d’échéance et de repérer les possibilités de remise. Où trouver ces données Champ « terms » de la transaction Exemples Net 302 % 10 Net 30Payable à réception
	Date de la facture InvoiceDate	Date figurant sur la facture du fournisseur.
Description Date du document fournie par le fournisseur. Elle sert souvent de point de départ au calcul de l’ancienneté de la facture. Elle permet de calculer le « Temps de cycle de traitement de bout en bout ». L’écart entre cette date et la date de création dans NetSuite peut révéler des retards liés à la numérisation ou au traitement du courrier. Pourquoi est-ce important ? Marque le début officiel du délai de traitement de la facture fournisseur. Où trouver ces données Champ « trandate » de la transaction Exemples 2023-10-012023-10-05
	Devise Currency	Devise dans laquelle la facture a été émise.
Description Code ISO représentant la devise de la transaction. Cette information est importante pour les organisations multinationales. Elle permet de normaliser les montants dans l’analyse du montant des factures. Elle aide également à déterminer si les opérations de change allongent le délai avant l’activité « Paiement compensé ». Pourquoi est-ce important ? Nécessaire pour agréger correctement les montants financiers et analyser les opérations de change. Où trouver ces données Champ « currency » de la transaction Exemples USDEURGBP
	Jours de retard DaysOverdue	Nombre de jours écoulés entre la date d’échéance et le paiement.
Description Métrique calculée qui mesure le retard de paiement par rapport à la date d’échéance. Les valeurs négatives indiquent un paiement anticipé. Cet attribut alimente le Dashboard « Suivi des retards de paiement et des pénalités ». Il est essentiel pour mesurer l’ampleur des retards de paiement et repérer les retards récurrents. Pourquoi est-ce important ? Métrique clé pour analyser le respect des conditions de paiement et le risque de pénalités. Où trouver ces données Calcul : date de paiement - date d’échéance Exemples 50-2
	Remise disponible DiscountAvailable	Montant de la remise éventuelle pour paiement anticipé.
Description Montant de la remise pour paiement anticipé, calculé à partir du montant de la facture et des conditions de paiement. Il représente l’économie potentielle. Cet attribut est au cœur du Dashboard « Taux de récupération des remises pour paiement anticipé ». En additionnant les montants correspondant aux paiements tardifs, les analystes peuvent calculer le total des économies manquées. Pourquoi est-ce important ? Quantifie les gains financiers possibles grâce à l’accélération du processus. Où trouver ces données Calculé à partir des conditions de paiement et du montant de la facture Exemples 30.000.0015.50

Obligatoire Recommandé Facultatif

Activités du traitement des paiements fournisseurs

Voici les principales étapes et les jalons à enregistrer dans votre journal d’événements pour reconstituer avec précision le cycle de traitement des paiements.

5 Recommandé 9 Facultatif

	Activité	Description
	Facture approuvée	Le statut de l’enregistrement Vendor Bill passe à Open, ce qui indique que la facture est autorisée au paiement et a été inscrite au grand livre. Il s’agit d’une étape clé avant le paiement.
Pourquoi est-ce important ? Met fin au cycle d’approbation et rend la facture disponible pour la planification du paiement. Cette étape est essentielle pour mesurer l’efficacité des approbations. Où trouver ces données System Notes. Recherchez le passage du champ 'approvalstatus' à '2' (Approved) ou le passage du statut à 'Open'. Données à recueillir Comparez le champ de statut avant et après Type d’événement inferred
	Facture créée	Création initiale de l’enregistrement Vendor Bill dans NetSuite. Cet événement marque le début du processus et indique que la facture a été saisie dans l’ERP.
Pourquoi est-ce important ? Définit l’horodatage de référence pour l’ensemble du cycle des comptes fournisseurs et le calcul de l’ancienneté des factures. Où trouver ces données Table des transactions. Filtrez les enregistrements dont le type est Vendor Bill. Récupérez le champ datecreated ou trandate. Données à recueillir Enregistré lors de l’exécution de la transaction Vendor Bill Type d’événement explicit
	Facture rapprochée avec le bon de commande	Indique que l’enregistrement Vendor Bill a été créé à partir d’un bon de commande existant ou qu’il y est associé. Cela permet de distinguer les factures liées à un bon de commande des autres.
Pourquoi est-ce important ? Indispensable pour analyser le respect des politiques d’approvisionnement et comparer les temps de cycle des factures avec et sans bon de commande. Où trouver ces données Table des transactions. Vérifiez le champ 'createdfrom' de l’enregistrement Vendor Bill. Si ce champ contient l’identifiant d’un bon de commande, l’activité a eu lieu. Données à recueillir Comparez le champ de statut avant et après Type d’événement inferred
	Paiement compensé par la banque	L’enregistrement Bill Payment est marqué comme compensé lors du rapprochement bancaire. Cela confirme que les fonds ont quitté le compte bancaire.
Pourquoi est-ce important ? Fournit la date réelle de sortie des fonds pour l’analyse de trésorerie, distincte de la date comptable du paiement. Où trouver ces données Transaction Line. Le champ 'cleared' de la ligne de transaction Bill Payment est défini sur True. Données à recueillir Enregistré lors de l’exécution de la transaction X Type d’événement explicit
	Paiement traité	Un enregistrement Bill Payment est comptabilisé avec succès. La facture est alors marquée comme entièrement ou partiellement payée et le passif est soldé dans le grand livre.
Pourquoi est-ce important ? Principale étape marquant la fin du processus de paiement. Sert à calculer le temps de cycle de traitement de bout en bout. Où trouver ces données Table des transactions. Repérez la création d’un enregistrement 'Bill Payment' ou le passage de son statut à 'Deposited' (pour les chèques) ou à 'Paid'. Données à recueillir Enregistré lors de l’exécution de la transaction Bill Payment Type d’événement explicit
	Approbation de la facture demandée	Le statut de l’enregistrement Vendor Bill passe à Pending Approval. La facture entre alors dans le circuit de travail d’approbation.
Pourquoi est-ce important ? Marque le début du temps de cycle d’approbation et permet de repérer les goulots d’étranglement dans le circuit d’autorisation. Où trouver ces données System Notes. Recherchez le passage du champ 'approvalstatus' à '1' (Pending Approval). Données à recueillir Comparez le champ de statut avant et après Type d’événement inferred
	Avoir fournisseur appliqué	Un avoir fournisseur (Vendor Credit) est appliqué à l’enregistrement Vendor Bill, ce qui réduit le montant dû. Il s’agit d’une solution de remplacement au paiement en espèces.
Pourquoi est-ce important ? Explique pourquoi le montant payé peut différer du montant de la facture et permet de solder correctement le passif. Où trouver ces données Transaction Links. Repérez les transactions de type 'Vendor Credit' associées à l’enregistrement Vendor Bill. Données à recueillir Comparez le champ de statut avant et après Type d’événement inferred
	Blocage du paiement appliqué	La case Payment Hold de l’enregistrement Vendor Bill est cochée. La facture ne peut alors plus être sélectionnée pour les campagnes de paiement.
Pourquoi est-ce important ? Repère les goulots d’étranglement qui retardent les factures en raison de litiges ou de décisions de gestion de trésorerie. Où trouver ces données System Notes. Recherchez le passage du champ 'paymenthold' de 'F' à 'T'. Données à recueillir Enregistré lors de l’exécution de la transaction X Type d’événement explicit
	Blocage du paiement levé	La case Payment Hold est décochée, ce qui autorise le traitement du paiement de la facture. Cette étape marque la fin de la période de blocage.
Pourquoi est-ce important ? Sert à calculer l’indicateur de durée de blocage du paiement et à comprendre les délais de résolution des factures contestées. Où trouver ces données System Notes. Recherchez le passage du champ 'paymenthold' de 'T' à 'F'. Données à recueillir Enregistré lors de l’exécution de la transaction X Type d’événement explicit
	Compte de la facture modifié	Le compte de charges du grand livre associé aux lignes de facture est modifié. Cela peut indiquer la correction d’une erreur d’imputation ou un reclassement.
Pourquoi est-ce important ? Mesure directement l’indicateur de taux de reprise d’imputation des factures et met en évidence les pertes d’efficacité à l’étape de l’imputation comptable. Où trouver ces données System Notes. Recherchez les modifications du champ 'account' dans la sous-liste Transaction Line. Données à recueillir Enregistré lors de l’exécution de la transaction X Type d’événement explicit
	Facture rejetée	L’enregistrement Vendor Bill est renvoyé à la personne qui l’a soumis pour correction ou refus. Cela correspond à une boucle ou à la fin du flux de travail d’approbation.
Pourquoi est-ce important ? Un taux de rejet élevé peut révéler des difficultés dans le processus, des besoins de formation ou des problèmes de qualité des données en amont. Où trouver ces données System Notes. Recherchez le passage du champ 'approvalstatus' à '3' (Rejected). Données à recueillir Comparez le champ de statut avant et après Type d’événement inferred
	Montant de la facture modifié	Le montant total de l’enregistrement Vendor Bill est modifié après sa création. Cela peut indiquer des reprises, des erreurs de saisie ou la résolution d’un écart.
Pourquoi est-ce important ? Signale une intervention manuelle et des reprises, qui réduisent le taux de traitement sans intervention manuelle. Où trouver ces données System Notes. Recherchez les modifications des champs 'total' ou 'usertotal' de l’enregistrement Vendor Bill. Données à recueillir Enregistré lors de l’exécution de la transaction X Type d’événement explicit
	Paiement annulé	Un enregistrement Bill Payment déjà traité est annulé, ce qui rouvre l’enregistrement Vendor Bill. Il s’agit d’une exception majeure et d’un échec du processus.
Pourquoi est-ce important ? Indispensable pour respecter les exigences d’audit et repérer les causes des échecs de paiement, comme les erreurs d’impression de chèques ou les rejets bancaires. Où trouver ces données System Notes de Bill Payment. Recherchez le passage du statut à 'Voided'. Données à recueillir Enregistré lors de l’exécution de la transaction X Type d’événement explicit
	Paiement planifié	Un enregistrement Bill Payment est créé avec le statut 'Pending Approval'. Cela se produit souvent lors de la création d’un lot de paiements électroniques (EFT).
Pourquoi est-ce important ? Distingue l’intention de payer du transfert effectif des fonds et met en évidence les retards d’autorisation du paiement. Où trouver ces données Table des transactions. Création d’un enregistrement 'Bill Payment' associé à la facture et portant le statut 'Pending Approval'. Données à recueillir Comparez le champ de statut avant et après Type d’événement inferred

Recommandé Facultatif

Guides d’extraction

Comment extraire vos données de NetSuite

Étapes

Connectez-vous à NetSuite en tant qu’administrateur ou utilisateur autorisé à créer et à exporter des recherches enregistrées.
Accédez à Lists > Search > Saved Searches > New.
Sélectionnez Transaction dans la liste des types d’enregistrement pour créer une recherche enregistrée de transactions.
Dans l’onglet Criteria, vérifiez que la case Use Expressions n’est pas cochée, puis ajoutez le filtre Type et sélectionnez Vendor Bill, Bill Payment ou Bill Credit.
Toujours dans l’onglet Criteria, ajoutez le filtre Main Line et définissez sa valeur sur True. Vous ciblerez ainsi les données d’en-tête relatives à la création et aux changements de statut.
Pour enregistrer l’historique, accédez à la jointure System Notes dans la liste des filtres, au bas du menu déroulant, puis ajoutez System Notes : Date. Définissez la période souhaitée, par exemple les 90 derniers jours.
Passez à l’onglet Results et supprimez toutes les colonnes par défaut.
Ajoutez la colonne d’identifiant du cas : sélectionnez Transaction Name ou Document Number. Attribuez-lui le libellé personnalisé InvoiceNumber.
Ajoutez la colonne d’heure de l’événement : sélectionnez System Notes fields... > Date. Attribuez-lui le libellé personnalisé EventTime.
Ajoutez la colonne Activité : sélectionnez Formula (Text). Dans la fenêtre de formule, collez l’instruction CASE fournie dans la section Query ci-dessous. Cette logique associe les modifications de champs NetSuite aux noms d’activité standard. Attribuez à la colonne le libellé personnalisé Activity.
Ajoutez les autres attributs requis (Source System, Last Data Update) à l’aide de Formula (Text), avec des valeurs statiques, par exemple « NetSuite », et la balise intégrée {today}.
Cliquez sur Save & Run. Une fois les résultats chargés, cliquez sur l’icône Export - CSV en haut à gauche de la barre d’outils des résultats pour télécharger le journal d’événements destiné à ProcessMind.

Configuration

Types de transaction : limitez le filtre à Vendor Bill, Bill Payment et Bill Credit afin d’éviter les données superflues provenant des écritures de journal ou des bons de commande.
Jointure System Notes : cette configuration s’appuie largement sur la jointure System Notes pour produire un historique plutôt qu’un instantané de l’état actuel. Vérifiez que votre rôle utilisateur permet de consulter System Notes.
Période : appliquez le filtre de date au champ System Notes : Date, et non au champ Date de la transaction. Vous pourrez ainsi inclure les activités récentes sur des factures anciennes, par exemple un paiement effectué aujourd’hui pour une facture créée l’année dernière.
Main Line : la valeur Main Line = True est recommandée pour réduire le nombre de lignes. Toutefois, si vous devez suivre « Invoice Account Modified », vous devrez peut-être définir Main Line = False ou créer une recherche distincte pour les modifications au niveau des lignes.
Limites des formules : les formules NetSuite sont limitées à 4 000 caractères. Si la logique de la colonne Activité devient trop complexe, répartissez-la entre deux recherches ou effectuez l’association en dehors de NetSuite.

Exemple de requête config

Type: Transaction

CRITERIA TAB:
- Type: is any of Vendor Bill, Bill Payment, Bill Credit
- Main Line: is True
- System Notes : Date: is within [Your Date Range]

RESULTS TAB:

Column 1: Document Number
- Label: InvoiceNumber

Column 2: System Notes : Date
- Label: EventTime

Column 3: Formula (Text)
- Label: Activity
- Formula:
CASE 
   WHEN {systemnotes.type} = 'Create' AND {type} = 'Bill' THEN 'Invoice Created'
   WHEN {systemnotes.type} = 'Create' AND {type} = 'Bill' AND {createdfrom} IS NOT NULL THEN 'Invoice Matched to PO'
   WHEN {type} = 'Bill' AND {systemnotes.field} = 'Approval Status' AND {systemnotes.newvalue} = 'Pending Approval' THEN 'Invoice Approval Requested'
   WHEN {type} = 'Bill' AND {systemnotes.field} = 'Approval Status' AND {systemnotes.newvalue} = 'Open' THEN 'Invoice Approved'
   WHEN {type} = 'Bill' AND {systemnotes.field} = 'Approval Status' AND {systemnotes.newvalue} = 'Rejected' THEN 'Invoice Rejected'
   WHEN {type} = 'Bill' AND {systemnotes.field} = 'Amount' THEN 'Invoice Amount Modified'
   WHEN {type} = 'Bill' AND {systemnotes.field} = 'Account' THEN 'Invoice Account Modified'
   WHEN {type} = 'Bill' AND {systemnotes.field} = 'Payment Hold' AND {systemnotes.newvalue} = 'T' THEN 'Payment Hold Applied'
   WHEN {type} = 'Bill' AND {systemnotes.field} = 'Payment Hold' AND {systemnotes.newvalue} = 'F' THEN 'Payment Hold Released'
   WHEN {type} = 'Bill Credit' AND {systemnotes.type} = 'Create' THEN 'Vendor Credit Applied'
   WHEN {type} = 'Bill Payment' AND {systemnotes.type} = 'Create' AND {status} = 'Pending Approval' THEN 'Payment Scheduled'
   WHEN {type} = 'Bill Payment' AND {systemnotes.type} = 'Create' AND {status} = 'Paid In Full' THEN 'Payment Processed'
   WHEN {type} = 'Bill Payment' AND {systemnotes.field} = 'Void' THEN 'Payment Voided'
   WHEN {type} = 'Bill Payment' AND {systemnotes.field} = 'Cleared' AND {systemnotes.newvalue} = 'T' THEN 'Payment Cleared'
   ELSE 'General Update'
END

Column 4: Formula (Text)
- Label: SourceSystem
- Formula: 'NetSuite'

Column 5: Formula (Text)
- Label: LastDataUpdate
- Formula: TO_CHAR({today}, 'YYYY-MM-DD HH24:MI:SS')

Column 6: Vendor : Name
- Label: VendorName

Column 7: Subsidiary
- Label: Subsidiary

Column 8: Amount
- Label: InvoiceAmount

Column 9: Due Date
- Label: DueDate

Column 10: Created From
- Label: PurchaseOrderNumber

Column 11: System Notes : Set by
- Label: User

Column 12: Department
- Label: Department

Column 13: Status
- Label: ApprovalStatus

Column 14: Formula (Text)
- Label: IsNonPO
- Formula: CASE WHEN {createdfrom} IS NULL THEN 'True' ELSE 'False' END

Étapes

Configurer le pilote ODBC : vérifiez que le pilote ODBC SuiteAnalytics Connect est installé et configuré sur la machine utilisée pour l’extraction. Vous aurez besoin de l’identifiant de compte NetSuite, de l’identifiant de rôle et d’identifiants de connexion valides.
Vérifier les autorisations : le rôle utilisateur associé à la connexion ODBC doit disposer de l’autorisation « SuiteAnalytics Connect » et d’un accès en consultation aux transactions, aux System Notes et aux entités.
Préparer l’environnement : ouvrez votre client SQL, par exemple DBeaver, DataGrip ou un outil ETL propriétaire, puis connectez-vous à la source de données NetSuite.
Définir le périmètre : déterminez les identifiants de filiale et la période à couvrir par l’extraction. Modifiez la clause WHERE de l’expression de table commune (CTE) nommée « VendorBills » dans la requête fournie.
Exécuter la requête : lancez le script SQL fourni. Il regroupe les données des tables « Transaction », « TransactionLine », « SystemNote » et « TransactionLink » afin de reconstituer l’historique du processus.
Surveiller l’exécution : les connexions ODBC NetSuite peuvent expirer avec de grands volumes de données. En cas d’échec de la requête, répartissez l’extraction par mois ou par trimestre à l’aide du filtre « trandate ».
Valider les données : vérifiez que la répartition des événements « Invoice Created » et « Payment Processed » est cohérente. Assurez-vous que le champ « InvoiceNumber » est renseigné pour chaque ligne.
Exporter les données : enregistrez les résultats de la requête dans un fichier CSV ou importez-les directement dans votre dataframe. Vérifiez que l’encodage des caractères est défini sur UTF-8 afin de préserver les caractères spéciaux des noms de fournisseurs.
Formater les dates : lors de l’importation dans ProcessMind, vérifiez que la colonne « EventTime » est interprétée comme une date et une heure au format YYYY-MM-DD HH:MM:SS.
Traiter les valeurs nulles : dans la colonne « User », les valeurs nulles correspondent souvent à des événements générés par le système, comme les scripts planifiés. Si vous le souhaitez, vous pouvez les remplacer par « System » lors du post-traitement.
Effectuer une vérification finale : confirmez que la colonne « Activité » contient les noms d’événements requis, par exemple « Invoice Created » et « Payment Processed », et qu’aucune erreur d’association ne s’est produite.

Configuration

Période : filtrez à l’aide de « Transaction.trandate ». Pour une première analyse de Process Mining, une période de 3 à 12 mois est recommandée.
Filtrage par filiale : si votre environnement NetSuite est configuré avec OneWorld, filtrez toujours par « Transaction.subsidiary » afin d’analyser la bonne entité juridique.
System Notes : l’extraction s’appuie largement sur la table « SystemNote » pour récupérer les validations et l’historique des modifications. Vérifiez que l’option « Log System Notes on Update Only » n’empêche pas l’enregistrement des étapes importantes du flux de travail.
Statut des transactions : les statuts des transactions NetSuite sont distincts, par exemple « A » et « B ». La requête les convertit en libellés lisibles. Vérifiez que votre environnement utilise les codes de statut standard.
Version du pilote ODBC : utilisez la dernière version disponible du pilote SuiteAnalytics Connect pour éviter les problèmes de compatibilité avec les mises à niveau récentes de NetSuite.

Exemple de requête sql

WITH VendorBills AS (
    SELECT
        t.ID AS TransactionID,
        t.tranid AS InvoiceNumber,
        t.trandate AS InvoiceDate,
        t.createDate AS CreatedDate,
        t.lastModifiedDate AS LastModified,
        e.altName AS VendorName,
        s.name AS Subsidiary,
        t.foreignTotal AS InvoiceAmount,
        t.dueDate AS DueDate,
        t.createdFrom AS CreatedFromID,
        CASE WHEN t.createdFrom IS NULL THEN 'True' ELSE 'False' END AS IsNonPO,
        dep.name AS Department,
        'NetSuite' AS SourceSystem
    FROM
        Transaction t
        LEFT JOIN Entity e ON t.entity = e.id
        LEFT JOIN Subsidiary s ON t.subsidiary = s.id
        LEFT JOIN Department dep ON t.department = dep.id
    WHERE
        t.type = 'VendBill'
        AND t.trandate >= TO_DATE('2023-01-01', 'YYYY-MM-DD') -- REPLACE WITH YOUR START DATE
        AND t.trandate <= TO_DATE('2023-12-31', 'YYYY-MM-DD') -- REPLACE WITH YOUR END DATE
),
PO_Data AS (
    SELECT
        t.ID AS PO_ID,
        t.tranid AS PONumber
    FROM
        Transaction t
    WHERE
        t.type = 'PurchOrd'
)

-- 1. Invoice Created
SELECT
    vb.InvoiceNumber,
    'Invoice Created' AS Activity,
    vb.CreatedDate AS EventTime,
    vb.SourceSystem,
    vb.LastModified AS LastDataUpdate,
    vb.VendorName,
    vb.Subsidiary,
    vb.InvoiceAmount,
    vb.DueDate,
    po.PONumber AS PurchaseOrderNumber,
    NULL AS User,
    vb.Department,
    'Created' AS ApprovalStatus,
    vb.IsNonPO,
    NULL AS PaymentDate
FROM
    VendorBills vb
    LEFT JOIN PO_Data po ON vb.CreatedFromID = po.PO_ID

UNION ALL

-- 2. Invoice Matched to PO
SELECT
    vb.InvoiceNumber,
    'Invoice Matched to PO' AS Activity,
    vb.CreatedDate AS EventTime,
    vb.SourceSystem,
    vb.LastModified AS LastDataUpdate,
    vb.VendorName,
    vb.Subsidiary,
    vb.InvoiceAmount,
    vb.DueDate,
    po.PONumber AS PurchaseOrderNumber,
    NULL AS User,
    vb.Department,
    'Created' AS ApprovalStatus,
    vb.IsNonPO,
    NULL AS PaymentDate
FROM
    VendorBills vb
    INNER JOIN PO_Data po ON vb.CreatedFromID = po.PO_ID

UNION ALL

-- 3. Invoice Approval Requested (Derived from System Notes)
SELECT
    vb.InvoiceNumber,
    'Invoice Approval Requested' AS Activity,
    sn.date AS EventTime,
    vb.SourceSystem,
    vb.LastModified AS LastDataUpdate,
    vb.VendorName,
    vb.Subsidiary,
    vb.InvoiceAmount,
    vb.DueDate,
    po.PONumber AS PurchaseOrderNumber,
    emp.entityid AS User,
    vb.Department,
    'Pending Approval' AS ApprovalStatus,
    vb.IsNonPO,
    NULL AS PaymentDate
FROM
    VendorBills vb
    INNER JOIN SystemNote sn ON vb.TransactionID = sn.recordID
    LEFT JOIN PO_Data po ON vb.CreatedFromID = po.PO_ID
    LEFT JOIN Entity emp ON sn.name = emp.id
WHERE
    sn.standardfield = 'approvalstatus'
    AND sn.newValue = 'Pending Approval'

UNION ALL

-- 4. Invoice Approved
SELECT
    vb.InvoiceNumber,
    'Invoice Approved' AS Activity,
    sn.date AS EventTime,
    vb.SourceSystem,
    vb.LastModified AS LastDataUpdate,
    vb.VendorName,
    vb.Subsidiary,
    vb.InvoiceAmount,
    vb.DueDate,
    po.PONumber AS PurchaseOrderNumber,
    emp.entityid AS User,
    vb.Department,
    'Open' AS ApprovalStatus,
    vb.IsNonPO,
    NULL AS PaymentDate
FROM
    VendorBills vb
    INNER JOIN SystemNote sn ON vb.TransactionID = sn.recordID
    LEFT JOIN PO_Data po ON vb.CreatedFromID = po.PO_ID
    LEFT JOIN Entity emp ON sn.name = emp.id
WHERE
    sn.standardfield = 'approvalstatus'
    AND (sn.newValue = 'Approved' OR sn.newValue = 'Open')

UNION ALL

-- 5. Invoice Rejected
SELECT
    vb.InvoiceNumber,
    'Invoice Rejected' AS Activity,
    sn.date AS EventTime,
    vb.SourceSystem,
    vb.LastModified AS LastDataUpdate,
    vb.VendorName,
    vb.Subsidiary,
    vb.InvoiceAmount,
    vb.DueDate,
    po.PONumber AS PurchaseOrderNumber,
    emp.entityid AS User,
    vb.Department,
    'Rejected' AS ApprovalStatus,
    vb.IsNonPO,
    NULL AS PaymentDate
FROM
    VendorBills vb
    INNER JOIN SystemNote sn ON vb.TransactionID = sn.recordID
    LEFT JOIN PO_Data po ON vb.CreatedFromID = po.PO_ID
    LEFT JOIN Entity emp ON sn.name = emp.id
WHERE
    sn.standardfield = 'approvalstatus'
    AND sn.newValue = 'Rejected'

UNION ALL

-- 6. Invoice Amount Modified
SELECT
    vb.InvoiceNumber,
    'Invoice Amount Modified' AS Activity,
    sn.date AS EventTime,
    vb.SourceSystem,
    vb.LastModified AS LastDataUpdate,
    vb.VendorName,
    vb.Subsidiary,
    vb.InvoiceAmount,
    vb.DueDate,
    po.PONumber AS PurchaseOrderNumber,
    emp.entityid AS User,
    vb.Department,
    'Modified' AS ApprovalStatus,
    vb.IsNonPO,
    NULL AS PaymentDate
FROM
    VendorBills vb
    INNER JOIN SystemNote sn ON vb.TransactionID = sn.recordID
    LEFT JOIN PO_Data po ON vb.CreatedFromID = po.PO_ID
    LEFT JOIN Entity emp ON sn.name = emp.id
WHERE
    (sn.standardfield = 'foreigntotal' OR sn.standardfield = 'total')

UNION ALL

-- 7. Invoice Account Modified
SELECT
    vb.InvoiceNumber,
    'Invoice Account Modified' AS Activity,
    sn.date AS EventTime,
    vb.SourceSystem,
    vb.LastModified AS LastDataUpdate,
    vb.VendorName,
    vb.Subsidiary,
    vb.InvoiceAmount,
    vb.DueDate,
    po.PONumber AS PurchaseOrderNumber,
    emp.entityid AS User,
    vb.Department,
    'Modified' AS ApprovalStatus,
    vb.IsNonPO,
    NULL AS PaymentDate
FROM
    VendorBills vb
    INNER JOIN SystemNote sn ON vb.TransactionID = sn.recordID
    LEFT JOIN PO_Data po ON vb.CreatedFromID = po.PO_ID
    LEFT JOIN Entity emp ON sn.name = emp.id
WHERE
    sn.standardfield = 'account'

UNION ALL

-- 8. Payment Hold Applied
SELECT
    vb.InvoiceNumber,
    'Payment Hold Applied' AS Activity,
    sn.date AS EventTime,
    vb.SourceSystem,
    vb.LastModified AS LastDataUpdate,
    vb.VendorName,
    vb.Subsidiary,
    vb.InvoiceAmount,
    vb.DueDate,
    po.PONumber AS PurchaseOrderNumber,
    emp.entityid AS User,
    vb.Department,
    'Hold' AS ApprovalStatus,
    vb.IsNonPO,
    NULL AS PaymentDate
FROM
    VendorBills vb
    INNER JOIN SystemNote sn ON vb.TransactionID = sn.recordID
    LEFT JOIN PO_Data po ON vb.CreatedFromID = po.PO_ID
    LEFT JOIN Entity emp ON sn.name = emp.id
WHERE
    sn.standardfield = 'paymenthold'
    AND sn.newValue = 'T'

UNION ALL

-- 9. Payment Hold Released
SELECT
    vb.InvoiceNumber,
    'Payment Hold Released' AS Activity,
    sn.date AS EventTime,
    vb.SourceSystem,
    vb.LastModified AS LastDataUpdate,
    vb.VendorName,
    vb.Subsidiary,
    vb.InvoiceAmount,
    vb.DueDate,
    po.PONumber AS PurchaseOrderNumber,
    emp.entityid AS User,
    vb.Department,
    'Released' AS ApprovalStatus,
    vb.IsNonPO,
    NULL AS PaymentDate
FROM
    VendorBills vb
    INNER JOIN SystemNote sn ON vb.TransactionID = sn.recordID
    LEFT JOIN PO_Data po ON vb.CreatedFromID = po.PO_ID
    LEFT JOIN Entity emp ON sn.name = emp.id
WHERE
    sn.standardfield = 'paymenthold'
    AND sn.newValue = 'F'

UNION ALL

-- 10. Vendor Credit Applied
SELECT
    vb.InvoiceNumber,
    'Vendor Credit Applied' AS Activity,
    vc.createDate AS EventTime,
    vb.SourceSystem,
    vb.LastModified AS LastDataUpdate,
    vb.VendorName,
    vb.Subsidiary,
    vb.InvoiceAmount,
    vb.DueDate,
    po.PONumber AS PurchaseOrderNumber,
    NULL AS User,
    vb.Department,
    'Credit Applied' AS ApprovalStatus,
    vb.IsNonPO,
    NULL AS PaymentDate
FROM
    VendorBills vb
    INNER JOIN TransactionLink tl ON vb.TransactionID = tl.previousDoc
    INNER JOIN Transaction vc ON tl.nextDoc = vc.ID
    LEFT JOIN PO_Data po ON vb.CreatedFromID = po.PO_ID
WHERE
    vc.type = 'VendCred'

UNION ALL

-- 11. Payment Scheduled (Bill Payment created but pending)
SELECT
    vb.InvoiceNumber,
    'Payment Scheduled' AS Activity,
    vp.createDate AS EventTime,
    vb.SourceSystem,
    vb.LastModified AS LastDataUpdate,
    vb.VendorName,
    vb.Subsidiary,
    vb.InvoiceAmount,
    vb.DueDate,
    po.PONumber AS PurchaseOrderNumber,
    NULL AS User,
    vb.Department,
    'Scheduled' AS ApprovalStatus,
    vb.IsNonPO,
    vp.trandate AS PaymentDate
FROM
    VendorBills vb
    INNER JOIN TransactionLink tl ON vb.TransactionID = tl.previousDoc
    INNER JOIN Transaction vp ON tl.nextDoc = vp.ID
    LEFT JOIN PO_Data po ON vb.CreatedFromID = po.PO_ID
WHERE
    vp.type = 'VendPymt'
    AND vp.status = 'Pending Approval'

UNION ALL

-- 12. Payment Processed (Payment posted)
SELECT
    vb.InvoiceNumber,
    'Payment Processed' AS Activity,
    vp.trandate AS EventTime,
    vb.SourceSystem,
    vb.LastModified AS LastDataUpdate,
    vb.VendorName,
    vb.Subsidiary,
    vb.InvoiceAmount,
    vb.DueDate,
    po.PONumber AS PurchaseOrderNumber,
    NULL AS User,
    vb.Department,
    'Paid' AS ApprovalStatus,
    vb.IsNonPO,
    vp.trandate AS PaymentDate
FROM
    VendorBills vb
    INNER JOIN TransactionLink tl ON vb.TransactionID = tl.previousDoc
    INNER JOIN Transaction vp ON tl.nextDoc = vp.ID
    LEFT JOIN PO_Data po ON vb.CreatedFromID = po.PO_ID
WHERE
    vp.type = 'VendPymt'
    AND (vp.status = 'PaidInFull' OR vp.status = 'Deposited' OR vp.status = 'NotDeposited')

UNION ALL

-- 13. Payment Voided
SELECT
    vb.InvoiceNumber,
    'Payment Voided' AS Activity,
    sn.date AS EventTime,
    vb.SourceSystem,
    vb.LastModified AS LastDataUpdate,
    vb.VendorName,
    vb.Subsidiary,
    vb.InvoiceAmount,
    vb.DueDate,
    po.PONumber AS PurchaseOrderNumber,
    emp.entityid AS User,
    vb.Department,
    'Voided' AS ApprovalStatus,
    vb.IsNonPO,
    NULL AS PaymentDate
FROM
    VendorBills vb
    INNER JOIN TransactionLink tl ON vb.TransactionID = tl.previousDoc
    INNER JOIN Transaction vp ON tl.nextDoc = vp.ID
    INNER JOIN SystemNote sn ON vp.ID = sn.recordID
    LEFT JOIN PO_Data po ON vb.CreatedFromID = po.PO_ID
    LEFT JOIN Entity emp ON sn.name = emp.id
WHERE
    vp.type = 'VendPymt'
    AND sn.standardfield = 'status'
    AND sn.newValue LIKE '%Void%'

UNION ALL

-- 14. Payment Cleared
SELECT
    vb.InvoiceNumber,
    'Payment Cleared' AS Activity,
    vp.clearedDate AS EventTime,
    vb.SourceSystem,
    vb.LastModified AS LastDataUpdate,
    vb.VendorName,
    vb.Subsidiary,
    vb.InvoiceAmount,
    vb.DueDate,
    po.PONumber AS PurchaseOrderNumber,
    NULL AS User,
    vb.Department,
    'Cleared' AS ApprovalStatus,
    vb.IsNonPO,
    vp.trandate AS PaymentDate
FROM
    VendorBills vb
    INNER JOIN TransactionLink tl ON vb.TransactionID = tl.previousDoc
    INNER JOIN Transaction vp ON tl.nextDoc = vp.ID
    LEFT JOIN PO_Data po ON vb.CreatedFromID = po.PO_ID
WHERE
    vp.type = 'VendPymt'
    AND vp.clearedDate IS NOT NULL

Étapes

Prérequis : vérifiez que vous disposez d’un compte NetSuite avec un accès administrateur ou développeur. Les fonctionnalités « SuiteTalk REST Web Services » et « SuiteAnalytics Connect » doivent être activées dans Setup > Company > Enable Features.
Configuration de l’intégration : accédez à Setup > Integration > Manage Integrations > New. Créez une intégration nommée « ProcessMining_ETL ». Cochez « Rest Web Services » et « Token-Based Authentication ». Notez la Consumer Key et le Consumer Secret générés.
Génération du jeton : accédez à la page Manage Access Tokens. Créez un jeton pour le rôle autorisé à consulter les transactions, System Notes et les listes. Notez le Token ID et le Token Secret.
Environnement Python : installez Python 3.x. Installez les bibliothèques nécessaires avec pip : pip install requests requests-oauthlib pandas.
Configuration du script : copiez le script Python fourni dans la section Query ci-dessous. Remplacez les variables ACCOUNT_ID, CONSUMER_KEY, CONSUMER_SECRET, TOKEN_ID et TOKEN_SECRET par vos identifiants. Définissez la variable START_DATE selon la période d’extraction souhaitée, par exemple « 2023-01-01 ».
Logique SuiteQL : le script utilise une approche UNION ALL. Il interroge la table Transaction pour récupérer les événements de création et de paiement, et la table SystemNote pour les événements d’audit, notamment les approbations, les modifications et les mises en attente.
Exécution : lancez le script en ligne de commande : python netsuite_extract.py. La pagination est gérée automatiquement : SuiteQL répartit les résultats en pages de 1 000 enregistrements.
Traitement des données : le script convertit automatiquement la réponse JSON en tableau à plat adapté au Process Mining. Il gère l’association des colonnes et le formatage des dates.
Validation : le script affiche le nombre total de lignes extraites. Si nécessaire, comparez ce résultat à une recherche enregistrée NetSuite.
Export : le dataframe final est enregistré sous le nom netsuite_ap_event_log.csv. Ce fichier est prêt à être importé dans ProcessMind.
Importation : importez le fichier CSV dans ProcessMind. Associez InvoiceNumber à l’ID de cas, Activity à Activité et EventTime à l’horodatage.

Configuration

Authentification : utilise OAuth 1.0a (Token-Based Authentication), le modèle de sécurité standard de l’API REST NetSuite.
Taille des lots : le script demande 1 000 lignes par page, soit le maximum par défaut de SuiteQL dans NetSuite.
Filtrage par date : le script filtre sur trandate pour les transactions et sur date pour les notes système, avec une valeur supérieure ou égale à START_DATE, afin d’optimiser les performances.
Périmètre : le script filtre la table Transaction par type : « VendBill » (Vendor Bill), « BillPymt » (Bill Payment) et « VendCred » (Vendor Credit).
System Notes : cette table est essentielle pour enregistrer les boucles d’approbation et les modifications. Elle peut être volumineuse ; vérifiez que l’utilisateur de l’intégration est autorisé à interroger SystemNote.
Fuseau horaire : l’API NetSuite renvoie les dates dans le fuseau horaire du compte. Le script suppose qu’elles sont au format ISO standard.

Exemple de requête python

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

class=class="hl-string">"hl-comment"># === CONFIGURATION ===
ACCOUNT_ID = class="hl-string">'1234567_SB1'  class=class="hl-string">"hl-comment"># Your NetSuite Account ID (Realm). Use hyphens for sandbox (e.g., 1234567-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'
START_DATE = class="hl-string">'2024-01-01'  class=class="hl-string">"hl-comment"># Filter for data extraction

class=class="hl-string">"hl-comment"># Normalize Account ID for URL (NetSuite requires lowercase and hyphens)
url_account_id = ACCOUNT_ID.lower().replace(class="hl-string">'_', class="hl-string">'-')
BASE_URL = fclass="hl-string">'https://{url_account_id}.suitetalk.api.netsuite.com/services/rest/query/v1/suiteql'

class=class="hl-string">"hl-comment"># === SUITEQL QUERY ===
class=class="hl-string">"hl-comment"># This query extracts 14 activities using UNION ALL to combine Transaction data and System Notes.
suiteql_query = fclass="hl-string">"""
/* 1. Invoice Created */
SELECT
    t.tranid AS InvoiceNumber,
    'Invoice Created' AS Activity,
    TO_CHAR(t.createddate, 'YYYY-MM-DD HH24:MI:SS') AS EventTime,
    'NetSuite' AS SourceSystem,
    TO_CHAR(SYSDATE, 'YYYY-MM-DD HH24:MI:SS') AS LastDataUpdate,
    bu.name AS VendorName,
    s.name AS Subsidiary,
    t.foreignTotal AS InvoiceAmount,
    t.duedate AS DueDate,
    t.otherrefnum AS PurchaseOrderNumber,
    e.entityid AS User,
    d.name AS Department,
    t.status AS ApprovalStatus,
    CASE WHEN t.createdfrom IS NULL THEN 'True' ELSE 'False' END AS IsNonPO,
    NULL AS PaymentDate
FROM Transaction t
LEFT JOIN Entity bu ON t.entity = bu.id
LEFT JOIN Subsidiary s ON t.subsidiary = s.id
LEFT JOIN Employee e ON t.createdBy = e.id
LEFT JOIN Department d ON t.department = d.id
WHERE t.type = 'VendBill'
AND t.trandate >= TO_DATE('{START_DATE}', 'YYYY-MM-DD')

UNION ALL

/* 2. Invoice Matched to PO */
SELECT
    t.tranid AS InvoiceNumber,
    'Invoice Matched to PO' AS Activity,
    TO_CHAR(t.createddate, 'YYYY-MM-DD HH24:MI:SS') AS EventTime,
    'NetSuite' AS SourceSystem,
    TO_CHAR(SYSDATE, 'YYYY-MM-DD HH24:MI:SS') AS LastDataUpdate,
    bu.name AS VendorName,
    s.name AS Subsidiary,
    t.foreignTotal AS InvoiceAmount,
    t.duedate AS DueDate,
    t.otherrefnum AS PurchaseOrderNumber,
    e.entityid AS User,
    d.name AS Department,
    t.status AS ApprovalStatus,
    'False' AS IsNonPO,
    NULL AS PaymentDate
FROM Transaction t
LEFT JOIN Entity bu ON t.entity = bu.id
LEFT JOIN Subsidiary s ON t.subsidiary = s.id
LEFT JOIN Employee e ON t.createdBy = e.id
LEFT JOIN Department d ON t.department = d.id
WHERE t.type = 'VendBill'
AND t.createdfrom IS NOT NULL
AND t.trandate >= TO_DATE('{START_DATE}', 'YYYY-MM-DD')

UNION ALL

/* 3. Invoice Approval Requested (System Note) */
SELECT
    t.tranid AS InvoiceNumber,
    'Invoice Approval Requested' AS Activity,
    TO_CHAR(sn.date, 'YYYY-MM-DD HH24:MI:SS') AS EventTime,
    'NetSuite' AS SourceSystem,
    TO_CHAR(SYSDATE, 'YYYY-MM-DD HH24:MI:SS') AS LastDataUpdate,
    bu.name AS VendorName,
    s.name AS Subsidiary,
    t.foreignTotal AS InvoiceAmount,
    t.duedate AS DueDate,
    t.otherrefnum AS PurchaseOrderNumber,
    rau.entityid AS User,
    d.name AS Department,
    t.status AS ApprovalStatus,
    CASE WHEN t.createdfrom IS NULL THEN 'True' ELSE 'False' END AS IsNonPO,
    NULL AS PaymentDate
FROM SystemNote sn
JOIN Transaction t ON sn.recordid = t.id
LEFT JOIN Entity bu ON t.entity = bu.id
LEFT JOIN Subsidiary s ON t.subsidiary = s.id
LEFT JOIN Employee rau ON sn.name = rau.id
LEFT JOIN Department d ON t.department = d.id
WHERE sn.recordtypeid = -30 /* Internal ID for Vendor Bill */
AND sn.field = 'status'
AND sn.value = 'Pending Approval'
AND t.trandate >= TO_DATE('{START_DATE}', 'YYYY-MM-DD')

UNION ALL

/* 4. Invoice Approved (System Note) */
SELECT
    t.tranid AS InvoiceNumber,
    'Invoice Approved' AS Activity,
    TO_CHAR(sn.date, 'YYYY-MM-DD HH24:MI:SS') AS EventTime,
    'NetSuite' AS SourceSystem,
    TO_CHAR(SYSDATE, 'YYYY-MM-DD HH24:MI:SS') AS LastDataUpdate,
    bu.name AS VendorName,
    s.name AS Subsidiary,
    t.foreignTotal AS InvoiceAmount,
    t.duedate AS DueDate,
    t.otherrefnum AS PurchaseOrderNumber,
    rau.entityid AS User,
    d.name AS Department,
    t.status AS ApprovalStatus,
    CASE WHEN t.createdfrom IS NULL THEN 'True' ELSE 'False' END AS IsNonPO,
    NULL AS PaymentDate
FROM SystemNote sn
JOIN Transaction t ON sn.recordid = t.id
LEFT JOIN Entity bu ON t.entity = bu.id
LEFT JOIN Subsidiary s ON t.subsidiary = s.id
LEFT JOIN Employee rau ON sn.name = rau.id
LEFT JOIN Department d ON t.department = d.id
WHERE sn.recordtypeid = -30
AND sn.field = 'status'
AND sn.value = 'Open'
AND t.trandate >= TO_DATE('{START_DATE}', 'YYYY-MM-DD')

UNION ALL

/* 5. Invoice Rejected (System Note) */
SELECT
    t.tranid AS InvoiceNumber,
    'Invoice Rejected' AS Activity,
    TO_CHAR(sn.date, 'YYYY-MM-DD HH24:MI:SS') AS EventTime,
    'NetSuite' AS SourceSystem,
    TO_CHAR(SYSDATE, 'YYYY-MM-DD HH24:MI:SS') AS LastDataUpdate,
    bu.name AS VendorName,
    s.name AS Subsidiary,
    t.foreignTotal AS InvoiceAmount,
    t.duedate AS DueDate,
    t.otherrefnum AS PurchaseOrderNumber,
    rau.entityid AS User,
    d.name AS Department,
    t.status AS ApprovalStatus,
    CASE WHEN t.createdfrom IS NULL THEN 'True' ELSE 'False' END AS IsNonPO,
    NULL AS PaymentDate
FROM SystemNote sn
JOIN Transaction t ON sn.recordid = t.id
LEFT JOIN Entity bu ON t.entity = bu.id
LEFT JOIN Subsidiary s ON t.subsidiary = s.id
LEFT JOIN Employee rau ON sn.name = rau.id
LEFT JOIN Department d ON t.department = d.id
WHERE sn.recordtypeid = -30
AND sn.field = 'status'
AND sn.value = 'Rejected'
AND t.trandate >= TO_DATE('{START_DATE}', 'YYYY-MM-DD')

UNION ALL

/* 6. Invoice Amount Modified (System Note) */
SELECT
    t.tranid AS InvoiceNumber,
    'Invoice Amount Modified' AS Activity,
    TO_CHAR(sn.date, 'YYYY-MM-DD HH24:MI:SS') AS EventTime,
    'NetSuite' AS SourceSystem,
    TO_CHAR(SYSDATE, 'YYYY-MM-DD HH24:MI:SS') AS LastDataUpdate,
    bu.name AS VendorName,
    s.name AS Subsidiary,
    t.foreignTotal AS InvoiceAmount,
    t.duedate AS DueDate,
    t.otherrefnum AS PurchaseOrderNumber,
    rau.entityid AS User,
    d.name AS Department,
    t.status AS ApprovalStatus,
    CASE WHEN t.createdfrom IS NULL THEN 'True' ELSE 'False' END AS IsNonPO,
    NULL AS PaymentDate
FROM SystemNote sn
JOIN Transaction t ON sn.recordid = t.id
LEFT JOIN Entity bu ON t.entity = bu.id
LEFT JOIN Subsidiary s ON t.subsidiary = s.id
LEFT JOIN Employee rau ON sn.name = rau.id
LEFT JOIN Department d ON t.department = d.id
WHERE sn.recordtypeid = -30
AND sn.field = 'total'
AND t.trandate >= TO_DATE('{START_DATE}', 'YYYY-MM-DD')

UNION ALL

/* 7. Invoice Account Modified (System Note) */
SELECT
    t.tranid AS InvoiceNumber,
    'Invoice Account Modified' AS Activity,
    TO_CHAR(sn.date, 'YYYY-MM-DD HH24:MI:SS') AS EventTime,
    'NetSuite' AS SourceSystem,
    TO_CHAR(SYSDATE, 'YYYY-MM-DD HH24:MI:SS') AS LastDataUpdate,
    bu.name AS VendorName,
    s.name AS Subsidiary,
    t.foreignTotal AS InvoiceAmount,
    t.duedate AS DueDate,
    t.otherrefnum AS PurchaseOrderNumber,
    rau.entityid AS User,
    d.name AS Department,
    t.status AS ApprovalStatus,
    CASE WHEN t.createdfrom IS NULL THEN 'True' ELSE 'False' END AS IsNonPO,
    NULL AS PaymentDate
FROM SystemNote sn
JOIN Transaction t ON sn.recordid = t.id
LEFT JOIN Entity bu ON t.entity = bu.id
LEFT JOIN Subsidiary s ON t.subsidiary = s.id
LEFT JOIN Employee rau ON sn.name = rau.id
LEFT JOIN Department d ON t.department = d.id
WHERE sn.recordtypeid = -30
AND sn.field = 'account'
AND t.trandate >= TO_DATE('{START_DATE}', 'YYYY-MM-DD')

UNION ALL

/* 8. Payment Hold Applied (System Note) */
SELECT
    t.tranid AS InvoiceNumber,
    'Payment Hold Applied' AS Activity,
    TO_CHAR(sn.date, 'YYYY-MM-DD HH24:MI:SS') AS EventTime,
    'NetSuite' AS SourceSystem,
    TO_CHAR(SYSDATE, 'YYYY-MM-DD HH24:MI:SS') AS LastDataUpdate,
    bu.name AS VendorName,
    s.name AS Subsidiary,
    t.foreignTotal AS InvoiceAmount,
    t.duedate AS DueDate,
    t.otherrefnum AS PurchaseOrderNumber,
    rau.entityid AS User,
    d.name AS Department,
    t.status AS ApprovalStatus,
    CASE WHEN t.createdfrom IS NULL THEN 'True' ELSE 'False' END AS IsNonPO,
    NULL AS PaymentDate
FROM SystemNote sn
JOIN Transaction t ON sn.recordid = t.id
LEFT JOIN Entity bu ON t.entity = bu.id
LEFT JOIN Subsidiary s ON t.subsidiary = s.id
LEFT JOIN Employee rau ON sn.name = rau.id
LEFT JOIN Department d ON t.department = d.id
WHERE sn.recordtypeid = -30
AND sn.field = 'paymenthold'
AND sn.value = 'T'
AND t.trandate >= TO_DATE('{START_DATE}', 'YYYY-MM-DD')

UNION ALL

/* 9. Payment Hold Released (System Note) */
SELECT
    t.tranid AS InvoiceNumber,
    'Payment Hold Released' AS Activity,
    TO_CHAR(sn.date, 'YYYY-MM-DD HH24:MI:SS') AS EventTime,
    'NetSuite' AS SourceSystem,
    TO_CHAR(SYSDATE, 'YYYY-MM-DD HH24:MI:SS') AS LastDataUpdate,
    bu.name AS VendorName,
    s.name AS Subsidiary,
    t.foreignTotal AS InvoiceAmount,
    t.duedate AS DueDate,
    t.otherrefnum AS PurchaseOrderNumber,
    rau.entityid AS User,
    d.name AS Department,
    t.status AS ApprovalStatus,
    CASE WHEN t.createdfrom IS NULL THEN 'True' ELSE 'False' END AS IsNonPO,
    NULL AS PaymentDate
FROM SystemNote sn
JOIN Transaction t ON sn.recordid = t.id
LEFT JOIN Entity bu ON t.entity = bu.id
LEFT JOIN Subsidiary s ON t.subsidiary = s.id
LEFT JOIN Employee rau ON sn.name = rau.id
LEFT JOIN Department d ON t.department = d.id
WHERE sn.recordtypeid = -30
AND sn.field = 'paymenthold'
AND sn.value = 'F'
AND t.trandate >= TO_DATE('{START_DATE}', 'YYYY-MM-DD')

UNION ALL

/* 10. Vendor Credit Applied */
SELECT
    t_bill.tranid AS InvoiceNumber,
    'Vendor Credit Applied' AS Activity,
    TO_CHAR(t_cred.trandate, 'YYYY-MM-DD HH24:MI:SS') AS EventTime,
    'NetSuite' AS SourceSystem,
    TO_CHAR(SYSDATE, 'YYYY-MM-DD HH24:MI:SS') AS LastDataUpdate,
    bu.name AS VendorName,
    s.name AS Subsidiary,
    t_bill.foreignTotal AS InvoiceAmount,
    t_bill.duedate AS DueDate,
    t_bill.otherrefnum AS PurchaseOrderNumber,
    e.entityid AS User,
    d.name AS Department,
    t_bill.status AS ApprovalStatus,
    CASE WHEN t_bill.createdfrom IS NULL THEN 'True' ELSE 'False' END AS IsNonPO,
    t_cred.trandate AS PaymentDate
FROM Transaction t_cred
JOIN TransactionLine tl ON t_cred.id = tl.transaction
JOIN Transaction t_bill ON tl.appliedtotransaction = t_bill.id
LEFT JOIN Entity bu ON t_bill.entity = bu.id
LEFT JOIN Subsidiary s ON t_bill.subsidiary = s.id
LEFT JOIN Employee e ON t_cred.createdBy = e.id
LEFT JOIN Department d ON t_bill.department = d.id
WHERE t_cred.type = 'VendCred'
AND t_bill.trandate >= TO_DATE('{START_DATE}', 'YYYY-MM-DD')

UNION ALL

/* 11. Payment Scheduled */
SELECT
    t_bill.tranid AS InvoiceNumber,
    'Payment Scheduled' AS Activity,
    TO_CHAR(t_pay.createddate, 'YYYY-MM-DD HH24:MI:SS') AS EventTime,
    'NetSuite' AS SourceSystem,
    TO_CHAR(SYSDATE, 'YYYY-MM-DD HH24:MI:SS') AS LastDataUpdate,
    bu.name AS VendorName,
    s.name AS Subsidiary,
    t_bill.foreignTotal AS InvoiceAmount,
    t_bill.duedate AS DueDate,
    t_bill.otherrefnum AS PurchaseOrderNumber,
    e.entityid AS User,
    d.name AS Department,
    t_bill.status AS ApprovalStatus,
    CASE WHEN t_bill.createdfrom IS NULL THEN 'True' ELSE 'False' END AS IsNonPO,
    t_pay.trandate AS PaymentDate
FROM Transaction t_pay
JOIN TransactionLine tl ON t_pay.id = tl.transaction
JOIN Transaction t_bill ON tl.appliedtotransaction = t_bill.id
LEFT JOIN Entity bu ON t_bill.entity = bu.id
LEFT JOIN Subsidiary s ON t_bill.subsidiary = s.id
LEFT JOIN Employee e ON t_pay.createdBy = e.id
LEFT JOIN Department d ON t_bill.department = d.id
WHERE t_pay.type = 'BillPymt'
AND t_pay.status = 'Pending Approval'
AND t_bill.trandate >= TO_DATE('{START_DATE}', 'YYYY-MM-DD')

UNION ALL

/* 12. Payment Processed */
SELECT
    t_bill.tranid AS InvoiceNumber,
    'Payment Processed' AS Activity,
    TO_CHAR(t_pay.trandate, 'YYYY-MM-DD HH24:MI:SS') AS EventTime,
    'NetSuite' AS SourceSystem,
    TO_CHAR(SYSDATE, 'YYYY-MM-DD HH24:MI:SS') AS LastDataUpdate,
    bu.name AS VendorName,
    s.name AS Subsidiary,
    t_bill.foreignTotal AS InvoiceAmount,
    t_bill.duedate AS DueDate,
    t_bill.otherrefnum AS PurchaseOrderNumber,
    e.entityid AS User,
    d.name AS Department,
    t_bill.status AS ApprovalStatus,
    CASE WHEN t_bill.createdfrom IS NULL THEN 'True' ELSE 'False' END AS IsNonPO,
    t_pay.trandate AS PaymentDate
FROM Transaction t_pay
JOIN TransactionLine tl ON t_pay.id = tl.transaction
JOIN Transaction t_bill ON tl.appliedtotransaction = t_bill.id
LEFT JOIN Entity bu ON t_bill.entity = bu.id
LEFT JOIN Subsidiary s ON t_bill.subsidiary = s.id
LEFT JOIN Employee e ON t_pay.createdBy = e.id
LEFT JOIN Department d ON t_bill.department = d.id
WHERE t_pay.type = 'BillPymt'
AND t_pay.status <> 'Voided'
AND t_bill.trandate >= TO_DATE('{START_DATE}', 'YYYY-MM-DD')

UNION ALL

/* 13. Payment Voided */
SELECT
    t_bill.tranid AS InvoiceNumber,
    'Payment Voided' AS Activity,
    TO_CHAR(t_pay.lastmodifieddate, 'YYYY-MM-DD HH24:MI:SS') AS EventTime,
    'NetSuite' AS SourceSystem,
    TO_CHAR(SYSDATE, 'YYYY-MM-DD HH24:MI:SS') AS LastDataUpdate,
    bu.name AS VendorName,
    s.name AS Subsidiary,
    t_bill.foreignTotal AS InvoiceAmount,
    t_bill.duedate AS DueDate,
    t_bill.otherrefnum AS PurchaseOrderNumber,
    e.entityid AS User,
    d.name AS Department,
    t_bill.status AS ApprovalStatus,
    CASE WHEN t_bill.createdfrom IS NULL THEN 'True' ELSE 'False' END AS IsNonPO,
    t_pay.trandate AS PaymentDate
FROM Transaction t_pay
JOIN TransactionLine tl ON t_pay.id = tl.transaction
JOIN Transaction t_bill ON tl.appliedtotransaction = t_bill.id
LEFT JOIN Entity bu ON t_bill.entity = bu.id
LEFT JOIN Subsidiary s ON t_bill.subsidiary = s.id
LEFT JOIN Employee e ON t_pay.createdBy = e.id
LEFT JOIN Department d ON t_bill.department = d.id
WHERE t_pay.type = 'BillPymt'
AND t_pay.status = 'Voided'
AND t_bill.trandate >= TO_DATE('{START_DATE}', 'YYYY-MM-DD')

UNION ALL

/* 14. Payment Cleared (Logic depends on bank rec features, using Check Cleared date or modification) */
SELECT
    t_bill.tranid AS InvoiceNumber,
    'Payment Cleared' AS Activity,
    /* Fallback to trandate if clearedDate is unavailable in your config */
    TO_CHAR(COALESCE(t_pay.createddate, t_pay.trandate), 'YYYY-MM-DD HH24:MI:SS') AS EventTime,
    'NetSuite' AS SourceSystem,
    TO_CHAR(SYSDATE, 'YYYY-MM-DD HH24:MI:SS') AS LastDataUpdate,
    bu.name AS VendorName,
    s.name AS Subsidiary,
    t_bill.foreignTotal AS InvoiceAmount,
    t_bill.duedate AS DueDate,
    t_bill.otherrefnum AS PurchaseOrderNumber,
    e.entityid AS User,
    d.name AS Department,
    t_bill.status AS ApprovalStatus,
    CASE WHEN t_bill.createdfrom IS NULL THEN 'True' ELSE 'False' END AS IsNonPO,
    t_pay.trandate AS PaymentDate
FROM Transaction t_pay
JOIN TransactionLine tl ON t_pay.id = tl.transaction
JOIN Transaction t_bill ON tl.appliedtotransaction = t_bill.id
LEFT JOIN Entity bu ON t_bill.entity = bu.id
LEFT JOIN Subsidiary s ON t_bill.subsidiary = s.id
LEFT JOIN Employee e ON t_pay.createdBy = e.id
LEFT JOIN Department d ON t_bill.department = d.id
WHERE t_pay.type = 'BillPymt'
AND t_pay.status = 'Paid In Full' /* Indicates cleared/posted in some contexts */
AND t_bill.trandate >= TO_DATE('{START_DATE}', 'YYYY-MM-DD')
"""

class=class="hl-string">"hl-comment"># === AUTH AND EXECUTION ===

def get_suiteql_results(query):
    oauth = OAuth1(
        client_key=CONSUMER_KEY,
        client_secret=CONSUMER_SECRET,
        resource_owner_key=TOKEN_ID,
        resource_owner_secret=TOKEN_SECRET,
        realm=ACCOUNT_ID,
        signature_method=class="hl-string">'HMAC-SHA256'
    )
    
    all_rows = []
    offset = 0
    has_more = True
    
    print(class="hl-string">"Starting extraction...")
    
    while has_more:
        class=class="hl-string">"hl-comment"># SuiteQL REST API payload
        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"># Add LIMIT/OFFSET to query if not using built-in cursors (SuiteQL doesn't support OFFSET well natively in string, 
        class=class="hl-string">"hl-comment"># but REST API handles pagination via links. However, for raw query, we usually rely on class="hl-string">'items' return)
        class=class="hl-string">"hl-comment"># Note: Pure SuiteQL via REST returns a set number of records. We must iterate via the class="hl-string">'links' provided in response
        class=class="hl-string">"hl-comment"># or typically, SuiteQL REST creates a job for large queries. 
        class=class="hl-string">"hl-comment"># For simplicity in this script, we assume a direct synchronous call pattern.
        
        class=class="hl-string">"hl-comment"># Actually, for large datasets, we must use the class="hl-string">'q' parameter. 
        class=class="hl-string">"hl-comment"># But SuiteQL POST body is standard. We will implement simple looping if class="hl-string">'hasMore' is present.
        
        payload = {
            class="hl-string">"q": query
        }
        
        response = requests.post(BASE_URL, headers=headers, auth=oauth, json=payload)
        
        if response.status_code != 200:
            print(fclass="hl-string">"Error: {response.text}")
            break
            
        data = response.json()
        items = data.get(class="hl-string">'items', [])
        all_rows.extend(items)
        
        class=class="hl-string">"hl-comment"># Check if there are more results (SuiteQL REST paging)
        class=class="hl-string">"hl-comment"># Standard REST response has class="hl-string">'hasMore' and class="hl-string">'links'. 
        class=class="hl-string">"hl-comment"># However, Query API V1 often requires traversing the class="hl-string">'next' link.
        has_more = data.get(class="hl-string">'hasMore', False)
        
        if has_more:
            class=class="hl-string">"hl-comment"># For subsequent pages, we follow the class="hl-string">'next' link logic or offset logic.
            class=class="hl-string">"hl-comment"># Note: The Query API creates a paged result set. We strictly need to follow the class="hl-string">'links' > class="hl-string">'next'.
            links = data.get(class="hl-string">'links', [])
            next_link = next((l[class="hl-string">'href'] for l in links if l[class="hl-string">'rel'] == class="hl-string">'next'), None)
            if next_link:
                BASE_URL = next_link class=class="hl-string">"hl-comment"># Update URL for next loop
                class=class="hl-string">"hl-comment"># Payload is not needed for next link GET usually, but Query API might differ.
                class=class="hl-string">"hl-comment"># If using links, we switch to GET for the next page.
                class=class="hl-string">"hl-comment"># (Simplified logic: In production, robustly handle the href)
            else:
                has_more = False
        
        print(fclass="hl-string">"Fetched {len(items)} rows. Total: {len(all_rows)}")
        time.sleep(1) class=class="hl-string">"hl-comment"># Rate limit protection

    return pd.DataFrame(all_rows)

class=class="hl-string">"hl-comment"># === RUN ===
if __name__ == class="hl-string">'__main__':
    df = get_suiteql_results(suiteql_query)
    
    class=class="hl-string">"hl-comment"># Post-processing
    if not df.empty:
        class=class="hl-string">"hl-comment"># Ensure numeric formats
        df[class="hl-string">'invoiceamount'] = pd.to_numeric(df[class="hl-string">'invoiceamount'], errors=class="hl-string">'coerce').fillna(0)
        
        class=class="hl-string">"hl-comment"># Save
        filename = class="hl-string">'netsuite_ap_event_log.csv'
        df.to_csv(filename, index=False)
        print(fclass="hl-string">"Success! Saved {len(df)} rows to {filename}")
    else:
        print(class="hl-string">"No data found.")

Prêt à commencer ?

Commencez dès aujourd’hui votre démarche de Process Mining en appliquant ce modèle à votre environnement NetSuite. Repérez les gains d’efficacité possibles et optimisez sans attendre vos flux de travail de paiement.

Retour au guide d’amélioration

Télécharger le modèle

Optimisez dès aujourd’hui le traitement des paiements fournisseurs

Repérez les goulots d’étranglement et réduisez le temps de cycle de 30 %.

Démarrez l’essai gratuit

Aucune carte bancaire n’est requise. La configuration ne prend que quelques minutes.

Votre modèle de données pour le traitement des paiements fournisseurs

Votre modèle de données pour le traitement des paiements fournisseurs

Attributs du traitement des paiements fournisseurs

Activités du traitement des paiements fournisseurs

Guides d’extraction

Export d’une recherche enregistrée NetSuite pour les transactions fournisseurs

Étapes

Configuration

Exemple de requête config

Extraction SuiteQL via ODBC avec SuiteAnalytics Connect

Étapes

Configuration

Exemple de requête sql

ETL Python avec l’API REST SuiteTalk et SuiteQL

Étapes

Configuration

Exemple de requête python

Prêt à commencer ?

Optimisez dès aujourd’hui le traitement des paiements fournisseurs

Votre modèle de données pour le traitement des paiements fournisseurs

Votre modèle de données pour le traitement des paiements fournisseurs

Attributs du traitement des paiements fournisseurs

Activités du traitement des paiements fournisseurs

Guides d’extraction

Export d’une recherche enregistrée NetSuite pour les transactions fournisseurs

Étapes

Configuration

Exemple de requête config

Extraction SuiteQL via ODBC avec SuiteAnalytics Connect

Étapes

Configuration

Exemple de requête sql

ETL Python avec l’API REST SuiteTalk et SuiteQL

Étapes

Configuration

Exemple de requête python

Prêt à commencer ?

Optimisez dès aujourd’hui le traitement des paiements fournisseurs

Prêt à commencer ?