Jump to content
xt:Commerce Community Forum

Jeldrik

Benutzer, die ihr Benutzerkonto
  • Content Count

    46
  • Joined

  • Last visited

About Jeldrik

  • Rank
    Benutzer

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Ich suche gerade verzweifelt das price-Template, dass beim Preis des Masters bei der Einstellung Autopreis greift. Alle Templates in xtCore/pages/price/ konnte ich ausschließen. Ich gehe davon aus, dass es an einem Fehler im System liegt und gar kein Price-Template für den Master-Preis genutzt wird. Shop-Version 4.0.16 Folgende Dateien sind bei mir in xtCore/pages/price/ vorhanden: graduated_table.html price.html price_special_graduated.html price_graduated.html price_special_discount.html price_special.html Ich habe in den Logs keine Fehlermeldung, dass eine Datei nicht geladen werden konnte. Jemand eine Idee bzw. selber schon mal auf das Problem gestoßen?
  2. Ich konnte ehrlich gesagt nicht glauben, dass es soetwas noch nicht gibt. Und wollte lieber nochmal nachfragen. Weil selber machen ist ja meistens teurer. ;-)
  3. Sorry, bei Punkt 1 muss es natürlich JavaScript heißen.
  4. Ich kann deine Motivation gut nachvollziehen und halte auch den Ansatz für praktikabel - soweit ich ihn verstanden habe. Es wäre hilfreicher gewesen, wenn du genauer aufgeschlüsselt hättest, was du tun willst. Ich schreibe mal runter, wie ich dein Vorgehen verstanden habe: 1. Du änderst per AJAX die Values für die Anzahl eines Artikel per +/- Button. 1.1 Was soll eigentlich passieren, wenn die Anzahl auf 0 gesetzt wird? Soll der Artikel dann aus der Liste gelöscht werden? Ein Verhalten für den Fall solltest du vorher definieren! 2. Du passt bei änderter Anzahl automatisch den Preis an. 2.1 Hierbei solltest du mögliche Staffelpreise beachten! Also entweder diesen Fall per Definition ausschließen oder du musst dir die richtigen Preise aus dem Shop per AJAX laden! Wenn du ihn per Definition ausschließt, sollte eine einfache mathematische Operation mit dem Einzelpreis reichen oder hab ich da einen Fall vergessen? 3. Du überträgst das geänderte Formular an den Shop, damit die aktualisierten Daten auch dort hinterlegt werden. 3.1 Eine unsaubere aber schnelle Lösung wäre das Formular einfach per AJAX zu senden und die komplette Seite sich zurückgeben zu lassen. Unsauber wegen der unnötige Generierung der Seite durch das Shop-System und die daraus resultierende Belastung der Datenbank und der Traffic bei der Übertragung. (So macht es aber zum Beispiel das Plugin vt_addproduct_nocart.) 3.2 Sauberer wäre es dafür eine eigene Schnittstelle zu implementieren, die die Funktionalität beim Absenden des Formulars auf das nötige Minimum reduziert. 4. Wichtig ist in jedem Fall zu überprüfen, ob die Änderungen korrekt vom Shop angenommen wurden. Ansonsten kann es zu einer Abweichung zwischen der Anzeige beim User und den Daten im Shop kommen! Diese sieht der User beim normalen Einkaufsverhalten dann erst auf der Bestellbestätigungsseite (/checkout/confirmation) oder er achtet da nicht mehr drauf und bestellt dann falsch. 4.1 Wenn du die unsaubere Lösung aus 3.1 nimmst, kannst du die zurückgegebene Seite auswerten und schauen, ob die Daten stimmen. 4.2 Bei der sauberen Lösung solltest du dir ein JSON zurückgeben lassen, in dem steht, ob die Prozedur erfolgreich war. Feedback zu diesen Gedanken wäre fein, weil ich mich dem Thema auch bald widmen werde. :-) Freundliche Grüße Jeldrik
  5. Guten Tag, ich suche eine Möglichkeit eine bestehende Bestellung im Backend (xtAdmin) zu kopieren. Diese soll als eigenständige neue Bestellung in der Datenbank hinterlegt werden. Es soll dabei eine neue Bestellnummer vergeben werden. Am besten wäre natürlich ein Eintrag in der History alten und der neuen Bestellung, dass sie kopiert wurde. Gemeinsam mit vt_oder_edit sollen in einigen Fällen bestehende Bestellungen nicht geändert, sondern storniert und die geänderte Bestellung als neue angelegt werden. Hintergrund ist die Verbesserung der Arbeitsabläufe im Büro. Ich habe bei der Suche kein entsprechendes Plugin gefunden. Gibt es dies einfach nicht? Oder war ich zu blind? Viele Grüße Jeldrik
  6. Leider ist diese Lösung nicht ganz zufriedenstellend. $comments steht in send_order nicht zur Verfügung. Nur in update_order-admin. Diese Variable enthält das Datenbankfeld xt_order_status_history.comments. Dieses Datenkbankfeld ist vom Typ text. Dieses wird auch im Admin-Bereich bei der Bestellung angezeigt. $order_data.comments steht in send_order zur Verfügung. Diese Variable liest aber ein anderes Datenkbankfeld ein und zwar xt_order.comments. Dieses ist jedoch vom typ VARCHAR und fasst daher nur 255 Zeichen. Bei einer Bestellung wird der Kommentar in beide Datenbankfelder gespeichert. Aus den unterschiedlichen Typen resultiet jedoch ein Problem, wenn die Bemerkung mehr als 255 Zeichen hat. Sie ist dann nur vollständig in xt_order_status_history.comments enthalten. Dies steht jedoch in send_order nicht zur Verfügung. In xt_order.comments und damit auch in $order_data.comments ist der Text dann abgeschnitten. In beiden Feldern werden leider keine Zeilenumbrüche gespeichert. Diese gehen verloren. Hat jemand schon eine Lösung für das Problem von Bermerkungen über 255 Zeichen und send_oder oder gar eine Lösung für die Zeilenumbrüche? Viele Grüße jeldrik
  7. Auch wenn ich leider mit mir selber rede, hier eine Lösung: Als Gebührentyp für die Zahlungsweise nicht Rabatt sondern prozentualen Aufschlag angeben. Der prozentuale Aufschlag lässt sich auch als negative Zahl eingeben. In diesem Fall wird es dann de facto wieder ein Rabatt. Die Anzeige ist jedoch dann in der Gesamtübersicht und nicht als Rabatt auf jeden einzelnen Artikel. Bei meinen Tests hat dies auch im Zusammenspiel mit PDF-Rechnung keine Probleme bereitet. Über Erfahrungswerte zu diesem Weg würde ich mich aber natürlich freuen.
  8. Das Kontaktformular überträgt auch bei unserer Installation trotz aktiviertem SSL die Daten unverschlüsselt. eTrusted ist das aber bei der Zertifizierung gar nicht aufgefallen. Shop-Version: 4.0.16 Dein Ansatz es zu beheben war schon gut. Wenn du im Template {form type=form name=login action='dynamic' link_params=getParams method=post} um conn=SSL ergänzt, also nachher {form type=form name=login action='dynamic' link_params=getParams method=post conn=SSL} hast, wird das Formular verschlüsselt übertragen. Wie die Kontaktseite aufgerufen wird, ist egal. Da werden ja noch keine persönlichen Daten übertragen. Nur beim Absenden des Formulars werden vertrauliche Daten übertragen und müssen daher verschlüsselt werden.
  9. Hallo, ich sitze nach wie vor an diesem Problem. Ich habe andere Plugins für andere Zahlungsweisen getestet (xt_cashondelivery, xt_payments) und bei diesen das gleiche Verhalten festgestellt. An dem Plugin scheint es also nicht zu liegen. Ein prozentualer Aufschlag wird korrekt als zusätzliche Kosten am Ende der Bestellung ausgegeben. Sieht niemand anders in diesem Verhalten in Problem? Oder finde ich bloß nicht die offensichtliche Lösung dafür? Viele Grüße Jeldrik
  10. Guten Tag, wir gewähren einen Rabatt bei Vorkasse (3%). Dass funktioniert an sich auch wunderbar. Leider wird der Rabatt aber auf jeden Artikelpreis berechnet. Wir würden den Gesamtrabat durch die Vorkasse gerne nur am Ende ausgeben. Also die Zwischensumme ohne diesen Rabatt, anschließend den Rabatt aufschlagen, wie auch fixe Kosten der Versandkosten aufgeschlagen werden. So soll es sein: Produkt A - Originalpreis 10€ Produkt B - Originalpreis 5€ Zwischensumme: 15,00€ Vorkassenrabatt: -0,45€ Versandkosten: 5,00€ Endsumme: 19,55€ So ist es: Produkt A - Originalpreis 10€ - Rabattpreis 9,70€ Produkt B - Originalpreis 5€ - Rabattpreis 4,85€ Zwischensumme: 14,55€ Versandkosten: 5,00€ Endsumme: 19,55€ Den Rabatt auf jedes Produkt auszugegeben, macht wenig Sinn, weil es ja der gleiche Rabatt auf alle Produkte ist und nicht vom Produkt sondern von der Zahlungsart abhängig ist. Das jetzt nur an der Anzeige zu ändern (bei Produkt nur Originalpreis, im Template die Rabattsumme ausrechnen und Anzeigen) geht leider auch nicht, weil dann produktabhängige Rabatte nicht mehr korrekt angezeigt werden. Wie habt ihr das gelöst? Oder zeigt ihr Rabatte auf Zahlungsweisen als Abschlag der einzelnen Produktpreise an? Shop-Version: 4.0.16 Plugin für die Zahlungsweise: xt_prepayment 1.0.0 Viele Grüße Jeldrik
  11. Guten Tag, ich möchte xt_cashondelivery (Nachname) auf eine deutsche Lieferadresse beschränken. Der normale Weg eine Zahlweise zu beschränken bezieht sich jedoch auf die Rechnungsadresse. In diesem Fall ist aber die Rechnungsadresse egal und die Lieferadresse entscheidend. Wie habt ihr das Problem gelöst? Viele Grüße jeldrik
  12. Von Haus aus gibt es auch die (nicht dokumentierte) Funktionalität bei einem Link Hersteller und Kategorie als Parameter zu übergeben und dann nur die Produkte des Herstellers in der Kategorie angezeigt zu bekommen. Der Link muss einfach nach folgendem Schema aufgebaut sein: /categorie?mnf={$HerstellerId}&cat={$KategorieId} Oder mit Suma URLs: /{Suma URL der Kategorie}?mnf={$HerstellerId}
  13. Du musst dazu dein Template anpassen. Konkret die Ausgabe des HTML in der product_listing und das CSS entsprechend schreiben. Wenn du dies dir nicht selber zu traust, musst du einen Fachmann / Fachfrau zu rate ziehen.
  14. An diesem Punkt denke ich, dass wir mit einer Fermdiagnose leider nicht mehr weiterkommen.
  15. Verstehe ich dich richtig, dass du alle Artikel gelöscht hattest und mit neu angelegten Artikeln der selbe Fehler aufgetreten ist? In diesem Fall würde ich darauf tippen, dass es nicht an den Artikeln liegen kann, außer du hast beim neuanlegen der Test-Artikel den selben Fehler reproduziert.
×
×
  • Create New...