MCP-server
Verbind AI-tools met Flowtly via het Model Context Protocol op mcp.flowtly.eu.
Verbinden
claude mcp add --transport http flowtly https://mcp.flowtly.eu/mcp
Op deze pagina
Overeenkomsten
Tools
| agreements_get | Haal één arbeidsovereenkomst op via id — type, variant, het venster dateFrom/dateTo, hoursPerWeek, en de afgeleide `calculable`, `active` en `status`. agreements_list levert de id. Vereist ROLE_AGREEMENTS_MANAGER of ROLE_MEETING_MANAGER. Alleen-lezen. |
| agreements_list | Lijst van arbeidsovereenkomsten — filter op employee (IRI), isActive, type of variant. DE manier om te beantwoorden "waarom zegt people_list dat deze persoon inactief is": elke rij bevat `calculable` en `active`, en een persoon is actief precies wanneer die een overeenkomst heeft die beide is. Ook de plek om de `type`-codes te lezen die deze organisatie daadwerkelijk gebruikt voordat agreements_create wordt aangeroepen, aangezien een organisatie eigen types kan toevoegen. Vereist ROLE_AGREEMENTS_MANAGER of ROLE_MEETING_MANAGER. Alleen-lezen. |
| agreements_create | Maak een arbeidsovereenkomst aan voor een persoon. DIT IS DE STAP DIE IEMAND ACTIEF MAAKT: people_create maakt alleen het record aan, en een persoon zonder overeenkomst meldt voor altijd isActive false — een bulkimport komt daardoor voor 100% inactief binnen totdat dit voor elk van hen wordt uitgevoerd. TWEE DINGEN MOETEN BEIDE WAAR ZIJN, anders blijven ze inactief zonder enige foutmelding: `type` moet een CALCULABLE type zijn (de ingebouwde "agreement", "annex", "termination" zijn dat; "list-of-intent" en "work-experience" niet), en het dateFrom/dateTo-venster moet vandaag omvatten (geef dateTo null mee voor een doorlopend contract in plaats van een datum ver in de toekomst). `employee` is een IRI — /people/<id> vanuit people_list. Types zijn per organisatie uitbreidbaar, dus voer agreements_list uit op iemand die al actief is om de codes te zien die deze organisatie daadwerkelijk gebruikt. Vereist ROLE_AGREEMENTS_MANAGER. Schrijven. |
| agreements_update | Wijzig een bestaande arbeidsovereenkomst — de manier waarop een overeenkomst wordt BEËINDIGD, omdat de backend voor deze resource geen delete aanbiedt: zet `dateTo` op de laatste dag die deze dekt en de persoon is vanaf dat moment niet meer actief, terwijl het record en de geschiedenis intact blijven. Dat is de juiste aanpak voor een aan payroll gerelateerde rij; er is geen manier om er een te laten verdwijnen en die zou er ook niet moeten zijn. Dit is ook de manier om een verkeerde `type`, `variant` of `positionName` ter plekke te corrigeren in plaats van een tweede overeenkomst boven op de persoon te stapelen — TWEE overeenkomsten heffen elkaar niet op, de calculable overeenkomst houdt de persoon actief, dus "er een correcte naast plaatsen" laat de verkeerde stilzwijgend van kracht blijven. `amount`, `amountType` en `billingType` worden geaccepteerd, maar de API geeft ze nooit terug, dus je kunt niet terug uitlezen wat je hebt geschreven. Vereist ROLE_AGREEMENTS_MANAGER. Schrijven. |
Overeenkomsttypen
Tools
| agreementTypes_get | Haal één contracttype op via id — de name of translationKey, `calculable`, `isActive`, `position` en `builtIn`. De id IS de code: dit leest een type dus terug met dezelfde string die een overeenkomst opslaat in `type`. Gebruik dit om te bevestigen dat een type is opgeslagen na agreementTypes_create, en om `calculable` te controleren voordat iemand op dit type wordt gezet. Vereist ROLE_USER. Alleen-lezen. |
| agreementTypes_list | Lijst van de contracttypes die DEZE organisatie op een overeenkomst kan zetten — de waarden achter `Ludzie > <person> > Umowy > Edytuj umowę`. Lees dit voor agreements_create of agreements_import, want de lijst is per tenant: vijf ingebouwde types worden standaard meegeleverd ("agreement", "annex", "termination", "list-of-intent", "work-experience") en een organisatie kan eigen types toevoegen, zodat een `type` dat in de ene organisatie geldig is in een andere een 422 oplevert. DE ID IS DE CODE — de `id` van elke rij is precies de string die `agreements_create` verwacht in `type`, geen numerieke sleutel om op te zoeken. `calculable` is het veld dat bepaalt of het hebben van dit type iemand ACTIEF maakt en meetelt in de resourcing bench, de verlofopbouw en de kostenbasis; een niet-calculable type laat iemand inactief zonder enige foutmelding, wat de bedoeling is voor een type als "list-of-intent" en een stille bug is als het per ongeluk is gekozen. `builtIn`-rijen bevatten een translationKey en een null name; aangepaste rijen bevatten een letterlijk weergegeven name en een null translationKey. Vereist ROLE_USER. Alleen-lezen. |
| agreementTypes_create | Voeg een contracttype toe aan de lijst van DEZE organisatie, zodat een overeenkomst kan worden vastgelegd tegen iets dat de vijf ingebouwde types niet dekken — "Umowa zlecenie", "Kontrakt B2B", "Użytkownik funkcyjny". Dit is configuratie, geen codewijziging: de lijst is een tabel per tenant, en een aangepast type heeft geen vertaalitem nodig omdat de `name` letterlijk wordt weergegeven in alle zeven locales. STUUR GEEN `id` MEE: de code wordt server-side van de naam afgeleid als slug, met diakritische tekens platgeslagen ("Użytkownik funkcyjny" wordt "uzytkownik-funkcyjny"), en het meesturen van een id wordt geweigerd met 422 "Update is not allowed for this operation". Post de name en lees de toegewezen code terug uit de response. `calculable` STAAT STANDAARD OP FALSE EN IS STIL: het bepaalt wie als werkzaam telt — de resourcing bench, de verlofopbouw, de kosten- en budgetbasis — dus een type bedoeld voor mensen die GEEN verlof mogen opbouwen of geen FTE mogen bezetten, is correct op false, en een type bedoeld voor echt dienstverband MOET dit op true zetten, anders meldt iedereen daarop inactief zonder enige foutmelding. Niets vertelt je welke van de twee je hebt gekregen. `position` bepaalt de volgorde in de keuzelijst; `isActive` staat standaard op true. Er is met opzet geen update of delete via MCP — `agreement.type` slaat de id van deze rij op als een kale string zonder foreign key, dus het hernoemen of verwijderen van een type maakt elke overeenkomst die ernaar verwijst wees. Vereist ROLE_AGREEMENTS_MANAGER. Schrijven. |
Allocaties
Tools
| allocations_get | Eén allocatie op id — de boeking van één persoon op een project, met de datums en het percentage. allocations_list vindt de id; dit leest het volledige record. Een allocatie zonder werknemer is een OPEN rol (onvervulde vraag), geen boeking. Vereist de resourcing-module. Alleen-lezen. |
| allocations_list | Lijst met resourcing-allocaties — toewijzingen met een datumbereik van een positie op een project aan een werknemer (of nog aan niemand, een open rol). Geen filters; pagineer met cursor. Elk item bevat al opgeloste employeeId/employeeName en projectId/projectName (null employeeId betekent een open rol); positionId is kaal — los de naam op via positions_list. source onderscheidt uit een sheet geïmporteerde rijen van rijen die rechtstreeks in Flowtly zijn aangemaakt. Gebruik dit om een resourcing-sheetimport te controleren: lees terug wat is beland en vergelijk dit met wat is ingediend. |
Assetboekingen
Tools
| assetBookings_get | Haal één assetreservering op via id — het asset, de houder ervan, de datums, en of deze is geannuleerd. Alleen-lezen. |
| assetBookings_list | Lijst van assetreserveringen — wie of wat elk asset op dit moment vasthoudt, dit is de toewijzing die het scherm Assets toont en de enige plek waar een koppeling tussen asset en persoon daadwerkelijk bestaat. Elke rij bevat het asset, de houder (`relationName` employee | project plus `relationId`), start-/einddatums en, zodra vrijgegeven, `cancelReason` en `cancelledAt`. Filter op `property` om de geschiedenis van één asset te zien, of op `employee` om alles te zien wat één persoon vasthoudt — dat laatste is wat je uitvoert voordat iemand vertrekt. Let op: `employee` is hier de NUMERIEKE id, niet de /people-IRI die assetBookings_create verwacht. Voeg `exists.cancelledAt: false` toe om alleen te zien wat nog steeds wordt vastgehouden; zonder dat bevat de lijst ook vrijgegeven reserveringen. Alleen-lezen. |
| assetBookings_create | Wijs een asset toe aan een persoon of een project. `property` is de asset-IRI (/assets/{id}) en is verplicht. Benoem de houder op EEN van drie manieren: `relation` met één IRI (/people/{id} voor een persoon, /projects/{id} voor een project), of `relationName` (employee | project) plus `relationId`, of het `employee`/`project`-IRI-veld rechtstreeks. Precies één houder moet worden opgelost — geen van beide benoemen wordt geweigerd met "Employee or Project must be set." en beide benoemen met "Employee and Project cannot be set at the same time." TWEE DINGEN DIE NIET IN HET SCHEMA STAAN EN JE EEN 422 OPLEVEREN: het asset moet al reserveerbaar zijn (`bookingAllowed: true` — stel dit in met assets_update), een bedrijfsregel die voor IEDERE aanroeper geldt, inclusief een manager, geweigerd met "This asset is not reservable."; en de eigen `bookingType` van het asset (minutes | days | single-days | permanently) is wat `duration`/`endDate` betekenis geeft — een ruimte die voor onbepaalde tijd aan één persoon is toegewezen is `permanently` met een `startDate` en geen einde. Gelijktijdige reserveringen op één asset worden server-side geserialiseerd, dus een overlap wordt geweigerd in plaats van dubbel geboekt. Vereist ROLE_PROPERTY_BOOKINGS_MANAGER om namens iemand anders te reserveren. Schrijven. |
| assetBookings_update | Werk een bestaande assetreservering bij — de datums, duur, factuurbedrag/valuta, of het aandeel in het gemeten verbruik. `relationName` en `relationId` zijn verplicht in de payload, dus stuur de houder mee die de reservering al heeft, tenzij je deze bewust verplaatst. Gebruik assetBookings_cancel om een toewijzing te beëindigen, niet een endDate in het verleden. Vereist ROLE_PROPERTY_BOOKINGS_MANAGER. Schrijven. |
| assetBookings_cancel | Geef een asset vrij — de manier waarop een toewijzing eindigt, en het dichtst wat deze resource heeft bij een delete (er is geen delete-bewerking). Neemt de booking-id en een `cancelReason` van 3-255 tekens; de reservering blijft bewaard en wordt voorzien van `cancelledAt` zodat de geschiedenis behouden blijft, en het asset komt vrij voor de volgende houder. Dit is de aanroep om te doen wanneer een werknemer vertrekt: assetBookings_list gefilterd op `employee` vindt wat die persoon vasthoudt, en dit geeft elk daarvan vrij. Vereist ROLE_PROPERTY_BOOKINGS_MANAGER. Schrijven. |
Meterstanden assets
Tools
| assetMeterReadings_get | Haal één meterstand op via id — de meter, datum en waarde. Alleen-lezen. |
| assetMeterReadings_list | Lijst van meterstanden — de gedateerde waarden die tegen een assetmeter zijn geregistreerd, de ruwe data waarop de verdeling van meterfacturatie is gebaseerd. Elke rij bevat de meter, datum en waarde. Gebruik dit om de geschiedenis van een meter te lezen: een waarde die over periodes heen nooit verandert (een vastgelopen of gedeelde meter) factureert nul, en een meter zonder recente rijen is er een die niemand afleest. Alleen-lezen. |
Activameters
Tools
| assetMeters_get | Haal één assetmeter op via id — het asset waarop deze zit, het utility type, de eenheid en de externe/QR-identifier, met de bijbehorende standen. Alleen-lezen. |
| assetMeters_list | Lijst van de assetmeters van de organisatie — de nuts-/mediatellers die aan assets zijn gekoppeld (elektriciteit, water, gas, warmte). Elke rij bevat het asset waarop de meter zit, het utility type en de eenheid, en de bijbehorende standen. Filter op `property` (het asset waartoe de meter behoort) en `utilityType`. Gebruik dit om de meter-id te achterhalen die standen nodig hebben, en om meters te vinden die nul aflezen, op één waarde vastzitten, of op een gedeelde/collectieve meter staan. Alleen-lezen. |
| assetMeters_update | Werk een assetmeter bij — het label, utility type, de eenheid, of de actieve status. Gebruik dit om een meter uit gebruik te nemen (bijvoorbeeld een utility die nu rechtstreeks via de factuur wordt afgerekend) zonder de standenhistorie te verwijderen. Vereist ROLE_PROPERTIES_MANAGER. Schrijven. |
Assets
Tools
| assets_get | Haal één asset op via id — name, status, categorie (attributeSet), parent, assetCode, serienummer, aankoop- en garantiedatums, locatie en reserveringsinstellingen. Alleen-lezen. |
| assets_list | Lijst van de assets van de organisatie — het register van fysieke zaken die zij bezit of verkoopt, van laptops en bureaus tot appartementen, parkeerplaatsen en opslageenheden. Filter op status (in-stock | damaged | sold), attributeSet (de categorie waarop de Assets-lijst groepeert), bookingAllowed, of een gedeeltelijke name of serialNumber; sorteer op name, status, serialNumber, boughtAt of warrantyTo. NIET GEPAGINEERD — de complete set komt terug in één response, dus een groot register is één grote payload in plaats van een eerste pagina. Gebruik dit om de asset-id te achterhalen die assetreserveringen en assetdocumenten nodig hebben. Alleen-lezen. |
| assets_import | Laad VEEL assets in één aanroep, met `assetCode` als sleutel — de tool om een voorraad vanuit een ander systeem over te zetten, waar assets_create één round trip per record zou zijn. Rijen worden verzoend met de organisatie: een onbekende assetCode maakt aan, een bekende werkt ter plekke bij, een identieke rij wordt overgeslagen, dus opnieuw uitvoeren verandert niets en een halfvoltooide run is veilig te herhalen. `parentAssetCode` nestelt een rij onder een andere OP BASIS VAN DE CODE, opgelost tegen de organisatie en tegen eerdere rijen van dezelfde batch; een parent die nooit wordt opgelost laat die rij falen in plaats van deze stilzwijgend wees te maken. DRIE VELDEN MAKEN HET RECORD LEESBAAR in plaats van een kale naam: `attributeSetName` is de categorie die de UI toont als Typ zasobu en waarop de lijst groepeert, `locationName` is waar het ding zich fysiek bevindt, en `attributes` is een {name: value}-map voor oppervlakte, verdieping, prijs en al het andere dat de bron bevat. Alle drie worden OP NAAM opgelost — de categorie, de locatie, de attribuutdefinities en hun koppelingen worden voor je gevonden of aangemaakt, zodat een aanroeper nooit met een van die IRIs hoeft te werken, en namen worden hoofdletterongevoelig gematcht zodat "Mieszkanie" en "mieszkanie " de lijst niet in tweeën kunnen splitsen. `attributes` heeft een categorie nodig om aan te hangen, en een waarde die als getal kan worden geparsed maakt een numeriek attribuut aan, wat wordt bepaald de eerste keer dat de naam verschijnt. Een attribuut dat niet kan worden geschreven laat zijn asset NIET falen. GEEF EERST dryRun:true MEE bij het laden van een echte voorraad — het rapporteert per rij would-create / would-update / would-skip en maakt helemaal niets aan, categorieën en locaties inbegrepen. Max 1000 rijen. Vereist ROLE_PROPERTIES_MANAGER. Schrijven. |
| assets_create | Maak een asset aan (name + status + bookingType verplicht; status = in-stock | damaged | sold, bookingType = minutes | days | single-days | permanently). bookingType is verplicht, ook als het asset nooit wordt gereserveerd — geef "permanently" op voor iets dat niet wordt uitgeleend, en laat bookingAllowed op false. Twee velden dragen de structuur: `parent` nestelt een asset onder een andere (een unit onder een gebouw, een monitor onder een bureau), en `attributeSet` stelt de categorie in waarop de Assets-lijst groepeert, wat ook de plek is waar aangepaste attributen zoals oppervlakte of verdieping zich bevinden. `assetCode` is een UNIEK cross-systeem-handvat — gebruik dit om de id vast te houden die dit asset heeft in het bronsysteem waaruit het is geïmporteerd, zodat een herimport bijwerkt in plaats van dupliceert. Vereist ROLE_PROPERTIES_MANAGER. Schrijven. |
| assets_update | Werk een asset bij via id — name, status, categorie, parent, assetCode, serienummer, datums, locatie of reserveringsinstellingen. Zo gaat een asset van in-stock naar sold. Let op: de statusvocabulaire is in-stock | damaged | sold en heeft GEEN reserved-status, dus een blokkering moet op een andere manier worden gemodelleerd. Vereist ROLE_PROPERTIES_MANAGER. Schrijven. |
Entiteitattribuutwaarden
Tools
| attributeEntityValues_list | Lijst van attribuut-WAARDEN — wat een specifiek asset, project, budget of client daadwerkelijk heeft voor een gekoppeld attribuut. Elke rij bevat het attribuut, de waarde, en `relationId` die de entiteit aangeeft waartoe deze behoort. Alleen-lezen. |
| attributeEntityValues_create | Zet een attribuutwaarde op één entiteit (attribute + value verplicht). `relation` IS EEN IRI — "/properties/7", niet het woord "property": de backend lost deze op en leidt de relatienaam af uit de resourceclass, dus het meesturen van een kale naam geeft een fout. (`relationId` neemt een kale id en werkt nog steeds, maar is deprecated ten gunste van de IRI.) Het attribuut moet al GEKOPPELD zijn aan de categorie van die entiteit, anders wordt de waarde opgeslagen maar nooit weergegeven. Vereist ROLE_ATTRIBUTES_MANAGER. Schrijven. |
| attributeEntityValues_update | Wijzig één attribuutwaarde ter plekke, via de id. Gebruik dit in plaats van een tweede waarde aan te maken voor hetzelfde (entiteit, attribuut)-paar — niets dwingt uniciteit af, dus een duplicaat wordt geaccepteerd en de UI toont er één van. Vereist ROLE_ATTRIBUTES_MANAGER. Schrijven. |
| attributeEntityValues_delete | Verwijder een attribuutwaarde van een entiteit. De definitie en de koppeling blijven bestaan; alleen de waarde van deze entiteit verdwijnt. Vereist ROLE_ATTRIBUTES_MANAGER. Schrijven. |
Attributen
Tools
| attributes_get | Haal één attribuutdefinitie op via id — name, type, of deze required of multiple is, standaardwaarde en format-patroon. Alleen-lezen. |
| attributes_list | Lijst van attribuut-DEFINITIES — de benoemde velden (oppervlakte, verdieping, prijs) die categorieën koppelen en waarvoor assets waarden dragen. Elke definitie heeft een type: number | string | date | state | period. Alleen-lezen. |
| attributes_create | Maak een attribuutdefinitie aan (name + type verplicht; type is number | string | date | state | period). HET TYPE IS DE BESLISSING: het wordt gedeeld door elke entiteit die dit attribuut draagt, dus een veld dat als `string` is aangemaakt kan later niet worden opgeteld of gesorteerd als getal zonder dat elke bestaande waarde wordt herschreven. Bepaal dit aan de hand van de waarden die je daadwerkelijk hebt, niet de eerste die je ziet. Een definitie doet op zichzelf niets — koppel deze aan een categorie met attributeSetAttributes_create, anders verschijnt hij nergens. Vereist ROLE_ATTRIBUTES_MANAGER. Schrijven. |
| attributes_update | Werk een attribuutdefinitie bij — name, type, required, multiple, default of format. Het wijzigen van `type` op een definitie die al waarden heeft, is de riskante: bestaande waarden worden niet geconverteerd. Vereist ROLE_ATTRIBUTES_MANAGER. Schrijven. |
Attribuutset-attributen
Tools
| attributeSetAttributes_list | Lijst van de koppelingen tussen categorieën en attribuutdefinities — welke velden op welke categorie verschijnen. Alleen-lezen. |
| attributeSetAttributes_create | Koppel een attribuutdefinitie aan een categorie (attributeSet + attribute, beide IRIs). DIT IS WAT EEN ATTRIBUUT LAAT VERSCHIJNEN: zonder de koppeling kan een waarde succesvol tegen een entiteit worden geschreven en zal deze nooit in de UI verschijnen — een fout zonder symptoom. Vereist ROLE_ATTRIBUTES_MANAGER. Schrijven. |
| attributeSetAttributes_delete | Ontkoppel een attribuut van een categorie. De definitie en eventuele waarden blijven bestaan; ze worden alleen niet meer getoond voor die categorie, wat hierdoor op dataverlies lijkt terwijl dat niet zo is. Vereist ROLE_ATTRIBUTES_MANAGER. Schrijven. |
Attribuutsets
Tools
| attributeSets_get | Haal één attribuutset op via id — de name, relationName, icon, en de attributen die eraan gekoppeld zijn. Alleen-lezen. |
| attributeSets_list | Lijst van de attribuutsets van de organisatie — de CATEGORIEËN waaronder een asset, project, budget of client is ingedeeld. Filter op relationName: "property" voor assetcategorieën (wat de UI Typ zasobu noemt en waarop de Assets-lijst groepeert), plus "project", "budget" en "client". Raadpleeg dit voordat je er een aanmaakt: een categorie die door spelling of hoofdlettergebruik gedupliceerd is, splitst de lijst die zij groepeert stilzwijgend, en niets in de UI legt uit waarom. Alleen-lezen. |
| attributeSets_create | Maak een categorie aan (name + relationName verplicht; relationName is één van property | project | budget | client, en voor een assetcategorie is dat de kale string "property" — GEEN IRI). Optionele icon uit een vaste lijst (room, parking, building, office, local, desk, monitor enzovoort) die de UI naast de categorie toont. EERST LIJSTEN: names zijn niet uniek, dus een tweede "Mieszkanie" wordt geaccepteerd en splitst de Assets-lijst stilzwijgend in tweeën. Vereist ROLE_ATTRIBUTES_MANAGER. Schrijven. |
| attributeSets_update | Hernoem een categorie, wijzig het icoon, of verplaats deze naar een andere relationName. Zo wordt een categorie die met een typfout is aangemaakt gecorrigeerd in plaats van gedupliceerd. Vereist ROLE_ATTRIBUTES_MANAGER. Schrijven. |
Bankrekeningen
Tools
| bankAccounts_get | Haal één bankrekening op via id — naam, valuta, bank en het formaat waarin de afschriften worden geïmporteerd. |
| bankAccounts_list | Lijst met de bankrekeningen van de organisatie. Filter op bank, of stel hidden in om gearchiveerde rekeningen mee te nemen. Gebruik dit om de bankAccount-id op te lossen waarop transactions_list filtert. |
| bankAccounts_create | Maak een bankrekening aan (type, name, currency, defaultImportFormat verplicht). Schrijfactie. |
| bankAccounts_update | Werk een bankrekening bij via id. Schrijfactie. |
Banken
Tools
| banks_get | Haal één bank op via id — de instelling, niet een rekening die daar wordt aangehouden. Gebruik bankAccounts_get voor de rekening. |
| banks_list | Lijst van de banken waarbij de rekeningen van de organisatie worden aangehouden. Verborgen banken worden standaard MEEGENOMEN — geef hidden=false op voor de weergave van de keuzelijsten, of hidden=true om de uitgefaseerde te vinden. Gebruik dit om de bank-id te achterhalen waarop bankAccounts_list filtert en die bankAccounts_create nodig heeft. |
| banks_create | Maak een bank aan — de instelling waartoe een bankrekening behoort, niet de rekening zelf (dat is bankAccounts_create). Schrijven. |
| banks_update | Werk een bank bij via id. Dit is ook de manier waarop een bank wordt verborgen en weer zichtbaar gemaakt: zet `hidden` op true om er een uit de keuzelijsten te halen zonder deze te verwijderen, op false om hem weer terug te brengen. Er is geen aparte archiveertool omdat de API geen archiveeractie heeft voor een bank — de flag is het mechanisme. Schrijven. |
Budgetten
Tools
| budgets_employeePnl | Winst-en-verliesrekening per werknemer voor een budget — wat de tijd van elke persoon opleverde tegenover wat die kostte. Vereist ROLE_BUDGETS_VIEWER. Alleen-lezen. |
| budgets_get | Haal één budget op via id — de periode, scope en instellingen. Vereist ROLE_BUDGETS_VIEWER. Alleen-lezen. |
| budgets_list | Lijst van de budgetten van de organisatie — de periodes waartegen inkomsten en kosten worden gepland en vergeleken. Gebruik dit om de budget-id te achterhalen die elke pnl-tool nodig heeft. Vereist ROLE_BUDGETS_VIEWER. Alleen-lezen. |
| budgets_pnlByTags | Winst-en-verliesrekening voor een budget, uitgesplitst PER TAG — income, costsByTag, costsByProject en netByTag over de periodes van het budget. De tag-as is wat dit leesbaar maakt voor een bedrijf waarvan de kosten niet van nature per project lopen: tag de documenten, en de splitsing volgt vanzelf. Bevat displayPricePerSqm wanneer de organisatie price-per-sqm heeft ingeschakeld en een oppervlakteattribuut heeft benoemd, wat hiervan een weergave per vierkante meter maakt voor een projectontwikkelaar. Vereist ROLE_BUDGETS_VIEWER. Alleen-lezen. |
| budgets_pnlByTagsDrilldown | De documenten achter één cel van budgets_pnlByTags. Gebruik dit wanneer een tag-totaal er verkeerd uitziet — het noemt de transacties waaruit het getal is opgebouwd in plaats van je te laten gissen. Vereist ROLE_BUDGETS_VIEWER. Alleen-lezen. |
Klanten
Tools
| clients_get | Haal één klant op via id — naam, land, valuta, belastingnummer en status. |
| clients_list | Lijst met klanten (de klanten van de organisatie). Filter op status, of op externalPaymentCustomerId om de klant achter een betaalprovider-id te vinden. Gebruik dit om de client-id op te lossen waarop invoices_list, deals_list, projects_list en contracts_list allemaal filteren. |
| clients_import | Laad VEEL clients in één aanroep, met `externalRef` als sleutel — de tool om een klanten- of koperslijst vanuit een ander systeem over te zetten, waar clients_create één round trip per persoon zou zijn. Rijen worden verzoend met de organisatie: een onbekende externalRef maakt aan, een bekende werkt ter plekke bij, een identieke rij wordt overgeslagen, dus opnieuw uitvoeren verandert niets. De ref wordt opgeslagen als `externalPaymentCustomerId`, de enige kolom voor externe referenties die een client heeft, en `clients_list` filtert erop. MATCH CLIENTS NIET OP NAAM — een koperslijst zit vol gedeelde achternamen en gezamenlijke aankopen. Elk resultaat bevat `counterpartyId`, wat contracts_import en contracts_create nodig hebben. Twee valkuilen die het schema niet kan uitdrukken: een `tin` wordt GEWEIGERD zonder `tinCountry`, en een contactrij heeft een e-mailadres nodig, dus een telefoonnummer alleen kan er geen aanmaken. GEEF EERST dryRun:true MEE bij een echte onboarding-load. Max 500 rijen. Vereist ROLE_CLIENTS_MANAGER. Schrijven. |
| clients_create | Maak een nieuwe klant aan (name, country, currency, status, tinType verplicht). Schrijfactie. |
| clients_update | Werk een klant bij via id. Schrijfactie. |
Configuratiesleutels
Tools
| configKeys_catalog | Lijst met elke organisatie-configsleutel die de backend herkent, met het type en de toegestane waarden. Dit is de catalogus van wat configureerbaar is — lees dit voor configs_get of configs_update in plaats van een sleutelnaam te raden. Rechten worden per sleutel afgedwongen door de backend, dus het feit dat een sleutel hier verschijnt garandeert niet dat de verbonden gebruiker deze mag schrijven. |
Configuraties
Tools
| configs_get | Lees één organisatie-configwaarde op id, waarbij de id een sleutel is uit configKeys_catalog (bijv. organization-logo-url, organization-icon-url). |
| configs_update | Werk een organisatieconfiguratiewaarde bij via id (type + name verplicht; rechten worden per configuratiesleutel afgedwongen door de backend). Schrijfactie. |
Contracten
Tools
| contracts_get | Haal één contract op via id — partijen, richting, waarde, cyclische voorwaarden en data. |
| contracts_list | Lijst van contracten. Filter op direction — de opgeslagen waarden zijn "out" (wij verkopen / uitgeven) en "in" (wij kopen / ontvangen), plus "unknown" — een echte, filterbare status en geen fout. Een contract dat is aangemaakt door een document te uploaden begint als "unknown" en blijft dat totdat extractie of een persoon het afhandelt, dus laat het filter weg om alle drie te krijgen: "in" en "out" apart opgevraagd tellen NIET op tot de volledige set (flowtly-mcp#130). NIET "outgoing"/"incoming": die matchen niets en komen terug als een lege lijst in plaats van een fout. Filtert ook op counterparty, project, cyclic, name of tags. Gebruik dit om de contract-id te achterhalen die contracts_paymentScheduleLines leest en waaraan deals_win een gewonnen deal kan koppelen. |
| contracts_paymentScheduleLines | Lijst van het betalingsschema van een contract — de termijnen waarin het naar verwachting wordt gefactureerd of betaald. Geef contractId mee vanuit contracts_list. Dit is het plan, niet de werkelijke cijfers: vergelijk het met transactions_list om te zien wat er daadwerkelijk is betaald. Het bedrag van elke regel staat in KLEINSTE EENHEDEN — grosze, niet złoty: "530000" is 5.300,00, dus deel door 100 voordat je een bedrag aan iemand rapporteert. |
| contracts_import | Laad VEEL contracten in één aanroep, met `name` als sleutel — het overeenkomstnummer. In tegenstelling tot een client of asset heeft een contract GEEN kolom voor externe referenties, dus de name IS de idempotentiesleutel; een batch die dezelfde name twee keer bevat wordt IN ZIJN GEHEEL GEWEIGERD in plaats van één contract twee keer bij te werken, omdat een dubbel nummer betekent dat de bron fout is. `counterpartyExternalRef` lost de koper op via dezelfde ref die aan clients_import is meegegeven, zodat de twee op elkaar aansluiten: importeer eerst de clients, dan de contracten, zonder ooit een numerieke counterparty-id te hoeven verwerken — een ref die met geen enkele client matcht, laat die rij falen in plaats van een contract zonder partij aan te maken. `direction` is "out" (wij verkopen) of "in" (wij kopen); de kolom heeft geen server-side beperking, dus een verkeerd woord wordt opgeslagen en het contract matcht daarna nergens meer een filter. GEEF EERST dryRun:true MEE. Max 500 rijen. Vereist ROLE_CONTRACTS_MANAGER. Schrijven. |
| contracts_create | Maak een contract aan. Schrijfactie. |
| contracts_update | Werk een contract bij via id. Schrijfactie. |
| contracts_delete | Verwijder een contract via id. Schrijfactie. |
Kostenplaatsen
Tools
| costGroups_list | Lijst met kostengroepen / kostenplaatsen — de categorieën waaronder kosten, leveranciers en inkomende facturen worden ingedeeld. Gebruik dit om de costGroup-id op te lossen die suppliers_create vereist en die suggesties voor inkomende facturen voorstellen. |
| costGroups_create | Maak een kostenplaats aan (name + type verplicht). Schrijfactie. |
| costGroups_update | Werk de naam of het type van een kostenplaats bij via id. Schrijfactie. |
Tegenpartijen
Tools
| counterparties_get | Haal één tegenpartij op via id. |
| counterparties_list | Toon tegenpartijen — elke partij waarmee de organisatie transacties heeft. De vlaggen supplier en client geven aan welke rol(len) een tegenpartij speelt, en één record kan beide zijn. Dit is de partij op een banktransactie, dus hier worden inkomende facturen en transacties tegen gematcht. Filter op type, supplier, client, cyclic of budgetNeutral. |
CRM-notities
Tools
| crmNotes_get | Haal één CRM-notitie op via id. |
| crmNotes_list | Toon notities geschreven bij leads en deals. Filter op lead of deal om de lopende commentaartrail van één record te lezen. |
| crmNotes_create | Voeg een notitie toe aan een lead of een deal (body + precies één van lead/deal). De auteur is de verbonden gebruiker. Schrijfactie. |
| crmNotes_update | Werk de inhoud van een CRM-notitie bij via id. Schrijfactie. |
| crmNotes_delete | Verwijder een CRM-notitie via id. Schrijfactie. |
Redenen verloren deal
Tools
| dealLostReasons_get | Haal één reden voor een verloren deal op via id. |
| dealLostReasons_list | Lijst met redenen waarom een deal als verloren kan worden gemarkeerd, in volgorde. deals_lose vereist een lostReasonId van hier. |
Deals
Tools
| deals_get | Haal één deal op via id — titel, klant, fase, bedrag, eigenaar, contact, verwachte en werkelijke afsluitdatum. |
| deals_list | Toon deals/opportunities — de salespipeline. Filter op status (open / won / lost), fase, eigenaar, klant, lead, of op periodes voor expectedCloseDate / closedAt. Bedragen zijn in kleinste eenheid met een expliciete valuta; ga niet uit van de standaardvaluta van de organisatie. |
| deals_create | Maak een deal/opportunity aan. Verplicht: title, stage (uit stages_list), en een ANKER — minstens één van client of lead. Een deal met geen van beide wordt geweigerd met 422 "A deal must reference a client or a lead.", dus anker een prospect waarvoor je nog geen klantrecord hebt aan diens lead (`/leads/<id>` uit leads_list) in plaats van een client te verzinnen; geef client mee (`/clients/<id>` uit clients_list) zodra die er is. Beide instellen is toegestaan. Optioneel: amountMinor, currency, expectedCloseDate, owner, contact. Direct aanmaken in een won-stage vereist bovendien client — een deal met alleen een lead kan niet worden gewonnen. Schrijven. |
| deals_update | Werk een deal bij via id (title, stage, amountMinor, currency, expectedCloseDate, owner, contact, client, lead). Het wijzigen van de stage wordt automatisch gelogd. De ankerregel uit deals_create blijft van toepassing op het resultaat, dus je kunt de enige client of lead van een deal niet wissen — wissel er eerst een in. Een deal naar een won-stage verplaatsen vereist client: koppel hier de klant (of voer leads_convert uit) voordat je een deal met alleen een lead wint. Schrijven. |
| deals_delete | Verwijder een deal via id (soft delete). Schrijfactie. |
| deals_win | Markeer een deal als gewonnen — verplaatst deze naar een won-stage en stempelt hem gesloten; optionele contractId koppelt een bestaand contract. EEN HISTORISCHE WIN TERUGVULLEN: geef optioneel closedAt mee (ISO-8601, bijv. "2026-05-07" of een volledige timestamp) om de datum vast te leggen waarop de deal DAADWERKELIJK is gesloten. Laat je dit weg, dan stempelt de server nu, wat een oude deal in het "gewonnen deze maand"-cijfer van deze maand plaatst — stel het dus in wanneer je een deal invoert die vóór vandaag is gesloten. Het mag niet in de toekomst liggen (422), en het MAG eerder liggen dan de eigen createdAt van de deal: een deal die vandaag is aangemaakt en in mei is gesloten, is de normale vorm van een correcte terugvulling, geen fout. De deal moet AL een client hebben: het winnen van een deal met alleen een lead wordt geweigerd met 422 "Attach a customer before marking this deal Won.", omdat er geen klant is om te factureren. Zet de lead om in een client met leads_convert, of stel client in met deals_update, en win dan pas. Schrijven. |
| deals_lose | Markeer een deal als verloren — vereist lostReasonId (uit dealLostReasons_list); optioneel lostReasonNote. EEN HISTORISCH VERLIES TERUGVULLEN: geef optioneel closedAt mee (ISO-8601) om de datum vast te leggen waarop de deal DAADWERKELIJK is gesloten, precies zoals deals_win dat doet. Laat je dit weg, dan stempelt de server nu. Het mag niet in de toekomst liggen (422), en mag eerder liggen dan de createdAt van de deal. Schrijven. |
| deals_reopen | Heropen een gewonnen/verloren deal terug naar open. Schrijfactie. |
Fasegeschiedenissen deal
Tools
| dealStageHistories_get | Haal één fasewijziging van een deal op via id. |
| dealStageHistories_list | Lijst met fase-overgangen van een deal, nieuwste eerst. Filter op deal. Elke deals_update die de fase wijzigt, wordt hier automatisch gelogd, zodat je hiermee kunt reconstrueren hoe lang een deal in elke fase heeft gezeten — de deal zelf bevat alleen de huidige fase. |
Afdelingen
Tools
| departments_list | De afdelingen van de organisatie, met de numerieke id waarmee elke afdeling wordt aangeduid. LEES DIT VOORDAT je people_create of people_update AANROEPT: beide accepteren een `department`-IRI en er is geen andere manier om een geldige te achterhalen. De collectie is niet gepagineerd en gesorteerd op name, dus één aanroep geeft alle afdelingen van de organisatie terug. Filter op `name` (gedeeltelijke match) of `code` (exact). Rijen bevatten id, name en code; `manager` is een relatie en zit niet in de lijstrijen — lees deze met people_list vanaf de andere kant als je hem nodig hebt. Vereist ROLE_EMPLOYEES_VIEWER. Alleen-lezen. |
| departments_create | Voeg een afdeling toe, zodat mensen eronder kunnen worden ingedeeld. `name` is verplicht (tot 128 tekens) en is UNIEK binnen de organisatie; `code` is optioneel (tot 64) en is EVENEENS uniek — de korte vorm die een organisatie al in haar eigen spreadsheets gebruikt (CEO, TECH, PROC). `manager` is een optionele employee-IRI vanuit people_list. EERST LIJSTEN EN BOTSINGEN VERWACHTEN: omdat zowel name als code uniek zijn, MISLUKT het opnieuw posten van een afdeling die al bestaat in plaats van idempotent te zijn, dus een import die uitgaat van create-per-rij loopt vast zodra deze een afdeling tegenkomt die de organisatie al heeft — meestal een overblijfsel van een proefperiode. Verzoen die rij met departments_update in plaats van eromheen aan te maken. ER IS GEEN DELETE: de backend biedt geen delete voor een afdeling, dus een verkeerde name of code wordt ter plekke gecorrigeerd met departments_update en nooit verwijderd. Vereist ROLE_EMPLOYEES_MANAGER. Schrijven. |
| departments_update | Hernoem een afdeling, geef deze een code, of stel de manager in. Dit is de tool die een afdelingsimport mogelijk maakt in plaats van slechts handig: `name` en `code` zijn beide uniek, dus een afdeling die de organisatie al heeft — de ene "HR"-rij die een proof-of-concept vaak achterlaat — kan niet opnieuw worden aangemaakt, en de echte lijst wordt bereikt door die rij te CORRIGEREN in plaats van ermee te botsen. Alleen de velden die je meestuurt veranderen, dus het alleen meesturen van `code` laat de naam intact. `id` is de numerieke id vanuit departments_list; `manager` is een employee-IRI vanuit people_list. ER IS GEEN DELETE, wat dit het complete herstelverhaal maakt: een afdeling die met een typfout is aangemaakt wordt hier gerepareerd, en een die niet zou moeten bestaan kan alleen worden hernoemd, niet verwijderd. Vereist ROLE_EMPLOYEES_MANAGER. Schrijven. |
Verlofdagenlimieten
Tools
| holidayDaysLimits_get | Eén verlofrecht-rij via id — het amount, het type, de contractvariant en de datum waarop deze ingaat. holidayDaysLimits_list vindt de id. Bedragen staan in SECONDEN (#3763). Alleen-lezen. |
| holidayDaysLimits_list | Hoeveel verlof elke persoon per type TOEKOMT — niet hoeveel er is opgenomen, dat is holidays_list. Filter op employee. Een persoon kan in de loop van de tijd meerdere rijen voor één type hebben, omdat een saldo wordt aangevuld of gecorrigeerd: de GELDENDE rij is die met de meest recente dateFrom die al is aangebroken, en rijen met een datum in de toekomst worden tot dan toe bewust genegeerd. Bedragen staan in SECONDEN (#3763) — een verlofdag van 8 uur is 28800. Vereist ROLE_HOLIDAYS_MANAGER. Alleen-lezen. |
| holidayDaysLimits_create | Geef een persoon een tegoed van één verloftype, ingaand vanaf een datum. `seconds`, NIET dagen (#3763): een dag van 8 uur is 28800, dus 21 dagen is 604800 en een overurensaldo van 2u30 is 9000 — een getal dat nergens naartoe kon toen dit in hele dagen werd opgeslagen. `employee` en `holidayType` zijn IRIs (geleverd door people_list en holidayTypes_list); `variant` is het contracttype waartoe het tegoed behoort (uop, b2b, uz, uod). Om een bestaand saldo te CORRIGEREN, voeg je een rij toe met een latere dateFrom in plaats van de oude te bewerken — de geldende rij is de meest recente waarvan de dateFrom is aangebroken, zodat de geschiedenis intact blijft en een correctie kan worden ingevoerd voordat deze van kracht wordt. (employee, holidayType, variant, dateFrom) is uniek, dus het opnieuw posten van dezelfde dag vervangt niets en mislukt. Vereist ROLE_HOLIDAYS_MANAGER. Schrijven. |
| holidayDaysLimits_update | Corrigeer een rij die verkeerd is ingevoerd — een typfout in het bedrag, de verkeerde variant. Bedragen staan in SECONDEN (#3763). Dit is NIET hoe je registreert dat een saldo in de loop van de tijd VERANDERT: gebruik daarvoor holidayDaysLimits_create om een nieuwe rij met een latere dateFrom aan te maken, wat bewaart wat het vorige saldo was en wanneer. Ter plekke bewerken herschrijft de geschiedenis en maakt het oude cijfer onherstelbaar. holidayDaysLimits_list vindt de id. Vereist ROLE_HOLIDAYS_MANAGER. Schrijven. |
Verlofaanvragen
Tools
| holidayRequests_list | Verlof-AANVRAGEN en hun status — in behandeling, goedgekeurd, afgewezen. Anders dan holidays_list, dat geboekt verlof is: een aanvraag die nog op een beslissing wacht, is nog geen afwezigheid, dus plan op basis van holidays_list en gebruik dit om te zien wat er nog op iemand wacht. Levert de holidayRequestId die holidays_approve en holidays_bulkApprove nodig hebben. Alleen-lezen. |
| holidayRequests_cancel | Annuleer een verlofaanvraag — gebruik dit om een aanvraag op te ruimen waarop nooit actie mag worden ondernomen, zoals een rij die is achtergebleven van een proefperiode, een test, of iemand die is vertrokken. TWEE DINGEN DIE MENSEN VERRASSEN. (1) DIT VERWIJDERT DE RIJ NIET: de backend zet status op `canceled` in plaats van de rij te verwijderen. MAAR EEN GEANNULEERDE AANVRAAG VERDWIJNT UIT holidayRequests_list — geverifieerd in productie: daarna geeft noch de ongefilterde lijst, noch status=canceled deze terug. Je kunt dus niet terug uitlezen wat je hebt geannuleerd en er is geen undo via de MCP; wees zeker van de id voordat je dit aanroept. (2) DIT IS NIET HETZELFDE ALS AFWIJZEN. Afwijzen legt een beslissing vast — het schrijft een goedkeuringslog-item met jouw naam en MAILT DE WERKNEMER dat het verlof is geweigerd — terwijl annuleren alleen HR informeert, en alleen wanneer `notify-hr-managers-of-leave-activity` voor de organisatie aan staat. Voor een rij die nooit een echte aanvraag was, is annuleren de eerlijkere en stillere optie. WERKT ALLEEN OP EEN IN BEHANDELING ZIJNDE (`requested`) AANVRAAG wanneer je niet de eigenaar bent: een geaccepteerde aanvraag heeft al een Holiday opgeleverd die dit niet verwijdert, dus het annuleren ervan zou een geboekte afwezigheid achterlaten achter een aanvraag met status `canceled`. Vereist ROLE_HOLIDAYS_MANAGER voor iemand anders' aanvraag; de aanvrager kan zijn eigen aanvraag altijd annuleren. holidayRequests_list levert de id. Schrijven. |
Vakantiedagen
Tools
| holidays_active | Wie er NU vrij is — elk verlof dat momenteel loopt, organisatiebreed, voor iedereen. Dit is de tool voor 'wie is er vandaag afwezig', en degene om te controleren voordat je resourcingBench_get's freePercent als beschikbaarheid beschouwt, omdat de bench geen verlof aftrekt. In tegenstelling tot holidays_list past dit geen projectafbakening toe en is er geen andere rechten nodig dan ingelogd zijn, dus het antwoord dekt de hele organisatie. Geeft elke afwezigheid terug met het type en de datums. Alleen-lezen. |
| holidays_get | Eén verlofrecord op id, met het type, de datums en de duur. Haal de id op uit holidays_list of holidays_active. Alleen-lezen. |
| holidays_list | Geboekt verlof over een periode — de planningsweergave, waarbij holidays_active alleen iets zegt over vandaag. Filter op werknemer, op datumbereik of op project. WAT JE ZIET HANGT AF VAN JE RECHTEN, en een korte lijst is geen bewijs dat niemand vrij is: een verlofbeheerder of accountancy-viewer krijgt de hele organisatie te zien, terwijl een projectleider of -viewer VERPLICHT een projectfilter moet meegeven (of naar zichzelf moet vragen) en zonder filter volledig wordt geweigerd — die weigering is een rechtengrens, geen lege kalender. Alleen-lezen. |
| holidays_create | Registreer verlof dat een persoon daadwerkelijk opneemt — de geboekte afwezigheid zelf, niet het recht (holidayDaysLimits_create) en niet een aanvraag in behandeling (verlofaanvragen, die nog goedgekeurd moeten worden). Wat dit schrijft is al overeengekomen vrije tijd, dus het verschijnt direct in holidays_list en heeft geen goedkeuringsstap nodig. `employee` is een IRI vanuit people_list; `type` is een holidayTypes_list-id. `dateFrom`/`dateTo` inclusief, en één aanroep dekt een hele periode in plaats van een rij per dag. Twee dingen bijten: een type waarvan `descriptionRequired` true is (lees eerst holidayTypes_list — `vacations` is dat vaak) WEIGERT een create zonder `description`; en `pick-up-day` is al verschuldigde tijd, dus dit verbruikt NIET het jaarlijkse tegoed zoals `vacations` dat doet — een dag die is teruggegeven voor een zaterdagse feestdag registreren als `vacations` vreet stilzwijgend een dag van iemands recht op. Controleer holidays_list voor dezelfde persoon en datums voordat je aanmaakt, want een overlap wordt GEWEIGERD, niet gedupliceerd: de backend geeft `validation_holiday_dates_overlap` terug als een 422 op `dateTo` wanneer de periode een dag raakt die al door een andere afwezigheid van die persoon wordt gedekt. De enige uitzondering is smal — twee afwezigheden van ÉÉN DAG voor een deel van de dag op dezelfde datum, van VERSCHILLENDE types, beide `vacations` of `pick-up-day`, waarvan de uren samen binnen de werkdag passen. Al het andere dat overlapt faalt. Er IS een holidays_update, dus het wijzigen van het type van een afwezigheid vereist niet langer eerst verwijderen en dan opnieuw aanmaken. ELKE CREATE MAILT DE WERKNEMER, op het eigen bedrijfsadres, om te melden dat de afwezigheid is toegevoegd — dus het laden van een jaar geschiedenis die iemand al heeft meegemaakt komt rij voor rij in hun inbox terecht, en voor medewerkers die nog niet zijn uitgenodigd, is het de allereerste keer dat ze van Flowtly horen. EEN JAAR GESCHIEDENIS LADEN? Er bestaat een bulkvariant — holidays_import verzoent tot 500 afwezigheden in één aanroep, slaat de al geregistreerde over zodat opnieuw uitvoeren veilig is, en zet de mail standaard UIT — maar DEZE IS NIET BESCHIKBAAR OP DEZE VERBINDING: hij wordt alleen aan de internal scope aangeboden, dus je kunt hem hier niet aanroepen en ernaar zoeken zal hem niet vinden. Roep deze tool in een lus aan, of vraag je Flowtly-operator om de bulklading uit te voeren. Geef `notify: false` mee voor een BACKFILL van afwezigheden die al hebben plaatsgevonden; laat het ongemoeid bij het vastleggen van iets nieuws, want dan is de mail juist de bedoeling. Het onderdrukt alleen het bericht — de rij, de `createdAt` en het payrollgegeven worden hoe dan ook geschreven. Vereist ROLE_HOLIDAYS_MANAGER. Schrijven. |
| holidays_delete | Verwijder een geboekte afwezigheid volledig — de rij wordt verwijderd, in tegenstelling tot holidayRequests_cancel dat alleen de status van een aanvraag omzet. Gebruik dit om afwezigheden op te ruimen die nooit hadden moeten meetellen: demo- of testrijen die van een proefperiode zijn achtergebleven, of rijen die verweesd zijn geraakt toen hun werknemer werd verwijderd (people_delete koppelt afwezigheden los in plaats van ze te verwijderen, dus ze blijven bestaan met een lege employee-naam). DIT VERANDERT ECHTE CIJFERS: een geboekte afwezigheid is `payrollEligible` en verbruikt het recht van de persoon, dus het verwijderen ervan wijzigt zijn verlofsaldo — precies de bedoeling bij het opruimen van testdata, en een dataverliesbug wanneer de rij echt was. Geen undo, geen melding. Lees eerst holidays_list en wees er zeker van dat de rij geen echte geschiedenis is: een description in de eigen taal van de organisatie, of datums die overeenkomen met een daadwerkelijke afwezigheid, betekenen doorgaans van wel. Vereist ROLE_HOLIDAYS_MANAGER. Schrijven. |
Verloftypen
Tools
| holidayTypes_list | De verloftypes die deze organisatie gebruikt, met de id waarmee elk type wordt aangeduid. Lees dit voor holidayDaysLimits_create/update, die een holidayType-IRI nodig hebben en anders geraden zou moeten worden. Het type dat geen verlof is in de gewone zin is `pick-up-day` — vrije tijd verschuldigd voor reeds gewerkte overuren (Pools *odbior nadgodzin*), wat een TOEGEKEND saldo is in plaats van een jaarlijks recht. Alleen-lezen. |
| holidayTypes_create | Voeg een verloftype toe dat de organisatie nog niet aanbiedt — een sabbatical, onbetaald ouderschapsverlof, een trainingsdag — zodat afwezigheden ertegen kunnen worden geboekt met holidays_create en een tegoed kan worden toegekend met holidayDaysLimits_create. `name` (3–64 tekens) is wat mensen kiezen bij het boeken; `color` en `icon` bepalen hoe het in de kalender oogt; `reducesWorkingTime` false markeert vrije tijd die het verwachte aantal uren van de maand NIET verlaagt; en `descriptionRequired` true zorgt dat het type een reden vereist, wat holidays_create vervolgens afdwingt — zie die tool voor wat er wordt geweigerd. `status` staat standaard op `active`, dus een type dat zonder nadenken wordt aangemaakt, wordt direct aan iedereen aangeboden. LEES EERST holidayTypes_list: types gelden organisatiebreed, en ER IS GEEN DELETE — een duplicaat of verkeerd gespelde naam kan alleen weer worden verborgen door status op inactive te zetten met holidayTypes_update, en het type houdt intussen elke afwezigheid die ertegen is geboekt vast. Vereist ROLE_HOLIDAYS_MANAGER. Schrijven. |
| holidayTypes_update | Wijzig een verloftype, en vooral: ZET ER EEN WEER AAN. `status` wisselt tussen `active` en `inactive`, en een inactive type wordt geweigerd door holidays_create — dus het registreren van historisch verlof tegen een type dat de organisatie inmiddels heeft uitgefaseerd begint hier, en dit is wat een verlofhistorie-import ontgrendelt in plaats van iemand de app-UI in te sturen. DEACTIVEREN IS GEEN VERWIJDEREN, en er is geen delete: al geboekte afwezigheden houden een inactive type en lezen daar nog steeds mee in holidays_list, dus inactive betekent alleen 'niet aangeboden voor nieuwe boekingen'. DE VALKUIL DIE HIERUIT VOLGT: reactiveer `vacations` om de afwezigheden van vorig jaar te laden, vergeet dit terug te zetten naar `inactive`, en je hebt niet slechts een import afgerond — je hebt veranderd wat de organisatie vandaag aanbiedt, want elke werknemer die verlof boekt ziet dat type nu weer op de lijst staan. Zet het terug binnen dezelfde sessie waarin je hebt geïmporteerd. `descriptionRequired` grijpt ook in op holidays_create, dat een boeking zonder description weigert zodra dit aan staat; het aanzetten laat reeds vastgelegde afwezigheden ongemoeid. `id` is de string-id uit holidayTypes_list (`vacations`, `not-paid`), en alleen de velden die je meestuurt veranderen. Vereist ROLE_HOLIDAYS_MANAGER. Schrijven. |
Inkomende facturen
Tools
| incomingInvoices_get | Haal één inkomende (leveranciers)factuur of ondersteunend document op via id, met de OCR-velden en huidige matchstatus. |
| incomingInvoices_list | Lijst met inkomende (leveranciers)facturen en onderliggende documenten — de accountancy-inbox. Een inkomende factuur IS een document dat aan een banktransactie is gekoppeld, dus exists.transaction=false is de manier om documenten te vinden die nog niet aan een betaling zijn gekoppeld. Filter ook op status, relatedMonth, tegenpartij, project, labels of hasDetectedProblems. Elk document krijgt een vingerafdruk als externalId 'upload_sha256:<sha256 van de bytes>' — hash een bestand en zoek hier naar die externalId VOORDAT je incomingInvoices_create gebruikt, anders leg je een duplicaat vast. |
| incomingInvoices_matchCandidates | Toon de banktransacties die de betaling voor deze inkomende factuur zouden kunnen zijn, gerangschikt door de eigen matcher van de backend. Gebruik dit wanneer een document nog geen gekoppelde transactie heeft en je er zelf één moet kiezen; geef de voorkeur aan deze kandidaten boven zelf gokken op basis van bedragen. |
| incomingInvoices_suggestions | Lees Flowtly's eigen voorstellen voor een inkomende factuur — leveranciersmatch, kostengroep, bijpassende banktransactie, duplicaatwaarschuwing. Dit zijn precies de voorstellen die een mens in de app ziet. Lees ze eerst en pas er dan één toe op id met incomingInvoices_applySuggestion, of neem ze allemaal over met acceptAllSuggestions. Geef refresh mee om opnieuw te berekenen in plaats van de gecachete set te leveren. |
| incomingInvoices_suggestionsDebug | Leg uit WAAROM de suggesties van een inkomende factuur zo zijn uitgekomen — de scoring van de matcher, om een ontbrekende of foutieve suggestie te diagnosticeren. Alleen diagnostisch; gebruik incomingInvoices_suggestions voor normaal werk. |
| incomingInvoices_create | Leg een inkomende (leveranciers)factuur of onderliggend document vast in de boekhouding — geef de bytes als base64 mee met een fileName en receivedAt. Flowtly voert er OCR op uit en stelt een leverancier en een bijpassende banktransactie voor. Het bestand krijgt een vingerafdruk als externalId 'upload_sha256:<sha256 van de bytes>': om een duplicaat te vermijden, hash de bytes en controleer incomingInvoices_list op die externalId VOORDAT je uploadt. Schrijfactie. |
| incomingInvoices_applySuggestion | Accepteer een van Flowtly's eigen suggesties voor een inkomende factuur — dezelfde voorstellen die een mens in de app ziet (leveranciersmatch, kostengroep, bijpassende banktransactie, duplicaatwaarschuwing). Lees ze eerst met incomingInvoices_suggestions en pas er dan één toe op basis van de id. Geef hier de voorkeur aan boven gokken: Flowtly's matcher, niet de agent, bepaalt wat aannemelijk is. Schrijfactie. |
| incomingInvoices_acceptAllSuggestions | Accepteer alle openstaande suggesties bij een inkomende factuur in één aanroep — wat een gebruiker doet met de "alles accepteren"-knop in de app. De server past toe, herberekent en past opnieuw toe totdat er niets nieuws meer verschijnt: de transactiematch bestaat pas zodra de leverancier en het bedrag zijn toegepast, dus één enkele ronde zou het document ongekoppeld achterlaten. Geeft een rapport terug (wat is toegepast, wat is geweigerd en waarom, en tegen welke transactie het document uiteindelijk is geboekt). Geef dryRun mee om te previewen zonder te schrijven. Accepteert nooit supplier_create of een duplicaatwaarschuwing. Schrijfactie. |
| incomingInvoices_checkEInvoices | Haal nieuwe KSeF e-facturen op in de organisatie — wat de knop "Sprawdź e-faktury" in de app doet. Roep dit aan voordat je concludeert dat een factuur van een leverancier ontbreekt: zonder dit kun je "de leverancier heeft hem nooit verstuurd" niet onderscheiden van "onze sync is nog niet uitgevoerd". Geeft een resultaat zodra het ophalen in de wachtrij staat; lees incomingInvoices_list daarna opnieuw om te zien wat er is binnengekomen. Schrijfactie. |
Initiële budgetposten
Tools
| initialBudgetItems_list | Lijst van initiële-budgetregels — de geplande bedragen, per tag, waartegen contractComparison wordt teruggegeven. Vereist ROLE_BUDGETS_VIEWER. Alleen-lezen. |
Initiële budgetten
Tools
| initialBudgets_contractComparison | GEPLAND versus GECONTRACTEERD, per tag — de geplande bedragen van het initiële budget tegenover de som van de contractwaarden die daadwerkelijk voor dat project zijn getekend. Dit is de vraag 'hebben we meer toegezegd dan we hebben begroot, en waar', en dit leest direct af van de contracten die al in de organisatie staan, zodat het importeren van contracten dit beantwoordbaar maakt zonder verder werk. Bedragen zijn in grosze; een project met gemengde valuta levert een melding op in plaats van een stilzwijgend onjuist totaal. Vereist ROLE_BUDGETS_VIEWER. Alleen-lezen. |
| initialBudgets_get | Haal één initieel budget op via id, met de bijbehorende regels. Vereist ROLE_BUDGETS_VIEWER. Alleen-lezen. |
| initialBudgets_list | Lijst van initiële budgetten — het OORSPRONKELIJKE plan voor een project of investering, in tegenstelling tot het actuele budget waartegen het wordt afgemeten. Vereist ROLE_BUDGETS_VIEWER. Alleen-lezen. |
Facturen
Tools
| invoices_get | Haal één uitgaande (verkoop)factuur op via id — klant, factuurregels, totalen, verkoop- en uitgiftedatum, status. |
| invoices_list | Lijst met uitgaande (verkoop)facturen. Filter op klant, labels, zoekterm of een saleDate-bereik. Let op: saleDate — niet de uitgiftedatum en niet de aanmaakdatum — is het veld waarop invoices_export filtert, gebruik dus hetzelfde veld hier bij het controleren van een export. |
| invoices_export | Start een zip-export van UITGEGEVEN facturen voor een periode (from/to, beide YYYY-MM-DD, inclusief) gefilterd op VERKOOPDATUM — niet de uitgifte- of aanmaakdatum. Alleen UITGEGEVEN facturen worden meegenomen; concepten en niet-verzonden facturen worden uitgesloten, maar correcties WORDEN meegenomen. Optioneel client beperkt tot één klant (id of IRI uit clients_list). Max 200 facturen per export — als de periode er meer bevat, maak deze dan kleiner (bijv. exporteer per maand); een periode met 0 uitgegeven facturen wordt ook geweigerd. Deze aanroep zet de taak alleen in de wachtrij (het renderen van een maand kan minuten duren) — er wordt GEEN downloadlink teruggegeven. Poll invoices_exportStatus met de teruggegeven exportId totdat deze "ready" meldt. Schrijfactie. |
| invoices_exportStatus | Poll de status van een zip-export gestart door invoices_export, op exportId. Zodra status "ready" is, bevat de respons downloadUrl (een kortstondige, ondertekende link — verloopt na 1 uur, zie expiresAt), filename en byteSize; de bytes van het bestand worden nooit via deze tool teruggegeven. Als status "failed" is, verklaart failureReason waarom. |
| invoices_import | Leg een AL UITGEGEVEN uitgaande (verkoop)factuur vast in de organisatie — voor het inbrengen van factuurhistorie bij onboarding. Het externe factuurnummer dat je meegeeft wordt letterlijk bewaard, de koper wordt opgelost op basis van het belastingnummer (aangemaakt indien afwezig), en de factuur landt als uitgegeven ZONDER een PDF te renderen, de client te mailen, of dit bij KSeF in te dienen. Het importeren van een nummer dat al bestaat is een no-op die de bestaande factuur terugrapporteert, dus een bulkimport is veilig om opnieuw uit te voeren — maar die garantie geldt alleen voor sequentiële aanroepen; twee daadwerkelijk gelijktijdige imports van hetzelfde nummer kunnen beide landen. Geef expectedGrossTotal mee (het brutobedrag zoals afgedrukt op het brondocument) en de import wordt geweigerd als dit afwijkt van het totaal dat uit de regels wordt berekend. buyer.tin is verplicht — de koper wordt nooit op naam gematcht. Gebruik invoices_create, niet dit, om een echte nieuwe factuur op te stellen. Schrijven. Geef dryRun:true mee om te PREVIEWEN zonder te schrijven — het rapporteert would-create / would-skip en maakt geen factuur en geen client aan; voer een historische terugvulling eerst droog uit en controleer de aantallen voordat je hem echt uitvoert. |
| invoices_create | Stel een NIEUWE uitgaande (verkoop)factuur op — de tool om een client voor het eerst te factureren. Verwar dit niet met de twee buren: invoices_import legt met terugwerkende kracht een factuur vast die AL elders is uitgegeven (onboardinghistorie), en incomingInvoices_create legt het kostendocument van een leverancier vast. De factuur landt ONVERZONDEN: status wordt afgeleid uit de logregels van de factuur en een nieuwe factuur heeft er geen, dus door deze aanroep wordt niets gerenderd, gemaild, of bij KSeF ingediend — behandel het resultaat als een concept dat vóór uitgifte wordt gecontroleerd. `name` is het factuurnummer en mag je zelf kiezen (max 32 tekens) — lees eerst invoices_list en volg de bestaande reeks van de organisatie in plaats van er zelf een te verzinnen, want niets hier wijst automatisch het volgende nummer toe. Verplicht: name, type ("invoice"), tinType, issueDate, saleDate, dueDate. Geef `client` mee (IRI uit clients_list) en, voor een boeking die later wordt verzoend, `contract` (IRI uit contracts_list) zodat de factuur onder dat contract verschijnt. Regelitems gaan in `invoiceRows` — netto eenheidsprijs, aantal en een belastingtarief per regel; de totalen worden berekend uit de regels, niet meegegeven. HET TARIEF VAN EEN GRENSOVERSCHRIJDENDE REGEL IS EEN WETTELIJKE GRONDSLAG, GEEN GETAL: naast de numerieke tarieven accepteert `vatRate` `np I`, `np II` en `zw`, het is een vrije string van 5 tekens, en niets valideert welke je stuurt. `np I` en `np II` zijn VERSCHILLENDE wettelijke grondslagen en komen in verschillende velden van de KSeF-factuur terecht: `np II` is P_13_9, diensten onder art. 100 ust. 1 pkt 4 van de Poolse btw-wet (de diensten die ook in de VAT-UE-opgave intracommunautaire prestaties worden gerapporteerd); `np I` is P_13_8, elke andere levering buiten Polen. Welke van de twee een bepaalde levering is, is een fiscale beslissing: haal die bij de accountant van de organisatie of uit de bevestigde praktijk van de organisatie voor dat soort klant, en NEEM HET TARIEF NIET OVER VAN EEN WILLEKEURIGE `np`-FACTUUR DIE DE ORGANISATIE AL HEEFT — een precedent kan zelf fout zijn. Het btw-nummer van de koper moet al ZONDER landprefix zijn opgeslagen (clients_create legt uit waarom) — dit document drukt tinCountry af samengevoegd met tin, dus een client die is opgeslagen als "RO40424862" wordt hier afgedrukt als RORO40424862. `bankAccount` (uit bankAccounts_list) kiest de rekening die op het document wordt afgedrukt, en `currency` staat standaard op die van de organisatie. Schrijven. |
| invoices_update | Corrigeer een uitgaande (verkoop)factuur via id, voor of na uitgifte. Het dagelijkse gebruik is het herstellen van een concept dat door invoices_create is opgesteld — een verkeerde datum, een verkeerde regel, een ontbrekende contractkoppeling — in plaats van deze te verwijderen en opnieuw op te stellen, wat een factuurnummer zou verbranden. Lees eerst invoices_get: dit is een PATCH op een document waarvan de totalen uit de regels worden afgeleid, dus het vervangen van `invoiceRows` vervangt de hele set, en een factuur die al is verzonden, wordt niet ongedaan verzonden doordat je hem hebt bewerkt. Schrijven. |
Lead-activiteiten
Tools
| leadActivities_get | Haal één lead-activiteit (outreach-contactmoment) op via id. |
| leadActivities_list | Lijst met de outreach-contactmomenten van een lead — de activiteitentijdlijn (uitnodiging verstuurd, reacties, gesprekken, follow-ups). Filter op lead om de geschiedenis van één prospect te lezen. Dit is de gestructureerde tegenhanger van crmNotes_list: activiteiten zijn het getypeerde, gedateerde contactlogboek; notities zijn vrije commentaar. |
| leadActivities_create | Leg ÉÉN outreach-contactmoment vast op een lead — een verstuurde uitnodiging, een geaccepteerde uitnodiging, een bericht, een reactie, een gesprek, een follow-up (lead + type + occurredAt verplicht; channel, contact, body optioneel). HIER hoort de outreach-geschiedenis van een prospect thuis: een crmNote is vrije commentaar, een activiteit is het gestructureerde, filterbare contactlogboek dat de tijdlijn van de prospectingqueue toont. Beschrijf contactmomenten NIET in een notitie. type: invite_sent | invite_accepted | message_sent | reply_received | call | meeting | follow_up | …; channel: linkedin | email | phone | …. Schrijfactie. |
| leadActivities_update | Werk een vastgelegde outreach-activiteit bij op id (type, channel, occurredAt, body). Schrijfactie. |
| leadActivities_delete | Verwijder een vastgelegde outreach-activiteit op id. Schrijfactie. |
| leadActivities_byList | Elke lead activity op een CAMPAGNE (een lead list), in één aanroep — geef de id, IRI, of exacte name van de lijst mee. leadActivities_list filtert op één lead, dus rapportage op campagneniveau kost anders één aanroep per lid (302 voor een lijst zoals PZFD); dit lost in plaats daarvan de leden van de lijst op en leest hun activiteiten in begrensde batches. Combineer met type en occurredAt.after/.before om de aantallen te krijgen waar mensen daadwerkelijk om vragen: reactiepercentage (type=reply_received), bouncepercentage (type=bounced), verzenddekking (type=message_sent). Geeft listId, listName, leadCount terug, en de samengevoegde activiteiten gesorteerd op occurredAt. Een onbekende lijst is een FOUT, geen leeg resultaat — dus een verkeerd getypte name kan niet worden gelezen als "deze campagne had geen activiteit". Ids komen van leadLists_list. Alleen-lezen. |
| leadActivities_bulkImport | Registreer een hele outbound-golf — elk bericht dat je daadwerkelijk hebt verstuurd — in ÉÉN aanroep, in plaats van één leadActivities_create per bericht. Geef een array mee; elke rij benoemt zijn lead (leadCompanyName, gematcht tegen een BESTAANDE lead, of een lead-IRI) plus type en occurredAt. Geef elke rij een externalId — de stabiele id per bericht, bijv. het Gmail-berichts-id — en de import is idempotent: opnieuw uitvoeren, of het opnieuw uitvoeren van een golf die maar deels is geïmporteerd, rapporteert duplicaten in plaats van ze aan te maken. Rijen zonder externalId dedupliceren op (lead, type, occurredAt, contact), dezelfde natuurlijke sleutel die leads_bulkImport gebruikt, dus een golf die eerst via die tool is geland, wordt hier niet gedupliceerd. Elke rij krijgt zijn eigen uitkomst (created | duplicate | error), zodat één misvormde rij niet de rest van de batch verwerpt. Maakt GEEN leads aan — gebruik daarvoor leads_bulkImport. ≤ 1000 rijen/aanroep. Schrijven. |
Leadcontacten
Tools
| leadContacts_get | Haal één leadcontact op via id. |
| leadContacts_list | Toon de contactpersonen die aan leads gekoppeld zijn. Filter op lead om de contacten van één prospect te lezen, of op email om te achterhalen van welke lead een bericht afkomstig is. |
| leadContacts_create | Voeg een contactpersoon toe aan een lead (lead + name verplicht; email, phone, role, linkedinUrl, isPrimary optioneel). De LinkedIn-URL van een contact hoort in linkedinUrl, NIET in een crmNote. Schrijfactie. |
| leadContacts_update | Werk een leadcontact bij op id — bijv. stel linkedinUrl / email / phone in zodra je ze vindt. Schrijfactie. |
| leadContacts_delete | Verwijder een leadcontact via id. Schrijfactie. |
Lidmaatschappen leadlijst
Tools
| leadListMemberships_get | Haal één lead-naar-lijst-lidmaatschap op via id. De status en lastContactedAt zijn een momentopname die door de aanroeper is geschreven, geen live status — zie leadListMemberships_list. |
| leadListMemberships_list | Lijst van welke leads op welke outbound-prospectielijsten staan. Filter op list, lead of status. LET OP: status en lastContactedAt zijn een MOMENTOPNAME, geschreven door wie het lidmaatschap het laatst heeft geïmporteerd of bijgewerkt. Ze zijn niet afgeleid, en niets werkt ze bij wanneer een activiteit wordt geregistreerd — het loggen van een golf van 529 follow-ups verandert geen van beide velden — dus ze kunnen willekeurig ver achterlopen. Om te beantwoorden "wanneer hebben we dit prospect voor het laatst benaderd", lees in plaats daarvan het activiteitenlog: leadActivities_list voor één lead, leadActivities_byList voor een hele campagne. leadListMemberships_syncFromActivities rapporteert het verschil en kan dit dichten. |
| leadListMemberships_create | Voeg een lead toe aan een outbound-lijst (list + lead verplicht; status optioneel). Elke lastContactedAt die je meegeeft is een momentopname die daarna door niets wordt bijgewerkt — log het contactmoment ook als lead activity, anders blijft het onbevraagbaar. Schrijven. |
| leadListMemberships_update | Werk het lidmaatschap van een lead in een lijst bij — bijv. de outreach-status instellen (contacted/replied/bounced). status en lastContactedAt worden door de aanroeper onderhouden: wat je schrijft blijft staan totdat iemand opnieuw schrijft, en het registreren van lead activities werkt ze NIET bij. Schrijven. |
| leadListMemberships_delete | Verwijder een lead uit een outboundlijst. Schrijfactie. |
Leadlijsten
Tools
| leadLists_get | Haal één outbound-prospectielijst op via id. |
| leadLists_list | Lijst met outbound-prospectinglijsten. Gebruik dit om de list-id op te lossen die leadListMemberships_create nodig heeft. |
| leadLists_create | Maak een outbound-prospectielijst aan (name verplicht). Schrijfactie. |
| leadLists_update | Werk een outboundlijst bij via id. Schrijfactie. |
| leadLists_delete | Verwijder een outboundlijst via id. Schrijfactie. |
Redenen verloren lead
Tools
| leadLostReasons_get | Haal één reden voor een verloren lead op via id. |
| leadLostReasons_list | Toon de redenen waarmee een lead als verloren gemarkeerd kan worden, in volgorde. |
Leads
Tools
| leads_dedupeCheck | Controleer of een prospect al in het CRM staat, met dezelfde filters als leads_list (companyName, source, owner, …). Roep dit aan VOORDAT je leads_create gebruikt: een dubbele lead splitst de outreach-geschiedenis over twee records, en niets verderop in de keten voegt ze voor je samen. |
| leads_get | Haal één lead op via id — bedrijf, website, bron, status, eigenaar en de klant waarnaar de lead is geconverteerd, indien van toepassing. |
| leads_list | Lijst met leads — prospectdoelen, vóór kwalificatie. Filter op status, source, owner, client, companyName of createdAt/closedAt-bereiken. Een gekwalificeerde lead wordt via leads_convert een Client plus een open Deal; tot die tijd bestaat hij alleen hier, niet in clients_list. |
| leads_create | Maak een lead aan (outbound/inbound prospectdoel; companyName, source, owner, gekoppelde client optioneel). Een nieuwe lead heeft altijd status=open — status is hier niet instelbaar en verandert alleen via leads_convert, leads_lose en leads_reopen. Schrijven. |
| leads_update | Werk een lead bij via id (company, website, source, owner, gekoppelde client, stage, doNotContact). NIET status of lostReason: die worden door de entiteit geweigerd en stilzwijgend genegeerd door dit endpoint, dus het sluiten van een lead vereist leads_lose (met een lostReasonId) en het ongedaan maken daarvan vereist leads_reopen. Het wijzigen van `stage` doorloopt de funnel; het sluit de lead niet. Schrijven. |
| leads_delete | Verwijder een lead via id (soft delete). Schrijfactie. |
| leads_convert | Converteer een gekwalificeerde lead naar een Client + één contact per leadcontact + een open Deal. Vereist een bestaande client (de client van de lead of een clientId in de body). Schrijfactie. |
| leads_lose | Sluit een lead als LOST — zet status=lost en stempelt closedAt. VEREIST lostReasonId, de `id` van een leadLostReasons-item (voer eerst leadLostReasons_list uit; het is een keuzelijst, dus vrije tekst wordt geweigerd met 422). Dit is de ENIGE manier om een lead als verloren te registreren: leads_update negeert status, en doNotContact betekent "nooit meer contact opnemen", wat een ander en veel sterker statement is dan "deze hebben we niet gewonnen". Dit verplaatst de stage van de lead NIET — LeadStage heeft geen terminale vlag, dus de lead behoudt zijn positie in de funnel en leads_reopen kan deze exact herstellen. Schrijven. |
| leads_reopen | Maak leads_lose ongedaan — zet status terug op open en wist closedAt en de lost reason. De stage blijft ongewijzigd, dus de lead hervat precies waar hij was. Gebruik dit wanneer een lead tegen het verkeerde record is gesloten of het prospect terugkwam. Schrijven. |
| leads_bulkImport | Importeer meerdere leads in ÉÉN aanroep, elk met geneste contacten, lidmaatschap van lijsten en outreach-activiteiten — de server maakt de lead aan en verwerkt vervolgens de id ervan in de onderliggende items, zodat je nooit met tussenliggende IRI's hoeft te jongleren. Idempotent op basis van natuurlijke sleutels (companyName / email / (list,lead) / (type,occurredAt,contact)): veilig om opnieuw uit te voeren en te chunken (≤100 leads/aanroep). Dit is het bulkpad dat een campagne-import moet gebruiken in plaats van N leads_create-aanroepen. Schrijfactie. |
Leadfasen
Tools
| leadStages_get | Haal één leadfase op via id. |
| leadStages_list | Lijst met de fasen waar een lead doorheen gaat, in volgorde. Leads hebben hun eigen fasenset — deals gebruiken stages_list, wat iets anders is. |
Locaties
Tools
| locations_get | Haal één locatie op via id — de naam en openingstijden. Alleen-lezen. |
| locations_list | Lijst van de locaties van de organisatie — de fysieke plekken waar assets zich bevinden, in de UI getoond als Lokalizacja. Vereist ROLE_LOCATIONS_MANAGER, wat ongebruikelijk genoeg zowel het LEZEN als het schrijven afschermt. Alleen-lezen. |
| locations_create | Maak een locatie aan (name verplicht; optioneel officeOpenHour/officeCloseHour als seconden na middernacht). Gebruik het echte adres in plaats van een project- of investeringsnaam — dat is wat iemand die voor het asset staat nodig heeft, en de projectnaam wordt al elders bijgehouden. Vereist ROLE_LOCATIONS_MANAGER. Schrijven. |
| locations_update | Hernoem een locatie of wijzig de openingstijden. Vereist ROLE_LOCATIONS_MANAGER. Schrijven. |
Adressen organisatie
Tools
| organizationAddresses_get | Haal één abonnementsadres-record op via id — name, street, city, postCode, country, en de belastingvelden. `street` bevat het huisnummer wanneer dit handmatig is ingevoerd, en niet wanneer het afkomstig is van de NIP/GUS-opzoeking. Alleen-lezen. |
| organizationAddresses_list | Lijst van de abonnementsadres-records van de organisatie — het adres dat aan het Flowtly-abonnement is gekoppeld, en de bron waaruit de mail-footer {{organizationAddress}} wordt gerenderd. Normaal gesproken precies één rij. Dit is NIET het factuuradres van de verkoper, dat zich bevindt in de organization-billing-*-configsleutels (configs_get) en dat is wat facturen en KSeF lezen; de twee worden apart onderhouden en lopen regelmatig uiteen. Lees beide voordat je concludeert welke een klant daadwerkelijk heeft bewerkt. |
| organizationAddresses_update | Werk het SUBSCRIPTION-adresrecord van de organisatie bij (id verplicht; stuur alleen de velden mee die je wijzigt). DIT IS HET RECORD WAARUIT DE MAIL-FOOTER WORDT GERENDERD: de {{organizationAddress}} van de footer wordt hieruit samengesteld als "street, postCode city", NIET uit de organization-billing-*-configsleutels die facturen en KSeF gebruiken als verkopersadres. De twee bronnen lopen uiteen, en dat de footer deze leest is een bekende tekortkoming — dus wanneer een handtekening een adres toont waarvan de klant zweert dat hij het heeft gecorrigeerd, heeft hij de billing-sleutels gecorrigeerd en is dit het record dat nog de oude waarde bevat. `street` is één vrije-tekstkolom die ook het huisnummer moet dragen: de NIP/GUS-opzoeking vult alleen de straatnaam en laat het huis- en flatnummer stilzwijgend weg, wat verklaart waarom adressen hier "ul. Example" zonder nummer luiden. Schrijf het volledige "ul. Example 8/12" om dit te herstellen. LEES EERST met organizationAddresses_list en vergelijk met configs_get op organization-billing-street voordat je schrijft, zodat je de eigen, onderhouden waarde van de klant overneemt in plaats van er zelf een te verzinnen. Vereist ROLE_BILLINGS_MANAGER. Schrijven. |
Organisaties
Tools
| organizations_get | Haal een organisatie op via id. WAARSCHUWING — dit vertelt je NIET met welke organisatie je verbonden bent. Een OAuth-verbinding is aan precies één organisatie gekoppeld (token-gebonden), maar dit endpoint geeft elke organisatie terug waarvan de verbonden GEBRUIKER lid is, dus een succesvolle lezing hier lijkt op een bevestiging dat je in die organisatie werkt, terwijl dat misschien niet zo is. Lees in plaats daarvan tenant-gebonden gegevens om de tenant te verifiëren waarin je daadwerkelijk werkt — people_list of clients_list — en begin nooit een bulkschrijfactie op basis van deze aanroep alleen. |
Personen
Tools
| people_get | Haal één persoon/medewerker op via id — namen, e-mailadressen, telefoon, leidinggevende en of ze actief zijn. |
| people_list | Toon personen/medewerkers. Filter op isActive, reportsTo (id van een leidinggevende), projectMembers.project, of search; pagineer met cursor. Personen en medewerkers delen dezelfde id, dus zo achterhaal je de employee id die werktijd, verantwoordelijkheden, projectlidmaatschap en rechtentools allemaal verwachten. |
| people_create | Maak een persoon/medewerker aan (firstname + lastname verplicht; optioneel companyEmail, contactEmail, contactPhone). Schrijfactie. |
| people_update | Werk een persoon/medewerker bij via id (name, companyEmail, contactEmail, contactPhone, enz.). Schrijfactie. |
| people_delete | Verwijder een medewerker/persoon via id (bijv. om een placeholder/dummy-medewerker te verwijderen). Vereist ROLE_EMPLOYEES_MANAGER; de backend voert een verwijderproces uit dat ook gekoppelde records loskoppelt. Grote impact, onomkeerbaar. Schrijfactie. |
| people_invite | Geef een bestaande persoon een LOGIN: maakt een openstaande organisatie-uitnodiging aan en mailt deze naar de persoon, in de ingestelde UI-taal van de organisatie. Dit is de stap die people_create en people_setPermissionGroups NIET doen — een persoon met permission groups kan nog steeds niet inloggen totdat hij is uitgenodigd en heeft geaccepteerd. Vereist het e-mailadres van de persoon; mislukt als deze al een login heeft. Onboardingvolgorde: people_create (record) -> people_invite (login) -> people_setPermissionGroups (rechten). Schrijven. |
| people_setPermissionGroups | Stel de VOLLEDIGE set permission groups van een persoon in (vervang deze) via numerieke group-ids (zie permissionGroups_list — bijv. de groep "Business Owner" verleent ROLE_ADMIN): geef elke groep mee waarmee de persoon moet eindigen, en [] verwijdert ze allemaal. Verleent toegang; maakt GEEN login aan en mailt de persoon niet — dat is people_invite. DE VALKUIL: iemand zijn EERSTE groep geven brengt hem op het berekende model, waarin rollen afkomstig zijn van groups en per-persoon-overrides, en een rol die buiten dat model om handmatig is toegekend verdwijnt in diezelfde aanroep — een ROLE_ADMIN die aan één persoon is gegeven is precies het soort dat hierdoor wordt verwijderd. Het werkt ook andersom: het wissen van iemands laatste groep haalt hem weer van dat model af en laat die oudere rollen opnieuw verschijnen. De lijsten overridesAdded/overridesRemoved zeggen hier niets over; ze beschrijven overrides en blijven leeg terwijl de effectieve toegang verandert. De response rapporteert dus het verschil tussen de rollen die de persoon vóór en na deze aanroep had, als rolesLost en rolesGained — dat is het paar dat je leest zodra de aanroep terugkomt. rolesLost null (niet []) betekent dat de momentopname die vóór het schrijven is genomen niet kon worden gelezen en dat het verschil ONBEKEND is, met de reden in roleDeltaUnavailable: de groepswijziging is wel doorgevoerd, dus een null is geen bewijs dat alles in orde is — controleer opnieuw met people_getPermissions. Om een rol terug te geven die had moeten blijven, ken je die toe met people_setRoleOverrides. Vereist ROLE_ROLES_MANAGER. Schrijven. |
| people_setRoleOverrides | Stel de rollen in (vervang deze) die ÉÉN persoon extra krijgt — of ontnomen wordt — bovenop diens permission groups. Grijp eerst naar een group (people_setPermissionGroups): groups zijn de bedoelde abstractie en schalen naar meer dan één persoon, dus gebruik een override alleen waar één individu daadwerkelijk afwijkt van elke group. VERVANGT beide lijsten volledig, dus lees eerst people_getPermissions en stuur elke override terug die de persoon moet behouden; het weglaten van een lijst wist deze. Rollen zijn ROLE_-constanten — permissionGroups_list toont welke deze organisatie al gebruikt. Een rol die zowel in added als removed staat wordt geweigerd in plaats van geraden. Geeft dezelfde opgeloste momentopname terug als people_getPermissions, zodat je het resultaat kunt bevestigen zonder een tweede aanroep. Maakt GEEN login aan — zie people_invite. Vereist ROLE_ROLES_MANAGER. Schrijven. |
| people_getPermissions | Wat een persoon daadwerkelijk kan doen, opgelost: diens permission groups (elk met de rollen die deze verleent), diens per-persoon-overrides, en de effectiveRoles waarin de twee samenkomen. DE manier om te controleren of een toegangswijziging is doorgevoerd — people_list toont een roles-veld, maar dit is degene die uitlegt WAAROM die rollen worden gehouden en aan welke hendel je moet trekken om dit te wijzigen. Raadpleeg dit voor elke people_setRoleOverrides-aanroep, want die tool vervangt de override-lijsten volledig en hier lees je de huidige. staleOverrides zijn verwijderde overrides die niet langer overeenkomen met een door een group verleende rol, dus ze doen op dit moment niets. people_list levert de id. Vereist ROLE_ROLES_MANAGER om iemand anders dan jezelf te bekijken. Alleen-lezen. |
Rechtengroepen
Tools
| permissionGroups_get | Haal één rechtengroep op via id, inclusief de ROLE_*-strings die hij toekent. |
| permissionGroups_list | Lijst met de rechtengroepen van de organisatie en de rollen die elke groep verleent — bijv. de groep "Business Owner" verleent ROLE_ADMIN. Lees dit voor people_setPermissionGroups: de rollen in de respons zijn bepalend voor wat een groep daadwerkelijk toestaat, zodat je nooit hoeft te raden op basis van de naam. |
| permissionGroups_create | Maak een rechtengroep aan (name verplicht; roles = lijst van ROLE_*-strings die deze toekent). Schrijfactie. |
| permissionGroups_update | Werk de naam, omschrijving of toegekende rollen van een rechtengroep bij via id. Schrijfactie. |
Pipelines
Tools
| pipelines_get | Haal één salespipeline op via id. |
| pipelines_list | Lijst met verkooppipelines. Een pipeline heeft een geordende reeks fasen — lees ze met stages_list, gefilterd op pipeline. |
Functies
Tools
| positions_list | Lijst met posities — de benoemde functies (bijv. "Backend Engineer") die een projectallocatie vervult. Geen filters; Position heeft paginering uitgeschakeld, dus dit geeft altijd de volledige functiecatalogus van de organisatie in één aanroep terug. Elk item is {id, name, roles}. Gebruik dit om de functienaam achter de positionId van een allocations_list-rij op te lossen, en om de position-id te vinden waar een resourcing-import op moet matchen. |
Projectleden
Tools
| projectMembers_get | Haal één projectlidmaatschap op via id — de employee, project en position. Ids komen van projectMembers_list of de projectMembers-array op projects_get. |
| projectMembers_list | Lijst van projectlidmaatschappen — WIE WELK PROJECT KAN ZIEN. Filter op project (`/projects/{id}`) om de bezetting van één project te lezen, of op employee om elk project te lezen dat één persoon kan bereiken; elke rij bevat een eigen id, de employee, het project en de position (employee|tech-lead|account-manager|viewer). Raadpleeg dit als eerste wanneer iemand meldt dat een project ontbreekt in hun Projects-lijst of dat ze er geen tijd op kunnen loggen: een lege bezetting, of een bezetting zonder hen erin, IS de verklaring — zichtbaarheid is lidmaatschap. Dit is ook de id-bron voor projectMembers_update en projectMembers_delete. Let op: dezelfde persoon kan meerdere keren op één project voorkomen, één keer per position. |
| projectMembers_create | Zet een persoon OP een project (employee- + project-IRIs verplicht, bijv. "/people/204" en "/projects/243"; optioneel position = employee|tech-lead|account-manager|viewer, standaard employee). DIT IS DE TOEGANGSCONTROLE, geen label: een persoon die geen lid is, ziet het project helemaal niet — het ontbreekt in hun Projects-lijst en ze kunnen er geen tijd op loggen — dus dit is de tool die iemand herstelt die van een project is buitengesloten. POSITION IS NIET COSMETISCH: een gebruiker met een projectgebonden rol ziet alleen de projecten waar hun lidmaatschaps-position ermee overeenkomt — ROLE_PROJECTS_LEAD komt overeen met tech-lead, ROLE_PROJECTS_VIEWER met viewer — dus een projectlead een `employee`-rij geven laat hem net zo blind achter als helemaal geen rij. Lidmaatschap CASCADEERT NIET: iemand op een oudermap zetten geeft hem niets op de projecten daaronder, dus een mappenboom heeft één aanroep per project nodig. De unieke sleutel is (employee, project, position), wat betekent dat posities stapelen in plaats van vervangen — een persoon kan zowel employee ALS tech-lead op hetzelfde project hebben als twee aparte rijen, en tech-lead toevoegen aan iemand die daar al employee is, verwijdert of upgradet de employee-rij niet (gebruik projectMembers_update om een position ter plekke te wijzigen). Lees eerst de huidige rijen met projectMembers_list?project=/projects/{id}, of projects_get, waarvan de projectMembers-array de id van elke rij bevat. EEN HEEL ROOSTER LADEN? Er bestaat een bulkvariant — projectMembers_import verzoent tot 500 lidmaatschappen in één aanroep, slaat de al geregistreerde over zodat opnieuw uitvoeren veilig is, en zet de notificatie standaard UIT — maar DEZE IS NIET BESCHIKBAAR OP DEZE VERBINDING: hij wordt alleen aan de internal scope aangeboden, dus je kunt hem hier niet aanroepen en ernaar zoeken zal hem niet vinden. Roep deze tool in een lus aan, of vraag je Flowtly-operator om de bulklading uit te voeren. NIET STIL: het toevoegen van een persoon die nog niet op het project staat verstuurt een project-assigned-notificatie naar die persoon, dus een backfill van 17 projecten verstuurt 17 notificaties. Vereist ROLE_PROJECTS_MANAGER. Schrijven. |
| projectMembers_update | Wijzig de position van een bestaand lidmaatschap via id (employee|tech-lead|account-manager|viewer) — haal de id op uit projectMembers_list of de projectMembers-array op projects_get. Gebruik dit om TER PLEKKE te promoveren of te degraderen; gebruik projectMembers_create om een tweede, extra position toe te voegen naast de al aanwezige. Het wijzigen van een position kan het zicht op het project INTREKKEN voor iemand met een projectgebonden rol (een ROLE_PROJECTS_LEAD die van tech-lead naar employee wordt gedegradeerd, ziet het project niet meer). Kan een lidmaatschap niet naar een andere persoon of project verplaatsen — verwijder en maak opnieuw aan voor dat doel. Vereist ROLE_PROJECTS_MANAGER. Schrijven. |
| projectMembers_delete | Haal een persoon VAN een project af via membership-id — vind deze met projectMembers_list of in de projectMembers-array van projects_get. Dit TREKT TOEGANG IN: zodra de laatste lidmaatschapsrij voor die persoon op dat project verdwenen is, verdwijnt het project uit zijn zicht en kan hij er geen tijd meer op loggen, wat precies is hoe een project stilzwijgend voor iemand verdwijnt. Al gelogde uren worden NIET verwijderd en blijven op het project staan; de persoon kan ze alleen niet meer zien of eraan toevoegen. Het verwijderen van één position laat elke andere position die dezelfde persoon op hetzelfde project heeft intact. Vereist ROLE_PROJECTS_MANAGER. Onomkeerbaar (opnieuw aanmaken maakt een nieuwe rij en stuurt opnieuw een melding), grote impact. Schrijven. |
Projecten
Tools
| projects_costAllocations | Hoe kosten OVER dit project zijn verdeeld — welke transacties en factuurregels eraan zijn toegerekend, en in welk aandeel. Gebruik dit om een winstgevendheidscijfer te verklaren in plaats van het alleen te citeren: hier wordt een onverwacht resultaat teruggeleid naar het document dat het veroorzaakte. Vereist ROLE_TRANSACTIONS_MANAGER. Alleen-lezen. |
| projects_folderCounts | Hoeveel projecten er in elke project-MAP zitten, als folderId + total + active. De folderId is een tagDefinition-id — namen los je op met tagDefinitions_list, en welke groepen mapgroepen zijn zie je met tagGroups_list (allowedRelations bevat "project"). Een lege folderId is de bak zonder categorie. Telt alleen hoofdprojecten, want mappen groeperen hoofdprojecten en fasen volgen hun bovenliggende project. Alleen-lezen. |
| projects_get | Haal één project op via id — naam, type, klant, data, omschrijving en prijs. |
| projects_list | Toon projecten. Filter op type (fixed-price | time-and-material | non-billable | internal), client.name, employee, name, of periodes voor dateFrom/dateTo. Gebruik dit om de project id te achterhalen die taken, werktijdregistratie, budgetten en contracten allemaal verwachten. |
| projects_profitability | HET RESULTAAT PER PROJECT — wat een project opleverde tegenover wat het kostte. Dit is het getal dat een dienstverlenend of ontwikkelbedrijf doorgaans wil zien, en het getal waar elke andere projecttool naartoe voedt. Geef de project-id mee vanuit projects_list. Vereist ROLE_ACCOUNT_MANAGER. Alleen-lezen. |
| projects_create | Maak een project aan (name + type verplicht; type = fixed-price|time-and-material|non-billable|internal; optioneel dateFrom/dateTo, client, publicDescription, notes, priceNet). Schrijfactie. |
| projects_update | Werk een project bij via id (name, type, dates, description, enz.). Schrijfactie. |
| projects_archive | Archiveert een project op id — de manier om een project buiten gebruik te stellen dat niet verwijderd kan worden omdat er geregistreerde tijd, facturen of budgetten aan hangen. Omkeerbaar met projects_unarchive. Beter dan dateTo terugzetten, wat het project alleen afgerond laat lijken. Schrijven. |
| projects_unarchive | Herstelt een gearchiveerd project op id en maakt projects_archive ongedaan. Schrijven. |
Projectsjablonen
Tools
| projectTemplates_get | Haal één projectsjabloon op via id, inclusief het volledige structuurdocument. projectTemplates_list vindt de id. Lees dit voor projectTemplates_update — de structure wordt IN ZIJN GEHEEL weggeschreven, dus een update moet het complete document meesturen, geen fragment. Alleen-lezen. |
| projectTemplates_list | Lijst van de projectsjablonen van de organisatie — herbruikbare blauwdrukken van een project, de fases, de takenlijsten en de taken ervan. Raadpleeg dit VOORDAT je projects_create gebruikt wanneer herhaaldelijk hetzelfde soort project wordt opgezet (een opdrachttype, een audit, een onboarding): het instantiëren van een sjabloon bouwt de hele boom in één aanroep, terwijl projects_create een leeg project maakt dat je vervolgens handmatig moet vullen. De rij met isDefault is het ingebouwde sjabloon van de organisatie, toegepast op een project dat zonder gekozen sjabloon is aangemaakt. Alleen-lezen. |
| projectTemplates_create | Maak een herbruikbare projectblauwdruk aan vanuit een structuurdocument (version, project, fases, en hun lijsten/taken). Offsets daarin zijn RELATIEF — startOffsetDays en durationDays worden geteld in dagen vanaf de startDate die bij het instantiëren wordt opgegeven, zodat één sjabloon elke toekomstige start bedient. De project.name in de structure is een placeholder; overschrijf deze per klant bij het instantiëren. De structure wordt server-side gevalideerd tegen het schema voor de opgegeven version, en een overtreding noemt de betreffende JSON pointer. Schrijven. |
| projectTemplates_update | Werk een projectsjabloon bij via id. De structure-kolom wordt IN ZIJN GEHEEL opgeslagen en vervangen, nooit samengevoegd — stuur het complete document mee, anders zijn de weggelaten delen verdwenen. Lees eerst de huidige met projectTemplates_get. Het wijzigen van een sjabloon raakt GEEN projecten die er al uit zijn geïnstantieerd; er is geen terugpropagatie. Schrijven. |
| projectTemplates_delete | Verwijder een projectsjabloon via id. Soft delete, en dit raakt GEEN projecten die al vanuit het sjabloon zijn aangemaakt — dat blijven gewone projecten die gewoon blijven bestaan. Schrijven. |
| projectTemplates_instantiate | Bouw een echt project vanuit een sjabloon — het project, de fases, de takenlijsten en elke taak, in ÉÉN atomaire aanroep. startDate is verplicht en is het ankerpunt waartegen elke startOffsetDays in het sjabloon wordt opgelost. Geef name mee om de placeholder-projectnaam van het sjabloon te overschrijven, en client om het nieuwe project aan een klant te koppelen: twee keer instantiëren tegen DEZELFDE client is hoe één klant meerdere opdrachten krijgt, elk als eigen project. Geeft het aangemaakte project terug. Schrijven. |
Kandidaten personeelsaanvragen
Tools
| resourceRequestCandidates_get | Eén recruitmentkandidaat op id. De id komt uit resourceRequestCandidates_list. Vereist ROLE_HR_MANAGER. Alleen-lezen. |
| resourceRequestCandidates_list | De kandidaten die zijn voorgedragen voor wervingsaanvragen — mensen in een recruitmentpipeline, geen werknemers die beschikbaar zijn voor allocatie. Filter op de request-id uit resourceRequests_list. Vereist ROLE_HR_MANAGER. Alleen-lezen. |
Resourceaanvragen
Tools
| resourceRequests_get | Eén wervingsaanvraag op id, met de positie en status. Haal de id op uit resourceRequests_list. HR/recruitment, geen resourcing-allocatie. Vereist ROLE_HR_MANAGER. Alleen-lezen. |
| resourceRequests_list | Open wervingsaanvragen — een verzoek om te werven voor een positie, in het HR-domein. Ondanks de naam is dit GEEN resourcing-allocatievraag: het is recruitment. Geeft de collectie terug; resourceRequests_get leest er één, en resourceRequestCandidates_list geeft de mensen die ervoor zijn voorgedragen. Vereist ROLE_HR_MANAGER. Alleen-lezen. |
Resourcing-aanvragen
Tools
| resourcingRequests_list | Open resourcing-aanvragen — iemand die vraagt om een persoon aan een project toe te wijzen, de vraagzijde van resourcing. Dit is de flow die de Requests-weergave van de Resourcing UI toont. Verwar dit NIET met resourceRequests_list: dat is HR-RECRUITMENT (werven voor een positie). Combineer dit met resourcingRequestsHistory_list voor wat al is besloten, en resourcingBench_get voor wie aan een aanvraag zou kunnen voldoen. Vereist de resourcing-module en ROLE_RESOURCING_MANAGER. Alleen-lezen. |
Geschiedenis resourcing-aanvragen
Tools
| resourcingRequestsHistory_list | Wat er al is gebeurd met resourcing-aanvragen — het beslissingsspoor (bevestigd, afgewezen, gewijzigd) achter de open aanvragen in resourcingRequests_list. Gebruik dit om te beantwoorden 'is hier al eerder om gevraagd en afgewezen?' voordat je dezelfde allocatie opnieuw voorstelt. Vereist de resourcing-module en ROLE_RESOURCING_MANAGER. Alleen-lezen. |
Verantwoordelijkheden
Tools
| responsibilities_get | Haal één verantwoordelijkheid op via id. |
| responsibilities_list | Toon verantwoordelijkheden binnen een RACI-groep. Filter op responsibilityGroup. Verantwoordelijkheden kunnen genest worden via parent; personen worden eraan toegewezen via responsibilityEmployees, niet rechtstreeks. |
| responsibilities_create | Maak een verantwoordelijkheid aan binnen een groep (responsibilityGroup = groep-id of IRI, + name, verplicht; optioneel description; optioneel parent = een andere responsibility-IRI voor nesting). Wijs er mensen aan toe via responsibilityEmployees_create. Schrijfactie. |
| responsibilities_update | Werk een verantwoordelijkheid bij via id (name, description, parent, responsibilityGroup = group id of IRI). Schrijfactie. |
Verantwoordelijkheidstoewijzingen
Tools
| responsibilityEmployees_get | Haal één verantwoordelijkheidstoewijzing op via id. |
| responsibilityEmployees_list | Toon wie aan welke verantwoordelijkheid is toegewezen, en voor welk percentage. Filter op employee om de volledige RACI-belasting van één persoon over alle groepen te lezen. |
| responsibilityEmployees_create | Wijs een medewerker toe aan een verantwoordelijkheid (responsibility = responsibility id of IRI, employee = employee id of IRI, percentage 0-100, allemaal verplicht; optioneel targets en description). Schrijfactie. |
| responsibilityEmployees_update | Werk een verantwoordelijkheidstoewijzing bij via id (percentage, targets, description). Schrijfactie. |
| responsibilityEmployees_delete | Verwijder de toewijzing van een medewerker aan een verantwoordelijkheid via id. Schrijfactie. |
Verantwoordelijkheidsgroepen
Tools
| responsibilityGroups_get | Haal één verantwoordelijkheidsgroep op via id. |
| responsibilityGroups_list | Toon verantwoordelijkheidsgroepen / RACI-gebieden — de hoofdonderdelen "Odpowiedzialności", elk met een verantwoordelijke persoon. Individuele verantwoordelijkheden hangen hieronder. |
| responsibilityGroups_create | Maak een verantwoordelijkheidsgroep / RACI-gebied aan (name verplicht; optioneel description en responsibleEmployee = de verantwoordelijke persoon, opgegeven als een gewone employee-id zoals 6 (uit people_list) of de IRI /people/6). Dit is het topniveau-item 'Odpowiedzialności'. Voeg er individuele verantwoordelijkheden aan toe via responsibilities_create. Schrijfactie. |
| responsibilityGroups_update | Werk een verantwoordelijkheidsgroep bij via id (name, description, responsibleEmployee = employee id of IRI). Schrijfactie. |
Roostermedewerkers
Tools
| scheduleEmployees_get | Eén toewijzing van rooster aan werknemer op id. De id komt uit scheduleEmployees_list. Vereist ROLE_SCHEDULES_MANAGER. Alleen-lezen. |
| scheduleEmployees_list | Welke werknemers zijn toegewezen aan welke werktijdroosters. Gebruik dit om vanuit een rooster (schedules_list) naar de bijbehorende mensen te gaan, of om het rooster te vinden dat een bepaalde werknemer volgt. Vereist ROLE_SCHEDULES_MANAGER. Alleen-lezen. |
Roosterplan
Tools
| schedulePlan_list | De roosters die van kracht zijn op ÉÉN opgegeven datum — geef de datum mee in het pad. Gebruik dit om te beantwoorden 'wie werkt er vandaag / op deze datum' zonder zelf elk rooster te lezen en de bereiken op te lossen. In tegenstelling tot de andere roosterleesacties is hiervoor alleen ROLE_USER vereist, dus dit is degene die beschikbaar is voor een gewone werknemer. Alleen-lezen. |
Roosterperiodes
Tools
| scheduleRanges_get | Eén tijdsbereik van een rooster op id. De id komt uit scheduleRanges_list. Vereist ROLE_SCHEDULES_MANAGER. Alleen-lezen. |
| scheduleRanges_list | De tijdsbereiken waaruit werktijdroosters bestaan — de daadwerkelijke uren die een rooster omvat. Lees eerst de bovenliggende met schedules_get; dit werkt de bereiken ervan verder uit. Vereist ROLE_SCHEDULES_MANAGER. Alleen-lezen. |
Roosters
Tools
| schedules_get | Eén werktijdrooster op id, met de bereiken en toegewezen werknemers. De id komt uit schedules_list; scheduleRanges_list en scheduleEmployees_list lezen de onderdelen ervan. Vereist ROLE_SCHEDULES_MANAGER. Alleen-lezen. |
| schedules_list | Werktijdroosters — de dienst-/werkpatronen die een organisatie definieert, GEEN projectallocatie. Gebruik resourcingSchedule_get voor wie op wat is geboekt; gebruik dit voor de werkpatronen zelf. schedules_get leest er één op id. Vereist ROLE_SCHEDULES_MANAGER. Alleen-lezen. |
Fasen
Tools
| stages_get | Haal één dealfase op via id. |
| stages_list | Lijst met dealfasen, in volgorde. Filter op pipeline. deals_create vereist een fase-id van hier, en het verplaatsen van een deal tussen fasen is wat dealStageHistories vastlegt. |
Leveranciers
Tools
| suppliers_list | Toon leveranciers/contractors — wordt geserveerd vanuit /contractors, dus "supplier" en "contractor" zijn hetzelfde record. Filter op cyclic voor terugkerende leveranciers. Gebruik dit om de leverancier te achterhalen waartegen een kost, een contract of een inkomende factuur wordt geboekt. |
| suppliers_create | Maak een nieuwe leverancier/contractor aan (name, tinType, costGroup verplicht). Schrijfactie. |
| suppliers_update | Werk de gegevens van een leverancier/contractor bij via id (name, belastingnummer, betalingstermijnen, enz.). Schrijfactie. |
Tagdefinities
Tools
| tagDefinitions_list | Lijst met labeldefinities — de labels die aan records kunnen worden gekoppeld, elk binnen een labelgroep. tags_create heeft een tagDefinition-id van hier nodig plus het record waaraan het gekoppeld moet worden. |
| tagDefinitions_create | Maakt een tagdefinitie aan (name, level, tagGroup verplicht) binnen een taggroep. Bevat allowedRelations van de groep "project", dan IS elke definitie hier een projectmap — dit is het gereedschap dat er een aanmaakt. Schrijven. |
Taggroepen
Tools
| tagGroups_list | Toon taggroepen — de containers waarin tagdefinities georganiseerd worden. |
| tagGroups_create | Maakt een taggroep aan (naam verplicht) om verwante tagdefinities te ordenen. Zo maak je ook een PROJECTMAP-container: geef allowedRelations: ["project"] mee, en de definities van de groep worden mappen in de projectenlijst. Een groep met een lege allowedRelations is universeel en wordt NIET als map behandeld. Schrijven. |
Taakopmerkingen
Tools
| taskComments_list | Toon opmerkingen bij projecttaken, oudste eerst. Filter op task om de discussie van één taak te lezen. |
| taskComments_create | Voeg een opmerking toe aan een projecttaak (task id + content). Schrijfactie. |
Taaklijsten
Tools
| taskLists_list | Lijst met takenlijsten — de bordkolommen/secties waarin taken worden ingedeeld. Filter op project. tasks_create heeft een list-id van hier nodig. |
Taken
Tools
| tasks_get | Haal één projecttaak op via id — titel, project, status, lijst, toegewezenen, data en herhaling. |
| tasks_list | Lijst met projecttaken. Filter op project, list, status, assignees, isTemplate of startAt/dueAt-bereiken. Terugkerende taken tonen recurrenceParent en recurrenceRule, zodat een gegenereerd voorkomen kan worden teruggeleid naar de regel die het heeft geproduceerd. Om te bepalen of een taak VOLTOOID is, vergelijk je de status met taskStatuses_list (isClosed) in plaats van te matchen op de statusnaam. |
| tasks_create | Maak een projecttaak aan (title + project verplicht; optioneel status, list, assignees, dueAt, priority). Schrijfactie. |
| tasks_update | Werk een projecttaak bij via id — wijzig status (incl. als afgerond markeren), assignees, dueAt, title, enz., of VERPLAATS de taak naar een ander project door `project` mee te geven (re-parenting; de takenlijst wordt geleegd tenzij je ook een `list` in het doelproject opgeeft, omdat een lijst bij één project hoort). Schrijven. |
Taakstatussen
Tools
| taskStatuses_list | Toon de projecttaakstatussen, in bordvolgorde. isClosed markeert de afgeronde statussen en isDefault de status die een nieuwe taak krijgt. Raadpleeg dit voordat je de status van een taak interpreteert — de namen zijn per organisatie configureerbaar, dus "Done" is geen betrouwbare string om op te matchen. |
Belastinggroepen
Tools
| taxGroups_list | Lijst met btw-groepen. Gebruik dit om de taxGroup-id op te lossen waarop taxRules_list filtert en die factuurregels dragen. |
| taxGroups_create | Maak een belastinggroep aan (name + type verplicht). Schrijfactie. |
| taxGroups_update | Werk de naam of het type van een belastinggroep bij via id. Schrijfactie. |
Belastingregels
Tools
| taxRules_list | Toon belastingregels — de tarieven en de periodes waarin ze gelden. Filter op taxGroup. |
| taxRules_create | Maak een belastingregel aan. Schrijfactie. |
| taxRules_update | Werk een belastingregel bij via id. Schrijfactie. |
Transacties
Tools
| transactions_list | Toon banktransacties — de bankfeed waartegen inkomende facturen worden gematcht. Filter op bankAccount, counterpartyRole, cost, ignored, hasDetectedProblems, een periode voor orderDate/execDate, of amount.between. Let op: orderDate en execDate zijn verschillend — een betaling kan in de ene maand worden opgedragen en in de volgende worden uitgevoerd. |
| transactions_suggestions | Lees Flowtly's voorstellen voor één banktransactie — tegen welke tegenpartij, kostengroep of document deze moet worden geboekt. Het spiegelbeeld van incomingInvoices_suggestions, vanuit de geldzijde. |
| transactions_importStatement | Importeer een bankafschriftbestand (bijv. een MT940 .sta-bestand) — geef de ruwe tekstinhoud van elk bestand letterlijk mee (NIET base64) met een filename. ER IS GEEN bankAccount-PARAMETER: de backend routeert een bestand door alle niet-cijfertekens uit de rekeningnummers van je bankrekeningen en uit de bytes van het bestand te strippen, en importeert in elke rekening waarvan de cijfers ergens in het bestand voorkomen — dus één bestand kan in meerdere rekeningen belanden, en een afschrift voor een rekening die niet in Flowtly is ingesteld (of waarvan het nummer anders is vastgelegd dan de bank schrijft) importeert in geen enkele, en faalt met een foutmelding die precies uitlegt waarom — lees dat bericht, het is de enige diagnose die dit endpoint geeft. Bij succes is de respons `{ imported, matching }`: `matching: "in_progress"` betekent dat contractant-/bijlagematching voor de nieuwe rijen nog loopt nadat deze aanroep terugkeert, dus een onmiddellijke transactions_list kan rijen tonen die nog niet gematcht zijn — lees iets later opnieuw voor de definitieve status. Het opnieuw importeren van hetzelfde afschrift maakt geen dubbele rijen aan; de importer herkent transacties die al eerder zijn gezien. Zodra een afschrift is verwerkt, koppel je een bestaande betaling zonder bankregel aan een van de rijen met invoiceTransactions_update. Schrijven. |
| transactions_delete | Verwijdert een banktransactie op id — vind haar met transactions_list. Grijp hier ALLEEN naar om een boekhoudfout ongedaan te maken die niet anders te corrigeren is: een afschrift dat op de verkeerde bankrekening is geïmporteerd, of regels die met de hand zijn ingevoerd voordat het echte afschrift binnenkwam en er nu door gedupliceerd worden. Een transactie is de vastlegging van wat de bank deed, dus er een verwijderen op een geïmporteerde rekening laat het grootboek afwijken van de bank; de backend staat het alleen toe voor ROLE_ADMIN (een transactiebeheerder mag uitsluitend op kas- en handmatige rekeningen verwijderen). VOORDAT je een vermoed duplicaat verwijdert, bewijs het paar: match de geïmporteerde regel op bedrag ÉN factuurnummer ÉN tegenpartij, niet op bedrag alleen — een betaling die na de einddatum van het afschrift binnenkwam heeft geen tegenhanger, en haar verwijderen vernietigt het enige bewijs van die inkomsten. De backend ONTKOPPELT in plaats van te verwijderen wat eraan hangt: factuurbetalingen blijven bestaan met een leeggemaakte bankregel (koppel ze opnieuw met invoiceTransactions_update), bijlagen en panden worden losgemaakt, terwijl project- en medewerkertransactieregels met haar verdwijnen. Onomkeerbaar, met grote impact. Schrijven. |
Werktijden
Tools
| workTimes_get | Haal één werktijdregel op via id — datum, minuten, project, notities en de medewerker aan wie hij toebehoort. |
| workTimes_list | Toon werktijdregistraties (geregistreerde uren). Filter op periode (date.after / date.before, YYYY-MM-DD) en optioneel op employee of project; pagineer met cursor. Elke rij bevat employeeId/employeeName en projectId/projectName, dus zo exporteer je alle geregistreerde uren voor een periode. BELANGRIJK: organisatiebrede resultaten vereisen ROLE_WORKING_HOURS_VIEWER. Zonder die rol geeft de backend GEEN foutmelding — hij geeft stilzwijgend alleen de eigen registraties van de verbonden gebruiker terug, waardoor een export van "ieders uren" met slechts één persoon terug kan komen en er toch volkomen normaal uitziet. Als elke rij bij dezelfde medewerker hoort en je niet op employee hebt gefilterd, bevat de respons een scopeWarning die dit meldt — geef die door aan de gebruiker in plaats van het resultaat als organisatiebreed te presenteren. |
| workTimes_log | Log een urenregistratie voor de gekoppelde Flowtly-gebruiker (date, durationMinutes, project, notes). DE NOTITIE MOET DE THIN-DESCRIPTION-CONTROLE VAN DE SERVER DOORSTAAN, waar een batch-backfill herhaaldelijk tegenaan loopt: er is OFWEL ongeveer 32 tekens nodig (de exacte ondergrens is een instelling per organisatie, en een organisatie kan deze op 0 zetten om de controle uit te schakelen) OF een "#"-ticketverwijzing OF een http(s)-link — elk van de drie volstaat. "Flowtly – Scallier" wordt geweigerd; "Flowtly – Scallier #FLOW-123" niet. De 422 noemt propertyPath `description`, de naam die de server gebruikt voor het veld dat deze tool `notes` noemt. Schrijven. |
| workTimes_update | Corrigeer één gelogde urenregistratie via id — de datum, minuten, project of description. Zo wordt een verkeerd ingeboekte registratie tussen projecten VERPLAATST: workTimes_log maakt alleen ooit aan, dus zonder dit blijft een verkeerd project of een typfout in de description permanent. Lees de registratie eerst met workTimes_get. Dezelfde thin-description-controle geldt als bij workTimes_log: ongeveer 32 tekens — de ondergrens is een instelling per organisatie en kan 0 zijn, wat de controle uitschakelt — OF een "#"-ticketverwijzing OF een http(s)-link, elk van de drie volstaat. Schrijven. |
| workTimes_delete | Verwijder één gelogde urenregistratie via id. Voor een duplicaat of een registratie tegen werk dat nooit heeft plaatsgevonden — geef de voorkeur aan workTimes_update wanneer de registratie echt is maar fout, zodat de uren in het record blijven staan in plaats van eruit te verdwijnen. Gelogde uren voeden de projectfinanciën en de bezettingsgraad, dus een delete wijzigt stilzwijgend gerapporteerde cijfers over een verstreken periode. Schrijven. |
Klantcontacten
Tools
| clientContacts_create | Maak een contactpersoon aan voor een klant (client, type, name, email verplicht). Schrijfactie. |
Bankrekeningen tegenpartij
Tools
| counterpartyBankAccounts_create | Koppel een bankrekening aan een tegenpartij (counterparty + accountNumber). Schrijfactie. |
Betalingsschemaregels
Tools
| paymentScheduleLines_import | Laad het complete betalingsschema van een contract in één aanroep, in plaats van één round trip per regel. Gebouwd voor ontwikkelaarscontracten, die in bouwtermijnen worden betaald — één verkoop is zes tot twaalf termijnen, en een register ervan telt honderden. Elke rij benoemt het contract OP NAAM (voor een geïmporteerd ontwikkelaarscontract het overeenkomstnummer), een vervaldatum, en een bedrag in KLEINSTE EENHEDEN — grosze, dus 5.300,00 is "530000" en "5300" boekt stilzwijgend 53,00. Rijen worden verzoend met de regels die er al staan op basis van contract+datum+bedrag+notitie, dus een onbekende regel wordt aangemaakt, een identieke wordt overgeslagen, en dezelfde batch opnieuw uitvoeren verandert niets; PaymentScheduleLine heeft geen kolom voor externe referenties, dus die natuurlijke sleutel is de verzoeningssleutel. Een rij waarvan de contractnaam met niets matcht, of met MEER dan één contract matcht, wordt gerapporteerd als mislukt in plaats van aan een gok gekoppeld — een termijn op het verkeerde contract zetten geeft twee cashflows tegelijk verkeerd weer. Geef eerst dryRun:true mee bij een echte load. Max 1000 rijen. Schrijven. |
| paymentScheduleLines_create | Voeg één termijn toe aan het betalingsschema van een contract — het plan van wat naar verwachting wordt gefactureerd of betaald, en wanneer. Geef de contract-IRI, een datum en een bedrag mee. Dit lost het probleem van een ontbrekend betalingsschema op dat contracts_get rapporteert bij een niet-cyclisch contract: ook een eenmalige vergoeding heeft een schema, dat is dan gewoon één regel voor het hele bedrag op de vervaldag. Cyclische contracten worden hier niet op gecontroleerd, omdat het systeem geen regels automatisch genereert vanuit een cadans. HET BEDRAG STAAT IN KLEINSTE EENHEDEN — grosze, niet złoty: 5.300,00 is "530000", en "5300" boekt stilzwijgend een regel van 53,00. De API geeft ze op dezelfde manier terug, dus lees er een terug met contracts_paymentScheduleLines als je twijfelt over de schaal. Lees het resultaat terug met contracts_paymentScheduleLines. Schrijven. |
| paymentScheduleLines_update | Wijzig één betalingsschemaregel via id — de datum, het bedrag of de notitie. Gebruik dit wanneer een termijn opschuift of opnieuw wordt onderhandeld, in plaats van te verwijderen en opnieuw aan te maken, zodat de regel elke factuur behoudt die er al aan is gekoppeld. HET BEDRAG STAAT IN KLEINSTE EENHEDEN — grosze, niet złoty: 5.300,00 is "530000", en "5300" boekt stilzwijgend een regel van 53,00. De API geeft ze op dezelfde manier terug, dus lees er een terug met contracts_paymentScheduleLines als je twijfelt over de schaal. Schrijven. |
| paymentScheduleLines_delete | Verwijder één betalingsschemaregel via id. Verwijdert het PLAN, niet het geld: een factuur of transactie die al aan de regel is gekoppeld, wordt niet beïnvloed, maar wordt niet langer ergens tegen verzoend. Geef de voorkeur aan paymentScheduleLines_update voor een termijn die is opgeschoven. Schrijven. |
Logo organisatie
Tools
| organizationLogo_upload | Upload/vervang het logo van de organisatie (base64-afbeelding + contentType + filename). Lees het huidige logo via configs_get organization-logo-url. Schrijfactie. |
Icoon organisatie
Tools
| organizationIcon_upload | Upload/vervang het icoon/de favicon van de organisatie (base64-afbeelding + contentType + filename). Lees het huidige icoon via configs_get organization-icon-url. Schrijfactie. |
Opslag
Tools
| storage_upload | Voeg een bestand toe aan elk record dat de generieke storage van Flowtly accepteert — een ASSET (relationName "property"), een project, een taak, een client, een locatie, een contractor, een factuur. Dit is de enige route naar een asset-AFBEELDING: uploaden met relationName "property" stelt de afbeelding in die de app voor dat asset toont (aangeboden als `file` in de asset-payload). Property heeft geen afbeeldingskolom -- de afbeelding wordt bij het lezen afgeleid uit deze tabel, wat verklaart waarom niets op de entiteit zelf erop wijst dat deze bestaat. Het is ÉÉN slot en de nieuwste upload wint, dus een tweede afbeelding vervangt de eerste in plaats van aan een galerij toe te voegen. Hetzelfde geldt voor location, invoices en transaction-attachments; clients, agreements en candidates verzamelen in plaats daarvan elke upload onder `files`. ELKE ANDERE RELATIE KOPPELT DE UPLOAD AAN NIETS ZICHTBAARS, en relationName "employees" is degene waarmee je voorzichtig moet zijn: die slaat de bytes op en maakt GEEN Document aan, dus People > Documents blijft leeg en de employee-payload bevat geen bestand. De /documents-route op elk record geeft Document-entiteiten terug, en een upload maakt er geen aan — zo kwam het dat ondertekende NDA- en ESOP-pdf's als gearchiveerd werden gemeld terwijl het tabblad Documents niets toonde (#255). Een echt werknemersdocument vereist POST /documents met een DocumentType waarvan de relationName `employee` is, de employee-id, en de IRI van de Storage-rij die deze aanroep teruggeeft. STEL DAT NIET HANDMATIG SAMEN: gebruik employeeDocuments_createUploadTicket, dat alle drie de stappen uitvoert — de bytes opslaat, het Document aanmaakt en het terugleest via /people/{id}/documents — en opgeslagen / gekoppeld / geverifieerd afzonderlijk rapporteert. Deze tool stopt bij de bytes. Grijp ook niet naar agreementTypes.*: een AgreementType is het type van een arbeidsCONTRACT (Umowa o pracę, Umowa zlecenie) onder Ludzie > Umowy, en is geen DocumentType. Rapporteer bytes opgeslagen, bedrijfsrecord gekoppeld en zichtbaarheid geverifieerd als drie afzonderlijke claims, en beweer alleen die je daadwerkelijk hebt gedaan. `file` wordt weggelaten uit LIST-responses tenzij het request ?include=file meegeeft, dus lees één record terug om te bevestigen dat de afbeelding is geland. Geef relationName + relationId mee (de id vanuit de list-tool van dat record; een /assets/7-IRI wordt geaccepteerd en gereduceerd) plus de bytes als base64 met een contentType en filename. GROOTTELIMIET: de bytes reizen als base64 binnen deze aanroep, dus houd het onder ongeveer 150 KB — foto's zitten daar bijna altijd boven, en gebruik daarvoor storage_createUploadTicket, dat geen plafond heeft. De rechten zijn wat het bewerken van het EIGENAAR-record vereist: de backend lost relationName op naar die entiteit en vraagt het aan de eigen voter daarvan, dus archiveren bij een asset vereist de assets-permissie, bij een client die van clients. Geef voor een contract de voorkeur aan contractAttachments_create — dat wist ook contracts.problem_missing_document, wat deze tool niet doet. Schrijven. |
| storage_createUploadTicket | Genereer een kortlevend, eenmalig ticket voor het toevoegen van een GROOT bestand aan elk record — zo komen asset-AFBEELDINGEN daadwerkelijk binnen, omdat een afbeelding altijd voorbij de base64-limiet gaat. Bij property/location/invoices/transaction-attachments wordt de nieuwste upload de zichtbare afbeelding van het record, ter vervanging van de vorige; bij clients/agreements/candidates stapelen uploads zich op. Gebruik dit in plaats van storage_upload zodra het bestand meer dan een paar tientallen KB is: die tool draagt de bytes als base64, wat een aanroeper als tekst moet uitzenden, en een JPEG van 400 KB wordt ~533K base64-tekens, ver voorbij wat in één response past. Geef relationName + relationId plus een filename mee; je krijgt een uploadUrl en een direct uitvoerbare curl terug. Stuur vervolgens de RUWE BYTES van het bestand naar die URL (curl --data-binary @photo.jpg) — geen base64, geen multipart — en de response bevat het aangemaakte Storage-record. Het ticket verloopt na 15 minuten, werkt eenmalig, en kan alleen tegen het ene genoemde record indienen. Schrijven. |
Contractbijlagen
Tools
| contractAttachments_create | Voeg een document toe aan een contract — normaal gesproken de ondertekende PDF, of een annex (DPA, SLA, prijsannex) die erbij wordt gearchiveerd. Geef de bytes als base64 mee met een fileName en het contract-id vanuit contracts_list; `contractId` is hier een KALE id, in tegenstelling tot de IRIs die contracts_update gebruikt voor counterparty en project, al wordt een volledige /contracts/<id>-IRI geaccepteerd en ontdaan van omhulsel. GROOTTELIMIET: de bytes reizen als base64 binnen deze aanroep, dus het hele document moet in één modelresponse passen — houd het onder ongeveer 150 KB, en gebruik voor alles groter contractAttachments_createUploadTicket, dat precies hiervoor is gebouwd en geen dergelijk plafond heeft. Een ondertekend contract met een handtekeningkaart zit doorgaans ruim daarboven (673.617 bytes wordt 898.156 base64-tekens, meerdere keren zoveel als één response kan dragen), en er komt geen foutmelding terug wanneer het niet past, omdat de aanroep helemaal niet kan worden verzonden — het request bereikt de server nooit, dus controleer de bestandsgrootte VOORDAT je begint in plaats van dit te ontdekken door te falen. Dit lost het probleem van een ontbrekend document op dat contracts_get rapporteert, zodat een contract dat via de API wordt onderhouden niet meer in de opruimwachtrij van de app blijft staan. Eén ondertekend document kan meerdere contractrijen onderbouwen (een deal met zowel een terugkerend als een eenmalig deel is twee rijen, omdat `cyclic` per record geldt) — roep dit één keer per contract-id aan met dezelfde bytes. Wat er daarna gebeurt, hangt af van kind. kind "contract": `status` komt terug als "analyzing" en de backend leest het document asynchroon, normaal gesproken binnen enkele minuten; poll contracts_get totdat de bijlage "analyzed" of "failed" is (een mislukking bevat failureReason en failureRetryable). Het lezen VULT alleen LEGE velden van het contract en overschrijft nooit een naam, richting, bedrag, datums, valuta, betalingsvoorwaarden, schemaregels of prijzen die er al op staan; elke geëxtraheerde waarde blijft in de analysisSummary van de bijlage staan, en analysisSummary.notApplied somt op wat als suggestie is achtergelaten. kind "annex": opgeslagen en NIET geanalyseerd; `status` is "stored", wat definitief is, en het contract verandert niet. Behandel analysisSummary als een SUGGESTIE om te controleren in plaats van een feit om op te vertrouwen. Schrijven. |
| contractAttachments_createUploadTicket | Genereer een kortlevend, eenmalig ticket voor het toevoegen van een GROOT document aan een contract — de ondertekende PDF, of een annex. Gebruik dit in plaats van contractAttachments_create zodra het bestand meer dan een paar tientallen KB is: die tool draagt de bytes als base64, wat een aanroeper als tekst moet uitzenden, en een echt ondertekend contract (~700 KB, ~900K base64-tekens) is ver voorbij wat in één response past. Geef het contract-id vanuit contracts_list plus een fileName mee; je krijgt een uploadUrl en een direct uitvoerbare curl terug. Stuur vervolgens de RUWE BYTES van het bestand naar die URL (curl --data-binary @file.pdf) — geen base64, geen multipart — en de response is de aangemaakte bijlage. Het ticket verloopt na 15 minuten, werkt eenmalig, en kan alleen bij het ene genoemde contract worden toegevoegd. Dit lost het probleem van een ontbrekend document op dat contracts_get rapporteert. Schrijven. |
Factuurtransacties
Tools
| invoiceTransactions_create | Registreer een betaling op een uitgaande (verkoop)factuur. `invoice` is een factuur-IRI uit invoices_list; `date` is wanneer de betaling als gedaan wordt beschouwd. `transaction` is optioneel — laat het weg om een afwikkeling zonder bankregel vast te leggen, wat je wilt voor historische facturen waarvan het bankafschrift nooit is geïmporteerd. `amount` is optioneel en valt standaard terug op het openstaande bedrag van de factuur. Het registreren van een betaling zorgt ervoor dat een uitgegeven, vervallen factuur niet als onbetaald wordt behandeld, en dus ook dat er geen betalingsherinneringen meer voor in de wachtrij worden gezet. Niets voorkomt dat je twee betalingen op één factuur registreert, dus lees eerst invoices_get als je niet zeker weet of er al is afgewikkeld. Schrijfactie. |
| invoiceTransactions_update | Werk een bestaand factuurbetalingsrecord bij op id (uit de invoiceTransactions van invoices_get, of door invoiceTransactions te pagineren). Het meest voorkomende gebruik: koppel een betaling die zonder bankregel is geregistreerd aan een transactie die je zojuist hebt geïmporteerd via transactions_importStatement, door `transaction` in te stellen op een transactie-IRI/id uit transactions_list. DE VALKUIL: dit is een PATCH, maar de backend vereist bij elke aanroep nog steeds `invoice` en `date` — de bestaande waarden worden NIET automatisch samengevoegd. Lees het record eerst (of heb het al van de create-aanroep) en stuur `invoice` en `date` ongewijzigd opnieuw mee naast wat je daadwerkelijk wilt wijzigen, anders wordt de update geweigerd. `transaction` accepteert null om een betaling van een bankregel los te koppelen. `amount` is optioneel. Schrijfactie. |
| invoiceTransactions_delete | Verwijdert een betalingsregistratie van een factuur op id — de ids lees je uit invoiceTransactions van invoices_get. Dit haalt DE VASTLEGGING DAT EEN FACTUUR BETAALD IS weg, niet een banktransactie: gebruik het wanneer een factuur een betaling draagt die er nooit had mogen zijn, meestal dezelfde betaling die twee keer is geboekt — een keer met de hand en een keer door de afschriftimport die haar later matchte. Raadpleeg eerst invoices_get en verwijder de registratie waarvan de `transaction` de verkeerde is (bewaar degene die naar de echte geïmporteerde bankregel wijst); het verwijderen van de laatste betaling maakt de factuur weer onbetaald, waardoor de betalingsherinneringen ervoor opnieuw scherp staan. Vereist ROLE_INVOICES_MANAGER. Onomkeerbaar, met grote impact. Schrijven. |
Resourcing
Tools
| resourcing_importTimeline | Importeer een resourcing-allocatie-tijdlijnsheet (haal deze op via de Drive MCP, geef de CSV letterlijk mee). Dit is een VOLLEDIGE VERVANGING (mirror) van de Allocation-rijen van de organisatie voor `year`: rijen in de sheet worden aangemaakt/bijgewerkt, en elke bestaande rij voor dat jaar die niet in de sheet voorkomt, wordt VERWIJDERD — geen samenvoeging. STANDAARD DRY-RUN: een weggelaten dryRun toont een voorbeeld en schrijft niets; geef dryRun:false mee om toe te passen. Het rapport geeft `created` / `replaced` plus `unmatchedPeople` / `unmatchedProjects`. TWEE DINGEN ZIJN GEMAKKELIJK TE MISSEN: een sheetrij waarvan het project niet kan worden opgelost, wordt OVERGESLAGEN terwijl de aanroep toch succes rapporteert, dus een groen resultaat kan een gedeeltelijke import verbergen; en een rolcode die de functiecatalogus nog niet bevat, wordt AANGEMAAKT als een nieuwe positie in plaats van geweigerd — zie `createdPositions`. Beide worden vermeld in `warnings` wanneer ze zich voordoen; breng dit onder de aandacht van de gebruiker in plaats van alleen `created` te rapporteren. Een sheet die naar nul rijen wordt geparsed, wordt geweigerd (het lijkt precies op een mislukte lezing die de hele tijdlijn dreigt te wissen) tenzij je force:true meegeeft. Lees achteraf allocations_list om te zien wat er is beland. Grote impact. Schrijfactie. |
Organisatie
Tools
| organization_whoami | Geeft de organisatie terug waaraan deze MCP-verbinding is gekoppeld — { orgId, name, slug, userId }. Roep dit aan om te bevestigen in WELKE tenant je op het punt staat te schrijven vóór elke create/update: de verbinding is via het token aan precies één organisatie gekoppeld, en prospects/records naar de verkeerde organisatie schrijven is een echt incident. Alleen-lezen. |
Resourcing-realisatie
Tools
| resourcingActuals_get | Gerapporteerde uren versus het plan, per persoon per week, over een from/to-venster — de vraag 'ligt het team echt op schema?', die GEEN enkele andere resourcing-tool beantwoordt: allocaties vertellen je wat er GEPLAND was, dit vertelt je wat er is GELEVERD. Geeft weekkolommen terug plus één rij per persoon (gepland %, gerapporteerd %, afwijking, totalen en een uitsplitsing per project). reportedPercent null betekent 'geen contract die week' en 0 betekent 'er bestond een contract en er is niets gerapporteerd' — behandel deze twee NIET als hetzelfde. Geef financials mee voor omzet/kosten/marge, die anders worden weggelaten. Vereist de resourcing-module en ROLE_RESOURCING_MANAGER. Alleen-lezen. |
Resourcing-bench
Tools
| resourcingBench_get | Wie er NIET is ingezet over een from/to-venster — de bench. Gebruik dit wanneer gevraagd wordt wie op een nieuw project te zetten of waar capaciteit onbenut blijft; resourcingActuals_get vertelt je hoe belast mensen zijn, dit vertelt je wie helemaal geen belasting heeft. HET WEET NIETS VAN VERLOF: freePercent is 100 min bevestigde allocaties, verder niets, dus iemand met drie weken goedgekeurd verlof komt uit op 100% vrij en geen enkel veld in de respons zegt anders. Als je 'wie is beschikbaar' alleen hierop baseert, zet je mensen op projecten terwijl ze afwezig zijn — controleer holidays_active of holidays_list. Vereist de resourcing-module. Alleen-lezen. |
Resourcingplanning
Tools
| resourcingSchedule_get | De geplande resourcingplanning over een from/to-venster — de allocatietijdlijn zoals de planner die toont. Gebruik dit voor wat er vooruitkijkend is GEBOEKT; gebruik resourcingActuals_get voor wat er daadwerkelijk tegenover is gerapporteerd. Vereist de resourcing-module en ROLE_RESOURCING_MANAGER. Alleen-lezen. |