Cerdic
commented
8 years ago On ne peut pas prendre non plus la date_transaction, car elle peut-être située dans le passé de plusieurs jours/semaines/mois dans le cas des paiements par chèque. Par ailleurs le champ SQL de la table spip_factures est date_paiement, donc je pense que le mieux c'est:
- ajouter un champ date qui sera la date de la facture, renseigné avec la date courante au moment de la création de la facture (donc ni la date_transaction ni la date_paiement)
- l'initialiser avec date_paiement pour l'upgrade de base
- l'utiliser pour numeroter les factures
- dans le squelette des factures distinguer aussi la date de la facture et la date_paiement qui sera indiquée dans la mention "Facture acquitée le ...."
rastapopougros
Suivant le mode de paiement, le prestataire peut parfois renvoyer une date_paiement dans le futur.
Du coup la facture se retrouve elle aussi avec une date dans le futur sauf que sa génération, du HTML et de son numéro unique (qui doit se suivre sans trou), elle se fait tout de suite, au moment où on revient avec un paiement validé. On a donc une facture fabriquée ce jour même, mais avec une date future.
Pour un même mois, quand on donne au comptable les factures classées par date, il peut donc y avoir des trous dans les numéros générés (pas obligatoirement : ça arrive quand on a un mélange de paiement SEPA et de paiement classique qui eux ont toujours la bonne date).
Il faudrait donc prendre la date de début de transaction pour mettre dans la facture.
(PS : ça c'est pour les factures futures qui suivront, après si quelqu'un a une idée pour corriger les anciennes factures… facile de corriger le champ SQL à la main, mais pas le HTML généré qui lui est toujours faux.)