Ich würde gerne einen Serienbrief mit verschiedenen Daten erstellen.
Konkret soll das so aussehen:
Ein Tabellenblatt beinhaltet alle Adressen. Zu jeder Adresse existiert ein weiteres Tabellenblatt mit den zur Person zugehörigen Daten (z.B. bereits geleistete Zahlungen mit Datum, etc.). Nun soll ein Serienbrief erstellt werden, der im Adresskopf die Adressen aus der erste Tabelle und im Text die korrespondierenden Daten des zugehörigen Tabellenblattes enthält. Gibt es da eine Funktion, mit der man das erreichen kann? Oder muss dazu eine richtige Datenbank her?
Wie soll der Serienbrief die Zuordnung von Adresse zu Tabelle geregelt bekommen? Ein Writer-Serienbrief kann immer nur einen Datensatz einer Datenquelle auf einmal darstellen. Das ist bei Adressetiketten genau das gleiche. Da wird dann einfach bei dem 2. Adressetikett der zweite Datensatz ausgegeben.
Dein Vorhaben klingt noch einem Bericht in einer Datenbank, Auch da musst Du für den ReportBuilder alle Daten in einer Tabelle haben. Allerdings kannst Du gruppieren und das wäre dann das, was mit Hilfe der Adresse passiert. Adresse in die Gruppe, zugehörige Zahlungen in den Detail-Bereich.
Mitlles Makros und Platzhaltern, zusätzlich dann Tabellen und einer Datenbank im Hintergrund geht das natürlich noch besser - nur ist das etwas aufwendig für den Anfang.
Stimmt. Die Zuordnung würde nur über einen Verweis gehen. Und dann wäre es halt echt eine Datenbank. In das Thema ReportBuilder muss ich mich aber noch einarbeiten. Danke auf jeden Fall für die schnelle Antwort!
Wenn ich das richtig verstehe willst Du vielleicht einen Fließtext mit Platzhaltern (Serienbrief) und dann eine zusätzliche Tabelle, also das, was einem ständig als Rechnung ins Haus flattert:
Betr: <Rechnungsnummer>
Sehr <Anrede> <Name>,
Anbei die ausstehenden Zahlungen für Monat <Monat>/<Jahr>
usw. und dann im Text eine Tabelle mit mehreren Zeilen,
die sich aber auf den konkreten Datensatz des Serienbriefes beziehen.
Datum | Rg-Nummer | Betrag
1.9.22 | 2022-98765 | 2123,74
5.9.22 | 2022-99451 | 1234,12
Ist das in etwa das, was Dir vorschwebt?Ganz genau. Und da im Datensatz relativ viele Werte sind möchte ich die Adresstabelle nicht unendlich breit machen.
Geschäftsdaten in einer Tabellenkalkulation zu speichern ist eine haarsträubende Unsitte, die abgesehen von der flachen Einstiegshürde ausschließlich Nachteile hat. Soviel erstmal dazu.
Bist Du Experimentierfreudig?
Ich habe hier eine Makrosammlung für diese Art von Dokument, wo ich irgendwann vor 2 Wochen aufgehört habe als es darum ging, eine Extension daraus zu bauen. Als Makrosammlung ist das ganze ein wenig blöd zu bedienen. Ich habe es noch nie mit Calc-Datenbanken getestet, aber prinzipiell sollte es funktionieren weil wir nur lesend auf die Datensätze von 2 getrennten Tabellen zugreifen.
- Du hast ein Writer-Dokument mit Serienbrieffeldern. Der Serienbrief funtioniert soweit.
- Im verbundenen Base-Dokument erstellst Du eine Parameter-Abfrage, wobei der oder die Parameter einen eindeutigen Datensatz des Serienbriefes identifizieren (z.B. Rechnungsnummer).
SELECT "A","B","C","D" FROM "Blatt2" WHERE "RG_NR" = :paramRG_NR
- In Deinem Serienbrief erstellst eine (oder mehr) Writer-Tabelle(n) mit 2 Zeilen, eine Kopfzeile und eine leere Datenzeile mit vorformatierten Zellen. Hier landen die Werte der Parameterabfrage, wobei der Parameter mit dem zugehörigen Wert aus dem Serienbrief ersetzt wird.
- Dann startest Du ein Makro, das die Verbindung für die Eingehenden Daten definiert, also Deine Parameterabfrage und das Serienbrieffeld, das den Parameter ausfüllen soll.
- Dann startest Du ein anderes Makro, das die Ausgabe-Optionen setzt. Beide Makros speichern diese Daten im Writer-Dokument für spätere Wiederverwendung.
- Schlussendlich startest Du ein drittes Makro, das den Serienbrief ausfüllt und dabei die zusätzliche Texttabelle(n) mit den jeweiligen Werten aus der Parameterabfrage füllt.
Ob das ganze wirklich funktioniert ist aus der Ferne überhaupt nicht einzuschätzen weil in Tabellenkalkulationen gewöhnlich ein ziemlicher inkonsistenter Datenmüll vorherrscht.