Detectar " machetazo " a programas estandar

[Figarogd]

Buenos días:
En primer lugar aprovecho para presentarme y daros las gracias por admitirme en este foro así como de darme la posibilidad de aprender con todos vosotros.
Empiezo por decir que no soy administrador de sistemas ni conozco tecnicamente R/3 así que perdonar por si la duda que os planteo resulta un poco absurda. La cuestión es la siguiente: en mi empresa tenemos que elevar el nivel de parches de uno de erp´s del 19 al 61 en una maquina ( base de datos sql server 2000, sist. op windows NT, ver sap. 45 b ) que desconocemos si tiene o no modificaciones y/o ampliaciones en los programas estandar ¿ existe alguna forma de hacer algún testeo a la maquina y que dicho testeo nos diga donde existen ( si existen ) dichas modificaciones ?.

Gracias de antemano por vuestras respuestas, un saludo.

Figaro

[ChaloZ]

Hola Figarogd, una pregunta:¿A que te refieres con modificaciones? ¿Necesitas saber que nivel de parches tiene el sistema?

[Figarogd]

Hola ChaloZ:

El nivel de parches que tiene el sistema lo conozco, estamos en el nivel 19. El problema que tengo es que tenemos que elevarlo hasta el parche 63 debido a una implantación de BW 3.5. Como la implantación de parches puede tocar parametrización lo que me gustaria saber es si existe alguna erramienta que me diga aquellos programas, tablas, objetos ... que estan modificados en SAP para una vez aplicados los parches comprobar que dichos programas funcionan correctamente.

Un saludo,

Figaro

[johangonz]

Figaro, te comento:

cuando aplicas patches ó como bien se conocen support package, lo haces primero en una instancia de DEV, luego, por las transacciones SE95 y SPAU emites un reporte de las modificaciones realizadas por sp. Te comento que los sp que por lo general realizan modificaciones son los appl en vista de que si haz realizado una modificacion sobre un programa estandar de sap y un sp toca ese programa lo vuelve al estado original perdiendo dichos cambios. En los demas aspectos es trasparente, no toca customizing ni nada de esas cosas, solo agrega funciones, objetos, etc, por el cual lo idoneo es que luego de aplicados los sp ejecutes estas transacciones y el resultado lo pases a un desarrollador (abapero) para que el nuevamente haga dichos cambios para cuando apliques en QAS y PRD los transportes y no hayan cambios notorios para los usuarios. Los programas Z* los sp no los toca en ningun momento asi como customizing como te mencione.

Johan González
Administrador Comunidad Basis en Español

[sapitoo]

Hola buenas tarde, pido tu opinion y comentario para el caso en que tienes un semaforo verde en la SPAU con el objeto:
CL_IM_UMB_AUTHORITY con la nota
0001023295 Balanced Scorecard: Authorization check in BAdI
No se si darle adopt modification o reset original (transporte padre X34K915768)


La persona que esta instalando el upgrade nos comenta de otro objeto el cual es:CL_UMM_MC_BSP_APPLICATION (Transporte hijo X34K915769)el cuaL tien como 10 objetos inactivos y no nos permite liberarlo para seguir el upgrade

Objetos inactivos en ...BSP_APPLICATIOn
CLSD CL_UMM_MC_BSP_APPLICATION is inactive
CLSD CL_UMM_MC_BSP_APPLICATION is inactive
CPRI CL_UMM_MC_BSP_APPLICATION is inactive
CPRI CL_UMM_MC_BSP_APPLICATION is inactive
CPUB CL_UMM_MC_BSP_APPLICATION is inactive
CPUB CL_UMM_MC_BSP_APPLICATION is inactive
METH CL_UMM_MC_BSP_APPLICATION=====CM006 is inactive
METH CL_UMM_MC_BSP_APPLICATION=====CM006 is inactive
METH CL_UMM_MC_BSP_APPLICATION=====CM00F is inactive
METH CL_UMM_MC_BSP_APPLICATION=====CM010 is inactive
METH CL_UMM_MC_BSP_APPLICATION=====CM01J is inactive
METH CL_UMM_MC_BSP_APPLICATION=====CM01J is inactive
METH CL_UMM_MC_BSP_APPLICATION=====CM01Y is inactive

Si no se libera el 769 no pasa el el 768

cual es tu opinion??
muchas gracias por tu apoyo.