Aller au contenu principal

Déclarer les paiements

Pour les ventes dont la TVA est due à l'encaissement - le régime par défaut des prestations de services - c'est le paiement, et non l'émission de la facture, qui déclenche l'exigibilité : le e-reporting demande donc de déclarer les montants encaissés de chaque période. Dans Scribee, cette déclaration est un sous-produit de votre suivi des règlements : chaque paiement enregistré sur une facture de vente concernée - vente B2B internationale ou vente B2C - alimente la déclaration de sa période, sans appel supplémentaire. Les endpoints de cette page servent à consulter ces déclarations et à déclarer les encaissements que votre système ne suit pas comme paiements de facture.

Ce que Scribee fait pour vous​

  • Déclaration dérivée des paiements de facture : l'enregistrement, la correction et la suppression d'un paiement de facture (Enregistrer les paiements) créent, mettent à jour et suppriment la ligne de déclaration correspondante - à condition que l'e-reporting couvre la vente et que l'entreprise émettrice soit soumise à l'obligation de déclaration des paiements à la date du paiement.
  • Rapport de période créé au besoin : la ligne rejoint le rapport de paiements dont la période couvre la date d'encaissement ; s'il n'existe pas, Scribee le crée à l'état draft Brouillon, avec la périodicité dérivée du régime de TVA de la société.
  • Ventilation par taux de TVA : le montant encaissé est réparti entre les taux de TVA de la facture, au prorata du montant TTC de chaque taux. La part qui revient aux taux en autoliquidation (catégorie de TVA AE) n'est pas déclarée, ni reportée sur les autres taux, pas plus que celle d'une ventilation en catégorie G (exportation hors de l'Union européenne) ou O (hors champ de la TVA) : elle n'est pas soumise à la TVA en France. Sur une facture double, qui mêle biens et services, seule la part services est déclarée. L'octroi de mer n'est jamais déclaré (détail ci-dessous).
  • Montants en euros : la part déclarée est convertie en euros au moment où la ligne est écrite ; une ligne dérivée porte toujours currency_code EUR.
  • Exclusions appliquées d'office : les factures d'achat ne génèrent aucune déclaration de paiement, ni les factures de vente qui portent un code d'exigibilité autre que l'encaissement, ni les ventes dont toutes les ventilations de TVA sont en catégorie G ou O, ni celles que leur acheteur, leur vendeur, leur autoliquidation ou leur nature de livraison de biens écarte (détail ci-dessous).
  • Déclarations en lecture seule : l'état du rapport s'observe en lecture, aucun endpoint ne le modifie.

Le suivi automatique depuis les paiements de facture​

Le suivi automatique couvre les factures de vente dont la TVA est due à l'encaissement, émises par une entreprise soumise à l'obligation de déclaration des paiements à la date du paiement. Sans cette obligation, aucune ligne n'est créée, silencieusement : l'API ne signale pas l'exclusion. Une facture qui ne précise aucun code d'exigibilité (tax_due_date_code absent) est traitée comme due à l'encaissement - le régime par défaut des prestations de services. Tout autre code d'exigibilité exclut la facture : seule l'absence de code, ou le code de l'encaissement, produit une déclaration de paiement. Une facture d'achat est exclue elle aussi, comme l'est toute facture émise par une entreprise sans obligation de déclaration des paiements. Une vente dont toutes les ventilations de TVA sont en catégorie G (exportation hors de l'Union européenne) ou O (hors champ de la TVA) est exclue elle aussi : elle n'est pas soumise à la TVA en France, quel que soit son acheteur. Une ventilation d'octroi de mer (catégorie O, tax_exemption_reason valant OCTROI_MER) n'entre pas dans ce décompte. Une vente de débours - chaque ligne portant disbursement à true, chaque ventilation de TVA en catégorie O, ou E sous VATEX-EU-79-C, sans montant de TVA - est exclue de même (Émettre une facture de vente). Seul le marquage disbursement fait d'une ligne un débours : le code VATEX-EU-79-C sans ce marquage n'exclut pas la facture à ce titre. Pour ces factures, l'enregistrement d'un paiement ne sert qu'au suivi du règlement.

Le suivi automatique ne couvre en outre que les ventes que l'e-reporting déclare, selon l'identification de l'acheteur sur la facture. Une vente dont l'acheteur est identifié sans SIREN - par un numéro de TVA étranger, par exemple -, ou dont l'acheteur porte un SIREN mais est établi hors du territoire de TVA français, est une vente B2B internationale : chaque paiement y devient une ligne rattachée à la facture. Une vente dont l'acheteur ne porte aucun identifiant est une vente B2C : chaque paiement y devient un encaissement agrégé.

Quatre ventes sont exclues en plus, quels que soient leur code d'exigibilité et le régime de la société, et l'API ne signale pas davantage l'exclusion :

  • une vente à un acheteur identifié par un SIREN ou un SIRET, et établi dans le territoire de TVA français ou sans pays renseigné - celle dont la facture est déposée auprès du PPF (Déclarer les transactions) : c'est une vente B2B domestique, dont l'encaissement se déclare par le statut 212 Encaissée de la facture elle-même (Enregistrer les paiements), pas par une ligne de déclaration de paiement. Un acheteur porteur d'un SIREN mais établi hors de ce territoire, dans un pays étranger comme dans l'outre-mer, n'est pas exclu à ce titre : sa vente est une vente B2B internationale ;
  • une vente d'un vendeur établi hors du territoire de TVA français : un vendeur établi en Guyane, à Mayotte, dans une collectivité d'outre-mer ou dans les Terres australes et antarctiques françaises, d'après l'adresse du vendeur portée par la facture - y compris une adresse FR dont le code postal rattache à l'un de ces territoires (L'outre-mer hors du territoire de TVA) - ne doit aucun e-reporting de ses ventes, paiements compris ;
  • une vente intégralement autoliquidée : quand toutes les ventilations de TVA de la facture, hors celles en catégorie G ou O, portent tax_category_id valant AE, la TVA est due par l'acheteur et la vente n'entre pas dans la déclaration des paiements ;
  • une livraison de biens : une facture dont le cadre de facturation désigne des biens - un code qui commence par B, B1 ou B7 par exemple - est exclue, sauf s'il s'agit d'une facture d'acompte (retainer_invoice ou self_billed_retainer_invoice). Sans invoicing_process_id, ce cadre est celui que Scribee déduit de product_type sur les lignes. Un cadre mixte (M1, M2, M4), un cadre de services - S7 compris - ou l'absence de cadre n'excluent pas la facture.

Une vente dont une partie seulement des ventilations porte AE, G ou O reste déclarée, mais sans ces ventilations : le montant encaissé est d'abord réparti entre tous les taux de la facture, puis les parts AE, G et O sont écartées. La somme des amount_collected de la ligne est alors inférieure au montant du paiement.

Une facture double - cadre de facturation M1, M2 ou M4 - ne déclare que la part des services : le montant encaissé déclaré est celui du paiement, multiplié par le total TTC des lignes de service rapporté au total TTC de la facture, et la ventilation ne porte que les montants des lignes de service. La nature de chaque ligne se lit sur son product_type, à défaut sur son quantity_unit_code (Émettre une facture de vente). Une facture double dont la part services est nulle - elle ne porte que des biens, ses services sont entièrement autoliquidés, ou leur total s'annule - ne produit aucune ligne. Quand elle porte aussi des ventilations G ou O, la part des services se calcule sur ses seules lignes et ventilations taxables : les lignes G et O ne pèsent d'aucun côté, et leurs ventilations ne sont pas déclarées.

L'octroi de mer n'est pas de la TVA : une ligne de ventilation de catégorie O dont le tax_exemption_reason vaut OCTROI_MER n'apparaît jamais comme ligne de taux dans la déclaration. Sur une vente qui porte de l'octroi de mer, le montant encaissé déclaré est celui du paiement, multiplié par le total TTC des ventilations de TVA rapporté au total TTC de la facture, octroi de mer compris. Un paiement de 1 210 sur une facture de 1 000 hors taxes, 200 de TVA à 20 % en catégorie S et 10 d'octroi de mer déclare ainsi une seule ligne de taux, 20 %, avec un amount_collected de 1 200. Une vente dont il ne reste rien à déclarer une fois l'octroi de mer écarté - aucune autre ventilation, des ventilations toutes autoliquidées (AE) ou en catégorie G ou O, ou un total qui s'annule - ne produit aucune ligne.

Les montants sont déclarés en euros. La TVA sur les encaissements étant exigible au paiement, une part encaissée dans une autre devise est convertie au taux de référence de l'euro publié pour la date de ce paiement - celui de la BCE ou, pour certaines devises, de la banque centrale qui les cote. Chaque paiement d'une même facture est donc converti à son propre taux, et c'est le seul taux utilisé : le taux enregistré sur la facture lors de son dépôt ne sert jamais à convertir un encaissement. Le montant converti est figé sur la ligne : seule une correction du paiement le recalcule.

Un paiement dont la date n'a pas encore de taux est mis en attente, pas perdu. Les taux de référence sont publiés chaque jour, souvent après l'enregistrement d'un paiement du jour même. Tant que le taux de sa date manque, le paiement est enregistré mais sa ligne de déclaration n'est ni créée ni mise à jour ; Scribee retente automatiquement, toutes les heures, et écrit la ligne au taux de la date du paiement dès qu'il est publié. Une transmission faite entre-temps part sans ce paiement ; si cette déclaration est acceptée, la période doit alors une transmission rectificative, qui le portera. L'attente est bornée à 38 jours, comptés depuis la date du paiement ou depuis sa première mise en attente, la plus ancienne des deux. Elle vaut pour toute devise, y compris une devise facturée pour la première fois. Au-delà, le paiement n'est plus retenté (voir ci-dessous).

Huit situations laissent pourtant un paiement couvert par le suivi automatique sans ligne de déclaration, silencieusement : le paiement reste enregistré sur la facture, mais aucune ligne n'est créée - et une ligne existante n'est pas mise à jour, elle reste telle qu'elle était. L'API ne signale rien.

  • Une devise hors de la liste ISO 4217 sur une ventilation de TVA déclarée de la facture, ou sur la facture elle-même quand la ventilation n'en précise aucune. Les ventilations que la déclaration écarte - autoliquidation, catégories G et O, octroi de mer - ne sont pas contrôlées.
  • Un net à payer négatif (payable_amount, BT-115) sur une facture qui n'est pas un avoir : le paiement est alors un remboursement à l'acheteur, qu'une déclaration de paiement ne peut pas porter avec un signe négatif.
  • Une vente au régime de la marge : une ligne de ventilation de TVA de catégorie E dont le motif d'exonération est VATEX-EU-F, VATEX-EU-I, VATEX-EU-J ou VATEX-EU-D, que ses bases de marge (margin_bases) soient fournies ou non.
  • Une facture double dont les lignes ne se répartissent pas entre biens et services : notamment aucune ligne de détail, une ligne dont le product_type vaut both, aucune ventilation de TVA, ou des montants de lignes qui s'annulent.
  • Une facture double dont la part services sort du paiement : des lignes négatives - une remise saisie comme ligne de services, par exemple - placent le total TTC des services sous zéro ou au-dessus du total TTC de la facture.
  • Une vente avec octroi de mer dont la part TVA sort du paiement : des lignes de ventilation négatives - un octroi de mer négatif, par exemple - placent le total TTC des ventilations de TVA sous zéro ou au-dessus du total TTC de la facture.
  • Une facture d'acompte reprise de l'agrégat B2C par une facture définitive qui le quitte : la facture définitive qui la solde est déposée auprès du PPF ou déclarée dans les données de transaction (10.1), et en a fait reprendre le comptage (Les factures d'acompte reprises de l'agrégat B2C). Un paiement de cette facture d'acompte n'est plus déclaré en données de paiement, quelle que soit sa date, tant que la reprise n'est pas compensée. Aucune correction de la facture n'est attendue. Une reprise faite pour une facture définitive comptée elle-même dans l'agrégat B2C n'est pas concernée : les paiements de la facture d'acompte restent déclarés.
  • Un taux vers l'euro qui ne peut plus arriver : l'attente de 38 jours décrite plus haut a expiré sans qu'un taux soit publié pour la date du paiement.

La déclaration reste due : une fois la cause levée, la correction suivante du paiement produit la ligne. Une facture d'acompte reprise de l'agrégat B2C par une facture définitive qui le quitte fait exception : cette cause ne se lève pas par une correction, et son paiement n'est simplement pas déclaré. Une déclaration de paiement que vous écrivez vous-même et qui désigne cette facture d'acompte est refusée de même (voir 422 : paiement d'une facture d'acompte reprise plus bas). La cause ne se lève que si la facture définitive est ensuite annulée (220), ou rejetée (213) sans pouvoir être renvoyée sous le même numéro, et non remplacée par une facture rectificative : la reprise est alors compensée (La reprise compensée après l'annulation ou le rejet de la facture définitive), et Scribee déclare de lui-même, sans correction de votre part, les paiements de la facture d'acompte qui n'ont pas de ligne. Ils suivent les règles de tout paiement : une déclaration close met la ligne de côté.

Chaque ligne dérivée porte la date d'encaissement et la ventilation du montant encaissé par taux de TVA. Une ligne issue d'une vente B2B internationale porte en plus le numéro et la date d'émission de la facture d'origine. Une vente à un acheteur que la facture n'identifie pas - aucun SIREN, aucun legal_registration_id, aucun vat_identifier, ou aucune partie buyer - fait exception : sa ligne est un encaissement agrégé, et invoice_number comme invoice_date y valent null. L'API restitue une ligne par paiement ; dans la déclaration transmise, les encaissements B2C d'une même journée sont additionnés par taux de TVA et par devise. Si vous corrigez la date d'un paiement vers une autre période encore soumise à l'obligation, la ligne est déplacée vers le rapport de cette période, créé si nécessaire ; si vous supprimez le paiement, la ligne est retirée. Si la facture ne remplit plus les conditions de cette section au moment où vous corrigez un paiement - acheteur désormais identifié par un SIREN et établi dans le territoire de TVA français, livraison de biens, TVA passée en autoliquidation ou sur les débits -, la correction retire la ligne existante au lieu de la mettre à jour ; l'obligation de la société, elle, suit l'encadré ci-dessous. Tant que la déclaration qui porte la ligne est close - un dépôt attend son verdict, ou la déclaration a été acceptée -, la ligne reste en place : le changement est mis de côté, puis appliqué si la déclaration redevient modifiable après un rejet 301, ou porté par la transmission rectificative que la période doit si elle a été acceptée. Vous n'appelez aucun des endpoints ci-dessous pour cela : l'enregistrement du paiement sur la facture suffit (Enregistrer les paiements).

:::caution La correction et la suppression ne se comportent pas de la même façon hors obligation Les trois opérations ne partagent pas la même condition. La suppression retire la ligne existante quelle que soit l'éligibilité au moment de l'appel. La correction, elle, ne peut aboutir que vers une période effectivement soumise à l'obligation : si vous déplacez un paiement déjà déclaré vers une date dont le régime ne porte pas l'obligation, aucun rapport ne peut l'accueillir et la ligne existante reste attachée à son rapport précédent, ni mise à jour ni supprimée. La déclaration d'origine continue donc de porter un montant à une date qui n'est plus la sienne, et l'API ne signale rien. Après un déplacement de ce type, relisez le rapport de la période d'origine, et supprimez puis recréez le paiement plutôt que d'en corriger la date si vous devez retirer la ligne. :::

Consulter les déclarations d'un rapport​

GET /api/v1/e_reportings/{e_reporting_id}/payments renvoie les lignes de déclaration du rapport ; le scope read suffit et l'appel ne modifie rien. Le rapport de paiements d'une période se repère dans la liste des rapports du workspace, GET /api/v1/workspaces/{workspace_id}/e_reportings, par ses champs kind (payments, libellé Paiements), start_date et end_date (Référence API : lister les rapports).

curl https://app.scribee.tech/api/v1/e_reportings/YOUR_REPORT_ID/payments \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN"
{
  "data": [
    {
      "id": 305,
      "payment_date": "2025-01-10",
      "invoice_date": "2024-12-15",
      "invoice_number": "F2024-0198",
      "report_id": 57
    },
    {
      "id": 304,
      "payment_date": "2025-01-06",
      "invoice_date": "2024-12-02",
      "invoice_number": "F2024-0185",
      "report_id": 57
    }
  ],
  "meta": {
    "current_page": 1,
    "per_page": 20,
    "total_pages": 1,
    "total_count": 2
  }
}

La liste est paginée (page, per_page - 20 par défaut, 100 au maximum) et triable (sort_by : payment_date, invoice_date, invoice_number, created_at ou updated_at ; sort_order : asc ou desc ; tri par défaut : payment_date décroissant). Le paramètre include charge les associations report et tax_subtotals à la demande. Une ligne isolée se lit sur GET /api/v1/e_reportings/payments/{id}.

Déclarer un encaissement manuellement​

Le CRUD manuel sert aux encaissements que Scribee ne voit pas passer - typiquement une vente dont la facture n'est pas suivie dans Scribee. Cet appel crée une ligne de déclaration dans le rapport visé, dans votre compte de production. Rien n'est envoyé à la DGFiP ni à aucun tiers au moment de l'appel ; la ligne se corrige (PATCH) et se supprime (DELETE). Le scope write est requis.

:::danger Le rattachement à la période n'est pas vérifié - et n'est pas rattrapable Ciblez vous-même le rapport de paiements dont la période couvre la date d'encaissement : rien ne le vérifie côté serveur. Une payment_date hors des bornes du rapport visé est acceptée sans erreur, et la ligne reste rattachée à ce rapport-là. Le PATCH ne corrige pas la situation : il change la date, jamais le rapport. Il n'existe aucun endpoint pour déplacer une ligne d'un rapport vers un autre - la seule réparation est de supprimer la ligne et de la recréer dans le bon rapport. Contrôlez start_date et end_date du rapport avant d'appeler : c'est une donnée réglementaire, pas une métadonnée. :::

POST /api/v1/e_reportings/{e_reporting_id}/payments accepte payment_date (obligatoire), invoice_date et invoice_number (facultatifs, et indissociables : les deux, ou aucun des deux), plus tax_subtotals, la ventilation par taux de TVA décrite plus bas.

:::info invoice_date et invoice_number vont par paire Un encaissement se déclare sous deux formes, et deux seulement : rattaché à une facture, il porte le numéro et la date d'émission de celle-ci ; agrégé, il n'en porte aucun. Il n'existe pas de forme intermédiaire, donc une requête qui ne renseigne qu'un seul des deux champs reçoit un 422. Envoyez la paire complète, ou omettez-la entièrement. :::

curl -X POST https://app.scribee.tech/api/v1/e_reportings/YOUR_REPORT_ID/payments \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "payment": {
      "payment_date": "2025-01-10",
      "invoice_date": "2024-12-15",
      "invoice_number": "F2024-0198"
    }
  }'
{
  "data": {
    "id": 305,
    "payment_date": "2025-01-10",
    "invoice_date": "2024-12-15",
    "invoice_number": "F2024-0198",
    "report_id": 57
  }
}

Une ligne créée par l'API porte ces trois champs ; la réponse est un 201.

La ventilation par taux de TVA se renseigne de deux façons : le suivi automatique depuis les paiements de facture la construit pour vous, et le POST comme le PATCH acceptent un tableau tax_subtotals imbriqué. Chaque entrée accepte amount_collected, vat_rate, currency_code, tax_category_id, tax_exemption_reason et tax_exemption_reason_code ; amount_without_taxes et vat_amount ne sont pas acceptés à l'écriture - un encaissement ne porte que le montant encaissé. C'est aussi la seule place où un paiement énonce une devise. Sur une ligne issue du suivi automatique, elle vaut toujours EUR : le montant y est déjà converti. amount_collected ne peut pas être négatif (voir Erreurs et cas limites).

En lecture, include=tax_subtotals restitue amount_collected, le seul montant qu'un sous-total d'encaissement porte, à côté de id, vat_rate, currency_code, tax_category_id, des champs d'exonération, created_at et updated_at. amount_without_taxes et vat_amount sont présents eux aussi mais toujours nuls : ne construisez pas de rapprochement comptable sur ces deux champs.

Corriger ou supprimer une déclaration​

Ces appels modifient ou suppriment la ligne dans votre compte de production ; rien n'est envoyé vers un tiers au moment de l'appel.

:::caution Ces endpoints atteignent aussi les lignes dérivées Ils ne sont pas limités aux lignes que vous avez créées : ils acceptent l'identifiant de n'importe quelle ligne de votre périmètre, y compris celles issues du suivi automatique. Une correction portée sur une ligne dérivée est écrasée dès que le paiement de facture d'origine est modifié - la ligne est alors reconstruite depuis la facture, sous-totaux compris. Pour corriger durablement une ligne dérivée, corrigez le paiement sur la facture (Enregistrer les paiements), pas la déclaration. :::

PATCH /api/v1/e_reportings/payments/{id} accepte les mêmes champs que la création ; seuls les champs envoyés changent. tax_subtotals fait exception : fournir la clé remplace l'intégralité du jeu existant - les sous-totaux en place sont supprimés puis recréés, donc leurs id changent à chaque remplacement, et "tax_subtotals": [] vide la ventilation. Une requête qui ne mentionne pas la clé laisse la ventilation intacte.

curl -X PATCH https://app.scribee.tech/api/v1/e_reportings/payments/YOUR_PAYMENT_ID \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "payment": { "payment_date": "2025-01-12" } }'
{
  "data": {
    "id": 305,
    "payment_date": "2025-01-12",
    "invoice_date": "2024-12-15",
    "invoice_number": "F2024-0198",
    "report_id": 57
  }
}

DELETE /api/v1/e_reportings/payments/{id} répond 204 sans corps. Le scope write est requis.

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

Ce qui se passe ensuite​

  • L'encaissement rejoint la déclaration de sa période dans votre compte de production ; vous pouvez le relire immédiatement via les endpoints de liste.
  • Le champ state de la déclaration est en lecture seule : aucun endpoint de l'API ne le modifie (L'e-reporting).

Erreurs et cas limites​

401 Unauthorized​

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

403 Forbidden : scope insuffisant​

Écriture ou suppression avec un token limité à read :

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

404 Not Found​

Le rapport ou la ligne de déclaration n'existe pas, ou appartient à un workspace hors du périmètre de votre application :

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

400 Bad Request : page au-delà de la dernière​

Sur la liste, demander une page au-delà de la dernière page d'une collection non vide retourne :

{
  "error": "bad_request",
  "message": "Le numéro de page dépasse le nombre de pages disponibles"
}

422 : rapport du mauvais type​

Un POST sur un rapport de type transactions est refusé - les déclarations de paiements ne vivent que dans un rapport de type payments :

{
  "error": "unprocessable_entity",
  "code": "validation_failed",
  "message": "La validation a échoué",
  "details": {
    "base": ["Ce rapport ne peut pas contenir de paiements - son type doit être \"payments\""]
  }
}

Les refus de validation - ceux qui portent un details.base - annoncent tous code: "validation_failed". C'est la clé sur laquelle brancher : elle n'est ni traduite ni reformulée, alors que message et les textes de details.base arrivent en français. Un DELETE refusé emprunte un autre code, operation_failed, et ne porte pas de details : le motif est alors dans message.

422 : rapport au rôle acheteur​

Les déclarations de paiements ne se rattachent qu'aux rapports où la société déclare en tant que vendeur ; c'est le rôle des rapports que Scribee crée pour vos encaissements de vente :

{
  "error": "unprocessable_entity",
  "code": "validation_failed",
  "message": "La validation a échoué",
  "details": {
    "base": ["Les paiements ne peuvent être rattachés qu'à un rapport de rôle vendeur (SE)"]
  }
}

422 : date d'encaissement manquante​

payment_date est obligatoire à la création. La réponse porte l'enveloppe error: "unprocessable_entity" avec code: "validation_failed" et message: "La validation a échoué", et le message de validation arrive dans details.base.

422 : référence de facture incomplète​

invoice_number et invoice_date se renseignent ensemble ou pas du tout. Une requête qui n'en porte qu'un seul est refusée, à la création comme à la correction, avec la même enveloppe que ci-dessus - code compris - et le message de validation dans details.base. Pour rattacher un encaissement à une facture, envoyez les deux champs ; pour le déclarer comme encaissement agrégé, n'envoyez ni l'un ni l'autre.

422 : devise hors de la liste ISO 4217​

Le currency_code d'un sous-total doit figurer dans la liste ISO 4217 que Scribee embarque, à la création comme à la correction. Le contrôle porte sur l'existence du code et pas seulement sur sa forme, et la comparaison est sensible à la casse : EUR passe, eur et USd sont refusés, comme l'est un jeton bien formé qui ne nomme aucune devise - XYZ, par exemple.

{
  "error": "unprocessable_entity",
  "code": "validation_failed",
  "message": "La validation a échoué",
  "details": {
    "base": ["Devise ne fait pas partie de la liste des devises ISO 4217"]
  }
}

Le message nomme l'attribut Devise, jamais currency_code, et n'indique pas quel sous-total est en cause. Le refus emporte l'appel entier : sur un POST la ligne n'est pas créée, et sur un PATCH la ventilation précédente reste en place, intacte. Mettez vos codes en majuscules avant l'appel - rien n'est normalisé à l'écriture.

422 : montant encaissé négatif​

Un amount_collected négatif est refusé, à la création comme à la correction : la règle G1.16 de l'annexe 7 interdit le signe sur un montant encaissé, si bien qu'un encaissement déjà déclaré ne s'annule pas par un encaissement négatif. Zéro reste accepté.

{
  "error": "unprocessable_entity",
  "code": "validation_failed",
  "message": "La validation a échoué",
  "details": {
    "base": ["Amount collected ne peut pas être négatif (annexe 7, règle G1.16) : le PPF refuse le signe sur un montant encaissé, un encaissement provisoire ne peut donc pas être annulé par un encaissement négatif"]
  }
}

Le message nomme l'attribut Amount collected, jamais amount_collected, et n'indique pas quel sous-total est en cause. Comme pour la devise, le refus emporte l'appel entier : sur un POST la ligne n'est pas créée, et sur un PATCH la ventilation précédente reste en place, intacte.

422 : paiement d'une facture d'acompte reprise​

Un paiement qui désigne une facture d'acompte reprise de l'agrégat B2C par une facture définitive qui le quitte - déposée auprès du PPF ou déclarée dans les données de transaction (10.1) (Les factures d'acompte reprises de l'agrégat B2C) - est refusé, à la création comme à la correction : les paiements de cette facture d'acompte ne se déclarent plus en données de paiement. Le paiement désigne la facture d'acompte lorsque son invoice_number est exactement le numéro de celle-ci, casse et accents compris, et, lorsque invoice_date est renseignée, que cette date est sa date d'émission. La facture d'acompte est recherchée dans toutes les entreprises du workspace, pas seulement dans celle du rapport visé. À la correction, c'est la ligne telle que l'appel la laisserait qui est examinée : un PATCH qui ne change que payment_date est refusé lui aussi lorsque la ligne désigne une telle facture d'acompte.

{
  "error": "unprocessable_entity",
  "code": "validation_failed",
  "message": "La validation a échoué",
  "details": {
    "base": ["Ce paiement porte sur la facture d'acompte A2024-0042, dont la déclaration dans les données de transaction B2C a été reprise par la facture finale qui la solde : l'opération ne relève plus du circuit B2C, ses paiements ne se déclarent donc plus en e-reporting. Retirez ce paiement ou rattachez-le à une autre facture."]
  }
}

Le message nomme la facture d'acompte par son numéro. Le refus emporte l'appel entier : sur un POST la ligne n'est pas créée, et sur un PATCH la ligne reste telle qu'elle était. Le DELETE n'est pas concerné. Une reprise faite pour une facture définitive comptée elle-même dans l'agrégat B2C ne déclenche pas ce refus, et le refus cesse dès que la reprise est compensée - la facture définitive annulée (220), ou rejetée (213) sans pouvoir être renvoyée sous le même numéro, et non remplacée par une facture rectificative (La reprise compensée après l'annulation ou le rejet de la facture définitive).

Un import CSV de données de paiement applique le même refus : chaque ligne en cause est signalée avec le code instalment_taken_back et ce message, et aucune ligne du fichier n'est importée.

Pages liées​