Aller au contenu principal

Enregistrer les paiements

Une facture émise n'est soldée que lorsque son règlement est constaté. En enregistrant chaque paiement dans Scribee, vous tenez deux obligations d'une seule écriture : le statut d'encaissement de la facture, qui passe automatiquement à 212 Encaissée dès que le montant réglé de la facture atteint le net à payer, et la déclaration d'e-reporting des paiements pour les factures de prestations de services B2C et B2B internationales dont la TVA est due à l'encaissement, quand l'entreprise émettrice est soumise à cette obligation. Votre système saisit le règlement ; Scribee dérive le reste.

Ce que Scribee fait pour vous​

  • Statut d'encaissement automatique : quand le montant réglé de la facture atteint payable_amount, la facture passe à 212 Encaissée, depuis n'importe lequel des statuts où l'enregistrement d'un paiement est accepté - les statuts intermédiaires sont facultatifs, une facture 200 Déposée passe directement à 212. Si une correction ou une suppression fait repasser le total sous ce montant, la facture revient à 211 Paiement transmis.
  • Le montant à solder est le net à payer, pas le total TTC : Scribee mesure le règlement contre payable_amount (BT-115, le net à payer), et non contre tax_inclusive_amount (BT-112, le total TTC). Sur une facture qui ne porte aucun montant déjà payé - la très grande majorité - les deux valeurs sont égales et rien ne change pour vous. Elles divergent dès qu'une partie de la facture a été encaissée à l'émission : ce montant est exposé sous prepaid_amount (BT-113), et payable_amount ne porte que le reste. Une facture de 35.11 TTC dont prepaid_amount vaut 20.00 a un payable_amount de 15.11 : elle est soldée par un versement de 15.11, et remaining_amount part de 15.11, pas de 35.11. Si vous rapprochez vos règlements sur remaining_amount, comparez-le à payable_amount, jamais à tax_inclusive_amount.
  • Les acomptes déduits incluent leur TVA : sur une facture provenant d'une intégration comptable, prepaid_amount correspond au montant déjà payé TTC dans la devise de la facture. Par exemple, un acompte de 100.00 hors taxe avec 20.00 de TVA représente 120.00 déjà payés. Pour un total de facture de 240.00 TTC sans arrondi, payable_amount vaut alors 120.00. La TVA de la facture reste calculée avant la déduction de cet acompte.
  • Un payable_amount à 0 est une facture intégralement prépayée : ce n'est pas une valeur manquante. remaining_amount vaut alors 0 dès l'émission et la facture est considérée soldée sans qu'aucun paiement soit enregistré. Sur les factures déposées par une intégration comptable de Scribee - jamais sur une facture créée ou importée par l'API partenaire, même déclarée déjà payée (Émettre une facture de vente) - le passage à 212 Encaissée est asynchrone : il intervient une fois la facture devenue éligible, jamais dans la réponse d'un appel, et un statut relu dans la foulée peut encore être le précédent. L'évènement 212 correspondant est daté de l'encaissement ; le montant encaissé se lit sous prepaid_amount sur la facture, jamais sur l'évènement de cycle de vie, et la liste des paiements reste vide. Le seul cas d'absence de valeur est payable_amount à null, que certaines factures importées ne renseignent pas : Scribee retombe alors sur tax_inclusive_amount.
  • Le montant réglé n'est pas toujours la somme de vos paiements : sur les workspaces où la gestion de l'escompte est activée, un escompte appliqué compte dans le montant réglé au même titre qu'un paiement. La facture peut donc passer à 212 alors que le champ paid_total de la facture reste inférieur à payable_amount. Le champ qui fait foi est remaining_amount, qui tient compte des deux ; ne recalculez pas le solde à partir de paid_total seul.
  • Devise héritée : currency_code n'est jamais envoyé ni modifiable ; chaque paiement reprend la devise de la facture, côté serveur.
  • Déclaration des paiements tenue à jour : pour une facture de vente dont le code d'exigibilité de la TVA est absent, vaut 72 ou vaut 432 - les deux codes désignent le même point d'exigibilité, sur deux listes UNTDID -, et dont l'entreprise émettrice est soumise à l'obligation de déclaration des paiements à la date du paiement, chaque création, correction ou suppression de paiement est répercutée dans la déclaration d'e-reporting de la période, avec ventilation par taux de TVA (voir Déclarer les paiements). Les trois conditions doivent être réunies : tout autre tax_due_date_code, toute facture d'achat, et tout régime de TVA sans obligation de déclaration des paiements sont exclus - sans erreur ni signal côté API. Une vente dont toutes les ventilations de TVA sont en catégorie G ou O, non soumise à la TVA en France, est exclue de la même façon. La correction et la suppression ne se comportent pas de la même façon quand l'obligation disparaît : déplacer un paiement déjà déclaré vers une date non soumise laisse la ligne sur son rapport d'origine, alors que la suppression la retire toujours (Déclarer les paiements). Seules les ventes que l'e-reporting couvre sont déclarées - vente B2B internationale, dont l'acheteur est identifié sans SIREN ou porte un SIREN mais est établi hors du territoire de TVA français, ou vente B2C, dont l'acheteur ne porte aucun identifiant - et certaines ventes sont en outre exclues quel que soit leur code d'exigibilité : acheteur identifié par un SIREN ou un SIRET et établi dans le territoire de TVA français, dont le statut 212 Encaissée déclare l'encaissement ; vendeur établi en Guyane, à Mayotte, dans une collectivité d'outre-mer ou dans les TAAF ; vente intégralement autoliquidée ; livraison de biens. Une vente n'est déclarée que pour ses ventilations autres que AE, G et O, une facture double que pour sa part services, et les montants sont déclarés en euros, au taux de la date du paiement. Quand la déclaration ne peut pas être établie, le paiement est enregistré sans ligne de déclaration, sans signal côté API (Déclarer les paiements).

Enregistrer un paiement​

Cet appel crée un paiement sur la facture, dans votre compte de production. Rien n'est transmis au destinataire de la facture. Pour une facture de vente couverte par la déclaration des paiements (voir plus haut), le paiement est ajouté au brouillon de la déclaration d'e-reporting de sa période.

POST /api/v1/invoices/{invoice_id}/payments accepte amount et payment_date (obligatoires), plus payment_means_code, reference, note, payer_role et allocations (facultatifs, les deux derniers décrits plus bas). Le token doit porter les scopes read write. La facture doit être dans l'un des statuts suivants : 200 Déposée, 202 Reçue, 203 Mise à disposition, 204 Prise en charge, 205 Approuvée, 206 Approuvée partiellement, 207 En litige, 208 Suspendue, 211 Paiement transmis ou 212 Encaissée. Tout autre statut - dont 000 Brouillon, 210 Refusée, 213 Rejetée, 220 Annulée et 221 Erreur de routage - est refusé.

curl -X POST https://app.scribee.tech/api/v1/invoices/YOUR_INVOICE_ID/payments \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "payment": {
      "amount": 1000.0,
      "payment_date": "2025-01-10",
      "payment_means_code": "30",
      "reference": "VIR-2025-0110"
    }
  }'

La réponse est un 201 Created :

{
  "data": {
    "id": 87,
    "amount": 1000.0,
    "payment_date": "2025-01-10",
    "payment_means_code": "30",
    "currency_code": "EUR",
    "reference": "VIR-2025-0110",
    "note": null,
    "payer_role": "buyer",
    "allocations": [],
    "created_at": "2025-01-10T09:15:00Z"
  }
}

payment_means_code suit la liste UNTDID 4461 restreinte aux valeurs 1, 10, 20, 30, 31, 48, 49, 57, 58, 59 et 97 - notamment 30 virement, 48 carte bancaire, 49 prélèvement, 58 virement SEPA, 59 prélèvement SEPA.

Les paiements partiels s'enregistrent de la même façon : plusieurs appels, un paiement chacun. Le statut de la facture ne change qu'au moment où le cumul atteint le net à payer (payable_amount).

Chaque paiement inscrit néanmoins un évènement de cycle de vie 212 portant son propre montant, jamais le cumul réglé : la règle P1.15 de l'annexe 7 déclare la somme reçue à chaque encaissement, et un paiement partiel est un encaissement. Les deux cas se lisent donc différemment :

  • Un paiement qui solde la facture déclenche la transition collect : lifecycle_state passe à collected et l'évènement porte le montant de ce paiement.
  • Un paiement partiel inscrit son évènement 212 sans faire bouger lifecycle_state.

Un évènement 212 dans l'historique ne suffit donc pas à conclure que la facture est encaissée - c'est lifecycle_state qui fait foi. Si vous préférez déclarer l'encaissement vous-même plutôt que de le dériver d'un paiement, l'endpoint de transition accepte collect avec un champ collected_amount ; voir Le cycle de vie d'une facture.

La transmission de l'évènement 212 au PPF (Portail Public de Facturation) est réservée aux factures dont la TVA est exigible à l'encaissement : tax_due_date_code à 72 (ou 432), toute facture d'acompte, ou, sans tax_due_date_code, toute facture dont le cadre de facturation (BT-23) n'est pas un cadre de biens (code commençant par B). Une facture dont tax_due_date_code vaut 5, 3, 29 ou 35 ne déclare pas ses évènements 212 au PPF.

Préciser le payeur et la ventilation par taux​

Par défaut, un paiement est réputé versé par l'acheteur, et Scribee répartit lui-même le montant de son évènement 212 entre les taux de TVA de la facture, au prorata. Deux champs facultatifs remplacent ces deux hypothèses quand elles ne tiennent pas, typiquement quand une part de la facture est réglée par un tiers - un assureur, un organisme qui verse une subvention, une compensation - et que cette part figure sur la facture sous prepaid_amount (BT-113).

  • payer_role : buyer (valeur par défaut) ou third_party_payer. third_party_payer désigne le tiers qui règle la part portée par prepaid_amount. Le tiers n'est pas identifié dans le paiement.
  • allocations : une liste de blocs vat_rate / amount. Fournie, elle est exactement la ventilation que déclare l'évènement 212 de ce paiement, à la place du prorata. Absente, le prorata s'applique. Chaque paiement renvoie payer_role et allocations, cette dernière vide quand aucune ventilation n'a été fournie.

Exemple : une facture de 1200.00 TTC au taux de 20 %, dont un assureur prend en charge 900.00. Elle porte prepaid_amount à 900.00, donc payable_amount à 300.00. L'acheteur règle ses 300.00 en déclarant le total au taux de la facture, moins la part du tiers au taux 0 :

curl -X POST https://app.scribee.tech/api/v1/invoices/YOUR_INVOICE_ID/payments \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "payment": {
      "amount": 300.0,
      "payment_date": "2025-01-10",
      "payer_role": "buyer",
      "allocations": [
        { "vat_rate": 20, "amount": 1200.0 },
        { "vat_rate": 0, "amount": -900.0 }
      ]
    }
  }'

L'assureur règle sa part, déclarée au taux 0 :

curl -X POST https://app.scribee.tech/api/v1/invoices/YOUR_INVOICE_ID/payments \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "payment": {
      "amount": 900.0,
      "payment_date": "2025-01-12",
      "payer_role": "third_party_payer",
      "allocations": [
        { "vat_rate": 0, "amount": 900.0 }
      ]
    }
  }'

Les règles suivantes sont vérifiées à l'enregistrement. Un écart est refusé en 422 et rien n'est enregistré :

  • Les amount des blocs totalisent exactement l'amount du paiement.
  • Chaque vat_rate est un taux porté par la facture, ou 0.
  • Un même vat_rate n'apparaît qu'une fois par signe : au taux 0, un bloc positif et un bloc négatif peuvent coexister ; aucun autre taux ne se répète.
  • Chaque amount de bloc est non nul, porte au plus deux décimales, et ne peut être négatif qu'au taux 0.
  • Pour l'acheteur, les blocs négatifs au taux 0 déduisent la part du tiers : leur cumul, sur l'ensemble des paiements de l'acheteur de la facture, ne dépasse pas prepaid_amount.
  • Pour third_party_payer, la facture doit porter un prepaid_amount strictement positif, allocations est obligatoire et chacun de ses blocs est positif, et le cumul des paiements du tiers sur la facture ne dépasse pas prepaid_amount.

Ce que le payeur change :

  • Chaque paiement inscrit un évènement 212 et un seul, portant son propre montant, qu'il vienne de l'acheteur ou du tiers.
  • Sur une facture où il reste un net à payer (payable_amount supérieur à zéro), le paiement du tiers règle une part que payable_amount déduit déjà : il inscrit son 212, mais ne fait jamais passer la facture à 212 Encaissée et n'est pas compté dans paid_total. Seuls les paiements de l'acheteur soldent payable_amount.
  • Sur une facture intégralement prépayée (payable_amount à 0), l'encaissement s'enregistre une seule fois, quel que soit le payeur, et pour exactement prepaid_amount : un paiement d'un autre montant est refusé, un second paiement aussi. Pour corriger, modifiez ou supprimez le paiement existant.

Consulter les paiements d'une facture​

GET /api/v1/invoices/{invoice_id}/payments renvoie tous les paiements de la facture, du plus récent au plus ancien (payment_date, puis created_at). La liste n'est pas paginée : ni meta, ni paramètre page, ni filtre. Le scope read suffit.

curl https://app.scribee.tech/api/v1/invoices/YOUR_INVOICE_ID/payments \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN"
{
  "data": [
    {
      "id": 88,
      "amount": 770.0,
      "payment_date": "2025-01-20",
      "payment_means_code": "59",
      "currency_code": "EUR",
      "reference": "PM0012ABCDEF",
      "note": null,
      "payer_role": "buyer",
      "allocations": [],
      "created_at": "2025-01-20T04:02:11Z"
    },
    {
      "id": 87,
      "amount": 1000.0,
      "payment_date": "2025-01-10",
      "payment_means_code": "30",
      "currency_code": "EUR",
      "reference": "VIR-2025-0110",
      "note": null,
      "payer_role": "buyer",
      "allocations": [],
      "created_at": "2025-01-10T09:15:00Z"
    }
  ]
}

Un paiement isolé se lit sur GET /api/v1/invoices/{invoice_id}/payments/{id}, avec les mêmes champs.

Tous les paiements listés ne viennent pas de vous​

La liste contient aussi les paiements que Scribee a enregistrés lui-même : prélèvement GoCardless encaissé, rapprochement bancaire confirmé dans l'interface. Aucun champ de la réponse n'indique la source. Deux indices seulement : un prélèvement GoCardless porte payment_means_code 59 et une reference égale à l'identifiant du paiement GoCardless ; un paiement issu du rapprochement bancaire porte en reference la référence de l'écriture comptable de son opération bancaire, BQ-AAAA-MM-NNNN : BQ, l'année et le mois de l'écriture - en principe ceux de l'opération ; une correction ultérieure de la date de l'opération ne les change pas -, puis l'identifiant Scribee de l'opération - celui que renvoie bank_operation_id - sur au moins quatre chiffres, par exemple BQ-2026-07-0144 (Écritures comptables bancaires).

Ces paiements portaient auparavant une autre reference. Ceux qui portaient encore la valeur attribuée à leur création ont été repris dans ce format ; leur id n'a pas changé. Si vous aviez conservé l'ancienne reference pour retrouver un de ces paiements, rapprochez-le désormais par son id.

Ne supposez donc pas que tout paiement listé est supprimable ni entièrement modifiable, et conservez les identifiants renvoyés par vos propres POST si vous devez distinguer vos écritures des autres.

Corriger un paiement​

Cet appel modifie le paiement en place et recalcule immédiatement le statut d'encaissement de la facture ainsi que, le cas échéant, la déclaration d'e-reporting - la ventilation par taux de TVA est recalculée, et le paiement est déplacé vers la déclaration d'une autre période si payment_date change. Si la facture est sortie du périmètre de la déclaration des paiements depuis que le paiement y a été répercuté - acheteur désormais identifié par un SIREN et établi dans le territoire de TVA français, lignes désormais toutes des biens, TVA passée en autoliquidation ou sur les débits -, la correction retire la ligne de la déclaration ; si cette déclaration est close, le retrait est différé (Déclarer les paiements). Exception : un paiement issu d'un rapprochement bancaire confirmé n'accepte que note, et cette modification ne recalcule rien (voir plus bas).

PATCH /api/v1/invoices/{invoice_id}/payments/{id} accepte les mêmes champs que la création ; seuls les champs envoyés changent. La réponse est un 200 portant le paiement à jour. Le token doit porter les scopes read write.

payer_role ne se modifie pas : le renvoyer avec la valeur enregistrée passe, une autre valeur est refusée en 422 - supprimez le paiement puis enregistrez-le à nouveau. allocations, s'il est envoyé, remplace l'ensemble des blocs du paiement ; omis, les blocs existants sont conservés.

Modifier amount sur un paiement qui porte des blocs exige de renvoyer allocations : les blocs conservés ne totaliseraient plus le montant, et la requête est refusée en 422. Quand la ventilation change, l'écart de montant ne suffit plus à la décrire : Scribee inscrit un évènement 212 qui annule en entier le précédent - le montant du paiement avant modification, de signe opposé, avec ses blocs éventuels de signe opposé -, puis un 212 qui déclare le paiement avec sa nouvelle ventilation.

Un paiement issu d'un prélèvement GoCardless n'est modifiable qu'en partie : amount, payment_date et payment_means_code sont refusés en 422 (voir ci-dessous), et seuls reference et note restent modifiables. Le refus se déclenche sur la présence de la clé dans la charge utile, pas sur un écart de valeur : renvoyer le montant déjà enregistré est refusé aussi.

Un paiement issu d'un rapprochement bancaire confirmé n'accepte que note : toute autre clé est refusée en 422 dependent_records (voir ci-dessous), même envoyée avec la valeur déjà enregistrée, et la requête est alors refusée en entier - la note qu'elle portait n'est pas appliquée non plus. Un PATCH qui ne porte que note change la note et rien d'autre : le montant, la date, la référence, la facture et le lien avec l'opération bancaire restent tels quels, le statut d'encaissement de la facture ne bouge pas, aucun évènement de cycle de vie n'est inscrit - donc aucun invoice.lifecycle_event.created n'est émis -, et ni la déclaration d'e-reporting ni l'écriture comptable de l'opération ne sont recalculées. Ce PATCH ne porte aucun contrôle de version : deux modifications concurrentes de la note s'appliquent l'une après l'autre, et la dernière l'emporte.

curl -X PATCH https://app.scribee.tech/api/v1/invoices/YOUR_INVOICE_ID/payments/YOUR_PAYMENT_ID \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "payment": { "amount": 900.0 } }'
{
  "data": {
    "id": 87,
    "amount": 900.0,
    "payment_date": "2025-01-10",
    "payment_means_code": "30",
    "currency_code": "EUR",
    "reference": "VIR-2025-0110",
    "note": null,
    "payer_role": "buyer",
    "allocations": [],
    "created_at": "2025-01-10T09:15:00Z"
  }
}

Supprimer un paiement​

Cet appel supprime le paiement, retire la ligne correspondante du brouillon de déclaration d'e-reporting et, si le total repasse sous le net à payer, ramène la facture de 212 Encaissée à 211 Paiement transmis.

La suppression inscrit un évènement 212 du montant du paiement, de signe opposé ; si le paiement portait des blocs, cet évènement les reprend, signes inversés.

DELETE /api/v1/invoices/{invoice_id}/payments/{id} répond 204 sans corps. Le token doit porter read, plus destroy ou write.

Deux refus sont possibles, en 422 : un paiement issu d'un prélèvement GoCardless n'est jamais supprimable, ni un paiement issu d'un rapprochement bancaire confirmé. Ces cas sont détaillés plus bas.

curl -X DELETE https://app.scribee.tech/api/v1/invoices/YOUR_INVOICE_ID/payments/YOUR_PAYMENT_ID \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN"

Ce qui se passe ensuite​

  • Chaque bascule de statut - passage à 212 Encaissée comme retour à 211 Paiement transmis - enregistre un événement de cycle de vie sur la facture et déclenche l'événement invoice.lifecycle_event.created vers vos endpoints de notification (voir Webhooks). Le détail des statuts est dans Le cycle de vie d'une facture.
  • Pour une facture de vente B2C ou B2B internationale dont la TVA est due à l'encaissement, et dont l'entreprise émettrice est soumise à l'obligation de déclaration des paiements, le paiement est ventilé par taux de TVA, en euros, dans la déclaration d'e-reporting de sa période, créée si nécessaire. Les factures d'achat, les ventes portant tout autre code d'exigibilité, les ventes dont toutes les ventilations de TVA sont en catégorie G ou O et les entreprises dont le régime de TVA ne porte pas cette obligation ne donnent lieu à aucune déclaration de paiement : l'enregistrement n'y sert qu'au suivi du règlement. Les exclusions propres à la vente - acheteur identifié par un SIREN ou un SIRET et établi dans le territoire de TVA français, dont le statut 212 Encaissée déclare l'encaissement, vendeur établi hors du territoire de TVA, vente intégralement autoliquidée, livraison de biens - sont détaillées dans Déclarer les paiements.
  • Rien n'est transmis à la DGFiP au moment de l'appel : le paiement rejoint le brouillon de la déclaration de sa période, dont le contenu est décrit dans Déclarer les paiements.

Erreurs et cas limites​

401 Unauthorized​

Token absent, expiré ou invalide. Corps vide ; redemandez un token sur /oauth/token (Authentification).

403 Forbidden : scope insuffisant​

Les lectures de cette page exigent read. Sur cette ressource, read est aussi exigé des écritures, en plus de leur propre scope : POST et PATCH exigent read et write ; DELETE exige read et (destroy ou write). Demandez read write pour couvrir tous les appels de cette page :

{
  "error": "forbidden",
  "message": "Vous n'êtes pas autorisé à effectuer cette action"
}

Redemandez un token avec scope="read write" (Authentification).

404 Not Found​

Trois causes : la facture ou le paiement n'existe pas ; la facture appartient à un workspace hors du périmètre de votre application, ou dont la liste d'adresses IP autorisées refuse votre appel ; la facture est une facture de vente et l'offre de l'entreprise ne couvre pas la facturation de vente.

{
  "error": "not_found",
  "message": "La ressource demandée est introuvable"
}

Un 404 sur un identifiant que vous savez correct relève des deux dernières causes, pas d'une faute de frappe.

422 : statut de facture incompatible​

Un POST sur une facture qui n'est pas dans l'un des statuts listés plus haut est refusé :

{
  "error": "unprocessable_entity",
  "code": "validation_failed",
  "message": "La validation a échoué",
  "details": {
    "base": ["Les paiements ne peuvent être enregistrés que sur des factures émises."]
  }
}

Déposez la facture d'abord (Émettre une facture), puis enregistrez le paiement. Le PATCH et le DELETE ne revérifient pas le statut : un paiement déjà enregistré reste modifiable si la facture change de statut ensuite.

422 : paiement GoCardless​

Un paiement créé par l'encaissement d'un prélèvement GoCardless n'est jamais supprimable par l'API :

{
  "error": "unprocessable_entity",
  "code": "validation_failed",
  "message": "La validation a échoué",
  "details": {
    "base": ["Les paiements GoCardless ne peuvent pas être supprimés manuellement. Contactez le support si une correction est nécessaire."]
  }
}

Le PATCH est bloqué lui aussi, mais seulement en partie. Dès que la charge utile porte amount, payment_date ou payment_means_code - la présence de la clé suffit, la valeur envoyée n'est jamais comparée à la valeur enregistrée :

{
  "error": "unprocessable_entity",
  "code": "validation_failed",
  "message": "La validation a échoué",
  "details": {
    "base": ["Le montant, la date et le moyen de paiement d'un paiement GoCardless ne peuvent pas être modifiés. Seules la référence et la note peuvent être mises à jour."]
  }
}

Un PATCH qui ne porte que reference et note passe : ce sont des annotations locales, sans contrepartie chez GoCardless.

422 : paiement issu d'un rapprochement bancaire​

Un paiement créé en confirmant un rapprochement bancaire ne se supprime pas par cet endpoint, et un PATCH qui porte une autre clé que note est refusé en entier, même quand cette clé porte la valeur déjà enregistrée. La réponse porte le code dependent_records et, dans details.bank_operation_id, l'identifiant Scribee de l'opération bancaire rapprochée :

{
  "error": "unprocessable_entity",
  "code": "dependent_records",
  "message": "Ce paiement provient d'une opération bancaire rapprochée et ne peut pas être supprimé. Contactez le support si une correction est nécessaire.",
  "details": {
    "base": ["Ce paiement provient d'une opération bancaire rapprochée et ne peut pas être supprimé. Contactez le support si une correction est nécessaire."],
    "bank_operation_id": [30144]
  }
}

Le refus du PATCH a la même forme, avec son propre message :

{
  "error": "unprocessable_entity",
  "code": "dependent_records",
  "message": "Le montant, la date, le moyen de paiement et la référence d'un paiement issu d'une opération bancaire rapprochée ne peuvent pas être modifiés. Seule la note peut être mise à jour.",
  "details": {
    "base": ["Le montant, la date, le moyen de paiement et la référence d'un paiement issu d'une opération bancaire rapprochée ne peuvent pas être modifiés. Seule la note peut être mise à jour."],
    "bank_operation_id": [30144]
  }
}

Rien n'est écrit, et renvoyer le même appel sera refusé à nouveau. Pour défaire ce paiement, annulez l'affectation confirmée qui l'a créé, et elle seule :

  1. Retrouvez-la par GET /api/v1/bank_operations/{bank_operation_id}/allocations avec les filtres status=confirmed et invoice_document_id égal à l'identifiant de cette facture (Lister les affectations). Son id est l'identifiant de l'affectation.
  2. Annulez-la par DELETE /api/v1/bank_operations/{bank_operation_id}/reconciliation avec allocation_ids réduit à cet id (Annuler une confirmation) : l'affectation devient unconfirmed et son paiement est supprimé en un seul acte.

N'omettez pas allocation_ids. Sans la clé, toutes les affectations confirmées de l'opération sont annulées : sur une opération ventilée entre plusieurs factures, les paiements des autres factures seraient supprimés avec celui-ci.

422 : champs invalides​

amount doit être strictement positif, payment_date est obligatoire et payment_means_code, s'il est fourni, doit appartenir à la liste des codes acceptés. Les messages arrivent dans details.base.

422 : payeur ou ventilation refusés​

Chaque règle de la ventilation par taux enfreinte ajoute son message à details.base. Sur une facture intégralement prépayée dont l'encaissement est déjà enregistré, un second POST est refusé ainsi :

{
  "error": "unprocessable_entity",
  "code": "validation_failed",
  "message": "La validation a échoué",
  "details": {
    "base": ["Cette facture était déjà payée à son émission et son encaissement est déjà enregistré : corrigez ou supprimez ce paiement au lieu d'en ajouter un autre."]
  }
}

Un PATCH qui change payer_role est refusé ainsi :

{
  "error": "unprocessable_entity",
  "code": "validation_failed",
  "message": "La validation a échoué",
  "details": {
    "base": ["Le payeur d'un paiement enregistré ne peut pas être modifié. Supprimez le paiement puis enregistrez-le à nouveau."]
  }
}

Pages liées​