J’ouvre un thread ici, car je suis plus à l’aise pour suivre un conversation en FR pour définir du fonctionnel.
Le flux est actuellement réservé au staff, mais on pourra le migrer plus tard, lorsqu’ on aura quelque chose de plus mur.
Je pose donc ici ce que j’attendrais de la fonctionnalité “carte à débit différé”, sans m’attarder sur les problématique d’implémentation (ça viendra ensuite, on pourra faire évoluer le scope fonctionnel si nécessaire):
Vue rapport
les opérations “détaillées” doivent apparaitre dans la liste des opérations (donc possibilité de modifier catégorie/label etc)
les opérations “réelles” (débitées à la fin du mois) peuvent ne pas apparaitre dans la liste d’opération (c’est un genre de méta opération)
les opérations “réelles” ne peuvent pas avoir de catégorie (voir section Vue graphique).
il doit être possible de voir le solde réel à l’instant t (ne prenant pas en compte les opérations “détaillées” du mois courant)
il doit être possible de voir une projection du solde à la fin du mois (prenant en compte les opérations “détaillées” du mois courant)
Vue graphique
les opérations “détaillées” doivent apparaitre dans le graphique par catégorie
les opérations “réelles” ne doivent pas apparaitre dans le graphique par catégorie
je n’ai pas d’avis sur l’évolution du solde
le graphique d’entrée/sortie ne doit prendre en compte soit
que les opérations “détaillées”
que les opérations “réelles”
Vue budget
les opérations “détaillées” doivent être utilisées pour les budgets
les opérations “réelles” ne doivent pas être utilisées pour les budgets
Je suis globalement d’accord avec la description fonctionnelle que tu as faite pour l’instant, mais j’ai pas encore eu le temps de creuser en détails ce qu’il peut manquer
Côté Weboob, on peut récupérer des transactions “à venir” avec iter_coming. Ces transactions ont le type “COMING” (11 ou 12, j’ai un doute) et sont présentes (chez LCL, avec ma carte) dans un compte “virtuel” séparé, qui s’appelle “Relevé CB” et contient les encours carte du mois courant.
À la fin du mois, une transaction “Relevé CB date” apparaît sur le compte courant. C’est une opération normale, importé par Weboob (et par Kresus actuellement) et le compte “virtuel” est remis à zéro.
L’opération de relevé CB n’a pas une grande importance en effet, je pense, mis à part pour savoir combien on a été débité en tout pour un mois donné.
L’affichage de ma banque est pas mal et assez pratique je trouve. Avoir un compte “virtuel” pour les encours, qui contiennent toutes les iter_coming de Weboob (et soit donc remis à zéro régulièrement, mais il suffit qu’il reflète précisément la liste iter_coming et tout devrait marcher), c’est à dire ne pas les afficher dans la liste des transactions (ou dans une section particulière ?). Importer les opérations “relevé CB” comme fait actuellement (c’est à dire comme une opération normale).
L’idéal serait d’avoir une opération multiple relevé CB qui contienne toutes les transactions du compte d’encours pour le mois courant. Je ne sais pas si ça peut se faire automatiquement, il faudrait que Weboob nous retourne un type spécial pour l’opération “Relevé CB” (et ce n’est pas le cas actuellement)
On doit pouvoir faire des choses donc Par contre il faudrait peut-être réfléchir à la possibilité de ne pas autoriser la modification du type d’opération dans certains cas genre:
uniquement si c’est unknown (toujours)
autoriser la modification dans la liste d’opérations uniquement si c’est unknown, sinon, autoriser la modification uniquement dans la vue détaillée (moins de risque de modification non voulue, mais aussi possibilité pour l’utilisateur de corriger par lui même)
Je suis assez d’accord avec tout ce qui a été dit. S’il y a des transactions « card summary », on devrait pouvoir les intercepter et avoir des comportements spécifiques quand on les récupère, c’est plutôt bon signe pour la suite.
Je suis aussi d’accord qu’il « suffirait » d’avoir des sous-opérations pour en faire un problème « trivial » : l’opération relevé serait virtuelle (introduite par kresus) jusqu’au moment où elle apparaîtrait réellement (weboob) dans les comptes.
Je ne comprends pas ce que tu veux dire par là, tu pourrais détailler stp ?
(aussi je me permets d’ouvrir le topic, il n’y a pas de raisons que l’on travaille de manière fermée dans ce cas :). Je préfèrerais que l’on garde les topics fermés pour les partenariats externes ou les problèmes de sécurité)
Dans ma tête, si on fait des traitements particuliers pour un type d’opération donné, notamment qui affectent les données (lien entre opérations par exemple), il faut limiter la possibilité de modifier le type des opérations au strict minimum, à savoir lorsque le type est inconnu. Si le type n’est pas inconnu, on interdit la modification du type depuis la liste d’opération. Par contre, il doit toujours être possible pour l’utilisateur de modifier une erreur, je propose donc dans ce cas de maintenir la possibilité de modifier le type d’opération, mais uniquement depuis la « modale » de détails de l’opération.
Je ne suis pas certain que ce soit une bonne idée : si jamais Weboob se trompe sur le classement d’une opération (ça m’est déjà arrivé par le passé), alors on devrait juste vivre avec ça (du moins ça ne serait pas intuitif que ça peut se changer via une autre interface).
Mais je pense que c’est surtout un sujet indépendant du problème actuel, vu qu’il doit être possible de juste créer un déclencheur sur soit l’arrivée d’une opération de type “Résumé de carte” via la source, soit changement manuel vers ce type par l’utilisateur.
Je suis d’accord que c’est indépendant, et qu’il faut pouvoir modifier ce que renvoie Weboob.
Je signal juste que si on “lie” plusieurs opérations entre elles au changement de type, ça peut avoir des conséquences, plus larges. Et qu’il faudrait peut être limiter ceci.
Par contre il faudrait peut-être réfléchir à la possibilité de ne pas autoriser la modification du type d’opération dans certains cas genre: