@all Mit dem Aufbau und der Struktur der Stammdaten habe ich mich im Zuge meiner DMS Umstellung sehr umfangreich und intensiv auseinandergesetzt um für mich in meinem DMS eine vernünftige Datenstruktur hinzubekommen. Auch wenn ich vorher schon den Kombityp 2 als Auslaufmodell angesehen habe gab es da so eine Sache namens Bequmlichkeit die mich lange davon abgehalten hat, den Typ 2 aus meinen Daten zu verbannen. Im Zuge der DMS Umstellung (meiner, nicht die der DATEV) habe ich dann doch eingesehen, dass ich die Umstellung angehen musste und habe es auch getan. Im Zuge der Umstellung musste ich auch dem Dienstleister die DATEV Nomenklatur "übersetzen" damit die Stammdaten übernommen werden konnten und natürlich auch laufend werden. Dabei sind auf den ersten Blick so einige "Ungereimtheiten" aufgetaucht die sich nicht so einfach vom Tisch wischen lassen da sie andererseits relativ sinnvoll sind. Wenn man sich gedanklich an folgende Nomenklatur hält ist das Verständnis der Datenbank gar nicht so schwer: Adressat als als grundlegendes Objekt. Kann verschiedene Funktionsverknüpfungen haben: Mandant Arbeitnehmer Betriebsstätte Kind Ehegatte (beide Richtungen) Mandat als "Sammler" für den Auftrag (Der Datensatz enthält tatsächlich nur die Beziehungen) Die Adressatstypen steuern wiederum die Masken und genutzten Felder beim Adressaten, hier sind auch Adressen, Finanzämter, Telefonnummern etc. in Subtabellen gespeichert. Wenn die Entwicklung diese Strukturen auch in alle (!) Programme übernommen hätte, wären ca. 80% der hier angesprochenen Probleme keine mehr. Was spricht dagegen z. B. im DMS eine Betriebsstätte als Objekt zu führen und die Stammdaten nutzen zu können? Was an der Datenstruktur (wieder einmal) fehlt ist die Sicht auf die Objekte. Die DATEV Entwicklung lässt (egal ob Arbeitsplatz oder Auskunftssystem) nur eine sehr eingeschränkte Sicht auf die Objekte zu, das erschwert zum einen die Übersicht und zum anderen das Verständnis. @marcohüwe Das Beispiel Telefonie ist leider ein schlechtes Beispiel. Die DATEV Telefonnummernverwaltung ist relativ modern, die Datenbank von z. B. ESTOS Metadirctory leider Steinzeit. Die Telefonnummer ist eine eindeutige Einheit (Durchwahlen lasse ich einmal unbetrachtet). Diese Nummer kann in DATEV einem Adressaten zugeordnet werden, dieser Adressat wird mit einem Mandat verknüpft, die Nummer ist nur 1x in DATEV existent. So, nun das Problem: ESTOS holt mittels API die Telefonverbindungen aus DATEV und findet durch die Abfrage einmal das Mandat mit der verknüpften Telefonnummer und einmal den Adressaten mit derselben Telefonnummer. Für ESTOS sind das 2 Zuordnungen, die dann zu 2 Datensätzen führen. Hinzu kommt, dass ESTOS durch die die Struktur in einem Datensatz nur eine begrenzte Anzahl von Telefonnummern speichern kann. Geht der Anruf ein sieht ESTOS natürlich nur die übermittelte Rufnummer und muss jetzt eine Zuordnung treffen und diese Zuordnung an DATEV übergeben. Je mehr Verknüpfungen in DATEV existieren desto mehr wird die eingehende Zuordnung zu Glücksspiel.
... Mehr anzeigen