EMBarbosa

Não necessariamente. Às vezes o governo prorroga a data da versão por um motivo ou outro. Atraso na implementação de funcionalidades no PVA por exemplo. Mas você é bem vindo em implementar o método em seu aplicativo. Ou se assim desejar, pode fazer o código e colocar aqui disponível para outros usuários também.

Tati, Realmente testei aqui a pesquisa e ela não resultou nada. Muito estranho... Vou averiguar. Mas tente os seguintes tópicos: Vou averiguar sobre a pesquisa...

Ah! Agora sim! Obrigado. Essas informações, (número de fabricação, MF adicional, tipo do ecf, marca do ecf e modelo do ecf), como você mesmo notou, são do ECF. Elas são, pelo menos no ATO COTEPE antigo, do Registro D1. Para tornar explícito de qual ECF o DAV foi emitido, elas são repetidas no Registro D2. Assim, como elas são propriedades do ECF e não do DAV, elas não são necessárias ao criar uma instância do registro D2.

Não existe. A sugestão é colocar a escolha da versão no mesmo lugar em que o usuário seleciona o período e os outros parâmetros que são definidos por arquivo.

Pesquise por "Não foi possível encontrar o ponto de entrada"

Anderson, o que o Régys pediu foi para você reformular a pergunta, escrevê-la de outra forma, com outras palavras, pois ele não entendeu a pergunta. E pra falar a verdade, Eu também não...

Nesse caso, as homologadoras não terão poder algum de decisão. Será definido pelos estados. Se o estado definir que vai aceitar, elas não podem fazer nada. O caso é saber se o estado vai querer forçar as empresas a terem um PAF-ECF-SN pensando que isso vai ser mais barato... Mas essa imposição, para software houses que atendem tanto SIMPLES como os que não o são, pode ser mais custoso. E aí o que era pra ser mais barato sairá mais caro. Contudo, para quem só atende clientes cadastrados no SIMPLES NACIONAL, temos que admitir que é um grande passo à frente. Descomplicou muito o trabalho dessas empresas e elas poderão oferecer um serviço de qualidade com um custo bem reduzido.

Não diz que podem continuar "usando normalmente", mas "usando o aplicativo atual para fins gerenciais". Mesmo assim, ainda não está claro.

Além do que já foi dito, na imagem que você postou parece que você identifica o PAF após cada cupom. Não precisa fazer isso.

É 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.