Wie wir eine komplette Buchhaltung in einem Tag aus FileMaker rausgehoben haben
*Doppelte Buchführung, Mandanten-Verwaltung, FM-Inbox mit Beleg-Anhang, Auswertungen mit Charts, DATEV-Export — alles in zehn Stunden mit PHP, SQLite, Bootstrap und ein bisschen FileMaker-Klebstoff. Und vor allem: in einem Bruchteil der Zeit, die das in FileMaker selbst gedauert hätte. Eine kleine Geschichte über Hybrid-Architektur, das richtige Werkzeug für das richtige Problem — und warum „mit FileMaker geht alles" zwar stimmt, aber nicht immer schlau ist.* --- ## Ausgangslage: „Wir bräuchten noch eine Buchhaltung" Manche Kundenwünsche kommen wie aus dem Nichts. Du sitzt im Auftragsabschlussgespräch, das CRM steht, die Rechnungen laufen sauber durch, der Workflow für Angebote und Aufträge wurde diese Woche live geschaltet — und dann kommt der Satz: *„Eigentlich bräuchten wir auch noch eine Buchhaltung. Doppelt, mit Soll und Haben. Und mit Mandanten, weil wir Schweiz und Deutschland getrennt führen müssen. Und Auswertungen wären schön. Und ein Export für die Steuerberaterin."* Das war der ungefähre Wortlaut. In FileMaker abgebildet wäre das eine Aufgabe von zwei bis drei Wochen. Tabellenstruktur, Sub-Summary-Sortierungen für Reports, Konten-Dropdowns, Soll-Haben-Validierung als Skript, Belege als Container-Anhänge, irgendwas Custom für Mandant-Wechsel, DATEV-Export als CSV-Berechnung. Funktioniert alles, aber jedes Stück ist Handarbeit. Und am Ende ist das Layout so verschachtelt, dass es niemand mehr anfassen will. Wir haben uns für einen anderen Weg entschieden: **die Buchhaltung verlässt FileMaker**. FM bleibt die Heimat der Geschäftsdaten — Kontakte, Projekte, Rechnungen, Ausgaben. Aber sobald es um doppelte Buchführung, Konten-Management, Auswertungen und Exporte geht, übernimmt ein eigenes kleines Web-Modul. Verbunden mit FileMaker über eine JSON-API. Das Ganze gebaut in einem Tag, am Ende ein eigenständiges, robustes Modul. ## Die Architektur in einer Skizze ``` FileMaker Buchhaltung (PHP/SQLite) +------------------+ +------------------------+ | T_INVOICES | -- JSON POST -> | /api/inbox.php | | T_EXPENSES | + PDF-base64 | (Token-Auth) | +------------------+ | | v | +------------------------+ | inbox_eintraege | | + inbox_belege | +------------------------+ v +------------------------+ | inbox.php (UI) | | „zu verbuchen" | +------------------------+ v +------------------------+ | buchung_neu.php | | mit Inbox-Prefill | +------------------------+ v +------------------------+ | buchungssaetze | | + buchungszeilen | | + belege (FK-Wechsel) | +------------------------+ v +------------------------+ | Dashboard / Reports / | | Export für DATEV | +------------------------+ ``` Drei Bewegungen zwischen den Systemen: 1. **Vom FM-Datensatz in die Inbox** — der User klickt im FileMaker-Layout auf einen Button, das Skript packt die Rechnung als JSON, hängt das PDF base64-codiert dran und schickt's an den PHP-Endpoint. 2. **Innerhalb des Web-Moduls** — User (oder Buchhalterin) zieht den Inbox-Eintrag durch den Verbuchungs-Workflow, ordnet Konten zu, speichert. Belege wandern automatisch vom Inbox-Pool zum Buchungssatz. 3. **Vom Web-Modul zur Steuerberatung** — CSV oder DATEV-Buchungsstapel-Format, ein Klick, fertige Datei. FM weiß von der Buchhaltung nur die URL und einen Token. Die Buchhaltung weiß von FM nur, dass Daten reinkommen können. **Beide Systeme sind unabhängig deploybar**, könnten in der Cloud oder lokal laufen, im gleichen Haus oder in verschiedenen. ## Die doppelte Buchführung selbst Doppelte Buchführung ist konzeptionell einfach: Jeder Vorgang trifft mindestens zwei Konten. Eines bekommt einen Soll-Eintrag, das andere einen Haben-Eintrag. **Soll = Haben muss immer gelten**. Das war's. Alle Schönheit kommt aus dieser einen Regel. Das Datenmodell besteht aus fünf Tabellen — und davon sind zwei nur „Stammdaten": ```sql mandanten -- pro Land/Buchhaltungseinheit ein Eintrag konten -- Kontenrahmen pro Mandant kostenstellen -- optional, pro Mandant buchungssaetze -- Kopfdaten eines Buchungssatzes buchungszeilen -- N Zeilen pro Satz, je Soll ODER Haben > 0 belege -- Datei-Anhänge zum Satz ``` Eine Buchung sieht in den Daten so aus — Beispiel: eine Rechnung über CHF 1077 brutto bei 7.7 % MWST: | satz_id | konto | soll | haben | steuer_satz | |---|---|---|---|---| | 42 | 1200 Forderungen | 1077.00 | 0 | 0 | | 42 | 3400 Erlös | 0 | 1000.00 | 7.7 | | 42 | 2200 MWST geschuldet | 0 | 77.00 | 0 | Drei Zeilen mit derselben `satz_id`. Soll-Summe = 1077.00, Haben-Summe = 1077.00. Balanciert. **Die Validierung passiert auf drei Ebenen:** 1. **JavaScript im Frontend** — Live-Update der Summen, Speicher-Button erst aktiv wenn ausgeglichen. Mit ein paar Zeilen Vanilla-JS, ohne Framework. 2. **PHP-seitig vor dem Insert** — der gleiche Check nochmal, damit niemand per direkter API-Manipulation eine Schief-Buchung reinschiebt. 3. **In der Auswertung** — die Saldenliste zeigt ein Soll/Haben-Total über alle Konten. Stimmt das nicht auf den Cent, ist irgendwo ein Bug — und wir sehen ihn sofort. Im Frontend ist das Hauptthema die Buchungsmaske. Zwei dynamische Zeilen am Anfang, „+ Zeile"-Button um weitere zu ergänzen, Konto-Dropdowns pro Zeile, Live-Summe unten, Balance-Indicator. Bootstrap macht das visuelle Heavy-Lifting, JavaScript verwaltet die Zeilen. ```javascript function updateSums() { let s = 0, h = 0; body.querySelectorAll('tr.zeile').forEach(tr => { s += parseNum(tr.querySelector('.soll').value); h += parseNum(tr.querySelector('.haben').value); }); sumSoll.textContent = s.toFixed(2); sumHaben.textContent = h.toFixed(2); const diff = s - h; if (Math.abs(diff) < 0.005) { balLab.innerHTML = 'ausgeglichen'; btnSave.disabled = false; } else { balLab.innerHTML = 'Diff ' + diff.toFixed(2) + ''; btnSave.disabled = true; } } ``` Das ist die ganze Live-Validierung. Würde man das in FileMaker bauen — mit Trigger-Scripts auf jedem Feld-Commit, einem Custom-Function für die Summenberechnung, und Sichtbarkeit-Skripten für das „Speichern"-Button — wäre man eine halbe Stunde beschäftigt. In Bootstrap + JS sind das fünfzehn Zeilen. ## Die Inbox: der eigentlich coole Teil FileMaker generiert Rechnungen. Diese Rechnungen müssen in die Buchhaltung. Aber: FM weiß nicht, auf welches Konto. FM weiß nicht, ob die Buchhalterin diese Buchung mit „Rechnung an Erlös" oder „Rechnung an Materialertrag" verbuchen will. FM weiß auch nicht, ob's eine separate MWST-Buchung sein soll oder eine Brutto-Buchung. **Lösung: Eingangskorb-Pattern**. FM schickt die Rohdaten in eine Inbox. Die Inbox lebt in der Buchhaltung. Die Buchhalterin sieht alles, was reinkommt — und ordnet beim Verbuchen die Konten zu. So funktionieren übrigens auch die meisten echten Buchhaltungs-Programme: GetMyInvoices, Lexoffice, sevDesk, alle haben einen „Posteingang" als ersten Verarbeitungsschritt. Was die FM-Seite zum Posteingang schickt: ```json { "mandant_name": "Aicher Schweiz", "typ": "einnahme", "datum": "2026-05-15", "betrag_brutto": 1077.00, "betrag_netto": 1000.00, "mwst_satz": 7.7, "beschreibung": "Rechnung INV00966 — CRM-Beratung", "beleg_nr": "INV00966", "partner_name": "Beispielkunde GmbH", "fm_quelle_id": "INV00966", "fm_quelle_typ": "invoice", "belege": [{ "filename": "Rechnung_INV00966.pdf", "mime": "application/pdf", "data_base64": "JVBERi0xLjQK..." }] } ``` **Drei Sachen sind hier elegant.** Erstens: Der Mandant wird per **Name** identifiziert, nicht per ID. Die Buchhaltung matched „Aicher Schweiz" case-insensitive und whitespace-tolerant gegen ihre Mandanten-Tabelle. Wenn FM den Namen leicht falsch schreibt, gibt die API eine Liste der verfügbaren Mandanten zurück. Damit ist FM komplett entkoppelt von der internen Mandant-ID-Vergabe der Buchhaltung. Zweitens: Die `fm_quelle_id` + `fm_quelle_typ` macht **Duplikat-Erkennung trivial**. Wenn jemand zweimal auf den „An Inbox senden"-Button klickt, bekommt der zweite Request 409 Conflict und einen Hinweis auf die bestehende Inbox-ID. Keine Doppel-Buchungen, kein Stress. Drittens: Der **Beleg geht direkt mit**. Das ist der GoBD-Knaller. „Keine Buchung ohne Beleg" — und hier wandert das Originaldokument von FileMaker als base64-Anhang in den JSON-Payload. PHP dekodiert, speichert die Datei in einem geschützten Verzeichnis, verlinkt sie mit dem Inbox-Eintrag. Beim Verbuchen wandern die Belege automatisch zum Buchungssatz mit. Die Steuerberaterin hat zu jeder Buchung das passende PDF — ein Klick im Buchungsdetail, Modal öffnet sich mit dem iframe-PDF-Viewer, fertig. Das Verbuchen aus der Inbox ist dann selbst ein hübscher Workflow: Klick auf „Verbuchen", Buchungs-Form öffnet sich mit allen Beträgen vorbefüllt — bei einer Einnahme mit MWST automatisch dreizeilig (Forderung Soll, Erlös Haben Netto, MWST Haben). User wählt nur noch die Konten aus den Dropdowns, klickt Speichern, fertig. Der Inbox-Eintrag bekommt Status „gebucht", Belege wandern mit, Verlinkung zum neuen Buchungssatz steht. ## Auswertungen mit Charts: aus 100 PHP-Zeilen Wow-Effekt Reports in FileMaker sind ein bisschen wie Auto-Reifen wechseln im Anzug: geht, fühlt sich aber nicht richtig an. Sub-Summary-Sortierungen, Trailing-Grand-Summary-Parts, Visualisierungen über zusätzliche Calc-Felder, Charts über die WebViewer-Krücke. In einer Web-Anwendung mit Chart.js sind die gleichen Reports eine Frage von ein paar Zeilen. Die Erfolgsrechnung ist im Kern ein einziges SQL-Statement: ```sql SELECT k.kontonummer, k.bezeichnung, k.typ, ROUND(SUM(bz.soll), 2) AS sum_soll, ROUND(SUM(bz.haben), 2) AS sum_haben FROM buchungszeilen bz JOIN buchungssaetze bs ON bs.id = bz.buchungssatz_id JOIN konten k ON k.id = bz.konto_id WHERE bs.mandant_id = ? AND bs.datum BETWEEN ? AND ? AND k.typ = 'ertrag' GROUP BY k.id ORDER BY k.kontonummer ``` Daraus baut PHP eine Tabelle mit allen Erträgen, daneben die Aufwand-Tabelle (gleiches Statement, `typ = 'aufwand'`). Saldo unten als Gewinn oder Verlust. Darunter zwei Chart.js-Doughnuts für die Verteilung pro Konto. Tooltips mit Prozent und absolutem Betrag. Total Aufwand für die Erfolgsrechnung: ~150 Zeilen PHP + ~80 Zeilen HTML/JS. In FileMaker wären das Stunden für die Sortierung, Stunden für die WebViewer-Charts, Stunden für die Tooltip-Logik. Die MWST-Abrechnung ist nochmal so ein Beispiel. Gruppiert pro Steuersatz, getrennt nach Output (was du an die Behörde schuldest) und Input (was du als Vorsteuer zurückbekommst). Daraus berechnet sich die Zahllast. Das ist ein simples GROUP BY auf `steuer_satz`, mit zwei Sub-Queries für Soll auf Aufwand-Konten und Haben auf Ertrag-Konten. Total fünfzig Zeilen. Das Kontenblatt mit laufendem Saldo und Verlaufschart? **Ein** Loop über die chronologisch sortierten Zeilen, in dem sich der Running-Total aktualisiert. Daten an Chart.js übergeben, fertig ist der Liquiditätsverlauf der Bank. ## Belege und Vorschau-Modal: die Kleinigkeit, die alles besser macht Bei der Buchhaltung sind die angeheftenten PDFs nicht Beiwerk, sondern das Herzstück. Du brauchst sie für GoBD, für die Steuerberatung, für deine eigene Kontrollfähigkeit. „Wann genau habe ich diese Rechnung erhalten? Was stand drauf?" — Klick auf Vorschau, Modal öffnet sich, PDF wird inline gezeigt. Das macht Bootstrap mit zehn Zeilen JavaScript: ```javascript modalEl.addEventListener('show.bs.modal', (ev) => { const t = ev.relatedTarget; const src = t.getAttribute('data-src'); const isT = t.getAttribute('data-istype'); bodyEl.innerHTML = (isT === 'image') ? '' : '
'; }); ``` Trigger: Klick auf das Beleg-Thumbnail in der Belege-Liste. Browser-eigener PDF-Viewer übernimmt das Rendering mit Scroll, Zoom, Suche. Fertig. Bei Bildern entsprechend ein ``. In FileMaker wäre das WebViewer mit `data:`-URLs für Bilder (geht), für PDFs eine separate Verarbeitung. Plus: die Container-Felder verhalten sich beim Anzeigen oft anders als beim Hochladen. Plus: keine Modal-Logik, sondern ein weiteres Fenster (oder ein Layout-Sprung mit Rück-Skript). ## DATEV-Export: einmal geschrieben, immer froh Die Steuerberaterin braucht die Daten in ihrem Format. Wenn sie mit DATEV arbeitet — und das tun die meisten deutschen Steuerberater — bedeutet das ein **DATEV-Buchungsstapel-CSV im EXTF-Format Version 7**, Windows-1252-codiert, mit einer sehr spezifischen Header-Struktur. Klingt schlimm. Ist es nicht. PHP schreibt die Datei zeilenweise raus, jede Zeile entspricht einem Buchungssatz. EXTF-Header drüber, Spalten-Header drunter, Daten danach. Encoding via `mb_convert_encoding($line, 'Windows-1252', 'UTF-8')`. Done. Die Steuerberaterin importiert das in DATEV unter „Stapelverarbeitung → Importieren → Buchungsstapel", und die Buchungen landen genau dort, wo sie hin sollen. Dazu noch ein Standard-CSV-Export (UTF-8 mit BOM, Excel-tauglich) für die Fälle, wo's mal kein DATEV ist. Beide Exporte auf einer Seite, Filter für Jahr und Quartal, Vorschau der ersten 20 Zeilen, Download-Button. Komplett: vielleicht 300 Zeilen PHP. Das gleiche in FileMaker zu bauen, mit einer Skript-Schleife über `Exportiere Datensätze` mit einem maßgeschneiderten Feldformat, der Encoding-Konvertierung als CF, dem Header-Voranschreiben mit `Exportiere Feldinhalte` und Datei-Append — eher zwei Tage als zwei Stunden. ## Wo der Hybrid-Ansatz seine Stolperfallen hatte Wenn man so eine Architektur baut, gibt's ein paar Sachen, die man beim ersten Mal trifft. **FileMaker und base64.** Beim ersten Versuch, das PDF aus dem Container-Feld zu base64-codieren, kam aus FM nicht das PDF als base64 — sondern der Wert „4648" als base64. Das ist die RFC-Version, die ich als zweiten Parameter an `Base64EncodeRFC` übergeben hatte. In der FM-Version des Kunden gibt's `Base64EncodeRFC` mit zwei Parametern nicht — die Funktion akzeptiert nur einen Parameter und gab anscheinend stillschweigend den zweiten als Ergebnis zurück. Lustige Fehlersuche. Lösung: `Base64Encode` (ein Parameter) — Zeilenumbrüche sind im Output drin, aber PHP strippt die per Regex vor dem Decoden. Funktioniert seitdem. **FileMaker und UTF-8-BOM.** Beim Editor-Workflow (siehe der separate Doku-System-Blogpost) kam in der WebViewer-URL ein Byte-Order-Mark vor das „https://". `%EF%BB%BFhttps://...` — Browser lädt nichts, weil das keine gültige URL ist. Quelle des BOM: nicht PHP, nicht der Filesystem, sondern FileMakers `JSONGetElement`. Das Modul hat einfach ein BOM-Zeichen in den extrahierten String gemoppelt. Fix: im WebViewer-URL-Calc alles vor dem ersten „http" wegschneiden mit `ZeichenMitte(url; Position(url; "http"; 1; 1); 9999)`. Robust gegen alles, was FileMaker an unsichtbaren Zeichen produzieren könnte. **mPDF und Schrift-Glyphen.** Wir nutzen mPDF im docsystem, das beim Verbuchen mit der Buchhaltung wenig zu tun hat — aber im selben Projekt. Beim ersten Print kamen Wörter wie „sofort" als „so☐ort" raus, mit Tofu statt „f". Die mPDF-Helvetica-Bold ist berüchtigt unvollständig. Lösung: `'default_font' => 'dejavusans'`, DejaVu Sans ist Unicode-komplett. **Logo-Pfad: Filesystem vs URL.** Im docsystem hatte ich den Logo-Pfad zuerst als absoluten Filesystem-Pfad gesetzt. Funktioniert für mPDF (das von Disk liest), funktioniert nicht für den Editor-Browser-Preview (der den Pfad als URL interpretiert). Lösung: URL setzen, die der Browser direkt lädt und die mPDF per HTTP fetchen kann. Beide Welten happy. Diese Stolperfallen sind alle einmal-und-für-immer. Hat man sie verstanden, taucht das gleiche Problem nie wieder auf. Aber beim ersten Mal kostet jede halb bis zwei Stunden Debugging. ## Zeitvergleich: was hätte FileMaker gekostet Hier ein ehrlicher Aufriss, was die einzelnen Bausteine in reiner FileMaker-Entwicklung gedauert hätten, basierend auf Erfahrung: | Baustein | FileMaker-Variante | Hybrid (PHP + FM) | |---|---|---| | Datenmodell doppelte Buchführung | 1 Tag (Tabellen + Relationen + Calcs) | 30 Min (SQL CREATE TABLEs) | | Buchungs-Eingabemaske mit Soll/Haben | 2 Tage (Portal-Logik + Trigger + Validation) | 4 Stunden (Bootstrap + Vanilla JS) | | Mandanten-Switcher | 0.5 Tag (Globals + Skripte + Layout-Refreshes) | 30 Min (Session + Helper) | | Konten/Kostenstellen-Verwaltung | 1 Tag | 2 Stunden | | Buchungsliste mit Filtern | 1 Tag | 1 Stunde | | Detail-Ansicht mit Belegen + Vorschau | 1 Tag (WebViewer-Tricks oder Container-Manage) | 1.5 Stunden | | Erfolgsrechnung + Saldenliste | 2 Tage (Sub-Summary-Layouts) | 2 Stunden | | MWST-Abrechnung | 1 Tag | 1 Stunde | | Kontenblatt mit Saldo-Verlauf | 1.5 Tage (Calc-Felder + WebViewer-Chart) | 2 Stunden | | Beleg-Upload + Modal-Vorschau | 1 Tag (Container-Tricks) | 1 Stunde | | DATEV-Export | 2 Tage (Encoding + Format) | 2 Stunden | | Inbox / API für FM-Anbindung | nicht in FM machbar | 4 Stunden | | Charts (Bar, Donut, Linie) | 1 Tag (WebViewer-Krücke) | 30 Min | | **Total** | **~15 Arbeitstage** | **~22 Stunden, also 3 Tage** | Faktor 5. Und das mit konservativen FileMaker-Schätzungen — die meisten Projekte würden noch länger dauern, weil unterwegs immer wieder UI-Polishing kommt, das in HTML/CSS trivial ist und in FM-Layouts schmerzhaft. ## Wann FM-Only trotzdem das richtige Werkzeug bleibt Damit nicht der falsche Eindruck entsteht: **FileMaker ist nicht das Problem**. FM ist immer noch das Werkzeug der Wahl für: - **Stammdaten und Geschäftsprozesse**: Kontakte, Projekte, Aufträge, Rechnungen — alles, was an einer Hand voll Hauptmasken hängt und mit Beziehungen verknüpft ist - **Datenintensive Eingabemasken**: Portalansichten, Suchergebnisse, Berichte über native Find-Funktionen - **Offline-Fähigkeit auf FileMaker Go**: einfach unschlagbar - **Rapid Prototyping** mit Geschäftslogik: was du in FM in einer Stunde mit Auto-Eingabe-Berechnungen und Skripten zusammenstecken kannst, würde in einem Web-Stack einen halben Tag dauern - **Cross-Plattform-Distribution**: ein FM-File, läuft auf Mac/Win/iOS/Web Was FM **nicht** gut kann — und was der Trigger für eine Hybrid-Lösung sein sollte: - **Komplexe Layout-Komposition** (HTML/CSS ist da Lichtjahre voraus) - **Standard-Datenformate** (DATEV, CSV mit spezifischen Headern, EDI, etc.) - **Visualisierungen** (Chart.js > FM-WebViewer mit Chart.js, weil's keine Komposition-Reibungsverluste gibt) - **Editiervorgänge nach dem Print** (kannst du in FM auch lösen — aber HTML/CSS macht das von allein) - **Datei-Uploads mit Vorschau** (Container-Felder sind keine Web-Komponenten) - **Multi-Tenant-Logik** (Mandanten in FM = Frickelarbeit mit Globals und Skripten) Die ehrliche Faustregel: Wenn der Kundenwunsch nach „Layout-Magie" klingt, nach „Standardformat-Export", nach „Charts und Reports" — dann lohnt sich ein Blick auf den Hybrid-Ansatz. Wenn er nach „Stammdaten + Workflow + Suche" klingt, bleib bei FM. ## Was kommt nach Tag 1? Was wir in den ersten zehn Stunden nicht angefasst haben: - **Authentifizierung und Berechtigungen**: solange die Buchhaltung lokal auf einem Mac läuft, ist Token-Auth über die API genug. Sobald mehrere User drauf zugreifen sollen — die Buchhalterin von zu Hause, der Geschäftsführer aus dem Büro — braucht's Session-Login, Rollen, Audit-Log. Einen halben Tag, mit Standard-Bordmitteln (Session + Password-Hash + Middleware-Check). - **Webhooks zurück nach FM**: wenn eine Buchung verbucht wurde, könnte die Buchhaltung das per Webhook an FM melden, damit dort die Rechnung als „verbucht" markiert wird. Zwei Stunden Arbeit. - **Mobile Ansicht**: Bootstrap 5 ist responsive, aber die Buchungs-Tabelle mit Soll/Haben/Steuer-Spalten ist auf dem Handy fummelig. Eine eigene Mobile-View mit Card-Layout, ein Tag. - **GoBD-Vollkonformität mit unveränderlicher Speicherung**: aktuell kann ein Buchungssatz noch editiert/gelöscht werden. Für echte GoBD bräuchte es Storno-Buchungen statt Edit, und einen unveränderlichen Audit-Log. Einen Tag. Alles davon ist incrementiell, keine Architektur-Änderung. Die Inbox-Pipeline und das Datenmodell bleiben stehen. Das ist die andere große Stärke der Trennung: jeder Baustein kann unabhängig wachsen. ## Was die Steuerberaterin sagt Wir haben das Modul vor zwei Wochen an die Steuerberaterin des Kunden geschickt — als Bildschirmaufnahme mit Walkthrough plus DATEV-Export einer Testperiode. Antwort kam am gleichen Tag: *„Den Export kann ich direkt in DATEV importieren, der hat alle Pflichtfelder. Die Charts und Auswertungen sind nett, brauchen wir aber nicht — wir haben unser eigenes Reporting. Aber dass die Belege als PDF mit jeder Buchung dabei sind, das ist gut. Spart uns das ewige Rückfragen bei euch."* Das ist im Grunde, was du als Entwickler hören willst. Das Ding tut, was es soll. Die externen Stakeholder kommen ohne Schulung damit klar. ## Fazit Die FileMaker-Plattform ist und bleibt eine starke Wahl für viele Geschäftsanwendungen. Sie wird nicht weniger gut, nur weil man manchmal etwas drumherum baut. Im Gegenteil — das, was FM am besten macht, kann sie umso besser machen, wenn man ihr nicht auch noch die Aufgaben aufdrückt, für die ein klassischer Web-Stack das viel bessere Werkzeug ist. Doppelte Buchführung mit allem Drum und Dran ist so eine Aufgabe. In FileMaker gemacht: zwei bis drei Wochen, am Ende ein Layout-Albtraum den niemand mehr anfasst, Reports, die sich nicht mehr ändern lassen, ohne dass das halbe Sub-Summary zerbricht. Als kleine PHP/SQLite-Anwendung mit FM-Anbindung: zehn Stunden, am Ende ein eigenständiges, wartbares Modul, das die Buchhalterin bedienen kann ohne FM zu öffnen. Das ist nicht das richtige Verhältnis für jedes Projekt. Es ist auch nicht „FM ist schlecht". Es ist nur das saubere Anerkenntnis, dass *jedes Werkzeug einen Bereich hat, in dem es überlegen ist*. Und dass die wirklichen Profis ihre Werkzeugkiste so kombinieren, dass die Stärken sich addieren — nicht so, dass alles mit dem einen Werkzeug erschlagen wird, das man am besten kennt. Wenn dir das nächste Mal jemand „nebenbei noch eine Buchhaltung" anbietet — überleg, ob das ein FM-Projekt ist oder eines, das in einem Tag erledigt sein kann, wenn man ein bisschen drumherumdenkt. ---