PEOPLE: Rechnungsexport mit zusätzlichen Attributen und Standardsortierung

[mlue00]

PEOPLE: Rechnungsexport mit zusätzlichen Attributen und Standardsortierung

[olibrian]

Offene Frage gemäss Mail 17.10.22:

1. Sämtliche eurer Exportierten Listen sollen automatisch nach dem Nachnamen sortiert sein. Ist es korrekt, dass dies sämtliche Listen betreffen soll, egal aus welcher Ansicht man diese Exportiert, mit der Ausnahme von Haushaltslisten (Personenlisten, Eventslisten, Rechnungslisten,etc)?
2. Der Rechnungsexport soll um diverse Attribute ergänzt werden.
   Neue Attribute: Vornamen, Nachnamen, Firmennamen, Firma, Adresse, PLZ, Ort, Land. (Aus Datenschutzgründen empfehlen wir euch die folgenden Attribute nicht im Rechnungsexport sichtbar zu machen, da man den Rechnungsexport auch über Personen machen kann, auf welche man sonnst keine Sicht hat: Geschlecht, Geburtstag, Anrede, Haupt-E-Mail, Titel, Korrespondenzsprache, Wohnt in einem Haushalt)
   Ist das so für euch in Ordnung, dass der Export nur um diese Felder erweitert wird?
   Auf der Rechnung wird die komplette Adresse in ein Feld geschrieben. Um im Export diese Felder wieder separat aufzulisten, würde dieser Export auf die Personendatensätze zurückgreifen. Ist eine Person in der Zeit zwischen Rechnungsstellung und Export umgezogen, findet der Rechnungsexport die neue Adresse (Auf der Rechnung ist jedoch statisch die Adresse hinterlegt, welche zum Rechnungszeitpunkt gültig war.)
   Ist dieses Verhalten für euch so in Ordnung?

[StefZuegerDieMitte]

Danke für die Fragen Oli!

1. Ja, die Listen müssen nach Nachnamen sortiert werden können, egal woher sie exportiert werden. Idealerweise können auch Haushaltslisten nach Nachname sortiert werden, auch dies ist ein häufiger Use Case bei uns. Hier direkt eine Gegenfrage, wie man die Haushaltslisten nach Nachnamen sortieren könnte? (Eventuell über ein Zusätzliches Feld mit dem Nachnamen, und wenn zwei verschiedene eben beide)
2. Es geht hier nur darum, die Rechnung so auf dem CSV export zu haben, dass sie sortierbar ist. Dafür kann Feld G (Empfänger Adresse) in Vorname, Nachname, Firmenname, Firma, Adrese, PLZ, Ort, Land aufgeteilt werden. Die anderen Attribute brauchen wir nicht im Export. Auf der originalen Rechnung ist es kein Problem, wenn die Adresse so bleibt wie ursprünglich erstellt, dieses Verhalten ist so passend!

[olibrian]

Können wir dies nicht im Core umsetzten? Dies ist immer wieder ein Thema bei Kunden.

[carlobeltrame]

Nein, wenn wir es in der besprochenen minimalen Version umsetzen ist es ein Datenschutzproblem, weil Rechnungssteller und deren Nachfolger für immer die aktuelle Adresse der Empfänger einsehen können. Wenn wir stattdessen die Rechnungen umbauen würden, sodass das Adressfeld nicht mehr ein grosses Freitextfeld ist sondern separate Felder, dann könnten wir es im Core machen. Aber das hätte grössere Umbau-Auswirkungen, plus es wäre unklar, was mit den alten Rechnungen geschehen würde. Wenn die Mitte bereit ist, diesen Nachhaltigkeits-Umbau zu machen, dann gerne im Core.

[daniel-illi]

Ich sehe eine weitere Möglichkeit, wie das gewünschte Ergebnis mit Anpassungen im Core erreicht werden kann ohne die Datenschutzprobleme und ohne dass ein grösserer Umbau nötig wäre:

Auf der Rechnung speichern wir zu dem bestehenden Empfänger Freitextfeld zusätzlich die für den Export und die Sortierung benötigten Attribute.
Für die Darstellung der Rechnung verwenden wir wie bisher das bestehende Rechnungsempfänger Attribut.
Für den Export und das Sortieren verwenden wir die spezifischen Attribute.
Wenn der Rechnungssteller die Berechtigung auf den Rechnungsempfänger verliert, kann er trotzdem noch die alte Rechnung mit den zum Rechnungszeitpunkt gültigen Personendaten sehen.
Änderungen an den Daten des Rechnungsempfängers reflektieren sich nicht auf der Rechnung.

[carlobeltrame]

Zwei Fragen zu diesem Vorschlag:

1. Was machen wir mit alten Rechnungen die die separaten Felder noch nicht befüllt haben?
2. Was passiert wenn ein User eine Rechnung bearbeitet? Wie stellen wir sicher dass das zusammengefasste Adressfeld mit den einzelnen Spalten zusammenpasst? Müssen wir dann nicht auch das Bearbeitungsformular ändern sodass User die einzelnen Spalten bearbeiten können, und das kombinierte Adressfeld dann wieder neu zusammengesetzt werden kann? Und wenn wir so weit gehen, hat das kombinierte Adressfeld dann noch einen Sinn? Falls wir es entfernen, sind wir dann genau bei der aufwändigeren Core-Lösung die ich in Betracht gezogen habe: das kombinierte Adressfeld abschaffen und durch einzelne Felder ersetzen. Dann wird aber die Frage 1 umso wichtiger und schwieriger.

[mtnstar]

Wir streben an die Adressfelder wie auf der Person auch auf den Rechnungen so einzuführen:

Person: first_name, last_name, company_name, company (boolean), address, zip_code, town, country

Für neue Rechnungen neu als separate Felder welche recipient_address Feld ersetzen.

Alte Rechnungen werden als Legacy Rechnungen angesehen und verwenden das recipient_address Feld. Neue Rechnungen nur noch mit den neuen, einzelnen Feldern.

Folgende Bereiche müssen angepasst werden:

• InvoicesController export Etiketten (vereinfachung)
• MessageRecipient + Message Dispatch Job muss angepasst werden da wir dort heute auch nur ein Feld haben, DonationConfirmation
• Rechnungs API -> Feld recipient_address auch für neue Rechnungen ausgeben
• Tabular Export mit neuen und alten Rechnungen? Geht das ohne Probleme?

@olibrian kannst du bitte checken wie wir hier weiter fahren?