Bestellungen :: Rechnungsadresse leer

Hallo Community, wir haben unsere Testphase mit der 3.5.4 jetzt durch und wollen offiziell online gehen. Bei den getätigten Testbestellungen lief alles problemlos durch. Jetzt wollte ich mal die Belege erstellen, um sie anpassen zu können. Jedoch taucht ganz oben bei der jeweiligen Bestellung im Backend (Kunden -> Bestellungen) folgender Satz auf: Achtung, zugeordneter Benutzer wurde gelöscht Die Felder Rechnungsadresse und Lieferadresse sind leer und natürlich erhalte ich auch bei der Belegerstellung eine riesige Fehlermeldung. Der Kunde und seine Adresse sind aber da. Unter der Kundenübersicht ist alles eingetragen. Habe schon im Forum gesucht, den Fehler mit Benutzer wurde gelöscht, habe ich auch gefunden. Jedoch keine Lösung dazu. Wir sind mit unserem Shopware Shop bei All-Inkl. Bis jetzt lief alles tadellos. Kann mir irgendwer bitte weiterhelfen? Danke im voraus

Kann geschlossen werden. In der Bestellabschluß - Mail muß ein Fehler gewesen sein. Habe mir die Vorlage aus dem Wiki geholt und reinkopiert, nochmal geändert und jetzt läufts. Thread kann geschlossen werden.

Dann mache ich den Thread mal wieder auf. Wir haben jetzt auch den ersten Fall mit “Achtung, zugeordneter Benutzer wurde gelöscht” Bestelldaten sind aber bei den Kundendaten gespeichert. Hier hat es die Bestellung nicht bis in die Kaufabwicklung geschafft. Die Bestellbestätigung ging auch nicht raus. Zahlart war Moneybookers Kreditkarte. Absoluter Einzelfall bei uns, aber das Problem scheint ja jetzt schon bei so einigen Shopbetreibern aufgetreten zu sein. “Shopware, bitte übernehmen Sie” :sunglasses:

Moin! Gleiches Phänomen bei uns. Das erste mal aufgefallen nach der Umstellung vom Heidelpay Modul auf das Heidelpay Plug-In. Rechnungsadresse und Lieferadresse bleibt leer, obwohl sich Daten unter dem “Bleistift” verstecken. Außerdem erhalten die Kunden nicht mehr den Checkout Successfull sondern fliegen nur noch raus… Diese Fehlermeldung wird ausgegeben: Syntax Error in template “string:” on line 46 “{/if}^M” unexpected closing tag in Vendor/Smarty/libs/sysplugins/smarty_internal_templatecompilerbase.php on line 404 Stack trace: #0 Vendor/Smarty/libs/sysplugins/smarty_internal_compilebase.php(98): Smarty_Internal_TemplateCompilerBase->trigger_template_error(‘unexpected clos…’, 46) #1 Vendor/Smarty/libs/sysplugins/smarty_internal_compile_if.php(108): Smarty_Internal_CompileBase->_close_tag(Array) #2 Vendor/Smarty/libs/sysplugins/smarty_internal_templatecompilerbase.php(252): Smarty_Internal_Compile_Ifclose->compile(Array, Object(Smarty_Internal_SmartyTemplateCompiler), NULL, NULL, NULL) #3 Vendor/Smarty/libs/sysplugins/smarty_internal_templatecompilerbase.php(114): Smarty_Internal_TemplateCompilerBase->callTagCompiler(‘ifclose’, Array) #4 Vendor/Smarty/libs/sysplugins/smarty_internal_templateparser.php(2278): Smarty_Internal_TemplateCompilerBase->compileTag(‘ifclose’, Array) #5 Vendor/Smarty/libs/sysplugins/smarty_internal_templateparser.php(2656): Smarty_Internal_Templateparser->yy_r55() #6 Vendor/Smarty/libs/sysplugins/smarty_internal_templateparser.php(2756): Smarty_Internal_Templateparser->yy_reduce(55) #7 Vendor/Smarty/libs/sysplugins/smarty_internal_smartytemplatecompiler.php(51): Smarty_Internal_Templateparser->doParse(11, ‘??’) #8 Vendor/Smarty/libs/sysplugins/smarty_internal_templatecompilerbase.php(83): Smarty_Internal_SmartyTemplateCompiler->doCompile(’

Hallo, Ursache für diese Meldung ist eine unvollständige Bestellung. Die tritt auf, wenn z.B. ein Fehler im eMail-Template (Bestellabschluss eMail) vorliegt. In der genannten Fehlermeldung deutet sich ebenfalls ein Fehler an. Dort ist zu lesen, dass ein if geschlossen wurde, hier aber falsch zu sein scheint. Syntax Error in template "string:" on line 46 "{/if}^M" unexpected closing tag --> Bitte einmal die sORDER Vorlage gegenprüfen

1 „Gefällt mir“

Bei einigen tausend Bestellungen ist bei uns ein Fehler in der Vorlage auszuschließen. Sowohl bei den Tests als auch im Livebetrieb hätte der “Fehler” viel, viel früher auffallen müssen, wenn da ein Fehler im sORDER Template wäre. Es ist bis jetzt auch wirklich der allererste Fall und daher nicht kriegsentscheidend, aber es muss noch eine andere Ursache geben.

Okay, bei euch kann das einfach ein temporäres Problem gewesen sein. Vielleicht sogar das bei Anbieter der Zahlungsart etwas hing. Meine Antwort bezog sich auch eher auf die allgemeinen Fragen oder Fehler hier. Zu 99% ist es die Vorlage sORDER und dann kann Shopware nicht alle Eintragungen vornehmen.

Das Problem bei den Schnittstellen zu/von den Zahlungsanbietern ist generell, dass es “Sekt-oder-Selters” Schnittstellen sind. Vielleicht etablieren sich ja irgendwann mal solche Dinge wie MQSeries oder RabbitMQ mit einer transaktionssicheren Messaging Queue dafür. Wäre vielleicht was für die Enterprise Edition… :wink:

[quote=“tschersich”]Das Problem bei den Schnittstellen zu/von den Zahlungsanbietern ist generell, dass es “Sekt-oder-Selters” Schnittstellen sind. Vielleicht etablieren sich ja irgendwann mal solche Dinge wie MQSeries oder RabbitMQ mit einer transaktionssicheren Messaging Queue dafür. Wäre vielleicht was für die Enterprise Edition… ;)[/quote] Wir hatten heute Nacht bei einer mit sofortüberweisung.de bezahlten Bestellung ebenfalls zum 1. Mal genau dieses Problem. Da es sich hier um unterschiedliche Zahlungsanbieter handelt und die ja kaum alle zum selben Zeitpunkt “Erreichbarkeitsprobleme” haben sollten, stellt sich m.E. die Frage, ob es ggf. ein kleiner Bug der 3.5.5 sein könnte … Was meint denn der Shopware Support dazu?

Hi, also ein Problem im Standard kann man auf jeden Fall ausschließen. Wenn so etwas Auftritt können da viele Faktoren eine Rolle spielen. Das Thema gab es hier auch schon des Öfteren. - dein Server (Shopware) - externer Server(Paymentanbieter) - Schnittstelle (paymentplugin) - Plugins (Plugins, die beim Ablauf der Bestellung eingreifen, ggf. temporär) - andere Anpassungen (Programmierungen/Template) - Problem am Kunden PC (Zeitüberschreitung o.ä.) - Abbruch der Bestellung + Statusänderung, z.B. durch Wawi - eMail Vorlage (Smartyfehler) und und und Eine weitere Prüfung würde ich in deinem System empfehlen, wenn das jetzt bei vielen Bestellungen auftritt. Das so eine Bestellung mal reinkommt, kann man nunmal auch nicht komplett verhindern oder abfangen. Wenn du keine Wawi hast und Probleme haben solltest, diese Bestellung zu bearbeiten, kannst du diese stornieren und eine neue für den Kunden durchführen. So ist due Bestellung dann vollständig und sauber im System.

Wenn ich eine neue Bestellung erstelle, erhält die Kundin aber auch ne neue Bestellbestätigung. Oder kann ich das abfangen?

In dem Du die nicht abschickst, sondern aus dem abgebrochenen Warenkorb erstellst! Also normal einkaufen über das Kundenkonto, alles in den Warenkorb und nicht abschicken.

[quote=“artep”]In dem Du die nicht abschickst, sondern aus dem abgebrochenen Warenkorb erstellst! Also normal einkaufen über das Kundenkonto, alles in den Warenkorb und nicht abschicken.[/quote] Danke für den Tipp. Hat (mit Einschränkungen - andere Bestellnummer …) funktioniert.

So, mein Problem ist gelöst (siehe oben). In der sOrder war nix zu finden. Vorgestern haben wir vom integrierten Heidelpay-Modul auf das Heidelpay Plug-In gewechselt und vorher nicht sämtliche Dateien des Moduls aus der Datenbank gelöscht. Also: 1. Einträge des integrierten Heidelpay-Moduls löschen. Das Vorgehen gab es von Heidelpay: ------ Deinstallation des alten Heidelpay Modules. Rufen Sie in Ihrer Datenbank die Tabelle “s_core_config_groups” auf. Suchen nach dem Eintrag Heidelpay und Löschen Sie diesen. Wechseln Sie nun in die Tabelle “s_core_paymentmeans” Löschen Sie alle Einträge die in der Spalte “template” mit"heidelpay_" beginnen. ------ 2. Plug-In installieren, Live-Daten eintragen, Einstellungen vornehmen 3. nicht vergessen die Versandkosten mit den Zahlungsarten zu verbinden. Hier läuft wieder alles! Danke.

Hallo, ich habe auch dieses Problem, das es sporadisch auftaucht, allerdings auch bei Vorkasse. So wie ich die Beiträge interpretiert habe, traten die Probleme hauptsächlich bei Zahlungsanbieter Schnittstellen auf. Gibt es dazu etwas Neues? Rainer Wolf

Hallo, ich habe ein ähnliches Problem. Der Bestellabschluß wird mit einem Fehler beendet, weil die Email-Vorlage sOrder falsch sei. Daraufhin gibt es keine Kundendaten mehr in der Bestellung. In den Kundendaten ist die Zuweisung der Bestellung aber korrekt. Ich habe bereits die Originalvorlage der sOrder reinkopiert. Beim anschließenden Überprüfen der Vorlage sind die " wieder da, obwohl dies eigentlich nicht der Fall sein sollte. Die magic_quotes sind korrekt gesetzt. Oder etwa doch nicht? Der Fehler tritt nur im Subshop auf, nicht im Hauptshop. Im Hauptshop wird die Vorlage korrekt mit " und nicht mit " abgespeichert. Die magic_quotes sind also korrekt eingestellt. Wo liegt hier der Fehler? Vielen Dank für eure Antworten. P.S.: Sollten weitere Informationen zur Konfiguration benötigt werden, beantworten ich diese gerne.

Hi, dann ist vielleicht nur die Vorlage für den Subshop defekt. Die wird ja in den Übersetzungflaggen hinterlegt.

Hallo Zusammen bei uns tritt dieses Phänomän auch auf. Auf der Bestellabschlußseite kommt folgende Fehlermeldung. Plugin „fill“ already registered in Vendor/Smarty/libs/sysplugins/smarty_internal_register.php on line 111 Stack trace: #0 Enlight/Template/TemplateManager.php(114): Smarty_Internal_Register->modifier(‚fill‘, Array) #1 engine/core/class/sOrder.php(853): Enlight_Template_TemplateManager->__call(‚register_modifi…‘, Array) #2 engine/core/class/sOrder.php(853): Enlight_Template_TemplateManager->register_modifier(‚fill‘, Array) #3 Shopware/Plugins/Community/Backend/SgateShopgatePlugin/Bootstrap.php(635): sOrder->sendMail(Object(Enlight_Hook_HookArgs)) #4 [internal function]: Shopware_Plugins_Backend_SgateShopgatePlugin_Bootstrap::sendOrderMailForShopgateOrders(Object(Enlight_Hook_HookArgs)) #5 Enlight/Hook/HookHandler.php(104): call_user_func(‚Shopware_Plugin…‘, Object(Enlight_Hook_HookArgs)) #6 Enlight/Hook/HookManager.php(95): Enlight_Hook_HookHandler->execute(Object(Enlight_Hook_HookArgs)) #7 Shopware/Proxies/sOrderProxy.php(22): Enlight_Hook_HookManager->executeHooks(Object(Enlight_Hook_HookArgs)) #8 engine/core/class/sOrder.php(790): Shopware_Proxies_sOrderProxy->sendMail(Array) #9 Shopware/Controllers/Frontend/Checkout.php(520): sOrder->sSaveOrder() #10 Shopware/Controllers/Frontend/Checkout.php(197): Shopware_Controllers_Frontend_Checkout->saveOrder() #11 [internal function]: Shopware_Controllers_Frontend_Checkout->finishAction() #12 Shopware/Proxies/ShopwareControllersFrontendCheckoutProxy.php(6): call_user_func_array(Array, Array) #13 Enlight/Hook/HookManager.php(100): Shopware_Proxies_ShopwareControllersFrontendCheckoutProxy->excuteParent(‚finishAction‘, Array) #14 Shopware/Proxies/ShopwareControllersFrontendCheckoutProxy.php(22): Enlight_Hook_HookManager->executeHooks(Object(Enlight_Hook_HookArgs)) #15 Enlight/Controller/Action.php(70): Shopware_Proxies_ShopwareControllersFrontendCheckoutProxy->finishAction() #16 Enlight/Controller/Dispatcher/DispatcherDefault.php(329): Enlight_Controller_Action->dispatch(‚finishAction‘) #17 Enlight/Controller/Front.php(99): Enlight_Controller_Dispatcher_DispatcherDefault->dispatch(Object(Enlight_Controller_Request_RequestHttp), Object(Enlight_Controller_Response_ResponseHttp)) #18 Shopware/Bootstrap.php(33): Enlight_Controller_Front->dispatch() #19 Enlight/Application.php(86): Shopware_Bootstrap->run() #20 shopware.php(6): Enlight_Application->run() #21 {main} hat jemand einen Tip. Der Fehler trat auf nachdem wir das Bereinigungs Script hatten laufen lassen Vielen Dank