Relatório ALV Hierárquico com estrutura dinâmica

Muito interessante o código abaixo, bem diferente dos códigos conhecidos e acho q dá para trabalhar bastante em cima da estrutura. Achei q valia a pena compartilhar.



   DATA lcl_hier_tab TYPE REF TO cl_salv_hierseq_table.

   DATA: lt_binding TYPE salv_t_hierseq_binding.

   DATA: lw_binding TYPE salv_s_hierseq_binding.

   FIELD-SYMBOLS: <lfsw_str>.

   IF gt_zsmm_0006_save[] IS NOT INITIAL.
     ASSIGN ('GT_ZSMM_0006_SAVE') TO <g_dyn_tab_save>.
   ENDIF.

   IF <g_dyn_tab_save> IS INITIAL.
     MESSAGE i053(zmm001).
     EXIT.
   ENDIF.

   lw_binding-master = 'MATNR'.
   lw_binding-slave = 'MATNR'.
   APPEND lw_binding TO lt_binding.
   lw_binding-master = 'LICHN'.
   lw_binding-slave = 'LICHN'.
   APPEND lw_binding TO lt_binding.

   cl_salv_hierseq_table=>factory(
   EXPORTING t_binding_level1_level2 = lt_binding
     IMPORTING r_hierseq = lcl_hier_tab
       CHANGING
       t_table_level1 = gt_itens_rc
       t_table_level2 = <g_dyn_tab_save> ).

   lcl_hier_tab->display( ).


Link útil.

http://wiki.scn.sap.com/wiki/display/ABAP/ALV+Grid+Report+-+with+Object+Oriented+SALV+Classes

Classificação e características de objeto - Funções úteis

======== Busca características de uma classe.
  CALL FUNCTION 'BAPI_CLASS_GET_CHARACTERISTICS'
    EXPORTING
      classnum        = f_classnum  "Nome da classe
      classtype       = '023' "Tipo da classe
    TABLES
      characteristics = gt_charact 
      char_values     = gt_charact_val.


characteristics = Tabela retorna as características e tipos
char_values     = Tabela com os valores fixos de uma característica


======== Buscar detalhes de um objeto

  CLEAR gw_class_key.
  CONCATENATE l_matnr f_charg INTO gw_class_key-object.
  gw_class_key-objecttable = 'MCH1'.
  gw_class_key-classnum    = f_classnum. "Nome da Classe de objetos
  gw_class_key-classtype   = '023'.

  CALL FUNCTION 'BAPI_OBJCL_GETDETAIL'
    EXPORTING
      objectkey       = gw_class_key-object
      objecttable     = gw_class_key-objecttable
      classnum        = gw_class_key-classnum
      classtype       = gw_class_key-classtype
    TABLES
      allocvaluesnum  = gt_num
      allocvalueschar = gt_char
      allocvaluescurr = gt_curr
      return          = gt_return.


============== Separação das características por tipo..
Tipos NUM e DATE para tabela   allocvaluesnum
Tipo CHAR para tabela allocvalueschar
Tipo CURR para tabela allocvaluescurr

================ Alteração de classificação
  CALL FUNCTION 'BAPI_OBJCL_CHANGE'
    EXPORTING
      objectkey          = l_object
      objecttable        = 'MCH1'
      classnum           = l_classnum
      classtype          = l_classtype
      keydate            = sy-datum
    TABLES
      allocvaluesnumnew  = lt_num_charac
      allocvaluescharnew = lt_chr_charac
      allocvaluescurrnew = lt_cur_charac
      return             = lt_return.  

============= exemplo

        CASE lw_charact-data_type.
          WHEN 'CHAR'.
            lw_allocvaluescharnew-charact = ls_comp-name.
            lw_allocvaluescharnew-value_char = <fs_comp>.
            APPEND lw_allocvaluescharnew TO lt_chr_charac.
          WHEN 'NUM' OR 'DATE'.
            lw_allocvaluesnumnew-charact = ls_comp-name.
            lw_allocvaluesnumnew-value_from = <fs_comp>.
            lw_allocvaluesnumnew-value_to   = <fs_comp>.
            APPEND lw_allocvaluesnumnew TO lt_num_charac.
          WHEN 'CURR'.
            lw_allocvaluescurrnew-charact = ls_comp-name.
            lw_allocvaluescurrnew-value_from = <fs_comp>.
            lw_allocvaluescurrnew-value_to   = <fs_comp>.
            APPEND lw_allocvaluescurrnew TO lt_cur_charac.
        ENDCASE. 

Atualização automática de usuário, data, hora modificador campo de visão de atualização SM30

 Esse estou postando pq sempre esqueço como faz.. 

Evento 01







 


FORM atualiza_modificador.

  FIELD-SYMBOLS: <lfs_field>,
                 <lfsw_total>.

  LOOP AT total.

    CHECK <action> = 'U' OR <action> = 'I'.
    ASSIGN COMPONENT 'AENAM' OF STRUCTURE <vim_total_struc> TO <lfs_field>.
    IF sy-subrc = 0.
      <lfs_field> = sy-uname.
    ENDIF.

    ASSIGN COMPONENT 'AEDAT' OF STRUCTURE <vim_total_struc> TO <lfs_field>.
    IF sy-subrc = 0.
      <lfs_field> = sy-datum.
    ENDIF.

    ASSIGN COMPONENT 'AEZET' OF STRUCTURE <vim_total_struc> TO <lfs_field>.
    IF sy-subrc = 0.
      <lfs_field> = sy-uzeit.
    ENDIF.
  

    "Atualiza os dados na tela

    READ TABLE extract WITH KEY <vim_xtotal_key>.

    IF sy-subrc EQ 0.

      extract = total.

      MODIFY extract INDEX sy-tabix.

    ENDIF.

    MODIFY total.

  ENDLOOP.

ENDFORM.                    "ATUALIZA_MODIFICADOR.

*================================================

Validar entradas na SM30

- Dentro do evento 01 

  TYPES: BEGIN OF tp_cont,

           cont      TYPE i,

         END OF tp_cont.

  DATA: lt_cont TYPE TABLE OF tp_cont.

  DATA ls_cont TYPE tp_cont.

  LOOP AT total.

    CHECK <action> = 'U' OR <action> = 'N'.

    IF <vim_total_struc> IS ASSIGNED.

      MOVE-CORRESPONDING <vim_total_struc> TO ls_cont.

    ENDIF.

  ENDLOOP.

  IF REDUCE i( INIT cont = 0

               FOR ls_cont IN lt_cont WHERE ( cont > 1 ) NEXT cont = cont + 1 ) > 0 .

    MESSAGE 'Erro' TYPE 'I' DISPLAY LIKE 'E'.

    vim_abort_saving = 'X'.

  ENDIF.

Estrutura de PRICING do pedido na criação de NF ( MIRO)

 Tive que fazer uma alteração na NF durante a criação da MIRO e precisava pegar alguns valores da pricing do pedido que geralmente só é calculado e não é gravado em nenhum tabela. debugando achei uma estrutura na criação da NF que já tem a pricing do pedido carregado. Como o cálculo é um pouco pesado em termos de processamento o mais interessante foi pegar esses valores já carregados.

Esses dados foram pegos no include LJ1BIF01. A tabela GT_TKOMV_SAVE. 

  TYPES: BEGIN OF ltp_tkomv_save,
         itmnum TYPE j_1bitmnum,
         komk   TYPE komk,
         komp   TYPE komp,
         tkomv  TYPE komv_tab,
       END OF ltp_tkomv_save.

DATA: lt_tkomv_save TYPE TABLE OF ltp_tkomv_save.
DATA: lw_tkomv_save TYPE ltp_tkomv_save,
      lw_komv       TYPE komv,
      lw_nfstx      TYPE j_1bnfstx,
      lw_param      TYPE zmme114.

FIELD-SYMBOLS: <lfsw_condtax> TYPE ANY TABLE.

ASSIGN ('(SAPLJ1BCONDTAX)GT_TKOMV_SAVE[]') TO  <lfsw_condtax>.

  F sy-subrc = 0.

  CLEAR: lw_param.
  lw_param-caller = 'MM'.
  lw_param-country = 'BR'.
  lw_param-icms = 'X'.

  lt_tkomv_save[] = <lfsw_condtax>[].

  LOOP AT lineitem.

    ADD 1 TO l_itmnum.

    CLEAR: l_kbetr.

    LOOP AT lt_tkomv_save INTO lw_tkomv_save
                         WHERE itmnum EQ l_itmnum.

      READ TABLE lw_tkomv_save-tkomv INTO lw_komv
                                     WITH KEY kschl = 'ICMV'.

      IF sy-subrc = 0 AND lw_komv-kwert <> 0.
        l_kbetr = lw_komv-kwert.
        EXIT.

      ENDIF.

    ENDLOOP.

    IF l_kbetr <> 0.

      READ TABLE litax INTO lw_nfstx
                       WITH KEY itmnum = lineitem-itmnum
                                taxtyp(2) = 'IC'.
      IF lw_nfstx-othbas > 0.

        lw_nfstx-taxtyp = 'ICOP'.
        lw_nfstx-rate   = '12'.
        lw_nfstx-taxval = l_kbetr.
        APPEND lw_nfstx TO litax.

      ENDIF.

    ENDIF.

  ENDLOOP.

Pontos Enhanc. Point ideal para alteração em valor da Nota Fiscal (BR)

 Depois da versão ECC 6.0 surgiu os enhancements points que salvaram a vida de muito ABAP por aí, como eu sou das antigas da versão 4.6C e até 4.0 sempre dependi muito de BADI, User Exits, BTE, regra de substituição, Field Exits que eram disponibilizados no standard em alguns pontos dos programas. Eu particularmente só utilizo o Enhancement Point em último caso, pois acredito muito nos pontos disponibilizados pela SAP, a galera mais nova usa o Enhancement point a rodo e as vezes não procura direito e acaba colocando vários para resolver um único problema ou estragando outras coisas.. a preguiça de procurar é muito grande..

  Bom vou falar sobre um ponto q acho muito útil, pois na NF q é um produto quase especifico para o Brasil, não tem exits ou BADIs para uma implementação de cliente.. sendo assim sempre utilizo um enhancement point (Explicito) standard criando apenas uma ampliação.

Para o caso de criação de NF na MIRO. (MM)

INCLUDE  LJ1BIF01.

Criar implementação para o SPOT ES_SAPLJ1BI

Nesse ponto é possível alterar a estrutura NFHEADER (J_1BNFDOC) ou as de tabela LINEITEM (J_1BNFLIN)  ou a LITAX (J_1BNFSTX)



 Para o caso de criação de NF pela VF01. (SD)
Utilizar INCLUDE  LJ1BGF01
Nesse caso tem q criar um enhancemente point implicito mesmo.


Para o caso de criação de NF pelas MB* ou BAPI_GOODSMVT_CREATE. (MM)
Utilizar INCLUDE  LJ1BFF01
Include bem tranquilo, tem vários SPOTS ao longo da montagem da estrutura da NF.. no meu caso eu consegui alterar o valor unitário e valor liquido, alterar os valores fiscais da NF, incluir parceiro e dados de transportador.


*************** ADENDO 2019 **********************

Resolvi colocar uma observação importante, já q o post acima é bem antigo. Há 6 anos estive fora da consultoria e voltando já percebi q muita coisa mudou depois da entrada da NF eletrônica. Pois bem só para complementar o post acima.

Hoje temos boas opções para alterar a nota fiscal, eu tenho um post mais recente sobre essa badi.
J_1BNF_ADD_DATA, que permite alterar todas essas novas tabelas que foram criados para o processo de nota fiscal. DETALHE IMPORTANTE, se vc implementa essa BADI, vc pode ter problema na outra de alterar o XML a CL_NFE_PRINT, isso porque se ativado essa badi ADD_DATA  e o sistema identificar que foi alterado qualquer campo das estruturas passados na BADI, o sistema inopera a badi NFE_PRINT, veja q não são todos os casos. As informações sobre essas 2 badis deixei nos posts mais recentes.