Zahlungsart-Einkaufswert Unterschied zwischen Shop und Admin?

Moinsen,
keine Ahnung, wie ich sonst dazu etwas suchen soll, aber ich wurde jedenfalls nicht fündig. Das Szenario ist eine eingehende Bestellung, die mit “gesicherten Rechnungskauf” über Heidelpay bezahlt wird, damit hat es aber nur indirekt zu tun. Entscheidend dabei ist, dass es einen Mindest-Einkaufswert dieser ZA von 25 € gibt und die Bestellung hatte einen Gesamtwert von 26,50 € (22,- + 4,50 Versand). Somit wurde im Shop auch korrekterweise Rechnung als ZA angeboten und der Kunde konnte bestellen. Das dürfte auch der “Normalfall” sein und alles weitere ist für viele Shopbetreiber uninteressant.

Nun kommt aber doch das Heidelpay-Modul (D3) ins Spiel, wodurch es die Möglichkeit gibt, Bestellungen im Backend zu finalisieren. Dies klappt jedoch nicht bei solchen Rechnungs-Bestellungen, die kleiner als 29,50 € (25,- + 4,50) sind, weil angeblich keine Zahlungsart hinterlegt sei. Und tatsächlich fehlt diese auch im Stamm-Reiter der jeweiligen Bestellung, sodass automatisch “oxempty” gewählt wird. Nun ist der Verdacht, dass das Heidelpay-Modul dieselbe OXID-Logik nutzt und daher in diesen Fällen zu einem Backend-Fehler führt. Deswegen stehe ich jedoch bereits mit D3 in Kontakt, und es ließe sich sicherlich auch irgendwie lösen.

Die Frage ist aber nun: warum wird zur Prüfung der gültigen ZAs einer Bestellung im Shop mit, und im Admin ohne Versand gerechnet? Konkret meine ich die Zeile 82 der order_main.php (OXID 4.10.8) oder Zeile 69 in OrderMain.php (OXID 6.1.2):
$dPrice = $oOrder->oxorder__oxtotalbrutsum->value / $oOrder->oxorder__oxcurrate->value;
Wenn man die durch diese ersetzt:
$dPrice = $oOrder->oxorder__oxtotalordersum->value / $oOrder->oxorder__oxcurrate->value;
dann würden die ZA-Prüfungen identische Ergebnisse liefern, aber gibt es evtl. einen trifftigen Grund, warum dies gerade nicht der Fall ist? Also kurzum: Bug oder Feature? :wink:
Danke + beste Grüße

Da ich es mir nicht anders erklären kann, neige ich zu Bug und habe diesen nun per kleinem Modulpatch behoben wie oben beschrieben. Somit kann der Kunde nichts mehr falsch machen, wie z.B. kurz vor besagtem Heidelpay-Finalize noch schnell einen Tracking-Code eintragen und speichern (das war letztlich der Auslöser)… :roll_eyes:
Also nochmal betont zur Klarheit: es hat nichts direkt mit Heidelpay zu tun, wurde dadurch nur zufällig sichtbar. Jetzt fehlt nur noch ein Bugeintrag und Pullrequest, schätze ich, aber mag nicht wer anders das übernehmen? Ich habe schon viel zu viel Zeit mit dem Problem verdaddelt, einfach weil ich neugierig war, und dies ist ja nun geklärt, oder gibt es noch andere Ideen dazu?