Design de Aplicações - Parte 5

Cursor

O cursor deve ser posicionado pelo programador. A regra genérica é colocar o cursor em cada chamada PBO no campo onde esteve durante o último PAI (ou seja, manter o cursor no mesmo campo).

Portanto, o primeiro módulo do PAI obtém o cursor e o último módulo do PBO posiciona-o.

process before output.
*…

  module m_set_cursor.
process after input.
  module m_get_cursor.

*…

Estas chamadas repetem-se em todas as telas com campos em aberto. Os módulos chamam o seu respectivo form.

form f_get_cursor .
  data: l_cursor like w_cursor.
  get cursor field l_cursor-field line l_cursor-line 
             offset l_cursor-offset.
  if sy-subrc eq 0. " Cursor está nesta subtela
    w_cursor = l_cursor.
  endif.
endform.                    " F_GET_CURSOR

form f_set_cursor .
  if w_cursor is not initial.
    set cursor field w_cursor-field line w_cursor-line 
               offset w_cursor-offset.
  endif.
endform.                 " F_SET_CURSOR

Design de Aplicações - Parte 4

Telas

A informação das telas deve encontrar-se suficientemente dividida de modo a facilitar a manipulação da visualização pelo utilizador e de modo a restringir o tratamento dos campos.

Mockup das Telas do Exemplo

Regra geral existe um cabeçalho, uma tabela com os items e o detalhe do item seleccionado. No exemplo existe ainda um topo com alguns campos que determinam a execução.

Algumas áreas têm mais que uma subtela atribuída como a 0100 e 0101 com o objectivo de expandir ou colapsar essa área. A diferença entre estas duas está no nº de linhas dos contentores para as subtelas dos items e do item que permite visualizar mais linhas de items se a subtela do item está colapsada.

Existe ainda uma subtela vazia, 0001, que é usada pelas áreas de lote e nº série quando esses dados não existem.

O colapso é controlado substituindo a tela, por exemplo, esta é a tela 0120, o cabeçalho expandido:

Cabeçalho Expandido

Quando se pressiona o botão  a subtela é substituída pela 0121, que apenas contém o botão para trocar novamente a subtela:

Cabeçalho minimizado

Os campos e as descrições devem ser construídos com algum cuidado visual, devidamente alinhados e comprimento adequado. As descrições dos campos devem sempre que possível referenciar o elemento de dados para que apareça o texto standard e apresentarem-se como denominação à esquerda de forma a aparecer uma sublinha a ligar a descrição ao campo.

Detalhe do texto de descrição referente ao campo nº de série

Já os campos devem ser criados com os dados exactos do dicionário de dados. Por regra crio o campo com um existente no dicionário de dados para obter o tipo de dados, comprimento, rotinas de conversão, ajudas de pesquisa, etc., e depois altero para o nome correcto.

Por exemplo, crio o campo nº de série com o nome EQUI-SERNR:

Passo 1 de criação de campo

Aceito a referencia ao dicionário e depois altero o nome do campo para o correcto, w_data-top-ref-sernr:

Passo 2 de criação de campo

Design de Aplicações - Parte 3

Apresentação

Como já foi mencionado, é boa prática seguir os exemplos das transacções Enjoy SAP. Nesse sentido o resto do documento vai acompanhar um exemplo de uma aplicação desenvolvida para registar movimentos de mercadoria para fabrico e desfabrico de materiais seriados baseada na transacção standard MIGO.

Aplicação de Fabricos e Desfabricos

Transacções

Vários casos em SAP usam diferentes códigos de transacção para a mesma aplicação. Tipicamente tal acontece para as transacções de Criação, Modificação e Exibição do mesmo documento. O facto de existir diferentes transacções pode ser útil na criação de autorizações e dos menus. Um exemplo desses casos é o grupo de transacções ME21N, ME22N e ME23N para a gestão de ordens de compra. Mas também existem casos de canivetes suíços em que a mesma transacção tem diferentes utilizações sobre o mesmo tipo de documento, como por exemplo a MIGO para os movimentos de mercadoria.

O exemplo apresentado tem três transacções, uma para fabrico outra para desfabrico e ainda outra genérica que consegue fazer as duas actividades. O código da transacção está associado a diferentes perfis, para além de que cada uma pré-preenche alguns campos de forma distinta.

Neste caso não existe transacção de exibição ou modificação uma vez que tal consegue-se pela MIGO.

Transacções do exemplo

Includes

A organização de includes segue a lógica proposta pela SAP, ou seja, o sufixo determina o tipo de conteúdo. Os seguintes prefixos são os normalmente usados:

·         F++ - forms

·         I++ - módulos PAI

·         O++ - módulos PBO

·         TOP – tipos, variáveis globais, constantes e outros objectos globais

·         SCR – subtelas de selecção

Includes do exemplo

O número do sufixo permite separar em diferentes includes objectos com objectivos diferentes. Por exemplo, eu tenho tendência em colocar os módulos gerados automaticamente para os tabstrips e table controls em includes separados.