...
| Info |
|---|
Retrouvez également des informations dans la page du traitement d’intégration des règlements concernant les règles métier : Espace produit (par exemple Divalto infinity 10.11 -> Gérer ses règlements > Utilitaires et traitements du module règlement |
| Astuce |
|---|
Selon votre version et service pack, l’utilitaire ERP prend en entrée un fichier au format JSON qui correspond uniquement aux informations métier du service web ou le format complet. Versions à partir de 2025 : L’utilitaire sait traiter les 2 formats Versions avant 2025 : La zone technique (action, acces_token, param) n’est pas traitée, et ne doit pas être donnée. C'est directement le contenu de “param” qui est attendu par cet utilitaire  |
Un mapping existe entre les noms de champs du dictionnaire et les noms de balise à utiliser
...
Balise | Contenu |
|---|---|
error | Anomalie technique de l’appel du service web 0 = pas n’anomalie, autre valeur = anomalie Dans ce cas la balise |
result | Détail du résultat fonctionnel de l’appel du service web
La |
Exemple de réponse
...
| language | json |
|---|
Voir le chapitre ci-dessous qui impacte la réponse https://divalto.atlassian.net/wiki/spaces/PAI/pages/edit-v2/10530423103#Retour-d%E2%80%99erreur-multiples-(V10.12)
| Bloc de code | ||
|---|---|---|
| ||
{
"error": 0,
"result": "{\"label\": \"infinity\",\"codeScript\": \"integration_reglement\",\"result\":{\"common\":{\"resultcode\": \"0\",\"errormessage\": \"Intégration règlements des échéances terminée |Consultez le livre de bord"},\"response\":\"transactionId\": \"1354\"}}",
"txterr": "",
"infos": ""
} |
...
Remise en banque sans n° de transaction
...
Retour d’erreur multiples (V10.12)
Jusqu’en version 10.12, le retour (dans la réponse) se faisait dans un format unique, c’est à dire que seul une seule information remontait, par exemple le dernier numéro de transaction ou un message d’erreur unique en cas d’anomalie.
La version 10.12 introduit une modification
dans la réponse, qui retourne un TABLEAU JSON dans la “response”
dans la demande, qui peut indiquer un numéro pour faire le lien entre une demande et la réponse
Lors de la demande, la balise “REGLEMENTNUM” (numérique) peut être ajoutée dans l’entête EnteteReglement. Son utilisation aura pour effet
d'être sauvegardé dans l’entête de journal de la transaction générée dans l’onglet Identifiant sous le nom “N° de règlement JSON”
d'être retourné dans la réponse
| Info |
|---|
Le numéro REGLEMENTNUM doit au minimum être un incrément d’unicité à l’intérieur d’une demande JSON ; idéalement un numéro chrono chez l’appelant permet une meilleure traçabilité |
Exemple de corps de demande avec REGLEMENTNUM en entête (ici 17 et 18)
| Bloc de code | ||
|---|---|---|
| ||
'data':
{
'EnteteReglementtb':
[
{
'EnteteReglement':
{
'PAYMENTTYPE' :'ENCASHMENT',
'CHGETAT' :'REMCDI',
'BQC' :'BNP',
'REGLEMENTNUM' :'17',
'LABEL' :'Traitement sans N° transac',
'DetailReglementtb':
[
{
'DetailReglement':
{
'MTORI' : '3400',
'ETATORI' : 'C30',
'TIERS' : 'C0000001'
}
},
{
'DetailReglement':
{
'MTORI' : '2400',
'ETATORI' : 'C30',
'TIERS' : 'C0000001'
}
}
]
}
},
{
'EnteteReglement':
{
'PAYMENTTYPE' :'ENCASHMENT',
'CHGETAT' :'REMCDI',
'BQC' :'BNP',
'REGLEMENTNUM' :'18',
'LABEL' :'Traitement avec N° transac',
'DetailReglementtb':
[
{
'DetailReglement':
{
'TRANSAC' : '661'
}
},
{
'DetailReglement':
{
'TRANSAC' : '508'
}
}
]
}
}
]
} |
Exemple de réponse à ce REGLEMENTNUM en entête (ici deux erreurs sur 17 et 18)
Le message est sous la forme :
Réussite : Règlement n°$1 : OK - La transaction $2 a été générée.
Echec : Règlement n°$1 : message d’erreur
...