Brouillonner une affectation sur une opération bancaire
POST/api/v1/bank_operations/:bank_operation_id/allocations
Crée une affectation proposed. C'est un brouillon et rien d'autre : aucun paiement n'est écrit, aucune ligne de grand livre n'est touchée, et la facture reste impayée. Le règlement de l'argent, c'est POST /api/v1/bank_operations/{id}/reconciliation, qui prend le jeu d'affectations complet et la version de l'opération.
La facture doit appartenir à L'ENTREPRISE DE L'OPÉRATION elle-même, et les mêmes règles métier que l'application applique valent ici : un mouvement entrant solde une facture de vente, un mouvement sortant une facture d'achat, les devises doivent concorder, et la facture doit être encore ouverte et payable.
Idempotency-Key est OBLIGATOIRE. Un rejeu sous la même clé et le même corps rend la réponse stockée avec Idempotency-Replayed: true et ne crée rien ; la même clé avec un corps différent donne un 409 idempotency_key_reuse.
Request
Responses
- 201
- 401
- 403
- 404
- 409
- 422
L'affectation brouillonné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.
Aucune opération de cet identifiant n'est atteignable par les habilitations du jeton.
Une première requête portant la même Idempotency-Key est encore en vol (idempotency_request_in_progress), ou la clé a été rejouée avec un corps DIFFÉRENT (idempotency_key_reuse). Rien n'a été écrit dans les deux cas. Ni l'un ni l'autre n'est réessayable en l'état : envoyez une clé neuve, ou renvoyez le corps d'origine pour rejouer la réponse stockée.
Le corps a été refusé. code dit lequel des refus : validation_failed pour un allocated_amount absent ou négatif, une référence de facture absente ou qui ne se résout pas, un couple déjà affecté, ou une règle métier (sens, devise, facture qui n'est plus ouverte et payable) ; allocation_exceeds_operation lorsque les affectations actives de l'opération solderaient alors plus que le mouvement ne porte. Une Idempotency-Key absente est un validation_failed avec details.idempotency_key.
Le corps est contrôlé dans cet ordre et seul le premier refus est renvoyé : allocated_amount (details.allocated_amount), la référence de facture (details.invoice_document), le plafond de l'opération (details.base), puis le couple et les règles métier. Ces deux derniers portent leur raison dans message et n'ont pas de clé details.
La référence de facture a deux refus distincts, tous deux sous details.invoice_document. N'envoyez aucun invoice_document_id et c'est est obligatoire. Envoyez-en un qui ne se résout pas - l'identifiant d'une autre entreprise, un identifiant qui n'existe nulle part, ou une valeur qui n'est pas du tout un identifiant, null compris - et c'est est introuvable dans l'entreprise de cette opération. Ces trois cas répondent À L'IDENTIQUE, délibérément, pour que la réponse ne permette pas de sonder une facture que vous ne pouvez pas voir autrement.