Neu Amicron Faktura zu JTL Wawi?

[ExFaktura]

Hallo,

gibt es hier jemanden der umgestiegen ist und noch Notizen oder scripte für den Datentransfer hat?

Wenn es wirklich dazu kommt, machen wir das selber im Detail, aber es geht aktuell um erste Tests, da will ich keine Wochen drann arbeiten.

 

[ExFaktura]

Nett wären auch weitere Infos zu euren Erfahrungen, läuft das stabil etc.
Amicron ist ja wirklich nicht zum Abstürzen zu bewegen, es lief immer top stabil, was fehlt ist eine API, viele Felder und Automationen.
Insgesammt ist Amicron wohl eher was für kleine Vertriebe, aber nichts für eine Shopanbindung. Es gibt nicht mal Preisspecials.
Wir benutzen Magento 2.

 

[ExFaktura]

Ich habe mir jetzt die 2-3 Videos zur Ameise angeschaut. Dabei kam eine ganz grundsätzliche Farge auf:

Wie gehe ich mit Foreign Key Constraints um?


Ausgedachtes Beispiel (hab das exakte Amicron Faktura-Layout nicht hier):

Die Haupttabelle Artikel setzt ein Lager voraus und setzt in der Sub-Tabelle "Lagerzuordnung" eine LFDNR voraus, die dann in die Tabelle "Lager" führt.
Wohin sollte ich die "LFDNR" (KEY) importieren und in welche Reihenfolge importiere ich die drei Tabellen?

Wie ich das in SQL machen würde, ist klar.
Aber ich vermute, ich kann die Amicron Faktura Keys nicht in die JTL eigenen KEYS eintragen lassen?

 

[mh1]

Was verstehst du unter AF Keys?

 

[ExFaktura]

habs geändert AF = Amicron Faktura.

 

[mh1]

Die JTL Datenbank verwaltet selber die Schlüsselwerte, also z.b. das Feld kArtikel in der Tabelle tArtikel
Amicron Factura hat die Keys und deren Beziehungen auch selber verwaltet.
Jedes Programm bzw jede Datenbank sollte seine Keys selber verwalten.
Es macht keinen Sinn, die Keys vom alten Programm in das neue zu übernehmen.

Was ist der Grund, dass du die Keys aus Amicron Factura nach JTL übernehmen willst?

Tipp: mach doch testweise mal einen Import von deinem Artikelstamm in ein JTL Testsystem. Dann siehst du, welche Daten dort wie ankommen und wo du ggf. noch etwas ändern musst.
Meiner Erfahrung nach ist die Datenübernahme eines bestehenden Systems sowieso sehr komplex und erfordert viele Tests.

 

[ExFaktura]

Die JTL Datenbank verwaltet selber die Schlüsselwerte, also z.b. das Feld kArtikel in der Tabelle tArtikel
Amicron Factura hat die Keys und deren Beziehungen auch selber verwaltet.
Jedes Programm bzw jede Datenbank sollte seine Keys selber verwalten.
Es macht keinen Sinn, die Keys vom alten Programm in das neue zu übernehmen.

Was ist der Grund, dass du die Keys aus Amicron Factura nach JTL übernehmen willst?

Tipp: mach doch testweise mal einen Import von deinem Artikelstamm in ein JTL Testsystem. Dann siehst du, welche Daten dort wie ankommen und wo du ggf. noch etwas ändern musst.
Meiner Erfahrung nach ist die Datenübernahme eines bestehenden Systems sowieso sehr komplex und erfordert viele Tests.

Ah, danke, also "K" = Key?

Es geht eben darum das z.B. Artikel-Gruppen zu den Artikeln verknüpft werden. Also das Verhalten der Haupttabellen sollte nach dem Import zumindest weitgehend so sein, wie wir das jetzt haben.

Ja, natürlich hast Du recht, ich mach jetzt einmal mal ein paar kleine Importtests. Ich hatte nur gehofft es gibt jemanden der den Weg schomal gegangen ist.

 

[mh1]

Ah, danke, also "K" = Key?

Es ist keine Vorgabe des SQL-Servers, dass das so sein muss, aber JTL hat seine Datenbank netterweise so aufgebaut, dass die meisten Datenbankobjekte einen sprechenden Namen haben.
Zum Beispiel heißt die Tabelle wo die Kunden drinstehen tKunde. Und dort gibt es ein Feld kKunde. Das ist der Primary Key dieser Tabelle.
Oder es gibt ein Feld cName, da stehen Zeichen (Character) drin. Im Feld dAngelegt steht ein Datumswert u.s.w.
Das ist super, wenn du z.B. direkt mit SQL was aus der Datenbank liest, dann weißt du direkt mit was du es zu tun hast.

Ja, natürlich hast Du recht, ich mach jetzt einmal mal ein paar kleine Importtests.

Viel Erfolg bei der Datenübernahme. Tipp: testen, testen, testen.... und am besten vor jedem neuen Test alles wieder auf Anfang, also mit einer neuen leeren DB starten.

Datenübernahmen aus einem Altsystem sind immer sehr aufwendig und zeitintensiv.
Es gibt auch meistens keine Standardwege, sondern man muss immer die eigenen Daten anschauen, analysieren und genau überlegen wie man diese Daten im neuen System abbilden kann. Weil einfach nur z.B. den Artikelstamm aus dem Altsystem eins zu eins im neuen System abzubilden ist meist nicht möglich. Der Teufel steckt dann meist im Detail und das findet sich dann nur durch Tests.
Von Vorteil ist ein Servicepartner, der das neue System, also die JTL Wawi genauestens kennt.

Ich hatte nur gehofft es gibt jemanden der den Weg schomal gegangen ist.

@RoyausHoy hier im Forum kam damals von Amicron.

Hast du im Forum schonmal gesucht, oder nur hier diese Frage gestellt? Kennst du z.B. das:
https://forum.jtl-software.de/threads/datenuebernahme-aus-amicron-11.70827/
https://forum.jtl-software.de/threa...ngebote-aus-amicron-nach-jtlw-moeglich.42588/

 

[recent.digital]

Viel Erfolg bei der Datenübernahme. Tipp: testen, testen, testen.... und am besten vor jedem neuen Test alles wieder auf Anfang, also mit einer neuen leeren DB starten.

Datenübernahmen aus einem Altsystem sind immer sehr aufwendig und zeitintensiv.
Es gibt auch meistens keine Standardwege, sondern man muss immer die eigenen Daten anschauen, analysieren und genau überlegen wie man diese Daten im neuen System abbilden kann. Weil einfach nur z.B. den Artikelstamm aus dem Altsystem eins zu eins im neuen System abzubilden ist meist nicht möglich. Der Teufel steckt dann meist im Detail und das findet sich dann nur durch Tests.
Von Vorteil ist ein Servicepartner, der das neue System, also die JTL Wawi genauestens kennt.

Bei Datenmigrationen mindestens 6 Augen-Prinzip umsetzen, das hilft Fehler zu finden. Wenn hier etwas nicht klappt, zieht man den Umstand in der Regel lange mit sich (insbesondere wenn er nicht schnell auffällt).