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?

Já utilizo o TimeOutPorThread em alguns clientes e notei esse mesmo comportamento de "bloqueio". A execução da TDFeSendThread também possui a Critical Section. A variável HttpSendCriticalSection é global e criada no initialization da unit (o que está correto). A seção crítica impede que qualquer outra thread acesse o envio. Acredito que no caso da TimeOutPorThread estar ativa a Critical Section é interessante (não tenho certeza, teria que fazer mais testes), mas quando está desativada não vejo motivo.

Entendo, mas no caso do nosso concentrador é criada uma instância do objeto ACBrNFe para cada envio realizado, então os recursos não estariam compartilhados. Posso estar enganado, mas o Critical Section impede o acesso àquele bloco de código independente de quem está acessando.

Daniel, Está em ambos os casos: com e sem a configuração TimeOutPorThread. Inclusive essa parte do código que postei é no ELSE da verificação do TimeOutPorThread.

Olá! Gostaria de entender/saber o motivo de existir um Critical Section no método TDFeSSL.Enviar. Segue trecho do código: HttpSendCriticalSection.Acquire; try Result := FSSLHttpClass.Enviar(ConteudoXML, AURL, ASoapAction, AMimeType); finally HttpSendCriticalSection.Release; end; Da forma como está não é possível realizar envios simultâneos. Questiono isso pois tenho clientes que possuem muitos PDVs realizando vendas simultaneamente e acaba criando um gargalo de envios, pois um fica aguardando o outro, afetando também o timeout de resposta. Existe a possibilidade de remover esse Critical Section ou é alguma limitação/problema que ainda precisa ser resolvido? Se alguém puder me dar maiores detalhes, agradeço.

Olá! Estou usando a configuração TimeOutPorThread (criada na revisão 14797) e estava enfrentando alguns erros de Access Violation em alguns clientes. Analisando verifiquei que o erro estava no método Enviar da classe TDFeSSL, mais especificamente no bloco abaixo: EndTime := IncSecond(now,TruncFix(TimeOut/1000)); SendThread := TDFeSendThread.Create( Self, TDFeSSLHttpClassOf(FSSLHttpClass.ClassType), ConteudoXML, AURL, ASoapAction, AMimeType); try while (SendThread.Response = '') and (Now <= EndTime) do Sleep(50); finally Result := SendThread.Response; SendThread.Abort; end; A TDFeSendThread não tinha nenhum tratamento de exceção no Execute e quando ocorriam erros na execução, como um erro de conexão ou sem Internet, a thread era abortada e no finally a variável SendThread já não existia mais, causando o AV. Acontecia esporadicamente e não era muito fácil de simular. Para corrigir o problema, implementei um tratamento de exceção no Execute da thread e tratei para abortar o while de verificação caso algum erro ocorra. Também alterei para que a thread fosse liberada manualmente ao final do envio. Peço que analisem e subam para o SVN se possível. ACBrDFeSSL.pas

Olá! A geração do XML para SAT já possui o tratamento para considerar a configuração RetiraEspacos na geração do XML de venda e cancelamento, mas não possui essa propriedade exposta para ativar/desativar. Fiz a implementação nas units pcnCFe e pcnCFeCanc. Peço que validem e subam para o SVN se possível. Abraços. pcnCFeCanc.pas pcnCFe.pas