ESTÁNDARES DE PROGRAMACIÓN ABAP4 -VERSIÓN 1.0 -2014

ESTÁNDARES DE PROGRAMACIÓN ABAP4 - VERSIÓN 1.0 2014

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

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

Control de Cambios del Documento Preparado por: Revisado y aprobado por:

Verónica Briceño Vásquez Luis Alba Vera Ruth Novoa La Torre Versión 1.0

-2-

Fecha de Preparación: Fecha de Aprobación: Fecha de Aprobación: Fecha Efectiva:

20.10.2014 25.11.2014 25.11.2014 01.12.2014

Sistemas - Área de Codificación -----------------------------------------------------------------------------------------------------------------------------------------------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 7.2. Cabecera del programa 7.3. Declaración de datos globales 7.4. Declaración de campos de pantalla 7.5. Validación de campos de pantalla e inicialización 7.6. Rutina principal del programa 7.7. Tratamiento de los datos obtenidos 7.8. Eventos de control 7.9. Subrutinas internas

10 10 11 12 13 14 15 15 16

8. Convención para nombres internos ABAP4/SAP

17

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

20 20 21 21 21 21 22 22 23

10. ASEGURAMIENTO DE CALIDAD EN DESARROLLOS ABAP 10.1. Codificación y Presentación 10.2. Performance 10.3. Modularización y reutilización 10.4. Verificación Ampliada 10.5. Puntos a revisar en una OT previo al pase a PRD

24 29 32 34 35

11. NOMENCLATURA DE OBJETOS DE REPOSITORIO SAP

36

ANEXOS • •

48 49

•

TABLA DE PARÁMETROS GUIAS G1. Acumular OTs G2. Uso de SU24: Cómo asociar Tx con Objeto de autorización IMAGENES

-3-

53

Sistemas - Área de Codificación -----------------------------------------------------------------------------------------------------------------------------------------------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.

-4-

Sistemas - Área de Codificación -----------------------------------------------------------------------------------------------------------------------------------------------1. Nomenclatura de OT’s Las órdenes de transporte deben ser nombradas de acuerdo a la siguiente nomenclatura: - Donde: Tipo Módulo Código Actividad Objeto Principal Descripción Versión Funcional

: : : : : : :

CU (Customizing), WB (Workbench), TC (Transporte de Copias) CO, FI, MM, SD, etc. Código de actividad registrada en PMO Transacción u objeto principal modificado Texto descriptivo Cuando se maneja más de una OT relacionada. Comenzar con 00. 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 MM

SOP_000019

Actividad SOPORTE VARIAS

Cod.Tarea

ID OD

TEP-000002

2

WB-MM SOP_000019 ZMMR001 Ajuste Rep Ped compras WB-MM SOP_000019 ZMMR001 Ajuste Rep Ped compras Mód Cod. Actividad SD

PYH_000049

Actividad Proyecto Impulso UNI

Cod.Tarea

ID OD

TEP-000001

1

WB-SD PYH_000049 ZSDR001 Reporte de Clientes WB-SD PYH_000049 ZSDR001 Reporte de Clientes Mód Cod. Actividad WM PYP_000032

Actividad WMS Ampliación de la capacidad de almacenamiento

Descripción (Tarea) Ajuste Reporte Pedido de Compras

00 EIZARRA 01 EIZARRA

E.Izarra

-> OT inicial -> No acumuló OT anterior

Descripción (Tarea) Reporte de Clientes

Funcional M.Villanueva

00 MV -> OT inicial * 01 MV -> Acumuló la OT anterior

Cod.Tarea

ID OD

TEP-000001

1

Descripción (Tarea) Ubicación para traslados

WB-WM PYP_000032 ZWMP001 Ubicación para traslados 00 ID WB-WM PYP_000032 ZWMP001 Ubicación para traslados * 01 ID WB-WM PYP_000032 ZWMP001 Ubicación para traslados * 02 ID WB-WM PYP_000032 ZWMP001 Ubicación para traslados 1 00 ID WB-WM PYP_000032 ZWMP001 Ubicación para traslados * 1 01 ID WB-WM PYP_000032 ZWMP001 Ubicación para traslados 2 00 ID

-5-

Funcional

Funcional I.Delgado

-> OT inicial -> Acumuló la OT anterior -> Acumuló la OT anterior -> OT anterior se pasó a PRD -> Acumuló la OT anterior -> OT anterior se pasó a PRD

Sistemas - Área de Codificación -----------------------------------------------------------------------------------------------------------------------------------------------2. Marca para modificaciones Las marcas de modificación deben ser nombradas de acuerdo a la siguiente nomenclatura: @ Donde: Acción

:

NNN

:

- INSERT : Insertar - REPLACE : Modificar - DELETE : Comentar 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. *} INSERT @001

"TEXTO_EXP

-6-

Sistemas - Área de Codificación -----------------------------------------------------------------------------------------------------------------------------------------------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=>FILETYPE_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

-7-

Sistemas - Área de Codificación -----------------------------------------------------------------------------------------------------------------------------------------------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 ZBC ZBW ZCO ZCS ZFI ZHR ZMM ZPM ZPP ZPS ZQM ZSD ZWM

Descripción Uso genérico Business Warehouse Controlling Servicio al Cliente Finanzas Recursos Humanos Materiales Mantenimiento Producción Gestión de Proyectos Calidad Ventas y Distribución Gestión de Almacenes

-8-

Sistemas - Área de Codificación -----------------------------------------------------------------------------------------------------------------------------------------------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.

-9-

Sistemas - Área de Codificación -----------------------------------------------------------------------------------------------------------------------------------------------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ónica 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 documento *

- 10 -

Sistemas - Área de Codificación -----------------------------------------------------------------------------------------------------------------------------------------------*&---------------------------------------------------------------------* *& 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 GS_CAMPO2 TYPE GN_CAMPO3 TYPE GD_BUDAT TYPE

T001-BUKRS, C LENGTH 3, N, BKPF-BUDAT.

"Adicionar "Adicionar "Adicionar "Adicionar

comentario comentario comentario 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 "Standard GTYD_MARC "Hashed GTYH_MARC "Sorted GTYS_MARC *Tablas internas DATA: GT_MARC "Standard

TYPE TABLE OF MARC, TYPE STANDARD TABLE OF GTY_MARC, TYPE HASHED TABLE OF GTY_MARC WITH UNIQUE KEY MATNR WERKS, TYPE SORTED TABLE OF GTY_MARC WITH NON-UNIQUE KEY MATNR.

TYPE TABLE OF GTY_MARC,

- 11 -

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

TYPE GTYD_MARC,

GHT_MARC

TYPE GTYH_MARC,

GST_MARC

TYPE GTYS_MARC.

"Hashed "Sorted

* 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 GWA_BUKRS

TYPE RANGE OF BKPF-BUKRS, "rango de sociedades LIKE LINE OF GR_BUKRS.

* Field symbols FIELD-SYMBOLS: LIKE LINE OF GDT_MARC, 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

- 12 -

Sistemas - Área de Codificación -----------------------------------------------------------------------------------------------------------------------------------------------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 P_REL P_ALM_R P_STCK

RADIOBUTTON GROUP G1 DEFAULT 'X', RADIOBUTTON GROUP G1, AS CHECKBOX, 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.

- 13 -

Sistemas - Área de Codificación -----------------------------------------------------------------------------------------------------------------------------------------------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 utilizando una BDL o no. * Tratar de agrupar código en subrutinas. * La información debe tratar de almacenarse en tablas 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.

- 14 -

Sistemas - Área de Codificación -----------------------------------------------------------------------------------------------------------------------------------------------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 usuario, 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 proceso 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. Eventos 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.

- 15 -

Sistemas - Área de Codificación -----------------------------------------------------------------------------------------------------------------------------------------------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.

- 16 -

Sistemas - Área de Codificación -----------------------------------------------------------------------------------------------------------------------------------------------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

TABLA INTERNA

ESTRUCTURA

Ámbito

PARÁMETRO DE ENTRADA SELECT-OPTIONS BLOCKS SELECTION SCREEN

Ejemplo

gt_ gdt_ gst_ ght_ lt_ ldt_ lst_ lht_ st_ sdt_ sst_ sht_ gwa_ lwa_ swa_ gs_ gn_ gd_ gh_ gx_ gi_ gp_ gf_ g_ ls_ ln_ ld_ lh_ lx_ li_ lp_ lf_ l_ ss_ sn_ sd_ sh_ sx_ si_ sp_ sf_ s_ pi_ po_ pt_

gt_makt gdt_makt gst_makt ght_makt lt_makt ldt_makt lst_makt lht_makt st_makt sdt_makt sst_makt sht_makt gwa_mara lwa_mara swa_mara gs_texto gn_num3 gd_budat gt_uzeit gx_byte gi_edad gp_total gf_total g_monto ls_texto ln_num3 ld_budat lt_uzeit lx_byte li_edad lp_total lf_total l_monto ss_texto sn_num3 sd_budat st_uzeit sx_byte si_edad sp_total sf_total s_monto pi_menge po_meins pt_ekpo

sin ámbito

sin tipo

p_

p_ bukrs

sin ámbito

sin tipo

s_

s_bukrs

sin ámbito

sin tipo

b_

b_01

local

static

PARÁMETROS (de una rutina FORM)

Valor

sin tipo estándar sorted hashed sin tipo estándar sorted hashed sin tipo estándar sorted hashed sin tipo sin tipo sin tipo C caracter N cadena numérica D fecha T hora X byte (hexadecimal) I entero P numero empaquetado F numero punto flotante otro C caracter N cadena numérica D fecha T hora X byte (hexadecimal) I entero P numero empaquetado F numero punto flotante otro C caracter N cadena numérica D fecha T hora X byte (hexadecimal) I entero P numero empaquetado F numero punto flotante otro using sin changing tipo tables

global global global global local local local local static static static static global local static

global

VARIABLE

Tipo Dato

sin ámbito

- 17 -


RANGOS

global

sin tipo

gr_

gr_bukrs

local

sin tipo

lr_

lr_bukrs

static

sin tipo

sr_

sr_bukrs

global

sin tipo

gc_

gc_edad_max

local

sin tipo

lc_

lc_edad_max

global

-

g_

del

objeto

local

-

l_

del

objeto

imprime_reporte

CONSTANTES

FIELD SYMBOL

SUBRUTINAS

sin ámbito

sin tipo

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

MACROS

sin ámbito

sin tipo

llena_fieldcat

global

sin tipo

gty_

gty_mara

local

sin tipo

lty_

lty_mara

sin tipo

gtyt_

gtyt_makt

estándar

gtyd_

gtyd_makt

sorted

gtys_

gtys_makt

hashed

gtyh_

gtyh_makt

sin tipo

ltyt_

ltyt_makt

estándar

ltyd_

ltyd_makt

sorted

ltys_

ltys_makt

hashed

ltyh_

ltyh_makt

global

sin tipo

gcl_

gcl_reporte

local

sin tipo

lcl_

lcl_reporte

global

sin tipo

go_

go_alv

local

sin tipo

lo_

lo_alv

static

sin tipo

so_

so_alv

parámetro

IP_

ip_matnr

estructura

IW_

iw_makt

tabla

IT_

it_ekpo

parámetro

EP_

ep_matnr

estructura

EW_

ew_makt

tabla

ET_

et_ekpo

parámetro

MP_

mp_matnr

estructura

MW_

mw_makt

TIPOS

global

TIPOS TABLA

local

CLASES

OBJETOS

PARÁMETROS DE MÓDULO DE FUNCIONES

global importing global importing global importing global exporting global exporting global exporting global modify global modify

- 18 -


PARÁMETROS DE MÉTODOS DE CLASES

global modify

tabla

MT_

mt_ekpo

tables

tabla

T_

t_datos

parámetro

IP_

ip_matnr

estructura

IW_

iw_makt

tabla

IT_

it_ekpo

clase

IC_

ic_reloj

parámetro

EP_

ep_matnr

estructura

EW_

ew_makt

tabla

ET_

et_ekpo

clase

EC_

ec_reloj

parámetro

CP_

cp_matnr

estructura

CW_

cw_makt

tabla

CT_

ct_ekpo

clase

CC_

cc_reloj

parámetro

RP_

rp_matnr

estructura

RW_

rw_makt

tabla

RT_

rt_ekpo

clase

RC_

rc_reloj

global importing global importing global importing global importing global exporting global exporting global exporting global exporting global changing global changing global changing global changing global returning global returning global returning global returning

- 19 -

Sistemas - Área de Codificación -----------------------------------------------------------------------------------------------------------------------------------------------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 ZMSTNNNN_TOP

ZMSTNNNN_SEL ZMSTNNNN_MAI ZMSTNNNN_F01 ZMSTNNNN_O01 ZMSTNNNN_I01 ZMSTNNNN_CLA

Contiene 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. Los parámetros de selección. El proceso principal y los eventos. Ejm: INITIALIZATION. START-OFSELECTION, AT SELECTION SCREEN, etc. Las subrutinas del programa. Process Before Output. Los modules output. Process After Input. Los modules input. 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.

- 20 -

Sistemas - Área de Codificación -----------------------------------------------------------------------------------------------------------------------------------------------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-OFPAGE.

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

- 21 -

Sistemas - Área de Codificación -----------------------------------------------------------------------------------------------------------------------------------------------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 Dynpro: 0200 Dynpro: 0300

-> -> ->

Status: 0100 Status: 0100 Status: 0300

-> -> ->

Título: 0100 Título: 0200 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 Campo de Texto Campo Entrada/Salida CheckBox Radio Button PushButton Marco Control de TabStrip Área SubScreen Table Control Custom Control Status Icon

Nomenclatura TF_ PF_ CB_ RB_ PB_ GB_ SC_ SA_ TC_ CC_ SI_

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.

- 22 -

Sistemas - Área de Codificación -----------------------------------------------------------------------------------------------------------------------------------------------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).

- 23 -

Sistemas - Área de Codificación -----------------------------------------------------------------------------------------------------------------------------------------------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 ECC6.0 Incorrecto: No usar LIKE como referencia a tipos de diccionario, DATA: GWA_KNA1 LIKE KNA1. Correcto: usar TYPE. DATA: GWA_KNA1 TYPE KNA1. Incorrecto: TYPES: GS_X, Se debe de especificar la longitud de la variable que GP_Y TYPE P. Correcto: se está definiendo. TYPES: GS_X TYPE C LENGTH 1, GP_Y TYPE P LENGTH 8 DECIMALS 0. Incorrecto: Los parámetros que se pasan a un método debe METHODS METH IMPORTING P1 EXPORTING P2. tener asignado un tipo, si no se sabe qué tipo va a Correcto: tener asignado se declara como type ANY. METHODS METH IMPORTING P1 TYPE ANY EXPORTING P2 TYPE ANY. Incorrecto: CALL FUNCTION FUN IMPORTING P = SY-SUBRC. No está permitido transferir directamente los campos Correcto: del sistema como parámetro, sino a través de una DATA: LI_SUBRC TYPE SY-SUBRC. variable. LI_SUBRC = SY-SUBRC. CALL FUNCTION FUN IMPORTING P = LI_SUBRC. Incorrecto: La sentencia TABLES no está permitido en ABAP TABLES: BKPF. objects, porque es ambigua. Una forma de Correcto: referenciarlo es a través de un work area. DATA: GWA_BKPF TYPE BKPF. Incorrecto: No está permitido el uso de Field-Symbols si es que FIELD-SYMBOLS: . no tiene un tipo de asignación. En ABAP objects la Correcto: adición type al field-symbols es obligatorio. FIELD-SYMBOLS: TYPE ANY. Incorrecto: RANGES: GR_VKORG FOR KNA1-VKORG. El uso de RANGES no está permitido. Correcto: DATA: GR_VKORG TYPE RANGE OF KNA1-VKORG. Incorrecto: DATA: BEGIN OF GT_KNA1 OCCURS 0, KUNNR TYPE KNA1-KUNNR, NAME1 TYPE KNA1-NAME1, La declaración con OCCURS no está permitida. END OF GT_KNA1. Si se requiere memoria inicial se puede especificar Correcto: agregando la sentencia INITIAL SIZE. 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.

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: 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. 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…

- 24 -

Sistemas - Área de Codificación -----------------------------------------------------------------------------------------------------------------------------------------------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 ... 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 … APPEND GWA_BKPF TO GT_BKPF… INSERT GWA_BKPF … MODIFY GWA_BKPF … Incorrecto: SELECT … FROM VBAK. INSERT VBAK. UPDATE VBAK. DELETE VBAK. MODIFY VABK. Correcto: Las siguientes sentencias en relación con el acceso DATA: GWA_VBAK TYPE VBAK. a la base de datos están prohibidas. SELECT … FROM VBAK INTO GWA_VBAK . Se debe de trabajar utilizando work areas. 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) Incorrecto: SELECT * FROM marc WHERE werks EQ ‘5000’ … IF vbfa-vbtyp_n EQ ‘J’ … w_cost = mbew-strps * 1.2. Los valores no deben ser fijados en el código fuente. 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 La existencia de valores fijos dentro del programa constantes globales. dificulta su mantenimiento, portabilidad y CONSTANTS: gc_constante TYPE n LENGTH 4 VALUE 1234. reutilización. DATA: gn_global TYPE n LENGTH 4, ... Además, demuestra desprolijidad en el diseño. 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-OFPAGE, 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.

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

Todas las Subrutinas (FORMs) serán colocadas FORM cargar_datos. después del código principal en un INCLUDE de … FORMs. Los FORMs deberán ser colocados, en lo ENDFORM posible, en el orden en que serán llamados. FORM procesar_datos. … ENDFORM FORM imprimir_datos. … ENDFORM

- 25 -

Sistemas - Área de Codificación -----------------------------------------------------------------------------------------------------------------------------------------------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.

Correcto:

*------------------------------------------------------* Toda Subrutina también debe tener un encabezado * Form GUARDAR_ULTIMA_EJECUCION conteniendo una breve descripción de su *------------------------------------------------------* funcionalidad y los parámetros de entrada y salida. * Lee la tabla ZZLRT donde la última Fecha y * hora de ejecución del programa es guardada Una Subrutina deberá tener solo un proceso *------------------------------------------------------* principal. En caso de que haya más de un proceso, * PI_JOBID código interno de JOB entonces deberá ser dividida en múltiples *  PO_STATUS resultado proceso Subrutinas. *------------------------------------------------------* FORM GUARDAR_ULTIMA_EJECUCION USING PI_JOBID Subrutinas que podrían ser utilizadas en otros CHANGING PO_STATUS. programas deberán ser colocadas en un Function … Module. … ENDFORM. 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. Anidamiento Correcto: Las estructuras IF-ENDIF, LOOP-ENDLOOP, CASE ln_var: CASE-ENDCASE, DO-ENDDO, etc. no deberán WHEN ‘01’. presentar una extensión excesiva en cuanto a la PERFORM procesar_opcion_01. longitud de líneas ni a profundidad (anidamiento). WHEN ‘02’. PERFORM procesar_opcion_02. Se deberá llegar a un equilibrio de estas WHEN ‘01’. características utilizando subrutinas. Para esto se PERFORM procesar_opcion_03. debe estructurar el módulo teniendo en cuenta los WHEN OTHERS conceptos de cohesión y acoplamiento. PERFORM procesar_opcion_otros. ENCASE. Comandos Incorrecto: START-OF-SELECTION. SELECT matnr werks lgort labst FROM mara Cada comando deberá comenzar en una nueva INTO TABLE gt_stock_mat línea para una mejor visualización del código. De WHERE matnr in s_matnr. esta forma, permitirá un mejor mantenimiento del IF sy-subrc NE 0. MESSAGE E001. ENDIF. código (borrado, comentario y debugging). END-OF-SELECTION. Para mantener los programas estructurados, deberemos indentar los diferentes niveles de Correcto: jerarquía con 2 espacios. START-OF-SELECTION. SELECT matnr werks lgort labst FROM mara El PRETTY PRINTER podrá ser utilizado para INTO TABLE gt_stock_mat indentar automáticamente los comandos. WHERE matnr in s_matnr. IF sy-subrc NE 0. Comandos largos deberán ser particionados en MESSAGE E001. varias líneas e indentados por la primera línea para ENDIF. permitir una mejor visualización. 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:

- 26 -

Sistemas - Área de Codificación -----------------------------------------------------------------------------------------------------------------------------------------------Incorrecto: Esto permite simplificar el desarrollo al poder manejarlas como una única estructura (asignaciones DATA: con move-corresponding, inicialización, pase de LS_BUKRS_AUX LIKE BKPF-BUKRS, "SOCIEDAD parámetros, etc.). 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) 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. Utilizar sentencia MOVE en vez de MOVE- MOVE-CORRESPONDING LT_STOCK_MAT TO LWA_STOCK_MAT... CORRESPONDING siempre que sea posible. ENDIF. ... En la definición de datos se debe de usar type en vez de like, también se debe evitar los OCCURS 0, Correcto: with header line y trabajar con work áreas, field TYPES: BEGIN OF LTY_STOCK, symbols. 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 Incorrecto: IF sy-subrc NE 0. WRITE: 'Error en la búsqueda'. ENDIF. Todos los mensajes de error implementados vía MESSAGE IDs.

deberán

ser

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).

- 27 -

Sistemas - Área de Codificación -----------------------------------------------------------------------------------------------------------------------------------------------Textos (Literales) 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. Para todos los textos utilizados a lo largo del ENDFORM. programa, utilice TEXT ELEMENTs. 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 * Se reemplaza el parámetro de salida por una variable auxiliar tipo N. seguimiento y el debugging. CALL FUNCTION ‘CONVERSION_EXIT_ALPHA_OUTPUT’ EXPORTING Cuando esté justificado, dejar indicado con input = t_stock_mat-matnr comentario el motivo. IMPORTING * output = t_stock_mat-matnr. “DELETE @001 En el caso de modificaciones al programa original, output = ln_matnr_aux. “INSERT @001 dejar comentado el código reemplazado/corregido, con la correspondiente referencia de modificación. 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) 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 Deben comentarse todas las variables declaradas a TYPES: begin of gty_stockmat, la derecha de la variable con “. 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 Incorrecto: WRITE T_LOG-NETWR.

Cuando se lista un campo numérico que presentaba decimales es necesario especificarlos por medio de Correcto: una variable, además de indicar la moneda si DATA: L_WAERK TYPE VBRK-WAERK. guarda valores monetarios. WRITE LWA_LOG-NETWR CURRENCY L_WAERK UNIT ‘3’.

- 28 -

Sistemas - Área de Codificación -----------------------------------------------------------------------------------------------------------------------------------------------Estructuras Incorrecto: DATA: BEGIN OF GT_BDCTAB OCCURS 0. INCLUDE STRUCTURE BDCDATA. No incluir una estructura de una tabla como parte de DATA: END OF GT_BDCTAB. la definición de una segunda tabla. 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) Incorrecto: Siempre que precise buscar solo una línea de una SELECT matnr werks lgort labst FROM mard Tabla o View, use SELECT SINGLE * en lugar de INTO CORRESPONDING FIELDS OF TABLE lt_stock_mat SELECT *. ( SELECT SINGLE * accede una vez a WHERE matnr IN s_matnr. la base de datos ) EXIT. ENDSELECT. Especifique siempre los campos de la selección en lugar de usar SELECT * Correcto: SELECT SINGLE matnr werks lgort labst FROM mard Al diseñar una tabla Z, trate de evitar que tenga INTO lwa_stock_mat muchos índices. WHERE matnr IN s_matnr. Siempre especifique las condiciones en la cláusula Incorrecto: WHERE en lugar de testearlas con el comando SELECT * FROM mard CHECK. INTO CORRESPONDING FIELDS OF TABLE lt_stock_mat WHERE matnr IN s_matnr. Evite utilizar ORDER BY, a menos que exista un índice en estos campos. Correcto: SELECT matnr werks lgort labst Utilice las funciones de cálculo (MAX, SUM, MIN....) FROM mard en el comando SELECT en lugar de calcular los INTO TABLE lt_stock_mat valores aparte. Esto minimiza el volumen de WHERE matnr IN s_matnr. transferencia de datos y utiliza los algoritmos optimizados de la base de datos. Incorrecto: Siempre testear SY-SUBRC después de un l_msgnr_max = -1. SELECT MSGNR FROM T100 INTO LWA-MSGNR acceso a la Base de Datos. WHERE ARBGB EQ ‘00’ SELECT (para Transparent y Pool Tables): la IF LWA-MSGNR > l_msgnr_max. l_msgnr_max = LWA-MSGNR. cláusula WHERE debe contener, preferentemente, los campos claves y demás campos que puedan ENDIF. ENDSELECT. restringir la consulta. SELECT (para Cluster Tables): solo los campos Correcto: claves deben ser especificados en la cláusula SELECT MAX (MSGNR) FROM T100 INTO l_msgnr_max WHERE. Los demás deben ser chequeados a WHERE ARBGB EQ ‘00’ través del comando CHECK. Incorrecto: Evite siempre utilizar ciclos SELECT – SELECT matnr werks lgort labst FROM mard ENDSELECT. Es preferible realizar un SELECT INTO lt_stock_mat INTO TABLE y un LOOP AT - ENDLOOP trabajando conjuntamente con WHERE matnr IN s_matnr. el work área. Esto optimiza el acceso a la base de IF lt_stock_mat-labst NE 0. datos y evita problemas de debugg en algunas APPEND lt_stock_mat. versiones de SAP R/3. En general, reduce el tiempo ELSE. de procesamiento en los debugg. APPEND lt_stock_mat_nostock. ENDIF. Evitar siempre reiterar el acceso a un mismo registro ENDSELECT. en la base de datos, así sea con un select single. El uso de los primeros n campos de un índice en la Correcto: cláusula WHERE de un SELECT, proporciona una SELECT matnr werks lgort labst FROM mard búsqueda más rápida. INTO TABLE lt_stock_mat Es importante utilizar la cláusula WHERE en el WHERE matnr IN s_matnr. comando SELECT. Siempre que la clave primaria

- 29 -

Sistemas - Área de Codificación -----------------------------------------------------------------------------------------------------------------------------------------------no pueda ser utilizada, los índices podrán ayudar.

lt_stock_mat_nostock[] = lt_stock_mat[]. DELETE lt_stock_mat WHERE labst = 0. Primero intente acceder por la clave primaria DELETE lt_stock_mat_nostock[] WHERE labst <> 0 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 Si se necesita imprimir el nombre del cliente en la factura… con t_facturas-kunnr para la clave o índice. (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 . READ TABLE lt_clientes INTO lwa_clientes WITH KEY kunnr = -kunnr. IF sy-subrc EQ 0. -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 Correcto: comando: READ TABLE ... WITH BINARY SORT GT_TABLA1 BY CAMPO1 ASCENDING. SEARCH. Debiendo estar ordenada la tabla Interna. LOOP AT GT_TABLA1…. … En caso de tener que repetir búsquedas sobre ENDLOOP. tablas, es conveniente seleccionar los datos una sola vez sobre una tabla interna, y trabajar sobre SORT GT_TABLA2 BY CAMPO1 ASCENDING. ella las veces que sea necesario. LOOP AT GT_TABLA2…. … SORT ENDLOOP. 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 . Caso contrario todos los campos serán clasificados.

Incorrecto: LOOP AT ITAB. CHECK T_ABC = KVAL. ... ENDLOOP.

LOOP...WHERE El comando LOOP .... WHERE es más eficiente que Correcto: el comando LOOP / CHECK, pues evalúa la LOOP AT GT_ABC INTO GWA_ABC WHERE K = GS_VAL. condición internamente. … ENDLOOP. Siempre usar los comandos CLEAR/ REFRESH después de finalizar un LOOP, cuando los datos no deban ser reutilizados. Incorrecto: LOOP AT GT_VBAK INTO GWA_VBAK. APPEND GWA_VBAK TO GT_AUX. Si dos tablas tienen la misma estructura, es más ENDLOOP. eficiente copiar el contenido de una a otra directamente y no a través de un LOOP. Correcto: GT_AUX[] = GT_VBAK[]. Sin embargo, si GT_AUX no está vacía y no debe de ser sobre-escrito entonces use:

- 30 -

Sistemas - Área de Codificación -----------------------------------------------------------------------------------------------------------------------------------------------APPEND LINES OF GT_VBAK TO GT_AUX. Incorrecto: GWA-DATE = SY-DATUM. Si se desea modificar un campo de una tabla MODIFY GT_ITAB FROM GWA INDEX 1. interna, es más eficiente modificarlo especificando el Correcto: campo. GWA-DATE = SY-DATUM. MODIFY GT_ITAB FROM GWA INDEX 1 TRANSPORTING DATE. 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. Para borrar entradas duplicadas dentro de una tabla ELSE. interna es mejor ordenar la tabla y borrar los GWA_PREV_LINE = GWA. duplicados y no hacerlos dentro de un LOOP. ENDIF. ENDLOOP.

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

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: SORT GT_TAB BY K. DELETE ADJACENT DUPLICATES FROM GT_TAB COMPARING K. Incorrecto: LOOP AT GT_TAB. LI_LINEAS = LI_LINEAS + 1. ENDLOOP. Correcto: DESCRIBE TABLE GT_TAB LINES LI_LINEAS. 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. Incorrecto: LOOP AT GT_TAB1. LOOP AT GT_TAB2 WHERE K = GT_TAB1-K. ... ENDLOOP. ENDLOOP.

En ocasiones tenemos tablas internas muy pesadas y debemos de recorrer una dentro de otra, suponiendo que contamos con dos tablas internas Correcto: gt_tab1 en donde hay m entradas y gt_tab2 donde LI_INDX = 1. hay n entradas, el número de vueltas sería m x n. LOOP AT GT_TAB1 INTO LWA_TAB1. Incluso, aunque hayamos puesto la cláusula READ TABLE GT_TAB2 WITH KEY K = GT_TAB1-K WHERE. BINARY SEARCH TRANSPORTING NO FIELDS. IF SY-SUBRC EQ 0. En estos casos, donde además ambas tablas LI_INDX = SY-TABIX. tengan los mismos campos clave, se recomienda LOOP AT GT_TAB2 INTO LWA_TAB2 FROM LI_INDX. usar un índice interno para empezar la búsqueda en IF LWA_TAB2-K <> LWA_TAB1-K. la segunda tabla, de esta forma se reducirá el EXIT. número de vueltas. ENDIF. " ... ENDLOOP. ENDIF. ENDLOOP. Incorrecto: * Tabla GT_TAB tiene 100 entradas. Siempre que sea posible, utilice operaciones con LOOP AT GT_TAB. arreglos en lugar de operaciones sobre una fila. La INSERT INTO VERI_CLNT VALUES GT_TAB. frecuente comunicación entre el programa de ENDLOOP. aplicación y el sistema de la base de datos produce Correcto: una considerable baja en la performance. * Tabla GT_TAB tiene 100 entradas. INSERT VERI_CLNT FROM TABLE GT_TAB. Incorrecto: READ TABLE GT_TAB WITH KEY k = ‘X’. Si la tabla interna tiene muchas entradas, en una búsqueda lineal a través de todas las entradas el Correcto: tiempo consumido es bastante largo. Trate de SORT GT_TAB BY K. mantener la tabla ordenada y usar búsqueda binaria. ….. READ TABLE GT_TAB INTO LWA_TAB WITH KEY k = ‘X’ BINARY SEARCH.

- 31 -

Sistemas - Área de Codificación -----------------------------------------------------------------------------------------------------------------------------------------------10.3. Modularización y reutilización Consideraciones

Ejemplos

Modularización Los programas deben modularizados completamente.

estar

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.

Correcto: START-OF-SELECTION. PERFORM buscar_datos. PERFORM calcular_porcentajes. PERFORM grabar_log.

END-OF-SELECTION. PERFORM imprimir_reporte. La modularización se establece durante PERFORM download_archivo. el diseño; implica comprender la complejidad total del programa y dividirla FORM buscar_datos. en partes (ó módulos). Cada modulo o ... rutina ejecutará solo una acción principal ENDFORM. o proceso. FORM calcular_porcentajes. A través de la modularización se divide … un “problema” grande en problemas ENDFORM. “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 Parametrización de módulos Solamente se deberán declarar variables globales cuando realmente este justificado.

Recomendable:

Nunca deberán declararse variables DATA: gwa_stock_mat TYPE mard. globales que solo sean utilizadas luego dentro de algún módulo. START-OF-SELECTION. PERFORM buscar_datos_stock changing gwa_stock_mat. Utilizar pase de parámetros entre PERFORM imprimir_datos_stock using gwa_stock_mat. módulos. (USING, CHAGING, TABLES). En este caso la variable gwa_stock_mat es global, si bien dentro de las rutinas la variable Incluso cuando no fuera necesario el esta dentro de su ámbito de incumbencia y podría ser referenciada, colocar el parámetro pase de parámetros desde el punto de clarifica el seguimiento, se observa entonces que el form BUSCAR_DATOS_STOCK vista técnico, siempre es recomendable modificará esa variable, y el form IMPRIMIR_DATOS_STOCK la utilizará. indicarlo, de manera que sea más claro entender que la subrutina llamada, utiliza o modifica cierta variable. Balanceo de la estructura de un programa Incorrecto: START-OF-SELECTION. PERFORM CARGAR_DATOS TABLES GT_DATA. PERFORM IMPRIMIR_CABECERA TABLES GT_DATA. PERFORM IMPRIMIR_DETALLE TABLES GT_DATA. Los programas se deberán estructurar de Correcto: manera que idénticos niveles de la START-OF-SELECTION. estructura conserven el mismo nivel PERFORM CARGAR_DATOS TABLES GT_DATA. funcional. 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.

- 32 -

Sistemas - Área de Codificación -----------------------------------------------------------------------------------------------------------------------------------------------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 Recomendable: parametrizado. Tipos reutilizables, grabarlos en TYPE-POOLS. Rutinas sin parámetros son muy difíciles de reutilizar. Definiciones de variables reutilizables, grabarlos en INCLUDES La reutilización mejora los tiempos de Rutinas (FORMs) reutilizables, grabarlos en ROUTINES-POOL o INCLUDES. desarrollo, simplifica el proceso y evita “reinventar la rueda” constantemente. Rutinas (FORMs) reutilizables, con parámetros de entrada y salida, grabarlos en MODULOS DE FUNCIONES. 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.

- 33 -

Sistemas - Área de Codificación -----------------------------------------------------------------------------------------------------------------------------------------------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.

- 34 -

Sistemas - Área de Codificación -----------------------------------------------------------------------------------------------------------------------------------------------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).

- 35 -

Sistemas - Área de Codificación -----------------------------------------------------------------------------------------------------------------------------------------------11. NOMENCLATURA DE OBJETOS DE REPOSITORIO SAP TRANSACCION Los nombres de estos objetos tendrán la siguiente forma Z[MS][T][NNN] Donde: Z MS T NNN

: : : :

Por definición SAP Módulo SAP (Ver tabla 1) Tipo de Programa (ver tabla 2) 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 MS T NNNN

: : : :

Por definición SAP Módulo SAP (ver tabla 1) Tipo de programa (ver tabla 2) Correlativo numérico

Ejm: ZFIR0001

INCLUDE Los nombres de estos objetos tendrán la siguiente forma Z[MS][T][NNNN]_XXX Include ZMSTNNNN_TOP ZMSTNNNN_SEL ZMSTNNNN_MAI ZMSTNNNN_F01 ZMSTNNNN_O01 ZMSTNNNN_I01 ZMSTNNNN_CLA

Contiene Todas las declaraciones iniciales. Los parámetros de selección iniciales. El proceso principal y los eventos. Las subrutinas del programa. Process Before Output. Process After Input. Implementación de todos los métodos de una clase.

- 36 -

Sistemas - Área de Codificación -----------------------------------------------------------------------------------------------------------------------------------------------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 MS IN X…X

: : : :

Por definición SAP Módulo SAP (ver tabla 1) Constante 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 MS CE X…X

: : : :


Ejm: ZMMCE_RESERVAS01

ENHANCEMENT IMPLEMENTATION Los nombres de estos objetos tendrán la siguiente forma Z[MS]EI_TTTT_[X…X] Donde: Z MS EI TTTT X…X

: : : : :

Por definición SAP Módulo SAP (ver tabla 1) Constante Código de transacción que se está ampliando 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 Si afecta a MIGO y MB01

=> ZSDEI_VA0X_SAVE_POPUP => ZMMEI_MIGO_MB01_VALIDA

- 37 -

Sistemas - Área de Codificación -----------------------------------------------------------------------------------------------------------------------------------------------TABLA Los nombres de estos objetos tendrán la siguiente forma Z[MS]T_[X…X] Donde: Z MS T X...X

: : : :


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 : NN :

Por definición SAP 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”.

- 38 -

Sistemas - Área de Codificación -----------------------------------------------------------------------------------------------------------------------------------------------VISTA Los nombres de estos objetos tendrán la siguiente forma Z[MS]V_[X…X] Donde: Z MS V X...X

: : : :


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 MS S X...X

: : : :


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 MS TT X...X

: : : :


Ejm: ZMMTT_RESERVAS.

- 39 -

Sistemas - Área de Codificación -----------------------------------------------------------------------------------------------------------------------------------------------ELEMENTO DE DATO Los nombres de estos objetos tendrán la siguiente forma ZE_[X…X] Donde: Z : E : X…X :

Por definición SAP Constante Descripción literal

Ejm: ZE_BANCO

DOMINIO Los nombres de estos objetos tendrán la siguiente forma ZD_[CCCC][NNN][_D] Donde: Z D CCCC NNN D

: : : : :

Por definición SAP Constante Tipo de formato del campo (ver tabla 3) Longitud del campo 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 D AV XXX

: : : :

Por definición SAP Constante Constante 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

- 40 -

Sistemas - Área de Codificación -----------------------------------------------------------------------------------------------------------------------------------------------AYUDA DE BÚSQUEDA Los nombres de estos objetos tendrán la siguiente forma ZH_[X…X] Donde: Z : H : X…X :


Ejm: ZH_USERS

OBJETO DE BLOQUEO Los nombres de estos objetos tendrán la siguiente EZ_[X...X] Donde: E : Z : X...X :

Prefijo Obligatorio SAP Por definición SAP 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 MS SS X…X

: : : :


Ejm: ZSDSS_ADUANA

ESTILO (SAPSCRIPT) Los nombres de estos objetos tendrán la siguiente forma ZST_[NNN] Donde: Z : ST : NNN :

Por definición SAP Constante 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 MS SF X…X

: : : :


Ejm: ZSDSF_ADUANA

- 41 -

Sistemas - Área de Codificación -----------------------------------------------------------------------------------------------------------------------------------------------ESTILO (SMARTFORM) Los nombres de estos objetos tendrán la siguiente forma ZST_[X…X] Donde: Z MS ST X…X

: : : :

Por definición SAP Módulo SAP (ver tabla 1) Constante 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 : MT : X…X :


GRUPO DE FUNCIONES Los nombres de estos objetos tendrán la siguiente forma Z[MS]GF_[X...X] Donde: Z MS GF X...X

: : : :

Por definición de SAP Módulo SAP (ver tabla 1) Constante 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. previamente coordinado con el Supervisor ABAP.

FUNCION Los nombres de estos objetos tendrán la siguiente forma Z[MS]F_[X...X] Donde: Z MS F X...X

: : : :


Ejm: ZFIF_VERPAGOS

- 42 -

El GF a tomar será

Sistemas - Área de Codificación -----------------------------------------------------------------------------------------------------------------------------------------------RFC Los nombres de estos objetos tendrán la siguiente forma Z[MS]RFC_[X…X] Donde: Z MS RFC X...X

: : : :


Ejm: ZSDRFC_TIPODOC

APLICACION BSP Los nombres de estos objetos tendrán la siguiente forma Z[MS]BSP_[X...X] Donde: Z MS BSP X...X

: : : :


Ejm: ZMMBSP_LIBERA_OC

IMPLEMENTACION BADI Los nombres de estos objetos tendrán la siguiente forma Z[X...X][N] Donde: Z : X...X : N :

Por definición SAP Descripción literal, de preferencia nombre de definició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 Interfase

Z[MS]CL_[X…X] Z[MS]IF_[X…X]

Donde: Z MS CL/IF X...X


: : : :

- 43 -

Sistemas - Área de Codificación -----------------------------------------------------------------------------------------------------------------------------------------------BUSINESS OBJECT Los nombres de estos objetos tendrán la siguiente forma ZBO_[X…X] Donde: Z : BO : X...X :


Ejm: ZBO_CRM

ENTERPRISE SERVICE Los nombres de estos objetos tendrán la siguiente forma Z[MS][WS_[X…X] Donde: Z MS WS X...X

: : : :

Por definición SAP Módulo SAP (Ver tabla 1) Constante 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 : MS : NNN :

Por definición SAP Módulo SAP (Ver tabla 1) 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 MS GU X...X

: : : :


Ejm: ZSDGU_VENTAS

- 44 -

Sistemas - Área de Codificación -----------------------------------------------------------------------------------------------------------------------------------------------INFOSET (QUERY) Los nombres de estos objetos tendrán la siguiente forma Z[MS]IS_[X...X] Donde: Z MS IS X...X

: : : :


Ejm: ZSDIS_DOC_VENTAS

QUERY Los nombres de estos objetos tendrán la siguiente forma Z[MS]Q_[X...X] Donde: Z MS Q X...X

: : : :


Ejm: ZSDQ_ENTREGAS

PROYECTO (LSMW) Los nombres de estos objetos tendrán la siguiente forma ZP_[X...X] Donde: Z : P : X...X :


Ejm: ZP_RANSA

SUB PROYECTO (LSMW) Los nombres de estos objetos tendrán la siguiente forma Z[MS]SP_[X...X] Donde: Z MS SP X...X

: : : :


Ejm: ZMMSP_PEDIDOS

- 45 -

Sistemas - Área de Codificación -----------------------------------------------------------------------------------------------------------------------------------------------OBJETO (LSMW) Los nombres de estos objetos tendrán la siguiente forma Z[MS]O_[X...X] Donde: Z MS O X...X

: : : :


Ejm: ZMMO_ME21N_01

CLASE DE DESARROLLO Los nombres de estos objetos tendrán la siguiente forma Z[MS] Donde: Z : MS :

Por definición SAP 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 : MS : X...X :

Por definición de SAP Módulo SAP (ver tabla 1) 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 : MS : NN :

Por definición SAP Módulo SAP (ver tabla 1) Correlativo de 2 dígitos

Ejm: ZPP01 Nota: Preferentemente usar una clase por módulo

- 46 -

Sistemas - Área de Codificación -----------------------------------------------------------------------------------------------------------------------------------------------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 : MS : NN :

Por definición SAP Módulo SAP (Ver tabla 1) Correlativo numérico

Ejm: ZWM01

- 47 -

Sistemas - Área de Codificación -----------------------------------------------------------------------------------------------------------------------------------------------ANEXOS TABLA DE PARÁMETROS TABLA 1. MÓDULOS Aplicación BC BW CRM CO CS FI HR MM PM PP PS QM SD WM

Descripción Uso genérico Business Warehouse Customer Relationship Management Controlling Servicio al Cliente Finanzas Recursos Humanos Materiales Mantenimiento Producción Gestión de Proyectos Calidad Ventas y Distribución Gestión de Almacenes

TABLA 2. TIPO DE PROGRAMA / TRANSACCIÓN Código Denominación Válido para programa ó transacción: B Batch P

Procesos y otros desarrollos

R

Reporte

M Mantenimiento de tablas Válido sólo para transacción: A Actualización Q Query

Descripción En ellos se encuentran los programas que manejan Batch Input, Call Transaction, etc 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. Para todos aquellos programas que impliquen una selección de datos y un listado en pantalla. Procesos exclusivos al mantenimiento o carga inicial de una tabla Transacción de actualización de tabla. Transacción creada para query

TABLA 3. TIPO DE FORMATO Código CHAR CURR DATS DEC FLTP INT NUMC QUAN TIMS UNIT

Descripción String Campo moneda, almacenado como DEC Campo para fecha (AAAAMMDD), almacenado como CHAR (8) Campo cálculo o de importe con coma y signo +/Cifra coma flotante con 8 byte de exactitud Entero String sólo con cifras Campo cantidad, apunta a campo unidades con formato UNIT Campo hora (HHMMSS), almacenado como CHAR (6) Clave de unidades para campos QUAN

- 48 -

ID C D P F I N Q T U

Sistemas - Área de Codificación -----------------------------------------------------------------------------------------------------------------------------------------------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.

- 49 -

Sistemas - Área de Codificación -----------------------------------------------------------------------------------------------------------------------------------------------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

- 50 -


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

- 51 -


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

- 52 -

Sistemas - Área de Codificación -----------------------------------------------------------------------------------------------------------------------------------------------IMÁGENES IMAGEN 10.4.a

- 53 -

Sistemas - Área de Codificación -----------------------------------------------------------------------------------------------------------------------------------------------IMAGEN 10.4.b

IMAGEN 10.4.c

- 54 -

ESTÁNDARES DE PROGRAMACIÓN ABAP4 -VERSIÓN 1.0 -2014

Recommend Documents