EMBarbosa

Tente aumentar o valor da margem e verificar se vai haver alguma alteração no Preview. Eu estou achando muito estranho porque a impressão do quadro "dados do produto" está toda fora de posição. Tem certeza que não há alterações locais? Nem nos arquivos dfm? Visto que o Fortes parece utilizar a impressora, pode ser... Você pode tentar em outra máquina com outra impressora.

Na verdade, a propriedade citada ainda não foi implementada no Fast Report. Então não existe propriedade para ocultar os descontos nos itens. Qual arquivo fr3 você está utilizando?

Me parece que sim. Muito obrigado pela contribuição. Já corrigi. Subi as alterações para o SVN na Revisão 18402. Pelo que vi está tudo certo. Queira por favor atualizar, testar e reportar qualquer problema. Mais uma vez obrigado.

Nas configurações de resolução, verifique a escala. Se a escala na resolução estiver diferente de 100% pode ser esse o motivo. No Windows 10 a tela é semelhante a essa:

Sua equipe está acostumada com Git? Você vai ter uma equipe distribuída? Você quer melhor integração com outras ferramentas de DevOps (como Jenkins por exemplo)? Você quer seguir a maioria? Se a resposta a alguma dessas perguntas for sim, use Git. Caso seja não para todas, então pode escolher entre SVN e GIT. Daí vão entrar coisas como simplicidade (tende para SVN) e recursos (tende para GIT). As versões mais novas do SVN permitem "Shelving" que é um recurso bem simplificado mas útil de alteração local.

Com ACBr você quer dizer o Monitor certo? Você fez alguma configuração na Lib para a impressão?

Você informou a tag vTotTrib dos itens dentro do grupo ICMS. Pelo layout do XML, ele deveria ser informado nos dados do produto. Você também pode ver esse exemplo na documentação do Monitor, já que o modelo do ini na ACBrLib é o mesmo: https://acbr.sourceforge.io/ACBrMonitor/ModeloNFeINICompleto.html

Veja esse help do Monitor com as tags permitidas: Acredito que seja a tag: <code39> - Bloco - Cod.Barras Code39 - Aceita: 0..9,A..Z, ,$,%,*,+,-,.,/, tamanho livre

Essa detecção como "Trojan.GenericKD" indica que é o algoritimo heurístico que detectou. Ele não sabe exatamente se é um vírus e nem qual é, por isso ele chamou de genérico. Pode ficar tranquilo. é mesmo um falso positivo.

Isso é um falso positivo. O BitDefender tem vários modos como On-Access e ATC. Algumas vezes, ao desativar um o outro fica habilitado... Talvez seja isso. Já tive um problema com ele aqui onde mesmo adicionando a pasta de exceções ele continuou barrando o executável.

No Indy realmente não tem... dá uma olhada no que comentaram nesse tópico aqui (em inglês): https://en.delphipraxis.net/topic/1725-sftp-client/

Como assim dois sistemas? De qual solução ACBr estamos falando?

Infelizmente, ele não pode simplesmente inventar um código de barra EAN. Os códigos de barra EAN/GTIN tem padrão internacional. Além disso, se você está passando o parâmetro barEAN13, como você vai passar um parâmetro com 14 dígitos?

Olá Arturguerra, Muito obrigado. O que pode estar acontecendo na sua situação é que o ACBrBal ligado ao ACBrMTer não está configurado para interpretar corretamente o peso passado a ele. Você pode tentar trocar os protocolos ou implementar um novo protocolo no ACBrBal. Mas infelizmente, verifiquei que não podemos enviar ao SVN essa alteração. O que acontece é que sua alteração faz com que o componente ACBrMTer passe a ignorar a ligação com o componente ACBrBal e interpretar o peso sempre do mesmo jeito. O componente ACBrBal é quem deve fazer a interpretação de peso, porque a forma como se interpreta o peso muda de modelo para modelo. Tentei adaptar suas alterações para o ACBrBal, mas as informações são insuficientes. O protocolo da balança Magna que temos implementado é mais complexo do que você implementou nesse código acima. De qualquer maneira agradecemos sua intenção em ajudar.

Olá Matheus, Mais uma vez obrigado por sua disposição e alterações. Boa parte delas já foram adicionadas ao SVN. Eu fiquei "debruçado" sobre esse último problema relacionado ao método TLeitor.rExtrai já há algum tempo. Sei que o código atual talvez não seja o mais otimizado, mas ainda não consegui reproduzir o problema. Utilizando o xml que você proveu e o exemplo que citei acima, a função TLeitor.rExtrai sempre tem como parâmetro item = 1. Quer dizer que o código é extremamente rápido mesmo sem as alterações. Por outro lado, o seu código realmente parece fazer sentido. Essa parte dos componentes é muito delicada porque afeta todos os documentos eletrônicos. Por isso, seria possível prover um exemplo que demonstra realmente o problema? Não precisa ser uma lentidão exagerada. Apenas um passo a passo pra reproduzir o problema com o código atual.

2.2 - Permaneça no assunto - Quando tiver uma dúvida diferente do assunto no tópico, poste em novo tópico. Não use algo equivalente a "aproveitando o gancho... [dúvida não relacionada com o tópico aqui]". Favor leia as regras do fórum.

Olá Edvaldo. O arquivo citado já foi enviado ao SVN conforme o outro tópico. Veja: https://www.projetoacbr.com.br/forum/topic/55083-falta-de-arquivos-e-dlls-na-no-demo-do-acbrlib/?do=findComment&comment=361888

Isso parece ser problema de codificação. De que componente você está falando?

A impressora retornou ACK = 0, que é como se a impressora não tivesse recebido o comando e por isso o comando é repetido numa nova tentativa. Veja essa parte do seu log: -------------------------------------------------------------------------------- ATIVAR - 26/11/19 07:24:45:594 - Modelo: Bematech - Porta: COM5 - TimeOut: 3 Device: BAUD=38400 DATA=8 PARITY=N STOP=1 HANDSHAKE=RTS/CTS HARDFLOW MAXBANDWIDTH=0 SENDBYTESCOUNT=0 SENDBYTESINTERVAL=0 -------------------------------------------------------------------------------- Você está utilizando um TimeOut muito pequeno 3. O recomendado para portas seriais é no mínimo 10. Se for uma porta virtual, sugiro aumentar para 20.

Geralmente isso não é normal. Embora possa ser um problema na SEFAZ, não estamos recebendo relatos semelhantes... Apenas quem dá manutenção no seu sistema pode dizer. Não ficou muito claro. Vocês são os desenvolvedores? Em caso afirmativo, vocês podem medir a lentidão e descobrir exatamente onde está acontecendo o problema. Em caso negativo, o melhor é tentar seguir as recomendações e entrar em contato com o suporte dos desenvolvedores. Eles provavelmente tem condições de medir a lentidão e te dar um diagnóstico mais preciso.

Provavelmente alguma inconsistência no "form". Você precisa abrir o lfm que está gerando essa mensagem no Lazarus para tentar identificar o problema e atualizá-lo.

Vocês não tem um xml de exemplo do provedor para comparar com o de vocês?

Olá Jésika, Até onde eu sei não existe um jeito de obter o NSU por fora desses dois métodos. Você deve manter na sua aplicação atualizada o valor do UltNSU e do maxNSU para não sobrecarregar os servidores da SEFAZ. Veja mais sobre esses métodos voltado especificamente para o CT-e na nossa base de conhecimento: É recomendada também ler as informações da Nota Técnica 2015/002 versão 1.00a.

Os arquivos mencionados acima existem nos respectivos diretórios?

Olá ALA, Embora exista essa propriedade, ela não foi implementada no DANFe NFC-e Fortes para tamanho A4. Não deve ser muito difícil adicionar o código para jogar o QrCode pra lateral. Caso tenha interesse em implementar e posteriormente anexar o código aqui no fórum para análise, vamos ficar felizes em ajudar.