Workshop para Desenvolvedores ABAP/4

Sumário
Workshop para desenvolvedores ABAP/4 1

Conceito breve do SAP................................................................................................3
Criação de Listas Básicas...............................................................................57
Criação de Listas Complexas.........................................................................62
Criando Tabelas Internas (Estruturas Complexas de Armazenagem
Temporária)...........................................................................................................73
CRIANDO PROGRAMAS..........................................................................................91
ATRIBUTOS DO PROGRAMA..................................................................................91
UTILIZANDO CAMPOS DO DICIONARIO ABAP............................................92
DEFININDO O FLOW CONTROL.....................................................................94
CRIANDO UMA SEQUENCIA DE TELAS........................................................95
DEFININDO CAMPOS NO MODULE POOL....................................................96
CRIANDO MODULES ABAP............................................................................96
O PROCESSAMENTO DO MODULE POOL....................................................96
DEFININDO CHAMADAS VIA TRANSAÇÃO..................................................97
Utilizando SAPSCRIPT............................................................................................113
Header......................................................................................................................114
Basic Setting ............................................................................................................115
Page.........................................................................................................................116
Windows...................................................................................................................117
Page Windows.........................................................................................................118
Parágrafo..................................................................................................................122
Tabs..........................................................................................................................123
Text Elements...........................................................................................................124
Criação de Bordas....................................................................................................125
Ativando SAPSCRIPT..............................................................................................126
Testando SAPSCRIPT.............................................................................................126
O Relatório...............................................................................................................126

1- Overview ABAP/4
Conceito breve do SAP
O SAP é um sistema que trabalha com um número muito grande de tabelas

interligadas, que armazenam e manipulam os valores de controle dos processos.
Essas tabelas são responsáveis pelo armazenamento dos valores do sistema e são
divididas em grupos que se interligam em um todo. Assim, existem tabelas
responsáveis pelas informações de FI, outras pelas informações de SD, outras
ainda por MM, mas todas elas apresentam campos chaves que permitem, pelos
mais diferentes e complicados caminhos, a interligação e consistência de todo o
sistema. Embora a ferramenta ABAP/4 dentro do SAP seja muito poderosa e
praticamente capaz de permitir qualquer customização do sistema, é muito
importante manter os conceitos originais sempre em mente, e nunca tentar forçar
alguma coisa que deveria ter um comportamento natural. Por exemplo, nunca tente
alterar um valor de uma tabela do SAP (embora perfeitamente possível, com o
comando UPDATE), sem um minucioso estudo de suas implicações anteriormente.
Isso pode comprometer a integridade dos dados do sistema, se não forem
atualizados todos os valores de todas as tabelas relacionadas a essa alteração.
ABAP é a linguagem de programação que a SAP criou para desenvolver as

aplicações do R/3, é focada em tarefas comerciais específicas e é totalmente
voltada para atender as necessidades dos usuários deste software, como:
processamento de dados em massa, moeda especifica, múltiplos idiomas, etc.

O ambiente de desenvolvimento é muito eficiente no trabalho em equipe, os
desenvolvedores não precisam se preocupar com quaisquer problemas de
comunicação ou de distribuição entre os diferentes níveis (camadas) do software.
Falando em banco de dados o ABAP também tem suas particularidades, o

desenvolvedor não necessita conhecer o banco no qual está rodando o R/3
( trabalha com vários bancos relacionais), apenas cabe ao programador conhecer o
Open SQL, que é uma definição especial de comando para acesso ao banco de
dados.
A área de trabalho dos desenvolvedores é chamada de ABAP Workbench e

todos os objetos de desenvolvimento criados com as ferramentas do ABAP
Workbench são classificadas como objetos do repository. O Repository é uma
parte do banco de dados central do R/3 e está organizado por aplicações e dentro
das aplicações ainda encontramos uma outra subdivisão denominada Classes de
Desenvolvimento. Todo desenvolvimento do ABAP Workbench tem que estar
relacionado obrigatoriamente a uma aplicação e a uma Classe de Desenvolvimento.
1- Overview ABAP/4
Transações
Transação é um código alfanumérico de 20 caracteres, utilizado para iniciar

um processo dentro do sistema SAP. Todo e qualquer processo ou parte dele deve
ser executado dentro do sistema através de uma transação. Na customização de
ABAP/4, sempre que um GAP do sistema é coberto, isso gera pelo menos uma
transação, de modo que o usuário possa executar esse produto customizado de
dentro do sistema.
Toda operação realizada através do menu do sistema, também corresponde a
uma transação. Um método para conhecermos o código de uma transação cujo
caminho pelo menu é sabido, é entrarmos na mesma, e na tela inicial desta
transação, utilizarmos o menu Sistema  Status, que informa o programa tela e
transação executados.
No desenvolvimento de customizações ABAP/4, as principais transações
utilizadas, são:
• ABAP Editor (SE38) – para escrita e edição de programas, mais utilizado

para desenvolvimentos de programas do tipo executável (Relatórios e
Cargas).
• ABAP Dictionary (SE11) – para edição de objetos relacionados com o
banco de dados e objetos específicos da aplicação.
• Menu Painter (SE41) – para desenho de interfaces de usuário (barra de
menu, ferramentas standard e ferramentas de aplicação).

• Screen Painter (SE51) – para desenho de telas para diálogo de usuário, não
é utilizado para criação de telas de seleção.
• Function Builder (SE37) – para programação de módulos de funções (sub-
rotinas, com interface fixa que estão disponíveis em todo o sistema).
• Repository Browser (SE80) – integra todas as ferramentas do ABAP
Workbench, muito utilizado para criação de programas do tipo on-line ou
module pool, pois, facilita e muito a visualização de todos os objetos em
uma mesma tela. Todo objeto do ABAP Workbench pode ser editado nessa
transação e de uma forma bem mais organizada.
O ambiente de trabalho do ABAP normalmente funciona da seguinte maneira:
• Ambiente de Desenvolvimento ( Client desenvolvimento ABAP e

Client de customizações funcionais/Testes ).
• Ambiente de Qualidade ( onde são feitos os testes de usuários para
aprovação final).
• Ambiente de Produção ( onde realmente os dados da empresa estão
sendo processados).
1- Overview ABAP/4
A área do desenvolvedor ABAP, isto é, o local onde ele irá criar seus objetos
será no Ambiente de Desenvolvimento no client específico para isso, os objetos
criados ali são amarrados a uma Classe de desenvolvimento e também a uma
Change Request/Task (normalmente o gerente de projeto cria uma request onde
serão amarradas as Tasks do projeto). No final do projeto cada desenvolvedor
libera sua Task para ser transportada e o Gerente após todas as Tasks liberadas
pode liberar a Request, nesse ponto entra em ação o pessoal de BASIS que
executam o transporte dessa Request para o outro ambiente QA e após os testes
feitos e aprovados transporta-se para a PRD.
Instância X Client
Também é muito importante o conceito do funcionamento do ambiente do
sistema durante a evolução de um projeto. Inicialmente devemos entender os
conceitos de client e instância:
Client – é definido como sendo uma unidade independente do R/3, em termos
comerciais, organizacionais e técnicos. Isso significa que possuem sua própria
configuração, dados de aplicação e dados cadastrais (master data).
Instância – é definida como um ambiente do R/3 que agrupa um ou mais
clients, onde se executa um determinado trabalho.
Uma instância de trabalho, geralmente possui mais de um client, onde são
trabalhados simultaneamente diferentes frentes de trabalho do projeto. A intenção

dessa divisão é que se possa trabalhar somando valores, sem que haja conflitos de
interesse. Por exemplo, durante um projeto, o client para desenvolvimento das
customizações de ABAP deve ser diferente dos outros, pois trabalha muito com
testes e alterações constantes, o que inviabiliza outros tipos de serviços.
Se essa divisão muitas vezes ajuda, algumas vezes atrapalha. Geralmente
as massas de dados são diferentes nos clients, e o comportamento principalmente
nos testes dos produtos customizados pode ser diferente. O recomendado pela
própria SAP é que exista um client só para testes, com massa de dados completa
que permita “recarga” sempre que necessário, o que permitiria que as condições de
teste pudessem ser repetidas. No dia a dia de um projeto isso é muito difícil, pois a
manutenção desses clients pelo time de basis geralmente não é muito bem vista.
As instâncias variam também ao longo de um projeto. A medida que o
sistema vai sendo refinado, geralmente se inicia uma nova instância livre dos vícios
e restos de testes da anterior. Pelo menos 3 instâncias sempre existem durante o
período de um projeto. A instância de desenvolvimento,
a de pré-produção e finalmente a de produção. Cada vez que o sistema é

migrado de uma instância para a outra, somente deve ser aproveitado o que está
comprovadamente funcionando na instância anterior, de modo a diminuir os erros a
cada migração.
1- Overview ABAP/4
Client dependent/independent
Esse conceito de objeto client dependent e client independent é necessário

estar bem claro, como a base de desenvolvimento normalmente é dividida em client
ou mandante alguns objetos quando desenvolvidos em um determinado client
somente são enxergados ali (para esses casos é necessário fazer transporte entre
clients) e outros são enxergados em todos os clients do ambiente, abaixo está uma
relação de objetos para facilitar:
• Código fonte de programas – Independent

• Telas, Menus e Funções - Independent
• Estrutura de tabela, elemento de dados e domínios – Independent
• Registro de dados da tabela – Dependent
• Objetos de Textos, Formulário SapScript - Dependent
Particularidades.
Os programas e outros objetos do repositório criados pelo cliente devem estar

no namespace de cliente, ou seja, seus nomes devem começar com as letras Z ou
Y (com exceção dos campos em append structures, que devem começar por ZZ ou
YY). Os clientes só devem alterar objetos com nomes fora dessa especificação

quando expressamente orientados pela SAP a fazê-lo (por exemplo, para aplicar
notas de correção). A SAP garante que os programas desenvolvidos pelos clientes
que observarem as especificações de namespace não serão afetados quando
houver uma atualização do sistema, como uma aplicação de Support Package. No
entanto, caso seja alterado um programa standard da SAP, não há garantias de
que o programa alterado permanecerá como tal após qualquer modificação no
sistema. Para agregar funcionalidades a programas da SAP, existe o recurso das
User Exits.
2 – Request
Ordens (Change Requests): Recurso através do qual um conjunto de

objetos C.D. ou C.I. que podem ser transferidos de um client para outro ou de
uma instância para outra.
Utilizam-se ordens para segurança na alteração de objetos já existentes,
sejam eles standards do SAP ou customizados, e para efetuar controle de
versões destes objetos.
A nomenclatura das ordens é controlada pelo próprio SAP, que promove a
criação do código do transporte, no momento em que a manutenção de objetos
específicos exige que o mesmo seja associado a uma ordem.
Geração de Arquivo de Controle (Interno SAP)

Número do transporte
AF1K900109
Objeto SAP (Interno SAP)

Instância

Tipos de Objetos: Locais ou Transportáveis
Ordens e Tarefas (Tasks): Cada ordem pode possuir uma ou mais Tasks.
Cada Task possui os objetos agrupados de acordo com seu tipo e ordem na qual
deverão ser criados no Cliente de destino.
Padronização ABAP Factory :
Ordem: 1 programa + objetos associados

OU
1 alteração de programa + objetos associados
Descrição da ordem:
nome_da_tarefa ou nome_do_produto - Geração Inicial

nome_da_tarefa ou nome_do_produto - 1a Correção …
2 – Request
Controlando e Administrando Transportes
Uma ordem criada por um determinado usuário garante que os objetos a ele
associados ficam “reservados” para tal usuário e somente serão liberados no
momento que a ordem for encerrada.
Quando uma ordem ainda permanece associado a um usuário, dizemos que

ele está com o status de Modifiable.
Quando uma ordem é encerrada, deixa de estar associado a um usuário e

passa a ter o status de Released (liberada), ou seja, os objetos a ela associados
são liberados para alteração por outros usuários.
Enquanto uma ordem possui o status Modifiable, pode-se manipular seus

objetos livrevente, mudar o usuário responsável transferindo a responsabilidade, ou
simplesmente eliminar a ordem, liberando assim seus objetos, ao passo que uma
ordem liberada é algo imutável.
Transação SE01  Permite verificar o conteúdo das ordens (objetos) e sua Log
de transporte (sucessos, erros ou warnings) para os outros clientes e instâncias.

Transação SE09  Permite verificar as ordens de objetos Client Independent
(Workbench Organizer) criados por um determinado usuário, bem como efetuar o
Release de tasks e da ordem em si.
Transação SE10  Permite verificar os transportes de objetos Client Dependent e

Client Independent (Customizing Organizer) criados por um determinado usuário,
bem como efetuar o Release de tasks e do transporte em si.
Tais transações fornecem informações para que criemos a planilha de controle

das ordens criadas e transportadas dentro de um projeto, permitindo assim,
conhecermos o histórico da criação e transporte dos objetos entre as várias
instâncias.
2 – Request
Workbench Organizer
Esta transação permite controlar as ordens (requests) geradas através das

alterações feitas nos objetos ABAP.
As alterações são sempre registradas em ordens do tipo local e transportável.
Ordem tranportável: Alterações transportáveis para objetos do ABAP/4

Development Workbench são gravados em ordens transportáveis. Isto permite que
as ordens possam ser enviadas ao demais ambientes do SAP, cada ordem gerada
para um objeto ABAP/4 consiste em uma nova versão para este objeto, permitindo
assim comparar, verificar e consolidar as alterações entre os ambientes de
desenvolvimento e produção.
Ordem Local: Alterações não transportáveis para objetos do ABAP/4 Development

Workbench são gravados em ordens locais. Isto garante que as ordens estão
sujeitas ao mesmo tipo de controle aplicado aos objetos transportáveis. Da mesma
forma, quando uma ordem local é liberada são criadas versões para o objeto.

Nesta opção podemos acompanhar o transporte de todas as requests que
foram liberadas
2 – Request
Clicando no botão de transportes podemos acompanhar todas as requests do

tipo Desenvolvimento/Correção.

Toda alteração em objetos standard é feita em request’s do tipo Reparação.
2 – Request
Acessando pelo menu Ordem/tarefa  Procurar Ordens, podemos efetuar

pesquisas nas request do sistema.

Clicando no botão de seleção de valores na seção Tipo de Ordem podemos
selecionar os tipos de change request que serão pesquisados.
3 - Dicionário de Dados - Introdução
Conceitos de Bancos de Dados Relacionais

Modelo Entidade-Relacionamento
Modelo desenvolvido para facilitar o projeto de banco de dados, permitindo a

especificação de um esquema que represente a estrutura lógica global de um banco
de dados.
Entidade: É um objeto que existe e é distinguível de outros objetos, ou seja,

identifica o agrupamento de objetos do mesmo tipo. Exemplos: Clientes, Bancos,
Agências, Contas-Corrente.
Atributos: São os qualificadores de uma entidade, isto é, representam no modelo

o que uma entidade pretende ser. Exemplos: Nome, RG, CPF, Endereço, Nro
Conta, Nro Agência, Nro Banco
Domínio: Conjunto de valores permissíveis para um atributo. Exemplo: Estado

Civil, Sexo, Cor, Meses do Ano.
Relacionamento: É a associação entre duas entidades, ou seja, representa a

maneira como duas entidades estão relacionadas ou ligadas. Exemplos: Conta-
Corrente de um Cliente, Agências de um Banco, Contas-Corrente de uma Agência.
Restrições de Mapeamento: Representam o modo como as diferentes entidades

de um modelo se relacionam. Determinadas pela cardinalidade dos
relacionamentos entre as entidades.
Um-para-Um: Uma ocorrência da Entidade A está relacionada com uma e apenas

uma ocorrência da Entidade B.
Um-para-N: Uma ocorrência da Entidade A está relacionada com uma ou várias

ocorrências da Entidade B.
N-para-Um: Várias ocorrências da Entidade A estão relacionadas com apenas uma

ocorrência da Entidade B.
N-para-N: Várias ocorrências da Entidade A está relacionada com várias

ocorrências da Entidade B.Modelo Relacional
Um banco de Dados Relacional é a implementação física do Modelo Entidade-

Relacionamento e traduz concretamente o que o modelo conceitual procura
representar. Consiste em uma coleção de tabelas cada uma das quais associada a

um nome único e que possuem relacionamentos entre si. Tabelas representam
fisicamente as Entidades.
Cada tabela possui uma estrutura similar àquilo que pretende a representar,
isto é, tabelas são formadas de linhas que por sua vez são formadas por colunas.
Colunas representam fisicamente os Atributos.
A cada linha da tabela chamamos de Ocorrência e o conjunto de ocorrências

pode ou não estar relacionado com ocorrências de outras tabelas.
Como distinguir as ocorrências umas das outras?
Utilizando o conceito de Chave Primária!!
Chave Primária: Conjunto de atributos que garante a unicidade de cada ocorrência

da tabela. Exemplos: RG, CPF, Nro Chassis.
Normalização: Processo de reconhecimento da chave primária
Como representar os relacionamentos entre tabelas?
Transferindo a chave primária de uma tabela para a outra!!
Chave Estrangeira: Quando a chave primária de uma tabela é um atributo em

outra(s) tabela(s).
O dicionário ABAP (transação SE11) permite a administração central de todas

as definições de dados do R/3, permitindo a criação de tipos de dados definidos

pelo usuário para uso posterior, além de vários itens auxiliares ao desenvolvimento
de programas (p.ex. search helps).
Podem ser definidas tabelas e visões dentro do dicionário. O R/3 se
encarrega, durante a ativação desses elementos, de criá-los no banco de dados. O
dicionário permite, ainda, a criação de índices, que agilizam as buscas. A definição
de índices apropriados é de suma importância para o bom desempenho do sistema.
Cabe lembrar que uma busca sem índice realizada em uma tabela extensa pode ter
pesado custo em termos de performance.
As definições de tipos de dados dentro do R/3 incluem os elementos de
dados, que definem um tipo elementar descrevendo o tipo básico de dados, o
comprimento e, eventualmente, as casas decimais; as estruturas, que podem
receber elementos de vários tipos (semelhante à representação de um registro
numa tabela); e os table types, que seriam “campos” em formato de tabela. Por
exemplo, uma estrutura do registro de uma estrutura de usuário que tivesse um
campo para números de telefone poderia usar um table type e permitir colocar
vários números num mesmo campo.
Além dessas definições, o dicionário ABAP permite criar os search helps, que
são tabelas de busca auxiliares aos campos de tela – são as buscas e tabelas que
aparecem quando se tecla F4 dentro de um campo em qualquer tela do R/3.
Criando documentação para o elemento de dados dentro do dicionário,
automaticamente está disponível a ajuda do campo, que pode ser invocada
usando-se a tecla F1 dentro dos campos de tela. Pode-se, ainda, definir
verificações de entrada automaticamente, bastando definir uma relação de foreign
key.
No dicionário também são criados os objetos de lock, que permitem definir o
travamento de dados dentro do R/3. Por exemplo, podem-se definir objetos de lock
para impedir que dois usuários editem a mesma informação ao mesmo tempo no
sistema.
O dicionário é integrado às ferramentas de desenvolvimento e execução do
R/3, permitindo o acesso das ferramentas às definições nele contidas. Por exemplo,
é possível navegar de um programa que esteja sendo criado no editor ABAP para
definições de campos, elementos e tabelas usadas no programa.
3 - Dicionário de Dados - Tipos de Dados
1. Dados elementares pré-definidos

Detalhes básicos dos tipos mais utilizados e exemplos de utilização:
• I - campos numéricos sem decimais, contadores, etc.

• P – campos numéricos com decimais, quantidade e moeda. Tomar cuidado
com cálculos feitos entre campos com número de casas decimais diferentes.
• C – campo alfa, mais utilizado para conter textos, pode conter números e até
efetuar cálculos, mas não é usual.
• N – campo alfa, utilizado para conter números sem decimais e preenchidos
com zero a esquerda.
• D – campo data, é armazenado no banco de dados no formato AAAAMMDD,
é mostrado em tela de acordo com a customização de cada usuário, permite-
se fazer contas do tipo “20041201 + 31 = 20050101”.
• T - campo hora, é armazenado no banco de dados no formato HHMMSS, é
mostrado em tela de acordo com a customização de cada usuário.
2. Dados definidos no programa

Entre as formas de tipos de dados mostrados acima, as mais usadas no
desenvolvimento de programas ABAP/4 são:
• 1 - Estrutura: consiste em vários campos com tipos de dados

elementares e tem tamanho fixo. (array)
• 3 – Tabela Interna: é uma estrutura que pode variar em tamanho, no que
diz respeito a linhas. (matriz)
• Os outros tipos acima, são variações dos dois já explicados e muito
pouco utilizados nos programas.
Exemplos:
TYPES: number TYPE i,

length TYPE p DECIMAL 2,
code(3) TYPE c.
TYPES: BEGIN OF <estrutura>,

<campos>…..
END OF <estrutura>.
3. Tipo de dados do Dicionário de Dados ABAP.

Transação – SE11
• Elemento de Dados: é a definição semântica para um campo individual, nele

colocamos os textos do campo e amarramos a um domínio.
• Domínio: e a definição técnica do campo, onde colocamos o tipo de dados, o

tamanho do campo e tabela de valores possíveis.
• Estrutura: São conjuntos de campos elementares ou do próprio tipo

estrutura e são utilizadas para referências em tela ou no programa.
• Tabela Transparente (database table): São as tabelas que possuem uma

estrutura criada no dicionário de dados e que são refletidas no banco de
dados, são elas que contém os dados necessários para o sistema, através
de instruções do ABAP OPEN SQL conseguimos obter essas informações.
• Visões: São agrupamentos de <n> tabelas transparentes que possuem

ligações entre si, funciona como se fosse um INNER JOIN só que já está pré-
criado no dicionário de dados, pode ser utilizada no SELECT como se fosse
uma tabela normal.
3 - Dicionário de Dados – Definições
Definição de tabelas transparentes

Uma tabela consiste de colunas (campos) e linhas (registros). Cada tabela
possui um nome e atributos, como por exemplo, a classe de desenvolvimento e a
autorização para manutenção. Cada campo deve ter um nome único dentro da
tabela, e pode fazer parte de uma chave. Cada tabela deve ter uma chave
primária, que é composta por campos cujos valores identificam unicamente os
registros de uma tabela. As tabelas definidas no dicionário de dados do R/3 são
criadas no banco de dados assim que ativadas.
Durante a ativação, a descrição da tabela dentro do dicionário é traduzida para
a definição de tabela correspondente na linguagem do banco de dados que estiver
sendo usado. A ordem dos campos no banco de dados não precisa seguir a ordem
estabelecida no dicionário de dados (com exceção dos campos de chave primária),
o que permite a extensão das tabelas standard do R/3 através e append
structures, que são definições de campos adicionais definíveis pelo usuário sem
haver a necessidade de alteração da definição normal da tabela Standard. Os
includes são estruturas definidas separadamente que podem ser inseridas em
outras tabelas.
Entendendo melhor: Elemento de Dados e Domínio

Basicamente, as tabelas dentro do R/3 são compostas de campos, cada um
usando um determinado elemento de dados, que por sua vez usam domínios. O
domínio define o tipo básico de dados, seu comprimento e o intervalo de valores
permitido; o elemento de dados descreve o significado de um domínio dentro de um
determinado cenário. Por exemplo, um campo de código de aeroporto de destino
deve estar ligado a um elemento de dados “aeroporto de destino”, que por sua vez
usa um domínio “código de aeroporto”, que está definido como três posições de
caractere, apenas com letras.

As características técnicas das tabelas do R/3
Quando uma tabela é definida no dicionário de dados do R/3, devem ser

definidas as características técnicas (technical settings) para a tabela. Essas
características são usadas para otimizar o acesso e a armazenagem da tabela
individualmente.
As características técnicas podem ser usadas para definir como a tabela deve
ser manipulada quando for criada no banco de dados, se ela deve ser incluída em
buffer e de que forma, e se as mudanças nela realizadas devem ser registradas em
log.
Para definir a armazenagem da tabela, deve-se indicar uma classe de dados.
Essa classe de dados determina de que forma o banco de dados deve armazená-la.
As classes principais são master data, transaction data, organizational data e
system data. Os dados mestres devem ser classificados como master data, os
dados transacionais como transaction data, a configuração funcional como
organizational data e os dados de sistema como system data. Geralmente, dentro
de um projeto, são criadas tabelas dos tipos master e transaction somente. De
posse dessa informação, o R/3 separa as tabelas em diferentes arquivos do banco
de dados de forma a otimizar a performance.
A categoria de tamanho das tabelas permite ao R/3 alocar espaço no banco
de dados de acordo com o tamanho projetado para a tabela, de modo a evitar
fragmentação dos dados.
Pode-se definir que uma determinada tabela será armazenada em buffer de
memória. Com isso, o acesso à tabela é otimizado, mas deve-se usar de bom senso
para colocar tabelas em buffer. Por exemplo, tabelas candidatas a entrar no buffer
são dados mestres com muita utilização e raramente atualizadas. Tabelas de dados
transacionais não devem ser colocadas em buffer, pois cada registro dentro delas é
menos freqüentemente acessado que nas tabelas de dados mestres, e estão
sujeitos a atualizações. A atualização de uma tabela que esteja no buffer provoca
seu re-carregamento com conseqüente impacto no desempenho dos programas.
O buffer pode ser definido nos modos full, no qual a tabela inteira é colocada
no buffer, single-record, onde apenas os registros eventualmente acessados são
colocados no buffer, e generic, no qual são colocados no buffer registros que
tenham determinados valores na chave. Os dados não são automaticamente
colocados no buffer assim que o sistema entra no ar; isso só acontecerá no primeiro
acesso a um registro que esteja em um intervalo de buffer.
Caso seja necessário, pode-se definir o registro em log das alterações feitas
numa tabela. Porém, deve-se ter em mente que isso pode criar um impacto na
performance do sistema.
3 - Dicionário de Dados – Visibilidade e Referência
Visibilidade dos Tipos de Dados

Conceito “LIKE”
Eu utilizo o comando LIKE na criação de um tipo de dados dentro do programa

ABAP para referenciar diretamente o objeto a um tipo de dados do Dicionário de
Dados ABAP, isto é muito utilizado, pois, se eu estou trabalhando com um campo
que é reflexo de um campo que já existe em uma tabela transparente eu não
preciso descobrir o tipo e tamanho do campo para defini-lo no programa basta eu
referenciá-lo utilizando LIKE.
Exemplos:
Type: <t> LIKE <obj>.

Exemplo Criação de Tabela, Manutenção e criação de transação
Criando uma tabela transparente customizada (tcode SE11). Por exemplo

ZCONTROLE.
Definir as características da tabela transparente.
Definir a estrutura da tabela (campos, data elements e domínios) e salvá-la.

Atribuir as opções
técnicas.
Definir as opções técnicas e <Salvar>.
Ao final ativar a nova tabela criada.
COMO CRIAR A MANUTENÇÃO DA TABELA CUSTOMIZADA

Agora vamos definir a manutenção da tabela transparente. Para acessar o “Gerador
de atualização de tabela”, selecionar no menu Utilitários conforme descrito abaixo.
Definir os parâmetros de manipulação da tabela transparente.
Definir o Grupo de Função a ser utilizado pelo Repository Object (tcode SE80).
Selecionar o
objeto.

Definir as características do objeto Grupo de Função.
Selecionar a “Classe de Desenvolvimento” a ser utilizado e <Salvar>.
Criar uma nova Request e Avançar <Enter>.
O grupo de função definido será criado na classe de desenvolvimento.
Criar novo
objeto.
O novo Grupo de Função

foi definido.
Este botão permite o

sistema sugerir as telas
Workshop para desenvolvedores ABAP/4 de atualização a serem 26
utilizadas.
Pode ser utilizado telas de
atualização de duas
categorias:
apenas um nível (apresenta a
síntese da tabela e a alteração
da entrada de dados é
efetuada nesta tela mesmo);
2 níveis: um nível de tela de
síntese e uma tela seguinte
somente para alterar a entrada
de dados.
Para que o usuário tenha acesso a manutenção da tabela customizada, utilizar o

caminho apresentado abaixo.

Nesta tela de visão de tabelas é possível efetuar a atualização de dados.
Esta tela de atualização é a “tela de síntese” (o 1º nível de acesso definido na

geração de manutenção).
Permite o cadastramento
de dados novos na tabela.

Esta tela de atualização é a “tela individual” (o 2º nível de acesso definido na
geração de manutenção).
A seguir é apresentado a entrada efetuada na tabela pela tela de atualização

individual.

PARA ACESSAR A MANUTENÇÃO DA TABELA VIA TRANSAÇÃO
CUSTOMIZADA.
Criar uma nova transação pelo Repository Object (tcode SE80).
Selecionar a opção de “transação c/parâmetros”.

Definir as características da transação.
Utilizar a transação
para “Atualização
de tabela ampliada”.
Definir também a tabela a ser acessada.
Definir os parâmetros
da tabela a ser
atualizada .
Selecionar a “Classe de Desenvolvimento” a ser utilizado e <Salvar>.
Criar uma nova Request e Avançar <Enter>.
4- Editor ABAP

Editor ABAP/4
O editor de programação ABAP/4 do SAP pode ser encontrado através do

caminho :
Menu SAP  Ferramentas  ABAP Workbench  Desenvolvimento  Editor

Abap

4- Editor ABAP
ou pela transação SE38.
Uma tela para a entrada do nome do programa é aberta, como exemplificada

abaixo. Para criar um programa novo, utilize um nome ainda não existente no
repositório, e apertar o botão Criar. Para editar ou exibir um programa já existente,
entrar com o nome do programa e apertar os botões respectivos.
Existe um padrão de nomenclatura que deve ser seguido, não só para nome
de programas, mas para todos os desenvolvimentos no SAP R/3. Esses padrões
podem variar de projeto a projeto e principalmente com a versão do SAP com a qual
se está trabalhando. Em todos os casos os nomes dos desenvolvimentos começam
sempre com Z ou Y.
Antes de iniciarmos o estudo dos Reports, devemos entender primeiro o

conceito de Report dentro do SAP. Apesar do nome indicar que são relatórios,
Report tem uma abrangência maior do que isso. Devemos entendê-los como
programas, que são capazes de fazer muito mais coisas do que exibir relatórios.

4- Editor ABAP
No editor ABAP, além de digitar o código fonte do programa, é possível

também efetuar outras tarefas e adicionar outros objetos inerentes à sua execução.
Na janela de “Objetos parciais” há 5 opções básicas de objetos associados a

um programa ABAP:
Texto fonte: Através desta opção acionamos o editor de programas ABAP.
Variantes: Definem-se os valores pré-definidos para os parâmetros de execução de

um programa ABAP. Os parâmetros de um programa são definidos pelos comandos
Parameters e Select-options do ABAP.
Atributos: Definem-se os atributos de programa, como classe de desenvolvimento,

título, categoria, status, aplicação, etc.
Documentação: Texto com uma descrição breve do que o programa executa e as

suas condições necessárias para execução.
Elementos de texto: Definem-se os textos que serão relacionados às mensagens,

rótulos de parâmetros do programa e títulos e nome de colunas para o relatório
gerado pelo programa.
Criando um programa passo-a-passo.
Entrar no editor ABAP na transação SE38, preencher o nome do programa

começando com “Z”, clicar em create.
Entra do código fonte
Para editar variantes de execução do programa
Editar os atributos do Programa
Alterar os Textos dos Parâmetros de Seleção

4- Editor ABAP
Aplicação: Você entra com o

módulo ou a aplicação que o
programa faz parte
Clicar em SAVE
Logo após entrar com os atributos do programa, entrar com a Classe de

Desenvolvimento/Package (perguntar para o gerente qual classe de
desenvolvimento se não estiver na especificação)
Entrar com a Classe

de Desenvolvimento
SAVE – para
amarrar a uma
Objeto Local –
Request/Task
quando não vou
transportar –
somente teste
Quando a escolha for SAVE/SALVAR, deve-se entrar com a REQUEST/TASK.

4- Editor ABAP
Clicar aqui ou tecla F4,

para escolher uma
Request já criada
OK – após
escolher Req. Clicar em Criar – quando for amarrar em
uma nova request
Para evitar maiores problemas crie um habito de salvar – verificar – ativar.
1º - Salvar
Prestar atenção no
Status, sempre deixar
active, se for feita uma
Testar – para alteração e salva, mas
2º - Verificar, faz 3º - Ativar, execução do não ativa, o depurador
a verificação de ativa a programa direto considera a última ativa.
sintaxe. versão atual do código fonte
Verificação de sintaxe é muito importante ir verificando a sintaxe sempre, pois,

isso facilita para encontrar os erros, caso dê algum erro na verificação de sintaxe
aparecerá da seguinte forma.
Caso ocorra algum erro

na verificação de sintaxe,
aparecerá assim. O(s)
erro(s) logo abaixo do
Para ir direto na linha código fonte.
que está acusando
erro clicar aqui

4- Editor ABAP
Criando telas de Seleção:
SELECTION-SCREEN: comando utilizado para definir a tela de seleção, com ele

pode se criar blocos dentro de uma mesma tela, incluir frames com textos
explicativos, etc.
PARAMETER: è utilizado para criação de um campo único de seleção, obter as

suas variações de sintaxe através do help (F1).
SELECTION-SCREEN BEGIN OF BLOCK bloco3 WITH FRAME TITLE text-003.

PARAMETER: p_num1 TYPE i,
p_sin(1) TYPE c,
p_num2 TYPE i.
PARAMETER: P_MATNR LIKE MARA-MATNR.

SELECTION-SCREEN end of BLOCK bloco3.
OBS: TEXT-003 é uma forma de se incluir textos de uma forma dinâmica, para criar
esses objetos digite text-003, dê dois clicks e se não existir o editor vai perguntar se
você deseja criar. Você entra com o texto na linguagem e depois faz a tradução
para as outras linguagens na transação SE63.
• TYPE: está definindo o tipo da variável de tela de seleção, deve-se entrar

com o tamanho e o tipo do dado a ser armazenado.
• LIKE: está definindo o tipo da variável de tela de seleção por referência,

dizendo que a variável terá o mesmo tipo e tamanho da variável MATNR da
tabela MARA que estão no Dicionário ABAP.
• Utilização no SELECT: para utilização no comando select, usa-se o

comparativo = ou EQ caso o campo esteja em branco ele busca todos os
registros que tenham conteúdo igual a branco.
Where MATNR = P_MATNR.
4- Editor ABAP

SELECT-OPTIONS: è utilizado para criação de um campo de/até de seleção com
várias opções de comparações, obter as suas variações de sintaxe através do help
(F1).
Clicando aqui, você

pode definir várias
comparações a serem
feitas na seleção
TABLES: MARA.
SELECTION-SCREEN BEGIN OF BLOCK bloco4 WITH FRAME TITLE text-004.

SELECT-OPTIONS: S_MATNR FOR MARA-MATNR.
SELECTION-SCREEN end of BLOCK bloco4.
• FOR: Para a opção Select-options utilizasse FOR no lugar do LIKE.
• TABLES: O Comando tables, disponibiliza a estrutura da tabela do banco de

dados, para ser utilizada dentro do programa, é obrigatória essa disponibilização
quando a tabela vai ser utilizada no FOR.
• TABELA DO SELECT-OPTIONS:
SIGN OPTION LOW HIGH

I EQ MATERIAL
I BT 100 200
• Utilização no SELECT: para utilização no comando select, usa-se o

comparativo IN e automaticamente ele já entende o tipo de comparação a fazer,
caso o campo esteja em branco ele busca todos os registros.
Where MATNR IN S_MATNR.
• Para alterar os textos que aparecem na tela de seleção:
Entrar com
os textos
Aqui

Na SE38 – Escolher
opções Elemento de
textos e <Modificar>
4- Editor ABAP
Alguns Comandos:
• DATA: é utilizado para definir uma variável de qualquer tipo (simples, estrutura
ou tabela interna).
DATA: V_num TYPE i.
DATA: v_matnr LIKE mara-matnr.
DATA: s_mara LIKE mara.
DATA: begin of t_mara occurs 0,

matnr LIKE mara-matnr,
end of t_mara.
• IF e CASE: são utilizados como comparativos na lógica do ABAP.

CASE p_sin.
IF p_sin = '+'. Ou WHEN '+'.
v_num = p_num1 + p_num2. v_num = p_num1 + p_num2.
ELSEIF p_sin = '-'. WHEN '-'.
v_num = p_num1 + p_num2. v_num = p_num1 + p_num2.
WHEN OTHERS.
ELSE.
ENDCASE.
ENDIF.
Detalhes:
o No término de toda instrução ABAP, deve ter um ponto final, para evitar
repetições pode-se utilizar “:” após o comando e “,” separando as instruções,
mas, deve terminar com ‘.’
o Quando me referencio a uma string utilizo “ ‘ “ aspas simples.
• MOVE ou “ = “: esses são os comandos de atribuição de valores.
MOVE: 2 to v_num,
'MATERIAL to v_matnr.
ou
v_num = 2.
v_matnr = ‘MATERIAL’.
• WRITE e WRITE ... TO ... : Utilizado para imprimir em tela, pode se também
mover o resultado dessa impressão para dentro de outra variável. Quando se
executa o comando write o ABAP faz todas as traduções necessárias de acordo
com a configuração do usuário (moeda, quantidade). Ver variações com o F1.
write: / v_num. Ou write; v_num to v_aux.

4- Editor ABAP
Executando Programa:
Na SE38 – é só clicar aqui

ou tecla F8 aqui ou dentro
do código fonte
Alguns Exemplos
EXEMPLO 1
REPORT ZEXP0001.
WRITE: '111111'.
WRITE: '222222',
'333333'.
WRITE: /'111111'.
WRITE: 15 '333333'.
WRITE: / TEXT-001.
ULINE.
ULINE 8(6).
SKIP.
SKIP 2.
WRITE : 8 SY-LANGU.
WRITE : / SY-DATUM UNDER SY-LANGU.
Existem alguns tipos de variáveis chamadas de variáveis do sistema. Elas

possuem informações e dados do processamento, como o idioma de acesso (sy-
langu), a data (sy-datum), a hora (sy-uzeit), etc.. Essas informações estão contidas
na estrutura SYST (Campos de sistema ABAP, que pode ser abreviada para SY) e
podem ser acessadas conforme o exemplo acima, o nome da estrutura mais o
campo que se deseja.
EXEMPLO 2
REPORT ZEXC0002 NO STANDARD PAGE HEADING.
WRITE 'PAG 1'.
NEW-PAGE.
WRITE 'PAG 2'.
TOP-OF-PAGE.
WRITE : 'EXEMPLO 2 - CURSO ABAP/4',
80 'Page',
SY-PAGNO.
ULINE.

4- Editor ABAP
EXEMPLO 3
REPORT ZEXP0003.
WRITE : 'NORMAL'.
FORMAT INTENSIFIED OFF.
WRITE : 'NEGRITO '.
FORMAT COLOR 1.
WRITE : 'FUNDO AZUL'.
FORMAT COLOR OFF.
FORMAT INTENSIFIED ON.
WRITE : 'NORMAL'.
EXEMPLO 4
REPORT ZEXP0004.
DATA: NOME(20) TYPE C,

RG(10) TYPE I,
DATA LIKE BKPF-BUDAT,
HORA(8) VALUE '14:05:45'.
MOVE 'Solution Center' TO NOME.

RG = 42159818.
DATA = '19973005'.
SKIP 2.
WRITE: 'Nome:',
NOME,
/ 'RG:',
RG UNDER NOME,
/ 'Data:',
DATA,
/ 'Hora:',
HORA.

4- Editor ABAP
EXEMPLO 5
REPORT ZEXP0005.
PARAMETER: P_NOME1(15) TYPE C,

P_NOME2(15) TYPE C DEFAULT 'Abap Factory',
P_BOTAO1 RADIOBUTTON GROUP G1,
P_BOTAO2 RADIOBUTTON GROUP G1.
WRITE P_NOME1.
IF P_NOME2 NE 'ABAP FACTORY'.

WRITE P_NOME2.
ENDIF.
IF P_BOTAO1 = 'X'.
WRITE / 'BOTÃO 1 ACIONADO'.
ELSE.
WRITE / 'BOTÃO 2 ACIONADO'.
ENDIF.

5- Open SQL
O ABAP oferece um conjunto de comandos que permite realizar operações

com os dados armazenados no banco, o Open SQL. A idéia central do Open SQL é
prover uma linguagem de acesso ao banco independente de plataforma. Os
comandos Open SQL têm de passar pelo interpretador ABAP, que os traduz para
os comandos SQL do banco de dados que esteja sendo utilizado.
Comandos
Dentro do Open SQL, podem-se utilizar os seguintes comandos:
• SELECT: permite a leitura de dados do banco de dados.
• INSERT: insere dados no banco.
• UPDATE: atualiza dados.
• MODIFY: atualiza dados existentes ou os acrescenta caso não

existam no banco.
• DELETE: apaga registros do banco de dados.
• OPEN CURSOR, FETCH, CLOSE CURSOR: respectivamente cria, lê e fecha

um cursor dentro do banco de dados.
Campos de sistema
Os dois principais campos de sistema envolvidos em operações do Open SQL

são o SY-SUBRC, que retorna zero caso a operação tenha sido bem-sucedida, e o
SY-DBCNT, que retorna o número de registros afetados pelo comando.
Trabalhando com os Mandantes
Num comando Open-SQL não é necessário especificar o mandante nas

cláusulas discriminadoras dos comandos. Automaticamente, o interpretador ABAP
definirá o mandante como o mandante atual, a não ser que seja especificada a
opção CLIENT SPECIFIED.

5- Open SQL
SELECT
O comando SELECT retorna um conjunto de dados (registros) que atendam a

um determinado critério. As cláusulas do comando SELECT são as seguintes:
• SELECT <lista de campos>: Pode-se selecionar uma lista de campos a

serem retornados, separados por espaços, ou o caractere * para retornar
todos os campos disponíveis. A opção SINGLE retorna somente um
registro que atenda às restrições impostas. Caso a tabela tenha sido
declarada através de TABLES, é automaticamente criado um registro na
memória com o mesmo nome para manipulá-la; caso o SELECT traga
campos de mais de uma tabela, não é possível utilizar esse artifício.
Nesse caso, as tabelas não precisam ser declaradas em TABLES, mas a
seleção dos campos deve separar o nome da tabela e o campo com um
til (~). Exemplo:
TABLES: SFLIGHT.
DATA: T_SFLIGHT LIKE SFLIGHT.
SELECT CARRID CONNID FLDATE SEATSOCC

FROM SFLIGHT INTO TABLE T_SFLIGHT.
• INTO [<lista de campos>| TABLE <tabela interna>]: Permite armazenar o

retorno numa tabela interna ou em campos definidos com o comando
DATA. O uso de SELECT sem especificar SINGLE ou INTO TABLE
exige o uso de ENDSELECT.
• FROM <tabela> [[INNER|LEFT OUTER] JOIN <tabela>, ..]: Especifica a

origem dos dados.
• FOR ALL ENTRIES Usado quando selecionamos dados de uma

tabela e precisamos de dados de outra tabela para compôr as
condições do where.
SELECT * FROM dtab FOR ALL ENTRIES in itab where…
EXEMPLO:
SELECT * FROM BSEG FOR ALL ENTRIES IN T_BKPF
WHERE BUKRS = T_BKPF-BUKRS
AND BELNR = T_BKPF-BELNR
AND BELNR = T_BKPF-BELNR.
Onde T_BKPF é uma tabela interna que recebeu a tebela BKPF.

5- Open SQL
NOTA: se itab estiver vazia, esse comando selecionará todo o conteúdo da tabela,
pois nenhuma restrição está sendo colocada. Uma maneira de fazer essa
verificação é a seguinte:
IF NOT itab[] IS INITIAL. “ se itab não está vazia

SELECT * FROM dtab FOR ALL ENTRIES in itab
where campo = itab-campo …
ENDIF. “ fim do: se itab não está vazia
• WHERE <condições>: A cláusula WHERE especifica as condições de busca.

Por exemplo, WHERE CARRID = ‘AA’ faz com que apenas os registros
em que o campo CARRID tenha conteúdo igual a ‘AA’ sejam retornados.
Maiores detalhes sobre o comando SELECT podem ser encontrados no

Help On-Line do R/3.
TESTE – SELECT: Para saber se o select encontrou algum registro ou não,

utilizamos uma variável de sistema SY-SUBRC, se o conteúdo dessa variável for 0
encontrou, caso contrário não encontrou nenhum registro. E isso vale para também
para todos os comandos ABAP, quando executado com sucesso SY-SUBRC é igual
a zero.
Se sy-subrc = 4 : nenhum dado foi lido
INSERT: O comando INSERT insere um novo registro no banco de dados, a

partir de uma área de dados especificada em TABLES ou uma área declarada com
DATA. Para usar INSERT, devem-se colocar os dados desejados na área
intermediária e, em seguida, chamar o comando INSERT. Caso a área não seja
especificada em TABLES, deve ser usada a opção FROM:
UPDATE: O comando UPDATE funciona como o comando INSERT, podendo

alterar dados no banco a partir de uma área ou tabela interna. No caso da tabela
interna, não é necessário especificar a cláusula WHERE: serão alterados os
registros correspondentes de acordo com as chaves.
MODIFY: O comando MODIFY opera da mesma forma que o comando

UPDATE, mas insere um novo registro caso o registro especificado não exista.
DELETE: O comando DELETE elimina registros do banco. Ele opera da mesma

forma que o comando INSERT.

5- Open SQL
LUW – COMMIT e ROLLBACK: Quando trabalhamos com alteração nos dados do

banco, é bom sabermos que todas as alterações que estamos fazendo ainda não
aconteceram efetivamente no banco, isso só ocorre quando encontra-se o primeiro
comit, automaticamente quando acaba a execução de um programa já é executado
um commit:
Exemplo:
INSERT <tabela1>.
IF SY-SUBRC = 0.
INSERT <tabela2>.
IF SY-SUBRC = 0.
COMMIT WORK.
ELSE.
ROLLBACK WORK.
ENDIF.
ENDIF.
Considerações sobre os diferentes tipos de select (PERFORMANCE)
1 - SELECT * FROM …<tabela>

(Quando não se impõe nenhum tipo de restrição, ocorre uma varredura sequencial
dos registros da tabela. Quando se utiliza grandes tabelas, isso obviamente afeta o
runtime.
Performance: Select * - seleciona todas as colunas de uma tabela. É melhor

sempre especificar as colunas, pois em caso de tabelas com muitas colunas,
prejudicará a performance).
2 - SELECT * FROM <tabela> WHERE <campo> eq <conteúdo>.

(Lê todos os registros da tabela especificada onde o campo é igual ao conteúdo
especificado)
Performance: Select * Where - seleciona todas as colunas de uma tabela de acordo

com a condição de where. É melhor sempre especificar as colunas, pois em caso
de tabelas com muitas colunas, prejudicará a performance.
3 - SELECT * FROM <table> WHERE <table field> BETWEEN <field1> and

<field2>.
Ex.: field1 = 100 e field2 = 500. Pega inclusive 100 e 500. Você trabalha com o
range.

4 - SELECT * FROM <table> WHERE <table field> LIKE ….’_R%’.
_ = a primeira letra não importa o que virá
a segunda deverá ser R (eu defini)
% = não importa a sequência de caracteres que virá.
5- Open SQL
5 - SELECT * FROM <table> WHERE <table field> IN (…….,…….).

Exemplo: select * from <table> where campo1 in (123,1000) - podem ser valores ou
literais
É como perguntar se campo1 é 123 ou 1000.
6 - SELECT * FROM <table> WHERE <table field> IN <internal table>.

Exemplo:
DATA : begin of ITAB occurs 10,
sign(1), option(2), low like sflight-price, high like sflight-price,
end of ITAB.
* RANGES: ITAB for sflight-table
Move: ’I’ to itab-sign, ‘bt’to itab-option, ‘500’ to itab-low, ‘1000’ to itab-high.
Append itab. Move: ’I’ to itab-sign, ‘bt’to itab-option, ‘440’ to itab-low.
Append itab.
7 - SELECT * FROM <table> ORDER BY <field1> <field2> … PRIMARY KEY.

Obs.: Classifica a tabela interna numa área auxiliar, sem afetar a tabela original.
Evitar o uso de sorts dentro de um select. Consome mais tempo que descarregar os
dados em uma tabela interna e classificá-los.
8 - SELECT * FROM <table> BYPASSING BUFFER.

(Usado para ler diretamente da tabela original, e não do buffer).
OBS.: Select single * sempre com chave completa especificada. Particularidade do

Abap/4
Select * - procurar evitar. Informar as colunas que serão necessárias,
apenas.
Uso de comando extract (insert header, details) – para relatórios
9 - SELECT * FROM <table> APPENDING TABLE <internal table>.

(Lê os registros e os inclui - não sobrepõe - em um internal table).
10 - SELECT …FROM <table> INTO TABLE <INTERNAL TABLE> .

(A estrutura da tabela interna deve corresponder à estrutura da tabela que está
sendo acessada. O sistema lê os registros em conjunto, não individualmente, e os
coloca dentro de uma internal table. Este processo é mais rápido que ler
individualmente através de um LOOP e ir gravando os registros, um a um).

5- Open SQL
11 - SELECT …. INTO CORRESPONDING FIELDS OF TABLE <itab>.

(Neste caso a estrutura da tabela interna não precisa corresponder à estrutura da
tabela que está sendo acessada. <itab> é o nome da internal table. Movimentará os
registros para as colunas definidas na internal table que possuam nome igual ao da
tabela acessada).
Obs.: corresponding ou appending corresponding não exigem o endselect.
12 - SELECT ….. APPENDING CORRESPONDING FIELDS OF TABLE <itab>.

( Lê e grava (não sobrepõe) os dados em uma internal table que possua nomes
idênticos aos nomes da tabela que está sendo lida).
13 - SELECT SINGLE * FROM SPFLI WHERE …..<campo>….. EQ … <conteúdo>

(Toda vez que se usa select single * a chave primária completa deve ser
especificada. Se a chave especificada não é qualificada, você receberá uma
mensagem de warning e a performance ficará prejudicada).
No caso de haver a necessidade de acessar um único registro via select, as opções
são: select * ….. seguido de comando exit OU select * … up to 1 row.
Neste caso não é necessário especificar a chave completa.
14 - SELECT <a1> <a2> … INTO (<f1>, <f2>, … ) FROM ….<tabela>

WHERE …… .
Lê as colunas especificada (a1, a2). Após INTO deverão ser especificadas as áreas
de trabalho auxiliares (f1, f2). O número de colunas lidas deverá ser igual ao
número de work-areas especificadas.
15 - SELECT MAX(campo)
MIN(campo)
AVG(campo)
COUNT(*) FROM <table> INTO (…..,……,…..,….)
WHERE ………… .
AVG e SUM: somente para campos numéricos.

Não se usa endselect.
Mais rápido fazer uma rotina “à mão” que utilizar este comando.
16 - SELECT * FROM SFLIGHT WHERE PRICE IN ITAB.

5- Open SQL
17 - SELECT * FROM (<table>) INTO <work area>.

Exemplo: data: begin of WA,
line(100),
end of WA.
Parameters: tabname(10) default ‘SPFLI’. *** especificando o nome da tabela em
tempo dinamicamente no select statement sempre consome mais tempo de CPU
que especificando estaticamente no programa ***
Select * from (tabname) into WA

Write ….
Endselect.
18-SELECT * FROM <table> FOR ALL ENTRIES IN <internal table> WHERE

campo1 = <conteúdo> and
campo2 = <conteúdo>
Defino uma tabela interna. Alimento os campos desta tabela interna. (move e
append).
No meu select campo1 e campo2 serão os campos definidos e alimentados na
tabela interna.
19 - SELECT carrid MIN( price ) max (price ) INTO (carrid, minimum, maximum)
FROM sflight GROUP BY carrid.
(Todos os campos que eu quero que apareçam na minha lista eu preciso especificar
após a cláusula GROUP BY)
(carrid, maximum e minimum são campos auxiliares).
(Se o nome do database não é conhecido até runtime não se pode especificar a
cláusula GROUP BY).

5- Open SQL
EXEMPLO 6
REPORT ZEXP0006 message-id za.
PARAMETER: P_PAIS LIKE T005S-LAND1.
TABLES T005H.
SELECT * FROM T005H WHERE LAND1 = P_PAIS ORDER BY CITYC.
WRITE: / T005H-Bezei,
T005H-LAND1.
ENDSELECT.
IF SY-SUBRC NE 0.
MESSAGE I000.
ENDIF.

5- Open SQL
EXEMPLO 8
REPORT ZEXP0008 MESSAGE-ID ZA.

TABLES: BKPF.
PARAMETER: P_BELNR LIKE BKPF-BELNR DEFAULT '5000000041',

P_ANO LIKE BKPF-GJAHR DEFAULT ' 2001'.
DATA: ARQ LIKE RLGRAP-FILENAME VALUE 'C:\TEMP\curso.txt'.
DATA: BEGIN OF T_ZCURSO OCCURS 0,
ZDATA LIKE BKPF-BUDAT,
SPACE1 TYPE C VALUE ' ',
ZBELNR LIKE BKPF-BELNR,
ZGJAHR LIKE BKPF-GJAHR.
DATA: END OF T_ZCURSO.
SELECT * FROM BKPF WHERE BELNR = P_BELNR
AND GJAHR = P_ANO.
T_ZCURSO-ZDATA = BKPF-BUDAT.
T_ZCURSO-ZBELNR = BKPF-BELNR.
T_ZCURSO-ZGJAHR = BKPF-GJAHR.
APPEND T_ZCURSO.
ENDSELECT.
IF SY-SUBRC = 0.
CALL FUNCTION 'WS_DOWNLOAD'
EXPORTING
* bin_filesize =''
* codepage =''
FILENAME = ARQ
* filetype =''
* mode =''
* wk1_n_format =''
* WK1_N_SIZE =''
* WK1_T_FORMAT = ' '
* WK1_T_SIZE =''
* col_select =''
* col_selectmask =''
* importing
* filelength =
TABLES
DATA_TAB = T_ZCURSO
* fieldnames =
EXCEPTIONS
FILE_OPEN_ERROR =1
FILE_WRITE_ERROR =2
INVALID_FILESIZE =3
INVALID_TABLE_WIDTH =4
INVALID_TYPE =5
NO_BATCH =6
UNKNOWN_ERROR =7
OTHERS = 8.
MESSAGE E007.
ELSE.
MESSAGE E008.
ENDIF

6- Modularização
Todo programa ABAP é estruturado e desenvolvido para ser processado em

bloco:
• Blocos de processamentos que são chamados pelo sistema:
o Blocos de Eventos
o Módulos de Diálogo
• Blocos de processamentos que são chamados pelo programa.
o Sub-rotinas
o Módulos de função
o Métodos
INCLUDE
Programa do tipo include, pode se modularizar um programa utilizando

códigos fontes não executáveis chamados includes e chama-se esses códigos de
dentro do programa principal. É comumente usado para declarações de variáveis
em programas muito extensos.

6- Modularização
Processamento de Mensagens
MESSAGE <tipo>+<numero>+(<classe mensagens>)
Exemlo: MESSAGE I368(00) with ‘Erro XXXXX’.
Tipos de Mensagem
Sub-rotina - FORM
Para estruturar nossos programas, utilizamos os blocos de processamentos

controlados pelo nosso pr[oprio programa os FORMs, delimitamos as rotinas de
processamentos em pequenos grupos, o que facilita a manutenção de nosso
código. Podemos passar e receber valores para essas rotinas, tanto por parâmetro
como por valor.
START...
PERFORM TESTE123.
END....
FORM TESTE123.
<código fonte com a rotina desejada>
ENDFORM.

6- Modularização
Módulos de Funções
São rotinas de processamento externas e independentes de programa, ficam

amarradas a um grupo de funções e tem o seu código desenvolvidos em
includes,podem ser chamadas por <n> programas diferentes, também trabalham
com passagem de parâmetros e de tabelas, e com exceções (erros no
processamento). Praticamente pouco se cria em matéria de funções, o que mais
fazemos é utilizar as funções prontas disponibilizadas pela SAP.
Sempre que chamamos uma função, é aconselhável utilizar os modelos do

editor ABAP, e também tomar cuidado com os tipos dos parâmetros que estamos
passando, pois, se passamos um campo com tipo diferente pode dar um short
dump, para evitar isso entrar dentro da função, consultar o tipo do parâmetro e criar
igual.

6- Modularização
Blocos de Eventos.
Os blocos de eventos são controlados pelo sistema e só valem para

programas do tipo executável. Abaixo vemos os principais:
REPORT...
INICIALIZATION.
Primeiro passo a ser executado no programa, antes da tela de seleção e antes
da lógica de processamento.
AT SELECTION-SCREEN.
Executa logo após sair da tela de seleção, utilizado para fazer tratamentos de
obrigatoriedade de campos e similares.
TOP-OF-PAGE.
Executa quando é encontrado o primeiro comando WRITE dentro da lógica
principal, utilizado para colocar cabeçalho, textos que devem sair em todas as
páginas.
END-OF-PAGE.
Informações que apareçam no rodapé do relatório
OBS: essas informações só aparecerão se o tamanho da página estiver definido no
comando REPORT e somente qdo houver quebra de página. Caso contrário, não
aparecerá
START-OF-SELECTION.
Entre o START-OF-SELECTION e o END-OF-SELECTION, se encontra a
lógica principal do programa, quando programamos de uma forma estruturada
colocamos aqui apenas chamadas de sub-rotinas, para evitar poluição de código.
Ex:
PERFORM seleciona_dados.
PERFORM tratamento_interno.
PERFORM impressao_dados.
PERFORM gera_arquivos.
END-OF-SELECTION.
AT LINE-SELECTION.
Somente é executado se o usuário der um duplo click em uma linha mostrada
no relatório, ou marcar a linha e pedir para ver detalhe, utilizada para listas
interativas, drill-down.
AT USER-COMMAND.
Somente é executado se o usuário der um click em algum objeto do menu,
utilizado para listas com botões de interação.

6- Modularização
Processo Geral de Programação
Nome e Descrição do
Programa
Declaração de
Variáveis
Montagem da
Tela de
Input
Montagem e
Impressão do
Relatório ou outra lógica

7- Report/Listas
Criação de Listas Básicas
Criando uma lista simples
A sintaxe básica do comando é a seguinte:

WRITE [:] [/] [<campo>|<literal>] [, <campo>|<literal>] [, ...] [opções].
A sintaxe completa do comando pode ser encontrada no Help do R/3. Existem
opções para alterar a cor dos elementos da tela, criação de molduras e inserção de
ícones na lista. Observe o código a seguir:
REPORT ZSELECT00 .
TABLES: SPFLI, SFLIGHT.
SELECT * FROM SPFLI.
WRITE: / SPFLI-CARRID, SPFLI-CONNID, SPFLI-CITYFROM,
SPFLI-AIRPFROM, SPFLI-CITYTO, SPFLI-AIRPTO.
ENDSELECT.

7- Report/Listas
Com esse trecho de código apenas, o R/3 gera uma lista simples do conteúdo
de alguns campos da tabela SPFLI:
Cabeçalhos e rodapés
Existem alguns comandos e opções que permitem melhorar o aspecto e a

funcionalidade de uma lista. No exemplo, a lista ainda não tem cabeçalho. Para
criá-los, pode-se editar diretamente o cabeçalho usando a opção Saltar 
Elementos de Texto  Títulos de Lista. Nesse caso, deve-se saber previamente em
que posição deve ficar o texto no cabeçalho. Por outro lado, utilizando-se a opção
Sistema  Lista  Título da Lista é possível editar o título no momento da exibição
da lista, facilitando muito o posicionamento dos textos. Também é possível suprimir
a geração do título básico, substituindo-o por um título composto pelo programa
ABAP. Para tanto, deve-se colocar na declaração REPORT do início do programa a
opção NO STANDARD PAGE HEADING e implementar no programa o evento
TOP-OF-PAGE. Caso também queira um rodapé para cada página, use o evento
END-OF-PAGE para escrevê-lo.

7- Report/Listas
Mudando a apresentação dos campos
Para melhorar a apresentação da lista, podemos modificar a forma como os

campos são exibidos. Por exemplo, podemos mudar a cor com a opção COLOR do
comando WRITE; podemos mudar a intensidade da cor com a opção INTENSIFIED
{ON|OFF}, transformar o campo num HOTSPOT para uso em listas com drill-down,
e mudar o posicionamento dos campos com WRITE AT. A opção COLOR admite
qualquer uma das cores padrão do R/3, disponíveis na transação LIBS:
Por exemplo, para modificar um campo de forma a usar a cor COL_KEY

menos intensa, como hotspot, centralizado, escreveríamos o código como segue:
WRITE: / SPFLI-CARRID COLOR COL_KEY INTENSIFIED OFF HOTSPOT CENTERED.
A opção HOTSPOT faz com que, ao se apontar o campo com o cursor, o

mesmo fique no formato de uma “mãozinha”, como num hyperlink da Internet,
permitindo a seleção do registro com um único clique do mouse. Essa característica
é muito útil no processamento de listas em vários níveis.

7- Report/Listas
Modificando o formato de exibição standard
As opções dentro do comando WRITE têm efeito apenas no campo a que se

referem. Caso se necessite mudar todos os campos a partir de um determinado
ponto do programa, pode-se usar o comando FORMAT, com as mesmas opções de
formatação vistas para o comando WRITE. Com isso, todos os campos a seguir
serão exibidos com as opções especificadas pelo comando FORMAT, até que seja
encontrado um novo comando FORMAT. Pode-se continuar usando os
modificadores no WRITE, mas os mesmos irão basear-se no novo padrão
estabelecido no comando WRITE. Por exemplo, caso seja colocado o comando.
FORMAT COLOR COL_KEY INTENSIFIED ON CENTERED
todos os campos a seguir passarão a ser exibidos na cor COL_KEY INTENSIFIED,

e serão apresentados centralizados. Caso tenhamos em seguida o comando
WRITE: / SPFLI-CARRID INTENSIFIED OFF, SPFLI-CONNID.
a cor exibida para o campo SPFLI-CARRID será COL_KEY INTENSIFIED OFF, e

não a cor padrão sem INTENSIFIED. O campo SPFLI-CONNID aparecerá da forma
estipulada no comando FORMAT.
O formato pode retornar ao formato standard usando o comando FORMAT
RESET.
Posicionando os campos
Pode-se alterar o posicionamento dos campos dentro de uma linha colocando

o número da coluna na qual queremos que o campo comece na frente do campo.
Pode-se também especificar a largura do campo colocando a mesma em seguida,
entre parênteses (sem essa opção, o tamanho do campo utilizado será o tamanho
dele no dicionário de dados). Por exemplo, para posicionarmos o mesmo campo
que modificamos anteriormente na décima coluna, estabelecendo um tamanho de
cinco caracteres, usamos o comando.
WRITE: /10(5) SPFLI-CARRID COLOR COL_KEY INTENSIFIED OFF HOTSPOT.

7- Report/Listas
Especificando unidades de medida e moedas
Para formatar automaticamente na lista campos numa determinada unidade

de medida e valores monetários, pode-se utilizar as opções UNIT e CURRENCY,
seguidas do campo que contém a chave da unidade, após o campo que se quer
formatar. Com isso, o campo será formatado de acordo com a definição nas tabelas
standard de unidades e de moedas do R/3. Veja o exemplo a seguir:
WRITE: /20(6) SFLIGHT-FLDATE,

SFLIGHT-CURRENCY,
'Sem CURRENCY:', (12) SFLIGHT-PAYMENTSUM,
'Com CURRENCY:', (12) SFLIGHT-PAYMENTSUM
CURRENCY SFLIGHT-
CURRENCY.
Um trecho do report seria:
150420 ITL Sem CURRENCY: 683.231,44 Com CURRENCY: 68.323.144

130520 ITL Sem CURRENCY: 318.202,60 Com CURRENCY: 31.820.260
Sem o uso da opção CURRENCY, o valor é apresentado no formato genérico

do usuário; com o CURRENCY, mesmo caso tenhamos moedas diferentes em cada
registro, cada uma será exibida no formato correto.
Símbolos de Texto
O ABAP permite a criação de símbolos de texto, que são elementos do

repositório que permitem a criação de tabelas de texto para uso nos programas
ABAP. Os símbolos de texto são criados dentro de classes de mensagem, que
servem para separar logicamente os símbolos de texto relacionados. Dentro da
classe de mensagem, cada texto deve ser identificado por um número de três
posições. Cada símbolo de texto pode ser criado em várias linguagens.
Suponha que exista o seguinte trecho de código:
WRITE: /10 'Assentos ocupados:', SFLIGHT-SEATSOCC.
Utilizando símbolos de texto, o comando ficaria
WRITE: /10 TEXT-001(ZCLMENS), SFLIGHT-SEATSOCC.
Toda vez que o interpretador ABAP encontra um campo que começa com
TEXT, coloca naquela posição um símbolo de texto correspondente ao número
após o hífen na classe entre parênteses. Caso seja usada a opção MESSAGE-ID
<classe> na declaração REPORT, não é necessário especificar a classe de
mensagem junto ao símbolo de texto. O uso de símbolos de texto pode simplificar a
manutenção de programas complexos ao agrupar todas as mensagens de texto em
um só local.
Para editar os símbolos de texto, use, na janela do editor ABAP, a opção
Saltar  Elementos de Texto  Símbolos de Texto.

7- Report/Listas
Criação de Listas Complexas

Até agora, as listas criadas apresentam um nível de dados apenas, mas o
ABAP tem recursos que permitem a exibição de listas de detalhe a partir de uma
lista.
O Evento AT LINE-SELECTION
O processamento das listas de detalhe dentro do R/3 é feito pelo evento AT

LINE-SELECTION. O R/3 executa os comandos que houver dentro desse evento
toda vez que o usuário clica duas vezes sobre uma linha em uma lista ouclica sobre
um campo marcado com HOTSPOT, ou teclando-se F2 sobre um registro, ou
escolhendo um botão que tenha o código standard ‘PICK’ a ele associado.
HIDE
Através do comando HIDE, é possível armazenar informação a respeito de

uma linha para uso do evento AT LINE-SELECTION. Suponha que exista uma lista
com os vôos para uma determinada companhia aérea, e deseja-se exibir as
reservas para aquele vôo. Para exibir a lista, é necessário armazenar em algum
local informações sobre a linha selecionada pelo usuário, e isso pode ser feito
através do comando HIDE do ABAP.
O comando HIDE guarda a informação sobre os campos desejados, além do
número da linha que está sendo processada, em uma tabela interna, que é
automaticamente acessada no evento AT LINE-SELECTION. Veja o seguinte
exemplo:
REPORT ZTESTE.
TABLES: SFLIGHT, SBOOK.
START-OF-SELECTION.
SELECT * FROM SFLIGHT.

WRITE: SFLIGHT-CARRID, SFLIGHT-CONNID, SFLIGHT-FLDATE,
SFLIGHT-SEATSOCC.
HIDE: SFLIGHT-CARRID, SFLIGHT-CONNID, SFLIGHT-FLDATE.
ENDSELECT.
AT LINE-SELECTION.
SELECT *
FROM SBOOK
WHERE CARRID = SFLIGHT-CARRID AND
CONNID = SFLIGHT-CONNID AND
FLDATE = SFLIGHT-FLDATE.
WRITE: / SBOOK-CARRID, SBOOK-CONNID, SBOOK-FLDATE,
SBOOK-CUSTOMID.
ENDSELECT.

7- Report/Listas
6- Report/Listas
Dentro desse programa, a cada linha lida no comando SELECT, está sendo
armazenada informação sobre a chave dentro da área de HIDE. Não é necessário
que os campos selecionados com HIDE façam parte da lista impressa via WRITE.
Quando o usuário seleciona um determinado registro, o processador de lista ABAP
automaticamente procura na área de HIDE o registro correspondente àquele
número de linha, e os disponibiliza para uso com o mesmo nome.
Cabeçalhos de listas secundárias

Para definir um cabeçalho próprio para listas secundárias, existe o evento
TOP-OF-PAGE DURING LINE-SELECTION, que permite redefinir o cabeçalho e os
comandos disponíveis dentro da lista secundária. Por exemplo.
REPORT ZTESTE NO STANDARD PAGE HEADING.
START-OF-SELECTION.
...
TOP-OF-PAGE.
SET PF-STATUS ‘LISTA1’.
WRITE: ‘Lista Primária’.
TOP-OF-PAGE DURING LINE-SELECTION.

SET PF-STATUS ‘LISTA2’.
WRITE: ‘Lista Secundária’.
AT LINE-SELECTION.
...

7- Report/Listas
Listas em mais de dois níveis
Quando a lista apresentar mais de dois níveis, é necessário identificar o nível

que está sendo processado – só existe um evento AT LINE-SELECTION e um
TOP-OF-PAGE DURING LINE-SELECTION por programa. Para tanto, deve-se
utilizar o campo de sistema SY-LSIND, que tem o nível corrente de lista. A primeira
sub-lista tem SY-LSIND igual a 1, a segunda, 2, e assim por diante, até o subnível
máximo 19. Por exemplo:
REPORT ZTESTE2N NO STANDARD PAGE HEADING.
START-OF-SELECTION.
SELECT * FROM SFLIGHT.

WRITE: SFLIGHT-CARRID, SFLIGHT-CONNID, SFLIGHT-FLDATE, SFLIGHT-
SEATSOCC.
HIDE: SFLIGHT-CARRID, SFLIGHT-CONNID, SFLIGHT-FLDATE.
ENDSELECT.
TOP-OF-PAGE.
WRITE: ‘Vôos’.
TOP-OF-PAGE DURING LINE-SELECTION.

CASE SY-LSIND.
WHEN 1.
WRITE: ‘Reservas’.
WHEN 2.
WRITE: ‘Cliente’.
ENDCASE.
AT LINE-SELECTION.
CASE SY-LSIND.
WHEN 1.
SELECT * FROM SBOOK
WRITE: / SBOOK-CARRID, SBOOK-CONNID, SBOOK-FLDATE, SBOOK-
CUSTOMID.
HIDE: SBOOK-CUSTOMID.
ENDSELECT.
WHEN 2.
SELECT * FROM SCUSTOM
WHERE ID = SBOOK-CUSTOMID.
WRITE: / SCUSTOM-ID, SCUSTOM-NAME.
ENDSELECT.
ENDCASE.

7- Report/Listas
AT USER-COMMAND
O processamento de lista também pode ser feito através do evento AT USER-

COMMAND. Nesse caso, será feito o processamento dos comandos (menu, teclas
de função, botões da barra), além do comando standard PICK.
6- Report/Listas
Abrindo Telas Dentro de Relatórios
Uma lista secundária pode ser mostrada dentro de uma janela ao colocar-se a
declaração WINDOW STARTING AT <col> <lin> [ENDING AT <col> <lin>]. Os
comandos WRITE subseqüentes serão direcionados para a janela especificada. Por
exemplo, alterando o código da seguinte maneira, podemos criar janelas nas listas
secundárias:
AT LINE-SELECTION.
CASE SY-LSIND.
WHEN 1.
WINDOW STARTING AT 5 3 ENDING AT 40 10.
SELECT * FROM SBOOK
WRITE: / SBOOK-CARRID, SBOOK-CONNID, SBOOK-FLDATE, SBOOK-CUSTOMID.
HIDE: SBOOK-CUSTOMID.
ENDSELECT.
WHEN 2.
WINDOW STARTING AT 45 10 ENDING AT 60 12.
SELECT * FROM SCUSTOM
WHERE ID = SBOOK-CUSTOMID.
WRITE: / SCUSTOM-ID, SCUSTOM-NAME.
ENDSELECT.
ENDCASE.
Chamando transações a partir de listagens
Para chamar uma transação a partir de uma listagem, pode-se utilizar o

comando CALL TRANSACTION <codtran> dentro do AT LINE-SELECTION, onde
<codtran> é o código da transação. Após executar a transação, o controle de
execução passará para a linha seguinte ao CALL TRANSACTION.

7- Report/Listas
Exemplos de comandos e eventos em geral

7- Report/Listas

7- Report/Listas

7- Report/Listas

7- Report/Listas

7- Report/Listas

7- Report/Listas

8- Tabela Interna
Criando Tabelas Internas (Estruturas Complexas de Armazenagem

Temporária).
Tabela interna
Dentro de um programa ABAP, muitas vezes é impossível trabalhar apenas

com os comandos de seleção e alteração de dados diretamente na tabela. Para
manipular localmente os dados, o ABAP permite o uso de tabelas internas, que
são áreas de memória organizadas como tabelas. Essas tabelas internas podem ter
o mesmo formato de uma tabela do banco de dados, o que as qualifica para serem
usadas como áreas de manipulação intermediária, o que traz benefícios em termos
de performance geral do R/3. Uma tabela interna é declarada através do comando
DATA, onde se especifica qual é o tipo de linha da tabela, se ela tem headerline e
qual é a forma de operação da mesma. A tabela pode ser manipulada por
comandos:
• De inserção:
o APPEND: Inclui um novo registro na TI, no último registro.
o INSERT: Inseri um novo registro em uma posição especifica.
o COLLECT: Compara os campos tipo texto, caso encontre chaves
iguais, soma os campos numéricos, se não inclui um novo registro.
• De exclusão:
o DELETE: Exclui um registro da tabela interna, usado dentro do
loop at exclui o registro corrente, caso contrário usar o INDEX
mostrando a linha a ser excluída.
o REFRESH: Limpa todos os registros da TI
o CLEAR: Limpa somente o conteúdo do header line da TI
• De alteração de dados:
o MODIFY: Altera um registro da tabela interna, usado dentro do
loop at altera o registro corrente, caso contrário usar o INDEX
mostrando a linha a ser alterada.

8- Tabela Interna
• De leitura de dados:
o LOOP AT <TI> WHERE <condição>: Utilizado para ler mais de
uma linha da tabela interna, para os casos de tabela interna com
Header line automaticamente o sistema joga os dados para este
registro, caso não deve-se indicar onde será jogado os dados lidos.
Filtro é a opção WHERE.
o READ TABLE <TI> WITH KEY <condição>: Como o Loop at lê os
dados de uma tabela interna só que apenas uma linha por vez.
OBS: Os comandos DELETE e MODIFY quando usados de forma incorreta fora do

loop at e sem a indicação do INDEX, ocasiona Short Dump.
Por exemplo, para declarar uma tabela interna, conforme no exemplo, usou-se
a declaração TYPES para declarar uma estrutura que contém os campos que
desejamos ter na tabela. Em seguida, a tabela é criada através da declaração
DATA, usando a estrutura como modelo.
Exemplos:
data: begin of t_spfli occurs 0,

carrid like spfli-carrid,
connid like spfli-connid,
end of t_spfli.
data: begin of t_sflight occurs 0.

include structure sflight.
data: end of t_sflight.
data: t_aux like t_sflight occurs 0 with header line.
Tipos de tabelas internas
O ABAP oferece três tipos de tabelas internas: STANDARD, SORTED e

HASHED. As tabelas standard permitem o acesso sequencial aos dados, além de
permitir o acesso mediante as chaves especificadas na declaração das tabelas. As
tabelas do tipo sorted já estão pré-ordenadas de acordo com a chave – as
operações realizadas nesse tipo de tabela devem ter o cuidado de não alterar a
ordem, sob pena de ocorrer um erro de execução. As tabelas do tipo hashed são
organizadas de acordo com a chave especificada e não permitem operações
utilizando o número sequencial dos registros. São adequadas a grandes volumes de
dados.

8- Tabela Interna
EXEMPLO 7
REPORT ZEXP0007.
TABLES: T005H..
DATA V_VAR1 VALUE '1'.
DATA: BEGIN OF T_T005H OCCURS 0,

LAND1 LIKE T005H-LAND1,
BEZEI LIKE T005H-BEZEI.
DATA: END OF T_T005H.
SELECT * FROM T005H WHERE LAND1 IN ('US', 'DE') ORDER BY LAND1.
T_T005H-LAND1 = T005H-LAND1.
T_T005H-BEZEI = T005H-BEZEI.
APPEND T_T005H.
ENDSELECT.
IF SY-SUBRC NE 0.
WRITE TEXT-001.
ENDIF.
LOOP AT T_T005H.
ON CHANGE OF T_T005H-LAND1.
IF V_VAR1 = 0.
NEW-PAGE.
ENDIF.
FORMAT COLOR OFF.

WRITE 'COUNTRY CITY'.
CLEAR V_VAR1.
ENDON.
IF T_T005H-LAND1 = 'DE'.
FORMAT COLOR COL_TOTAL.
ELSE.
FORMAT COLOR COL_NORMAL.
ENDIF.
WRITE : / T_T005H-LAND1,
21 T_T005H-BEZEI.
ENDLOOP.

8- Tabela Interna
EXEMPLO 9
REPORT ZEXP0009 MESSAGE-ID ZA.

TABLES: ZCURSO.
DATA: ARQ LIKE RLGRAP-FILENAME VALUE 'C:\TEMP\CURSO.TXT',
V_CONT TYPE I.
DATA: BEGIN OF T_ZCURSO OCCURS 0,
ZDATA LIKE ZCURSO-ZDATA,
ZBELNR LIKE ZCURSO-ZNUMERO,
ZGJAHR LIKE ZCURSO-ZANO.
DATA: END OF T_ZCURSO.
CALL FUNCTION 'WS_UPLOAD'

EXPORTING
* CODEPAGE =''
FILENAME = ARQ
* FILETYPE =''
* HEADLEN =''
* LINE_EXIT =''
* TRUNCLEN =''
* USER_FORM =''
* USER_PROG =''
* importing
* filelength =
TABLES
DATA_TAB = T_ZCURSO
EXCEPTIONS
CONVERSION_ERROR =1
FILE_OPEN_ERROR =2
FILE_READ_ERROR =3
INVALID_TYPE =5
NO_BATCH =6
UNKNOWN_ERROR =7
OTHERS = 8.
CLEAR V_CONT.
LOOP AT T_ZCURSO.
ZCURSO-ZDATA = T_ZCURSO-ZDATA.
ZCURSO-ZNUMERO = T_ZCURSO-ZBELNR.
ZCURSO-ZANO = T_ZCURSO-ZGJAHR.
INSERT ZCURSO.
IF SY-SUBRC = 0.
V_CONT = V_CONT + 1.
ENDIF.
ENDLOOP.
WRITE: 'FORAM INSERIDOS ', V_CONT, 'NA TABELA ZCURSO'.

9 - Programas de Carga (BDC)

BDC Session
ABAP/4 tem uma técnica de programação para a colocação de dados dentro

do SAP conhecida como Batch Data Communication Session ou BDC Session.
Existe a necessidade de entrar com dados no sistema SAP, nas seguintes

situações:
• Na implantação é necessário fazer a carga dos dados do sistema legado
no SAP. Nesse caso normalmente gera-se arquivos TXT e através de
programas ABAP que utilizam o conceito BDC sobe esses dados para o
SAP.
• Em casos de interface com outro sistema também existe a necessidade
de receber dados de outro sistema paralelo.
• Em casos onde utiliza-se de dados do próprio SAP para criar novos
processos (ex: a partir da ordem de venda se cria o fornecimento e a
fatura).
Na maioria dos casos essa carga poderia ser feita diretamente no banco de
dados, mas, quando falamos de SAP isso não funciona, pois, a maioria de
tratamentos na entrada de dados está na interface com usuários, e feito dessa
forma afetaria a integralidade dos dados, então os programas de carga (batch input
ou call transaction ) são utilizados para emular as entradas de dados via interface
com usuário, só que dessa forma as coisas acontecem como se fosse o usuário que
estivesse entrando com os dados manualmente só que não necessita da
intervenção manual do operador. Nas próximas páginas veremos como isso
funciona.

Transação SHDB
Antes de iniciar o desenvolvimento de um programa de carga/interface, é

necessário que faça um mapeamento da transação que será utilizada para fazer a
entrada dos dados, gravando as telas e os campos de cada tela.
Para obtermos qual o programa e tela e também o nome de um determinado
campo, utilizamos a tecla F1 e logo ap[os F9 (ou dados técnicos nas versões mais
atuais), fazendo assim imagine que vamos preencher 100 campos em 5 telas
diferentes, o trabalho para determinar toda a seqüência seria enorme, para facilitar
isso o R3 disponibiliza a transação SHDB, que faz um tipo de filmagem do que
estamos fazendo na transação e gera uma tela com as informações necessária
para utilizarmos na confecção de nosso programa ( inclusive gera um programa
pronto se for o caso e também o arquivo de teste).
Utilizando SHDB
Criar um novo registro de
gravação

Entrar com a o nome do novo registro e com a transação que será utilizada
para entrar com os dados. Clicar em iniciar gravação, automaticamente a SHDB irá
para a transação que você digitou e a partir desse ponto tudo o que você fizer
estará sendo gravado.
Essa já é a tela da transação MM01, cada campo de for preenchido e cada

botão ou tecla de ação que for executada será gravado no registro da SHDB,
CUIDADO com erros no momento de preencher, pois, tudo será gravado.

Após toda a execução da transação, normalmente após um comando SAVE
ou BACK/EXIT, automaticamente fecha-se a transação e volta para a SHDB onde
podemos ver o que foi gravado.
O que estamos vendo acima é exatamente a forma que devemos preencher a

tabela BDC em nosso programa. Nessa tela devemos salvar o registro e aceitá-lo,
em casos específicos podemos gerar o programa e até o arquivo de testes,
normalmente isso não ocorre apenas chegamos a esse ponto, e muitas vezes isso
já está pronto pois o analista funcional já fez.

Após os passos da SHDB, já podemos criar nosso programa, para isso temos
que entender a estrutura BDC, acima está a forma para criarmos nossa tabela
interna para ser utilizada e a estrutura da tabela BDC.
Também é importante definir o tipo de programa que será desenvolvido

BATCH INPUT ou CALL TRANSACTION.

• BATCH INPUT
Programas de BATCH INPUT, são mais utilizados para grandes massas de

dados, pois, ele não faz a execução automática da entrada dos dados, ele apenas
armazena os dados da BDC em uma local chamado PASTA, e esses dados
carregados somente serão processados quando essa pasta for executada na
transação SM35. Nesse caso todo o tratamento de erros de processamento será
controlado pela SM35, os registros com erros ficam em status de erro e podem ser
processados novamente, caso tenha que ser feito qualquer alteração no arquivo ou
base de dados, deve-se rodar novamente o programa ABAP que gera a pasta.
Utiliza-se três funções para armazenar a pasta, como vemos acima.

• CALL TRANSACTION
call transaction 'MM01'

using t_bdc
mode p_modo
messages into t_msg
update 'S'.
Programas CALL TRANSACTION, são mais utilizados para menor quantidade

de dados, ou interfaces on-line que necessitam da resposta do processamento logo
após a execução.
Preenche-se a tabela BDC de acordo com a SHDB e ao invés de armazenar

em pasta, executa-se a instrução CALL TRANSACTION, passando os parâmetros
como mostra acima.
• CALL TRANSACTION <transação>

• USING <tabela interna BDC>
• MODE <A> exibir passo a passo <E> somente erros <N> não exibir
• MESSAGES <tabela interna para armazenar as mensagens>
• UPDATE <modo de gravação (S) Síncrono>
Nesse tipo de programa as mensagens devolvidas pelo CALL TRANSACTION

devem ser tratadas pelo programa de acordo com definição do usuário. Para obter a
mensagem com os dados da tabela interna de mensagens executar a função
WRITE_MESSAGE.

Trabalhando com arquivo texto.
• On-Line – arquivo na máquina presentation.

Utilizar a função WS_UPLOAD para subir o arquivo para uma tabela interna.
CALL FUNCTION 'WS_UPLOAD'

EXPORTING
* CODEPAGE =''
FILENAME = p_path “Nome e caminho do arquivo
FILETYPE = 'ASC' “ASC para TXT e DAT p/ XLS
TABLES
DATA_TAB = t_arq “Tabela interna para receber os dados
EXCEPTIONS
CONVERSION_ERROR =1
FILE_OPEN_ERROR =2
FILE_READ_ERROR =3
INVALID_TYPE =4
NO_BATCH =5
UNKNOWN_ERROR =6
GUI_REFUSE_FILETRANSFER =8
CUSTOMER_ERROR =9
OTHERS = 10
Utiliza-se a função WS_DOWNLOAD para gerar um arquivo TXT ou XLS a

partir de uma tabela interna
CALL FUNCTION 'WS_DOWNLOAD'

EXPORTING
* BIN_FILESIZE =''
* CODEPAGE =''
FILENAME = 'C:\VOOS.XLS'
FILETYPE = 'DAT'
* IMPORTING
* FILELENGTH =
TABLES
DATA_TAB = ti_semquebra
* FIELDNAMES =
EXCEPTIONS
FILE_OPEN_ERROR =1
FILE_WRITE_ERROR =2
INVALID_FILESIZE =3
INVALID_TYPE =4
NO_BATCH =5
UNKNOWN_ERROR =6
GUI_REFUSE_FILETRANSFER =8
CUSTOMER_ERROR =9
OTHERS = 10
Trabalhando com arquivo texto.

• BACKGROUND – arquivo no servidor <Unix>. É utilizado para casos onde o
programa em questão não poderá rodar on-line e o ambiente seja UNIX, pois
as funções WS só funcionam em ambiente Windows.
Subindo dados de um arquivo texto do servidor.
OPEN DATASET <nome do arquivo>

READ DATASET ...
CLOSE DATASET.....
Exemplo:
DATA:
dsn(20) VALUE '/usr/test.dat',
rec(80).
OPEN DATASET dsn FOR INPUT.

IF sy-subrc = 0.
DO.
READ DATASET dsn INTO rec.
IF sy-subrc <> 0.
EXIT.
ELSE.
WRITE / rec.
ENDIF.
ENDDO.
ENDIF.
CLOSE DATASET dsn.
Gerando um arquivo texto no servidor a partir de uma tabela interna.
OPEN DATASET dsn FOR INPUT.

IF sy-subrc = 0.
LOOP AT TI.
TRANSFER TI TO dsn .
ENDLOOP.
ENDIF.
CLOSE DATASET dsn.
• Para os casos de BACKGROUND, se for necessário que o arquivo vá para o

ambiente Windows é necessário criar uma rotina FTP.
Estruturando programa de Carga.

O processo de preencher a tabela interna com estrutura BDC é sempre o
mesmo para todos os programas, então podemos utilizar técnicas que permite nos
desenvolver com maior rapidez e também com um código mais limpo.
Exemplo:
REFRESH T_BDC.
perform insert_line USING:
'X' 'SAPLMGMM' '0060',
' ' 'BDC_CURSOR' 'RMMG1-MTART',
' ' 'RMMG1-MBRSH' 'A',
' ' 'RMMG1-MTART' 'FERT',
' ' 'BDC_OKCODE' '/00'.
REFRESH T_MSG.
call transaction 'MM01'

using t_bdc
mode p_modo
messages into t_msg
update 'S'.
*&---------------------------------------------------------------------*
*& Form insert_line
*&---------------------------------------------------------------------*
FORM insert_line USING U_START TYPE C U_NAME TYPE C U_VALUE.
CLEAR T_BDC.
MOVE U_START TO T_BDC-DYNBEGIN.
IF U_START = 'X'.
MOVE:
U_NAME TO T_BDC-PROGRAM,
U_VALUE TO T_BDC-DYNPRO.
ELSE.
MOVE:
U_NAME TO T_BDC-FNAM,
U_VALUE TO T_BDC-FVAL.
ENDIF.
APPEND T_BDC.
ENDFORM. " insert_line

10 - Programas de Tela – On Line

Dialog Programming – On Line
Introdução:
Online são tipos de programas que, como o próprio nome indica, funcionam
online, ou seja, instantaneamente. Por isso, eles são dotados de uma maior
capacidade de customização das telas e maior flexibilidade para criarem uma
interface mais amigável com o usuário.
Eles são especialmente úteis na criação de aplicações que necessitem de
subtelas ou quando é necessário fornecer informações aos usuários de outra
maneira que não um relatório. Na maioria dos casos, os programas standard
funcionam assim.
Os principais componentes de um programa On-Line são:
- Development environment
o ABAP/4 Dictionary
o Screen Painter
o ABAP/4
o Menu Painter
- Runtime environment
o Dialog processor
o ABAP/4 processor

É necessária a utilização do Screen Painter e do Menu Painter para a criação
dos modelos e dos programas controladores das telas.
O fluxo lógico do processamento da tela é definido no programa ABAPA
( Module Pool )
Os campos definidos nas telas devem ser obtidos através de estruturas e/ou
tabelas definidas no dicionário de dados.
Screen Painter – ABAP/4
Para criação de uma tela, devem ser seguidos os seguintes passos:
- Defina os componentes básicos da tela ( screen attributes ).

- Desenhe o Layout da tela utilizando o fullscreen editor
- Defina os atributos dos campos ( field list )
- Escreva o fluxo lógico da tela. ( flow logic )
Os mais importantes componentes do programa ABAP são encontrados nos

seguintes objetos:
- Global data ou Estruturas do dicionário no TOP include (declaração de dados

)
- Module PBO ( Process Before Output )
- Module PAI ( Process After Input )
- Sub-rotinas ( se necessário )

FIGURA 3
O Fluxo lógico é dividido em dois eventos para cada tela?
O PROCESS BEFORE OUTPUT evento ( PBO ) é executado antes da tela ser

apresentada.
O PROCESS AFTER INPUT evento ( PAI ) é executado após u usuário ter

acionado algum botão ou disparado algum evento na tela anteriormente
apresentada.
O sistema processa módulos em um evento seqüencialmente.

Em cada módulo, o controle é passado do processador de diálogos ( tela )
para o processador do programa ABAP, e após o processamento, o controle é
retornado ao processador de diálogo ( tela ).
Quando todos os módulos do PBO terminarem a execução, os conteúdos dos

campos na Work Area do ABAP são copiados para a Work Area da tela em nomes
idênticos.
Antes do PAI se processado, os conteúdos dos campos na Work Area da tela

são copiados para a Work Area do ABAP em nomes idênticos.

CRIANDO PROGRAMAS
Crie o seu programa (ABAP Module Pool ) no Development Workbench

seguindo a regra de nomenclatura abaixo:
- O nome deverá iniciar com as letras SAP

- A quarta posição do nome do programa deverá ser sempre M ( Module
Pool )
- A quinta posição, no caso de programas customizáveis deverá ser Z ou Y.
Escolha a opção TOP include, pois desta forma, será criado o include
que será utilizado para a declaração dos dados globais.
Se você utilizar os includes, o sistema automaticamente sugerirá os nomes

para eles, seguindo uma regra particular, de acordo com o nome do programa
principal ( module pool) e com um determinado sufixo, o qual facilitará a sua
identificação dentro do programa.
ATRIBUTOS DO PROGRAMA
Nos atributos do programa, você define o Título, o tipo do programa e a

aplicação. Para programas Module Pool, escolha o tipo de programa M.
DEFININDO TELAS
Crie as telas necessárias para o seu programa Module Poll a partir da lista de
objetos.
Após você ter digitado o Número da tela, o sistema abre uma nova tela com
dados daquela tela.
Digite uma pequena descrição para a tela.
Escolha a opção normal e especifique o numero da próxima tela ( se
necessário, n momento da execução, o sistema desviará para o número da tela
indicado nesse campo, caso esteja preenchido ).

UTILIZANDO CAMPOS DO DICIONARIO ABAP
Geralmente, você define campos utilizando os campos previamente definidos

no dicionário ABAP.
Podem ser utilizados também campos já definidos no module pool, bastando
para isso que exista uma geração prévia deste module pool.
Podem ser feitas cópias dos campos de saída e dos templates ( tela )
individualmente ou juntas.

LAYOUT DA TELA ( GRAPHICAL SCREEN PAINTER )
Para desenhar telas, utilize o Screen Painter.
A inteface do Screen Painter Gráfico contém funções easy-to-use para

definição de diversos elementos da tela ( campo de entrada/saída, labels, boxes,
botões, etc.). Você escolhe cada elemento e os posiciona na tela utilizando o
mouse.
Para excluir os elementos da tela, é necessário selecionar cada elemento
com o mouse ( foco ) e pressionar delete.
É possível também mover os elementos gráficos pela tela, somente clicando e
arrastando.

DEFININDO O FLOW CONTROL
Nos Flow Logics não são permitidos palavras reservadas ( IF, PERFORM,
WHILE, ETC ) da mesma forma em que são permitidos nos programas. O Flow
Logic, embora se pareça muito com o programa , não tem o mesmo
comportamento. Ele é usado basicamente para ordenar o processamento da tela, e
para isso são criados os MODULES, que tem uma função análoga a do perform.
Para criarmos um module, escreva o seu nome no flow logic no lugar desejado
e efetue um double-click. O sistema criará uma sub-rotina iniciando com MODULE
<NOME> e terminando com ENDMODUILE no include apropriado. Isto pode ser
facilmente observado efetuando uma navegação pelo include.
Se não existirem includes, o sistema poderá criar uma ou poderá incluir a sub-
rotina no programa principal.

CRIANDO UMA SEQUENCIA DE TELAS
Para telas com estrutura similar, você pode copiar uma tela existente e, se
necessário, modificá-la.
Para fazer isso, você utiliza o DEVELOPMENT WORKBENCH posicionando o
cursor na tela que você deseja copiar e escolha a opção COPY.
Quando terminar o processo com sucesso, o sistema mostrará a tela como um
novo sub-objeto do module pool e você poderá editá-lo.
IMPORTANTE: Sempre que você copiar uma tela o flow logic também será
copiado, e o module aparece declarado nos flow logics e somente a chamada desse
module, esteja ciente que as sub-rotinas ( modules ) podem ser compartilhadas por
varias telas, e que a modificação de uma sub-rotina com esse nível de amarração
deve ser feita com muita atenção.

DEFININDO CAMPOS NO MODULE POOL
No processamento do dialogo, os dados são passados entre as telas e

programas ABAP durante a execução. O sistema efetua a comunicação
automaticamente, mas é necessário que seja utilizado o nome idêntico dos campos
nas telas e no module pool.
Defina os dados globais no TOP INCLUDE, para que todas as telas possam
enxergá-lo.
CRIANDO MODULES ABAP
Durante o processo de criação dos modules PAI/PBO, você pode associá-los

aos includes desejados ou deixar que o sistema automaticamente faca isto por
você.
O PROCESSAMENTO DO MODULE POOL
As sub-rotinas provenientes dos modules do PBO tem a adição OUTPUT e as

provenientes do PAI tem a adição INPUT.

DEFININDO CHAMADAS VIA TRANSAÇÃO
Para executar um programa ABAP module pool, é necessária a criação de

uma transação.
Transações customizadas devem iniciar com Z ou Y.
O sistema armazena suas especificações de transações na tabela TSTC.
INPUT CHECHING NO MODULE POOL
Se for necessária a checagem dos campos de entrada no module pool e incluir

um tratamento de mensagem de erro, deverá ser utilizado o comando FIELD,
associado ao campo que desejamos checar, se for necessário o tratamento mais
apurado , pode ser associado um module especifico a esse comando.
COMANDO FIELD E TRANSPORTE DE DADOS
No module PAI, campos da tela são transportados com nomes idênticos para
Work Areas do programa ABAP.
Campos não associados a comandos FIELD são transportados primeiro,
Todos os outros campos são copiados somente quando todos os FIELD estiverem
sido executados.

ANTERANDO A SEQUENCIA DE TELAS DINAMICAMENTE
Se as funções do seu dialog program requererem um controle de

processamento diferenciado, pode ser feito o controle da seqüência das telas
dinamicamente, usando o comando SET SCREEN.
O comando SET SCREEN NNN temporariamente sobrepõe o controle feito
nos atributos da tela no campo next screen.
A tela NNN deve ser uma tela do mesmo module pool.
Quando a tela corrente termina seu processamento, o sistema desvia o
controle para a tela definida no campo next screen. Se você quiser cancelar a tela
corrente, pode ser usado o comando LEAVE SCREEN.
Pode ser usado o comando CALL SCREEN para controle da seqüência da tela
dinamicamente. Aqui você pode inserir a seqüência de telas após retornar para a
tela original que originou a chamada.

INTERPRETANDO FUNCTION CODES NO PROGRAMA
Quando é definido um PUSHBUTTON para possibilitar ao usuário escolher

funções especificas, quando o botão é pressionado, o evento PAI é disparado.
Pode-se criar um FUNCTION CODE para cada PUSHBUTTON.
Existe um formato ( Dicionário ) pré definido para function codes, é o OK, com
tamanho de 4 bytes.
Para permitir a execução correta de uma função associada a um pushbutton, é
necessária a criação de um campo chamado exatamente de OKCODE. Este campo
contem o valor do function code após os dados serem transportados da tela para o
programa.

MENU PAINTER: OVERVIEW
Usa-se o Menu Painter para definir funções na tela em um status particular e

associá-los a um apropriado menu, a saber ? menu bar, standard toolbar e
application toolbar.
Pode-se também definir um titulo para a tela.
Em geral, define-se um menubar para cada dialog program e associa-se esse
menubar a um status. Para cada status, define-se qual função estará ativa/inativa.
Cada alteração nos status ( menus ) deve ser seguida de uma re-geração da
tela completa.
Para associar um status e um título a uma tela, isto deve ser feito no seu PBO,
usando o comando SET PF-STATUS e SET TITLEBAR.
Quando necessário, o sistema propõe valores default para o menu bar e
também teclas de função, porem podem ser modificadas.

Criando ajuda de pesquisa (Matchcode)
Para se criar uma ajuda de pesquisa no SAP, utiliza-se a transação SE11.
Nela, deve ser preenchido o nome da ajuda de pesquisa e apertar a tecla

<CRIAR>
Em seguida, deve-se entrar os seguintes campos:
Descrição da ajuda de pesquisa

Método de Seleção (tabela ou visão que contém os dados)
O tipo da ajuda de pesquisa (se será uma lista tipo “dropdown” ou uma outra
tela)
Os parâmetros que deverão constar da ajuda de pesquisa, com os seus
respectivos elementos de dados (OBS: para uma ajuda de pesquisa, é necessário
que um elemento de dados para o parâmetro em questão exista).
Preenchimento dos campos PosL e ISel. Estes campos indicam a posição na
lista de acertos da ajuda de pesquisa que os parâmetros aparecerão e o se eles
devem aparecer na listagem ou não. Em muitos casos, um parâmetro serve apenas
para ajudar na seleção de outro e portanto não deve ser exibido.
Devemos informar ainda qual campo sera importado/exportado quando a
ajuda de pesquisa for ativada. Essa informação é indicada através de 2 boxes junto
aos parâmetros de ajuda de pesquisa.

Exemplo:
No exemplo acima, uma ajuda de pesquisa é criada para o parâmetro

CODAL (cód. do aluno), que será importado e exportado (lido e devolvido para
tela de seleção após a escolha do usuário). Para auxiliar o usuário, o nome do
aluno deverá aparecer também (parâmetro NOMEA), porém, ele não será lido e
nem devolvido para a tela.Com isso, obtemos uma ajuda de pesquisa da
seguinte forma:
11 - SAPSCRIPT

Definição:
SAPSCRIPT é uma ferramenta que auxilia o desenvolvedor Abap a criar
relatórios com formatação gráfica, independentemente do programa que o utilizará.
É claro que ele não funciona sozinho, pois para que ele seja executado, depende
diretamente de um programa ABAP. Portanto, cria-se um programa Z qualquer
para chamar o seu SAPSCRIPT.
Podemos definir alguns parametros importantes:
- Formatação de fontes (tamanho,tipo)

- Box
- Figuras ( logomarcas )
-
Limitações e problemas da ferramenta
O SAPSCRIPT apresenta uma série de limitações, principalmente no que diz

respeito a verificação de erros e análise de debug. Um comando escrito na grafia
errada dentro de um formulário, jamais será detectado pelo mesmo. Somente a não
funcionalidade esperada do comando poderá levar ao programador descobrir seu
próprio erro.
O modo debug do ambiente de SAPscript pode ser ativado na transação SE71
(SAP Standard Menu -> Tools -> Sapscript -> Form), através do menu Utilitários ->
Ativar debug. O método correto consiste em se preencher o nome do formulário e
idioma nos campos da tela, antes de percorrer o caminho do menu. Algumas vezes,
no entanto, principalmente para um processamento em background, o formulário
não permite ser debugado, embora percorrendo o caminho acima citado, nenhuma
mensagem de impossibilidade seja exibida. Simplesmente, nenhuma tentativa de
debug funciona. Nesses casos, o programador deve utilizar de artifícios como
imprimir o conteúdo dos campos a serem checados em pontos estratégicos do
formulário, para observar seu comportamento.
O comportamento de um formulário SAPscript pode também ser muitas vezes
irritante, principalmente quando se desconhece alguns de seus detalhes. Um dos
problemas mais comuns do formulário SAPscript é quanto a utilização de logotipos
nos relatórios gerados. Sua filosofia pode parecer bastante simples e é, mas essa
operação é bastante sensível, e devem ser salientados alguns pontos:
O objeto com o logotipo deve ser gerado a partir de um programa de ABAP,
através da transação SE38, chamado RSTXLDMC. O modo como o arquivo com o
logotipo é tratado, deve ser cuidadosamente verificado, pois implicará no sucesso
ou fracasso da exibição do logotipo esperado. Inicialmente, deve ser ressaltado que
o arquivo deve estar no formato TIFF (extensão .TIF), não comprimido. Essa figura
gerada nestes padrões tem ainda algumas restrições para a sua aplicação. Em
primeiro lugar, o número de píxeis da figura ( a resolução da mesma, em DPI – dots
per inch ) devem ser exatamente o número de píxeis informado na tela de seleção
do programa para se garantir que o logotipo seja exibido no tamanho em que foi
gerado. Alguns programas de editoração gráfica, como o Paint Shop Pro,
11 – SAPSCRIPT

possuem recursos para se determinar o tamanho da figura em centímetros e até
mudá-lo (resize), mantendo-se a resolução (número de píxels). Em alguns casos, se
o número de píxeis não coincidir com o informado, a figura pode nem ser gerada no
SAP, dificultando o trabalho do programador. Em segundo lugar, o número de cores
ou tonalidades de cinza também precisam coincidir (esse parâmentro varia de
acordo com a versão do SAP, devendo-se estar atento aos dados na tela de
seleção do programa). Por fim, um último parâmetro que pode alterar o tamanho e o
formato do logotipo é a configuração da impressora no SAP. O SAP utiliza a
configuração da impressora para gerar o formulário e imprimí-lo. Se a configuração
não estiver correta, pode influenciar no logotipo e na criação de linhas e caixas
(BOXES).
Nessa hora entra a segunda dificuldade de se trabalhar com logotipos em
SAPscript. Ao se executar o formulário, em uma visualização na tela, o usuário
nunca irá conseguir enxergar o logotipo. Esse somente irá aparecer na impressão
em papel (ainda que impressão do layout do formulário, e não seu conteúdo final -
Utilitários -> Imprimir layout). As novas versões do SAP já corrigiram esse
problema.
Essas duas características podem tomar algumas horas do programador,

ainda que bem experiente no trabalho com SAPscript.
É importante se observar também que os formulários são “client dependent”, o
que significa dizer que devem ser transportados a todos os clientes em que se
deseja executá-lo, independentemente de estar na mesma instância que já o tenha.
Isso não pareceria ser muito complicado se não fosse um trabalho a mais controlar
a versão de todos no momento que uma alteração for feita. Por isso, recomenda-se
que todos os números das Change Requests sejam inseridos como comentário no
corpo do formulário, pois não há administração de versões para Sapscript, como há
nos reports. Um outro problema são os objetos gerados, como os logotipos e textos,
que além de dependentes do cliente, não estão vinculados a nenhuma request, não
podendo nem ser transportados diretamente de um cliente para o outro. Tanto os
logotipos quanto os textos são armazenados da mesma maneira no sistema. Para
transportá-los, deve-se executar o programa RSTXTRAN, que associa esses textos
a uma change request para em seguida, poderem ser transportados
Por falar em transporte, é sempre bom reforçar que no momento do transporte

de um formulário SAPscript, é necessário assegurar que todas as estruturas
utilizadas por ele, tenham sido transportadas anteriormente. O objetivo é assegurar
que tudo que será utilizado pelo formulário já esteja no cliente, no momento em que
este for introduzido, para que não haja erros. A ordem mais aconselhada para
esses transportes seria:
1 . Estrutura
2 . Layout
3 . Programa de povoamento
11 – SAPSCRIPT

Programa de Povoamento do SAPSCRIPT
O programa de povoamento é o programa responsável pelo controle da

impressão do formulário. É através dele que o formulário é aberto, que os dados
são enviados para as janelas corretas, que é feito o controle de quebra de páginas,
que é feito o fechamento do formulário, etc.
É no programa de povoamento que é feita a seleção dos dados que deverão
aparecer no relatório. Toda a lógica de seleção, busca dos dados, associação de
tabelas, etc., é feita nele. O formulário é apenas um “dispositivo” para output dos
dados.
A construção de um programa de povoamento deve seguir a seguinte
estrutura:
• Abertura de um formulário
• Inicialização de um formulário
• Seleção dos dados do formulário
• Impressão dos dados nas janelas do formulário
• Encerramento do formulário
• Fechamento do formulário

11 – SAPSCRIPT
Abertura de formulários.
O primeiro passo para a impressão de um Sapscript através de um programa

é a abertura de um formulário para que se possa fazer o povoamento.
Para que se possa inicializar um formulário é necessário que este seja aberto.
Portanto, é obrigatória a presença de um comando de abertura num programa de
povoamento.
A abertura de um formulário gera automaticamente a inicialização de um
formulário.
O comando para a abertura de um formulário é a seguinte função:
call function 'OPEN_FORM'

exporting
* APPLICATION = 'TX'
* ARCHIVE_INDEX = ' '
* ARCHIVE_PARAMS = ' '
DEVICE = 'PRINTER'
* DIALOG = 'X'
FORM = (Nome do Formulário)
LANGUAGE = (Idioma do Formulário)
* OPTIONS = ITCPO
* importing
* language =
* new_archive_params =
* result =
exceptions
canceled = 1
device = 2
form = 3
options = 4
unclosed = 5
others = 6.
Os parâmetros mais importantes a serem passados para a função são:

Device – Dispositivo onde será gerado o formulário (geralmente PRINTER)
Form – Nome do formulário a ser aberto
Language – Idioma a ser utilizado
Dois outros parâmetros também muitas vezes utilizados são o dialog e o

options.
No primeiro, indica-se se a caixa de diálogo para configuração da impressão
deve ou não ser apresentado. Caso este deva ser omitido, os dados para impressão
serão tomados de uma estrutura a ser colocada no segundo parâmetro. Nessa
estrutura são passados os dados tais como número de cópias e nome da
impressora. A opção de não exibição da caixa de diálogo esta diretamente ligada a
utilização do segundo parâmetro. Se a exibição estiver desabilitada (DIALOG = ‘ ‘)
mas a estrutura ITCPO não estiver preenchida, a caixa de diálogo será exibida.
Alguns dos campos mais importantes e que normalmente são utilizados na
estrutura ITCPO são:

11 – SAPSCRIPT
- TDCOPIES (Número de Cópias)

- TDDEST (Dispositivo de Saída)
- TDPREVIEW (Print Preview)
- TDIMMED (Saída Imediata)
Exemplo de abertura do formulário ZSCR_CURSO.
ITCPO-TDIMMED = ‘X’.
ITCPO-TDCOPIES = 2.
ITCPO-TDDEST = ‘IMP1’.
call function 'OPEN_FORM'

exporting
* APPLICATION = 'TX'
* ARCHIVE_PARAMS = ' '
DEVICE = 'PRINTER'
DIALOG = ' '
FORM = 'ZSCR_CURSO'
LANGUAGE = 'P'
OPTIONS = ITCPO
* importing
* language =
* new_archive_params =
* result =
exceptions
canceled = 1
device = 2
form = 3
options = 4
unclosed = 5
others = 6.
Neste exemplo, o formulário ZSCR_CURSO no idioma português será aberto,

sem a exibição da caixa de diálogo de impressão, utilizando a impressora IMP1 e
executando a impressão imediata de 2 cópias.

11 – SAPSCRIPT
Inicialização de um formulário.
A abertura de um formulário automaticamente gera a inicialização do mesmo.

Mas, imagine por exemplo que estejamos gerando relatórios para uma
empresa de computadores onde, para cada novo computador vendido, deve ser
gerado um novo relatório, e esse relatório deve conter todos os componentes
presentes no computador em questão.
A abertura de um formulário inicia o primeiro, mas para cada novo computador
vendido um novo formulário deve ser gerado.
Para isso utilizamos o comando de inicialização. Este comando permite que,
numa mesma impressão, sejam gerados vários formulários diferentes, como se
estivéssemos abrindo um novo para cada computador vendido.
Este comando não é obrigatório e pode não ser utilizado caso não haja
necessidade da quebra e criação de vários formulários para uma só seleção de
dados.
O comando para inicialização de um formulário é a seguinte função:
call function 'START_FORM'

exporting
FORM = ' '
LANGUAGE = ' '
* STARTPAGE = ' '
* PROGRAM = ' '
* importing
* language =
exceptions
form = 1
format = 2
unended = 3
unopened = 4
unused = 5
others = 6.
A função é muito similar à função OPEN_FORM, e novamente os parâmetros

mais importantes são o nome (FORM) e o idioma (LANGUAGE) do formulário.
Para que se possa utilizar um comando START_FORM é obrigatório que um
comando de OPEN_FORM tenha sido executado.

11 – SAPSCRIPT
Finalizando um formulário.
Em contrapartida com o item acima (comando START_FORM), toda vez que

um formulário é inicializado, o mesmo deve ser finalizado ao final do seu
processamento. Isso é obtido através do comando:
CALL FUNCTION 'END_FORM'.

* IMPORTING
* RESULT =
* EXCEPTIONS
* UNOPENED = 1
* BAD_PAGEFORMAT_FOR_PRINT = 2
* OTHERS = 3
Para o seu funcionamento, apenas a sua chamada é suficiente, sem as

cláusulas adicionais, comentadas acima.
Fechando um formulário.
Finalmente, em contrapartida ao comando OPEN_FORM, toda vez que um

formulário é aberto, o mesmo deve ser fechado. Isso é obtido através do comando :
CALL FUNCTION 'CLOSE_FORM'.

* IMPORTING
* RESULT =
* RDI_RESULT =
* TABLES
* OTFDATA =
* EXCEPTIONS
* UNOPENED = 1
* BAD_PAGEFORMAT_FOR_PRINT = 2
* SEND_ERROR = 3
* OTHERS = 4
Como no comando END_FORM, para o seu funcionamento, apenas a sua

chamada é suficiente, sem as cláusulas adicionais, comentadas acima.

11 – SAPSCRIPT
Seleção dos dados
A seleção dos dados é feita normalmente com comandos SELECT e demais

comandos ABAP, como já foi visto em tópicos anteriores.
Um ponto importante que deve ser observado é que não é possível utilizar
tabelas internas e variáveis do programa para a impressão dos dados no
SAPSCRIPT. Portanto, se algum dado que deva ser impresso estiver numa tabela
interna ou variável, este deve ser copiado para uma estrutura para que possa ser
enviado ao SAPSCRIPT.
Impressão dos dados nas janelas
A impressão dos dados nas janelas na maioria das vezes é feita

simultaneamente com a seleção dos dados, ou seja, a medida que os dados são
selecionados, são enviados imediatamente para o formulário.
O comando para impressão dos dados é a seguinte função:
call function 'WRITE_FORM'

exporting
ELEMENT = ' '
* FUNCTION = 'SET'
* TYPE = 'BODY'
WINDOW = 'MAIN'
* importing
* pending_lines =
exceptions
element = 1
function = 2
type = 3
unopened = 4
unstarted = 5
window = 6
others = 7.
Dois parâmetros são os mais importantes:
Element – Determina qual Data Element será utilizado dentro do Sapscript

Window – Janela na qual os dados devem ser impressos.

11 – SAPSCRIPT
Neste ponto fica evidente a diferenciação entre os tipos de janela MAIN e

demais janelas.
Para as janelas do tipo MAIN, cada comando de escrita (write_form) significa
uma nova linha no formulário e o valor a ser impresso é o valor que o campo
armazena no momento do comando de impressão.
Por exemplo, digamos que o campo MARA-MATNR tenha o valor ‘1234’ e
que um comando de impressão seja dado para a janela MAIN que irá imprimir este
campo. Logo em seguida uma nova seleção da tabela MARA é feita e o campo
MATNR agora vale ‘5678’. Se uma nova impressão na janela MAIN for executada o
resultado será o seguinte:
1234
5678
Já as janelas que não forem do tipo MAIN imprimem os dados uma única vez,
no final da impressão do formulário ou na quebra de página, com os valores
armazenados nos campos no momento do encerramento ou no momento da
quebra, e não no momento da escrita (write_form), ou seja, se no exemplo anterior
fosse utilizada uma janela não-main, o resultado final seria somente 5678.
Na realidade, a utilização de um comando WRITE_FORM numa janela não-
main é utilizada para a escolha de qual elemento de texto será utilizado para a
impressão dos dados. Exemplo:
Uma janela HEADER não-main contém dois elementos de texto chamados

FRASE1 e FRASE2 da seguinte forma:
/E FRASE1
&MARA-MATNR& Teste de Frase 1
/E FRASE2
&MARA-MATNR& Teste de Frase 2
Se um comando WRITE_FORM for executado para a janela HEADER

utilizando o elemento de texto FRASE1,
call function 'WRITE_FORM'

exporting
ELEMENT = 'FRASE1'
* FUNCTION = 'SET'
* TYPE = 'BODY'
WINDOW = 'HEADER'
estará sendo indicado ao programa que, ao se encerrar o formulário, deve ser

impresso o elemento de texto FRASE1 para a janela HEADER (somente um
elemento de texto é utilizado para cada janela não-main).
No caso do exemplo, se o campo MATNR for igual a ‘1234’ no encerramento
do formulário, seria impressa a seguinte frase:
Teste de Frase 1.

11 – SAPSCRIPT
O elemento de texto a ser impresso será sempre o último a ser selecionado

antes do final ou da quebra de página.
Se nenhum for selecionado, ao encerrar o formulário ou mudar de página
serão impressos os dados que não pertençam a nenhum elemento de texto.
Portanto no caso de um campo que deva ser impresso sempre em todas as
páginas, como numero de página por exemplo, basta colocá-lo fora de qualquer
elemento de texto e não selecionar nenhum elemento de texto para a janela que,
automaticamente, este dado será impresso em todas as páginas.
Fluxo do SAPSCRIPT:
Tendo visto os comandos acima, um fluxo simplificado de um programa para a

impressão de um SAPSCRIPT seria:
FORM f_imprime_sapscript.
* Abre o formulário
CALL FUNCTION 'OPEN_FORM'
EXPORTING
DEVICE = 'PRINTER'
FORM = 'Z_SAPSCRIT'
LANGUAGE = SY-LANGU.
* inicializa o formulário
CALL FUNCTION 'START_FORM'
EXPORTING
FORM = 'Z_SAPSCRIT'
LANGUAGE = SY-LANGU.
loop at i_tab.
* imprime o elemento de dados ITEM da janela MAIN do Sapscript

* com os dados da tabela interna i_tab
CALL FUNCTION 'WRITE_FORM'
EXPORTING
ELEMENT = 'ITEM'
WINDOW = 'MAIN'.
endloop.
* finaliza o formulário
call function 'END_FORM'.
* fecha o formulário
call function 'CLOSE_FORM'.
ENDFORM.

11 - SAPSCRIPT
Também vale a pena chamar a atenção para que esses 3 classes de objetos
estejam em requests separadas no desenvolvimento de um projeto, o que pode
evitar problemas quando algum deles não estiver funcionando propriamente e
necessitar ser reparado...
Utilizando SAPSCRIPT
Para a utilização dessa ferramenta, utilizaremos a transação SE71 e como de

costume, temos que informar um novo nome de Formulário e clicar no botão
CREATE conforme exemplo da figura 1.

11 - SAPSCRIPT
Header
No Header (Cabeçalho) faz-se necessário informarmos a Descrição do

formulário e a Classe de Desenvolvimento, para então começarmos efetivamente
a montar nosso primeiro SAPSCRIPT.

11 - SAPSCRIPT
Basic Setting
No Basic Setting, informaremos alguns parâmetros referentes a configuração

da página de impressão, os principais e necessários são:
- Page format ( Tipo de página )

- Default paragr. ( Parágrafo padrão )
- First page ( Primeira página a ser mostrada na execução )
Esta etapa só poderá ser feita depois de criarmos PAGINAS e

PARAGRAFOS.
11 - SAPSCRIPT

Page
A Page servirá para armazenar as informações do relatório.
Para criar uma page, basta preencher os campos indicados abaixo:
- Page ( nome da página )

- Next page ( próxima página )
- Description ( descrição da página )
11 - SAPSCRIPT

Windows
Nesta etapa, criaremos as Windows, ou seja, as janelas da Page. Essas

Janelas, podem ser criadas de acordo com a necessidade de cada desenvolvedor.
Campos a serem preenchidos:

- Window ( nome da janela )
- Description ( descrição da janela )
11 - SAPSCRIPT

Page Windows
Agora iremos amarrar as Windows com as Pages, informando cada posição

de cada Window na Page. Para isso basta informarmos os seguintes campos:

Left margin ( margem a esquerda )
Upper margin ( margem superior )
Window width ( largura da janela )
Window height ( altura da janela )
Figura 6.
11 - SAPSCRIPT
Parágrafo
Criaremos os parágrafos que serão utilizados no relatório de acordo com a

necessidade do programa. Aqui você já pode definir uma formatação para seu
parágrafo ( Tamanho da fonte, tipo de letra, negrito, itálico ou sublinhado ).

11 - SAPSCRIPT
Tabs
Com os Tabs podemos indicar em qual coluna cada texto vai estar no
parágrafo. E para criá-los, temos que indicar os seguintes campos:

- Tab position ( posição do tab )
- Alignment ( alinhamento )
11 - SAPSCRIPT
Text Elements
Esta é a principal etapa, porque utilizaremos tudo que criamos nas etapas
anteriores. Voltemos para Page Windows e clicaremos no botão Text
Elements. Não esqueça de selecionar a Page Window que deseja.

Vemos na figura 9 um formulário dividido em 2 partes. A primeira,
informaremos o tipo do parágrafo ( aqueles que criamos e outros default ) e a
segunda, o que vai conter no parágrafo, ou seja, o que vai aparecer no relatório e
como vai aparecer.
Informações importantes:
,, ( definem os tabs que serão utilizados)

&campo& (indica que será utilizado uma variável do programa)
11 - SAPSCRIPT
Criação de Bordas

Ativando SAPSCRIPT
Como tudo em Abap temos que Ativar, não esqueçam de ativar o SapScript,
porque senão, não vai funcionar.
Testando SAPSCRIPT
Podemos testar se o relatório está funcionando, mas lembre-se, é somente a

mascara do relatório, ou seja, é um relatório sem dados.
11 - SAPSCRIPT
O Relatório

11 – SAPSCRIPT
Chamando o SAPSCRIPT a partir do programa.

Abrindo Formulário
MOVE: 'LOCL' TO ITCPO-TDDEST, "Impressora

'' TO ITCPO-TDIMMED, "Imediato
'' TO ITCPO-TDDELETE, "Deleção apos impressao
P_EXIBI TO ITCPO-TDPREVIEW,"Exibir antes da impressão
'' TO ITCPO-TDGETOTF.
CALL FUNCTION 'OPEN_FORM'

EXPORTING
DEVICE = 'PRINTER'
DIALOG = 'X'
FORM = 'ZSAPCURSOXX'
LANGUAGE = 'P'
OPTIONS = ITCPO
EXCEPTIONS
CANCELED =1
DEVICE =2
FORM =3
OPTIONS =4
UNCLOSED =5
MAIL_OPTIONS =6
ARCHIVE_ERROR =7
MORE_PARAMS_NEEDED_IN_BATCH = 8
OTHERS = 9.
IF SY-SUBRC <> 0.
MESSAGE E368(00) WITH TEXT-007.
ENDIF.
Chamando um TEXT_ELEMENT
CALL FUNCTION 'WRITE_FORM'
EXPORTING
ELEMENT = 'ITEM'
* FUNCTION = 'SET'
* TYPE = 'BODY'
WINDOW = 'MAIN'
* IMPORTING
* PENDING_LINES =
EXCEPTIONS
ELEMENT =1
FUNCTION =2
TYPE =3
UNOPENED =4
UNSTARTED =5
WINDOW =6
BAD_PAGEFORMAT_FOR_PRINT = 7
OTHERS = 8.
Fechando o Formulário
CALL FUNCTION 'CLOSE_FORM'
* IMPORTING
* RESULT = I_RESULT
* TABLES
* OTFDATA = I_OTF
EXCEPTIONS
UNOPENED =1
BAD_PAGEFORMAT_FOR_PRINT = 2
SEND_ERROR =3
OTHERS = 4.
11 - SAPSCRIPT
Inclusão de Logos nos formulários

Utilizar logotipos em formulários SAPscripts, não é das tarefas mais simples
que se possa ter. Teoricamente falando, o processo é bastante simples e consiste
em gerar no sistema um objeto no formato hexadecimal, que possa ser interpretado
pelo SAPscript, originando a inclusão de uma imagem. No entanto, devido ás
limitações expostas no começo deste documento, isso pode levar um certo tempo
até reproduzir o resultado desejado.
Para gerarmos o objeto no client desejado (lembre que esse objeto não pode
ser transportado…), devemos executar o programa standard RSTXLDMC, com um
arquivo no formato *.TIF.

11 – SAPSCRIPT
Preencher o primeiro campo (file name), com o path completo do arquivo da

imagem do logotipo. Esse caminho pode ser no servidor ou local.
O segundo campo (type) determina se o logotipo deve ser gerado
monocromático (default) ou colorido.
O último parâmetro que exige ser preenchido é o Text Name, onde é feita a
atribuição do nome do objeto que será referenciado de dentro do formulário
(padrão: ZHEX-MACRO-…).
A geração desse logo está intimamente ligado ao formato do arquivo TIF. Isso
quer dizer que o seu tamanho obtido no formulário está relacionado ao tamanho da
imagem geradora do objeto.
Tomar cuidado com o número de cores e tonalidades da imagem e lembrar na
hora de fazer os testes, que o logotipo não aparece na tela, somente em
impressões no papel (problema corrigido nas versões atuais).
Nesta hora, vale lembrar todas as ressalvas feitas anteriormente:
O arquivo deve estar no formato TIFF (extensão .TIF), não comprimido. Essa
figura gerada nestes padrões tem ainda algumas restrições para a sua aplicação.
Em primeiro lugar, o número de píxeis da figura ( a resolução da mesma, em DPI –
dots per inch ) devem ser exatamente o número de píxeis informado na tela de
seleção do programa para se garantir que o logotipo seja exibido no tamanho em
que foi gerado. Alguns programas de editoração gráfica, como o Paint Shop Pro,
possuem recursos para se determinar o tamanho da figura em centímetros e até
mudá-lo (resize), mantendo-se a resolução (número de píxels). Em alguns casos, se
o número de píxeis não coincidir com o informado, a figura pode nem ser gerada no
SAP, dificultando o trabalho do programador.
O número de cores ou tonalidades de cinza também precisam coincidir (esse
parâmentro varia de acordo com a versão do SAP, devendo-se estar atento aos
dados na tela de seleção do programa).
A configuração da impressora no SAP pode alterar o tamanho e o formato do
logotipo é a configuração da impressora no SAP. O SAP utiliza a configuração da
impressora para gerar o formulário e imprimí-lo. Se a configuração não estiver
correta, pode influenciar no logotipo e na criação de linhas e caixas (BOXES).
Para se transportar um logotipo ou texto, deve-se primeiro, associá-lo a uma
Change Request, através do programa standard RSTXTRAN

12 – Introdução ALV
Introdução
O ALV Grid é uma ferramenta flexível para exibição de relatórios ou árvore.

São disponibilizados botões que permitem ao usuário manipular os dados
(classificar, filtrar, somar).
Além dos botões standards do sistema, é possível criar novos botões
conforme a necessidade do usuário. Isto pode eliminar certas etapas no processo
de gerenciamento de eventos para controles.
ATENÇÃO : O ALV Grid não permite processamento em Background apenas o

ALV List.
Utilização
O Abap List Viewer padroniza e simplifica o uso de listas e relatórios no

sistema R/3.
Pode-se especificar os campos a serem exibidos no relatório e modificar a

seqüência em que esses campos são exibidos. Além disso, pode-se ajustar a
largura das colunas individuais para atender a requisitos específicos.
O ALV permite :
Usar variantes de exibição standard predefinidas pela SAP

Definir um filtro : Exibir somente os campos desejados
Formar totais e subtotais : Em uma lista, é possível calcular totais e subtotais de

uma ou mais colunas selecionadas.
Exibição de informações detalhadas : Pode-se acessar informações detalhada de

linhas individuais da lista
Impressão de Lista e pré-visualização : Pode-se imprimir as listas e chamar uma

pré-exibição antes de imprimir
Exportação de dados : Pode-se copiar as listas, por exemplo, para uma planilha
ou grava-las como arquivo local

O ALV Grid é formado basicamente por :
 Uma barra de ferramenta

 Um título
 Uma lista de saída
Conceito de Variante de Exibição
A variante de exibição é utilizada para exibir o relatório em vários formatos

diferente. Cada usuário pode criar a sua própria variante e utiliza-la para
visualizar o relatório.
Por exemplo : Um relatório que tenha 20 campos exibidos na tela. Você pode
eliminar os campos que não irá utilizar, acrescentar totalizadores, ordenação,
mudar os campos de posição, etc.

Tela Normal do relatório
Eliminando Campos, Ordenando pela Data Documento e Criando

Totalizadores.

Tela de Seleção Relatório
EVENTO – INITIALIZATION
Neste evento você verificará se existe uma variante definida como default
para o relatório através da função REUSE_ALV_VARIANT_DEFAULT_GET
Variável :
def_variante LIKE disvariant.
Parâmetro da tela de seleção :

PARAMETERS : p_vari LIKE disvariant-variant.
Função :
CALL FUNCTION 'REUSE_ALV_VARIANT_DEFAULT_GET'
EXPORTING
i_save = ‘A’
CHANGING
cs_variant = def_variante
EXCEPTIONS
not_found = 2.
IF sy-subrc = 0.
p_vari = def_variante-variant.
ENDIF.

EVENTO – AT SELECTION-SCREEN ON VALUE-REQUEST .....
Neste evento você deverá criar uma rotina para exibir as variantes já
existentes para o relatório em questão.
AT SELECTION-SCREEN ON VALUE-REQUEST FOR p_vari.
PERFORM f_f4_variant.
Variáveis :
variant_exit(01) TYPE c,
variante LIKE disvariant,
Função :
CALL FUNCTION 'REUSE_ALV_VARIANT_F4'
EXPORTING
is_variant = variante
i_save = ‘A’
IMPORTING
e_exit = variant_exit
es_variant = def_variante
EXCEPTIONS
not_found = 2.
IF sy-subrc = 2.
MESSAGE ID sy-msgid TYPE 'S' NUMBER sy-msgno
WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
ELSE.
IF variant_exit = space.
p_vari = def_variante-variant.
ENDIF.
ENDIF.

EVENTO – AT SELECTION-SCREEN
Neste evento você irá tratar a variante informada, ou seja, verificar a sua
existência, pois o usuário pode ter digitado um nome qualquer ao invés de utilizar o
F4.
AT SELECTION-SCREEN.
PERFORM f_variante.
Verificar se existe valor no parâmetro da tela
IF NOT p_vari IS INITIAL.
Mover valor em branco para a estrutura def_variante e o nome da variante

para o campo def_variante-variant
MOVE variante TO def_variante.

MOVE p_vari TO def_variante-variant.
Executar a função
CALL FUNCTION 'REUSE_ALV_VARIANT_EXISTENCE'

EXPORTING
i_save = ‘A’
CHANGING
cs_variant = def_variante.
Mover estrutura def_variante para variante
variante = def_variante.
ELSE.
Se não existir valor no parâmetro inicializar a estrutura Variante
CLEAR variante.
variante-report = v_repid.
ENDIF.

FORMATAÇÃO DO RELATÓRIO EM ALV
Neste tópico iremos mostrar as rotinas necessárias para formatação de um

relatório em ALV. Formatação geral, de campos, botões e etc.
1. Definições de dados para o layout ALV
1.1. Definicao de Tipos
*Grupos de tipo
TYPE-POOLS: slis.
TYPE-POOLS: kkblo.
1.2. Workareas
DATA: w_layout TYPE slis_layout_alv,

w_print TYPE slis_print_alv
w_event TYPE slis_alv_event,
w_line TYPE slis_listheader.
DATA: colinfo TYPE kkblo_specialcol.
1.3. Tabela Interna
DATA: l_sort TYPE slis_t_sortinfo_alv,

l_event TYPE slis_t_event,
l_top_of_page TYPE slis_t_listheader,
t_campos TYPE slis_t_fieldcat_alv WITH HEADER LINE.
1.4. Tabela Interna para Impressão do Relatório
DATA : BEGIN OF t_relat OCCURS 0,

Campo1
Campo2
Campo3
.................
.................
box(1) TYPE c, " Campo Selecao Linha
colinfo TYPE kkblo_t_specialcol, “ Formatação de Colunas
END OF t_relat.

2. Rotinas para Formatação do Layout
2.1. PERFORM f_evento_lista. " Eventos da Lista
O evento mais comum a ser definido é o TOP_OF_PAGE para impressão do

cabeçalho na lista
Executar a função para selecionar todos os eventos possíveis de serem
tratados
CALL FUNCTION 'REUSE_ALV_EVENTS_GET'

EXPORTING
I_LIST_TYPE = 0
IMPORTING
ET_EVENTS = t_event.
* Ler a tabela para o evento TOP_OF_PAGE
READ TABLE t_event WITH KEY NAME = SLIS_EV_TOP_OF_PAGE

INTO w_event.
Se o evento foi encontrado então cadastrar o nome do form do seu programa

(que trata o cabeçalho) no campo FORM
IF SY-SUBRC = 0.
MOVE 'F_CABECALHO' TO w_event-form.
APPEND w_event TO t_event.
ENDIF.
Criar o FORM F_CABECALHO

Criar o FORM f_cabeçalho e inserir o código abaixo.
CALL FUNCTION 'REUSE_ALV_COMMENTARY_WRITE'

EXPORTING
it_list_commentary = l_top_of_page.
Outros eventos que retornarão da função e podem ser tratados :

CALLER_EXIT
USER_COMMAND
TOP_OF_PAGE
TOP_OF_COVERPAGE
END_OF_COVERPAGE
FOREIGN_TOP_OF_PAGE
FOREIGN_END_OF_PAGE
PF_STATUS_SET
LIST_MODIFY
TOP_OF_LIST
END_OF_PAGE
END_OF_LIST
AFTER_LINE_OUTPUT
BEFORE_LINE_OUTPUT
REPREP_SEL_MODIFY SUBTOTAL_TEXT
Estes eventos estão gravados dentro do Tipo SLIS

2.2. PERFORM f_cabec_lista. " Cabecalho da Lista
Neste FORM iremos criar os textos que deverão sair no cabeçalho do

relatório.
* Texto Principal - Header

CLEAR w_line.
w_line-typ = 'H'.
w_line-info = text-h01.
APPEND w_line TO t_top_of_page.
No campo TYP deverá ser informado:
H – Header
S – Selection
A – Action
Estes tipos irão colocar os textos em formatos diferentes (letra, negrito ou

itálico). Estas informações serão gravadas na tabela interna T_TOP_OF_PAGE

2.3. PERFORM f_layout. " Layout Geral da Lista
Neste FORM iremos formatar o relatório nos parâmetros gerais, ou seja, a

aparëncia do relatório.
Veja abaixo os campos que podem ser formatados :
Campo Descrição
Parâmetros Gerais
no_colhead Sem Títulos (Cabeçalho)
no_hotspot Títulos sem Hotspot
no_vline Colunas separadas por espaços
Zebra Listrado (Uma linha clara outra escura)
cell_merge Não suprimir a replicação de campo
Edit Edição somente para o grid todo
edit_mode Edição somente para o grid todo
numc_sum Total para campos numéricos
no_input Somente exibição de campos
f2code
Reprep
no_keyfix Não fixar coluna chave
expand_all Expandir todas as posições
no_author Nenhuma verificação padrão da autoridade
PF-status
def_status Status Default
item_text
Opções de Display
colwidth_optimize
no_min_linesize Tamanho da linha = tamanho da lista
min_linesize Default 80
max_linesize Default 250
Window_titlebar
no_uline_hs
Exceções
lights_fieldname Nome do campo para exceção
lights_tabname Nome da tabela para exceção
lights_rollname
lights_condense
Somatórios
no_sumchoice Sem escolha para Somar para cima
no_totalline Sem Total Linha
no_subchoice
no_subtotals Sem Sub-Total
no_unit_splitting
totals_before_items Mostrar total antes dos itens
totals_only Mostrar somente os totais
totals_text Texto para a 1a. coluna na linha de total
subtotals_text Texto para a 1a. coluna na linha de Sub-total
Interações
box_fieldname Nome do Campo para Checkbox

box_tabname
box_rollname
expand_fieldname
hotspot_fieldname Nome do Campo para Hotspot
confirmation_prompt Confirmar Saída da lista
key_hotspot keys as hotspot " K_KEYHOT
flexible_key Mover as colunas chaves
group_buttons Grupo de Botões
get_selinfos Ler tela de seleção
group_change_edit Settings by user for new group
no_scrolling Sem movimentar tela
 Detalhes
Tela
detail_popup Mostrar detalhes em nova janela
detail_initial_lines Mostrar somente as linhas iniciais
detail_titlebar Título para tela de detalhes
Mostar Variantes
header_text Texto para o botão
default_item
Cores
info_fieldname
Coltab_fieldname Nome do campo que conterá as cores das colunas
Outros
list_append Sem chamada de tela
xifunckey Extended interaction(SAPQuery)
xidirect Extended INTeraction(SAPQuery)
dtc_layout Configuração de layout para Tabstrip
Coluna Chave
Box_fieldn
ame

Tela de Detalhe
Titulo
Detalhe
Popup do detalhe
2.4. PERFORM f_sort. " Ordenação/SubTotal
Neste FORM você deve informar os campos pelos quais a lista deve ser
ordenada inicialmente, bem como se deve-se gerar sub-total ou total para esta
quebra.
Campo Centro
t_sort-spos = '1'.
t_sort-fieldname = 'WERKS'.
t_sort-tabname = 'T_RELAT'.
t_sort-up = 'X'.
t_sort-subtot = 'X'.
APPEND t_sort.
CLEAR t_sort.

Segue abaixo os campos que podem ser formatados para cada campo de
ordenação.
Campo Descrição
Spos Seqüência de Ordenação
fieldname Nome do campo
Tabname Nome da tabela a qual pertence o campo
Up Ordenação Menor para Maior
Down Ordenação Maior para Menor
Group
Subtot Gerar Sub Total
Comp
Expa
Obligatory
2.5. PERFORM f_info_campos.
Neste FORM você irá definir o layout de cada coluna do relatório.
Veja abaixo os campos que podem ser formatados :

Campo Descrição
row_pos Saída na linha (1,2,3,...)
col_pos Posição da coluna
fieldname Nome do campo
tabname Nome da tabela interna
currency Moeda
cfieldname Campo com Unidade de Moeda
ctabname Tabela referência para Unidade Moeda
ifieldname initial column
quantity Unidade de Medida
qfieldname Campo com Unidade Medida
qtabname Tabela com Unidade Medida
round Arredondar Campo
exponent Expoente para floats
key Campo como Chave
icon Campo como Ícone
symbol Campo como Símbolo
checkbox Campo como Checkbox
just Alinhamento – R (Direita) L (Esquerda) C (Centralizado)
lzero leading zero
no_sign Sem sinal
no_zero Não imprimir campos zerados
no_convext
edit_mask Máscara de Edição
emphasize Campo em destaque
fix_column Fixar Coluna
do_sum Totalizar Coluna
no_out Não exibir o campo
tech

outputlen Tamanho do campo para saída dos dados
Offset
seltext_l Descrição Longa do Campo
seltext_m Descrição Média do Campo
seltext_s Descrição Curta do Campo
Ddictxt Indicação de Qual descrição utilizar - (S)hort (M)iddle (L)ong
rollname
datatype Tipo do Campo
inttype Tipo do Campo
intlen Tamanho do Campo
lowercase Letra Minúscula
ref_fieldname Campo referência
ref_tabname Tabela referência
roundfieldname Nome campo para Arredondamento
roundtabname Nome tabela
decimalsfieldname Nome campo para Decimais
decimalstabname Nome tabela
decimals_out Número de decimais para escrever um número
text_fieldname
reptext_ddic Texto para a coluna
ddic_outputlen Tamanho do Campo
key_sel field not obligatory
no_sum Não totalizar o campo
sp_group Grupo
Reprep
Input Campo como input de dados
Edit Uso interno
Hotspot Campo como hotspot
2.6. PERFORM f_print.
Neste FORM você irá definir dados de impressão.

Campo Descrição
prnt_info Informações de Impressão
print
prnt_title
no_coverpage
no_new_page
reserve_lines Linhas reservadas para o final da página
no_print_listinfos Não imprimir página com número de registros selecionados
no_change_print_params Não alterar tamanho de linha

3. Exibir Relatório
Neste FORM você irá exibir o relatório.
v_repid = sy-repid.
CALL FUNCTION 'K_KKB_SAVE_MODE_GET'
IMPORTING
e_save = v_save.
CALL FUNCTION 'REUSE_ALV_GRID_DISPLAY'

EXPORTING
I_CALLBACK_PROGRAM = v_repid
I_CALLBACK_PF_STATUS_SET = 'F_SET_STATUS'
I_CALLBACK_USER_COMMAND = 'F_USER_COMMAND'
IS_LAYOUT = w_layout
IS_LAYOUT = w_print
IT_FIELDCAT = t_campos[]
IT_SORT = t_sort[]
I_DEFAULT = 'X'
I_SAVE = v_save
IS_VARIANT = variante
IT_EVENTS = t_event[]
TABLES
t_outtab = t_relat
EXCEPTIONS
PROGRAM_ERROR =1
OTHERS = 2.
IF sy-subrc <> 0.
MESSAGE ID sy-msgid TYPE 'I' NUMBER sy-msgno
WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
STOP.
ENDIF.

Como mudar cor de uma coluna
Para mudar a cor de uma coluna, você deve definir na sua tabela interna final
(que será utilizada na função de exibição do relatório) o campo COLINFO (ou o
nome que você desejar) que seja do tipo kkblo_t_specialcol.
Este campo será uma tabela interna onde você definirá para cada linha do
relatório a cor de cada coluna. Isso deve ser feito no momento em que você estiver
gerando a tabela final para a impressão.
Definir o campo na tabela interna final

Campo1
Campo2
Campo3
......
......
COLINFO TYPE kkblo_t_specialcol
END OF t_relat.
Definir uma workarea auxiliar :
CLEAR colinfo.
Nome da coluna a ser colorida

colinfo-fieldname = 'ATREXP'.
De acordo com o valor do campo a cor será diferente
IF t_relat-atrexp < 0.
colinfo-color-col = '3'. " Amarelo
ELSEIF t_relat-atrexp = 0.
colinfo-color-col = '5'. " Verde
ELSE.
colinfo-color-col = '6'. " Vermelho
ENDIF.
colinfo-color-int = '1'. " Intenso

APPEND colinfo TO t_relat-colinfo.
Os campos que devem ser formatados são :

FIELDNAME = Nome do campo na tabela interna
COLOR-COR = Número da cor
COLOR-INT = Intensidade da cor

1 : Intenso
Branco : cor normal
Como mudar a cor de uma linha
Para mudar a cor da linha toda e não somente de uma coluna você deve
seguir o mesmo procedimento da coluna porém fazer para todas as colunas do
relatório.
Por exemplo sua tabela tem 5 campos então :
Definir a tabela interna final

Campo1
Campo2
Campo3
Campo4
Campo5
COLINFO TYPE kkblo_t_specialcol
END OF t_relat.
Definir uma workarea auxiliar :

CLEAR colinfo.
Todas as colunas deverão ter a mesma cor e intensidade
colinfo-color-col = '3'. " Amarelo

colinfo-color-int = '1'. " Intenso
1a. Coluna
colinfo-fieldname = 'CAMPO1'.
2a. Coluna
colinfo-fieldname = 'CAMPO2'.
3a. Coluna
colinfo-fieldname = 'CAMPO3.
4a. Coluna
5a. Coluna

Como utilizar outros botões na tela
Para inserir novos botões na tela, você deve copiar o Status Gui Standard
STANDARD_FULLSCREEN para outro a ser utilizado no seu relatório. Após a cópia
você deve retirar botões que não serão utilizados e inserir os seus novos botões :
Botões Inseridos
O tratamento destes novos botões deverá ser no FORM F_USER_COMMAND

especificado na chamada da função de exibição do relatório :
CALL FUNCTION 'REUSE_ALV_GRID_DISPLAY'
form f_user_command USING p_ucomm LIKE sy-ucomm

p_selfield TYPE slis_selfield.
CASE p_ucomm.

* Modificar Documento
WHEN 'ZVA02'.
CHECK p_selfield-fieldname = 'VBELN'.
SET PARAMETER ID 'AUN' FIELD p_selfield-value.
CALL TRANSACTION 'VA02' AND SKIP FIRST SCREEN.
* Exibir Documento
WHEN 'ZVA03'.
SET PARAMETER ID 'AUN' FIELD p_selfield-value.
CALL TRANSACTION 'VA03' AND SKIP FIRST SCREEN.
* Exibir Remessa
WHEN 'ZVL01'.
READ TABLE t_relat INDEX p_selfield-tabindex.
IF sy-subrc EQ 0.
SET PARAMETER ID 'AUF' FIELD t_relat-vbeln.
SET PARAMETER ID 'VST' FIELD t_relat-vstel.
SET PARAMETER ID 'LEDAT' FIELD t_relat-mbdat.
CALL TRANSACTION 'VL01N' AND SKIP FIRST SCREEN.
ENDIF.
WHEN OTHERS.
ENDCASE.
endform. " f_user_command
Programas Standard - Modelo
BALVST02_GRID – Programa teste visor de listas ABAP: lista simples modelo vôo
BALVST03_GRID - Programa teste visor de listas ABAP: lista simples modelo vôo
BALVHT01 - Programa de teste ALV: lista seqüencial hierárquica modelo de vôo
Na versão 4.6 todos os programas BCALV*

13 –USER-EXITS
USER-EXIT – TRANSAÇÃO CMOD
1. Ir para : Utilitarios > Ampliações SAP
2. Executar (F8)

13 –USER-EXITS
3. Selecionar a User Exit e clicar em para exibir ou modificar
ATIVAR UMA USER EXIT
1. Procure o nome da função chamada por esta customer –function,

2. Vá, na SMOD, clique sobre o search help (ou F4) na ampliação

13 –USER-EXITS
3. Ao aparecer a proxima tela, clique no botão de “Sistema de Informação”
4. Na tela seguinte tem um botão que ativa todas as opções de pesquisa

( um que tem uma seta para baixo ) clique que ira aparecer todas as formas de
pesquisa possiveis

13 –USER-EXITS
5. Em nome do componente, digite o nome da função que você pegou na

primeira opção e mandar procurar;
6. Ira aparecer um nome de uma ampliação. Guarde esse nome.
7. Vá na transação CMOD e crie um projeto

13 –USER-EXIT
8. Tem um botão para associar ampliação ao projeto. Digite o nome da

ampliação que você pegou no item 6.
9. O Proximo passo é criar o codigo desejado para o funcionamento da user-

exit. Neste caso, entra na sua função ( ou via SE37 ou dentro da propria
CMOD ) e faça o codigo ( clique sobre o include que aparece dentro da
função para criar um programa separado )

Para ativar, na tela inicial da CMOD tem um botão especifico.
14 – FIELD-EXITS
FIELD-EXIT ->( Esta realciona a lógica do campo, ao passar o cursor )

TRANSAÇÃO CMOD – Para localizar uma FIELD-EXIT
MENU : IR PARA -> AMPLIAÇÕES GLOBAIS -> ELEMENTO DE DADOS ->

NOVO DOC.CLIENT.ED
FIELD AMARRAR EM UM PROJETO

14 – FIELD-EXITS
FIELD-EXIT – Na tela CMOD digitar = PRFB e dar Enter
Marcar o elemento de dados e clicar em

14 – FIELD-EXITS
CRIÇÃO DE FIELD-EXIT
1. Como primeiro passo, devemos executar a transação aonde iremos colocar o

FIELD-EXIT, e coletar os dados.
• Nome do Campo
• Elemento de dados
• Nome do Programa
• Numero da Tela
2. Em seguida executar a transação CMOD: Dentro da transação digitar na

caixa de dialogo PRFB e dar Enter.

3. No menu Superior escolher : Exit Campo -> Criar
14 – FIELD-EXITS
4. Informar o nome do elemento de dados
5. Criar a função para a FIELD-EXIT

6. Informar o Grupo de Funções e o texto breve
14 – FIELD-EXITS
7. Digitar o Código fonte da função e Salvar

8. Marcar o item criado e clicar em e preencher a tela que
será mostrada com o nome de programa e tela. Desta forma a FIELD-EXIT será
validada para este programa. Para ativar para todos os programas, não
preencher a tela apenas salvar.
14 – FIELD-EXITS
INFORMAÇÕES
A FIELD-EXIT, permite que seja feita alguma seleção ou checagem de um

determinado campo no programa e tela desejados.
Para isso, se faz necessário, buscar o elemento de dados do campo que se
deseja fazer a FIELD-EXIT.
Ir ate a transação CMOD, clicar AMPLIAÇÕES TEXTO(menu), depois
escolher Exits Campo, aparecerão todas as FIELD-EXITS existentes.
Para se criar uma nova.
• Exit Campo (menu)

• Criar
• Digitar o elemento de dados – Avançar
• Digitar o código – como uma função
• Depois clicar no botão atribuir prog/tela, colocando o nome do
progroma e o numero da tela, para pegar essas informações, clicar
em F1 e F9 no campo desejado.
• Visualiza ou modifica o conteúdo da Field, no botão Processar MF,
deve-se selecionar o elemento de dados desejado.
• Ativar a FIELD-EXIT.

IMPORTANTE: Na Field-Exit, você precisa pegar o valor desejado, para isso existe
a importação e a exportação, ou seja, as variáveis INPUT ou OUTPUT, você
precisa sempre colocar OUTPUT = INPUT, para que o valor possa voltar para tela
de origem.
OBSERVAÇÃO: A FIELD-EXIT apenas funcionara, se a mesma estiver ativa.

Workshop para Desenvolvedores ABAP/4

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Workshop para Desenvolvedores ABAP/4

Enviado por

Direitos autorais:

Formatos disponíveis

Sumário

Workshop para desenvolvedores ABAP/4 1

Workshop para desenvolvedores ABAP/4 2

Conceito breve do SAP

O SAP é um sistema que trabalha com um número muito grande de tabelas

ABAP é a linguagem de programação que a SAP criou para desenvolver as

Workshop para desenvolvedores ABAP/4 3

Falando em banco de dados o ABAP também tem suas particularidades, o

A área de trabalho dos desenvolvedores é chamada de ABAP Workbench e

Transação é um código alfanumérico de 20 caracteres, utilizado para iniciar

• ABAP Editor (SE38) – para escrita e edição de programas, mais utilizado

Workshop para desenvolvedores ABAP/4 4

O ambiente de trabalho do ABAP normalmente funciona da seguinte maneira:

• Ambiente de Desenvolvimento ( Client desenvolvimento ABAP e

Workshop para desenvolvedores ABAP/4 5

a de pré-produção e finalmente a de produção. Cada vez que o sistema é

Esse conceito de objeto client dependent e client independent é necessário

• Código fonte de programas – Independent

Os programas e outros objetos do repositório criados pelo cliente devem estar

Workshop para desenvolvedores ABAP/4 6

Ordens (Change Requests): Recurso através do qual um conjunto de

Geração de Arquivo de Controle (Interno SAP)

Objeto SAP (Interno SAP)

Workshop para desenvolvedores ABAP/4 7

Padronização ABAP Factory :

Ordem: 1 programa + objetos associados

nome_da_tarefa ou nome_do_produto - Geração Inicial

Controlando e Administrando Transportes

Quando uma ordem ainda permanece associado a um usuário, dizemos que

Quando uma ordem é encerrada, deixa de estar associado a um usuário e

Enquanto uma ordem possui o status Modifiable, pode-se manipular seus

Workshop para desenvolvedores ABAP/4 8

Transação SE10  Permite verificar os transportes de objetos Client Dependent e

Tais transações fornecem informações para que criemos a planilha de controle

Esta transação permite controlar as ordens (requests) geradas através das

Ordem tranportável: Alterações transportáveis para objetos do ABAP/4

Ordem Local: Alterações não transportáveis para objetos do ABAP/4 Development

Workshop para desenvolvedores ABAP/4 9

Clicando no botão de transportes podemos acompanhar todas as requests do

Workshop para desenvolvedores ABAP/4 10

Acessando pelo menu Ordem/tarefa  Procurar Ordens, podemos efetuar

Workshop para desenvolvedores ABAP/4 11

3 - Dicionário de Dados - Introdução

Conceitos de Bancos de Dados Relacionais

Workshop para desenvolvedores ABAP/4 12

Modelo desenvolvido para facilitar o projeto de banco de dados, permitindo a

Entidade: É um objeto que existe e é distinguível de outros objetos, ou seja,

Atributos: São os qualificadores de uma entidade, isto é, representam no modelo

Domínio: Conjunto de valores permissíveis para um atributo. Exemplo: Estado

Relacionamento: É a associação entre duas entidades, ou seja, representa a

Restrições de Mapeamento: Representam o modo como as diferentes entidades

Um-para-Um: Uma ocorrência da Entidade A está relacionada com uma e apenas

Um-para-N: Uma ocorrência da Entidade A está relacionada com uma ou várias

N-para-Um: Várias ocorrências da Entidade A estão relacionadas com apenas uma

N-para-N: Várias ocorrências da Entidade A está relacionada com várias

3 - Dicionário de Dados - Introdução

Um banco de Dados Relacional é a implementação física do Modelo Entidade-

Workshop para desenvolvedores ABAP/4 13

A cada linha da tabela chamamos de Ocorrência e o conjunto de ocorrências

Como distinguir as ocorrências umas das outras?

Utilizando o conceito de Chave Primária!!

Chave Primária: Conjunto de atributos que garante a unicidade de cada ocorrência

Normalização: Processo de reconhecimento da chave primária