Projet

Général

Profil

Development #74790

toulouse-maelis: facturation (post-paiement)

Ajouté par Nicolas Roche (absent jusqu'au 3 avril) il y a environ un an. Mis à jour il y a 12 mois.

Statut:
Fermé
Priorité:
Normal
Version cible:
-
Début:
23 février 2023
Echéance:
23 février 2023
% réalisé:

0%

Temps estimé:
Patch proposed:
Non
Planning:
Non

Description

Ajouter les endpoints "invoice/..." permettant de configurer les cellules "Factures actives" et "Historique des factures",
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

Lié à Passerelle - Development #75475: toulouse-maelis: ajouter le référentiel des régiesFermé15 mars 2023

Actions

Révisions associées

Révision 3226fd0c (diff)
Ajouté par Nicolas Roche (absent jusqu'au 3 avril) il y a 12 mois

toulouse-maelis: get last invoice WSDL for tests (#74790)

Révision bd7b1566 (diff)
Ajouté par Nicolas Roche (absent jusqu'au 3 avril) il y a 12 mois

toulouse-maelis: add an endpoint to get current invoices (#74790)

Révision 75de5eb3 (diff)
Ajouté par Nicolas Roche (absent jusqu'au 3 avril) il y a 12 mois

toulouse-maelis: add an endpoint to get historical invoices (#74790)

Révision b5a19ee8 (diff)
Ajouté par Nicolas Roche (absent jusqu'au 3 avril) il y a 12 mois

toulouse-maelis: add an endpoint to get an invoice (#74790)

Révision 332ad30f (diff)
Ajouté par Nicolas Roche (absent jusqu'au 3 avril) il y a 12 mois

toulouse-maelis: add an endpoint to pay an invoice (#74790)

Révision bb5e1280 (diff)
Ajouté par Nicolas Roche (absent jusqu'au 3 avril) il y a 12 mois

toulouse-maelis: add an endpoint to get a PDF invoice (#74790)

Révision e4089b33 (diff)
Ajouté par Nicolas Roche (absent jusqu'au 3 avril) il y a 12 mois

toulouse-maelis: store invoice in database (#74790)

Révision 3d99dd40 (diff)
Ajouté par Nicolas Roche (absent jusqu'au 3 avril) il y a 12 mois

toulouse-maelis: cache invoices on link call (#74790)

Historique

#1

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à.

#2

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
#3

Mis à jour par Stéphane Guiet il y a environ un an

  • Echéance mis à 23 février 2023
  • Priorité changé de Normal à Immediat
#4

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.

#5

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.

#6

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)
#7

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).

#8

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 :

#9

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é
#10

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.

#11

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 ?

#12

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).

#13

Mis à jour par Nicolas Roche (absent jusqu'au 3 avril) il y a environ un an

  • Statut changé de En cours à Solution proposée

ça pourrait peut-être être fait dans un autre ticket ?

Finalement j'ai ajouté 2 commits
  • 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.

#14

Mis à jour par Benjamin Dauvergne il y a environ un an

C'est rouge.

#15

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.

#16

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.

#17

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.

#18

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 :

#19

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 :

#20

Mis à jour par Transition automatique il y a 12 mois

  • Statut changé de Résolu (à déployer) à Solution déployée
#21

Mis à jour par Transition automatique il y a 10 mois

Automatic expiration

Formats disponibles : Atom PDF