Está en la página 1de 51

SUBGERENCIA DE TECNOLOGÍA DE INFORMACIÓN - ABBOTT EPD PERÚ

Estándares de
Programación ABAP 4
Una guía rápida con respecto a nombres y mejores
prácticas en ABAP

- Versión 1.0 -
2018

Preparado por: Luis Fajardo/Juan Ullauri Fecha de Preparación: 24.11.2017

Revisado y aprobado por: Fecha de Aprobación:

Fecha Efectiva:
Tabla de contenido
OBJETIVO ............................................................................................................................................................ 3
1. SOBRE LAS OT’S .............................................................................................................................................. 3
2. PAQUETE-Clase de Desarrollo ........................................................................................................................ 4
3. Objetos de Prueba .......................................................................................................................................... 5
4. Estructura para programas ............................................................................................................................. 5
4.1. Comentarios ............................................................................................................................................ 5
4.2. Cabecera del programa ........................................................................................................................... 5
4.3. Objetos de Autorización .......................................................................................................................... 8
4.4. Declaración de datos globales ................................................................................................................. 8
4.5. Declaración de campos de pantalla......................................................................................................... 9
4.6. Validación de campos de pantalla e inicialización................................................................................. 10
4.7. Rutina principal del programa ............................................................................................................... 10
4.8. Tratamiento de los datos obtenidos. .................................................................................................... 11
4.9. Subrutinas internas................................................................................................................................ 11
4.10. Convención para nombres internos ABAP4/SAP ................................................................................. 12
5. Recomendaciones generales sobre el formato ............................................................................................ 14
5.1. Subrutinas ( FORMS ) ............................................................................................................................. 14
5.2. Programas INCLUDE .............................................................................................................................. 14
5.3. Textos de Selección ............................................................................................................................... 15
5.4. Símbolos de texto .................................................................................................................................. 15
5.5. Pantallas ................................................................................................................................................ 15
5.6. Dynpros, Status y Títulos ....................................................................................................................... 15
5.7. Status GUI .............................................................................................................................................. 16
7. PERFORMANCE ............................................................................................................................................. 21
8. MODULARIZACION Y REUTILIZACIÓN ........................................................................................................... 24
9. VERIFICACIÓN AMPLIADA ............................................................................................................................. 26
10. PAUTAS ANTES DEL TRANSPORTE A PRD ................................................................................................... 27
11. NOMENCLATURA DE OBJETOS DE REPOSITORIO SAP ................................................................................ 28
12. RESPECTO A CONSTANTES (TABLA DE CONSTANTES) ................................................................................ 42
ANEXOS............................................................................................................................................................. 44
TABLA DE PARÁMETROS................................................................................................................................... 44
GUIAS ................................................................................................................................................................ 46
OBJETIVO

Contar con características comunes para uniformizar la nomenclatura a utilizar en los desarrollos ABAP, permitiendo
un orden, organización a identificación rápida, precisa y oportuna durante la etapa de desarrollo y mantenimiento.

1. SOBRE LAS OT’S

Las órdenes de transporte deben ser nombradas de acuerdo a la siguiente nomenclatura:

<Tipo> - <Categoría> <Código Actividad> - <Descripción> <Versión>

Donde:

Tipo : CU (Customizing), WB (Workbench), TC (Transporte de Copias)

Categoría : PRY (Proyecto), REQ (Requerimiento), INC (Incidencia), SEG (Seguridad TI)

Código Actividad : Código de actividad registrado por el Analista Funcional Responsable

Descripción : Texto descriptivo

Versión : Si es que se genera más de una OT Relacionada. Comenzar con 00.

Nota:

- La clasificación de la Categoría y Código de Actividad será brindada por el Analista Funcional Responsable al
momento de aceptar la OC y/o iniciar el requerimiento.

- La Categoría “SEG” sólo será usada para requerimientos realizados por el Área de Seguridad TI.

- 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

Proyecto Impulso Reporte de M.Villanue


SD PYH_000049 UNI TEP-000001 1 Clientes va

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

WMS Ampliación
de

WM PYP_000032 la capacidad de TEP-000001 1 Ubicación para traslados I.Delgado

almacenamiento

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

2. PAQUETE-Clase de Desarrollo

Para el caso de objetos de Mejora Continua, la asignación estará relacionada con el módulo SAP al que pertenece.

Para el caso de objetos de Proyectos, debe crearse un paquete exclusivo, a fin de tener identificado todos los objetos
que se crearon a partir de él.

Ej:

Paquete Proyecto Descripción


ZFI_ABAP Mejora Continua jora Continua Desarrollos FI ABAP adulo FI
ZCO_ABAP Mejora Continua Desarrollos CO ABAP
ZMM_ABAP Mejora Continua Desarrollos MM ABAP
ZPP_ABAP Mejora Continua Desarrollos PP ABAP
ZSD_ABAP Mejora Continua Desarrollos SD ABAP
ZVMS_ABAP Mejora Continua Desarrollos VMS ABAP
ZFM_ABAP Mejora Continua Desarrollos FM ABAP
ZCS_ABAP Mejora Continua Desarrollos CS ABAP
ZDP_ABAP Mejora Continua Desarrollos DP ABAP
3. 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 YY.

4. Estructura para programas

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

4.2. Cabecera del programa

Las primeras líneas del programa deben ser destinadas al nombre del programa, clase de mensaje, tamaño del reporte
de salida, etc.

El Titulo de modificaciones tiene el sgte criterio:

Item: Indica  <Acción> @<NNN>

Donde Acción puede ser: INSERT (Insertar), REPLACE (Modificar), DELETE (Comentar).

NNN: Número correlativo de 3 dígitos.

Num_Ticket: Numero de Ticket de atención.

Desarrollador: Nombre del Programador

Funcional: Nombre del Analista que solicita el cambio.

Fecha: Fecha de modificación

Objetivo: En breve texto indicar el motivo del cambio.


Ejemplo:

Nota:

El título MODIFICACIONES, sólo se coloca la primera vez que se va a hacer una modificación al programa, luego cada
solicitud de cambio será añadido como se indica en el ejemplo.

Ejemplo de modificaciones en el programa:

Caso 1: Agregar varias líneas de código.


Caso 2: Modificar varias líneas de código.

Caso 3: Eliminar/Comentar varias líneas de código.

Caso 4: Agregar una línea de código.

Caso 5: Modificar una línea de código.

Caso 6: Eliminar/Comentar una línea de código.


4.3. Objetos 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.

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

Ejemplo:
Las primeras líneas de este bloque deben utilizarse para la declaración de las tablas 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.

CONSIDERAR:

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, a usar las líneas
de cabeceras (_WA_XXXX), por motivos de performance.

4.5. 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 de este tipo 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 selección, evitando
que el usuario ejecute el programa por error. La declaración de parámetros de pantalla debe respetar el siguiente
formato:
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”.

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

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.

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

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.

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

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 último, se creará una subrutina adicional donde se codificarán las sentencias necesarias para emitir el reporte.
(WRITE, ALV, etc.)

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

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

Objeto de programación Ámbito Tipo Dato Valor


global sin tipo gt_<nombre tabla>
global estándar gdt_<nombre tabla>
global sorted gst_<nombre tabla>
global hashed ght_<nombre tabla>
local sin tipo lt_<nombre tabla>
local estándar ldt_<nombre tabla>
TABLA INTERNA
local sorted lst_<nombre tabla>
local hashed lht_<nombre tabla>
static sin tipo st_<nombre tabla>
static estándar sdt_<nombre tabla>
static sorted sst_<nombre tabla>
static hashed sht_<nombre tabla>
global sin tipo gwa_<nombre estructura >
ESTRUCTURA local sin tipo lwa_<nombre estructura >
static sin tipo swa_<nombre estructura>
global C carácter gs_<nombre variable>
N cadena numérica gn_<nombre variable>
D fecha gd_<nombre variable>
T hora gh_<nombre variable>
X byte (hexadecimal) gx_<nombre variable>
VARIABLE I entero gi_<nombre variable>
P número empaquetado gp_<nombre variable>
F número punto flotante gf_<nombre variable>
otro g_<nombre variable>
local C carácter ls_<nombre variable>
N cadena numérica ln_<nombre variable>
D fecha ld_<nombre variable>
T hora lh_<nombre variable>
X byte (hexadecimal) lx_<nombre variable>
I entero li_<nombre variable>
P número empaquetado lp_<nombre variable>
F número punto flotante lf_<nombre variable>
otro l_<nombre variable>
static C carácter ss_<nombre variable>
N cadena numérica sn_<nombre variable>
D fecha sd_<nombre variable>
T hora sh_<nombre variable>
X byte (hexadecimal) sx_<nombre variable>
I entero si_<nombre variable>
P número empaquetado sp_<nombre variable>
F número punto flotante sf_<nombre variable>
otro s_<nombre variable>
sin ámbito sin tipo using pi_<nombre variable>
PARÁMETROS changing po_<nombre variable>
(de una rutina FORM)
tables pt_<nombre variable>
PARÁMETRO DE ENTRADA sin ámbito sin tipo p_<nombre parámetro>
SELECT-OPTIONS sin ámbito sin tipo s_<nombre select-option>

BLOCKS SELECTION sin ámbito sin tipo b_<nombre del bloque>


SCREEN
global sin tipo gr_<nombre rango>
RANGOS local sin tipo lr_<nombre rango>
static sin tipo sr_<nombre rango>
global sin tipo gc_<nombre constante>
CONSTANTES
local sin tipo lc_<nombre constante>
global sin tipo g_<nombre del objeto apuntado>
Ejm:
FIELD SYMBOL Field Symbol : <g_matnr>

local sin tipo l_<nombre del objeto apuntado>


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

global sin tipo gty_<nombre tipo>


TIPOS
local sin tipo lty_<nombre tipo>
global sin tipo gtyt_<nombre tipo tabla>
estándar gtyd_<nombre tipo tabla>
sorted gtys_<nombre tipo tabla>
hashed gtyh_<nombre tipo tabla>
TIPOS TABLA
local sin tipo ltyt_<nombre tipo tabla>
estándar ltyd_<nombre tipo tabla>
sorted ltys_<nombre tipo tabla>
hashed ltyh_<nombre tipo tabla>
global sin tipo gcl_<nombre objeto>
CLASES
local sin tipo lcl_<nombre objeto>
global sin tipo go_<nombre objeto>
OBJETOS
local sin tipo lo_<nombre objeto>
static sin tipo so_<nombre objeto>
global importing parámetro IP_<nombre parámetro>
global importing estructura IW_<nombre estructura>
global importing tabla IT_<nombre de la tabla>
global exporting parámetro EP_<nombre parámetro>
PARÁMETROS DE global exporting estructura EW_<nombre estructura>
MÓDULO DE
global exporting tabla ET_<nombre de la tabla>
FUNCIONES
global modify parámetro MP_<nombre parámetro>
global modify estructura MW_<nombre estructura>
global modify tabla MT_<nombre de la tabla>
tables tabla T_<nombre de la tabla>
global importing parámetro IP_<nombre parámetro>
global importing estructura IW_<nombre estructura>
global importing tabla IT_<nombre de la tabla>
global importing clase IC_<nombre de la clase>
global exporting parámetro EP_<nombre parámetro>
global exporting estructura EW_<nombre estructura>
global exporting tabla ET_<nombre de la tabla>

PARÁMETROS DE global exporting clase EC_<nombre de la clase>


MÉTODOS DE CLASES global changing parámetro CP_<nombre parámetro>
global changing estructura CW_<nombre estructura>
global changing tabla CT_<nombre de la tabla>
global changing clase CC_<nombre de la clase>
global returning parámetro RP_<nombre parámetro>
global returning estructura RW_<nombre estructura>
global returning tabla RT_<nombre de la tabla>
global returning clase RC_<nombre de la clase>

5. Recomendaciones generales sobre el formato

En los puntos siguientes se detallan las normas generales que rigen para el formato del entorno desarrollo y que
pueden formar parte de un programa ABAP.

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

5.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
ZMMZNNNN_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.
ZMMZNNNN_SEL Los parámetros de selección iniciales.
ZMMZNNNN_MAI El proceso principal y los eventos. Ejm: INITIALIZATION. START-OFSELECTION, AT SELECTION
SCREEN, etc.
ZMMZNNNN_F01 Las subrutinas del programa.
ZMMZNNNN_O01 Process Before Output. Los Modules Output y las subrutinas implicadas.
ZMMZNNNN_I01 Process After Input. Los modules Input y las subrutinas implicadas.
ZMMZNNNN_CLA La implementación de todos los métodos de una clase.
ZMMZNNNN_ALV La implementación de los ALV.

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.

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

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

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

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

Observación: 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.

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

6. CALIDAD EN DESARROLLOS ABAP

En los puntos siguientes se detallan algunas recomendaciones a tomar en cuenta en la programación.

Consideraciones Ejemplos
No usar LIKE como referencia a tipos de Incorrecto:
diccionario, usar TYPE. DATA: GWA_KNA1 LIKE KNA1.
Correcto:
DATA: GWA_KNA1 TYPE KNA1.
Se debe de especificar la longitud de la variable Incorrecto:
que se está definiendo. 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 Incorrecto:
tener asignado un tipo, si no se sabe qué tipo va a METHODS METH IMPORTING P1 EXPORTING P2.
tener asignado se declara como type ANY. Correcto:
METHODS METH IMPORTING P1 TYPE ANY EXPORTING P2 TYPE ANY.
No está permitido transferir directamente los Incorrecto:
campos del sistema como parámetro, sino a través CALL FUNCTION FUN IMPORTING P = SY-SUBRC.
de una variable. 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 Incorrecto:
objects, porque es ambigua. Una forma de TABLES: BKPF.
referenciarlo es a través de un work area. Correcto:
DATA: GWA_BKPF TYPE BKPF.
No está permitido el uso de Field-Symbols si es Incorrecto:
que no tiene un tipo de asignación. En ABAP FIELD-SYMBOLS: <G_VALUE>.
objects la adición type al field-symbols es Correcto:
obligatorio. 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. Incorrecto:
Si se requiere memoria inicial se puede especificar DATA: BEGIN OF GT_KNA1 OCCURS 0,
agregando la sentencia INITIAL SIZE. 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 Incorrecto:
interna, no está permitido hacer CLEAR dentro del LOOP AT GT_KNA1 INTO GWA_KNA1.
LOOP, ya que esta borraría todo el contenido de la CLEAR GT_KNA1.
tabla interna. …..
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 Incorrecto:
internas están prohibidas ya que no está permitido INSERT TABLE GT_BKPF.
trabajar directamente con la cabecera de la tabla COLLECT GT_BKPF.
interna; por el contrario ahora se utilizan work READ TABLE GT_BKPF…
áreas o field-symbols. MODIFY TABLE GT_BKPF…
MODIFY GT_BKPF… WHERE …
DELETE TABLE GT_BKPF.
LOOP ATGT_BKPF…
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 Incorrecto:
a la base de datos están prohibidas. SELECT … FROM VBAK.
Se debe de trabajar utilizando work areas. 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.
Los valores no deben ser fijados en el código Incorrecto:
fuente. SELECT * FROM marc WHERE werks EQ „5000‟ …
La existencia de valores fijos dentro del programa IF vbfa-vbtyp_n EQ „J‟ …
dificulta su mantenimiento, portabilidad y w_cost = mbew-strps * 1.2.
reutilización. Correcto: Para evitar fijar valores, se pueden utilizar parámetros de
Además, demuestra desprolijidad en el diseño. 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.
Los eventos (END-OF-SELECTION, TOP-OFPAGE, Correcto:
etc.) deberán aparecer, en lo posible, en el código, INITIALIZATION.
en el orden en que serán utilizados. Si algún ...
evento no estuviese siendo utilizado, deberá ser AT SELECTION-SCREEN.
retirado. ...
Todas las Subrutinas (FORMs) serán colocadas START-OF-SELECTION.
después del código principal en un INCLUDE de PERFORM cargar_datos.
FORMs. Los FORMs deberán ser colocados, en lo PERFORM procesar_datos.
posible, en el orden en que serán llamados. PERFORM imprimir_datos.

END-OF-SELECTION.

FORM cargar_datos.

ENDFORM
FORM procesar_datos.

ENDFORM
FORM imprimir_datos.

ENDFORM

El nombre de la subrutina deberá ser descriptivo, y Correcto:


comenzar con un verbo en infinitivo + el objeto. *------------------------------------------------------*
Por ejemplo: * Form GUARDAR_ULTIMA_EJECUCION
PERFORM buscar_proveedor. *------------------------------------------------------*
PERFORM grabar_pedido. * Lee la tabla ZZLRT donde la última Fecha y
PERFORM calcular_iva_factura. * hora de ejecución del programa es guardada
Toda Subrutina también debe tener un *------------------------------------------------------*
encabezado conteniendo una breve descripción de *  PI_JOBID código interno de JOB
su funcionalidad y los parámetros de entrada y *  PO_STATUS resultado proceso
salida. *------------------------------------------------------*
Una Subrutina deberá tener solo un proceso FORM GUARDAR_ULTIMA_EJECUCION USING PI_JOBID
principal. En caso de que haya más de un proceso, CHANGING PO_STATUS.
entonces deberá ser dividida en múltiples …
Subrutinas. …
Subrutinas que podrían ser utilizadas en otros ENDFORM.
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.
Las estructuras IF-ENDIF, LOOP-ENDLOOP, Correcto:
CASE-ENDCASE, DO-ENDDO, etc. no deberán CASE ln_var:
presentar una extensión excesiva en cuanto a la WHEN ‘01’.
longitud de líneas ni a profundidad (anidamiento). PERFORM procesar_opcion_01.
Se deberá llegar a un equilibrio de estas WHEN ‘02’.
características utilizando subrutinas. Para esto se PERFORM procesar_opcion_02.
deben estructurar el módulo teniendo en cuenta WHEN ‘03’.
los conceptos de cohesión y acoplamiento. PERFORM procesar_opcion_03.
WHEN OTHERS
PERFORM procesar_opcion_otros.
ENCASE.
Cada comando deberá comenzar en una nueva Incorrecto:
línea para una mejor visualización del código. De START-OF-SELECTION.
esta forma, permitirá un mejor mantenimiento del SELECT matnr werks lgort labst FROM mara
código (borrado, comentario y debugging). INTO TABLE gt_stock_mat
Para mantener los programas estructurados, WHERE matnr in s_matnr.
deberemos indentar los diferentes niveles de IF sy-subrc NE 0.
jerarquía con 2 espacios. MESSAGE E001.
El PRETTY PRINTER podrá ser utilizado para ENDIF.
indentar automáticamente los comandos. END-OF-SELECTION.
Comandos largos deberán ser particionados en
varias líneas e indentados por la primera línea Correcto:
para permitir una mejor visualización. 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.
Siempre que se utilicen variables relacionadas Como las tres variables están relacionadas porque definen un nro. de
entre sí, deberán declararse como campos de una asiento que se necesitar tratar en el programa:
estructura y no como variables “sueltas”.
Esto permite simplificar el desarrollo al poder
manejarlas como una única estructura ( Incorrecto:
asignaciones con move-corresponding , DATA:
inicialización, pase de parámetros, etc.). 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.
Utilizar sentencia MOVE en vez de Incorrecto:
MOVECORRESPONDING siempre que sea posible. TYPES: BEGIN OF LTY_STOCK,
En la definición de datos se debe de usar type en MATNR TYPE MATNR, " CÓDIGO
vez de like, también se debe evitar los OCCURS WERKS TYPE WERKS, " CENTRO
0,with header line y trabajar con work áreas, field LGORT TYPE LGORT, " ALMACÉN
symbols. 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.

Todos los mensajes de error deberán ser Incorrecto:
implementados vía MESSAGE IDs. 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.
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).
Para todos los textos utilizados a lo largo del Incorrecto:
programa, utilice TEXT ELEMENTs. 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.
No debe dejarse código muerto injustificado en * Se reemplaza el parámetro de salida por una variable auxiliar tipo N.
los programas, ya que es desprolijo y dificulta CALL FUNCTION „CONVERSION_EXIT_ALPHA_OUTPUT‟
el seguimiento y el debugging. EXPORTING
Cuando esté justificado, dejar indicado con input = t_stock_mat-matnr
comentario el motivo. IMPORTING
En el caso de modificaciones al programa * output = t_stock_mat-matnr. “DELETE @001
original, dejar comentado el código output = ln_matnr_aux. “INSERT @001
reemplazado / corregido, con la
correspondiente referencia de modificación.
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.
Deben comentarse todas las variables declaradas a Correcto:
la derecha de la variable con “ * 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
Cuando se lista un campo numérico que Incorrecto:
presentaba decimales es necesario especificarlos WRITE T_LOG-NETWR.
por medio de una variable, además de indicar la Correcto:
moneda si guarda valores monetarios. DATA: L_WAERK TYPE VBRK-WAERK.
WRITE LWA_LOG-NETWR CURRENCY L_WAERK UNIT ‘3’.
No incluir una estructura de una tabla como parte Incorrecto:
de la definición de una segunda tabla. 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.

7. PERFORMANCE

Consultas a Base de Datos (SELECTS)


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

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 <l_facturas>.
READ TABLE lt_clientes INTO lwa_clientes
WITH KEY kunnr = <l_facturas>-kunnr.
IF sy-subrc EQ 0.
<l_facturas>-kunnr = lwa_clientes_aux-kunnr.
ENDIF.
ENDLOOP.
Performance memoria dinámica.
TABLAS INTERNAS Correcto:
La manera más eficiente de buscar un único registro en SORT GT_TABLA1 BY CAMPO1 ASCENDING.
una tabla interna del tipo standard es utilizando el LOOP AT GT_TABLA1….
comando: READ TABLE ... WITH BINARY SEARCH. …
Debiendo estar ordenada la tabla Interna. ENDLOOP.
En caso de tener que repetir búsquedas sobre tablas, es SORT GT_TABLA2 BY CAMPO1 ASCENDING.
conveniente seleccionar los datos una sola vez sobre una LOOP AT GT_TABLA2….
tabla interna, y trabajar sobre ella las veces que sea …
necesario. ENDLOOP.
SORT Incorrecto:
El SORT de una tabla Interna, es más eficiente si los LOOP AT ITAB.
campos son especificados. CHECK T_ABC = KVAL.
Siempre identificar si un SORT es ascending o descending ...
y especificar la cláusula BY <fields>. ENDLOOP.
Caso contrario todos los campos serán clasificados. Correcto:
LOOP...WHERE LOOP AT GT_ABC INTO GWA_ABC WHERE K = GS_VAL.
El comando LOOP .... WHERE es más eficiente que el …
comando LOOP / CHECK, pues evalúa la condición ENDLOOP.
internamente.
Siempre usar los comandos CLEAR/ REFRESH después de
finalizar un LOOP, cuando los datos no deban ser
reutilizados.
Si dos tablas tienen la misma estructura, es más eficiente Incorrecto:
copiar el contenido de una a otra directamente y no a LOOP AT GT_VBAK INTO GWA_VBAK.
través de un LOOP. APPEND GWA_VBAK TO GT_AUX.
Si se desea modificar un campo de una tabla interna, es ENDLOOP.
más eficiente modificarlo especificando el campo. Correcto:
GT_AUX[] = GT_VBAK[].
Sin embargo, si GT_AUX no está vacía y no debe de ser
sobre-escrito entonces
use:
APPEND LINES OF GT_VBAK TO GT_AUX.
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 Incorrecto:
interna es mejor ordenar la tabla y borrar los duplicados y READ TABLE GT_TAB INDEX 1 INTO GWA_PREV_LINE.
no hacerlos dentro de un LOOP. 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 Incorrecto:
registros de una tabla. 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 Correcto:
un volumen grande de accesos de base de datos IF NOT GT_TAB1[] IS INITIAL.
(dependientes en el tamaño de tablas). En lugar de ello SELECT FIELD1 FIELD2 FROM TABLE
utilizar FOR ALL ENTRES. 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 Incorrecto:
debemos de recorrer una dentro de otra, suponiendo que LOOP AT GT_TAB1.
contamos con dos tablas internas gt_tab1 en donde hay LOOP AT GT_TAB2 WHERE K = GT_TAB1-K.
m entradas y gt_tab2 donde hay n entradas, el número de ...
vueltas sería m x n. ENDLOOP.
Incluso, aunque hayamos puesto la cláusula WHERE. ENDLOOP.
En estos casos, donde además ambas tablas tengan los Correcto:
mismos campos clave, se recomienda usar un índice LI_INDX = 1.
interno para empezar la búsqueda en la segunda tabla, de LOOP AT GT_TAB1 INTO LWA_TAB1.
esta forma se reducirá el número de vueltas. LOOP AT GT_TAB2 INTO LWA_TAB2 FROM LI_INDX.
IF LWA_TAB2-K <> LWA_TAB1-K.
LI_INDX = SY-TABIX.
EXIT.
ENDIF.
" ...
ENDLOOP.
ENDLOOP.
Siempre que sea posible, utilice operaciones con arreglos Incorrecto:
en lugar de operaciones sobre una fila. La frecuente * Tabla GT_TAB tiene 100 entradas.
comunicación entre el programa de aplicación y el LOOP AT GT_TAB.
sistema de la base de datos produce una considerable INSERT INTO VERI_CLNT VALUES GT_TAB.
baja en la performance. ENDLOOP.
Correcto:
* Tabla GT_TAB tiene 100 entradas.
INSERT VERI_CLNT FROM TABLE GT_TAB.
Si la tabla interna tiene muchas entradas, en una Incorrecto:
búsqueda lineal a través de todas las entradas el tiempo READ TABLE GT_TAB WITH KEY k = „X‟.
consumido es bastante largo. Trate de mantener la tabla Correcto:
ordenada y usar búsqueda binaria. READ TABLE GT_TAB INTO LWA_TAB WITH KEY k = „X‟
BINARY SEARCH.

8. MODULARIZACION Y REUTILIZACIÓN

Modularización
Los programas deben estar modularizados Correcto:
completamente. START-OF-SELECTION.
Esto significa que el programa principal consistirá de una PERFORM buscar_datos.
serie de subrutinas (módulos), las cuales resumirán los PERFORM calcular_porcentajes.
procesos principales del programa. PERFORM grabar_log.
A su vez, cada, subrutina, se dividirá en forma coherente END-OF-SELECTION.
y balanceada en nuevas subrutinas, que dividirán PERFORM imprimir_reporte.
nuevamente el módulo en subprocesos. Y así PERFORM download_archivo.
sucesivamente. FORM buscar_datos.
La modularización se establece durante el diseño; implica ...
comprender la complejidad total del programa y dividirla ENDFORM.
en partes (ó módulos). Cada módulo o rutina ejecutará FORM calcular_porcentajes.
SOLO una acción principal o proceso. …
A través de la modularización se divide un “problema” ENDFORM.
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.
Parametrización de módulos
Solamente se deberán declarar variables globales cuando Recomendable:
realmente esté justificado. DATA: gwa_stock_mat TYPE mard.
Nunca deberán declararse variables globales que solo START-OF-SELECTION.
sean utilizadas luego dentro de algún módulo. PERFORM buscar_datos_stock changing gwa_stock_mat.
Utilizar pase de parámetros entre módulos. (USING, PERFORM imprimir_datos_stock using gwa_stock_mat.
CHAGING, TABLES). En este caso la variable gwa_stock_mat es global, si bien
Incluso cuando no fuera necesario el pase de parámetros dentro de las rutinas la variable está dentro de su ámbito
desde el punto de vista técnico, siempre es recomendable de incumbencia y podría ser referenciada, colocar el
indicarlo, de manera que sea más claro entender que la parámetro clarifica el seguimiento, se observa entonces
subrutina llamada, utiliza o modifica cierta variable. 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 Incorrecto:
idénticos niveles de la estructura conserven el mismo START-OF-SELECTION.
nivel PERFORM CARGAR_DATOS TABLES GT_DATA.
funcional. 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.
Reutilización
Se deberá tener en cuenta al momento del diseño del Recomendable:
programa, qué componentes del mismo podrán ser Tipos reutilizables, grabarlos en TYPE-POOLS.
reutilizados en desarrollos similares. Definiciones de variables reutilizables, grabarlos en
Para esto debe estar el desarrollo correctamente INCLUDES Rutinas (FORMs) reutilizables, grabarlos en
modularizado y parametrizado. ROUTINES-POOL o INCLUDES.
Rutinas sin parámetros son muy difíciles de reutilizar. Rutinas (FORMs) reutilizables, con parámetros de entrada
La reutilización mejora los tiempos de desarrollo, y salida, grabarlos en MODULOS DE FUNCIONES.
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.
9. 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.


10. PAUTAS ANTES DEL TRANSPORTE 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 OT’s 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 OT’s 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 o datos críticos no pasen por código duro sino por tabla de constantes
(ver punto 12).

 Revisar posibles dependencias (por ejemplo pasar una función cuyo grupo de funciones aún no está en
PRD).
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 [NNN] 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.

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

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.

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

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

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

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 grupos 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
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 d e 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

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

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

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

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

12. RESPECTO A CONSTANTES (TABLA DE CONSTANTES)

El uso de parámetros a través del manejo de una tabla de constantes es vital para hacer nuestros
programas escalables, claros y de fácil mantenimiento.

La tabla de constantes que usamos es: ZTCONSTANTES.

Los programas desarrollados deberán de tener la capacidad de soportar uno o más valores que
se puedan asociar en la tabla de constantes.

Considerar lo siguiente:

- El campo Módulo deberá estar acorde a la TABLA 1 (Obligatorio)


- El campo sociedad se llenará si es que se requiere aplicar la constante para una
sociedad en específico. No es obligatorio el llenado.
- El campo Programa tendrá el nombre del programa afectado. De ser posible, en la
llamada a la consulta de la tabla de constantes usar variables del Sistema. Dicho campo
es Obligatorio.
- El campo “Nombre campo” deberá tener el identificador del valor que se desea
obtener. En la definición de dicho identificador, deberá ser un valor constante en el
programa (Obligatorio).
- El campo “Secuencia” es un correlativo para cada clave registrada (Obligatorio).
- Los campos Módulo, Soc, Programa, Nombre Campo y Secuencia conforman la
clave con la que se accederá unívocamente a cada constante de la tabla.
- Los campos Signo, Opción, Valor Low y Valor High representan los valores a
obtener en el programa (parámetros o constantes).

A continuación, un ejemplo del llenado de dicha tabla.

Finalmente, los parámetros configurados serán documentados en los documentos


técnicos/funcionales entregados.
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


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


6. Ingresamos las actividades que se validan desde el programa y grabamos
7. Finalmente grabar, asignarlo a la OT de nuestro desarrollo y listo.
Imágenes

IMAGEN 10.4.a
IMAGEN 10.4.b

IMAGEN 10.4.c