Combien de temps un cabinet comptable perd-il chaque mois à ressaisir manuellement les commandes d’une boutique en ligne ? Sur les dossiers suivis, la réponse tourne souvent autour d’une demi-journée par mois pour une boutique de taille moyenne — un temps entièrement absorbable par une intégration webhook bien conçue entre WooCommerce et Pennylane.
L’objectif du projet n’est pas de synchroniser toutes les commandes dès leur création, mais uniquement celles réellement encaissées : une commande en attente de paiement n’a rien à faire dans la comptabilité, et l’inverse — oublier une commande payée — est la source d’erreur la plus coûteuse à corriger après coup.
Choisir le bon déclencheur : paiement confirmé, pas création de commande
WooCommerce propose plusieurs points d’ancrage possibles, mais un seul correspond réellement au moment où une écriture comptable doit être créée : le hook woocommerce_payment_complete, déclenché quand une passerelle de paiement confirme la transaction, quel que soit le statut final choisi ensuite (traitement en cours ou terminée selon la configuration de la boutique).
add_action( 'woocommerce_payment_complete', function ( $order_id ) {
$order = wc_get_order( $order_id );
if ( ! $order || $order->get_meta( '_pennylane_synced' ) ) {
return;
}
wc_get_container()->get( 'App\\Sync\\PennylaneSyncer' )->push( $order );
$order->update_meta_data( '_pennylane_synced', true );
$order->save();
} );
La métadonnée _pennylane_synced évite les doubles envois si le hook se déclenche plusieurs fois — un cas réel avec certaines passerelles qui confirment le paiement en deux temps (autorisation puis capture).
Mapper les lignes de commande vers des écritures Pennylane
Chaque ligne d’article WooCommerce doit correspondre à une ligne de facture côté Pennylane, avec le bon taux de TVA et le bon compte comptable. C’est là que la majorité des erreurs de synchronisation apparaissent, en particulier sur les frais de port et les remises globales qui n’ont pas de ligne dédiée par défaut.
- Une ligne par article, avec sa quantité, son prix HT et son taux de TVA récupéré via
$item->get_taxes(). - Une ligne distincte pour les frais d’expédition, mappée sur un compte comptable spécifique.
- Une ligne de remise si un coupon a été appliqué globalement, plutôt que de la répartir silencieusement sur chaque article.
Construire le corps de la facture envoyée à l’API
{
"customer": {
"external_reference": "wc-client-482",
"name": "Client boutique 482"
},
"invoice_lines": [
{ "label": "T-shirt coton bio - Taille M", "quantity": 2, "unit_price": 24.90, "vat_rate": "FR_200" },
{ "label": "Frais de livraison", "quantity": 1, "unit_price": 4.90, "vat_rate": "FR_200" }
],
"date": "2025-05-04",
"currency": "EUR"
}
Le champ external_reference côté client est essentiel : il permet à Pennylane de rattacher automatiquement les factures suivantes au même client sans créer de doublon à chaque commande.
Traiter séparément les remboursements et avoirs
Un remboursement WooCommerce, déclenché via woocommerce_order_refunded, ne doit jamais être traité comme une nouvelle facture négative envoyée sur le même flux : il correspond à un avoir, une entité distincte côté Pennylane, rattachée à la facture d’origine. Confondre les deux flux dans le même connecteur est l’erreur la plus fréquente observée sur les premières implémentations.
Sur nos projets, la règle appliquée est stricte : une facture ne se modifie jamais après émission côté Pennylane. Toute correction passe par un avoir, jamais par un renvoi de la facture initiale mise à jour.
Gérer les échecs d’envoi sans perdre de commande
L’API Pennylane peut être temporairement indisponible. Le connecteur doit journaliser chaque échec avec l’identifiant de commande, et proposer une file de reprise manuelle ou automatique via Action Scheduler, plutôt que de laisser un error_log silencieux comme seule trace du problème.
En résumé
Automatiser la facturation comptable d’une boutique WooCommerce avec Pennylane tient en un principe simple : synchroniser au moment du paiement confirmé, mapper chaque ligne de commande explicitement, et traiter les avoirs comme des entités séparées des factures. Le reste — formats d’API, authentification, retries — n’est que de la plomberie une fois ce modèle posé correctement.
