Ir para conteúdo
  • Cadastre-se

joedbat

Membros
  • Total de ítens

    38
  • Registro em

  • Última visita

Tudo que joedbat postou

  1. Bom Dia, Juliomar Na verdade, este é o trecho de código que utilizo para carregar o logotipo do banco de dados. Ele está correto, pois funcionava perfeitamente no trunk1 do acbr. E o mesmo trecho é utilizado para carregar o logotipo na geração do DANF-e, no Trunk2. Apenas no DACT-e, do trunk2, é que o erro ocorre. Att
  2. O carregamento do logotipo do DACT-e (FastReport 5.x) funcionava de maneira correta, ao carregar de um stream, utilizando o código abaixo: imgFR := TLogotipoFR.Create(DadosFilho.qryJoker); stLogo := TStringStream.Create; imgFR.SetEmpresa(FPrincipal.iIDEmpresa); imgFR.Load(stLogo); imgFR.Free; CTe.DACTe.Logo := stLogo.DataString; stLogo.Free; Após a migração para o Trunk2, ao exibir um DACT-e, ocorre um acess violation. Isolando o trecho de código acima (deixando o logo em branco), o DACT-e é exibido corretamente. Att.
  3. Boa tarde, Percebi que o DACTe (FastReport) na versão atual, somente lê o logotipo, a partir de um arquivo. Pesquisando no fórum, vi que o DANFe já permite o carregamento através de um stream. Implementei a mesma solução na unit ACBrCTeDACTEFRDM e modifiquei o arquivo DACTE.fr3, para suportar a modificação. Envio em anexo os arquivos modificados. O arquivo .fr3 está compactado, pois a ferramenta de upload não aceita arquivo .fr3 direto. Testei e a solução funcionou a contento. Deixo registrado meus agradecimentos ao usuário juaumkiko, por prover a solução para o DANFe O exemplo do tópico pode ser utilizado como base para utilização no DACTe. Att, Joemerson de Oliveira ACBrCTeDACTEFRDM.pas DACTE.zip
  4. Atualizei e com a correção realizada, o processo funcionou da maneira esperada Agradeço pelo rápido retorno. Att, Joemerson de Oliveira Intelitime Soluções Ltda
  5. Olá, Bom dia. Ao carregar o xml de um evento transmitido, para impressão, ocorre um erro de "access violation". O problema está na unit ACBrNFEDANFEFRDM, no método frxReportBeforePrint, na linha 1736, pois o método está tentando verificar o modelo da NFe, para gerar o QRCode. Entretanto, se não houver nota carregada, o Objeto NFe estará com o valor nil, o que causa o erro. Caso uma NFe tenha sido visualizada / impressa anteriormente, o erro não irá ocorrer, mas como por vezes o usuário precisa imprimir apenas o evento, o erro acaba por se manifestar. Acredito que uma possível solução seria testar se o objeto está atribuido antes de verificar o modelo da NFe. Att, Joemerson de Oliveira Intelitime Soluções Ltda
  6. Boa tarde, Na procedure TdmACBrCTeFR.CarregaTomador, caso o tomador seja diferente do Remente, o campo Nro, não está sendo atribuido. Consequentemente, no DACTe o tomador pode ficar com o campo número incorreto (Em testes percebi que ele as vezes pega do recebedor). Segue em anexo a unit corrigida. ACBrCTeDACTEFRDM.pas
  7. Achei que apenas os mantenedores do código podiam enviar units alteradas. Bem, de qualquer forma, segue em anexo a unit com as correções. ACBrCTeDACTEFRDM.pas
  8. Boa tarde, Quando é informado CPF para o Recebedor / Destinatario / Expedidor / Recebedor e também para o tomador, independente de qual seja, a documentação é formata como se fosse CNPJ. Isto ocorre devido ao fato de que a função utilizada é a DFeUtil.FormatarCNPJ, ao invés da função DFeUtil.FormatarCNPJCPF. Utilizei a versão que se encontra no repositório e realizei as correções sugeridas. Resolveu o problema. A ocorrência se dá nas seguintes linhas, do arquivo ACBrCTeDACTEFRDM.pas: Expedidor : 679 Recebedor : 1226 Remetente : 1280 E para o tomador, nas linhas Remente: 1391 Destinatario: 1415 Expedidor: 1437 Recebedor: 1459 Outros: 1483 Att, Joemerson de Oliveira
  9. Italo e Rafael, Eu é que agradeço pela rápida resposta. Grato, Joemerson de Oliveira
  10. Até o momento, apenas este endereço apresentou problema. Os demais, para homologação, estão funcionando corretamente. O endereço correto, informado pela SEFAZ-MT para a homologação da recepção de eventos é: https://homologacao.sefaz.mt.gov.br/ctews2/services/CteRecepcaoEvento Caso surja alguma outra eventualidade, reportarei no fórum. Ou há outro canal para este tipo de report? Atenciosamente, Joemerson de Oliveira
  11. Boa tarde, Rafael Na verdade, apesar de o site estar acessível, adicionando a exceção de segurança, no browser, não há nenhum serviço disponível. Durante a execução do teste, o componente ACBRCte recebia uma string vazia. Ao verificar a origem do problema, analisei a string sem tratamento e percebi que a mensagem era exatamente esta, de que não havia nenhum serviço disponível. Consultei a SEFAZ a respeito disto e me indicaram o outro endereço para a realização dos testes. Apliquei a alteração na unit ACBrCTeUtil.pas e o processo funcionou corretamente. Abraços, Joemerson
  12. Olá, Ao testar o envio de eventos, em homologação, para a SEFAZ-MT, observei que o endereço do Webservice está incorreto. Realizei a alteração e funcionou corretamente. Segue abaixo dados detalhados para a correção: Unit: ACBrCTeUtil.pas Linha: 574 Está: https://homologacao.sefaz.mt.gov.br/ctews/services/cteRecepcaoEvento Deveria ser: https://homologacao.sefaz.mt.gov.br/ctews2/services/CteRecepcaoEvento Abraços, Joemerson de Oliveira
  13. Eu tentei reportar o Bug no Mantis, mas a página de registro não está aceitando novos usuários. Como o Bug a meu ver é sério, achei importante relatar, apesar de estar utilizando o canal incorreto. O que identifiquei foi o seguinte: Na unit pceCTeW, na procedure GerarEnderExped (linha 726) a UF passada para a função AjustarMunicipioUF é a do Emitente, quando deveria ser a do Expedidor. Isto causa um erro, caso o expedidor seja de uma uf e o emitente de outra. Agradeço aos colegas registrados no mantis, se puderem reportar este bug para que seja realizada a correção no SVN
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.

The popup will be closed in 10 segundos...