SOMMAIRE
| Sommaire | ||
|---|---|---|
|
Intégration de règlements
...
| 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 |
...
Nom de balise | Nom de champ | Obligatoire | Remarque |
|---|---|---|---|
PAYMENTTYPE | reglttyp | OUI | ENCASHMENT=1, DISBURSEMENT=2 |
THIRDPARTY | tiers | OUI | |
AMOUNT | MtDev | OUI | Montant en devise |
LABEL | 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 | 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'
}
}
]
}
}
]
}
|
...
| 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',
'LIB' : 'Règlement',
'RegltTyp' : '1',
'ChgEtat' : 'PORCHQ',
'EtatFin' : 'C30',
'DetailReglementtb':
[
{
'DetailReglement':
{
'MTDEVFIN' : '3595',
'PREFPIECE' : ' ',
'PIECE' : '87',
'TIERS' : 'C0000007',
'NatureOperation' : ' '
}
},
{
'DetailReglement':
{
'MTDEVFIN' : '2400 }
,
'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'
}
}
]
}
}
]
}
}"
} |
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':
[
{
'EnteteReglement':
{
'ETB' : '',
'TRANSACDT' : '20241020',
'DEV' : 'EUR',
'TIERS' : 'C0000004',
'MTDEV' : '1000',
'LIB' : 'Règlement 1',
'RegltTyp' : '1',
'ChgEtat' : 'PORESP',
'EtatFin' : 'E30',
'Transac' : '1',
'Noordre' : '1',
'DetailReglementtb':
[
{
'DetailReglement':
{
'MTDEVFIN' : '1000',
'PREFPIECE' : ' ',
'PIECE' : '10002797',
'TIERS' : 'C0000004',
'NatureOperation' : ' '
}
},
{
'DetailReglement':
{
'MTDEVFIN' : '900',
'PREFPIECE' : ' ',
'PIECE' : '10002797',
'TIERS' : 'C0000004',
'NatureOperation' : 'WPA'
}
},
]
}
},
{
'EnteteReglement':
{
'ETB' : '',
'TRANSACDT' : '20241020',
'DEV' : 'EUR',
'TIERS' : 'C0000004',
'MTDEV' : '900',
'LIB' : 'Règlement 2',
'RegltTyp' : '1',
'ChgEtat' : 'PORCHQ',
'EtatFin' : 'C30',
'Transac' : '1',
'Noordre' : '2',
'DetailReglementtb':
[
{
'DetailReglement':
{
'MTDEVFIN' : '900',
'PREFPIECE' : ' ',
'PIECE' : '10002797',
'TIERS' : 'C0000004',
'NatureOperation' : ''
}
}
]
}
}
]
}
}
|
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':
{
'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', 'PREFPIECEPREFIX' : ' ', 'PIECE' : '86394', 'TIERSTHIRDPARTY' : 'C0000007C0000004', 'NatureOperationOPERATION' : ' PAYMENT' } }, { 'DetailReglement': { 'amount' {: '1440', 'MTDEVFINmtDevregle' : '51440', 'PREFPIECEmtregle' : ' 1152', 'PIECEPREFIX' : '87', 'TIERSPIECE' : 'C0000007395', 'NatureOperationTHIRDPARTY' : 'WDRC0000004', } 'OPERATION' }: 'PAYMENT' ] } } }, { 'EnteteReglement': { 'ETB' : '', 'TRANSACDTDetailReglement' : '20210320', 'DEV' : 'EUR', { 'TIERSamount' : 'C000000340', 'MTDEVPREFIX' : '5000', 'LIBPIECE' : 'Règlement394', 'RegltTypTHIRDPARTY' : '1C0000004', 'ChgEtatOPERATION' : 'PORCHQWE', 'EtatFin' : 'C30', 'DetailReglementtb': } [}, { 'DetailReglement': { 'MTDEVFINamount' : '500060', 'PREFPIECEPREFIX' : ' ', 'PIECE' : '395', 'TIERSTHIRDPARTY' : 'C0000003C0000004', 'NatureOperationOPERATION' : 'WARWE' } } ] } } ] } }" } } |
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 |
...
| 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
Intégration L’intégration par fichier JSON de transaction de type remise en banque est disponible. Exemple , par exemple une opération de type C30 → C50 (remise en banque de chèques en portefeuille)
...
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
...
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 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
...