Das BAPI Cancel() storniert eine Instanz eines Business-Objekts.

Im Gegensatz zum BAPI Delete(), mit dem eine Objektinstanz vollständig von der Datenbank gelöscht wird, wird beim BAPI Cancel()

• die zu stornierende Instanz des Business-Objekts nicht gelöscht,

• eine zusätzliche Instanz angelegt, mit der die entsprechende Instanz des Business-Objekts storniert wird.

Das BAPI Cancel() wird im allgemeinen für die Stornierung von Geschäftsvorfällen, wie z.B. Warenbewegungen oder Rechnungseingängen, verwendet.

Das BAPI Cancel() ist eine Instanzmethode.

Bei der Festlegung der Import-Parameter sind folgende Aspekte zu beachten:

• Das BAPI Cancel() muß als Import-Parameter im Funktionsbaustein die Schlüsselfelder des zugehörigen Business-Objekttyps enthalten. Dabei müssen die Namen der Parameter mit den Namen der Objektschlüssel im BOR übereinstimmen und die gleichen Datenelemente besitzen.

• Die Daten der zu erstellenden Instanz ergeben sich aus den Daten der zu stornierenden Business-Objektinstanz. Sie müssen somit nicht mehr explizit mitgegeben werden.

• Zusätzlich können Sie weitere Parameter für Informationen anlegen, die für den eigentlichen Stornovorgang von Bedeutung sind, z.B. den Namen des Benutzers, der die Stornierung vornimmt.

• Das BAPI muß zusätzlich einen TestRun-Parameter besitzen, der es ermöglicht, Testläufe durchzuführen. Ist dieser Parameter mit dem Wert "X" gefüllt, wird das BAPI zwar normal abgearbeitet, die Ergebnisse werden aber nicht vom BAPI in den Verbucher geschrieben. Somit können nach Ausführen des BAPIs BapiService.TransactionCommit sämtliche Ergebnisse, wie beispielsweise der Application Log, ausgewertet werden, die Datenbank bleibt aber vom BAPI unberührt.

Bei der Festlegung der Export-Parameter sind folgende Aspekte zu beachten:

• In weiteren Export-Parametern müssen der oder die Schlüssel der erzeugten Stornoinstanz zurückgeben werden.

• Legen Sie den Parameter Return an, um Meldungen aus dem Methodenaufruf an das aufrufende Programm zurückzugeben. Um ein umfangreiches Monitoring der Ergebnisse des Cancel()-BAPIs sowohl bei einem synchronen als auch bei einem asynchronen Aufruf zu gewährleisten, müssen beim Füllen des Return-Parameters die folgenden Konventionen eingehalten werden:

• Wird das Cancel()-BAPI erfolgreich abgearbeitet, also eine Stornoinstanz angelegt, muß im Return-Parameter folgende standardisierte T100-Nachricht übergeben werden:

• Das Feld MESSAGE_V1 enthält den externen Namen des Business-Objekttyps, wie z.B. SalesOrder.

• In MESSAGE_V2 wird derjenige Schlüssel zurückgegeben, unter dem auf das stornierte Objekt zugegriffen wurde. Dies kann entweder bei externer Nummervergabe der externe Schlüssel oder bei interner Nummernvergabe der interne Schlüssel sein. Besitzt das Objekt mehrere Schlüsselfelder, dann müssen die Werte dieser Schlüsselfelder in MESSAGE_V2 konkateniert werden. Bei der Konkatenation ist die diejenige Reihenfolge einzuhalten, in der die Schlüsselfelder im BOR definiert sind. Außerdem muß für jedes Schlüsselfeld die maximale Länge verwendet werden, so daß gegebenenfalls ein Auffüllen notwendig ist.

• In MESSAGE_V4 wird der für die Stornoinstanz angelegte Schlüssel zurückgegeben. Dies kann entweder bei externer Nummervergabe der externe Schlüssel oder bei interner Nummernvergabe der interne Schlüssel sein. Besteht der Schlüssel ebenfalls aus mehreren Feldern, dann müssen diese in der gleichen Weise konkateniert werden.

• Tritt bei der Abarbeitung des Cancel()-BAPIs ein Fehler auf, ist neben den anwendungsspezifischen Fehlermeldungen folgende standardisierte T100-Nachricht im Return-Parameter zu übergeben:

• Neben der standardisierten Meldung können weitere Meldungen in den Return-Parameter geschrieben werden. Insbesondere im Fehlerfall müssen Meldungen zurückgegeben werden, die den Fehler konkret beschreiben. Deshalb sollte der volle Funktionsumfang des Typs BAPIRET2 Verwendung finden. Insbesondere sollten die Felder Parameter, Row und Field gefüllt werden.