EMBarbosa

Com certeza. Vou adicionar na minha lista de tarefas.

Reduza o tamanho do nome das pastas e a quantidade de pastas. Por exemplo, em vez de instalar em algo parecido com "C:\programacao\projetos\Delphi\Componentes\acbr", usa apenas "C:\acbr" . A mesma coisa para seus projetos pessoais. Você também pode criar links simbólicos pra encurtar os caminhos. Mas eu particularmente não gosto dessa solução porque adiciona mais uma coisa pra você lembrar sempre que for mexer no projeto.

A mensagem de erro é que o nome ou a extensão do arquivo é muito grande. É possível que se você reduzir os caminhos do arquivo você consiga resolver.

Mas não foi isso que foi registrado. Se estiver usando os componentes, você pode analisar o log e verificar que não foi esse valor de 0,260 KG que foi enviado. Pela imagem, podemos ver que o valor da quantidade registrada foi 2,268 KG... É um valor diferente, como se o produto custasse R$ 87,97 ou R$ 87,98. O que indica que algo estranho pode ter acontecido. Talvez você possa procurar algum produto na sua tabela com um desses preços para ver se não está sendo pego um produto equivocado... Ou talvez esses valores te ajudem a debugar...

Você precisa verificar se sua tabela CESTxNCM está realmente atualizada de acordo com as últimas legislações. Comece olhando por esse link: https://www.confaz.fazenda.gov.br/legislacao/convenios/2018/CV142_18

Algumas balanças imprimem na etiqueta "Código/Peso". Mas essa balança imprime no código de barra "Código/Preço". Veja o que está escrito no código de barras "2039700010093", onde com certeza "0397" é código do produto e "01009" é o preço. Então depois de ler esse código seu aplicativo precisa calcular o peso/quantidade para enviar pro cupom. Pelo visto sua aplicação está calculando o valor incorreto.

Não acredito em ser algo similar ao modelo do DANFe. Na SEFAZ geralmente eles não querem que sejam impressos nada que possa se assemelhar ao documento fiscal. Após verificarmos aqui, é possível que eles querem dizer algo sobre tamanhos mínimos de fontes. Ou talvez seja uma referência incorreta mesmo... Mas em todo o caso, seria interessante fazerem uma consulta sobre esse Requisito.

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.

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.

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.

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.

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.

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.

Qualquer uma das duas opções é viável. Atualmente, de modo geral as pessoas preferem a DLL por poder ter mais controle.

Ok... Vou tentar verificar mais uma vez.

Joia. Fico feliz em ajudar. Bom trabalho por aí.

Olá, Essa informação você encontra na própria Nota Técnica na coluna "Ocor." (ocorrência). Você pode ver na imagem abaixo: O campo cEAN tem uma ocorrência 1-1. Isso significa que o campo precisa aparecer no mínimo 1 e no máximo 1 vez. Já o campo cBarra tem uma ocorrência 0-1. Isso significa que o campo precisa aparecer no mínimo 0 e no máximo 1 vez. Ou seja, ele pode não ser informado por ter ocorrência mínima de 0 (zero).

De certa maneira, a "venda no balcão" não deixa de ser venda na "plataforma própria" da loja. Até onde sei, no momento só em homologação. Mas essa informação é bom sempre você conferir na NT e na Sefaz da sua UF.