Você está na página 1de 48

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

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


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

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


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

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


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

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


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.

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


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;

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


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

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


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.

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


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:

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


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

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


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

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


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:

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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


SELECT-OPTIONS s_name for mara-matnr. “ Descrição do campo

Declaração de comentários em Eventos

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


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.

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


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;

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


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

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


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.

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


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.

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


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:

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


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.

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


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

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


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:

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


CARÁTER DESCRIÇÃO
Constante que identifica o objeto como não pertencente ao
Z
padrão “standard” do R/3.
V Constante que identifica o objeto como sendo uma variante
MM Identificação do módulo funcional a qual o programa se destina.
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:

CARÁTER DESCRIÇÃO
Constante que identifica o objeto como não pertencente ao
Z
padrão “standard” do R/3.
E Constante que identifica o objeto como sendo um evento
MM Identificação do módulo funcional a qual o programa se destina.
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.5. SUB-PROGRAMA (Forms)

O padrão a ser utilizado na nomenclatura de objetos do tipo ‘SUB-


PROGRAMA’ corresponde a forma ZF_ID. Onde:

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


CARÁTER DESCRIÇÃO
Constante que identifica o objeto como não pertencente ao
Z
padrão “standard” do R/3.
F Constante que identifica o objeto como sendo sub-programa
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’ ( _ ).
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:
CARÁTER DESCRIÇÃO
Constante que identifica o objeto como não pertencente ao
Z
padrão “standard” do R/3.
M Constante que identifica o objeto como sendo uma macro
MM Identificação do módulo funcional a qual o programa se destina.
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.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.

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


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:

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


CARÁTER DESCRIÇÃO
Constante que identifica o objeto como não pertencente ao
Z
padrão “standard” do R/3.
I Constante que identifica o objeto como sendo um include
MM Identificação do módulo funcional a qual o programa se destina.
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:

CARÁTER DESCRIÇÃO
Constante que identifica o objeto como não pertencente ao
Z
padrão “standard” do R/3.
T Constante que identifica o objeto como sendo uma transação
MM Identificação do módulo funcional a qual o programa se destina.
Seqüência numérica para a identificação do objeto. Variando de
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.

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


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:

CARÁTER DESCRIÇÃO
Constante que identifica o objeto como não pertencente ao
Z
padrão “standard” do R/3.
Constante que identifica o objeto como sendo um módulo de
D
diálogo
MM Identificação do módulo funcional a qual o programa se destina.
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’ ( _ ).
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:

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


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:

CARÁTER DESCRIÇÃO
Constante que identifica o objeto como não pertencente ao
Z
padrão “standard” do R/3.
WW Constante que identifica o objeto conforme a tabela anterior.
MM Identificação do módulo funcional a qual o programa se destina.
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’ ( _ ).

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

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


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

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:

CARÁTER DESCRIÇÃO
Constante que identifica o objeto como não pertencente ao
Z_
padrão “standard” do R/3.
F Constante que identifica o objeto como módulo de função.
R Constante que identifica o objeto como grupo.
MM Identificação do módulo funcional a qual o programa se destina.
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.6. OBJETOS PRIVADOS LOCAIS

A forma para esse tipo de objeto está definida como ‘ZOMM_ID’.


Onde:

CARÁTER DESCRIÇÃO
Constante que identifica o objeto como não pertencente ao
Z
padrão “standard” do R/3.
O Constante que identifica o objeto como objeto privado local.
MM Identificação do módulo funcional a qual o programa se destina.
ID 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

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


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

Os objetos ABAP desse grupo estão relacionados, com as respectivas


dimensões, conforme a tabela abaixo:

OBJETO RELEASE 4.X


Classe de Desenvolvimento ou Pacote 30 caracteres
Include 30 caracteres
Módulo de Função 30 caracteres
Módulo de Diálogo 30 caracteres
Transação 20 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:

CARÁTER DESCRIÇÃO
Constante que identifica o objeto como não pertencente ao
Z
padrão “standard” do R/3.
MM Identificação do módulo funcional a qual o programa se destina.
ID Reservado a ‘string’ que melhor identifique o objeto, a dimensão e

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


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
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’ ( _ ).

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:

CARÁTER DESCRIÇÃO
Constante que identifica o objeto como não pertencente ao
Z
padrão “standard” do R/3.
Y Constante que identifica o objeto como banco de dados lógico.
MM Identificação do módulo funcional a qual o programa se destina.
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.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:

CARÁTER DESCRIÇÃO
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
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
ou composta. No caso de ser composta, dois ou mais conjuntos

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


de caracteres, a concatenação entre os conjuntos deverá ser feita
através do sinal ‘underscore’ ( _ ).

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


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:

CARÁTER DESCRIÇÃO
Constante que identifica o objeto como não pertencente ao
Z
padrão “standard” do R/3.
H Constante que identifica o objeto como menu de área.
MM Identificação do módulo funcional a qual o programa se destina.
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:

CARÁTER DESCRIÇÃO
Constante que identifica o objeto como não pertencente ao
Z
padrão “standard” do R/3.
L Constante que identifica o objeto como classe de mensagem
MM Identificação do módulo funcional a qual o programa se destina.
Seqüência numérica para a identificação do objeto. Variando de
ID
01 à 99.

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


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:

CARÁTER DESCRIÇÃO
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:

CARÁTER DESCRIÇÃO
Constante que identifica o objeto como não pertencente ao
Z
padrão “standard” do R/3.
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.

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


5.7.10.MEMORY-ID

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


ID’ corresponde à forma ZNNN. Onde:

CARÁTER DESCRIÇÃO
Constante que identifica o objeto como não pertencente ao
Z
padrão “standard” do R/3.
Seqüência numérica para a identificação do objeto. Variando de
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:

CARÁTER DESCRIÇÃO
Constante que identifica o objeto como não pertencente ao
Z
padrão “standard” do R/3.
B Constante que identifica o objeto como pasta de Batch Input.
MM Identificação do módulo funcional a qual o programa se destina.
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

Os objetos ABAP desse grupo estão relacionados, com as respectivas


dimensões, conforme a tabela abaixo:

OBJETO RELEASE 4.X


Modelo de Dados 26 caracteres

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


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:

CARÁTER DESCRIÇÃO
Constante que identifica o objeto como não pertencente ao
Z
padrão “standard” do R/3.
J Constante que identifica o objeto como modelo de dados.
MM Identificação do módulo funcional a qual o programa se destina.
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.8.2. TIPO DE ENTIDADE

O padrão a ser utilizado na nomenclatura do objeto ‘TIPO DE


ENTIDADE’ corresponde a forma ZQMM_ID. Onde:

CARÁTER DESCRIÇÃO
Constante que identifica o objeto como não pertencente ao
Z
padrão “standard” do R/3.
Q Constante que identifica o objeto como modelo de dados.
MM Identificação do módulo funcional a qual o programa se destina.
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’ ( _ ).

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


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:

CARÁTER DESCRIÇÃO
Constante que identifica o objeto como não pertencente ao
Z
padrão “standard” do R/3.
Constante que identifica o objeto como categoria de objeto
W
business.
MM Identificação do módulo funcional a qual o programa se destina.
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’ ( _ ).

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.

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


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.

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


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

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


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.

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


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.

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


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

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


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.

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


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

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


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.

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


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

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


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

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


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.doc Página 48 de 48