Estandares de Programacion Abap4 - Versio PDF

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: Verónica Briceño Vásquez Fecha de Preparación: 20.10.2014

Revisado y aprobado por: Luis Alba Vera Fecha de Aprobación: 25.11.2014
Ruth Novoa La Torre Fecha de Aprobación: 25.11.2014
Versión 1.0 Fecha Efectiva: 01.12.2014
-2-
------------------------------------------------------------------------------------------------------------------------------------------------
INDICE
OBJETIVO 04
ALCANCE 04
1. Nomenclatura de OT’s 05
2. Marca para modificaciones 06
3. Objeto de Autorización 08
4. Grupo de Autorización 08
5. Paquete - Clase de desarrollo 08
6. Objeto de Prueba 09
7. ESTRUCTURA PARA PROGRAMAS

7.1. Comentarios 10
7.2. Cabecera del programa 10
7.3. Declaración de datos globales 11
7.4. Declaración de campos de pantalla 12
7.5. Validación de campos de pantalla e inicialización 13
7.6. Rutina principal del programa 14
7.7. Tratamiento de los datos obtenidos 15
7.8. Eventos de control 15
7.9. Subrutinas internas 16
8. Convención para nombres internos ABAP4/SAP 17
9. RECOMENDACIONES GENERALES SOBRE FORMATO

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

10.1. Codificación y Presentación 24
10.2. Performance 29
10.3. Modularización y reutilización 32
10.4. Verificación Ampliada 34
10.5. Puntos a revisar en una OT previo al pase a PRD 35
11. NOMENCLATURA DE OBJETOS DE REPOSITORIO SAP 36
ANEXOS
• TABLA DE PARÁMETROS 48
• GUIAS 49
G1. Acumular OTs
G2. Uso de SU24: Cómo asociar Tx con Objeto de autorización
• IMAGENES 53
-3-
------------------------------------------------------------------------------------------------------------------------------------------------
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-
------------------------------------------------------------------------------------------------------------------------------------------------
1. Nomenclatura de OT’s
Las órdenes de transporte deben ser nombradas de acuerdo a la siguiente nomenclatura:
<Tipo>-<Módulo> <Código Actividad> <Objeto Principal> <Descripción> <Versión> <Funcional>
Donde:
Tipo : CU (Customizing), WB (Workbench), TC (Transporte de Copias)
Módulo : CO, FI, MM, SD, etc.
Código Actividad : Código de actividad registrada en PMO
Objeto Principal : Transacción u objeto principal modificado
Descripción : Texto descriptivo
Versión : Cuando se maneja más de una OT relacionada. Comenzar con 00.
Funcional : Siglas de funcional responsable o solicitante
Nota:
- Si a la OT creada se le acumula una OT predecesora, se coloca como notación un (*) antes del número de
versión que le corresponde.
- Si la OT predecesora fue pasada a PRD, y se continúan con ajustes al mismo requerimiento, se sube el
nivel de la OT y se vuelve a empezar de 00 (Ejemplo: 1 00, 2 00, 3 00, etc).
- Para ver cómo acumular OTs, revisar sección ANEXOS -> GUIAS -> G1.
Ejm:
Mód Cod. Actividad Actividad Cod.Tarea ID OD Descripción (Tarea) Funcional

MM SOP_000019 SOPORTE VARIAS TEP-000002 2 Ajuste Reporte Pedido de Compras E.Izarra
WB-MM SOP_000019 ZMMR001 Ajuste Rep Ped compras 00 EIZARRA -> OT inicial
WB-MM SOP_000019 ZMMR001 Ajuste Rep Ped compras 01 EIZARRA -> No acumuló OT anterior

SD PYH_000049 Proyecto Impulso UNI TEP-000001 1 Reporte de Clientes M.Villanueva
WB-SD PYH_000049 ZSDR001 Reporte de Clientes 00 MV -> OT inicial

WB-SD PYH_000049 ZSDR001 Reporte de Clientes * 01 MV -> Acumuló la OT anterior

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
-5-
------------------------------------------------------------------------------------------------------------------------------------------------
2. Marca para modificaciones
Las marcas de modificación deben ser nombradas de acuerdo a la siguiente nomenclatura:
<Acción> @<NNN>
Donde:
Acción : - INSERT : Insertar
- REPLACE : Modificar
- DELETE : Comentar
NNN : Número correlativo de 3 dígitos
Modelo ejemplo:
CASO1: Agregar varias líneas de código
*{ INSERT @001
*----------------------------------------------------------------------*
* Form TEXTO_EXP
*----------------------------------------------------------------------*
FORM TEXTO_EXP USING PI_ASNUM.
DATA: LS_ASNUM TYPE ASMD-ASNUM,

LS_TDNAME TYPE THEAD-TDNAME.
REFRESH GDT_LINES.
CLEAR GDT_LINES.
CALL FUNCTION 'CONVERSION_EXIT_ALPHA_INPUT'

EXPORTING
INPUT = PI_ASNUM
IMPORTING
OUTPUT = LS_ASNUM.
LS_TDNAME = LS_ASNUM.
CALL FUNCTION 'READ_TEXT'

EXPORTING
ID = GC_ID
LANGUAGE = SY-LANGU
NAME = LS_TDNAME
OBJECT = GC_OBJECT
TABLES
LINES = GDT_LINES
EXCEPTIONS
NOT_FOUND = 4.
IF SY-SUBRC <> 0.
MESSAGE S006 WITH TEXT-003 PI_ASNUM TEXT-004.
ENDIF.
ENDFORM. "TEXTO_EXP
*} INSERT @001
-6-
------------------------------------------------------------------------------------------------------------------------------------------------
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-
------------------------------------------------------------------------------------------------------------------------------------------------
3. Objeto de Autorización
Todo desarrollo debe contar con la validación de uno o varios objetos de autorización según lo solicitado en
el requerimiento respectivo. Esto con el objetivo de restringir la información a mostrar o procesar.
Asimismo la transacción con su respectivo objeto de autorización debe registrarse en la tx SU24 a fin de
llevar un mejor control.
Ejm:
*----------------------------------------------------------------------*
* VALIDACION DE PARAMETROS DE PANTALLA
*----------------------------------------------------------------------*
AT SELECTION-SCREEN.
AUTHORITY-CHECK OBJECT 'ZMM_WERKS'
ID 'TCODE' FIELD SY-TCODE
ID 'WERKS' FIELD P_WERKS
ID 'ACTVT' FIELD '03'. "visualizar
IF SY-SUBRC NE 0.
MESSAGE E000 WITH TEXT-E01 P_WERKS.
ENDIF.
Nota:
- Considerar el campo actividad en la validación, la actividad a validar debe ir acorde a la función principal
del programa (crear, modificar, visualizar, borrar, imprimir, contabilizar, etc).
- Para ver cómo asociar Tx con O.A. en SU24, revisar sección ANEXOS -> GUIAS -> G2.
4. Grupo de Autorización
Toda tabla Z creada debe ser asociada a un grupo de autorización, según lo solicitado en el requerimiento
respectivo. Esto con el objetivo de restringir el acceso a la data de dicha tabla. Adicionalmente toda tx de
mantenimiento creada para una tabla Z debe validar un objeto de autorización. Existirá para ello un
programa único por módulo para la validación de objeto de autorización a tablas Z.
5. Paquete - Clase de desarrollo
Todo objeto de repositorio Z válido para PRD, debe crearse haciendo referencia a un paquete de desarrollo.
La asignación estará relacionada con el módulo SAP al que pertenece.
Ejm:
Paquete Descripción
ZBC Uso genérico
ZBW Business Warehouse
ZCO Controlling
ZCS Servicio al Cliente
ZFI Finanzas
ZHR Recursos Humanos
ZMM Materiales
ZPM Mantenimiento
ZPP Producción
ZPS Gestión de Proyectos
ZQM Calidad
ZSD Ventas y Distribución
ZWM Gestión de Almacenes
-8-
------------------------------------------------------------------------------------------------------------------------------------------------
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-
------------------------------------------------------------------------------------------------------------------------------------------------
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 -
------------------------------------------------------------------------------------------------------------------------------------------------
*&---------------------------------------------------------------------*
*& Actividad: PYH_000052 – Facturación Electrónica Chile Salmofood *
*& Marca....: @002 *
*& Funcional: Maria Campos *
*& Autor....: Ana Perez *
*& Fecha....: 15.10.2014 *
*& Motivo...: Enviar reporte por correo *
*&---------------------------------------------------------------------*
7.3. Declaración de datos globales
Esta sección se debe utilizar para la declaración de todas las constantes y variables globales utilizadas en el
programa. La declaración de datos debe respetar el siguiente formato:
Modelo ejemplo:
*----------------------------------------------------------------------*
* DECLARACION DE TABLAS *
*----------------------------------------------------------------------*
TABLES: T001W, "Centros/Sucursales
MBEW, "Valoración de material
MSEG. "Segmento doc.material
*----------------------------------------------------------------------*
* CONSTANTES *
*----------------------------------------------------------------------*
CONSTANTS: GC_SOBKZ TYPE QBEW-SOBKZ VALUE 'Q',
GC_XXXXX TYPE C LENGTH 10 VALUE 'OTROS',
GC_WERKS TYPE T001W-WERKS VALUE '105A'.
*----------------------------------------------------------------------*
* DECLARACION DE VARIABLES *
*----------------------------------------------------------------------*
TYPE-POOLS: SLIS. "Agregar comentario
* Campos globales
DATA: GS_BUKRS TYPE T001-BUKRS, "Adicionar comentario
GS_CAMPO2 TYPE C LENGTH 3, "Adicionar comentario
GN_CAMPO3 TYPE N, "Adicionar comentario
GD_BUDAT TYPE BKPF-BUDAT. "Adicionar comentario
* Tipos
TYPES: GTY_MARC TYPE MARC.
TYPES: BEGIN OF GTY_MAKT,
MATNR TYPE MAKT-MATNR,
MAKTX TYPE MAKT-MAKTX,
END OF GTY_MAKT.
*Tipo tabla
TYPES: GTYT_MARC TYPE TABLE OF MARC,
"Standard
GTYD_MARC TYPE STANDARD TABLE OF GTY_MARC,
"Hashed
GTYH_MARC TYPE HASHED TABLE OF GTY_MARC WITH UNIQUE KEY MATNR WERKS,
"Sorted
GTYS_MARC TYPE SORTED TABLE OF GTY_MARC WITH NON-UNIQUE KEY MATNR.
*Tablas internas
DATA: GT_MARC TYPE TABLE OF GTY_MARC,
"Standard
- 11 -
------------------------------------------------------------------------------------------------------------------------------------------------
GDT_MARC TYPE GTYD_MARC,
"Hashed
GHT_MARC TYPE GTYH_MARC,
"Sorted
GST_MARC TYPE GTYS_MARC.
* Estructuras
DATA: BEGIN OF GWA_XXXX,
BUKRS TYPE BKPF-BUKRS, "Sociedad
BELNR TYPE BSEG-BELNR, "Fecha de contabilización
END OF GWA_XXXX.
DATA: GWA_MARC LIKE LINE OF GT_MARC. "Agregar comentario
* Rangos
DATA: GR_BUKRS TYPE RANGE OF BKPF-BUKRS, "rango de sociedades
GWA_BUKRS LIKE LINE OF GR_BUKRS.
* Field symbols
FIELD-SYMBOLS: <GWA_MARC> LIKE LINE OF GDT_MARC,
<GS_MATNR> TYPE MARA-MATNR.
* Fields groups
FIELD-GROUPS: FG_HEADER, "Agregar comentario
FG_DETALLE. "Agregar comentario
Donde:
Las primeras líneas de este bloque deben utilizarse para la declaración de las tablas y estructura de datos
utilizada por el programa. Cada tabla declarada debe tener a su derecha el comentario sobre la descripción
breve de la misma.
La segunda sección del bloque se utilizará para la declaración de constantes.
La tercera sección del bloque se utilizará para la declaración de variables globales. Esto incluye campos,
tablas internas, estructuras, etc. en la forma y orden en que se muestra en el ejemplo de arriba.
Cada objeto adicionado debe comentarse.
Nota:
Debe tratarse en lo posible, definir las variables haciendo referencia a campos definidos en el diccionario de
datos, mediante la utilización de TYPE.
La sentencia OCCURS todavía se permite por razones de compatibilidad con versiones más antiguas. Sin
embargo, se recomienda que solamente se utilice las nuevas versiones de las definiciones de tablas. Esto
facilita reutilizar el código en un contexto de Objetos ABAP.
Se recomienda (en la medida de lo posible) el uso de FIELD-SYMBOLS para modificar una tabla interna, en
vez de usar líneas de cabeceras (_WA_XXXX), por motivos de performance.
7.4. Declaración de campos de pantalla
Esta sección se debe utilizar para la declaración de todos los campos que se mostrarán en la pantalla de
inicio del programa y que permiten la selección de la información (PARAMETERS, SELECT-OPTIONS,
ETC).
No debe crearse un programa sin al menos un parámetro de selección. Esto posibilitará que al ejecutar el
programa se muestre primero una pantalla de selección, con el título del programa y los campos de
- 12 -
------------------------------------------------------------------------------------------------------------------------------------------------
selección, evitando que el usuario ejecute el programa por error. La declaración de parámetros de pantalla
debe respetar el siguiente formato:
Modelo ejemplo:
*----------------------------------------------------------------------*
* DISEÑO PANTALLA DE SELECCION
*----------------------------------------------------------------------*
SELECTION-SCREEN BEGIN OF BLOCK B_01 WITH FRAME TITLE TEXT-B01.
PARAMETERS: P_BUKRS TYPE T001-BUKRS OBLIGATORY DEFAULT '10',
P_WERKS TYPE T001W-WERKS MEMORY ID WRK OBLIGATORY.
SELECT-OPTIONS: S_BKLAS FOR MBEW-BKLAS NO INTERVALS NO-EXTENSION,
S_MATNR FOR MSEG-MATNR.
SELECTION-SCREEN END OF BLOCK B_01.
SELECTION-SCREEN BEGIN OF BLOCK B_02 WITH FRAME TITLE TEXT-B02.

PARAMETERS: P_LFMON TYPE MBEW-LFMON OBLIGATORY,
P_LFGJA TYPE MBEW-LFGJA OBLIGATORY,
P_WAERS TYPE T001-WAERS OBLIGATORY.
SELECTION-SCREEN END OF BLOCK B_02.
PARAMETERS: P_ALV RADIOBUTTON GROUP G1 DEFAULT 'X',

P_REL RADIOBUTTON GROUP G1,
P_ALM_R AS CHECKBOX,
P_STCK AS CHECKBOX DEFAULT 'X'.
Donde:
Deben posicionarse los distintos PARAMETERS y SELECT-OPTIONS, de acuerdo a la posición en la que

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

PERFORM HELP_WAERS USING P_WAERS.
AT SELECTION-SCREEN ON BLOCK B_01.
AT SELECTION-SCREEN ON P_BUKRS.
- 13 -
------------------------------------------------------------------------------------------------------------------------------------------------
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 -
------------------------------------------------------------------------------------------------------------------------------------------------
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 -
------------------------------------------------------------------------------------------------------------------------------------------------
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 -
------------------------------------------------------------------------------------------------------------------------------------------------
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
Ámbito Tipo Dato Valor Ejemplo
programación
global sin tipo gt_<nombre tabla> gt_makt
global estándar gdt_<nombre tabla> gdt_makt
global sorted gst_<nombre tabla> gst_makt
global hashed ght_<nombre tabla> ght_makt
local sin tipo lt_<nombre tabla> lt_makt
local estándar ldt_<nombre tabla> ldt_makt
TABLA INTERNA
local sorted lst_<nombre tabla> lst_makt
local hashed lht_<nombre tabla> lht_makt
static sin tipo st_<nombre tabla> st_makt
static estándar sdt_<nombre tabla> sdt_makt
static sorted sst_<nombre tabla> sst_makt
static hashed sht_<nombre tabla> sht_makt
global sin tipo gwa_<nombre estructura > gwa_mara
ESTRUCTURA local sin tipo lwa_<nombre estructura > lwa_mara
static sin tipo swa_<nombre estructura> swa_mara
C caracter gs_<nombre variable> gs_texto
N cadena numérica gn_<nombre variable> gn_num3
D fecha gd_<nombre variable> gd_budat
T hora gh_<nombre variable> gt_uzeit
global X byte (hexadecimal) gx_<nombre variable> gx_byte
I entero gi_<nombre variable> gi_edad
P numero empaquetado gp_<nombre variable> gp_total
F numero punto flotante gf_<nombre variable> gf_total
otro g_<nombre variable> g_monto
C caracter ls_<nombre variable> ls_texto
N cadena numérica ln_<nombre variable> ln_num3
D fecha ld_<nombre variable> ld_budat
T hora lh_<nombre variable> lt_uzeit
VARIABLE local X byte (hexadecimal) lx_<nombre variable> lx_byte
I entero li_<nombre variable> li_edad
P numero empaquetado lp_<nombre variable> lp_total
F numero punto flotante lf_<nombre variable> lf_total
otro l_<nombre variable> l_monto
C caracter ss_<nombre variable> ss_texto
N cadena numérica sn_<nombre variable> sn_num3
D fecha sd_<nombre variable> sd_budat
T hora sh_<nombre variable> st_uzeit
static X byte (hexadecimal) sx_<nombre variable> sx_byte
I entero si_<nombre variable> si_edad
P numero empaquetado sp_<nombre variable> sp_total
F numero punto flotante sf_<nombre variable> sf_total
otro s_<nombre variable> s_monto
PARÁMETROS using pi_<nombre variable> pi_menge
sin po_meins
(de una rutina FORM) sin ámbito changing po_<nombre variable>
tipo
tables pt_<nombre variable> pt_ekpo
PARÁMETRO DE
sin ámbito sin tipo p_<nombre parámetro> p_ bukrs
ENTRADA
SELECT-OPTIONS
sin ámbito sin tipo s_<nombre select-option> s_bukrs
BLOCKS
SELECTION sin ámbito sin tipo b_<nombre del bloque> b_01
SCREEN
- 17 -
------------------------------------------------------------------------------------------------------------------------------------------------
global sin tipo gr_<nombre rango> gr_bukrs
RANGOS local sin tipo lr_<nombre rango> lr_bukrs
static sin tipo sr_<nombre rango> sr_bukrs
global sin tipo gc_<nombre constante> gc_edad_max

CONSTANTES
local sin tipo lc_<nombre constante> lc_edad_max
g<tipo>_<nombre del objeto <gs_matnr>

global -
apuntado> <gwa_makt>
FIELD SYMBOL
l<tipo>_<nombre del objeto <ls_matnr>
local -
apuntado> <lwa_makt>
<nombre subrutina>
El uso de using changing y
SUBRUTINAS sin ámbito sin tipo tables dependerá de la imprime_reporte
necesidad de la misma por
contar con variables globales.
MACROS sin ámbito sin tipo <nombre macro> llena_fieldcat
global sin tipo gty_<nombre tipo> gty_mara

TIPOS
local sin tipo lty_<nombre tipo> lty_mara
sin tipo gtyt_<nombre tipo tabla> gtyt_makt
estándar gtyd_<nombre tipo tabla> gtyd_makt

global
sorted gtys_<nombre tipo tabla> gtys_makt
hashed gtyh_<nombre tipo tabla> gtyh_makt

TIPOS TABLA
sin tipo ltyt_<nombre tipo tabla> ltyt_makt
estándar ltyd_<nombre tipo tabla> ltyd_makt

local
sorted ltys_<nombre tipo tabla> ltys_makt
hashed ltyh_<nombre tipo tabla> ltyh_makt
global sin tipo gcl_<nombre objeto> gcl_reporte

CLASES
local sin tipo lcl_<nombre objeto> lcl_reporte
global sin tipo go_<nombre objeto> go_alv
OBJETOS local sin tipo lo_<nombre objeto> lo_alv
static sin tipo so_<nombre objeto> so_alv

global
parámetro IP_<nombre parámetro> ip_matnr
importing
global
estructura IW_<nombre estructura> iw_makt
importing
global
tabla IT_<nombre de la tabla> it_ekpo
importing
global
PARÁMETROS DE parámetro EP_<nombre parámetro> ep_matnr
exporting
MÓDULO DE
global
FUNCIONES estructura EW_<nombre estructura> ew_makt
exporting
global
tabla ET_<nombre de la tabla> et_ekpo
exporting
global
parámetro MP_<nombre parámetro> mp_matnr
modify
global
estructura MW_<nombre estructura> mw_makt
modify
- 18 -
------------------------------------------------------------------------------------------------------------------------------------------------
global
tabla MT_<nombre de la tabla> mt_ekpo
modify
tables tabla T_<nombre de la tabla> t_datos
global
parámetro IP_<nombre parámetro> ip_matnr
importing
global
estructura IW_<nombre estructura> iw_makt
importing
global
tabla IT_<nombre de la tabla> it_ekpo
importing
global
clase IC_<nombre de la clase> ic_reloj
importing
global
parámetro EP_<nombre parámetro> ep_matnr
exporting
global
estructura EW_<nombre estructura> ew_makt
exporting
global
tabla ET_<nombre de la tabla> et_ekpo
exporting
global
PARÁMETROS DE clase EC_<nombre de la clase> ec_reloj
exporting
MÉTODOS DE
global
CLASES parámetro CP_<nombre parámetro> cp_matnr
changing
global
estructura CW_<nombre estructura> cw_makt
changing
global
tabla CT_<nombre de la tabla> ct_ekpo
changing
global
clase CC_<nombre de la clase> cc_reloj
changing
global
parámetro RP_<nombre parámetro> rp_matnr
returning
global
estructura RW_<nombre estructura> rw_makt
returning
global
tabla RT_<nombre de la tabla> rt_ekpo
returning
global
clase RC_<nombre de la clase> rc_reloj
returning
- 19 -
------------------------------------------------------------------------------------------------------------------------------------------------
9. RECOMENDACIONES GENERALES SOBRE FORMATO
En los puntos siguientes se detallan las normas generales que rigen para el formato del entorno de
desarrollo y que pueden formar parte de un programa ABAP.
9.1. Subrutinas (FORMS)
Las subrutinas internas en el programa ABAP deben utilizarse en los siguientes casos:
Para englobar partes de código compleja y extensa.

Para hacer más legible el programa y brindar una mayor facilidad de mantenimiento.
Para definir un proceso una sola vez en el programa, el cual es llamado desde diferentes lugares dentro
del mismo programa ABAP
Los FORMS deben respetar el siguiente formato:
La cantidad de líneas de código no debe tener más de una página de longitud en promedio.
Su nombre y el nombre de los parámetros deben respetar lo descrito anteriormente en la Convención
para nombres internos ABAP/4
Debe incluir comentarios sobre la funcionalidad principal y parámetros de entrada y salida.
9.2. Programas INCLUDE
Los programas INCLUDE (tipo “I” en sus atributos), pueden utilizarse en los siguientes casos:
Para estructurar programas con muchas líneas de código.

Para generar código re-utilizable en otros programas.
Para definir FORMS utilizables por otros programas (Ejemplo: Rutinas de programas BATCH-INPUT).
Si existe un gran número de declaración de data necesaria como parte del programa, debe separarse las
declaraciones dentro de un INCLUDE. El nombre del include debe ser el mismo del programa con el sufijo
TOP. Los siguientes includes deberán ser utilizados en los programas a implementarse.
Include Contiene
ZMSTNNNN_TOP Todas las declaraciones iniciales. Ejm: tablas, estructuras, variables, Type-Pools,
table Controls, etc. Adicionalmente se puede utilizar para la definición de los
métodos de una clase.
ZMSTNNNN_SEL Los parámetros de selección.
ZMSTNNNN_MAI El proceso principal y los eventos. Ejm: INITIALIZATION. START-OF-
SELECTION, AT SELECTION SCREEN, etc.
ZMSTNNNN_F01 Las subrutinas del programa.
ZMSTNNNN_O01 Process Before Output. Los modules output.
ZMSTNNNN_I01 Process After Input. Los modules input.
ZMSTNNNN_CLA La implementación de todos los métodos de una clase.
La codificación de INCLUDE debe respetar los convenios de nombres internos y estándares de

programación descritos en los puntos anteriores. Los nombres de los includes tienen como prefijo el nombre
del programa, cuya nomenclatura será tratada más adelante.
- 20 -
------------------------------------------------------------------------------------------------------------------------------------------------
9.3. Cabeceras de listados
Todos los programas ABAP desarrollados que emitan un reporte (Report List – WRITE), deben mantener el
siguiente formato de salida:
*-----------------------------------------------------------------------------------------------------------------------------------------------
XXXXXXXXXXXXXXXXXXXX (1) XXXXXXXXXXXXXXXXXXXXXXXXXX (2) 99/99/9999 (3)
XXXXXXXX (4) XXXXXXXXXXXXXXXX (5) Pag.: 9999 (6)
XXXXXXX (7) XXXXXXXXXXXXXXXXXX (7) XXXXXXXXX (7) XXXXXXXX (7)

*-----------------------------------------------------------------------------------------------------------------------------------------------
Donde:
(1) Nombre de la sociedad. Corresponde al campo T001-BUKRS.
(2) Título del reporte. Debe mostrarse en letra mayúscula.
(3) Fecha de emisión del reporte. Mostrar en formato DD/MM/AAAA.
(4) Nombre del reporte. Corresponde al campo de sistema SY-REPID.
(5) Subtítulo del listado. Es opcional y en caso de utilizarse debe ser mostrado en letra mayúscula.
(6) Número de página.
(7) Cabeceras de columnas. Mostrar en letras mayúsculas.
Estos campos en la cabecera del reporte deben figurar siempre, independientemente de si se utilizan los
títulos standard de los elementos de texto o si se los codifica manualmente mediante el evento TOP-OF-
PAGE.
9.4. Textos de selección
Los textos de selección correspondientes a los PARAMETERS y SELECT-OPTIONS declarados en el

programa deben ser incorporados en letra minúscula.
9.5. Símbolos de texto
Podrán utilizarse en letra minúscula o mayúscula dependiendo del lugar donde se mostrará, de acuerdo a
las normas que figuran en este documento. Deben ser utilizados en todas las sentencias WRITE, evitando
colocar en las mismas literales.
9.6. Pantallas
En el diseño de pantallas se debe tratar de mantener siempre los estándares de diseño empleados por
SAP, para ello, se debe respetar lo siguiente:
Todos los textos de los campos deben figurar en letras minúsculas.

Tratar de aprovechar las referencias a los campos del diccionario de datos.
Utilizar FRAMES para enmarcar campos relacionados.
Ubicar los campos de tal manera que facilite su llenado por parte del usuario
- 21 -
------------------------------------------------------------------------------------------------------------------------------------------------
9.7. Dynpros, Status y Títulos
Para la creación de cada uno de estos objetos, la nomenclatura a seguir será números correlativos de 4
dígitos con intervalos de 100 en 100, es decir, 0100, 0200, etc., guardando asociación entre los 3 objetos
mediante el mismo número de codificación.
Por ejemplo a la dynpro 0100 está asociada el status 0100 y el título 0100.
De darse el caso que dos dynpros estén reutilizando algún objeto en particular, se debe, mantener la
integración en código de los tres objetos, es decir,
Dynpro: 0100 -> Status: 0100 -> Título: 0100

Como se observa el Status 0200 no se ha tomado, en caso, a futuro la Dynpro 0200 necesite poseer su
propio status.
Elementos de Dynpros
Para el diseño de una dynpro es necesario el uso de elementos de dynpros, para los cuáles usaremos la
siguiente nomenclatura para los nombres de campo, dependiendo del elemento a utilizar:
Elemento Nomenclatura
Campo de Texto TF_<nombre campo texto>
Campo Entrada/Salida PF_<nombre campo entrada/salida>
CheckBox CB_<nombre CheckBox>
Radio Button RB_<nombre Radio Button>
PushButton PB_<nombre Push Button>
Marco GB_<nombre Marco>
Control de TabStrip SC_<nombre TabStrip>
Área SubScreen SA_<nombre Subscreen Area>
Table Control TC_<nombre Table Control>
Custom Control CC_<nombre Custom Control>
Status Icon SI_<nombre Status Icon>
Nota:
Como es conocido, estos elementos pueden ser obtenidos también vía referencia ya sea del Diccionario de
datos o también de las variables que posee el programa, en dicho caso el nombre del objeto cargado en la
dynpro se mantendrá con el nombre que se coloca automáticamente al jalar el objeto con la referencia
determinada. Además es posible indicar un nombre de campo precedido por un '*' cuando se trata de la
misma referencia al Diccionario de datos ABAP/4.
9.8. Status GUI
En su diseño debe tenerse en cuenta lo siguiente:
Utilizar hasta donde sea posible los defaults propuestos por SAP en lo que respecta a las funciones y
menús.
Los títulos de la superficie deben ser completados en minúscula y deben ser llamados igual que la
superficie.
En toda superficie debe asegurarse que figuren las funciones de BACK, CANCEL y EXIT
El texto de los pulsadores creados debe estar en letra minúscula.
- 22 -
------------------------------------------------------------------------------------------------------------------------------------------------
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 -
------------------------------------------------------------------------------------------------------------------------------------------------
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.
usar TYPE. Correcto:
DATA: GWA_KNA1 TYPE KNA1.
Incorrecto:
TYPES: GS_X,
Se debe de especificar la longitud de la variable que GP_Y TYPE P.
se está definiendo. Correcto:
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: <G_VALUE>.
no tiene un tipo de asignación. En ABAP objects la
Correcto:
adición type al field-symbols es obligatorio.
FIELD-SYMBOLS: <G_VALUE> 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.
Incorrecto:
LOOP AT GT_KNA1 INTO GWA_KNA1.
CLEAR GT_KNA1.
…..
Si utilizas work areas para hacer LOOP a la tabla
ENDLOOP.
interna, no está permitido hacer CLEAR dentro del
Correcto:
LOOP, ya que esta borraría todo el contenido de la
LOOP AT GT_KNA1 INTO GWA_KNA1.
tabla interna.
CLEAR GWA_KNA1.
…..
ENDLOOP.
CLEAR GT_KNA1.
Incorrecto:
INSERT TABLE GT_BKPF.
Las siguientes sentencias en relación con las tablas
COLLECT GT_BKPF.
internas están prohibidas ya que no está permitido
READ TABLE GT_BKPF…
trabajar directamente con la cabecera de la tabla
MODIFY TABLE GT_BKPF…
interna; por el contrario ahora se utilizan work areas
MODIFY GT_BKPF… WHERE …
o field-symbols.
DELETE TABLE GT_BKPF.
LOOP ATGT_BKPF…
- 24 -
------------------------------------------------------------------------------------------------------------------------------------------------
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 …
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
reutilización. CONSTANTS: gc_constante TYPE n LENGTH 4 VALUE 1234.
Además, demuestra desprolijidad en el diseño. DATA: gn_global TYPE n LENGTH 4, ...
IF wn_global NE gc_constante …..
Excepciones:
Programas de conversión que serán utilizados solo una vez.
Eventos
Correcto:
INITIALIZATION.
...
...
START-OF-SELECTION.
PERFORM cargar_datos.
Los eventos (END-OF-SELECTION, TOP-OF- PERFORM procesar_datos.
PAGE, etc.) deberán aparecer, en lo posible, en el PERFORM imprimir_datos.
código, en el orden en que serán utilizados. Si algún …
evento no estuviese siendo utilizado, deberá ser END-OF-SELECTION.
retirado. …
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 -
------------------------------------------------------------------------------------------------------------------------------------------------
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. Correcto:
PERFORM calcular_iva_factura.
*------------------------------------------------------*
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 Como las tres variables están relacionadas porque definen un nro. de asiento
estructura y no como variables “sueltas”. que se necesitar tratar en el programa:
- 26 -
------------------------------------------------------------------------------------------------------------------------------------------------
Esto permite simplificar el desarrollo al poder Incorrecto:
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 deberán ser
Correcto:
implementados vía MESSAGE IDs.
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 -
------------------------------------------------------------------------------------------------------------------------------------------------
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.

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 -
------------------------------------------------------------------------------------------------------------------------------------------------
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
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.
acceso a la Base de Datos. SELECT MSGNR FROM T100 INTO LWA-MSGNR
WHERE ARBGB EQ ‘00’
SELECT (para Transparent y Pool Tables): la IF LWA-MSGNR > l_msgnr_max.
cláusula WHERE debe contener, preferentemente, l_msgnr_max = LWA-MSGNR.
los campos claves y demás campos que puedan ENDIF.
restringir la consulta. ENDSELECT.
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
ENDSELECT. Es preferible realizar un SELECT FROM mard
INTO TABLE <tabla interna> y un LOOP AT <tabla INTO lt_stock_mat
interna> - ENDLOOP trabajando conjuntamente con WHERE matnr IN s_matnr.
el work área. Esto optimiza el acceso a la base de
datos y evita problemas de debugg en algunas IF lt_stock_mat-labst NE 0.
versiones de SAP R/3. En general, reduce el tiempo APPEND lt_stock_mat.
de procesamiento en los debugg. ELSE.
APPEND lt_stock_mat_nostock.
Evitar siempre reiterar el acceso a un mismo registro ENDIF.
en la base de datos, así sea con un select single. ENDSELECT.
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
búsqueda más rápida. FROM mard
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 -
------------------------------------------------------------------------------------------------------------------------------------------------
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 <lwa_facturas>.
READ TABLE lt_clientes INTO lwa_clientes
WITH KEY kunnr = <lwa_facturas>-kunnr.
IF sy-subrc EQ 0.
<lwa_facturas>-kunnr = lwa_clientes_aux-kunnr.
ENDIF.
ENDLOOP.
Performance memoria dinámica.
TABLAS INTERNAS
La manera más eficiente de buscar un único registro
en una tabla interna del tipo standard es utilizando el
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.
Incorrecto:
Siempre identificar si un SORT es ascending o
LOOP AT ITAB.
descending y especificar la cláusula BY <fields>.
CHECK T_ABC = KVAL.
Caso contrario todos los campos serán clasificados.
...
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 -
------------------------------------------------------------------------------------------------------------------------------------------------
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
campo. Correcto:
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.
Correcto:
SORT GT_TAB BY K.
DELETE ADJACENT DUPLICATES FROM GT_TAB COMPARING K.
Incorrecto:
LOOP AT GT_TAB.
Se debe evitar el LOOP para averiguar el número de LI_LINEAS = LI_LINEAS + 1.
registros de una tabla. ENDLOOP.
Correcto:
DESCRIBE TABLE GT_TAB LINES LI_LINEAS.
Correcto:
IF NOT GT_TAB1[] IS INITIAL.
Se deben evitar los SELECT anidados mientras dan SELECT FIELD1 FIELD2 FROM TABLE INTO TABLE GT_TAB2
lugar a un volumen grande de accesos de base de FOR ALL ENTRIES IN GT_TAB1
datos (dependientes en el tamaño de tablas).
En lugar de ello utilizar FOR ALL ENTRES. 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.
En ocasiones tenemos tablas internas muy pesadas
ENDLOOP.
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 -
------------------------------------------------------------------------------------------------------------------------------------------------
10.3. Modularización y reutilización
Modularización
Los programas deben estar

modularizados completamente.
Esto significa que el programa principal

consistirá de una serie de subrutinas
(módulos), las cuales resumirán los
procesos principales del programa.
Correcto:
START-OF-SELECTION.
A su vez, cada, subrutina, se dividirá en
PERFORM buscar_datos.
forma coherente y balanceada en nuevas
PERFORM calcular_porcentajes.
subrutinas, que dividirán nuevamente el
PERFORM grabar_log.
módulo en subprocesos. Y así
sucesivamente.
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 -
------------------------------------------------------------------------------------------------------------------------------------------------
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 -
------------------------------------------------------------------------------------------------------------------------------------------------
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 -
------------------------------------------------------------------------------------------------------------------------------------------------
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 -
------------------------------------------------------------------------------------------------------------------------------------------------
11. NOMENCLATURA DE OBJETOS DE REPOSITORIO SAP
TRANSACCION
Los nombres de estos objetos tendrán la siguiente forma Z[MS][T][NNN]
Donde:
Z : Por definición SAP
MS : Módulo SAP (Ver tabla 1)
T : Tipo de Programa (ver tabla 2)
NNN : Correlativo numérico
Nota:
El numeral [NNNN] debe ser el mismo en el nombre del programa y en la transacción (sin el 0 inicial), por lo
que será utilizado sólo una vez. Ejemplo, si el programa es ZMMR0023, la transacción respectiva es
ZMMR023.
Si se encontrara algún espacio en los correlativos de txs, utilizar dichos espacios para las nuevas txs a
crear. Ejm: Si en el sistema existe la tx ZFIP001, ZFIP003, ZFIP004..., utilizar el nombre ZFIP002 como
nueva tx a crear.
Transacción Copia Estándar
Las txs copias de un estándar deben evitarse y validarse con el Supervisor ABAP, en su lugar debe
buscarse la forma de ampliar la tx estándar. Sólo en caso aplicara y se aprobara la creación de la copia, los
nombres de estos objetos tendrán la siguiente forma Z[TX_ORI], donde TX_ORIG es el nombre de la tx
Original. Ejm: ZQA33.
PROGRAMA
Los nombres de estos objetos tendrán la siguiente forma Z[MS][T][NNNN]
Donde:
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.
- 36 -
------------------------------------------------------------------------------------------------------------------------------------------------
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:
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:
CE : Constante
Ejm: ZMMCE_RESERVAS01
ENHANCEMENT IMPLEMENTATION
Los nombres de estos objetos tendrán la siguiente forma Z[MS]EI_TTTT_[X…X]
Donde:
EI : Constante
TTTT : Código de transacción que se está ampliando
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
- 37 -
------------------------------------------------------------------------------------------------------------------------------------------------
TABLA
Los nombres de estos objetos tendrán la siguiente forma Z[MS]T_[X…X]
Donde:
T : Constante
X...X : Descripción literal
Ejm: ZCOT_MATCOSTO
Nota:
Se debe definir la Categoría de Ampliación antes de activar la tabla.

Para acceder: ingresar a la tabla en la Tx. SE11, ir al menú Detalles -> Categoría de Ampliación.
Por seguridad se debe asociar un grupo de autorización para toda tabla Z (Ver punto 4 del presente
Manual).
CAMPO DE TABLA
El nombre que llevarán los diferentes campos que conforman una tabla de base de datos, estará asignado
de la siguiente forma, dependiendo el caso en que se encuentre:
De ser un campo que hace referencia a un tipo de dato existente en SAP, se mantendrá el mismo
nombre de campo usado por la nomenclatura estándar de SAP.
Ejemplo: Sociedad -> BUKRS
De ser un campo creado según la situación del negocio o cliente, el nombre del campo estará asignado
por un nombre adecuado seleccionado bajo el criterio del consultor responsable, tomando un tamaño
recomendado de 5 caracteres.
Ejemplo:
Alimentos -> ALMTS.
Tienda de Textiles -> TDATL.
INDICE DE TABLA
Los índices que sean necesarios crear, para la optimización en el acceso de lectura a las tablas de bases
de datos tendrán la siguiente forma Z[NN]
Donde:
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”.
- 38 -
------------------------------------------------------------------------------------------------------------------------------------------------
VISTA
Los nombres de estos objetos tendrán la siguiente forma Z[MS]V_[X…X]
Donde:
V : Constante
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:
S : Constante
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:
TT : Constante
Ejm: ZMMTT_RESERVAS.
- 39 -
------------------------------------------------------------------------------------------------------------------------------------------------
ELEMENTO DE DATO
Los nombres de estos objetos tendrán la siguiente forma ZE_[X…X]
Donde:
E : Constante
Ejm: ZE_BANCO
DOMINIO
Los nombres de estos objetos tendrán la siguiente forma ZD_[CCCC][NNN][_D]
Donde:
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:
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
- 40 -
------------------------------------------------------------------------------------------------------------------------------------------------
AYUDA DE BÚSQUEDA
Los nombres de estos objetos tendrán la siguiente forma ZH_[X…X]
Donde:
H : Constante
Ejm: ZH_USERS
OBJETO DE BLOQUEO
Los nombres de estos objetos tendrán la siguiente EZ_[X...X]
Donde:
E : Prefijo Obligatorio 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:
SS : Constante
Ejm: ZSDSS_ADUANA
ESTILO (SAPSCRIPT)
Los nombres de estos objetos tendrán la siguiente forma ZST_[NNN]
Donde:
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:
SF : Constante
Ejm: ZSDSF_ADUANA
- 41 -
------------------------------------------------------------------------------------------------------------------------------------------------
ESTILO (SMARTFORM)
Los nombres de estos objetos tendrán la siguiente forma ZST_[X…X]
Donde:
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:
MT : Constante
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
GF : Constante
Ejm: ZHRGF_PERSONAL
Nota:
Los grupo de funciones correspondientes a la vista de actualización de una tabla o vista Z, deberán llevar el
mismo nombre que la tabla o vista relacionada.
Los field exits serán agrupados en un grupo de funciones único por módulo. El GF a tomar será
previamente coordinado con el Supervisor ABAP.
FUNCION
Los nombres de estos objetos tendrán la siguiente forma Z[MS]F_[X...X]
Donde:
F : Constante
Ejm: ZFIF_VERPAGOS
- 42 -
------------------------------------------------------------------------------------------------------------------------------------------------
RFC
Los nombres de estos objetos tendrán la siguiente forma Z[MS]RFC_[X…X]
Donde:
RFC : Constante
Ejm: ZSDRFC_TIPODOC
APLICACION BSP
Los nombres de estos objetos tendrán la siguiente forma Z[MS]BSP_[X...X]
Donde:
BSP : Constante
Ejm: ZMMBSP_LIBERA_OC
IMPLEMENTACION BADI
Los nombres de estos objetos tendrán la siguiente forma Z[X...X][N]
Donde:
X...X : Descripción literal, de preferencia nombre de definición
N : Opcional: correlativo numérico de 1 dígito
Ejm: ZME_PROCESS_PO_CUST.
CLASE E INTERFASE
La nomenclatura de una clase o de una interfase puede constar de caracteres alfanuméricos y del carácter
especial de subrayado (_) y de la barra (/). La barra (/) sirve para delimitar el prefijo del ámbito de nombres
del resto del denominador. La clase o interfase no puede empezar con una cifra.
Clase Z[MS]CL_[X…X]
Interfase Z[MS]IF_[X…X]
Donde:
CL/IF : Constante
- 43 -
------------------------------------------------------------------------------------------------------------------------------------------------
BUSINESS OBJECT
Los nombres de estos objetos tendrán la siguiente forma ZBO_[X…X]
Donde:
BO : Constante
Ejm: ZBO_CRM
ENTERPRISE SERVICE
Los nombres de estos objetos tendrán la siguiente forma Z[MS][WS_[X…X]
Donde:
WS : Constante
Ejm: ZSDWS_SCE_PEDIDOS
OBJETO DE AMPLIACION (CMOD)
Los nombres de estos objetos tendrán la siguiente forma Z[MS][NNN]
Donde:
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:
GU : Constante
Ejm: ZSDGU_VENTAS
- 44 -
------------------------------------------------------------------------------------------------------------------------------------------------
INFOSET (QUERY)
Los nombres de estos objetos tendrán la siguiente forma Z[MS]IS_[X...X]
Donde:
IS : Constante
Ejm: ZSDIS_DOC_VENTAS
QUERY
Los nombres de estos objetos tendrán la siguiente forma Z[MS]Q_[X...X]
Donde:
Q : Constante
Ejm: ZSDQ_ENTREGAS
PROYECTO (LSMW)
Los nombres de estos objetos tendrán la siguiente forma ZP_[X...X]
Donde:
P : Constante
Ejm: ZP_RANSA
SUB PROYECTO (LSMW)
Los nombres de estos objetos tendrán la siguiente forma Z[MS]SP_[X...X]
Donde:
SP : Constante
Ejm: ZMMSP_PEDIDOS
- 45 -
------------------------------------------------------------------------------------------------------------------------------------------------
OBJETO (LSMW)
Los nombres de estos objetos tendrán la siguiente forma Z[MS]O_[X...X]
Donde:
O : Constante
Ejm: ZMMO_ME21N_01
CLASE DE DESARROLLO
Los nombres de estos objetos tendrán la siguiente forma Z[MS]
Donde:
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:
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:
NN : Correlativo de 2 dígitos
Ejm: ZPP01
Nota:
Preferentemente usar una clase por módulo
- 46 -
------------------------------------------------------------------------------------------------------------------------------------------------
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:
NN : Correlativo numérico
Ejm: ZWM01
- 47 -
------------------------------------------------------------------------------------------------------------------------------------------------
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
- 48 -
------------------------------------------------------------------------------------------------------------------------------------------------
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 -
------------------------------------------------------------------------------------------------------------------------------------------------
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 -
------------------------------------------------------------------------------------------------------------------------------------------------
IMÁGENES
IMAGEN 10.4.a
- 53 -
------------------------------------------------------------------------------------------------------------------------------------------------
IMAGEN 10.4.b
IMAGEN 10.4.c
- 54 -

Estandares de Programacion Abap4 - Versio PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Estandares de Programacion Abap4 - Versio PDF

Cargado por

Copyright:

Formatos disponibles

ESTÁNDARES DE

Guía rápida de nomenclaturas

Control de Cambios del Documento

Preparado por: Verónica Briceño Vásquez Fecha de Preparación: 20.10.2014

2. Marca para modificaciones 06

5. Paquete - Clase de desarrollo 08

7. ESTRUCTURA PARA PROGRAMAS

8. Convención para nombres internos ABAP4/SAP 17

9. RECOMENDACIONES GENERALES SOBRE FORMATO

10. ASEGURAMIENTO DE CALIDAD EN DESARROLLOS ABAP

11. NOMENCLATURA DE OBJETOS DE REPOSITORIO SAP 36

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

<Tipo>-<Módulo> <Código Actividad> <Objeto Principal> <Descripción> <Versión> <Funcional>

Mód Cod. Actividad Actividad Cod.Tarea ID OD Descripción (Tarea) Funcional

Mód Cod. Actividad Actividad Cod.Tarea ID OD Descripción (Tarea) Funcional

WB-SD PYH_000049 ZSDR001 Reporte de Clientes 00 MV -> OT inicial

Mód Cod. Actividad Actividad Cod.Tarea ID OD Descripción (Tarea) Funcional

WB-WM PYP_000032 ZWMP001 Ubicación para traslados 00 ID -> OT inicial

Las marcas de modificación deben ser nombradas de acuerdo a la siguiente nomenclatura:

CASO1: Agregar varias líneas de código

FORM TEXTO_EXP USING PI_ASNUM.

DATA: LS_ASNUM TYPE ASMD-ASNUM,

CALL FUNCTION 'CONVERSION_EXIT_ALPHA_INPUT'

CALL FUNCTION 'READ_TEXT'

CASO3: Eliminar/Comentar varias líneas de código

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

5. Paquete - Clase de desarrollo

La asignación estará relacionada con el módulo SAP al que pertenece.

7.2. Cabecera del programa

La cabecera de un programa ABAP deberá respetar el siguiente formato:

7.3. Declaración de datos globales

La segunda sección del bloque se utilizará para la declaración de constantes.

Cada objeto adicionado debe comentarse.

7.4. Declaración de campos de pantalla

SELECTION-SCREEN BEGIN OF BLOCK B_02 WITH FRAME TITLE TEXT-B02.

PARAMETERS: P_ALV RADIOBUTTON GROUP G1 DEFAULT 'X',

Deben posicionarse los distintos PARAMETERS y SELECT-OPTIONS, de acuerdo a la posición en la que

Debe comentarse cada parámetro declarado.

7.5. Validación de campos de pantalla e inicialización

AT SELECTION-SCREEN ON VALUE-REQUEST FOR P_WAERS.

AT SELECTION-SCREEN ON BLOCK B_01.

7.6. Rutina principal del programa

El formato es el que se muestra a continuación:

GET BKPF LATE.

* Si no usas BDL incluir aquí métodos o subrutinas

7.8. Eventos de control

TOP-OF-PAGE DURING LINE-SELECTION.

En el encabezado de la sub-rutina debe comentarse la funcionalidad principal de la misma, así como

Se detalla a continuación la nomenclatura que debe respetarse en la codificación de programas ABAP. Se

global sin tipo gr_<nombre rango> gr_bukrs

RANGOS local sin tipo lr_<nombre rango> lr_bukrs

static sin tipo sr_<nombre rango> sr_bukrs

global sin tipo gc_<nombre constante> gc_edad_max

g<tipo>_<nombre del objeto <gs_matnr>

MACROS sin ámbito sin tipo <nombre macro> llena_fieldcat

global sin tipo gty_<nombre tipo> gty_mara

sin tipo gtyt_<nombre tipo tabla> gtyt_makt

estándar gtyd_<nombre tipo tabla> gtyd_makt