** aucun don dans la bdd sur don.laquadrature.net/admin entre le 09/09 et le 05/11 : souci avec les csv de septembre (une douzaine de lignes entre le 10 et le 30 septembre), d'octobre 2018 et de novembre 2018 (deux lignes les 1er et 2 novembre)
** des personnes signalaient des dons manquants sur 2017 (récurrents et ponctuels), et on n'a rien dans la bdd entre le 14/11 (csv novembre 2017 300 lignes manquantes) et le 08/12 2017 (csv décembre 2017 200 lignes manquantes)
Il me manque des CSV en 2017, ce qui explique que ces dons ne sont pas présents. Je n'ai que ceux de Décembre, il me faudrait donc ceux d'Octobre et Novembre 2017 (j'ai ceux de 2018).
Sur le fichier 2 de Septembre 2018, à part les ',' au lieu des ';', je ne vois aucune erreur. Les 20 dons ponctuels présents ne peuvent être créés car ils ne correspondent pasà uneadresse connue.
En revanche, j'aimerai faire un point sur les 3 fonctions bancaires présente, @Robinson dis moi si je me plante.
Mise à jour des dates d'expiration des CB : je ne suis pas sûr que l'on s'en serve encore
Vérification des dons : prend un CSV en entrée et mets à jour les dons ponctuels (si j'ai bien suivi). Le problème ici est que tous es dons ponctuels sont en erreur, car ils ne sont pas connectable à des utilisatrices existantes.
Mise à jour des dons : Ne s'occupe que des dons récurrents, et pas du tout des dons pomctuels.
De là, plusieurs possibilité.
La fonction 1 ne sert à rien, et on peut mettre à jour les dtes d'expiration des CB directement pendant la fonction 3. Il y a un champ ''Date d'expiration'' dans le CSV. Je pense que c'est relativement simple à faire, et ça peut supprimer une étape pas super pertinente.
Le gros des problèmes est autour des fonctions 2 et 3.
Solution 1
On garde deux gestions différentes, une pour les ponctuels et une pour les récurrents. Les logiques de code étant différentes, c'est plus léger dans le backend, et moins de taff (il faut adapter légèrement ce qu'il y a derrière). Il me faut cependant être sur que l'on utilise les mêmes CSV à chaque fois.
Solution 2
On fusionne en une seule action les trois présentées ci-dessus. Ça simplifie l'usage, mais c'est un petit peu plus de code. Et le traitement sera un peu plus long aussi.
Dans tous les cas
Que fait-on des dons ponctuels anonymes ? Ceux qui ne sont liés à aucun compte. En l'état, ils sont marqués en erreur et donc non importés. Ce qui fait que notre comptabilité ne les prends pas en compte. Cela peut représenter une certaines somme (quelques centaines d'euros rien que pour Septembre).
Il nous faut obligatoirement un compte associé aux dons. Je peux créer le compte de ''Anne Onyme'' au cas où, auquel on peut rattacher les paiements anonymes.
Pource qui est des fichiers de Novembre et Décembre 2017, ils commencent par un caractère Unicode non visible et qui fait cafouiller le script php. J'ai modifié les fichiers et je les fait passer en prod.
@okhin La solution 1 me va très bien, vu que je n'ai pas besoin d'injecter les dons ponctuels en temps normal, mais seulement les dons mensuels. Le problème de l'injection des dons ponctuels ne se pose que dans cette phase de migration.
Oui pour Anne Onyme :)
Mais si on arrive a récupérer les comptes créés en 2018, ça devait bcp réduire le nbre !
Et je n'ai pas besoin d'un outil pour les CB en expiration, je les gère directement à partir du back-office de la BRED, de toute façon c'est une étape obligatoire pour discriminer les donatrices qui méritent d'être relancées. Et surtout pas de mail automatique ! Trop de cas particuliers...
Pour importer, de la base postgresql, on peut utiliser l'adresse mail + la date de création du don, il y a peu de chance qu'un même utilisateur ait créé le même jour à la même heure, deux dons.
MAJ au 15 janvier : après rapide vérification dans l'interface admin, tout semble cohérent dans la bdd entre janvier 2017 et septembre 2018 (ponctuels comme récurrents). Par contre il manque les récurrents d'octobre et novembre 2018 (entre le 8 et le 9 octobre, on n'a que 6 dons ponctuels en bdd ; entre le 8 et le 9 novembre on n'en a que quatre), et il faut aussi importer les csv de décembre 2018 et janvier 2019 pour être à jour
Jusqu'en Septembre 2018 (inclus) la date du CSV éatit au format MM/JJ/AA, avec une année sur deux chiffres. A laquelle nous ajoutions 1900, pour obtenir une année sur 4 chiffres (oui, 1900, pas 2000 … j'ai arrété d'essayer de comprendre la logique des banques).
A partir d'Octobre 2018, la date du CSV est affichée au format MM/JJ/AAAA, avec une année sur 4 chiffres, à laquelle nous ajoutions toujours 1900. Ce qui explique pourquoi on ne voyait pas les donc (ou pourauoi ils terminaient avec une date en 1899 …)
Bref, on s'est fait avoir par le bug de l'an 2000. Avec presque 20 ans de retard.