viernes, mayo 23, 2008

Delimitaciones dinámicas en LDB_PROCESS

Cuando usamos bases de datos lógicas de partidas de FI hay campos que no aparecen directamente en la pantalla de selección, pero sí a través del botón de delimitaciones opcionales. los programas estándar que incluyen la LDB en los atibutos gestionan correctamente estas delimitaciones, pero... ¿cómo las especificaríamos si utilizamos la función LDB_PROCESS? aquí va un ejemplillo.



Funciones relacionadas con los días de los períodos

PERIOD_DAY_DETERMINE: devuelve primer/último días de período
- Entrada: I_GJAHR, I_MONAT, I_PERIV (de sociedad en T001)
- Salida: E_FDAY, E_LDAY, E_SPERIOD (indicador período especial)

FIRST_DAY_IN_PERIOD_GET / LAST_DAY_IN_PERIOD_GET
- Entrada: I_GJAHR, I_PERIV (de sociedad en T001) , I_POPER (período)
- Salida: E_DATE (primer / último día)

Gracias a Lucas León.

Esperar 'n' segundos

Si se desea meter un retardo de 'n' segundos en el código se puede utilizar la siguiente instrucción:


Opciones del DELETE ADJACENT

El motivo de este post es para explicarles unas opciones del DELETE de las tablas internas, que puede resultar de gran ayuda. Supongo que los más experimentados en Abap ya sabrán de ellas, pero el resto puede que no lo hayan visto.

Supongamos que nos pasan una tabla con muchísimos registros, de los cuales pueden haber duplicados. Necesitamos tener un solo registro de cada tipo, por lo que nos interesa eliminar de la tabla los duplicados. Para ello, podemos hacer lo siguiente:
  1. ordenamos la tabla -> SORT tabla_interna.
  2. eliminamos los duplicados -> DELETE ADJACENT DUPLICATES FROM tabla_interna.

Este delete eliminaría los duplicados de los registros, pero sólo aquellos que coincidan en todos los campos. Si cada registro se compone de varios campos, tienen que coincidir en todos para ser eliminados.

Si lo que nos interesa es eliminar registros que coincidan sólo en uno, dos, ... n campos, lo especificariamos de la siguiente forma.
  1. ordenamos la tabla -> SORT tabla_interna.
  2. eliminamos los duplicados -> DELETE ADJACENT DUPLICATES FROM tabla_interna COMPARING campo1 campo2 ... campoX.

dónde cada campo es el nombre del campo en la tabla interna.

Por ejemplo.

Tenemos la estructura siguiente, formada por tres campos:



Ahora queremos aplicar lo explicado antes, pero para que tenga en cuenta sólo el campo MATKL a la hora de eliminar duplicados.
  1. SORT gt_fich_gr_articulos.
  2. DELETE ADJACENT DUPLICATES FROM gt_fich_gr_articulos COMPARING MATKL.

Se eliminarian todos los registros duplicados excepto uno, el primero de la ordenación, con el mismo campo MATKL, aunque los dos campos siguientes sean diferentes.

Gracias a Samuel Artiles.

Estructura para CALL TRANSACTIONS

Con la estructura CTU_PARAMS podemos definir algunos parámetros del CALL TRANSACTION como modo de ejecución (Sólo errores, Visible, Invisible,...), modo de actualización, tamaño estándar de dynpro,...

Para su uso, por ejemplo, podemos definir un parámetro de tipo CTU_PARAMS-XXXXXX en la pantalla de selección y ello nos dará la posibilidad de seleccionar los diferentes aspectos en la ejecución del CALL TRANSACTION.

Ejemplo:


Cambiar el Infoset a un Query

Muchos (sobre todo funcionales) se habrá tropezado alguna vez cuando intenta copiar un query, porque no pueden cambiar el infoset. Pues bien, si no lo sabían, aquí está el truco.

1. Transacción SQ01 (SAP Query). Copiar el QUERY1 en QUERY2. El QUERY2 tendrá asignado el INFOSET1 y no se puede cambiar.
2. Transacción SQ02 (Infosets). Copiar el INFOSET1 en INFOSET2. Hacer las modificaciones que quieran en el INFOSET2.
3. Download el QUERY2 a fichero. Para ello ir a Infosets, Entorno->Transportes (Camioncito).
4. Editar el fichero de texto y cambiar INFOSET1 por INFOSET2.
5. Upload del QUERY2.
Y Listo. El QUERY2 será remplazado por el del fichero, que tiene el nuevo infoset.

Gracias a Jorge Martel por esta información.

Comprobación del NIF



para españa p.e.: COUNTRY = 'ES' y TAX_CODE_1 = nif a comprobar

en las excepciones devuelve si el NIF es válido o no.

martes, mayo 20, 2008

Reutilizar un tipo importado de una RFC

En muchas ocasiones habremos deseado aprovechar los tipos importados de las RFCs, evitando así diseñar los tipos necesarios para el mapeo con éstas, sobre todo si constan de muchos campos. Pues bien, existe una manera de hacerlo un poco casera pero eficaz. Para ello deberemos localizar en primer lugar la RFC/iDoc donde se encuentre el tipo a utilizar.

Una vez localizada, exportaremos el esquema XSD del tipo de mensaje deseado. En este caso exportaremos el correspondiente a la petición (request). Para ello iremos al menú Tools -> Export XSD -> Request... . Ésto nos generará el fichero .xsd en la ubicación que le hayamos indicado. A continuación, editaremos dicho fichero para poder importarlo desde el tipo que vayamos a crear. Supongamos que el tipo de datos que vamos a crear se llamará DT_DUMMY y que pertenece al dominio "http://dummy.es".


En primer lugar deberemos reemplazar el nombre del dominio con el que fue exportado el esquema. En este caso el dominio es "urn:sap-com:document:sap:rfc:functions", debiendo remplazarlo por "http://dummy.es". En sugundo lugar, faltará reemplazar el nombre del tipo del elemento "item" de "*_E_INTE_CAN_ALMACEN" a "DT_DUMMY". Guardamos los cambios.

Con ésto ya podremos crear el nuevo tipo de datos basado en el de la RFC. El nombre del tipo de datos y del dominio debe coincidir con lo que hemos puesto en el fichero. Para importar el esquema modificado deberemos seleccionar la etiqueta "XSD" y pulsar el icono de importar esquema.


En el momento de importarlo nos aparecerá un mensaje de aviso informando que se ignorará el elemento global que se define en el esquema, pero no debemos de darle mayor importancia ya que hace referencia al nombre de la RFC del que proviene. Con ello tendremos definido el nuevo tipo con los mismos campos y características que el tipo de la RFC, solo faltará aplicar las reglas de cardinalidad en función de las especificaciones.

lunes, mayo 19, 2008

Acerca las USER EXITS

Las user exits (Function module exits) son salidas desarrolladas por SAP. La salida se implementa como una llamada a un módulo de función. El código para el módulo de función lo escribe el desarrollador. No escribes el código directamente en el módulo de función sino en el include que está en dicho módulo.

La nomenclatura estándar de los módulos de función de las user exits es:
  • EXIT_

La llamada a un módulo de función de user exit se realiza de la siguiente manera:
  • CALL CUSTOMER-FUNCTION

Ejemplo:

El programa de la transacción VA01 es SAPMV45A.

Si se busca CALL CUSTOMER-FUNCTION en el programa SAPMV45A se encontrará ( entre otras user exits):



La exit llama al módulo de función EXIT_SAPMV45A_003

Para encontrar las user exits que se necesitan se puede hacer uso del programa que se detalla en esta entrada del blog: User Exits de una transacción.

Enlaces de interés:

USER-EXITs de una transacción

A continuación se muestra el código de un REPORT que devuelve las USER-EXITS de una transacción determinada:



jueves, mayo 15, 2008

Menú del Message Mappings desactivado

Para que el menú del Message Mappings esté activo, es necesario utilizar la versión 1.4.1 de java.


La versión a utilizar es un parámetro dependiente de usuario en Windows, para definir que se utilice la versión 1.4.1 deberemos ir al Panel de Control -> Java y picar sobre la pestaña "Java". Una vez ahí pulsaremos el botón "Ver" referente a la JNLP que se ve en la siguiente imagen:

Y por último dejamos solamente marcada la versión 1.4 de Java.

Conocer las BAdIs de una transacción

Para conocer qué BAdIs son llamadas cuando se ejecuta una transacción determinada deberemos seguir los siguientes pasos.
  1. TX. SE80 -> Seleccionamos Clase / Interfase.
  2. Dentro de ella colocamos la clase CL_EXITHANDLER.
  3. Seleccionar el método GET_INSTANCE.
  4. Colocar un BREAK en la llamada al metodo:



Ahora al ejecutar el proceso/transacción deseado, cada vez que se invoque a una BADI se podrá conocer el nombre de la BADI en el parametro "exit_name".

lunes, mayo 12, 2008

Información sobre BAdIs

En el siguiente enlace se muestra un pequeño tutorial sobre cómo detectar las BAdIs (Business Add-Ins) relacionadas con determinadas transacciones y cómo implementarlas:
También desde el portal de ayuda de SAP se muestra más información sobre esta técnica: