allg. Frage zu DB Tabellen und Feldern

allg. Frage zu DB Tabellen und Feldern

Hallo,

wie geht ihr als Entwickler ans Werk, wenn ihr nicht gerade einen Berater an der Seite habt und einen Report entwickeln müsst?
Woher wisst ihr welche Tabellen ihr braucht und vorallem, welche Felder um zu dem Resultat zu kommen?
Und wie die Abhängigkeiten zwischen den Tabellen sind?

Muss ich dies wissen oder ist es eigentl. die Aufgabe eines Beraters mir diese Infos zu geben?

Ich weiß in der Regel nicht, welche Kenntnisse vorausgesetzt werden und welche Infos ich beim Berater selber einholen sollte.

Viele Grüße
coco

Re: allg. Frage zu DB Tabellen und Feldern

black_adept hat geschrieben:du hast gerade den Unterschied zwischen einem Entwickler mit mehr und einem Entwickler mit weniger Erfahrung entdeckt.

Zwischen einem Entwickler und einem Azubi.

Die Kernkompetenz eines Entwicklers ist die Entwicklung von Problemlösungsstrategien (darum ja "Entwickler" har har har). Was heute keiner mehr braucht, sind Batch-Input-Mappen-Erzeuger-Eintipper. Die Probleme sind oft schon betriebswirtschaftlich knifflig (hat mal wer den Importprozess eines Artikels nach China verstehen müssen? Die 50 m vom Schiff über das Zolllager in das Freilager sind eine Freude für einen jeden Buchhalter ). Wenn man den entsprechenden Prozess (das eben war nur ein Beispiel) dann verstanden hat bzw. eine Lösung mit dem Berater / Keyuser erstellt hat, geht's daran, dafür ein Programm zu schreiben, das das Problem zu lösen imstande ist.

Da ist das Wissen darum, wo was in der DB abgelegt ist, absolutes Basiswissen (man weiss natürlich nicht immer alles, aber man kann alles herausfinden). Und dann kriegt man die Krätze, weil Betragsfelder im SAP auf der DB immer zwei Nachkommastellen haben. Das hätte man den Japanern (und anderen) erklären müssen, als die Währungen ohne oder mit drei Nachkommastellen "erfunden" haben. Ehe man also einen Betrag zum Beispiel in ein IDOC schreibt (so wars bei mir), stellt man erstmal fest, wie viele Nachkommastellen die Währung hat, denn selbst ein "Komma Null" darf dann nicht erscheinen, weil das empfangende System (in diesem Falle das von einer Clearingstelle in den USA) damit nicht klarkommt. Wenn man 50 Testfälle in EUR und USD hat und kurz vor Produktivstart einer auf die Idee kommt, mal aus Spaß eine Rechnung für Japan zu testen.....

(Stell ich mir gerade witzig vor, wie die eine neue Währung beschließen und einer aus dem Ministerium sagt: Das geht nicht - ist in SAP nicht abbildbar LOL)

Die Programmieranforderungen werden auch zunehmend diffuser, so ist mein Eindruck. Es gab Zeiten, da schickte man mir ein Konzept, das man mehr oder weniger herunterprogrammieren konnte (mit den oben beschriebenen Problemen), inzwischen erhalte ich Programmieranforderungen für ganze Verbuchungstransaktionen, die auf ein Post-it-note (das sind die Dinger, auf denen man eigentlich Passwörter speichert ) passen.

Re: allg. Frage zu DB Tabellen und Feldern

c oco hat geschrieben:

Da ist das Wissen darum, wo was in der DB abgelegt ist, absolutes Basiswissen (man weiss natürlich nicht immer alles, aber man kann alles herausfinden).

Wie kann man alles herausfinden? (Abgesehen vom Berater fragen)

Erstmal versuche ich, per Logik drauf zu kommen. So findet man einfache Tabellen wie MKPF/MSEG oder BKPF/BSEG. Gerade bei alten Tabellen funktioniert das ziemlich gut. Ansonsten suche ich halt per Suchhilfe mit Suchbegriffen in der Beschreibung. Wenn das nicht hilft, muss die Brechstange her. Zum Beispiel per SQL-Trace. Oder durch Suchen im Coding der SAP. Zur Not im Debugger.

Re: allg. Frage zu DB Tabellen und Feldern

ralf.wenzel hat geschrieben:Zur Not im Debugger.

Da musst ich doch ein wenig lächeln

"Zur Not....'. Also der Debugger ist einer meiner besten und ehrlichsten Freunde.

In meiner Firma fiel auch schon der Spruch "Niemand mag debuggen".

Falsch: Ich(!) liebe es zu debuggen.

Re: allg. Frage zu DB Tabellen und Feldern

Danke an alle für die hilfreichen Tipps.

Viele Grüße
coco