Já te aconteceu o SAPGui não guardar um histórico dos valores que vais introduzindo nos vários campos ainda que, nas configurações, a opção de Histórico esteja activa?

Este aparente paradoxo pode dever-se ao facto de, no SAP Logon, a tua ligação a este servidor SAP estar configurada como “conexão lenta (tráfego de rede reduzido)” em vez de “conexão rápida (LAN)”. Nesse caso o histórico é automaticamente desactivado.

Obscuro.

(Obrigado a unaluzazul pela foto)

O Abapinho saúda-vos.

Na transacção SE80 há de tudo. Parece aquelas mercearias de aldeia atafulhadas de tralha onde se compra pasta de dentes, pão, sandálias, perfume e arroz a granel. Eu gosto dessas mercearias. Mas para lá ir é preciso saber ao que se vai, senão anda-se ao tio ao tio.

Mas isso é nesses mercearias, porque na SE80… há favoritos.

Pois é. Só soube há uns dias que a transacção SE80 tem a capacidade de guardar favoritos. É um botãozinho logo ali à mão. Vejam a foto:

De cada vez que se visita um objecto que se acredita vir a visitar mais vezes no futuro, é só inseri-lo na lista de favoritos e assim nunca mais se tem de andar à procura dele.

Obrigado Nuno Morais pela dica.

E obrigado a ~suchitra~ pela foto.

O Abapinho saúda-vos.

Num relatório, os valores são normalmente pedidos ao utilizador no ecrã de selecção inicial, antes da execução do programa. Mas e se quiseres pedir-lhe mais alguns valores, interactivamente, a meio da execução do programa?

Uma forma de o fazer é criar um ecrã com os campos desejados e depois invocá-lo com CALL SCREEN. Mas desenhar o ecrã e definir o PAI e o PBO é uma valente maçada.

Outra solução é recorrer às funções POPUP_GET_VALUES ou POPUP_GET_VALUES_DB_CHECKED. São bastante versáteis mas ainda assim algo chatas de utilizar e com algumas limitações.

Mas há uma forma mais simples de o fazer. É através do CALL SELECTION-SCREEN. Passo a explicar:

Primeiro há que definir o ecrã de selecção. A sua definição é praticamente igual à do ecrã de selecção inicial de um relatório:

TABLES: t001.

SELECTION-SCREEN BEGIN OF SCREEN 3000.
PARAMETERS: p_uname TYPE syuname.
SELECT-OPTIONS: p_bukrs FOR t001-bukrs.
SELECTION-SCREEN END OF SCREEN 3000.

Depois, onde quer que te apeteça invocar o ecrã é só… invocares o ecrã:

START-OF-SELECTION.

* faz não sei quê antes

  CALL SELECTION-SCREEN 3000 STARTING AT 5 5.

* e mais não sei quê depois

E dá nisto:

Se meteres o STARTING AT ele vai criar uma janela de diálogo modal. Se não meteres nada, o ecrã ocupará a janela toda. O ecrã de selecção pode ser tão complicado quanto quiseres, podendo incluir abas e tudo o mais. Além disso, porque para o SAP ele não passa de um ecrã de selecção como os outros, poderás gravar variantes e tudo.

Nota que esta abordagem pode também ser usada em transacções, sendo a única desvantagem o facto de exigir F8 em vez de ENTER para submeter os valores.

Obrigado a cristinacosta pela foto.

O Abapinho saúda-vos.

Os ecrãs de selecção dos programas ABAP têm várias funcionalidades que, embora sofisticadas e simples de usar, são geralmente ignoradas. Aqui mostrar-te-ei quão simples é criar abas para melhor organizar os parâmetros de um programa. Desta vez, excepcionalmente, vou poupar-te à verborreia. É uma aula prática.

Vamos lá. O nosso ecrã de selecção terá 3 abas que representam 3 grupos distintos de parâmetros.

Como o que tem que ser tem muita força, comecemos pela declaração de dados:

REPORT  zzz_nfg_selscreen_tabs2.

TABLES: kna1.

DATA: ucomm1 LIKE sy-ucomm,
      ucomm2 LIKE sy-ucomm,
      ucomm3 LIKE sy-ucomm.

A tabela KNA1 é declarada porque vai ser usada em SELECT-OPTIONS e as outras 3 variáveis são declaradas porque, embora como irão constatar, não sejam usadas para nada, é preciso declará-las senão o programa não compila.

Agora declaramos os 3 sub-ecrãs:

* Sub-ecrã: Filtros KNA1
SELECTION-SCREEN BEGIN OF SCREEN 3010 AS SUBSCREEN.
SELECT-OPTIONS: s_kunnr FOR kna1-kunnr,
                s_land1 FOR kna1-land1,
                s_ktokd FOR kna1-ktokd.
SELECTION-SCREEN END OF SCREEN 3010.

* Sub-ecrã: Opções
SELECTION-SCREEN BEGIN OF SCREEN 3020 AS SUBSCREEN.
PARAMETERS: p_opt1 AS CHECKBOX,
            p_opt2 AS CHECKBOX,
            p_opt3 AS CHECKBOX.
SELECTION-SCREEN END OF SCREEN 3020.

* Sub-ecrã: Ficheiro
SELECTION-SCREEN BEGIN OF SCREEN 3030 AS SUBSCREEN.
PARAMETERS: p_file TYPE rlgrap-filename DEFAULT '/ficheiro.txt'.
SELECTION-SCREEN END OF SCREEN 3030.

Agora que temos os sub-ecrãs definidos é só aplicá-los num TABBED BLOCK:

* Bloco normalíssimo só porque sim
SELECTION-SCREEN BEGIN OF BLOCK b1 WITH FRAME TITLE text-b01.
PARAMETERS: p_uname TYPE uname OBLIGATORY.
SELECTION-SCREEN END OF BLOCK b1.

* Tabbed strip
SELECTION-SCREEN BEGIN OF TABBED BLOCK tabs FOR 3 LINES.
SELECTION-SCREEN TAB (15) tab1 USER-COMMAND ucomm1 DEFAULT SCREEN 3010.
SELECTION-SCREEN TAB (30) tab2 USER-COMMAND ucomm2 DEFAULT SCREEN 3020.
SELECTION-SCREEN TAB (15) tab3 USER-COMMAND ucomm3 DEFAULT SCREEN 3030.
SELECTION-SCREEN END OF BLOCK tabs.

Como vês, é simples. As variáveis TAB1, TAB2 e TAB3 são declaradas implicitamente e deverão conter os títulos das abas. Já as variáveis UCOMM1, UCOMM2 e UCOMM3 têm de ser declaradas explicitamente e definem o comando que poderá ser usado no SELECTION-SCREEN OUTPUT (equivalente ao PAI dos ecrãs) para controlar qualquer coisa adicional, mas neste caso não as vamos usar para mais nada.

O primeiro bloco com o P_UNAME está ali só para mostrar que os TABBED BLOCKS podem conviver com outros blocos normais.

Só falta definirmos os títulos das abas:

INITIALIZATION.
  tab1 = 'Filtros KNA1'(t01).
  tab2 = 'Opções'(t02).
  tab3 = 'Ficheiro'(t03).

Já está. E o resultado é este:

A partir daqui é o START-OF-SELECTION e o resto do programa é igual ao que seria sem as abas.

Ainda está a milhas do Adobe Flex, mas é melhor do que nada.

Obrigado a ensee_89 pela foto.

O Abapinho saúda-vos.

Há determinados momentos em que não é possível fazer /H para iniciar o debugger. O caso mais comum é durante uma janela de diálogo modal (aquilo que os estrangeiros chamam de popup). Mas há uma forma simples, ainda que rocambolesca, para o conseguires:

1. Cria um ficheiro de texto com o seguinte conteúdo:
[FUNCTION]
Command=/H
Title=Debugger
Type=SystemCommand

2. Grava o ficheiro numa pasta ou no ambiente de trabalho;

3. Arrasta (aquilo que os estrangeiros chamam de drag and drop) o ficheiro de onde o gravaste para cima da janela de diálogo ao mesmo tempo que gritas ABRACADABRA.

E assim, desta forma estrambólica, como que por magia, se tiveres gritado, o modo de debug será activado para teu regozijo.

É verdade que provavelmente já toda a gente conhece esta dica, mas é tão fundamental que me pareceu ser obrigação do Abapinho ensiná-la.

(Obrigado a alandberning pela foto)

O Abapinho saúda-vos.

Queres obter o texto de uma mensagem da qual só sabes o ID e o número e não sabes como? Aprende aqui:

DATA texto TYPE string.
MESSAGE ID '00' TYPE 'E' NUMBER '163' WITH '123' INTO texto.

É só isto. Agora do lado de dentro da variável texto encontras o seguinte texto:

“O mandante 123 não existe no sistema”

Obrigado a Peteris B pela foto.

O Abapinho saúda-vos.

Para tentar determinar quais as profissões com gente mais preguiçosa fiz as seguintes pesquisas no Google:

Como se pode concluir inequivocamente, os engenheiros não são suficientemente preguiçosos pois são ultrapassados pelos advogados e pelos médicos. Isto tem de mudar. E esta dica vai ajudar. Mas não sem deixar clara a seguinte diferença: preguiça não é ergasiofobia. Falo aqui da preguiça nobre, a de quem gosta de fazer as coisas mas procura fazê-las com o mínimo esforço possível. Já os preguiçosos mandriões, esses não são para aqui chamados.

O SAP, que lá vai evoluindo lentamente, lançou já há uns anos um editor novo que vem cheio de capacidades muitas das quais, ainda que convenientes, são pouco aproveitadas. Uma delas chama-se “Modelos de código” que passo a apresentar:

1. Vai à SE38 ou à SE24 ou à SE37 ou qualquer outra transacção que apresente o editor de ABAP;
2. No canto inferior direito há um ícone com ar de clipboard. Clica nele;
3. Aparecem-te as opções do editor;
4. Nas opções à esquerda escolhe “Modelos de código”;
5. Aí encontras vários modelos já pré-definidos (ex: TRY) e podes definir outros só teus.

Aqui a definição dos modelos de código:

Enquanto escreves código basta que em qualquer sítio escrevas o nome de um dos modelos e carregues em TAB para que esse nome seja substituído pelo seu modelo.

Dica dentro da dica: ideal para aquelas linhas “eu estive aqui!” que são apanágio de qualquer martelada em código alheio.

Toca a ser preguiçoso!

O Abapinho saúda-vos.

Sabes apresentar, numa janela de diálogo, uma ALV com uma lista de registos permitindo escolha múltipla? Eu não sabia e agora já sei. Vou explicar como é.

Faz de conta que queres escolher uns clientes:

DATA: t_kna1 TYPE STANDARD TABLE OF kna1.

SELECT * FROM kna1 INTO TABLE t_kna1.

Pronto, agora já enchemos à bruta uma tabela interna com os clientes todos. O próximo passo é criar o catálogo de campos:

  DATA: ls_fieldcat TYPE slis_fieldcat_alv,
        lt_fieldcat TYPE slis_t_fieldcat_alv.

  CLEAR ls_fieldcat.
  ls_fieldcat-row_pos   = '1'.
  ls_fieldcat-tabname   = 'T_KNA1'.

  ls_fieldcat-col_pos   = '1'.
  ls_fieldcat-fieldname = 'CHECKBOX'.
  ls_fieldcat-seltext_m = 'SELECT'.
  APPEND ls_fieldcat TO lt_fieldcat.

  ls_fieldcat-col_pos   = '2'.
  ls_fieldcat-fieldname = 'KUNNR'.
  ls_fieldcat-seltext_m = 'Nº cliente'.
  ls_fieldcat-outputlen = 10.
  APPEND ls_fieldcat TO lt_fieldcat.

  ls_fieldcat-col_pos   = '3'.
  ls_fieldcat-fieldname = 'NAME1'.
  ls_fieldcat-seltext_m = 'Nome'.
  ls_fieldcat-outputlen = 35.
  APPEND ls_fieldcat TO lt_fieldcat.

Claro que o catálogo pode ser criado automaticamente recorrendo à FM REUSE_ALV_FIELDCATALOG_MERGE se for caso disso. Mas nota que, para poder fazer a selecção múltipla, terás de adicionar uma coluna chamada CHECKBOX (ou com o nome que bem entenderes).

A seguir vamos criar uma tabela com as funções a excluir da ALV (para que em vez de aparecerem todos os comandos apareçam apenas o OK e o CANCEL:

  DATA: lt_excl     TYPE slis_t_extab,
        ls_excl     TYPE slis_extab.

  ls_excl-fcode = '&ETA'. APPEND ls_excl TO lt_excl.
  ls_excl-fcode = '%SC'.  APPEND ls_excl TO lt_excl.
  ls_excl-fcode = '%SC+'. APPEND ls_excl TO lt_excl.
  ls_excl-fcode = '&OUP'. APPEND ls_excl TO lt_excl.
  ls_excl-fcode = '&ODN'. APPEND ls_excl TO lt_excl.
  ls_excl-fcode = '&ILT'. APPEND ls_excl TO lt_excl.
  ls_excl-fcode = '&OL0'. APPEND ls_excl TO lt_excl.
  ls_excl-fcode = '&CRB'. APPEND ls_excl TO lt_excl.
  ls_excl-fcode = '&CRL'. APPEND ls_excl TO lt_excl.
  ls_excl-fcode = '&CRR'. APPEND ls_excl TO lt_excl.
  ls_excl-fcode = '&CRE'. APPEND ls_excl TO lt_excl.
  ls_excl-fcode = '&ALL'. APPEND ls_excl TO lt_excl.
  ls_excl-fcode = '&SAL'. APPEND ls_excl TO lt_excl.

Depois chamamos a função mágica que faz aparecer o popup com a ALV:

  CALL FUNCTION 'REUSE_ALV_POPUP_TO_SELECT'
    EXPORTING
      i_zebra              = 'X'
      it_fieldcat          = lt_fiedcat
      i_tabname            = 'T_KNA1'
      i_screen_start_column = 1
      i_screen_start_line   = 1
      i_screen_end_column   = 100
      i_screen_end_line     = 25
      i_checkbox_fieldname = 'CHECKBOX'
    TABLES
      t_outtab             = t_kna1.

Esta função mostra o popup que permite ao utilizador seleccionar um ou mais registos. Quando o utilizador carrega em OK ou CANCEL, o programa continua e podemos utilizar o campo CHECKBOX para determinar quais as linhas por ele seleccionadas:

  LOOP AT it_output INTO wa_output WHERE checkbox = 'X'.
"  Faz aqui o que te apeteceer
  ENDLOOP.

E já está.

Obrigado a Ayelie pela foto.

O Abapinho saúda-vos.

Às vezes pergunto-me qual será, no mundo, a percentagem de código ABAP desnecessário. Um exemplo paradigmático de como se pode desperdiçar tempo a escrever código que não serve para nada e só prejudica é a tão frequente definição das descrições dos campos de uma ALV directamente em ABAP.

Cenário típico:

1. define-se uma tabela interna
2. preenche-se essa tabela com dados
3. constrói-se o catálogo de campos da ALV
4. apresenta-se a ALV

Não é incomum a definição do catálogo de campos extender-se por centenas de linhas, as quais se limitam a definir a ordem, o tipo de dados ou as descrições de cada um dos campos.

O problema começa logo no passo 1, a definição dos dados:

TYPES: BEGIN OF ty_data,
             campo1 TYPE char10,
             campo2 TYPE char15,
             campo3 TYPE char10,
             campo4 TYPE i,
          END OF ty_data.
DATA: t_data TYPE STANDARD TABLE OF ty_data.

E continua no passo 3 porque, como esta definição de dados não explicita um contexto semântico para cada campo, depois, claro está, há que construir à mão o catálogo de campos da ALV:

DATA: o_table TYPE REF TO cl_salv_table,
          o_columns       TYPE REF TO cl_salv_columns.

cl_salv_table=>factory(
  IMPORTING
    r_salv_table = o_table
  CHANGING
    t_table      = t_data ).

o_columns = o_table->get_columns( ).

o_column = in_columns->get_column( 'CAMPO1' ).
o_column->set_short_text(  'Textito1' ).
o_column->set_medium_text( 'Texto 1' ).
o_column->set_long_text(   'Textão 1' ).

o_column = in_columns->get_column( 'CAMPO2' ).
o_column->set_short_text(  'Textito2' ).
o_column->set_medium_text( 'Texto 2' ).
o_column->set_long_text(   'Textão 2' ).

o_column = in_columns->get_column( 'CAMPO3' ).
o_column->set_short_text(  'Textito3' ).
o_column->set_medium_text( 'Texto 3' ).
o_column->set_long_text(   'Textão 3' ).

(etc... )

o_table->display( ).

Ora uma solução muito simples para evitar estar a espalhar descrições dos campos pelo código é, em vez de definir a estrutura de dados directamente no código, usar uma estrutura do DDIC em que cada campo tem o seu contexto semântico devidamente definido através de um elemento de dados que contém já as descrições que se pretende ver aparecer no ALV. Assim, já não é preciso definir programaticamente nem as descrições nem a ordem nem o tipo dos campos pois tudo isto será deduzido automaticamente pelas classes/funções das ALV:

DATA: t_data TYPE STANDARD TABLE OF zxxxxx_alv,
          o_table TYPE REF TO cl_salv_table.

cl_salv_table=>factory(
  IMPORTING
    r_salv_table = o_table
  CHANGING
    t_table      = t_data ).

o_table->display( ).

Poupam-se dezenas ou centenas de linhas no programa e além disso, desta forma os campos podem ser traduzidos, o que não é de pouca monta (cristalizar descrições no código é sempre de evitar). E se no futuro for necessário alterar a descrição de um campo basta modificar o elemento de dados a ele associado na estrutura. Cada coisa em seu lugar.

Como exemplo, um cenário real com que me deparei há uns dias: num relatório que apresentava os dados numa ALV foi-me pedido para adicionar a possibilidade de, ao invés, gravar os dados num Excel. Implementei esta opção (recorrendo ao fantástico ABAP2XLSX do qual falarei em breve) e depois constatei que os nomes das colunas no Excel eram todos feios tipo "CHAR10" ou descontextualizados tipo "Description" e "Text". Constatei que o programa até usava uma estrutura, mas os seus campos estavam definidos com elementos de dados genéricos. O catálogo de campos era modificado à mão sendo todas as descrições introduzidas programaticamente. Ora como o ABAP2XLSX também tem um catálogo de campos a solução mais simples e parva seria adicionar também as descrições ao catálogo de campos do ABAP2XLSX. Mas a solução melhor e mais saudável foi definir correctamente os elementos de dados da estrutura. Depois os campos passaram a aparecer automaticamente bem tanto no ALV como no Excel. E ainda pude apagar do programa todas as descrições directamente programadas.

(Obrigado Editor B pela imagem.)

O Abapinho saúda-vos.

Por vezes um programa quer gravar um ficheiro localmente, no computador do utilizador através do SAP Gui. Nesses casos é comum que um dos campos do ecrã de selecção seja a localização da pasta no disco local.

Eis uma forma de inicializar esse campo com a pasta temporária do SAP Gui:

PARAMETERS: p_path TYPE string.

AT SELECTION-SCREEN ON VALUE-REQUEST FOR p_path.
  CALL METHOD cl_gui_frontend_services=>directory_browse
    EXPORTING
      initial_folder  = p_path
    CHANGING
      selected_folder = p_path.

INITIALIZATION.
  CALL METHOD cl_gui_frontend_services=>get_sapgui_workdir
    CHANGING
      sapworkdir = p_path.
  CALL METHOD cl_gui_cfw=>flush.

Obrigado Sérgio Fraga pela dica.

E obrigado HatM pela foto.

O Abapinho saúda-vos.

Claro que já conheces a transacção SE30 (Análise de tempo de execução) e claro que a usas amiúde para analisar programas standard e descobrir nele tabelas, funções, BADIs e quejandos.

Ora se fores como eu, manténs uma relação de amor-ódio com esta transacção: se por um lado a amas por graças a ela consegues ver as entranhas de um programa sem ter de fazer debug, por outro lado odeia-la porque normalmente a lista de entranhas costuma ter milhares de linhas e tornar-se ingerível.

Mas eu já não sou como eu porque, desde que descobri que a SE30 permite fazer análises parciais, a minha relação com ela passou a ser de puro amor. E a partir de agora também tu poderás amá-la na sua totalidade porque vou ensinar-te este segredo.

1. Transacção SE30;
2. No bloco “Restrições de medição” cria uma variante com um nome qualquer diferente do DEFAULT;
3. Na variante activa o pisco “Unidades determinadas”;
4. Insere a transacção ou programa ou módulo de função a analisar;
5. Carrega em “Executar” (normalmente agora a análise começaria mas, como escolhemos “unidades determinadas”, começa desligada e é preciso ligá-la explicitamente);
6. Navega dentro do programa que estás a analisar até chegares ao ponto que queres analisar;
7. Activa a análise escrevendo /ron lá em cima no campo de comandos;
8. Faz o que tens a fazer;
9. Desactiva a análise escrevendo lá em cima /roff;
10. Sai do programa, voltando ao ecrã da SE30.

Acabaste de fazer uma análise parcial que, em vez dos típicos milhares de linhas, tem apenas as dezenas ou centenas de linhas que ocorreram entre os comandos /ron e /roff. Mais útil, não?

Aproveita o balanço e explora as outras possibilidades disponibilizadas pelas variantes de “restrição de medição”.

Obrigado a Michael Opoczynski pelo ensinamento.

E obrigado a * Cati Kaoe * pela foto.

O Abapinho saúda-vos.

O SAP é um grande poliglota. Mas o ABAP nem sempre. O ABAP até tem muita facilidade em aprender e falar várias línguas, mas às vezes os programadores não o deixam.

Muitos programadores cinzelam os textos literais directamente no programa, deixando-o irremediavelmente incapaz de comunicar em vários idiomas. Imagino duas razões para se agrilhoar um programa a uma única língua:

• A preguiça, que é a principal razão para se fazerem as coisas mal feitas;
• A legibilidade. Realmente a forma de tornar um programa ABAP localizável é pejá-lo com referências a textos, tipo TEXT-001, o que pode torná-lo bastante ilegível.

Então aqui fica uma dica para ter o melhor dos dois mundos: um programa localizável que não perca a legibilidade:

Em vez de seres preguiçoso e fazeres:

WRITE: 'Eu quero ver auroras boreais'.

E em vez de seres obscuro e fazeres:

WRITE: TEXT-001.

Sê esperto e faz:

WRITE: 'Eu quero ver auroras boreais'(001).

E já está.

Se o text TEXT-001 estiver definido na língua em que o programa estiver a correr este TEXT-001 será usado. Caso contrário, o texto literal escrito directamente no programa será usado. Assim mantém-se a legibilidade do código, pode traduzir-se os textos à vontade e ainda por cima temos a certeza de que, mesmo quando faltar traduzir algum texto, mesmo assim aparecerá o texto que está no programa.

Obrigado Sérgio Lopes pela dica.

(E obrigado doug88888 pela foto)

O Abapinho saúda-vos.

Durante doze anos
Quando quis contar
As linhas de uma itab
Fazia o que todos fazem:
DESCRIBE TABLE itab LINES linhas.

Até que outro dia
Vi uma coisa que,
Parece mentira,
Nunca antes vira:
LINES( itab ).

Dá no mesmo
E sem ter de declarar
O raio da variável.

Assim, em vez de:

DATA: linhas TYPE i.
DESCRIBE TABLE itabl LINES linhas.
IF linhas = 42.
  WRITE 'A tua tabela é a verdade'.
ENDIF.

Basta fazer:

IF LINES( itbl ) = 42.
  WRITE 'A tua tabela é a verdade'.
ENDIF.

É a prova de que
Se a SAP quisesse
Fazia um esforço
E o ABAP seria
Uma coisa fixe.

Mas parece que não quer
E o ABAP que se lixe.

Merda de poema. Foi o que se arranjou.

O Abapinho saúda-vos.

Nos módulos AT SELECTION-SCREEN de um REPORT é-te possível lançar mensagens de erro e voltar ao ecrã de selecção. Mas uma vez que passes do START-OF-SELECTION, se lançares uma mensagem de erro, o programa termina. A solução para dar um erro e, ainda assim, regressar ao ecrã de selecção, é travestir a mensagem:

START-OF-SELECTION.
  IF condicao_desejada.
    MESSAGE S001(00) with 'Erro!' DISPLAY LIKE 'E'.
    EXIT.
  ENDIF.
  WRITE 'Olá, eu sou o resto do programa'.

A mensagem do tipo S mascarou-se de E. Parece que É, mas não É.

Se experimentares vais ver que o sistema dá erro mas não sai completamente do programa; Volta ao ecrã de selecção e não corre o resto do programa (por causa do EXIT).

Obrigado Sérgio Lopes pela dica.

(E obrigado Tiago Celestino pela foto)

O Abapinho saúda-vos.

Nunca te aconteceu esbarrares com uma coisa no ABAP que parece que é mas não é? A documentação diz que é, tudo indica que assim seja, e depois afinal não é.

Provavelmente já precisaste de, ao definir um parâmetro no ecrã de selecção de um relatório, limitar as possibilidades do que o utilizador pode introduzir aos valores disponíveis no tipo de dados desse parâmetro, certo? Para isto existe o VALUE CHECK. Parece simples. Por exemplo, presumia-se que isto funcionasse:

PARAMETERS: P_BUKRS LIKE T001-BUKRS OBLIGATORY VALUE CHECK.

Vais a ver e não funciona.

O campo T001-BUKRS é do tipo BUKRS que é do domínio BUKRS que por sua vez tem definida a tabela de valores T001 para a qual BUKRS é a única chave primária. Mesmo assim, pateticamente, isto não funciona. Não funciona porque, por alguma razão lamentável, ao contrário do que faria sentido e se subentende na documentação, o VALUE CHECK não tem em conta o domínio do campo que valida. Pelo contrário, para este funcionar é preciso que o campo referido tenha uma chave externa para a tabela de valores.

Portanto, no nosso caso, embora a tabela que contém a lista de valores possíveis do BUKRS seja a T001, para o VALUE CHECK funcionar temos antes de fazer referência a uma outra tabela qualquer que tenha a T001 definida como chave externa. Como por exemplo, a T001K:

PARAMETERS: P_BUKRS LIKE T001K-BUKRS OBLIGATORY VALUE CHECK.

E assim já funciona.

Em resumo: conhecendo já tu a tabela com os valores possíveis, em vez de a poderes usar, tens de ir procurar outra que a defina como chave externa. É complicar o simples com rodeios. Um retórico chamar-lhe-ia circunlóquio. Eu chamo-lhe estupidez. Aposto que é um bug que a SAP decidiu orgulhosamente ignorar para sempre.

Obrigado Luís Rocha pela dica.

O Abapinho saúda-vos.

Quando se está a desenvolver um relatório com um ecrã de selecção, é muito chato de cada vez que o testamos ter de preencher o ecrã de selecção com os dados de teste. Normalmente acabamos por criar uma variante de teste para nos poupar a esse chatice. Mas mesmo assim, de cada vez que corremos o relatório, temos de invocar manualmente esta variante.

Aqui está uma forma simples de invocar automaticamente uma variante. Este código pode ser inserido no evento INITIALIZATION durante o desenvolvimento do programa:

INITIALIZATION.

  CALL FUNCTION 'RS_SUPPORT_SELECTIONS'
    EXPORTING
      report                     = sy-repid
      variant                    = 'TESTE'
 EXCEPTIONS
   VARIANT_NOT_EXISTENT       = 1
   VARIANT_OBSOLETE           = 2
   OTHERS                     = 3.

Obrigado Sérgio Fraga pela dica.

(E obrigado a Telstar Logistics pela foto)

O Abapinho saúda-vos.

Classes. Sempre as houve entre as pessoas. Mas no ABAP ainda há poucos que as tenham em conta. Se ser classicista na sociedade pode resultar em pedantismo, no ABAP, a única luta de classes é a que alguns travam para que estas sejam mais usadas.

Há dois tipos de classes: as globais e as locais. As globais são criadas na transacção SE24. As locais, que por sinal dou por mim a usar cada vez mais, são feitas declarativamente na SE38. Se soubermos que a nossa classe vai ser usada amiúde, faz sentido criá-la global. Se, pelo contrário, a classe for particular a um programa, não há porque fazer dela um objecto autónomo, bastando assim criá-la local ao programa que a vai usar.

Não é impossível que uma classe local se venha mais tarde a revelar útil noutro sítio. A hipótese mais estúpida, ainda que não inédita, é copiar o código de um programa para outro. Outra hipótese é colocá-la num “include” partilhado pelos vários programas que a usem. Mas mesmo isto também foleiro. Se é usada em mais que um sítio, ficará sempre mellhor como objecto global da SE24.

Os senhores da SAP, pensando já na possibilidade de uma classe local se emancipar, criaram uma ferramenta para isto. Funciona assim:

1. Vai à SE24
2. No menu “Tipo de objecto” escolhe a opção “Importar” e depois “classe local de programa”
3. Escolhe o programa
4. Aparece uma lista das classes locais desse programa
5. scolhe as classes locais que queres tornar globais
6. Dá-lhes um nome
7. E pimbas

Se esta ferramenta não te parecer útil, vai comprar o livro ABAP para totós.

O Abapinho saúda-vos.

O SAP GUI tem boa memória. Vai decorando os valores que lhe vamos metendo nos campos e depois sugere-os quando, mais tarde, voltamos a esses campos. Mas às vezes decora coisas que mais valia esquecer. Como por exemplo quando introduzimos um valor errado e a seguir ele insiste em sugerir-nos esse valor errado.

Há uns tempos descobri que este pequeno drama tem solução. Quando, no campo, aparece a combo box com as várias hipóteses, usa as setas do teclado para te posicionares no valor que queres esquecer e depois carrega na tecla DELETE. E assim se faz o SAP GUI esquecer um valor.

(Obrigado a cloois pela foto)

O Abapinho saúda-vos.

Aqui vos mostro uma forma criativa de preencher uma tabela interna com constantes que aprendi num programa standard. Imagina que querias criar uma tabela interna com os seguintes tipos de documento financeiro:

AB
AF
CH
DG
DZ
EX
F3
F4.

A forma mais convencional seria assim:

DATA: t_blart TYPE STANDARD TABLE OF blart,
      wa_blart LIKE LINE OF t_blart.

wa_blart = 'AB'.
APPEND wa_blart TO t_blart.
wa_blart = 'AF'.
APPEND wa_blart TO t_blart.
wa_blart = 'CH'.
APPEND wa_blart TO t_blart.
wa_blart = 'DG'.
APPEND wa_blart TO t_blart.
wa_blart = 'DZ'.
APPEND wa_blart TO t_blart.
wa_blart = 'EX'.
APPEND wa_blart TO t_blart.
wa_blart = 'F3'.
APPEND wa_blart TO t_blart.
wa_blart = 'F4'.
APPEND wa_blart TO t_blart.

Mas há uma forma muito mais sintética e curiosa:

DATA: lv_blart_list TYPE string,
      t_blart TYPE STANDARD TABLE OF blart,
      wa_blart LIKE LINE OF t_blart.

lv_blart_list = 'AB AF CH DG DZ EX F3 F4'.
SPLIT lv_blart_list AT space INTO TABLE t_blart.

O preenchimento da tabela é feito em apenas 2 linhas, bem menos que as 16 da forma convencional.

Fica aqui mais um exemplo copiado do standard que é interessante por ter dois níveis:

l_action_list = 'A01 A02 A03 A04'.
SPLIT l_action_list AT ' ' INTO TABLE lt_action.
LOOP AT lt_action INTO l_action.
  CASE l_action.
    WHEN 'A01'. l_refdoc_list = 'R01 R02 R03 R04 R05 R06 R14'.
    WHEN 'A02'. l_refdoc_list = 'R07 R08 R10 R12'.
    WHEN 'A03'. l_refdoc_list = 'R07 R08 R10 R11 R12 R13'.
    WHEN 'A04'. l_refdoc_list = 'R09'.
  ENDCASE.
  SPLIT l_refdoc_list AT ' ' INTO TABLE lt_refdoc.
  LOOP AT lt_refdoc INTO l_refdoc.
    ls_cust-action = l_action.
    ls_cust-refdoc = l_refdoc.
    APPEND ls_cust TO t_cust.
  ENDLOOP.
ENDLOOP.

O Abapinho saúda-vos.

Como todos sabem, pode fazer-se selecções de blocos de texto verticais e horizontais em quase todo o lado do SAPGUI carregando em CTRL-Y e depois arrastando o rato para fazer a selecção. Como todos também sabem, isto não funciona no editor de ABAP. Mas o que provavelmente nem todos sabem é que há uma forma de fazer este tipo de selecções no editor de ABAP: primir e manter o ALT. Assim já podes seleccionar blocos de texto. Bom, não?

Obrigado Sérgio Fraga pela dica.

O Abapinho saúda-vos.