Règles d'imputation bancaires

Des consignes permanentes qui imputent le RELIQUAT NON RAPPROCHÉ d'une opération bancaire sur un compte choisi. Une règle ne lettre JAMAIS une facture et ne crée aucun rapprochement : un rapprochement confirmé prime toujours sur elle, et ce qu'une règle décide, c'est seulement où atterrit ce qui reste. LE CHEMIN FIXE LA PORTÉE DÉFINITIVEMENT - une règle créée sous un espace de travail lie chacune de ses entreprises sauf celles qui en sont exclues, une règle créée sous une entreprise ne lie que celle-là, et scope et company_id envoyés dans le corps sont ignorés, parce que changer le niveau changerait la précédence. LA PORTÉE L'EMPORTE SUR LA PRIORITÉ : une règle société prime sur une règle d'espace de travail quels que soient leurs numéros, et priority n'ordonne que les règles de même portée. Le vocabulaire de conditions est FERMÉ et une clé inconnue est refusée plutôt qu'ignorée ; description_matches en particulier est un fragment littéral insensible aux accents et à la casse, et non une expression régulière. preview répond ce qu'une règle FERAIT d'une opération sans rien écrire, et ne demande que le scope de lecture.

📄️Lister les règles d'imputation bancaires d'un espace de travail

Retourne toutes les règles d'imputation de l'espace de travail - celles de portée espace de travail comme celles de portée société - dans l'ordre où le moteur les parcourt : `priority` croissant, puis `id` croissant. Attention, l'ordre de la LISTE n'est pas l'ordre de PRÉCÉDENCE : une règle société prime sur une règle d'espace de travail quelle que soit sa priorité, servez-vous donc de `scope` pour distinguer les deux niveaux.

📄️Créer une règle d'imputation d'espace de travail

Crée une règle qui s'applique à TOUTES les entreprises de l'espace de travail, sauf celles qui en sont exclues. Pour créer une règle liée à une seule entreprise, postez plutôt sur le chemin de portée société - c'est le chemin qui fixe le niveau de précédence, et il n'est plus modifiable ensuite. L'en-tête `Idempotency-Key` est accepté et facultatif : cette écriture ne produit aucun effet chez un tiers et se rejoue sans risque.

📄️Lister les règles d'imputation bancaires qui gouvernent une entreprise

Retourne les règles qui GOUVERNENT cette entreprise : ses propres règles de portée société ET les règles d'espace de travail dont elle n'est pas exclue. Les règles d'espace de travail y figurent à dessein - elles lient les opérations de cette entreprise et sont nommées dans l'explication que publie la simulation, si bien qu'une liste sans elles ne pourrait pas expliquer une imputation. Les règles désactivées sont listées elles aussi ; utilisez `enabled` pour filtrer.

📄️Créer une règle d'imputation société

Crée une règle liée à cette seule entreprise. Une règle société PRIME sur toute règle d'espace de travail quelle que soit sa priorité, et elle ne peut jamais faire l'objet d'une exclusion - elle ne s'applique déjà qu'à une seule entreprise, si bien que son `excluded_company_ids` est toujours vide. L'en-tête `Idempotency-Key` est accepté et facultatif.

📄️Lire une règle d'imputation bancaire

Retourne une règle d'imputation. `excluded_company_ids` est dérivé à chaque lecture, si bien qu'il reflète la règle telle qu'elle est à l'instant.

📄️Modifier une règle d'imputation bancaire

Modifie la règle sur place. L'activation et la désactivation passent par un PATCH de `enabled` plutôt que par un point de terminaison dédié. Le niveau de précédence est fixé à la création, si bien que `scope` et `company_id` envoyés dans le corps sont IGNORÉS plutôt que refusés - c'est ce qui vous permet de lire une règle et de renvoyer l'objet entier avec un seul champ modifié. `workspace_id` fait exception - il est lu par le contrôle d'habilitation d'espace de travail commun à toute l'API, si bien que renvoyer celui d'un espace pour lequel votre jeton n'a pas d'habilitation est refusé avec un 403. L'en-tête `Idempotency-Key` est accepté et facultatif.

📄️Supprimer une règle d'imputation bancaire

Supprime la règle et ses exclusions. Elle arrête les classements FUTURS et n'en réécrit aucun passé : une règle ne possède ni écriture comptable ni paiement, si bien que rien de déjà comptabilisé ne bouge. Le corps de la réponse est la règle telle qu'elle était au moment où vous en avez demandé la suppression.

📄️Simuler ce qu'une règle d'imputation ferait

Confronte la règle à de VRAIES opérations SANS RIEN ÉCRIRE - ni rapprochement, ni paiement, ni écriture comptable. C'est pour cela qu'elle ne demande que `read` : vous obliger à détenir `write` pour inspecter une règle serait à l'envers. Chaque ligne dit si la règle déterminerait la projection de cette opération, les lignes qu'elle produirait, et - par `overridden_by` - si une source de précédence supérieure l'emporte déjà.