toulouse-maelis: add a for_payment parameter to reduce cancellation delay (#76856) #227
No reviewers
Labels
No Label
No Milestone
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: entrouvert/passerelle#227
Loading…
Reference in New Issue
No description provided.
Delete Branch "wip/76856-parsifal-param-for-invoice-cancel-delay"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Sur réception de ce paramètre on update Invoice.start_payment_date à now(), ça permettra de réduire le délai avant annulation à min(Invoice.created + cancel_invoice_delay, Invoice.start_payment_date + max_payment_delay).
Je note ici qu'un effet de bord de l'implémentation est qu'après un appel à /invoice/?for_payment la facture ne sera plus affiché à l'usager.
Autrement dit, il ne la verra plus s'il revient de Lingo sans l'avoir payée et devra recommencer à zéro la démarche d'inscription s'il (re-)change à nouveau d'avis.
(Je ne sais pas si le parcours était imaginé ainsi ou non.)
Je n'ai pas cherché à optimiser la requête du cron (en vrai je ne saurais pas faire).
Je ne vois pas pourquoi ça ferait ça, tu peux expliquer ? Il peut y avoir un bloquage des factures pendant leur paiement pour éviter les doubles transactions mais elle est toujours visible.
Ce patch a pour but de réduire le temps d'attente d'envoie de l'ordre d'annulation de la facture en supprimant le delai d'attente cancel_invoice_delay.
Sur invoices/ et /invoice il ne faut plus remonter les factures dès lors qu'elle sont sur le point d'être annulées (cancel_invoice_delay dépassé) dans max_payment_delay minutes.
Ici on a bien une facture qui est sur le point d'être annulée dans max_payment_delay minutes.
Ce serait contradictoire à mon avis de toujours l'afficher, parce qu'ensuite l'usager devrait la payer en moins de max_payment_delay minutes.
S'il faut encore afficher la facture pendant le paiement, alors
Je dirai qu'effectivement c'est un peu bizarre de cacher la facture pendant qu'on la paie, mais les délais sont déjà bien long. Les pages de paiement ne laisse pas 20 minutes aux gens pour valider leur paiement, c'est plus 5 minutes. 20 minutes c'est la borne haute pour recevoir la notification. Je dirai que après T+cancel_invoice_delay si on a une valeur start_payment_date, on affiche la facture avec un statut non payable en cours de paiement/expiration.
L'alternative ce serait d'avoir un cancel_invoice_delay très court mais qu'on prolonge de max_payment_delay à chaque fois qu'une personne démarre un paiement.
Je propose ne pas cherche trop la règle parfaite, on a les deux paramètres qu'il nous faut max_payment_delay et cancel_invoice_delay, on pourra toujours ajuste les règles.
@ -301,4 +301,2 @@
basket_generation_date__isnull=False,
maelis_cancel_notification_date__isnull=True,
created__lte=now()
- datetime.timedelta(minutes=(self.cancel_invoice_delay + self.max_payment_delay)),
Garde
created__lte=now() - datetime.timedelta(minutes=self.cancel_invoice_delay)
mais à ajoute :faut prendre le max (my bad) pas le min. Désolé.
oui (si j'ai bien interprété), donc on change rien ici.
---8<---
Actuellement on a :
Le but de ce ticket c'est :
Ce qui est résumé dans la description du ticket par :
delais avant annulation = min(T+30, T'+20)
Si l'on réduit le delais avant annulation (pas d'affichage lingo) à min(T+30, T'+20),
alors on doit annuler (ordre qui est passé à maélis) les factures qui sont dans ces deux cas (OU logique)
soit (T <= t - (30+20) ) OU (T' <= t - 20).
@ -305,3 +303,3 @@
)
for invoice in invoices:
invoice.cancel()
if (
La condition ne sera plus nécessaire.
Merci de m'avoir donné la formule (que j'avais demandé), je la comprends, mais en fait je ne souhaite pas optimiser dès à présent (pour moi c'est encore trop embrouillé).
@ -4044,3 +4052,3 @@
if invoice.status() == 'cancelled':
raise APIError('Invoice cancelled')
return {'data': invoice.format_content()}
if invoice.basket_generation_date and for_payment is not None:
Je pense que tu peux mettre à jour start_payment_date sur n'importe quel type de facture ça ne mange pas de pain et ça nous donne une information dans tous les cas.
Fait.
@ -4047,0 +4055,4 @@
invoice.start_payment_date = now()
invoice.save()
return {
'has_invoice_for_payment': bool(invoice.start_payment_date is not None),
Non c'est sur invoices qu'il faut ajouter has_invoice_for_payment et c'est toujours True.
Ce point est important, sans ça ça ne marchera pas.
Oups, j'ai compris tout de travers.
Il s'agit ici d'ajouter une indication comme quoi le connecteur gère bien le paramètre '?for_payment'.
J'ai corrigé : je le renvoie toujours à True sur
/invoies
et il n'est pas renvoyé surinvoices/history
.J'avais mal interprété la description du tiket.
Pour moi on réduisait le temps d'envoie de l'ordre d'annulation
en supprimant le premier temps où la facture n'est plus affichée.
Je réalise qu'en fait le second scénario s'insère de manière plus
complexe : réduire le temps d'envoie de l'ordre d'annulation
en ayant la facture toujours affichée mais pas payable.
Ok, j'ajoute des états pour détailler l'état "annulé" :
Bof, là tu as introduis un future second scénario (avec ?for_payment) donc
je serais d'avis de conserver le premier en l'état (sans ?for_payment).
J'ai ajouté 3 commits pour faciliter la relecture, que je pense squasher ensuite.
2716b72748
to06b640731f