> Amélioration Continue des Processusus > De la commande au paiement Facturation et encaissement > Salesforce Sales Cloud > Template de données

Votre modèle de données `Order-to-Cash` - Facturation

Salesforce Sales Cloud

← Retour au Guide d'amélioration

Attributs De la commande au paiement - Facturation et encaissement (19) Activités De la commande au paiement - Facturation et encaissement (13) Guides d'extraction (3)

Votre modèle de données `Order-to-Cash` - Facturation

Ce modèle offre un aperçu complet des attributs de données et des activités essentiels nécessaires pour analyser efficacement votre processus Order-to-Cash - Facturation et encaissement. Il décrit les informations spécifiques à collecter pour votre journal d'événements, ainsi que des conseils pratiques sur l'extraction de ces données. Utilisez cette ressource pour optimiser vos initiatives de Process Mining et obtenir des informations clés.

Attributs recommandés à collecter
Activités clés à suivre
Guide d'extraction

Vous découvrez les journaux d'événements ? Apprenez comment créer un journal d'événements Process Mining.

Télécharger le modèle

Attributs De la commande au paiement - Facturation et encaissement

Ce sont les champs de données recommandés à inclure dans votre journal d'événements pour une analyse complète de l'Order-to-Cash - Facturation et encaissement, garantissant que toutes les informations critiques sont capturées.

3 Obligatoire 5 Recommandé 11 Facultatif

	Nom	Descriptionn
	Heure de l'événement EventTime	L'horodatage indiquant quand une activité spécifique s'est produite.
Descriptionn Cet attribut fournit la date et l'heure de chaque activité, ce qui est impératif pour l'ordonnancement chronologique et l'analyse des performances. Les horodatages établissent la séquence des événements et permettent le calcul des durées entre eux. Dans l'analyse des processus, l'Heure de l'Événement est utilisée pour calculer toutes les métriques temporelles, y compris les temps de cycle, les temps d'attente et les durées d'activités spécifiques. C'est la base des KPI comme le 'Temps de Cycle Moyen de la Facture' et le 'DSO', et cela alimente des dashboards tels que 'Temps de Cycle d'Approbation des Factures' et 'Performance de Réconciliation des Paiements'. Pourquoi est-ce important ? : Cet horodatage est indispensable pour séquencer correctement les événements et calculer toutes les métriques de performance, telles que les temps de cycle et les durées, qui sont la clé pour identifier les retards. Source des données : Ces données proviennent souvent de champs d'horodatage générés par le système comme `CreatedDate` ou `LastModifiedDate` sur l'objet Facture ou les enregistrements Tâche/Événement connexes. Exemples 2023-04-15T10:00:00Z2023-04-16T14:30:00Z2023-05-20T09:05:12Z
	Nom de l'activité ActivityName	Le nom de l'événement métier spécifique qui s'est produit dans le processus de facturation.
Descriptionn Cet attribut décrit l'étape ou le jalon qui a été atteint dans le cycle de vie de la facture, tel que 'Facture Générée' ou 'paiement reçu'. Ces activités constituent les nœuds de la cartographie des processus. L'analyse de la séquence du Nom d'Activité est clée pour le Process Mining. Elle révèle le flux de processus réel, permettant une comparaison avec le processus conçu. Elle est utilisée pour identifier les écarts, les points de blocage entre des étapes spécifiques et les boucles de reprise, soutenant directement des dashboards tels que 'Reprise et Erreurs du Processus de Facturation' et le 'Rapport de Violation de Conformité de la Facturation'. Pourquoi est-ce important ? : Il définit les étapes du processus, formant l'pilier central de la carte de processus et permettant l'analyse du workflow, des points de blocage et des écarts. Source des données : Ceci est généralement dérivé des changements apportés au champ Statut de l'objet Facture ou des enregistrements dans des objets liés comme Tâche ou Événement, qui suivent des actions spécifiques. Exemples Facture généréeFacture approuvéeFacture envoyée au clientpaiement reçu
	Numéro de facture InvoiceNumber	L'identifiant unique pour chaque facture, servant d'identifiant de dossier principal pour le processus de facturation.
Descriptionn Le Numéro de Facture est l'attribut central qui regroupe toutes les activités de facturation connexes en un seul cas. Chaque numéro représente un document de facturation distinct envoyé à un client. Dans l'analyse Process Mining, cet attribut permet un suivi complet du cycle de vie d'une facture, de sa génération à son paiement final et à sa clôture. Il est indispensable pour construire la cartographie des processus et calculer les KPI au niveau du cas, tels que le 'Temps de Cycle Moyen de la Facture' et le 'Days Sales Outstanding'. L'analyse des processus par Numéro de Facture aide à identifier les points de blocage, les boucles de reprise et les écarts de Conformité pour les instances de facturation individuelles. Pourquoi est-ce important ? : C'est la clé essentielle pour lier tous les événements de facturation connexes, permettant une vision globale complet du processus de facturation pour chaque transaction unique. Source des données : C'est généralement la clé primaire de l'objet Facture dans Salesforce Sales Cloud, souvent représentée par le `InvoiceNumber` ou un champ d'ID unique similaire. Exemples INV-00582INV-01934INV-10345
	Date d'échéance du paiement PaymentDueDate	La date à laquelle le client est tenu de payer la facture.
Descriptionn Cet attribut spécifie la date limite de paiement, telle qu'indiquée sur la facture. Elle est calculée en fonction de la date de la facture et des conditions de paiement convenues. La Date d'Échéance du Paiement est un point de données critique pour la planification financière et la gestion des recouvrements. C'est la référence par rapport à laquelle la performance de paiement réelle est mesurée. Elle est indispensablele pour calculer le KPI 'Taux de paiement ponctuel' et pour les dashboards qui suivent la ponctualité des paiements, tels que le 'Tendance du Days Sales Outstanding (DSO)'. Pourquoi est-ce important ? : C'est le repère pour mesurer la performance des paiements, calculer le DSO et déclencher des activités de recouvrement comme les rappels de paiement. Source des données : C'est un champ de date standard sur l'objet Facture de Salesforce, souvent nommé `DueDate`. Exemples 2023-05-152023-06-302023-07-01
	Montant total de la facture InvoiceTotalAmount	La valeur monétaire totale de la facture.
Descriptionn Cet attribut représente le montant total dû par le client pour les biens ou services rendus. C'est une métrique financière clé associée à chaque cas de facture. L'analyse du Montant Total de la Facture aide à prioriser les factures de grande valeur et à comprendre comment la performance des processus diffère pour les petites par rapport aux grandes transactions. Elle peut être utilisée pour segmenter l'analyse dans les dashboards, par exemple, pour voir si les factures de valeur supérieure ont des temps d'approbation plus longs ou sont payées plus tard. C'est important pour gérer les risques financiers et concentrer efficacement les efforts de recouvrement. Pourquoi est-ce important ? : Cela permet une analyse de l'impact financier, aidant à prioriser les factures de grande valeur et à comprendre comment la valeur monétaire affecte le comportement du processus, tels que les délais d'approbation ou de paiement. Source des données : Ce serait probablement un champ de devise standard sur l'objet Facture, éventuellement nommé `GrandTotal` ou un champ récapitulatif similaire. Exemples 5400.5012500.00850.75
	Service de facturation BillingDepartment	Le service ou l'équipe responsable de l'activité de facturation.
Descriptionn Cet attribut spécifie le groupe fonctionnel, tel que 'Comptes Clients' ou 'Opérations Commerciales', auquel appartient l'utilisateur responsable. Cela est généralement dérivé du profil ou du rôle de l'utilisateur dans Salesforce. L'analyse des performances par département est indispensablele pour comprendre la propriété des processus et identifier les problèmes systémiques au sein d'équipes spécifiques. Elle est utilisée dans les dashboards 'Performance de Réconciliation des Paiements' et 'Charge de Travail et Performance de l'Équipe de Facturation' pour comparer l'efficacité et l'utilisation des ressources dans différentes zones fonctionnelles. Pourquoi est-ce important ? : Cela permet une analyse de la performance au niveau de l'équipe ou du département, aidant à identifier les points de blocage spécifiques au groupe, les contraintes de ressources ou les lacunes en matière de formation. Source des données : Ces informationsns sont généralement stockées sur l'objet Utilisateur dans Salesforce, dans des champs comme `Department` ou `Role.Name`. Exemples Comptes ClientsOpérations financièresÉquipe de recouvrement
	Statut de la facture InvoiceStatus	Le statut actuel de la facture dans son cycle de vie.
Descriptionn Cet attribut reflète l'état actuel de la facture, par exemple 'Brouillon', 'En Attente d'Approbation', 'Envoyée', 'Payée' ou 'Annulée'. Il fournit un aperçu de l'endroit où se trouve la facture dans le processus à un moment donné. Le Statut de la Facture est une dimension majeure pour le filtrage et la segmentation. Il permet aux analystes de se concentrer sur des cohortes spécifiques de factures, telles que toutes les factures en attente de paiement ou toutes les factures rejetées. Cela aide à prioriser le travail et à analyser les caractéristiques des factures qui restent bloquées à certaines étapes. Pourquoi est-ce important ? : Il fournit un aperçu clair de l'état actuel d'une facture, permettant le filtrage et l'analyse des cas ouverts, fermés ou problématiques. Source des données : C'est généralement un champ de liste de sélection (picklist) standard nommé `Status` sur l'objet Facture dans Salesforce. Exemples En attente d'approbationApprouvéEnvoyé au clientPayéPassé en pertes
	Utilisateur Responsable UserResponsible	L'utilisateur ou l'agent qui a effectué l'activité.
Descriptionn Cet attribut identifie l'utilisateur Salesforce spécifique responsable d'une activité donnée, telle que l'approbation d'une facture ou l'enregistrement d'un paiement. Il est souvent lié à l'utilisateur qui a modifié l'enregistrement en dernier ou qui possède la tâche. L'analyse du processus par Utilisateur Responsable est indispensablele pour comprendre la performance de l'équipe, la répartition de la charge de travail et identifier les besoins en formation. Elle contribue directement au le tableau de bord 'Charge de Travail et Performance de l'Équipe de Facturation' en permettant des comparaisons de performance et une analyse de l'allocation des ressources. Elle aide également à l'analyse des causes profondes lors de l'enquête sur les retards ou les erreurs. Pourquoi est-ce important ? : Il permet l'analyse des performances individuelles et d'équipe, l'équilibrage de la charge de travail et aide à identifier les meilleurs collaborateurs les plus performants ou les utilisateurs nécessitant une formation supplémentaire. Source des données : Cela peut être trouvé dans des champs comme `LastModifiedById` sur l'objet Facture ou `OwnerId` sur des objets Tâche ou personnalisés liés. Ces ID devraient être joints à l'objet Utilisateur pour obtenir le nom de l'utilisateur. Exemples Alice JohnsonBob WilliamsCharlie Brown
	Conditions de paiement PaymentTerms	Les conditions de paiement de la facture convenues, telles que 'Net 30' ou 'Dû à la réception'.
Descriptionn Cet attribut définit les règles régissant quand et comment une facture doit être payée. Il dicte souvent le calcul de la Date d'Échéance du Paiement et peut inclure des dispositions pour des escomptes pour paiement anticipé. L'analyse par Conditions de Paiement aide à comprendre comment les différents accords affectent le comportement de paiement. Elle est indispensablele pour le tableau de bord 'Utilisation des Escomptes pour Paiement Anticipé', qui compare les dates de paiement aux conditions pour identifier les opportunités financières manquées. Elle fournit également un contexte expliquant pourquoi certaines factures ont des cycles de paiement plus longs ou plus courts. Pourquoi est-ce important ? : Il fournit un contexte pour les échéances de paiement et est indispensable pour analyser le comportement de paiement, le DSO et l'efficacité des programmes d'escompte pour paiement anticipé. Source des données : Ces informationsns sont probablement stockées dans un champ de liste de sélection (picklist) ou un champ de texte sur l'objet Facture ou l'objet Compte associé dans Salesforce. Exemples Net 30Net 602% 10, Net 30Dû à la réception
	Dernière mise à jour des données LastDataUpdate	Horodatage de la dernière actualisation des données du système source.
Descriptionn Cet attribut indique la date de la dernière extraction des données pour l'analyse de Process Mining depuis Salesforce Sales Cloud. C'est un champ de métadonnées appliqué à l'ensemble du jeu de données lors de chaque rafraîchissement. Cet horodatage est indispensable à que les utilisateurs comprennent la récence de l'analyse. Il les aide à savoir si les dashboards et les KPI qu'ils consultent sont à jour, ce qui est indispensable pour prendre des décisions stratégiques au bon moment et éclairées basées sur les enseignements des processus. Pourquoi est-ce important ? : Informe les utilisateurs sur la pertinence des données, garantissant que les décisions sont basées sur une vue actuelle et pertinente du processus. Source des données : Cette valeur est générée et horodatée sur l'ensemble de données par l'outil ETL ou le pipeline de données lors de chaque exécution. Exemples 2023-10-27T02:00:00Z2023-10-28T02:00:00Z
	Devise de la facture InvoiceCurrency	Le code de devise pour le montant de la facture, tel que USD ou EUR.
Descriptionn Cet attribut indique la devise dans laquelle la facture est libellée. Il est particulièrement important pour les organisations qui opèrent dans plusieurs pays. Ce champ fournit un contexte essentiel pour toute analyse financière. Il permet une agrégation correcte des valeurs monétaires et permet la comparaison des métriques de processus à travers différentes zones monétaires. C'est un filtre nécessaire lors de l'analyse des KPI financiers pour éviter de mélanger différentes devises. Pourquoi est-ce important ? : Fournit le contexte nécessaire à toutes les valeurs monétaires, garantissant une analyse financière et des rapports précis, en particulier dans les opérations multinationales. Source des données : C'est généralement le champ standard `CurrencyIsoCode`, disponible dans les instances Salesforce où la multi-devise est activée. Exemples USDEURGBPJPY
	Est un paiement en retard IsLatePayment	Un indicateur calculé signalant si le paiement a été reçu après la date d'échéance.
Descriptionn Cet attribut booléen est dérivé en comparant l'horodatage 'Paiement Client Reçu' avec la 'Date d'Échéance du Paiement'. Il est vrai si le paiement a été en retard et faux autrement. Ce flag simplifie l'analyse du comportement de paiement et l'efficacité des recouvrements. C'est la base du KPI 'Taux de paiement ponctuel' et aide à segmenter les clients en payeurs à temps et en retard pour une analyse ultérieure. Il fournit un résultat binaire clair pour la performance de paiement sur chaque facture. Pourquoi est-ce important ? : Ceci fournit une métrique de succès claire pour les recouvrements, soutenant directement le KPI 'Taux de paiement ponctuel' et permettant l'analyse des facteurs contribuant aux retards de paiement. Source des données : Cet attribut n'est pas présent dans le système source. Il est calculé dans la couche ETL ou l'outil de Process Mining en comparant la date de paiement au champ `PaymentDueDate`. Exemples truefaux
	Est un reprises IsRework	Un indicateur calculé qui indique si une facture a subi une boucle de reprises.
Descriptionn Cet attribut booléen est dérivé pendant le traitement des données. Il est défini sur vrai si la séquence d'activités d'une facture montre des preuves de reprise, comme un retour à une étape antérieure après l'avoir passée (par exemple, 'Facture Corrigée' après 'Facture Approuvée'). Ce flag est indispensable pour identifier et quantifier rapidement les inefficacités des processus. Il alimente directement le KPI 'Taux de Reprise de Facture' et le tableau de bord 'Reprise et Erreurs du Processus de Facturation', permettant aux analystes d'isoler et d'examiner les cas avec des boucles de reprise coûteuses et chronophages. Pourquoi est-ce important ? : Ce flag quantifie directement l'inefficacité des processus en identifiant les cas avec des boucles de correction, aidant à localiser les sources d'erreurs et à calculer le coût de la mauvaise qualité. Source des données : Cet attribut n'est pas présent dans le système source. Il est calculé par l'outil de Process Mining ou dans la couche ETL basé sur la séquence des activités pour chaque cas. Exemples truefaux
	Heure de fin de l'événement EventEndTime	L'horodatage indiquant quand une activité a été achevée.
Descriptionn Cet attribut enregistre l'heure d'achèvement d'une activité. Bien que de nombreuses activités de facturation soient des événements instantanés où l'heure de début est égale à l'heure de fin, certaines, comme une étape d'approbation, peuvent avoir une durée mesurable. Avoir une Heure de Fin permet le calcul précis du temps de traitement de l'activité, qui est la durée pendant laquelle un agent ou un système travaille activement sur une tâche. Cela aide à différencier le temps de travail actif du temps d'attente, offrant une vue plus détaillée de l'efficacité du processus. Pourquoi est-ce important ? : Il permet le calcul des temps de traitement précis des activités, distinguant le travail actif du temps d'attente inactif pour une analyse d'efficacité plus précise. Source des données : Ce n'est souvent pas un champ standard. Il peut être nécessaire de le dériver en prenant l'heure de début de l'activité suivante dans le cas, ou de le capturer dans un champ personnalisé. Exemples 2023-04-15T10:05:00Z2023-04-16T14:32:10Z2023-05-20T09:05:12Z
	Jours de Vente en Suspens (DSO) DaysSalesOutstanding	Le nombre de jours entre l'envoi de la facture et la réception du paiement.
Descriptionn Le Days Sales Outstanding (DSO) est un indicateur financier critique qui mesure le nombre moyen de jours qu'il faut à une entreprise pour encaisser un paiement après qu'une vente a été effectuée. Il est calculé comme le temps entre l'événement 'Facture envoyée au client' et l'événement 'Paiement client reçu'. Ce KPI est un objectif principal du processus du bon de commande à encaissement, et cet attribut le rend disponible pour chaque facture. Il prend en charge directement le tableau de bord 'Tendance du Days Sales Outstanding (DSO)' et est indispensable pour le suivi et l'amélioration des flux de trésorerie. Pourquoi est-ce important ? : C'est un KPI essentiel pour mesurer l'efficacité du processus de recouvrement et son impact direct sur la trésorerie de l'entreprise. Source des données : Ceci est un attribut calculé. Le calcul est `(Horodatage('Paiement Client Reçu') - Horodatage('Facture envoyée au client'))`. Exemples 32 jours58 jours29 jours
	Nom du client CustomerName	Le nom du client ou du compte facturé.
Descriptionn Cet attribut identifie le client ou l'entreprise à laquelle la facture est émise. Il est généralement lié à l'enregistrement de Compte associé dans Salesforce. L'analyse du processus par client est indispensablele pour comprendre les comportements spécifiques aux clients et identifier les problèmes qui peuvent affecter les comptes clés. Elle peut révéler si certains clients paient systématiquement en retard, nécessitent plus de reprises, ou ont des cycles d'approbation complexes. Cette compréhension aide à gérer les relations clients et à adapter les stratégies de recouvrement. Pourquoi est-ce important ? : Permet une analyse orientée client.ur identifier des schémas, tels que les clients qui paient fréquemment en retard ou nécessitent plus de corrections de facture, améliorant ainsi la gestion de la relation client. Source des données : Ceci est extrait du champ `Account.Name`, lié via une relation de recherche (lookup) de l'objet Facture à l'objet Compte. Exemples ABC CorporationGlobal Tech Inc.Innovate Solutions LLC
	Pays de facturation BillingCountry	Le pays spécifié dans l'adresse de facturation de la facture.
Descriptionn Cet attribut capture le pays de l'adresse de facturation du client. C'est une dimension géographique clé pour segmenter les données de processus. L'analyse du processus de facturation par pays est indispensablele pour identifier les variations régionales en matière de performance, de Conformité et de comportement client. Elle peut révéler si certains pays ont des cycles de paiement plus longs, des taux de reprise différents ou des exigences réglementaires spécifiques qui impactent le processus. Cela soutient l'harmonisation globale des processus et les efforts d'optimisation localisés. Pourquoi est-ce important ? : Permet une analyse géographique pour identifier les variations régionales en matière de performance, d'exigences de conformité et de comportements de paiement. Source des données : Cela fait partie du champ composé d'adresse standard sur l'objet Facture, typiquement `BillingCountry`. Exemples États-UnisAllemagneJaponBrazil
	Propriétaire du compte AccountOwner	Le représentant commercial ou le gestionnaire de compte responsable du compte client.
Descriptionn Cet attribut identifie le propriétaire interne de la relation client. Il s'agit généralement du commercial ou du gestionnaire de compte attribué au Compte dans Salesforce. Bien que non directement impliqué dans la facturation, le Propriétaire du Compte peut être une dimension pertinente pour l'analyse. Les problèmes dans le processus de facturation peuvent impacter la relation client, et cet attribut aide à relier les données de performance du processus à l'aspect commercial de l'entreprise. Il peut être utilisé pour voir si les comptes gérés par certains propriétaires rencontrent plus de problèmes de facturation. Pourquoi est-ce important ? : Établit un lien entre la performance du processus de facturation et le responsable de la relation commerciale, aidant à comprendre l'impact métier des erreurs ou des retards de facturation. Source des données : C'est le champ `Owner.Name` de l'objet Compte, qui est lié à la Facture. Exemples David MillerSophia GarciaJames Wilson
	Système source SourceSystem	Identifie le système d'où proviennent les données.
Descriptionn Cet attribut spécifie l'application source où les données d'événement ont été générées. Pour ce processus, ce sera typiquement 'Salesforce Sales Cloud'. Dans les environnements avec plusieurs systèmes intégrés, ce champ est impératif pour la traçabilité des données et le dépannage. Il aide à comprendre le contexte des données et à s'assurer que les événements de différents systèmes sont correctement fusionnés et interprétés dans l'outil de Process Mining. Pourquoi est-ce important ? : Il fournit un contexte essentiel sur l'origine des données, ce qui est indispensable pour la gouvernance des données, la validation et l'analyse dans les environnements multi-systèmes. Source des données : C'est généralement une valeur statique ajoutée pendant le processus d'extraction, transformation et chargement des données (ETL) pour étiqueter l'origine de l'ensemble de données. Exemples Salesforce Sales CloudSFSC

Obligatoire Recommandé Facultatif

Activités De la commande au paiement - Facturation et encaissement

Ce sont les étapes clés du processus et les jalons à capturer dans votre journal d'événements pour une découverte de processus et une évaluation de la performance précises.

5 Recommandé 8 Facultatif

	Activité	Descriptionn
	Facture approuvée	Un utilisateur autorisé a examiné et approuvé la facture, confirmant son exactitude et sa conformité pour être envoyée au client. Cet événement est généralement capturé lorsque le statut de la facture passe à 'Approuvée'.
Pourquoi est-ce important ? : C'est un jalon clé qui conditionne le reste du processus de facturation. Les retards à ce niveau créent des points de blocage significatifs, impactant le DSO et les temps de cycle globaux, ce qui est mesuré par le tableau de bord 'Temps de Cycle d'Approbation des Factures'. Source des données : Déduit d'un changement du champ de statut de l'objet Facture à 'Approuvée'. Si des Processus d'approbation Salesforce sont utilisés, cela peut être explicitement capturé à partir de l'historique de l'objet ProcessInstance. Capture Changement du champ de statut de facture à 'Approuvée' ou achèvement d'une étape de processus d'approbation formelle. Type d'événement inferred
	Facture clôturée	Le cycle de vie de la facture est terminé, car elle a été entièrement payée et réconciliée. Il s'agit de l'activité finale pour une facture traitée avec succès et est généralement enregistrée par une mise à jour de statut.
Pourquoi est-ce important ? : Cette activité sert de point d'arrivée principal pour le processus, permettant un calcul précis du temps de cycle complet. Elle fournit une définition claire de l'achèvement pour l'analyse des processus. Source des données : Déduit de l'horodatage lorsque le champ de statut de l'objet Facture est mis à jour à 'Clôturée', 'Payée intégralement' ou un état terminal similaire. Capture Changement du champ de statut de facture à une valeur finale 'Clôturée'. Type d'événement inferred
	Facture envoyée au client	La facture approuvée a été officiellement livrée au client par e-mail, courrier ou via un portail. Cet événement est souvent capturé par le remplissage d'un champ 'Date d'Envoi' ou un changement de statut en 'Envoyée'.
Pourquoi est-ce important ? : Ceci marque le début de la période de recouvrement des paiements et est le point de départ pour calculer le Days Sales Outstanding (DSO). C'est un jalon critique pour le suivi de la communication client et des délais de paiement. Source des données : Déduit du remplissage d'un champ 'Date d'envoi' sur l'objet Facture ou d'une mise à jour de statut à 'Envoyée'. Il pourrait également s'agir d'un événement explicite enregistré dans l'historique des activités si envoyé via un outil de messagerie intégré. Capture Horodatage lorsque le champ 'Sent_Date__c' est rempli. Type d'événement inferred
	Facture générée	Cette activité marque la création d'un nouvel enregistrement de facture dans Salesforce. C'est le début officiel du processus de facturation pour une transaction spécifique et elle est généralement déclenchée après l'exécution d'une commande ou l'atteinte d'un jalon contractuel. L'événement est capturé à partir de l'horodatage de création de l'enregistrement de la facture.
Pourquoi est-ce important ? : Ceci est l'événement de démarrage principal pour le processus de facturation. L'analyse du temps écoulé entre ce point et le paiement aide à mesurer le temps de cycle global de l'Order-to-Cash et à identifier les retards initiaux de saisie de données. Source des données : Cet événement est capturé à partir de la date de création (champ CreatedDate) de l'objet personnalisé Facture ou d'un obj« what-if »milaire représentant la facture dans Salesforce. Capture Horodatage de la création de l'enregistrement de l'objet facture. Type d'événement explicit
	Paiement client reçu	Le client a effectué un paiement sur la facture, et les fonds ont été reçus. Cela est généralement enregistré en créant un enregistrement 'Paiement' connexe et en le liant à la facture.
Pourquoi est-ce important ? : C'est le jalon le plus important dans la partie recouvrement de trésorerie du processus. C'est le point final pour le calcul du DSO « what-if »gnifie la réception réussie des revenus. Source des données : Capturé à partir de la date de création d'un enregistrement d'objet personnalisé 'Paiement' lié à l'objet Facture. Il pourrait également être déduit d'un changement de statut de facture à 'Payée'. Capture Création d'un enregistrement de Paiement associé. Type d'événement explicit
	Date d'Échéance de Paiement Atteinte	Ceci est un événement calculé représentant le moment où le paiement de la facture devient dû selon ses conditions de paiement. Ce n'est pas une action utilisateur mais est dérivé des données de la facture.
Pourquoi est-ce important ? : Cette activité fournit un repère critique pour analyser le comportement de paiement et mesurer le KPI 'Taux de paiement ponctuel'. Elle aide à différencier les paiements à temps des paiements en retard. Source des données : Ceci est un événement calculé. Il est dérivé en comparant l'horodatage actuel avec le champ 'Date d'Échéance' de l'objet Facture. Il n'existe pas en tant qu'événement stocké dans Salesforce. Capture Calculé en comparant la date actuelle au champ Date d'échéance de la facture. Type d'événement calculated
	Facture Corrigée	Représente une correction manuelle ou une mise à jour d'une facture après qu'elle ait été rejetée ou qu'une erreur y ait été détectée. Cela est souvent inféré lorsque le statut d'une facture revient à un état antérieur, par exemple de 'Rejetée' à 'Brouillon'.
Pourquoi est-ce important ? : L'identification des boucles de correction est indispensablele pour mesurer le KPI 'Taux de reprises des factures'. Des volumes élevés de corrections indiquent des problèmes dans le processus initial de génération de facture qui entraînent des retards. Source des données : Déduit du suivi de l'historique des champs en détectant un changement de statut d'une valeur ultérieure (par exemple, 'Rejetée', 'Approuvée') vers une valeur antérieure (par exemple, 'Brouillon', 'En cours'). Capture Le statut de la facture recule dans le flux de processus. Type d'événement inferred
	Facture passée en perte	Une décision a été prise d'annuler la dette, et la facture est clôturée sans paiement intégral. Cela représente une fin alternative et infructueuse au processus de facturation.
Pourquoi est-ce important ? : Le suivi des radiations aide à quantifier les pertes de revenus et à identifier les clients ou les situations qui entraînent des créances douteuses. C'est un chemin d'exception critique à surveiller pour la santé financière. Source des données : Déduit de l'horodatage lorsque le champ de statut de l'objet Facture est mis à jour à 'Passée en pertes et profits' ou 'Annulée - Créance irrécouvrable'. Capture Changement du champ de statut de facture à 'Passée en pertes et profits'. Type d'événement inferred
	Facture rejetée	Un approbateur a rejeté la facture, généralement en raison d'erreurs ou de divergences, ce qui nécessite sa correction et sa resoumission. Ceci est capturé par un changement de statut de l'enregistrement de la facture à 'Rejetée'.
Pourquoi est-ce important ? : Cette activité témoigne de reprises et d'inefficacité de processus. L'analyse de la fréquence des rejets aide à identifier les sources d'erreur courantes et soutient l'analyse des causes profondes pour le tableau de bord 'Reprise et Erreurs du Processus de Facturation'. Source des données : Déduit d'un changement du champ de statut de l'objet Facture à 'Rejetée'. Ces données peuvent également être trouvées dans les commentaires dans l'historique d'un Processus d'approbation formel. Capture Changement du champ de statut de facture à 'Rejetée'. Type d'événement inferred
	Facture soumise pour approbation	La facture a été finalisée et soumise à une révision interne avant d'être envoyée au client. Cette activité est généralement capturée par un changement de champ de statut sur l'enregistrement de la facture, par exemple, de 'Brouillon' à 'En Attente d'Approbation'.
Pourquoi est-ce important ? : Le suivi de cette activité aide à isoler le temps passé dans la file d'attente d'approbation. C'est une première étape déterminant pour calculer le KPI 'Temps Moyen d'Approbation des Factures'. Source des données : Déduit du suivi de l'historique des champs sur l'objet Facture lorsqu'un champ de statut est mis à jour à une valeur comme 'Soumise à approbation' ou 'En révision'. Capture Changement du champ de statut de facture à 'En attente d'approbation'. Type d'événement inferred
	Paiement Appliqué/Rapproché	Le paiement reçu a été entièrement rapproché et appliqué à la facture spécifique dans le système, clôturant ainsi la créance. Cela est capturé par un changement de statut final sur l'enregistrement du paiement ou de la facture.
Pourquoi est-ce important ? : Ceci marque la dernière étape du cycle de conversion de la trésorerie. Le tableau de bord 'Performance de Réconciliation des Paiements' s'appuie sur cette activité pour mesurer l'efficacité de l'équipe financière dans l'application des fonds. Source des données : Déduit d'un changement de statut sur l'objet Facture ou un objet Paiement lié à un statut terminal comme 'Rapproché' ou 'Appliqué'. Capture Changement de statut de facture ou de paiement à 'Rapproché'. Type d'événement inferred
	Paiement Comptabilisé dans le Grand Livre	Le paiement reçu a été formellement enregistré dans le système de comptabilité financière ou le grand livre de l'entreprise. Cela peut être capturé via une mise à jour de statut sur l'enregistrement du paiement ou de la facture après l'exécution d'une intégration.
Pourquoi est-ce important ? : Cette activité sépare la réception du paiement de la réconciliation financière. Le temps entre la réception et l'enregistrement du paiement peut mettre en évidence des retards dans les processus comptables internes. Source des données : Déduit d'un changement de champ de statut sur l'objet Paiement ou Facture à une valeur comme 'Comptabilisé' ou 'Exporté vers l'ERP', souvent mis à jour via une intégration API. Capture Changement de statut de paiement ou de facture à 'Comptabilisé'. Type d'événement inferred
	Rappel de Paiement Émis	Une communication a été envoyée au client pour lui rappeler un paiement à venir ou en retard. Ceci est souvent enregistré comme une activité spécifique (Tâche ou E-mail) liée à la facture.
Pourquoi est-ce important ? : Le suivi des rappels aide à évaluer l'efficacité des stratégies de recouvrement. C'est indispensable pour le tableau de bord 'Efficacité des Rappels de Paiement' et le KPI 'Taux de Déclenchement des Rappels de Paiement'. Source des données : Capturé à partir de la création d'un enregistrement d'activité (Tâche ou E-mail) lié à l'objet Facture, où le sujet ou le type indique qu'il s'agit d'un rappel de paiement. Capture Création d'un enregistrement de Tâche ou d'E-mail associé avec un type/sujet spécifique. Type d'événement explicit

Recommandé Facultatif

Guides d'extraction

Comment obtenir vos `données` depuis `Salesforce Sales Cloud`

Étapes

Vérification des prérequis: Assurez-vous de disposer des permissions nécessaires dans Salesforce, notamment "Exécuter des rapports", "Créer et personnaliser des rapports" et "Exporter des rapports". Vérifiez que le Suivi de l'historique des champs est activé pour les champs de statut clés de vos objets Facture et Paiement. Pour ce faire, naviguez vers Configuration > Gestionnaire d'objets, trouvez l'objet pertinent, allez dans Champs et Relations, puis cliquez sur "Définir le suivi de l'historique".
Définir la stratégie de rapport: Ce processus nécessite la création de plusieurs rapports car les activités proviennent de différents enregistrements ou événements (par exemple, création de facture, changements de statut, paiements associés). Vous créerez un rapport distinct pour chaque source et combinerez ensuite les résultats en externe.
Créer un rapport pour les créations d'enregistrements: Commencez par les événements les plus simples. Créez un rapport pour 'Facture générée' et 'Paiement client reçu'. Naviguez vers l'onglet Rapports et cliquez sur "Nouveau rapport". Choisissez un type de rapport qui inclut votre objet Facture (par exemple, "Factures") ou votre objet Paiement. Ajoutez les colonnes correspondant aux attributs du journal d'événements. Pour l'activité 'Facture générée', la CreatedDate de l'enregistrement de la facture sera l'(EventTime).
Créer un rapport pour l'historique des champs: Pour capturer les changements de statut comme 'Facture soumise à approbation', 'Facture approuvée', 'Facture rejetée' et 'Facture corrigée', créez un rapport basé sur le type de rapport "Historique des factures". Ce type de rapport spécial expose les changements suivis par le Suivi de l'historique des champs. Vous filtrerez ce rapport pour les changements du champ Statut.
Créer un rapport pour les événements basés sur la date: Pour des événements comme 'Facture envoyée au client' ou 'Date d'échéance du paiement atteinte', créez un rapport sur l'objet Facture. Utilisez les champs de date eux-mêmes, tels que Sent_Date__c ou Payment_Due_Date__c, comme (EventTime). Vous devez filtrer les enregistrements où ces dates ne sont pas nulles.
Créer un rapport pour les activités liées: Pour des événements comme 'Rappel de paiement émis', vous avez besoin d'un rapport qui lie les Activités (Tâches ou Événements) aux Factures. Utilisez un type de rapport comme "Activités avec les factures" ou un type personnalisé que vous créez. Filtrez les activités avec un sujet ou un type spécifique qui indique un rappel.
Ajouter des colonnes standard à tous les rapports: Dans chaque rapport que vous créez, assurez-vous d'ajouter des colonnes qui peuvent être associées à la structure requise du journal d'événements : InvoiceNumber, un champ pour l'(EventTime) (comme CreatedDate ou la date du changement de champ), UserResponsible (comme LastModifiedById), et d'autres attributs recommandés.
Exporter les rapports au format CSV: Exécutez chaque rapport individuellement. À partir de l'écran des résultats du rapport, utilisez le menu déroulant pour sélectionner "Exporter" et choisissez le format "Détails seulement" avec une extension .csv. Répétez cette opération pour tous les rapports que vous avez créés.
Combiner et transformer les données: Ouvrez les fichiers CSV exportés dans un programme de feuille de calcul ou utilisez un outil de prélèvement.paration de données. Pour chaque fichier, ajoutez une nouvelle colonne nommée (ActivityName) et remplissez-la avec l'activité spécifique qu'elle représente (par exemple, "Facture générée" pour toutes les lignes du premier rapport). Mappez les colonnes source (par exemple, Facture: Date de création) aux en-têtes standard du journal d'événements ((EventTime)).
Créer le journal d'événements final: Consolidez toutes les données transformées des fichiers CSV individuels dans un seul fichier maître. Assurez-vous que les en-têtes de colonne sont exactement InvoiceNumber, (ActivityName), (EventTime), UserResponsible, etc. Ce fichier unifié est votre journal d'événements final.
Formatage final: Enregistrez le fichier consolidé au format CSV avec l'encodage UTF-8. Le fichier est maintenant prêt à être téléchargé sur ProcessMind.

Configuration

Types de rapports: Vous aurez probablement besoin de plusieurs types de rapports personnalisés pour lier des objets parents comme Compte à des objets enfants et petits-enfants comme Facture, Paiement et Activité. Créez-les dans Configuration > Types de rapports.
Suivi de l'historique des champs: C'est indispensable. Pour l'objet Facture, activez le suivi de l'historique pour tout champ Statut. Sans cela, vous ne pourrez pas capturer les activités de changement de statut comme 'Approuvée' ou 'Rejetée'. L'historique n'est pas suivi rétroactivement.
Filtres de données: Appliquez toujours un filtre de date à vos rapports pour maintenir le volume de données gérable. Une bonne pratique consiste à filtrer la date de création de l'objet principal pour les 3 à 6 derniers mois (par exemple, Facture: Date de création égale LAST 180 DAYS).
Service d'exportation de données: Comme alternative à l'exécution de rapports individuels, vous pouvez utiliser le Service d'exportation de données natif (Configuration > Exportation de données). Ce service exporte toutes les données de votre organisation sur une base hebdomadaire ou mensuelle. Cela fournit une sauvegarde complète mais nécessite un post-traitement important pour filtrer, joindre et transformer les données en un journal d'événements.
Autorisations utilisateur: L'utilisateur effectuant l'extraction a besoin d'un accès en lecture à tous les objets pertinents (par exemple, Compte, Commande, Invoice__c, Payment__c, Activité) et champs, en plus des permissions de création et d'exportation de rapports.

a Exemple de requête config

// This is a configuration guide for building multiple Salesforce reports.
// The data from these separate CSV exports must be manually combined and transformed into a single event log.

// Report 1: Invoice Generated
// Report Type: Invoices (or your custom invoice object report type)
// Filters: 
// 1. Created Date GREATER OR EQUAL [Start Date]
// 2. Created Date LESS OR EQUAL [End Date]
// Columns to Export & Map:
// - Invoice Number -> InvoiceNumber
// - 'Invoice Generated' (static text) -> ActivityName
// - Created Date -> EventTime
// - Created By -> UserResponsible
// - [Billing Department Field] -> BillingDepartment
// - Status -> InvoiceStatus
// - Total Amount -> InvoiceTotalAmount
// - Payment Due Date -> PaymentDueDate

// Report 2: Invoice Status Changes (Submitted, Approved, Rejected, Corrected, Closed, Written Off)
// Report Type: Invoice History (or your custom object's history report type)
// Filters:
// 1. Edit Date GREATER OR EQUAL [Start Date]
// 2. Edit Date LESS OR EQUAL [End Date]
// 3. Field/Event EQUALS 'Status' (or the name of your status field)
// Columns to Export & Map:
// - Invoice Number -> InvoiceNumber
// - New Value (transformed*) -> ActivityName 
// - Edit Date -> EventTime
// - Edited By -> UserResponsible
// - [Billing Department Field] -> BillingDepartment
// - New Value -> InvoiceStatus
// - [Invoice Total Amount] -> InvoiceTotalAmount
// - [Invoice Payment Due Date] -> PaymentDueDate
// *Transformation Logic for ActivityName: 
//   - IF New Value = 'Pending Approval' THEN 'Invoice Submitted for Approval'
//   - IF New Value = 'Approved' THEN 'Invoice Approved'
//   - IF New Value = 'Rejected' THEN 'Invoice Rejected'
//   - IF New Value = 'Draft' AND Old Value = 'Rejected' THEN 'Invoice Corrected'
//   - IF New Value = 'Closed' THEN 'Invoice Closed'
//   - IF New Value = 'Written Off' THEN 'Invoice Written Off'

// Report 3: Invoice Sent to Customer
// Report Type: Invoices
// Filters:
// 1. [Sent Date Field] NOT EQUAL TO "" (not null)
// 2. [Sent Date Field] GREATER OR EQUAL [Start Date]
// 3. [Sent Date Field] LESS OR EQUAL [End Date]
// Columns to Export & Map:
// - Invoice Number -> InvoiceNumber
// - 'Invoice Sent to Customer' (static text) -> ActivityName
// - [Sent Date Field] -> EventTime
// - Last Modified By -> UserResponsible
// - [Billing Department Field] -> BillingDepartment
// - Status -> InvoiceStatus
// - Total Amount -> InvoiceTotalAmount
// - Payment Due Date -> PaymentDueDate

// Report 4: Payment Due Date Reached
// Report Type: Invoices
// Filters:
// 1. Payment Due Date NOT EQUAL TO "" (not null)
// 2. Payment Due Date GREATER OR EQUAL [Start Date]
// 3. Payment Due Date LESS OR EQUAL [End Date]
// Columns to Export & Map:
// - Invoice Number -> InvoiceNumber
// - 'Payment Due Date Reached' (static text) -> ActivityName
// - Payment Due Date -> EventTime
// - 'System' (static text) -> UserResponsible
// - [Billing Department Field] -> BillingDepartment
// - Status -> InvoiceStatus
// - Total Amount -> InvoiceTotalAmount
// - Payment Due Date -> PaymentDueDate

// Report 5: Payment Reminder Issued
// Report Type: Activities with Invoices (or similar custom report type)
// Filters:
// 1. Task or Event Subject CONTAINS 'Payment Reminder'
// 2. Created Date GREATER OR EQUAL [Start Date]
// 3. Created Date LESS OR EQUAL [End Date]
// Columns to Export & Map:
// - Invoice: Invoice Number -> InvoiceNumber
// - 'Payment Reminder Issued' (static text) -> ActivityName
// - Created Date -> EventTime
// - Assigned To -> UserResponsible
// - [Billing Department Field] -> BillingDepartment
// - [Invoice Status Field] -> InvoiceStatus
// - [Invoice Total Amount] -> InvoiceTotalAmount
// - [Invoice Payment Due Date] -> PaymentDueDate

// Report 6: Customer Payment Received & Status Changes (Posted, Applied)
// Report Type: Payments with Invoices (or similar custom report type)
// This report combines multiple events from the Payment record.
// Filters:
// 1. Payment: Created Date GREATER OR EQUAL [Start Date]
// 2. Payment: Created Date LESS OR EQUAL [End Date]
// Part A: Payment Received
// Columns to Export & Map:
// - Invoice: Invoice Number -> InvoiceNumber
// - 'Customer Payment Received' (static text) -> ActivityName
// - Payment: Created Date -> EventTime
// - Payment: Created By -> UserResponsible
// Part B: Payment Posted and Applied (Requires exporting and transforming multiple rows for the same payment if status changes)
// You may need a separate Payment History Report, similar to Report 2.
// Assuming a simple status field on the Payment for this example:
//   - IF Payment Status = 'Posted' THEN 'Payment Posted to Ledger'
//   - IF Payment Status = 'Applied' THEN 'Cash Applied/Reconciled'

Étapes

Prérequis et configuration : Assurez-vous que Python 3.6 ou une version plus récente est installé sur votre système. Installez les bibliothèques nécessaires en exécutant la commande suivante dans votre terminal : pip install simple-salesforce pandas. Vous aurez également besoin de votre identifiant Salesforce, de votre mot de passe et de votre jeton de sécurité. Pour obtenir ce jeton, connectez-vous à Salesforce, accédez à vos paramètres personnels et recherchez l'option « Réinitialiser mon jeton de sécurité ».
Activer le suivi de l'historique des champs : Connectez-vous à votre organisation Salesforce en tant qu'administrateur. Accédez à la Configuration, puis au Gestionnaire d'objet. Recherchez votre objet Facture principal, par exemple Invoice__c, et allez dans « Champs et relations ». Cliquez sur « Définir le suivi de l'historique ». Activez le suivi pour le champ représentant le statut de la facture, par exemple Status__c. Répétez l'opération pour votre objet Paiement, par exemple Payment__c, et son champ de statut correspondant.
Téléchargement et configuration du script : Enregistrez le script Python fourni sous le nom extract_invoices.py. Ouvrez le fichier dans un éditeur de texte et mettez à jour les valeurs de remplacement dans la section « Salesforce Credentials and Settings ». Vous devez renseigner vos variables SF_USERNAME, SF_PASSWORD, SF_SECURITY_TOKEN et SF_INSTANCE_URL. Ajustez les dates START_DATE et END_DATE pour définir la période d'extraction.
Personnalisation des noms d'objets et de champs : Examinez attentivement les requêtes SOQL du script. Le script utilise des noms génériques comme Invoice__c, Payment__c, Status__c, Total_Amount__c, etc. Vous devez remplacer ces éléments par les noms d'API réels des objets et des champs utilisés dans votre instance Salesforce pour la facturation.
Exécution du script d'extraction : Ouvrez un terminal ou une invite de commande, accédez au répertoire où vous avez enregistré le script, et lancez-le avec la commande : python extract_invoices.py. Le script se connectera à l'API Salesforce, exécutera les requêtes et traitera les données.
Suivi de la progression du script : Le script affichera des messages d'état dans la console au fur et à mesure de la récupération et du traitement des données pour chaque type d'activité. Selon le volume de données et vos limites d'API, cela peut prendre un certain temps. Surveillez les messages d'erreur qui pourraient indiquer des identifiants incorrects ou des noms d'API erronés.
Vérification du fichier de sortie : Une fois l'exécution terminée, le script générera un fichier nommé salesforce_billing_event_log.csv dans le même répertoire. Ouvrez ce fichier CSV avec un tableur pour vérifier son contenu et vous assurer qu'il contient les données attendues.
Préparation pour l'importation : Le fichier CSV généré est structuré avec les colonnes requises : InvoiceNumber, (ActivityName) et (EventTime), ainsi que d'autres attributs recommandés. Ce fichier est prêt à être chargé directement dans l'outil de Process Mining sans formatage supplémentaire.

Configuration

Identifiants Salesforce: Vous devez fournir votre nom d'utilisateur Salesforce, votre mot de passe et votre jeton de sécurité. Le jeton de sécurité est requis pour l'accès API depuis l'extérieur des plages d'adresses IP de confiance de votre organisation.
URL de l'instance Salesforce: Spécifiez le domaine de votre instance Salesforce, tel que your_instance.my.salesforce.com. Si vous utilisez une sandbox, l'URL sera différente, par exemple, test.salesforce.com.
Filtres de plage de dates: Le script inclut les variables START_DATE et END_DATE. Il est recommandé de commencer par une plage de dates plus petite, telle que 3 à 6 mois, pour gérer le volume de données et rester dans les limites de l'API. Ces dates filtrent la requête initiale pour les dates de création de facture.
Noms API des objets et champs: Le script est construit avec des noms API de substitution pour les objets et les champs, par exemple, Invoice__c et Status__c. Vous devez les remplacer par les noms API exacts de votre modèle de données Salesforce. Ceux-ci se trouvent dans Configuration Salesforce sous Gestionnaire d'objets.
Prérequis pour le suivi: La précision du journal d'événements, en particulier pour les changements de statut, dépend entièrement de l'activation du suivi de l'historique des champs de Salesforce pour les champs pertinents avant que les transactions ne se produisent. S'il n'était pas activé, les changements historiques ne seront pas capturés.
Limites d'appels API: Salesforce applique des limites de gouverneur sur le nombre d'appels API que vous pouvez effectuer sur une période de 24 heures. Pour de très grands ensembles de données, envisagez d'exécuter l'extraction par lots de plages de dates plus petites ou de la planifier pendant les heures creuses pour éviter d'atteindre ces limites.

a Exemple de requête python

import pandas as pd
from simple_salesforce import Salesforce
from datetime import datetime

class=class="hl-string">"hl-comment"># --- Salesforce Credentials and Settings ---
class=class="hl-string">"hl-comment"># IMPORTANT: Replace all placeholder values with your actual Salesforce information.
SF_USERNAME = class="hl-string">'[your_salesforce_username]'
SF_PASSWORD = class="hl-string">'[your_salesforce_password]'
SF_SECURITY_TOKEN = class="hl-string">'[your_salesforce_security_token]' class=class="hl-string">"hl-comment"># Append this to your password if required
SF_INSTANCE_URL = class="hl-string">'https://[your_instance].my.salesforce.com' class=class="hl-string">"hl-comment"># e.g., na1.salesforce.com

class=class="hl-string">"hl-comment"># --- Extraction Period ---
START_DATE = class="hl-string">'2023-01-01T00:00:00Z'
END_DATE = class="hl-string">'2023-12-31T23:59:59Z'

class=class="hl-string">"hl-comment"># --- Object and Field API Name Placeholders ---
class=class="hl-string">"hl-comment"># Replace these with the actual API names from your Salesforce org.
INVOICE_OBJECT = class="hl-string">'Invoice__c'
INVOICE_NUMBER_FIELD = class="hl-string">'Name'
INVOICE_STATUS_FIELD = class="hl-string">'Status__c'
INVOICE_TOTAL_AMOUNT_FIELD = class="hl-string">'Total_Amount__c'
INVOICE_DUE_DATE_FIELD = class="hl-string">'Due_Date__c'

PAYMENT_OBJECT = class="hl-string">'Payment__c'
PAYMENT_INVOICE_LOOKUP_FIELD = class="hl-string">'Invoice__c' class=class="hl-string">"hl-comment"># Lookup field from Payment to Invoice
PAYMENT_STATUS_FIELD = class="hl-string">'Status__c'

class=class="hl-string">"hl-comment"># --- Main Script ---
def main():
    print(class="hl-string">"Connecting to Salesforce...")
    sf = Salesforce(username=SF_USERNAME, password=SF_PASSWORD, security_token=SF_SECURITY_TOKEN, instance_url=SF_INSTANCE_URL)
    print(class="hl-string">"Connection successful.")

    all_events = []

    class=class="hl-string">"hl-comment"># 1. Get base Invoice data
    print(class="hl-string">"Fetching base invoice data...")
    soql_invoices = fclass="hl-string">"""
        SELECT Id, {INVOICE_NUMBER_FIELD}, CreatedDate, CreatedById, LastModifiedById, 
               {INVOICE_STATUS_FIELD}, {INVOICE_TOTAL_AMOUNT_FIELD}, {INVOICE_DUE_DATE_FIELD}
        FROM {INVOICE_OBJECT}
        WHERE CreatedDate >= {START_DATE} AND CreatedDate <= {END_DATE}
    """
    invoices_data = sf.query_all(soql_invoices)[class="hl-string">'records']
    df_invoices = pd.DataFrame(invoices_data).drop(columns=[class="hl-string">'attributes'])
    invoice_ids = class="hl-string">"','".join(df_invoices[class="hl-string">'Id'].tolist())

    class=class="hl-string">"hl-comment"># Activity: Invoice Generated & Payment Due Date Reached
    print(class="hl-string">"Processing 'Invoice Generated' and 'Payment Due Date Reached' events...")
    generated_events = df_invoices.copy()
    generated_events[class="hl-string">'ActivityName'] = class="hl-string">'Invoice Generated'
    generated_events[class="hl-string">'EventTime'] = pd.to_datetime(generated_events[class="hl-string">'CreatedDate']).dt.tz_localize(None)
    generated_events[class="hl-string">'UserResponsible'] = generated_events[class="hl-string">'CreatedById']
    all_events.append(generated_events)

    due_date_events = df_invoices[df_invoices[INVOICE_DUE_DATE_FIELD].notna()].copy()
    due_date_events[class="hl-string">'ActivityName'] = class="hl-string">'Payment Due Date Reached'
    due_date_events[class="hl-string">'EventTime'] = pd.to_datetime(due_date_events[INVOICE_DUE_DATE_FIELD]).dt.tz_localize(None)
    due_date_events[class="hl-string">'UserResponsible'] = None class=class="hl-string">"hl-comment"># System-generated event
    all_events.append(due_date_events)

    class=class="hl-string">"hl-comment"># 2. Get Invoice Status Changes from Field History
    print(class="hl-string">"Fetching invoice status changes...")
    soql_invoice_history = fclass="hl-string">"""
        SELECT ParentId, Field, OldValue, NewValue, CreatedDate, CreatedById
        FROM {INVOICE_OBJECT}History
        WHERE ParentId IN ('{invoice_ids}') AND Field = '{INVOICE_STATUS_FIELD}'
    """
    invoice_history_data = sf.query_all(soql_invoice_history)[class="hl-string">'records']
    if invoice_history_data:
        df_invoice_history = pd.DataFrame(invoice_history_data).drop(columns=[class="hl-string">'attributes'])
        df_invoice_history = df_invoice_history.merge(df_invoices[[class="hl-string">'Id', INVOICE_NUMBER_FIELD, INVOICE_TOTAL_AMOUNT_FIELD, INVOICE_DUE_DATE_FIELD]], left_on=class="hl-string">'ParentId', right_on=class="hl-string">'Id')
        df_invoice_history[class="hl-string">'EventTime'] = pd.to_datetime(df_invoice_history[class="hl-string">'CreatedDate']).dt.tz_localize(None)
        df_invoice_history[class="hl-string">'UserResponsible'] = df_invoice_history[class="hl-string">'CreatedById']

        class=class="hl-string">"hl-comment"># Map status changes to Activity Names
        status_map = {
            (class="hl-string">'Draft', class="hl-string">'Pending Approval'): class="hl-string">'Invoice Submitted for Approval',
            (class="hl-string">'Pending Approval', class="hl-string">'Approved'): class="hl-string">'Invoice Approved',
            (class="hl-string">'Pending Approval', class="hl-string">'Rejected'): class="hl-string">'Invoice Rejected',
            (class="hl-string">'Rejected', class="hl-string">'Draft'): class="hl-string">'Invoice Corrected',
            (class="hl-string">'Approved', class="hl-string">'Sent'): class="hl-string">'Invoice Sent to Customer',
            (class="hl-string">'Approved', class="hl-string">'Closed'): class="hl-string">'Invoice Closed',
            (class="hl-string">'Sent', class="hl-string">'Closed'): class="hl-string">'Invoice Closed',
            (class="hl-string">'Approved', class="hl-string">'Written Off'): class="hl-string">'Invoice Written Off'
        }
        df_invoice_history[class="hl-string">'ActivityName'] = df_invoice_history.apply(lambda row: status_map.get((str(row[class="hl-string">'OldValue']), str(row[class="hl-string">'NewValue']))), axis=1)
        df_invoice_history.rename(columns={class="hl-string">'NewValue': INVOICE_STATUS_FIELD}, inplace=True)
        all_events.append(df_invoice_history.dropna(subset=[class="hl-string">'ActivityName']))

    class=class="hl-string">"hl-comment"># 3. Get Payment Reminders from Tasks
    print(class="hl-string">"Fetching payment reminder tasks...")
    soql_tasks = fclass="hl-string">"""
        SELECT WhatId, ActivityDate, CreatedById, CreatedDate
        FROM Task
        WHERE WhatId IN ('{invoice_ids}') AND Subject LIKE '%Payment Reminder%'
    """
    task_data = sf.query_all(soql_tasks)[class="hl-string">'records']
    if task_data:
        df_tasks = pd.DataFrame(task_data).drop(columns=[class="hl-string">'attributes'])
        df_tasks = df_tasks.merge(df_invoices[[class="hl-string">'Id', INVOICE_NUMBER_FIELD, INVOICE_STATUS_FIELD, INVOICE_TOTAL_AMOUNT_FIELD, INVOICE_DUE_DATE_FIELD]], left_on=class="hl-string">'WhatId', right_on=class="hl-string">'Id')
        df_tasks[class="hl-string">'ActivityName'] = class="hl-string">'Payment Reminder Issued'
        df_tasks[class="hl-string">'EventTime'] = pd.to_datetime(df_tasks[class="hl-string">'CreatedDate']).dt.tz_localize(None)
        df_tasks[class="hl-string">'UserResponsible'] = df_tasks[class="hl-string">'CreatedById']
        all_events.append(df_tasks)

    class=class="hl-string">"hl-comment"># 4. Get Payment Data
    print(class="hl-string">"Fetching payment data...")
    soql_payments = fclass="hl-string">"""
        SELECT Id, {PAYMENT_INVOICE_LOOKUP_FIELD}, CreatedDate, CreatedById, LastModifiedById, {PAYMENT_STATUS_FIELD}
        FROM {PAYMENT_OBJECT}
        WHERE {PAYMENT_INVOICE_LOOKUP_FIELD} IN ('{invoice_ids}')
    """
    payment_data = sf.query_all(soql_payments)[class="hl-string">'records']
    if payment_data:
        df_payments = pd.DataFrame(payment_data).drop(columns=[class="hl-string">'attributes'])
        df_payments = df_payments.merge(df_invoices[[class="hl-string">'Id', INVOICE_NUMBER_FIELD, INVOICE_TOTAL_AMOUNT_FIELD, INVOICE_DUE_DATE_FIELD]], left_on=PAYMENT_INVOICE_LOOKUP_FIELD, right_on=class="hl-string">'Id', suffixes=(class="hl-string">'_payment', class="hl-string">'_invoice'))
        payment_ids = class="hl-string">"','".join(df_payments[class="hl-string">'Id_payment'].tolist())
        
        class=class="hl-string">"hl-comment"># Activity: Customer Payment Received
        payment_received_events = df_payments.copy()
        payment_received_events[class="hl-string">'ActivityName'] = class="hl-string">'Customer Payment Received'
        payment_received_events[class="hl-string">'EventTime'] = pd.to_datetime(payment_received_events[class="hl-string">'CreatedDate']).dt.tz_localize(None)
        payment_received_events[class="hl-string">'UserResponsible'] = payment_received_events[class="hl-string">'CreatedById']
        all_events.append(payment_received_events)
        
        class=class="hl-string">"hl-comment"># 5. Get Payment Status Changes
        print(class="hl-string">"Fetching payment status changes...")
        soql_payment_history = fclass="hl-string">"""
            SELECT ParentId, Field, OldValue, NewValue, CreatedDate, CreatedById
            FROM {PAYMENT_OBJECT}History
            WHERE ParentId IN ('{payment_ids}') AND Field = '{PAYMENT_STATUS_FIELD}'
        """
        payment_history_data = sf.query_all(soql_payment_history)[class="hl-string">'records']
        if payment_history_data:
            df_payment_history = pd.DataFrame(payment_history_data).drop(columns=[class="hl-string">'attributes'])
            df_payment_history = df_payment_history.merge(df_payments[[class="hl-string">'Id_payment', INVOICE_NUMBER_FIELD, INVOICE_TOTAL_AMOUNT_FIELD, INVOICE_DUE_DATE_FIELD]], left_on=class="hl-string">'ParentId', right_on=class="hl-string">'Id_payment')
            df_payment_history[class="hl-string">'EventTime'] = pd.to_datetime(df_payment_history[class="hl-string">'CreatedDate']).dt.tz_localize(None)
            df_payment_history[class="hl-string">'UserResponsible'] = df_payment_history[class="hl-string">'CreatedById']

            payment_status_map = {
                (class="hl-string">'Received', class="hl-string">'Posted'): class="hl-string">'Payment Posted to Ledger',
                (class="hl-string">'Posted', class="hl-string">'Reconciled'): class="hl-string">'Cash Applied/Reconciled'
            }
            df_payment_history[class="hl-string">'ActivityName'] = df_payment_history.apply(lambda row: payment_status_map.get((str(row[class="hl-string">'OldValue']), str(row[class="hl-string">'NewValue']))), axis=1)
            df_payment_history.rename(columns={class="hl-string">'NewValue': INVOICE_STATUS_FIELD}, inplace=True)
            all_events.append(df_payment_history.dropna(subset=[class="hl-string">'ActivityName']))

    class=class="hl-string">"hl-comment"># --- Final Assembly ---
    print(class="hl-string">"Assembling final event log...")
    final_df = pd.concat(all_events, ignore_index=True)

    class=class="hl-string">"hl-comment"># Standardize column names
    final_df.rename(columns={
        INVOICE_NUMBER_FIELD: class="hl-string">'InvoiceNumber',
        INVOICE_STATUS_FIELD: class="hl-string">'InvoiceStatus',
        INVOICE_TOTAL_AMOUNT_FIELD: class="hl-string">'InvoiceTotalAmount',
        INVOICE_DUE_DATE_FIELD: class="hl-string">'PaymentDueDate'
    }, inplace=True)

    class=class="hl-string">"hl-comment"># Select and order columns for the final event log
    required_cols = {
        class="hl-string">'InvoiceNumber': None,
        class="hl-string">'ActivityName': None,
        class="hl-string">'EventTime': None,
        class="hl-string">'UserResponsible': None,
        class="hl-string">'InvoiceStatus': None,
        class="hl-string">'InvoiceTotalAmount': None,
        class="hl-string">'PaymentDueDate': None
    }
    for col in required_cols:
        if col not in final_df.columns:
            final_df[col] = required_cols[col]
    
    class=class="hl-string">"hl-comment"># We cannot extract Billing Department directly from this model, so we will add it as an empty column
    final_df[class="hl-string">'BillingDepartment'] = None

    final_df = final_df[list(required_cols.keys()) + [class="hl-string">'BillingDepartment']]

    class=class="hl-string">"hl-comment"># Sort by case and event time
    final_df.sort_values(by=[class="hl-string">'InvoiceNumber', class="hl-string">'EventTime'], inplace=True)

    class=class="hl-string">"hl-comment"># Save to CSV
    output_filename = class="hl-string">'salesforce_billing_event_log.csv'
    final_df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%S.%f')
    print(fclass="hl-string">"Event log saved to {output_filename}")

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

Étapes

Vérification des prérequis: Assurez-vous de disposer des permissions nécessaires dans Salesforce, notamment "Exécuter des rapports", "Créer et personnaliser des rapports" et "Exporter des rapports". Vérifiez que le Suivi de l'historique des champs est activé pour les champs de statut clés de vos objets Facture et Paiement. Pour ce faire, naviguez vers Configuration > Gestionnaire d'objets, trouvez l'objet pertinent, allez dans Champs et Relations, puis cliquez sur "Définir le suivi de l'historique".
Définir la stratégie de rapport: Ce processus nécessite la création de plusieurs rapports car les activités proviennent de différents enregistrements ou événements (par exemple, création de facture, changements de statut, paiements associés). Vous créerez un rapport distinct pour chaque source et combinerez ensuite les résultats en externe.
Créer un rapport pour les créations d'enregistrements: Commencez par les événements les plus simples. Créez un rapport pour 'Facture générée' et 'Paiement client reçu'. Naviguez vers l'onglet Rapports et cliquez sur "Nouveau rapport". Choisissez un type de rapport qui inclut votre objet Facture (par exemple, "Factures") ou votre objet Paiement. Ajoutez les colonnes correspondant aux attributs du journal d'événements. Pour l'activité 'Facture générée', la CreatedDate de l'enregistrement de la facture sera l'(EventTime).
Créer un rapport pour l'historique des champs: Pour capturer les changements de statut comme 'Facture soumise à approbation', 'Facture approuvée', 'Facture rejetée' et 'Facture corrigée', créez un rapport basé sur le type de rapport "Historique des factures". Ce type de rapport spécial expose les changements suivis par le Suivi de l'historique des champs. Vous filtrerez ce rapport pour les changements du champ Statut.
Créer un rapport pour les événements basés sur la date: Pour des événements comme 'Facture envoyée au client' ou 'Date d'échéance du paiement atteinte', créez un rapport sur l'objet Facture. Utilisez les champs de date eux-mêmes, tels que Sent_Date__c ou Payment_Due_Date__c, comme (EventTime). Vous devez filtrer les enregistrements où ces dates ne sont pas nulles.
Créer un rapport pour les activités liées: Pour des événements comme 'Rappel de paiement émis', vous avez besoin d'un rapport qui lie les Activités (Tâches ou Événements) aux Factures. Utilisez un type de rapport comme "Activités avec les factures" ou un type personnalisé que vous créez. Filtrez les activités avec un sujet ou un type spécifique qui indique un rappel.
Ajouter des colonnes standard à tous les rapports: Dans chaque rapport que vous créez, assurez-vous d'ajouter des colonnes qui peuvent être associées à la structure requise du journal d'événements : InvoiceNumber, un champ pour l'(EventTime) (comme CreatedDate ou la date du changement de champ), UserResponsible (comme LastModifiedById), et d'autres attributs recommandés.
Exporter les rapports au format CSV: Exécutez chaque rapport individuellement. À partir de l'écran des résultats du rapport, utilisez le menu déroulant pour sélectionner "Exporter" et choisissez le format "Détails seulement" avec une extension .csv. Répétez cette opération pour tous les rapports que vous avez créés.
Combiner et transformer les données: Ouvrez les fichiers CSV exportés dans un programme de feuille de calcul ou utilisez un outil de prélèvement.paration de données. Pour chaque fichier, ajoutez une nouvelle colonne nommée (ActivityName) et remplissez-la avec l'activité spécifique qu'elle représente (par exemple, "Facture générée" pour toutes les lignes du premier rapport). Mappez les colonnes source (par exemple, Facture: Date de création) aux en-têtes standard du journal d'événements ((EventTime)).
Créer le journal d'événements final: Consolidez toutes les données transformées des fichiers CSV individuels dans un seul fichier maître. Assurez-vous que les en-têtes de colonne sont exactement InvoiceNumber, (ActivityName), (EventTime), UserResponsible, etc. Ce fichier unifié est votre journal d'événements final.
Formatage final: Enregistrez le fichier consolidé au format CSV avec l'encodage UTF-8. Le fichier est maintenant prêt à être téléchargé sur ProcessMind.

Configuration

Types de rapports: Vous aurez probablement besoin de plusieurs types de rapports personnalisés pour lier des objets parents comme Compte à des objets enfants et petits-enfants comme Facture, Paiement et Activité. Créez-les dans Configuration > Types de rapports.
Suivi de l'historique des champs: C'est indispensable. Pour l'objet Facture, activez le suivi de l'historique pour tout champ Statut. Sans cela, vous ne pourrez pas capturer les activités de changement de statut comme 'Approuvée' ou 'Rejetée'. L'historique n'est pas suivi rétroactivement.
Filtres de données: Appliquez toujours un filtre de date à vos rapports pour maintenir le volume de données gérable. Une bonne pratique consiste à filtrer la date de création de l'objet principal pour les 3 à 6 derniers mois (par exemple, Facture: Date de création égale LAST 180 DAYS).
Service d'exportation de données: Comme alternative à l'exécution de rapports individuels, vous pouvez utiliser le Service d'exportation de données natif (Configuration > Exportation de données). Ce service exporte toutes les données de votre organisation sur une base hebdomadaire ou mensuelle. Cela fournit une sauvegarde complète mais nécessite un post-traitement important pour filtrer, joindre et transformer les données en un journal d'événements.
Autorisations utilisateur: L'utilisateur effectuant l'extraction a besoin d'un accès en lecture à tous les objets pertinents (par exemple, Compte, Commande, Invoice__c, Payment__c, Activité) et champs, en plus des permissions de création et d'exportation de rapports.

a Exemple de requête config

// This is a configuration guide for building multiple Salesforce reports.
// The data from these separate CSV exports must be manually combined and transformed into a single event log.

// Report 1: Invoice Generated
// Report Type: Invoices (or your custom invoice object report type)
// Filters: 
// 1. Created Date GREATER OR EQUAL [Start Date]
// 2. Created Date LESS OR EQUAL [End Date]
// Columns to Export & Map:
// - Invoice Number -> InvoiceNumber
// - 'Invoice Generated' (static text) -> ActivityName
// - Created Date -> EventTime
// - Created By -> UserResponsible
// - [Billing Department Field] -> BillingDepartment
// - Status -> InvoiceStatus
// - Total Amount -> InvoiceTotalAmount
// - Payment Due Date -> PaymentDueDate

// Report 2: Invoice Status Changes (Submitted, Approved, Rejected, Corrected, Closed, Written Off)
// Report Type: Invoice History (or your custom object's history report type)
// Filters:
// 1. Edit Date GREATER OR EQUAL [Start Date]
// 2. Edit Date LESS OR EQUAL [End Date]
// 3. Field/Event EQUALS 'Status' (or the name of your status field)
// Columns to Export & Map:
// - Invoice Number -> InvoiceNumber
// - New Value (transformed*) -> ActivityName 
// - Edit Date -> EventTime
// - Edited By -> UserResponsible
// - [Billing Department Field] -> BillingDepartment
// - New Value -> InvoiceStatus
// - [Invoice Total Amount] -> InvoiceTotalAmount
// - [Invoice Payment Due Date] -> PaymentDueDate
// *Transformation Logic for ActivityName: 
//   - IF New Value = 'Pending Approval' THEN 'Invoice Submitted for Approval'
//   - IF New Value = 'Approved' THEN 'Invoice Approved'
//   - IF New Value = 'Rejected' THEN 'Invoice Rejected'
//   - IF New Value = 'Draft' AND Old Value = 'Rejected' THEN 'Invoice Corrected'
//   - IF New Value = 'Closed' THEN 'Invoice Closed'
//   - IF New Value = 'Written Off' THEN 'Invoice Written Off'

// Report 3: Invoice Sent to Customer
// Report Type: Invoices
// Filters:
// 1. [Sent Date Field] NOT EQUAL TO "" (not null)
// 2. [Sent Date Field] GREATER OR EQUAL [Start Date]
// 3. [Sent Date Field] LESS OR EQUAL [End Date]
// Columns to Export & Map:
// - Invoice Number -> InvoiceNumber
// - 'Invoice Sent to Customer' (static text) -> ActivityName
// - [Sent Date Field] -> EventTime
// - Last Modified By -> UserResponsible
// - [Billing Department Field] -> BillingDepartment
// - Status -> InvoiceStatus
// - Total Amount -> InvoiceTotalAmount
// - Payment Due Date -> PaymentDueDate

// Report 4: Payment Due Date Reached
// Report Type: Invoices
// Filters:
// 1. Payment Due Date NOT EQUAL TO "" (not null)
// 2. Payment Due Date GREATER OR EQUAL [Start Date]
// 3. Payment Due Date LESS OR EQUAL [End Date]
// Columns to Export & Map:
// - Invoice Number -> InvoiceNumber
// - 'Payment Due Date Reached' (static text) -> ActivityName
// - Payment Due Date -> EventTime
// - 'System' (static text) -> UserResponsible
// - [Billing Department Field] -> BillingDepartment
// - Status -> InvoiceStatus
// - Total Amount -> InvoiceTotalAmount
// - Payment Due Date -> PaymentDueDate

// Report 5: Payment Reminder Issued
// Report Type: Activities with Invoices (or similar custom report type)
// Filters:
// 1. Task or Event Subject CONTAINS 'Payment Reminder'
// 2. Created Date GREATER OR EQUAL [Start Date]
// 3. Created Date LESS OR EQUAL [End Date]
// Columns to Export & Map:
// - Invoice: Invoice Number -> InvoiceNumber
// - 'Payment Reminder Issued' (static text) -> ActivityName
// - Created Date -> EventTime
// - Assigned To -> UserResponsible
// - [Billing Department Field] -> BillingDepartment
// - [Invoice Status Field] -> InvoiceStatus
// - [Invoice Total Amount] -> InvoiceTotalAmount
// - [Invoice Payment Due Date] -> PaymentDueDate

// Report 6: Customer Payment Received & Status Changes (Posted, Applied)
// Report Type: Payments with Invoices (or similar custom report type)
// This report combines multiple events from the Payment record.
// Filters:
// 1. Payment: Created Date GREATER OR EQUAL [Start Date]
// 2. Payment: Created Date LESS OR EQUAL [End Date]
// Part A: Payment Received
// Columns to Export & Map:
// - Invoice: Invoice Number -> InvoiceNumber
// - 'Customer Payment Received' (static text) -> ActivityName
// - Payment: Created Date -> EventTime
// - Payment: Created By -> UserResponsible
// Part B: Payment Posted and Applied (Requires exporting and transforming multiple rows for the same payment if status changes)
// You may need a separate Payment History Report, similar to Report 2.
// Assuming a simple status field on the Payment for this example:
//   - IF Payment Status = 'Posted' THEN 'Payment Posted to Ledger'
//   - IF Payment Status = 'Applied' THEN 'Cash Applied/Reconciled'

Votre modèle de données `Order-to-Cash` - Facturation

Votre modèle de données `Order-to-Cash` - Facturation

Attributs De la commande au paiement - Facturation et encaissement

Activités De la commande au paiement - Facturation et encaissement

Guides d'extraction

Générateur de rapports Salesforce et service d'exportation de données

Étapes

Configuration

a Exemple de requête config

Script Python utilisant l'API REST de Salesforce

Étapes

Configuration

a Exemple de requête python

Extraction par outil ETL via un connecteur Salesforce préintégré

Étapes

Configuration

a Exemple de requête config

Prêt(e) à démarrer ?

Paiements plus rapides : Optimisez votre facturation et recouvrement O2C dès maintenant

Votre modèle de données Order-to-Cash - Facturation

Votre modèle de données Order-to-Cash - Facturation

Attributs De la commande au paiement - Facturation et encaissement

Activités De la commande au paiement - Facturation et encaissement

Guides d'extraction

Générateur de rapports Salesforce et service d'exportation de données

Étapes

Configuration

a Exemple de requête config

Script Python utilisant l'API REST de Salesforce

Étapes

Configuration

a Exemple de requête python

Extraction par outil ETL via un connecteur Salesforce préintégré

Étapes

Configuration

a Exemple de requête config

Nous respectons votre vie privée

Prêt(e) à démarrer ?

Paiements plus rapides : Optimisez votre facturation et recouvrement O2C dès maintenant

Votre modèle de données `Order-to-Cash` - Facturation

Votre modèle de données `Order-to-Cash` - Facturation