Metodología SAP - Estándares ABAP

ESTANDARES
DE
PROGRAMACION
ABAP/4
443137933.doc LÍNEA DE NEGOCIO SAP
Estándares de Programación ABAP/4
Fecha: 21/10/aa
Índice
1. Alcances y Objetivos...................................................................................................................................... 3
2. Herramientas.................................................................................................................................................. 4
3. Estándares generales de programación........................................................................................................ 5
3.1. Convenios de nombres............................................................................................................................ 5
3.2. Atributos de Programa............................................................................................................................. 5
3.2.1. Título................................................................................................................................................ 5
3.2.2. Tipo.................................................................................................................................................. 5
3.2.3. Aplicación......................................................................................................................................... 5
3.3. Estructura para nuevos programas......................................................................................................... 5
3.3.1. Comentarios..................................................................................................................................... 5
3.3.2. Cabecera del programa.................................................................................................................... 6
3.3.3. Declaración de datos globales......................................................................................................... 6
3.3.4. Declaración de campos de pantalla................................................................................................. 8
3.3.5. Validación de campos de pantalla e inicialización............................................................................9
3.3.6. Rutina principal del programa........................................................................................................ 10
3.3.7. Tratamiento de los datos obtenidos...............................................................................................10
3.3.8. Eventos de control.......................................................................................................................... 11
3.3.9. Subrutinas internas........................................................................................................................ 12
3.4. Convención para nombres internos ABAP/4......................................................................................... 13
3.5. Recomendaciones generales sobre formato.........................................................................................13
3.5.1. Subrutinas ( FORMS ).................................................................................................................... 13
3.5.2. Programas INCLUDE..................................................................................................................... 14
3.5.3. Cabeceras de listados.................................................................................................................... 14
3.5.4. Textos de selección........................................................................................................................ 15
3.5.5. Símbolos de texto........................................................................................................................... 15
3.5.6. Pantallas........................................................................................................................................ 15
3.5.7. Status GUI...................................................................................................................................... 15
4. Modificación del Standard............................................................................................................................ 16
4.1. Modificación para adicionar funcionalidad............................................................................................. 16
4.2. Modificación por aplicación de notas SAP.............................................................................................16
ANEXO................................................................................................................................................................ 18
Página 2 de 21
Fecha: 21/10/aa
1. Alcances y Objetivos
Tiene como objetivo principal el de fijar normas en el desarrollo en ABAP/4 para que de esa manera, el
código sea legible y más fácil de mantener por cualquier desarrollador de Soluziona.
Este documento está destinado a cubrir la totalidad de los desarrollos efectuados.
Página 3 de 21
Fecha: 21/10/aa
2. Herramientas
Se recomienda la utilización del OBJECT BROWSER (3.0F) o REPOSITORY BROWSER (4.0) para
todo desarrollo a efectuarse en el sistema SAP R/3.
Página 4 de 21
Fecha: 21/10/aa
3. Estándares generales de programación
3.1. Convenios de nombres

Todos los programas y objetos propios desarrollados en SAP, deben seguir las normas establecidas en
el ANEXO “Nomenclatura de objetos” de este documento.
Todos los programas ABAP desarrollados, deben seguir lo definido en el punto Convención para
nombres internos ABAP/4 de este mismo documento
3.2. Atributos de Programa

Será obligatorio completar los atributos de programa que se detallan en los puntos siguientes. El resto
de los atributos solo se completarán en caso de ser necesarios.
3.2.1. Título
El título del programa deberá ser claro y conciso, de tal manera que no deje dudas cual es el objetivo
del programa.
Deberá completarse en letra minúscula, para mantener la ergonomía del sistema general
3.2.2. Tipo
Utilizar alguno de los tipos propuestos por SAP y que se corresponda con el desarrollo a efectuar.
3.2.3. Aplicación
Completar con ‘Z’, para el caso de programas desarrollados
3.3. Estructura para nuevos programas

Se detallan en los puntos siguientes las normas para la estructuración del código ABAP.
Esta estructura está referida solamente a los programas cuyo atributo de tipo está indicado con ‘1’ y
debe respetarse para la codificación del mismo, el mismo orden que sigue en este documento.
3.3.1. Comentarios
Todo programa desarrollado debe incluir comentarios con el propósito de facilitar a futuros
programadores una herramienta para comprender con mayor exactitud cual es la funció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.
Página 5 de 21
Fecha: 21/10/aa
3.3.2. Cabecera del programa
La cabecera de un programa ABAP deberá respetar el siguiente formato:
REPORT ZBCNORM1 MESSAGE-ID Z1

LINE-SIZE 132
LINE-COUNT 65
NO STANDARD PAGE HEADING.
*=======================================================================
* TITULO DEL PROGRAMA
*
* DESCRIPCION: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
* xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
* xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
*
* ANALISTA : xxxxxxxxxxxxxx (Empresa)
* PROGRAMADOR: xxxxxxxxxxxxxx (Empresa)
*
*----------------------------------------------------------------------
* LOG DE MODIFICACION:
* FECHA PROGRAMADOR CORRECCION DESCRIPCION
* ddmmmaaaa xxxxxxxxxxxxxx C11K906167 xxxxxxxxxxxxxxxxxxxxxxxx
* (14DIC2004) xxxxxxxxxxxxxxxxxxxxxxxx
* xxxxxxxxxxxxxxxxxxxxxxxx
*
*-------------------------------------------------------------------------------------------------------------------------------
Donde:
 Las primeras líneas del programa deben ser destinadas al nombre del programa, tamaño del
reporte de salida, clase de mensajes, etc. Se debe respetar el sangrado y el orden de cada
atributo de la sentencia REPORT.
 En el bloque siguiente se debe colocar el título del desarrollo en mayúsculas. Este debe ser claro,
conciso y dar una rápida idea de la funcionalidad del programa.
A continuación debe completarse en letra minúscula, un comentario lo más detallado posible de la
funcionalidad del programa, explicando el objetivo, principales validaciones, etc.
Por último, debe indicarse los responsables del desarrollo y la empresa a la que pertenecen
 Debe completarse también un bloque dentro de la misma sección donde se lleve un registro
detallado de las modificaciones que sufre el código en el transcurso del tiempo de la manera y
formato que se muestra en el ejemplo de arriba.
En este punto es muy importante mantener el número de orden de transporte tanto para la creación
del programa como para sus posibles posteriores modificaciones, ya que permitirá un mejor manejo
del sistema de versiones de SAP
3.3.3. Declaración de datos globales
Esta sección se debe utilizar para la declaración de todas las variables globales utilizadas en el
programa.
La declaración de datos debe respetar el siguiente formato:
Página 6 de 21
Fecha: 21/10/aa
*----------------------------------------------------------------------*
* DECLARACION DE TABLAS *
*----------------------------------------------------------------------*
TABLES:
T001, "Sociedades
BKPF, "Cabecera de documento para Contabilidad
BSEG. "Segmento de documento de Contabilidad
*----------------------------------------------------------------------*
* DECLARACION DE VARIABLES *
* Utilizar esta seccion para declaracion de variables elementales,
* estructuras y tablas internas ( de lo mas simple a lo mas complejo)
*----------------------------------------------------------------------*
* Campos globales
DATA: G_CAMPO1 LIKE T001-BUKRS, "Adicionar comentario
G_CAMPO2(3), "Adicionar comentario
G_CAMPO3 TYPE N, "Adicionar comentario
G_CAMPO4 LIKE BKPF-BUDAT. "Adicionar comentario
* Estructuras
DATA: BEGIN OF E_XXXXXX,
BUKRS LIKE BKPF-BUKRS, "Sociedad
BELNR LIKE BSEG-BELNR, "Fecha de contabilizacion
END OF E_XXXXXX.
DATA: BEGIN OF E_BKPF.

INCLUDE STRUCTURE BKPF. "Agregar comentario
DATA: END OF E_BKPF.
* Tablas internas
DATA: BEGIN OF T_XXXXXX OCCURS 10,
BUKRS LIKE BKPF-BUKRS, "Sociedad
BUDAT LIKE BKPF-BUDAT, "Fecha de contabilizacion
END OF T_XXXXXX.
DATA: BEGIN OF T_BKPF OCCURS 100.

INCLUDE STRUCTURE BKPF. "Agregar comentario
DATA: END OF T_BKPF.
* Rangos
RANGES: R_BUKRS FOR BKPF-BUDAT. "Rango de sociedades
* Field symbols
FIELD-SYMBOLS:
<FS_001>,
<FS_002>.
* Fields groups
FIELD-GROUPS: HEADER, "Agregar comentario
FG_DETALLE. "Agregar comentario
Donde:
Página 7 de 21
Fecha: 21/10/aa
 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 tabla
 La segunda 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.
 Debe tratarse en lo posible de definir las variables haciendo referencia a campos definidos en el
diccionario de datos, mediante la utilización del LIKE.
3.3.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 bajo ningún concepto 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 el/los campo/s 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:
*----------------------------------------------------------------------*
* DISEÑO PANTALLA DE SELECCION
*----------------------------------------------------------------------*
* En esta sección del programa deben codificarse todas las sentencias
* que permitan mostrar campos en la pantalla de selección.
* Las mismas deben respetar los grupos de bloques y el sangrado
* No deben hacerse programas de este tipo sin al menos un parámetro de
* entrada.
SELECTION-SCREEN BEGIN OF BLOCK BLK01 WITH FRAME TITLE TEXT-001.

SELECT-OPTIONS: S_BUKRS FOR BKPF-BUKRS
NO INTERVALS,
S_BLART FOR BKPF-BLART.
PARAMETERS: P_GJAHR
LIKE BKPF-GJAHR
OBLIGATORY,
P_MONAT LIKE BKPF-MONAT.
SELECTION-SCREEN END OF BLOCK BLK01.
PARAMETERS: P_KUNNR LIKE KNA1-KUNNR.
Donde:
 Deben posicionarse los distintos PARAMETERS y SELECT-OPTIONS, de acuerdo a la posición

que se desea aparezcan en la pantalla.
Página 8 de 21
Fecha: 21/10/aa
 Debe comentarse cada parámetro declarado.
 Este tipo de variables deben ser utilizadas para evitar los ‘HARD_CODES’
3.3.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 F_INICIALIZACION_NN.
*----------------------------------------------------------------------*
* VALIDACION DE PARAMETROS DE PANTALLA
*----------------------------------------------------------------------*
* En esta sección del programa deben codificarse todas las validaciones
* de los campos de la pantalla
AT SELECTION-SCREEN ON BLOCK BLK01.
AT SELECTION-SCREEN ON P_KUNNR.
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 según corresponda y los
mismos aparecerán sobre la pantalla de selección, posibilitando de esa manera que el usuario
corrija el error.
 Debe comentarse cada parámetro declarado.
 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 modularizar el
programa.
3.3.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.
Página 9 de 21
Fecha: 21/10/aa
*----------------------------------------------------------------------*
* LECTURAS DE BASES DE DATOS
* BDL: Base de datos logica utilizada - Nro.pantalla
*----------------------------------------------------------------------*
START-OF-SELECTION.
* Realizar aquí todos los procesos necesarios para recuperar la
* informacion de las bases de datos, ya sea utilizando una BDL o no.
* Tratar de agupar codigo en subrutinas.
* La información debe tratar de almacenarse en tablas internas
GET BKPF.
GET BSEG.
GET BKPF LATE.

MOVE-CORRESPONDING BKPF TO T_XXXXXX.
MOVE-CORRESPONDING BSEG TO T_XXXXXX.
APPEND T_XXXXXX.
Donde:
 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 y que
pantalla de selección 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.
*----------------------------------------------------------------------*
* FIN DE SELECCION DE DATOS
3.3.7. *----------------------------------------------------------------------*
Tratamiento de los datos obtenidos.
END-OF-SELECTION.
* Debe verificarse que la búsqueda de la información en las
Esta sección
* bases dedeldatos
programa
fuedebe ser utilizada
exitosa. para codificar
Si esto no fuera el tratamiento de los terminarse
así, deberá datos obtenidos en la
sección anterior.
* el programa enviando un mensaje de aviso al usuario, para que revise
* la selección efectuada
DESCRIBE TABLE T_XXXXXX LINES SY-INDEX.
IF SY-INDEX IS INITIAL.
MESSAGE S001(Z1).
EXIT.
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.
Página 10 de 21
PERFORM F_SUBRUTINA USING G_CAMPO1
G_CAMPO2.
PERFORM F_LISTA.
Fecha: 21/10/aa
Donde:
 La codificación en esta parte del programa siempre debe comenzar con el evento END-OF-
SELECTION.
 Luego debe validarse que la selección de datos ha sido exitosa. En ese caso se continúa con el
programa, caso contrario, se debe enviar un mensaje de tipo ‘S’, informándole al usuario que
verifique los datos ingresados en la pantalla de selección y dar por terminado el programa.
 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, FORMAT, etc.)
3.3.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.
*----------------------------------------------------------------------*
* EVENTOS DE CONTROL
*----------------------------------------------------------------------*
* No será necesario codificar todos los eventos en esta sección del
* programa sino solamente los necesarios.
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.
Página 11 de 21
Fecha: 21/10/aa
3.3.9. Subrutinas internas.
Es la última sección del programa. Deben codificarse en esta todas las subrutinas internas que son
llamadas en el programa.
*----------------------------------------------------------------------*
* SUBRUTINAS INTERNAS
*----------------------------------------------------------------------*
*&---------------------------------------------------------------------*
*& Form F_INICIALIZACION_NN
*&---------------------------------------------------------------------*
* Documentar en esta parte la funcionalidad de la *
* subrutina. *
*----------------------------------------------------------------------*
* --> p1 documentación de parametros
* <-- p2 Dcoumentacion de parametros
*----------------------------------------------------------------------*
FORM F_INICIALIZACION_NN.
ENDFORM. " F_INICIALIZACION_NN

*&---------------------------------------------------------------------*
*& Form F_SUBRUTINA
*&---------------------------------------------------------------------*
* Documentar aquí la funcionalidad de la subrutina *
*----------------------------------------------------------------------*
* --> p1 documentar parametros de entrada
* <-- p2 documentar parametros de salida
*----------------------------------------------------------------------*
FORM F_SUBRUTINA USING U_PAR1
U_PAR2.
DATA: L_CAMPO1 TYPE D. "Adicionar comentario
ENDFORM. " F_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 click 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.
3.4. Convención para nombres internos ABAP/4

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.: G_BUKRS
Página 12 de 21
Fecha: 21/10/aa
OBJETO LG.MAX. POSICION VALOR

Variables globales 10 1-2 G_
3-10 Libre
Variables locales 10 1-2 L_
3-10 Libre
Tablas Internas 10 1-2 T_
3-10 Libre
Estructuras 10 1-2 E_
3-10 Libre
Rangos 8 1-2 R_
3-8 Libre
Field Symbols 8 1-3 FS_
4-8 Libre
Fields Groups 10 1-3 FG_
4-10 Libre
Select-options 8 1-2 S_
3-8 Libre
Parameters 8 1-2 P_
3-8 Libre
Forms Libre 1-2 F_
3-n Libre
Parámetros actuales 8 1-2 U_
3-8 Libre
3.5. Recomendaciones generales sobre formato

En los puntos siguientes se detallan las normas generales que rigen para el formato de otros objetos
del entorno de desarrollo y que pueden formar parte de un programa ABAP.
3.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 descripto anteriormente en

Convención para nombres internos ABAP/4
 Debe incluir comentarios sobre su funcionalidad principal y parámetros de entrada y salida.
Página 13 de 21
Fecha: 21/10/aa
3.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 ).
La codificación de INCLUDE debe respetar los convenios de nombres internos y estándares de

programación descriptos en los puntos anteriores.
3.5.3. Cabeceras de listados.
Todos los programas ABAP desarrollados que emitan un reporte, 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.
Página 14 de 21
Fecha: 21/10/aa
3.5.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.
3.5.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.
3.5.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
3.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.
4. Modificación del Standard

Si bien las modificaciones al standard SAP se debe tratar de no realizarlas, puede ocurrir que se haga
necesaria su implementación. Los distintos motivos por los que se pueda modificar el estándar, se
detallan en los puntos siguientes.
Es necesario documentar siempre y en forma detallada cualquier cambio en programas standard.
Página 15 de 21
Fecha: 21/10/aa
4.1. Modificación para adicionar funcionalidad.

Antes de hacer cualquier alteración al código standard SAP debe establecerse un Proceso para el
cambio del Código fuente, consensuado con cada cliente y para requerir la aprobación de cada cambio.
De esta manera solo las reparaciones autorizadas se efectuarán en el estándar.
En la cabecera del programa debe completarse el LOG de modificación como se indica en el punto
Cabecera del programa de este mismo informe.
*----------------------------------------------------------------------
* LOG DE MODIFICACION:
*
*-------------------------------------------------------------------------------------------------------------------------------
4.2. Modificación por aplicación de notas SAP

Esta modificación al standard resulta de la aplicación de notas del OSS.
Debe respetarse el siguiente formato:
DESCRIBE TABLE T_XXXXXX LINES SY-INDEX.

IF SY-INDEX IS INITIAL.
*----------------------------------------------------------------------
* BEGIN OF APLICATION NOTE SAP NRO. 6140808 DD/MM/AAAA
* REPAIR NUMBER: R01K907858 BY José Peréz
*----------------------------------------------------------------------
* MESSAGE S001(Z1). “ Delete
* EXIT. “ Delete
MESSAGE E030(Z1). “ Insert
*----------------------------------------------------------------------
* END OF APLICATION NOTE SAP NRO. 6140808
*----------------------------------------------------------------------
ENDIF.
Donde:
 Cada reparación por aplicación de nota SAP debe respetar exactamente los cambios que se
detallan en la misma.
 Cada reparación efectuada debe estar acotada por un texto de cabecera y uno de fin el cual
contenga los datos de la nota aplicada, la fecha de aplicación, el número de reparación propuesto
por el sistema de transporte ( WORKBENCH ), y el responsable de la modificación.
 No deben borrarse líneas de código del estándar . Aquellas que la nota de SAP proponga borrar,
deben ser comentadas mediante un asterisco e incluir el comentario : “DELETE.
Página 16 de 21
Fecha: 21/10/aa
 Las líneas insertadas deben llevar el comentario: “INSERT
Página 17 de 21
Fecha: 21/10/aa
ANEXO
NOMENCLATURA STANDARD DE OBJETOS
PROGRAMAS:
Los nombres de los programas se dividen en cuatro partes de la siguiente forma

ZPPAAXXX donde:
Z Por definición SAP
PP Describe el tipo de programa(ver tabla 1)
AA Describe la aplicación (ver tabla 2)
XXX Secuencia numérica.
TABLAS:
Los nombres de las tablas se dividen en cuatro partes de la siguiente forma
ZTANNNNN donde.
T Tipo de tabla (ver tabla 3)
A Describe la aplicación (ver tabla 2)
NNNNN Descripción literal
CAMPOS:
Los nombres de los campos dentro de las tablas serán de largo variable y
descripción literal alfabética.
ELEMENTOS DE DATOS:
Para los nombres de estos objetos se deberá anteponer al nombre del campo una
letra Z .
DOMINIOS:
Los nombres de los dominios se dividirán de la siguiente forma ZCCCCNNT

donde:
CCCC Tipo de formato del campo (ver tabla 4)
NN Longitud del campo
T Valor fijo para determinar si tiene tabla de valores
TRANSACCIONES:
Los códigos de transacción se deberán codificar de la siguiente forma ZANN
donde:
A Descripción de la aplicación
NN Secuencia numérica.
Página 18 de 21
Fecha: 21/10/aa
MENÚES:
Los menús se codificaran de la siguiente forma ZAMN
donde:

A Descripción de la aplicación
M Valor fijo que describe que es un menú
N Secuencia numérica
FORMULARIOS:
Los nombres de estos objetos se codificaran como ZF_A_XXXXXXXX
donde:
F Valor fijo
A Aplicación (ver tabla 2)
X… DDescripciónliteral
FUNCIONES:
Los nombres de las funciones deberán codificarse de la siguiente forma
ZAA_XX...X. Donde
Z Por definición de SAP
AA Aplicación (ver tabla 2)
X...X Descripción literal referente
DOCUMENTOS:
Los documentos Word que se creen para documentar el desarrollo deberán respetar la
nomenclatura siguiente: ZAA_CCNN
donde:
AA Aplicación
CC Tipo de documentación
NN Secuencia numérica
TABLAS DE PARAMETROS
Tabla 1. Tipo de Programas
Código Descripción
BI BATCH INPUT
CI CARGA INICIAL
DI DIALOGO
RP REPORTE
BT PROCESO BATCH
RI REPORTE INTERACTIVO
IN INCLUDE
Página 19 de 21
Fecha: 21/10/aa
Tabla 2. Aplicaciones
Código Código Descripción

ampliado
L AP Cuentas a pagar
K AR Cuentas a cobrar
C CO Controlling
J CCA Cost. Center Acc
W PC Product Costing
G GL Contabilidad general
A AM Activos Fijos
B BC Sistema Básico
S LC Consolidación
F TR Tesorería
M MM Gestión de materiales
Z R3 General de proyectos
V SD Ventas y Distribución
X GX Cont. General extendida
O OR Ordenes internas CO
D DP Documentación de proced.
I PM Mantenimiento de planta
Q QM Gestión de Calidad
E SM Gestión de Servicios
Y PS Gestión de Proyectos
H HR Recursos Humanos
P PP Production Planing
T Extranet
Tabla 3. Tipo de Tablas
T Transparentes
E Estructuras
P Pool
C Cluster
V Vistas
M Match-code
Tabla 4. Tipo de Formato
Código
Descripción
CHAR CARACTERES
DATSFORMATO FECHA AAAAMMDD
DEC CAMPO EMPAQUETADO CON COMA Y
SIGNO
NUMC CARACTER SOLO NUMEROS
QUAN CAMPO PARA CANTIDADES
Página 20 de 21
Fecha: 21/10/aa
TIMS FORMATO HORA HHMMSS

UNIT CLAVE DE UNIDADES PARA CAMPOS
QUAN
FLTP CIFRA DE COMA FLOTANTE
Tabla 5. Tipo de Documento
DC PROCESOS SEGUN SAP
DD DOCUMENTACION DESARROLLOS
GC MANUAL DE PARAMETRIZACION
GU MANUAL DEL USUARIO
MS MODIFICACIONES AL ESTANDAR
TD ELEMENTOS DEL DICCIONARIO
OM OBJETOS DE MATCHCODE
TX TRANSACCIONES
IN INTERFASES
TS PRUEBAS
AV INFORMES DE AVANCE
LOS OBJETOS CREADOS PARA PRUEBAS O PROCESOS COCINEROS QUE NO SON

NECESARIOS PARA EL PRODUCTIVO, DEBEN SER CREADOS COMO OBJETOS LOCALES
(SIN ORDEN DE TRANSPORTE) Y EL NOMBRE DEBE EMPEZAR CON Y.
Página 21 de 21

Metodología SAP - Estándares ABAP

Cargado por

Copyright:

Formatos disponibles

Metodología SAP - Estándares ABAP

Cargado por

Información del documento

Descripción 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

Metodología SAP - Estándares ABAP

Cargado por

Copyright:

Formatos disponibles

ESTANDARES

Este documento está destinado a cubrir la totalidad de los desarrollos efectuados.

3. Estándares generales de programación

3.1. Convenios de nombres

3.2. Atributos de Programa

Completar con ‘Z’, para el caso de programas desarrollados

3.3. Estructura para nuevos programas

3.3.2. Cabecera del programa

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

REPORT ZBCNORM1 MESSAGE-ID Z1

3.3.3. Declaración de datos globales

DATA: BEGIN OF E_BKPF.

DATA: BEGIN OF T_BKPF OCCURS 100.

3.3.4. Declaración de campos de pantalla.

La declaración de parámetros de pantalla debe respetar el siguiente formato:

SELECTION-SCREEN BEGIN OF BLOCK BLK01 WITH FRAME TITLE TEXT-001.

PARAMETERS: P_KUNNR LIKE KNA1-KUNNR.

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

 Debe comentarse cada parámetro declarado.

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

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

AT SELECTION-SCREEN ON BLOCK BLK01.

 Debe comentarse cada parámetro declarado.

3.3.6. Rutina principal del programa.

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

GET BKPF LATE.

* en esta sección debe codificarse la parte del proceso referida a

3.3.8. Eventos de control.

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

 No es necesaria la codificación de la totalidad de los eventos sino solamente los estrictamente

 No tienen un orden establecido.

3.3.9. Subrutinas internas.

ENDFORM. " F_INICIALIZACION_NN

DATA: L_CAMPO1 TYPE D. "Adicionar comentario

ENDFORM. " F_SUBRUTINA

 Debe respetarse el formato mostrado en el ejemplo de arriba. Este formato se obtiene

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

3.4. Convención para nombres internos ABAP/4

OBJETO LG.MAX. POSICION VALOR

3.5. Recomendaciones generales sobre formato

3.5.1. Subrutinas ( FORMS )

 Para englobar partes de código compleja y extensa.

Los FORMS deben respetar el siguiente formato:

 Su nombre y el nombre de los parámetros deben respetar lo descripto anteriormente en

 Debe incluir comentarios sobre su funcionalidad principal y parámetros de entrada y salida.

3.5.2. Programas INCLUDE

 Para estructurar programas con muchas líneas de código.

 Para generar código re-utilizable en otros programas.

La codificación de INCLUDE debe respetar los convenios de nombres internos y estándares de

3.5.3. Cabeceras de listados.

XXXXXXX (7) XXXXXXXXXXXXXXXXXX (7) XXXXXXXXX (7) XXXXXXXX (7)

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

(6) Número de página.

(7) Cabeceras de columnas. Mostrar en letras mayúsculas.

3.5.4. Textos de selección

Los textos de selección correspondientes a los PARAMETERS y SELECT-OPTIONS declarados en el