cancel
Showing results for 
Search instead for 
Did you mean: 

Método CHECK SUBSEQUENT DOCUMENTS impede cancelamento de algumas NFe´s

Former Member
0 Kudos

Bom dia a todos,

Após implementarmos o método CHECK_SUBSEQUENT_DOCUMENTS no QA para impedir a solicitação de estorno cancelamento (através do usuário) de NFe´s do mês anterior, nos primeiros dias do mês subsequente, verificamos que algumas NF-e´s geradas e aprovadas num mesmo dia, são impedidas também de se requisitar o cancelamento, ou seja não se permite nem disparar a solicitação de cancelamento através da J1BNFE para algumas NF-e, sendo assim, ainda não estamos seguros em nossos testes para mover este método para o PRD.

Como parâmetros, implementos este método com base no código ABAP sugerido no material de treinamento de NF-e elaborado no Workshop de NF-e realizado pela SAP (WBRNFE 6.0 Português de 2008).

Alguém já passou por este problema?

Desde já agradeço.

André

METHOD if_ex_cl_nfe_print~check_subsequent_documents.

*----


*

  • types *

*----


*

TYPES: BEGIN OF ty_type_doc,

reftyp TYPE j_1bnflin-reftyp,

refkey TYPE j_1bnflin-refkey,

END OF ty_type_doc.

*----


*

  • Tables and Structures *

*----


*

DATA: tl_type_doc TYPE TABLE OF ty_type_doc,

tl_return TYPE TABLE OF bapireturn1,

tl_success TYPE TABLE OF bapivbrksuccess,

el_type_doc TYPE ty_type_doc,

el_message TYPE bapireturn1.

*----


*

  • Variables *

*----


*

DATA: i_billing TYPE vbeln.

*----


*

  • Constants *

*----


*

CONSTANTS: cl_1(1) TYPE c VALUE '1',

cl_0567(4) TYPE c VALUE '0567',

cl_bi TYPE j_1bnflin-reftyp VALUE 'BI',

cl_x(1) TYPE c VALUE 'X',

cl_s(1) TYPE c VALUE 'S'.

*----


*

  • *

*----


*

CLEAR: tl_type_doc, tl_return, tl_success,

el_type_doc, el_message, i_billing.

CHECK is_active-docsta EQ cl_1.

CHECK is_active-scssta CA cl_0567.

CHECK is_active-cancel IS INITIAL.

SELECT reftyp refkey

FROM j_1bnflin

INTO TABLE tl_type_doc

WHERE docnum EQ is_active-docnum.

CHECK sy-subrc EQ 0.

SORT tl_type_doc.

DELETE ADJACENT DUPLICATES FROM tl_type_doc.

LOOP AT tl_type_doc INTO el_type_doc.

CASE el_type_doc-reftyp.

WHEN cl_bi.

MOVE: el_type_doc-refkey TO i_billing,

cl_x TO sy-binpt.

CALL FUNCTION 'BAPI_BILLINGDOC_CANCEL1'

EXPORTING

billingdocument = i_billing

testrun = cl_x

no_commit = cl_x

TABLES

return = tl_return

success = tl_success.

DELETE tl_return WHERE type EQ cl_s.

READ TABLE tl_return INTO el_message INDEX 1.

IF sy-subrc EQ 0.

MOVE: el_message-type TO sy-msgty,

el_message-number TO sy-msgno,

el_message-id TO sy-msgid,

el_message-message_v1 TO sy-msgv1,

el_message-message_v2 TO sy-msgv2,

el_message-message_v3 TO sy-msgv3,

el_message-message_v4 TO sy-msgv4.

ch_subrc = 4.

ENDIF. " IF sy-subrc EQ 0.

EXIT.

WHEN OTHERS.

EXIT.

ENDCASE.

ENDLOOP.

ENDMETHOD.

Accepted Solutions (0)

Answers (1)

Answers (1)

former_member182114
Active Contributor
0 Kudos

Bom dia BBKO,

Não vi nada óbvio errado no seu código.

Essa data de posting da NF-e e do billing document estão em período aberto? Talvez a nota não devesse ter sido criada, o que é uma outra issue mas seu código do CHECK SUBSEQUENT DOCUMENTS estaria correto.

Isso acontece também quando você faz uma nova venda+fatura e tenta cancelar?

Que mensagens você obtem ao tentar o cancelamento?

Já debugou para tentar entender o que está acontecendo?

Veja este comportamento nesta thread:

Atenciosamente, Fernando Da Ró

Former Member
0 Kudos

Boa tarde Fernando,

Respondendo as suas perguntas:

Essa data de posting da NF-e e do billing document estão em período aberto?

Sim, esta data de NF-e que estamos tentanto estornar encontra-se dentro de perído aberto, foi gerada em 26.07.2010.

Isso acontece também quando você faz uma nova venda+fatura e tenta cancelar?

Sim, está ocorrendo em alguns casos para NF-e emitida e faturada no mesmo dia.

Que mensagens você obtem ao tentar o cancelamento?

Um exemplo da mensagem de erro (caso citado acima):

Gravado doc. $000000002 (não foi criado documento contábil)

Nº mensagem VF050

Já debugou para tentar entender o que está acontecendo?

Geramos algumas notas ontem (29/07) e hoje (30/07), na 2a. feira iremos tentar executar estes estornos para analisar o comportamento, quando estaremos debugando para retornar maiores detalhes aqui neste fórum, ok?!

Desde já agradeço.

André

Former Member
0 Kudos

Olá,

BBKO, conseguiu alguma coisa referente ao erro?

estamos com o mesmo erro por aqui, quando vamos estornar pela J1BNFE:

Gravado doc. $000000002 (não foi criado documento contábil)

Nº mensagem VF050

Obrigado.

former_member182114
Active Contributor
0 Kudos

Pergunta:

Por que vocês estão deixando executar o método check_subsequent_documents com o mesmo código que no pedido de cancelamento?

Digo, este método é chamado em dois momentos:

1) Ao tentar solicitar o cancelamento no J1BNFE

2) Ao receber uma autorização para cancelar

Apesar de ser um método só, o ideal é vocês controlarem a execução para a "verificação" só ser feita no primeiro momento, no segundo... Inês é morta, já foi cancelada na Sefaz.

Atenciosamente, Fernando Da Ró

Former Member
0 Kudos

Olá Pitoshi,

Referente ao erro observamos de diferente apenas que, por se tratar de uma mensagem do tipo "Warning", ao se teclar um simples "Enter", o documento contábil permite ser gerado, no caso de estar sendo cancelada uma NF-e dentro do mês corrente.

Por favor, verifique se com você ocorre o mesmo.

Abs.

André Teixeira

Former Member
0 Kudos

Olá Fernando,

Entendi sua sugestão e já estou analisando com o ABAP por aqui para implementarmos.

Creio que este seja o motivo da mensagem (warning) ficar aguardando uma confirmação, um "enter".

Gravado doc. $000000002 (não foi criado documento contábil)

Nº mensagem VF050

Vamos testar isso e retorno aqui o resultado do teste.

Grato.

André Teixeira

Former Member
0 Kudos

Comigo acontece o Mesmo, apenas dando Enter passa tranquilo pelo Warning, vou aguardar o resultado desse teste para analisar se aplicamos isso também aqui ou não.

Por favor se conseguir algo poste para nós

obrigado

former_member182114
Active Contributor
0 Kudos

Bom dia Pitoshi/André,

@André, nos testes que está fazendo verifique a situação na SM12, talvez esteja ficando algum lock. Se isto estiver acontecendo pode ser caso de abrir chamado pois a função de simulação terminou e não liberou seus locks.

Indepentende disso, verifique a necessidade de fazer o check apenas para o pedido de cancelamento.

Duas coisas diferentes que andam juntas.

Atenciosamente, Fernando Da Ró