Discover Top Posts Tagged with #filemaker php

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. ---

#Entwicklung #FileMaker PHP #KI

Schöne Dokumente aus FileMaker - ohne FileMaker-Layout

# Schöne Dokumente aus FileMaker - ohne FileMaker-Layout *Wie wir Rechnungen, Angebote und Briefe aus FileMaker als HTML-Templates rendern, im WebViewer mit TinyMCE bearbeiten lassen und am Ende ein sauberes PDF zurück in die Datenbank schreiben. Ein paar bewegliche Teile, aber das Ergebnis ist überraschend rund — und designerisch viel flexibler als der klassische FM-Layout-Druck.* --- ## Ausgangslage: Rechnungen aus FileMaker Es gibt viele FileMaker-Projekte, in denen Rechnungen und Angebote über FM-Layouts gedruckt werden. Funktioniert. Sieht meistens auch okay aus. Aber irgendwann kommt einer dieser Momente: - Der Kunde möchte den Briefkopf neu gestalten — mit echtem Logo, vernünftigen Farben, einem coolen Layout - Die zweite Seite soll umbrechen wie in echten Geschäftsbriefen, mit Kopf-/Fußzeile, Seitennummerierung „Seite X von Y" - Ein Reverse-Charge-Hinweis soll dynamisch eingeblendet werden, je nach Kunden-Land - Die Texte sollen vor dem Versand schnell mal angepasst werden — ein zusätzlicher Absatz, ein anderer Schlusssatz, eine spezielle Bemerkung für diesen Kunden In FM-Layouts wird das schnell zur Schmerz-Übung. Konditionale Formatierung, Sub-Summary-Sortierungen, Slide-Object-Tetris. Und am Ende ist die Vorlage so verschachtelt, dass keiner sie mehr anfassen will — schon gar nicht die Texte, die in einem statischen Layout-Element verklebt sind. ## Die Idee: HTML-Templates + ein kleiner PHP-Dienst Was wäre, wenn: - Die Rechnung ein einfaches **HTML-Template** wäre, mit Platzhaltern wie `{{rechnung_nummer}}`, `{{kunde_name}}`, `{{positionen_rows}}`? - FileMaker **liefert die Daten** als JSON an einen kleinen PHP-Dienst - Der Dienst **rendert das Template**, gibt einen Editor-Link zurück - Im FileMaker-WebViewer öffnet sich ein **WYSIWYG-Editor** (TinyMCE), in dem man die Rechnung nochmal bearbeiten kann - Beim Klick auf „Fertig" holt FileMaker das **fertige PDF** zurück in den Datensatz-Container Genau das haben wir gebaut. Wir nennen's „docsystem" — ein eigener kleiner Ordner mit PHP, ein paar HTML-Templates und [mPDF](https://mpdf.github.io/) als PDF-Renderer. ## Architektur in einer Skizze ``` FileMaker (Projektdatei) docsystem (PHP) +------------------+ +------------------------+ | T_INVOICES | ─→ JSON-POST ─→ | api/create_document | | T_ESTIMATES | | | | T_DOCUMENTS | ←─ editor_url ── | drafts/.html | +------------------+ | | ↓ WebViewer | editor.php (TinyMCE) | öffnet editor.php | | ↓ | api/get_pdf_base64 | Klick „Fertig" | | ↓ fmp:// callback | pdf/.pdf | FM holt PDF (base64) +------------------------+ ↓ (mPDF) Container_PDF gefüllt ``` Drei Aufrufe von FileMaker aus: 1. **POST `api/create_document_json.php`** — mit JSON-Body: `doc_id`, `template`, `data`. Antwort: `editor_url` 2. **WebViewer öffnet `editor_url`** — der TinyMCE-Editor lädt den Draft, User editiert 3. **Klick „Fertig" im Editor** löst per `fmp://` ein FM-Skript aus, das `api/get_pdf_base64.php?doc_id=…` aufruft und das PDF in den Container schreibt ## Wie ein Template aussieht Hier ein gekürzter Ausschnitt aus `templates/rechnung.html`: ```html

{{absender_name}} {{absender_telefon}} …

RECHNUNG

Rechnungsnummer{{rechnung_nummer}} Rechnungsdatum{{rechnung_datum}} Fälligkeitsdatum{{faelligkeit_datum}}

{{kunde_name}} {{kunde_strasse}} …

ArtikelBeschreibung… {{positionen_rows}}

``` Reines HTML mit Mustache-artigen `{{…}}`-Platzhaltern. Kein PHP, keine Schleifen-Syntax im Template. Es gibt einen Sonderfall — die Positionen, dazu gleich mehr. ## Wie FileMaker die Daten liefert Im FM-Skript wird der JSON-Payload aufgebaut. Vereinfacht: ``` JSONSetElement ( "{}" ; [ "doc_id" ; "RECHNUNG-" & T_INVOICES::ID_Invoice ; JSONString ]; [ "template" ; "rechnung" ; JSONString ]; [ "data" ; $data ; JSONObject ] ) ``` `$data` ist ein zweites JSON-Objekt, das die ganzen Platzhalter-Werte enthält: ``` JSONSetElement ( "{}" ; [ "absender_name" ; "Beispiel GmbH" ; JSONString ]; [ "rechnung_nummer" ; T_INVOICES::ID_Invoice_Display ; JSONString ]; [ "rechnung_datum" ; GetAsText ( T_INVOICES::Date_Invoice ) ; JSONString ]; [ "kunde_name" ; T_INVOICES::BillTo_Company ; JSONString ]; [ "positionen_rows" ; $positionen_rows ; JSONString ]; [ "netto" ; "€" & Substitute ( T_INVOICES::Subtotal_Net ; "." ; "," ) ; JSONString ]; … ) ``` Ein POST per „Aus URL einfügen" mit `--request POST --header "Content-Type: application/json" --data @$json` — und auf der anderen Seite parst PHP das. Im docsystem läuft die Template-Ersetzung minimalistisch: ```php function render_template(string $tpl, array $data): string { return preg_replace_callback( '/\{\{\s*([a-zA-Z0-9_\-]+)\s*\}\}/', fn($m) => (string)($data[$m[1]] ?? ''), $tpl ); } ``` Das war's. Kein Twig, kein Blade, kein Mustache-Paket — eine Funktion mit einem Regex. ## Der Positionen-Trick: ein Calc-Feld pro Datensatz Tabellen mit dynamischen Zeilen sind die Stelle, wo simple Template-Engines aussteigen. Statt eine Loop-Syntax ins Template einzubauen, lassen wir die Arbeit von FileMaker erledigen — über ein Calc-Feld: Auf der Line-Items-Tabelle ein berechnetes Textfeld `c_invoice_row_html`: ``` Let ([ prod_safe = Substitute ( Product ; [ "&" ; "&" ] ; [ "<" ; "<" ] ; [ ">" ; ">" ] ) ; unit_fmt = "€" & Substitute ( Runden ( UnitPrice ; 2 ) ; "." ; "," ) ; sum_fmt = "€" & Substitute ( Runden ( ExtendedPrice ; 2 ) ; "." ; "," ) ]; "" & "" & prod_safe & "" & "" & Description & "" & "" & unit_fmt & "" & "" & Quantity & "" & "" & sum_fmt & "" & "" ) ``` Im FM-Skript ziehen wir alle ``-Zeilen über die normale Liste-Funktion über die portal-relevante Beziehung: ``` Variable setzen [ $positionen_rows ; Substitute ( Liste ( T_invoices_LINE_ITEM||id_invoice|::c_invoice_row_html ) ; "¶" ; "" ) ] ``` `Liste()` mit ¶-Trennzeichen sammelt alle Rohzeilen, `Substitute` entfernt den Trenner. Heraus kommt **ein einziger String** mit allen `...`-Tags — den schicken wir als `positionen_rows` ins Template. PHP setzt das stumpf in den `` ein. Fertig. Vorteile dieses Ansatzes: - **Pro-Position-Formatierung** liegt im Calc-Feld — also bei den FM-Devs, nicht im PHP - **Kein PHP-Code für unterschiedliche Positions-Layouts**: für Angebote, Rechnungen, Lieferscheine kann man je ein eigenes Calc-Feld definieren - **HTML-Escaping** passiert dort, wo die Daten herkommen — sauberer als am PHP-Ende ## Der Editor: TinyMCE im WebViewer `api/create_document_json.php` legt unter `drafts/.html` die gerenderte Seite ab und gibt eine URL zurück: ``` https://maps.example.com/docsystem/editor.php?doc_id= ``` Diese URL landet im WebViewer eines FM-Layouts. `editor.php` baut um den Draft eine TinyMCE-Instanz drumherum. Der User kann frei nachbearbeiten — einen extra Absatz einfügen, eine Zeile streichen, einen freundlicheren Schlusssatz wählen. Alles direkt in der Rechnung, ohne FM-Layout-Anpassung. Drei Buttons oben: - **Speichern** — schreibt den HTML zurück nach `drafts/.html` - **PDF erzeugen** — speichert + ruft mPDF auf, legt das PDF unter `pdf/.pdf` ab - **Fertig (an FileMaker übergeben)** — feuert `fmp://$/MyDB.fmp12?script=Dokument%20uebernehmen&param=` Der letzte Button ist die Brücke zurück: FM bekommt einen Skript-Aufruf mit der `doc_id` als Parameter. Das Skript ruft dann selbst `api/get_pdf_base64.php?doc_id=…` auf, holt das PDF als base64, und schreibt es per `Base64Decode` direkt in den Container des Dokuments. Fenster schließt sich, der User landet wieder auf seinem Datensatz — der Container ist gefüllt. ## mPDF macht das PDF mPDF nimmt das gespeicherte HTML aus `drafts/.html`, kombiniert es mit `assets/pdf.css`, und schreibt eine PDF nach `pdf/.pdf`. Die CSS ist normales Print-CSS: A4-Format, Margins, dezente Tabellen-Borders, Markenfarbe für Headlines und Bullets. mPDF ist nicht ohne Tücken — wir haben drei Stolperfallen erlebt, die für jede ähnliche Setup gelten: ### Logo via URL, nicht via Filesystem-Pfad Erster Versuch: Das Logo als absoluten Filesystem-Pfad in den `` schreiben. Funktioniert für mPDF, das von der Disk lesen kann. **Funktioniert NICHT** für den Editor-Preview im Browser — der interpretiert `/var/www/...` als URL-Pfad und scheitert. Lösung: eine URL nehmen, die sowohl der Browser als auch mPDF abholen können: ```php $data['LOGO_PFAD'] = BASE_URL . '/assets/logo.png'; ``` mPDF holt das per HTTP, der Browser zeigt's normal an. Funktioniert lokal und auf dem Server, weil `BASE_URL` aus dem Request abgeleitet wird (Auto-Detect, kein Hardcoding). ### Helvetica fällt um, Bold-„f" als Tofu mPDF bringt eine PostScript-Helvetica mit, die in den Bold-Varianten **berüchtigt unvollständig** ist. Konkret: das Wort „Offener Betrag" rendert als „O[]fener Betrag" mit Glyph-Tofu auf dem „f". Auf den ersten Blick ein bizarres Phänomen — bis man merkt, dass der Bold-Cut bestimmte Glyphen einfach nicht hat. Fix: in den mPDF-Konstruktor `'default_font' => 'dejavusans'` setzen, in der CSS-Body-Regel `font-family: dejavusans, sans-serif`. DejaVu Sans ist Unicode-vollständig, bringt saubere Bold/Italic-Varianten mit, ist mPDF-mitgeliefert. Optik etwas weniger streng, aber lesbar und korrekt. ### Ein BOM in der editor_url Der erste Echtbetrieb: WebViewer zeigt „Laden: %EF%BB%BFhttps://…". Das `%EF%BB%BF` ist die URL-Codierung eines UTF-8 Byte-Order-Mark, das sich vor die URL geschmuggelt hat. PHP-Response war sauber, also kam das Zeichen aus FileMaker — bekannte Quirks beim `JSONGetElement` mit UTF-8-Responses. Wir hätten den BOM im Skript wegschneiden können. Eleganter ist es im WebViewer-Calc selbst: ``` ZeichenMitte ( DOC_Documents::g_editor_url ; Position ( DOC_Documents::g_editor_url ; "http" ; 1 ; 1 ) ; 9999 ) ``` Schneidet alles vor dem ersten „http" weg — egal ob BOM, Leerzeichen, Zeilenumbruch. Robust gegen alles, was FileMaker an unsichtbaren Zeichen produzieren könnte. Und der Vorteil: nur eine Stelle anpassen, nicht in jedem Skript. ## Was uns überraschend gefreut hat **Wiederverwendung zwischen Templates.** Rechnung und Angebot teilen sich denselben CSS-Stack — `letterhead-rechnung`, `positions-rechnung`, `totals-table`, alles definiert in `pdf.css`. Das Angebot ist eine 1:1-Kopie der Rechnung mit anderen Platzhalter-Namen und einem geänderten Bedingungen-Text. Neuer Look entstand in zehn Minuten, nicht in zehn Stunden. **Texte sind editierbar.** Das war der eigentliche Trigger. Der User kann jeden Brief, jede Rechnung kurz vor dem Versand nochmal anfassen — eine Bemerkung ergänzen, einen Absatz raushauen, eine spezielle Anrede. Im FM-Layout-Druck unmöglich, im TinyMCE trivial. **Separation of Concerns.** FileMaker macht Daten und Beziehungen. PHP macht Templates und PDF-Rendering. CSS macht Optik. Drei Welten, klar getrennt, jede für sich änderbar. **Multi-Instance-tauglich.** Der ganze Ordner ist relocateable. Auf einem Server zwei docsystem-Instanzen parallel? Einfach beide Ordner hochladen, beide `config.php` haben `BASE_URL` als Auto-Detect — keine Pfade hardcoded. Eine Instanz für die GmbH, eine für die GbR, eine für den Kunden. Funktioniert. ## Was wir noch vor uns haben Ein paar offene Punkte, die in der nächsten Iteration drankommen: - **Pro-Kunden-Vorlagen.** Aktuell hat jeder Kunde dieselbe Vorlage. Für „edge"-Kunden wäre ein eigenes Branding nett — über einen optionalen `template_variant`-Parameter - **Mehrsprachige Templates.** `rechnung_de.html`, `rechnung_en.html`, `rechnung_fr.html` — und `data.lang` entscheidet - **Tausender-Trennzeichen für Beträge.** Aktuell „€4000,00" statt „€4.000,00". Eine Custom Function in FM würde das lösen — einmal schreiben, überall verwenden - **Bilder im Editor.** Der TinyMCE kann Bilder embedden; wir würden Anhänge (z.B. Produktfotos) gerne direkt im Editor einfügbar machen ## Fazit Wenn dein FileMaker-Druck irgendwann an Grenzen stößt — sei es Optik, Flexibilität oder Editierbarkeit kurz vor dem Versand — lohnt sich der Blick auf das HTML/CSS/mPDF-Stack. Du brauchst nicht viel: einen Webserver mit PHP, mPDF aus Composer, ein paar Templates, einen Editor (TinyMCE), und FileMaker auf der anderen Seite, das per JSON die Daten liefert und am Ende das PDF entgegennimmt. Die mPDF-Quirks (Logo-URLs, Schriften, BOM) klingen alle erstmal nervig — sind aber alle einmal-und-für-immer-Probleme. Hat man sie verstanden, läuft der Stack still und zuverlässig. Und das Beste: das ganze System ist **kein Plugin**. Kein Vendor-Lock-in, kein Lizenzmodell, keine Lieferanten-Abhängigkeit. Nur PHP, mPDF, HTML, CSS und etwas FileMaker-JSON. Wartbar von jedem, der diese Bausteine kennt. ---

#Entwicklung #FileMaker PHP #Tricks

Wie wir die FileMaker-Mail-Lösung von einem Plugin befreit haben

# Wie wir die FileMaker-Mail-Lösung von einem Plugin befreit haben *Eine kleine Migrations-Geschichte: von Dacons MailIT zu einer eigenen PHP-Mail-Pipeline mit echtem Threading, ohne Plugin-Lizenzen, ohne lokalen Mini-Webserver, ohne Vendor-Lock-in. Was als „der Kunde will Konversations-Ansicht" begann, wurde zur kompletten Neuverdrahtung der Mail-Schicht. Mit überraschend wenig Code und einigen Erkenntnissen, die wir hier teilen.* --- ## Ausgangslage: ein Plugin, das alles entscheidet Der Kunde hatte eine FileMaker-Mailtabelle mit gut 49.000 Datensätzen. Eingehende und ausgehende Mails, Anhänge in zwölf globalen Container-Slots, Verknüpfungen zu Kontakten, Projekten und Konten alles solide gewachsen. Und alles durchwoben mit dem Plugin **Dacons MailIT**. MailIT ist ein in die Jahre gekommenes, aber durchaus mächtiges Plugin. Es bringt IMAP, POP3, SMTP, sogar einen kleinen lokalen Webserver mit (für die Inline-Bilder-Darstellung im WebViewer) und das in einer fertigen Beispieldatenbank, die viele Kunden direkt als Basis übernehmen. Das war hier auch passiert: die DB-Struktur stammte aus der „Mailit Ticket"-Demo. Der Wunsch des Kunden klang harmlos: **„Ich möchte, dass zusammengehörige Mails als Konversation angezeigt werden."** Klingt nach „ein bisschen Sortierung". Wurde zum Anlass für eine vollständige Plugin-Befreiung. ## Die Diagnose: Threading geht so nicht Threading auf Mail-Ebene heißt: aus losen Datensätzen wird eine Konversation. Eine eingehende Mail mit `In-Reply-To: ` gehört zur Mail mit `Message-ID: `. Mehrere Antworten auf eine Antwort bauen einen Baum. Mail-Clients wie Apple Mail oder Outlook lösen das seit zwanzig Jahren — in FileMaker bauen wir uns das selbst. Das Schema hatte schon `Message_ID` und `In_Reply_To`. Reicht für eine Stufe Rückwärts. Für tiefe Konversationen reicht das nicht — dafür braucht's den `References`-Header, der nach RFC 5322 die ganze Vorgänger-Kette mitschleppt. Und der war nicht da. Plugin lieferte ihn auch nicht. Außerdem: das Match-Feld in der DB hieß `Message_id_suche` und war definiert als `LiesAlsZahl ( Message_ID )`. Bei einer Message-ID wie `` ergibt das **`3`**. Dreiundsiebzig Mails matchen damit munter zusammen. Bug seit Jahren unentdeckt — weil bisher niemand drüber gestolpert ist, dass es nicht funktioniert. ## Die Idee: ein PHP-Mailclient gibt's schon Wir hatten in einem anderen Projekt einen kleinen PHP-Mailclient liegen — IMAP über `webklex/php-imap`, SMTP über PHPMailer, eine SQLite-Tabelle für die Verknüpfung Message-ID ↔ FileMaker-Entität, ein paar HTML-Seiten für den WebViewer. War als Prototyp gedacht (dann als AddOn), lag aber zu rund 70 Prozent funktionsfähig herum. Die Idee schrieb sich von selbst: - **MailIT komplett raus.** Keine Plugin-Lizenz mehr, keine MailIT-Templates, keine „Plug-in not installed"-Dialoge. - **PHP übernimmt die Mail-Mechanik.** Senden, Abholen, Anhänge, Folder-Listing — alles per JSON-API. - **FileMaker bleibt die Heimat der Daten.** Anzeige, Beziehungen, Threading-Logik, Verknüpfungen mit dem CRM — bleibt nativ. Die Architektur: ``` FileMaker (PRJ_CRM.fmp12) PHP-Mailclient +------------------+ +--------------------------+ | TAB_Mail | ←─ JSON-Import ── | /api/list_inbox_messages | | TAB_MailAccount | ─→ JSON-Send ──→ | /api/send_mail | | Skripte/Layouts | ─→ Anhang holen → | /attachment.php | +------------------+ +--------------------------+ ↑ ↓ └── data/accounts.json ←── sync ─── TAB_MailAccount ↓ IMAP/SMTP Server ``` ## Die zentrale Architektur-Entscheidung: Stateless, aber pragmatisch Klassisch hat man zwei Wahlmöglichkeiten: **A) Reines Stateless** — jeder API-Aufruf bringt die Server-Credentials mit. Sauber, aber FileMaker müsste bei jedem Klick die Account-Daten extrahieren, in ein JSON packen und mitschicken. Bei einem WebViewer-Aufruf (`view.php?...`) geht das nicht — der WebViewer kann nur GET-URLs absetzen, ohne JSON-Body. **B) Session-basiert** — Login-Endpoint, Session-Token, ablaufende Tokens. Sicher, aber erheblich mehr Code, vor allem auf FileMaker-Seite. Wir entschieden uns für eine dritte Variante, die in der Praxis am unauffälligsten ist: **Account-Cache in PHP, gefüllt aus FileMaker.** FileMaker pflegt die Mail-Accounts in einer eigenen Tabelle `TAB_MailAccount` (mit IMAP-Host, SMTP-Port, Username, Passwort, allem). Beim Speichern eines Accounts in FileMaker wird per Skript einmalig `POST /api/sync_account.php` aufgerufen. Der PHP-Server cached die Account-Daten in einer `data/accounts.json`. Ab dann reicht in jedem API-Aufruf eine `account_id` — PHP resolvt sie selbst. Vorteile: - FileMaker muss Credentials nur **einmal** synchronisieren, nicht bei jedem Klick. - HTML-Views (`view.php`, `attachment.php`) funktionieren mit GET-Parametern. - Die Quelle der Wahrheit bleibt FileMaker — `accounts.json` ist nur Cache. - Wechsel des Mail-Passworts: Wert in FileMaker ändern, Sync-Knopf, fertig. Kein Code-Deploy, kein PHP-Anfassen. Für die Authentifizierung selbst genügt ein **statischer Bearer-Token**, der in einer `.env` auf PHP-Seite und einer Custom Function `CF_API_Token` auf FileMaker-Seite hinterlegt ist. JWT wäre Overkill für eine Backoffice-Lösung. ## Threading: das eigentliche Herzstück Der ursprüngliche Wunsch — die Konversationen — bekam jetzt das passende Datenmodell. Vier neue Felder in `TAB_Mail`: | Feld | Zweck | |---|---| | `References` | Komma-getrennte Liste aller Vorgänger-Message-IDs aus dem RFC-5322-Header | | `thread_root_id` | Die Message-ID der Wurzel des Threads — alle Mails desselben Threads tragen denselben Wert | | `thread_depth` | Einrückungstiefe, 0 = Wurzel, sonst Vorgänger + 1 | | `thread_seq` | Sortierreihenfolge innerhalb des Threads (für später) | Plus drei **normalisierte Match-Felder** für die Self-Joins: ``` Kleinbuchstaben ( Trimme ( Substitute ( Message_ID ; [ "<" ; "" ] ; [ ">" ; "" ] ; [ " " ; "" ] ; [ "¶" ; "" ] ) ) ) ``` `Message_ID_norm`, `In_Reply_To_norm`, `thread_root_id_norm` — alle indiziert. Damit wird `` zu `[email protected]`, sauber gegen Großschreibung, Klammern, Whitespace. Drei Self-Join-TOs: | Tabellenokkurrenz | Beziehung | Liefert | |---|---|---| | `T34_mail_MAIL\|\|parent` | `In_Reply_To_norm = Message_ID_norm` | direkten Vorgänger (max. 1 DS) | | `T34_mail_MAIL\|\|replies` | `Message_ID_norm = In_Reply_To_norm` | alle Direkt-Antworten (0..n) | | `T34_mail_MAIL\|\|thread` | `thread_root_id_norm = thread_root_id_norm` | alle Mails desselben Threads | Das **Skript „Mail einreihen"** läuft nach jedem neuen Datensatz und kennt vier Regeln, in dieser Reihenfolge: 1. `In_Reply_To` leer → eigene Wurzel: `thread_root_id = Message_ID`, `thread_depth = 0` 2. Vorgänger ist über `T34_mail_MAIL||parent` erreichbar → erbe `thread_root_id` und setze `thread_depth = parent.depth + 1` 3. Vorgänger fehlt → Fallback auf erste ID aus `References` (per ExecuteSQL gegen `Message_ID_norm`) 4. Komplett verwaist → eigene Wurzel Was hier passiert, ist klassische Hierarchie-Synthese auf Datensatz-Ebene. Der Witz: das Skript läuft **ohne Mehrfach-Durchgänge** auf einem importierten Datensatz, weil der Vorgänger bei chronologischer Reihenfolge (älteste zuerst) bereits korrekt einsortiert war. Für den seltenen Fall, dass eine Antwort vor ihrem Vorgänger ankommt, gibt's das `Threading_Backfill`-Skript, das iterativ bis zur Konvergenz läuft. ## Die schönste Überraschung: kein Webserver nötig MailIT hatte einen lokalen HTTP-Server, der bei jedem FileMaker-Start auf einem konfigurierbaren Port hochfuhr. Zweck: Inline-Bilder in HTML-Mails (``) im WebViewer anzeigen können. Der WebViewer braucht eine URL — MailIT lieferte sie über `localhost:Port`. Das war wackelig: Port-Konflikte, fehlende Berechtigungen, der berühmte „Failed to start local web server"-Dialog. In unserer neuen Lösung war dieser ganze Webserver-Komplex schlicht **überflüssig**. Wir haben einen echten Webserver, auf dem der PHP-Mailclient ohnehin läuft. Inline-Bilder werden entweder direkt als `data:`-URLs ins HTML eingebettet oder über `attachment.php` ausgeliefert — der WebViewer holt sie sich wie jedes andere Bild. Allein dieses Detail würde eine Plugin-Migration rechtfertigen. Es waren zwei `Email_Send_*`-Felder weniger im Schema, eine ganze Skript-Sektion „Start/Stop Web Server" entfernt, und keine mysteriösen Port-Konflikte mehr. ## Eine ehrliche Falle: Auto-Eingabe-Berechnungen Drei Tage lang lief das System scheinbar perfekt. Dann fiel auf: nach jedem Mail-Abruf wurden die seit gestern gesendeten Mails wieder mit-importiert. Doppelt, dreifach. Der Doppel-Match auf `Message_ID_norm` griff nicht. Diagnose: das `Message_ID_norm`-Feld war bei neu angelegten Datensätzen **leer**. Warum? In FileMaker hat eine Auto-Eingabe-Berechnung standardmäßig die Option **„Vorhandenen Feldwert nicht ersetzen"** angehakt. Das klingt harmlos, ist aber tückisch: beim Anlegen eines neuen Datensatzes wird die Berechnung **einmal** ausgeführt — mit leerem Quellfeld. Ergebnis: leeres Norm-Feld. Wenn das Skript danach `Feldwert setzen [ Message_ID = "" ]` macht, greift die Berechnung **nicht mehr**, weil der Wert „schon vorhanden" ist (auch wenn er leer war). Lösung: Häkchen raus. Dann rechnet FM die Auto-Eingabe bei jeder Änderung am Quellfeld neu. Klassische Falle, von der man als FileMaker-Entwickler nie genug Schaden nehmen kann. ## Was am Ende stand Nach gut anderthalb Tagen Migration: - **MailIT komplett raus.** Keine Plugin-Abhängigkeit, keine Lizenzgebühren pro Client, keine plugin-spezifischen Skripte mehr. - **Plugin-frei auch im Mehr-Client-Betrieb.** Der PHP-Mailclient läuft einmal zentral. Mehrere FileMaker-Clients teilen ihn — auch FileMaker Server, WebDirect oder iOS Go funktionieren ohne Anpassung. - **Echtes Threading** mit Self-Joins, Einrückung, Reply-Indikatoren (↩/↪/↳) und einer Detail-Ansicht, die die ganze Konversation chronologisch zeigt. - **Multi-Account-fähig** ohne Code-Änderung. Accounts kommen aus FileMaker, neue Postfächer brauchen nur einen Datensatz. - **OAuth-ready** — die Architektur ist offen für XOAUTH2 (Gmail, Microsoft 365), wenn ein Kunde das braucht. Heute nicht aktiv, aber morgen kein Architektur-Eingriff mehr. - **Mehrere To-Empfänger** funktionieren sauber, ein- wie ausgehend. - **Robuste Anhang-Verarbeitung** über eindeutige `imap_folder + imap_uid + att_index`-Adressierung statt fragiler Message-ID-Suche. ## Lessons Learned Drei Sachen würde ich aus dieser Migration mitnehmen: **1. Plugin-Befreiung lohnt sich oft erst auf den zweiten Blick.** Der ursprüngliche Anlass (Threading) hätte auch innerhalb von MailIT mit Krücken gelöst werden können. Aber sobald man den Schritt einmal geht, fallen reihenweise andere Probleme weg, die man als „normal" akzeptiert hatte: der Webserver-Dialog, die Lizenzpflege, die Limitierung auf einen Account, die fehlende OAuth-Option. Eine Migration zahlt sich oft erst durch die Aufräumarbeit aus, die man nebenbei mitmacht. **2. Eine PHP-Bridge ist im FileMaker-Kosmos unterschätzt.** „Aus URL einfügen" mit cURL-Optionen ist mächtig — Bearer-Tokens, POST mit JSON-Body, alles geht. Wer mit FileMaker eine Datenquelle anbinden will, die kein klassisches Plugin hat (Stripe, GitHub, eine interne API), sollte den PHP-Sandwich-Ansatz im Hinterkopf haben. Schneller geschrieben als ein eigenes Plugin, einfacher zu testen, und unabhängig von der FileMaker-Version. **3. Normalisierte Match-Felder gehören in jedes Schema mit Fremd-IDs.** Egal ob Mail-IDs, Telefonnummern, IBANs, ISBN: das Original-Feld bleibt, ein `_norm`-Feld als indizierte Auto-Eingabe-Berechnung daneben, und der Match läuft darüber. Spart langfristig die seltsamen Bugs, bei denen ein User mal mit Großbuchstaben tippt und nichts gefunden wird. --- **Stack im Überblick:** - FileMaker 22 mit deutscher Lokalisierung - PHP 8.3 mit `webklex/php-imap` 5.x und `PHPMailer` 6.x - Apache als HTTP-Frontend - SQLite für die Mail-↔-FileMaker-Verknüpfung - Bearer-Token aus `.env`, Account-Cache in `data/accounts.json` - Keine Browser-Frameworks, kein npm, kein Build-Schritt **Code-Umfang nach der Migration:** - `mailclient/`: rund 1 200 Zeilen PHP, davon etwa die Hälfte aus dem Prototyp übernommen - FileMaker: 5 neue Skripte (`Mails abholen`, `Mail senden`, `Mail beantworten`, `Mail einreihen`, `Threading Backfill`), eine neue Tabelle (`TAB_MailAccount`), 7 neue Felder, 3 neue Beziehungen - Aufwand inklusive Schema-Refactor, PHP-Anpassungen und Tests: ungefähr zwölf Stunden, verteilt über drei Arbeitstage

#FileMaker PHP #IMAP Mail #Tricks #FileMaker

Mein dritter Artikel in diesem Jahr im FileMaker Magazin!

Es läuft gerade richtig gut: In der aktuellen Ausgabe des FileMaker Magazins ist bereits mein dritter Artikel in diesem Jahr erschienen! Diesmal geht es um "Per Spracheingabe in den Datensatz", eine Lösung, die Monteure und Außendienstmitarbeiter auch offline Aufträge per Sprache erfassen lässt. Die KI verwandelt das Gesprochene später automatisch in vollständige FileMaker-Datensätze mit verknüpften Datensätzen über Bezugstabellen hinweg. Nach 15 Jahren Pause vom Schreiben für das Magazin freut es mich besonders, dass ich dieses Jahr so richtig in Fahrt gekommen bin. Die Kombination aus FileMaker und KI bietet einfach unglaublich viele spannende Möglichkeiten, über die es sich zu berichten lohnt. Danke an die Redaktion für die Zusammenarbeit – und an alle Leser für das Interesse!

#KI #FileMaker #FileMaker PHP

KI-gestützte Datensatzerstellung in FileMaker: Als AddOn installierbar KI-gestützte Datensatzerstellung in FileMaker: Wenn Sprache zu Daten wird !!! (Das System wird als AddOn in ein bestehendes FileMaker-System integriert) Das Problem Jeder FileMaker-Entwickler kennt es: Daten erfassen ist mühsam. Besonders wenn Mitarbeiter unterwegs sind, offline arbeiten oder einfach keine Lust haben, Dutzende von Feldern auszufüllen. Was wäre, wenn man einfach sagen könnte: “Erstelle einen Auftrag für Pumpe austauschen bei Anlage 2666, Status in Planung, Kategorie Reparatur, im Mai, mit Notiz und Aufgabe für 3 Mitarbeiter” Und das System erstellt automatisch: ✅ Den Master-Datensatz (Auftrag) ✅ Verknüpfte Notizen ✅ Tasks mit Fristen ✅ Automatische Verknüpfungen zu bestehenden Objekten ✅ Alle Felder korrekt befüllt Genau das haben wir gebaut. Die Lösung: Ein intelligentes KI-Bridge-System Wir haben eine PHP-basierte Middleware entwickelt, die als Brücke zwischen FileMaker und Claude AI (Anthropic) funktioniert. Das Besondere: Das System ist vollständig konfigurierbar über FileMaker, ohne eine Zeile Code zu ändern. Die 3 Kern-Innovationen: Dynamisches Config-System Statt statischer Workflows werden alle Konfigurationen als JSON in FileMaker gepflegt: Welche Layouts verwendet werden Welche Felder verfügbar sind Welche Item-Typen (Notizen, Tasks, etc.) erstellt werden sollen Spezielle Anweisungen für die KI Diese Configs werden automatisch auf dem Server gespeichert und können von jedem Mitarbeiter wiederverwendet werden. Intelligente Config-Auswahl Das Geniale: Mitarbeiter müssen keine Config-ID mehr angeben. Das System analysiert ihren Text-Prompt automatisch: Bildschirmfoto 2025-10-30 um 17.26.57. Prompt: “Erstelle einen neuen Auftrag…” → System findet automatisch Config “Auftrag anlegen” → Lädt passende Feldnamen & Layouts → Führt aus Bildschirmfoto 2025-10-30 um 17.28.53. Über ein Keyword-Scoring-System werden Prompts mit gespeicherten Configs abgeglichen. Je mehr Keywords übereinstimmen, desto höher der Score. 3. Such- & Verknüpfungs-Engine Nicht nur Erstellen, auch Suchen! Das System kann: In bestehenden FileMaker-Datensätzen suchen (z.B. Anlage 2666) Relevante IDs extrahieren Automatisch mit neuen Datensätzen verknüpfen Bildschirmfoto 2025-10-30 um 17.29.19. Technische Highlights Intelligentes Field-Mapping Claude AI kennt FileMaker nicht. Aber unser System: Ruft dynamisch verfügbare Felder aus dem FileMaker-Layout ab Sendet sie als Prompt an Claude Claude befüllt nur existierende Felder Case-insensitive Matching (project_name → Project_Name) Automatische Datumskonvertierung (verschiedene Formate → FileMaker-Format) Filterung von AutoEnter/Calculation-Feldern Multi-Item-Support Ein Prompt kann mehrere Aktionen auslösen: { “master”: “Auftrag erstellen”, “items”: [ “Notiz anlegen”, “Task anlegen”, “Objekt zuordnen” ] } Jedes Item kann erstellen oder suchen – automatisch erkannt anhand von Keywords wie “zuordnen”, “verknüpfen”, “finde”. Das gibt der Mitarbeiter an: Erstelle einen neuen Auftrag und die Notiz -Teste mal die 1372- Der Auftragsname lautet Pumpe ist bald defekt und muss getauscht werden. Der Status lautet -In Planung-, die Kategorie heisst -Reparatur- Als Planungsmonat hinterlege den Mai. Die Anlage ist die 2666. Erstelle auch gleich eine Aufgabe dazu. Hinterlege das Product bzw. Objekt dazu. Für den Auftrag werden 3 Mitarbeiter benötigt. Prominente Prompt-Hierarchie FileMaker-User können spezielle Anweisungen mitgeben: 🎯 SPEZIELLE ANWEISUNGEN FÜR DEN MASTER:────────────────────────────────────────Planungsmonat immer als 12/2025 formatieren.Anlagennummer in Feld id_anlage eintragen.────────────────────────────────────────BEACHTE DIESE ANWEISUNGEN STRIKT! Diese werden Claude mit visueller Betonung präsentiert, sodass sie nicht übersehen werden. Use Cases aus der Praxis Szenario 1: Außendienst (Offline-First) Problem: Techniker ist vor Ort, kein Internet, notiert sich 10 Aufträge handschriftlich. Mit unserem System: Notizen in FMGo-App erfassen (offline) Bei Internet: Alle Prompts auf einmal absenden System erstellt automatisch alle Aufträge mit Notizen, Tasks, Verknüpfungen Techniker muss keine Felder ausfüllen Szenario 2: Multi-CRM Umgebung Problem: Firma hat mehrere CRM-Systeme (Vertrieb, Service, Projekte). Mit unserem System: Configs: crm_vertrieb_firma, service_auftrag, projekt_anlegen Automatische Config-Erkennung je nach Prompt Ein System, mehrere Workflows Szenario 3: Sprachbarriere Problem: Internationale Teams, verschiedene Sprachen. Mit unserem System: Prompts in jeder Sprache möglich (Claude versteht 95+ Sprachen) FileMaker-Feldnamen bleiben gleich Nur die Config-Bezeichnung anpassen Performance & Kosten Geschwindigkeit Config-Laden: < 50ms (lokales JSON) Claude API: ~2-4 Sekunden (abhängig von Komplexität) FileMaker API: ~500ms pro Record Gesamt: 3-5 Sekunden für komplette Workflow-Ausführung API-Kosten (Claude Haiku) Input: ~$0.00025 pro 1K Tokens Output: ~$0.00125 pro 1K Tokens Durchschnitt: ~$0.01-0.03 pro Prompt → Selbst bei 1000 Prompts/Tag: ~$10-30/Monat Sicherheit & Datenschutz ✅ Kein Datenleck: Nur Feldnamen (nicht Werte) werden im Prompt sichtbar ✅ Verschlüsselte Verbindung: HTTPS zu Claude API ✅ On-Premise möglich: Bei Bedarf mit lokaler AI (z.B. Ollama) ✅ Config-Zugriffskontrolle: FileMaker-Berechtigungen greifen Technik: Frontend: FileMaker Pro/Go Middleware: PHP 8.x (FileMaker Data API + Anthropic API) AI: Claude 3 Haiku (Anthropic) Storage: JSON-Configs (dateisystembasiert)

#FileMaker #KI #FileMaker PHP

Neues Feature: Gap-Report für ZUGFeRD-Mapping (Prüfung auf fehlende Felder)

# Neues Feature: Gap-Report für ZUGFeRD-Mapping Unser **KI-gestütztes ZUGFeRD-Mapping** hat ein neues Feature bekommen, das die Arbeit noch einfacher macht! ## Das Problem Die KI mappt automatisch ~90% der ZUGFeRD-Felder. Aber was ist mit den **fehlenden 10%**? Bisher musste man selbst herausfinden, welche Felder in FileMaker noch fehlen und wie man sie anlegt. ## Die Lösung: Gap-Report Ab sofort erstellt die KI einen **detaillierten Gap-Report** für alle fehlenden Felder: ### Was der Gap-Report liefert: ✅ **Welches Feld fehlt** (z.B. `invoiceCurrencyCode`) ✅ **ZUGFeRD-Code** (z.B. BT-5) ✅ **Beschreibung** (was bedeutet das Feld?) ✅ **Pflicht oder Optional?** (Priorität HOCH/NIEDRIG) ✅ **Konkrete Empfehlung** für FileMaker ✅ **Beispielwerte** zur Orientierung ### Beispiel: ``` ❌ invoiceCurrencyCode (BT-5) - PFLICHT Beschreibung: Währungscode der Rechnung Empfehlung: Textfeld mit Werteliste (EUR, USD, CHF, GBP) Beispiel: EUR ❌ unitCode (BT-130) - PFLICHT Beschreibung: Einheitencode (UN/ECE) Empfehlung: Textfeld mit Werteliste (C62, HUR, MTR, KGM, LTR) Beispiel: C62 (Stück), HUR (Stunden) ℹ️ deliveryTerms (BT-20) - Optional Beschreibung: Lieferbedingungen (IncoTerms) Empfehlung: Textfeld mit Werteliste (EXW, FOB, CIF, DAP, DDP) Beispiel: DAP ``` ## Vorteile **Vorher:** "15 Felder fehlen" - und jetzt? **Nachher:** Konkrete Schritt-für-Schritt-Anleitung, was genau anzulegen ist. Perfekt für **FileMaker-Entwickler ohne ZUGFeRD-Kenntnisse**! ## Fazit Das KI-Mapping wird immer intelligenter. Nicht nur automatisch mappen, sondern auch **aktiv beim Nacharbeiten helfen**. ZUGFeRD-Compliance wird zum Kinderspiel. --- **Update:** Oktober 2025 **Feature:** Gap-Report mit konkreten FileMaker-Empfehlungen **Status:** Live #FileMaker #ZUGFeRD #KI #Automatisierung #ERechnung

#FileMaker #ZUGFeRD #FileMaker PHP #KI

Unser ZUGFeRD AddOn erhält ein Update

Im Zuge der Zusammenarbeit mit dem geschätzten Entwickler Alexander Lemuth haben wir in den letzten 2 Wochen etliche spannende Änderungen und Verbesserungen vorgenommen. Ursprünglich war geplant, die Implementierung gemeinsam per Zoom durchzuführen. Doch wie es oft bei guter Zusammenarbeit der Fall ist: während der intensiven Auseinandersetzung mit der bestehenden Lösung sind uns immer mehr interessante Details und Optimierungsmöglichkeiten aufgefallen. Was als einfaches Update beginnen sollte, entwickelte sich zu einer grundlegenden Überarbeitung. Die kritischen Fragen von Alexander und seine praktischen Anforderungen haben uns dazu gebracht, tiefer zu graben und das FM ZUGFeRD AddOn kräftig zu überarbeiten. Das Ergebnis ist Version 2.0, eine deutlich flexiblere, intuitivere und mächtigere Lösung, die wir ohne diesen produktiven Austausch nie erreicht hätten. Ein herzliches Dankeschön an dieser Stelle an Alexander für die konstruktiven Impulse, die geduldigen Tests und das ehrliche Feedback! # FM ZUGFeRD 2.0 – Die Evolution der elektronischen Rechnungsstellung in FileMaker Die elektronische Rechnungsstellung wird in Deutschland und Europa zunehmend zur Pflicht. Mit **FM ZUGFeRD 2.0** präsentieren wir die nächste Generation unseres AddOns für FileMaker – komplett überarbeitet, intuitiver und flexibler als je zuvor. ## Was ist neu? Die wichtigsten Features im Überblick ### 🎯 1. Flexible Primärschlüssel-Zuordnung Endlich: **Abweichende Primärschlüssel** für maximale Flexibilität! Nicht jede FileMaker-Lösung nutzt standardisierte Primärschlüssel. Mit der neuen Funktion können Sie für jeden Bereich (Seller, Buyer, Invoice, Items) einen **alternativen Primärschlüssel** definieren. **Was bedeutet das für Sie?** - Keine Anpassung Ihrer bestehenden Datenstruktur nötig - Volle Kontrolle über die Datenzuordnung - Nahtlose Integration in Ihre vorhandene FileMaker-Lösung **So funktioniert's:** Ein einfacher Dialog ermöglicht die Auswahl eines abweichenden Identifikationsfeldes. Das System nutzt dann automatisch diesen alternativen Schlüssel für die Datenzuordnung – perfekt für komplexe Datenmodelle mit individuellen Beziehungsstrukturen. ### 🖨️ 2. Erweiterte Drucklayout-Verwaltung Die neue **Drucklayout-Funktion** bietet Ihnen volle Kontrolle über die Ausgabe Ihrer ZUGFeRD-Dokumente: **Zwei Ansichtsmodi:** - **Formularansicht**: Für detaillierte Einzelrechnungen mit allen Informationen - **Tabellenansicht**: Für kompakte Listenansichten und Sammelrechnungen **Intelligente Layout-Zuordnung:** - Separate Layouts für verschiedene Ausgabeformate - Flexible Feldzuordnung pro Ansicht - Automatische Anpassung an Ihre Corporate Identity Das bedeutet: **Einmal konfigurieren, mehrfach nutzen** – ohne ständige manuelle Anpassungen. ### 🎨 3. Überarbeitete Benutzeroberfläche Die komplette Oberfläche wurde von Grund auf neu gestaltet. **Moderne, intuitive Navigation** durch alle Konfigurationsbereiche: **9 übersichtliche Tabs:** 1. **Info** – Zentrale URL-Konfiguration für alle Endpunkte 2. **Payments** – Rechnungskopf und allgemeine Daten 3. **Buyer** – Käufer-/Kundendaten mit vollständiger Adressverwaltung 4. **Seller** – Verkäufer-/Firmendaten inkl. Steuer-IDs 5. **Finance** – Bankinformationen und Zahlungskonditionen 6. **Invoice** – Rechnungsbeträge, Steuern und Totalsummen 7. **Items** – Rechnungspositionen mit detaillierten Artikeldaten 8. **Print** – Drucklayout-Verwaltung für beide Ansichtsmodi 9. **Testen** – Integrierte Demo- und Validierungsfunktionen **Das neue Design punktet mit:** - Klarer visueller Hierarchie - Zweisprachigen Labels (Deutsch/English) - Kontextsensitiven Hilfetexten - Farblich gekennzeichneten Bereichen für schnellere Orientierung ### 🔄 4. Intelligentes Feld-Mapping Das Herzstück von FM ZUGFeRD: Die **automatisierte Feldzuordnung**. **Wie es funktioniert:** 1. **Layout wählen**: Dropdown-Auswahl Ihrer FileMaker-Tabellen 2. **Felder zuordnen**: Drag & Drop Ihrer FileMaker-Felder zu ZUGFeRD-Standardfeldern 3. **Validieren**: Automatische Prüfung auf Vollständigkeit und Konformität 4. **Testen**: Sofortige Vorschau der generierten Dokumente **Unterstützte Datenquellen:** - Beliebige FileMaker-Tabellen - Portal-Beziehungen für Positionsdaten - Berechnungsfelder für dynamische Werte - Globale Felder für Standardwerte ### 📋 5. EN 16931 Konformität garantiert Alle generierten ZUGFeRD-Dokumente entsprechen der **Europäischen Norm EN 16931** für elektronische Rechnungen. **Technische Details:** - **Format**: PDF/A-3 mit eingebettetem XML - **Profile**: BASIC, COMFORT, EXTENDED - **Standard**: ZUGFeRD 2.x / Factur-X - **Kompatibilität**: UBL (Universal Business Language) **Validierung in Echtzeit:** Das AddOn prüft kontinuierlich: - Pflichtfelder gemäß gewähltem Profil - Korrekte Datenformate (Datum, Währung, Steuersätze) - Konsistenz zwischen Positionen und Gesamtsummen - Gültige ISO-Codes für Länder, Währungen und Einheiten ### 🧪 6. Integrierte Test- und Demo-Funktionen Der neue **Testen-Tab** ist Ihr Playground für ZUGFeRD-Dokumente: **Demo-Funktionen:** - **Create ZUGFeRD Demo**: Erstellt Beispielrechnungen zum Testen - **Create UBL Demo**: Generiert UBL-Testdokumente - **Read ZUGFeRD Demo**: Liest und analysiert vorhandene ZUGFeRD-Dateien - **Read UBL Demo**: Importiert UBL-Dokumente zur Validierung **Export/Import von Konfigurationen:** - Einstellungen exportieren für Backup oder Migration - Konfigurationen importieren zwischen Test- und Produktivumgebungen - Versionierung Ihrer Mapping-Definitionen **Live-Vorschau:** Zwei Container zeigen in Echtzeit: - **XML-Container**: Die generierte ZUGFeRD-XML-Struktur - **PDF-Container**: Das finale PDF/A-3-Dokument mit eingebettetem XML ### 🌐 7. Nahtlose HTTP-Integration FM ZUGFeRD arbeitet mit **PHP-Scripten (local oder Server)** über standardisierte HTTP-Schnittstellen: **Der Workflow:** 1. FileMaker sendet Rechnungsdaten via POST an konfigurierten Endpoint 2. PHP-Service generiert ZUGFeRD-konforme Struktur 3. XML wird nach EN 16931 erstellt und validiert 4. PDF/A-3 wird mit eingebettetem XML erzeugt 5. Fertiges Dokument wird zum Download bereitgestellt 6. FileMaker lädt automatisch herunter und speichert in Container-Feld **Ihre Vorteile:** - Keine lokale PDF-Bibliothek erforderlich - Zentrale Verwaltung der Generierungslogik - Skalierbar für hohe Dokumentenvolumen - Einfache Updates der ZUGFeRD-Spezifikationen ### 📊 8. Präzise Steuerberechnung Die Steuerberechnung erfolgt auf **zwei Ebenen** – vollständig automatisiert: **Positionsebene:** Jede Rechnungsposition enthält: - Einzelpreis (netto) - Menge und Einheit - Steuersatz (%) - Steuerkategorie (S, Z, E, AE, ...) - Automatische Berechnung des Zeilentotals **Dokumentebene:** Automatische Aggregation zu: - Gesamtnettobetrag (Summe aller Positionen) - Steuerblöcke pro Steuersatz - Steuerbemessungsgrundlage pro Satz - Gesamtsteuerbetrag - Bruttoendbetrag **Wichtig:** Das System stellt sicher, dass Position- und Dokumentsummen immer konsistent sind! ## Praktische Anwendungsfälle ### Szenario 1: Standardrechnung mit 19% MwSt. ``` Artikel: "Beratungsdienstleistung" Menge: 8 Stunden Einzelpreis: 120,00 EUR (netto) Steuersatz: 19% → Netto: 960,00 EUR → MwSt.: 182,40 EUR → Brutto: 1.142,40 EUR ``` FM ZUGFeRD erstellt automatisch ein PDF/A-3 mit eingebettetem XML – bereit für die elektronische Übermittlung. ### Szenario 2: Rechnung mit mehreren Steuersätzen ``` Position 1: Bücher (7% MwSt.) → 100,00 EUR netto Position 2: Software (19% MwSt.) → 500,00 EUR netto → Steuerblock 7%: Basis 100,00 EUR, Steuer 7,00 EUR → Steuerblock 19%: Basis 500,00 EUR, Steuer 95,00 EUR → Gesamt: 702,00 EUR brutto ``` Das AddOn erstellt automatisch separate Steuerblöcke für jeden Satz – EN 16931 konform. ### Szenario 3: Grenzüberschreitende Rechnung (Reverse Charge) ``` Verkäufer: Deutschland (DE) Käufer: Österreich (AT) mit gültiger UID Steuerkategorie: AE (Reverse Charge) → Nettobetrag: 2.500,00 EUR → Steuersatz: 0% (Hinweis auf Reverse Charge) → Bruttobetrag: 2.500,00 EUR ``` Perfekt für B2B-Geschäfte innerhalb der EU. ## Best Practices für Ihre FileMaker-Lösung ### 1. Datenstruktur vorbereiten **Empfohlene Felder in Ihrer Rechnungstabelle:** - `rg_nummer` (Text): Eindeutige Rechnungsnummer - `rg_datum` (Datum): Rechnungsdatum im Format YYYY-MM-DD - `rg_faellig` (Datum): Fälligkeitsdatum - `rg_waehrung` (Text): ISO-Währungscode (EUR, USD, CHF, ...) - `rg_kunde_id` (Zahl): Fremdschlüssel zur Kundentabelle - `rg_netto` (Zahl): Nettosumme (berechnet) - `rg_steuer` (Zahl): Steuerbetrag (berechnet) - `rg_brutto` (Zahl): Bruttosumme (berechnet) ### 2. Berechnungsfelder nutzen **Steuerbetrag berechnen:** ``` Round ( rg_netto * 0.19 ; 2 ) ``` **Bruttobetrag berechnen:** ``` rg_netto + rg_steuer ``` **Aggregation von Positionen:** ``` Sum ( rg_positionen::pos_netto ) ``` ### 3. Validierung implementieren **Prüfen vor Export:** - Sind alle Pflichtfelder gefüllt? - Ist die USt-ID formal korrekt? - Stimmen Positions- und Kopfsummen überein? - Sind ISO-Codes korrekt (Land, Währung, Einheit)? **FileMaker-Skript Beispiel:** ``` If [ IsEmpty ( rg_nummer ) or IsEmpty ( rg_datum ) ] Show Custom Dialog [ "Fehler"; "Pflichtfelder fehlen!" ] Exit Script [ Text Result: False ] End If # ZUGFeRD Export starten Perform Script [ "ZUGFeRD - Export Rechnung" ] ``` ### 4. Layouts strukturieren **Empfohlene Layout-Struktur:** - **Formularansicht**: Vollständige Rechnung mit Header, Positionen, Footer - **Listenansicht**: Kompakte Positionsübersicht - **Druckansicht**: Formatiert für PDF-Export mit Corporate Design ### 5. Fehlerbehandlung einbauen **Typische Fehlerquellen:** - Leere Pflichtfelder - Ungültige Datumsformate - Falsche Währungscodes - Fehlende Beziehungen zu Stammdaten **Lösung:** Validierungs-Skripte vor dem Export ausführen! ## Technische Details für Entwickler ### Unterstützte Einheitencodes (UN/ECE Recommendation 20) Die wichtigsten Codes für den deutschen Markt: | Code | Bedeutung | Verwendung | |------|-----------|------------| | **C62** | Stück | Einzelne Artikel, Produkte | | **HUR** | Stunde | Dienstleistungen, Beratung | | **DAY** | Tag | Tagessätze, Miete | | **MTR** | Meter | Längenangaben, Textilien | | **MTK** | Quadratmeter | Flächen, Immobilien | | **MTQ** | Kubikmeter | Volumen, Baustoffe | | **KGM** | Kilogramm | Gewichtsangaben | | **TNE** | Tonne | Schwergewicht, Rohstoffe | | **LTR** | Liter | Flüssigkeiten | | **SET** | Set | Produktsets, Bundles | | **MON** | Monat | Abonnements, Mieten | ### Steuerkategorien nach EN 16931 | Code | Bedeutung | Anwendung | |------|-----------|-----------| | **S** | Standard rate | Regelsteuersatz (19% in DE) | | **AA** | Lower rate | Ermäßigter Satz (7% in DE) | | **Z** | Zero rated | 0% (z.B. innergemeinschaftlich) | | **E** | Exempt | Steuerbefreit (z.B. Kleinunternehmer) | | **AE** | Reverse charge | Umkehr der Steuerschuldnerschaft | | **K** | Intra-Community | Innergemeinschaftliche Lieferung | | **G** | Free export | Export außerhalb EU | | **O** | Outside scope | Nicht steuerbar | ### Rechnungstyp-Codes (UNTDID 1001) | Code | Typ | Verwendung | |------|-----|------------| | **380** | Commercial Invoice | Standardrechnung | | **381** | Credit Note | Gutschrift/Stornorechnung | | **384** | Corrected Invoice | Korrekturrechnung | | **389** | Self-billed Invoice | Gutschriftverfahren | | **751** | Invoice Information | Rechnungsinformation | ### Zahlungsarten (ISO 20022) | Code | Zahlungsart | |------|-------------| | **58** | SEPA-Überweisung | | **30** | Banküberweisung | | **48** | Kreditkarte | | **49** | Lastschrift | | **97** | Verrechnungsscheck | ## Lizenzierung und Support ### COMFORT-Version FM ZUGFeRD ist als **COMFORT-Version** lizenziert und bietet: - Vollständige EN 16931 Konformität - Alle ZUGFeRD 2.x Profile (BASIC, COMFORT, EXTENDED) - UBL-Unterstützung - Unbegrenzte Dokumentenerstellung - Professioneller Support ### Updates und Wartung - Regelmäßige Updates bei Änderungen der ZUGFeRD-Spezifikation - Anpassungen bei gesetzlichen Änderungen - Bug-Fixes und Optimierungen - Neue Features basierend auf Kundenanforderungen ### Support-Kanäle - E-Mail Support: [email protected] - Dokumentation: Wiki mit ausführlichen Anleitungen - Video-Tutorials: Schritt-für-Schritt Konfiguration - Community-Forum: Austausch mit anderen Nutzern ## Migration von älteren Versionen ### Von FM ZUGFeRD 1.x auf 2.0 Die Migration ist einfach: 1. **Backup erstellen**: Sichern Sie Ihre aktuelle Konfiguration 2. **Export Settings**: Exportieren Sie Ihre Feldzuordnungen 3. **Update installieren**: Neue AddOn-Version in FileMaker laden 4. **Import Settings**: Importieren Sie Ihre gespeicherte Konfiguration 5. **Test durchführen**: Erstellen Sie Test-Dokumente zur Validierung **Was bleibt erhalten:** - Alle Feldzuordnungen - URL-Konfigurationen - Layout-Einstellungen **Was ist neu zu konfigurieren:** - Drucklayout-Zuordnungen (neue Funktion) - Alternative Primärschlüssel (falls gewünscht) ## Roadmap: Was kommt als Nächstes? Wir arbeiten bereits an weiteren Verbesserungen: ### Geplante Features (Q2-Q4 2025) - 🔄 **Batch-Verarbeitung**: Mehrere Rechnungen auf einmal exportieren - 📧 **E-Mail-Integration**: Direktversand via FM MailBridge AddOn - 🗄️ **Archivierung**: Automatisches Ablegen in revisionssicheren Archiven - 📱 **Mobile Optimierung**: Rechnungserstellung auf iPad - 🤖 **KI-Unterstützung**: Automatische Felderkennung beim Import - 🌍 **Weitere Formate**: X-Rechnung, Peppol BIS - 📊 **Analytics**: Reporting und Statistiken über ZUGFeRD-Nutzung ## Fazit: Bereit für die E-Rechnungs-Pflicht Mit **FM ZUGFeRD 2.0** sind Sie bestens gerüstet für die elektronische Rechnungsstellung: ✅ **Rechtskonform**: EN 16931 zertifiziert ✅ **Flexibel**: Passt sich Ihrer FileMaker-Lösung an ✅ **Intuitiv**: Moderne, übersichtliche Benutzeroberfläche ✅ **Zuverlässig**: Validierung in Echtzeit ✅ **Zukunftssicher**: Regelmäßige Updates und Erweiterungen ### Ab sofort verfügbar! **Jetzt informieren:** - 📧 E-Mail: [email protected] - 🌐 Web: www.filemaker-experts.de - 📞 Telefon: +49 (0) 176 3130 9949 --- *Hinweis: Ab 2025 wird die E-Rechnung in Deutschland für B2B-Transaktionen schrittweise verpflichtend. Mit FM ZUGFeRD erfüllen Sie alle gesetzlichen Anforderungen – heute schon für morgen bereit.* **#FileMaker #ZUGFeRD #ERechnung #DigitaleTransformation #Automatisierung**

#FileMaker #ZUGFeRD #FileMaker PHP

ZUGFeRD mit eigenem PDF-Layout, endlich pragmatisch gelöst

Monate lang stand ich vor dem gleichen Problem: Die PHP-Bibliothek horstoeko/zugferd erzeugt zuverlässig die ZUGFeRD-XML, möchte aber idealerweise, dass man das sichtbare PDF mit FPDF neu aufbaut. Für standardisierte Rechnungen ist das akzeptabel; für gewachsene Corporate-Designs mit sauber gesetzten Typografien, Logos, farbigen Flächen und komplexeren Kopf-/Fußbereichen ist es schlicht unpraktikabel. Mein Ziel war daher, ein beliebiges, bereits perfektes Template-PDF (aus FileMaker, InDesign, Word oder einem anderen System) weiterzuverwenden und ausschließlich die ZUGFeRD-XML sauber zu integrieren – ohne das Layout neu zu programmieren. Ausgangsproblem – warum der reine FPDF-Weg nicht reicht Sobald es um reale Layouts geht, wird der FPDF-Weg schnell mühsam: Spaltenbreiten, Zeilenabstände, Schriften, Positionierungen, Logos, CI-Farben – alles muss mühsam nachgebaut werden, obwohl das Layout als fertige PDF längst existiert. Hinzu kommt, dass einzelne PDFs wegen Kompressionsarten, PDF-Versionen oder Producer-Spezifika von FPDI nicht immer direkt importierbar sind. Das kostet Zeit, Nerven und bringt keinen fachlichen Mehrwert, wenn das Ziel schlicht „bestehendes Layout beibehalten, ZUGFeRD einbetten“ heißt. Die Lösung – Template-PDF nutzen, ZUGFeRD einbetten, robustes Fallback Ich habe ein Template-System mit mehrstufigem Fallback gebaut, das vorhandene PDFs bevorzugt, FPDI nur nutzt, wenn es geht, andernfalls automatisiert konvertiert oder, falls nötig, das Template schlicht als Basis kopiert und anschließend die ZUGFeRD-XML einbettet. Die ZUGFeRD-Erzeugung bleibt sauber im ZugferdDocumentBuilder, das Einbetten erfolgt mit ZugferdDocumentPdfBuilder::fromPdfFile(…). Ergebnis: Das Layout bleibt 1:1 erhalten, und die PDF wird ZUGFeRD-konform. Kernpunkte des Ansatzes: • Automatische Template-Erkennung im templates/-Ordner, optional mit layout_config.json für kleinere Koordinaten-/Schrift-Tweaks (falls man doch etwas übersteuern möchte). • Mehrstufiger FPDI-Fallback: Direktimport → Konvertierung (Ghostscript) → sichere Kopie. • Robustes Error-Handling & Logging: Jede Stufe wird sauber protokolliert, inklusive Dateigrößen, Rückgaben und etwaigen Ausnahmen. • Saubere Trennung der Verantwortlichkeiten: Der Builder erzeugt die XML; der PDF-Builder fügt sie einem bestehenden PDF hinzu; FPDF kommt nur noch dann zum Einsatz, wenn wirklich ein Basispapier benötigt wird. Technischer Ablauf – von Template bis ZUGFeRD-PDF 1. Template laden oder Standard-PDF erzeugen (Upload aus FileMaker per aus URL einfügen) Im Projektverzeichnis liegt ein templates/-Ordner. Dort wird automatisch die erste passende PDF als Template ausgewählt. Deshalb wird die Rechnung immer als template.pdf hochgeladen. Möglich ist auch dort schon die Rechnugs-PDF mit eigenem Datei-Namen zu versehen. Dies ist aber nicht notwendig. Ist FPDI verfügbar und kann das Template öffnen, wird die Seite importiert. Schlägt dies wegen Kompressionsdetails fehl, versucht das System eine Konvertierung (via Ghostscript) und importiert erneut. Misslingt auch das, wird das Template als Datei kopiert und danach direkt mit XML versehen. Nur wenn überhaupt kein Template vorhanden/geeignet ist, wird minimal mit FPDF eine neutrale Seite gebaut. 2. ZUGFeRD-XML generieren Die fachlichen Rechnungsdaten kommen wie gehabt per POST (Rechnungsnummer, Datum, Positionen, Summen, Steuerblöcke, Zahlungsbedingungen etc.). Daraus wird mit ZugferdDocumentBuilder die EN16931-konforme XML erzeugt. 3. XML in PDF integrieren Mit ZugferdDocumentPdfBuilder::fromPdfFile($document, $tempPdfPath) wird die XML in das vorbereitete PDF geschrieben und als finale ZUGFeRD-PDF gespeichert. Ausschnitt: Template-Erkennung mit mehrstufigem Fallback Im folgenden Ausschnitt ist das Prinzip komprimiert dargestellt. Beachten: Kommentare sind bewusst ausführlich, da sie beim späteren Debuggen Gold wert sind.

// Template-PDF automatisch erkennen $templatesDir = __DIR__ . '/templates/'; $templatePdfs = glob($templatesDir . '*.pdf'); if (!empty($templatePdfs)) { $templatePdf = $templatePdfs[0]; try { // Versuch 1: FPDI nutzen (falls verfügbar) if (!class_exists('Fpdi')) { throw new Exception('FPDI-Klasse nicht verfügbar'); } $pdf = new Fpdi(); $pageCount = $pdf->setSourceFile($templatePdf); $tpl = $pdf->importPage(1); $pdf->AddPage(); $pdf->useTemplate($tpl, 0, 0); // Als temporäre Basis speichern $pdf->Output('F', $tempPdfPath); // -> ab hier geht es direkt zum Einbetten der XML } catch (Exception $e) { // Versuch 2: PDF kompatibel machen und erneut probieren $converted = $templatesDir . 'converted_template.pdf'; if (convertPdfForFpdi($templatePdf, $converted)) { try { $pdf = new Fpdi(); $pageCount = $pdf->setSourceFile($converted); $tpl = $pdf->importPage(1); $pdf->AddPage(); $pdf->useTemplate($tpl, 0, 0); $pdf->Output('F', $tempPdfPath); @unlink($converted); } catch (Exception $e2) { @unlink($converted); // Versuch 3: Direkte Kopie als Fallback copy($templatePdf, $tempPdfPath); } } else { // Falls Konvertierung nicht möglich: Direkte Kopie copy($templatePdf, $tempPdfPath); } } } else { // Kein Template gefunden -> neutrale FPDF-Seite als Minimalbasis $pdf = new FPDF(); $pdf->AddPage(); // Optional: Logo/Absender, wenn gewünscht; ansonsten blank lassen // $pdf->Image('logo.png', 20, 10, 30, 15); $pdf->Output('F', $tempPdfPath); }

Konvertierung für FPDI-Kompatibilität Manche PDFs scheitern an der Importhürde wegen Kompressionsart oder PDF-Version. Ich reiche deshalb (falls vorhanden) eine Ghostscript-Konvertierung vor. Der Code ist so geschrieben, dass er ohne Ghostscript nicht abstürzt, sondern sauber weiter macht.

XML erzeugen und in bestehendes PDF einbetten Der entscheidende Schritt: Wir nutzen die Stärke der Bibliothek – die XML-Erzeugung – und vermeiden, das Layout neu bauen zu müssen. Dazu erstellen wir den ZugferdDocumentBuilder, setzen alle Pflicht- und optionalen Felder (Dokumenttyp, Beträge, Steuern, Zahlungsbedingungen etc.) und übergeben dieses Dokument anschließend an den PDF-Builder.

// 1) ZUGFeRD-XML vorbereiten $document = ZugferdDocumentBuilder::createNew(ZugferdProfiles::PROFILE_EN16931); $document->setDocumentInformation($invoiceNumber, $invoiceTypeCode, new DateTime($invoiceDate), $currency); // Summation/Steuerblöcke etc. setzen ... // $document->setDocumentSummation(...); // $document->addDocumentTax(...); // $document->addDocumentPaymentMeanToCreditTransfer(...); // 2) XML in das vorhandene (Template-)PDF einbetten $pdfBuilder = ZugferdDocumentPdfBuilder::fromPdfFile($document, $tempPdfPath); $pdfBuilder->generateDocument(); $pdfBuilder->saveDocument($outputPath);

Template-Konfiguration: optional, klein, hilfreich Damit ich bei Bedarf Kleinigkeiten ohne neues Template anfassen kann, lese ich eine layout_config.json ein. Sie enthält vor allem Koordinaten und Schriftgrößen für Textbausteine, die ich optional über FPDF ergänze (z. B. Adressblock, Infospalte, Summenfeld) – praktisch, falls Kundenvarianten leichte Unterschiede verlangen, aber kein komplett eigenes Template rechtfertigen. Beispielhafte Keys (gekürzt): page_width, margin_left, sender_start_x, right_column_label_x, document_type_y, table_start_y, default_font, header_bg_color, summary_label_x, template_pdf. Fehlt die Datei, läuft das System mit vernünftigen Standardwerten weiter – der ZUGFeRD-Teil ist davon ohnehin unabhängig. Logging und Fehlertoleranz Alle wesentlichen Schritte werden in uploads/zugferd_log.txt mit Zeitstempel geloggt: Welche Stufe gegriffen hat, Dateigrößen vor/nach Verarbeitung, gefundene Templates, etwaige Exceptions inklusive Trace. Damit sind Fehlersuche und spätere Betriebsbeobachtung unaufwendig. Auch wenn FPDI oder Ghostscript nicht verfügbar sind, bleibt das System funktionsfähig, da es am Ende immer auf die „Kopie + Einbettung“-Strategie zurückfällt. Was bleibt von FPDF? FPDF bleibt im Projekt lediglich als Minimal-Fallback oder für sehr kleine Ergänzungen (z. B. dynamischer Hinweistext) erhalten. Logos, Balken, CI-Elemente usw. kommen aus dem Template, so wie es sein soll. Fazit Statt aufwendig ein bestehendes Corporate-Design in FPDF nachzubauen, nutze ich jetzt vorhandene PDFs die in FileMaker erzeugt werden unverändert und lasse lediglich die ZUGFeRD-XML sauber einbetten. Die Kombination aus Template-Erkennung, FPDI-Fallback, optionaler Konvertierung und konsequentem Error-Handling führt zu einem robusten, praxistauglichen Workflow: Template bzw. die aktuelle Rechnung hochladen, Daten senden, fertige ZUGFeRD-PDF erhalten. Wenn Sie bereits ein gutes Rechnungslayout in FileMaker haben und nur „ZUGFeRD dazu“ brauchen, ist dieser Ansatz die pragmatische Abkürzung.

#ZUGFeRD #FileMaker #FileMaker PHP