Datenaustausch zwischen 2 Mandanten

Hallo @All,
gibt es einen vermeidlich "einfachen" Weg Stammdaten (T27, T18 beide ohne Abhängigkeiten) zwischen 2 Mandanten auszutauschen. Dabei kann es auch ein Master-Slave Prinzip sein (also Eingabe der Daten nur in Mandant 1, Mandant 2 wird dann durch Push oder Pull aktuallisiert.

lg
Tobias

Hallo,

gerade bei den Tabellen gibt es sehr viele Abhängigkeiten (Artikeleinheiten, Varianten, Buchungsgruppen,Preise,..). Da wäre ich vorsichtig.

Die zweite Frage ist, wie synchron müssen die sein? reicht eine Aktualisierung 1 mal pro Stunde oder wird direkt nach der Anlage auf den anderen Mandanten zugegriffen?

Gruß Fiddi

RapdiStart Services...

...

Die zweite Frage ist, wie synchron müssen die sein? reicht eine Aktualisierung 1 mal pro Stunde oder wird direkt nach der Anlage auf den anderen Mandanten zugegriffen?
...

Die Aktualisierung würde auch täglich einmal oder auf verlangen reichen - Mandant 2 hat eine sehr untergeordnete Rolle, aber die Daten (Artikel, Debitoren und Konten) sollten gleich sein.
Hilfstabellen (Einheiten, etc.) werden einmalig angelegt(Rapid).

lg
Tobias

RapdiStart Services...

Naja, das ist dann doch sehr händisch - aber im Prinzip ein einfacher manueller Weg, oder gibt es den automatisiert?

lg
Tobias

Hilfstabellen (Einheiten, etc.) werden einmalig angelegt(Rapid).

Es gibt Tabellen, wie die Artikeleinheiten- Tabelle, die sind direkt von einem Artikel abhängig, d.h. die kannst/musst du erst anlegen,wenn der Artikel auch da ist.

Gruß Fiddi

Jepp das ist auch ok - z.B. EK-Einheiten bzw. VK-Einheiten (ggf. auch Basiseinheit) sind u.U. auch etwas anders. Aber der Artikel ist der Gleiche.

Es gibt eine Lösung von unserem Partner - aber ehrlich gesagt kaufen andere Firmen ein komplettes NAV für diese Erweiterung...

lg
Tobias

RapdiStart Services...

Naja, das ist dann doch sehr händisch - aber im Prinzip ein einfacher manueller Weg, oder gibt es den automatisiert?

Richtig, einfach und bereits standardmäßig vorhanden. Ich habe leider gerade keinen Überblick wie schwierig das zu automatisieren wäre.

Ansonsten kann man mit Sicherheit auch eine kleine Codeunit schreiben. Allerdings bist du mit dem Preis dann auch schon bei einem Addon.

Das mit den Abhängigkeiten ist so eine Sache. Die Debitoren hängen z.B. direkt mit den Kontakten zusammen. Jeder Debitor und Artikel hat Dimensionen und Buchungsgruppen. Debitoren haben Bankkonten usw.

Du könntest auch "logische" Probleme bekommen. Du hast zum Beispiel zwei Mandanten von denen einer in Deutschland und der andere in einem anderen EU-Land beheimatet ist. Dann ist der gleiche Debitor in Deutschland INLAND aber in dem anderen Mandant "EU". Ist aber auch der Fall, falls ihr in den Mandanten unterschiedliche Bedeutungen von Dimensionen habt.

Aber je nach Umfang und Tiefe der Felder ist das mit einer Codeunit eigentlich nur Fleißarbeit.
Ich würde empfehlen euch vorab genau die Felder und deren Abhängigkeiten anzusehen. Dann lässt sich auch der Aufwand in ein besseres Verhältnis setzen.
Oftmals stolpert man dann doch noch über die eine oder andere Abhängigkeit.

...Du könntest auch "logische" Probleme bekommen. Du hast zum Beispiel zwei Mandanten von denen einer in Deutschland und der andere in einem anderen EU-Land beheimatet ist. …
...Aber je nach Umfang und Tiefe der Felder ist das mit einer Codeunit eigentlich nur Fleißarbeit.
Ich würde empfehlen euch vorab genau die Felder und deren Abhängigkeiten anzusehen. Dann lässt sich auch der Aufwand in ein besseres Verhältnis setzen.
Oftmals stolpert man dann doch noch über die eine oder andere Abhängigkeit....

Diese Auslandsthematik habe ich nicht, das ist aber klar, dass es da zu Herausforderungen kommen würde.

Aber es scheint wirklich so als ob ich mich da hinsetzten muss , und ein wenig fleissig sein muss.
Wenn das einer von Euch schonmal in der Vergangenheit umgesetzt hat, würde ich mich über Input freuen.

Gruß
Tobias

Die Sache ist beliebig kompliziert. Wir nutzen bei Kunden agiles Template, ein Partner Add-on zur zentralen Stammdatenverwaltung. Auch das deckt nicht jeden Spezialfall ab und hat die eine oder andere Einschränkung, kann aber schon recht viel, insbesondere auch verknüpfte Tabellen.

Wenn's recht einfach sein soll und du Zeit zum Programmieren hast, dann kann man das sicher über eine selbst programmierte Codeunit machen.

Hallo zusammen,

wir sind gerade dabei, einen Stammdaten-Mandanten zu entwickeln. Dieser soll die Tabellen Sachkonten, Debitoren und Kreditoren beinhalten.

Aus dem Stammdatenmandanten kann man Regeln anlegen, die besagen, dass nur Datensätze mit bestimmten Filtern in die einzelnen Mandanten übernommen werden sollen. (Unsere Idee: neuen Reiter in der Karte mit "verwenden in" und dann Check-Boxen für jeden einzelnen lokalen Mandanten, Filter dann: Wenn Checkbox-Haken gesetzt, dann in lokalen Mandanten übernehmen)

In den Tabellen gibt es Felder, die global vorgegeben werden (Name, Adresse, IBAN) und welche die sich ein lokaler Mandant selber füllen darf. Jetzt ist es so, dass leider auch die globalen Felder in den lokalen Mandanten geändert werden dürfen, und diese erst danach wieder (1x täglich) mit den globalen Daten überschrieben werden. Hat jemand eine Lösung hierzu, wie man dies unterbinden kann? Lt. unseren Beratern ist es nicht möglich in einer Tabelle einzelne Felder für die Bearbeitung zu sperren../ nur bestimmten Personen die Berechtigung zur Bearbeitung von einzelnen Feldern zu geben

Gerne würden wir auch Informationen auch von den lokalen Mandanten zu den Stammdatenmandanten und den anderen lokalen Mandanten vererben. Hat jemand so etwas schon mal gemacht?

Gruß,
Anna

Hallo,

die erste Frage, die ich mir stelle ist: Sind die Mandaten getrennte Firmen?

Falls nein, würde ich mir andere Wege überlegen. Denn eine Synchronisation zwischen mehreren Mandanten ist extrem aufwändig.

Es kann ja auch in zwei Mandanten der gleiche Debitor geändert werden,z.B. auf Gesperrt gesetzt werden. Wer gewinnt denn dann?

Auch ist eine Sperrung einzelner Felder durchaus möglich. Es gab/gibt da von Agiles AgilesWorkflow, damit konnte/kann man die Felder steuern.

Ob du das allerdings wirklich willst musst du dir sehr genau überlegen. Für die Tabellen die änderbaren Felder pro Mandant und/oder Benutzergruppe anzulegen, hat schon einige überfordert. Denn es ist ja nicht nur die Debitorentabelle, die du pflegen musst. Alle anderen davon abhängigen Tabellen (Zahlungsform, Zahlungsbedingung,Liefer-An Adresse,... ) müss(t)en ebenfalls gepflegt werden.

Auch die Option Daten Mandanten übergreifend anzulegen würde ich mir sehr sehr genau überlegen.

Gruß Fiddi

Stammdaten-Tabellen (Sachkonto, Debitor, Kreditor, Artikel, ...) auf mandantenübergreifend umzustellen sollte unbedingt vermieden werden!
Beim Umbenennen/Löschen eines Stammdatensatzes wird im Hintergrund geprüft, ob es noch (offene) Posten gibt. Diese Prüfungen finden nur im aktuellen Mandanten statt.
Wenn der Artikel in dem aktiven Mandant also keine offenen Artikelposten hat, dann kann er dort gelöscht werden - und wird dann auch gelöscht.
In anderen Mandanten könnte es aber noch Restbestände im Lager geben. Diese Artikelposten verweisen immer noch auf den Artikel, den es aber nicht mehr gibt. Das totale Chaos ist garantiert.

Wir haben bei uns eine ähnliche Anforderung und haben uns daher eine eigene Stammdaten-Replikation geschrieben.
Da es einen Hauptmandanten gibt, der für die Stammdaten verantwortlich ist, brauchen wir keine bidirektionale Replikation berücksichtigen. Die Daten aus dem Hauptmandanten überschreiben immer die Daten in den anderen Mandanten.
Diese anderen Mandanten können sich auch in anderen NAV-Datenbanken befinden, da der Austausch klassisch über Textdateien erfolgt.
Für jeden Ziel-Mandanten kann separat festgelegt werden, welche Tabellen und Felder exportiert werden sollen.
In jedem Mandanten muss zusätzlich eine korrespondierende Einrichtung vorhanden sein, die festlegt, welche Tabellen und Felder er von dem Absender-Mandanten erwartet.
Um auch branchenlösungsspezifische Feldwerte (5.000.000er Tabellen/Felder) in "Standardfelder" replizieren zu können, haben wir die Möglichkeit geschaffen, beim sendenden Mandanten abweichende Tabellen-IDs/Tabellennamen/Feld-IDs/Feldnamen vorzugaukeln. (Z. B. Mitarbieter-Tabelle in der Lohndatenbank -> Mitarbeiter-Tabelle in NAV-Standard)
Unter Umständen müssen Feldwerte vor dem Export konvertiert werden. Dafür bedienen wir uns der Transformationsregeln aus dem RapidStart-Paket.)

So ein Modul ist schon relativ komplex, erst recht, wenn man bidirektional replizieren will, da man dann auch noch ein umfangreiches Konflikt-Handling benötigt.
Man muss sich auch genau darüber im Klaren sein, was bei welchen Triggern (Insert, Modify, Delete, Rename) passieren soll/kann/darf.

Unsere Lösung ist da sehr pragmatisch:
- Keine bidirektionale Synchronisation (Jede Tabelle hat einen federführenden Mandanten, der auch in einer anderen Datenbank liegen kann)
- Datensätze in Tabellen, die an der Replikation teilnehmen, dürfen nicht umbenannt werden (globale Prüfung über OnDatabaseRename)

Hi Timo Lässer,

vielen Dank für die Info.

So ist es aktuell auch geplant bei uns. Wir möchten es vermeiden, dass die Stammdaten nach der Anlage im Master Data Mandant einen neuen Primärschlüssel bekommen.
Ich kann mir auch vorstellen, dass eine bidirektionale Synchronisation nicht so einfach ist. Dies wäre für uns wirklich das non-plus-ultra.

Was uns jedoch sehr wichtig ist, ist dass in den lokalen Mandanten die globalen Felder nicht geändert werden dürfen. Kann man dies einrichten?

Gruß,
Anna

Hallo,

das Ändern kann man Programmieren, aber nicht im Standard einrichten. Dazu benötigst du ein externes Tool (z.B. AgilesWorkflow) oder du musst selbst programmiern (lassen).

Gruß Fiddi

Um einzelne Felder in einzelnen Mandanten vor Bearbeitungen durch bestimmte Benutzer zu verbieten/erlauben: Stichwort "Feldsicherheit"
Es gibt entsprechende AddOns von zahlreichen Systemhäusern.
Hier wurde zwar schon häufiger Agiles genannt, mir fallen jetzt aber spontan noch mindestens zwei weitere Systemhäuser ein, die eine solche Funktionalität anbieten (Cosmo Consult, Yaveon).
Ich bin mir sicher, dass man unzählige Lösungen von noch viel mehr Anbietern über Google & Co. für NAV/BC findet.

Das Thema "Datenaustausch" haben sich auch einige Systemhäuser auf die Fahne geschrieben und bieten entsprechende AddOns dazu an.
Hierbei muss man verschiedene Punkte beachten:
- mandantenintern, datenbankintern, datenbankübergreifend, systemübergreifend?
- identische Datenstruktur, ähnliche Struktur, andere Struktur?
- Echtzeit, periodisch (alle x Minuten/Stunden)?

Wir haben sowohl eine "mandanteninterne Echtzeitsynchronisation zwischen verschiedenen Tabellen ähnlicher Struktur", wie auch eine "datenbankübergreifende, periodische Replikation ähnlicher Struktur", wie auch einen "periodischen, systemübergreifenden Datenaustausch in ein Fremdsystem".
Felder, die von niemandem (außer dem Datenaustausch) geändert werden dürfen sind in den Tabellen auf Editable=False gesetzt.
Für Felder, die nur von bestimmten Benutzern geändert werden dürfen, setzen wir eine Feldsicherheit ein.
Für die Feldsicherheit und den Datenaustausch mit dem Fremdsystem setzen wir ein AddOn eines Drittanbieters ein, welches beide Funktionen in einem AddOn beherrscht.
Für die Echtzeitsynchronisation sowie die datenbankübergreifende Replikation setzen wir entsprechende Eigenentwicklungen ein, da es (zumindest zum damaligen Zeitpunkt) kein AddOn gab, welches unsere Anforderungen erfüllen konnte.

Ich werfe mal kurz das Add-on "Template" in den Raum, das von agiles kam, die sich dann in ocean5 umbenannt haben und in Insolvenz sind. (Achtung, das ist ein anderes Unternehmen als die agiles von denen agiles Workflow ist.) Jetzt ist das unter dem Namen Multi Entity Management" bei einem dänischen Partner namens XtensionIT gelandet. Ich habe seither noch nix mit denen zu tun gehabt und kann auch nicht sagen wie der aktuelle Stand dort ist.

https://www.xtensionit.com/multi-entity ... solutions/

Im Standard gibt es dazu bald eine erste Lösung https://yzhums.com/35196/. Wie gut/schlecht die ist, wird sich vermutlich erst zeigen, wenn die ersten Erfahrungen mit realen Fällen gemacht werden.

Wir stecken gerade in einer ähnlichen Herausforderung, mit dem Zusatz, dass unterschiedliche Versionen im Einsatz sind.

Headquarter: NAV2018, hoch individualisiert
Tochter 1: NAV2018, Standardnah
+ X weitere TG mit Drittsystemen, die Schrittweise auf BC SaaS umgestellt werden sollen.

Es besteht bereits eine Eigenentwicklung die zwischen den beiden NAV Versionen Stammdaten austauscht, die ziemlich flexibel parametrisiert werden kann. Zu synchronisierende Tabellen und Felder können ausgewählt werden und anhand von Filtern werden Pakete über die Job Queue erzeugt, die im Zielsystem via JobQueue eingelesen werden. Dort kann eine freie Feldzuordnung vorgenommen werden, so wird z.B. der VK-Preis zu Last Direct Cost um den Einkaufspreis anzusteuern. Zudem werden über eine Nachverarbeitung bestimmte Felder vorbelegt (Buchungsgruppen, Einheitencodes (die leider nicht standardisiert sind).

Das müssen wir zukünftig abbilden können, und zusätzlich in die Cloud geschoben bekommen. Ich glaube, wir kommen hier an einem Modul nicht vorbei. Bei der Recherche sind wir im ersten Step auf ein Modul aus Polen gestoßen, das wir uns wohl mal näher ansehen werden.

Hat hier jemand zufällig eine Datensynchronisation und nebenbei auch einen Variantenkonfigurator im Einsatz?

Im Standard gibt es dazu bald eine erste Lösung https://yzhums.com/35196/. Wie gut/schlecht die ist, wird sich vermutlich erst zeigen, wenn die ersten Erfahrungen mit realen Fällen gemacht werden.

Sieht mMn ganz interessant aus, vor allem das Coupling von Datensätzen ist eine nette Funktion. Nachteil mMn sind hier aber leider die Beschränkung auf die Datenbank und keine Möglichkeit Feldwerte zu beeinflussen. Da wird man entweder programmiertechnisch aufsetzen müssen oder eine Alternative nutzen. Für viele Kunden wird das aber sicherlich reichen.