Jump to content
Notícias do ACBr

click.png

click.png

click.png

click.png

click.png

click.png

click.png

click.png

click.png

consultoria_sticker.png

Conteúdo para desenvolvedores
 ao vivo de terça a quinta!
Saiba mais

dev.png

logo_acbr_paygo.png

TEF ACBr PayGo
Seja um revendedor e ofereça uma solução completa para seu cliente.


Saiba mais

beneficios.png

rhuanrc

Membros
  • Content Count

    21
  • Joined

  • Last visited

Community Reputation

14 Good

2 Followers

About rhuanrc

  • Rank
    Novato

Profile Information

  • Sexo
    Masculino
  • Location
    Timbó, SC

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Boa tarde, Juliana! Sem problemas, eu também acabei esquecendo de cobrar um retorno e percebi por um acaso que estava sem resposta Segue em anexo a unit alterada com as últimas alterações do SVN. ACBrBancoSantander.pas
  2. Boa tarde! Abri esse tópico há quase um ano e não obtive resposta. Verifiquei que essa alteração ainda não foi passada ao SVN. Podem verificar, por favor? Meu receio é acabar sobrescrevendo o fonte sem perceber e acabar perdendo essa alteração. Grato.
  3. Boa tarde! Realizei um ajuste na geração da remessa do Banco do Brasil para enviar no campo "Identificação da Distribuição" (Posição 62 do Segmento P) a opção "3 - Banco envia e-mail" quando a propriedade ACBrTitulo.CarteiraEnvio for tceBancoEmail. No leiaute do próprio BB esse campo possui a observação "Campo não tratado pelo Banco do Brasil.", porém uma homologação de remessa foi rejeitada por não enviar essa opção quando no campo "08.3S - Identificação da Impressão" (Posição 18 do Segmento S) informei "8 - Bloqueto por email". Em anexo envio a unit alterada para análise e o m
  4. Bom dia, @Italo Jurisato Junior Atualizado, testado e tudo certo! Obrigado pela atenção.
  5. @EMBarbosa, em nossa aplicação utilizamos uma mesma rotina para gerar o XML de NF-e e NFC-e, que é usado posteriormente na impressão. A impressão de NFC-e no ACBr não possui esse tratamento de adicionar o "ponto-e-vírgula" automaticamente no InfAdFisco. Para não ter que tratar para retirar ou não o "ponto-e-vírgula" dependendo do modelo de nota, optei por tratar isso na própria geração do report do DANFE. Como também essa alteração não gera nenhum impacto maior, para mim ficou mais fácil fazer de forma.
  6. @EMBarbosa, Fiz os testes e funcionou perfeitamente! Apenas uma sugestão: não seria melhor alterar o default dessas configurações no construtor para False para manter a compatibilidade? Como antes na geração do PDF do DANFE estavam fixas como False, quem atualizar os fontes e não informá-las para o componente o default passará a ser True, podendo ocasionar o aumento de tamanho do arquivo PDF ou até enfrentar o A.V. que estava ocorrendo para mim.
  7. Boa tarde! Ao gerar o PDF da Carta de Correção usando Fast estava ocorrendo erro de Access Violation. Analisando a situação, verifiquei que o problema é um bug na versão do Fast Report que utilizamos na empresa (5.1.12), quando a opção frxPDFExport.EmbeddedFonts está ativa. Para resolver o problema realizei o tratamento para que a geração do PDF de Eventos respeite as configurações IncorporarFontesPdf e IncorporarBackgroundPdf do componente. Dessa forma, fica a critério de quem for gerar habilitar ou não essas opções. No meu caso deixei desabilitado e passou a funcionar. Não consegui test
  8. Olá! Realizei uma alteração simples na função que trata a quebra de linha da tag InfAdFisco para impressão do DANFE. Apenas tratei para não incluir o ponto-e-vírgula caso já exista no último dígito. Meu sistema já inclui a quebra antes de enviar para o componente e acabava gerando uma quebra dupla na impressão. Peço que analisem e subam para o SVN se estiverem de acordo. ACBrDFeDANFeReport.pas
  9. Boa tarde! Adicionei as seguintes ocorrências que estavam faltando no método TACBrBancoSantander.CodOcorrenciaToTipoRemessa: 10 : Result:= toRemessaConcederDesconto; {Concessão de Desconto} 11 : Result:= toRemessaCancelarDesconto; {Cancelamento de desconto} 31 : Result:= toRemessaAlterarOutrosDados; {Alteração de outros dados} Peço que analisem e subam para o SVN se possível. ACBrBancoSantander.pas
  10. Muito bom! Funcionou perfeitamente. Na minha primeira tentativa tinha desabilitado o FreeOnTerminate, mas sua implementação ficou melhor e mais limpa. Quando quiserem podem subir o fonte ao SVN. Obrigado pela atenção, Daniel!
  11. Perfeito, Daniel! Fiz os testes com a mudança de visibilidade do HttpSendCriticalSection e funcionou bem. Acredito que resolva a questão da concorrência de envios que citei em minha dúvida inicial.
  12. Fiz testes usando a unit que você alterou e voltou a acontecer o A.V. Consegui simular da seguinte forma: - Adicionei um "raise exception" dentro do Execute da thread apenas para forçar um erro qualquer. - Fiz o envio de algumas notas em sequência. Em algumas notas ocorreu o A.V. no finally do código que pega as informações da thread após finalizá-la, conforme o comentário que coloquei abaixo: Parece-me que após Abortar a thread no tratamento de exceção e antes de capturar as mensagens de Response e ExceptMessage a thread está sendo liberada. Esse problema não aconteceu
  13. Desculpa, anexei o arquivo errado. Segue novamente. ACBrDFeSSL.pas
  14. Vou realizar alguns testes sem as seções críticas e verificar o comportamento. Apenas levantei esse questionamento para entender, porque o comentário do SVN que implementou essa alteração (Revision 15240) cita que foi adicionado isto para evitar A.V. em algumas situações, mas não cita quais e não tem nenhum tópico referente ao problema. Obrigado pelos esclarecimentos, Daniel.
  15. Então mesmo que eu tenha duas instâncias de ACBrNFe, criadas em threads separadas, as duas não podem realizar envios ao mesmo tempo porque o objeto FSSLHttpClass possui métodos que não podem ser acessados simultaneamente?
×
×
  • Create New...