EMBarbosa

Você precisa verificar o motivo do lazarus não conseguir localizar o arquivo. Esse arquivo se encontra na pasta ACBr\Fontes\ACBrDFe\

você usa links simbólicos no Windows pra esse BD específico?

Os componentes não mudam de comportamento quando o SiTef é produção. Na verdade, no caso do TEF, o componente nem sabe quando é produção ou quando é simulação. Sugiro você até comparar os logs nas duas situações para comprovar que esse comportamento está sendo o mesmo. Sendo assim, me parece algum problema na configuração do SiTef. O mais indicado seria, depois de averiguar os logs conforme mencionado acima, acionar o suporte do SiTef.

Isso confirma que que o problema está nos bindings da LibXML2 (isso é o arquivo \Fontes\Terceiros\LibXmlSec\libxml2.pas). Pode ser algo relacionado a arquitetura, como o Rafael mencionou acima. Pode ser alguma incompatibilidade com o Mojave. Seria necessário reabilitar a libXML2, abrir o pacote "ACBrDFeComum.lpk", fazer um build nele e verificar uma possível correção para os erros apresentados. Essa linha desabilita a LibXML2. Então a consequência é que não é possível utilizar a LibXML2.

Não temos ainda certeza do que o governo vai fazer. Precisamos esperar sair a legislação para podermos tomar algum rumo... Por enquanto o que está vigente ainda é o modelo atual.

O arquivo do banco de dados já está sendo usado por outro aplicativo ou talvez pelo seu aplicativo? O arquivo está em rede? Está usando a configuração superserver do Firebird?

Você precisa converter os projetos do Delphi 7 para o Lazarus. Vá em Ferramentas -> Conversão Delphi -> Converter projeto Delphi para lazarus ...

Eu verifiquei o arquivo libxml2.pas e não parece ter algum IFDEF que poderia ter gerado as mensagens de erro. Você poderia tentar desabilitar a dependência da LibXML2 no ACBr.inc? Veja por volta da linha 60 desse arquivo. Talvez assim, você consiga pelo menos fazer a instalação.

Se puder anexar todos os arquivos alterados, podemos analisar as sugestões.

Olá a todos! Devido a alguns usuários necessitarem de mais informações no canhoto do DANFe Retrato, foi criado uma nova propriedade que permite alterar o layout do canhoto: "PosCanhotoLayout". O @hleorj foi o culpado de termos isso implementado. Qual a ideia dessa propriedade? O objetivo de criar essa propriedade foi permitir a impressão do código de barras da chave de acesso no canhoto. Então, a propriedade PosCanhotoLayout tem no momento duas opções: prlPadro : Imprime o canhoto padrão prlBarra : Imprime o canhoto com chave de acesso  Veja as imagens abaixo do novo canhoto. Versão em Fortes Report: Versão em Fast Report:

Não sei se é esse o caso, mas me lembro de que há um limite de caracteres em algumas informações da NF-e e isso não acontece no cadastro das SEFAZ, ou vice-versa.

A imagem não está aparecendo aqui pra mim.

Você quer dizer usar o ACBrBal pra fazer a leitura? Se for isso, acho que o componente foi feito para comunicar diretamente com balanças e não com indicadores de pesagem. Talvez por isso você não está conseguindo fazer funcionar. Acredito que vai ser necessário implementar. Ou pelo menos adaptar uma nova classe para o ACBrBal para fazer a leitura. Você pode tentar verificar o funcionamento de uma das classes. Daí, com o manual explicando a comunicação serial e protocolo pode ser possível fazer alterações para a leitura correta. Talvez você deva configurar pra não ter uma transmissão contínua, ou um modo de transmissão que não acumule os valores.

Olá, Acabei de enviar uma correção pra essa situação na revisão 17393. Ela não foi detectada porque só acontece com as versões do Delphi que não tem TStringHelper. O Lazarus já possui isso. Obrigado por reportar.

No momento, o ACBr continua compatível com o Delphi 7. Você pode continuar baixando da maneira costumeira pelo site do Source Forge ou diretamente pelo SVN (recomendado). Veja: https://www.projetoacbr.com.br/fontes/ Temos um vídeo sobre a instalação:

Esse erro 0x5 se não me engano é "Acesso Negado". Geralmente acontece porque o antivírus (ou algum antimalware) está varrendo a instalação.

No momento, acho que esses relatórios não estão sendo exigidos. Mas aconselho você questionar a SEFAZ da UF que seu aplicativo é/será comercializado.

Olá, acho que você confundiu de tópico. Essa mensagem não tem relação com o que estamos falando nesse tópico. Tem vários tópicos no fórum falando sobre esse assunto. Queira usar a pesquisa ou talvez criar um novo tópico.

Muito obrigado pela contribuição. Me parece que você tem razão. Então, subi as alterações para o SVN na Revisão 17381. Pelo que vi está tudo certo. Queira por favor atualizar, testar e reportar qualquer problema. Mais uma vez obrigado.

Talvez você devesse então usar o QuandoVendeItem do ACBrECF em vez do ACBrECFVirtualSAT, não? Ou talvez, seria ainda melhor passar esse código para sua aplicação ou uma camada exterior... Não acho uma boa prática você usar comandos do ACBrECF dentro de um evento gerado por ele... Talvez. Sinceramente não testei isso porque não foi o assunto levantado no tópico no início e porque nenhuma alteração consciente foi feita nessa parte do código. Eu concordo com você que o comportamento precisa ser consistente. Contudo, discordo que seja uma boa prática chamar o ACBrECF.Subtotal dentro de um evento gerado pelo próprio ACBrECF. Apenas dei uma sugestão que achei simplificaria seu código. De qualquer maneira, você está levantando esse problema agora. Não consta nenhuma alteração nesse sentido e anteriormente não havia nenhuma ciência de qualquer problema relacionado. Para que possamos analisar com todo cuidado que esse tipo de problema merece, peço que, por favor, abra um novo tópico exatamente sobre essa suposta inconsistência do ACBrECF. Este novo tópico deve conter: um passo a passo de como reproduzir a inconsistência, se possível usando o programa de exemplo; descreva os passos descreva o resultado observado descreva o que era esperado Cite quais modelos você testou que apresentam o mesmo problema e quais você testou que não o apresentam; Me acione usando meu nome de usuário juntamente com @

Como mencionei antes e reitero, não estou ciente de nenhuma alteração nessa parte de cálculo de descontos nem de subtotal. Eu entendo esse problema dos arredondamentos. Pra mim não tem nada de confuso. Só acho que você estava fazendo chamadas desnecessárias ao ACBrECF.Subtotal. No caso das ECFs virtuais talvez não tenha problema. Mas em ECFs reais isso gera uma lentidão na venda de itens. Minha sugestão seria fazer apenas uma chamada após o VenderItem. Algo como: ACBrECFVirtualSAT1QuandoVenderItem Prod_Atual.Prod_vSubTotal_Anterior := vSubTotalAtual; vSubTotalAtual := ACBrECF.Subtotal; Prod_Atual.Prod_vTotal_Prod_Atual := vSubTotalAtual - Prod_Atual.Prod_vSubTotal_Anterior; Ahh, agora ficou mais claro com o que você está tendo problemas. Ao chamar o ACBrECF.Subtotal dentro do evento QuandoVenderItem, o retorno não está considerando o desconto já aplicado aos itens.Mesmo assim, não me lembro de nenhuma alteração nesse sentido...

Ninguém é obrigado a atualizar um sistema operacional. A questão é até quando o sistema operacional continuará oferecendo o que você precisa. Por exemplo, imagine que ano que vem surge um novo método de criptografia que vai ser utilizado como padrão da NF-e. Só que ele não pode ser implementado no Windows 7. Como você vai proceder? Desculpe, esse não é o tipo de interação que queremos num fórum. Caso você queira ser informado de respostas no seu tópico por e-mail, você pode alterar suas configurações de preferência de notificações no seu perfil.

O que eu disse inclui programas que contenham o ACBr. Não tenho problema algum. Isso pode ser por vários motivos: aplicação 32 bits tentando acessar dll de 64 bits (alguns componentes do ACBr usa dlls); falta de permissão (rode o aplicativo como administrador); Vírus ou malwares; Mídia corrompida; Erro na instalação do Windows; etc...

Aqui está ok. Veja: -- 26/07 09:42:02:448 AbreDocumento -- 26/07 09:42:02:450 GetEstado estVenda -- 26/07 09:42:02:940 GravaArqINI -- 26/07 09:42:02:942 ClasstoINI -- 26/07 09:42:02:946 GetNumCupom: 000004 -- 26/07 09:42:39:217 VendeItem( 111222333 , TESTE DE PRODUTO , NN , 50 , 2 , 10 , UN , $ , D , -1 ) -- 26/07 09:42:39:219 CarregaTotalizadoresNaoTributados -- 26/07 09:42:39:220 GetEstado estVenda -- 26/07 09:42:39:341 CarregaTotalizadoresNaoTributados -- 26/07 09:42:39:342 GetEstado estVenda -- 26/07 09:42:39:415 GravaArqINI -- 26/07 09:42:39:417 ClasstoINI -- 26/07 09:42:39:420 GetArredonda: -1 -- 26/07 09:43:27:153 GetSubTotal: 90

Realmente, parece ser apenas para o código 2.