Beiträge von Marcus

Beim Versuch, einen offenen Warenkorb durchzubuchen, kommt man in die Bestellmaske und bekommt den Hinweis:
"Porto konnte nicht ermittelt werden"
Wieso eigentlich ? Sind doch alle Informationen vorhanden, um das durchzukalkulieren.
Fehlt da der Aufruf der Portoroutine ?

Datenbank ist UTF-8
Und es stand auch wirklich in der Beschreibung "Rießig" drin.
Nachdem wir das richtig auf "Riesig" korrigiert hatten und dann wieder "Rießig" in die Suche eingegeben haben, wurde der Artikel angezeigt.....
Probiert es mal selber aus

Ein Aushilfserfasser hat einige Artikel mit "rießig" anstatt mit "riesig" erfasst.
Wollten das dann korrigieren und haben im Shop nach "rießig" gesucht. Als Ergebnis haben wir nur die Artikel angezeigt bekommen, die richtig im Shop mit "riesig" drinstanden wie "riesiger Korb" etc.
Die falschen Artikel mit "rießig" in der beschreibung wurden nicht angezeigt.
Ist das ein Kniefall der Suche vor der Rechtschreibreform ? :p

Tja, und noch eine Konstellation:
Nutze Magnalister, und für eine Bestellung aus England wurde in das Feld Bundesland vom Magnalister "Bedfordshire" eingetragen.
Später wurde dann über Paypal eine abweichende Versandadresse nach Irland übermittelt, OHNE Bundesland.
Auch hier keine Möglichkeit, im Shop das zu löschen oder zu überschreiben, da in der Bestellung bei Änderung der Adresse das Feld Bundesland nicht vorhanden ist. Und so steht im Lieferschein "Bedfordshire , Irland" ......

Das Thema ist ja auch nur augeschoben, aber nicht aufgehoben
Ich teste für unseren Admin jetzt erstmal die 3.4. BETA, ob die Steuerthemen erledigt sind.
Das ist am drängensten.

Wie geschrieben:
Ich bin im Shop im Adminbereich, gehe mit der Maus auf den Menüpunkt Hilfsprogramme, das Menü klappt auf und ich klicke auf "CSV Import/Export"
Unten links steht im Browser "Auf http://www.deinedomain.de/admin/csv_backend.php" wird gewartet, weiter passiert nix.
Nach ca. 30-60Sekunden kommt dann die Fehlermeldung "Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 262143981 bytes) in /vrmd/homepages/u16000/admin/csv_backend.php on line 90"

Und während hier einerseits die Forumfraktion sagt: "Setz das Memory Limit hoch", hat mir andererseits mein Provider plausibel erklärt, wieso 256 MB (Standardkonfiguration aller bei denen betriebenen Managed Server und der Dedicated Server) völlig ausreichend ist.

Und ich schließe mich dem Provider an, denn wieso werden mehr als 256 MB benötigt bei einer Datenbank mit 23 MB ?

"Früher" wurden ja auf dem Sinclair auch gute Programme geschrieben mit 1 KB Arbeitsspeicher.

Bei Erstellung einer Rechnung wird, sofern ein Kommentar vorhanden ist, dieser mit ausgegeben am Ende.
Bei einem Lieferschein wurde das vergessen, hier muß man leider ohne den Kommentar auskommen.
Bitte noch ergänzen.

Hallo Mario,
unter STANDARDINSTALLATION verstehe ich natürlich das schicke grau-schwarz-weiße 0/8/15-Template, das dabei ist.
Aber Dein Tip mit dem Javascriptfehler war es, da hat es dann Klick gemacht.

Habe dann mal den Firefox gestartet. Und es funktioniert.
Der Fehler tritt nur bei IE8 auf.
Sollte mal gefixt werden, damit das aufgeklappte Kommentarfeld auch beim IE8 funktioniert.

Ich mache weder Export noch Import.
Ich habe im Shop nur unter Module->Export Module das Programm aufzurufen.
Außer dem Fehlerhinweis nach ca. 20-30 Sekunden passiert eben NIX !
Ich bekomme noch nicht mal die Startmaske für Export/Import zu sehen.

Es gibt leider nur einen Umrechnungskurs je Währung, den man einstellen kann.
Dies führt im Laufe der Zeit unweigerlich zu Fehlern, wenn man diesen Umrechnungskurs mal an den tatsächlichen Kurs anpaßt.
Beispiel: Euro:Dollar = 1:1,25
3 Monate später 1:1,40
Wenn man dann auf den aktuellen Kurs anpaßt, weißt die Statistik natürlich einen gewaltigen Umsatzeinbruch auf, den man aber gar nicht hat.

Es wäre also sinnvoll, eine Tabelle mit Währungskursen und Datumsrange zu haben, damit bei einer Anpassung die Vergangenheitswerte nicht "zerstört" werden.
Also in der Form Datumvon, Datumbis, Währung, Umrechnungskurs.
Jede Anpassung, die man dann vornimmt, ist somit dokumentiert.
Noch besser:
Man hat eine Tabelle mit Monatskursen für jede Währung analog dem vom Finanzamt veröffentlichten Umrechnungskurse für die Umsatzsteuer.
http://www.bundesfinanzministerium.de/Content/DE/Dow…kurse-2013.html

Somit ist die Statistik auch nach Jahren noch richtig. Wird aber dann wohl etwas Performance kosten bei einer Auswertung über große Zeiträume und viele verschiedene Währungen. Aber einen Tod muß man immer sterben.

Schade, warte hier immer noch auf Antwort.
Wobei ich mir ernsthaft die Frage stellen muß, wieso bei einer Datenbank mit insgesamt 23 MB Datenvolumen (mit allen Tabellen wie orders, products etc.) 256 MB Memory nicht ausreichend sein soll und dieser Error erscheint.
Das sollte man vielleicht die Routine überarbeiten und nicht so ressourcenfressend stehen lassen.

Da muß ich Dir widersprechen. Ich poste nicht aus Jux und Dollerei, ich habe dies mit 3 Shops getestet, 2 im laufenden Betrieb und einen neu aufgesetzten in einer Testumgebung mit Standardkonfiguration, ohne da irgendetwas zu verändern.
Wenn Du schon schreibst "dann bitte mit nützlichen Informationen" dann faß Dir mal an die eigene Nase.
Ich kann nirgendwo in Deinem Posting eine nützliche Information von Dir lesen nach dem Motto: "Hab' ich getestet, bei mir paßt es". Mit so einer Antwort kann ich was anfangen und müßte dann den Fehler weiter bei mir suchen.
Dauert nur 2 Minuten: Häkchen im Admin rein, als Admin (oder als Kunde) Ware in den Warenkorb und ab an die Kasse.

Würde das Frage/Antwortspiel enorm vereinfachen.

Standard halt wie in der Grundkonfiguration festgelegt.
Probiers doch einfach mal selbst mit einer Standardinstallation aus.

Der normale Bestellprozeß im Shop für die Kunden.

Egal ob in diversen Shops oder in einem neu aufgesetzten Testshop.
Unter SEO-Config->Bestellprozeßß ist die Option "Kommentarfeld aufgeklappt" auf true, im Bestellprozeß bleibt das Kommentarfeld zugeklappt.

15.000 Produkte, die Hälfte davon aktiv.

OK, da steht 256M.
Sollte ich also bei meinem Provider anpassen lassen. Wobei 256M ja ein Standardwert der meisten Dedicated und Managed Server ist.

Was wäre denn ein guter Wert ?
512 M oder gleich 1024M ?

Bei Aufruf des Hilfsprogramms (csv_backend.php) dauert es erst ewig, dann kommt der Fehler
Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 262406126 bytes) in /vrmd/homepages/u16000/admin/csv_backend.php on line 90

Versteh ich nicht. Der Shop läuft ganz allein auf einem Dedicated Server mit 4 CPU-Kernen und 8 GB RAM.
Oder muß ich da noch irgendeine Einstellung vornehmen ?

Das hat man davon, wenn man eine bestehende Installation von 2.1. auf die aktuelle 2.3.5. updated und dort haarsträubende Fehler auftauchen.
In 2.1. konnte man das Land noch manuell eingeben bzw. ändern in der Bestellung. In 2.3.5. gibt es ein "praktisches" Pulldown-Menü. Naja, für Recalculate der richtigen Steuerberechnung braucht man sowas, WENN die Steuerberechnung funktionieren würde......

Problem:
Bei Anlegen einer Bestellung wird das Land als Klartext in die Tabelle orders für alle 3 Felder (Costumer, Delivery, Billing) gefüllt. Bei Aufruf der Bestellung ist dann das Pulldownmenü beim richtigen Land positioniert.
Wenn man dieses nun ändern und auf Adreßänderung speichern klickt, springt das Pulldownmenü auf den Anfangswert Afghanistan und speichert in der Tabelle die 3 Länderfelder leer ab.
Es gibt danach auch keine Möglichkeit mehr, die Länder auf irgendetwas einzustellen.

Also einmal geändert -> Ende Gelände

Es gibt somit KEINE Möglichkeit im Admin-Backend, ein Land zu ändern.

Nacht sinnlos um die Ohren gehauen für nix und wieder auf die 2.1 zurückgegangen

Kunde Huber bestellt, trägt als Empfänger den Herrn Schmidt ein.
Bei Erstellung Lieferschein ist es schon komisch, wenn der Empfänger Schmidt mit "Sehr geehrter Herr Huber" angesprochen wird.
Auch der weitere text wie "wir freuen uns, dass Sie bei XXXX bestellt haben." ist etwas komisch.
Hier sollte sowas stehen wie: Diese Lieferung erhalten Sie im Auftrag von...."

Ich vermisse zudem die Möglichkeit, einen Lieferschein ebenfalls in einer Order abspeichern zu können so wie die Rechnung.

Massenerstellung von Lieferscheinen auf der Bestellübersichtsseite ist auch nicht möglich.