Chave de Acesso no DANFE difere da Chave de Acesso do XML

Prezados,
Bom dia.
Temos uma situação esporádica aqui, absolutamente aleatória, sobre a qual gostaria de perguntar aos nossos gurus:
Nosso ambiente é ECC 7.01 EHP4, e utilizamos o GRC para a comunicação com as SEFAZ's.
Fazemos um processo de venda, e enviamos à SEFAZ, que autoriza a operação, normalmente.
Ao imprimir o DANFE, o processo de impressão acontece sem problemas, com exceção da Chave de Acesso: é impressa uma Chave de Acesso DIFERENTE da Chave de Acesso que consta no XML, e na SEFAZ.
Ao se reimprimir o DANFE, a Chave de Acesso é corretamente impressa, ou seja, é impressa a mesma Chave de Acesso constante no XML e na SEFAZ.... diferente da impressa inicialmente.
Seguem detalhes sobre nossa instalação PI:
SAP_ABA     700     0022     SAPKA70022
SAP_BASIS     700     0022     SAPKB70022
PI_BASIS     2005_1_700     0022     SAPKIPYJ7M
SAP_BW     700     0024     SAPKW70024
SLL-NFE     100     0016     SAPK-10016INSLLNFE
Alguém já passou por isso ?
Muito obrigado.
Cordialmente,
Loduca

Loduca,
A impressão da DANFE é ABAP, não há motivos para pensar em algum erro no PI desde que a nota está devidamente aprovada.
Vocês usam impressão automática da DANFE ?
BADI CL_NFE_PRINT method CALL_RSNAST00
Acredito que exista algum erro no código Abap e se há um cenário especifico debugando é possível achar.
O que seria a chave de acesso diferente? Alguma chave já existente no sistema? Ou sujeira mesmo?
Abraço,
Bruno Lima

Similar Messages

  • 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

  • Devolução de compra

    Tenho o seguinte cenario:
    Foi recebida uma mercadoria por NFe,  e dado entrada com NFe, porem a NFe, não foi enviada para a SEFAZ.
    Preciso fazer uma devolução de um dos itens da NFe, quando envio a NFe de devolução para SEFAZ,
    é rejeitada porque a chave de acesso esta incompleta.
    Meu sistema esta buscando a chave de acesso na NFe, de entrada que não foi enviada a SEFAZ, logo não esta completa, porque não tem o numero aleatório.
    Duvida:
    Preciso enviar a NFe de entrada para a SEFAZ ?
    Se não for preciso, como faço com o numero de referencia que a NFe de devolução exige ?
    Agradeço desde já a ajuda .
    Att

    Guiliano,
    o processo nao é esse.
    No recebimento de uma NF-e de entrada, nao há comunicacao com a SEFAZ para autorizacao.
    A NF-e já está autorizada (quem fez a comunicacao p/ autorizacao foi o emissor!).
    Aliás, como ele iria pegar a chave de acesso na SEFAZ se a chave de acesso é o identificador inicial que a SEFAZ exige? Nao faz sentido.
    Os campos que completam a chave de acesso e o protocolo de autorizacao sao parametros que devem ser inputados no sistema durante o processo de entrada.
    Essa nota aparece como na J1BNFE?
    Ela deveria aparecer com o icone amarelo (de que falta acao manual).
    Se nao aparece assim, podem estar faltando algumas notas.
    De qq maneira, o que vc precisa fazer é:
    1. verificar no site da SEFAZ, com a chave de acesso, se a NFe está realmente autorizada (manual)
    2. no ERP, na transacao de entrada, vc vai no botao de Nota Fiscal, daí na aba "NFe" vc inclui o protocolo de autorizacao, o numero randomico e o digito verificador.
    Alternativamente, vc pode seguir com o processo normal, depois de salvar a NFe ela vai aparecer na J1BNFE com o icone amarelo (requer acao manual). Daí vc pode ir na J1B2N e atualizar as informacoes faltantes e salvar a Nota; pode ser preciso abrir os campos no screen control (view J_1BAMV). Depois de salvar a NFe com os dados, volte na J1BNFE; ela deverá aparecer com a bandeira quadriculada.
    Abs,
    Henrique.

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

  • Falha ao atualizar status no R/3 (J1BNFE)

    Bom dia,
    Algumas NFs apresentaram no GRC o erro "204: Rejeição: Duplicidade de NF-e" porém, no monitor do R/3 (J1BNFE) as mesmas continuam com status "In process" (engrenagem).
    Saberiam me dizer se existe alguma nota que resolva isto ou se é possível cancelar estas NFs no R/3?
    Estamos utilizando o SP10 no GRC.
    Obrigado,
    Ricardo Marcondes.

    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.

  • Brazil: User Exit in RFFOBR_A

    Hi everybody,
    When running program RFFOBR_A to generate a CNAB payment medium we want to add the Boleto number in field J_1BDMEZA-A11 (Nosso Numero). At this time it is '0' but we want it to be populated with the next check lot number in order to be able to use the payment file for Boleto printing. Does anybody know a user Exit / enhancement point that can be used to populate this field?
    Thanks in advance!
    Best regards,
    Alex

    Alexander Bösel,
    you don`t need to create user exit to populate "nosso número".
    There is a standard algorithm in Brazilian Localization.
    1 - Make sure the following fields are defined in OB32 - Document change rules.
    D
    BSEG-XREF1
    Chave referência 1
    D
    BSEG-XREF2
    Chave referência 2
    D
    BSEG-XREF3
    Chave referência 3
    2 - Check FEBRABAN Layout Description code C044 - Código de Movimento Retorno as external operation: '02' = Entrada Confirmada (1st Bank Advice upload)
    3 - Enter OT51 and define processing type and external operation: Brazil: enter document with brazilian data
    Best Regards

  • Certificados repetidos

    Sou  novato neste ambiente de trabalho, e por isso venho pedir ajuda e esclarecimento. São duas situações que me levantam dúvida.
    O assunto: Chaves certificadas
    Reparo a existência de chaves certificadas repetidas
    Reparo a existência de chaves a vermelho, inválidas
    Pergunto:
    Como verificar cada uma das anomalias e como determinar a ação correspondente: manter , ou apagar?
    Agradeço a colaboração
    Abraço

    Fabiana,
    certificados sao objetos pre-definidos e que a priori tem que ser estaticos durante um longo tempo de validade (1~3 anos).
    Se vc tem um certificado que se altera constantemente, onde está a confiabilidade?
    Me parece que SP está com sérios problemas de infra.
    De qq maneira, vc está falando dos certificados da própria SEFAZ.
    Bastaria importar as 2 cadeias no TrustedCAs e vc nao precisaria mais se preocupar.
    Nao teria que ficar trocando um pelo outro pois ambos estariam "trusted" ou confiáveis.
    Abs,
    Henrique.

  • Accesing external files in ME

    Hi,
    I would like to read and write "external" files in a midlet. I mean, I want to be able to create a text file on a PC, transfer it to the phone, and read it (and vice versa).
    I know there is JSR-75. I even found an example:
    [Java Tips - How to Access Local File Systems from J2ME devices using FileConnection API|http://www.java-tips.org/java-me-tips/midp/how-to-access-local-file-systems-from-j2me-devices-using-fileconnectio-2.html]
    It works on Netbeans, but it doesn't work in my phone. The midlet just present a white form and doesn't do anything.
    I think the problem is with permissions. The example includes the following "In order to overcome security issues MIDlet needs to include requested file permission in its JAD file under MIDLet-Permission property."
    I know how to edit the JAD file in Netbeans. My question is what is the value given to the property? Is there any other way to give permissions to the midlet in order to read and write files?
    Thanks
    Edited by: King_Guanaco on Feb 16, 2010 8:08 AM

    well... using a xml its very fine to implement diferent things
    mabe to make a same app whit diferent theme
    ex .. changing the xml to load diferents img
    my question its... you can use  a load function whit as3 on iphone ....for load a xml file??
    thanks guy
    lucky on the code!!!

  • User authorization base on calculated field

    I may ask for an imposible, here my case
    we have a customer repository, where depending of the convination of values of few fields, diferent organizations are responsible of each customer (4 diferent organizations, I would call them by colours)
    in that way I thought to make four calculated fields, as isrelevant_for_organization_blue, etc... where I codify the logic behind
    (note, a customer can be relevant for more than one organization, therefore the four fields)
    and of course, the users want to only only their relevant customers, and not able to see the non-relevant
    so, the first idea, "let's maintain the authorization on the calculated field !!"
    which it come to do not work, becouse no authorization can be made on calculated fields
    second idea, "let's calculate it on import time", which even is worst idea (in case logic change, there is a need of correct the data) and it does not work neither. No calculation fields on import time ...
    any other idea arround ??
    thanks you
    (running MDM 5.5.SP6)

    what you mean  by "by using assignments" ??
    doing it manually ??
    we are loading from diferent sources via XI into MDM (XML file into the MDM folder ...)  and we would not like to codify this logic into XI. Te logic is subject to change from time to time (often I fear)
    correction to historical data when logic is changing, can be done using a calculate field and manual correcting the necesary records. But on daily/weekly bases (when we load info) it should be done someway automatically
    any ideas ??
    thansk in advance

  • Rejeição por erro 539 Duplicidade de NF-e, com diferença na Chave de Acesso

    Senhores,
    Todo o processo de NFE está funcionando perfeitamente, porem existem algumas notas, que aleatoriamente apresentam o seguinte erro:
    http://img814.imageshack.us/img814/6417/screenhunter02jan260836.jpg
    Se notarmos ele traz status 539 e um símbolo quadrado com um raio no meio, significando recusado.
    Verificando no PI, noto que a assinatura digital (SIGNN) ocorre sem problemas nenhum, porem no envio do lote BATSR, no campo "" traz a mensagem: "Rejeicao: Duplicidade de NF-e, com diferença na Chave de Acesso ". Porem esse numero entre chaves é de uma nota de outra data... do dia 18.01. Não sei qual o motivo de estar puxando esta chave e dando esse erro.
    Segue print:
    http://img227.imageshack.us/img227/8190/imagem2sp.jpg
    Importante salientar, que todas as notas estão funcionando normalmente, os problemas são sempre com notas de mesmo número, porem com movimentação, local de negócio... diferentes. Ou seja, são ranges de números diferentes.
    Obrigado desde já

    Boa tarde,nao sei criar um topico(acho que nao posso,sei lá)
    enfim estou postando aqui pois pesquisei mto e nao tive soluçao em 3 dias,é o seguinte:
    na versao anterior tudo funcionava perfeitamente,emitia notas sem problema,ae no dia de atualizar,começou os meus problemas.
    toda vez que ia assinar uma nota dava o seguinte erro
    *Ocorreu um erro ao tentar recuperar o disposito A3*
    *verifique se o dispositivo esta conectado corretamente:*
    mudei o dispositivo de porta USB,mudei de pc e nada.liguei  entrei em contato com a empresa que vendeu a certificaçao digital.,achei que poderia ser ele o problema,fui informado que nao seria e que essa versao tem apresentado mtos problemas,se eu marco a opçao '' utilizar reposutorio do windows'',ele valida,transmite,e na hora de assinar da um erro de rejeição 562:rejeiçao codigo numerico informado na chave de acesso difere do codigo numerico da nf-e  no qual ta ruim sair dele,se marco ''utilizar o cadastro de certificado via aplicativo'' o erro ja aparece no VALIDAR,ae da o erro que citei
    *Ocorreu um erro ao tentar recuperar o disposito A3*
    *verifique se o dispositivo esta conectado corretamente:*
    aceito todo tipo de ajuda,obrigado

  • NFe - Obrigatoriedade da chave de acesso nas NFs de entrada.

    Olá
    Verificando no Site do SPED temos a nova alteração abaixo para Janeiro/2012
    http://www1.receita.fazenda.gov.br/noticias/2011/setembro/noticia-23092011.htm
    "Disponibilizada a versão 2.0.6 do Guia Prático da EFD (Art. 1º do Ato COTEPE ICMS 41/11).
    Obs.: Foi regerada a versão do Guia Prático da EFD (2.0.6A) apenas para correção do documento, sem qualquer outra modificação. A partir de janeiro de 2012, o número da Chave de Acesso da NF-e e CT-e, nas operações de entradas, passa a ser informação obrigatória."
    Para os casos de NFes de MM, não temos problema, pois todas as entradas já são preenchidas manualmente, mas temos um problema nas entradas via SD onde não existe um campo para o preenchimento da chave de acesso durante o processo de uma ordem de devolução por exemplo.
    Na geração da entrada via SD, os campos de número aleatório e dígito verificador não são preenchidos, deixando a chave de acesso incompleta.
    Gostaria de saber se existe alguma forma de fazer o preenchimento destes dois campos durante o processo de forma a garantir que sempre a chave de acesso seja criada corretamente em uma geração de NF de entrada SD via transação VF01.
    att,
    Denis C. Santos

    Oi Denis,
    creio que hoje o procedimento requer que o usuário vá na J1B2N para preencher essas informacoes, depois de criar a fatura.
    Alternativamente, vc poderia abrir um popup na exit da VF01 para preenchimento dos campos quando fosse devolução.
    Abs,
    Henrique.

  • J1B3N - Chave de Acesso - Iss. Tipo, não aleatória. & Verifique dígitos

    Na transação J1B3N, após digitar o número do documento e na tela de exibição de um nota fiscal -> na guia dados NF-e -> entre todos os campos para a chave de acesso, só vejo três campos (Iss. Tipo, de números aleatórios e Check Digit) estão em modo de mudança (não cinza).
    Você poderia por favor me ajude a responder as perguntas abaixo,
    1> Como podem estes três campos podem ser mutável em NF-e operação de exibição?
    2> falto quaisquer notas OSS?
    obrigado,
    Adv
    Edited by: adv fico on Sep 14, 2011 6:22 AM

    Bom dia Adv,
    Em linhas gerais, estes campos devem ficar cinzas para as notas de emissão própria pois o sistema as controla (numera), apenas devem estar abertos para notas emitidas pelos fornecedores e cadastradas no sistema.
    Dicas:
    - Use a transação J1B2N (alteração) para testes.
    - Faça o teste numa NF-e com formulário e outra sem (com formulário indica que é da empresa, sem formulário indica que é externa).
    Atenciosamente, Fernando Da Ró

  • Campo NF-e issuing type na chave de acesso

    Caros,
    Estou fazendo alguns testes de entrada de fornecedor e deparei com uma dúvida.
    Segundo a SAP Note 1497422 o campo  NF-e issuing type terá o valor de 1 a 5.
    Vamos supor que eu estaria dando entrada de uma nota com a chave de acesso 34100851474716000161550010000072960330544794
    O campo NF-e issuing type está bloqueado por default, até aí tudo bem é só liberar.
    Como vai ficar o dígito zero (detaacdo em vermelho) sendo que abrindo o match code vai de 1 a 5 ?   Sem falar que se ficar 1 no lugar do zero o usuário não conseguirá consultar a NFe na SEFAZ.
    Obrigado a todos.
    Marcelo

    Bom dia Marcelo,
    O issuing type requerido de 1 a 5, fazendo parte da chave de acesso é apenas para o layout 2.0.
    Quando na chave de acesso correta você tem o valor 0, refere-se ao padrão até o layout 1.10, então se o programa após esta aplicação exigir o 1 a 5 é um erro de programa.
    Se ao abrir você ficar com erro, por favor crie um chamado para XX-CSC-BR-NFE, com o step-by-step para reproduzir.
    Notas relevantes:
    1497422 TPEMIS wrong default value (0) for incoming NF-e
    1486401 NF-e: Issuing type not filled in accordance to
    1489116 NF-e: Issuing type not correct for SCAN and non-decouple
    1485996 NF-e: Issuing type in status contingency not correct
    1454408 Nf-e: Change of access key: tpEmis and random number
    1443089 NFe: Inclusion of NF-e issuing type in Access Key - Part 1
    Atenciosamente, Fernando Da Ró

  • Chave

    meu celular não está ativando a chave é um iPhone 4s de 8gb processador de 1.0 GHz iOS 7.0.1

    Oi Rodrigo,
    Até hoje não vi a SEFAZ alterar dados de um XML de NF-e, essa seria a primeira vez na história.
    Na minha opinião há um indício que o seu sistema de mensageria alterou a informação recebida do ERP antes de comunicar com a SEFAZ.
    Você consegue verificar o XML que foi enviado para a SEFAZ?
    Se a sua mensageria tem alguma lógica que pode modificar o tpemis ou qualquer dado da chave de acesso após o documento ser postado no ERP então você precisará desenvolver um mecanismo de garantir que ambos os sistemas terão os mesmo dados. A interface do ERP espera que o documento enviado para a mensageria não sofra alterações posteriores.
    OBS: SVC não é TPEMIS 2, SVC é 6 ou 7.
    att,
    Renan Correa

  • NF-e: Maintain Connected Authority Systems - Já existe uma entrada com a mesma chave

    Bom dia!
    Estou tendo um problema para adicionar novas entradas na SPRO - OUTBOUND -NF-e: Maintain Connected Authority Systems para configuração do layout 3.10:
    Sendo assim, como devo configurar todos os estados para a SEFAZ se o sistema lógico e CNPJ são chaves da tabela /xnfe/govpar?
    Com isso, não consigo executar todos os status de serviço no layout novo através do report (/XNFE/NFE_CHECK_SRV_STATUS) depois de cadastrálos na atividade NF-e: Define Service Status Request for Authority (SEFAZ,) pois durante a execução do report  (/XNFE/NFE_CHECK_SRV_STATUS) além da tabela  /xnfe/tcuf a tabela /xnfe/govpar também é verificada.
    Grato.,

    Bom dia Luís,
    Exatamente! De fato o que ocorreu foi uma confusão, pois na versão anterior era possível enviar o status de serviço mesmo se você não possuísse uma filial para o estado em questão. Quando fui fazer a migração do cliente todos os estados estavam configurados para emitir status de serviço, porém não há necessidade de enviar o status de serviço para um estado visto que você não possui uma filial para emissão de Nota no mesmo.
    Abs.,

Maybe you are looking for