Il y a exactement 2 façons d'écrire dans Pennylane : ① Compléter en masse les transactions encore vides (n'écrase jamais une valeur déjà présente) et ② Corriger une transaction précise (remplace une valeur déjà présente). La section ③ Règles automatiques n'écrit jamais elle-même dans Pennylane — elle alimente les propositions de la section ①.
Propositions générées automatiquement (règles de la section ③ + mapping RH + heuristique fournisseur), groupées par motif et triées par montant. Elles ne remplacent jamais une valeur déjà présente dans Pennylane — seulement les champs vides. Vérifie la confiance ("39/39 unanime" = fiable, "27/28 majorité" = à surveiller), puis choisis pour chaque ligne : "Valider" écrit tout de suite cette ligne dans Pennylane et la retire de la liste ; "Exclure" retire un motif à risque des propositions futures (sans rien écrire) et l'envoie dans la file "à corriger" de la section ②. Le bloc "Aperçu puis envoi" ci-dessous sert uniquement à pousser tout le reste d'un coup, pas ligne par ligne.
Étape obligatoire avant tout envoi réel : lance l'Aperçu (dry-run), relis le détail de ce qui serait écrit, puis Pousser vers Pennylane (désactivé tant que l'aperçu n'est pas allé jusqu'au bout).
Remplace immédiatement une valeur déjà présente dans Pennylane — contrairement à la section ①, qui ne touche jamais un champ déjà rempli. Un "Enregistrer" ici écrit réellement si tu as changé une valeur ; si tout est déjà correct, il marque juste la ligne comme vérifiée (aucune écriture) — dans les deux cas la ligne disparaît et compte comme traitée.
Motifs exclus depuis la section ① — l'automatisation n'est plus fiable pour ce fournisseur, il faut regarder chaque transaction à l'œil. Clique "Auditer" pour charger sa liste complète dans la recherche ci-dessous, puis "Enregistrer / vérifier toutes les lignes visibles" pour traiter tout le lot d'un coup (corrige ce qui est faux, marque vérifié ce qui est déjà bon). La ligne disparaît d'elle-même de cette liste une fois toutes ses transactions passées par "Enregistrer" ou vérifiées.
Recherche TOUTES les transactions correspondantes (déjà taguées ou non), une ligne par transaction. Une case surlignée en orange s'écarte de la valeur majoritaire affichée parmi les résultats. Les lignes déjà vérifiées (revue ou correction précédente) sont masquées par défaut — une recherche ne remontre que ce qui reste réellement à traiter.
Pour un fournisseur récurrent : pose la règle une seule fois (motif de libellé → Type de dépenses/BU/Pôle/Point de vente), elle alimentera automatiquement les propositions de la section ① pour toutes ses transactions futures — sans repasser par ici à chaque fois.
Triées par retard décroissant puis montant — signal fiable (remaining_amount < 0), jamais surveillé avant cet écran.
Restreint à l'exercice fiscal encore "open" dans Pennylane (les exercices figés/clos ne bougent plus) — triées par montant non rapproché décroissant.
Chaque ligne de vente Prodmode (facturée à un partenaire B2B — magasin, ambassadeur, agent, presse...) doit être lue analytiquement comme Wholesale, Corporate, Retail, E-Comm (vraie vente), ou Marketing/Produit (dotation, collab presse/ambassadeur, échantillon — pas une vente réelle) — c'est cette lecture, pas le libellé Prodmode brut du partenaire (Shop, Ambassadeur, Press, Guides...), qui alimente le Dashboard client de l'app B2B et la marge B2B du reporting investisseurs. L'export Prodmode automatisé ne fournit plus cette lecture nativement — elle est déduite de l'historique (partenaire × collection, ou partenaire seul) quand c'est possible, mais un partenaire jamais vu avant ne peut être résolu par aucune donnée existante. Cet écran sert exactement à ça : classer une fois pour toutes ces nouveaux partenaires — la classification est reprise automatiquement par toutes les apps qui en ont besoin, sans repasser par ici.
Triés par CA décroissant. Choisis une catégorie existante ou tape-en une nouvelle si aucune ne convient.
Historique des classifications faites ici — modifiable si un partenaire change vraiment de catégorie (la nouvelle saisie remplace l'ancienne).
"unknown" n'est pas un vrai nom de partenaire — c'est un problème de donnée source côté Prodmode (client non résolu à l'export). Ces commandes ne sont PAS classifiables ici : une seule catégorie appliquée à "unknown" mélangerait des commandes potentiellement de clients différents. À identifier directement dans Prodmode (n° de commande ci-dessous) ou à signaler à Josie.