Régys Silveira

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.

Esse erro acontece com o Demo ?

Como disse documento legal não existe, mas não existe nada na lei que impeça você imprimir alguma coisa para ter o papel. Agora veja o seguinte, para a fiscalização o documento fiscal e o arquivo XML, tanto da NF-e quanto da carta de correção, quando eles forem fiscalizar eles não vão olhar o papel (DANFE ou outra impressão da CCe) eles vão pedir os arquivos. Eu dei a ideia da impressão somente para que você tenha algo para o cliente, mas a obrigação do teu software e enviar o XML da CC-e assim como o da NF-e e o cliente também tem a obrigação de guardar o XML.

Estes valores são passados por você mesmo na propriedades do componente, basta calcular corretamente e passar os valores corretos que o schema vai validar.

Como eu disse anteriormente não existe um padrão, mas nada impede o programador de criar um próprio e enviar para o cliente ficar ciente, a lei não limita a impressão da carta de correção em nenhum lugar.

Eu acho que vai passar sim, eu tenho 1 cliente que ainda tem ela e ele não reportou nada, agora não sei se pode ter a ver com a versão do firmware, quem sabe em um firmware mais antigo não funcione mesmo, dai seria o caso de tratar a exceção.

Copie as dlls da pasta "\DLLs\OpenSSL" para um dos diretórios que estejam no path do sistema (windows, system32, etc).

Você deve ter arquivos .bpl do ACBr em algum outro lugar do computador ou não compilou os pacotes na sequencia correta. O ideal é sempre compilar estes pacotes antes de qualquer outro e nesta sequência: ACBrComum, ACBrDiversos, ACBrSerial.

Você deve ter esquecido de apagar os .bpl que são gerados. Você precisa apagar todos os .bpl do ACBr, esse erro ocorreu porque o pacote ACBrComum está numa versão antiga.

Ruby é muito bom, e é uma mãe para programar. PHP é o mais usado para esse tipo de aplicativo, juntamente com JavaScript. O problema maior seria se você for trabalhar com Paf-ECF, pois ele tem como requisito trabalhar off-line, no HTML5 isso seria facilmente resolvido, mas como ele ainda não está totalmente aceitado seria complicado fazer algo nele agora, mas já poderia ser feito pensando.