docs/70-systemes-a-part/30-paiement-differe.md —
ce document se lit aussi dans le dépôt, sans serveur.
Le paiement différé
Où : Finance → Paiement différé. Module finance.
À quoi ça sert
L'écran liste les commandes Pro non encaissées. On coche, on marque payé.
C'est le pendant de l'encours : ce qui est ici est ce qui compte dans le plafond de crédit d'un professionnel. Voir l'application Pro.
Marquer payé ne change pas le statut
Une commande Pro naît processing avec la facture déjà émise : WooCommerce ne la considère pas comme en attente de paiement.
L'encaissement est une information en plus, pas un changement d'état.
Mais ça passe quand même par le plugin
Un UPDATE SQL direct laissait la commande en cache dans WooCommerce continuer à lire « non payée ». Le plugin écrit la méta sur l'objet commande et ajoute une note.
C'est la règle générale : voir les règles des commandes.
Le relevé de fin de mois
Où : sur la fiche du client, pas ici. Un bloc « Relevé pro » apparaît au-dessus de l'historique des commandes, et seulement si ce client porte le rôle client_pro.
C'est le geste qui manquait. Le modèle est : le pro commande, la facture part tout de suite, et on lui envoie l'ensemble de ses factures en fin de mois. Cette dernière étape n'avait aucun support — ni liste par pro et par mois, ni moyen de récupérer les PDF autrement que commande par commande.
| Sur le bloc | |
|---|---|
| Un sélecteur de mois | Le mois en cours par défaut |
| Une ligne par facture | Numéro, date, payée ou à payer, total TTC |
| Un total | Le mois entier, et ce qui reste dû |
| Un bouton | Télécharger les factures — un ZIP des PDF |
Il télécharge, il n'envoie pas
C'est voulu. François relit avant d'envoyer, et écrit son mot au pro lui-même. Darsy sait pourtant déjà envoyer une facture avec sa pièce jointe — c'est le même travail — donc ce n'est pas une limite technique mais un geste humain choisi. Et il n'y a aucune tâche planifiée : voir les règles de travail.
Les payées en font partie
Un relevé mensuel est l'image du mois, pas la liste des dettes. Une facture réglée le 12 y figure, marquée payée. La retirer donnerait au pro un relevé qui ne correspond à rien de ce qu'il a reçu.
Trois états, et un seul appelle une action
| État | Ce qu'il veut dire |
|---|---|
| Payée | La banque l'a confirmé, ou quelqu'un a constaté l'encaissement |
| À payer | Paiement différé : la facture est partie, l'argent est attendu |
| À vérifier | Aucun signal de paiement — ce n'est pas une dette |
« On ne sait pas » n'est pas « impayé ». Une commande clôturée sans aucun marqueur n'est pas une créance : la compter comme telle ferait réclamer une somme peut-être déjà reçue. Seul le paiement différé entre dans le total « à encaisser ».
Le défaut du 25/09/2026 : trois écrans, trois réponses
Sur la commande 85292 d'un pro, la fiche commande affichait « Payée » et le relevé « À payer ». Aucun des deux ne mentait — ils ne posaient pas la même question. Il y avait trois définitions de l'encaissement dans le code, et le relevé venait d'en ajouter une quatrième :
| Où | Ce qu'il regardait |
|---|---|
| La fiche commande | Référence bancaire, ou _ispaid = yes, ou un statut de paiement en ligne |
| Cet écran | L'absence de _ispaid = yes |
| L'application des pros | _ispaid = yes, et rien d'autre |
_ispaid n'existe pas sur une commande payée par carte. Cette méta est posée par l'application Pro à la création, et par « marquer payé ». Une commande passée sur le site n'en a aucune — et deux des trois définitions la lisaient comme impayée. Dont celle de l'application : le pro voyait « À payer » sur son téléphone pour une commande qu'il avait réglée.
La règle vit maintenant dans src/Orders/Encaissement.php, une seule fois. Elle ajoute ce que la fiche ne pouvait pas voir — date_paid_gmt, la date que WooCommerce inscrit lui-même — et retombe sur postmeta, la migration HPOS étant en cours.
VerdictEncaissementTest tient la liste PHP et celle de la fiche (qui est en JavaScript) identiques : une divergence ne se voit pas, elle s'observe sur une commande des semaines plus tard.
Ce qui manque est dans l'archive
Si la boutique ne rend pas le PDF d'une facture, le relevé n'est pas annulé : l'archive porte un fichier A-VERIFIER.txt qui nomme les factures absentes et dit quoi vérifier.
Échouer en bloc pour une facture sur trente obligerait à deviner laquelle — et un ZIP ne peut pas porter de message d'erreur autrement.
Soixante factures au plus
Chaque PDF est un aller-retour vers la boutique. Un mois ordinaire en compte quelques dizaines ; au-delà, la requête n'aboutirait pas et personne ne saurait pourquoi. Le surplus est nommé dans A-VERIFIER.txt plutôt que tronqué en silence.
Cinquante commandes par appel
Chaque commande est un aller-retour HTTP vers la boutique, et « tout sélectionner » sur un mois peut en tenir des centaines.
Sans borne, PHP tue la requête à mi-chemin et l'opérateur n'apprend rien sur la moitié qui est passée. C'est ça le vrai défaut : pas la lenteur, mais l'ignorance sur ce qui a réussi.