Stripeaccounting

StripeAccounting est un module Dolibarr de rapprochement comptable Stripe.

Il lit l'API Stripe (ou un export CSV), repère les mouvements que le module Stripe officiel ne comptabilise pas — frais, remboursements, litiges, virements — et pose les écritures manquantes.

Compatibilité — Dolibarr 17+, PHP 7.2 → 8.5

Dépend de — modules Stripe, Banque, Comptabilité en partie double

Voir aussi — Installation et guide utilisateur

1. Principes de fonctionnement

Quatre règles gouvernent tout le module.

Principe	Ce que ça veut dire
Complémentaire	Le module ne crée aucun paiement, aucune facture, aucun webhook. Il lit Stripe et complète la comptabilité, rien de plus.
Idempotent	Chaque objet Stripe n'est traité qu'une fois, quel que soit le nombre de relances de la synchronisation.
Jamais de devinette	Si une opération ne peut pas être rattachée avec certitude, rien n'est posté : la ligne passe en error pour revue manuelle.
Configuration bloquante	Tant que la configuration minimale est incomplète, aucune synchronisation ne démarre (ni bouton, ni cron, ni import).

2. Prérequis

Modules Dolibarr requis

Module	Ce qu'il apporte
Stripe (modStripe)	Clé API, mode test/live, compte financier Stripe
Banque (modBanque)	Tables llx_bank et llx_bank_account
Comptabilité en partie double (modAccounting)	Table llx_accounting_bookkeeping

Réglage Dolibarr indispensable

ACCOUNTING_ACCOUNT_TRANSFER_CASH doit être renseigné dans Comptabilité → Configuration → Comptes par défaut. Sans lui, le virement interne généré par les payouts ne peut pas être transféré en comptabilité (limite de Dolibarr, pas du module).

l’option s'appelle : Compte comptable par défaut pour les virements internes

Notes

• Le SDK PHP Stripe n'est pas dupliqué : le module réutilise la copie du cœur (includes/stripe/stripe-php/).
• Le code évite volontairement toute syntaxe PHP postérieure à 7.2 (pas de match, ?->, enums, propriétés typées, str_contains…) pour couvrir toute la plage 7.2 → 8.5.

3. Arborescence

custom/stripeaccounting/
├── core/modules/modStripeAccounting.class.php   Descripteur (droits, menus, cron, constantes)
├── class/
│   ├── StripeApi.class.php                      Wrapper SDK Stripe (lecture seule)
│   ├── StripeRepository.class.php               Accès SQL + idempotence
│   ├── StripeLogger.class.php                   Journalisation
│   ├── StripeAccounting.class.php               Génération des écritures
│   ├── StripePayout.class.php                   Rapprochement des virements
│   ├── StripeSync.class.php                     Orchestrateur (point d'entrée du cron)
│   ├── StripeCsvImporter.class.php              Import CSV
│   └── actions_stripeaccounting.class.php       Hook 'bankcard'
├── admin/setup.php                              Configuration
├── import.php                                   Import CSV
├── dashboard.php                                Tableau de bord
├── transaction_list.php                         Liste des transactions
├── cron/stripe_sync.php                         Point d'entrée CLI
├── lib/stripeaccounting.lib.php
├── sql/
├── langs/{fr_FR,en_US,es_ES,it_IT,de_DE}/
└── css/

Sens des dépendances

pages et hook → StripeSync → (StripeApi, StripeRepository, StripeAccounting, StripePayout) → StripeLogger

Classe	Rôle
StripeApi	Interroge le SDK Stripe (balance transactions, charges, remboursements, litiges, payouts) avec pagination automatique. Aucun accès base, aucune écriture.
StripeRepository	Tout le SQL des deux tables du module. upsertTransaction() est le point d'idempotence.
StripeLogger	Écrit dans llx_stripeaccounting_log et en miroir dans dol_syslog().
StripeAccounting	Construit les écritures (remboursement, litige, TVA autoliquidation) ou les mouvements bancaires (frais). Expose checkConfig().
StripePayout	Crée le virement bancaire interne entre le compte Stripe et la banque réelle.
StripeSync	Orchestrateur : une méthode par flux, plus reconcileStripeAccount() qui enchaîne tout.
StripeCsvImporter	Alimente le même pipeline depuis un export CSV Stripe.
ActionsStripeAccounting	Hook bankcard : lien vers le tableau de bord sur la fiche du compte Stripe.

4. Synchronisation et idempotence

Chaque flux (syncFees, syncRefunds, syncDisputes, syncPayouts, syncTransactions) suit toujours les mêmes étapes :

1. Vérifier la configuration — si elle est incomplète : log ERROR, arrêt immédiat, aucun appel API.
2. Lister les objets Stripe sur une fenêtre glissante de 35 jours.
3. Filtrer — un objet est ignoré seulement s'il existe déjà et que son statut est reconciled ou ignored. Une ligne en pending ou error est retentée à ce run.
4. Enregistrer en statut pending, puis générer l'écriture ou le mouvement bancaire.
5. Conclure — succès : statut reconciled. Échec : statut error avec le message, et le lot continue sur l'objet suivant.

Reprise automatique — une ligne en error redevient éligible au run suivant. Une fois la cause corrigée (par exemple un exercice comptable créé tardivement), aucune intervention manuelle n'est nécessaire.

Pourquoi les doublons sont impossibles

• Clé unique en base sur (stripe_object_id, entity) — protège même contre deux exécutions concurrentes du cron.
• Test explicite avant traitement — évite jusqu'à la tentative d'écriture pour un objet déjà finalisé.

Cas particuliers : adjustment et payment_failure_refund

Ce sont des corrections de solde effectuées par Stripe lui-même (réversion après litige, remboursement d'un paiement finalement échoué). Le module les enregistre — sinon elles resteraient invisibles — mais ne les comptabilise jamais automatiquement : le signe du montant et la cause varient trop. Elles sont créées directement en error, avec un message explicite, à traiter manuellement.

5. Écritures comptables

Toutes les lignes d'un même évènement partagent le triplet doc_type='stripeaccounting', fk_doc, doc_ref : Dolibarr les regroupe automatiquement sous un même numéro de pièce, sans numérotation propre au module.

Vue d'ensemble

Évènement	Ce que fait le module	Résultat comptable
Frais Stripe (TVA none ou autoliquidation)	Mouvement bancaire PaymentVarious	Écriture 627xxx / 517xxx générée plus tard par Dolibarr
Frais Stripe (mode autoliquidation)	En plus : paire TVA postée immédiatement	Débit TVA déductible, crédit TVA autoliquidation (impact net nul)
Frais Stripe (mode french)	Écriture directe complète	Débit compte de frais HT + TVA déductible, crédit compte Stripe TTC
Frais d'abonnement / service (Radar, Billing, Connect…)	Mouvement bancaire PaymentVarious	Écriture générée plus tard par Dolibarr, sur le compte fournisseur Stripe
Virement (payout)	Virement bancaire interne entre les 2 comptes	Écriture générée plus tard par Dolibarr
Remboursement (facture retrouvée)	Écriture directe	Débit compte client 411xxx, crédit compte Stripe 517xxx
Remboursement (facture introuvable)	Rien	Statut error, à traiter manuellement
Litige / chargeback	Écriture directe	Débit perte sur litiges 658xxx, crédit compte Stripe 517xxx (+ compte de frais si frais associés)

Pourquoi frais et virements ne génèrent pas d'écriture directe

Le problème historique : quand une facture Stripe est transférée en comptabilité par le workflow standard de Dolibarr, le paiement est comptabilisé pour son montant brut — les frais sont ignorés à cette étape.

Si le module postait en plus sa propre écriture et sa propre ligne bancaire, cette ligne resterait invisible pour bankjournal.php — qui ne reconnaît que les lignes rattachées à doc_type='bank'. Un administrateur transférant « normalement » le compte bancaire en comptabilité créait alors une seconde écriture pour le même mouvement.

La solution retenue : pour les frais, les frais d'abonnement et les virements, le module ne crée plus que le mouvement bancaire réel, avec les mécanismes natifs de Dolibarr. C'est ensuite le bouton natif « Transférer en comptabilité » qui produit l'écriture, comme pour n'importe quel autre mouvement bancaire. Le module ne touche donc plus du tout llx_accounting_bookkeeping dans ces trois cas.

Cas	Mécanisme natif utilisé
Frais et frais d'abonnement	PaymentVarious (mouvement bancaire avec compte de contrepartie, sans tiers ni facture), avec son propre accountancy_code que bankjournal.php lit directement.
Virements (payouts)	Virement interne Dolibarr : Account::addline() des deux côtés, plus add_url_line(…, 'banktransfert'). La contrepartie est imputée sur ACCOUNTING_ACCOUNT_TRANSFER_CASH.

Dans les deux cas, le statut passe à reconciled — le module a fini son travail — mais piece_num reste vide : l'écriture n'existe pas encore, seul fk_bank est renseigné. Après transfert manuel, on la retrouve avec doc_type='bank' et fk_doc égal au fk_bank de la ligne.

À savoir — l'écriture des virements ne s'équilibre à zéro sur le compte de transfert que lorsque les deux comptes bancaires (Stripe et la banque réelle) ont été transférés en comptabilité, pas seulement un des deux.

⚠ STRIPE_AUTO_RECORD_PAYOUT doit rester désactivé

Dès lors que ce module gère les virements, décochez « Activer l'enregistrement automatique des paiements Stripe » dans stripe/admin/stripe.php — malgré son libellé, cette case ne concerne que les virements.

Sinon, le webhook du module officiel et ce module créeraient chacun leur propre mouvement bancaire pour le même virement, sans le savoir l'un de l'autre.

Le webhook cœur ne conserve d'ailleurs aucune trace de l'id du virement traité : en cas de double livraison Stripe (garantie « au moins une fois »), rien ne l'empêche de doublonner tout seul. Ce module, lui, a une vraie idempotence et rattrape automatiquement tout virement manqué sur 35 jours.

Page « Transferts Stripe » masquée

À l'activation, modStripeAccounting::init() désactive l'entrée de menu stripe/payout.php : cette page interroge l'API en direct sans rien enregistrer, et sa coexistence avec ce module ne créerait qu'une confusion sur ce qui fait foi pour les virements. remove() restaure la condition d'origine. C'est la seule table du cœur que ce module modifie — délibéré, et documenté ici pour cette raison.

Frais par transaction ou frais d'abonnement ?

Stripe facture deux choses distinctes sous le mot « frais » :

	Frais par transaction	Frais d'abonnement / service
Exemple	Commission sur chaque encaissement	Radar, Billing, Connect
Où le trouver	Champ .fee d'une balance transaction de type charge	Balance transaction dédiée, de type stripe_fee ou application_fee (le .fee y vaut toujours 0, le montant est dans .amount)
Compte utilisé	Compte de frais configuré (627xxx)	Code comptable fournisseur du tiers Stripe configuré
Type en base	fee	subscription_fee

Limite du mode TVA french

Ce mode doit scinder le montant TTC en HT + TVA, un découpage que PaymentVarious ne sait pas exprimer. Il reste donc sur l'ancien comportement : écriture directe complète, aucun mouvement bancaire créé. Pas de risque de doublon (puisque aucune ligne bancaire n'est produite), mais le solde llx_bank du compte Stripe ne reflétera jamais les frais tant que ce mode est actif.

6. Import CSV

L'import couvre le cas d'un compte Stripe différent de celui configuré dans le module officiel — par exemple une autre boutique PrestaShop avec son propre compte marchand. L'API n'y a pas accès : le contenu est exporté en CSV depuis le dashboard Stripe, puis importé.

Hypothèse de départ

Les factures et paiements de cette boutique sont déjà comptabilisés dans Dolibarr par un autre processus, et l'encaissement (débit 517, crédit 411) est déjà posé. Seuls manquent les frais, les remboursements et les virements — c'est exactement ce que l'import traite.

Interface : un seul champ

import.php n'expose plus qu'un champ d'upload, Historique général, câblé sur importGeneralHistory(). Ce fichier couvre à lui seul tous les types de mouvements.

Les méthodes importPayments() et importPayouts() restent implémentées et fonctionnelles, mais ne sont plus atteignables depuis l'interface ; elles sont documentées ci-dessous pour mémoire.

Comme le bouton « Synchroniser maintenant », l'import est bloqué — bandeau d'alerte, bouton désactivé, garde-fou côté serveur — tant que la configuration est incomplète.

Les trois méthodes

Méthode	Export Stripe lu	Traitement
importGeneralHistory() (seule exposée)	Balance history	Aiguillage par colonne Type, voir tableau ci-dessous
importPayments()	Payments	Frais → écriture de frais. Montant remboursé → ligne refund toujours en error.
importPayouts()	Payouts	Exactement le même traitement qu'un payout venu de l'API

Aiguillage de l'historique général, par colonne Type :

Type Stripe	Traitement
payout	Virement bancaire interne, comme via l'API
charge / payment avec frais	Mouvement de frais
stripe_fee / application_fee	Frais d'abonnement, sur le compte fournisseur Stripe
refund	Enregistré, toujours en error
payout_minimum_balance_hold / …_release	Ignorés — réserve glissante Stripe, impact net nul, rien à comptabiliser
tout autre type	Enregistré en type='other', statut error, type brut conservé dans la description. Aucune écriture devinée.

Les colonnes sont reconnues par leur nom : l'ordre importe peu, et les colonnes en plus non utilisées sont ignorées.

Idempotence de l'import

La clé unique protège contre tout double import : réimporter le même CSV, ou un CSV qui chevauche un import précédent, ne crée aucun doublon.

Point important : dans l'historique général, les lignes payout et charge/payment sont indexées par leur colonne Source (po_…, ch_…), pas par l'id de la ligne (txn_…) — soit exactement la même clé que les imports dédiés. Importer l'historique général en plus des exports spécifiques ne poste donc jamais deux fois la même écriture, quel que soit l'ordre.

Les identifiants Stripe étant uniques à l'échelle de la plateforme, mélanger dans la même table des lignes venant du compte API et de plusieurs comptes importés en CSV ne présente aucun risque de collision.

Détails pratiques

• Libellé source — un champ libre saisi à l'import (ex. « Boutique DRM ») est stocké sur chaque ligne créée et sert de colonne et de filtre dans la liste, pour distinguer plusieurs boutiques côte à côte.
• Format des montants — les CSV Stripe utilisent la virgule décimale française, convertie via price2num(). Les dates marquées (UTC) sont interprétées comme telles.

7. Configuration

La clé API et le mode test/live ne sont pas ressaisis ici : ils sont lus en lecture seule depuis le module Stripe officiel.

Champ	Constante	Usage
Compte financier Stripe	STRIPE_BANK_ACCOUNT_FOR_PAYMENTS (constante du module officiel)	Sélecteur de compte bancaire. Aucune copie locale, donc aucun risque de divergence.
Compte bancaire principal	STRIPE_BANK_ACCOUNT_FOR_BANKTRANSFERS (constante du module officiel)	Même sélecteur. Voir l'encadré ci-dessous.
Compte de frais	STRIPEACCOUNTING_COMPTE_FRAIS	Numéro de compte, ex. 627xxx
Compte de litiges	STRIPEACCOUNTING_COMPTE_LITIGES	Numéro de compte, ex. 658xxx. Requis — utilisé dès qu'un litige survient, quel que soit le mode TVA.
Tiers fournisseur Stripe	STRIPEACCOUNTING_FOURNISSEUR_STRIPE_ID	Tiers marqué fournisseur ; c'est son code comptable fournisseur qui est utilisé. Optionnel, sauf s'il existe des frais d'abonnement.
Mode TVA	STRIPEACCOUNTING_VAT_MODE	none, french ou autoliquidation
Compte TVA déductible (intracommunautaire)	STRIPEACCOUNTING_COMPTE_TVA_DEDUCTIBLE	Requis si mode TVA ≠ none. Stripe facturant toujours depuis une entité UE non française, la TVA déductible est intracommunautaire dans tous les cas.
Compte de TVA due (intracommunautaire)	STRIPEACCOUNTING_COMPTE_TVA_AUTOLIQUIDATION	Requis en mode autoliquidation uniquement — jamais utilisé en mode french.
Taux de TVA	STRIPEACCOUNTING_VAT_RATE	Pourcentage, 20 par défaut
Fréquence de synchronisation	STRIPEACCOUNTING_SYNC_UNITFREQUENCY	Répercutée sur la tâche planifiée (en secondes)

Pourquoi redéfinir le compte bancaire principal ici ?

La page de configuration du module Stripe officiel n'affiche ce champ que si STRIPE_AUTO_RECORD_PAYOUT est activé — et son handler de sauvegarde remet la valeur à 0 à chaque enregistrement tant que le champ n'est pas rendu. Or ce réglage doit justement rester désactivé quand ce module gère les virements. Le champ est donc réexposé ici, en écrivant directement la constante du cœur, pour que la valeur reste configurable et stable.

Les deux sélecteurs de compte n'écrivent leur constante que si un compte réel a été soumis : enregistrer la page pour un tout autre champ n'écrase jamais une valeur correcte.

Vérification de la configuration

StripeAccounting::checkConfig() renvoie la liste des constantes manquantes. Elle est appelée à la fois par la page de configuration (bandeau d'information) et par chaque point d'entrée de synchronisation (garde-fou réel qui bloque tout traitement).

Piège des sélecteurs de compte comptable

Les quatre champs utilisant FormAccounting::select_account() (frais, litiges, les deux comptes TVA) ont une option « rien sélectionné » dont la valeur est -1 — une chaîne non vide, donc vraie en PHP. Un champ laissé vide et enregistré stocke littéralement -1.

StripeAccounting::getAccountConst() normalise cette valeur en chaîne vide à la lecture, partout où ces constantes sont lues. Aucune écriture ne peut donc atterrir sur le compte inexistant -1.

8. Interface

Tableau de bord

Solde Stripe (appel API en direct), nombre de transactions non rapprochées, total des frais du mois, payouts en attente, et bouton Synchroniser maintenant — désactivé, avec bandeau listant les constantes manquantes, tant que la configuration est incomplète.

Liste des transactions

Liste paginée, triable et filtrable, construite avec le même mécanisme que les listes natives Dolibarr : l'icône en haut à droite du tableau permet à chaque utilisateur de choisir ses colonnes, et la préférence est mémorisée par utilisateur.

Colonne	Contenu
Montant, Frais, Total	Le popup sur les frais indique la TVA sur frais quand une paire d'autoliquidation ou une TVA française a été postée
Type, Description	Popup avec l'ID Stripe, l'ID d'évènement ou de source, et la description complète non tronquée
Tiers	Le client résolu via la facture, ou via la charge source pour son frais associé, ou le tiers fournisseur Stripe pour un frais d'abonnement
Écriture	Lien « Pièce n°X » vers l'écriture, et/ou lien vers le mouvement bancaire associé — voir la nuance ci-dessous
Source, Statut	Le badge error ouvre un popup avec le message d'erreur complet : plus besoin d'aller en base pour comprendre un échec

Lire la colonne « Écriture » — sur une ligne fee, subscription_fee ou payout, le lien pointe vers le mouvement bancaire, pas vers une pièce comptable. Le piece_num du module, lui, n'est jamais l'écriture 627/517 du frais : c'est uniquement la paire TVA d'autoliquidation. L'écriture du frais est générée plus tard, par le bouton natif de Dolibarr, et n'est jamais reportée sur cette ligne.

La page est purement consultative : aucune comptabilisation manuelle n'y est proposée. Le module comptabilise automatiquement, et le transfert en comptabilité des frais et virements se fait depuis le bouton natif « Transférer en comptabilité ».

Lignes charge et fee

Chaque paiement produit deux lignes en base :

• une ligne charge, toujours en statut ignored, frais à 0, jamais traitée — présente uniquement pour l'idempotence ;
• une ligne fee pour le même paiement, liée à la première.

Les deux apparaissent séparément dans la liste, mais la ligne fee porte elle aussi le lien vers le paiement et la facture, résolu par jointure.

Bandeau mode test

Tant que le mode live n'est pas activé, le tableau de bord, la page de configuration et la liste des transactions affichent tous les trois le même avertissement que le module Stripe officiel. Impossible d'oublier qu'on travaille en mode test.

Menus

Tout est regroupé sous Banques et caisses → Compte Stripe (menu du module officiel), à plat, en trois entrées de même niveau :

1. Tableau de bord Stripe
2. Transactions Stripe
3. Import CSV (réservé aux administrateurs)

Un lien vers le tableau de bord est aussi ajouté automatiquement sur la fiche du compte bancaire configuré comme compte Stripe.

9. Tâche planifiée

Deux façons d'exécuter la synchronisation, toutes deux idempotentes et sans risque à relancer. Dans les deux cas le code exécuté est strictement le même : aucune divergence de comportement.

⚠ Aucune des deux ne démarre toute seule.

L'activation du module crée la tâche StripeAccountingSync, mais désactivée par défaut. Et même activée, l'ordonnanceur Dolibarr n'est déclenché par rien tant qu'aucune crontab système ne l'appelle. Sans ces deux étapes, la synchro n'a lieu qu'au clic manuel sur « Synchroniser maintenant ».

Étape 1 — activer la tâche

Dans Accueil → Configuration → Modules → Tâches planifiées. llx_cronjob étant une table du cœur, ce réglage se fait uniquement par l'interface, jamais en SQL direct depuis le module.

Étape 2 — un déclencheur système

Au choix, l'une des deux options.

Option A — ordonnanceur Dolibarr (recommandé si plusieurs tâches planifiées coexistent). Lance toutes les tâches dues, pas seulement celle-ci. Nécessite l'étape 1.

*/15 * * * * curl "https://votre-dolibarr/public/cron/cron_run_jobs_by_url.php?securitykey=VOTRE_CLE&userlogin=VOTRE_LOGIN"

La clé de sécurité se génère sur la page des tâches planifiées, bouton « Sécurité de l'exécution des tâches par URL ».

Option B — script CLI du module. Autonome, refuse l'exécution depuis un navigateur, et indépendant de l'état activé ou non de la tâche Dolibarr.

*/15 * * * * php /chemin/vers/htdocs/custom/stripeaccounting/cron/stripe_sync.php >> /var/log/stripeaccounting.log 2>&1

10. Journalisation et permissions

Journalisation

Chaque appel API, écriture générée, avertissement ou erreur est tracé dans llx_stripeaccounting_log, consultable en base ou via le fichier de log standard Dolibarr. Niveaux : DEBUG < INFO < WARNING < ERROR. La colonne context contient le détail structuré en JSON (payload API, montants calculés…).

Permissions

Droit	Contrôle
read	Consultation du tableau de bord et de la liste
write	Déclarée pour la configuration, mais non vérifiée dans le code aujourd'hui
reconcile	Déclenchement manuel de la synchronisation

En pratique, admin/setup.php et import.php ne contrôlent que le statut administrateur Dolibarr, pas le droit write : seuls les administrateurs peuvent configurer le module ou importer un CSV, quoi qu'il soit coché dans les permissions.

11. Base de données

llx_stripeaccounting_transaction

Une ligne par objet Stripe traité — charge, frais, remboursement, litige ou virement — tous dans la même table, distingués par la colonne type.

Colonne	Type	Rôle
rowid	int AI	Clé primaire
entity	int	Multi-société Dolibarr
stripe_object_id	varchar(80)	Identifiant Stripe — ancre d'idempotence
stripe_event_id	varchar(80)	Identifiant d'évènement, informatif seulement
type	varchar(20)	charge, fee, subscription_fee, refund, dispute, payout, other
stripe_source_id	varchar(80)	Objet Stripe source (ex. la charge liée à un remboursement)
source_label	varchar(80)	Libellé libre saisi à l'import CSV ; vide pour les lignes venues de l'API
description	varchar(255)	Libellé Stripe
amount, fee, net	decimal(24,8)	Montants déjà convertis depuis les centimes Stripe
currency	varchar(3)	Code devise ISO
date_created, date_available_on	datetime	Dates côté Stripe
fk_facture, fk_paiement	int	Facture et paiement Dolibarr résolus, si trouvés
fk_bank	int	Ligne llx_bank générée (vide pour un frais en mode TVA french)
piece_num	varchar(20)	Numéro de pièce comptable généré, quand il y en a un
status	varchar(16)	pending, reconciled, error, ignored
error_message	text	Détail en cas d'erreur
date_creation, date_processed	datetime	Horodatage technique
fk_user_creat	int	Utilisateur ayant déclenché le traitement

Clé unique sur (stripe_object_id, entity) — c'est elle qui garantit qu'un même objet Stripe ne peut jamais être inséré deux fois, même en cas d'exécutions concurrentes.

llx_stripeaccounting_log

Colonne	Rôle
level	DEBUG, INFO, WARNING, ERROR
message	Message court
context	Contexte structuré en JSON
fk_stripeaccounting_transaction	Transaction liée, si applicable
datec	Horodatage

12. Dépannage

Symptôme	Cause probable	Action
Le bouton « Synchroniser maintenant » est désactivé	Configuration minimale incomplète	Compléter les champs listés dans le bandeau d'alerte de la page de configuration
Une transaction reste en error	Écriture refusée par Dolibarr (compte inexistant, période clôturée), ou remboursement non rattaché	Lire error_message sur la ligne, puis le détail dans la table de logs
Le solde Stripe ne s'affiche pas	Clé API manquante ou invalide dans le module Stripe officiel	Vérifier stripe/admin/stripe.php
Un remboursement n'est jamais rapproché	Le paiement d'origine n'a pas été retrouvé via ext_payment_id	Vérifier que le paiement Stripe a bien été enregistré par le module officiel avec cet identifiant
Un subscription_fee reste en error	Tiers fournisseur Stripe non renseigné, ou sans code comptable fournisseur	Renseigner le champ en configuration, et compléter la fiche du tiers
Un remboursement importé en CSV reste en error	Normal et attendu — ce compte n'est pas relié à ext_payment_id	Traiter la facture et le remboursement manuellement en comptabilité

13. Pièges rencontrés

Notes de développement, conservées pour éviter de retomber dedans.

• PaymentVarious::create() ne met à jour fk_bank qu'en base, jamais sur l'objet PHP. Un fetch() après create() est indispensable pour récupérer la vraie valeur.
• select_comptes() affiche son propre HTML et retourne le nombre de comptes. L'appeler en instruction nue : l'envelopper dans print réafficherait ce nombre juste après la balise select.
• master.inc.php, pas main.inc.php pour le script CLI. Le second attend une session HTTP et, en pur CLI, se termine silencieusement — aucune sortie, aucun log, code retour 0 — dans sa redirection vers la page de connexion. L'impression trompeuse que le script « ne fait rien » plutôt qu'une vraie erreur.
• Bibliothèques du cœur — master.inc.php ne charge pas tout ce que main.inc.php charge pour le web (par exemple core/lib/date.lib.php, requis par BookKeeping). À inclure explicitement si le script CLI évolue.
• Option « rien sélectionné » à -1 dans les sélecteurs de compte comptable — voir la section Configuration.

14. Limites connues

• Devises « zéro décimale » (JPY, KRW…) non gérées : les montants sont divisés par 100 en supposant deux décimales. Usage prévu : EUR.
• Fenêtre de 35 jours non configurable. Une synchronisation interrompue plus longtemps devra être rattrapée manuellement.
• Rattachement des remboursements — dépend de ext_payment_id et ext_payment_site sur llx_paiement, renseignés par le flux de paiement Stripe standard. Un paiement enregistré autrement ne pourra pas être rattaché automatiquement. Le rattachement se fait via le PaymentIntent id, jamais via l'id de charge : le module Stripe du cœur ne stocke jamais ce dernier (il y met soit le PaymentIntent brut, soit un composite, selon le chemin de paiement emprunté).
• Import CSV en notation française uniquement : un export à point décimal ne serait pas interprété correctement.
• Colonne « Transfer » du CSV Paiements stockée à titre informatif seulement : elle ne sert pas à vérifier que le total des paiements correspond au montant du virement importé.
• Remboursements importés en CSV toujours en error — comportement voulu, pas un bug.
• Mode TVA french — le solde bancaire du compte Stripe ne reflète pas les frais, voir section 5.