MCP Server
Verbinde AI-Tools mit Flowtly über das Model Context Protocol unter mcp.flowtly.eu.
Verbinden
claude mcp add --transport http flowtly https://mcp.flowtly.eu/mcp
Auf dieser Seite
Agreements_get
Tools
| agreements_get | Eine Arbeitsvereinbarung anhand der id abrufen — type, variant, das dateFrom/dateTo-Fenster, hoursPerWeek sowie die abgeleiteten `calculable`, `active` und `status`. agreements_list liefert die id. Erfordert ROLE_AGREEMENTS_MANAGER oder ROLE_MEETING_MANAGER. Nur lesend. |
Agreements_list
Tools
| agreements_list | Arbeitsvereinbarungen auflisten — filterbar nach employee (IRI), isActive, type oder variant. DER Weg, um "warum sagt people_list, diese Person sei inaktiv" zu beantworten: Jede Zeile trägt `calculable` und `active`, und eine Person ist genau dann aktiv, wenn sie eine Vereinbarung hält, bei der beides zutrifft. Auch die Stelle, um die `type`-Codes zu lesen, die diese Organisation für Vereinbarungen tatsächlich verwendet, bevor agreements_create aufgerufen wird, da eine Organisation eigene hinzufügen kann. Erfordert ROLE_AGREEMENTS_MANAGER oder ROLE_MEETING_MANAGER. Nur lesend. |
Agreement Types_get
Tools
| agreementTypes_get | Einen Vertragstyp anhand der id abrufen — dessen name oder translationKey, `calculable`, `isActive`, `position` und `builtIn`. Die id IST der Code, das heißt, dies liest einen Typ mit demselben String zurück, den eine Vereinbarung in `type` speichert. Damit lässt sich bestätigen, dass ein Typ nach agreementTypes_create persistiert wurde, und `calculable` prüfen, bevor jemand darauf gesetzt wird. Erfordert ROLE_USER. Nur lesend. |
Agreement Types_list
Tools
| agreementTypes_list | Die Vertragstypen auflisten, die DIESE Organisation einer Vereinbarung zuweisen kann — die Werte hinter `Ludzie > <person> > Umowy > Edytuj umowę`. Vor agreements_create oder agreements_import lesen, denn die Liste ist pro Mandant: Fünf eingebaute Typen werden mitgeliefert ("agreement", "annex", "termination", "list-of-intent", "work-experience"), und eine Organisation kann eigene hinzufügen, sodass ein `type`, der in einer Organisation gültig ist, in einer anderen zu einem 422 führt. DIE ID IST DER CODE — die `id` jeder Zeile ist genau der String, den `agreements_create` in `type` erwartet, kein numerischer Schlüssel zum Nachschlagen. `calculable` ist das Feld, das entscheidet, ob das Halten dieses Typs jemanden AKTIV macht und in die Ressourcenplanung, den Urlaubsanspruch und die Kostenbasis einbezieht; ein nicht-calculable Typ lässt die Person ohne jede Fehlermeldung inaktiv — das ist bei einem Typ wie "list-of-intent" beabsichtigt und ein stiller Bug, wenn er versehentlich gewählt wurde. `builtIn`-Zeilen tragen einen translationKey und einen null-name; benutzerdefinierte Zeilen tragen einen wörtlich gerenderten name und einen null-translationKey. Erfordert ROLE_USER. Nur lesend. |
Allocations_get
Tools
| allocations_get | Eine Zuweisung nach id — die Buchung einer Person auf einem Projekt, mit ihren Daten und ihrem Prozentsatz. allocations_list findet die id; dieses Tool liest den vollständigen Datensatz. Eine Zuweisung ohne Mitarbeiter ist eine OFFENE Rolle (ungedeckter Bedarf), keine Buchung. Erfordert das Resourcing-Modul. Nur lesend. |
Allocations_list
Tools
| allocations_list | Listet Resourcing-Zuweisungen — datumsbezogene Zuordnungen einer Position auf einem Projekt zu einem Mitarbeiter (oder noch zu niemandem, eine offene Rolle). Keine Filter; Paginierung per Cursor. Jedes Element enthält employeeId/employeeName und projectId/projectName bereits aufgelöst (null bei employeeId bedeutet eine offene Rolle); positionId ist unaufgelöst — den Namen über positions_list ermitteln. source unterscheidet aus einem Sheet importierte Zeilen von solchen, die direkt in Flowtly erstellt wurden. Damit lässt sich ein Resourcing-Sheet-Import abgleichen: auslesen, was tatsächlich angekommen ist, und mit dem Übermittelten vergleichen. |
Asset Bookings_get
Tools
| assetBookings_get | Eine Asset-Buchung anhand der id abrufen — das Asset, dessen Inhaber, die Daten und ob sie storniert wurde. Nur lesend. |
Asset Bookings_list
Tools
| assetBookings_list | Asset-Buchungen auflisten — wer oder was jedes Asset aktuell hält; das ist die Zuordnung, die der Assets-Bildschirm zeigt, und die einzige Stelle, an der eine Verknüpfung zwischen Asset und Person tatsächlich existiert. Jede Zeile trägt das Asset, den Inhaber (`relationName` employee | project plus `relationId`), Start-/Enddatum sowie, sobald freigegeben, `cancelReason` und `cancelledAt`. Nach `property` filtern, um die Historie eines Assets zu sehen, oder nach `employee`, um alles zu sehen, was eine Person hält — Letzteres ist das, was vor dem Ausscheiden einer Person auszuführen ist. Zu beachten: `employee` ist hier die NUMERISCHE id, nicht die /people-IRI, die assetBookings_create erwartet. `exists.cancelledAt: false` hinzufügen, um nur noch Gehaltenes zu sehen; ohne diesen Filter enthält die Liste auch freigegebene Buchungen. Nur lesend. |
Asset Meter Readings_get
Tools
| assetMeterReadings_get | Eine Zählerablesung anhand der id abrufen — deren Zähler, Datum und Wert. Nur lesend. |
Asset Meter Readings_list
Tools
| assetMeterReadings_list | Zählerablesungen auflisten — die datierten Werte, die zu einem Asset-Zähler erfasst wurden, die Rohdaten, aus denen die verbrauchsabhängige Kostenaufteilung liest. Jede Zeile trägt Zähler, Datum und Wert. Damit lässt sich die Historie eines Zählers lesen: ein Wert, der sich über Perioden hinweg nie ändert (ein feststehender oder gemeinsam genutzter Zähler), rechnet null ab, und ein Zähler ohne aktuelle Zeilen ist einer, den niemand abliest. Nur lesend. |
Asset Meters_get
Tools
| assetMeters_get | Einen Asset-Zähler anhand der id abrufen — das Asset, auf dem er sitzt, Utility-Typ, Einheit und externe/QR-Kennung, samt seiner Ablesungen. Nur lesend. |
Asset Meters_list
Tools
| assetMeters_list | Die Asset-Zähler der Organisation auflisten — die Medienzähler, die an Assets angebracht sind (Strom, Wasser, Gas, Wärme). Jeder trägt das Asset, auf dem er sitzt, seinen Utility-Typ und seine Einheit sowie seine Ablesungen. Nach `property` (das Asset, zu dem er gehört) und `utilityType` filtern. Damit lässt sich die meter-id auflösen, die readings erwartet, und Zähler erkennen, die null anzeigen, auf einem Wert feststehen oder an einem gemeinsam genutzten/Sammelzähler hängen. Nur lesend. |
Assets_get
Tools
| assets_get | Ein Asset anhand der id abrufen — name, status, Kategorie (attributeSet), parent, assetCode, Seriennummer, Kauf- und Garantiedaten, location und Buchungseinstellungen. Nur lesend. |
Assets_list
Tools
| assets_list | Die Assets der Organisation auflisten — das Register physischer Dinge, die sie besitzt oder verkauft, von Laptops und Schreibtischen bis zu Wohnungen, Parkplätzen und Lagereinheiten. Filterbar nach status (in-stock | damaged | sold), attributeSet (die Kategorie, nach der die Assets-Liste gruppiert), bookingAllowed oder einem Teil von name oder serialNumber; sortierbar nach name, status, serialNumber, boughtAt oder warrantyTo. NICHT PAGINIERT — die gesamte Menge kommt in einer Antwort zurück, sodass ein großes Register eine große Payload statt einer ersten Seite ist. Damit lässt sich die asset-id auflösen, die Asset-Buchungen und Asset-Dokumente erwarten. Nur lesend. |
Attribute Entity Values_list
Tools
| attributeEntityValues_list | Attribut-WERTE auflisten — was ein bestimmtes Asset, Projekt, Budget oder ein Kunde tatsächlich für ein gebundenes Attribut hält. Jede Zeile trägt das Attribut, den Wert und `relationId`, die die Entität benennt, zu der er gehört. Nur lesend. |
Attributes_get
Tools
| attributes_get | Eine Attributdefinition anhand der id abrufen — name, type, ob sie required oder multiple ist, Standardwert und Formatmuster. Nur lesend. |
Attributes_list
Tools
| attributes_list | Attribut-DEFINITIONEN auflisten — die benannten Felder (Fläche, Stockwerk, Preis), die Kategorien binden und für die Assets Werte tragen. Jede hat einen type: number | string | date | state | period. Nur lesend. |
Attribute Set Attributes_list
Tools
| attributeSetAttributes_list | Die Bindungen zwischen Kategorien und Attributdefinitionen auflisten — welche Felder bei welcher Kategorie erscheinen. Nur lesend. |
Attribute Sets_get
Tools
| attributeSets_get | Ein Attribute-Set anhand der id abrufen — dessen name, relationName, icon und die daran gebundenen Attribute. Nur lesend. |
Attribute Sets_list
Tools
| attributeSets_list | Die Attribute-Sets der Organisation auflisten — die KATEGORIEN, unter denen ein Asset, Projekt, Budget oder Kunde abgelegt ist. Nach relationName filtern: "property" für Asset-Kategorien (was die UI Typ zasobu nennt und wonach die Assets-Liste gruppiert), außerdem "project", "budget" und "client". Hierauf zurückgreifen, bevor eine neue Kategorie angelegt wird: eine durch Schreibweise oder Groß-/Kleinschreibung duplizierte Kategorie spaltet die Liste, die sie gruppiert, still auf, und nichts in der UI erklärt warum. Nur lesend. |
Bank Accounts_get
Tools
| bankAccounts_get | Ruft ein Bankkonto anhand der id ab — Name, Währung, Bank und das Format, in dem seine Kontoauszüge importiert werden. |
Bank Accounts_list
Tools
| bankAccounts_list | Listet die Bankkonten der Organisation. Filterung nach Bank, oder hidden setzen, um archivierte Konten einzuschließen. Damit lässt sich die bankAccount-id ermitteln, nach der transactions_list filtert. |
Banks_get
Tools
| banks_get | Eine Bank anhand der id abrufen — das Institut, nicht ein dort geführtes Konto. Für das Konto bankAccounts_get verwenden. |
Banks_list
Tools
| banks_list | Die Banken auflisten, bei denen die Konten der Organisation geführt werden. Versteckte Banken sind standardmäßig ENTHALTEN — hidden=false übergeben für die Auswahllisten-Ansicht, oder hidden=true, um die ausrangierten zu finden. Damit lässt sich die bank-id auflösen, nach der bankAccounts_list filtert und die bankAccounts_create benötigt. |
Budgets_employee Pnl
Tools
| budgets_employeePnl | GuV pro Mitarbeiter für ein Budget — was die Zeit jeder Person eingebracht hat gegenüber dem, was sie gekostet hat. Erfordert ROLE_BUDGETS_VIEWER. Nur lesend. |
Budgets_get
Tools
| budgets_get | Ein Budget anhand der id abrufen — dessen Zeitraum, Geltungsbereich und Einstellungen. Erfordert ROLE_BUDGETS_VIEWER. Nur lesend. |
Budgets_list
Tools
| budgets_list | Die Budgets der Organisation auflisten — die Zeiträume, gegen die Einnahmen und Kosten geplant und verglichen werden. Damit lässt sich die budget-id auflösen, die jedes pnl-Tool erwartet. Erfordert ROLE_BUDGETS_VIEWER. Nur lesend. |
Clients_get
Tools
| clients_get | Ruft einen Kunden anhand der id ab — Name, Land, Währung, Steuernummer und Status. |
Clients_list
Tools
| clients_list | Listet Kunden (die Kunden der Organisation). Filterung nach status, oder nach externalPaymentCustomerId, um den Kunden hinter einer Zahlungsanbieter-id zu finden. Damit lässt sich die client-id ermitteln, nach der invoices_list, deals_list, projects_list und contracts_list filtern. |
Config Keys_catalog
Tools
| configKeys_catalog | Listet jeden vom Backend erkannten Konfigurationsschlüssel der Organisation, mit Typ und zulässigen Werten. Dies ist der Katalog dessen, was konfigurierbar ist — vor configs_get oder configs_update lesen, statt einen Schlüsselnamen zu erraten. Berechtigungen werden vom Backend pro Schlüssel durchgesetzt, ein hier erscheinender Schlüssel garantiert also nicht, dass der verbundene Benutzer ihn schreiben darf. |
Configs_get
Tools
| configs_get | Liest einen Konfigurationswert der Organisation nach id, wobei die id ein Schlüssel aus configKeys_catalog ist (z. B. organization-logo-url, organization-icon-url). |
Contracts_get
Tools
| contracts_get | Ruft einen Vertrag anhand der id ab — Parteien, Richtung, Wert, wiederkehrende Konditionen und Daten. |
Contracts_list
Tools
| contracts_list | Verträge auflisten. Nach direction filtern — die gespeicherten Werte sind "out" (wir verkaufen / stellen aus) und "in" (wir kaufen / empfangen), sowie "unknown" — ein echter, filterbarer Zustand und kein Fehler. Ein durch Hochladen eines Dokuments erzeugter Vertrag startet als "unknown" und bleibt dort, bis eine Extraktion oder eine Person ihn klärt; den Filter also weglassen, um alle drei zu erhalten: separat abgefragte "in" und "out" ERGEBEN NICHT die gesamte Menge (flowtly-mcp#130). NICHT "outgoing"/"incoming": Diese treffen auf nichts zu und liefern eine leere Liste statt eines Fehlers. Filtert außerdem nach counterparty, project, cyclic, name oder tags. Damit lässt sich die contract-id auflösen, die contracts_paymentScheduleLines liest und an die deals_win einen gewonnenen Deal verknüpfen kann. |
Contracts_payment Schedule Lines
Tools
| contracts_paymentScheduleLines | Den Zahlungsplan eines Vertrags auflisten — die Raten, in denen er voraussichtlich fakturiert oder bezahlt wird. contractId aus contracts_list übergeben. Dies ist der Plan, nicht die Ist-Werte: mit transactions_list vergleichen, um zu sehen, was tatsächlich bezahlt wurde. Der Betrag jeder Zeile liegt in KLEINSTEN EINHEITEN vor — Grosze, nicht Złoty: "530000" entspricht 5 300,00, also vor der Weitergabe einer Zahl durch 100 teilen. |
Cost Groups_list
Tools
| costGroups_list | Listet Kostengruppen / Kostenstellen — die Kategorien, unter denen Kosten, Lieferanten und Eingangsrechnungen abgelegt werden. Damit lässt sich die costGroup-id ermitteln, die suppliers_create benötigt und die von Eingangsrechnungs-Vorschlägen vorgeschlagen wird. |
Counterparties_get
Tools
| counterparties_get | Ruft einen Geschäftspartner anhand der id ab. |
Counterparties_list
Tools
| counterparties_list | Listet Geschäftspartner auf — jede Partei, mit der die Organisation Geschäfte macht. Die Flags supplier und client geben an, welche Rolle(n) ein Geschäftspartner einnimmt; ein Datensatz kann beides sein. Dies ist die Partei auf einer Banktransaktion, gegen die Eingangsrechnungen und Transaktionen abgeglichen werden. Filtern Sie nach type, supplier, client, cyclic oder budgetNeutral. |
CRM Notes_get
Tools
| crmNotes_get | Ruft eine CRM-Notiz anhand der id ab. |
CRM Notes_list
Tools
| crmNotes_list | Listet Notizen zu Leads und Deals auf. Filtern Sie nach lead oder deal, um den laufenden Kommentarverlauf zu einem Datensatz zu lesen. |
Deal Lost Reasons_get
Tools
| dealLostReasons_get | Ruft einen Deal-Verlustgrund anhand der id ab. |
Deal Lost Reasons_list
Tools
| dealLostReasons_list | Listet die Gründe, aus denen ein Deal als verloren markiert werden kann, in Reihenfolge. deals_lose benötigt eine lostReasonId von hier. |
Deals_get
Tools
| deals_get | Ruft einen Deal anhand der id ab — Titel, Kunde, Phase, Betrag, Eigentümer, Kontakt, voraussichtliches und tatsächliches Abschlussdatum. |
Deals_list
Tools
| deals_list | Listet Deals/Opportunities auf — die Vertriebspipeline. Filtern Sie nach status (offen / gewonnen / verloren), stage, owner, client, lead oder nach expectedCloseDate-/closedAt-Zeiträumen. Beträge sind in Kleinsteinheiten mit expliziter Währung angegeben; verlassen Sie sich nicht auf die Standardwährung der Organisation. |
Deal Stage Histories_get
Tools
| dealStageHistories_get | Ruft einen Deal-Phasenwechsel-Datensatz anhand der id ab. |
Deal Stage Histories_list
Tools
| dealStageHistories_list | Listet die Phasenübergänge eines Deals, neueste zuerst. Filterung nach Deal. Jedes deals_update, das die Phase ändert, wird hier automatisch protokolliert — so lässt sich rekonstruieren, wie lange ein Deal in jeder Phase verbracht hat; der Deal selbst führt nur seine aktuelle Phase. |
Departments_list
Tools
| departments_list | Die Abteilungen der Organisation, mit der numerischen id, unter der jede referenziert wird. DIES VOR people_create ODER people_update LESEN: Beide akzeptieren eine `department`-IRI, und es gibt keinen anderen Weg, eine gültige zu ermitteln. Die Collection ist nicht paginiert und nach name sortiert, sodass ein einzelner Aufruf jede Abteilung der Organisation zurückgibt. Filterbar nach `name` (Teiltreffer) oder `code` (exakt). Zeilen tragen id, name und code; `manager` ist eine Relation und ist in Listenzeilen nicht enthalten — bei Bedarf mit people_list von der anderen Seite lesen. Erfordert ROLE_EMPLOYEES_VIEWER. Nur lesend. |
Holiday Days Limits_get
Tools
| holidayDaysLimits_get | Eine Anspruchszeile anhand der id — der Betrag, der Typ, die Vertragsvariante und das Datum des Inkrafttretens. holidayDaysLimits_list findet die id. Beträge liegen in SEKUNDEN vor (#3763). Nur lesend. |
Holiday Days Limits_list
Tools
| holidayDaysLimits_list | Wie viel Urlaub jeder Person pro Typ ZUSTEHT — nicht, wie viel sie bereits genommen hat, das ist holidays_list. Nach employee filtern. Eine Person kann im Laufe der Zeit mehrere Zeilen für einen Typ halten, weil ein Saldo aufgestockt oder korrigiert wird: Die GÜLTIGE Zeile ist die mit dem spätesten bereits erreichten dateFrom, und im Voraus datierte Zeilen werden bis dahin bewusst ignoriert. Beträge liegen in SEKUNDEN vor (#3763) — ein 8-Stunden-Urlaubstag sind 28800. Erfordert ROLE_HOLIDAYS_MANAGER. Nur lesend. |
Holiday Requests_list
Tools
| holidayRequests_list | Urlaubs-ANTRÄGE und ihr Status — ausstehend, genehmigt, abgelehnt. Zu unterscheiden von holidays_list, das gebuchten Urlaub abbildet: Ein noch nicht entschiedener Antrag ist noch keine Abwesenheit, daher für die Planung holidays_list verwenden und dieses Tool, um zu sehen, was noch auf eine Entscheidung wartet. Liefert die holidayRequestId, die holidays_approve und holidays_bulkApprove benötigen. Nur lesend. |
Holidays_active
Tools
| holidays_active | Wer ist GERADE JETZT abwesend — jeder aktuell laufende Urlaub, organisationsweit, für alle. Dies ist das Tool für 'Wer ist heute nicht da', und dasjenige, mit dem gegengeprüft werden sollte, bevor freePercent aus resourcingBench_get als Verfügbarkeit interpretiert wird, denn der Pool zieht Urlaub nicht ab. Anders als holidays_list wendet es keine Projekteinschränkung an und erfordert keine Berechtigung über das Angemeldetsein hinaus, seine Antwort deckt also die gesamte Organisation ab. Gibt jede Abwesenheit mit Typ und Daten zurück. Nur lesend. |
Holidays_get
Tools
| holidays_get | Ein Urlaubsdatensatz nach id, mit Typ, Daten und Dauer. Die id aus holidays_list oder holidays_active beziehen. Nur lesend. |
Holidays_list
Tools
| holidays_list | Gebuchter Urlaub über einen Zeitraum — die Planungsansicht, während holidays_active nur über heute Auskunft gibt. Filterung nach Mitarbeiter, Datumsbereich oder Projekt. WAS SIE SEHEN, HÄNGT VON IHREN BERECHTIGUNGEN AB, und eine kurze Liste ist kein Beweis dafür, dass niemand abwesend ist: Ein Urlaubs-Manager oder Buchhaltungs-Betrachter erhält die gesamte Organisation, während eine Projektleitung oder ein Betrachter EINEN Projektfilter übergeben MUSS (oder nach sich selbst fragen) und ohne diesen rundweg abgewiesen wird — diese Ablehnung ist eine Berechtigungsgrenze, kein leerer Kalender. Nur lesend. |
Holiday Types_list
Tools
| holidayTypes_list | Die Urlaubstypen, die diese Organisation verwendet, mit der id, unter der jeder referenziert wird. Vor holidayDaysLimits_create/update lesen, die eine holidayType-IRI benötigen und sonst geraten würde. Der Typ, der kein Urlaub im gewöhnlichen Sinn ist, ist `pick-up-day` — freie Zeit, die für bereits geleistete Überstunden geschuldet wird (polnisch *odbior nadgodzin*), ein GEWÄHRTER Saldo statt eines jährlichen Anspruchs. Nur lesend. |
Incoming Invoices_get
Tools
| incomingInvoices_get | Ruft eine Eingangsrechnung (Lieferant) oder einen Beleg anhand der id ab, mit den per OCR erfassten Feldern und dem aktuellen Abgleichsstatus. |
Incoming Invoices_list
Tools
| incomingInvoices_list | Listet Eingangsrechnungen (Lieferanten) und Belegdokumente — der Buchhaltungs-Posteingang. Eine Eingangsrechnung IST ein an eine Banktransaktion angehängtes Dokument, daher findet man mit exists.transaction=false Dokumente, die noch keiner Zahlung zugeordnet sind. Filterung außerdem nach status, relatedMonth, Vertragspartner, Projekt, Tags oder hasDetectedProblems. Jedes Dokument ist als externalId 'upload_sha256:<sha256 der Bytes>' fingerprintet — eine Datei hashen und VOR incomingInvoices_create hier nach dieser externalId suchen, sonst wird ein Duplikat abgelegt. |
Incoming Invoices_match Candidates
Tools
| incomingInvoices_matchCandidates | Listet die Banktransaktionen auf, die die Zahlung für diese Eingangsrechnung sein könnten, bewertet vom backend-eigenen Matcher. Nutzen Sie dies, wenn einem Dokument keine Transaktion zugeordnet ist und Sie eine auswählen müssen; bevorzugen Sie diese Kandidaten, statt selbst anhand von Beträgen zu raten. |
Incoming Invoices_suggestions
Tools
| incomingInvoices_suggestions | Liest Flowtlys eigene Vorschläge für eine Eingangsrechnung — Lieferantenabgleich, Kostengruppe, passende Banktransaktion, Duplikatswarnung. Dies sind genau die Vorschläge, die ein Mensch in der App sieht. Zuerst lesen, dann einen davon per id mit incomingInvoices_applySuggestion anwenden, oder alle mit acceptAllSuggestions übernehmen. refresh übergeben, um neu zu berechnen, statt die zwischengespeicherte Menge zu liefern. |
Incoming Invoices_suggestions Debug
Tools
| incomingInvoices_suggestionsDebug | Erklärt, WARUM die Vorschläge einer Eingangsrechnung so ausgefallen sind, wie sie sind — die Bewertung des Matchers, zur Diagnose eines fehlenden oder falschen Vorschlags. Nur zu Diagnosezwecken; für die normale Arbeit incomingInvoices_suggestions verwenden. |
Initial Budget Items_list
Tools
| initialBudgetItems_list | Positionen des Ausgangsbudgets auflisten — die geplanten Beträge nach Tag, gegen die contractComparison antwortet. Erfordert ROLE_BUDGETS_VIEWER. Nur lesend. |
Initial Budgets_contract Comparison
Tools
| initialBudgets_contractComparison | GEPLANT gegen VERTRAGLICH GEBUNDEN, pro Tag — die geplanten Beträge des Ausgangsbudgets gegen die Summe der für dieses Projekt tatsächlich unterzeichneten Vertragswerte. Dies beantwortet die Frage "haben wir mehr gebunden, als budgetiert war, und wo", und liest direkt aus den bereits in der Organisation vorhandenen Verträgen, sodass ein Import von Verträgen die Frage ohne weitere Arbeit beantwortbar macht. Beträge liegen in Grosze vor; ein Projekt mit gemischten Währungen erzeugt einen Hinweis statt einer stillschweigend falschen Summe. Erfordert ROLE_BUDGETS_VIEWER. Nur lesend. |
Initial Budgets_get
Tools
| initialBudgets_get | Ein Ausgangsbudget anhand der id abrufen, samt seiner Positionen. Erfordert ROLE_BUDGETS_VIEWER. Nur lesend. |
Initial Budgets_list
Tools
| initialBudgets_list | Ausgangsbudgets auflisten — der URSPRÜNGLICHE Plan für ein Projekt oder eine Investition, im Gegensatz zum laufenden Budget, an dem er gemessen wird. Erfordert ROLE_BUDGETS_VIEWER. Nur lesend. |
Invoices_get
Tools
| invoices_get | Ruft eine Ausgangsrechnung (Verkauf) anhand der id ab — Kunde, Positionen, Summen, Verkaufs- und Ausstellungsdatum, Status. |
Invoices_list
Tools
| invoices_list | Listet Ausgangsrechnungen (Verkauf). Filterung nach Kunde, Tags, Suche oder einem saleDate-Bereich. Zu beachten: saleDate — nicht das Ausstellungsdatum und nicht das Erstellungsdatum — ist das Feld, nach dem invoices_export filtert; beim Abgleich eines Exports hier dasselbe Feld verwenden. |
Lead Activities_get
Tools
| leadActivities_get | Ruft eine Lead-Aktivität (Kontaktaufnahme) nach id ab. |
Lead Activities_list
Tools
| leadActivities_list | Listet die Kontaktaufnahmen eines Leads — dessen Aktivitätsverlauf (Einladung gesendet, Antworten, Anrufe, Follow-ups). Filterung nach Lead, um die Historie eines Interessenten zu lesen. Dies ist das strukturierte Gegenstück zu crmNotes_list: Aktivitäten sind das typisierte, datierte Kontaktprotokoll; Notizen sind freier Kommentartext. |
Lead Contacts_get
Tools
| leadContacts_get | Ruft einen Lead-Kontakt anhand der id ab. |
Lead Contacts_list
Tools
| leadContacts_list | Listet die Kontaktpersonen auf, die Leads zugeordnet sind. Filtern Sie nach lead, um die Kontakte eines Interessenten zu lesen, oder nach email, um herauszufinden, von welchem Lead eine Nachricht stammt. |
Lead List Memberships_get
Tools
| leadListMemberships_get | Eine Lead-zu-Liste-Mitgliedschaft anhand der id abrufen. Ihr status und lastContactedAt sind eine vom Aufrufer geschriebene Momentaufnahme, kein Live-Zustand — siehe leadListMemberships_list. |
Lead List Memberships_list
Tools
| leadListMemberships_list | Auflisten, welche Leads auf welchen Outbound-Prospecting-Listen stehen. Filterbar nach list, lead oder status. VORSICHT: status und lastContactedAt sind eine MOMENTAUFNAHME, geschrieben von wem auch immer die Mitgliedschaft zuletzt importiert oder aktualisiert hat. Sie sind nicht abgeleitet, und nichts aktualisiert sie, wenn eine Aktivität erfasst wird — das Protokollieren einer Welle von 529 Follow-ups verändert keines der beiden Felder — sie können also beliebig weit zurückliegen. Um "wann haben wir diesen Interessenten zuletzt kontaktiert" zu beantworten, stattdessen das Aktivitätsprotokoll lesen: leadActivities_list für einen einzelnen Lead, leadActivities_byList für eine ganze Kampagne. leadListMemberships_syncFromActivities meldet die Lücke und kann sie schließen. |
Lead Lists_get
Tools
| leadLists_get | Ruft eine Outbound-Prospecting-Liste anhand der id ab. |
Lead Lists_list
Tools
| leadLists_list | Listet Outbound-Prospecting-Listen. Damit lässt sich die list-id ermitteln, die leadListMemberships_create benötigt. |
Lead Lost Reasons_get
Tools
| leadLostReasons_get | Ruft einen Lead-Verlustgrund anhand der id ab. |
Lead Lost Reasons_list
Tools
| leadLostReasons_list | Listet die Gründe auf, aus denen ein Lead als verloren markiert werden kann, in Reihenfolge. |
Leads_dedupe Check
Tools
| leads_dedupeCheck | Prüft, ob ein Interessent bereits im CRM vorhanden ist, mit denselben Filtern wie leads_list (companyName, source, owner, …). Dies VOR leads_create aufrufen: Ein doppelter Lead verteilt die Kontakthistorie auf zwei Datensätze, und nichts nachgelagert führt sie für Sie wieder zusammen. |
Leads_get
Tools
| leads_get | Ruft einen Lead anhand der id ab — Unternehmen, Website, Quelle, Status, Eigentümer und, falls vorhanden, den Kunden, zu dem er konvertiert wurde. |
Leads_list
Tools
| leads_list | Listet Leads — Interessenten-Ziele vor der Qualifizierung. Filterung nach status, source, owner, client, companyName oder createdAt/closedAt-Bereichen. Ein qualifizierter Lead wird über leads_convert zu einem Kunden plus einem offenen Deal; bis dahin existiert er nur hier, nicht in clients_list. |
Lead Stages_get
Tools
| leadStages_get | Ruft eine Lead-Phase anhand der id ab. |
Lead Stages_list
Tools
| leadStages_list | Listet die Phasen, die ein Lead durchläuft, in Reihenfolge. Leads haben ihren eigenen Phasensatz — Deals verwenden stages_list, was etwas anderes ist. |
Locations_get
Tools
| locations_get | Einen Standort anhand der id abrufen — dessen name und Öffnungszeiten. Nur lesend. |
Locations_list
Tools
| locations_list | Die Standorte der Organisation auflisten — die physischen Orte, an denen Assets stehen, in der UI als Lokalizacja angezeigt. Erfordert ROLE_LOCATIONS_MANAGER, die ungewöhnlicherweise auch das LESEN und nicht nur das Schreiben absichert. Nur lesend. |
Organization Addresses_get
Tools
| organizationAddresses_get | Einen Abo-Adressdatensatz anhand der id abrufen — name, street, city, postCode, country und die Steuerfelder. `street` enthält die Hausnummer, wenn sie manuell eingegeben wurde, nicht jedoch, wenn sie aus dem NIP/GUS-Lookup stammt. Nur lesend. |
Organization Addresses_list
Tools
| organizationAddresses_list | Die Abo-Adressdatensätze der Organisation auflisten — die an das Flowtly-Abonnement angehängte Adresse und die Quelle, aus der die Mail-Fußzeile {{organizationAddress}} rendert. Normalerweise genau eine Zeile. Dies ist NICHT die Verkäuferadresse auf Rechnungen, die in den organization-billing-*-Konfigurationsschlüsseln (configs_get) liegt und die Rechnungen und KSeF lesen; die beiden werden getrennt gepflegt und weichen regelmäßig voneinander ab. Beide lesen, bevor man schlussfolgert, welche ein Kunde tatsächlich bearbeitet hat. Nur lesend. |
Organizations_get
Tools
| organizations_get | Ruft eine Organisation nach id ab. WARNUNG — dies sagt NICHT aus, mit welcher Organisation Sie verbunden sind. Eine OAuth-Verbindung ist an genau eine Organisation gebunden (token-gebunden), aber dieser Endpunkt liefert jede Organisation, in der der verbundene BENUTZER Mitglied ist — ein erfolgreiches Lesen hier wirkt also wie eine Bestätigung, dass Sie in dieser Organisation arbeiten, obwohl das nicht der Fall sein muss. Um den tatsächlich aktiven Mandanten zu verifizieren, stattdessen mandantenbezogene Daten lesen — people_list oder clients_list — und niemals allein aufgrund dieses Aufrufs einen Massen-Schreibvorgang beginnen. |
People_get
Tools
| people_get | Ruft einen Personen-/Mitarbeiterdatensatz anhand der id ab — Namen, E-Mails, Telefon, Vorgesetzter und ob die Person aktiv ist. |
People_list
Tools
| people_list | Listet Personen/Mitarbeiter auf. Filtern Sie nach isActive, reportsTo (die id eines Vorgesetzten), projectMembers.project oder search; paginieren Sie mit cursor. Personen und Mitarbeiter teilen sich dieselbe id — so ermitteln Sie die employee-id, die Arbeitszeit, Zuständigkeiten, Projektmitgliedschaft und Berechtigungstools erwarten. |
Permission Groups_get
Tools
| permissionGroups_get | Ruft eine Berechtigungsgruppe anhand der id ab, einschließlich der ROLE_*-Strings, die sie gewährt. |
Permission Groups_list
Tools
| permissionGroups_list | Listet die Berechtigungsgruppen der Organisation und die Rollen, die jede davon gewährt — z. B. gewährt die Gruppe "Business Owner" ROLE_ADMIN. Dies vor people_setPermissionGroups lesen: Die Rollen in der Antwort sind maßgeblich dafür, was eine Gruppe tatsächlich erlaubt, sodass nie anhand des Namens geraten werden muss. |
Pipelines_get
Tools
| pipelines_get | Ruft eine Vertriebspipeline anhand der id ab. |
Pipelines_list
Tools
| pipelines_list | Listet Vertriebs-Pipelines. Eine Pipeline besitzt eine geordnete Menge von Phasen — diese mit stages_list, gefiltert nach pipeline, lesen. |
Positions_list
Tools
| positions_list | Listet Positionen — die benannten Rollen (z. B. "Backend Engineer"), die eine Projektzuweisung besetzt. Keine Filter; für Position ist Paginierung deaktiviert, daher liefert dies stets den vollständigen Rollenkatalog der Organisation in einem Aufruf. Jedes Element ist {id, name, roles}. Damit lässt sich der Positionsname hinter der positionId einer allocations_list-Zeile ermitteln, sowie die position-id finden, gegen die ein Resourcing-Import abgleichen muss. |
Project Members_get
Tools
| projectMembers_get | Eine Projektmitgliedschaft anhand der id abrufen — deren employee, project und position. Ids stammen aus projectMembers_list oder dem projectMembers-Array bei projects_get. |
Project Members_list
Tools
| projectMembers_list | Projektmitgliedschaften auflisten — WER WELCHES PROJEKT SEHEN KANN. Nach project (`/projects/{id}`) filtern, um die Besetzung eines Projekts zu sehen, oder nach employee, um jedes Projekt zu lesen, das eine Person erreichen kann; jede Zeile trägt ihre eigene id, den employee, das project und die position (employee|tech-lead|account-manager|viewer). Hierauf zuerst zurückgreifen, wenn jemand meldet, ein Projekt fehle in seiner Projektliste oder er könne keine Zeit dagegen buchen: Eine leere Besetzung oder eine Besetzung ohne diese Person IST die Erklärung — Sichtbarkeit ist Mitgliedschaft. Dies ist außerdem die id-Quelle für projectMembers_update und projectMembers_delete. Zu beachten: Dieselbe Person kann mehrfach in einem Projekt auftauchen, einmal pro position. |
Projects_cost Allocations
Tools
| projects_costAllocations | Wie Kosten AUF dieses Projekt aufgeteilt wurden — welche Transaktionen und Rechnungszeilen ihm zugeordnet wurden, und in welchem Anteil. Damit lässt sich eine Rentabilitätszahl erklären, statt sie nur zu zitieren: Hier wird ein unerwartetes Ergebnis auf das Dokument zurückverfolgt, das es verursacht hat. Erfordert ROLE_TRANSACTIONS_MANAGER. Nur lesend. |
Projects_folder Counts
Tools
| projects_folderCounts | Wie viele Projekte in jedem Projekt-ORDNER liegen, als folderId + total + active. Die folderId ist eine tagDefinition-id — Namen löst du mit tagDefinitions_list auf, und welche Gruppen Ordnergruppen sind, zeigt tagGroups_list (allowedRelations enthält "project"). Eine leere folderId ist der Sammelbereich für Nicht-Kategorisiertes. Zählt nur Wurzelprojekte, da Ordner Wurzeln gruppieren und Phasen ihrem übergeordneten Projekt folgen. Nur Lesen. |
Projects_get
Tools
| projects_get | Ruft ein Projekt anhand der id ab — Name, Typ, Kunde, Daten, Beschreibung und Preis. |
Projects_list
Tools
| projects_list | Listet Projekte auf. Filtern Sie nach type (fixed-price | time-and-material | non-billable | internal), client.name, employee, name oder dateFrom-/dateTo-Zeiträumen. Damit ermitteln Sie die project-id, die Aufgaben, Arbeitszeiterfassung, Budgets und Verträge allesamt benötigen. |
Projects_profitability
Tools
| projects_profitability | DAS ERGEBNIS PRO PROJEKT — was ein Projekt eingebracht hat gegenüber dem, was es gekostet hat. Das ist die Zahl, die ein Dienstleistungs- oder Entwicklungsunternehmen in der Regel sehen möchte, und diejenige, in die jedes andere Projekt-Tool einfließt. Die project-id aus projects_list übergeben. Erfordert ROLE_ACCOUNT_MANAGER. Nur lesend. |
Project Templates_get
Tools
| projectTemplates_get | Eine Projektvorlage anhand der id abrufen, samt ihres vollständigen structure-Dokuments. projectTemplates_list findet die id. Dies vor projectTemplates_update lesen — die structure wird ALS GANZES geschrieben, ein Update muss also das vollständige Dokument senden, nicht ein Fragment. Nur lesend. |
Project Templates_list
Tools
| projectTemplates_list | Die Projektvorlagen der Organisation auflisten — wiederverwendbare Blaupausen eines Projekts, seiner Phasen, seiner Aufgabenlisten und seiner Aufgaben. Hierauf VOR projects_create zurückgreifen, wenn dieselbe Art von Projekt wiederholt angelegt wird (eine Auftragsart, ein Audit, ein Onboarding): Das Instanziieren einer Vorlage baut den gesamten Baum in einem Aufruf, während projects_create ein leeres Projekt anlegt, das anschließend von Hand gefüllt werden muss. Die mit isDefault markierte Zeile ist die eingebaute Vorlage der Organisation, die auf ein ohne gewählte Vorlage angelegtes Projekt angewendet wird. Nur lesend. |
Resource Request Candidates_get
Tools
| resourceRequestCandidates_get | Ein Recruiting-Kandidat nach id. Die id stammt aus resourceRequestCandidates_list. Erfordert ROLE_HR_MANAGER. Nur lesend. |
Resource Request Candidates_list
Tools
| resourceRequestCandidates_list | Die für Stellenanfragen vorgeschlagenen Kandidaten — Personen in einer Recruiting-Pipeline, keine für Zuweisungen verfügbaren Mitarbeiter. Filterung nach der request-id aus resourceRequests_list. Erfordert ROLE_HR_MANAGER. Nur lesend. |
Resource Requests_get
Tools
| resourceRequests_get | Eine Stellenanfrage nach id, mit Position und Status. Die id aus resourceRequests_list beziehen. HR/Recruiting, keine Resourcing-Zuweisung. Erfordert ROLE_HR_MANAGER. Nur lesend. |
Resource Requests_list
Tools
| resourceRequests_list | Offene Stellenanfragen — eine Anfrage zur Rekrutierung für eine Position, im HR-Bereich. Trotz des Namens ist dies KEIN Resourcing-Zuweisungsbedarf: Es ist Recruiting. Liefert die Sammlung; resourceRequests_get liest eine einzelne, und resourceRequestCandidates_list liefert die dafür vorgeschlagenen Personen. Erfordert ROLE_HR_MANAGER. Nur lesend. |
Resourcing Requests_list
Tools
| resourcingRequests_list | Offene Resourcing-Anfragen — jemand bittet darum, eine Person einem Projekt zuzuweisen; dies ist die Bedarfsseite des Resourcing. Dies ist der Ablauf, den die Requests-Ansicht der Resourcing-UI darstellt. NICHT mit resourceRequests_list verwechseln: Jenes ist HR-RECRUITING (Einstellung für eine Position). Zusammen mit resourcingRequestsHistory_list verwenden, um zu sehen, was bereits entschieden wurde, und mit resourcingBench_get, um zu sehen, wer eine Anfrage erfüllen könnte. Erfordert das Resourcing-Modul und ROLE_RESOURCING_MANAGER. Nur lesend. |
Resourcing Requests History_list
Tools
| resourcingRequestsHistory_list | Was mit Resourcing-Anfragen bereits geschehen ist — der Entscheidungsverlauf (bestätigt, abgelehnt, geändert) hinter den offenen Anfragen in resourcingRequests_list. Damit beantworten, ob 'dies bereits angefragt und abgelehnt wurde', bevor dieselbe Zuweisung erneut vorgeschlagen wird. Erfordert das Resourcing-Modul und ROLE_RESOURCING_MANAGER. Nur lesend. |
Responsibilities_get
Tools
| responsibilities_get | Ruft eine Zuständigkeit anhand der id ab. |
Responsibilities_list
Tools
| responsibilities_list | Listet Zuständigkeiten innerhalb einer RACI-Gruppe auf. Filtern Sie nach responsibilityGroup. Zuständigkeiten können über parent verschachtelt werden; Personen werden ihnen über responsibilityEmployees zugewiesen, nicht direkt. |
Responsibility Employees_get
Tools
| responsibilityEmployees_get | Ruft eine Zuständigkeitszuweisung anhand der id ab. |
Responsibility Employees_list
Tools
| responsibilityEmployees_list | Listet auf, wer welcher Zuständigkeit zugewiesen ist und zu welchem Prozentsatz. Filtern Sie nach employee, um die gesamte RACI-Auslastung einer Person über alle Gruppen hinweg zu lesen. |
Responsibility Groups_get
Tools
| responsibilityGroups_get | Ruft eine Zuständigkeitsgruppe anhand der id ab. |
Responsibility Groups_list
Tools
| responsibilityGroups_list | Listet Zuständigkeitsgruppen / RACI-Bereiche auf — die übergeordneten "Odpowiedzialności"-Einträge, jeweils mit einer verantwortlichen Person. Einzelne Zuständigkeiten hängen darunter. |
Schedule Employees_get
Tools
| scheduleEmployees_get | Eine Zuordnung Zeitplan-zu-Mitarbeiter nach id. Die id stammt aus scheduleEmployees_list. Erfordert ROLE_SCHEDULES_MANAGER. Nur lesend. |
Schedule Employees_list
Tools
| scheduleEmployees_list | Welche Mitarbeiter welchen Arbeitszeit-Zeitplänen zugeordnet sind. Damit von einem Zeitplan (schedules_list) zu seinen Personen gelangen, oder den Zeitplan eines bestimmten Mitarbeiters finden. Erfordert ROLE_SCHEDULES_MANAGER. Nur lesend. |
Schedule Plan_list
Tools
| schedulePlan_list | Die an EINEM bestimmten Datum geltenden Zeitpläne — das Datum im Pfad übergeben. Damit beantworten, 'wer heute / an diesem Datum arbeitet', ohne jeden Zeitplan zu lesen und dessen Zeiträume selbst aufzulösen. Anders als die übrigen Zeitplan-Lesevorgänge benötigt dies nur ROLE_USER und steht damit auch einem gewöhnlichen Mitarbeiter zur Verfügung. Nur lesend. |
Schedule Ranges_get
Tools
| scheduleRanges_get | Ein Zeitplan-Zeitraum nach id. Die id stammt aus scheduleRanges_list. Erfordert ROLE_SCHEDULES_MANAGER. Nur lesend. |
Schedule Ranges_list
Tools
| scheduleRanges_list | Die Zeiträume, aus denen sich Arbeitszeit-Zeitpläne zusammensetzen — die tatsächlichen Stunden, die ein Zeitplan abdeckt. Zuerst das übergeordnete Element mit schedules_get lesen; dies liefert dessen Zeiträume im Detail. Erfordert ROLE_SCHEDULES_MANAGER. Nur lesend. |
Schedules_get
Tools
| schedules_get | Ein Arbeitszeit-Zeitplan nach id, mit seinen Zeiträumen und zugeordneten Mitarbeitern. Die id stammt aus schedules_list; scheduleRanges_list und scheduleEmployees_list lesen seine Bestandteile. Erfordert ROLE_SCHEDULES_MANAGER. Nur lesend. |
Schedules_list
Tools
| schedules_list | Arbeitszeit-Zeitpläne — die von einer Organisation definierten Schicht-/Arbeitsmuster, KEINE Projektzuweisung. resourcingSchedule_get verwenden, um zu sehen, wer worauf gebucht ist; dieses Tool für die Arbeitsmuster selbst. schedules_get liest einen einzelnen nach id. Erfordert ROLE_SCHEDULES_MANAGER. Nur lesend. |
Stages_get
Tools
| stages_get | Ruft eine Deal-Phase anhand der id ab. |
Stages_list
Tools
| stages_list | Listet Deal-Phasen, in Reihenfolge. Filterung nach pipeline. deals_create benötigt eine stage-id von hier, und das Verschieben eines Deals zwischen Phasen ist das, was dealStageHistories protokolliert. |
Suppliers_list
Tools
| suppliers_list | Listet Lieferanten/Auftragnehmer auf — ausgeliefert von /contractors, "supplier" und "contractor" sind also derselbe Datensatz. Filtern Sie nach cyclic für wiederkehrende Lieferanten. Damit ermitteln Sie den Lieferanten, gegen den eine Kosten-, Vertrags- oder Eingangsrechnungsposition verbucht ist. |
Tag Definitions_list
Tools
| tagDefinitions_list | Listet Tag-Definitionen — die Tags, die Datensätzen angehängt werden können, jeweils innerhalb einer Tag-Gruppe. tags_create benötigt eine tagDefinition-id von hier sowie den Datensatz, an den sie angehängt wird. |
Tag Groups_list
Tools
| tagGroups_list | Listet Tag-Gruppen auf — die Container, die Tag-Definitionen organisieren. |
Task Comments_list
Tools
| taskComments_list | Listet Kommentare zu Projektaufgaben auf, älteste zuerst. Filtern Sie nach task, um die Diskussion zu einer Aufgabe zu lesen. |
Task Lists_list
Tools
| taskLists_list | Listet Aufgabenlisten — die Board-Spalten/Bereiche, in denen Aufgaben abgelegt werden. Filterung nach project. tasks_create benötigt eine list-id von hier. |
Tasks_get
Tools
| tasks_get | Ruft eine Projektaufgabe anhand der id ab — Titel, Projekt, Status, Liste, Zugewiesene, Daten und Wiederholung. |
Tasks_list
Tools
| tasks_list | Listet Projektaufgaben. Filterung nach project, list, status, assignees, isTemplate oder startAt/dueAt-Bereichen. Wiederkehrende Aufgaben stellen recurrenceParent und recurrenceRule bereit, sodass ein generiertes Vorkommen bis zur erzeugenden Regel zurückverfolgt werden kann. Um zu entscheiden, ob eine Aufgabe ERLEDIGT ist, deren status mit taskStatuses_list (isClosed) abgleichen, statt den Statusnamen zu vergleichen. |
Task Statuses_list
Tools
| taskStatuses_list | Listet die Projektaufgabenstatus auf, in Board-Reihenfolge. isClosed kennzeichnet die abgeschlossenen Zustände und isDefault den Status, den eine neue Aufgabe erhält. Lesen Sie dies, bevor Sie den Status einer Aufgabe interpretieren — die Namen sind organisationsseitig konfigurierbar, sodass "Done" kein verlässlicher String zum Abgleich ist. |
Tax Groups_list
Tools
| taxGroups_list | Listet Steuergruppen. Damit lässt sich die taxGroup-id ermitteln, nach der taxRules_list filtert und die Rechnungspositionen führen. |
Tax Rules_list
Tools
| taxRules_list | Listet Steuerregeln auf — die Sätze und die Zeiträume, für die sie gelten. Filtern Sie nach taxGroup. |
Transactions_list
Tools
| transactions_list | Listet Banktransaktionen auf — den Kontoauszugs-Feed, gegen den Eingangsrechnungen abgeglichen werden. Filtern Sie nach bankAccount, counterpartyRole, cost, ignored, hasDetectedProblems, einem orderDate-/execDate-Zeitraum oder amount.between. Beachten Sie: orderDate und execDate sind unterschiedlich — eine Zahlung kann in einem Monat beauftragt werden und im nächsten ausgeführt werden. |
Transactions_suggestions
Tools
| transactions_suggestions | Liest Flowtlys Vorschläge für eine Banktransaktion — welchem Vertragspartner, welcher Kostengruppe oder welchem Dokument sie zugeordnet werden sollte. Das Gegenstück zu incomingInvoices_suggestions, von der Geldseite aus. |
Work Times_get
Tools
| workTimes_get | Ruft einen einzelnen Arbeitszeiteintrag anhand der id ab — Datum, Minuten, Projekt, Notizen und der zugehörige Mitarbeiter. |
Work Times_list
Tools
| workTimes_list | Listet Arbeitszeiteinträge (erfasste Stunden) auf. Filtern Sie nach Zeitraum (date.after / date.before, YYYY-MM-DD) und optional nach employee oder project; paginieren Sie mit cursor. Jede Zeile führt employeeId/employeeName und projectId/projectName, damit exportieren Sie alle erfassten Stunden für einen Zeitraum. WICHTIG: Organisationsweite Ergebnisse erfordern ROLE_WORKING_HOURS_VIEWER. Ohne diese Rolle meldet das Backend KEINEN Fehler — es liefert stillschweigend nur die eigenen Einträge des verbundenen Benutzers, sodass ein Export "aller Stunden" nur eine Person enthalten kann und dabei völlig unauffällig aussieht. Wenn jede Zeile zu einem einzigen Mitarbeiter gehört und Sie nicht nach employee gefiltert haben, führt die Antwort ein scopeWarning, das dies anzeigt — weisen Sie den Benutzer darauf hin, statt das Ergebnis als organisationsweit darzustellen. |
Agreements_create
Tools
| agreements_create | Eine Arbeitsvereinbarung für eine Person anlegen. DIES IST DER SCHRITT, DER JEMANDEN AKTIV MACHT: people_create legt nur den Datensatz an, und eine Person ohne Vereinbarung meldet isActive für immer als false — ein Massenimport landet daher zu 100% inaktiv, bis dies für jede Person ausgeführt wird. ZWEI DINGE MÜSSEN BEIDE ZUTREFFEN, sonst bleiben sie ohne jede Fehlermeldung inaktiv: `type` muss ein CALCULABLE-Typ sein (eingebaute "agreement", "annex", "termination" sind es; "list-of-intent" und "work-experience" nicht), und das dateFrom/dateTo-Fenster muss den heutigen Tag abdecken (dateTo null übergeben für einen laufenden Vertrag statt eines weit in der Zukunft liegenden Datums). `employee` ist eine IRI — /people/<id> aus people_list. Typen sind organisationsweit erweiterbar; agreements_list für eine bereits aktive Person ausführen, um die Codes zu sehen, die diese Organisation tatsächlich verwendet. Erfordert ROLE_AGREEMENTS_MANAGER. Schreibend. |
Agreements_update
Tools
| agreements_update | Eine bestehende Arbeitsvereinbarung ändern — so wird eine Vereinbarung BEENDET, denn das Backend bietet für diese Ressource kein Löschen: `dateTo` auf den letzten abgedeckten Tag setzen, und die Person ist ab dann nicht mehr aktiv, während der Datensatz und seine Historie erhalten bleiben. Das ist der richtige Weg für eine lohnrelevante Zeile; es gibt keine Möglichkeit, eine verschwinden zu lassen, und das sollte es auch nicht geben. Ebenso der Weg, um einen falschen `type`, `variant` oder `positionName` an Ort und Stelle zu korrigieren, statt eine zweite Vereinbarung auf die Person zu stapeln — ZWEI Vereinbarungen heben sich nicht auf, die calculable Vereinbarung hält die Person aktiv, sodass "eine korrekte daneben hinzufügen" die falsche still in Kraft belässt. `amount`, `amountType` und `billingType` werden akzeptiert, aber die API gibt sie nie zurück, sodass sich das Geschriebene nicht zurücklesen lässt. Erfordert ROLE_AGREEMENTS_MANAGER. Schreibend. |
Agreement Types_create
Tools
| agreementTypes_create | Einen Vertragstyp zur Liste DIESER Organisation hinzufügen, damit eine Vereinbarung gegen etwas erfasst werden kann, das die fünf eingebauten Typen nicht abdecken — "Umowa zlecenie", "Kontrakt B2B", "Użytkownik funkcyjny". Das ist Konfiguration, keine Codeänderung: Die Liste ist eine Tabelle pro Mandant, und ein benutzerdefinierter Typ braucht keinen Übersetzungseintrag, weil sein `name` wörtlich in allen sieben Locales gerendert wird. `id` NICHT SENDEN: Der Code wird serverseitig aus dem Namen geslugt, wobei diakritische Zeichen aufgelöst werden ("Użytkownik funkcyjny" wird zu "uzytkownik-funkcyjny"), und das Übergeben einer id wird mit 422 "Update is not allowed for this operation" abgelehnt. Den name posten und den zugewiesenen Code aus der Antwort zurücklesen. `calculable` IST STANDARDMÄSSIG FALSE UND STILL: Es entscheidet, wer als angestellt zählt — die Ressourcenplanung, der Urlaubsanspruch, die Kosten- und Budgetbasis — ein Typ für Personen, die KEINEN Urlaubsanspruch erwerben oder keine Vollzeitstelle belegen sollen, ist bei false korrekt, und ein Typ für echte Anstellung MUSS es auf true setzen, sonst meldet jede Person darauf ohne jede Fehlermeldung inaktiv. Nichts verrät, welchen Wert man erhalten hat. `position` ordnet das Dropdown; `isActive` ist standardmäßig true. Es gibt absichtlich kein Update oder Delete über MCP — `agreement.type` speichert die id dieser Zeile als bloßen String mit… |
Attribute Sets_create
Tools
| attributeSets_create | Eine Kategorie anlegen (name + relationName erforderlich; relationName ist eine von property | project | budget | client, und für eine Asset-Kategorie ist es der einfache String "property" — KEINE IRI). Optionales icon aus einer festen Liste (room, parking, building, office, local, desk, monitor und so weiter), das die UI neben der Kategorie zeigt. ZUERST LISTEN: Namen sind nicht eindeutig, sodass ein zweites "Mieszkanie" akzeptiert wird und die Assets-Liste still in zwei Teile spaltet. Erfordert ROLE_ATTRIBUTES_MANAGER. Schreibend. |
Attribute Sets_update
Tools
| attributeSets_update | Eine Kategorie umbenennen, ihr icon ändern oder sie zu einer anderen relationName verschieben. So wird eine mit einem Tippfehler angelegte Kategorie korrigiert statt dupliziert. Erfordert ROLE_ATTRIBUTES_MANAGER. Schreibend. |
Attributes_create
Tools
| attributes_create | Eine Attributdefinition anlegen (name + type erforderlich; type ist number | string | date | state | period). DER TYPE IST DIE ENTSCHEIDUNG: Er wird von jeder Entität geteilt, die dieses Attribut trägt, sodass ein als `string` angelegtes Feld später nicht als Zahl summiert oder sortiert werden kann, ohne dass jeder vorhandene Wert umgeschrieben wird. Die Entscheidung anhand der tatsächlich vorhandenen Werte treffen, nicht anhand des ersten gesehenen. Eine Definition allein bewirkt nichts — sie mit attributeSetAttributes_create an eine Kategorie binden, sonst erscheint sie nirgends. Erfordert ROLE_ATTRIBUTES_MANAGER. Schreibend. |
Attributes_update
Tools
| attributes_update | Eine Attributdefinition aktualisieren — name, type, required, multiple, default oder format. Das Ändern von `type` bei einer Definition, die bereits Werte hat, ist riskant: Vorhandene Werte werden nicht konvertiert. Erfordert ROLE_ATTRIBUTES_MANAGER. Schreibend. |
Attribute Set Attributes_create
Tools
| attributeSetAttributes_create | Eine Attributdefinition an eine Kategorie binden (attributeSet + attribute, beide IRIs). DIES LÄSST EIN ATTRIBUT ERSCHEINEN: Ohne die Bindung kann ein Wert erfolgreich gegen eine Entität geschrieben werden und erscheint dennoch nie in der UI — ein Fehler ohne Symptom. Erfordert ROLE_ATTRIBUTES_MANAGER. Schreibend. |
Attribute Set Attributes_delete
Tools
| attributeSetAttributes_delete | Ein Attribut von einer Kategorie lösen. Die Definition und etwaige Werte bleiben erhalten; sie werden nur nicht mehr für diese Kategorie angezeigt, was wie ein Datenverlust wirkt, ohne einer zu sein. Erfordert ROLE_ATTRIBUTES_MANAGER. Schreibend. |
Attribute Entity Values_create
Tools
| attributeEntityValues_create | Einen Attributwert auf einer Entität setzen (attribute + value erforderlich). `relation` IST EINE IRI — "/properties/7", nicht das Wort "property": Das Backend löst sie auf und leitet den Relationsnamen aus der Ressourcenklasse ab, sodass die Übergabe eines bloßen Namens einen Fehler wirft. (`relationId` nimmt eine einfache id und funktioniert weiterhin, ist aber zugunsten der IRI veraltet.) Das Attribut muss bereits an die Kategorie dieser Entität GEBUNDEN sein, sonst wird der Wert gespeichert und nie angezeigt. Erfordert ROLE_ATTRIBUTES_MANAGER. Schreibend. |
Attribute Entity Values_update
Tools
| attributeEntityValues_update | Einen Attributwert an Ort und Stelle ändern, anhand seiner id. Dies verwenden statt einen zweiten Wert für dasselbe (entity, attribute)-Paar anzulegen — nichts erzwingt Eindeutigkeit, ein Duplikat wird also akzeptiert und die UI zeigt eines der beiden. Erfordert ROLE_ATTRIBUTES_MANAGER. Schreibend. |
Attribute Entity Values_delete
Tools
| attributeEntityValues_delete | Einen Attributwert von einer Entität entfernen. Die Definition und die Bindung bleiben erhalten; nur der Wert dieser Entität verschwindet. Erfordert ROLE_ATTRIBUTES_MANAGER. Schreibend. |
Departments_create
Tools
| departments_create | Eine Abteilung hinzufügen, damit Personen darunter abgelegt werden können. `name` ist erforderlich (bis zu 128 Zeichen) und über die gesamte Organisation EINDEUTIG; `code` ist optional (bis zu 64) und ist EBENFALLS eindeutig — die Kurzform, die eine Organisation bereits in ihren eigenen Tabellen verwendet (CEO, TECH, PROC). `manager` ist eine optionale employee-IRI aus people_list. ZUERST LISTEN UND MIT KOLLISIONEN RECHNEN: Da sowohl name als auch code eindeutig sind, SCHLÄGT das erneute Posten einer bereits existierenden Abteilung FEHL, statt idempotent zu sein; ein Import, der create-pro-Zeile annimmt, stockt daher beim ersten Auftreffen auf eine bereits vorhandene Abteilung — typischerweise ein Überbleibsel eines Testlaufs. Diese Zeile mit departments_update abgleichen, statt darum herum neu anzulegen. ES GIBT KEIN LÖSCHEN: Das Backend bietet kein Löschen für eine Abteilung, ein falscher name oder code wird also mit departments_update an Ort und Stelle korrigiert und nie entfernt. Erfordert ROLE_EMPLOYEES_MANAGER. Schreibend. |
Departments_update
Tools
| departments_update | Eine Abteilung umbenennen, ihr einen code geben oder ihren manager setzen. Dieses Tool macht einen Abteilungsimport überhaupt erst möglich, nicht nur bequemer: `name` und `code` sind beide eindeutig, sodass eine bereits vorhandene Abteilung — die einzelne "HR"-Zeile, die ein Proof-of-Concept meist hinterlässt — nicht erneut angelegt werden kann; die tatsächliche Liste wird erreicht, indem diese Zeile KORRIGIERT statt mit ihr kollidiert wird. Nur die gesendeten Felder ändern sich, sodass die alleinige Übergabe von `code` den name unverändert lässt. `id` ist die numerische id aus departments_list; `manager` ist eine employee-IRI aus people_list. ES GIBT KEIN LÖSCHEN, was dies zur gesamten Reparaturstrategie macht: Eine mit einem Tippfehler angelegte Abteilung wird hier korrigiert, und eine, die nicht existieren sollte, kann nur umbenannt, nicht entfernt werden. Erfordert ROLE_EMPLOYEES_MANAGER. Schreibend. |
Locations_create
Tools
| locations_create | Einen Standort anlegen (name erforderlich; optional officeOpenHour/officeCloseHour als Sekunden nach Mitternacht). Die echte Adresse verwenden statt eines Projekt- oder Investitionsnamens — das ist es, was jemand braucht, der vor dem Asset steht, und der Projektname wird bereits anderswo geführt. Erfordert ROLE_LOCATIONS_MANAGER. Schreibend. |
Locations_update
Tools
| locations_update | Einen Standort umbenennen oder seine Öffnungszeiten ändern. Erfordert ROLE_LOCATIONS_MANAGER. Schreibend. |
Clients_import
Tools
| clients_import | VIELE Kunden in einem Aufruf laden, mit `externalRef` als Schlüssel — das Tool, um eine Kunden- oder Käuferliste aus einem anderen System herüberzubringen, wo clients_create einen Roundtrip pro Person bedeuten würde. Zeilen werden gegen die Organisation abgeglichen: Eine unbekannte externalRef legt an, eine bekannte aktualisiert an Ort und Stelle, eine identische Zeile wird übersprungen, ein erneuter Lauf ändert also nichts. Die Referenz wird als `externalPaymentCustomerId` gespeichert, die einzige externe Referenzspalte, die ein Client hat, und `clients_list` filtert danach. Clients NICHT stattdessen nach Namen abgleichen — eine Käuferliste ist voller gemeinsamer Nachnamen und gemeinsamer Käufe. Jedes Ergebnis trägt `counterpartyId`, die contracts_import und contracts_create benötigen. Zwei Fallen, die das Schema nicht ausdrücken kann: eine `tin` wird ohne `tinCountry` ABGELEHNT, und eine Kontaktzeile braucht eine E-Mail, eine Telefonnummer allein kann also keine anlegen. Für einen echten Onboarding-Lauf ZUERST dryRun:true ÜBERGEBEN. Maximal 500 Zeilen. Erfordert ROLE_CLIENTS_MANAGER. Schreibend. |
Contracts_import
Tools
| contracts_import | VIELE Verträge in einem Aufruf laden, mit `name` als Schlüssel — der Vertragsnummer. Anders als ein Client oder ein Asset hat ein Vertrag KEINE externe Referenzspalte, der name IST also der Idempotenzschlüssel; ein Batch, der denselben Namen zweimal enthält, wird ALS GANZES ABGELEHNT statt einen Vertrag zweimal zu aktualisieren, weil eine doppelte Nummer bedeutet, dass die Quelle fehlerhaft ist. `counterpartyExternalRef` löst den Käufer über dieselbe Referenz auf, die clients_import erhalten hat, die beiden setzen sich also zusammen: erst die Clients, dann die Verträge importieren, ohne je eine numerische counterparty-id anzufassen — eine Referenz, die zu keinem Client passt, lässt diese Zeile scheitern, statt einen parteilosen Vertrag anzulegen. `direction` ist "out" (wir verkaufen) oder "in" (wir kaufen); die Spalte hat keine serverseitige Einschränkung, ein falsches Wort wird also gespeichert, und der Vertrag passt danach zu keinem Filter mehr. ZUERST dryRun:true ÜBERGEBEN. Maximal 500 Zeilen. Erfordert ROLE_CONTRACTS_MANAGER. Schreibend. |
Assets_import
Tools
| assets_import | VIELE Assets in einem Aufruf laden, mit `assetCode` als Schlüssel — das Tool, um ein Inventar aus einem anderen System herüberzubringen, wo assets_create einen Roundtrip pro Datensatz bedeuten würde. Zeilen werden gegen die Organisation abgeglichen: Ein unbekannter assetCode legt an, ein bekannter aktualisiert an Ort und Stelle, eine identische Zeile wird übersprungen, ein erneuter Lauf ändert also nichts, und ein halb fertiger Lauf lässt sich gefahrlos wiederholen. `parentAssetCode` verschachtelt eine Zeile unter einer anderen ANHAND IHRES CODES, aufgelöst gegen die Organisation und gegen frühere Zeilen desselben Batches; ein Parent, der sich nie auflösen lässt, lässt diese Zeile scheitern, statt sie still verwaist zu lassen. DREI FELDER MACHEN DEN DATENSATZ LESBAR statt eines bloßen Namens: `attributeSetName` ist die Kategorie, die die UI als Typ zasobu zeigt und wonach die Liste gruppiert, `locationName` ist, wo das Ding sich physisch befindet, und `attributes` ist eine {name: value}-Map für Fläche, Stockwerk, Preis und alles andere, was die Quelle trägt. Alle drei werden ANHAND DES NAMENS aufgelöst — die Kategorie, der Standort, die Attributdefinitionen und ihre Bindungen werden für einen gefunden oder angelegt, ein Aufrufer hat also nie mit einer dieser IRIs zu tun, und Namen werden ohne Berücksichtigung der Groß-/Kleinschreibung abgeglichen, sodass "Mieszkanie" und "mieszkanie " die Liste nicht in zwei Teile spalten können. `attributes` braucht eine Kategorie, an der es hängen kann,… |
Assets_create
Tools
| assets_create | Ein Asset anlegen (name + status + bookingType erforderlich; status = in-stock | damaged | sold, bookingType = minutes | days | single-days | permanently). bookingType ist auch dann erforderlich, wenn das Asset nie gebucht wird — "permanently" übergeben für etwas, das nicht verliehen wird, und bookingAllowed auf false lassen. Zwei Felder tragen die Struktur: `parent` verschachtelt ein Asset unter einem anderen (eine Einheit unter einem Gebäude, ein Monitor unter einem Schreibtisch), und `attributeSet` setzt die Kategorie, nach der die Assets-Liste gruppiert und in der auch benutzerdefinierte Attribute wie Fläche oder Stockwerk liegen. `assetCode` ist ein EINDEUTIGES systemübergreifendes Handle — damit die id halten, die dieses Asset im führenden System hat, aus dem es importiert wurde, sodass ein erneuter Import aktualisiert statt dupliziert. Erfordert ROLE_PROPERTIES_MANAGER. Schreibend. |
Assets_update
Tools
| assets_update | Ein Asset anhand der id aktualisieren — name, status, Kategorie, parent, assetCode, Seriennummer, Daten, location oder Buchungseinstellungen. So wechselt ein Asset von in-stock zu sold. Zu beachten: Das status-Vokabular ist in-stock | damaged | sold und hat KEINEN reservierten Zustand, ein Halten muss also anders modelliert werden. Erfordert ROLE_PROPERTIES_MANAGER. Schreibend. |
Asset Meters_update
Tools
| assetMeters_update | Einen Asset-Zähler aktualisieren — dessen label, Utility-Typ, Einheit oder aktiven Zustand. Damit lässt sich ein Zähler aus der Erfassung nehmen (z. B. eine Nebenkostenart, die jetzt direkt über die Rechnung abgerechnet wird), ohne dessen Ablesehistorie zu löschen. Erfordert ROLE_PROPERTIES_MANAGER. Schreibend. |
Asset Bookings_create
Tools
| assetBookings_create | Ein Asset einer Person oder einem Projekt zuweisen. `property` ist die Asset-IRI (/assets/{id}) und ist erforderlich. Den Inhaber auf EINE von drei Arten benennen: `relation` mit einer einzelnen IRI (/people/{id} für eine Person, /projects/{id} für ein Projekt), oder `relationName` (employee | project) plus `relationId`, oder das `employee`- / `project`-IRI-Feld direkt. Genau ein Inhaber muss sich auflösen lassen — keinen zu benennen wird mit "Employee or Project must be set." abgelehnt, beide zu benennen mit "Employee and Project cannot be set at the same time." ZWEI DINGE, DIE NICHT IM SCHEMA STEHEN UND ZU EINEM 422 FÜHREN: Das Asset muss bereits reservierbar sein (`bookingAllowed: true` — mit assets_update setzen), eine Geschäftsregel, die für JEDEN Aufrufer gilt, auch für einen Manager, abgelehnt mit "This asset is not reservable."; und der eigene `bookingType` des Assets (minutes | days | single-days | permanently) gibt `duration` / `endDate` erst einen Sinn — ein einer Person unbefristet zugewiesener Platz ist `permanently` mit einem `startDate` und ohne Ende. Gleichzeitige Buchungen auf einem Asset werden serverseitig serialisiert, eine Überschneidung wird also abgelehnt statt doppelt gebucht. Erfordert ROLE_PROPERTY_BOOKINGS_MANAGER, um im Namen einer anderen Person zu buchen. Schreibend. |
Asset Bookings_update
Tools
| assetBookings_update | Eine bestehende Asset-Buchung aktualisieren — deren Daten, duration, Abrechnungsbetrag/-währung oder verbrauchsabhängigen Anteil. `relationName` und `relationId` werden vom Payload verlangt; also den Inhaber senden, den die Buchung bereits hat, sofern sie nicht absichtlich verschoben wird. Um eine Zuweisung zu beenden, assetBookings_cancel verwenden, nicht ein in der Vergangenheit liegendes endDate. Erfordert ROLE_PROPERTY_BOOKINGS_MANAGER. Schreibend. |
Asset Bookings_cancel
Tools
| assetBookings_cancel | Ein Asset freigeben — so endet eine Zuweisung, das Nächste, was diese Ressource zu einem Löschen hat (es gibt keine Löschoperation). Nimmt die booking-id und einen `cancelReason` von 3–255 Zeichen entgegen; die Buchung bleibt erhalten und wird mit `cancelledAt` versehen, sodass die Historie erhalten bleibt, und das Asset wird für den nächsten Inhaber frei. Das ist der Aufruf, wenn ein Mitarbeiter ausscheidet: assetBookings_list, gefiltert nach `employee`, findet, was er hält, und dies gibt jede einzelne davon frei. Erfordert ROLE_PROPERTY_BOOKINGS_MANAGER. Schreibend. |
Work Times_log
Tools
| workTimes_log | Einen Arbeitszeiteintrag für den verbundenen Flowtly-Benutzer erfassen (date, durationMinutes, project, notes). DIE NOTIZ MUSS DIE THIN-DESCRIPTION-PRÜFUNG DES SERVERS BESTEHEN, auf die ein Batch-Backfill wiederholt trifft: Sie braucht ENTWEDER etwa 32 Zeichen (die genaue Untergrenze ist eine organisationsweite Einstellung, und eine Organisation kann sie auf 0 setzen, um die Prüfung abzuschalten) ODER eine "#"-Ticket-Referenz ODER einen http(s)-Link — eines von beiden genügt. "Flowtly – Scallier" wird abgelehnt; "Flowtly – Scallier #FLOW-123" nicht. Der 422 nennt den propertyPath `description`, den Namen, den der Server für das Feld verwendet, das dieses Tool `notes` nennt. Schreibend. |
Tasks_create
Tools
| tasks_create | Erstellt eine Projektaufgabe (title + project erforderlich; optional status, list, assignees, dueAt, priority). Schreibend. |
Tasks_update
Tools
| tasks_update | Eine Projektaufgabe anhand der id aktualisieren — status ändern (inkl. als erledigt markieren), assignees, dueAt, title usw., oder die Aufgabe in ein anderes Projekt VERSCHIEBEN, indem `project` übergeben wird (Re-Parenting; die Aufgabenliste wird geleert, sofern nicht auch eine `list` im Zielprojekt benannt wird, da eine Liste zu einem Projekt gehört). Schreibend. |
Task Comments_create
Tools
| taskComments_create | Fügt einer Projektaufgabe einen Kommentar hinzu (task-id + content). Schreibend. |
Suppliers_create
Tools
| suppliers_create | Erstellt einen neuen Lieferanten-/Auftragnehmerdatensatz (name, tinType, costGroup erforderlich). Schreibend. |
Suppliers_update
Tools
| suppliers_update | Aktualisiert die Angaben eines Lieferanten/Auftragnehmers (name, Steuernummer, Zahlungsbedingungen usw.) anhand der id. Schreibend. |
People_create
Tools
| people_create | Erstellt einen Personen-/Mitarbeiterdatensatz (firstname + lastname erforderlich; optional companyEmail, contactEmail, contactPhone). Schreibend. |
People_update
Tools
| people_update | Aktualisiert einen Personen-/Mitarbeiterdatensatz anhand der id (name, companyEmail, contactEmail, contactPhone usw.). Schreibend. |
People_delete
Tools
| people_delete | Löscht einen Mitarbeiter-/Personendatensatz anhand der id (z. B. um einen Platzhalter-/Dummy-Mitarbeiter zu entfernen). Erfordert ROLE_EMPLOYEES_MANAGER; das Backend führt einen Löschprozessor aus, der auch verknüpfte Datensätze löst. Hohe Auswirkung, unumkehrbar. Schreibend. |
Cost Groups_create
Tools
| costGroups_create | Erstellt eine Kostengruppe / Kostenstelle (name + type erforderlich). Schreibend. |
Cost Groups_update
Tools
| costGroups_update | Aktualisiert Name oder Typ einer Kostengruppe / Kostenstelle anhand der id. Schreibend. |
Tag Groups_create
Tools
| tagGroups_create | Legt eine Tag-Gruppe an (Name erforderlich), um zusammengehörige Tag-Definitionen zu ordnen. So erstellst du auch einen PROJEKTORDNER-Container: übergib allowedRelations: ["project"], und die Definitionen der Gruppe werden zu Ordnern in der Projektliste. Eine Gruppe mit leerem allowedRelations ist universell und wird NICHT als Ordner behandelt. Schreiben. |
Tag Definitions_create
Tools
| tagDefinitions_create | Legt eine Tag-Definition an (name, level, tagGroup erforderlich) innerhalb einer Tag-Gruppe. Enthält allowedRelations der Gruppe "project", IST jede Definition hier ein Projektordner — dies ist das Werkzeug, das einen anlegt. Schreiben. |
Clients_create
Tools
| clients_create | Erstellt einen neuen Kundendatensatz (name, country, currency, status, tinType erforderlich). Schreibend. |
Clients_update
Tools
| clients_update | Aktualisiert einen Kundendatensatz anhand der id. Schreibend. |
Client Contacts_create
Tools
| clientContacts_create | Erstellt eine Kontaktperson für einen Kunden (client, type, name, email erforderlich). Schreibend. |
Bank Accounts_create
Tools
| bankAccounts_create | Erstellt ein Bankkonto (type, name, currency, defaultImportFormat erforderlich). Schreibend. |
Bank Accounts_update
Tools
| bankAccounts_update | Aktualisiert ein Bankkonto anhand der id. Schreibend. |
Banks_create
Tools
| banks_create | Eine Bank anlegen — das Institut, zu dem ein Bankkonto gehört, nicht das Konto selbst (das ist bankAccounts_create). Schreibend. |
Banks_update
Tools
| banks_update | Eine Bank anhand der id aktualisieren. So wird eine Bank auch ausgeblendet und wieder eingeblendet: `hidden` auf true setzen, um sie aus den Auswahllisten zu nehmen, ohne sie zu löschen, auf false, um sie zurückzuholen. Es gibt kein separates Archiv-Tool, weil die API keine Archivaktion für eine Bank hat — das Flag ist der Mechanismus. Schreibend. |
Counterparty Bank Accounts_create
Tools
| counterpartyBankAccounts_create | Ordnet einem Geschäftspartner ein Bankkonto zu (counterparty + accountNumber). Schreibend. |
Contracts_create
Tools
| contracts_create | Erstellt einen Vertrag. Schreibend. |
Contracts_update
Tools
| contracts_update | Aktualisiert einen Vertrag anhand der id. Schreibend. |
Contracts_delete
Tools
| contracts_delete | Löscht einen Vertrag anhand der id. Schreibend. |
Tax Groups_create
Tools
| taxGroups_create | Erstellt eine Steuergruppe (name + type erforderlich). Schreibend. |
Tax Groups_update
Tools
| taxGroups_update | Aktualisiert Name oder Typ einer Steuergruppe anhand der id. Schreibend. |
Tax Rules_create
Tools
| taxRules_create | Erstellt eine Steuerregel. Schreibend. |
Tax Rules_update
Tools
| taxRules_update | Aktualisiert eine Steuerregel anhand der id. Schreibend. |
Configs_update
Tools
| configs_update | Aktualisiert einen Organisationskonfigurationswert anhand der id (type + name erforderlich; Berechtigungen werden vom Backend pro Konfigurationsschlüssel durchgesetzt). Schreibend. |
Organization Addresses_update
Tools
| organizationAddresses_update | Den SUBSCRIPTION-Adressdatensatz der Organisation aktualisieren (id erforderlich; nur die zu ändernden Felder senden). DIES IST DER DATENSATZ, AUS DEM DIE MAIL-FUSSZEILE RENDERT: Das {{organizationAddress}} der Fußzeile wird von hier als "street, postCode city" zusammengesetzt, NICHT aus den organization-billing-*-Konfigurationsschlüsseln, die Rechnungen und KSeF als Verkäuferadresse verwenden. Die beiden Speicher laufen auseinander, und dass die Fußzeile diesen liest, ist ein bekannter Fehler — wenn also eine Signatur eine Adresse zeigt, die der Kunde beschwört, korrigiert zu haben, hat er die Billing-Schlüssel korrigiert, und dies ist der Datensatz, der noch den alten Wert hält. `street` ist eine einzelne Freitextspalte, die auch die Hausnummer tragen muss: Der NIP/GUS-Lookup füllt nur den Straßennamen und verwirft still die Haus- und Wohnungsnummer, weshalb Adressen hier "ul. Example" ohne Nummer lauten. Das vollständige "ul. Example 8/12" schreiben, um es zu reparieren. ZUERST mit organizationAddresses_list LESEN und mit configs_get auf organization-billing-street vergleichen, bevor geschrieben wird, damit der eigene gepflegte Wert des Kunden kopiert wird, statt einen zu erfinden. Erfordert ROLE_BILLINGS_MANAGER. Schreibend. |
Permission Groups_create
Tools
| permissionGroups_create | Erstellt eine Berechtigungsgruppe (name erforderlich; roles = Liste der gewährten ROLE_*-Strings). Schreibend. |
Permission Groups_update
Tools
| permissionGroups_update | Aktualisiert Name, Beschreibung oder gewährte Rollen einer Berechtigungsgruppe anhand der id. Schreibend. |
People_invite
Tools
| people_invite | Einer bestehenden Person einen LOGIN geben: legt eine ausstehende Organisationseinladung an und mailt sie ihr, in der konfigurierten UI-Sprache der Organisation. Dies ist der Schritt, den people_create und people_setPermissionGroups NICHT übernehmen — eine Person mit Berechtigungsgruppen kann sich weiterhin nicht anmelden, bis sie eingeladen wurde und akzeptiert hat. Erfordert die E-Mail der Person; schlägt fehl, wenn sie bereits einen Login hat. Onboarding-Reihenfolge: people_create (Datensatz) -> people_invite (Login) -> people_setPermissionGroups (Rechte). Schreibend. |
People_set Permission Groups
Tools
| people_setPermissionGroups | Die GESAMTE Berechtigungsgruppen-Zuordnung einer Person per numerischer group-id setzen (ersetzen) (siehe permissionGroups_list — z. B. gewährt die Gruppe "Business Owner" ROLE_ADMIN): jede Gruppe übergeben, in der die Person am Ende stehen soll, und [] entfernt sie alle. Gewährt Zugriff; erstellt KEINEN Login und mailt die Person nicht — das ist people_invite. DIE FALLE: Jemandem seine ERSTE Gruppe zu geben, verschiebt ihn auf das berechnete Modell, bei dem Rollen aus Gruppen und personenbezogenen Overrides stammen, und eine ihm von Hand außerhalb dieses Modells gewährte Rolle verschwindet im selben Aufruf — ein einer Person übergebenes ROLE_ADMIN ist genau die Art, die dies entfernt. Es funktioniert auch umgekehrt: Das Entfernen der letzten Gruppe verschiebt die Person aus dem Modell heraus und lässt diese älteren Rollen wieder erscheinen. Die Listen overridesAdded/overridesRemoved sagen darüber nichts aus; sie beschreiben Overrides und bleiben leer, während sich der effektive Zugriff ändert. Die Antwort meldet daher den Unterschied zwischen den Rollen, die die Person vor diesem Aufruf hatte, und danach, als rolesLost und rolesGained — das ist das Paar, das nach Rückgabe des Aufrufs zu lesen ist. rolesLost null (nicht []) bedeutet, dass die vor dem Schreiben genommene Momentaufnahme nicht gelesen werden konnte und das Delta UNBEKANNT ist, mit dem Grund in roleDeltaUnavailable: die… |
People_set Role Overrides
Tools
| people_setRoleOverrides | Die Rollen setzen (ersetzen), die EINE Person zusätzlich zu — oder abgezogen von — ihren Berechtigungsgruppen erhält. Zuerst eine Gruppe verwenden (people_setPermissionGroups): Gruppen sind die vorgesehene Abstraktion und skalieren auf mehr als eine Person, einen Override also nur dort verwenden, wo eine einzelne Person sich tatsächlich von jeder Gruppe unterscheidet. ERSETZT beide Listen vollständig, also zuerst people_getPermissions lesen und jeden Override zurückgeben, der erhalten bleiben soll; das Weglassen einer Liste leert sie. Rollen sind ROLE_-Konstanten — permissionGroups_list zeigt die, die diese Organisation bereits verwendet. Eine Rolle, die sowohl in added als auch in removed steht, wird abgelehnt statt geraten. Gibt dieselbe aufgelöste Momentaufnahme wie people_getPermissions zurück, sodass sich das Ergebnis ohne einen zweiten Aufruf bestätigen lässt. Erstellt KEINEN Login — siehe people_invite. Erfordert ROLE_ROLES_MANAGER. Schreibend. |
Holiday Days Limits_create
Tools
| holidayDaysLimits_create | Einer Person ein Kontingent eines Urlaubstyps gewähren, wirksam ab einem Datum. `seconds`, NICHT Tage (#3763): ein 8-Stunden-Tag sind 28800, also sind 21 Tage 604800, und ein Überstundensaldo von 2h30 sind 9000 — eine Zahl, die keinen Platz hatte, solange dies in ganzen Tagen gespeichert wurde. `employee` und `holidayType` sind IRIs (people_list und holidayTypes_list liefern sie); `variant` ist der Vertragstyp, zu dem das Kontingent gehört (uop, b2b, uz, uod). Um einen bestehenden Saldo zu KORRIGIEREN, eine Zeile mit einem späteren dateFrom hinzufügen, statt die alte zu bearbeiten — die gültige Zeile ist die letzte, deren dateFrom bereits erreicht ist, sodass die Historie intakt bleibt und eine Korrektur eingetragen werden kann, bevor sie wirksam wird. (employee, holidayType, variant, dateFrom) ist eindeutig, ein erneutes Posten desselben Tages ersetzt also nichts und schlägt fehl. Erfordert ROLE_HOLIDAYS_MANAGER. Schreibend. |
Holiday Days Limits_update
Tools
| holidayDaysLimits_update | Eine falsch eingetragene Zeile korrigieren — einen Tippfehler im Betrag, die falsche variant. Beträge liegen in SEKUNDEN vor (#3763). So wird NICHT erfasst, dass sich ein Saldo im Zeitverlauf ÄNDERT: Dafür mit holidayDaysLimits_create eine neue Zeile mit einem späteren dateFrom anlegen, die bewahrt, was der vorherige Saldo war und wann. Das Bearbeiten an Ort und Stelle schreibt die Historie um und macht die alte Zahl unwiederbringlich. holidayDaysLimits_list findet die id. Erfordert ROLE_HOLIDAYS_MANAGER. Schreibend. |
Holiday Requests_cancel
Tools
| holidayRequests_cancel | Einen Urlaubsantrag stornieren — damit lässt sich ein Antrag bereinigen, auf den nie reagiert werden sollte, etwa eine von einem Testlauf, einem Test oder einer ausgeschiedenen Person hinterlassene Zeile. ZWEI DINGE, DIE ÜBERRASCHEN. (1) ES LÖSCHT DIE ZEILE NICHT: Das Backend setzt status auf `canceled`, statt die Zeile zu entfernen. ABER EIN STORNIERTER ANTRAG VERSCHWINDET AUS holidayRequests_list — auf Produktion verifiziert: Danach liefert ihn weder die ungefilterte Liste noch status=canceled zurück. Man kann also nicht zurücklesen, was storniert wurde, und es gibt kein Rückgängigmachen über den MCP; vor dem Aufruf der id sicher sein. (2) ES IST NICHT DASSELBE WIE ABLEHNEN. Ablehnen erfasst eine Entscheidung — es schreibt einen Genehmigungsprotokolleintrag mit dem eigenen Namen und MAILT DEM MITARBEITER, dass sein Urlaub abgelehnt wurde — während Stornieren nur HR benachrichtigt, und nur, wenn `notify-hr-managers-of-leave-activity` für die Organisation eingeschaltet ist. Für eine Zeile, die nie ein echter Antrag war, ist Stornieren die ehrlichere und leisere Variante. FUNKTIONIERT NUR BEI EINEM AUSSTEHENDEN (`requested`) ANTRAG, wenn man nicht dessen Inhaber ist: Ein genehmigter Antrag hat bereits einen Holiday-Eintrag erzeugt, den dies nicht entfernt, ein Stornieren würde also eine gebuchte Abwesenheit hinter einem Antrag mit dem Status `canceled` zurücklassen. Erfordert ROLE_HOLIDAYS_MANAGER für jemand… |
Holidays_create
Tools
| holidays_create | Urlaub erfassen, den eine Person tatsächlich nimmt — die gebuchte Abwesenheit selbst, nicht den Anspruch (holidayDaysLimits_create) und nicht einen ausstehenden Antrag (Urlaubsanträge, die noch genehmigt werden müssen). Was dies schreibt, ist bereits vereinbarte freie Zeit, sie erscheint also sofort in holidays_list und braucht keinen Genehmigungsschritt. `employee` ist eine IRI aus people_list; `type` ist eine id aus holidayTypes_list. `dateFrom`/`dateTo` einschließlich, und ein Aufruf deckt einen ganzen Zeitraum ab statt einer Zeile pro Tag. Zwei Dinge beißen: Ein Typ, dessen `descriptionRequired` true ist (zuerst holidayTypes_list lesen — `vacations` ist es üblicherweise), LEHNT ein Anlegen ohne `description` AB; und `pick-up-day` ist bereits geschuldete Zeit, verbraucht also NICHT das jährliche Kontingent wie `vacations` — einen für einen Samstagsfeiertag zurückgegebenen Tag als `vacations` zu erfassen, frisst still einen Tag des Anspruchs einer Person. holidays_list für dieselbe Person und dieselben Daten vor dem Anlegen prüfen: Dieser Endpunkt erfasst dieselbe Abwesenheit anstandslos zweimal. JEDES ANLEGEN MAILT DEM MITARBEITER, an seine eigene Firmenadresse, dass die Abwesenheit hinzugefügt wurde — das Laden eines Jahres bereits erlebter Historie landet also zeilenweise in seinem Posteingang, und für Mitarbeiter, die… |
Holidays_delete
Tools
| holidays_delete | Eine gebuchte Abwesenheit endgültig entfernen — die Zeile wird gelöscht, anders als holidayRequests_cancel, das nur den status eines Antrags umschaltet. Damit lassen sich Abwesenheiten bereinigen, die nie hätten zählen sollen: Demo- oder Testzeilen, die ein Testlauf hinterlassen hat, oder solche, die verwaist sind, weil ihr Mitarbeiter gelöscht wurde (people_delete löst Abwesenheiten nur ab, statt sie zu entfernen, sie überleben also mit leerem Mitarbeiternamen). DIES VERÄNDERT ECHTE ZAHLEN: Eine gebuchte Abwesenheit ist `payrollEligible` und verbraucht den Anspruch der Person, das Löschen ändert also ihren Urlaubssaldo — beabsichtigt beim Bereinigen von Testdaten, ein Datenverlust-Bug, wenn die Zeile echt war. Kein Rückgängigmachen, keine Benachrichtigung. Zuerst holidays_list lesen und sicherstellen, dass die Zeile keine echte Historie ist: eine Beschreibung in der Sprache der Organisation oder Daten, die zu einer tatsächlichen Abwesenheit passen, bedeuten das meist. Erfordert ROLE_HOLIDAYS_MANAGER. Schreibend. |
Holiday Types_create
Tools
| holidayTypes_create | Einen Urlaubstyp hinzufügen, den die Organisation noch nicht anbietet — ein Sabbatical, unbezahlte Kinderbetreuung, ein Schulungstag — damit Abwesenheiten mit holidays_create dagegen gebucht und ein Kontingent mit holidayDaysLimits_create gewährt werden kann. `name` (3–64 Zeichen) ist das, was Personen bei der Buchung auswählen; `color` und `icon` bestimmen die Darstellung im Kalender; `reducesWorkingTime` false markiert freie Zeit, die die erwarteten Stunden des Monats NICHT senkt; und `descriptionRequired` true lässt den Typ einen Grund verlangen, den holidays_create dann erzwingt — siehe dieses Tool dafür, was es ablehnt. `status` ist standardmäßig `active`, ein ohne weiteres Nachdenken angelegter Typ wird also sofort allen angeboten. ZUERST holidayTypes_list LESEN: Typen gelten organisationsweit, und ES GIBT KEIN LÖSCHEN — ein Duplikat oder ein falsch geschriebener Name kann nur mit holidayTypes_update wieder auf inactive gesetzt und damit ausgeblendet werden, wobei jede dagegen gebuchte Abwesenheit währenddessen erhalten bleibt. Erfordert ROLE_HOLIDAYS_MANAGER. Schreibend. |
Holiday Types_update
Tools
| holidayTypes_update | Einen Urlaubstyp ändern, und vor allem einen wieder EINSCHALTEN. `status` wechselt zwischen `active` und `inactive`, und ein inaktiver Typ wird von holidays_create abgelehnt — das Erfassen historischen Urlaubs gegen einen Typ, den die Organisation inzwischen stillgelegt hat, beginnt also hier, und das ist es, was einen Urlaubshistorien-Import freischaltet, statt jemanden in die App-UI zu schicken. DEAKTIVIEREN IST KEIN LÖSCHEN, und es gibt kein Löschen: Bereits gebuchte Abwesenheiten behalten einen inaktiven Typ und werden in holidays_list weiterhin damit gelesen, inactive bedeutet also nur "wird für neue Buchungen nicht angeboten". DIE DARAUS FOLGENDE FALLE: `vacations` reaktivieren, um die Abwesenheiten des letzten Jahres zu laden, vergessen, es wieder auf `inactive` zu setzen, und man hat nicht nur einen Import abgeschlossen — man hat geändert, was die Organisation heute anbietet, denn jeder Mitarbeiter, der Urlaub bucht, sieht diesen Typ nun wieder in der Liste. Es in derselben Sitzung zurücksetzen, in der importiert wurde. `descriptionRequired` reicht ebenfalls in holidays_create hinein, das eine Buchung ohne Beschreibung ablehnt, sobald es eingeschaltet ist; das Einschalten lässt bereits erfasste Abwesenheiten unangetastet. `id` ist die String-id aus holidayTypes_list (`vacations`, `not-paid`), und nur die gesendeten Felder ändern sich. Erfordert ROLE_HOLIDAYS_MANAGER. Schreibend. |
Projects_create
Tools
| projects_create | Erstellt ein Projekt (name + type erforderlich; type = fixed-price|time-and-material|non-billable|internal; optional dateFrom/dateTo, client, publicDescription, notes, priceNet). Schreibend. |
Projects_update
Tools
| projects_update | Aktualisiert ein Projekt anhand der id (name, type, Daten, Beschreibung usw.). Schreibend. |
Project Members_create
Tools
| projectMembers_create | Eine Person AUF ein Projekt setzen (employee- + project-IRIs erforderlich, z. B. "/people/204" und "/projects/243"; optional position = employee|tech-lead|account-manager|viewer, Standard employee). DIES IST DIE ZUGRIFFSKONTROLLE, kein Label: Eine Person, die kein Mitglied ist, sieht das Projekt überhaupt nicht — es fehlt in ihrer Projektliste, und sie kann keine Zeit dagegen buchen — dies ist also das Tool, um jemanden wiederherzustellen, der von einem Projekt ausgesperrt ist. POSITION IST NICHT KOSMETISCH: Ein Benutzer mit einer projektbezogenen Rolle sieht nur die Projekte, bei denen seine Mitgliedschafts-position dazu passt — ROLE_PROJECTS_LEAD passt zu tech-lead, ROLE_PROJECTS_VIEWER zu viewer — einem Projektleiter eine `employee`-Zeile zu geben, lässt ihn also genauso blind wie ganz ohne Zeile. Mitgliedschaft kaskadiert NICHT: Jemanden auf einen übergeordneten Ordner zu setzen, gibt ihm nichts auf den darunterliegenden Projekten, ein Ordnerbaum braucht also einen Aufruf pro Projekt. Der eindeutige Schlüssel ist (employee, project, position), Positionen stapeln sich also statt ersetzt zu werden — eine Person kann employee UND tech-lead auf demselben Projekt als zwei separate Zeilen halten, und tech-lead zu jemandem hinzuzufügen, der dort bereits employee ist, entfernt oder erweitert die employee-Zeile nicht (verwenden… |
Project Members_update
Tools
| projectMembers_update | Die position einer bestehenden Mitgliedschaft anhand der id ändern (employee|tech-lead|account-manager|viewer) — die id aus projectMembers_list oder dem projectMembers-Array bei projects_get holen. Damit lässt sich AN ORT UND STELLE befördern oder degradieren; projectMembers_create verwenden, um eine zweite, zusätzliche position neben der bereits gehaltenen hinzuzufügen. Das Ändern einer position kann für jemanden mit einer projektbezogenen Rolle die Sicht auf das Projekt ENTZIEHEN (ein von tech-lead zu employee degradiertes ROLE_PROJECTS_LEAD sieht es nicht mehr). Eine Mitgliedschaft kann nicht zu einer anderen Person oder einem anderen Projekt verschoben werden — dafür löschen und neu anlegen. Erfordert ROLE_PROJECTS_MANAGER. Schreibend. |
Project Members_delete
Tools
| projectMembers_delete | Eine Person anhand der membership-id VON einem Projekt nehmen — mit projectMembers_list oder im projectMembers-Array von projects_get finden. Dies ENTZIEHT DEN ZUGRIFF: Sobald die letzte Mitgliedschaftszeile dieser Person auf diesem Projekt verschwunden ist, verschwindet das Projekt aus ihrer Ansicht, und sie kann keine Zeit mehr dagegen buchen — genau so verschwindet ein Projekt für jemanden still und leise. Bereits erfasste Stunden werden NICHT gelöscht und bleiben auf dem Projekt; die Person kann sie nur nicht mehr sehen oder ergänzen. Das Löschen einer position lässt jede andere position, die dieselbe Person auf demselben Projekt hält, unangetastet. Erfordert ROLE_PROJECTS_MANAGER. Unumkehrbar (ein Neuanlegen erzeugt eine neue Zeile und benachrichtigt erneut), hohe Auswirkung. Schreibend. |
Project Templates_create
Tools
| projectTemplates_create | Eine wiederverwendbare Projektblaupause aus einem structure-Dokument anlegen (version, project, Phasen sowie deren Listen/Aufgaben). Offsets darin sind RELATIV — startOffsetDays und durationDays werden in Tagen ab dem beim Instanziieren angegebenen startDate gezählt, eine Vorlage bedient also jeden zukünftigen Start. Der project.name in der structure ist ein Platzhalter; beim Instanziieren pro Kunde überschreiben. Die structure wird serverseitig gegen das Schema ihrer deklarierten version validiert, und ein Verstoß benennt den betreffenden JSON-Pointer. Schreibend. |
Project Templates_update
Tools
| projectTemplates_update | Eine Projektvorlage anhand der id aktualisieren. Die structure-Spalte wird ALS GANZES gespeichert und ersetzt, nie zusammengeführt — das vollständige Dokument senden, sonst sind die weggelassenen Teile verloren. Zuerst die aktuelle mit projectTemplates_get lesen. Das Ändern einer Vorlage betrifft NICHT bereits daraus instanziierte Projekte; es gibt keine Rückpropagierung. Schreibend. |
Project Templates_delete
Tools
| projectTemplates_delete | Eine Projektvorlage anhand der id löschen. Soft Delete, und es betrifft NICHT bereits aus der Vorlage angelegte Projekte — diese sind gewöhnliche Projekte und bestehen fort. Schreibend. |
Project Templates_instantiate
Tools
| projectTemplates_instantiate | Ein echtes Projekt aus einer Vorlage aufbauen — das Projekt, seine Phasen, seine Aufgabenlisten und jede Aufgabe, in EINEM atomaren Aufruf. startDate ist erforderlich und ist der Anker, gegen den jedes startOffsetDays in der Vorlage aufgelöst wird. name übergeben, um den Platzhalter-Projektnamen der Vorlage zu überschreiben, und client, um das neue Projekt an einen Kunden anzuhängen: Zweimaliges Instanziieren gegen DENSELBEN Kunden ist der Weg, wie ein Kunde am Ende mehrere Aufträge hält, jeden als eigenes Projekt. Gibt das angelegte Projekt zurück. Schreibend. |
Projects_archive
Tools
| projects_archive | Archiviert ein Projekt anhand seiner id — der Weg, ein Projekt stillzulegen, das sich nicht löschen lässt, weil erfasste Zeiten, Rechnungen oder Budgets daran hängen. Umkehrbar mit projects_unarchive. Vorzuziehen gegenüber einem zurückdatierten dateTo, das ein Projekt nur abgeschlossen aussehen lässt. Schreiben. |
Projects_unarchive
Tools
| projects_unarchive | Stellt ein archiviertes Projekt anhand seiner id wieder her und macht projects_archive rückgängig. Schreiben. |
Responsibility Groups_create
Tools
| responsibilityGroups_create | Erstellt eine Verantwortungsgruppe / einen RACI-Bereich (name erforderlich; optional description und responsibleEmployee = die verantwortliche Person, angegeben als einfache employee-id wie 6 (aus people_list) oder die IRI /people/6). Dies ist das übergeordnete 'Odpowiedzialności'-Element. Einzelne Verantwortlichkeiten darunter über responsibilities_create hinzufügen. Schreibend. |
Responsibility Groups_update
Tools
| responsibilityGroups_update | Aktualisiert eine Zuständigkeitsgruppe anhand der id (name, description, responsibleEmployee = employee-id oder IRI). Schreibend. |
Responsibilities_create
Tools
| responsibilities_create | Erstellt eine Verantwortlichkeit innerhalb einer Gruppe (responsibilityGroup = group-id oder IRI, + name, erforderlich; optional description; optional parent = eine weitere responsibility-IRI zur Verschachtelung). Personen dafür über responsibilityEmployees_create zuweisen. Schreibend. |
Responsibilities_update
Tools
| responsibilities_update | Aktualisiert eine Zuständigkeit anhand der id (name, description, parent, responsibilityGroup = group-id oder IRI). Schreibend. |
Responsibility Employees_create
Tools
| responsibilityEmployees_create | Weist einer Zuständigkeit einen Mitarbeiter zu (responsibility = responsibility-id oder IRI, employee = employee-id oder IRI, percentage 0-100, alle erforderlich; optional targets und description). Schreibend. |
Responsibility Employees_update
Tools
| responsibilityEmployees_update | Aktualisiert eine Zuständigkeitszuweisung anhand der id (percentage, targets, description). Schreibend. |
Responsibility Employees_delete
Tools
| responsibilityEmployees_delete | Entfernt die Zuweisung eines Mitarbeiters zu einer Zuständigkeit anhand der id. Schreibend. |
Leads_create
Tools
| leads_create | Einen Lead anlegen (Outbound-/Inbound-Interessent; companyName, source, owner, verknüpfter client optional). Ein neuer Lead hat immer status=open — status ist hier nicht setzbar und bewegt sich nur über leads_convert, leads_lose und leads_reopen. Schreibend. |
Leads_update
Tools
| leads_update | Einen Lead anhand der id aktualisieren (company, website, source, owner, verknüpfter client, stage, doNotContact). NICHT status oder lostReason: Diese werden von der Entität abgelehnt und von diesem Endpunkt still ignoriert; das Schließen eines Leads braucht also leads_lose (mit einer lostReasonId), und das Rückgängigmachen braucht leads_reopen. Das Verschieben von `stage` bewegt sich durch den Funnel; es schließt den Lead nicht. Schreibend. |
Leads_delete
Tools
| leads_delete | Löscht einen Lead anhand der id (Soft-Delete). Schreibend. |
Leads_convert
Tools
| leads_convert | Konvertiert einen qualifizierten Lead in einen Client + einen Kontakt pro Lead-Kontakt + einen offenen Deal. Erfordert einen bestehenden Client (den client des Leads oder eine clientId im Body). Schreibend. |
Leads_lose
Tools
| leads_lose | Einen Lead als VERLOREN schließen — setzt status=lost und stempelt closedAt. ERFORDERT lostReasonId, die `id` eines leadLostReasons-Eintrags (zuerst leadLostReasons_list ausführen; es ist eine Auswahlliste, Freitext wird also mit 422 abgelehnt). Dies ist der EINZIGE Weg, einen Lead als verloren zu erfassen: leads_update ignoriert status, und doNotContact bedeutet "nie wieder kontaktieren", eine andere und deutlich stärkere Aussage als "diesen haben wir nicht gewonnen". Es verschiebt NICHT die stage des Leads — LeadStage hat kein terminales Flag, der Lead behält also seine Funnel-Position, und leads_reopen kann sie exakt wiederherstellen. Schreibend. |
Leads_reopen
Tools
| leads_reopen | leads_lose rückgängig machen — setzt status zurück auf open und leert closedAt und den lost reason. Die stage bleibt unangetastet, der Lead setzt also genau dort fort, wo er war. Hierauf zurückgreifen, wenn ein Lead gegen den falschen Datensatz geschlossen wurde oder der Interessent zurückgekehrt ist. Schreibend. |
Lead Activities_create
Tools
| leadActivities_create | Protokolliert EINE Kontaktaufnahme bei einem Lead — eine gesendete Einladung, eine akzeptierte Einladung, eine Nachricht, eine Antwort, ein Anruf, ein Follow-up (lead + type + occurredAt erforderlich; channel, contact, body optional). HIER gehört die Kontakthistorie eines Interessenten hin: Eine crmNote ist freier Kommentartext, eine Aktivität ist das strukturierte, filterbare Kontaktprotokoll, das die Timeline der Prospecting-Warteschlange darstellt. Kontakte NICHT in einer Notiz beschreiben. type: invite_sent | invite_accepted | message_sent | reply_received | call | meeting | follow_up | …; channel: linkedin | email | phone | …. Schreibend. |
Lead Activities_update
Tools
| leadActivities_update | Aktualisiert eine protokollierte Kontaktaktivität nach id (type, channel, occurredAt, body). Schreibend. |
Lead Activities_delete
Tools
| leadActivities_delete | Löscht eine protokollierte Kontaktaktivität nach id. Schreibend. |
Lead Contacts_create
Tools
| leadContacts_create | Fügt eine Kontaktperson zu einem Lead hinzu (lead + name erforderlich; email, phone, role, linkedinUrl, isPrimary optional). Die LinkedIn-URL eines Kontakts gehört in linkedinUrl, NICHT in eine crmNote. Schreibend. |
Lead Contacts_update
Tools
| leadContacts_update | Aktualisiert einen Lead-Kontakt nach id — z. B. linkedinUrl / email / phone setzen, sobald diese gefunden wurden. Schreibend. |
Lead Contacts_delete
Tools
| leadContacts_delete | Löscht einen Lead-Kontakt anhand der id. Schreibend. |
Deals_create
Tools
| deals_create | Einen Deal/eine Opportunity anlegen. Erforderlich: title, stage (aus stages_list) und ein ANKER — mindestens eines von client oder lead. Ein Deal mit keinem von beiden wird mit 422 "A deal must reference a client or a lead." abgelehnt; einen Interessenten, für den es keinen Kundendatensatz gibt, also an seinen lead (`/leads/<id>` aus leads_list) verankern, statt einen client zu erfinden; client (`/clients/<id>` aus clients_list) übergeben, sobald es einen gibt. Beide zu setzen ist erlaubt. Optional: amountMinor, currency, expectedCloseDate, owner, contact. Direktes Anlegen in einer gewonnenen stage erfordert zusätzlich client — ein Deal mit nur einem lead kann nicht gewonnen werden. Schreibend. |
Deals_update
Tools
| deals_update | Einen Deal anhand der id aktualisieren (title, stage, amountMinor, currency, expectedCloseDate, owner, contact, client, lead). Das Verschieben der stage wird automatisch protokolliert. Die Anker-Regel aus deals_create gilt weiterhin für das Ergebnis, der einzige client oder lead eines Deals kann also nicht geleert werden — zuerst einen anderen einsetzen. Das Verschieben eines Deals in eine gewonnene stage erfordert client: den Kunden hier anhängen (oder leads_convert ausführen), bevor ein Deal mit nur einem lead gewonnen wird. Schreibend. |
Deals_delete
Tools
| deals_delete | Löscht einen Deal anhand der id (Soft-Delete). Schreibend. |
Deals_win
Tools
| deals_win | Einen Deal als gewonnen markieren — verschiebt ihn in eine gewonnene stage und stempelt ihn als geschlossen; optionale contractId verknüpft einen bestehenden Vertrag. EINEN HISTORISCHEN GEWINN NACHTRAGEN: optionales closedAt (ISO-8601, z. B. "2026-05-07" oder ein vollständiger Zeitstempel) übergeben, um das Datum zu erfassen, an dem tatsächlich abgeschlossen wurde. Wird es weggelassen, stempelt der Server jetzt, was einen alten Deal in die "in diesem Monat gewonnen"-Zahl dieses Monats einordnet — es also immer setzen, wenn ein vor heute abgeschlossener Deal erfasst wird. Es darf nicht in der Zukunft liegen (422), und es DARF vor dem eigenen createdAt des Deals liegen: Ein heute angelegter und im Mai abgeschlossener Deal ist die normale Form eines korrekten Nachtrags, kein Fehler. Der Deal muss BEREITS einen client referenzieren: Das Gewinnen eines Deals mit nur einem lead wird mit 422 "Attach a customer before marking this deal Won." abgelehnt, weil es keinen Kunden zum Abrechnen gibt. Den lead mit leads_convert in einen umwandeln oder client mit deals_update setzen, dann gewinnen. Schreibend. |
Deals_lose
Tools
| deals_lose | Einen Deal als verloren markieren — erfordert lostReasonId (aus dealLostReasons_list); optional lostReasonNote. EINEN HISTORISCHEN VERLUST NACHTRAGEN: optionales closedAt (ISO-8601) übergeben, um das Datum zu erfassen, an dem tatsächlich abgeschlossen wurde, genau wie bei deals_win. Wird es weggelassen, stempelt der Server jetzt. Es darf nicht in der Zukunft liegen (422) und darf vor dem createdAt des Deals liegen. Schreibend. |
Deals_reopen
Tools
| deals_reopen | Öffnet einen gewonnenen/verlorenen Deal wieder. Schreibend. |
Lead Lists_create
Tools
| leadLists_create | Erstellt eine Outbound-Prospecting-Liste (name erforderlich). Schreibend. |
Lead Lists_update
Tools
| leadLists_update | Aktualisiert eine Outbound-Liste anhand der id. Schreibend. |
Lead Lists_delete
Tools
| leadLists_delete | Löscht eine Outbound-Liste anhand der id. Schreibend. |
Lead List Memberships_create
Tools
| leadListMemberships_create | Einen Lead zu einer Outbound-Liste hinzufügen (list + lead erforderlich; status optional). Jedes übergebene lastContactedAt ist eine Momentaufnahme, die danach nichts mehr aktualisiert — den Kontakt zusätzlich als Lead-Aktivität protokollieren, sonst bleibt er unabfragbar. Schreibend. |
Lead List Memberships_update
Tools
| leadListMemberships_update | Die Mitgliedschaft eines Leads in einer Liste aktualisieren — z. B. den Outreach-status setzen (contacted/replied/bounced). status und lastContactedAt werden vom Aufrufer gepflegt: Was geschrieben wird, bleibt stehen, bis jemand erneut schreibt, und das Erfassen von Lead-Aktivitäten aktualisiert sie NICHT. Schreibend. |
Lead List Memberships_delete
Tools
| leadListMemberships_delete | Entfernt einen Lead aus einer Outbound-Liste. Schreibend. |
Work Times_update
Tools
| workTimes_update | Einen erfassten Arbeitszeiteintrag anhand der id korrigieren — dessen date, minutes, project oder description. So wird ein falsch abgelegter Eintrag zwischen Projekten VERSCHOBEN: workTimes_log legt nur an, ohne dies wäre ein falsches Projekt oder ein Tippfehler in der Beschreibung also dauerhaft. Zuerst den Eintrag mit workTimes_get lesen. Dieselbe Thin-Description-Prüfung gilt wie bei workTimes_log: etwa 32 Zeichen — die Untergrenze ist eine organisationsweite Einstellung und kann 0 sein, was sie deaktiviert — ODER eine "#"-Ticket-Referenz ODER ein http(s)-Link, eines der drei genügt. Schreibend. |
Work Times_delete
Tools
| workTimes_delete | Einen erfassten Arbeitszeiteintrag anhand der id löschen. Für ein Duplikat oder einen Eintrag zu Arbeit, die nie stattgefunden hat — workTimes_update vorziehen, wenn der Eintrag echt, aber falsch ist, damit die Stunden im Datensatz bleiben, statt daraus zu verschwinden. Erfasste Stunden fließen in Projektfinanzen und Auslastung ein, ein Löschen verändert also still die für eine vergangene Periode gemeldeten Zahlen. Schreibend. |
Payment Schedule Lines_import
Tools
| paymentScheduleLines_import | Den gesamten Ratenplan eines Vertrags in einem Aufruf laden, statt eines Roundtrips pro Zeile. Gebaut für Bauträgerverträge, die in Baufortschrittsraten bezahlt werden — ein einzelner Verkauf sind sechs bis zwölf Raten, und ein Register davon sind Hunderte. Jede Zeile benennt ihren Vertrag ANHAND DES NAMENS (bei einem importierten Bauträgervertrag dessen Vertragsnummer), ein Fälligkeitsdatum und einen Betrag in KLEINSTEN EINHEITEN — Grosze, sodass 5 300,00 "530000" ist und "5300" still 53,00 bucht. Zeilen werden mit den dort bereits vorhandenen Zeilen anhand von Vertrag+Datum+Betrag+Notiz abgeglichen: eine unbekannte Zeile wird angelegt, eine identische übersprungen, ein erneuter Lauf desselben Batches ändert also nichts; PaymentScheduleLine hat keine externe Referenzspalte, dieser natürliche Schlüssel ist also der Abgleichsschlüssel. Eine Zeile, deren Vertragsname zu nichts oder zu MEHR als einem Vertrag passt, wird als fehlgeschlagen gemeldet statt an eine Vermutung angehängt — eine Rate am falschen Vertrag stellt gleich zwei Cashflows falsch dar. Für einen echten Ladevorgang zuerst dryRun:true übergeben. Maximal 1000 Zeilen. Schreibend. |
Payment Schedule Lines_create
Tools
| paymentScheduleLines_create | Eine Rate zum Zahlungsplan eines Vertrags hinzufügen — der Plan dessen, was voraussichtlich fakturiert oder bezahlt wird, und wann. Die Vertrags-IRI, ein Datum und einen Betrag übergeben. Damit wird das Problem des fehlenden Zahlungsplans behoben, das contracts_get bei einem nicht-zyklischen Vertrag meldet: Auch eine einmalige Gebühr hat einen Zahlungsplan, es ist einfach eine einzelne Zeile über den Gesamtbetrag am Fälligkeitstag. Bei zyklischen Verträgen wird nicht darauf geprüft, weil das System keine Zeilen aus einer Wiederholung automatisch erzeugt. DER BETRAG LIEGT IN KLEINSTEN EINHEITEN VOR — Grosze, nicht Złoty: 5 300,00 ist "530000", und "5300" bucht still eine Zeile über 53,00. Die API gibt sie auf dieselbe Weise zurück; bei Unsicherheit über die Größenordnung also eine mit contracts_paymentScheduleLines zurücklesen. Das Ergebnis mit contracts_paymentScheduleLines zurücklesen. Schreibend. |
Payment Schedule Lines_update
Tools
| paymentScheduleLines_update | Eine Zahlungsplanzeile anhand der id ändern — deren date, amount oder note. Verwenden, wenn sich eine Rate verschiebt oder neu verhandelt wird, statt zu löschen und neu anzulegen, damit die Zeile eine bereits zugeordnete Rechnung behält. DER BETRAG LIEGT IN KLEINSTEN EINHEITEN VOR — Grosze, nicht Złoty: 5 300,00 ist "530000", und "5300" bucht still eine Zeile über 53,00. Die API gibt sie auf dieselbe Weise zurück; bei Unsicherheit über die Größenordnung also eine mit contracts_paymentScheduleLines zurücklesen. Schreibend. |
Payment Schedule Lines_delete
Tools
| paymentScheduleLines_delete | Eine Zahlungsplanzeile anhand der id entfernen. Löscht den PLAN, nicht das Geld: Eine bereits der Zeile zugeordnete Rechnung oder Transaktion bleibt unberührt, wird aber nicht mehr gegen irgendetwas abgeglichen. Für eine verschobene Rate paymentScheduleLines_update vorziehen. Schreibend. |
CRM Notes_create
Tools
| crmNotes_create | Fügt einem Lead oder Deal eine Notiz hinzu (body + genau eines von lead/deal). Autor ist der verbundene Benutzer. Schreibend. |
CRM Notes_update
Tools
| crmNotes_update | Aktualisiert den Text einer CRM-Notiz anhand der id. Schreibend. |
CRM Notes_delete
Tools
| crmNotes_delete | Löscht eine CRM-Notiz anhand der id. Schreibend. |
Organization Logo_upload
Tools
| organizationLogo_upload | Lädt das Logo der Organisation hoch bzw. ersetzt es (Base64-Bild + contentType + filename). Das aktuelle Logo über configs_get organization-logo-url lesen. Schreibend. |
Organization Icon_upload
Tools
| organizationIcon_upload | Lädt das Icon/Favicon der Organisation hoch bzw. ersetzt es (Base64-Bild + contentType + filename). Das aktuelle Icon über configs_get organization-icon-url lesen. Schreibend. |
Storage_upload
Tools
| storage_upload | Eine Datei an jeden Datensatz anhängen, den der generische Storage von Flowtly akzeptiert — ein ASSET (relationName "property"), ein Projekt, eine Aufgabe, ein Client, ein Standort, ein Auftragnehmer, eine Rechnung, ein HR-Datensatz. Dies ist der einzige Weg zu einem Asset-BILD: Ein Upload mit relationName "property" setzt das Bild, das die App für dieses Asset zeigt (ausgeliefert als `file` in der Asset-Payload). Property hat keine Bild-Spalte -- das Bild wird beim Lesen aus dieser Tabelle abgeleitet, weshalb nichts an der Entität andeutet, dass es existiert. Es ist EIN Slot, und der neueste Upload gewinnt, ein zweites Bild ersetzt also das erste, statt einer Galerie hinzugefügt zu werden; beide Zeilen bleiben unter /assets/{id}/documents gelistet. Dasselbe gilt für location, invoices und transaction-attachments; clients, agreements und candidates sammeln stattdessen jeden Upload unter `files`; der Rest erscheint nur über die eigene /documents-Route. `file` wird aus LIST-Antworten weggelassen, sofern die Anfrage nicht ?include=file übergibt; also einen Datensatz zurücklesen, um zu bestätigen, dass das Bild angekommen ist. relationName + relationId übergeben (die id aus dem list-Tool dieses Datensatzes; eine /assets/7-IRI wird akzeptiert und reduziert) plus die Bytes als base64 mit contentType und filename. GRÖSSENLIMIT: Die Bytes reisen als base64 innerhalb… |
Storage_create Upload Ticket
Tools
| storage_createUploadTicket | Ein kurzlebiges Einweg-Ticket erzeugen, um eine GROSSE Datei an einen Datensatz anzuhängen — so gelangen Asset-BILDER tatsächlich hinein, da ein Bild stets über der base64-Obergrenze liegt. Bei property/location/invoices/transaction-attachments wird der neueste Upload zum sichtbaren Bild des Datensatzes und ersetzt das vorherige; bei clients/agreements/candidates sammeln sich Uploads an. Dies statt storage_upload verwenden, wann immer die Datei mehr als ein paar Dutzend KB umfasst: Jenes Tool trägt die Bytes als base64, die ein Aufrufer als Text ausgeben muss, und ein 400-KB-JPEG wird zu ~533 K base64-Zeichen, weit mehr, als in eine Antwort passt. relationName + relationId plus einen filename übergeben; man erhält eine uploadUrl und ein sofort ausführbares curl zurück. Dann die ROHEN BYTES der Datei an diese URL senden (curl --data-binary @photo.jpg) — nicht base64, nicht multipart — und die Antwort trägt den angelegten Storage-Datensatz. Das Ticket läuft nach 15 Minuten ab, funktioniert einmal und kann nur gegen den einen benannten Datensatz ablegen. Schreibend. |
Contract Attachments_create
Tools
| contractAttachments_create | Ein Dokument an einen Vertrag anhängen — normalerweise das unterzeichnete PDF oder einen Anhang (DPA, SLA, Preisanhang), der daneben abgelegt wird. Die Bytes als base64 mit einem fileName und der contract-id aus contracts_list übergeben; `contractId` ist hier eine NACKTE id, anders als die IRIs, die contracts_update für counterparty und project erwartet, wobei eine vollständige /contracts/<id>-IRI akzeptiert und reduziert wird. GRÖSSENLIMIT: Die Bytes reisen als base64 innerhalb dieses Aufrufs, das gesamte Dokument muss also in eine Modellantwort passen — unter etwa 150 KB bleiben, und für alles Größere stattdessen contractAttachments_createUploadTicket verwenden, das genau dafür gebaut ist und keine solche Obergrenze hat. Ein unterzeichneter Vertrag mit Unterschriftenkarte liegt meist deutlich darüber (673.617 Bytes werden zu 898.156 base64-Zeichen, mehrfach so viel, wie eine Antwort tragen kann), und es kommt kein Fehler zurück, wenn es nicht passt, weil der Aufruf gar nicht erst abgesetzt werden kann — die Anfrage erreicht den Server nie, die Dateigröße also VOR dem Beginn prüfen, statt es durch Scheitern zu entdecken. Damit wird das Problem des fehlenden Dokuments behoben, das contracts_get meldet, ein über die API gepflegter Vertrag verschwindet also aus der Aufräum-Warteschlange der App. Ein unterzeichnetes Dokument kann… |
Contract Attachments_create Upload Ticket
Tools
| contractAttachments_createUploadTicket | Ein kurzlebiges Einweg-Ticket erzeugen, um ein GROSSES Dokument an einen Vertrag anzuhängen — das unterzeichnete PDF oder einen Anhang. Dies statt contractAttachments_create verwenden, wann immer die Datei mehr als ein paar Dutzend KB umfasst: Jenes Tool trägt die Bytes als base64, die ein Aufrufer als Text ausgeben muss, und ein echter unterzeichneter Vertrag (~700 KB, ~900 K base64-Zeichen) liegt weit über dem, was in eine Antwort passt. Die contract-id aus contracts_list plus einen fileName übergeben; man erhält eine uploadUrl und ein sofort ausführbares curl zurück. Dann die ROHEN BYTES der Datei an diese URL senden (curl --data-binary @file.pdf) — nicht base64, nicht multipart — und die Antwort ist der angelegte Anhang. Das Ticket läuft nach 15 Minuten ab, funktioniert einmal und kann nur an den einen benannten Vertrag anhängen. Damit wird das Problem des fehlenden Dokuments behoben, das contracts_get meldet. Schreibend. |
Incoming Invoices_create
Tools
| incomingInvoices_create | Legt eine Eingangsrechnung (Lieferant) oder ein Belegdokument in der Buchhaltung ab — die Bytes als Base64 mit fileName und receivedAt übergeben. Flowtly führt eine OCR durch und schlägt einen Lieferanten sowie eine passende Banktransaktion vor. Die Datei wird als externalId 'upload_sha256:<sha256 der Bytes>' fingerprintet: Um ein Duplikat zu vermeiden, die Bytes hashen und VOR dem Upload incomingInvoices_list auf diese externalId prüfen. Schreibend. |
Invoices_export
Tools
| invoices_export | Startet einen ZIP-Export AUSGESTELLTER Rechnungen für einen Zeitraum (from/to, beide YYYY-MM-DD, einschließlich), gefiltert nach VERKAUFSDATUM — nicht Ausstellungs- oder Erstellungsdatum. Es werden nur AUSGESTELLTE Rechnungen eingeschlossen; Entwürfe und nicht versendete Rechnungen sind ausgeschlossen, Korrekturen SIND jedoch eingeschlossen. Optionales client schränkt auf einen Kunden ein (id oder IRI aus clients_list). Max. 200 Rechnungen pro Export — hat der Zeitraum mehr, ihn eingrenzen (z. B. jeweils einen Monat exportieren); ein Zeitraum mit 0 ausgestellten Rechnungen wird ebenfalls abgelehnt. Dieser Aufruf reiht den Job nur ein (das Rendern eines Monats kann Minuten dauern) — er liefert KEINEN Download-Link. invoices_exportStatus mit der zurückgegebenen exportId abfragen, bis "ready" gemeldet wird. Schreibend. |
Invoices_export Status
Tools
| invoices_exportStatus | Fragt den Status eines von invoices_export gestarteten ZIP-Exports nach exportId ab. Sobald status "ready" ist, enthält die Antwort downloadUrl (ein kurzlebiger signierter Link — läuft nach 1 Stunde ab, siehe expiresAt), filename und byteSize; die Bytes der Datei werden über dieses Tool niemals zurückgegeben. Bei status "failed" erklärt failureReason den Grund. |
Invoices_import
Tools
| invoices_import | Eine BEREITS AUSGESTELLTE ausgehende (Verkaufs-)Rechnung in die Organisation einbringen — um Rechnungshistorie beim Onboarding einzubringen. Die übergebene externe Rechnungsnummer wird wörtlich beibehalten, der Käufer wird per Steuer-id aufgelöst (bei Fehlen angelegt), und die Rechnung landet als ausgestellt, OHNE ein PDF zu rendern, den Client zu mailen oder an KSeF zu übermitteln. Der Import einer bereits existierenden Nummer ist ein No-Op, das die bestehende Rechnung meldet, ein Massenimport lässt sich also gefahrlos erneut ausführen — diese Garantie gilt jedoch nur für sequentielle Aufrufe; zwei tatsächlich gleichzeitige Importe derselben Nummer können beide landen. expectedGrossTotal übergeben (der auf dem Quelldokument gedruckte Bruttobetrag), und der Import wird abgelehnt, wenn er von der aus den Zeilen berechneten Summe abweicht. buyer.tin ist erforderlich — der Käufer wird nie über den Namen abgeglichen. invoices_create, nicht dieses Tool, verwenden, um eine echte neue Rechnung auszustellen. Schreibend. dryRun:true übergeben, um eine VORSCHAU ohne Schreiben zu erhalten — meldet would-create / would-skip und legt keine Rechnung und keinen Client an; einen historischen Nachtrag zuerst trocken laufen lassen und die Zählungen prüfen, bevor er real ausgeführt wird. |
Invoice Transactions_create
Tools
| invoiceTransactions_create | Erfasst eine Zahlung zu einer Ausgangsrechnung (Verkauf). `invoice` ist eine invoice-IRI aus invoices_list; `date` ist der Zeitpunkt, zu dem die Zahlung als erfolgt gilt. `transaction` ist optional — weglassen, um eine Ausgleichung ohne Bankposition zu erfassen, was bei historischen Rechnungen erwünscht ist, deren Kontoauszug nie importiert wurde. `amount` ist optional und entspricht standardmäßig dem offenen Betrag der Rechnung. Das Erfassen einer Zahlung sorgt dafür, dass eine ausgestellte, überfällige Rechnung nicht mehr als unbezahlt behandelt wird, und stoppt damit auch das Einreihen von Zahlungserinnerungen dafür. Nichts verhindert das Erfassen zweier Zahlungen zu einer Rechnung — bei Unsicherheit, ob bereits ausgeglichen wurde, zuerst invoices_get lesen. Schreibend. |
Invoice Transactions_update
Tools
| invoiceTransactions_update | Aktualisiert einen bestehenden Rechnungszahlungs-Datensatz nach id (aus den invoiceTransactions von invoices_get, oder durch Paginieren von invoiceTransactions). Häufigste Verwendung: eine ohne Bankposition erfasste Zahlung mit einer gerade über transactions_importStatement importierten Transaktion verknüpfen, indem `transaction` auf eine transaction-IRI/id aus transactions_list gesetzt wird. DIE FALLE: Dies ist ein PATCH, das Backend verlangt bei jedem Aufruf dennoch `invoice` und `date` — es führt bestehende Werte NICHT automatisch zusammen. Zuerst den Datensatz lesen (oder ihn bereits aus dem Erstellungsaufruf vorliegen haben) und dessen `invoice` und `date` unverändert erneut senden, zusammen mit dem, was tatsächlich geändert werden soll, sonst wird die Aktualisierung abgelehnt. `transaction` akzeptiert null, um eine Zahlung von einer Bankposition zu lösen. `amount` ist optional. Schreibend. |
Invoice Transactions_delete
Tools
| invoiceTransactions_delete | Löscht einen Zahlungseintrag einer Rechnung anhand seiner id — die ids liest du aus invoiceTransactions von invoices_get. Entfernt den EINTRAG, DASS EINE RECHNUNG BEZAHLT WURDE, nicht eine Banktransaktion: dann einzusetzen, wenn eine Rechnung eine Zahlung trägt, die es nie hätte geben dürfen, üblicherweise dieselbe Zahlung doppelt gebucht — einmal von Hand und einmal durch den Kontoauszugsimport, der sie später zugeordnet hat. Prüfe zuerst invoices_get und lösche den Eintrag, dessen `transaction` die falsche ist (behalte den, der auf die echte importierte Bankzeile zeigt); wird die letzte verbleibende Zahlung gelöscht, gilt die Rechnung wieder als offen, was die Zahlungserinnerungen dafür erneut scharf stellt. Erfordert ROLE_INVOICES_MANAGER. Unumkehrbar, weitreichend. Schreiben. |
Invoices_create
Tools
| invoices_create | Eine NEUE ausgehende (Verkaufs-)Rechnung ausstellen — das Tool, um einen Client zum ersten Mal zu fakturieren. Nicht mit seinen beiden Nachbarn verwechseln: invoices_import trägt eine BEREITS anderswo ausgestellte Rechnung nach (Onboarding-Historie), und incomingInvoices_create erfasst das Kostendokument eines Lieferanten. Die Rechnung landet UNVERSENDET: status wird aus den Log-Zeilen der Rechnung abgeleitet, und eine frische Rechnung hat keine, dieser Aufruf rendert also nichts, mailt nichts und übermittelt nichts an KSeF — das Ergebnis als Entwurf zur Prüfung vor dem Ausstellen behandeln. `name` ist die Rechnungsnummer und frei wählbar (max. 32 Zeichen) — zuerst invoices_list lesen und der bestehenden Serie der Organisation folgen, statt eine zu erfinden, denn nichts hier weist automatisch die nächste Nummer zu. Erforderlich: name, type ("invoice"), tinType, issueDate, saleDate, dueDate. `client` (IRI aus clients_list) übergeben und, für eine später abgeglichene Buchung, `contract` (IRI aus contracts_list), damit die Rechnung unter diesem Vertrag erscheint. Positionen kommen in `invoiceRows` — Netto-Einzelpreis, Menge und ein Steuersatz pro Zeile; die Summen werden aus den Zeilen berechnet, nicht übergeben. `bankAccount` (aus bankAccounts_list) wählt das auf dem Dokument gedruckte Konto, und `currency`… |
Invoices_update
Tools
| invoices_update | Eine ausgehende (Verkaufs-)Rechnung anhand der id korrigieren, vor oder nach dem Ausstellen. Die alltägliche Verwendung ist das Korrigieren eines mit invoices_create erstellten Entwurfs — ein falsches Datum, eine falsche Zeile, ein fehlender Vertragslink — statt ihn zu löschen und neu auszustellen, was eine Rechnungsnummer verbrennen würde. Zuerst invoices_get lesen: Dies ist ein PATCH über ein Dokument, dessen Summen aus seinen Zeilen abgeleitet werden, das Ersetzen von `invoiceRows` ersetzt also die gesamte Menge, und eine bereits versendete Rechnung wird sich durch die Bearbeitung nicht selbst zurückziehen. Schreibend. |
Incoming Invoices_apply Suggestion
Tools
| incomingInvoices_applySuggestion | Übernimmt einen von Flowtlys eigenen Vorschlägen zu einer Eingangsrechnung — dieselben Vorschläge, die ein Mensch in der App sieht (Lieferantenabgleich, Kostengruppe, passende Banktransaktion, Duplikatswarnung). Zuerst mit incomingInvoices_suggestions lesen, dann einen davon per id anwenden. Dies dem Raten vorziehen: Flowtlys Matcher entscheidet, was plausibel ist, nicht der Agent. Schreibend. |
Incoming Invoices_accept All Suggestions
Tools
| incomingInvoices_acceptAllSuggestions | Übernimmt in einem Aufruf jeden ausstehenden Vorschlag zu einer Eingangsrechnung — das, was ein Mensch mit dem "Alle übernehmen"-Button der App tut. Der Server wendet an, baut neu auf und wendet erneut an, bis nichts Neues mehr erscheint: Der Transaktionsabgleich existiert erst, wenn Lieferant und Betrag angewendet sind, ein einziger Durchlauf würde das Dokument also unverknüpft lassen. Liefert einen Bericht zurück (was angewendet wurde, was abgelehnt wurde und warum, sowie die Transaktion, gegen die am Ende verbucht wurde). Übergeben Sie dryRun, um ohne Schreibvorgang eine Vorschau zu erhalten. Übernimmt niemals supplier_create oder eine Duplikatswarnung. Schreibend. |
Incoming Invoices_check EInvoices
Tools
| incomingInvoices_checkEInvoices | Holt neue KSeF-E-Rechnungen in die Organisation — das, was der Button "Sprawdź e-faktury" in der App tut. Dies aufrufen, bevor der Schluss gezogen wird, dass die Rechnung eines Lieferanten fehlt: Ohne diesen Aufruf lässt sich "der Lieferant hat sie nie gesendet" nicht von "unsere Synchronisierung ist noch nicht gelaufen" unterscheiden. Kehrt zurück, sobald der Abruf eingereiht ist; anschließend incomingInvoices_list erneut lesen, um zu sehen, was eingetroffen ist. Schreibend. |
Resourcing_import Timeline
Tools
| resourcing_importTimeline | Importiert ein Resourcing-Allokations-Zeitplanblatt (über den Drive-MCP abrufen, dessen CSV unverändert übergeben). Dies ist ein VOLLSTÄNDIGER ERSATZ-Abgleich der Allocation-Zeilen der Organisation für `year`: Zeilen im Sheet werden erstellt/aktualisiert, und jede bestehende Zeile dieses Jahres, die im Sheet fehlt, wird GELÖSCHT — kein Merge. STANDARDMÄSSIG DRY-RUN: Ein weggelassenes dryRun zeigt nur eine Vorschau und schreibt nichts; dryRun:false übergeben, um anzuwenden. Der Bericht liefert `created` / `replaced` sowie `unmatchedPeople` / `unmatchedProjects`. ZWEI DINGE WERDEN LEICHT ÜBERSEHEN: Eine Sheet-Zeile, deren Projekt sich nicht auflösen lässt, wird ÜBERSPRUNGEN, während der Aufruf dennoch Erfolg meldet — ein grünes Ergebnis kann also einen teilweisen Import verbergen; und ein Rollencode, den der Positionskatalog noch nicht enthält, wird als NEUE Position ANGELEGT statt abgelehnt — siehe `createdPositions`. Beides wird, wenn es auftritt, in `warnings` genannt; dies dem Benutzer mitteilen, statt nur `created` zu melden. Ein Sheet, das zu null Zeilen geparst wird, wird abgelehnt (es sieht genau wie ein fehlerhaftes Lesen aus, das den gesamten Zeitplan löschen würde), es sei denn, force:true wird übergeben. Anschließend allocations_list lesen, um zu sehen, was angekommen ist. Große Auswirkung. Schreibend. |
Transactions_import Statement
Tools
| transactions_importStatement | Importiert eine Kontoauszugsdatei (z. B. eine MT940-.sta-Datei) — den Rohtextinhalt jeder Datei unverändert (NICHT Base64) mit einem filename übergeben. ES GIBT KEINEN bankAccount-PARAMETER: Das Backend leitet eine Datei, indem es alle Nicht-Ziffernzeichen aus den Nummern Ihrer Bankkonten sowie aus den Bytes der Datei entfernt und in jedes Konto importiert, dessen Ziffern irgendwo in der Datei vorkommen — eine Datei kann also in mehreren Konten landen, und ein Auszug für ein Konto, das in Flowtly nicht angelegt ist (oder dessen Nummer anders erfasst ist, als die Bank sie schreibt), wird in keines davon importiert und schlägt mit einer Fehlermeldung fehl, die genau erklärt, warum — diese Meldung lesen, sie ist die einzige Diagnose, die dieser Endpunkt liefert. Bei Erfolg lautet die Antwort `{ imported, matching }`: `matching: "in_progress"` bedeutet, dass der Auftragnehmer-/Anhang-Abgleich für die neuen Zeilen nach Rückkehr dieses Aufrufs noch läuft, sodass ein sofortiges transactions_list Zeilen zeigen kann, die noch nicht abgeglichen sind — etwas später erneut lesen für den endgültigen Zustand. Das erneute Importieren desselben Auszugs erzeugt keine doppelten Zeilen; der Importer erkennt bereits gesehene Transaktionen. Sobald ein Auszug vorliegt, eine bestehende Zahlung ohne Bankposition mit einer ihrer Zeilen verknüpfen mit… |
Transactions_delete
Tools
| transactions_delete | Löscht eine Banktransaktion anhand ihrer id — finde sie mit transactions_list. Greife NUR dann dazu, um einen Buchungsfehler rückgängig zu machen, der sich anders nicht korrigieren lässt: ein Kontoauszug, der auf das falsche Bankkonto importiert wurde, oder von Hand erfasste Zeilen, die vor dem echten Auszug angelegt wurden und nun durch ihn doppelt vorliegen. Eine Transaktion ist die Aufzeichnung dessen, was die Bank getan hat; sie auf einem importierten Konto zu löschen bringt das Hauptbuch mit der Bank in Widerspruch. Das Backend erlaubt es nur für ROLE_ADMIN (ein Transaktionsmanager darf ausschließlich auf Bar- und manuellen Konten löschen). BEVOR du ein vermutetes Duplikat löschst, beweise das Paar: gleiche die importierte Zeile über Betrag UND Rechnungsnummer UND Geschäftspartner ab, nicht über den Betrag allein — eine Zahlung, die nach dem Enddatum des Auszugs eingegangen ist, hat kein Gegenstück, und sie zu löschen vernichtet den einzigen Nachweis dieses Ertrags. Das Backend LÖST, was daran hängt, statt es zu löschen: Rechnungszahlungen bleiben mit geleerter Bankzeile bestehen (setze sie mit invoiceTransactions_update neu), Anhänge und Immobilien werden entkoppelt, während Projekt- und Mitarbeitertransaktionszeilen mit ihr entfernt werden. Unumkehrbar, weitreichend. Schreiben. |
Organization_whoami
Tools
| organization_whoami | Gibt die Organisation zurück, an die diese MCP-Verbindung gebunden ist — { orgId, name, slug, userId }. Vor jedem create/update aufrufen, um zu bestätigen, IN WELCHEN Mandanten geschrieben wird: Die Verbindung ist per Token an genau eine Organisation gebunden, und das Schreiben von Interessenten/Datensätzen in die falsche Organisation ist ein realer Vorfall. Nur lesend. |
Resourcing Actuals_get
Tools
| resourcingActuals_get | Gemeldete Stunden im Vergleich zum Plan, pro Person und Woche, über ein from/to-Fenster — die Frage 'liegt das Team tatsächlich im Plan?', die KEIN anderes Resourcing-Tool beantwortet: Zuweisungen zeigen, was GEPLANT war, dies zeigt, was GELEISTET wurde. Liefert Wochenspalten plus eine Zeile pro Person (geplanter %, gemeldeter %, Abweichung, Summen und eine Aufschlüsselung pro Projekt). reportedPercent = null bedeutet 'kein Vertrag in dieser Woche' und 0 bedeutet 'ein Vertrag bestand und nichts wurde gemeldet' — die beiden NICHT gleichsetzen. financials übergeben für Umsatz/Kosten/Marge, die sonst weggelassen werden. Erfordert das Resourcing-Modul und ROLE_RESOURCING_MANAGER. Nur lesend. |
Resourcing Bench_get
Tools
| resourcingBench_get | Wer über ein from/to-Fenster NICHT eingesetzt ist — der Pool. Damit klären, wer einem neuen Projekt zugeteilt werden könnte oder wo Kapazität ungenutzt bleibt; resourcingActuals_get zeigt, wie ausgelastet Personen sind, dieses Tool zeigt, wer gar keine Auslastung hat. ES KENNT KEINEN URLAUB: freePercent ist 100 minus bestätigte Zuweisungen, nichts weiter — jemand mit drei Wochen genehmigtem Urlaub erscheint als 100 % frei, und kein Feld der Antwort weist auf etwas anderes hin. Wird 'wer ist verfügbar' allein hieraus beantwortet, werden Personen Projekten zugeteilt, während sie abwesend sind — mit holidays_active oder holidays_list gegenprüfen. Erfordert das Resourcing-Modul. Nur lesend. |
Resourcing Schedule_get
Tools
| resourcingSchedule_get | Der geplante Resourcing-Zeitplan über ein from/to-Fenster — der Zuweisungs-Zeitplan, wie ihn der Planer anzeigt. Damit sehen, was künftig GEBUCHT ist; resourcingActuals_get verwenden für das, was tatsächlich dagegen gemeldet wurde. Erfordert das Resourcing-Modul und ROLE_RESOURCING_MANAGER. Nur lesend. |
People_get Permissions
Tools
| people_getPermissions | Was eine Person tatsächlich tun kann, aufgelöst: ihre Berechtigungsgruppen (jede mit den Rollen, die sie gewährt), ihre personenbezogenen Overrides und die effectiveRoles, zu denen sich beide zusammensetzen. DER Weg, um zu prüfen, ob eine Zugriffsänderung angekommen ist — people_list zeigt ein roles-Feld, aber dieses erklärt, WARUM diese Rollen gehalten werden und an welchem Hebel zu ziehen ist, um sie zu ändern. Hierauf vor jedem people_setRoleOverrides-Aufruf zurückgreifen, denn jenes Tool ersetzt die Override-Listen vollständig, und hier werden die aktuellen gelesen. staleOverrides sind entfernte Overrides, die zu keiner gruppengewährten Rolle mehr passen, sie bewirken derzeit also nichts. people_list liefert die id. Erfordert ROLE_ROLES_MANAGER, um jemand anderen als sich selbst zu sehen. Nur lesend. |
Leads_bulk Import
Tools
| leads_bulkImport | Importiert viele Leads in EINEM Aufruf, jeweils mit verschachtelten Kontakten, Listenmitgliedschaft und Kontaktaktivitäten — der Server legt den Lead an und reicht dessen id dann an die untergeordneten Elemente weiter, sodass niemals mit Zwischen-IRIs jongliert werden muss. Idempotent anhand natürlicher Schlüssel (companyName / email / (list,lead) / (type,occurredAt,contact)): gefahrlos erneut ausführbar und in Blöcken (≤100 Leads/Aufruf) nutzbar. Dies ist der Massenweg, den ein Kampagnenimport statt N einzelner leads_create-Aufrufe verwenden sollte. Schreibend. |
Lead Activities_by List
Tools
| leadActivities_byList | Jede Lead-Aktivität auf einer KAMPAGNE (einer Lead-Liste), in einem Aufruf — die id, IRI oder den exakten Namen der Liste übergeben. leadActivities_list filtert nach einem einzelnen Lead, ein Reporting auf Kampagnenebene würde sonst einen Aufruf pro Mitglied kosten (302 für eine Liste wie PZFD); dies löst stattdessen die Mitglieder der Liste auf und liest ihre Aktivitäten in begrenzten Batches. Mit type und occurredAt.after/.before kombinieren, um die Zahlen zu erhalten, nach denen tatsächlich gefragt wird: Antwortrate (type=reply_received), Bounce-Rate (type=bounced), Sendeabdeckung (type=message_sent). Gibt listId, listName, leadCount sowie die zusammengeführten, nach occurredAt sortierten Aktivitäten zurück. Eine unbekannte Liste ist ein FEHLER, kein leeres Ergebnis — ein vertippter Name kann also nicht als "diese Kampagne hatte keine Aktivität" gelesen werden. Ids stammen aus leadLists_list. Nur lesend. |
Lead Activities_bulk Import
Tools
| leadActivities_bulkImport | Eine ganze Outbound-Welle — jede tatsächlich gesendete Nachricht — in EINEM Aufruf erfassen, statt einem leadActivities_create pro Nachricht. Ein Array übergeben; jede Zeile benennt ihren Lead (leadCompanyName, gegen einen BESTEHENDEN Lead abgeglichen, oder eine Lead-IRI) sowie type und occurredAt. Jeder Zeile eine externalId geben — die stabile id pro Nachricht, z. B. die Gmail-Nachrichten-id — und der Import ist idempotent: Ein erneuter Lauf, oder der erneute Lauf einer nur teilweise importierten Welle, meldet Duplikate, statt sie anzulegen. Zeilen ohne externalId werden über (lead, type, occurredAt, contact) dedupliziert, denselben natürlichen Schlüssel, den leads_bulkImport verwendet, eine Welle, die zuerst über jenes Tool gelandet ist, wird hier also nicht dupliziert. Jede Zeile erhält ihr eigenes Ergebnis (created | duplicate | error), eine fehlerhafte Zeile verwirft also nicht den Rest des Batches. Legt KEINE Leads an — dafür leads_bulkImport verwenden. ≤ 1000 Zeilen/Aufruf. Schreibend. |