Dieser Artikel beschreibt die Änderungen der collana pay App, veröffentlicht am 16.10.2026. Die Änderungen sind in folgenden Versionen enthalten:

• v28: 28.0.2610.1666
• v27: 27.0.2610.1674
• v26: 26.0.2610.1677

Fehlerbehebungen

Rundungspräzision der Währung wird bei Währungen mit ganzen Beträgen verwendet

Beträge, die an collana pay übertragen werden, wurden bisher immer auf zwei Nachkommastellen gerundet.

Für Währungen, deren Rundungspräzision in Business Central gröber als 0,01 ist (z. B. HUF oder CZK mit ganzen Beträgen), verwenden folgende Bereiche jetzt die Rundungspräzision der Währung, sodass die Beträge zum Beleg passen:

• die Transaktionsartikel
• der an collana pay gesendete Warenkorb
• die Betragsprüfungen gegen den Beleg

Die Toleranzen der Erstattungsprüfungen skalieren entsprechend mit.

Für Währungen mit einer Präzision von 0,01 oder feiner ändert sich nichts: collana pay arbeitet mit zwei Nachkommastellen, daher bleibt 0,01 die feinste Präzision.

Beim Löschen einer Transaktion werden verwaiste Transaktionen gebuchter Belege mit entfernt

Schlägt eine Buchung fehl (z. B. ein abgelehnter Capture), hat collana pay bereits eine Transaktion vom Typ Posted Sales Invoice bzw. Posted Sales Credit Memo für die nie verwendete Buchungsnummer geschrieben. Dieser Datensatz teilt sich die Transaktions-GUID mit der Auftragstransaktion und hielt dadurch Transaktionslog und Positionen am Leben, nachdem die Auftragstransaktion gelöscht wurde.

Ein neuer STATUS-Aufruf übernahm dann die alte GUID mit der alten Positionsliste. Das blockierte den üblichen Ausweg aus einer fehlgeschlagenen No-Cart-Buchung: Transaktion löschen, Auftrag korrigieren, neuen STATUS starten.

Das Verhalten wurde wie folgt angepasst:

• Beim Löschen der Transaktion eines Verkaufsauftrags, einer Rechnung, einer Reklamation oder einer Gutschrift werden jetzt auch diese verwaisten Transaktionen gebuchter Belege gelöscht (Transaktionen, deren gebuchter Beleg nicht existiert).
• Log und Positionen werden mit der letzten Transaktion entfernt. Der nächste STATUS-Aufruf legt dadurch eine neue Transaktions-GUID mit frischem Log und frischer Positionsliste unter derselben collana pay Transaktions-ID an.
• Transaktionen gebuchter Belege, deren Beleg existiert (z. B. eine frühere Teilrechnung), und Mandatstransaktionen bleiben unberührt.
• Dieselbe Bereinigung läuft beim Löschen des Verkaufsbelegs und beim Archivieren der Transaktion.

Upgrade-Hinweis

Ein Daten-Upgrade ist nicht nötig.

Teilrechnungen brechen nicht mehr ab, wenn die Debitorenposten-Referenzen eines Captures das Log-Feld überschreiten

Wird ein Auftrag mit einem Capture bezahlt (Capture = Freigabe oder eine als bereits eingezogen importierte Transaktion), trägt jede Teilrechnung die Nummer ihres Debitorenpostens in das Feld Customer Ledger Entry Filter des CAPTURE-Logeintrags ein.

Das Feld fasst 250 Zeichen, sodass nach etwa 25 Teilrechnungen die nächste Buchung mit einem Fehler zur Textlänge in der Verkaufsbuchung abbrach. Betroffen waren Aufträge mit vielen Einzellieferungen.

Das Verhalten wurde wie folgt angepasst:

• Die Referenzen werden nur noch eingetragen, solange sie in das Feld passen.
• Ist das Feld voll, wird der Filter mit der Markierung |0 abgeschlossen. Es werden keine weiteren Posten mehr aufgenommen, die Buchung läuft weiter.

• Bei einem solchen abgeschnittenen Filter werden die Debitorenposten über die gebuchten Verkaufsrechnungen der Transaktion statt über den Filter ermittelt. Das gilt für:

  • die Anzahl der verknüpften Debitorenposten und den Drilldown im Transaktionslog
  • die Prüfung des Erstattungsbetrags im Order Amount Clearing

  Die Debitorenposten bleiben dadurch vollständig und die Prüfung bleibt exakt.

Upgrade-Hinweis

Ein Daten-Upgrade ist nicht nötig.

Rechnungsrundungszeilen (z. B. HUF) werden bei collana pay ignoriert

Bei Währungen mit einer Rechnungsrundungspräzision (z. B. HUF) fügt Business Central jeder Rechnung eine Rundungszeile hinzu. collana pay zieht diesen Betrag nie ein, er bleibt als Rundungsdifferenz auf dem Debitorenposten offen.

Bisher wurde die Zeile wie jede andere Belegzeile behandelt. Dadurch traten folgende Fehler auf:

• Die letzte Buchung eines vollständig eingezogenen Auftrags scheiterte („Artikel ... wurde während des Betragsausgleichsvorgangs in den Transaktionsartikeln nicht gefunden“ bzw. ein Fehler zum fehlenden Verk.-an-Debitor).
• Das erneute Freigeben eines solchen Auftrags wurde blockiert („Der Belegbetrag übersteigt den von collana pay eingezogenen Betrag“).
• Spätere Rücksendungen wären abgelehnt worden.

Das Verhalten wurde wie folgt angepasst:

• Die Rundungszeile ist für collana pay jetzt unsichtbar: Sie ist nicht Teil der Warenkorbvergleiche, zählt nicht als fakturiert und wird weder erstattet noch storniert.
• Der Abschluss eines Auftrags, den Business Central nach der letzten Buchung löscht, läuft jetzt, solange der Auftrag noch existiert, sodass die Buchung durchläuft.

Für Währungen ohne Rechnungsrundung, z. B. EUR, ändert sich nichts.

Verbesserungen & Erweiterungen

Refund – Klare Fehlermeldung, wenn der Capture noch auf die Aufgabenwarteschlange wartet (Capture = Job)

Bei Capture = Job wird der Capture einer Bestellung erst gesendet, wenn die collana pay Aufgabenwarteschlange läuft. Eine vorher gebuchte Reklamation oder Gutschrift brach bisher mit der allgemeinen Meldung „No capture was found“ ab, obwohl der Capture existiert und nur noch nicht verarbeitet ist.

Dieser Fall hat jetzt eine eigene Fehlermeldung, Capture Not Yet Processed:

• Sie nennt den bezahlten Beleg und den Aufgabenwarteschlangenposten, der den Capture sendet, samt dessen Status (z. B. Angehalten).
• Sie erklärt, dass der erfasste Betrag erst nach dem Senden des Captures erstattet werden kann.
• Sie verweist auf den Capture-Eintrag mit Status Created im collana pay Transaktionslog.
• Gibt es gar keinen Aufgabenwarteschlangenposten für die collana pay Job-Funktionen, sagt die Meldung auch das, weil der Capture dann nie gesendet würde.
• Wo die Plattform Fehleraktionen anzeigt, bietet die Meldung zusätzlich das Öffnen der collana pay Aufgabenwarteschlangenposten und der Transaktion an.

Bereits gesendete Captures, die auf die Antwort des Zahlungsanbieters warten (Status Pending), sowie Transaktionen mit anderem Capture-Zeitpunkt behalten die bisherige Meldung.

Assisted Setup – API-Schlüssel wird über die collana pay Admin-API erstellt und geprüft

collana pay zeigt die API-Schlüssel eines Tenants nach dem Erstellen nicht mehr an. Der Assisted Setup prüft jetzt, ob der in Business Central gespeicherte API-Schlüssel noch ein aktiver Schlüssel des Tenants ist, und legt andernfalls über die collana pay Admin-API einen neuen Schlüssel an. Der neue Schlüssel wird im Assistenten einmalig angezeigt.

Neue Aktionen in der collana pay Einrichtung

• API-Schlüssel erstellen
• API-Schlüssel prüfen
• API-Schlüssel eingeben – für einen im Admin-Portal erstellten Schlüssel
• API-Schlüssel entfernen – z. B. in einem aus einer Live-Datenbank wiederhergestellten Testsystem
• Zugriffstoken zurücksetzen – fordert nach geänderten OAuth-Zugangsdaten ein neues Token für die Admin-API an

Speicherung und Verwaltung des API-Schlüssels

• Der API-Schlüssel wird nur noch im Isolated Storage gehalten. Die collana pay Einrichtung zeigt nur noch die letzten fünf Zeichen des gespeicherten Schlüssels.
• Business Central hält je Umgebung (Live / Sandbox, gewählt über Sandbox-Modus) einen eigenen Schlüssel.
• Über Business Central erstellte Schlüssel werden nie automatisch widerrufen. Nicht mehr benötigte Schlüssel werden im collana pay Admin-Portal widerrufen.

Fehlermeldungen zur Admin-API

• Ein fehlgeschlagener Abruf des Zugriffstokens für die Admin-API wird jetzt mit Status und Fehlerbeschreibung des Identitätsanbieters gemeldet (und in die Telemetrie geschrieben), statt stillschweigend beim nächsten Aufruf zu einem 401 zu führen.
• Unbekannte Eigenschaften in der Token-Antwort führen nicht mehr zu einem Fehler.
• Können die Zugangsdaten für die Admin-API nicht geladen werden, unterscheidet die Meldung jetzt zwischen:
  • On-Premises
  • Installationen als PTE bzw. im Dev-Scope
  • der AppSource-Installation (Key Vault)

⚠️ Deprecations

Upgrade-Hinweis

• Das Feld API-Schlüssel in der collana pay Einrichtung wird beim Upgrade geleert.
• Beim Upgrade wird der vorhandene Schlüssel der aktuell aktiven Umgebung zugeordnet.

Reservierung – Reserve-Anfragen senden keinen leeren Warenkorb mehr

Die Reservierungsanfrage (z. B. bei der Verlängerung einer Reservierung) enthält keinen Warenkorb mehr. Der Warenkorb wird mit der Create-Interaktion übermittelt, in der Reserve-Anfrage war er bisher immer leer.

Die simulierte Reservierungsantwort wurde angeglichen und liefert ebenfalls keinen Warenkorb mehr. Für bestehende Installationen ändert sich nichts.