Mettre à jour un paiement d'e-reporting
PATCH/api/v1/e_reportings/payments/:id
Met à jour un paiement existant. L'autorisation repose sur l'accès tenant de l'application OAuth.
Request
Responses
- 200
- 401
- 404
- 422
Le paiement d'e-reporting a été mis à jour avec les attributs fournis.
La requête ne comportait pas de jeton d'accès (bearer token) OAuth 2.0 valide.
Aucun paiement d'e-reporting n'existe avec cet ID, ou il appartient à un espace de travail auquel le client OAuth authentifié n'a pas accès.
La validation du payload du paiement a échoué. 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. Parmi eux un tax_subtotals[].currency_code qui ne nomme aucune devise ISO 4217 - la devise se porte sur la ventilation fiscale et non sur le paiement, si bien qu'une entrée de sous-total est la seule place où un paiement en énonce une. 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-PMT-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 paiement qui désigne une facture d'acompte de l'espace de travail - par son invoice_number exact, et par sa date d'émission lorsque invoice_date est renseignée - est refusé lui aussi dès que cette facture d'acompte a été reprise des données de transaction B2C (flux 10.3) par une facture définitive déclarée hors B2C (flux 1 ou 10.1) : ses paiements ne se déclarent alors plus en e-reporting, jusqu'à ce que cette facture définitive soit annulée ou rejetée.