CGR EstandaresDeProgramacion ABAP4 v1 0

ESTÁNDARES DE PROGRAMACIÓN ABAP4

- VERSIÓN 1.0 - 2014

Sistemas - Área de Codificación ------------------------------------------------------------------------------------------------------------------------------------------------

- 2 -

Guía rápida de nomenclaturas y mejores prácticas en ABAP

Control de Cambios del Documento

Preparado por: Verónica Briceño Vásquez Fecha de Preparación: 20.10.2014 Revisado y aprobado por: Luis Alba Vera Fecha de A probación: 25.11.2014

Ruth Novoa La Torre Fecha de Aprobación: 25.11.2014 Versión 1.0 Fecha Efectiva: 01.12.2014


- 3 -

INDICE

OBJETIVO 04 ALCANCE 04

1. Nomenclatura de OT’s 05 2. Marca para modificaciones 06 3. Objeto de Autorización 08 4. Grupo de Autorización 08 5. Paquete - Clase de desarrollo 08 6. Objeto de Prueba 09 7. ESTRUCTURA PARA PROGRAMAS

7.1. Comentarios 10 7.2. Cabecera del programa 10 7.3. Declaración de datos globales 11 7.4. Declaración de campos de pantalla 12 7.5. Validación de campos de pantalla e inicialización 13 7.6. Rutina principal del programa 14 7.7. Tratamiento de los datos obtenidos 15 7.8. Eventos de control 15 7.9. Subrutinas internas 16

8. Convención para nombres internos ABAP4/SAP 17 9. RECOMENDACIONES GENERALES SOBRE FORMATO

9.1. Subrutinas (FORMS) 20 9.2. Programas INCLUDE 20 9.3. Cabeceras de listados 21 9.4. Textos de selección 21 9.5. Símbolos de texto 21 9.6. Pantallas 21 9.7. Dynpros, Status y Títulos 22 9.8. Status GUI 22 9.9. Patrones 23

10. ASEGURAMIENTO DE CALIDAD EN DESARROLLOS ABAP 10.1. Codificación y Presentación 24

10.2. Performance 29 10.3. Modularización y reutilización 32 10.4. Verificación Ampliada 34

10.5. Puntos a revisar en una OT previo al pase a PRD 35 11. NOMENCLATURA DE OBJETOS DE REPOSITORIO SAP 36 ANEXOS

• TABLA DE PARÁMETROS 48 • GUIAS 49

G1. Acumular OTs G2. Uso de SU24: Cómo asociar Tx con Objeto de autoriza ción

• IMAGENES 53


- 4 -

OBJETIVO �� Contar con un marco referencial para uniformizar la nomenclatura a utilizar en los desarrollos ABAP, permitiendo una identificación rápida, precisa y oportuna durante la etapa de desarrollo y mantenimiento, además de contar con pautas y recomendaciones para conseguir programas óptimos.

ALCANCE �� Este estándar de desarrollo abarca a todos los Consultores ABAP de Grupo Romero y a los proveedores de desarrollo de aplicaciones ABAP.


- 5 -

1. Nomenclatura de OT’s �� Las órdenes de transporte deben ser nombradas de acuerdo a la siguiente nomenclatura: <Tipo>-<Módulo> <Código Actividad> <Objeto Principal> <Descripción> <Versión> <Funcional> Donde: Tipo : CU (Customizing), WB (Workbench), TC (Transporte de Copias) Módulo : CO, FI, MM, SD, etc. Código Actividad : Código de actividad registrada en PMO Objeto Principal : Transacción u objeto principal modificado Descripción : Texto descriptivo Versión : Cuando se maneja más de una OT relacionada. Comenzar con 00. Funcional : Siglas de funcional responsable o solicitante Nota: - Si a la OT creada se le acumula una OT predecesora, se coloca como notación un (*) antes del número de versión que le corresponde. - Si la OT predecesora fue pasada a PRD, y se continúan con ajustes al mismo requerimiento, se sube el nivel de la OT y se vuelve a empezar de 00 (Ejemplo: 1 00, 2 00, 3 00, etc). - Para ver cómo acumular OTs, revisar sección ANEXOS -> GUIAS -> G1. Ejm: Mód Cod. Actividad Actividad Cod.Tarea ID OD Descripción (Tarea) Funcional

MM SOP_000019 SOPORTE VARIAS TEP-000002 2 Ajuste Reporte Pedido de Compras E.Izarra

WB-MM SOP_000019 ZMMR001 Ajuste Rep Ped compras 00 EIZARRA -> OT inicial WB-MM SOP_000019 ZMMR001 Ajuste Rep Ped compras 01 EIZARRA -> No acumuló OT anterior Mód Cod. Actividad Actividad Cod.Tarea ID OD Descripción (Tarea) Funcional

SD PYH_000049 Proyecto Impulso UNI TEP-000001 1 Reporte de Clientes M.Villanueva

WB-SD PYH_000049 ZSDR001 Reporte de Clientes 00 MV -> OT inicial WB-SD PYH_000049 ZSDR001 Reporte de Clientes * 01 MV -> Acumuló la OT anterior Mód Cod. Actividad Actividad Cod.Tarea ID OD Descripción (Tarea) Funcional

WM PYP_000032 WMS Ampliación de la capacidad de almacenamiento

TEP-000001 1 Ubicación para traslados I.Delgado

WB-WM PYP_000032 ZWMP001 Ubicación para traslados 00 ID -> OT inicial WB-WM PYP_000032 ZWMP001 Ubicación para traslados * 01 ID -> Acumuló la OT anterior WB-WM PYP_000032 ZWMP001 Ubicación para traslados * 02 ID -> Acumuló la OT anterior WB-WM PYP_000032 ZWMP001 Ubicación para traslados 1 00 ID -> OT anterior se pasó a PRD WB-WM PYP_000032 ZWMP001 Ubicación para traslados * 1 01 ID -> Acumuló la OT anterior WB-WM PYP_000032 ZWMP001 Ubicación para traslados 2 00 ID -> OT anterior se pasó a PRD


- 6 -

2. Marca para modificaciones �� Las marcas de modificación deben ser nombradas de acuerdo a la siguiente nomenclatura: <Acción> @<NNN> Donde: Acción : - INSERT : Insertar

- REPLACE : Modificar - DELETE : Comentar

NNN : Número correlativo de 3 dígitos Modelo ejemplo : � CASO1: Agregar varias líneas de código *{ INSERT @001 *-------------------------------------------------- --------------------* * Form TEXTO_EXP *-------------------------------------------------- --------------------* FORM TEXTO_EXP USING PI_ASNUM. DATA: LS_ASNUM TYPE ASMD-ASNUM, LS_TDNAME TYPE THEAD-TDNAME. REFRESH GDT_LINES. CLEAR GDT_LINES. CALL FUNCTION 'CONVERSION_EXIT_ALPHA_INPUT' EXPORTING INPUT = PI_ASNUM IMPORTING OUTPUT = LS_ASNUM. LS_TDNAME = LS_ASNUM. CALL FUNCTION 'READ_TEXT' EXPORTING ID = GC_ID LANGUAGE = SY-LANGU NAME = LS_TDNAME OBJECT = GC_OBJECT TABLES LINES = GDT_LINES EXCEPTIONS NOT_FOUND = 4. IF SY-SUBRC <> 0. MESSAGE S006 WITH TEXT- 003 PI_ASNUM TEXT- 004 . ENDIF. ENDFORM. "TEXTO_EXP *} INSERT @001


- 7 -

� CASO2: Modificar varias líneas de código *{ REPLACE @001 *&------------------------------------------------- --------------------* *& Form GET_FILE *&------------------------------------------------- --------------------* FORM GET_FILE CHANGING PO_FILE TYPE STRING. DATA: LDT_FILE_TABLE TYPE STANDARD TABLE OF FILE_TABLE, LS_FILE_FILTER TYPE STRING, LI_RC TYPE I . LS_FILE_FILTER = CL_GUI_FRONTEND_SERVICES=>FILETY PE_EXCEL. CALL METHOD CL_GUI_FRONTEND_SERVICES=>FILE_OPEN_DIALOG EXPORTING WINDOW_TITLE = 'Abrir en ...' FILE_FILTER = LS_FILE_FILTER DEFAULT_FILENAME = PO_FILE INITIAL_DIRECTORY = '/' CHANGING FILE_TABLE = LDT_FILE_TABLE RC = LI_RC. IF SY-SUBRC EQ 0 AND LI_RC EQ 1. READ TABLE LDT_FILE_TABLE INDEX 1 INTO PO_FILE. ENDIF. ENDFORM. " GET_FILE *} REPLACE @001 � CASO3: Eliminar/Comentar varias líneas de código *{ DELETE @001 **&------------------------------------------------ ---------------------* **& Module STATUS_0100 OUTPUT **&------------------------------------------------ ---------------------* ** text **------------------------------------------------- ---------------------* *MODULE status_0100 OUTPUT. * SET PF-STATUS '0100'. * SET TITLEBAR '0100'. *ENDMODULE. " STATUS_0100 OUTPUT *} DELETE @001 � CASO4: Agregar una línea de código DATA: GS_ID TYPE ICON- ID. "INSERT @001 � CASO5: Modificar una línea de código REFRESH GT_LINES. "REPLACE @001 � CASO6: Eliminar/Comentar una línea de código * CHECK NOT GHT_BSEG[] IS INITIAL. "DELETE @001


- 8 -

3. Objeto de Autorización �� Todo desarrollo debe contar con la validación de uno o varios objetos de autorización según lo solicitado en el requerimiento respectivo. Esto con el objetivo de restringir la información a mostrar o procesar. Asimismo la transacción con su respectivo objeto de autorización debe registrarse en la tx SU24 a fin de llevar un mejor control. Ejm: *-------------------------------------------------- --------------------* * VALIDACION DE PARAMETROS DE PANTALLA *-------------------------------------------------- --------------------* AT SELECTION- SCREEN. AUTHORITY- CHECK OBJECT 'ZMM_WERKS' ID 'TCODE' FIELD SY-TCODE ID 'WERKS' FIELD P_WERKS ID 'ACTVT' FIELD '03' . "visualizar IF SY-SUBRC NE 0. MESSAGE E000 WITH TEXT-E01 P_WERKS. ENDIF. Nota: - Considerar el campo actividad en la validación, la actividad a validar debe ir acorde a la función principal del programa (crear, modificar, visualizar, borrar, imprimir, contabilizar, etc). - Para ver cómo asociar Tx con O.A. en SU24, revisar sección ANEXOS -> GUIAS -> G2. 4. Grupo de Autorización �� Toda tabla Z creada debe ser asociada a un grupo de autorización, según lo solicitado en el requerimiento respectivo. Esto con el objetivo de restringir el acceso a la data de dicha tabla. Adicionalmente toda tx de mantenimiento creada para una tabla Z debe validar un objeto de autorización. Existirá para ello un programa único por módulo para la validación de objeto de autorización a tablas Z. 5. Paquete - Clase de desarrollo �� Todo objeto de repositorio Z válido para PRD, debe crearse haciendo referencia a un paquete de desarrollo. La asignación estará relacionada con el módulo SAP al que pertenece. Ejm: Paquete Descripción ZBC Uso genérico ZBW Business Warehouse ZCO Controlling ZCS Servicio al Cliente ZFI Finanzas ZHR Recursos Humanos ZMM Materiales ZPM Mantenimiento ZPP Producción ZPS Gestión de Proyectos ZQM Calidad ZSD Ventas y Distribución ZWM Gestión de Almacenes


- 9 -

6. Objetos de Prueba �� Los objetos creados para pruebas que no sean necesarios para el ambiente PRD, deben ser creados como objetos locales y el nombre debe empezar con Y.


- 10 -

7. ESTRUCTURA PARA PROGRAMAS �� 7.1. Comentarios Todo programa desarrollado debe incluir comentarios, con el propósito de facilitar a futuros programadores una mejor comprensión del código desarrollado y disminuir el impacto que representa para esta persona la modificación de un código no propio. Todo comentario debe estar en letra minúscula, además debe ser claro y conciso, dando una idea general de la función que realiza esa sección de código en el programa. 7.2. Cabecera del programa La cabecera de un programa ABAP deberá respetar el siguiente formato: *&------------------------------------------------- --------------------* *& Actividad...: * *& Módulo.....: * *& Funcional..: * *& Autor......: * *& Fecha......: * *& Descripción: * *&------------------------------------------------- --------------------* *& MODIFICACIONES * *&------------------------------------------------- --------------------* *& Actividad: * *& Marca....: * *& Funcional: * *& Autor....: * *& Fecha....: * *& Motivo...: * *&------------------------------------------------- --------------------* REPORT ZMSTNNNN MESSAGE- ID Z0 LINE - SIZE 132 LINE - COUNT 65 NO STANDARD PAGE HEADING. Las primeras líneas del programa deben ser destinadas al nombre del programa, clase de mensaje, tamaño del reporte de salida, etc. Nota: El título MODIFICACIONES, sólo se coloca la primera vez que se va a hacer una modificación al programa, los encabezados se colocan todas las veces que se hagan modificaciones. Ejm: *&------------------------------------------------- --------------------* *& Actividad..: PYH_000052 – Facturación Electrónic a Chile Salmofood * *& Módulo.....: SD * *& Funcional..: Christian Torres * *& Autor......: Ana Perez * *& Fecha......: 01.09.2014 * *& Descripción: Flujo de facturas de ventas * *&------------------------------------------------- --------------------* *& MODIFICACIONES * *&------------------------------------------------- --------------------* *& Actividad: PYH_000052 – Facturación Electrónica Chile Salmofood * *& Marca....: @001 * *& Funcional: Christian Torres * *& Autor....: Roberto Sanchez * *& Fecha....: 02.10.2014 * *& Motivo...: Agregar fecha de creación de document o *


- 11 -

*&------------------------------------------------- --------------------* *& Actividad: PYH_000052 – Facturación Electrónica Chile Salmofood * *& Marca....: @002 * *& Funcional: Maria Campos * *& Autor....: Ana Perez * *& Fecha....: 15.10.2014 * *& Motivo...: Enviar reporte por correo * *&------------------------------------------------- --------------------* 7.3. Declaración de datos globales Esta sección se debe utilizar para la declaración de todas las constantes y variables globales utilizadas en el programa. La declaración de datos debe respetar el siguiente formato: Modelo ejemplo : *-------------------------------------------------- --------------------* * DECLARACION DE TABLAS * *-------------------------------------------------- --------------------* TABLES: T001W, "Centros/Sucursales MBEW, "Valoración de material MSEG. "Segmento doc.material *-------------------------------------------------- --------------------* * CONSTANTES * *-------------------------------------------------- --------------------* CONSTANTS: GC_SOBKZ TYPE QBEW-SOBKZ VALUE 'Q' , GC_XXXXX TYPE C LENGTH 10 VALUE 'OTROS' , GC_WERKS TYPE T001W-WERKS VALUE '105A' . *-------------------------------------------------- --------------------* * DECLARACION DE VARIABLES * *-------------------------------------------------- --------------------* TYPE-POOLS: SLIS. "Agregar comentario * Campos globales DATA: GS_BUKRS TYPE T001-BUKRS, "Adicionar comentario GS_CAMPO2 TYPE C LENGTH 3, "Adicionar comentario GN_CAMPO3 TYPE N, "Adicionar comentario GD_BUDAT TYPE BKPF-BUDAT. "Adicionar comentario * Tipos TYPES: GTY_MARC TYPE MARC. TYPES: BEGIN OF GTY_MAKT, MATNR TYPE MAKT-MATNR, MAKTX TYPE MAKT-MAKTX, END OF GTY_MAKT. *Tipo tabla TYPES: GTYT_MARC TYPE TABLE OF MARC, "Standard GTYD_MARC TYPE STANDARD TABLE OF GTY_MARC, "Hashed GTYH_MARC TYPE HASHED TABLE OF GTY_MARC WITH UNIQUE KEY MATNR WERKS, "Sorted GTYS_MARC TYPE SORTED TABLE OF GTY_MARC WITH NON- UNIQUE KEY MATNR. *Tablas internas DATA: GT_MARC TYPE TABLE OF GTY_MARC, "Standard


- 12 -

GDT_MARC TYPE GTYD_MARC, "Hashed GHT_MARC TYPE GTYH_MARC, "Sorted GST_MARC TYPE GTYS_MARC. * Estructuras DATA: BEGIN OF GWA_XXXX, BUKRS TYPE BKPF-BUKRS, "Sociedad BELNR TYPE BSEG-BELNR, "Fecha de contabilización END OF GWA_XXXX. DATA: GWA_MARC LIKE LINE OF GT_MARC. "Agregar comentario * Rangos DATA: GR_BUKRS TYPE RANGE OF BKPF-BUKRS, "rango de sociedades GWA_BUKRS LIKE LINE OF GR_BUKRS. * Field symbols FIELD-SYMBOLS: <GWA_MARC> LIKE LINE OF GDT_MARC, <GS_MATNR> TYPE MARA- MATNR. * Fields groups FIELD -GROUPS: FG_HEADER, "Agregar comentario FG_DETALLE. "Agregar comentario Donde: Las primeras líneas de este bloque deben utilizarse para la declaración de las tablas y estructura de datos utilizada por el programa. Cada tabla declarada debe tener a su derecha el comentario sobre la descripción breve de la misma. La segunda sección del bloque se utilizará para la declaración de constantes. La tercera sección del bloque se utilizará para la declaración de variables globales. Esto incluye campos, tablas internas, estructuras, etc. en la forma y orden en que se muestra en el ejemplo de arriba. Cada objeto adicionado debe comentarse. Nota: Debe tratarse en lo posible, definir las variables haciendo referencia a campos definidos en el diccionario de datos, mediante la utilización de TYPE. La sentencia OCCURS todavía se permite por razones de compatibilidad con versiones más antiguas. Sin embargo, se recomienda que solamente se utilice las nuevas versiones de las definiciones de tablas. Esto facilita reutilizar el código en un contexto de Objetos ABAP. Se recomienda (en la medida de lo posible) el uso de FIELD-SYMBOLS para modificar una tabla interna, en vez de usar líneas de cabeceras (_WA_XXXX), por motivos de performance. 7.4. Declaración de campos de pantalla Esta sección se debe utilizar para la declaración de todos los campos que se mostrarán en la pantalla de inicio del programa y que permiten la selección de la información (PARAMETERS, SELECT-OPTIONS, ETC). No debe crearse un programa sin al menos un parámetro de selección. Esto posibilitará que al ejecutar el programa se muestre primero una pantalla de selección, con el título del programa y los campos de


- 13 -

selección, evitando que el usuario ejecute el programa por error. La declaración de parámetros de pantalla debe respetar el siguiente formato: Modelo ejemplo : *-------------------------------------------------- --------------------* * DISEÑO PANTALLA DE SELECCION *-------------------------------------------------- --------------------* SELECTION-SCREEN BEGIN OF BLOCK B_01 WITH FRAME TITLE TEXT- B01. PARAMETERS: P_BUKRS TYPE T001-BUKRS OBLIGATORY DEFAULT '10' , P_WERKS TYPE T001W-WERKS MEMORY ID WRK OBLIGATORY. SELECT-OPTIONS: S_BKLAS FOR MBEW-BKLAS NO INTERVALS NO-EXTENSION, S_MATNR FOR MSEG-MATNR. SELECTION-SCREEN END OF BLOCK B_01. SELECTION-SCREEN BEGIN OF BLOCK B_02 WITH FRAME TITLE TEXT- B02. PARAMETERS: P_LFMON TYPE MBEW-LFMON OBLIGATORY, P_LFGJA TYPE MBEW-LFGJA OBLIGATORY, P_WAERS TYPE T001-WAERS OBLIGATORY. SELECTION-SCREEN END OF BLOCK B_02. PARAMETERS: P_ALV RADIOBUTTON GROUP G1 DEFAULT 'X' , P_REL RADIOBUTTON GROUP G1, P_ALM_R AS CHECKBOX, P_STCK AS CHECKBOX DEFAULT 'X' . Donde: Deben posicionarse los distintos PARAMETERS y SELECT-OPTIONS, de acuerdo a la posición en la que se desea aparezcan en la pantalla. Debe comentarse cada parámetro declarado.

Este tipo de variables deben ser utilizadas como alternativa para evitar los “HARD_CODES” 7.5. Validación de campos de pantalla e inicialización En esta sección del programa se deben efectuar las validaciones de todos los campos de la pantalla de selección y realizar las inicializaciones de variables si corresponde. El formato es el que se muestra a continuación: *-------------------------------------------------- --------------------* * INICIALIZACION *-------------------------------------------------- --------------------* INITIALIZATION . PERFORM INICIALIZACION. *-------------------------------------------------- --------------------* * VALIDACION DE PARAMETROS DE PANTALLA *-------------------------------------------------- --------------------* AT SELECTION- SCREEN OUTPUT. AT SELECTION- SCREEN ON VALUE-REQUEST FOR P_WAERS. PERFORM HELP_WAERS USING P_WAERS. AT SELECTION- SCREEN ON BLOCK B_01. AT SELECTION- SCREEN ON P_BUKRS.


- 14 -

AT SELECTION- SCREEN. Donde: Toda validación que se realice sobre los parámetros de entrada debe efectuarse utilizando estos eventos. De esta manera, se enviarán los mensajes de error o información sobre la pantalla de selección, posibilitando de esa manera que el usuario corrija el error según corresponda. Pueden crearse subrutinas del tipo PERFORM para agrupar las validaciones correspondientes a un evento de este tipo y de esa manera mejorar la modularización del programa, facilitando los probables cambios posteriores. El evento INITIALIZATION debe utilizarse para cargar previamente a su utilización las variables deseadas. Podrá crearse una subrutina para agrupar todas las inicializaciones y modular el programa. 7.6. Rutina principal del programa Esta sección del programa representa el cuerpo principal de código y debe utilizarse para la extracción de la información en las bases de datos o en su defecto codificar el “nudo” del desarrollo. El formato es el que se muestra a continuación: *-------------------------------------------------- --------------------* * START-OF-SELECTION *-------------------------------------------------- --------------------* * BDL: Base de datos lógica utilizada – Nº pantalla *-------------------------------------------------- --------------------* START-OF-SELECTION. * Realizar aquí todos los procesos necesarios para recuperar la * información de la bases de datos, ya sea utilizan do una BDL o no. * Tratar de agrupar código en subrutinas. * La información debe tratar de almacenarse en tabl as internas. GET BKPF. GET BSEG. GET BKPF LATE. CLEAR GWA_XXXX. MOVE-CORRESPONDING BKPF TO GWA_XXXX. MOVE-CORRESPONDING BSEG TO GWA_XXXX. APPEND GWA_XXXX TO GDT_XXXX. * Si no usas BDL incluir aquí métodos o subrutinas GO_APLICACION->GET_DATOS( IMPORTING EDT_DATA = GDT_DATA ). PERFORM ALV. La rutina principal del programa siempre debe comenzar con el evento START-OF-SELECTION. Comentar el bloque principal del programa, indicando en el caso de utilizar una BDL, cuál es la pantalla de selección que utiliza, así como también incluir todo comentario de interés sobre la funcionalidad de la rutina. Los datos leídos deben almacenarse en una tabla interna para después de realizada la selección controlar que se haya efectuado con éxito. Pueden crearse subrutinas del tipo PERFORM para agrupar el código y de esa manera mejorar la modularización del programa, facilitando la lectura y los probables cambios posteriores.


- 15 -

7.7. Tratamiento de los datos obtenidos Esta sección del programa debe ser utilizada para codificar el tratamiento de los datos obtenidos en la sección anterior. El formato es el que se muestra a continuación: *-------------------------------------------------- --------------------* * FIN DE SELECCION DE DATOS *-------------------------------------------------- --------------------* END- OF-SELECTION. * Debe verificarse que la búsqueda de la informació n en las * bases de datos fue exitosa. Si esto no fuera así, deberá terminarse * el programa enviando un mensaje de aviso al usuar io, para que revise * la selección efectuada IF GDT_XXXX[] IS INITIAL . MESSAGE S000(ZXX) DISPLAY LIKE 'E' . STOP. ENDIF. * en esta sección debe codificarse la parte del pro ceso referida a * la generación de la salida, ya sea un reporte, un call transaction o * o alguna otra funcionalidad. * Debe tratar de agruparse el código en subrutinas. PERFORM SUBRUTINA USING GS_CAMPO1 GI_CAMPO2. PERFORM DATOS. Una vez verificado que el programa tiene datos para trabajar, debe codificarse en una subrutina todo lo que haga falta para complementar los datos seleccionados, ordenarlos, etc. Por ultimo, se creará una subrutina adicional donde se codificarán las sentencias necesarias para emitir el reporte. (WRITE, ALV, etc.) 7.8. Evento s de control Esta sección del programa debe ser utilizada para codificar todos los posibles eventos de control, que son aquellos que se disparan una vez generada la salida. El formato es el que se muestra a continuación: *-------------------------------------------------- --------------------* * EVENTOS DE CONTROL *-------------------------------------------------- --------------------* TOP-OF- PAGE. END- OF- PAGE. TOP-OF- PAGE DURING LINE -SELECTION. AT LINE -SELECTION. AT PFNN. AT USER-COMMAND. Donde: No es necesaria la codificación de la totalidad de los eventos sino solamente los estrictamente necesarios. No tienen un orden establecido.


- 16 -

7.9. Subrutinas internas Es la última sección del programa. Deben codificarse en esta todas las subrutinas internas que son llamadas en el programa. El formato es el que se muestra a continuación: *-------------------------------------------------- --------------------* * SUBRUTINAS *-------------------------------------------------- --------------------* *-------------------------------------------------- --------------------* * Form INICIALIZACION *-------------------------------------------------- --------------------* * Documentar aquí la funcionalidad de la subrutina * *-------------------------------------------------- --------------------* FORM INICIALIZACION. ENDFORM. "INICIALIZACION *-------------------------------------------------- --------------------* * Form SUBRUTINA *-------------------------------------------------- --------------------* * Documentar aquí la funcionalidad de la subrutina * *-------------------------------------------------- --------------------* * --> p1 documentar parámetros de entrada * <-- p2 documentar parámetros de salida *-------------------------------------------------- --------------------* FORM SUBRUTINA USING PI_PAR1 PI_PAR2. DATA: LD_CAMPO1 TYPE D. "Adicionar comentario . . . ENDFORM. " SUBRUTINA Donde: Debe respetarse el formato mostrado en el ejemplo de arriba. Este formato se obtiene automáticamente en el momento de creación del PERFORM, haciendo doble clic sobre el nombre de la sub-rutina. En el encabezado de la sub-rutina debe comentarse la funcionalidad principal de la misma, así como también cada uno de los parámetros pasados, comentando su contenido.


- 17 -

8. Convención para nombres internos ABAP4/SAP �� Se detalla a continuación la nomenclatura que debe respetarse en la codificación de programas ABAP. Se recomienda incluir dentro del nombre (en la parte libre) el mismo nombre de variable que el campo de SAP. Ej.: GS_BUKRS

Objeto de programación Ámbito Tipo Dato Valor Ejemplo

TABLA INTERNA

global sin tipo gt_<nombre tabla> gt_makt

global estándar gdt_<nombre tabla> gdt_makt

global sorted gst_<nombre tabla> gst_makt

global hashed ght_<nombre tabla> ght_makt

local sin tipo lt_<nombre tabla> lt_makt

local estándar ldt_<nombre tabla> ldt_makt

local sorted lst_<nombre tabla> lst_makt

local hashed lht_<nombre tabla> lht_makt

static sin tipo st_<nombre tabla> st_makt

static estándar sdt_<nombre tabla> sdt_makt

static sorted sst_<nombre tabla> sst_makt

static hashed sht_<nombre tabla> sht_makt

ESTRUCTURA global sin tipo gwa_<nombre estructura > gwa_mara

local sin tipo lwa_<nombre estructura > lwa_mara

static sin tipo swa_<nombre estructura> swa_mara

VARIABLE

global

C caracter gs_<nombre variable> gs_texto

N cadena numérica gn_<nombre variable> gn_num3

D fecha gd_<nombre variable> gd_budat

T hora gh_<nombre variable> gt_uzeit

X byte (hexadecimal) gx_<nombre variable> gx_byte

I entero gi_<nombre variable> gi_edad

P numero empaquetado gp_<nombre variable> gp_total

F numero punto flotante gf_<nombre variable> gf_total

otro g_<nombre variable> g_monto

local

C caracter ls_<nombre variable> ls_texto

N cadena numérica ln_<nombre variable> ln_num3

D fecha ld_<nombre variable> ld_budat

T hora lh_<nombre variable> lt_uzeit

X byte (hexadecimal) lx_<nombre variable> lx_byte

I entero li_<nombre variable> li_edad

P numero empaquetado lp_<nombre variable> lp_total

F numero punto flotante lf_<nombre variable> lf_total

otro l_<nombre variable> l_monto

static

C caracter ss_<nombre variable> ss_texto

N cadena numérica sn_<nombre variable> sn_num3

D fecha sd_<nombre variable> sd_budat

T hora sh_<nombre variable> st_uzeit

X byte (hexadecimal) sx_<nombre variable> sx_byte

I entero si_<nombre variable> si_edad

P numero empaquetado sp_<nombre variable> sp_total

F numero punto flotante sf_<nombre variable> sf_total

otro s_<nombre variable> s_monto

PARÁMETROS (de una rutina FORM)

sin ámbito sin tipo

using pi_<nombre variable> pi_menge

changing po_<nombre variable> po_meins

tables pt_<nombre variable> pt_ekpo

PARÁMETRO DE ENTRADA sin ámbito sin tipo p_<nombre parámetro> p_ bukrs

SELECT-OPTIONS sin ámbito sin tipo s_<nombre select-option> s_bukrs

BLOCKS SELECTION SCREEN

sin ámbito sin tipo b_<nombre del bloque> b_01


- 18 -

RANGOS

global sin tipo gr_<nombre rango> gr_bukrs

local sin tipo lr_<nombre rango> lr_bukrs

static sin tipo sr_<nombre rango> sr_bukrs

CONSTANTES

global sin tipo gc_<nombre constante> gc_edad_max

local sin tipo lc_<nombre constante> lc_edad_max

FIELD SYMBOL

global - g<tipo>_<nombre del objeto apuntado>

<gs_matnr> <gwa_makt>

local - l<tipo>_<nombre del objeto apuntado>

<ls_matnr> <lwa_makt>

SUBRUTINAS sin ámbito sin tipo

<nombre subrutina> El uso de using changing y tables dependerá de la necesidad de la misma por contar con variables globales.

imprime_reporte

MACROS sin ámbito sin tipo <nombre macro> llena_fieldcat

TIPOS global sin tipo gty_<nombre tipo> gty_mara

local sin tipo lty_<nombre tipo> lty_mara

TIPOS TABLA

global

sin tipo gtyt_<nombre tipo tabla> gtyt_makt

estándar gtyd_<nombre tipo tabla> gtyd_makt

sorted gtys_<nombre tipo tabla> gtys_makt

hashed gtyh_<nombre tipo tabla> gtyh_makt

local

sin tipo ltyt_<nombre tipo tabla> ltyt_makt

estándar ltyd_<nombre tipo tabla> ltyd_makt

sorted ltys_<nombre tipo tabla> ltys_makt

hashed ltyh_<nombre tipo tabla> ltyh_makt

CLASES global sin tipo gcl_<nombre objeto> gcl_reporte

local sin tipo lcl_<nombre objeto> lcl_reporte

OBJETOS

global sin tipo go_<nombre objeto> go_alv

local sin tipo lo_<nombre objeto> lo_alv

static sin tipo so_<nombre objeto> so_alv

PARÁMETROS DE MÓDULO DE FUNCIONES

global importing parámetro IP_<nombre parámetro> ip_matnr

global importing

estructura IW_<nombre estructura> iw_makt

global importing tabla IT_<nombre de la tabla> it_ekpo

global exporting

parámetro EP_<nombre parámetro> ep_matnr

global exporting estructura EW_<nombre estructura> ew_makt

global exporting

tabla ET_<nombre de la tabla> et_ekpo

global modify parámetro MP_<nombre parámetro> mp_matnr

global modify

estructura MW_<nombre estructura> mw_makt


- 19 -

global modify

tabla MT_<nombre de la tabla> mt_ekpo

tables tabla T_<nombre de la tabla> t_datos

PARÁMETROS DE MÉTODOS DE CLASES

global importing parámetro IP_<nombre parámetro> ip_matnr

global importing

estructura IW_<nombre estructura> iw_makt

global importing tabla IT_<nombre de la tabla> it_ekpo

global importing

clase IC_<nombre de la clase> ic_reloj

global exporting parámetro EP_<nombre parámetro> ep_matnr

global exporting

estructura EW_<nombre estructura> ew_makt

global exporting tabla ET_<nombre de la tabla> et_ekpo

global exporting

clase EC_<nombre de la clase> ec_reloj

global changing parámetro CP_<nombre parámetro> cp_matnr

global changing

estructura CW_<nombre estructura> cw_makt

global changing tabla CT_<nombre de la tabla> ct_ekpo

global changing

clase CC_<nombre de la clase> cc_reloj

global returning parámetro RP_<nombre parámetro> rp_matnr

global returning

estructura RW_<nombre estructura> rw_makt

global returning tabla RT_<nombre de la tabla> rt_ekpo

global returning

clase RC_<nombre de la clase> rc_reloj


- 20 -

9. RECOMENDACIONES GENERALES SOBRE FORMATO �� En los puntos siguientes se detallan las normas generales que rigen para el formato del entorno de desarrollo y que pueden formar parte de un programa ABAP. 9.1. Subrutinas (FORMS) Las subrutinas internas en el programa ABAP deben utilizarse en los siguientes casos: � Para englobar partes de código compleja y extensa. � Para hacer más legible el programa y brindar una mayor facilidad de mantenimiento. � Para definir un proceso una sola vez en el programa, el cual es llamado desde diferentes lugares dentro

del mismo programa ABAP Los FORMS deben respetar el siguiente formato: � La cantidad de líneas de código no debe tener más de una página de longitud en promedio. � Su nombre y el nombre de los parámetros deben respetar lo descrito anteriormente en la Convención

para nombres internos ABAP/4 Debe incluir comentarios sobre la funcionalidad principal y parámetros de entrada y salida. 9.2. Programas INCLUDE Los programas INCLUDE (tipo “I” en sus atributos), pueden utilizarse en los siguientes casos: � Para estructurar programas con muchas líneas de código. � Para generar código re-utilizable en otros programas. � Para definir FORMS utilizables por otros programas (Ejemplo: Rutinas de programas BATCH-INPUT). Si existe un gran número de declaración de data necesaria como parte del programa, debe separarse las declaraciones dentro de un INCLUDE. El nombre del include debe ser el mismo del programa con el sufijo TOP. Los siguientes includes deberán ser utilizados en los programas a implementarse. Include Contiene ZMSTNNNN_TOP Todas las declaraciones iniciales. Ejm: tablas, estructuras, variables, Type-Pools,

table Controls, etc. Adicionalmente se puede utilizar para la definición de los métodos de una clase.

ZMSTNNNN_SEL Los parámetros de selección. ZMSTNNNN_MAI El proceso principal y los eventos. Ejm: INITIALIZATION. START-OF-

SELECTION, AT SELECTION SCREEN, etc. ZMSTNNNN_F01 Las subrutinas del programa. ZMSTNNNN_O01 Process Before Output. Los modules output. ZMSTNNNN_I01 Process After Input. Los modules input. ZMSTNNNN_CLA La implementación de todos los métodos de una clase. La codificación de INCLUDE debe respetar los convenios de nombres internos y estándares de programación descritos en los puntos anteriores. Los nombres de los includes tienen como prefijo el nombre del programa, cuya nomenclatura será tratada más adelante.


- 21 -

9.3. Cabeceras de listados Todos los programas ABAP desarrollados que emitan un reporte (Report List – WRITE), deben mantener el siguiente formato de salida: *----------------------------------------------------------------------------------------------------------------------------------------------- XXXXXXXXXXXXXXXXXXXX (1) XXXXXXXXXXXXXXXXXXXXXXXXXX (2) 99/99/9999 (3) XXXXXXXX (4) XXXXXXXXXXXXXXXX (5) Pag.: 9999 (6) XXXXXXX (7) XXXXXXXXXXXXXXXXXX (7) XXXXXXXXX (7) XXXXXXXX (7) *----------------------------------------------------------------------------------------------------------------------------------------------- Donde: (1) Nombre de la sociedad. Corresponde al campo T001-BUKRS. (2) Título del reporte. Debe mostrarse en letra mayúscula. (3) Fecha de emisión del reporte. Mostrar en formato DD/MM/AAAA. (4) Nombre del reporte. Corresponde al campo de sistema SY-REPID. (5) Subtítulo del listado. Es opcional y en caso de utilizarse debe ser mostrado en letra mayúscula. (6) Número de página. (7) Cabeceras de columnas. Mostrar en letras mayúsculas. Estos campos en la cabecera del reporte deben figurar siempre, independientemente de si se utilizan los títulos standard de los elementos de texto o si se los codifica manualmente mediante el evento TOP-OF-PAGE. 9.4. Textos de selección Los textos de selección correspondientes a los PARAMETERS y SELECT-OPTIONS declarados en el programa deben ser incorporados en letra minúscula. 9.5. Símbolos de texto Podrán utilizarse en letra minúscula o mayúscula dependiendo del lugar donde se mostrará, de acuerdo a las normas que figuran en este documento. Deben ser utilizados en todas las sentencias WRITE, evitando colocar en las mismas literales. 9.6. Pantallas En el diseño de pantallas se debe tratar de mantener siempre los estándares de diseño empleados por SAP, para ello, se debe respetar lo siguiente: � Todos los textos de los campos deben figurar en letras minúsculas. � Tratar de aprovechar las referencias a los campos del diccionario de datos. � Utilizar FRAMES para enmarcar campos relacionados. � Ubicar los campos de tal manera que facilite su llenado por parte del usuario


- 22 -

9.7. Dynpros, Status y Títulos Para la creación de cada uno de estos objetos, la nomenclatura a seguir será números correlativos de 4 dígitos con intervalos de 100 en 100, es decir, 0100, 0200, etc., guardando asociación entre los 3 objetos mediante el mismo número de codificación. Por ejemplo a la dynpro 0100 está asociada el status 0100 y el título 0100. De darse el caso que dos dynpros estén reutilizando algún objeto en particular, se debe, mantener la integración en código de los tres objetos, es decir, Dynpro: 0100 -> Status: 0100 -> Título: 0100 Dynpro: 0200 -> Status: 0100 -> Título: 0200 Dynpro: 0300 -> Status: 0300 -> Título: 0300 Como se observa el Status 0200 no se ha tomado, en caso, a futuro la Dynpro 0200 necesite poseer su propio status. Elementos de Dynpros Para el diseño de una dynpro es necesario el uso de elementos de dynpros, para los cuáles usaremos la siguiente nomenclatura para los nombres de campo, dependiendo del elemento a utilizar: Elemento Nomenclatura Campo de Texto TF_<nombre campo texto> Campo Entrada/Salida PF_<nombre campo entrada/salida> CheckBox CB_<nombre CheckBox> Radio Button RB_<nombre Radio Button> PushButton PB_<nombre Push Button> Marco GB_<nombre Marco> Control de TabStrip SC_<nombre TabStrip> Área SubScreen SA_<nombre Subscreen Area> Table Control TC_<nombre Table Control> Custom Control CC_<nombre Custom Control> Status Icon SI_<nombre Status Icon> Nota: Como es conocido, estos elementos pueden ser obtenidos también vía referencia ya sea del Diccionario de datos o también de las variables que posee el programa, en dicho caso el nombre del objeto cargado en la dynpro se mantendrá con el nombre que se coloca automáticamente al jalar el objeto con la referencia determinada. Además es posible indicar un nombre de campo precedido por un '*' cuando se trata de la misma referencia al Diccionario de datos ABAP/4. 9.8. Status GUI En su diseño debe tenerse en cuenta lo siguiente: � Utilizar hasta donde sea posible los defaults propuestos por SAP en lo que respecta a las funciones y

menús. � Los títulos de la superficie deben ser completados en minúscula y deben ser llamados igual que la

superficie. � En toda superficie debe asegurarse que figuren las funciones de BACK, CANCEL y EXIT � El texto de los pulsadores creados debe estar en letra minúscula.


- 23 -

9.9. Patrones Se llevará a cabo el manejo de patrones, para mantener una misma organización en el diseño de nuestros programas. Para hacer uso de ello, dentro del editor ABAP, hacer clic en MODELO, clic en “Otro patrón” e ingresar uno de los siguientes valores: � PAT_GEN: Plantilla de encabezado inicial � PAT_TOP: Plantilla de declaraciones globales. � PAT_SEL: Plantilla de parámetros de selección. � PAT_MAI: Plantilla de validaciones y eventos del programa principal. � PAT_MOD: Plantilla de encabezado para modificaciones

Nota: Las secciones no utilizadas de los patrones, se eliminan del programa. Ejemplo: Si uso el patrón TOP, y no voy a usar constantes, borramos esa sección de nuestro programa (no la comentamos).


- 24 -

10. ASEGURAMIENTO DE CALIDAD EN DESARROLLOS ABAP �� En los puntos siguientes se detallan algunas recomendaciones a tomar en cuenta en la programación. 10.1. Codificación y Presentación Consideraciones Ejemplos

Nuevas formas de declarar las sentencias en ABAP EC C6.0

No usar LIKE como referencia a tipos de diccionario, usar TYPE.

Incorrecto: DATA: GWA_KNA1 LIKE KNA1. Correcto: DATA: GWA_KNA1 TYPE KNA1.

Se debe de especificar la longitud de la variable que se está definiendo.

Incorrecto: TYPES: GS_X, GP_Y TYPE P. Correcto: TYPES: GS_X TYPE C LENGTH 1, GP_Y TYPE P LENGTH 8 DECIMALS 0.

Los parámetros que se pasan a un método debe tener asignado un tipo, si no se sabe qué tipo va a tener asignado se declara como type ANY.

Incorrecto: METHODS METH IMPORTING P1 EXPORTING P2. Correcto: METHODS METH IMPORTING P1 TYPE ANY EXPORTING P2 TYPE ANY.

No está permitido transferir directamente los campos del sistema como parámetro, sino a través de una variable.

Incorrecto: CALL FUNCTION FUN IMPORTING P = SY-SUBRC. Correcto: DATA: LI_SUBRC TYPE SY-SUBRC. LI_SUBRC = SY-SUBRC. CALL FUNCTION FUN IMPORTING P = LI_SUBRC.

La sentencia TABLES no está permitido en ABAP objects, porque es ambigua. Una forma de referenciarlo es a través de un work area.

Incorrecto: TABLES: BKPF. Correcto: DATA: GWA_BKPF TYPE BKPF.

No está permitido el uso de Field-Symbols si es que no tiene un tipo de asignación. En ABAP objects la adición type al field-symbols es obligatorio.

Incorrecto: FIELD-SYMBOLS: <G_VALUE>. Correcto: FIELD-SYMBOLS: <G_VALUE> TYPE ANY.

El uso de RANGES no está permitido.

Incorrecto: RANGES: GR_VKORG FOR KNA1-VKORG. Correcto: DATA: GR_VKORG TYPE RANGE OF KNA1-VKORG.

La declaración con OCCURS no está permitida. Si se requiere memoria inicial se puede especificar agregando la sentencia INITIAL SIZE.

Incorrecto: DATA: BEGIN OF GT_KNA1 OCCURS 0, KUNNR TYPE KNA1-KUNNR, NAME1 TYPE KNA1-NAME1, END OF GT_KNA1. Correcto: TYPES: BEGIN OF GTY_KNA1 , KUNNR TYPE KNA1-KUNNR, NAME1 TYPE KNA1-NAME1, END OF GTY_KNA1. DATA: GDT_KNA1 TYPE STANDARD TABLE OF GTY_KNA1 INITIAL SIZE 0.

Si utilizas work areas para hacer LOOP a la tabla interna, no está permitido hacer CLEAR dentro del LOOP, ya que esta borraría todo el contenido de la tabla interna.

Incorrecto: LOOP AT GT_KNA1 INTO GWA_KNA1. CLEAR GT_KNA1. ….. ENDLOOP. Correcto: LOOP AT GT_KNA1 INTO GWA_KNA1. CLEAR GWA_KNA1. ….. ENDLOOP. CLEAR GT_KNA1.

Las siguientes sentencias en relación con las tablas internas están prohibidas ya que no está permitido trabajar directamente con la cabecera de la tabla interna; por el contrario ahora se utilizan work areas o field-symbols.

Incorrecto: INSERT TABLE GT_BKPF. COLLECT GT_BKPF. READ TABLE GT_BKPF… MODIFY TABLE GT_BKPF… MODIFY GT_BKPF… WHERE … DELETE TABLE GT_BKPF. LOOP ATGT_BKPF…


- 25 -

APPEND GT_BKPF… INSERT GT_BKPF… MODIFY GT_BKPF… Correcto: INSERT GWA_BKPF INTO TABLE GT_BKPF. COLLECT GWA_BKPF INTO GT_BKPF. READ TABLE GT_BKPF INTO GWA_BKPF/ ASSIGNING <G_BKPF>... MODIFY TABLE GT_BKPF FROM GWA_BKPF… MODIFY GT_BKPF FROM GWA_BKPF WHERE … DELETE TABLE GT_BKPF FROM GWA_BKPF. LOOP AT GT_BKPF INTO GWA_BKPF/ASSIGNING <G_BKPF>… APPEND GWA_BKPF TO GT_BKPF… INSERT GWA_BKPF … MODIFY GWA_BKPF …

Las siguientes sentencias en relación con el acceso a la base de datos están prohibidas. Se debe de trabajar utilizando work areas.

Incorrecto: SELECT … FROM VBAK. INSERT VBAK. UPDATE VBAK. DELETE VBAK. MODIFY VABK. Correcto: DATA: GWA_VBAK TYPE VBAK. SELECT … FROM VBAK INTO GWA_VBAK . INSERT VBAK FROM GWA_VBAK. OR INSERT INTO VBAK VALUES GWA_VBAK. UPDATE VBAK FROM GWA_VBAK. OR UPDATE VBAK SET . . . DELETE VBAK FROM GWA_VBAK. OR DELETE FROM VBAK WHERE… MODIFY VBAK FROM GWA_VBAK.

Valores Fijos (HARDCODE)

Los valores no deben ser fijados en el código fuente. La existencia de valores fijos dentro del programa dificulta su mantenimiento, portabilidad y reutilización. Además, demuestra desprolijidad en el diseño.

Incorrecto: SELECT * FROM marc WHERE werks EQ ‘5000’ … IF vbfa-vbtyp_n EQ ‘J’ … w_cost = mbew-strps * 1.2. Correcto: Para evitar fijar valores, se pueden utilizar parámetros de selección o la tabla de constantes. Cuando no es posible evitar fijar valores, utilizarlos como constantes globales. CONSTANTS: gc_constante TYPE n LENGTH 4 VALUE 1234. DATA: gn_global TYPE n LENGTH 4, ... IF wn_global NE gc_constante ….. Excepciones: Programas de conversión que serán utilizados solo una vez.

Eventos

Los eventos (END-OF-SELECTION, TOP-OF-PAGE, etc.) deberán aparecer, en lo posible, en el código, en el orden en que serán utilizados. Si algún evento no estuviese siendo utilizado, deberá ser retirado. Todas las Subrutinas (FORMs) serán colocadas después del código principal en un INCLUDE de FORMs. Los FORMs deberán ser colocados, en lo posible, en el orden en que serán llamados.

Correcto: INITIALIZATION. ... AT SELECTION-SCREEN. ... START-OF-SELECTION. PERFORM cargar_datos. PERFORM procesar_datos. PERFORM imprimir_datos. … END-OF-SELECTION. … FORM cargar_datos. … ENDFORM FORM procesar_datos. … ENDFORM FORM imprimir_datos. … ENDFORM


- 26 -

Subrutinas (FORM)

El nombre de la subrutina deberá ser descriptivo, y comenzar con un verbo en infinitivo + el objeto. Por ejemplo: PERFORM buscar_proveedor. PERFORM grabar_pedido. PERFORM calcular_iva_factura. Toda Subrutina también debe tener un encabezado conteniendo una breve descripción de su funcionalidad y los parámetros de entrada y salida. Una Subrutina deberá tener solo un proceso principal. En caso de que haya más de un proceso, entonces deberá ser dividida en múltiples Subrutinas. Subrutinas que podrían ser utilizadas en otros programas deberán ser colocadas en un Function Module. Los parámetros de entrada de una subrutina deberán ser definidos utilizando la palabra clave USING, y deberán pasarse por valor (palabra clave “USING VALUE(var)” en todos los casos en que pueda utilizarse un literal en la llamada PERFORM. Los parámetros de salida de una subrutina deberán ser definidos utilizando la palabra clave CHANGING.

Correcto: *------------------------------------------------------* * Form GUARDAR_ULTIMA_EJECUCION *------------------------------------------------------* * Lee la tabla ZZLRT donde la última Fecha y * hora de ejecución del programa es guardada *------------------------------------------------------* * � PI_JOBID código interno de JOB * PO_STATUS resultado proceso *------------------------------------------------------* FORM GUARDAR_ULTIMA_EJECUCION USING PI_JOBID CHANGING PO_STATUS. … … ENDFORM.

Anidamiento

Las estructuras IF-ENDIF, LOOP-ENDLOOP, CASE-ENDCASE, DO-ENDDO, etc. no deberán presentar una extensión excesiva en cuanto a la longitud de líneas ni a profundidad (anidamiento). Se deberá llegar a un equilibrio de estas características utilizando subrutinas. Para esto se debe estructurar el módulo teniendo en cuenta los conceptos de cohesión y acoplamiento.

Correcto: CASE ln_var: WHEN ‘01’. PERFORM procesar_opcion_01. WHEN ‘02’. PERFORM procesar_opcion_02. WHEN ‘01’. PERFORM procesar_opcion_03. WHEN OTHERS PERFORM procesar_opcion_otros. ENCASE.

Comandos

Cada comando deberá comenzar en una nueva línea para una mejor visualización del código. De esta forma, permitirá un mejor mantenimiento del código (borrado, comentario y debugging). Para mantener los programas estructurados, deberemos indentar los diferentes niveles de jerarquía con 2 espacios. El PRETTY PRINTER podrá ser utilizado para indentar automáticamente los comandos. Comandos largos deberán ser particionados en varias líneas e indentados por la primera línea para permitir una mejor visualización.

Incorrecto: START-OF-SELECTION. SELECT matnr werks lgort labst FROM mara INTO TABLE gt_stock_mat WHERE matnr in s_matnr. IF sy-subrc NE 0. MESSAGE E001. ENDIF. END-OF-SELECTION. Correcto: START-OF-SELECTION. SELECT matnr werks lgort labst FROM mara INTO TABLE gt_stock_mat WHERE matnr in s_matnr. IF sy-subrc NE 0. MESSAGE E001. ENDIF. END-OF-SELECTION. PERFORM IMPRIMIR_TOTALES.

Agrupación de Variables Globales

Siempre que se utilicen variables relacionadas entre sí, deberán declararse como campos de una estructura y no como variables “sueltas”.

Como las tres variables están relacionadas porque definen un nro. de asiento que se necesitar tratar en el programa:


- 27 -

Esto permite simplificar el desarrollo al poder manejarlas como una única estructura (asignaciones con move-corresponding, inicialización, pase de parámetros, etc.).

Incorrecto: DATA: LS_BUKRS_AUX LIKE BKPF-BUKRS, "SOCIEDAD LS_BELNR_AUX LIKE BKPF-BELNR, "DOCUMENTO SAP LN_GJAHR_AUX LIKE BKPF-GJAHR. "EJERCICIO Correcto: TYPES: BEGIN OF LTY_ASIENTO_AUX, BUKRS TYPE BKPF-BUKRS, "SOCIEDAD BELNR TYPE BKPF-BELNR, "DOCUMENTO SAP GJAHR TYPE BKPF-GJAHR, "EJERCICIO END OF LTY_ASIENTO_AUX. DATA: LWA_ASIENTO_AUX TYPE LTY_ASIENTO_AUX.

MOVE (asignaciones)

Utilizar sentencia MOVE en vez de MOVE-CORRESPONDING siempre que sea posible. En la definición de datos se debe de usar type en vez de like, también se debe evitar los OCCURS 0, with header line y trabajar con work áreas, field symbols.

Incorrecto: TYPES: BEGIN OF LTY_STOCK, MATNR TYPE MATNR, " CÓDIGO WERKS TYPE WERKS, " CENTRO LGORT TYPE LGORT, " ALMACÉN LABST TYPE LABST, " STOCK END OF LTY_STOCK. DATA: lt_stock_mat TYPE lty_stock OCCURS 0 WITH HEADER LINE. DATA: lwa_stock_mat LIKE mard. ... READ TABLE lt_stock_mat INDEX 1. IF sy-subrc EQ 0. MOVE-CORRESPONDING LT_STOCK_MAT TO LWA_STOCK_MAT... ENDIF. ... Correcto: TYPES: BEGIN OF LTY_STOCK, MATNR TYPE MATNR, " CÓDIGO WERKS TYPE WERKS, " CENTRO LGORT TYPE LGORT, " ALMACÉN LABST TYPE LABST, " STOCK END OF LTY_STOCK. DATA: LT_STOCK_MAT TYPE STANDARD TABLE OF LTY_STOCK. DATA: LWA_STOCK LIKE LINE OF LT_STOCK_MAT. DATA: LWA_STOCK_MAT TYPE MARD. ... READ TABLE LT_STOCK_MAT INTO LWA_STOCK INDEX 1. IF SY-SUBRC EQ 0. MOVE: lwa_stock-matnr to lwa_stock_mat-matnr, lwa_stock-werks to lwa_stock_mat-werks, lwa_stock-lgort to lwa_stock_mat-lgort, lwa_stock-labst to lwa_stock_mat-labst. ENDIF.

Mensajes

Todos los mensajes de error deberán ser implementados vía MESSAGE IDs.

Incorrecto: IF sy-subrc NE 0. WRITE: 'Error en la búsqueda'. ENDIF. Correcto: REPORT xxx MESSAGE-ID ‘ZMM01’. … IF sy-subrc NE 0. MESSAGE E001. ENDIF.

PARAMETROS / SELECTION SCREEN

Evite utilizar valores “DEFAULT” en los campos parameter / selection screen. Es preferible utilizar variantes . Incluya Ayuda de Búsqueda (MATCHCODES) cuando sea conveniente. Separe los grupos de parámetros relacionados en BLOCKS (frame) cuando sea conveniente. Siempre reemplace el nombre que genera por default el parámetro en pantalla por un texto descriptivo (TEXTO DE SELECCIÓN).


- 28 -

Textos (Literales)

Para todos los textos utilizados a lo largo del programa, utilice TEXT ELEMENTs.

Incorrecto: FORM titular_columnas. WRITE 'Nro.Cliente' to lwa_titulos-col01. WRITE 'Razón Social' to lwa_titulos-col02. WRITE 'CUIT' to lwa_titulos-col03. ENDFORM. Correcto: FORM titular_columnas. WRITE text-001 to lwa_titulos-col01. WRITE text-002 to lwa_titulos-col02. WRITE text-003 to lwa_titulos-col03. ENDFORM.

Código “Muerto”

No debe dejarse código muerto injustificado en los programas, ya que es desprolijo y dificulta el seguimiento y el debugging. Cuando esté justificado, dejar indicado con comentario el motivo. En el caso de modificaciones al programa original, dejar comentado el código reemplazado/corregido, con la correspondiente referencia de modificación.

* Se reemplaza el parámetro de salida por una variable auxiliar tipo N. CALL FUNCTION ‘CONVERSION_EXIT_ALPHA_OUTPUT’ EXPORTING input = t_stock_mat-matnr IMPORTING * output = t_stock_mat-matnr. “DELETE @001 output = ln_matnr_aux. “INSERT @001

Comentarios (1)

Todo el programa debe estar comentado, para facilidad de seguimiento, interpretación, mantenimiento y documentación. Los comentarios tienen sentido cuando explican y clarifican cada parte de la lógica del programa, no la exacta descripción de lo que hacen los comandos. Los comentarios deberán estar en minúscula. Puede comenzarse con mayúscula cada frase. El nivel de comentarios debe ser congruente en todo el programa. Evitar caer en la práctica de comentar todo el programa al final, una vez codificado. Esto genera que los comentarios no sean claros, se pierde la idea global del programa, y es proclive a errores. Además, el resultado es pobre, porque se comenta solo para “cumplir” y se pierde el objetivo de ayudar a entender el desarrollo del programa, así como también luego su mantenimiento y documentación.

Comentarios (2)

Deben comentarse todas las variables declaradas a la derecha de la variable con “.

Correcto: * Definición de Tablas TABLES: mara. " Maestro de materiales * Definición de constantes CONSTANTS: gc_long TYPE i VALUE 70. " Long. línea sep. * Declaración de Tipos TYPES: begin of gty_stockmat, matkl type matkl, " Grupo de Artículos matnr type matnr, " Numero de Material maktx type maktx, " Descripción del Material labst type labst, " Stock Libre end of gty_stockmat. * Definición de variables globales DATA: gi_lines type i. " Cant. reg. encontrados

Writes

Cuando se lista un campo numérico que presentaba decimales es necesario especificarlos por medio de una variable, además de indicar la moneda si guarda valores monetarios.

Incorrecto: WRITE T_LOG-NETWR. Correcto: DATA: L_WAERK TYPE VBRK-WAERK. WRITE LWA_LOG-NETWR CURRENCY L_WAERK UNIT ‘3’.


- 29 -

Estructuras

No incluir una estructura de una tabla como parte de la definición de una segunda tabla.

Incorrecto: DATA: BEGIN OF GT_BDCTAB OCCURS 0. INCLUDE STRUCTURE BDCDATA. DATA: END OF GT_BDCTAB. Correcto: TYPES: GTY_BDCDATA TYPE BDCDATA. DATA: GDT_BDCTAB TYPE STANDARD TABLE OF GTY_BDCDATA.

10.2. Performance Consideraciones Ejemplos

Consultas a Base de Datos (SELECTS)

Siempre que precise buscar solo una línea de una Tabla o View, use SELECT SINGLE * en lugar de SELECT *. ( SELECT SINGLE * accede una vez a la base de datos ) Especifique siempre los campos de la selección en lugar de usar SELECT * Al diseñar una tabla Z, trate de evitar que tenga muchos índices. Siempre especifique las condiciones en la cláusula WHERE en lugar de testearlas con el comando CHECK. Evite utilizar ORDER BY, a menos que exista un índice en estos campos. Utilice las funciones de cálculo (MAX, SUM, MIN....) en el comando SELECT en lugar de calcular los valores aparte. Esto minimiza el volumen de transferencia de datos y utiliza los algoritmos optimizados de la base de datos. Siempre testear SY-SUBRC después de un acceso a la Base de Datos. SELECT (para Transparent y Pool Tables): la cláusula WHERE debe contener, preferentemente, los campos claves y demás campos que puedan restringir la consulta. SELECT (para Cluster Tables): solo los campos claves deben ser especificados en la cláusula WHERE. Los demás deben ser chequeados a través del comando CHECK. Evite siempre utilizar ciclos SELECT – ENDSELECT. Es preferible realizar un SELECT INTO TABLE <tabla interna> y un LOOP AT <tabla interna> - ENDLOOP trabajando conjuntamente con el work área. Esto optimiza el acceso a la base de datos y evita problemas de debugg en algunas versiones de SAP R/3. En general, reduce el tiempo de procesamiento en los debugg. Evitar siempre reiterar el acceso a un mismo registro en la base de datos, así sea con un select single. El uso de los primeros n campos de un índice en la cláusula WHERE de un SELECT, proporciona una búsqueda más rápida. Es importante utilizar la cláusula WHERE en el comando SELECT. Siempre que la clave primaria

Incorrecto: SELECT matnr werks lgort labst FROM mard INTO CORRESPONDING FIELDS OF TABLE lt_stock_mat WHERE matnr IN s_matnr. EXIT. ENDSELECT. Correcto: SELECT SINGLE matnr werks lgort labst FROM mard INTO lwa_stock_mat WHERE matnr IN s_matnr. Incorrecto: SELECT * FROM mard INTO CORRESPONDING FIELDS OF TABLE lt_stock_mat WHERE matnr IN s_matnr. Correcto: SELECT matnr werks lgort labst FROM mard INTO TABLE lt_stock_mat WHERE matnr IN s_matnr. Incorrecto: l_msgnr_max = -1. SELECT MSGNR FROM T100 INTO LWA-MSGNR WHERE ARBGB EQ ‘00’ IF LWA-MSGNR > l_msgnr_max. l_msgnr_max = LWA-MSGNR. ENDIF. ENDSELECT. Correcto: SELECT MAX (MSGNR) FROM T100 INTO l_msgnr_max WHERE ARBGB EQ ‘00’ Incorrecto: SELECT matnr werks lgort labst FROM mard INTO lt_stock_mat WHERE matnr IN s_matnr. IF lt_stock_mat-labst NE 0. APPEND lt_stock_mat. ELSE. APPEND lt_stock_mat_nostock. ENDIF. ENDSELECT. Correcto: SELECT matnr werks lgort labst FROM mard INTO TABLE lt_stock_mat WHERE matnr IN s_matnr.


- 30 -

no pueda ser utilizada, los índices podrán ayudar. Primero intente acceder por la clave primaria completa o por algún índice completo. De no ser posible, acceda parcialmente por la clave primaria o índice, utilizando los campos en el orden establecido para la clave o índice.

lt_stock_mat_nostock[] = lt_stock_mat[]. DELETE lt_stock_mat WHERE labst = 0. DELETE lt_stock_mat_nostock[] WHERE labst <> 0 Si se necesita imprimir el nombre del cliente en la factura… con t_facturas-kunnr (cód. cliente) y t_facturas-name1 (nombre cliente) Incorrecto: LOOP AT T_FACTURAS. SELECT NAME1 FROM KNA1 INTO T_FACTURAS-NAME1 MODIFY T_FACTURAS. ENDLOOP. Correcto: TYPES: BEGIN OF lty_clientes, kunnr TYPE kunnr, "CÓD. CLIENTE name1 TYPE name1, "NOMBRE CLIENTE END OF lty_clientes. DATA: lt_clientes TYPE STANDARD TABLE OF lty_clientes. DATA: lwa_clientes LIKE LINE OF lt_clientes. * GENERAR MAESTRO DE CLIENTES IF NOT lt_facturas[] IS INITIAL. SELECT kunnr name1 FROM kna1 INTO TABLE lt_clientes FOR ALL ENTRIES IN lt_facturas WHERE kunrr = lt_facturas-kunnr. ENDIF. * BUSCAR NOMBRE DE CLIENTE POR CADA CLIENTE CON FACTURAS LOOP AT lt_facturas ASSIGNING <lwa_facturas>. READ TABLE lt_clientes INTO lwa_clientes WITH KEY kunnr = <lwa_facturas>-kunnr. IF sy-subrc EQ 0. <lwa_facturas>-kunnr = lwa_clientes_aux-kunnr. ENDIF. ENDLOOP.

Performance memoria dinámica.

TABLAS INTERNAS La manera más eficiente de buscar un único registro en una tabla interna del tipo standard es utilizando el comando: READ TABLE ... WITH BINARY SEARCH. Debiendo estar ordenada la tabla Interna. En caso de tener que repetir búsquedas sobre tablas, es conveniente seleccionar los datos una sola vez sobre una tabla interna, y trabajar sobre ella las veces que sea necesario. SORT El SORT de una tabla Interna, es más eficiente si los campos son especificados. Siempre identificar si un SORT es ascending o descending y especificar la cláusula BY <fields>. Caso contrario todos los campos serán clasificados. LOOP...WHERE El comando LOOP .... WHERE es más eficiente que el comando LOOP / CHECK, pues evalúa la condición internamente. Siempre usar los comandos CLEAR/ REFRESH después de finalizar un LOOP, cuando los datos no deban ser reutilizados.

Correcto: SORT GT_TABLA1 BY CAMPO1 ASCENDING. LOOP AT GT_TABLA1…. … ENDLOOP. SORT GT_TABLA2 BY CAMPO1 ASCENDING. LOOP AT GT_TABLA2…. … ENDLOOP. Incorrecto: LOOP AT ITAB. CHECK T_ABC = KVAL. ... ENDLOOP. Correcto: LOOP AT GT_ABC INTO GWA_ABC WHERE K = GS_VAL. … ENDLOOP.

Si dos tablas tienen la misma estructura, es más eficiente copiar el contenido de una a otra directamente y no a través de un LOOP.

Incorrecto: LOOP AT GT_VBAK INTO GWA_VBAK. APPEND GWA_VBAK TO GT_AUX. ENDLOOP. Correcto: GT_AUX[] = GT_VBAK[]. Sin embargo, si GT_AUX no está vacía y no debe de ser sobre-escrito entonces use:


- 31 -

APPEND LINES OF GT_VBAK TO GT_AUX.

Si se desea modificar un campo de una tabla interna, es más eficiente modificarlo especificando el campo.

Incorrecto: GWA-DATE = SY-DATUM. MODIFY GT_ITAB FROM GWA INDEX 1. Correcto: GWA-DATE = SY-DATUM. MODIFY GT_ITAB FROM GWA INDEX 1 TRANSPORTING DATE.

Para borrar entradas duplicadas dentro de una tabla interna es mejor ordenar la tabla y borrar los duplicados y no hacerlos dentro de un LOOP.

Incorrecto: READ TABLE GT_TAB INDEX 1 INTO GWA_PREV_LINE. LOOP AT GT_TAB FROM 2 INTO GWA. IF GWA = GWA_PREV_LINE. DELETE GT_TAB. ELSE. GWA_PREV_LINE = GWA. ENDIF. ENDLOOP. Correcto: SORT GT_TAB BY K. DELETE ADJACENT DUPLICATES FROM GT_TAB COMPARING K.

Se debe evitar el LOOP para averiguar el número de registros de una tabla.

Incorrecto: LOOP AT GT_TAB. LI_LINEAS = LI_LINEAS + 1. ENDLOOP. Correcto: DESCRIBE TABLE GT_TAB LINES LI_LINEAS.

Se deben evitar los SELECT anidados mientras dan lugar a un volumen grande de accesos de base de datos (dependientes en el tamaño de tablas). En lugar de ello utilizar FOR ALL ENTRES.

Correcto: IF NOT GT_TAB1[] IS INITIAL.

SELECT FIELD1 FIELD2 FROM TABLE INTO TABLE GT_TAB2

FOR ALL ENTRIES IN GT_TAB1

WHERE FIELD3 EQ GT_TAB1-FIELD3

AND FIELD4 IN S_FIELD.

ENDIF.

En ocasiones tenemos tablas internas muy pesadas y debemos de recorrer una dentro de otra, suponiendo que contamos con dos tablas internas gt_tab1 en donde hay m entradas y gt_tab2 donde hay n entradas, el número de vueltas sería m x n. Incluso, aunque hayamos puesto la cláusula WHERE. En estos casos, donde además ambas tablas tengan los mismos campos clave, se recomienda usar un índice interno para empezar la búsqueda en la segunda tabla, de esta forma se reducirá el número de vueltas.

Incorrecto: LOOP AT GT_TAB1. LOOP AT GT_TAB2 WHERE K = GT_TAB1-K. ... ENDLOOP. ENDLOOP. Correcto: LI_INDX = 1. LOOP AT GT_TAB1 INTO LWA_TAB1. READ TABLE GT_TAB2 WITH KEY K = GT_TAB1-K BINARY SEARCH TRANSPORTING NO FIELDS. IF SY-SUBRC EQ 0. LI_INDX = SY-TABIX. LOOP AT GT_TAB2 INTO LWA_TAB2 FROM LI_INDX. IF LWA_TAB2-K <> LWA_TAB1-K. EXIT. ENDIF. " ... ENDLOOP. ENDIF. ENDLOOP.

Siempre que sea posible, utilice operaciones con arreglos en lugar de operaciones sobre una fila. La frecuente comunicación entre el programa de aplicación y el sistema de la base de datos produce una considerable baja en la performance.

Incorrecto: * Tabla GT_TAB tiene 100 entradas. LOOP AT GT_TAB. INSERT INTO VERI_CLNT VALUES GT_TAB. ENDLOOP. Correcto: * Tabla GT_TAB tiene 100 entradas. INSERT VERI_CLNT FROM TABLE GT_TAB.

Si la tabla interna tiene muchas entradas, en una búsqueda lineal a través de todas las entradas el tiempo consumido es bastante largo. Trate de mantener la tabla ordenada y usar búsqueda binaria.

Incorrecto: READ TABLE GT_TAB WITH KEY k = ‘X’. Correcto: SORT GT_TAB BY K. ….. READ TABLE GT_TAB INTO LWA_TAB WITH KEY k = ‘X’ BINARY SEARCH.


- 32 -

10.3. Modularización y reutilización Consideraciones Ejemplos

Modularización

Los programas deben estar modularizados completamente. Esto significa que el programa principal consistirá de una serie de subrutinas (módulos), las cuales resumirán los procesos principales del programa. A su vez, cada, subrutina, se dividirá en forma coherente y balanceada en nuevas subrutinas, que dividirán nuevamente el módulo en subprocesos. Y así sucesivamente. La modularización se establece durante el diseño; implica comprender la complejidad total del programa y dividirla en partes (ó módulos). Cada modulo o rutina ejecutará solo una acción principal o proceso. A través de la modularización se divide un “problema” grande en problemas “pequeños”. Facilita la compresión y el seguimiento, y es clave para el mantenimiento de un programa. Los programas correctamente modularizados y parametrizados facilitan su reutilización

Correcto: START-OF-SELECTION. PERFORM buscar_datos. PERFORM calcular_porcentajes. PERFORM grabar_log. END-OF-SELECTION. PERFORM imprimir_reporte. PERFORM download_archivo. FORM buscar_datos. ... ENDFORM. FORM calcular_porcentajes. … ENDFORM. …

Parametrización de módulos

Solamente se deberán declarar variables globales cuando realmente este justificado. Nunca deberán declararse variables globales que solo sean utilizadas luego dentro de algún módulo. Utilizar pase de parámetros entre módulos. (USING, CHAGING, TABLES). Incluso cuando no fuera necesario el pase de parámetros desde el punto de vista técnico, siempre es recomendable indicarlo, de manera que sea más claro entender que la subrutina llamada, utiliza o modifica cierta variable.

Recomendable: DATA: gwa_stock_mat TYPE mard. START-OF-SELECTION. PERFORM buscar_datos_stock changing gwa_stock_mat. PERFORM imprimir_datos_stock using gwa_stock_mat. En este caso la variable gwa_stock_mat es global, si bien dentro de las rutinas la variable esta dentro de su ámbito de incumbencia y podría ser referenciada, colocar el parámetro clarifica el seguimiento, se observa entonces que el form BUSCAR_DATOS_STOCK modificará esa variable, y el form IMPRIMIR_DATOS_STOCK la utilizará.

Balanceo de la estructura de un programa

Los programas se deberán estructurar de manera que idénticos niveles de la estructura conserven el mismo nivel funcional.

Incorrecto: START-OF-SELECTION. PERFORM CARGAR_DATOS TABLES GT_DATA. PERFORM IMPRIMIR_CABECERA TABLES GT_DATA. PERFORM IMPRIMIR_DETALLE TABLES GT_DATA. Correcto: START-OF-SELECTION. PERFORM CARGAR_DATOS TABLES GT_DATA. PERFORM IMPRIMIR_DATOS TABLES GT_DATA. FORM IMPRIME_DATOS TABLES PT_DATA. PERFORM IMPRIMIR_CABECERA TABLES GT_DATA. PERFORM IMPRIMIR_DETALLE TABLES GT_DATA. ENDFORM.


- 33 -

Reutilización

Se deberá tener en cuenta al momento del diseño del programa, qué componentes del mismo podrán ser reutilizados en desarrollos similares. Para esto debe estar el desarrollo correctamente modularizado y parametrizado. Rutinas sin parámetros son muy difíciles de reutilizar. La reutilización mejora los tiempos de desarrollo, simplifica el proceso y evita “reinventar la rueda” constantemente. Es fundamental tener en cuenta todos las demás reglas y estándares de codificación en ABAP para poder convertir un programa o parte del mismo en material reutilizable y aprovechable. Un programa con errores de performance, o de codificación, no puede ser reutilizado. Un programa no modularizado o no parametrizado o con harcoding, no puede ser reutilizado. Un programa mal presentado o desprolijo, es muy difícil analizarlo para determinar su reutilización potencial.

Recomendable: Tipos reutilizables, grabarlos en TYPE-POOLS. Definiciones de variables reutilizables, grabarlos en INCLUDES Rutinas (FORMs) reutilizables, grabarlos en ROUTINES-POOL o INCLUDES. Rutinas (FORMs) reutilizables, con parámetros de entrada y salida, grabarlos en MODULOS DE FUNCIONES.


- 34 -

10.4. Verificación Ampliada Antes de transportar un programa al ambiente QAS, se debe verificar la sintaxis del mismo utilizando la herramienta Verificación Ampliada. Se puede acceder a esta herramienta a través de las siguientes opciones: � A través de la tx SLIN ó � A través del mismo programa, haciendo clic derecho en el programa -> Menú "Verificar" -> Opción

"Verificación Ampliada". Al ingresar, aparecerá una pantalla con unas opciones marcadas por defecto, marcar adicionalmente las opciones: Cadenas caracteres y Sentencias obsoletas. Presionar F8. Con esta herramienta se podrá verificar si el programa contiene errores o advertencias en las diferentes secciones y componentes del mismo. Nota: Ver imágenes: 10.4.a y 10.4.b. Existe además otra herramienta similar llamada CODE INSPECTOR. El Inspector de código es una herramienta para el control de objetos de repositorio que evalúa rendimiento, seguridad, sintaxis, y adhesión a nombre de convenciones. Se puede acceder a esta herramienta a través de la siguiente opción: � Clic derecho en el programa -> Menú "Verificar" -> Opción "Code Inspector". Nota: Ver imagen: 10.4.c.


- 35 -

10.5. Puntos a revisar en una OT WB previo al pase a PRD El objetivo de este punto es asegurar que los desarrollos a transportar a PRD: cumplan los estándares, sean programas seguros, se eviten errores técnicos en PRD y sean programas ágiles. � Verificar que las OTs no presenten cruce de versiones en la comparación de la OT de DEV versus PRD

(no debemos pasar cambios u objetos que no estén relacionados con el requerimiento de la OT – cambios no aprobados).

� Verificar que las OTs estén acumulando todas las versiones anteriores. � Verificar que la OT a pasar sea la más actualizada del requerimiento (versión final). � Revisar que se cumpla la nomenclatura de los objetos nuevos. � Revisar validaciones críticas: FOR ALL ENTRIES con tabla interna llena, READ TABLE con verificación

de SY-SUBRC EQ 0, FIELD SYMBOL con verificación de asignación previo a su invocación, etc. � Revisar consultas críticas que puedan afectar performance: SELECT SINGLES dentro de LOOPs,

LOOPs anidados, SELECT sin llave o índice, etc. � Ejecutar la tx SLIN o Verificación ampliada de los programas, revisar sólo los puntos que puedan

resultar críticos. � Revisar que no se pase código nuevo comentado (evitar que “código nuevo que hemos desechado”

pase a PRD). � Verificar que todos los cambios estén encerrados en marcas y tengan un encabezado de creación ó

modificación. � Verificar que si son programas nuevos deben validar un objeto de autorización y deben estar

registrados en la SU24. � Verificar que si son tablas Z deben estar asociados a un grupo de autorización.

� Verificar que datos organizacionales ó datos críticos no pasen por código duro sino por tabla de

constantes. � Revisar posibles dependencias (por ejemplo pasar una función cuyo grupo de funciones aún no está en

PRD).


- 36 -

11. NOMENCLATURA DE OBJETOS DE REPOSITORIO SAP �� TRANSACCION Los nombres de estos objetos tendrán la siguiente forma Z[MS][T][NNN] Donde: Z : Por definición SAP MS : Módulo SAP (Ver tabla 1) T : Tipo de Programa (ver tabla 2) NNN : Correlativo numérico Nota: El numeral [NNNN] debe ser el mismo en el nombre del programa y en la transacción (sin el 0 inicial), por lo que será utilizado sólo una vez. Ejemplo, si el programa es ZMMR0023, la transacción respectiva es ZMMR023. Si se encontrara algún espacio en los correlativos de txs, utilizar dichos espacios para las nuevas txs a crear. Ejm: Si en el sistema existe la tx ZFIP001, ZFIP003, ZFIP004..., utilizar el nombre ZFIP002 como nueva tx a crear. Transacción Copia Estándar Las txs copias de un estándar deben evitarse y validarse con el Supervisor ABAP, en su lugar debe buscarse la forma de ampliar la tx estándar. Sólo en caso aplicara y se aprobara la creación de la copia, los nombres de estos objetos tendrán la siguiente forma Z[TX_ORI] , donde TX_ORIG es el nombre de la tx Original. Ejm: ZQA33. PROGRAMA Los nombres de estos objetos tendrán la siguiente forma Z[MS][T][NNNN] Donde: Z : Por definición SAP MS : Módulo SAP (ver tabla 1) T : Tipo de programa (ver tabla 2) NNNN : Correlativo numérico Ejm: ZFIR0001 INCLUDE Los nombres de estos objetos tendrán la siguiente forma Z[MS][T][NNNN]_XXX Include Contiene ZMSTNNNN_TOP Todas las declaraciones iniciales. ZMSTNNNN_SEL Los parámetros de selección iniciales. ZMSTNNNN_MAI El proceso principal y los eventos. ZMSTNNNN_F01 Las subrutinas del programa. ZMSTNNNN_O01 Process Before Output. ZMSTNNNN_I01 Process After Input. ZMSTNNNN_CLA Implementación de todos los métodos de una clase.


- 37 -

INCLUDE GENÉRICO Si se crea un include con rutinas generales que va a ser utilizado por cualquier programa, se utilizará la siguiente forma Z[MS][IN_[X…X] Donde: Z : Por definición SAP MS : Módulo SAP (ver tabla 1) IN : Constante X…X : Descripción literal Ejm: Include global de Macros ZBCIN_MACRO COMPOSITE ENHANCEMENT IMPLEMENTATION Los nombres de estos objetos tendrán la siguiente forma Z[MS]CE_[X…X] Donde: Z : Por definición SAP MS : Módulo SAP (ver tabla 1) CE : Constante X…X : Descripción literal Ejm: ZMMCE_RESERVAS01 ENHANCEMENT IMPLEMENTATION Los nombres de estos objetos tendrán la siguiente forma Z[MS]EI_TTTT_[X…X] Donde: Z : Por definición SAP MS : Módulo SAP (ver tabla 1) EI : Constante TTTT : Código de transacción que se está ampliando X…X : Descripción literal Ejm: ZSDEI_VF04_OCULTAR_BOTON Nota: Si el enhancement afecta a más de una transacción y las transacciones sólo variaran por un caracter, reemplazar el carácter diferente por una X. Si todos los caracteres de las txs fueran diferentes, colocar las txs más importantes y mencionar el resto como para de la descripción del enhancement. Ejm: Si afecta a VA01, VA02 y VA03 => ZSDEI_VA0X_SAVE_POPUP Si afecta a MIGO y MB01 => ZMMEI_MIGO_MB01_VALIDA


- 38 -

TABLA Los nombres de estos objetos tendrán la siguiente forma Z[MS]T_[X…X] Donde: Z : Por definición SAP MS : Módulo SAP (ver tabla 1) T : Constante X...X : Descripción literal Ejm: ZCOT_MATCOSTO Nota: Se debe definir la Categoría de Ampliación antes de activar la tabla. Para acceder: ingresar a la tabla en la Tx. SE11, ir al menú Detalles -> Categoría de Ampliación. Por seguridad se debe asociar un grupo de autorización para toda tabla Z (Ver punto 4 del presente Manual). CAMPO DE TABLA El nombre que llevarán los diferentes campos que conforman una tabla de base de datos, estará asignado de la siguiente forma, dependiendo el caso en que se encuentre: � De ser un campo que hace referencia a un tipo de dato existente en SAP, se mantendrá el mismo

nombre de campo usado por la nomenclatura estándar de SAP. Ejemplo: Sociedad -> BUKRS

� De ser un campo creado según la situación del negocio o cliente, el nombre del campo estará asignado por un nombre adecuado seleccionado bajo el criterio del consultor responsable, tomando un tamaño recomendado de 5 caracteres. Ejemplo: Alimentos -> ALMTS. Tienda de Textiles -> TDATL.

INDICE DE TABLA Los índices que sean necesarios crear, para la optimización en el acceso de lectura a las tablas de bases de datos tendrán la siguiente forma Z[NN] Donde: Z : Por definición SAP NN : Secuencia numérica de 2 caracteres. Ejm: Z01. Nota: Al crear el índice Z por la tx SE11, se debe elegir la opción “Crear índice extensión”.


- 39 -

VISTA Los nombres de estos objetos tendrán la siguiente forma Z[MS]V_[X…X] Donde: Z : Por definición SAP MS : Módulo SAP (ver tabla 1) V : Constante X...X : Descripción literal Ejm: ZMMV_MATCENTRO VISTA APPEND Los nombres de estos objetos tendrán la siguiente forma ZZ[MS]V_[X…X] VISTA AYUDA Los nombres de estos objetos tendrán la siguiente forma Z[MS]VH_[X…X] CLUSTER DE VISTA Los nombres de estos objetos tendrán la siguiente forma Z[MS]VC_[X…X] ESTRUCTURA Los nombres de estos objetos tendrán la siguiente forma Z[MS]S_[X…X] Donde: Z : Por definición SAP MS : Módulo SAP (ver tabla 1) S : Constante X...X : Descripción literal Ejm: ZWMS_STOCKMAT Nota: Se debe definir la Categoría de Ampliación antes de activar la estructura. ESTRUCTURA APPEND Los nombres de estos objetos tendrán la siguiente forma ZZ[MS]S_[X…X] Los nombres de los campos deberán empezar con ZZ. TIPO TABLA Los nombres de estos objetos tendrán la siguiente forma Z[MS]TT_[X...X] Donde: Z : Por definición SAP MS : Módulo SAP (ver tabla 1) TT : Constante X...X : Descripción literal Ejm: ZMMTT_RESERVAS.


- 40 -

ELEMENTO DE DATO Los nombres de estos objetos tendrán la siguiente forma ZE_[X…X] Donde: Z : Por definición SAP E : Constante X…X : Descripción literal Ejm: ZE_BANCO DOMINIO Los nombres de estos objetos tendrán la siguiente forma ZD_[CCCC][NNN][_D ] Donde: Z : Por definición SAP D : Constante CCCC : Tipo de formato del campo (ver tabla 3) NNN : Longitud del campo D : Opcional: Número de decimales Ejm: ZD_CHAR255 Almacena un texto de 255 caracteres ZD_DEC15_2 Almacena un número de longitud 15 y 2 decimales. Los dominios que tuvieran ámbito de valores tendrán la siguiente forma ZD_AV[XXX] Donde: Z : Por definición SAP D : Constante AV : Constante XXX : Descripción literal Ejm: ZD_AVMES contiene los meses del año Nota: Considerar que sólo se debe crear un dominio Z, si en caso no existiera un dominio estándar con el mismo tipo y longitud. ID PARAMETRO SET/GET Los ID de parámetro sirven para llenar un campo con los valores propuestos de la memoria SAP. Estos iniciarán con el prefijo Z, seguido de una abreviatura del parámetro que va a representar, recomendable 3 caracteres. Ejm: ZRET


- 41 -

AYUDA DE BÚSQUEDA Los nombres de estos objetos tendrán la siguiente forma ZH_[X…X] Donde: Z : Por definición SAP H : Constante X…X : Descripción literal Ejm: ZH_USERS OBJETO DE BLOQUEO Los nombres de estos objetos tendrán la siguiente EZ_[X...X] Donde: E : Prefijo Obligatorio SAP Z : Por definición SAP X...X : Descripción literal, de preferencia tabla relacionada a bloquear Ejm: EZ_ZSDT_BLOCK SAPSCRIPT Los nombres de estos objetos tendrán la siguiente forma Z[MS]SS_[X…X] Donde: Z : Por definición SAP MS : Módulo SAP (ver tabla 1) SS : Constante X…X : Descripción literal Ejm: ZSDSS_ADUANA ESTILO (SAPSCRIPT) Los nombres de estos objetos tendrán la siguiente forma ZST_[NNN] Donde: Z : Por definición SAP ST : Constante NNN : Correlativo de 3 dígitos Ejm: ZST_001 SMARTFORM Los nombres de estos objetos tendrán la siguiente forma Z[MS]SF_[X…X] Donde: Z : Por definición SAP MS : Módulo SAP (ver tabla 1) SF : Constante X…X : Descripción literal Ejm: ZSDSF_ADUANA


- 42 -

ESTILO (SMARTFORM) Los nombres de estos objetos tendrán la siguiente forma ZST_[X…X] Donde: Z : Por definición SAP MS : Módulo SAP (ver tabla 1) ST : Constante X…X : Nombre de Smartform Ejm: ZSDST_ADUANA MÓDULO DE TEXTO (SMARTFORM) Los nombres de estos objetos tendrán la siguiente forma ZMT_[X…X] Donde: Z : Por definición SAP MT : Constante X…X : Descripción literal GRUPO DE FUNCIONES Los nombres de estos objetos tendrán la siguiente forma Z[MS]GF_[X...X] Donde: Z : Por definición de SAP MS : Módulo SAP (ver tabla 1) GF : Constante X...X : Descripción literal Ejm: ZHRGF_PERSONAL Nota: Los grupo de funciones correspondientes a la vista de actualización de una tabla o vista Z, deberán llevar el mismo nombre que la tabla o vista relacionada. Los field exits serán agrupados en un grupo de funciones único por módulo. El GF a tomar será previamente coordinado con el Supervisor ABAP. FUNCION Los nombres de estos objetos tendrán la siguiente forma Z[MS]F_[X...X] Donde: Z : Por definición de SAP MS : Módulo SAP (ver tabla 1) F : Constante X...X : Descripción literal Ejm: ZFIF_VERPAGOS


- 43 -

RFC Los nombres de estos objetos tendrán la siguiente forma Z[MS]RFC_[X…X] Donde: Z : Por definición de SAP MS : Módulo SAP (ver tabla 1) RFC : Constante X...X : Descripción literal Ejm: ZSDRFC_TIPODOC APLICACION BSP Los nombres de estos objetos tendrán la siguiente forma Z[MS]BSP_[X...X] Donde: Z : Por definición SAP MS : Módulo SAP (ver tabla 1) BSP : Constante X...X : Descripción literal Ejm: ZMMBSP_LIBERA_OC IMPLEMENTACION BADI Los nombres de estos objetos tendrán la siguiente forma Z[X...X][N] Donde: Z : Por definición SAP X...X : Descripción literal, de preferencia nombre de definición N : Opcional: correlativo numérico de 1 dígito Ejm: ZME_PROCESS_PO_CUST. CLASE E INTERFASE La nomenclatura de una clase o de una interfase puede constar de caracteres alfanuméricos y del carácter especial de subrayado (_) y de la barra (/). La barra (/) sirve para delimitar el prefijo del ámbito de nombres del resto del denominador. La clase o interfase no puede empezar con una cifra. Clase Z[MS]CL_[X…X] Interfase Z[MS]IF_[X…X] Donde: Z : Por definición SAP MS : Módulo SAP (ver tabla 1) CL/IF : Constante X...X : Descripción literal


- 44 -

BUSINESS OBJECT Los nombres de estos objetos tendrán la siguiente forma ZBO_[X…X] Donde: Z : Por definición SAP BO : Constante X...X : Descripción literal Ejm: ZBO_CRM ENTERPRISE SERVICE Los nombres de estos objetos tendrán la siguiente forma Z[MS][WS_[X…X] Donde: Z : Por definición SAP MS : Módulo SAP (Ver tabla 1) WS : Constante X...X : Descripción literal Ejm: ZSDWS_SCE_PEDIDOS OBJETO DE AMPLIACION (CMOD) Los nombres de estos objetos tendrán la siguiente forma Z[MS][NNN] Donde: Z : Por definición SAP MS : Módulo SAP (Ver tabla 1) NNN : Correlativo numérico Ejm: ZSD001 GRUPO DE USUARIO (QUERY) Los nombres de estos objetos tendrán la siguiente forma Z[MS]GU_[X...X] Donde: Z : Por definición SAP MS : Módulo SAP (ver tabla 1) GU : Constante X...X : Descripción literal Ejm: ZSDGU_VENTAS


- 45 -

INFOSET (QUERY) Los nombres de estos objetos tendrán la siguiente forma Z[MS]IS_[X...X] Donde: Z : Por definición SAP MS : Módulo SAP (ver tabla 1) IS : Constante X...X : Descripción literal Ejm: ZSDIS_DOC_VENTAS QUERY Los nombres de estos objetos tendrán la siguiente forma Z[MS]Q_[X...X] Donde: Z : Por definición SAP MS : Módulo SAP (ver tabla 1) Q : Constante X...X : Descripción literal Ejm: ZSDQ_ENTREGAS PROYECTO (LSMW) Los nombres de estos objetos tendrán la siguiente forma ZP_[X...X] Donde: Z : Por definición SAP P : Constante X...X : Descripción literal Ejm: ZP_RANSA SUB PROYECTO (LSMW) Los nombres de estos objetos tendrán la siguiente forma Z[MS]SP_[X...X] Donde: Z : Por definición SAP MS : Módulo SAP (ver tabla 1) SP : Constante X...X : Descripción literal Ejm: ZMMSP_PEDIDOS


- 46 -

OBJETO (LSMW) Los nombres de estos objetos tendrán la siguiente forma Z[MS]O_[X...X] Donde: Z : Por definición SAP MS : Módulo SAP (ver tabla 1) O : Constante X...X : Descripción literal Ejm: ZMMO_ME21N_01 CLASE DE DESARROLLO Los nombres de estos objetos tendrán la siguiente forma Z[MS] Donde: Z : Por definición SAP MS : Módulo SAP (ver tabla 1) Ejm: Paquete módulo PP: ZPP OBJETO DE AUTORIZACION Con la finalidad de mantener la seguridad de accesos y permisos respectivos a las transacciones, será necesaria la creación de objetos de autorización, los cuales tendrán la siguiente forma: Z[MS]_[X…X] Donde: Z : Por definición de SAP MS : Módulo SAP (ver tabla 1) X...X : Descripción literal (De preferencia colocar campo a validar) Ejm: ZMM_WERKS Nota: Considerar el campo ACTIVIDAD (ACTVT) para una mejor restricción. CLASE DE MENSAJE Los nombres de las clases de mensaje tienen la siguiente forma Z[MS][NN] Donde: Z : Por definición SAP MS : Módulo SAP (ver tabla 1) NN : Correlativo de 2 dígitos Ejm: ZPP01 Nota: Preferentemente usar una clase por módulo


- 47 -

NUMEROS DE MENSAJE Los números de mensajes consta de 3 caracteres numéricos: [NNN] Donde: NNN : Número de intervalo ( 001 – 999 ) VARIANTE El texto es libre GRUPO TIPO Los nombres de estos objetos tendrán la siguiente forma Z[MS][NN] Donde: Z : Por definición SAP MS : Módulo SAP (Ver tabla 1) NN : Correlativo numérico Ejm: ZWM01


- 48 -

ANEXOS ��

TABLA DE PARÁMETROS �� TABLA 1. MÓDULOS Aplicación Descripción BC Uso genérico BW Business Warehouse CRM Customer Relationship Management CO Controlling CS Servicio al Cliente FI Finanzas HR Recursos Humanos MM Materiales PM Mantenimiento PP Producción PS Gestión de Proyectos QM Calidad SD Ventas y Distribución WM Gestión de Almacenes TABLA 2. TIPO DE PROGRAMA / TRANSACCIÓN Código Denominación Descripción Válido para programa ó transacción: B Batch En ellos se encuentran los programas que manejan Batch Input,

Call Transaction, etc P Procesos y otros desarrollos Para el caso de un programa que presente una serie de procesos

o realice actividades particulares. Estos programas se caracterizan por realizar más de una actividad de las mencionadas en un mismo programa.

R Reporte Para todos aquellos programas que impliquen una selección de datos y un listado en pantalla.

M Mantenimiento de tablas Procesos exclusivos al mantenimiento o carga inicial de una tabla Válido sólo para transacción: A Actualización Transacción de actualización de tabla. Q Query Transacción creada para query TABLA 3 . TIPO DE FORMATO Código Descripción ID CHAR String C CURR Campo moneda, almacenado como DEC DATS Campo para fecha (AAAAMMDD), almacenado como CHAR (8) D DEC Campo cálculo o de importe con coma y signo +/- P FLTP Cifra coma flotante con 8 byte de exactitud F INT Entero I NUMC String sólo con cifras N QUAN Campo cantidad, apunta a campo unidades con formato UNIT Q TIMS Campo hora (HHMMSS), almacenado como CHAR (6) T UNIT Clave de unidades para campos QUAN U


- 49 -

GUIAS �� G1. Acumular OTs

1. En Tx SE10, colocar cursor en la OT generada. La nueva OT debe tener la misma descripción que la OT anterior, y sólo debe aumentarse la versión de acuerdo a las indicaciones dadas en el punto 1 del presente Manual.

2. Presionar botón mostrado en la imagen, o presionar CTRL + F11.

3. Ingresar OT predecesora en el popup y dar enter

4. Al abrir la OT, se verá la OT acumulada en la sección “Lista de objetos tomada”, y se podrán ver todos los objetos importados en nuestra OT.


- 50 -

G2. Uso de SU24: Cómo asociar Tx con Objeto de autorización

1. Entrar a la Tx. SU24

2. Ingresar código de transacción Z desarrollado y dar clic en botón Ejecutar

3. Clic en botón Modificar

4. Clic en Añadir Objeto de Autorización

5. Ingresar objeto de autorización que se esté validando en el programa y Enter


- 51 -

6. Ingresamos las actividades que se validan desde el programa y grabamos


- 52 -

7. Finalmente grabar, asignarlo a la OT de nuestro desarrollo y listo.


- 53 -

IMÁGENES �� IMAGEN 10.4.a


- 54 -

IMAGEN 10.4.b

IMAGEN 10.4.c

CGR EstandaresDeProgramacion ABAP4 v1 0

Documents