Aller au contenu principal

Mettre à jour une facture brouillon

PATCH 
/api/v1/invoices/:id

Met à jour une facture brouillon par ID. Seules les factures à l'état de cycle de vie « draft » peuvent être mises à jour.

Il s'agit d'une opération de remplacement complet : tous les enregistrements enfants (parties, lignes, sous-totaux de taxe, moyens de paiement, notes, remises/charges, références de facture) sont effacés et reconstruits à partir du payload fourni.

Avant que la facture ne soit reconstruite, le payload est complété avec les mêmes valeurs par défaut côté entreprise que POST .../invoices - résolution de party_id par rapport à l'annuaire de l'entreprise, une valeur par défaut de tiers côté entreprise quand le payload l'omet (sans jamais écraser une entrée de tiers que l'appelant fournit), des valeurs par défaut d'item_notes sur sales, et des valeurs par défaut de payment_means (comptes bancaires de l'entreprise, ou compte du factor de l'acheteur pour un client confidentiellement affacturé) dans les deux sens. Il s'agit d'un changement de comportement pour les intégrations existantes : un PATCH qui omet item_notes ou payment_means les reremplit désormais à partir de l'entreprise au lieu de laisser la facture sans aucun. Les mêmes contrôles s'appliquent, parmi eux le contrôle de devise ISO 4217 documenté sur POST .../invoices : currency_code (BT-5), tax_currency_code (BT-6) et chaque tax_subtotals[].currency_code sont comparés aux listes de codes embarquées de façon sensible à la casse, et une valeur non listée retourne 422 sans rien écrire. Un BT-5 omis laisse en vigueur la devise existante de la facture et n'est jamais refusé. Le contrôle de cohérence de la ventilation de TVA documenté au même endroit s'applique aussi à ce verbe, et il y est jugé sur les totaux EFFECTIFS plutôt que sur ceux du payload : sur direction: "sales", la somme des tax_subtotals[].amount_without_taxes est raccordée au total_amount_excluding_taxes et la somme des tax_subtotals[].vat_amount au total_tax_amount, à la tolérance de 0,01 de la règle PPF G1.53 près, chaque total étant lu dans le payload quand sa clé est présente et dans la facture persistée quand elle est omise, et un écart au-delà retourne 422 sans rien écrire. Ne lire que le payload était faux sur ce verbe : les tax_subtotals envoyés REMPLACENT ceux du document en bloc, alors qu'un total dont la clé est absente garde sa valeur persistée ; un PATCH ne portant qu'une nouvelle ventilation laissait donc les totaux inchangés, sortait du périmètre de la règle, et persistait exactement l'incohérence que le contrôle existe pour refuser. La conversion en SIREN aussi : un tiers rempli depuis une fiche d'annuaire dont le SIRET est déclaré sous le schéma 0009 est écrit avec le SIREN de l'unité légale sous le schéma 0002 (BR-FR-11 / BT-47), tandis qu'un legal_registration_id envoyé explicitement sur l'entrée n'est jamais converti. Les valeurs par défaut de payment_means se résolvent par rapport au currency_code existant de la facture quand le payload l'omet, pas en EUR. Elles sont résolues UNIQUEMENT à partir de l'acheteur du payload : parce que cet endpoint remplace chaque tiers, omettre parties laisse la facture sans acheteur, et aucun moyen de paiement n'est émis dans ce cas plutôt que de reporter le compte bancaire de l'acheteur détruit.

Le contrôle de cohérence de l'état déjà payée documenté sur POST .../invoices s'applique aussi à ce verbe, jugé sur les valeurs EFFECTIVES comme le contrôle de la ventilation de TVA : invoicing_process_id, profile_id, les totaux, due_date et issue_date sont chacun lus dans le payload quand la clé est présente et dans la facture persistée quand elle est omise. Ainsi, un PATCH qui modifie le total d'une facture B2 / S2 / M2 sans redéclarer prepaid_amount retourne 422, et un PATCH qui ramène la facture dans la famille B1 / S1 / M1 la sort du périmètre du contrôle.

L'autorisation repose sur l'accès tenant de l'application OAuth à l'espace de travail de la facture.

Request​

Responses​

La facture mise à jour, reconstruite à partir du payload avec les valeurs par défaut côté entreprise réappliquées pour tout parties, item_notes ou payment_means que le payload a omis.