Às vezes uma SALV pode ter inconsistências que passam despercebidas a quem as programa. Um exemplo é uma estrutura com um campo WRBTR sem um campo de moeda associado:

O Manelinho criou a transacção ZFB01 associada ao programa ZFB01 que faz lá umas coisas e depois faz CALL TRANSACTION à FB01. A seguir veio o Joãozinho e correu a transacção ZFB01. Conseguiu começar a corrê-la porque tem permissões para a transacção ZFB01. Mas a meio teve um erro porque não tem permissões para a transacção FB01. Tanto o Manelinho como o Joãozinho sabiam que os administradores de sistema nunca na vida deles darão ao Joãozinho autorizações para correr a FB01.

Todos os objectos criados em SAP têm de estar associados a um pacote. Até recentemente, quando eu queria fazer um teste rápido criava o objecto no pacote $TMP. Tinha assim a garantia de este nunca viria a ser transportado. Mas por vezes há necessidade de criar coisas no sistema de desenvolvimento que não pretendemos nunca vir a transportar mas que queremos que lá existam eternamente. Como o ZSAPLINK e o abapGit, por exemplo. Mas se as associarmos todas as pacote $TMP fica uma valente confusão.

Hoje em dia quando quero criar uma SALV defino sempre a estrutura dos dados no DDIC já com os elementos de dados com as descrições desejadas em vez de os forçar no código.

Toda a minha vida ABAPiana usei APPEND STRUCTURES para adicionar campos extra a tabelas standard. Mas aprendi recentemente que afinal servem para mais duas coisas:

Quando chamas uma função por RFC tens de lhe dar a RFC DESTINATION do sistema remoto: CALL FUNCTION ‘ZESPIRREI’ DESTINATION ’sistema_longe_daqui’. E se, por alguma razão, precisares que a função que corre no sistema remoto chame uma função no sistema original. Sabes fazê-lo?

Todos conhecemos as ampliações implícitas da SAP, que permitem adicionar código no início ou final qualquer blocos de código standard (funções, métodos, etc.). Já todos as usámos para alterar uma BAPI ou outro código standard qualquer. Mas só há pouco tempo é que descobri que também é possível usar ampliações implícitas para acrescentar parâmetros a funções e métodos ABAP standard.

Uma das coisas que distingue o homem dos restantes animais é o facto de ser capaz de pensar o pensamento. Um pardal pode pensar “estou assustado, vou dizer piu piu piu” e, como consequência, quem estiver ao pé dele ouve “piu piu piu”.

Acabei de descobrir que o SAP consegue tirar selfies. Ainda não estou a ver para que é que isto possa servir. Mas não é grave porque na verdade também nunca vi para que é que servem as selfies tiradas por nós os humanos. Faz-se assim:

Desenvolveste um report que sabes que demora 12 horas a correr. Por isso não queres que ninguém tente corrê-lo em foreground. Vou mostrar-te uma forma de garantires que isso não acontece.

Às vezes não gosto dos nomes que a SAP deu às coisas. E então mudo-os. Por exemplo, um dia estava muito zangado e achava que os clientes eram todos uns parasitas. Então fiz o seguinte:

Normalmente os sistemas SAP têm definido um tempo limite para que um programa possa correr interactivamente. Se o programa demorar mais ocorre um erro de execução (vulgo dump ).

No início dos tempos usava-se a transacção SE17 para ver o conteúdo de tabelas. Rapidamente sentiram vergonha e decidiram fazer uma coisa melhorzinha a que chamaram SE16. Depois inventaram a ALV e surgiu a SE16N (e muita gente continuou até hoje a usar a SE16, algo que me ultrapassa). Hoje apresento-vos a SE16H.

Se tu és daquelas pessoas que ainda usa a SE16, este artigo não é para ti. Se continuares a ler corres o risco de encontrar ainda mais uma razão para finalmente passares a usar a SE16N (como se todas as outras não fossem já suficientes). Imagina que queres seleccionar todos os materiais que tenham “PREGO" no nome e que sejam do tipo FERRAGENS e além disso todos os materiais que tenham “GUARDANAPO" no nome e que sejam do tipo COMIDA. Ou seja, não deverá aparecer o “PREGO_NO_PAO” nem o “GARDANAPO_PAPEL”. O que tu queres é isto (faz de conta): (MATNR = “PREGO%” AND MTART = “FERR” ) OR (MATNR = “GUARDANAPO%” AND MAKT = “COMI” ) Como bem sabes, numa utilização normal (sem recorrer a isto que te vou mostrar) da SE16N terias de a executar duas vezes e cruzar manualmente a informação porque o ecrã de selecção não dá para fazer ORs. Ou dá?

Sabias que quando invocas uma função com a opção DESTINATION ‘NONE’ estás a iniciar uma nova LUW? Isto pode parecer apenas uma curiosidade, mas há um caso em que pode fazer toda a diferença: sabes aqueles módulos de função que ao serem chamados uma segunda vez têm um comportamento diferente da primeira vez? Isto acontece porque eles hão-de ter alterado alguma variável global ao grupo de funções. Ora se iniciares uma nova LUW quando chamares a função, o seu grupo de funções é automaticamente inicializado e assim garantes que o comportamento da função é o esperado.