EMBarbosa

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?

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.

Olá Willian, Tive que fazer alterações para que o componente pudesse compilar no Delphi 7 e Lazarus. Você pode observar no código anexado como foram as alterações, de modo que sua dúvida sobre como substituir generics deve ser resolvida. BrLCDPR.7z Visto que você deu a permissão, ideia é adicionar ao ACBr. Primeiro terei que adicionar o cabeçalho da licença nos arquivos. Devo fazer isso nos próximos dias.

Será que não poderia ser algum problema de antivírus? Talvez detectando que seu aplicativo em 32 bits seja um malware e bloqueando a execução?

Se não me engano, o layout do comprovante do TEF é definido pelo gerenciador (aplicação da certificadora). O ACBrTEFD envia para impressão exatamente o que recebe. É preciso verificar com a certificadora a possibilidade de mudar o layout da impressão reduzindo as colunas.

Com a JCL é possível fazer isso. Tem artigos na internet.

Pelo que eu entendi, a tag é opcional. Isso quer dizer que ela nem sempre virá. Quando a tag vir, você deve levar ela em conta antes de enviar uma consulta sobre o mesmo lote. Se você não fizer isso pode ser considerado consumo indevido. Mas quando a tag não vier, isso quer dizer que você deve usar bom-senso.

Já está na minha lista de afazeres. Vou analisar.

Muito obrigado pela contribuição. Fiz a implementação baseada nela. Subi as alterações para o SVN na Revisão 17692. 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. No entanto tive que fazer diversas alterações para seguir o novo modo de implementar as balanças. Queira observar que agora, geralmente, apenas precisamos implementar os métodos InterpretarRespostaPeso e SolicitarPeso. Subi as alterações para o SVN na Revisão 17688. Pelo que vi está tudo certo mas queira por favor atualizar, testar e reportar qualquer problema. Mais uma vez obrigado.