Factures et Formidable et Paiement

[pierr0t]

Bonjour,

J'ai un système de formulaire Formidable (v5.4.0) accouplé à un Formidable Paiement (v2.1.0), Bank (v6.2.0) dans un Spip maintenant en 4.2.5, PHP 8.2 et Factures (v2.1.1).

Le passage à cette nouvelle version de Formidable s'est fait entre le 25/09 et le 26/09 et depuis cette date l'affichage des factures est mauvais, il manque la partie centrale. Je mets ça en relation avec la mise à jour de Formidable car cela a généré d'autres soucis dans d'autres traitements liés à priori au champ "parrain" et on voit sur la capture d'écran que la structure du parrain a changé, je suppose pour l'instant que c'est ce qui casse l'affichage de #DETAILS dans le corps de la facture, on est passé de parrain comme "form13:concours2023" à "formidable:13" (pour le même formulaire bien sûr). (le "formidable:3" est pour un autre formulaire).

Je ne suis pas sûr à 100% que le pbm vient de Factures, ou de Formidable, ou de Formidable Paiement, mais j'avais l'impression qu'ici était le meilleur endroit pour commencer à diagnostiquer ça (étant donné que je n'ai pas trouvé de Spip Contrib Factures).

Votre avis ?

[Cerdic]

Alors oui en effet le parrain a changé au passage de la version 2.1.0 de formidablepaiement.

Par contre le detail des factures est fourni par un modèle modeles/transaction_details.html qui n'est pas fourni par formidablepaiement ni par factures, et celui de bank ne prévoit pas le cas des formulaires formidables
https://github.com/nursit/bank/blob/master/modeles/transaction_details.html

donc je pense que tu as un modèle perso qui fait le lien entre la transaction et le formidable (via le parrain) et du coup ça a cassé en effet :(

[pierr0t]

Bonjour,
Effectivement voilà qui semble être le chainon manquant de cette histoire. Moi j'ai effectivement un modeles/transaction_details.html qui semble être un aiguillage vers modeles/transaction_details_formulaires.html ou modeles/transaction_details_defaut.html:

<BOUCLE_trans(TRANSACTIONS){id_transaction}>
[(#REM) Définir quel fond utiliser.
        Pour les formulaires, c'est un squelette spécial,
        pour le reste c'est le squelette par défaut ]
#SET{variante, #PARRAIN*|match{^form}|?{formulaires,defaut}}
<INCLURE{fond=modeles/transaction_details_#GET{variante}, env}>
</BOUCLE_trans>

Par contre pour l'instant quoi que je modifie la dedans ou dans modeles/transaction_details_formulaires.html, pas d'effet ... c'est bien utilisé chaque fois que l'on clique sur une facture ou seulement à la génération initiale de la facture ?

[pierr0t]

Bon pour l'instant je ne trouve pas, je n'ai pas l'impression que ces 3 fichiers dans mon dossier "modeles" soient utilisés, je peux même les supprimer ça ne change rien ... Le plus marrant c'est que #DETAIL m'affiche dans la facture le #PARRAIN qui n'a rien à faire là, je vois qu'effectivement dans mon modeles/transaction_details_formulaires.html j'ai une balise #PARRAIN toute seule ce qui justifierait cet affichage intempestif sauf que je l'enlève, je la remets, j'écris n'importe quoi ... rien ne change ... je me demande si je ne devrai pas faire un vidage de cache plus sévère via FTP ...

[Cerdic]

Alors première chose à savoir : une facture est générée au moment de son emission à l'aide des modèles, mais ensuite plus jamais. C'est la loi : une facture est définitive et ne peut être modifiée après avoir été émise.
Donc normal que si tu changes des trucs tu peux pas voir d'impact sur les factures.

Pour tester il faut que tu affiches spip.php?page=modeles/transaction_details&id_transaction=xx avec l'id_transaction qui va bien (en étant webmestre sinon tu as pas le droit d'afficher cette URL) et là tu pourras corriger le bug pour retrouver les bonnes infos dans ta page

De ce que je vois dans modeles/transaction_details.html le match va continuer à fonctionner, donc je pense que c'est ton modèle modeles/transaction_details_formulaires.html qu'il doit falloir modifier.

Cela dit, si on intégrait cette feature par défaut dans le plugin formidable (repérer qu'une transaction est liée à un formidable, et aiguiller automatiquement vers un modeles/formidablepaiement_transaction_details.html ce serait mieux et plus maintenable (et on eviterait une casse de ce genre dans le futur)

[Cerdic]

Aussi je note que formidablepaiement devrait faire un upgrade de base sur les parrains de la table spip_factures si présente et pas seulement sur spip_transactions

[pierr0t]

Merci pour ces retours et surtout pour cette url pour faciliter mon debuggage, mais j'avais fini par admettre que la facture était définitive et non re-générable, j'ai juste attendu que d'autres achats se fassent sur ces formulaires et j'ai vu que mes modifs étaient ok et d'ailleurs tu peux ajouter à ce problème une trilogie modeles/client_adresse_facture.html, modeles/client_adresse_facture_defaut.html, modeles/client_adresse_facture_formulaires.html qui remontent de fait le même souci.

Une question sur cette histoire d'immutabilité des factures. Dans mon cas typiquement je veux garder ces factures, le client a payé, le souci c'est que avant de m'apercevoir du problème j'ai eu 5-6 factures sans la zone "détails", et même ensuite j'ai encore 2-3 factures avec la zone "detail" mais sans la zone "client" avant que je réalise qu'il y avait ce souci là aussi. Il n'y a vraiment aucun moyen de régénérer ces factures sans les modifier ? voire même à la main (genre éditer un champ dans phpMyAdmin) pour que ces clients aient une facture ? mais peut-être que le lien fait ça, je vais tester !

Un des avantages/argument de l'immutabilité est en plus que les anciennes factures ne sont pas re-générées et donc toujours correctes malgré cette modification qui casse la logique précédente.

En tous cas merci, effectivement tout ça marchait depuis longtemps et j'avais complètement zappé cette étape dans le processus, je vais me faire une note à ce sujet. Je savais que cette mise à jour était potentiellement impactante, j'avais une sauvegarde au cas ou, mais j'étais plus ou moins obligé d' y passer ...

[Cerdic]

Ah oui en effet puisque ça va utiliser les données de la réponse formidable je suppose.

Mais plusieurs points ici

• on peut gérer l'aiguillage automatiquement dans le plugin formidablepaiement, ce qui sera plus robuste, mais ensuite il faudra faire des modèles à la main pour chaque formidable, pour adapter le contenu du modèle aux données du formidable
• je sais pas encore très bien comment on va gérer ça, mais ce plugin factures qui était déjà borderline d'un point de vue des obligations légales Françaises, et va bientôt être complètement obsolète cf Facturation électronique obligatoire légalement #8 (mais c'est un autre sujet)

[Cerdic]

Pour les factures defectueuses, quand j'ai eu le problème pour cause de bug, je fait une reprise manuelle en PHP avec un bout de code genre

$id_transaction = xx;
$id_facture = yy;

$details = recuperer_fond('modeles/transaction_details',array('id_transaction'=>$id_transaction));
$client = recuperer_fond('modeles/client_adresse_facture',array('id_auteur'=>$row['id_auteur'],'id_transaction'=>$id_transaction));

	$set = array(
		'client' => $client,
		'details' => $details,
	);
sql_updateq('spip_factures', $set, 'id_facture='.intval($id_facture));

que je lance manuellement pour les quelques factures à réparer.
C'est pas du tout convivial, mais c'est le principe même : si on fait un truc qui facilite la modification d'une facture on est hors la loi..

[pierr0t]

Ok je vais regarder ça !

Pour la facturation électronique je suis moi-même développeur/auteur d'un CMS complet qui génère des factures, j'ai commencé à explorer ce problème de facturation électronique, il semble pour l'instant quasi impossible de trouver une librairie qui inclut la génération du bon format pdf adapté (Factur/X, PDF/A3, ...), j'utilise TCPDF pour générer mes factures, il ne fait pas, et apparemment aucune librairie que j'ai exploré ne le fait, même après plusieurs heures dans ChatGPT il a donné sa langue au chat ... ça ressemble à un joli coup des grosses boites, faire un truc tellement complexe que seuls eux peuvent assurer l'investissement nécessaire pour développer le truc ... mais apparemment Dolibar a déjà un module donc je garde espoir de trouver quelque chose ou d'arriver à le faire moi.