Jump to content
xt:Commerce Community Forum

forensis

Members
  • Content Count

    29
  • Joined

  • Last visited

About forensis

  • Rank
    Neuer Benutzer

Recent Profile Visitors

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

  1. Hallo zusammen, xtC sendet ja meines Wissens immer sowohl eine html als auch eine TXT-Mail heraus. Nun möchte ich auch die richtige Funktion der TXT-Mails testen. Aber wenn ich in meinem Outlook-Mailclient das Sicherheitscenter anweise, eingehende Nachrichten im NUR-TEXT-Format darzustellen, dann erkenne ich, dass es lediglich aus der eingehenden HTML-Mail die entsprechenden Tags entfernt hat. Das sieht bloß furchtbar aus, aber damit habe ich die echte TXT-Mail aus xtC immer noch nicht getestet. Gibt es irgendwo einen Schalter, der xtC zwingt, nur TXT-Mails zu versenden? Oder kann man wenigstens bei einem Testkunden irgendwo NUR-TXT einstellen? (Im Registrierungsformular findet sich ja kein Schalter). Es gibt ja Shopsysteme, da kann der Kunde wählen, ob er HTML- oder Text-Mails erhält. Wie lässt sich das Test-Problem lösen? Einfach "blind" darauf verlassen, dass es schon richtig wird, ist jedenfalls nicht die geeignete Lösung. Gruß, forensis
  2. Wie bei Kripo-Ermittlungen: Zuerst hat man einen Verdächtigen. Irgendwann später - wenn er Glück hat - findet man den wahren Schuldigen. Ich bin sicher, dass viele Outlookbenutzer, die bei eingehenden Mails Regeln anwenden, diese BCC-Problematik gar nicht kennen. Wer weiß denn schon, dass die BCC-Information vom letzten Mailserver verworfen und in ein TO umgewandelt wird? Eigentlich können NUR Tester von Shop- (u.ä.) Software dieses Problem überhaupt erkennen. Aber auch die rätseln zuerst ... Bei meinen Internetrecherchen habe ich viel Zeugs zu "BCC-Problemen" aller Art gefunden, aber 98% davon war für diesen Fall unbrauchbar. LG, forensis
  3. Ja, das Zahlungsmodul tut schon, was es kann. Es ist der Gesetzgeber, der hier den Medienbruch erzwingt: Alles läuft seit Jahren online, indem der Kunde einen Haken bei Lastschrift setzt und seine Bankdaten einträgt. Und JETZT plötzlich soll er nach der Onlinebestellung zuerst das Formular unterschreiben und per Post zurücksenden. Ich bin sicher: Viele Onlinekunden haben einfach "keinen Bock" darauf und wählen andere Zahlungsformen. Der Shopbetreiber muss ja auch - wenn er es ganz genau nimmt - abwarten, bis der Schrieb bei ihm eingetroffen ist, bevor er abbucht. Das führt zu weiterer Wartezeit beim Kunden bis die Ware eintrifft. Das mit der handschriftlichen Unterschrift (bei Onlinegeschäften) war nichts anderes als ein "genialer" Schildbürgerstreich von oben! Ich frage mich, wozu eigentlich schon vor Jahren die digitalen Personalausweise eingeführt wurden, wenn sie bis heute nicht mit der Fähigkeit ausgestattet wurden, mit ihnen elektronisch signieren zu können. DAS wäre doch eine pragmatische Lösung: Ich mache ein paar Mausklicks am PC und stecke den Ausweis anschließend in meinen Chipkartenleser und betätige dann "Zahlungspflichtig bestellen". Fertig. Aber auf sowas Einfaches kommen komplizierte Hirne wohl nicht. Offenbar sind eine Menge der neuen digitalen Erfindungen der letzten Jahre nichts anderes gewesen als heiße Luft, die zu sonst nichts taugt, außer einige Wenige schnell reich zu machen ... Gruß, forensis
  4. Endlich habe ich die Lösung am Schlafittchen! Es lag weder am xtC-Shop, noch an den Providern auf der Mailstrecke, sondern schlicht und einfach daran, dass ich in MS-Outlook etliche "Regeln" benutze, um - der Übersicht halber - eingehende E-Mails auf verschiedene Ordner zu verteilen. Dahinter zu kommen ist aber nicht ganz ohne. Zum einen muss man wissen, dass der letzte Mail-Provider die BCC-Adresse löscht und in eine ganz normale TO-Adresse umwandelt. Das war mir bisher nicht klar, macht aber Sinn, da ja die anderen BCC-Empfänger nichts voneinander wissen sollen (Datenschutz). Und zum anderen funktionieren die MS-Outlookregeln so, dass sie nach dem TO und CC-Empfänger schauen (BCC gibt's da ja auch gar nicht mehr!). Ergo wird der ursprüngliche BCC-Empfänger, der jetzt zu TO geworden ist, exakt so behandelt, als hätte er schon immer in der TO-Zeile gestanden. Wenn man dann die Shopfunktionen zwar mit verschiedenen Mailadressen testet, die aber allesamt von ein und demselben Outlook empfangen und verteilt werden, dann muss es einfach so kommen, dass der "Testkunde" 2 E-Mails und der "Shop-Admin" (BCC) keine erhält! Meine Problemlösung: Ich lasse Outlook weiter mit seinen bewährten Regeln arbeiten, habe aber die beiden Shop-Mailkonten auf ein extra dafür installiertes Thunderbird gelegt. Da gibt es keine Regeln, nur 2 verschiedene Konten, die den Shop-Mailserver direkt abfragen. Jetzt weiß ich: Alles was in Thunderbird landet, ist "Shop-Sache" ... und es funktioniert reibungslos. Erstaunlich fand ich, dass T-Online 5 Tage nichts von sich hören ließ. Auch die Hotline dort scheint mit diesem Problem überfordert zu sein. Und in den Microsoftforen musste ich schon heftig wühlen, bis ich den Hinweis auf das Löschen der Outlook-Regeln fand. Gruß forensis
  5. Zwischenzeitlich habe ich mich bei einigen wenigen größeren Shopbetreibern umgehört. Die meisten halten die postalische Zusendung des SEPA-Mandats für dem Kunden nicht zuzumuten. Es gibt offenbar die Tendenz "Augen zu und durch!". Das heißt: Verzicht auf ein handunterschriebenes Mandat. Ergo: Sie gehen bewusst das Risiko ein, dass eine SEPA-Lastschrift (ohne handunterschriebenes Mandat) ggf. auch noch viele Monate nach der Abbuchung zurückgefordert wird. Als Kleinst-Shopbetreiber kann ich mir das aber nicht leisten und werde daher auf die SEPA-Lastschriftzahlung genau so verzichten, wie auf BillSafe. Gruß forensis
  6. ...stutzig geworden, habe ich gerade meinen eigenen Mail-Provider (T-Online) geprüft und musste feststellen, dass es an IHM liegt, dass ich KEINE BCC-adressierten Mails erhalte! (Alles was an X-ENVELOPE-TO addressiert ist, bleibt auf der Strecke - egal, woher es kommt!) Mist! BCC hat früher immer geklappt! Ob's was mit der Umstellung auf SSL-Mails zu tun hat, zu denen T-Online seine Kunden schon seit längerem auffordert? Jetzt muss ich auf den Rückruf der T-Online-Servicestelle warten. Solange halte ich mich hier mal zurück. Vermutlich muss ich sogar froh sein, dass ich mich mit xtc seit Tagen abmühe ... andernfalls hätte ich wohl lange nicht bemerkt, dass BCC-Mails (von wem auch immer) an mich gar nicht mehr ankommen! Gruß forensis
  7. Hallo Alex, heute habe ich den ganzen Tag herumprobiert von morgens bis jetzt:wenn die Kundenmailadresse identisch ist mit der Adminweiterleitung, dann geht nur 1 Mail heraus. Sobald die Kundenmailadresse eine andere ist, erhält der Kunde 2 Mails (mit unterschiedlichen Mailheadern!) und der Admin keine. Ich hab's mit SMTP, sendmail und mail/qmail probiert: Immer dasselbe! Und für den Shopadmin habe ich ein eigenes Postfach eingerichtet, das zu nichts anderem dient. Mein Hoster ist Domainbox.de, aber ich betreibe dort einen VServer und habe daher via Plesk Panel selbst jede Konfigurationsmöglichkeit. Auf dem VServer laufen z.Z. 14 Webseiten und ein Mehrfaches an Postfächern mit den jeweiligen Domainnamen. Allesamt funktionieren reibungslos mit Outlook - auch die neue Shopadresse. Nur der Shop selbst verhält sich fehlerhaft. Bei der Installation von 4.1.0 waren sämtliche Voraussetzungen okay (=grün). Letzter Konfigurationsstand unter Einstellungen / Emaileinstellungen: Pfad zu sendmail: /usr/sbin/sendmail Emailsystem: mail E-Mail-Debug: 1 (true) (Alle anderen Einstellungen ändern auch nichts am falschen Verhalten). Shop-Einstellungen / Email: Empfänger - Kontaktformular: (Hier ist die Adminadresse eingetragen). Sämtliche SMTP-Felder sind jetzt leer (nachdem ich auch hier alle möglichen Kombinationen probiert hatte). Und natürlich sind die Felder unter Inhalte / E-Mail-Manager für die einzelnen Mails auch richtig ausgefüllt: Type: send_order Template special: 0 Absender E-Mail und Name (entspricht der Shop-Adminadresse) Reply Email und Name (ist eine weitere/andere Shop-Adminadresse) Weiterleitung: erfolgt auf meine Privatadresse. Meinst Du andere Konfig-Einstellungen? Welche wären das? ************ Hier die Internetkopfzeilen von 2 an den Kunden (und keine an den Admin) gesandten E-Mails. Dabei kann ich nicht sagen, welche für den Admin "gedacht" ist und welche für den "Kunden". (Beim Oxid-Shop ghibt's z. B. 2 verschiedene Mails; davon geht eine zuverlässig an den Kunden und eine an den Admin - mit einem anderen Text. Ich habe den Verdacht, dass das System von xtc 4.1.0 die Adminmailadresse falsch verarbeitet: Internetkopfzeile der einen Mail (an die Kundenadresse): Return-Path: <shop@trxxxxxx.de> X-Original-To: ego@abxxxxxx.me Delivered-To: ego@abxxxxxx.me Received: by vhostXXXXX.server-home.net (Postfix, from userid 10000) id 12FDE1A5B60; Sat, 22 Feb 2014 22:47:25 +0100 (CET) To: Hutzlifutzli Gertrud <KUNDE@xxxxxxxxx.de> Subject: Ihre Bestellung Nr. 3469 vom 22.02.2014 X-PHP-Originating-Script: 10000:class.phpmailer.php Date: Sat, 22 Feb 2014 21:47:25 +0000 From: Mein Shop <shop@trxxxxxx.de> Reply-To: Mein Shop <media@trxxxxxx.de> Message-ID: <2bc66815ecd925b88663a8bc3b10793d@shop.trxxxxxx.de> X-Priority: 3 X-Mailer: PHPMailer (phpmailer.sourceforge.net) [version 2.0.0 rc3] MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1_2bc66815ecd925b88663a8bc3b10793d" X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== [/HTML] [i][color="DarkGreen"]Hier ist die obere "[b]To[/b]"-Zeile dafür verantwortlich, dass diese Mail zur Kundin geht.[/color][/i] Und hier die der [b][u]anderen[/u][/b], die auch an den Kunden ging, sich aber inhaltlich unterscheidet: [HTML] Return-Path: <shop@trxxxxxx.de> Received: from mailin53.aul.t-online.de ([172.20.27.2]) by ehead510.aul.t-online.de (Dovecot) with LMTP id 4VZYDDQbCVPKNgAAugtVLw; Sat, 22 Feb 2014 22:50:39 +0100 Received: from vhostXXXXX.server-home.net ([77.236.97.170]) by mailin53.aul.t-online.de with esmtp id 1WHKSx-1DRArg0; Sat, 22 Feb 2014 22:50:35 +0100 Received: by vhostXXXXX.server-home.net (Postfix, from userid 10000) id 12FDE1A5B60; Sat, 22 Feb 2014 22:47:25 +0100 (CET) To: Hutzlifutzli Gertrud <KUNDE@xxxxxxx.de> Subject: Ihre Bestellung Nr. 3469 vom 22.02.2014 X-PHP-Originating-Script: 10000:class.phpmailer.php Date: Sat, 22 Feb 2014 21:47:25 +0000 From: Mein Shop <shop@trxxxxxx.de> Reply-To: Mein Shop <media@trxxxxxx.de> Message-ID: <2bc66815ecd925b88663a8bc3b10793d@shop.trxxxxxx.de> X-Priority: 3 X-Mailer: PHPMailer (phpmailer.sourceforge.net) [version 2.0.0 rc3] MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1_2bc66815ecd925b88663a8bc3b10793d" X-TOI-SPAM: n;1;2014-02-22T21:50:39Z X-TOI-VIRUSSCAN: clean X-TOI-EXPURGATEID: 149288::1393105835-00001458-1F1E9C0E/0-0/0-0 X-TOI-SPAMCLASS: CLEAN, NORMAL X-TOI-MSGID: 4ab0a847-56b8-4438-a8cc-6d854659d32e X-Seen: false X-ENVELOPE-TO: <KUNDE@xxxxxxx.de> [/HTML] [i][color="DarkRed"]Die letzte Codezeile (X-ENVELOPE-TO) scheint dafür verantwortlich zu sein, dass [b]AUCH [/b]diese Mail an die "Kundin" geht. [b]Müsste hier nicht die Adminadresse stehen?[/b][/color][/i] Es wäre interessant zu erfahren, welche von beiden eigentlich die für den Admin gedachte ist. Beste Grüße von einem genervten, zeitverschwendenden Shoptester, der sich auch darüber ärgert, dass das Online-Handbuch noch nicht auf den 4.1.0-Stand aktualisiert wurde. Das ist zusätzlich unnötig irreführend ... forensis
  8. 2 Jahre später ... Version 4.1.0: Immer noch (oder wieder) dasselbe Problem: Egal, ob mit sendmail oder mit SMTP versendet wird: Der Kunde bekommt 2 Mails, der Admin KEINE. Und es spielt auch keine Rolle, ob der HTML-Code der Mail falsch ist. WENN er falsch ist, dann bleibt der Checkout-Prozess im Ganzen hängen. Nur, wenn xtCommerce den Code als richtig erkennt, lässt es den Checkout durchlaufen und versendet die Mails... ...leider 2 mal an den Kunden... Gruß forensis
  9. "Nicht alle Daten eingegeben..." das schreibt sich so einfach. Damit lässt sich der schwarze Peter immer einem anderen zuschieben. Aber im PlugIn stehen auch teilweise ANDERE Bezeichnungen als die, die man von BillSafe erhält. Und: Es müssen gar nicht alle Felder ausgefüllt werden! M.a.W.: Die Anleitung(en) zur BillSafe-Integration sind nicht aktuell! Ich habe mich jetzt ein paar Tage mit der BillSafe-Implementation in 4.1.0 herumgeschlagen, nachdem ich dieser Methode sowieso eher skeptisch gegenüber stand. Aber dank der Unterstützung des BillSafe-Supports funktioniert jetzt immerhin die BESTELL-Abwicklung. (Komischerweise passt aber die Anleitung zur Integration nicht zu den Gegebenheiten in 4.1.0). Aber es ist ja ebenso wichtig, dass die Rechnung allen BillSafe-Anforderungen genügt. Da müssen die BillSafe/PayPal-Bank- und Zahlungsdaten und einige Sachen zusätzlich angegeben werden. xtCommerce selbst kann eine solche BillSafe-konforme Rechnung NICHT ausgeben. Der sog. "Zahlschein", den das BillSafe-Plugin generieren kann, enthält all diese Daten zwar, entspricht aber nicht den Anforderungen an eine ordnungsgemäße Rechnung, kann also nicht an ihre Stelle treten. Da ich aber die Rechnungen sowieso über eine Fakturierungssoftware (orgaMAX) erzeuge, müssten die von BillSafe zurückgegebenen Bank-/Zahlungsdaten korrekt in diese Faktura übertragen werden. Das aber funktioniert nicht. BillSafe hat - verständlicherweise - keinen Bock mehr, mich weiter zu unterstützen (sie könnten an mir sowieso nicht viel verdienen). Ich habe keinen Bock mehr, noch länger Zeit in diese Zahlungsart zu stecken. Schon gar nicht bin ich bereit, Geld an Dritte zu bezahlen, damit sie das für mich machen. Bei xtCommerce selbst habe ich bisher auch keine eindeutige Dokumentation zur Programmierung der Übergabeschnittstellen gefunden. Mit anderen Worten: BillSAFE ist für mich gestorben! Ich werde regulären Einzelkunden keinen Rechnungskauf im Shop anbieten. Erst wenn ein Kunde mehrere (mehr als 3) Bestellungen vorgenommen hat, schalte ich ihn für den Rechnungskauf (ganz normale Rechnung, bei der ich das Risiko trage und der Zahlungsempfänger bin) frei - aber nur bis zum ersten Zahlungsausfall. Dann ist's vorbei mit "Zahlung per Rechnung". Ich selbst finde, dass der Rechnungskauf zwar im B2B angebracht ist, aber bei B2C hat er sich überholt! Hier gehört sich m. E.: Ich erhalte das Geld zur selben Zeit wie der Kunde die Ware (wie im Ladengeschäft)! Am liebsten nutze ich selbst PayPal. An zweiter Stelle steht das Lastschriftverfahren und an dritter die Vorkasse. Ich bin niemandem böse, wenn er mich nicht per Rechnung beliefert ... außer er beschei*** mich und liefert die Ware nicht oder nicht richtig. BillSAFE adé forensis
  10. Ab 1.2.2014 sind Abbuchungen/Lastschriften nur noch im SEPA-Verfahren möglich. Wie ich heute erfahre, muss dazu dem SEPA-Lastschrifteinreicher zwingend ein Mandat des Lastschrifterteilers vorliegen, das von diesem handschriftlich unterschrieben ist, also in Papierform an den Shopbetreiber gesandt werden muss. Außerdem muss dann 14 Tage vor der Abbuchung/Lastschrift dem Lastschrifterteiler eine "Pre-Notification" über die jeweilige Lastschrift zugehen. Das alles ruft in mir den Gedanken hervor: Wir bieten die Zahlungsmöglichkeit "Lastschrift/Abbuchung" ab dem 1.2.2014 gar nicht mehr an, denn diese wäre für alle Beteiligten dermaßen aufwendig, dass sie sich nur noch für Zahlungen ab dem dreistelligen Euro-Bereich rentieren würde. Meine Frage: Gibt es schon eine Lösung (oder ist eine solche in Arbeit), die diese SEPA-"Verrücktheiten" auf shoptechnischer Basis für alle Beteiligten simpel und schnell handhabbar macht? Gruß, forensis
  11. Leider nein! Ich habe nichts herausgefunden und nichts in Erfahrung bringen können. Ich vermute mal, dass xtCommerce es selbst nicht weiß, weil die Komponente von einem (inzwischen verstorbenen ???) Fremdprogrammierer aus Ostindien stammt... Ich hab resigniert - zumal der Kunde, für den ich den Shop aufgesetzt habe, offenbar weniger Probleme mit "invoice" hat, als ich ... LG forensis
  12. Zwischenzeitlich hat sich dieses Problem bei mir gelöst. Ich kann nicht mit völliger Sicherheit sagen, was denn nun der letztendliche Auslöser dafür war, dass ich jetzt auch die Admin-Mails bekomme, vermute aber stark, dass es daran lag, dass ich sämtliche Email-Vorlagen (unter Inhalte) auf problematische Einträge hin durchforstet habe. Und ich denke, dass mein ursprünglicher Hauptfehler entstand, als ich den Emails eine andere Formatierung (Schriftart Arial und nicht mehr diese supergroßen und fetten Überschriften) gab. Zuerst war mir nicht klar, dass ich damit das interne "smarty-System" wuschig mache. In irgendeinem Beitrag und schließlich auch im smarty-Handbuch fand ich dann den Hinweis, dass sobald geschweifte Klammern im Spiel sind - wie z. B. bei den CSS-Anweisungen, die ich hinzugefügt hatte - smarty diese als Steueranweisungen interpretiert und dann nur noch "blöd aus der Wäsche guckt", weil es nichts damit anfangen kann. Schließlich habe ich allen diesen CSS-Codes die smarty-Anweisungen {literal} ... Nicht-smarty-Code ... {/literal} verpasst. Ab diesem Zeitpunkt - glaube ich - funktionierten alle E-Mails richtig. LG forensis
  13. Das xt_orders_invoices PlugIn (PDF-Rechnung) ist ja sehr anpassungsfähig. Das gefällt mir. Allerdings suche ich nun schon seit Tagen nach der Programmstelle des PlugIns, die dafür verantwortlich ist, dass der Dateiname der PDF-Rechnung immer mit dem englischen "invoice" beginnt. Ich möchte dort statt "invoice####" steht: "Rechnung####" (#### ist die Rechnungsnummer). Weiß jemand wo da einzugreifen ist? In der SQL-Datenbank offenbar nicht. LG forensis
  14. Im Admin-Menü "Hersteller" gibt es unter anderem ein Feld namens "REIHENFOLGE". Der damit korrespondierende Wert in der Datenbank heißt "manufacturers_sort". Den Gesetzen der Logik folgend gehe ich davon aus, dass diese Reihenfolge-Ziffer die Reihenfolge des Erscheinens in der Hersteller-Box steuern soll, denn nicht jeder will in seinem Shop eine alphabetische Reihenfolge haben. Allerdings muss ich betrübt zur Kenntnis nehmen, dass ich unter Reihenfolge beliebige Ziffern schreiben kann - das System ordnet die Hersteller trotzdem immer alphabetisch nach Namen! Ganz anders bei den Artikeln: Da funktioniert die "Reihenfolgeziffer". Hat bereits jemand eine Lösung gefunden? LG forensis V4.0.14
×
×
  • Create New...