EMBarbosa

Olá. Até onde eu consegui identificar, a maior diferença nesse seu dfm para o que está no SVN é a propriedade "PixelsPerInch". No seu dfm está configurada como 96. No nosso, ela usa o valor padrão (vazio). Não podemos subir isso porque essa é uma configuração específica para cada monitor/impressora/etc... e também pode ser influenciado dependendo da configuração no "manifesto" da aplicação. Essa configuração então é feita nas propriedades que você já citou... Mais informações abaixo. Os valores padrões realmente são esses. Já eram antes de atualizar o ACBr e atualizar ele não faz qualquer quebra no layout a menos que você modifique essas propriedades. No entanto, isso não quer dizer que funciona em toda ocasião. Se esse fosse o caso, não teríamos criado essas propriedades há anos atrás. Conforme dito anteriormente isso depende de vários fatores: 1) versão do Fortes Report 2) configurações da sua aplicação (manifest) 3) configurações do Windows (ou monitor) . Não quer dizer que esteja com problemas. Você deve fazer a configuração conforme a máquina que estiver executando o aplicativo. Não coloque a configuração amarrada na sua aplicação. Se isso não for configurável em sua aplicação, você terá problemas na impressão. Além disso não deve ser uma configuração arbitrária e sim a configuração correta para aquela máquina/monitor/impressora.

https://projetoacbr.com.br/cursos/sat-sp/

Olá Daniel, É muito difícil que alguém te ajude com uma dúvida tão genérica. Come por ler o manual. A partir daí faça pesquisas aqui no fórum, no nosso Discord e na internet de modo geral. Depois tente consultar um contador de confiança, preferencialmente os dos seus clientes. Ainda tendo dúvidas específicas, poste aqui no fórum. Talvez alguém possa ajudar.

Obrigado pelo retorno. Mas é como eu disse, poderia mesmo ser algo da própria impressora. Não quer dizer que seja um problema da linguagem PPLA. Talvez seja da PPLA nessa impressora. As fontes geralmente são internas, ou seja, pré codificadas na memória interna da impressora. Pode ver no manual que o Elias postou acima. Inclusive, nesse manual, em algumas fontes tem diferença entre um "ç" e um "Ç". Mas parece que nem todas as fontes tem isso. Fora o fato já citado que varia de impressora para impressora. De qualquer forma, me parece que sua dúvida maior seria: qual linguagem usar? Certo? A resposta é use a que for melhor para a impressora que tem. Seu sistema pode ser parametrizável de forma que use a linguagem que seja mais compatível com a impressora de cada cliente.

Me parece que o "ç" na imagem está saindo minúsculo. A ideia seria fazer ele ficar maiúsculo. Talvez a função que está convertendo para maiúsculo não esteja fazendo bem o trabalho. Mas também pode ser um problema específico da impressora.

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

Muito Obrigado. Subi as alterações para o SVN na Revisão 28486. Pelo que vi está tudo certo. Queira por favor atualizar, testar e reportar qualquer problema no tópico linkado: Estou fechando esse para evitar duplicidade de informações.

Muito obrigado pela contribuição. Fiz a implementação baseada nela mas mantive outras validações que me pareceram corretas conforme outro tópico Subi as alterações para o SVN na Revisão 28486. Pelo que vi está tudo certo. Queira por favor atualizar, testar e reportar qualquer problema. Mais uma vez obrigado.

Boa tarde. Não temos nada no ACBr que faça isso. Mas você pode tentar a comunidade. Tente no subfórum banco de dados :https://www.projetoacbr.com.br/forum/forum/60-banco-de-dados/ Alguém pode sugerir uma opção open source. Mas é importante você citar qual banco de dados e backend você está trabalhando. E talvez também queira tentar a área de classificados. Existem muitas opções no mercado, mas variam muito em quais bancos de dados suportam.

MODERAÇÃO: Tópico movido para subfórum mais adequado.

Acredito que não tenha nada pronto. Mas isso me parece combinações e permutações simples. Não deve ser muito difícil encontrar na internet ou desenvolver. O problema é que parece muito com um exercício de dever de casa... Pode dar mais informações sobre o contexto?

Sim. É isso mesmo. Não existe a versão 117 ainda. Veja a tabela conforme diz o manual: http://sped.rfb.gov.br/pagina/show/1578

Se você passa o XML pra lib, não importa se ele é lido em arquivo ou em string, o comportamento é o mesmo. Foi sugerido para você tentar passar o caminho ao invés do conteúdo. porque quando a lib lê de um arquivo, ela é responsável por fazer a leitura binária do arquivo. Isso pode mitigar qualquer conversão incorreta do encoding. Essa conversão incorreta é o que está gerando o erro reportado no início: Essa sequência de bytes "0xE9 0x67 0x72 0x61" não é UTF-8 "bem formado".

Entendemos, e isso pode ter sido a confusão inicial. Mas só pra deixar claro os motivos pra esse comportamento: se você passa um XML, a lib (e o componente) entende que o xml passado está pronto e não precisa gerar ele novamente. Isso é importante para casos de pessoas que querem que o seu XML tenha alguma particularidade diferente do que é o padrão das soluções do ACBr.

Oi Andergoncalves. Com certeza. Esse código além de ser mais fácil de ler e manter, evita problemas de enumerados implementados sem uma string correspondente. Então, a ideia é, na medida do possível, fazer isso para todos os componentes que tenham situações parecidas. Nesse sentido, toda ajuda é bem vinda. E agradecemos aqueles que quiserem e puderem contribuir como você e o @Marcelo Pontes Melim tem feito. E com respeito ao Reinf, esperamos ter novidades nos próximos dias.

Obrigado pela contribuição, em breve será validada para possível inclusão ao svn TK -3560

Oi @Marcelo Pontes Melim, Queria avisar que eu fiz um commit relacionado a esse código na revisão 28381. Acontece que havia um método na unit pcesConversaoeSocial que faz a conversão usada naquela unit. Só que o método tinha uma incompatibilidade por conta da letra 'v' . Daí eu fiz uma alteração no método e uma varrida no componente pro uso dessas strings. Além disso encontrei outros lugares onde a mudança poderia ser aplicada. Do jeito que estava, a gente sempre precisava ficar indo nos arquivos e mudando. Agora, basta mudar na pcesConversaoeSocial e pronto. Por favor, depois de atualizar, reporte qualquer problema.

Relembre o último Papo Pro com a participação do IBPT.

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

@oliveira_arara e @Alysson Rengel Outras perguntas importantes: 1) Por que vocês estão usando Capicom? 2) Tentaram com OpenSSL? 3) E WinCrypt?

Eu não consigo nem abrir para analisar (com extensões) esses arquivos no VS Code já que tem mais de 20 MB. O Notepad++ abre com uma certa dificuldade. É possível que precisemos de algum tempo a mais para poder analisar isso. Qual a versão do Delphi de vocês?

A minha resposta foi para o Fernando. O que eu te pedi você ainda não respondeu:

Reduza o número de itens removendo os que estão com estoque zerado e os que não houveram movimentação.

Nesse log não tem a chamada para os métodos que geram o erro reportado. Por favor, gere um log desde o início da operação até o momento em que o erro é reportado. Se possível anexe os arquivos utilizados.

Bom dia. Por favor, nos dê mais informações. Qual a sua linguagem de programação? Consegue reproduzir o problema com a aplicação de exemplo? Como você está alimentando a lib? Por meio de arquivos INI ou xml? Anexe o log gerado desde o início da operação por favor. Anexe o arquivo INI utilizado pela Lib.