on 06-24-2009 8:41 PM
Boa tarde pessoal,
estava conversando com o Fernando nesta [Thread|; e resolvi abrir uma nova thread.
Estava implementando a badi de impressão do danfe e notei um comportamento estranho.
Após gerar uma NFe, é gerado um registro na NAST.
Na sequencia, executo o FM J_1B_NFE_XML_IN para simular o aceite desta NFe, o que acarreta na chamada da badi de impressão e na minha badi tenho a chamada p/ o FM J_1BNFE_CALL_RSNAST00.
Dentro deste FM, ele move alguns parâmetros de entrada para a NAST e chama o form einzelnachricht, que chama tnaprlesen_, optischearchivierung_, programmaufrufen_, protocolstore_ e finalmente o nastupdate_.
Neste ponto do programa, a chave que tenho no header da tabela NAST é diferente da que já consta na tabela do bd.
No BD tenho este registro na NAST:
MANDT 321
KAPPL NF
OBJKY 0003347752
KSCHL ZNFE
SPRAS E
PARNR
PARVW
ERDAT 06/24/2009
ERUHR 14:38:41
e no programa, no form nastupdate_, tenho o header da NAST assim:
MANDT
KAPPL NF
OBJKY 0003347752
KSCHL ZNFE
SPRAS
PARNR
PARVW
ERDAT 00000000
ERUHR 000000
Sendo assim, quando ele dá o update nast. ele dá sy-subrc = 4, e na sequencia, o código trata if sy-subrc ne 0, insert nast. Com isso tenho 2 registros na NAST pra mesma NF, um com o status VSTAT = 1, mas com o SPRAS/ERDAT/ERUHR não preenchidos e o outro, o "original", com tudo preenchido porém com o status VSTAT = 0.
Olhando o Spool na SP01 eu vejo a NFe "impressa" apenas uma vez, o que está correto. Mas o que me incomoda é que ele acaba gerando registros duplicados.
Segue meu código da BADI:
IF i_active-code EQ '100' "NF-e autorizada
AND i_active-printd IS INITIAL "só imprimir automaticamente se ainda não foi impressa
AND i_active-cancel IS INITIAL "não faz sentido imprimir autom. se ela foi cancelada
AND i_active-conting_s IS INITIAL. "não faz sentido imprimir autom. se ela foi alternada
"p/conting. pois deverá ser cancelada
CALL FUNCTION 'J_1BNFE_CALL_RSNAST00'
EXPORTING
I_ACTIVE = i_active
I_DIMME = 'X'
I_PRINTER = vl_printer
EXCEPTIONS
no_printer = 1
others = 2.
COMMIT WORK.
IF sy-subrc = 0.
CALL FUNCTION 'J_1B_NFE_ERROR_PROTOKOLL'
EXPORTING
i_docnum = i_active-docnum.
ENDIF.
ENDIF.
Para "resolver" esse pequeno problema (ao meu ver, não sei se está correto ou não este comportamento), criei um FM Z com o seguinte código:
FUNCTION ZBR_J_1BNFE_CALL_RSNAST00.
*"----
-
""Local Interface:
*" IMPORTING
*" VALUE(I_ACTIVE) TYPE J_1BNFE_ACTIVE
*" VALUE(I_KAPPL) TYPE NAST-KAPPL DEFAULT 'NF'
*" VALUE(I_NACHA) TYPE NAST-NACHA DEFAULT '1'
*" VALUE(I_DIMME) TYPE NAST-DIMME DEFAULT 'X'
*" VALUE(I_PRINTER) TYPE RSPONAME OPTIONAL
*" EXCEPTIONS
*" PRINT_ERROR
*"----
-
TABLES: nast.
SELECT SINGLE *
FROM nast
WHERE kappl = i_kappl AND
objky = i_active-docnum AND
kschl = i_active-form AND
nacha = i_nacha AND
vstat = '0'.
*
start printing
nast-kappl = i_kappl.
nast-objky = i_active-docnum.
nast-kschl = i_active-form.
nast-nacha = i_nacha. "1 = print output
"nast-ldest = i_printer.
"nast-dimme = i_dimme. "X = print immidiately
PERFORM einzelnachricht IN PROGRAM rsnast00 USING sy-subrc.
*
IF NOT sy-subrc IS INITIAL.
MESSAGE i230(8b) with i_active-docnum RAISING print_error. "#EC *
ENDIF.
*
ENDFUNCTION.
e na BADI, o chamei desta forma:
CALL FUNCTION 'ZBR_J_1BNFE_CALL_RSNAST00'
IN BACKGROUND TASK
EXPORTING
i_active = i_active
EXCEPTIONS
no_printer = 1
others = 2.
Desta maneira, não ocorreu a duplicação dos registros da NAST e a nota também foi impressa OK.
A minha dúvida é se realmente o comportamento esperado utilizando o primeiro procedimento é duplicar o registro na NAST ou se pode ser que tenha algo errado no meu sistema(SAP_APPL 602 SP01) na hora da chamada da RSNAST00.
Bom dia,
Também estivemos fazendo testes com esta função, e observamos que o spool do DANFE fica em nome do usuário do PI, que faz a conexão com o ECC e executa a função de impressão.
Assim, quando o usuário do ECC que iniciou o processo tenta consultar o spool, precisa procurar com nome do usuário do PI.
Será que deve funcionar assim mesmo?
Atenciosamente,
Luciana M. M. Kanno
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Deletei as msgs duplicadas.
Quanto ao usuario, é isso mesmo, pois a impressao é iniciada apenas após a aprovacao da SEFAZ.
Note que há uma mudanca de conceito com NFe: o usuario nao solicita mais impressao de nota. Ele solicita autorizacao p/ emissao de Nota.
Após a aprovação, o sistema pode automaticamente imprimi-la (e daí por isso que vai com o usuario RFC) ou o usuario pode posteriormente solicitar manualmente a impressao, através da J1B3N.
Att.
Henrique.
Foi aberto chamado junto a SAP para verificar o ocorrido.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Senhores,
após abertura de chamado na SAP referente a este bug, temos uma nota corretiva.
https://service.sap.com/sap/support/notes/1365293
[]'s
parte 2
Segue meu código da BADI:
IF i_active-code EQ '100' "NF-e autorizada
AND i_active-printd IS INITIAL "só imprimir automaticamente se ainda não foi impressa
AND i_active-cancel IS INITIAL "não faz sentido imprimir autom. se ela foi cancelada
AND i_active-conting_s IS INITIAL. "não faz sentido imprimir autom. se ela foi alternada
"p/conting. pois deverá ser cancelada
CALL FUNCTION 'J_1BNFE_CALL_RSNAST00'
EXPORTING
I_ACTIVE = i_active
I_DIMME = 'X'
I_PRINTER = vl_printer
EXCEPTIONS
no_printer = 1
others = 2.
COMMIT WORK.
IF sy-subrc = 0.
CALL FUNCTION 'J_1B_NFE_ERROR_PROTOKOLL'
EXPORTING
i_docnum = i_active-docnum.
ENDIF.
ENDIF.
Para "resolver" esse pequeno problema (ao meu ver, não sei se está correto ou não este comportamento), criei um FM Z com o seguinte código:
FUNCTION ZBR_J_1BNFE_CALL_RSNAST00.
*" IMPORTING
*" VALUE(I_ACTIVE) TYPE J_1BNFE_ACTIVE
*" VALUE(I_KAPPL) TYPE NAST-KAPPL DEFAULT 'NF'
*" VALUE(I_NACHA) TYPE NAST-NACHA DEFAULT '1'
*" VALUE(I_DIMME) TYPE NAST-DIMME DEFAULT 'X'
*" VALUE(I_PRINTER) TYPE RSPONAME OPTIONAL
*" EXCEPTIONS
*" PRINT_ERROR
TABLES: nast.
SELECT SINGLE *
FROM nast
WHERE kappl = i_kappl AND
objky = i_active-docnum AND
kschl = i_active-form AND
nacha = i_nacha AND
vstat = '0'.
*
* start printing
nast-kappl = i_kappl.
nast-objky = i_active-docnum.
nast-kschl = i_active-form.
nast-nacha = i_nacha. "1 = print output
"nast-ldest = i_printer.
"nast-dimme = i_dimme. "X = print immidiately
PERFORM einzelnachricht IN PROGRAM rsnast00 USING sy-subrc.
*
IF NOT sy-subrc IS INITIAL.
MESSAGE i230(8b) with i_active-docnum RAISING print_error. "#EC *
ENDIF.
*
ENDFUNCTION.
continua
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
parte 3
e na BADI, o chamei desta forma:
CALL FUNCTION 'ZBR_J_1BNFE_CALL_RSNAST00'
IN BACKGROUND TASK
EXPORTING
i_active = i_active
EXCEPTIONS
no_printer = 1
others = 2.
Desta maneira, não ocorreu a duplicação dos registros da NAST e a nota também foi impressa OK.
A minha dúvida é se realmente o comportamento esperado utilizando o primeiro procedimento é duplicar o registro na NAST ou se pode ser que tenha algo errado no meu sistema(SAP_APPL 602 SP01) na hora da chamada da RSNAST00.
fim
Não abri chamado pois não sabia se era "esperado" criar 2 entradas na NAST.
Gostaria de saber dos outros usuários se isto também ocorre no sistema deles, utilizando esta abordagem "padrão" na BADI.
Quanto a testar sem comentar os campos i_printer e i_dimme, fiz um teste aqui e não passei nada nesses parametros e sendo assim, foram os 2 em branco.
A NF não apareceu na SP01 e na NAST apareceu como VSTAT=1 e os campos LDEST e DIMME ficaram vazios.
A grande questão foi ter que redeterminar a impressora que já tinha sido determinada antes, no momento da criação da NF.
Acredito que daria pra manter meu código Z do jeito que está, apenas verificando se o usuário passou algum parametro(I_KAPPL, I_NACHA, I_DIMME, I_PRINTER) com valor e se ele passou, sobrescrever a NAST com os valores repassados. Assim o usuário da função ainda teria controle sobre onde quer imprimir, mesmo que seja em um local diferente do determinado anteriormente.
Tentando resolver o problema da formatação do post acima....
Edited by: Jose Nunes on Jun 24, 2009 4:49 PM
Bom, não consigo mais editar a mensagem principal. Henrique, poderia arrumar?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
parte 1
Boa tarde pessoal,
estava conversando com o Fernando nesta [Thread|; e resolvi abrir uma nova thread.
Estava implementando a badi de impressão do danfe e notei um comportamento estranho.
Após gerar uma NFe, é gerado um registro na NAST.
Na sequencia, executo o FM J_1B_NFE_XML_IN para simular o aceite desta NFe, o que acarreta na chamada da badi de impressão e na minha badi tenho a chamada p/ o FM J_1BNFE_CALL_RSNAST00.
Dentro deste FM, ele move alguns parâmetros de entrada para a NAST e chama o form einzelnachricht, que chama tnapr_lesen, optische_archivierung, programm_aufrufen, protocol_store e finalmente o nast_update.
Neste ponto do programa, a chave que tenho no header da tabela NAST é diferente da que já consta na tabela do bd.
No BD tenho este registro na NAST:
MANDT 321
KAPPL NF
OBJKY 0003347752
KSCHL ZNFE
SPRAS E
PARNR
PARVW
ERDAT 06/24/2009
ERUHR 14:38:41
e no programa, no form nastupdate_, tenho o header da NAST assim:
MANDT
KAPPL NF
OBJKY 0003347752
KSCHL ZNFE
SPRAS
PARNR
PARVW
ERDAT 00000000
ERUHR 000000
Sendo assim, quando ele dá o update nast. ele dá sy-subrc = 4, e na sequencia, o código trata if sy-subrc ne 0, insert nast. Com isso tenho 2 registros na NAST pra mesma NF, um com o status VSTAT = 1, mas com o SPRAS/ERDAT/ERUHR não preenchidos e o outro, o "original", com tudo preenchido porém com o status VSTAT = 0.
Olhando o Spool na SP01 eu vejo a NFe "impressa" apenas uma vez, o que está correto. Mas o que me incomoda é que ele acaba gerando registros duplicados.
continua
Edited by: Jose Nunes on Jun 24, 2009 5:00 PM
Edited by: Jose Nunes on Jun 24, 2009 5:01 PM
User | Count |
---|---|
6 | |
5 | |
2 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.