Überarbeitung Adressen

[andyundso]

Reporter: Andi

---

Um alle Adressen ins Dime sauber aufzunehmen, soll die bestehende Struktur mit den Kunden / Adressen überarbeitet werden.

Neu:

• Bei der Erfassung kann angegeben werden, ob es eine Einzelperson oder eine Firma ist.
• Bei einer Firma können allgemeine Daten abgefüllt werden (Adresse, Hauptnummer etc.) und mehrere Ansprechspersonen zugewiesen werden.
• Bei einer Einzelperson können keine Ansprechspersonen zugewiesen werden.
• Bei der Erstellung einer Offerte / Projekt / Rechnung kann, wenn eine Firma ausgewählt wird, eine Ansprechsperson ausgewählt werden.

Abklären:

• Umsetzung Datenbankstruktur für diese neue Konstellation.
• Umsetzung Migration bestehende Kundentabelle (Export, Excel-Tabelle, Import?)
• Bestehende Beziehungen zwischen der Kundentabelle sowie den angehängten Tabellen überprüfen: wo könnten Stolpersteine bestehen? Was muss neu geknüpft werden?

[andyundso]

Das wäre die Idee fürs Datenbankschema:

Abklären mit Andi:

• Wird es zukünftig das Szenario geben, dass Rechnungen oder Offerten an eine Firma gesendet werden und nicht an eine Ansprechsperson?

Umsetzung Migration:

• Bestehende Dime-Customers-Tabelle wird im Schema belassen, und dann die Daten händisch durch die Büro-Zivis übernommen.
• Bestehende Beziehungen zu Offerten, Projekte und Rechnungen werden belassen, und die Daten händisch oder via Skript durch die Büro-Zivis angepasst.
• Der Kunden-Import wird so angepasst, dass deklariert wird, ob es sich um die Daten in der Zeile um eine Einzelperson, um eine Firma oder um eine Ansprechsperson handelt.

[jonixis]

[andyundso]

Ein erste Version ist nun auf dem Test-System. Es gibt aber noch einige TODOs:

• [x] AbstractCustomer als Single-Table-Inheritance einrichten, und Company und Person als eigene Entität belassen. So können die 50%-Checks bei Phone und Address entfernt werden und es ist dennoch möglich, gewisse Dinge individuell zu betrachten (z.B. Firma muss eine RateGroup haben, während die Person nur eine bracht, wenn sie eine Firma hat). API-Endpunkte mit "companies" und "persons" belassen.
• [x] Firmen können Person hinzugefügt werden, welche bereits existieren, jedoch keine Firma zugewiesen haben.
• [x] Umkehrfunktion: Personen können aus Firmen gelöst werden.
• [x] Beschreibung zu Adressen hinzufügen: Bereits nach zwei Adressen kann es verwirrend sein, was nun genau an welcher Adresse passiert.
• [x] Alias, Chargeable und SystemCustomer wieder implementieren.
• [x] Adressen Import / Export aus #136 und die Tags-Relation wieder implementieren. Dazu das CSV so verändern, dass Einzelpersonen, Firmen und Personen von Firmen sauber unterschieden werden können.
• [x] Anpassen der Entities, welche Verbindungen zu der Kundentabelle oder den alten Adressen haben.
• [x] Migration bestehende Kunden: Jeder Kunde und seine Adresse wird als neue Person erfasst (Im Nachnamen vermerken, dass der Kunde "migriert" wurde, damit man nach dem Update einfach die Kundentabelle überprüfen kann). Danach Offerten / Rechnungen / Rechnungen checken, ob dort die Adresse von der Haupt-Adresse des Kunden abweicht, wenn ja, als neue Adresse erfassen. Möglichkeit im UI anbieten, dann die Einzelpersonen zu Firmen zu "befördern".
• [x] Invoice und Project haben derzeit keine Address-Property, dies wäre nun möglich.
• [x] Überprüfen, dass alle neuen PHP-Sachen Tests enthalten.

[andyundso]

Nachfragen bei Andi:

• [x] Export Adressen: Für was brauchen wir Exports?

[andyundso]

Feature ist nun soweit fertig mit den letzten Überarbeitungen, folgende Schritte gibt es noch zum Abschluss:

• [ ] Feedback von Andi einholen.
• [ ] Feedback ggf. von Alex einholen (Andi fragen ob nötig).
• [ ] Import-Datei vorbereiten (etwa 50 Firmen und 50 Personen) und auf Dime-Test importieren, importierte Daten auf Vollständigkeit und Korrektheit prüfen.
• [ ] Pull-Request #178 nach Code Review von Dani über Squash + Merge in master übernehmen, FF-Merge auf production von master vornehmen.
• [ ] Kunden-Migrationsskript anstossen (app/console customers:migrate).
• [ ] Information an SWO-Mitarbeitende über die Änderungen (speziell, dass alle vorherig erfassten Kunden als "Migriert" erfasst sind und man diese Angaben, wenn man etwas im Zusammenhang mit diesem Kunden verändert, doch gleich prüfen solle).

Folgende Datensätze nach Migration prüfen

• Projekt 314 auf Firmenkunde 4 (ALN) ändern.
• Projekt 558 auf Firmenkunde 4 (ALN) ändern.
• Rechnung 303 auf Firmenkunde 4 (ALN) ändern.
• Rechnung 304 auf Firmenkunde 4 (ALN) ändern und Person 154 löschen.
• Person 138 (Geschäftshaus City) zu Firma umwandeln.
• Person 74 (Zürcher Blumenbörse) zu Firma umwandeln.
• Person 1 (SWO) zu Firma umwandeln.
• Person 158 (Tiefbauamt) zu Firma umwandeln.

Nachdem die Änderungen mehrere Wochen live und stabil sind, kann die alte Kunden-Entität aus dem Backend entfernt werden:

• [ ] Entity / FormType / Controller / AliceDataSet / Tests / etc. löschen.
• [ ] OldCustomer und OldAddress von Invoice / Project / Offer / .. entfernen.
• [ ] MigrateCustomerCommand entfernen.
• [ ] Neue Doctrine-Migration erstellen, um die dazugehörigen Tabellen und Spalten zu löschen.
• [ ] Neue Doctrine-Migration erstellen, um die "Customer"-Tabelle zu "customers" umzuschreiben und "new_customers_tags" zu "customers_tags".

[andyundso]

Migration wird nun über das Migrationsskript für das neue Dime gehandelt (https://github.com/stiftungswo/DimeMigration/blob/master/EntityMigrator/CustomerMigrator.php).