Régys Silveira

Pelo meu entendimento sim.

Concordo

Eu utilizo o FastReport aqui na empresa em produção e não dá erro. Você dever ter duas instâncias do componente abertas ao mesmo tempo como o Kiko postou.

André seria mesmo o máximo de 999.99 eu conferi aqui, por isso que mandei essa validação para o rapaz ai, o problema não é aquele campo não são outros.

Fiz uma validação do XML enviado, utilizando o site: http://www.sefaz.rs.gov.br/nfe/nfe-val.aspx e os erros reportados foram outros: Schema XML: Nenhum erro encontrado NF-e 35120347946074000189550010000020971135687027 Regras de Negócio [Ambiente de Homologação (Testes)] 8 erros de validação 291 - [simulacao] Rejeicao: Certificado Assinatura Data Validade 295 - [simulacao] Rejeicao: Certificado Assinatura difere ICP-Brasil 531 - [simulacao] Rejeicao: Total da BC ICMS difere do somatorio dos itens 532 - [simulacao] Rejeicao: Total do ICMS difere do somatorio dos itens 533 - [simulacao] Rejeicao: Total da BC ICMS-ST difere do somatorio dos itens 534 - [simulacao] Rejeicao: Total do ICMS-ST difere do somatorio dos itens 610 - [simulacao] Rejeicao: Total da NF difere do somatorio dos Valores compoe o valor Total da NF. 245 - [simulacao] Rejeicao: CNPJ Emitente nao cadastrado

O problema está nos valores que você está passando. Os registros 60A tem que somar e bater com o valor informado no 60M não é algo no ACBr e algo ai no teu app na hora de passar os valores, ou você não gravou tudo corretamente. Lembrando que o 60A são as aliquotas da Redução Z, a soma delas tem bater com o valor da venda bruta informado no 60M.

O NCM é obrigatório e é validado pelo schema XML, tentou colocar '99' no NCM?

Quando pergunto o tipo, estou falando de DANFE FastReport, Rave, etc. Qual o tipo que você utiliza?

Não, é porque a soma dos registros 60A não bate com o valor informado no 60M.

Qual o tipo de DANFE que você utiliza? esse cdsIdentificacao é um ClientDataset utilizado pelo DANFE.

O registro 50 são notas de entrada ou saída, o sintegra sabe qual a operação pelo CFOP informado, isso ai foi um aviso ou realmente um erro, eu sempre vi isso ai como aviso, e avisos não impedem de entregar o arquivo. Esse erro acontece quando tem uma nota de entrada geralmente emitida pela própria empresa, dai o CNPJ fica igual ao informado no registro 10 que são os dados da empresa.

Teria como postar um XML que dá este erro para analisarmos?

É o que mensagem diz mesmo, você adicionou o registro 75 sem ter um correspondente em algum outro registro do arquivo, o 75 é o cadastro de mercadorias, os registros dele só devem existem se algum outro registro 54,57,60D,60I,60R,74,77,86 exista.

Nestes 6 meses várias outras coisas foram acertadas, tente atualizar e verificar.

Tentou reinstalar a capicom que vem junto com o ACBr?

O item em questão é especifico para bares e restaurantes se você não trabalha com isso não precisa implementar.

Você deu uma olhada nos fontes? Os comandos utilizados são comandos AT padrão, sendo que as classes só fazem o que é estritamente da empresa, o componente funciona para qualquer modem do mercado hoje inclusive o 3G, veja que neste tópico aqui do fórum praticamente todos os colegas utilizam modens 3G.

O Windows está atualizado com pelo menos o service pack 3? Você instalou a nova cadeia de certificados? Não existem nenhum firewall ou antivírus bloqueando o aplicativo? Foram feitas alguns acerto no ACBrNFeMonitor, você já tentou recompilar e atualizar?

Se mais usuários assinassem o ACBrSAC poderíamos ter mais melhorias e mais componentes para outras situações, os poucos assinantes que já estão inscritos já tem rendido frutos.

Pode-se tomar como base o projeto da nota eletrônica na parte de troca de certificados.

Não me entenda mal, eu uso bastante o projeto, tenho clientes que preferem baixar a pedir o XML, tenho outros que simplesmente nem querem saber disso e outros piores que acham que o DANFE é nota, inclusive alguns destes últimos são contadores formados e com empresas já no mercado a bastante tempo. Só quis expor o que penso da situação, aqui sempre tenho tentado trabalhar com meus quase 400 clientes os riscos de baixar o XML, os problemas advindos disso o que eles ganham e o que eles perdem, mas os danados insistem . Eu penso que o problema não vai acontecer agora mas no futuro, a NF-e é uma bomba relógio como já foi dito pelo Roberto Dias Duarte em seus artigos, muitas pessoas estão emitindo notas indiscriminadamente, sem entender de tributação sem saber como agir nas diversas situações e também o que fazer com tais documentos eletrônicos. Ainda acho que no futuro quando a SEFAZ resolver fiscalizar ao pé da letra, muita coisa vai acontecer e a bomba vai ser grande, e infelizmente eu acho que vai estourar uma boa parte na mão das software houses.

Pessoal, Primeiro, a página não foi criptografada, somente alguns campos e que passaram a ser mostrados como imagem ao invés de texto, isso não passa nem perto de criptografia, nem de longe. Segundo, não seria a hora de aproveitar a oportunidade e ajudar nosso cliente a passar a fazer a coisa corretamente? Vejam, isso vai ser uma guerra interminável, onde o SEFAZ altera e o pessoal corre atrás, e não é algo correto, visto que o XML gerado não tem validade alguma e é obrigação do cliente guardar o documento fiscal, no caso o XML validado e gerado, ou seja, esse XML gerado só vai causar problema ao cliente e por consequência a software house. Concordo que facilita e muito a vida do usuário, mas quanto mais insistimos em manter esse "quebra galho" mas nos engalfinhamos e ficamos dependentes disso e o cliente por consequência, imagem quando o fisco começar a fiscalizar realmente, vai todo mundo estar com XMLs inválidos guardados, que não servem como documento fiscal e a culpa vai cair em quem? É claro que no software que "facilitou" a vida do usuário. Coisas assim já aconteceram no passado, lembro aqui em MG do SAPI, chegou a um ponto que o pessoal da SEFAZ criptografou de verdade usando algoritmos de criptografia real cada registro das tabelas do banco de dados, e no final quem perdeu foram os softwares, porque? porque facilitou a vida do usuário utilizando de formas "erradas" para "facilitar" a vida do usuário. Penso que o caminho e conscientizar o cliente e não ficar fazendo tudo do jeitinho brasileiro, esse jeitinho infelizmente estraga tudo, quanto mais tentarmos burlar a forma disponibilizada pelo fisco menos eles vão querer ajudar realmente a nós programadores, imagino que se não usássemos desses meios o fisco pela pressão dos órgãos responsáveis e também dos usuários já teria disponibilizado uma forma mais organizada. Desculpem pelo desabafo, eu sei que algumas pessoas podem ficar chateadas com o que escrevi, mas como eu disse, penso que o caminho e trabalharmos juntos, nós e o fisco e não nós contra eles, porque sempre no final quem perde somos nós, nada custa para eles fazerem uma lei e passar a bloquear pelos próprios servidores da receita estadual e federal os acessos de software que estão fazendo isso.

Poste o log, assim podemos ver como você está enviando os comando, mas ainda insisto que isso e alguma coisa na tua rotina de impressão, talvez um erro não tratado ou algo que force a rotina a tentar reimprimir o cupom.

Então, isso parece ser um problema na tua rotina de impressão, tente gravar um log e poste aqui para visualizarmos o que está acontecendo. Isso acontece com frequência?

O ACBrECF vai fazer somente o que você pedir a ele, tem certeza que a sua rotina de impressão da venda para o cupom fiscal não tem algum problema? O segundo cupom é idêntico ao primeiro, explique melhor o problema.