Inutilização de NFE nao atualiza status no R/3

Amigos aconteceu uma coisa muito estranha,
Ao solicitar a inutilizacao de uma NFE, o SEFAZ retornou ok codigo 102
Entao no GRC ficou autorizado com status 102
No R/3 o cancelamente foi feito normalmente todos os documentos foram estornados
porem a tabela J_1BNFE_ACTIVE nao foi atualizada com o status 102
e a nota fica com status 'Aguardando resposta'
Vi aqui no forum que algumas pessoas ja tiveram este problema
alguem sabe a solucao ?
Obs: estamos no SP61 a nota 1357713 esta aplicada
Este foi um caso isolado so aconteceu 1 porem preciso atualizar o status deste nota para que ela apareca no livro fiscal
SAP 4.6C
Obrigado

provavelmente aconteceu algum erro na montagem do campo chave de acesso na hora que o ERP mandou pro GRC.
Isso causou o erro na SEFAZ, rejeicao.
Na hora que o GRC tentou devolver pro ERP, como a chave de acesso estava errada, o ERP nao reconheceu aquele documento, e portanto nao atualizou nada (a entrada deve estar na /xnfe/backstatus).
Nao vejo muita alternativa a nao ser resetar o status da nota no ERP e tentar reenviar, dessa vez debugando para ver pq está montando a chave de acesso errada. Isso porque a chave de acesso errada já virou campo chave do documento no GRC.
Na verdade, se vc conseguir reenviar com a chave de acesso correta, ele vai criar outra entrada no GRC, que agora deve processar corretamente. Aquela que ficou com 216 vai ficar "perdida".
Verifique se a chave de acesso dessa nota que ficou com 216 tem algum espaco em branco ou campos com 00.
Abs,
Henrique.

Similar Messages

Inutilização de NFe - J_1BNFE_OUTNFE_CREATE - Mensageria não-sap

Olá pessoal!
Preciso esclarecer uma dúvida:
A SAP disponibilizou a função J_1BNFE_OUTNFE_CREATE para fazer interface com sistemas de mensageria não-sap, para o layout 3.10.
Dúvida:
Nessa função, como eu faço para identificar que a ação do usuário foi uma solicitação de inutilização da nfe e não a solicitação de autorização? Não encontrei nenhum parâmetro que me diga isso.
Na versão 2.0 era utilizada a função J_1B_NFE_XML_OUT, que com a combinação dos parâmetros XML_IN-DOCSTAT, XML_IN-SCSSTAT e XML_IN-TPEMIS era possível determinar qual era a ação a ser realizada (solicitar aprovação, cancelamento [ quando ainda não era por evento] , inutilização...)
Me parece que falta algum parâmetro na nova função que nos diga qual foi a ação realizada...
Notei que para casos de inutilização o parametro IS_NFE_IDE-TP_EMIS, e alguns outros, ficam em branco. Mas não achei seguro fazer a validação dessa forma.
Será que existe alguma nota que corrige isso? procurei, mas não encontrei.
Enfim, agradeço por qualquer ajuda.
Abraços!

Oi,
A diferença entre a autorização e a inutilização pode ser identificada pelos parâmetros em branco. Na solicitação de autorização as estruturas com dados de produto/impostos/destinatário estão preenchidas, na inutilização elas estão em branco.
Além disso algumas informações de header da nota estarão em branco na inutilização, como por exemplo o tpemis.
Acredito que independente da mensageria é possível que eles mapeiem os dados usando essas diferenças como parâmetros para identificação.
att,
Renan

Inutilização de NFe: Log de erro Message type 8 is not defined

Olá Pessoal,
Estamos com um erro aqui muito semelhante ao descrito na Thread: [Skip número da NF não autorizada|;.
Solicitamos a inutilização de uma nota writer de saída que foi barrada no Monitor GRC por erro de validação e por isso estava com status 8 na J1BNFE (ECC). A inutilização foi feita com sucesso, o status no GRC está correto, mas no ECC a autorização ainda não constava. Executamos o report XNFE/UPDATE_ERP_STATUS_DIAL e ao fazermos a msg de "erro ao atuzalizar ECC". No monitor da J1BNFE a nota agora aparece com o seguinte log de erro:
Message type 8 is not defined
Message no. J1B_NFE018
Diagnosis
The messaging system passed a value for the message type to the back-end system (field I_MSGTYP) that is not defined in the back-end system.
System Response
The back-end system cannot interpret and process the inbound message.
Procedure
Configure the messaging system in a way that it transfers only allowed message types to the back-end system via the inbound interfaces J_1B_NFE_XML_IN or J_1B_NFE_XML_IN_TAB.
Achei a thread mencionada acima com o mesmo erro e verifiquei a aplicação das notas, já que o problema foi solucionado com a aplicação das mesmas. Eis os status:
Nota 1298283 (ECC) - Não relevante pois estamos no ECC 6.0 SP17;
Nota 1376324 (ECC) - Não relevante pois estamos no ECC 6.0 SP17;
Nota 1413636 (ECC) - Completely Implemented na SNOTE;
Nota 1376901 (GRC) - Não relevante pois estamos no GRC SP13.
Aparenmente alguma coisa ainda está faltando.. mas nao sei o que é.
Desde já agradeço,
Daniela Machado

Verifique esses passos da nota 1298283 (no ECC)::
Change Domain J_1BNFE_MESSAGE_TYPE
Use transaction SE11
Select Domain and insert name J_1BNFE_MESSAGE_TYPE
Push Change.
Select Tab "Value Range".
Insert
Fix value Short text
8 Authorization to Skip a NF-e with Validation Error
9 Rejection to Skip a NF-e with Validation Error
Maintain table J_1BNFE_MAP_TYPE
Use transaction SE16 and display the table entries.
Push CREATE (F5)
Insert records
MSGTYP DOCSTA SCSSAT
8 Space A
9 Space B
At.,
Bernardo Braga
Edited by: Bernardo Braga on Jul 1, 2010 10:06 PM

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

NF-e sem linha de material não é cancelada/não atualiza status no ERP

Bom dia!
Estou com o seguinte cenário.
O usuário criou uma NF-e manualmente via J1B1N e enviou para SEFAZ. Posteriormente o mesmo solicitou o cancelamento e a NF-e foi cancelada na SEFAZ e no GRC; porém não foi possível atualizar o status no ECC.
Detalhe, consultando a NF-e no ERP a mesma não contém nenhuma linha de material! Diferentemente do documento no GRC! Ou seja, o item da nota no ERP sumiu!
Obviamente que perguntamos aos usuários como fizeram essa façanha... e a reposta não poderia ser diferente... não fizeram nada além do normal! :-p
Verificando a função J_1B_NFE_CANCEL disparada ao solicitar uma inutilização/cancelamento a mesma contém o código abaixo onde o sistema verifica se a NF-e contém registro na J_1BNFLIN e se não, retorna erro.
D O C U M E N T    P R O C E S S I N G
CLEAR: itab, e_cancel, lv_subrc.
CLEAR: bdcdata[], itab[], wa_bdcdata, wa_itab.
clear: lv_sernpcount.                             "1247602
SELECT * FROM j_1bnflin INTO ls_nflin
WHERE docnum = i_docnum.
    EXIT.
ENDSELECT.
IF sy-subrc IS NOT INITIAL.
    MESSAGE e045 WITH i_docnum RAISING no_nf.
ENDIF.
Estamos usando ECC 604 0008
Temos vários documentos criados na produção com essa situação e tentamos de diversas maneiras recriar o cenário em qualidade mas não conseguimos.
Abraço
Eduardo Chagas

Bom dia Eduardo,
Esta seria a "melhor ideia" que imagino ter linhas de itens enviadas ao GRC que não estão no ERP. Veja os campos CALLRFC nas linhas da ACTIVE e HISTORY se tem o valor 3 (numerado e transmitido pelo job).
Outras duas opções para investigação:
- BAdI com "boa memória", verifique se a codificação permitiria pegar itens de outro docnum e enviar como sendo desta.
- Deleção dos registros
No mais um chamado para investigação, mas sem o "como reproduzir" nem sei ajudaria.
Atenciosamente, Fernando Da Ró

Inutilização NFe 2,00 - Processo Devolução de entrada

Pessoal,
Estou com um problema no processo de MM para a inutilizar NFe (2,00) de uma Devolução de entrada.
Fizemos um devolução de entrada que foi rejeitada e para corrigir o processo, foi feito a inutilização via J1BNFE.
O status da Nfe ficou da seguinte forma
- A inutilização da Nota foi autorizada pela SEFAZ
- No GRC a nota está como inutilizãção autoriza, porém com erro de atualização no ERP.
- No ERP aparece o log abaixo:
Preencher todos os campos obrigatórios
Erro formato em campo UF05A-STGRD. Ver mensagem seguinte
Preencher todos os campos obrigatórios
Alguém já passou por isto ou poderia ajudar?
Obrigada,
Erica

Bom dia Érica,
Dê uma procurada no fórum antes de postar, veja:
threads com UF05A-STGRD problemas e soluções
Atenciosamente, Fernando Da Ró

NFe em processamento no ERP e OK no GRC mas teve erro de atualização do ERP

Boa tarde,
Tem acontecido que ao tentar atualizar a NFe, ocorre o erro de atualização (tabela /XNFE/NFE_HISTconsta 108), porém no monitor GRC a NFe está com status OK (verde).
Ao verificar a tabela /XNFE/NFE_HIST, o registro de wasstat 05 (Result Received) tem o error_erp 108, porém o último registro da tabela é o de wasstat 08 (sent to B2B) e neste o erroe_erp está em branco. Inserindo o erro 108 neste último registro, a NFe aparece agora no monitor GRC com status de erro, e o erro ERP 108, e aparece na aba de "Erro atualização status ERP", permitindo assim o uso da opção Atual. (atualizar o ERP novamante), que após acionado, atualiza o ERP corretamente e volta a NFe para OK no monitor GRC.
Já pesquisei notas e aqui no SCN e não encontrei nada relacionado.
Alguém já passou por isso.
GRC 10.0 sp13
ERP 604 sp11
Abraços
Ricardo Carneiro.

Bom dia Ricardo,
Vamos por partes...
- o 05 significa resultado recebido da Sefaz, e o status 100 diz que foi tudo Ok por lá
- o 05 tenta comunicar com o ERP, e o 108 indica neste status que o ERP não pode processar seu status
- o 08 não comunica com o ERP, então nele não deve ter ERP_ERROR mesmo
Agora as questões:
- Deveria ter o processo parado no 05 já que houve um erro? Para alguns a resposta seria sim sim sim, para outros já que tá tudo OK faz o B2B
- Não deveria ter sido copiado o status 05 para 08? Talvez (pq resolveria a questão manual)
- O que fazer então?
Sobre o 108 ele é sintoma SEMPRE, algo não está bom no processamento ERP. A única coisa esperada de fato na emissão é o lock de processo no ERP, que o SAP NFE trata reenviando via job.
Na emissão muito provavelmente é algo errado seja configuração, seja código e deve estar dentro da BAdI.
Você não postou o que encontrou na RSRFCTRC. Poste por favor.
Com o foco em solução te indicaria investigar o que está errado no ERP, e a questão ERP_ERROR não estar visível no 08 vai ficar menor. De qualquer forma pode ser motivo de chamado para o desenvolvimento avaliar opções, mas é um remédio para sanar sintoma não para curar a doença.
* Se fosse um processo de cancelamento ou skip bem mais coisas poderiam acontecer como fonte de um erro de processamento ERP.
Atenciosamente, Fernando Da Rós

ERP STATUS 109 - Erro de Validação

Boa Noite ,
Estamos Implementando NF-e no Cliente e estamos com problema no momento de inutilizar qualquer NFE que foi reprovada pelo validador interno do GRC (Bandeira Vermelha e Engrenagem na J1BNFE) , no ambiente de DEV esta funcionando OK , em QAS ocorre o problema. Estamos a alguns dias do Go-Live e esse é o unico erro critico que estamos encontrando no Projeto.
O Fluxo de aprovação da inutilização esta ok , retorna para o GRC , mas nao atualiza a tabela J_1BNFE_ACTIVE no ECC, acusando o erro ERP 105 ou 109 no monitor do GRC
Ja haviamos realizado a aplicação das notas abaixo , conforme indicaçao do Henrique Pinto e Fernando Ros em outros Threads.
1413636 - Status bandeira vermelha após Skip NFe. (Nãqo lembro da descrição correta)
1376324 - NF-e: Skip for NF-e with validation error
1298283 - NF-e: Skip for NF-e with validation error
1376901 - Skip for validation error
Alguem ja teve que brigar com esse problema ??? Poderiam nos ajudar ???
Grande abraço a todos,
Rafael Medice

Bom dia Rafael,
Ao que parece está faltando algumas coisas na sua implementação:
105 - refere-se aos objetos NF-e estarem bloqueados no R/3 quando o GRC envia a resposta do processamento, então é provável que vocês não tenham implementado o decouple. Verifique na J_1BNFE_ACTIVE se estão com CALLRFC=vazio, se estiver não está implementado. Solução: Procure pelas notas e no fórum tem vasto material sobre isso.
109 - quando o status que o GRC está enviando é incompatível com o status que o ERP aguarda. Isto pode até estar associado ao anterior, mas o mais comum é a falta de tratamento na impressão automática ou qq coisa que implementaram no método CALL_RSNAST00 da BAdI CL_NFE_PRINT. A SAP Note 1470484 evita o 109 numa retransmissão do mesmo status de Sefaz, porém você deve revisar seus códigos. Procure por exemplos de código aqui no fórum também.
Observação: Verifique TODAS as notas XX-CSC-BR-NFE para o seu ambiente, TODAS são necessárias. Sendo que as mais recentes deve-se planejar pois envolvem também o layout 2.0.
Atenciosamente, Fernando Da Ró

Cancelamento/inutilização: erro de sistema PI

Pessoal, bom dia!
Por favor, estamos testando o cenário de Cancelamento de NF e as notas estão ficando com os seguintes status:
Stat. Processo: 06 - Enviado ao Processamento da Nota Fiscal Eletrônica
Status de erro: 50 - Cancelamento/inutilização: erro de sistema PI
Analisando o erro no Monitor do PI, peguei o XML enviado ao Sefaz e testei no endereço http://www.sefaz.rs.gov.br/NFE/NFE-VAL.aspx e os dados estão corretos.
O Erro detalhado no Monitor do PI é (Error in response):
Message processing failed. Cause: com.sap.aii.af.ra.ms.api.RecoverableException: SOAP: response message contains an error XIAdapter/PARSING/ADAPTER.SOAP_EXCEPTION - soap fault: Unexpected Error java.lang.NoSuchMethodError: javax.xml.soap.SOAPFactory.newInstance(Ljava/lang/String;)Ljavax/xml/soap/SOAPFactory; at br.inf.portalfiscal.soapclient.ClientSoap.(TransitoCancelamentoClient.java:56) at br.inf.portalfiscal.nfe.controller.ValidaDadosCanc.verificarRegistroCirculacao(ValidaDadosCanc.java:248) at br.inf.portalfiscal.nfe.controller.ValidaDadosCanc.validaDadosCanc(ValidaDadosCanc.java:214) at br.inf.portalfiscal.nfe.controller.ValidacaoXMLHelper.validaCancelamento(ValidacaoXMLHelper.java:307) at br.inf.portalfiscal.nfe.controller.UtilSession.processarCancelamento(UtilSession.java:509) at sun.reflect.GeneratedMethodAccessor292.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.invocation.Invocation.performCall(Invocation.java:359) at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:237) at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:158) at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:169) at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:350) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181) at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:168) at org.jboss.ejb.plugins.LogInterceptor.inv
Obrigado,
Danilo

De fato, esse trace é do web service da propria SEFAZ.
Esses objetos referenciados (e.g. ValidaDadosCanc.java) não fazem parte do pacote do SAP NFE.
O status no GRC está como comunicacao de PI (vermelho)?
Se sim, depois de a SEFAZ corrigir o problema, vc consegue restartar o processo pela aba de Erro de Cancelamento/Inutilizacao no Monitor de NFes.
Abs,
Henrique.

NFe de Entrada Docstat incorreto

Bom dia Senhores(a). Tudo bem?
Meu problema é que criamos algumas notas de entrada através da BAPI_J_1B_NF_CREATEFROMDATA, e o XML foi gerado com sucesso, tal como as NFe´s do processo de SD. Porém ao efetuar o retorno, apesar do monitor a NFe aparecer com Status "Completo", na tabela J_1BNFDOC o campo DOCSTAT, vem em branco. O Problema é por causa deste campo estar em branco a NFe não esta aparecendo no livro de entrada mesmo estando ok no monitor.
Nos casos de NFe´s criadas por SD (VA01) este campo vem preenchido automaticamente após o retorno realizado.
OU seja, quando a Nfe esta ok no monitor tb está ok no livro fiscal.
Espero poder ter sido claro, agradeço a ajuda de vocês.
Um abraço
Vitor Grassato

Bom dia Vitor,
Esta linha está comentada. Está comentada também no código ? Se tiver não fede nem cheira...
Quando você diz que não funciona, não funciona como ? Que retorno tem no RETURN ?
Na chamada da BAPI_J_1B_NF_CREATEFROMDATA tem um parâmetro NFCHECK que gerencia os checks obrigatórios é uma string preenchida com vários X e espaços, sendo o X verificar o o espaço permitir campo vazio.
No código fonte da BAPI você encontra estas informações:
Positions in character 30 string NFCHECK
Following checks are executed when NF-e flag is set in the header
40. Check NF-e number filled
41. Check Protocol number filled
42. Check XML-Version filled
43. Check Sefaz code filled
A. Check if duclicate keys are existing (NF line items, NF taxes)
=> e.g. NFCHECK = 'XX X XXX XXXXXXXXXX.....' will perform all checks,
except checks number 3, 5 and 9)
Se o parâmetro não for preenchido, no código temos:
IF nfcheck IS INITIAL.
*--------------12345678901234567890123456789012345678901234567890123
nfcheck = 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'.
ENDIF.
O que quer dizer que por default apenas o NF-e number filled é verificado. Vocês estão preenchendo NFCHECK ? Que erro está dando que impede o processo ?
Editando: Outra pergunta: Quais são os valores para AUTHCOD, DOCSTAT e CODE na J_1BNFDOC logo após a criação ? E após a autorização ?
Atenciosamente, Fernando Da Rós
Edited by: Fernando Ros on Feb 4, 2010 2:57 PM

PI NFE StatusService Problem

Hello all,
I'm testing my Nfe process, but the Status Service is not ok..
I dont know why, because I've configuration this scenary according the sap best practices...
In Nfe monitor the status is red since the test started...
STATUS ERROR: 70
In the SOAP ADAPTER that will comunicate with sefaz i entered theses parameters:
target url: http://nfe.fazenda.sp.gov.br:443/DigitalSignature/ws?style=document   .....> SP
Configure user authentication: Is it needed?
Proxy: I configurated the proxy according my Internet Explorer uses for others sites.
Obs.: I've heard about the password be UPPERCASE, it has some sense? If so, what password? proxy or authentication one?
Thanks and regards,
André Ramalho.
Edited by: Andre Ferreira Ramalho on Sep 18, 2009 2:54 PM

Hello everyone,
I am having the similar issue.
I am running a service staus job "/XNFE/CHECK_SRV_STATUS" every half hour for testing but I am getting the error code 70 in the NFE browser monitor under service status tab.
1. Looking at the table /XNFE/SRVSTA I see the following information.
MANDT           xxx
CUF                 35
TPAMB             2
CHECKTMPL       20,091,028,xxxxxxxx
STATUS
TMED            0
ERROR STATUS    70
RETURN DATE
RETURN TIME     00:00:00
TZONE           BRAZIL
RETURNTMPL      0.0000000
XOBS
ERROR TEXT      MESSAGE.GENERAL
2.Checking at the communication channels in PI under RWB i see the error in two communication channels corresponding to t2o regions which I have defined
Audit Log for Message: dec3d072-07ad-c8f1-822f-005056b819bc
Time Stamp Status Description
2009-10-28 10:44:55 Success Message successfully received by messaging system. Profile: XI URL: http://hostname:5xx00/MessagingSystem/receive/AFW/XI Credential (User): PIISUSER
2009-10-28 10:44:55 Success Using connection SOAP_http://sap.com/xi/XI/System. Trying to put the message into the request queue.
2009-10-28 10:44:55 Success Message successfully put into the queue.
2009-10-28 10:44:55 Success The message was successfully retrieved from the request queue.
2009-10-28 10:44:55 Success The message status set to DLNG.
2009-10-28 10:44:55 Success Delivering to channel: SRVSC_SOAP_RCV
2009-10-28 10:44:55 Success MP: Entering module processor
2009-10-28 10:44:55 Success MP: Processing local module localejbs/sap.com/com.sap.aii.af.soapadapter/XISOAPAdapterBean
2009-10-28 10:44:55 Success SOAP: request message entering the adapter with user J2EE_GUEST
2009-10-28 10:44:58 Error SOAP: call failed: java.io.IOException: invalid content type for SOAP: TEXT/HTML; HTTP 403 Forbidden
Q.2 Second question I have is we have configured core system NFE in ERP itself so for that I have defined two RFC's between ERP and PI 7.0 systems
1. ABAP RFC
2. HTTP RFC
My question with respect to this is which RFC should be used while creating a NFE.
Thanks and regards
Basit Shaikh
Edited by: Shaikh Basit on Oct 28, 2009 6:44 PM

Preciso de opnião sobre qual cenário usar para um processo SD

Pessoal,
Como estão ? Espero que todos bem e alocados.
Seguinte estou com um processo de venda na qual não estou segura de qula cenário SAP posso aplicar.
Gostrai da opnião de vocês.
A empresa precisa emitir uma remessa para manutenção, de um equipamento que se encontra dentro de uma fábrica de terceiros, mais este equipamento não pertenece a empresa, este equipamento esta na fabrica do cliente do nosso cliente.
Ou seja
Fabrica X - dona do material que enviou em comodato - saiu como remessa em comadato para o cliente H
Fabrica Y - recebeu o material em comodato em nome do fornecedor H
Cliente H - E o cliente real da fabrica X, o pagador do material e da manutenção.
O material que sera usado na manutenção estara nas mães de técnicos da Fabrica X
Pergunta, qual melhor cenário para envio das peças para conserto, e uma emessa mesmo.
Existe um cenário melhor ?
Com trabalham empresas que tercerizam sua manutenção para uma outra empresa ? usam que tipo de cenário
obrigada a todos
Edited by: Martha Zar on Oct 19, 2009 6:45 PM

A data de escrituracao = posting date da J_1BNFDOC.
O problema é para notas emitidas perto da meia noite, em que a autorizacao pode vir só no outro dia, é isso?
Pq nao tem hora pra escrituracao, só data, entao só vejo problema em querer alterar a data, a nao ser nesse caso.
Mas note que a NF-e nao aparece no livro (ou nao deveria aparecer) enqto ela nao estiver autorizada (docstat = 1, statcode = 100), ou aparece como cancelada (se ela tiver sido cancelada ou inutilizada, flag de cancelled = X).
De qq maneira, se vc quiser, pode analisar a possibilidade de alterar o valor do posting date no metodo call_rsnast00 da badi cl_nfe_print (que eh chamada no retorno do grc pro erp), e alterar qdo a nfe for autorizada (status atual = aguardando resposta e status da sefaz = 100 (autorizada)). Nao sei se dá, tem q ver os parametros q sao passados.
Abs,
Henrique.

Erro de Validação SCS = 9

Bom dia pessoal, tudo bem?
Estamos atualizando a NFE 2.0 no ambiente QAS.
Após a geração da NFE, retornou o status para J1BNFE da seguinte forma:
- status ação: em comunicação (rodinha)
- log NFE: verdinho
- status do documento: branco
- status de comunicação do sistema: 9
- status do sistema de mensagem: V
No GRC está:
- Nos detalhes da NFE => Status NFE: X vermelho / Status processo: 5 / Código status: 102
- Na aba "Erro atualização status ERP" (na primeira tela do GRC) => Status: X vermelho / Erro ERP: 105
Observação: tentei atualizar a NFE, marcando a linha e reiniciando o processo, mas não está surtindo efeito.
Alguém já passou por isso?
Agradeço pela ajuda.
Abçs.
Adriana

Adriana,
se a mensagem continua a mesma, deve ser porque não inseriram as linhas na tabela J_1BNFE_MAP_TYPE, como citado pelo Fernando. Você limpou o log de erros da nota antes de reenvia-la do GRC p/ o ECC?
Verifique se o passo abaixo foi executado durante a aplicação da nota:
Maintain table J_1BNFE_MAP_TYPE
Use transaction SE16 and display the table entries.
Push CREATE (F5)
Insert records
MSGTYP    DOCSTA     SCSSAT
8       Space        A
9       Space        B
Já passei por isso em uns 2 clientes e o problema sempre foi a aplicação dessa nota hehehe
Notas com "manual step" sempre dão mais dor de cabeça.
[]'s
JN

Momento de disparo comunicação com GRC NF-e (Processo SD)?

Boa tarde a todos!
Uma dúvida interessante:
Qual seria o real momento de disparo de comunicação entre o ERP e o servidor GRC NF-e em um processo SD?
Imagine um cenário no qual a liberação contábil é feita após o salvamento do faturamento.
a. Seria no momento de se salvar o documento de faturamento;
b. Ou seria no momento de se liberar o documento para o lançamento contábil?
Acredito que seja a primeira opção, mas tenho dúvida.
Outra dúvida:
Seria possível, no caso de o disparo ser no momento de se salvar o documento de faturamento, realizar alguma configuração no SAP para que, ao invés disso, o mesmo realizasse o disparo no momento de se liberar o documento para o lançamento contábil?
Obrigado pela atenção,
Daniel.

A data de escrituracao = posting date da J_1BNFDOC.
O problema é para notas emitidas perto da meia noite, em que a autorizacao pode vir só no outro dia, é isso?
Pq nao tem hora pra escrituracao, só data, entao só vejo problema em querer alterar a data, a nao ser nesse caso.
Mas note que a NF-e nao aparece no livro (ou nao deveria aparecer) enqto ela nao estiver autorizada (docstat = 1, statcode = 100), ou aparece como cancelada (se ela tiver sido cancelada ou inutilizada, flag de cancelled = X).
De qq maneira, se vc quiser, pode analisar a possibilidade de alterar o valor do posting date no metodo call_rsnast00 da badi cl_nfe_print (que eh chamada no retorno do grc pro erp), e alterar qdo a nfe for autorizada (status atual = aguardando resposta e status da sefaz = 100 (autorizada)). Nao sei se dá, tem q ver os parametros q sao passados.
Abs,
Henrique.

GRC! Realmente devo investir em aprende-lo só agora?

Boa noite,
Sou consultor PI da Gafisa S.A construtora em SP.
Aqui não precisamos implementar o GRC, a SPED foi feito por um software de terceiro e a única coisa que temos desenvolvida no PI são interfaces que levam informações para o SQL desse software terceirizado.
Gostaria de saber se com o limite do prazo para a entrega da SPED, é realmente importante aprender como utilizar o GRC nessa altura do campeonato ? O GRC possui alguma outra funcionalidade tão bem utilizada além da NFE ? Se eu sair do meu atual emprego em 1 ano. Nessa data daqui à 1 ano, terão oportunidades para NFE ou já estará tudo implementado e será algo já extinto ?
Gostaria de sugestões de vocês que estão tão envolvidos com esse módulo, e gostaria de saber se devo estudar sobre o GRC afim de aumentar minhas habilidades de PI.
Muito Obrigado,
Diego Crespo

Muita informacao misturada no mesmo canto.
Vamos tentar desmistificar alguns conceitos:
- SPED: projeto nacional conceitual, que visa a reducao do chamado "Custo Brasil", focando principalmente na eliminacao de obrigacoes em papel e "simplificando" (ou reduzindo o numero de) reports e processos eletronicos;
- EFD (tb chamado "SPED Fiscal"): Escrituracao Fiscal Digital, report eletronico que visa substituir diversos livros fiscais, entre eles nota fiscal de saida, de entrada, inventario etc. Faz parte, num contexto macro, do projeto nacional SPED.
- ECD (tb chamado "SPED Contabil"): Escritruacao Contabil Digital, report eletronico que visa substituir obrigacoes contabeis (e.g. Diario, Razao etc). Faz parte, num contexto macro, do projeto nacional SPED.
- NF-e: Nota Fiscal eletronica, que criou um novo processo de autorizacao online para emissao de notas modelo 55 (em substituicao às notas modelo 1/1A). Faz parte, num contexto macro, do projeto nacional SPED.
- SAP GRC NFE: solução SAP para o processo de NF-e. Utiliza o produto SAP Process Integration (SAP PI) para a comunicacao com Business Partners externos (e.g. SEFAZs, fornecedores (p/ recepcao de XML) e clientes (p/ envio de XML));
- GRC: Governance, Risk & Compliance, uma suite de solucoes SAP que endereçam issues de governança, gerenciamento de risco e conformidade legal. Além do SAP NFE, existem diversas outras solucoes classificadas como GRC: SAP Access Control, SAP Process Control, SAP GTS, SAP EH&S etc. Todas essas solucoes sao independentes das outras no sentido de que não tem necessariamente a mesma arquitetura (e.g. usando o SAP PI).
Quando vc diz que vcs utilizaram software de 3o p/ o "SPED", vc quis dizer p/ a NF-e ou EFD/ECD?
A data limite de entrega do "SPED", imagino que esteja falando do EFD/ECD, que nao tem nada a ver com NF-e.
P/ NF-e, existem diversas ondas de obrigatoriedade, com certeza muitas empresas já foram, mas existem ainda diversas para entrarem, então acho q ainda existe um mercado potencial pelos proximos 2 anos, no minimo. Com certeza, depois disso a tendencia é cair. O SAP NFE nao deve ser encarado como sendo um modulo a ser aprendido e viver só dele, mas sim como uma porta de entrada para os processos dentro do SAP. Uma vez aprendido o NFE, vc pode dar um foco mais funcional (no SD e MM) ou mais tecnico, no PI. Vai depender do seu perfil.
Abs,
Henrique.
PS: vou mover o tópico p/ o forum de Discussoes Gerais

Inutilização de NFE nao atualiza status no R/3

Similar Messages

Maybe you are looking for