• Author / Uploaded
• carmen

• Categories
• Sap Se
• Servidor (Computación)
• Entorno de desarrollo integrado
• Bases de datos
• Microsoft Windows

Citation preview

Contenido 1 Introducción a SAP R/3........................................iii 1.1 Características de SAP R/3.............................................................vii 1.2 Entorno de Desarrollo ABAP.............................................................x 1.3 Aplicaciones del ABAP..................................................................xiv Modularización......................................................................................... xv

16 BATCH INPUTS..............................................xviii 16.1 Introducción.............................................................................xviii 16.2 Batch input ................................................................................xix 16.2.1 Generar Juego de datos..................................................................xix 16.2.2 Abrir el juego de datos...................................................................xxiii 16.2.3 Llenar la tabla BDCDATA...............................................................xxiii 16.2.4 Llamar a la transacción..................................................................xxv 16.2.5 Cerrar juego de datos...................................................................xxvi 16.2.6 Call transaction............................................................................ xxvi

17 PROGRAMAS DE CARGA DIRECTA...................xxviii 17.1 Ficheros del PC......................................................................xxviii 17.2 Ficheros del Servidor.................................................................xxix

18 TECNICAS DE REPORTING..............................xxxii 18.1 Introducción al reporting interactivo.............................................xxxii 18.1.1. ALVs Orientados a Objetos..........................................................xxxv 18.1.2. Listados Interactivos.......................................................................xl

19 PROGRAMACION DE DIALOGO...........................xlii 19.1 Introduccion............................................................................xlii 19.2 Logica de proceso..................................................................xliii

19.2.1

Llamar a los módulos de diálogo ABAP........................................xliv

19.3 Creacion de DYNPRO ............................................................xlv 19.3.1

Screen painter........................................................................xlvi

19.4 Menu Painter........................................................................xlix 19.4.1

Creacion de un STATUS..........................................................xlix

19.4.2

Barra de menú............................................................................ l

19.4.3

Barra de pulsadores...................................................................li

19.4.4

Teclas de función.......................................................................lii

19.4.5

Codigos de Funcion.....................................................................liv

19.4.1.1

Tipos de función...................................................................liv

1 Introducción a SAP R/3 SAP R/3 es un sistema empresarial integrado diseñado para ayudar a las organizaciones a ejecutar procesos empresariales tales como gestionar inventarios, crear solicitudes, procesar pedidos de venta, pagar facturas, etc. SAP R/3 abarca un amplio espectro de procesos empresariales.

SAP R/3 proporciona un sistema único integrado de gestión de las necesidades común a todos los departamentos de una empresa. Esta integración es la gran ventaja que aporta SAP R/3. Además, como SAP R/3 es un sistema basado en cliente-servidor, su versatilidad es aún mayor.

SAP R/3 consiste en una serie de áreas de aplicación las cuales estudiaremos más adelante.

Desde el punto de vista funcional y de su arquitectura técnica, SAP R/3 puede definirse como un software abierto basado en la tecnología cliente-servidor, diseñado para manejar las necesidades de información de una empresa.

Se trata de un paquete de software estándar (en contraposición al desarrollo a medida ) que puede modelar los procesos de negocios de una empresa en su propio modelo de datos.

Los niveles o componentes del SAP R/3 y la función que realizan están representados dentro de la elipse.

S A P

APLICACIONES R/3 NIVEL FUNCIONAL

1

SISTEMA BASICO

2

SISTEMA OPERATIVO, BASE DE DATOS Y RED

3

Componentes de SAP R/3 1. Aplicaciones funcionales, Los diferentes módulos que componen el sistema R/3 son: Finanzas     

FI - Gestión financiera CO - Controlling o Contabilidad de costes EC - Controlling Corporativo IM - Gestión de inversiones TR -Tesorería) Logística

       

LO - Logística general SD - Ventas y Distribucion MM - Gestión de Materiales PP - Planeamiento de la Produccion PM - Mantenimiento QM - Control de calidad PS - Sistema de control de proyectos WM - Gestión de almacenes Recursos Humanos

  

PA - Administracion de Personal PD - Desarrollo y planificación personal IS - Solución vertical para industrias 2. Sistema básico, es el encargado de la interfaz entre el sistema operativo y las aplicaciones R/3 incluyendo componentes tales como el entorno de

desarrollo ABAP, herramientas de administración del sistema, manejo de jobs, autorizaciones, etc. 3. Sistema Operativo, gestión de la base de datos y la red cuyo software viene incluido en SAP R/3.

1.1 Características de SAP R/3 SAP R/3 ofrece para gestionar los distintas funciones de una empresa las siguientes características:

 Sistema Cliente – Servidor.

Sistema Cliente Servidor.- en la computación cliente-servidor, una parte del procesamiento se ejecuta en el PC de sobremesa ( cliente ) y la otra en computadoras centrales compartidas ( servidores ).

La presentación y el

preprocesamiento se ejecutan en el PC mientras que la información se almacena en los servidores.

Servidor Base de Datos.- Este es el servidor central que contiene la base de datos ( el sistema de gestión de base de datos ) y se conoce generalmente como servidor de base de datos. Servidor de Aplicaciones.- Contienen la lógica de proceso del sistema incluyendo servicios como el de impresión, peticiones de usuario, servicios para procesar los jobs de fondo, etc.

La comunicación entre los tres niveles anteriores se realiza mediante el protocolo estándar TCP/IP.  Tecnología de Sistemas Abiertos Significa que las aplicaciones pueden funcionar sobre múltiples sistemas operativos (UNIX, WINDOWS NT, AS/400, etc. ) y diferentes gestores de bases de datos ( ORACLE, INFORMIX, ADABAS, etc. ), siendo el código fuente de las aplicaciones ABAP completamente reutilizable y transportable entre los distintos sistemas. SAP soporta muchas GUI (Interfaces Gráficas de Usuario ) tales como Windows 3.11, Windows 95, Windows 98, Windows NT, Macintosh, etc. La GUI diseñada por SAP es la SAP GUI y está orientada a ventanas, botones, iconos, barras de menú, barras de herramientas, etc. Esta GUI depende de la versión con la que se esté trabajando.

 Integración de Aplicaciones Todas las aplicaciones R/3 están integradas y relacionadas con capacidad de hacerlo en tiempo real, es decir, la información se actualiza constantemente. ¿Qué significa esto? Cualquier cambio que se realice por ejemplo en una base de datos se reflejará inmediatamente en todos los componentes de SAP: screen painter, menu painter, diccionario de datos, etc.

 Entorno de desarrollo

2 CARACTERÍSTICAS DE SAP R/3

Incluye todas las herramientas necesarias para el diseño y desarrollo de programas, pantallas, menús, módulos de funciones, etc. Contiene también funciones para realizar la depuración de programas y pruebas de rendimiento. Todas las aplicaciones estándar de R/3 están realizadas en ABAP.

Se ha diseñado un entorno de desarrollo llamado Development Workbench que se encuentra integrado dentro del sistema R/3 y permite al cliente desarrollar soluciones específicas o ampliar las estándard en el núcleo de entorno de desarrollo se encuentran el Repositorio de objetos y el Diccionario de datos.

Dentro del Diccionario de Datos se encuentran la definición de tablas, valores permitidos, relaciones entre tablas, etc. Repositorio de Objetos: programas, datos del diccionario, dynpros, documentación, etc.

 Herramientas para la configuración del sistema La parametrización es la piedra angular de una implantación SAP R/3. Algunas tareas de parametrización son tan sencillas como introducir el país donde está situada la empresa y otras son más complicadas, orientadas a áreas o industrias especificas que requiere conocimientos técnicos de configuración como de actividades empresariales.

 Servicios de Soporte, Formación, Consultoría e Implantación ( OSS ) SAP ha dispuesto un amplio conjunto de servicios de calidad para ayudar a su cliente durante el proceso de implantación y soporte de los sistemas R/3. Estos servicios abarcan desde información de aplicaciones, formación, servicio de instalación hasta consultoría.

SAP realiza la gran mayoría de los servicios a través de conexiones remotas con red de comunicación internacional. El sistema de servicio en línea de SAP se llama OSS ( Online Service System ).

1.2 Entorno de Desarrollo ABAP El entorno de desarrollo ABAP consiste de las siguientes herramientas :

Para

La

herramienta

/ Se utiliza para

componente Programación

Diccionario ABAP

Definir,

mantener

y

almacenar el diccionario de datos del sistema R/3. Contiene todos los objetos del diccionario, tales como tablas,

relaciones,

documentación, etc. Editor ABAP

Crear

y

programas

mantener ABAP

los para

editar módulos de función, bases de datos lógicas y la lógica de programación de las pantallas ( Dynpros ) Librería de Funciones

Definir y mantener modulo de función ABAP ( rutinas de propósito general que pueden ser utilizadas en otros programas ABAP )

3 ENTORNO DE DESARROLLO ABAP

Screen Painter

Diseñar y mantener las pantallas

e

interfaces

gráficas de usuario en R/3. Menu Painter

Diseñar y mantener los menús para los interfaces gráficos de usuario.

Navegación

Object Browser

Gestionar y revisar los objetos de desarrollo de modo

jerárquico

para

permitir una navegación fácil entre los objetos y el entorno de desarrollo. Sistema de información del Navegar y buscar objetos Repositorio ABAP

del diccionario, objetos de desarrollo entre

y

relaciones

objetos

de

desarrollo.

Visualizar los objetos de Jerarquía Aplicación

desarrollo desde un punto de vista organizativo y de aplicación.

Data Browser

Navegar y visualizar los contenidos de las tablas de la base de datos.

Debugging

Trace SQL

Seguir

y

rastrear

los

accesos y llamadas a la base de datos desde los programas y transacciones

del sistema Análisis Tiempo Ejecución

Analizar el rendimiento de las llamadas al sistema.

Debugger en línea

Detener un programa y analizar el resultado de la ejecución

de

cada

sentencia del programa. Log del Sistema

Seguimiento de los errores y

mensajes

que

se

producen

durante

la

ejecución

de

los

programas. Organización

del Workbench Organizer

desarrollo

Controlar

y

seguir

el

trabajo de desarrollo y los proyectos para

en

equipo

gestionar

y las

versiones de los objetos de desarrollo. Sistema de Transporte

Realizar y gestionar los transportes de los objetos de

desarrollo

entre

distintos sistemas SAP.

Concepto de Mandante (cliente).- Muchas veces se entiende de manera equivocada el este concepto, en realidad es el nombre del sistema SAP R/3 al que nos conectamos, la mayoría de las compañías cuentan con un cliente para cada tarea específica.

Se define como una unidad independiente dentro del sistema R/3, desde el punto de vista fiscal, legal y organizativo. Por ejemplo un mandante se puede decir que representa a una empresa dentro de una corporación. Técnicamente se puede decir que un mandante se comporta dentro de SAP como una base de datos lógica independiente, es decir, los datos de una tabla en un mandante no pueden ser modificados ni visualizados desde otro mandante.

Por ejemplo una compañía podría tener la siguiente configuración: 

El sistema cliente de formación 400, que se utiliza para la formación de nuevos usuarios.



El sistema cliente de desarrollo 100, que se utiliza para nuevos desarrollos así como etapa de prueba de los nuevos desarrollos.



El sistema de producción 100 es el sistema activo utilizado para dirigir la empresa. Ésta es un área nada recomendable para practicar.

Es importante conocer el cliente o mandante en que se requiera realizar la tarea específica debido a los posibles problemas que se puedan generar. Cada cliente

o

mandante

determinadas tarea.

tiene

especificadas

autorizaciones

para

realizar

La realización de las tareas en cada mandante está

restringida y asignada dependiendo del nivel del usuario. Por ejemplo un usuario final no siempre tiene autorización para manipular todos los menús de SAP R/3, así como un programador puede tener un límite dentro del sistema de desarrollo ( no estar autorizado para actualizar bases de datos, eliminar elementos de SAP, etc. ), un funcional no tendrá acceso a los recursos del sistema base (administración de la base de datos)…

Concepto de Transacción.- De un modo genérico una transacción es una operación que permite a un usuario realizar cambios en la base de datos. Todo el sistema R/3 se puede considerar como un sistema de proceso de transacciones de negocios.

1.3 Aplicaciones del ABAP ABAP es el lenguaje de programación de SAP. En versiones anteriores a la 4.0 era un lenguaje de programación de 4ª generación ( se denominaba ABAP/4); a partir de entonces, se puede decir que es un lenguaje de programación orientada a objetos. El significado de ABAP es: A - Advanced B - Business A - Aplication P - Programming

Las aplicaciones del ABAP son:  Reporting ( Clásico e interactivo )  Programación de diálogo o transacciones ( diseño de pantallas )  Otras aplicaciones ( Batch-Input, programas de comunicaciones, etc. ) Una vez instalado SAP, la principal aplicación del ABAP es la generación de informes ya sea porque no han sido contemplados por SAP o se requiere un formato muy completo (al margen de posibles modificaciones, ampliaciones, etc.).

El Reporting Clásico se caracteriza por listados voluminosos o muy frecuentes con mezcla de información detallada y resumida. El Reporting Interactivo está orientado a pantallas, listados cortos y ventanas controladas por teclas de función.

Ambos reporting se pueden ejecutar en Online ( tiempo real ) mientras que únicamente el clásico se puede ejecutar en Batch ( diferido/proceso de fondo ). La programación en diálogo se caracteriza por estar enfocado a pantallas que estarán controladas por módulos ABAP.

Otras aplicaciones posibles en lenguaje de programación son la generación de Batch Input y programas de comunicaciones. Un Batch Input es una utilidad de SAP para transferir información de forma segura y automatizada. Para ello se simula mediante un proceso en batch la introducción de datos en el sistema a través de una transacción online.

Modularización Una unidad de modularización es una parte de un programa encapsulada con una funcionalidad determinada. La modularización hace más fácil mantener los programas Por modularización dentro de los programas ABAP, entendemos el hecho de facilitar su lectura y mejorar su estructura. Modularizar programas facilita el mantenimiento y la actualización de los mismos a comparación de los que no están debidamente modularizados. A este nivel, modularización es sinónimo de estructuración.

Principio de Modularización No modularizado PROGRAM …

….. Block de Sentencias

…..

Modularizado PROGRAM … ….. CALL UNIDAD DE MODULARIZACION ….. CALL UNIDAD DE MODULARIZACION ….. CALL UNIDAD DE MODULARIZACION …..

Block de Sentencias

….. CALL UNIDAD DE MODULARIZACION Block de Sentencias Block de Sentencias

…..

1.3.1.1 Técnicas para facilitar la modularización: 1) MODULARIZACION LOCAL  Definicion de subrutinas internas y externas para evitar secuencias de sentencias similares o idénticas, es decir, evitar redundancia de contextos. Las subrutinas mejoran la estructura de tu programa ( esto significa modularización ) y facilitan su lectura. Una secuencia de sentencias definida dentro de una subrutina puede ser llamada desde varios puntos de un programa. Para mayor claridad se deben colocar las subrutinas al inicio o al fin del programa (por convenio, es mejor hacerlo al final).

 Definir de includes dentro de la biblioteca.

Sí se desea utilizar la misma secuencia de sentencias en varios programas, es aconsejable realizar el código dentro de un programa include. 

Metodos en clases locales.

2) MODULARIZACION G LOBAL  Definir módulos de función. Éstos son almacenados dentro de la biblioteca de funciones, en donde son asignados a un grupo de función. El sistema R/3 proporciona diversos módulos de función predefinidos, los cuales pueden ser llamados desde cualquier programa ABAP. Además estos módulos de función pueden ser creados por el propio programador. A diferencia de las subrutinas, los módulos de función cuentan con una interface, siendo capaz de esta forma de estandarizar el paso de parámetros. 

Metodos en clases globales.

 llamadas a programas externos – Llamadas a interfaces abiertas.

16 BATCH INPUTS 16.1 Introducción Cuando se instala una aplicación en productivo es necesario dar de alta toda la información indispensable para que la empresa pueda funcionar (proceso de migración de datos o conversión). Por ejemplo, antes de poder generar facturas reales será necesario introducir todos los clientes activos y todos los productos que se encuentran a la venta. Para realizar la carga de productos que están a la venta se debería ejecutar manualmente la transacción “Alta de materiales” tantas veces como productos sean precisos y la misma operación mediante “Alta de clientes” para todos los clientes. En el caso de que la empresa tenga muchos productos y muchos clientes, la carga inicial será muy costosa. Generalmente todos estos datos maestros (clientes, materiales, proveedores,... ) ya se encuentran almacenados en el antiguo sistema informático. Por lo tanto lo ideal será disponer de un mecanismo que permitiese trasladar los datos de un sistema a otro de forma eficaz. A la hora de la migración de datos de un sistema externo a SAP, existen dos posibilidades: 1

Realizar programas que llenen todas las bases de datos SAP involucradas, mediante instrucciones directas de SAP-SQL (inserción/modificación directa de las tablas de las bases de datos). Utilizar la técnica del Batch Input de SAP.

2

Para muchas transacciones, la primera de las opciones es inviable, debido a la complejidad de la estructura de datos SAP y la dificultad dea mantener la integridad de la misma, ya que sería necesario utilizar una elevada cantidad de validaciones sobre los datos de entrada. Como consecuencia, tanto el coste en diseño, codificación y pruebas sería altísimo.

En cambio, mediante la técnica de los Batch Input de SAP se realizan todas las verificaciones automáticamente, con un coste en diseño y desarrollo mínimos. En este capítulo se explica cómo utilizar la técnica de los Batch Input.

16.2 Batch input . El Batch input es un proceso que se lanza en fondo ( sin la presencia de un usuario) y que realiza tareas costosas y largas como por ejemplo leer los datos de un fichero e introducirlos en una tabla. Consiste en simular las transacciones, todas las pantallas, pasos teclas a pulsar y demás acciones que se debern realizar para cumplir una tarea. Todo se almacena en el juego de datos.

Los pasos a la hora de crear el juego de datos son:    

Abrir el juego de datos. Llenar la tabla BDCDATA. Llamar a la transacción. Cerrar el juego de datos.

Estos tres pasos suelen estar almacenados en FORMS para que su uso sea mas sencillo.

16.2.1 Generar Juego de datos. SAP incorpora una herramienta que genera el juego de datos de forma auotmatica sin tener que anotar una por una las pantallas por las que se quiere pasar.Se accede a herramienta desde el menú o llamando a la transacción. 

Servicios-> Batch Input->Grabadora.



Transacción. SHDB.

Fig – Transaccion SHDB

Para crear un juego nuevo de datos pulsamos sobre Grabacion nueva,

Indicamos nombre para la grabación y la transacción que se quiere llamar, pulsar el botón iniciar grabación y simular la acción deseada para la transacción.

No siempre los juegos de datos son para ser utilizados desde los programas, pueden ser lanzados directamente. Para ello acceder a la transacción SM35. Aparecera una lista con todos los juegos de datos creados en el sistema.

Fig – Transaccion SM35 . Resumen juego de datos Batch input.

Para lanzar el proceso de batch input hay que marcar el juego de datos y pulsar en ejecutar.

Apararecera una pantalla para elegir el modo de

procesamiento y otras funciones

Fig- Ejecutar juego de datos Batch Input

Una vez ejecutado el proceso podemos ver el resultado y analizar los errores en la misma transaccion SM35 mediante el log de errores . Una sesión de Batch Input puede encontrarse en uno de los siguientes estados: 

A procesar: Si la sesión todavía no ha sido procesada.



Procesada: Si las transacciones que componen la sesión han sido ejecutadas íntegramente sin errores.



Errónea: Si en la sesión aún quedan transacciones que no se han procesado correctamente. Cuando una sesión está en estado incorrecto, no quiere decir que las transacciones que contenía no hayan sido procesadas, sino que algunas se han procesado y otras no. Estas transacciones erróneas podrásn ser reprocesadas más adelante, es decir nunca se pierde una transacción a no ser que explícitamente la sesión sea borrada.



Siendo creada: Si hay un programa Batch Input que está generando una sesión en ese momento.



En proceso: Si se está procesado en ese instante la transacción.



Fondo: Si se ha lanzado la sesión para que se procese pero todavía no ha comenzado a ejecutarse por falta de recursos del sistema.

16.2.2 Abrir el juego de datos. Para abrir el juego de datos vamos a utilizar una función de diccionario BDC_OPEN_GROUP, indicándole el nombre de juego de datos, el usuario y el mandante. Se puede crear un form con un parámetro de entrada que será el nombre del juego de datos que se desea crear.

FORM ABRIR_JUEGO USING p_juego CALL FUNCTION ’BDC_OPEN_GROUP’ EXPORTING Client

= SY-MANDT

Group

= p_juego

User

= SY-UNAME

Keep

= ‘X’

EXCEPTIONS … ENDFORM.

16.2.3 Llenar la tabla BDCDATA Para indicar las pantallas por las que se va a pasar y que datos hay que rellenar en cada uno de los campos, hay que informar la tabla interna llamada I_BDCDATA que estará declarada con la misma estructura que la tabla BDCDATA del diccionario de datos.

Se puede crear un form con tres parámetros p_name p_value y p_dynbegin. El primero de ellos indica si es una pantalla nueva, en cuyo caso vendrá con el valor ‘X’. Los otros dos paramentros dependen de este.



Si se esta en una pantalla nueva p_name nos indicara el programa y p_value el numero de pantalla.



Si no es una pantalla nueva p_name indica el campo donde hay que indicar un dato y p_value su valor.

Ejemplo:

Transacción: FSSI Programa: SAPMF02H Dynpro : 0102

Ejemplo:

Rellenar campo RF02H-SAKNR con variable VAR_CTA. Rellenar campo RF02H-BUKRS con variable VAR_SOC.

FORM CREAR_TABLA USING p_dynbegin p_name p_value. CLEAR i_bdcdata.

IF p_dynbegin = ‘X’. i_bdcdata-program = ‘SAPMF02H’. i_bdcdata-dynpro - DYNPRO = ‘0102’. i_bdcdata-dynbegin = ‘X’. ELSE. i_bdcdata-fnam

= ‘RF02H-SAKNR’

i_bdcdata-fval

= VAR_CTA.

ENDIF. APPEND i_bdcdata

Si es necesario proveer de una tecla de función a la pantalla, se utilizará el campo BDC_OKCODE. El valor del campo será el número de la tecla de función precedido por una barra inclinada. .

Ejemplo: CLEAR i_bdcdata. i_bdcdata-fnam

= ‘BDC_OKCODE’.

i_bdcdata-fval

= ‘/13’.

 F13= Grabar

APPEND i_bdcdata.

Si se necesita colocar el cursor en un campo en particular, se utilizará el campo BDC_CURSOR. El valor del campo será el nombre del campo sobre el cual se desee situarse.

Ejemplo: CLEAR i_bdcdata.. i_bdcdata-fnam i_bdcdata-fval

= BDC_CURSOR. = ‘RF02H-BUKRS’

APPEND i_bdcdata.

16.2.4 Llamar a la transacción. Para llamar a la transacción, se utiliza la función BDC_INSERT. Se puede crear un form que reciba el parámetro D_CODE que indique el código de la transacción a ejecutar.

FORM INSERTAR USING VALUE (D_CODE). CALL FUNCTION ‘BDC_INSERT’ EXPORTING TCODE = D_CODE TABLES DYNPROTAB = I_TAB_BDC EXCEPTIONS…. ENDFORM

16.2.5 Cerrar juego de datos. Para cerrar juego de datos creado, hay que llamar a la transacción BDC_CLOSE_GROUP. Se puede crear un form con el siguiente código. FORM CERRAR. CALL FUNCTION ’BDC_CLOSE_GROUP ’ EXCEPTIONS NOT OPEN = 1 QUEUE_ERROR = 2 OTHERS = 3. ENDFORM.

16.2.6 Call transaction. El call transaction sirve para llamar a una transacción desde un punto del programa. Al finalizar esta, se retornara a la siguiente línea desde el programa que le llamo. El programa que llama la transacción puede enviar datos para que esta se ejecute, al igual que en un batch input. La principal diferencia entre un batch input y un call transaction es que el primero genera un juego de datos y el segundo no. Ademas la ejecución de las transacciones es inmediata en el CALL TRANSACTION es decir la ejecución de las transacciones y es controlada mediante un programa ABAP y no posteriormente desde la transacción SM35, lo cual puede resultar interesante en determinadas ocasiones.

Para llamar a un CALL TRANSACTIONse utiliza la siguiente sentencia:

CALL TRANSACTION tcod [AND SKIP FIRST SCREEN]

-> Se salta la pantalla de selección

[USING itab] -> Tabla interna para datos de otras pantallas en formato BI [OPTIONS FROM opt] [MODE mode]

-> opciones de control de ejecucion

-> Modo de ejecución visible o invisible

[UPDATE f] -> Modo de actualización síncrona o asíncrona. [MESSAGES INTO itab] ->mensajes que devuelve tras la ejecución.

La opción MODE sirve para indicar que el call transaction se realicen visible o en invisible. Si se indica el modo ‘A’ será visible y si se indica el modo ‘N’ se ejecutara en invisible y si es una ‘E’ solo se mostraran los errores.

La opción UPDATE sirve para indicar el modo de actualización: ‘A’ indica una actualización asíncrona, ‘S’ una síncrona y ‘L’ una actualización local.

17 PROGRAMAS DE CARGA DIRECTA El manejo de ficheros en SAP es distinto para ficheros que se encuentran en el PC que para ficheros que se encuentran en el servidor.

17.1 Ficheros del PC La información que se encuentra en un fichero del PC en forma de tabla se puede subir a un programa llamando al método de una clase. cl_gui_frontend_services=>gui_upload parámetros.   

Filename: Filetype: Data_tab:

indicándole

los

siguientes

ruta y nombre del fichero tipo del fichero ‘ASC’ o ‘DAT’ tabla interna de tipo estándar para guardar los datos.

Para bajar información de una tabla interna del programa de un fichero se puede utilizar el método cl_gui_frontend_services=>gui_download indicándole los siguientes parámetros.   

Filename: Filetype: Data_tab:

ruta y nombre del fichero tipo del fichero ‘ASC’ o ‘DAT’ tabla interna de tipo estándar para guardar los datos.

El fichero generado será separado por tabulación (.txt)

17.2 Ficheros del Servidor Para trabajar con un fichero que esta en el servidor, primero hay que abrirlo con la sentencia, se leen los datos y por ultimo se cierra el fichero:

OPEN DATASET . FOR OUTPUT / (INPUT) /

Escritura / Lectura (por defecto).

IN BINARY MODE / IN TEXT MODE Si SY-SUBRC = 0 SY-SUBRC = 8

Binario (por defecto) / Texto.

Fichero abierto correctamente. Fichero no se ha podido abrir.

Las opciones de apertura tienen el siguiente significado:     

FOR INPUT. Apertura de lectura FOR OUTPUT. Apertura de escriturta. Borra el contenido del fichero y escribe nuevos registros unos seguidos de otros. FOR APPENDING. Apertura de escritura pero sin borrar el contenido, sino que añade los registros al final. IN BINARY MODE se usa cuando el contenido del fichero no esta estructurado en líneas. IN TEXT MODE para transferir línea a línea del registro.

Para cerrar un fichero se utiliza la instrucción CLOSE. CLOSE DATASET .

Si se desean leer datos de un fichero se utilizará READ. READ DATASET INTO (LENGTH )

Guarda en la longitud del registro leído

. Ejemplo: Lectura de un fichero DATA: BEGIN OF REC, LIFNR LIKE LFA1-LIFNR, BAHNS LIKE LFA1-BAHNS, END OF REC. OPEN DATASET ‘/usr/test’. DO READ DATASET ‘/usr/test’ INTO REC. IF SY-SUBRC NE 0. EXIT. ENDIF. WRITE: / REC-LIFNR, REC-BAHNS. ENDDO CLOSE DATASET ‘/usr/test’. Notas: 1. Se puede leer de hasta 4 ficheros simultaneamente. 2. Si SY-SUBRC = 0 Fichero leído correctamente. 3. SY-SUBRC = 4 Fin de fichero encontrado.



Para escribir sobre un fichero se dispone de la instrucción TRANSFER. TRANSFER TO (LENGTH )  Transfiere la longitud especificada en la variable .

Por defecto la transferencia se realiza sobre un fichero secuencial (texto) a no ser que el fichero sea abierto en formato binario. En el caso de que el fichero no se encuentre todavía abierto, la instrucción TRANSFER lo intentará en modo binario y escritura.

Nota: Este tratamiento es válido solo sobre ficheros UNIX: es necesario distinguir la declaración de ficheros UNIX como de DOS y otros.

Los ficheros UNIX se identifican por: 1. file(30) default ‘/tmp/TELXX’. Su tratamiento es análogo a la utilización de sentencias anteriores: open dataset, read dataset, transfer. A diferencia de los no exclusivos de UNIX.

2. File(30) default ‘c:\prueba\prueba02.txt’, su tratamiento se realiza mediante llamadas a funciones ( módulos de función ), como por ejemplo: UPLOAD y DOWNLOAD. (Normalmente WS_UPLOAD y WS_DOWNLOAD).

18 TECNICAS DE REPORTING 18.1 Introducción al reporting interactivo. En el Reporting Interactivo se aprovecha la tecnología SAP para ofrecer informes que van detallando la información bajo la interacción del usuario, es decir, se realizan listados generales que se visualizan por pantalla y mediante teclas de función o seleccionando teclas de pantalla, se desarrolla aquella información que va siendo solicitada por el usuario.

En contraposición con el reporting clásico, que es asociado con procesos de entornos Batch (fondo), el reporting interactivo es un desarrollo que adopta todas las ventajas del entorno on-line.

Un ejemplo de listado interactivo podría ser una lista de clientes, que permita visualizar sus datos de dirección, datos bancarios, partidas... etc. en pantallas diferentes, que van apareciendo a medida que vaya siendo seleccionado un cliente y/o se solicita una función.

Existen dos tipos de salida distintos

1.

ALVs (Abap List Viewer). Listados con una presentación mas amigables que la que tienen los que se hacen mediante la sentencia WRITE.

2.

Listados Interacivos. Son listados normales hechos con la sentencia write, pero con la característica de que son navegables.

Fig. imagen de un ALV simple.

Hay tres tipos de Alvs en función de su presentación y para cada tipo de alv utilizaremos una clase predefinida en sap: -

Lista Simple. -> cl_salv_table Lista Jerarquica secuencial. -> cl_salv_hierseq_table Lista forma de arbol. -> cl_salv_tree

Fig- Tipos de ALV

18.1.1. ALVs Orientados a Objetos. El ALV Grid Control, es una herramienta que permite la visualización de listados por pantalla. Está basada en programación orientada a objetos. La utilización de esta herramienta ofrece funciones estándar tales como ordenación

de

columnas,

añadir

columnas,

totalizaciones,

extraer

la

información a fichero como por ejemplo excel. Además de permitirnos el desarrollo de otras funcionalidades propias.

La clase que encapsula la funcionalidad del ALV GRID es cl_gui_alv_grid.

Para que una lista pueda mostrarse por el ALV GRID control necesitamos definir unos componentes básicos: 

CONTENEDOR: El contenedor de datos es en el que se visualizará el listado, y podremos definirnos un menú a medida, con las funcionalidades que deseemos, además de aquellas que por defecto nos ofrecerá SAP.



DATOS: los datos estarán almacenados en una tabla interna esta tabla la pasaremos como parámetro de entrada al ALV GRID. La tabla interna debe de ser plana.



CATALAGO: tabla interna para definer y especicar los campos que se visualizaran en el ALV esta tabla interna se denomina “field catalog” y debe ser del tipo de diccionario LVC_T_FCAT. El catalogo contiene informacion tecnica adicional ademas de las opciones de visualizacion de cada campo.

Nota: utilizar este método CALL FUNCTION 'LVC_FIELDCATALOG_MERGE' nos devolverá el catalogo de la estrutura que le pasemos en el parámetro de entrada 



LAYOUT: estructura que contiene las opciones de visualización del layout del ALV GRID, podemos utilizar las opciones por defecto o podemos customizarlas. Tiene que ser del tipo de diccionario LVC_S_LAYOUT. MANEJADOR DE EVENTOS: Deberemos definir e implementar una clase manejadora de eventos si queremos lanzar eventos del ALV GRID.



DATOS ADICIONALES: Para tener alguna mejora del ALV, podemos pasar datos adicionales como parámetros por ejemplo un criterio de orden inicial,botones que deben estar desactivados… etc.

Ejemplo: REPORT ZALV_CSC

-

Paso 1. Nos creamos un report con una dynpro por ejemplo ‘100’. Paso 2. en el Layout de la dynpro dibujamos un contendor. CONTAINER1.

-

Paso 3. Populamos tabla interna con los datos a mostrar por el ALV y llamo a la dynpro donde mostrare los datos .

18 REPORTING INTERACTIVO

* DEFINICION DE VARIBLES LOCALES DATA: lt_SFLIGHT TYPE TABLE OF SFLIGHT, ls_SFLIGHT TYPE SFLIGHT.

* seleccion de los datos SELECT * FROM SFLIGHT INTO TABLE lT_SFLIGHT. CALL SCREEN 100.

-

Paso 4. Creacion del Contendor. Paso 5. Creacion del ALV GRID

* DEFINICION DE VARIBLES GLOBALES DATA:

go_container TYPE REF TO cl_gui_custom_container, go_grid TYPE REF TO cl_gui_alv_grid.

* CREACION DEL CONTENEDOR IF

go_container IS INITIAL. CREATE

OBJECT go_container

EXPORTING

container_name

= 'CONTAINER1'

EXCEPTIONS

cntl_error

= 1

cntl_system_error

= 2

create_error

= 3

lifetime_error

= 4

lifetime_dynpro_dynpro_link = 5 OTHERS ENDIF.

* CREACION DEL CONTROLADOR ALV GRID CREATE

OBJECT go_alvgrid

EXPORTING

= 6.

iparent

=

go_container EXCEPTIONS

error_cntl_create = 1

OTHERS

-

error_cntl_init

= 2

error_cntl_link

= 3

error_dp_create

= 4

= 5.

Paso 6. Creacion del Catalago. y con los campos que necistemos.

* DEFINICION DE VARIBLES LOCALES

ls_fieldcat TYPE lvc_s_fcat, lt_fieldcat TYPE lvc_t_fcat.

* CREACION DEL CATALGO clear

ls_fieldcat.

ls_fieldcat-fieldname

= 'MANDT'.

ls_fieldcat-no_out = 'X'. APPEND

ls_fieldcat TO lt_fieldcat.

clear

ls_fieldcat.

ls_fieldcat-fieldname

= 'CURRENCY'.

ls_fieldcat-col_pos = 2. ls_fieldcat-scrtext_l = 'moneda'. APPEND

-

ls_fieldcat TO lt_fieldcat.

Paso 7. Creacion del Layout.

* DEFINICION DE VARIBLES LOCALES

ls_layout TYPE lvc_s_layo.

*

CREACION DEL LAYOUT

ls_layout-smalltitle = 'X'. ls_layout-no_rowmark = ' '. ls_layout-cwidth_opt = 'X'. ls_layout-zebra ls_layout-sel_mode

-

= 'X'.

= 'D'.

Paso 8. Display ALV. * DISPLAY ALV. CALL METHOD go_alvgrid->set_table_for_first_display EXPORTING is_layout = ls_layout CHANGING it_outtab = lt_sflight it_fieldcatalog = lt_fieldcat EXCEPTIONS invalid_parameter_combination = 1 program_error = 2 too_many_lines = 3 OTHERS = 4. IF sy-subrc IS NOT INITIAL. MESSAGE text-e05 TYPE 'S' DISPLAY LIKE 'E'. LEAVE TO LIST-PROCESSING. ENDIF. "Insert correct name for .

18.1.2. Listados Interactivos. Son listados normales, hechos con la sentencia Write pero con la característica de que son navegables, es decir al hacer doble click sobre una liena se puede navegar hacia otra pantalla o listado. Para controlar el flujo del listado interactivo, existen una serie de eventos, tales como: 

AT LINE-SELECTION si lo que se selecciona es una línea,



AT PFn



AT USER-COMMAND (si se pulsa una tecla).

Un listado interacivo puede tener como máximo 19 listados secundarios. Si el usuario selecciona la función BACK el sistema vuelve al listado anterior. ABAP numera los listados a medida que se van generando, empezando desde 0. El número del listado en proceso estará en la variable del sistema SY-LSIND.

En el listado básico se pueden visualizar cabeceras con TOP-OF-PAGE o con la cabecera estándar, pero en los listados de ramificación no es posible utilizar cabeceras estándar; se utiliza el evento TOP-OF-PAGE DURING LINESELECTION.

1)

LA

INTERACCIÓN CON EL USUARIO.

El usuario tiene dos formas de interactuar con el sistema: - Seleccionando una línea del listado (con doble-click) o utilizando la función seleccionar para controlar la entrada del usuario se utiliza el evento de ABAP AT LINE-SELECTION. En el momento que el usuario selecciona una línea, el contenido de ésta se almacenará en la variable del sistema SY-LISEL

-

Seleccionando una función, pulsando su botón correspondiente o una tecla de función. Para controlar la entrada del usuario se utiliza el evento de ABAP, AT USERCOMMAND. El código de la función solicitada se puede obtener con la variable SY-UCOMM.

Ejemplo : Listado Interactivo

Report ZLISTADO_CSC

* Definicion de variables locales DATA: ls_mara TYPE mara, lt_mara TYPE TABLE OF mara. * Inicializacion del programa INITIALIZATION. CLEAR lt_mara. REFRESH lt_mara. * Comienzo pantalla seleccion START-OF-SELECTION. * Populamos con datos la tabla interna SELECT * FROM mara INTO TABLE lt_mara. END-OF-SELECTION. * mostramos el listado LOOP AT lt_mara INTO ls_mara. WRITE:/ ls_mara-matnr. WRITE:ls_mara-ernam. WRITE:ls_mara-mtart. ENDLOOP. AT LINE-SELECTION. *

Si se hace docle clik sobre la linea READ TABLE lt_mara INDEX sy-lilli into ls_mara. IF sy-subrc EQ 0.

*

lo que queramos mostrar ENDIF.

19 PROGRAMACION DE DIALOGO 19.1 Introduccion Las Dynpro (también conocidas como una pantalla) están formadas por la pantalla y la lógica de proceso de la pantalla. Las dynpros normales se crean utilizando la herramienta Screen Painter, Tenemos tres tipos distintas de Dynpros : 

Normal



Subscreen



Modal : pantalla emergente que se llama con la sentencia CALL SCREEN XXX STARTING AT …ENDING AT.

Pueden crearse Dynpros en un programa ejecutable, o en un grupo de funciones. Las Dynpros pueden combinarse para formar secuencias de Dynpros y navegar de unas pantallas a otras. Podemos llamar a la Dynpros mediante un código de transacción si llamamos desde fuera del programa o bien mediante instrucciones ABAP ”CALL SCREEN” si llamamos desde dentro de un programa.

19.2 Logica de proceso. La lógica de Proceso de pantalla llama a modulos de dialogo en el programa ABAp, ya sea para preparar las pantallas de visualización (PBO) o para procesar las entradas del usuario (PAI) . La lógica de proceso esta fundamentalmente dividida en dos bloques: 

Proccess Before Output. (PBO) Proceso que se llama antes de mostrar los datos en pantalla. En este apartado se incluyen la inicializacion de campos, valores por defecto situar el cursor en algún punto derterminado de la pantalla, mostrar u ocultar campos, modificar atributos de un campo o establecer botones para las acciones de usuario.



Process After Input. (PAI) Proceso que se realiza después de ejecutar alguna acción en la pantalla. Se ejecuta después del PBO. En esta parte se realizan las validaciones de los campos de salida y se procesan las entradas correctas e incorrectas. Ademas se incluye un bloque de salida por si el usuario desea abandona el programa y no procese ningún otro modulo. La llamada de salida se hace mediante la siguiente instrucción: MODULE EXIT at EXITCOMMAND. Fig - Flujo de proceso de dos Dynpros. Screen 1

Screen 2

Ademas también existen otros dos procesos que se ejecutaran unicamente cuando pulsemos la ayuda de un campo de la pantalla F4 o cuando pulsemos a la ayuda de programa F1. 

Process On Value-Request. Proceso que se ejecuta cuando un usuario pulsa a la ayuda F4 sobre un campo de la pantalla .



Process On Help – Request. Proceso que se ejecuta cuando el usuario pulsa sobre la ayuda de programa F1.

EJEMPLO : De la lógica de proceso de una DYNPRO. PROCESS BEFORE OUTPUT. MODULE status_0100. MODULE inicializar. MODULE ocultar_campos. MODULE set_cursor. PROCESS AFTER INPUT. MODULE user_command. MODULE get_cursor. FIELD: v_campo MODULE validar_campo

19.2.1

Llamar a los módulos de diálogo ABAP

Se uitilizara la instuccion ABAP para definir un modulo de dialogo PBO o PAI. MODULE name_module ……. ENDMODULE. Por tanto, un módulo de diálogo del programa ABAP se puede llamar desde diferentes pantallas. De esta manera las funciones requeridas en carias pantallas solo necesitan ser programadas una vez y si fuese necesario distinguir entre los números de pantalla en un módulo de diálogo, puede utilizar el campo de sistema SY-DYNNR , que siempre contiene el número de la pantalla actual.

NOTA: Cada apartado se agrupa en MODULES, se pueden crear includes para agrupar los modules o bien en el programa principal.

19.3Creacion de DYNPRO . Podemos crear pantallas desde la transacción SE51, donde indicamos el programa y el numero

de pantalla. Tambien desde el propio programa

podemos crear una dynpro si pulsamos en Crear->Dynpro y le indicamos el numero.



Indicamos el numero de dynpro 100



Indicamos el tipo de Dynpro ( Normal)



Podemos indicar una serie de atributos que pueden ser de interés: - la posición del cursor en la dynpro

-El tamaño de la ventana asi como el numero de las líneas.

Ademas Cuando Creamos una dynpro aparecen tres pestañas:



Atributos. Indicación breve del tipo de pantalla y tamaño asi como su descripccion.



Lista de Elementos: Contendra todos los elementos que se dibujen en la pantalla asi como sus atributos y propiedades



Logica de Proceso. Contendra la estructura de la lógica de proceso del programa.

19.3.1

Screen painter. Es la herramienta de sap que permite dibujar pantallas mas amigables que las pantallas de selección Nos permite diseñar la apariencia de la pantalla, diseñando el layout nos permite crear cada elemento de la pantalla y definir sus atributos y definir sus eventos. Podemos acceder a ella pinchando sobre el layout de la DYNPRO. Screen painter

Fig- Imagen Screen Painter. Lista de elementos

Atributos de un elemento Podemos dibujar en la pantalla cualquier elemento de la lista haciendo Click sobre el y situándolo sobre la zona que queremos dibujar y darle el tamaño desado.

Cuando coloquemos un elemento en la pantalla se pondrán de color rosa aquellos datos que hay que informar obligatoriamente.

Si se hace doble clik sobre el elemento Dibujado aparecera la ventana con todos sus atributos y propiedades. En funcion del tipo de elemento estaran habilidatos unos campos u otros.

En vez de escoger un elemento de la lista de elementos tambien podemos traernos del diccionario de datos o de las declaraciones del programa pulsando sobre el icono

y nos aparecera la siguiente ventana.

Hay que indicar el campo en la parte superior y pulsar el boton traer del diccionara o traer del programa, sera necesario que el programa este activado.

19.4Menu Painter El Menú Painter es una herramienta de SAP para personalizar los menus de las transacciones y los botones en cada pantalla. Se accede desde la transacción SE41 o bien haciendo docle click el el module PBO STATUS de una dynpro. Nota: Al conjunto de botones y menus se le denomina STATUS.

19.4.1

Creacion de un STATUS

El primer paso para crear un status es indicar el nombre que debe existir previamente, y el numero de pantalla y pulsar al botón crear.

A continuacion dar una breve descripcion y continuar.

La siguiente Pantalla aparecera dividida en tres partes: - Barra de menu, Barra de pulsadores y teclas de funcion

19.4.2

Barra de menú

La barra de menú es donde se inidica el menú de status que aparecerá en la aplicación. Para poder introducir los nombres de los menus que pulsar hacemos click sobre el icono Escribir el nombre del menu. Al hacer doble click aparecera una tabla para inidicar las entradas:

En la columna código hay que indicar un código para la entrada y el texto que tiene que aparecer en pantalla. Por ejemplo BUSC – Buscar. El siguiente paso es asignar una tecla de función al botón haciendo doble click sobre el código.

No todas las opciones están disponibles, ya que se reservan códigos como el F1 para las ayudas o el F4 para los matchcode.

Hay codigos que suele ser comunes en el resto de transacciones SAp como son F8 para ejecutar, F2 o F5 para crear, F6 para modificar y F7 para visualizar. Es conveniente utilizarlos para las mismas acciones, si el programa creado las contempla.

19.4.3

Barra de pulsadores.

En la barra de pulsadores se definen los botones que se mostraran en la barra de aplicacion.

Hay que introducir un código y pulsar enter. Aparecera la siguiente ventana de dialogo.

Fig – Barra de pulsadores y popup con botón cancel.

Indicaremos la opción de texto estatico y pulsar continuar.En la siguiente pantalla hay que indicar el texto descriptivo para esta función y el texto de información que aparecerá al pasar el raton por encima del botón. Opcionalmente se puede asignar un icono al botón y un texto que se podrá escoger del matchcode.

19.4.4

Teclas de función.

En este apartado se encuentran todas las teclas de función que tienen asociado un botón o un menú. En la parte superior se indican todos los botones que hay en cualquier pantalla estándar de SAP: grabar, atrás, cancelar, salir, imprimir… Estan definidos por defecto, solo falta darles un código para que se habiliten (SAVE,BACK,CANC,LEAVE,…..).

Si se quiere asignar un código de función a las entradas de menú, hay que indicar los códigos utiliados en el apartado barra menú y la misma descripción. Para guardar el okcode (SY_UCOMM), se suelen utilizar dos variables, una principal que se indica en la pestaña lista de elementos y otra que se guarda en el module del user-command.

Ambas variable deben estar declaradas en el TOP. TOP ( include con la declaracion de las variables globales de un programa) Ejemplo:

* Declaraciones en el TOP DATA: gv_okcode

TYPE sy-ucomm,

gv_save_okcode TYPE sy-ucomm. * MODULE USER COMMAND

PAI MODULE

user_command INPUT.

gv_save_okcode.

CLEAR

gv_save_okcode = gv_okcode. gv_okcode.

CLEAR

CASE

gv_save_okcode. *

...

ENDCASE. ENDMODULE.

19.4.5

Codigos de Funcion

Todos los códigos de función que se pulse y que tengan como resultado alguna acción en el programa ( por ejemplo: BUSCA) se indicara en el campo de la ventana de propiedades de campo.

19.4.1.1 Tipos de función Una vez definido el código de función en la barra de pulsadores se puede inidcar que tipo de función es la que se le ha asignado. Haciendo doble click sobre el código, aparecerá la siguiente ventana:

Fig – Atributos de códigos de Funcion

Los tipos de Funcion existentes son : E – Comando Exit ( MODULE xxx at EXIT-COMMAND) S – Funcion de sistema T – Llamada de transaccion “” – Funcion normal de Aplicación P – Funcion GUI local H – Funcion interna.

19.5Modificacion dinamica del status En el desarrollo del programa se puede controlar que botones se quieren mostrar en la barra de status, ya que no hay porque mostrar todos los botones definidos.

Ejemplo: * Esto estara metido dentro del module status_0100 output

del PBO

MODULE status_0100 OUTPUT. TYPES: BEGIN OF

ty_excluir. codigo type sy-ucomm.

TYPES: END OF ty_excluir. DATA: ls_excluir TYPE ty-excluir. ls_excluir-codigo = ‘SAVE’. APPEND ls_excluir. SET PF-STATUS '0100' excluding ls_excluir. ENDMODULE.

19.6Modificacion dinámica de atributos Ciertos atributos de los elementos de la pantalla se pueden modificar durante la ejecución del programa. Esto se puede realizar desde un modulo del PBO que se encargue de recorrer la pantalla y establecer los nuevos valores, Para realizar estos cambios existe una estructura SCREEN, formada por los siguientes campos

Tab – Campos de la estructura SCREEN. NOMBRE

TIPO

LONG

DESCRIPCION

Name

C

132

Nombre campo pantalla

Group1

C

3

Nombre grupo 1

Group 2

C

3

Nombre grupo 2

Group 3

C

3

Nombre grupo 3

Group 4

C

3

Nombre grupo 4

Required

C

1

Campo obligatorio

Input

C

1

Campo de entrada

Output

C

1

Campo de salida

intensified

C

1

Campo resaltado

iInvisible

C

1

Campo oculto

Ejemplo: ocultamos un campo en función de un elemento de la dynpro Para ello programamos el modulo ocultar campos del PBO

MODULE ocultar_campos OUTPUT. LOOP AT SCREEN. IF screen-name = 'V_CAMPO'. " deshabilitamos campo para escritura entrada de datos no permitida screen-input = '0'. ELSEIF screen-name = 'V_CAMPO2'. screen-input = '1'. ENDIF. MODIFY SCREEN. ENDLOOP. ENDMODULE.

Nota: si un campo tiene deshabilitada la escritura como atributo inicial, durante la ejecución del programa no se podrá habilitar.

Eventos: CHAIN – ENDCHAIN

19.6.1

Se pueden incluir en el PAI y sirven para ejecutar determinado modulos solamente cuando se producen cambios en determinados campos con los que están relacionados.

Ejemplos: CHAIN. FIELD: gv_campo MODULE validar_campo. " llama a validar en cuanto se cambia la entrada el valor de entra de datos

FIELD: gv_campo MODULE validar ON CHAIN-INPUT . ENDCHAIN.

19. 6.2 Dynpros con pestañas. Las pantallas se pueden agrupar en una misma dynpro incluyéndolas en un marco llamado tabstrip. Para crear este marco pulsar sobre el elemento . de la barra de botones y situarlo en la zona del layout que queramos. Aparecera lo siguiente:

La informacion necesaria para cada pestaña es: 

El nombre



La descripción que va a aparecer en pantalla



El código de función asociado



El campo de referencia, es decir, la subscreen que contiene.

También hay que darle nombre al Tabstrip e indicarle el numero de pestañas que va a contener. Ademas hay que declararlo con la siguiente sentencia: CONTROLS TYPE tabstrip.

Una vez que esta definido el marco hay que definir las pantallas que contiene cada pestaña, es decir a que subscreens van a hacer referencia. Para ello con el botón

dibujamos una subscreen area por cada pestaña. Tomaran

automaticamente el nombre que se haya indicado en la pestaña. En la logica de programa hay que indicar lo siguiente por cada pestaña: 

PBO: CALL SUBSCREEN Including ‘nom_programa



PAI: CALL SUBSCREEN .

Por otra parte hay que crear cada una de las pantallas que se mostraran en las pestañas.Estas pantallas será de tipo subscreen, lo cual hay que indicarlo en la pestaña de atributos, donde se indica el tipo de dynpro, marcar el radio button subscreen. En el user command de la pantalla con el marco, hay que indicar que pestaña se va a activar en cada momento usando el campo ACTIVETAB del tabstrip. Ejemplo: declaramos en function del codigo de la pestaña cual esta activa. PAI MODULE user_command INPUT. CASE gv_okcode. WHEN 'CLIENT'. pestanas-activetab = 'CLIENT'. WHEN 'MAT'. pestanas-activetab = 'MAT'. ENDCASE. ENDMODULE.

Hay que tener en cuenta que el status solamente se podrá indicar en la pantalla padre, la que tiene las llamadas a la subscreens. Al crear la transacción para este programa, se debe crear para la pantalla que tiene el marco de las pestañas.

19.6.3

Table controls

La table control son tablas que sirven para mostrar en una dynpro la información recogida por una tabla interna del programa.

Para crear un table control, escogemos el siguiente botón de la lista de elementos

y dibujamos en el layout . Hay que darle un nombre y definir sus

propiedades: nombre,separacion entre filas y columnas, su queremos poner cabecera. Para inidicar las columnas que debe llevar pulsar sobre el boton

y escoger

los campos de la tabla interna del programa o del diccionario de datos. Para dar nombre a las columnas hay que arrastrar hasta la cabacera de la tabla un campo de texto. En el programa el table control tiene que ser declarado con la siguiente sentencia: CONTROLS: TYPE tableview USING SCREEN . El nombre del table control de la dynpro y del programa debe ser el mismo. Para que el contenido de la tabla interna se refleje en la pantalla y viceversa. MODULE tablecontrol_init OUTPUT. IF Lt_user IS INITIAL. SELECT * FROM zuserinfo INTO CORRESPONDING FIELDS OF TABLE lt_user. REFRESH CONTROL 'TC_NAME' FROM SCREEN '0100'. ENDIF. ENDMODULE.

19.6.4. Uso del Cursor. Para tener el control del cursor y poscionar el campo deseado en cada momento, existen las sentencias GET CURSOR y SET CURSOR que se poenen como se indica a continuacion. Ejemplo: Logica del proceso para el uso de cursor. data: gv_cursor type screen-name, gv_linea type sy-lilli.

PROCESS BEFORE OUTPUT. … MODULE set_cursor. " ultima sentencia del PBO PROCESS AFTER INPUT. MODULE get_cursor. " primera sentencia del PAI

… MODULE set_cursor OUTPUT. “Definicion del modulo set cursor SET CURSOR FIELD gv_cursor LINE gv_linea. ENDMODULE. MODULE get_cursor INPUT. GET CURSOR FIELD gv_cursor LINE gv_linea. ENDMODULE.

19.6.4

Secuencias de Pantallas.

Para llamar a una pantalla desde un programa, se pueden usar las siguiente sentencias: SET SCREEN CALL SCREEN CALL SCREEN STARTING AT ENDING AT . LEAVE SCREEN . Para abandoner una pantalla se usa la sentencia LEAVE SCREEN. Si lo que se quiere es abandonar el programa se indicara LEAVE PROGRAM.