Historische Daten bei Migration auf BC übernehmen?

Wir haben derzeit NAV 2015 im Einsatz und wollen auf BC updaten. Dabei stellt sich die Frage, ob historische Daten übernommen werden sollen.
Wir haben eine ziemlich angepasste Version und wollen möglichst im Standard bleiben. Die Datenbank ist ca. 900 GB groß

Ein diskutierter Ansatz wäre die historischen Daten im alten System zu belassen und dieses im Zugriff zu belassen, so dass die gesetzlichen Anforderungen erfüllt werden und Garantiezeiten eingesehen werden können.

Wie sind eure Erfahrungen mit der Übernahme historischer Daten und welche Argumente gibt es dagegen?

Zuletzt geändert von reinske am 27. Februar 2023 09:59, insgesamt 1-mal geändert.

Hallo,

das kommt darauf an. Alles was jünger ist als 10 Geschäftsjahre, bzw. aufgrund anderer Aufbewahrungspflichten, musst du sowieso verfügbar haben.
Wenn es sich um Posten handelt, könnte man die theoretisch komprimieren. Da musst du aber jemanden haben, der ganz genau weiß was er da tut.

Und da ich unverschuldet mit solchen komprimierten Daten schon meine Erfahrung hatte, lasse ich meine Finger davon.

Ob das generell sinnvoll ist, hängt von euren Gepflogenheiten ab.
Wen euch euer Geschäft von gestern egal ist, Umsatzstatistiken eh gefälscht und damit überflüssig sind, Dann setzt euer System ganz neu auf.
Habt ihr allerdings mit Seriennummern zu tun, müsst Service- oder Garantieleistungen erbringen, oder habt Nachweispflichten, und eurer Kunden sind euch nicht egal (die kaufen also öfters) order auch die eine oder andere Statistik über mehrere Jahre wäre interessant, dann sollte man vielleicht doch über die Übernahme der historischen Daten nachdenken.

Du schreibst, ihr wollt möglichst nah am Standard bleiben? Welchen Standard?

Gruß Fiddi

Tschuldigung, wenn ich höre oder lese jemand will ein ERP standardnah nutzen dann muss ich lachen. Das gibt es nicht bzw. nur wenn man parallel alles in Excel führt was im ERP nicht geht - und solche Unternehmen gibt es auch heute noch (oder wieder?).

Es gibt nur ein Argument die historischen Daten nicht zu übernehmen - wenn ihr für Auswertungszwecke eine separate Software / Datenbank habt, in der die nötigen Daten vorgehalten werden, Stichwort Data Warehouse. Jeder Buchhalter wird dich erschlagen wenn du ihm erzählst dass er für die nächsten Jahre in seiner ganz normalen alltäglichen Arbeit IMMER in zwei Systemen arbeiten muss. Aber auch jeder Vertriebler der natürlich auch Kundendaten der letzten 2 Jahre im Alltag braucht.

Natürlich kann man Daten bei einer Migration (oder auch unabhängig davon) wegwerfen, die nicht mehr benötigt sind, insbesondere wenn die Datenbank sehr groß ist, z. B. Daten die nicht mehr aufbewahrungspflichtig sind oder Daten aus Modulen die nicht mehr genutzt werden. Aber bei einer Migration grundsätzlich keine Bewegungsdaten mitzunehmen halte ich für hochgradig gefährlich. Das schmälert auch die Akzeptanz des neuen Systems ganz erheblich, weil die Mitarbeiter ja durch den Umstieg deutlich mehr Arbeit haben als vorher.

Trotzdem gibt es unter IT Beratern extrem viele Befürworter die dann so tolle Begrifflichkeiten wie "clean start" in den Raum werfen.

Hallo,

Trotzdem gibt es unter IT Beratern extrem viele Befürworter die dann so tolle Begrifflichkeiten wie "clean start" in den Raum werfen.

Das ist ganz einfach. Die Kosten dafür machen einen großen Teil der Umstellungskosten aus und sind nur schwer kalkulierbar. Insbesondere dann, wenn dabei auch noch gravierende Änderungen in der Datenstruktur passieren.

Zum Thema Standardsoftware:

Ich frage mich schon seit geraumer Zeit warum Handwerker mit so vielen unterschiedlichen Hämmern und Zangen arbeiten.
Wenn es nach den Aussagen von IT- Entscheidern gehen würde, müssten die alle mit einem Standard 5kg Hammer und einer Standard Kneifzange auskommen können.

Tatsächlich ist es aber so, das jedes Gewerk spezielle Werkzeuge für spezielle Aufgaben hat, teilweise sogar spezielle Werkzeuge für einen Arbeitsgang.
Niemand würde in der Autoindustrie darauf kommen, den Kotflügel eines Autos mit einem Schlosserhammer zu dengeln, wenn er 500 Stück davon am Tag benötigt.
Das wäre in diesem Fall einfach zu teuer und zu ineffizient.

Das ist bei der Software nicht anders. Auch die ist nur ein Werkzeug, dass man sich für bestimmte Aufgaben mehr anpassen muss, weil täglich 1000 mal benutzt, bei anderen aber darauf verzichten kann, weil nur einmal im Jahr benutzt. Bei einem Anwender der mehrere 10 Mandanten hat, wird das komplett anders sehen, wenn er für jeden Jahresabschluss mehrere Tage lnger benötigt, weil das Werkzeug (Software) nicht passt.

Daher gibt es keine Standard- Software auch nicht in BC, die wird immer an die Anforderungen angepasst durch Apps oder PTE's

Gruß Fiddi
Gruß Fiddi

... Dabei stellt sich die Frage, ob historische Daten übernommen werden sollen....

Ich häng mich hier mal mit dran, denn auch bei uns steht das Thema "Move to Cloud" gerade an. Wir haben NAV 2018 im Einsatz (Prädikat "extremly customized" ) und es soll in naher Zukunft Richtung BC gehen.

Einfach alles mitzunehmen - inkl. des bestehenden Customizing - ist für ein Update auf BC einfacher und somit auch kostengünstiger. Zudem gibt es keinen Standard, der alle Unternehmen/Branchen bedient (ausser man macht "nur" die Buchhaltung mit NAV ohne jegliche Sonderlocke)

Wenn man aber wieder standardnah sein will, ohne die komplette Historie mitzunehmen, dann wird das ein Projekt wie bei einem kompletten Neuanfang mit NAV rsp. dann BC. Dabei könnte man dann natürlich auch eine Datenreduzierung in den Bewegungsdaten und eine Datenbereinigung im Bereich der Stammdaten vornehmen (z.B. nur offene Posten der Debitoren/Kreditoren). Das wird entsprechend zeitintensiver und kostspieliger. Zudem muss man dann jeden Prozess in BC durchspielen, um herauszufinden, ob der "BC Standard" das wie gewünscht bedient oder ob nicht auch hier eine Extension benötigt wird. Das einzig Gute ist, dass es für BC schon sehr viele Extensions gibt und diese auch sehr einfach anzubinden sein sollen.

Ich überlege gerade, ob wir bei uns nicht einfach alles aus NAV 2018 mitnehmen ( auch das Customizing), um dadurch einen kostengünstigen und reibungsloseren Start mit BC zeitnah zu ermöglichen. Eine Datenreduzierung beim Update auf BC wünsche ich mir bei uns allerdings in den Bewegungsdaten der Debitoren/Kreditoren, da unsere DB Daten von mehr als 20 Jahren beinhaltet.
Und im Anschluss würden wir dann ein Projekt aufsetzen, um zu sehen, welches historisch übernommene Customizing wir mit BC Standard oder neuen Extension ablösen können. Wie gesagt, ich bin noch am überlegen...

VG Anke

Die hist. Daten sollen noch über das alte NAV zugänglich sein, um gesetzliche Anforderungen zu gewährleisten.
Gegen die Übernahme sprechen für mich:
- Fehler in den Artikel- und Wertposten (Ein Bericht von Microsoft hat eine Vielzahl von Fehlern entdeckt, die dann zukünftig erhalten bleiben)
- Die Lagerregulierung dauert jetzt schon sehr lange, da die Lagerabgangsmethode auf Durchschnitt steht und ständig der gesamte Urschleim bei der Bewertung herangezogen wird.
- Lagerabgangsmethode auf FIFO - Daher wollen wir auf FIFO umstellen, was sich aber bei hist. Daten als sehr schwierig erweist.
- Performance (500 Mio. Posten in den 8 größten Postentabellen), Extensions sollen bei Postentabellen mit Mio. Einträgen die Performance zusätzlich senken)
- Bereinigung von Stammdaten (nicht genutzte Artikel, Debitoren, Kreditoren, Kontakte, etc.) ist nicht möglich, wenn die Historie übernommen wird
- Dauer der Datenkonvertierung (können 900 GB an einem langen Wochenende konvertiert werden? / Was ist bei zukünftigen Updates in BC die ja jedes halbe Jahr kommen?)

Das Thema "zurück zum Standard" will ich mal außen vor lassen, da dies ein eigenes Riesenthema ist.
Mich interessiert vor allem die Erfahrung von allen, die bereits auf BC sind.

Ich überlege gerade, ob wir bei uns nicht einfach alles aus NAV 2018 mitnehmen ( auch das Customizing), um dadurch einen kostengünstigen und reibungsloseren Start mit BC zeitnah zu ermöglichen. Eine Datenreduzierung beim Update auf BC wünsche ich mir bei uns allerdings in den Bewegungsdaten der Debitoren/Kreditoren, da unsere DB Daten von mehr als 20 Jahren beinhaltet.
Und im Anschluss würden wir dann ein Projekt aufsetzen, um zu sehen, welches historisch übernommene Customizing wir mit BC Standard oder neuen Extension ablösen können. Wie gesagt, ich bin noch am überlegen...
VG Anke

Meine Erfahrung ist, dass wenn man noch die Möglichkeit hat auf Altes zurück zu greifen, nie die Chance nutzt etwas Neues zu implementieren. Zudem dürfte sich das als äußerst kostspielig erweisen. Es ist ja nicht mehr so, dass über einen Codeabgleich einfach entschieden werden kann, wo der neue Code in der neuen Version eingebunden werden kann. Durch den Technologie-Switch muss jede Änderung neu eingebunden werden.
Und dann im Nachhinein Stück für Stück einzugreifen, um das alte neu hinzubiegen und dabei die Daten entsprechend zu ändern...?
Ich weiß nicht, das hört sich für mich nicht wie eine optimale Lösung an.

Hallo reinske

Schau mal hier, falls Du diese Lösungen noch nicht kennst -> https://www.ckl365.com/de/
Ich denke, insbesondere die APP Costing Method wäre da wohl für Euch interessant, gerade wegen der Möglichkeit eine Änderung der Lagerabgangsmethode auf bestehenden Artikeln vorzunehmen.

Wir haben Gottseidank keine Lagerhaltung - da wird es für uns auf jeden Fall diesbezüglich einfacher werden. Danke auf jeden Fall für deinen Input, ich grübele mal weiter an einem sinnvollen Weg für uns.

VG Anke

Hallo,

Meine Erfahrung ist, dass wenn man noch die Möglichkeit hat auf Altes zurück zu greifen, nie die Chance nutzt etwas Neues zu implementieren.

Alte Daten zu übernehmen hat nichts damit zu tun, ob man historische Daten übernimmt oder nicht. Es ist nur eine etwas größere Herausforderung.

Ich vermute du hast nichts mit Auftragsbearbeitung oder Statistiken zu tun. Sonst wärst du da anderer Meinung.
Wenn du keine historischen Daten hast, kannst du z.B. keine korrekte Lagerabwertung vornehmen, keine Umsatzvergleiche zu Vorjahreszeiträumen machen, oder auch nur angefangene Aufträge in der neuen Version weiter bearbeiten. Geschweige irgendwelche Korrekturen oder Gutschriften buchen.

Gruß Fiddi

bei uns steht das Thema "Move to Cloud" an […]
Und im Anschluss würden wir dann ein Projekt aufsetzen, um zu sehen, welches historisch übernommene Customizing wir mit BC Standard oder neuen Extension ablösen können.

Was genau ist bei euch die "Cloud"? SaaS,PaaS oder IaaS?
Wenn ihr damit SaaS meint, müsst ihr vorher das Projekt aufsetzen, nicht hinterher. Also aus euren Anpassungen eine PTE (Per-Tenant Extension) erstellen und dabei alle eigenen Erweiterungen aus den Standardobjekten entfernen. Die PTE könnt ihr dann auch unter SaaS weiternutzen, zusammen mit den anderen benötigten im AppSource.

Es gibt nur ein Argument die historischen Daten nicht zu übernehmen - wenn ihr für Auswertungszwecke eine separate Software / Datenbank habt, in der die nötigen Daten vorgehalten werden, Stichwort Data Warehouse. .

Separate Datenbanken braucht es normalerweise nicht, dafür bietet sich Power BI an, damit hätte man dann eine Auswertesoftware für beide Systeme.
Die kann man auch jetzt schon ausprobieren How to Connect to Dynamics Navision Server From Power BI Desktop.
Bei einer DB-Größe von 900 GB würde ich immer zu einem Neustart raten. Wie groß und schwerfällig soll die denn noch werden in den nächsten Jahren? Die Technologie der Tabellenextensions hat das System nicht schneller gemacht, im Gegenteil.

bei uns steht das Thema "Move to Cloud" an […]
Und im Anschluss würden wir dann ein Projekt aufsetzen, um zu sehen, welches historisch übernommene Customizing wir mit BC Standard oder neuen Extension ablösen können.

Was genau ist bei euch die "Cloud"? SaaS,PaaS oder IaaS?
Wenn ihr damit SaaS meint, müsst ihr vorher das Projekt aufsetzen, nicht hinterher. Also aus euren Anpassungen eine PTE (Per-Tenant Extension) erstellen und dabei alle eigenen Erweiterungen aus den Standardobjekten entfernen. Die PTE könnt ihr dann auch unter SaaS weiternutzen, zusammen mit den anderen benötigten im AppSource.

Hallo Kowa
Danke für den Hinweis und den Link. Wir wollen wenn auf SaaS.
Wenn ich das richtig verstehe, würden wir also z.B. für den Customized Emailversand zuerst eine separate PTE erstellen, welche wir im Anschluss nach und nach in BC durch Standard oder eine neue Extension ablösen könnten (?) .
VG Anke

Sinnvoller erschiene mir zuerst zu schauen was anzupassen ist, das dann zu machen, und mit diesen Extensions dann in SaaS zu starten.

zuerst eine separate PTE erstellen, welche wir im Anschluss nach und nach in BC durch Standard oder eine neue Extension ablösen könnten (?) .

Ablösen kann man die nur, wenn man sie nicht mehr braucht .
Eine PTE ist für all die benötigte Funktionalität da, die sich weder im Standard noch in einer App im AppSource befindet, bzw. die man lieber selber programmiert /programmieren lässt, weil es langfristig billiger kommt, als eine App dafür zu bezahlen (d.h. diese zu mieten).
Also erst mal den aktuellen Standard prüfen, ob der das Benötigte mittlerweile abdeckt. Dann ggf. im AppSource schauen, ob jemand das Benötigte liefert.
Falls nicht oder preislich nicht attraktiv, eine Sandbox der aktuellen BC-Version erstellen und die PTE darin entwickeln. Der gesamte Endkundenbereich mit den Objekt-IDs 50000-99999 ist mittlerweile kostenlos verfügbar, benötigte Objekte muss man nicht mehr lizenzieren (seit BC 15).
Man kann zwar auch unter NAV 2018 schon rudimentäre Extensions entwicklen und dann später auf SaaS und die neueste Version anpassen, aber das ist nur zusätzliche Arbeit.

Vielen Dank enh und Kowa
ich werde euren wertvollen Input in unsere Überlegungen einfliessen lassen.
VG Anke

Tschuldigung, wenn ich höre oder lese jemand will ein ERP standardnah nutzen dann muss ich lachen.

Natürlich kann man nah am Standard bleiben. Es kommt auf das Geschäft an und darauf, welche Prozess man in der ERP abdecken möchte.
Auch der Vergleich mit dem Hammer hinkt gewaltig. Ein ERP ist kein Hammer, sondern eine Werkzeugkiste. Natürlich sind in einer Werkzeugkiste nicht alle Werkzeuge enthalten, aber für 90% der Fälle reicht es. Alles, was man nicht dabei hat, nennt sich Spezialwerkzeug und genau das sind die Apps auch.
Es ist auch nicht entscheidend, ob ich einen Prozess 500mal oder 1000mal am Tag ausführen muss. Es ist entscheidend, wie die Durchlaufzeit dabei ist und was ich ggf. automatisieren kann (mit Standardmitteln).
Abgesehen davon hat sich der Standard enorm weiterentwickelt, was die Basisfunktionalitäten angeht.
Statistiken und Verkaufshistorien kann man auch zusammentragen, wenn die alte DB weiterhin lesend zur Verfügung steht. Ggf. unterstützt man die Anforderung dann noch mit einem BI-Tool, welches aus beiden DBs liest.
Und die Lagerbewertung ist eh nicht korrekt wie reinske bereits geschrieben hat.

Bei einer DB-Größe von 900 GB würde ich immer zu einem Neustart raten. Wie groß und schwerfällig soll die denn noch werden in den nächsten Jahren? Die Technologie der Tabellenextensions hat das System nicht schneller gemacht, im Gegenteil.

Das ist aus meiner Sicht der einzig wahre Grund, nach dem man bewerten sollte, wieviele Daten man mitnehmen möchte in das neue System. Auch hier hatte reinske schon einen Hinweis gegeben:

- Performance (500 Mio. Posten in den 8 größten Postentabellen), Extensions sollen bei Postentabellen mit Mio. Einträgen die Performance zusätzlich senken)

Und bevor ich all meine uralten Anpassungen in einer PTE aufwendig nachprogrammiere, weil sie gar nicht mehr zu dem Standard von heute passen, prüfe ich doch eh, wie man den Prozess im Standard darstellen würde, um die ggf. nötige Anpassung an die richtige Stelle im neuen Standard zu packen. Daher enthält ein Projekt dieser Art sowieso immer einen gewissen Teil Restandardisierung. Und für den Rest der Prozesse muss man sich "nur" fragen, passe ich lieber meinen Prozess an den Standard an oder ist mir das so wichtig, dass ich den Standard anpassen möchte, mit all seinen Konsequenzen.

Hallo,

ob du das jetzt Hammer oder Werkzeugkiste nennst ist ziemlich gleich. Du hast ein spezielles Werkzeug/Hammer für eine spezielle Aufgabe.

Der Unterschied zwischen den Apps und einer Branchenlösung ist relativ groß. Während die Module einer bisherigen Branchenlösung meist aufeinander abgestimmt sind, hast du bei Apps das Problem, dass diese u.U. unterschiedliche Bedienkonzepte haben, und schon gar nicht kompatibel bzw. interoperabel zu den anderen installierten Apps sind, wenn du da nicht eingreifst, und PTE's installierst.
Beispiel aus einer Kunden- Anfordeung:
Eine angebundene Onlineplattform erwartet bei der vorhandenen Übertragung der Lieferdaten auch eine Trackinginformation für ein Retourenetikett. Das war so bisher nicht vorhanden.
Mal ganz davon abgesehen, das du dafür ein Spezialwerkzeug benötigt. das man nicht mal eben im App- Store laden kann, und wenn es eins gibt das dieses Problem löst, bietet es eine andere benötugte Funktion U.U. nicht.
In diesem Fall sind drei Module an diesem Vorgang beteiligt. Der Magento, der die Anforderung der Onlineplattform empfängt und dann an ein NAV-Modul weitergibt, das wiederum einen Auftrag anlegt.
Wenn der Auftrag geliefert wird, wird über ein weiteres Modul ein Versandetikett angefordert. Im Rücklauf werden die Tracking- Information an den Lieferschein übergeben und von dort wieder an das Modul für die Magento-Anbindung. Diese überträgt die Daten an den Magento, der wiederum die Online- Plattform bedient.
Damit man nun das Retouren- Etikett übertragen werden kann, muss man nun in allen Modulen Erweiterungen vornehmen, damit die Daten angefordert werden können, und zurück übertragen werden können.

Wie du das mit einer App aus dem App-Sstore erledigen willst, musst du mir mal erklären.

Das Schlimme ist außerdem. das sich solche Anforderungen regelmäßig ändern, weil die Plattformen regelmäßig Ihre APIs ändern, und der Markt regelmäßig neue Plattformen hervorbringt, musst du sehr flexibel reagieren können. Du musst also sehr schnell an deinen Werkzeugen herum feilen können. Da ist nichts mit Standard.

zu den 500 Mio- Posten muss man sich zunächst einmal fragen, wie alt die sind. Wenn die Posten nicht älter als 10 Jahre sind, musst du Sie eh aufbewahren. Du kannst jetzt zwar eine zweite DB aufbauen, aber was nützt dir das?

Innerhalb kürzester Zeit wird wieder eine große Menge Posten angefallen sein, die mit den Extensions nicht schneller werden. Du würdest das Problem einfach nur zeitlich verschieben, das Problem aber nicht lösen.

Gruß Fiddi

Ich weiß nicht genau, was du damit sagen möchtest. Nur weil du ein Beispiel hast, bei dem es nach oberflächlicher Betrachtung mal nicht so gut geklappt hat mit den zur Verfügung stehenden Erweiterungen, die du gefunden hast, heißt das ja nicht, dass man das als generelle Empfehlung ausgeben sollte.

Ich habe ja lediglich gesagt, dass ein ERP kein Hammer ist, sondern eine Werkzeugkiste. Soll heißen, ein Hammer ist ein Werkzeug, mit dem ich einen Nagel irgendwo reinhauen kann, mehr nicht. Mit einem Zimmermannshammer kann ich auch Nägel wieder herausholen, mit einem Vorschlaghammer kann ich auch Wände einreißen, mit einem Presslufthammer kann ich auch Straßen aufbrechen,... Heißt zwar alles Hammer, meint aber teilweise etwas ganz unterschiedliches. Daher der Vergleich mit der Werkzeugkiste, weil ich in einem ERP eben nicht nur ein Werkzeug habe, sondern viele. Kann es sein, dass das vorhandene Werkzeug trotzdem für meine Anforderungen nicht passt? Natürlich! In einer Werkzeugkiste werde ich sicherlich keinen Presslufthammer haben. Aber so zu tun, als ob ein ERP ein ganz simples Einfunktionswerkzeug wäre, verkennt nach meinem Dafürhalten die Bandbreite, die einem schon im Standard mitgeliefert wird.

Abgesehen davon, bei deinem Beispiel geht es um Schnittstellenanbindungen zu externen Systemen, ergo auch Abhängigkeiten von Dritten. Das ist aber nicht bei jeder Anforderung der Fall. Und mein Argument war ja auch nicht, nehmt bitte für alle Anforderungen Apps. Die Bewertung muss immer das anfordernde Unternehmen durchführen. Wenn einer meint, er ist mit einer individualisierten Anpassung schneller und besser am Markt als ein Anbieter, der sich nur auf diese Fragestellung fokussiert hat, dann soll er das tun. Ich kann nur daraus keine allgemeine Empfehlung abgeben, denn ich habe beides schon gesehen. Firmen, die sich mit ihrer Eigenentwicklung übernommen haben und denen dann ganz andere Probleme (wie z.B. Updatefähigkeit) ins Haus standen, als auch Firmen, die in ihrer Nische damit super gefahren sind. Meiner Erfahrung nach kommt das erste allerdings deutlich häufiger vor.

Dass ein System immer auch einen Lebenszyklus hat, muss ich dir, glaube ich, nicht erklären. Nur verstehe ich hier auch deinen Punkt nicht. Was soll denn die Alternative sein? Ich nehme die Daten direkt mit bei der Migration? Dann habe ich doch sofort die Probleme, die du als Argument lieferst, dass sie dann nur auf Zeit verschoben wären. Daher kann ich nur nochmal wiederholen, was ich schon gesagt habe. Wenn so viele Daten bestehen, dass sie zu einem Performanceproblem geworden sind oder in absehbarer Zeit führen werden und die Daten nicht anderweitig benötigt werden, dann ist es immer besser, diese einfach lesend im Altsystem zu belassen und im neuen System mit einer reduzierten Menge neu zu starten. Sonst verkürze ich ja sehenden Auges den Lebenszyklus meines Systems von vornherein.

Nur weil du ein Beispiel hast, bei dem es nach oberflächlicher Betrachtung mal nicht so gut geklappt hat mit den zur Verfügung stehenden Erweiterungen, die du gefunden hast, heißt das ja nicht, dass man das als generelle Empfehlung ausgeben sollte.

Das hängt immer damit zusammen, in welchen Bereichen du tätig bist. wenn du dich mehr auf den "Massenmarkt" konzentrierst, indem du möglichst viele Installationen deiner App erreichen möchtest, dann wirst du anders verfahren, als wenn du mehr in Projekten arbeitest, bei denen es darauf ankommt bestimmte Prozesse zu implementieren, die durch einen Business Case oder örtliche Gegebenheiten vorgegeben werden, dann findest du so etwas nicht im App- Store.

Ob ein ERP eine Werkzeugkiste oder oder EIN Werkzeug ist, darüber kann man sich streiten. Ich sehe das eher so, dass es sich dabei um EIN Werkzeug handelt, bei der die Funktionen aufeinander abgestimmt sind. Ähnlich einer Produktionsanlage bei der auch alle Produktionsschritte aufeinander abgestimmt werden müssen.

Nun, das Firmen keine Schnittstellen zu anderen System hat, mag vorkommen, ab einer gewissen Größe ist das aber eher normal, und wird eher schlimmer, kurzfristiger und spezieller.

Das eine Firma alles als Eigenentwicklung durchziehen soll, habe ich auch nicht gesagt. das kann und wird wahrscheinlich auch schief gehen, insbesondere dann, wenn derjenige der das Projekt vorangetrieben hat, die Firma verlässt.

Ob eine solche Anpassung in die Hose geht oder auch update fähig ist, hängt zum großen Teil von der Erfahrung der Entwickler ab. Wenn ich aber eine Produktion, ein Hochregal, und auch spezielle Anforderungen des Business Case unter einen Hut bringen muss, dann finde ich das nicht im App- store, da muss ich speziell anpassen.

Ob viele Daten ein Performance- Problem sind, hängt auch ein wenig von der Flexibilität des Systems ab. Wenn es schlecht programmiert ist, kann das auch schon bei seht geringen Datenmengen passieren. Dummerweise gibt es oft keine allgemeine Lösung für Performance Probleme. Nicht umsonst haben Leute wie Jörg Stryk genug zu tun, um langsame NAV- Systeme zum Laufen zu bringen, und schaffen das auch.

Die Frage ob man Daten übernimmt, kann man nicht pauschal beantworten, die Anzahl - auch bei ein paar Millionen Posten - sollte dabei aber eine untergeordnete Rolle spielen. Es kann aber sein, das die Posten so verbastelt oder hinüber sind, dass man nichts sinnvolles mehr damit anfangen kann, dann macht es natürlich keinen Sinn, da irgend etwas zu übernehmen. Sollen auch Fehler der Vergangenheit korrigiert werden (Lagerabgangsmethoden,...) muss man auch darüber nachdenken neu anzufangen.
Ich habe bisher nur in ganz wenigen Fällen erlebt, das die Anzahl der Posten wirklich die Ursache für Performance- Probleme sind. Schon aber das Performance Probleme durch Posten auftreten, weil Programmierer - auch im Standard - nicht nachgedacht haben. Und genau hier fehlt es mir im Moment an Flexibilität um die Probleme zu beheben.

Gruß Fiddi

Grundsätzlich muss man unterscheiden, ob als SaaS oder On-Premises weitergeht.

Nicht umsonst haben Leute wie Jörg Stryk genug zu tun, um langsame NAV- Systeme zum Laufen zu bringen, und schaffen das auch.

On-premises (bzw. als PaaS/IaaS) geht das sicherlich, aber unter SaaS sind diese Optionen gegenwärtig nicht gegeben.

Hier ist ein Thema bei Yammer, wo es um eine DB von 1,25 TB geht als SaaS,
https://www.yammer.com/dynamicsnavdev/t ... 1978231808
und J. Bulsink von MS eher davon abrät, solche Dimensionen dort zu betreiben, nicht nur wegen der Performance

[…]our cloud migration tooling should be able to handle this amount of data, but future environments operations (updates, restores, exports) may take very long to run

sondern auch wegen der erhöhten Kosten, da die Erweiterungen á 100 GB zusätzlich lizenziert werden müssen. Die Standardgröße für eine BC-Datenbank unter SaaS ist weiterhin 80 GB, alles weitere kostet extra.
Blogartikel von Tomas Kapitan mit Preisen (2021): D365 Business Central database capacity changes valid from the 1st of July
Learn: Managing Capacity

Ich habe bisher nur in ganz wenigen Fällen erlebt, das die Anzahl der Posten wirklich die Ursache für Performance- Probleme sind.

Mit vielen angehängten Table Extensions können sie das durchaus werden, das hat MS ja auch schon bestätigt.(Nachtrag: Ab BC 23 im neuen Datenmodell deutlich verbesserte Performance).

SaaS,PaaS oder IaaS?

Auch für BC soll jetzt ISV Cloud Embed kommen, also quasi "PaaS für Partner" .
https://twitter.com/JesperSchulz/status ... 27/photo/1
Hier wird es derzeit noch ausgeschlossen: https://azureopportunity.azurewebsites. ... Terms.html

Learn: Estimating the data size in your Business Central online tenant