Stimmt! Und somit zeigt unsere SepaGedöhns jetzt die Sepa-Daten der letzten Sepa-Bestellung an! Nennen wir "Kundenfreundlich" <Angeberei OFF>
In der Tabelle "sepa" werde die entsprechenden SEPA-Daten gespeichert. Wenn ich die zugehörigen SEPA-Bestellungen lösche, weshalb sind denn in Tabelle "sepa" noch alle Daten (der gelöschten Best.) vorhanden?
In Falle von Falscheingaben gibt "banktransfer" diese Daten an "checkout_payment.php" zurück: [payment_error], [error], [banktransfer_owner], [banktransfer_number], [banktransfer_blz], [banktransfer_bankname], ..... [recheckok], [XTCsid], [tpl] "sepa" nur diese: [payment_error],[error], .....[recheckok], [XTCsid], [tpl] Hat diese Sparsamkeit einen tieferen Sinn? Es gibt ja Systeme, die daraus eine kundenfreundliche Fehlermeldung erzeugen!
Hallo Manfred, die Daten, die du in das Formular eingibst werden in der checkout_confirmation in die SESSION geschrieben. Sollte dann ein Fehler auftreten, wird der checkout_payment nur noch die Fehlermeldung übergeben. Die eingegebenen Daten des Kunden werden dann wieder aus der SESSION geholt. Die Umstellung erfolgte, damit auch die eigegebenen Daten bei einem Klick auf "Abbrechen" weiterhin zur Verfügung stehen. Somit sind die GET Parameter überflüssig und wurden entfernt... Das Sepa Modul ist natürlich für alle Sepa-Länder nutzbar. Wie bereits erläutert ist die Überprüfung für DE noch intensiver (passt die angegebene Konto-Nr zur BLZ etc.). Die Fehlermeldungen wurden ebenfalls überarbeitet und sind nun in Sepa noch differenzierter. Hast du dort irgendwelche Probleme? Das Problem beim Löschen einer Bestellung ist uns auch aufgefallen. Wir wollten aber dafür nicht extra wieder eine Korrektur-Version veröffentlichen. Beim nächsten Service-Pack bzw. Master-Update wird die Tabelle automatisch bereinigt. Solltest du bereits den Wunsch haben, dass die Daten gelöscht werden, kannst du folgende Zeile in die /admin/includes/functions/general.php in die Funktion "xtc_remove_order" einfügen: Suche: PHP: xtc_db_query("DELETE FROM " . TABLE_ORDERS_PRODUCTS . " WHERE orders_id = '" . (int)$order_id . "'"); Füge danach ein: PHP: xtc_db_query("DELETE FROM sepa WHERE orders_id = '" . (int)$order_id . "'"); MfG, Timo
Hallo Timo, Jetzt nicht mehr, seit ich in meinem SepaOverlay diese Zeile Code: $payment_error_return = 'payment_error=' . $this->code . '&error=' . urlencode($error) . '&recheckok=' . $recheckok; ... durch diese ersetzt habe: Code: $payment_error_return = 'payment_error=' . $this->code . '&error=' . urlencode($error) . '&sepa_owner=' . urlencode($_POST['sepa_owner']) . '&sepa_iban=' . urlencode($_POST['sepa_iban']) . '&sepa_bic=' . urlencode($_POST['sepa_bic']) . '&sepa_bankname=' . urlencode($_POST['sepa_bankname']) . '&recheckok=' . $recheckok; Was dazu führt, das auch bei SEPA-Falscheingaben eine vernünftige Fehler ausgabe erfogt - wie bei "banktransfer" - siehe Bild. Danke für den "Lösch-Fix"! PS: Könnt Ihr ja mit dem GM-Acount im Liveshop testen.
Ihr wisst schon, daß für Zahlungen innerhalb von Deutschland kein BIC mehr notwendig ist? Quelle: http://www.die-deutsche-kreditwirts...Lastschriftmandat-SDD_Basis-Core_09072012.pdf Wenn das nicht notwendig ist, sollte man die Kunden dazu auch nicht zwingen. Viele werden ihre IBAN kennen, aber nicht den BIC.
Nun, die Dokumentationen zur SEPA-Lastschrift sind auf der Seite der Bundesbank für jeden seit langer Zeit einsehbar. Man müsste sie nur lesen und entsprechend umsetzen. Wie schon vorher geschrieben: Gambio macht es sich hier wirklich zu einfach. Ausbaden müssen das dann die Shopbetreiber. http://www.bundesbank.de/Redaktion/DE/Standardartikel/Aufgaben/Unbarer_Zahlungsverkehr/die_sepa_lastschrift.html?nsc=true
Seit Mitte 2012!!! ist das SEPA-Regelwerk allen bekannt -richtig? Und wir schustern hier vorn und hinten an einem ZAHLUNGSMODUL herum, das nur so von Fehlern strotzt! Ich denke - wir werden jetzt die Reißleine ziehen und nach einer anderen (funktionierenden) Lösung suchen - egal ob die nun was kostet!
Das wurde aber nicht nur hier verschleppt. Die hätten die SEPA-Einführung sicher nicht um 6 Monate verschoben, wenn nicht etliche große Firmen das verschwitzt hätten.
Weil es langsam unübersichtlich wird was alles fehlt, hier mal eine kleine Todo-Liste für Gambio im SEPA-Modul: - Unterscheidung Firmenkunde / Privatkunde einbauen (am besten direkt bei der Anmeldung) - Unterscheidung ob Kunde Einzelmandat oder Mehrfachmandat ausstellen will - Mandatsrefrenz festlegen (z.B. Mandatsreferenz = Kundennummer bei Mehrfachmandat ODER Auftragsnummer bei Einzelmandat) - Bei Mehrfachmandat feststellen ob Erstlastschrift oder Folgelastschrift - Vorankündigungsfrist im SEPA-Modul konfigurierbar machen, für verkürzte Fristen (möglich über den Mandatstext oder AGB) - Mandatstext mit entsprechender Frist auf der Ermächtigungsseite einbauen, dabei Unterscheidung im Text für Firmen- und Privatkunden (kein Widerrufsrecht für Firmenkunden) - BIC wird nur noch für Einzug von Auslandsbanken benötigt - Vorankündigungstexte in die Bestellbestätigung einbauen mit Abbuchungsdatum, Mandatsreferenz und Gläubigernummer, damit die Fristen so früh wie möglich anfangen zu laufen (!) Nachtrag: Das Mandatsdatum sollte auch noch irgendwo gespeichert werden, wird wichtig bei Folgelastschriften!
Hallo Manfred, deine Anmerkung zu den Fehlertexten ist kein Fehler des Moduls. Du hast nunmal eine individuelle Anpassung im Shop und durch eine Strukturänderung hat deine Anpassung nicht mehr funktioniert. Ein Lösungsansatz wäre gewesen, wenn du statt GET einfach auf SESSION umstellst. Das hätte die gleiche Wirkung, sodass deine Anpassung wieder funktioniert. Die anderen genannten Punkte werden wir hier nochmal besprechen... MfG, Timo
Original 2.0.13 "banktransfer.php" gibt diese Error zurück: Code: $payment_error_return = 'payment_error=' . $this->code . '&error=' . urlencode($error) . '&banktransfer_owner=' . urlencode($_POST['banktransfer_owner']) . '&banktransfer_number=' . urlencode($_POST['banktransfer_number']) . '&banktransfer_blz=' . urlencode($_POST['banktransfer_blz']) . '&banktransfer_bankname=' . urlencode($_POST['banktransfer_bankname']) . '&recheckok=' . $recheckok; Original "sepa.php" gibt das zurück: Code: $payment_error_return = 'payment_error=' . $this->code . '&error=' . urlencode($error) . '&recheckok=' . $recheckok; Original 2.0.13 "checkout_payment.php" wertet die so aus: Code: if (isset ($_GET['payment_error']) && is_object(${ $_GET['payment_error'] }) && ($error = ${$_GET['payment_error']}->get_error())) { So - wo soll ich deiner Meinung nach mit der Umstellung anfangen, damit Fehlermeldungen von beiden Zahlarten vernünftigt ausgegeben werden?