Mettre à jour une transaction d'e-reporting
PATCH/api/v1/e_reportings/transactions/:id
Met à jour une transaction existante. Quand des tax_subtotals sont fournis, ils remplacent tous les existants.
Request
Responses
- 200
- 401
- 404
- 422
La transaction d'e-reporting a été mise à jour avec les attributs fournis. Fournir tax_subtotals remplace l'intégralité du jeu existant.
La requête ne comportait pas de jeton d'accès (bearer token) OAuth 2.0 valide.
Aucune transaction d'e-reporting n'existe avec cet ID, ou elle appartient à un espace de travail auquel le client OAuth authentifié n'a pas accès.
La validation du payload de la transaction a échoué - un attribut obligatoire manquant, un category_code hors TLB1 / TPS1 / TNT1 / TMA1, un transaction_count qui n'est pas strictement supérieur à 0, une date postérieure à la date du jour, ou un code devise - currency_code (TT-86) ou l'un des tax_subtotals[].currency_code - qui ne nomme aucune devise ISO 4217. Les codes devise sont comparés de façon sensible à la casse aux deux listes de codes embarquées par Scribee (l'énumération UN/CEFACT ISO3AlphaCurrencyCode réunie à la liste ISO4217 de Peppol BIS), si bien que eur est refusé plutôt que mis en majuscules. C'est délibérément plus strict que la règle flux 10 F10-TX-DEVISE-G1.10 du PPF, qui n'exige que la forme à trois lettres et indique dans son propre message que l'existence dans le référentiel n'est pas contrôlée. Un currency_code omis n'est jamais refusé - la colonne retombe sur EUR. Le corps de la réponse porte code: "validation_failed" et rapporte les attributs en échec et leurs messages d'erreur sous forme de messages complets sous details.base. Une transaction qui prend part à la reprise d'une mensualité ne peut pas être modifiée du tout : ce refus porte code: "operation_failed", un message nommant le cas, et aucun details.