Só ALV

Somente para informações sobre ALV.

Usando mesmo event_handler para vários ALVs no mesmo programa

Nos eventos tem o parâmetro oculto sender para todos os eventos, utilizá-lo para definir qual objeto ALV está sendo utilizado para um evento compartilhado.

Ex.:

      handle_alv_hotspot_click FOR EVENT hotspot_click OF cl_gui_alv_grid
        IMPORTING
            e_row_id
            e_column_id
            es_row_no
            sender,



O SENDER define o objeto ALV sendo executadoo naquele momento.

Para conseguir saber qual está sendo executado existem várias maneiras, eu fazia lendo qual container estava sendo utilizado, mas achei uma maneira mais fácil de um exemplo no SDN.

Primeiro define um nome para o objeto ALV utilizando o metodo SET_NAME.

Ex: go_alv_adi_nf->set_name('ADI_NF').

Quanto é executado dentro do evento, utilizar o método para pegar o nome do ALV definido.

Ex.: 
FORM handle_alv_hotspot_click USING iv_row_id    TYPE lvc_s_row
                                    is_column_id TYPE  lvc_s_col
                                    is_row_no    TYPE lvc_s_roid
                                    io_sender TYPE REF TO cl_gui_alv_grid.

  DATA lv_name TYPE string.

  CALL METHOD io_sender->get_name
    RECEIVING
      name = lv_name.

  IF lv_name = 'ADI_NF'.

 ELSE.
 ENDIF.


========================================================================

ES_J_1BNF_ADD_DATA - NF WRITER

Opa.. essa ADD_DATA não tava passando quando é uma NF writer. Tem uma nota que explica como funciona, mas pelo blog abaixo fica mais fácil de entender.

Outro detalhe.. nessa caso ele tem um método especifico para J1B1N

ADD_DATA_J1B1N


https://blogs.sap.com/2016/09/08/badi-nova-chamada-automaticamente-na-nf-writer-j1b1nj1b2n/

Liberar tabelas customizing J1BTAX em QA e PRD

  Para ficar guardado na gaveta;

- É normal os funcionais solicitarem para abrir as tabelas da J1BTAX para modificação no QA ou PRD. Me bati um monte pq o que encontrei no google foi o básico que seria modificar na SOBJ a visão marcando o flag de "Opção em curso"/"Current setting", mas o diabo não funcionou..
 Teve um colega que acabou me ajudando, acho q deve ter diversas outras formas, mas enfim essa achei sem muito impacto, e sem mexer na customização do mandante SCC4.

Coisa simples na verdade.

A idéia é ir na SE54 no objeto da visão e alterar a opção "indicação para transporte de dados do diálogo".

O padrão é estar no "Rotina de registro standard".
Alterar para "Rotina de registro individual/nenhuma".

NFE NT 2018.005 - Erro no técnico responsável não passa na CL_NFE_PRINT

Talvez a SAP já tenha corrigido isso, mas quem implementou as notas para a NT 2018.005 que inclui o responsável técnico e umas outras funcionalidades.

Depois de implementado as notas parou de passar pela BADI CL_NFE_PRINT, no meu post anterior falei sobre a BADI ...ADD_DATA que marca o flag na J_1BFNDOC, eis que fui verificar e após aplicação das notas essa campo IND_BADI_CTRL da .j_1bnfdoc começou a ficar marcado, aí fui debugar e vi que mesmo não alterando nada na BADI ...ADD_DATA, a nota ficava como tivesse sido modificada na BADI marcando o campo.
Aí vi que após a ADD_DATA tem um método novo para o técnico responsável.(abaixo)

" Technical responsible has only the DocNum as Primary Key.
" Therefore it should be a structure during the badi fields editing (there will be only 1 entry per document)
    lo_nfe_persist_badi->tec_resp_move_str_to_table(        "2747190
      EXPORTING                                             "2747190
        is_tec_resp = ls_tec_resp                           "2747190
      IMPORTING                                             "2747190
        et_tec_resp = wnftec_resp[]                         "2747190
    ).                                                      "2747190

Dentro desse método mesmo que a estrutura LS_TEC_RESP estiver vazia ele grava em branco na tabela interna WNFTEC_RESP, aí fudeu !!!  logo depois qdo ele compara a estrutura.

   "Check if BAdI is active.                             "2112507
    CALL METHOD                                           "2112507
      lo_nfe_persist_badi->is_add_data_changed            "2112507
....
 p_tec_resp     = wnftec_resp[]                    "2747190

Fica como se tivesse sido modificado pq tem uma linha em branco na tabela interna.

Acho q a SAP deve corrigir,  a principio coloquei um enhancement para resolver por hora.

  METHOD tec_resp_move_str_to_table.
ENHANCEMENT 1  ZSD_NFE_TEC_RESP.    "active version
    CHECK is_tec_resp IS NOT INITIAL.
ENDENHANCEMENT.
    " Method delivered by note 2747190
    CLEAR et_tec_resp[].
    APPEND is_tec_resp TO et_tec_resp.
  ENDMETHOD.

BADI CL_NFE_PRINT X ES_J_1BNF_ADD_DATA

======= ESSE TEXTO PODE NÃO SER 100% =======================
Peguei casos em q as 2 estão ativas e funcionando
============================================================

Voltei a ativa e já peguei um pepino..

Li umas notas e tal sobre esse caso, foi bem porque eu tinha um método para modificar um XML na BADI NFE_PRINT e tinha um código nessa outra BADI  ADD_DATA, aí tava vendo uns blogs e tal e falaram que se uma estivesse implementada a outra não funcionaria, fui nessa direção querendo passar tudo que tava numa para outra, mas aí reparei que não é bem assim, as duas podem estar ativadas e só é desconsiderado a NFE_PRINT se alguma alteração na estrutura for feita na ADD_DATA, ou seja mesmo as 2 ativadas se não tiver alteração nenhuma na ADD_DATA vai passar pela NFE_PRINT.
Existe um código logo após a ADD_DATA que verifica se houve modificação nos dados do que entrou para o que saiu da BADI, quando isso acontece que é no momento de criar a nota, fica um flag na J_1BNFDOC campo IND_BADI_CTRL que fica marcado, e é esse flag que ele verifica quando vai criar o XML e passa na NFE_PRINT, se estiver vazio passa na BADI se estiver marcado ele ignora.

==> CÓDIGO QUE ESTÁ NO MOMENTO DO XML

  IF obj_ref IS BOUND AND                                 "2112507
     wk_header-ind_badi_ctrl = 'X' AND                    "2112507
     wk_header-cnpj_bupla IS NOT INITIAL. "transitional phase 1844621
    lo_obj_ref = obj_ref.                                       "1844621
    CLEAR obj_ref.               "save for later use            "1844621
  ENDIF.              

==> CÓDIGO QUE ESTÁ NA CRIAÇÃO DA NF - LOGO APÓS PASSAR NA BADI ADD_DATA
METHOD is_add_data_changed.
  IF mr_header        <> p_header       OR
     mt_item[]        <> p_item[]       OR
     mt_transvol[]    <> p_transvol[]   OR
     mt_trailer[]     <> p_trailer[]    OR
     mt_tradenotes[]  <> p_tradenotes[] OR
     mt_refproc[]     <> p_refproc[]    OR
     mt_add_info[]    <> p_add_info[]   OR
     mt_sugarsuppl[]  <> p_sugarsuppl[] OR
     mt_sugardeduc[]  <> p_sugardeduc[] OR
     mt_pharmaceut[]  <> p_pharmaceut[] OR
     mt_vehicle[]     <> p_vehicle[]    OR
     mt_fuel[]        <> p_fuel[]       OR
     mt_export[]      <> p_export[]     OR
     mt_import_adi[]  <> p_import_adi[] OR
     mt_import_di[]   <> p_import_di[]  OR
     mt_nve[]         <> p_nve[]           OR             "2459713
     mt_traceability[] <> p_traceability[] OR             "2459713
     mt_pharma[]       <> p_pharma[]       OR             "2459713
     mt_payment[]      <> p_payment[]      OR             "2747190
     mt_tec_resp[]     <> p_tec_resp[].                   "2747190
                                                          "2459713
     rv_flag = abap_true.                                 "2459713
  ENDIF.
ENDMETHOD.


==> RETORNO DO MÉTODO IS_ADD_DATA_CHANGED acima
.....
RECEIVING                                           "2112507
        rv_flag       = wnfdoc-ind_badi_ctrl.             "2112507
.......

SQL error general error: <> Cannot compare NLocator and NLocator

 Tive um problema recentemente num cliente onde estava dando um DUMP no ambiente ECC/HANA, o dump se referia a uma calculation view específica.

Fiz um teste no eclipse dando um data preview na calculation view que deu o erro, e deu a mesma mensagem.

Primeiro tive q isolar o problema.

- Copiei a calculation view inteira para uma outra calculation view Z*
- Debaixo para cima comecei a executar o data preview para todas as caixinha e ver onde começava o erro.
- No meu caso o erro era numa aggregation, então tive que fazer várias ligações diferentes para saber qual a perna da aggregation que estava com problema.

- Quando encontrei a projection/union/aggregation com erro, comecei a isolar os campos e fazer 

testes.
- A dica nesse caso é que esse erro do NLOCATOR é por causa de campos textos, então mire diretamente nesses tipos de campos.
- Vi que no tinha um filtro na calculation fazendo uma comparação tipo ("TXT" != ' '), traduzindo o filtro seria pegar os registros onde o campo TXT estiver diferente de espaço.
- Se eu removesse o filtro não dava o erro, se deixasse o erro  aparecia. Eu poderia simplesmente deixar sem filtro que resolveria o meu problema, mas resolvi ir mais a fundo.
- Vimos que na tabela de origem dos dados, tinha um campo tipo STRING, e o problema era justamente isso, a calculation view dá pau quando tem uma condição considerando espaços em campo tipo STRING.
- Procurei uma nota referente a essa tabela, e no meu caso tinha uma divergência, pois a nota q achei criava a tabela com o campo com CHAR255, mas vi q na instalação do sistema o campo veio como STRING, tentei achar uma nota de correção com o erro mas não achei. Consultei a SAP e me informaram q o correto era o CHAR255, estou esperando  uma nota de correção ainda, nem sei se esses fillhos da mãe vão disponibilizar, mas corrigindo  o tipo do campo resolve o problema.

Fica a dica.

NOTA: então. fiquei na dúvida de uma coisa.. o cliente q estava com esse problema usa o HANA com o esquema de CROSS DATABASE. Andei dando uma vasculhada em algumas notas e nesse esquema de crossdb existe várias limitações.

Execução ALV (CL_GUI_ALV_GRID) em background

  A função REUSE_ALV_GRID_DISPLAY faz a listagem dos dados no spool sem problema, utilizando a classe CL_GUI_ALV_GRID, por causa do container, dá um DUMP.  Andei procurando e achei a solução, utilizando um outro objeto base para a criação do objeto ALV.

Solução abaixo.

==========================

DATA: o_alv         TYPE REF TO cl_gui_alv_grid,
      o_cc_alv      TYPE REF TO cl_gui_custom_container,
      o_ctr_alv_job TYPE REF TO cl_gui_docking_container.


  IF sy-batch IS INITIAL.
    CREATE OBJECT o_cc_alv
      EXPORTING
        container_name = 'CC_ALV'.

    CREATE OBJECT o_alv
      EXPORTING
        i_parent = o_cc_alv.

  ELSE.
    CREATE OBJECT o_alv
      EXPORTING
        i_parent = o_ctr_alv_job.

  ENDIF.

=========================================
Em vez do sy-batch tem um método que tambem determina se o alv está em job ou não.

IF cl_gui_alv_grid=>offline( ) IS INITIAL.

ENDIF.