Déclencher une transition de cycle de vie de facture

PATCH 
/api/v1/invoices/:id/transition

Déclenche une transition d'état de cycle de vie pour une facture.

L'event est l'un des événements AASM exposés dans le lifecycle_available_transitions de la facture. Les transitions disponibles dépendent de l'état de cycle de vie courant :

• draft → deposit
• deposited → receive, reject, cancel
• received → make_available, cancel
• available → take_in_charge, approve, dispute, refuse, send_payment, cancel
• taken_in_charge → approve, dispute, refuse, send_payment, cancel
• disputed → approve, refuse, cancel
• approved → send_payment
• payment_sent → collect

Pour une facture d'achat soumise au circuit d'approbation, send_payment n'est proposé que depuis approved.

Request

Responses

200

La facture après la transition, reflétant son nouveau lifecycle_state.

401

La requête ne comporte aucun jeton d'accès (bearer token) OAuth, ou celui-ci est invalide ou expiré.

403

Le jeton d'accès ne porte pas le scope write requis pour déclencher une transition de cycle de vie.

404

Aucune facture n'existe avec l'ID donné, ou la facture appartient à un espace de travail auquel l'application du jeton n'a pas accès - les deux cas renvoient cette même réponse afin de ne jamais révéler l'existence d'une ressource dans un autre espace de travail.

422

L'event demandé n'est pas une transition valide depuis l'état de cycle de vie courant de la facture, est manquant ou non reconnu, ou - pour un statut à déclaration CDV tel que dispute - omet le reason_code normalisé requis, ou - pour un refus (statut 210, refuse) - omet le texte libre reason qui doit le motiver, que le reason_code ne remplace pas, ou envoie un requested_action_code ou un requested_action avec un événement autre que dispute (statut 207), ou un requested_action_code hors de la liste BR-FR-CDV-CL-10. Le corps d'erreur indique error: "unprocessable_entity" avec un message décrivant l'échec précis. details est indexé par champ dès lors que le contrôle qui refuse nomme les attributs à corriger - le contrôle de dépôt y liste les mentions légales obligatoires manquantes - et vaut un objet vide quand le refus porte sur la facture dans son ensemble. Un deposit refusé par le contrôle Schematron nomme sa cause dans code : schematron_engine_unavailable (le moteur devait un verdict et n'a pas pu le produire - transitoire, réessayez, la facture n'est pas en cause) et schematron_profile_unsupported (la réforme n'admet aucun jeu de règles pour ce profil - déterministe, envoyez-en un autre) utilisent cette même enveloppe, tandis que schematron_fatal utilise un corps distinct ne portant qu'un objet errors indexé par champ et code, sans error, message ni details. Le deposit d'une facture libellée dans une devise autre que l'EUR est refusé avec code: "operation_failed" et un details vide lorsqu'aucun taux de change n'est disponible pour son issue_date : le total de TVA doit être porté en EUR à côté de la devise de la facture, ce qui exige un taux publié ; la facture reste donc à l'état draft - réessayez une fois les taux synchronisés. Un deposit est aussi refusé, avant le contrôle Schematron, lorsqu'une partie ne déclare aucun pays : details est sous la clé seller.address.country_code ou buyer.address.country_code. Scribee ne substitue plus FR à un pays que personne n'a déclaré, si bien que le country_code d'une partie peut valoir null dans une réponse et que BT-40 / BT-55 doivent être renseignés avant le dépôt. Seule l'obligation flux 1 porte cette règle de présence ; une vente dont l'acheteur doit une déclaration e-reporting (flux 10) n'est pas refusée pour cela.