metodología sap estándares abap - forosap

ESTANDARES

DE

PROGRAMACION

ABAP/4

MANUALES Y TUTORIALES WWW.MUNDOSAP.COM

Página 2 de 21

Í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 3 de 21

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 4 de 21

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 5 de 21

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 6 de 21

3.3.2. Cabecera del programa La cabecera de un programa ABAP deberá respetar el siguiente formato: 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:

REPORT ZBCNORM1 MESSAGE-ID Z1 LINE-SIZE 132 LINE-COUNT 65 NO STANDARD PAGE HEADING. *================================================== ===================== * TITULO DEL PROGRAMA * * DESCRIPCION: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxx * xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxx * xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxx * * ANALISTA : xxxxxxxxxxxxxx (Empresa) * PROGRAMADOR: xxxxxxxxxxxxxx (Empresa) * *-------------------------------------------------- -------------------- * LOG DE MODIFICACION: * FECHA PROGRAMADOR CORRECCION DESCRIPCION * ddmmmaaaa xxxxxxxxxxxxxx C11K906167 xxxx xxxxxxxxxxxxxxxxxxxx * (14DIC2004) xxxx xxxxxxxxxxxxxxxxxxxx * xxxx xxxxxxxxxxxxxxxxxxxx * * FECHA PROGRAMADOR CORRECCION DESCRIPCION * ddmmmaaaa xxxxxxxxxxxxxx C11K906200 xxxx xxxxxxxxxxxxxxxxxxxx * (14DIC2008) xxxx xxxxxxxxxxxxxxxxxxxx * xxxx xxxxxxxxxxxxxxxxxxxx *-------------------------------------------------------------------------------------------------------------------------------


Página 7 de 21

*-------------------------------------------------- --------------------* * DECLARACION DE TABLAS * *-------------------------------------------------- --------------------* TABLES: T001, "Sociedades BKPF, "Cabecera de docume nto para Contabilidad BSEG. "Segmento de docume nto de Contabilidad *-------------------------------------------------- --------------------* * DECLARACION DE VARIABLES * * Utilizar esta seccion para declaracion de variab les elementales, * estructuras y tablas internas ( de lo mas simple a lo mas complejo) *-------------------------------------------------- --------------------* * Campos globales DATA: G_CAMPO1 LIKE T001-BUKRS, "Adicionar c omentario G_CAMPO2(3), "Adicionar c omentario G_CAMPO3 TYPE N, "Adicionar c omentario G_CAMPO4 LIKE BKPF-BUDAT. "Adicionar c omentario * Estructuras DATA: BEGIN OF E_XXXXXX, BUKRS LIKE BKPF-BUKRS, "Sociedad BELNR LIKE BSEG-BELNR, "Fecha de con tabilizacion END OF E_XXXXXX. DATA: BEGIN OF E_BKPF. INCLUDE STRUCTURE BKPF. "Agregar come ntario 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 con tabilizacion END OF T_XXXXXX. DATA: BEGIN OF T_BKPF OCCURS 100. INCLUDE STRUCTURE BKPF. "Agregar come ntario DATA: END OF T_BKPF. * Rangos RANGES: R_BUKRS FOR BKPF-BUDAT. "Rango de soc iedades * Field symbols FIELD-SYMBOLS: <FS_001>, <FS_002>. * Fields groups FIELD-GROUPS: HEADER, "Agregar comentario FG_DETALLE. "Agregar comentario


Página 8 de 21

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 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 to das las sentencias * que permitan mostrar campos en la pantalla de sel ección. * Las mismas deben respetar los grupos de bloques y el sangrado * No deben hacerse programas de este tipo sin al me nos un parámetro de * entrada. SELECTION-SCREEN BEGIN OF BLOCK BLK01 WITH FRAME TI TLE 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.


Página 9 de 21

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

que se desea aparezcan en la pantalla.

• 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 inicializ ació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: 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.

*-------------------------------------------------- --------------------* * INICIALIZACION *-------------------------------------------------- --------------------* INITIALIZATION. PERFORM F_INICIALIZACION_NN.

*-------------------------------------------------- --------------------* * VALIDACION DE PARAMETROS DE PANTALLA *-------------------------------------------------- --------------------* * En esta sección del programa deben codificarse to das las validaciones * de los campos de la pantalla AT SELECTION-SCREEN ON BLOCK BLK01. AT SELECTION-SCREEN ON P_KUNNR.


Página 10 de 21

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. El formato es el que se muestra a continuación: 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.

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

*-------------------------------------------------- --------------------* * LECTURAS DE BASES DE DATOS * BDL: Base de datos logica utilizada - Nr o.pantalla *-------------------------------------------------- --------------------* START-OF-SELECTION. * Realizar aquí todos los procesos necesarios para recuperar la * informacion de las bases de datos, ya sea utiliza ndo una BDL o no. * Tratar de agupar codigo en subrutinas. * La información debe tratar de almacenarse en tabl as internas GET BKPF. GET BSEG. GET BKPF LATE. MOVE-CORRESPONDING BKPF TO T_XXXXXX. MOVE-CORRESPONDING BSEG TO T_XXXXXX. APPEND T_XXXXXX.


Página 11 de 21

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. El formato es el que se muestra a continuación:

*-------------------------------------------------- --------------------* * FIN DE SELECCION DE DATOS *-------------------------------------------------- --------------------* END-OF-SELECTION. * Debe verificarse que la búsqueda de la informació n en las * bases de datos fue exitosa. Si esto no fuera así, deberá terminarse * el programa enviando un mensaje de aviso al usuar io, para que revise * la selección efectuada 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 pro ceso referida a * la generación de la salida, ya sea un reporte, un call transaction o * o alguna otra funcionalidad. * Debe tratar de agruparse el código en subrutinas. PERFORM F_SUBRUTINA USING G_CAMPO1 G_CAMPO2. PERFORM F_LISTA.

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


Página 12 de 21

Donde: • No es necesaria la codificación de la totalidad de los eventos sino solamente los estrictamente

necesarios.

• No tienen un orden establecido.

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. El formato es el que se muestra a continuación:

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.

*-------------------------------------------------- --------------------* * SUBRUTINAS INTERNAS *-------------------------------------------------- --------------------* *&------------------------------------------------- --------------------* *& Form F_INICIALIZACION_NN *&------------------------------------------------- --------------------* * Documentar en esta parte la funcionalidad d e 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 subr utina * *-------------------------------------------------- --------------------* * --> p1 documentar parametros de entrada * <-- p2 documentar parametros de salida *-------------------------------------------------- --------------------* FORM F_SUBRUTINA USING U_PAR1 U_PAR2. DATA: L_CAMPO1 TYPE D. "Adicionar com entario ENDFORM. " F_SUBRUTINA


Página 13 de 21

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

OBJETO LG.MAX. POSICION VALOR Variables globales 10 1-2

3-10 G_ Libre

Variables locales 10 1-2 3-10

L_ Libre

Tablas Internas 10 1-2 3-10

T_ Libre

Estructuras 10 1-2 3-10

E_ Libre

Rangos 8 1-2 3-8

R_ Libre

Field Symbols 8 1-3 4-8

FS_ Libre

Fields Groups 10 1-3 4-10

FG_ Libre

Select-options 8 1-2 3-8

S_ Libre

Parameters 8 1-2 3-8

P_ Libre

Forms Libre 1-2 3-n

F_ Libre

Parámetros actuales 8 1-2 3-8

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


Página 14 de 21

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

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:

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.

*-------------------------------------------------- ---------------------XXXXXXXXXXXXXXXXXXXX (1) XXXXXXXXXXXXXXXXXXXXXXXXXX (2) 99/99/9999 (3) XXXXXXXX (4) XXXXXXXXXXXXXXXX (5 ) Pag.: 9999 (6) XXXXXXX (7) XXXXXXXXXXXXXXXXXX (7) XXXXXXXXX (7) XXXXXXXX (7) *-------------------------------------------------- ---------------------*


Página 15 de 21

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

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.


Página 16 de 21

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

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.

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:

*-------------------------------------------------- -------------------- * LOG DE MODIFICACION: * FECHA PROGRAMADOR CORRECCION DESCRIPCION * ddmmmaaaa xxxxxxxxxxxxxx C11K906167 xxxx xxxxxxxxxxxxxxxxxxxx * (14DIC2004) xxxx xxxxxxxxxxxxxxxxxxxx * xxxx xxxxxxxxxxxxxxxxxxxx * * FECHA PROGRAMADOR CORRECCION DESCRIPCION * ddmmmaaaa xxxxxxxxxxxxxx C11K906200 xxxx xxxxxxxxxxxxxxxxxxxx * (14DIC2008) xxxx xxxxxxxxxxxxxxxxxxxx * xxxx xxxxxxxxxxxxxxxxxxxx *-------------------------------------------------------------------------------------------------------------------------------

DESCRIBE TABLE T_XXXXXX LINES SY-INDEX. IF SY-INDEX IS INITIAL. *-------------------------------------------------- -------------------- * BEGIN OF APLICATION NOTE SAP NRO. 6140808 DD/M M/AAAA * REPAIR NUMBER: R01K907858 BY José Peréz *-------------------------------------------------- -------------------- * MESSAGE S001(Z1). “ De lete * EXIT. “ Delete MESSAGE E030(Z1). “ Insert *-------------------------------------------------- -------------------- * END OF APLICATION NOTE SAP NRO. 6140808 *-------------------------------------------------- -------------------- ENDIF.


Página 17 de 21

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.

• Las líneas insertadas deben llevar el comentario: “INSERT


Página 18 de 21

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. Z Por definición SAP 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: Z Por definición SAP 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: Z Por definición SAP A Descripción de la aplicación NN Secuencia numérica.


Página 19 de 21

MENÚES: Los menús se codificaran de la siguiente forma ZAMN donde:

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


Página 20 de 21

IN INCLUDE

Tabla 2. Aplicaciones Código Código

ampliado Descripción

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

T Transparentes E Estructuras P Pool C Cluster V Vistas M Match-code

Tabla 4. Tipo de Formato Código Descripción CHAR CARACTERES DATS FORMATO FECHA AAAAMMDD


Página 21 de 21

DEC CAMPO EMPAQUETADO CON COMA Y SIGNO

NUMC CARACTER SOLO NUMEROS QUAN CAMPO PARA CANTIDADES TIMS FORMATO HORA HHMMSS UNIT CLAVE DE UNIDADES PARA CAMPOS

QUAN FLTP CIFRA DE COMA FLOTANTE

Tabla 5. Tipo de Documento Código Descripción

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 COCINER OS QUE NO SON NECESARIOS PARA EL PRODUCTIVO, DEBEN SER CREADOS CO MO OBJETOS LOCALES (SIN ORDEN DE TRANSPORTE) Y EL NOMBRE DEBE EMPEZAR CON Y.

metodología sap estándares abap - forosap

Documents