Datenauswertung

[ShopNix]

Amazon Connector

Da werden wir nicht zusammen kommen. Wenn's nicht mit aller Gewalt sein muß, unterstütze ich die Riesen nicht.

[ShopNix]

Das ist doch eigentlich ein k.o.-Kriterium bei einem ERP, bei dem die Buchhaltung doch den zentralen Bestandteil darstellt.

Das soll inzwischen besser sein. Es hat sich schon von Version 5 auf 6 in dieser Hinsicht viel getan, das Problem ist also erkannt. Die aktuelle Version 7 habe ich noch nicht unter die Lupe genommen.

Über den zentralen Bestandteil streiten sich die Gelehrten. Ich sehe den eher in der Beschaffung und ggfls der Produktion. Wie der Name schon sagt: Enterprise Ressource Planning.

Bevor wir allerdings einen unsinnigen Streit über den zentralen Bestandteil führen: Es gibt eine Reihe von k.o.-Kriterien, und alle müssen erfüllt sein.

[Alfred]

.... Magento ..... massiv seo optimiert.

Wer es glaubt... Wie kommst du darauf?

Gruß

[Matt]

Wer es glaubt... Wie kommst du darauf?

Steht bestimmt in irgendwelchen bunten Broschüren Dann muss es ja stimmen.

[noRiddle (revilonetz)]

einschließlich der Implementation eines EKs bei allen Produkten und der stimmigen Ausgabe eines Rohgewinnes

Der EK hat nichts im Shop zu suchen.

Wegen der Sicherheitslücke die wir noch nicht kennen.
Die kann bei php 8.0, beim IE15 oder beim Win10 existieren.

Das ist nur ein möglicher Grund.

Muß ich das verstehen ?
Wie meinst du das ?
EK nicht in Shop-DB ?
Aufgrund von evtl. zukünfig sich auftuenden Sicherheitslücken ?
Häää ?

Verzeih mir, ich komme da nicht mit.

Gruß,
noRiddle

[michafn]

der Ton ist hier gerade nicht mehr so recht konstruktiv stelle ich fest, daher mal um wieder auf das eigentliche Thema zu fokussieren und nicht in Grabenkämpfe abzudriften:
macht BI (sei es als Modul oder externer Service) auf Basis der Daten im Shop Sinn, besteht Bedarf an so etwas.
Da EK Preislisten zur Beschaffung gehören und die entsprechenden Kontrakte selbstverständlich im ERP gepflegt werden, werden Margenberechnungen aufgrund des Webshops ohne Erweiterung schwierig, evtl. kann aber ein Mehrwert darin liegen die Entwicklung der Verkäufe zu tracken, Trends zu identifizieren und Optimierung der Produktpalette. Auch wenn es sicherlich mehr Sinn macht, dieses BI im backend aufzuhängen, würde ich sagen, dass viele Shopbetreiber kein vernünftiges Backend haben und daher diese Auswertungen so nicht bekommen können (z.B. CAO kann so etwas nicht vernünftig).

[noRiddle (revilonetz)]

Was ist daran nicht konstruktiv ?
Nicht konstruktiv sind lapidare Aussagen wie "Der EK gehört nicht in den Shop".

Man kann da verschiedener Meinung drüber sein, ja, ich finde es allerdings gut den EK im Shop zu hinterlegen.
Ich kann auch nicht die komlexen Implementationen mit Konnektoren nachvollziehen.
Der Shop hat eine Datenbank in der alle nötigen Informationen enthalten sind.
Aber macht Ihr mal, ich bin lediglich der Aufforderung gefolgt mal etwas zum Thread-Thema zu sagen.

Wenn die Meinung besteht EKs gehören in die externe WaWi / ins externe ERP, dann auch BI.
ohne EK, Rohgewinn usw. macht eine BI-Implementation wenig Sinn.
Ansonsten würde eine lediglich gefixte Statistik ausreichen
(Backend => Statistiken => Umsatzstatistik und Backend => Statistiken => Verkaufte Artikel).
Ich muß da keine Bildchen und Diagramme haben um die Statistik zu verstehen.
ein Diagramm bedarf immer der Interpretation, Zahlen sind eindeutig.

Gruß,
noRiddle

[michafn]

"Aber macht Ihr mal, ich bin lediglich der Aufforderung gefolgt mal etwas zum Thread-Thema zu sagen."

nunja, das ist nicht destruktiv aber auch nicht sehr konstruktiv sondern eher "wenn ihr denkt ihr wisst es besser macht halt", nichts für ungut Es ging mir eher darum gemeinsam ideen zu entwickeln in Richtung Dashboard für kleine Shops, die nicht gerade ein SAP o.ä. als backend haben. Ich habe das für mich spasseshalber gemacht und fand es eine nette Ergänzung für einen webshop.

Ich glaube auch nicht, daß die konkrete Implementierungsfragen, welche Daten ich von wo ziehe diskutiert werden muss. Ein Webshop ist nunmal ein Frontend (daher ist diese Aussage mit dem EK auch nicht lapidar, es sei denn du wickelst deine Beschaffung über den Shop ab, dann sollte der EK auch vorhanden sein), ein Kanal, und keine Warenwirtschaft und das ist ja auch gut so, dafür gibt es ja entsprechend mächtige Backendlösungen. Und Preisfindung im Rahmen der Beschaffung ist nun einfach mal ein sehr komplexes Thema und nicht einfach mit einem weiteren Feld getan.

Mir ging es lediglich darum mal eine Diskussion loszutreten was sich andere Shopanwender wünschen würden, um dann zu schauen was man vielleicht umsetzen kann.
Ich habe gelernt, daß dir die Zahlen ausreichen, ich persönlich erfasse Graphen schneller als Tabellen und ja natürlich ist es nur eine Visualisierung, die absoluten Zahlen müssen natürlich immer sichtbar sein und es darf kein Interpretationsspielraum dabei geben, aber das ist ja eben auch die Herausforderung dabei

[noRiddle (revilonetz)]

Ich will deine Idee keinesfalls schmälern und es sieht ja auch schick aus.

Was den EK betrifft kenne ich eine ganze Reihe Shopbetreiber die keine WaWi oder ein ERP haben.
Sie müssten Ihre EKs aus Ihrem Papierkram raussuchen.
Die haben alle ein EK-Feld in der Artikelbearbeitung und können so leicht mal den EK nachschauen.
Der Nachteil ist, es muß bei Eintreffen neuer Ware eines Artikels mit anderem EK ertsmal anhand des alten EKs, des Bestandes, des neuen EKs und neuen Bestandes ein Misch-EK errechnet werden.
Aber auch dies ist programmtechnisch automatisierbar,
insofern die Lagerverwaltung des Shops stimmig ist,
was sie leider Attribute betreffend nicht ist.

Jedenfalls ist das für viele kleinere Shopbetreiber eine hilfreiche Sache mit dem EK.

Da ich auch nicht auf Gefrickel stehe werde ich das mal nebenbei so umbauen, daß alles funktioniert.
Lagerverwaltung (evtl. per Master-Slave), EK und Misch-EK.
Damit kann man dann auch perfekte Statistiken ausgeben.

Nach meiner Meinung würde das das Shopsystem stark aufwerten, sowas hat nämlich keiner, eine, wie ich es nenne Mini-WaWi im Shop.

Ich bitte um Vergebung, denn dein Anliegen war ja erstmal ein anderes.
Ich finde aber, daß da die oben ausgeführten Zusammenhänge bestehen die das ganze erst interessant machen würden.

Gruß,
noRiddle

[webald]

Ich habe mal ein kleines Script um die komplette DB in eine XML-Datei zu speichern.

Ich erhalte aber beim Versuch diese in Excel zu öffnen immer eine Parse-Fehler. Aber ich sehe den beim besten Willen nicht. Wenn es bei jemand anderen funktioniert ist das ja gut.

Code: PHP  [Auswählen]

// #region externe Dateien
include('../includes/configure.php');
include('../includes/database_tables.php');
// include ('../includes/application_top.php');
// Store DB-Querys in a Log File
define('STORE_DB_TRANSACTIONS', 'false');
// Database
require_once (DIR_FS_INC.'xtc_db_connect.inc.php');
require_once (DIR_FS_INC.'xtc_db_close.inc.php');
require_once (DIR_FS_INC.'xtc_db_error.inc.php');
require_once (DIR_FS_INC.'xtc_db_perform.inc.php');
require_once (DIR_FS_INC.'xtc_db_query.inc.php');
require_once (DIR_FS_INC.'xtc_db_queryCached.inc.php');
require_once (DIR_FS_INC.'xtc_db_fetch_array.inc.php');
require_once (DIR_FS_INC.'xtc_db_num_rows.inc.php');
require_once (DIR_FS_INC.'xtc_db_data_seek.inc.php');
require_once (DIR_FS_INC.'xtc_db_insert_id.inc.php');
require_once (DIR_FS_INC.'xtc_db_free_result.inc.php');
require_once (DIR_FS_INC.'xtc_db_fetch_fields.inc.php');
require_once (DIR_FS_INC.'xtc_db_output.inc.php');
require_once (DIR_FS_INC.'xtc_db_input.inc.php');
require_once (DIR_FS_INC.'xtc_db_prepare_input.inc.php');
require_once (DIR_FS_INC.'xtc_get_top_level_domain.inc.php');

// require_once ('../admin/includes/functions/general.php');

// make a connection to the database... now
xtc_db_connect() or die('Unable to connect to database server!');

// security
define('_VALID_XTC',true);
include('../admin/includes/classes/categories.php');
include ('../admin/includes/functions/general.php');
require_once (DIR_FS_INC.'xtc_not_null.inc.php');
require_once (DIR_FS_INC.'xtc_validate_password.inc.php');

// Pull in the NuSOAP code
// require_once('../services/nusoap/lib/nusoap.php');
// #endregion

$date1=date("Ymd");

$xmlfile = 'db_'.DB_DATABASE.'_'.$date1.'.xml';
$fp=fopen($xmlfile,'a');

$root_element = DB_DATABASE;

$dom = new DOMDocument('1.0', 'utf-8');
$rootNode = $dom->appendChild($dom->createElement($root_element));

$tablesquery = mysql_query('SHOW TABLE STATUS');
while ($fields = mysql_fetch_array($tablesquery)) {
$table_element = $fields['Name'];

        $tableNode = $rootNode->appendChild($dom->createElement($table_element));
        $dataquery=mysql_query("SELECT * FROM ". $table_element);
while($datarows = xtc_db_fetch_array($dataquery)){
                        foreach($datarows as $column=>$datavalue){
                        $columnNode = $tableNode->appendChild($dom->createElement($column))->appendChild($dom->createCDATASection($datavalue));
        }
}
}

$xmldoc= $dom->saveXML();

fwrite($fp,$xmldoc);

fclose($fp);
 

[Matt]

phpMyAdmin kaputt?

Du bekommst einen Parse Error vom php oder einen vom Excel, der versucht, das XML zu parsen? Im php ist auf den ersten Blick nichts drin.

[webald]

In Excel. Wenn ich mir die XML-Datei ansehe, die vom Script erzeugt wird, sehe ich nichts was den Fehler verursachen könnte.

Evtl. wäre es sinnvoller für jede Tabelle eine eigene XML-Datei zu erzeugen.

[Matt]

Dann hilft uns dein php-Code natürlich herzlich wenig.

Wie gesagt, phpMyAdmin kann XML exportieren. Würde ich den Vorzug geben, da es sich dabei um gut abgehangene Software handelt.

[webald]

Hi Matt,

das Problem liegt lt. Excel ja in der Datei, die von besagtem Code erzeugt wird. Wie Du ja selber schon gesagt hast, sieht der Code eigentlich richtig aus.

Falls das mal jemand anderes ausprobiert, hat er evtl. den gleichen Fehler oder eben nicht.

[Matt]

Du musst Excel schon ein fertiges XML geben. Das kann deinen php-Code nicht verarbeiten. Und vermutlich ist dann im fertigen XML ein Fehler, weil irgendwas nicht in CDATA steht, das aber in CDATA stehen müsste o.ä. Machst du den gleichen Export mit phpMyAdmin hast du das Problem vermutlich nicht.