Régys Silveira

Testei aqui o troco com EscPOS e FastReport e está tudo normal. Tente passar o valor de troco diretamente ao componente de impressão: ACBrNFeDANFCe1.vTroco ACBrNFeDANFeESCPOS1.vTroco

Outros usuários estão reportando problemas como SVRS também nessa questão de horários, aparentemente tem algo errado por lá, tentou entrar em contato com o suporte deles?

RJ utiliza o SVRS, alguns usuários dos estados que utilizam este webservice tem reportado problemas referentes a horários, talvez fosse interessante entrar em contato com o webservice para verificar com eles como estão as coisas por lá. Não tenho como testar aqui o envio de NFC-e para o RJ pois não tenho certificado daí, só consigo testar aqui em MG e SP é está tudo normal, mas ambos tem webservice próprio.

Werner, estou com o Trunk2 em produção emitindo CT-es normalmente, sem nenhum erro. Poderia passar o exato momento no seu código fonte onde o erro de index é levantado? Você não está tentando utilizar algum número de index que está fora da quantidade de CT-es que você adicionou ao componente?

Isso mesmo, não existe uma forma oficial de saber de antemão se alguém está com problemas na SEFAZ estadual/federal infelizmente. Somente o retorno da nota fiscal denegada pode dizer isso.

Jose, você está enviando de forma sincrona, tente enviar de forma assincrona: NFe.CriarEnviarNFeSEFAZ(cTXTSefaz, nLote, [bImprimeDANFE], [bSincrono], [cImpressora], [bMostrarPreview], [nNumCopias]) Ficaria algo assim: NFe.CriarEnviarNFeSEFAZ(<Seu TXT>, 1, 0, 0) O problema do erro de lote ocorre porque ele tenta consultar o recibo de envio após o envio síncrono, no envio síncrono esse recibo não existe, já estou verificando uma forma de contornar isso, por enquanto teste da forma que lhe passei, por favor. Se ainda não funcionar poste novamente o comando é o log de resultado.

O ACBrNFeMonitor foi descontinuado, agora temos o ACBrMonitorPLUS que engloba todos os monitores antigos, por favor, tente migrar para ele.

Talvez este link lhe ajude: https://regys.com.br/como-instalar-o-trunk2-do-acbr/

Na aba "DF-e", "Webservices", "NFC-e" desmarque a opção: "Adicionar Tag de QRCode em Informações Suplementares", está marcação deve ser utilizada somente quando entrar em produção nos webservices, por agora ela está implementada somente em homologação e alguns nem a implementarão ainda.

Não acho que essa informação estará disponível via consulta do CNPJ pois ela é oriunda de vários fatores, como por exemplo falta de pagamento de imposto por parte do contribuinte, algum problema contábil ou fiscal junto a receita estadual ou federal e por ai vai.

Não precisa reinstalar o ACBr, basta abrir o formulário onde está o componente ACBrDANFEFR mudar algo, salvar e recompilar o aplicativo. Isso ocorre porque com a troca no nome da propriedade o Delphi te avisa que a antiga não existe mais e pergunta se deseja remover, mas para remover efetivamente você precisa salvar o formulário, alterando algo antes para que o delphi aceite e salve.

Qual trunk (1 ou 2) está usando, qual tipo de impressor (Fast ou Fortes)

Essa validação da hora é o servidor que faz, não temos controle sobre ela, o mais correto seria reportar ao suporte do webservice o acontecido e aguardar que eles resolvam o problema.

Você chegou a verificar o ponto que citei do horário, faça o seguinte teste, envie uma nota e marque seu horário, no log de recebimento verifique se está condizente a tag DhRecbto com o horário que você enviou.

doidopb, em qual UF você está?

Quanto ao horário, depende do webservice e não do aplicativo, se o webservice não atualizou a hora ou está em uma zona que possui horário de verão então haverá a diferença. Quantos aos XMLs, tente enviar passando o parâmetro assíncrono como 0: NFe.EnviarNFe(cArqXML,nLote,[bAssina],[bImprime],[cImpressora],[bSincrono]), no seu caso seria o ultimo parâmetro. Uma dica para facilitar, existe o comando criarenviarnfe que faz o mesmo que os dois comandos que você está enviando.

Fiz um teste utilizando o ACBrSAT Demo e enviando os dados conforme seu relato, está funcionando normalmente, teste feito com SAT da TANCA. AD35151008723218000186599000028120000895576993.xml

Bom dia Regys e galera do Fórum! Gostaria de saber sobre a solução deste problema na impressão. Visto que estou com alguns clientes que começam a me cobrar sobre o gasto desnecessário de papel. Obrigado! Como eu disse anteriormente somente para A4 isso ocorre e não é problema como ACBr mas com o motor do Fortes, então você pode escolher utilizar o FastReport ou EsPOS em impressoras não fiscais e não terá problemas de gasto de papel.

Todas as marcas são compatíveis, o SAT possui uma especificação única a qual os fabricantes devem seguir e o componente ACBrSAT trabalha em cima desta especificação. Quanto as impressoras, se você utilizar EscPOS qualquer impressora que suporte o protocolo EscPOS será compatível, se você utilizar impressão via spooler, qualquer impressora que possua um driver spooler também será compatível.

Estranho, porque vários usuários do PLUS que eu acompanho via consultoria já até colocaram em produção ou estão testando sem problemas. Em qual UF está efetuando os testes, lembro que alguns estados ainda não estão totalmente adaptados a nova nota técnica, tanto que ela foi postergada.

TConfig não está nil? Chegou a verificar isso?

Você precisa dar mais informações, o que está tentando fazer, enviar, cancelar, etc, como está fazendo e se possível um xml de exemplo da situação que não funciona.

Provavelmente o servidor de NF-e/NFC-e está com horário errado

Aparentemente é um problema na implementação da validação pelo webservice, fiz alguns testes enviando para o webservice de SP, RJ e AM e está tudo normal. Tentou entrar em contato com o suporte do webservice?

Certo, neste ponto é levantada uma exceção, agora no teu código como você está tratando esta exceção?