NFe com SEFAZ-AM: Código de retorno 200. O que seria isto?

Pessoal,
Estávamos realizando um teste com um cenário de devolução de compra de material de uso e consumo com a nossa filial do Amazonas e obtivemos o retorno no XML com o código de retorno 200.
Alguém já viveu esta experiência antes? Se sim, o que significa o código de retorno 200?
Abraço,
Daniel.
Edited by: Daniel Carvalho on Jun 29, 2010 10:54 AM

daniel, eu tenho uma solucao que derrepente pode ajuda-lo, mas preciso saber uma coisa, essa nfe chegou a ser enviada ao sefaz, ja consultou ela no proprio sefaz para ver se ela nao foi criada?
existe um "workaround" ( como o Henrique costuma falar ) que vc acaba conseguindo reenviar esse lote, mas vc terá que fazer duas alteracoes em dados da tabela.
1)Entre na tabela BATSTA e no campo BATCHID informe o numero do lote problemático e em seguida edite e altere o valor do campo PROCESS para u2018Xu2019 ( em processamento)
2)Em seguida entre na tabela /XNFE/BAT_HIST com o mesmo BATCHID e apague o valor da ultima linha de processamento que esta com o campo ERROR STATUS preenxido ( LIMPE O CAMPO ERROR STATUS)
3)Após essas alteraçoes dos dados execute o programa /XNFE/BATCH_REQUEST..
Nao é garantido que funcione, o passo 2 algumas pessoas preferem criar uma nova linha para que seja mantido o historico
Edited by: Carlos Rodrigo Pereira on Jun 29, 2010 8:19 PM

Similar Messages

Erro 225 - Falha no Schema XML do lote de NFe com mensagem formato invalid

Pessoal, boa noite.
Estou me deparando com um problema de validação de NFe no Sefaz GO, onde está retornando o erro 225, mas quando verifico o retorno tenho a mensagem de que o formato não é valido (abaixo print) . Verificando o dado, não tem nenhuma divergencia entre os demais valores. Alguém ja se deparou com este erro?
<?xml version="1.0" encoding="utf-8" ?>
- <ns1:nfeRetRecepcaoResponse2 xmlns:ns1="http://sap.com/xi/NFE/006">
- <ns1:nfeRetRecepcao2Result>
- <ns2:retConsReciNFe xmlns:ns2="http://www.portalfiscal.inf.br/nfe" versao="2.00">
<ns2:tpAmb>2</ns2:tpAmb>
<ns2:verAplic>GO2.0</ns2:verAplic>
<ns2:nRec>521000004377506</ns2:nRec>
<ns2:cStat>225</ns2:cStat>
<ns2:xMotivo>Rejeição: Falha no Schema XML do lote de NFe</ns2:xMotivo>
<ns2:cUF>52</ns2:cUF>
<ns2:cMsg>225</ns2:cMsg>
<ns2:xMsg>cvc-pattern-valid: Value '5499.00' is not facet-valid with respect to
pattern '0|0.[0-9]{2}|[1-9]{1}[0-9]{0,12}(.[0-9]{2})?' for
type 'TDec_1302'.</ns2:xMsg>
</ns2:retConsReciNFe>
</ns1:nfeRetRecepcao2Result>
</ns1:nfeRetRecepcaoResponse2>
Edited by: Fernando Ros on Apr 22, 2011 8:03 AM adicionando tag code para visualizar todos os caracteres

Bom dia Carlos,
Em sendo a Sefaz GO a inconstância não me surpreende, mas a de se estar atualizado, principalmente com o removedor de caracteres e validador ativo para evitar a chance do programa da Sefaz se confundir que é o que parece estar acontecendo... Está apontando o problema num lugar onde a mensagem apresentada está ok.
Sugiro atualizar o sistema ao SP18 que é o necessário para trabalhar de forma saudável com layout 2.0
Atenciosamente, Fernando Da Rö

Problemas de Comunicação com SEFAZ PE - Urgente

Boa tarde!
Pessoal,
Ontem a SEFAZ de PE ficou fora o dia inteiro.
Hoje ao acessar o Portal, vimos que a SEFAZ PE está on.
Mas no GRC, quando vou verificar o status de serviço da SEFAZ PE código 26, está inoperante.
Alguém está passando por isso?
Estou em ambiente de Produção com cerca de 100 notas paradas, pois não consigo enviá-las a SEFAZ, por causa do status 70 da SEFAZ PE 26.
Pensamos entrar em contingência até resolver o problema, mas colocá-las em contingência manualmente é muita coisa para cancelar e fazer cópia da NFe comutada.
Aguardo comentários, ajuda....
OBrigada.
Adriana

A SEFAZ/PE está muito intermitente, e além de tudo, ela simplesmente não desliga o serviço de recepção dos arquivos enviados, travando nossos serviços de mensageria.
O que fizemos como uma solução paleativa, foi alterar o webservice de recepção, forçando para que não ocorra a comunicação automática, convertendo as NFEs para Contingência DPEC junto à SEFAZ Nacional (RFBrasil).
Webservice de recepção original: "https://nfe.sefaz.pe.gov.br/nfe-service/services/NfeRecepcao?WSDL"
Webservice de recepção alteramos: "CHANGE:https://nfe.sefaz.pe.gov.br/nfe-service/services/NfeRecepcao?WSDL"
No dia seguinte no primeiro horário da manhã, ajustamos novamente o "webservice" de recepção para o formato correto, e então reenviamos as NFEs aprovadas via DPEC para que sejam protocoladas junto à SEFZ PE.
Pelo menos até o dia 22/09, data prevista em que SEFAZ PE está prometendo manter esse serviço intermitente, estaremos trabalhando dessa forma.
Nossos caminhões não tem sofrido nenhum tipo de problemas em barreiras fiscais estaduais e federais trafegando com DANFEs protocolados junto à SEFAZ Nacional através da Contingência DPEC.
Espero ter colaborado de alguma forma.
Obrigado,
Eduardo Pini

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

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

Campo cNF do XML v.200 da NFe com 9 dígitos

Olá!
Estamos testando a NFe na versão 2.00 do XML.
Encontramos inconsistência no campo cNF do XML gerado pelo SAP.
Segundo o Manual do Contribuinte 4.01, o campo cNF deve ter o tamanho de 8 dígitos.
Nosso ambiente de testes está com o SP18 atualizado e o local de negócio atualizado para gerar o lay-out do XNL da NFe no na versão 2.00. Neste ambiente, o SAP está gerando o campo CNF no XML com o tamanho de 9 dígitos, sendo invalidado pelo SEFAZ.
O XML na RFC do SAP do cabeçalho da NFe, gera o campo
Somente para a versão 1.10 do XML da NFe que o campo cNF tem 9 dígitos, sendo que o primeiro refere-se ao tipo de emissão. Entretanto, para a versão 2.0 do XML, segundo o manual do contribuinte 4.01, dever ter 8 dígitos.
Não temos o GRC. Nosso serviço de mensageria é da Alliance.
Aplicamos as Notas SAP abaixo, porem sem sucesso:
Note 1519167 - Nf-e: Issuing type filled for XML-version < 2.00
Note 1520408 - Nf-e: Issuing type filled for XML-version < 2.00 and RFC = 3
Alguem já passou ou está passando por isso? Como está resolvendo?
Obrigado.
Abrçs
Heron Caetano

Ola, respondendo a sua pergunta.
O formato com 9 digitos para a troca de dados entre o ECC e o GRC aparentemente foi mantida para compatibilidade das versões, porem, a validacao dos dados do NFEid por exemplo e os demais processos, para o formato 006 ( XML 2.0 ) leva em conto o novo formato de 8 digitos como demonstrado abaixo.
IF lv_id(2)     NE is_nfe_header-cuf       "Region
OR lv_id+02(02) NE is_nfe_header-demi+2(2) "Year
OR lv_id+04(02) NE is_nfe_header-demi+4(2) "Month
OR lv_id+06(14) NE is_nfe_header-c_cnpj    "CNPJ of issuer
OR lv_id+20(02) NE is_nfe_header-mod       "model
OR lv_id+22(03) NE lv_serie                "serie
OR lv_id+25(09) NE is_nfe_header-nnf       "NFe number
OR ( lv_id+34(01) NE is_nfe_header-tpemis    "Issuing type
       AND is_nfe_header-version NE gc_xmlvers1_erp ) "only for newer version then 1.10 (005a)
OR lv_id+35(08) NE is_nfe_header-cnf+1     "random number (except first digit fixed zero)
OR lv_id+43(01) NE is_nfe_header-cdv.      "control digit
De uma verificada no seu ambiente do GRC, ele está com o SP15 instalado com todas as notas aplicadas ? inclusive no seu ECC, todas as notas referentes ao XML 2.0 foram realizadas com sucesso?

Usando GRC NFe com Outro Middleware (TIBCO)

Pessoal,
Estamos instalando o GRC NFe em uma empresa e por questões de segurança o PI não pode "sair" para internet.
Assim, ao invés de me comunicar com o SEFAZ, estou comunicando com o TIBCO (este é o nome do software).
Acordamos que o TIBCO teria que simular o SEFAZ para eu não alterar a solução standard e assim os caras tiveram que desenvolver interfaces identicas as da SEFAZ.
SOmente duas coisas ficaram diferentes:
1 - Para chamar os webservices do TIBCO eu não preciso usar o certificado digital instalado no PI
2 - Os Webservices que chamo não são os da SEFAZ, mas sim os do TIBCO, porém o SOAP Action é identico.
Concluímos todo o processo de configuração e agora iniciei os testes, porém já na primeira tentativa de envio de nota encontramos um problema
O Status de Serviço já está se comunicando com a SEFAZ perfeitamente e já está retornando a informação correta até o GRC.
O problema é que quando o lote com a nota vai ser enviado na chamada call adapter da interface BATSR_nfeRetRecepcaoSoapIn_SYNC_IB , portanto, BATSR_SOAP_RCV ele dá o seguinte erro:
SAP_Code area="INTERNAL"_AE_DETAILS_GET_ERROR
Error while reading from the secure store: ERROR_U: No service user password found for Adapter Engine
Error while reading access data (URL, user, password) for the Adapter Engine
Porém no TIBCO não é necessário usuário e senha para se conectar, portanto, deixei em branco. Repetindo, o Status Service está funcionando normalmente assim.
De antemão obrigado pela ajuda

Sim sim, o erro nao tem nada a ver com o fato de ser TIBCO, é algum erro de post-installation/configuração no Adapter Engine.
Verifique no SLD, technical systems process integration (ou exchange infrastructure, depende da versão) se vc vê a entrada do tipo Adapter Engine, e se ela está com os dados consistentes.
Verifique tb se o FM SAI_AE_DETAILS_GET finaliza com sucesso, e revise se o Exchange Profile foi mantido com os dados, em particular do Adapter Engine. Verifique se a SLDCHECk tb termina com sucesso.
Outra coisa, atualize o CR Content e o CIM Model do seu SLD para o ultimo disponível (6.x) de acordo com a nota 669669
Abs,
Henrique.

Skip NFE com erro de validação

Oi tudo,
Tenho uma pergunta sobre a funcionalidade de saltar uma NF-e com erro de validação.
Eu apliquei notas SAP
1298283 - NF-e: Passar para a NF-e com erro de validação
1376324 - NF-e: Passar para a NF-e com erro de validação
1376901 - Passar para o erro de validação
Mas ainda assim o processo não funciona completamente.
Em nota 1298283 do texto;
Os novos valores definidos no J_1BNFE_MESSAGE_TYPE domínio deve ser usado
do sistema de mensagens ao chamar as funções interface de entrada
u2022 J_1B_NFE_XML_IN ou
u2022 J_1B_NFE_XML_IN_TAB
de ERP para corrigir o ajuste siga em stati do processo de
NF-es com erros de validação, dependendo da resposta da SEFAZ.
NF-e autorizada para o cancelamento são cancelados e da etapa do processo é
definido como C (completo).
Eu tenho definido os novos tipos de mensagens de acordo com as instruções de nota, mas como estes podem ser implementados e ser utilizado em GRC - sistema de NFe?
O tipo de mensagem autorizado para pular com o erro de validação em GRC agora é '5 ', mas deve ter o valor "8" de acordo com notas acima.
Incluir / XNFE / DB_CONSTANTS em GRC não contém os novos tipos de mensagens
    8 Autorização para Passar uma NF-e com erro de validação
    9 Rejeição Passar para uma NF-e com erro de validação
Alguém sabe como o resolver isso?
BR
Honey

Olá Fernando,
Obrigado pela sua resposta!
Temos também notas 1296515 e 1252567 instalado.
O teste que eu fiz antes de começar a depurar é que eu deliberadamente criada uma NF-e com um valor em falta, de modo que a resposta do GRC seria erro de validação. O exigido quando eu pressionar "Definir Número de NF-e" processo passo status muda para "8" = erro de validação interna do sistema de mensagens. Enviar novamente!
Agora eu enviar um pedido de pular para esta NF-e e as alterações do estado de acção para "Em processamento".
Em GRC Ignorando o pedido for aprovado, mas o processo nunca é completado em R / 3. No log eu posso ver J1B_NFE007 mensagem de erro;
Nova SCS-status "Rejeitado & Skipping (Cancelar) Autorizado" não é permitida para SCS anterior "Erro de validação e Skipping solicitadas".
Quando a depuração vejo que isso acontece em função J_1B_NFE_CHECK_NEXT_SCSSTATUS módulo na declaração
WHEN c_authorized_for_skip.                                                                  "1152140
      IF is_acttab-scssta NA '3'.                                                                  "1152140
        PERFORM get_domain_text USING c_scssta                                   "1152140
                                      i_newscsstat                                                      "1152140
                                      c_scssta                                                             "1152140
                                      is_acttab-scssta                                                 "1152140
                                CHANGING gv_msgtxt1                                            "1152140
                                         gv_msgtxt2.                                                     "1152140
                                                                                "1152140
        MESSAGE e007 WITH gv_msgtxt1        "i_newscsstat                    "1152140
                          gv_msgtxt2        "is_acttab-scssta                                 "1152140
                          RAISING scs_status_not_allowed.                                "1152140
      ENDIF.                                                                                "1152140
Neste ponto, o valor em is_acttab-scssta igual '9 '.
Lamento, mas eu não entendo o significado de "V" na descrição:
(NF-novo e rejeição RESET + + V + + V + SEND Skip Request)
Eu testei:
1. Novo NF-e
2. Definir NF-e número & enviar às autoridades
3. Rejeição devido a erro de validação
4. Enviar pedido de cancelamento de NF-e
Existe algum outro procedimento que eu devo testar?
Se eu tentar redefinir a NF-e após receber a primeira rejeição devido a um erro de validação, R / 3, não me permitem enviar pedido de cancelamento.
Eu penso que este comportamento é muito estranho, já que temos seguido as recomendações na execução notas SAP.
Você recomendaria o próximo passo é registrar um bilhete em relação a este?
obrigada &
atenciosamente!

ERRO DE COMUNICAÇÃO COM SEFAZ

Bom dia!
Ao tentarmos enviar uma verificação de status à SEFAZ, ocorre o seguinte erro em PI:
<SAP:Code area="ABAP">INTERFACE_REGISTRATION_ERROR</SAP:Code>
<SAP:Stack>No implementing class registered for the interface (ABAP interface, request message SRVSC_nfeStatusServicoNF_SYNC_OB, request message, namespace http://sap.com/xi/NFE/005a)</SAP:Stack>
Entendemos que seja um problema com a instalação, pois não tivemos erro nos ambientes de D (desenvolvimento) nem no Q (testes).
Verificamos a configuração de integração e o servidor de aplicação no sxmb_adm.
As proxies parecem estar registradas.
Nunca funcionou no ambiente de Produção.
Alguém pode ajudar?
Obrigada,
Fabiana

Fabiana,
A partir de hoje eu e outros usuários estamos recebendo um erro justamente nesse WS:
SRVSC_nfeStatusServicoNF_SYNC_OB
estava funcionando normalmente até sexta-feira, no meu caso no ambiente de homologação, estamos suspeitando que seja algo referente a certificado.
Abs,
Marco

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

PI NFE com erro 92 / stack java caindo

Amigos,
A 2 meses estamos passando por um problema com o ambiente GRC PI NFE,
A 1 mes atru00E1s o Stack Java estava caido e apu00F3s tentar subir via SMICM e SAPMMC, constatei que o server0 demorava mais de 50 minutos para reportar o erro e abortar o start.
Atualizei o Java JRE para a versu00E3o j2sdk1.4.2_27-x64 sem sucesso.
Ao acessar o diretu00F3rio D:\usr\sap\SID\DVEBMGS00\j2ee\cluster\sever0 constatei uma grande lentidu00E3o pois havia uma grande quantidade de pequenos arquivos.
Via ferramente JAVA Configtool, criei um novo server (SAP NOTE 723909) , chamado server1 e o stack java subiu em 5 minutos.
Ontem, o cliente reclamou de falha de envio de email aos clientes, e ERRO 92 no monitor PI.
Foi verificado o mail gateway e estava tudo ok, entu00E3o solicitou um reboot no servidor PI/NFE
Antes de efetuar o reboot verifiquei que o server1 estava LOTADO de arquivos XML novamente, entu00E3o movi esses arquivos para uma area de backup, resetei o server e subi novamente.
Aparentemente esta tudo ok desde entu00E3o, poru00E9m sabemos que u00E9 um problema cronico que mais cedo ou mais tarde teremos novamente.
Pergunto: ERRO 92 tem haver com o numero de arquivos XML que estavam no diretorio do server0 e server1?
O ambiente u00E9:
Windows 2003 x64
Oracle 10.2

Olá Fernando,
os arquivos XML são todos padronizados assim:
newPayload_2010-10-11 19.24.47.406.xml
E são as NFE sim.
Verifiquei hoje, a transação sxmb_moni -> Estatisticas de Processamento
Aparece o seguinte resultado:
Processing Statistics:
XML Messages with error = 109
- Manually canceled = 64
Unprocessed XML messages = 23.633
Correctly Processed XML Messages 375 992
Archives XML Messages = 0
XML Messages Flagged for Deletion = 0
Deleted XML Messages = 288067
Pergunta: Poderiam ser esses Unprocessed XML messages estão ligados aos emails que não foram enviados?
Obrigado pela atenção!
Maycon Leite
Campinas - SP

NFE com status "em processamento" que não foi enviada ao PI para assinatura

Olá pessoal.
No dia 08/03 tivemos um problema no servidor do PI e GRC (ambiente de produção) devido a uma diferença entre os horários do Application Server e do Database Server.
A grande maioria das NF-eu2019s geradas durante o problema, tiveram o fluxo normal retomado depois da correção no dia 09/03, porém existem três NF-eu2019s que ficaram u201Ctravadasu201D, pois não saíram do GRC para serem assinadas.
As filas do PI e do GRC tiveram que ser reativadas para que o fluxo das NFE's com problema fosse retomado. Não há nenhum registro parado nas filas do GRC e nem do PI.
Percebemos que o envio para assinatura dá-se no momento da criação da NF-e no GRC. Tentamos re-enviar as NF-e's pelo monitor do ECC, mas não surtiu nenhum efeito.
Existe dentro do GRC alguma forma de reenviar para assinatura estas NF-e's?
Obrigado,
Dorval Neto.

Bom dia Pessoal,
Só para chamar a atenção das modificações em tabelas do GRC NFe, isto somente deverá ser feito após esgotadas todas as opções possíveis ( PI, filas, RFC, tunning, basis, java, monitores do aplicativo e também aplicação de notas ).
No suporte, tenho encontrado em produção problemas que foram ignorados em tempo de DEV / QAS onde o acesso é facilidado.
Em produção além do acesso limitado o alto volume de notas juntamente com a pressão dos usuários pela resolução rápida pode desgastar a imagem da implementação e do consultor.
Felizmente temos este canal, e também o suporte oficial, para apoio à esta identificação.
Abraços,
Fernando Da Ró

NFe com erro de assinatura - caracteres especiais

Bom dia,
Algumas notas estão paradas com erro de assinatura por caracteres especiais nas descrições dos materiais.
Fizemos a correção dos mesmos porém o GRC não recebe a atualização feita.
A função J_1B_NFE_MS_REQUESTS_DATA também foi executada e mesmo assim não houve atualização.
Há alguma outra função que pode ser executada para que o GRC receba a atualização do SAP?
Att.,

Herique,
Os ambientes estão nas versões:
- SAP ECC 6.00
- SAP PI 7.0 SP22
- SLL-NFe SP16
A NFe não foi emitida pelo SCAN, ou seja, tpEmis=1.
Depois que restarta, ele reenvia a NFe para assinatura novamente, como tem que fazer, mas retorna com erro de assinatura novamente, sem as alterações efetuadas nas descrições dos materiais, removendo os caracteres especiais.
Obrigado.
Abs.

Interceptar resposta de cancelamento de NFe do sefaz

Boa tarde,
Estou trabalhando em um desenvolvimento ABAP onde no momemento da geração da DANFE são gerados e enviados (via e-mail) certificados de qualidade para o cliente. Porém um problema constatado acontece no momento do cancelamento da NF: existe algum meio de "interceptar" a resposta do sefaz a um cancelamento e automaticamente rodar uma rotina Z que cancelasse também os certificados de qualidade relativos a NF enviando um aviso ao cliente?
Procurei por exits e afins nas interfaces CFB2B_enhProcCancNFe_IB mas não obtive sucesso.
Agradeço desde já qualquer ajuda neste problema,
Fabio Gross

Se nao me engano, a J_1B_NFE_XML_IN_TAB vai chamar a BAdI CL_NFE_PRINT método CALL_RSNAST00 (ou algo assim) tb para retornos de cancelamento.
Vc poderia utilizar essa badi como workaround para chamar esse seu Z, quando fosse um docnum de cancelamento.
Talvez haja sugestao melhor, porém.
Abs,
Henrique.

NFe com dados de fornecedor incompletos após atualização do mesmo

Bom dia!
Estou tendo o seguinte problema. É enviada uma NF ao GRC, porém não consta no cadastro do Fornecedor o campo Bairro.
Ao alterar o cadastro do fornecedor (via FK02) incluindo o bairro, esta informação não é replicada à NFe, e o erro no GRC continua após o reenvio desta NF pela J1BNFE.
Alguém já passou por algo parecido? Qual foi o procedimento seguido?
Grata!
Audria

Bom dia Audria,
A opção Reenviar só deveria funcionar caso a nota ainda não estivesse no GRC (casos de falha de entrega por erro de comunicação).
O normal seria NF-e -> Reset NF-e Status (CtrlF5) e depois NF-e -> Enviar (CtrlF3).
Verifique pela data/hora e pelo histórico se você está vendo a mesma informação ou é uma informação antiga.
Sobre a causa raiz deste seu problema, talvez estejam faltando notas, ou talvez o cenário seja este mesmo.
Sei que por um problema de histórico no R3 sobre o que está na fazenda, os dados mestres do contribuinte passaram a ser copiados para a tabela J_1BNFDOC no momento da criação, então deve ser o que está gerando este comportamento, só não sei se existe alguma opção para reler as informações do dado mestre e atualizar a J_1BNFDOC em algum momento do processo.... Talvez não... daí é cancelar e fazer outro faturamento.
Atenciosamente, Fernando Da Rós
Complementando... O motivo desta cópia para a J_1BNFDOC é ter nos relatórios SPED a real informação da época da geração da NF-e e não o dado atual do contribuinte.
Edited by: Fernando Ros on May 11, 2010 6:02 PM

NFe com SEFAZ-AM: Código de retorno 200. O que seria isto?

Similar Messages

Maybe you are looking for