Dúvida no cancelamento de uma NFe Rejeitada

Boa tarde a todos,
Estou com uma dúvida quanto ao processo de cancelamento de uma NFe rejeitada e agradeço antecipadamente a colaboração dos colegas aqui do forum que possam ter passado por situação semelhante.
Temos o seguinte cenário: implementação SAP ECC 6.0 (SP13), já foram aplicadas uma série de notas dos SP14, SP15 e SP16 para resolver outros problemas que surgiram ao longo do projeto. O sistema de mensageria não é o GRC SAP, o cliente optou pela solução da Mastersaf.
O problema ocorre quando o usuário cancela uma NFe (opção "Solicitar Estorno") que está rejeitada pela validação da mensageria (NFe sem CPF do cliente, por exemplo). Como esta NFe não foi enviada à SEFAZ, o sistema interpreta o cancelamento como uma inutilização de número. Até este ponto tudo perfeito, o procedimento é correto, segundo nosso entendimento. O problema é que ao consultar a inutilização, tanto no sistema Mastersaf quanto na SEFAZ, o número inutilizado foi o número aleatório (DOCNUM9) e não o número da NFe (NFENUM).
Debugando a rotina, descobrimos que o "problema" está no módulo de função J_1B_NFE_SEND_REQUESTS, onde há uma linha onde a rotina move o número aleatório para a estrutura que irá gerar o XML para a mensageria ("xmlh-nnf  = ls_acttab-docnum9.").
A pergunta é se isso está correto ou se é um bug da função? Procurei por alguma nota OSS que tratasse isso mas não encontrei nada.
Vocês já se depararam com essa situação?
Um abraço,
Rinaldo Conte

Bom dia Rinaldo,
Talvez este problema esteja limitado ao R/3 NFe x MasterSAF. Como a interface chamada é a de inutilização, entende-se que já ocorreu uma tentativa de envio ( o que envia o NNF corretamente ). Então ao solicitar a inutilização a mensageria poderia partir deste NNF correto para proceder a inutilização.
De qualquer forma, parece que você encontrou um bug no envio de dados à interface de inutilização.
Discuta este ponto com o fornecedor da mensageria, pode ser necessário abrir chamado à SAP para modificação.
Atenciosamente,
Fernando Da Ró

Similar Messages

  • Assinatura de uma NFe

    Olá...
    Estamos tentando enviar uma NFe, mas recebo o seguinte em SIGNN_SignNFe_OB no sxmb_monitor:
    <?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
    - <!--  Response
      -->
    - <SAP:Error xmlns:SAP="http://sap.com/xi/XI/Message/30" xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/" SOAP:mustUnderstand="">
      <SAP:Category>XIAdapter</SAP:Category>
      <SAP:Code area="BPE_ADAPTER">NEGATIVE_ACKNOWLEDGEMENT</SAP:Code>
      <SAP:P1 />
      <SAP:P2 />
      <SAP:P3 />
      <SAP:P4 />
      <SAP:AdditionalText />
      <SAP:ApplicationFaultMessage namespace="" />
      <SAP:Stack>Negative acknowledgment triggered by a process</SAP:Stack>
      <SAP:Retry>M</SAP:Retry>
      </SAP:Error>
    E na resposta de SIGNN_SignNFe_SYNC:
    <?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
    - <!--  Request Message Mapping
      -->
    - <SAP:Error xmlns:SAP="http://sap.com/xi/XI/Message/30" xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/" SOAP:mustUnderstand="">
      <SAP:Category>Application</SAP:Category>
      <SAP:Code area="MAPPING">STREAM_TRANSFORMATION_EX</SAP:Code>
      <SAP:P1>sap/com/xi/nfe/map/SIGN_SignNFeCancInutConverter</SAP:P1>
      <SAP:P2>Exception in Java mapping occured while parsing t~</SAP:P2>
      <SAP:P3 />
      <SAP:P4 />
      <SAP:AdditionalText />
      <SAP:ApplicationFaultMessage namespace="" />
      <SAP:Stack>Java mapping of application triggered an exception</SAP:Stack>
      <SAP:Retry>N</SAP:Retry>
      </SAP:Error>
    Isso ocorreu em apenas uma nota...
    Estou tentando achar algum problema de parse, nos XMLs, mas não identifiquei nada ainda.
    Obrigado.

    Olá.
    O problema é o da mensagem acima... o XML veio com uma informação que o GRC não conseguiu fazer o parse... daí não consegue assinar.
    Por exemplo, a NF possui alguns itens, mas o total da NF fica 0,00 no GRC.
    Mas no ERP, na j1bnfe, ela está em processamento.
    Daí vem a dúvida...
    Ela não pode ser reprocessada, por ter problemas no XML, preciso devolver algo ao ERP para que saia do status de processamento, e assim ela possa ser corrigida, e reenviada...
    Basicamente é isso que eu imagino como solução.
    Obrigado.

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

    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.

    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é

  • Inutilização de uma nfe com mensageria não sap

    Prezados Colegas,
    Gostaria de solicitar uma preciosa ajuda de vocês.
    Estou em um projeto de implementação, utilizando a solução SAP para NF-e, porém com uma mensageria NÃO-SAP que o cliente já utiliza hoje.
    Preciso entender como funciona o seguinte cenário:
    Foi emitida uma NF-e no ERP SAP e enviada para a Mensageria. Por algum problema na SEFAZ não houve uma resposta para a mensageria e neste intervalo o faturista vê que tinha erro na NF-e e resolve cancelar a nota.
    No monitor de NF-e a nota está com estes parâmetros:
    Status Ação : engrenagem
    Etapa do Processo: em processamento
    Status do Documento: Aguardar resposta
    Status de Com. Sistema: Enviado ao Sistema de Envio de mensagens
    Como devo proceder para cancelar esta nota e solicitar inutilização na SEFAZ ? A NF-e tem uma chave de acesso, a Inutilização vai gerar uma outra chave correto?, e na volta está chave  (da inutilização) ficará gravada na tabela, e no Livro de Saídas aparecerá como inutilizada ?
    Confirmem se são estes os passos que tenho que seguir:
    No monitor, seleciono a nota e faço um ESTORNO ANTES DA AUTORIZAÇÃO;  em seguida ESTORNAR DOCUMENTO DE ORIGEM, e depois eu clico em ENVIAR (ESTA É A SOLICITAÇÃO DE INUTILIZAÇÃO ?)
    E pelo fato de ser outra mensageria, tem alguma implicação diferente, algo que eventualmente não funcione na atualização do SAP ?
    Antecipadamente agradeço,
    Diógenes

    Fernando,
    Eu vou reformular minha questão, porque acredito que misturei o cenário que o cliente comentou que existe hoje e como isto se daria no SAP, com o que realmente eu preciso saber que é a Inutilização de uma nota fiscal.
    Então o cenário seria este:
    O  usuário criou uma nota, e se deu conta que criou errada e precisa cancelá-la, a nota foi para a mensageria, porém esta (a mensageria)  por algum motivo, alguma falha na SEFAZ, o ambiente estava fora, algo parecido, ainda não tinha recebido resposta para a nota, se foi autorizada ou rejeitada, consequentemente o monitor de NF-e no SAP não foi atualizado, para esta nota na coluna Status da Ação, continua aparecendo a "engrenagem".
    Para que o usuário cancele esta nota no SAP e na sequencia peça a inutilização, tudo isso levando-se em conta que não obtivemos a resposta da SEFAZ, a sequencia de passos que ele tem que fazer é esta que coloco abaixo ? :
    1 - No monitor, seleciona a NF-e
    2 - Escolhe "Estorno antes da Autorização"
    3 - Na coluna ETAPA aparece a atividade "2"
    4 - Escolho "Estornar documento de Origem"
    5 - Enviar NF-e as Autoridades Fiscais
    E levando-se em conta que a SEFAZ não respondeu da 1a vez, que a nota não consta na base de dados dela, então a SEFAZ deve aprovar a inutilização.
    Pelo fato de ser uma outra mensageria, o processo acontece normalmente, não há nenhum desenvolvimento a ser feito do lado do ERP SAP para que esta situação seja atendida, a saída da solicitação de inutilização é feita normalmente pela função J_1B_NFE_XML_OUT, e no nosso caso aqui temos o PI como middleware que envia os dados para a mensageria NÃO - SAP. Nós já fizemos o desenvolvimento para atender a Inutilização quando se tratar do gap de numeração, em que usamos o programa J_1BNFECHECKNUMBERRANGES.
    Desculpe, se não fui muito claro anteriormente.
    Atenciosamente,
    Diógenes

  • NFe 3.10 Devolução com mais de uma NFe referenciada

    Caros,
    Estamos realizando o teste para o cenário de Devolução utilizando o layout do XML 3.10 através da NF-e.
    O manual técnico (NT2013.005_v1.03.pdf), em sua página 46, dá a entender que podem ser refenciadas várias NFes a serem devolvidas em uma única NFe de Devolução.
    "BA. Documento Fiscal Referenciado
    Informação de Documentos Fiscais referenciados.
    Grupo com informações de Documentos Fiscais referenciados. Informação utilizada nas hipóteses previstas na legislação. (Ex.: Devolução de mercadorias, Substituição de NF cancelada, Complementação de NF, etc.)."
    Ocorrência: 0-500
    O nosso teste consiste em fazer várias entradas (Físico e Fiscal) para o mesmo fornecedor, e após isto, gerar uma única Nota de Crédito referenciando a cada uma dessas NFe entradas.
    Porém, ao executar a MIRO, na operação de Nota de Crédito, o sistema permite apenas referenciar um único DOCNUM (NFe).
    Há alguma nota SAP ou atendimento à este requerimento da Nota Técnica?
    O entendimento está correto?
    Alguém testou esse cenário desta forma?
    Att,
    Levi Luis

    Então, Luciano
    lá, o que dá a entender, é que uma mesma NF-e de devolução pode ter várias NFes de referencia.
    Veja:
    "Permitida novamente a consolidação de várias devoluções de NF-e distintas, em uma mesma NF-e de devolução de mercadoria (eliminada a validação “B25-80”)"
    É nisso que a área usuária está se apegando para cobrar a melhoria da SAP.
    O que eles estão entendendo é que o layout 3.10 do XML daria essa abertura de consolidar várias NF-es a serem devolvidas em uma única NF-e, o que simplificaria o operacional (já que atualmente o SAP, via MIRO, só trabalha com Devolução 1 x 1).

  • Dúvida no fluxo do processo de rejeição/recusa

    Bom dia, pessoal,
    Embora tenha participado de alguns projetos de nota fiscal eletrônica, uma coisa nunca ficou muito clara para mim. Estou em um novo projeto agora e eu queria fazer da melhor forma possível.
    A primeira dúvida é sobre Recusa/Rejeição. Basicamente qual a diferença entre os dois? Eu sempre entendi que uma nota é rejeitada pela SEFAZ, e recusada pela validação do GRC ou do outro sistema de mensageria. Essa abordagem está correta?
    A segunda dúvida é sobre essa mesma validação. Quando o GRC, ou outro sistema encontra erros de sintaxe do arquivo, ou de qualquer informação, qual deve ser o status dessa nota? Ela deve ficar como recusada? E o status de comunicação do sistema?
    Quando uma nota fiscal está recusada, qual o melhor fluxo? Considerando que o erro foi apontado pelo sistema de mensageria e não pela SEFAZ, a nota fiscal não pode ser cancelada. O sistema também não permite o estorno da nota, nem mesmo depois de resetar seu status . Uma vez eu debuguei e vi que é porque ela está numerada.
    Meu último problema é sobre inutilização. Alem do report, existe alguma outra forma de fazer a inutilização, direto pelo monitor? Penso em fazer isso justamente quando uma nota está recusada/rejeitada sem ter ido para o SEFAZ. Daí usaríamos a própria entrada dela, no monitor, para solicitar a inutilização da numeração.
    É Isso...
    Obrigado,
    Fernando Fussi

    Bom dia Fernando,
    Esta dúvida é comum principalmente que boa parte dos projetos (no início) não fez a implementação de NF-e por Support Package mas por aplicação de notas, então os termos originais Rejected and Denied foram traduzidos de forma diferente em cada projeto (a SAP só entrega traduções por SP), isso deu margem a boa confusão no tema.
    A primeira dúvida é sobre Recusa/Rejeição. Basicamente qual a diferença entre os dois?
    Existe rejeição (2xx, 4xx,999) e denegação (301 / 302)
    - Na rejeição a Sefaz rejeita por algum dado incorreto e não deixa salvo no banco de dados dela, você deve tentar corrigir e enviar quantas vezes necessário
    - Na denegação é uma situação específica que o emissor ou o destinatário estão com irregularidade fiscal junto à Receita, neste caso a NF-e é armazenada na base da Sefaz e não deve ser novamente enviada (o ERP ao receber a denegação dispara o cancelamento automaticamente)
    Eu sempre entendi que uma nota é rejeitada pela SEFAZ, e recusada pela validação do GRC ou do outro sistema de mensageria. Essa abordagem está correta?
    - Sim, a rejeição da validação é devido a algo que provocaria uma rejeição da Sefaz se enviado você também pode tentar acertar até passar pelo validador/Sefaz
    A segunda dúvida é sobre essa mesma validação. Quando o GRC, ou outro sistema encontra erros de sintaxe do arquivo, ou de qualquer informação, qual deve ser o status dessa nota?Ela deve ficar como recusada? E o status de comunicação do sistema?
    - Sim, rejeitado pelo validador MSS=V   DOCSTAT=vazio (o ERP não considera que a rejeição do validador tem peso igual a validação da Sefaz, porém pro processo é a mesma coisa que no ERP tem status específicos)
    Veja detalhes sobre status e situações aqui:
    Status do SAP Nota Fiscal Eletrônica (ERP x GRC x PI)
    ou em inglês:
    NF-e Status on SAP Nota Fiscal Electronica Solution (ERP x GRC x PI)
    Quando uma nota fiscal está recusada, qual o melhor fluxo? Considerando que o erro foi apontado pelo sistema de mensageria e não pela SEFAZ
    - Em linhas gerais o fluxo básico seria RESET + tentar corrigir o que o GRC ou a Sefaz informaram + NF-e -> Send
    , a nota fiscal não pode ser cancelada. O sistema também não permite o estorno da nota, nem mesmo depois de resetar seu status . Uma vez eu debuguei e vi que é porque ela está numerada.
    - Em um ERP e GRC corretamente atualizado com os SP's e notas isso não é normal em cada caso a causa raiz deve ser encontrada e sanada com notas ou chamado à SAP
    Meu último problema é sobre inutilização. Alem do report, existe alguma outra forma de fazer a inutilização, direto pelo monitor?
    - Que report? O de encontrar gaps? Este report é para sanar um side effect quando os clientes não implementaram ainda o decouple. Hoje em dia todos os clientes devem implementar o decouple job para evitar vários transtornos como (gaps (já não dá mais medo), NF-e autorizada no GRC/Sefaz e não existe no ERP (isso é terrível), inconsistência de transmissão (dados obtidos em memória X dados obtidos do banco)....
    - Inutilização é direto no monitor, que situação está descrevendo?
    Penso em fazer isso justamente quando uma nota está recusada/rejeitada sem ter ido para o SEFAZ. Daí usaríamos a própria entrada dela, no monitor, para solicitar a inutilização da numeração.
    - não entendi. Hoje uma nota Rejected seja pela Sefaz ou pelo validador deve ser cancelada pelo monitor J1BNFE. Entendi errado sua pergunta?
    - Existe também uma nova funcionalidade "Cancel Prior Authorization" que permite o cancelamento de uma NF-e antes mesmo dela ter sido numerada
    Atenciosamente, Fernando Da Ró

  • Nota Fiscal Eletrônica de Cancelamento

    Prezados,
    As notas fiscais modelo 1 e 1A quando são canceladas é possível efetuar a visualização da NF de cancelamento pela J1B3N.
    Cancelei uma NFe através da J1BNFE e não foi possível visualizar a NFe de cancelamento através da J1B3N.
    O sistema exibe a seguinte mensagem:
    "No entry exists in the NF-e table for document number 0000001153"
    Diagnosis
    No entry exists for the received document number 0000001153 in the table J_1BNFE_ACTIVE.
    Alguém sabe me dizer porque não consigo mais visualizar esta nota de cancelamento, como era feito antes da Nfe?
    Muito Obrigada
    Cristina

    Bom dia Cristina,
    Uma nova nota NF-e pode referenciar uma NF 1/1A antiga, e sua visualização dá-se também pela J1B3N.
    Perguntas:
    - A nota 1175722 está aplicada em seu sistema ?
    - Tem uma nota nova 1355928, esta eh aplicada em cima das notas do decouple (começa nesta: 1265172, pegue todas as referentes)
    - Isto acontece para toda NF 1/1A ou é uma situação específica ?
    - Existe algum código não standard no cliente (BADI/EXIT/Enhancement) que faça commit no processo de gravação, que possa causar ter registro na J_1BNFDOC e nao ter na J_1BNFE_ACTIVE ?
    - Verificou se ocorreu algum erro de atualização neste processo (veja SM14 cancelled updates) <-- Basis
    Atenciosamente, Fernando Da Ros

  • NFe - Rej: 660 CFOP de Combustível não informado grp combustível da NF-e

    Pessoal,
    Bom dia.
    Estou com uma nota rejeitada pelo motivo 660.
    Verifiquei que este motivo de rejeição foi liberado na NT 2012/003.
    Foi utilizado o CFOP 6.659 no processo de transferência entre centros e como não foram enviados os dados da TAG (L1 - Detalhamento Específico de Combustíveis)  a NFe foi rejeitada.
    Verifiquei a nota de overview da NFe e ela menciona a aplicação da nota de 1766127 (SP 12), porém já estamos com este SP.
    Para enviar os campos pretendo utilizar a BADI de NFe porém gostaria de saber se alguém passou por este erro e se tratou da mesma fora.
    Encontrei algumas outras notas do lado do ECC que mencionam a criação de novos campos no cadastro mestre de material e um deles seria o cProdANP (Código de produto da ANP), diante disso gostaria de saber se alguém aplicou estas notas e o valor foi levado pelo standard ou continuou tratando via BADI.
    Seguem as notas que encontrei que mencionam o campo:
    1882947  NF-e: Storing Additional Data - Corrections for NF Writer
    1883752  Fill new master data fields into NF document (CNAE, CRT, ..)
    1860362  NF-e: Storing Additional Data - outbound NF-e & Reports
    1859126  NF-e: Storing Additional Data - Enhancement of NF Writer
    1860433 - NF-e: Storing Additional Data for DANFE & Reporting
    1877404 - NF-e: Enhancements NF Writer screen controls
    Desde já agradeço.
    Atenciosamente
    Cristina

    Boa tarde Cristina,
    Não sei se você já resolveu o problema, mas para poder aprovar a nota fiscal sem o erro 660 sendo retornado pela SEFAZ eu modifiquei os campos OIL_CPRODANP e OIL_UFCONS da estrutura do OUT_ITEM (Tipo J1B_NF_XML_BADI_ITEM) no item.
    BADI
    Estrutura
    Att,
    Fábio Caselato

  • NFe - erro 204

    Bom dia!
       Estou a 3 dias com uma NFe de tranferência parada ( engrenagem ) relacioanda ao erro 204 "Rejeicao: Duplicidade de NF-e [nRec:310001601853941]' e não consegui libera-la.
        Abri uma OSS, e depois de muito tempo me retornaram para realizar as instruções abaixo mas não encontrei resultado.
        Estamos na NFe 3.10 e não encontrei mais o botão "STATUS QUERY".
        Tentei  o botão "continuar processo" mas nada. "Outra funções" e nada.
    In order to solve this issue you'll have to manually adjust some
    fields in table /XNFE/OUTNFEHD.
    Table: /XNFE/OUTNFEHD
    ACTSTAT from 11 to 02
    LAST STEP STATUS  From 11 to 02
    Then go to NF-e web monitor and push the "STATUS QUERY". It should
    solve this NF-e issue.
          Retornei a dúvida para a OSS mas nada de resposta.
         Conseguimos liberar a mercadoria de nossa planta em MG emitindo uma DANFE pela SEFAZ, pois esta já foi autorizada, mas agora a mercadoria chegou em nossa planta de produção em SP em não conseguimos dar entrada.
       Alguém poderia nos ajudar?
    Grato.

    Bom dia Clayton
    Na empresa que trabalho, o que fizemos é:
    No Monitor de Saída do GRC, selecionamos a NFe com problema, vamos no menu "Outras funções - Solicitar Verificação de Status".
    No momento da solicitação a comunicação com o SEFAZ deve estar ativa.
    Verifique se o LOTE está concluído, caso não esteja, reinicie o LOTE.
    Outra opção é você verificar a Chave de Acesso da NFe no SEFAZ, se a NFe está aprovada, caso esteja, você pode ir no menu "Outras funções - Encerrar Ignorar" o sistema irá pedir algumas informações como "Protocolo de autorização".
    O nosso amigo Renan Correa postou uma ótima ajuda, conforme segue o link abaixo:
    Como lidar com os erros mais comuns a partir dos novos monitores de NF-e
    Qualquer coisa avise.
    Abraço.

  • Múltiplas NFes de entrada em um email

    Boa tarde senhores,
    Há algumas semanas percebi que a implementação "padrão" que fizeram da NFe de entrada considera apenas uma nota por email (unbelievable!). Além disso, pega o primeiro anexo e toca ficha... se esse primeiro anexo for o pdf com a danfe, crash, óbvio.
    Dei uma vasculhada no fórum e ninguém parece ter discutido sobre isso (ou cada um fez o seu e ficou por isso mesmo). Se alguém já teve de consertar isso e quiser partilhar a experiência, fique à vontade.
    Se ninguém tiver feito isso ainda, vou começar a fazer amanhã um adpater module pra tratar vários xml's de entrada. Quem quiser ajudar fique à vontade, vou postando aqui o progresso.
    T+
    Waldemar

    Boa tarde senhores,
    Então, depois das semanas de atropelo por causa do SAPForum, vamos voltar à programação normal.
    O adapter module está pronto. Ele cria uma nova mensagem adicionando a esta mensagem todos os anexos que possuem uma NFE (procurei pela tag .
    Já está testado e funcionando. Temos então chegando no integration engine o seguinte:
    <nfeList>
       <nfeProc>...</nfeProc>
       <nfeProc>...</nfeProc>
       <nfeProc>...</nfeProc>
    </nfeList>
    Agora, pra executar várias requisições pro grc (uma pra cada  em uma mensagem separada
    3 - Block com o atributo mode setado pra ForEach
    4 - Um sender dentro desse block pra enviar cada mensagem pra frente
    Pro atributo message do receiver (1) é necessário uma mensagem abstrata. Fiz uma cópia da mensagem NFB2B_procNFe_OB e alterei-a pra abstrata, criei uma interface variable pra ela e associei ao receiver.
    Para o transformation, source message é a mesma do receiver e para o target message criei uma nova interface variable de NFB2B_procNFe_OB, só que multiline. Aí vem a dúvida cruel. Embora a mensagem que eu esteja utilizando seja a NFB2B_procNFe_OB, o que vem do adapter engine não respeita esse schema, então fiz um mapping XSL pra quebrar a mensagem que entra em várias compatíveis com a NFB2B_procNFe_OB.
    Para o block, o multiline element é a target message do transformation. Criei uma nova interface variable pro atributo current line tendo como container o block.
    Para o sender configurei o atributo message com o current line do block.
    Amanhã pela manhã vou fazer a configuração no directory, vamos ver se vai.
    Tentei ser breve, intenção apenas de compartilhar o que estou fazendo. Se alguém encontrar alguma inconsistência no cenário, não deixe de dar um toque.
    T+
    Waldemar

  • NFe de inutilização com aguardando resposta

    Bom dia!
    Estou com uma NFe de inutilização que está com os seguintes status:
    SEFAZ - OK Inutilizada
    GRC - OK Inutilizada
    ECC - Não OK
    O problema é que a nota fiscal está como aguardando resposta, mas no monitor está como concluido já.
    Achei esse post no forum.
    Nele o Henrique cita que o status não precisa ficar como inutilizada ou cancelada, mas num post abaixo ele fala para buscar com status = 2 rejeitada. (docstat = 2 OR msstat = V)
    É correto a nota ficar com esse status? Aguardando resposta?
    Tabelas:
    J_1BNFEACTIVE
    DOCNUM          147892
    DOCSTA
    SCSSTA          A
    CONTING
    CANCEL          X
    CODE            102
    ACTION REQU     C
    PRINTD
    CONTING S
    MSSTAT          V
    REASON          02
    REASON1         Problema Operacional
    J_1BNFDOC
    DOCNUM        147892
    CANCEL        X
    CANDAT        02.07.2010
    AUTHCOD       135100396806804
    DOCSTAT
    XMLVERS       1,10
    NFENRNR       01
    CODE          102
    As notas já estão aplicadas:
    1376324     NF-e: Skip for NF-e with validation error
    1403811     NF-e: Disabling switch to contingency for MSS 'V' and 'G'
    1413636     NF-e: Skip NF-e with validation error - new status not set
    1420754     NF-e: authorization of documents with MSS 'G' not possible
    ECC
    SAP_ABA     700     0020     SAPKA70020
    SAP_BASIS     700     0020     SAPKB70020
    SAP_APPL     600     0016     SAPKH60016
    GRC
    SAP_ABA     700     0020     SAPKA70020
    SAP_BASIS     700     0020     SAPKB70020
    SLL-NFE     100     0012     SAPK-10012INSLLNFE
    Muito obrigado,
    Dalmo Costa

    Henrique Pinto wrote:
    Vc tem algum log de erro no ERP (bandeirinha vermelha na J1BNFE) ou status de erro de ERP no monitor do GRC?
    Na bandeira vermelha está:
    Novo status de comunicação de sistema "Autorização para rejeição & inutilização (cancela não permitido p/SCS "Erro de validação, mas acho que o usuario deve ter tentado inutiliza-la novamente.
    Henrique Pinto wrote:
    Vc tem o job /xnfe/update_erp_status schedulado?
    Então o job está schedulado de 15 em 15 min.

  • Inutilização de NFe com erro de validação

    Srs.
    Gostaria de tirar uma duvida mais "funcional" do processo de uma nfe, que seria a seguinte, caso uma NFE esteja com erro de validação no GRC, se o erro e o status voltou para o ERP e na j1bnfe ela esta com status 8, eu poderia solicitar a inutilização da mesma sem ter que envia-la antes ao SEFAZ ?
    Pergunto isso pois eu pensava que havia uma maneira e até agora não encontrei nenhuma.
    Se puderem me responder o mais rápido possível eu agradeceria.

    Oi Carlos.
    Então... quando ocorre um erro de validação você tem duas alternativas:
    - Corrigir os dados e reenviar a NF-e
    - Solicitar a inutilização (solicitar o cancelamento da NF-e no monitor)
    Para solicitar a inutilização - o registro da NF-e está com status da mensageria igual a V (erro de validação.
    1. Selecione o documento em questão
    2. Clique no botão "Request Cancellation"
    3. Sistema irá apresentar pop-up perguntando de realmente deseja continuar. Clique em Yes para confirmar.
    4. Selecione a razão do cancelamento.
    5. Selecione o documento a ser cancelado e clique no botão Copy to Selected Documents
    6. Clique no botão Send Requests. Sistema enviará a solicitação de inutilização. Após obter a autorização de inutilização o sistema irá retornar o status 102 de autorizada inutilização e reverter o lançamento.
    Abraço
    Eduardo Chagas

  • Possibilidade de evitar a continuação NFe ser publicado sob contingência

    Olá a todos,
      Só queria ver se alguém deparei com esse problema antes.
    O cenário é assim: - nós criamos uma NFE, esperando a resposta da SEFAZ, sem resposta, mudamos para contingência, cancelamento de pedido feito passo, cancelar o documento de origem (documento de faturamento). Ao criar um novo documento de faturamento a partir do documento de entrega, o novo NFE é automaticamente marcada publicado sob a contingência.
      Existe alguma era evitar o novo documento a ser publicado em contingência e, em vez processado normalmente e para que possamos imprimir o DANFE normalmente.
    Qualquer ajuda será apreciada.
    Honey

    Bom dia Honey,
    Este processo é standard e não há configuração para mudar este comportamento.
    Em SD ele verifica no fluxo de documentos se a nota anterior foi "Switched to contingency", então a nova é criada em contingência.
    Se quiser você pode codificar na BAdI CL_SD_NFTYPE, método MODIFY e colocar sua lógica para alterar o valor de CV_CONTING (contingência).
    Atenciosamente, Fernando Da Ró

  • Reenvio do GRC para o ERP do Status de NFe 225

    Pessoal,
    Enviamos uma Nfe que foi rejeitada pela SEFAZ, com o validador GRC desativado.
    Devido a uma falha de comunicação logada na /XNFE/BACKSTATUS o ERP não teve o update do status da nota, sendo que o GRC estava atualizado com o Status 225 para o lote, com o Error Status 46 para nota.
    Em análise do programa de reenvio /XNFE/UPDATE_ERP_STATUS percebemos que o status enviado ao ERP é o status do cabeçalho da Nfe (tabela /XNFE/NFEHD, campo STATCOD).
    Para o DOCNUM 138746, o campo STATCOD está em branco na tabela /XNFE/NFEHD, porém está preenchido na tabela /XNFE/BACKSTATUS, campo CSTAT como pode ser visto nos screenshots anexos.
    No ERP, então, temos o erro u201CNo status code was received for NF-e 0000138746u201D
    Existe alguma forma de reprocessar NF-e com status SEFAZ setado somente para o lote?
    Segue os prints das telas:
    http://img5.imageshack.us/img5/1936/screen1le5.jpg
    http://img232.imageshack.us/img232/1678/screen2zs7.jpg
    http://img232.imageshack.us/img232/4084/screen3ns1.jpg
    http://img232.imageshack.us/img232/5003/screen4nt6.jpg
    http://img232.imageshack.us/img232/1944/screen5hc2.jpg
    Obrigado,
    Dorval Neto.

    Bom dia Alexandre,
      O report /XNFE/UPDATE_ERP_STATUS foi lançado no SP05 através da nota 1251349, nela é comentado sobre a criação do job e a execução individual. Após esta nota o report foi modificado algumas vezes sendo a mais recente 1273616 ou SP06. Acredito que mais modificações são necessárias ao programa, como a descrita que não retorna individualmente para NFe que ocorreu rejeição 225 por lote.
      Quanto a como identificar o erro:
    a) NORMAL - Se foi uma rejeição de processamento "normal" do R/3, ou seja, por algum motivo conhecido ele rejeitou a resposta enviada pelo GRC, então a resposta será encontrada na tabela J_1BNFE_INVALID no R/3, procure pelo docnum (obter na /xnfe/nfehd-docnum). Existe algumas situações especiais que o R/3 usa como docnum o valor de 9999999999, invalidando a pesquisa anterior. Então procura pela data e hora (ACTION_DATE e ACTION_TIME) da transmissão do GRC para o R/3.
    b) ST22 - Se o não processamento no R/3 foi devido a algum dump no momento da execução da função ou alguma EXIT/BADI, então este não será logado corretamento no R/3. Verifique na ST22 do ERP se existe alguma informação no momento da execução do report update_erp_status.
    c) RFC - Se não encontrar nesta tabela no R/3 então o problema pode ser de comunicação ou impressão, neste caso verifique no GRC NFE os logs de RFC via transação AL11, é um pouco mais complicado, pois você terá pegar o exato work process que fez a comunicação (se seu sistema tiver poucos erros de RFC, então fica mais simples). Exemplo:
      . Transação AL11, Name of Directory Parameter = DIR_HOME
      . Para facilitar, coloque em ordem por data e hora decrescente
      . Procure um arquivo chamado dev_rfcN, onde N foi o Work Process que executou o call function remote (este é o ponto onde talvez não saiba), então procure pelo último data/hora logo após a execução do report /XNFE/UPDATE_ERP_STATUS
    d) SEM OPÇÃO - Em último caso pode-se executar diretamente a função chamada no R/3 (J_1BNFE_XML_IN_TAB) através da SE37 e acompanhar passo-a-passo com os valores que o GRC  tentou enviar sem sucesso (atenção para preencher exatamente os mesmo valores)
    Dorval,
      Poderia abrir um chamado na SAP sobre esta situação, desta forma poderemos submeter à equipe de desenvolvimento para providenciar a correção.
      Atenciosamente,
    Fernando Da Rós
    Edited by: Fernando Ros on Mar 4, 2009 9:53 PM

  • Como cancelar uma devolução de nota fiscal de saída

    Olá,
    Estou precisando saber como é feito o cancelamento de uma devolução de nota fiscal de saída. Foi enviado um material parao cliente e o cliente devolveu. O usuário inseriu no B1 essa devolução de nota fiscal de saída baseada na nota fiscal de saída, porém o usuário errou em algumas informações e agora é preciso cancelar e fazer novamente.
    Como eu posso fazer isso no B1?
    Obrigado
    Luciana Amorim.

    Prezada Luciana,
    uma vez que o documento de Devolução de Nota Fiscal foi inserido no sistema, a única forma de se efetuar o cancelamento de tal documento é através da criação de uma nova NF e posterior reconciliação dos documentos. Para maiores detalhes de como efetuar tais cancelamentos, vide as informações no documento "Canceling Documents in Release 6.5":
    SAP Portal -> Support -> Documentation Resource Center -> SAP Business One 6.5 -> How-To Guides 6.5 -> Canceling Documents in Release 6.5
    Espero que a minha explicação tenha sanado a sua dúvida. Caso esta questão esteja clara, peço a gentileza de fechar esta thread e alocar pontos ao meu usuário.
    Atenciosamente,
    Wesley

Maybe you are looking for