Tucos SAP

Tucos SAP
Truco 1 – Texto personalizado en la pantalla de Logon

Publicado el 9 abril, 2011por Roberto Espinosa
1 Vote
Con esta entrada inicio una serie de trucos generales que podemos utilizar para
personalizar nuestro sistema Sap. En la mayoría de casos estan descritos en
alguna nota del OSS o en la documentación Online de Sap.
En esta primera entrada vamos a ver la forma de incluir un texto
personalizado en la pantalla de Logon. Esta es la que aparece cuando un
usuario se conecta al sistema, antes de introducir sus datos de usuario y
contraseña. En esto texto podemos incluir información importante para los
usuarios que nos puede permitir, por ejemplo:
 Diferenciar los sistemas de desarrollo o formación de los sistemas
productivos.
 Incluir información acerca de la disponibilidad del sistema u operaciones de
mantenimiento.
 En los sistemas de test, incluir información sobre los diferentes mandantes
disponibles y su utilidad o uso.
 En grandes instalaciones, incluir información de contacto con el
administrador del sistema o textos que describan determinados
procedimientos.
El procedimiento esta descrito en la nota OSS 205487. Esta disponible desde la
versión 4.6 (sustituye a la modificación del programa SAPMSYST screen 0020
de versiones anteriores). Vamos a ver en detalle los pasos necesarios para la
configuración de esta funcionalidad del sistema:
1. Comprobar cual es el idioma de nuestra instalación Sap: Esto es
importante porque solo se mostrará el texto si esta definido en el mismo
idioma. Para comprobar el valor, accederemos a la RZ11 y indicaremos el
parámetro zcsa/system_language. Si el valor es S, el idioma es el
Español. Si es una E, será el Ingles. Y habrá que utilizar ese idioma para que
el mensaje se muestre.
2. Entrar en la transacción SE61 y crear un texto con el
nombre ZLOGIN_SCREEN_INFO. El texto ha de ser de la clase de
documentos Texto General y el idioma debe ser el que hayamos obtenido en
el paso anterior.
A continuación se nos abrirá el editor de texto, donde podremos introducir el
texto deseado, teniendo en cuenta las siguientes consideraciones generales:
 En la pantalla de logon hay espacio para 16 lineas (con 45 caracteres por
linea en una fuente fija o 60 en una fuente proporcional).
 Se pueden introducir textos de titulo indicando el correspondiente formato
(clave de formato que empiezan por ‘U’).
 Se pueden insertar iconos en el principio de cada linea (por ejemplo, el valor
@1D@ nos mostrará el icono Stop). La lista completa de iconos la podemos
obtener con los reports estandar RLMON_ICONS_DISPLAY o RSTXICON
(los códigos de icono con dos simbolos @ seguidos no se pueden utilizar).
Aquí teneis un ejemplo del texto introducido en la transacción Se61:
Y este sería la pantalla que logon que observariamos la próxima vez que nos
conectaramos al sistema:
NOTA IMPORTANTE: en condiciones normales, tendremos un texto para
cada sistema. Por tanto, no podremos definir un texto en el sistema de
desarrollo y transportarlo al resto de sistemas. Como alternativa, habrá que
abrir el sistema (transacciones SCC4/SE06) e introducir el texto personalizado
en cada uno de nuestros sistemas.
P.D.: existe una forma adicional de modificar el logon a través del GuiXT de
Sap (tal y como se describe en el foro mundosap.com). Yo no lo he utilizado
nunca, pero os dejo el enlace por si alguién lo quiere probar.
Truco 2. Imagen personalizada en el menú Sap.
2 Votes
En una instalación estandar de Sap, una vez accedemos al sistema aparece una
imagen a la derecha, que es la estandar proporcionada por Sap (tal y como
vemos en la imagen):
Esta imagen se puede ocultar a nivel de usuario desde la opción de menú

Detalles –> Opciones o bien desde la configuración del Saplogon (en el caso de
definir el acceso a un sistema con el valor Conexion de red lenta). Esta
parametrización afectará a todos los usuarios que utilicen el ordenador y
agilizará el trabajo con Sap en los usuarios localizados en redes remotas.
Ademas, podemos desactivar la imagen para todos los usuarios de un
sistema(de forma global). Para ello accederemos a la transaccion SM31 y
añadiremos/modificaremos un registro en la tabla SSM_CUST. El registro
tendrá el nombre HIDE_START_IMAGE y el valor YES. De esta forma, la
imagen dejará de aparecer a todos los usuarios.
En condiciones normales, lo habitual será cambiar la imagen de Sap por una
imagen más corporativa, que normalmente será el logotipo de la empresa o el
nombre comercial. Para configurar esto, deberemos de realizar las siguientes
tareas en nuestro sistema:
 Carga de la imagen en Sap: a través de la

transaccion SMW0 cargaremos nuestro fichero de imagen. Seleccionaremos
la opción datos binarios y crearemos un nuevo fichero (utilizar siempre la
nomenclatura Z??? para nombrar la imagen). El archivo que carguemos
puede ser del tipo jpg o gif, por ejemplo.
 Parametrización: a través de la transacción SM31, crearemos un registro

en la tabla SSM_CUST, con el nombre START_IMAGE y el valor el
nombre de la imagen que hemos creado en el paso anterior. Tras realizar
esta acción, la próxima vez que accedamos al menú principal de Sap
observaremos nuestra imagen personalizada.
En la misma tabla SSM_CUST podemos configurar otros aspectos de la imagen,
como el ajuste automático de la imagen a la ventana introduciendo el registro
RESIZE_IMAGE con el valor YES o NO según si deseamos o no que se realize
este ajuste.
De una forma sencilla, hemos personalizado nuestro sistema (aunque no
seamos Repsol) y lo hemos hecho corporativo, algo que siempre vende muy
bien.
Truco 3. Personalizacion de los menus de Sap.
7 Votes
Cuando accedemos al sistema Sap, tenemos disponibles dos menús con las
diferentes transacciones a las que podrá acceder el usuario:
 Menú Sap: es el menú estándar que incluye todas las opciones disponibles
en el sistema (aunque esto se puede cambiar, como veremos más adelante).
Normalmente accedemos al menú de ámbito S000 cuando estamos
trabajando con el ERP.
 Menú de usuario: es el menú que se construye con los roles de

autorizaciones asignados al usuario. Los roles se definen mediante la
transacción PFCG, y pueden incluir arboles de transacciones, además de
las correspondientes objetos de autorización para acceder a ellas. Los roles se
asignan a los usuarios en el mantenimiento de estos (que se realiza con la
transacción SU01). A partir de todos los roles que tiene asignados el usuario,
el sistema nos construye el menú correspondiente incluyendo todos los
elementos definidos.
En la imagen siguiente podemos ver un ejemplo de definición de un Rol para

usuarios encargados de la administración de un sistema Sap. Vemos en la
definición del rol como se puede construir un menú personalizado por tareas (del
que dispondrán los usuarios en su menú de usuario). En la definición del rol
también se pueden incluir las autorizaciones apropiadas para que el usuario tenga
acceso a todas las transacciones y objetos organizativos necesarios según el tipo
de trabajo a realizar. El rol definido en el ejemplo es el que se visualiza en el menú
de usuario de la imagen anterior.
Además, tanto en un menú como en otro el usuario tendrá disponible siempre su

propio menú de favoritos, donde podrá crear accesos rápidos a las
transacciones de uso más frecuente (incluyendo una estructura de carpetas para
clasificar los elementos definidos por el usuario de una manera ordenada).
Teniendo en cuenta esto, algunas de las parametrizaciones que podemos realizar
en el sistema para configurar los menús son las siguientes:
 Desactivar el menú Sap: de esta forma, los usuarios solo verán las
transacciones asignadas en sus roles y los favoritos. Esto lo realizaremos a
través de la transacción SM31, incluyendo en la tabla SSM_CUST un
registro con nombre SAP_MENU_OFF y el valor YES. Esto aplica a todos
los usuarios del sistema.
 Desactivar los menús de usuario: solo será visible el menú estándar y los
favoritos. Esto lo realizaremos a través de la transacción SM31, incluyendo
en la tabla SSM_CUST un registro con
nombre ALL_USER_MENUS_OFF y el valor YES. Esto aplica a todos los
usuarios del sistema.
 Cambiar el menú Sap para todos los usuarios: a través de la
transacción SSM2podemos cambiar el menú inicial del sistema. Por defecto,
el menú es el S000. Podemos indicar un menú diferente de entrada al sistema,
o un menú Z que hayamos elaborado a medida.
 Cambiar el menú Sap para un usuario individual: desde el

mantenimiento de los datos de usuario (transacción SU01), podemos
indicar un valor de menú inicial para el usuario, en la pestaña de
datos Valores Fijos.
 Configuración de menú permitidos por usuario: aparte de todas las

configuraciones descritas, podemos indicar a nivel de usuario, las
autorizaciones de acceso al menú Sap o al menú de usuario. Esto se configura
a través de la transacción SM31, en la tabla USERS_SSM. En la imagen
podemos observar un ejemplo: el usuario TM02011 solo tiene acceso al menú
de usuario, el usuario RESPINOSA a ambos y el usuario ACIGANDA solo al
menú Sap. Esto nos permite personalizar la configuración usuario por
usuario, en lugar de la configuración general que vimos antes.
Ademas, en la tabla SSM_CUST podemos indicar otros valores para ajustar los
menús de usuario y evitar determinadas problematicas, como la redundancia de
entradas ( id CONDENSE_MENU), evitar las transacciones duplicadas (
id DELETE_DOUBLE_TCODES) o configurar la ordenación de la entradas
en el menú de usuario (id SORT_USER_MENU). En la nota del
OSS 357693 se explica en detalle la forma de configurar estos valores.
Como vemos, tenemos disponibles opciones suficientes para configurar el
sistema según nuestras necesidades y las diferentes problemáticas de usuarios
con las que nos podamos encontrar (usuarios avanzados, usuarios que solo
accede a un número limitado de transacciones, etc).
Además de todo esto, Sap nos permite configurar el menú estándar, ampliándolo
para incluir nuestra propia estructura de carpetas o nuestras transacciones en los
puntos de menú estándar más apropiados para su accesibilidad por parte del
usuario final. La forma de configurar esto la veremos en la próxima entrada del
blog. Veremos que es una configuración general y que, al tratarse de una
ampliación, será respetada por Sap en los procesos de Upgrade cuando
realicemos un cambio de versión
Truco 6. Ampliacion de ayudas de
busqueda (Matchcode).
3 Votes
En muchas ocasiones, las ayudas de busqueda estandar de Sap

(Matchcode), a las que accedemos como ayuda para completar los valores de
los campos pulsando la tecla de función F4, son insuficientes para nuestras
necesidades o no tienen en cuenta cosas tan obvias como no incluir registros
que tienen peticiones de borrado.
Para estas ocasiones, tenemos la posibilidad de definir nuestras propias ayudas
de búsqueda (Z) e incluirlas como una ayuda adicional en las ayudas estandar.
Las ayudas estandar suelen ser ayudas complejas que incluyen varias ayudas
simples, que podemos ir seleccionando según nuestras necesidades (en la
imagen, podeís ver las ayudas de búsqueda disponibles cuando estamos dando
de alta datos maestros de cliente a través de la transacción XD01).
Como ejemplos de ayudas de búsqueda que habitualmente se van a tener que

definir en el sistema, tenemos:
 Administración de personal: búsqueda por el segundo apellido, ya que
es muy frecuente empleados con los mismos apellidos, y este tipo de
búsqueda no esta incluido en el estandar.
 Datos maestros: ayudas de búsqueda que excluyan registros con petición
de borrado. Esto puede aplicar a proveedores, clientes, materiales, etc.
 Busqueda por otros criterios: en muchas ocasiones nos puede interesar
buscar por otros criterios que no son estandar, campos de cliente u otros
campos estandar que andan perdidos en los datos maestros pero por los que
nos interesa realizar búsquedas.
 Ayudas personalizadas: también podremos incluir ayudas que ataquen a
tablas Z o a vistas de datos estandar y tablas de cliente. Por ejemplo, en un
sistema con control de imputaciones por cuentas contables, incluir una
ayuda de búsqueda que nos indique, por cuenta contable, donde podemos
imputar (tirando de tablas de cliente).
Los pasos para la creación de una ayuda de búsqueda y su inclusión en la
estandar serían los siguientes:
1. Asegurarnos que las ayuda de búsqueda estandar no cumplen con los

requerimientos que necesitamos en la instalación.
2. Localizar el nombre de la ayuda de búsqueda estandar asociada a un
determinado campo. Para ello, tendremos que investigar, pues la ayuda
puede estar asociada en la definicion de la tabla donde se utiliza el campo
(transacción SE11), a nivel de la dynpro (pulsando F1 sobre el campo
podremos localizarla) o bien a nivel de elemento de datos (también se accede
desde la SE11)
3. Definir los campos por los que queremos buscar y localizar las tablas donde
se encuentran.
4. Crear la ayuda de búsqueda (partiendo desde cero o bien utilizando como
modelo una de las ayudas estandar). La creación de las ayudas se realiza
desde la transacción SE11.
5. La creación de la ayuda de búsqueda puede llevar aparejado también la
creación de una vista de acceso a datos, que incluya los campos/tablas que
necesitamos para nuestro proposito. Esto se hace también desde la
transacción SE11.
6. Verificación de la ayuda e inclusión como ayuda adicional en la ayuda
estandar. Este paso permitirá que la ayuda creada este disponible en el
sistema como una ayuda mas, y al desplegar las disponibles, nos aparezca la
nuestra como un elemento mas en los matchodes.
EJEMPLO PRACTICO. BUSQUEDA DE
EMPLEADOS POR EL SEGUNDO APELLIDO.
En nuestro ejemplo, vamos a crear una ayuda de búsqueda por segundo apellido
para los datos maestros de empleados. Según los pasos que hemos descrito
antes:
1. Revisión de las ayudas de búsqueda existentes, asegurandonos que

ninguna cumple nuestras necesidades.
Entramos en la transacción PA20, y abrimos el matchcode sobre el campo
Número de empleado. Tenemos disponibles varias ayudas de búsqueda, pero
ninguna por este concepto.
2. Localizar la ayuda de búsqueda estandar.
Nos posiciones en el campo y pulsamos F1. En este caso, la ayuda de búsqueda
esta definida en la dynpro, y se nos muestra en la información técnica del
campo. Sino hubiera estado disponible la información ahí, hubieramos tenido
que acudir a la definición de la tabla (RP50G en este caso) o bien al elemento de
datos (PERNR_D) para buscarla.
Accedemos a la transacción SE11 y consultamos la ayuda PREM. Es una ayuda

de búsqueda compuesta por varias ayudas simples (que son las que podemo
seleccionar al buscar).
Vamos a tomar como modelo la ayuda de búsqueda PREMN, que es la más
parecida a nuestras necesidades.
3. Localizar los campos por los que queremos buscar.
La información del segundo apellido del empleado se encuentra en la tabla
PA0002, en el campo NACH2.
4. Creación de la ayuda de busqueda (ZPREMN).

Desde la transacción SE11 copiamos la ayuda PREMN en la nueva ayuda
ZPREMN. Creamos la vista que incluye el campo que nos falta (como veremos
en el paso 5), y realizamos el ajuste de los parámetros de la ayuda como sigue:
En la columna PosS indicamos los campos los campos que aparecen en la ayuda
de búsqueda cuando entramos a ella y en que orden. En este caso los campos
son NCHMD (1er apellido), NACH2 (2º apellido) y VNAMC (nombre). Son los
campos que nos permiten restringir los resultados de búsqueda.
En la columna P.I indicamos los campos que aparecen en los resultados de

búsqueda y en que orden. El campo PERNR (número de empleado) esta
marcado en la columna EXP como valor de retorno al campo donde se este
utilizando la ayuda de búsqueda.
En la ayuda se pueden definir otros parámetros, como el tipo de dialogo cuando

se ejecuta la ayuda, si tenemos una tecla de acceso rápido o una exit asociada a
la ayuda (para permitir otro tipo de personalizaciones).
5. Creación de la vista asociada a la ayuda de búsqueda.

La ayuda requiere una nueva vista, como hemos indicado, pues tiene campos
que no tenemos disponibles en la vista M_PREMN (que es la que utiliza la
ayuda PREMN). Para ello, creamos la vista ZM_PREMN como copia de la
mencionada, y añadimos el campo NACH2.
En este caso no es necesario, pero en otros puede ser necesario incluir nuevas
tablas, campos y las correspondientes relaciones entre las tablas existentes para
definir correctamente la vista.
6. Asignación de la ayuda en la ayuda estandar.

En la transacción SE11, modificamos la ayuda estandar PREM, e incluimos la
ayuda creada. Es fundamental para que funcione correctamente realizar la
Asignación de parámetros, que es el enlace entre la ayuda de búsqueda simple
(la que hemos creado) y la ayuda de búsqueda compuesta donde se incluye.
A partir de este momento, la ayuda ya esta disponible en todas las pantallas de
las transacciones donde se utilize la ayuda PREM. Bastara seleccionarla entre
las disponibles e indicar los criterios de búsqueda. La ayuda nos permite buscar
por el segundo apellido y visualizar también este dato en los resultados de
búsqueda.
Otra utilidad más que nos va a sacar de algún apuro y que nos va a permitir
personalizar nuestro sistema Sap y sobre todo, hacerle al usuario más rápidos
los procesos de búsqueda.
Truco 7. Uso de User-exits para verificaciones en
datos maestros.
5 Votes
En muchas ocasiones necesitamos modificar el comportamiento del

estandar de Sap para incluir verificaciones adicionales en los
procesos. Por ejemplo, nos puede interesar incluir comprobaciones en los
datos maestros (clientes, proveedores, materiales), realizar chequeos
adicionales en cualquier otra transacción (contabilizaciones, registro de
documentos de ventas o de compras, etc) o intervenir en la forma en que se
comporta el sistema (por ejemplo, numeración en facturas o documentos de
venta, generación de contabilidad, determinación de proveedor o stocks, calculo
de condiciones de precio, etc, etc).
Para este tipo de casuísticas, Sap nos deja una puerta abierta a través de las
Exits (concepto que se ha ido ampliando en las ultimas versiones con las Badis y
los enhancements en el código). Ya entraremos más adelante en analizar como
incluir verificaciones adicionales incluyendo estas últimas funcionalidades.
Ahora nos vamos a centrar en las Exits. En una entrada anterior del
blog explicamos como, a través de un desarrollo Abap, localizar las exits que
tenemos disponibles en una determinada transacción. También vimos
un ejemplo de como configurar una exit que realiza verificaciones adicionales en
el proceso de logon al sistema.
Además, en las notas OSS suele haber información sobre las ampliaciones
disponibles, y también podemos buscar en la documentación de la transacción
SMOD.
EJEMPLO PRACTICO: VERIFICACION

ADICIONAL DE NIF DUPLICADOS EN LOS DATOS
MAESTROS DE CLIENTES.
Queremos añadir una verificacion adicional en nuestro sistema para evitar que
un cliente (con un numero de identificacion fiscal), se duplique en el sistema.
Para ellos realizaremos los siguientes pasos:
1) Identificar la transacción y localizar las exits disponibles en la
transacción.
El mantenimiento de datos maestros de clientes se realiza con las transacciones
FD01 o XD01 (según si estamos dando de alta el cliente solo en finanzas o
también en el módulo de ventas). Ejecutamos el report que os he indicado antes,
introduciendo el nombre de la transacción, y el resultado es el siguiente:
Desde la misma utilidad accedemos a la transaccion SMOD, donde podemos

ver los componentes de esta. Podriamos haber utilizado esta transacción para
buscar las exits, tal y como vemos en la imagen. Los objetos en Sap se agrupan
en paquetes, y sabiendo el paquete de una aplicación, podemos intentar buscar
las ampliaciones disponibles.
Importante: cada exit esta definida de forma que en ella vamos a tener
disponible una serie de variables, estructuras de datos o tablas que son las que
podremos utilizar posteriormente en el código abap para realizar las diferentes
verificaciones o acciones sobre los datos. Las exits son siempre un módulo de
función (se pueden ver desde la transacción SE37), con sus correspondientes
parametros de import (se reciben en la exit), export (se devuelven) y tablas de
datos. La exit lleva un include a un programa Z que no existe y que nosotros
crearemos para introducir el código abap propio dentro de el.
2) Creación de un proyecto de ampliación e inclusión de la

ampliación localizada.
Creamos el proyecto de ampliación ZCLIENTE con la transacción CMOD, e
incluimos en el la ampliación SAPMF02D. En el módulo de función asociado,
EXIT_SAPMF02D_001, esta la llamada al include que hemos mencionado
(ZXF04U01 ). Lo crearemos haciendo doble clic sobre el. La exit no estara activa
en el sistema hasta que no activemos el proyecto de ampliación.
3) Desarrollo del código que implementa la validación.

En la estructura I_KNA1 estamos recibiendo los datos maestros del cliente (la
parte general), donde se encuentra su nombre, dirección, datos fiscales, etc. En
el código recibiremos estos datos y verificaremos contra la tabla KNA1, que no
exista un cliente ya creado con el mismo NIF. En la verificación no se tendrán
en cuenta registros de cliente con petición de borrado. El código de nuestra
comprobación sería el siguiente:
*&-----------------------------------------------------------
----------*
*& Include ZXF04U01
*&----------------------------------------------------------
-----------*
* Definición de la tabla maestro de cliente, contra la cual v
erificaremos.
TABLES: kna1.
DATA: lv_kunnr LIKE kna1-kunnr.
* Si el pais es ESPAÑA tiene que tener rellenado el NIF nor

mal
IF i_kna1-land1 = 'ES' AND i_kna1-stcd1 IS INITIAL.
MESSAGE e000(zfi). "Campo NIF obligatorio.
* Chequeamos que no esté repetido el NIF.
ELSEIF i_kna1-land1 = 'ES' AND i_kna1-stcd1 IS NOT INITIAL.
CLEAR lv_kunnr.
SELECT SINGLE kunnr INTO lv_kunnr
FROM kna1
WHERE kunnr <> i_kna1-kunnr
AND stcd1 = i_kna1-stcd1
* Si el cliente tiene peticion de borrado no lo tiene que ten

er
* en cuenta en la verificacion de nif duplicados.
and LOEVM ne 'X'.
* Fin Modif.
* Si encontramos un Cliente con el mismo NIF -> ERROR
IF sy-subrc = 0.
MESSAGE e008(zsistemas) WITH 'EL cliente' lv_kunnr 'tien

e el mismo NIF'.
ENDIF.
endif.
La verificación es sencilla, pero podriamos haber incluido otras como exigir

valores obligatorios en campos según el valor de otros campos, actualización de
tablas Z, interfases con otros sistemas, etc.
4) Verificación y pruebas. Puesta en productivo.

Activamos el proyecto de ampliación para probarlo en nuestro sistema de
pruebas. Hacemos una simulación duplicando un cliente y el sistema nos
muestra el siguiente mensaje al intentar dar de alta un nif duplicado:
La verificacion se realiza cuando vamos a

grabar, al final de todo el proceso de alta de datos maestros. La
verificación también es efectiva cuando estemos modificando los
datos maestros existentes.
NOTA SOBRE USER-EXITS
En algunos módulos de Sap (como en Ventas), no todas las exits se gestionan
deste las transacciones SMOD/CMOD. Algunas exits estan documentadas en el
customizing y son simplemente includes de programa donde nosotros podemos
incluir nuestro código (es una especie de modificación del estandar permitida
por Sap). Tiene el incoveniente, respecto a los proyectos de ampliación, que se
pierde el rastro de las que tenemos implementadas y es más difícil tenerlas
documentadas. Ademas, es más fácil activar/desactivar una exit gestionada
desde la SMOD (en las otras habrá que comentar todo el código para que no se
ejecute si queremos paralizarla en determinadas situaciones, como por ejemplo,
en cargas iniciales). En la imagen, se muestran las exits disponibles en el arbol
de customizing, en el módulo de ventas.
Para terminar, os dejo algunos links donde se detallan algunas de las user-exits
mas frecuentes existentes en los módulos de ventas de Sap (SD), gracias
a Saptricks:
1. User Exits para el chequeo de disponibilidad de crédito y riesgos..
2. User Exits en procesos de expedicion.
3. User Exits para facturación.
4. User Exits para determinación de Precio
5. User exits en proceso de documentos de Venta.
Tutorial: creación de planes de facturación en compras.
Publicado el 5 mayo, 2011por Roberto Espinosa
1 Vote
En todas las empresas tenemos ejemplos de compras reguladas por contrato, y

que tienen una periodicidad determinada, tras la cual llegará la correspondiente
factura u obligación de pago. Por ejemplo, contratos de mantenimiento
informático, servicios profesionales, alquileres, etc.
En estos casos, nos va a llegar regularmente la correspondiente factura, y no es

necesario realizar una entrada de mercancía para confirmar que el servicio se ha
realizado, pues los servicios se rigen por un contrato o acuerdo de referencia.
Para este tipo de casuísticas, utilizaremos en Sap los planes de

facturación. Los planes se registran a través de los pedidos de
compra (transacción ME21N), teniendo en cuenta lo siguiente:
A nivel de posición, siempre hay que desmarcar la casilla Entrada mercancía en
la pestaña Entrega.
A nivel de posición, siempre hay que desmarcar la casilla Verificación Factura

basada en EM en la pestaña Factura.
Tras desmarcar las dos casillas, nos aparece un nuevo botón en la pestaña
Factura, que nos permite acceder al registro del plan de facturación. El plan de
facturación nos permite definir un calendario de recepción de facturas, asociado
a la posición del pedido que estamos tratando.
Los valores mas importantes que podemos introducir en el plan de facturación

son los siguientes:
 Clase de plan de facturación: es el modelo para la creación del plan de
facturación. Lo habitual es usar un plan de facturación periódico para la facturación
de servicios que son regulares. Podremos parametrizar nuestras propias clases de
planes. Se nos pide la primera vez que entramos en el plan de facturación, al
crearlo.
 Fecha de inicio: fecha de inicio del plan (validez).
 Fecha final: fecha fin.
 Regla determinación de fechas: en el modelo de plan de facturación definimos
la frecuencia de la facturación (periodos mensuales, trimestrales, etc), así como el
día de referencia (a principio de mes, a final de mes), etc.
 Por adelantado: se marca cuando las facturas de un periodo se van a recibir por
adelantado.
Con los valores indicados, el sistema construye la tabla del plan de facturación,
que determinará los diferentes periodos, y las fechas en las que están previstas
la emisión de facturas por parte del proveedor. Una vez registrado el plan de
facturación, ya se podrán registrar las correspondientes facturas en
la transacción MIRO (si el pedido tiene estrategias de liberación, tendrá que
ser liberado previamente).
Una vez registrada la factura contra una de las posiciones del plan de
facturación, se cambia el estado de la posición a nivel del plan de facturación, tal
y como podemos observar en la imagen siguiente.
PARAMETRIZACION DE LOS PLANES DE FACTURACION.
Se accede desde la ruta de customizing siguiente:
Gestión de materiales –> Compra –> Pedidos –> Plan de
facturación.
Algunos de los elementos que podemos parametrizar para los planes de
facturación son los siguientes:
Clase de plan de facturación.

Determina los valores con los que se inicializa el plan de facturación al crearlo:
propuesta de fecha inicio y fecha fin, regla de determinación de fechas
(periodicidad y fecha de facturación a proponer), si es una facturación por
adelantado o no, un calendario de laborables para ajustar las fechas de
facturación, etc.
Esto solo tiene efecto al crear el plan de facturación, y actúa como una plantilla
de inicialización de valores.
Reglas de determinación de fechas.
Determina el método para calcular las fechas de facturación previstas al
construir el plan de facturación.
En nuestro caso, hemos añadido dos reglas para determinación de fecha
Trimestrales, además de las mensuales que ya existían. Veamos un ejemplo de
una regla para facturación mensual, y otra para trimestral:
En la regla mensual, indicamos que la fecha base es la fecha de factura, en el
periodo indicamos 1, y como unidad el mes (podemos indicar dias, semanas,
meses o años para ajustar el calculo de las fechas de facturación a nuestras
necesidades).
Además, podemos indicar si queremos que se proponga el primer día del mes o
el último, y un calendario de fábrica, donde se podrá introducir en que fechas
suele facturar el proveedor, para ajustar más aún las fechas propuestas.
Para el caso de la regla trimestral, hemos indicamos en el periodo el valor 3, y

como unidad el mes. De esta forma, estamos indicándole al sistema que el
cálculo nos lo hago en periodos trimestrales.
Ahora, nos vamos al pedido e indicamos la nueva regla de determinación de
fechas (la trimestral). El plan de facturación se recalcula, teniendo el siguiente
aspecto:
Para terminar, os dejo el enlace al contenido de esta entrada en formato PDF, a
modo de Manual de Usuario.
Preparando la certificación MM de Sap.
18 Votes
Si estais pensando en aprender o certificaros en Sap en el Módulo MM, aquí os

dejo algo de información interesante que os puede ayudar en este cometido.
Sap propone varios niveles de certificación (+info en la web de Sap), con un

examen en el que verificar nuestros conocimientos en la gestión de la cadena de
suministro (SCM) y los procesos de compras utilizando Sap:
 Certificación Associate. Es necesario un conocimiento fundamental de las
soluciones SAP y la adquisición de una amplia competencia. Es el nivel más
básico.
 Certificación Proffesional: Es necesaria la experiencia demostrada en
proyectos, conocimientos sobre procesos empresariales y una comprensión
más detallada de las soluciones SAP. Es el nivel medio.
 Certificación Master: Es necesaria la experiencia demostrada con respecto
a aspectos específicos de las funcionalidades y tecnología SAP, así como la
capacidad de fomentar la innovación y la optimización de las soluciones
necesarias para cubrir tanto los requisitos técnicos como los empresariales en
una organización. Nivel más avanzado.
Para poder acceder al nivel necesario para la certificación, disponemos de
múltiples ofertas formativas, que suelen ser necesarias para la obtención de la
certificación o como complemento de una experiencia anterior trabajando con el
módulo. En estos cursos se suele ofrecer material y un acceso a un sistema Sap de
test donde practicar con los conocimientos teóricos impartidos. El itinerario para
la certificación consiste básicamente en los cursos TSCM50 y TSCM52, aunque se
puede obtener de forma alternativa con los cursos SCM500, SCM510, SCM515,
SCM520, SCM525 y SCM550.
Una vez terminada la realización del curso o la preparación de la certificación (en
el caso de que tengamos experiencia previa en Sap trabajando en el módulo que
queramos complementar con la certificación), podemos inscribirnos al examen
en la web de Sap. Existe un calendario amplio de fechas de examen, el cual dura
180 minutos, consistiendo en 80 preguntas relacionadas con el temario de curso,
con una ponderación por áreas que se explica aquí. El precio del examen es de
425 € + Iva (en España).
Aquí os dejo algo de material que os puede ser útil para el caso de que queráis
preparar la certificación por vosotros mismos, aunque desde mi modesto punto
de vista, puede no ser suficiente y es conveniente recibir una formación específica
con profesorado especializado en el módulo o con experiencia en proyectos Sap.
 Manual de Instructor del curso TSCM50 (Ingles): Parte 1 y Parte 2.

 Manual de Instructor del curso TSCM52 (Ingles): Parte 1 y Parte 2.
 Manual de Instructor TSCM50 (Español): TSCM50-1-ES-Col62-FV-
Inst-A4 y TSCM50-2-ES-Col62-FV-Inst-A4.
 Manual de Instructor TSCM52 (Español): TSCM52-1-ES-Col62-FV-
Inst-A4 y TSCM52-2-ES-Col62-FV-Inst-A4.
 Manual de Alumno: TSCM50 y TSCM52. El manual de alumno del curso, en
castellano y en formato Doc para incluir nuestras propias anotaciones. No
incluye los ejercicios prácticos, pero si toda la teoria del manual de instructor,
perfectamente traducida al castellano (eliminar la extensión DOC del archivo
al descargar, ya que es un fichero comprimido tipo RAR).
Algunas empresas venden acceso a sistemas Sap incluyendo funcionalidad
completa con disponibilidad de las opciones de usuario y parametrización
(configuración del sistema). Es indispensable disponer de un entorno de pruebas
para poder consolidar todos los conocimientos necesarios para el examen. Aquí
os dejo algunos links para obtener información (el único sistema que he probado
es el de Sapconexion y funciona bastante bien):
 SapConexion.
 Idesacces.
 ErpTrainingUK.
 Fuzeserver.
 Acceso servidor Ides via web. El servidor es gratuito, aunque hay que renovar
diariamente las contraseñas de acceso.
Por precios razonables, podemos contratar acceso por periodos de tiempo (1 mes,
3 meses, 1 año) a un sistema que incluye toda la funcionalidad requerida en el
módulo en el que estemos interesados. Incluso algunos nos pueden dar clave de
desarrollador si estamos interesados en trabajar o formarnos con Abap.
Para terminar, una buena prueba para comprobar cual es el nivel de vuestros
conocimientos son los siguientes exámenes online:
 Repositorio de preguntas de certificación relacionadas con MM: ver aquí.

 Test de conocimientos de Sap MM en
castellano: http://www.daypo.com/test-examine-conocimientos-sap-
mm.html.
 100 preguntas de certificación:
link SAP_MM_Interview_Questions_Answers_and_Explanations. Manual
de configuración MM, link SAP MM – Functionality and Technical
Configuration.
 Otro cuestionario aquí.
 Ejemplos de preguntas de Examen: gracias a Javiera Parada. Preguntas
examen 1, Preguntas examen 2, Preguntas examen 3 y Preguntas Examen 4.
También podéis ver un ejemplo de preguntas del examen en la propia Web de
Sap. Respecto a los examentes, el porcentaje de preguntas a acertar para poder
aprobar el examen de certificación es variable (puede estar entre el 60 y el 70%
según el módulo).
FORMACION EN EL MODULO SAP MM.
Si estáis interesados en recibir formación en el módulo SAP MM, como ayuda
para formaros en el uso y parametrización de este módulo, o como preparación
para la certificación oficial, actualmente ofrezco clases personalizadas con acceso
a un sistema de pruebas incluido. Consulta metodología del curso,
temario, tarifas y fechas disponibles en los siguientes enlaces:
 Metodología del curso e información: link aquí.
 Temario: link aquí. Podeís descargarlo en formato PDF aquí.
 Opinión de los alumnos del curso aquí.
Truco 13. Transacciones personalizadas con las
variantes de transacción (SHDO).
17 Votes
Conocer otra funcionalidad como la que nos ofrece la transacción SHD0 nos
puede ser muy útil en ocasiones en las que queremos personalizar el
comportamiento de las transacciones estándar (o incluso la desarrolladas
por nosotros mismos).
En muchas transacciones podemos por customizing o por opciones de usuario
personalizar valores predeterminados al entrar en ellas (clase de documento en
transacciones de contabilización, valores predeterminados en documentos de
compras, parametros de memoria para datos de unidades organizativas
(sociedad, organización de ventas, sector), etc).
Pero a traves de las variantes de transacciones y de pantalla, podemos

personalizar y simplificar los procesos mediante:
 la asignación previa de campos con valores (valores predefinidos en campos)

 la supresión y modificación de la disponibilidad para entrada de los
campos.
 la supresión y modificación de los atributos de las columnas en los table
control (tablas de introducción de datos en muchas de las transacciones estándar).
 la supresión de las funciones de menú.
 la supresión de todas las imágenes.
Algunas de estas funcionalidades pueden estar disponibles a través del
customizing (por ejemplo, mostrar o suprimir determinados campos en el
mantenimiento de datos maestros de clientes, proveedores, materiales, cuentas o
en los procesos de compras, ventas, contabilidad, etc), pero son opciones globales
que afectan a todos los usuarios. En cambio, con las variantes de transacción
podemos personalizar los procesos de transacción según el tipo de tarea o
funciones que realiza un usuario, para hacer la introducción de datos más rápida,
concisa, eliminando campos, pantallas u opciones de menú innecesarias o
inicializando los valores con valores propios o repetitivos para hacer más
productivo el trabajo del usuario. Aunque es importante remarcar que esta
personalización siempre tendrá que respetar la lógica de las
aplicaciones: campos obligatorios, verificación de valores introducidos, etc,
que nunca nos vamos a poder saltar.
Vamos a realizar 3 ejemplos sencillos de lo que podríamos configurar utilizando
esta funcionalidad:
1. Grabación de apuntes contables fijando la clase de documento y un texto de
cabecera.
Queremos dejar preparada la entrada de datos a un usuario de forma que siempre
se le inicialice el valor de la clase de documento (que no será modificable) y le
proponga un texto de cabecera del documento (si modificable).
Pasos a seguir:
a) Creación de la variante: entramos en la transacción SHD0, indicamos la

transacción para la que vamos a crear la variante (la FB50), el nombre de la
variante de transacción (ZAPUNTES_CAJA) y pulsamos el icono Crear (F5).
La grabación nos lleva a la transacción que estamos personalizando.
Introducimos los diferentes valores y pulsamos Intro.
Se nos grabará una variante de pantalla por cada pantalla que existiera en la
dynpro de la transacción. En las variantes podremos indicar para cada
campo, si mantiene el contenido introducido al grabar, si es visible o
no, obligatorio o de solo salida (impedimos que se pueda modificar su
contenido).
b) Ajuste de la variante: al salir de la transacción, se recogen todas las
variantes de pantalla creadas, y se crea la variante de transacción propiamente
dicha, a la que habrá que poner una descripción.
Aquí podremos ajustar los diferentes campos de las pantallas, adaptandolos a
nuestras necesidades, tal y como hemos comentado (visibles o no, obligatorios,
solo salida, etc).
c) Creación de una transacción: la transacción de variante hay que
convertirla a una transacción para que pueda ser ejecutada directamente por los
usuarios, incluirla en los menús estandar o de rol. La crearemos con
la transaccion SE93, indicando un código de transacción (por ejemplo,
ZFB50), una descripción y el tipo de transacción “Transacción con
variantes”.
Al crear la transacción, indicaremos la transacción estándar y el nombre de la

variante que hemos creado. Importante siempre marcar el flag Valido para todos
los mandantes.
d) Inclusión en el arbol de menú con la transacción SE43N para el menú
estandar o bien en los roles asignados al usuario (transacción PFCG), para que
aparezca en sus menús de usuario.
Al entrar en la transacción ZFB50, ya nos aparece los campos personalizados
según nuestra configuración.
Siguiendo el mismo procedimiento, vamos a preparar dos transacciones

personalizadas mas.
2. Creación de pedidos de venta, omitiendo la primera pantalla donde se

introduce clase de documento y organización de ventas.
Personalizamos la transacción VA01 con la diferencia del ejemplo anterior que en
la variante de pantalla para la primera dynpro de la transacción, marcamos el flag
“No visualizar imagen” y llenamos los campos de clase de documento,
organización de ventas, canal de distribución y sector.
Cuando el usuario entre a la transacción personalizada, no pasará por esa pantalla
y accederá directamente a la grabación del pedido, con los valores indicados
predeterminados.
3. Personalización del table control en la grabación de pedidos de compras,
omitiendo opciones de menú.
En este caso vamos a personalizar la transacción ME21N. Entramos en la SHD0
y nos quedamos en principio solo con la dynpro 1211, que es la que tiene el detalle
de las posiciones de compras.
En este caso, suprimimos un montón de campos del table control que no son
relevantes (marcando el flag invisible). Ademas, de la barra de botones
disponible, ponemos como solo salida los que permiten borrar o bloquear
posiciones. Esta opción solo la podrán realizar determinados usuarios en la
transacción estandar.
Estos son algunos ejemplos de lo que nos permiten las variantes de transacción.
Sin duda, algo muy interesante y potente. Y con muchas posibilidades para
aquellos caso de usuarios que utilizan pocas funcionalidades del sistema o para
los que queremos evitar errores o mejorar de forma notable su productividad.
También podriamos haber ajustado las opciones de menú disponibles, tal y
como os muestra en la siguiente imagen para la transacción VA05n (listado de
pedidos de venta).
Seleccionando el botón Funciones de menú al crear la variante, nos aparecen
las opciones de menú, que podemos activar o desactivar (tanto opciones de
menús y submenus, como botones y barras).
NOTA: la transacción SHD0 también nos permite asignar las variantes de
transacción creadas como variantes predefinidas en las transacciones estandar.
Aunque esta es una opción que habrá que tratar con mucha cautela, pues puede
producir mas problemas que ventajas.
La SHD0 solo esta disponible para transacciones con dialogo. Y en las
transacciones que ejecutan reports, solo las podremos utilizar para ajustar las
opciones de menú disponibles.
Truco 14. Análisis de autorizaciones. Traza.
Publicado el 26 junio, 2011por Roberto Espinosa
12 Votes
La gestión de autorizaciones en Sap es un tema complejo, sobre todo si queremos

restringir el acceso a los usuarios a su ambito de actuación y funciones, evitando
la modificación o consulta de datos en módulos para los que no debería de estar
autorizado.
En esta entrada del blog no voy a entrar en profundidad en el tema de

autorizaciones, lo que requeriria una serie de articulos para poder abordar todos
los aspectos a tener en cuenta de una forma profunda. Simplemente os voy a
mencionar algunas transacciones interesantes para el caso de que
tengamos problemas de autorizaciones y queramos analizar donde
reside el problema.
Objetos de autorización verificados en una transacción.
Con la transacción SU24 podemos ver las autorizaciones asociadas a una
transacción y que se verificaran cuando entremos en ella.
En el ejemplo, en la transacción PA20 (consulta de datos maestros de

empleados), vemos que se verifican los objetos típicos para acceso a datos de
administración de personal (P_ORGIN, P_PCLX, P_PERNR, PLOG).
Ultima verificación de autorizaciones realizada en el usuario actual.

Cuando intentamos acceder a una transacción o intentamos realizar algún
proceso sobre algún objeto sobre el que no estamos autorizados (aunque si
tengamos acceso a la transacción donde se realiza este), la revisión del objeto de
autorización que ha fallado la podemos realizar a traves de la transacción
SU53.
En la imagen podemos ver el resultado de la transacción, despues de intentar
acceder a una transacción de finanzas (la FB50 de contabilizaciones), para la que
no estamos autorizados.
En la parte superior aparece el objeto de autorización verificado que no
disponemos en nuestro perfil, y en la parte inferior los valores que si tenemos en
nuestro perfil para ese objeto de autorización, pero que no son suficientes para
poder acceder al objeto.
Es conveniente incluir la transacción SU53 en los perfiles de todos los usuarios

para agilizar las tareas de administración (se puede permitir que todos los
usuarios del sistema tengan acceso a las transacciones SU53 y SU56 con el
parametro de sistema auth/tcodes_not_checked). Solo aparece el último
objeto de autorización revisado que ha fallado.
Autorizaciones existentes en el perfil de usuario actual.
Aunque las autorizaciones de las que dispone un usuario pueden ser consultadas
desde la transacción SU01 (en la pestaña de Roles o Perfiles), desde aquí no
veremos el detalle de objetos de autorización asignados al usuario. Para ello,
tenemos la interesante transacción SU56 que nos muestra de forma detallada
los valores de autorizaciones asignadas a un usuario que residen en la memoria
intermedia del sistema.
Traza de autorizaciones.
Cuando tenemos verificaciones de autorizaciones complejas, el uso de la
transacción SU53 puede ser muy incomodo pues el sistema nos avisará de la
autorización que falta, la incluiremos en el perfil del usuario, volverá a fallar otro
objeto, etc. Así hasta que podamos identificar todo lo que nos falta e incluirlo en
los correspondientes roles o perfiles.
Para simplificar esta tarea de identificar las autorizaciones verificadas, podemos

utilizar la traza de contexto (transacción STKONTEXTTRACE) o bien la
clásica traza de sistema (transacción ST01). En ambas transacciones
podemos analizar otros aspectos ademas de las autorizaciones, como las traza
SQL, de memoria intermedia, RFC, etc.
En la traza de contexto indicaremos la transacción a analizar, marcaremos el flag
trace de autorización y realizaremos las tareas en el sistema como si fuesemos el
usuario para el que estamos preparando o revisando los perfiles de autorización.
Una vez completada la traza, la revisaremos desde la transacción ST01, desde
la opción evaluación. El programa nos mostrará todos los objetos de autorización
verificados, con sus correspondientes valores para cada uno de sus campos. Con
el resultado podremos preparar un perfil de autorización que incluya todo lo
necesario para el trabajo del usuario.
La traza también la podremos realizar desde la transacción ST01
directamente, llevando cuidado en marcar el flag Verif. Autorización,
e indicar los correspondientes filtros (por ejemplo, un usuario o una
transacción), ya que sino la traza se realizará sobre todos los usuarios
del sistema, y es un proceso pesado que puede afectar al rendimiento del
sistema.
NOTA: Transacciones para el mantenimiento de las autorizaciones.
PFCG Mantenimiento de Roles de Autorizacion (incluidos los menús de
Rol que se asocian al usuario). El mantenimiento se realizaba antiguamente con
la transacción SU02. El rol incluye los perfiles de autorización, que son una lista
de objetos de autorización con valores asignados en sus campos, que son los que
determinan que acciones podemos realizar en el sistema.
SU21 Mantenimiento de objetos de autorizacion (para visualizar los
estandar o crear nuestros propios objetos de autorizacion para las transacciones
de cliente). También se puede acceder desde la SU03.
SU20 Mantenimiento de campos de autorizacion (un objeto de
autorizacion se compone de varios campos).
Truco 17. Añadir nuevos campos en
informes comerciales.
Publicado el 29 agosto, 2011por Roberto Espinosa
7 Votes
Para concluir la serie de ampliación de algunos de los informes estándar más

importantes, vamos a ver hoy la forma de incluir nuevos campos en los informes
comerciales (pedidos, facturas, etc).
En nuestro ejemplo, vamos a añadir algunos campos en la transacción de

listado de pedidos de ventas (VA05). Para ello, accederemos al
customizing desde la ruta Comercial –> Adaptación del sistema –> Inclusión de
nuevos campos (sin técnica de condiciones) –> Nuevos campos para las listas de
documentos comerciales –> Otros campos visual.para listas de documentos de
ventas. Tambien podemos acceder con la transacción VOA01.
Los pasos a seguir son basicamente tres:

1) Campos autorizados (vista V_T180A): pulsando el botón campos
permitidos, podemos ver los campos disponibles para el listado de pedidos. En
el caso de que el campo deseado no se encuentre en la lista, lo añadiremos.
Crearemos un campo con la nomenclatura ZZ_NOMBRECAMPO, para que

nunca colisione con los campos estandar de Sap. Es necesario que el campo
se defina en esta tabla, ya que sino no lo podremos utilizar en los pasos
siguientes de la configuración.
2) Inclusión del campo en la estructura VBMTVZ: accediendo desde la
opción Ampliación de estructura –> Mejoras de cliente para: Posiciones de
pedido para material, realizamos el mantemiento de la estructura VBMTVZ,
donde incluiremos el/los campos que queramos que aparezcan posteriormente
en la lista de pedidos.
3) Ajuste del include V05TZZMO donde se llenara el valor del campo:
en esta sección escribiremos el código Abap para llenar los valores del campo.
En este caso, el campo ya existe en la cabecera del pedido de venta (tabla VBAK)
y nos limitaremos a moverlo a nuestro campo de cliente, pero en el caso de un
campo que incluya información de otro lugar (cliente, materiales, etc) o un
cálculo, lo podremos realizar sin problema con nuestro código Abap.
Es importante incluir el código en el lugar correcto (VBAK Cabecera de pedido,
VBAP Posiciones de pedido, etc). Y tener en cuenta que hay campos que aunque
esten en la estructura de datos, no tienen porque aparecer en el listado estándar
disponibles, algo que es lógico teniendo en cuenta la cantidad de campos
posibles que tiene el estandar.
Con este último paso, hemos terminado la configuración de la lista de pedidos y
el nuevo campo ya estará disponible en la transacción VA05. Antes de que el
usuario lo visualize en la lista, un pequeña consideración sobre el
mantenimiento de las variantes de visualización en los informes comerciales:
El mantenimiento de variantes en los informes comerciales no esta

habilitado por defecto, y solo se realiza cuando el usuario tiene en su
perfil el parámetro SD_VARIANT_MAINTAIN (Authorization for variant
maintenance) con el valor A. Es un mecanismo de protección para proteger las
variantes y que cualquier pueda modificarlas.
Una vez ajustada la variante deseada, el usuario ya tendrá disponibles los
nuevos campos.
El procedimiento descrito es válido también para ampliar el listado de

facturas (transacción VF05), pero usando la transacción de
configuración VOF01 (opción del custo Otros campos de visualización para
listas docs.facturación, en la misma ruta que hemos indicado al principio).
Como bonus de esta entrada, si alguna vez teneis que ampliar los campos
que aparecen en el pool de facturación (transacción VF04 o VF06),
que es desde donde realizamos la facturación manual de pedidos y entregas,
podeis utilizar el módulo de función RV_READ_INVOICE_INDEX. Esta se
llama desde las transacciones VF04 y VF06 (facturación en procesos de fondo).
En el final del código de esta función hay una llamada a la
rutina END_MODIFICATION, que se encuentra dentro del include VV05HFZ2
y que nosotros podremos modificar para introducir nuestro propio código Abap,
y el llenado de nuestros campos de cliente.
Previamente habrá que añadir los campos deseados en la estructura VKDFI,
utilizando el include VKDFIZ. Con esta opción podemos superar las
limitaciones del pool de facturación en cuanto a campos disponibles para
ajustar el proceso de selección y validación de pedidos/entregas en la creación
de facturas.
Resumen. Opciones de personalización en nuestro
sistema Sap.
Publicado el 4 septiembre, 2011por Roberto Espinosa
8 Votes
En las últimas entradas del blog hemos utilizado las diferentes “puertas
abiertas” que deja Sap en sus aplicaciones para que los clientes sean
capaces de personalizar sus sistemas en aquellos aspectos en los que la
parametrización no es suficiente. Cada uno de los metodos los hemos analizado
con un ejemplo práctico para ver las posibilidades de cada uno de ellos. Vamos a
hacer un repaso:
 Field exits: a nivel de campo en cada pantalla, podemos introducir código
abap propio para realizar verificaciones adicionales en los datos (ver entrada
relacionada). Es una tecnologia obsoleta que Sap va abandonando, pero que
aun se puede utilizar en muchas dynpros.
 Variantes de transacción: con las variantes de transacción podemos
crear nuestras propias transacciones proponiendo valores por defecto,
modificando los campos que aparecen, su tipo (visibles, invisibles, solo
visualización, obligatorios, etc). Ejemplo aquí.
 Documentación de campo estandar: con esta funcionalidad podemos
añadir documentación adicional a cualquier campo. La ayuda de campo se
accede desde la tecla F1. Ejemplo aquí.
 Ayudas de búsqueda: Sap ofrece los matchcode o ayudas de busqueda
(con la tecla F4) de forma estándar de una forma muy completa en la
mayoria de campos. En el caso de que las ayudas estandar no nos
valgan,porque queramos buscar por campos adicionales o por campos de
cliente, podemos ampliarlas con las nuestras propias. Ejemplo aquí.
Respecto a las ampliaciones o Enhancements, estos son programas que Sap deja
habilitados para cubrir las necesidades adicionales del cliente, sin modificar el
código fuente del programa estandar. Es decir, son usadas para expandir la
funcionalidad estándar dentro del sistema SAP.
Actualmente existen en SAP tres generaciones de ampliaciones:
 Primera generación: subrutinas vacías dentro de un programa estándar

en las cuales se puede agregar código. El nombre de las mismas comienza
con USEREXIT. Esta modalidad implica modificar el estándar
(necesitamos clave de modificación de Sap), aunque Sap asegura que las
rutinas para las exits no serán tocadas en las actualizaciones. Las Userexit se
utilizan mucho en el módulo SD, donde vimos un ejemplo para añadir
campos adicionales en los informes de pedidos y en el pool de facturación
(ver aquí).
 Segunda generación: CUSTOMER-FUNCTION. En algunos lugares
del código estándar hay llamadas de tipo CALL CUSTOMER-FUNCTION
<NRO> (Ej:‘001’). Estas rutinas se definen con la transacción SMOD y se
editan con la transacción CMOD. Son realmente llamadas a módulos de
función que incluyen un include Z que no existe (esta vacío), y que nosotros
creamos y le damos contenido cuando creamos el proyecto de
ampliación. Vimos un ejemplo de exit de este tipo ampliando los campos del
informe de partidas individuales de controlling (ver aquí).
 Tercera generación: BADIS. Usan instancias de ABAP Objects. Se

invocan con CALL METHOD. Se crean con la transacción SE18 y se
implementan con la transacción SE19. Sap nos deja disponibles crear
la correspondiente implementación de la BADIS donde nosotros
personalizaremos el sistema con nuestro código Abap. Vimos un ejemplo de
Badis ampliando los campos de los informes de partidas de contabilidad
(ver aquí). Tambien os recomiendo la entrada del blog Teknodatips donde se
habla de la forma de localizar las badis.
Además, podemos mencionar otras posiblidades de ampliación del sistema que
son:
 Business Transactions Events (BTE): se gestionan desde
la transacción FIBF y son módulos de función que se llaman desde
determinados puntos del código fuente, en determinados eventos. Podemos
crear nuestros propios módulos de función y activar su llamada en dichos
eventos. Vimos igualmente un ejemplo de su uso en la ampliación de
campos del listado de Partidas de FI (ver aquí).
 Enhancements de código: con los puntos de ampliación implicitos
(disponibles en cualquier programa Abap en unos lugares determinados),
podemos introducir nuestro propio código Abap sin que ello sea una
modificación del estandar. Los enhancements son puglins dinámicos que
sustituyen el código fuente, y que nos dan muchisimas posibilidades, aunque
siempre se habrán de usar con la debida cautela. Vimos un ejemplo para
modificar la selección de pedidos en el registro de facturas de compras
(transacción MIRO), ver aquí. En la entrada del blog abap.es podeis
visualizar los pasos a seguir para crear una enhacement del tipo implicito.
Como podeís ver, casi siempre Sap nos va a dejar una puerta para adaptar el
sistema a nuestras necesidades, aunque quizás lo más complejo será identificar
el método de personalización que podemos utilizar y localizarlo de entre las
diferentes opciones disponibles
Truco 21. Parametros de usuario y valores en memoria.
Publicado el 21 enero, 2012por Roberto Espinosa
5 Votes
Después de un largo mes de diciembre, y un mes de enero “movidito”, como

todos los comienzos de año con Sap (ya sabéis, instalación de parches, arreglo
de errores, notas, cambios legales, etc, etc), vamos retomar el blog con un truco
sencillo donde vamos a hablar sobre los valores fijos y parámetros de memoria
que podemos fijar en el sistema a nivel de usuario.
Accedemos tanto a los valores fijos como a los parámetros desde la opción de
menú Sistema –> Valores Prefijados –> Datos Propios. Esta opción de
menú esta disponible desde cualquier lugar, bien desde los menús o dentro de
una transacción. Los datos también se pueden mantener en las transacciónes
de gestión de usuarios(SU01 para un usuario individual o la SU1o para la
modificación de usuarios de forma masiva).
Valores Fijos.
En los valores fijos indicamos la configuración de trabajo del usuario con el

sistema, pudiendo indicar aspectos como:
 Menú inicial: podemos hacer que el usuario tenga por defecto un menú inicial que
no sea el general del sistema (S000). Incluso podríamos crear nuestros propios
menús personalizados y asignárselos a los usuarios que van a trabajar en un
determinado ámbito (aunque esto también lo podemos hacer vía roles de
autorización).
 Idioma de trabajo: el idioma indicado aquí tendrá prioridad por el indicado en el
momento del logon al sistema.
 Representación decimal: este valor fijo es muy interesante. Por defecto, Sap nos
ofrece la coma como separador para los decimales y el punto para los miles. La
mayoría de gente que trabaja con los módulos de finanzas, compras o ventas suele
utilizar el teclado numérico para introducir las cifras en el sistema y está
acostumbrado a trabajar con el punto (.) como separador de los decimales. Aquí
podemos cambiar la representación para que siga este formato (internamente no
afecta, pues Sap guarda la información en la base de datos de la misma forma).
 Representación de la fecha: el formato por defecto es el dd.mm.aaaa, aunque
aquí podremos trabajar con otros formatos, habituales en otros países (
mm/dd/aaaa, aaaa.mm.dd, aaaa-mm-dd, etc).
 Control Spool: aquí indicamos valores relacionados con la impresión, como la
impresora por defecto del usuario y la forma de imprimir (impresión inmediata o
no, conservación de las ordenes en el spool una vez realizada la impresión).
Parámetros.
Los parámetros son valores de usuario que se pueden conservar en

memoria y que luego nos van a aparecer predefinidos cuando entremos en las
transacciones. Por ejemplo, podemos fijar la sociedad de finanzas o controlling
con la que trabajamos (parámetros BUK o CAC), Organización de compras
(EKO), Grupo de compras (EKG), Organización de ventas (VKO), Tipo de
documento de ventas (AAT), Clase de documento de finanzas (BAR), etc, etc.
Cuando entremos en una transacción que tenga estos campos y habilitada la
recuperación de valores de memoria, estos campos se llenarán con estos valores
predefinidos, agilizando el trabajo de usuario.
La forma de localizar si
un campo en una determinada transacción es susceptible de ser importado a
partir de los valores en memoria del usuario es hacer un F1 posicionados en
el campo y buscar el valor “ID parámetro”.
Ademas, los parámetros nos pueden servir para guardar
configuraciones predefinidas cuando las fijamos utilizando los
diferentes programas de Sap. Por detras, el sistema se ha guardado los
valores de dicha configuración utilizando parámetros de memoria. Por ejemplo,
la configuración de Opciones de tratamiento en finanzas (transacción FB00),
guarda su configuración en el perfil del usuario en los parámetros.
En el ejemplo, he fijado diferentes opciones para trabajar con finanzas (calculo
de impuestos, variantes para las pantallas de contabilización, variantes de
visualización en las listas de partidas abiertas, etc). Todo eso se ha quedado
guardado automáticamente en mi perfil de usuario en los parámetros FBA, FBZ,
F02, F03, FOP, etc.
Existen una multitud de parámetros relevantes en el sistema, como el MOL y
UGR en Recursos Humanos, donde se determina el grupo de usuario y
modificador de país, lo que luego afecta al comportamiento del sistema y a los
menús de infotipos o de medidas; el parámetro IVFIDISPLAY que nos
permite, al contabilizar facturas de compras desde la transacción MIRO, que el
sistema nos devuelva el número de documento contable además del número de
registro de facturas; el parámetro SD_VARIANT_MAINTAIN que nos
permite mantener las variantes de visualización en los informes comerciales,
etc, etc. Son solo algunos ejemplos de la multitud de aspectos que se pueden
configurar para mejorar la productividad de usuario en el sistema usando esta
funcionalidad.
Nota: podremos crear nuestros propios parámetros de memoria
manteniendolos con la transacción SM30/SM31 en la tabla TPARA.
Luego los podremos utilizar en nuestros desarrollos a medida y utilidades para
inicializar valores o para establecer diferentes comportamientos de las
aplicaciones según los valores prefijados (utilizando las sentencias abap SET
PARAMETER/GET PARAMETER). Igualmente, podremos recuperar con estas
instrucciones los valores de los parámetros estandar.
Truco 26. Configuración del envio de correo electrónico
desde Sap.
12 Votes
Hoy vamos a hablar de un tema antiguo y que aparece mucho en los foros,
aunque, como casi siempre, con poca documentación en castellano. Me refiero a
la configuración para permitir enviar correo electrónico desde un
sistema Sap al exterior.
Desde la version 6.10 y superiores, el kernel de Sap contiene de forma nativa
funciones para el procesamiento del correo via SMTP (incluidas en el ICM
Internet Connection Manager). Vamos a ver la forma de preparar para que el
sistema envie correo al exterior y algunos ejemplos de programación para generar
estos envios desde nuestros propios desarrollos.
Nota: hemos de tener un servidor de correo interno (propio) o externo que

permita el reenvio SMTP.
Configuración del Sistema.

En la nota 455140 del OSS se detallan paso por paso las tareas de configuración
del sistema.
Ejemplo de envio de correo desde cualquier transacción:
1. Parametros del perfil de la instancia: a través de la transacción RZ10,

incluiremos con el parámetro icm/server_port_X (donde X es un número
secuencial para los diferentes puertos que configuremos: http, https, smtp, etc) el
número de puerto TCP/IP (25 por defecto) y el protocolo (SMTP).
2. Activación de servicios: a través de la transacción SICF, comprobaremos
que tenemos nuestro nodo SMTP configurado y activado. Aquí se relaciona el
servicio con el puerto del ICM que hemos configurado en el paso anterior.
3. Configuración del Sap Connect: a través de este paso conectamos el nivel
de aplicación (por ejemplo Sap Office) con el nivel ICM (nivel técnico). La gestión
de esta configuración se realiza desde la transacción SCOT. Hay que realizar la
configuración en cada mandante. Siempre se crea de forma automática un nodo
SMTP, que tendremos que ajustar para indicarle los parametros del servidor de
correo saliente que utilizaremos para enviar los correos desde la pasarela Sap.
Haciendo donde clic en el nodo SMTP configuraremos la IP y el puerto del

servidor de correo saliente, si hay que realizar alguna conversión de codigos de
pagina (juegos de caracteres) y los tipos de dirección soportados (en este caso
Internet).
A nivel de detalle, configuraremos los dominios a los que se pueden enviar
correos (* sera a todos), y los formatos de envio de los documentos enviados de
Sap (al enviar formulario o listados por correo, aquí indicamos en que formato
se construiran los anexos que los contengan: pdf, txt, htm, etc).
La transacción SCOT también nos permite monitorizar los correos que estan en
cola e iniciar los procesos de envio (y planificar el Job de envio
automatico de correos,que se ejecutara con la regularidad deseada para que
los correos vayan saliendo de la cola interna a la cola del servidor de correo).
4. Monitorización del envio de correos externos: con la transacción
SOSTpodemos gestionar los correos que tenemos en cola para envio externo:
ver correos pendientes y enviados, visualizar los mensajes, analizar errores, etc.
5. Asignación de cuentas de correo a los usuarios del sistema: estas
cuentas serán las utilidas con remitentes de los correos que salgan al exterior.
Desde la transacción SU01, habra que indicar en todos los usuarios que vayan a
enviar correo su cuenta, que sea utiliza como remitente de los correos que se
envien.
Envio de correo desde las aplicaciones.
Una vez realizada toda la configuración, ya podremos enviar correos de la forma
habitual:
 Sap Office: desde la transacción SBWP podremos crear nuestros mensajes, que
podrán incluir usuarios Sap (que recibiran los mensajes en el propio Sap a través de
la misma transacción) o bien a destinatarios externos (indicado su cuenta de correo
electrónico).
 Aplicaciones: en todos los informes donde tengamos disponible la opción de
menú Lista –> Enviar, podremos crear un mensaje en el cual se anexara como
documento el listado o tabla ALV que estemos procesando.
Envio de correo desde nuestros desarrollos.
Tenemos multitud de formas de poder enviar correos en nuestros programas.
En la Wiki del SDN de Sap hay una completa lista.
Templates de ejemplo proporcionados por Sap:
SAP provides the following programs, which are in fact
templates because they can't be executed as is (email is
hardcoded for example):
 BCS_EXAMPLE_1: send a simple text provided as an internal

table of text lines to joe.doe@crazy-company.com
 BCS_EXAMPLE_2: send a simple text provided as an internal
table of text lines and text attachment in form of text
lines itab to fax DE 09999-123456
 BCS_EXAMPLE_3: send a simple text provided in an internal
table of text lines and an additional note to SY-UNAME
 BCS_EXAMPLE_4: send a simple text provided in an internal

table of text lines recipients are selected in dialogue
(default joe.doe@crazy-company.com)
 BCS_EXAMPLE_5: a simple text provided in an internal table
of text lines and an attached MS word document provided in
internal table SOLIX_TAB (document retrieval has to be
coded) to joe.doe@crazy-company.com
 BCS_EXAMPLE_6: enter customer, carrier (flight demo data)
and email, and generate corresponding FP_TEST_03 adobe
form, and send it as attachment to the email
 SENDLIST_BCS: provided as attachment in SAP Note 190669 -

Sending lists using SAPconnect, it uses
SO_DOCUMENT_SEND_API1
 SENDLIST_BCS: provided as attachment in SAP Note 190669 -
Sending lists using SAPconnect, it uses CL_BCS
 ZSSO_DOCUMENT_SEND_API1_46 and ZSSO_DOCUMENT_SEND_API1_610:
provided as attachment in SAP Note 609696 - SAPoffice:
Error in documentation (SO_DOCUMENT_SEND_API1). There are 2
versions, one for 4.6C, and one for 6.10 and above, the
difference between the 2 is only the addition of
COMMIT_WORK parameter for 6.10 version. Both call
SO_DOCUMENT_SEND_API1.
 RSWNSENDMAIL1: demo of SO_NEW_DOCUMENT_ATT_SEND_API1.
Ejemplos de programas del SDN, utilizando los siguientes elementos:

 CL_BCS
 SO_DOCUMENT_SEND_API1
 SO_NEW_DOCUMENT_ATT_SEND_API1
 SO_NEW_DOCUMENT_SEND_API1
Basicamente, tenemos programas que utilizan los módulos de función (SO), que están
obsoletos (aunque se pueden utilizar) y aquellos que utilizan la programación orientada
a objetos (con la clase CL_BCS). Os recomiendo acceder a los links si quereis profundizar
en los temas y analizar los ejemplos de desarrollo.
Referencias:
 Postalmethods.com: configuración del envio de correo saliente desde Sap.

 Thomas Jung: envio de correo desde Abap en version 6.10 y superiores.
 Thomas Jung: envio de correo desde Abap en versiones 4.6D e inferiores.
 Thomas Jung: recepcion de correo en Sap y su procesamiento en Abap.
 Dataxstream.com: configuración de Sap connect.
 Snippets: envio de correo desde Abap usando programacion orientada a objetos.
 Wiki SDN: resumen de elementos Abap para envio de correo electronico (modulos
de función).
Truco 27. Guia para programacion de ALV´s en ABAP.
1 Vote
La compañia suiza Consolut, ademas de ofrecer acceso gratuito a un servidor

Sap IDES via Web (más información en este link), proporciona en su portal un
completo repositorio de documentación, que incluye, entre otros:
 Lista de manuales Sap en formato PDF: ver link. Incluye mas de 500
documentos, desde guias de programación Abap, ALE, descripción de
funcionalidades de los diferentes modulos, Guias de Administración, etc
 Documentación Online: ver link. Documentación detallada de los
siguientes componentes de Sap:
 ABAP
 Report
 Function Modules
 Tables
 Authorization Objects
 Profile Parameters
 Classes
 Basis Info
 SMOD Docu
 Transactions
 IMG Activities
 Messages
 All Unicode Characters
 Guias para sistema IDES: ver link. Como sabeis, un sistema IDES es un
sistema Sap con datos precargados, orientado principalmente a formación
de usuarios y consultores.
Dentro de las guias PDF hay un monton de documentación interesante. Como
ejemplo, os dejo una guia fundamental para el caso de que programeis en Abap
y querais controlar todos los elementos del lenguaje disponibles para trabajar
con controles ALV.
En la guia podemos ver desde aspectos tan sencillos como la coloración de filas
y columnas, formato, personalizar las opciones estandar, preparación del
catalogo de campos, etc, hasta un completo detalle de los metodos de
programación disponibles. Espero os sea de utilidad.
Preparando la certificación MM de Sap (II).
Publicado el 3 noviembre, 2012por Roberto Espinosa
4 Votes
Al hilo de la entrada publicada en nuestro blog en mayo de 2011 (link aquí),

donde hablábamos de los requisitos para obtener la Certificación en el Módulo
MM (Gestion de Materiales) de Sap y compartíamos diverso material de
formación, acceso a servidores y documentación, me gustaría compartir nuevo
material con vosotros. Lo hemos conocido gracias a Marcos García y a Ainhoa que
lo ha publicado en Scribd (gracias también a Rodrigo Olivares opr subir el
TSCM50, parte II). Los materiales corresponden al curso TSCM50 (parte I y
II) y TSCM52 – Compras II(parte I y II, “mySAP ERP Procurement and
Logistics Execution”). Todos los materiales están en Español, espero que os
sean de utilidad. Os dejo igualmente el acceso a los cursos TSCM60 y TSCM62
en Español, correspondientes a la logistica en el modulo de Ventas (SD).
NOTA: Actualizado el 13.01.2013, incluyendo el TSCM50 (Parte I).
NOTA: Actualizado el 24.05.2013, incluyendo el TSCM50 (Parte II).
View this document on Scribd
Para el caso de que os falle los enlaces en Scribd, os dejo a continuación los
enlaces a los documentos.
 TSCM50: TSCM50-1-ES-Col62-FV-Inst-A4 y TSCM50-2-ES-Col62-FV-Inst-A4.

 TSCM52: TSCM52-1-ES-Col62-FV-Inst-A4 y TSCM52-2-ES-Col62-FV-Inst-A4.
 Ejemplos de preguntas de Examen: gracias a Javiera Parada. Preguntas examen
1, Preguntas examen 2, Preguntas examen 3 y Preguntas Examen 4.
 TSCM60: Tscm60-Es-Col62-Fv-Part-a4.
 TSCM62: Tscm62-Es-Col62-Fv-Part-a4.
Si tenéis cualquier material relacionado, no dudéis en compartirlo con todos
nosotros.
Nota: los manuales del TSCM50 y TSCM52 son los del instructor (si quereis los
manuales del participante (alumno), los podeis conseguir en Scribd en este
link: http://es.scribd.com/rodrigo_olivares_16/documents ).
FORMACION ONLINE EN EL MODULO MM.
Si estáis interesados en recibir formación en el módulo SAP MM, como ayuda

para formaros en el uso y parametrización de este módulo, o como preparación
para la certificación oficial, actualmente ofrezco clases personalizadas con
acceso a un sistema de pruebas incluido. Consulta metodología del curso,
temario, tarifas y fechas disponibles en los siguientes enlaces:
 Metodología del curso e información: link aquí.
 Temario: link aquí. Podeís descargarlo en formato PDF aquí.
 Opinión de los alumnos del curso aquí.
Truco 31. Exportacion a Excel en reports tipo ALV.
Reseteo de valores por defecto.
Publicado el 1 diciembre, 2012por Roberto Espinosa
4 Votes
Hoy vamos a ver un truco sencillo, pero muy útil cuando hemos seleccionado un
formato de exportación a Excel por defecto y deseamos resetear esta opción.
Como sabeís, los informes en Sap del tipo ALV tienen la opción de
exportación a Excel directamente (en algunos informes lo llama Hoja de
Calculo, en otros Hoja de Calculo del coste). Es una opción muy útil en tanto que
los usuarios van a poder disponer de la información visualizada en pantalla en su
hoja de cálculo, con cada columna del alv en su correspondiente columna de la
excel, manteniendo los formatos de los valores. La exportación tiene algunas
limitaciones, como que no se respetan los filtros establecidos en el alv y tampoco
se representan los posibles subtotales que hubieramos definido. Pero esto no
quita que sea una funcionalidad muy útil y ampliamente utilizada por los usuarios
Sap.
Al realizar la exportación, el sistema nos permite seleccionar el tipo de formato a

utilizar, pudiendo en este momento seleccionar una opción por defecto que
quedara preestablecida en nuestro usuario para siempre (y no se nos volvera a
preguntar nunca más por el formato de exportación a utilizar).
Los posibles formatos de los que disponemos son los siguientes:
 Excel en formato MHTML.

 Star Office 8 Cal.
 Seleccion de formatos disponibles (todos), donde a su vez podemos
seleccionar entre varios formatos MHTML, XML o XXL (este es el que yo
recomiendo usar).
En el caso de que hayamos seleccionado un formato por defecto y necesitemos
eliminar esta opción y poder volver a elegir el formato deseado, SAP nos ofrece
un report para gestionar esta configuración. El report se llama
SALV_BS_ADMIN_MAINTAIN y se ejecuta desde la transcción SE38 (es
necesario introducir en el usuario que lo vaya a utilizar el parametro de
memoria SALV_BS_ADMIN_XXL con el valor X en su perfil de usuario, con
la transacción SU01).
El report es muy sencillo de utilizar y nos permite desde eliminar los valores por
defecto a cambiar de forma másiva el valor por defecto de exportación para los
usuarios deseados.
Por ejemplo, para borrar los valores de un determinado usuario, seleccionamos
la opción Delete, indicando el mandante y usuario que queremos resetear. En
la pantalla de resultados, veremos el/los usuarios seleccionados y el valor por
defecto que tienen actualmente. Con el botón eliminar (tal y como vemos en la
imagen inferior), reseteamos esta opción y el usuario ya podrá volver a
seleccionar el formato que necesite.
Gracias al blog home4sap.com por la información proporcionada sobre este

tema.
En las próximas entradas del blog vamos a ver que son los Idocs y todas las
opciones que nos proporcionan en Sap para comunicarnos con otros sistemas o
con sistemas Sap, tanto en interfases de entrada como de salida, incluyendo todas
las herramientas de monitorización estandar que proporciona el sistema.
Actualización 28.01.16
Otra opción mas sencilla es pulsar con el botón del derecho del ratón encima de
cualquier registro a exportar y seleccionar la opción ‘Hoja de calculo….’. La
ventana de selección de formato aparece y nos permite actualizarlo.
Truco 32. Listado de registros info de compras en
formato ALV.
Rate This
Este es un tema sobre el que he recibido multitud de consultas (tanto en las

empresas donde he estado como en el blog). Como sabeis, los registros info de
compras son los datos maestros donde almacenamos las condiciones
de precio y condiciones de servicio (plazos de entrega, impuestos,
pedido minimo, etc) de un material con respecto a un proveedor.
Los registros info se pueden mantener manualmente o bien alimentarse
automaticamente, por ejemplo, desde los pedidos de compra (de forma que
mantenemos la ultima condición de compra a un proveedor, que será la que se
aplique en la proxima compra al mismo proveedor del mismo material).
Los registros info se pueden listar desde las transacciones estandar disponibles
en el sistema:
 ME1L: Registros info por Proveedor.

 ME1M: Registros info por Material.
 ME1W: Registros info por Grupo Articulos.
 ME1A: Registros info Archivados.
La opción por defecto en estos listados es un feo listado en modo lista desde el
que no se puede realizar la exportación a Excel, por ejemplo y otro tipo de
acciones propias de los informes tipos ALV.
Existe una alternativa sencilla para convertir este informe al tipico
report ALV, usando el parametro de usuario ME_USE_GRID (Use
ALV Grid Control in Purchasing Reporting) con el valor X. Los
parametros se mantienen desde la transacción SU01, o bien en el menu principal
de Sap, opción Sistema –> Valores prefijados –> Datos Propios –> Parametros.
Una vez indicada esta opción en nuestro perfil de usuario, el aspecto de los
informes varia sustancialmente, ofreciendonos muchas más posibilidades de
trabajo:
El cambio es reversible eliminando el parametro introducido en el perfil de
usuario. Afecta a otras transacciones de compras, como la ME2O.
Truco 37. Transacciones y tablas Sap siempre en
nuestro bolsillo.
3 Votes
Quien no ha hecho o ha consultado alguna vez la típica lista de transacciones de

Sap o de las tablas mas frecuentes que se utilizan en los diferentes módulos.
Lo ideal sería, en estos tiempos en los que todo es móvil o tablet, tener un
aplicación donde llevar esa información siempre con nosotros. Gracias a Gregor
Brett, que ha desarrollado varias aplicaciones en Android, tenemos disponibles
algunas apps que hacen este trabajo para nosotros.
Respecto a las transacciones, tenemos la aplicación SAP Searcher, que nos

organiza por módulos cerca de 16 mil transacciones, incluyendo la
posibilidad de realizar búsquedas por nombre, descripción por
módulo. Igualmente, nos permite construir nuestras listas de favoritos e
incluso añadir nuestras propias transacciones.
Otra aplicación interesante es Sap Tables, que nos permite acceder a las tablas
mas usadas, organizadas igualmente por módulos. Esta aplicación es más
sencilla que la anterior y con menos funcionalidades.
El mismo desarrollador tiene otra aplicación llamada Sap ABAP Cookbook para
gestionar desde el móvil nuestro código abap, permitiendo exportar el codigo en
ficheros de texto y enviarlo por email.
Para terminar, otra aplicación relacionada con Sap, en este caso de John Moy,
llamada myHelp for SAP Professionals. Esta aplicacion nos permite
realizar búsquedas desde nuestro móvil o tablet en la ayuda online de
Sap (help.sap.com), de la que hablamos en nuestra anterior entrada del blog.
Con el desarrollo de los smartphones y las tablets, este tipo de aplicaciones seguro
que van a crecer mucho en los próximos meses, y tendremos muchas más
utilidades similares a estas.
Truco 38. Personalizando table controls.
2 Votes
Para empezar el 2013 vamos a ver un truco muy sencillo, pero muy util para la
mayoria de usuarios de un sistema Sap. Se trata de un truco de ergonomia
que nos permite personalizar la disposición de los campos en los
“Table Control”. Estos son un elemento de la programación Abap que
se utilizan para mostrar listas de datos en forma de tabla. Por
ejemplo, el resumen de posiciones en un pedido de compras o de
ventas es el tipico Table Control. Podemos verificar que estamos en un
elemento de este tipo por el icono que aparece en la parte superior derecha del
control, que nos permite acceder a la configuración personalizada.
La personalización se puede realizar a dos niveles:
 Nivel de Usuario: se ha de realizar usuario a usuario y con ella se puede configurar

el orden de los campos que aparecen en el control, asi como su ancho. Se pueden
definir varias visualizaciones por usuario para el mismo table control, aunque solo
una de ellas será la opción por defecto. En el caso de haber varias, se puede cambiar
en cualquier momento de una disposición a otra.
 Nivel de Responsable del Sistema: son disposiciones validas para todos los
usuarios y todos los mandantes, aunque si un usuario tiene su disposición propia,
esta estará por encima de la de sistema. Aqui, ademas del orden de los campos y su
ancho, se puede configurar también si un campo es visible o no, así como la cantidad
de columnas fijas y las lineas de separación (horizontales y verticales). Esta opción
no debería de estar disponible para todos los usuarios (se requiere para ella el objeto
de autorización S_ADMI_FCD), por lo delicado de esta configuración general.
Vamos a ver un ejemplo de personalización de ambos tipos.
Personalizacion a nivel de usuario del orden de campos y ancho de

estos en el resumen de posiciones de un pedido de compras
(transaccion ME21N/ME22N).
En este supuesto un usuario del departamento de compras nos plantea que, de

cara a la mejora de productividad en el uso de la transacción de
Creación/Modificación de pedidos de compras, la posibilidad de modificar el
orden de los campos y su ancho en el resumen de posiciones del pedido. El
usuario quiere los siguientes cambios:
 Los flags “Posicion de devolución” y “Posicion gratuita” estén al principio de la linea,

despues del campo tipo de posicion.
 Cambio en los tamaños de los campos Material, Texto Breve Material.
 Campo Lote se localize despues de la cantidad de pedido.
 Grupo de material se localize despues del almacén.
Lo primero que hay que realizar es modificar la disposición de los campos; para
el caso del ancho de estos, ajustarlo moviendo en la cabecera la esquina superior
derecha de cada campo ampliandolo o reduciendolo. Para el caso de la posición,
si queremos modificar la de un campo, seleccionaremos este, y lo arrastraremos
en el table control hasta el lugar donde queremos que se localice.
Una vez preparada la disposicion, seleccionaremos el icono en la esquina superior

derecha del table control y nos aparecera un dialogo para guardar los valores de
nuestra configuración.
Para crear la nueva disposición (o modificar una ya existente),
indicaremos un nombre para ella en el campo Variante (sección de la
pantalla Gestionar Variantes) y pulsaremos el boton Crear para
guardarla. Si deseamos que la disposición se quede como por defecto
marcaremos el flag “Utilizar como parametrización std”. De esta forma, cada vez
que el usuario entre a Sap en esta transaccion (ME21N/ME22N), los campos le
sera visualizados de la forma descrita.
Si el usuario quiere en cualquier momento cambiar a la

parametrización estandar, volvera a entrar a la configuración del
Table Control y en la sección “Seleccionar variantes” indicará en
Opción actual “Parametrización básica”, volviendo a la visualización
de sistema definida de forma global. También podrá modificar o borrar la
disposición que se hubiera creado o seleccionar otra de las disposiciones que se
hubieran configurado para el.
Personalizacion a nivel de sistema del resumen de posiciones en la
creacion/modificación de pedidos de ventas (transacciones
VA01/VA02).
En este caso, queremos configurar para todos los usuarios del sistema, los
siguientes aspectos:
 Modificar el ancho de las columnas Material y Denominación.

 El campo Importe se encuentre posicion despues de la unidad de medida de la venta.
 Hacer invisible el campo Numero de material del cliente.
Para ello, hacemos como en el caso anterior. Modificamos por un lado el ancho
de los campos y posicionamos los que queremos cambiar de ubicación al sitio
deseado. Una vez realizada esta tarea, seleccionamos en la parte superior derecha
del table control el icono para su configuración.
En este caso, seleccionamos la opción Responsable del Sistema. Nos
aparecerá un nuevo diálogo donde podremos realizar la configuración de la
parametrización de sistema.
En esta pantalla podremos seleccionar los campos que queremos ocultar
(Marcando la casilla Invisible). También podremos indicar el número de
columnas fijas y si queremos lineas de separación horizontal/vertical en la
sección Otras parametrizaciones.
Una vez terminada la configuración, seleccionaremos el botón Activar

y la configuración quedará establecida para todos los usuarios del
sistema en todos los mandantes (a no ser que los usuarios tengan
configuradas sus propias disposiciones).
En nuestro ejemplo, la pantalla de resumen de posiciones en la creación de
pedidos de venta tendrá el siguiente aspecto:
Como podeís ver, un truco muy sencillo pero que nos da muchisimas
posibilidades de mejorar la experiencia de usuario con las transacciones en las
que se utilizan estos controles (muy ampliamente utilizados en la programación
de las transacciones de Sap).
Truco 42. Transporte de la clasificacion de Estrategias
de Liberacion de Compras utilizando ALE.
3 Votes
Cuando creamos nuestras estrategias de liberación para pedidos de compras,

solicitudes de pedido, etc, nos encontramos con un problema (sobre el que he
recibido multitud de consultas en el blog): la clasificación que indicamos en
cada estrategia de liberación (valores de caracteristicas) no se
transporta de forma automatica. Es decir, de toda la parametrización que
realizamos para los procedimientos de liberación, se transporta todo excepto
esto.
Esto nos obliga a que, una vez realizados los transportes, tenemos que volver a
introducir en cada uno de los sistemas los diferentes valores de clasificaciones
que tuvieramos. Esto puede llegar a ser tedioso en un sistema con estrategias
complejas y con muchos valores de características diferentes. Existe una
alternativa que yo no conocia y que nos ha dado a conocer nuestro amigo Milton
Fernando Suarez Pulido.
Esta alternativa consiste en utilizar la funcionalidad ALE de

Sap (“Application Link Enabling”) que nos permite intercambiar
información entre diferentes sistemas Sap de una forma automática utilizando
Idoc´s. ALE nos permite intercambiar datos maestros como información de
Clientes, Proveedores, Materiales, Registros Info, Centros, Clases de Coste,
Cuentas de Mayor, etc . Tambien nos permite enviar documentos, como Pedidos
Abiertos, Libros de Pedidos, Listas de materiales, etc., etc.
Igualmente, también nos permite transportar el sistema de clasificación. En
nuestro caso, podremos utilizar la transacción BD93 para enviar toda la
configuración de clasificación de las estrategias de liberación de un
sistema a otro.
Para nuestro caso, sería tan sencillo como indicar la clase que queremos
transportar y la categoria de la clase (siempre indicaremos el valor 032 –
Estrategia liber), asi como el sistema lógico destino. Ejecutaremos y el sistema
generará los correspondientes Idocs que crearan la información en el sistema
destino.
Bueno, en realidad todo no es tan sencillo. La utilización de la tecnología
ALE requiere una configuración previa un tanto compleja, que
nuestro amigo Milton ha plasmado de maravilla en un documento que
nos ha pasado, que comparto con vosotros. Muchas gracias de nuevo por
su aportación.
También podeís acceder al documento en este link. Resumiendo, los pasos
necesarios y que estan descritos en el manual serían los siguientes:
 Creacion de los sistemas lógicos.
 Asignación de los sistemas lógicos a los mandantes.
 Crear las conexiones RFC para cada mandante.
 Configuración de los puertos ALE.
 Creacion de los acuerdos de Interlocutores (Partners profiles) en cada
mandante.
 Creación de los modelos de distribución.
 Generacion de los acuerdos de Interlocutores.
 Distribucion de la vista del modelo a los diferentes sistemas.
En el manual también se incluye la forma de analizar los Idocs que se generan
en el momento de la distribución (tanto en el sistema origen como destino),
para poder analizar posibles errores en el proceso de distribución.
Hemos solucionado un viejo problema que teniamos pendiente y de paso nos

hemos familiarizado con los Idoc´s que serán objeto de estudio en las próximas
entradas del blog de una forma amplia.
Truco 43. Gestion de versiones en Documentos
de Compra.
Publicado el 9 febrero, 2013por Roberto Espinosa
2 Votes
Siguiendo en el modulo MM, en nuestro truco de hoy vamos a hablar de una

funcionalidad no muy conocida que se encuentra disponible tanto en las
solicitudes de pedidos como en los documentos de compras (ofertas, pedidos,
pedidos abiertos, plan de entregas, etc.). Se trata de la gestión de
versiones.
Básicamente, la gestión de versiones no permite llevar un historial de las

modificaciones realizadas en el documento de compras (independiente del
log de modificaciones que tenemos siempre disponible para ver los cambios
que se van realizando en los documentos). Una vez activada la funcionalidad,
aparece una nueva pestaña a nivel de cabecera, que se llama Versiones.
Esta pestaña se va llenando con los datos de las versiones del documento
teniendo en cuenta lo siguiente.
1) Cuando creamos, por ejemplo, el pedido, tenemos una versión 0 (inicial),
que no se concluye hasta que no se realiza la impresión del mensaje asociado al
documento.
2) A partir de ese momento, cualquier modificación posterior del pedido nos
obliga a gestionar una nueva versión del documento. Esta nueva versión se
crea de forma automática y tenemos disponible en ella una serie de campos de
usuario (motivo, texto, solicitante, nº externo, fecha contabilización) que
podemos hacer opcionales, obligatorios, ocultos o solo visibles. Estos campos
nos pueden informar del motivo de la modificación y aportarnos información
adicional del motivo de los cambios.
3) Se pueden añadir nuevas versiones de forma manual, completando los
campos que nos informan del origen de las modificaciones. Podemos de esta
forma ir concluyendo versiones y creando manualmente nuevas versiones.
4) Una vez realizada una modificación en el pedido y creada una nueva
versión, cuando la versión se concluye, automáticamente se genera un
nuevo mensaje para el documento y se puede volver a realizar la impresión
de este (o el envió mediante email, edi, etc en el caso de que fuera el caso). La
próxima modificación del pedido generará una nueva versión del documento
automáticamente.
5) En la información de la versión tenemos el valor neto del pedido después de
las modificaciones, y la variación con respecto al importe de la anterior
versión.
6) Además de la información resumida de las versiones, podemos con la

opción visualizar modificaciones ver todos los cambios realizados en un
pedido entre una versión y otra, de forma detallada campo por
campo (separándonos la información de cabecera, posiciones,
etc).
Además, cada cambio queda asociado a una versión del documento y se

hace sencillo analizar los cambios realizados entre un momento y otro de la vida
del documento.
Como podéis ver, una forma útil de ir documentando las modificaciones en los
pedidos, además de un registro de los usuarios que van realizando los cambios,
todo ello integrado con la gestión de mensajes de los documentos.
Vamos a ver a continuación la parametrización relacionada con esta
funcionalidad.
Activacion de la gestión de versiones.
En la ruta de customizing Gestión de materiales –> Compras –> Gestion

de Versiones –>Configurar la gestión de versiones para documento de
compras (o SM31, vista V_T16CA). Aquí indicamos por tipo de documento,
clase de documento y Organización de compras si queremos activar la gestión
de
versiones.
En el detalle de la configuración indicamos los campos que vamos a gestionar

en el versionado, indicando si están ocultas, solo visualización, entrada
opcional u obligatoria. En nuestro ejemplo, hemos puesto el campo Motivo
como obligatorio, el resto opcionales (excepto la fecha de contabilización, que
se ha
ocultado).
Parametrización de motivos de modificación.
En la ruta de customizing Gestión de materiales –> Compras –> Gestion de

Versiones –>Especificar motivos de modificación ( o SM31, vista
V_T16CC). Aquí indicamos los códigos de los motivos de modificación que
vamos a poder utilizar en las
versiones.
NOTA: en las solicitudes de pedido se configura la gestión de versiones de

forma similar, aunque tiene alguna peculiaridad, como la posibilidad de indicar
la lista de campos para los cuales una modificación generará una nueva versión
de documento, es decir, los campos que son relevantes para la gestión de
versiones.
Podeís acceder a la versión en PDF de este documento aquí.
Truco 44. Gestion Documental en Sap (I). GOS.
7 Votes
En las próximas 3 entradas vamos a hablar de la gestión documental en Sap y de

las diferentes alternativas que tenemos para añadir nuestros documentos
(imagenes, words, pdf, planos, etc) en los diferentes componentes de la
aplicación. Por ejemplo, si queremos añadir documentación relativa a un material
(imagenes, catalogos en pdf o word, planos en autocad, etc) o un pdf escaneado
de una factura de compras al registrarla a través de la verificación de facturas,
tendremos varias alternativas disponibles. Dependera del tipo de objeto de
negocio tratado las opciones disponibles (no siempre podremos usar las 3
alternativas existentes). En resumen, disponemos de:
 Gos: son los Generic Object Services y nos ofrece funciones como añadir
documentos en los objetos (siempre que este disponible el correspondiente
icono en la aplicacion donde estemos, tal y como vemos en la imagen siguiente).
Ademas nos permite otras opciones como añadir links a los objetos, notas,
añadir a lista de favoritos o seguimiento sobre las modificaciones (a traves
del Sapoffice, que es la mensajeria interna en Sap). El GOS no requiere una
parametrización específica, aunque se pueden personalizar determinadas cosas
(como veremos más adelante). Tiene dos grandes inconvenientes: no hay un
herramienta de búsqueda para los anexos y por defecto los archivos se almacen en la
misma base de datos de Sap (lo que nos puede ocasionar graves problemas de
ocupación o rendimiento si se usa de forma masiva). Este ultimo incoveniente se
puede solucionar (ver nota oss 530792), pero con efectos laterales sobre el Sap Office.
 Archivelink: a esta opción se accede tambien desde el GOS (lo que Sap llama
Archivar Business Document) o bien desde una transacción especifica (la OAAD). En
este caso, si necesitamos una parametrización adicional asociada a cada
Business Object (objeto de negocio, por ejemplo, pedido de compra, factura,
etc). Los documentos se pueden almacenar en la Base de datos de Sap o
en un Content Server (Sap nos ofrece uno gratuito con la licencia,
aunque hay alternativas noSap) y si tenemos herramientas de busqueda,
como las transacciones OAAD o OAOR. Ademas cada documento enlazado se
clasifica por tipo y esta relacionado con cada objeto de negocio en si (por ejemplo, un
pedido de compras).
 DMS: es la gestión documental propiamente dicha. Su disponibilidad es mucho más

limitada que el GOS o el ArchiveLink (por ejemplo, maestro de materiales, maestro
de proveedores o clientes; avisos, ordenes, ubicaciones (modulo PM); posicion de
solicitud de pedido o pedido de compras, posicion de documento de ventas,
proyectos, etc). Se crea un registro de documento con multitud de información
que se vincula a los objetos de la aplicación. Tiene multitud de funcionalidades
disponibles como la gestión de aprobación de documentos, gestión de
versiones, utilización del sistema de clases para clasificar los
documentos, busqueda e indexacion de documentos(Trex), etc. Ademas,
dispone de una herramienta Windows (el Easy DMS) que nos permite estructurar en
carpetas los documentos que hubieramos anexado.
A continuación vamos a ver en detalle cada una de las tres alternativas de las
que hemos hablado, empezando por el GOS.
Utilización del GOS.
La utilización es muy sencilla. Una vez estemos en el objeto Sap donde queremos
añadir el añexo, seleccionamos en el control del GOS la opción Crear –>
Crear Anexo. Nos aparecerá un dialogo donde podremos seleccionar el
documento que queremos anexar.
Podremos añadir todos los documentos que queramos. Para consultar los
ficheros anexados, importante, tendremos que estar siempre en el objeto
relacionado y mediante la opción del Gos “Lista de Anexos” podremos ver
los diferentes ficheros enlazados con la opción de acceder a su contenido.
En el caso de que hubieramos creados notas o enlaces a documentos externos

(URL) asociados al objeto, también los veriamos en la opción de lista de anexos.
Parametrización del GOS.
Tenemos tres vistas donde podemos configurar los aspectos mas importantes del
GOS.
 Vista SGOSATTR (transaccion SM31): aquí se configuran las opciones

disponibles en el gos (incluso podriamos añadir nuevas opciones con la
correspondiente programación). En esta tabla se configuran las opciones
disponibles, su jerarquia, el icono correspondiente a cada opción y la clase que se
utiliza para su gestión.
 Vista SGOSCUST (transaccion SM31): nos permite habilitar/deshabilitar

servicios. En el ejemplo de la imagen estamos deshabilitando la opción de crear
anexos.
 Vista SGOSSUB (transaccion SM31): nos permite configurar la funcionalidad

de las subscripciones a la modificación de objetos. Para el objeto deseado (por
ejemplo, BUS2012 para el pedido de compra), según el evento producido en el objeto
(modificación, liberación, etc), se puede indicar si la subscripcion está disponible y
que texto se enviara a los usuarios subscritos al objeto. Se puede crear textos con
variables que se referiran al objeto en tratamiento (ver ejemplo texto
SGBT_DEF_SUB, transacción SE61).
Además, para que el GOS aparezca en los pedidos de ventas, necesitamos el

parámetro de usuario SD_SWU_ACTIVE con el valor X.
Finalmente, si queremos realizar alguna personalización en el comportamiento

estandar del GOS, Sap nos ofrece dos Badis para este cometido.
Nota sobre el lugar de almacenamiento de los objetos: en la nota

OSS 530792 se habla del lugar donde se almacen los objetos vinculados con el
GOS. Resumiendo los aspectos más importantes que menciona la nota:
 Tecnicamente hablando, los anexos, las notas y los links son tratados en Sap como si
fueran documentos del Sapoffice (con sus correspondientes entradas en las tablas
SOOD y SOFM).
 Antes de la version 4.6B, el contenido de los anexos se almacenaba en la base de datos
en la tabla SOC3.
 A partir de la version 4.6B, en la SOC3 se guarda información de control del anexo,
pudiendose decidir si el contenido se almacena en BD o en un gestor de contenido.
Si se almacen en BD los datos estarán en la tabla SOFFCONT1.
 Si estamos en version >=4.6B y no queremos almacenar en base de datos, tendremos
que configurar un repositorio con la transacción OAC0 del tipo Archivelink, asignarlo
a una categoria con la OACT y configurar en la tabla SDOKPHCL para la clase de
documento SOFFPHIO, la categoria de almacenamiento (indicando el nombre de la
categoria creada). Por defecto, en ese campo aparece el valor SOFFDB (que indica
que se archiva en la base de datos). Tambien podemos hacer la asignación con la
transacción SKPR08.
 Efecto colateral del cambio: si cambiamos el almacenamiento a un repositorio
externo, esta afectando a los anexos del GOS y también a todos los anexos del
SapOffice. Esto es importante tenerlo en cuenta antes del cambio por lo que pueda
afectar al sistema.
Otros enlaces de interes.
Si quereis ampliar información sobre este tema, os dejo algunos links

interesantes:
 Revision del tipo de usuario Sap para que funcione el GOS: gracias a Teknodatips.
 Preguntas frecuentes sobre el GOS en la wiki del SDN de Sap. En esta entrada se
tratan los problemas más frecuentes con los que nos podemos encontrar cuando
trabajamos con el GOS:
 1. The „Generic object services” (GOS) is not available for a user
 2. The GOS is not available in an application at all
 3. Problem while displaying “Generic object services” or some service is not
functioning correctly
 4. Authorizations in GOS
 5. Service “Store Business Document” is inactive
 6. Some attributes of attachments are not displayed in attachment list (title,
creator name, time)
 7. Performance problem while opening “Generic object services”
 8. Where are the documents stored while using “Generic object services”
 Ejemplo de como añadir nuevas opciones en el GOS: gracias a ZEVOLVING (Parte
1 y parte 2).
 Ayuda Online de SAP sobre GOS: ver aquí.
 Ayuda Online de Sap sobre el Eays DMS: https://help.sap.com/easydoc71
Truco 45. Gestion Documental en Sap (II). ArchiveLink.
11 Votes
Como ya comentamos en la anterior entrada del blog, otra alternativa para

anexar documentos en el sistema era utilizar el Archive Link,
funcionalidad que esta disponible a través del GOS en la opción “Archivar
Business Document”. Lo podriamos considerar una mejora de la función
“Crear Anexo”, ya que aquí se realiza de una forma clasificada, disponiendo
además de una herramienta de búsqueda sencilla para los objetos anexados (lo
que no ocurre con la otra forma de anexar).
La funcionalidad requiere una parametrización especifica por objeto de
negocio (por defecto no esta activada) y podemos realizar el archivo de los
documentos en la base de datos de Sap o en un Servidor de Contenido.
Utilización del Archive Link.
El anexo de los documentos lo realizamos desde el control del GOS, a través de

la opción Crear –> Archivar Business Document (la opción solo estará
disponible si previamente se ha configurado para el objeto de negocio, a
diferencia de la opción “Crear Anexo” que siempre esta disponible).
A continuación, el sistema nos preguntará la Clase de Documento que queremos

anexar. Las clases de documento disponibles las parametrizaremos
nosotros (asociadas a un tipo de documento), como un documento lógico
que vamos a utilizar para clasificar los diferentes documentos que podemos
anexar a los objetos. Por ejemplo, en un pedido de compra, podríamos tener las
clases de documento: Oferta del proveedor, Catalogo de materiales, Fotos de
materiales, etc. Cada una de estas clases de documento llevaran asociado un tipo
de documento: por ejemplo, la oferta del proveedor será un tipo de documento
pdf, las fotos de materiales un jpg, etc.
Si estuvieramos trabajando con el objeto de negocio Empleado en el módulo de
administración de personal, las clases de documento podrían ser: foto del
empleado, contrato de trabajo, material entregado, etc, cada uno de ellos de un
tipo de documento concreto (jpg, doc, xls, etc). En esta entrada del
blog hablabamos de la forma de cargar las fotos de empleado en el sistema y
verlas en la transacción PA20/PA30, contenido relacionado con el que estamos
tratando en esta entrada.
Seleccionaremos el archivo asociado a la clase de documento elegida y el fichero

quedará anexado al objeto en el que estemos trabajando, un pedido de compra en
nuestro ejemplo. Para consultar los documentos anexados accederemos
desde el control del GOS a la opción “Listar anexos”. Aquí nos aparecera
la lista de todos los objetos creados a través del Gos: Anexos, Notas, Enlaces y
Documentos anexados con el archive link.
Tenemos otra alternativa para anexar documentos a los objetos de negocio, a

través de la transacción OAAD. Desde esta transacción podemos anexar
ficheros o bien realizar la busqueda directa (incluyendo la visualización posterior
de los documentos
anexados).
Para anexar, seleccionaremos la opción “Asignar y asignar” y el sistema

nos preguntara, el objeto de negocio a utilizar, la clase de documento a anexar y
el número del objeto donde estamos vinculando los documentos (en nuestro
ejemplo, un número de pedido), abriendo una ventana de navegación para
seleccionar los archivos a “subir”.
El “Business Object” es un código que representa al tipo de objeto de
la aplicación: por ejemplo, el BUS2012 representa un Pedido de compras, el
BUS1001 un Material, el LFB1 un Proveedor, etc. Es fundamental conocer estos
códigos tanto para parametrizar la funcionalidad como para su uso desde la
transacción OAAD.
Una vez anexados los documentos, tenemos disponible la opción de

búsqueda desde la OAAD con la opción “Búsqueda técnica” en la
sección Documentos. Desde aquí podemos realizar búsqueda de los documentos
anexados en 1 o varios objetos de negocio. Por ejemplo, para el business object
BUS2012 Pedido de compra, podriamos poner la lista de documentos de compra
para los cuales queremos sacar los documentos anexos.
Nada que ver con la opción de tener que entrar pedido por pedido a ver los anexos.
Ademas, tenemos la posibilidad de filtrar la búsqueda por multiples
criterios (repositorio, clase de documento, tipo de documento, fecha
de archivado, etc). Desde la lista de resultados, esta disponible la navegación
a los documentos con un doble click.
Desde la transacción OAOR también se puede realizar la búsqueda de los
documentos anexados a un determinado objeto de negocio.
Parametrización del ArchiveLink.
A la parametrización de las opciones del ArchiveLink se accede desde la ruta de

customizing Sap NetWeaver –> Servidor de Aplicacion –> Servicios
Base –> ArchiveLink –> Customizing de base.
En primer lugar, definiremos el lugar donde se van a almacenar los

documentosque anexemos utilizando el ArchiveLink, a través de la opción
de custo “Definir Repositorios de Contenido” o con la transacción
OAC0. Crearemos si es necesario un repositorio de contenido que siempre
tendrá que tener el Ambito de documento “ARCHLINK”, y que luego asociaremos
a nuestros objetos de negocio para indicar que el archivado para ellos se realizará
en este lugar.
Ademas, con la opción “Tipo de archivo” podremos indicar si los

documentos se almacenan fisicamente en la base de datos de Sap o
bien en un repositorio de contenido externo (por ejemplo, el content
server que Sap proporciona gratuitamente con sus productos y que requiere un
servidor adicional para depositar los documentos via HTTP).
A continuación, con la opción “Tratar tipos documentos” definiremos los
tipos de documentos que se pueden anexar (extensiones de fichero) y
el tipo MIME asociado, que determinará la aplicación que se utilizará para su
visualización. Sap dispone de varios tipos de documento prefijado que cubre los
más habituales, aunque es posible que tengamos que definir algunos propios.
El siguiente elemento a configurar serán las “Clases de Documento”, donde

definiremos nuestros documentos lógicos asociandolos a un tipo de
documento de los definidos en el punto anterior. Para nuestro ejemplo, vamos a
definir tres clases de documento, que serán la clase de documento que
permitiremos anexar a los pedidos de compra: Oferta del proveedor (del tipo
PDF), Catalogo de materiales (del tipo Excel xls), Fotos de materiales.del tipo
jpg).
A continuación configuraremos la opción “Tratar enlace” que relaciona el

objeto de negocio con las clases de documento y el repositorio de
contenido. Para cada objeto de negocio donde vayamos a permitir el enlace de
documentos, indicaremos las clases de documento permitidas y el repositorio de
documentos donde se va a almacenar (el que creamos en el primer paso de la
configuración). En el campo Conexión se indica la tabla donde se van a
guardar los enlaces a los documentos (Sap ofrece varias tablas para
mejorar el rendimiento del sistema, así como la posibilidad de crear nuestras
propias tablas Z de enlace (con la transacción OAC3, siguiendo como modelo la
estructura TOAV0).
Una vez completada esta parametrización, la opción “Archivar Business

Document” ya debe de aparecer activa en el GOS y las clases de documento
configuradas accesibles para anexar ficheros al pedido de compra del tipo
correspondiente.
Opciones generales del archivel link.
Existen unas opciones finales de configuración que se acceden desde la ruta de

customizing Sap NetWeaver –> Servidor de Aplicacion –> Servicios
Base –> Archive Link –> Customizing comunicación frontend.
Los aspectos que podemos configurar son las “Parametrizaciones de archivo y
visualizacion”, donde podemos indicar la forma de ver los resultados de
búsqueda, opciones de visualización, etc.
Como habeís visto, una opción sencilla de configurar y que ofrece bastante
posibilidades, sin llegar a ser un verdadero sistema de gestión documental.
Para terminar la serie, en la próxima entrada hablaremos del DMS y los registros
info de documento que nos ofrecen unas funcionalidades mucha más avanzadas
en la gestión documental, incluyendo un herramienta Windows (el Easy DMS) y
sistemas de búsqueda y clasificación mucho mas potentes.
Actualización 27.05.15
En las ultimas versiones de Sap se permite modificar la descripcion del

documento que se anexa, asi como ver el nombre del fichero. En esta entrada del
OSS se explica las notas que hay que aplicar en el caso de que no lo tengais en la
versión instalada:
http://scn.sap.com/thread/3400530
Truco 46. Gestion Documental en Sap (y III). DMS.
Publicado el 3 marzo, 2013por Roberto Espinosa
12 Votes
Para terminar nuestro monografico sobre las funciones básicas de gestión

documental que proporciona SAP, vamos a hablar de los registros info de
documento (DMS) y de las funcionalidades y herramientas que nos
proporciona Sap. Algunas de las características son:
 Gestión de aprobación de documentos con diferentes status (incluyendo
posibilidad de Workflow).
 Gestión de versiones.
 Utilización del sistema de clases para clasificar los documentos con criterios
propios.
 Busqueda de documentos por criterios multiples: clase de documento,
descripción, texto, valores de características de clasificación, por enlaces a objetos de
negocio, etc.
 Si tenemos montada la indexacion de documentos (servidor Trex), podriamos buscar
dentro del contenido de los documentos anexados.
 Gestion de documentos via Web (utilizando BSP).
 Sap Easy DMS: herramienta windows tipo explorador que nos permite crear,
modificar y visualizar los documentos, clasificarlos, anexar a objetos Sap. Incluye
funciones drag and drop, busqueda de documentos y la posibilidad de ordenar los
documentos en carpetas (cada carpeta tambien se crea en Sap como un registro info
de documento sin anexos).
 Los documentos se pueden almacenar en un repositorio tipo DMS (que
puede ubicarse en la base de datos de Sap o en un Content Server externo
(el de Sap u otro fabricante)) o bien en carpetas a nivel de sistema de ficheros u
otros sistemas de almacenamiento externo.
 Los documentos pueden estar almacenados de forma independiente en el sistema o
vinculados a objetos de negocio (la cantidad de objetos disponible es mucho menor
que para el ArchiveLink).
 En los objetos de negocio previstos tenemos dentro de las aplicaciones la
funcionalidad para ver los registros info de documento asociados. Por ejemplo, para
el maestro de materiales tenemos en Datos adicionales la pestaña Datos de
documento dondre podriamos ver todos los documentos relacionados.
 Otras funcionalidades: jerarquía de documentos para relacionar varios registros
de forma jerarquica, distribución, etc.
Como podeis ver, una funcionalidad mas completa y versatil que la que nos
ofrecian los anexos del GOS o el Archivelink.
Utilización de DMS. Creación de documentos.
Los Registros Info de Documento (DIR) se pueden crear directamente

con una transacción especifica, la CV01N (CV02N para modificar y CV03N
para visualizar).
Trabajamos con clases de documento (que previamente habremos

parametrizado). Al crear un registro info de documento, le indicamos una
descripción, información de status, responsable, etc (hay diferentes campos
disponibles, para los cuales se puede configurar su disponibilidad, obligatoriedad
o no, etc) así como los anexos a los documentos originales asociados. Ademas, si
para la clase de documento hemos indicado una clase asociada, podremos indicar
los valores de característica que clasifican al documento así como
el enlace a objetos de negocio Sap (también se parametriza por clase de
documento a que objetos podemos vincular). En nuestro ejemplo, al maestro de
materiales.
Con el status del documento podemos gestionar un sistema de

aprobación de los documentos (incluyendo un Workflow), impidiendo
igualmente si es necesario la modificación de los documentos una vez aprobados.
Si se ha parametrizado a nivel de clase de documento, también se
pueden crear los registros info de documento desde las transacciones
asociadas a los objetos de negocio. Por ejemplo, para el maestro de
materiales, lo podremos hacer desde la sección Datos Adicionales, pestaña Datos
de Documento en la transacción
MM01/MM02.
Además, en este lugar podremos ver todos los documentos que se han creado en
el sistema (desde cualquier fuente) asociados al objeto de negocio material. Desde
este lugar se puede acceder a la modificación/consulta de los documentos ya
creados o a crear nuevos registros.
La tercera alternativa para crear o modificar documentos sería la

utilización de las herramientas externas: la via Web (que no vamos a ver)
y el Easy DMS. Como indicamos antes, el Easy DMS es una herramienta que
proporciona Sap y que nos permite, en un entorno Windows, similar al Explorer,
realizar la gestión de los documentos.
En nuestro ejemplo, hemos creado una estructura de carpetas (es una de las
ventajas de la herramienta) para diferencias los diferentes documentos que
vamos a anexar. Al crear las carpetas también se crea un registro info de
documento para cada una de ellas (sin anexos).
Desde el Easy DMS podemos crear o modificar los documentos, en un entorno

visual totalmente conectado con Sap, donde se nos pedirá toda la información
relevante según la parametrización de la clase de documento que estemos
utilizando. Igualmente, para datos que requieran una lista de valores o para el
enlace con los objetos de negocio de Sap, tenemos disponibles las ayudas de
búsqueda que leen en la base de datos de Sap.
Esta herramienta es mucho más versatil que la transacción CV01N/CV02N y

permite realizar la gestión documental de una forma mucho más intuitiva.
Utilización de DMS. Búsqueda de documentos.
Para buscar en los documentos desde Sap podemos utilizar la

transaccion CV04N, la cual nos permite restringir la selección por todos los
criterios asociados al documento: número, descripcion, status, características de
clasificación, enlace de objets. etc.
Los resultados se visualizan en forma de lista (tambien se pueden ver en forma

de mosaico), pudiendo acceder desde aquí a visualizar tanto el contenido de los
registros info de documento como los documentos anexados propiamente dichos.
Si hubiesemos tenido instalado un servidor Trex con indexación de documentos

tendriamos activa en esta transacción la búsqueda por texto completo dentro de
los documentos.
También podriamos realizar la búsqueda de documentos via Web o desde la
herramienta Easy DMS, que también tiene habilitadas las funciones de
búsqueda.
Una vez ejecutada la búsqueda, el sistema nos devuelve la lista de documentos

que cumplen las condiciones (no necesariamente creados con el Easy DMS), sino
que también nos aparecen los documentos creados directamente desde Sap.
Desde los resultados de búsqueda podemos acceder a las propiedades del registro
info de documento y también a visualizar los anexos (si el estado del documento
lo permite también podriamos editar su contenido y generar una nueva versión
del documento).
Parametrización del DMS.
Los aspectos más relevantes de la parametrización de las funcionalidades vistas

son:
 Creación del repositorio de contenido (transacción OAC0), que siempre

tendrá que ser del tipo DMS. Para el caso de que vayamos a realizar archivado a nivel
de sistema de ficheros, no será necesario disponer de un repositorio. Este repositorio
podrá estar en la base de datos de Sap o en un Content Server externo.
 Creación de categoria de archivo (transacción OACT): para poder utilizar el

repositorio creado en el punto anterior, es necesario vincularlo a una categoria de
archivo, que crearemos en este punto de parametrización. Siempre del ámbito de
documento DMS.
 Configuración de las clases de documento: es la parte más importante de la

parametrización en el sistema documental. Se accede desde la ruta de customizing
Componentes multiaplicaciones –> Gestion de documentos –> Datos de control –>
Definir clases de
documento.
Aquí definiremos los diferentes status que tenemos disponibles según la

clase de documento (y como la secuencia entre cada uno de elos y atributos
que personalizan el comportamiento de los documentos).
Igualmente definiremos el enlace de objetos permitidos a la clase de

documento y si permitimos crear documentos solo desde la CV01N o también
desde las transacciones asociados al objeto de negocio (como vemos en la imagen,
el valor 1 en crear documento nos lo permite, el valor 2 solo desde la CV01N).
En la configuración de la clase de documento le indicaremos el rango de

números a utilizar (también habrá que parametrizarlo), si el archivo es
Kpro o no. Igualmente, definiremos si utilizamos una clase para
la clasificación de los documentos, campos disponibles en la
información del documento (con opciones de ocultarlos, hacerlos
obligatorios u opcionales, etc), etc.
 Definir aplicación para la estación de trabajo: en la ruta de customizing

Componentes multiaplicaciones –> Gestion de documentos –> Datos generales –
>Definir aplicacion para la estacion de trabajo. Aquí definimos las extensiones para
los documentos que vamos a poder utilizar y las aplicaciones relacionadas para su
visualización/modificación.
En el caso de no archivar los documentos anexados en el Content Server y

realizarlo a nivel de sistema de ficheros, tendremos que configurar los soportes
de datos en la ruta de parametrización Componentes multiaplicaciones –> Datos
generales –> Definir soporte de datos.
Nota importante: en el archive link habia una vinculación directa con

el lugar donde se almacenaban fisicamente los documentos a traves
de la asociación Objeto de negocio, clase de documento y repositorio
de contenido.
En el DMS esta vinculación no existe de forma directa y se indica al
anexar los documentos con la categoria de archivo (si estamos en el
Easy DMS, si la clase de documento es KP nos mostrara las categorias
de archivo del ambito de documento DMS; si no es KP, nos mostrara
los soportes de datos definidos; si estamos en la CV01N, nosotros
seleccionaremos la categoria de archivado o el soporte de datos). Es
importante tener esto en cuenta. Si se pueden configurar valores
propuestos en los Perfiles de gestión de docuentos (Datos generales –
> Definir perfil) o en valores predeterminados en el Easy DMS.Esto es
uno de los temas más confusos de la parametrización del DMS, y hay que revisarlo
con detenimiento y entender bien para su correcta utilización.
La parametrización mostrada en esta entrada esta descrita de forma general y no

detallada, teniendo disponibles otras configuraciones adicionales que tendremos
que tener en cuenta según el tipo de archivado documental que vamos a realizar.
Para concluir, podemos indicar que la funcionalidad esta disponible para enlazar
los objetos de negocio más habituales como por ejemplo:
 Activos fijos: inmovilizado (objeto ANLA).

 Posicion de solicitud de pedido de compras (objeto EBAN).
 Posicion de pedido de compras (objeto EKPO).
 Maestro de equipos (objeto EQUI).
 Ubicaciones técnicas de mantenimiento (objeto IFLOT).
 Puntos de medida de mantenimiento (objeto IMPTT).
 Cliente (objeto KNA1).
 Proveedor (objeto LFA1).
 Maestro de materiales (objeto MARA).
 Unidad organizativa (objeto NORG).
 Aviso mantenimiento (objeto PMQMEL).
 Listas de materiales (cabecera: objeto STKO_DOC, posiciones: STPO_DOC).
 Elementos Pep (objeto PRPS).
 Etc, etc.
En mi experiencia en proyectos lo he visto utilizar sobre todo en la gestión del
módulo de mantenimiento, para añadir documentación de ubicaciones, equipos,
avisos, etc o en el módulo de gestión de calidad (QM). Igualmente, en los
documentos de compras para anexar especificaciones de la compras de
determinados materiales, equipos o servicios.
Documentación adicional: Manual de Instalacion del Content Server que Sap

proporciona de forma gratuita (requiere un servidor adicional, con servidor
Internet activado): Content_Server_Win_640. Lo utilizaremos en el caso de que
no queramos almacenar los documentos en base de datos o a nivel de sistema de
ficheros, y si en un servidor de repositorio externo (existen otros productos de
fabricantes distintos a Sap). Si necesitais descargaros el software, desde
el http://service.sap.com/swdc, buscando a continuación Content Server (Sap
proporciona la licencia gratuita, incluyendo la base de datos MaxDB).
Truco 47. Proteccion de modificaciones de campos en
maestro de clientes y proveedores.
10 Votes
En algunos de mis proyectos, algún key-user de finanzas me ha consultado si

existia la posibilidad de restringir la modificación de determinados
campos “CRITICOS” del maestro de clientes o proveedores, con el
objeto de evitar errores.
Seria asi como establecer dos niveles de autorización a la hora de modificar los
datos maestros de deudores y acreedores. En el primer nivel estan todos los
usuarios que tienen acceso a modificar las fichas de datos maestros,
excepto a algunos campos (que nosotros seleccionaremos), cuya
modificación estará restringida y solo podrá ser realizada por los usuarios que
tengan unos determinados objetos de autorización en sus perfiles. En este primer
nivel determinados campos apareceran en gris y podran ser visualizados por el
usuario, pero no modificados. Esto puede tener sentido si queremos que algunos
usuarios puedan modificar datos de dirección o contacto, una cuenta bancaria,
direcciones de correo, pero no queremos que toquen campos delicados como la
forma de pago, cuenta asociada, via de pago, datos fiscales, grupo de tesoreria u
otros datos de clasificación.
En el segundo nivel, los usuarios tendrán acceso a la modificación de
datos maestros de una forma completa, sin limitaciones. De ellos
dependerá la correcta modificación de estos campos críticos.
La parametrización se realiza desde las rutas de customizing:
 Clientes: Gestion financiera –> Contabilidad de deudores y acreedores –> Cuentas

de deudor –> Datos maestros –> Preparar modificacion de datos maestros de
deudores.
 Proveedores: Gestion financiera –> Contabilidad de deudores y acreedores –>
Cuentas de acreedor –> Datos maestros –> Preparar modificacion de datos maestros
de acreedores.
Veamos un ejemplo de parametrización sencillo para proteger determinados
campos en las fichas de cliente de la sección de datos generales y datos de
sociedad.
Identificación de los campos a proteger.
Localizamos los campos desde la transaccion de modificación de clientes (XD02;

para proveedores sería la XK02). Nos posicionamos en cada campo y pulsamos
F1, y a continuación el botón de Información Técnica. En datos de campo tenemos
la tabla y el nombre de campo en el que estamos interesados.
En nuestro ejemplo, vamos a proteger los campos:
 Datos generales –> Datos de Control –> Autorizacion: campo KNA1-BEGRU.

 Datos generales –> Datos de Control –> Sociedad GL: campo KNA1-VBUND.
 Datos generales –> Datos de Control –> Nº. ident.fis 1: campo KNA1-STCD1.
 Datos generales –> Datos de Control –> N.I.F. comunitario: campo KNA1-STCEG.
 Datos de sociedad –> Gestion de Cuenta –> Cuenta Asociada: campo KNB1-
AKONT.
 Datos de sociedad –> Pagos –> Condiciones de pago: campo KNB1-ZTERM.
 Datos de sociedad –> Pagos –> Vias de pago: campo KNB1-ZWELS.
Creacion del grupo de campos.
Siguiendo la ruta de customizing indicada antes, entramos en la opción

“Definir grupos campos para datos maestros deudores”. Aquí creamos
una etiqueta númerica de dos digitos para identificar al grupo, una descripción y
siempre dejaremos el flag “Sin autorizac.” desmarcado para indicar que queremos
proteger los campos del grupo por autorizaciones.
Sino queremos que se haga la verificacion de autorizaciones, entonces

marcaremos el flag “Sin autorizac”. En ese caso, el grupo de autorizaciones
se utilizara con fines de reporting. El grupo de campos nos permitira
analizar que modificaciones se han realizado en el maestro de clientes o
proveedores en los campos que forman el grupo. Asi se facilita el analisis de las
modificaciones (utilizaremos el report RFDABL00 para clientes y el report
RFKABL00 para proveedores). Es una opción muy útil para hacer análisis de
modificación de determinados campos.
Inclusion de los campos a proteger en el grupo de campos.
El siguiente paso consiste en detallar los campos que conforman cada

grupo. Para ello, entramos en la opción “Agrupar campos de registros
maestros de deudor” y para el identificador de nuestro grupo, detallamos los
campos que indicamos antes.
Tenemos disponible una ayuda de búsqueda con todos los campos del maestro de
clientes o proveedores disponible (incluyendo la parte general, de sociedad o de
ventas/compras).
Asignación de autorizaciones a los usuarios.
Con la transacción PFCG creamos un rol de autorizaciones que

incluira los objetos de autorización necesarios para modificar los campos
incluidos en los grupos parametrizados anteriormente. Estos objetos son:
 F_KNA1_AEN: para clientes.
 F_LFA1_AEN: para proveedores.
En el objeto de autorización indicamos para que grupos de campos el

usuario que posea este rol va a poder modificar los campos. Esto
significa que podemos tener diferentes autorizaciones de forma que un usuario
podrá solo modificar un determinado grupo de campos (aparte de los que no
estan protegidos), otro usuario otro grupo e incluso un tercer usuario ambos
grupos (asignandole los correspondientes roles). Esto nos da juego para en
organizaciones grandes donde cada departamento puede gestionar determinados
datos maestros, sea el propio departamento el único autorizado a modificar los
datos que le afectan.
Para terminar, asignaremos al usuario con las transacciones SU01 o
SU10 los roles definidos y ya podremos comprobar entrando al sistema la
efectividad de la nueva parametrización realizada (en combinación con las
autorizaciones creadas y asignadas).
Para el usuario sin el objeto de autorización F_KNA1_AEN, los campos
previstos estan “en gris”, no modificables.
Para el usuario con el objeto de autorización F_KNA1_AEN, todos los
campos están visibles.
Espero que os sea de utilidad la información.

Truco 49. Autorizaciones desde el Modulo de
Organizacion. Roles de usuario con PFCG(I).
6 Votes
En nuestro dos próximos trucos volvemos al modulo Basis para hablar de una
funcionalidad no demasiado conocida pero que puede ser muy útil si
queremos utilizar el modulo de Organización para construir la
estructura de puestos de trabajo de nuestra organización (desde el
punto de vista de RRHH o también desde el punto de vista de uso o funciones en
Sap). Cada unidad organizativa y/o puesto de trabajo tendrá asociadas
las diferentes autorizaciones en el sistema, de forma que cuando un
empleado/usuario sea asignado en los diferentes puestos/roles en el
arbol organizativo, automáticamente en su perfil de usuario Sap se
asignarán todas las autorizaciones vinculadas para que pueda
desempeñar las funciones previstas.
De esta forma se realiza una gestión de las autorizaciones mucho más
ordenada. Utilizando el arból organizativo de las transacciones del
modulo de organización (PPOMW/PPOSW), podemos ver de forma visual
nuestra estructura y quién esta asignado en cada lugar (asi como los roles de
autorización asignados). Como os digo, puede ser una funcionalidad muy
interesante para poner un poco de “orden” en el laberinto en el que se suele
convertir la gestión de autorizaciones en Sap conforme los proyectos van
evolucionando.
Antes de entrar en profundidad en el módulo de organización y ver la forma de

configurarlo para utilizarlo desde la visión de la gestión de autorizaciones (no
desde el punto de vista de RRHH u organigramas, aunque podrian ser
compartidos), vamos a hacer un repaso a los aspectos mas importantes de
las autorizaciones en Sap. El control de autorizaciones es un concepto
transversal en Sap (afecta a todos los módulos) y es fundamental su buena
definición para evitar que los usuarios tengan acceso a funciones o tareas para las
que no deberían de estar autorizadas por sus funciones en la empresa (en especial
a determinados tipo de operaciones o informes).
Objeto de autorización.
Las autorizaciones en Sap se basan en dos unidades básicas de gestión: el campo
de autorización y el objeto de autorización.
Con los campos de autorización definimos tecnicamente la longitud de los

campos de autorización (dominio), así como los valores posibles que se van a
poder indicar en ellos cuando los utilicemos en las definición de nuestras
autorizaciones. Por ejemplo, para el control de acceso a transacciones se utiliza el
campo TCODE, que tiene el dominio tcode que permite utilizar valores en el
campo de longitud 20 (suficiente para cualquiera de las transacciones definidas
en Sap).
En otras autorizaciones debemos de indicar que tipo de actividad esta permitida
o no para el usuario. Para este caso, tendremos por ejemplo el campo de
autorizacion ACTVT que utiliza el dominio ACTIV_AUTH, asociado a una tabla
de valores que indicarán los diferentes actividades que podemos hacer, por
ejemplo, en el mantenimiento de datos maestros de articulos, clientes,
proveedores, etc (Añadir, Modificar, Borrar, Visualizar modificaciones, etc).
Los campos de autorización se definen en la transacción SU20. Sap

dispone de campos de autorización suficientes para crear nuestros propios
objetos de autorización (aunque es posible si fuera necesaria alguna
personalización especifica), crear nuestros propios campos de autorización.
El objeto de autorización es el nivel superior dentro de la gestión de
autorizaciones y el objeto básico con el que trabajaremos.
Básicamente, un objeto de autorizacion en una etiqueta (nombre
técnico) y un conjunto de campos de autorización asociados (de los
vistos anteriormente). Los objetos de autorización se mantienen en
la transacción SU21, estando clasificados de forma estandar por los diferentes
módulos y componentes de Sap. También podremos crear nuestros propios
objetos de autorización insertandolos en una clase Z (las clases se crean desde la
transacción SU03).
La asignación de autorizaciones se realiza utilizando los objetos de

autorización, asignando a cada campo una serie de valores, que
indican las operaciones permitidas dentro del ambito del objeto de
autorización. En el ejemplo de la imagen, podemos ver como el objeto de
autorización esta siendo utilizando en un rol de autorizaciones y como se le
asignan determinados valores que luego serán los que tenga el usuario al que este
rol sea asignado.
Dentro de la programación de las aplicaciones SAP, con la sentencia

“AUTHORITY-CHECK” verificaremos que el usuario dispone de la
autorización correspondiente y le dejaremos continuar o no con la acción a
realizar (en caso de informes podremos estar restringiendo también la
información a mostrar). En el estandar Sap lo hace de forma automática, aunque
este procedimiento lo podremos incluir también en nuestros desarrollos Z.
* Verificacion de autorizacion para crear pedidos de venta
AUTHORITY-CHECK OBJECT ‘V_VBAK_AAT’
ID ‘AUART’ FIELD VBAK-AUART
ID ‘ACTVT’ FIELD ’01’.
IF SY-SUBRC ne 0.
message e008(ZSISTEMAS) with ‘SIN AUTORIZACION PARA C
LASE DOC’.
ENDIF.
Como podeís ver, al final se acaba chequeando cada objeto de autorización
concreto y los valores de este. Si el usuario tiene asignada la autorización
requerida, puede llevar a cabo la acción. En caso contrario, se genera un mensaje
de error o simplemente no tiene acceso a la visualización de los objetos
involucrados.
Hay objetos de autorización para casi todo en Sap, desde el acceso a ejecutar
transacciones que veiamos antes (TCODE), objetos para modificar datos
maestros en los diferentes ambitos (general, centro, sociedad, organización de
ventas, sociedad CO, organización de compras, etc). También hay objetos de
autorización para las funciones básicas del sistema. De esta forma, casi cualquier
operación sobre el sistema, siempre se podrá permitir o no (con la ausencia de la
autorización).
Perfiles de autorización.
En versiones anteriores no existia el concepto de roles y se trabajaba con los
perfiles de autorización. Estos no eran mas que un conjunto de objetos de
autorización con sus correspondientes valores que se asignaban a los usuarios en
la transacción SU01/SU10. En versiones mas recientes se introdujo un concepto
mucho mas potente, el de los roles (aunque realmente por detras siempre siguen
estando los perfiles de autorización). Los roles se gestionan desde la transaccion
PFGC y tiene un generador automatico de perfiles de autorización que veremos a
continuación, que facilitan la utilizacion de los objetos de autorización.
Sino queremos trabajar con los roles, siempre podemos definir los perfiles
de autorización con la transacción SU02 (opción que no os
recomiendo en absoluto).
En los perfiles se indican los diferentes objetos de autorizacion que vamos a

asignar al usuario y con la autorización, que valores incluidos para los campos de
dichos objetos. Finalmente, estos se asignan a los usuarios mediante la
transacción SU01 en la pestaña Perfiles.
Roles de usuario simples.

Con la introducción del concepto de Rol Sap dio un respiro a los administradores
del sistema y les facilito mucho la vida a la hora de realizar la tediosa
configuración de las autorizaciones en Sap.
Los roles se definen con la transacción PFCG y son un nivel superior

dentro de la gestión de autorizaciones con funcionalidades añadidas como:
 Creación de menus de usuario asociados al rol: en el rol se define una
estructura de carpetas y las transacciones que se van a poner a disposicion del
usuario.
 Ademas de incluir en el menú transacciones ya creadas, podemos crear las nuestras

propias directamente aquí, enlazando a Programas Abap, Querys, Informes de
Report Writer o de Investigación, etc:
 Transferencia de menus al rol desde los menus de ambito Sap, de otros roles, desde
ficheros de texto.
 Traducción de los textos asociados o modificación de estos en el ámbito del menu
para indicarles textos mas significativos a los usuarios.
Una vez indicadas las transacciones, reports, etc que se asocian al rol, la
transacción PFCG automaticamente nos genera o actualiza el perfil de
autorizaciones asociado al rol con los objetos de autorización
necesarios. Según cada transacción o report indicado, el sistema nos genera una
propuesta de autorizaciones que tendremos que actualizar (habrá que concretar
los objetos referentes a las unidades organizativas de los diferentes módulos,
clases de actividad permitidas, clases de documentos, etc, etc).
Desde la pestaña de autorizaciones podemos acceder a la modificación del perfil

de autorizaciones. Aquí podremos ver todos los objetos de autorización
asignados, asi como los campos relacionados con cada uno de ellos y los valores
asignados. Os recomiendo activar siempre la visualización de los
nombre técnicos a través de la opción de menú Utilidades –> Activar
nombre técnicos.
Además de la propuesta de objetos de autorización que nos realiza Sap según las
transacciones indicadas, podremos incluir manualmente nuestros
propios objetos de autorización o bien copiarlos de otros modelos
(perfil de autorizaciones, modelo, etc). Es interesante conocer que Sap
dispone de un repertorio de Roles y Perfiles de autorización estandar que
posiblemente podamos utilizar como módelo para nuestras propias
autorizaciones.
IMPORTANTE: una vez concluida la definicion de objetos de

autorizacion y sus valores, siempre hay que generar el perfil de
autorización para que este sea activo y sus valores aplicables a los
usuarios.
El último paso sería la asignación del Rol al usuario, bien desde la misma
transacción PFCG en la pestaña Usuario o bien desde el mantenimiento de datos
de usuarios (transacciones SU01 / SU10 en la sección Roles).
Una vez asignado el Rol al usuario, las autorizaciones estarán disponibles para el
usuario en cuestión y si hemos incluido un arbol de transacciones, estas estaran
visibles en el Menu del usuario en Sap.
En el Rol no es obligatorio indicar un menú de transacciones, puede

incluir unicamente el perfil de autorización (es decir, incluir unicamente objetos
de autorización con sus correspondientes valores asignados).
Roles de usuario compuestos.

Los Roles de autorización compuestos también se mantienen desde la
transacción PFCG y consisten en roles que a su vez estan formados
por varios roles simples. Son un mecanismo para “agregar” varios roles y
facilitar su asignación a los usuarios.
Cuando vemos como esta el rol asignado en el maestro de usuarios, aparece el rol
compuesto (es el que podremos asignar o desasignar) y luego en color azul los
roles que forman ese rol compuesto (se hace la explosion al asignarlo en el
usuario).
Es un buen mecanismo para “agrupar” autorizaciones y simplificar la gestión de

la asignación a los usuarios.
Analisis de autorizaciones y traza.

Para concluir este repaso a nociones básicas de autorizaciones en Sap, os
recomiendo una lectura anterior del blog donde hablabamos de como analizar
problemas con autorizaciones y como realizar una traza en el sistema para
obtener que autorizaciones se verifican realmente: ver
entrada aquí. Resumiendo:
 Transacción SU24: objetos de autorización verificados en cada transacción.
 Transacción SU53: ultima verificación de autorizaciones erronea realizada en el
usuario actual.
 Transacción SU56: autorizaciones existentes en memoria para el usuario actual
(las asignadas en su perfil).
 Transacción ST01: traza de autorizaciones verificadas (también la
transacción STKONTEXTTRACE). Nos permite hacer una medición de todas las
autorizaciones que son verificadas en un determinado usuario, transacción, etc.
Las autorizaciones SU53 y SU56 seria conveniente que estuvieran

asignadas a todos los usuarios por autorizaciones (o bien permitiendo siempre
su ejecución con el parametro de sistema auth/tcodes_not_checked).
Una vez introducidos los conceptos básicos de autorizaciones, en nuestra
próxima entrada veremos la forma de gestionar las autorizaciones
utilizando el módulo de Organización de Sap, y como asignando los
usuarios a las posiciones del Organigrama, podremos derivar la asignación
automatica de autorizaciones. Con una herramienta visual podremos de forma
jerarquica ver nuestra estructura de usuarios y las posiciones funcionales y roles
de autorización que tienen asignados.
Truco 50. Autorizaciones desde el Modulo de
Organizacion. PPOCW y PPOMW (y II).
4 Votes
Una vez creados todos los roles de autorización necesarios para la gestión de los
procesos de usuario en Sap (puede ser uno de los temas que mas tiempo nos
pueda llevar por su complejidad), procederemos a crear la estructura del
organigrama dentro del módulo de organización. Básicamente, el
organigrama es una estructura jerárquica con diferentes tipos de componentes
vinculados entre si en forma de árbol. Los elementos que vamos a usar para
poblar este árbol con nuestra estructura organizativa y de autorizaciones son los
siguientes (los que a nosotros nos afectan para la gestión de autorizaciones):
 Unidad Organizativa: corresponde con la estructura de departamentos dentro de

la empresa u organización. En nuestro ejemplo, las hemos marcado en Rojo. Podrian
corresponder a las divisiones de una empresa, direcciones, departamentos, areas
funcionales, etc. Las unidades organizativas utilizan la sigla O (las siglas son el
código que identifica a cada uno de los tipo de objeto que vamos a poder
utilizar en la definición de la estructura).
 Posición: corresponde a los diferentes puestos de trabajo dentro de nuestra
organización (puede corresponder a posiciones funcionales, por tipo de trabajo o
tareas). En nuestro ejemplo, las hemos marcado en Azul. Las posiciones utilizan
la sigla S.
 Empleado: podriamos asignar empleados del módulo de RRHH de Sap a las
posiciones y despues desde el infotipo 0105 asociarle un usuario al que derivará las
autorizaciones. En nuestro ejemplo no lo vamos a utilizar, pero que sepais que
también existe esa posibilidad. Los empleados utilizan la sigla P (Persona).
 Usuario: codigos de usuario de los creados en el sistema (transacción SU01). En
nuestro ejemplo, en color Naranja. Se usa la sigla US.
 Rol: códigos de los roles de autorización que hemos creado en el sistema (transacción
PFCG). En nuestro ejemplo, en color Verde. Se usa la sigla AG.
El paso final, una vez creado el organigrama y asignados los diferentes elementos
necesarios en el es la explosión de la autorizaciónes a partir del arbol y
las relaciones de vinculación establecidas entre los diferentes objetos
que lo forman. Esta tarea se realiza a través de la transacción PFUD
(report RHAUTUPD_NEW). Este proceso se puede lanzar manualmente o
bien automatizar a través de un job que hará el trabajo por nosotros.
A continuación vamos a ver de forma detallada el proceso de creación del
organigrama, la explosión de las autorizaciones desde el arbol al maestro de
usuarios y finalmente la parametrización necesaria para poder utilizar esta
funcionalidad.
Creacion de nuestro organigrama.

Con la transacción PPOCW crearemos la unidad organizativa raiz y las
diferentes unidades organizativas y posiciones que forman nuestro
organigrama. Este organigrama podra estar construido desde el punto de vista
de la Recursos Humanos (si vamos a utilizar la asignación de empleados) o desde
el punto de vista de uso funcional de Sap (si vamos a utilizar la asignación de
usuarios). Puede darse el caso de que ambas “vistas” coincidan y utilizemos un
único arbol.
La primera vez que entramos en la transacción, se crea la unidad organizativa
raiz, que es la base desde la que colgarán el resto de elementos.
A continuación, podremos ir creando el resto de elementos que

cuelgan de la raiz (igualmente desde la transacción PPOCW o desde la
PPOMW). Para crear nuevas unidades organizativas o posiciones,
seleccionaremos el lugar del que queremos que dependan y seleccionaremos el
botón Crear. El sistema nos preguntará el tipo de elemento a crear:
Unidad organizativa o Posición. Le indicaremos una sigla (nombre corto),
una descripción, pudiendo indicar también otros aspectos como un Texto largo,
información de imputación del modulo de Controlling o Tareas asignadas a la
posicion (el módulo de organización también nos permite la definicion de tareas y
su vinculacion a los objetos, pero no vamos a entrar en esta funcionalidad).
Siguiendo el mismo procedimiento completaremos todo el organigrama con la

información de los diferentes departamentos, areas, direcciones, así como los
diferentes puestos de trabajo que los conforman. Una vez completada la
estructura, procederemos a la asignación de los roles de
autorización en las diferentes unidades organizativas y posiciones. Es
importante saber que podemos asignar los roles en cualquier unidad
organizativa o posición, y que las autorizaciones se heredan hacia
abajo. Si, como en nuestro ejemplo, indicamos unas autorizaciones en el nivel
del Departamento de Cuentas a Cobrar y de este departamento cuelga una
posicion con otra asignación de roles de autorizacion, el usuario que ocupe esa
posición recibira tanto los roles de la unidad organizativa como de la posición.
Esto nos permite definir autorizaciones genéricas para el departamento y otras
especificas por posicion (mas especializadas o restringidas). Los mismo para
autorizaciones generales que pueden indicarse en la posición raiz para que sean
heredadas por todos los usuarios (tipo autorizaciones generales de uso de
funciones básicas).
Para asignar los roles, seleccionaremos el boton Asignar y a continuación
seleccionaremos el tipo de objeto Rol (sigla AG). Sap nos permitirá buscar
entre los diferentes Roles simples o compuestos que tengamos definidos en
nuestro sistema y asignarlos a la Unidad organizativa o posición en la que nos
encontremos posicionados (permite selección multiple al hacer la asignación, lo
que es una gran ventaja).
El ultimo paso sería, siguiendo el mismo procedimiento de asignación, llenar

las diferentes posiciones con los usuarios que van a desarrollar cada
una de las funciones descritas. Para ello, siguiendo el mismo procedimiento,
pulsaremos el botón Asignar, seleccionaremos el tipo de objeto US
(Usuario en este caso) e indicaremos los códigos de usuario Sap incluidos en la
posición (varios usuarios podrá ocupar una misma posición, y Sap permite la
selección multiple en la asignación).
NOTA IMPORTANTE: cuando estemos realizando tanto la creacion de las
unidades organizativas, posiciones, asi como la asignación de roles y usuarios, es
importante haber indicado una fecha de inicio para las vinculaciones (todos los
objetos se relacionan entre si con una fecha de validez inicio/fin, con el objetivo
de permitir cambios a futuro en la estructura, que sera variable). Para ello,
pulsaremos tal y como vemos en la imagen el botón “Fecha y periodo previsión”
e indicaremos la fecha inicial para la validez de las vinculaciones que vayamos
realizando en la estructura.
De una forma visual hemos construido la estructura de nuestra empresa,

llenandola desde un punto de vista de las autorizaciones. De forma gráfica
tenemos toda la estructura del sistema dibujada, y podemos saber donde “cuelga”
cada usuario y que autorizaciones tiene concedidas, de una forma más legible que
viendo su ficha de usuario con la SU01. Además, tenemos disponibles funciones
de búsqueda potentes que nos permiten localizar los diferentes elementos dentro
del árbol.
Explosión del organigrama hacia los datos maestros de usuario.

La explosión del organigrama (roles) hacia el maestro de usuarios se realiza a
través de la transacción PFUD (que utiliza el report estandar
RHAUTUPD_NEW). La explosión la realizaremos en dos pasos:
1) Generaremos los roles en el maestro de usuario derivandolos de la
asignación organizativa: para ello, en la transacción
PFUD seleccionaremos la opción “Comparacion Gestion Organizacion
HR”.
El programa lee la estructura del organigrama, busca los roles que hayamos
indicado en los criterios de seleccion (Z* corresponderian a nuestra definición de
Roles) dentro del arbol, los relaciona con los usuarios asignados a las unidades
organizativas o posiciones, y los asigna dentro del maestro de usuarios. Para
hacer este proceso se utilizan las vias de evaluación, que han de estar
correctamente configuradas como veremos más adelante.
Con este primera ejecucion de la transacción hemos pasado de tener el usuario

sin roles en sus datos maestros a estar asignados los roles correspondientes,
aunque, es importante, sin activar (tal y como observamos en la imagen).
2) Para completar la activación de los roles asignados, volveremos a ejecutar
la transacción PFUD, pero seleccionando en esta ocasión las opciones
“Comparación de perfil” y “Comparacion de roles compuestos”.
Esta segunda ejecución recorre los roles (ya sin ser relevantes los datos del
organigrama), busca los usuarios que lo tienen asignado y activa los roles en los
datos maestros del usuario. Tras esta segunda ejecución, los roles ya aparecen
activos en el usuario, estan disponibles para que el usuario pueda trabajar en el
sistema con las funciones descritas.
La ejecución de estos dos procesos se puede planificar en forma de
job (2/3 veces al día) para que el ajuste se haga de forma automatica. De esta
forma, la asignación de los usuarios en el organigrama estará activa pasadas unas
pocas horas de forma automática (aunque siempre tendremos la opción de forzar
la actualización con una ejecución a demanda de la transaccion PFUD). La misma
transacción PFUD permite la generación de los jobs.
Parametrización necesaria para activar la funcionalidad.
 Definir una Variante de Plan Activa: en la transaccion OOPV crearemos la
variante y la activaremos. En la transaccion OOAP la asignaremos al grupo PLOGI.
 Tabla PRGN_CUST: El flag de Customizing HR_ORG_ACTIVE se habra de

activar con el valor YES: este valor activa la gestion de modulo de
organización para la gestion de roles de autorización (se realiza con la
transacción SM30 o SM31).
 Via de evaluación US_ACTGR: ajuste de la vias de evaluacion US_ACTGR (table

T77AW) a través de la transacción OOAW. La via de evaluación es la
parametrizacion que permite la lectura de la asignación de los roles en el arbol
organizativo y a partir de ahí derivar los usuarios a los que asignar los roles en su
maestro de usuarios. Basicamente, determinamos la forma en que el programa de
evaluación, partiendo de las posiciones o unidades organizativas que tienen
asignados los roles, recorre hacia arriba el árbol hasta encontrar los códigos de los
usuarios a los que asignar los roles.
Nota importante: para que funcione la herencia de roles de unas

unidades organizativas a otras que dependan de ellas ha de estar
creada la linea 101 de la imagen (no viene en la configuración estandar).
Sin ella no funciona la herencia (solo la herencia de primer nivel, de unidad
organizativa superior a posicion, y de ahí al usuario).
Links y documentación adicional.
 Ayuda de Sap sobre la
funcionalidad: http://help.sap.com/saphelp_nw70ehp2/helpdata/en/92/e7623c
28695c63e10000000a11405a/content.htm.
 Manual de usuario: Indirect Role Assignment Using HR-ORG[1]. En este
documento de forma detallada la funcionalidad, conceptos adicionales, asi como la
distribución entre diferentes sistemas.
 Entrada del SCN donde se explica la configuración necesaria para permitir
herencia de roles de unidad organizativa hacia abajo (de unidad
organizativa superior a inferior) en las vias de
evaluación: https://scn.sap.com/thread/1899175.
Truco 51. Utilizando el sistema de informacion de
usuarios (SUIM).
6 Votes
Continuando con el tema de las autorizaciones de las que hablamos en nuestros

dos anteriores posts del blog, hoy veremos el Sistema de Información de
Usuarios. Para la gestión de autorizaciones es fundamental conocer el Sistema
de Información de usuarios (se accede desde la transacción SUIM). Con
una gran variedad de herramientas, nos permite realizar análisis relacionados
con las autorizaciones asignadas a los usuarios en sus datos maestros, roles,
perfiles de autorización y
objetos.
La ejecución de los reports se realiza seleccionando el icono ejecutar.
Algunos de los informes más interesantes son:
 Usuario –> Según fecha de alta y modificación clave de acceso:

resumen de los usuarios del sistema, ultima entrada al sistema, estado de la
clave de acceso, bloqueo,
etc.
 Usuario –> Con autorizaciones críticas: para detectar usuarios con

autorizaciones criticas (por ejemplo, usuarios que pueden modificar el
maestro de usuario, jobs, etc). Podremos crear nuestras combinaciones
críticas de autorizaciones para ejecutar el informe con esa variante y el
informe nos devuelva los usuarios que tienen en sus autorizaciones esa
combinación de autorizaciones (en forma de semáforos con colores según la
criticidad que otorgamos a cada tipo de
autorización).
 Roles –> Roles por criterios de selección complejos: es la

transacción “principal” para obtener información de los roles. Podemos
buscar los roles por nombre, por usuario a los que están asignados, por
transacciones incluidas en el menú del Rol, por valores en los campos de los
objetos de autorización, por perfiles de autorización asignados al rol, etc. Nos
va a permitir localizar por casi cualquier criterio un
rol.
Se suele utilizar para localizar roles que incluyen una determinada

autorización. Por ejemplo, si queremos localizar en que roles esta el objeto de
autorización F_KNA1_AEN, lo indicaremos en la parte sección “Selección según
valores de
autorización”.
Además, al indicar el objeto de autorización, a continuación nos aparecen los

campos de autorización que lleva asociados (podremos indicar también valores a
buscar en el contenido de estos campos o con “*” la autorización global a todos
los posibles valores). Al ejecutar el informe, se nos devolverá la lista de roles que
incluyen el objeto (con los valores en los campos que coincidan si los hubiéramos
incluido).
 Transacciones –> Transacciones ejecutables: nos permite analizar las

transacciones que puede ejecutar un usuario con sus autorizaciones actuales,
las transacciones que se pueden ejecutar con un rol determinado, etc. Es un
mecanismo rápido para ver que puede ejecutar un usuario o un role si entrar
al mantenimiento de
roles.
 Comparaciones –> De usuarios: nos permite comparar los objetos de

autorización asignados a dos usuarios. Muy útil para cuando tenemos un
usuario al que le faltan autorizaciones y queremos, en comparación con otro
que si tiene los accesos, saber donde radican las
diferencias.
Entrando al detalle podemos ver incluso los valores de los campos de autorización
y desde que perfil de autorización se están heredando al usuario (como vemos en
la imagen a continuación). Tener en cuenta que en el detalle se muestra los
perfiles de autorización asociados al Rol (lo que se indica como
autorización).
 Comparaciones –> De roles: similar al anterior, en este caso nos permite

comparar las autorizaciones de dos roles, objeto por objeto. Es una forma
sencilla de comparar que objetos están en un rol y no en el otro. Igualmente,
entrando al detalle podemos ver los valores de los campos de
autorización.
 Referencia de utilización –> Roles –> En usuarios: nos permite

visualizar los usuarios que están asignados a los
roles.
Pulsando el botón “ROLES” podemos ver de forma detallada toda la asignación

de roles al usuario, con información detallada si el rol es simple o compuesto, si
la asignación es directa (al usuario) o indirecta a través del módulo de
organización de Sap, fechas de validez,
etc.
Pulsando el botón “PERFILES” podemos ver cada uno de los perfiles asociados a
los usuarios que cumplen los criterios de selección del report.
En la proxima entrada del Blog, y para concluir el tema de autorizaciones,

veremos la forma de crear nuestras propias variantes para analisis de
autorizaciones críticas. Nos puede ser útil, en instalaciones muy grandes y con
muchos usuarios, para evitar que nunca se den determinadas combinaciones de
autorizaciones y para facilitar la labor en Auditorias de Seguridad (por mi
experiencia muchas auditorias contables ya incluyen incluso auditorias de
usuarios en Sap).
Truco 56.Costes indirectos planificados en compras
que no afectan a la cuenta de existencias.
3 Votes
Este es un tema sobre el que he recibido múltiples consultas en el blog. En la

configuración estándar de las clases de condición para los costes
indirectos planificados de adquisición en los procesos de compra del
Modulo MM (por ejemplo, las condiciones para gastos de transporte
como FRA1, FRA2, FRB1, FRB1, FRC1, FRC2; gastos de aduana, etc),
estos costes se añaden como más valor en la cuenta de existencias de
los materiales.
Esto esta bien, pues nos permite incluir en la valoración de los materiales aquellos
elementos que no son solamente el precio de la compra, y podemos incluir otros
importes provenientes de gastos de transporte, tasas, aduanas, gastos de seguros,
etc.
Pero en algunos tipos de negocio, todos estos costes no se han de

considerar como valor de las existencias (debido a que los gastos
serán reembolsables, por temas legales específicos de algún país o
por criterios contables). En este caso, estos gastos tendrán que ser
contabilizados en una cuenta contable diferente para poder realizar otro tipo de
tratamiento.
Para solucionar este problema, hemos de crear nuevas clases de condición,
modificando los parámetros de control de ellas para obtener el comportamiento
deseado del sistema. Los pasos son los siguientes:
1. Crear una nueva clase de condición, como copia de las estándar (por
ejemplo FRA1, FRB1, FRC1, etc), desde la transacción M/06 o ruta de customizing
Gestión de materiales –> Compras –> Condiciones –> Fijar determinación del
precio –> Fijar clases de condición –> Definir clase de condición.
Importante: indicar en tipo de condición el valor blanco y y en el signo

el valor X Negativo.
2. Creación de una nueva operación para la determinación de
cuentas: desde la vista V_T687, aplicación “M” Compras (transacción SM31) o
bien desde la ruta Gestión de materiales –> Compras –> Condiciones –> Fijar
determinación del precio –> Fijar clave de operación –> Clave de operación
(también accesible desde la transacción OLME).
3. Asignar la nueva clase de condición al esquema de cálculo: con la

transacción M/08 o la ruta de customizing Gestión de materiales –> Compras –
> Condiciones –> Fijar determinación del precio –> Fijar esquema de cálculo. La
incluiremos en la misma sección del esquema de cálculo
que utilicemos donde están el resto de condiciones de costes
indirectos planificados (fletes).
Importante: en la clave de operación de la clase de condición

(columna Delim), asignar la nueva operación creada en el paso
anterior (en este caso, la ZR1).
4. Configuración de la determinación de cuentas para la nueva
operación: con la transacción OBYC, realizaremos la asignación de cuentas para
la nueva clave de operación. Aquí indicaremos la cuenta contable diferente donde
queremos llevar los gastos de transporte.
Importante: antes de indicar las cuentas, configurar las normas (según

los criterios que queramos utilizar para la determinación de la cuenta: agrupador
de áreas de valoración, categorias de valoracion, D/H, etc). Igualmente,
definir las claves de contabilización que se utilizarán para los
asientos (40/50).
En principio, con esta configuración todo esta preparado para que el sistema se
comporte de la forma deseada por nosotros. Vamos a ver un ejemplo de un pedido
de compras utilizando esta clase de condición para verificar que la
parametrización ha sido correcta.
En el nuevo pedido utilizamos la clase de condición creada (ZFR1) y la clase de

condición original (FRA1). Con la combinación de las dos vamos a conseguir
realizar el juego contable deseado.
NOTA: SE HAN DE INTRODUCIR LAS DOS CONDICIONES (HACER

EL JUEGO CON LAS DOS) PARA CONSEGUIR EL RESULTADO
DESEADO. NO BASTA CON UTILIZAR SOLO LA CLASE DE
CONDICION CREADA. ESTO ES TANTO VALIDO PARA COMPRAS A
STOCK COMO PARA COMPRAS IMPUTADAS. EN ESTE ULTIMO
CASO, EL FLETE SE LLEVARA A OTRA CUENTA DIFERENTE DE LA
DEL GASTO DE MATERIAL.
A continuación, realizamos la entrada de mercancía del pedido. Podemos
observar el apunte contable que se ha generado en el sistema al realizar la EM con
la transacción MIGO:
Podemos observar que en la cuenta de existencias (cuenta 301000) no
hay ningún reflejo del gasto de transporte. Por otro lado, en la cuenta que
hemos parametrizado para la clave de operación ZR1, nos aparece el importe del
gasto (en rojo). En la parte marcada en naranja en el asiento, podemos ver las
cuentas de la clave de operación FRE (generadas por el juego de las clases de
condición FRA1 y ZFR1) se compensan entre si. Por otro lado, la cuenta de
facturas pendientes de recibir para los portes refleja el importe de estos.
Cuando recibamos la factura, el asiento generado será el siguiente (en este caso
hemos supuesto que el proveedor del transporte es el mismo que el de
la mercancía). En caso contrario, haremos la contabilización en dos movimientos
pero con el mismo resultado contable. Su aspecto es:
Se compensan las cuentas de EM/RM de la mercancía y del transporte, y se lleva
la deuda a la cuenta del proveedor.
Conclusión.
Con este método hemos conseguido nuestro propósito de separar los costes
indirectos planificados de adquisición de la valoración del material,
contabilizándolos en una cuenta contable diferente, separándolo del importe de
las cuentas de existencias del material.
La alternativa no es un método directo y nos obliga a indicar las dos clases de
condición en el pedido (siempre habrá que hacer ese juego). Pero el resultado
contable es el deseado y nos puede valer para aquellas excepciones donde tenga
que realizarse esta separación.
Bibliografía: entrada original publicada por Raja Ramasamy en el SCN de

Sap http://wiki.sdn.sap.com/wiki/display/ERPLO/Posting+planned+delivery+
cost+to+Non-inventory+account
Truco 60. Protección de campos en el Maestro de
Materiales (Fijación).
6 Votes
En un truco anterior hablamos de la posibilidad de proteger la modificación de

determinados campos en el maestros de proveedores y clientes (ver
entrada aquí). Si nos encontramos con la misma necesidad cuando hablamos del
maestro de materiales (MM02) tenemos disponible la funcionalidad de
“Fijación”.
Básicamente, la funcionalidad consiste en definir un conjunto de campos

del maestro de materiales susceptibles de fijación. Cuando el usuario
autorizado realiza la fijación en un código de material concreto, los
campos incluidos en la parametrización quedan bloqueados
(grisados) y ningún usuario podrá realizar modificaciones sobre ellos (aunque
si en el resto de campos del maestro de materiales).
Para la definición de los campos relevantes para fijación, accederemos a
la transacción OMSFIX o bien a través de la ruta de
parametrización Logística en general –> Maestro de Materiales –> Selección de
Campos –> Especificar campos relevantes para fijación.
Los
campos los habremos previamente localizado en la transacción MM02, con la
opción habitual (F1 situados encima del campo, botón Información Técnica). Los
campos que queramos incluir como “fijables” los marcaremos en la
parametrización.
A continuación, accederemos a la modificación de un material cualquiera que
queramos proteger, utilizando la transacción MM02. Al pulsar el botón de
“Fijar material”, como podéis ver en la imagen siguiente,
nos aparecerá un popup con la lista de campos que se fijaran
y protegerán en el material.
Aceptaremos y grabaremos las modificaciones en el material, que quedará fijado.
El sistema nos avisa de las repercusiones de fijar un material (y aunque avisa que
el cambio es irreversible, no es cierto, si podremos eliminar a posteriori la
fijación).
Si volvemos a entrar a modificar el mismo material, podremos ver que los
campos indicados en la parametrización aparecen en gris y no son
modificables, lo que nos permitirá proteger determinados campos críticos o
cuyo mantenimiento solo deba quedar en manos de usuarios muy concretos.
Ademas, al lado de la descripción del material aparece el icono del Candado que
nos indica que un material se encuentra Fijado.
IMPORTANTE: para poder crear o eliminar la fijación de un material, deberemos
de disponer del objeto de autorización M_MATE_MAF. En este objeto
tenemos la posibilidad de indicar dos códigos de actividad para los que pueden
estar autorizados los usuarios:
 16 Ejecutar: nos permite realizar la fijación de campos en un material.

 51 Inicializar: nos permite eliminar la fijación de campos en un material.
Teniendo en cuenta estas dos actividades, podríamos montar un escenario en
el que la mayoría de usuarios no tendrían en su perfil de
autorizaciones este objeto, de forma que ellos nunca podría
fijar/desfijar un material para modificaciones.
Por otro lado, los “administradores” o “key-users” del maestro de
materiales si tendrían la autorización. Ellos indicarían en los campos
críticos los valores correctos y a continuación fijarían los materiales
para que nadie pudiera modificar esos valores. Esos valores quedarían
protegidos hasta que ellos mismos eliminasen la fijación para indicar otros
valores según las necesidades concretas y volver a fijar el material posteriormente
para volver a protegerlo.
Una funcionalidad sencilla de implementar, y que nos puede dar juego para
determinados requerimientos en un cliente o proyecto. Espero que os sea de
utilidad.
Truco 62. Textos de cabecera predefinidos en el
registro de facturas de MM (Miro).
2 Votes
Cuando estamos trabajando con la transacción MIRO, en el registro de facturas

desde MM, es habitual incluir, en la contabilización de estas, textos
informativos referentes al concepto de la factura, incluyendo
información del periodo, tipo de gasto, departamento, etc.
Al contabilizar la factura, el texto introducido se registra en el documento

de Finanzas, en la posición del asiento de FI correspondiente a la cuenta del
acreedor/proveedor, en el campo Texto.
Luego este texto lo tenemos disponible en el informe de partidas abiertas de
proveedores, utilizando por ejemplo la transacción FBL1N. Teniendo
ahí esta información, podemos realizar búsquedas o totalizaciones usando esa
información del “concepto” al que se asocia la factura registrada.
Para facilitar el trabajo del usuario, así como para “normalizar” los valores que
podemos introducir en este campo al registrar las facturas, tenemos la posibilidad
de parametrizar una lista de valores que podremos usar en este
campo (además de la lista de valores, siempre tendremos la opción de introducir
texto libre).
La parametrización asociada se encuentra en la ruta de customizing Gestión
financiera –> Contabilidad de deudores y acreedores –> Operac.
Contables –> Recepción de facturas /Entrada de Abonos –> Realizar
y verificar parametrizaciones para documento –> Almacenar textos
para posiciones documento. Aquí definiremos los valores, asignándoles una
clave identificadora y un texto asociado.
Con la opción de parametrización “Visual.control” sin marcar,el texto aparecerá
en el campo con el formato =Z001 al seleccionarlo, apareciendo posteriormente
el texto propuesto.
En la definición de los textos podemos incluir variables que se sustituirán
en el momento de la contabilización. Las opciones disponibles son las
siguientes:
 &BLD Fecha del documento.
 &BUD Fecha de contabilización.
 &ZFB Fecha base para plazo de pago.
 $BUP Periodo contable.
 $XBL Nº documento de referencia.
Esto nos permite añadir automáticamente información del documento
generado sin necesidad de escribirla manualmente.
Al entrar un documento, podremos indicar la variable de texto precedida del
signo ‘=’ (=XXXX) o bien utilizar el matchcode para seleccionar el texto deseado.
Nota: los textos también estarán disponibles para su uso en las
transacciones de registro de facturas desde FI, tanto en la parte de
Deudores (FB70 Facturas, FB75 Abonos), como para Acreedores (FB60 Facturas,
FB65 Abonos).
Este truco forma parte del contenido del Curso MM Gestión de Materiales que
estamos impartiendo en la actualidad, en la lección correspondiente al registro
de Facturas. Espero que os sea de utilidad.
Truco 63. Autorizacion de funciones en compras con el
parametro EFB (OMET).
12 Votes
En una entrada antigua del blog hicimos referencia a algunos trucos que
podíamos utilizar en el módulo MM para personalizar, mediante parámetros de
usuario, el comportamiento del sistema.
Hoy vamos a ampliar esa información y nos vamos a centrar en el parametro
EFB, el cual se configura a través de la transacción OMET y nos
permite determinar autorizaciones por usuario para la realización o no
de determinadas funciones en los procesos de compra.
La configuración es bien sencilla. En primer lugar, se define con la transacción
OMET una etiqueta con sus correspondientes funciones autorizadas (que
veremos en detalle a continuación).
En segundo lugar, para los usuarios que queremos que se apliquen dichas
autorizaciones, accederemos a la transacción SU3 e indicaremos en sus
parámetros el valor EFB con la etiqueta definida en la configuración. A partir de
ese momento, la configuración de autorizaciones será relevante para el
usuario y el sistema solo le permitirá realizar las funciones a las que haya sido
autorizado.
Nota: si el parametro EFB no ha sido asignado, no habrá ninguna
restricción para el usuario. La asignación también se podrá realizar con la
SU01 o de forma masiva con la SU10.
Las acciones a las que podemos autorizar o no al usuario mediante esta
configuración son las siguientes:
 Opción “Visualizar condiciones”: permite que el usuario tenga visible la
pestaña Condiciones. Si la opción esta desmarcada, dicha pestaña
desaparecerá (nos permite permitir a determinados usuarios consultar
documentos de compras sin ver el detalle de los datos de condiciones de
precio).
 Opción “Indicar condiciones”: permite que el usuario pueda introducir
condición de precio en los documentos, así como introducir clase de
condiciones adicional (por ejemplo, gastos de transporte, descuentos, etc) en
los documentos de compra. Si la opción esta desmarcada, el usuario no tendrá
acceso a realizar estas funciones (la pestaña de condiciones aparecerá a nivel
de posición, pero no podrá indicar ni modificar ningún valor).
 Opción “Sin Material”: nos permite crear posiciones en los documentos de
compra sin indicar un material (solo el texto de la descripción). Si la opción
no esta marcada, el usuario recibirá un mensaje de error como el que vemos
en la imagen siguiente.
 Opción “Transfer.precio pedido”: al crear una solicitud de pedido, en la

pestaña Valoración a nivel de posición tenemos disponible la opción para
configurar como queremos que se traspase el valor que indicamos en la solped
al pedido (sin traspaso, como precio bruto o como precio neto). Esta opción
aparecerá disponible si tenemos marcado el parámetro “Transfer precio
pedido”. Si se desmarca, la opción no será visible en la ME51N/ME52N.
 Opciones “SelecCpo” y “CtrlSelCampLib”: podemos indicar formatos
de imagen para los documentos de compra o para las solicitudes de
pedido. En estos formatos de imagen personalizaremos la
configuración de los campos para el usuario (por ejemplo,
determinados campos obligatorios, opcionales, solo visibles u
ocultos). Con esta opción podremos personalizar, solo para determinados
usuarios, el comportamiento de las transacciones en lo referente a los campos
en las transacciones. Esta opción nos puede dar mucha potencia.
En la sección “Objetos de referencia posibles” indicamos los objetos de
referencia que se pueden utilizar cuando estemos creando un pedido
de compra. Por ejemplo, sino queremos que se pueda crear un pedido sin
referencia a otro documento (Solped, Pedido Abierto, etc), desmarcaremos este
flag para no permitir la función.
Las opciones de referencia disponibles, ademas de sin referencia, son: Pedido
Abierto (incluyendo según el tipo de este, por Cantidad o Valor), Solicitud de
Pedido, Pedido, Petición de Oferta sin Oferta, Oferta, Registro Info sin Oferta
(que no se haya generado desde una oferta).
En la sección “Asignación manual fuentes de aprovisionamiento”

podemos indicar que fuentes de aprovisionamiento se pueden indicar
de forma manualcuando estemos creando una solicitud de pedido.
Con todas estas opciones podemos modificar de forma relevante la forma de
trabajar del usuario con los documentos de compra, y seguramente poder cubrir
algunos requerimientos que pueden surgir en un proyecto de implantación o
mantenimiento del modulo MM de Sap.
Para terminar, os dejo el vídeo con los pasos de la configuración, con el que
estrenamos una nueva forma de compartir conocimiento en el blog. Espero que
os sea de utilidad.
Truco 65. Formas de encontrar la transacción que se
usa en la parametrización de SAP.
Publicado el 11 julio, 2014por Roberto Espinosa
6 Votes
Hoy nos vamos a un truco un poco más técnico que podemos utilizar
para averiguar cual es la transacción asociada a una parametrización
dentro de la SPRO. A todos nos pica la curiosidad de saber cual es la
transacción que usa para un determinado paso del customizing (muchas veces
para tenerla localizada y acceder de forma mucho más rapida a ella, sin la tediosa
navegacion en el arbol del custo, en la que no siempre recordamos la opción para
llegar a un punto concreto).
Esta tarea de averiguar la transacción no es siempre sencilla ni inmediata. Los
siguientes pasos nos pueden ayudar:
1) Visualizar la transacción en la barra de estado del sapgui: en la mayoría de

ocasiones nos mostrará la transacción SPRO (nuestro gozo en un pozo).
2) Utilizando la opción de menu Sistema –> Status: nos devuelve
información similar al punto 1. Tambien podemos ver el programa que se utiliza
para este punto de parametrización, que nos podrá servir para encontrar la
transacción como explicaremos a continuación.
3) Dentro del árbol de parametrización de la SPRO, seleccionando la opción

de menú Información adicional –> Info adicional –> Visualizar clave
–> Actividad IMG.
A nivel de cada uno de los pasos de parametrización nos aparecerá un texto con
información adicional. En algunas ocasiones, los 4 últimos dígitos de ese
valor nos indicarán la transacción con la que se accede a dicha
parametrización (por desgracia, no siempre, y no hay una regla clara).
4) Localizando la transacción a través del programa asociado: nos iremos a
la transacción SE16N, indicando la tabla TSTC, que es donde se registran
los datos de las transacciones en el sistema SAP.
En el campo Programa indicaremos el nombre del programa que habremos

localizado siguiendo las instrucciones del punto 1 o 2. Si tenemos suerte en los
resultados de la búsqueda nos aparecerá el código de la transacción.
Pero, por desgracia, esto no siempre funciona.
5) Otra alternativa sería, desde el arbol de parametrización, seleccionar la
opción que queremos investigar y pulsando el botón derecho del
ratón, elegir la opción “Visualizar información técnica”:
Nos aparecerá una ventana con información adicional. En la pestaña

“Obj.actualiz” podremos ver la transacción asociada (muchas veces la transacción
es la SM30, que utiliza una vista de actualización sobre una tabla).
En mi ejemplo, la creación de las estrategias de liberación de pedidos, la podemos
llamar desde la transacción SM30, con la vista VV_T16FS_2. En otras ocasiones
nos aparecerá directamente la transacción que llama a la parametrización.
6) Si no hemos sido capaces de localizar todavía la transacción, nos queda una

última alternativa que casi siempre dará resultado. Con el ID del
objeto de parametrización que podemos obtener siguiendo las instrucciones
del punto 5.
A continuación, con la transacción SE16N y la tabla CUS_IMGACH,
buscaremos con el código de Actividad IMG que hemos localizado.
Si todo esta bien, obtendremos como resultado un registro que nos indicará cual
es la transacción que utiliza Sap para llamar a ese punto de parametrización.
Nos costo, pero al final lo conseguimos. Espero os parezca interesante.
Truco 67. Valores por defecto al crear Proveedores (o
Clientes) en SAP.
Publicado el 26 julio, 2014por Roberto Espinosa
3 Votes
Un requerimiento muy habitual en cualquier proyecto de implantación o de

mantenimiento de Sap es la posibilidad de inicializar con valores por
defecto determinados campos en el maestro de Proveedores o de
Clientes en el momento de crearlos. Además, es posible que estos valores
tengan dependencia de otros campos del maestro que es posible controlar (por
ejemplo, según la Sociedad, Organización de Compras, Organización de Ventas,
Grupo de Cuentas, etc).
Si lo que necesitamos hacer es muy genérico, con valores por defecto sin ninguna
lógica de control, podríamos utilizar las variantes de transacción para
inicializar valores por defecto en determinados campos de las
pantallas de las transacciones. Podéis ver las siguientes entradas que hablan
sobre ello y la forma de crear variantes de transacción.
 http://sapinsider.wispubs.com/Assets/Blogs/2011/July/Setting-Up-
Default-Field-Values-for-the-Vendor-and-Customer-Master
 https://saptricks.wordpress.com/2011/05/22/truco-13-transacciones-
personalizadas-con-las-variantes-de-transaccion-shdo/
Pero realmente las variantes de transacción son difíciles de configurar y poco
flexibles para luego hacer cambios. Por tanto, si ademas de eso tenéis pensado
incluir una lógica inteligente en esta asignación inicial de valores por defecto, yo
os recomiendo utilizar la adaptación del sistema que Sap nos habilita para este
caso, en concreto:
 BADI: VENDOR_ADD_DATA
 Metodos:
 PRESET_VALUES_CCODE: para inicializar valores en la información de
sociedad (tabla LFB1).
 PRESET_VALUES_PORG: para inicializar valores en los datos de
organización de compras (tabla LFM1).
 PRESET_VALUES_PORG_ALTERNATIVE: para inicializar valores en
los datos de organización de compras, para los datos divergentes por
centro/surtido de proveedor (tabla LFM2).
Podéis consultar las definiciones de la BADI con la transacción SE18, así como la
documentación asociada a cada método.
El procedimiento para implementar la BADI en nuestro sistema sería el siguiente:
1. Creación de la implementación propia de la BADI con la transacción SE19.

2. Programación del código necesario en el Método.
3. Validación y pruebas.
Creación de la implementación propia de la BADI
con la transacción SE19.
Desde la transacción SE19 creamos la implementación de la BADI
VENDOR_ADD_DATA, con el nombre oportuno siguiendo las
recomendaciones de Sap en cuanto a nomenclatura.
A continuación indicaremos el nombre de la implementación de la Badi, asi
como la clase asociada, enlazándola con la definición de Badi
VENDOR_ADD_DATA.
El sistema nos pedirá el paquete donde queremos incluir los objetos creados, asi
como la correspondiente orden de transporte para luego poder pasar las
especificaciones a nuestro sistema de productivo.
Programación del código necesario en el Método.

A continuación desde la misma SE19 accederemos a la implementación para
acceder al código Abap del método PRESET_VALUES_CCODE, tal y como
observamos en la imagen.
En mi ejemplo voy a inicializar valores incluidos en los datos de
Sociedad del proveedor. Si quisierais actualizar los datos de compras
usaríamos el método PRESET_VALUES_PORG en lugar del indicado.
En el código incluimos la lógica de proceso de la inicialización, teniendo en cuenta

que:
 La variable I_ACTIVITY la actividad que estamos realizando: si
estamos en la creación de un proveedor (valor H) o en la modificación (valor
V).
 La estructura I_LFA1 incluye toda la información de los datos generales
del proveedor (no modificable).
 La estructura E_LFB1 incluye los datos de sociedad del proveedor
(modificable).
Nota: el método se ejecuta en el evento PBO (Process Before Output) en todas las
pantallas donde se encuentran los datos de sociedad.
Validación y pruebas.
A continuación accedemos a las transacciones de creación de
proveedores para verificar el correcto funcionamiento del código abap incluido
(en este caso, al estar inicializando los datos de sociedad, podriamos utilizar la
XK01 o FK01).
En nuestro ejemplo, procedemos a crear un proveedor de un grupo de cuentas
0001. Al llegar a los datos de sociedad, podemos observar como los valores
deseados son inicializados según la lógica descrita en el método de la Badi.
De esta manera, nos aseguramos que determinados campos relevantes se

inicialicen con determinados valores al crear los proveedores, siguiendo si es
necesario una lógica relevante según los valores de las unidades organizativas o
los valores de otros campos de referencia.
NOTA: si tuviéramos el mismo requerimiento, pero para el maestro de

clientes, podríamos utilizar, con la misma lógica para su configuración:
 BADI: FM_CUSTOMER_ADD_DATA
 Método: PRESET_VALUES_AREA
Truco 70. Copia de condiciones de precio en MM o SD.
5 Votes
En ocasiones, nos encontramos con la necesidad de hacer una copia masiva

de condiciones de precio (precios, descuentos, recargos, portes, etc) y no se
nos ocurre otra forma que preparar un fichero de carga y mediante un legacy
(LSMW), Batch Input o un desarrollo a medida realizar la carga de los datos
proporcionados por el usuario.
Existe también la alternativa de realizar una copia con modelo utilizando el
estándar de Sap con un mínima configuración (parametrización y en algunos
casos la preparación de un sencillo programa de selección de los registros a crear).
La alternativa la tenemos disponible tanto en SD (transacciones VK31, VK34,

VK11 ,VK14) o en MM (transacciones MEK1 o MEK4).
Nota Importante: realizar la copia utilizando este procedimiento

pivota en torno a uno de los valores de los registros de condición
existentes. Por ejemplo, si tenemos un descuento asociado a un proveedor,
podremos copiar a N proveedores pivotando sobre el campo proveedor. Pero solo
podremos pivotar sobre un campo a la vez.
Por ejemplo, podremos igualmente copiar los registros de un material de un
centro a otro.
En nuestro ejemplo, vamos a configurar la posibilidad de copiar unos registros de

condición que hemos creado en nuestro sistema (clase de condición ZRL1
%Descuento proveedor), replicando los registros existentes en un proveedor a un
conjunto de proveedores seleccionados en el momento de la copia.
Parametrización del control de copia.

Para la parte de MM, en la ruta Gestión de materiales –> Compras –>
Condiciones –> Fijar determinación de precio –> Control de copia
para condiciones. Dispone de dos opciones de configuración:
 Regla de copia para clases de condición (vista V_T688K): en esta
configuración indicamos las clases de condición origen/destino para las que
vamos a poder hacer copia.
 Reglas de copia para condiciones (vista V_T688): en esta
parametrización indicamos, para la tabla de condiciones en la que tendremos
definidos los registros de condición que vayamos a copiar, el campo sobre el
cual va a pivotar la copia.
Puede ser necesario revisar la configuración de las clases de condiciones (vista

V_T685A) y su secuencia de acceso para obtener la tabla de condiciones que se
este utilizando en el sistema para la clase de condición que vayamos a copiar.
En la sección de configuración Control de copia se indica el programa

que nos permitirá hacer la selección de los registros destino (en nuestro
caso, la lista de proveedores a los que copiar la condición) para los que realiza la
copia de las condiciones modelo. Existe una lista de programa estandar con los
criterios mas habituales, aunque podremos crear nuestro propio programa Z
tomando como modelo uno existente y adaptarlo a nuestro criterio de copia.
Aquí también configuramos si te tomará la fecha de los registros de
condición existentes como modelo y si la regla de copia por defecto es
la que estemos configurando.
Si estuviéramos en SD, la configuración se realizaría desde la ruta Comercial –>
Funciones basicas –> Determinación de precio –> Control de copia para
condiciones. Exactamente con la misma filosofía de funcionamiento.
Operativa de copia.
Una vez realizada la parametrización, accederemos a la transacción MEK4 e
indicaremos la clase de condición a copiar y la Combinación de claves
de la secuencia de acceso asociada a la condición (determinará la tabla de
condición utilizada, que deberá de coincidir con la que hayamos configurado en
el customizing).
Realizaremos a continuación la selección de los registros de condición que

vayamos a utilizar como modelo en la copia.
Una vez presentando la lista de registros, accederemos a la utilidad de
copia pulsando los botones Copiar o Copiar con selección de regla (tal
y como vemos en la imagen siguiente).
El sistema nos llevará al programa de selección de los registros

destino que hayamos indicado en la parametrización de las Reglas de Copia para
Condiciones. Es este caso, indicaremos el proveedor origen de las condiciones y
los proveedores destino (si lo dejamos en blanco no ofrecerá toda la lista de
proveedores).
Tras indicar los criterios de selección, el sistema nos mostrará una lista de los
proveedores destino para la copia, donde podremos seleccionar los valores que
realmente queremos procesar.
En el último paso, el sistema nos mostrará la propuesta de registros que
van a ser creados. Podremos tener disponibles varias vistas para visualizar los
registros a crear (en mi ejemplo, por periodos de validez y por importe). Estas
vistas se parametrizan en el customizing de Indice de condiciones, opciones
Definir Resumenes y Asignar resumenes.
Desde este lugar podremos seguir añadiendo registros a crear, pues están
disponibles los botones Copiar y Copiar con Sel.regla para afinar en la lista de
valores a crear e incluir nuevos valores.
También tenemos disponibles los botones “Modificar Fecha” y “Modificar
Importe” para realizar una actualización masiva de esos valores en el caso de que
fuera necesario.
Finalmente grabaremos y se realizara la creación de los registros de

condición. Con la transacción ME3K podremos consultar los registros creados
y verificar que la creación se ha realizado correctamente:
Como habéis podido comprobar, un método sencillo para poder realizar una
replicación masiva de registros de condiciones con una configuración muy
sencilla. Con la única limitación de poder pivotar sobre un único valor,
aunque nos puede ser muy útil en determinadas situaciones donde
hay que realizar un copiado rápido de condiciones o en aquellos casos
donde se producen cambios organizativos que requieren actualizaciones masivas
en los registros de condición.
Truco 71. Exclusión de condiciones de precio
en MM/SD.
2 Votes
En ocasiones, en nuestro esquema de cálculo de condiciones (utilizado para el

cálculo del precio de compra en MM o del precio de venta en SD), podemos
tener diferentes clases de condición que deberían ser excluyentes
entre si. Por ejemplo, si tenemos un descuento X y un descuento Y a la vez en el
cálculo, uno de ellos no debería de ser aplicado. También podríamos utilizar la
funcionalidad para seleccionar las condiciones más favorables o menos
favorables dentro de unos grupos determinados.
Resumiendo, las opciones disponibles serían:
 selección de la clase de condición más/menos apropiada dentro de un grupo

de exclusión de condiciones.
 selección del registro de condición más/menos apropiado de una clase de
condición, en caso de que existan más registros de condición (p.ej., selección
entre diversos registros de condición de la clase de condición PR00).
 selección del más/menos apropiado de entre dos grupos de exclusión de
condiciones (en dicho caso se acumulan todas las clases de condición de
ambos grupos, comparándose las sumas).
 procedimiento exclusivo: si en el documento existe cualquier clase de
condición del primer grupo, todas las clases de condición contenidas en el
segundo grupo se fijan como inactivas.
La parametrización es muy sencilla de realizar, constando de 3 pasos. Vamos a
ver un ejemplo de un escenario en el que queremos que un conjunto de
condiciones de descuento, no se puedan aplicar nunca en el cálculo si existe otro/s
descuentos específicos.
Parametrización de la exclusión de condiciones.

Si estuviéramos en Ventas (SD), accederíamos por la ruta de customizing
Comercial –> Funciones Básicas –> Determinación de Precio –> Exclusión de
Condiciones –> Exclusión de Condiciones para Grupo de Condiciones.
Si estuviéramos en Compras (MM), accederíamos por la ruta Gestión de
Materiales –> Compras –> Condiciones –> Fijar determinación del Precio –>
Definir Exclusión de Condiciones.
La filosofía de configuración es exactamente igual, con los siguientes pasos:
Definición de los grupos de exclusión.

En primer lugar, creamos las etiquetas para los grupos de exclusión a los
que luego asignaremos las clases de condición deseadas. Lo realizaremos en la
opción “Definir grupos de exclusión de condiciones”.
Asignación de las clases de condición a los grupos de exclusión.

En la opción “Asignar clases de condición a grupos de exclusión”. Para los grupos
de exclusión de condiciones que vayamos a utilizar, indicamos la lista de clases
de condiciones involucradas (una o varias).
En mi caso, tengo un grupo para descuentos globales, donde he incluido la
condición de descuento por Material (K004). En el segundo grupo, he incluido la
condición Cliente/Material (K005).
La idea es evitar que se use un descuento por Material, si ya existe un descuento

Cliente/Material (que se supone es especifico para un cliente concreto, y más
restrictivo).
Configuración de la forma de excluir las condiciones asociadas al

esquema de cálculo.
En la opción “Actualizar exclusión de condición para esquema de cálculo”. Este
último paso es el más importante. En el, asociado al esquema de cálculo,
indicamos como queremos que sea el tratamiento de exclusión de condiciones y
los grupos de condiciones involucrados.
En mi ejemplo, en el esquema estándar de ventas (SD) llamado RVAA01, he

incluido una exclusión del tipo D (Exclusivo). De esta manera, el
sistema, cuando encuentra en el cálculo del precio una de las
condiciones incluidas en el Grupo 1, automáticamente se desactiva
cualquier condición existente del Grupo 2 (si las hubiera).
En nuestro ejemplo, si hay una condición del Grupo ZPR0 (clase de condición
K005 Descuento por Cliente/Material), las condiciones del Grupo ZPN0 (clase
de condición K004 Descuento por Material ) serán desactivadas en el cálculo del
precio.
Podemos ver con el ejemplo de un pedido de venta como aparecen las condiciones
y como son desactivadas en el caso de que se cumplan las condiciones.
Otras opciones de configuración.
Además del método excluyente, con el que hemos configurado nuestro ejemplo,
tenemos disponibles otros métodos de configuración, que podemos ver en la
imagen.
Estos otros métodos nos permitirían:
 A Mas favorable entre las clases de condiciones: solo se indica en este
caso un grupo de exclusión. De las diferente condiciones que se hayan definido
en el grupo, nos quedaremos con la más favorable.
 L Menos favorable entre las clases de condiciones: solo se indica en
este caso un grupo de exclusión. De las diferente condiciones que se hayan
definido en el grupo, nos quedaremos con la menos favorable.
 B Mas favorable dentro de la clase de condición: para el caso de que
existan varias condiciones de la misma clase de condición, se quedará con la
más favorable (para las clases de condición incluidas en el grupo).
 E Menos favorable dentro de la clase de condición: para el caso de que
existan varias condiciones de la misma clase de condición, se quedará con la
más favorable (para las clases de condición incluidas en el grupo).
 C Mas favorable entre los dos grupos de exclusión: en este caso, se
acumulan todas las condiciones de los dos grupos y se comparan entre sí,
quedándonos con el grupo que ofrezca condiciones más favorables.
 F Menos favorable entre los dos grupos de exclusión: en este caso, se
acumulan todas las condiciones de los dos grupos y se comparan entre sí,
quedándonos con el grupo que ofrezca condiciones menos favorables.
Como veis, es una funcionalidad sencilla de parametrizar y que nos puede
permitir manejar las diferentes situaciones en lo referente al cálculo del precio y
la gestión de casuísticas especiales (sin necesidad de recurrir todavía a las
condiciones en el esquema de cálculo, que conllevan programación).
Truco 72. Determinación automática del Indicador de
Impuesto (Iva) en pedidos de compra (MM).
7 Votes
Cuando creamos los pedidos de compras en SAP (transacción ME21N), podemos

introducir el Indicador de Impuestos (Iva) a nivel de cada una de las
posiciones del documento, en la pestaña Factura.
Esta información se utilizará posteriormente como valor de propuesta en el

registro de facturas de compras con la transacción MIRO o como base para el
cálculo de impuestos si estamos utilizando la Autofacturación.
La determinación del indicador de IVA en los pedidos de compras se

realiza normalmente a partir de la información existente en los
registros info, donde alimentamos los datos de condiciones a nivel de
Proveedor, Material y Organización Compras / Org.Compras-Centro. En los
registros info, ademas de indicar condiciones de precio, también se detallan
plazos de entrega habituales, cantidades de compras, normas de envio,
tratamiento de suministro incompleto o excedido, control de confirmación o el
indicador de Iva a utilizar en esta combinación Proveedor Material.
En ocasiones, nos puede interesar que la determinación del indicador
de IVA sea independiente de los registros Info. En ese caso, utilizaremos
el esquema de cálculo como herramienta para inicializar el valor del campo en los
posiciones del pedido. Si la determinación se realiza por el esquema de cálculo,
esta tendrá prioridad sobre el valor existente en el registro info (en el caso de que
se encuentren las condiciones oportunas).
Por ejemplo, si queremos determinar el indicador de Iva de una forma
general (por organización de compras), con excepciones por material
o por grupos de material o por el país del proveedor, sería una
solución el hacerlo usando el esquema de cálculo.
En mi caso concreto, he tenido que usar esta funcionalidad por los últimos
cambios legales para IVA que hay en España (nuevos supuestos de Inversión del
sujeto pasivo), donde la compra de determinados materiales de Informática,
Tablets, pasa a estar exento de Iva (realmente hay una contabilización doble de
iva soportado y repercutivo que da un saldo de Iva cero), lo que se llama Inversión
del Sujeto Pasivo.
Veamos los pasos a realizar para configurar esto en nuestro sistema.
Creación de las tablas de condición y secuencia de
acceso.
En primer lugar, tendremos que decidir con que criterios queremos
determinar los indicadores de impuestos. Por ejemplo, podremos
establecer un criterio general, por Organización de Compras, o criterios
dependientes del material (hay un indicador de tipo de impuesto que se puede
mantener en la vista de Compras del material; los valores de este campo se puede
definir en la vista de customizing V_TMKM1, tcode SM31), o dependientes del
pais donde compramos, etc.
En nuestro ejemplo, y para no complicar demasiado las diferentes casuísticas,

vamos a definir las tablas de condición por:
 905 OrgCompras/Material
 906 OrgCompras/Gpo.artíc
 907 OrgCompras
En mi caso no he incluido el país origen o destino de la mercancía (aspecto que
puede ser relevante en un ejemplo real). Por eso, tener en cuenta que ya tenemos
tablas de condición estándar para la determinación de impuestos en compras. Por
ejemplo, la 80 (Indicador Impuesto del material en la vista de compras y Pais
receptor).
Todo será cuestión de analizar las tablas existentes y nuestros necesidades, y

decidir utilizar las estandar o crear nuestras tablas de condición personalizadas.
La creación de las tablas de condición se realiza con la transacción

M/03. Básicamente se indican los campos que utilizaremos para la creación de
los registros de condición (y que por tanto nos determinarán el tipo de impuesto
a aplicar).
Con la opción Vista Técnica se puede configurar la estructura de los campos en la
transacción de creación/modificación de los registros de condición (transacción
MEK1/MEK2).
A continuación, incluiremos las tablas definidas en la secuencia de
acceso (lista de tablas de condición) que vayamos a utilizar en la creación de
nuestra condición de impuestos. Esto lo realizaremos desde la ruta de
customizing Gestión de materiales –> Compras –> Condiciones –> Fijar
determinación del precio –> Fijar secuencia de acceso.
Es muy importante indicar las tablas en el orden correcto, pues será la

forma en que SAP ira a buscar los registros de condición. Las
condiciones más especificas (con mas nivel de detalle) deberán de ir primero, y
luego las de menos nivel de detalle (mas generales). Y siempre marcar el flag
Exclusivo para que el sistema no siga buscando cuando encuentre una condición.
Creación de la clase de condición ZIVA.
En el estándar ya tenemos definida una Clase de condición para el Iva (la MWST).
Pero vamos a crearnos una Z como copia de esta para no tocar la configuración
predefinida. Para ello, accederemos a la ruta Gestión de materiales –> Compras
–> Condiciones –> Fijar determinación del precio –> Fijar clase de condición.
Crearemos la clase de condición ZIVA, en la categoría de condición D

Impuestos y no procesable de forma manual. Importante indicar la
secuencia de acceso que hayamos creado previamente con las tablas de condición
oportunas.
Ajustes en el esquema de cálculo de compras.
El último paso de configuración consiste en incluir la nueva condición en el
esquema de cálculo que utilicemos para realizar la valoración de
nuestros pedidos de compra. Para ello, accederemos a la ruta Gestión de
materiales –> Compras –> Condiciones –> Fijar determinación del precio –>
Fijar esquema de cálculo.
Una vez localizado el esquema de cálculo que usemos en nuestro sistema,

incluiremos nuestra clase de condición en la sección de impuestos, y siempre
como una condición estadística (solo es informativa, no se va a realizar
ninguna contabilización con ella). Esto es así porque los impuestos los
introduciremos en el momento de registrar la factura.
Creación de registros de condición para la
determinación del impuesto.
La creación de los registros de condición la realizaremos con las transacciones
MEK1/MEK2/MEK3. Al crear los registros, el sistema nos pedirá la combinación
de claves a utilizar. Esto no es más que elegir entre las diferentes tablas de
condición existentes en la secuencia de acceso que hayamos asignado a la clase
de condición.
La secuencia de acceso determinará a que nivel de datos crearemos los registros
de condición. Para nuestro ejemplo, voy a crear el registro de condición a nivel de
Organización de Compras.
En el registro de condición indicaremos el porcentaje de

Impuesto (que tendrá que estar alineado con la configuración del indicador de
Iva en la tabla FTXP), el periodo de validez y el indicador de impuesto a
utilizar (S5 en mi ejemplo). Este indicador de impuesto será el que luego se
ofrecerá como propuesta en los datos del pedido.
Una vez concluida la parametrización, y dados de alta los registros de
condición, al crear los documentos de pedido, aparecerá la clase de
condición ZIVA en los datos de condición a nivel de la
posición (siempre que se encuentren valores en los registros de condición que
hagan que la posición del documento determine el impuesto).
Pero no solo eso, en la pestaña Factura se nos habrá inicializado el campo

“Ind.Impuestos” con el valor que informamos al crear el registro de condición del
impuesto.
Y tendremos la solución a la necesidad de determinar los indicadores de

impuestos por criterios generales en el sistema, sin necesidad de
tener que informar del dato en todos los registros info (teniendo en
cuenta que no necesariamente siempre vamos a contar con ellos).
Nota Importante: el indicador de impuesto determinado por el esquema de
cálculo tiene prioridad sobre el indicador de impuesto existente en el registro info
de condiciones (en caso de que exista este)
Truco 73. Personalizando el listado de documentos de
material (transacción MB51).
17 Votes
La transacción MB51 es una de las más útiles en la gestión de stocks, pues nos
permite realizar una análisis completo de los movimientos de mercancía
realizados en nuestro sistema.
Con el simple uso de la herramienta podemos ver los movimientos por clase de
movimiento, con valor, incluyendo información de los clientes o proveedores
implicados en el movimiento, las relaciones con otros documentos (pedido de
compra, pedido de venta, reservas), objetos de imputación utilizados, valoración
de los movimientos, etc.
Igualmente, podríamos visualizar información sobre el tipo de stock utilizado

(por ejemplo stocks especiales), si el movimiento es contra consumo o contra
stock (por ejemplo en una entrada de mercancía de pedido), los motivos del
movimiento o el usuario y fecha/hora en la que se realizo el movimiento. Desde
mi punto de vista, uno de los informes más completos y que me ha sacado de
apuros en más de una ocasión.
Una de las cosas menos conocidas de este informe es la posibilidad de
parametrizarlo y añadir, tanto en los criterios de selección como en la
lista de resultados, otros campos disponibles en las tablas de
documentos de material(tablas MKPF y MSEG).
Para hacer esto, accederemos a la ruta de customizing Gestión de materiales –>
Gestión de Stocks e Inventario –> Reporting –> Especificar selección de campos
p. lista documentos material.
Se nos mostrarán los campos asignados actualmente al informe, con un flag en la

primera columna si el campo se utiliza en los criterios de selección y un flag en la
segunda columna si se utiliza en los resultados del informe.
Aparte de modificar la configuración de los campos existentes (por ejemplo,

modificar un campo ya existente en los resultados y ponerlo como criterio de
selección), podremos añadir otros campos “ocultos” para que aparezcan tanto en
los criterios de selección como en los resultados.
Están disponibles prácticamente todos los campos de las tablas MKPF y MSEG.
Y una recomendación, añadir determinados campos como criterios de selección
puede dar lugar a consultas muy lentas debido al tamaño que suelen tener las
tablas que almacenan los documentos de material.
Truco 74. Informe de Stock a una fecha (MB5B). Grupos
de clases de movimiento.
3 Votes
Los informes de stock clásicos de SAP (transacciones MB52, MMBE, etc), nos
ofrecen la foto del stock en el momento actual. Cuando necesitamos analizar el
stock en una fecha pasada, tenemos disponibles dos opciones por el estándar:
Si lo que queremos ver es el stock y su valor a final de un periodo (por
ejemplo, a final del ejercicio, al final del periodo anterior, etc), podemos
recurrir a los informes del SIL (Sistema Información de Logística). El
sistema info guarda información de los stocks por periodo, y nos permite acceder
a la foto de al final de cada periodo. Por ejemplo, las transacciones MC.9 Stock
por material, MC.1 Stock por centro, MC.5 Stock por almacén, MC.L Stock por
grupo de material o MC.T Stock por tipo de material.
Al ejecutar las transacciones, tenemos disponible la opción de seleccionar el
periodo de referencia. El periodo final sera la referencia para obtener el stock.
Al ejecutar el informe, tendremos el stock que había en ese momento del

tiempo. Ademas, los sistemas info tienen muchísimas funcionalidades
disponibles como permitir el guardado de fotos de los datos (que luego se pueden
recuperar en un momento posterior), navegación en las diferentes características
disponibles (material, centro, almacén, grupo de articulo, tipo de material,
categoría de valoración, periodo, etc), agregar ratios al informe, comparación de
dos ratios, comparación de periodos, funciones estadísticas, etc. Ademas,
tenemos disponibles más de 70 ratios de análisis, como la fecha de ultima
entrada, ultima salida, ultimo movimiento, rotación, consumos, etc.
El sistema info esta disponible por estandar (es posible que haya que retocar algo
en la parametrización). Además, se pueden crear estructuras info
propias para registrar información adicional o con otra estructura temporal.
Si lo que necesitamos es analizar el stock existente en una fecha concreta,
fuera del final o principio de un periodo, podemos utilizar la
transacción MB5B. Esta transacción es una clásica para analizar la situación
de los stocks en un momento del pasado. Realiza un cálculo dinámico del stock
en el momento que indiquemos recorriendo los documentos de material (tablas
MKPF/MSEG).
Con esta transacción, podemos analizar el stock en una fecha (o periodo), de

forma que podemos obtener:
 Resumen de stocks: stock y valor en la fecha inicial indicada; stock y valor

en la fecha final indicada. Ademas, podemos ver el valor y cantidad de los
movimientos realizados en el periodo. De esta forma, podemos calcular la foto
en momentos concretos y realizar los análisis oportunos.
 Detalle de movimientos: el informe, seleccionando esta opción de

desglose, nos permite ademas ver los movimientos, material por material.
Partiendo de la fecha inicial, con el stock existente en el sistema, nos muestra
los movimientos que se han realizado hasta llegar al momento final del
periodo.
Ademas, la transacción tiene diferentes criterios para restringir los materiales a
visualizar, como podemos ver en la imagen.
Ahora es donde viene la funcionalidad que os quiero comentar. Muchas veces nos
piden que obtengamos la información de movimientos agrupada por tipos de
movimientos: entradas, salidas, consumos, desguaces. Esto se puede
solucionar con la transacción MB51, realizando totales, agrupaciones
por clase de movimiento, etc. También a veces se suelen realizar desarrollos
para este cometido.
Igualmente, en la MB5B tenemos disponible una opción interesante para
organizar los movimientos cuando usamos la transacción con detalle de
movimientos. En el customizing (ruta Gestión de materiales –> Gestión de stocks
e inventario –> Reporting –> Agrupar clases de movimiento para listas de
stocks), tenemos la opción de indicar una etiqueta de clasificación a las
diferentes clases de movimiento. Los valores se almacenan en la tabla de
customizing T156Q, y son un texto libre (4 caracteres), donde podemos indicar
cualquier valor.
Posteriormente, cuando utilizamos la MB5B con la opción de detalle de
movimientos, tenemos disponible la columna “Grupo clases de
movimientos” que lee esa parametrización y nos muestra la etiqueta
asignada a cada movimiento. Las clases de movimiento no clasificadas
muestran el valor REST (Resto).
Con la etiqueta podremos realizar ordenaciones, clasificación, filtrado,
subtotales y ver la información desde un punto de vista más lógico.
Lástima que la clasificación no este disponible en otros informes, como la MB51.
Truco 76. Ubicaciones informativas en gestión de
Stocks. Ampliando la MB52.
5 Votes
En ocasiones, necesitamos saber la ubicación de nuestros materiales en un

almacén clásico (MM), sin necesidad de utilizar el módulo WM. Este módulo si
nos permite trabajar con stock identificado en ubicaciones, aunque complicando
nuestros procesos logísticos con pasos adicionales (gestión de necesidades,
Ordenes de transporte para ubicar y desubicar la mercancía, etc).
Si estamos buscando un escenario sencillo y que nos de la funcionalidad mínima,

podemos utilizar las ubicaciones informativas que se pueden indicar en
el maestro de materiales. En la vista de Almacenamiento, a nivel de
Centro y Almacén, se puede indicar un valor alfanumérico que indica la
ubicación física del material en el almacén (campo MARD-LGPBE). Es un campo
de texto libre, sin lista de valores.
El valor informado aparece en el estándar en la transacción de consulta de
stocks por material (transacción MMBE), de forma que podemos ver en
cada almacén que ubicación se utiliza para almacenar el producto. Es algo
informativo, pero muy útil para saber donde debería de estar el stock.
Además, cuando estamos realizando los movimientos de mercancía en la
transacción MIGO, la ubicación también aparece en el momento de
indicar los valores para la operación de movimiento de stocks (en la imagen, un
ejemplo al realizar un traslado de almacén a almacén).
Incluso, si estamos realizado procesos de venta y gestionamos la entregas de

salida del material, el estándar también nos permite ver la ubicación del
material en el almacén de donde estamos sacando la mercancía para
entregar a nuestro cliente (transacción VL01N/VL02N).
En el momento de la recepción de mercancía (por ejemplo, en las compras),

también tendremos disponible la información de la ubicación (tanto si
trabajamos con entregas entrantes con la transacción VL31N o hacemos las
entradas directamente con la MIGO).
Solo echamos en falta la información en unos de los informes más importantes
en la gestión de stocks de MM, la transacción MB52. Para este informe, sería
conveniente realizar una ampliación y añadir una nueva columna que nos
mostrase la ubicación en cada uno de los almacenes donde hubiera stock del
material.
Nuestro amigo Eduardo M. Puricelli habla en su blog de como realizar la
ampliación, utilizando los Enhacements.
https://abapers.wordpress.com/2014/04/01/mb52-agregar-campo-en-alv/
En el caso de que no queráis realizar programación, siempre tendríamos la opción
de generar una query sencilla, utilizando las tablas MARA, MAKT, MARC y
MARD donde mostrar la información de stocks con la ubicación informativa.
Como habéis visto, una alternativa sencilla para gestionar ubicaciones en

nuestros stocks, con limitaciones, pero sin la complejidad de usar WM. Valido
para pequeños almacenes o situaciones en las que queremos una operativa
sencilla de movimientos
Truco 79. Aprobación de modificaciones en campos
sensibles del maestro de proveedores/clientes.
10 Votes
Hace ya algún tiempo hablamos de la posibilidad de proteger determinados

campos en el maestro de proveedores o clientes, de forma que solo los usuarios
con las autorizaciones oportunas (objeto de autorización F_KNA1_AEN para
clientes o F_LFA1_AEN para proveedores) podrían modificar una lista de
campos que nosotros previamente habríamos definido en el customizing como
campos sensibles.
Tenéis todos los detalles en este entrada del blog:
https://saptricks.wordpress.com/2013/03/06/truco-47-proteccion-de-
modificaciones-de-campos-en-maestro-de-clientes-y-proveedores/
Puede ocurrir un caso parecido, en el que nosotros queramos permitir
modificaciones en el maestro (tanto de clientes o proveedores) en
campos sensibles, pero que sea requerido que las modificaciones de
dichos campos sean validadas por un segundo usuario. Existe una
parametrización en el estándar que nos permite indicar que campos, cuando sean
modificados, serán sensibles para aprobación. En ese caso, la emisión de pagos
se bloqueará en el sistema para el interlocutor, hasta que se realice la validación
de los cambios por parte del responsable.
A continuación vamos a ver la configuración de esta funcionalidad y como afecta
a la forma de trabajar en el sistema.
Por un lado, realizaremos la parametrización de los campos sensibles a las

modificaciones:
 Clientes: ruta de customizing Gestión financiera –> Contabilidad de

deudores y acreedores –> Cuentas de deudor –> Datos maestros –> Preparar
creación de datos maestros de deudores –> Def. campos
sensibles p.ppiio.verif.p/2 o mas pers. o transacción S_ALR_87003378.
 Proveedores: ruta de customizing Gestión financiera –> Contabilidad de
deudores y acreedores –> Cuentas de acreedor –> Datos maestros –>
Preparar creación de datos maestros de acreedores –> Def. campos
sensibles p.ppiio.verif.p/2 o mas pers. o transacción S_ALR_87003179
En nuestro ejemplo, hemos configurado tres campos sensibles para el maestro de
proveedores.
En principio, a nivel de parametrización ya no habría que configurar nada más.
Cuando entremos a modificar el maestro de proveedores (o clientes), con

cualquiera de las transacciones disponibles, como son la MK02, FK02 o
XK02 (VD02, FD02 o XD02 para clientes), el sistema nos permite realizar la
modificación de los campos. Pero al grabar, aparece el siguiente mensaje:
El mensaje nos indica que se han modificado datos sensibles y que otro usuario
autorizado tendrá que confirmar los cambios con la transacción FK08 (FD08
para clientes). Si miramos en las tablas del maestro de proveedores, podemos
ver que se guarda la información del status de confirmación.
El bloqueo determina que no se puedan realizar propuesta de pagos al
proveedor utilizando la transacción F110 hasta que no se realice la confirmación.
La operativa terminará cuando otro usuario diferente (el mismo usuario no podrá
nunca realizar la confirmación), entre a la transacción FK08 y verifique que los
cambios son correctos.
Al realizar la confirmación se podrán consultar cuales fueron los cambios en los

campos sensibles antes de proceder a la confirmación o al rechazo de los
cambios. Si el usuario Confirma los cambios, se eliminará el bloqueo
de pago. Si el usuario rechaza los cambios, el interlocutor continuará bloqueado
y, lo que es importante, no se echarán para atrás las modificaciones de forma
automática.
En ese caso, cuando volvamos a entrar a modificar o a consultar el proveedor, nos

aparecerá el mensaje de que los cambios siguen sin confirmar. En esta
situación, alguien tendría que verificar las modificaciones y echarlas para atras
en el caso de que fuera necesario, volviendo a confirmar que todo queda
correctamente en la FK08.
Es una forma estándar y sencilla de controlar que las modificaciones
en campos sensibles de los maestros de clientes o proveedores son
visados por un responsable que verificará la corrección de datos maestros
importantes (Datos de impuestos, cuentas, condiciones de pago, información
para tesorería, direcciones, etc).
También existe la posibilidad de realizar confirmaciones (o rechazo) de
los cambios de forma masiva, utilizando la transacción FK09 (FD09
para clientes).
De esta forma, el usuario responsable puede analizar todos los cambios realizados
en el sistema y proceder a su tratamiento.
Autorizaciones necesarias:
Para que el usuario puede ejecutar las transacciones:
 Objeto S_TCODE: con las transacciones FK08 y FK09 (el resto de usuarios
no tendría que tener acceso a estas transacciones.
 Autorizaciones propias del maestro de proveedores (idem para
clientes con el objeto KNA1).
F_LFA1_AEN Acreedor: Autorización modificación p.campos determinados
F_LFA1_APP Acreedor: Autorización para aplicación
F_LFA1_BEK Acreedor: Autorización de cuentas
F_LFA1_BUK Acreedor: Autorización para sociedades
F_LFA1_GEN Acreedor: Datos centrales
F_LFA1_GRP Acreedor: Autorización de grupos de cuentas
Truco 81. Debug en procesos de fondo.
Publicado el 25 junio, 2016por Roberto Espinosa
2 Votes
Hace tiempo hablamos de la forma de realizar debug en las transacciones o

reports de Sap, incluso cuando estábamos en ventanas modales en las que no
está disponible el cuadro de comando (ver
entrada https://saptricks.wordpress.com/2013/04/28/truco-53-debug-en-
ventanas-popup/)
En ocasiones, el debug necesitamos realizarlo en procesos de fondo (por ejemplo,
un job planificado en el sistema) o en las actualizaciones que se lanza de forma
asíncrona cuando grabamos los datos en un proceso (por ejemplo, al facturar
pedidos de ventas o entregas en SD).
Para el caso de los procesos de actualización, bastaría con activar la opción

correspondiente en los parámetros de usuario cuando estamos en la herramienta
de debug. Esto se realiza desde el punto de menú Opciones –>
Visualizar/Modificar parametrizaciones que tenemos disponible desde la
ventana de debug.
Cuando lo que queremos hacer es realizar un debug sobre un proceso que se
ejecuta en fondo, tenemos disponibles varios métodos para realizar el proceso.
En detalle, cada una de las opciones serían:
Jobs que están en ejecución

Accederemos a la transacción SM50, donde podemos consultar los procesos
que se encuentran en ejecución en nuestro sistema. Nos posicionaremos encima
del proceso a debugear y seleccionaremos la opción de menu Programa/Modo –
> Programa –> Debugging.
A continuación se nos pedirá confirmación de la acción y entraremos a la
herramienta de debug de la forma habitual.
Jobs finalizados.
Para realizar la misma operación, pero en este caso sobre jobs que ya hayan
concluido, accederemos a la transacción SM37 y seleccionaremos el job que
queremos analizar.
Escribiremos el comando JDBG en el campo de transacción, tal y como vemos
en la imagen siguiente:
El programa del job seleccionado se ejecutará en modo debug, con un

comportamiento de proceso en fondo (con la variable de sistema SY-BATCH =
‘X’).
Forzar debug en jobs de fondo.
En ocasiones, los jobs que se estan ejecutando son rápidos y no nos da tiempo a
acceder a la SM50 para lanzar el debug sobre ellos. Para solucionar este
problema, utilizaremos un pequeño truco.
Cuando realicemos la definición de los jobs con la transacción SM36,

añadiremos siempre un paso previo, que incluirá la ejecución del
programa BTCLOOP.
El programa BTCLOOP genera un bucle infinito, que hace que tengamos el
programa disponible en la SM50 para poder tomar el control de el con el debug
(como hemos indicado anteriormente).
Bastará con cambiar el valor de la variable I a 1, y el programa continuará su
ejecución, realizando el debug hasta donde nos interese (habiendo puesto, por
ejemplo, puntos de breakpoint en el programa que nos interesa analizar).
Truco 83. Configuración tabulacion en una pantalla
de SAP.
4 Votes
En nuestros propios desarrollos Z, podemos configurar que cuando el

usuario pulsa la tecla Tabulación (TAB), el cursor pase de un campo a
otro en un orden establecido. Esto, que parece una tontería, puede ahorrar
horas de trabajo a un usuario que trabaja siempre con la misma transacción y se
limita a completar un número limitado de campos en una pantalla con mucha
información que no siempre introduce.
¿Y que ocurre cuando estamos hablando de las transacciones estándar?. El
programa que utilizamos para conectarnos a nuestro Sap (SAPGUI), nos
permite, en sus opciones de configuración, personalizar, por cada
equipo, el orden de fabulación en las pantallas según las necesidades del
usuario.
Para ver la configuración de la tabulación y realizar la personalización,

podemos acceder al menú contextual pulsando la tecla Control (CTRL)
y el botón derecho del ratón en cualquier campo de la pantalla. Las opciones
marcadas en rojo en la imagen aparecen al pulsar la tecla Control (no son visibles
si utilizamos el menú contextual normal).
Para ver la configuración de esta opción, vamos a realizar un sencillo ejemplo con
la transacción de registro de facturas de acreedor en compras (transacción FB60).
Deseamos que al entrar el usuario en la transacción, el cursor se posicione en un

campo. Para ello, nos posicionamos en el campo Acreedor y pulsamos la tecla
CTRL y el botón derecho del ratón. Seleccionamos la opción “Secuencia de
tabulación local: Punto de acceso”.
A continuación iremos realizando la secuencia de tabulación por los diferentes

campos de la pantalla de la siguiente manera:
 Nos posicionaremos en el campo origen y pulsaremos la tecla CTRL y el

botón derecho del ratón, seleccionando la opción “Secuencia de tabulación
local: Elemento de Salida”. Con esto determinamos el origen en la tabulación.
 Nos posicionaremos en el campo destino y pulsaremos la tecla CTRL y el
botón derecho del ratón, seleccionando la opción “Secuencia de tabulación
local: Elemento de Entrada”. Con esto determinamos el destino en la
tabulación.
 Repetiremos la secuencia para todo el conjunto de campos que deseemos.
Tras terminar la configuración, podemos visualizar el resultado de la
configuración seleccionado la opción “Configurar secuencia de tabulación local”.
El icono correspondiente en la barra de estado (ver imagen), nos indica
igualmente que se ha configurado la tabla de tabulación para la pantalla en la
que nos encontramos.
Cuando el usuario para el que hemos realizado la configuración acceda a su

equipo y entre en la transacción FB60, el curso se le posicionará en el
Proveedor (Acreedor). Ira introduciendo la información y al pulsar la
tecla TAB, ira pasando por los diferentes campos de la pantalla en el
orden configurado. Sin duda es una funcionalidad que nos puede permitir
mejorar la productividad del usuario y ahorrarle mucho trabajo al usuario (sobre
todos aquellos que trabajan con grandes volúmenes de información,
introduciendo datos en el sistema).
Truco 84. Transporte de variantes de Layout en
Informes ALV.
4 Votes
Como todos vosotros conocéis, los informes que se muestran en formato

ALV dentro de Sap son una herramienta muy útil para consultar la información
y personalizar las listas de resultados utilizando las variantes de visualización o
disposiciones del ALV (también conocidos como Layouts).
Con estas variantes podemos personalizar los campos que se visualizan

(del catálogo disponible en cada informe), definir valores de
clasificación, ordenación, filtros, etc. Toda esta configuración queda
guardada dentro del Layout y se recupera cuando se selecciona en la lista de
resultados (o al ejecutar el informe en algunas transacciones).
En ocasiones nos puede interesar transportar los layouts de un
mandante a otro, o de un sistema a otro. No hay ningún problema, Sap nos
habilita la opción para poder realizar este transporte, que no se realiza de forma
automática (pues no se trata en si de un objeto de customizing).
Para hacer el transporte, seleccionaremos la opción Opciones –> Disposición
–> Gestionar (puede haber varias formas de acceder a esta opción según la
transacción en la que nos encontremos).
A continuación se nos mostrará una lista con los Layouts definidos en la
transacción en la que nos encontremos. Con la opción de menú Layout –>
Transportar podremos incluir en una orden de transporte los Layouts que
deseemos transportar.
El sistema nos pedirá una orden de transporte de Customizing. Al ser importada

la orden en el destino, tendremos disponibles todos los Layouts que hayamos
configurado, por ejemplo, en nuestro de desarrollo para probar un desarrollo Z o
una transacción estándar.
Feliz lectura!!!.

Tucos SAP

Cargado por

Copyright:

Formatos disponibles

Tucos SAP

Cargado por

Información del documento

Descripción original:

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tucos SAP

Cargado por

Copyright:

Formatos disponibles

Tucos SAP

Truco 1 – Texto personalizado en la pantalla de Logon

Esta imagen se puede ocultar a nivel de usuario desde la opción de menú

 Carga de la imagen en Sap: a través de la

 Parametrización: a través de la transacción SM31, crearemos un registro

 Menú de usuario: es el menú que se construye con los roles de

En la imagen siguiente podemos ver un ejemplo de definición de un Rol para

Además, tanto en un menú como en otro el usuario tendrá disponible siempre su

 Cambiar el menú Sap para un usuario individual: desde el

 Configuración de menú permitidos por usuario: aparte de todas las

En muchas ocasiones, las ayudas de busqueda estandar de Sap

Como ejemplos de ayudas de búsqueda que habitualmente se van a tener que

1. Asegurarnos que las ayuda de búsqueda estandar no cumplen con los

1. Revisión de las ayudas de búsqueda existentes, asegurandonos que

Accedemos a la transacción SE11 y consultamos la ayuda PREM. Es una ayuda

4. Creación de la ayuda de busqueda (ZPREMN).

En la columna P.I indicamos los campos que aparecen en los resultados de

En la ayuda se pueden definir otros parámetros, como el tipo de dialogo cuando

5. Creación de la vista asociada a la ayuda de búsqueda.

6. Asignación de la ayuda en la ayuda estandar.

En muchas ocasiones necesitamos modificar el comportamiento del

EJEMPLO PRACTICO: VERIFICACION

Desde la misma utilidad accedemos a la transaccion SMOD, donde podemos

2) Creación de un proyecto de ampliación e inclusión de la

3) Desarrollo del código que implementa la validación.

*& Include ZXF04U01

DATA: lv_kunnr LIKE kna1-kunnr.

* Si el pais es ESPAÑA tiene que tener rellenado el NIF nor

IF i_kna1-land1 = 'ES' AND i_kna1-stcd1 IS INITIAL.

MESSAGE e000(zfi). "Campo NIF obligatorio.

* Chequeamos que no esté repetido el NIF.

ELSEIF i_kna1-land1 = 'ES' AND i_kna1-stcd1 IS NOT INITIAL.

SELECT SINGLE kunnr INTO lv_kunnr

WHERE kunnr <> i_kna1-kunnr

AND stcd1 = i_kna1-stcd1

* Si el cliente tiene peticion de borrado no lo tiene que ten

* en cuenta en la verificacion de nif duplicados.

and LOEVM ne 'X'.

MESSAGE e008(zsistemas) WITH 'EL cliente' lv_kunnr 'tien

La verificación es sencilla, pero podriamos haber incluido otras como exigir

4) Verificación y pruebas. Puesta en productivo.

La verificacion se realiza cuando vamos a

En todas las empresas tenemos ejemplos de compras reguladas por contrato, y

En estos casos, nos va a llegar regularmente la correspondiente factura, y no es

Para este tipo de casuísticas, utilizaremos en Sap los planes de

A nivel de posición, siempre hay que desmarcar la casilla Verificación Factura

Los valores mas importantes que podemos introducir en el plan de facturación

Clase de plan de facturación.

Para el caso de la regla trimestral, hemos indicamos en el periodo el valor 3, y

Si estais pensando en aprender o certificaros en Sap en el Módulo MM, aquí os

Sap propone varios niveles de certificación (+info en la web de Sap), con un

 Manual de Instructor del curso TSCM50 (Ingles): Parte 1 y Parte 2.

 Repositorio de preguntas de certificación relacionadas con MM: ver aquí.

Pero a traves de las variantes de transacciones y de pantalla, podemos

 la asignación previa de campos con valores (valores predefinidos en campos)

a) Creación de la variante: entramos en la transacción SHD0, indicamos la

Al crear la transacción, indicaremos la transacción estándar y el nombre de la

Siguiendo el mismo procedimiento, vamos a preparar dos transacciones

2. Creación de pedidos de venta, omitiendo la primera pantalla donde se