Xtc2oxid jetzt mit Import der Bestellungen!

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.

Hallo,

also, mein erstes Fazit:

Trotz angemeldetem Admin (Firefox Browser) wird mir die Meldung ausgegeben, dass ich nicht als Admin angemeldet bin.

Habe nun in der xtc2oxid.php die Zeilen 80 bis 98 auskommentiert, damit ich überhaupt testen kann.

Der Importer läuft durch, folgende Daten sind jedoch [B]NICHT[/B] vorhanden:

  • Customers
  • Newsletterempfänger stehen alle in der oxnewssubscribed in OXDBOPTIN auf 0, was ein unschöner Status ist, da dies bedeutet, sie hätten sich alle abgemeldet.

Bestellungen wurden schön übernommen und sind bei einer ersten Durchsicht valide.

[QUOTE=Christian76;14409]
Trotz angemeldetem Admin (Firefox Browser) wird mir die Meldung ausgegeben, dass ich nicht als Admin angemeldet bin.[/QUOTE]

Die Erkennung des Admin-Login-Status ist nur erfolgreich, wenn man sich [B]im Shop-Front-End[/B] als Admin einlogged.

[QUOTE=Christian76;14409]…folgende Daten sind jedoch [B]NICHT[/B] vorhanden:

  • Customers[/QUOTE]
    Das kann ich bei mir nicht nachvollziehen, die Kunden werden hier erfolgreich importiert. :confused:

Ich habe bei dem Kunden-Import jetzt eine Prüfung auf einen SQL-Fehler eingebaut, mal sehen, ob man damit die Ursache findet.

[B]Falls nicht[/B]:

könntest Du mir die xtc-Tabellen “[B]address_book[/B]” und “[B]customers[/B]” als PHPMyAdmin-SQL-Dump zur Verfügung stellen, damit ich das hier mal untersuchen kann?

[QUOTE=Christian76;14409] - Newsletterempfänger stehen alle in der oxnewssubscribed in OXDBOPTIN auf 0, was ein unschöner Status ist, da dies bedeutet, sie hätten sich alle abgemeldet.[/QUOTE]
Der Importer hat den Newsletterstatus nicht übernommen, sondern der blieb auf 0.

Habe ich geändert, so dass der xxCommerce-Status übernommen wird (der zufällig gleich wie bei OXID ist).

Dann habe ich beim Bestellimport noch ein Problem korrigiert:

die [B]Produkt-Umsatzsteuer[/B] war falsch importiert.

Im Anhang ein Ausschnitt einer Rechnung für eine importierte Bestellung.
(Glückliche Schweiz, nur 7,6% MwSt.!)

Die aktualisierte Version ist im Anhang.

Hi,

probiere es gleich mal aus.

So, dies sieht nun sehr gut aus.
Der fehlerhafte Customer Import lag an einer unterschiedlichen latin1. XTC hatte latin1_german_ci, Oxid latin1_general_ci. Damit wollte er nicht. Die Customer werden nun übernommen, zur Validierung bin ich noch nicht gekommen.

Newsletter schaut jetzt auch gut aus, prima.
Der Order-Import läuft noch und wird auch noch lange dauern, da ich gerade keine Zugriff auf meine Testmaschine habe und dies auf einem Laptop durchführe was nicht so leistungsfähig ist.

Login mit Admin geht nun auch.

Erstes Fazit ist schon mal wirklich positiv.

[QUOTE=Christian76;14480]So, dies sieht nun sehr gut aus.
Der fehlerhafte Customer Import lag an einer unterschiedlichen latin1. XTC hatte latin1_german_ci, Oxid latin1_general_ci. Damit wollte er nicht. [/QUOTE]
Hat das Programm jetzt eine entsprechende Fehelrmeldung angezeigt, oder wie hast Du das Problem erkannt?

Hi,

das Programm von Dir hat die Fehlermeldung ausgegeben - somit war gleich klar was Sache ist. Top!

[QUOTE=Christian76;14490]Hi,

das Programm von Dir hat die Fehlermeldung ausgegeben - somit war gleich klar was Sache ist. Top![/QUOTE]
Schön, dann klappt das ja mit der Fehlerprüfung…

Das mit den unterschiedlichen Zeichensätzen der Ziel- und Quelldatenbank ist in der Tat ein Problem.,

Habe aber noch keinen Weg gefunden, das in den SQL-Statements automatisiert zu lösen (z.B. über eine explizite Zeichensatzdefinition der Tabellen).

Hat dazu evtl. jemand eine zündende Idee?

[QUOTE=avenger;14500]
Habe aber noch keinen Weg gefunden, das in den SQL-Statements automatisiert zu lösen (z.B. über eine explizite Zeichensatzdefinition der Tabellen).

Hat dazu evtl. jemand eine zündende Idee?[/QUOTE]

Allgemein:
http://dev.mysql.com/doc/refman/5.0/en/charset-show.html

Eine Tabelle -> Collation der Spalten.
http://dev.mysql.com/doc/refman/5.1/en/show-table-status.html

SHOW FULL COLUMNS FROM `oxarticles` WHERE 1

Datenbank -> Collation der Tabelle.
http://dev.mysql.com/doc/refman/5.1/en/show-table-status.html

SHOW TABLE STATUS FROM dbName

Denke, das hilft.

[QUOTE=MBa;14504]Allgemein:
http://dev.mysql.com/doc/refman/5.0/en/charset-show.html

Eine Tabelle -> Collation der Spalten.
http://dev.mysql.com/doc/refman/5.1/en/show-table-status.html

SHOW FULL COLUMNS FROM `oxarticles` WHERE 1

Datenbank -> Collation der Tabelle.
http://dev.mysql.com/doc/refman/5.1/en/show-table-status.html

SHOW TABLE STATUS FROM dbName

Denke, das hilft.[/QUOTE]
Die Doku habe ich mir schon zu Gemüte geführt…

Die “Collation” der Tabelle habe ich schon ermittelt, aber den “Character Set” kann ich in den Informationen nirgends finden…

[QUOTE=avenger;14509]Die Doku habe ich mir schon zu Gemüte geführt…

Die “Collation” der Tabelle habe ich schon ermittelt, aber den “Character Set” kann ich in den Informationen nirgends finden…[/QUOTE]

Bin mir da auch nicht sicher, glaube aber wenn Du die colation hast, dann kansst Du

SHOW CHARACTER SET WHERE `Default collation` LIKE '".$colation."';

http://dev.mysql.com/doc/refman/5.0/en/charset-show.html

The character set is not part of the display but is implied by the collation name.

Ich glaube, wenn ich das richtig verstehe, ist der C-Set so hinterlegt.

Die Bestellungen funktionieren super. Allerdings kriege ich die Kunden nicht rein, was mit einer älternen Version schon mal funktioniert hat. Ich habe nun mal die xtc2oxid.php geändert, habe quasi alles ausgesternt, bis auf den Customer Import:

<?php

//(c)2009 OXID eSales AG
//This script imports OS Commerce shop catalog to OXID eShop
//What's imported:
// Manufacturers, categories, product info, products in categories, images, reviews.
// It tries to convert OSCommerce options to OXID variants.
//Script automatically sets OXID lanuage config array according to OSCommerce languages.
//[email protected]
//
//This script also supports data import from XTCommerce (extended OSCommerce clone)
//In this case additionally product search keywords, short description, EAN, image array,
//general scale prices, crosseling, category short/long description,
//newsletter subscriber list are imported and tag cloud are generated.
//
//Set configuration params in _config.inc.php
//and run this script from command line (recommended):
//>php osc2oxid.php

/*
(c)2009 Avenger, [email protected]

2009-09-10

The osc2oxid/xtc2oxid importers needed some enhancements, in order to import osc/xtc-data correctly.

First of all, a security issue has been fixed: you must be logged in as an administrator in order to use the program.

The ID of the active language is determined from the source database, instead of using the fixed ID "1", as the importer did (which was wrong at least for xtc, as 1 is the ID for the english language).

The tax-rates for the store-country and -zone are determined from the source database.

These are used on product-import to calculate the product's gross price from xtc's net price.

If the product uses a tax-rate different form OXID's standard tax-rate (e.g. 7%), then this tax-rate is stored with the product.

The product's "active" state is taken from the source-product's "active" information, instead of setting it always to "active".

The categorie's "hidden" state is taken from the source-categories's "active" information, instead of leaving it always "not hidden".

If a product containde more then 5 images, PHP warnings were generated

Also customer-data can now be imported.

The importer's ability to import product attributes is  v e r y  limited, as it stores the osc/xtc )attributes as OXID variants.

This means, you will can have 1(!) attribute-group in OXID, regardless of the number of attribute-groups a product has in xtc/osc.

The importer code, however, processes all option groups and options a product has in osc/xtc, storing different data for the same product redundantly, which is uselessly time consuming with a large number of attributes.

The importer code has been modified, so that only the data of the first option-group is processed.

2009-09-17

The importer has been extended to allow also order import

*/

define('IS_ADMIN_FUNCTION',true);
$iStartTime = time();

//CONFIGURATION
require_once("_config.inc.php");
require_once("_functions.inc.php");

//IMPLEMENTATION
set_time_limit(0);

//language count
$iLangCount = 4;


global $sOxidConfigDir;

//init OXID framework
@include_once($sOxidConfigDir . "_version_define.php");
require_once($sOxidConfigDir. "core/oxfunctions.php");
require_once($sOxidConfigDir. "core/adodblite/adodb.inc.php");

//Avenger 
//Make sure user is logged in as admin!!!
/*$myConfig = oxConfig::getInstance();
$user=oxSession::getVar('usr');
if (!$user)
{
  //If not logged in as user, try admin login
  $user=oxSession::getVar('auth');
}
if (strpos($user,'admin')===false)
{
  die('Für den Daten-Import müssen Sie als Administrator eingelogged sein!');
}  */
//default OXID shop id
$sShopId = 'oxbaseshop';
//Avenger 

if ($blIsXtc)
    $oIHandler = new XtImportHandler($sShopId);
else
    $oIHandler = new ImportHandler($sShopId);

//connect to db
//$oIHandler->mysqlConnect();
//empty tables:
//$oIHandler->cleanUpBeforeImport();

printLine("<pre>");

//--- LANGUAGES ----------------------------------------------------------
//printLine("SETTING LANGUAGES");
//$oIHandler->setLanguages();
//printLine("Done.
");
//------------------------------------------------------------------------

//--- CUSTOMERS ------------------------------------------------------
printLine("IMPORTING CUSTOMERS");
$oIHandler->importCustomers();
printLine("Done.
");
//------------------------------------------------------------------------

//--- MANUFACTURERS ------------------------------------------------------
//printLine("IMPORTING MANUFACTURERS");
//$oIHandler->importManufacturers();
//printLine("Done.
");
//------------------------------------------------------------------------

//--- CATEGORIES ---------------------------------------------------------
//printLine("IMPORTING CATEGORIES");
//printLine("Get categories..");
//$oIHandler->importCategories();
//printLine("Rebuilding category tree..");
//$oIHandler->rebuildCategoryTree();
//printLine("Done.
");
//------------------------------------------------------------------------

//--- PRODUCTS -----------------------------------------------------------
//printLine("IMPORTING PRODUCTS");
//printLine("Get Products..");
//$oIHandler->importProducts();
//printLine("Get Relations..");
//$oIHandler->importProduct2Categories();
//printLine("Get Reviews..");
//$oIHandler->importReviews();
//printLine("Handle variants(options)..");
//$oIHandler->importVariants();
//printLine("Extended info..");
//$oIHandler->importExtended();
//printLine("Done.
");
//------------------------------------------------------------------------

//--- ORDERS ------------------------------------------------------
//printLine("IMPORTING ORDERS");
//$oIHandler->importOrders();
//printLine("Done.
");
//------------------------------------------------------------------------

//--- IMAGES -------------------------------------------------------------
//printLine("COPYING IMAGES");
//printLine("Handle manufacturer icons..");
//$oIHandler->handleManufacturerImages();
//printLine("Handle category icons..");
//$oIHandler->handleCategoryImages();
//printLine("Handle product images..");
//$oIHandler->handleProductImages();
//printLine("Done.
");
//------------------------------------------------------------------------

/*printLine("IMPORT DONE!");

printLine("</pre>");*/
?>

Beim Starten des Skriptes bekomme ich folgende Feme, es wird nix importiert:

IMPORTING CUSTOMERS
Done.



Warning:  Unknown: open(/tmp/sess_ad84920b668e3e9a3eb03e3e984e83f7, O_RDWR) failed: Permission denied (13) in Unknown on line 0



Warning:  Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/tmp) in Unknown on line 0

Gibt es hier eine Idee ? Ansonsten funktioniert alles perfekt.

Da hat wohl der Ordner “tmp” keine Schreibrechte.

Setze die Rechte mal auf “777”.

Beim Kundenimport wird dort nämlich eine Text-Datei mit allen eMail-Adressen der importierten Kunden erstellt, damit man diese einfach informieren kann.

OK, wer lesen kann, ist klar im Vorteil. Permission denied :slight_smile:
Allerdings habe ich auch das Collation Problem, wie der Kollege im Thread. Das muß ich nun erst mal lösen. Dann wird es schon klappen. Danke

Habe nun alles importiert. Funktioniert wunderbar !!! Kann ich nur empfehlen

So, bin nun an der Datenvalidierung und gleich mal auf ein Problem gestoßen. Der Kundenimport scheint funktionell zu sein, jedoch funktioniert die “Passwort erinnern” Funktion im Shop nichtl Die Kunden werden als aktiver Kunde importiert, Haken ist da. Unter “hat ein Passwort” steht “nein”. Auch korrekt (leider), an und für sich kein Problem, weil sich kein Kunde ohne Passwort anmelden kann. Nutzt man nun die Passwort erinnern Funktion erscheint “Die eingegebene E-Mail-Adresse ist ungültig. Bitte geben Sie eine gültige E-Mail-Adresse ein.”.

[QUOTE=Christian76;15491]So, bin nun an der Datenvalidierung und gleich mal auf ein Problem gestoßen. Der Kundenimport scheint funktionell zu sein, jedoch funktioniert die “Passwort erinnern” Funktion im Shop nichtl Die Kunden werden als aktiver Kunde importiert, Haken ist da. Unter “hat ein Passwort” steht “nein”. Auch korrekt (leider), an und für sich kein Problem, weil sich kein Kunde ohne Passwort anmelden kann. Nutzt man nun die Passwort erinnern Funktion erscheint “Die eingegebene E-Mail-Adresse ist ungültig. Bitte geben Sie eine gültige E-Mail-Adresse ein.”.[/QUOTE]
Habe mir das mal im Code angesehen…

Mit folgendem SQL wird prüft OXID bei der Passwort-Funktion, ob die eMail-Adresse im System bekannt ist:

select oxid from oxuser where oxuser.oxactive = 1 and oxuser.oxusername = '[email protected]' and oxuser.oxpassword != '' order by oxshopid = 'oxbaseshop' desc

Da kein Passwort importiert wird, wird die eMail-Adresse wegen der Bedingung "oxuser.oxpassword != ‘’ nicht gefunden, da kein Passwort vorhanden ist…

D.h., beim Import der Kundendaten muss irgendwas in das Feld “oxpassword” geschrieben werden…

Habe den Importer entsprechend angepasst…

Hallo!

Kann mir irgendjemand erklären woher dieser Fehler kommt?

IMPORTING CUSTOMERS
importCustomers – Unknown column ‘c.customers_date_added’ in 'field list’
Done.

lg
Alex

Da fehlt das Feld “'customers_date_added” in der “customers”-Tabelle der xtCommerce-Datenbank.

Was für eine xtc-Version ist das denn?

Version 3.0.3… ist schon etwas alt. sollte jetzt umgestellt werden auf oxid.