Remises de chèques et de prélèvements

Cas d'usage : proposer à l'utilisateur la liste des comptes sur lesquels il peut déposer ses chèques ou ses prélèvements.

Chaque compte expose notamment estActif, destination, estOperationsCourantes, iban, bic, ics et planComptable. C'est planComptable.id qu'il faut transmettre à la création de la remise, pas l'id du compte.

• Ne gardez que les comptes où estActif vaut true.
• Écartez les comptes de placement (destination = rémunéré / à intérêt) : on n'y dépose pas de chèques.
• Pour une remise de prélèvements, ne gardez que les comptes dont ics est renseigné. Sans identifiant créancier SEPA, la banque ne peut pas traiter le fichier.
• Présentez en premier le compte où estOperationsCourantes vaut true : c'est le choix attendu dans la plupart des cas.

Cas d'usage : les chèques reçus ont été saisis un par un au fil de l'eau. Le gestionnaire en sélectionne un lot pour préparer le bordereau qu'il portera à la banque.

Répétez l'appel pour chaque exercice non clôturé (estCloture: false dans le tableau exercices de GET /v2/copro/{idCopro}.json). Un chèque de fin d'exercice peut en effet être remis au début du suivant. Le filtre modePaiement.id vaut =1 pour les chèques. Parmi les résultats, ne proposez que les encaissements dont depot est vide et estEnBanque vaut false.

{
  "depotComptabilite": {
    "type": "remise-de-cheques",
    "planComptable": 48213,
    "libelle": "Chèques appel de fonds T4",
    "reference": "0004127",
    "details": [90112, 90118, 90131]
  }
}

type, planComptable et details sont indispensables. Attention : l'API accepte pourtant une création sans type ni planComptable. Elle répond 201, et c'est le dépôt en banque qui échouera plus tard (Parcours E).

La réponse est un 201. Son champ message contient la remise créée, avec son id et sa reference (générée si vous l'avez laissée vide). La clé racine depot_comptabilite est acceptée au même titre que depotComptabilite.

Cas d'usage : le gestionnaire décide, copropriétaire par copropriétaire, du montant à prélever, puis génère d'un coup les prélèvements et le lot SEPA correspondant.

Contrairement aux chèques, les encaissements n'existent pas encore. On les crée d'abord, un par payeur, puis on les regroupe dans la remise.

Le payeur prélevé est un contact du copropriétaire. Le mandat SEPA se lit dans lots[].lotContacts[].preference : etatMandat (et son libellé libelleEtatMandat), iban, bic, referenceMandat, dateSignatureMandat, typeMandat. Écartez les liens de locataires (estLocataire) et ceux qui sont terminés (dateFin renseignée).

Tous les prélèvements du lot, et la remise elle-même, portent la même date : celle de la remise. Retrouvez dans GET /v2/copro/{idCopro}.json l'exercice dont dateDeDebut et dateDeFin encadrent cette date, et vérifiez que estCloture vaut false. La date ne doit pas non plus dépasser la date du jour.

{
  "encaissement": {
    "date": "2026-09-29 00:00:00",
    "coproprietaire": 9931,
    "contact": 22804,
    "montant": 45000,
    "comptabilite": 1
  }
}

Le 4 de la route est le mode de paiement « prélèvement ». Renseignez contact : c'est ce qui relie le prélèvement au mandat du payeur. comptabilite: 1 passe immédiatement l'encaissement sur le compte d'attente des prélèvements (voir le mouvement comptable). Relevez l'id renvoyé dans message.id.

{
  "depotComptabilite": {
    "type": "prelevement",
    "planComptable": 48213,
    "date": "2026-09-29 00:00:00",
    "details": [90340, 90341, 90342]
  }
}

Passez la même date qu'aux encaissements. Sinon la remise porterait une date différente de celle des prélèvements qui la composent. Cette reference sert ensuite d'identifiant du lot dans le fichier SEPA. Fournissez-en une que vous savez unique. Si vous la laissez vide, l'API génère une référence RMP-…, mais celle-ci peut reprendre une référence déjà utilisée (voir Limites).

Cas d'usage : conserver avec la remise la pièce transmise à la banque, c'est-à-dire le bordereau PDF de remise de chèques ou le fichier de prélèvement SEPA.

L'API ne produit pas ces fichiers. Vous générez le bordereau ou le fichier SEPA (pain.008.001.02) de votre côté, à partir des données déjà lues :

• créancier : le nom de la copropriété, et l'iban, le bic et l'ics du compte choisi au Parcours A ;
• identifiant du lot : la reference de la remise ;
• une transaction par ligne de details : le montant (en centimes), ainsi que l'IBAN, le BIC, la référence et la date de signature du mandat du contact de la ligne (Parcours C, étape 1).

{
  "libelle": "Prélèvement #RMP-20260929000014",
  "fichier": { "mode": "base64", "nom": "RMP-20260929000014.xml", "valeur": "PD94bWwgdmVyc2lvbj0iMS4wIi…" },
  "tags": ["Dépôt"]
}

Ici, le corps n'est pas enveloppé dans une clé racine. fichier.mode vaut base64 (contenu encodé) ou url (fichier déjà hébergé, accessible publiquement). En mode base64, fichier.nom est obligatoire : il donne l'extension du fichier stocké, qui ne doit contenir que des lettres, des chiffres ou des tirets. Sans lui, la requête est refusée en 400. La réponse est un 201 qui contient le document créé. Celui-ci apparaît ensuite dans documents[] de la remise.

Cas d'usage : le bordereau a été porté au guichet, ou le fichier SEPA transmis à la banque. On enregistre ce dépôt pour que les fonds apparaissent sur le compte bancaire de la copropriété.

{ "date": "2026-10-02 00:00:00" }

Ce corps est plat, sans clé racine. La même route accepte aussi libelle, reference et note. Elle répond 202 avec la remise mise à jour.

Le corps de la requête est vide. En cas de succès, la réponse est un 201 contenant le jeu d'écritures créé, et la remise renvoie désormais estEnBanque: true.

Cas d'usage : afficher l'historique des remises d'une copropriété avec leur état (en attente ou en banque), et ouvrir le détail de l'une d'elles.

La liste couvre la copropriété entière, tous exercices confondus. Chaque remise y est renvoyée avec ses details et ses documents. Le paramètre type restreint la liste aux chèques ou aux prélèvements. Les autres paramètres sont décrits dans Paramètres transverses.

Pour savoir quel bouton proposer sur une remise, lisez estEnBanque et estSupprimable :

• estEnBanque: false : on peut la déposer (Parcours E) ou la supprimer (Parcours H).
• estEnBanque: true et estSupprimable: true : on peut annuler le dépôt (Parcours G).
• estEnBanque: true et estSupprimable: false : la remise est figée, parce que son dépôt est rapproché ou que son exercice est clôturé.

Cas d'usage : un dépôt a été enregistré à tort ou à la mauvaise date. On veut revenir en arrière sans perdre la composition de la remise.

Cette route modifie des données alors qu'elle s'appelle en GET. Ne la placez jamais derrière un lien qu'un navigateur ou un robot pourrait précharger.

Effets observables :

• Les écritures de dépôt ne sont pas effacées : elles sont contre-passées par un jeu d'annulation à la même date. Les deux jeux restent visibles dans la comptabilité.
• La date de la remise repasse à null et estEnBanque à false.
• Les encaissements restent dans la remise.

Pour redéposer la remise, reprenez le Parcours E depuis l'étape 1 : il faut refixer une date, puisqu'elle a été effacée.

Cas d'usage : défaire une remise préparée par erreur, pour libérer ses chèques ou pour annuler un lot de prélèvements qui ne partira pas.

La suppression est refusée avec un 400 dans les mêmes cas que l'annulation (Parcours G). Sinon l'API répond 204 et enchaîne les effets suivants :

1. Si la remise était en banque, son dépôt est d'abord annulé par contre-passation, comme au Parcours G.
2. Les documents joints sont détachés de la remise.
3. Les encaissements sont détachés, pas supprimés. Ils redeviennent libres, avec leurs propres écritures intactes.
4. La remise disparaît. Les écritures de dépôt et leur annulation restent en comptabilité, sans lien avec aucune remise.