View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000904 | Fakturama | Kontakte (Contacts) | public | 2020-10-08 16:00 | 2023-01-19 22:41 |
Reporter | Pedestrian | Assigned To | rheydenr | ||
Priority | normal | Severity | feature | Reproducibility | always |
Status | assigned | Resolution | open | ||
Platform | PC | OS | Windows | OS Version | 10 (64bit) |
Product Version | 2.1.0 | ||||
Target Version | 2.1.4 | ||||
Summary | 0000904: Name auch änderbar bei weiterer Adresse | ||||
Description | In Version 2.1.0 wurde die Option eingeführt zu einer Hauptadresse weitere Adressen unter der gleichen Kundennummer anzulegen. Manchmal kommt es vor, dass die Angebotsadresse nicht der Rechnungsadresse entsprechen soll. Dabei hatten wir jetzt den Fall, das auch ein anderer Name, Firma mit Anschrift notwendig wäre. Bedeutet das Angebot ging an xy und die Rechnung an yz. Die Rechnung sollte aber die gleiche Kundennummer behalten, da auch der Bezug zum Angebot weiterhin bestehen bleiben soll. Lässt sich das noch mit umsetzen? | ||||
Additional Information | siehe dazu auch https://www.fakturama.info/community/postid/11595/ | ||||
Tags | No tags attached. | ||||
|
Bei Weiterführung eines Angebot an xy dessen Kundennummer auf der Rechnung an yz zu übernehmen halte ich für äußerst problematisch... führt so etwas doch unweigerlich zu einem Chaos im Datenbestand. Stadtessen gibt es doch im Datenbestand bereits die automatisch erzeugte TRANSACTIONID, welche beim Weiterführen vom ersten bis zum letzten Beleg übernommen wird und somit bereits den Bezug zwischen den Dokumenten sicherstellt. Diese kann aktuell ja bereits über den Platzhalter <DOCUMENT.TRANSACTION> ausgegeben werden. Was hierzu innerhalb Fakturama aber bis dato noch fehlt, ist zum einen die Anzeige dieser Nummer im Dokumenteditor und zum anderen eine entsprechende Übersicht, welche zusammengehörige Dokumente und dessen Status anzeigt. Letzteres sollte mögl. in einer Art Baumstruktur erfolgen, die Darstellt welche Dokumente aus welchen hervorgingen, wann sie erzeugt, ausgegeben und zuletzt bearbeitet wurden und wie der jeweilige Status und Zahlungsstand ist. |
|
Das ist vermutlich eine größere Geschichte. Die Darstellung der abhängigen Dokumente als Baumstruktur kann ich mir gut vorstellen. Ich hatte bewußt den Firmennamen außerhalb des Adreßbereiches positioniert, weil ich davon ausgegangen bin, daß die Kontakte eben nur zu einer Firma erfaßt werden sollen (mit diversen Adressen, aber eben unter demselben Firmennamen). |
|
Bei 90% aller Geschäftskunden dürfte die Firmenbezeichnung über alle Anschriften hinweg tatsächlich identisch sein. Und bei Privatkunden bleibt das Feld ohnehin leer. Neben gelegentlichen Ausnahmeerscheinungen sind hier aber vor allem andere Organisationen wie etwa die öffentliche Hand oder auch Hausverwaltungen der entscheidende Knackpunkt! Als Beispiel hier mal ein Liefervertrag von Verbrauchsmaterial an Schulen: Ein weiteres häufig anzutreffendes Beispiel sind Hausverwaltungen, welche für jede Verwaltungseinheit eine abweichende Rechnungsanschrift fordern (Firma= "WEG Musterhaus Beispielort" & Namenszusatz= "c/o Hausverwaltung Müller" oder eben Firma= "VE Testobjekt Musterdorf" & Namenszusatz= "c/o Hausverwaltung Müller" usw.). Trotz der Umsetzung Multipler Adressen bleibt hier nur die Möglichkeit entweder für jeder abweichende Bezeichnung im Firmenfeld eine eigenes Kundenkonto an zu legen, oder die Bezeichnung im erzeugten Dokument anschließend händisch zu korrigieren. Ersteres führt zu einer immensen Zersplitterung eigentlich zusammengehöriger Datensätze und bei letzterem müssen die korrekten Bezeichnungen anderweitig abgelegt sein. Beides ist jedoch gleichsam äußerst Fehleranfällig. Das Feld für die Firmenbezeichnung sollte daher zu den Adressen verlagert und m.E. auch von Firma in Organisation umbenannt werden. Innerhalb des Kundenkonto könnte hingegen ein Feld für einen beliebigen Matchcode (z.B. "Schulen Musterkreis" oder "Alte Brauerei" für eine "Brewery Consulting GmbH & Co. KG") die Auffindbarkeit eines Kunden erheblich erleichtern. |
Date Modified | Username | Field | Change |
---|---|---|---|
2020-10-08 16:00 | Pedestrian | New Issue | |
2020-10-09 17:40 | LastBoyScout | Note Added: 0001114 | |
2020-10-11 17:09 | rheydenr | Assigned To | => rheydenr |
2020-10-11 17:09 | rheydenr | Status | new => assigned |
2020-10-11 17:09 | rheydenr | Target Version | => Pipeline |
2020-10-11 17:09 | rheydenr | Note Added: 0001116 | |
2020-10-12 10:29 | LastBoyScout | Note Added: 0001117 | |
2020-12-03 22:29 | rheydenr | Additional Information Updated | |
2023-01-19 22:41 | rheydenr | Target Version | Pipeline => 2.1.4 |