Projet

Général

Profil

Support #85758

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

Ajouté par Benjamin Dauvergne il y a 3 mois. Mis à jour il y a 3 mois.

Statut:
En cours
Priorité:
Normal
Assigné à:
Version cible:
-
Début:
16 janvier 2024
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Non
Planning:
Non

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.


Demandes liées

Lié à Passerelle - Development #76394: toulouse-maelis: notification asynchrone du paiement des facturesFermé07 avril 2023

Actions

Historique

#1

Mis à jour par Benjamin Dauvergne il y a 3 mois

  • Assigné à mis à Nicolas Roche
  • Priorité changé de Normal à Immediat
#2

Mis à jour par Benjamin Dauvergne il y a 3 mois

  • Lié à Development #76394: toulouse-maelis: notification asynchrone du paiement des factures ajouté
#3

Mis à jour par Nicolas Roche il y a 3 mois

  • Priorité changé de Immediat à 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

Mis à jour par Benjamin Dauvergne il y a 3 mois

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

Mis à jour par Benjamin Dauvergne il y a 3 mois

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

Mis à jour par Nicolas Roche il y a 3 mois

  • Priorité changé de Haut à 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

Mis à jour par Benjamin Dauvergne il y a 3 mois

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

Mis à jour par Nicolas Roche il y a 3 mois

  • Priorité changé de Normal à 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

Mis à jour par Benjamin Dauvergne il y a 3 mois

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

Mis à jour par Benjamin Dauvergne il y a 3 mois

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

Mis à jour par Nicolas Roche il y a 3 mois

  • Statut changé de Nouveau à En cours
  • Priorité changé de Haut à 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

Formats disponibles : Atom PDF