Erklärung Mandantenkonzept in NAV
17. Juni 2008 09:17
Hallo,
wollte fragen, ob mich jemand das grundsätzliche Mandantenkonzept von Dynamics Nav erklären kann. Mit einen Link wäre ich auch zufrieden. Hab selber schon geschaut, aber nichts vernünftiges gefunden.
U.a. würde mich interessieren:
1. Bestimmte Datensätze sind Mandantenabhängig und andere Mandantenübergreifend. Korrekt?
2. Ein Datensatz z.B. ein Artikel ist immer genau einen Mandanten zugeordnet. Stimmt das?
3. Falls ich mit Punkt 2 Recht habe, was mache ich mit Datensätzen die für mehrere Mandanten benötigt werden. Muss ich die dann redundant anlegen?
Wäre für eure Hilfe echt dankbar.
Gruß
Snowwolf
wollte fragen, ob mich jemand das grundsätzliche Mandantenkonzept von Dynamics Nav erklären kann. Mit einen Link wäre ich auch zufrieden. Hab selber schon geschaut, aber nichts vernünftiges gefunden.
U.a. würde mich interessieren:
1. Bestimmte Datensätze sind Mandantenabhängig und andere Mandantenübergreifend. Korrekt?
2. Ein Datensatz z.B. ein Artikel ist immer genau einen Mandanten zugeordnet. Stimmt das?
3. Falls ich mit Punkt 2 Recht habe, was mache ich mit Datensätzen die für mehrere Mandanten benötigt werden. Muss ich die dann redundant anlegen?
Wäre für eure Hilfe echt dankbar.
Gruß
Snowwolf
17. Juni 2008 09:46
Hallo zurück,
mal kurz und knapp meine Antwort:
1. Logik:
Anders als bspw. in SAP (Mandant = (Teil-) Konzern und Buchungskreis = Gesellschaft) entspricht in Navision der Mandant einer rechtlichen Einheit.
2. Aufbau:
Der Aufbau der Datenbank ist ja relational (vgl. ER- Modell) und hat damit eine Tabellenstruktur zur Abbildung dieser rechtlichen Einheit (plus Darstellung (Forms), Reports, Funktionen (Codeunits) und Schnittstellen). Im Standard ist dieser Struktur nur für einen Mandanten gedacht und hat nur Systemtabellen als übergreifend eingeplant. Bedeutet neuer Mandant = clonen der Struktur. Folglich wären Punkt 2 und 3 richtig. Es gibt aber Möglichkeiten auch hier übergeordnetet Strukturen zu schaffen.
Gruß
defiant701
mal kurz und knapp meine Antwort:
1. Logik:
Anders als bspw. in SAP (Mandant = (Teil-) Konzern und Buchungskreis = Gesellschaft) entspricht in Navision der Mandant einer rechtlichen Einheit.
2. Aufbau:
Der Aufbau der Datenbank ist ja relational (vgl. ER- Modell) und hat damit eine Tabellenstruktur zur Abbildung dieser rechtlichen Einheit (plus Darstellung (Forms), Reports, Funktionen (Codeunits) und Schnittstellen). Im Standard ist dieser Struktur nur für einen Mandanten gedacht und hat nur Systemtabellen als übergreifend eingeplant. Bedeutet neuer Mandant = clonen der Struktur. Folglich wären Punkt 2 und 3 richtig. Es gibt aber Möglichkeiten auch hier übergeordnetet Strukturen zu schaffen.
Gruß
defiant701
17. Juni 2008 23:59
Erstmal danke für dein Antwort. Hilft mir schon weiter.
Kannst du das noch genauer erklären? Was gibt es da für Möglichkeiten?
Es gibt aber Möglichkeiten auch hier übergeordnetet Strukturen zu schaffen.
Kannst du das noch genauer erklären? Was gibt es da für Möglichkeiten?
18. Juni 2008 10:47
Mastertabellen wie die Artikeltabelle sollten nie einfach mandantenübergreifend geschaltet werden (dieser Schritt ist irreversibel!). Das schafft wesentlich mehr Probleme als es löst. Tabellen enthalten neben Daten auch Code in den Feldtriggern und Funktionen.
Hier wird erklärt wie man Synchronisationsfunktionen anlegt, um die Mandantendaten untereinander abzustimmen.
Alternativ kann man auch eine übergeordnete neue Tabelle anlegen, die nur den Zweck hat, die normalen Mastertabellen zu versorgen, oder einen Mastermandanten, wie hier empfohlen.
Allgemein zur Redundanz :
An vielen Stellen in NAV sind redundante Daten. Der Grund dafür ist, dass Betragsflowfields nur summieren können. Bewegungsdaten müssen also "ausgerechnet" bereitgehalten werden, auch wenn sie nur das Ergebnis aus einer Multiplikation zweier Felder aus der Tabelle sind.
Hier wird erklärt wie man Synchronisationsfunktionen anlegt, um die Mandantendaten untereinander abzustimmen.
Alternativ kann man auch eine übergeordnete neue Tabelle anlegen, die nur den Zweck hat, die normalen Mastertabellen zu versorgen, oder einen Mastermandanten, wie hier empfohlen.
Allgemein zur Redundanz :
An vielen Stellen in NAV sind redundante Daten. Der Grund dafür ist, dass Betragsflowfields nur summieren können. Bewegungsdaten müssen also "ausgerechnet" bereitgehalten werden, auch wenn sie nur das Ergebnis aus einer Multiplikation zweier Felder aus der Tabelle sind.
25. Juni 2008 08:44
Hallo und danke für die Antworten!
Ich würde mal sagen: huch, die Folgen von "data per company" habe ich wohl stark unterschätzt.
Wir stehen konkret vor folgender Aufgabe: Umstellung der "alten" Fibu; hier waren diverse Stammdaten "mandantenübergreifend". So soll es nun natürlich auch in Navision sein. Denn eine doppelte Pflege z. B. der Kunden- oder Lieferantendaten möchten wir definitiv nicht.
Der Link zur Lösung mit den "Master Tables" scheint mir eine gute Lösung zu beschreiben. Allerdings habe ich das noch nicht ganz verstanden. Ich versuche einmal das mit meinen Worten zu beschreiben, was dort vorgeschlagen wird (am Beispiel der Kundenstammdaten):
Ich würde also als erstes einen neuen Mandanten "Master Company" anlegen. Dann kommt jedoch "in the Company table create a link between this and the sub companies". Das verstehe ich leider nicht
Was muss man da genau tun?
Und im weiteren Text hört es sich für mich dann so an, dass man die Änderungen wie bisher in der jeweiligen Company durchführt, die Daten aber automatisch zentral in der Master Company gespeichert werden. Habe ich das so richtig verstanden?
Ich vermute, dass es da noch mehr Leute gibt, die ihre Kundendaten nur einmalig pflegen möchten und dennoch in mehreren Mandaten nutzen möchten. Oder befinde ich mich da auf dem Holzweg?
Viele Grüße
Turm
Ich würde mal sagen: huch, die Folgen von "data per company" habe ich wohl stark unterschätzt.
Wir stehen konkret vor folgender Aufgabe: Umstellung der "alten" Fibu; hier waren diverse Stammdaten "mandantenübergreifend". So soll es nun natürlich auch in Navision sein. Denn eine doppelte Pflege z. B. der Kunden- oder Lieferantendaten möchten wir definitiv nicht.
Der Link zur Lösung mit den "Master Tables" scheint mir eine gute Lösung zu beschreiben. Allerdings habe ich das noch nicht ganz verstanden. Ich versuche einmal das mit meinen Worten zu beschreiben, was dort vorgeschlagen wird (am Beispiel der Kundenstammdaten):
Ich würde also als erstes einen neuen Mandanten "Master Company" anlegen. Dann kommt jedoch "in the Company table create a link between this and the sub companies". Das verstehe ich leider nicht
Was muss man da genau tun?
Und im weiteren Text hört es sich für mich dann so an, dass man die Änderungen wie bisher in der jeweiligen Company durchführt, die Daten aber automatisch zentral in der Master Company gespeichert werden. Habe ich das so richtig verstanden?
Ich vermute, dass es da noch mehr Leute gibt, die ihre Kundendaten nur einmalig pflegen möchten und dennoch in mehreren Mandaten nutzen möchten. Oder befinde ich mich da auf dem Holzweg?
Viele Grüße
Turm
25. Juni 2008 12:25
Eine "so wird es gemacht" Variante gibt es definitiv nicht. Vielmehr geben die Antworten auf Unternehmensgröße, IT- Landschaft, Ausrichtung des Unternehmens, Geschäftsbereiche, Marketing Lastigkeit... etc. die möglichen Ansätze für Lösungen. Es ist auch nicht immer sinnvoll alles in einem ERP System zu realisieren. Wer beispielsweise noch ein CRM System hat, kann den Abgleich hierzu vornehmen (vgl. SOA oder ECM Konzepte).
Gruß
defiant
Gruß
defiant
30. Juni 2008 17:59
Konnte letzte Woche leider nicht schreiben, aber vielen Dank für eure Antworten! Habt mir echt weitergeholfen.