Project

General

Profile

Support #85758

maelis: erreur sur notification d'un paiement de zéro euro

Added by Benjamin Dauvergne 6 months ago. Updated 15 days ago.

Status:
Fermé
Priority:
Normal
Assignee:
Target version:
-
Start date:
16 January 2024
Due date:
% Done:

0%

Estimated time:
Patch proposed:
No
Planning:
No

Description

https://sentry.entrouvert.org/entrouvert/publik/issues/115116/events/?referrer=RegressionActivityEmail

SOAP service at https://pfs.applis.toulouse-metropole.fr/parsifal/services/InvoiceService?wsdl returned an error "E500 : Le montant est requis et ne peut être vide" 

Je pense que le code n'est pas bon:

                amount=str(
                    Decimal(obj.maelis_data['amountInvoice']) - Decimal(obj.maelis_data['amountPaid'])
                ),

On devrait notifier le montant payé, là je suppose qu'on notifie toujours 0.


Related issues

Related to Passerelle - Development #76394: toulouse-maelis: notification asynchrone du paiement des facturesFermé07 April 2023

Actions
Related to Passerelle - Bug #90074: toulouse-maelis: date de notification à maélis non positionnéeSolution déployée26 April 2024

Actions
Related to Passerelle - Development #92394: toulouse-maelis: rattraper les erreurs réseaux sur les réponses des notifications des factures payéesSolution déployée27 June 2024

Actions

History

#1

Updated by Benjamin Dauvergne 6 months ago

  • Assignee set to Nicolas Roche
  • Priority changed from Normal to Immediat
#2

Updated by Benjamin Dauvergne 6 months ago

  • Related to Development #76394: toulouse-maelis: notification asynchrone du paiement des factures added
#3

Updated by Nicolas Roche 6 months ago

  • Priority changed from Immediat to Haut

Je vais avoir besoin d'analyser un peu pourquoi on a l'erreur uniquement sur cette facture, je baisse la priorité du ticket (le temps que je m'y mette asap).
A première vue ce n'est pas forcément lié à ce code qui (il faut que je recherche dans l'historique) aurait été prévu (par toi ? je sais pas encore), pour gérer plusieurs paiements.
De ce que je vois ce serait lié à une seule facture (101/37) dont la notification de paiement ne serait pas partie vers maélis, puis qui aurait été payée une seconde fois en backoffice.
Il y aura aussi à traiter l'erreur côté CPF : la facture me semble avoir été payée 2 fois.

#4

Updated by Benjamin Dauvergne 6 months ago

Je ne comprends pas si amount est le montant de la facture, le montant payé ou le montant restant, si c'est le montant payé le code est faux.

#5

Updated by Benjamin Dauvergne 6 months ago

Nicolas Roche a écrit :

A première vue ce n'est pas forcément lié à ce code qui (il faut que je recherche dans l'historique) aurait été prévu (par toi ? je sais pas encore), pour gérer plusieurs paiements.

J'ai juste relu, c'est bien ton code.

#6

Updated by Nicolas Roche 6 months ago

  • Priority changed from Haut to Normal

Je ne comprends pas si amount est le montant de la facture, le montant payé ou le montant restant, si c'est le montant payé le code est faux.

Oui, d'après la doc Sigec on devrait envoyer le montant payé alors qu'on envoie le montant restant (ou zéro suivant l'interprétation).
https://demo-toulouse.sigec.fr/maelisws-toulouse/doc/invoice.html#method5

> amount : montant du règlement

https://demo-toulouse.sigec.fr/maelisws-toulouse/doc/invoice.html#bean-InvoiceBean

> amountInvoice BigDecimal     montant de la facture
> amountPaid     BigDecimal     montant à paier       

Et non (cf dernier commentaire de https://git.entrouvert.org/entrouvert/passerelle/pulls/182) :

Et là je me rend compte que le code idiot dans lingo ne remonte pas le montant payé, je serai franchement pour ouvrir tout de suite un ticket pour avoir ça dans la notif et ici pouvoir écrite self.lingo_data['amount'] parce que si la facture a été partiellement payée par ailleurs on ne sait quel montant a été payé.
J'ai ouvert #76572 que je vais traiter de ce pas.

Parce que dans la doc: #1573

> Double amountPaid : montant réglé à la régie

Donc on enverrai bien le montant payé.
(question posée à Sigec, pour en avoir le cœur net : https://redmine.sigec.fr/issues/3813)

J'ai juste relu, c'est bien ton code.

Oui, pardon.

#7

Updated by Benjamin Dauvergne 6 months ago

Moi aussi je me suis mélangé les pinceaux encore une fois en re-relisant, donc oui amount-amountPaid c'est bien le montant restant sur la facture. Maintenant reste à savoir comment cette facture a été payé à zéro euros (combo/lingo a laissé faire ça ?), et comment ça a pu arriver entre le moment où elle a été réglé au guichet et son paiement en ligne.

Vu que maelis refuse les notifications de zéro euro dans ce cas là on devrait juste ne pas notifier i.e:

si @amount-amountPaid <= 0, on appelle pas payInvoice, on log un warning et on pose la date de notification)

À voir aussi si on ignore bien les factures annulées dans ce cas (et peut-être nécessaire de faire un refresh de la facture avant de tenter la notification pour avoir son statut à jour).

#8

Updated by Nicolas Roche 6 months ago

  • Priority changed from Normal to Haut

Facture payée via le portail à 10:08:15 (utc+1), connecteur notifié à 10:08:48
https://famille-loisirs.eservices.toulouse-metropole.fr/manage/lingo/?regie=&q=20240115090815_ajmXz3
Il y a eu un pépin sur le job qui dans les logs c'est terminé correctement,
mais sans pour autant inscrire sur la facture de date de notification à maélis.
Du coup le connecteur veut à nouveau prévenir Maélis du paiement.

Je pense qu'il est arrivé à atteindre maélis parce que la somme a été modifiée
juste après dans maélis à 10:09:11 (on a le diff sur la facture dans nos logs).

(L'autre version, plus improbable, serait que la facture ait été payée sur le portail avant la notification et que la notification ait échouée, mais ne l'ait pas renseigné dans les logs.
Désolé, j'ai du mal à avancer sur l'analyse.
Après, pour moi comme on touche à l'argent et donc il ne faut pas ignorer le problème, la bonne solution serait de s'assurer du déroulé et de poser une date de notification si elle a vraiment eu lieu)

#9

Updated by Benjamin Dauvergne 6 months ago

Oui j'ai trouvé le log de l'appel payInvoice pour cette facture 37 : Le job semble rejoué à 11:17 par le cron :

Pas évident pour moi de comprendre pourquoi le log de l'appel arrive après le log d'erreur de la commande (peut-être un coup de defer qui est appliqué sur BaseCommand.execute.

Aucune trace ni erreur nul part n'indique pourquoi maelis_notification_date est resté nul.

#10

Updated by Benjamin Dauvergne 6 months ago

C'est le seul cas, je penche pour poser maelis_notfication_date maintenant et attendre que ça se reproduise.

passerelle=# select id, maelis_data->>'amountInvoice', maelis_data->>'amountPaid', maelis_data->>'amountPaidTG' from toulouse_maelis_invoice where (maelis_data->>'amountPaid')::decimal <> 0 and maelis_notification_date is null and lingo_notification_date is not null;
 id | ?column? | ?column? | ?column? 
----+----------+----------+----------
 53 | 9.6      | 9.6      | 0
(1 ligne)

PS: fait

passerelle=# begin;
BEGIN
passerelle=*# update toulouse_maelis_invoice set maelis_notification_data = '45', maelis

passerelle=*# update toulouse_maelis_invoice set maelis_notification_data = '45', maelis_no

passerelle=*# update toulouse_maelis_invoice set maelis_notification_data = '45', maelis_notification_date = '2024-01-15 10:08:54+01' where id = 53;
UPDATE 1
passerelle=*# commit
passerelle-*# ;
COMMIT

#11

Updated by Nicolas Roche 6 months ago

  • Status changed from Nouveau to En cours
  • Priority changed from Haut to Normal

Oui j'ai trouvé le log de l'appel payInvoice pour cette facture 37 :

Super, j'avais un doute sur le fait que l'on enregistrait les trames SOAP sur les jobs.

C'est le seul cas, je penche pour poser maelis_notfication_date maintenant et attendre que ça se reproduise.

Merci, je pensais faire ça aussi.

Au cas où j'ai ouvert un ticket sur le redmine Sigec (vu qu'on a bien reçu la trame SOAP, c'est finalement sans intérêt).
https://redmine.sigec.fr/issues/3816

#12

Updated by Nicolas Roche 16 days ago

  • Related to Bug #90074: toulouse-maelis: date de notification à maélis non positionnée added
#13

Updated by Nicolas Roche 16 days ago

  • Related to Development #92394: toulouse-maelis: rattraper les erreurs réseaux sur les réponses des notifications des factures payées added
#14

Updated by Benjamin Dauvergne 15 days ago

On en est où ici, on ferme ? Le connecteur reçoit maintenant le montant réel du paiement de la part de combo, on ne peut de toute façon pas envoyer les trop payés à Maelis il ne le gère pas; on peut juste espérer que ça n'arrive jamais (double paiement).

#15

Updated by Nicolas Roche 15 days ago

  • Status changed from En cours to Fermé

Oui, je ferme.
Le ticket a dérivé sur le fait que la date de notification n'était pas toujours enregistrée.
Du coup j'ai ouvert #92394 pour repartir sur le sujet initial et ta note 7.

Also available in: Atom PDF