saptricks.wordpress.com Open in urlscan Pro
192.0.78.12  Public Scan

Submitted URL: http://saptricks.wordpress.com/
Effective URL: https://saptricks.wordpress.com/
Submission: On May 17 via api from US — Scanned from DE

Form analysis 4 forms found in the DOM

GET https://saptricks.wordpress.com/

<form role="search" method="get" id="searchform" class="searchform" action="https://saptricks.wordpress.com/">
  <div>
    <label class="screen-reader-text" for="s">Buscar:</label>
    <input type="text" value="" name="s" id="s">
    <input type="submit" id="searchsubmit" value="Buscar">
  </div>
</form>

POST https://subscribe.wordpress.com

<form action="https://subscribe.wordpress.com" method="post" accept-charset="utf-8" data-blog="17484522" data-post_access_level="everybody" id="subscribe-blog">
  <p id="subscribe-email">
    <label id="subscribe-field-label" for="subscribe-field" class="screen-reader-text"> Dirección de correo electrónico: </label>
    <input type="email" name="email" style="width: 95%; padding: 1px 10px" placeholder="Dirección de correo electrónico" value="" id="subscribe-field" required="">
  </p>
  <p id="subscribe-submit">
    <input type="hidden" name="action" value="subscribe">
    <input type="hidden" name="blog_id" value="17484522">
    <input type="hidden" name="source" value="https://saptricks.wordpress.com/">
    <input type="hidden" name="sub-type" value="widget">
    <input type="hidden" name="redirect_fragment" value="subscribe-blog">
    <input type="hidden" id="_wpnonce" name="_wpnonce" value="24726185a7"> <button type="submit" class="wp-block-button__link"> Sign me up! </button>
  </p>
</form>

POST https://subscribe.wordpress.com

<form method="post" action="https://subscribe.wordpress.com" accept-charset="utf-8" style="display: none;">
  <div class="actnbr-follow-count">Únete a otros 1.551 suscriptores</div>
  <div>
    <input type="email" name="email" placeholder="Introduce tu dirección de correo electrónico" class="actnbr-email-field" aria-label="Introduce tu dirección de correo electrónico">
  </div>
  <input type="hidden" name="action" value="subscribe">
  <input type="hidden" name="blog_id" value="17484522">
  <input type="hidden" name="source" value="https://saptricks.wordpress.com/">
  <input type="hidden" name="sub-type" value="actionbar-follow">
  <input type="hidden" id="_wpnonce" name="_wpnonce" value="24726185a7">
  <div class="actnbr-button-wrap">
    <button type="submit" value="Suscríbeme"> Suscríbeme </button>
  </div>
</form>

<form id="jp-carousel-comment-form">
  <label for="jp-carousel-comment-form-comment-field" class="screen-reader-text">Escribe un comentario...</label>
  <textarea name="comment" class="jp-carousel-comment-form-field jp-carousel-comment-form-textarea" id="jp-carousel-comment-form-comment-field" placeholder="Escribe un comentario..."></textarea>
  <div id="jp-carousel-comment-form-submit-and-info-wrapper">
    <div id="jp-carousel-comment-form-commenting-as">
      <fieldset>
        <label for="jp-carousel-comment-form-email-field">Correo electrónico (Obligatorio)</label>
        <input type="text" name="email" class="jp-carousel-comment-form-field jp-carousel-comment-form-text-field" id="jp-carousel-comment-form-email-field">
      </fieldset>
      <fieldset>
        <label for="jp-carousel-comment-form-author-field">Nombre (Obligatorio)</label>
        <input type="text" name="author" class="jp-carousel-comment-form-field jp-carousel-comment-form-text-field" id="jp-carousel-comment-form-author-field">
      </fieldset>
      <fieldset>
        <label for="jp-carousel-comment-form-url-field">Web</label>
        <input type="text" name="url" class="jp-carousel-comment-form-field jp-carousel-comment-form-text-field" id="jp-carousel-comment-form-url-field">
      </fieldset>
    </div>
    <input type="submit" name="submit" class="jp-carousel-comment-form-button" id="jp-carousel-comment-form-button-submit" value="Publicar comentario">
  </div>
</form>

Text Content

NOTAS Y TRUCOS SAP (BITACORA)

Trucos y anotaciones para el día a día con Sap
Ir al contenido
 * Inicio
 * Indice
 * Transacciones
 * ABAP
   * Ejemplos Abap
 * Descargas
 * Material
 * Funcional
   * CO
   * CRM
   * FI
   * HR
   * MM
   * PM
   * SD
 * Notas OSS
 * Sobre mi

← Entradas anteriores



TRUCO 125. VALORES POR DEFECTO EN DATOS DE CLIENTES Y PROVEEDORES UTILIZANDO
BUSINESS PARTNERS (BP)

Publicado el 5 noviembre, 2023 por Roberto Espinosa
i

5 Votes




En un post anterior hablamos de la forma de inicializar valores por defecto
cuando estamos creando los datos de clientes o proveedores en un sistema R3,
usando las Badis VENDOR_ADD_DATA y CUSTOMER_ADD_DATA. De esa forma podiamos
conseguir tener valores por defecto en los datos de sociedad o ventas/compras en
el momento de la creación de los datos maestros.

Pero que ocurre si estamos en un sistema S4 y ya estamos trabajando directamente
con Business Partners. En ese caso, estamos pasando por la integración CVI y las
Badis anteriores ya no son validas ni funcionan.

En esta situación, tenemos una alternativa a través de la Badi
CVI_DEFAULT_VALUES.

Realizando una o varias implementaciones de esta Badi, podemos conseguir
inicializar valores por defecto cuando estemos creando los datos de un BP, en la
parte correspondiente a datos de Clientes o de Proveedores:

Para los clientes, tenemos disponibles los métodos:

GET_DEFAULTS_FOR_CUST: datos generales de cliente.
GET_DEFAULTS_FOR_CUST_CC: datos de sociedad.
GET_DEFAULTS_FOR_CUST_SALES: datos de ventas.

Y para los proveedores los siguientes:

GET_DEFAULTS_FOR_VEND: datos generales de proveedor.
GET_DEFAULTS_FOR_VEND_CC: datos de sociedad.
GET_DEFAULTS_FOR_VEND_PORG: datos de compras.

En la interfaz de cada uno de los métodos tenemos la información de los roles
que se estan tratando durante la creación del BP y las estructuras de
intercambio para poder dar valor a los campos. Ademas, en las últimas versiones
tenemos toda la información de la tabla BUT000 disponible en los métodos.

Ejemplo 1. Valores por defecto al crear los datos de sociedad de un BP (rol
FLCU00).

En nuestro ejemplo, estamos creando un cliente desde 0, y queremos, que, al
crear el BP con el rol FLCU00, se inicializen ciertos valores por defecto a
nivel de sociedad.

Al crear los datos de sociedad del BP, en la parte de cliente, los valores se
inicializan según lo indicado en la programación (cuenta asociada, forma de
pago, via de pago, grupo de tesorería, etc).

Ejemplo 2. Valores por defecto al crear los datos de ventas de un BP (rol
FLCU01).



En este caso, queremos que según la agrupación de BP y la organización de ventas
(canal), se inicialicen valores por defecto en los datos de venta del cliente.

En el momento de la creación de los datos de ventas del BP, la información se
inicializa según lo indicado:

En este caso, ademas de poder inicializar los valores de ventas, también
podremos modificar los datos relacionados con las funciones de interlocutor y
los datos de impuestos que tenemos en la pestaña de Factura ( que se podran
modificar en las tablas C_FUNCTIONS y C_TAX_IND de la Badi).

Otros escenarios.



Si lo que necesitais es definir valores por defecto al crear un BP, fuera del
ambito de cliente/proveedor, podeís seguir las instrucciones descritas en la
nota:

2992030: Cómo crear un interlocutor comercial con valores propuestos en la
transacción BP

Teniendo en cuenta que estamos bastante limitados en cuanto a los valores que
podremos inicializar.








COMPARTIR:

 * Correo electrónico
 * 
 * 
 * Imprimir
 * Share
 * 

Me gusta Cargando...
Publicado en Formacion, S/4HANA, Sap FI, SAP MM, Sap SD | Etiquetado BP,
CVI_DEFAULT_VALUES, Default Values, Valores por defecto | Deja un comentario


TRUCO 124. ALGUNAS COSAS QUE DEBERIAMOS DE CONOCER SOBRE LAS ORDENES DE
TRANSPORTE EN SAP.

Publicado el 4 diciembre, 2022 por Roberto Espinosa
i

7 Votes




La orden de transporte es el elemento fundamental que nos permite «mover» la
parametrización y los elementos de desarrollo o workbench (tablas, elementos de
datos, dominios, programas, dynpros, clases, módulos de función, formularios,
etc) desde el sistema de Desarrollo hasta los sistemas intermedios de pruebas
(Test, Qas) y finalmente al sistema de Producción.

Es fundamental, aunque no seamos consultores técnicos, que tengamos unas
nociones básicas sobre las ordenes y que también que seamos conocedores de los
problemas más habituales que se producen con las ordenes por no gestionarlas
correctamente.

Tipos de Ordenes.

Aunque existen otros tipos de ordenes (por ejemplo, los Hot Packages que
utilizamos para las actualizaciones de SAP), normalmente un consultor o
desarrollador trabaja principalmente con tres tipos de ordenes:

 * Customizing: ordenes del tipo W, son las que utilizamos para registrar los
   cambios en la parametrización que completamos en el sistema de desarrollo.
   Normalmente, la parametrización corresponde con entradas en tablas o vistas
   de actualización, donde guarda la parametrización del sistema realizada a
   través de la transacción SPRO. Y es una configuración dependiente del
   mandante en el que estemos conectados.
 * Workbench: ordenes del tipo K, son las utilizadas por los desarrolladores
   cuando realizar cualquier creación o modificación de los objetos de
   desarrollo (reports abap, clases, dynpros, formularios, objetos del
   diccionario de datos, ayudas de busqueda, cds, vistas, etc., etc.). Las
   ordenes de workbench registran objetos que son independientes de mandante. La
   parametrización de objetos que no depeden del mandante también se incluyen en
   ordenes de este tipo.
 * Transporte de copias: nos permite realizar el transporte de objetos de
   desarrollo o parametrización, incluidos en otras ordenes, sin necesidad de
   liberar las ordenes originales. Por ejemplo, puede ser útil para probar un
   desarrollo en un sistema de test sin liberar la orden en desarrollo donde
   estamos realizando todos los cambios. También se puede utilizar con ordenes
   de parametrización.

Cuando creamos una orden del tipo Transporte de copias, la orden se crea vacía y
nosotros a continuación seleccionamos los objetos que queremos incluir en ella
para su transporte para la realización de pruebas (normalmente los objetos
incluidos en uno o varias ordenes adicionales que todavia no hemos liberado).

Elementos de una orden.

Normalmente, en una orden veremos al menos el número de orden principal y una o
varias tareas (asociadas a los diferentes usuarios que intervienen en un proceso
de parametrización del sistema o de creación de objetos de desarrollo).

Tanto la cabecera como las tareas pueden incluir objetos, aunque lo habitual es
que esten en cada una de la tareas.



Para que un usuario pueda incluir sus objetos en una orden de transporte, habrá
que crear una tarea para el dentro de la orden. Es tan sencillo como acceder a
la transacción SE09/SE10, seleccionar la orden, y con el botón derecho
seleccionar la opción «Añadir empleado».

El sistema nos solicitará el identificador del usuario que queremos incluir y se
creará una tarea para el dentro de la orden.

Modificar el titular de una tarea o de la orden.

En ocasiones, las ordenes de transporte o sus tareas estan asociadas a usuarios
incorrectos (usuarios borrados o que dejaron la compañia). En las ordenes o
tareas que no esten liberadas, podremos modificar el titular sin problema desde
la transacción SE09/SE10, seleccionando el elemento y, desde botón derecho,
opción «Modificar titular». Esto vale tanto para la tarea como para la orden en
si.

Que ocurre cuando liberamos una orden.

Para liberar una orden de transporte, primero hemos de liberar todas las tareas
incluidas en ella, con el menú contextual (botón derecho) o pulsando la tecla
F9.

A continuación, repetiremos la acción con la orden propiamente dicha, momento en
el nos aparecerá un dialogo indicando que se ha realizado la liberación de la
orden.

En este momento, se escribe, a nivel de sistema operativo, en el directorio de
transporte, dos ficheros que incluyen todos los elementos incluidos en la orden.
Los ficheros que se escriben son los siguientes:

 * Directorio data: fichero RXXXXXX.YYY, donde XXXXXX es el número de la orden y
   YYY el id de la instancia donde hemos realizado la creación de la orden. Es
   el fichero binario que incluye todos los cambios realizados.
 * Directorio cofiles: fichero KXXXXXX.YYY, con el mismo significado. Es el
   fichero de control.

Conocer la existencia de estos ficheros nos puede ser de utilidad para mover,
por ejemplo, un desarrollo o parametrización a otro sistema que no este
conectado al sistema de transporte (por ejemplo, un sandbox o un sistema de
pruebas autonomo).



Igualmente, es importante entender que es el momento de la liberación cuando el
sistema accede a la base de datos y lee la parametrización o desarrollos
realizados, y se guarda una copia de esos elementos a nivel de fichero. Y esa
copia será la que se transmita al sistema destino cuando hagamos la importación
con la transacción STMS. Si entendemos bien esto, nos evitaremos muchos
problemas. Por ejemplo, yo puedo haber realizado una parametrización del control
de copia en la facturación (transacción VTFL) y haberla incluido en una orden.
Si un compañero, antes de liberar la orden, realiza otro cambio sobre la misma
configuración, aunque la incluya en otra orden, cuando yo libere mi orden me
llevaré los cambios de mi compañero. Algo parecido ocurrirá con objetos de
desarrollo (workbench), aunque en ese caso Sap no nos deja tocar el mismo objeto
en dos ordenes abiertas a la vez (en ese caso siempre se incluyen todos los
cambios, aunque sean de diferentes usuarios, en la misma orden, con una tarea
para cada uno de los usuarios).

Ver los objetos que conforman una orden.

Cuando accedemos al detalle de la orden o tarea (SE09/SE10), podemos ver la
lista de objetos incluidos en ella con sus nombre técnicos.

Para hacernos una idea, podemos ver en la imagen un ejemplo de objetos de una
orden de parametrización.

En esta otra imagen una orden de workbench, con los objetos de desarrollo
incluidos.

Cada uno de los objetos incluidos en la orden tiene un nombre técnico, que se
identifica con tres elementos:

 * Id. Programa: normalmente veremos el valor R3TR, aunque cuando transportarmos
   traducciones de textos podremos ver el valor LANG o valores que nos indican
   comentarios.
 * Tipo de Objeto: identifica el tipo de objeto que estamos incluyendo en la
   orden. Hay más de mil tipos de objetos diferentes.

Algunos de los tipos de objetos más habituales para un consultor funcional serán
TABU (contenido de una tabla de parametrización), VDAT (vista de
parametrización), TDAT, CDAT (cluster de vistas de parametrización), ACGR (roles
de autorizaciones), etc.

 * Nombre del objeto: el nombre que identifica al objeto incluido en la orden.



En la orden también puede aparecer el objeto de parametrización asignado a cada
elemento de la orden (en el campo llamado Actividad IMG). Ademas para cada
elemento incluido dentro de una orden, podremos ver, para los objetos asociados
a contenido de tablas o vistas, los registros de datos asociados pulsando el
icono de la Llave (Objeto con claves).

Es interesante conocer esto, pues lo que veamos en ese detalle serán los valores
de configuración que realmente se van a transportar cuando liberemos la orden de
transporte. Nos permite realizar chequeos o analizar problemas cuando algo ha
fallado después del transporte de una configuración.

Fusionar ordenes.

Tanto en un proyecto como en las tareas de soporte habituales, es posible que
hayamos creado varios ordenes de transporte donde hemos ido incluyendo
elementos. Llegado el momento de gestionar el paso de los cambios a productivo,
el disponer de varias ordenes puede ser confuso de cara a la importación de la
orden en el destino (objetos dependientes, orden de la carga, etc).

Para evitar problemas, una solución puede ser el fusionar una o varias ordenes
en una única orden, de forma que realizaremos el transporte completo de todos
los objetos en un único «contenedor».

Para realizar la fusión de dos ordenes, usuaremos el menú contextual (opción
«Fusionar ordenes»).

El sistema nos pedirá la orden origen y la orden destino (donde se realizará la
fusión). La orden origen se eliminará una vez completado el proceso de fusión.

Esta opción se utiliza mucho en los proyectos cuando diferentes consultores han
estado trabajando en la configuración con ordenes individuales y necesitamos
incluir todos los objetos en la misma orden, dentro de las tareas de preparación
de la subida de los cambios a productivo.

Incluir elementos de una orden en otra.

Además de la fusión de ordenes, otra opción muy útil es la de incluir en una
orden de transporte objetos de otras. Esto lo realizaremos desde el menú
contextual, con la opción «Incluir objetos».

Nos aparecerá un popup desde el cual dispondremos de diferentes opciones para
incluir nuevos objetos en la orden:

 * Objetos de una orden.
 * Objetos de varias ordenes.
 * Selección libre de objetos.
 * Etc.



Cuando incluimos en una orden objetos de otra orden, podremos ver en la cabecera
de la orden entradas de este tipo, que nos indican que se toman objetos de otra
orden. Y estos objetos serán incluidos cuando liberemos la orden para el
transporte.

De forma que vemos que realmente se esta guardando un «puntero» a la otra orden.

Incluir la ejecución de un programa tras el transporte de una orden.

Existen tareas de configuración del sistema, que pueden requerir la ejecución de
un determinado programa una vez se transportan los cambios a los sistemas de
test o de productivo. Por ejemplo, cuando creamos rutinas con la transacción
VOFM (como rutinas de calculo de precio, condiciones, etc), una vez se pasan los
cambios a productivo, hay que ejecutar el report RV80HGEN para la regeneración
de los pools de programas y asi, de esta forma, la rutina puede ser utilizada en
el sistema.

Si queremos evitar tener que hacer esta ejecución manualmente, podemos incluirla
en la orden de transporte. Para ello, iremos a la orden de transporte
(SE09/SE10), opción Modificiar, e incluiremos un nuevo objeto con los valores:

Cuando transportemos la orden al siguiente sistema, Sap ejecutará el programa
indicado una vez completadas las tareas de importación de los elementos de
orden.

Una forma fácil de no olvidarnos de tareas que son obligatorias, incluso puede
valer para nuestros propios desarrollos.

Abrir una orden de transporte ya liberada.

Una orden de transporte ya liberada, ha generado ya los correspondientes
archivos en el directorio de transporte (como hemos visto antes) y en principio
no es posible volver asignar mas cambios en ella.

En el caso de que fuese necesario «revertir» la liberación de una orden,
podriamos utilizar, desde la transacción SE38 el report RDDIT076. Indicaremos la
orden de transporte y ejecutaremos.

Al acceder veremos la orden de transporte y sus tareas asociadas, con
información de su estado. Una orden ya liberada estará en estado «R – Liberado».

Para volver abrir la orden, cambiaremos primero el status de orden, indicando el
valor «D – Modificable». A continuación, repetiremos la acción para todas las
tareas que incluya y grabaremos. Esta orden estará lista para seguir trabajando
con ella e incluyendo objetos hasta que la volvamos a liberar, aunque será
necesario modificar la orden con la transacción SE09/SE10 y eliminar el atributo
EXPORT_TIMESTAMP, ya que sino no será posible volverla a liberar.

Nota: no se recomienda realizar esta tarea más que en casos excepcionales, por
las implicaciones que podría tener incluir en una orden ya liberada (y puede que
transportada), objetos nuevos y volver a realizar un ciclo completo de
transporte sin verificar que pueda haber otras ordenes dependientes afectadas.



Borrar objetos o una orden.

En ocasiones hemos realizado pruebas en un sistema y hemos incluido cambios en
una orden de tranporte, que finalmente no desearemos transportar a productivo.

Con cuidado, para no evitar inconsistencias, es posible borrar objetos de una
orden desde la SE09/SE10. Buscaremos el lugar donde esta incluido el objeto, y
pulsaremos la opción de modificar:

Una vez localizados los objetos a eliminar, los seleccionaremos y pulsaremos la
opción de eliminar. De esta forma, estos objetos quedarán excluidos del
transporte y no se moveran al sistema destino. Y como siempre, utilizar con
mucho cuidado para no generar un problema cuando estamos intentando solucionar
otro.

Buscar objetos en las ordenes.

Es muy habitual que se produzcan problemas cuando se transportan los cambios a
productivo, tanto relacionados con customizing o objetos de desarrollo. Cuando
ocurre esto, necesitamos una herramienta ágil para poder buscar los objetos en
las ordenes y poder identificar cual es el problema que se ha producido.

Para ello, disponemos de la transacción SE03, que nos sirve de Menú para todas
las tareas relacionadas con las ordenes.

En mi caso, voy a utilizar la opción «Buscar objetos en ordenes» para localizar
las ordenes que han tocado una determinada tabla de parametrización.

Al seleccionar esta opción, nos aparece un report donde podemos indicar los
objetos que queremos buscar y el ambito de la busqueda (tipos de ordenes, status
de las ordenes, numeros de orden, fecha, usuario, etc).

Si tenemos un conocimiento mínimo de los objetos más habituales, podremos
sacarle partido y encontrar el origen de problemas relacionados con el
transporte. Cuando ejecutemos el informe, nos devolverá la lista de ordenes que
cumplan las condiciones.

Problemas más habituales con las ordenes.



Por su propia forma de funcionamiento, las ordenes de transporte son una fuente
continua de problemas, que normalmente se solucionan con unas buenas prácticas e
intentando evitar determinadas cosas. Lo primero de todo, es entender dos cosas
básicas:

 * Ordenes de parametrización: los valores que se exportan a los ficheros de las
   ordenes de transporte son los que tienen las tablas de configuración en el
   momento de realizar la exportación de la orden. Esto significa que yo puedo
   haber realizado una parametrización y haberla incluido en la orden (tendra su
   correspondiente objeto con sus valores de claves). Pero otra persona puede
   posteriormente haber cambiado esa configuración y haberla introducido en otra
   orden. Cuando yo libere la orden, me llevaré los cambios de la otra persona,
   no los valores que yo «pensaba» que se habian incluido.
 * Ordenes de workbench: normalmente, cuando transporte objetos de desarrollo,
   me llevaré el objeto de desarrollo completo en el momento de liberar la orden
   (por ejemplo, en un programa abap me llevo todo el código del programa).

Teniendo en cuenta estas dos cosas, algunos de los problemas más habituales son:

 1. Transportes incompletos: no nos llevamos todas las ordenes necesarias, y nos
    dejemos objetos dependientes sin transportar. Esto se puede producir tanto
    en ordenes de custo como de workbench.
 2. Secuencia de importación incorrecta: al importar las ordenes, no seguimos la
    secuencia correcta, lo que implica que se machaquen objetos con versiones
    anteriores, que al final dan como resultado que no tengamos en
    productivo/test la misma configuración que en el sistema de desarrollo.
    Normalmente volviendo a importar en el orden correcto se soluciona el
    problema.
 3. Transportes incorrectos: porque no estamos llevando la configuración
    realizada por nosotros o nos estamos llevando cambios de otros consultores
    incluidos en una orden. Esto es muy habitual, y puede producir problemas muy
    graves, pudiendo producir un fallo en la funcionalidad del sistema de
    productivo por transportes incompletos o erróneos.
 4. Transportes de calendarios o rangos de números: estos dos elementos son muy
    delicados y os recomiendo que ante que cualquier duda, consulteis a los
    consultores de Basis o los veteranos de vuestra empresa. Por ejemplo, los
    calendarios se transportan completos, si hay cualquier diferencia entre el
    sistema de DES y PROD, al transportar machacaremos la configuración de los
    calendarios (ver entrada del blog donde hablabamos de esto).
 5. Ordenes de transporte antiguas: es muy habitual que en el sistema de
    desarrollo vayan quedando ordenes de consultores que pasaron por la empresa,
    pruebas que se fueron realizando, funcionalidad que nunca se llego a subir a
    productivo. Es importante tener controladas esta ordenes e incluso intentar
    hacer limpieza para evitar problemas o errores en el futuro.
 6. Transporte de parametrización en desarrollo: algunas tareas funcionales,
    como la de abrir los periodos contables, es posible que el sistema nos pida
    orden de transporte en un entorno de desarrollo. Es importante no incluir
    estos cambios en una orden en la que estemos realizando parametrización, y
    lo incluyamos en una orden de las llamadas «No transportar». Asi también nos
    evitaremos algún susto.

Mi consejo, para evitar estos problemas, es intentar ser meticuloso y metódico,
revisar bien las ordenes en caso de duda y sobre todo, disponer de unas buenas
prácticas en la gestión del transporte de las que sean conocedores todas las
personas que realizan cambios en nuestro sistema.

Bibliografía.

https://blogs.sap.com/2020/05/26/7-secrets-about-sap-transportation-request-that-every-functional-consultant-should-knows/

https://blogs.sap.com/2016/06/16/xpra-execute-abap-program-automatically-after-transport-request-import/

https://www.kodyaz.com/sap-abap/execute-abap-program-after-transport-request-import.aspx




COMPARTIR:

 * Correo electrónico
 * 
 * 
 * Imprimir
 * Share
 * 

Me gusta Cargando...
Publicado en Formacion, S/4HANA, Sap Basis | Etiquetado Ordenes de transporte,
RDDIT076, SE03, SE09, SE10, Transport Request | Deja un comentario


TRUCO 123. ENCONTRAR LA AYUDA DE BÚSQUEDA ASOCIADA A UN CAMPO EN CUALQUIER
TRANSACCIÓN. BUSCAR CADENAS EN EL CÓDIGO ABAP.

Publicado el 16 noviembre, 2022 por Roberto Espinosa
i

3 Votes




Hoy os voy a compartir un par de trucos más técnicos, que seguramente puedan ser
de utilidad a la gente que hace desarrollos, aunque también a los consultores
funcionales que estan preparando especificaciones para desarrollos a medida o
ampliaciones del estandar.

Encontrar la ayuda de búsqueda asociada a cualquier transacción.

Empecemos con las ayudas de búsqueda. Como sabeís, en el estandar tenemos
multitud de ayudas de búsqueda o matchcodes, que nos permiten buscar los valores
de datos maestros, organizativos o de documentos cuando estamos realizando algún
proceso funcional. Cuando nos posicionamos en un campo, pulsando F4 o el icono
de acceso a la ayuda, el sistema nos muestra un dialogo con una o varias ayudas
de búsqueda (ayuda compuesta), la cual nos permite filtrar en el elemento,
localizar los valores y llevarnos uno o varios de ellos a la transacción en la
que nos encontremos.

En muchas ocasiones, estas ayudas estandar no son suficientes y necesitamos
ampliarlas con nuestras propias ayudas. En un post anterior en el blog, hablamos
de como realizar esta tarea de ampliación. Ahi explicamos todos los pasos para
hacerlo.

> Truco 6. Ampliacion de ayudas de busqueda (Matchcode).

El principal problema con el que nos solemos encontrar para ampliar una ayuda de
búsqueda estandar es localizar su nombre y encontrar el sitio donde «colocar»
nuestra ayuda Z. En muchas ocasiones, es muy sencillo, y basta con pulsar F1 en
el campo y mirar los opciones técnicas en el campo en cuestión.

Pero en la mayoria de ocasiones, esto no funciona y no es tan sencillo localizar
la ayuda, para luego poder ampliarla a través de la SE11. Para esto, vamos a
usar un truco realizando DEBUG, que hemos conocido gracias Arghadip Kar, un gran
compartidor de conocimiento Sap.



El truco consiste en poner un punto de break-point en el módulo de función
DD_SHLP_CALL_FROM_DYNP (transacción SE37). En mi ejemplo, he accedido a la
transacción ME21N (creación de pedidos) y he realizado una búsqueda por el campo
material.

El break-point lo he situado tras el perform DETERMINE_SHLP_OF_FIELD, en el
modulo de función indicado. Y en ese lugar, en la variable SHLP_TOP-SHLPNAME
tengo identificado el nombre de la ayuda de búsqueda.

En mi ejemplo, la ayuda se llama MAT1. Ya podré acceder a la transcción SE11 y
realizar los pasos para ampliar la ayuda de búsqueda estandar. Normalmente, en
las ayudas de búsqueda habrá ayudas de busqueda compuestas, y en una de ellas
podremos añadir nuestras propias ayudas de búsqueda Z.

En mi ejemplo, he añadido una nueva de búsqueda para localizar materiales por
tipo de material, excluyendo los materiales borrados o con un status general de
centro (MSTAE) distinto de blanco.

La ayuda la creado a partir de la ayuda MAT1T_E y la he incluido en la ayuda
compuesta MAT1T, que es la definida para hacer búsquedas por tipo de material.

Este procedimiento debería funcionar casi siempre, en caso contrario, ya os
recomiendo solicitar ayuda a un Abaper para localizarla.



Buscar cadenas en el codigo abap. Transacción EWK1 y otras alternativas.

Para terminar, un truco muy rápido y útil que nos permite localizar en cualquier
programa abap una determinada cadena, y que hemos conocido gracias a Enrique
Higuero. Para ellos podemos usar la transacción EWK1.

Con una interfaz muy sencilla, indicaremos los programas en donde buscar (se
pueden indicar caracteres comodin como el *), la cadenas que queremos encontrar
y algunos parametros para ajustar la búsqueda. En la opción Ambito de búsqueda
se pueden añadir mas lugares donde buscar.

Al ejecutar el programa, el sistema nos devolverá la lista de programas donde se
localize la cadena. En mi ejemplo, estaba buscando «Hardcode» en el código para
sustituirlo para una tabla de parametros y realizar una buena práctica de
desarrollo.

Esta opción es similar a la que podemos realizar desde la SE38, una vez estamos
dentro del código, con la opción Buscar.

Como curiosidad, indicar que la transacción EWK1 fue desarrollada por Sap como
una herramienta para la migración al Euro. Ya ha llovido un poco desde eso, unos
20 años!!!!



Además, tenemos otras alternativas a esta transacción, que os detallo (pueden
variar según la versión de Sap en la que nos encontremos):

 * Report RKCTSEAR.
 * Transacción CODE_SCANNER: es esta podemos hacer búsquedas trabajando tambien
   con los paquetes en los criterios de selección, tal y como veis en la imagen
   siguiente. Además nos permite excluir de la búsqueda a las lineas de
   comentarios o visualizar programas en los que no se encuentra el patron de
   búsqueda.

 * Report RPR_ABAP_SOURCE_SCAN: es uno de los más completos para realizar
   búsquedas, y el que os recomiendo si quereis hacer búsquedas más complejas.

Bibliografía.

https://blogs.sap.com/2020/08/25/how-to-find-a-search-help-behind-a-transaction-code-in-sap/

Different ways to find any string or hard coded values in sap abap code.


COMPARTIR:

 * Correo electrónico
 * 
 * 
 * Imprimir
 * Share
 * 

Me gusta Cargando...
Publicado en Abap, Formacion | Etiquetado Ayudas de busqueda,
DD_SHLP_CALL_FROM_DYNP, EWK1, F4, matchcode | Deja un comentario


TRUCO 122. ALGUNAS UTILIDADES PARA OBTENER INFORMACIÓN DE TABLAS.

Publicado el 9 noviembre, 2022 por Roberto Espinosa
i

3 Votes




En el trabajo día a día con Sap como consultor funcional o técnico, es
imprescindible tener un conocimiento mínimo del módelo de datos del sistema y
conocer las tablas más importantes y sus relaciones. Eso nos permite, por
ejemplo:

 * Obtener información de los datos maestros o documentos ante cualquier
   requerimiento.
 * Poder realizar comprobaciones de una forma rápida. Por ejemplo, despues de
   haber terminado unas cargas iniciales, comprobación de procesos de
   integración, analisis de incidencias, pruebas de nuevos desarrollos o cambios
   en la parametrización, etc.
 * Preparar especificaciones para los desarrolladores, donde indicamos que
   chequeos o condiciones se han de cumplir en un determinado desarrollo.
 * Conocer la lógica de funcionamiento de la aplicación y como los procesos
   funcionales se traducen en datos registrados en la base de datos.

En Intenert hay multitud de información sobre las tablas más importantes
existentes en cada módulo y podeís encontrar sin problema entradas donde se
enumeran con mayor o menor detalle las tablas de cada módulo o ambito funcional
especifico (por ejemplo, MM, SD, etc.).

Pero siempre es útil conocer algunos otros pequeños trucos que nos permitan
localizar las tablas estandar/Z u otros elementos, y que nos puedan sacar de
algún apuro. Aquí los dejo.

Transacción SE16T. Encontrar las tablas de aplicacion sin conocer nada del
sistema.

Hablamos hace tiempo de las nuevas transacciones SE16X y como utilizar la
transacción SE16T para buscar tablas en el sistema.

Básicamente, seleccionamos la función de búsqueda de tablas e indicamos el
concepto a buscar (pudiendo seleccionar búsqueda por texto o por nombres de
campo).

El sistema nos devuelve la lista de tablas que cumplen las condiciones.

Vista DD03VV. Localizar tablas por campos, elementos de datos o dominios.

La vista DD03VV ( Vista de campos tabla – Sistema Info ) nos permite realizar la
busqueda en el diccionario de datos por nombre de tabla, campo, elemento de
datos o dominio. Yo la suelo utilizar para buscar las tablas Z en un sistema o
localizar tablas de parametrización que se que utilizan un determinado elemento
de datos o dominio.

Podemos consultarla con la transacción SE16N. En mi ejemplo, estoy buscando
tablas Z que tengan el elemento de datos del centro (*WERK*). Es importante
indicar la clase de tabla del tipo TRANSP para limitar los resultados de
búsqueda a tablas de datos transparentes.

En los resultados obtengo toda la información para localizar las tablas que
estoy buscando. Posteriormente podré acceder a la SE11 para ver la definición de
las tablas y la lista completa de sus campos.

También puede ser interesante conocer la tabla DD03L, donde se guarda la
información de los campos que contienen una tabla.



Tabla TCDOB. Obtener el objeto del log de modificaciones de una tabla.

El log de modificaciones de una tabla nos permite registrar los cambios que se
realizan en los datos y luego poder consultarlos, normalmente desde las misma
funcionalidad, de forma que podemos ver quien realizo los cambios, cuales fueron
estos (valores anteriores/valores nuevos) y en que momento.

La información de modificaciones se registra en las tablas CDHDR y CDPOS. La
primera tabla contiene un número de documento de modificación, estando en la
CDPOS el detalle de los cambios, campo por campo. Los cambios se registran
usando un identificador de objeto (código que identifica su tipología), el valor
del objeto (el número del documento o datos maestro concreto) y un documento de
modificación.

Recordad que podemos activar el log de modificaciones de una tabla estandar o
una tabla Z desde las opciones técnicas en la transacción SE11 del diccionario
de datos (siempre con los pertinentes chequeos con el equipo de desarrollo o
basis para no provocar problemas de rendimiento en el sistema).

Cuando necesitamos obtener de forma másiva los cambios que se han realizado en
un objeto, los más complicado es localizar el nombre del objeto (campo
OBJECTCLAS), con el que se guardan los cambios en las tabla.

Para localizar este nombre de objeto, utilizaremos la tabla TCDOB, a través de
la SE16N.

En mi ejemplo, estoy localizando la clase de objeto con la que se guardan los
cambios en los Business Partners que creamos desde la transacción BP (tabla
BUT000).

El objeto con el que se guardaran los cambios en el log de modificaciones será
el BUPA_BUP. Con ese valor ya podremos atacar directamente las tablas para
obtener la información requerida y visualizar los cambios realizados en los
elementos objeto del análisis.



Obtener la vista de actualizacion para una tabla de parametrización.

Otra necesidad muy habitual es tener localizar las vistas de parametrización
asociadas a una tabla. Es decir, tenemos la tabla donde esta la parametrización,
pero no recordamos el lugar en la SPRO donde realizar los cambios.

Para esto, tenemos dos opciones desde la transacción SM30. Una vez en la
transacción, indicaremos el nombre de la tabla (en mi ejemplo, la tabla T001
Almacenes en Gestión de Materiales) y:

1) Customizing: realiza una búsqueda en la configuración de sistema y nos ofrece
una lista más o menos útil con los puntos de parametrización relacionados con la
tabla.

2) Buscar diálogo de búsqueda: nos devuelve la vista de actualización de la
tabla, que corresponden a los diferentes objetos de parametrización y que
podremos acceder directamente desde la SM30.





Encontrar las tablas que son llamadas en un programa.

En ocasiones la cosa se complica y necesitamos saber las tablas estandar o de
cliente que se utilizan en un determinado programa o transacción. En este caso,
tenemos disponibles varias alternativas para localizar las tablas implicadas.

La forma más completa de obtener información es realizar una traza SQL
utilizando la transacción ST05. Es importante activar la traza con la opción de
filtro, ya que podemos colapsar el sistema con la traza si no se limitan el
ámbito de este análisis.

En mi ejemplo, estoy haciendo la traza de un determinado usuario y con una
determinada transacción.

A continuación realizaremos el trabajo funcional con el usuario filtrado (hemos
accedido a consultar un pedido en la transacción ME22N y le hemos añadido una
posición).

Al finalizar, desactivaremos la traza y procederemos a consultar los resultados
de esta con la opción «Display Trace».

El sistema nos mostrará una lista de todas las tablas que ha ido leyendo durante
la ejecución del programa

Existe otra alternativa para realizar traza con la transacción ANST_SEARCH_TOOL.

Al ejecutar, el sistema nos llevará a la transacción elegida, donde realizaremos
la operativa deseada. Al concluir, volveremos a la ANST_SEARCH_TOOL, donde
podremos ver la lista de resultados.

Seleccionando la opción de Tables, podremos ver la lista de todas las tablas
utilizadas en la transacción, o solo las tablas de parametrización.

Encontrar las CDS asociadas a una tabla SAP.



Desde la transacción SE11, podremos localizar las CDS que se han creado
utilizando la tabla, con la opción «Referencia de utilización», seleccionado el
area de utilización «Data Definitions».

El sistema nos mostará la lista de DDL.

En el detalle podremos ver el nombre de la vista e información de su definición
(es aconsejable utilizar Eclipe para ver la información completa).

Bibliografia.



http://thinkdoforward.com/sap-s-hana-diesen-datenbankview-solltest-du-dir-merken-dd03vv/

https://blogs.sap.com/2020/07/15/how-to-find-sap-table-by-just-knowing-nothing-about-sap-its-true/

https://blogs.sap.com/2020/07/24/how-to-find-change-document-object-from-table-name/

https://blogs.sap.com/2014/01/17/find-changes-logs-for-a-table-using-sm30/

https://blogs.sap.com/2020/08/25/how-to-find-a-search-help-behind-a-transaction-code-in-sap/

https://blogs.sap.com/2020/07/15/in-sap-how-to-find-a-table-behind-a-transaction-code/


COMPARTIR:

 * Correo electrónico
 * 
 * 
 * Imprimir
 * Share
 * 

Me gusta Cargando...
Publicado en Abap, Formacion, S/4HANA, Sap Basis | Etiquetado ANST_SEARCH_TOOL,
CDHRD, CDPOS, DD03L, DD03VV, SE16T, ST05, TCDOB | 1 Comentario


TRUCO 121. AUDITORIA CON LA TRANSACCIÓN ST13.

Publicado el 3 noviembre, 2022 por Roberto Espinosa
i

4 Votes




Hemos conocido gracias a Diego Muñoz una interesante herramienta de auditoria,
que viene incluida en ST-A/PI (Servicetools for SAP Basis) y que podemos lanzar
desde la transacción ST13. Al parecer, es una herramienta interna de Sap,
relacionada con Solution Manager.

Básicamente, la herramienta dispone de una serie de informes predefinidos que
nos permiten analizar el uso de procesos de negocio en el sistema. En mi caso,
estoy en plenas pruebas funcionables de una migración de sistema a Rise Cloud
Private y me ha sido muy útil para validar las pruebas realizadas por los
usuarios en los diferentes módulos implantados y poder verificar los documentos
creados.

Otros posibles escenarios en los que nos podría venir bien la herramienta:

 * Verificación tras cargas iniciales de datos en un proyecto de implantación o
   un rollout.
 * Auditoria de procesos.
 * Verificación tras sesiones de formación o validaciones de nuevas
   funcionalidades o cambios en el sistema.
 * Tareas de mantenimiento regular (por ejemplo, control de rangos de números).

Algunas de las cosas que podemos analizar son (lo más destacado):

 * Compras: documentos/lineas de documento creadas, lineas de pedido sin flag de
   entrega completa o factura final, cambios en cabecera o posiciones de
   documentos, control de entrega temprano/tardio, lineas con cantidad recibida
   mayor que cantidad factura, pedidos sin referencia a contrato o documentos en
   un workflow activo/erroneo, uso de esquema de cálculo o condiciones de precio
   en documentos, etc.
 * Ventas: documentos/lineas de documento creadas, pedidos abiertos, porcentaje
   de pedidos abierto, documentos incompletos, pedidos retrasados, documentos
   con bloqueo de factura, documentos sin lineas, documentos modificados, uso de
   esquema de cálculo o condiciones de precio en documentos, etc.
 * Finanzas: numero de documentos contables creados, numero de posiciones
   creadas, cambios en documentos, documentos anulados, documentos contables por
   clase de documento o sociedad, partidas abiertos por cuenta de
   mayor/cliente/proveedor, documentos preliminares, activos sin
   contabilizaciones, documentos bloqueados para el pago, documentos sin metodo
   de pago, etc.
 * Logistic Execution: entregas entrantes/salida creadas, entregas pendientes,
   entregas incompletas, documentos de transporte creados o en un cierto estado,
   cambios en documentos, etc.
 * Maestros: cambios en el maestro de clientes o proveedores, uso de materiales,
   clientes o proveedores en documentos, alineación de la condición de pago en
   el maetro respecto a los documentos, etc.
 * ……

Estos son solo algunos de los report de analisis que tenemos disponibles, pero
como podeís ver, tenemos para analizar casi cualquier cosa que nos soliciten
relacionada con nuestros procesos de negocio. En muchos de los informes podremos
realizar filtros por fechas o por caracteristicas de los procesos de negocio
(unidades organizativas, clases de documento, usuario), teniendo incluso la
posibilidad de navegar a los documentos individuales o datos maestros.

Para utilizar la herramienta, accederemos a la transacción ST13, seleccionando
el conjunto de reports llamado TBI_REPORTS y ya estaremos en el menú donde
podremos realizar la auditoria en los diferentes módulos o procesos del sistema.

Tenemos areas de aplicación disponible en el monitor para todos los módulos y
ambitos funcionales de Sap. Podemos acceder a los reports seleccionando el
correspondiente Objeto de Monitorización, que corresponde a cada uno de los
reports individuales (tenemos disponibles casi mil).

O bien indicando el Area de Aplicación, y a continuación el correspondiente
report de análisis a traves de las llamadas Keyfigure, tal y como vemos en la
imagen.



Ejemplo de analisis. Posiciones de pedido de compra creados en un periodo.

Accedemos al area de aplicación Sourcing & Procurement y seleccionamos el
keyfigure 01 – Purchase order items created. En mi caso, quiero obtener las
lineas de pedido de compra creadas en los últimos 30 dias (también podriamos
indicar fechas).

 Procesamos y el sistema nos devuelve el total de posiciones creados, pudiendo
navegar a continuación a los documentos creados:

Ejemplo de análisis. Rangos de números que han superado un determinado
porcentaje de uso.

Para ello seleccionamos el area de aplicación Cross Application y el keyfigure
02 Max fill level for numer range interval. En mi caso, indico rangos de número
que superen un determinado porcentaje.

El sistema me devuelve aquellos rangos que han superado el porcentaje indicado.

Ejemplo de análisis. Documentos de ventas con bloqueo de factura.



Seleccionamos el area funcional Sales y el keyfigure 09 – Sales documentos with
billing block. En el ejemplo, indicamos documentos mas nuevos de 365 días. Y
obtenemos como resultado el total de documentos bloqueados para la facturación,
y en el detalle la información del documentos y sus status.

Ejemplo de análisis. Cambios en los datos de proveedores en un periodo.

En este caso, seleccionamos el area de aplicación Master Data Management y el
keyfigure Changes to Vendor Master, indicando una sociedad y 365 de periodo.

El sistema nos devuelve la lista de cambios (total) y el detalle de los campos
modificados (valor anterior/valor nuevo, campos modificado, fecha de la
modificación, usuario, etc).

Estos son solo algunos ejemplos de las cosas que podemos auditar con la
transacción ST13. Como mínimo, conocerla y tenerla en cuenta para esas
comprobaciones u obtenciones de información que a veces son tan tediosas, y para
las que tenemos que llegar a conocer la estructura de tablas de sap y el
diccionario de campos si no tuvieramos esta herramienta disponible.

Nota: en la misma transacción hay otros monitores interesantes. Nos ha llamado
la atención el llamado TABLE_ANALYSIS, que nos explica como usar Arghadip Kar en
los blogs de Sap, así como otro disponible para analizar cambios en los
programas Abap.



Bibliografía:

https://www.linkedin.com/posts/diego-mu%C3%B1oz-l%C3%B3pez-4a06a665_st13-activity-6955094048428687360-ZoPf?utm_source=share&utm_medium=member_desktop

https://blogs.sap.com/2020/08/22/how-to-do-table-counts-for-multiple-tables-at-one-go/

https://blogs.sap.com/2015/12/02/backoffice-tools-change-analysis-abap-in-st13/

2971611 – ST-A/PI 01U: Customizing error in «Purchase Orders» key figures (S/4
HANA)

2197502 – BPMon/BPA: How to test & execute data collection manually in ST13:
TBI_REPORTS

https://go.support.sap.com/kpicatalog/?sap-language=EN


COMPARTIR:

 * Correo electrónico
 * 
 * 
 * Imprimir
 * Share
 * 

Me gusta Cargando...
Publicado en Formacion, Productividad, Sap Basis | Etiquetado Audit, Auditoria,
ST-A/PI, ST13, tbi_reports | Deja un comentario


TRUCO 120. TRANSACCIONES PARA LA GESTIÓN DE IDOCS. NUEVO MONITOR WLF_IDOC, LA
«NAVAJA SUIZA» DE LOS IDOCS.

Publicado el 28 octubre, 2022 por Roberto Espinosa
i

7 Votes




En los últimos años, los Idocs me han perseguido por todos las empresas en las
que he trabajado. En un mundo cada vez más interconectado, los idocs son un
elemento fundamental para gestionar las comunicaciones de entrada / salida con
sistemas propios o externos, tales como:

 * Operadores logísticos: envio de pedidos, entregas, recepción del picking,
   documentos de transporte, etc.
 * Comunicaciones EDI: envio/recepcion de pedidos, entregas, confirmaciones de
   pedido, facturas. Para nuestra comunicaciones con clientes o proveedores.
 * Ecommerce: envio de materiales, precios, recepción de pedidos,
   confirmaciones, envio de albaranes, facturas, etc.
 * Portales internos: portales de comerciales, portales de proveedores, sistema
   CRM, etc.
 * Retail: integraciones con terminal punto de venta (POS), integraciones con
   sistema CAR, etc.
 * Distribución de datos maestros o documentos entre sistemas SAP (Ale).

Solo por poner algunos ejemplos.

Como la mayoria de vosotros conoceis, los Idocs son unos documentos electrónicos
intermedios que nos permiten realizar el intercambio de información, con una
estructura normalizada, que siempre incluye los siguientes elementos.

 * Registro de control: un unico registro donde se indica quien envia, el
   destinatario, tipo de mensaje, tipo base, puertas, etc.
 * Registros de datos: estructura jerarquica, con uno o varios registros, donde
   se detalla toda la información del documento. Podemos tener diferentes tipos
   de segmentos, cada uno con su estructura de datos y con repetición (por
   ejemplo, posiciones de un documento) y anidación de segmentos en forma
   jerarquica. Por ejemplo, una factura recibida de un proveedor, con sus
   diferentes segmentos de cabecera (fechas, interlocutores, identificadores de
   documentos) y detalle de posiciones.

 * Registros de estado: uno o varios registros en donde se historifican los
   diferentes estados por los que van pasando el idoc, pudiendo incluir
   informacion asociada a cada estado (log de errores, información de documentos
   creados, etc).



En un entorno así, con sistemas cada vez más interconectados, necesitamos
herramientas para poder monitorizar y gestionar los problemas más frecuentes que
se producen con los idocs. Hasta la fecha, y según la mania de cada uno,
utilizabamos las siguientes transacciones:

Monitor de Idoc. Transacción WE02

Es una de las transacciones más usadas por los consultores que gestionan idocs
(a mi personalmente me gusta más la BD87). Nos muestra los idocs seleccionados
organizados en carpetas según Entrada/Salida, Tipo de Mensaje y Status. Nos
permite de una forma más o menos rapida ver lo que se ha procesado
correctamente, lo que esta pendiente o lo que esta erroneo. Y desde allí
realizar el analisis de los sucedido.

Desde el monitor podemos acceder a los idocs individuales para visualizar o
modificarl si es necesario (desde el segmento de control o en un segmento de
datos, opción Registro de datos –> Visualizar/Modificar) o ver el contenido
completo del idoc con la opción Visualización de datos.

El monitor no permite relanzar el procesamiento de idocs erróneos, pero si nos
permite una opción muy interesante. Seleccionando un nodo, y con la opción Lista
de segmento especial, indicamos el segmento que queremos visualizar y nos
muestra el contenido de ese segmento en todos los idocs seleccionados.

Una opción muy interesante para analizar de una forma rápida el contenido de un
grupo de idocs o para realizar comprobaciones.

Monitor de Idoc. Transacción BD87.

Este monitor ha sido hasta hoy mi preferido. Basicamente, se diferencía de la
WE02 en la forma de mostrar la información y en las acciones que se pueden
realizar con los idocs.

A nivel de formato de visualización, me gusta que de un vistazo podemos ver lo
estados de los idocs, lo que ha ido bien, lo que esta pendiente o erroneo. De
una forma rápida.

Desde la visualización inicial podemos:

 * Realizar filtrado de los idocs.
 * Reprocesar los idocs erroneos o procesar idocs en estado inicial.
 * Navegar a la lista de idocs.

En este listado podremos acceder a los idocs individuales (y realizar las mismas
operaciones descritas en la WE02 a nivel de cada documenbto individual),
visualizar las vinculaciones (si un idoc ha creado un documento, desde aqui
podremos ver el numero de documento asociado y navegar hasta el), ver
información de status y el texto explicativo (interesante para ver el detalle de
los errores), etc.

Busqueda de contenido en idocs. Transacción WE09.

Pero que ocurre cuando necesitamos encontrar un idoc por su contenido. Podriamos
intentarlo con las tablas donde se guarda la información, que son las mismas
para todos los tipos de idocs ( EDID4 / EDIDC / EDIDS ). Pero tenemos otra
opción con la transacción WE09, donde podemos indicar uno o varios segmentos y
los valores a buscar en un campo determinado.

El monitor hace un barrido por los idocs que cumplan las condiciones de
seleccion generales indicadas y busca en sus segmentos los valores introducidos.

Desde la lista de resultados podremos navegar al idoc, modificarlo, ver su
contenido completo (igual que en la visualización individual de la WE02 o BD87).

Cambio estado de idocs. Report RC1_IDOC_SET_STATUS.

Cuando necesitemos cambiar el status de un idoc, por ejemplo para dar por
concluidos documentos erroneos o cuando necesitemos inicializar el estado de
alguno de ellos, podemos utilizar el report abap RC1_IDOC_SET_STATUS.

El report nos permite indicar uno o varios idocs a actualizar, el estado actual
y el estado destino, pudiendo realizar una ejecucion en test antes de hacerlo en
real.

Herramienta de test. Transacción WE19.

Esta herramienta es muy util cuando estamos montando una nueva integración
utilizando Idocs y queremos probar con datos «inventados». También nos puede
valer para replicar idocs erroneos y modificar su contenido. A diferencia de las
transacciones vistas hasta ahora, donde solo podiamos modificar el contenido de
los segmentos existentes, en la WE09 podemos añadir o quitar segmentos tambien,
lo que puede ser muy útil para solucionar determinados tipos de errores.

Indicaremos el idoc que queremos utilizar como modelo y realizaremos la edición
de los segmentos, modificando los valores en segmentos existentes, añadiendo o
quitando estos, copiando un segmento como un segmento nuevo, etc. Desde la misma
herramienta se puede lanzar la creación y el procesamiento del idoc editado al
sistema (tanto idocs de entrada como de salida al exterior).

Visualizar formato de idocs. Transacción WE30.

Esta es otra de mis favoritas, no orientada a monitorizar los idocs existentes,
pero si para obtener información de las estructuras de los diferentes tipos de
idocs que podemos gestionar en nuestro sistema.

En el ejemplo, el tipo base ORDERS05, que podremos utilizar tanto para enviar
pedidos a nuestros proveedores, como para recibir pedidos de nuestros clientes.

La transacción nos muestra la estructura del idoc, con sus diferentes segmentos,
la jerarquia de ellos y los campos componentes de cada segmento si vamos
navegado en el arbol.

Documentacion de Idocs. Transacción WE60.

Con esta utilidad podemos obtener documentación referente a los idocs en
diferentes formatos como HTML, XML, DTD o C. Muy util cuando tenemos que pasar
documentación «a la otra parte» de la información que le vamos a enviar a través
d elos idocs.

Transacción WLF_IDOC.

Gracias a Isa Bodur hemos conocido la transacción WLF_IDOC, la verdadera navaja
suiza de los idocs, donde vamos a poder hacer casi todo lo que hemos descrito
anteriormente desde un único lugar. El monitor fue introducido por Sap hace ya
algún tiempo (EhP5 SP10 / EhP6 SP07), yo al menos lo he conocido recientemente.

Esta nueva transacción dispone de una pantalla inicial de selección con
diferentes pestañas, incluyendo los criterios habituales de selección (fecha con
la opción de mayor o igual, hora, tipo de mensaje, interlocutores, status,
usuario, etc), mas la búsqueda por el contenido de los idocs (como la WE09), con
ademas la opción de sustituir valores (ojo a esta opción).

Incluye un modo supervisión que nos permite planificar un job para realizar
chequeos relacionados al procesamiento de los idocs. También nos permite, usando
la ultima pestaña de los criterios de selección programar el procesamiento en
segundo plano para procesar IDocs con el estado 30 (saliente) o 64 (entrante).

Una vez ejecutado el informe, nos aparecerá un informe ALV con toda la
información posible de los idocs que cumplan los criterios de selección (tenemos
disponibles todos los campos relacionados con un idoc).

Opciones de navegación.

Desde la lista de resultados, podremos:

 * Tenemos disponibles todas las opciones clásicas de un informe ALV: filtros,
   ordenación, exportación a excel, envio de email, gestión de variantes, etc.
 * Visualización del contenido del IDOC, es un formato mucho mas amigable que
   las transacciones clásicas. Se muestran tres secciones con la lista de los
   segmentos, el resumen de status con toda la información y el detalle de
   campos del segmento seleccionado.

Al seleccionar un segmento en la parte izquierda, en la parte derecha inferior
veremos todos los segmentos del mismo tipo (por ejemplo, posiciones de un
documento). Esta opción es super útil para poder ver todos los nodos que se
repiten en diferentes posiciones del documento.

 * Acceso a la visualización clasica del idoc, haciendo doble click en el
   Status. Desde esta opción tenemos disponible la modificación del segmento de
   cabecera o de los segmentos de datos, tal y como teniamos en la WE02/BD87.

 * Visualización del log de aplicación, en el caso de que exista uno relacionado
   con el procesamiento del idoc (como si llamaramos a la transacción SLG1).

 * Visualización de documentos enlazados: podremos obtener los enlaces a otros
   idocs, datos maestros o documentos creados en el sistema, incluyendo la
   navegación a ellos con doble clic.

 * Navegación al formato del Idoc (como si entraramos a la transacción WE30),
   desde la columna Tipo Base.
 * Navegación a los acuerdos de interlocutor, puertas, etc utilizados en cada
   uno de los idocs.

Ademas de todo esto, tenemos disponibles las siguientes opciones de tratamiento:

 * Modificación del idoc: Si hemos completado la parametrización que permite
   modificar los segmentos o campos del idoc, podremos realizar la modificación
   directamente de los campos en el visor de los segmentos (sin necesidad de
   realizar la tediosa navegación segmento por segmento que realizabamos en la
   WE02/BD87).

 * Procesamiento del idoc: la misma opción que tenemos disponible en la BD87,
   teniendo disponibles tres modos de ejecución.

 * Cambio de vista de visualización, pudiendo pasar, para los idocs
   seleccionados en el alv, a una visualización similar a la WE02.

 * Enviar Idoc via RFC: nos permite enviar un idoc a otro sistema, indicando una
   conexión Rfc. Muy util para pasar idocs de un sistema productivo a un sistema
   de desarrollo, por ejemplo.
 * Comparación de dos idocs: podemos seleccionar dos idocs del mismo tipo y el
   sistema nos hace una verificación segmento por segmento, indicando los
   valores diferentes.

 * Modificación del registro de control del idoc: como indicamos más adelante,
   esta opción solo esta disponible en el modo experto. Pero es una forma mucho
   más rapida de modificar el segmento de control que la que tenemos ahora en la
   WE02/BD87.

 * Copiar idoc y borrar un segmento: podemos crear un idoc nuevo, borrando un
   segmento definido.
 * Modificación del status del idoc: como si realizaramos la ejecución del
   report RC1_IDOC_SET_STATUS. La modificación se puede realizar a uno o varios
   documentos seleccionados.

A tener en cuenta.

En un sistema productivo (mandante marcado como tal en la transacción SCC4),
alguna de las funciones de la WLF_IDOC estan restringidas. En concreto:

 * Cambio del registro de cabecera de los idocs.
 * Cambio del status de idocs.
 * Copiar un idoc y borrar un segmento.

En ese caso, para perfiles de usuario avanzados, podemos hacer disponibles estas
opciones con el parametro WLFIDOC_NEW_EXPERT = X. Al modo experto se accede
ejecutando la funcion &EXPERT una vez estamos en la transacción.

Además, hay un tema importante respecto a la modificación de los idocs. Al
contrario de la WE02 / BD87, donde podiamos modificar cualquier segmento de un
documento, en la transacción WLF_IDOC tendremos que parametrizar que segmentos y
que campos son modificables desde la transacción (si queremos realizar la
modificación directamente en el visor de idocs).

La parametrización de modificación se encuentra en la SPRO, ruta Componentes
Multiaplicaciones –> Monitor Idoc –> Especificar parametrizaciones de
actualización de Idoc. Podemos indicar por tipo de mensaje, los segmentos
editables (se podrá indicar que se pueden modificar todos los campos de un
segmento o enumerar los campos editables).

Si no queremos realizar esta configuración, podremos realizar también la
modificación del idoc navegado a la visualización clásica de los idocs (tal y
como hemos indicado) o cambiando a la vistas clasicas desde la WLF_IDOC.

Ha sido una grata sorpresa descubrir esta transacción y poder, por fin, hacer
todo desde el mismo sitio y de una forma mucho más sencilla y completa.
¡¡¡Felicidades Sap!!!

Bibliografia:

WLF_IDOC: Die Zauber-IDoc-Transaktion, die die WE02, WE09 und BD87 alt aussehen
lässt.

> Swiss knife for idocs: WLF_IDOC transaction





COMPARTIR:

 * Correo electrónico
 * 
 * 
 * Imprimir
 * Share
 * 

Me gusta Cargando...
Publicado en Formacion, Productividad, S/4HANA, Sap Basis | Etiquetado BD87,
IDOC, RC1_IDOC_SET_STATUS, WE02, WE09, WE19, WE80, WLFIDOC_NEW_EXPERT, WLF_IDOC
| 4 comentarios


TRUCO 119. GESTIÓN DE JOBS TÉCNICOS CON LA TRANSACCIÓN SJOBREPO.

Publicado el 20 octubre, 2022 por Roberto Espinosa
i

3 Votes




Seguimos descubriendo las novedades que nos trae S/4HANA en lo referente a la
gestión de Jobs, en este caso, los jobs técnicos que estan presentes en
cualquier instalación Sap y que son fundamentales para un correcto
funcionamiento del sistema.

En las versiones anteriores, la gestión de los jobs técnicos la realizaban los
consultores de Basis desde la transacción SM36, utilizando la opción Jobs
estandar, donde iban realizando la planificación de los diferentes procesos
técnicos de administración del sistema.

Sap nos indica en la nota 16083 – Standard jobs, reorganization jobs, alguno de
los reports recomendados para estas tareas. Por ejemplo, tenemos tareas para la
reorganización de jobs, de ordenes de spool o batch inputs, recolectores de
estadísticas, workflows, etc. Dentro de las tareas de configuración de un
sistema nuevo o de mantenbimiento de uno existente, estos jobs han de estar
correctamente planificados para que el entorno funcione sin problemas.

Teniendo en cuenta lo descrito por Sap en esta nota (y otras notas relacionadas
que la actualizan o los componentes que estamos utilizando en nuestro sistema),
el consultor BC realizaba la configuración de los jobs en el mandante
correspondiente y con la frecuencia recomendada por Sap segun la tipologia de
cada proceso.

Asi, por ejemplo, en mi sistema tengo un proceso diario que ejecuta el report
RSPO0041 que borra las ordenes de spool mayores de 30 dias. Esto permite liberar
espacio en la base de datos y que tablas donde se guarda esta información no
tengan un crecimiento demasiado grande.

Cambios en S/4 HANA

A raiz de lanzamiento de los productos S4/Hana Cloud, Sap desarrollo una
herramienta para la ejecución de los jobs técnicos, de una forma automatizada,
sin necesidad de la intervención externa de un administrador. Dada la utilidad
de esta herramienta, Sap decidio liberarla también a los sistema On-Premise,
donde la tenemos disponible.

Podemos acceder a la herramienta desde la SM36, opción Repository de Jobs. O
bien directamente desde la transacción SJOBREPO. Al entrar en esta opción,
podemos observar un monitor donde hay un repositorio con todos los jobs técnicos
e información del estado de planificación de los procesos en nuestro sistema.

Estas definiciones de los jobs ha sido creadas por los desarrolladores de Sap
como objetos de workbench del tipo R3TR JOBD (ver nota 2581518). Ademas,
podremos crear nuestras propias definiciones de jobs utilizando un namespace de
cliente sin ningún problema.

Desde el monitor podremos realizar tareas como:

 * Visualizar los jobs activos en un momento determinado.
 * Visualizar los atributos de los diferentes jobs técnicos: programa y variante
   de ejecución, frecuencia y recurrencia, etc. No se deberían de realizar
   cambios en estos valores, ya que al tratarse de un objeto de desarrollo,
   estaríamos tocando un objeto Sap (modificación del estandar). Para ver la
   documentación asociada a un job, entraremos en el detalle, seleccionando la
   opción Goto -> Documentation.

 * Activar / Desactivar localmente los jobs, sobreescribiendo la configuración
   por defecto.
 * Cambio de los parametros de frecuencia de ejecución de los jobs.

 * Visualización de estadísticas de ejecución de los jobs.

Se podrá igualmente cambiar el usuario que se utiliza en la planificación de los
pasos de los jobs con la transacción SJOBREPO_STEPUSER o desde el mismo monitor.
Por defecto se utiliza el usuario SAP_SYSTEM (si no existiera en el mandante, se
usaría el usuario DDIC).

El job R_JR_BTCJOBS_GENERATOR se ejecuta periodicamente y se encarga de realizar
la revisión y planificación de los jobs existentes en el monitor (usando como
tiempo de frecuencia de ejecución el parámetro del sistema
rdisp/job_repo_activate_time, que normalmente son 60 minutos ).

Con el report R_JR_UTIL_1 podremos ver el estado del monitor y realizar cambios
en el.

En la nota 2190119 – Background information about SAP S/4HANA technical job
repository tenemos un documento donde se explican en detalle algunas de las
opciones del nuevo monitor.

Nota: si se quiere cancelar la planificación de un job técnico, no será
suficiente con hacerlo desde la transacción SM37, también habrá que hacerlo en
la SJOBREPO. Si no lo hicieramos, el job R_JR_BTCJOBS_GENERATOR volvería a
planificarlo en su próxima ejecución.

Si quisieramos crear la definición de un job técnico propio, o cambiar la
variante estandar asociada un job de sistema, crearemos nuestras propias
definiciones de Job en un rango de nombres de cliente usando la SE80.

En la nota 3236399 – FAQ – Technical Job Repository (SJOBREPO) estan las
referencias a las diferentes notas en las que se enumeran los jobs técnicos
disponibles según la versión de Sap en la que nos encontremos. Es importante,
pues según la versión de S4 se van modificando los elementos disponibles.

Bibliografia.

https://xiting.com/en/transaction-sjobrepo-the-new-sap-s4hana-technical-job-repository/

Batch jobs tips & tricks: www.saptechnicalguru.com/batchjobs/

Activación del monitor: https://itsiti.com/how-to-activate-sjobrepo-in-s-4hana/

> S4HANA standard batch jobs

https://blogs.sap.com/2015/12/22/bye-bye-standart-jobs-function/

https://blogs.sap.com/2017/10/17/implementing-technical-jobs-in-s4hana/

Notas OSS:

16083 – Standard jobs, reorganization jobs

2190119 – Background information about SAP S/4HANA technical job repository

2744380 – Technical Job Repository: Using a different report variant for job
scheduling

2581518 – Jobs in the Technical Job Repository (SJOBREPO)

2731999 – Assign custom step user for Technical Job Repository (SJOBREPO)

2499529 – Disable / Enable Job Repository scheduler

3236399 – FAQ – Technical Job Repository (SJOBREPO)

Videos:






COMPARTIR:

 * Correo electrónico
 * 
 * 
 * Imprimir
 * Share
 * 

Me gusta Cargando...
Publicado en Formacion, S/4HANA, Sap Basis | Etiquetado R_JR_BTCJOBS_GENERATOR,
R_JR_UTIL_1, SJOBREPO, SJOBREPO_STEPUSER, SM36, SM37 | Deja un comentario


TRUCO 118. GESTION DE JOBS CON APLICACIONES FIORI.

Publicado el 14 octubre, 2022 por Roberto Espinosa
i

3 Votes




Seguimos revisando los cambios que tenemos disponibles en S/4HANA y nos
encontramos con alguna novedad en lo que respecta a la gestión de los Jobs.

Anteriormente, planificabamos nuestros jobs desde los reports en el momento de
su ejecución o utilizando la transacción SM36. Posteriormente, podiamos
consultar su estado de ejecución, resultados o logs desde la clásica SM37,
pudiendo realizar también cambios en su planificación o pasos desde este mismo
lugar. Estas transacciones podemos seguir utilizandolas, tanto si utilizamos Sap
Logon, Netweaver o desde Fiori.

Pero tenemos algunas novedades al respecto. Ahora en Fiori disponemos de varias
aplicaciones para realizar las gestion de los jobs:

 * Application Jobs: nos permite realizar todas las tareas de consulta de los
   logs de ejecución de los jobs, spools asociados si existen y los estados de
   los trabajos. Aquí no veremos los jobs planificados desde la SM36/SM37.

Desde la misma aplicación podemos ver el detalle de los pasos de cada job y sus
parámetros de ejecución. En la imagen podeis ver un ejemplo de un job de
creación de facturas de ventas.

Igualmente, desde aquí podremos realizar la creación de nuevos jobs. A
diferencia a la SM36, solo podremos utilizar las plantillas de jobs que hayamos
definido previamente, como veremos a continuación.

Podeís ver la información de la app Fiori en este link.

 * Application Jobs Template: nos permite realizar la definición de las
   plantillas de jobs que luego podremos utilizar en la aplicación Application
   Jobs. Información de la app Fiori aquí.

En la aplicación veremos los template de jobs del tipo Global, que no podremos
modificar, y que se definen en la transacción SAPJ, que explicaremos a
continuación.

Los template que creemos directamente desde esta transacción tendran el origen
del tipo Compartido o Privado (indica que lo podrán utilizar todos los usuarios
o solo el usuario que lo haya creado), pero siempre tendrán que utilizar un «Job
Catalog» para definir los diferentes pasos de la plantilla de job. Esos tipos de
Job se definen igualmente en la transacción SAPJ.

 * Transacción SAPJ: es la transacción central de configuración de los tipos de
   jobs que vamos a poder planificar en las apps descritas. Sap nos entrega un
   catalogo de jobs predefinido, aunque podremos crear nuestras propias
   entradas, incluso para jobs sobre desarrollos Z.

En esta transacción, ademas de añadir las Entradas de Catálogo, también podremos
crear los Template de jobs del tipo Global que usaremos en la definición de los
jobs, como hemos visto antes.

Por ejemplo, tenemos una entrada del Catalogo de Jobs para lanzar la facturación
de ventas llamado BILLING_DOCUMENT_RUN.

En la definición del catalogos definiremos los parametros que se podran indicar
en la ejecución del proceso y que estaran del programa o clase como parametros
de entrada.

En los blogs de Sap, Vijay Chintarlapalli nos explica paso a paso todo lo
necesario para definir una nueva entrada del catálogo. Puede ser útil analizar
con un abaper como estan creados los programas de otras entradas para definir
los jobs de nuestros propios desarrollos.

Una vez creado el Catalogo, se definirá la correspondiente Plantilla o Template.
En la imagen el template para el job de creación de facturas
(BILLING_DOCUMENT_RUN).

Estas plantillas o las creadas desde la app Application Jobs Template serán las
que nos permitan realizar la planificación de los Jobs.

Tenemos disponibles por Estandar cientos de Templates para la realización de
todo tipo de procesos, especialmente en el módulo de Finanzas. Por ejemplo,
ejecución de amortización de activos fijos, compensación, cambio de periodos,
procesos de facturación o impresión de facturas, etc.

Nota: los jobs planificados desde la nueva App de Fiori si son visibles en la
transacción SM37, pero desde allí no se puede realizar ninguna modificación del
job.

Las aplicaciones, tal y como se indica en la documentación de Fiori, están
disponibles en el catalogo SAP_BASIS_TCR_T.

Ejemplo práctico: Creación de un job de Amortización de Activos Fijos

Accederemos a la aplicación Application Jobs y pulsaremos el icono para crear un
nuevo proceso en fondo.

1) En primer lugar introduciremos la Plantilla de Job a utilizar, dentro del
catalogo disponible en el sistema. En nuestro caso, seleccionamos
Contabilización de amortizaciones. Tenemos disponible un buscador para localizar
la plantilla deseada.

2) Indicaremos un nombre al job.

3) Opciones de planificación: si es una ejecución puntual o periodica. En el
caso de ejecución periódico, los valores de periodo.

4) Parametros de ejecución del proceso: en nuestro ejemplo, la sociedad,
ejercicio, periodo y tipo de ejecución (test en este caso).

Realizamos la planificación del job y analizamos los resultados de su ejecución.

Igualmente hemos podido observar que hay diferentes aplicaciones predefinidas en
Fiori, sobre todo en Finanzas, que llaman a la app Application Jobs, pasandole
como parametros el o los templates que se podrán utilizar para la planificación
de los trabajos.

Como veis, van cambiando cosas en nuestro sistema SAP y conviene estar al tanto
para poder gestionarlo. Todo pinta a que estamos en una transición que ira
cambiando el modelo anterior hacia un funcionamiento como el que hemos explicado
en este post. Vamos a una herramienta donde no hay que conocer los nombres de
los programas y sus programas para planificar los jobs, sino un catalogo de
tareas bien definida que podemos planificar desde la herramienta, en la que los
usuarios podrán ser autonomos de los usuarios técnicos.

¿Que pensais vosotros?

Bibliografía:

Activate Job Template in S4 Hana

https://blogs.sap.com/2019/07/06/s4-hana-schedule-and-monitor-application-related-jobs./

Ayuda de SAP: Defining Job Catalog Entries in ABAP

2947448 – Scheduling a Background job for a Fiori-based app

https://answers.sap.com/questions/669356/how-to-activate-job-template-to-fiori-app-in-s4-ha.html


COMPARTIR:

 * Correo electrónico
 * 
 * 
 * Imprimir
 * Share
 * 

Me gusta Cargando...
Publicado en Formacion, S/4HANA, Sap Basis | Etiquetado Application Job
Template, Application Jobs, SAPJ, SM36, SM37 | Deja un comentario


TRUCO 117. CAMBIO DE PERIODOS CONTABLES DE FORMA AUTOMÁTICA.

Publicado el 7 octubre, 2022 por Roberto Espinosa
i

7 Votes




En nuestro sistema SAP podemos gestionar varios tipos de periodos abiertos, que
son los que nos permiten realizar operaciones en unas fechas determinadas, no
pudiendo realizar contabilizaciones fuera de los periodos que están habilitados.
Mas concretamente, tenemos tres tipos de periodos:

 * Periodos logísticos: se gestionan, a nivel de sociedad, con la transacción
   MMPV y nos permiten contabilizar los movimientos relacionados con gestión de
   stocks, registro de facturas de compras (MIRO), valoración de materiales,
   etc. Solo es posible contabilizar en una rango de dos periodos (meses),
   normalmente el mes en curso y el mes anterior. Con la transacción OMSY se
   pueden consultar los periodos actualmente abiertos en cada sociedad.

 * Periodos contables (FI): se gestionan, a nivel de variante de periodos
   contables, con la transacción OB52. Podemos tener una o varias sociedades
   asignada a una variante de periodos contables. El control se puede realizar
   por tipologia de cuentas (Deudor, Acreedor, Activos, Cuentas de Mayor,
   Cuentas de Material), teniendo la posibilidad de gestionar periodos para los
   usuarios normales o para usuarios administradores mediante autorizaciones
   (hablamos de ello en una entrada anterior del blog).

 * Periodos controlling: se gestionan con la transacción OKP1, a nivel de
   sociedad de Controlling, Ejercicio, Periodo, Versión y Tipo de
   contabilización (Real o Plan). En esos niveles, podemos indicar para los
   diferentes tipos de operaciones, si esta permitido o no el realizar
   contabilizaciones en la contabilidad de costes.

En condiciones normales, un usuario avanzado se encarga de gestionar los
periodos y de realizar la apertura y cierre de cada uno de ellos. Por ejemplo,
es habitual en la gestión de periodos contables de FI, el restringir la
contabilización en las cuentas de IVA para evitar contabilizaciones en periodos
ya reportados a las autoridades, tal y como vemos en la imagen siguiente.

Nota aclaratoria: la gestión de los periodos contables va relacionada con el
ejercicio fiscal que gestione la empresa, no teniendo porque coincidir con el
año natural (según el sector, puede haber ejercicios que van de febrero a enero,
abril a marzo, etc).

¿Como automatizamos el cambio de ejercicio?

Periodos Logísticos

Para los periodos lógisticos, es tan sencillo como como utilizar el report
RMMMPERI, que es el que se llama cuando ejecutamos la transacción MMPV. En este
report podemos introducir la sociedad para la que queremos realizar el cambio y
el periodo a entrar. Aunque tenemos una opción mucho más flexible, introduciendo
la fecha del periodo que queremos abrir (lo que nos evita tener que conocer la
configuración de periodos fiscales del sistema). De esta forma, indicando la
fecha del primer dia del mes del nuevo periodo, el sistema hará el cambio sin
ninguna complicación.

Para ello, crearemos un job con la transacción SM36, indicando al job una
periodicidad mensual, con ejecución el primer día de cada mes (por ejemplo, a
las 00:01 de la madrugada).

Añadiremos un paso con el programa RMMMPERI, donde habremos creado una variante
con los parametros correspondientes (sociedad, diferentes flags marcados, etc) y
para el campo de la fecha, utilizaremos una variable dinámica del tipo Fecha del
día.

De esta forma, el proceso se ejecutará el día 1 de cada mes (por la periodicidad
del job), y se abrirá el periodo lógístico correspondiente a ese dia por la
variable dinamica indicada en la variante del job. Con la transacción SE38
podemos mantener las variantes asociadas al programa y realizar la configuración
deseada de los parametros de ejecución de este.

Como indicabamos antes, con la transacción OMSY podremos comprobar que el cambio
se haya realizado correctamente.

Periodos contables

Para realizar el cambio de los periodos contables, podremos utilizar los reports
RFPERIOD_OPEN y RFPERIOD_CLOSE. En este caso, podremos utilizar igualmente un
job para planificar el cambio, pero la cuestión es un poco más complicada, pues
tenemos que indicar los valores de año y periodo, y no tenemos variables
dinámicas disponibles para poder hacerlo.

En ese caso, tendriamos varias opciones para automatizar el proceso:

 * Desarrollo a medida que cree el job correspondiente llamando al programa
   RFPERIOD_OPEN, llenando los parametros de selección con los valores
   necesarios para realizar la apertura o cierre de los periodos. En la lógica
   del programa podremos tener en cuenta la sociedad, que ejercicio fiscal
   tiene, etc, para poder enviar los valores correctos para realizar el cambio.
 * Planificar un job, usando las variables que tiene Sap definidas en las tablas
   TVARV/TVARVC. Estas variables se actualizan ejecutando el programa RVSETDAT o
   manualmente con las transacciones STVARV o STVARVC. Aquí podriamos añadir
   nuestras propias variables Z y actualizarlas con un programa Z o manualmente,
   con la lógica deseada.

Primero actualizariamos las variables y luego planificariamos un job, indicando
en la variante del report RFPERIOD_OPEN, las variables para el ejercicio/s y
periodo/s a abrir o cerrar.

Un poco más complejo pero tenemos una solución más o menos sencilla para
realizar el proceso.

Periodos de controlling

Para realizar el cambio de los periodos de controlling, utilizaremos el report
RKCOOKP1. La problemática es la misma que la descrita en el punto anterior, así
que podremos utilizar la misma solución para indicar los periodos que vayamos a
abrir o cerrar usando las variables de sistema o un desarrollo a medida.

Y siempre teniendo en cuenta las implicaciones de esta configuración y que ha de
ser consensuada y gestionada con los departamentos financieros o de controlling.

Os recomiendo la lectura del documento de Sanjeev Kumar donde se explica en
detalle todos los pasos para realizar la automatización que acabamos de
describir.

Espero os sea de utilidad. Encantado de volver a publicar en el blog despues de
tanto tiempo.

Bibliografía.

Automate Period opening in SAP – Sanjeev Kumar

Gestion de dos periodos contables abiertos en Finanzas

 


COMPARTIR:

 * Correo electrónico
 * 
 * 
 * Imprimir
 * Share
 * 

Me gusta Cargando...
Publicado en Formacion, Sap FI, SAP MM | Etiquetado MMPV, ob52, OKP1, Periodos
contables, Posting Periods, RFPERIOD_CLOSE, RFPERIOD_OPEN | 2 comentarios


TRUCO 116. NAVEGACIÓN EN EL FLUJO DE DOCUMENTOS DE VENTA EN S/4HANA.

Publicado el 28 febrero, 2021 por Roberto Espinosa
i

37 Votes




Hoy os voy a explicar un truco muy rápido que he conocido gracias a Isa Bodur
(os recomiendo la lectura de su blog llamado thinkdoforward.com ).

Hace algún tiempo hablamos en el blog sobre el flujo de documentos en ventas,
las opciones de parametrización y como podíamos utilizar la transacción IW72
para consultarlo para varios documentos a la vez.



Pero vayamos al grano. Una de las cosas más incomodas cuando estamos consultando
este historial es la forma de navegar por los documentos. 



En primer lugar, hay que posicionarse en la linea a la que queremos navegar (por
ejemplo, la factura). Y a continuación pulsar la opción «Visualizar documento»
para que Sap nos lleve al correspondiente documento (pedido, entrega, factura,
documento de material, etc).

Pues después de tantos años, alguien debió de darse cuenta de esto y ahora
tenemos  la opción de una navegación inmediata haciendo doble clic en la linea
correspondiente. Para ello, basta con incluir el parámetro DOCFLOW_DCLICK_NAVI
con el valor X en los datos de cada usuario el sistema.



La opción esta disponible desde 2018 (consultar la nota 2631700, tanto en R3
como en S/4HANA).

Ademas, hay más buenas noticias. Tenemos otros parámetros interesantes que nos
van a facilitar la vida y nos permiten:

 * Transacción VA05/VF05/VF15…: cuando hacemos doble clic y navegamos a las
   documentos, lo hacemos en modo modificación. Con el parámetro
   DISPLAY_SDOC_RE_NAVI podemos forzar a la que navegación sea en modo
   visualización (ver nota 2761156 ).



 * Transacciones VF01/VF02/VF03: con el parámetro VF_PREVIEW podemos hacer que
   aparezca un botón que nos permite realizar la visualización de los mensajes
   asociados a la factura ( ver nota 2633052 ). Esto es una gran ayuda de cara a
   realizar la impresión de mensajes o simplemente la visualización previa.



 * Transacción VFX3: con el parametro VFX3_ENH_VKO permitimos la selección por
   varias organizaciones de ventas en la liberación de facturas para
   contabilidad (ver nota 2663048).
 * Transacción VF04: con el parámetro VF04_ENH ampliamos los criterios de
   selección en el pool de facturación teniendo disponibles los campos Oficina
   de Ventas y Creado por (ver nota 2658557).
 * Transacción VF04: con el parametro VF04_SEL podemos predefinir por usuario
   las clases de factura que se van a tratar en el pool de facturación (ver nota
   2650026).

Nota: es posible que según el nivel de Hot Packages de nuestro sistema estas
opciones no estén disponibles o en otros casos sean enhacements que haya que
activar aplicando la correspondiente nota. Os recomiendo la lectura de detallada
de las notas asociadas a cada parámetro para ver en que versión están
disponibles o cuales son los pasos para activarlos.

Igualmente, os recomiendo la lectura del blog dan852.com donde nos explican
otros parámetros relevantes en el módulo de ventas.


BIBLIOGRAFIA.

https://www.dan852.com/overview-available-user-parameters-sap-sd/

https://saptricks.wordpress.com/2016/02/21/truco-78-flujo-de-documentos-en-ventas/



> S/4HANA SD-Belegfluss – Jahrzehntelange Lücke endlich geschlossen



 


COMPARTIR:

 * Correo electrónico
 * 
 * 
 * Imprimir
 * Share
 * 

Me gusta Cargando...
Publicado en Formacion, S/4HANA, Sap SD | Etiquetado Document FLow, Flujo
documento, SD | 2 comentarios
← Entradas anteriores

Entradas anteriores


 * ESTADÍSTICAS DEL BLOG
   
   * 5.785.410 visitas


 * BÚSQUEDA DE ENTRADAS
   
   Buscar:


 * NUESTRO LEMA
   
   "Me lo contaron y lo olvidé; lo vi y lo entendí; lo hice y lo aprendí"
   (Confucio)
   


 * AYUDANOS A MEJORAR
   
   Todos los contenidos de este blog se elaboran de forma gratuita y
   desinteresada. Ayudanos con tu aportación a mejorar el sitio y los contenidos
   que ofrecemos.
   
   
   


 * SUSCRIPCIÓN POR CORREO ELECTRÓNICO
   
   Dirección de correo electrónico:
   
   Sign me up!
   
   Únete a otros 3.665 suscriptores


 * BLOGROLL
   
   * Abap Lovers
   * ABAP PERS – Eduardo Puricelli
   * ABAP TIP & TRICKS – Daniel Paramo
   * ABAP.ES
   * ADMINISTRACION SAP
   * Antonio de Ancos – Consultor de sentido comun
   * BLOG de SAP – Oscar Arranz
   * Blog de SD – Seisc1
   * Blogs de Sap
   * Codigo de Retorno: Programacion en SAP
   * Consultoria Sap
   * DATAPRIX: Knowledge is the goal
   * Desarrollo en Sap – Borja Garcia
   * ERP DB
   * ERP Genie
   * FOROSAP.COM
   * Hablamos de Sap – Entrevistas con gente del mundo SAP
   * Inside Sap
   * Learn Sap Tips – Anupa Wijesinghe
   * Mis Cosas de Abap y Sap
   * MUNDOSAP.COM
   * MYSAPBASIS
   * Ramgv Sap
   * REPORTS OVERVIEW
   * SAP Abap Help
   * Sap Basis Cafe
   * SAP Brains Online
   * SAP Dev
   * Sap Docs
   * Sap España (Orekait): Tutoriales en Español
   * SAP Techies
   * Sap Technical Guru
   * Sap Training Hub
   * Sapfans
   * SAPPROGRAMS
   * SDN SAP
   * SEARCHSAP.COM
   * Setevalapinsap.com
   * Teknoda Sap Tips – Abap
   * thinkdoforward.com – Isa Bodur
   * TODO SAP
   * Wiki SAP
   * Workflow (Abapguides)


 * CATEGORIAS
   
   * Abap (28)
   * Autorizaciones (7)
   * Estadisticas (1)
   * Formacion (97)
   * Gestion de proyectos (2)
   * Humor (1)
   * Opinion. (1)
   * Productividad (8)
   * S/4HANA (11)
   * S4/HANA (1)
   * Sap Basis (65)
   * Sap CO (5)
   * Sap CRM (1)
   * Sap FI (17)
   * Sap HR (7)
   * SAP MM (57)
   * Sap PP (1)
   * Sap SD (32)


 * POSTS MÁS VISTOS
   
   * MM
   * Crear estrategias de liberación en pedidos de compras
   * User-exits, ampliaciones, badis,...: como localizarlas (II).
   * Truco 103. Obtener valores de clasificación de objetos en SAP.
   * Truco 120. Transacciones para la gestión de IDOCs. Nuevo monitor WLF_IDOC,
     la "navaja suiza" de los Idocs.
   * Truco 111. Bloqueo de entrega / factura en pedidos. Desactivar la
     modificación del bloqueo mediante autorizaciones.
   * Truco 122. Algunas utilidades para obtener información de tablas.
   * Truco 78. Flujo de documentos en ventas.
   * Truco 74. Informe de Stock a una fecha (MB5B). Grupos de clases de
     movimiento.
   * Empezando con S/4HANA. Business Partner (BP).


 * ARCHIVOS
   
   Archivos Elegir el mes noviembre 2023  (1) diciembre 2022  (1) noviembre 2022
    (3) octubre 2022  (4) febrero 2021  (3) enero 2021  (2) May 2020  (1) abril
   2020  (3) marzo 2020  (2) May 2019  (3) abril 2019  (3) marzo 2019  (4)
   diciembre 2018  (1) octubre 2018  (2) febrero 2018  (1) diciembre 2017  (1)
   agosto 2017  (3) junio 2017  (1) enero 2017  (3) agosto 2016  (3) junio 2016
    (3) febrero 2016  (3) enero 2016  (3) diciembre 2015  (1) May 2015  (1)
   marzo 2015  (2) febrero 2015  (1) diciembre 2014  (1) agosto 2014  (1) julio
   2014  (5) febrero 2014  (2) enero 2014  (3) diciembre 2013  (2) noviembre
   2013  (3) agosto 2013  (2) junio 2013  (1) May 2013  (1) abril 2013  (2)
   marzo 2013  (6) febrero 2013  (3) enero 2013  (8) diciembre 2012  (7)
   noviembre 2012  (2) octubre 2012  (2) May 2012  (8) abril 2012  (1) febrero
   2012  (1) enero 2012  (2) noviembre 2011  (1) octubre 2011  (2) septiembre
   2011  (2) agosto 2011  (2) julio 2011  (3) junio 2011  (2) May 2011  (7)
   abril 2011  (8) marzo 2011  (4) febrero 2011  (3) enero 2011  (1) noviembre
   2010  (3)


 * ACTUALIZACIONES DE TWITTER
   
   


 * ENTRADAS RECIENTES
   
   * Truco 125. Valores por defecto en datos de clientes y proveedores
     utilizando Business Partners (BP) 5 noviembre, 2023
   * Truco 124. Algunas cosas que deberiamos de conocer sobre las ordenes de
     transporte en SAP. 4 diciembre, 2022
   * Truco 123. Encontrar la ayuda de búsqueda asociada a un campo en cualquier
     transacción. Buscar cadenas en el código abap. 16 noviembre, 2022
   * Truco 122. Algunas utilidades para obtener información de tablas. 9
     noviembre, 2022
   * Truco 121. Auditoria con la transacción ST13. 3 noviembre, 2022
   * Truco 120. Transacciones para la gestión de IDOCs. Nuevo monitor WLF_IDOC,
     la «navaja suiza» de los Idocs. 28 octubre, 2022
   * Truco 119. Gestión de jobs técnicos con la transacción SJOBREPO. 20
     octubre, 2022
   * Truco 118. Gestion de Jobs con aplicaciones Fiori. 14 octubre, 2022
   * Truco 117. Cambio de periodos contables de forma automática. 7 octubre,
     2022
   * Truco 116. Navegación en el flujo de documentos de Venta en S/4HANA. 28
     febrero, 2021
 * 
   
   

 * Abap Autorizaciones Estadisticas Formacion Gestion de proyectos Humor
   Opinion. Productividad S/4HANA S4/HANA Sap Basis Sap CO Sap CRM Sap FI Sap HR
   SAP MM Sap PP Sap SD


 * COMENTARIOS RECIENTES
   
   Patricio en Algunos trucos para la configu…Iván en Algunos trucos para la
   configu…Osvaldo en Truco 1 – Texto personal…Luis Zambrano en Truco 57.
   Reducción manual en…LUISANA ALFONZO en Truco 66. Retención de
   documen…Wilfredo Germán Obre… en Truco 61. Añadir campos adicio…Victor
   Castellanos en Truco 10. Actualización masiva…Mary en Truco 33. Documento
   contable a…Jean López en Truco 74. Informe de Stock a u…Teresa en Truco 103.
   Obtener valores de…

Notas y trucos SAP (Bitacora)
Crea un blog o un sitio web gratuitos con WordPress.com.

 * Suscribirse Suscrito
    * Notas y trucos SAP (Bitacora)
      
      Únete a otros 1.551 suscriptores
      
      Suscríbeme
    * ¿Ya tienes una cuenta de WordPress.com? Inicia sesión.

 * Privacidad
 *  * Notas y trucos SAP (Bitacora)
    * Personalizar
    * Suscribirse Suscrito
    * Regístrate
    * Iniciar sesión
    * Denunciar este contenido
    * Ver sitio web en el Lector
    * Gestionar las suscripciones
    * Contraer esta barra

 

Cargando comentarios...

 

Escribe un comentario...
Correo electrónico (Obligatorio) Nombre (Obligatorio) Web


%d