EMBarbosa

Não precisa. Os schemas da maior parte, senão todos, DF-e estão no caminho: ACBr\Exemplos\ACBrDFe\Schemas

Seria bom, talvez eles possam dar uma orientação mais detalhada.

Reabrindo esse tópico. O outro tópico já está fechado.

Me parece ok. Enviei ao SVN na revisão 15994. Queira por favor atualizar e verificar. Para esse problema queira criar outro tópico e me mencionar por favor.

Nesse caso tenho que concordar com o Henrique é realmente melhor você criar um tópico para cada problema. Você vai precisar exemplificar em cada tópico o problema que está passando e como reproduzir.

Moderação: Tópico dividido Se você debugar a aplicação, ela não dá nenhuma outra mensagem de erro?

Se houver alguma e não existir um tópico sobre ela, pode reportar aqui mesmo.

Já foram corrigidos esses problemas citados.

Pelo visto você está fazendo a certificação com ECF, correto? Você verificou se sua aplicação está dando o retorno correto ao ACBrTEFD sobre a situação do ECF? O que é apresentado nos logs do ACBrTEFD?

Esse tópico é para informar que o Refactoring das impressores DF-e foi concluído e enviado ao SVN na revisão 15983. Queremos lembrar que vai ser necessário reinstalar os pacotes e componentes, pois houveram alterações nas propriedades. Se você utiliza o ACBrInstall, não se preocupe. Ele já foi atualizado no SVN e daqui a pouco será já foi atualizado aqui na área de Downloads também. Se você não sabe do que se trata, veja esse tópico aqui: Nesse tópico são citados dois vídeos sobre o refactoring que recomendamos você assistir. Esse abaixo explica o refactoring: E esse mostra um exemplo de atualização de uma aplicação usando usando o exemplo do ACBrNFe: Deu bastante trabalho esse refactoring e fomos bem minuciosos. Mas pode ser que alguma coisa passou despercebido. Sugerimos que você atualize sua aplicação e comece os testes o quanto antes possível. Para complementar o disponibilizado antes, veja também essa tabela abaixo o nome de propriedades e métodos que mudaram. Note no entanto que há propriedades que são específicas de algumas classes e isso não foi alistado abaixo: Uma informação importante é que agora existe um componente específico para NFC-e em Fast Report. Se você vai trabalhar com NFC-e e imprimir usando o Fast Report, será necessário utilizar esse componente. Nele você encontrará as propriedades que são específicas para NFC-e. Agradecemos ao @BigWings pela ajuda no trabalho com esse componente. No mais, bom trabalho a todos.

Olá Wanderson. Visto que o pedido deste tópico era um exemplo em TXT e o @Italo Jurisato Junior já mostrou como você pode conseguir, pedimos que crie um novo tópico para cada dúvida que você tiver.

Além disso há outras sugestões nesse tópico citado na minha resposta acima: trocar a midas.dll que estava na pasta SYSTEM pela que estava na pasta do Delphi adicionar Datasnap.Midas na uses pegar midas.dll da pasta bin e colocar na pasta System32, SysWOW64 e na pasta do Meu Projeto

Na imagem você abriu o exemplo pelo explorer. Se você abrir o Delphi primeiro a mensagem continua aparecendo? Ela aparece antes ou depois de abrir o exemplo? Aparece alguma mensagem antes? Outra coisa, tem mais de uma versão do Delphi instalado na máquina? um caso praticamente idêntico o usuário corrigiu reinstalando o Delphi. Veja:

O segundo vídeo mostrando um exemplo de como atualizar já está on-line. Vejam: A previsão é que até a tardinha já esteja no SVN os componentes já alterados.

Verifique primeiro se com o programa de exemplo funciona, por favor. Porque não me lembro desse problema. Pode ser que seu sistema esteja alterando a formatação de campos float do Windows.

Esse erro é diferente do apresentado nesse tópico. Apague o arquivo "SPEDFiscal.dproj" e tente novamente. Acabei de fazer o teste aqui no Berlim e abriu e compilou e executou sem erros.

O Régys fez uma alteração hoje agora a pouco. Confere aí.

Acho que não existe nenhum componente que faz isso. Talvez você deva pensar se não seria o caso de mudar para um outro estilo de GUI. Ao invés de usar SDI ou MDI usar TDI, por exemplo. Mas se quiser uma outra opção, você pode responder a mensagem WM_SYSCOMMAND do windows para detectar que ele está sendo minimizado e daí escondê-lo. Veja um exemplo em: https://stackoverflow.com/a/20575148/460775

É desse jeito mesmo que tem que ser feito. Infelizmente não existe um lugar só para procurar. Felizmente algumas UFs tem um site só sobre o SPED e facilita procurar legislação específica. O de MG é http://www.sped.fazenda.mg.gov.br/ Infelizmente, nem sempre estão atualizados, como é o caso de MG.

Crie na sua aplicação uma opção "gerar bloco K"?

Realmente, estou movendo para área apropriada. Não tem, mas talvez alguém possa ajudar. Como assim "minimizar o form e mover para o panel"? Poderia explicar melhor?

Se estiver em modo debug esse erro é comum... Ele geralmente é tratado pelo componente. Mas se você demorar a clicar em "Continue", o componente pode entender que a demora superou o TimeOut, daí vai retornar o erro. Então o certo é clicar rápido no botão, ou marcar para "ignorar esse tipo de exception".

pode ser necessário aumentar o timeout.

Legal! O mORMot é uma ferramenta muito poderosa e, na minha opinião, é ideal para o que está querendo fazer. Se começar a usar ele vai querer jogar fora os TDatasets. ? Realmente, você ter que alterar um código chamado milhares de vezes não é o desejado. Se não me engano a unit SynDBVCL.pas pode ajudar nessa conversão. Mas você precisa mesmo de um pouco de cautela. O que você colocar no componente IBXQuery e UniQuery em tempo de design, não vai funcionar em tempo de execução. Afinal, você mesmo admitiu que não está usando a conexão desses componentes. Quando você faz: Você substituiu a query desenhada em tempo de design, e consequentemente os campos (TFields) adicionados em tempo de design também param de funcionar. Um detalhe é que isso acontece toda vez que o comando acima for executado, cada vez apontando para uma referência diferente. O mORMot já tem uma função que retorna o Dataset preenchido. Se não me engano um TClientDataset. Veja esse post no blog deles, embora um pouco desatualizado, indica a unit que mencionei acima. A conexão sempre vai ser necessária, de uma maneira ou de outra, mesmo que por fora do TDataset. No seu caso, a conexão terá que ser feita pelo mORMot. Processar os dados manualmente e preencher um TDataset daria mais trabalho do que substituir o seu design atual. Eu não recomendaria isso de forma alguma. É preferível remover de vez os componentes em tempo de design e passar a usar só o mORMot. Com certeza daria um trabalho braçal agora, mas tornaria seu aplicativo muito mais clean, fácil de dar manutenção e com uma possibilidade de erros muito menor. A outra opção mais interessante que vejo é tentar fazer funcionar o proposto no começo: remapear todos os campos em tempo de design para os campos criados pelo mORMot. Note no entanto que você teria que fazer isso para cada query existente no seu datamodule e toda vez que a query for ativada. Ou seja, você teria criar um método que faz o mapeamento dos campos e substituir em todos os lugares que é executado comandos semelhantes aos abaixo: UniQuery1.Open; //ou UniQuery1.Active := True;