Documentation d'intégration · API Datacopro

Budget & Échéancier

Comment consulter les budgets d'une copropriété, faire voter une version, puis en dériver un plan de financement (échéancier) et ses appels de fonds.

À propos de ce guide. Ce document décrit uniquement le contrat de l'API Datacopro : les appels HTTP disponibles, leurs paramètres et les réponses qu'ils renvoient. Aucune connaissance d'un logiciel de gestion de copropriété en particulier n'est nécessaire pour le suivre — les cas d'usage cités servent uniquement à motiver l'ordre des appels.
01

Modèle & périmètre

Tous les appels de ce guide sont adressés à une copropriété précise (idCopro) : c'est le périmètre racine de chaque route. À l'intérieur de ce périmètre, deux notions structurent le sujet :

Budget groupe de lignes

Une version chiffrée du budget d'un exercice et d'un type de poste donné. Un exercice peut porter plusieurs versions successives (brouillons, corrections, version votée) — voir Parcours A.

idtypeversion estVotedateVoteestLastBudget budgets[]echeanciernote tagsdateCreation

estLastBudget indique si cette version est la plus récente pour son exercice et son type, indépendamment de son statut de vote — voir Parcours A.

Ligne de budget budgets[]

Un montant affecté à un poste comptable, à l'intérieur d'un budget.

idmontantplanComptable montantRealise*tva*

* présents uniquement sur la route qui expose le réalisé — voir Parcours A.

Échéancier plan de financement

Le calendrier d'appels de fonds calculé pour un budget voté. Un seul échéancier existe par (exercice ou travaux, type de poste) — voir Parcours D.

idecheances[]type notetags exercice*travaux*

* présents seulement quand la route consultée détaille l'échéancier (pas sur un appel de liste allégé).

Échéance echeances[]

Une ligne du calendrier : soit un appel de fonds, soit une affectation d'un paiement déjà reçu.

idnumerotype datemontantpart estAppeleestGenereestEnvoye comptesourceversionBudget details*documentsAppels*jeuxDecritures*

compte identifie le compte bancaire visé par un appel de fonds (non applicable à une affectation) ; source identifie l'origine du paiement pour une affectation (non applicable à un appel). * présents uniquement en consultation détaillée d'une échéance précise — voir Parcours F.

02

Contrôle d'accès

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 : toute tentative sur un périmètre non autorisé renvoie 403 Forbidden, qu'il s'agisse d'un budget, d'un échéancier ou d'une échéance. Il n'y a pas de restriction supplémentaire propre à ces deux entités au-delà de ce contrôle de périmètre.

À savoir en pratique Le jeton d'accès se transmet en paramètre de requête (access_token=…) plutôt qu'en en-tête Authorization: Bearer — cette dernière forme est rejetée. Toutes les routes de ce guide sont préfixées /v2 et servies depuis https://syndic.datacopro.org en production, ou https://preprod-syndic.datacopro.org sur la plateforme de test — par exemple GET https://syndic.datacopro.org/v2/copro/{idCopro}/echeancier en production.
03

Parcours fonctionnels

Ces six parcours suivent le cycle de vie réel d'un budget : de sa consultation à son vote, puis du plan de financement qui en découle jusqu'à la gestion de chaque échéance individuelle.

A

Consulter les budgets d'un exercice

Cas d'usage : afficher l'état budgétaire courant d'une copropriété, avec ou sans le détail des montants déjà réalisés.

GET/v2/copro/{idCopro}/exercice/{idExercice}/budgets/{type}

Renvoie toutes les versions de budget existantes pour cet exercice et ce type de poste — brouillons compris.

GET/v2/copro/{idCopro}/last-budget/{type}/{idAssociation}

Ne renvoie que la version la plus récente, votée ou non. idAssociation est l'identifiant de l'exercice (ou de l'opération de travaux pour ce type de poste).

GET/v2/copro/{idCopro}/exercice/{idExercice}/budget-vote-et-realise

Réservé aux charges courantes : renvoie la version votée en ajoutant, sur chaque ligne, les montants effectivement réalisés (montantRealise, tva) — des champs absents des deux appels précédents.

GET/v2/copro/{idCopro}/exercice/{idExercice}/budget-vote

La même version votée que ci-dessus, mais sans les montants réalisés — également réservé aux charges courantes. Pour les autres types de poste, l'équivalent « version votée uniquement » est exposé par une route dédiée par poste (voir la référence des endpoints) plutôt que par cette route générique.

Pourquoi « Dernier budget » et « budget voté » sont deux notions distinctes, et ni budgets/{type} ni last-budget ne filtrent sur le statut de vote : les deux renvoient des brouillons aussi bien que des versions votées, et aucun des deux ne renvoie montantRealise. Un intégrateur qui veut la version de référence pour la comptabilité doit soit lire le champ estVote sur les éléments renvoyés par ces deux appels, soit interroger directement une route « vote » dédiée.
Limite Le nombre de versions par exercice et type n'est pas plafonné : un budget peut accumuler de nombreux brouillons au fil des corrections. Prévoir l'affichage en conséquence plutôt que de supposer une ou deux versions.
B

Préparer une nouvelle version de budget

Cas d'usage : saisir un projet de budget avant qu'il ne soit soumis au vote de l'assemblée générale.

POST/v2/copro/{idCopro}/exercice/{idExercice}/budget/{type}
{
  "groupeBudgetExercice": {
    "isVote": 0,
    "note": "Projet soumis à l'AG du 14/03",
    "budgets": [
      { "cle": 4821, "type": 9012, "montant": 128000 },
      { "planComptable": 55310, "montant": 42500 }
    ]
  }
}

Chaque ligne de budgets désigne un poste soit par la paire cle (clé de répartition) + type (poste comptable générique), soit directement par un planComptable existant de la copropriété. Les montants s'expriment en centimes.

Pourquoi Le numéro de version n'est pas à la charge de l'appelant : l'API l'attribue elle-même en incrémentant la version la plus haute déjà connue pour cet exercice et ce type. Un version envoyé dans la requête est ignoré.
Limite Il n'existe pas d'appel de mise à jour partielle : chaque POST crée une version complète et indépendante. Modifier une ligne signifie renvoyer l'intégralité des lignes du budget dans une nouvelle version. Les lignes envoyées à montant nul sont silencieusement ignorées — elles ne créent pas de ligne à zéro.
C

Voter un budget

Cas d'usage : entériner la version soumise à l'assemblée générale comme référence officielle de l'exercice.

PUT/v2/copro/{idCopro}/last-budget/{type}/{idAssociation}/voter

Marque la version la plus récente comme votée et enregistre sa date de vote. Le vote est un appel séparé de la création : il n'existe pas de paramètre « voter » à passer directement dans le POST du Parcours B.

D

Définir le plan de financement (échéancier)

Cas d'usage : une fois le budget voté, produire le calendrier d'appels de fonds envoyé aux copropriétaires.

POST/v2/copro/{idCopro}/echeancier
{
  "echeancier": {
    "type": 4110,
    "exercice": 3305,
    "calculer": 1,
    "echeances": [
      { "numero": 1, "type": "appel", "date": "2026-01-05 00:00:00", "part": 1, "libelle": "1er appel" },
      { "numero": 2, "type": "appel", "date": "2026-04-05 00:00:00", "part": 1, "libelle": "2e appel" }
    ]
  }
}

Le type de l'échéancier (ici 4110) est un code de calendrier propre à la comptabilité de la copropriété : ce n'est pas le même espace de valeurs que le type de poste utilisé comme paramètre de chemin dans les routes de budget (Parcours A/B). Chaque échéance porte en plus un numero d'ordre, un type (appel de fonds, ou affectation d'un paiement déjà reçu), une date et une part — le poids relatif de cette échéance parmi les échéances de même type : des parts égales répartissent le montant total à parts égales entre elles, des parts inégales le répartissent proportionnellement. Au moins une échéance est obligatoire.

Illustration C'est typiquement immédiatement après avoir enregistré le résultat d'un vote d'assemblée générale qu'un logiciel de gestion déclenche cet appel : le budget vient d'être marqué voté (Parcours C), et le plan de financement en est dérivé dans la foulée.
Pourquoi calculer: 1 déclenche un calcul réellement effectué côté serveur : l'API répartit elle-même chaque échéance entre les lots de la copropriété selon les clés de répartition en vigueur. Il n'est pas nécessaire — ni possible — de soumettre une répartition par lot déjà calculée dans cette requête.
Limite Un seul échéancier peut exister par couple (exercice — ou opération de travaux — , type de poste) : une deuxième création sur le même couple échoue en 400. Passé ce point, tout ajustement se fait par modification (Parcours E), jamais par une nouvelle création. La création échoue également en 400 s'il n'existe pas de budget voté avec au moins une ligne non nulle pour ce type.
E

Corriger un échéancier existant

Cas d'usage : ajuster le calendrier après une correction budgétaire votée en cours d'exercice.

PUT/v2/copro/{idCopro}/echeancier/{idEcheancier}

Accepte le même format de corps que la création. La liste d'échéances soumise remplace la définition du plan, mais pas de façon purement destructrice.

Pourquoi L'API tente de rapprocher chaque échéance soumise d'une échéance déjà connue (par numéro et type, puis par date/part/source si elle a déjà été appelée) pour décider s'il faut la mettre à jour, la créer ou la supprimer. Une échéance déjà appelée qui disparaît du corps de la requête sans être retrouvée par ce rapprochement provoque une erreur explicite plutôt qu'une suppression silencieuse — l'historique des appels déjà envoyés aux copropriétaires est protégé.
Limite Le rattachement de l'échéancier (son exercice ou son opération de travaux) et son type ne peuvent plus être changés dès qu'au moins une de ses échéances a généré une écriture comptable. Prévoir ce cas en amont plutôt que de compter sur la modification pour reclasser un échéancier existant.
F

Gérer le cycle de vie d'une échéance

Cas d'usage : consulter le détail d'un appel de fonds précis, ajouter un appel isolé sans passer par un échéancier complet, ou revenir sur une échéance saisie par erreur.

POST/v2/copro/{idCopro}/echeance/{typeEcheance}

Ajoute un appel de fonds ponctuel, indépendamment de tout échéancier — utile pour un appel exceptionnel qui ne doit pas modifier le plan de financement existant.

GET/v2/copro/{idCopro}/echeance/{idEcheance}

Seule route à renvoyer details, documentsAppels et jeuxDecritures — la liste des écritures comptables déjà générées à partir de cette échéance.

POST/v2/copro/{idCopro}/echeance/{idEcheance}/annuler
DELETE/v2/copro/{idCopro}/echeance/{idEcheance}
Limite Annuler ou supprimer une échéance est refusé (400) dès que son exercice est clôturé. Supprimer une échéance déjà appelée exige en plus de passer explicitement un indicateur de confirmation dans la requête — une suppression « silencieuse » d'un appel déjà envoyé n'est jamais le comportement par défaut.
04

Référence des endpoints

MéthodeRouteRôle
GET/v2/copro/{idCopro}/exercice/{idExercice}/budgets/{type}Toutes les versions de budget d'un exercice et d'un type de poste
POST/v2/copro/{idCopro}/exercice/{idExercice}/budget/{type}Crée une nouvelle version de budget
GET/v2/copro/{idCopro}/last-budget/{type}/{idAssociation}Dernière version de budget, votée ou non
PUT/v2/copro/{idCopro}/last-budget/{type}/{idAssociation}/voterMarque la dernière version comme votée
DELETE/v2/copro/{idCopro}/budget/{idGroupeBudget}Supprime une version de budget (refusé si un échéancier y est lié)
GET/v2/copro/{idCopro}/exercice/{idExercice}/budget-vote-et-realiseBudget voté des charges courantes, avec montants réalisés
GET/v2/copro/{idCopro}/exercice/{idExercice}/budget-voteBudget voté des charges courantes, sans le réalisé
GET/v2/copro/{idCopro}/exercice/{idExercice}/budget-a-voterDernière version non encore votée
GET/v2/copro/{idCopro}/exercice/{idExercice}/budget-avances-de-tresorerieBudget voté du poste avance de trésorerie / fonds de roulement
GET/v2/copro/{idCopro}/exercice/{idExercice}/budget-fonds-travauxBudget voté du poste fonds de travaux / fonds de réserve
GET/v2/copro/{idCopro}/exercice/{idExercice}/budget-avances-travauxBudget voté du poste avances sur travaux (obsolète)
GET/v2/copro/{idCopro}/exercice/{idExercice}/budget-autres-avancesBudget voté du poste autres avances
POST/v2/copro/{idCopro}/echeancierCrée un échéancier sur un budget voté
PUT/v2/copro/{idCopro}/echeancier/{idEcheancier}Modifie un échéancier existant
GET/v2/copro/{idCopro}/echeanciersListe les échéanciers de la copropriété
GET/v2/copro/{idCopro}/echeancier/{idEcheancier}Détail d'un échéancier, échéances comprises
DELETE/v2/copro/{idCopro}/echeancier/{idEcheancier}Supprime un échéancier
GET/v2/copro/{idCopro}/echeance/{idEcheance}Détail complet d'une échéance (pièces jointes, écritures)
POST/v2/copro/{idCopro}/echeance/{typeEcheance}Ajoute un appel de fonds isolé, hors échéancier complet
POST/v2/copro/{idCopro}/echeance/{idEcheance}/annulerAnnule une échéance
DELETE/v2/copro/{idCopro}/echeance/{idEcheance}Supprime une échéance
POST / GET / DEL/v2/copro/{idCopro}/echeance/{idEcheance}/document(s)[/{idDocument}]Pièces jointes d'une échéance

Toutes ces routes attendent une extension de format explicite en fin de chemin (par exemple .json).

05

Paramètres transverses

Les routes de liste (échéanciers, budgets) acceptent trois familles de paramètres de requête génériques, communs à l'ensemble de l'API :

Limite displays ne permet pas de « débloquer » un champ qui n'appartient pas à l'ensemble déjà exposé par la route choisie. Concrètement, il est impossible de demander montantRealise via displays sur l'appel générique GET .../budgets/{type} (Parcours A) : ce champ n'existe que dans la réponse de budget-vote-et-realise. De même, details ou jeuxDecritures sur une échéance ne sont disponibles qu'en consultant l'échéance individuellement (Parcours F), jamais via displays sur une liste d'échéanciers. Le bon réflexe est de choisir la route qui expose nativement le champ recherché, plutôt que de chercher à l'obtenir par ce paramètre.
06

Limites & pièges connus

✕
Un exercice et un type de poste peuvent accumuler un nombre illimité de versions de budget : aucune limite n'est appliquée à la création (Parcours B).
✕
« Dernière version » et « version votée » sont deux notions différentes qu'il faut demander explicitement l'une ou l'autre (Parcours A).
✕
Un seul échéancier par (exercice ou travaux, type de poste) est autorisé ; passé ce point, toute correction doit passer par la modification, jamais par une nouvelle création (Parcours D).
✕
La répartition par lot d'un échéancier est calculée côté serveur via calculer: 1 — elle ne s'envoie pas précalculée (Parcours D).
✕
Une modification d'échéancier qui omet une échéance déjà appelée échoue plutôt que de la supprimer silencieusement (Parcours E).
✕
Un budget ne peut pas être supprimé tant qu'un échéancier lui est rattaché (référence des endpoints, DELETE .../budget/{id}).
✕
Une échéance ne peut plus être annulée ni supprimée une fois son exercice clôturé (Parcours F).
✕
displays ne fait que filtrer les champs déjà exposés par la route appelée — il n'ouvre jamais l'accès à un champ propre à une autre route (Paramètres transverses).
07

Questions de validation

Q1. Si j'envoie deux fois de suite une création de budget pour le même exercice et le même type, que se passe-t-il ?
Aucune erreur : chaque appel crée une version distincte (version 1, puis version 2, etc.), l'API attribuant elle-même le numéro. Le second appel ne remplace pas le premier — les deux versions coexistent et sont toutes deux renvoyées par un appel de consultation ultérieur, tant qu'aucune n'est explicitement supprimée. Voter l'une d'elles (Parcours C) ne fait pas disparaître les autres : cela ne fait qu'ajouter un statut « votée » à la version choisie. Parcours B · Parcours C
Q2. Comment distinguer un montant « prévisionnel voté » d'un montant « réalisé » dans la réponse ?
Ce n'est pas un indicateur porté par le champ lui-même : c'est la route appelée qui détermine si montantRealise est présent, indépendamment du statut de vote. Les routes génériques de consultation (budgets/{type}, last-budget) renvoient du prévisionnel — voté ou non, à vérifier via estVote — mais jamais de réalisé. Seule la route dédiée au réalisé des charges courantes (budget-vote-et-realise) ajoute montantRealise à chaque ligne, et uniquement sur la version votée. Parcours A · Modèle & périmètre
Q3. Puis-je calculer moi-même la répartition par lot d'un échéancier plutôt que de la demander à l'API ?
Non : le paramètre calculer ne sert pas à activer un calcul optionnel côté client, il déclenche le calcul réel effectué par le serveur à partir des clés de répartition de la copropriété. Il n'existe pas de mode où l'appelant fournirait sa propre répartition ligne par lot dans la requête de création ou de modification. Parcours D