Nachdem mit meiner ersten verbesserten Version des Importeres der Kundenimport möglich wurde, war m.E. im Importer immer noch eine hässliche Lücke vorhanden: die [B]Bestellungen [/B]aus dem xxCommerce-Shop wurden nicht importiert.
Ich habe den Importer jetzt so erweitert, dass auch die [B]Bestellungen [/B] importiert werden können, so dass man jetzt den kompletten Status des xxCommerce-Shops in OXID zur Verfügung hat, und komplett umstellen kann.
Was [B]nicht [/B]importiert wird sind die in den Bestellungen von xxCommerce-Shops evtl. enthaltenen [B]Attribute (Optionen) [/B]von Produkten in den Bestellungen.
Das Attribut-Konzept von xxCommerce-Shops und dem OXID-Shop ist einfach zu unterschiedlich, um hier etwas sinnvolles realisieren zu können.
Das ist aber m.E. nicht weiter schlimm, da die Hauptprodukte in der Bestellung enthalten sind, und die Preise auch i.O. sind. (Die Attribute in den Bestellungen von xxCommerce-Shops sind rein informativ.)
Die Hauptarbeit des Kopierens der Bestellungen und der Bestelldetails (Produkte) wird wieder per SQL erledigt.
Da aber einige Änderungen in den so importierten Bestelldaten nötig sind (z.B. Split des Straßennamens der Liefer- und Rechnungsadresse in Name und Nummer, setzen der [B]Länderkennung[/B] in der Liefer- und Rechnungsadresse, setzen des [B]Bestellstatus[/B], Konvertierung der [B]Zahlungsart [/B]von xxCommerce-Bezeichnungen zu den OXID-Bezeichnungen u.ä.) muss nach dem Kopieren die Bestelltabelle noch einmal durchlaufen werden, um diese Werte zu setzen.
Weiterhin müssen aber vor allem für die OXID-Bestelltabelle noch einige wichtige Angaben (z.B. Brutto-/Netto-Bestellwert, Steuerwerte, Zuschläge für Liefer- und Zahlungsart u.ä.) aus einer 3. xxCommerce-Tabelle ("[B]ot_total[/B]") ermittelt und gespeichert werden, da xxCommerce diese Daten nicht in der Bestelltabelle führt.
Eine Bemerkung zu den [B]Zahlungsarten[/B]:
Hier kann es vorkommen, dass (bei den Zillionen von verfügbaren Zahlungsarten für xxCommerce) der Importer nicht alle solche Zahlungsarten kennt.
Derzeit sind in der Datei “[B]_config.inc.php[/B]” folgende Übersetzungen definiert:
//Avenger
//Translation table of xtc (and family!) payment-types to OXID payment types
//'xxComerce-payment-type-name'=>'OXID-payment-type-name'
$payment_types=array(
'banktransfer'=>'oxiddebitnote',
'cash'=>'oxcash',
'cc'=>'oxidcreditcard',
'cod'=>'oxidcashondel',
'eustandardtransfer'=>'oxidinvoice',
'invoice'=>'oxidinvoice',
'ipayment'=>'oxidcreditcard',
'moneyorder'=>'oxidinvoice',
'paypal'=>'oxpaypal',
'uos_kreditkarte_modul'=>'oxidcreditcard',
'uos_lastschrift_at_modul'=>'oxiddebitnote',
'uos_lastschrift_de_modul'=>'oxiddebitnote',
'uos_vorkasse_modul'=>'oxidpayadvance',
);
//Avenger
Wenn der Importer eine xxCommerce-Zahlungsart findet, die in dieser Tabelle nicht definiert ist, wird während des Imports eine entsprechende Meldung angezeigt.
Wenn es für diese unbekannte Zahlungsart im OXID-Zielsystem eine entsprechende Zahlungsart gibt, kann man diese Tabelle entsprechend erweitern, und den Import wiederholen.
Falls nicht, ist das m.E. auch nicht weiter tragisch, da die importierten Bestellungen ja doch eher informativen Charakter haben.
Noch eine kleine Erweiterung:
Bei den Produkten wird jetzt auch die Information über die bisher verkauften Menge importiert.
[B]Im Anhang das Zip-Archiv mit der neuen Version.[/B]
Bitte um Test, Plausibilitätsprüfung der importierten Bestellungen und Feedback.
Wenn das dann auch “in freier Wildbahn” OK ist, kann ich das Modul in Exchange bereit stellen, damit das nicht verloren geht.
