Serveur MCP

Connectez les outils IA à Flowtly via le Model Context Protocol à mcp.flowtly.eu.

Connecter

claude mcp add --transport http flowtly https://mcp.flowtly.eu/mcp

Sur cette page

Accords

Outils

agreements_getRécupère un contrat de travail par id — type, variant, la fenêtre dateFrom/dateTo, hoursPerWeek, et les champs dérivés `calculable`, `active` et `status`. agreements_list fournit l'id. Nécessite ROLE_AGREEMENTS_MANAGER ou ROLE_MEETING_MANAGER. Lecture seule.
agreements_listListe les contrats de travail — filtre par employee (IRI), isActive, type ou variant. LE moyen de répondre à « pourquoi people_list indique que cette personne est inactive » : chaque ligne porte `calculable` et `active`, et une personne est active exactement quand elle détient un contrat où les deux sont vrais. C'est aussi l'endroit où lire les codes `type` d'agreement que cette organisation utilise réellement avant d'appeler agreements_create, car une organisation peut ajouter les siens. Nécessite ROLE_AGREEMENTS_MANAGER ou ROLE_MEETING_MANAGER. Lecture seule.
agreements_createCrée un contrat de travail (employment agreement) pour une personne. C'EST L'ÉTAPE QUI REND QUELQU'UN ACTIF : people_create ne fait que créer la fiche, et une personne sans agreement rapporte isActive à false pour toujours — un import en masse arrive donc 100% inactif tant que ceci n'a pas été exécuté pour chacun. DEUX CONDITIONS DOIVENT ÊTRE VRAIES SIMULTANÉMENT sinon la personne reste inactive sans aucune erreur : le `type` doit être CALCULABLE (les types intégrés "agreement", "annex", "termination" le sont ; "list-of-intent" et "work-experience" ne le sont pas), et la fenêtre dateFrom/dateTo doit couvrir aujourd'hui (passez dateTo à null pour un contrat en cours plutôt qu'une date lointaine dans le futur). `employee` est une IRI — /people/<id> depuis people_list. Les types sont extensibles par organisation, donc lancez agreements_list sur quelqu'un déjà actif pour voir les codes réellement utilisés par cette organisation. Nécessite ROLE_AGREEMENTS_MANAGER. Écriture.
agreements_updateModifie un contrat de travail existant — la façon dont un agreement est TERMINÉ, car le backend n'expose aucune suppression sur cette ressource : réglez `dateTo` sur le dernier jour couvert et la personne cesse d'être active à partir de là, avec la fiche et son historique intacts. C'est le bon geste pour une ligne liée à la paie ; il n'existe aucun moyen de la faire disparaître, et il ne devrait pas y en avoir. C'est aussi la façon de corriger sur place un `type`, `variant` ou `positionName` erroné plutôt que d'empiler un second agreement sur la personne — DEUX agreements ne s'annulent pas, celui qui est calculable la maintient active, donc « en ajouter un correct à côté » laisse silencieusement le mauvais en vigueur. `amount`, `amountType` et `billingType` sont acceptés mais l'API ne les retourne jamais, donc vous ne pouvez pas relire ce que vous avez écrit. Nécessite ROLE_AGREEMENTS_MANAGER. Écriture.

Types d'accord

Outils

agreementTypes_getRécupère un type de contrat par id — son name ou translationKey, `calculable`, `isActive`, `position` et `builtIn`. L'id EST le code : cela relit donc un type via la même chaîne qu'un agreement stocke dans `type`. À utiliser pour confirmer qu'un type a bien été persisté après agreementTypes_create, et pour vérifier `calculable` avant d'y placer quelqu'un. Nécessite ROLE_USER. Lecture seule.
agreementTypes_listListe les types de contrat que CETTE organisation peut mettre sur un agreement — les valeurs derrière `Ludzie > <person> > Umowy > Edytuj umowę`. À lire avant agreements_create ou agreements_import, car la liste est propre à chaque tenant : cinq types intégrés sont livrés ("agreement", "annex", "termination", "list-of-intent", "work-experience") et une organisation peut ajouter les siens, si bien qu'un `type` valide dans une organisation renvoie une 422 dans une autre. L'ID EST LE CODE — le `id` de chaque ligne est exactement la chaîne que `agreements_create` attend dans `type`, pas une clé numérique à résoudre. `calculable` est le champ qui décide si détenir ce type rend quelqu'un ACTIF et le fait compter dans le resourcing bench, l'accrual des congés et la base de coûts ; un type non calculable laisse la personne inactive sans aucune erreur nulle part, ce qui est voulu pour un type comme "list-of-intent" et un bug silencieux si le choix était accidentel. Les lignes `builtIn` portent une translationKey et un name à null ; les lignes personnalisées portent un name rendu tel quel et une translationKey à null. Nécessite ROLE_USER. Lecture seule.
agreementTypes_createAjoute un type de contrat à la liste de CETTE organisation, afin qu'un agreement puisse être enregistré pour quelque chose que les cinq types intégrés ne couvrent pas — "Umowa zlecenie", "Kontrakt B2B", "Użytkownik funkcyjny". C'est de la configuration, pas un changement de code : la liste est une table propre à chaque tenant, et un type personnalisé n'a besoin d'aucune entrée de traduction car son `name` est rendu tel quel dans les sept locales. N'ENVOYEZ PAS `id` : le code est dérivé du name côté serveur (slugifié), diacritiques repliés ("Użytkownik funkcyjny" devient "uzytkownik-funkcyjny"), et l'envoi d'un id est refusé avec une 422 "Update is not allowed for this operation". Postez le name et relisez le code assigné dans la réponse. `calculable` VAUT FALSE PAR DÉFAUT ET C'EST SILENCIEUX : cela décide qui compte comme employé — le resourcing bench, l'accrual des congés, la base de coûts et de budget — donc un type destiné à des personnes qui ne doivent PAS accumuler de congés ni occuper un FTE est correct à false, et un type destiné à un emploi réel DOIT le mettre à true, sinon tous ceux qui en dépendent rapportent inactif sans aucune erreur. Rien ne vous dira lequel des deux vous avez obtenu. `position` ordonne la liste déroulante ; `isActive` vaut true par défaut. Il n'y a volontairement ni update ni delete via MCP — `agreement.type` stocke l'id de cette ligne comme une simple chaîne sans aucune clé étrangère, donc renommer ou supprimer un type rend orphelin chaque agreement qui pointe vers lui. Nécessite ROLE_AGREEMENTS_MANAGER. Écriture.

Allocations

Outils

allocations_getUne allocation par id — la réservation d'une personne sur un projet, avec ses dates et son pourcentage. allocations_list permet de trouver l'id ; celui-ci lit l'enregistrement complet. Une allocation sans employé est un rôle OUVERT (demande non pourvue), pas une réservation. Nécessite le module resourcing. Lecture seule.
allocations_listListe les allocations de resourcing — affectations datées d'un poste sur un projet à un employé (ou à personne pour l'instant, un rôle ouvert). Aucun filtre ; pagination par curseur. Chaque élément contient employeeId/employeeName et projectId/projectName déjà résolus (employeeId null signifie un rôle ouvert) ; positionId est brut — résolvez son nom via positions_list. source distingue les lignes importées depuis une feuille de celles créées directement dans Flowtly. Utilisez ceci pour rapprocher un import de feuille resourcing : relisez ce qui a été enregistré et comparez avec ce qui a été soumis.

Réservations d'actifs

Outils

assetBookings_getRécupère une réservation d'actif (asset booking) par id — l'actif, son détenteur, les dates, et si elle a été annulée. Lecture seule.
assetBookings_listListe les réservations d'actifs — qui ou quoi détient actuellement chaque actif, l'affectation affichée par l'écran Assets et le seul endroit où vit réellement un lien actif-personne. Chaque ligne porte l'actif, le détenteur (`relationName` employee | project plus `relationId`), les dates de début/fin et, une fois libérée, `cancelReason` et `cancelledAt`. Filtrer par `property` pour voir l'historique d'un actif, ou par `employee` pour voir tout ce qu'une personne détient — ce second cas est celui à lancer avant le départ de quelqu'un. Notez que `employee` ici est l'id NUMÉRIQUE, pas l'IRI /people que prend assetBookings_create. Ajoutez `exists.cancelledAt: false` pour ne voir que ce qui est encore détenu ; sans cela, la liste inclut aussi les réservations libérées. Lecture seule.
assetBookings_createAffecte un actif à une personne ou à un projet. `property` est l'IRI de l'actif (/assets/{id}) et est requis. Nommez le détenteur d'UNE des trois façons : `relation` avec une seule IRI (/people/{id} pour une personne, /projects/{id} pour un projet), ou `relationName` (employee | project) plus `relationId`, ou directement le champ IRI `employee` / `project`. Exactement un détenteur doit se résoudre — n'en nommer aucun est refusé avec « Employee or Project must be set. » et nommer les deux avec « Employee and Project cannot be set at the same time. » DEUX CHOSES QUI NE SONT PAS DANS LE SCHÉMA ET QUI VOUS VAUDRONT UNE 422 : l'actif doit déjà être réservable (`bookingAllowed: true` — à définir avec assets_update), une règle métier appliquée à TOUT appelant y compris un manager, refusée avec « This asset is not reservable. » ; et le `bookingType` propre de l'actif (minutes | days | single-days | permanently) est ce qui donne son sens à `duration` / `endDate` — un espace dédié indéfiniment à une personne est `permanently` avec un `startDate` et pas de fin. Les réservations concurrentes sur un même actif sont sérialisées côté serveur, donc un chevauchement est refusé plutôt que doublement réservé. Nécessite ROLE_PROPERTY_BOOKINGS_MANAGER pour réserver au nom de quelqu'un d'autre. Écriture.
assetBookings_updateMet à jour une réservation d'actif existante — ses dates, sa duration, son montant/devise de facturation, ou sa part de consommation au compteur. `relationName` et `relationId` sont requis par le payload, donc envoyez le détenteur déjà associé à la réservation sauf si vous la déplacez délibérément. Pour mettre fin à une affectation, utilisez assetBookings_cancel, pas un endDate dans le passé. Nécessite ROLE_PROPERTY_BOOKINGS_MANAGER. Écriture.
assetBookings_cancelLibère un actif — la façon dont une affectation se termine, et ce qui se rapproche le plus d'une suppression pour cette ressource (il n'existe aucune opération de suppression). Prend l'id de la réservation et un `cancelReason` de 3 à 255 caractères ; la réservation est conservée et estampillée de `cancelledAt` pour que l'historique survive, et l'actif devient libre pour le prochain détenteur. C'est l'appel à faire quand un employé quitte l'organisation : assetBookings_list filtré par `employee` trouve ce qu'il détient, et cet appel libère chacun d'eux. Nécessite ROLE_PROPERTY_BOOKINGS_MANAGER. Écriture.

Relevés de compteurs d'actifs

Outils

assetMeterReadings_getRécupère un relevé de compteur (meter reading) par id — son meter, sa date et sa valeur. Lecture seule.
assetMeterReadings_listListe les relevés de compteur — les valeurs datées enregistrées pour un compteur d'actif (asset meter), les données brutes que lit la répartition de facturation au compteur. Chaque ligne porte le meter, la date et la valeur. À utiliser pour lire l'historique d'un compteur : une valeur qui ne bouge jamais d'une période à l'autre (compteur bloqué ou partagé) facture zéro, et un compteur sans ligne récente est un compteur que personne ne relève. Lecture seule.

Compteurs d'actifs

Outils

assetMeters_getRécupère un compteur d'actif (asset meter) par id — l'actif sur lequel il se trouve, le type de fluide (utility type), l'unité et l'identifiant externe/QR, avec ses relevés. Lecture seule.
assetMeters_listListe les compteurs d'actifs de l'organisation — les compteurs de fluides/énergie rattachés aux actifs (électricité, eau, gaz, chauffage). Chacun porte l'actif sur lequel il se trouve, son utilityType et son unité, ainsi que ses relevés. Filtrer par `property` (l'actif auquel il appartient) et `utilityType`. À utiliser pour résoudre l'id de meter que prennent les relevés, et pour repérer les compteurs qui affichent zéro, restent bloqués sur une valeur, ou se trouvent sur un compteur partagé/collectif. Lecture seule.
assetMeters_updateMet à jour un compteur d'actif (asset meter) — son label, son utility type, son unit, ou son état actif. À utiliser pour retirer un compteur du relevé (par ex. un fluide désormais facturé directement depuis la facture) sans supprimer son historique de relevés. Nécessite ROLE_PROPERTIES_MANAGER. Écriture.

Actifs

Outils

assets_getRécupère un actif par id — name, status, catégorie (attributeSet), parent, assetCode, numéro de série, dates d'achat et de garantie, location et paramètres de réservation. Lecture seule.
assets_listListe les actifs de l'organisation — le registre des biens physiques qu'elle possède ou vend, des ordinateurs portables et bureaux jusqu'aux appartements, places de parking et box de stockage. Filtrer par status (in-stock | damaged | sold), attributeSet (la catégorie selon laquelle la liste Assets regroupe), bookingAllowed, ou un name ou serialNumber partiel ; trier par name, status, serialNumber, boughtAt ou warrantyTo. NON PAGINÉ — l'ensemble complet revient en une seule réponse, donc un grand registre est une seule grosse charge utile plutôt qu'une première page. À utiliser pour résoudre l'id d'actif que prennent les réservations d'actifs et les documents d'actifs. Lecture seule.
assets_importCharge DE NOMBREUX actifs en un seul appel, indexés sur `assetCode` — l'outil pour importer un inventaire depuis un autre système, là où assets_create ferait un aller-retour par fiche. Les lignes se réconcilient avec l'organisation : un assetCode inconnu crée, un assetCode connu met à jour sur place, une ligne identique est ignorée, donc relancer l'opération ne change rien et une exécution inachevée peut être relancée sans risque. `parentAssetCode` imbrique une ligne sous une autre PAR SON CODE, résolu par rapport à l'organisation et par rapport aux lignes précédentes du même lot ; un parent qui ne se résout jamais fait échouer cette ligne plutôt que de l'orpheliner silencieusement. TROIS CHAMPS RENDENT LA FICHE LISIBLE plutôt qu'un simple name : `attributeSetName` est la catégorie que l'UI affiche comme Typ zasobu et selon laquelle la liste regroupe, `locationName` est l'endroit où se trouve physiquement la chose, et `attributes` est une map {name: value} pour area, floor, price et tout ce que la source porte d'autre. Les trois sont résolus PAR NOM — la catégorie, la location, les définitions d'attributs et leurs liaisons sont trouvées ou créées pour vous, donc l'appelant ne manipule jamais l'une de ces IRIs, et les names sont comparés sans tenir compte de la casse, si bien que "Mieszkanie" et "mieszkanie " ne peuvent pas scinder la liste en deux. `attributes` a besoin d'une catégorie à laquelle se rattacher, et une valeur qui s'analyse comme un nombre crée un attribut numérique, ce qui est décidé la première fois que le name apparaît. Un attribut dont l'écriture échoue ne fait PAS échouer son actif. PASSEZ D'ABORD dryRun:true lors d'un vrai chargement d'inventaire — il indique would-create / would-update / would-skip par ligne et ne crée absolument rien, catégories et locations comprises. 1000 lignes max. Nécessite ROLE_PROPERTIES_MANAGER. Écriture.
assets_createCrée un actif (name + status + bookingType requis ; status = in-stock | damaged | sold, bookingType = minutes | days | single-days | permanently). bookingType est requis même quand l'actif n'est jamais réservé — passez "permanently" pour quelque chose qui n'est pas prêté, et laissez bookingAllowed à false. Deux champs portent la structure : `parent` imbrique un actif sous un autre (une unité sous un immeuble, un écran sous un bureau), et `attributeSet` fixe la catégorie selon laquelle la liste Assets regroupe, qui est aussi là où vivent les attributs personnalisés comme area ou floor. `assetCode` est un identifiant cross-système UNIQUE — utilisez-le pour porter l'id que cet actif a dans le système d'origine depuis lequel il a été importé, afin qu'un réimport mette à jour plutôt que de dupliquer. Nécessite ROLE_PROPERTIES_MANAGER. Écriture.
assets_updateMet à jour un actif par id — name, status, catégorie, parent, assetCode, numéro de série, dates, location ou paramètres de réservation. C'est ainsi qu'un actif passe de in-stock à sold. Notez que le vocabulaire de status est in-stock | damaged | sold et n'a AUCUN état reserved, donc une mise de côté doit être modélisée autrement. Nécessite ROLE_PROPERTIES_MANAGER. Écriture.

Valeurs d'attributs d'entité

Outils

attributeEntityValues_listListe les VALEURS d'attributs — ce qu'un actif, projet, budget ou client précis détient réellement pour un attribut lié. Chaque ligne porte l'attribute, la value, et `relationId` nommant l'entité à laquelle elle appartient. Lecture seule.
attributeEntityValues_createDéfinit une valeur d'attribut sur une entité (attribute + value requis). `relation` EST UNE IRI — "/properties/7", pas le mot "property" : le backend la résout et dérive le nom de relation à partir de la classe de ressource, donc passer un simple nom échoue. (`relationId` prend un id brut et fonctionne encore, mais il est déprécié au profit de l'IRI.) L'attribut doit déjà être LIÉ à la catégorie de cette entité, sinon la valeur est stockée mais jamais affichée. Nécessite ROLE_ATTRIBUTES_MANAGER. Écriture.
attributeEntityValues_updateModifie une valeur d'attribut sur place, par son id. À utiliser plutôt que de créer une seconde valeur pour la même paire (entité, attribut) — rien n'impose l'unicité, donc un doublon est accepté et l'UI en affiche un des deux. Nécessite ROLE_ATTRIBUTES_MANAGER. Écriture.
attributeEntityValues_deleteRetire une valeur d'attribut d'une entité. La définition et la liaison survivent ; seule la valeur de cette entité disparaît. Nécessite ROLE_ATTRIBUTES_MANAGER. Écriture.

Attributs

Outils

attributes_getRécupère une définition d'attribut par id — name, type, si elle est required ou multiple, valeur par défaut et format pattern. Lecture seule.
attributes_listListe les DÉFINITIONS d'attributs — les champs nommés (area, floor, price) que les catégories lient et pour lesquels les actifs portent des valeurs. Chacun a un type : number | string | date | state | period. Lecture seule.
attributes_createCrée une définition d'attribut (name + type requis ; type vaut number | string | date | state | period). LE TYPE EST LA DÉCISION QUI COMPTE : il est partagé par toute entité portant cet attribut, donc un champ créé en `string` ne pourra pas ensuite être totalisé ou trié comme un nombre sans que toutes les valeurs existantes soient réécrites. Décidez-le en fonction des valeurs que vous avez réellement, pas de la première que vous voyez. Une définition seule ne fait rien — liez-la à une catégorie avec attributeSetAttributes_create, sinon elle n'apparaît jamais nulle part. Nécessite ROLE_ATTRIBUTES_MANAGER. Écriture.
attributes_updateMet à jour une définition d'attribut — name, type, required, multiple, default ou format. Changer `type` sur une définition qui a déjà des valeurs est le cas risqué : les valeurs existantes ne sont pas converties. Nécessite ROLE_ATTRIBUTES_MANAGER. Écriture.

Attributs d'ensembles d'attributs

Outils

attributeSetAttributes_listListe les liaisons entre catégories et définitions d'attributs — quels champs apparaissent sur quelle catégorie. Lecture seule.
attributeSetAttributes_createLie une définition d'attribut à une catégorie (attributeSet + attribute, toutes deux des IRIs). C'EST CE QUI FAIT APPARAÎTRE UN ATTRIBUT : sans cette liaison, une valeur peut être écrite avec succès sur une entité et ne s'affichera jamais dans l'UI — un échec sans aucun symptôme. Nécessite ROLE_ATTRIBUTES_MANAGER. Écriture.
attributeSetAttributes_deleteDélie un attribut d'une catégorie. La définition et les valeurs éventuelles survivent ; elles cessent simplement d'être affichées pour cette catégorie, ce qui peut avoir l'air d'une perte de données alors que ce n'en est pas une. Nécessite ROLE_ATTRIBUTES_MANAGER. Écriture.

Ensembles d'attributs

Outils

attributeSets_getRécupère un attribute set par id — son name, relationName, icon, et les attributs qui y sont liés. Lecture seule.
attributeSets_listListe les attribute sets de l'organisation — les CATÉGORIES sous lesquelles un actif, projet, budget ou client est classé. Filtrer par relationName : "property" pour les catégories d'actifs (ce que l'UI appelle Typ zasobu et selon quoi la liste Assets regroupe), plus "project", "budget" et "client". À consulter avant d'en créer une : une catégorie dupliquée par une faute d'orthographe ou une casse différente scinde silencieusement la liste qu'elle regroupe, et rien dans l'UI n'explique pourquoi. Lecture seule.
attributeSets_createCrée une catégorie (name + relationName requis ; relationName vaut property | project | budget | client, et pour une catégorie d'actif c'est la simple chaîne "property" — PAS une IRI). icon optionnelle issue d'une liste fixe (room, parking, building, office, local, desk, monitor, etc.) que l'UI affiche à côté de la catégorie. LISTEZ D'ABORD : les names ne sont pas uniques, donc un second "Mieszkanie" est accepté et scinde silencieusement la liste Assets en deux. Nécessite ROLE_ATTRIBUTES_MANAGER. Écriture.
attributeSets_updateRenomme une catégorie, change son icon, ou la déplace vers un autre relationName. C'est ainsi qu'une catégorie créée avec une faute de frappe est corrigée plutôt que dupliquée. Nécessite ROLE_ATTRIBUTES_MANAGER. Écriture.

Comptes bancaires

Outils

bankAccounts_getRécupère un compte bancaire par id — nom, devise, banque, et le format dans lequel ses relevés sont importés.
bankAccounts_listListe les comptes bancaires de l'organisation. Filtrez par banque, ou définissez hidden pour inclure les comptes archivés. Utilisez-le pour résoudre l'id bankAccount sur lequel filtre transactions_list.
bankAccounts_createCrée un compte bancaire (type, name, currency, defaultImportFormat requis). Écriture.
bankAccounts_updateMet à jour un compte bancaire par id. Écriture.

Banques

Outils

banks_getRécupère une banque par id — l'établissement, pas un compte détenu auprès de celui-ci. Utilisez bankAccounts_get pour le compte.
banks_listListe les banques auprès desquelles les comptes de l'organisation sont détenus. Les banques masquées (hidden) sont INCLUSES par défaut — passez hidden=false pour la vue des sélecteurs, ou hidden=true pour retrouver celles retirées. À utiliser pour résoudre l'id de banque sur lequel filtre bankAccounts_list et dont bankAccounts_create a besoin.
banks_createCrée une banque — l'établissement auquel appartient un compte bancaire, pas le compte lui-même (c'est bankAccounts_create). Écriture.
banks_updateMet à jour une banque par id. C'est aussi la façon de masquer et démasquer une banque : mettez `hidden` à true pour la retirer des sélecteurs sans la supprimer, à false pour la faire revenir. Il n'y a pas d'outil d'archivage séparé car l'API n'a aucune action d'archivage pour une banque — le flag est le mécanisme. Écriture.

Budgets

Outils

budgets_employeePnlCompte de résultat (P&L) par employé pour un budget — ce que le temps de chaque personne a rapporté par rapport à ce qu'elle a coûté. Nécessite ROLE_BUDGETS_VIEWER. Lecture seule.
budgets_getRécupère un budget par id — sa période, sa portée et ses paramètres. Nécessite ROLE_BUDGETS_VIEWER. Lecture seule.
budgets_listListe les budgets de l'organisation — les périodes par rapport auxquelles les revenus et les coûts sont planifiés et comparés. À utiliser pour résoudre l'id de budget que prend chaque outil pnl. Nécessite ROLE_BUDGETS_VIEWER. Lecture seule.
budgets_pnlByTagsCompte de résultat (P&L) d'un budget, décomposé PAR TAG — income, costsByTag, costsByProject et netByTag sur les périodes du budget. L'axe tag est ce qui rend cela lisible pour une activité dont les coûts ne sont pas naturellement par projet : taguez les documents, et la répartition suit. Porte displayPricePerSqm quand l'organisation a activé le price-per-sqm et nommé un attribut area, ce qui transforme ceci en vue au mètre carré pour un promoteur immobilier. Nécessite ROLE_BUDGETS_VIEWER. Lecture seule.
budgets_pnlByTagsDrilldownLes documents derrière une cellule de budgets_pnlByTags. À utiliser quand un total par tag semble faux — cela nomme les transactions qui composent le chiffre au lieu de vous laisser deviner. Nécessite ROLE_BUDGETS_VIEWER. Lecture seule.

Clients

Outils

clients_getRécupère un client par id — nom, pays, devise, identifiant fiscal et statut.
clients_listListe les clients (les clients de l'organisation). Filtrez par status, ou par externalPaymentCustomerId pour trouver le client derrière un id de fournisseur de paiement. Utilisez-le pour résoudre l'id client sur lequel filtrent invoices_list, deals_list, projects_list et contracts_list.
clients_importCharge DE NOMBREUX clients en un seul appel, indexés sur `externalRef` — l'outil pour importer une liste de clients ou d'acheteurs depuis un autre système, là où clients_create ferait un aller-retour par personne. Les lignes se réconcilient avec l'organisation : un externalRef inconnu crée, un externalRef connu met à jour sur place, une ligne identique est ignorée, donc relancer l'opération ne change rien. La référence est stockée dans `externalPaymentCustomerId`, la seule colonne de référence externe qu'ait un client, et `clients_list` filtre dessus. NE FAITES PAS correspondre les clients par name à la place — une liste d'acheteurs est pleine de noms de famille partagés et d'achats conjoints. Chaque résultat porte `counterpartyId`, dont ont besoin contracts_import et contracts_create. Deux pièges que le schéma ne peut pas exprimer : un `tin` est REJETÉ sans `tinCountry`, et une ligne de contact a besoin d'un e-mail, donc un numéro de téléphone seul ne peut pas en créer une. PASSEZ dryRun:true D'ABORD sur un vrai import d'onboarding. Max 500 lignes. Nécessite ROLE_CLIENTS_MANAGER. Écriture.
clients_createCrée une nouvelle fiche client (name, country, currency, status, tinType requis). Écriture.
clients_updateMet à jour une fiche client par id. Écriture.

Clés de configuration

Outils

configKeys_catalogListe toutes les clés de configuration de l'organisation reconnues par le backend, avec leur type et leurs valeurs autorisées. C'est le catalogue de ce qui est configurable — consultez-le avant configs_get ou configs_update plutôt que de deviner un nom de clé. La permission est appliquée par clé par le backend, donc l'apparition d'une clé ici ne garantit pas que l'utilisateur connecté puisse l'écrire.

Configurations

Outils

configs_getLit une valeur de configuration de l'organisation par id, où l'id est une clé issue de configKeys_catalog (par ex. organization-logo-url, organization-icon-url).
configs_updateMet à jour une valeur de configuration de l'organisation par id (type + name requis ; les permissions sont appliquées par le backend clé par clé). Écriture.

Contrats

Outils

contracts_getRécupère un contrat par id — parties, sens, valeur, conditions cycliques et dates.
contracts_listListe les contrats. Filtre par direction — les valeurs stockées sont "out" (nous vendons / émettons) et "in" (nous achetons / recevons), plus "unknown" — un état réel et filtrable, pas une erreur. Un contrat créé en téléversant un document démarre en "unknown" et y reste jusqu'à ce que l'extraction ou une personne le règle, donc omettez le filtre pour obtenir les trois : "in" et "out" interrogés séparément NE totalisent PAS l'ensemble complet (flowtly-mcp#130). PAS "outgoing"/"incoming" : ces valeurs ne correspondent à rien et reviennent comme une liste vide plutôt qu'une erreur. Filtre aussi sur counterparty, project, cyclic, name ou tags. À utiliser pour résoudre l'id de contrat que lit contracts_paymentScheduleLines et auquel deals_win peut lier un deal gagné.
contracts_paymentScheduleLinesListe l'échéancier de paiement (payment schedule) d'un contrat — les échéances auxquelles il est censé être facturé ou payé. Passez contractId depuis contracts_list. C'est le plan, pas le réalisé : comparez-le à transactions_list pour voir ce qui a réellement été payé. Le montant de chaque ligne est en UNITÉS MINEURES — des grosze, pas des złote : "530000" représente 5 300,00, donc divisez par 100 avant de communiquer un chiffre à qui que ce soit.
contracts_importCharge DE NOMBREUX contrats en un seul appel, indexés sur `name` — le numéro d'agreement. Contrairement à un client ou un actif, un contrat n'a AUCUNE colonne de référence externe, donc le name EST la clé d'idempotence ; un lot contenant deux fois le même name est REFUSÉ EN BLOC plutôt que de mettre à jour un contrat deux fois, car un numéro dupliqué signifie que la source est en tort. `counterpartyExternalRef` résout l'acheteur via la même référence que celle donnée à clients_import, donc les deux s'enchaînent : importez les clients, puis les contrats, sans jamais manipuler un id numérique de counterparty — une référence ne correspondant à aucun client fait échouer cette ligne plutôt que de créer un contrat sans partie. `direction` vaut "out" (nous vendons) ou "in" (nous achetons) ; la colonne n'a aucune contrainte côté serveur, donc un mot erroné est stocké et le contrat ne correspond alors plus à aucun filtre nulle part. PASSEZ dryRun:true D'ABORD. Max 500 lignes. Nécessite ROLE_CONTRACTS_MANAGER. Écriture.
contracts_createCrée un contrat. Écriture.
contracts_updateMet à jour un contrat par id. Écriture.
contracts_deleteSupprime un contrat par id. Écriture.

Groupes de coûts

Outils

costGroups_listListe les groupes de coûts / centres de coûts — les catégories sous lesquelles sont classés les coûts, fournisseurs et factures entrantes. Utilisez-le pour résoudre l'id costGroup requis par suppliers_create et proposé par les suggestions de factures entrantes.
costGroups_createCrée un groupe de coûts / centre de coûts (name + type requis). Écriture.
costGroups_updateMet à jour le nom ou le type d'un groupe de coûts / centre de coûts par id. Écriture.

Contreparties

Outils

counterparties_getRécupère une contrepartie par id.
counterparties_listListe les contreparties — chaque partie avec laquelle l'organisation transige. Les indicateurs supplier et client précisent le(s) rôle(s) joué(s) par une contrepartie, et un même enregistrement peut cumuler les deux. C'est la partie figurant sur une transaction bancaire, donc c'est elle qui sert de référence de rapprochement pour les factures entrantes et les transactions. Filtrez par type, supplier, client, cyclic ou budgetNeutral.

Notes CRM

Outils

crmNotes_getRécupère une note CRM par id.
crmNotes_listListe les notes rédigées sur les prospects et les affaires. Filtrez par lead ou deal pour lire le fil de commentaires d'un enregistrement.
crmNotes_createAjoute une note à un prospect ou une affaire (body + exactement un des deux, lead ou deal). L'auteur est l'utilisateur connecté. Écriture.
crmNotes_updateMet à jour le contenu d'une note CRM par id. Écriture.
crmNotes_deleteSupprime une note CRM par id. Écriture.

Motifs de perte d'affaire

Outils

dealLostReasons_getRécupère un motif de perte d'affaire par id.
dealLostReasons_listListe les raisons pour lesquelles une affaire peut être marquée comme perdue, dans l'ordre. deals_lose requiert un lostReasonId issu d'ici.

Affaires

Outils

deals_getRécupère une affaire par id — titre, client, étape, montant, propriétaire, contact, dates de clôture prévue et réelle.
deals_listListe les affaires/opportunités — le pipeline commercial. Filtrez par status (open / won / lost), stage, owner, client, lead, ou par plages expectedCloseDate / closedAt. Les montants sont en unités mineures avec une devise explicite ; ne présumez pas de la devise par défaut de l'organisation.
deals_createCrée un deal/opportunité. Requis : title, stage (depuis stages_list), et un ANCRAGE — au moins un des deux, client ou lead. Un deal sans aucun des deux est refusé avec une 422 « A deal must reference a client or a lead. », donc ancrez un prospect pour lequel vous n'avez pas de fiche client à son lead (`/leads/<id>` depuis leads_list) plutôt que d'inventer un client ; passez client (`/clients/<id>` depuis clients_list) une fois qu'il en existe un. Définir les deux est autorisé. Optionnel : amountMinor, currency, expectedCloseDate, owner, contact. Créer directement dans un stage gagné nécessite en plus client — un deal reposant uniquement sur un lead ne peut pas être gagné. Écriture.
deals_updateMet à jour un deal par id (title, stage, amountMinor, currency, expectedCloseDate, owner, contact, client, lead). Déplacer le stage est journalisé automatiquement. La règle d'ancrage de deals_create s'applique toujours au résultat, donc vous ne pouvez pas vider le seul client ou lead qu'a un deal — substituez-en un d'abord. Déplacer un deal vers un stage gagné nécessite client : rattachez le client ici (ou lancez leads_convert) avant de gagner un deal reposant uniquement sur un lead. Écriture.
deals_deleteSupprime une affaire par id (suppression douce). Écriture.
deals_winMarque un deal comme gagné — le déplace vers un stage gagné et l'estampille clos ; contractId optionnel lie un contrat existant. RATTRAPAGE D'UN GAIN HISTORIQUE : passez le closedAt optionnel (ISO-8601, par ex. « 2026-05-07 » ou un timestamp complet) pour enregistrer la date à laquelle il a RÉELLEMENT été clôturé. Omettez-le et le serveur estampille maintenant, ce qui place un vieux deal dans le chiffre « gagné ce mois-ci » du mois en cours — réglez-le donc dès que vous saisissez un deal clôturé avant aujourd'hui. Il ne peut pas être dans le futur (422), et il PEUT être antérieur au propre createdAt du deal : un deal créé aujourd'hui et clôturé en mai est la forme normale d'un rattrapage correct, pas une erreur. Le deal doit DÉJÀ référencer un client : gagner un deal reposant uniquement sur un lead est refusé avec une 422 « Attach a customer before marking this deal Won. », car il n'y a pas de client à facturer. Transformez le lead en client avec leads_convert, ou définissez client avec deals_update, puis gagnez. Écriture.
deals_loseMarque un deal comme perdu — nécessite lostReasonId (depuis dealLostReasons_list) ; lostReasonNote optionnel. RATTRAPAGE D'UNE PERTE HISTORIQUE : passez le closedAt optionnel (ISO-8601) pour enregistrer la date à laquelle il a RÉELLEMENT été clôturé, exactement comme le fait deals_win. Omettez-le et le serveur estampille maintenant. Il ne peut pas être dans le futur (422), et peut être antérieur au createdAt du deal. Écriture.
deals_reopenRouvre une affaire gagnée/perdue et la remet à l'état ouvert. Écriture.

Historiques des étapes d'affaire

Outils

dealStageHistories_getRécupère un enregistrement de changement d'étape d'affaire par id.
dealStageHistories_listListe les transitions d'étape d'une affaire, la plus récente en premier. Filtrez par deal. Chaque deals_update qui change l'étape est enregistré automatiquement ici, c'est donc ainsi que vous reconstituez combien de temps une affaire est restée à chaque étape — l'affaire elle-même ne conserve que son étape actuelle.

Départements

Outils

departments_listLes départements de l'organisation, avec l'id numérique par lequel chacun est référencé. À LIRE AVANT people_create ou people_update : les deux acceptent une IRI `department` et il n'existe aucun autre moyen d'en découvrir une valide. La collection n'est pas paginée et est triée par name, donc un seul appel retourne tous les départements de l'organisation. Filtrer par `name` (correspondance partielle) ou `code` (exacte). Les lignes portent id, name et code ; `manager` est une relation et n'est pas inclus dans les lignes de liste — lisez-le via people_list depuis l'autre côté si nécessaire. Nécessite ROLE_EMPLOYEES_VIEWER. Lecture seule.
departments_createAjoute un département, afin que des personnes puissent y être classées. `name` est requis (jusqu'à 128 caractères) et UNIQUE au sein de l'organisation ; `code` est optionnel (jusqu'à 64) et EST AUSSI unique — la forme courte qu'une organisation utilise déjà dans ses propres tableurs (CEO, TECH, PROC). `manager` est une IRI employee optionnelle depuis people_list. LISTEZ D'ABORD ET ATTENDEZ-VOUS À DES COLLISIONS : comme name et code sont tous deux uniques, republier un département déjà existant ÉCHOUE au lieu d'être idempotent, donc un import qui suppose un create par ligne se bloquera dès qu'il rencontrera un département déjà présent dans l'organisation — typiquement un reliquat d'un essai. Réconciliez cette ligne avec departments_update plutôt que de créer autour d'elle. IL N'Y A PAS DE SUPPRESSION : le backend n'expose aucune suppression sur un département, donc un name ou code erroné est corrigé sur place avec departments_update et jamais supprimé. Nécessite ROLE_EMPLOYEES_MANAGER. Écriture.
departments_updateRenomme un département, lui donne un code, ou définit son manager. C'est l'outil qui rend un import de départements possible plutôt que simplement pratique : `name` et `code` sont tous deux uniques, donc un département que l'organisation possède déjà — la seule ligne "HR" qu'un proof-of-concept a tendance à laisser derrière lui — ne peut pas être créé à nouveau, et la vraie liste s'atteint en CORRIGEANT cette ligne plutôt qu'en entrant en collision avec elle. Seuls les champs envoyés changent, donc passer `code` seul laisse le name intact. `id` est l'id numérique depuis departments_list ; `manager` est une IRI employee depuis people_list. IL N'Y A PAS DE SUPPRESSION, ce qui fait de cet outil toute l'histoire de la réparation : un département créé avec une faute de frappe est corrigé ici, et un département qui ne devrait pas exister ne peut être que renommé, pas supprimé. Nécessite ROLE_EMPLOYEES_MANAGER. Écriture.

Plafonds de jours de congé

Outils

holidayDaysLimits_getUne ligne d'entitlement (droit acquis) par id — le amount, le type, la variant de contrat et la date de prise d'effet. holidayDaysLimits_list permet de trouver l'id. Les montants sont en SECONDES (#3763). Lecture seule.
holidayDaysLimits_listCombien de congés chaque personne a DROIT, par type — pas combien elle a pris, ce qui relève de holidays_list. Filtre par employee. Une personne peut détenir plusieurs lignes pour un même type au fil du temps, car un solde est réajusté ou corrigé : la ligne EN VIGUEUR est celle avec le dateFrom le plus récent déjà arrivé, et les lignes datées dans le futur sont délibérément ignorées jusque-là. Les montants sont en SECONDES (#3763) — une journée de congé de 8h vaut 28800. Nécessite ROLE_HOLIDAYS_MANAGER. Lecture seule.
holidayDaysLimits_createAttribue à une personne une allocation d'un type de congé, effective à partir d'une date. En `seconds`, PAS en jours (#3763) : une journée de 8h vaut 28800, donc 21 jours vaut 604800 et un solde d'heures supplémentaires de 2h30 vaut 9000 — un chiffre qui n'avait nulle part où aller tant que c'était stocké en jours entiers. `employee` et `holidayType` sont des IRIs (fournies par people_list et holidayTypes_list) ; `variant` est le type de contrat auquel appartient l'allocation (uop, b2b, uz, uod). Pour CORRIGER un solde existant, ajoutez une ligne avec un dateFrom plus tardif plutôt que d'éditer l'ancienne — la ligne en vigueur est la plus récente dont le dateFrom est arrivé, donc l'historique reste intact et une correction peut être saisie avant sa prise d'effet. (employee, holidayType, variant, dateFrom) est unique, donc republier le même jour ne remplace rien et échoue. Nécessite ROLE_HOLIDAYS_MANAGER. Écriture.
holidayDaysLimits_updateCorrige une ligne saisie par erreur — une faute de frappe dans le montant, la mauvaise variant. Les montants sont en SECONDES (#3763). Ce n'est PAS ainsi que vous enregistrez un solde qui CHANGE au fil du temps : pour cela, faites un holidayDaysLimits_create d'une nouvelle ligne avec un dateFrom plus tardif, ce qui préserve ce qu'était le solde précédent et à quel moment. Éditer sur place réécrit l'historique et rend l'ancien chiffre irrécupérable. holidayDaysLimits_list permet de trouver l'id. Nécessite ROLE_HOLIDAYS_MANAGER. Écriture.

Demandes de congé

Outils

holidayRequests_listLes DEMANDES de congé et leur statut — en attente, approuvée, rejetée. À distinguer de holidays_list, qui recense les congés réservés : une demande encore en attente de décision n'est pas encore une absence, donc planifiez à partir de holidays_list et utilisez celui-ci pour voir ce qui attend une décision de quelqu'un. Fournit le holidayRequestId attendu par holidays_approve et holidays_bulkApprove. Lecture seule.
holidayRequests_cancelAnnule une demande de congé — à utiliser pour évacuer une demande qui ne devrait jamais être traitée, comme une ligne laissée par un essai, un test, ou quelqu'un qui a quitté l'organisation. DEUX CHOSES QUI SURPRENNENT. (1) CELA NE SUPPRIME PAS LA LIGNE : le backend met status à `canceled` plutôt que de supprimer la ligne. MAIS UNE DEMANDE ANNULÉE DISPARAÎT DE holidayRequests_list — vérifié en production : ensuite, ni la liste non filtrée ni status=canceled ne la retourne. Vous ne pouvez donc pas relire ce que vous avez annulé et il n'y a pas d'annulation de l'annulation via le MCP ; soyez sûr de l'id avant d'appeler. (2) CE N'EST PAS LA MÊME CHOSE QUE REJETER. Rejeter enregistre une décision — cela écrit une entrée de journal d'approbation vous nommant et ENVOIE UN E-MAIL À L'EMPLOYÉ pour dire que son congé a été refusé — alors qu'annuler ne notifie que les RH, et seulement quand `notify-hr-managers-of-leave-activity` est activé pour l'organisation. Pour une ligne qui n'a jamais été une vraie demande, l'annulation est la version honnête et la plus discrète. NE FONCTIONNE QUE SUR UNE DEMANDE EN ATTENTE (`requested`) quand vous n'en êtes pas le propriétaire : une demande acceptée a déjà produit un Holiday que ceci ne supprime pas, donc annuler une telle demande laisserait une absence réservée derrière une demande affichant `canceled`. Nécessite ROLE_HOLIDAYS_MANAGER pour la demande de quelqu'un d'autre ; le demandeur peut toujours annuler la sienne. holidayRequests_list fournit l'id. Écriture.

Congés

Outils

holidays_activeQui est absent EN CE MOMENT — tous les congés en cours, pour toute l'organisation. C'est l'outil pour « qui est absent aujourd'hui », et celui à vérifier avant de considérer le freePercent de resourcingBench_get comme une disponibilité, car le bench ne déduit pas les congés. Contrairement à holidays_list, il n'applique aucune restriction par projet et ne nécessite aucune permission au-delà d'être connecté, sa réponse couvre donc toute l'organisation. Renvoie chaque absence avec son type et ses dates. Lecture seule.
holidays_getUn enregistrement de congé par id, avec son type, ses dates et sa durée. Récupérez l'id depuis holidays_list ou holidays_active. Lecture seule.
holidays_listCongés réservés sur une période — la vue de planification, là où holidays_active ne répond que pour aujourd'hui. Filtrez par employé, par plage de dates, ou par projet. CE QUE VOUS VOYEZ DÉPEND DE VOS PERMISSIONS, et une liste courte n'est pas la preuve que personne n'est absent : un gestionnaire de congés ou un lecteur comptabilité obtient toute l'organisation, tandis qu'un chef de projet ou un lecteur DOIT passer un filtre de projet (ou interroger sur lui-même) et se voit refuser l'accès sans cela — ce refus est une limite de permission, pas un calendrier vide. Lecture seule.
holidays_createEnregistre un congé qu'une personne prend réellement — l'absence réservée elle-même, pas le droit (holidayDaysLimits_create) et pas une demande en attente (les holiday requests, qui doivent encore être approuvées). Ce que cet outil écrit est du temps libre déjà convenu, donc cela apparaît immédiatement dans holidays_list et ne nécessite aucune étape d'approbation. `employee` est une IRI depuis people_list ; `type` est un id de holidayTypes_list. `dateFrom`/`dateTo` inclusifs, et un seul appel couvre toute une plage plutôt qu'une ligne par jour. Deux choses mordent : un type dont `descriptionRequired` est true (lisez d'abord holidayTypes_list — `vacations` l'est couramment) REJETTE un create sans `description` ; et `pick-up-day` est du temps déjà dû, donc cela NE consomme PAS l'allocation annuelle comme le fait `vacations` — enregistrer une journée rendue pour un jour férié tombant un samedi en tant que `vacations` mange silencieusement une journée du droit de quelqu'un. Vérifiez holidays_list pour la même personne et les mêmes dates avant de créer, car un chevauchement est REFUSÉ, pas dupliqué : le backend lève `validation_holiday_dates_overlap` sous forme d'une 422 sur `dateTo` quand la plage touche un jour déjà couvert par une autre absence de cette personne. La seule exception est étroite — deux absences d'UNE SEULE JOURNÉE à temps partiel à la même date, de types DIFFÉRENTS, toutes deux `vacations` ou `pick-up-day`, dont les heures cumulées tiennent dans la journée de travail. Tout autre chevauchement échoue. Il EXISTE un holidays_update, donc changer le type d'une absence ne nécessite plus de supprimer puis recréer. CHAQUE CREATE ENVOIE UN E-MAIL À L'EMPLOYÉ, à sa propre adresse d'entreprise, pour dire que l'absence a été ajoutée — donc charger une année d'historique déjà vécue arrive dans sa boîte de réception ligne par ligne, et pour le personnel qui n'a pas encore été invité, c'est la toute première fois qu'il entend parler de Flowtly. VOUS CHARGEZ UNE ANNÉE D'HISTORIQUE ? Une forme en masse existe — holidays_import réconcilie jusqu'à 500 absences en un seul appel, ignore celles déjà enregistrées, donc peut être relancé sans risque, et désactive l'e-mail par défaut — mais ELLE N'EST PAS DISPONIBLE SUR CETTE CONNEXION : elle n'est servie qu'au scope interne, vous ne pouvez donc pas l'appeler ici et la chercher ne la trouvera pas. Appelez cet outil en boucle, ou demandez à votre opérateur Flowtly d'effectuer le chargement en masse. Passez `notify: false` pour un BACKFILL d'absences déjà passées ; ne le touchez pas quand vous enregistrez quelque chose de nouveau, car alors l'e-mail est tout l'intérêt. Cela supprime uniquement le message — la ligne, son `createdAt` et son fait de paie sont écrits dans tous les cas. Nécessite ROLE_HOLIDAYS_MANAGER. Écriture.
holidays_deleteSupprime purement et simplement une absence réservée — la ligne est supprimée, contrairement à holidayRequests_cancel qui ne fait que changer le status d'une demande. À utiliser pour évacuer des absences qui n'auraient jamais dû compter : lignes de démo ou de test laissées par un essai, ou orphelines suite à la suppression de leur employé (people_delete détache les absences au lieu de les supprimer, donc elles survivent avec un employee name vide). CECI DÉPLACE DE VRAIS CHIFFRES : une absence réservée est `payrollEligible` et consomme le droit de la personne, donc en supprimer une change son solde de congés — c'est le but quand on nettoie des données de test, et un bug de perte de données quand la ligne était réelle. Aucune annulation, aucune notification. Lisez d'abord holidays_list et soyez certain que la ligne n'est pas un historique réel : une description dans la langue propre de l'organisation, ou des dates correspondant à une absence réelle, signifie généralement qu'elle l'est. Nécessite ROLE_HOLIDAYS_MANAGER. Écriture.

Types de congé

Outils

holidayTypes_listLes types de congés que cette organisation utilise, avec l'id par lequel chacun est référencé. À lire avant holidayDaysLimits_create/update, qui ont besoin d'une IRI holidayType et qui seront sinon devinées. Celui qui n'est pas un congé au sens ordinaire est `pick-up-day` — du temps libre dû pour des heures supplémentaires déjà travaillées (polonais *odbior nadgodzin*), qui est un solde ACCORDÉ plutôt qu'un droit annuel. Lecture seule.
holidayTypes_createAjoute un type de congé que l'organisation n'offre pas encore — un sabbatique, une garde d'enfant non rémunérée, un jour de formation — afin que des absences puissent y être réservées avec holidays_create et qu'une allocation puisse être accordée avec holidayDaysLimits_create. `name` (3 à 64 caractères) est ce parmi quoi les gens choisissent en réservant ; `color` et `icon` déterminent son apparence dans le calendrier ; `reducesWorkingTime` à false marque un temps libre qui ne réduit PAS les heures attendues du mois ; et `descriptionRequired` à true fait que le type exige une raison, que holidays_create impose ensuite — voir cet outil pour ce qu'il rejette. `status` vaut `active` par défaut, donc un type créé sans y réfléchir est offert immédiatement à tout le monde. LISEZ D'ABORD holidayTypes_list : les types sont à l'échelle de l'organisation, et IL N'Y A PAS DE SUPPRESSION — un doublon ou un name mal orthographié ne peut être que remasqué en mettant status à inactive avec holidayTypes_update, et il conserve entre-temps toutes les absences réservées à son nom. Nécessite ROLE_HOLIDAYS_MANAGER. Écriture.
holidayTypes_updateModifie un type de congé, et surtout LE RÉACTIVE. `status` bascule entre `active` et `inactive`, et un type inactive est refusé par holidays_create — donc enregistrer un congé historique sur un type que l'organisation a depuis retiré commence ici, et c'est ce qui débloque un import d'historique de congés plutôt que d'envoyer quelqu'un dans l'UI de l'application. DÉSACTIVER N'EST PAS SUPPRIMER, et il n'y a pas de suppression : les absences déjà réservées gardent un type inactive et se lisent toujours avec lui dans holidays_list, donc inactive signifie seulement « non proposé pour de nouvelles réservations ». LE PIÈGE QUI EN DÉCOULE : réactiver `vacations` pour charger les absences de l'an dernier, oublier de le remettre en `inactive`, et vous n'avez pas seulement terminé un import — vous avez changé ce que l'organisation offre aujourd'hui, car chaque employé réservant un congé revoit désormais ce type dans la liste. Remettez-le dans la même session que celle où vous avez importé. `descriptionRequired` agit aussi sur holidays_create, qui refuse une réservation sans description une fois activé ; l'activer laisse tranquilles les absences déjà enregistrées. `id` est l'id chaîne depuis holidayTypes_list (`vacations`, `not-paid`), et seuls les champs envoyés changent. Nécessite ROLE_HOLIDAYS_MANAGER. Écriture.

Factures entrantes

Outils

incomingInvoices_getRécupère une facture entrante (fournisseur) ou un justificatif par id, avec ses champs OCRisés et son état de rapprochement actuel.
incomingInvoices_listListe les factures entrantes (fournisseurs) et documents justificatifs — la boîte de réception comptable. Une facture entrante EST un document rattaché à une transaction bancaire, donc exists.transaction=false permet de trouver les documents pas encore rapprochés d'un paiement. Filtrez aussi par status, relatedMonth, counterparty, project, tags, ou hasDetectedProblems. Chaque document est identifié par une empreinte externalId 'upload_sha256:<sha256 des octets>' — hachez un fichier et recherchez cet externalId ici AVANT incomingInvoices_create, sinon vous créerez un doublon.
incomingInvoices_matchCandidatesListe les transactions bancaires susceptibles d'être le paiement de cette facture entrante, classées par le moteur de rapprochement du backend. Utilisez-le lorsqu'un document n'a pas de transaction associée et que vous devez en choisir une ; préférez ces candidats plutôt que de deviner vous-même à partir des montants.
incomingInvoices_suggestionsLit les propositions de Flowtly pour une facture entrante — correspondance fournisseur, groupe de coûts, transaction bancaire correspondante, avertissement de doublon. Ce sont exactement les propositions qu'un humain voit dans l'application. Lisez-les d'abord, puis appliquez-en une par id avec incomingInvoices_applySuggestion, ou acceptez-les toutes avec acceptAllSuggestions. Passez refresh pour recalculer plutôt que de servir l'ensemble mis en cache.
incomingInvoices_suggestionsDebugExplique POURQUOI les suggestions d'une facture entrante sont sorties telles quelles — le scoring du moteur de rapprochement, pour diagnostiquer une suggestion manquante ou erronée. Diagnostic uniquement ; utilisez incomingInvoices_suggestions pour le travail courant.
incomingInvoices_createClasse une facture entrante (fournisseur) ou un document justificatif dans la comptabilité — passez les octets en base64 avec un fileName et receivedAt. Flowtly l'analyse par OCR et suggère un fournisseur et une transaction bancaire correspondante. Le fichier est identifié par une empreinte externalId 'upload_sha256:<sha256 des octets>' : pour éviter un doublon, hachez les octets et vérifiez incomingInvoices_list pour cet externalId AVANT de charger le fichier. Écriture.
incomingInvoices_applySuggestionAccepte l'une des propositions de Flowtly sur une facture entrante — les mêmes propositions qu'un humain voit dans l'application (correspondance fournisseur, groupe de coûts, transaction bancaire correspondante, avertissement de doublon). Lisez-les d'abord avec incomingInvoices_suggestions, puis appliquez-en une par son id. Préférez ceci à une supposition : c'est le moteur de rapprochement de Flowtly, pas l'agent, qui décide de ce qui est plausible. Écriture.
incomingInvoices_acceptAllSuggestionsAccepte en un seul appel toutes les suggestions en attente sur une facture entrante — ce que fait un humain avec le bouton « tout accepter » de l'application. Le serveur applique, reconstruit, et applique à nouveau jusqu'à ce que plus rien de nouveau n'apparaisse : la correspondance de transaction n'existe PAS tant que le fournisseur et le montant n'ont pas été appliqués, donc une seule passe laisserait le document non rattaché. Renvoie un rapport (ce qui a été appliqué, ce qui a été refusé et pourquoi, et la transaction à laquelle le document a fini par être rattaché). Passez dryRun pour prévisualiser sans écrire. N'accepte jamais supplier_create ni une alerte de doublon. Écriture.
incomingInvoices_checkEInvoicesRécupère toute nouvelle e-facture KSeF dans l'organisation — ce que fait le bouton « Sprawdź e-faktury » de l'application. Appelez ceci avant de conclure qu'une facture fournisseur est manquante : sans cela, vous ne pouvez pas distinguer « le fournisseur ne l'a jamais envoyée » de « notre synchronisation n'a pas encore tourné ». Renvoie dès que la récupération est mise en file ; relisez ensuite incomingInvoices_list pour voir ce qui est arrivé. Écriture.

Postes de budget initial

Outils

initialBudgetItems_listListe les lignes d'un budget initial — les montants planifiés, par tag, sur lesquels s'appuie contractComparison. Nécessite ROLE_BUDGETS_VIEWER. Lecture seule.

Budgets initiaux

Outils

initialBudgets_contractComparisonPLANIFIÉ contre CONTRACTUALISÉ, par tag — les montants planifiés du budget initial face à la somme des valeurs de contrat réellement signées pour ce projet. C'est la question « avons-nous engagé plus que budgété, et où », et cela se lit directement à partir des contrats déjà dans l'organisation, donc importer des contrats rend la question répondable sans travail supplémentaire. Les montants sont en grosze ; un projet multi-devises produit un avertissement plutôt qu'un total silencieusement faux. Nécessite ROLE_BUDGETS_VIEWER. Lecture seule.
initialBudgets_getRécupère un budget initial par id, avec ses items. Nécessite ROLE_BUDGETS_VIEWER. Lecture seule.
initialBudgets_listListe les budgets initiaux — le plan D'ORIGINE d'un projet ou d'un investissement, par opposition au budget en cours par rapport auquel il est mesuré. Nécessite ROLE_BUDGETS_VIEWER. Lecture seule.

Factures

Outils

invoices_getRécupère une facture sortante (vente) par id — client, lignes, totaux, dates de vente et d'émission, statut.
invoices_listListe les factures sortantes (ventes). Filtrez par client, tags, search, ou une plage saleDate. Notez que saleDate — et non la date d'émission ni la date de création — est le champ sur lequel filtre invoices_export, utilisez donc le même ici lors du rapprochement d'un export.
invoices_exportDémarre un export zip des factures ÉMISES pour une période (from/to, toutes deux au format AAAA-MM-JJ, inclusives) filtrée sur la SALE DATE — et non la date d'émission ni la date de création. Seules les factures ÉMISES sont incluses ; les brouillons et factures non envoyées sont exclus, mais les corrections SONT incluses. Un client optionnel restreint à un seul client (id ou IRI depuis clients_list). Maximum 200 factures par export — si la période en contient plus, réduisez-la (par ex. exportez un mois à la fois) ; une période avec 0 facture émise est également rejetée. Cet appel ne fait que mettre le travail en file d'attente (le rendu d'un mois peut prendre plusieurs minutes) — il NE renvoie PAS de lien de téléchargement. Interrogez invoices_exportStatus avec l'exportId renvoyé jusqu'à ce qu'il indique « ready ». Écriture.
invoices_exportStatusInterroge le statut d'un export zip démarré par invoices_export, par exportId. Une fois le status à « ready », la réponse inclut downloadUrl (un lien signé de courte durée — expire au bout d'1 heure, voir expiresAt), filename, et byteSize ; les octets du fichier ne sont jamais renvoyés via cet outil. Si status est « failed », failureReason explique pourquoi.
invoices_importEnregistre une facture de vente sortante DÉJÀ ÉMISE dans l'organisation — pour importer un historique de factures lors d'un onboarding. Le numéro de facture externe que vous passez est préservé tel quel, l'acheteur est résolu par son numéro fiscal (créé s'il est absent), et la facture atterrit comme émise SANS rendre de PDF, sans envoyer d'e-mail au client, ni soumettre au KSeF. Importer un numéro déjà existant est un no-op qui rapporte la facture existante, donc un import en masse peut être relancé sans risque — mais cette garantie ne tient que pour des appels séquentiels ; deux imports vraiment concurrents du même numéro peuvent tous deux aboutir. Passez expectedGrossTotal (le montant brut imprimé sur le document source) et l'import est rejeté s'il diverge du total calculé à partir des lignes. buyer.tin est requis — l'acheteur n'est jamais rapproché par name. Utilisez invoices_create, pas celui-ci, pour émettre une vraie nouvelle facture. Écriture. Passez dryRun:true pour PRÉVISUALISER sans écrire — cela rapporte would-create / would-skip et ne crée ni facture ni client ; lancez d'abord un rattrapage historique à blanc et vérifiez les comptages avant de le lancer pour de vrai.
invoices_createÉmet une NOUVELLE facture de vente sortante — l'outil pour facturer un client pour la première fois. Ne le confondez pas avec ses deux voisins : invoices_import enregistre a posteriori une facture DÉJÀ émise ailleurs (historique d'onboarding), et incomingInvoices_create enregistre un document de COÛT d'un fournisseur. La facture atterrit NON ENVOYÉE : status est dérivé des lignes de journal de la facture et une facture toute neuve n'en a aucune, donc rien n'est rendu, envoyé par e-mail, ni soumis au KSeF par cet appel — traitez le résultat comme un brouillon à relire avant émission. `name` est le numéro de facture et c'est à vous de le choisir (32 caractères max) — lisez d'abord invoices_list et suivez la série existante de l'organisation plutôt que d'en inventer une, car rien ici ne vous alloue le numéro suivant. Requis : name, type ("invoice"), tinType, issueDate, saleDate, dueDate. Passez `client` (IRI depuis clients_list) et, pour un enregistrement qui se rapprochera plus tard, `contract` (IRI depuis contracts_list) afin que la facture apparaisse sous ce contrat. Les lignes vont dans `invoiceRows` — prix unitaire net, quantité et un taux de taxe par ligne ; les totaux sont calculés à partir des lignes, pas passés en entrée. LE TAUX D'UNE LIGNE TRANSFRONTALIÈRE EST UNE BASE LÉGALE, PAS UN NOMBRE : en plus des taux numériques, `vatRate` accepte `np I`, `np II` et `zw`, c'est une chaîne libre de 5 caractères, et rien ne valide celle que vous envoyez. `np I` et `np II` sont des bases légales DIFFÉRENTES et atterrissent dans des champs différents de la facture KSeF : `np II` est P_13_9, les services relevant de l'art. 100 ust. 1 pkt 4 de la loi polonaise sur la TVA (ceux également déclarés dans l'état récapitulatif VAT-UE) ; `np I` est P_13_8, toute autre livraison hors de Pologne. Savoir lequel des deux correspond à une livraison donnée est une décision fiscale : prenez-la auprès du comptable de l'organisation ou de la pratique confirmée de l'organisation pour ce type de client, et NE COPIEZ PAS LE TAUX DE N'IMPORTE QUELLE FACTURE `np` QUE L'ORGANISATION A DÉJÀ — un précédent peut lui-même être erroné. Le numéro fiscal de l'acheteur doit déjà être stocké SANS son préfixe de pays (clients_create explique pourquoi) — ce document imprime tinCountry accolé à tin, donc un client enregistré comme "RO40424862" s'imprime RORO40424862 ici. `bankAccount` (depuis bankAccounts_list) choisit le compte imprimé sur le document, et `currency` prend par défaut celle de l'organisation. Écriture.
invoices_updateCorrige une facture de vente sortante par id, avant ou après émission. L'usage courant est de corriger un brouillon émis par invoices_create — une date erronée, une ligne erronée, un lien de contrat manquant — plutôt que de le supprimer et de le réémettre, ce qui brûlerait un numéro de facture. Lisez d'abord invoices_get : c'est un PATCH sur un document dont les totaux sont dérivés de ses lignes, donc remplacer `invoiceRows` remplace l'ensemble complet, et une facture déjà envoyée ne se désenverra pas parce que vous l'avez modifiée. Écriture.

Activités de prospect

Outils

leadActivities_getRécupère une activité de prospect (contact de prospection) par id.
leadActivities_listListe les contacts de prospection d'un prospect — son fil d'activité (invitation envoyée, réponses, appels, relances). Filtrez par lead pour lire l'historique d'un prospect. C'est l'équivalent structuré de crmNotes_list : les activities forment le journal typé et daté des contacts ; les notes sont des commentaires libres.
leadActivities_createEnregistre UN contact de prospection sur un lead — une invitation envoyée, une invitation acceptée, un message, une réponse, un appel, une relance (lead + type + occurredAt requis ; channel, contact, body optionnels). C'EST ici que doit résider l'historique de prospection d'un prospect : une crmNote est un commentaire libre, une activity est le journal de contacts structuré et filtrable que rend la timeline de la file de prospection. NE racontez PAS les contacts dans une note. type : invite_sent | invite_accepted | message_sent | reply_received | call | meeting | follow_up | … ; channel : linkedin | email | phone | …. Écriture.
leadActivities_updateMet à jour une activité de prospection enregistrée par id (type, channel, occurredAt, body). Écriture.
leadActivities_deleteSupprime une activité de prospection enregistrée par id. Écriture.
leadActivities_byListToute lead activity sur UNE CAMPAGNE (une lead list), en un seul appel — passez l'id, l'IRI, ou le name exact de la liste. leadActivities_list filtre par un seul lead, donc un reporting au niveau campagne coûterait sinon un appel par membre (302 pour une liste comme PZFD) ; ceci résout les membres de la liste et lit leurs activités par lots bornés à la place. À combiner avec type et occurredAt.after/.before pour obtenir les comptages réellement demandés : taux de réponse (type=reply_received), taux de rebond (type=bounced), couverture d'envoi (type=message_sent). Retourne listId, listName, leadCount, et les activités fusionnées triées par occurredAt. Une liste inconnue est une ERREUR, pas un résultat vide — donc un name mal orthographié ne peut pas se lire comme « cette campagne n'a eu aucune activité ». Les ids proviennent de leadLists_list. Lecture seule.
leadActivities_bulkImportEnregistre toute une vague d'envois sortants — chaque message réellement envoyé — en UN SEUL appel, au lieu d'un leadActivities_create par message. Passez un tableau ; chaque ligne nomme son lead (leadCompanyName, rapproché d'un lead EXISTANT, ou une IRI de lead) plus type et occurredAt. Donnez à chaque ligne un externalId — l'id stable par message, par ex. l'id de message Gmail — et l'import devient idempotent : le relancer, ou relancer une vague qui n'avait été importée que partiellement, rapporte des doublons au lieu d'en créer. Les lignes sans externalId se dédupliquent sur (lead, type, occurredAt, contact), la même clé naturelle qu'utilise leads_bulkImport, donc une vague d'abord arrivée par cet outil n'est pas dupliquée ici. Chaque ligne obtient son propre résultat (created | duplicate | error), donc une ligne malformée ne fait pas rejeter le reste du lot. NE crée PAS de leads — utilisez leads_bulkImport pour cela. ≤ 1000 lignes/appel. Écriture.

Contacts de prospect

Outils

leadContacts_getRécupère un contact de prospect par id.
leadContacts_listListe les personnes de contact rattachées aux prospects. Filtrez par lead pour lire les contacts d'un prospect donné, ou par email pour retrouver de quel prospect provient un message.
leadContacts_createAjoute une personne de contact à un lead (lead + name requis ; email, phone, role, linkedinUrl, isPrimary optionnels). L'URL LinkedIn d'un contact doit être dans linkedinUrl, PAS dans une crmNote. Écriture.
leadContacts_updateMet à jour un contact de lead par id — par ex. définir linkedinUrl / email / phone une fois que vous les trouvez. Écriture.
leadContacts_deleteSupprime un contact de prospect par id. Écriture.

Appartenances aux listes de prospects

Outils

leadListMemberships_getRécupère une appartenance lead-liste (lead-to-list membership) par id. Ses status et lastContactedAt sont un instantané écrit par l'appelant, pas un état en temps réel — voir leadListMemberships_list.
leadListMemberships_listListe quels leads figurent sur quelles listes de prospection sortante. Filtre par list, lead ou status. ATTENTION : status et lastContactedAt sont un INSTANTANÉ écrit par la dernière personne ayant importé ou mis à jour l'appartenance. Ils ne sont pas dérivés, et rien ne les fait avancer quand une activité est enregistrée — journaliser une vague de 529 relances ne modifie aucun des deux champs — ils peuvent donc être arbitrairement en retard. Pour répondre à « quand avons-nous contacté ce prospect pour la dernière fois », lisez plutôt le journal d'activité : leadActivities_list pour un lead, leadActivities_byList pour toute une campagne. leadListMemberships_syncFromActivities signale l'écart et peut le combler.
leadListMemberships_createAjoute un lead à une liste sortante (list + lead requis ; status optionnel). Tout lastContactedAt que vous passez est un instantané que rien ne fera ensuite avancer — journalisez aussi le contact comme une lead activity, sinon il reste impossible à interroger. Écriture.
leadListMemberships_updateMet à jour l'appartenance d'un lead à une liste — par ex. définir le status de prospection (contacted/replied/bounced). status et lastContactedAt sont maintenus par l'appelant : ce que vous écrivez reste tel quel jusqu'à ce que quelqu'un écrive à nouveau, et enregistrer des lead activities ne les met PAS à jour. Écriture.
leadListMemberships_deleteRetire un prospect d'une liste de prospection sortante. Écriture.

Listes de prospects

Outils

leadLists_getRécupère une liste de prospection sortante par id.
leadLists_listListe les listes de prospection sortante. Utilisez-le pour résoudre l'id de liste attendu par leadListMemberships_create.
leadLists_createCrée une liste de prospection sortante (name requis). Écriture.
leadLists_updateMet à jour une liste de prospection sortante par id. Écriture.
leadLists_deleteSupprime une liste de prospection sortante par id. Écriture.

Motifs de perte de prospect

Outils

leadLostReasons_getRécupère un motif de perte de prospect par id.
leadLostReasons_listListe, dans l'ordre, les motifs pour lesquels un prospect peut être marqué comme perdu.

Prospects

Outils

leads_dedupeCheckVérifie si un prospect est déjà dans le CRM, en utilisant les mêmes filtres que leads_list (companyName, source, owner, …). Appelez ceci AVANT leads_create : un lead en doublon répartit l'historique de prospection entre deux enregistrements, et rien en aval ne les fusionnera pour vous.
leads_getRécupère un prospect par id — société, site web, source, statut, propriétaire et le client vers lequel il a été converti, le cas échéant.
leads_listListe les leads — cibles de prospection, avant qualification. Filtrez par status, source, owner, client, companyName, ou des plages createdAt/closedAt. Un lead qualifié devient un Client plus une Deal ouverte via leads_convert ; jusque-là, il n'existe que ici, pas dans clients_list.
leads_createCrée un lead (cible de prospection sortante/entrante ; companyName, source, owner, client lié optionnels). Un nouveau lead est toujours status=open — status n'est pas paramétrable ici, et ne change qu'au travers de leads_convert, leads_lose et leads_reopen. Écriture.
leads_updateMet à jour un lead par id (company, website, source, owner, client lié, stage, doNotContact). PAS status ni lostReason : ces champs sont refusés par l'entité et silencieusement ignorés par ce endpoint, donc clôturer un lead nécessite leads_lose (avec un lostReasonId) et l'annuler nécessite leads_reopen. Déplacer `stage` fait avancer dans l'entonnoir ; cela ne clôture pas le lead. Écriture.
leads_deleteSupprime un prospect par id (suppression douce). Écriture.
leads_convertConvertit un prospect qualifié en Client + un contact par contact de prospect + une Affaire ouverte. Nécessite un client existant (le client du prospect ou un clientId dans le corps de la requête). Écriture.
leads_loseClôture un lead comme PERDU — met status=lost et estampille closedAt. NÉCESSITE lostReasonId, l'`id` d'une entrée leadLostReasons (lancez d'abord leadLostReasons_list ; c'est une liste fermée, donc du texte libre est refusé avec une 422). C'est le SEUL moyen d'enregistrer un lead comme perdu : leads_update ignore status, et doNotContact signifie « ne plus jamais contacter », ce qui est une affirmation différente et bien plus forte que « nous n'avons pas gagné celui-ci ». Cela ne déplace PAS le stage du lead — LeadStage n'a pas de flag terminal, donc le lead conserve sa position dans l'entonnoir et leads_reopen peut la restaurer exactement. Écriture.
leads_reopenAnnule leads_lose — remet status à open et efface closedAt et la lost reason. Le stage n'est pas touché, donc le lead reprend exactement là où il en était. À utiliser quand un lead a été clôturé sur la mauvaise fiche ou que le prospect est revenu. Écriture.
leads_bulkImportImporte de nombreux leads en UN seul appel, chacun avec ses contacts, son appartenance à une liste et ses activités de prospection imbriqués — le serveur crée le lead puis propage son id dans les enfants, vous n'avez donc jamais à jongler avec des IRI intermédiaires. Idempotent par clés naturelles (companyName / email / (list,lead) / (type,occurredAt,contact)) : sûr à relancer et à découper en lots (≤100 leads/appel). C'est la voie en masse qu'un import de campagne devrait utiliser au lieu de N appels leads_create. Écriture.

Étapes de prospect

Outils

leadStages_getRécupère une étape de prospect par id.
leadStages_listListe les étapes que traverse un lead, dans l'ordre. Les leads ont leur propre ensemble d'étapes — les deals utilisent stages_list, qui est différent.

Emplacements

Outils

locations_getRécupère un location par id — son name et ses horaires de bureau (office hours). Lecture seule.
locations_listListe les locations de l'organisation — les lieux physiques où se trouvent les actifs, affichés dans l'UI comme Lokalizacja. Nécessite ROLE_LOCATIONS_MANAGER, qui protège de façon inhabituelle la LECTURE autant que l'écriture. Lecture seule.
locations_createCrée un location (name requis ; officeOpenHour/officeCloseHour optionnels, en secondes après minuit). Utilisez l'adresse réelle plutôt qu'un nom de projet ou d'investissement — c'est ce dont a besoin quelqu'un qui se trouve devant l'actif, et le nom du projet est déjà porté ailleurs. Nécessite ROLE_LOCATIONS_MANAGER. Écriture.
locations_updateRenomme un location ou change ses horaires de bureau. Nécessite ROLE_LOCATIONS_MANAGER. Écriture.

Adresses de l'organisation

Outils

organizationAddresses_getRécupère un enregistrement d'adresse d'abonnement (subscription address) par id — name, street, city, postCode, country, et les champs fiscaux. `street` porte le numéro du bâtiment quand il a été saisi à la main, et ne le porte pas quand il provient de la recherche NIP/GUS. Lecture seule.
organizationAddresses_listListe les enregistrements d'adresse d'abonnement de l'organisation — l'adresse rattachée à l'abonnement Flowtly, et la source à partir de laquelle le pied de mail {{organizationAddress}} est rendu. Normalement exactement une ligne. Ce N'EST PAS l'adresse du vendeur sur les factures, qui vit dans les clés de config organization-billing-* (configs_get) et que lisent les factures et le KSeF ; les deux sont maintenues séparément et divergent régulièrement. Lisez les deux avant de conclure laquelle un client a réellement modifiée.
organizationAddresses_updateMet à jour l'enregistrement d'adresse d'ABONNEMENT de l'organisation (id requis ; n'envoyez que les champs que vous modifiez). C'EST L'ENREGISTREMENT À PARTIR DUQUEL LE PIED DE MAIL EST RENDU : le {{organizationAddress}} du footer est composé comme « street, postCode city » à partir d'ici, PAS à partir des clés de config organization-billing-* qu'utilisent les factures et le KSeF comme adresse du vendeur. Les deux stockages divergent, et le fait que le footer lise celui-ci est un défaut connu — donc quand une signature affiche une adresse que le client jure avoir corrigée, il a corrigé les clés billing et c'est cet enregistrement qui détient encore l'ancienne valeur. `street` est une seule colonne en texte libre qui doit aussi porter le numéro du bâtiment : la recherche NIP/GUS ne remplit que le nom de la rue et abandonne silencieusement le numéro de bâtiment et d'appartement, ce qui explique pourquoi les adresses ici se lisent « ul. Example » sans numéro. Écrivez le "ul. Example 8/12" complet pour la réparer. LISEZ D'ABORD avec organizationAddresses_list et comparez avec configs_get sur organization-billing-street avant d'écrire, afin de recopier la valeur réellement maintenue par le client plutôt que d'en inventer une. Nécessite ROLE_BILLINGS_MANAGER. Écriture.

Pied de page des e-mails de l'organisation

Outils

organizationMailFooter_getLit le texte de pied de page des e-mails sortants de l'organisation (le bloc ajouté aux e-mails que Flowtly envoie au nom de l'organisation).
organizationMailFooter_updateMet à jour le texte de pied de page des e-mails sortants de l'organisation. Écriture.

Organisations

Outils

organizations_getRécupère une organisation par id. ATTENTION — cela ne vous indique PAS à quelle organisation vous êtes connecté. Une connexion OAuth est liée à exactement une org (liée au token), mais ce endpoint renvoie n'importe quelle org dont l'UTILISATEUR connecté est membre, donc une lecture réussie ici peut donner l'impression de confirmer que vous travaillez dans cette org alors que ce n'est peut-être pas le cas. Pour vérifier le tenant sur lequel vous opérez réellement, lisez plutôt des données scopées au tenant — people_list ou clients_list — et ne lancez jamais une écriture en masse sur la seule foi de cet appel.

Personnes

Outils

people_getRécupère une fiche personne/employé par id — noms, e-mails, téléphone, manager, et si la personne est active.
people_listListe les personnes/employés. Filtrez par isActive, reportsTo (l'id d'un manager), projectMembers.project, ou search ; paginez avec cursor. Les personnes et les employés partagent le même id, c'est donc ainsi que vous résolvez l'id employé attendu par les temps de travail, les responsabilités, l'appartenance aux projets et les outils de permissions.
people_createCrée une fiche personne/employé (firstname + lastname requis ; companyEmail, contactEmail, contactPhone optionnels). Écriture.
people_updateMet à jour une fiche personne/employé par id (name, companyEmail, contactEmail, contactPhone, etc.). Écriture.
people_deleteSupprime une fiche employé/personne par id (par ex. pour retirer un employé factice/placeholder). Nécessite ROLE_EMPLOYEES_MANAGER ; le backend exécute un processeur de suppression qui détache aussi les enregistrements liés. Fort impact, irréversible. Écriture.
people_inviteDonne à une personne existante un LOGIN : crée une invitation d'organisation en attente et la lui envoie par e-mail, dans la langue d'UI configurée pour l'organisation. C'est l'étape que people_create et people_setPermissionGroups NE font PAS — une personne avec des groupes de permission ne peut toujours pas se connecter tant qu'elle n'a pas été invitée et n'a pas accepté. Nécessite l'e-mail de la personne ; échoue si elle a déjà un login. Ordre d'onboarding : people_create (fiche) -> people_invite (login) -> people_setPermissionGroups (droits). Écriture.
people_setPermissionGroupsDéfinit (remplace) l'ENSEMBLE COMPLET des groupes de permission d'une personne par des ids numériques de groupe (voir permissionGroups_list — par ex. le groupe « Business Owner » accorde ROLE_ADMIN) : passez tous les groupes qu'elle doit détenir au final, et [] les retire tous. Accorde l'accès ; ne crée PAS de login et n'envoie PAS d'e-mail à la personne — c'est people_invite. LE PIÈGE : donner à quelqu'un son PREMIER groupe le fait basculer sur le modèle calculé, où les roles proviennent des groups et des overrides par personne, et un role accordé à la main en dehors de ce modèle disparaît dans ce même appel — un ROLE_ADMIN donné à une personne à la main est exactement le genre de role que ceci supprime. Cela joue aussi dans l'autre sens : vider son dernier groupe la fait sortir de ce modèle et fait réapparaître ces anciens roles. Les listes overridesAdded/overridesRemoved ne disent rien de tout cela ; elles décrivent les overrides et restent vides pendant que l'accès effectif change. La réponse rapporte donc la différence entre les roles que la personne détenait avant cet appel et après, sous la forme rolesLost et rolesGained — c'est cette paire qu'il faut lire une fois l'appel revenu. rolesLost à null (pas []) signifie que l'instantané pris avant l'écriture n'a pas pu être lu et que le delta est INCONNU, la raison étant dans roleDeltaUnavailable : le changement de groupes a tout de même eu lieu, donc un null n'est pas un certificat de bonne santé — revérifiez avec people_getPermissions. Pour rendre un role qui aurait dû survivre, accordez-le avec people_setRoleOverrides. Nécessite ROLE_ROLES_MANAGER. Écriture.
people_setRoleOverridesDéfinit (remplace) les roles qu'UNE personne obtient en plus — ou se voit retirer — par rapport à ses groupes de permission. Privilégiez d'abord un groupe (people_setPermissionGroups) : les groups sont l'abstraction voulue et passent à l'échelle pour plus d'une personne, donc n'utilisez un override que lorsqu'un individu diffère réellement de tous les groupes. REMPLACE les deux listes en bloc, donc lisez d'abord people_getPermissions et renvoyez tous les overrides à conserver ; omettre une liste la vide. Les roles sont des constantes ROLE_ — permissionGroups_list montre celles déjà utilisées par cette organisation. Un role présent à la fois dans added et removed est refusé plutôt que deviné. Retourne le même instantané résolu que people_getPermissions, ce qui permet de confirmer le résultat sans second appel. Ne crée PAS de login — voir people_invite. Nécessite ROLE_ROLES_MANAGER. Écriture.
people_getPermissionsCe qu'une personne peut réellement faire, résolu : ses groupes de permission (chacun avec les roles qu'il accorde), ses overrides propres à la personne, et les effectiveRoles que les deux combinent. LE moyen de vérifier si un changement d'accès a bien pris effet — people_list montre un champ roles, mais c'est ici que l'on explique POURQUOI elle détient ces roles et quel levier actionner pour le changer. À consulter avant chaque appel à people_setRoleOverrides, car cet outil remplace les listes d'overrides en bloc et c'est ici que l'on lit les listes actuelles. staleOverrides sont des overrides supprimés qui ne correspondent plus à aucun role accordé par un groupe, donc ils ne font actuellement rien. people_list fournit l'id. Nécessite ROLE_ROLES_MANAGER pour consulter quelqu'un d'autre que soi-même. Lecture seule.

Groupes de permissions

Outils

permissionGroups_getRécupère un groupe de permissions par id, y compris les chaînes ROLE_* qu'il accorde.
permissionGroups_listListe les groupes de permissions de l'organisation et les rôles que chacun accorde — par ex. le groupe « Business Owner » accorde ROLE_ADMIN. Lisez ceci avant people_setPermissionGroups : les rôles dans la réponse font autorité sur ce qu'un groupe permet réellement, vous n'avez donc jamais à deviner à partir de son nom.
permissionGroups_createCrée un groupe de permissions (name requis ; roles = liste des chaînes ROLE_* qu'il accorde). Écriture.
permissionGroups_updateMet à jour le nom, la description ou les rôles accordés d'un groupe de permissions par id. Écriture.

Pipelines

Outils

pipelines_getRécupère un pipeline commercial par id.
pipelines_listListe les pipelines de vente. Un pipeline possède un ensemble ordonné d'étapes — lisez-les avec stages_list filtré par pipeline.

Postes

Outils

positions_listListe les positions — les rôles nommés (par ex. « Backend Engineer ») qu'une allocation de projet pourvoit. Aucun filtre ; Position a la pagination désactivée, cet appel renvoie donc toujours le catalogue complet des rôles de l'organisation en un seul appel. Chaque élément est {id, name, roles}. Utilisez-le pour résoudre le nom du poste derrière le positionId d'une ligne d'allocations_list, et pour trouver l'id de poste qu'un import de resourcing doit faire correspondre.

Membres du projet

Outils

projectMembers_getRécupère une appartenance de projet (project membership) par id — son employee, project et position. Les ids proviennent de projectMembers_list ou du tableau projectMembers sur projects_get.
projectMembers_listListe les appartenances de projet — QUI PEUT VOIR QUEL PROJET. Filtrer par project (`/projects/{id}`) pour lire l'effectif d'un projet, ou par employee pour lire tous les projets qu'une personne peut atteindre ; chaque ligne porte son propre id, l'employee, le project et la position (employee|tech-lead|account-manager|viewer). À consulter en premier lorsque quelqu'un signale un projet manquant dans sa liste Projects ou qu'il ne peut pas y enregistrer de temps : un effectif vide, ou un effectif où cette personne ne figure pas, EST l'explication — la visibilité, c'est l'appartenance. C'est aussi la source d'id pour projectMembers_update et projectMembers_delete. Notez que la même personne peut apparaître plusieurs fois sur un même projet, une fois par position.
projectMembers_createAjoute une personne SUR un projet (IRIs employee + project requises, par ex. "/people/204" et "/projects/243" ; position optionnelle = employee|tech-lead|account-manager|viewer, employee par défaut). C'EST LE CONTRÔLE D'ACCÈS, pas une étiquette : une personne qui n'est pas membre ne voit pas du tout le projet — il manque dans sa liste Projects et elle ne peut pas y enregistrer de temps — c'est donc l'outil qui restaure quelqu'un exclu d'un projet. LA POSITION N'EST PAS COSMÉTIQUE : un utilisateur détenant un role à portée projet ne voit que les projets où sa position d'appartenance y correspond — ROLE_PROJECTS_LEAD correspond à tech-lead, ROLE_PROJECTS_VIEWER correspond à viewer — donc donner à un chef de projet une ligne `employee` le laisse tout aussi aveugle que l'absence totale de ligne. L'appartenance ne se propage PAS en cascade : mettre quelqu'un sur un dossier parent ne lui donne rien sur les projets en dessous, donc une arborescence de dossiers a besoin d'un appel par projet. La clé unique est (employee, project, position), ce qui signifie que les positions s'empilent plutôt qu'elles ne se remplacent — une personne peut détenir employee ET tech-lead sur le même projet comme deux lignes distinctes, et ajouter tech-lead à quelqu'un qui est déjà employee dessus ne retire ni ne met à niveau la ligne employee (utilisez projectMembers_update pour changer une position sur place). Lisez d'abord les lignes actuelles avec projectMembers_list?project=/projects/{id}, ou projects_get, dont le tableau projectMembers porte l'id de chaque ligne. VOUS CHARGEZ UNE ÉQUIPE ENTIÈRE ? Une forme en masse existe — projectMembers_import réconcilie jusqu'à 500 appartenances en un seul appel, ignore celles déjà enregistrées, donc peut être relancé sans risque, et désactive la notification par défaut — mais ELLE N'EST PAS DISPONIBLE SUR CETTE CONNEXION : elle n'est servie qu'au scope interne, vous ne pouvez donc pas l'appeler ici et la chercher ne la trouvera pas. Appelez cet outil en boucle, ou demandez à votre opérateur Flowtly d'effectuer le chargement en masse. PAS SILENCIEUX : ajouter une personne qui n'est pas encore sur le projet lui envoie une notification project-assigned, donc un backfill de 17 projets envoie 17 notifications. Nécessite ROLE_PROJECTS_MANAGER. Écriture.
projectMembers_updateModifie la position d'une appartenance existante par id (employee|tech-lead|account-manager|viewer) — obtenez l'id depuis projectMembers_list ou le tableau projectMembers sur projects_get. À utiliser pour promouvoir ou rétrograder SUR PLACE ; utilisez projectMembers_create pour ajouter une seconde position, en plus de celle déjà détenue. Changer une position peut RÉVOQUER la visibilité du projet pour quelqu'un dont le role est à portée projet (un ROLE_PROJECTS_LEAD rétrogradé de tech-lead à employee cesse de le voir). Impossible de déplacer une appartenance vers une autre personne ou un autre projet — supprimez et recréez pour cela. Nécessite ROLE_PROJECTS_MANAGER. Écriture.
projectMembers_deleteRetire une personne D'UN projet par id d'appartenance — trouvez-le avec projectMembers_list ou dans le tableau projectMembers de projects_get. CECI RÉVOQUE L'ACCÈS : une fois que la dernière ligne d'appartenance de cette personne sur ce projet a disparu, le projet disparaît de sa vue et elle ne peut plus y enregistrer de temps, ce qui est exactement la façon dont un projet disparaît silencieusement pour quelqu'un. Les heures déjà enregistrées ne sont PAS supprimées et restent sur le projet ; la personne ne peut simplement plus les voir ni en ajouter. Supprimer une position laisse intacte toute autre position que la même personne détient sur le même projet. Nécessite ROLE_PROJECTS_MANAGER. Irréversible (recréer fait une nouvelle ligne et renotifie), fort impact. Écriture.

Projets

Outils

projects_costAllocationsComment les coûts ont été répartis SUR ce projet — quelles transactions et lignes de facture lui ont été attribuées, et dans quelle proportion. À utiliser pour expliquer un chiffre de rentabilité plutôt que de simplement le citer : c'est ici qu'un résultat inattendu est retracé jusqu'au document qui en est la cause. Nécessite ROLE_TRANSACTIONS_MANAGER. Lecture seule.
projects_folderCountsCombien de projets se trouvent dans chaque DOSSIER de projets, sous la forme folderId + total + active. Le folderId est un id de tagDefinition — résolvez les noms avec tagDefinitions_list, et repérez les groupes de dossiers avec tagGroups_list (allowedRelations contient "project"). Un folderId nul correspond au lot non catégorisé. Ne compte que les projets racines, car les dossiers regroupent les racines et les phases suivent leur parent. Lecture seule.
projects_getRécupère un projet par id — nom, type, client, dates, description et prix.
projects_listListe les projets. Filtrez par type (fixed-price | time-and-material | non-billable | internal), client.name, employee, name, ou par plages dateFrom/dateTo. Utilisez-le pour résoudre l'id projet attendu par les tâches, la saisie de temps, les budgets et les contrats.
projects_profitabilityLE RÉSULTAT PAR PROJET — ce qu'un projet a rapporté par rapport à ce qu'il a coûté. C'est le chiffre qu'une activité de services ou de développement cherche habituellement à voir, et celui que nourrit tout autre outil de projet. Passez l'id de projet depuis projects_list. Nécessite ROLE_ACCOUNT_MANAGER. Lecture seule.
projects_createCrée un projet (name + type requis ; type = fixed-price|time-and-material|non-billable|internal ; dateFrom/dateTo, client, publicDescription, notes, priceNet optionnels). Écriture.
projects_updateMet à jour un projet par id (name, type, dates, description, etc.). Écriture.
projects_archiveArchive un projet par son id — la façon de retirer un projet qui ne peut pas être supprimé parce que du temps saisi, des factures ou des budgets y sont rattachés. Réversible avec projects_unarchive. Préférable à une antidatation de dateTo, qui ne fait que donner au projet l'apparence d'être terminé. Écriture.
projects_unarchiveRestaure un projet archivé par son id, annulant projects_archive. Écriture.

Modèles de projet

Outils

projectTemplates_getRécupère un modèle de projet (project template) par id, y compris son document structure complet. projectTemplates_list permet de trouver l'id. À lire avant projectTemplates_update — la structure est écrite EN ENTIER, donc une mise à jour doit envoyer le document complet, pas un fragment. Lecture seule.
projectTemplates_listListe les modèles de projet de l'organisation — des plans réutilisables d'un projet, ses phases, ses listes de tâches et ses tâches. À consulter AVANT projects_create quand le même type de projet est mis en place de façon répétée (un type de mission, un audit, un onboarding) : instancier un modèle construit tout l'arbre en un seul appel, là où projects_create crée un projet vide qu'il faut ensuite remplir à la main. La ligne marquée isDefault est le modèle intégré de l'organisation, appliqué à un projet créé sans modèle choisi. Lecture seule.
projectTemplates_createCrée un plan de projet réutilisable (project template) à partir d'un document structure (version, project, phases, et leurs lists/tasks). Les décalages qu'il contient sont RELATIFS — startOffsetDays et durationDays sont comptés en jours depuis le startDate donné au moment de l'instanciation, donc un même template sert à tout démarrage futur. Le project.name dans la structure est un placeholder ; à surcharger par client au moment de l'instanciation. La structure est validée côté serveur par rapport au schéma de sa version déclarée, et une violation nomme le JSON pointer fautif. Écriture.
projectTemplates_updateMet à jour un modèle de projet (project template) par id. La colonne structure est stockée et remplacée EN ENTIER, jamais fusionnée — envoyez le document complet, sinon les parties omises disparaissent. Lisez d'abord la version actuelle avec projectTemplates_get. Modifier un template ne touche PAS les projets déjà instanciés à partir de lui ; il n'y a pas de rétropropagation. Écriture.
projectTemplates_deleteSupprime un modèle de projet (project template) par id. Suppression douce (soft delete), et cela ne touche PAS les projets déjà créés à partir du template — ce sont des projets ordinaires qui continuent d'exister. Écriture.
projectTemplates_instantiateConstruit un vrai projet à partir d'un template — le project, ses phases, ses task lists et chaque task, en UN SEUL appel atomique. startDate est requis et sert d'ancrage auquel se résout chaque startOffsetDays du template. Passez name pour surcharger le project name placeholder du template, et client pour rattacher le nouveau projet à un client : instancier deux fois pour LE MÊME client est ainsi qu'un client finit par détenir plusieurs missions, chacune son propre projet. Retourne le projet créé. Écriture.

Candidats pour les demandes de ressource

Outils

resourceRequestCandidates_getUn candidat au recrutement par id. L'id provient de resourceRequestCandidates_list. Nécessite ROLE_HR_MANAGER. Lecture seule.
resourceRequestCandidates_listLes candidats proposés pour des demandes de recrutement — des personnes dans un pipeline de recrutement, pas des employés disponibles pour allocation. Filtrez par l'id de demande issu de resourceRequests_list. Nécessite ROLE_HR_MANAGER. Lecture seule.

Demandes de ressource

Outils

resourceRequests_getUne demande de recrutement par id, avec son poste et son statut. Récupérez l'id depuis resourceRequests_list. RH/recrutement, pas allocation de resourcing. Nécessite ROLE_HR_MANAGER. Lecture seule.
resourceRequests_listDemandes de recrutement ouvertes — une demande de recrutement pour un poste, dans le domaine RH. Malgré son nom, ce n'est PAS une demande d'allocation de resourcing : c'est du recrutement. Renvoie la collection ; resourceRequests_get en lit une, et resourceRequestCandidates_list donne les personnes proposées pour elle. Nécessite ROLE_HR_MANAGER. Lecture seule.

Demandes de planification des ressources

Outils

resourcingRequests_listDemandes de resourcing ouvertes — quelqu'un demandant qu'une personne soit allouée à un projet, le côté demande du resourcing. C'est le flux que rend la vue Requests de l'interface Resourcing. Ne le confondez PAS avec resourceRequests_list : celui-ci concerne le RECRUTEMENT RH (embauche pour un poste). Associez-le à resourcingRequestsHistory_list pour ce qui a déjà été décidé, et à resourcingBench_get pour savoir qui pourrait satisfaire une demande. Nécessite le module resourcing et ROLE_RESOURCING_MANAGER. Lecture seule.

Historique des demandes de planification

Outils

resourcingRequestsHistory_listCe qui est déjà arrivé aux demandes de resourcing — l'historique des décisions (confirmée, refusée, modifiée) derrière les demandes ouvertes dans resourcingRequests_list. Utilisez-le pour répondre à « cela a-t-il déjà été demandé et refusé ? » avant de proposer à nouveau la même allocation. Nécessite le module resourcing et ROLE_RESOURCING_MANAGER. Lecture seule.

Responsabilités

Outils

responsibilities_getRécupère une responsabilité par id.
responsibilities_listListe les responsabilités au sein d'un groupe RACI. Filtrez par responsibilityGroup. Les responsabilités peuvent s'imbriquer via parent ; les personnes y sont affectées via responsibilityEmployees, pas directement.
responsibilities_createCrée une responsabilité à l'intérieur d'un groupe (responsibilityGroup = id ou IRI du groupe, + name, requis ; description optionnelle ; parent optionnel = un autre IRI de responsabilité pour l'imbrication). Assignez-y des personnes via responsibilityEmployees_create. Écriture.
responsibilities_updateMet à jour une responsabilité par id (name, description, parent, responsibilityGroup = id de groupe ou IRI). Écriture.

Employés responsables

Outils

responsibilityEmployees_getRécupère une affectation de responsabilité par id.
responsibilityEmployees_listListe qui est affecté à quelle responsabilité, et à quel pourcentage. Filtrez par employee pour lire toute la charge RACI d'une personne à travers tous les groupes.
responsibilityEmployees_createAffecte un employé à une responsabilité (responsibility = id de responsabilité ou IRI, employee = id employé ou IRI, percentage 0-100, tous requis ; targets et description optionnels). Écriture.
responsibilityEmployees_updateMet à jour une affectation de responsabilité par id (percentage, targets, description). Écriture.
responsibilityEmployees_deleteRetire l'affectation d'un employé à une responsabilité par id. Écriture.

Groupes de responsabilité

Outils

responsibilityGroups_getRécupère un groupe de responsabilité par id.
responsibilityGroups_listListe les groupes de responsabilité / domaines RACI — les éléments de premier niveau « Odpowiedzialności », chacun avec une personne responsable (accountable). Les responsabilités individuelles se rattachent en dessous.
responsibilityGroups_createCrée un groupe de responsabilités / zone RACI (name requis ; description optionnelle et responsibleEmployee = la personne responsable, indiquée comme un simple id d'employé tel que 6 (depuis people_list) ou l'IRI /people/6). C'est l'élément de plus haut niveau « Odpowiedzialności ». Ajoutez des responsabilités individuelles sous celui-ci via responsibilities_create. Écriture.
responsibilityGroups_updateMet à jour un groupe de responsabilité par id (name, description, responsibleEmployee = id employé ou IRI). Écriture.

Employés du planning

Outils

scheduleEmployees_getUne affectation planning-employé par id. L'id provient de scheduleEmployees_list. Nécessite ROLE_SCHEDULES_MANAGER. Lecture seule.
scheduleEmployees_listQuels employés sont affectés à quels horaires de travail. Utilisez-le pour aller d'un horaire (schedules_list) à ses employés, ou pour trouver l'horaire que suit un employé donné. Nécessite ROLE_SCHEDULES_MANAGER. Lecture seule.

Plan du planning

Outils

schedulePlan_listLes horaires en vigueur à UNE date donnée — passez la date dans le chemin. Utilisez-le pour répondre à « qui travaille aujourd'hui / à cette date » sans lire tous les horaires et résoudre vous-même leurs plages. Contrairement aux autres lectures d'horaires, celui-ci ne nécessite que ROLE_USER, c'est donc celui accessible à un employé ordinaire. Lecture seule.

Plages du planning

Outils

scheduleRanges_getUne plage horaire d'un planning par id. L'id provient de scheduleRanges_list. Nécessite ROLE_SCHEDULES_MANAGER. Lecture seule.
scheduleRanges_listLes plages horaires qui composent les horaires de travail — les heures réelles couvertes par un horaire. Lisez d'abord le parent avec schedules_get ; ceci développe ses plages. Nécessite ROLE_SCHEDULES_MANAGER. Lecture seule.

Plannings

Outils

schedules_getUn horaire de travail par id, avec ses plages et ses employés affectés. L'id provient de schedules_list ; scheduleRanges_list et scheduleEmployees_list en lisent les parties. Nécessite ROLE_SCHEDULES_MANAGER. Lecture seule.
schedules_listHoraires de travail — les modèles de poste/horaire qu'une organisation définit, PAS l'allocation de projet. Utilisez resourcingSchedule_get pour savoir qui est réservé sur quoi ; utilisez celui-ci pour les modèles horaires eux-mêmes. schedules_get en lit un par id. Nécessite ROLE_SCHEDULES_MANAGER. Lecture seule.

Étapes

Outils

stages_getRécupère une étape d'affaire par id.
stages_listListe les étapes des affaires, dans l'ordre. Filtrez par pipeline. deals_create requiert un id d'étape issu d'ici, et déplacer une affaire entre étapes est ce qu'enregistre dealStageHistories.

Fournisseurs

Outils

suppliers_listListe les fournisseurs/prestataires — servis depuis /contractors, donc « supplier » et « contractor » désignent le même enregistrement. Filtrez par cyclic pour les fournisseurs récurrents. Utilisez-le pour résoudre le fournisseur auquel un coût, un contrat ou une facture entrante est rattaché.
suppliers_createCrée une nouvelle fiche fournisseur/prestataire (name, tinType, costGroup requis). Écriture.
suppliers_updateMet à jour les détails d'un fournisseur/prestataire (nom, identifiant fiscal, conditions de paiement, etc.) par id. Écriture.

Définitions de tags

Outils

tagDefinitions_listListe les définitions de tags — les tags pouvant être attachés à des enregistrements, chacun à l'intérieur d'un groupe de tags. tags_create prend un id de tagDefinition issu d'ici plus l'enregistrement auquel l'attacher.
tagDefinitions_createCrée une définition d'étiquette (name, level, tagGroup requis) au sein d'un groupe d'étiquettes. Lorsque allowedRelations du groupe contient "project", chaque définition ici EST un dossier de projets — c'est l'outil qui en crée un. Écriture.

Groupes de tags

Outils

tagGroups_listListe les groupes de tags — les conteneurs qui organisent les définitions de tags.
tagGroups_createCrée un groupe d'étiquettes (nom requis) pour organiser des définitions d'étiquettes liées. C'est aussi ainsi que l'on crée un conteneur de DOSSIER DE PROJETS : passez allowedRelations : ["project"] et les définitions du groupe deviennent des dossiers dans la liste des projets. Un groupe dont allowedRelations est vide est universel et n'est PAS traité comme un dossier. Écriture.

Commentaires de tâche

Outils

taskComments_listListe les commentaires sur les tâches de projet, du plus ancien au plus récent. Filtrez par task pour lire la discussion d'une tâche.
taskComments_createAjoute un commentaire à une tâche de projet (id de task + content). Écriture.

Listes de tâches

Outils

taskLists_listListe les listes de tâches — les colonnes/sections du tableau dans lesquelles les tâches sont classées. Filtrez par projet. tasks_create prend un id de liste issu d'ici.

Tâches

Outils

tasks_getRécupère une tâche de projet par id — titre, projet, statut, liste, assignés, dates et récurrence.
tasks_listListe les tâches de projet. Filtrez par project, list, status, assignees, isTemplate, ou des plages startAt/dueAt. Les tâches récurrentes exposent recurrenceParent et recurrenceRule, de sorte qu'une occurrence générée peut être retracée jusqu'à la règle qui l'a produite. Pour déterminer si une tâche est TERMINÉE, comparez son status à taskStatuses_list (isClosed) plutôt que de comparer le nom du statut.
tasks_createCrée une tâche de projet (title + project requis ; status, list, assignees, dueAt, priority optionnels). Écriture.
tasks_updateMet à jour une tâche de projet par id — change status (y compris la marquer terminée), assignees, dueAt, title, etc., ou DÉPLACE la tâche vers un autre projet en passant `project` (reparentage ; la task list est effacée sauf si vous nommez aussi une `list` dans le projet cible, car une list appartient à un seul projet). Écriture.

Statuts de tâche

Outils

taskStatuses_listListe les statuts de tâche de projet, dans l'ordre du tableau. isClosed marque les états terminés et isDefault le statut qu'obtient une nouvelle tâche. Consultez ceci avant d'interpréter le statut d'une tâche — les noms sont configurables par l'organisation, donc « Done » n'est pas une chaîne fiable pour faire une correspondance.

Groupes de taxes

Outils

taxGroups_listListe les groupes de taxes. Utilisez-le pour résoudre l'id taxGroup sur lequel filtre taxRules_list et que portent les lignes de facture.
taxGroups_createCrée un groupe de taxes (name + type requis). Écriture.
taxGroups_updateMet à jour le nom ou le type d'un groupe de taxes par id. Écriture.

Règles de taxe

Outils

taxRules_listListe les règles de taxe — les taux et les périodes auxquelles ils s'appliquent. Filtrez par taxGroup.
taxRules_createCrée une règle de taxe. Écriture.
taxRules_updateMet à jour une règle de taxe par id. Écriture.

Transactions

Outils

transactions_listListe les transactions bancaires — le flux bancaire auquel les factures entrantes sont rapprochées. Filtrez par bankAccount, counterpartyRole, cost, ignored, hasDetectedProblems, une plage orderDate/execDate, ou amount.between. Notez que orderDate et execDate sont différents : un paiement peut être ordonné un mois et s'exécuter le mois suivant.
transactions_suggestionsLit les propositions de Flowtly pour une transaction bancaire — à quelle contrepartie, groupe de coûts ou document elle devrait être rattachée. L'équivalent en miroir de incomingInvoices_suggestions, côté trésorerie.
transactions_importStatementImporte un fichier de relevé bancaire (par ex. un fichier MT940 .sta) — passez le contenu texte brut de chaque fichier tel quel (PAS en base64) avec un filename. IL N'Y A PAS de PARAMÈTRE bankAccount : le backend achemine un fichier en supprimant tous les caractères non numériques des numéros de vos comptes bancaires et des octets du fichier, puis importe dans chaque compte dont les chiffres apparaissent n'importe où dans le fichier — un seul fichier peut donc atterrir dans plusieurs comptes, et un relevé pour un compte non configuré dans Flowtly (ou dont le numéro est enregistré différemment de la façon dont la banque l'écrit) n'est importé dans aucun d'eux, échouant avec une erreur qui explique exactement pourquoi — lisez ce message, c'est le seul diagnostic que fournit ce endpoint. En cas de succès, la réponse est `{ imported, matching }` : `matching: "in_progress"` signifie que le rapprochement contrepartie/pièce jointe pour les nouvelles lignes est encore en cours après le retour de cet appel, un transactions_list immédiat peut donc montrer des lignes pas encore rapprochées — relisez un peu plus tard pour l'état final. Réimporter le même relevé ne crée pas de lignes en double ; l'importeur reconnaît les transactions déjà vues. Une fois un relevé importé, rattachez un paiement existant sans ligne bancaire à l'une de ses lignes avec invoiceTransactions_update. Écriture.
transactions_deleteSupprime une transaction bancaire par son id — trouvez-la avec transactions_list. N'y recourez QUE pour annuler une erreur comptable impossible à corriger autrement : un relevé importé sur le mauvais compte bancaire, ou des lignes saisies à la main avant l'arrivée du vrai relevé et désormais dupliquées par celui-ci. Une transaction est l'enregistrement de ce qu'a fait la banque : en supprimer une sur un compte importé fait diverger le grand livre de la banque ; le backend ne l'autorise qu'à ROLE_ADMIN (un gestionnaire des transactions ne peut supprimer que sur les comptes de caisse et manuels). AVANT de supprimer un doublon présumé, prouvez la paire : rapprochez la ligne importée sur le montant ET le numéro de facture ET le tiers, pas sur le montant seul — un paiement arrivé après la date de fin du relevé n'a pas de contrepartie, et le supprimer détruit la seule trace de cette recette. Le backend DÉTACHE au lieu de supprimer ce qui en dépend : les paiements de factures subsistent, leur ligne bancaire effacée (repointez-les avec invoiceTransactions_update), les pièces jointes et les biens sont dissociés, tandis que les lignes de transaction de projet et de salarié sont supprimées avec elle. Irréversible, à fort impact. Écriture.

Temps de travail

Outils

workTimes_getRécupère une entrée de temps de travail par id — date, minutes, projet, notes et l'employé auquel elle appartient.
workTimes_listListe les entrées de temps de travail (heures saisies). Filtrez par plage de dates (date.after / date.before, YYYY-MM-DD) et éventuellement par employee ou project ; paginez avec cursor. Chaque ligne porte employeeId/employeeName et projectId/projectName, c'est donc ainsi que vous exportez toutes les heures saisies sur une période. IMPORTANT : les résultats à l'échelle de l'organisation exigent ROLE_WORKING_HOURS_VIEWER. Sans ce rôle, le backend ne renvoie PAS d'erreur — il renvoie silencieusement uniquement les entrées de l'utilisateur connecté, si bien qu'un export « toutes les heures » peut ne contenir qu'une seule personne tout en paraissant parfaitement normal. Si toutes les lignes appartiennent à un seul employé et que vous n'avez pas filtré par employee, la réponse porte un scopeWarning le signalant — signalez-le à l'utilisateur plutôt que de présenter le résultat comme couvrant toute l'organisation.
workTimes_logEnregistre une entrée de temps de travail (work-time) pour l'utilisateur Flowtly connecté (date, durationMinutes, project, notes). LA NOTE DOIT PASSER LE CONTRÔLE ANTI-DESCRIPTION-TROP-COURTE DU SERVEUR, ce qu'un rattrapage en masse (batch backfill) rencontre à répétition : il faut SOIT environ 32 caractères (le seuil exact est un paramètre par organisation, et une organisation peut le mettre à 0 pour désactiver le contrôle), SOIT une référence de ticket « # », SOIT un lien http(s) — un seul de ces trois suffit. « Flowtly – Scallier » est refusé ; « Flowtly – Scallier #FLOW-123 » ne l'est pas. La 422 nomme le propertyPath `description`, qui est le nom côté serveur du champ que cet outil appelle `notes`. Écriture.
workTimes_updateCorrige une entrée de temps de travail enregistrée, par id — sa date, ses minutes, son project ou sa description. C'est ainsi qu'une entrée mal classée est DÉPLACÉE entre projets : workTimes_log ne fait jamais que créer, donc sans cet outil un mauvais project ou une faute de frappe dans la description est permanente. Lisez d'abord l'entrée avec workTimes_get. Le même contrôle anti-description-trop-courte que sur workTimes_log s'applique : environ 32 caractères — le seuil est un paramètre par organisation et peut être à 0, ce qui le désactive — OU une référence de ticket « # » OU un lien http(s), l'un des trois suffisant. Écriture.
workTimes_deleteSupprime une entrée de temps de travail enregistrée, par id. Pour un doublon ou une entrée enregistrée pour un travail qui n'a jamais eu lieu — préférez workTimes_update quand l'entrée est réelle mais erronée, afin que les heures restent dans le registre plutôt que d'en disparaître. Les heures enregistrées alimentent les finances de projet et l'utilisation, donc une suppression change silencieusement les chiffres rapportés pour une période passée. Écriture.

Tags

Outils

tags_createAttache une définition d'étiquette à un enregistrement (tagDefinition + relationName + relationId ; p. ex. relationName "counterparty" pour étiqueter un fournisseur). Utilisez relationName "project" pour PLACER UN PROJET DANS UN DOSSIER, la tagDefinition étant le dossier. Seuls les projets racines (sans parent) sont regroupés en dossiers — les phases suivent leur parent, donc classez la racine et l'arborescence suit. Écriture.

Contacts client

Outils

clientContacts_createCrée une personne de contact pour un client (client, type, name, email requis). Écriture.

Comptes bancaires des contreparties

Outils

counterpartyBankAccounts_createAttache un compte bancaire à une contrepartie (counterparty + accountNumber). Écriture.

Lignes d'échéancier de paiement

Outils

paymentScheduleLines_importCharge tout le plan d'échéances d'un contrat en un seul appel, au lieu d'un aller-retour par ligne. Conçu pour les contrats de promotion immobilière, payés en tranches de construction — une seule vente représente six à douze échéances, et un registre complet en compte des centaines. Chaque ligne nomme son contrat PAR SON NAME (pour un contrat de promoteur importé, son numéro d'agreement), une date d'échéance, et un montant en UNITÉS MINEURES — des grosze, donc 5 300,00 s'écrit "530000" et "5300" enregistre silencieusement 53,00. Les lignes se réconcilient avec les lignes déjà présentes sur contract+date+amount+note, donc une ligne inconnue est créée, une identique est ignorée, et relancer le même lot ne change rien ; PaymentScheduleLine n'a aucune colonne de référence externe, donc cette clé naturelle est la clé de réconciliation. Une ligne dont le nom de contrat ne correspond à rien, ou correspond à PLUS d'un contrat, est signalée en échec plutôt que rattachée à une supposition — placer une échéance sur le mauvais contrat fausse deux flux de trésorerie à la fois. Passez dryRun:true d'abord sur un vrai chargement. Max 1000 lignes. Écriture.
paymentScheduleLines_createAjoute une échéance à l'échéancier de paiement (payment schedule) d'un contrat — le plan de ce qui est censé être facturé ou payé, et quand. Passez l'IRI du contrat, une date et un montant. C'est ce qui résout le problème d'échéancier manquant que signale contracts_get sur un contrat non cyclique : un frais ponctuel a quand même un échéancier, c'est simplement une seule ligne pour le montant total au jour de son échéance. Les contrats cycliques ne sont pas contrôlés à cet égard, car le système ne génère pas automatiquement de lignes à partir d'une cadence. LE MONTANT EST EN UNITÉS MINEURES — des grosze, pas des złote : 5 300,00 s'écrit "530000", et "5300" enregistre silencieusement une ligne de 53,00. L'API les retourne de la même façon, donc relisez-en une avec contracts_paymentScheduleLines si vous n'êtes pas sûr de l'échelle. Relisez le résultat avec contracts_paymentScheduleLines. Écriture.
paymentScheduleLines_updateModifie une ligne d'échéancier de paiement par id — sa date, son amount ou sa note. À utiliser quand une échéance glisse ou est renégociée, plutôt que de supprimer et recréer, afin que la ligne conserve toute facture déjà rapprochée. LE MONTANT EST EN UNITÉS MINEURES — des grosze, pas des złote : 5 300,00 s'écrit "530000", et "5300" enregistre silencieusement une ligne de 53,00. L'API les retourne de la même façon, donc relisez-en une avec contracts_paymentScheduleLines si vous n'êtes pas sûr de l'échelle. Écriture.
paymentScheduleLines_deleteRetire une ligne d'échéancier de paiement par id. Supprime le PLAN, pas l'argent : une invoice ou transaction déjà rapprochée de la ligne n'est pas affectée, mais elle cesse d'être réconciliée avec quoi que ce soit. Préférez paymentScheduleLines_update pour une échéance qui a bougé. Écriture.

Icône de l'organisation

Outils

organizationIcon_uploadCharge/remplace l'icône/favicon de l'organisation (image base64 + contentType + filename). Lisez l'actuelle via configs_get organization-icon-url. Écriture.

Stockage

Outils

storage_uploadAttache un fichier à tout enregistrement que le stockage générique de Flowtly accepte — un ACTIF (relationName "property"), un project, une task, un client, un location, un sous-traitant, une invoice. C'est la seule voie vers une PHOTO d'actif : téléverser avec relationName "property" définit l'image que l'application affiche pour cet actif (servie comme `file` dans le payload de l'actif). Property n'a pas de colonne image -- la photo est dérivée de cette table au moment de la lecture, ce qui explique pourquoi rien sur l'entité ne laisse deviner son existence. C'est UN SEUL emplacement et le dernier téléversement gagne, donc une seconde image remplace la première plutôt que de s'ajouter à une galerie. Il en va de même pour location, invoices et transaction-attachments ; clients, agreements et candidates accumulent en revanche chaque téléversement sous `files`. TOUTE AUTRE RELATION NE RATTACHE LE TÉLÉVERSEMENT À RIEN DE VISIBLE, et relationName "employees" est celle avec laquelle il faut être prudent : elle stocke les octets et ne crée AUCUN Document, donc People > Documents reste vide et le payload de l'employé ne porte aucun fichier. La route /documents de tout enregistrement retourne des entités Document, et un téléversement n'en crée aucune — c'est ainsi que des PDF signés de NDA et d'ESOP ont été signalés comme classés alors que l'onglet Documents n'affichait rien (#255). Un vrai document d'employé nécessite un POST /documents portant un DocumentType dont le relationName est `employee`, l'id de l'employé, et l'IRI de la ligne Storage que cet appel retourne. NE L'ASSEMBLEZ PAS À LA MAIN : utilisez employeeDocuments_createUploadTicket, qui effectue les trois étapes — stocke les octets, crée le Document, et le relit via /people/{id}/documents — et rapporte stored / linked / verified séparément. Cet outil s'arrête aux octets. Ne vous tournez pas non plus vers agreementTypes.* : un AgreementType est le type d'un CONTRAT de travail (Umowa o pracę, Umowa zlecenie) sous Ludzie > Umowy, et n'est pas un DocumentType. Rapportez octets stockés, enregistrement métier rattaché et visibilité vérifiée comme trois affirmations distinctes, et n'affirmez que celles que vous avez réellement faites. `file` est omis des réponses LIST sauf si la requête passe ?include=file, donc relisez un enregistrement pour confirmer que la photo est bien arrivée. Passez relationName + relationId (l'id depuis l'outil de liste de cet enregistrement ; une IRI /assets/7 est acceptée et réduite) plus les octets en base64 avec un contentType et un filename. LIMITE DE TAILLE : les octets voyagent en base64 à l'intérieur de cet appel, donc restez sous environ 150 Ko — les photographies dépassent presque toujours cela, et pour celles-ci utilisez storage_createUploadTicket, qui n'a pas de plafond. Les permissions sont celles qu'exige l'édition de l'enregistrement PROPRIÉTAIRE : le backend résout relationName vers cette entité et interroge son propre voter, donc classer un fichier sur un actif nécessite la permission des actifs, sur un client celle des clients. Pour un contrat, préférez plutôt contractAttachments_create — il résout aussi contracts.problem_missing_document, ce que ceci ne fait pas. Écriture.
storage_createUploadTicketGénère un ticket éphémère à usage unique pour attacher un GROS fichier à tout enregistrement — la façon dont les PHOTOS d'actif entrent réellement, puisqu'une image dépasse toujours le plafond du base64. Sur property/location/invoices/transaction-attachments, le dernier téléversement devient l'image visible de l'enregistrement, remplaçant la précédente ; sur clients/agreements/candidates, les téléversements s'accumulent. À utiliser à la place de storage_upload dès que le fichier dépasse quelques dizaines de Ko : cet outil transporte les octets en base64, que l'appelant doit émettre en texte, et un JPEG de 400 Ko devient environ 533 000 caractères base64, bien au-delà de ce qui tient dans une réponse. Passez relationName + relationId plus un filename ; vous récupérez un uploadUrl et un curl prêt à l'emploi. Envoyez ensuite les OCTETS BRUTS du fichier à cette URL (curl --data-binary @photo.jpg) — pas de base64, pas de multipart — et la réponse porte l'enregistrement Storage créé. Le ticket expire en 15 minutes, fonctionne une fois, et ne peut déposer que sur le seul enregistrement qu'il nomme. Écriture.

Pièces jointes de contrat

Outils

contractAttachments_createAttache un document à un contrat — normalement le PDF exécuté, ou une annexe (DPA, SLA, annexe tarifaire) classée à ses côtés. Passez les octets en base64 avec un fileName et l'id de contrat depuis contracts_list ; `contractId` ici est un id BRUT, contrairement aux IRIs que prend contracts_update pour counterparty et project, bien qu'une IRI /contracts/<id> complète soit acceptée et réduite. LIMITE DE TAILLE : les octets voyagent en base64 à l'intérieur de cet appel, donc tout le document doit tenir dans une seule réponse du modèle — restez sous environ 150 Ko, et pour tout ce qui est plus gros, utilisez plutôt contractAttachments_createUploadTicket, conçu exactement pour cela et sans un tel plafond. Un contrat exécuté avec une carte de signature dépasse généralement cela (673 617 octets deviennent 898 156 caractères base64, plusieurs fois ce qu'une réponse peut transporter), et aucune erreur ne revient quand cela ne tient pas, car l'appel ne peut pas du tout être émis — la requête n'atteint jamais le serveur, donc vérifiez la taille du fichier AVANT de commencer plutôt que de le découvrir par un échec. C'est ce qui résout le problème de document manquant que signale contracts_get, si bien qu'un contrat maintenu via l'API cesse de traîner dans la file d'attente de rangement de l'application. Un seul document signé peut couvrir plusieurs lignes de contrat (un accord comportant à la fois une partie récurrente et une partie ponctuelle correspond à deux lignes, car `cyclic` est par enregistrement) — appelez ceci une fois par id de contrat avec les mêmes octets. La suite dépend de kind. kind "contract" : `status` revient à "analyzing" et le backend lit le document de manière asynchrone, normalement en quelques minutes ; interrogez contracts_get jusqu'à ce que la pièce jointe soit "analyzed" ou "failed" (un échec porte failureReason et failureRetryable). La lecture ne fait que REMPLIR LES CHAMPS VIDES du contrat et n'écrase jamais un nom, une direction, un montant, des dates, une devise, des conditions de paiement, des lignes d'échéancier ou des prix déjà présents ; chaque valeur extraite reste dans l'analysisSummary de la pièce jointe, et analysisSummary.notApplied liste ce qu'elle a laissé à l'état de suggestion. kind "annex" : stockée et NON analysée ; `status` vaut "stored", ce qui est définitif, et le contrat ne change pas. Traitez analysisSummary comme une SUGGESTION à vérifier plutôt que comme un fait auquel se fier. Écriture.
contractAttachments_createUploadTicketGénère un ticket éphémère à usage unique pour attacher un GROS document à un contrat — le PDF exécuté, ou une annexe. À utiliser à la place de contractAttachments_create dès que le fichier dépasse quelques dizaines de Ko : cet outil transporte les octets en base64, que l'appelant doit émettre en texte, et un vrai contrat signé (~700 Ko, ~900 000 caractères base64) dépasse largement ce qui tient dans une réponse. Passez l'id de contrat depuis contracts_list plus un fileName ; vous récupérez un uploadUrl et un curl prêt à l'emploi. Envoyez ensuite les OCTETS BRUTS du fichier à cette URL (curl --data-binary @file.pdf) — pas de base64, pas de multipart — et la réponse est l'attachment créé. Le ticket expire en 15 minutes, fonctionne une fois, et ne peut s'attacher qu'au seul contrat qu'il nomme. C'est ce qui résout le problème de document manquant que signale contracts_get. Écriture.

Transactions de facture

Outils

invoiceTransactions_createEnregistre un paiement pour une facture sortante (vente). `invoice` est un IRI de facture issu de invoices_list ; `date` est la date à laquelle le paiement est considéré comme effectué. `transaction` est optionnel — omettez-le pour enregistrer un règlement sans ligne bancaire, ce que vous voulez pour les factures historiques dont le relevé bancaire n'a jamais été importé. `amount` est optionnel et vaut par défaut le solde dû de la facture. Enregistrer un paiement est ce qui empêche qu'une facture émise et échue soit traitée comme impayée, et c'est donc aussi ce qui empêche que des relances de paiement soient mises en file pour elle. Rien n'empêche d'enregistrer deux paiements pour une même facture, lisez donc d'abord invoices_get si vous n'êtes pas sûr qu'elle est déjà réglée. Écriture.
invoiceTransactions_updateMet à jour un enregistrement de paiement de facture existant par id (depuis invoiceTransactions de invoices_get, ou en paginant invoiceTransactions). Usage le plus courant : rattacher un paiement enregistré sans ligne bancaire à une transaction que vous venez d'importer via transactions_importStatement, en définissant `transaction` sur un IRI/id de transaction issu de transactions_list. LE PIÈGE : c'est un PATCH, mais le backend requiert quand même `invoice` et `date` à chaque appel — il ne fusionne PAS les valeurs existantes pour vous. Lisez d'abord l'enregistrement (ou disposez-en déjà depuis l'appel de création) et renvoyez ses `invoice` et `date` inchangés en plus de ce que vous voulez réellement modifier, sinon la mise à jour est rejetée. `transaction` accepte null pour délier un paiement d'une ligne bancaire. `amount` est optionnel. Écriture.
invoiceTransactions_deleteSupprime un enregistrement de paiement d'une facture par son id — les ids se lisent dans invoiceTransactions de invoices_get. Cela retire L'ENREGISTREMENT INDIQUANT QU'UNE FACTURE A ÉTÉ PAYÉE, pas une transaction bancaire : à utiliser lorsqu'une facture porte un paiement qui n'aurait jamais dû exister, le cas habituel étant le même paiement comptabilisé deux fois — une fois à la main et une fois par l'import de relevé qui l'a ensuite rapproché. Vérifiez d'abord invoices_get et supprimez l'enregistrement dont la `transaction` est la mauvaise (gardez celui qui pointe vers la vraie ligne bancaire importée) ; supprimer le dernier paiement restant rend la facture de nouveau impayée, ce qui réarme ses relances de paiement. Nécessite ROLE_INVOICES_MANAGER. Irréversible, à fort impact. Écriture.

Planification des ressources

Outils

resourcing_importTimelineImporte une feuille de timeline d'allocations de resourcing (récupérez-la via le MCP Drive, passez son CSV tel quel). C'est un miroir en REMPLACEMENT COMPLET des lignes Allocation de l'organisation pour `year` : les lignes de la feuille sont créées/mises à jour, et toute ligne existante pour cette année absente de la feuille est SUPPRIMÉE — ce n'est pas une fusion. DRY-RUN PAR DÉFAUT : un dryRun omis prévisualise et n'écrit rien ; passez dryRun:false pour appliquer. Le rapport donne `created` / `replaced` plus `unmatchedPeople` / `unmatchedProjects`. DEUX CHOSES SONT FACILES À MANQUER : une ligne de la feuille dont le projet ne se résout pas est IGNORÉE alors que l'appel signale quand même un succès, un résultat vert peut donc cacher un import partiel ; et un code de rôle que le catalogue de postes ne possède pas déjà est CRÉÉ comme nouveau poste plutôt que rejeté — voir `createdPositions`. Les deux sont signalés dans `warnings` lorsqu'ils se produisent ; faites remonter cela à l'utilisateur plutôt que de ne rapporter que `created`. Une feuille qui se résout en zéro ligne est refusée (cela ressemble exactement à une mauvaise lecture sur le point d'effacer toute la timeline) sauf si vous passez force:true. Lisez allocations_list ensuite pour voir ce qui a été enregistré. Fort impact. Écriture.

Organisation

Outils

organization_whoamiRenvoie l'organisation à laquelle cette connexion MCP est liée — { orgId, name, slug, userId }. Appelez-le pour confirmer DANS QUEL tenant vous êtes sur le point d'écrire avant tout create/update : la connexion est liée à exactement une org par le token, et écrire des prospects/enregistrements dans la mauvaise org est un véritable incident. Lecture seule.

Réalisé des ressources

Outils

resourcingActuals_getHeures déclarées par rapport au plan, par personne et par semaine, sur une fenêtre from/to — la question « l'équipe est-elle réellement dans les temps ? » à laquelle AUCUN autre outil de resourcing ne répond : les allocations indiquent ce qui était PLANIFIÉ, celui-ci indique ce qui a été LIVRÉ. Renvoie des colonnes hebdomadaires plus une ligne par personne (% planifié, % déclaré, écart, totaux, et une répartition par projet). reportedPercent à null signifie « pas de contrat cette semaine-là » et 0 signifie « un contrat existait et rien n'a été déclaré » — ne confondez PAS les deux. Passez financials pour le revenu/coût/marge, omis sinon. Nécessite le module resourcing et ROLE_RESOURCING_MANAGER. Lecture seule.

Vivier de ressources

Outils

resourcingBench_getQui N'EST PAS affecté sur une fenêtre from/to — le bench. Utilisez-le lorsqu'on vous demande qui affecter à un nouveau projet ou où de la capacité reste inutilisée ; resourcingActuals_get indique la charge des personnes, celui-ci indique qui n'a aucune charge du tout. IL NE CONNAÎT PAS LES CONGÉS : freePercent est 100 moins les allocations confirmées, rien d'autre, donc quelqu'un en congé approuvé pour trois semaines apparaît à 100% libre et aucun champ de la réponse n'indique le contraire. Répondre à « qui est disponible » à partir de cela seul mettra des personnes sur des projets pendant qu'elles sont absentes — vérifiez en croisant avec holidays_active ou holidays_list. Nécessite le module resourcing. Lecture seule.

Planning des ressources

Outils

resourcingSchedule_getLe planning de resourcing prévu sur une fenêtre from/to — la timeline des allocations telle que la montre le planificateur. Utilisez-le pour ce qui est RÉSERVÉ à venir ; utilisez resourcingActuals_get pour ce qui a réellement été déclaré par rapport à cela. Nécessite le module resourcing et ROLE_RESOURCING_MANAGER. Lecture seule.