R E G I S T R O D E A C C E S O A D AT O S D E N I V E L A LT O

El Reglamento de medidas de seguridad de los ficheros automatizados que contengan datos de carácter personal, aprobado por Real Decreto 994/1999 de 11 de junio y publicado en el BOE de 25 de junio de 1999 exige en su CAPITULO IV (Medidades de nivel alto), Articulo 24 el registro de accesos a datos clasificados como de nivel alto. El modulo de RRHH de R/3 para España almacena una serie de datos de nivel alto como pueden ser el grado de minusvalía del empleado, por lo que es necesario implantar un mecanismo de registro de acceso a estos datos que cumpla con el artículo 24 del citado reglamento: •

"De cada acceso se guardarán, como mínimo, la identificación del usuario, la fecha y hora en que se realizó el acceso, el fichero accedido, el tipo de acceso y si ha sido autorizado o denegado.

•

En el caso de que el acceso haya sido autorizado, será preciso guardar la información que permita identificar el registro accedido.

•

Los mecanismos que permiten el registro de los datos detallados en los párrafos anteriores estarán bajo el control directo del responsable de seguridad competente sin que se deba permitir, en ningún caso, la desactivación de los mismos.

• •

El período mínimo de conservación de los datos registrados será de dos años. El responsable de seguridad competente se encargará de revisar periódicamente la información de control registrada y elaborará un informe de las revisiones realizadas y los problemas detectados al menos una vez al mes."

El plazo de implantación de las medidas es de 2 años a partir de la entrada en vigor del citado reglamento para los datos de nivel alto, es decir que este plazo caduca el 25 de junio de 2001. SAP entrega la funcionalidad de acceso a datos protegidos a través del HR SP ES18.1. Se ruega consultar la nota 115907 en la que se indica la fecha de disponibilidad de este HR SP en concreto. Actualmente SAP considera que los siguientes datos almacenados en el sistema tienen carácter de nivel alto, aunque siempre exista cierto márgen de interpretación. En la descripción de la solución se indica como quitar/agregar campos al sistema de registro mediante parametrización:

www.cuviv.com

Datos de nivel alto almacenados en infotipos P0004-SBPRO: Grado de minusvalía del empleado en infotipo 0004 P0057-UFUNC: Sindicato al que está afiliado el empleado P0062-FAMNU: Grado de minusvalía del empleado en infotipo 0062 Q0021-MINSV: Grado de minusvalía de un familiar del empleado en infotipo 0021 Q0061-IDSEG: Clave de contrato en infotipo 0061. Este dato porta indirectamente información acerca de la minusvalía de un empleado si tiene asignada una clave de contrato específica para minusválidos Q0062-NDM33: Grado de minusvalía de un familiar en infotipo 0062, visible al enseñar la pantalla con el desglose de familiares relevantes para IRPF. Q0062-NDM65: idem Q0062-NDM33. Q0480-IDSEG: Clave de contrato en infotipo 0016 a partir de la versión 4.5 por la misma razón enunciada para Q0061-IDSEG P2001-AWART: Tipo de absentismo del infotipo 2001, se pueden deducir datos relacionados con la salud del empleado y datos sobre el perfil de absentismos laborales del empleado. Atención: Para registrar accesos al IT 2001 es necesario implementar código de cliente en la user exit de cliente de infotipos que se indica en el apartado "Descripción de la solución. P0008-LGART: En el infotipo 0008 podría haber CC-nóminas de las cuales se podrían deducir datos de nivel alto. Para registrir los accesos a estas CC-nóminas también es necesario implentar el registro en la user exit de cliente de infotipos como se describe en el apartado "Descripción de la solución". P0015-LGART: ver la descripción de P0008-LGART P0014-LGART: ver la descripción de P0008-LGART

Datos de nivel alto almacenados en ficheros TemSe Únicamente se registra un acceso si se listan explícitamente los registros pulsando el botón correspondiende o haciendo doble click en la lista inicial no estructurada. El sistema borra el contenido de los datos de nivel alto en la lista inicial para evitar tener que hacer registros por el simple hecho de visualizar esta lista, de la que generalmente no se extrae información específica para este tipo de campos. Se advierte que la visualización masiva de registros TemSe como los registros de tipo 2 del modelo 190 causa una registro masivo de accesos, en el caso del modelo 190, 3 entradas por cada registro.

www.cuviv.com

PES1909902-DISCA: Visualización de ficheros TemSe con datos para el modelo 190, grado de minusvalía del empleado. Formatos regiones 51, 52 y 99 PES1909902-DIS_65: idem PES1900002-DISCA, para el grado de minusvalía de un descendiente del empleado . PES1909902-DIS_100: idem PES1900002-DIS_65 PES1909902-AS_DIS65: idem PES1909902 pero para el grado de minusvalía de un ascendiente del empleado. PES1909902-AS_DIS100: idem PES1909902-AS_DIS65 PES1900002-DISCA: Visualización de ficheros TemSe con datos para el modelo 190, grado de minusvalía del empleado. Formatos de regiones 01, 20, 31 y 48. PES1900002-DIS_65: idem PES1900002-DISCA pero para el grado de minusvalía de un descendiente del empleado. Formatos de regiones 01, 20, 31 y 48. PES1900002-DIS_100: idem PES1900002-DIS_65. PESREDDAT-CONTRATO: Clave de contrato de la Seguridad Social en fichero. FAN o fichero AFI. Este campo tiene la siguiente particularidad: Los registros DAT que portan la información del contrato por empleado se listan separadamente de los registros TRA que identifican al empleado, por lo que es imposible relacionar el contrato visualizado con el empleado a no ser que el fichero contenga a un único o pocos empleados. Actualmente se registra que un usuario ha visualizado la lista de registros DAT sin especificar a qué trabajador corresponden.

Datos almacenados en el cluster de resultados nómina La visualización de datos del cluster de resultados de nómina también puede considerarse un acceso a datos de nivel alto en el caso de la clave de contrato almacenada en la tabla SV o del grado de minusvalía del empleado almacenado en la tabla ST. La versión entregada en el HR SP ES18.1 todavía no cubre el registro de estos datos, pero implementando la correción nº 12 de la nota 0375597 se puede obtener esta funcionalidad, salvo para la versión 4.6C que se entregará en el HR SP ES19. Los campos que se consideran como de nivel alto en la parametrización estándar son los siguientes: PC225-PESOC: Clave de contrato para la Seguridad Social grabado en la tabla SV PC226-FAMNU: Grado de minusvalía del empleado grabado en la tabla ST PC207-LGART: En caso de visualizar la tabla RT se podría deducir información referente al pago de cuotas sindicales. En el estándar se incluye una entrada para PC207-LGART en la tabla T5EL4 que desencadena un registro de acceso de este tipo de datos cada vez que se visualiza la tabla RT.

www.cuviv.com

ATENCION: A partir del HR SP ES21 también se registran las lecturas a resultados de nómina realizadas por los programas RPCEDTE0 (recibo de nómina), RPCKTOE0 y RPCLJNE0. Debido a que a la mayoría de los clientes no les interesa registrar accesos a resultados de nómina por el elevado número de registros que esto implica la entrada en la tabla T5EL4 correspondiente al campo PC207LGART será ELIMINADA. Si se desea registrar este tipo de accesos se deberá restituir esta entrada utilizando la vista V_T5EL4.

Acceso a datos de nivel alto via transacciones SE16 o SM30 En caso de que un usuario tenga autorización para utilizar la transación se16 en un sistema productivo, podrá visualizar el contenido de cualquier tabla de base de datos, en particular las tablas PAxxxx que contienen los datos relativos a infotipos. No está previsto entregar un sistema de registro de acceso de datos a través de la transacción SE16 ya que ningún usuario debería tener autorización para utilizar esta transacción en un sistema productivo. Por lo tanto es necesario revisar los perfiles de autorización para descartar la posibilidad de que se acceda a datos de nivel alto via SE16. No existe ninguna vista estándar con la que se puedan visualizar datos de nivel alto a través de la transacción SM30. Se recomienda revisar el sistema para descartar que existan vistas de cliente que permitan tal acceso y bloquearlas o borrarlas en caso de que existan. La solución disponible hasta el HR SP ES22 no permite el registro de intentos de acceso a registros de nivel alto. A partir del HR SP ES22 se pondrá a disposición una nueva user exit en el sistema de autorizaciones de infotipos que permitirá realizar este tipo de registros.

Novedades 1. 16/10/2002: Se ha creado el apartado 12 en la sección "PASOS A SEGUIR EN LA IMPLANTACION DE LA NUEVA FUNCIONALIDAD" en la que se describe como archivar los registros de acceso evitándo un aumento de volumen descontrolado del contenido de la table T5EL1. 2. 16/10/2002: Cambios introducidos con el HR SP ES22 a) A partir del HR SP ES22 el programa de gestión y visualización de registros de acceso (RPULORE0) ofrece la posibilidad de seleccionar registros de acceso por Sociedad a la que pertenece el empleado cuyos datos fueron accedidos. Es uso de esta opción puede bajar sensiblemente el rendimiento de la visualización de registros porque el proceso de determinación de la sociedad a partir del NIF del empleado es relativamente costoso. b) Adicionalmente existe la posibilidad de borrar registros redundantes, entendiéndose como redundantes un registro idéntico a una anterior que se ha registrado no más de una cantidad fija de segundos luego del primero. c) Se ha creado el apartado 11 en la sección 'PASOS A SEGUIR PARA IMPLEMENTAR LA NUEVA FUNCIONALIDAD" en el cual se explican los pasos a seguir para registrar INTENTOS www.cuviv.com

de acceso rechazados por el control de autorizaciones en las transacciones PAxx y para registrar accesos a infotipos no cubiertos por el mecanísmo de registro estándar (p.e. 0008, 0014, 2001) d) Se ha creado el apartado 13 en la sección 'PASOS A SEGUIR PARA IMPLEMENTAR LA NUEVA FUNCIONALIDAD" en el cual se explican la posibilidad de establecer un control de autorizaciones específico para la ejecución del programa de gestión de registros RPULORE0.

3. 08/2003: Cambios introducidos con el HR SP ES23 a) Se amplia la clave de la tabla T5EL1 incorporando el campo MODNO (Sistema R/3, índice modos externos) el cual almacena el número del modo del sistema que el usuario esta utilizando reduciendo considerablemente las posibilidades de bloqueos y tiempos de espera por recursos compartidos de la T5EL3 y T5EL1. Este campo se puede visualizar a través del listado arrojado por el programa RPULORE0, en su tercera columna.

PASOS A SEGUIR PARA IMPLANTAR LA NUEVA FUNCIONALIDAD 1. Cargue el HR SP ES18.1. Con la carga de este HR SP el sistema de registro de accesos está automáticamente activo salvo en el infotipo 0004 (Minusvalías) que requiere un proceso de parametrización adicional que se describe más adelante. 2. Realice un acceso al infotipo 0062 en el cual no se ha ocultado el campo de minusvalía del empleado (P0061-FAMNU) a través de la tabla t588M. 3. Ejecute el programa RPULORE0, opción visualizar y con la casilla test marcada. Verifique que se liste una entrada para su usuario, la fecha y la hora en la que se ha realizado el acceso y para el fichero lógico 0001 = Grado de minusvalía del empleado. 4. Oculte el campo P0061-FAMNU a través de la tabla T588M, acceda al infotipo 0062 y verifique que no se haya creado un registro de acceso a este camo lanzando el programa RPULORE0. Repita este procedimiento para los infotipos 0016 (a partir de 4.5B), 0021 (dynpro 2004), 0057 (dynpro 2004) y 0061. 5. Active la característica P0004 y copie la entrada para la clave variable 04 de la tabla T588M que se entrega en el mandante 000, para que se utilice el nuevo dynpro 2004 para el infotipo 0004. 6. Genere un fichero para el modelo 190 (programa RPC190E0) y visualice los registros de tipo 2 de este fichero. Compruebe con el programa RPULORE0 que se ha creado un registro para el fichero lógico 0001 = grado de minusvalía del empleado y 0002 = grado de minusvalía de un familiar para cada registro de tipo 2 visualizado. 7. Si ha desarrollado ABAP Queries que incluyan alguno de los campos de nivel alto, será necesario modificar el área funcional agregando el siguiente código ABAP en el evento 'Tratamiento de frases' para el infotipo Pnnnn y campo xxxx:

www.cuviv.com

loop at Pnnnn where begda le pn-endda and endda ge pn-begda. CALL FUNCTION 'HR_ES_PRODA_REG_DAT_METO_STRUC' EXPORTING p_struc_field = 'Pnnnn-xxxx' p_pernr

= pnnnn-pernr

EXCEPTIONS ERROR

=1

OTHERS

= 2.

IF SY-SUBRC 0. ENDIF. endloop. * commit work. "[Opcional] El registro únicamente se producirá si la combinación campo/tabla Pnnnn/xxxx está mantenida en la tabla T5EL4 (vista V_T5EL4) con su correspondiente asignación a un fichero lógico. En caso de tener que registrar el acceso a un campo que no esté mantenido en esta tabla, se puede mantener la combinación de tabla/campo siempre y cuando el nombre de la tabla comience con una Z. En caso contrario se recomienda utilizar el siguiente código ABAP en lugar de realizar una entrada en la tabla T5EL4 que viole el rango de entradas de SAP: Versión 3.1I loop at Pnnnn where begda le pn/endda and endda ge pn/begda. CALL FUNCTION 'HR_ES_PRODA_REG_DAT_METO_DIREC' EXPORTING p_ficid = 'mmmm' p_pernr

= pnnnn-pernr

EXCEPTIONS ERROR

=1

OTHERS

= 2.

IF SY-SUBRC 0.

www.cuviv.com

ENDIF. endloop. * commit work. "[Opcional] Versiones superiores a 3.1I loop at Pnnnn where begda le pn-endda and endda ge pn-begda. CALL FUNCTION 'HR_ES_PRODA_REG_DAT_METO_DIREC' EXPORTING p_ficid = 'mmmm' p_pernr

= pnnnn-pernr

EXCEPTIONS ERROR

=1

OTHERS

= 2.

IF SY-SUBRC 0. ENDIF. endloop. * commit work. "[Opcional] donde mmmm es el identificador de fichero lógico según tabla T5EL2

(Vista V_T5EL2) que proporciona SAP. En caso de no encontrar un identificador apropiado para el dato cuyo acceso se quiera registrar, se pueden crear identificadores de cliente con la condición de que comiencen con 9. En caso de utilizar un área funcional que contenga más de un infotipo con datos de nivel alto con queries que accedan sólo a un subconjunto de estos infotipos, se produce un error de sintaxis debido al uso de la tabla Pnnnn, siendo Pnnnn el infotipo que no se utiliza en esta query en particular. En estos casos es necesario utilizar un código ABAP más complejo: ... data: begin of tab_infotypes occurs 0, name(7),

www.cuviv.com

FICID LIKE T5EL2-FICID, end of tab_infotypes. field-symbols: type table, , , , . refresh tab_infotypes. TAB_INFOTYPES-NAME = 'PNNNN[]'. "PNNNN es p.e. P0061 TAB_INFOTYPES-FICID = 'aaaa'.

"aaaa = identificador según T5EL2 append tab_infotypes.

TAB_INFOTYPES-NAME = 'PMMMM[]'. "PMMMM[ es p.e. P0062 TAB_INFOTYPES-FICID = 'bbbb'. "bbbb = identificador según T5EL2 append tab_infotypes. .... Repetir para cada uno de los infotipos que puedan existir loop at tab_infotypes. assign (tab_infotypes-name) to . check sy-subrc is initial. CLEAR TAB_INFOTYPES-NAME+5(2). assign (tab_infotypes-name) to . check sy-subrc is initial. loop at into . assign component 'BEGDA' of structure to . if sy-subrc ne 0. exit. endif. assign component 'ENDDA' of structure to . if sy-subrc ne 0. exit. endif. check le pn-endda and ge pn-begda. assign component 'PERNR' of structure to . if sy-subrc ne 0. www.cuviv.com

exit. endif. call function 'HR_ES_PRODA_REG_DAT_METO_DIREC' exporting P_FICID = TAB_INFOTYPES-FICID p_pernr = exceptions error = 1 others = 2. if sy-subrc 0. endif. endloop. * commit work. "[Opcional]

Para aquellos queries que puedan necesitar un tiempo considerable de ejecución se recomienda descomentar la sentencia commit work para hacer posible la liberación de recursos compartidos, específicamente de la tabla T5EL3 que podría originar un error de time out al tener un proceso que esperar hasta que el recurso compartido sea liberado por el otro proceso. Esta sentencia es altamente prohibitiva para ejecuciones de nómina ya que elimina la LUW que se este procesando y puede acarrear consecuencias de perdida de datos al dejar de ser posible un Rollback. El uso o no de esta sentencia queda a juicio del programador de la query. En cualquier caso debe quedar claro que es una sentencia muy seria si se esta realizando algún tipo de actualización en la BD ya que como ya se mencionó rompe la LUW (Logical Unit Work) y elimina cualquier mecanismo de Rollback. 8. Si ha desarrollado informes en ABAP accediendo a datos de nivel alto, debe modificar su código para registrar la visualización de estos datos valiéndose de los módulos de funciones anteriormente mencionados. 9. Si ha desarrollado infotipos de cliente con datos de nivel alto, también será necesario adaptar su código tomando como ejemplo el módulo PBO reg_proda del infotipo 0061 (include MP006120). 10. Desactivación del registro de acceso: Utilice la vista V_T5EL4 para agregar/borrar entradas que causen el registro de determinados campos. Si desea desactivar el registro de visualización de segmentos DAT, basta con borrar la entrada para la tabla PESREDDAT y campo CONTRATO. Recuerde que únicamente se puede gestionar el www.cuviv.com

registro de aquellos datos que son grabados mediante el módulo de funciones HR_ES_PRODA_REG_DAT_METO_STRUC, los registros que se realizan indicando directamente el identificador del fichero lógico (módulo HR_ES_PRODA_REG_DAT_METO_DIREC) no son desactivables mediante parametrización. El estándar no utiliza este módulo, por tanto todos los registros pueden ser desactivados. Dado que las entradas se encuentran en rango de SAP se debe verificar el estado de la tabla T5EL4 luego de cada HR SP en caso de haberla modificado. Las entradas en la tabla T5EL4 únicamente tendrán efecto en los infotipos/dynpros preparados a tal efecto, que actualmente son los siguientes: infotipo

dynpro

0004

2004, 3004 (a partir del ES19)

0021

2004

0057

2004, 3004 (a partir del ES19)

0061

2000, 3004 (a partir del ES19)

0062

2000

11. Registro de acceso a datos de nivel alto en infotipos estándar mediante user exit central de autorizaciones en las transacciones PAxx. En los siguientes HR SP se ha entregado una nueva user exit que se llama durante el control de autorizaciones que realizan las transacciones de gestión de infotipos PAxx 3.1I SAPKE31B0 4.0B SAPKE40A2 4.5B SAPKE4586 4.6B SAPKE4668 4.6C SAPKE4659 4.70 SAPKE4704 Esta user exit se puede utilizar para registrar los INTENTOS de acceso rechazados por el sistema por falta de autorización del usuario para visualizar o modificar un registro de infotipo y para registrar accesos a infotipos que no están cubiertos en el estándar como p.e. IT 0014, 0008 y 2001. Una particularidad de los registros realizados a través de esta user exit es que se pueden producir múltiples registros para un único acceso del infotipo ya que el control de autorizaciones se llama varias veces durante este proceso. Para evitar estos registros en principio redundantes, el programa de gestión de registros de acceso (RPULORE0) ofrece desde el HR SP ES22 la posibilidad de eliminar registros idénticos cuyo el tiempo de registro (campos AS4DATE, AS4TIME) no supere un límite expresados en segundos a través de la pantalla de selección del programa RPULORE0.

www.cuviv.com

Una vez cargado el HR SP ES22 es posible implementar el registro de intentos de acceso realizando los siguientes pasos: Versiones hasta 4.6B: a) Utilice la transacción CMOD para crear un projecto para user exits de infotipos si todavía no creado un proyecto que contenga la extensión PBAS0004 y asígnele esta extensión. b) Navegue a la componente exit_sapfp50p_001 y luego al include zxpadu04 que deberá ser creado en caso de no existir e introduzca el siguiente código: data: l_ioper like psyst-ioper, l_infty_name(5) type c, wa_i0008 like p0008, i0008 like p0008 occurs 0 with header line, lgaxx(5) type c value 'LGAxx', xx(2) type n. field-symbols: like i0008-lga01. if rcode is initial. "Si el usuario no tiene autorización de acceso case level. when 'W'. "Write L_IOPER = 'MOD'. when 'R'. "Read L_IOPER = 'DIS'. when others. L_IOPER = 'DIS'. endcase. CONCATENATE 'P' INFTY INTO L_INFTY_NAME. CALL FUNCTION 'HR_ES_PRODA_REG_DAT_METO_STRUC' EXPORTING P_STRUC_NAME = L_INFTY_NAME P_PERNR

= PERNR

www.cuviv.com

P_IOPER

= L_IOPER

P_AUTOR

= 'N'

EXCEPTIONS ERROR

=1

OTHERS

= 2.

endif. Versiones a partir de 4.6C: a) Utilice la transacción se19 para crear una implementación de la BAdI HRPAD00AUTH_RECORD. b) Introduzca el código que se indica a continuación para el método RECORD_AUTH_RESULTS ... data: l_ioper type psyst-ioper, l_infty_name(5) type c, wa_i0008 type p0008, i0008 type table of p0008, lgaxx(5) type c value 'LGAxx', xx(2) type n. field-symbols: type p0008-lga01. case level. when 'W'. "Write L_IOPER = 'MOD'. when 'R'. "Read L_IOPER = 'DIS'. when others. L_IOPER = 'DIS'. endcase. if rcode is initial. "Si el usuario no tiene autorización de acceso CONCATENATE 'P' INFTY INTO L_INFTY_NAME. www.cuviv.com

CALL FUNCTION 'HR_ES_PRODA_REG_DAT_METO_STRUC' EXPORTING P_STRUC_NAME = L_INFTY_NAME P_PERNR

= PERNR

P_IOPER

= L_IOPER

P_AUTOR

= 'N'

EXCEPTIONS ERROR

=1

OTHERS

= 2.

endif. Adicionalmente deberá indicar a través de la tabla T5EL4 los infotipos para los cuales se desea registrar los intentos de acceso realizando entradas de la siguiente estructura: |STRUC| FIELD|ENDDA

|BEGDA

|Pnnnn| * |31.12.9999|01.01.1900|

|FIPER|FIPID|FICID| |

|xxxx |

donde nnnn es el infotipo para el cual se debe registrar el intento de acceso y xxxx es la identificación del fichero lógico según T5EL2 Estas entradas no se entregan en el estándar pero en caso de implementar el registro de intentos de acceso se recomienda realizar las siguientes entradas utilizando la transacción sm30 y la vista V_T5EL4. |P0004| * |31.12.9999|01.01.1900| | |0001| |P0021| * |31.12.9999|01.01.1900| | |0002| |P0061| * |31.12.9999|01.01.1900| | |0004| |P0062| * |31.12.9999|01.01.1900| | |0001| |P0057| * |31.12.9999|01.01.1900| | |0003| Los infotipos 0008, 0014, 2001 no han sido modificados para registrar accesos a datos de alto nivel, sin embargo es posible registrar estos accesos mediante la implementación del siguiente código en la nueva user exit o BAdI de control de acceso. Incluya el siguiente codigo en el include zxpadu04 (versiones hasta 46B) o en la implementación del BAdI HRPAD00AUTH_RECORD (versiones a partir de 4.6C). Es condición necesaria haber incluido el código de la sección anterior destinado a registrar los intentos de acceso.

www.cuviv.com

if rcode = 'X'. "Si el usuario tiene permiso para acceder al IT case infty. when '0008'. CALL FUNCTION 'HR_READ_INFOTYPE' EXPORTING PERNR INFTY

= PERNR = INFTY

BEGDA

= BEGDA

ENDDA

= ENDDA

TABLES INFTY_TAB

= I0008

EXCEPTIONS INFTY_NOT_FOUND = 1 OTHERS

= 2.

loop at i0008 into wa_i0008. clear xx. do. add 1 to xx. lgaxx+3(2) = xx. ASSIGN COMPONENT LGAXX OF STRUCTURE wa_i0008 TO . if sy-subrc ne 0. exit. endif. IF = 'NNNN'. "'NNNN' es la cc-nómina de nivel alto CALL FUNCTION 'HR_ES_PRODA_REG_DAT_METO_DIREC' EXPORTING P_PERNR

= PERNR www.cuviv.com

P_FICID

= 'xxxx'

"xxxx fichero según T5El4

EXCEPTIONS ERROR

=1

OTHERS

= 2.

IF SY-SUBRC 0. ENDIF. ENDIF. ENDDO. endloop. when '0014'. if subty = 'NNNN'. " 'NNNN' es la CC-nómina CALL FUNCTION 'HR_ES_PRODA_REG_DAT_METO_DIREC' EXPORTING P_PERNR P_FICID P_IOPER

= pernr = 'xxxx' " xxxx fichero según T5El4 = l_ioper

EXCEPTIONS ERROR

=1

OTHERS

= 2.

IF SY-SUBRC 0. ENDIF. endif. when '0015'. if subty = 'NNNN'. " 'NNNN' es la CC-Nómina de nivel alto CALL FUNCTION 'HR_ES_PRODA_REG_DAT_METO_DIREC' EXPORTING P_PERNR

= pernr www.cuviv.com

P_FICID P_IOPER

= 'xxxx' " xxxx fichero según T5El4 = l_ioper

EXCEPTIONS ERROR

=1

OTHERS

= 2.

IF SY-SUBRC 0. ENDIF. endif. when '2001'. if subty = 'NNNN'. " 'NNNN' es el subtypo de nivel alto CALL FUNCTION 'HR_ES_PRODA_REG_DAT_METO_DIREC' EXPORTING P_PERNR P_FICID P_IOPER

= pernr = 'xxxx' " xxxx fichero según T5El4 = L_ioper

EXCEPTIONS ERROR

=1

OTHERS

= 2.

IF SY-SUBRC 0. ENDIF. endif. endcase. endif. 12. Archivo de registros de accesos de datos de nivel alto El volumen de datos almacenado en la tabla T5EL1 es muy importante y puede afectar al rendimiento de los procesos que registran o gestionan registros de accesos. El programa de gestión de registros ofrece la posibilidad de borrar registros de la base de datos sin embargo la ley exige almacenar estos datos durante dos años lo cual puede implicar un volúmen crítico para ciertas

www.cuviv.com

instalaciones. En estos casos se recomienda listar los registros existentes hasta el momento y archivar la lista generada. Esto se puede realizar escogiendo la opción de "Archivar" en el díalog de impresión de la lista (campo ARTXT). Una vez archivada la lista se pueden borrar los registros archivados mediante la opción que ofrece el programa RPULORE0. 13. Objeto de autorización para el programa RPULORE0 A partir del HR SP ES22 el programa de gestión de registros de acceso controla si el usuario posee la autorización para el objeto S_APPL_LOG para los campos ALG_OBJECT = HRES, ALG_SUBOBJ = PRODA y ACTVT = 03 (visualización) o 06 (modificación de registros).

www.cuviv.com

Descripción técnica de la Solución Se ha creado un juego de tablas de base de datos para registrar los accesos a datos de alta protección y un programa para evaluar estos registros. Cada acceso se graba en la tabla T5EL1, que tiene los siguientes campos: MANDT (clave) : Mandante AS4USER(clave) : Usuario de R/3 NUREG (clave) : Número de acceso registrado FICID : Identificador del fichero lógico accedido AS4DATE : Fecha del acceso AS4TIME : Hora del acceso TIACC : Tipo de acceso (visualización o copia 'V', modificación 'M', inserción 'C', borrado 'B') TIREC : Tipo de registro de de acceso (intento rechazado 'N', o acceso exitoso 'A'), este campo se incluye con el HR ES22. En la tabla T5EL2 se encuentran los identificadores de ficheros lógicos con su correspondiente texto explicativo, p.ej. identificador '0001' 'Grado de minusvalía del empleado'. Los campos de esta tabla son: MANDT (clave) : Mandante FICID (clave) : Identificador de fichero lógico TEXTO : Texto descriptivo del identificador Igualmente se ha creado la tabla T5EL3 que contiene el número del último acceso registrado para un usuario, con el fin de poder obtener una actualización rápida de la tabla T5EL1 sin tener que determinar el proximo número de registro mediante una lectura costosa de la misma. La tabla T5EL3 debe su existencia exclusivamente a razones técnicas y no contiene datos directamente relacionados con la grabación de registros de datos de alta protección. Por último se ha creado la tabla T5EL4 que permite indicar los campos de estructuras o tablas del diccionario que se consideran datos de alta protección y que desencadenarán un registro en la tabla T5EL1 en caso de ser accedidos. El registro del acceso únicamente se producirá en aquellos programas (modulpools de infotipos, visualizador de ficheros TemSe, programas de evaluación) que han sido especialmente modificados a tal efecto. La estructura de la tabla T5EL4 es la siguiente: MANDT (clave) : Mandante STRUC (clave) : Nombre de la estructura, p.ej. P0061 FIELD (clave) : Nombre del campo, p.ej. FAMNU

www.cuviv.com

ENDDA (clave) : Fecha final de validez BEGDA : Fecha inicial de validez FIPER : Nombre del campo de la estructura indicada en el campo STRUCT del cual se puede extraer el número de personal del empleado observado, p.ej. PERN (de la estr. P0061) FIPID : Análogo al campo FIPER pero para el número de documento FICID : Identificador de fichero lógico Report RPULORE0 Este report permite la evaluación de los registros generados por usuario y en un intervalo de tiempo dado. Básicamente se listan los datos almacenados en la tabla T5EL1 combinados con el texto explicativo para cada identificador de fichero lógico indicado en la tabla T5EL2. Adicionalmente este programa ofrece borrar de la tabla T5EL1 datos para los cuales ha caducado la obligación de conservarlos (actualmente después de dos años). En caso de querer borrar registros con menos de 2 años de antigüedad se recomienda seguir las instrucciones del apartado 12 de la sección anterior. Este programa debe ser utilizado en caso de problemas de sincronización entras las tablas T5EL1 y T5EL3 marcando la opción de reorganización. Si no hay necesidad de reorganizar estas tablas, el programa lo indicará con el correspondiente mensaje por usuario. A partir del HR SP ES22 el programa de gestión y visualización de registros de acceso (RPULORE0) ofrece la posibilidad de seleccionar registros de acceso por Sociedad a la que pertenece el empleado cuyos datos fueron accedidos. Es uso de esta opción puede bajar sensiblemente el rendimiento de la visualización de registros porque el proceso de determinación de la sociedad a partir del NIF del empleado es relativamente costoso. Como último existe la posibilidad de borrar registros redundantes, entendiéndose como redundante a un registro idéntico a una anterior que se ha registrado no más tarde que una cantidad fija de segundos luego del primero. Si desea realizar esta compresión de registros seleccione la opción correspondiente e indique el tamaño en segundos del intervalo en que un registro se considera redundante si ha sido registrado dentro de este intervalo luego de que haya ocurrido el último registro de una acceso de este tipo.

www.cuviv.com