Confirmer le rapprochement d'une opération bancaire
POST/api/v1/bank_operations/:bank_operation_id/reconciliation
Solde l'opération contre les factures que vous nommez - en écrivant un Invoice::Payment par affectation et en recalculant l'écriture comptable à partir du jeu confirmé.
Le corps porte le jeu d'affectations COMPLET voulu, et un corps partiel n'est pas une mise à jour partielle. Le jeu que vous envoyez est celui qui se retrouve confirmé : une affectation confirmée aujourd'hui et absente de ce corps est retirée, une affectation présente à un montant différent est reconfirmée au nouveau montant, et une affectation qui correspond déjà n'est pas touchée - si bien que renvoyer un corps identique n'écrit rien. C'est TOUT OU RIEN : si un seul membre est refusé, aucun n'est appliqué.
La réponse est l'opération recalculée. Demandez ?include=allocations,bank_accounting_entry et vous relisez le jeu confirmé et ses lignes équilibrées dans le même aller-retour - un mouvement de 300.00 ventilé 200/100 revient avec DEUX affectations et trois lignes, jamais avec une seule ligne mutée.
Deux jetons font deux métiers différents, et ce point d'entrée exige les deux. Idempotency-Key protège d'une requête DUPLIQUÉE ; expected_version protège d'une requête PÉRIMÉE - un appel calculé sur une image du jeu d'affectations qui a bougé depuis. Lisez version sur l'opération, renvoyez-la ici.
Request
Responses
- 200
- 401
- 403
- 404
- 409
- 422
L'opération bancaire recalculée.
La requête ne porte aucun jeton, ou un jeton invalide ou expiré.
Votre jeton ne porte pas le scope write, ou la fonctionnalité bank_reconciliation est désactivée sur l'espace de travail de l'opération. Une opération que votre jeton ne peut pas lire répond 404, jamais 403.
Aucune opération de cet identifiant n'est atteignable par les habilitations du jeton. Une opération appartenant à un autre espace de travail répond de la même manière, si bien que la réponse ne permet pas d'en sonder l'existence.
stale_version : l'expected_version que vous avez envoyée n'est plus celle de l'opération, donc l'image sur laquelle votre jeu a été calculé a bougé. RIEN N'A ÉTÉ ÉCRIT. details porte l'état COURANT - la version, l'opération et ses affectations actives - de sorte que vous réaffichez depuis lui et réessayez avec details.current_version plutôt que de relire la ressource. Une confirmation issue d'une autre opération, enregistrée au même moment sur la même facture, peut aussi la faire bouger : lorsque cette course laisse cette opération sans aucune affectation active, le perdant reçoit cette réponse ; sinon, il reçoit le refus 422 qu'appelle le nouvel état de la facture. (idempotency_key_reuse et idempotency_request_in_progress répondent aussi 409 sur ce chemin, sans details.)
La requête ne peut pas être exécutée. code dit lequel des refus : validation_failed pour une expected_version absente ou non entière, une liste allocations vide ou illisible, une facture nommée deux fois, une facture qui n'est pas de l'entreprise de cette opération, ou une règle métier qu'une affectation prise isolément enfreint ; allocation_exceeds_operation lorsque le jeu solderait plus que le mouvement ne porte ; entry_already_exported lorsque l'écriture comptable de l'opération a déjà quitté les livres ; operation_failed lorsqu'un autre rapprochement portant sur les mêmes factures était enregistré au même moment et que la nouvelle tentative est de nouveau entrée en collision - rien n'a été écrit, relisez donc l'opération et renvoyez la requête ; reconfirmation_out_of_order lorsque confirmer une affectation à côté d'une affectation plus récente qui reste confirmée comptabiliserait le centime d'arrondi dans un autre ordre que celui de l'écriture comptable - details.allocations nomme les factures, et le remède est d'envoyer d'abord le jeu sans les affectations plus récentes, puis de nouveau le jeu complet.
entry_already_exported et reconfirmation_out_of_order sont délibérément des 422 et non des 409. Un 409 signifie que la requête est périmée et qu'un réessai à une version plus fraîche peut réussir ; une écriture exportée rend la requête impossible À TOUTE VERSION, et le remède est une écriture de reclassement plutôt qu'une réécriture. Une reconfirmation hors d'ordre échoue elle aussi à toute version : les paiements qui subsistent ne sont jamais recomptabilisés, si bien que les affectations plus récentes doivent d'abord être retirées.