Comments (7)
Offene Frage gemäss Mail 17.10.22:
- 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)?
- 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?
from hitobito_die_mitte.
Danke für die Fragen Oli!
- 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)
- 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!
from hitobito_die_mitte.
Können wir dies nicht im Core umsetzten? Dies ist immer wieder ein Thema bei Kunden.
from hitobito_die_mitte.
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.
from hitobito_die_mitte.
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.
from hitobito_die_mitte.
Zwei Fragen zu diesem Vorschlag:
- Was machen wir mit alten Rechnungen die die separaten Felder noch nicht befüllt haben?
- 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.
from hitobito_die_mitte.
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?
from hitobito_die_mitte.
Related Issues (20)
- MESSAGE: Export von Spendenbestätigung HOT 2
- MESSAGES: Spendenbestätigung als eigener Brieftyp HOT 1
- MESSAGES: Schriftgrösse im PDF anpassen HOT 1
- INVOICE: Anreden
- PERSON: Berechtigungssystem HOT 3
- PERSON: Übersetzte Rollen Labels mergen
- EXPORT: Nur ausgewählte Rollen exportieren HOT 4
- INVOICES: Sortierung Rechnungsbriefe
- INVOICES: Anpassung Formel Bisherspenden HOT 1
- INVOICES: 360° Sicht HOT 3
- EBICS: Umgang mit nicht zuweisbaren Zahlungen HOT 3
- INVOICE: Nichtzuweisbare Zahlungen rückwirkend abholen
- INVOICES: Analyse Differenz zwischen allen per EBICS empfangen Zahlungen und der DB HOT 1
- INVOICE: Rechnungsadresse links/rechts ausrichten
- PEOPLE: Nur relevante Rollen exportieren
- RECHNUNGEN: Keine 0.- Rechnungen bei Spendenbestätigung und Bisherspender
- PEOPLE: complete_finance Permission für IT-Support/Leitung vs. performance HOT 1
- Korrespondenzssprache: Personenfilter & Globale Bedingungen auf Abonement HOT 1
- EXPORT: Identifikationsnummer aufnehmen HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from hitobito_die_mitte.