MCP-server

Forbind AI-værktøjer til Flowtly gennem Model Context Protocol på mcp.flowtly.eu.

Connect

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

På denne side

Aftaler

Tools

agreements_getHent én ansættelsesaftale ud fra id — type, variant, dateFrom/dateTo-vinduet, hoursPerWeek samt de afledte `calculable`, `active` og `status`. agreements_list leverer id'et. Kræver ROLE_AGREEMENTS_MANAGER eller ROLE_MEETING_MANAGER. Skrivebeskyttet.
agreements_listVis ansættelsesaftaler — filtrér på employee (IRI), isActive, type eller variant. DEN måde at besvare "hvorfor siger people_list at denne person er inaktiv" på: hver række har `calculable` og `active`, og en person er aktiv præcis når vedkommende har én, der er begge dele. Også stedet at læse de `type`-koder for aftaler, som denne organisation rent faktisk bruger, før agreements_create kaldes, da en organisation kan tilføje sine egne. Kræver ROLE_AGREEMENTS_MANAGER eller ROLE_MEETING_MANAGER. Skrivebeskyttet.
agreements_createOpret en ansættelsesaftale for en person. DETTE ER TRINNET, DER GØR NOGEN AKTIV: people_create opretter kun posten, og en person uden aftale rapporterer isActive false for evigt — en bulkimport lander derfor 100 % inaktiv, indtil dette køres for hver enkelt af dem. TO TING SKAL BEGGE VÆRE SANDE, ellers forbliver de inaktive uden fejl: `type` skal være en, der er BEREGNELIG (de indbyggede "agreement", "annex", "termination" er det; "list-of-intent" og "work-experience" er det ikke), og dateFrom/dateTo-vinduet skal dække i dag (send dateTo som null for en igangværende kontrakt frem for en dato langt ude i fremtiden). `employee` er en IRI — /people/<id> fra people_list. Typer kan udvides pr. organisation, så kør agreements_list på nogen, der allerede er aktiv, for at se de koder, denne organisation reelt bruger. Kræver ROLE_AGREEMENTS_MANAGER. Skrivning.
agreements_updateRet en eksisterende ansættelsesaftale — sådan AFSLUTTES en aftale, fordi backend'en ikke stiller nogen sletning til rådighed for denne ressource: sæt `dateTo` til den sidste dag, den dækker, og personen stopper med at være aktiv fra da af, med posten og dens historik intakt. Det er det rigtige træk for en lønrelateret række; der findes ingen måde at få en til at forsvinde på, og sådan bør det være. Også måden at rette en forkert `type`, `variant` eller `positionName` på stedet frem for at stable en anden aftale oven på personen — TO aftaler ophæver ikke hinanden, den beregnelige holder dem aktive, så "tilføj en korrekt en ved siden af" efterlader tavst den forkerte gældende. `amount`, `amountType` og `billingType` accepteres, men API'et returnerer dem aldrig, så du kan ikke læse tilbage, hvad du skrev. Kræver ROLE_AGREEMENTS_MANAGER. Skrivning.

Aftaletyper

Tools

agreementTypes_getHent én kontrakttype ud fra id — dens name eller translationKey, `calculable`, `isActive`, `position` og `builtIn`. id'et ER koden, så dette henter en type tilbage ud fra den samme streng, som en aftale gemmer i `type`. Brug det til at bekræfte, at en type blev gemt efter agreementTypes_create, og til at tjekke `calculable`, før nogen sættes på den. Kræver ROLE_USER. Skrivebeskyttet.
agreementTypes_listVis de kontrakttyper, DENNE organisation kan sætte på en aftale — værdierne bag `Ludzie > <person> > Umowy > Edytuj umowę`. Læs den før agreements_create eller agreements_import, fordi listen er pr. tenant: fem indbyggede følger med ("agreement", "annex", "termination", "list-of-intent", "work-experience"), og en organisation kan tilføje sine egne, så en `type`, der er gyldig i én organisation, giver 422 i en anden. ID'ET ER KODEN — `id` på hver række er præcis den streng, `agreements_create` forventer i `type`, ikke en numerisk nøgle, der skal slås op. `calculable` er feltet, der afgør, om det at have denne type gør nogen AKTIV og tæller dem med i resourcing-bænken, ferieoptjeningen og omkostningsgrundlaget; en ikke-beregnelig type efterlader dem inaktive uden fejl nogen steder, hvilket er tilsigtet for en type som "list-of-intent" og en tavs fejl, hvis den er valgt ved et uheld. `builtIn`-rækker har en translationKey og et null name; brugerdefinerede rækker har et name, der vises ordret, og en null translationKey. Kræver ROLE_USER. Skrivebeskyttet.
agreementTypes_createTilføj en kontrakttype til DENNE organisations liste, så en aftale kan registreres mod noget, de fem indbyggede ikke dækker — "Umowa zlecenie", "Kontrakt B2B", "Użytkownik funkcyjny". Dette er konfiguration, ikke en kodeændring: listen er en tabel pr. tenant, og en brugerdefineret type kræver ingen oversættelsespost, fordi dens `name` vises ordret i alle syv sprogversioner. SEND IKKE `id`: koden slugges ud fra name på serversiden med diakritiske tegn foldet væk ("Użytkownik funkcyjny" bliver til "uzytkownik-funkcyjny"), og hvis et id sendes, afvises det med 422 "Update is not allowed for this operation". Post name'et og læs den tildelte kode tilbage fra svaret. `calculable` ER SOM STANDARD FALSE OG ER TAVS: den afgør, hvem der tæller som ansat — resourcing-bænken, ferieoptjeningen, omkostnings- og budgetgrundlaget — så en type beregnet til personer, der IKKE bør optjene ferie eller optage en fuldtidsstilling, er korrekt sat til false, og en type beregnet til reel ansættelse SKAL sætte den til true, ellers rapporterer alle på den inaktiv uden fejl. Intet fortæller dig, hvad du fik. `position` sorterer rullelisten; `isActive` er som standard true. Der findes bevidst ingen opdatering eller sletning via MCP — `agreement.type` gemmer denne rækkes id som en ren streng uden fremmednøgle, så omdøbning eller fjernelse af en type gør alle aftaler, der peger på den, forældreløse. Kræver ROLE_AGREEMENTS_MANAGER. Skrivning.

Allokeringer

Tools

allocations_getÉn allokering ud fra id — én persons booking på et projekt, med datoer og procentsats. allocations_list finder id'et; denne læser den fulde post. En allokering uden en medarbejder er en ÅBEN rolle (udækket behov), ikke en booking. Kræver ressourcemodulet. Skrivebeskyttet.
allocations_listVis ressourceallokeringer — datoafgrænsede tildelinger af en position på et projekt til en medarbejder (eller endnu ingen, en åben rolle). Ingen filtre; sideinddeles med cursor. Hvert element indeholder employeeId/employeeName og projectId/projectName allerede opløst (null employeeId betyder en åben rolle); positionId er rå — find navnet via positions_list. source skelner mellem rækker importeret fra ark og dem, der er oprettet direkte i Flowtly. Brug denne til at afstemme en ressourcearkimport: læs, hvad der blev registreret, og sammenlign med det, der blev indsendt.

Aktivbookinger

Tools

assetBookings_getHent én aktivbooking ud fra id — aktivet, dets indehaver, datoerne, og om den er blevet annulleret. Skrivebeskyttet.
assetBookings_listVis aktivbookinger — hvem eller hvad der aktuelt har hvert aktiv, hvilket er den tildeling, Aktiver-skærmen viser, og det eneste sted en aktiv-til-person-forbindelse faktisk findes. Hver række har aktivet, indehaveren (`relationName` employee | project plus `relationId`), start-/slutdatoer og, når det er frigivet, `cancelReason` og `cancelledAt`. Filtrér på `property` for at se ét aktivs historik, eller på `employee` for at se alt, én person har — det sidste er det, man kører, før nogen forlader organisationen. Bemærk at `employee` her er det NUMERISKE id, ikke den /people-IRI, som assetBookings_create tager. Tilføj `exists.cancelledAt: false` for kun at se det, der stadig er i brug; uden den inkluderer listen også frigivne bookinger. Skrivebeskyttet.
assetBookings_createTildel et aktiv til en person eller et projekt. `property` er aktiv-IRI'en (/assets/{id}) og er påkrævet. Navngiv indehaveren på ÉN af tre måder: `relation` med en enkelt IRI (/people/{id} for en person, /projects/{id} for et projekt), eller `relationName` (employee | project) plus `relationId`, eller feltet `employee`/`project`-IRI direkte. Præcis én indehaver skal løses op — hvis ingen navngives, afvises det med "Employee or Project must be set.", og hvis begge navngives, afvises det med "Employee and Project cannot be set at the same time." TO TING, DER IKKE ER I SKEMAET OG VIL GIVE DIG 422: aktivet skal allerede kunne reserveres (`bookingAllowed: true` — sæt det med assets_update), en forretningsregel, der håndhæves for ALLE kaldende parter, inklusive en manager, afvist med "This asset is not reservable."; og aktivets eget `bookingType` (minutes | days | single-days | permanently) er det, der giver mening til `duration`/`endDate` — en plads dedikeret til én person på ubestemt tid er `permanently` med en `startDate` og ingen slutning. Samtidige bookinger på ét aktiv serialiseres på serversiden, så et overlap afvises frem for at blive dobbeltbooket. Kræver ROLE_PROPERTY_BOOKINGS_MANAGER for at booke på vegne af en anden. Skrivning.
assetBookings_updateOpdatér en eksisterende aktivbooking — dens datoer, varighed, faktureringsbeløb/valuta eller andel af målt forbrug. `relationName` og `relationId` er påkrævet i payloaden, så send den indehaver, bookingen allerede har, medmindre du bevidst flytter den. For at afslutte en tildeling, brug assetBookings_cancel, ikke en endDate i fortiden. Kræver ROLE_PROPERTY_BOOKINGS_MANAGER. Skrivning.
assetBookings_cancelFrigiv et aktiv — sådan afsluttes en tildeling, og det tætteste denne ressource kommer på en sletning (der findes ingen sletningshandling). Tager booking-id'et og en `cancelReason` på 3-255 tegn; bookingen bevares og stemples med `cancelledAt`, så historikken overlever, og aktivet bliver ledigt for den næste indehaver. Dette er kaldet, der skal foretages, når en medarbejder forlader organisationen: assetBookings_list filtreret på `employee` finder, hvad de har, og dette frigiver hver enkelt. Kræver ROLE_PROPERTY_BOOKINGS_MANAGER. Skrivning.

Måleraflæsninger for aktiver

Tools

assetMeterReadings_getHent én måleraflæsning ud fra id — dens måler, dato og værdi. Skrivebeskyttet.
assetMeterReadings_listVis måleraflæsninger — de daterede værdier, der er registreret på en aktivmåler, de rådata, som forbrugsafregningsfordelingen læser. Hver række har måleren, dato og værdi. Brug den til at læse en målers historik: en værdi, der aldrig ændrer sig på tværs af perioder (en fastlåst eller delt måler), fakturerer nul, og en måler uden nylige rækker er en, ingen aflæser. Skrivebeskyttet.

Aktivmålere

Tools

assetMeters_getHent én aktivmåler ud fra id — aktivet, den sidder på, forsyningstype, enhed og eksternt/QR-id, samt dens aflæsninger. Skrivebeskyttet.
assetMeters_listVis organisationens aktivmålere — de forsynings-/medieforbrugsmålere, der er knyttet til aktiver (el, vand, gas, varme). Hver har det aktiv, den sidder på, sin forsyningstype og enhed samt sine aflæsninger. Filtrér på `property` (det aktiv, den hører til) og `utilityType`. Brug den til at finde det meter-id, som aflæsninger tager, og til at få øje på målere, der viser nul, er fastlåst på én værdi, eller sidder på en delt/fælles måler. Skrivebeskyttet.
assetMeters_updateOpdatér en aktivmåler — dens label, forsyningstype, enhed eller aktiv tilstand. Brug den til at udfase en måler fra måling (fx en forsyning, der nu faktureres direkte fra fakturaen), uden at slette dens aflæsningshistorik. Kræver ROLE_PROPERTIES_MANAGER. Skrivning.

Aktiver

Tools

assets_getHent ét aktiv ud fra id — name, status, kategori (attributeSet), parent, assetCode, serienummer, købs- og garantidatoer, lokation og bookingindstillinger. Skrivebeskyttet.
assets_listVis organisationens aktiver — registret over fysiske ting, den ejer eller sælger, fra bærbare computere og skriveborde til lejligheder, parkeringspladser og opbevaringsenheder. Filtrér på status (in-stock | damaged | sold), attributeSet (kategorien, Aktiver-listen grupperer efter), bookingAllowed, eller et delvist name eller serialNumber; sortér på name, status, serialNumber, boughtAt eller warrantyTo. IKKE PAGINERET — hele mængden kommer tilbage i ét svar, så et stort register er én stor payload frem for en første side. Brug den til at finde det aktiv-id, som aktivbookinger og aktivdokumenter tager. Skrivebeskyttet.
assets_importIndlæs MANGE aktiver i ét kald, nøglet på `assetCode` — værktøjet til at overføre en beholdning fra et andet system, hvor assets_create ville være én tur-retur pr. post. Rækker afstemmes mod organisationen: en ukendt assetCode opretter, en kendt opdaterer på stedet, en matchende række springes over, så en gentaget kørsel ikke ændrer noget, og en halvfærdig kørsel er sikker at gentage. `parentAssetCode` indlejrer en række under en anden UD FRA DENS CODE, som løses op mod organisationen og mod tidligere rækker i samme batch; en parent, der aldrig løses op, fejler for den række frem for tavst at gøre den forældreløs. TRE FELTER GØR POSTEN LÆSBAR frem for et rent name: `attributeSetName` er den kategori, brugerfladen viser som Typ zasobu, og som listen grupperer efter, `locationName` er, hvor tingen fysisk befinder sig, og `attributes` er et {name: value}-map for areal, etage, pris og alt andet, kilden bærer. Alle tre løses op UD FRA NAME — kategorien, lokationen, attributdefinitionerne og deres bindinger findes eller oprettes for dig, så en kaldende part aldrig håndterer én af de IRI'er, og navne matches uden hensyn til store/små bogstaver, så "Mieszkanie" og "mieszkanie " ikke kan splitte listen i to. `attributes` kræver en kategori at hænge på, og en værdi, der kan fortolkes som et tal, opretter en talattribut, hvilket afgøres første gang navnet optræder. En attribut, der ikke kan skrives, får IKKE sit aktiv til at fejle. SEND dryRun:true FØRST ved en reel beholdningsindlæsning — det rapporterer would-create / would-update / would-skip pr. række og opretter slet intet, kategorier og lokationer inklusive. Maks. 1000 rækker. Kræver ROLE_PROPERTIES_MANAGER. Skrivning.
assets_createOpret et aktiv (name + status + bookingType påkrævet; status = in-stock | damaged | sold, bookingType = minutes | days | single-days | permanently). bookingType er påkrævet, selv når aktivet aldrig bookes — send "permanently" for noget, der ikke udlånes, og lad bookingAllowed være false. To felter bærer strukturen: `parent` indlejrer et aktiv under et andet (en enhed under en bygning, en skærm under et skrivebord), og `attributeSet` sætter den kategori, Aktiver-listen grupperer efter, hvilket også er der, brugerdefinerede attributter som areal eller etage findes. `assetCode` er et UNIKT håndtag på tværs af systemer — brug det til at holde det id, aktivet har i det kildesystem, det blev importeret fra, så en genimport opdaterer frem for at duplikere. Kræver ROLE_PROPERTIES_MANAGER. Skrivning.
assets_updateOpdatér et aktiv ud fra id — name, status, kategori, parent, assetCode, serienummer, datoer, lokation eller bookingindstillinger. Sådan flytter et aktiv sig fra in-stock til sold. Bemærk at status-vokabularet er in-stock | damaged | sold og har INGEN reserveret tilstand, så en reservation skal modelleres på anden vis. Kræver ROLE_PROPERTIES_MANAGER. Skrivning.

Attributværdier for entiteter

Tools

attributeEntityValues_listVis attribut-VÆRDIER — hvad et specifikt aktiv, projekt, budget eller en specifik klient rent faktisk har for en bundet attribut. Hver række har attributten, værdien og `relationId`, der navngiver den entitet, den hører til. Skrivebeskyttet.
attributeEntityValues_createSæt en attributværdi på én entitet (attribute + value påkrævet). `relation` ER EN IRI — "/properties/7", ikke ordet "property": backend'en løser den op og udleder relationsnavnet fra ressourceklassen, så et rent navn kastet ind giver en fejl. (`relationId` tager et almindeligt id og virker stadig, men er udfaset til fordel for IRI'en.) Attributten skal allerede være BUNDET til den entitets kategori, ellers gemmes værdien og vises aldrig. Kræver ROLE_ATTRIBUTES_MANAGER. Skrivning.
attributeEntityValues_updateRet én attributværdi på stedet, ud fra dens id. Brug denne frem for at oprette en anden værdi for det samme (entity, attribute)-par — intet håndhæver unikhed, så en dublet accepteres, og brugerfladen viser én af dem. Kræver ROLE_ATTRIBUTES_MANAGER. Skrivning.
attributeEntityValues_deleteFjern en attributværdi fra en entitet. Definitionen og bindingen overlever; kun denne entitets værdi forsvinder. Kræver ROLE_ATTRIBUTES_MANAGER. Skrivning.

Attributter

Tools

attributes_getHent én attributdefinition ud fra id — name, type, om den er required eller multiple, standardværdi og formatmønster. Skrivebeskyttet.
attributes_listVis attribut-DEFINITIONER — de navngivne felter (areal, etage, pris), som kategorier binder, og som aktiver bærer værdier for. Hver har en type: number | string | date | state | period. Skrivebeskyttet.
attributes_createOpret en attributdefinition (name + type påkrævet; type er number | string | date | state | period). TYPEN ER BESLUTNINGEN: den deles af enhver entitet, der bærer denne attribut, så et felt oprettet som `string` kan ikke senere summeres eller sorteres som et tal, uden at hver eneste eksisterende værdi skrives om. Beslut den ud fra de værdier, du rent faktisk har, ikke den første, du ser. En definition alene gør intet — bind den til en kategori med attributeSetAttributes_create, ellers vises den aldrig nogen steder. Kræver ROLE_ATTRIBUTES_MANAGER. Skrivning.
attributes_updateOpdatér en attributdefinition — name, type, required, multiple, default eller format. At ændre `type` på en definition, der allerede har værdier, er den risikable: eksisterende værdier konverteres ikke. Kræver ROLE_ATTRIBUTES_MANAGER. Skrivning.

Attributter i attributsæt

Tools

attributeSetAttributes_listVis bindingerne mellem kategorier og attributdefinitioner — hvilke felter der vises på hvilken kategori. Skrivebeskyttet.
attributeSetAttributes_createBind en attributdefinition til en kategori (attributeSet + attribute, begge IRI'er). DETTE ER DET, DER FÅR EN ATTRIBUT TIL AT VISES: uden bindingen kan en værdi skrives med succes på en entitet og vil aldrig vises i brugerfladen — en fejl uden symptom. Kræver ROLE_ATTRIBUTES_MANAGER. Skrivning.
attributeSetAttributes_deleteFjern bindingen mellem en attribut og en kategori. Definitionen og eventuelle værdier overlever; de holder blot op med at blive vist for den kategori, hvilket får det til at ligne datatab, selvom det ikke er det. Kræver ROLE_ATTRIBUTES_MANAGER. Skrivning.

Attributsæt

Tools

attributeSets_getHent ét attributsæt ud fra id — dets name, relationName, ikon og de attributter, der er bundet til det. Skrivebeskyttet.
attributeSets_listVis organisationens attributsæt — de KATEGORIER, et aktiv, projekt, budget eller en klient er arkiveret under. Filtrér på relationName: "property" for aktivkategorier (det brugerfladen kalder Typ zasobu, og som Aktiver-listen grupperer efter), samt "project", "budget" og "client". Brug denne, før der oprettes en: en kategori, der duplikeres pga. stavning eller store/små bogstaver, splitter tavst den liste, den grupperer, og intet i brugerfladen forklarer hvorfor. Skrivebeskyttet.
attributeSets_createOpret en kategori (name + relationName påkrævet; relationName er en af property | project | budget | client, og for en aktivkategori er det den rene streng "property" — IKKE en IRI). Valgfrit icon fra en fast liste (room, parking, building, office, local, desk, monitor og så videre), som brugerfladen viser ved siden af kategorien. VIS LISTEN FØRST: navne er ikke unikke, så en anden "Mieszkanie" accepteres og splitter tavst Aktiver-listen i to. Kræver ROLE_ATTRIBUTES_MANAGER. Skrivning.
attributeSets_updateOmdøb en kategori, skift dens ikon, eller flyt den til en anden relationName. Sådan rettes en kategori oprettet med en tastefejl, i stedet for at den duplikeres. Kræver ROLE_ATTRIBUTES_MANAGER. Skrivning.

Bankkonti

Tools

bankAccounts_getHent én bankkonto ud fra id — navn, valuta, bank, og det format dens kontoudtog importeres i.
bankAccounts_listVis organisationens bankkonti. Filtrér på bank, eller sæt hidden for at inkludere arkiverede konti. Brug den til at finde det bankAccount-id, som transactions_list filtrerer på.
bankAccounts_createOpret en bankkonto (type, name, currency, defaultImportFormat påkrævet). Skrivning.
bankAccounts_updateOpdater en bankkonto ud fra id. Skrivning.

Banker

Tools

banks_getHent én bank ud fra id — instituttet, ikke en konto oprettet i den. Brug bankAccounts_get for kontoen.
banks_listVis de banker, organisationens konti er oprettet i. Skjulte banker er INKLUDERET som standard — send hidden=false for vælgernes visning, eller hidden=true for at finde de udgåede. Brug den til at finde det bank-id, som bankAccounts_list filtrerer på, og som bankAccounts_create har brug for.
banks_createOpret en bank — instituttet, en bankkonto hører til, ikke selve kontoen (det er bankAccounts_create). Skrivning.
banks_updateOpdatér en bank ud fra id. Sådan skjules og af-skjules en bank også: sæt `hidden` til true for at udfase en fra vælgerne uden at slette den, false for at bringe den tilbage. Der findes ikke et separat arkiveringsværktøj, fordi API'et ikke har en arkiveringshandling for en bank — flaget er mekanismen. Skrivning.

Budgetter

Tools

budgets_employeePnlResultatopgørelse pr. medarbejder for et budget — hvad hver persons tid har indtjent set i forhold til, hvad de koster. Kræver ROLE_BUDGETS_VIEWER. Skrivebeskyttet.
budgets_getHent ét budget ud fra id — dets periode, omfang og indstillinger. Kræver ROLE_BUDGETS_VIEWER. Skrivebeskyttet.
budgets_listVis organisationens budgetter — de perioder, indtægter og omkostninger planlægges og sammenlignes imod. Brug den til at finde det budget-id, som alle pnl-værktøjer tager. Kræver ROLE_BUDGETS_VIEWER. Skrivebeskyttet.
budgets_pnlByTagsResultatopgørelse for et budget, opdelt PR. TAG — income, costsByTag, costsByProject og netByTag hen over budgettets perioder. Tag-aksen er det, der gør dette læsbart for en virksomhed, hvis omkostninger ikke naturligt er pr. projekt: tag dokumenterne, og opdelingen følger med. Har displayPricePerSqm, når organisationen har aktiveret pris-pr.-kvadratmeter og navngivet en arealattribut, hvilket er det, der gør dette til en pr.-kvadratmeter-visning for en ejendomsudvikler. Kræver ROLE_BUDGETS_VIEWER. Skrivebeskyttet.
budgets_pnlByTagsDrilldownDokumenterne bag én celle i budgets_pnlByTags. Brug den, når en tag-sum ser forkert ud — den navngiver de transaktioner, tallet består af, i stedet for at overlade dig til at gætte. Kræver ROLE_BUDGETS_VIEWER. Skrivebeskyttet.

Kunder

Tools

clients_getHent én kunde ud fra id — navn, land, valuta, skatte-id og status.
clients_listVis klienter (organisationens kunder). Filtrér på status eller på externalPaymentCustomerId for at finde klienten bag et id fra en betalingsudbyder. Brug den til at finde det client-id, som invoices_list, deals_list, projects_list og contracts_list alle filtrerer på.
clients_importIndlæs MANGE klienter i ét kald, nøglet på `externalRef` — værktøjet til at overføre en kunde- eller køberliste fra et andet system, hvor clients_create ville være én tur-retur pr. person. Rækker afstemmes mod organisationen: en ukendt externalRef opretter, en kendt opdaterer på stedet, en matchende række springes over, så en gentaget kørsel ikke ændrer noget. Referencen gemmes som `externalPaymentCustomerId`, den eneste eksterne referencekolonne en klient har, og `clients_list` filtrerer på den. MATCH IKKE klienter på name i stedet — en køberliste er fuld af delte efternavne og fælles køb. Hvert resultat har `counterpartyId`, som er det, contracts_import og contracts_create har brug for. To fælder, skemaet ikke kan udtrykke: en `tin` AFVISES uden en `tinCountry`, og en kontaktrække kræver en e-mail, så et telefonnummer alene ikke kan oprette en. SEND dryRun:true FØRST ved en reel onboarding-indlæsning. Maks. 500 rækker. Kræver ROLE_CLIENTS_MANAGER. Skrivning.
clients_createOpret en ny kundepost (name, country, currency, status, tinType påkrævet). Skrivning.
clients_updateOpdater en kundepost ud fra id. Skrivning.

Konfigurationsnøgler

Tools

configKeys_catalogVis alle organisationskonfigurationsnøgler, som backend'en genkender, med deres type og tilladte værdier. Dette er kataloget over, hvad der kan konfigureres — læs det før configs_get eller configs_update i stedet for at gætte på et nøglenavn. Tilladelser håndhæves pr. nøgle af backend'en, så en nøgle, der optræder her, garanterer ikke, at den tilsluttede bruger må skrive til den.

Konfigurationer

Tools

configs_getLæs én organisationskonfigurationsværdi ud fra id, hvor id'et er en nøgle fra configKeys_catalog (fx organization-logo-url, organization-icon-url).
configs_updateOpdater en organisationskonfigurationsværdi ud fra id (type + name påkrævet; rettigheder håndhæves pr. konfigurationsnøgle af backenden). Skrivning.

Kontrakter

Tools

contracts_getHent én kontrakt ud fra id — parter, retning, værdi, cykliske vilkår og datoer.
contracts_listVis kontrakter. Filtrér på direction — de gemte værdier er "out" (vi sælger/udsteder) og "in" (vi køber/modtager), plus "unknown" — en reel, filtrerbar tilstand frem for en fejl. En kontrakt oprettet ved upload af et dokument starter som "unknown" og forbliver der, indtil udtræk eller en person afklarer den, så udelad filteret for at få alle tre: "in" og "out" forespurgt hver for sig giver IKKE hele mængden tilsammen (flowtly-mcp#130). IKKE "outgoing"/"incoming": de matcher intet og kommer tilbage som en tom liste frem for en fejl. Filtrerer også på counterparty, project, cyclic, name eller tags. Brug den til at finde det contract-id, som contracts_paymentScheduleLines læser, og som deals_win kan knytte en vundet deal til.
contracts_paymentScheduleLinesVis en kontrakts betalingsplan — de rater, den forventes faktureret eller betalt i. Send contractId fra contracts_list. Dette er planen, ikke de faktiske tal: sammenhold den med transactions_list for at se, hvad der reelt er betalt. Hver linjes amount er i MINDSTE ENHEDER — grosze, ikke złoty: "530000" er 5.300,00, så divider med 100, før et tal rapporteres til nogen.
contracts_importIndlæs MANGE kontrakter i ét kald, nøglet på `name` — aftalenummeret. I modsætning til en klient eller et aktiv har en kontrakt INGEN eksterne referencekolonne, så name ER idempotensnøglen; en batch, der indeholder samme name to gange, AFVISES HELT frem for at opdatere én kontrakt to gange, fordi et duplikeret nummer betyder, at kilden er forkert. `counterpartyExternalRef` løser køberen op via samme reference, som clients_import fik, så de to spiller sammen: importér klienterne, derefter kontrakterne, uden nogensinde at håndtere et numerisk counterparty-id — en reference, der ikke matcher nogen klient, fejler for den række frem for at oprette en kontrakt uden part. `direction` er "out" (vi sælger) eller "in" (vi køber); kolonnen har ingen serverside-begrænsning, så et forkert ord gemmes, og kontrakten matcher derefter intet filter nogen steder. SEND dryRun:true FØRST. Maks. 500 rækker. Kræver ROLE_CONTRACTS_MANAGER. Skrivning.
contracts_createOpret en kontrakt. Skrivning.
contracts_updateOpdater en kontrakt ud fra id. Skrivning.
contracts_deleteSlet en kontrakt ud fra id. Skrivning.

Omkostningsgrupper

Tools

costGroups_listVis omkostningsgrupper/omkostningssteder — de kategorier, som omkostninger, leverandører og indgående fakturaer arkiveres under. Brug den til at finde det costGroup-id, som suppliers_create kræver, og som forslag til indgående fakturaer foreslår.
costGroups_createOpret en omkostningsgruppe/et omkostningssted (name + type påkrævet). Skrivning.
costGroups_updateOpdater en omkostningsgruppes/et omkostningssteds navn eller type ud fra id. Skrivning.

Modparter

Tools

counterparties_getHent én modpart ud fra id.
counterparties_listList modparter — alle parter, organisationen handler med. Flagene supplier og client angiver, hvilken side (eller sider) en modpart spiller, og én post kan godt være begge dele. Det er denne part, der optræder på en banktransaktion, så det er den, indgående fakturaer og transaktioner matches mod. Filtrer efter type, supplier, client, cyclic eller budgetNeutral.

CRM-noter

Tools

crmNotes_getHent én CRM-note ud fra id.
crmNotes_listList noter skrevet på leads og deals. Filtrer efter lead eller deal for at læse den løbende kommentering på én post.
crmNotes_createTilføj en note til et lead eller en deal (body + præcis én af lead/deal). Forfatteren er den tilsluttede bruger. Skrivning.
crmNotes_updateOpdater en CRM-notes indhold ud fra id. Skrivning.
crmNotes_deleteSlet en CRM-note ud fra id. Skrivning.

Årsager til tabte deals

Tools

dealLostReasons_getHent én årsag til tabt deal ud fra id.
dealLostReasons_listVis de grunde, en deal kan markeres som tabt, i rækkefølge. deals_lose kræver et lostReasonId herfra.

Deals

Tools

deals_getHent én deal ud fra id — titel, kunde, stadie, beløb, ejer, kontakt samt forventet og faktisk lukkedato.
deals_listList deals/muligheder — salgspipelinen. Filtrer efter status (open/won/lost), stadie, ejer, kunde, lead, eller efter intervaller for expectedCloseDate/closedAt. Beløb angives i mindste møntenhed med en eksplicit valuta; antag ikke organisationens standardvaluta.
deals_createOpret en deal/mulighed. Påkrævet: title, stage (fra stages_list), og et ANKER — mindst én af client eller lead. En deal uden nogen af delene afvises med 422 "A deal must reference a client or a lead.", så et prospekt, du ikke har en kundepost for, forankres til dets lead (`/leads/<id>` fra leads_list) frem for at opfinde en client; send client (`/clients/<id>` fra clients_list), når der er en. At sætte begge er tilladt. Valgfrit: amountMinor, currency, expectedCloseDate, owner, contact. At oprette direkte i en vundet stage kræver desuden client — en deal med kun et lead kan ikke vindes. Skrivning.
deals_updateOpdatér en deal ud fra id (title, stage, amountMinor, currency, expectedCloseDate, owner, contact, client, lead). At flytte stage logges automatisk. Ankerreglen fra deals_create gælder stadig for resultatet, så du kan ikke rydde den eneste client eller lead, en deal har — byt en ind først. At flytte en deal ind i en vundet stage kræver client: knyt kunden her (eller kør leads_convert), før en deal med kun et lead vindes. Skrivning.
deals_deleteSlet en deal ud fra id (soft delete). Skrivning.
deals_winMarkér en deal som vundet — flytter den til en vundet stage og stempler den lukket; valgfri contractId knytter en eksisterende kontrakt. EFTERINDLÆSNING AF EN HISTORISK VINDING: send valgfri closedAt (ISO-8601, fx "2026-05-07" eller et fuldt tidsstempel) for at registrere den dato, den RENT FAKTISK lukkede. Udelades den, stempler serveren nu, hvilket lægger en gammel deal ind i denne måneds "vundet denne måned"-tal — så sæt den, når der indtastes en deal, der lukkede før i dag. Den må ikke ligge i fremtiden (422), og den MÅ gerne være tidligere end dealens egen createdAt: en deal oprettet i dag og lukket i maj er den normale form for en korrekt efterindlæsning, ikke en fejl. Dealen skal ALLEREDE referere en client: at vinde en deal med kun et lead afvises med 422 "Attach a customer before marking this deal Won.", fordi der ikke er nogen kunde at fakturere. Gør leadet til én med leads_convert, eller sæt client med deals_update, og vind derefter. Skrivning.
deals_loseMarkér en deal som tabt — kræver lostReasonId (fra dealLostReasons_list); valgfri lostReasonNote. EFTERINDLÆSNING AF ET HISTORISK TAB: send valgfri closedAt (ISO-8601) for at registrere den dato, den RENT FAKTISK lukkede, præcis som deals_win gør. Udelades den, stempler serveren nu. Den må ikke ligge i fremtiden (422), og må gerne være tidligere end dealens createdAt. Skrivning.
deals_reopenGenåbn en vundet/tabt deal til open. Skrivning.

Deal-stadiehistorikker

Tools

dealStageHistories_getHent én registrering af deal-stadieskift ud fra id.
dealStageHistories_listVis en deals stadieovergange, nyeste først. Filtrér på deal. Hver deals_update, der flytter stadiet, logges automatisk her, så det er sådan, du rekonstruerer, hvor længe en deal har været i hvert stadie — selve deal'en bærer kun sit aktuelle.

Afdelinger

Tools

departments_listOrganisationens afdelinger, med det numeriske id, hver enkelt refereres med. LÆS DENNE FØR people_create ELLER people_update: begge accepterer en `department`-IRI, og der er ingen anden måde at finde en gyldig en på. Samlingen er upagineret og sorteret efter name, så ét kald returnerer alle organisationens afdelinger. Filtrér på `name` (delvist match) eller `code` (eksakt). Rækker har id, name og code; `manager` er en relation og indgår ikke i listerækker — læs den med people_list fra den anden side, hvis du har brug for den. Kræver ROLE_EMPLOYEES_VIEWER. Skrivebeskyttet.
departments_createTilføj en afdeling, så personer kan arkiveres under den. `name` er påkrævet (op til 128 tegn) og er UNIK på tværs af organisationen; `code` er valgfri (op til 64) og er OGSÅ unik — den korte form, en organisation allerede bruger i sine egne regneark (CEO, TECH, PROC). `manager` er en valgfri employee-IRI fra people_list. VIS LISTEN FØRST OG FORVENT KOLLISIONER: fordi både name og code er unikke, FEJLER det at poste en afdeling igen, der allerede findes, frem for at være idempotent, så en import, der antager oprettelse pr. række, går i stå, første gang den møder en afdeling, organisationen allerede har — typisk en tilbageværende fra en prøveperiode. Afstem den række med departments_update i stedet for at oprette udenom den. DER ER INGEN SLETNING: backend'en stiller ingen sletning til rådighed for en afdeling, så et forkert name eller code rettes på stedet med departments_update og fjernes aldrig. Kræver ROLE_EMPLOYEES_MANAGER. Skrivning.
departments_updateOmdøb en afdeling, giv den en code, eller sæt dens manager. Dette er værktøjet, der gør en afdelingsimport mulig frem for blot bekvem: `name` og `code` er begge unikke, så en afdeling, organisationen allerede har — den ene "HR"-række, et proof-of-concept har en tendens til at efterlade — kan ikke oprettes igen, og den rigtige liste nås ved at RETTE den række frem for at kollidere med den. Kun de felter, du sender, ændres, så hvis kun `code` sendes, forbliver name uændret. `id` er det numeriske id fra departments_list; `manager` er en employee-IRI fra people_list. DER ER INGEN SLETNING, hvilket gør dette til hele reparationshistorien: en afdeling oprettet med en tastefejl rettes her, og en, der ikke burde eksistere, kan kun omdøbes, ikke fjernes. Kræver ROLE_EMPLOYEES_MANAGER. Skrivning.

Feriedagsgrænser

Tools

holidayDaysLimits_getÉn rettighedsrække ud fra id — beløbet, typen, kontraktvarianten og den dato, den træder i kraft. holidayDaysLimits_list finder id'et. Beløb er i SEKUNDER (#3763). Skrivebeskyttet.
holidayDaysLimits_listHvor meget ferie hver person har RET TIL, pr. type — ikke hvor meget de har afholdt, hvilket er holidays_list. Filtrér på employee. En person kan have flere rækker for én type over tid, fordi en saldo bliver fyldt op eller korrigeret: rækken, der ER GÆLDENDE, er den med den seneste dateFrom, der allerede er indtruffet, og rækker dateret frem i tiden ignoreres bevidst indtil da. Beløb er i SEKUNDER (#3763) — en 8-timers feriedag er 28800. Kræver ROLE_HOLIDAYS_MANAGER. Skrivebeskyttet.
holidayDaysLimits_createGiv en person en tildeling af én ferietype, gældende fra en dato. `seconds`, IKKE dage (#3763): en 8-timers dag er 28800, så 21 dage er 604800, og en overarbejdssaldo på 2t30 er 9000 — et tal, der ikke havde noget sted at være, mens dette blev gemt i hele dage. `employee` og `holidayType` er IRI'er (people_list og holidayTypes_list leverer dem); `variant` er den kontrakttype, tildelingen hører til (uop, b2b, uz, uod). For at RETTE en eksisterende saldo, tilføj en række med en senere dateFrom frem for at redigere den gamle — rækken, der er gældende, er den seneste, hvis dateFrom er indtruffet, så historikken forbliver intakt, og en rettelse kan indtastes, før den træder i kraft. (employee, holidayType, variant, dateFrom) er unik, så en gentagen postering samme dag erstatter intet og fejler. Kræver ROLE_HOLIDAYS_MANAGER. Skrivning.
holidayDaysLimits_updateRet en række, der blev indtastet forkert — en tastefejl i amount, den forkerte variant. Beløb er i SEKUNDER (#3763). Dette er IKKE måden at registrere, at en saldo ÆNDRER SIG over tid: til det skal holidayDaysLimits_create en ny række med en senere dateFrom, hvilket bevarer, hvad den tidligere saldo var, og hvornår. Redigering på stedet omskriver historikken og gør det gamle tal uigenkaldeligt. holidayDaysLimits_list finder id'et. Kræver ROLE_HOLIDAYS_MANAGER. Skrivning.

Ferieanmodninger

Tools

holidayRequests_listOrlovs-ANMODNINGER og deres status — afventer, godkendt, afvist. Adskiller sig fra holidays_list, som er booket orlov: en anmodning, der stadig afventer en beslutning, er endnu ikke et fravær, så planlæg ud fra holidays_list, og brug denne til at se, hvad der venter på nogen. Leverer det holidayRequestId, som holidays_approve og holidays_bulkApprove tager imod. Skrivebeskyttet.
holidayRequests_cancelAnnullér en ferieanmodning — brug den til at rydde en anmodning, der aldrig bør handles på, såsom en række efterladt af en prøveperiode, en test, eller nogen der er stoppet. TO TING, DER OVERRASKER FOLK. (1) DEN SLETTER IKKE RÆKKEN: backend'en sætter status til `canceled` frem for at fjerne rækken. MEN EN ANNULLERET ANMODNING FORSVINDER FRA holidayRequests_list — verificeret i produktion: bagefter returnerer hverken den ufiltrerede liste eller status=canceled den. Så du kan ikke læse tilbage, hvad du annullerede, og der er ingen fortryd via MCP'en; vær sikker på id'et før kaldet. (2) DET ER IKKE DET SAMME SOM AT AFVISE. At afvise registrerer en beslutning — det skriver en post i godkendelsesloggen, der navngiver dig, og E-MAILER MEDARBEJDEREN, at deres ferie blev afvist — hvorimod annullering kun underretter HR, og kun når `notify-hr-managers-of-leave-activity` er slået til for organisationen. For en række, der aldrig var en reel ansøgning, er annullering den ærlige og mere stilfærdige mulighed. VIRKER KUN PÅ EN AFVENTENDE (`requested`) ANMODNING, når du ikke er dens ejer: en accepteret anmodning har allerede produceret en Holiday, som dette ikke fjerner, så annullering af én ville efterlade et booket fravær bag en anmodning, der lyder `canceled`. Kræver ROLE_HOLIDAYS_MANAGER for nogen andens anmodning; anmoderen kan altid annullere sin egen. holidayRequests_list leverer id'et. Skrivning.

Helligdage

Tools

holidays_activeHvem er væk LIGE NU — al aktuelt løbende orlov, organisationsbredt, for alle. Dette er værktøjet til 'hvem er fraværende i dag', og det, der skal krydstjekkes, før resourcingBench_get's freePercent behandles som tilgængelighed, fordi bænken ikke trækker orlov fra. I modsætning til holidays_list anvender den ingen projektafgrænsning og kræver ingen tilladelse ud over at være logget ind, så svaret dækker hele organisationen. Returnerer hvert fravær med dets type og datoer. Skrivebeskyttet.
holidays_getÉn orlovspost ud fra id, med type, datoer og varighed. Hent id'et fra holidays_list eller holidays_active. Skrivebeskyttet.
holidays_listBooket orlov over en periode — planlægningsvisningen, hvor holidays_active kun svarer om i dag. Filtrér på medarbejder, datointerval eller projekt. HVAD DU SER, AFHÆNGER AF DINE TILLADELSER, og en kort liste er ikke bevis for, at ingen er fraværende: en orlovsansvarlig eller en regnskabsseer får hele organisationen, mens en projektleder eller -seer SKAL angive et projektfilter (eller spørge om sig selv) og afvises helt uden et — den afvisning er en tilladelsesgrænse, ikke en tom kalender. Skrivebeskyttet.
holidays_createRegistrér fravær, en person rent faktisk afholder — selve det bookede fravær, ikke rettigheden (holidayDaysLimits_create) og ikke en afventende ansøgning (ferieanmodninger, som stadig skal godkendes). Det, dette skriver, er allerede aftalt fravær, så det vises i holidays_list med det samme og kræver ingen godkendelse. `employee` er en IRI fra people_list; `type` er et holidayTypes_list-id. `dateFrom`/`dateTo` inklusive, og ét kald dækker et helt interval frem for én række pr. dag. To ting bider: en type, hvis `descriptionRequired` er true (læs holidayTypes_list først — `vacations` er det som regel), AFVISER en oprettelse uden `description`; og `pick-up-day` er tid, der allerede skyldes, så det FORBRUGER IKKE den årlige tildeling på samme måde som `vacations` — at registrere en dag givet tilbage for en lørdagshelligdag som `vacations` æder tavst en dag af nogens rettighed. Tjek holidays_list for samme person og datoer før oprettelse, fordi et overlap AFVISES, ikke duplikeres: backend'en rejser `validation_holiday_dates_overlap` som en 422 på `dateTo`, når intervallet berører en dag, der allerede er dækket af et andet fravær for den person. Den ene undtagelse er snæver — to ENKELTDAGS-fravær for en del af dagen på samme dato, af FORSKELLIGE typer, begge `vacations` eller `pick-up-day`, hvis timer tilsammen passer ind i arbejdsdagen. Alt andet overlappende fejler. Der FINDES en holidays_update, så ændring af et fraværs type kræver ikke længere slet-og-derefter-opret. HVER OPRETTELSE E-MAILER MEDARBEJDEREN, på deres egen firma-adresse, for at sige, at fraværet blev tilføjet — så indlæsning af et års historik, nogen allerede har levet igennem, ankommer i deres indbakke række for række, og for personale, der ikke er blevet inviteret endnu, er det det første, de overhovedet hører til Flowtly. INDLÆSER DU ET ÅRS HISTORIK? Der findes en masseform — holidays_import afstemmer op til 500 fravær i ét kald, springer dem over, der allerede er registreret, så den er sikker at køre igen, og slår som standard mailen FRA — men DEN ER IKKE TILGÆNGELIG PÅ DENNE FORBINDELSE: den leveres kun til det interne scope, så du kan ikke kalde den her, og at lede efter den vil ikke finde den. Kør dette værktøj i en løkke, eller bed din Flowtly-operatør om at køre masseindlæsningen. Send `notify: false` for en BACKFILL af fravær, der allerede har fundet sted; lad den være, når du registrerer noget nyt, for så er mailen pointen. Den undertrykker kun beskeden — rækken, dens `createdAt` og dens lønfaktum skrives under alle omstændigheder. Kræver ROLE_HOLIDAYS_MANAGER. Skrivning.
holidays_deleteFjern et booket fravær helt — rækken slettes, i modsætning til holidayRequests_cancel, som kun vender en anmodnings status. Brug den til at rydde fravær, der aldrig burde have talt med: demo- eller testrækker efterladt af en prøveperiode, eller sådanne, der blev forældreløse, da deres medarbejder blev slettet (people_delete løsriver fravær frem for at fjerne dem, så de overlever med et tomt employee-navn). DETTE FLYTTER REELLE TAL: et booket fravær er `payrollEligible` og forbruger personens rettighed, så sletning af ét ændrer deres feriesaldo — pointen ved oprydning af testdata, og en datatabsfejl, når rækken var reel. Ingen fortryd, ingen underretning. Læs holidays_list først, og vær sikker på, at rækken ikke er reel historik: en beskrivelse på organisationens eget sprog, eller datoer der matcher et faktisk fravær, betyder som regel, at den er. Kræver ROLE_HOLIDAYS_MANAGER. Skrivning.

Ferietyper

Tools

holidayTypes_listDe ferietyper, denne organisation bruger, med det id, hver enkelt refereres med. Læs den før holidayDaysLimits_create/update, som skal bruge en holidayType-IRI og ellers vil blive gættet. Den, der ikke er en "ferie" i almindelig forstand, er `pick-up-day` — afspadsering for allerede udført overarbejde (polsk *odbior nadgodzin*), som er en TILDELT saldo frem for en årlig rettighed. Skrivebeskyttet.
holidayTypes_createTilføj en ferietype, organisationen endnu ikke tilbyder — et sabbatår, ulønnet børnepasning, en kursusdag — så fravær kan bookes mod den med holidays_create, og en tildeling kan gives med holidayDaysLimits_create. `name` (3-64 tegn) er det, folk vælger mellem ved booking; `color` og `icon` er, hvordan den ser ud i kalenderen; `reducesWorkingTime` false markerer fravær, der IKKE nedsætter månedens forventede timer; og `descriptionRequired` true kræver, at typen skal have en begrundelse, hvilket holidays_create derefter håndhæver — se det værktøj for, hvad det afviser. `status` er som standard `active`, så en type oprettet uden omtanke tilbydes alle med det samme. LÆS holidayTypes_list FØRST: typer er organisationsbrede, og DER ER INGEN SLETNING — en dublet eller et fejlstavet name kan kun skjules igen ved at sætte status til inactive med holidayTypes_update, og den beholder i mellemtiden hvert fravær booket mod den. Kræver ROLE_HOLIDAYS_MANAGER. Skrivning.
holidayTypes_updateRet en ferietype, og frem for alt TÆND EN IGEN. `status` skifter mellem `active` og `inactive`, og en inaktiv type afvises af holidays_create — så registrering af historisk fravær mod en type, organisationen siden har udfaset, starter her, og det er dette, der låser en ferie-historik-import op frem for at sende nogen ind i app-brugerfladen. DEAKTIVERING ER IKKE SLETNING, og der findes ingen sletning: fravær, der allerede er booket, beholder en inaktiv type og læses stadig med den i holidays_list, så inaktiv betyder kun "ikke tilbudt til nye bookinger". FÆLDEN, DER FØLGER AF DET: genaktivér `vacations` for at indlæse sidste års fravær, glem at sætte den tilbage til `inactive`, og du har ikke blot afsluttet en import — du har ændret, hvad organisationen tilbyder i dag, fordi hver medarbejder, der booker ferie, nu ser den type på listen igen. Sæt den tilbage i samme session, du importerede i. `descriptionRequired` rækker også ind i holidays_create, som afviser en booking uden beskrivelse, når den er slået til; at slå den til lader allerede registrerede fravær være i fred. `id` er streng-id'et fra holidayTypes_list (`vacations`, `not-paid`), og kun de felter, du sender, ændres. Kræver ROLE_HOLIDAYS_MANAGER. Skrivning.

Indgående fakturaer

Tools

incomingInvoices_getHent én indgående (leverandør-)faktura eller bilag ud fra id, med dens OCR-udlæste felter og nuværende matchstatus.
incomingInvoices_listVis indgående (leverandør-) fakturaer og bilag — regnskabets indbakke. En indgående faktura ER et dokument knyttet til en banktransaktion, så exists.transaction=false er, hvordan du finder dokumenter, der endnu ikke er matchet med en betaling. Filtrér også på status, relatedMonth, modpart, projekt, tags eller hasDetectedProblems. Hvert dokument fingeraftrykkes som externalId 'upload_sha256:<sha256 af bytes>' — hash en fil, og søg efter det externalId her, FØR du kalder incomingInvoices_create, ellers registrerer du en duplikat.
incomingInvoices_matchCandidatesList de banktransaktioner, der kan være betalingen for denne indgående faktura, rangeret af backendens egen matcher. Brug den, når et dokument ikke har nogen transaktion tilknyttet, og I skal vælge én; foretræk disse kandidater frem for selv at gætte ud fra beløb.
incomingInvoices_suggestionsLæs Flowtlys egne forslag til en indgående faktura — leverandørmatch, omkostningsgruppe, matchende banktransaktion, duplikatadvarsel. Dette er nøjagtig de samme forslag, som et menneske ser i appen. Læs dem først, og anvend derefter ét ud fra id med incomingInvoices_applySuggestion, eller tag dem alle med acceptAllSuggestions. Angiv refresh for at genberegne i stedet for at levere det cachede sæt.
incomingInvoices_suggestionsDebugForklar HVORFOR en indgående fakturas forslag blev, som de blev — matcherens scoring, til diagnosticering af et manglende eller forkert forslag. Kun til diagnosticering; brug incomingInvoices_suggestions til normalt arbejde.
incomingInvoices_createRegistrér en indgående (leverandør-) faktura eller et bilag i regnskabet — angiv bytes som base64 sammen med fileName og receivedAt. Flowtly OCR-behandler den og foreslår en leverandør og en matchende banktransaktion. Filen fingeraftrykkes som externalId 'upload_sha256:<sha256 af bytes>': for at undgå en duplikat skal du hashe bytes og tjekke incomingInvoices_list for det externalId, FØR du uploader. Skrivning.
incomingInvoices_applySuggestionAccepter ét af Flowtlys egne forslag til en indgående faktura — de samme forslag, som et menneske ser i appen (leverandørmatch, omkostningsgruppe, matchende banktransaktion, duplikatadvarsel). Læs dem først med incomingInvoices_suggestions, og anvend derefter ét ud fra dets id. Foretræk dette frem for at gætte: det er Flowtlys matcher, ikke agenten, der afgør, hvad der er sandsynligt. Skrivning.
incomingInvoices_acceptAllSuggestionsAccepter alle afventende forslag til en indgående faktura i ét kald — det, et menneske gør med appens "accepter alle"-knap. Serveren anvender, genopbygger og anvender igen, indtil intet nyt dukker op: transaktionsmatchet findes IKKE, før leverandør og beløb er anvendt, så én enkelt gennemgang ville efterlade dokumentet uden tilknytning. Returnerer en rapport (hvad der blev anvendt, hvad der blev afvist og hvorfor, samt den transaktion, den endte med at blive registreret mod). Angiv dryRun for at forhåndsvise uden at skrive. Accepterer aldrig supplier_create eller en dublet-advarsel. Skrivning.
incomingInvoices_checkEInvoicesHent nye KSeF-e-fakturaer ind i organisationen — det, som appens knap "Sprawdź e-faktury" gør. Kald denne, før du konkluderer, at en leverandørs faktura mangler: uden den kan du ikke skelne mellem "leverandøren har aldrig sendt den" og "vores synkronisering er ikke kørt endnu". Returnerer, når hentningen er sat i kø; genlæs incomingInvoices_list bagefter for at se, hvad der er ankommet. Skrivning.

Startbudgetposter

Tools

initialBudgetItems_listVis linjeposter for det oprindelige budget — de planlagte beløb, pr. tag, som contractComparison sammenholdes med. Kræver ROLE_BUDGETS_VIEWER. Skrivebeskyttet.

Startbudgetter

Tools

initialBudgets_contractComparisonPLANLAGT versus KONTRAHERET, pr. tag — det oprindelige budgets planlagte beløb sammenholdt med summen af de kontraktværdier, der faktisk er underskrevet for det pågældende projekt. Dette er spørgsmålet "har vi forpligtet os til mere, end vi har budgetteret med, og hvor", og det læses direkte ud fra de kontrakter, der allerede findes i organisationen, så import af kontrakter gør det besvarligt uden yderligere arbejde. Beløb er i grosze; et projekt med blandet valuta udløser en meddelelse frem for en tavst forkert sum. Kræver ROLE_BUDGETS_VIEWER. Skrivebeskyttet.
initialBudgets_getHent ét oprindeligt budget ud fra id, med dets poster. Kræver ROLE_BUDGETS_VIEWER. Skrivebeskyttet.
initialBudgets_listVis oprindelige budgetter — den OPRINDELIGE plan for et projekt eller en investering, i modsætning til det løbende budget, den måles op imod. Kræver ROLE_BUDGETS_VIEWER. Skrivebeskyttet.

Fakturaer

Tools

invoices_getHent én udgående (salgs-)faktura ud fra id — kunde, linjer, totaler, salgs- og udstedelsesdato, status.
invoices_listVis udgående (salgs-) fakturaer. Filtrér på klient, tags, søgning eller et saleDate-interval. Bemærk, at saleDate — ikke udstedelsesdato og ikke oprettelsesdato — er det felt, invoices_export filtrerer på, så brug det samme felt her, når du afstemmer en eksport.
invoices_exportStart en zip-eksport af UDSTEDTE fakturaer for en periode (from/to, begge YYYY-MM-DD, inklusive) filtreret på SALGSDATO — ikke udstedelses- eller oprettelsesdato. Kun UDSTEDTE fakturaer inkluderes; kladder og ikke-sendte fakturaer udelades, men kreditnotaer/korrektioner ER inkluderet. Valgfrit client begrænser til én klient (id eller IRI fra clients_list). Maks. 200 fakturaer pr. eksport — hvis perioden har flere, skal den indsnævres (fx eksportér én måned ad gangen); en periode med 0 udstedte fakturaer afvises også. Dette kald sætter kun jobbet i kø (at rendere en måned kan tage minutter) — det returnerer IKKE et downloadlink. Poll invoices_exportStatus med det returnerede exportId, indtil det rapporterer "ready". Skrivning.
invoices_exportStatusPoll status for en zip-eksport startet af invoices_export, ud fra exportId. Når status er "ready", indeholder svaret downloadUrl (et kortvarigt signeret link — udløber efter 1 time, se expiresAt), filename og byteSize; filens bytes returneres aldrig gennem dette værktøj. Hvis status er "failed", forklarer failureReason hvorfor.
invoices_importArkivér en ALLEREDE UDSTEDT udgående (salgs-)faktura i organisationen — til at bringe fakturahistorik ind ved onboarding. Det eksterne fakturanummer, du sender, bevares ordret, køberen løses op ud fra skatte-id (oprettes, hvis den mangler), og fakturaen lander som udstedt UDEN at generere en PDF, e-maile klienten eller indsende til KSeF. At importere et nummer, der allerede findes, er en no-op, der rapporterer den eksisterende faktura, så en bulkimport er sikker at gentage — men den garanti gælder kun for sekventielle kald; to reelt samtidige importer af samme nummer kan begge lande. Send expectedGrossTotal (bruttobeløbet trykt på kildedokumentet), og importen afvises, hvis det ikke stemmer med summen beregnet ud fra rækkerne. buyer.tin er påkrævet — køberen matches aldrig på navn. Brug invoices_create, ikke denne, til at rejse en reel ny faktura. Skrivning. Send dryRun:true for at FORHÅNDSVISE uden at skrive — det rapporterer would-create/would-skip og opretter hverken faktura eller klient; kør en historisk efterindlæsning tør først, og tjek tallene, før den køres for alvor.
invoices_createRejs en NY udgående (salgs-)faktura — værktøjet til at fakturere en klient for første gang. Forveksl den ikke med sine to naboer: invoices_import efterindlæser en faktura, der ALLEREDE er udstedt et andet sted (onboarding-historik), og incomingInvoices_create arkiverer en leverandørs OMKOSTNINGSDOKUMENT. Fakturaen lander USENDT: status udledes af fakturaens logrækker, og en helt ny faktura har ingen, så intet genereres, e-mailes eller indsendes til KSeF af dette kald — behandl resultatet som et kladdeudkast, der skal gennemgås før udstedelse. `name` er fakturanummeret og er dit eget valg (maks. 32 tegn) — læs invoices_list først, og følg organisationens eksisterende serie frem for at opfinde en, fordi intet her tildeler det næste nummer for dig. Påkrævet: name, type ("invoice"), tinType, issueDate, saleDate, dueDate. Send `client` (IRI fra clients_list), og for en bogføring, der afstemmes senere, `contract` (IRI fra contracts_list), så fakturaen vises under den kontrakt. Linjeposter går i `invoiceRows` — nettostykpris, mængde og en momssats pr. række; totalerne beregnes ud fra rækkerne, sendes ikke ind. EN GRÆNSEOVERSKRIDENDE RÆKKES SATS ER ET RETSGRUNDLAG, IKKE ET TAL: ud over de numeriske satser tager `vatRate` `np I`, `np II` og `zw`, den er en fri streng på 5 tegn, og intet validerer, hvilken du sender. `np I` og `np II` er FORSKELLIGE retsgrundlag og lander i forskellige felter i KSeF-fakturaen: `np II` er P_13_9, tjenesteydelser under art. 100 ust. 1 pkt 4 i den polske momslov (dem, der også indberettes i VAT-UE-listeangivelsen); `np I` er P_13_8, enhver anden levering uden for Polen. Hvilken af de to en given levering er, er en skattemæssig beslutning: tag den fra organisationens revisor eller fra organisationens bekræftede praksis for den slags kunde, og KOPIÉR IKKE SATSEN FRA EN HVILKEN SOM HELST `np`-FAKTURA, ORGANISATIONEN ALLEREDE HAR — en præcedens kan selv være forkert. Køberens skattenummer skal allerede være gemt UDEN sit landepræfiks (clients_create forklarer hvorfor) — dette dokument trykker tinCountry sammenføjet med tin, så en client gemt som "RO40424862" trykkes som RORO40424862 her. `bankAccount` (fra bankAccounts_list) vælger den konto, der trykkes på dokumentet, og `currency` er som standard organisationens. Skrivning.
invoices_updateRet en udgående (salgs-)faktura ud fra id, før eller efter udstedelse. Den daglige brug er at rette en kladde rejst af invoices_create — en forkert dato, en forkert række, et manglende kontraktlink — frem for at slette og genrejse den, hvilket ville brænde et fakturanummer. Læs invoices_get først: dette er en PATCH over et dokument, hvis totaler udledes af dets rækker, så en erstatning af `invoiceRows` erstatter hele mængden, og en faktura, der allerede er sendt, vil ikke af sig selv blive usendt, fordi den blev redigeret. Skrivning.

Lead-aktiviteter

Tools

leadActivities_getHent én lead-aktivitet (outreach-kontakt) ud fra id.
leadActivities_listVis en leads outreach-kontakter — dens aktivitetstidslinje (invitation sendt, svar, opkald, opfølgninger). Filtrér på lead for at læse én prospekts historik. Dette er den strukturerede pendant til crmNotes_list: aktiviteter er den typede, daterede kontaktlog; noter er fri kommentar.
leadActivities_createLog ÉN outreach-kontakt på en lead — en sendt invitation, en accepteret invitation, en besked, et svar, et opkald, en opfølgning (lead + type + occurredAt er påkrævet; channel, contact, body er valgfrie). DET er her, en prospekts outreach-historik hører hjemme: en crmNote er fri kommentar, en aktivitet er den strukturerede, filtrerbare kontaktlog, som prospekteringskøens tidslinje viser. Beskriv IKKE kontakter i en note. type: invite_sent | invite_accepted | message_sent | reply_received | call | meeting | follow_up | …; channel: linkedin | email | phone | …. Skrivning.
leadActivities_updateOpdatér en logget outreach-aktivitet ud fra id (type, channel, occurredAt, body). Skrivning.
leadActivities_deleteSlet en logget outreach-aktivitet ud fra id. Skrivning.
leadActivities_byListHver lead-aktivitet på en KAMPAGNE (en lead-liste), i ét kald — send listens id, IRI eller eksakte navn. leadActivities_list filtrerer på ét enkelt lead, så rapportering på kampagneniveau ellers koster ét kald pr. medlem (302 for en liste som PZFD); denne løser i stedet listens medlemmer op og læser deres aktiviteter i afgrænsede batches. Kombinér med type og occurredAt.after/.before for at få de tal, folk rent faktisk beder om: svarrate (type=reply_received), afvisningsrate (type=bounced), sendedækning (type=message_sent). Returnerer listId, listName, leadCount og de sammenflettede aktiviteter sorteret efter occurredAt. En ukendt liste er en FEJL, ikke et tomt resultat — så et fejlstavet navn kan ikke læses som "denne kampagne havde ingen aktivitet". Id'er kommer fra leadLists_list. Skrivebeskyttet.
leadActivities_bulkImportRegistrér en hel udgående bølge — hver besked, du rent faktisk sendte — i ÉT kald, i stedet for én leadActivities_create pr. besked. Send et array; hver række navngiver sit lead (leadCompanyName, matchet mod et EKSISTERENDE lead, eller en lead-IRI) plus type og occurredAt. Giv hver række et externalId — det stabile pr.-besked-id, fx Gmail-beskedens id — og importen er idempotent: en gentaget kørsel, eller en gentaget kørsel af en bølge, der kun delvist blev importeret, rapporterer dubletter frem for at oprette dem. Rækker uden et externalId dedupliceres på (lead, type, occurredAt, contact), den samme naturlige nøgle leads_bulkImport bruger, så en bølge, der først landede gennem det værktøj, dupliceres ikke her. Hver række får sit eget udfald (created | duplicate | error), så én misdannet række ikke kasserer resten af batchen. Opretter IKKE leads — brug leads_bulkImport til det. ≤ 1000 rækker/kald. Skrivning.

Lead-kontakter

Tools

leadContacts_getHent én lead-kontakt ud fra id.
leadContacts_listList de kontaktpersoner, der er knyttet til leads. Filtrer efter lead for at læse én emne-virksomheds kontakter, eller efter email for at finde ud af, hvilket lead en besked stammer fra.
leadContacts_createTilføj en kontaktperson til en lead (lead + name er påkrævet; email, phone, role, linkedinUrl, isPrimary er valgfrie). En kontaktpersons LinkedIn-URL hører hjemme i linkedinUrl, IKKE i en crmNote. Skrivning.
leadContacts_updateOpdatér en lead-kontakt ud fra id — fx angiv linkedinUrl/email/phone, når du finder dem. Skrivning.
leadContacts_deleteSlet en lead-kontakt ud fra id. Skrivning.

Lead-listemedlemskaber

Tools

leadListMemberships_getHent ét lead-til-liste-medlemskab ud fra id. Dets status og lastContactedAt er et øjebliksbillede skrevet af den kaldende part, ikke en løbende tilstand — se leadListMemberships_list.
leadListMemberships_listVis hvilke leads der sidder på hvilke udgående prospekteringslister. Filtrér på list, lead eller status. FORSIGTIG: status og lastContactedAt er et ØJEBLIKSBILLEDE skrevet af, hvem der sidst importerede eller opdaterede medlemskabet. De er ikke afledte, og intet fremskriver dem, når en aktivitet registreres — at logge en bølge på 529 opfølgninger flytter ingen af felterne — så de kan ligge vilkårligt langt bagud. For at besvare "hvornår talte vi sidst med dette prospekt", læs i stedet aktivitetsloggen: leadActivities_list for ét lead, leadActivities_byList for en hel kampagne. leadListMemberships_syncFromActivities rapporterer forskellen og kan lukke den.
leadListMemberships_createTilføj et lead til en udgående liste (list + lead påkrævet; status valgfri). Enhver lastContactedAt, du sender, er et øjebliksbillede, intet efterfølgende vil fremskrive — log kontakten som en lead-aktivitet også, ellers forbliver den ikke-forespørgelig. Skrivning.
leadListMemberships_updateOpdatér et leads medlemskab i en liste — fx sæt outreach-status (contacted/replied/bounced). status og lastContactedAt vedligeholdes af den kaldende part: det, du skriver, står ved magt, indtil nogen skriver igen, og registrering af lead-aktiviteter opdaterer dem IKKE. Skrivning.
leadListMemberships_deleteFjern et lead fra en outbound-liste. Skrivning.

Lead-lister

Tools

leadLists_getHent én outbound-prospekteringsliste ud fra id.
leadLists_listVis udgående prospekteringslister. Brug den til at finde det list-id, som leadListMemberships_create tager imod.
leadLists_createOpret en outbound-prospekteringsliste (name påkrævet). Skrivning.
leadLists_updateOpdater en outbound-liste ud fra id. Skrivning.
leadLists_deleteSlet en outbound-liste ud fra id. Skrivning.

Årsager til tabte leads

Tools

leadLostReasons_getHent én årsag til tabt lead ud fra id.
leadLostReasons_listList årsagerne til, at et lead kan markeres som tabt, i rækkefølge.

Leads

Tools

leads_dedupeCheckKontrollér, om en prospekt allerede findes i CRM'et, med de samme filtre som leads_list (companyName, source, owner, …). Kald denne FØR leads_create: en duplikeret lead splitter outreach-historikken over to poster, og intet efterfølgende vil samle dem for dig.
leads_getHent ét lead ud fra id — virksomhed, hjemmeside, kilde, status, ejer og den kunde, det er konverteret til, hvis nogen.
leads_listVis leads — prospektmål, før kvalificering. Filtrér på status, source, owner, client, companyName eller createdAt/closedAt-intervaller. En kvalificeret lead bliver til en klient plus en åben deal via leads_convert; indtil da findes den kun her, ikke i clients_list.
leads_createOpret et lead (udgående/indgående prospektmål; companyName, source, owner, linket client valgfrit). Et nyt lead har altid status=open — status kan ikke sættes her og flyttes kun via leads_convert, leads_lose og leads_reopen. Skrivning.
leads_updateOpdatér et lead ud fra id (company, website, source, owner, linket client, stage, doNotContact). IKKE status eller lostReason: de afvises af entiteten og ignoreres tavst af dette endpoint, så lukning af et lead kræver leads_lose (med en lostReasonId), og at fortryde det kræver leads_reopen. At flytte `stage` bevæger sig gennem tragten; det lukker ikke leadet. Skrivning.
leads_deleteSlet et lead ud fra id (soft delete). Skrivning.
leads_convertKonverter et kvalificeret lead til en Client + én kontakt pr. lead-kontakt + en åben Deal. Kræver en eksisterende client (leadets client eller et clientId i body). Skrivning.
leads_loseLuk et lead som TABT — sætter status=lost og stempler closedAt. KRÆVER lostReasonId, `id`'et på en leadLostReasons-post (kør leadLostReasons_list først; det er en picklist, så fritekst afvises med 422). Dette er den ENESTE måde at registrere et lead som tabt på: leads_update ignorerer status, og doNotContact betyder "kontakt aldrig igen", hvilket er et andet og langt stærkere udsagn end "vi vandt ikke denne". Det flytter IKKE leadets stage — LeadStage har intet terminalflag, så leadet beholder sin position i tragten, og leads_reopen kan gendanne den præcist. Skrivning.
leads_reopenFortryd leads_lose — sætter status tilbage til open og rydder closedAt og tabsårsagen. Stage røres ikke, så leadet genoptages præcis, hvor det var. Brug denne, når et lead blev lukket mod den forkerte post, eller prospektet kom tilbage. Skrivning.
leads_bulkImportImportér mange leads i ÉT kald, hver med sine kontakter, listemedlemskab og outreach-aktiviteter indlejret — serveren opretter leaden og fletter derefter dens id ind i underelementerne, så du aldrig behøver at jonglere med mellemliggende IRI'er. Idempotent ud fra naturlige nøgler (companyName / email / (list,lead) / (type,occurredAt,contact)): sikker at køre igen og at opdele (≤100 leads/kald). Dette er den masseimportvej, en kampagneimport bør bruge i stedet for N kald til leads_create. Skrivning.

Lead-stadier

Tools

leadStages_getHent ét lead-stadie ud fra id.
leadStages_listVis de stadier, en lead bevæger sig igennem, i rækkefølge. Leads har deres eget stadiesæt — deals bruger stages_list, som er noget andet.

Lokationer

Tools

locations_getHent én lokation ud fra id — dens name og åbningstider. Skrivebeskyttet.
locations_listVis organisationens lokationer — de fysiske steder, aktiver befinder sig, vist i brugerfladen som Lokalizacja. Kræver ROLE_LOCATIONS_MANAGER, som usædvanligt nok spærrer for LÆSNING såvel som skrivning. Skrivebeskyttet.
locations_createOpret en lokation (name påkrævet; valgfri officeOpenHour/officeCloseHour som sekunder efter midnat). Brug den rigtige adresse frem for et projekt- eller investeringsnavn — det er det, nogen der står foran aktivet har brug for, og projektnavnet føres allerede andetsteds. Kræver ROLE_LOCATIONS_MANAGER. Skrivning.
locations_updateOmdøb en lokation, eller skift dens åbningstider. Kræver ROLE_LOCATIONS_MANAGER. Skrivning.

Organisationsadresser

Tools

organizationAddresses_getHent én abonnementsadresse ud fra id — name, street, city, postCode, country og skattefelterne. `street` bærer husnummeret, når det er indtastet manuelt, og gør det ikke, når det stammer fra NIP/GUS-opslaget. Skrivebeskyttet.
organizationAddresses_listVis organisationens abonnementsadresser — adressen knyttet til Flowtly-abonnementet, og den kilde mail-fodnoten {{organizationAddress}} genereres ud fra. Normalt præcis én række. Dette er IKKE fakturaens sælgeradresse, som ligger i organization-billing-*-konfigurationsnøglerne (configs_get), og som fakturaer og KSeF læser; de to vedligeholdes hver for sig og er rutinemæssigt uenige. Læs begge, før det konkluderes, hvilken en kunde rent faktisk har redigeret. Skrivebeskyttet.
organizationAddresses_updateOpdatér organisationens ABONNEMENTSADRESSE (id påkrævet; send kun de felter, du ændrer). DETTE ER DEN POST, MAIL-FODNOTEN GENERERES UD FRA: fodnotens {{organizationAddress}} sammensættes som "street, postCode city" herfra, IKKE fra organization-billing-*-konfigurationsnøglerne, som fakturaer og KSeF bruger som sælgeradresse. De to gemmesteder driver fra hinanden, og at fodnoten læser denne er en kendt fejl — så når en signatur viser en adresse, kunden sværger på at have rettet, har de rettet faktureringsnøglerne, og dette er posten, der stadig holder den gamle værdi. `street` er en enkelt fritekstkolonne, der også skal bære husnummeret: NIP/GUS-opslaget udfylder kun gadenavnet og kasserer tavst bygnings- og lejlighedsnummeret, hvilket er, hvorfor adresser her lyder "ul. Example" uden nummer. Skriv det fulde "ul. Example 8/12" for at rette det. LÆS FØRST med organizationAddresses_list, og sammenhold med configs_get på organization-billing-street, før der skrives, så du kopierer kundens egen vedligeholdte værdi frem for at opfinde en. Kræver ROLE_BILLINGS_MANAGER. Skrivning.

Organisationens mailsidefod

Tools

organizationMailFooter_getLæs organisationens sidefodstekst til udgående mail (den blok, der tilføjes mails, Flowtly sender på organisationens vegne).
organizationMailFooter_updateOpdater organisationens sidefodstekst til udgående mail. Skrivning.

Organisationer

Tools

organizations_getHent en organisation ud fra id. ADVARSEL — dette fortæller IKKE, hvilken organisation du er forbundet til. En OAuth-forbindelse er bundet til præcis én organisation (token-bundet), men dette endpoint returnerer enhver organisation, som den tilsluttede BRUGER er medlem af, så et vellykket kald her kan fejlagtigt læses som en bekræftelse på, at du arbejder i den organisation. For at bekræfte, hvilken tenant du faktisk opererer på, skal du i stedet læse tenant-afgrænsede data — people_list eller clients_list — og aldrig starte en masseskrivning alene på baggrund af dette kald.

Personer

Tools

people_getHent én person-/medarbejderpost ud fra id — navne, emails, telefon, leder, og om personen er aktiv.
people_listList personer/medarbejdere. Filtrer efter isActive, reportsTo (en leders id), projectMembers.project eller search; paginer med cursor. Personer og medarbejdere deler samme id, så det er sådan, I finder det employee-id, som arbejdstid, ansvarsområder, projektmedlemskab og rettighedsværktøjer alle forventer.
people_createOpret en person-/medarbejderpost (firstname + lastname påkrævet; valgfrit companyEmail, contactEmail, contactPhone). Skrivning.
people_updateOpdater en person-/medarbejderpost ud fra id (name, companyEmail, contactEmail, contactPhone osv.). Skrivning.
people_deleteSlet en medarbejder-/personpost ud fra id (f.eks. for at fjerne en placeholder-/dummy-medarbejder). Kræver ROLE_EMPLOYEES_MANAGER; backenden kører en sletteproces, der også løsner tilknyttede poster. Vidtrækkende og irreversibel. Skrivning.
people_inviteGiv en eksisterende person et LOGIN: opretter en afventende organisationsinvitation og e-mailer den til dem, på organisationens konfigurerede brugerfladesprog. Dette er trinnet, people_create og people_setPermissionGroups IKKE udfører — en person med permission groups kan stadig ikke logge ind, før de er inviteret og har accepteret. Kræver personens e-mail; fejler, hvis de allerede har et login. Onboarding-rækkefølge: people_create (post) -> people_invite (login) -> people_setPermissionGroups (rettigheder). Skrivning.
people_setPermissionGroupsSæt (erstat) en persons HELE sæt af permission groups ud fra numeriske gruppe-id'er (se permissionGroups_list — fx giver gruppen "Business Owner" ROLE_ADMIN): send alle de grupper, de skal ende med, og [] fjerner dem alle. Giver adgang; opretter IKKE et login eller e-mailer personen — det er people_invite. FÆLDEN: at give nogen deres FØRSTE gruppe flytter dem over på den beregnede model, hvor roller kommer fra grupper og pr.-person-overrides, og en rolle givet til dem manuelt uden for den model forsvinder i selv samme kald — en ROLE_ADMIN givet til én person er præcis den slags, dette fjerner. Det gælder også den anden vej: fjernes deres sidste gruppe, flyttes de tilbage væk fra modellen, og de ældre roller dukker op igen. Listerne overridesAdded/overridesRemoved siger intet om noget af dette; de beskriver overrides og forbliver tomme, mens den reelle adgang ændrer sig. Så svaret rapporterer forskellen mellem de roller, personen havde før dette kald, og efter det, som rolesLost og rolesGained — det er parret, der skal læses, når kaldet returnerer. rolesLost null (ikke []) betyder, at det øjebliksbillede, der blev taget før skrivningen, ikke kunne læses, og differencen er UKENDT, med årsagen i roleDeltaUnavailable: gruppeændringen skete stadig, så en null er ikke en ren helbredsattest — tjek igen med people_getPermissions. For at give en rolle tilbage, der burde have overlevet, skal du tildele den med people_setRoleOverrides. Kræver ROLE_ROLES_MANAGER. Skrivning.
people_setRoleOverridesSæt (erstat) de roller, ÉN person får oven i — eller frataget fra — sine permission groups. Grib fat i en gruppe først (people_setPermissionGroups): grupper er den tilsigtede abstraktion og skalerer til mere end én person, så brug kun en override, hvor en enkelt person reelt afviger fra enhver gruppe. ERSTATTER begge lister som helhed, så læs people_getPermissions først, og send hver override tilbage, de skal beholde; udelades en liste, ryddes den. Roller er ROLE_-konstanter — permissionGroups_list viser de roller, denne organisation allerede bruger. En rolle i både added og removed afvises frem for at blive gættet på. Returnerer det samme opløste øjebliksbillede som people_getPermissions, så resultatet kan bekræftes uden endnu et kald. Opretter IKKE et login — se people_invite. Kræver ROLE_ROLES_MANAGER. Skrivning.
people_getPermissionsHvad en person rent faktisk kan gøre, opløst: deres permission groups (hver med de roller, den giver), deres pr.-person-overrides, og de effectiveRoles, de to kombinerer til. DEN måde at tjekke, om en adgangsændring landede — people_list viser et roles-felt, men dette er det, der forklarer HVORFOR det har de roller, og hvilken håndtag der skal trækkes i for at ændre det. Brug den før hvert people_setRoleOverrides-kald, fordi det værktøj erstatter override-listerne som helhed, og her læser du de nuværende. staleOverrides er fjernede overrides, der ikke længere matcher nogen gruppetildelt rolle, så de gør i øjeblikket intet. people_list leverer id'et. Kræver ROLE_ROLES_MANAGER for at se andre end dig selv. Skrivebeskyttet.

Rettighedsgrupper

Tools

permissionGroups_getHent én rettighedsgruppe ud fra id, inklusive de ROLE_*-strenge, den giver.
permissionGroups_listVis organisationens tilladelsesgrupper og de roller, hver af dem giver — fx giver gruppen "Business Owner" ROLE_ADMIN. Læs dette før people_setPermissionGroups: rollerne i svaret er facitlisten for, hvad en gruppe reelt tillader, så du aldrig behøver at gætte ud fra navnet.
permissionGroups_createOpret en rettighedsgruppe (name påkrævet; roles = liste af ROLE_*-strenge, den giver). Skrivning.
permissionGroups_updateOpdater en rettighedsgruppes navn, beskrivelse eller tildelte roller ud fra id. Skrivning.

Pipelines

Tools

pipelines_getHent én salgspipeline ud fra id.
pipelines_listVis salgspipelines. En pipeline ejer et ordnet sæt af stadier — læs dem med stages_list filtreret på pipeline.

Stillinger

Tools

positions_listVis positioner — de navngivne roller (fx "Backend Engineer"), som en projektallokering udfylder. Ingen filtre; Position har paginering deaktiveret, så dette returnerer altid organisationens fulde rollekatalog i ét kald. Hvert element er {id, name, roles}. Brug den til at finde positionsnavnet bag en positionId i en allocations_list-række, og til at finde det position-id, en ressourceimport skal matche mod.

Projektmedlemmer

Tools

projectMembers_getHent ét projektmedlemskab ud fra id — dets employee, project og position. Id'er kommer fra projectMembers_list eller projectMembers-arrayet på projects_get.
projectMembers_listVis projektmedlemskaber — HVEM KAN SE HVILKET PROJEKT. Filtrér på project (`/projects/{id}`) for at læse ét projekts besætning, eller på employee for at læse alle de projekter, én person kan tilgå; hver række har sit eget id, employee, project og position (employee|tech-lead|account-manager|viewer). Brug denne først, når nogen rapporterer, at et projekt mangler fra deres projektliste, eller at de ikke kan bogføre tid på det: en tom besætning, eller en besætning uden dem i, ER forklaringen — synlighed er medlemskab. Det er også id-kilden til projectMembers_update og projectMembers_delete. Bemærk at samme person kan optræde flere gange på ét projekt, én gang pr. position.
projectMembers_createSæt en person PÅ et projekt (employee + project-IRI'er påkrævet, fx "/people/204" og "/projects/243"; valgfri position = employee|tech-lead|account-manager|viewer, standard employee). DETTE ER ADGANGSSTYRINGEN, ikke en etiket: en person, der ikke er medlem, kan slet ikke se projektet — det mangler fra deres projektliste, og de kan ikke bogføre tid på det — så dette er værktøjet, der genskaber adgang for nogen, der er låst ude af et projekt. POSITION ER IKKE KOSMETISK: en bruger med en projektafgrænset rolle ser kun de projekter, hvor deres medlemskabsposition matcher den — ROLE_PROJECTS_LEAD matcher tech-lead, ROLE_PROJECTS_VIEWER matcher viewer — så at give en projektleder en `employee`-række efterlader dem lige så blinde, som slet ingen række gør. Medlemskab KASKADERER IKKE: at sætte nogen på en overordnet mappe giver dem intet på de underliggende projekter, så et mappetræ kræver ét kald pr. projekt. Den unikke nøgle er (employee, project, position), hvilket betyder, at positioner lægges oven på hinanden frem for at erstatte — en person kan have employee OG tech-lead på samme projekt som to separate rækker, og at tilføje tech-lead til nogen, der allerede er employee der, fjerner eller opgraderer ikke employee-rækken (brug projectMembers_update til at ændre en position på stedet). Læs de aktuelle rækker med projectMembers_list?project=/projects/{id} først, eller projects_get, hvis projectMembers-array bærer hver rækkes id. INDLÆSER DU EN HEL BEMANDINGSLISTE? Der findes en masseform — projectMembers_import afstemmer op til 500 medlemskaber i ét kald, springer dem over, der allerede er registreret, så den er sikker at køre igen, og slår som standard notifikationen FRA — men DEN ER IKKE TILGÆNGELIG PÅ DENNE FORBINDELSE: den leveres kun til det interne scope, så du kan ikke kalde den her, og at lede efter den vil ikke finde den. Kør dette værktøj i en løkke, eller bed din Flowtly-operatør om at køre masseindlæsningen. IKKE TAVS: at tilføje en person, der endnu ikke er på projektet, sender en project-assigned-notifikation til dem, så en backfill af 17 projekter sender 17 notifikationer. Kræver ROLE_PROJECTS_MANAGER. Skrivning.
projectMembers_updateRet et eksisterende medlemskabs position ud fra id (employee|tech-lead|account-manager|viewer) — hent id'et fra projectMembers_list eller projectMembers-arrayet på projects_get. Brug denne til at forfremme eller nedgradere PÅ STEDET; brug projectMembers_create til at tilføje en anden, ekstra position ved siden af den allerede indehavte. At ændre en position kan INDDRAGE synet af projektet for nogen, hvis rolle er projektafgrænset (en ROLE_PROJECTS_LEAD nedgraderet fra tech-lead til employee holder op med at se det). Kan ikke flytte et medlemskab til en anden person eller et andet projekt — slet og genopret for det. Kræver ROLE_PROJECTS_MANAGER. Skrivning.
projectMembers_deleteTag en person AF et projekt ud fra medlemskabs-id — find det med projectMembers_list eller i projectMembers-arrayet på projects_get. Dette INDDRAGER ADGANG: når den sidste medlemskabsrække for den person på det projekt er væk, forsvinder projektet fra deres visning, og de kan ikke længere bogføre tid på det, hvilket er præcis, hvordan et projekt tavst forsvinder for nogen. Timer, der allerede er registreret, SLETTES IKKE og forbliver på projektet; personen kan blot ikke længere se eller tilføje til dem. Sletning af én position lader enhver anden position, samme person har på samme projekt, være intakt. Kræver ROLE_PROJECTS_MANAGER. Uigenkaldelig (genoprettelse laver en ny række og genunderretter), stor betydning. Skrivning.

Projekter

Tools

projects_costAllocationsHvordan omkostninger blev fordelt PÅ dette projekt — hvilke transaktioner og fakturalinjer der blev henført til det, og med hvilken andel. Brug den til at forklare et rentabilitetstal frem for blot at citere det: her spores et uventet resultat tilbage til det dokument, der forårsagede det. Kræver ROLE_TRANSACTIONS_MANAGER. Skrivebeskyttet.
projects_folderCountsHvor mange projekter der ligger i hver projektMAPPE, som folderId + total + active. folderId er et tagDefinition-id — slå navne op med tagDefinitions_list, og find ud af hvilke grupper der er mappegrupper med tagGroups_list (allowedRelations indeholder "project"). Et tomt folderId er spanden med ukategoriserede. Tæller kun rodprojekter, da mapper grupperer rødder og faser følger deres overordnede projekt. Skrivebeskyttet.
projects_getHent ét projekt ud fra id — navn, type, kunde, datoer, beskrivelse og pris.
projects_listList projekter. Filtrer efter type (fixed-price | time-and-material | non-billable | internal), client.name, employee, name eller intervaller for dateFrom/dateTo. Brug den til at finde det project-id, som opgaver, tidsregistrering, budgetter og kontrakter alle tager imod.
projects_profitabilityRESULTATET PR. PROJEKT — hvad et projekt har indtjent set i forhold til, hvad det har kostet. Dette er det tal, en service- eller udviklingsvirksomhed som regel prøver at se, og det alle andre projektværktøjer bidrager til. Send project-id'et fra projects_list. Kræver ROLE_ACCOUNT_MANAGER. Skrivebeskyttet.
projects_createOpret et projekt (name + type påkrævet; type = fixed-price|time-and-material|non-billable|internal; valgfrit dateFrom/dateTo, client, publicDescription, notes, priceNet). Skrivning.
projects_updateOpdater et projekt ud fra id (name, type, datoer, beskrivelse osv.). Skrivning.
projects_archiveArkiverer et projekt via id — måden at tage et projekt ud af drift, som ikke kan slettes, fordi der hænger registreret tid, fakturaer eller budgetter på det. Kan fortrydes med projects_unarchive. Bedre end at tilbagedatere dateTo, som blot får projektet til at se afsluttet ud. Skrivning.
projects_unarchiveGendanner et arkiveret projekt via id og fortryder projects_archive. Skrivning.

Projektskabeloner

Tools

projectTemplates_getHent én projektskabelon ud fra id, inklusive dens fulde strukturdokument. projectTemplates_list finder id'et. Læs denne før projectTemplates_update — strukturen skrives SOM HELHED, så en opdatering skal sende hele dokumentet, ikke et fragment. Skrivebeskyttet.
projectTemplates_listVis organisationens projektskabeloner — genanvendelige blueprints af et projekt, dets faser, dets opgavelister og dets opgaver. Brug denne FØR projects_create, når den samme slags projekt oprettes igen og igen (en engagementstype, en revision, en onboarding): instantiering af en skabelon bygger hele træet i ét kald, hvor projects_create laver et tomt projekt, der derefter skal udfyldes manuelt. Rækken markeret isDefault er organisationens indbyggede skabelon, som anvendes på et projekt oprettet uden valgt skabelon. Skrivebeskyttet.
projectTemplates_createOpret en genanvendelig projektblueprint ud fra et strukturdokument (version, project, faser og deres lister/opgaver). Forskydninger indeni er RELATIVE — startOffsetDays og durationDays tælles i dage fra den startDate, der gives ved instantiering, så én skabelon betjener enhver fremtidig start. project.name i strukturen er en pladsholder; overskriv den pr. kunde ved instantiering. Strukturen valideres på serversiden mod skemaet for sin angivne version, og en overtrædelse navngiver den fejlende JSON-pointer. Skrivning.
projectTemplates_updateOpdatér en projektskabelon ud fra id. Struktur-kolonnen gemmes og erstattes SOM HELHED, sammenflettes aldrig — send hele dokumentet, ellers er de dele, du udelader, væk. Læs den aktuelle med projectTemplates_get først. At ændre en skabelon rører IKKE ved projekter, der allerede er instantieret ud fra den; der er ingen tilbagepropagering. Skrivning.
projectTemplates_deleteSlet en projektskabelon ud fra id. Blød sletning, og den rører IKKE ved projekter, der allerede er oprettet ud fra skabelonen — de er almindelige projekter og lever videre. Skrivning.
projectTemplates_instantiateByg et rigtigt projekt ud fra en skabelon — projektet, dets faser, dets opgavelister og hver opgave, i ÉT atomisk kald. startDate er påkrævet og er ankeret, hver startOffsetDays i skabelonen løses op imod. Send name for at overskrive skabelonens pladsholder-projektnavn, og client for at knytte det nye projekt til en kunde: at instantiere to gange mod SAMME client er, hvordan én kunde ender med at have flere engagementer, hver sit eget projekt. Returnerer det oprettede projekt. Skrivning.

Kandidater til ressourceanmodninger

Tools

resourceRequestCandidates_getÉn rekrutteringskandidat ud fra id. Id'et kommer fra resourceRequestCandidates_list. Kræver ROLE_HR_MANAGER. Skrivebeskyttet.
resourceRequestCandidates_listDe kandidater, der er indstillet til ansættelsesanmodninger — personer i en rekrutteringspipeline, ikke medarbejdere, der er tilgængelige til allokering. Filtrér på request-id'et fra resourceRequests_list. Kræver ROLE_HR_MANAGER. Skrivebeskyttet.

Ressourceanmodninger

Tools

resourceRequests_getÉn ansættelsesanmodning ud fra id, med dens position og status. Hent id'et fra resourceRequests_list. HR/rekruttering, ikke ressourceallokering. Kræver ROLE_HR_MANAGER. Skrivebeskyttet.
resourceRequests_listÅbne ansættelsesanmodninger — en anmodning om at rekruttere til en position, i HR-domænet. På trods af navnet er dette IKKE efterspørgsel efter ressourceallokering: det er rekruttering. Returnerer samlingen; resourceRequests_get læser én, og resourceRequestCandidates_list giver de personer, der er indstillet til den. Kræver ROLE_HR_MANAGER. Skrivebeskyttet.

Ressourcestyringsanmodninger

Tools

resourcingRequests_listÅbne ressourceanmodninger — nogen der beder om, at en person allokeres til et projekt, hvilket er efterspørgselssiden af ressourcestyring. Dette er det flow, som Ressourcestyrings-UI'ets visning af anmodninger viser. Forveksl den IKKE med resourceRequests_list: den handler om HR-REKRUTTERING (ansættelse til en position). Kombinér den med resourcingRequestsHistory_list for, hvad der allerede er besluttet, og resourcingBench_get for, hvem der kunne opfylde en anmodning. Kræver ressourcemodulet og ROLE_RESOURCING_MANAGER. Skrivebeskyttet.

Historik for ressourcestyringsanmodninger

Tools

resourcingRequestsHistory_listHvad der allerede er sket med ressourceanmodninger — beslutningssporet (bekræftet, afvist, ændret) bag de åbne anmodninger i resourcingRequests_list. Brug den til at besvare 'blev der allerede spurgt om dette og sagt nej?', før du foreslår den samme allokering igen. Kræver ressourcemodulet og ROLE_RESOURCING_MANAGER. Skrivebeskyttet.

Ansvarsområder

Tools

responsibilities_getHent ét ansvar ud fra id.
responsibilities_listList ansvarsområder inden for en RACI-gruppe. Filtrer efter responsibilityGroup. Ansvarsområder kan indlejres via parent; personer tildeles dem gennem responsibilityEmployees, ikke direkte.
responsibilities_createOpret et ansvarsområde inden for en gruppe (responsibilityGroup = gruppe-id eller IRI, + name, påkrævet; valgfrit description; valgfrit parent = en anden responsibility-IRI til indlejring). Tildel personer til det via responsibilityEmployees_create. Skrivning.
responsibilities_updateOpdater et ansvar ud fra id (name, description, parent, responsibilityGroup = group-id eller IRI). Skrivning.

Ansvarstildelinger

Tools

responsibilityEmployees_getHent én ansvarstildeling ud fra id.
responsibilityEmployees_listList hvem, der er tildelt hvilket ansvar, og med hvor stor en procentdel. Filtrer efter employee for at læse én persons samlede RACI-belastning på tværs af alle grupper.
responsibilityEmployees_createTildel en medarbejder til et ansvar (responsibility = responsibility-id eller IRI, employee = employee-id eller IRI, percentage 0-100, alle påkrævet; valgfrit targets og description). Skrivning.
responsibilityEmployees_updateOpdater en ansvarstildeling ud fra id (percentage, targets, description). Skrivning.
responsibilityEmployees_deleteFjern en medarbejders tildeling fra et ansvar ud fra id. Skrivning.

Ansvarsgrupper

Tools

responsibilityGroups_getHent én ansvarsgruppe ud fra id.
responsibilityGroups_listList ansvarsgrupper/RACI-områder — de øverste "Odpowiedzialności"-elementer, hver med en ansvarlig person. De enkelte ansvarsområder hænger under dem.
responsibilityGroups_createOpret en ansvarsgruppe/RACI-område (name er påkrævet; valgfrit description og responsibleEmployee = den ansvarlige person, angivet som et rent employee-id som 6 (fra people_list) eller IRI'en /people/6). Dette er det øverste 'Odpowiedzialności'-element. Tilføj individuelle ansvarsområder under den via responsibilities_create. Skrivning.
responsibilityGroups_updateOpdater en ansvarsgruppe ud fra id (name, description, responsibleEmployee = employee-id eller IRI). Skrivning.

Vagtplanmedarbejdere

Tools

scheduleEmployees_getÉn tildeling af skema til medarbejder ud fra id. Id'et kommer fra scheduleEmployees_list. Kræver ROLE_SCHEDULES_MANAGER. Skrivebeskyttet.
scheduleEmployees_listHvilke medarbejdere er tildelt hvilke arbejdstidsskemaer. Brug den til at gå fra et skema (schedules_list) til dets personer, eller til at finde det skema, en given medarbejder følger. Kræver ROLE_SCHEDULES_MANAGER. Skrivebeskyttet.

Vagtplan

Tools

schedulePlan_listDe skemaer, der gælder på ÉN given dato — angiv datoen i stien. Brug den til at besvare 'hvem arbejder i dag/på denne dato' uden selv at skulle læse hvert skema og udlede dets intervaller. I modsætning til de andre skema-læsninger kræver denne kun ROLE_USER, så det er den, en almindelig medarbejder har adgang til. Skrivebeskyttet.

Vagtplanperioder

Tools

scheduleRanges_getÉt tidsinterval for et skema ud fra id. Id'et kommer fra scheduleRanges_list. Kræver ROLE_SCHEDULES_MANAGER. Skrivebeskyttet.
scheduleRanges_listDe tidsintervaller, der udgør arbejdstidsskemaer — de faktiske timer, et skema dækker. Læs først forælderen med schedules_get; denne udvider dens intervaller. Kræver ROLE_SCHEDULES_MANAGER. Skrivebeskyttet.

Skemaer

Tools

schedules_getÉt arbejdstidsskema ud fra id, med dets intervaller og tildelte medarbejdere. Id'et kommer fra schedules_list; scheduleRanges_list og scheduleEmployees_list læser dets dele. Kræver ROLE_SCHEDULES_MANAGER. Skrivebeskyttet.
schedules_listArbejdstidsskemaer — de vagt-/arbejdsmønstre, en organisation definerer, IKKE projektallokering. Brug resourcingSchedule_get for at se, hvem der er booket på hvad; brug denne til selve arbejdsmønstrene. schedules_get læser ét ud fra id. Kræver ROLE_SCHEDULES_MANAGER. Skrivebeskyttet.

Stadier

Tools

stages_getHent ét deal-stadie ud fra id.
stages_listVis deal-stadier, i rækkefølge. Filtrér på pipeline. deals_create kræver et stage-id herfra, og det er flytning af en deal mellem stadier, dealStageHistories registrerer.

Leverandører

Tools

suppliers_listList leverandører — serveres fra /contractors, så "supplier" og "contractor" er den samme post. Filtrer efter cyclic for tilbagevendende leverandører. Brug den til at finde den leverandør, en omkostning, en kontrakt eller en indgående faktura er registreret mod.
suppliers_createOpret en ny leverandørpost (name, tinType, costGroup påkrævet). Skrivning.
suppliers_updateOpdater en leverandørs oplysninger (name, skatte-id, betalingsbetingelser osv.) ud fra id. Skrivning.

Tag-definitioner

Tools

tagDefinitions_listVis tagdefinitioner — de tags, der kan knyttes til poster, hver inden for en taggruppe. tags_create tager et tagDefinition-id herfra plus posten, det skal knyttes til.
tagDefinitions_createOpretter en tagdefinition (name, level, tagGroup påkrævet) inden for en taggruppe. Når gruppens allowedRelations indeholder "project", ER hver definition her en projektmappe — det er dette værktøj, der opretter en. Skrivning.

Tag-grupper

Tools

tagGroups_listList tag-grupper — de beholdere, der organiserer tag-definitioner.
tagGroups_createOpretter en taggruppe (navn påkrævet) til at organisere beslægtede tagdefinitioner. Sådan opretter du også en PROJEKTMAPPE-beholder: angiv allowedRelations: ["project"], så bliver gruppens definitioner til mapper i projektlisten. En gruppe med tom allowedRelations er universel og behandles IKKE som en mappe. Skrivning.

Opgavekommentarer

Tools

taskComments_listList kommentarer på projektopgaver, ældste først. Filtrer efter task for at læse diskussionen på én opgave.
taskComments_createTilføj en kommentar til en projektopgave (task-id + content). Skrivning.

Opgavelister

Tools

taskLists_listVis opgavelister — de tavlekolonner/sektioner, opgaver arkiveres i. Filtrér på projekt. tasks_create tager et list-id herfra.

Opgaver

Tools

tasks_getHent én projektopgave ud fra id — titel, projekt, status, liste, ansvarlige, datoer og gentagelse.
tasks_listVis projektopgaver. Filtrér på projekt, liste, status, ansvarlige, isTemplate eller startAt/dueAt-intervaller. Tilbagevendende opgaver eksponerer recurrenceParent og recurrenceRule, så en genereret forekomst kan spores tilbage til den regel, der producerede den. For at afgøre, om en opgave er FÆRDIG, skal du sammenligne dens status med taskStatuses_list (isClosed) i stedet for at matche på statusnavnet.
tasks_createOpret en projektopgave (title + project påkrævet; valgfrit status, list, assignees, dueAt, priority). Skrivning.
tasks_updateOpdatér en projektopgave ud fra id — skift status (inkl. markér udført), assignees, dueAt, title osv., eller FLYT opgaven til et andet projekt ved at sende `project` (ny forælder; opgavelisten ryddes, medmindre du også angiver en `list` i målprojektet, fordi en liste hører til ét projekt). Skrivning.

Opgavestatusser

Tools

taskStatuses_listList projektopgavernes statusser, i tavlerækkefølge. isClosed markerer de færdiggjorte tilstande, og isDefault den status, en ny opgave får. Læs dette, før I fortolker en opgaves status — navnene kan konfigureres pr. organisation, så "Done" ikke er en pålidelig streng at matche på.

Skattegrupper

Tools

taxGroups_listVis afgiftsgrupper. Brug den til at finde det taxGroup-id, som taxRules_list filtrerer på, og som fakturarækker bærer.
taxGroups_createOpret en skattegruppe (name + type påkrævet). Skrivning.
taxGroups_updateOpdater en skattegruppes navn eller type ud fra id. Skrivning.

Skatteregler

Tools

taxRules_listList skatteregler — satserne og de perioder, de gælder for. Filtrer efter taxGroup.
taxRules_createOpret en skatteregel. Skrivning.
taxRules_updateOpdater en skatteregel ud fra id. Skrivning.

Transaktioner

Tools

transactions_listList banktransaktioner — det bankfeed, indgående fakturaer matches mod. Filtrer efter bankAccount, counterpartyRole, cost, ignored, hasDetectedProblems, et interval for orderDate/execDate eller amount.between. Bemærk, at orderDate og execDate er forskellige: en betaling kan blive bestilt i én måned og udført i den næste.
transactions_suggestionsLæs Flowtlys forslag til én banktransaktion — hvilken modpart, omkostningsgruppe eller dokument den skal registreres mod. Spejlbilledet af incomingInvoices_suggestions, set fra pengesiden.
transactions_importStatementImportér en kontoudtogsfil (fx en MT940 .sta-fil) — angiv hver fils rå tekstindhold ordret (IKKE base64) sammen med et filnavn. DER ER INGEN bankAccount-PARAMETER: backend'en dirigerer en fil ved at fjerne alle ikke-cifre fra dine bankkontonumre og fra filens bytes og importere til enhver konto, hvis cifre optræder et sted i filen — så én fil kan lande på flere konti, og et kontoudtog for en konto, der ikke er sat op i Flowtly (eller hvis nummer er registreret anderledes, end banken skriver det), importeres til ingen af dem og fejler med en fejlmeddelelse, der forklarer nøjagtig hvorfor — læs den meddelelse, det er den eneste diagnostik, dette endpoint giver dig. Ved succes er svaret `{ imported, matching }`: `matching: "in_progress"` betyder, at kontrahent-/bilagsmatchning for de nye rækker stadig kører, efter at dette kald returnerer, så et umiddelbart transactions_list kan vise rækker, der endnu ikke er matchet — genlæs lidt senere for den endelige tilstand. Genimport af det samme kontoudtog opretter ikke duplikerede rækker; importøren genkender transaktioner, den allerede har set. Når et kontoudtog er inde, kan du pege en eksisterende betaling uden banklinje på en af dens rækker med invoiceTransactions_update. Skrivning.
transactions_deleteSletter en banktransaktion via id — find den med transactions_list. Brug KUN dette til at fortryde en bogføringsfejl, der ikke kan rettes på anden vis: et kontoudtog importeret til den forkerte bankkonto, eller rækker indtastet manuelt, før det rigtige udtog kom, og som nu dubleres af det. En transaktion er en registrering af, hvad banken gjorde, så at slette en på en importeret konto får regnskabet til at afvige fra banken; backend tillader det kun for ROLE_ADMIN (en transaktionsansvarlig må kun slette på kasse- og manuelle konti). FØR du sletter en formodet dublet, så bevis parret: match den importerede række på beløb OG fakturanummer OG modpart, ikke på beløb alene — en indbetaling, der kom efter udtogets slutdato, har ingen modpart, og at slette den ødelægger det eneste spor af den indtægt. Backend FRAKOBLER i stedet for at slette det, der hænger på den: fakturabetalinger består med tømt banklinje (peg dem om med invoiceTransactions_update), vedhæftninger og ejendomme frakobles, mens projekt- og medarbejdertransaktionsrækker fjernes sammen med den. Uigenkaldeligt, med stor virkning. Skrivning.

Tidsregistreringer

Tools

workTimes_getHent én tidsregistrering ud fra id — dato, minutter, projekt, noter og den medarbejder, den tilhører.
workTimes_listList tidsregistreringer (loggede timer). Filtrer efter datointerval (date.after/date.before, ÅÅÅÅ-MM-DD) og eventuelt efter employee eller project; paginer med cursor. Hver række bærer employeeId/employeeName og projectId/projectName, så det er sådan, I eksporterer alle loggede timer for en periode. VIGTIGT: resultater på tværs af hele organisationen kræver ROLE_WORKING_HOURS_VIEWER. Uden den fejler backenden IKKE — den returnerer stiltiende kun den tilsluttede brugers egne registreringer, så en eksport af "alles timer" kan komme tilbage med kun én person og se helt normal ud. Hvis hver eneste række tilhører én medarbejder, og I ikke har filtreret efter employee, bærer svaret en scopeWarning, der gør opmærksom på det — gør brugeren opmærksom på den i stedet for at fremstille resultatet som organisationsdækkende.
workTimes_logRegistrér en arbejdstidspost for den tilknyttede Flowtly-bruger (date, durationMinutes, project, notes). NOTEN SKAL BESTÅ SERVERENS TJEK FOR TYND BESKRIVELSE, som en batch-efterindlæsning rammer gentagne gange: den skal enten have ca. 32 tegn (den præcise grænse er en indstilling pr. organisation, og en organisation kan sætte den til 0 for at slå tjekket fra), ELLER en "#"-ticketreference, ELLER et http(s)-link — én af delene er nok. "Flowtly – Scallier" afvises; "Flowtly – Scallier #FLOW-123" gør ikke. 422-fejlen navngiver propertyPath `description`, som er serverens navn for det felt, dette værktøj kalder `notes`. Skrivning.
workTimes_updateRet én registreret arbejdstidspost ud fra id — dens date, minutes, project eller description. Sådan FLYTTES en fejlplaceret post mellem projekter: workTimes_log opretter kun nogensinde, så uden denne er et forkert project eller en tastefejl i beskrivelsen permanent. Læs posten først med workTimes_get. Det samme tjek for tynd beskrivelse gælder som på workTimes_log: cirka 32 tegn — grænsen er en indstilling pr. organisation og kan være 0, hvilket slår den fra — ELLER en "#"-ticketreference, ELLER et http(s)-link, én af de tre er nok. Skrivning.
workTimes_deleteSlet én registreret arbejdstidspost ud fra id. Til en dublet eller en post registreret mod arbejde, der aldrig fandt sted — foretræk workTimes_update, når posten er reel, men forkert, så timerne bliver i posten frem for at forsvinde fra den. Registrerede timer fodrer projektøkonomi og udnyttelsesgrad, så en sletning stille ændrer rapporterede tal for en tidligere periode. Skrivning.

Tags

Tools

tags_createKnytter en tagdefinition til en post (tagDefinition + relationName + relationId; f.eks. relationName "counterparty" for at tagge en leverandør). Brug relationName "project" til at LÆGGE ET PROJEKT I EN MAPPE, hvor tagDefinition er mappen. Kun rodprojekter (uden overordnet projekt) grupperes i mapper — faser følger deres overordnede projekt, så placer roden, og træet følger med. Skrivning.

Kundekontakter

Tools

clientContacts_createOpret en kontaktperson for en kunde (client, type, name, email påkrævet). Skrivning.

Modparters bankkonti

Tools

counterpartyBankAccounts_createKnyt en bankkonto til en modpart (counterparty + accountNumber). Skrivning.

Betalingsplanlinjer

Tools

paymentScheduleLines_importIndlæs en kontrakts hele afdragsplan i ét kald, i stedet for én tur-retur pr. linje. Bygget til developer-kontrakter, som betales i byggetrancher — et enkelt salg er seks til tolv afdrag, og et register over dem er hundredvis. Hver række navngiver sin kontrakt VED NAVN (for en importeret developer-kontrakt, dens aftalenummer), en forfaldsdato og et beløb i MINDSTE ENHEDER — grosze, så 5.300,00 er "530000", og "5300" bogfører tavst 53,00. Rækker afstemmes mod de linjer, der allerede er der, på contract+date+amount+note, så en ukendt linje oprettes, en identisk springes over, og en gentaget kørsel af samme batch ændrer intet; PaymentScheduleLine har ingen ekstern referencekolonne, så den naturlige nøgle er afstemningsnøglen. En række, hvis kontraktnavn ikke matcher noget, eller matcher MERE end én kontrakt, rapporteres som fejlet frem for at blive knyttet til et gæt — at sætte et afdrag på den forkerte kontrakt fejlangiver to pengestrømme på én gang. Send dryRun:true først ved en reel indlæsning. Maks. 1000 rækker. Skrivning.
paymentScheduleLines_createTilføj ét afdrag til en kontrakts betalingsplan — planen for, hvad der forventes faktureret eller betalt, og hvornår. Send kontrakt-IRI'en, en dato og et beløb. Dette er det, der rydder problemet med manglende betalingsplan, contracts_get rapporterer på en ikke-cyklisk kontrakt: et engangsgebyr har stadig en plan, det er blot én linje for hele beløbet på den dag, det forfalder. Cykliske kontrakter tjekkes ikke for en, fordi systemet ikke automatisk genererer linjer ud fra en kadence. BELØB ER I MINDSTE ENHEDER — grosze, ikke złoty: 5.300,00 er "530000", og "5300" bogfører tavst en linje på 53,00. API'et returnerer dem på samme måde, så læs en tilbage med contracts_paymentScheduleLines, hvis du er i tvivl om skalaen. Læs resultatet tilbage med contracts_paymentScheduleLines. Skrivning.
paymentScheduleLines_updateRet én betalingsplanlinje ud fra id — dens dato, beløb eller note. Brug den, når et afdrag rykker eller genforhandles, frem for at slette og genoprette, så linjen beholder enhver faktura, der allerede er matchet til den. BELØB ER I MINDSTE ENHEDER — grosze, ikke złoty: 5.300,00 er "530000", og "5300" bogfører tavst en linje på 53,00. API'et returnerer dem på samme måde, så læs en tilbage med contracts_paymentScheduleLines, hvis du er i tvivl om skalaen. Skrivning.
paymentScheduleLines_deleteFjern én betalingsplanlinje ud fra id. Sletter PLANEN, ikke pengene: en faktura eller transaktion, der allerede er matchet til linjen, påvirkes ikke, men den stopper med at blive afstemt mod noget. Foretræk paymentScheduleLines_update til et afdrag, der er flyttet. Skrivning.

Organisationsikon

Tools

organizationIcon_uploadUpload/erstat organisationens ikon/favicon (base64-billede + contentType + filename). Læs det aktuelle via configs_get organization-icon-url. Skrivning.

Lager

Tools

storage_uploadVedhæft en fil til enhver post, Flowtlys generiske storage accepterer — et AKTIV (relationName "property"), et project, en task, en client, en location, en contractor, en invoice. Dette er den eneste vej til et aktiv-BILLEDE: at uploade med relationName "property" sætter det billede, appen viser for det aktiv (leveret som `file` på aktivets payload). Property har ingen billedkolonne — billedet udledes fra denne tabel ved læsning, hvilket er hvorfor intet på entiteten antyder, at det findes. Det er ÉT slot, og den nyeste upload vinder, så et andet billede erstatter det første frem for at blive føjet til et galleri. Det samme gælder for location, invoices og transaction-attachments; clients, agreements og candidates ophober i stedet hver upload under `files`. ENHVER ANDEN RELATION KOBLER UPLOADEN TIL INTET SYNLIGT, og relationName "employees" er den, man skal passe på med: den gemmer bytes og opretter INGEN Document, så People > Documents forbliver tom, og medarbejderens payload bærer ingen fil. /documents-ruten på enhver post returnerer Document-entiteter, og en upload opretter ingen — det var sådan, underskrevne NDA- og ESOP-PDF'er blev rapporteret som arkiveret, mens fanen Documents intet viste (#255). Et reelt medarbejderdokument kræver POST /documents med en DocumentType, hvis relationName er `employee`, medarbejderens id og IRI'en for den Storage-række, dette kald returnerer. SAML DET IKKE I HÅNDEN: brug employeeDocuments_createUploadTicket, som udfører alle tre trin — gemmer bytes, opretter Document'et og læser det tilbage via /people/{id}/documents — og rapporterer stored / linked / verified hver for sig. Dette værktøj stopper ved bytes. Grib heller ikke efter agreementTypes.*: en AgreementType er typen af en ansættelsesKONTRAKT (Umowa o pracę, Umowa zlecenie) under Ludzie > Umowy og er ikke en DocumentType. Rapportér bytes gemt, forretningspost koblet og synlighed verificeret som tre separate påstande, og påstå kun dem, du faktisk har udført. `file` udelades fra LIST-svar, medmindre forespørgslen sender ?include=file, så læs én post tilbage for at bekræfte, at billedet landede. Send relationName + relationId (id'et fra den posts listeværktøj; en /assets/7-IRI accepteres og reduceres) plus bytes som base64 med en contentType og filename. STØRRELSESGRÆNSE: bytes rejser som base64 inde i dette kald, så hold det under cirka 150 KB — fotografier er næsten altid over det, og til dem skal du bruge storage_createUploadTicket, som ikke har noget loft. Tilladelser er det, redigering af den EJENDE post kræver: backend'en løser relationName op til den entitet og spørger dens egen voter, så arkivering mod et aktiv kræver aktiv-tilladelsen, mod en client clients-tilladelsen. For en kontrakt skal du i stedet foretrække contractAttachments_create — den rydder også contracts.problem_missing_document, hvilket dette ikke gør. Skrivning.
storage_createUploadTicketUdsted en kortvarig engangsbillet til at vedhæfte en STOR fil til enhver post — sådan kommer aktiv-BILLEDER faktisk ind, da et billede altid ligger over base64-loftet. På property/location/invoices/transaction-attachments bliver den nyeste upload postens synlige billede og erstatter den forrige; på clients/agreements/candidates ophobes uploads. Brug denne i stedet for storage_upload, når filen er mere end nogle få titusinder KB: det værktøj bærer bytes som base64, som en kaldende part skal udsende som tekst, og et 400 KB JPEG bliver til ~533 K base64-tegn, langt over hvad der er plads til i ét svar. Send relationName + relationId plus et filename; du får en uploadUrl og en klar-til-kørsel curl tilbage. Send derefter filens RÅ BYTES til den URL (curl --data-binary @photo.jpg) — ikke base64, ikke multipart — og svaret bærer den oprettede Storage-post. Billetten udløber om 15 minutter, virker én gang, og kan kun arkivere mod den ene post, den navngiver. Skrivning.

Kontraktbilag

Tools

contractAttachments_createVedhæft et dokument til en kontrakt — normalt den underskrevne PDF, eller en annex (DPA, SLA, prisannex) arkiveret sammen med den. Send bytes som base64 med et fileName og kontrakt-id'et fra contracts_list; `contractId` her er et RENT id, i modsætning til de IRI'er, contracts_update tager for counterparty og project, selvom en fuld /contracts/<id>-IRI accepteres og strippes. STØRRELSESGRÆNSE: bytes rejser som base64 inde i dette kald, så hele dokumentet skal passe i ét modelsvar — hold det under cirka 150 KB, og brug contractAttachments_createUploadTicket i stedet for alt større, hvilket er bygget præcis til dette og ikke har et sådant loft. En underskrevet kontrakt med et signaturkort er som regel langt over det (673.617 bytes bliver til 898.156 base64-tegn, flere gange hvad ét svar kan bære), og der kommer ingen fejl tilbage, når det ikke passer, fordi kaldet slet ikke kan udsendes — forespørgslen når aldrig serveren, så tjek filstørrelsen FØR start frem for at opdage det ved at fejle. Dette er det, der rydder problemet med manglende dokument, contracts_get rapporterer, så en kontrakt vedligeholdt via API'et stopper med at ligge i appens kø til oprydning. Ét underskrevet dokument kan understøtte flere kontraktrækker (en aftale med både en tilbagevendende del og en engangsdel er to rækker, fordi `cyclic` er pr. post) — kald dette én gang pr. kontrakt-id med de samme bytes. Hvad der sker derefter, afhænger af kind. kind "contract": `status` kommer tilbage som "analyzing", og backend'en læser dokumentet asynkront, normalt inden for få minutter; poll contracts_get, indtil vedhæftningen er "analyzed" eller "failed" (en fejl bærer failureReason og failureRetryable). Læsningen UDFYLDER KUN TOMME felter i kontrakten og overskriver aldrig et navn, en retning, et beløb, datoer, valuta, betalingsbetingelser, planlinjer eller priser, der allerede står på den; hver udtrukket værdi forbliver i vedhæftningens analysisSummary, og analysisSummary.notApplied angiver, hvad den efterlod som et forslag. kind "annex": gemt og IKKE analyseret; `status` er "stored", hvilket er endeligt, og kontrakten ændres ikke. Behandl analysisSummary som et FORSLAG, der skal tjekkes, frem for et faktum, der skal stoles på. Skrivning.
contractAttachments_createUploadTicketUdsted en kortvarig engangsbillet til at vedhæfte et STORT dokument til en kontrakt — den underskrevne PDF, eller en annex. Brug denne i stedet for contractAttachments_create, når filen er mere end nogle få titusinder KB: det værktøj bærer bytes som base64, som en kaldende part skal udsende som tekst, og en rigtig underskrevet kontrakt (~700 KB, ~900 K base64-tegn) er langt over, hvad der er plads til i ét svar. Send kontrakt-id'et fra contracts_list plus et fileName; du får en uploadUrl og en klar-til-kørsel curl tilbage. Send derefter filens RÅ BYTES til den URL (curl --data-binary @file.pdf) — ikke base64, ikke multipart — og svaret er det oprettede vedhæft. Billetten udløber om 15 minutter, virker én gang, og kan kun vedhæftes til den ene kontrakt, den navngiver. Dette er det, der rydder problemet med manglende dokument, contracts_get rapporterer. Skrivning.

Fakturatransaktioner

Tools

invoiceTransactions_createRegistrér en betaling mod en udgående (salgs-) faktura. `invoice` er en faktura-IRI fra invoices_list; `date` er det tidspunkt, betalingen behandles som foretaget. `transaction` er valgfrit — udelad den for at registrere afregning uden en banklinje, hvilket er det, du ønsker for historiske fakturaer, hvis kontoudtog aldrig er blevet importeret. `amount` er valgfrit og defaulter til fakturaens udestående beløb. At registrere en betaling er det, der stopper en udstedt, forfalden faktura fra at blive behandlet som ubetalt, så det er også det, der stopper betalingspåmindelser fra at blive sat i kø til den. Intet forhindrer registrering af to betalinger mod én faktura, så læs invoices_get først, hvis du er i tvivl om, hvorvidt en allerede er afregnet. Skrivning.
invoiceTransactions_updateOpdatér en eksisterende faktura-betalingspost ud fra id (fra invoices_get's invoiceTransactions, eller ved at sideinddele invoiceTransactions). Den mest almindelige brug: peg en betaling registreret uden en banklinje på en transaktion, du lige har importeret via transactions_importStatement, ved at sætte `transaction` til en transaction-IRI/id fra transactions_list. FÆLDEN: dette er en PATCH, men backend'en kræver stadig `invoice` og `date` ved hvert kald — den sammenfletter IKKE de eksisterende værdier for dig. Læs posten først (eller hav den allerede fra oprettelseskaldet), og gensend dens `invoice` og `date` uændret sammen med det, du faktisk ønsker at ændre, ellers afvises opdateringen. `transaction` accepterer null for at frikoble en betaling fra en banklinje. `amount` er valgfrit. Skrivning.
invoiceTransactions_deleteSletter en betalingspost fra en faktura via id — id'erne læser du fra invoiceTransactions i invoices_get. Dette fjerner REGISTRERINGEN AF, AT EN FAKTURA ER BETALT, ikke en banktransaktion: brug det, når en faktura bærer en betaling, der aldrig burde have eksisteret, typisk den samme betaling bogført to gange — én gang manuelt og én gang af kontoudtogsimporten, som senere matchede den. Tjek invoices_get først, og slet den post, hvis `transaction` er den forkerte (behold den, der peger på den rigtige importerede banklinje); sletning af den sidste tilbageværende betaling gør fakturaen ubetalt igen, hvilket genaktiverer dens betalingspåmindelser. Kræver ROLE_INVOICES_MANAGER. Uigenkaldeligt, med stor virkning. Skrivning.

Ressourcestyring

Tools

resourcing_importTimelineImportér et regneark med en ressourceallokeringstidslinje (hent det via Drive MCP'en, angiv dets CSV ordret). Dette er et FULDT ERSTATTENDE spejl af organisationens Allocation-rækker for `year`: rækker i arket oprettes/opdateres, og enhver eksisterende række for det år, der ikke findes i arket, SLETTES — det er ikke en sammenfletning. TØRKØRSEL SOM STANDARD: et udeladt dryRun forhåndsviser og skriver intet; angiv dryRun:false for at anvende. Rapporten giver `created`/`replaced` plus `unmatchedPeople`/`unmatchedProjects`. TO TING ER LETTE AT OVERSE: en arkrække, hvis projekt ikke kan opløses, SPRINGES OVER, mens kaldet stadig rapporterer succes, så et grønt resultat kan skjule en delvis import; og en rollekode, som positionskataloget ikke allerede indeholder, OPRETTES som en ny position i stedet for at blive afvist — se `createdPositions`. Begge dele nævnes i `warnings`, når de sker; gør brugeren opmærksom på det i stedet for kun at rapportere `created`. Et ark, der parses til nul rækker, afvises (det ligner nøjagtig en fejlbehæftet læsning, der er ved at slette hele tidslinjen), medmindre du angiver force:true. Læs allocations_list bagefter for at se, hvad der blev registreret. Stor gennemslagskraft. Skrivning.

Organisation

Tools

organization_whoamiReturnér den organisation, denne MCP-forbindelse er bundet til — { orgId, name, slug, userId }. Kald den for at bekræfte, HVILKEN tenant du er ved at skrive til, før enhver create/update: forbindelsen er bundet til præcis én organisation af tokenet, og at skrive prospekter/poster til den forkerte organisation er en reel hændelse. Skrivebeskyttet.

Faktisk ressourceforbrug

Tools

resourcingActuals_getRapporterede timer versus planen, pr. person pr. uge, over et from/to-vindue — spørgsmålet 'følger teamet rent faktisk planen?', som INTET andet ressourceværktøj besvarer: allokeringer fortæller dig, hvad der var PLANLAGT, denne fortæller dig, hvad der blev LEVERET. Returnerer ugekolonner plus én række pr. person (planlagt %, rapporteret %, afvigelse, totaler og en opdeling pr. projekt). reportedPercent = null betyder 'ingen kontrakt den uge', og 0 betyder 'en kontrakt fandtes, og intet blev rapporteret' — sammenlign IKKE de to. Angiv financials for indtægt/omkostning/margin, som ellers udelades. Kræver ressourcemodulet og ROLE_RESOURCING_MANAGER. Skrivebeskyttet.

Ressourcebænk

Tools

resourcingBench_getHvem er IKKE bemandet over et from/to-vindue — bænken. Brug den, når der spørges om, hvem der skal sættes på et nyt projekt, eller hvor kapacitet går til spilde; resourcingActuals_get fortæller dig, hvor belastede folk er, denne fortæller dig, hvem der slet ingen belastning har. DEN VED IKKE NOGET OM ORLOV: freePercent er 100 minus bekræftede allokeringer, intet andet, så en person med tre ugers godkendt ferie fremstår som 100 % ledig, og intet felt i svaret siger andet. At besvare 'hvem er tilgængelig' udelukkende ud fra denne vil sætte folk på projekter, mens de er væk — krydstjek med holidays_active eller holidays_list. Kræver ressourcemodulet. Skrivebeskyttet.

Ressourceplan

Tools

resourcingSchedule_getDen planlagte ressourceplan over et from/to-vindue — allokeringstidslinjen, som planlæggeren viser den. Brug den til, hvad der er BOOKET fremadrettet; brug resourcingActuals_get til, hvad der faktisk blev rapporteret mod den. Kræver ressourcemodulet og ROLE_RESOURCING_MANAGER. Skrivebeskyttet.