SOMMAIRE
| Sommaire | ||
|---|---|---|
|
Intégration de règlements
L'action pour l'intégration externe de règlements : integration_reglement
Balise de paramètres (parameters) | Niveau | Contenu | Obligatoire | Remarques |
|---|---|---|---|---|
dos | 1 | Dossier achat-vente | NON | Par défaut selon utilisateur |
doscpt | 1 | Dossier comptable | NON | Par défaut selon utilisateur |
etb | 1 | Etablissement | NON | Par défaut selon utilisateur |
Balise du corps (data) | Niveau | Contenu | Obligatoire | Remarques |
|---|---|---|---|---|
EnteteReglementtb | 1 | Tableau de règlements | OUI | Liste d’entêtes de règlements |
EnteteReglement | 2 | Entête de règlement | OUI | |
“nomChamp1”:”valeur1”, ”nomChamp2”:valeur2” | 3 | Liste des champs d’un entête de règlement avec les valeurs | OUI | |
DetailReglementtb | 3 | Tableau de détails des règlements | OUI | Pour identifier la facture et le montant du règlement |
DetailReglement | 4 | Détail de règlement | OUI | Permet de préciser les différences de règlements éventuellement associées par échéance et de préciser les éventuels acomptes |
“nomChamp1”:”valeur1”, ”nomChamp2”:valeur2” | 5 | Liste des champs d’un détail de règlement avec les valeurs | OUI |
| 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.7 11 -> Gérer ses règlements > Utilitaires et traitements du module règlement |
Un mapping existe entre les noms de champs du dictionnaire et les noms de balise à utiliser
Table RGLTJNLENT (EnteteReglement)
...
Nom de balise
...
Nom de champ
...
| 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
Table RGLTJNLENT (EnteteReglement)
Nom de balise | Nom de champ | Obligatoire | Remarque |
|---|---|---|---|
PAYMENTTYPE | reglttyp |
OUI | ENCASHMENT=1, DISBURSEMENT=2 | ||
THIRDPARTY | tiers | OUI | |
AMOUNT | MtDev |
OUI |
Montant en devise |
CURRENCY
Dev
LABEL |
transacDt
LibEcr | Libellé de l'écriture associée à la transaction crée | ||
DATE | transacDt | Date de la transaction. Si absente date de traitement du fichier | |
CURRENCY | Dev | OUI | |
FINALSTATEMENT | EtatFin |
dictionaryAddValue(DicoValues,"FINALSTATEMENT", "CHECK
OUI | Etat final CHECK=C30, CHECKINBANK=C50, TRANSFERT=V30, TRANSFERTINBANK=V50, SEPATRANSFERT=S30, SEPATRANSFERTINBANK=S50, INTERNATIONALVIREMENT=I30, INTERNATIONALVIREMENTINBANK=I50, DIRECTDEBIT=D30, DIRECTDEBITINBANK=D50 | ||
CHGETAT | CHGETAT | OUI | Code du changement d'état à utiliser |
TRANSAC | Voir le chapitre dédié plus bas. Attention usage selon règlement (factures ou remise en banque) | ||
NOORDRE |
Table RGLTJNLDET (DetailReglement)
Nom de balise | Nom de champ |
|---|
Obligatoire | Remarque |
|---|---|
THIRDPARTY | tiers |
OUI | |||
AMOUNT | MTDEVFIN | OUI | |
OPERATION | NatureOperation | OUI | PAYMENT=(blank), RegltDiff=WDR, ChangeDiff=WDC, Escompte=WE, Acompte=WAR, PARTIALPAYMENT=WPA |
PREFIX | PrefPiece | OUI | Obligatoire si gestion des prefixes |
PIECE | Piece | OUI | |
DUEDATE | EchOriDt |
Exemple de corps
...
| language | json |
|---|
...
TRANSAC | Voir le chapitre dédié plus bas. Attention usage selon règlement (factures ou remise en banque) | ||
NOORDRE |
Intégration de facture
La constitution d’une fichier d’intégration de facture doit suivre les règles métier.
Quelques précisions
La somme des détails doit toujours être égal au montant de l'échéance d’origine de la facture
Le
NatureOperation = ' 'dans un détail indique de prendre la nature du règlement prévuLes champs TRANSAC et NOORDRE de l’entête de règlement ont un impact fort sur l’intégration
Un numéro TRANSAC différent (par exemple 1 puis 2) donnera un traitement distinct des transactions pour obtenir des écritures séparées
Un numéro NOORDRE permet d’indiquer une chronologie au sein d’un même TRANSAC
Exemple de corps
| Bloc de code | ||
|---|---|---|
| ||
'data':{ 'EnteteReglementtb': [ { 'EnteteReglement': { 'ETB' : '', 'TRANSACDT' : '20210320', 'DEV' : 'EUR', 'TIERS' : 'C0000007', 'MTDEV' : '5995', 'LIB' : 'Règlement', 'RegltTyp' : '1', 'ChgEtat' : 'PORCHQ', 'EtatFin' : 'C30', 'DetailReglementtb': [ { 'DetailReglement': { 'MTDEVFIN' : '3595', 'PREFPIECE' : ' ', 'PIECE' : '87', 'TIERS' : 'C0000007', 'NatureOperation' : ' ' } }, { 'DetailReglement': { 'MTDEVFIN' : '2400', 'PREFPIECE' : ' ', 'PIECE' : '86', 'TIERS' : 'C0000007', 'NatureOperation' : ' ' } }, { 'DetailReglement': { 'MTDEVFIN' : '5', 'PREFPIECE' : ' ', 'PIECE' : '87', 'TIERS' : 'C0000007', 'NatureOperation' : 'WDR' } } ] } }, { 'EnteteReglement': { 'ETB' : '', 'TRANSACDT' : '20210320', 'DEV' : 'EUR', 'TIERS' : 'C0000003', 'MTDEV' : '5000', 'LIB' : 'Règlement', 'RegltTyp' : '1', 'ChgEtat' : 'PORCHQ', 'EtatFin' : 'C30', 'DetailReglementtb': [ { 'DetailReglement': { 'MTDEVFIN' : '5000', 'PREFPIECE' : ' ', 'PIECE' : '', 'TIERS' : 'C0000003', 'NatureOperation' : 'WAR' } } ] } } ] } |
Exemple complet flux JSON
| Bloc de code | ||
|---|---|---|
| ||
{
"action":"WEB_SERVICE_INFINITY",
"access_token":"{{TOKEN}}",
"param":"
{
'action': {
'swinfinity': 'integration_reglement',
'parameters':
{
'doscpt': '998',
'dos': '998',
'etb': '1'}
}
},
'data':
{
{
'EnteteReglementtb':
[
{
'EnteteReglement':
{
'ETB' : '',
'TRANSACDT' : '20210320',
'DEV' : 'EUR',
'TIERS' : 'C0000007',
'MTDEV' : '5995',
[
{
'EnteteReglement':
{
'ETB' : '',
'TRANSACDT' : '20210320',
'DEV 'LIB' : 'Règlement',
'RegltTyp' : '1',
'ChgEtat' : 'PORCHQ',
'EtatFin' : 'C30',
'DetailReglementtb':
[
{
'DetailReglement':
{
'MTDEVFIN' : '3595',
'PREFPIECE' : ' ',
'PIECE' : '87',
'TIERS' : 'C0000007',
'NatureOperation' : ' '
}
},
{
'DetailReglement':
{
'MTDEVFIN' : '2400',
'PREFPIECE' : 'EUR ',
'TIERS' 'PIECE' : 'C000000786',
'MTDEV
'TIERS' : '5995C0000007',
'NatureOperation' : ' '
'LIB' : 'Règlement',
'RegltTyp' : '1',
'ChgEtat' : 'PORCHQ',
'EtatFin' : 'C30',
'DetailReglementtb':
[
}
},
{
'DetailReglement':
{
'MTDEVFIN' : '5',
'PREFPIECE' : ' ',
'PIECE' : '87',
'TIERS' : 'C0000007',
'NatureOperation' : 'WDR'
}
}
]
}
},
{
'EnteteReglement':
{
'ETB' : '',
'TRANSACDT' : '20210320',
'DEV' : 'EUR',
'TIERS' : 'C0000003',
'MTDEV' : '5000',
'LIB' : 'Règlement',
'RegltTyp' : '1',
'ChgEtat' : 'PORCHQ',
'EtatFin' : 'C30',
'DetailReglementtb':
[
{
'DetailReglement':
{
'MTDEVFIN' : '5000',
'PREFPIECE' : ' ',
'PIECE' : '',
'TIERS' : 'C0000003',
'NatureOperation' : 'WAR'
}
}
]
}
}
]
}
{
'DetailReglement':
}"
} |
Compléments intégration facture - règlement multiple
Exemple d’utilisation TRANSAC et NOORDRE
Dans le cas de 2 entêtes de règlement dans le même fichier JSON pour régler une même facture, par exemple 1900€ à régler avec 1000€ espèce et 900 par chèque, il faudra
Regrouper nécessairement les 2 entêtes dans un même numéro TRANSAC
Utiliser le NOORDRE pour imposer l’ordre de traitement (donc 1 puis 2)
Donner le premier entête avec le premier règlement (dans l’exemple 1000€ espèce) ET un reste WPA de l'écart au montant de l'échéance d’origine (ici 900€ de WPA)
Donner le second entête avec le second règlement (dans l’exemple 900€ chèque)
Exemple flux complet JSON pour deux règlements
| Bloc de code | ||
|---|---|---|
| ||
{ 'action': {'swinfinity': 'integration_reglement', 'parameters': { 'doscpt': '998', 'dos': '998', {'etb': '1' } }, 'data': { 'EnteteReglementtb': 'MTDEVFIN' : '3595', [ { 'PREFPIECEEnteteReglement' : ' ', { 'PIECEETB' : '87', 'TRANSACDT' : '20241020', 'TIERSDEV' : 'C0000007EUR', 'TIERS' : 'C0000004', 'NatureOperationMTDEV' : ' 1000', 'LIB' : 'Règlement 1', } 'RegltTyp' : '1', 'ChgEtat' : 'PORESP', }, 'EtatFin' : 'E30', 'Transac' : '1', 'Noordre' : '1', { 'DetailReglementtb': [ 'DetailReglement': { { 'DetailReglement': 'MTDEVFIN' : '2400', { 'PREFPIECEMTDEVFIN' : ' 1000', 'PIECE''PREFPIECE' : '86 ', 'TIERSPIECE' : 'C000000710002797', 'NatureOperationTIERS' : ' C0000004', 'NatureOperation' : ' ' } } }, }, { { 'DetailReglement': 'DetailReglement': { { 'MTDEVFIN' : '5900', 'PREFPIECE' : ' ', 'PIECE' : '8710002797', 'TIERS' : 'C0000007C0000004', ''NatureOperation' : 'WDR' WPA' } }, } ] ] } }, } { },'EnteteReglement': { 'EnteteReglementETB' : '', { 'TRANSACDT' : '20241020', 'ETBDEV' : 'EUR', 'TRANSACDTTIERS' : '20210320C0000004', 'DEVMTDEV' : 'EUR900', 'TIERS''LIB' : 'C0000003Règlement 2', 'MTDEV' 'RegltTyp' : '50001', 'LIBChgEtat' : 'RèglementPORCHQ', 'EtatFin' : 'C30', 'RegltTypTransac' : '1', 'Noordre' : '2', 'ChgEtatDetailReglementtb' : 'PORCHQ', [ 'EtatFin' : 'C30', { 'DetailReglementtb': 'DetailReglement': [ { 'DetailReglementMTDEVFIN' : '900', 'PREFPIECE' : { ' ', 'MTDEVFINPIECE' : '500010002797', 'PREFPIECETIERS' : ' C0000004', 'PIECENatureOperation' : '', } 'TIERS' : 'C0000003', } 'NatureOperation' : 'WAR' ] } } ] } } |
Exemple flux complet JSON pour deux règlements avec escompte
A noter que dans ce exemple, le TRANSAC est différent, ce qui donnera 2 transactions distinctes
| Bloc de code |
|---|
{ 'action': {'swinfinity': 'integration_reglement', 'parameters': } { 'doscpt': '998', 'dos': '998', 'etb': '1' } }, 'data': { ] 'EnteteReglementtb': [ } { } 'EnteteReglement': ] { } }" } |
Format de la réponse :
...
Balise
...
Contenu
...
error
Anomalie technique de l’appel du service web
0 = pas n’anomalie, autre valeur = anomalie
...
result
...
Détail du résultat fonctionnel de l’appel du service web
resultcode= 0 => pas d’anomalie fonctionnelle la demande est bien traitée
resultcode<>0 => anomalie fonctionnelle/métier dont la raison est indiquée dans errormessage
La response contient notamment la réponse avec les éventuelles erreurs errormessage et la transaction générée dans transactionId
...
| 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": ""
} |
'ETB' : '',
'TRANSACDT' : '20241020',
'DEV' : 'EUR',
'TIERS' : 'C0000004',
'MTDEV' : '980',
'LIB' : 'Règlement 1',
'RegltTyp' : '1',
'ChgEtat' : 'PORESP',
'EtatFin' : 'E30',
'Transac' : '1',
'Noordre' : '1',
'DetailReglementtb':
[
{
'DetailReglement':
{
'MTDEVFIN' : '980',
'PREFPIECE' : ' ',
'PIECE' : '10002797',
'TIERS' : 'C0000004',
'NatureOperation' : ' '
}
},
{
'DetailReglement':
{
'MTDEVFIN' : '918.20',
'PREFPIECE' : ' ',
'PIECE' : '10002797',
'TIERS' : 'C0000004',
'NatureOperation' : 'WPA'
}
},
{
'DetailReglement':
{
'MTDEVFIN' : '20',
'PREFPIECE' : ' ',
'PIECE' : '10002797',
'TIERS' : 'C0000004',
'NatureOperation' : 'WE'
}
}
]
}
},
{
'EnteteReglement':
{
'ETB' : '',
'TRANSACDT' : '20241020',
'DEV' : 'EUR',
'TIERS' : 'C0000004',
'MTDEV' : '918.20',
'LIB' : 'Règlement 2',
'RegltTyp' : '1',
'ChgEtat' : 'PORCHQ',
'EtatFin' : 'C30',
'Transac' : '2',
'Noordre' : '1',
'DetailReglementtb':
[
{
'DetailReglement':
{
'MTDEVFIN' : '918.20',
'PREFPIECE' : ' ',
'PIECE' : '10002797',
'TIERS' : 'C0000004',
'NatureOperation' : ''
}
}
]
}
}
]
}
} |
Compléments intégration facture - règlement en devises (V10.11)
Le règlement en devises par l’intégration de règlements suit quelques règles
Gestion des montants total du règlement dans l’entête du règlement (
EnteteReglement)Si le règlement est en devise différente de la devise du dossier, le montant total du règlement en devise MTDEV dans l’entête est obligatoire.
Si le montant total dans la devise du dossier MT est renseigné, on considère le règlement à taux de change bloqué et il sera égal au rapport entre les montants. Si le règlement n’est pas dans la devise des factures, il faut obligatoirement faire le traitement à devise bloquée.
Sinon, le taux de change sera récupéré dans la table des taux de change
Gestion des montants dans les détails de règlement(
DetailReglement)Description des champs montants
MTDEVREGLE est le montant effectif du règlement dans la devise du règlement
MTREGLE est le montant effectif du règlement dans la devise du dossier
AMOUNT est le montant dans la devise de la facture que l’on va régler
Cas 1 : le règlement est à taux de change bloqué
Les montants effectifs du règlement (MTDEVREGLE, MTREGLE) sont obligatoires
Cas 2 : le règlement n’est pas à taux de change bloqué
On considère dans ce cas là que la devise du règlement est dans la devise de la facture. Et donc le montant du règlement est égal au montant à régler (MTDEVREGLE = AMOUNT) et le montant à régler dans la devise du dossier est calculé en automatique à partir du taux de change à date.
Si le règlement est dans la devise du dossier, alors l’un des deux champs MTDEVREGLE ou MTREGLE suffit (l'autre sera copié à l’identique), mais dans tous les cas les deux champs MTREGLE et MTDEVREGLE doivent être égaux (erreur si différents ou non renseignés)
Exemple flux complet JSON pour règlement en devise
Dans l’exemple, règlement de 2400 TND pour 2 factures en TND avec un escompte pour chaque facture
| Bloc de code | ||
|---|---|---|
| ||
'action': {
'swinfinity': 'integration_reglement',
'parameters': {
'withlog': '1',
'doscpt': '998',
'dos': '998',
'etb': ''
}
},
'data':
{'EnteteReglementtb':
[
{
'EnteteReglement':
{
'ETB' : ' ',
'TRANSACDT' : '20231010',
'currency' : 'TND',
'THIRDPARTY' : 'C0000004',
'MtDev' : '2400',
'Mt' : '1920',
'LABEL' : 'Règlement de 2400 TND de 2 factures en TND avec un escompte pour chaque facture ',
'PAYMENTTYPE' : 'ENCASHMENT',
'FINALSTATEMENT' : 'CHECK',
'BQC' : 'BNP',
'DetailReglementtb':
[
{
'DetailReglement':
{
'amount' : '960',
'mtDevregle' : '960',
'mtregle' : '768',
'PREFIX' : '',
'PIECE' : '394',
'THIRDPARTY' : 'C0000004',
'OPERATION' : 'PAYMENT'
}
},
{
'DetailReglement':
{
'amount' : '1440',
'mtDevregle' : '1440',
'mtregle' : '1152',
'PREFIX' : '',
'PIECE' : '395',
'THIRDPARTY' : 'C0000004',
'OPERATION' : 'PAYMENT'
}
},
{
'DetailReglement':
{
'amount' : '40',
'PREFIX' : '',
'PIECE' : '394',
'THIRDPARTY' : 'C0000004',
'OPERATION' : 'WE'
}
},
{
'DetailReglement':
{
'amount' : '60',
'PREFIX' : '',
'PIECE' : '395',
'THIRDPARTY' : 'C0000004',
'OPERATION' : 'WE'
}
}
]
}
}
]
}
} |
Format de la réponse :
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
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": ""
} |
Intégration de remise en banque
L’intégration par fichier JSON de transaction de type remise en banque est disponible, par exemple une opération de type C30 → C50 (remise en banque de chèques en portefeuille)
à partir de la version X.7 service pack 217e
à partir de la version X.9 service pack 219c
à partir de la version X.10 service pack 220b
à partir de la version X.11 service pack 221a
Si l'état final de type n’est pas un virement et est associé à un bordereau, il faudra passer par l'étape de confection du bordereau pour générer l'écriture associée à la transaction créée.
Si l'état final de type remise est un virement ou n'est pas associé à un bordereau, l'écriture associée à la transaction créée est générée lors du traitement du fichier JSON .
Le mécanisme général est identique à l’intégration ci-dessus, mais voici quelques précisions pour le cas de la remise en banque
Donnée à mettre dans le fichier JSON
Dans RGLTJNLENT (EnteteReglement) on doit définir
La devise et le montant total de la transaction à effectuer (Facultatif ). Si présent le total des transactions (DetailReglement) sera comparé à ce montant.
Le type de règlement (PAYMENTTYPE) 1 Encaissement, 2 décaissement. (Obligatoire)
le code du changement d'état à utilisé (Obligatoire)
la banque de destination (Obligatoire)
Dans RGLTJNLDET (DetailReglement) Il faut renseigner
soit un n° de transaction existant correspondant à le remise en portefeuille
TRANSAC : le n° de la transaction qui à permis la passage de la position 1 à la position 2 (Ex : transaction de remise en portefeuille de chèque)
NOORDRE : le n° d’ordre n’est pas obligatoire (N° 1 pris par défaut)
soit des informations permettant de retrouver la transaction. Si plusieurs transactions correspondent aux critères fournis on prend celle avec le N° le plus petit
TIERS (THIRDPARTY) : Code tiers
ETATORI : Etat des règlements à traiter. Doit correspondre à un des état d’entrées possible pour le changement d'état précisé dans l’entête
MTORI : Montant de la transaction en devise du dossier
ou MTDEVORI (AMOUNT) montant en devise et DEV (CURRENCY) : devise
Exemple de fichier
Remise en banque avec N° de transaction
...
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
...