Porque haveria de ser difícil lê-las? Só tornaria mais difícil a vida de quem vier a precisar de a entender. Lá porque uma condição IF é complexa não é por isso que tem de ser complicada.

O ABAP está a permitir fazer coisas cada vez mais interessantes em SQL. A última que descobri foi que agora se pode usar CASEs.

Quantas vezes na tua vida de consultor tiveste de lidar com dumps que aconteceram em consequência de um programa tentar inserir duas linhas com a mesma chave numa tabela interna definida com UNIQUE KEY? Chega.

Em 2012 lamentei que a LISTBOX fosse tão pouco usada. Ensinei a usá-la com elementos de dado standard, que a populam automaticamente. Hoje vou-te ensinar como a podes popular tu próprio se quiseres listar opções que não venham de um elemento de dados.

Há tantas coisas que se podem fazer nos ecrãs de selecção. Aqui está mais uma: cinco botões na barra de ferramentas.

Quando tens de enviar o mesmo email para mais do que um endereço, o mais comum é guardar a lista de endereços numa tabela qualquer e depois adicionar todos os endereços como recipientes. Mas aprendi recentemente uma forma muito mais bonita para conseguir o mesmo resultado.

Embora muitos ABAPers ainda se esqueçam disto, quanto menos textos forem fixados no programa mais fácil será traduzi-lo. Aqui está uma forma simples mas relativamente obscura de alterar os textos para, por exemplo, adicionar-lhes ícones, mantendo-os traduzíveis.

Imagina que chamas um módulo de função por RFC várias vezes seguidas. Se calhar julgas que cada chamada é completamente independente. Mas não é. O grupo de funções fica carregado em memória no sistema remoto e os mesmos dados globais serão reutilizados em todas as chamadas. Isto não deverá constituir um problema na maior parte dos casos. Mas haverá cenários em que, por uma razão ou outra, o módulo de funções chamado guarda dados em variáveis globais que podem interferir negativamente com as chamadas subsequentes.

Como é que se há-de traduzir dummy? Fica manequim. Comecei a trabalhar recentemente num cliente novo e reparei que fazem aqui uma coisa que me agradou. Quando precisam de invocar por RFC módulos de função em outros sistemas SAP, criam localmente um módulo de função com o mesmo nome mas sem código, apenas com um comentário explicando que é uma função remota noutro sistema. A virtude disto é que assim pode usar-se a ferramenta where-used para descobrir todos os sítios onde é invocada.

Sou do tempo em que as notas da SAP se introduziam à mão. Copy paste e rezar para não errar. Granda maluquice. Lembro-me de um projecto que, por alguma razão que nunca ficou clara, em vez de se fazer upgrade, decidiu-se implementar várias centenas de notas à mão. Imprimiram as notas todas, fizeram num monte gigante com elas e uns 10 consultores passaram um fim-de-semana inteiro a tentar acabar com o monte. Conseguímos. Não faço ideia do que aconteceu a seguir mas de certeza que criámos montes de bugs.

Antes do 7.40 ter modernizado o ABAP, um lookup a uma tabela obrigava a declarar uma variável auxiliar e a pelo menos 4 linhas de código.

Como é conhecido, o SAP guarda internamente os montantes e variáveis com 2 casas decimais. Quando queremos convertê-los no formato externo costumamos usar o WRITE com a opção CURRENCY. Mas o WRITE escreve numa variável alfa-numérica. E se quisermos escrever numa variável numérica?

Lá aprendi mais uma pequena funcionalidade obscura do SAPGui. Como acelerar o corte e costura.

Durante muitos anos, quando entrava em discussões sobre ABAP OO ser melhor do que FORMs, INCLUDEs e CALL FUNCTIONs, o mais comum é a pessoa do lado de lá continuar convencida de que OO é bom nas outras linguagens mas não traz vantagens para o ABAP. Logo a começar pelo atroz código standard SAP que parece ter sido escrito para provar que é possível fazer algo que viola todas as boas prácticas de programação e mesmo assim funciona.

Não, o ABAP nunca vai ter o operador NOT.