Fehlerbehebungen
Credit – Fehler bei gemischten MwSt-Sätzen
Es wurde ein Fehler bei der Erstellung von Credits behoben, der Belege mit gemischten MwSt-Zeilen betraf. Der im Transaktionslog angezeigte Betrag wich vom tatsächlich an collana pay übermittelten Betrag ab. Betroffen waren ausschließlich Credits mit Zeilen, die unterschiedliche MwSt-Sätze enthielten (z. B. gleichzeitig 19 % und 0 % MwSt).
Verbesserungen & Erweiterungen
Simulation – No Cart und Recurring Payments
Die Simulationsfunktion wurde um Unterstützung für Recurring Payments und No Cart-Transaktionen erweitert. Beide Transaktionstypen können jetzt in der Simulationsumgebung getestet werden.
Publisher – SplitAddress-Fehler
| Hinweis für Partner: Dieses Event ermöglicht es, eigene Adressauflösungslogik zu implementieren und Fehler bei nicht parsebaren Adressen gezielt abzufangen, ohne den Standard-Fehlerfluss zu durchlaufen. |
In der Codeunit PAYWebServCommunication steht ein neues Publisher-Event zur Verfügung, das ausgelöst wird, wenn die Funktion SplitAddress eine Adresse nicht parsen kann.
- Das Event OnBeforeSplitAddressError wird in den Methoden AddBillingCustomerData und AddShippingCustomerData ausgelöst.
- Über den Parameter IsBillingAddress wird mitgeteilt, in welchem Kontext der Fehler aufgetreten ist (true = Rechnungsadresse).
- Subscriber können Street, HouseNo und IsHandled := true setzen, um eigene Adressdaten bereitzustellen und die Fehlermeldung zu unterdrücken.
Verarbeitung von „Unsupported"-Antworten
Das Handling von collana pay-Antworten mit dem Status Unsupported wurde geändert. Bisher wurden diese Antworten wie erfolgreiche Benachrichtigungen behandelt, was bei einigen Zahlungsanbietern zu Problemen geführt hat, die Reservierungen automatisch verlängert haben.
Unsupported-Antworten – überwiegend Void-Interaktionen – werden nun als fehlgeschlagene Interaktionen behandelt und müssen manuell geprüft werden. Im collana pay Rollencenter steht dafür eine neue Kachel für fehlgeschlagene Stornoeinträge bereit.
Transaktionsreferenzen bearbeiten
Das Bearbeiten von Referenz 1 und Referenz 2 an Transaktionen sowie an Verkaufsaufträgen und Verkaufsrechnungen ist nun auf definierte Bedingungen beschränkt.
- Eine Änderung der Referenzfelder am Verkaufskopf oder an der Transaktion löst automatisch eine Aktualisierung des jeweils anderen Datensatzes aus.
- Der Page-Update-Trigger wurde entfernt, da er nicht mehr benötigt wird.