Hallo zusammen, da hier zuletzt nach konkreten Langdock-Erfahrungen mit DATEV-Anbindung gefragt wurde (@unklarer_Posten, @oliverstippe), ein kurzer Bericht aus der Praxis. Vorweg: Ich bin Anwender in einer Kanzlei, kein Anbieter, und verkaufe nichts. Setup Langdock als Plattform, DATEV-Anbindung über das Cloud Gateway von Riecken. Kein MCP, sondern eigene, eng geschnittene Aktionen gegen die REST-Schnittstellen (Rechnungswesen, Stammdaten, DMS). Ausgelöst wird fast alles über Teams-Kanäle: Mandantennummer posten, der Workflow läuft, das Ergebnis liegt im DMS und die Antwort kommt in den Thread. Protokolliert wird in SharePoint-Listen. Was damit läuft FiBu-Review: Die Buchführung eines Mandanten wird gegen ein festes Regelwerk geprüft (allgemeine Regeln plus mandantenindividuelle). Heraus kommt ein Report mit Begründung in Klartext, der im DMS abgelegt wird und beim zuständigen Sachbearbeiter zur Erledigung landet. Ein Musterreport mit frei erfundenen Daten hängt als PDF an. Der erste große Lauf ging über eine dreistellige Zahl Mandanten. Registerabruf: Registerauszug und Gesellschafterliste werden zum Mandanten geholt und abgelegt, dazu ein Abgleich der Registerdaten mit den DATEV-Stammdaten samt Prüfprotokoll. Signierte Dokumente aus DocuSign werden automatisch am Ursprungsdokument im DMS abgelegt. Belegnachforderung aus der OPOS-Liste als fertiges Word-Dokument. Bestandsweite Prüfungen, z. B. ob die Saldenvortragskonten bei allen Mandanten ausgeglichen sind. Daneben ein paar kleine lokale Helfer direkt über DATEVconnect, ganz ohne KI. Was wir gelernt haben So wenig KI wie möglich. Den FiBu-Review haben wir zuerst als Agenten gebaut und stellen ihn gerade auf deterministischen Code um. Regeln wie „Konto X muss ausgeglichen sein” braucht kein Sprachmodell zu beurteilen, das kostet nur Geld und Zeit und ist nicht reproduzierbar. Das Modell kommt nur noch dahin, wo wirklich Sprache gebraucht wird. Die Live-Schnittstellen verhalten sich öfter anders als die Dokumentation. Ohne Ausprobieren am echten System geht es nicht. Die Plattform hat Grenzen (Schritte pro Lauf, Anzahl Abrufe). Bei Prüfungen über den ganzen Bestand muss man in Paketen arbeiten. Es ist kein Selbstläufer. Jemand in der Kanzlei muss das bauen und pflegen können und die Fachlogik verstehen. Zur Modellauswahl in Langdock (@deusex, @oliverstippe) Bei uns sieht das so aus: Die Modelle, die nicht in der EU laufen, stehen in der Verwaltung in einer separaten Tabelle und sind von Haus aus nicht aktiv. Ein Admin muss sie bewusst einschalten, erst dann funktionieren sie in der Umgebung. Versehentlich landet also niemand bei einem Nicht-EU-Modell. Ob das formal an die §203-Vereinbarung gekoppelt ist, kann ich nicht sagen, da bin ich auf die Antwort des Supports auch gespannt. Zum Thema Sicherheit (@kmstrategie, @dstoll) Ich sehe das wie @dstoll. Bei uns bekommt kein Agent pauschal Zugriff auf den Bestand, und es wird nichts vorab indiziert oder kopiert. Jede Aktion kann genau eine Sache, zum Beispiel die Saldenliste eines Mandanten für ein Wirtschaftsjahr lesen. Abgefragt wird anlassbezogen für den einen Mandanten, um den es gerade geht. Geschrieben wird im Wesentlichen nur die Ablage neuer Dokumente im DMS, an Buchungen oder Stammdaten ändert kein Workflow selbständig etwas. Ob das einem reicht, muss jede Kanzlei selbst bewerten, aber es ist ein anderes Risikoprofil als ein Vollabzug des DMS zu einem Dritten. Und eine Bitte Wer selbst schon Abläufe gebaut hat, egal mit welchem Tool: Teilt bitte eure Anwendungsfälle hier. Mich interessiert vor allem, was bei euch im Alltag wirklich läuft und was ihr wieder verworfen habt. Ideen gibt es genug, Erfahrungsberichte aus dem Betrieb sind selten. Fragen gern hier im Thread. Viele Grüße
... Mehr anzeigen
