EMBarbosa

Olá Lucas. Não me lembro de termos disponibilizado nenhuma impressão de DAV da forma mais generalizada. Assim, acho que não temos nada específico pra SC também. Observação: Eu não sei bem o que eles quiseram dizer com seguir o manual do DANFe. Afinal isso é um DAV. Não uma NFC-e.

Tente instalar uma versão mais nova do .Net Framework.

Vejam também a área: https://www.projetoacbr.com.br/forum/forum/89-requisitos-fiscais-por-uf/

Conforme informação da SEF MG: Fonte: http://www.sped.fazenda.mg.gov.br/spedmg/cte/ Via: @Gr@c@

São as propriedades da mensagem de erro que você postou, por exemplo "ExplicitTop". Veja: Quanto a isso: Isso pode significar que a propriedade existe em algum dos arquivos: .pas, dfm, .dcu.

Se você abrir esse arquivo no Delphi 10.3 e depois tentar abrir ele no Delphi 7 pode gerar problemas porque ele vai adicionar essas propriedades que o Delphi 7 não conhece.

Bom dia. Esse é um erro de schema. Verifique se os schemas atualizados e corretos estão sendo encontrados pelo Monitor. A propósito, não encontrei o erro mencionado no arquivo de log...

Bom dia. Não entendi seu questionamento. Se são dois comandos diferentes, não devemos esperar dois resultados diferentes?

Boa tarde. Veja essa configuração do seu arquivo: [Titulo1] NumeroDocumento=95512519 NossoNumero=00009551 ... NossoNumero (00009551) com certeza é maior de 7 caracteres. É isso que o Monitor está informando com erro. Tente passar como "0009551".

Bom dia. Esse primeiro erro, é um erro de schemas. Veja que é mencionado validação. Isto é antes de ser enviado: Você provavelmente está com schemas desatualizados nessa máquina. Confirme que está com os componentes ACBr atualizados também. O Manual (MOC 7.0 -Anexo I) menciona que é valor. Não menciona nem que é unitário. Veja:

Poderia aumentar pelo menos para fazer um teste de impressão da GNRe?

Você tentou aumentar a margem superior para um valor maior como "10"?

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

Não dá... A mensagem de sucesso é do próprio Delphi Trial. Acho que não tem como saber que não foi compilado. Já estou verificando... EDIT: Para futura referência, isso já foi resolvido.

Compartilhando esse tutorial que encontrei, via firebirdnews O Tutorial foi escrito por Jan Baumgarten. Ele explica como criar uma aplicação simples usando Delphi + ZeosLib and Firebird 4RC1 para Android. O link para o artigo: https://sourceforge.net/p/zeoslib/wiki/How to use Firebird 4.0 with Zeos on Android/ Está em inglês, mas mesmo que você não entenda inglês, não é muito difícil de seguir usando o Google Translate.

Na verdade, colocar no final traria problemas ainda maiores quando a SEFAZ criasse outro valor... Acho que a questão aqui é discutir se é viável. Estamos apenas expondo as preocupações.

Boa tarde. Primeiro, você vai precisar debugar e ver exatamente em qual linha do código acontece o Access Violation. Daí tentar descobrir o motivo do Access Violation. Só então vai dar pra ter uma posição, porque não conseguimos reproduzir daqui. Eu dei uma olhada, mas não consegui identificar nada aqui. Se o motivo for esse, então talvez alguma dessas dlls estejam repetidas no seu HD. uma aplicação usa uma e a outra use outra. Mas isso não dá pra descobrir por esses logs porque os logs só mostram os nomes das dlls e não os caminhos.

Mas esse componente existe no form? Abra o form desse arquivo e verifique se está assim, com o componente do Fortes:

Gustavo, o maior problema é a quebra do código alheio. Nós nos preocupamos com isso. Veja bem, um monte de gente guarda no banco o valor do enumerado ao invés de guardar no banco o valor da tag. Daí na hora de converter de volta, qualquer alteração na ordem dos enumerados vai dar problema para os valores que já estão no BD. Nem é tanto pela alteração do código em si, que faz algum sentido. Mas pela retrocompatibilidade.

Olá Juliano Rosa. Agradecemos sua contribuição. Mas eu não entendi a necessidade dela. A adição do parâmetro AOwner não parece ser necessário. Sei que mencionou a padronização como motivação, ou seja, para ficar semelhante aos registros H020 e H030. Mas nem mesmo nos registros H020 e H030 esse parâmetro parece ser necessário. Na verdade, acho que o correto seria remover deles. A menos que você tenha percebido alguma coisa que eu deixei passar. Poderia confirmar se seria apenas isso mesmo?

Muito obrigado pela contribuição. Fiz a implementação baseada nela com o objetivo principal de deixar os pacotes padronizados. No entanto, não enviei os arquivos .res e também outras modificações que julguei desnecessárias ou incorretas. Subi as alterações para o SVN na Revisão 21515. Pelo que vi está tudo certo. Queira por favor atualizar, testar e reportar qualquer problema. Por outro lado, tenho que concordar com os colegas acima na questão do seu objetivo das alterações. Se a questão é não ficar recompilando os arquivos do ACBr, é muito melhor remover do "search path" as entradas do ACBr que contem os arquivos ".pas". De qualquer forma, mais uma vez, obrigado.

Boa tarde. Notei pelo log que está utilizando o ACBrMonitor Plus: 11/03/2021 17:32:08 - ACBr MonitorPLUS Ver.1.4.0.0 - x86 No entanto, parece que ou os seus schemas não estão atualizados ou os schemas da SEFAZ não estão atualizados. Pode verificar, por favor se os seus estão?

Olá doidopb. Os tipos básicos são Retrato, Paisagem e simplificado para NFe e NFCe. Você pode usar o ObjectInspector para avaliar os valores como na imagem do @antonio.carlos acima. Tente usar o seu programa, ou o programa exemplo para comparar as impressões diferentes. Talvez isso ajude.

Essa imagem é de uma impressão não esc/pos. Nesse caso é bom você verificar as configurações padrão da impressora no Windows. Pode ser que esteja configurado para impressão "múltipla em uma página".

Não entendi o problema. Se as margens estão sempre configuradas com "5", "6" e "8", a impressão vai mudar na comparação da versão anterior e no atual. Afinal uma usa cm e outra milímetros.