Testar GRC QAS em Sefaz Produtivo

Bom dia amigos,
perguntarei primeiro, e depois explico a razão:
Considerando que a sefaz valida o numero da nota fiscal para evitar duplicidade, se eu cancelar uma nota autorizada e gerar outra com o mesmo numero esta será rejeitada?
Pois o projeto de implantação de sap está prestes a subir para o ambiente produtivo. A nossa configuração do GRC e do PI (que estao em servidores diferentes) já foi transportada para seus respectivos ambientes produtivos. O serviço de verificação de status está funcionando corretamente.
Agora o cliente, para garantir, queria passar notas pelo GRC e PI de produção a partir de notas geradas no ECC QAS. Existem o flag de ambiente que pode ser alterado via debug, mas a questão que me deixou em duvida foi quanto à numeração das nota.
Estou tentando fazer um teste aqui no ambiente de homologação da sefaz, mas vai que no ambiente de produção o comportamento seja diferente.....
Abraço!

Oi
Se a NF-e já foi cancelada na SEFAZ e você tentar enviar uma nova com o mesmo número será rejeitada. Erro 218 Rejeição: NF-e já esta cancelada na base de dados da SEFAZ.
Abraço
Eduardo Chagas

Similar Messages

  • GRC 10.0 - Transport Connector Relevant Settings

    Hi Gurus,
    Many of you have already completetd GRC 10.0 implementaion. One of the Key advantage of GRC 10.0 stated as "Changes can be transported".
    While carrying out configuration settings under nodes SPRO -->GRC --> Common Component Settings --> Integration Framework and other Subsequent nodes in Access Control, we find many steps involve Connector, Connector Mappings, Actions related Settings which are connector dependent.
    Further, there are relevant sub-nodes viz. User Defaults, User data sources, HR Triggers etc., which involve connector values as part of configuration steps.
    We have created Back end test / Development related connectors and carried out the relevant configuration settings. We find that all these settings are getting collected in the transport request.
    Once we move this transport request to GRC QAS / Production landscape all the back-end Test / Development /QAS related connector settings will also move. Further this will also call for defining back-end Production systems related Connector Settings in GRC Development System itself.
    Looking forward for inputs with respect best practices for managing the GRC 10.0 config / workflow related transports across Dev / QAS / landscape.
    Regards
    Hemant

    Hi Hemant
    SAP has made a lot of the transport functionality in GRC10. I find that they hereby created a huge expectation with the customer, that in fact is not true.
    For instance Exclusion Objects and Mitigation Controls are NOT transported. What about Organizations? Critical Roles and Profiles are also not transportable.
    As for the Connectors - system specific parameters are transported. Therefore you end up having to delete the DEV and QA connectors in the PRD GRC system.
    On this question, has anyone used CLM yet? It seems that only Functions and Risks will be extracted to CLM and then deployed in the other system (DEV to QA for example). Does CLM even work?
    SAP provide not guidance on all of these important issues. I agree that it is about time that SAP takes some leadership and produce a proper best practise guide for this software. By the way, an offical sizing document from SAP is still to be delivered.
    Thanks
    Will

  • Duplicidade de NF-e

    Boa tarde pessoal,
    hoje emitimos 2 NFe's no ambiente de DEV no do cliente. As NFe's são:
    33100407005330000119550023000004150577201076
    33100407005330000119550023000004160209120157
    No SAP PI verifiquei que as duas notas foram colocadas no mesmo lote 501.
    As duas NFe's foram encaminhadas para a Sefaz e a mesma rejeitou. Segue o XML:
    Rejeicao: Duplicidade de NF-e Rejeicao: Duplicidade de NF-e Rejeicao: Duplicidade de NF-e Rejeicao: Duplicidade de NF-e </xMotivo></infProt></protNFe></protNFeStr>
      </protNFeString>
      </nfeRetRecepcaoResponse>
    Posteriormente, executei o botão "Consulta do status" no GRC e recebi o retorno:
    <ns2:cStat>562</ns2:cStat>
    <ns2:xMotivo>Rejeicao: Codigo Numerico informado na Chave de Acesso difere do Codigo Numerico da NF-e</ns2:xMotivo>
    Na transação SNUM, o intervalo de numeração se encontra com valor de 510 e o lote foi gerado com o número 501.
    Alguém já viu isso?
    A duplicidade de NFe pode estar ligada ao fato de no mesmo lote ter 2 NFe's?
    Como faço para ter

    Bom dia pessoal,
    Este código de status novo é para uma situação antiga que normalmente tinha como resultado um 204 e mesmo o Status Query não resolvia a questão.
    Onde é comum: DEV/QAS
    Motivo: É comum após refresh ou por não existir na empresa uma separação de numeração entre os ambientes chegar até a Sefaz uma mesma numeração porém com chave diferente (normalmente o aleatório). Neste caso, de fato são notas diferentes, geradas em ambientes diferentes, porém com mesma numeração.
    Motivo adicional: Mesmo que você tenha vários ambientes DEV/QAS a Sefaz tem apenas 1 ambiente de homologação, e não faz distinção sobre o seu ambiente.
    Solução: Customize sua numeração de forma a não conflitar os ambientes, ex.: DEV client xxx de 1 a 100000, DEV client yyy de 100001 a 200000, QAS clilent bbb de 200001 a 300000... E por aí vai.
    Observação: Em caso de refresh de ambiente, fazer um backup antes da numeração atual e reinserí-la antes de liberar o ambiente.
    Pode também acontecer em produção, porém é raro e normalmente denota uma falha no momento em que estava sendo criada a nota. Se acontecer a criação/transmissão ao GRC, porém por falha de update o ERP "esqueceu" da numeração aleatória então criará novamente e para o GRC/Sefaz será uma nova nota.
    Solução para este caso: Investigação no ERP sobre quais chaves, possíveis erros, investigação no GRC para saber as chaves envolvidas e na Sefaz para saber qual é a que foi autorizada. Por fim, acertar o ambiente na mão conforme o encontrado na Sefaz.
    @Bernardo, sim o decouple reduz quase a zero a possibilidade disto acontecer em produção por falhas de sistema.
    Atenciosamente, Fernando Da Rós
    @Sergio, se sua questão foi respondida ou quando for poderia fechá-la (marcar como respondida). Verifiquei que você tem várias questões abertas e isto confunde o fórum. Total Questions:  82 (47 unresolved)
    Edited by: Fernando Ros on Apr 26, 2010 8:20 PM

  • 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ó

  • Código de Status 109

    Boa Tarde,
    Estamos com a situação de um rejeição de 9 Nfe que estão retornando o código de status 109 - Serviço Paralisado sem Previsão da SEFAZ-MT.
    Como podemos alterar esse código de status, para que o nota fiscal possa ser reenviado para a Sefaz?
    Já validei o XML no site da SEFAZ e ele está OK, assim como não existem caracteres estranhos na mensagem.
    Desde já agradeço a ajuda.
    Edgar Oliveira.
    Edited by: Suporte SAP Rexam Procwork on Jul 20, 2009 7:33 PM

    Peguei uma nota para exemplo e segue o histórico do que aconteceu:
    No dia 18/07/2009 as 10:28 foi enviada pela J1BNFE para o GRC. GRC enviou para SEFAZ e retornou o Status 109.
    Fizemos o procedimento de resetar e enviar novamente várias vezes inclusive hoje mesmo. Volta sempre com o mesmo Status.
    No GRC, consultando o histórico das notas só tenho como envio e recebimento no dia 18/07/2009. Os lotes das notas foram enviados somente no dia 18/07/2009.
    O que eu acredito que está acontecendo é que o PI não está reenviando estas notas para a SEFAZ. Esta pegando o status que se encontra no GRC e atualiza no R3.
    Abaixo o link com o histórico de uma das notas:
    Histórico J1BNFE: http://img149.imageshack.us/img149/6527/nfstatus109.jpg
    Status GRC:
    http://img79.imageshack.us/img79/8497/nfstatus109grc.jpg
    http://img174.imageshack.us/img174/2851/nfstatus109grc1.jpg
    Att,
    Edgar Oliveira.

  • ECC QAS e PRD enviando para GRC PRD, PI PRD e SEFAZ HOMOLOGAÇÂO e PRODUÇÃO

    Temos somente um ambiente de GRC NFe e PI que usamos para desenvolver, realizar o teste integrado com SEFAZ Homologação e entramos em  produção.
    Precisamos que os dois cenários abaixo funcionem:
    ECC QAS  ->  GRC NFe PRD -> PI PRD -> SEFAZ Homologação
    e
    ECC PRD -> GRC NFe PRD -> PI PRD -> SEFAZ produção
    Isto é possível  ?
    O ECC QAS está configurado para homologação e o ECC PRD está configurado para produção.
    Quando criamos uma nota no ECC QAS, aparece no GRC PRD a nota com SEFAZ homologação, mas fica parada, com status 04 - somado no lote e status documento 'A' - MS Received: Request for Authorization.
    O ECC PRD está funcionando perfeitamente.
    No SPRO do GRC PRD contém o CNPJ, descrição, SEFAZ produção e Keys, não é possivel criar nesta tabela o mesmo CNPJ para os dois ambientes da SEFAZ. Será que é por isto que não funciona ?
    Muito obrigada.
    Tania Kaça.

    Bom dia Tania,
    Verifique a variante do job /xnfe/check_srv_status como parametro de execução tem o tipo de ambiente (alguém pode ter fixado o Productive), se for deixe em branco.
    Confirme na tabela /xnfe/tsrv se existem o tpamb 1 e 2 para a Sefaz que você deseja.
    Observação: Na sua configuração está 1800 segundos, significa que mesmo que o job rode de minuto em minuto, para aquela sefaz ele irá respeitar um tempo de 30 minutos. Quando você for configurar o ambiente produtivo como sugestão baixe esta valor para algo em torno de 2 minutos, e configure o job de acordo. Isto irá tornar a informação de "Sefaz fora" bem mais real para o GRC.
    Caso ainda esteja sem solução sugiro executar manualmente o programa /xnfe/check_srv_status e identificar o motivo de não executar para o ambiente homologação, sendo que está tudo "correto".
    Atenciosamente,
    Fernando Da Rós
    PS.: Por favor, verifique se suas outras mensagens (Fabrica BBKO) realmente não estão respondidas. Marcar como respondido é um feedback importante.

  • GRC 10.0 / PI 7.3 - SEFAZ PR

    Boa tarde, pessoal, tudo bem?
    Estamos configurando a SEFAZ do PR no PI, porém não estamos conseguindo nem mesmo consultar o Status de Serviço da SEFAZ PR, as outras, SP, RJ, SE, CE conseguimos normalmente.
    Fizemos um teste, pegamos o Webservice da SEFAZ SP e colocamos no cenário que criamos para a SEFAZ PR e o Status ficou verde no Monitor GRC WEB.
    Utilizamos estes Webservices para SEFAZ PR (Homologação):
    -> https://ssefa00011.fazenda.pr.gov.br:8543/nfe/NFeStatusServico2
    -> https://ssefa00011.fazenda.pr.gov.br:8543/nfe/NFeStatusServico2?wsdl
    -> https://homologacao.nfe2.fazenda.pr.gov.br/nfe/NFeStatusServico2
    -> https://homologacao.nfe2.fazenda.pr.gov.br/nfe/NFeStatusServico2?wsdl
    Alguém passou por este problema?
    Desde já, muito obrigado.
    Abs.
    Att.,
    Fábio

    Olá, Henrique.
    Então, as duas primeiras encontrei ao tentar acessar o webservice da Sefaz PR que consta neste link que vc me passou (https://homologacao.nfe2.fazenda.pr.gov.br/nfe/NFeStatusServico2?wsdl), entrei no WSDL dele e verifiquei que o Addres Location dele aponta para este endereço:
    - <wsdl:service name="NfeStatusServico2">
    - <wsdl:port binding="tns:NfeStatusServico2Soap12" name="NfeStatusServicoServicePort">
      <soap12:address location="https://ssefa00011.fazenda.pr.gov.br:8543/nfe/NFeStatusServico2" />
      </wsdl:port>
      </wsdl:service>
    Mesmo utilizando o https://homologacao.nfe2.fazenda.pr.gov.br/nfe/NFeStatusServico2?wsdl ou o https://ssefa00011.fazenda.pr.gov.br:8543/nfe/NFeStatusServico2, não consigo consultar o status de serviço da Sefaz PR.
    Se eu pegar um webservice por exemplo, de SP ou RJ ou CE.., o cenário criado para PR passa a funcionar, mas com o status de outro estado, fiz isso para testar se não havia erro na criação co cenário.
    Para os outros estados funciona, mas para PR, não consegui ainda. Alguma idéia?
    Desde já, muito obrigado.
    Abs.
    Att.,
    Fábio
    Edited by: FHCsilva on Feb 6, 2012 5:13 PM

  • NFe com status lote "Enviado às autoridades" no GRC, mas aprovada na Sefaz

    Bom dia!
    Estou com um problema no GRC. Foi lançada uma nota hoje, e a mesma encontra-se parada no GRC com o status de lote 03 - "Enviado às autoridades". Já reiniciei os jobs, verifiquei o status da sxmb_moni e não há erros, nem filas paradas nas SMQ*.
    Ao consultar a nota na Sefaz, a mesma está aprovada, mas esse status não chega ao GRC nem ao ERP, que fica com a nota enviada, aguardando retorno do GRC.
    Ainda estamos utilizando a versão 1.10 do XML, e outras notas foram lançadas antes e depois desta com problema, e todas foram aprovadas sem problema.
    Obrigada!

    Bom dia Audria,
    Foi Pedro, não Fernando nas últimas duas respostas... rsss
    Seguinte, a nota que o Pedro sugeriu corrige a causa raiz porém, como viu, o incidente já está feito.
    Para resolver este caso específico crie uma nova entrada na tabela /xnfe/bat_hist confome abaixo:
    ERTIME = maior + ,99999
    ERNAME = 'MARRETA' ou algo que seja rastreável como ação manual (rastreabilidade é super importante para futuras investigação (não estou falando de punição, ok?):
    BATSTAT = 05
    ERROR_STATUS = vazio
    Com isso o Status Query deverá estar habilitado no detalhe da NF-e.
    Atenciosamente, Fernando Da Rós
    Edited by: Fernando Ros on Feb 3, 2011 1:42 PM

  • SAP GRC NFE

    Hello,
    eu estou trabalhando no electronica fiscal de Nota. Nós temos seguintes sistemas: --
    SAP R/3 -
    SAP GRC NFE--JAVA (assinaturas digitais)-SAP NETWEAVER PI/XI -
    As AUTORIDADES (PARA A AUTORIZAÇÃO)
    como eu verificam a conexão entre estes sistemas. Como eu sei uma comunicação existe entre
    SAP GRC NFE--JAVA (assinaturas digitais)-SAP NETWEAVER PI/XI -
    A conexão das AUTORIDADES (PARA A AUTORIZAÇÃO)
    foi feita já com sucesso entre SAP R/3 E SAP GRC NFE através do RFC.
    Por favor ajuda.
    Agradecimentos adiantado,
    Honey

    Bom dia Honey,
    Além da comunicação entre os sistemas, você deve customizar as Sefaz-es e também os CNPJs na SPRO do GRC.
    Acompanhe as telas aqui:
    SAP GRC NFE 1.0 - New Solution Introduction & Implemention Best Practices
    Você pode testar o serviço assinador (java) diretamente pelo web service:
    Web Service Navigator
    Leonardo deu uma boa dica para testar o customizing dos serviços e comunicação com o sistema externo (Sefaz).
    Atenciosamente, Fernando Da Ró

  • Ativar SCAN com solução de mensageria não GRC

    Pessoal bom dia,
    Estou em um projeto e o cliente deseja utilizar a contingência da NF-e com o SCAN, porém a mensageria é uma solução de mercado, não é o GRC. Vocês sabem o que fazer para ativar o SCAN quando a mensageria não é o GRC. A comunicação entre o SAP e a solução de mensageria ocorre, no envio, por arquivos texto. Somente o retorno para o SAP ocorre por RFC.
    Qualquer dica será bem vinda, desde já agradeço!
    Assis Medeiros

    Olá a todos!
    Nossa instalação tenta combinar o SAP ERP com a mensageria não ERP. Na verdade nem sempre combinam bem, mas dá samba. Para funcionar o SCAN, conforme a dica do Fernando, aplicamos a seguinte solução:
    Ao assinalar o campo u201CDeterm.aut.servd.u201D no Local de Negócio (customizing), o SAP automaticamente consultará se é SEFAZ ou SCAN que está ativo, através do método GET_SERVER da implementação da BAdI CL_NFE_PRINT
    Neste método, a tabela CT_SERVER_CHECK contem os campos SEFAZ_ACTIVE e SCAN_ACTIVE. Apenas um destes campos de ser assinalado com X. Para cada campo o SAP definirá o formulário a ser utilizado ao fazer a numeração da Nfe, se para SEFAZ ou SCAN, conforme customizing.
    Dentro do método GET_SERVER pode-se consultar uma tabela Z que indica quem está ativo, se SCAN ou SEFAZ, assinalando o campo correspondente da tabela CT_SERVER_CHECK.
    Uma alternativa automática para saber qual serviço está ativo é consumir via PI o WS do Sefaz que indica o serviço que está ativo.
    Valeu Fernando.
    Espero ajudar quem está passando por aqui.
    Abçs
    Heron Caetano
    www.hcaetano.blogspot.com

  • Duas empresas emitindo NF-e para mesma UF e único GRC/PI, é possível?

    Pessoal, bom dia!
    Num projeto de NF-e é possível duas empresas emitirem NF-e para a mesma UF, utilizando o mesmo GRC/PI (únicos)?
    Pergunto isso, pois não existe uma forma de diferenciar no PI os multiplos Receiver Determination nos cenários para determinar quando é uma empresa ou outra e enviar para o Canal de Comunicação correto, pois se temos duas empresas emitindo NF-e, por exemplo, para o estado de SP, devemos ter dois canais de comunicação pra SP, pois cada um deve conter a View/Entry da assinatura digital de cada empresa.
    Existe alguma forma desse cenário com duas empresas (no SAP) e um único GRC/PI funcionar?
    No aguardo, obrigado.
    Danilo

    Danilo,
    no processo de NFe, o certificado digital é utilizado em 2 momentos:
    1. assinatura digital: os dados do keystore entry/view sao inputados na customizing de empresa (CNPJ) na SPRO do SAP NFE;
    2. SSL: os dados do keystore entry/view sao inputados nos communication channels das SEFAZs.
    Para #1, vc precisa ter um certificado por "raiz de cnpj", ou seja, filiais de uma mesma empresa podem usar o mesmo mas empresas diferentes (8 1os digitos do CNPJ diferentes) precisam de certificados distintos. Isso vc parametriza normalmente, p/ cada CNPJ habilitado no GRC, através da view da SPRO comentada acima.
    Para #2, a SEFAZ permite que uma empresa seja "carrier" das mensgens de outras empresas, independente do CNPJ. Isso é o que ocorre por exemplo nos casos de hosting, onde uma empresa única fornece o serviço de transmissao de NFe. Assim, não há impeditivo (nem legal nem técnico) de ter um único communication channel que atenda várias empresas. Simplesmente escolha 1 dos certificados, nao importa qual, e o configure nos communication channels.
    Abs,
    Henrique.

  • Inutilização de Nota com erro de validação no GRC

    Bom dia,
    Estou com um problema na inutilização de notas com erro de validação no GRC!
    Quando a nota é rejeitada pela GRC, fica da seguinte maneira:
    Etata obrigatória do processo : 8 (Erro validação interna sistema de mensagem.Envie novamente!)
    status de comunicação do sistema : 0 (Enviada ao sistema de menssagem (XI,...))
    status do sistema de mensagens : V (Mensagem Recebida: Erro de Validação Interna)
    Sem utilizar o botão Reset NFe, clico no botão Request Cancelation e realizo os procedimento de cancelamento.
    Verifico pela tabela /XNFE/NFE_HIST que gerou um registro com a chave de acesso, type 3 (Inutilização) e status 6 (Enviado ao Processamento da Nota Fiscal Eletrônica).
    Consulto no SEFAZ e verifico que essa nota já esta inutilizada porém na J1BNFE a nota continua processando.
    Alguem sabe como resolver este problema?
    Obrigado,
    Leandro Von Zubem.

    Bom dia.
    Tenho uma NF-e que está em situação parecida e agradeço suas colaborações.
    Estamos na ECC 5.0 SP 19.
    Esta NF-e foi rejeitada pela SEFAZ (NF-e writer e o erro estava no ano da data de emissão = 2008)
    e o usuário não percebendo tentou re-enviar várias vezes.
    Por fim, mesmo Rejeitada foi solicitado o Estorno (Skip) e os status da NF-e ficaram como abaixo:
       SAP ECC 5.0 SP19
          Status Ação :          Em processamento
          Status do documento NF-e:     2 Rejeitado
          Status de comunicação do sistema: 3 Rejeitado/a & autorização solicitada para ignorar
          Status do sistema de mensagens:     C Mensagem recebida: pedido de inutilização
          NF-e Código de Status :     228
       Log
              Novo stat.comun.sistema "Rejeitar estorno/ignorar usuário aceitos" não permitido p/status
                         comun.sist.anterior "Rejeitado/a & autorização solicitada para ignorar
              Nº mensagem J1B_NFE007
       GRC
          Status Code:               228     Rejeição: Data de Emissão muito atrasada
    Seguindo as orientações já mencionadas aplicamos em Desenv as Notas 1376901, 1376324 e 1298283 e
    simulamos a situação. Mas a NF-e também permanece "em processamento".
    A Nota 1141636 não foi possível aplicar porque exige para Basis o SP 700 e estamos no SP 640.
    Esta atualização seria muito mais demorada.
    Pergunto: existe alguma forma de ajustarmos os status para finalizar esta NF-e? (Rejeitar ou Aprovar/Rejeitar).
    Agradeço a toda colaboração.
    Abraços a todos e ótimas festas.
    Luis Appel

  • ATUALIZAÇÃO DE STATUS NF-E EMITIDA E ENVIADA A LEGADO P/ COMUNICAÇÃO SEFAZ

    Senhores (as);
       Estou desenvolvendo uma NF-e que será gerada no SAP (J1B1N), depois será enviada a um sistema legado que fará o envio a SEFAZ. Para tal, na J_1B_NFE_XML_OUT, coloquei uma codificação que gera um arquivo .xml e salva num diretório, onde o legado busca este arquivo e envia a Sefaz e trata as contigências, cancelamentos, imprime o DANFE, etc. coloquei também uma chamada a essa RFC no form Call_Xi. Ocorre que no monitor J1BNFE, quando seleciono a nota e clico em enviar aparece a mensagem:
    "Mensagem incompleta (Falta nível de gravidade, área, número ou exceção)"
        E quando eu tento carregar o retorno na J_1B_NFE_XML_IN e forçar nela status de enviado, retorna "Não permite status seguinte 'Não Enviado' para doc. 'Autorizada'".
        Gostaria de saber se alguém sabe como atualizar os status do Monitor (J1BNFE) neste caso;  e se tem como, somente alimentando a J_1B_NFE_XML_IN, atualizar os status ? Gostaria de que quando enviar no Monitor o status ficasse em 'enviado', 'Autorizado', etc, de acordo com a fase do processo, pois o legado consegue carregar a J_1B_NFE_XML_IN com o retorno da SEFAZ....
    Desde já agradeço....

    Exmo Sr:. Da Rós;
       Segue abaixo respostas:
    Bom dia José Aguilar,
    porém o meu problema com a atualização dos status persiste
    Pergunta: Agora quando a NF-e é emitida e transferida para o sistema mensagerio você obtem um SCSSTAT = 0 na J1BNFE?
    Resposta: Não. Esta é exatamente a causa de todas as minhas perguntas neste fórum.
    ...temos para auxiliar os amigos do fórum no entendimento correto da questão, pois se trata de cenário único (envolve 3 sistemas) e com particularidades específicas, como servidor Unix, cliente Retail, sem PI nem GRC, etc.
    Para o ERP este passo de saída não faz tanta distinção ser o GRC ou não, ele irá chamar a /XNFE/NFE_CREATE para o GRC ou a J_1BNFE_XML_OUT para mensageria de terceiros.
    Próximos passos:
    - Qual o resultado do debug? O que descobriu?
    Resposta: No Debug descobri a solução para o meu problema antigo, as mensagens do log; porém não conseguí ainda achar exatamente  o ponto onde acontece o flag do campo SCSSTAT, o mesmo passa por diversas estruturas, variáveis e ti's, tentei forçar o valor no campo porém quando passa por outras consistências e funções volta a zerar o conteúdo. Agora estou debugando o grupo de funções j_1b_nfe e a j1b1, pois a verdade é que preciso flegar este campo no momento da criação da nf-e, pois os usuários terão acesso ao j1bnfe só para verificar status, pois o volume de notas é muito grande e devem já ser criadas com a determinação do número e o envio para o programa que repassará o arquivo ao Synchro.
    - Os status mudaram?
    Resposta: Não.
    Atenciosamente, Fernando Da Rós
    Agradeço pela compreensão, disposição, educação e grande paciência com que o senhor vem reportando meus questionamentos.
    Grato.
    José Aguilar.

  • Processo NFE - Biztalk GRC

    Bom dia a todos, estamos implementando NFE e gostaria de saber se alguem ja passou por algo parecido.
    Iremos partir de um software em VB que ira enviar para o GRC via biztalk...alguem ja passou por essa situação? Gostaria de saber como o BIztalk irá startar, se possivel também, as RFC.
    Obrigado,

    Henrique,
    Voce teria alguma documentação ou link referente a interface SOAP to RFC.
    Como eu disse anteriormente, temos o seguinte cenario
    Biztalk -> SAP GRC/PI -> Sefaz..
    Preciso entender melhor a configuração necessária para a realização desse processo.
    Obrigado mais uma vez.
    Vinicius

  • NFe Fiscal Workplace - Não atualiza com Status Sefaz

    Boa noite!
    Estou tentando reexecutar a consulta de status de NFe através do fiscal workplace para algumas NFes que ficaram com Status Global 11 devido a um problema temporário que tivemos com SSL (certificado estava sendo rejeitado pela SEFAZ) . Para tal, quando seleciono uma NFe clico em "Outras Funções > Consultar Eventos" o cenário de processo de integração "NFESC_WebAS_Outbound_NFeStatusCheck"  é executado com sucesso e posso ver a interface NFESC_nfeConsultaNFResponse_IB retornando ao SAP GRC com sucesso, porém no monitor fiscal workplace a nota continua com Status Global = 11.
    Um detalhe importante é que isso só está ocorrendo para estas notas que estamos tentando consultar o status através do monitor "Outras Funções > Consultar Eventos", pois após a SEFAZ passar a aceitar nosso certificado, para o processo automático (resumindo entrada de nota e depois conferência de status)  está tudo correndo bem. Parece ser algo relacionado com a execução de consulta de status via monitor!
    Por favor, se alguém puder dar um auxílio será de grande ajuda!
    Desde já agradeço.,

    Bom dia Glauco,
    Não estou lembrado do caso exato, mas sim você tem razão que diferente do SAP NFE 1.0, no SAP NFE 10.0 tem vários "chamadores" da consulta de status na Sefaz, e de acordo com o processo que solicitou esta consulta tem ações diferentes a analisar.
    Em que versão você está? Já usando 3.10?
    Atenciosamente, Fernando Da Rós

Maybe you are looking for