Administracion de SAP R3

GESTIÓN DE SISTEMAS DE
INFORMACIÓN
Universidad de Deusto - Facultad de Ingenierı́a
Antonio Toledo Carnicero

Pablo Pérez Pérez

c Octubre de 2006

c
copyleft
Copyright (c) 2006 Pablo Pérez Pérez y Antonio Toledo Carnicero.
This work is licensed under the Creative Commons Attribution-
NonCommercial-ShareAlike License. To view a copy of this license, visit
http://creativecommons.org/licenses/by-nc-sa/2.0/ or send a letter to Creative
Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.
Copyright (c) 2006 Pablo Pérez Pérez y Antonio Toledo Carnicero.

Esta obra esta licenciada bajos los términos de la licencia Atribución-No Comercial-
Comparte Igual de Creative Commons. Para ver una copia de esta licencia visite
http://creativecommons.org/licenses/by-nc-sa/2.0/es/deed.es o escriba una carta a
Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.
Prefacio
En los últimos 15 años la implantación de sistemas de información tipo

ERP en las grandes empresas ha sido masiva. SAP R/3 es el máximo
exponente de ello al ser el lı́der mundial en número de instalaciones. La
gran amplitud y complejidad de un sistema R/3 exige la especialización del
personal de la empresa en cada uno de sus aspectos como pueden ser, la
funcionalidad, la parametrización, la programación o la administración del
sistema. Es en este último aspecto, la administración del sistema, en el que
se centra la presente obra.
Audencia
Este libro está especı́ficamente escrito para los alumnos de la asignatura
Gestión de Sistemas de Información dentro del quinto curso del programa de
estudios de Ingenierı́a en Informática de ESIDE en la Universidad de Deusto.
Son a ellos, principalmente, a quién va dirigido el libro.
No obstante, a lo largo de nuestra experiencia laboral hemos tenido
la oportunidad de mostrar varios capı́tulos del libro a diversas personas
que trabajan con SAP R/3. A algunos programadores y técnicos de
atención a usuarios les ha resultado útil para comprender determinados
aspectos globales de SAP que no tratan habitualmente en su trabajo diario
como la arquitectura del sistema, el sistema de transporte o la seguridad.
También puede servir como introducción a los que quieran iniciarse en la
administración de sistemas R/3.
Sobre los autores

Pablo Pérez completó sus estudios de licenciatura en informática en
la Universidad de Deusto en el año 1995. Comenzó su experiencia con
SAP R/3 en 1997, en la empresa de automoción Grupo Antolı́n, como
programador de ABAP/4 y administrador de sistemas. Posteriormente ha
3
4
trabajado como analista y consultor técnico de SAP para varias empresas y

formó parte durante 5 años del equipo de desarrollo de Finanzas y Control
de Gestión en la eléctrica Iberdrola. En la actualidad es el responsable de los
sistemas informáticos de la empresa reprográfica Cianoplan y ocasionalmente
trabaja como analista freelance de ABAP/4. Su experiencia docente incluye
varias ediciones del Master de Consultorı́a e Implantación de Sistemas de
Información y la Diplomatura de Especialización en Gestión de Sistemas y
Redes, ambos tı́tulos de postgrado impartidos por la Universidad de Deusto.
Antonio Toledo es licenciado en Ciencias Fı́sicas por la Universidad
del Paı́s Vasco desde el año 1995. Su experiencia laboral se inició en Grupo
Antolı́n, una multinacional del sector de la automoción, como programador
ABAP/4 y administrador de Sistemas SAP. Posteriormente ha formado
parte de varias empresas del sector de las TI como Ceinsa o IT Deusto.
Actualmente es jefe de proyectos del área de sistemas en la empresa AVN y
ha formado parte de los equipos de administración y soporte SAP de empresas
como Iberdrola o Eroski. Ha colaborado en varias ocasiones como profesor
en el Master de Consultorı́a e Implantación de Sistemas de Información y
la Diplomatura de Especialización en Gestión de Sistemas y Redes de la
Universidad de Deusto.
Índice general
Copyleft 2
1. Introducción a SAP R/3 13

1.1. Software estándar vs. software a medida . . . . . . . . . . . . 13
1.2. Visión general de SAP R/3 . . . . . . . . . . . . . . . . . . . 14
1.2.1. Caracterı́sticas principales . . . . . . . . . . . . . . . . 14
1.2.2. Módulos . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.2.3. Entorno de desarrollo . . . . . . . . . . . . . . . . . . . 19
2. Introducción al sapgui 21
2.1. Pantalla de logon a SAP R/3 . . . . . . . . . . . . . . . . . . 21
2.2. Concepto de mandante . . . . . . . . . . . . . . . . . . . . . . 21
2.3. La barra de tı́tulo . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.4. El menú desplegable . . . . . . . . . . . . . . . . . . . . . . . 24
2.5. La barra estándar de herramientas . . . . . . . . . . . . . . . 25
2.6. La barra de aplicaciones . . . . . . . . . . . . . . . . . . . . . 27
2.7. La pantalla principal . . . . . . . . . . . . . . . . . . . . . . . 27
2.8. La barra de estado . . . . . . . . . . . . . . . . . . . . . . . . 28
2.9. Ventana de diálogo . . . . . . . . . . . . . . . . . . . . . . . . 29
2.10. Ayudas de búsqueda . . . . . . . . . . . . . . . . . . . . . . . 29
2.11. Modos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.12. Concepto de transacción . . . . . . . . . . . . . . . . . . . . . 32
2.13. Opciones técnicas . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.14. La pantalla status . . . . . . . . . . . . . . . . . . . . . . . . . 34
3. Arquitectura de un sistema R/3 37

3.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2. Servicios de base de datos . . . . . . . . . . . . . . . . . . . . 39
3.3. Servicios de aplicación . . . . . . . . . . . . . . . . . . . . . . 40
3.4. Servicios de presentación . . . . . . . . . . . . . . . . . . . . . 43
5
6 ÍNDICE GENERAL
4. Escenarios de configuración 45
4.1. Consideraciones generales sobre los sistemas R/3 . . . . . . . . 45
4.2. Descripción y funciones de cada sistema . . . . . . . . . . . . 46
4.2.1. Sistema de desarrollo . . . . . . . . . . . . . . . . . . . 46
4.2.2. Sistema de integración . . . . . . . . . . . . . . . . . . 46
4.2.3. Sistema de producción . . . . . . . . . . . . . . . . . . 47
4.3. Mandantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.3.1. Mandantes estándar . . . . . . . . . . . . . . . . . . . 47
4.3.2. Mandantes propios . . . . . . . . . . . . . . . . . . . . 48
4.4. Comparación de escenarios . . . . . . . . . . . . . . . . . . . . 50
4.4.1. Configuración con un sólo sistema (Producción) . . . . 50
4.4.2. Configuración con dos sistemas (Desarrollo y Producción) 51
4.4.3. Configuración con tres sistemas (Desarrollo, Inte-
gración y Producción) . . . . . . . . . . . . . . . . . . 52
5. Monitorización de procesos y usuarios 55

5.1. Monitorización de procesos activos . . . . . . . . . . . . . . . 55
5.2. Monitorización usuarios conectados . . . . . . . . . . . . . . . 61
6. Procesamiento en fondo 65
6.1. Conceptos de procesamiento en fondo . . . . . . . . . . . . . . 65
6.2. Definición de jobs . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.2.1. Información general . . . . . . . . . . . . . . . . . . . . 66
6.2.2. Hora de inicio o evento . . . . . . . . . . . . . . . . . . 67
6.2.3. Pasos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.3. Análisis de jobs . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.3.1. Estados de un job . . . . . . . . . . . . . . . . . . . . . 69
6.3.2. Operaciones sobre jobs . . . . . . . . . . . . . . . . . . 70
7. Servicios de actualización 73
7.1. Actualización sı́ncrona y ası́ncrona . . . . . . . . . . . . . . . 73
7.2. Procesos de actualización V1 y V2 . . . . . . . . . . . . . . . 75
7.3. Monitorización del estado de la actualización del sistema . . . 75
7.4. Actualizaciones interrumpidas . . . . . . . . . . . . . . . . . . 77
7.5. Entradas de bloqueo . . . . . . . . . . . . . . . . . . . . . . . 80
8. Log del sistema y análisis de dumps 85

8.1. Conceptos del log del sistema . . . . . . . . . . . . . . . . . . 85
8.1.1. Accediendo al log local del sistema . . . . . . . . . . . 86
8.1.2. Accediendo al log local en modo normal . . . . . . . . 86
8.1.3. Accediendo al log local en modo experto . . . . . . . . 88
ÍNDICE GENERAL 7
8.1.4. Leyendo el log del sistema . . . . . . . . . . . . . . . . 89

8.1.5. Opciones de relectura del log del sistema . . . . . . . . 89
8.1.6. Accediendo a logs remotos del sistema . . . . . . . . . 91
8.2. Concepto de dump . . . . . . . . . . . . . . . . . . . . . . . . 92
8.2.1. Accediendo a los dumps del sistema . . . . . . . . . . . 92
8.2.2. Interpretando los dumps . . . . . . . . . . . . . . . . . 94
9. Gestión de spool 103

9.1. Concepto de spool . . . . . . . . . . . . . . . . . . . . . . . . 103
9.2. Instalación de una impresora . . . . . . . . . . . . . . . . . . . 103
9.3. Como imprimir . . . . . . . . . . . . . . . . . . . . . . . . . . 106
9.4. Operaciones sobre órdenes de spool . . . . . . . . . . . . . . . 108
10.Gestión de usuarios y autorizaciones 111

10.1. Modelo de seguridad en R/3 . . . . . . . . . . . . . . . . . . . 111
10.2. Mantenimiento de usuarios . . . . . . . . . . . . . . . . . . . . 113
10.3. Generador de perfiles . . . . . . . . . . . . . . . . . . . . . . . 116
11.Sistema de transporte 121

11.1. Órdenes de transporte . . . . . . . . . . . . . . . . . . . . . 121
11.2. Clases de desarrollo . . . . . . . . . . . . . . . . . . . . . . . 124
11.3. Tipos de órdenes de transporte . . . . . . . . . . . . . . . . . 124
11.4. Estados de una orden de transporte y sus tareas . . . . . . . 126
11.5. Customizing organizer y workbench organizer . . . . . . . . . 127
11.6. Transporte manual de órdenes . . . . . . . . . . . . . . . . . 131
11.7. Log del transporte . . . . . . . . . . . . . . . . . . . . . . . . 136
12.Gestión de mandantes 139

12.1. Creación de un nuevo mandante . . . . . . . . . . . . . . . . 140
12.2. Copia local de mandante . . . . . . . . . . . . . . . . . . . . 145
12.3. Copia remota de mandante . . . . . . . . . . . . . . . . . . . 148
12.4. Transporte de mandante . . . . . . . . . . . . . . . . . . . . . 149
13.Mantenimiento de instancias 153

13.1. Perfiles del sistema . . . . . . . . . . . . . . . . . . . . . . . . 153
13.1.1. Mantenimiento de perfiles del sistema . . . . . . . . . . 153
13.1.2. Importación de perfiles del sistema . . . . . . . . . . . 157
13.1.3. Visualización todos los parámetros activos . . . . . . . 158
13.1.4. Parámetros más importantes de un sistema R/3 . . . . 159
13.2. Modos de Operación . . . . . . . . . . . . . . . . . . . . . . . 159
13.2.1. Gestión de modos de operación . . . . . . . . . . . . . 161
8 ÍNDICE GENERAL
13.3. Grupos de logon . . . . . . . . . . . . . . . . . . . . . . . . . 164

13.3.1. Gestión de grupos de logon . . . . . . . . . . . . . . . 165
13.3.2. Saplogon . . . . . . . . . . . . . . . . . . . . . . . . . 166
A. Transacciones más comunes 171
B. Recursos Web 177
C. Casos reales 179

C.1. Autodesk, Inc. . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
C.2. Schweppes, S.A. . . . . . . . . . . . . . . . . . . . . . . . . . . 180
C.3. IBM España . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
D. Glosario 185
Índice de figuras
2.1. Pantalla de entrada a SAP R/3 . . . . . . . . . . . . . . . . . 22

2.2. Barra de tı́tulo . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.3. Barra de aplicaciones . . . . . . . . . . . . . . . . . . . . . . . 27
2.4. Pantalla principal . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.5. Barra de estado . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.6. Ventana de diálogo . . . . . . . . . . . . . . . . . . . . . . . . 29
2.7. Ayuda de búsqueda . . . . . . . . . . . . . . . . . . . . . . . . 30
2.8. Listado de valores posibles . . . . . . . . . . . . . . . . . . . . 31
2.9. Icono de acceso a las opciones técnicas . . . . . . . . . . . . . 33
2.10. Menu del icono de acceso a opciones técnicas . . . . . . . . . . 33
2.11. Status del sistema . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.1. Capas de la estructura cliente/servidor de R/3 . . . . . . . . . 37

3.2. Arquitectura abierta de R/3 . . . . . . . . . . . . . . . . . . . 39
3.3. Esquema del funcionamiento del dispatcher . . . . . . . . . . . 42
5.1. Monitor de procesos de una instancia . . . . . . . . . . . . . . 56

5.2. Monitor de instancias activas . . . . . . . . . . . . . . . . . . 59
5.3. Monitor de sistema operativo . . . . . . . . . . . . . . . . . . 60
5.4. Monitor global de procesos activos . . . . . . . . . . . . . . . 60
5.5. Monitor de conexión de usuarios por instancia . . . . . . . . . 61
5.6. Lista de modos activos por usuario . . . . . . . . . . . . . . . 62
5.7. Información detalllada de usuario . . . . . . . . . . . . . . . . 63
5.8. Usuarios conectados vistos en la transacción AL08 . . . . . . . 64
6.1. Pantalla inicial de definición de job . . . . . . . . . . . . . . . 66

6.2. Pantalla inicial de selección de jobs . . . . . . . . . . . . . . . 69
6.3. Resumen de jobs seleccionados . . . . . . . . . . . . . . . . . . 70
7.1. Esquema funcionamiento actualización ası́ncrona . . . . . . . . 74

7.2. Esquema funcionamiento actualización sı́ncrona . . . . . . . . 74
7.3. Pantalla principal monitor actualización . . . . . . . . . . . . 76
9
10 ÍNDICE DE FIGURAS
7.4. Actualizaciones pendientes . . . . . . . . . . . . . . . . . . . . 78

7.5. Módulos de actualización . . . . . . . . . . . . . . . . . . . . . 79
7.6. Pantalla principal entradas de bloqueo . . . . . . . . . . . . . 81
7.7. Listado de bloqueos activos en el sistema . . . . . . . . . . . . 81
7.8. Información detallada de un bloqueo . . . . . . . . . . . . . . 82
8.1. Pantalla principal log local del sistema . . . . . . . . . . . . . 87

8.2. Parámetros de selección adicionales en modo experto . . . . . 88
8.3. Contenido del log del sistema . . . . . . . . . . . . . . . . . . 90
8.4. Opciones de la barra de aplicaciones del log del sistema . . . . 90
8.5. Pantalla principal log remoto del sistema . . . . . . . . . . . . 91
8.6. Pantalla principal de análisis de dumps . . . . . . . . . . . . . 93
8.7. Búsqueda de dumps antiguos . . . . . . . . . . . . . . . . . . 93
9.1. Transacción SPAD. Mantenimiento de dispositivos de salida . 104

9.2. Datos generales para una impresora local . . . . . . . . . . . . 105
9.3. Tipo de impresora para una impresora local . . . . . . . . . . 106
9.4. Ventana de diálogo para imprimir un listado . . . . . . . . . . 107
9.5. Transacción SP01. Selección de órdenes de spool . . . . . . . . 109
9.6. Transacción SP01. Listado de órdenes de spool . . . . . . . . . 109
9.7. Atributos de una orden de spool . . . . . . . . . . . . . . . . . 110
10.1. Componentes de la seguridad en R/3 . . . . . . . . . . . . . . 112

10.2. Pantalla inicial de la actualización de usuarios . . . . . . . . . 114
10.3. Datos de direccion del maestro de usuarios . . . . . . . . . . . 115
10.4. Transaccion PFCG. Mantenimiento de papeles . . . . . . . . . 116
10.5. Descripcion del papel . . . . . . . . . . . . . . . . . . . . . . . 117
10.6. Transacciones asignadas a un papel . . . . . . . . . . . . . . . 118
10.7. Asignación de valores a los objetos de autorización . . . . . . . 119
10.8. Asignacion de un papel a usuarios . . . . . . . . . . . . . . . . 119
11.1. Esquema de una orden de transporte . . . . . . . . . . . . . . 123

11.2. Esquema de ordenes de transporte . . . . . . . . . . . . . . . . 123
11.3. Clase de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . 125
11.4. Esquema pasos del transporte . . . . . . . . . . . . . . . . . . 127
11.5. Pantalla principal Workbench Organizer . . . . . . . . . . . . 128
11.6. Órdenes de transporte . . . . . . . . . . . . . . . . . . . . . . 129
11.7. Creación de una orden de transporte . . . . . . . . . . . . . . 131
11.8. Listado de órdenes transportadas y liberadas . . . . . . . . . . 133
11.9. Transporte de una orden a un sistema destino . . . . . . . . . 134
11.10.Esquema ejemplo del transporte de una orden . . . . . . . . . 135
11.11.Visualización individual de órdenes . . . . . . . . . . . . . . . 137
ÍNDICE DE FIGURAS 11
11.12.Log del transporte de una orden . . . . . . . . . . . . . . . . . 137
12.1. Pantalla principal de la gestión de mandantes . . . . . . . . . 141

12.2. Detalle de opciones de un mandante . . . . . . . . . . . . . . . 142
12.3. Copia local de un mandante . . . . . . . . . . . . . . . . . . . 145
12.4. Detalle de un perfil de copia . . . . . . . . . . . . . . . . . . . 147
12.5. Copia remota de un mandante . . . . . . . . . . . . . . . . . . 148
12.6. Export de mandante . . . . . . . . . . . . . . . . . . . . . . . 150
13.1. Pantalla pricipal perfiles del sistema . . . . . . . . . . . . . . . 155

13.2. Datos de gestión de un perfil . . . . . . . . . . . . . . . . . . . 155
13.3. Actualización básica de un perfil . . . . . . . . . . . . . . . . . 156
13.4. Actualización ampliada de un perfil . . . . . . . . . . . . . . . 157
13.5. Modos de operación . . . . . . . . . . . . . . . . . . . . . . . . 161
13.6. Distribución de procesos de trabajo . . . . . . . . . . . . . . . 162
13.7. Pantalla principal asignación horaria . . . . . . . . . . . . . . 163
13.8. Asignación horaria a modos de operación . . . . . . . . . . . . 164
13.9. Pantalla principal grupos de logon . . . . . . . . . . . . . . . . 166
13.10.Pantalla detalles creación grupo logon . . . . . . . . . . . . . . 167
13.11.Pantalla de saplogon . . . . . . . . . . . . . . . . . . . . . . . 168
13.12.Opción de selección servidor en saplogon . . . . . . . . . . . . 169
13.13.Opción propiedades en saplogon . . . . . . . . . . . . . . . . . 169
Capı́tulo 1
Introducción a SAP R/3
1.1. Software estándar vs. software a medida

Tras la continua y masiva introducción de la informática en los sistemas
de gestión empresariales durante mas de treinta años, nos encontramos
a principio de los noventa con un panorama variopinto. Los diversos
departamentos de gestión de la mayorı́a de las empresas utilizan varios
software diferentes hechos a medida por el propio departamento de TI1 o
por alguna consultorı́a externa. La compatibilidad es casi nula y la creación
de interfases para integrar los datos de un departamento con otro está a la
orden del dı́a. Veamos un ejemplo clarificador de esta situación. El director
del departamento de TI de una empresa dedicada a la fabricación de grandes
piezas industriales, refleja su caótica situación:
”Nuestra planta de 1.500 trabajadores esta operando sobre

una amalgama formada por sistemas anticuados y modernos
servidores. Estamos operando TCP/IP, IPX y Decnet en nuestra
Ethernet y tenemos concentradores de todo tipo. Algunos
departamentos tienen clientes ligeros y estan formulando grandes
demandas en la red ya que operan procesos en el servidor y estan
reenviando datos de un sitio para otro.
Los sistemas de contabilidad e inventario que tiene la planta
operan en mainframes de arquitectura 370. Un desfasado sistema
de planificación de recursos de fabricación (MRP) opera en
un VAX de gama alta. Y parte del software de gestión de la
fabricación y de transporte opera en un AS/400. Prácticamente
1
Tecnologı́as de la información
13
14 CAPÍTULO 1. INTRODUCCIÓN A SAP R/3
todo el código de cosecha propia que tiene la planta esta escrito

en COBOL.
Aproximadamente la mitad de los operarios de la planta
trabaja con una diversidad de sistemas Windows. La otra mitad
permanece conectada al mainframe IBM con terminales no
inteligentes tipo 3270. Existe una red de area local que engloba
a toda la planta y que opera Novell 3.11, asi como una pequeña
cantidad de servidores NT no tan grandes pero en crecimiento.”
Un situación como esta obliga al departamento de TI a incurrir en grandes

costes para poder mantener en pie unos sistemas que ya no son tan efectivos
como antes. Hablamos de programas que se diseñaron para las necesidades
especificas de la empresa hace unos años y que con la evolución que ha venido
sufriendo la industria y la tecnologı́a, se han quedado obsoletos. Además de
las deficiencias que cada empresa detecta en sus sistemas de información
tenemos que tener en cuenta otros factores generales que afectan a todas
ellas. Problemas como el efecto 2000 o la introducción del Euro como moneda
única en los paı́ses de la CEE no pueden ser obviados por el departamento
de TI.
La pregunta que se plantea cualquier empresa en esta situación es la
siguiente ¿Vamos rehaciendo y adaptando nuestro software o adquirimos
una solución estándar?. Veremos que casi todas la grandes empresas han
optado por una solucion estándar. En la mayorı́a de los casos se trata de
SAP R/3 , por ello es el lı́der mundial, pero existen otras opciones como
Baan, PeopleSoft, Oracle Financials o en menor medida Ross, BCPS o JD
Edwards.
1.2. Visión general de SAP R/3

1.2.1. Caracterı́sticas principales
Las múltiples ventajas del software R/3 hace que se haya convertido
en uno de los estándares de hecho dentro de las grandes corporaciones. A
continuación detallaremos algunas de estas ventajas.
Exhaustivo El sistema R/3 engloba la práctica totalidad de los procesos de

gestión de la empresa. En el siguiente apartado veremos detallados la
cantidad de módulos que incluye.
Integrado Tal cantidad de modulos no aportarı́an demasiado valor añadido

a la empresa si no fuera por la integración. Las interrelaciones estrechas
1.2. VISIÓN GENERAL DE SAP R/3 15
entre modulos de SAP permiten tener disponible en tiempo real y

con exactitud los principales indicadores de gestión. Como ejemplo
ilustrativo diremos que una entrada de mercancı́as en R/3 puede
producir una actualización del inventario de almacén, un apunte
contable en la contabilidad financiera, un actualizacion del sistema de
información del control de costes y un aviso a producción de que hay
nueva materia prima en almacén.
Abierto Tecnológicamente hablando, SAP es un sistema abierto. Podemos

implantarlo en una variedad enorme de servidores diferentes y
ejecutarlo sobre sistemas operativos y sistemas de gestion de bases
de datos de diversos fabricantes. Esto nos permite escalar nuestro
sistema adecuandolo a nuestro tamaño de empresa y elegir a nuestros
proveedores de hardware y software de sistemas sin estar atados a
ninguno. La arquitectura sigue varios de los estándares de sistemas
abiertos como POSIX o X/OPEN.
Flexible Podemos utilizar junto con SAP R/3 otros productos de software
de otros fabricantes, existen interfases con productos de Microsoft,
Lotus o Oracle entre otros. SAP posee tambien un amplio menu de
parametrización que nos permite adecuar 1 el sistema a nuestras
necesidades, asi como un completo sistema de desarrollo para crear
nuestros nuevos programas y que mantengan la integración con el
estándar.
Global El sistema R/3 soporta su utilización en varios idiomas, la

contabilización de documentos en cualquier moneda y tiene recogidas
las particularidades fiscales y de gestión de recursos humanos de un
gran número de paı́ses. Esta globalidad es el argumento de mayor peso
en la decisión de una multinacional a la hora de adquirir SAP.
Actualizado Dos de los grandes problemas de los departamentos de TI a

finales de los 90 han sido el efecto 2000 y la entrada en vigor del euro. El
software SAP R/3 tiene contemplados y solucionados estos problemas.
Además, la constante investigación llevada a cabo por SAP hace que su
software este al dı́a incluyendo la última tecnologı́as disponibles como
EDI, Data Warehouse, clientes Java, comercio electrónico. . . .
1
Para referirse a la adecuación del sistema a la necesidades del cliente se es-
cuchará frecuentemente el termino anglosajón customizing que en castellano se traduce
por parametrización. La palabra inglesa proviene de customer – cliente – por lo que el sig-
nificado completo de customizing viene a ser ”modificación de los parámetros del sistema
para adecuarlo a las necesidades del cliente”
1.2.2. Módulos
Como apuntabamos anteriormente el software de SAP es un compendio
realmente exhaustivo de aplicaciones de gestión. A cada uno de los
componentes que sirven para gestionar cada una de la áreas de la empresa se
les denomina módulos y se les nombra con dos letras correspondientes a las
iniciales del nombre en inglés. Los módulos principales (finanzas, logı́stica
y recursos humanos) se componen a su vez de submódulos. Estos son los
principales módulos y sus caracterı́sticas.
1. Gestión Financiera FI Financial Accounting. Reúne todos los
datos de la empresa relevantes para la contabilidad financiera. Recibe
todas la imputaciones contables del resto de módulos y las centraliza en
un base de datos actualizada en tiempo real. Esto nos permite conocer
el estado contable de nuestra compañia (balance y cuenta de pérdidas
y ganancias) en todo momento. Los submódulos que la componen son
los siguientes.
Control de Gestión CO Controlling. La contabilidad financiera no

siempre puede proporcionar información desde todos los puntos
de vista que una gestión eficaz de costes requiere y es, en este
punto, donde actúa el módulo CO. Partiendo de los datos de
FI, la contabilidad analı́tica nos muestra los ingresos, gastos e
inversiones desde vistas diferentes. Si juntamos esto con el sistema
de planificación y previsión de costes obtendremos un sistema
de información completo con las comparativas del plan contra el
real que nos permiten saber si nos ajustamos al presupuesto y el
porqué.
Tesoreria TR Treasury. Representa la solución completa para
una gestión económico financiera eficaz. Nos permite asegurar la
liquidez de la empresa en todo momento y estructurar los activos
financieros de la manera más lucrativa posible.
Activos Fijos AM Asset Management. Nos permite controlar el
ciclo de vida completo del nuestro inmovilizado, desde la inversión
inicial en activos fijos en curso, pasando por la contabilización
de la manera más conveniente las amortizaciones, la puesta en
explotación de dicho inmovilizado y la enajenación del mismo.
Existe otro pequeño submódulo denominado gestion de inversiones
(IM Investment Management) que esta muy relacionado con AM.
2. Logı́stica LO Logistics. Bajo este epı́grafe se engloba la gestión

de todo el ciclo de vida de los productos de una empresa, desde la
compra y almacenaje de materia prima, pasando por la fabricación del

producto hasta su venta y distribución. Es el módulo más grande de
todos ellos y el que más componentes tiene. Describimos a continuación
los más usados aunque existen otros menos conocidos como la gestión
del servicio al cliente, la gestión de proyectos y la gestión de la calidad
de productos.
Gestión de Materiales MM Materials Management. Optimiza

todos los procesos de compra a través de varias funciones
disponibles. Por un lado permite automatizar las evaluaciones de
proveedores mediante la entrada de ofertas y el mantenimiento de
registros info. También podemos reducir los costes de aprovision-
amiento y almacenamiento, gracias a la precisión de la gestión de
stocks y de almacenes. Este es uno de los puntos donde más clara-
mente poder apreciar el retorno de la inversión porque los costes
de almacenaje es una de las principales preocupaciones de las em-
presas en la actualidad. Un completo sistema de verificación de
facturas nos proporciona la integración necesaria con los modulos
contables FI, CO y TR para tener la información actualizada en
tiempo real.
Planificación de la Producción PP Production Planning. Propor-
ciona procesos completos para todos los tipos de fabricación: fab-
ricación repetitiva, fabricación contra pedido, fabricación contra
catálogo, fabricación por procesos, fabricación por lotes y en se-
rie, hasta la gestión integrada de cadenas de suministro con fun-
ciones MRP y Kanban. La integración con MM puede provocar la
solicitud de necesidades automática al lanzar la planificación de
requerimientos de material.
Mantenimiento de Planta PM Plant Manteinance. Para una em-
presa industrial es fundamental el poder garantizar la disponibil-
idad de la planta y sus herramientas de producción y de esto se
encarga el módulo de PM. Aplicaciones como la planificación de
las revisiones, la programación de órdenes de mantenimiento, las
gestión notificaciones de aprobación nos aseguran una rendimiento
óptimo de nuestra fábrica. Integrando todo esto con PP (podemos
modificar las órdenes de producción en función de la disponibili-
dad de la cadena de producción), con HR (calendarios laborales,
turnos. . . ) y con MM (creando solicitudes de necesidad de re-
puestos, por ejemplo) tenemos controlada una pieza vital de la
empresa.
Ventas y Distribución SD Sales and Distribution. La cambiante

realidad de los mercados actuales es un reto para cualquier
programa de gestión de ventas. SD es lo suficientemente flexible
como para poder adecuarnos a precios, condiciones de entrega,
descuentos, comisiones y ofertas que a veces cambian a diario.
Informar adeduadamente a los módulos financieros del estado de
nuestras ventas es una labor imprescindible para poder conocer el
estado económico y financiero actualizado de la empresa.
3. Recursos Humanos HR Human Resources. Tradicionalmente, la

gestión de recursos humanos se ha considerado una área aislada del
resto de sistemas de gestión de la empresa. SAP, sin embargo, ha llevado
su máxima de integración hasta el punto de incluir la gestión de turnos
y plantillas, los horarios de fábricas, y el absentismo laboral en los
procesos de negocio de la fabricación y el mantemiento de planta entre
otros. Los dos submódulos principales son PA y PD aunque también
existen soluciones menos usadas como la gestión de candidatos, el
calendario de fábrica y la gestión de viajes y gastos.
Nómina PA Payroll Accounting. Mantiene todos los datos de los

empleados en unas estructuras denominadas infotipos que nos
permiten calcular el pago de la nómina y contabilizarla tanto en
FI como CO de manera automática. Existen infotipos para todas
las caracterı́sticas de un empleado, como datos personales, salario
bruto, datos familiares, turnos, retenes, retenciones fiscales. . . Este
submódulo es posiblemente el más especı́fico de cada paı́s debido
a que las leyes que rigen las relaciones laborales difieren mucho
de unos paı́ses a otros. Es por ello que SAP porporciona unos
programas diferentes para cada paı́s y un servicio de actualización
para poder estar al dı́a con los cambios que se producen en
materia de legislación laboral (aparición de nuevas modalidades
de contratación, cambios en la normativa fiscal, etc. . . )
Estructura Organizativa PD Personnel Development. Este submódu-

lo se encarga de gestionar la estructura de la empresa orga-
nizando la misma en departamentos, áreas, grupos de trabajo,
etc. . . Permite la definicición de tareas de puestos de trabajo y la
reorganización de los mismos.
1.2.3. Entorno de desarrollo

Aunque la cantidad de aplicaciones desarrolladas por SAP es enorme,
siempre existe la posibilidad de que el cliente que compre R/3 tenga
alguna necesidad tan especı́fica de su negocio que no este contemplada
en el estándar. También puede darse el caso de que la funcionalidad que
ofrece el estándar no se ajuste completamente a las necesidades del cliente.
Para resolver estas situaciones existe un entorno completo de desarrollo de
nuevas aplicaciones integradas en R/3. Este entorno, que SAP denomina
ABAP/4 Development Workbench, se compone de una serie de herramientas
integradas que permiten crear desarrollos nuevos en poco tiempo.
ABAP/4 El lenguaje de programación ABAP/4 se caracteriza por su total

integración en el sistema R/3. No en vano todo el software de aplicación
(se calcula que más de treinta millones de lı́neas de código) que el cliente
recibe cuando compra R/3 esta escrito en ABAP. Es un mezcla entre
el COBOL y el SQL, hay que tener en cuenta que se creo en los años
70 cuando el COBOL era el lenguaje preferido para los desarrollos de
aplicaciones de gestión. Es un lenguaje de muy alto nivel, fácil de leer
y se aprende rápidamente.
Data Dictionary Es el punto de referencia para los programadores ya que

permite aislarles del sistema de gestión de base de datos que se utilize
por debajo. Desde un misma pantalla se puede crear, modificar y
borrar los objetos de bases de datos, entre los que se incluyen tablas,
estructuras, vistas, elementos de datos y dominios. Las definiciones de
las tablas, por ejemplo, pueden ser referenciadas directamente en los
programas permitiéndonos modificar posteriormente las tablas sin tener
que cambiar los programas. Tenemos la posibilidad de gestionar otros
objetos del data dictionary como las ayudas de búsqueda, los objetos
de bloqueo o los objetos de autorización.
Editor de programas El editor ABAP/4, aparte de proveer de las fun-

ciones básicas para la edición de texto, tiene múltiples caracterı́sticas
que facilitan la programación enormemente. Nos permite efectuar una
verificación de sintaxis y aceptar las sugerencias del dispositivo de cor-
reción automática que tiene incluido. También nos permite resaltar las
palabras clave y tener una vista en forma de estructura jerárquica que
ofrece la posibilidad de ocultar o desglosar bloques sintácticos. De es-
ta forma, el programador obtiene una buena visión de conjunto de la
estructura general del programa.
Screen Painter Con esta herramienta crearemos rápidamente interfases

gráficas de usuario incluyendo una amplia gama de elementos de
control, como botones de pulsación, botones de radio, checkboxes,
etiquetas, campos de entrada, listas de base de datos. . . Las pantallas
que se crean se denominan dynpro 2 y en ellas se incluye la definicion
de la pantalla y sus campos y la lógica de proceso de la misma.
Esta lógica de proceso esta dirigida por eventos, como los lenguajes
visuales modernos, aunque la variedad de eventos posibles esta bastante
limitada.
Entorno de depuración El modo debugging de ABAP/4 es posiblemente

la herramienta más alabada por los programadores habituales de
este lenguaje. Tiene todas las ventajas de este tipo de ayudas a la
programación (creación de breakpoints, watchpoints, ejecución paso a
paso, ejecución por bloques. . . ) pero además nos permite hacer todo
esto viendo el código fuente del programa, por lo que la localización del
lugar del error es exacta.
Otras herramientas. Existe una gran variedad de herramientas adicionales

cuyo uso no es tan frecuente como el Menu Painter, el análisis del
tiempo de ejecución, el Object Browser, el sistema de test asistido por
ordenador (CATT), etc. . .
2
Abreviatura de dynamic programs
Capı́tulo 2
Introducción al sapgui
Como cualquier software que esté basado en arquitectura cliente/servidor,

SAP R/3 dispone de un programa cliente que se debe instalar en cada uno
de los servidores de presentación (PC’s) para poder realizar la conexión al
sistema R/3. Este programa cliente se llama SAPGUI o SAP Frontend y es la
herramienta que nos permite navegar por las distintas aplicaciones integradas
que conforman el sistema R/3 de SAP.
2.1. Pantalla de logon a SAP R/3

Una vez que tengamos instalado el SAPGUI y pulsemos el icono
correspondiente, nos aparecerá la pantalla de conexión al sistema R/3
indicada en la figura 2.1.
En esta pantalla deberemos introducir el usuario que nos hayan asignado
ası́ como su clave de acceso.También podremos elegir el idioma de conexión.
SAP R/3 es un software multilingüe que permite presentar al usuario todos
los textos que aparezcan en pantalla en el idioma que él elija, siempre que
ese idioma haya sido previamente instalado en el sistema. Si el usuario no
introduce idioma alguno, se conectará en el idioma que tenga asignado por
defecto en su registro maestro de usuario.
En esta pantalla aparece un nuevo concepto: Mandante. Este es quizá el
término más importante dentro SAP R/3. El usuario, además de los datos
arriba especificados, deberá indicar a qué mandante se quiere conectar.
2.2. Concepto de mandante

El concepto se puede definir desde 2 puntos de vista distintos pero
complementarios: La Visión Lógica y la Visión Fı́sica.
21
22 CAPÍTULO 2. INTRODUCCIÓN AL SAPGUI
Figura 2.1: Pantalla de entrada a SAP R/3
La Visión Lógica. El mandante no es más que una unidad organizativa

divisoria de la empresa y permite que distintos usuarios estén trabajando en
el mismo sistema sin ningún tipo de interferencia mutua ya que cada usuario
sólo dispondrá de acceso para visualizar y actualizar los datos de aplicación
de la empresa que estén asociados al mandante al que están conectados. Esto
es ası́ porque en el sistema SAP R/3 existen dos tipos de datos diferentes:
Datos dependientes de mandante. Se engloban aquı́ los datos de
aplicación de la empresa (datos de clientes, proveedores, pedidos,
facturas, cuentas contables, etc. . . ) ası́ como la mayorı́a de los datos de
parametrización de la empresa. Se llaman dependientes de mandante
porque sólo son accesibles desde el mandante en el que se crearon. Estos
tipo de datos son los más habituales en un sistema SAP R/3.
Datos independientes de mandante. Se engloban aquı́ ciertos datos de
la parametrización de la empresa que son accesibles desde cualquier
mandante creado. Este tipo de datos son los menos numerosos. Cada
vez que se va a proceder a la modificación de este tipo de datos, el
sistema avisa con un mensaje informativo informándonos de que la
modificación afectará a todos los mandantes. Se ha de ser especialmente
cuidadoso al modificar la parametrización independiente de mandante.
La Visión Fı́sica. La base de datos de SAP R/3 está formada por

tablas relacionales. Cuando el usuario navega por las pantallas de SAP es
2.2. CONCEPTO DE MANDANTE 23
el sistema R/3 el que accede a dichas tablas para irle mostrando al usuario
la información pedida. El mandante es el primer campo clave de la mayorı́a
de la tablas que conforman la base de datos de SAP R/3. Las tablas que
contienen al campo mandante como primer campo dentro de su clave son las
llamadas dependientes de mandante. Las tablas que no contienen al campo
mandante dentro de su clave se llaman independientes de mandante.
Cuando un usuario se conecta a un mandante, el sistema le está asignando
en ese momento el valor del mandante elegido, con lo que el usuario sólo
podrá acceder a visualizar o modificar los datos de cada tabla que tengan
como mandante el que ha elegido en tiempo de conexión. Sin embargo, si
una tabla es independiente de mandante, ésta puede ser accedida desde
cualquier mandante al que se conecte el usuario. Esto se consigue de manera
transparente para el usuario e incluso para el desarrollador ya que es el
propio sistema el que traduce los accesos a las tabla incluyendo en la clausula
WHERE de la instrucción SQL el campo mandante y el valor actual que
tenga.
Ejemplo:
Situación 1: Los usuarios user1 y user2 están ambos conectados al

mandante 015 de un mismo sistema. Mientras el usuario user1 está modifican-
do la factura 1000, el usuario user2 sólo podrá acceder en modo visualización
ya que la factura está siendo bloqueada por el usuario user1; sin embargo,
cuando el usuario user1 termine de modificarla, user2 podrá ver la modifi-
cación realizada por user1, e incluso podrá realizar cualquier modificación
posterior.
Situación 2: El usuario user1 está conectado al mandante 015 y el

usuario user2 está conectado al mandante 016 del mismo sistema. Ahora los
2 usuarios no pueden acceder a la misma información ya que sus conexiones al
sistema están ”lógicamente separadas”; el usuario user1 accede a la factura
1000 de su mandante y el usuario user2 puede acceder al mismo tiempo
a la factura 1000 ( si ésta existe ) de su mandante, si bien los datos son
completamente distintos ya que la factura 1000 del mandante 015 no es la
misma que la factura 1000 del mandante 016.
Lo que realmente ocurre es que para poder los usuarios acceder a la
factura 1000, el sistema está accediendo a la tabla de facturas, pero en cada
caso accede al registro compuesto por el mandante de conexión del usuario
y el número de factura:
Mandante Num. fáctura Descripción

015 1000 Factura X
015 1010 Factura Y
016 1000 Factura Z
016 1050 Factura V
Ası́ pues, cuando el usuario user1, conectado al mandante 015, solicita

la factura 1000, el sistema le muestra la factura con descripción Factura X,
mientras que si el usuario user2 se conecta al mandante 016 para solicitar la
factura 1000, el sistema le mostrará la factura con descripción Factura Z.
2.3. La barra de tı́tulo
Figura 2.2: Barra de tı́tulo
Con la visualización antigua del sapgui se encuentra en la parte superior

de la pantalla y su función principal es mostrarnos la descripción de la
transacción o menú de ámbito en curso. En la nueva visualización del
sapgui se encuentra entre la barra estándar de herramientas y la barra de
aplicaciones.
Ejemplos: Crear usuario, Visualizar material.
2.4. El menú desplegable

El menú desplegable es la herramienta básica para la navegación por
las distintas aplicaciones del sistema SAP R/3. En él podremos encontrar
todas las funciones necesarias para un llevar a cabo un control total sobre
las transacciones y programas. El menú desplegable se caracteriza por tener
fijas las últimas dos opciones de la derecha. Estas dos opciones son:
Sistema. Opción para crear y borrar modos, desconexión del sistema,

ver el status de nuestra sesión entre otras.
Ayuda. Acceso a la ayuda online de SAP.

2.5. LA BARRA ESTÁNDAR DE HERRAMIENTAS 25
2.5. La barra estándar de herramientas

La barra de herramientas estándar es de particular interés, ya que contiene
muchos de los botones necesarios para realizar las acciones más comunes tales
como grabar, enter, imprimir, etc. . . Las funciones asignadas a la barra de
herramientas estándar son las siguientes.
Botón Enter
Se deberá pulsar este botón para chequear los datos introducidos en una
pantalla. El botón enter realiza la misma función que pulsar la tecla enter
del teclado.
Campo de Comandos
Es un prompt de linea de comandos, y en él se pueden introducir

comandos tales como códigos de transacciones o menús de ámbito.
Botón Grabar
Se deberá pulsar este botón cuando deseemos confirmar la grabación de

los datos introducidos.
Botón Back
Se deberá pulsar este botón si queremos regresar a la pantalla anterior

sin grabar los datos introducidos.
Botón Exit
Se deberá pulsar este botón si queremos salir de la actual aplicación. El

sistema nos devuelve a la anterior aplicación.
Botón Cancel
Se deberá pulsar este botón si deseamos salir de la tarea actual sin grabar.
Botón Imprimir
Se deberá pulsar este botón si deseamos imprimir los datos que

actualmente aparecen en pantalla. El botón de impresión estará activado
únicamente en pantallas donde se los datos aparezcan en formato de listado
y formato de tabla.
Botón Buscar
Se deberá pulsar este botón si deseamos realizar una búsqueda de una

cadena de caracteres en la pantalla actual. El botón de buscar estará activado
únicamente en pantallas donde los datos aparezcan en formato de listado y
formato de tabla.
Botón Buscar Siguiente
Se deberá pulsar este botón si deseamos seguir buscando la cadena de

caracteres indicada en una búsqueda anterior con el botón buscar. El botón
de buscar siguiente estará activado únicamente en pantallas donde los datos
aparezcan en formato de listado y formato de tabla.
Botones de Paginación
2.6. LA BARRA DE APLICACIONES 27
Los botones de paginación nos permiten colocarnos en las páginas

deseadas dentro de los listados que podamos obtener en pantalla. Los botones
de paginación estarán activado únicamente en pantallas donde los datos
aparezcan en formato de listado y formato de tabla.
Disponemos de las opciones primera página, página arriba, página abajo
y última página:
2.6. La barra de aplicaciones
Figura 2.3: Barra de aplicaciones
Con la visualización antigua del sapgui se encuentra entre la barra

estándar de herramientas y la parte principal de la pantalla. En ella
disponemos de las opciones básicas para el control de la aplicación actual
(ejemplos de aplicaciones: visualizar pedido de compras, creación de cliente,
.. ). En la nueva visualización del sapgui se encuentra entre la barra de tı́tulos
y la parte principal de la pantalla.
2.7. La pantalla principal
Figura 2.4: Pantalla principal

Es la parte principal de la aplicación y dependiendo de ésta podrá estar

compuesta de campos de entrada y/ o salida, subpantallas, tabla, etc. . .
2.8. La barra de estado
Figura 2.5: Barra de estado
Se encuentra en la parte inferior de la pantalla y su función principal es

la de mostrarnos los mensajes de Información, Advertencia, Error o Éxito
que la aplicación en curso nos muestre al navegar por ella. Como funciones
adicionales, la barra de estado nos muestra también:
El nombre de la base de datos SAP (de 3 caracteres) a la que estamos

conectados. Cuando se instala en el servidor el software del sistema SAP
R/3, éste se comunica con el RDBMS - que debe haber sido previamente
instalado - para crear la base de datos que contendrá todas las tablas
relacionales de las que se componen las distintas aplicaciones modulares
de SAP. El nombre de la base de datos se elige en tiempo de instalación
y debe ser obligatoriamente de 3 caracteres de longitud
El número de modo al que corresponde la pantalla actual.
El mandante al que estamos conectados.
El nombre del servidor a nivel de sistema operativo al que estamos

conectados.
El modo de escritura en el que estamos. Los valores posibles pueden

ser INS (modo insert) y OVR (modo overwrite). Cambiaremos de uno
a otro sin más que pulsar la tecla Insert de nuestro teclado.
En la visualización antigua del sapgui aparece la hora que tiene

configurada el servidor de presentación a nivel de sistema operativo.
Sin embargo, en la nueva visualización no aparece la hora del PC.
Esta hora no es la hora que tiene configurada el Sistema R/3 en el
servidor, sino que es dependiente de la configuración de cada servidor
de presentación.
2.9. VENTANA DE DIÁLOGO 29
2.9. Ventana de diálogo

Un elemento final de la ventana R/3 es la ventana de diálogo en la que el
sistema nos presenta una ventana flotante donde normalmente nos pedirá la
introducción de algún dato o la confirmación o anulación de algún mensaje
sin posibilidad de retornar o avanzar en la navegación hasta que el usuario
introduzca la información pedida. Ver figura 2.6.
Figura 2.6: Ventana de diálogo
2.10. Ayudas de búsqueda

El sistema SAP R/3 dispone de una herramienta especı́fica para la
determinación de valores posibles en un campo de entrada. Esta herramienta
se conoce con el nombre de Ayudas de Búsqueda a partir de la versión 4.0B de
SAP R/3 (hasta esta versión la herramienta era conocida como matchcodes).
Junto con este cambio de nombre se produce a su vez una mejora sustancial
de la herramienta.
Las ayudas de búsqueda son muy útiles ya que en la mayorı́a de los
casos en que deberemos introducir un dato en un campo no conoceremos los
valores posibles. Se encuentran activas en casi todos los campos de entrada
de cualquier pantalla de SAP R/3 y se identifican por aparecer a la derecha
del campo de entrada un pequeño recuadro con una flecha vertical apuntando
hacia abajo como podemos ver en la figura 2.7.
Esta flecha podrá estar activa permanentemente o sólo cuando posi-
cionemos el cursor sobre dicho campo. Veamos esto con un ejemplo:
Figura 2.7: Ayuda de búsqueda
En una pantalla cualquiera del módulo de Gestión de Materiales(MM)

debemos introducir un valor en el concepto Material ; sin embargo no
conocemos qué valores posibles puede tomar ese campo.
Para saber qué posibles valores puede llegar a tomar el campo Material
haremos uso de la ayuda de búsqueda asociada. Para ello pulsaremos su botón
de ayuda de búsqueda o la tecla de función F4 estando posicionados en el
campo.
A continuación nos aparecerá un listado con los posibles valores como el de
la figura 2.8 que el concepto Material puede tomar. Cualquier valor distinto
de los presentados en el listado será un valor no válido y el sistema mostrará el
consiguiente mensaje de error si un valor incorrecto es introducido.
2.11. Modos
Los modos externos en un sistema R/3 son conexiones virtuales que un
usuario puede realizar a partir de una conexión real al sistema. A efectos de
servidor de presentación esto se traduce en la creación de una nueva pantalla
del SAPGUI con la que el usuario puede interactuar con el sistema R/3
independientemente de los anteriores modos externos. En lo que sigue nos
referiremos a los modos externos simplemente como modos.
Ejemplo: En un modo accedemos al Módulo de Ventas para la visual-
ización de un pedido y en otro accedemos a los datos maestros de un cliente.
A esta opción accederemos desde cualquier pantalla de SAP R/3 por el
menú desplegable Sistema → Crear Modo. Es importante saber distinguir
entre conexión real (también llamada sesión) y modo. Existe una limitación
: Sólo se pueden abrir 6 modos por conexión real o sesión
Esta limitación se aplica sólo a los modos, no a las conexiones fı́sicas. Para
las conexiones fı́sicas la única limitación es la que imponga la disponibilidad
de recursos en el Servidor de Presentación. Cada vez que creemos un nuevo
2.11. MODOS 31
Figura 2.8: Listado de valores posibles
modo no estamos realizando una nueva conexión real sino que estamos usando
la misma conexión para simular conexiones virtuales.
La opción del menú desplegable Sistema → Salir del sistema nos
desconecta de la conexión real con la que estemos trabajando, con lo cual se
cerrarán todas las ventanas de los modos que correspondan a esa conexión
real.
Veamos los comandos más habituales para la gestión de modos. Estos
comandos se deberán introducir en el campo de comandos de la barra
estándar de herramientas:
Llamar una transacción
• en el mismo modo (ventana) → Indicar: /nxxxx (xxxx = código

de transacción)
• en un modo adicional → Indicar: /oxxxx (xxxx = código de
transacción)
Finalizar la transacción actual → Indicar: /n.

Atención: Las modificaciones hechas se perderán sin que el sistema
emita un mensaje de advertencia.
Borrar el modo actual → Indicar: /i.

Generar una lista con los modos propios activos → Indicar: /o.
Salir del sistema → Indicar: /nend.
2.12. Concepto de transacción

Una transacción comercial es un intercambio entre una parte del sistema
y otra. La planta de producción, por ejemplo, quiere un suministro desde el
almacén a cambio de un albarán. El almacén sabrá utilizar este albarán para
conciliar el saldo de esta pieza en el inventario de las mismas. Mientras tanto,
el departamento de contabilidad habrá anotado que el material ha pasado
de la cuenta del almacén a la de la planta de producción y definirá una
transacción financiera para registrar el intercambio de valor por el material.
Cuando un usuario está trabajando en un terminal, una transacción con
el sistema no queda terminada hasta que éste verifica que las entradas
de información son correctas. El sistema registrará automáticamente la
transacción como un documento que queda en el sistema en prueba de quién
hizo la transacción y cuándo ésta ocurrió exactamente.
Llevando esta visión al sistema SAP veremos que una transacción se
compone de una o varias dynpros por las que va pasando el usuario en las que
se le pide los datos referentes a la operación que quiere llevar a cabo. Tras
completar toda la información obligatoria y parte de los campos opcionales,
el usuario tiene la opción de grabar la transacción o de desechar toda la
operación. Este es el punto clave de una transacción; si se graba, entonces
todos los datos quedarán registrados, si se cancela, entonces ningún dato se
grabará. El concepto de transacción implica que no pueden quedarse grabados
sólo una parte de los datos, porque esto provocarı́a una inconsistencia en
el sistema. En el ejemplo anterior, si sólo se registrara el movimiento de
mercancı́as entre la planta y el almacén y no se grabara la anotación contable
correspondiente, no podrı́amos, en un momento dado, sacar un balance
contable correcto.
En R/3 accedemos a las transacciones generalmente a través del
menú, pero también podemos acceder directamente tecleando su código de
transacción en el campo de comandos. Los usuarios noveles no suelen utilizar
este último método descrito, pero a medida que se acostumbran al sistema y
se dan cuenta que suelen ejecutar siempre la misma decena de transacciones se
aprenden el código y lo utilizan. En la sección 2.14 veremos como se averigua
el código de una transacción que estamos ejecutando.
2.13. OPCIONES TÉCNICAS 33
2.13. Opciones técnicas

Las opciones técnicas del SAPGUI se encuentran en el último botón a
la derecha de la barra estándar de herramientas y se puede acceder a ellas
pulsando el icono de la figura 2.9 que se encuentra en la parte superior derecha
de la ventana del sapgui.
Figura 2.9: Icono de acceso a las opciones técnicas
Al pinchar el boton nos aparece el menú de la figura 2.10 que tiene las
siguientes opciones.
Figura 2.10: Menu del icono de acceso a opciones técnicas
Opciones nos permite reconfigurar el aspecto de nuestro SAPGUI estable-

ciendo nuevos colores, fuentes. Esta opción sólo es válida para el modo
de visualización antiguo.
Portapapeles es una herramienta similar al Portapapeles de Windows que

nos permite realizar selecciones de texto en cualquier pantalla del
SAPGUI y llevar esa selección a cualquier editor de texto ( bien sea
dentro del Sistema R/3 como fuera de él ).
Generar Gráfico es una herramienta que nos crea una pantalla similar a la
que estamos visualizando con la herramienta de gráficos de SAP R/3.
Sólo funciona con pantallas en las que tengamos algún tipo de listado.
Tamaño estándar cambia la pantalla del SAPGUI a su tamaño por

defecto. Esta opción sólo funciona con resoluciones de pantalla
superiores a 800x600.
Hardcopy (duplicado de pantalla) envı́a la pantalla actual del SAPGUI

a la impresora que tengamos configurada por defecto en el PC. Esta
es una herramienta que está todavı́a en desarrollo por SAP y que
todavı́a produce errores en la impresión de estas capturas debido a
incompatibilidades con ciertos drives de monitores.
Acerca de nos muestra los datos técnicos de versión del SAPGUI que
estamos utilizando.
2.14. La pantalla status

Existe en SAP R/3 una ventana que nos informa sobre la conexión actual
que hemos realizado en el sistema, ası́ como sobre los datos técnicos referentes
al sistema operativo, el sistema de gestión de base de datos del servidor y la
versión de SAP instalada.
A esta pantalla accederemos desde el menú Sistema→Status, el cual
siempre se encuentra disponible desde cualquier punto de navegación de SAP.
En ella podemos distinguir varias partes que describimos a continuación:
Datos utilización En esta parte se presentan los datos relativos a la

conexión que el usuario ha realizado sobre SAP como el mandante,
nombre de usuario, idioma de conexión, fecha y hora del sistema,
ası́ como la fecha y hora de la conexión anterior que realizó ese mismo
usuario sobre ese sistema.
Se deberá tener en cuenta que la hora aquı́ presentada no tiene nada
que ver con la hora presentada en la barra de estado ya que la que
aparece en la ventana status se refiere a la hora actual del servidor y
la hora de la barra de estado se refiere a la hora actual del PC, que en
general no coincidirán.
Datos SAP Este área está destinada a mostrar información técnica sobre
SAP R/3 y se compone de varias subpartes. La parte de Datos
Repository se refiere a la transacción y programas asociados a dicha
2.14. LA PANTALLA STATUS 35
Figura 2.11: Status del sistema
transacción desde donde se ha ejecutado la ventana Status. De

particular importancia es el campo transacción, ya que es uno de los
que más se consulta. La parte Datos Sistema SAP nos dice qué versión
de R/3 está instalada en el servidor, el código que SAP asigna a
nuestra instalación, ası́ como la fecha de vencimiento de la licencia.
La parte Release base nos informa de la versión base que tenemos
instalada. Además de la versión base podemos tener instalados algunos
parches. SAP, periódicamente, envı́a unos parches que arreglan errores
en sus objetos estándar y estos deben ser instalados a medida que
son proporcionados al cliente para corregir malos funcionamientos de
ciertas aplicaciones.
Datos máquina y base de datos En esta última parte se presentan datos

relativos al sistema como puede ser el tipo de sistema operativo
instalado, nombre de la máquina, código de página instalado y tipo
de base de da tos.
Capı́tulo 3
Arquitectura de un sistema R/3
3.1. Introducción
El sistema R/3 de SAP se basa en una arquitectura cliente/servidor de 3
capas: la capa de base de datos, capa de aplicación y capa de presentación.
La idea fundamental de la filosofı́a cliente/servidor es la distribución de las
tareas que debe realizar el sistema. Cada capa se encarga de proveer ciertos
servicios:
Figura 3.1: Capas de la estructura cliente/servidor de R/3
37
38 CAPÍTULO 3. ARQUITECTURA DE UN SISTEMA R/3
1. Capa de base de datos . Servicios de base de datos para el salvado y

recuperación de los datos empresariales.
2. Capa de aplicación. Servicios de aplicación para el manejo de la lógica

de aplicación.
3. Capa de Presentación. Servicios de presentación para la imple-

mentación del GUI.
La arquitectura multicapa cliente/servidor le confiere al sistema R/3 las

siguientes caracterı́sticas:
Escalabilidad Permite la adición de nuevos equipos en cualquiera de sus 3

niveles para acomodarse a los requerimientos dinámicos del sistema.
Portabilidad El software normalmente continua en vigencia más tiempo

que el hardware que lo soporta, es por ello por lo que el software SAP
R/3 se caracteriza por su portabilidad a través de distintos tipos de
hardware, sistemas operativos y RDBMS.
Apertura Todos los datos están almacenados en tablas que son accesibles
sin necesidad de instrucciones complejas de recuperación de datos.
Parametrizabilidad SAP R/3 es un software estándar que dispone

de herramientas especı́ficas para la adaptación del software a las
necesidades de la empresa. Estas herramientas, englobadas en lo que se
conoce como el customizing, permiten amoldar los procesos de negocio
establecidos en el estándar a la manera de trabajar de cada empresa.
El Sistema R/3 sigue varios estándares reconocidos internacionalmente e

interfaces abiertos:
TCP/IP Como protocolo de comunicaciones.

RFC Como el interface de programación de más alto
nivel. Funciones de aplicación pueden ser llamadas
externamente.
CPI-C Para comunicaciones entre programas.
SQL y ODBC Para acceso a los datos guardados en RDBs.
OLE/DDE y RFC Para la integración de aplicaciones de PC.
X.400/X.500 Como el interface de email.
EDI Para el intercambio de datos a nivel de aplicación.
ALE Para la integración on line de aplicaciones descentral-
izadas.
3.2. SERVICIOS DE BASE DE DATOS 39
Debido a su arquitectura abierta no hay prácticamente ninguna restric-

ción en la portabilidad como podemos comprobar por la figura 3.2
S.O. soportados UNIX, Windows NT, AS/400, OS/390

RDBMS soportados Informix, Oracle, ADABAS, DB2, SQL Server
G.U.I. soportados Windows, OS/2 , OSF/Motif, Macintosh
Figura 3.2: Arquitectura abierta de R/3
3.2. Servicios de base de datos

Acceso a base de datos relacional
Para el acceso y manipulación de datos, R/3 usa exclusivamente comandos
del lenguaje SQL. Se dispone de 2 tipos diferentes de SQL: el Open SQL
(extensión de lenguaje de programación ABAP/4 ) y el Native SQL (SQL
nativo de sistema de base de datos que tengamos por debajo de nuestro SAP)
Optimización de las operaciones cliente/servidor

Se dispone de un caché de cliente consistente en bufferes especiales en cada
servidor de aplicación situados en la memoria principal. Reduce el tráfico de
red y los accesos a base de datos.
La optimización de los bufferes es asegurada por el mecanismo de
sobrescritura LRU (Least Recently Used) que consigue mantener en memoria
los datos más frecuentemente usados.
Administración base de datos SAP

SAP ha desarrollado una serie de herramientas para la administración de
la base de datos; para el caso de ORACLE como RDBMS son:
BRBACKUP Herramienta para los backups online y offline de los

datos de aplicación y control, ası́ como de los logs.
BRRESTORE Herramienta para la restauración de los datos de
aplicación y control, ası́ como de los logs.
BRARCHIVE Herramienta para el archivado de los logs.
SAPDBA Herramienta que integra todas las tareas de adminis-
tración de la base de datos.
3.3. Servicios de aplicación

La capa de de aplicación estará, en el caso más general, compuesto de
multiples instancias; por lo que estos servicios estarán distribuidos por todas
estas instancias. Una instancia R/3 consiste de un dispatcher y de uno o
varios procesos de trabajo para cada uno de los servicios que debe proveer,
además de un conjunto de bufferes en memoria compartida
Los servicios de la capa de aplicación se pueden clasificar en:
Dialogo D
Actualización V
Gestión Bloqueos E
Procesamiento Batch B
Servidor Mensajes M
Gateway G
Spool S
El nombre de la instancia contiene el nombre del sistema R/3 al

que pertenece, junto con los servicios que proporciona y el puerto de
comunicaciones:
Un sistema R/3 central con una unica instancia ofreciendo todos los
servicios tendrá el nombre:
<SID>_DVEBMGS00_<TCP/IP Port>
3.3. SERVICIOS DE APLICACIÓN 41
Servicios de diálogo
Cuando un usuario está conectado a un sistema R/3 y realiza cualquier
petición de información al sistema (por ejemplo visualizar una factura), esta
petición es gestionada por el sistema a través de una cola de trabajo o
proceso llamado de diálogo. Estos procesos actúan como interlocutores entre
el usuario final y la base de datos.
Servicios de actualización
El sistema está provisto de unas colas de trabajo especiales llamadas
de actualización por donde gestionará las modificaciones de los datos de
aplicación en la base de datos.
Servicio de gestión de bloqueos

Este servicio juega un papel muy importante y, como el anterior, sólo
una instancia dentro de un mismo sistema puede proveer este servicio. Este
servicio es el encargado de impedir que un objeto en SAP sea modificado por
más de un usuario a la vez. Este servicio es absolutamente necesario para la
integridad de los datos de aplicación.
Se recomienda que estos dos últimos servicios corran en la misma instancia
ya que interactúan entre sı́.
Servicios de procesamiento batch

El sistema R/3 proporciona unos procesos llamados de batch especı́ficos
para la realización de tareas, especialmente largas, que no requieran la
intervención del usuario final. De esta forma se podrán planificar tareas
pesadas como la carga o modificación masiva de datos maestros sin que el
usuario tenga que estar presente para su ejecución.
Servidor de mensajes
Dentro de la capa de aplicación hay una instancia entre el resto que
provee el servicio de servidor de mensajes; este servicio es necesario para
la comunicación de todas las instancias de un sistema R/3, y monitoriza
y asigna recursos libres. La instancia donde corre este servicio es llamada
instancia central.
Servicio de Gateway
Cada instancia necesita de este servicio para realizar tareas que se

extienden más allá de la instancia local:
Servicio de Spool
Este servicio es el encargado de gestionar las peticiones de impresión dentro
de SAP R/3.
- Comunicación entre diferentes sistemas R/3
- Llamadas a funciones remotas
- CPIC (Common Programming Interface for Comunications)
- Conexión de sistemas externos tales como MAPI Server, sistemas EDI. . .
Existe un servicio de gateway por instancia y se activa automáticamente

sin la intervención del administrador cuando la instancia arranca.
Figura 3.3: Esquema del funcionamiento del dispatcher
Dispatcher y procesos de trabajo

Los servicios de diálogo, gestión de bloqueos, actualización, fondo y spool
son provistos por los procesos de trabajo, los cuales son coordinados por el
3.4. SERVICIOS DE PRESENTACIÓN 43
dispatcher. El dispatcher actúa de interface entre la capa de presentación

y la de aplicación ya que todas las peticiones que vienen del nivel de
presentación son recibidas por el dispatcher y son asignadas a procesos de
trabajo libres de las instancias. Las peticiones de usuario, una vez asignadas
por el dispatcher a su correspondiente proceso de trabajo, accederán a la
base de datos directamente con SQL.
SAP R/3 funciona como un grupo de procesos de sistema trabajando en
cooperación y en paralelo. En cada servidor de aplicaciones existe un único
dispatcher y varios procesos de trabajo.
3.4. Servicios de presentación

Las aplicaciones de SAP R/3 han sido diseñadas siguiendo unos
estándares que aseguran uniformidad, integración y ergonomicidad. Esta
uniformidad se extiende a todas las partes del diseño del interface. Algunas
de estas partes en las que observaremos la consistencia del interface son:
Ayuda online Permite acceder a la documentación sobre el uso de las
aplicaciones R/3. Esta ayuda trabaja con referencias de hipertexto
permitiendo la navegación.
Elementos de control Se dispone de campos de entrada para la introduc-
ción de datos, campos de salida para la visualización de los mismos,
table control para la visualización de datos en formato de tabla, push-
buttons, casillas de selección y radio buttons. Se implementan barras de
desplazamiento cuando la información a visualizar en pantalla supera
el tamaño de ésta.
Menús Todas las funciones implementadas en las aplicaciones R/3 pueden
ser accedidas vı́a menus desplegables. Estos menús desplegables se
encuentran uniformemente estructurados a lo largo de todas las
aplicaciones del sistema R/3 siguiendo una estructura arbórea. Se
permite, además la creación de menús propios de usuario.
Barras de tareas La barra de tareas contiene los sı́mbolos de los comandos
de navegación más usados.
Barras de botones Las funciones esenciales para el control de una apli-
cación pueden ser accedidas a través de las barras de botones.
Valores de entrada posibles En casi todos los campos de entrada se
dispone de una función que nos permite visualizar los valores limitados
para la introducción de valores.
Capı́tulo 4
Escenarios de configuración
Cualquier entorno de software de gestión empresarial presenta la

necesidad de tener sistemas completos (hardware y software) separados
dedicados a funciones especı́ficas. Entre estas funciones podemos destacar
el desarrollo del software, las pruebas del mismo, la formación a los usuarios
finales y, la más importante de todas, la puesta en producción del software.
SAP R/3 dispone de múltiples alternativas de configuración de escenarios.
Cada empresa deberá decidir, segun los criterios que veremos posteriormente,
cual es la que mejor se ajusta a sus necesidades. Esta decisión, debido al
carácter abierto y escalable de R/3, puede alterarse en cualquier momento si
se aprecia que los condicionantes de la empresa que llevaron a optar por una
solución determinada han cambiado.
4.1. Consideraciones generales sobre los sis-

temas R/3
Siguiendo la definición de sistema R/3 que se da en el glosario, vamos a
indicar una serie de requerimientos y limitaciones que existen, y que deben
tenerse en cuenta a la hora de decidir el numero de sistemas necesarios para
una implantación real.
La base de datos de un sistema R/3 requiere aproximadamente unos
15 Gb1 de disco duro y cada servidor de aplicaciones necesitará unos
2 Gb. Un mandante que contenga únicamente la parametrización básica
ocupa unos 500 Mb, pero si le añadimos los datos de aplicación que se
van creando al entrar en productivo, los requerimientos de almacenamiento
puede incrementarse hasta varios gigabytes. Otros factores que influyen en
1
En la version 4.0B
45
46 CAPÍTULO 4. ESCENARIOS DE CONFIGURACIÓN
la necesidad de espacio son el sistema de base de datos elegido, el número de

mandantes creados, la cantidad de datos históricos que se guardan. . .
R/3 no provee de ninguna herramienta para separar los datos maestros
de los datos transaccionales. No podemos transportar únicamente los datos
maestros de proveedores sin pasar también los datos de sus pedidos y/o
facturas. Del mismo modo, tampoco podemos separar los datos de módulos
diferentes, una aplicación individual como FI o HR no puede aislarse para
transportarse a otros sistemas.
Por otro lado, sı́ que disponemos de herramientas para reinicializar los
datos transaccionales antes de la entrada en productivo 2 lo que nos permite
borrar toda la contabilidad, pedidos, facturas, órdenes de mantenimiento,
etc, que se hayan creado durante las pruebas.
4.2. Descripción y funciones de cada sistema

Atendiendo únicamente a la función que van a cumplir, hay varios tipos
de sistemas R/3. Vamos a describir los tres más habituales (desarrollo,
integración y producción) aunque dependiendo del tamaño y necesidades
de la empresa SAP también contempla la posibilidad de tener un sistema de
formación aislado y un sistema de desarrollo de cliente propio.
4.2.1. Sistema de desarrollo

Este es el sistema inicial donde se origina el software. Todos los desarrollos
y la parametrización se llevan a cabo aquı́. Una vez que se han completado las
pruebas unitarias de los programas, estos pueden ser transportados al sistema
de integración para hacer pruebas más exhaustivas. Los datos de este sistema
suelen ser escasos (únicamente los que se van creando como pruebas) y a veces
son inconsistentes. Debido al gran número de personas (muchas veces ajenas
a la empresa) que acceden a este sistema debemos controlar, por motivos de
seguridad, que nunca tenga datos reales.
4.2.2. Sistema de integración

En este sistema se realizan pruebas definitivas del software que incluyen:
Pruebas integradas Con ellas nos aseguramos que nuestros desarrollos no

interfieren en otros módulos del sistema. También debemos probar
2
”Go Live”es el término inglés que se utiliza para referirse al momento en que el sistema
productivo se abre a los usuarios finales para que comienzen a trabajar.
4.3. MANDANTES 47
conjuntamente desarrollos de distintos módulos que interactúen entre

sı́.
Pruebas de rendimiento Cargando el sistema de integración con sufi-

ciente volumen de datos podemos probar la eficiencia de nuestro soft-
ware permitiéndonos descubrir errores no funcionales pero que nos im-
posibilitan poner en explotación los programas.
Pruebas de usuario El usuario final no suele tener acceso al sistema de

desarrollo ası́ que es en integración donde debe comprobar que la
funcionalidad del software es la que él pidió en sus especificaciones.
También le sirve para familiarizarse con los nuevos programas y su
interface y solicitar cambios en la interacción si algo no es de su agrado.
La formación a usuarios es otra de las funciones de este sistema.

Aprovechando la necesidad de volumen de datos que tienen las pruebas de
rendimiento, podemos enseñar a los usuarios con ejemplos casi reales como
funciona el software que van a tener que utilizar.
Por último, destacaremos como función importante la posibilidad de
probar el sistema de transporte. Al pasar el software de desarrollo a
integración ya tenemos una prueba de como va a pasar de integración a
producción. Veremos el sistema de transporte detalladamente en capı́tulos
posteriores.
4.2.3. Sistema de producción

El sistema de producción tiene una única función: la explotación real del
software. Aquı́ es donde se almacenan los datos reales de la empresa y donde
se ejecutan los procesos de negocio. Los otros sistemas deben garantizar
que los programas o parametrizaciones incorrectas no afecten ni al trabajo
productivo ni a los datos reales.
4.3. Mandantes
4.3.1. Mandantes estándar
Cualquier sistema R/3 se instala inicialmente con tres mandantes
estándar. En el caso de un sistema IDES existe también el mandante 800 que
incluye un modelo de compañia completo para demostraciones y formación.
Las funciones de los mandantes estándar son las siguientes:
Mandante 000 Es el mandante de referencia. No contiene datos de

parametrización empresarial y por lo tanto las creaciones de mandante
propios se deben hacer como copias de este para asegurarnos que
empezamos la parametrización desde cero. Durante un cambio de
versión de R/3 los datos dependientes de mandante se actualizan
automáticamente en el 000 y los cambios al resto de mandantes se deben
hacer desde aquı́. En el IMG se incluyen unos proyectos que destacan
los cambios entre diferentes versiones de SAP R/3 y que sirven de ayuda
despues del upgrade. Este mandante no debe borrarse del sistema ni
cambiarse ningún aspecto de él.
Mandante 001 Es el mandante de ejemplo. Inicialmente es idéntico al 000

y salvo que lo cambiemos nosotros, ninguna actualización de R/3 lo
va a modificar, al contrario de lo que ocurre con el 000. Siempre lo
podemos tener como ejemplo de la instalación inicial aunque SAP no
impone ninguna prohibición de cambiarlo o borrarlo.
Mandante 066 Mandante del servicio EarlyWatch. Para garantizar la

confidencialidad de nuestros datos reales en productivo existe este
mandante aislado al que se conecta SAP cuando le pedimos que nos
realice un servicio de detección de problemas de rendimiento. Los
usuarios de este mandante tiene las autorizaciones mı́nimas para poder
ejecutar el informe de rendimiento. Este mandante tampoco debe ser
borrado ni modificado nunca.
4.3.2. Mandantes propios

A partir del mandante de referencia 000 podemos crear tantos mandantes
como queramos (siempre que el tamaño de nuestra base de datos nos lo
permita). En el sistema de desarrollo se suelen crear varios mandantes, en
integración alguno menos y en el sistema de producción solo debe existir
un mandante propio. A continuación vamos a describir los mandantes que se
crean habitualmente y cuales son sus funciones. Aunque vemos que tienen un
número asignado, esto se ha hecho para facilitar la diferenciación entre ellos.
En nuestros sistemas R/3 nosotros podemos darle el número que queramos
a cada mandante propio.
Es posible implementar SAP con más o menos mandantes de los
indicados pero hay que buscar el equilibrio entre muchos y pocos. Con
pocos mandantes podemos tener conflictos durante la parametrización, el
desarrollo de programas o las pruebas, pero con muchos mandantes estaremos
aumentando el tamaño de la base de datos y empeorando el rendimiento
4.3. MANDANTES 49
además de requerir un mayor esfuerzo en los procedimiento de administración

de sistemas. Las funciones de los mandantes propios son las siguientes:
Mandante 200 Desarrollo y parametrización en el sistema de desarrollo.

Aquı́ iniciamos nuestro prototipo de empresa y creamos los primeros
desarrollos a medida que sean necesarios. Los programadores y
consultores de aplicación trabajan en este sistema. No tendremos datos
maestros ni transaccionales de manera que la pruebas las realizaremos
en el mandante 220 después de pasar todos los cambios hechos aquı́.
Mandante 210 Trastero.3 Las pruebas inusuales de parametrización las

realizaremos en el 210 de manera que no interrumpamos el trabajo
normal del mandante 200. Los cambios que hagamos aquı́ no se
registran en ningun sitio de manera que si probamos algo que nos va
bien debemos repetirlo a mano en el 200 para que quede grabado en una
orden de transporte y se pueda pasar al mandante de pruebas unitarias.
Periódicamente y para mantener el mandante limpio se hara una copia
de refresco desde el 220.
Mandante 220 Pruebas unitarias en desarrollo. Los responsables de

desarrollo y parametrización efectuarán aquı́ las pruebas unitarias
del prototipo que se está creando. Aquı́ si que tendremos datos
maestros y transaccionales aunque no serán muy fiables debido a que
la parametrización puede cambiarse.
Mandante 300 Pruebas integradas y control de calidad en integración. La

función de este mandante es similar a la del 220 pero con la diferencia
de que las pruebas incluyen la interacción entre los diferentes módulos,
rendimiento y aprobación del usuario. También se comprueba que
el paso de las órdenes de transporte desde el sistema de desarrollo
sea correcto como garantı́a de que el paso de esas mismas órdenes a
producción también lo sea.
Mandante 310 Formación a usuarios finales. Una vez superadas las pruebas
correspondientes al mandante 300, pasamos el prototipo aquı́ para que
los usuarios finales reciban los cursos de formación y tengan un sitio
donde poder seguir practicando después. De esta manera, los datos
maestros y transaccionales que crean no nos interfieren en nuestro
trabajo de implantación habitual.
3
El palabra que utiliza SAP es ”sandbox” que es una caja de arena en la que juegan
los niños. El término ha sido libremente traducido al castellano por los autores.
Mandante 320 Maestro de parametrización. Este mandante se usa única-

mente como referencia para poder consultar la parametricación que ten-
emos en productivo sin tener que acceder a la maquina de productivo,
no obligandonos a dar acceso a la misma a personal no autorizado. Para
que cumpla su función se deben transportar los cambios al mandante
400 y al 320 al mismo tiempo y mantenerlos siempre sincronizados.
Mandante 400 Mandante productivo. Aquı́ es donde se lleva a cabo la

explotación real del software. Este es el único mandante propio que
debe existir en el sistema productivo. Antes del arranque en productivo
realizaremos aquı́ las cargas iniciales de datos maestros, movimientos e
históricos.
4.4. Comparación de escenarios

SAP tiene contemplados escenarios de configuración desde un sólo sistema
hasta cuatro. El escenario que aconseja en todas sus especificaciones técnicas
es el de tres sistemas aunque también es aceptable trabajar con dos (si
las necesidades de la empresa no son muy grandes). Trabajar con un sólo
sistema R/3 es un caso excepcional como veremos más adelante. Vamos a ver
esquemáticamente las ventajas y desventajas de cada una las configuraciones.
4.4.1. Configuración con un sólo sistema (Producción)

Ventajas
Al tener una sola máquina los costes de hardware son mı́nimos.
Todo el trabajo del transporte de elementos de desarrollo queda

suprimido con lo que la administración del sistema se simplifica en
cierto modo.
Desventajas
Tendremos problemas con las tablas independientes de mandante.
Problemas durante la instalación y pruebas de los parches.
Tendremos dificultades para crear nuevos desarrollos y tendremos

que provocar la indisponibilidad del sistema para realizar las pruebas
integradas.
4.4. COMPARACIÓN DE ESCENARIOS 51
El rendimiento de nuestra única máquina será malo ya que tendremos

todos los mandantes en la misma base de datos con el aumento de
tamaño de las tablas que ello implica.
Conclusión
SAP desaconseja totalmente esta configuración. Algunos clientes se
decantan por ella alegando que no van a desarrollar nada de software
nuevo y que tampoco van a parametrizar mucho con lo que un sistema
R/3 básico les sirve para empezar a trabajar. La realidad demuestra más
tarde que hacer esto significa infrautilizar el potencial de adaptabilidad y
crecimiento que tiene SAP y en poco tiempo instalan un segundo sistema
que les permite hacer cosas que antes no podı́an. La reducción inicial de
costes en hardware también resulta engañosa porque en el presupuesto de
un proyecto de implantación de R/3 el coste del hardware representa un
porcentaje bastante pequeño del total. Lo que ocurre es que es uno de los
primeros gastos en el que hay que incurrir y por eso da la impresión de que es
importante reducirlo al mı́nimo. Únicamente se aconseja esta configuración
para centros de formación o demostración del producto.
4.4.2. Configuración con dos sistemas (Desarrollo y

Producción)
Ventajas
Todos los desarrollos nuevos y la parametrización creada se puede

probar en el sistema de desarrollo sin interferir con el trabajo real en
productivo.
Tenemos los datos reales de nuestro sistema productivo aislados en una

máquina a la que no puede acceder el personal de desarrollo, de esta
manera garantizamos la confidencialidad de nuestra información. Este
punto puede ser en algunos caso vital, estratégicamente hablando, o
incluso de obligado cumplimiento legal, en el caso de la información
relativa a empleados, clientes y proveedores.
La inversión en hardware es reducida. El sistema de desarrollo puede ser

una máquina de caracterı́sticas inferiores a la de productivo y estaremos
ajustando bastante nuestro presupuesto.
Desventajas
La cantidad y el ámbito de actuación de los desarrollos que hagan

estará limitado por la falta de un sistema dedicado a las pruebas
integradas. Tendremos que hacer el control de calidad y las pruebas
de aceptación de usuario en el mismo sistema en el que desarrollamos
lo que puede implicar la interrupción de las tareas de desarrollo durante
el tiempo que duren las mismas.
Tampoco podremos llevar a cabo pruebas de rendimiento sin perjudicar

a los equipos de desarrollo o al funcionamiento en productivo.
Tareas ineludibles y de gran complejidad como un cambio de versión

nos dejan inservible el sistema de desarrollo durante todo el tiempo que
dura la actualización de versión.
Conclusión
Esta es la solución mı́nima que acepta SAP para una empresa que pretenda
sacar rentabilidad de R/3. Es una opción correcta para empresas con un
pequeño número de desarrollos y que implanta sólo uno o dos módulos lo que
reduce la cantidad de parametrización a realizar. A medida que la empresa
vaya instalando más módulos de R/3 o que vaya asimilando el Workbench
ABAP/4 como paquete de desarrollo es posible que se vea en la necesidad de
añadir un tercer sistema. En cualquier caso, es muy común ver empresas que
tienen esta configuración desde hace varios años y funcionan correctamente
con ella. En el caso de un cambio de versión, que es uno de los proyectos
complicados que requieren una máquina aparte, la solución por la que se
opta consiste en alquilar durante el tiempo de la actualización de versión una
máquina de pruebas o subcontratar la migración a una consultorı́a externa
que tenga máquinas disponibles para ello.
4.4.3. Configuración con tres sistemas (Desarrollo,

Integración y Producción)
Ventajas
La instalación de aplicaciones o módulos adicionales se puede hacer sin

afectar al trabajo habitual de desarrollo.
La existencia del mandante trastero en el sistema de desarrollo facilita

la familiarización con las funcionalidades de los módulos y la realización
de pruebas sin peligro.
4.4. COMPARACIÓN DE ESCENARIOS 53
Disponemos del sistema de integración para la realización de pruebas de

rendimiento, pruebas de aceptación de usuario, formación a usuarios. . .
Tres es el número mı́nimo de sistemas que hacen falta para poder

probar el sistema de transporte. Al tener integración como paso
intermedio antes de llevar el software a productivo podemos y hacer
este paso utilizando el sistema de transporte, podemos garantizar que
el transporte a productivo va a ser correcto siempre que haya sido
correcto el paso a integración. La importancia de esta prueba radica en
que puede resultar frustrante haber pasado todo el ciclo de pruebas de
un desarrollo y que al final falle en producción por una mala gestión
del sistema de transporte.
Desventajas
Necesitamos una inversión mayor en hardware, tanto en máquinas

para albergar los sistemas R/3 como en hardware auxiliar de
comunicaciones, copias de respaldo, administracion de red. . .
La administración del sistema se complica y por lo tanto necesitaremos

más personal y que además esté bien formado en estas tareas. Este
punto es realmente importante porque si no somos cuidadosos en la
gestión de los transportes de workbench y customizing a traves de los
tres sistemas podemos llegar a anular alguna de las ventajas que supone
tenerlos y convertirla en un claro inconveniente.
Conclusión
Como decı́amos al principio ésta es la configuración que recomienda SAP y
es la que utilizan la mayorı́a de las empresas grandes que tienen presupuesto
y personal suficiente para gestionar todos los sistemas. Cuando se instalan
muchos módulos diferentes y de áreas diferentes (logı́stica, finanzas y recursos
humanos) se hace necesario tener un sistema aislado para las pruebas
integradas. Un configuración con cuatro sistemas solo será necesaria para
empresas que tengan un volúmen de desarrollos propios realmente grandes.
Como se puede suponer, la gestión de un sistema ası́ requiere de personal
realmente cualificado y de una metodologı́a y procedimientos de transporte
que eviten cualquier error ajeno a los desarrollos en sı́ mismos.
Capı́tulo 5
Monitorización de procesos y
usuarios
Una de las tareas básicas de administración de un sistema SAP R/3

consiste en la monitorización de los procesos activos en las instancias que
conforman el sistema – ya sea en el entorno de desarrollo, integración o
producción -, ası́ como qué usuarios han ejecutado tales procesos.
Será labor del administrador el evitar que se ejecuten procesos demasiado
pesados que provoquen una ralentización global del sistema, manteniendo
un contacto estrecho con el departamento de desarrollo y con los usuarios
finales para identificar tales procesos para que sean ejecutados en modo batch
durante el procesamiento nocturno.
5.1. Monitorización de procesos activos

El sistema SAP R/3 dispone de un monitor de procesos activos por el
cual podemos ver qué usuario ha lanzado qué proceso. Además, este monitor
nos informa de qué procesos han sido lanzados en diálogo y qué procesos
corren en modo batch.
Este monitor puede ser accedido directamente por la transacción
SM50 o alternativamente por el menú desplegable Herramientas→Gestión→
Monitor→Supervisar Sistema→Resumen Procesos.
En la pantalla de la figura 5.1 podemos ver qué usuario está realizando
peticiones al sistema, ası́ como el tipo de proceso de trabajo que está gestio-
nando tales peticiones. Explicaremos la información más importante que nos
proporciona el monitor. En la columna ID tenemos un identificador secuen-
cial para cada uno de los procesos de trabajo y la columna Tipo nos dice la
naturaleza del proceso de trabajo:
55
56 CAPÍTULO 5. MONITORIZACIÓN DE PROCESOS Y USUARIOS
Figura 5.1: Monitor de procesos de una instancia
DIA para procesos de diálogo

BTC para procesos batch
UPD para procesos de actualización V1
UPD2 para procesos de actualización V2
ENQ para procesos de Enqueue
SPO para procesos de spool
La columna IDP es el identificador del proceso a nivel de sistema

operativo. Cada uno de los procesos en SAP es realmente un proceso activo
a nivel de sistema operativo. Este código único para cada proceso de trabajo
sirve para identificarlos.
La columna Status nos indica el status de cada uno de los procesos de
trabajo. El status puede tomar cada uno de estos valores:
En ejec. Proceso de trabajo que está actualmente gestionando
peticiones de usuario.
Espera Proceso actualmente en espera de gestionar peticiones
de usuario.
Finalizado Proceso que ha sufrido algún error en el procesamiento
de alguna petición de usuario y cuya actividad ha
sido cancelada automáticamente por el sistema o por
el administrador del mismo. Los procesos con tales
status no pueden volver a gestionar ninguna petición
de usuario hasta que el administrador los vuelva a
activar.
5.1. MONITORIZACIÓN DE PROCESOS ACTIVOS 57
La columna Inicio nos indica si el proceso de trabajo se reinicia cuando

sufre un error para poder seguir gestionando futuras peticiones de usuario
o si por el contrario, cuando una de las peticiones sufra un error el proceso
se quede en status finalizado con lo cual no se reactivará automáticamente.
El valor por defecto es ”Sı́”, y es el valor que deberemos dejar para que los
procesos estén siempre activos aunque sufran algún error en su ejecución.
Errores tı́picos en la ejecución de peticiones de usuario son la terminación
manual de algún modo por parte del usuario. Para cambiar este valor de
Sı́ a No o viceversa deberemos acudir a la opción del menú desplegable
Proceso→Reanudar trás error.
La columna Error nos indica el número de errores que un proceso de
trabajo ha sufrido desde que se arrancó el sistema por última vez.
La columna Semáforo nos indica el número de semáforo asociado a cada
proceso. Para ciertos tipos de actividades como pueda ser la escritura en un
fichero de log a nivel de sistema operativo, el sistema asigna unos códigos a
cada proceso de trabajo. El semáforo para escritura en fichero del sistema
operativo es ”22”.
La columna CPU es el tiempo de CPU que está consumiendo actualmente
el proceso de trabajo en formato minutos:segundos. Esta información por
defecto no está activa, ya que su propia visualización consume recursos del
sistema. Para activarlo deberemos acudir a la barra de aplicaciones y pulsar
el botón CPU.
La columna Hora nos indica el tiempo en segundos que ese proceso
está activo.
La columna Report nos indica el programa que internamente está eje-
cutando el sistema para gestionar la petición de usuario. Todas las pantallas
de SAP tienen por detrás un programa en código fuente que es compilado la
primera vez que es llamado; las siguientes veces el programa ya se encuentra
en el buffer, por lo que el sistema no lo volverá a compilar hasta que lo pierda
del buffer y sea nuevamente llamado.
La columna Mandante nos indica el mandante al que se ha conectado
el usuario que está ejecutando ese proceso.
La columna Usuario nos indica el usuario que ha realizado la petición al
sistema asociada a ese proceso de trabajo.
La columna Acción indica el tipo de acción que es llevada a cabo
sobre la base de datos para gestionar la petición de ese usuario. Acciones
tı́picas pueden ser: Lectura secuencial, lectura directa, insert, update, delete.
Para más información sobre las acciones que ese proceso está realizando
posicionaremos el cursor sobre el proceso deseado y a continuación
pulsaremos el botón Detalle de la barra de aplicaciones.

La barra de aplicaciones nos permite también refrescar el contenido de
la pantalla. Deberemos tener en cuenta que el monitor de esta pantalla
se activará exclusivamente cuando pulsemos el botón refrescar, por lo que
si deseamos tener en pantalla y en todo momento información actualizada
sobre los procesos actualmente en curso deberemos pulsar continuamente el
botón de refresco. Otra opción que nos brinda la barra de aplicaciones del
monitor de procesos activos es la de borrar el modo de usuario asociado al
proceso en cuestión. Esta opción se deberá usar con cuidado y siempre con
el consentimiento del usuario ya que podemos provocar pérdida de datos si
cancelamos un modo que esté actualmente accediendo a la base de datos
para actualizar. Otra posibilidad es la de debugging. SAP, en su entorno
de desarrollo, dispone de una herramienta de depuración de programas; este
debugger puede ser activado para un proceso siempre que seamos el dueño de
tal proceso. Con esto se pueden analizar errores de programación en tiempo
de ejecución.
Los procesos actualmente activos en la instancia en la que estamos
conectados se pueden cancelar manualmente por el administrador del sistema
con la opción del menú desplegable Proceso→Cancelar con core y Proceso→
Cancelar sin core. Ambas opciones cancelan el proceso a nivel de sistema
operativo asociado al proceso de SAP con la salvedad que la opción con
core genera un fichero llamado core donde queda registrada la razón de la
cancelación del proceso. Como este fichero no es editable, elegiremos la opción
sin core para no crear en los discos duros información que no vayamos a usar.
La cancelación manual de un proceso debe ser realizada con extremo cuidado
y siempre deberemos asegurarnos que dicha cancelación no provoque ningún
problema de inconsistencia en los datos de SAP.
Es muy importante tener en cuenta que la información visualizada en la
transacción SM50 se limita exclusivamente a la instancia a la que estemos
conectados. Si nuestro sistema R/3 está formado por varias instancias, para
poder visualizar los procesos de cada una de ellas tendremos que realizar
cualquiera de las siguientes acciones:
1. Conectarnos directamente a cada una para visualizar la SM50

(recordemos que el nombre del servidor sobre el que está montado la
instancia aparece en todo momento en la barra de estado).
2. Acudir directamente a la transacción SM51 (Herramientas→ Gestión→

Monitor→Supervisar Sistema→Servidor ).
En la transacción SM51 visualizamos las instancias que están activas y
que componen el sistema SAP. Desde esta transacción podremos saber
5.1. MONITORIZACIÓN DE PROCESOS ACTIVOS 59
Figura 5.2: Monitor de instancias activas
si un sistema SAP es distribuı́do o si por el contrario está formado por

una única instancia central.
En la columna Servidor aparece el nombre de la instancia. En
la columna Máquina aparace el nombre del servidor sobre el que
está instalada la instancia SAP y por último, en la columna Tipo
se visualizan los tipos de procesos de trabajo que están dados de alta
en esa instancia.
En la barra de aplicaciones de esa pantalla tenemos la opción de refresco
para actualizar la información. También tenemos la opción Procesos
que nos lleva directamente a la transacción SM50 de cada una de las
instancias sin más que posicionar el cursor sobre la instancia deseada y
pulsar el botón descrito. Accedemos a la misma transacción si hacemos
doble click sobre cada una de las instancias.
La opción Usuarios nos muestra un listado con los usuarios conectados
a la instancia que hayamos elegido. Esta opción la veremos más a
fondo en la siguiente sección. La opción Log del sistema nos lleva a
la transacción SM21 que está descrita en el capı́tulo 8.
La opción Colector SO nos muestra información técnica acerca del
sistema operativo tal como el número de procesadores, el porcentaje
de utilización CPU, la cantidad de memoria disponible y libre, e
información sobre la paginación. Esta opción se encuentra disponible
en el menú desplegable Pasar a→ Collector SO.
Figura 5.3: Monitor de sistema operativo
La opción Login remoto nos abre un modo sobre la instancia

previamente seleccionada. El modo nuevo nos accede al menú inicial
de conexión a SAP. La opción Info Release nos muestra información
sobre la versión del kernel de SAP instalado en la instancia que
hayamos elegido. El kernel de SAP está formado por ficheros ejecutables
compilados en lenguaje C necesarios para el arranque y funcionamiento
de SAP.
3. Ejecutar la transacción SM66 de Procesos Globales activos (Herramientas→

Gestión→ Monitor→ Rendimiento→ Exceptions/Users→ Active Users→
All Processes) que se muestra en la figura 5.4
Figura 5.4: Monitor global de procesos activos

5.2. MONITORIZACIÓN USUARIOS CONECTADOS 61
5.2. Monitorización usuarios conectados

Otra tarea básica de administración que se complementa con la moni-
torización de procesos activos es la monitorización de usuarios conectados al
sistema. Existe en el sistema una herramienta que nos proporciona en for-
mato listado los usuarios que se han conectado a la instancia actual. Tal
información es mostrada en la transacción SM04 Herramientas→ Gestión→
Monitor→Supervisar Sistema→ Usuarios Conectados.
Figura 5.5: Monitor de conexión de usuarios por instancia
La pantalla de usuarios conectados nos da la siguiente información:
1. Mandante de conexión .
2. Nombre de usuario en SAP .
3. Nombre del servidor de presentación desde donde se ha realizado la

conexión.
4. Código de transacción perteneciente al modo actualmente activo .
5. Hora a la que se ejecutó por última vez algún proceso desde el modo
activo asociado a la conexión fı́sica que estamos visualizando.
6. Cantidad de modos abiertos por el usuario .

7. Cantidad de modos internos que el sistema ha debido abrir para

gestionar las peticiones del usuario. Estos modos internos no tienen
nada que ver con los modos externos o de usuario – denominados
simplemente modos – que se explicaron en el capı́tulo 2.
Cada lı́nea de este listado corresponde con una conexión fı́sica al sistema
por usuario. Este monitor tiene además diversas funciones en su barra de
aplicaciones:
Una de ellas es la posibilidad de ver los modos abiertos por cada usuario.
Posicionando el cursor sobre un usuario y pulsando el botón Modos, o
alternativamente, haciendo doble click sobre un usuario, el sistema nos
muestra una ventana de diálogo con un listado de los modos abiertos por
usuario y conexión fı́sica.
Figura 5.6: Lista de modos activos por usuario
Esta ventana nos muestra en orden de apertura los modos abiertos por el
usuario y conexión fı́sica elegidos, ası́ como la hora a la que se ha realizado
la última petición de información por tales modos. También tenemos la
opción de borrar el modo que queramos. Con esta última opción estaremos
cerrando remotamente al usuario la pantalla asociada a ese modo. Esta opción
habrá que usarla siempre con el consentimiento del usuario y con extremo
cuidado. Tal acción de borrado manual de modo queda reflejado en el log del
sistema – ver capı́tulo 8 –.
Otra opción de la barra de aplicaciones es la de refresco de pantalla. Esta
opción es muy útil ya que el sistema sólo nos estará mostrando la información
actualizada cada vez que pulsemos la función de refresco. También podremos
ordenar el listado por la columna deseada tanto en orden ascendente como
descendente.
Como una tercera opción de la barra de aplicaciones el sistema, si
pulsamos el botón Info Usuario, nos muestra en una ventana de diálogo el
5.2. MONITORIZACIÓN USUARIOS CONECTADOS 63
nombre, apellido, departamento y extensión telefónica asociados al usuario

elegido. Estos datos aparecerán siempre y cuando se hayan introducido en el
maestro de usuarios cuando se creó el usuario.
Figura 5.7: Información detalllada de usuario
Será labor del administrador, en general, el crear los usuarios en el maestro

de usuarios con los permisos adecuados para que puedan desarrollar sus tareas
sin problema y el mantener actualizados sus datos básicos como el nombre,
departamento, teléfono de contacto para que la gestión y monitorización de
tales usuarios resulte más sencilla.
La limitación de este monitor es que el listado se restringe a usuarios
que se han conectado al sistema por la instancia desde donde estamos
iniciando el monitor de usuarios. Si nuestro sistema se compone de una única
instancia, este listado nos mostrará al completo todos los usuarios conectados
al sistema, pero si nuestro sistema se compone de varias instancias tenemos
varias opciones para visualizar todos los usuarios conectados:
Abrir una conexión fı́sica por cada instancia de las que se componga
nuestro sistema SAP e iniciar desde cada conexión la transacción SM04.
En un único modo acudir a la transacción SM51 y desde ahı́ y

posicionándonos en cada una de las instancias activas pulsaremos el
botón Usuario de la barra de aplicaciones. De esta manera tendremos
un listado de usuarios por cada instancia.
Desde el menú desplegable inicial de SAP ejecutar Gestion→ Monitor→

Rendimiento→ Exceptions/Users→ Active Users, o alternativamente
ejecutar la transacción AL08 que se muestra en la figura 5.8. Esta
transacción muestra los usuarios actualmente conectados al sistema y
agrupados por instancia de conexión.
Figura 5.8: Usuarios conectados vistos en la transacción AL08
Crear un programa o query sencilla sobre la tabla USR41 que contiene

en todo momento los usuarios conectados por cualquier instancia. Hay
que tener en cuenta que el resultado se nos restringe al mandante al
que estamos conectados. Si el sistema tiene más de un mandante donde
estén definidos los usuarios, el listado no será completo.
Capı́tulo 6
Procesamiento en fondo
6.1. Conceptos de procesamiento en fondo

Además de la opción de ejecutar programas y transacciones online, SAP
nos da la posibilidad de ejecutar procesos en fondo.Podemos encontrarnos con
otros términos para referirse al mismo concepto como procesamiento batch
o procesamiento en segundo plano. Simplemente consiste en la ejecución de
un proceso sin interacción con el usuario, es decir, que lanzamos el proceso y
el sapgui nos devuelve el control aunque el programa todavı́a no ha acabado
de ejecutarse.
Este modo de ejecución de procesos adquiere una importancia vital
cuando tratamos con programas que tardan mucho tiempo en completarse.
Tradicionalmente se considera un buen tiempo de respuesta para un sistema
online el hecho de que no transcurran más de dos segundos entre dos acciones
del usuario sobre el programa. Parece poco probable que un usuario este
esperando más de cinco minutos a la respuesta del sistema sin pensar que
se ha quedado bloqueado o que ha fallado el programa, por eso, cuando se
prevea que un proceso va a durar más tiempo deberı́a ser lanzado en fondo.
El lanzamiento de programas en fondo nos permite mejorar el rendimiento
de las transacciones online ya que podemos determinar que la prioridad
de los mismos sea menor ya que el usuario no esta esperando respuesta
inmediata. Lo más aconsejable es lanzar los programas en fondo durante
la noche, cuando la carga de usuarios que actúan online es casi nula. Esto
último se deberá hacer cuando los procesos no sean crı́ticos para la obtención
de datos en tiempo real; es la dirección de la empresa la que debe decidir, por
ejemplo, si sus pedidos de compra deben emitirse online o por el contrario
pueden esperar todos a la noche.
65
66 CAPÍTULO 6. PROCESAMIENTO EN FONDO
6.2. Definición de jobs

Un job es conjunto de uno o más programas que se lanzan consecutiva-
mente en proceso de fondo. Para crear un job 1 utilizaremos la transacción
SM36, a la que se llega a traves de Herramientas→ CCMS→ Jobs→ Defini-
ción, y que nos muestra la pantalla de la figura 6.1
Figura 6.1: Pantalla inicial de definición de job
La definición de un job tiene tres áreas principales:
Información general
Hora de inicio o evento de ejecución
Pasos
6.2.1. Información general

La información general conforma la base de la definición del job.
Primeramente debemos darle un nombre que defina el propósito que tiene.
Este nombre no es único, lo que significa que podemos crear varios jobs que
se llamen actualizar estadı́sticas enero. Esto se produce porque SAP
asigna un número interno a cada job con el que diferencia a unos de otros
pero para nosotros esa clave es desconocida y sólo podremos referirnos al job
por su nombre.
1
SAP utiliza la palabra definir para la acción de crear un job
6.2. DEFINICIÓN DE JOBS 67
Otro datos de información general es la clase de job que indica a SAP la

prioridad de ejecución de los procesos que le mandamos y en función de ello
asigna los recursos adecuadamente. La clases posibles son:
A La más alta prioridad. Se utiliza para procesos que son crı́ticos para el
funcionamiento del sistema.
B Prioridad media. Para procesos periódicos que aseguran el mantenimiento
del sistema.
C Prioridad normal. Es la clase normal que se asigna a los jobs de usuario.
El administrador del sistema puede decidir reservar colas de BTC
especı́ficas para los jobs de clase A de manera que nunca tenga que esperar
un proceso de este tipo a que haya recursos libres para su ejecución.
Por último, tenemos la posibilidad de determinar especı́ficamente el
servidor de aplicaciones que dara curso a nuestra petición de proceso de
fondo. Si no indicamos ninguna instancia por la que deba ejecutarse entonces
el sistema elegira la primera disponible.
6.2.2. Hora de inicio o evento

Una vez definidas la caracterı́sticas generales del job tenemos que indicar
cuándo debe ejecutarse. Esta indicación puede hacerse de diversas formas:
Ejecución inmediata. Como su propio nombre indica nos permite iniciar
el job en el momento de acabar su definición.
Ejecución por fecha/hora. Deberemos indicarle un dı́a y una hora en
la que queramos que comience el job. Además podemos marcar el job
como periódico, es decir, que se repetirá su ejecución cada cierto periodo
de tiempo (cada dı́a, cada 35 minutos. . . ). Esta opción es muy útil
para la planificación de jobs de mantenimiento o de recolección de
estadı́sticas, de hecho, al instalar SAP ya existen una serie de jobs
de estas caracterı́sticas.
Por job. Con esta indicación de comienzo podemos encadenar unos
jobs con otros, es decir, indicaremos al job B que empiece a ejecutarse
cuando acabe el job A. Tambien podemos especificar que sólo comience
cuando la finalización del job A sea correcta, en caso de que el job A
haya sido cancelado en mitad de su ejecución el job B no se ejecutará.
Por evento. El job comenzará cuando se produzca en el sistema el evento
que le indiquemos.
Un evento es un suceso se produce automáticamente en el sistema R/3

o que podemos provocar manualmente. Previamente, el evento debe estar
definido en la correspondiente tabla. SAP viene con una serie de eventos
predefinidos como pueden ser, el arranque o parada de las instancias, el
cambio de modo de operación de nocturno a diurno, etc. El administrador o
los desarrolladores pueden crear otros eventos a conveniencia. Estos pueden
dispararse desde programas en ejecución o podemos lanzarlos manualmente
a través del menú Herramientas→ CCMS→ Jobs→ Lanzar evento.
6.2.3. Pasos
Tras definir cómo y cuándo queremos que se procese el job, por último,
vamos a decirle qué es lo que queremos que haga. Los pasos de un job
los componen los diferentes programas que queremos que se ejecuten. Estos
programas pueden ser de tres tipos:
Un programa ABAP estándar o creado por nosotros al que le

indicaremos una variante que contenga los parámetros de selección de
ese programa.
Un comando externo que se ejecutará en el sistema operativo donde

este el servidor de aplicaciones que procesa el job. Este tipo de pasos
son dependientes del sistema operativo, no sirven los mismos comandos
para Unix que para Windows NT. Un ejemplo clásico es la ordenación
de un fichero que ha creado un programa en un paso previo y que lo
necesita otro programa de un paso posterior.
Un programa externo que reside en otro sistema distinto a R/3. Se

utiliza cuando tenemos otros sistemas de gestión distintos a SAP y
necesitamos tener interfases entre ellos.
Los pasos de un job constituyen un proceso unificado, esto implica que si

el primero de un job de tres pasos sufre un cancelación, ninguno de los otros
dos pasos restantes se procesará. Es como si crearamos tres jobs encadenados
con dependencia de status con un paso cada uno.
6.3. Análisis de jobs

Una vez definido completamente el job podemos analizar y monitorizar
su situación a través de la transacción SM37 o por el menú Herramientas→
CCMS→ Jobs→ Actualización que nos muestra la pantalla de la figura 6.2.
6.3. ANÁLISIS DE JOBS 69
Figura 6.2: Pantalla inicial de selección de jobs
Inicialmente tendremos que introducir los criterios de selección de los jobs

que queremos analizar porque pueden existir cientos de jobs definidos en un
momento dado y nosotros estaremos interesados en unos pocos. La selección
se hace principalmente por nombre del job, usuario creador del job, fecha y
hora de comienzo y estado actual en el que se encuentra. Una vez introducidos
los datos y tras pulsar enter veremos la pantalla de la figura 6.3. En ella vemos
un listado de los jobs con diversos datos sobre él. La información que más nos
interesa es el estado en el que se encuentra, en la siguiente sección hablamos
de los diferentes estados de un job.
6.3.1. Estados de un job

Una vez definido un job lo que nos interesa conocer en todo momento
su estado. Los posibles estados en los que se puede encontrar un job son los
siguientes:
Previsto Es el estado inicial en el que se encuentra cuando hemos definido

los datos generales y los pasos del job pero no hemos dicho nada acerca
de cuando debe ejecutarse. La elección del nombre no es muy acorde a
su significado real porque un job que esta previsto no se ejecutará nunca
a menos que lo liberemos o modifiquemos la sección de datos de inicio.
Liberado Cuando definimos completamente un job con la transaccion SM36

o liberamos un job que estaba en estado previsto, entonces pasa a
liberado. En este estado permanecerá hasta que se cumpla la condición

de su fecha de inicio o se produzca el evento que lo lanza.
Listo Una vez se han cumplido las condiciones de inicio del job pasa al
estado listo en el que estará esperando a que haya recursos libres en el
sistema para ejecutarse. Normalmente no veremos jobs en este estado
a menos que tengamos el sistema tan cargado que no haya suficientes
colas de batch para atender a todos los jobs que están en estado listo.
Activo El job se está procesando. Podemos ver el log desde este momento
y ver lo que está haciendo.
Finalizado El job completó su ejecución correctamente.
Cancelado Algún problema hizo que el job finalizara de manera incorrecta.

Normalmente se producen cancelación por errores de los programas que
componen el job o problemas de acceso a la base de datos. En el log
del job podemos ver el motivo de la cancelación.
6.3.2. Operaciones sobre jobs

El listado de la figura 6.3 es en realidad un completo centro de control
de los procesos en fondo. Si pulsamos en el menú Job veremos todas las
operaciones posibles que podemos hacer para alterar el estado o composición
de un job.
Figura 6.3: Resumen de jobs seleccionados

6.3. ANÁLISIS DE JOBS 71
Vamos a describir alguna de las operaciones que podemos realizar sobre

los procesos en fondo:
Verificar status En alguna ocasiones podemos descubrir que un job que

creemos que está activo – porque la transacción SM37 ası́ nos lo
dice – realmente no lo está. Esto puede suceder cuando el proceso
del sistema operativo correspondiente a la cola BTC por donde va el
job es cancelado o el servidor de aplicaciones tiene algún problema
de rendimiento. Con está opción forzamos a SAP a comprobar que el
estado que nos da para el job es realmente el que tiene en el sistema
operativo. Cuando comprueba la actividad de un job que vemos como
activo y no recibe respuesta del sistema operativo nos dirá que el
proceso ya no está en activo y nos pregunta si queremos pasarlo a
estado cancelado.
Cancelar job activo Con esta opción detenemos un job activo y lo

pasamos directamente a estado cancelado. Si tuviera un job encadenado
a continuación este no se procesará.
Borrar . Una vez terminado o cancelado un job podemos borrarlo

manualmente de la lista con este punto del menú.
Liberado→Previsto Para poder deshacer la liberación de un job utilizare-

mos esta opción. Es muy útil para no tener que borrar y redefinir un
job que hemos liberado a una hora concreta y después nos hemos dado
cuenta de que no queremos lanzarlo aún.
Copiar Si queremos que un job se ejecute dos o tres veces lo copiaremos con
esta opción y liberaremos cada una de las copias convenientemente. Si
queremos que se ejecute más veces deberı́amos pensar en la posibilidad
de crear un job periódico.
Modificar Siempre y cuando no haya comenzado la ejecución del job

(mientras este en previsto o liberado) podremos modificar cualquier
dato de la definición del mismo.
Repetir previsión Esta opción es muy similar a la de copiar pero además

nos pide los datos de inicio del job, es decir, es como si copiamos un
job y liberamos inmediatamente la copia.
Traslado a otro servidor Con esta opción cambiamos el servidor de

destino de un job que no este activo.
Capturar job activo Para comprobar en que punto va la ejecución del

proceso que hemos lanzado podemos capturar un job que este activo.
Al pulsar este opción se nos abre un modo nuevo con el depurador
(debugger ) de ABAP/4 parado en el punto del programa que estuviera
en ese momento. Sólo tiene hacer esto sentido si conocemos y
entendemos el código fuente del programa que se procesa. Además hay
que ser cauteloso con está opción ya que hay determinadas fases de un
programa ABAP en las que el hecho de activarse el debugger provoca
una cancelación con dump debido a un commit work implı́cito en la
base de datos.
Detalles de job Aquı́ podemos ver datos internos del job. El más intere-
sante es comprobar en que servidor de aplicaciones se está procesan-
do y en número de cola BTC para poder monitorizar su estado y/o
rendimiento con la transacción SM51.
Capı́tulo 7
Servicios de actualización
El servicio de actualización en SAP R/3 es especialmente importante ya

que es el encargado de gestionar las modificaciones solicitadas por los usuarios
en las base de datos. Dichas actualizaciones se pueden generar a través de
procesos de trabajo tipo diálogo, batch o update.
7.1. Actualización sı́ncrona y ası́ncrona

La actualización en la base de datos de un sistema R/3 es mayoritaria-
mente ası́ncrona, es decir, el sistema gestiona la petición de actualización del
usuario en un proceso aparte del proceso de dialogo del usuario. El efecto de
este tipo de actualizaciones es que el usuario se desentiende totalmente del
proceso de actualización, ya que no debe esperar a que el sistema acceda a
actualizar a la base de datos para poder seguir trabajando. Esto se traduce en
una mejora del rendimiento; el proceso de diálogo del usuario no espera a que
se terminen las actualizaciones para seguir procesando las peticiones de ese
usuario. La actualización ası́ncrona no se realiza directamente en los procesos
de diálogo, sino que se gestionan en procesos de actualización especı́ficos.
En la figura 7.1 se muestra en forma esquemática cómo las actualizaciones
ası́ncronas pertenecientes a un proceso de trabajo a un usuario son lanzadas
en paralelo.
La actualización sı́ncrona, aunque es menos frecuente, también se produce
en un sistema R/3, y se diferencia de la ası́ncrona en que la petición
de actualización en la base de datos se genera en el mismo proceso de
trabajo que gestiona el resto de peticiones del usuario – diálogo si el usuario
está trabajando en online o batch si el usuario ha dejado programado un job
–. De esta forma el proceso de diálogo o batch debe esperar a que se realicen
las actualizaciones en la base de datos antes de seguir procesando el resto de
73
74 CAPÍTULO 7. SERVICIOS DE ACTUALIZACIÓN
Figura 7.1: Esquema funcionamiento actualización ası́ncrona
peticiones del usuario, por lo que el rendimiento será peor que en el caso de
la actualización ası́ncrona.
En la figura 7.2 se muestra en forma esquemática cómo las actualizaciones
sı́ncronas pertenecientes a un proceso de trabajo asociado a un usuario
son lanzadas en el mismo proceso, obligando al proceso a esperar a que la
actualización termine para poder continuar.
Figura 7.2: Esquema funcionamiento actualización sı́ncrona
Los usuarios no pueden elegir si los cambios en la base de datos se realizan

7.2. PROCESOS DE ACTUALIZACIÓN V1 Y V2 75
de forma sı́ncrona o ası́ncrona, ya que esto depende de la programación de la

aplicación en curso. Si se trata de actualizaciones dentro de alguna aplicación
hecha a medida será tarea del analista de la aplicación el decidir qué tipo
de actualización realizar. En lo que sigue nos ceñiremos a la actualización
ası́ncrona, que a la postre es la que juega un papel más importante en un
sistema SAP R/3.
7.2. Procesos de actualización V1 y V2

La actualización ası́ncrona presenta además una ventaja adicional:
implementa las LUW 1 . Las LUWs consisten en bloques autoconsistentes de
datos, de tal forma que su actualización en la base de datos es llevada a cabo
completamente. Si surgiera algún problema en la base de datos la grabación
de cada LUW no se realizarı́a, de esta manera se evitan las inconsistencias
que pudieran surgir al grabar una LUW a medias.
La actualización ası́ncrona, consiste de 2 tipos de actualización : V1 y
V2. El sistema R/3 distingue entre componentes de actualización crı́tica
primaria (V1) y secundaria no crı́tica (V2). La diferenciación entre estos
dos tipos de actualización permite que el sistema procese los cambios crı́ticos
en la base de datos por delante de los cambios menos crı́ticos asignándoles
diferentes LUWs; esto es necesario ya que las componentes V1 deben ser
realizadas cuanto antes. Para asegurar la consistencia de los datos, las
actualizaciones V1 se procesan con la supervisión del gestor de bloqueos
de SAP R/3 que impide que varias modificaciones sobre el mismo objeto se
realicen concurrentemente.
Las componentes de actualización V1 y V2 se procesan por distintos
procesos de trabajo, siempre que en el sistema existan procesos de
actualización UPD y UP2: Las componentes V1 se gestionan por las colas
de trabajo UPD y los componentes V2 se gestionan por las colas de trabajo
UP2. Si no existen este tipo de procesos de trabajo, las componentes V2 se
gestionan también por las colas UPD.
7.3. Monitorización del estado de la actual-

ización del sistema
El sistema SAP R/3 dispone de una herramienta para la activación y de-
sactivación genérica de los servicios de actualización, ası́ como para la mon-
1
Logical units of work o unidades lógicas de trabajo
itorización de las actualizaciones en curso y de las posibles actualizaciones

interrumpidas que puedan haber ocurrido.
El sistema SAP R/3, ante un problema grave en la base de datos –como
pueda ser el llenado de algún tablespace a nivel del RDBMS– reacciona
desactivando la actualización con lo cual todas las modificaciones a realizar en
la base de datos se quedan en un estado de espera hasta que la actualización
vuelva a estar activa. Esta desactivación automática tiene lugar en aras de
preservar la integridad de la base de datos y su ejecución queda registrada en
el log del sistema (ver Capı́tulo 8). Será tarea del administrador el subsanar
el error que produjo la desactivación de la actualización del sistema y su
posterior activación. La actualización es activada automáticamente cada vez
que el sistema SAP R/3 es arrancado en el servidor, por lo que sólo se
deberá monitorizar su posible desactivación.
La transacción desde donde podremos gestionar centralmente la actual-
ización es la SM13, o alternativamente por el menú deplegable Herramientas
→ Gestión → Monitor → Actualización.
Figura 7.3: Pantalla principal monitor actualización
En ella, básicamente, se nos muestra si la actualización del sistema

está activa o ha sido desactivada por alguna causa. Si la actualización ha
sido desactivada, el botón Info nos proporciona qué proceso y usuario han
causado su desactivación. El resto de campos son campos de selección para
monitorizar las actualizaciones que han tenido lugar y han fallado o las que
están en curso. Como campos de selección tenemos:
7.4. ACTUALIZACIONES INTERRUMPIDAS 77
Mandante Por defecto aparece el mandante al que nos hemos

conectado.
Usuario Por defecto aparece el código de usuario con que nos
hemos conectado al sistema.
Status Podremos elegir las actualizaciones que se han can-
celado, las que todavı́a no se han ejecutado, las que
tienen la parte V1 ejecutada, las que tienen la parte
V2 ejecutada o todas las actualizaciones con los 3 sta-
tus anteriores.
Fecha y hora Podremos elegir una fecha y hora mı́nima a partir de
la cual mostrar los datos.
Ctdad. Reg. Podremos elegir la cantidad de actualizaciones a
visualizar .
Servidor Podremos elegir las actualizaciones que se han real-
izado desde un servidor de aplicaciones determinado.
Se dispone, desde esta transacción, de la posibilidad de activar como

de desactivar la actualización del sistema. El administrador puede, en caso
necesario, desactivar la actualización para evitar una situación crı́tica si se ha
detectado algún problema grave en la base de datos. Esta opción se encuentra
en la transacción SM13, en el menú desplegable Regs. Actualización →
Actualización → Desactivar (existe a este nivel también la opción activar).
7.4. Actualizaciones interrumpidas

Las actualizaciones en la base de datos se pueden ver interrumpidas por
dos tipos de problemas:
1. Problemas globales que afectan a toda la base de datos, como pueda ser
el llenado de un tablespace en un sistema R/3 sobre un RDBMS como
ORACLE o DB2 (en sistemas sobre SQL Server el concepto análogo al
tablespace es el device).
2. Problemas locales que afectan exclusivamente a ciertas aplicaciones

dentro del sistema SAP R/3 y que pueden venir causados por errores de
programación o por la cancelación abrupta del proceso de actualización
desde el servidor de presentación debido a una caı́da del fluı́do eléctrico
o a una interrupción deliberada del sistema por parte del usuario.
Las actualizaciones interrumpidas por este tipo de problemas las
deberá supervisar el equipo de desarrollo de la aplicación en cuestión,
y a la postre deberán ser ellos quienes decidan qué hacer con estas
actualizaciones.
Un registro de actualización puede tener uno de los siguientes 6 estados:
1. Init. El registro no ha sido procesado todavı́a.
2. Auto. El registro será automáticamente actualizado cuando la actual-

ización del sistema se active.
3. Run. El registro de actualización está siendo procesado .
4. V1. La parte V1 ha sido completada.
5. V2. La parte V2 ha sido completada. Cuando esta parte se completa el

registro desaparece (es la configuración por defecto) por lo que será muy
dificil visualizar un registro en este status.
6. Err. Un error causó la interrupción de la actualización del registro.
Para visualizar los registros de actualización interrumpidas acudiremos

a la transacción SM13 y elegiremos el status Çancelado” en la pantalla de
selección. A continuación pulsamos ejecutar y el sistema nos mostrará en un
listado las actualizaciones interrumpidas como el de la figura 7.4
Figura 7.4: Actualizaciones pendientes
En este listado nos aparece el mandante y usuario que han lanzado el

registro de actualización, ası́ como la fecha y hora y transacción desde dónde
se ha realizado la actualización. Como último campo tenemos el estado actual
del registro de actualización.
7.4. ACTUALIZACIONES INTERRUMPIDAS 79
Si queremos disponer de más información acerca de los distintos módulos

que componen el registro de actualización podremos hacer doble click sobre
él o posicionar el cursor en la lı́nea deseada y a continuación pulsar el botón
de Módulos de Actualización en la barra de aplicaciones. A continuación se
nos mostrará una pantalla similar a la de la figura 7.5.
Figura 7.5: Módulos de actualización
En esta pantalla se nos divide el registro de actualización en varios

módulos y se nos especifica si pertenecen a la parte V1 o V2. Conjuntamente
con el departamento de desarrollo y los usuarios finales se deberá decidir
qué hacer con los registros de actualización interrumpidos. Estos registros
pueden ser:
Contabilizados Esta opción es para procesar registros de actualización

que se encuentren en status init. Para ejecutar esta opción deberemos
posicionar el cursor sobre el registro deseado y elegir la opción Regs.
Actualización → Contabilizar → Uno por uno (existe también la opción
de contabilizar todos los registros visualizados).
Grabados posteriormente Opción para registros cuya parte V1 haya

sido realizada y quede por hacer la parte V2. Con esta opción
se continúa con la grabación. Esta opción se encuentra en Regs.
Actualización → Grabar Posteriormente → Uno por uno (existe
también la opción de grabar posteriormente todos los registros
visualizados).
Reiniciados En casos aislados, un registro de actualización se puede

quedar indefinidamente es estatus Run” aunque realmente no se
está procesando. La opción Reiniciar en Regs. Actualización →
Reinicializar → Status orden actualización → Uno por uno (existe

también la opción de reiniciar todos los registros visualizados) deja
el registro preparado para ser procesado de nuevo.
Borrados Opción para eliminar los registros de actualización. Esta opción

se encuentra en Regs. Actualización → Borrar → Uno por uno (existe
también la opción de borrar todos los registros visualizados). Cuando
ninguna de las opciones anteriores funciona, como pueda ser para el caso
de actualizaciones que provengan de procesos batch, esta es la única
posibilidad que resta. El borrado será el paso previo a la repetición
del proceso de actualización del objeto en cuestión –alta de material,
alta de apunte contable, modificación de pedido– desde la aplicación
correspondiente.
7.5. Entradas de bloqueo

SAP R/3 dispone de un sistema de gestión de bloqueos de objetos para
evitar la modificación concurrente de un objeto. Con esto, se asegura la
consistencia de los objetos en SAP R/3.
Cuando un usuario accede a modificar un objeto, el sistema genera un
registro de bloqueo con la información necesaria. Si un segundo usuario
intenta modificar ese mismo objeto mientras el 1er usuario lo tiene bloqueado,
el sistema le muestra al segundo usuario un mensaje de error indicándole que
un usuario ya está tratando el objeto solicitado. Los bloqueos se establecen
al iniciar las transacciones de modificación y no son liberados hasta que el
usuario pulsa ”Grabar”, la información es actualizada en la base de datos y
la transacción es finalizada.
Toda modificación de un objeto desde cualquier aplicación estándar
dentro de SAP R/3 genera entradas de bloqueo. Será tarea del departamento
de desarrollo asegurar que las nuevas aplicaciones hechas a medida dentro de
SAP R/3 generen tales bloqueos cuando desde estas nuevas aplicaciones se
acceda a modificar algún objeto.
La transacción que nos muestra los bloqueos actualmente activos en
el sistema es la SM12 y se puede acceder a ella por el siguiente menú:
Herramientas → Gestión → Monitor → Entradas de bloqueo.
En esta pantalla disponemos de unos parámetros de selección para filtrar
los bloqueos actualmente activos. Los parámetros son tabla, argumento de
bloqueo, mandante y usuario. En general no conoceremos el argumento de
bloqueo, ya que esa información depende del objeto que se esté modificando.
Es más normal conocer la tabla o usuario que está produciendo un bloqueo.
7.5. ENTRADAS DE BLOQUEO 81
Figura 7.6: Pantalla principal entradas de bloqueo
Por defecto, el campo mandante y usuario están rellenos con los valores por
defecto.
Una vez rellenos los parámetros de selección con los valores deseados
pulsamos el botón ”Enter” en la barra de aplicaciones y nos aparecerá un
listado con las entradas de bloqueo que cumplen la selección realizada.
Figura 7.7: Listado de bloqueos activos en el sistema
El listado está compuesto por los campos mandante, usuario, hora a la que
se ha producido el bloqueo, tabla a la que pertenece el registro bloqueado, y
argumento de bloqueo que en general corresponderá con el código del objeto
que se esté modificando. En la barra de aplicaciones disponemos de tres
opciones: Detalles, Borrado y Refrescar.
La opción ”Detalles”, a la que también se puede acceder haciendo doble
click sobre el registro deseado, nos muestra información adicional sobre la
entrada de bloqueo tal como la transacción desde donde se ha producido el
bloqueo.
Figura 7.8: Información detallada de un bloqueo
En raras ocasiones puede llegar a ocurrir que el bloqueo generado por una
modificación no se llegue a liberar, lo cual provoca que el resto de usuarios
no pueda acceder a modificar esos objetos debido al bloqueo. Existen dos
causas principales de bloqueos no liberados:
Actualizaciones interrumpidas Cuando un registro de actualización

queda interrumpido, su entrada de bloqueo correspondiente no es
liberada hasta que el registro de actualización en cuestión sea procesado
correctamente o borrado.
Estas entradas de bloqueo no se deberán borrar bajo ningún concepto
ya que se podrı́an causar inconsistencias en la base de datos. Estas
7.5. ENTRADAS DE BLOQUEO 83
entradas de bloqueo se liberarán automáticamente cuando el registro

de actualización interrumpida sea tratado.
Terminación anormal de la conexión de usuario Si un usuario apaga

abruptamente su PC sin haberse desconectado previamente, el modo
de usuario puede quedar activo en el sistema, con lo cual los bloqueos
activados por el usuario no son liberados. Se deberán borrar los modos
que el usuario tenga activos en el sistema para eliminar las entradas de
bloqueo; si con ello no desaparecen, y estamos seguros que la entrada
de bloqueo no procede de una actualización interrumpida, podremos
borrar la entrada desde el listado de la transacción SM12.
Capı́tulo 8
Log del sistema y análisis de

dumps
8.1. Conceptos del log del sistema

El sistema R/3 graba eventos y problemas, tales como borrado de modos
de usuarios del sistema, bloqueos de usuarios al introducir incorrectamente
la password, parada y arranque del sistema, etc en un log. Este log no es más
que un fichero a nivel de sistema operativo. Si el sistema R/3 se ejecuta en
hosts UNIX, existen dos tipos de log del sistema:
Local
Cada servidor de aplicaciones de R/3 dispone de un log local que contiene
los mensajes que ha generado ese servidor. Este fichero de log local es un
fichero circular. Cuando el fichero llega a su tamaño máximo, el sistema
empieza a sobreescribir el fichero desde el principio (la información más
antigua). El fichero de log local se guarda en cada servidor de aplicación
en la siguiente ruta:
Entorno UNIX → /usr/sap/<SID>/<instance number>/log/SLOG00
Entorno Windows NT → C:\usr\sap\<SID>\<instance number>\log\Slog00.log
donde <SID> es el nombre de la base de datos SAP y <instance number>

es el número de instancia.
Central
Cada servidor de aplicaciones copia las entradas del log local a un log
85
86 CAPÍTULO 8. LOG DEL SISTEMA Y ANÁLISIS DE DUMPS
central. Esta opción no se encuentra en servidores Windows NT ni AS/400,

sólo existen logs locales (uno por servidor de aplicación). El log central se
guarda en un servidor de aplicaciones seleccionado, el resto de servidores de
aplicación envı́an sus mensajes locales a este servidor.
El log central es escrito en 2 ficheros: un fichero activo y un fichero antiguo.
El fichero activo contiene el log actual. Cuando el fichero activo llega a su
longitud máxima definido en los parámetros del sistema, éste borra el fichero
antiguo de logs, usa el fichero activo como fichero antiguo y crea un nuevo
fichero de log. Este cambio en el log no es notificado al usuario.
Mientras que el log local se mantiene siempre actualizado, el log central
puede sufrir retardos desde que se escribe un mensaje en el log local hasta
que ese mensaje es enviado al log central. Fallos de comunicaciones entre los
distintos servidores pueden resultar en retardos grandes en la escritura del
log central o incluso en pérdida de estos mensajes.
8.1.1. Accediendo al log local del sistema

Al log del Sistema se accede directamente por la transacción SM21 o por
el menú general Herramientas→Gestión→Monitor→Log Sistema .
La pantalla de seleccción de la transacción SM21 tiene 2 modos: El modo
Normal y Experto. El modo normal es el definido por defecto, y al que se
entra directamente cuando se ejecuta la transacción SM21. Para cambiar
a modo experto, deberemos ir al menú desplegable Tratar→Modo experto.
Ambos modos se diferencian en que éste último da más opciones de selección.
8.1.2. Accediendo al log local en modo normal

Accediendo a la transacción SM21 – directamente o a través de menú –
entramos por defecto a la pantalla de selección del log local del servidor de
aplicaciones al que estemos conectados en Modo Normal.
Veamos los distintos parámetros de selección que nos permitirán filtrar
los datos del log:
De Fecha/Hora a Fecha/Hora: Permite establecer un rango de fechas

de mensajes del log a visualizar.
Usuario: Nos permitirá visualizar sólo los mensajes que se hayan

grabado en el sistema debido exclusivamente a la actividad del usuario
especificado.
8.1. CONCEPTOS DEL LOG DEL SISTEMA 87
Figura 8.1: Pantalla principal log local del sistema
Código de transación: Nos permitirá visualizar los mensajes del log

debidos exclusivamente a la acción de los usuarios sobre la transacción
especificada.
Proceso SAP: Nos permitirá visualizar los mensajes de log debidos a

un proceso particular R/3. Valores posibles son:
DP Procesos del dispatcher

Dn Procesos de trabajo, donde n = 0,...,9 o n = a,
...,z . En el caso de tener más de 10 procesos de
trabajo numeraremos los siguientes con las letras del
abecedario.
VB Actualizaciones
Vn Programas de actualizazión, donde n = 0,...,9 o n =
a, ...,z
Sn Spool, donde n = 0,...,9 o n = a, ...,z
MS Servidor de Mensajes
Clases de Problemas: Limita la visualización por tipo de mensaje, sólo

errores, errores y advertencias y todos los mensajes. El valor por defecto

es la opción todos los mensajes.
8.1.3. Accediendo al log local en modo experto

Para acceder al log del sistema en modo experto deberemos acceder por
el menú desplegable tal y como se ha explicado anteriormente. La pantalla
visualizada es igual que la anterior con la salvedad que se dispone de más
opciones de filtro como es la opción Atributos.
Figura 8.2: Parámetros de selección adicionales en modo experto
Esta opción nos permite filtrar además por:
Programa: Se restringe el resultado a los mensajes causados por la

ejecución del programa especificado.
Clase de Problema: Limita el resultado a ciertos tipos de mensajes. Los
valores posibles son:
K Mensajes del kernel del sistema

S Mensajes de estado
T Mensajes de transacciones
W Mensajes de advertencia
X Otros tipos de mensajes
De fichero / posición a fichero / posición: Define el segmento del fichero

de log a leer. Si ya se ha leı́do el fichero una vez, se puede determinar
la posición de una entrada especı́fica haciendo doble click; la posición

se encuentra en la sección de detalles técnicos.
Formato mensaje (tipo): Se pueden seleccionar mensajes por el

formato de la componente del sistema. Para visualizar posibles valores,
deberemos pulsar el botón de ayuda de búsqueda correspondiente.
Terminal: Se pueden filtrar los mensajes que han sido causados por la
actividad llevada a cabo desde un servidor de presentación.
Clase de desarrollo: Se pueden filtrar los mensajes que han sido

producidos por la ejecución de programas que pertenezcan a una clase
de desarrollo en particular. Las clases de desarrollo son agrupaciones
de objetos de Workbench o Customizing cuyo propósito es la
jerarquización de tales objetos para una mejor gestión ası́ como el
posibilitar su transporte a otros entornos.
Con entradas internas Syslog: Visualización de mensajes relativos a los

procesos de recolección y envı́o de mensajes de log desde el log local al
log central. Esta opción no esta disponible para entornos que no sean
Unix.
8.1.4. Leyendo el log del sistema

Una vez introducidos los valores de selección en la pantalla accederemos
al contenido del log pulsando el botón Nueva Lectura syslog.
El log del sistema aparece en formato tabla con las siguientes columnas
en el siguiente orden:
Hora del mensaje

Proceso SAP
Mandante
Usuario
Código transacción
No de mensaje
Texto del mensaje
8.1.5. Opciones de relectura del log del sistema

Si hemos visualizado una vez el contenido del log del sistema filtrando
exclusivamente por fecha y sin salirnos de la transacción volvemos a la
Figura 8.3: Contenido del log del sistema
pantalla de selección, el sistema muestra tres distintas opciones para volver

a visualizar la información:
Figura 8.4: Opciones de la barra de aplicaciones del log del sistema
Nueva Lectura en el Syslog. Vuelve a acceder al fichero para sacar un nuevo

listado con los parámetros que se hayan seleccionado.
Sólo Editar Nuevamente. Vuelve a mostrar el último resultado del log

visualizado anteriormente con esta opción.
Cargar en Syslog. Permite realizar una nueva lectura en el syslog filtrando

con otros valores pero mantiene en el buffer el anterior resultado que puede
ser accedido de nuevo a través de la segunda opción.
8.1.6. Accediendo a logs remotos del sistema

Si el sistema SAP R/3 al que estamos conectados es un sistema
distribuı́do, es decir , está compuesto de varios servidores de aplicaciones,
tendremos la posibilidad de acceder a cada uno de los logs locales de cada
uno de los servidores sin tener que conectarnos directamente a cada uno de
los servidores de aplicación. Para ello usaremos las opciones de lectura de logs
remotos que nos ofrece la transacción SM21. Estas opciones se encuentran
en el menú desplegable en Syslog→Seleccionar .
Figura 8.5: Pantalla principal log remoto del sistema
La opción syslog local es la que está activa por defecto y ya ha sido

explicada . La opción syslog remoto nos lleva a una pantalla similar a la
pantalla de selección del syslog local con la salvedad que incluye un parámetro
más en la pantalla de selección. Este parámetro es la instancia. Aquı́ le
podremos indicar el nombre de la instancia cuyo log del sistema queremos
visualizar.
La opción todos los syslogs remotos nos lleva a una pantalla de selección
idéntica a la del log local con la salvedad que los mensajes que se visualizarán
corresponderán la los de todas las instancias que componen nuestro sistema
R/3. En la visualización de los mensajes del log aparecerá un campo más
llamado instancia que nos servirá para conocer en qué instancia se ha

generado cada mensaje.
La opción Syslog Central no está disponible para sistemas R/3 fuera del
entorno UNIX.
Es importante destacar que las únicas instancias que estan disponibles
para la visualización de los logs remotos son las que componen el sistema
R/3 al que estamos conectados.
8.2. Concepto de dump

Dump o error en tiempo de ejecución es un log de terminación anormal
de ejecución de cualquier programa. Esto se produce por una cancelación del
programa que se está actualmente ejecutando; el sistema nos muestra una
pantalla con un log de terminación donde se puede encontrar información
acerca del error producido y su posible solución.
Las posibles causas de terminación anormal de programas, entre otras,
pueden ser:
Errores de sintaxis en programas hechos a medida.
Referencias obsoletas a objetos del Workbench hechos a medida que
han sido eliminados.
Cancelación manual de un modo actualmente en ejecución.
Cuando se produce una terminación anormal de una ejecución de un
programa, el dump es mostrado automáticamente en exclusiva al usuario cuyo
proceso de diálogo ha sido cancelado. En ese momento el usuario podrá leer
ese log, pero si se sale de la pantalla del log del dump, éste ya no se vuelve
a mostrar en pantalla. Para acceder de nuevo a él, deberemos acudir a
la transacción donde se puede gestionar todos los dumps producidos en el
sistema.
8.2.1. Accediendo a los dumps del sistema

La transacción de los dumps es ST22; accediendo por el menú desplegable
será Herramientas→Gestión → Monitor→Análisis de Dumps.
Por defecto sólo se muestran los dumps producidos a fecha de hoy y el
dı́a anterior. Si deseamos acceder a un dump más antiguo deberemos pulsar
la opción Pasar a → Sel. Dump breve. A continuación nos aparacerá una
pantalla de selección donde podremos filtrar por fecha, usuario, máquina,
mandante.
8.2. CONCEPTO DE DUMP 93
Figura 8.6: Pantalla principal de análisis de dumps
Figura 8.7: Búsqueda de dumps antiguos

8.2.2. Interpretando los dumps

Tanto si visualizamos los dumps producidos a fecha actual, como del dı́a
anterior o alguna fecha más antigua, éstos aparecerán en forma de lista. Esta
lista está formada por los siguientes campos:
Fecha del dump

Hora del dump
Servidor de aplicaciones donde se ha producido
Usuario que ha provocado el dump
Breve descripción del dump
Haciendo doble click en cada uno de ellos accederemos al log del dump
donde tendremos toda la información. El contenido de todos los dumps están
organizados en las siguientes secciones:
1. ¿Qué sucedió? .
Sección donde se explica brevemente el error.
2. ¿Qué se puede hacer? .

Sección que explica brevemente las acciones a llevar a cabo.
3. Análisis error .
Sección donde se explica más detalladamente el error. Es una extensión
de la sección 1.
4. Notas para corregir errores .

Sección donde se explica más detalladamente las acciones a llevar a
cabo. Es una extensión de la sección 2.
5. Entorno sistema .
Sección donde aparecen las variables del sistema más importantes, tales
como la versión de SAP, nombre del servidor, dirección IP, sistema
operativo, RDBMS, version del kernel, etc. . .
6. Usuario, transacción.
Sección donde aparece el usuario que ha generado el dump, programa
que se estaba ejecutando, transacción, idioma, etc. . .
7. Informaciones lugar terminación .

Sección donde se especifica la linea del programa donde se ha producido
el error.
8. Detalle código fuente .

Sección que muestra un intervalo del código fuente donde se ha
producido el error. La lı́nea donde se ha producido el error aparece
marcada con una flecha.
9. Contenido campos sistema.

Sección donde se muestran los valores que tenı́an algunas variables del
sistema cuando se produjo el error.
10. Variables seleccionadas .

Sección donde se detalla más exhaustivamente el contenido de más
variables cuando se produjo el error .
11. Llamadas / Eventos activos.

Sección que detalla el evento o la llamada a la que pertenece la linea
de código que ha producido el error .
12. Notas internas .

Sección que detalla la función C –perteneciente al kernel de SAP– donde
se ha producido el error .
13. Llamadas activas kernel SAP .

Sección que detalla los elementos del kernel y su posición que estaban
activos en el momento del error .
14. Lista programas ABAP involucrados .

Sección que muestra los programas involucrados en la ejecución del
programa que produjo el error .
15. Lista tablas internas .

Sección que detalla el conjunto de tablas internas que se estaban
procesando en el momento del error y el contenido de su cabecera
cuando el error se produjo.
16. Directorio tablas aplicación (contenidos) .

Sección que detalla las tablas de aplicación que han sido usadas durante
la ejecución del programa que ha terminado en error.
17. Directorio ámbitos datos (info gestión) .

Sección que detalla el conjunto de objetos del workbench ( variables,
parámetros, tablas) involucradas en la ejecución del programa.
18. Directorio ámbitos datos (contenidos).

Sección de contenido parecido a la anterior .
19. ABAP/4 Bloques control CONT .

Sección con información complementaria a la de la seccion 8 .
20. Fin análisis error tiempo ejecución .

Sección que marca el fin del log del dump.
Si bien el tı́tulo de cada sección aparece en el idioma de conexión,

el contenido sólo se encuentra disponible en inglés y en alemán. Si nos
conectamos al sistema en un idioma distinto del inglés y alemán, el dump
será visualizado en el idioma configurado como de suplementación, que en
general será el inglés, sino se ha definido suplementación de idioma (esto
pertenece a la instalación de lenguajes) se visualizará en el idioma original
de SAP, que es el alemán.
Las secciones más importantes y que más nos pueden ayudar para
solucionar el error son la 1,3,7 y 8.
Ejemplo de log de dump
Errores tiempo ejecución SYNTAX_ERROR

ocurrido el 20.07.2000 a 04:10:06
----------------------------------------------------------
Syntax error in program "AQ99HA==========CAND1========= ".
----------------------
> Qué sucedió ?
----------------------
The following syntax error occurred in the program
AQ99HA==========CAND1========= :
"The data object "T750B" does not have a component called "PERNR".
"The current ABAP/4 program "AQ99HA==========CAND1========= " had
to be terminated because one of the statements could not be
executed.
This is probably due to an error in the ABAP/4 program.
--------------------------------
> Qué se puede hacer ?
--------------------------------
Please eliminate the error by performing a syntax check

(or an extended program check) on the program
"AQ99HA==========CAND1========= ".
You can also perform the syntax check from the ABAP/4 Editor.
If the problem persists, proceed as follows:
Print out the error message (using the "Print" function)
and make a note of the actions and input that caused the
error.
To resolve the problem, contact your SAP system administrator.
-----------------
Análisis error
-----------------
The following syntax error was found in the program

AQ99HA==========CAND1========= :
"The data object "T750B" does not have a component called "PERNR".
------------------------------------
Notas para corregir errores
------------------------------------
Probably the only way to eliminate the error is to correct

the program.
-
If you cannot solve the problem yourself, please send the
following documents to SAP:
1. A hard copy print describing the problem.

To obtain this, select the "Print" function on the current screen.
-
2. A suitable hardcopy printout of the system log.

To obtain this, call the system log with Transaction SM21
and select the "Print" function to print out the relevant
part.
3. If the programs are your own programs or modified SAP programs,

supply the source code.

To do this, you can either use the "PRINT" command in the
editor or print the programs using the report RSINCL00.
4. Details regarding the conditions under which the error occurred

or which actions and input led to the error.
----------------------
Entorno sistema
----------------------
SAP Release.............. "40B"
Application server....... "prodsap1"

Network address.......... "10.190.20.13"
Operating system......... "AIX"
Release.................. "3"
Hardware type............ "000541934C00"
Database server.......... "sa3dbh2r"

Database type............ "ORACLE"
Database name............ "SP1"
Database owner........... "SAPR3"
Character set............ "es_ES.ISO8859-1"
SAP kernel............... "40B"

Created on............... "Nov 4 1999 01:44:15"
Created in............... "AIX 2 4 004218294C00"
Database version......... "ORACLE 8.0.0.4"
Patch level.............. "542"

Patch text............... " "
Supported environment....
Database................. "ORACLE 8"
SAP database version..... "40B"
Operating system......... "AIX 2, AIX 1, AIX 3"
-------------------------------
Usuario, transacción....
-------------------------------
Client.............. 111
User................ "116665u"
Language key........ "S"
Transaction......... " "
Program............. "AQ99HA==========CAND1========= "
Screen.............. "SAPMSSY0 1000"
Screen line......... 6
-------------------------------------------
Informaciones lugar terminación
-------------------------------------------
The termination occurred in the ABAP/4 program

"AQ99HA==========CAND1========= " in " ".
The main program was " ".
The termination occurred in line 0 of the source code of

program " " (when calling the editor 00).
The program "AQ99HA==========CAND1========= " was started as a
background job.
------------------------------------
Contenido campos sistema
------------------------------------
Campo SY Contenido....... Campo SY Contenido...........

-------- ---------------- -------- --------------------
SY-SUBRC 0 SY-INDEX 0
SY-TABIX 0 SY-DBCNT 0
SY-FDPOS 0 SY-LSIND 0
SY-PAGNO 0 SY-LINNO 1
SY-COLNO 1
--------------------------------
Variables seleccionadas
---------------------------------
No existe ninguna información en el dump.

-------------------------------------
Llamadas / Eventos activos
-------------------------------------
No Tipo Nombre Programa Include Lı́nea
-------------------------------------------------------
1 ??? ??? ??? ??? 0
-----------------
Notas interna
------------------
The termination occurred in the function "ab_genprog" of the SAP

Basis System, specifically in line 845 of the module "abgen".
The internal operation just processed is " ".
Program name.........: "AQ99HA==========CAND1========= ".
Error message........: "The data object "T750B" does not
have a component called "PERNR". ".
----------------------------------------
Llamadas activas kernel SAP
----------------------------------------
AixStack at 0x100c3cb0
CTrcStack at 0x100c3fa0
rabax_CStackSave at 0x100683f0
ab_rabax at 0x1006f270
ab_genprog at 0x103fd33c
newload at 0x100dd164
ab_LoadProg at 0x100dd518
ab_dialg at 0x103558f0
dy_cdiag at 0x101fd310
ab_submit at 0x104ee7a8
ab_retdynp at 0x10351794
ab_run at 0x104eda34
dynpmcal at 0x104d62cc
dynppai0 at 0x104d7aec
dynprctl at 0x104d8cd0
dynpen00 at 0x104c0f30
Thdynpen00 at 0x100b4f14
TskhLoop at 0x100b9d7c
tskhstart at 0x100c2404
DpMain at 0x10016bb4
main at 0x100011fc
------------------------------------------------
Lista programas ABAP involucrados
------------------------------------------------
--------------------------------------------------------------
----------------------------
Lista tablas internas
---------------------------
------------------------------------------------------
Directorio tablas aplicación (contenidos)
------------------------------------------------------
Programa
Nombre........ Cont.....1....+....2....+....3....+....
---------------------------------------------------------
---------------------------------------------------
Directorio ámbitos datos (info gestión)
---------------------------------------------------
Programa
No .. Nombre........ Long Ofsg Tipo Next Fecha gen. H.gen.
---------------------------------------------------------------
0 not assigned 0 0 INVL 0

1 /%_LISTTABLES 6968 0 COMM 0
2 global stack 65536 0 GLST 0
--------------------------------------------------
Directorio ámbitos datos (contenidos)
--------------------------------------------------
Programa
No .. Nombre... Cont.....1....+....2....+....3....+....
---------------------------------------------------------
?
0 not assigned <initial>
1 /%_LISTTABLES |\0\0\00\0\0\0\0\0\0\0\0\0\0\0\0\0\
2 global stack | 0000
-----------------------------------------
ABAP/4 Bloques control CONT
-----------------------------------------
----------------------------------------------
Fin análisis error tiempo ejecución
----------------------------------------------
Capı́tulo 9
Gestión de spool
9.1. Concepto de spool

En cualquier entorno de gestión empresarial se produce una gran cantidad
de información que en muchas ocasiones interesa sacar a papel a través de
informes, listados, análisis. . . El spool es un almacén receptor de peticiones
de impresión que proporciona una serie de utilidades para controlar la salida
de información. Aunque se asocia directamente spool con imprimir en papel,
en SAP las posibilidades son más amplias: podemos enviar una orden de
spool por fax, o imprimirla en un fichero. Nosotros nos limitaremos a ver
el funcionamiento de la salida por impresora para lo cual lo primero que
debemos hacer es aprender cómo se instala una.
9.2. Instalación de una impresora

Con la transacción SPAD – pantalla de la figura 9.1 a la que llegaremos
a través de Herramientas→ CCMS→ Spool→ Gestión de spool – podemos
instalar dispositivos de salida en nuestro sistema R/3. Vamos a describir
la instalación de una impresora de tipo local a nivel de PC, es decir, una
impresora genérica en la que cualquiera puede imprimir pero a cada persona
que lo haga le saldrá la información por la impresora que tenga definida por
defecto en su servidor de presentación.
En el campo dispositivo de salida introduciremos el nombre que le vamos
a dar a la impresora y tras pulsar el boton Gestión total y el botón con el
icono de un folio en blanco llegaremos a la pantalla de la figura 9.2 en la que
definiremos los siguientes datos:
Tipo de dispositivo. Es lo más parecido a lo que en microinformática
se denomina driver de la impresora. Para la creacion de una impresoral
103
104 CAPÍTULO 9. GESTIÓN DE SPOOL
Figura 9.1: Transacción SPAD. Mantenimiento de dispositivos de salida
local elegiremos siempre el tipo SAPWIN. Este dispositivo precisa de un

programa llamado saplpd que forma parte de la instalación del frontend
de SAP. Cuando se imprime algo el sapgui ejecuta automáticamente el
programa saplpd y este recibe los datos a imprimir y se encarga de
enviarlos a la impresora.
Clase de dispositivo. Seleccionamos de la lista la opción Impresora

común.
Grupo de autorizaciones. Podemos restringir a los usuarios a que

puedan imprimir por determinadas impresoras. Esto es muy interesante
cuando disponemos de impresoras de alto rendimiento dedicadas a
la impresión de facturas, nóminas, etc. No nos interesara, en estos
casos, que ningún usuario pueda sacar listados por estas impresoras
interrumpiendo los largos procesos que suelen llevar a cabo. Como
estamos definiendo una impresora local para todo el mundo dejamos
este campo en blanco.
Modelo. Campo descriptivo para poner la marca y modelo de la

9.2. INSTALACIÓN DE UNA IMPRESORA 105
Figura 9.2: Datos generales para una impresora local
impresora.
Ubicación. Campo descriptivo para indicar al usuario donde se encuen-

tra fı́sicamente la impresora. Es útil rellenarlo cuando disponemos de
salas separadas para las impresoras a las que hay que dirigirse para
recoger la salida del spool.
Por último, pasamos a la pestaña marcada con la etiqueta Acomplam.

SPOOL host y nos mostrará la pantalla de la figura 9.3
Aquı́ se le dice como esta conectada la impresora al servidor SAP.
Elegiremos de la lista la opción F:Imprimir en front end que le marca
que debe enviar la información al PC para que sea este el que le de
salida. El campo impresora host debemos rellenarlo con el nombre DEFAULT
para indicarle que la orden de spool debe salir por la impresora que este
configurada por defecto en el PC. Una vez hecho esto sólo nos queda pulsar
el botón de grabar y ya podemos usar la impresora instalada.
Figura 9.3: Tipo de impresora para una impresora local
9.3. Como imprimir

Teniendo una impresora ya instalada podemos, desde cualquier pantalla
de listado, pulsar el icono de impresora de la barra de estándar de
herramientas y tendremos que rellenar las opciones que vemos en la figura
9.4.
El primer campo a rellenar es el nombre de la impresora por donde
queremos que salga nuestro listado1 . Este es el único campo obligatorio, pero
también podemos indicar otras muchas opciones que vemos a continuación.
La cantidad de copias que queremos sacar.
Si queremos todas las página o sólo un rango de ellas.
El nombre y el tı́tulo de la orden de spool. Será útil para luego buscarla

entre el spool o entre el montón de hojas impresas que salen por una
impresora compartida.
La salida inmediata o el almacenamiento en el spool.

1
En la pantalla viene con el nombre genérico de dispositivo de salida.
9.3. COMO IMPRIMIR 107
Figura 9.4: Ventana de diálogo para imprimir un listado

Podemos marcar el borrado de la orden tras la impresión correcta o,

por el contrario, dejar que la orden permanezca en el spool para futuras
reimpresiones.
La cantidad de dı́as que debe permanecer en el spool antes de ser

borrada por los jobs de mantenimiento.
La impresión de una portada previa con el tı́tulo de la orden de spool

y el destinatario y departamento al que pertenece. Estos ultimos datos
tienen sentido en una empresa en la que haya servicio de entrega de
impresiones, es decir, que no tenemos que ir a la impresora sino que
nos envı́an los papeles a nuestro puesto de trabajo.
La cantidad de lı́neas y columna que queremos sacar y por lo tanto el

formato de la página.
9.4. Operaciones sobre órdenes de spool

Para poder administrar todas las peticiones de spool que hacemos SAP
provee de la transacción SP01 que se encuentra en Herramientas→ CCMS→
Spool→ Control de salida. En ella nos encontramos inicialmente una pantalla
con criterios de seleccion como la de la figura 9.5.
Aquı́ podemos elegir las órdenes de spool por varios criterios; los
más habituales son el creador de la orden y la fecha. Tras pulsar F8
nos encontramos con un listado de las órdenes seleccionadas como el
de la figura 9.6. Este listado tiene la misma caracterı́stica que el de la
transacción de gestión de jobs; es un programa de selección, listado y gestión
simultáneamente.
Las operaciones que podemos hacer sobre una orden de spool incluyen
la creación de órdenes de salida, el cambio de los atributos, el borrado de
la orden o la visualización de su contenido. Esta última opción es realmente
interesante cuando queremos comprobar el resultado de un programa que se
ha ejecutado en proceso de fonfo, pero no queremos imprimirlo hasta ver
si ha salido lo que esperabamos. En cuanto a los atributos, en la figura 9.7
podemos ver algunos de los que se pueden cambiar. Básicamente son los
mismos que definimos inicialmente al crear la orden de spool (ver figura
9.4). Por ejemplo, es muy habitual comprobar tras la salida al papel que un
listado que tiene 132 columnas en sus atributos ha salido con letra pequeña
y en formato horizontal pero no llega a ocupar realmente más de 80. En ese
caso cambiaremos el campo edición por un X 65 80 para conseguir un listado
con letra más grande y en vertical y volveremos a repetir la salida de la orden.
9.4. OPERACIONES SOBRE ÓRDENES DE SPOOL 109
Figura 9.5: Transacción SP01. Selección de órdenes de spool
Figura 9.6: Transacción SP01. Listado de órdenes de spool

Una de las labores del administrador consiste en asegurarse que las

órdenes de spool olvidadas por los usuarios no llenan nuestra base de
datos. Para ello dispone del programa RSPO0041 que le permite eliminar
masivamente el spool que lleve más de n dı́as almacenado.
Figura 9.7: Atributos de una orden de spool

Capı́tulo 10
Gestión de usuarios y
autorizaciones
10.1. Modelo de seguridad en R/3

En cualquier sistema de gestión de información integrado se guardan datos
de diferentes áreas a los que sólo pueden acceder algunas personas. Estas
restricciones pueden darse por varios motivos:
Proteger datos que afecten a la estrategia de la empresa para no ofrecer

ventajas a la competencia.
Evitar fraudes en la contabilidad o en los cobros y pagos.
Obligación legal de proteger información ajena a la propia empresa

como los datos personales de sus empleados, las condiciones económicas
de los proveedores.
SAP contempla toda esta problemática implementando un modelo de

seguridad que permite proteger de una manera flexible los datos y las
operaciones que se hacen sobre ellos. En la figura 10.1 podemos ver un
esquema de los componentes de la seguridad en R/3.
En el lado derecho tenemos los objetos de autorización que se componen
de campos. Estos objetos representan lo que queremos proteger. Ejemplos de
objetos de autorización son:
S TCODE. Protege el código de transacción y contiene un sólo campo

que es la transacción. Es el más importante de todos porque todas
las operaciones que se hacen en SAP empiezan por el acceso a una
transacción.
111
112 CAPÍTULO 10. GESTIÓN DE USUARIOS Y AUTORIZACIONES
Figura 10.1: Componentes de la seguridad en R/3
S TABU DIS. Protección del contenido de tablas de customizing.

Contiene dos campos que son el grupo de autorizaciones de la tabla
(DICBERCLS) a la que se quiere acceder y la actividad (ACTVT) que
se quiere ejecutar (crear, modificar, borrar. . . )
F BKPF BUK. Protección de la contabilización de documentos por

sociedad financiera. Se compone de dos campos; la sociedad (BUKRS) a
cuyos documentos contables queremos acceder y la actividad (ACTVT)
que se quiere hacer.
En el lado izquierdo de la figura vemos la estructura modular que va desde

la autorización simple sobre un único objeto de autorización hasta el maestro
de usuarios que son los que acceden al sistema. Veamos lo que representa cada
uno de los niveles:
Autorizaciones. Una autorización consiste en una asignación de

valores a los campos de un objeto de autorización. Por ejemplo,
crearemos una autorización para el objeto S TCODE que tenga el
valor FB01 para el campo TCODE. De está manera el usuario que
tenga asignada esta autorización podrá acceder a la transacción de crear
documento contable. También tendremos que crear otra autorización
10.2. MANTENIMIENTO DE USUARIOS 113
sobre el objeto F BKPF BUK con los valores 1000 para BUKRS y 01
para ACTVT con la que puedan completar la operación de contabilizar
para la sociedad financiera 1000.
Perfiles. Un perfil es simplemente la agrupación de varias autoriza-

ciones que hayamos creado anteriormente. El perfil es la unidad mı́nima
de seguridad que le podemos asignar a un usuario, es decir, la única
forma de asignar las dos autorizaciones del ejemplo anterior es incluir-
las en un perfil que llamaremos CONTABLE e incluir este perfil en los
usuarios.
Grupos de actividad. Son las agrupaciones de transacciones y

actividades que se crean con el generador de perfiles. Estos grupos
de actividad contienen internamente perfiles (que a su vez contienen
autorizaciones) y se asignan directamente a los usuarios.
Usuarios. Para que un empleado tenga acceso a los datos de gestión

de la empresa debe disponer de un código de usuario en R/3. Este
usuario tendrá asignados unos grupos de actividad o unos perfiles de
autorización (o ambos) para poder realizar las tareas que exige su
función o puesto de trabajo.
10.2. Mantenimiento de usuarios

Para la creación y mantenimiento de usuario R/3 dispone de la transac-
ción SU01 (Herramientas→ Gestión→ Actualizar usuarios→ Usuarios). En
la pantalla correspondiente a la figura 10.2 escribiremos el código del usuario
y pulsando uno de los botones de la barra de aplicación o escogiendo una
de las opciones del menú Usuario podemos realizar diversas acciones como
crear, modificar, cambiar clave acceso, bloquear. . .
Pulsando sobre el botón con el icono de un folio en blanco vamos a crear
un nuevo usuario en el sistema. Vemos en la figura 10.3 las siete pestañas
que componen el registro maestro de un usuario. Estas son:
Dirección. Se graban en este apartado datos personales como el

nombre, apellidos, departamento, teléfono. . . . En el campo edición
veremos el nombre tal y como aparecerá en los listados o en otras
transacciones.
Datos logon. Es obligatorio indicar una clave inicial con la que

accederá el usuario, aunque en su primera conexión se le pedirá que
la cambie. También podemos limitar la validez temporal de manera
Figura 10.2: Pantalla inicial de la actualización de usuarios
que podemos tener empleados que accedan a nuestro sistema hasta

determinada fecha como puede ser el fin de su contrato o cesión a
nuestro departamento.
Valores fijos. En esta pestaña definimos el menú inicial de entrada
al sistema, la impresora SAP y algunos parámetros de impresión por
defecto, y el formato en que debe ver el usuario las fechas y los importes
en todas las transacciones SAP. Esta última opción, junto con la del uso
horario, es vital para empresas multinacionales que tienen empleados
en diversos paı́ses.
Parámetros. Existe la posibilidad de asignar parámetros por defecto
para multitud de campos de todos los módulos de SAP. Si un empleado
solo realiza entradas de mercancı́as en el centro 1000, es muy útil
asignarle ese valor en el parámetro correspondiente consiguiendo que
en todas las pantallas de R/3 en la que aparezca el campo centro, éste
se encuentre relleno automáticamente con el valor 1000.
papeles y perfiles. Las operaciones a las que esta autorizado un
usuario vienen determinadas por los valores que le ponemos en estas
dos pestañas. Al asignarles un papel le estamos añadienlo perfiles
también, pero existe la posibilidad de incluir perfiles manualmente. Esta
posibilidad se conserva por compatibilidad con versiones anteriores pero
no es el modo de trabajo habitual desde la versión 4.6A.
Grupos. A la hora de descentralizar el mantenimiento de un
10.2. MANTENIMIENTO DE USUARIOS 115
Figura 10.3: Datos de direccion del maestro de usuarios

número enorme de usuarios debemos agruparlos asignándoles la

pertenencia a uno o varios grupos. De esta manera podemos autorizar
a diversos administradores a gestionar los usuarios que pertenezcan a
determinados grupos.
10.3. Generador de perfiles

Debido a la gran complejidad que supone la creación manual de perfiles
y autorizaciones, desde la version 3.1G de R/3, existe el generador de
perfiles. Las ventajas que aporta para el administrador la utilización de esta
herramienta son múltiples aunque la más destacable es que ya no necesita
conocer o investigar la funcionalidad de las transacciones que incluyen en
los perfiles de usuario. El generador de perfiles incluyen una base de datos
que relaciona cada una de las transacciones de R/3 con los objetos que
comprueba. En la versión 3.0F y anteriores, la creación de un perfil de
seguridad exigı́a un tedioso trabajo de búsqueda de objetos que chequea
cada transacción.
Para crear un papel disponemos de la transacción PFCG que nos muestra
una pantalla como la de la figura 10.4.
Figura 10.4: Transaccion PFCG. Mantenimiento de papeles

10.3. GENERADOR DE PERFILES 117
Al pulsar el botón de crear pasaremos a la pantalla de la figura 10.5 en

la que vemos las diferentes partes de la creación de un grupo de actividad
repartidas en cuatro pestañas. En la primera de ellas rellenamos unicamente
un descripción corta del papel y también podemos completar el campo de
descripción inferior en el que podemos indicar instrucciones sobre a quién se
debe asignar este perfil o cual es su función especı́fica.
Figura 10.5: Descripcion del papel
Al pasar a la pestaña menú (ver figura 10.6) vemos unos botones que
nos permiten incluir transacciones, informes o direcciones web en el grupo
de actividad. Observamos en la figura como se ha incluido ya la transacción
de contabilizar documento (perteneciente al módulo FI). Esto implica que
el usuario al que se le asigne este perfil podrá ejecutar la transacción FB01,
pero no hemos determinado aún para que sociedades financieras, cuentas o
deudores podrá hacerlo.
En la figura 10.7 tenemos la pantalla de asignación de valores a los objetos
de autorización a la que se llega a través de la pestaña Autorizaciones. Son
cuatros los objetos de la gestión financiera los que chequea esta transacción
Figura 10.6: Transacciones asignadas a un papel
y habrá que dar los valores correspondientes para el grupo de actividad.

Por ejemplo, en el objeto grupo de autorización de cuentas para deudores
podemos poner un 01 en actividad y un * en grupo de autorizaciones con lo
que estamos permitiendo crear para todos los grupos de deudores. El resto de
los objeto de autorización debe ser completado también, solo cuando hayamos
asignado valores a todos tendremos los semáforos en verde, indicación de que
podemos grabar el papel.
Por último, despúes de completar la grabación del grupo, tenemos la
posibilidad de asignárselo a uno o varios usuarios. En la figura 10.8 conviene
fijarse en que tenemos los semáforos de las pestañas menú y autorizaciones en
verde, indicándonos que los pasos anteriores se han procesado correctamente.
Es entonces, cuando podemos poner en la tabla de usuarios los códigos (el
nombre nos lo rellena el propio programa) a los que queremos incluir el
papel y la fecha de validez de la asignación. Esta fecha de validez tiene la
misma función que la que vimos en el maestro de usuario, es decir, nos puede
interesar autorizar a un usuario a hacer determinadas cosas en el sistema
durante un tiempo limitado de tiempo. Para evitar el tener que acordarnos
de quitar la autorización cuando llegue el dı́a, ponemos la fecha de validez y
entonces perderá la autorización al dia siguiente.
10.3. GENERADOR DE PERFILES 119
Figura 10.7: Asignación de valores a los objetos de autorización
Figura 10.8: Asignacion de un papel a usuarios

Capı́tulo 11
Sistema de transporte
El sistema R/3 dispone de una herramienta que nos permite pasar objetos
de un entorno (por ejemplo, desarrollo) a otro (por ejemplo, producción
). Los objetos a pasar pueden ser definición y contenido de tablas nuevas,
programas nuevos, datos de customizing e incluso modificaciones al estándar.
Este traspaso de información entre un sistema R/3 y otro nos facilita
el mantenimiento del sistema productivo ya que con ello evitamos tener
que duplicar el trabajo de programación o repetir la inclusión de datos
de customizing. Todo ello redunda en una mayor productividad y en una
minimización de riesgos ya que la información, antes de ser insertada en el
sistema productivo, es probada en el sistema de desarrollo y su traspaso no
será realizado hasta que el responsable del proyecto dé el visto bueno.
La herramienta que permite este traspaso de información entre sistemas
R/3 es el llamado sistema de transportes.
11.1. Órdenes de transporte

El sistema de transporte se emplea, generalmente, para trasladar objetos
desde el sistema de desarrollo hasta el sistema de producción; obviamente
si no existe tal separación de sistemas, es decir, si sólo se dispone de un
único sistema la utilidad del sistema de transportes se reduce a traspasar
información dependiente de mandante de un mandante a otro dentro del
mismo sistema. El sistema de transporte puede usarse para:
Borrado de objetos obsoletos en el sistema destino.
Inserción de nuevos objetos en el sistema destino.
Modificación de objetos ya existentes en el sistema destino.
121
122 CAPÍTULO 11. SISTEMA DE TRANSPORTE
Cuando se crea o modifica un objeto en el sistema de desarrollo, el

sistema propone un código único para identificar la creación o modificación
de ese objeto, siempre y claro está que el mandante donde se esté trabajando
esté configurado para registrar cualquier modificación (ver capı́tulo 12). El
código propuesto conforma lo que se denomina Orden de Transporte y a ella
se asociarán los objetos que el usuario cree o modifique, de tal manera que
el sistema bloqueará, dependiendo de la naturaleza de la orden, esos objetos
para que nadie más que el propietario de esa orden de transporte pueda
modificar esos objetos mientras la orden no esté liberada, es decir preparada
para ser transportada.
La nomenclatura de una orden de transporte es:
<SID>K9nnnnn
donde <SID> es el nombre de la base de datos del sistema donde estamos

trabajando y 9nnnnn es un número secuencial que irá creciendo desde 900000
hasta 999999 a medida que vayamos creando nuevas órdenes de transporte.
El sistema de transportes no asocia directamente los objetos creados o
modificados a una orden de transporte sino que lo hace a través de las tareas;
las tareas deben obligatoriamente pertenecer a una única orden de transporte
y al igual que ellas siguen el mismo código secuencial de tal manera que nunca
pueden existir varias órdenes o tareas con el mismo código. Las tareas, al
igual que las órdenes, están asignadas a un usuario y su finalidad es mejorar
la gestión de los cambios introducidos en el sistema ya que una orden puede
albergar varias tareas pertenecientes o no al mismo usuario.
Ejemplo: Supongamos un sistema SAP R/3 de desarrollo cuyo SID es

D10 en el cual el usuario USUARIO1 crea un nuevo programa llamado
ZPROGRAMA y una nueva tabla llamada ZTABLA. Supongamos que es
la primera orden de transporte que se genera en ese sistema por lo que su
código será D10K900000, y que se usa la misma orden para englobar los dos
objetos.
Supongamos el mismo sistema pero el caso de introducir cada objeto en
una orden distinta, por ejemplo D10K900000 y D10K900002.
La diferencia básica entre un caso y otro será que el transporte al sistema
productivo de la primera orden conllevará el transporte de los dos objetos –
programa y tabla – a la vez, mientras que en el segundo caso el transporte
de una orden conllevará el transporte sólo del objeto asociado.
Será tarea del propietario de la orden el decidir de cuantos objetos se va a
componer cada orden de transporte. No se deberá crear una orden para cada
objeto a modificar o crear ya que esto complicará de manera excesiva nuestra
11.1. ÓRDENES DE TRANSPORTE 123
Figura 11.1: Esquema de una orden de transporte
Figura 11.2: Esquema de ordenes de transporte

labor de gestión de las órdenes de transporte; tampoco se deberá asignar una

única orden de transporte a todos los objetos que vayamos a crear o modificar
ya que ello puede llegar a hacer inmanejable la orden debido a su tamaño.
Se deberá, por lo tanto, llegar a un término intermedio de tal forma que
incluyamos en una orden los objetos que puedan estar relacionados, bien
debido a su naturaleza, bien porque pertenezcan al mismo proyecto.
11.2. Clases de desarrollo

Cuando nos disponemos, en el sistema de desarrollo, a crear nuevos
objetos con las herramientas de desarrollo apropiadas, el sistema antes de
asignarle una orden de transporte nos pedirá asociar el nuevo objeto por
crear a una Clase de Desarrollo.
Las clases de desarrollo no son más que agrupaciones lógicas de objetos
que, además, tienen asignada internamente una ruta de transporte, es decir,
un sistema origen y un sistema destino de transporte. Al asociar un objeto
a una clase de desarrollo estaremos, implı́citamente, asignándole la ruta de
transporte a seguir cuando la orden asociada a ese objeto sea transportada.
Todos los objetos estándar del sistema SAP R/3, ya sean programas, tablas,
ayudas de búsqueda, etc, tienen asociado una clase de desarrollo estándar de
SAP.
Los objetos nuevos a crear deberán asociarse a clases de desarrollo nuevas,
que se distinguirán de las estándar por el primer carácter de su identificación,
que siempre deberá ser una ”Z”. Como caso excepcional podremos asignar a
nuestros objetos la clase de desarrollo $ TMP, la cual es denominada temporal
o local y tiene como particularidad el hecho de que los objetos a ella asociados
no son transportados a ningún sistema destino, y por lo tanto el sistema no le
asigna ninguna orden de transporte. Esta clase de desarrollo se deberá asignar
a objetos que sean de pruebas y que no deseemos que vayan a pasar nunca
a formar parte del sistema de producción. Hablamos entonces de objetos
locales privados o temporales. Ver figura 11.3.
11.3. Tipos de órdenes de transporte

El sistema SAP R/3 provee distinto tipo de órdenes de transporte para
cada tipo de cambio que se desee realizar en el sistema:
Órdenes de customizing A la hora de implementar el modelo de empresa

en SAP R/3 se necesita establecer ciertos datos en la parametrización
del sistema. La parametrización afecta primordialmente a los procesos
11.3. TIPOS DE ÓRDENES DE TRANSPORTE 125
Figura 11.3: Clase de desarrollo
de negocio y es, por ello, dependiente de mandante. Si un mandante

ha sido establecido con grabación automática de cambios (ver capı́tulo
12), una tarea y una orden de customizing son creadas automáticamente
cuando un usuario en un sistema R/3 realiza cambios de customizing.
Ordenes de modificación transportables A la vez que cambios en el

customizing, será también necesario desarrollar nuevas aplicaciones
que se ajusten perfectamente a las necesidades de la empresa. Esto
permite moldear el sistema R/3 a cualquier necesidad. Estos cambios,
pertenecientes al área de desarrollo y que afectarán básicamente a
programas y tablas, son independientes de mandante; esto significa
que tienen efecto en todo el sistema. La creación de nuevos objetos, o
la modificación de los que proporciona SAP son grabados, de manera
similar al customizing, en tareas asignadas a órdenes de modificación
transportables.
Órdenes de modificación locales También se pueden realizar cambios

locales; se distinguen de los anteriores en que estos cambios no pueden
ser transportados a otros sistemas.
11.4. Estados de una orden de transporte y

sus tareas
Desde que se crean una orden de transporte y sus correspondientes tareas
hasta que son liberadas (fase previa para el transporte de dicha orden a otro
sistema), éstas pasan por dos estados:
Modificable Cuando la orden o tarea es creada para ser asociada a objetos

de desarrollo o de customizing, ésta aparece con status modificable;
es decir, permite la inclusión y eliminación de objetos asociados. Si se
trata de una orden, ésta permite la asignación o borrado de tareas; si
se trata de una tarea, esta permite la asignación o desasignación de
objetos del sistema .
Liberada El paso previo del transporte consistirá en la liberación de
la orden y sus tareas asociadas. Para poder liberar una orden, se
deberá primero liberar todas sus tareas asociadas. La liberación de una
tarea consiste en cerrarla para posteriores modificaciones; es decir, no se
podrá asignar nuevos objetos a esa tarea ni desasignar los ya existentes.
La liberación de una orden consiste en cerrarla para posteriores tareas;
no se podrá crear ninguna nueva tarea asociada a esa orden ni se podrán
borrar las ya existentes.
Una orden puede permanecer en status Modificable aunque todas sus

tareas asociadas estén en estado liberado; ello nos permitirá asignarle nuevas
tareas con status modificable para poder seguir trabajando con ella hasta
que liberemos la orden.
La liberación de una orden de transporte además de bloquearla para
cualquier modificación futura, realiza el export de la orden. El export de
la orden consiste en la creación de dos ficheros a nivel de sistema operativo
– fichero data y fichero cofiles –. En estos ficheros se produce la exportación
de los datos fuera de su base de datos, de tal manera que puedan ser
transportados al sistema destino. Ası́ pues, el transporte no es más que la
exportación de información fuera de la base de datos de origen a fichero del
sistema operativo y la importación de dicha información en la base de datos
destino.
Los dos ficheros creados en la exportación de una orden de transporte
tienen la siguiente ubicación en el sistema operativo:
Fichero data
Ubicado en /usr/sap/trans/data; es el que contiene toda la información
asociada a la orden de transporte; cuantos más objetos estén asociados a la
11.5. CUSTOMIZING ORGANIZER Y WORKBENCH ORGANIZER 127
Figura 11.4: Esquema pasos del transporte
orden de transporte a liberar, mayor será el fichero data a crear y mayor el

tiempo que llevará su creación, es decir, la exportación. La nomenclatura del
fichero data, siendo la de la orden liberada <SID>K9nnnnn, puede ser:
D9nnnnn.<SID>
R9nnnnn.<SID>
Fichero cofiles
Ubicado en /usr/sap/trans/cofiles; es un fichero de control necesario
para el transporte; su tamaño es mucho menor que el data ya que no contiene
los datos de la orden. La nomenclatura del fichero cofiles, siendo la de la orden
liberada <SID>K9nnnnn, es:
K9nnnnn.<SID>
11.5. Customizing organizer y workbench

organizer
Para gestionar las órdenes de transporte y sus tareas podremos usar el
customizing organizer – CO – y el Workbench Organizer – WBO –. Tanto
uno como otro se pueden acceder a través de las transacciones SE09 como
SE10 y desde ellas se puede gestionar las órdenes de transporte relativas a
desarrollo (órdenes de modificación tanto locales como transportables; esta

herramienta la usarán los desarrolladores) y las de Customizing (herramienta
que usarán los consultores).
Figura 11.5: Pantalla principal Workbench Organizer
En ambas herramientas la pantalla de selección dispone como parámetro

principal del usuario, que por defecto está relleno con el nombre del
usuario con el que nos hemos conectado al sistema. Todas las órdenes
que visualicemos con esta herramienta serán las asociadas al usuario arriba
indicado. Como parámetros adicionales podemos elegir visualizar las órdenes
modificables y las liberadas o sólo uno de los dos tipos. Además, también
podemos restringir por fechas para evitar que el listado sea demasiado largo
si es que hemos trabajado con muchas órdenes de transporte. En el caso del
customizing organizer tenemos, además, la posibilidad de visualizar sólo las
órdenes de customizing o sólo las de workbench o ambas a la vez.
Una vez elegidos los parámetros de selección del CO o del WBO
pulsaremos el botón de visualización y accederemos a una pantalla como
la mostrada en la figura 11.6.
11.5. CUSTOMIZING ORGANIZER Y WORKBENCH ORGANIZER 129
Figura 11.6: Órdenes de transporte
Desde esta pantalla podremos identificar qué objetos están asociados a

qué órdenes de transporte sin más que ir desplegando la estructura en árbol
presentada. Esta estructura en árbol nos muestra en un primer nivel la orden
de transporte, en un segundo nivel las tareas asociadas a esa orden y en un
tercer y último nivel los objetos asociados a esa tarea.
Tanto el primer como segundo nivel tienen asociado un propietario que
es mostrado a la derecha de la orden y tarea. El propietario de la orden no
tiene por qué coincidir con el propietario de las tareas asociadas ya que el
propietario de esa orden puede crear tareas asociadas y repartir la propiedad
de ellas entre los usuarios que considere adecuados. Esto puede ser de utilidad
en el caso del desarrollo de una nueva aplicación donde el jefe de proyecto
crea una única orden, si ası́ lo considera oportuno, y crea una tarea asociada
a esa orden por cada desarrollador involucrado en el proyecto asignando la
propiedad de cada tarea a cada uno de los desarrolladores. De esta manera,
cada desarrollador irá asignando sus objetos a su tarea con lo que no se
producirá solapamiento. Una vez que los desarrolladores acaben su trabajo, el

jefe de proyecto les indicará que liberen sus tareas (la liberación sólo la puede
realizar el propietario), pero el jefe de proyecto será el que tenga la decisión
de cuándo liberar la orden, de la cual él es propietario. La exportación de la
orden a fichero no se producirá hasta que el propietario de la orden ejecute
la liberación de la misma.
Desde esta pantalla podremos ejecutar la liberación de cualquier orden de
la que seamos propietarios. La liberación debe llevar siempre esta secuencia:
Ejecutar la liberación de todas las tareas asociadas a esa orden
Ejecutar la liberación de la orden
Además de la liberación podremos borrar asignaciones de objetos a tareas

con estatus modificable. Esta opción nos permite eliminar la asignación de
un objeto dentro de una tarea sin más que posicionar el cursor en el objeto
deseado y pulsar a continuación la opción de borrar. Esta opción no borra
fı́sicamente el objeto, sólo su asignación a una tarea, y deberá ser usado
cuando, por error, hayamos incluido un objeto en una tarea no deseada. Esta
opción de borrado también puede ser útil para eliminar tareas con estatus
modificable de órdenes, la única restricción que nos impone el sistema es que
esas tareas deben estar vacı́as. La opción de borrado – bien de objetos o de
tareas – sólo es aplicable cuando la orden y la tarea asociada tienen el estatus
modificable, es decir, que no se ha liberado todavı́a. Un tarea ya liberada no
permite la desasignación de sus objetos mediante la opción de borrado. En
esta pantalla, además, podremos cambiar el texto descriptivo asociado a una
orden con el botón de modificar.
Otra opción muy importante disponible tanto en la pantalla inicial del
WBO y del CO ası́ como en las pantallas donde se muestran las órdenes
de transporte seleccionadas de los dos organizers es la opción crear orden.
Eligiendo esta opción el sistema nos muestra la pantalla de diálogo que vemos
en la figura 11.7.
Como campo principal se nos pide que introduzcamos una descripción
para la orden a crear cuya codificación la dará automáticamente el sistema
al crearla. El sistema, además, crea la orden con una única tarea cuyo
propietario es el mismo que el que ha creado la orden; esta opción se puede
cambiar. Podremos introducir tantas tareas como queramos sin más que
asignar nuevos empleados a las tareas a introducir en la orden – el sistema
introducirá tantas tareas en la orden como empleados se haya especificado –.
A esta opción de creación de órdenes de transporte también se puede
acceder desde fuera de la transacción SE09 y SE10 cuando modificamos o
11.6. TRANSPORTE MANUAL DE ÓRDENES 131
Figura 11.7: Creación de una orden de transporte
creamos un nuevo objeto de desarrollo. El sistema nos pide asignarle una

orden ya creada o crear una nueva.
11.6. Transporte manual de órdenes

Una vez que una orden ha sido liberada, ésta se encuentra preparada para
ser importada al sistema destino.
El programa de control del transporte se encuentra a nivel del
sistema operativo; es el llamado tp.exe que está junto con el resto
de programas ejecutables de SAP que componen el Kernel en la ruta
/usr/sap/<SID>/SYS/exe/run, donde <SID> es el directorio que tiene igual
nombre que la base de datos de SAP instalada en el servidor.
El programa tp se debe ejecutar desde la ruta /usr/sap/trans/bin, en
el servidor y directorio adecuado dependiendo del sistema operativo:
En sistemas UNIX, este directorio del transporte deberá estar

compartido via NFS para todos los entornos que conforman la ruta del
transporte. Es por ello por lo que podremos acceder a este path desde
cualquier servidor al que nos conectemos desde el sistema operativo
(por ejemplo via telnet).
En sistemas Windows NT, esta directorio de transporte deberá estar

configurado como compartido para que desde todos los entornos
esté disponible, sin embargo sólo será local para uno de ellos.
Accederemos a través del emulador MSDOS en el servidor donde la
ruta es local.
Presentamos a continuación la estructura en árbol del sistema operativo

UNIX que es necesaria para el transporte y explicaremos para qué sirve cada
directorio:
/usr/sap/trans/bin Directorio desde donde se lanza el programa

de control del transporte, tp.
/usr/sap/trans/data Directorio donde se almacenan los ficheros
data generados en la exportación de datos
desde la base de datos que se realiza durante
la liberación de una orden.
/usr/sap/trans/cofiles Directorio donde se almacenan los ficheros
cofiles generados en la exportación de datos
desde la base de datos que se realiza durante
la liberación de una orden.
/usr/sap/trans/log Directorio donde se almacenan en ficheros los
logs de cada una de las órdenes de transporte
que se importan al sistema destino.
/usr/sap/trans/buffer Directorio donde se almacena un listado con
todas y cada una de las órdenes de transporte
que han sido liberadas desde el sistema origen.
Antes de poder importar al sistema destino, el
programa de control del transporte chequea
que la orden solicitada se encuentra en el
listado mencionado y que está todavı́a sin
transportar; si es ası́, se ejecuta el transporte
al sistema destino. Las órdenes, por defecto,
al ser liberadas son añadidas al ”buffer”por lo
que no será necesario incluir ninguna orden
en este listado a no ser que expresamente
hayamos eliminado su entrada de dicho listado
o que la orden ya haya sido transportada y
queramos volver a ejecutar su transporte.
Veamos a continuación cómo deberemos usar el programa de control para

gestionar el transporte de las órdenes ejecutándolo desde el directorio bin
mencionado antes:
tp showbuffer <SID>
Nos muestra el listado de órdenes incluı́das en el buffer. En lo que sigue,

<SID> se refiere al nombre del sistema destino del tranporte. Las órdenes que
ya han sido transportadas al sistema destino aparecen con el texto already
imported.
Figura 11.8: Listado de órdenes transportadas y liberadas
Todas las ejecuciones del comando tp, independientemente del argumento

asociado, devuelven un código de retorno cuyos valores pueden ser:
0 → Operación ejecutada con éxito
4 → Operación ejecutada con advertencias
8 → Operación ejecutada con errores.
Un valor mayor que 8 también indicará que la operación no se ha realizado

con éxito.
tp delfrombuffer <orden> <SID>
Elimina del listado del directorio buffer la referencia a la orden de

transporte seleccionada. No borra la orden fı́sicamente, pero impide que se
pueda transportar esa orden.
tp addtobuffer <orden> <SID>
Añade la orden seleccionada al buffer, dejando la orden preparada para

ser transportada. Esta operación, por defecto, no es necesario ejecutarla a
no ser que una orden sea eliminada con el comando anterior y deseemos
posteriormente transportarla.
tp import <orden> <SID>
Importa al sistema destino la orden seleccionada, y lo hace en el

mandante cuyo nombre es el mismo que en el sistema origen. Si el mandante
destino de la orden no coincide con el mandante origen de la orden,
se deberá obligatoriamente especificar el mandante destino con la opción
client=<mandante destino> añadida después del <SID>.
Figura 11.9: Transporte de una orden a un sistema destino
tp import all <SID>
Importa al sistema destino especificado todas las órdenes que hayan

sido liberadas y que, por tanto, se encuentran en el buffer. Las órdenes
son importadas por orden de aparición en buffer, por lo que primero se
transportarán las órdenes que han sido liberadas primero. Si el mandante
destino no coincide con el origen, se deberá usar la opción especificada en el

caso anterior.
No se recomienda el uso de esta opción ya que podemos desear importar
al sistema destino en un orden distinto al que han sido liberadas las órdenes
que se encuentran en el buffer, y este comando tiene un orden de transporte
preestablecido.
tp import <orden> <SID> client=<nnn> u1
La opción u1 es el modo incondicional de sobreescritura. Habrá que

especificarlo obligatoriamente si deseamos transportar al sistema destino una
segunda vez una orden. Esto es ası́ porque el sistema chequea que la orden ya
ha sido transportada previamente y no vuelve a ejecutar la importación. Para
obligarle a sobrescribir la misma orden que se ha transportado previamente,
será necesario especificar la opción u1.
Figura 11.10: Esquema ejemplo del transporte de una orden
Veamos a continuación un ejemplo. Supongamos un sistema de desarrollo

D10 en un servidor NT llamado devsap10 y un sistema de producción P10
en otro servidor NT llamado prodsap10. En ambos entornos está establecida
la ruta del transporte D10 → P10 a través de la clase de desarrollo ZDEV.
Estableceremos el directorio de transporte C:\usr\sap\trans localmente en
el servidor de producción, prodsap10.
Supongamos que creamos en el mandante 101 de D10 un programa

ZREPORT que queremos pasar al mandante 110 de producción. Al crearlo,
le asignaremos la clase de desarrollo ZDEV y el sistema nos propondrá un
código para su orden de transporte, por ejemplo D10K902010.
Al liberar esta orden, el sistema de desarrollo se conecta a :
\\prodsap10\usr\sap\trans
para crear en los subdirectorios data y cofiles los ficheros D902010.D10

y K902010.D10 correspondientemente. Abriendo una ventana de MSDOS en
el sistema de producción, sistema destino del transporte, ejecutamos:
C:\usr\sap\trans\bin\tp showbuffer P10
para comprobar que la orden D10K902010 se encuentra en el buffer; si

acaba de ser liberada, aparecerá la última del listado. Una vez comprobado
que la orden se encuentra en el buffer del sistema de producción ejecutaremos
el transporte al mandante 110. Como el mandante destino y origen no
coinciden deberemos usar la opción client=<SID>.
C:\usr\sap\trans\bin\tp import D10K902010 P10 client=110
Una vez que este comando ejecute la importación y su código de retorno

sea 0, el programa ZREPORT estará disponible en el sistema de producción.
11.7. Log del transporte

Existe dentro del sistema SAP R/3 una herramienta que nos proporciona
mucha más información sobre el transporte de una orden que el simple
código de retorno devuelto por el comando tp. Tal código de retorno nos
informa si el transporte se ha ejecutado correctamente, o si por el contrario ha
ocurrido algún problema; sin embargo no nos informa qué tipo de problema
ha ocurrido. La herramienta del log del transporte está disponible tanto en la
transacción SE09 como en la SE10. Podemos pulsar el botón de visualización
individual – aparece asociado a un icono de gafas – en la barra de aplicaciones
si conocemos el número de orden cuyo log queremos consultar:
También podemos rellenar los parámetros de selección explicados en la
sección del WBO y CO para, posteriormente, buscar la orden en el listado
que nos aparezca en pantalla y una vez posicionado el cursor sobre la orden
deseada, pulsar la opción log del transporte – asociado a una hoja y gafas –
dentro de la barra de aplicaciones.
11.7. LOG DEL TRANSPORTE 137
Figura 11.11: Visualización individual de órdenes
Figura 11.12: Log del transporte de una orden
Las dos opciones nos llevan a la misma pantalla. En ella, podemos ver
desde qué sistema se ha producido el export ası́ como el import en el sistema
destino con cada uno de sus pasos.
La importación se realiza en varios pasos, dependiendo su número del
tipo de objeto a transportar. Desglosando la estructura en árbol del log
podemos obtener distintos niveles de información, cada vez más detallados.
Una vez que hemos visto en qué paso del transporte se ha producido un error,
haremos doble click sobre esa lı́nea para acceder a un listado completo del
log en ese paso. Esto nos sirve para saber por qué razón se ha producido un
error en el transporte y cómo habrá que resolverlo. Los errores más comunes
son de información incompleta en el sistema destino para poder activar las
modificaciones recién transportadas.
Un ejemplo puede ser que el código fuente de un programa que
queramos transportar al sistema destino del transporte haga referencia a
una tabla cuya definición se encuentra en otra orden de transporte, todavı́a
sin transportar. Si transportamos primero la orden del código fuente, la
importación fallará devolviendo un código de retorno 8. Si visualizamos el
log del transporte de dicha orden veremos que el paso que ha fallado ha sido
la generación del código fuente por hacer referencia a una tabla que todavı́a
no existe en el sistema destino. Lo que deberemos hacer será, pasar la orden
donde se encuentra la definición de la tabla a la que se hace referencia en el
programa y, posteriormente, transportar de nuevo la orden que ha fallado –
primero deberemos añadirla manualmente de nuevo al buffer –.
Capı́tulo 12
Gestión de mandantes
Como ya se vio en el capı́tulo 2, los datos en la base de datos de SAP R/3

se dividen en dependientes de mandante y en independientes de mandante.
Un mandante es una unidad contable de negocio independiente que
incluye, además una hoja de balance también independiente. La imple-
mentación del modelo de empresa basado en los requerimientos de la empresa
se conocen como customizing o parametrización. El customizing, dependien-
do del tipo de datos a los que afecte, se puede dividir en dependiente o en
independiente de mandante.
También vimos en el capı́tulo 2 que un usuario, para trabajar con SAP
R/3, necesita conectarse a un mandante y lo que ello significaba. En este
capı́tulo vamos a profundizar en el concepto, caracterı́sticas y mantenimiento
de los mandantes en un sistema SAP R/3.
El sistema SAP R/3, cuando es instalado en los servidores, viene provisto
con mandantes estándar, es decir preconfigurados. Los mandantes estándar
son el 000, 001 y 066. En sistemas SAP R/3 destinados a la formación y
educación cuyo nombre es IDES existe además de los anteriores el mandante
800. Estos mandantes se distinguen principalmente de los anteriores por
estar ya parametrizados, es decir por tener implementados en cada uno de
los mandantes la modelización de una o varias empresas modelo además de
incluir datos de las actividades de negocio de cada una de las empresas.
Estos mandantes vienen provistos con unos usuarios estándar con
autorización global, es decir, sin restricciones, que en general, no deberán
ser usados para conectarse al sistema salvo por el administrador y que sea
estrictamente necesario. Estos usuarios son SAP* , DDIC y EARLYWATCH
(este último sólo existe en el mandante 066) .
139
140 CAPÍTULO 12. GESTIÓN DE MANDANTES
12.1. Creación de un nuevo mandante

Los mandantes estándar bajo ningún concepto deberán ser usados como el
mandante de trabajo de la empresa. Estos mandantes, deberán permanecer en
el sistema sin ser modificados ni borrados y sin que se creen nuevos usuarios,
a excepción del administrador del sistema, para que se conecten a ellos.
Es por ello, por lo que una de las primeras tareas del administrador
será la creación de un nuevo mandante cuyo destino final puede ser de test,
de producción, de integración. . . dependiendo del sistema SAP R/3 con el
que estemos tratando y de los requerimientos de la empresa.
La creación de un nuevo mandante, en general, se realizará como copia
de uno ya existente. Se hará copia del 000 si se quiere partir de cero o
copia de alguno ya existente si ya hemos creado alguno previamente, se han
introducido datos en él y necesitamos una copia de él con datos incluidos.
Las copias de mandante pueden ser Locales (los mandantes fuente y
origen pertenecen al mismo sistema), Remotas (los mandantes fuente y origen
pertenecen a sistemas distintos), o a través de un export de mandante (la
información del mandante se exporta a fichero por medio de órdenes de
transporte).
Cuando el sistema origen y el destino sean diferentes se deberá tener
cuidado de copiar mandantes sólo entre sistemas SAP R/3 que dispongan de
la misma versión de SAP R/3, de otra manera una copia de mandante puede
dejar inconsistente por completo el sistema destino.
Un mandante es creado en dos pasos. El primer paso permite que el
nuevo mandante sea reconocido por el sistema, dándose de alta, además,
importantes parámetros básicos. El segundo paso (descrito en la siguiente
sección) llena el mandante de datos; sólo después de este paso el mandante
estará plenamente operativo.
El primer paso consiste, realmente, en dar de alta el mandante en la
tabla T000, que es la tabla donde están referenciados todos los mandantes
activos en el sistema. Este alta en la tabla T000 se realiza a través de la
transacción SCC4 o a través del menú general Herramientas→ Gestión→
Gestión→ Gestión de Mandantes→ Actualizar Mandantes .
A esta pantalla entraremos por defecto en modo visualizar. La informa-
ción presentada es la de la tabla T000. Pulsando el botón que cambia a modo
modificar, tendremos la opción de crear una nueva entrada; el primer campo
corresponde al código del mandante que vayamos a crear; el segundo campo
corresponde a una pequeña descripción del mandante, el tercero a la ciudad
asociada a la empresa que va a usar ese mandante, ası́ como la moneda básica
de la empresa que va a usar ese mandante.
Los siguientes datos a rellenar se refieren al papel del mandante, opciones
12.1. CREACIÓN DE UN NUEVO MANDANTE 141
Figura 12.1: Pantalla principal de la gestión de mandantes
de modificación para objetos dependientes e independientes de mandante,

nivel de protección y restricciones.
Papel del mandante Cuando creamos un mandante deberemos asignarle

un papel, es decir un propósito o función para lo que se va a utilizar.
Los valores posibles son producción , test , customizing , presentación
, formación o referencia SAP .
Modificaciones y transportes de objetos dependientes de mandante
Dependiendo del papel que tome el mandante puede llegar a ser nece-
saria la activación o desactivación del transporte para ese mandante en
concreto. Para mandantes productivos es aconsejable protegerlos con-
tra cambios en el sistema; para mandantes de customizing todos los
cambios realizados deberán ser registrados en órdenes de transporte
para su posterior paso al mandante productivo. Veamos las distintas
opciones:
Modificaciones sin grabación automática No pide orden de

transporte al modificar el customizing. Sin embargo permite asig-
nar órdenes de transporte manualmente. Para mandantes de for-
mación y test.
Figura 12.2: Detalle de opciones de un mandante

12.1. CREACIÓN DE UN NUEVO MANDANTE 143
Grabación automática de modificaciones Al modificar customiz-

ing el sistema pide órdenes de transporte. Para mandantes de de-
sarrollo.
No se permiten modificaciones No se permite modificar cus-
tomizing. Permite asignar órdenes de transporte manualmente.
Opción más usada para mandantes de sistemas productivos.
No se permiten transportes Se permite modificar el customizing
pero las modificaciones no se registran automáticamente en
órdenes de transporte. Tampoco se permite la asignación manual
a órdenes de transporte. Opción más usada para mandantes de
sistemas productivos
Modificaciones objetos independiente mandante Se puede limitar el

alcance de las modificaciones permitidas en el mandante. Las opciones
son:
Se permite modificar repository y customizing indep.mandante

Opción más usada para mandantes en sistemas de desarrollo o
pruebas donde sepamos que las modificaciones independientes de
mandante no afectarán negativamente al funcionamiento del sis-
tema.
No modificación de objetos customizing independ.de mandante
Las modificaciones del customizing que afectan a tablas independi-
entes de mandante afectan a todo el sistema. En ciertos sistemas
no productivos con diversos mandantes donde se han realizado
tareas de customizing antagónicas, se deberá usar esta opción.
No modificación de objetos repository Impide modificar objetos
standard del repository (tablas, programas, pantallas, etc...) y la
creación de nuevos objetos de desarrollo.
No modif.de objetos repository y customizing indep.mandante
Opción más usada en mandantes de sistemas de productivo. Con
esta opción se desactiva la posibilidad de modificar objetos stan-
dard de SAP (tablas, programas, etc. . . ) y la posibilidad de mod-
ificar opciones de customizing globales que afecten a todos los
mandantes.
Protección Se pueden proteger mandantes de una copia de mandante o

de comparación (existen herramientas que nos permiten comparar los
datos de distintos mandantes). Es importante tener los mandantes
productivos protegidos contra copias – intencionadas o no – de

mandante. Veamos los distintos niveles de protección:
Nivel Protección 0: No hay restricciones En este nivel no existe

protección .
Nivel Protección 1: No se permite sobrescritura En este nivel
se protege contra copia de mandante. El mandante ası́ protegido
no podrá ser sobrescrito por una copia de mandante.
Nivel Protección 2: No se permite sobrescritura ni comparación
Este nivel además de proteger contra copia de mandante protege
contra la herramienta de comparación. Esta opción será especial-
mente necesaria para mandantes productivos donde la información
allı́ contenida es especialmente confidencial y donde se deberán
cumplir todos los requerimientos impuestos por las leyes oficiales
de protección de datos.
Restricciones Por último podremos restringir el uso de herramientas CATT

o incluso proteger el mandante contra un upgrade - cambio de versión
-. Las opciones son:
Inicio de procesos CATT permitido CATT proviene de Comput-

er Aided Test Tool. Engloba un grupo de programas usados por
SAP para el chequeo del funcionamiento del sistema.
Protección contra upgrade Si un mandante es protegido contra
upgrade, los datos dependientes de mandante en él no podrán
ser modificados.
Esto compone lo que es el primer paso en la creación de un mandante.

El segundo paso será el llenado del nuevo mandante de datos a partir de un
mandante ya existente a través de uno de los siguientes procesos:
Copia local
Copia remota
Transporte de mandante
12.2. COPIA LOCAL DE MANDANTE 145
12.2. Copia local de mandante

Una vez completado el primer paso de la creación de mandante, veamos
los pasos a seguir en el caso de que se quiera copiar con los datos de otro
mandante ya existente en el mismo sistema, es decir, lo que se llama una
copia local.
Deberemos entrar en el nuevo mandante creado como se ha explicado
en la sección anterior. El único usuario disponible en un mandante recién
creado y sin ningún tipo de datos es el usuario SAP* con password PASS.
Este usuario está disponible siempre en SAP ya que ası́ se ha programado
el kernel. La password PASS sólo está activa en mandantes recién creados
o si en un mandante estandar o ya creado y con datos propios eliminamos
del maestro de usuarios el usuario SAP*; esta eliminación del superusuario
SAP* no es sino una simple reinicialización del usuario. Esto permite poder
acceder siempre a un mandante aunque por error se hayan eliminado todos
sus usuarios.
Una vez conectados al nuevo mandante – recordemos que no estará plena-
mente operativo hasta que el la copia de datos se finalice – deberemos acceder
a la opción de Copia Local disponible en la transacción SCCL o alternativa-
mente Herramientas→ Gestión→ Gestión→ Gestión de Mandantes→ Copia
Mandante→ Copia Local.
Figura 12.3: Copia local de un mandante
En esta pantalla el mandante destino es el mandante al que nos hemos

conectado; deberemos elegir un perfil de copia, el mandante origen de copia
de datos, el mandante origen de copia de datos de maestros de usuario y

si el proceso corre en modo test o real. El sistema permite elegir distintos
mandantes origen para copiar los usuarios y el resto de datos porque nos
puede llegar a interesar crear un mandante con los datos de uno pero con los
usuarios definidos en otro.
Si no estamos seguros de si el tamaño actual de nuestra base de datos
soportará el aumento debido a la creación de un nuevo mandante deberemos
lanzar el proceso en modo test y comprobar en el log si tenemos suficiente
espacio libre en la base de datos o si por el contrario debemos aumentarla
como paso previo a una copia de mandante. Si no realizamos el proceso en
modo test y la copia se cancela por falta de espacio, no sólo tendremos un
mandante creado a medias sino que además será imposible seguir trabajando
en todo el sistema hasta que la base de datos sea extendida.
Los datos a copiar se establecen en los llamados Perfiles de Copia.
Al realizar la copia local se debe elegir un perfil de copia, con lo que
implı́citamente se estará indicando el tipo de datos a copiar. Podremos
crear nuevos perfiles de copia a partir de los ya existentes. Para visualizar
el contenido de cada perfil desde la transacción SCCL acudiremos al
menú desplegable a la opción Perfil→ Visualizar Perfil .
En ellos básicamente se puede elegir los datos a copiar que pueden ser
el maestro de usuarios, los datos de customizing , los datos de aplicaciones
, las variantes de reports y la validez (para todo tipo de copias, sólo copias
locales, sólo copias remotas, sólo para export de mandantes ).
Una vez elegido el perfil lo único que deberemos hacer es pulsar el botón
ejecutar o ejecutar en fondo. La opción ejecutar realiza el proceso de copia en
diálogo con lo que el sistema no nos devuelve el control de nuestra sesión hasta
que termine el proceso de copia. Esta opción es totalmente desaconsejable
porque la copia tarda mucho tiempo. Se recomienda usar siempre la opción
ejecutar en fondo y programar la copia para una hora en la que sepamos que
la actividad del sistema va a ser nula o mı́nima.
Una vez lanzada la copia de mandante podremos acceder al log de la copia
a través de la transacción SCC3 o alternativamente por el menú desplegable
Herramientas→ Gestión→ Gestión→ Gestión de Mandantes→ Logs de
Copia. En este log podremos ver el tanto por ciento de proceso de copia
ejecutado.
La copia de mandante consiste realmente en un proceso en el que
se accede alfabéticamente tabla a tabla para copiar los registros que
pertenecen al mandante origen en otros tantos registros cuyo mandante
será el mandante destino de la copia. El tiempo que consuma el proceso
de copia dependerá fundamentalmente de los recursos del sistema, los datos
elegidos a copiar en el perfil de copia, y el número de registros de los
12.2. COPIA LOCAL DE MANDANTE 147
Figura 12.4: Detalle de un perfil de copia

que se componga el mandante origen. Se deberá tener en cuenta todo esto

para dimensionar los tablespaces o devices – dependiendo del RDBMS –
adecuadamente y evitar un llenado de ellos que provoque una cancelación de
la copia.
Se debe recalcar que este proceso es muy crı́tico y extremadamente
sensible a la carga de trabajo del sistema, ya que consume muchos recursos.
En el momento de la ejecución de la copia no debe haber ningún usuario
conectado al mandante origen ni al destino y tampoco debe haber ningún
proceso batch corriendo aparte del propio proceso de copia. De otra manera
se podrı́a provocar una cancelación en el proceso de copia.
12.3. Copia remota de mandante

Cada sistema R/3 tiene claramente definidas sus tareas; ası́ por ejemplo,
desarrollo y producción deben estar en sistemas claramente separados. Para
poder realizar una copia de mandantes entre sistemas distintos existe la
herramienta de la copia remota. Debido a que los datos deben pasar a través
de la red, una copia remota es mucho más lenta que una copia local.
La transacción de copia remota es SCC9 que puede ser accedida
por el menú desplegable Herramientas→ Gestión→ Gestión→ Gestión de
Mandantes→ Copia de mandante→ Copia remota.
Figura 12.5: Copia remota de un mandante

12.4. TRANSPORTE DE MANDANTE 149
A diferencia de la copia local, en la copia remota exclusivamente se

deberá indicar un destino fuente como origen de la copia. Este destino fuente
será realmente una conexión RFC, necesaria para que ambos sistemas , fuente
y destino se puedan comunicar para el traspaso de datos. En la definición de
este sistema lógico estará incluido el sistema origen y el mandante origen. Por
las mismas razones que en la sección de copia local se recomienda siempre
lanzar este proceso de copia en fondo.
El sistema, igual que en la copia local, bloquea los mandantes origen y
destino impidiendo que los usuarios se conecten, pero los usuarios conectados
previamente no serán desconectados. Será tarea del administrador lanzar la
copia cuando no haya ninguna conexión al sistema o cancelar las conexiones
ya existentes.
En la copia remota, sólo se copian datos de tablas no las definiciones de
tablas. Si se crearon tablas nuevas en el mandante origen cuyas definiciones
no fueron transportadas, estas tablas no son pasadas en el proceso de copia.
Se deberá proceder a transportar todas las tablas nuevas que no se encuentran
en el sistema destino antes de realizar la copia remota.
12.4. Transporte de mandante

Con esta herramienta los datos no son copiados directamente al mandante
destino sino que, a través del programa de control de transporte tp, se realiza
un export del mandante consistente en la exportación a fichero de toda la
información a copiar. El export genera tres órdenes de transporte, una orden
para los datos independientes de mandante, otra para los dependientes y otra
para los textos especı́ficos.
Otra diferencia importante con respecto a la copia remota es que el
sistema destino no tiene por qué ser accesible desde el sistema origen , como
ocurrı́a en la copia remota. Aunque el sistema destino, en este caso, no tiene
por qué ser distinto del origen, este método se recomienda sólo para el caso de
copia a un sistema destino diferente del origen ya que para copiar mandantes
dentro de un mismo sistema disponemos de la copia local que consume menos
tiempo.
Accederemos a esta herramienta en la transacción SCC8 o a través
del menú desplegable Herramientas→ Gestión→ Gestión→ Gestión de
Mandantes→ Transporte de Mandante→ Export de Mandante.
En este caso, igual que en los anteriores, se deberá elegir un perfil de copia,
y se podrá elegir entre ejecución real o de test ası́ como un lanzamiento del
proceso de exportación en diálogo o background. Por las mismas razones que
en las dos secciones anteriores se deberá elegir la ejecución en background.
Figura 12.6: Export de mandante
El sistema nos mostrará a continuación una ventana de diálogo

informándonos de las tres órdenes de transporte que se van a generar:
Orden generada con datos indep. de man- <SID>KO(No secuencial)

dante:
Orden generada con datos dep. de mandante: <SID>KT(No secuencial)
Orden generada con los textos especı́ficos: <SID>SX(No secuencial)
Este proceso de exportación de mandante también queda registrado en

el log de copia, en la transacción SCC3. La creación de estas 3 órdenes de
transporte lleva asociada la creación de ficheros a nivel de sistema operativo,
con lo que tendremos como limitación de espacio para esas órdenes el asignado
a la unidad donde esté establecido el directorio de transportes – en entornos
Windows –, o el asignado al file system correspondiente – en entornos UNIX
–. Deberemos recordar que la exportación de mandante puede llegar a crear
ficheros de gran tamaño, dependiendo de la información asociada al mandante
a exportar; por lo que un llenado del file system o de la unidad de disco
asignada causará una cancelación del proceso de exportación.
Una vez creadas satisfactoriamente las órdenes de transporte lo único que
restará será importar (como se vio en el capı́tulo 11) en el sistema destino
primero la orden asociada a los datos independiente de mandante, y después
la orden asociada a los datos dependientes de mandante con el programa de
control de transporte tp.
Como tercer paso deberemos importar los textos especı́ficos conectándonos
12.4. TRANSPORTE DE MANDANTE 151
al sistema destino y accediendo a Herramientas→ Gestión→ Gestión→

Gestión de Mandantes→ Transporte de Mandante →Trabajo Repaso Im-
port. Introduciremos la orden de los textos especı́ficos y pulsaremos ejecutar
en diálogo o background.
Capı́tulo 13
Mantenimiento de instancias
13.1. Perfiles del sistema

El sistema SAP R/3 dispone de unos parámetros de configuración
necesarios para el arranque y funcionamiento de sus instancias. En
este capı́tulo veremos cómo gestionar tales parámetros para optimizar el
funcionamiento del sistema R/3. Tales parámetros nos permitirán configurar
tamaño de bufferes, idioma de conexión por defecto, mandante de conexión
por defecto, tiempo de expiración de passwords, número intentos fallidos de
conexión para bloquear usuario, etc. . .
13.1.1. Mantenimiento de perfiles del sistema

Los parámetros activos se mantienen desde los Perfiles del Sistema. Estos
perfiles son realmente 3 ficheros a nivel de sistema operativo donde se guarda
toda la información técnica del sistema R/3:
1. Perfil de Inicio: El nombre es Start <número instancia> <nombre

máquina>. Es un perfil único por instancia del sistema R/3 que contiene
parámetros necesarios para el arranque de SAP en los servidores que
componen el sistema.
2. Perfil por Defecto: El nombre es DEFAULT. Es un perfil único por sistema

R/3 que contiene parámetros globales para todo el sistema.
3. Perfil de Instancia: El nombre es <SID> <número instancia> <nombre

de máquina> y es un perfil único por instancia del sistema R/3 con
parámetros especı́ficos de cada instancia.
153
154 CAPÍTULO 13. MANTENIMIENTO DE INSTANCIAS
Estos tres perfiles están almacenados a nivel de sistema operativo en tres

ficheros con los nombres especificados anteriormente en el siguiente path de
la instancia central:
\usr\sap\<SID>\SYS\profile\
donde <SID> es el System Identification, es decir, el nombre de la base de

datos del sistema R/3 que está compuesto de tres caracteres y que se establece
en tiempo de instalación del sistema en los servidores.
Ejemplo: Supongamos un sistema R/3 compuesto de 2 instancias; una

instancia central y otra de aplicaciones, cada una de ellas en una máquina
distinta. Supongamos que tenemos la siguiente configuración:
Nombre base de datos SAP (SID): ”P11”
Nombre máquina de la instancia central: ”servr001”
Identificador instancia central: ”00”(este valor de identificador para la
instancia se establece en tiempo de instalación y no se puede cambiar)
Nombre máquina de la instancia de aplicaciones: ”servr002”
Identificador instancia aplicaciones: ”10”
Los perfiles del sistema serán, en este caso, cinco: un único perfil por
defecto y dos perfiles de inicio y de instancia por cada una de las instancias
que componen nuestro sistema:
Perfil por defecto: DEFAULT
Perfil inicio instancia central: START DVEMGS00 servr001
Perfil instancia insta. central: P11 DVEBMGS00 servr001
Perfil inicio instancia aplicacl: START D10 servr002
Perfil de instancia insta. aplic.: P11 D10 servr001
Hay una herramienta en SAP para gestionar el mantenimiento de estos

perfiles sin tener que bajar a nivel de sistema operativo. Esta herramienta se
encuentra en la transacción RZ10, accesible por el menú desplegable desde
Herramientas→ CCMS→ Configuración→Actualizar Perfiles.
En esta transacción existen 3 niveles de gestión de perfiles, en cada uno
de los niveles se muestra distinto tipo de información:
Datos de gestión. En este nivel se mantiene el path completo del fichero a

nivel de sistema operativo, ası́ como fechas de modificación y activación
del perfil en cuestión y autor de dicha modificación y activación.
13.1. PERFILES DEL SISTEMA 155
Figura 13.1: Pantalla pricipal perfiles del sistema
Figura 13.2: Datos de gestión de un perfil

Actualización básica . En este nivel no se permite introducir ningún

parámetro nuevo, sólo modificación de los parámetros básicos que
componen el perfil.
Este nivel es especialmente importante en el caso del perfil de instancia
ya que permite, de una manera muy sencilla y segura, cambiar los
parámetros relativos a los bufferes y al número de colas de trabajo.
Será este el perfil que debamos modificar si deseamos que una instancia
o varias tengan una distribución distinta de sus colas de trabajo.
Figura 13.3: Actualización básica de un perfil
Actualización ampliada . En este nivel se permite la visualización o

modificación de todos los parámetros activos en el perfil seleccionado,
ası́ como la introducción de nuevos parámetros. Algunos parámetros
tienen documentación asociada en este nivel que puede ser visualizada
pulsando F1 sobre el parámetro deseado.
13.1. PERFILES DEL SISTEMA 157
Figura 13.4: Actualización ampliada de un perfil
13.1.2. Importación de perfiles del sistema
La primera vez que se accede a esta herramienta desde que se instala

el sistema SAP R/3, los perfiles no se encuentran disponibles desde SAP;
existen sólo a nivel de sistema operativo por lo que será necesario importar
dichos perfiles para que se puedan mantener desde dentro del sistema. A
esta herramienta de importación se accede desde la RZ10 en la opción del
menú desplegable Utilidades→Importar Perfil→ De servidores Activos.
Una vez que ejecutemos la importación de los perfiles desde el sistema

operativo, los tendremos disponibles en la transacción RZ10. Pulsando
la ayuda de búsqueda correspondiente al campo Perfil, el sistema nos
mostrará en un listado los perfiles importados.
13.1.3. Visualización todos los parámetros activos

Existen más parámetros técnicos de configuración SAP que los que
aparecen en los perfiles antes indicados. Se pueden ver todos los parámetros
activos en SAP ejecutando el programa RSPARAM desde la transacción
SE38 (editor ABAP/4). Si un parámetro no aparece en ninguno de los tres
perfiles del sistema no quiere decir que no exista, ya que puede encontrarse
activo en el sistema pero no aparecer en ninguno de los tres perfiles por
tener asociado su valor por defecto. Para saber si un parámetro determinado
está activo en el sistema deberemos ejecutar el programa antes mencionado
y comprobar si aparece en el listado. Si no aparece, esto significará que el
parámetro no está activo en el sistema.
Si deseamos modificar un parámetro al que sólo se puede acceder a través
de la ejecución del programa RSPARAM, deberemos proceder incluyéndolo
como un parámetro nuevo en cualquiera de los perfiles existentes. Si es un
parámetro que debe tener un valor distinto por cada instancia o que sólo
se debe activar en determinadas instancias de nuestro sistema, deberemos
incluirlo en el perfil de instancia de las instancias adecuadas; si el parámetro
es global para todo el sistema R/3 deberemos incluirlo una única vez en el
perfil por defecto (otra posibilidad menos recomendada es que se incluya en
cada uno de los perfiles de instancia de las instancias que conforman nuestro
sistema SAP R/3).
Importante: Cualquier modificación sobre cualquiera de los perfiles de
inicio y de instancia – bien sea en la modificación del valor de un parámetro
o en la inclusión de un nuevo parámetro – no toman efecto hasta que la
instancia en cuestión sea reiniciada. Cualquier modificación sobre el perfil por
defecto no toma efecto hasta que el sistema R/3 al completo es reiniciado.
Este hecho es avisado por el sistema R/3 cada vez que se procede a la
modificación de cualquiera de sus tres perfiles a través de una ventana de
diálogo.
La modificación de los perfiles del sistema requiere de un paso más además
de la grabación en sı́ de las modificaciones; este paso es la Activación del
perfil. El concepto de activación o generación se encuentra presente en muchas
de las aplicaciones de SAP como puede ser el mantenimiento de perfiles y
autorizaciones de usuario, programación o mantenimiento de tablas, etc. . . La
grabación de una modificación de tales objetos supone la creación de una
nueva versión de ese objeto a nivel de SAP R/3 pero el sistema no la toma
como la actual. La activación o generación de ese objeto supone, en algunos
casos como los programas y tablas, la modificación real de ese objeto en la
base de datos o la modificación real a nivel de sistema operativo como es el
caso de la activación de los perfiles del sistema.
13.2. MODOS DE OPERACIÓN 159
13.1.4. Parámetros más importantes de un sistema

R/3
Debido al gran número de parámetros existentes en un sistema R/3 es
prácticamente imposible conocer a fondo todos ellos, sin embargo existen
varios que, por su importancia en procesos básicos de administración, toman
un papel muy importante. A continuación listamos algunos de los parámetros
más importantes.
Nombre parámetro Valor de ejemplo Descripción
SAPSYSTEMNAME US1 Nombre de la base de datos

INSTANCE NAME DVEBMGS00 Nombre instancia
SAPSYSTEM 00 Número de instancia
SAPGLOBALHOST uisabl4 Nombre del servidor
rdisp/wp no dia 6 Número colas de dialogo
rdisp/wp no vb 2 Número colas de update
rdisp/wp no vb2 1 Número colas de update2
rdisp/wp no enq 1 Número colas de enqueue
rdisp/wp no btc 2 Número colas de batch
rdisp/wp no spo 1 Número colas de spool
zcsa/installed languages DES Idiomas instalados D -alemán-
, E -inglés- , S -español-
zcsa/system language S idioma por defecto
login/system client 800 mandante por defecto
13.2. Modos de Operación

En muchos casos será absolutamente necesario cambiar la configuración
de las colas de trabajo de nuestro sistema R/3 de una forma periódica
debido a exigencias de operativa de nuestra empresa. Las exigencias más
comunes son la definición de más procesos de trabajo de tipo batch durante
el procesamiento nocturno, que deberán ser minimizadas en cantidad durante
el horario de trabajo de nuestra empresa para dar más prioridad a los procesos
de diálogo. Esto nos optimizará la ejecución de jobs de carga o modificación
masiva de datos que se pueden realizar sin intervención del usuario durante
la noche. Esta modificación en el número de procesos de trabajo, si no
dispusiéramos de la herramienta de Modos de Operación, nos llevarı́a a tener
que modificar los perfiles de instancia de cada una de las instancias que
conforman nuestro sistema R/3 y reiniciar nuestro sistema cada vez que se
quisiera cambiar la configuración de los procesos de trabajo.

Un Modo de Operación no es más que el número y tipo de colas de
trabajo de una instancia asignados a un intervalo horario. De esta manera
nos aseguraremos que nuestro sistema R/3 funcione con una configuración
de procesos determinada durante un intervalo de tiempo, y además el
sistema cambiará en modo on line, sin necesidad de parar el sistema, a otra
configuración cuando llegue la hora de su activación.
Ejemplo : Supongamos un sistema SAP formado por una única instancia

donde están configuradas 15 colas de trabajo. Podemos definir dos modos
de operación: diurno y nocturno. En el modo de operación diurno daremos
prioridad a los procesos de diálogo definiendo más procesos DIA mientras
que en el nocturno daremos prioridad a los procesos en fondo definiendo más
colas BTC .
Modo Diurno activo de las 8.00 am hasta las 8.00 pm
Formado por 7 colas DIA
3 colas BTC
1 cola SPO
1 cola ENQ
2 colas UPD
1 cola UP2
En el modo diurno nos debemos asegurar que el sistema va a poder

gestionar sin problemas las peticiones de los usuarios, las cuales entrarán
por los procesos de diálogo; es por ello que las colas DIA deben superar al
resto de colas .
Modo Nocturno activo de las 8.00 pm hasta las 8.00 am
Formado por 3 colas DIA
7 colas BTC
1 cola SPO
1 cola ENQ
2 colas UPD
1 cola UP2
En el modo nocturno no habrá ningún usuario conectado al sistema y nos

deberemos asegurar que el sistema podrá gestionar sin problemas todos los
jobs que haya planificados; es por ello que las colas BTC deben superar al
resto de colas. No se debe reducir nunca a cero el número de colas de DIA ya
que hay procesos internos de SAP que necesitan de estas colas y además, de
otra forma, no podrı́amos conectarnos al sistema en caso de urgencia ya que
las conexiones de los usuarios al sistema se gestionan a través de procesos

DIA.
13.2.1. Gestión de modos de operación
Para crear modos de operación deberemos acceder a la transacción

RZ04, o alternativamente por el menú desplegable Herramientas→ CCMS→
Configuración→ Mod Oper + Servidores .
Figura 13.5: Modos de operación
En esta pantalla aparecerán los modos de operación definidos en nuestro

sistema como muestra la figura 13.5. Haciendo doble click en cada una
de las entradas – o posicionando el cursor en una entrada y pulsando la
opción Instancias/Form.op – accederemos a una pantalla donde aparecen los
siguientes campos:
Host Nombre del servidor a nivel de sistema opera-

tivo .
Servidor Nombre de la instancia instalada en el servidor
anteriormente mencionado .
Perfil Instancia Nombre del perfil de instancia de la instancia
anteriormente mencionada.
Forma Operación Modo de operación asociados a la instancia.
Procesos de trabajo Número y tipo de colas de trabajo de las que se
compone el modo de operación anteriormente
mencionado. El campo Sum es la suma de
todos los procesos de trabajo, el cual debe ser
el mismo para todos los modos de operación
definidos en nuestro sistema.
Si deseamos modificar la configuración de alguno de los modos de

operación definidos en el sistema, haremos doble click sobre el modo de
operación deseado con lo que accederemos a la ventana de diálogo de la
figura 13.6 donde podremos, con los botones ”+ ”−”, aumentar o disminuir
2
el número de colas de un tipo determinado:
Figura 13.6: Distribución de procesos de trabajo
La única limitación que impone esta herramienta es que el total de

procesos no puede cambiar. Si aumentamos el número de colas de diálogo,
posicionándonos en la linea correspondiente y pulsando el botón ”+”, el
sistema automáticamente disminuirá en la misma cantidad el número de

colas de fondo, y viceversa, si aumentamos en una cantidad el número de
colas de fondo el sistema disminuirá en la misma cantidad el número de colas
de diálogo.
Si deseamos aumentar o disminuir el número total de colas de una o varias
instancias, no podremos realizarlo a través de los modos de operación, sino
que se deberá realizar a través del mantenimiento de los perfiles de instancia,
con lo que el cambio no se activará realmente hasta que las instancias
modificadas sean reiniciadas de nuevo.
Hasta ahora hemos visto cómo crear o modificar un modo de operación,
pero éste no se activa realmente hasta que no es asociado a un intervalo
horario. Como último paso deberemos asociar los modos definidos a unas
horas determinadas en la transacción SM63 o a través del menú desplegable
Herramientas→ CCMS→ Configuración→ Planificar Modos Operación:
Figura 13.7: Pantalla principal asignación horaria
En esta pantalla tenemos la posibilidad de asociar un modo de operación,

bien sea normal (diario) o excepcional (válido sólo para determinados dı́as),
a un intervalo horario. Elegiremos la opción modo de operación normal
y pulsaremos bien visualizar o bien modificar. En la siguiente pantalla
podremos, si hemos elegido modificar, asociar el modo que deseemos a unas
horas determinadas.
Figura 13.8: Asignación horaria a modos de operación
13.3. Grupos de logon

En sistemas SAP R/3 con múltiples servidores de aplicaciones es
importante distribuir la carga de trabajo tan óptimamente como sea posible,
es decir, deberemos evitar a toda costa que unos servidores de aplicaciones
soporten toda la carga de trabajo debido a que un tanto por ciento muy
elevado de los usuarios se hayan conectado a esas instancias y que otros
se encuentren prácticamente sin realizar ningún trabajo debido a un bajo
13.3. GRUPOS DE LOGON 165
número de conexiones de usuario. Para evitar este tipo de problemas que

puede afectar muy negativamente al rendimiento global del sistema se deben
usar los Grupos de Logon.
Un grupo de logon es un subconjunto de servidores de aplicación
disponibles en nuestro sistema R/3. Cuando los usuarios se conectan al
sistema R/3 deberán elegir uno de los grupos de logon definidos con lo que
la conexión al sistema R/3 se produce exclusivamente a través de una de
las instancias asociadas a ese grupo. De esta manera, definiendo grupos de
logon para cada una de las áreas de aplicación de SAP que sean usadas por
nuestra empresa, podremos conseguir un óptimo balance de carga de trabajo
en los servidores SAP. La definición de grupos de logon, además, nos permite
un rendimiento óptimo de los bufferes ya que los usuarios que van a realizar
tareas similares se conectarán por el mismo grupo de logon con lo cual un
tanto por ciento muy elevado de los programas que vayan a ser usados por
un usuario que se acaba de conectar ya se encuentra en los bufferes de dichas
instancias con lo que el acceso a la información es mucho más rápido.
Dependiendo del tamaño y áreas de nuestra empresa que trabajen con
SAP deberemos definir uno o varios grupos de logon por cada departamento,
área de trabajo, módulos de SAP, etc . . .
13.3.1. Gestión de grupos de logon

Los grupos de logon se pueden definir en la transacción SMLG, por el
menú desplegable Herramientas→ CCMS→ Configuración→ Grupos Acceso
En esta pantalla aparecen los grupos de logon ya definidos, sus instancias
asociadas y si se encuentran activos o no. Para definir un grupo nuevo
pulsaremos el botón Crear Entrada .
En esta ventana deberemos introducir el nombre descriptivo del grupo,
que en general será un nombre descriptivo del conjunto de usuarios que lo
vayan a usar; por ejemplo, si creamos un grupo de logon para el departamento
de recursos humanos, lo más lógico será dar ese mismo nombre al grupo de
logon.
Además del nombre descriptivo se deberá introducir la instancia por la
que se conectarán los usuarios que entren por ese grupo. Podremos restringir
los accesos a este grupo de logon por dirección IP, por tiempo de respuesta
o por número de usuarios ya conectados. Estas restricciones, si se activan,
permitirán accesos a través de dicho grupo sólo si el servidor de presentación
se encuentra en el intervalo de direcciones IP incluı́das, o sólo si su conexión
a red es de un tiempo de respuesta menor que el especificado o si el número
de usuarios conectados a este grupo no supera el máximo establecido.
Una vez que se han definido los grupos de logon, cada servidor de
Figura 13.9: Pantalla principal grupos de logon
presentación deberá tener instalado el programa saplogon.exe, que se instala

con el sapgui. Este programa permite tener un único icono de conexión a
SAP para todos los sistemas SAP y grupos de logon de los que dispongamos.
13.3.2. Saplogon
A continuación veremos cómo se debe usar el programa saplogon incluido
como opción de instalación del sapgui. Lo primero que deberemos hacer
es ejecutar el programa que se encontrará dentro del grupo de programas
instalado con el sapgui o SAP Frontend en nuestro PC, como muestra la
figura 13.11.
Los botones Server y Groups sirven para crear iconos de servidores de
aplicaciones y grupos de logon respectivamente para el acceso a uno o varios
sistemas SAP R/3. Como ya se ha explicado anteriormente, los accesos a
través de iconos de servidores de aplicación nos conectan a un sistema SAP
por un servidor determinado, mientras que los grupos de logon nos conectan
a través de uno de los servidores que tenga asociados ese grupo, con lo cual
si un servidor queda indisponible, el grupo de logon elige automáticamente
otro servidor asociado. Esto redunda en una mejor gestión de acceso de los
usuarios.
Para crear en el saplogon tantas entradas como servidores hay en un
Figura 13.10: Pantalla detalles creación grupo logon
sistema, lo único que deberemos hacer es pulsar el botón Server. En la

pantalla que se muestra en la figura 13.12 deberemos elegir el sistema SAP
al que nos queremos conectar.
En el campo ID introduciremos el valor del SID de nuestro sistema y en
message server el servidor donde está la instancia central. A continuación
pulsaremos el botón Generate List y entonces el programa se comunica con
el sistema y recupera todas y cada una de las instancias que componen el
sistema SAP.
Si pulsamos el botón Logon, el programa simplemente nos conecta al
sistema indicado a través del servidor seleccionado, pero no añade la entrada
al saplogon. Si pulsamos el botón Add, los servidores seleccionados son
añadidos al saplogon.
De manera similar podemos insertar los grupos de logon definidos en
un sistema; pulsando el botón Groups del saplogon e introduciendo los
valores deseados en los campos ID y message server obtendremos un listado
de los grupos de logon definidos en ese sistema en la transacción SMLG.
Procediendo de igual manera que con la opción Server, obtendremos el listado
Figura 13.11: Pantalla de saplogon
de grupos de logon.
Si añadimos todos los servidores y todos los grupos de logon, obtendremos
un saplogon con todos los servidores y grupos de logon definidos en nuestro
sistema.
Por último veremos las opciones New, Properties y Delete del saplogon. La
opción Properties nos permite crear de una manera más rápida que la opción
Server una entrada de icono de acceso a través de un servidor de aplicaciones.
Para ello lo único que deberemos indicar es el nombre del servidor en el campo
Application Server, una descripción del icono en el campo Description y por
último indicar el número de instancia de ese servidor – si la instancia es
única, el número será 00 – en el campo System Number.
La opción Edit edita la entrada seleccionada, ya sea icono de servidor
o de grupo, y por último, la opción Delete elimina la entrada del saplogon
seleccionada.
El programa saplogon, en definitiva, nos facilita la conexión a cualquier
servidor SAP evitando que tengamos el escritorio de nuestro PC plagado de
iconos de acceso a distintos servidores y/o sistemas SAP R/3.
Figura 13.12: Opción de selección servidor en saplogon
Figura 13.13: Opción propiedades en saplogon

Apéndice A
Transacciones más comunes
DB02 Análisis de tablas e Índices
DB14 Mostrar logs actividad SAPDBA
PFCG Generador de perfiles.
RZ01 Monitor para previsión de jobs
RZ02 Gráfico grafos de instancias SAP
RZ03 Representación,Control instancias SAP
RZ04 Actualizar instancias SAP
RZ06 Alerts Thresholds Maintenance
RZ08 Monitor alert SAP
RZ10 Actualizar parámetros perfil
RZ11 Actualización parámetros de perfil
RZ12 Actual.asignación grupos serv.RFC
SA38 Informes ABAP
SA39 SA38 para transacción parámetros
SAR Actualizar códigos de transacción
SAR0 Visualizar árbol de informes estánd.
SARA Gestión de archivos
171
172 APÉNDICE A. TRANSACCIONES MÁS COMUNES
SARL Llamada de ArchiveLink Monitor
SARP Reporting (Estruct.árbol): efectuar
SART Visualizar árbol de informes
SC38 Lanzar report remoto
SC80 CATT Utilities
SCAT Computer Aided Test Tool
SCC1 Copia mandante - selección especial
SCC3 Copia mandante Log
SCC4 Gestión mandantes
SCC5 Borrado de mandante
SCC6 Importación de mandante
SCC7 Import.mandante - tratam.posterior
SCC8 Export mandante
SCC9 Copia mandante remota
SCCL Import.mandante - tratam.posterior
SCMP Comparación vista/tablas
SCPF Generar guı́a implem. para la empresa
SCPI Interfase optimización de producción
SCT1 Resumen - Imports lógicos
SCU0 Comparac.Customizing
SE01 Transport Organizer
SE03 Workbench Organizer: Herramientas
SE06 Instalar Workbench Organizer
SE07 Visual.status gestión transp
SE09 Workbench Organizer

173
SE10 Customizing Organizer
SE11 Actualización Dictionary ABAP
SE13 Parám.memoria para actual.tablas
SE14 Utilities para tablas Dictionary
SE15 Sistema Info Dictionary
SE16 Browser de datos
SE17 Visualizar tabla (general)
SE30 Análisis tiempo ejecución ABAP
SE37 Módulos de funciones ABAP
SE38 Editor ABAP
SE39 Editor Split screen Comp. report
SE41 Menu Painter
SE43 Actualizar menú de ámbito
SE51 Screen Painter
SE54 Generar vista tabla
SE61 Docu R/3
SE63 Acceso Traducción
SE80 Browser Repository
SE84 Sistema Info Repository
SE85 Sistema Info ABAP/4 Dictionary
SE86 ABAP/4 Sistema Info
SE91 Actualizar mensajes
SE93 Actualizar códigos de transacción
SEWA Earlywatch Alert
SM0 Resumen de procesos de trabajo

174 APÉNDICE A. TRANSACCIONES MÁS COMUNES
SM01 Bloquear transacciones
SM02 Mensajes de sistema
SM04 Lista de usuarios
SM12 Visualizar y borrar bloqueos
SM13 Visualizar registros actualización
SM21 Log de sistema
SM30 Llamar actualización de vistas
SM31 Actualizar tablas
SM35 Monitoring batch input
SM36 Solicitud para proceso de fondo
SM37 Resumen de jobs de fondo
SM38 Transacción de gestión queue
SM39 Análisis jobs
SM49 Ejecución comandos OS externos
SM50 Resumen de procesos de trabajo
SM51 Lista con Sistemas SAP
SM59 Destinos RFC (visualizar y actual.)
SMLI Utilidad para import de idiomas
SMLT Utilidad para transporte de idiomas
SMOD Gestión de ampliaciones SAP
SMX Visualizar jobs propios
ST01 Trace sistema
ST22 ABAP/4 Análisis errores tiempo ejec.
STAT Estadı́sticas de acceso al sistema
SU01 Actualización de usuarios

175
SU01D Visualizar usuarios
SU02 Actualizar perfiles de autorización
SU03 Actualizar autorizaciones
SU10 Modificaciones masa Maestros usuario
SU12 Modificaciones masa Maestros usuario
SU20 Actualizar campos de autorización
SU21 Actualizar objetos de autorización
SU22 Utiliz.obj.autoriz.en transacciones
SU24 Verif.obj.autoriz.bajo transacciones
SU53 Visualizar valores de verificación
SUIM Llamada árbol report.AUTH (infosist)
SUPC Perfiles para grupos actividad
SUSE Actual.p.Self Upgrading Software

Apéndice B
Recursos Web
http://www.sap.com
Pagina principal de SAP. La versión española esta en http://www.sap.
com/spain
http://www.sappro.com
Pagina de la editorial Wellesley Information Services que edita la revista
”Sap Professional Journal”. Se pueden consultar ı́ndices de las revistas
anteriores y solicitar un ejemplar de muestra gratuito para evaluar la
publicación antes de suscribirse.
http://www.sapfans.com
Excelente web dedicada enteramente a SAP. Tienen foros de usuarios,
chat, artı́culos, descripciones de los diferentes productos de SAP, etc.
Son especialmente interesantes los foros de discusión abiertos de los
que existe uno por cada módulo de SAP R/3. Se puede descargar
ficheros .zip con el historial de preguntas y respuestas de los foros mas
concurridos.
http://www.erpfans.com
Web de la misma serie que el anterior pero mas general, con referencias
a otros productos ERP como Baan, PeopleSoft, Oracle Financials, etc.
http://www.sapclub.com
Noticias, empleo, foros, test de conocimientos sobre el modulo BASIS,
salvapantallas y fondos de escritorio con SAP como tema principal.
http://www.erpsupersite.com/sap/
Noticias acerca de SAP, catálogos de libros, análisis de implantaciones
en empresas, etc.
177
178 APÉNDICE B. RECURSOS WEB
http://www.saplabs.com
Pagina de los diversos laboratorios Technical Core Competence de
SAP que hay en el mundo. Existe un link a cada uno de ellos
y allı́ encontraremos ofertas de empleo, descripciones de los nuevos
proyectos, software para descargar y enlaces a la documentación del
Simplification Group. Esta documentación incluye artı́culos, white
papers e incluso libros completos, todo ello en formato PDF. Es la
mejor documentación disponible gratuitamente que existe.
http://www.realtimeusa.com/sap-group/archives/
Archivos con los mensajes del grupo de noticias de SAP comp.
soft-sys.business.sap. Es un grupo moderado (por lo menos no
hay que sufrir el spam :-) y el contenido es interesante.
Apéndice C
Casos reales
C.1. Autodesk, Inc.

Sector
Autodesk, Inc. centra sus actividades en el desarrollo y venta de productos
de software informático. Es uno de los principales productores de software
CAD/CAM. Su central se encuentra en San Rafael, California y posee 4
centros de desarrollo en USA y Suiza ası́ como veinte subsidiarias repartidas
por Europa y Asia.
Autodesk se encontraba, antes de la implementación del sistema SAP
R/3, en una situación en la que sus sistemas de gestión no se correspondı́an
con las necesidades de la empresa, razón por la cual se necesitaba un cambio
radical que se ajustara a la situación de rápido crecimiento y expansión
internacional que estaba experimentando.
El proyecto que se planificó para conseguir tales fines, System 2000, se
basó en cinco objetivos principales:
Globalización del software de aplicación de negocio: Los procesos de
negocio no se debı́an ver limitados por limitaciones del sistema o por
fronteras geográficas. La información debı́a fluir en tiempo real para
todos los aspectos del negocio.
El nuevo sistema informático debı́a ser capaz de soportar todos los
idiomas, operaciones, ası́ como procedimientos de cálculo de impuestos
especı́ficos de cada paı́s en los que Autodesk tenı́a algún centro o filial.
Los tiempos de los procesos de negocio se debı́an ser claramente
reducidos.
Gestión precisa de inventario.
179
180 APÉNDICE C. CASOS REALES
Como manufacturador de productos de software para UNIX y

Windows NT, Autodesk insistió en disponer de un sistema abierto
con arquitectura cliente / servidor para la gestión de sus procesos de
negocio.
El producto R/3 de SAP resultó ser el sistema que mejor se ajustaba

a las necesidades de la empresa. Los módulos R/3 de contabilidad
financiera, controlling, gestión de materiales, ventas y distribución fueron
implementados en los centros americanos en sólo 6 meses.
C.2. Schweppes, S.A.

Sector
Schweppes, S.A. pertenece al grupo Cadbury Schweppes dentro de su
división de bebidas y su actividad radica en la fabricación y distribución de
bebidas refrescantes.
Schweppes está compuesto por una plantilla de más de 1.000 personas.
Dispone de una sofisticada red de distribución formada por 30 delegaciones
de ventas, 8 cabeceras de área, más de 1.000 distribuidores y 20 almacenes, lo
que le permite dar servicio a sus más de 200.000 clientes de una forma rápida
y eficaz. Toda esta infraestructura, la existencia de sistemas de información
distribuidos sin ninguna conexión entre las aplicaciones y sin una conexión
geográfica entre las distintas áreas de venta y las oficinas centrales llevó a
Schweppes en 1989 a tomar la decisión de elegir SAP R/2 como la mejor
herramienta para la gestión de la compañı́a.
La calidad del paquete SAP R/3 evaluado en la casa matriz y la
experiencia obtenida de la utilización del sistema R/2 llevó a Schweppes
en 1995 a seguir con la tecnologı́a de SAP; en este caso el sistema R/3, como
la opción segura para la gestión de la empresa. Entre otras razones estaba
el que SAP R/3 encajaba dentro de las estrategias de futuro en el sector de
consumo en temas tan importantes como:
ECR.
Intranet.
Internet.
Comunicación con distribuidores, proveedores y clientes
Las razones que llevaron a elegir R/3 como sistema de información fueron:
C.3. IBM ESPAÑA 181
El sistema debı́a ser único para conseguir una reducción de costes.
Debı́a cumplir los requerimientos para la transición de milenio.
Facilidad de conversión de moneda.
Implantación
La implantación de SAP R/3 en Schweppes fue realizada de abril de 1996
a junio de 1997. El primer paso se dio en abril de 1996 con la implantación
del módulo de control de calidad (QM). En el mes de octubre se implantó el
módulo de gestión de materiales (MM). En el mes de enero se implantaron
los módulos de FI, CO, AM y FI-SL en el área financiera. Los módulos de
ventas y vistribución (SD) y planificación de la producción (PP) quedaron
implantados en junio de 1997.
Infraestructura
Está basada en una plataforma AIX con un SP de IBM para producción en
el mismo ”frame”en el que reside el sistema de data warehouse, herramienta
complementaria a SAP R/3 y con Oracle como base de datos. Asimismo,
existe una máquina de backup y un entorno RS 6000 separado para test.
Pasar de un entorno host a un entorno cliente / servidor ha supuesto
montar toda una nueva infraestructura en cuanto a redes LAN y WAN,
cambio de estaciones de trabajo, etc. . . que ha sido importante debido a la
dispersión de las fábricas, oficinas y delegaciones. Existen otras herramientas
colaterales como datawarehousing, EIS y desarrollos verticales, todas ellas
perfectamente integradas con R/3 y bajo el mismo entorno cliente / servidor,
de modo que todas las funcionalidades se encuentren cubiertas.
C.3. IBM España

Sector
IBM centra sus actividades en investigación, desarrollo y venta de
productos y servicios de tecnologı́a de la información.
El hecho que IBM opere en 164 paı́ses en los 5 continentes supone
una gran diversidad de necesidades especı́ficas a nivel de cada paı́s, lo cual
lleva a distintas aplicaciones y distintos procesos. Además, el operar en un
mercado cada vez más multinacional impone una unificación de procesos que
permita hacer negocios cross-border, ası́ como una reducción en el desarrollo
182 APÉNDICE C. CASOS REALES
y mantenimiento de miles de aplicaciones que hoy en dı́a mantiene el negocio

de IBM.
Estudio de Necesidades
En un estudio de necesidades, existı́an básicamente dos opciones, además
de otras pequeñas firmas que se descartaron, entre otros motivos por el hecho
de no ser internacionales o tener una estructura de soporte no suficiente para
el proyecto que se querı́a abordar.
Las dos opciones eran ir a SAP o desarrollar un sistema propio. IBM
apostó por SAP R/3 entre otras razones:
Disponer de un sistema ya desarrollado que permite unificar y

simplificar los procesos a nivel internacional
Por su arquitectura integrada en un entorno cliente / servidor.
Su compatibilidad con aplicaciones desarrolladas en otros lenguajes e

instaladas en otros entornos.
Por la flexibilidad que supone respecto a tecnologı́as ya anticuadas.
Por su estructura de soporte.
Proyecto Piloto
Como proyecto piloto se eligió España por el tamaño de su mercado y
caracterı́sticas para la instalación de SAP R/3 a nivel internacional. En
una primera fase se instalaron los módulos de ventas y distribución (SD)
y gestión de materiales (MM) de la versión 3.0D. Para 1998 estaba prevista
la implementación del módulo de finanzas (FI) casi en su totalidad.
La división encargada de utilizar el sistema es ”Fulfilment dentro de ella
2
básicamente el departmento de administración. La aplicación se utiliza para

cubrir los siguientes procesos comerciales:
Preparación de una propuesta.
El pedido.
El envı́o a la planta de fabricación.
El envı́o desde la planta al paı́s.
El envı́o al cliente.
C.3. IBM ESPAÑA 183
Facturación.
Dada la naturaleza del negocio fue necesario la realización de algunas

interfaces con otras aplicaciones para la conexión con otros departmentos y
divisiones de la empresa. Ello llevó a una reingenierı́a de procesos. Dicha
reingenierı́a ha traı́do consigo una simplificación que se ha visto reflejada en
un mejor servicio al cliente que es el objetivo primordial de IBM.
La instalación del R/3 se hizo bajo sistema operativo UNIX en un SP2
de IBM con base de datos DB2.
Apéndice D
Glosario
ABAP Advance Business Application Programming. Es el lenguaje de

programación del sistema SAP R/3. Es un lenguaje de cuarta
generación, con una sintaxis mezcla entre COBOL y SQL.
ASAP AcceleratedSAP. Metodologı́a de implementación de SAP R/3 que

busca el ahorro máximo de tiempo de parametrización.
Batch input Método para la importación rápida y consistente de datos en

R/3 partiendo de ficheros externos.
CATT Computer-Aided Test Tool. Herramienta para la generación de datos

de test para probar el software.
CO Customizing Organizer. Herramienta para administrar las órdenes de

transporte de parametrización.
Dynpro DYNamic PROgram. Programa dinámico que consiste en una

pantalla y la lógica de proceso subyacente que la controla. Es algo
similar a un form de visual basic.
EarlyWatch Service Servicio de alerta previa que ofrece SAP a sus clientes
para que, aprovechando la mayor experiencia de sus consultores,
detecten rápidamente problemas de rendimiento en nuestro sistema
productivo.
Entreprise IMG Guı́a de implementación de la empresa. Cuando se inicia

la parametrización de un sistema SAP hay que crear el Enterprise IMG
incluyendo los módulos que se va a implementar.
185
186 APÉNDICE D. GLOSARIO
Front End Término que engloba a los ordenadores, programas y procesos

que se ejecutan en el cliente y que procesan datos antes de enviarlos al
servidor.
GUI Graphical User Interface. Programa mediante el cual el usuario puede

intercambiar información con el ordenador de manera fácil e intuitiva.
Hot Package Conjunto de objetos del repositorio que SAP pone disponibles
a sus clientes para arreglar los errores o faltas graves de funcionalidad
de los programas estándar. Son los equivalentes a los Service Packs que
proporciona Microsoft para sus sistemas operativos.
IDES International Demo and Education System. Es un sistema R/3 que

se vende con un modelo de empresa parametrizado y completamente
funcional. Se usa para las demostraciones y los cursos de formación.
IMG Implementation Guide. Transacción que contiene un árbol con cientos

de transacciones de parametrización agrupadas por módulos y que
constituyen el punto de trabajo principal del equipo que implanta SAP
R/3 en una empresa.
LUW Logical Unit of Work. Secuencia indivisible de operaciones de base

de datos que forman una actualización que aegura la integrad de los
datos.
Modo Cada una de las seis pantallas como máximo que puede abrir un
usuario desde que abre una sesión con R/3.
OSS Online Service System. Servicio de atención al cliente de SAP que

funciona conectándose a una serie de servidores dispuestos a lo largo
del mundo que proveen de un servicio 24x7. Se puede buscar nuestro
problema en la base de conocimiento de SAP o abrir una nueva
indidencia si no encontramos nada parecido a lo nuestro.
RDBMS Relational Database Management System. Hace referencia a

alguno de los sistemas de gestión de bases de datos relacionales sobre
los que funciona R/3 como Oracle, DB2. SQL Server. . .
RFC Remote Function Call. Mediante este protocolo se permite que

programa externos a SAP escritos en lenguajes distintos a ABAP
ejecuten operaciones sobre la base de datos de R/3.
SAP Sistemas, Productos, Aplicaciones para el Proceso de Datos.

187
SAPGUI SAP Graphical User Interface. Programa principal con el que nos
conectaremos a R/3.
Sesión Cada una de las conexiónes que un usuario hace con el servidor R/3
en las que le pide el mandante, el usuario y la clave.
Sistema R/3 Recibe este nombre el conjunto formado por el servidor

central de base de datos, los servidores de aplicación que trabajen con
él junto con el software R/3 instalado en ellos. La identificación de un
sistema SAP se denomina SAPSID o simplemente SID y es un código
de tres caracteres.
WBO Workbench Organizer. Herramienta para administrar las órdenes de

transporte de desarrollo.
WP Work process. Cada uno de los procesos que los servidores de aplicación
proporcionan a SAP para gestionar las peticiones de diálogo, fondo,
spool, actualización. . .
Bibliografı́a
[1] Fundamentos de SAP R/3 – Dennis L. Prince – Anaya Multimedia –

ISBN: 8441510261
http://www.anayamultimedia.es
[2] SAP R/3 System Administration : The Official SAP Guide – Liane
Will – Ed.Sybex – ISBN: 0782124267
http://www.amazon.com/exec/obidos/ASIN/0782124267/qid=
963220261/sr=1-64/104-9469904-0307951
[3] SAP R/3 System : A Client/Server Technology – Rudiger Buck-

Emden, Jurgen Galimow, Sap Ag – Addison-Wesley Pub Co – ISBN:
0201403501
http://www.amazon.com/exec/obidos/ASIN/0201403501/qid%
3D963223251/104-9469904-0307951
[4] The R/3 System Landscape - Simplification Group

http://207.105.30.51/simple/sysadmin/files/Landscape-I.pdf
[5] Edición Especial SAP R/3 – ASAP World Consultancy. Blain, Jonathan
– Prentice Hall Iberia – ISBN: 0789713519
http://www.amazon.com/exec/obidos/ISBN%3D0789713519/
thesapfansclubanA/104-9469904-0307951
[6] Ası́ es SAP R/3 Hernández Muñoz, José Antonio – Osborne McGraw-
Hill – ISBN: 8448121007
http://www.mcgrawhill.es/McGrawHill/catalogo.htm
[7] System Administration Made Easy Release 4.0B - Simplification Group

http://207.105.30.51/simple/sysadmin/saezindex.htm
[8] Authorizations Made Easy Guide 4.0B - Simplification Group

http://207.105.30.51/simple/authorization/40_pdf_files/
amez4ball.pdf
189

Administracion de SAP R3

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Administracion de SAP R3

Uploaded by

Copyright:

Available Formats

GESTIÓN DE SISTEMAS DE

Universidad de Deusto - Facultad de Ingenierı́a

Antonio Toledo Carnicero

Copyright (c) 2006 Pablo Pérez Pérez y Antonio Toledo Carnicero.

En los últimos 15 años la implantación de sistemas de información tipo

Sobre los autores

trabajado como analista y consultor técnico de SAP para varias empresas y

1. Introducción a SAP R/3 13

3. Arquitectura de un sistema R/3 37

5. Monitorización de procesos y usuarios 55

8. Log del sistema y análisis de dumps 85

8.1.4. Leyendo el log del sistema . . . . . . . . . . . . . . . . 89

9. Gestión de spool 103

10.Gestión de usuarios y autorizaciones 111

11.Sistema de transporte 121

12.Gestión de mandantes 139

13.Mantenimiento de instancias 153

13.3. Grupos de logon . . . . . . . . . . . . . . . . . . . . . . . . . 164

A. Transacciones más comunes 171

B. Recursos Web 177

C. Casos reales 179

2.1. Pantalla de entrada a SAP R/3 . . . . . . . . . . . . . . . . . 22

3.1. Capas de la estructura cliente/servidor de R/3 . . . . . . . . . 37

5.1. Monitor de procesos de una instancia . . . . . . . . . . . . . . 56

6.1. Pantalla inicial de definición de job . . . . . . . . . . . . . . . 66

7.1. Esquema funcionamiento actualización ası́ncrona . . . . . . . . 74

7.4. Actualizaciones pendientes . . . . . . . . . . . . . . . . . . . . 78

8.1. Pantalla principal log local del sistema . . . . . . . . . . . . . 87

9.1. Transacción SPAD. Mantenimiento de dispositivos de salida . 104

10.1. Componentes de la seguridad en R/3 . . . . . . . . . . . . . . 112

11.1. Esquema de una orden de transporte . . . . . . . . . . . . . . 123

11.12.Log del transporte de una orden . . . . . . . . . . . . . . . . . 137

12.1. Pantalla principal de la gestión de mandantes . . . . . . . . . 141

13.1. Pantalla pricipal perfiles del sistema . . . . . . . . . . . . . . . 155

Introducción a SAP R/3

1.1. Software estándar vs. software a medida

”Nuestra planta de 1.500 trabajadores esta operando sobre

todo el código de cosecha propia que tiene la planta esta escrito

Un situación como esta obliga al departamento de TI a incurrir en grandes

1.2. Visión general de SAP R/3

Exhaustivo El sistema R/3 engloba la práctica totalidad de los procesos de

Integrado Tal cantidad de modulos no aportarı́an demasiado valor añadido

entre modulos de SAP permiten tener disponible en tiempo real y

Abierto Tecnológicamente hablando, SAP es un sistema abierto. Podemos

Global El sistema R/3 soporta su utilización en varios idiomas, la

Actualizado Dos de los grandes problemas de los departamentos de TI a

Control de Gestión CO Controlling. La contabilidad financiera no

2. Logı́stica LO Logistics. Bajo este epı́grafe se engloba la gestión

compra y almacenaje de materia prima, pasando por la fabricación del

Gestión de Materiales MM Materials Management. Optimiza

Ventas y Distribución SD Sales and Distribution. La cambiante

3. Recursos Humanos HR Human Resources. Tradicionalmente, la

Nómina PA Payroll Accounting. Mantiene todos los datos de los

Estructura Organizativa PD Personnel Development. Este submódu-

1.2.3. Entorno de desarrollo

ABAP/4 El lenguaje de programación ABAP/4 se caracteriza por su total

Data Dictionary Es el punto de referencia para los programadores ya que

Editor de programas El editor ABAP/4, aparte de proveer de las fun-

Screen Painter Con esta herramienta crearemos rápidamente interfases

Entorno de depuración El modo debugging de ABAP/4 es posiblemente

Otras herramientas. Existe una gran variedad de herramientas adicionales

Como cualquier software que esté basado en arquitectura cliente/servidor,

2.1. Pantalla de logon a SAP R/3

2.2. Concepto de mandante