EMBarbosa

É isso mesmo. Veja o Art. 7º.

Sua resposta foi muito boa, concisa e completa. Acho que você pode marcar seu post como resolvido marcando sua própria resposta.

Essa é uma parte da legislação que confunde muito até alguns contadores. Uma vez perguntando ao contador de um cliente sobre o assunto, ele não soube dizer nem se podia converter... Acho que deveria ter uma legislação ou pelo menos orientação mais clara para preencher os documentos fiscais nesse sentido. Fica difícil ter sempre que modelar alguma coisa no software pra só depois descobrir como é que pode e não pode... Acho que o ideal é ter uma tabela de conversão no BD com unidades padrões e daí o usuário acrescentar quaisquer outras unidades de acordo com elas. Ex. Haveria a unidade Metro e se o cliente usar, poderia acrescentar Quilometro, Léguas, Milhas, centímetros, etc. juntamente com seu fator de conversão. Mesmo assim, esbarraria no problema de precisão ao converter de unidades muito grandes para muito pequenas (toneladas para gramas por exemplo) ou vice-versa.

Então eu estava certo. Entenda. Duas perguntas diferentes, dois tópicos diferentes. São as Regras e orientações para uso do fórum.

Desculpe, mas a opção Marcar como Resolvido não é para ser usado como um termina um tópico por aqui. Isso não ajuda outros usuários. Tópico marcado como não resolvido. Desculpe, então foi eu quem não entendi seu post. Assim, me aponte no seu tópico qual foi a sua pergunta então?

Veja no post de Regras a parte "Como fazer perguntas inteligentes e receber respostas satisfatórias" que você deve fazer um tópico específico: Isso é importante. A funcionalidade de marcar um post como resolvido com "Melhor Resposta" não vai funcionar se houver várias perguntas diferentes e várias respostas. Além disso, se você usar a busca, verá que é muito difícil buscar uma resposta a um problema específico quando o tópico fala de diversos assuntos diferentes e abrange páginas e páginas. Espero que tenha notado que ao ler o log e procurar por erros e postar minhas respostas anteriores, eu mostrei disposição em querer ajudar. Mas como sou usuário que faz buscas frequentes e um pouco mais antigo do fórum, eu sei exatamente como um tópico se torna ineficaz mais tarde por não se seguir essas orientações.

Vai depender dos componentes e do tipo de código que você usa. Eu aconselho a mudar para o Delphi 7 primeiro e depois passar para o XE. Fuja do Delphi 5 o mais rápido possível.

Não é gambiarra. CX144 e CX1728 são duas coisas totalmente diferentes, então merecem um lançamento diferente no 0190. Mas você tem razão em dizer que o SPED é limitado, pois o tamanho de unidade é reduzido. Contudo, a limitação persiste, e é você quem deverá decidir a melhor maneira de contornar. Só pra finalizar, não sei se percebeu, mas o problema que você iniciou é diferente do assunto tratado nesse tópico. Por favor, crie tópicos diferentes para dúvidas diferentes. Veja as

Não é por causa do CNAE da empresa? Veja o Guia prático na página 140, o segundo parágrafo debaixo de "REGISTRO H005: TOTAIS DO INVENTÁRIO" Veja também a descrição do campo 04.

Então tente localizar no log do seu cliente onde é o erro da redução Z. Pois eu não tenho como localizar sem conhecer o seu código fonte e foi nessa parte que percebi o erro.

Não sei. Você está abrindo relatório gerencial para emitir uma Redução Z? Se estiver, isso me parece errado.

O campo com apenas 6 caracteres é a descrição. Nesse caso, a descrição da unidade deveria ser "PCT". Veja também o mesmo campo no Registro 0190. P.S.: Logicamente você poderia criar uma unidade com descrição diferente, para ser mais específica. Mas aí você é quem vai ter que usar a criatividade. Poderia usar por exemplo "PCTMIL", "PCTMMM" ou "PCT1M". Use a imaginação aí.

Os erros que eu vi no seu log foram erros relacionados a relatório gerencial, nada sobre Redução Z. Veja: O log é um pouco grande, então não dá pra saber onde exatamente está o erro sem que você aponte em qual momento está tentando chamar a redução Z. Tente verificar o seu problema. No entanto, o erro "Aguardando resposta do comando anterior" significa que seu software mandou para o ACBrECF um comando antes de receber a resposta de outro que já havia mandado. Talvez o seu problema esteja por aí. Seria onde eu começaria a investigar.

Não sei se entendi direito sua preocupação, mas não há como proteger contra falhas de comunicação. O mesmo problema que daria em uma forma, daria em outra. Pois o número de vezes que você vai comunicar com o ECF é o mesmo.

Mais segura contra o quê?

Nesses casos você deve usar o método GetDadosUltimaReducaoZ. Contudo, é extremamente recomendado você enviar esse ECF para a intervenção e mudar a configuração, pois pode ser que alguns dados você não consiga recuperar com esse método, dependendo do ECF.

Até onde me lembro você não precisa daquele FreeAndNil ali no código. De resto não parece haver nada de errado... Talvez um erro no seu SQL?

Como assim? Não foi você quem iniciou o tópico, foi?

Se o modelo for MFD deve-se usar o SwedaSTX.

Talvez você possa usar o ACBrNFeMonitor.

Tópico movido para área de programação Pascal/Delphi/Lazarus.

Eu não conheço ninguém não.

Atualize seu Delphi para uma versão igual ou superior ao Delphi 2009 com update 3 ou utilize o MidasSpeedFix.

Existem regras sim. Mas download de um software disponibilizado com licença definindo seu uso e uma empresa que presta serviço são coisas um pouco diferentes. Além disso, em alguns estados é permitido que se use software não fiscal, desde que o software não fique no mesmo ambiente de atendimento ao freguês e que a loja continue emitindo os documentos fiscais normalmente.

Comece aqui: -> Não tenha medo de ler as legislações mesmo que pareçam confusas. Você vai precisar estar bem a par delas... Note que se for homologar depois de junho, você vai precisar se adequar ao novo modelo. Então veja também esse tópico: Nota: da próxima vez, queira fazer uma busca no fórum.