Comment consulter le cycle de vie d'un règlement (paiement ou remboursement) déjà comptabilisé — sa liste, son détail, la régénération de ses écritures, sa validation à plusieurs regards, et les conditions de sa suppression.
Tous les appels de ce guide sont adressés à une copropriété précise (idCopro) et à un exercice comptable précis (idExercice) de cette copropriété. Un règlement appartient à un seul exercice à la fois — celui dont la période couvre sa date. L'API ne distingue pas « règlement » et « remboursement » par un champ dédié : c'est le signe du champ montant qui porte cette information (positif pour un paiement, négatif pour un remboursement) — il n'existe pas de valeur de type à filtrer pour séparer les deux.
Un mouvement de paiement (ou de remboursement) rattaché à un exercice, un tiers et un compte comptable, avec son mode de paiement.
* fournisseur est un champ hérité conservé pour compatibilité : ne vous y fiez pas pour un règlement dont le tiers n'est pas un fournisseur — utilisez tiers, qui est générique quel que soit le type de tiers réglé.
estRapproche indique si un rapprochement bancaire a déjà été posé sur ce règlement. estSupprimable et estModifiable ne sont pas des indicateurs stockés : ils reflètent, au moment de la lecture, le résultat des mêmes règles générales qu'à la suppression et à la modification (voir Limites & pièges connus).
Le destinataire (ou l'émetteur, pour un remboursement) du règlement. Son type détermine le vocabulaire fonctionnel employé, mais pas la structure de l'appel.
Le détail des opérations (factures, salaires, cotisations…) couvertes par ce règlement, chacune avec la part de montant qui lui est allouée.
Un règlement unique peut couvrir plusieurs opérations en une seule fois — cette liste porte la répartition du montant total entre elles.
Trois circuits de validation indépendants, chacun avec son propre statut : comptable, administrative, metier.
* date est renvoyée en lecture mais ignorée si elle est soumise en écriture — voir Parcours D.
Chaque appel nécessite un jeton d'accès OAuth2, et le client doit être explicitement autorisé sur la copropriété visée par idCopro, sinon la réponse est un 403. L'exercice et le règlement passés dans le chemin sont en plus vérifiés comme appartenant réellement à cette copropriété — et, pour un règlement, à l'exercice indiqué : un identifiant valide mais rattaché ailleurs est refusé, même si le client est par ailleurs autorisé sur la copropriété.
/v2 et servies depuis https://syndic.datacopro.org en production, ou https://preprod-syndic.datacopro.org sur la plateforme de test.
Ces cinq parcours couvrent la vie d'un règlement une fois qu'il existe : sa consultation, la régénération de ses écritures comptables, sa progression dans un circuit de validation, et sa suppression.
Cas d'usage : afficher l'ensemble des règlements et remboursements passés sur une copropriété — fournisseurs, salaires, cotisations, redevances de servitude, loyers confondus — filtrable à l'affichage.
Un règlement appartient à un seul exercice : afficher tous les règlements d'une copropriété toutes périodes confondues suppose de répéter cet appel pour chaque exercice à couvrir — il n'existe pas de route qui les liste tous en une fois indépendamment de l'exercice.
Cas d'usage : afficher la fiche complète d'un règlement précis — son tiers, son compte, ses opérations couvertes, ses écritures comptables et son état de validation.
La réponse inclut systématiquement les écritures comptables déjà générées (jeuxDecritures) — il n'y a pas de paramètre à ajouter pour les obtenir, elles font partie de la réponse par défaut de cette route.
Cas d'usage : forcer la reconstruction des écritures comptables d'un règlement dont la comptabilisation semble incohérente, sans passer par une suppression puis une recréation.
reglement précise seulement quel type d'entité est visé par l'identifiant qui suit. Le paramètre de type doit correspondre exactement à l'entité réelle, sinon l'appel échoue à résoudre l'entité ciblée.
Cas d'usage : faire progresser (ou revenir sur) l'approbation d'un règlement dans un circuit à plusieurs regards — comptable, administratif, métier — avant qu'il ne soit considéré comme définitivement acquis.
{
"validation": {
"comptable": { "statut": "validé" }
}
}
Seuls les champs présents dans la requête sont pris en compte — pas de remplacement complet de l'objet. Les trois circuits (comptable, administrative, metier) sont indépendants et se mettent à jour séparément : modifier l'un ne touche pas le statut des deux autres.
validation, la correction des autres informations du règlement : libelle, note, referenceComptable, tiers, cstModePaiement (le mode de paiement, exposé en lecture comme modePaiement), compte (ou planComptable), et date. Changer le compte, le mode de paiement, le libellé ou la date régénère automatiquement les écritures comptables du règlement — le même effet que le Parcours C, mais déclenché en conséquence plutôt que sur demande explicite. Changer le tiers suit un chemin de vérification distinct, propre à la cohérence du rattachement aux opérations déjà réglées.
statut sont acceptées : à valider, indéfini, validé. Une valeur hors de cette liste n'est ni rejetée ni signalée par une erreur : elle est silencieusement ignorée, et le statut du circuit visé reste inchangé. De même, un champ date soumis dans l'objet de validation est toujours ignoré : la date de validation n'est jamais pilotable par ce biais. Cet appel — comme la suppression du Parcours E — est intégralement refusé en 400 si l'exercice du règlement est déjà clôturé, quels que soient les champs envoyés.
Cas d'usage : retirer un règlement saisi par erreur, tant qu'aucun rapprochement bancaire n'a été posé dessus.
400. Il faut d'abord défaire ce rapprochement (voir le guide Rapprochement bancaire) avant de pouvoir supprimer le règlement. La suppression échoue aussi, comme la modification, si l'exercice du règlement est déjà clôturé.
operationsReglements) avant de supprimer le règlement lui-même : les factures, salaires ou cotisations concernés redeviennent donc non réglés plutôt que de rester associés à un règlement qui n'existe plus.
| Méthode | Route | Rôle |
|---|---|---|
| GET | /v2/copro/{idCopro}/exercice/{idExercice}/reglements.{_format} | Liste des règlements d'un exercice |
| GET | /v2/copro/{idCopro}/exercice/{idExercice}/reglement/{idExerciceReglement}.{_format} | Détail d'un règlement |
| POST | /v2/copro/{idCopro}/exercice/{idExercice}/reglement/paiement/{idCstModePaiement}.{_format} | Crée un règlement (détaillé dans le guide Rapprochement bancaire) |
| POST | /v2/copro/{idCopro}/exercice/{idExercice}/reglement/{idExerciceReglement}.{_format} | Modifie un règlement (champs et/ou statut de validation) |
| DELETE | /v2/copro/{idCopro}/exercice/{idExercice}/reglement/{idExerciceReglement}.{_format} | Supprime un règlement |
| POST | /v2/copro/{idCopro}/exercice/{idExercice}/ecritures/reglement/{idExerciceReglement}/rejouer.{_format} | Régénère les écritures comptables du règlement |
| POST | /v2/copro/{idCopro}/exercice/{idExercice}/reglement/{idExerciceReglement}/document/{idDocument}.{_format} | Associe un document justificatif au règlement |
| PUT | /v2/copro/{idCopro}/exercice/{idExercice}/reglement/{idExerciceReglement}/delier-document.{_format} | Retire le document associé |
Toutes ces routes attendent une extension de format explicite en fin de chemin (par exemple .json). Associer ou retirer un document justificatif suit les mêmes règles d'accès que le reste de ce guide (§02) ; aucune restriction métier additionnelle (rapprochement, clôture) ne s'applique actuellement à ces deux appels.
La liste des règlements d'un exercice accepte les mêmes familles de paramètres génériques que le reste de l'API :
filters — restreint les résultats, par exemple sur le tiers ou le mode de paiement.displays — restreint ou ouvre l'ensemble des champs renvoyés, parmi ceux déjà présents dans la réponse de la route appelée ; n'ajoute jamais un champ qui n'y figure pas par défaut.jeuxDecritures) et ses opérations couvertes : sur une liste volumineuse, restreindre les champs demandés via displays réduit sensiblement la taille de la réponse par rapport à une demande qui laisse passer tous les champs par défaut.
POST, pas en PUT — contrairement à la convention employée par d'autres entités comptables de l'API pour leur propre endpoint de modification (Parcours D).à valider, indéfini, validé) est silencieusement ignoré, sans erreur ni changement d'état (Parcours D).date d'un circuit de validation est toujours ignoré en écriture, même s'il est envoyé (Parcours D).fournisseur ne reflète fidèlement le tiers que pour un règlement dont le tiers est effectivement un fournisseur : pour tout autre type de tiers (salarié, organisme collecteur, servitude, locataire), c'est le champ générique tiers qu'il faut lire (Modèle & périmètre).reglement n'est qu'une des valeurs possibles (Parcours C).400, dès que le règlement est rapproché en tout ou partie — pas seulement s'il l'est intégralement. Il n'existe pas de suppression forcée qui outrepasserait cette règle : il faut d'abord défaire le rapprochement via l'endpoint dédié du guide Rapprochement bancaire, puis réessayer la suppression. C'est une cause de refus indépendante de l'autre condition qui bloque aussi la suppression : un exercice clôturé (voir Parcours E) — les deux peuvent se cumuler. Parcours E"en attente"), l'API me renvoie-t-elle une erreur ?statut hors liste est silencieusement ignorée : le statut du circuit visé reste inchangé, sans qu'aucun message ne le signale dans la réponse. Un intégrateur qui envoie une valeur non prévue doit donc relire le règlement pour vérifier que le changement a réellement eu lieu, plutôt que de se fier au seul succès de l'appel. Parcours D400 — la même condition que pour la suppression (Parcours E). Parcours C, D, E