Stamm- / Bewegungsdaten im Entwicklungssystem

[Isabella600]

Hallo zusammen,

von unserem SAP-Consultant kam die Anfrage, dass ins Entwicklungssystem eine SAP_ALL Kopie aus dem Produktivsystem durchgeführt werden soll.

Bis jetzt habe ich immer das Entwicklungssystem frei von Stamm- / Bewegungsdaten gehalten.

Die Begründung hierfür sei, dass sonst kein anständiges Customizing möglich sei.

Wie haltet ihr das in euren Systemen?
Was sagt dazu eigentlich SAP? Ich habe keine Hinweise dazu gefunden.

Viele Grüße
Blue

[Alessio37]

Hallo,

mit einer SAP_ALL Kopie alle noch nicht transportierten Entwicklungen töten und sämtliche anderen laufenden Entwicklungen abschießen? Das wäre das Ergebnis des Wunsches eures SAP-Consultant. Die Begründung ist Quatsch.

Im Entwicklungssystem sind bei uns, nur ganz wenige Testkonstrukte von den Entwicklern, die ohne Rückfrage, Testdaten angelegt haben.
Zum Testen gibt es das Testsystem, das alle paar Monate oder bei Projektbedarf, durch eine Kopie des P-Systems aufgebaut wird.

Wenn das Entwicklungssystem durch nicht fertiggestellte Entwicklungen/Customizing zu versaut ist, dann kann man sich schon mal Überlegen, ob man nicht das P-System ohne Stamm- und Bewegungsdaten kopiert und ein neues Entwicklungssystem aufsetzt.

Ist das Delta in einzelnen Bereichen zwischen P- und D-System zu groß, dann kann man einzelne Entwicklungen vor der Anpassung vom P- nach D-System transportieren.

Grüße
Alex

[Ida5160]

Hallo,

wir haben Stamm- und Bewegungsdaten in unserem E-System. Die meisten wurden von den Entwicklern und Architekten im Rahmen der Entwicklung angelegt. Gegen irgendwas müssen ja auch die Entwickler (oder jemand anderes) testen.

Ich stimme zu, dass es ein Problem ist, das E-System sauber zu halten. Also entweder aufräumen (setzt gewisse Kenntnisse voraus, um so etwas wie verschwurbeltes Customizing und Datenschiefstände durch Entwickler wieder hinzubiegen) oder regelmässig neu aufsetzen.

Wir benutzen übrigen die aufräumen Variante.

Gruß

[Isabella600]

Hallo Jungs,

Vielen Dank für eure Einschätzung, ich sehe es ähnlich.

Was ich noch verstehen könnte ware eine SAP_CUST Kopie, aber keine SAP_ALL lehne ich ebenfalls ab.

Viele Grüße
Blue

[Bilal3242]

Hallo,

also im HR-Bereich ist ein Entwicklungssystem ohne aktuelle Daten fast nutzlos. Daher kopiere ich mir immer Beispielmitarbeiter (inkl. allen Tabellen, Abrechnungsergebnissen, etc.) vom P ins E, wenn ich da etwas einstellen muss. Vor Patchen und Releasewechseln werden dann natürlich alle komplett kopiert.

Aus dem Grund nutze ich das Testsystem überhaupt nicht mehr, da mir die dortigen Daten zu alt sind. Das Testsystem ist für mich nun eine Art Sicherheitskopie geworden für den Fall das ich Änderungen noch einmal rückgängig machen muss und den vorherigen Stand sehen will, transportiert wird direkt vom E ins P.

Ich fände es auch nicht schlecht, wenn das E-System mal wieder vom P-System kopiert werden würde, aber da ist natürlich das große Problem das es noch viele offene Aufträge gibt und man dadurch auch die Versionsverwaltung verlieren würde.

Gruß
Michael

[Ida5160]

Hallo,

@miru: Du hast natürlich recht. ich bin Tester und hab folgende Erfahrung gemacht. Es wird auf E getestet, alles ist gut (entweder Entwickler oder Architekt oder Tester vorab).

Dann kommt alles auf Q: Ab und zu wird ebend doch vergessen, Customizing oder Tabellen zu transportieren (oder ne Screenvariante). Man kann zwar auch gut auf E testen, ich würde aber trotzdem nicht auf Q verzichten. Außerdem gibt es ja noch ne Abnahme durch den Fachbereich (entweder auf einem eigenen A oder Q).

Wie man nun auf Q zu einer guten Datenqualität kommt (besonders im HR-Fall) steht auf einem anderen Blatt.

MfG

[Bilal3242]

Dann kommt alles auf Q: Ab und zu wird ebend doch vergessen, Customizing oder Tabellen zu transportieren (oder ne Screenvariante). Man kann zwar auch gut auf E testen, ich würde aber trotzdem nicht auf Q verzichten. Außerdem gibt es ja noch ne Abnahme durch den Fachbereich (entweder auf einem eigenen A oder Q).

Es kommt auch ganz auf die Firma und dessen Größe an wie sowas geregelt ist. In meinem Fall bin ich z.B. Programmierer, Customizer und Sachbearbeiter in einer Person. Ein Großteil der Transporte ist für mich selber, von daher reicht es mir wenn ich das im Entwicklungssystem getestet habe, das muss ich dann nicht nochmal im Test bzw. Produktiv machen.

Gruß
Michael