Régys Silveira

Verifica os cabos e o driver, geralmente é um dos dois fatores que causa problemas de comunicação

Aqui eu comprei o certificado digital de assinatura de software próprio na COMODO e assino normalmente usando o signtool ou outra ferramenta de assinatura, a própria COMODO tem um inclusive.

Provavelmente você alterou alguma arquivo e ele não foi atualizado corretamente, ficando diferente do esperado em todo o resto do projeto ou você tem arquivos .dcu antigos ainda no seu path, como você compila a mão isso é comum acontecer. Porque ao invés de alterar o próprio ACBr você não o mantem intacto sem alterações e se mesmo necessário fazer alguma, herde a classe ou componente que deseja alterar e faz uma própria, assim, você pode manter seu ACBr atualizado e recompilando normalmente sem mexer nas suas alterações próprias.

Não existe, basicamente toda a comunicação com o SAT é feita pelas DLLs do fabricante, o componente envia comandos, recebe e trato os retornos somente.

Ai volta na pergunta do Daniel, você setou corretamente em ambos os casos a versão do SAT correta conforme o seu SAT?

Eu tenho duas FS700 para testes e em nenhum ocorre o problema com vendas de 100 itens ou mais, mesmo em sequência. Poderia anexar o log de um ECF onde ocorre o erro?

Ele não encontrou uma nota com a chave passada. Por favor não abra dois tópicos para o mesmo assunto, abra somente um e aguarde a resposta.

Faça assim: with ACBrNFe1.EventoNFe.Evento.Add do begin InfEvento.cOrgao := 91; InfEvento.chNFe := infoFat.CDCHAVACESNFE; InfEvento.CNPJ := infoFat.NRCGCCPF; InfEvento.dhEvento := Now; InfEvento.tpEvento := teManifDestCiencia; InfEvento.detEvento.xJust := 'Manifestacao da Operacao'; end; ACBrNFe1.EnviarEventoNFe(idLote); Se mesmo assim ainda der erro, dê mais detalhes, como por exemplo mensagem de erro retornada. Continue no outro tópico: http://www.projetoacbr.com.br/forum/topic/25914-manifestação-destinatário/

A alteração é feita pelo monitor, é normal, ele enviou o comando de configuração para a dll Daruma que grava o valor. Você está utilizando quando versão das DLLs daruma?

A impressora não fiscal está desligada ou você ainda está tentando ativar o ACBrECF

Correto, anexe o XML recebido após a autorização do SAT, precisamos comparar o antes e depois para entender o que o SAT está alterando.

Problemas na instalação do Driver, remova ele desinstalando e reinstale como administrador. Para desinstalar, no gerenciador de dispositivos, clique com o botão direito no dispositivo e clique desinstalar.

Você deve ter alguma arquivo .pas ou .dcu antigo do Fortes em algum lugar do path do seu aplicativo e provavelmente isto está causando o problema. Tente limpar todos os .dcu e verificar nos paths se não tem algum .pas antigos do Fortes, remova e deixe somente os corretos.

Sim no DF em produção não aceita, até já comentei isso anteriormente, não sei se neste tópico ou em outro. Você imprime o QRCode normalmente independente da TAG, isso o componente já faz inclusive.

Este XML é o XML antes de enviar a nota, você precisa salvar o XML após o envio. Talvez seja a forma que você está fazendo, você deve estar enviando e testando somente o retorno de autorizada. O correto é enviar e testar o retorno de autorizada e denegada e salvar o XML em ambos os casos, mas atualizar estoques e todo o resto somente quando autorizada.

Realmente, então deve ser alguma restrição de domínio, seria bom sabermos qual.

Você está passando o que em "Ide.cUF", precisa passar o código IBGE do AM (13 se não estou enganado, ou pode usar o método UFToCUF para converter a string AM para o código).

Ele retorna assim após autorizar o CF-e pelo SAT? Se sim o retorno é do próprio SAT, se não, me passe um passo-a-passo do que está fazendo com os comando enviados para que eu possa entender melhor a situação.

Sim, provavelmente tem algo errado na instalação, uma coisa muito comum é o java ou windows estarem desatualizados.

você pode atualizar os schemas sem problema, como é uma tag opcional, gerar sem ela vai passar na validação de schemas do ACBr e quando a SEFAZ validar novamente em produção não existe a tag, passa normal. Quando eles começarem a cobrar e tornarem a tag obrigatória ai sim eles vão validar e se você não gerar vai ter problemas.

Então, pode ser justamente isso, em um Domínio existem restrições e uma destas restrições deve estar afetando a leitura do certificado, estranho que aqui na empresa eu tenho Domínio e não tenho demora, talvez seja alguma restrição que você tem que não tenho aqui. Ou pode ter a ver com o certificado também, talvez o certificado que você está utilizando esteja precisando de mais direitos de acesso que um certificado normal.

Você fala de qual componente de impressão? DANFe ou DANFCe? Dê mais informações para que possamos lhe ajudar.

O Componente não entra em modo off-line automaticamente, você é que tem que informar a ele. Você deve mudar a NF-e para modo off-line, assim a FormaEmissao é alterada também e tudo funciona a contento: Ide.tpEmis := teOffLine; Ide.dhCont := <data é hora da entrada em contingência>; Ide.xJust := 'sua justificativa para entrar em modo off-line'; Lembre-se que no modo off-line você não envia o XML, salva ele para enviar posteriormente, nestes caso quando for envia, você lê o XML como foi gravado (ACBrNFe1.NotasFiscais.LoadFromFile/LoadFromString) e envia, sem alterar nada. Quanto a impressão você deve imprimir uma via do contribuinte e outra do consumidor, para isso imprima uma, depois antes de imprimir a segunda, marca a opção ViaConsumidor no DANFE e imprima, assim terá as duas vias corretas.

É alguma coisa ai concerteza, pois a maioria dos usuários já migraram para o PLUS e está todo mundo rodando normalmente. Você deve pegar o XML da pasta onde o XML autorizado foi gravado, na pasta logs que você cita provavelmente estão os XMLs ainda não autorizados, se pegar de um XML não autorizado a mensagem vai continuar aparecendo como já havia dito antes. Revise sua rotina e pegue o XML da pasta onde ele está autorizado.