Aktuelle Versionen

• v28: 28.0.2608.225
• v27: 27.0.2608.232
• v26: 26.0.2608.234

Fehlerbehebungen

Artikel im Capture-LOG ohne Belegreferenz beim Fakturieren ohne Lieferung

Wurde ein Capture während der Buchung erstellt (Capture-Zeitpunkt Buchung, Manuell oder Job), wurden die Transaktionsartikel mit der Liefernr. des Verkaufskopfs versehen. Diese Nummer existiert nur, wenn im selben Buchungslauf geliefert wird. Wurde ein bereits gelieferter Auftrag ausschließlich fakturiert, war sie leer und die Transaktionsartikel enthielten keine Belegreferenz. Die Artikel verwenden nun die Buchungsnr. des gebuchten Belegs und greifen auf die Nr. des Verkaufskopfs zurück, wenn der gebuchte Beleg seine eigene Nummer behält. Noch offene Captures werden beim Update automatisch angepasst.

AmountClearing nach fehlgeschlagenem Capture

Der AmountClearing-Prozess erstellte keinen REVERSAL-Logeintrag, wenn bereits ein Logeintrag für eine fehlgeschlagene oder abgelehnte Abbuchung (Capture) vorlag. Dieses Problem wurde sowohl für den automatischen AmountClearing-Prozess als auch für die manuelle Betragsauflösung behoben.

Zudem wurde ein Problem behoben, das bei der Verarbeitung eines REVERSAL zu einem Fehler führte, wenn in der collana pay-Konfiguration keine externe Sitzung verwendet wurde.

Verbesserungen & Erweiterungen

Artikel können als Gutschein oder Versandkosten verwendet werden

Artikel können jetzt einen collana pay Subtyp tragen, genau wie Ressourcen. Verkaufszeilen mit diesem Artikel gehen dann als Gutschein bzw. Versandkosten an collana pay statt als normale Warenkorbposition.

Das Feld ist standardmäßig leer, für bestehende Artikel und Transaktionen ändert sich also nichts. Eine Änderung wirkt nur auf neue Transaktionen – für eine bestehende hilft die Aktion zum Neuaufbau der Artikelliste auf den Transaktionsposten.

Ebenfalls enthalten

• Ressourcenbasierte Gutscheine verhalten sich jetzt wie artikelbasierte: Bei der Reservierung werden sie gegen die Verkaufszeilen geprüft und bei der Anpassung der zu fakturierenden Menge in Reklamationen berücksichtigt. Bisher wurden sie übersprungen – ein geänderter Gutschein blieb unbemerkt und ein zurückgegebener Gutschein fehlte in der Gutschrift.
• Korrektur: Enthielt ein Warenkorb mehr als eine Versandkostenposition, konnte eine Benachrichtigung die Artikelnr. der einen mit der einer anderen überschreiben. Die betroffene Zeile ließ sich danach nicht mehr erstatten.

collana pay-Transaktionen archivieren und Beleg für eine neue Zahlung freigeben

Offene, nicht abgeschlossene collana pay-Transaktionen auf einem Verkaufsauftrag oder einer ungebuchten Verkaufsrechnung lassen sich jetzt archivieren. Dadurch wird der Beleg für eine neue Transaktion frei – zum Beispiel für eine Umschlüsselung auf Pay by Link oder eine andere collana pay-Zahlungsart – ohne dass die Historie des vorherigen Versuchs verloren geht.

• Aktion „Transaktion archivieren": Auf der collana pay-Transaktionskarte und -liste steht die neue Aktion Transaktion archivieren zur Verfügung. Sie wird verfügbar, sobald eine Transaktion eine fehlgeschlagene, ausgesetzte, abgelehnte oder stornierte (Void/Reversal) Interaktion und keinen erfolgreichen Capture aufweist. Belege mit bereits erfolgtem (Teil-)Capture sind nie archivierbar – dort wird die Aktion ausgeblendet. Solange noch eine Interaktion aussteht, bleibt die Aktion deaktiviert.
• Automatisches Angebot beim Zahlungsartwechsel: Beim Wechsel der Zahlungsart im Beleg auf eine andere collana pay-Zahlungsart wird das Archivieren der bestehenden Transaktion angeboten, damit der Beleg sauber umgeschlüsselt werden kann.
• Vollständige Historie: Die aktive Transaktion behält ihre 1:1-Beziehung zum Beleg, während das Archiv beliebig viele vergangene Transaktionen pro Beleg aufnehmen kann – inklusive Logs, Log-Details und Warenkorbpositionen. Die Archivseiten sind schreibgeschützt.
• Wiederherstellen: Eine archivierte Transaktion kann wieder auf ihren Beleg zurückgeholt werden. Eine Farbanzeige (grün/rot) signalisiert, ob eine Wiederherstellung noch möglich ist (Beleg existiert weiterhin und die Zahlungsart passt noch).
• Absicherung reservierter Betrag: Beim Archivieren einer Transaktion mit noch reserviertem Betrag erfolgt ein Warnhinweis mit der Empfehlung, diesen zu stornieren (über Reversal Amount) oder im PSP-Backend freizugeben. Beim Archivieren wird ein freigegebener Verkaufsbeleg zudem wieder geöffnet, damit der collana pay-Freigabeprozess nicht umgangen wird.
• Setup-Schalter: Die Funktion lässt sich zentral über Transaktionsarchiv aktivieren im collana pay-Setup ein- und ausschalten. Bereits archivierte Transaktionen bleiben auch bei deaktivierter Funktion zugänglich.
• Robuste Benachrichtigungen: Verspätete Benachrichtigungen zu einer bereits archivierten Transaktion werden sauber behandelt und führen nicht mehr zu Fehlern.

Neue Publisher und Integrationsevents

Die folgenden Erweiterungspunkte richten sich an Integrationspartner.

OnIsCreditNeededOnPAYTransactionItemNotFound

Wird innerhalb der Schleife über die Verkaufszeilen in der Funktion IsCreditNeeded ausgelöst, wenn für ein Sachkonto oder eine Zu-/Abschlagszeile kein entsprechender Eintrag in den PAYTransactionItems von collana pay vorhanden ist. IsHandled := true kann gesetzt werden, um das Standardverhalten zu überspringen (entweder exit(true), wenn Gutschriften zulässig sind, oder die Fehlermeldung „Gutschrift nicht zulässig") und mit den verbleibenden Verkaufszeilen fortzufahren.

OnIsCreditNeededOnPAYTransactionItemNotFound(PAYTransaction; SalesHeader; var TempSalesLine temporary; var IsHandled)

OnAfterCaptureNotRefundable

Wenn eine Retourenzeile zu einem Capture passt, dieser aber keine erstattbare Restmenge mehr aufweist oder der Einzelbetrag der Retourenzeile den eingeforderten Einzelbetrag übersteigt, wird der neue Publisher OnAfterCaptureNotRefundable ausgelöst, bevor die Rückerstattung abgebrochen wird. Er liefert die höchste gefundene verbleibende Menge sowie ein Kennzeichen, ob der Einzelbetrag überschritten wurde, und ermöglicht Erweiterungen die Behandlung dieses Falls. Der bestehende Publisher OnAfterCaptureNotFound wird weiterhin nur dann ausgelöst, wenn die Retourenzeile zu keiner Zahlungseinforderung passt. Zusätzlich wird der Behandlungsstatus nun je Verkaufszeile zurückgesetzt, sodass eine von einer Erweiterung behandelte Zeile die Prüfung der folgenden Zeilen nicht mehr unterdrückt.

OnBeforeCheckCreditAmountExceedsCapture

In PAY Item Handling HVE.FindNextCaptureForCreditLog wurde das Integrationsevent OnBeforeCheckCreditAmountExceedsCapture vor der Prüfung hinzugefügt, ob der Gutschriftsbetrag den erfassten Betrag (Capture-Betrag) übersteigt. Partner können CreditAmount, CapturedAmount oder AlreadyCreditedRefundedAmount anpassen (z. B. um Gutscheine von Drittanbietern zu berücksichtigen, die nicht in den Verkaufszeilen aufgeführt sind) oder IsHandled setzen, um die Prüfung zu überspringen.

Die Prüfung auf negative Gutschriftsbeträge wurde vor die Prüfung auf Überschreitung des Betrags verlagert, sodass NegativeCreditAmountForRefErr nun erreicht werden kann.

Neuer Publisher für benutzerdefinierte Belegtypen (Custom Doc Type)

Ein neuer Publisher wurde hinzugefügt, um Partnern die Verwendung von Dokumenttypen ohne Sales Header oder von fremden Dokumenttypen zu ermöglichen.