Ir para conteúdo
  • Cadastre-se

guarasemini

Membros
  • Total de ítens

    62
  • Registro em

  • Última visita

Posts postados por guarasemini

  1. Boa tarde a todos.

    Estou com problema para emissão d NFCe quando por dentro de RDP.

    Já verifiquei o conteúdo do cUF, coloquei breakpoint e mesmo showmessage para conferir se está sendo enviada somente uma nota (NotasFiscais.count).

     

    O estranho é que se eu executar pelo meu pc, ou direto no pc, o problema não ocorre, se eu fizer atraves de RDP, sempre ao enviar apresenta "UF não pode ser vazia", e ocorre na acbrDFE.pas.

     

    Estou colocando o XML que salvei pelo componente no logo apos assinar e validar, ou seja, antes de enviar. Eu não consegui localizar nenhum problema no xml.

     

    Agradeço a todos pela atenção.

    35221253437315000400650010000000011172042772-nfe.xml

  2. Sim, já fiz essa alteração, mas o acbrNFe retorna: "Rejeição: Solicitada resposta assincrona para lote somente 1 (uma) NFC-e"

     

    essa situação é uma particularidade para SP.

     

    Eu já tenho implementado NFe e NFCe conforme regras, mas vi hoje que SP permite ambos modos. Minha duvida era se existe no acbrNFe um grande 'IF" para SP ou alguma propriedade que ignoraria de rejeição.

  3. Bom dia para todos.
    Estou tendo um access violation quando uso o ImprimirPDF utilizando a DANFE pelo FastReport.

    Meu Fast está na versão 5.1.5.
    Meus fontes estão no build 16940.

    Vi um tópico onde havia um problema com o EmbeddedFonts e o Background do pdfExport.
    Se eu deixar ambas com false o erro não aparece, mas o PDF fica corrompido para alguns clientes.

    O preview aparece sem nenhum o problema. O problema é somente quando utilizo "ImprimirPDF" ou direto a exportação pelo preview.

    Alguém poderia ajudar ?

    Desde já, obrigado pela atenção.

  4. Boa tarde para todos.

    Depois de muito testar e pesquisar e comparar cabeçalho e assinatura dos emails, vi junto com outro programador uma seguinte curiosidade que, ao altera-la, funcionou tudo como funcionava antes.

     

    Na unit ACbrMail, linha 722 (MimePartAttach.Disposition := inline'), eu alterei o disposition para 'attachment', assim, forçando como anexo e para não utilizar recursos internos do cliente de email ou da ferramenta que irá ler.

     

    Com isso, o indy passou a considerar o XML como anexo e não como idText. Pude salvar e manipular o arquivo.

     

    Em outro termos....se recebo pelo outlook, por exemplo, não apresenta nenhum problema, já, se recebo pelo indy, com essa alteração não apresentou problema.

     

    Não saberia dizer porque estava fixo como 'inline', mas apresento aqui a solução que encontrei para analise da equipe.

     

    Estarei realizando mais testes durante todos esses dias e em caso de alguma divergência como o que disse, volto a postar.

  5. Boa tarde.

    Coloquei hoje em produção na empresa a NFe 4.0 e me deparei com um problema que não esperava.

    Temos uma rotina que usa idMessage para se conectar e pegar os emails enviados pelo AcBrMail, utilizando no NotasFiscais[0].EnviarEmail.

    E na rotina de receber, pego as partes do email e verifico os anexos, para fazer entrada no banco.

    Porém, com a versão mais recente dos componentes, o arquivo XML passou a não ser considerado um anexo e assim um simples idText.

     

    Já realizei testes adicionando manualmente o XML pelo outlook e funciona.

    Já tentei adicionar no Tstrings de anexo o arquivo XML e mesmo assim não ficou como anexo.

    Já fiz o teste pelo exemplo e o problema é o mesmo.

     

    Não alterei nada nas configurações do componente no que diz respeito a default charset e IDE charset.

     

    Voltei a versão do meu executavel para antes dos componentes NFe 4 (de novembro) e executei a mesma rotina...dai não apresenta problema e o arquivo XML passa a ser um TidAttachament.

     

    Vi pelo menos 1 post no forum que tocou no assunto mas não houve nenhuma conclusão sobre o problema.

     

    Alguém passando ou passou por isso ?

     

    Desde já, obrigado pela atenção.

  6. Bom, para retorno...

    refiz minha rotina, basicamente antes eu passava por parametro um stringList para uma função no meu server datasnap, que recebia e colocava dentro de uma classe generica para repassava para mais 2 funções internas. Tenho CERTEZA que no processo estava destruindo algo que não deveria, mas preferi refazer, fazendo a função já retornar minha classe completa e gerando o stringList no client.

     

    Fiz algumas dezenas de testes e não apresentou mais access violation.

    Obrigado a todos pela atenção e ajuda.

  7. Bom dia para todos.
     

    Estou com um problema bastante estranho no meu ACBrMail.

    Tenho uma rotina simples...

      ACBrMail1.From      := '[email protected]';
      ACBrMail1.FromName  := 'Faturamento';
      ACBrMail1.Host      := 'smtp.empresa.com.br';
      ACBrMail1.Password  := 'senha';
      ACBrMail1.Port      := '587';
      ACBrMail1.Subject   := 'REF - assunto';
      ACBrMail1.Username  := '[email protected]';
      ACBrMail1.AddAddress('[email protected]');
    
      ACBrMail1.AltBody.Assign(aMensagem); --> aMensagem é um TStringList
      ACBrMail1.Send(false);

     

    Quando do Send, ele apresenta access violation em fAltBody.SaveToStream(DecodedLines); (linha 557 do ACBMail.pas). 

    Tentei pelo DEMO e o erro não acontece. 

    Dai no nada enviou a msg pelo meu sistema, fui testar novamente...não envia e tenho o acess violation.

     

    As demais propriedades estão setadas direto no componente. Que funciona sem nenhum problema para o envio de NFe.

     

    Alguém poderia dar alguma ideia ?

    Desde já, obrigado a atenção de todos.

     

    Rafael

     

  8. Bom dia para todos.

    Desculpe minha insistência, mas ninguém tem alguma ideia ? Ontem (08/09) fico boa parte da tarde sem nenhum problema, mas já hoje cedo (09/09), começou na maioria das NFs.

     

    Novamente, obrigado a todos pela atenção

  9. Boa tarde para todos.

    Estou com um problema bastante estranho por aqui.

    Meu ambiente é: 

    Delphi XE7

    AcBr no truck 

    Dlls do svn com openSSL 0.9.8.14

     

    Quando do envio do email pela função "NotasFiscais[0].EnviarEmail", as vezes, sim...nem sempre mesmo repetindo a mesma operação eu recebo um access violation no seguinte bloco de codigo

    function TMimeMess.AddPartHTML(const Value: TStrings; const PartParent: TMimePart): TMimepart;
    begin
      Result := AddPart(PartParent);
      with Result do
      begin
        Value.SaveToStream(DecodedLines); <--
     AQUI
        Primary := 'text';
        Secondary := 'html';
        Description := 'HTML text';
        Disposition := 'inline';
        CharsetCode := UTF_8;
        EncodingCode := ME_QUOTED_PRINTABLE;
        EncodePart;
        EncodePartHeader;
      end;
    end;

    Já mudei dlls, desinstalei e recoloquei o AcBr, mas o problema persiste. Envio 10, 20 NFs e do nada acontece bem ai (cheguei até ai com o Eureka)

    Não sei mais o que fazer.

    Se alguém puder me dar um norte seria de enorme ajuda.

    Desde já, obrigado pela atenção de todos.

  10. Bom dia a todos.

     

    Eu já fiz essa mudança de colocar o title no header, o problema é que existe acesso pelo componente ao title, dai, eu teria que mudar mais coisas dentro do componente para não ler mais de alguns lugares e ler em outros. Isso não seria grande problema, mas em qualquer atualização que tiver, tenho que alterar novamente, gerando retrabalho e tudo mais.

     

    Sobre aumentar a altura, também já fiz, mas não funciona como eu gostaria. Tentei editar o fr3, adicionando um evento para aumentar o tamanho na segunda pagina, mas não obtive um bom resultado.

    Não quero mudar muito ao ponto de ter que refazer trabalho sempre que houver uma atualização.

     

    Independente disso, obrigado pela atenção na resposta.

  11. Obrigado pela ajuda.

     

    Mas não existe esse tipo de código no fast. O canhoto foi definido como PageTitle e ele é impresso somente 1x (controle do proprio fast).

    Tentei muda-lo para pageHeader, mas não dá também, pois só pode ter 1 por pagina.

    Peguei o conteudo do Canhoto e joguei no Emitente, não dá, pois o componente da DANFE busca em diversos lugares o Canhoto e mudar isso seria um pouco mais trabalhoso.

     

    Então tentei via evento do fast, no afterPrint do Canhoto, setar o top do Emitente, mas não funcionou também.

     

    Alguem tem mais alguma ideia ?

     

    Desde ja, obrigado pela atenção de todos.

  12. Bom dia para todos.

    Estou com mais um problema na impressão da DANFE.

    Utilizo delphi xe7 com DANFE em Fast, sendo o arquivo DANFERetrato.fr3.

     

    Aqui na empresa, a DANFE é impressa em um formulário pre-impresso com o logo e mais algumas informações da empresa. 

    Na primeira pagina, a impressão é sem problemas, mas na segunda pagina, como não tem o canhoto (dá para colocar ?), ele imprime desde o topo, dai fica sobrepondo as informações pre-impressas.

     

    O que posso fazer para ajudar isso ? Teria como colocar o canhoto para todas as paginas (isso resolveria) ? Ou há algo mais ?

     

    Novamente, obrigado pela atenção de todos.

  13. Boa tarde pessoal.

     

    Meu ambiente é delphi xe7 + Danfe FastReport.

     

    Estou com o seguinte problema:

     

    . Como informo pela DANFE qual bandeja deve ser impressa ? Aqui, dependente do cliente a Danfe é enviada em bandejas diferentes, algo que se fosse direto pelo Fast dá para se fazer, mas como informar na Danfe o "bin" da bandeja que será impressa ?

     

    Não teria como eu fixar isso no .fr3 pois muda a todo momento, então tem que ser em RunTime mesmo. Não estou querendo mexer no fonte da Danfe, mas é uma opção também, mas somente se realmente não existir alguma outra opção.

     

    Bom, se alguém fez isso e puder ajudar.

     

    Desde já, obrigado a atenção de todos.

     

×
×
  • 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.