#filemaker php

'; }); ``` 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. ---

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

# 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

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

# 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

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

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.