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:

Ler o resto do artigo »

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 é.
Ler o resto do artigo »

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

Ler o resto do artigo »

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.

Volta não volta aparece um cliente que pede a um funcional que pede a um programador que crie um parâmetro protegido contra escrita no ecrã de selecção de um programa. É um bocado cretino visto que a ideia dos parâmetros é serem parametrizáveis.

Mas enfim, vê-se de tudo.

Os clientes têm tanta imaginação que a SAP devia criar um módulo de cinema, SAP CI, especialmente para eles poderem realizar os tantos filmes que lhes vão na cabeça. Estou certo de que se criariam grandes sucessos de ficção científica. E muitas comédias também.

Bem, caso alguém te peça para fazer isto, faz-se assim:

REPORT ZTEST1.
PARAMETERS: nao_mexe LIKE mara-matnr DEFAULT '220705' MODIF ID ro.

AT SELECTION-SCREEN OUTPUT.
  LOOP AT SCREEN.
    IF SCREEN-GROUP1 = 'RO' .
      SCREEN-INPUT = '0'.
      MODIFY SCREEN.
    ENDIF.
  ENDLOOP.

START-OF-SELECTION.
  WRITE: / nao_mexe.

Agora falando mais a sério, a ideia de proteger parâmetros contra escrita é interessante se isso depender dos valores de outros parâmetros. Por exemplo, se o pisco “gravar ficheiro” estiver ligado, permite introduzir o nome do ficheiro, caso contrário, este último fica protegido contra escrita. Fica a sugestão. É só adicionar ao código as condições desejadas.

O Abapinho saúda-vos.

Tens à tua frente um daqueles IF ELSEIF ELSEIF ELSEIF ELSEIF ELSE ENDIF gigantescos que atravessa centenas de linhas de código.

Se fizeres duplo clique em cima do IF ou de qualquer dos ELSEIF vais parar ao ENDIF. Se fizeres duplo-clique lá em baixo no ENDIF vais parar lá acima ao IF. Isto toda a gente sabe. Dá jeito com IF ENDIF pequeninos. Já com os grandes, não serve de muito.

Mas o que se calhar nem toda a gente sabe é que se fizeres ALT-clique no IF, em vez de ires parar directamente lá abaixo ao ENDIF, saltas só para o próximo ELSEIF e assim por adiante até chegares ao ENDIF.

Funciona tal e qual com o CASE WHEN WHEN WHEN WHEN WHEN ENDCASE.

Dá jeito.

(Obrigado Renato Sousa pela dica)
(E obrigado ao dj @ oxherder arts pela foto)

O Abapinho saúda-vos.

Nunca te aconteceu estar a programar num programa ABAP daqueles que parecem um testamento com centenas e centenas de linhas e teres de estar sempre a saltar entre uma zona e outra do código?

Até há uns dias eu, ignorante, usava o PageUp e o PageDown para saltar entre os dois sítios e perdia montes de tempo à procura do lugar exacto do código que me interessava.

Mas entretanto o Sérgio Fraga ensinou-me que o editor ABAP tem uma funcionalidade chamada bookmarks que permite evitar o disparate de andar a subir e a descer às apalpadelas.

Primeiro é só fazer CTRL-ALT-1 numa determinada linha para nela definir o bookmark 1, CTRL-ALT-2 para definir o bookmark 2, e assim por adiante até ao 9.

Depois basta fazer CTRL-1 para saltar directamente para o bookmark 1, CTRL-2 para o 2 e assim por adiante.

Depois é só começar aos saltos de um lado para o outro como se não houvesse amanhã.

Já agora, os bookmarks também podem ser definidos através do menu que aparece quando se clica com o botão direito do rato na margem esquerda do editor.

Se saíres do editor estragas tudo porque os bookmarks não ficam gravados, mas mesmo assim, por serem tão simples de usar, dão muito jeito.

Obrigado Sérgio Fraga!

(E obrigado ao epi.us pela foto)

O Abapinho saúda-vos.

Qual é a tua cor preferida?

SELECTION-SCREEN BEGIN OF BLOCK b1.
PARAMETERS: p_azul BUTTONGROUP GROUP COR DEFAULT 'X',
            p_verde BUTTONGROUP GROUP COR,
            p_roxo BUTTONGROUP GROUP COR.
SELECTION-SCREEN END OF BLOCK b1.

Se respondeste azul sobrevives e podes atravessar a ponte.

De qualquer das formas, em ABAP costuma fazer-se o seguinte para descobrir a cor que o utilizador escolheu:

IF p_azul = 'X'.
  lv_cor = 'AZUL'.
ELSE IF p_verde = 'X'.
  lv_cor = 'VERDE'.
ELSE IF p_roxo = 'X'.
  lv_cor = 'ROXO'.
ENDIF.

Mas há uma forma curiosa e muito mais elegante de conseguir o mesmo. É aquilo a que se pode chamar de CASE de pernas para o ar:

CASE 'X'.
  WHEN p_azul.
    lv_cor = 'AZUL'.
  WHEN p_verde.
    lv_cor = 'VERDE'.
  WHEN p_roxo.
    lv_cor = 'ROXO'.
ENDCASE.

E esta, heim?

(Obrigado ao itspaulkelly pela foto.)

O Abapinho saúda-vos.

Quando se quer obter um único registo de uma tabela da base de dados é costume usar-se o SELECT SINGLE que, como toda a gente sabe, na sua forma mais básica reza assim:

SELECT SINGLE *
  FROM KNA1
  WHERE KUNNR = '1234567890'.

Ler o resto do artigo »

O RICEF é um acrónimo do mundo SAP que aparentemente não foi inventado pela SAP. É, por isso, um acrónimo não oficial. O que não faz dele um acrónimo ilegal ou clandestino visto que tem vindo a tornar-se um termo de uso corrente em cada vez mais projectos.

RICEF significa Report, Interface, Conversion, Enhancement, Form e, basicamente, refere-se a qualquer tipo de desenvolvimento que seja necessário num projecto SAP.

• Report refere-se a reports, ALVs, transacções, e todo o género de coisas interactivas.
• Interface servem para transportar dados entre o SAP e outros sistemas. Refere-se portanto a IDOCs, ALE, EDI, RFC, coisas de PI, etc.
• Conversion trata de conversão de dados, ou seja, carregamentos de dados através de BDC, DI, LSMW, etc.
• Enhancement refere-se a todo o tipo de user-exits, BADIs e seus primos;
• Form são, claro, os famigerado Layouts e os mais recentes Smart Form, Adobe Forms e integrações com MS Office.

E com 5 letrinhas apenas se descreve todo o tipo de desenvolvimentos possíveis em SAP.

A sua utilização prende-se com a necessidade de identificar univocamente os diferentes desenvolvimentos num projecto. Atente-se como exemplo neste breve diálogo entre um consultor funcional de cor verde e um consultor ABAP de cor roxa:

Verde – É preciso fazer um RICEF novo em FI.
Roxo – Outro? Porquê outro? Não chegam já?
Verde – Não. São sempre precisos mais.
Roxo – E como se chama este novo RICEF?
Verde – F451.
Roxo – Merda, mais um formulário.

O Abapinho saúda-vos.