Möchte man in unserem Beispiel mit der Anzahl Spieler 0, wie im Klassiker War Games, das beide Spieler strategisch vorgehen, ist im Unterprogramm „spielen“ folgendes zu ändern.
Es wird zuerst, ist der Spieler SAP am Zug, der Defensivzug durch die Summe der Zeilen,Spalten oder Diagonalen mit dem Wert 10 bestimmt. Danach der Offensivzug mit der Summe 2. Ist der Spieler USR am Zug genau umgekehrt. Ist Defensiv gegen 2 vorzugehen und anschließend ob die Summe 10 zum Gewinn führt.
Im Artikel (Link) erwähnte ich eine Offensiv- und Defensivstrategie für den alten Übungscode den ich zur Anschauung (Link) überarbeitet habe.
Strategiedaten eingeblendet damit sie ohne Debugger im Spielverlauf beobachtet werden können.
Im Code sehen wir, das zunächst Spielzüge wie im Original per Zufallszahl ermittelt werden. Das gilt für den Spieler SAP (wer=1) immer und für den Spieler USR (wer=5) wenn die Anzahl der Spieler Null ist (a=0). Vor dem setzen des Zuges, wird der Zug für den Spieler SAP strategisch gesprüft. Zunächst Defensiv – das heisst, hat der Spieler USR zwei Züge gemacht (ein Zug hat den Wert 5) ist die Summe der Zeilen, Spalten oder Diagonalen gleich 10. Ist sie gleich 10, bedeutet es, das der nächste Zug des Spielers USR zum Gewinn führt. Es wird also das freie Feld in der Zeile, Spalte oder Diagonalen gesucht und die Werte x und y, für den nächsten Zug des Spielers SAP, angepasst.
Danach erfolgt die Offensivprüfung. (Im Code sehen wir die Aufrufe PERFORM strategie USING 10. und PERFORM strategie USING 2.) Hier wird nun geprüft ob der nächste Zug des Spielers SAP zum Gewinn führt. Es ist sinnvoller direkt zu gewinnen, als sich zu verteidigen. Die Werte x und y können also wieder manipuliert werden. KÖNNEN! Wie gesagt, die Werte x und y sind Zufallszahlen und bleiben unverändert wenn keine Strategie greift. Das passiert solange keine zusammenhängende Züge gemacht werden, wie zum Beispiel zum Beginn des Spiels.
Genau hier liegt jetzt die Chance des Spielers USR. Nur noch mit Glück und ausgefeilter Taktik kann USR noch gewinnen. Zum Beispiel führen die Züge 2,1 3,3 2,2 mit dem finalen Schlag auf 2,3 zum Gewinn. WENN keine Zufallszahl in die Quere kommt. Das Geheimnis liegt darin, zwei mögliche Gewinnsituationen zu stellen. Mit 2,1 3,3 „bemerkt“ die Strategie noch nichts. Kommt jetzt 2,2 hinzu, habe ich in der zweiten Zeile und in der Diagonalen die Summe 10. Für den User SAP wird jetzt vorrangig ein Zug in der Diagonalen vorgeschlagen, also auf 1,1. Jetzt kann USR in der zweiten Zeile gewinnen.
Mit Defensivstrategie wird es für den User schwierig
Lang ist es her, aber gerne benutze ich den alten Code und lasse ihn auch noch auf einer PDP11 laufen. Im letzten Workshop sprachen wir über die Möglichkeiten der Programmierung eines Reports in ABAP. Wir wissen, das ein Report für die dynamische, interaktive Darstellung von Listen gedacht ist. Als Übung, damit die laufzeitabhängigen Ereignisse eines Reports klar werden, habe ich den original DEC Code des Spiels „Tic Tac Toe“ gegeben der analysiert und in ABAP realisiert werden sollte.
Hier nun eine kurze Vorstellung meiner Musterlösung.
Der Sinn des Spiels ist klar – drei Felder, in einer Reihe, Spalte oder Diagonalen sind zu besetzen. Wir erkennen im Original, in den Zeilen 1090 und folgenden, das die Züge der Maschine per Zufallszahl erzeugt werden.
Das ist auch so in ABAP realisierbar. Es stehen ein Funktionsbaustein aus der Gruppe QF05 (QF05_RANDOM_INTEGER) sowie die Klasse CL_ABAP_RANDOM_INT zur Verfügung.
Expliziet wird der Zug geprüft, nämlich ob das Feld bereits belegt wurde und ob der Zug zum Gewinn der Partie führt. Das Vorgehen, auch gerade mit den im Original verwendeten Befehlen GOTO und GOSUB, ist im Report nicht möglich da er nicht prozedual abläuft. Um nah, wie die Aufgabe lautet, am Original zu bleiben, empfiehlt sich für den Ersatz des GOSUB der Befehl PERFORM.
Um die Sache etwas interessanter zu machen, habe ich zwei Dinge berücksichtig. In der Grundliste des Reports (SY-LSIND = 0) kann „Anzahl Spieler 0“ eingegeben werden. Das Programm spielt dann beide Spieler – wir erinnern uns an den Klassiker „War Games“. Eine Defensivstrategie ermöglicht dem Spieler „SAP“ einen Gewinnzug des Gegners zu verhindern. Taktisch wird nach jedem Zug die Summe der Zeilen, Spalten und Diagonalen errechnet und dem entsprechend ein Zug vereinbart. Dennoch ist es dem User möglich zu gewinnen, nämlich dann, wenn es mehr als eine Gewinnmöglichkeit gibt. Eine Offensivstrategie ist nicht implementiert – das kann als
Ohne Defensivstrategie ist der User im Vorteil.
Zwei Gewinnmöglichkeiten. Der User hat die Chance zu gewinnen.
Mit Defensivstrategie wird es für den User schwierig
Zusatzaufgabe verstanden werden. Offensiv heisst, das Programm stellt nicht fest ob oder das der nächste Zug zum Gewinn führt. Gibt es nichts zu verteidigen, wird eine Zufallszahl über den nächsten Zug entscheiden!
Grundsätzlich sollte man, nach Aktivierung der neuen Hauptbuchhaltung, auf die Anwendung alter Reports und den Transaktionen wie zB. FBL3N oder FS10N verzichten. In der Praxis haben sie dennoch ihren Reiz und ich erliege auch oft ihrem Charme und verwende sie.
Wo liegt nun der Zusammenhang mit dem Kennzeichen Einzelpostenanzeige wie sie zB über die Transaktion FS00, in den Steuerungsdaten Kontoverwaltung im Buchungskreis, zu finden ist?
Im wesentlichen ist zu sagen, das mit setzen des Kennzeichens u.a. eine zusätzliche Tabelle ( BSIS ) geführt wird, in der die Verbindung Belegposition und Konto geführt wird. Ausserdem sind die Tabellen BSIS und BSAS für die OP Verwaltung wichtig. Die SAP Dokumentation gibt umfassend Auskunft. In diesem Kontext aber, sind die Stichworte Erfassungs- und Hauptbuchsicht entscheidend.
Die Transaktion FAGLL03 führt, in der Standardvariante, immer zu einer Einzelpostenliste – auch ohne Kennzeichen „Einzelpostenanzeige“. Warum ist das so?
Es ist Augenwischerei! Es ist die Betrachtungssicht zu beachten. Die Betrachtung der Einzelpostenliste, aus Sicht des Sachkontos, ist eine andere als die aus Sicht des Hauptbuchs. Die Transaktion FAGLL03 beginnt in der Standardvariante mit der Einzelpostenliste Hauptbuchsicht – die Transaktion FBL3N mit der Einzelpostenliste Erfassungssicht.
Das Kennzeichen „Einzelpostenanzeige“ in den Steuerungsdaten des Sachkontos ist also sehr wichtig wenn es um die Anzeige der Belegaufteilungen in der Erfassungssicht geht. Das Kennzeichen, wenn es denn vergessen wurde zu aktivieren, lässt sich auch nachträglich aktivieren.
Über die FS00 ist das Kennzeichen für das betreffende Konto zu setzen. Danach muss das Konto gesperrt werden ( Systemfunktionsleiste –> Sachkonto/Sperren ). Mit dem Aufruf des Reports RFSEPA01 (SA38) wird die Tabelle BSIS nachträglich generiert.
Die echte Einzelpostenanzeige, also die Sachkonteneinzelpostenliste in der Erfassungssicht, steht zur Verfügung.
Etwas umständlich ist die Suche nach Belegen und Buchungen im Tryton ERP System. Will man nicht in Views herum klicken und bei der Suche nach Buchungsnummer oder Fremdbelegnummer gar in verschiedenen Listen suchen, muss sich die Auswertung selbst anlegen.
Das Standardjournal ist unbrauchbar
Suche in der Buchungsübersicht
Suche in einer Buchungszeile.
LibreOffice kann hier helfen. Es besitzt im Programm „Base“ bereits alle nötigen Schnittstellen zu vielen Datenbanken – so auch zu Postgresql, welche Tryton nutzt. Mit etwas Geduld findet man die entsprechenden Tabellen die Belegnummer, Buchungsatznummer, Abstimmung und Fremdbelegnummer beinhalten. Achte auf die LEFT OUTER JOIN Bedingungen, da nicht alle Buchungssätze unbedingt Fremdbelegnummern besitzen. (Link)
Direkte Verbindung zu Postgresql
Logische Verbindungen zu einem Buchungssatz.
Auf die JOIN Bedingungen achten!
Die Abfrage lässt kaum Wünsche offen
In CALC unter Ansicht/Datenquellen lässt sich die Abfrage direkt einbinden
Eingebunden in LibreOffice CALC oder Microsoft Excel lässt sich die Liste jetzt nach allem filtern und sortieren. In der Revision unglaublich hilfreich, wenn Konten gruppiert und Belegnummern schnell gefunden werden können.
Eine interessante Entdeckung kann man machen, wenn man SAP Systeme mit der Transaktion STMS miteinander verbindet. Ich habe das IDES System mit der Development Version NSP verbunden um Pakete auszutauschen. Anleitungen dazu existieren (Link).
Was aber erstaunlich ist, die möglicher Weise existierende Konfiguration eines Services – in meinem Fall die des SMTP Port – werden mit den Daten des exportierenden Systems ergänzt.
SICF – Der Service wird mit dem Link zum Transportsystem kopiert
IDES – NSP System per Link als Transportziel.
NSP – IDES System als Transportziel
Hier war es so, dass die Konfiguration des Services (SICF) im IDES System geändert und neu aktiviert werden musste. Pakte können aber problemlos zwischen beiden Systemen transportiert werden.
Möglichkeiten, Daten aus Altsystemen in SAP zu importieren, gibt es reichlich. LSWM, SHDB sind die wichtigsten Transaktionen die auch sehr gut dokumentiert sind. Sie basieren auf der Technik des Batch-Input – also des „abspielens“, des simulierens einer Benutzeraktion mit Dateneingabe. Im Fall des Adressimports, genauer: Adressdatensätze der Geschäftspartner – ist dieses Vorgehen sehr umständlich, sehr Ressourcenaufwendig und führte, bei meinen Versuchen, zu einem Speicherüberlauf da nicht nur die BUP1 Transaktion angesprochen wird, sondern zeitgleich mehrere Prozesse angestossen werden die für die Sache eigentlich nicht nötig sind. Es sollte unbedingt darauf verzichtet werden und den Import über Code und den entsprechenden Verbucher-Funktionsbausteinen der BAS zu realisieren. Hilfreich ist diese Seite zu der Funktionsgruppe SZA1.
In der Schulung gehen wir einmal den Weg eines Batch-Inputs der grundsätzlich sehr gut ist.
In der Transaktion SHDB starten wir eine neue Aufzeichnung mit der Transakton BUP1 und legen einen Kunden „Mustermann“ an. Wenn die Aufzeichnung nach dem speichern des Kunden beendet ist, sieht man eine lange Liste der ausgeführten Aktionen auf dem Screen.
Mit dieser Aufzeichnung lässt sich einiges anstellen: Als Vorlage für den Import mit der Transaktion LSMW, als eigenständiger Report oder als Funktionsbaustein. Letzteren wollen wir einmal ausprobieren.
Hier zeigt sich schon der ernorme Ressourcenverbrauch. In meinem Beispiel importiere ich eine CSV Datei mit 4000 Sätzen. Es wird 4000 mal der Input in die Transaktion BUP1 erzeugt. Man sollte darüber kurz nachdenken, bevor man F8 drückt! In der Realität würde ich mit Sicherheit den Verbucherbaustein direkt mit einem COMMIT WORK AND WAIT aufrufen.
Datemimport ist eine einmalige Sache, bei der man schon den zu betreibenden Aufwand berücksichtigen muss. Über den Batch-Import ist aber immer gewährleistet, nur gültige Daten importiert zu haben. Andere Ideen, wie der Import in das BAS schöner gestaltet werden kann, sind willkommen und werden veröffentlicht!
Nach Aufzeichnung lassen sich automatisch Reports und Funktionsbausteine generieren.
Nach Aufbereitung der Importdaten, wird pro Satz einmal der FB aufgerufen
Es kommt immer wieder vor, das Buchungen falsch erfasst wurden. Richtig ist es, diese Buchung durch eine Gegenbuchung zu stornieren. Genau so wie es gesetzlich vorgeschrieben ist, in den Bücher keine Radierung vor zu nehmen, ist auch in der elektronischen Buchhaltung eine Stornierung immer nachvollziehbar. Sollte so sein.
Entwickeln und lernen macht in der Gruppe mehr Spass. SAP stellt ein Basis-System für Entwicklungsarbeit kostenlos zur Verfügung von denen wir zwei Systeme in Betrieb halten. Zum einen ein Netwaeaver 702 auf einem Windows Terminalserver und ein Netweaver 750 System auf meinem Linux PC. Ein gravierender Unterschied fiel mir auf, den das System 702 zum idealen Entwicklungssystem für Gruppen kürt.
Neben den Änderungen der Syntax im ABAP Befehlssatz (Artikel) ist der Entwicklerschlüssel, der zur Erzeugung von Code im System berechtigt, nun digital signiert und setzt einen installierten Lizenzschlüssel voraus!
Wir wissen, bei der ersten Inbetriebnahme wird zunächst ein temporärer Lizenzschlüssel generiert, der sich bei der Berechnung der Gültigkeit zunächst an der Systemuhr zum Zeitpunkt des Starts orientiert. Im Netweaver 702 konnte es nun passieren, das man das System mit einem gültigen, sehr lange gültigen, temporären Lizenschlüssel in Betrieb nimmt und der Entwicklerschlüssel auch gültig ist.
Dieser Fehler, den man fairer Weise niemals nicht nie ausnutzen sollte, wurde in der Version 750 korrigiert – eben durch Signierung des Entwicklerschlüssels mit der signierten Programmlizenz, so das hier alle 90 Tage die Lizenz erneuert werden muss.
In beiden Versionen ist der Entwicklerschlüssel immer nur einmal gültig! Das heisst: Mag man auch so viele Benutzer und Mandanten anlegen können, wie man möchte, gibt es nur einen Entwickler. Ungünstig, wenn mit mehrer Entwicklern an einem Projekt gearbeitet werden soll.
Schalten wir doch vor Eingabe des Entwicklerschlüssels einmal den Debugger ein und verfolgen die Programmlogik. Wir sehen, dass ein Funktionsbaustein aus der Funktionsgruppe SKEY benutzt wird. Im ablaufenden Include Programm wird die Funktion
Implizite Erweiterung im Rahmenprogramm Include
NETWEAVER 702 und 750. Code ist gleich geblieben
„DEVELOPER_KEY_CHECK“ nach der Güligkeit des Schlüssels befragt, die mit entsprechenden Rückgabewert SY-SUBRC den Entwickler zulässt oder eben nicht. Hier können wir eine impliziten Erweiterung vornehmen, nämlich derart, das der Rückgabewert der Funktion immer „0“ also gültig ist. Beliebig viele Benutzer können nun mit dem einen gültigen Entwicklerschlüssel Code erzeugen.
In den neueren Spielereien unseren hochgeschätztem Enno Wulff wird der überarbeitete ABAP Befehlssatz verwendet. Ich verwende noch den Stand 702 und kann so einfach seinen Code nicht übernehmen.
So verwendet er gerne die neue Kurzschreibweise mit der eine Klasse instanziiert wird: NEW x( ).
Seht in seinen Code unter den Zeilen 20 und 98 und erinnern wir uns an BC401 Seite 59.
Die Zeile 20 mit „timer = NEW #( )“ ändern wir durch –> „CREATE OBJECT timer.“ und das „NEW main()–>start().“ ersetzen wir mit
„DATA m TYPE REF TO main.
CREATE OBJECT m.
m->start( ).“
Dann läuft die Sache auch und ist eine tolle Vorlage für so manch Lösung.
damit die laufzeitabhängigen Ereignisse eines Reports klar werden, habe ich den 
im Original, in den Zeilen 1090 und folgenden, das die Züge der Maschine per Zufallszahl erzeugt werden.
Belegaufteilungen in der Erfassungssicht geht. Das Kennzeichen, wenn es denn vergessen wurde zu aktivieren, lässt sich auch nachträglich aktivieren.
Du muss angemeldet sein, um einen Kommentar zu veröffentlichen.