JeannyPaiva

Boa tarde. Fiz a atualização, e realizei alguns testes na versão 2.00 do CTe. Tudo Ok até ai. Porém me deparei com um problema: Como a versão é definida por diretiva de compilação e consequentemente a estrutura muda de acordo com o que foi definido, uma vez que compilei o projeto com a versão 2.00 não é mais possível efetuar operações com os XML da versão anterior (impressão do DACTe por exemplo). Haveria possibilidade de passar a definir a versão do CTe através de um parâmetro, como está sendo feito com a NFe? Obrigada.

Boa tarde Temos clientes que irão iniciar a emissão do MDFe que são transportadores de carga própria, não possuem RNTRC. Porém está obrigando a informar. De acordo com o manual, o campo não é obrigatório. Se possível alterar na unit pmdfeMDFeW, linha 355 Gerador.wCampo(tcStr, '#02', 'RNTRC', 08, 08, 0, SomenteNumeros(MDFe.Rodo.RNTRC), DSC_RNTRC);. Obrigada

Desculpe Italo, falha minha. Anexei agora.

Bom dia. Foi encontrado um problema relativo ao DAMDFe em contingência. Estava cortando na mensagem de contingência o horário da impressão. Seguem os fontes corrigidos, se alguém puder colocar no SVN por favor. DAMDFe.zip

Tudo certo Italo! Obrigada

Boa tarde a todos. Notei que a propriedade PathEvento não está sendo respeitada para salvar os xml dos eventos. Poderiam alterar na unit ACBrMDFeWebServices Função: function TMDFeEnvEvento.Executar: Boolean; Linhas: 1723, 1749, 1783 e 1873. Esta passando: FConfiguracoes.Arquivos.GetPathMDFe, quando deveria ser FConfiguracoes.Arquivos.GetPathEvento(TipoEvento). Obrigada

Tudo certo Italo. Obrigada

Bom dia a todos. Seque o componente incluindo a impressão de eventos. (Cancelamento, Encerramento e Inclusão de Condutor). No caso da inclusão de condutor, encontrei dois problemas no componente. 1-Geração do evento: Unit pmdfeEnvEventoMDFe, Linhas 196 e 199 - Condutor está com a primeira letra maiúscula, gerando erro de validação do XML. 2-Leitura do XML do evento: pmdfeRetEnvEventoMDFe, Necessário acrescentar as linhas: infEvento.detEvento.xNome := Leitor.rCampo(tcStr, 'xNome'); infEvento.detEvento.CPF := Leitor.rCampo(tcStr, 'CPF'); no bloco if Leitor.rExtrai(3, 'detEvento', '', i + 1) <> '' then begin . . . end; DAMDFe.zip

OpenNet, pela Demo do ACBR, acontece o mesmo? Estou anexando a forma como esta o executavel de demonstração aqui, veja se esta da mesma forma. Exemplo.zip

Opennet, eu realmente não sei o que pode estar ocorrendo no seu caso não. Tanto na minha aplicação, quanto na Demo que vem no componente bastou eu informar no componente: ACBrMDFeDAMDFEFR1.FastFile := 'C:\fontes\cliente\Recursos\DAMDFe_Retrato.fr3'; E informar no componente ACBrMDFe1 que o DAMDFE é o ACBrMDFeDAMDFEFR1, não foi necessário nenhum outro artifício. Agora, uma pergunta, pois não entendi, você adicionou a unit ACBrMDFeDAMDFEFRDM ao seu projeto??

Bom dia Italo. Estou implementando agora os eventos no sistema. Vou dar uma olhada no que foi feito no QR e assim que possível disponibilizo aqui também.

Fabio e Open Net. Poderia mesmo ser questão de versão, embora eu nunca tenha passado por isto. Mas em todo caso, aqui não acontece, utilizo Delphi XE2 e FR 4.14. Se for o caso só abrindo o fr3 na fastreport que vocês utilizam mesmo para resolver, lembrando que o fr3 é apenas como exemplo/sugestão. Eu mesmo sempre faço mais algumas personalizações para atender algumas particularidades dos clientes.

Realizei duas correções no componentes: 1- Série não estava sendo exibida. 2- CT-e associados estavam sendo duplicados na impressão DAMDFe.zip

Bom dia Open Net. Aqui eu não precisei fazer isto em momento algum, apenas quando criei os fr3. Por acaso vc não chegou a abrir o fr3 em outro local que não fosse o ACBrMDFeDAMDFEFRDM não?

Open Net, Boa Tarde. Se nenhuma das duas alternativas funcionaram, tente debugar na unit ACBrMDFeDAMDFEFRDM para ver em que momento ocorre.

Opennet, boa tarde. Outra situação que pode ocorrer é se tiver dois componentes de impressão da criados (Danfe e Damdfe por exemplo). Como os dois utilizam ClientDataSet com mesmo nome, o FastReport costuma ler todos os datasets diponíveis e da problema ao imprimir. Nesses casos altero a propriedade a seguir do componente: ACBrDamdfeFR1.dmDAMDFe.frxReport.EngineOptions.UseGlobalDataSetList := False;

Desculpe Fabio Machado, não recebi a notificação do tópico portanto não tinha visto sua mensagem. Tinha faltado incluir no arquivo .zip a unit alterada. Segue novamente os fontes. ACBrMDFeDAMDFEFRpkg.zip

Boa Tarde Italo. Atualizei os fr3 incluindo o campo da quantidade de MDF-e, e as informações dos documentos. Inclui diretivas para ficar compatível com outras versões do Delphi. FR3-RetratoEPaisagem.zip ACBrMDFeDAMDFEFRpkg.zip DAMDFe_PAISAGEM.pdf DAMDFe_Retrato.pdf

Aqui não tive erro de conversão de string para double. Poderia ser diferença de versão, aqui nós utilizamos o Delphi XE2. Conseguiu identificar onde ocorre? Quanto as informações presentes na NF-e e CT-e, eu criei mais com base no manual, e as informações são mais simples mesmo, alguma informação adicional que achar interessante adicionar, só acrescentar nos fontes.

Componente para DAMDFe em Fast Report. Quem quiser testar, e colocar no SVN... ACBrMDFeDAMDFEFRpkg.zip FR3-RetratoEPaisagem.zip

Obrigada Italo. Irei iniciar os testes, se necessário eu desenvolvo e compartilho aqui.

Boa tarde. Gostaria de saber se alguém já desenvolveu ou está desenvolvendo a impressão do DAMFE para o FastReport.

Estamos testando aos poucos todas as situações. Muito obrigada

Com a última atualização em meus testes ficou ok. Obrigada Italo.

Na última atualização o XML está gerando a tag pICMS com 4 casas decimais. O que está causando erro na validação do XML. Segundo o novo layout serão 4 casas decimais, mas os Esquemas de XML disponibilizados até o momento estão apenas com 2 casas. Corrigindo: São todas as alíquotas, não apenas ICMS.