Rapprocher les virements bancaires des commandes Sylius
Pour rapprocher les virements bancaires des commandes Sylius, on combine des règles simples et un agent IA. Les règles traitent les virements qui portent le numéro de commande et le montant exact. L'agent traite le reste : il lit le libellé, le nom du payeur et le montant, les compare aux commandes en attente de paiement et propose un rapprochement avec sa raison. Vous confirmez. L'agent ne marque aucune commande comme payée, ne rembourse rien et ne contacte personne.
Je suis développeur Sylius et Symfony indépendant, et j'intègre des agents IA dans des boutiques en ligne. Le virement reste très présent dans certaines boutiques, surtout en B2B ou pour les gros paniers. Et il crée un travail ingrat : ouvrir le compte bancaire, lire chaque opération, retrouver la commande, la passer en payé dans l'administration. Pour la vue d'ensemble des agents sur Sylius, voyez la page agents IA pour Sylius.
Pourquoi le rapprochement des virements coince-t-il ?
Parce que les clients ne remplissent pas le libellé comme prévu. L'un écrit « commande site », l'autre met le nom de sa société alors que la commande est au nom d'un salarié, un troisième paie deux commandes en un seul virement, un quatrième arrondit le montant. Chaque cas demande une enquête de quelques minutes. Pendant ce temps, la commande attend, et le client qui a payé attend aussi.
Il y a un piège propre à Sylius. Dans sa configuration par défaut, une commande impayée expire au bout de cinq jours, et Sylius fournit une commande d'annulation des commandes impayées qui s'appuie sur ce délai lorsqu'elle est planifiée. Un virement lent peut donc arriver pour une commande déjà annulée, et le stock réservé pour elle a pu être remis en vente.
Quelles données l'agent compare-t-il ?
Côté banque, chaque opération entrante : date, montant, libellé, nom du donneur d'ordre. L'accès est en lecture seule, limité aux crédits, par l'API de la banque ou par l'export de relevé. Côté Sylius, les commandes dont le paiement est à l'état awaiting_payment, l'un des états définis dans les états de paiement de Sylius, avec leur numéro, leur total, le nom du client et de sa société. L'agent lit aussi les commandes annulées récemment, pour repérer le piège décrit plus haut.
L'agent ne voit que ce dont il a besoin : pas le solde du compte, pas les paiements sortants, pas les autres moyens de paiement. Ce périmètre est fixé dans le code, c'est la couche des accès par rôle.
Et si un agent le faisait pour vous ?
Laissez votre numéro : je vous rappelle sous 24 heures ouvrées et je regarde avec vous ce qu'un agent peut prendre en charge dans votre boutique, dans votre budget.
Que propose l'agent selon les cas ?
| Cas | Qui le traite | Proposition |
|---|---|---|
| Numéro de commande et montant exact | Une règle, sans IA | Rapprochement certain, validation par lot |
| Libellé sans numéro, nom et montant concordants | L'agent | Rapprochement probable, avec la raison |
| Un virement pour plusieurs commandes | L'agent, total vérifié par le code | Rapprochement groupé si la somme tombe juste |
| Montant différent | L'agent | Signalement : paiement partiel, trop-perçu ou frais |
| Commande déjà annulée | Le code | Alerte prioritaire, stock à vérifier |
| Aucune commande plausible | L'agent | Mise de côté, avec les pistes envisagées |
La règle de fond : le modèle peut rapprocher un nom de société d'un nom de client, comprendre un libellé abrégé, mais il ne fait aucun calcul. Les sommes, les écarts et les correspondances de montant sont faits par le code. Une proposition dont les montants ne tombent pas juste est rejetée avant de vous parvenir. Ce sont les garde-fous.
Ce que l'agent ne fait jamais seul
Il ne passe aucune commande en payé, ne réactive aucune commande annulée, ne rembourse aucun trop-perçu, n'écrit pas au client et n'a aucun accès aux paiements sortants. Passer une commande en payé déclenche la préparation et l'expédition : c'est votre décision, même quand elle se prend en un clic pour un lot de rapprochements certains. Chaque proposition et chaque validation sont tracées, avec l'opération bancaire d'origine, ce qui facilite le travail de votre comptable. C'est la couche tests et traces.
Ce sont les cas douteux qui coûtent le plus : un client qui a payé et dont la commande ne part pas, ou une commande expédiée sur la foi d'un virement mal rapproché. C'est pour ces cas que l'agent écrit toujours sa raison en clair (« nom du donneur d'ordre identique à la société du client, montant égal au total, libellé sans numéro »), pour que votre vérification prenne quelques secondes au lieu de quelques minutes.
Combien de temps cela fait-il gagner ?
Cela dépend entièrement de votre volume et de la discipline de vos clients sur le libellé. Si presque tous les virements portent le numéro de commande, une règle sans IA suffit, et je vous le dirai. L'agent prend son intérêt quand une part notable des virements demande une enquête. Pour mesurer, relevez sur un mois le nombre de virements reçus et le nombre de ceux qui vous ont fait chercher.
Le rapprochement s'intègre bien dans d'autres routines : le point du matin sur la boutique, décrit dans l'article sur le rapport quotidien, peut afficher les virements en attente, et le temps passé dans l'administration en général est le sujet de l'article sur le back-office Sylius.
Par où commencer ?
Vérifiez d'abord deux réglages : le délai d'expiration des commandes impayées et l'instruction donnée au client pour le libellé du virement. Un libellé clairement demandé, avec le numéro de commande en évidence, règle déjà une partie du problème sans aucune IA. Ensuite, exportez trois mois de virements avec les commandes rapprochées : ce sera le jeu de test de l'agent.
Je propose un diagnostic IA offert : je vous rappelle sous 24 heures ouvrées, je regarde vos commandes payées par virement, votre banque et votre version de Sylius, et je vous propose la solution qui rentre dans votre budget.