Gestion des problèmes de dédoublement côté ASP

[pskl]

Lié aussi à #859

Problème:

• dedoublonnage pas possible sur les étudiants à l'étranger
• volumétrie: 1500 doublons
• 2 stages dans le même fichier devraient être fusionnés si on suivait les recommendations de l'ASP
• question posée: 2 dossiers pour une DA (2 idDoss differents côté ASP), est-ce un risque de notre côté pour la modélisation?
• 1 ticket court-terme, 1 tache moyen terme

Etape 1 (court-terme):

• fix la creation et la modification sur les individus: quand on connait déjà un student côté ASP (présence d'un asp_individu_id sur le Student) envoyer l'individu avec modification = O (balise XML dans le fichier de paiements) et idem pour le dossier (schooling) : quand on le connaît, on envoie en mode mofication = O

Etape 2 (long-terme):

• fusionner les dossiers dans le fichier d'envoi

[pskl]

Si on met "O" ca veut dire que tout ce qui est inclus dans la balise remplace ce qu'ils ont pour l'individu. Donc si on renvoit des balises d'information vides ca re-initialise à vide de leur côté... C'est pour ca que quand on a l'id de notre côté on renvoit toujours modification = "N"...

def individu(xml)
      if new_record?
        xml.natureindividu("P")
        PersPhysique.from_payment_request(payment_request).to_xml(xml)
        xml.adressesindividu { Adresse.from_payment_request(payment_request).to_xml(xml) }
        xml.coordpaiesindividu { CoordPaie.from_payment_request(payment_request).to_xml(xml) }
      end

      xml.listedossier { Dossier.from_payment_request(payment_request).to_xml(xml) }
    end

On pourrait envoyer tout le temps toutes les infos qu'on a de notre côté avec modification = "O" en elevant le doublon sur CoordPaie.from_payment_request

[pskl]

Pour ce qui est des dossiers (schooling): Vu qu'au moment de la compilation du fichier d'envoi on ne prend en compte que la dernière requête de paiement (une seule balise prestadoss) si on passe la modification à "O" cela risquerait d'écraser de la donnée côté ASP (notamment l'historique des Prestadoss je pense) donc il est préférable de la garder à "N".

@pskl : OK, donc on aura côté ASP plusieurs dossier pour une seule DA dès lors qu'on aura plusieurs PFMPs, donc plusieurs demandes de paiement. Quand est-il si on relance des demandes de paiment pour une pmfp n-1, sachant qu'on a payé n?

[pskl]

Pour ce qui est de l'étape 2: grouper les dossiers quand plusieurs requêtes de paiement dans le lot d'envoi correspondent à la même personne. C'est faisable mais cela requiert des changements de code plus profonds (à l'heure actuelle notre unitée de base est la payment_request sans groupement particulier).

Il faudrait une étape de pre-traitement dans le job de création du Fichier -> ASP::Request#send!

[gtournadre]

En lien avec #859