Manual de Padronização Desenvolvimento Abap - v07

PADRÕES DE
DESENVOLVIMENTO
ABAP
 Este material é de propriedade intelectual da Procwork.
Manual de Padronização Desenvolvimento Abap.doc Página 1 de 48

ÍNDICE
1. INTRODUÇÃO..............................................................................................................................4
2. IDENTIFICAÇÃO DO OBJETO.................................................................................................5
2.1. HEADER....................................................................................................................................5
3. COMENTÁRIOS...........................................................................................................................7
3.1. PONTOS CHAVES..................................................................................................................7
3.2. SITUAÇÕES.............................................................................................................................8
3.3. FORMA......................................................................................................................................8
4. ORGANIZAÇÃO DOS CÓDIGOS FONTES..........................................................................14
4.1. HIERARQUIA DE DECLARAÇÕES...................................................................................14
4.2. IDENTAÇÃO, ALINHAMENTO E ESPAÇAMENTO........................................................15
5. NOMENCLATURA.....................................................................................................................17
5.1. VARIÁVEIS.............................................................................................................................18
5.2. IDENTIFICAÇÃO DA APLICAÇÃO.....................................................................................20
5.3. OBJETOS DE PROGRAMA................................................................................................21
5.3.1. PROGRAMA...........................................................................................................................21
5.3.2. VARIANTE..............................................................................................................................22
5.3.3. CAMPO GLOBAL..................................................................................................................22
5.3.4. EVENTO..................................................................................................................................23
5.3.5. SUB-PROGRAMA (Forms)..................................................................................................23
5.3.6. MACRO...................................................................................................................................24
5.3.7. TELA........................................................................................................................................24
5.3.8. STATUS GUI..........................................................................................................................24
5.3.9. TÍTULO GUI............................................................................................................................25
5.3.10. INCLUDE..............................................................................................................................25
5.3.12. MÓDULO DE DIÁLOGO...................................................................................................27
5.4. OBJETOS DO DICIONÁRIO................................................................................................27
5.5. OBJETOS DE GRUPO DE FUNÇÃO................................................................................29
5.6. OBJETOS PRIVADOS LOCAIS..........................................................................................30
5.7. OUTROS OBJETOS.............................................................................................................30
5.7.1. CLASSE DE DESENVOLVIMENTO OU PACOTE..........................................................31
5.7.2. BANCO DE DADOS LÓGICO.............................................................................................32
5.7.3. ID PARÂMETRO SET/GET.................................................................................................32
5.7.4. MENU DE ÁREA....................................................................................................................33
5.7.5. CLASSE DE MENSAGEM.............................................................................................33
5.7.6. NÚMERO DE MENSAGEM...........................................................................................34
5.7.7. AUTHORITY-CHECK.....................................................................................................34
5.7.8. PF-STATUS......................................................................................................................34
5.7.9. TITLEBAR.........................................................................................................................35
5.7.10. MEMORY-ID.....................................................................................................................35
5.7.11. BATCH INPUT (Pastas)....................................................................................................35
5.8. BUSINESS ENGINEERING.................................................................................................36
5.8.1. MODELO DE DADOS...........................................................................................................36
5.8.2. TIPO DE ENTIDADE.............................................................................................................37
5.8.3. CATEGORIA DE OBJETO BUSINESS.............................................................................37
6. LAY-OUT.....................................................................................................................................38
6.1. LAY-OUT DE TELA...............................................................................................................38
6.2. LAY-OUT DE SAIDA (RELATÓRIO)......................................................................................38
7. NORMAS DE PROGRAMAÇÃO.............................................................................................39
7.1. TABELAS INTERNAS...........................................................................................................39
7.2. PARÂMETROS DE SELEÇÃO............................................................................................39
7.3. DECLARAÇÃO DE VARIÁVEIS..........................................................................................41

7.4. DECLARAÇÃO DE EVENTOS............................................................................................41
7.5. DECLARAÇÃO DE SUBROTINAS (FORMS)...................................................................41
7.6. CÁLCULOS.............................................................................................................................41
7.7. COMANDO MOVE-CORRESPONDING...........................................................................42
7.8. COMANDO DESCRIBE........................................................................................................42
7.9. COMANDO CASE.................................................................................................................42
7.10. COMANDO LOOP.................................................................................................................42
7.11. COMANDO WHILE................................................................................................................43
7.12. COMANDO SORT.................................................................................................................44
7.13. COMANDO SELECT.............................................................................................................44
7.14. COMANDO INTO TABLE.....................................................................................................45
7.15. COMANDO FREE..................................................................................................................45
7.16. ÍNDICE.....................................................................................................................................46
7.17. CÓDIGO MORTO..................................................................................................................46
7.18. COMANDO READ TABLE...................................................................................................46
7.19. TAMANHO PADRÃO DE COLUNAS (73 CARACTERES)............................................46
7.20. VERIFICAÇÃO EXTENDIDA DE SINTAXE......................................................................47
7.21. ANÁLISE DO TEMPO DE EXECUÇÃO.............................................................................47
7.22. CRIAÇÃO DE LITERAIS......................................................................................................47
7.23. PROGRAMAÇÃO PARA O MODULO DE HR (HUMAN RESOURCES).....................48
7.24. NOTAS OSS...........................................................................................................................49

1. INTRODUÇÃO
Esse documento tem como objetivo definir padrões de metodologia e

nomenclatura a serem utilizados nos desenvolvimentos de objetos ABAP no
sentido de obter um produto final com qualidade.
A aplicação das diretrizes contidas nesse documento é de
responsabilidade de cada consultor.
Serão fornecidos esclarecimentos, e modelos de documentos formais
necessários ao acompanhamento e documentação das atividades a serem
seguidas pela equipe.
Importante !
Nunca comece a desenvolver ou alterar um objeto sem antes ter em

mãos as seguintes informações:
 A Especificação Técnica;
 A Classe de Desenvolvimento (Pacote nas versões mais novas do SAP);
 A “Request”;
 A “Task”.

2. IDENTIFICAÇÃO DO OBJETO
A identificação de um objeto ABAP sempre envolverá um “Header”

padrão conteúdo informações como, nome do programa, transação, modulo
SAP utilizado, quem criou o objeto, entre outros dados. Tal “Header” deve estar
presente, ou seja, sempre que o objeto ABAP o permitir e na forma como será
apresentado nesse tópico. Em termos gerais, pode-se considerá-los como
parte integrante de todo código gerado, independendo do tipo do mesmo.
2.1. HEADER
Deverá estar localizado nas primeiras linhas do código fonte. Para

padronizar os desenvolvimentos o template deve ser deverá ser seguido à
risca, inclusive na ordem em que as informações são exibidas e nas ‘*’ e ‘-‘ que
aparecem nas linhas. Vide o exemplo abaixo de um “Header”:
*---------------------------------------------------------------------------
* Programa : ZPSDR_001
* Cliente :
* Módulo :
* Transação:
* Descrição: Programa de conversão de dados para
* o cadastro de materiais
* Autor : Codificador01 Data: dd/mm/aaaa
*---------------------------------------------------------------------------
* Histórico de Alterações:
*---------------------------------------------------------------------------
* Data |Change # |Autor |Alteração
*---------------------------------------------------------------------------
* dd/mm/aaaa |C01K9016 |Codificador01 |Desenvolvimento Inicial
* dd/mm/aaaa |C01K9020 |Codificador02 |Descrição da Alteração
*---------------------------------------------------------------------------

Observações:
 A linha de comentário é tracejada e não termina com asterisco (*), essa

regra deve valer para todos os códigos gerados sob a Metodologia da
Procwork;
 Não existe um número de linhas pré-definido para os itens Cliente, Módulo,

Transação, Descrição, procure apenas ser objetivo;
 Nas sentenças, tentar usar o máximo da linha disponível para o comentário,

simulando os espaçamentos necessários e seguindo as regras de
hifenização e acentuação.

3. COMENTÁRIOS
A padronização no que se refere aos comentários adicionados ao código

ABAP deve ser implementada de forma objetiva. Nesse tópico, será
apresentado os pontos, situações e a forma que o consultor deve basear-se no
momento de criar seus comentários.
O objetivo dos comentários é esclarecer a lógica de programação
utilizada em uma dada solução, com isto, caso seja necessário realizar
manutenção no programa, outros consultores conseguiram interpretar com
maior facilidade as regras de negócio existente.
O consultor deverá efetuar os seus comentários utilizando-se do seu
bom senso. Como sugestão use o ‘Princípio da Expectativa’, onde a
elaboração de certos comentários deverá basear-se na expectativa que o
próprio executor gostaria de encontrar, se o mesmo estivesse na posição de
‘entender’ o código que está sendo gerado.
3.1. PONTOS CHAVES
Entenda-se por comentário, toda e qualquer string que não faça parte
da linguagem ABAP, mas que caracterize ou identifique elementos da mesma,
bem como toda descrição referente aos “Forms” e as soluções encontradas e
empregadas na construção da lógica de programação.
Sendo assim, consideram-se como pontos chaves a serem comentados
e monitorados pelo Controle da Qualidade:
 Seções do Código: toda seção de declaração deverá apresentar a sua

correspondente identificação, o mesmo estendendo-se para as
‘Selection-Screens’;
 Data Dictionary Objects: todos os objetos independendo entre os
‘standard’ do sistema R/3 ou os que forem gerados de acordo com as
necessidades apontadas pela especificação técnica;

 Data: todas as declarações deverão estar devidamente comentadas ou
identificadas conforme o ‘data dictionary’, estendendo-se as declarações
envolvendo ‘Constants’ e ‘Parameters’;
 Types: todas as declarações deverão estar comentadas, principalmente

no que tange aos campos utilizados;
 BDC_Table: identificação dos campos e ações executadas pelos

elementos pertencentes a uma tela.
3.2. SITUAÇÕES
Esse tópico é estritamente ligado ao chamado ‘bom senso’ do consultor,

pois ele arbitrará em seu código quais os trechos que necessitam estar
comentado. É comum cada solução apresentar particularidades por esta razão
cada objeto criado poderá apresentar um grau maior ou menor de
detalhamento através dos comentários adicionados ao código ABAP.
Lembrar que um objeto devidamente comentado reduz o tempo e
aumenta a qualidade da documentação a ser apresentada a Área Técnica e/ou
cliente.
3.3. FORMA
Nesse tópico será apresentado exemplo de comentários que os

consultores devem utilizar em seus respectivos desenvolvimentos.
Observação: Caso precise eliminar temporariamente a ação de uma
linha, o uso do (*) é livre, mas se ao término do objeto, concluir-se que a
mesma não é mais necessária ao processamento, a mesma deverá ser
eliminada para não caracterizar uma ‘poluição visual’ e um aumento
desnecessário de linhas que não precisaram ser consideradas no
entendimento da lógica do objeto.

Declaração de comentários em Tabelas Transparentes
Declaração de tabelas do dicionário de dados que serão utilizadas em

um programa. Antes da declaração das tabelas transparentes é necessário
identificar a área com um cabeçalho padrão, e após as declarações de tais
tabelas é necessário incluir um comentário de meia linha contendo breve
descrição da tabela, vide o exemplo abaixo:
*-------------------------------------------------------------------------
* Tabelas do Dicionário de Dados
*-------------------------------------------------------------------------
TABLES: tabela. “ Breve descrição da tabela
Declaração de comentários em Constantes
Todo a literal fixa em um programa deve ser representada por meio de

uma constante (com exceção de comparação com o SY-SUBRC e cálculos
numéricos simples do tipo a = a + 1). Antes da declaração das constantes é
necessário identificar a área com um cabeçalho padrão, e após as declarações
de tais constantes é necessário incluir um comentário de meia linha contendo
breve descrição da mesma, vide o exemplo abaixo:
*-------------------------------------------------------------------------
* Definição de Constantes
*-------------------------------------------------------------------------
CONSTANTS: c_texto type c value ‘X’ . “ Descrição da constante.
Observações:
 Declarar usando o bom senso. Exemplo: Tipo de movimento 101. Ao invez

de colocar C_101, coloque C_XXX, onde XXX é a descrição que mais se
aproxima do objetivo/propósito da constante, como: C_ENTRADA já que o
movimento 101 sempre denota uma entrada.
 Para constantes genéricas não é necessário colocar a descrição na frente.
Exemplos: ‘X’, ‘.’, ‘;’, ‘)’, ‘(‘ e assim por diante.

Declaração de comentários em Tipos
É recomendável (por questões de organização de código) que toda

declaração de tabela interna utilize um TYPE. Antes da declaração dos tipos é
necessário identificar a área com um cabeçalho padrão, e após as declarações
é necessário criar um comentário inicial (utilizar *) para indicar a finalidade do
tipo e cada campo deste tipo deve possuir um comentário de meia linha
contendo breve descrição do campo, vide o exemplo abaixo:

*-------------------------------------------------------------------------
* Definição de Tipos
*-------------------------------------------------------------------------
TYPES:
*** Descrição da finalidade do tipo

BEGIN OF mara_type,
matnr type mara-matnr, “ Descrição do campo
END OF mara_type.
Declaração de comentários em Tabelas Internas
Deve ser utilizado um cabeçalho padrão para identificar a área de

criação de tabelas interna e após a declaração das mesmas incluir um
comentário (utilizar *) contendo breve descrição destes objetos, vide o exemplo
abaixo:
*-------------------------------------------------------------------------
* Definição de Tabelas Internas
*-------------------------------------------------------------------------
DATA:
*** Descrição da utilização da tabela interna

gw_mara type standard table of mara_type.
Declaração de comentários em Estruturas

criação de estruturas e após a declaração das mesmas incluir um comentário
(utilizar *) contendo breve descrição destes objetos, vide o exemplo abaixo:
*-------------------------------------------------------------------------
* Definição de Estruturas
*-------------------------------------------------------------------------
DATA:
*** Descrição da utilização da estrutura

gs_mara type mara_type.
Declaração de comentários em Field-Symbol

criação de field-symbol e após a declaração das mesmas incluir um comentário
(utilizar *) contendo breve descrição destes objetos, vide o exemplo abaixo:

*-------------------------------------------------------------------------
* Definição de Field-Symbol
*-------------------------------------------------------------------------
FIELD-SYMBOL:
*** Descrição da utilização do field-symbol

<mara> type mara_type.
Declaração de comentários em Variáveis

criação de variáveis e após a declaração das mesmas incluir um comentário de
meia linha contendo breve descrição destes objetos, vide o exemplo abaixo:
*-------------------------------------------------------------------------
* Definição de Variáveis
*-------------------------------------------------------------------------
DATA gn_var1 type n. “ Descrição da variável global
Declaração de comentários em Controls

criação de controls (tablecontrol) e após a declaração dos mesmos incluir um
comentário de meia linha contendo breve descrição destes objetos, vide o
exemplo abaixo:
*-------------------------------------------------------------------------
* Definição de Controls
*-------------------------------------------------------------------------
CONTROLS: tb_email type tableview using screen 9000. “ Descrição breve
Declaração de comentários em Macros

criação de macros e após a declaração dos mesmos incluir um comentário
contendo breve descrição destes objetos, vide o exemplo abaixo:
*-------------------------------------------------------------------------
* Definição de Macros
*-------------------------------------------------------------------------
*** Macro para realizar a tarefa XXXXX

DEFINE macro_nome.
...

Declaração de comentários Definições de Classes

definições de classes e após a declaração das mesmas incluir um comentário
contendo breve descrição destes objetos, vide o exemplo abaixo:
*-------------------------------------------------------------------------
* Class Definition
*-------------------------------------------------------------------------
*** Classe para realizar o processo XXXXX

CLASS xxxx DEFINITION.
...
ENDCLASS.
Declaração de comentários Implementações de Classes

implementações de classes e após a declaração das mesmas incluir um
comentário contendo breve descrição destes objetos, vide o exemplo abaixo:
*-------------------------------------------------------------------------
* Class Implementation
*-------------------------------------------------------------------------
*** Classe para realizar o processo XXXXX

CLASS xxxx IMPLEMENTATION.
...
ENDCLASS.
Declaração de comentários em Parameters e Select-options

criação de objetos de seleção e após a declaração dos mesmos incluir um
comentário de meia linha contendo breve descrição destes objetos, vide o
exemplo abaixo:
*-------------------------------------------------------------------------
* Definição da Tela de Seleções
*-------------------------------------------------------------------------
PARAMETERS p_param type c. “ Descrição do parâmetro

SELECT-OPTIONS s_name for mara-matnr. “ Descrição do campo
Declaração de comentários em Eventos

criação dos eventos que um programa venha a possuir (start-of-selection, end-
of-selection, por exemplo), vide o exemplo abaixo:
*-------------------------------------------------------------------------
* Evento: Start-of-Selection
*-------------------------------------------------------------------------
START-OF-SELECTION.
… (codificação).
Declaração de comentários em seqüências de comandos
Todas as seqüências de comandos devem ser comentadas por asterisco

(*) no início da linha precedendo o texto de comentário. Além disso, deve existir
uma linha em branco antecedendo o comentário. Vide o exemplo abaixo:
<linha em branco>
*** Lê as linhas do arquivo de ICMS
READ DATASET pc_file INTO gs_record.
Declaração de comentários em forms
Todo form a ser criado pelo consultor deve possuir um cabeçalho padrão
conforme o exemplo abaixo:
*&---------------------------------------------------------------------*
*& Form ZF_FORM
*&---------------------------------------------------------------------*
* Coloque aqui uma descrição de forma simples,clara e objetiva
*----------------------------------------------------------------------*
* -->P_PARAM_1 Descrição do parâmetro 1. Ex.: Nr. documento vendas
* <--P_PARAM_2 Descrição do parâmetro 2. Ex.: Tipo do documento
* -->P_TABELA Descrição da tabela. Ex.: Itens do doc. vendas
*----------------------------------------------------------------------*
Observação: tanto os parâmetros de entrada como os de saída devem

ser declarados contendo o texto fixo p_ seguido de uma string que identifique o
parâmetro.

4. ORGANIZAÇÃO DOS CÓDIGOS FONTES
Esse tópico e seus itens estão relacionados com a estruturação a ser

seguida pelo consultor na codificação dos objetos ABAP. Basicamente serão
abordados os seguintes assuntos:
 Hierarquia de declarações;
 Identação, alinhamento e espaçamento.
4.1. HIERARQUIA DE DECLARAÇÕES
Na estrutura de todo objeto ABAP que admita linhas de codificação,

será observada a hierarquia de declarações como segue logo mais abaixo.
Observar que a aplicação da hierarquia está vinculada a existência da
declaração dentro do objeto, caso a declaração não se aplique ao objeto a
mesma não deve estar referenciada na estrutura. A hierarquia a ser seguida
apresenta-se com a seguinte seqüência:
 Tables;
 Constants;
 Types;
 Internal tables;
 Field-Symbol;
 Data;
 Controls;
 Macros;
 Class Definition;
 Class Implementation;
 Parameters;
 Selection screens;
 Main program;
 Events;

 Procedures (forms).
No caso de procedures (Forms) e class implementation a hierarquia de

declarações que se faça necessária deve seguir como acima ilustrado.
4.2. IDENTAÇÃO, ALINHAMENTO E ESPAÇAMENTO
As regras principais a serem observadas pelo consultor referem-se a

forma de apresentar as instruções no código do objeto. O primeiro contato com
um código é o visual, seguido do analítico. No primeiro contato transmite-se ao
cliente a qualidade do(s) serviço(s) prestados, a experiência tem mostrado
quanto um código ‘bem escrito’ é apreciado e esperado, por parte do corpo
técnico dos clientes. O consultor tem que ter ciência que um código ‘bem
escrito’ muitas vezes faz o papel do seu cartão de visita e a qualidade
apresentada uma ferramenta poderosa de ‘marketing’ para a sua empresa.
O segundo contato, o analítico, refletirá seus resultados em
entendimento e tempo de resposta a solicitação de alteração(ões) como
decorrência do primeiro contato. Se o primeiro tem um peso na qualidade, o
segundo tem em seu peso além da qualidade o fator tempo.
Em termos práticos, a identação a ser aplicada nos códigos ABAP
deverá ser de fator dois (2), ou seja, dois espaços em branco.
O alinhamento levará em conta a identação aplicada e deverá ser
aplicado sempre que o código permitir, como por exemplo, na declaração de
data com seus respectivos tipos e comentários.
Como já foi ilustrado no tópico sobre ‘Comentários’, o alinhamento
deverá obedecer ao seguinte critério, a posição do alinhamento de uma série
de comentários ou tipos correlatos, será definida pelo início da maior ‘string’,
visto que o término da mesma estará ocorrendo a direita na última coluna.
Em relação ao espaçamento utilizado entre as linhas de código, o critério
sugerido visto que não é obrigatório, é usar apenas uma linha. Não é objeto
desse trabalho a definição dos locais em que o consultor deverá utilizar um
espaçamento dentro de um código.

Porém, ilustramos o uso não esperado do recurso, ou seja, entre a declaração
de data e constantes, por exemplo, ou dentro de um mesmo bloco lógico de
comandos, por exemplo, as estruturas condicionais e as estruturas simples que
caracterizam laços, por exemplo, loop-endloop e do-enddo.
Para um melhor entendimento do que foi descrito acima, ilustramos a
seguir uma tela como exemplo.
Espaçamento entre
linhas nos blocos de
comandos.
Observação: Para manter o layout do código uniforme, todos os

desenvolvedores deverão utilizar a funcionalidade “Pretty Printer” do editor para
auxiliar na identação do código fonte.

5. NOMENCLATURA
Todos os objetos criados pelos consultores nos projetos sob a

responsabilidade da Procwork deverão seguir a nomenclatura proposta nesse
documento, salvo os casos onde se faça uso da metodologia do cliente ou de
parceiros.
Como convenção, adotaremos apenas a letra ‘Z’ para identificação de
objetos R/3.
O ambiente de desenvolvimento, quanto ao repositório de objetos do
sistema R/3, pode ser dividido por tipos de objetos, conforme seguem abaixo:
 Objetos de Programa;
 Objetos do Dicionário;
 Objetos de Grupo de Função;
 Objetos Privados Locais;
 Business Engineering;
 Outros Objetos.
Observe que alguns objetos são comuns entre os tipos citados acima e
sendo assim, as correspondentes nomenclaturas serão referenciadas apenas
uma vez. As declarações de variáveis recebem um tópico dedicado, visto que
sua aplicação na construção dos objetos deve seguir a mesma nomenclatura
independendo do tipo do mesmo.
Nos tópicos relacionados a seguir, serão apresentadas tabelas
ilustrativas quanto à nomenclatura a ser empregada na identificação dos
objetos.

5.1. VARIÁVEIS
O sistema R/3 no seu ambiente de desenvolvimento pode trabalhar com

variáveis (campos globais ou locais), o consultor deverá nomear todas as
variáveis conforme ilustração, seguida do sinal ‘underscore’ ( _ ), mais o nome,
ou nomes que melhor identifiquem o conteúdo da variável com o sinal
‘underscore’ entre os nomes.
Para definir o tipo da variável, procurar utilizar a opção TYPE.
Declaração de Constantes
Todas as constantes devem começar por “c_xxxx” onde xxxx deve

identificar de forma clara a utilização da variável, por exemplo, para o tipo de
movimento 101 que significa entrada, em vez de criar um constante c_101 criar
a constante c_entrada.
Declaração de Tipos
Todas as constantes devem ser da forma “nome_TYPE”. Observe que

_TYPE é fixo.
Declaração de Parameters e Selection-options
Todos os parâmetros (parameters) devem começar por “p_” e todas as

opções de seleção (select-options) devem começar por “s_”.
Declaração de Variáveis
Todas as variáveis devem começar por “g<tipo>_” (variáveis globais)

ou por “l<tipo>_” (variáveis locais). Esta regra não vale para campos de
tabelas internas! O <tipo> deve ser utilizado como referência ao tipo da
declaração conforme tabela abaixo:

Tipo <tipo>
Date D
Time T
Float F
Integer I
Character C
Numeric N
Tabela sem Header Line W
Estrutura S
Declaração de Tabelas Internas
Todas as tabelas internas devem começar por “gw_” (tabelas internas

globais) ou por “lw_” (tabelas internas locais). Sempre procurar declarar um
tipo (TYPES) com os campos da tabela interna e utilizar os complementos
STANDARD TABLE. Vide o exemplo abaixo para declaração de tabela interna:
DATA gw_kna1 TYPE STANDARD TABLE OF kna1_type.
Declaração de Estruturas
Todas as estruturas devem começar por “gs_” (estruturas globais) ou

por “ls_” (estruturas locais). Vide o exemplo abaixo para declaração de tabela
interna:
DATA gs_kna1 TYPE kna1_type.
Declaração de Field-Symbol
Todos os ponteiros (field-symbol) devem ser declarados por

“<xxxxxxx>” onde xxxxxx é a identificação de qual tabela interna este field-
symbol irá ser utilizado como header line. Vide exemplo abaixo:
FIELD-SYMBOL <kna1> TYPE kna1_type.
Declaração de Telas de Module Pool
As telas deste tipo de programa devem possuir numeração variando

entre 9000 até 9999.

5.2. IDENTIFICAÇÃO DA APLICAÇÃO
O sistema R/3 apresenta uma classificação para as suas aplicações

conforme a tabela ilustrada abaixo, essa classificação corresponde a dois
caracteres, o qual será usado na composição da nomenclatura dos objetos
desenvolvidos pelos consultores.
Sigla Módulo Funcional Observação

SD Sales & Distribution Logistics
MM Materials Management Logistics
PP Production Planning Logistics
QM Quality Management Human Resources
PM Plant Maintenance Human Resources
HR Human Resources Human Resources
FI Financial Accounting Accounting
CO Controlling Accounting
TR Treasury Accounting
PS Project System Cross-Application
WF Workflow Cross-Application
IS Industry Solutions Cross-Application
AB ABAP – Interfaces - Gerenciador Dif. De Módulos
5.3. OBJETOS DE PROGRAMA
Os objetos ABAP desse grupo estão relacionados, com as dimensões,

conforme a tabela abaixo:
OBJETO RELEASE 4.X
Programa 30 caracteres
Variante 14 caracteres
Campo Global 30 caracteres
Evento 30 caracteres
Sub-Programa 30 caracteres
Macro 30 caracteres
Tela 04 caracteres
Status GUI 20 caracteres
Título GUI 20 caracteres
Include 30 caracteres
Transação 20 caracteres
Módulo de Diálogo 30 caracteres
5.3.1. PROGRAMA / FORMULÁRIOS

O padrão a ser utilizado na nomenclatura de objetos do tipo
‘PROGRAMA’ corresponde a forma ZPMMX_ID. Onde:
CARÁTER DESCRIÇÃO
Constante que identifica o objeto como não pertencente ao
Z
padrão “standard” do R/3.
P Constante que identifica o objeto como sendo um programa.
MM Identificação do módulo funcional a qual o programa se destina.
Identifica o tipo de programa conforme a seqüência abaixo:
I – Interfaces
C – Conversão (Cargas Iniciais)
E – Enhancement (Aplicações do Cliente, exits)
X – Cross-Aplication (IDOC, ALE, Etc...)
X
R – Relatórios (report simples, ALV)
F – Formulários (SapScripts, Smartforms)
S – Estilo de Formulários (SapScripts, Smartforms)
K – Copia de Standard
w – WorkFlow (Amplianção de Tipo de Objeto – Subtipo)
String que identifica o objetivo do programa. Poderá ser uma
ID seqüência numérica para a identificação do objeto. Variando de
001 à 999.
 OBSERVAÇÃO: Os programas de Module Pool não seguirão o padrão

acima e sim o padrão standard da SAP no caso “SAPMZ_ID”.
o Onde: ID – String que identifica o objetivo do programa. Poderá ser
uma seqüência numérica para identificação do objeto. Variando de
001 a 999.
 OBSERVAÇÃO 2: Para formulários, o nome deverá ser o mesmo do
programa que estiver sendo utilizado, quando este for Z ou Y.
5.3.2. VARIANTE
O padrão a ser utilizado na nomenclatura de objetos do tipo ‘VARIANTE’

corresponde a forma ZVMM_ID. Onde:

Z
V Constante que identifica o objeto como sendo uma variante
Reservado a ‘string’ que melhor identifique o objeto, a dimensão e
o conteúdo são livres, desde que respeitem respectivamente o
limite máximo e o bom senso. A ‘string’ poderá ser do tipo simples
ID
ou composta. No caso de ser composta, dois ou mais conjuntos
de caracteres, a concatenação entre os conjuntos deverá ser feita
através do sinal ‘underscore’ ( _ ).
5.3.3. CAMPO GLOBAL
O consultor deve considerar as definições apresentadas no tópico 5.1.,

porém não deixando de respeitar as dimensões informadas na tabela
comparativa apresentada no tópico 5.3.
5.3.4. EVENTO
O padrão a ser utilizado na nomenclatura de objetos do tipo ‘EVENTO’

corresponde à forma ZEMM_ID. Onde:
Z
E Constante que identifica o objeto como sendo um evento
ID
5.3.5. SUB-PROGRAMA (Forms)
O padrão a ser utilizado na nomenclatura de objetos do tipo ‘SUB-

PROGRAMA’ corresponde a forma ZF_ID. Onde:

Z
F Constante que identifica o objeto como sendo sub-programa
ID ou composta. No caso de ser composta, dois ou mais conjuntos
Exemplo: ZF_AÇÃO_OBJETO => ZF_MONTA_TABELA
5.3.6. MACRO
O objeto do tipo ‘MACRO’ definido pelo consultor deve apresentar a

forma ZMMM_ID. Considere no ‘corpo’ do objeto que conterá as macros, uma
seção de declaração devidamente comentada para as mesmas. Onde:
Z
M Constante que identifica o objeto como sendo uma macro
ID
5.3.7. TELA
A identificação dos objetos do tipo ‘TELA’ deverá apresentar apenas

caracteres numéricos. O consultor deve procurar usar uma ‘seqüência’
coerente para as telas dinâmicas a serem implementadas no projeto.

5.3.8. STATUS GUI
O padrão a ser utilizado na nomenclatura de objetos do tipo ‘STATUS

GUI’ corresponde ao mesmo ID da tela, ou seja se a tela é 9000 o status GUI
para esta tela deve ser 9000.
5.3.9. TÍTULO GUI
O padrão a ser utilizado na nomenclatura de objetos do tipo ‘TÍTULO

GUI’ corresponde ao mesmo ID da tela, ou seja se a tela é 9000 o status GUI
para esta tela deve ser 9000.
5.3.10. INCLUDE
Os objetos do tipo ‘INCLUDE’ apresentarão sua nomenclatura como os

objetos do tipo ‘PROGRAMA’, a menos da constante de identificação, que
nesse caso será ‘I’ ao invés de ‘P’. No caso de modules pools a o ID dos
includes devem ser o mesmo do programa principal e utilizar ‘_’ mais a
identificação se o include é para as variáveis (TOP), process before output (O),
process after input (I) ou rotinas (F). Onde:

Z
I Constante que identifica o objeto como sendo um include
Seqüência numérica para a identificação do objeto. Variando de
ID
001 à 999.
No caso de module pool, seguir o padrão após o ‘_’:
1. Include para variáveis adicionar o identificador ‘TOP’.
2. Include para os process before output (PBO) adicionar o
_ identificador ‘O’.
3. Include para os process after input (PAI) adicionar o
identificador ‘I’.
4. Include para rotinas adicionar o identificador ‘F’.
5.3.11. TRANSAÇÃO
O padrão a ser utilizado na nomenclatura de objetos do tipo

‘TRANSAÇÃO’ corresponde à forma ZTMMNNNY. Onde:
Z
T Constante que identifica o objeto como sendo uma transação
ID 001 à 999. Essa seqüência deverá ser seguida
independentemente do módulo a qual se destina o objeto.
Subdivisão do objeto para uma mesma solução. Este item não é
Y obrigatório.
Exemplo: ZTFI001 e ZTFI001B.

5.3.12. MÓDULO DE DIÁLOGO
O padrão a ser utilizado na nomenclatura de objetos do tipo ‘MÓDULO

DE DIÁLOGO’ corresponde à forma ZDMM_ID. Onde:
Z
Constante que identifica o objeto como sendo um módulo de
D
diálogo
ID ou composta. No caso de ser composta, dois ou mais conjuntos
Ex: ZDFI_AÇÃO_OBJETO => ZDFI_INICIALIZA_TELA
5.4. OBJETOS DO DICIONÁRIO
Os objetos ABAP desse grupo estão relacionados, com as respectivas dimensões,

conforme a tabela abaixo:
OBJETO RELEASE 4.X

Tabela 30 caracteres
Estrutura 30 caracteres
Visão 30 caracteres
Elemento de Dados 30 caracteres
Domínio 30 caracteres
Objeto de Bloqueio 30 caracteres
Ajuda para Pesquisa 30 caracteres
Grupo de Tipos 05 caracteres
O padrão a ser utilizado na nomenclatura de objetos do ‘Dicionário’

corresponde à forma ZWWMM_ID. O fator que proverá a diferença entre os
objetos será o valor da constante ‘WW’, que assumirá um dos seguintes
valores possíveis, conforme a tabela abaixo:

OBJETO VALOR DA CONSTANTE ‘WW’
Tabela TB
Estrutura ST
Visão VW
Elemento de Dados DE
Domínio DO
Objeto de Bloqueio BO
Ajuda para Pesquisa SH
Grupo de Tipos TY
Onde:
Z
WW Constante que identifica o objeto conforme a tabela anterior.
ID
Contudo o objeto ‘GRUPO DE TIPOS’ apresenta-se com dimensão 5 e a

sua nomenclatura seguirá a forma ‘ZWWKK’ onde a variável ‘WW’ assumirá o
valor ‘TY’ e a variável ‘K’, que apresenta-se mais flexível, poderá assumir
qualquer valor alfanumérico.
5.5. OBJETOS DE GRUPO DE FUNÇÃO
Os objetos ABAP desse grupo estão relacionados, com as respectivas

dimensões, conforme a tabela abaixo:
OBJETO RELEASE 4.X

Grupo 26 caracteres
Módulo de Função 30 caracteres
Campo Global 30 caracteres
Evento 30 caracteres
Módulo PBO 30 caracteres
Módulo PAI 30 caracteres

Sub-Programa 30 caracteres
Macro 30 caracteres
Tela 04 caracteres
Status GUI 20 caracteres
Título GUI 20 caracteres
Comparando-se com os ‘Objetos de Programa’, nota-se que apenas os

objetos ‘GRUPO’ e ‘MÓDULO DE FUNÇÃO’ não estão caracterizados até o
presente momento. A forma a ser adotada é Z_RMM_ID para objetos do tipo
‘GRUPO’ e ‘Z_FMM_ID’ para objetos do tipo ‘MÓDULO DE FUNÇÃO’. Onde:
Z_
F Constante que identifica o objeto como módulo de função.
R Constante que identifica o objeto como grupo.
ID
5.6. OBJETOS PRIVADOS LOCAIS
A forma para esse tipo de objeto está definida como ‘ZOMM_ID’.

Onde:
Z
O Constante que identifica o objeto como objeto privado local.
ID Reservado a ‘string’ que melhor identifique o objeto, a dimensão e

5.7. OUTROS OBJETOS

OBJETO RELEASE 4.X

Classe de Desenvolvimento ou Pacote 30 caracteres
Módulo de Função 30 caracteres
Banco de Dados Lógico 20 caracteres
ID Parâmetro SET/GET 20 caracteres
Menu de Área 20 caracteres
Classe de Mensagem 20 caracteres
Número da Mensagem 20 caracteres
AUTHORITY-CHECK
PF-STATUS
TITLEBAR
Sessão BATCH INPUT
MEMORY-ID
Nesse grupo, os objetos ‘INCLUDE’, ‘MÓDULO DE FUNÇÃO’,

‘MÓDULO DE DIÁLOGO’ e ‘TRANSAÇÃO’ já se encontram caracterizados em
tópicos anteriores. Os demais objetos desse grupo estão caracterizados a
seguir.
5.7.1. CLASSE DE DESENVOLVIMENTO OU PACOTE
O padrão a ser utilizado na nomenclatura do objeto ‘CLASSE DE

DESENVOLVIMENTO’ (também conhecido como pacote nas versões mais
novas do SAP) corresponde à forma ZMM_ID. Onde:
Z
ID Reservado a ‘string’ que melhor identifique o objeto, a dimensão e

Observação: Poderá ser adotado o padrão já estabelecido pela equipe

de Basis.
5.7.2. BANCO DE DADOS LÓGICO
O padrão a ser utilizado na nomenclatura do objeto ‘BANCO DE DADOS

LÓGICO’ corresponde à forma ‘ZYMM_ID’. Onde:
Z
Y Constante que identifica o objeto como banco de dados lógico.
ID
5.7.3. ID PARÂMETRO SET/GET
O objeto ‘ID’ usado como parâmetro junto aos comandos ‘SET’ e ‘GET’
devera ser identificados pelo consultor através do formato ‘ZID_SS’. Onde:
Z Fixo
ID Constante que identifica o objeto como um parâmetro ID.
SS Reservado a ‘string’ que melhor identifique o objeto, a dimensão e


5.7.4. MENU DE ÁREA
O padrão a ser utilizado na nomenclatura do objeto do tipo ‘MENU DE
ÁREA’ corresponde à forma ZHMM_ID. Onde:
Z
H Constante que identifica o objeto como menu de área.
Reservado corresponde a forma a ‘string’ que melhor identifique o
objeto, a dimensão e o conteúdo são livres, desde que respeitem
respectivamente o limite máximo e o bom senso. A ‘string’ poderá
ID
ser do tipo simples ou composta. No caso de ser composta, dois
ou mais conjuntos de caracteres, a concatenação entre os
conjuntos deverá ser feita através do sinal ‘underscore’ ( _ ).
5.7.5. CLASSE DE MENSAGEM
O padrão a ser utilizado na nomenclatura do objeto do tipo ‘CLASSE DE

MENSAGEM’ corresponde à forma ZLMMNN. Onde:
Z
L Constante que identifica o objeto como classe de mensagem
ID
01 à 99.

5.7.6. NÚMERO DE MENSAGEM
O padrão a ser utilizado na nomenclatura do objeto do tipo ‘NUMERO DE

MENSAGEM’ corresponde à forma ZNNN. Onde:
Constante que identifica o objeto como não pertencente ao padrão
Z
“standard” do R/3.
Seqüência numérica para a identificação do objeto. Variando de 001 à
NNN
999.
5.7.7. AUTHORITY-CHECK
O padrão a ser utilizado na nomenclatura do objeto do tipo

‘AUTHORITY-CHECK’ corresponde à forma ZXXXXXXX. Onde:
Z
XXX Nome do programa que utiliza o objeto.
O objeto deve sempre conter o campo ACTVT e demais campos

necessários e constar dentro do grupo de acordo com o módulo.
5.7.8. PF-STATUS
O padrão a ser utilizado na nomenclatura de objetos do tipo ‘PF-

STATUS’ corresponde ao mesmo ID da tela, ou seja se a tela é 9000 o status
GUI para esta tela deve ser 9000.
5.7.9. TITLEBAR
O padrão a ser utilizado na nomenclatura de objetos do tipo ‘TITLEBAR’

corresponde ao mesmo ID da tela, ou seja se a tela é 9000 o status GUI para
esta tela deve ser 9000.

5.7.10.MEMORY-ID
O padrão a ser utilizado na nomenclatura do objeto do tipo ‘MEMORY-

ID’ corresponde à forma ZNNN. Onde:
Z
NNN
001 à 999.
5.7.11. BATCH INPUT (Pastas)
O padrão a ser utilizado na nomenclatura do objeto do tipo ‘BATCH

INPUT’ corresponde à forma ZBMM_ID. Onde:
Z
B Constante que identifica o objeto como pasta de Batch Input.
Reservado corresponde a forma a ‘string’ que melhor identifique o
objeto, a dimensão e o conteúdo são livres, desde que respeitem
respectivamente o limite máximo e o bom senso. A ‘string’ poderá
ID
ser do tipo simples ou composta. No caso de ser composta, dois
ou mais conjuntos de caracteres, a concatenação entre os
conjuntos deverá ser feita através do sinal ‘underscore’ ( _ ).
o Padrão para criação de pastas via programa, o gerenciador gera

pastas automáticas utilizando variáveis da execução para efetuar a
nomenclatura das mesmas.
5.8. BUSINESS ENGINEERING

OBJETO RELEASE 4.X

Modelo de Dados 26 caracteres

Tipo de Entidade 26 caracteres
Ctg. Obj. Business 10 caracteres
5.8.1. MODELO DE DADOS
O padrão a ser utilizado na nomenclatura do objeto do tipo ‘MODELO

DE DADOS’ corresponde à forma ZJMM_ID. Onde:
Z
J Constante que identifica o objeto como modelo de dados.
ID
5.8.2. TIPO DE ENTIDADE
O padrão a ser utilizado na nomenclatura do objeto ‘TIPO DE

ENTIDADE’ corresponde a forma ZQMM_ID. Onde:
Z
Q Constante que identifica o objeto como modelo de dados.
ID

5.8.3. CATEGORIA DE OBJETO BUSINESS
O padrão a ser utilizado na nomenclatura do objeto do tipo ‘CATEGOTIA

DE OBJETOS BUSINESS’ corresponde à forma ZWMM_ID. Onde:
Z
Constante que identifica o objeto como categoria de objeto
W
business.
ID
6. LAY-OUT
6.1. LAY-OUT DE TELA
Devem seguir as definições da Especificação Funcional. Na sua

ausência, devem ser seguidos os mesmos critérios utilizados no standard do
R/3.
6.2. LAY-OUT DE SAIDA (Relatório)
Devem seguir as definições da Especificação Funcional, na sua

ausência, deve ser sugerido pelo consultor abap um lay-out limpo e claro no
tocante as cores.

7. Normas de Programação
Nesse ponto existem algumas dicas de programação para melhorar a

performance e a manutenção dos programas escritos em ABAP.
7.1. TABELAS INTERNAS
Nas versões mais recentes do SAP (ECC 5.0 ou superior) não é

recomenda criar tabelas internas com header line. Por está razão nenhuma
tabela interna declarada em um desenvolvimento deve conter header line.
Abaixo exemplo de como declaração uma tabela interna sem header line:
(Seguir as normas de criação de comentários já definidas).
DATA: gw_mara type standard table of mara_type.
Dentro de um programa, a maior parte do tempo computacional é

despendido no acesso ao banco de dados. O acesso a tabelas muito grandes
pode se transformar num fator de risco ao bom desempenho de um programa,
principalmente em se tratando de programas que devam ser executados
periodicamente, tais como interfaces. A fim de minimizar o tempo gasto no
acesso ao banco de dados, vale lembrar que em ABAP, os métodos de
extração de dados (do mais eficiente para o menos) são:
 Executar uma cláusula “select” numa view ao invés de utilizarmos várias

tabelas.
 Realizar um loop numa internal table.
 Executar uma cláusula “select” numa tabela
 Utilizar uma tabela lógica usando o comando “get”.
7.2. PARÂMETROS DE SELEÇÃO
Em telas de seleção, os campos devem ser sempre referenciados a um

campo existente no dicionário de dados do R/3. Desta forma, o usuário poderá
acessar a tela de help do campo através das teclas de função F1 e F4 quando
o mouse estiver posicionado no campo.

Levar em consideração durante um desenvolvimento:
 Evite a utilização de valores explícitos no programa. Para obter os dados

necessários à lógica do programa, cláusulas de seleção (select
statement), arquivos de entrada ou saída, utilize parâmetros ou telas de
seleção para garantir flexibilidade de manutenção. Portanto evite
comandos do tipo:
Forma incorreta:
SELECT matnr werks FROM marc WHERE werks = '5000' …
IF gh_vbfa-vbtyp_n = 'J' …
gf_custo = mbew-strps * '1.2' ...
Forma Correta:
SELECT matnr werks FROM marc WHERE werks = pc_werks.
IF gh_vbfa-vbtyp_n = pc_vbtyp
gf_custo = mbew-strps * pn_valor.
 Evite também o uso do “default” para atribuir valores iniciais aos

parâmetros ou em telas de seleções. Esses valores podem mudar no
futuro. Dê preferência à criação de variantes para setar esses valores.
 Os parâmetros de seleção devem ser validados no evento “at-selection-

screen” para limitar os dados fornecidos àqueles configurados pela
equipe funcional. Por exemplo: Não permitir que a data informada tenha
um ano anterior ao início do ano corrente.
 Todos os parâmetros para seleção de nomes de arquivos devem ser

definidos com entradas em caracteres minúsculos (“lower case”) de
tamanho 128 bytes. (Use “type rlgrap-filename”).

7.3. DECLARAÇÃO DE VARIÁVEIS
Sempre que possível utilizar o complemento TYPE para declarar

variáveis, constantes, estruturas, tabelas internas, etc.
7.4. DECLARAÇÃO DE EVENTOS
O evento “START-OF-SELECTION” não deve possuir mais de 20 linhas

(excluindo os comentários) para que se reflita de forma lógica e concisa o
processamento global do programa. O uso de subrotinas (perform xxxxxxx
using yyyyyyy) deve ser extensamente utilizado para que este limite de 20
linhas seja mantido.
7.5. DECLARAÇÃO DE SUBROTINAS (FORMS)
Blocos de código que são executados mais de uma vez devem ser
colocados numa subrotina (“form”). Tal procedimento deve ser adotado para
eliminar trechos de código redundante e para facilitar a depuração do
programa. Uma subrotina deve realizar apenas um processo. Se existir alguma
subrotina que realize mais de um processo, então deve-se dividi-la em
múltiplas subrotinas. O nome de uma subrotina deve ser mnemônico. A
subrotina que poderá ser usada em outros programas deverá ser colocada em
um módulo de função.
7.6. CÁLCULOS
Evite o uso de comandos para cálculo de expressões aritméticas. Por

exemplo:
gn_data1 = gn_data1 + 1
É melhor que
compute gn_data1 = gn_data1 + 1
ou
add 1 to gn_data1.

7.7. COMANDO MOVE-CORRESPONDING
Não é indicado utilizar este comando dentro de loops ou em seleções de

dados. Mover campo a campo é sempre mais indicado (leia-se performático),
para isto declarar uma estrutura ou tabela interna na mesma seqüência dos
campos que devem ser movidos.
7.8. COMANDO DESCRIBE
O comando DESCRIBE é a maneira mais eficiente de determinar o

número de registros de uma tabela interna. Exemplo de utilização:
*** Encontrar a quantidade de registros

DESCRIBE TABLE gh_tabela LINES gn_linhas.
7.9. COMANDO CASE
O comando CASE geralmente é mais claro, legível e um pouco mais

rápido do que o comando IF. Quando testamos se um campo é igual a um
outro campo, tanto faz usarmos CASE ou IF. Porém, o comando CASE é o
melhor, pois além de facilitar a leitura do código, é mais eficiente depois de 5
“if’s”.
7.10. COMANDO LOOP
Por questões de performance não é recomendo utilizar o comando

LOOP com o completo WHERE. Caso seja necessário encontrar um grupo de
registros em vez de utilizar o complemento WHERE utilizar o completo FROM
conforme o exemplo abaixo:
*** Ordenar os registros

SORT: gw_vbak BY vbeln ASCENDING
gw_vbap BY vbeln ASCENDING.

*** Ler todos os cabeçalhos das cotações
LOOP AT gw_vbak ASSIGNING <fs_vbak>.
*** Localizar os itens da cotação

READ TABLE gw_vbap ASSIGNING <fs_vbap>
WITH KEY
vbeln = <fs_vbak>-vbeln
BINARY SEARCH.
*** Ler todos os itens da cotação

LOOP AT gw_vbap ASSIGNING <fs_vbap> FROM sy-tabix.
*** Verifica se modificou o número da cotação

IF <fs_vbap>-vbeln <> <fs_vbak>-vbeln.
EXIT.
ENDIF.
*** Escrever mensagem

WRITE: <fs_vbap>-vbeln,
<fs_vbap>-posnr.
ENDLOOP.
ENDLOOP.
Observação: para o código acima funcionar é necessário que a tabela

interna esta ordena pelos campos de procura do comando READ TABLE.
Levar em consideração caso seja necessário verificar mais de um campo no IF
do segundo LOOP utilizar o complemento OR. Outro ponto de atenção é a
utilização do complemento ASSIGNING que torna a execução do comando
LOOP mais rápida, já que o conteúdo da tabela interna não será copiado para
uma nova área de memória (isto aconteceria se tivesse movido o conteúdo da
tabela interna para uma estrutura).
7.11. COMANDO WHILE
O comando WHILE é mais eficiente do que DO + EXIT. WHILE é mais

fácil de entender e mais rápido durante a execução.

7.12. COMANDO SORT
Quando utilizar o comando SORT para ordenar tabelas internas,

especifique quais os campos utilizados como referência. Ou seja, é mais
eficiente SORT GH_ITAB BY FIELD_1 ASCENDING FIELD_2 DESCENDING
que apenas SORT ITAB.
7.13. COMANDO SELECT
Evite a utilização do comando SELECT sob a forma “SELECT * FROM

<TABLE> WHERE ...”. Ao utilizarmos “ * ” para busca de campos estaremos
trazendo do servidor de banco de dados todas as colunas da tabela TABLE. Ao
invés disto, utilize a forma “SELECT FLD1 FLD2 FLD3 INTO (GC_FLD1,
GC_FLD2, GC_FLD3) FROM <TABLE> WHERE ....”.
Quando o consultor for utilizar o complete FOR ALL ENTRIES em uma
seleção de dados atentar para os fatos:
 Sempre verificar se a tabela do FOR ALL ENTRIES não está vazia, pois
se for utilizado uma tabela interna vazia para realizar uma seleção de
dados será selecionado todos os registros da tabela informada no
FROM.
 Sempre ordenar e excluir os registros duplicados da tabela interna do

FOR ALL ENTRIES. Caso a tabela interna não possa ter os registros
duplicados excluídos, criar uma tabela interna temporária mover os
dados e realizar as operações.
 Sempre selecionar os campos conforme a ordem das tabelas

transparentes.

 Sempre procurar utilizar índices primários ou secundários nas seleções
de dados (e sempre na mesma ordem da tabela transparente ou da
criação do índice secundário). Caso algum campo não chave tenha que
ser filtrado é preferível selecionar tal campo e após a seleção excluir o
mesmo da tabela interna. Imagine o cenário: selecionar todas as
cotações informadas no parâmetro de tela de Nº Cotações onde a data
de criação seja igual ao dia de hoje. A tabela de cotações é a VBAK e
seu campo chave é o VBELN. O campo ERDAT (data de criação) não é
chave.
*** Seleção das cotações

SELECT vbeln “ Nº Cotação
erdat “ Data de Criação
INTO TABLE gw_vbak
FROM vbak
WHERE vbeln in so_vbeln.
*** Excluir os registros que não estejam no parâmetro data de criação

DELETE gw_vbak WHERE NOT erdat IN so_erdat.
 Evitar na clausula WHERE comparações do tipo diferente (<>).
7.14. COMANDO INTO TABLE
O comando INTO TABLE é sempre mais rápido que os comandos INTO

e APPEND para inserção de dados numa tabela interna. Desta forma prefira
sempre a forma “SELECT * FROM <TABELA> INTO TABLE GH_ITAB” à forma
“SELECT * FROM <TABELA> INTO GH_ITAB. APPEND GH_ITAB.
ENDSELECT”.
7.15. COMANDO FREE
Quando os registros de uma tabela interna não forem mais utilizados no

decorrer do programa utilizar o comando FREE para liberar espaço em
memória.

7.16. ÍNDICE
Cada índice criado diminui a performance dos “inserts” e dos “updates”

nas tabelas. No geral, tabelas onde são feitos muitos “inserts” e “updates”,
deverão ter poucos índices. Da mesma forma, tabelas onde há muitos
“selects”, poderão ter mais índices. Uma média de 3-4 índices por tabela é
aceitável.
7.17. CÓDIGO MORTO
Evite a existência de código morto ao longo dos programas. Remova

definições de campos que nunca serão usados e códigos que nunca serão
executados.
7.18. COMANDO READ TABLE
Sempre que possível ordenar a tabela interna pelos campos que serão
utilizados no complemento WITH KEY para poder, nestes casos será possível
utilizar o complemento BINARY SEARCH tornando a busca de registros mais
performática. Outro ponto importante é utilizar o complemento ASSIGNING
também por questões de performance. Vide um exemplo de utilização do
comando:
*** Selecionar uma cotação

READ TABLE gw_vbak ASSIGNING <fs_vbak> WITH KEY
vbeln = ln_vbeln
BINARY SEARCH.
7.19. TAMANHO PADRÃO DE COLUNAS (73 CARACTERES)
Sempre respeitar a digitação de no máximo 73 caracteres por linha. Por

exemplo, caso um comentário ultrapasse 73 caracteres, continuar na linha
subseqüente a digitação do mesmo.

O SAP já possui uma opção para realizar tal verificação, com isto caso o
limite de caracteres (73) for ultrapassado, o editor ABAP do SAP
automaticamente irá quebrar os caracteres excedentes em uma nova linha.
Para ativar este opção ir em Utilitários -> Configuração e marcar a opção
Compri. Linha Standard.
7.20. VERIFICAÇÃO EXTENDIDA DE SINTAXE
Todos os desenvolvedores deverão utilizar a funcionalidade de

Verificação Estendida de Sintaxe dos programas criados. Esta funcionalidade
executa uma série de verificações no código fonte, normalmente não
verificadas na checagem simplificada de sintaxe. Entre os erros detectados
com esta funcionalidade encontraremos: definição de variáveis não utilizadas
pelo programa, declaração desnecessária de parâmetros, forms não
chamados, etc.
Para executar a Verificação Estendida, a partir do Edit ABAP, selecione
Programa -> Verificar -> Verificação de Programa Ampliada | Executar
Verificação Ou utilize a transação SLIN.
7.21. ANÁLISE DO TEMPO DE EXECUÇÃO
Cada desenvolvedor deverá utilizar a funcionalidade SAP de Análise do

Tempo de Execução dos programas criados. Tal ferramenta nos ajuda a
descobrir trechos do código fonte que apresentam baixa performance. A
transação utilizada para esta análise é SE30.
7.22. CRIAÇÃO DE LITERAIS
Caso seja necessário utilizar algum hard code no programa, sempre

criar constantes, por exemplo, em vez de realizar uma comparação var = ‘X’ ou
correto deve ser var = cc_x (onde cc_x possui o valor ‘X’). Em ocasiões que
existe a necessidade de imprimir um texto fixo na tela, por exemplo,
“Problemas com o cliente”, em vez de executar WRITE “Problemas com o
cliente” criar um elemento de texto contendo esta mensagem (text-001).

Criando elementos de texto é possível traduzir as mensagens do programa
para outras línguas.
7.23. PROGRAMAÇÃO PARA O MODULO DE HR (HUMAN RESOURCES)
O modulo de HR possui algumas particularidades em termo de

programação e performance que serão demonstradas abaixo:
 Por questões de performance evite o uso de instruções SQL dentro do

evento GET. É preferível realizar as seleções de dados fora deste
evento e utilizar o comando READ TABLE para encontrar os valores
desejados.
 Durante a utilização de um infotipo para edição ou criação de um

registro bloqueá-lo para que não haja possibilidade de perda da
informação devido ao uso simultâneo de outro usuário no mesmo. Para
realizar tal bloqueio/desbloqueio utilizar as funções
“BAPI_EMPLOYEET_ENQUEUE” e “BAPI_EMPLOYEET_DEQUEUE”
garantindo o uso exclusivo do registro.
 Para acessar os dados dos infotipos sempre procure utilizar as funções

como, por exemplo, “HR_READ_INFOTYPE” do que acessar as tabelas
diretamente através de instruções SQL. As funções de leituras já
realizam toda a verificação de permissão dos usuários para acesso de
dados tornando o programa mais seguro.
 Por questões de performance sempre utilizar a função

“HR_PSBUFFER_INITIALIZE” antes da função de atualização de
infotipos “HR_INFOTYPE_OPERATION”.

7.24. NOTAS OSS
Caso ao aplicar uma determinada Nota OSS seja necessário

alterar/apagar o código padrão do SAP, teremos que seguir os passos
descritos neste item.
No início do programa (caso exista um cabeçalho, imediatamente abaixo
deste), colocar a seguinte referência:
Exemplo:
*-------------------------------------------------------------------------
* Histórico das modificações referentes a notas OSS
*-------------------------------------------------------------------------
* Data |Autor |Nota |Descrição
*-------------------------------------------------------------------------
* 10/11/2007 |Fulano |008412 |Number of range:multiple copies
*-------------------------------------------------------------------------
No local da modificação sugerida pela nota OSS: quando temos que

modificar/apagar/inserir uma linha, a mesma deverá ser colocada em
comentário.
Exemplo:
*-------------------------------------------------------------------------
* Início da Nota OSS: 008412
... “ <-- Alterado
...
... “ <-- Apagado
...
... “ <-- Inserido
* Fim da Nota OSS: 008412
*-------------------------------------------------------------------------

Manual de Padronização Desenvolvimento Abap - v07

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Manual de Padronização Desenvolvimento Abap - v07

Загружено:

Авторское право:

Доступные форматы

PADRÕES DE

 Este material é de propriedade intelectual da Procwork.

Manual de Padronização Desenvolvimento Abap.doc Página 1 de 48

Manual de Padronização Desenvolvimento Abap.doc Página 2 de 48

Manual de Padronização Desenvolvimento Abap.doc Página 3 de 48

Esse documento tem como objetivo definir padrões de metodologia e

Nunca comece a desenvolver ou alterar um objeto sem antes ter em

Manual de Padronização Desenvolvimento Abap.doc Página 4 de 48

A identificação de um objeto ABAP sempre envolverá um “Header”

Deverá estar localizado nas primeiras linhas do código fonte. Para

Manual de Padronização Desenvolvimento Abap.doc Página 5 de 48

 A linha de comentário é tracejada e não termina com asterisco (*), essa

 Não existe um número de linhas pré-definido para os itens Cliente, Módulo,

 Nas sentenças, tentar usar o máximo da linha disponível para o comentário,

Manual de Padronização Desenvolvimento Abap.doc Página 6 de 48

A padronização no que se refere aos comentários adicionados ao código

3.1. PONTOS CHAVES

 Seções do Código: toda seção de declaração deverá apresentar a sua

Manual de Padronização Desenvolvimento Abap.doc Página 7 de 48

 Types: todas as declarações deverão estar comentadas, principalmente

 BDC_Table: identificação dos campos e ações executadas pelos

Esse tópico é estritamente ligado ao chamado ‘bom senso’ do consultor,

Nesse tópico será apresentado exemplo de comentários que os

Manual de Padronização Desenvolvimento Abap.doc Página 8 de 48

Declaração de tabelas do dicionário de dados que serão utilizadas em

Declaração de comentários em Constantes

Todo a literal fixa em um programa deve ser representada por meio de

 Declarar usando o bom senso. Exemplo: Tipo de movimento 101. Ao invez

Manual de Padronização Desenvolvimento Abap.doc Página 9 de 48

É recomendável (por questões de organização de código) que toda

Manual de Padronização Desenvolvimento Abap.doc Página 10 de 48

*** Descrição da finalidade do tipo

Declaração de comentários em Tabelas Internas

Deve ser utilizado um cabeçalho padrão para identificar a área de

*** Descrição da utilização da tabela interna

Declaração de comentários em Estruturas

Deve ser utilizado um cabeçalho padrão para identificar a área de

*** Descrição da utilização da estrutura

Declaração de comentários em Field-Symbol

Deve ser utilizado um cabeçalho padrão para identificar a área de

Manual de Padronização Desenvolvimento Abap.doc Página 11 de 48

*** Descrição da utilização do field-symbol

Declaração de comentários em Variáveis

Deve ser utilizado um cabeçalho padrão para identificar a área de

Declaração de comentários em Controls

Deve ser utilizado um cabeçalho padrão para identificar a área de

Declaração de comentários em Macros

Deve ser utilizado um cabeçalho padrão para identificar a área de

*** Macro para realizar a tarefa XXXXX

Manual de Padronização Desenvolvimento Abap.doc Página 12 de 48

Deve ser utilizado um cabeçalho padrão para identificar a área de

*** Classe para realizar o processo XXXXX

Declaração de comentários Implementações de Classes

Deve ser utilizado um cabeçalho padrão para identificar a área de

*** Classe para realizar o processo XXXXX

Declaração de comentários em Parameters e Select-options

Deve ser utilizado um cabeçalho padrão para identificar a área de

Manual de Padronização Desenvolvimento Abap.doc Página 13 de 48

Declaração de comentários em Eventos

Deve ser utilizado um cabeçalho padrão para identificar a área de

Declaração de comentários em seqüências de comandos

Todas as seqüências de comandos devem ser comentadas por asterisco