rhuanrc

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

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.

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 manual do BB utilizado para homologação. Caso estejam de acordo peço que subam para o SVN. Grato. Cnab240PARTICULARIDADES.pdf ACBrBancoBrasil.pas

Bom dia, @Italo Jurisato Junior Atualizado, testado e tudo certo! Obrigado pela atenção.

@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.

@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.

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 testar em versões mais recentes do Fast para verificar se esse "bug" acontece em versões mais novas com a opção habilitada. Peço que analisem a subam para o SVN assim que possível. Obs: percebi que na geração de PDF do DANFE essas configurações estão fixas como False: frxPDFExport.EmbeddedFonts := False; frxPDFExport.Background := False; O correto aqui seria também respeitar o que foi definido em IncorporarFontesPdf e IncorporarBackgroundPdf, mas como o padrão para essas configurações é True, não alterei para não quebrar a compatibilidade. Mas é uma questão para ser analisada. ACBrNFeDANFEFRDM.pas

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

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

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!

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.

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 em todas as notas que tentei enviar.

Desculpa, anexei o arquivo errado. Segue novamente. ACBrDFeSSL.pas

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.

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?