wolkenkrieger

Here too ??

but in some cases, this may result in the behavior you reported.

If you know that, why do you release this bs? Or why do you don’t withdraw this?

“Aber alles, was im Status quo geladen wird, ist aus Sicht der Integration technisch notwendig.”

Ich mag mit dir nicht streiten aber das PP-Plugin von Shopware kommt ohne die Einbindung des Marketingteils der SDK aus und funktioniert, wie es soll.

Arbeiten die mit einem anderen PayPal Deutschland zusammen?

Was meinst du mit eingekapselt?

Wenn du das do_action() selber in einen try-catch-Block packst, gehst du sicher, dass dein Code sauber ausgeführt wird und du dich um Fehler kümmern kannst, die in deiner Verantwortung liegen.

Das ist sicher nicht die sonst gelebte Praxis in Woocommerce – weis ich ??

Das Problem jetzt ist aber, dass eine ganz ganz wichtige Funktionalit?t nicht mehr da ist. Es gibt sonst keine M?glichkeit, die Versandmail zu versenden, richtig?

Selbstredend ist das eigentliche Problem eine besch*ssene Fehlerbehandlung im Payment-Plugin. Klar.

da muss man wohl im PP Plugin nacharbeiten

Naja. Ja, eigentlich, schon. Aber aus meiner Sicht müsstet ihr dort auch Hand anlegen. Alles, was das Shipment ansich betrifft, kann man ja ruhig in einem try-catch drin haben.

Sonderbehandlungen oder Hooks sollten imho selbst eingekapselt sein.

Du siehst ja, was passiert: die eigentliche Funktionalit?t l?uft. Eine externe Quelle funkt aber jetzt derma?en dazwischen, dass ganz wichtige Core-Funktionalit?t (n?mlich der Status-Switch und die Trigger, die dadurch ausgel?st werden sollen/müssen) nicht mehr da ist.

Ich hab in der Shipment.php einfach mal das letzte do_action() auskommentiert und alles l?uft, wie es soll –> Staus wird ge?ndert und Mail wird versendet.

Da solltet ihr wirklich drüber nachdenken ??

[Nachtrag 4]

Quickfix:

add_filter( 'woocommerce_paypal_payments_sync_gzd_tracking', '__return_false' );

unterbindet den Versuch, den Shipment-Status an PayPal zu übermitteln, nachdem das Shgipment als solches gespeichert wurde.

Der Ball liegt also nun im Spielfeld der PayPalPayment-Macher ??

[Nachtrag 3]

Jupp, bei

do_action( "woocommerce_gzd_{$hook_postfix}shipment_after_save", $this, $is_new );

fliegt die Exception ??

Ich habe den Machern von PayPalPayments hier schon Bescheid gegeben.

Das ist gerade ein echtes Problem, weil meine Kunden keine Versandbenachrichtigung bekommen :/

[Nachtrag]

Nach ein bisschen “probieren” :: die Mail wird nicht versendet, wenn das Syncen der Trackingdaten zu PayPal fehl schl?gt (Woocommerce-Problem, wie es scheint) … zumindest funktionieren im Staging alle Bestellungen, die entweder Vorkasse sind oder bei denen aus anderen Gründen keine Tracking-ID zu PayPal gesyncet werden soll.

Die Woocommerce-eigene “Bestellung abgeschlossen” – Mail ist von dem Problem nicht betroffen – die wird immer versendet.

[Nachtrag 2]

Im Log steht dann sowas:

2022-11-24T17:10:10+00:00 ERROR Error saving shipment #61

kommt, wie mir scheint, aus src/Shipment.php :: 2760

• This reply was modified 2 years, 3 months ago by wolkenkrieger.

The Plugin loads the PayPal SDK from paypal.com/sdk … and the pptm.js from paypal.com/tagmanager

and the tagmanager-script is not nexxessery for the payment functionality … it is part of the PayPal Marketing Solutions which send data back to PayPal, which are NOT technical related!

[German]

Das Plugin l?dt aus der SDK auch den Tagmanager nach (paypal.com/tagmanager/pptm.js?id= …). Der ist aber nicht technisch notwendig, unterliegt also der Erlaubnispflicht nach DSGVO (Cookie Consent) … schon allein deswegen, weil der nach Hause funkt und Daten übertr?gt. Das pptm-Script geh?rt zu den PayPal Marketing Solutions … also nicht zur eigentlichen Zahlungsfuntionalit?t.

NO, i don’t mean the whoole text. I mean the greetings only. After that, the mail has additional text … and another greeting.

[German]

ich meine tats?chlich nur die abschlie?ende Gru?formel unter dem Ratepay-Text.

Nach dem “Mit freundlichen Grü?en …” geht die mail ja noch weiter – dann kommt ja noch die Order-table und sonstige Texte … und ganz am Ende dann nochmal eine Gru?formel

Hallo @aweissinpsyde

Das Hochsetzen der Nachkommastellen rei?t an einer anderen Stelle jetzt ein Loch ??

In der Gateweay-Klasse für das PUI wird im Hook ‘woocommerce_email_before_order_table’ der Text erstellt, den der Kunde als Zahlungsinfo in s?mtlichen Mails zu sehen bekommt und dort wird der Preis nicht via wc_price(), sondern via ‘{$order->get_currency()}{$order->get_total()}’ ausgegeben.

Sprich: in den Kundenmails steht der Kaufpreis dann mit 4 Nachkommastellen drin.

Es w?re also wirklich wichtig, dass hier eine L?sung gefunden wird, die keiner “Tricks” bedarf und rechtssicher einzusetzen ist ??

Mir ist sowieso schleierhaft, warum man einen before_order_table (!!) Text mit einer Gru?formel beendet ?? Mal ganz abgesehen davon, dass das Zahldatum falsch formatiert ist (d-m-Y) und man in Deutschland nicht EUR 12,34 schreibt, sondern 12,34 € (oder EUR).

Guckt sich das Ergebnis keiner an, bevor man sowas in release gehen l?sst??

Und ganz fein ist auch, dass der hook mit einer anonymen Funktion realisiert wurde :/

• This reply was modified 2 years, 3 months ago by wolkenkrieger.
• This reply was modified 2 years, 3 months ago by wolkenkrieger.

?hm … kann es sein, dass die ?nderungen im letzten Release (3.10.6) gar nicht drin sind?

Bei mir werden nach wie vor die Bestellmails versendet, wenn der Kunde mit Ratepay bezahlt?!

[Nachtrag]

Wenn ich, wie von dir empfohlen, die Nachkommastellen auf 4 einstelle, werden die Preise im Shop mit 4 Nachkommastellen angezeigt.

Entweder, es gibt eine M?glichkeit, das zu unterbinden oder das Hochsetzen der Nachkommastellen ist keine Option!

[Nachtrag 2]

Das Hochsetzen der Nachkommastellen auf 4 würde das Problem als solches aber l?sen Hab’s gerade erfolgreich getestet. Bleibt also die Frage, wo ich das so einstellen kann, dass im Frontend in Deutschland übliche und gesetzl. vorgeschriebene Preise mit 2 Nachkommastellen angezeigt werden ??

• This reply was modified 2 years, 4 months ago by wolkenkrieger.
• This reply was modified 2 years, 4 months ago by wolkenkrieger.

Ich gebe meine Preise brutto ein und das muss aus organisatorischen Gründen auch so bleiben.

Das Hochsetzen auf 4 Nachkommastellen kann ich testen.

Dass du dich in Punkto Nachkommastellen widersprichst, ist dir bewusst, oder? In deiner ersten Antwort schreibst du, dass der Fehler vorkommen kann, wenn man mehr als 2 Nachkommastellen nutzt und nun schl?gst du mir als m?gliche Probleml?sung genau das vor?

[Nachtrag]

Aus dem Log:

Request Body: {“intent”:”CAPTURE”,”processing_instruction”:”ORDER_COMPLETE_ON_PAYMENT_APPROVAL”,”purchase_units”:[{“reference_id”:”default”,”amount”:{“currency_code”:”EUR”,”value”:”9.87″,”breakdown”:{“item_total”:{“currency_code”:”EUR”,”value”:”13.90″},”shipping”:{“currency_code”:”EUR”,”value”:”0.00″},”tax_total”:{“currency_code”:”EUR”,”value”:”0.65″},”discount”:{“currency_code”:”EUR”,”value”:”4.67″}}} […]

Amount sollte in dem Fall eigentlich 9.88 sein … das scheint mir ein Rundungsfehler zu sein?!

Hallo Andreas,

der Rechnungskauf als solcher funktioniert einwandfrei. Ich kann sogar denselben Warenkorb abschicken, nachdem ich den Gutschein entfernt habe.

Falls du im Reiter “Allgemein” den Punkt “Anzahl der Dezimalstellen” meinst, dann sind es 2 … ich wüsste sonst nicht, wo ich das noch einstellen k?nnte (Woocommerce-Neuling).

Es kommen als preismanipulierende Plugins das Woocommerce-eigene Marketing-Plugin und Rightpress Woocommerce Dynamic Pricing & Discounts (https://support.rightpress.net/hc/en-us/categories/200133263-WooCommerce-Dynamic-Pricing-Discounts) zum Einsatz.

Letzteres kann ich auch deaktivieren, ohne an der Fehlersituation etwas zu ?ndern.

Weil mein Englisch nicht das sattelfesteste ist^^: der Fehler tritt NUR beim “Rechnungskauf mit Ratepay” auf. Alle anderen PayPal – Zahlungen sind mit dem Gutschein problemlos durchgelaufen laut Log. Wobei Kartenzahlung bei mir zwar im Konto freigeschaltet, im Shop aber nicht aktiviert ist … dazu kann ich also keine Aussage treffen.

Danke und Gru?