Ir para conteúdo
  • Cadastre-se

thiih_

Membros
  • Total de ítens

    6
  • Registro em

  • Última visita

Reputação

3 Neutro

Sobre thiih_

  • Rank
    Novato
  • Data de Nascimento 10-03-1990

Contact Methods

  • Website URL
    www.deltress.com.br

Profile Information

  • Sexo
    Masculino
  • Localização
    Marília

Últimos Visitantes

O bloco dos últimos visitantes está desativado e não está sendo visualizado por outros usuários.

  1. Boa Noite pessoal, tudo bem? Por um descuido, um cliente estava emitindo os XMLs do SAT ainda na versão 0.06, o aparelho que é um RB-1000 estava na versão 0.07 porém no sistema ainda estava configurado para versão 0.06. A emissão do cupom ocorreu normalmente, o cliente me ligou somente hoje (mesmo o sistema avisando que não havia transmissão de CFes para SEFAZ ha n dias). Enfim, até dia 20/01/19 todos os cupons emitidos, mesmo que no layout 0.06, foram transmitidos e processados pela SEFAZ... A partir do dia 21/01/19 os cupons pararam de ser transmitidos/processados, sendo acumulando na memória do aparelho. Fazendo a trasmissão manual pelo retaguarda, recebo a mensagem: 239 - Rejeição: Versão do arquivo XML não suportada. Em uma tentatica frustada de tentar "enganar" a SEFAZ, apenas mudei no XML para versao 0.07, o XML é aceito (processado com inconsistencias), com o retorno: 297 - Rejeição: Assinatura difere do calculado. São um total de 261 cupons entre 21/01/19 até 30/01/19 emitidos no Layout 0.06 que não consigo transmitir, porém hoje já alteramos para o Layout 0.07 e os cupons emitidos após a alteração foram processados e transmitidos tranquilamente. Alguém saberia me dizer como proceder neste caso? o que pode ser feito com esses cupons emitidos que a SEFAZ não aceita? Como que pode o aparelho processar e aceitar o cupom normalmente visto que ele não é mais válido? Tudo bem que foi um descuido manter a versão 0.06, porém acho que o aparelho também deveria barrar a emissão nesse layout antigo, e se o cliente tivesse nos avisado no primeiro dia quando falhou a transmissão, também seria "mais tranquilo". Desde já, Muito Obrigado!
  2. Pessoal, boa tarde, beleza? Estou com uma situação em 3 clientes (por enquanto), na qual os 3 são SIMPLES e os fornecedores não estão aceitando as notas de devoluções porque não está saindo impresso no DANFE, no campo próprio de IPI. Os fornecedores se recusam a receber a devolução alegando que não está o IPI no DANFE, porém estamos enviando na tag IPIDevol, ou seja, com o XML está tudo correto acredito eu. Minha pergunta é: Empresas do simples é para realmente mover o valor de IPI no campo IPIDevol, correto? e o mesmo não deve ser impresso, a nao ser nas informações complementares.. se mover para o campo IPI normal a nota é aceita e impresso no campo próprio, mas acho que viola as NT visto que são empresas do SIMPLES. Os contadores dessas empresas também disseram que é para sair impresso na DANFE, porém acabei de mandar a NT para ele e para o fornecedor, estou aguardando uma resposta deles.. se for o caso, somente nesse cliente estava pensando em modificar o danfe e imprimir o ipidevol no campo de ipi, apenas para satisfazerem esses fornecedores, mas sei que não é o correto.. o que me dizem? Obrigado, até mais
  3. @Marcos Davi Mendes Boa tarde pessoal, tudo bem? Estou tendo o mesmo problema do tópico criado pelo amigo citado acima, porém como é na parte paga, eu não consigo postar lá.. após fazer alguns testes, pelo menos para nós, "resetando" o driver o token "resolveu" (entre aspas porque tenho que fazer isso toda vez que desliga e liga o computador). Acontece isso somente com um único cliente, cujo certificado é da Serasa Experian etoken 72k (SafeNet), que está prestes a vencer, espero que renovando isso pare de acontecer.. Bom, toda primeira nota do dia, ou seja, primeira vez que vai usar o certificado digital para assinar a nota, recebo a mensagem "Falha em obter o provedor de cripytografia do certificado. Erro: 80090014" e descobri que Desativando e Reativando o USB Token no Gerenciador de Dispositivos do Windows consigo enviar a NFe normalmente, funciona o dia inteiro, até que ele desligue o computador e ligue no dia seguinte, pois ai na primeira nota da o erro, Desativo e Reativo o USB Token no gerenciador e funciona o dia inteiro novamente, e por ai vai.. Enfim, descobri isso após desinstalar/reinstalar diversas vezes/versões dos drivers e gerenciadores do certificado e mesmo assim sempre ter o mesmo problema.. Para automatizar o processo de Desativa/Ativa o driver do token, fiz um batch utilizando o programa DevManView.. Só consegui "resolver" o problema dessa maneira.. Estamos usando a versão NFe 4.0 com as seguintes configurações:
  4. Está sim, texto básico: "Segue sua nota fiscal eletrônica + dados do emitente", conforme a imagem em anexo.
  5. Boa noite, tudo bem? Também estamos tendo esse "problema", começamos a atualizar nossos clientes para a versão 4.0 e começamos a receber alguns relatos de que apenas o PDF estava sendo enviado nos email, nada do XML. Resumindo, após alguns testes: Emails enviados para provedores Gmail, Outlook/Hotmail e nosso provedor próprio -> Recebemos o PDF e o XML. Emails enviados para provedor YAHOO: vai apenas o PDF em anexo, a pessoa não recebe o XML. (só consegui testar com o Yahoo, pois os outros casos são email dos clientes de nossos clientes, então nâo temos acesso, mas alguns alegam que só recebem o PDF) você tem alguma novidade sobre isso? Obrigado!
×
×
  • Criar Novo...