Development #74790
toulouse-maelis: facturation (post-paiement)
0%
Description
pour récupérer
- l'historique des factures,
- les facture à payer,
- le détail d'une facture,
- le PDF d'une facture
et pour payer les factures.
Pour cela, utiliser les WS readRegieList, readInvoices, getInvoicePDF et payInvoices.
https://demo-toulouse.sigec.fr/maelisws-toulouse-recette/doc/invoice.html
Documentation : https://redmine.sigec.fr/issues/1573
Demandes liées
Révisions associées
toulouse-maelis: add an endpoint to get current invoices (#74790)
toulouse-maelis: add an endpoint to get historical invoices (#74790)
toulouse-maelis: add an endpoint to get an invoice (#74790)
toulouse-maelis: add an endpoint to pay an invoice (#74790)
toulouse-maelis: add an endpoint to get a PDF invoice (#74790)
toulouse-maelis: store invoice in database (#74790)
toulouse-maelis: cache invoices on link call (#74790)
Historique
Mis à jour par Benjamin Dauvergne il y a environ un an
- Statut changé de Nouveau à Information nécessaire
- Assigné à mis à Stéphane Laget
Il faut déterminer si le découpage en régie multiples coté Maelis a un sens pour nous au niveau paiement et remontée aux usagers, est-ce que chaque régie maelis correspond à une régie administrative distincte et donc un compte en banque distinct et donc un raccordement à un système de paiement distinct. Si ce n'est pas le cas on peut rationaliser (avoir un endpoint qui renvoie toutes les factures d'un usager). Et j'en appelle à Stéphane pour ces questions.
Pour la stabilité du portail (je ne connais pas celle de Maelis) il peut être intéressant de faire du cache, voir du cache proactif (i.e. régulièrement récupérer la liste de toutes les factures la nuit pour les liaison connues et lors de la liaison) et d'utiliser un timeout assez court dans les appels synchrones (ça ne répond pas vite -> on utilise le cache).
Pour la remontée du paiement des factures normalement pas besoin d'être asynchrone, lingo s'en occupe déjà.
Mis à jour par Nicolas Roche (absent jusqu'au 3 avril) il y a environ un an
- Assigné à changé de Stéphane Laget à Stéphane Guiet
Mis à jour par Stéphane Guiet il y a environ un an
- Echéance mis à 23 février 2023
- Priorité changé de Normal à Immediat
Mis à jour par Stéphane Guiet il y a environ un an
- Assigné à changé de Stéphane Guiet à Benjamin Dauvergne
- Priorité changé de Immediat à Normal
Est-ce que chaque régie maelis correspond à une régie administrative distincte et donc un compte en banque distinct et donc un raccordement à un système de paiement distinct
Oui, une boutique par régie.
Mis à jour par Benjamin Dauvergne il y a environ un an
Stéphane Guiet a écrit :
Est-ce que chaque régie maelis correspond à une régie administrative distincte et donc un compte en banque distinct et donc un raccordement à un système de paiement distinct
Oui, une boutique par régie.
Ok donc il faudra bien un endpoint par régie. Ça risque de poser problème pour les inscriptions on ne pourra jamais les payer en une fois. Par contre mes remarques sur le cache reste pertinente.
Mis à jour par Benjamin Dauvergne il y a environ un an
- Statut changé de Information nécessaire à Nouveau
- Assigné à changé de Benjamin Dauvergne à Nicolas Roche (absent jusqu'au 3 avril)
Mis à jour par Nicolas Roche (absent jusqu'au 3 avril) il y a environ un an
- Assigné à changé de Nicolas Roche (absent jusqu'au 3 avril) à Benjamin Dauvergne
Pour la stabilité du portail (je ne connais pas celle de Maelis) il peut être intéressant de faire du cache
Tu parles de mettre en cache les résultats des requêtes (django.core.cache).
voir du cache proactif (i.e. régulièrement récupérer la liste de toutes les factures la nuit pour les liaison connues et lors de la liaison)
La j'imagine qu'il s'agirait de reproduire le modèle Régie / Invoice de Lingo dans le connecteur.
J'ai quand même un doute sur la pertinence d'aller requêter toutes les familles sur les 9 régies
(Sans trop bien savoir combien on aura de dossiers DUI, j'imagine bien que ça générera pas loin d'un million de requêtes).
Mis à jour par Robot Gitea il y a environ un an
- Statut changé de Nouveau à En cours
- Assigné à changé de Benjamin Dauvergne à Nicolas Roche (absent jusqu'au 3 avril)
Nicolas Roche (nroche) a ouvert une pull request sur Gitea concernant cette demande :
- URL : https://git.entrouvert.org/entrouvert/passerelle/pulls/120
- Titre : WIP: toulouse-maelis: facturation (post-paiement) (#74790)
- Modifications : https://git.entrouvert.org/entrouvert/passerelle/pulls/120/files
Mis à jour par Nicolas Roche (absent jusqu'au 3 avril) il y a environ un an
- Lié à Development #75475: toulouse-maelis: ajouter le référentiel des régies ajouté
Mis à jour par Benjamin Dauvergne il y a environ un an
Nicolas Roche a écrit :
Pour la stabilité du portail (je ne connais pas celle de Maelis) il peut être intéressant de faire du cache
Tu parles de mettre en cache les résultats des requêtes (django.core.cache).
Non je parle de cache en base avec des modèles.
voir du cache proactif (i.e. régulièrement récupérer la liste de toutes les factures la nuit pour les liaison connues et lors de la liaison)
La j'imagine qu'il s'agirait de reproduire le modèle Régie / Invoice de Lingo dans le connecteur.
J'ai quand même un doute sur la pertinence d'aller requêter toutes les familles sur les 9 régies
(Sans trop bien savoir combien on aura de dossiers DUI, j'imagine bien que ça générera pas loin d'un million de requêtes).
Je ne connais pas le nombre de familles mais disons n, et m régies, je vois l'appel readInvoices qui prend le numéro famille et la régie je dirai qu'il faut faire au max n * m régies. Pour diminuer on peut se restreindre aux régies qui pour une famille ont déjà eu une facture et comme date de début la date de la dernière facture ou il y 7 jours. Au niveau du modèle pour le cache je dirai :
class Invoice family : FK(Family/DUI) regie : FK(Regie) InvoiceBean_as_json : JSON
Le but étant de rendre les appels à invoices/ le plus rapides possibles sans charger maelis.
PS: on ne met bien sûr pas en cache les PDFs.
PS2: si déjà on peut mettre en cache sur les appels synchrones et à la liaison pour une famille donnée, c'est déjà bien. Rajouter une rafraîchissement du cache régulier sera un exercice pour les soirées d'hivers.
PS3: si j'en crois la volumétrie sur Teamnet il y a 33500 DUI liés à au moins un compte en ligne.
Mis à jour par Nicolas Roche (absent jusqu'au 3 avril) il y a environ un an
sur Teamnet il y a 33500 DUI liés à au moins un compte en ligne
soit (n * m régies) 301500 listes de factures à gérer en cache.
Le but étant de rendre les appels à invoices/ le plus rapides possibles sans charger maelis.
Je ne pense vraiment pas que ce soit là le goulet d'étranglement.
Pour moi on charge beaucoup plus maélis sur l'affichage du catalogue, ou les source de données relatives au catalogue personnalisé.
Après j'entends bien le besoin d'avoir des objets Invoices et Inscriptions qui nous permettront de savoir quand une inscription sera finalisée,
mais ça pourrait peut-être être fait dans un autre ticket ?
Mis à jour par Benjamin Dauvergne il y a environ un an
Nicolas Roche a écrit :
sur Teamnet il y a 33500 DUI liés à au moins un compte en ligne
soit (n * m régies) 301500 listes de factures à gérer en cache.
Quel est le souci ? On stocke le résultat dans InvoiceBean, pas des listes de facture, on aura difficilement plus de 33500 nouvelles factures par jour, ça 0.5 par secondes.
Le but étant de rendre les appels à invoices/ le plus rapides possibles sans charger maelis.
Je ne pense vraiment pas que ce soit là le goulet d'étranglement.
Pour moi on charge beaucoup plus maélis sur l'affichage du catalogue, ou les source de données relatives au catalogue personnalisé.
On pourrait le mettre en cache, en dehors de la liste différente d'activités/unités/lieux rien ne diffère du catalogue général (pas besoin de stocker un résultat par famille, on peut ne garder en cache que la liste des activités/unités/lieux et la reconstruire quand c'est indisponible ou qu'on l'a déjà lu récemment).
Mis à jour par Nicolas Roche (absent jusqu'au 3 avril) il y a environ un an
- Statut changé de En cours à Solution proposée
Finalement j'ai ajouté 2 commitsça pourrait peut-être être fait dans un autre ticket ?
- pour enregistrer les factures et les renvoyer sur un timeout de maélis.
- pour enregistrer les factures lors de l’appairage.
Quel est le souci ?
Aucun, tant que l'on ne parle pas d'un cron qui irait récupérer toutes les factures.
Mis à jour par Nicolas Roche (absent jusqu'au 3 avril) il y a 12 mois
- Assigné à changé de Nicolas Roche (absent jusqu'au 3 avril) à Benjamin Dauvergne
Pour la remontée du paiement des factures normalement pas besoin d'être asynchrone, lingo s'en occupe déjà.
Je suis passé trop vite sur cette phrase.
Par "remonté" tu entends du connecteur vers Lingo (pas de Lingo vers le connecteur) ?
Ce serait pour avoir confirmation que je dois prévoir des appels asynchrone vers Maélis sur payInvoice.
Mis à jour par Benjamin Dauvergne il y a 12 mois
Nicolas Roche a écrit :
Ce serait pour avoir confirmation que je dois prévoir des appels asynchrone vers Maélis sur payInvoice.
Oui payInvoice doit être asynchrone, de plus tu dois stocker localement l'état intermédiaire de la facture payée, i.e. si Maelis répond qu'elle est à payer mais qu'on a un enregistrement local nous disant le contraire, on répond la vérité. Comme ça la cellule d'affichage des factures fonctionnent, même en cas de lag de la remontée du paiement vers Maelis.
Mis à jour par Frédéric Péters il y a 12 mois
- Assigné à changé de Benjamin Dauvergne à Nicolas Roche (absent jusqu'au 3 avril)
Pour pouvoir avancer en parallèle sur des tests réels, la présentation, etc. je serais pour valider ici et poser l'asynchrone dans un nouveau ticket, je l'ai créé #76394.
Mis à jour par Robot Gitea il y a 12 mois
- Statut changé de Solution proposée à Solution validée
Frédéric Péters (fpeters) a approuvé une pull request sur Gitea concernant cette demande :
Mis à jour par Robot Gitea il y a 12 mois
- Statut changé de Solution validée à Résolu (à déployer)
Nicolas Roche (nroche) a mergé une pull request sur Gitea concernant cette demande :
- URL : https://git.entrouvert.org/entrouvert/passerelle/pulls/120
- Titre : toulouse-maelis: facturation (post-paiement) (#74790)
- Modifications : https://git.entrouvert.org/entrouvert/passerelle/pulls/120/files
Mis à jour par Transition automatique il y a 12 mois
- Statut changé de Résolu (à déployer) à Solution déployée
toulouse-maelis: get last invoice WSDL for tests (#74790)