Jump to content

Jörg Saxtec

Members
  • Content count

    34
  • Joined

  • Last visited

About Jörg Saxtec

  • Rank
    PrestaShop Apprentice
  • Birthday 05/16/1972

Profile Information

  • Gender
    Male
  • Location
    germany & españa
  • Activity
    Web development agency

Contact Methods

  • Website URL
    http://www.saxtec.com/produkte/prestashop/
  • Skype
    braeutigamjoerg
  • iMessage
    office@joergbraeutigam.com

Recent Profile Visitors

3,028,747 profile views
  1. Brutto und Netto Anzeige PrestaShop 1.7

    Das ist seltsam. habe gestern abend dazu einen frischen 1.7.2.4 installiert und das Problem auch ohne das PS_LEGAL Modul nachstellen können. Bei uns tritt es bei allen 1.7 Installationen auf.
  2. Brutto und Netto Anzeige PrestaShop 1.7

    Ich denke, man muss das von zwei Seiten sehen. Natürlich ist die "override" Geschichte sehr angenehm und im Gegensatz zu manch anderem Shopsystem auf dem Markt schon ein Grund, auf PrestaShop zu setzen. Die andere Seite ist jedoch: Wenn ich ein Modul erzeuge, und für die korrekte Funktion Overrides benötige, kann ich für den Händler automatisiert die Files in den Override Ordner kopieren. Wurde und wird von einigen Modulherstellern auch intensiv genutzt. Wenn ich nun aber ein zweites Modul installiere, welche die gleiche Klasse überschreiben möchte, dann knallt es an der Stelle. Der Händler sieht im Backend nach der Modulinstallation nur, das etwas nicht funktioniert. Das ist dann ärgerlich. Ich kann mir gut vorstellen, dass aus diesem Grund die Entscheidung aus dem Hohen Haus so getroffen wurde.
  3. Brutto und Netto Anzeige PrestaShop 1.7

    Auch wenn ich Dich und Deine Fachkenntnis sehr schätze: Overrides funktionieren recht gut mit Klassen in PrestaShop 1.7. Habe in einem Shop die Bestellnummern so überschrieben, da der Kunde die Buchstabenkombination nicht wünschte <?php class Order extends OrderCore { public static function generateReference() { $last_id = Db::getInstance()->getValue(' SELECT MAX(id_order) FROM '._DB_PREFIX_.'orders'); $order_id = str_pad((int)$last_id + 1, 6, '000000', STR_PAD_LEFT); return "LT-".$order_id; } }
  4. Brutto und Netto Anzeige PrestaShop 1.7

    Habe auch schon etwas "gewühlt". Es werden die Variablen "unit_price" und "unit_price_full" dafür verwendet. Die finde ich in der PaymentModule.php ab Zeile 501. Die Änderung funktioniert zumindest in der Bestätigungsmail (order_conf), im Frontend (noch) nicht. In Zeile 490 wird $product_price definiert und die Mehrwertsteuer entsprechend eingerechnet. Weiter unten wird jedoch (fälschlicherweise?) mit der Netto Variablen $product['price'] anstatt $product_price gerechnet. Ich habe das geändert und es funktioniert - bis zum nächsten Update. Möglicherweise könnte man daraus ein Override machen. if (isset($product['price']) && $product['price']) { // $product_var_tpl['unit_price'] = Tools::displayPrice($product['price'], $this->context->currency, false); $product_var_tpl['unit_price'] = Tools::displayPrice($product_price, $this->context->currency, false); // $product_var_tpl['unit_price_full'] = Tools::displayPrice($product['price'], $this->context->currency, false) // .' '.$product['unity']; $product_var_tpl['unit_price_full'] = Tools::displayPrice($product_price, $this->context->currency, false) .' '.$product['unity']; } else { $product_var_tpl['unit_price'] = $product_var_tpl['unit_price_full'] = ''; }
  5. Brutto und Netto Anzeige PrestaShop 1.7

    Das Array für die Mail (order_conf) beinhaltet folgende Daten (Ein Produkt in der Tabelle) Array ( [id_product] => 3 [reference] => 12345678 [name] => TEST Produkt [price] => 758,00 CHF [quantity] => 2 [customization] => Array ( ) [unit_price] => 351,90 CHF [unit_price_full] => 351,90 CHF ) Im Beispiel habe ich 2 Produkte für je 379,00 CHF, gesamt 758,00 CHF. Das ist auch korrekt in Brutto ausgezeichnet. Ein Einzelpreis in Brutto fehlt. Was habe ich übersehen?
  6. Hallo, Unter PrestaShop 1.7.2 ist mir aufgefallen, dass im Checkout sowie in der Bestätigungsmail zum Kunde Brutto und netto Anzeigen durcheinander gewürfelt sind. So wird noch vor dem Checkout alles korrekt in Brutto Preisen angezeigt, In der Bestellbestätigung werden in der Produkttabelle nur Netto Preise angezeigt und in der Bestätigungsmail wird in der Produkttabelle der Einzelpreis netto angezeigt, und der Gesamtpreis (Einzelpreis * Anzahl) wieder Brutto, also mit Mehrwertsteuer. Kann man das vereinheitlichen, dass IMMER Brutto Preise angezeigt werden? Die entsprechenden Smarty Variablen habe ich schon mit "print_r" validiert, die korrekten Preise sind jedoch nicht erhältlich. Hat von jemand von euch auch das Problem? Wie habt Ihr das gelöst? LG Jörg
  7. PayPal mit PrestaShop 1.7

    Problem hat sich erledig
  8. Habe gerade einmal einen Blick auf die 1.7.2.1 geworfen. Da sind so einige Bugs behoben worden. So funktionieren nun unter anderem die Übersetzungen korrekt (soweit ich das testen konnte), die Lagerverwaltung ist nun auch okay. Mit etwas Handarbeit bekommt man auch einen mehr oder weniger rechtssicheren Bestellprozess zustande. (Ein Anwalt sagte einmal, in Deutschland ist es grundsätzlich NICHT möglich, einen 100% rechtssicheren Shop zu betreiben) Ich sehe mit der aktuellen Version 1.7 einen schnellen, stabilen und benutzbaren Shop.
  9. Bei einem Update kommt es sicherlich auch darauf an, was am Shop-(Core) geändert wurde. Sofern "nur" im Template Ordner und unter "Overrides" - so wie es sein sollte - Änderungen durchgeführt werden, sollte ein Update seit der 1.6 problemlos mit dem mitgelieferten Modul zu machen sein. Bislang hatte ich da (bis auf Zusatzmodule) noch keine großen Schwierigkeiten. Auch empfiehlt es sich, das Update auf einer 1:1 Kopie und NICHT im Live Shop durchzuführen. Um zum Thema 1.7 zurückzukommen: Das Update lief auf von einer 1.7.1.2 ohne Schwierigkeiten durch und der Shop funktionierte danach auch. Großartige Verbesserungen kann ich jedoch nicht feststellen. LG Jörg ------------------------------- Saxtec IT - eCommerce und SEO http://www.saxtec.com Skype: saxtec.leipzig
  10. Wir nutzen für unsere Kundenshops auch die 1.6.15 bzw. auch bei einem die frische 1.6.1.16 - bislang ohne Probleme gegenüber älteren Versionen. Die 1.7 haben wir in einem ersten Projekt getestet. Der Shop geht vor September nicht Live, so haben wir noch etwas Zeit, um Fehler zu finden. PretsaShop 1.7 hat natürlich auch Vorteile, ohne Frage. Den größten Benefit sehe ich im Frontend. Ja, da wurde viel Gutes getan. Aus meiner Sicht ist es das Aussehen und die Funktion im Frontend durchaus wichtig, da der Kunde sich im Shop wohlfühlen darf (meine persönliche Meinung). Auch ist das Frontend im Vergleich zur 1.6.x schneller geworden, was nicht nur Google, sondern auch die Kunden freuen wird. Auch ist das Standard Template "Classic" jetzt auf einem mobilen Gerät wesentlich angenehmer zu bedienen. Doch wo Licht ist, ist bekanntlich auch Schatten: Die bislang schmerzlichsten Fehler aus meiner Sicht (inklusive 1.7.2.0) sind im Backend und in der Datenhaltung zu suchen. Es können keine Währungsanzeigen mehr eingestellt werden! Unter 1.6 war es noch möglich, einen Preis mit "CHF 10,00" sowie "10,00 €" darzustellen.Was die Entwickler dazu entschieden hat, dies zu ändern, weiß ich nicht. Nun kann ein Shop nicht mehr "vernünftig" mehrere Währungen darstellen. Das heißt, Entweder "10,00 €" UND "10,00 CHF" oder "€ 10,00" und "CHF 10,00" - Das ist schlicht Blödsinn. Der schöne Favoriten Ordner bei den Modulen ist leider dem Rotstift zum Opfer gefallen. Nun muss man sich immer durch die ganzen Module kämpfen oder man legt für jedes Kundenprojekt einen eigenen Browser-Lesezeichen-Baum für die Module im Backend an, um gleich zum gesuchten Modul zu gelangen. Das kann es aber nicht sein. Hinter einigen Menüpunkten verstecken sich zwei oder mehr Konfigurartionspunkte, welche vergeblich im Menü gesucht werden! So ist z.B. der "Wartungsmodus" unter "Shop Einstellungen" -> "Allgemein" versteckt. Wenn man das nicht weiß, sucht man ewig! Übersetzungen werden nicht angenommen. So steht zwar unter anderem ein Geänderter Eintrag für "SHOPEINSTELLUNGEN" im Backend UND in der Datenbank, doch das interessiert die Ausgabe im Frontend (Dargestellt über der Anschrift im Footer) herzlich wenig. Weitere Übersetzungen werden auch nicht dargestellt. Grundsätzlich glaube ich jedoch, dass PrestaShop auf einem guten Weg ist und würde neue Projekte, sofern sinnvoll, mit der 1.7 an den Start bringen. Denn die Vorteile überwiegen und die Nachteile werden sicherlich in Zukunft auch ausgebessert sein. Dann hat man aber mit der 1.7 ein modernes, schnelles und umfangreiches Shopsystem, welches sich bei den Mitbewerbern nicht verstecken muss. LG Jörg ---------------------------------------- Saxtec IT - eCommerce und SEO http://www.saxtec.com Skype: saxtec.leipzig
  11. Das heißt, Du würdest unbedingt bei 1.6 bleiben? Für mich war die Entscheidung vor allem wegen des schönen Frontends und des gelungenen Checkouts auf die Version 1.7 gefallen. VG Jörg
  12. Vielen Dank. Allerdings habe ich noch nicht das gewünschte Ergebnis. Ist es richtig, dass man die Preisauszeichnung nur einmal (global) je Sprache festlegen kann? So habe ich in meiner Testumgebung (Deutsch und Spanisch) eine Datei translations -> cldr -> main--de-DE--numbers sowie translations -> cldr -> main--es-ES--numbers. Wenn ich nun in der spanischen Vorlagedatei den Wert ändere, habe ich für ALLE Währungen das Währungszeichen vor dem Preis. So wird dann die Währung anhand der gewählten Sprache und nicht auf Basis der gewählten Währung formatiert. (es wird dann auch '€ 100‘ anstatt '100 €' angezeigt, bei der Auswahl Sprache Deutsch wird zwar '100,00 €' dargestellt, aber die Fremdwährung falsch). Kann man das mit einem PrestaShop 1.7 lösen? Andernfalls wäre diese Version für internationale Shops nicht mehr geeignet. LG Jörg
  13. Hallo, in PS 1.6 konnte man festlegen, wie ein Preis im Frontend dargestellt wird. Zur besseren Verständlichkeit: Ich meine die Preisauszeichnungen wie: 100,00 € - CHF 100,00 oder $ 100,00 . Wie und wo kann ich das in PrestaShop 1.7.1 umsetzen? Leider werden alle Währungssymbole NACH dem Preis angezeigt. Zur Verdeutlichung habe ich einige Screenshots beigelegt. Und nein, ich möchte nicht PS 1.6 einsetzen, da ich überzeugt bin, dass in PS 1.7.X trotz bekannter Anfangsschwierigkeiten sehr viel Potential steckt, und das Frontend auch in der Classic Version um Längen Kundenfreundlicher ist. Liebe Grüße, Jörg
  14. Kontaktformular Bearbeiten

    Ich schaue mir einmal an, wie das Standard Formular erzeugt wird. Die Herausforderung wird eher sein, die Daten zu validieren und entsprechend zu übertragen. Das Smarty TPL ist sicherlich schnell geändert. Schick wäre es meiner Meinung, die Felder für das Standard Formular im Backend festzulegen. Oder? LG Jörg
  15. Kontaktformular Bearbeiten

    Der Post ist zugegebenermassen etwas älter. Ich brauche diese Felder auch. Hat schon jemand eine Lösung dafür (PrestaShop 1.6 und auch 1.7) Falls nein, würde ich mich an die Arbeit machen. LG Jörg
×