EMBarbosa

Sim. Na verdade isso é uma característica, da maioria dos ECF da Bematech. De pendendo da situação, se você envia um finalizar cupom o ECF fecha com o restante de pagamento como dinheiro.

Você pode usar os programas do fabricante para testar o corte. Se não estiver cortando nem mesmo com eles, é possível que seja um defeito e precise de assistência técnica.

Boa tarde Marcos, apesar de estar liberado esse 08 e ele não estar no cálculo publicado, o resto continua o mesmo. Assim, é possível validar com o mesmo algoritmo desde que você o atualize para aceitar esse segundo caractere como "8". Foi o que fizemos com o ACBrValidador. Ele agora já está funcional.

Boa tarde Higor, Obrigado pelo relato. A nossa decisão é fazer uma correção temporária, mas também avisar a SEFAZ. O erro é da própria SEFAZ, mas entendemos que possa estar causando transtorno em vários casos. O que acontece é que a SEFAZ está retornando um XML "não canonicalizado". Isso, pela regras deles mesmo está errado (vide o item 3.2.1.1 no "MOC - Visão Geral" ). Conforme pode ser confirmado pelo link acima: Por isso, incentivamos a todos que passarem por esse problema a contatar a sua Sefaz e relatar para que eles possam corrigir. Vamos tentar fazer isso também, mas quanto maior o número de pessoas relatando, maior a probabilidade deles agirem rapidamente e levarem mais a sério as regras que eles mesmos definiram. O nosso consultor @Italo Jurisato Junior já está analisando a correção temporária e logo enviará ao SVN.

Bruno, chegou a verificar o manual do Sitef? Ou talvez enviar uma pergunta pra certificadora?

Tópico fechado por falta de retorno do usuário

Um usuário confirmou a situação com a própria Sefaz do DF no seguinte tópico: Então estou fechando esse tópico que trata apenas do ACBrValidador.

No caso da denegação realmente não tem muito o que fazer a não ser esperar. Mas foi por se tratar do problema com mesma base que eu "linkei" o outro tópico. Nele chegamos a conclusão que essa alteração no CF/DF tinha sido recente e provavelmente estava causando problemas. Ainda não tínhamos certeza que o próprio Ambiente nacional e Sefaz estavam com problemas, então obrigado por compartilhar a resposta da Sefaz do DF.

Conforme o que o BigWings disse: Nesse caso, seria necessário implementar essa nova ou novas propriedades na classe para poder tratar essa situação, lembrando de manter o comportamento atual como padrão.

Talvez esteja relacionado a esse tópico. Vejam:

Por favor, além do mencionado acima, queiram ver o seguinte post.

Boa tarde Lowry e rdrtecnologia. Agradecemos o report. Eu consultei os cadastros do sintegra, o do próprio DF e o CCC. Parece que está certo mesmo. Estou enviando a alteração. Isso provavelmente é recente. Tivemos relatos similar sobre esse cadastro CF/DF não ser compatível com IE. Mas no caso, a empresa não era contribuinte de ICMS. Pelo visto, até então, o DF separava os contribuintes pelo código. Agora isso não acontece mais. Informando melhor, o CF/DF é um cadastro único tanto de ICMS como de ISS. Isso acontece porque o DF é uma cidade e também uma UF. Mas como não é chamado de "estado", o DF não tem IE e sim esse CF/DF. Esse é o mesmo cadastro que nos outros munincípios é chamado de Inscrição Municipal. Então a pessoa/empresa pode ser contribuinte de ICMS ou não; de ISS ou não e ela vai ser cadastrada no mesmo lugar. A questão que precisamos ficar atentos agora é que, se o camarada é do DF, não dá pra ter certeza pela IE (ou melhor dizendo CF/DF) se a empresa é contribuinte ou não do ICMS. Então se não tomarmos cuidado com o software, poderá acontecer de se fazer um cadastro e emissões incorretas. Muito obrigado pela contribuição. Fiz a implementação baseada nela. Subi as alterações para o SVN na Revisão 20645. Pelo que vi está tudo certo. Queiram por favor atualizar, testar e reportar qualquer problema. Mais uma vez obrigado.

Olá Obrigado pela análise. Realmente existe essa limitação na função. Na minha opinião, não seria interessante, porque vai incluir uma responsabilidade que não pertence a essa função. O certo seria tratar o nome do produto antes de enviar ao componente. Mas vamos aguardar outros desenvolvedores do ACBr pra ver se concordam com isso.

Oi Gumercindo. O código é muito complexo pra eu conseguir analisar. Eu até tentei olhar aqui, mas não tem como fazer isso com pouco tempo e sem o restante do seu software. De qualquer maneira, eu sugiro você tentar outra abordagem. Ao invés de tentar comparar as duas. Veja onde a sua falha e tende descobrir a partir daí. No link que te passei, menciona que um motivo dessa mensagem é a tentativa de destruição de um handle que foi alocado por uma thread diferente. Então uma opção interessante seria você descobrir qual handle estava sendo destruído na hora que o erro foi levantado. A partir daí, você pode tentar encontrar onde ele está sendo criado. Outra opção é você tentar reduzir o código a um programa mínimo que reproduza o problema. Vá removendo código do programa até que consiga isolar o problema com o mínimo de código possível. É o mesmo princípio usado na Stack Overflow.

Dei uma olhada por alto na sua thread e estou levando em conta que você já a utiliza há algum tempo sem nenhum ou maiores problemas. O código que você anexou é apenas parte da implementação, porque essa unit faz uso extenso de outras que não faço ideia de como estão implementadas. Não tem afirmar nada sem um código completo. Mas notei alguns pontos sensíveis que podem levar a um problema maior depois. Por exemplo: Você cria um componente de query na thread, mas todos os outros já estão criados num DataModule(DM.conGestor, DM.transGestor, etc..). Geralmente a thread deve ter sua própria conexão com o BD. Isso acontece porque os componentes da VCL de modo geral não são threadsafe. Você faz acesso direto a forms sem o controle do syncrhonize. Por exemplo na configuração do componente ACBrNFSe1 que está em um form fora da thread. Sem um mecanismo de lock, isso pode gerar problemas. Outro exemplo do acima é que o form que cria a thread é acessado pela thread de modo direto. Isso pode gerar problemas. Em via de regra, thread só pode acessar qualquer coisa que esteja na interface com o usuário via método syncrhonize.

Não é um arquivo. Os dados que vem de resposta no socket ou porta é em formato de arquivo ini. Então sua leitura dos sockets não está implementada corretamente. Sugerimos você seguir a sugestão do Daniel acima: Nesse caso, você deve usar troca de arquivos e não socket. Daí vai ter arquivo de envio e retorno.

Precisamos de um passo a passo pra poder reproduzir o problema. No entanto, não creio que seja um problema no componente. Até onde me lembro o componente não gera "handles" de janelas. E esse parece ser justamente o seu problema. Sua thread está criando handles, mas é a thread da VCL que está tentando destruir. Encontrei essa resposta no StackOverflow. Creio que entender o princípio por trás da resposta pode te ajudar. Em especial, essa parte:

Bom dia sinval.gedolin. O Big Wings respondeu acima, que é pegando o retorno do comando de "Distribuição DFe" do ACBrMonitor. Veja: Se você está trabalhando com sockets, não vai ser diferente do modo de trabalho por arquivos. A mesma resposta gerada no arquivo de retorno é dada no socket. Então do lado da sua aplicação, você precisa garantir que o envio de comandos e o recebimento da resposta (escrita e a leitura no socket) sejam feitas corretamente. O que você vai encontrar no socket é um arquivo ini como esse que está nesse link da documentação acima. O vídeo indicado, é apenas um da série que explica sobre a distribuição. Veja os outros aqui: https://www.projetoacbr.com.br/forum/video/browse/37-aula-24-distribuicao-dfe/ Mais uma vez, a comunicação por socket ou arquivos é basicamente a mesma coisa. As respostas são as mesmas. Nesses outros vídeos aqui, há uma explicação sobre a comunicação socket TCP/IP.

Não conheço esse aplicativo, mas dependendo do Banco de dados existem outras ferramentas.

Verdade. É importante fazer um teste com cancelamentos e também descontos e acréscimos nos itens para garantir que o seu Subtotal está funcionando igual ao do ECF.

Eu não tenho muito conhecimento do ACBrSMS, mas um motivo em que isso acontece é quando existe o aplicativo da operadora do chip baixando as mensagens. Geralmente esse aplicativo baixa e apaga as mensagens do modem.

Boa tarde renemelo. Sempre que alguém reclama de lentidão minha recomendação primária é medir. É importante você saber exatamente onde está a lentidão. Use um profiler e descubra exatamente onde está a lentidão no seu processo. Depois de saber onde está a lentidão, resolver o problema se torna coisa muito mais fácil. Talvez até de segundos. Se você está enviando e-mails repetidos, não teria sentido carregar o HTML e anexos para cada e-mail. Mas mesmo que você não esteja enviando e-mails repetidos, talvez possa destruir e reconstruir o componente para cada lista de e-mails e não para cada e-mail. Não parece muita coisa, mas sem medir onde está a lentidão, não dá pra ter certeza onde você precisa otimizar.

É impossível representar corretamente os valores ponto flutuante numa memória finita. Pense bem, existem infinitos números entre 0,5 e 0,6. Existem infinitos números entre 0,51 e 0,52. E assim por diante. Para que seja possível representar os números é feito uma aproximação. Então quando você vê o número, na verdade está vendo uma aproximação. Assim 0,5 na verdade é 0,49999999999789. Isso não é um problema do Delphi em si. Toda linguagem de programação tem essa limitação de uma forma ou de outra. Uma explicação mais detalhada está no artigo científico: "What Every Computer Scientist Should Know About Floating-Point Arithmetic" disponível nesse link abaixo https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html

Você não anexou os logs do componente nem as mensagens de erro para analisarmos.

Apenas para registro, não consegui reproduzir esse problema. Não parece ser no componente. Mas notei o seguinte destacado em negrito na mensagem: Como se pode ver, apesar de estarmos falando de importação pelo componente do SPED Fiscal, o componente citado no código parece ser o do PIS/COFINS (SpedContribuicao). Assim, é possível que o erro seja apenas a troca dos componentes nessa linha específica.