EMBarbosa

Olá. Por favor, verifique o seguinte: Se o seu Windows tem a pasta SysWow64, então é justamente o contrário... as dlls em 64 bits vão pra System 32 e as x86 vão pra SysWOW64. Se o seu programa está sendo compilado em 32 você deve colocar a x86. Caso seu programa seja 64 bits então deve colocar as x64.

Foram colocados 3 arquivos no outro tópico. Com qual dos arquivos você está tendo problemas?

Olá Celso. Acho que o pessoal da SgaPetro com quem você conversou está mal informado. O Registro C850 já existe em nosso componente ACBrSPEDFiscal pelo menos desde janeiro de 2015.

Bom dia, Após conversa com o pessoal aqui, nos pareceu muito boa sua sugestão. Queremos subir ao SVN. Verifique por favor o seguinte: Apesar da propriedade ImprimeDescAcrescItem estar marcada como default idaiSempre, ela deve ser atribuída no método Create (Veja a nota na documentação). Após isso queira por favor anexar novamente os arquivos alterados.

Mas até onde me consta, você pode declarar funções de dlls no VBA e chamar sem o arquivo TLB. Basta você utilizar o 'Declare'. Veja essa documentação do VBA no Excel: https://docs.microsoft.com/pt-br/office/client-developer/excel/how-to-access-dlls-in-excel

É possível anexar um xml e descrever um passo a passo para verificar mais a fundo? Notei que o método HTMLStringReplace o que foi alterado é mudar de ReplaceString para StringReplace e executar ele em partes da string por vez... Só que ele não está fazendo os casts originais... Acho que isso pode explicar seu ganho de performance. Mas pode acarretar outros problemas. Antes... ReplaceString(AnsiString(S), AnsiString(OldPatern), AnsiString(ACBrStr(NewPattern))) Agora StringReplace(wSL[w], OldPattern, NewPattern, Flags);

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

Será que não está usando o CommitRetaining? Isso poderia explicar manter a conexão.

Oi Ricardo, Subi as alterações para o SVN na Revisão 17770. 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 17769. Pelo que vi está tudo certo. Queira por favor atualizar, testar e reportar qualquer problema. Mais uma vez obrigado. Gostaria apenas de comentar sobre a imagem: Acredito que se alterar o número de casas decimais mostradas nos valores unitários e totais, reduzindo de 4 para 2, também vai permitir um valor maior ser mostrado.

Olá, Eu não tenho trabalhado com esses componentes do Lazarus, mas acredito que não seja necessário você executar um Connection.Close depois de executar o Commit. Pelo menos em teoria, o Commit deveria fechar a transação e qualquer comunicação com o BD. Assim, apenas isso deveria bastar. Da mesma maneira não deveria ser necessário você executar o close antes de carregar um DBgrid.

Você tentou com o protocolo "balança genérica"? Poderia anexar o log do componente?

Mesmo depois de instalar o "Fortes CE" você precisa reinstalar o ACBr e marcar os componentes do Fortes.

Talvez a pergunta certa seja: Por quê você precisa de um arquivo .TLB para a ACBrLib?

Se remover o "s" do "https" fez voltar a funcionar, é provável que o problema sejam as dlls conforme explicado anteriormente.

Pode ser que o protocolo de comunicação esteja incorreto. Chegou a alterar os protocolos pra ver?

Eu não tenho certeza se isso interfere no comportamento. A questão é que se o gerenciador não retornar o valor, não tem como o componente pegar. Por mais frustrante que pareça ser, isso geralmente é resolvido pela certificadora. Então é preciso ter certeza que o gerenciador (mesmo que seja simulador) está retornando o valor. Talvez analisando os logs dele, o pessoal da certificadora consiga explicar o que está acontecendo.

Tentou o contato com a Software Express/SkyTef/Certificadora? Eles geralmente respondem rápido esse tipo de questão.

Olá, Para quem utiliza o ACBrMonitorPLUS, as margens dos documentos fiscais eletrônicos podem ser configuradas em um único local, sendo válidas para todos os Formulários (NFe, CTe, MDFe, GNRe). Com as padronizações realizadas, o que muda é a definição de margens de Centímetros para Milímetros, sendo assim basta multiplicar as configurações já existentes por 10. ex: Antes - Margem Inferior: 0,70 Margem Superior: 0,70 Margem Direita: 0,50 Margem Esquerda: 0,50 ex: Depois- Margem Inferior: 7,00 Margem Superior: 7,00 Margem Direita: 5,00 Margem Esquerda: 5,00 Veja onde configurar: Para o cupom SAT e NFCe tipo (Bobina) não será necessário alterações nas configurações já existentes. Estas alteração precisam ser realizadas a partir da versão: 1.3.0.140

Oi @Andremomb Desculpe, eu acabei me confundindo. Estávamos numa conversa sobre MDe, e aqui você falou do MF-e, eu acabei juntando tudo e passando o link para o MDF-e. A documentação do MF-e está no site da SEFAZ do Ceará. http://cfe.sefaz.ce.gov.br/mfe/informacoes/legislacao-estadual#/ Ali, você vai encontrar downloads de informações e manuais, legislação, e etc... Voltando ao campo Esse campo é de informações do Fisco. Quer dizer que ele vai ser preenchido pelo aparelho MF-e. Isso talvez explique o porque não apareceu no cupom. Veja esse tópico:

Tente o Manual de Orientação ao Contribuinte (MOC). O portal da Sefaz virtual do RS, costuma ter um MOC mais atualizado. Veja https://dfe-portal.svrs.rs.gov.br/Nfe/Documentos

Algumas impressoras possuem várias fontes e você pode trocar a fonte via protocolo. Geralmente pelo menos uma delas possui acentuação básica como algum subconjunto de ASCII. Aí você pode pegar o manual da linguagem e da impressora e tentar, mas nossa experiência é que geralmente não funciona ou funciona muito precariamente. Pode verificar nesse link os manuais que temos e no site do fabricante os manuais da sua. https://svn.code.sf.net/p/acbr/code/tools/Etiqueta

Olá pessoal, Sei que todos estão muito atarefados com seus programas por aí... Maaaasssss.... Precisamos de sua atenção para uma alteração nos componentes!!! Atualmente temos uma falta de padronização nas unidades de medidas das margens das impressões dos documentos fiscais. Cada impressão Report tem margens medidas com um formato. Isso não está bom. Note a tabela a seguir com as unidades de medidas das margens atual: DF-e Fortes Fast LazReport ESCPOS NF-e (Paisagem, Retrato, Inut, Evento, Simplificado) cm cm nd X NFC-e mm mm X X NFC-e (A4) cm mm X X SAT mm X X X CT-e (Evento) cm nd X X CT-e (A5, Retrato) nd nd X X CT-e (Inut, Inut Retrato) nd nd X X GNR-e nd nd nd X MDF-e (Retrato, Evento) cm nd X X NFS-e cm nd X X BP-e X X X X Legenda: mm – milímetros cm – centímetros nd – O componente poderia, mas não está atualizando as margens do report X – Não possui impressão nesse formato ou não interage com as margens. Nota: Os modelos em ESCPOS que existem não consideram as propriedades de margem. Afinal, não faz muito sentido mesmo. Como podem ver na tabela acima, muitos componentes não estão atualizando as margens. Isso significa que mesmo que configure uma margem, ela será simplesmente ignorada. Então a ideia é fazer com que esses componentes imprimam de acordo com a configuração. Além disso, queremos evitar qualquer possível confusão e por isso vamos padronizar as unidades de medidas. A unidade de medida escolhida foi milímetros (mm). Alguns dos motivos foram: A unidade de medida mm funciona bem tanto para impressões grandes (por exemplo A4) como para bobinas (80 mm); As pessoas estão acostumadas com mm porque é a unidade padrão de todos os geradores de relatório usados atualmente (Fast Report, Fortes Report, LazReport ...); Devido ao ponto anterior, usar mm vai nos poupar código de conversão de unidades; Mesmo que tivéssemos escolhido centímetros (cm), haveria quebra de compatibilidade por causa do SAT e NFC-e; Quando as alterações vão entrar em vigor? A previsão é que dia 14 de outubro, as alterações sejam enviadas ao SVN. Acreditamos que isso dá tempo suficiente, para conseguirmos avisar a todos e para que todos possam se preparar. As alterações já foram enviadas ao SVN. Veja nota no fim desse post. O que eu preciso verificar no meu aplicativo? A primeira coisa é verificar se você tem configuração de margem (seria bom que tivesse). Em caso afirmativo, como você está armazenando? Em que unidade está armazenando? cm ou mm? Vai ser necessário fazer alguma conversão? Verifique como você deseja manter a configuração? De posse das informações acima, faça um teste imprimindo todos os documentos que você usa. Isso vai ajudar você a prevenir qualquer problema antes de enviar o executável para o cliente. Sugerimos você a imprimir tanto antes como depois das alterações no componente. Assim você vai ter algo para comparar as impressões e ajustar as margens caso necessário. O que eu preciso fazer caso use o ACBrMonitor Plus? A nossa ideia é minimizar o impacto para quem usa o ACBrMonitor. Vamos colocar as informações o próximo post logo abaixo. Se ficarmos atentos a essas alterações, as impressões vão seguir o mesmo padrão e ninguém mais vai precisar se confundir. Atualização- 17/10/2019 As alterações já foram enviadas ao SVN. Agora todos os reports seguem o mesmo padrão: DF-e Fortes Fast LazReport ESCPOS NF-e (Paisagem, Retrato, Inut, Evento, Simplificado) mm mm mm X NFC-e mm mm X X NFC-e (A4) mm mm X X SAT mm X X X CT-e (Evento) mm mm X X CT-e (A5, Retrato) mm mm X X CT-e (Inut, Inut Retrato) mm mm X X GNR-e mm mm mm X MDF-e (Retrato, Evento) mm mm X X NFS-e mm mm X X BP-e X X X X Caso encontre algum problema, queira por favor criar um novo tópico.

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