Mandanteübergreifende Daten teilweise DataPerCompany=YES

Hallo,

vielleicht der Betreff ein wenig holperig, aber viel Platz ist nicht die Info dort unterzubringen.

Frage: Ist es möglich Tabellen die mandantenübgreifend geschaltet (DataPerCompany=No) sind, teilweise mit mandantenspezifischen Felder versehen?

Hintergrund: Wir haben u.a. die Tabellen Debitor(T18) und Kreditor (T23) mandantenübgreifend geschaltet (DataPerCompany=No).

Das ist grundsätzlich so in Ordnung, da sonst der größte Teil der Daten redundant wäre. Da sich die Mandanten natürlich in einigen Punkten unterscheiden, beispielsweise andere Mitarbeiter (Verkäufer/Einkäufer-Code), Zahlungsbedingungen usw. haben, wäre es gut wenn einige der Felder mandantenbezogen sind. Die dahinterliegenden Tabellen z.B. Verkäufer/Einkäufer ist mandantenspezifisch.

Dies mandantenspezifischen Daten sollen dann in der vorhandenen Umgebung (Aufträge, Reports usw.) transparent verwendet werden, also möglichst ohne weitere Anpassungen zur Verfügung stehen.

Lösungansatz wäre sicherlich sowas wie:
[list=]
[*] für die betreffenden Felder jeweils eine Untertabelle mit entsprechenden Primärschlüssel wir Ursprungstabelle (z.B. Debitor) erstellen
[*] die transparent bei Laufzeit für den entsprechenden Mandanten die Werte anspricht.
[/list]

Das mit dem ablegen der mandantenspezifischen Information kann ich mir vorstellen. Große Fragezeichen sehe ich aber noch wie ich das "transparente" abrufen soll.

Hat jemand schon mal sowas gemacht? Was wäre ein möglicher Lösungsweg?

Viele Grüße,

Janosch

Mahlzeit,

im Zuge der Intrastatmeldung ist mir aufgefallen. dass ich die oben genannten Spalten nirgends finden kann, wobei sie für die Intrastatmeldung erforderlich sind. Sie sollen also zu schnell wie möglich in die dafür vorgesehen Buchungsblätter angelegt werden.

Wo befinden sich diese Spalten?

Hallo janosch,

ich habe eine ähnliche Aufgabenstellung bei uns in der Firma. Was wohl gehen wird ist eine Untertabelle (mandantenspezifisch) zu machen, die als Primärschlüssel den Debitor bzw. Kreditor hat und alle mandantenspezifischen Felder enthält. Und dann die mandantenspezifischen Felder in der Debitoren/Kreditorentabelle als Flowfields zu setzen... das hat aber Tücken. Man kann damit nicht verhindern, dass man doch durch die gesamte Anwendung gehen muss, um dort die Kopplung im Code herzustellen - und sei es nur das calcfields() aufzurufen. Wenn man das sowieso machen muss, kann man auch die Debitoren/Kreditoren Karte und Übersicht entsprechend anpassen.

LG Jens

[*] für die betreffenden Felder jeweils eine Untertabelle mit entsprechenden Primärschlüssel wir Ursprungstabelle (z.B. Debitor) erstellen

Ich würde diese Variante verwenden. Braucht dann insgesamt nur zwei weitere Tabellen (eine für Debitor; eine für Kreditor).

Hallo,

im Prinzip wäre euer Vorschlag möglich, aber mit sehr viel Aufwand verbunden, da an jeder Stelle in der gesamten Anwendung wenn der Debitor gelesen wird, auch die Tabelle gelesen werden müsste, was nur sehr schwer zum laufen zu bekommen wäre. Dann müsste an allen Stellen im Code, wo auf den Verkäufer Code aus dem Debitoren- Stamm zugegriffen wird, der Zugriff auf eure Tabelle eingefügt werden. Denn den Debitoren- Stamm beim Lesen der Zusatztabelle ändern könnte dazu führen, das bei einem Modify auf die Debitoren das falsche Werte zurückgeschrieben werden.
Das nächste Problem sind Table-Relations, die könntet ihr bei diesen Feldern nicht mehr sinnvoll nutzen (Reports!). Sämtliche Lookups bei den entsprechenden Feldern müssten ausprogrammiert werden.

Mein Vorschlag daher:
Debitorenstamm DataPerCompany=Yes. Eine Funktion schreiben, die die gewünschten Daten über alle Mandanten synchronisiert. Diese Funktion wird in den OnModify/OnInsert- Trigger der Debitoren- Tabelle aufgerufen, und an allen Stellen, an denen der Debitorenstamm mit Modify(False)/Insert(False) aufgerufen wird.

Das hat man wesentlich besser im Griff, und lässt einen bei einem Update auf eine neue Version später nicht verzweifeln. Außerdem dürfte die Geschwindigkeit des Systems nicht so sehr darunter leiden.

Ich hab gerade mal in unserer Branche geschaut: die Tabelle Debitor wird dort ca. 310 mal verwendet, 108 mal ein Get, 42 mal Find, aber es wird nur 9 mal ein Modify und 2 mal ein Insert aufgerufen. Ich denke das sollte eure Frage beantworten.

Gruß, Fiddi

Hallo fiddi,

~300x finde ich jetzt nicht sooo viel Die Synchronisationsmethode hat ggf. auch ihre Tücken. Das ist für 2 oder auch 10 Mandanten sinnvoll, aber nicht mehr für 100 oder mehr. Das dauert dann einfach im täglichen Betrieb zu lang.

Zum Thema Lookups macht wohl eine Kombilösung Sinn:

- Die mandantenspezifischen Felder als FlowField (ReadOnly) mit der alten TableRelation erhalten. Man kann diese Felder als Filter in den Reports weiterverwenden, den Code in den Reports muss man sowieso anpassen. In der Deb./Kred. Übersicht kann man diese Felder weiter zum filtern verwenden. Das ist zwar "dirty", aber wenn ich mir den RTC so anschaue... akzeptabel Wenn man genau diese Felder für die Eingabe benutzen will geht das wsl. auch, ist aber mit entsprechender Programmierung in jedem Feld.
- Die Eingabe erfolgt in der Debitorenkarte und Kreditorenkarte, dort wird der mandantenspezifische Teil auf OnAfterGetrecord geholt oder bei OnNewRecord mit angelegt usw. Die mandantenspezifischen Felder sind die der mandantenspezifischen Tabelle... mit etwas Code pro Feld, um sicherzustellen das sie auch wieder geschrieben werden.

Egal wie, ein wenig Aufwand ist das schon.

LG Jens

Das ist für 2 oder auch 10 Mandanten sinnvoll, aber nicht mehr für 100 oder mehr. Das dauert dann einfach im täglichen Betrieb zu lang.

Wie oft werden Stammdaten geändert, bzw. angelegt, und wie oft wird auf Sie zugegeriffen? Dies ist das Entscheidungskriterium. Wird jeder Debitor nur einmal angelegt und nur einmal benutzt, hast du recht, wird der Debitor aber wesentlich öfter gelesen, als geschrieben (ich denke das ist der Normalfall), hast du eine wesentlich bessere Gesamtperformance wenn du nicht jedes mal die zusätzliche Tabelle lesen musst.

Die mandantenspezifischen Felder als FlowField (ReadOnly) mit der alten TableRelation erhalten. Man kann diese Felder als Filter in den Reports weiterverwenden,..

Das wird aber sehr langsam, wenn diese Felder Bestandteil von Flowfields sind, wenn es denn überhaupt funktioniert. Wenn du z.B. die Debitor- Verkäufer-Umsätze haben möchtest.

Du musst dir jedes Objekt anschauen, ob dort eine Verknüpfung zwischen Debitoren und einer anderen Tabelle über solch ein Feld läuft, und anpassen (viel Spass beim suchen )


Gruß, Fiddi

Ich finde es nicht ganz unproblematisch Debitoren Mandantenübergrefend anzulegen. Werden denn alle Debitoren in allen Mandanten genutzt? Sind auch die Nummernkreise synchronisiert? Was ist mit verbundenen Tabellen (z. B. Contact)?

Beispiel andersrum:
-Contact ist Mandanten übergreifend, Debitor ist Mandantenspezifisch.
- Aus Contact wird ein Debitor erstellt
- Contact wird in anderem Mandanten geändert. Diese Änderung wirkt sich aber nicht auf den ursprünlichen Debitor aus.

Volker

Ich finde Fiddis Vorgehensweise und Argumentation genauso wie Volkers Hinweis richtig und würde die Vorgehensweise wie Fiddi beschrieben hat, auch nehmen. Habe auch beide Fälle mal gehabt. Der Sync-Ansatz ist um längen besser und bereitet weniger Kopfschmerzen plus geringere Wartungs-/Servicekosten. (anders ausgedrückt: Die Gefahr bei "DataPerCompany=No" ein negatives Ergebnis in den Firmenzahlen ist bedeutend größer.)