EMBarbosa

Olá... vou responder suas mensagens em ordem cronológica. Mesmo que não sejam as dúvidas atuais, podem ajudar outras pessoas no futuro ou te dar alguma ideia... Se estiver usando um conversor USB/serial, ou emulador USB/serial, geralmente esse problema é levantado por um driver defeituoso. Você pode ver isso no seguinte tópico: Também já vi ocorrer quando há problema no cabo ou conectores. Esses são os problemas mais comuns. --- Esse erro, como você pode imaginar, é porque algum programa já está acessando a porta (possivelmente o Hercules). Só um aplicativo pode ter acesso a uma porta serial por vez. Quando o segundo aplicativo "pede" o acesso à porta, o sistema operacional (nesse caso o Windows) retorna esse erro informando que o acesso foi negado. ---- Mais uma vez, geralmente isso indica problema no driver, dispositivo conversor USB/Serial como na resposta do Rubinho aqui: --- Isso é o esperado... "Monitorar a Balança" é um sistema de fazer a leitura automaticamente. É útil em alguns casos onde a aplicação quer fazer vários pesos seguidos, mas prefere delegar ao componente essas leituras. Se "Monitorar a Balança" não estiver habilitado o ACBrBal só faz a leitura de peso via o comando "LerPeso". Esse comando envia uma solicitação de peso para a Balança(caso necessário), lê e depois interpreta o retorno. ----- Esses comandos são de "limpeza" da comunicação com a porta serial. Documentação: -> IOCTL_SERIAL_PURGE -> IOCTL_SERIAL_CLR_RTS -> IOCTL_SERIAL_CLR_DTR Apesar de ser um pouco baixo nível, não deveriam causar nenhum problema na comunicação. Na verdade, para comunicação serial usamos a Synapse. A Synapse, (e por conseguinte nosso código), nem vai a tão baixo nível assim já que faz chamadas a API do Windows. Então, se esse tipo de mensagem gerasse algum problema, nós teríamos vários relatos sobre isso com todo tipo de balança que suportamos e não somente com a Urano POP S. Tente utilizar outros dispositivos conversão USB/Serial. Eles costumam ser muito baratos e talvez o problema seja justamente esse. Infelizmente, a maioria desses dispositivos no mercado não são tão confiáveis. Se houvesse detectado outras comunicações ou envio de bytes diferentes. Talvez poderíamos atribuir ao ACBr o problema. Mas não parece ser o caso.

Acabamos de ter a confirmação desse problema pela Receita: https://www.nfe.fazenda.gov.br/portal/informe.aspx?ehCTG=false&Informe=MIrogWJTf2w=

Remova os arquivos antigos e duplicados do Fast Report. Daí, reinstale o Fast Report. Faça o mesmo com o ACBr. Remova os arquivos antigos do ACBr e também os duplicados. Daí, reinstale o ACBr.

Essa mensagem indica que a Unit ACBrNFeDANFEFR que você está utilizando foi compilada com outra versão do Fast Report. Tem algumas informação no StackOverflow sobre o assunto. Mesmo que você tenha instalado essa mesma versão nos dois delphis, se os compiladores usados são diferentes, o erro vai acontecer. Veja na sua própria imagem: Os arquivos são diferentes mesmo comparando para mesma plataforma (veja os tamanhos). Então se o Delphi se confundir (talvez pelas configurações do LibPath, search path, etc...), vai gerar esse erro. Você precisa garantir que o Delphi vai acessar apenas uma versão de units. Isso é válido tanto para o Fast Report, como o ACBr.

Tentou enviar outra mensagem? Por exemplo uma mensagem vazia?

Bom dia. Não existe. Há muito tempo o pessoal tinha desenvolvido um validador para o PAF-ECF, mas acho que ele não foi atualizado pro PAF-NFC-e. Nós do Projeto ACBr não temos acesso ao código fonte, então também não podemos atualizar. Por outro lado, não é muito difícil validar seguindo a documentação. É basicamente seguir o tamanho e o tipo dos campos. Só isso.

Por favor, verifique se existe alguma alteração local nos seus arquivos ACBr/Fast Report. Veja também se está com a última versão do ACBrInstall. Se for o caso, baixe os arquivos do ACBr novamente. A unit ToolsAPI é do Delphi. Teoricamente, não teria motivos para ela não ser localizada.

Atualize os fontes novamente por favor. O nosso amigo @Victor H. Gonzales - Panda enviou uma correção para o SVN.

Pode ser uma incompatibilidade com essa versão que ainda não foi detectada. Pode verificar qual versão dos pacotes ela instala? No Delphi 12, vá no menu Component -> Install Packages Na lista Design packages, localize os pacotes FastReport e clique em um deles (por exemplo "FastReport XX Components") Veja qual a versão está no nome do arquivo do pacote, como na imagem abaixo:

Por favor, anexe o log completo da instalação que deu esse erro.

@CrasH, @Tiago Domingues Carneiro, @Dor_poa, e outros Subi no SVN uma correção. Deve estar tudo ok agora.

Olá pessoal!! Uma nova versão dessa Nota Técnica (NT 2023.001 - v1.50) foi publicada em 01/11/2023. Alterações Apenas data de implantação da Regra de Validação LA18 foi alterada. Relembrando essa regra visa obrigar o preenchimento do grupo de origem do combustível (tag: origComb). Datas de Implantação Implantação Homologação: Implementação futura Implantação Produção: Implementação futura E como fica o ACBr e você? No momento isso significa que temos pelo menos até a nova publicação de uma nova NT para nos preocupar com essa regra.

Recebemos relatos de falhas ao emitir NFC-e e NFe em MG. Parece estar relacionado ao seguinte informativo da Sefaz de MG. Ela informa sobre instabilidade desde o dia 30/10... Mensagem ainda está on-line no site http://www.fazenda.mg.gov.br/ Veja abaixo a mensagem deles: A instabilidade afetou o site "sped" que agrega as informações sobre os documentos fiscais eletrônicos: https://www.sped.fazenda.mg.gov.br/

Muito obrigado pela contribuição. Fiz a implementação baseada nela. Subi as alterações para o SVN na Revisão 31108 Pelo que vi está tudo certo. Queira por favor atualizar, testar e reportar qualquer problema. Mais uma vez obrigado.

Muito obrigado pela contribuição. Fiz a implementação baseada nela. Subi as alterações para o SVN na Revisão 31107. Pelo que vi está tudo certo. Queira por favor atualizar, testar e reportar qualquer problema. Mais uma vez obrigado.

Muito obrigado pela contribuição. Fiz a implementação baseada nela. Pelo que vi está tudo certo. Queira por favor atualizar, testar e reportar qualquer problema. Mais uma vez obrigado.

Muito obrigado pela contribuição. Fiz a implementação baseada nela. Queira por favor atualizar, testar e reportar qualquer problema. Mais uma vez obrigado.

Foi publicada uma nova versão do Guia Prático da EFD ICMS IPI. As alterações, em resumo, estão logo abaixo. Como poderão ver, devemos ter que alterar o componente ACBrSPEDFiscal para inclusão de alguns registros. Ficaremos felizes com o apoio de todos que puderem nos ajudar com contribuições. Fonte: http://sped.rfb.gov.br/pagina/show/7275

Olá, bom dia. Parece que é a DLL que está repetindo o pedido de código do produto no loop. Veja: Os dados estão sendo preenchidos corretamente? Por exemplo, no manual deles não tem algum requisito para esse campo? Outra possibilidade, houve alguma mudança recente no fluxo da clientSitef ou desse módulo específico que precise ser implementada no componente?

Muito obrigado pela contribuição Já foi adicionado no nosso backlog (TK-4441). Assim que possível daremos um retorno.

Oi Clóvis, bom dia. Esses logs indicam que o ACBr foi instalado corretamente. Essa é a boa notícia. A má notícia é que o erro que você apresentou não é de instalação. Esse erro: Geralmente isso significa que o compilador está encontrando arquivos dcu ou pas de versões diferentes e/ou não consegue recompilar os mesmos. Isso pode ser por vários motivos: Seu path do Windows pode estar incluindo pastas que são de Delphis diferentes Tem várias cópias do ACBr na máquina Tem várias cópias do código fonte da synapse na máquina Em qualquer uma das situações acima, o Delphi encontrou uma "Synautil"(.dcu ou .pas) uma vez (na hora de compilar o dcu da unit ACBrUtil.Math), mas depois (na hora de montar o exe) está encontrando outra "Synautil". A única opção que você tem é localizar essas units Synautil que estão repetidas e remover elas. Daí reinstalar o ACBr e aí tentar recompilar o demo. Antes disso, faça questão de localizar no seu computador a pasta de BPLs de todos as versões Delphi que tem instalada e apagar qualquer bpl do ACBr ou Synapse que esteja lá. Elas geralmente ficam na pasta: C:\Users\Public\Documents\Embarcadero\Studio\<versao>\Bpl Onde <versao> deve ser uma versão instalada. Por exemplo o Delphi Alexandria é 22.0, ficando: C:\Users\Public\Documents\Embarcadero\Studio\22.0\Bpl Verifique todas as pastas BPL que tiver. Atualmente, nenhuma BPL do ACBr deve ficar nessas pastas.

Não... pelo menos ainda não... Eles só atualizam depois ou bem próximo do lançamento. Eu não tive acesso a essa versão ainda então não posso afirmar com certeza o que aconteceu. Mas geralmente pede-se para instalar uma versão beta em outra máquina justamente por conta de conflitos com as instalações anteriores. Oi @Paulo Alexandre Hostertpela mensagem de erro, o mais certo é que a instalação do Delphi 12 tenha "bagunçado" a detecção de versões instaladas. Olhando no código fonte, mesmo considerando o código da JCL eu não consegui encontrar exatamente onde no código o problema é levantado. Mas acredito que consegui fazer uma alteração que vai proporcionar ao instalador continuar mesmo quando o erro for levantado. Assim que fizer mais testes, subo a versão e aviso aqui no tópico. Mas até lá, ou até nós termos o ACBrInstall compatível, talvez o melhor seja desinstalar essa versão do Delphi nessa máquina e instalar ela em outra. Ou talvez instalar o ACBr em uma outra máquina ou numa máquina virtual. É claro, você sempre tem a opção de instalar o ACBr manualmente, pacote por pacote.... mas não recomendamos isso. É muito trabalhoso.

É isso mesmo. Usando o Fortes, não há comando de corte (guilhotina) visto que não há esse comando via spool. O que pode ser verificado é se o driver da impressora implementa isso. Daí você acionaria no driver, nas configurações do dispositivo (impressora). Como vias, não... teria que imprimir duas vezes mesmo. Mas se o corte é importante, talvez seja melhor usar o modelo ESC/POS

Sim...

Muito obrigado pela contribuição. Fiz a implementação baseada nela. Subi as alterações para o SVN na Revisão 30270. Me parece correto. Mas fiquei na dúvida se em algum caso a balança poderia retornar a TARA e o peso. Nesse caso, me parece que o componente não conseguirá fazer a leitura com o código implementado. Queira por favor atualizar, testar e reportar qualquer problema.