Daniel Braz de Oliveira

Bom dia. Creio que estou chegando à conclusão final. Seguindo a sugestão do BigWings, capturei o SetRoundMode. Quando executo no modo direto, isto é, gerando o borderô e em seguida gerar a remessa que apresente o erro, o SetRoundMode está Mas quando feclho o programa e reabro, quando gera correto está: Pelo jeito, a solução deva ser setar para RmNearest, cada vez que entrar nesta rotina. Vou testar agora e posto aqui na sequencia.

É Renato, lascou mesmo. Ainda mais quando os amigos ficam no domingo tentando ajudar.. Vou testar mais tarde. Obrigado pela ajuda e as dicas de pensar um pouco fora da caixa... Posto aqui depois o resultado.

Resultado da sugestão do Renato. Setei o ValorDocumento = 10.37; No SetValorDocumento, chega 10.37 Depois que aplica a RoundABNT: O valor é alterado. É na função roundABNT que está o problema. Façam as suas apostas, senhores...

Obrigado pela dica, Renato. Vou fazer isso. Respondendo a BigWings, não uso SetRoundMode em nenhum lugar do sistema.

Bom dia Vou explicar o titulo do post. Será um tanto extenso, mas preciso qualificar a situação em busca da solução. Antes de mais nada, quero relatar que já tentei diversas maneiras de contornar este problema. Desde o dia 03/01/2022, estou com esta demanda num cliente. Resumindo: 1 - Temos um rotina de geração do borderô, que é a vinculação do titulo à um banco com a devida carteira e configurações de cada banco. Aqui não uso nada do ACBR. 2 - Depois de pronto o borderô, é gerado o arquivo remessa, onde uso os componentes do ACBR. Agora pasmem: Se a geração da remessa for realizada imeditamente à criação do borderô, embora na tela de conferencia dos titulos, os valores com centavos estejam corretos, pois o sistema já faz todos os calculos de tributos, descontos e retenções antecipadamente, já gerando o contas a receber e os valores para a emissão da notafiscal de serviços com os valores finais, já arredondados, conforme regras financeiras, quando é associado o valor do título ao Titulo.ValorDocumento, os valores com centavos, são acrescidos de 0,01, gerando inconsistências, pois o boleto gerado no sistema está com o valor correto, a nota fiscal emitida com o valor correto, mas o titulo enviado para o banco, com o 0,01 acrescido. Fiz o debug e percebi que o valor é acrescido após a execução deste procedimento do AcbrBoleto: procedure TACBrTitulo.setValorDocumento(const AValue: Currency); begin fValorDocumento := RoundABNT(AValue, 2); end; Quando o foco volta para a instrução Titulo.ValorDocumento ele recebe o valor com 4 casas decimais. Por exemplo, o valor do titulo é 10,37, ele retorna 10,3701, provocando o arredondamento para 10,38. Quando disse acima, 'Agora pasmem', é porque o que vou relatar a seguir é no mínimo inusitado. Se o sistema for fechado e reaberto e for gerado a remessa novamente, os valores todos saem corretamente. Inclusive o mesmo borderô que foi gerado com erro. Sem o acrescimo dos 0,01. Também ficam corretos, se outro usuário, fizer a remessa em outro computador. Se fosse no PHP, eu dia que a 'sessão' da geração borderô ficou com sujeira na memória. A solução paliativa encontrada, foi conversar com o pessoal do financeiro para criar os borderôs e outra pessoa gerar a remessa, ou fechar e reabrir o sistema. Claro que a empresa não gostou muito e me exigiu resolução imediata. Fiz uma alteração na procedure conforme abaixo: procedure TACBrTitulo.setValorDocumento(const AValue: Currency); begin // O arredondamento é com objetivo de remover as diferenças em arredondamentos posteriores, // que causa uma diferença entre o valor do documento e a linha digitável. fValorDocumento := AValue; // testado por daniel - 05-02-2022 end; Onde não executo a função RoundABNT; Os valores ficaram corretos mesmo gerando a remessa na mesma 'sessão' do borderô. Será que posso ter problemas? Afinal o valor enviado pelo banco de dados é exatamente o que deve ser gerado na remessa. Enfim o problema não é a função, mas alguma coisa que influencia a função, dependendo de como foi invocada. Há alguma coisa que eu possa pesquisar ? Como sou um dinossauro, este sistema roda no Delphi 7, com Postgres. E claro, sempre funcionou corretamente. Desculpe o tamanho do texto. Quem quiser dar um pitaco, fique à vontade. Grato.

Bom dia. Desde ontem estamos recebendo este erro. Alguém mais ? Não foi atualizado nada e testado em redes diferentes.

Pois é Juliomar, abri um chamado no suporte, mas não tive retorno ainda. Será que alguém mais reportou erro igual ??

Boa tarde. Pela manhã meu cliente não consegui emitir nfse aqui em Curitiba. Atualizei os componentes, recompilei o projeto e agora recebo este erro. Segue abaixo o rec-soap-xml Alguma ajuda ?? soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <soap:Body> <RecepcionarLoteRpsResponse xmlns="http://www.e-governeapps2.com.br/"> <RecepcionarLoteRpsResult> <NumeroLote xsi:nil="true"/> <DataRecebimento xsi:nil="true"/> <ListaMensagemRetorno> <MensagemRetorno> <Codigo>E504</Codigo> <Mensagem>O certificado digital do prestador de serviços é obrigatório.168.194.162.233168.194.162.233168.194.162.233168.194.162.233</Mensagem> <Correcao>Envie junto a requisição do serviço o certificado digital do prestador de serviços.</Correcao> </MensagemRetorno> </ListaMensagemRetorno> </RecepcionarLoteRpsResult> </RecepcionarLoteRpsResponse> </soap:Body> </soap:Envelope>

Valeu BigWings. Matou a pau. Abraço.

Boa tarde. Meu cliente abriu uma filial no Espirito Santo e eu preciso configurar a emissão de NFe. Acontece que o ambiente de homologação não está funcional. O de produção sim. Homologação: Produção Alguém tem informação sobre isso ? Grato.

ìtalo, atualizei no começo de março. O mais inquietante, é que são 4 usuários, 2 maquinas estão funcionando e 2 não... na mesma rede. Estou verificando as configurações individuais de cada máquina..

Ok, vou tentar aqui. Estou usando as dlls da versão OpenSSL\1.1.1.7\x64. correto ??

Ainda sobre este assunto, a configuração acima está correta ? Com Configuracoes.Geral.SSLHttpLib = httpOpenSSL usando openssl diferente das outras configuraçôes ? Estou com um problema semelhante num cliente com w10. Ítalo qual seria a configuração do SSL_TYPE para usar tudo OpenSSL ? Recebi msg do servidor que OpenSSL era incompatível.

Bom dia. Até o momento as emissões estão executando normalmente. Obrigado mais uma vez pela grande ajuda. Bom semana a todos. Ítalo, valeu de novo meu amigo.

Aproveito o momento e faço mais um questionamento relacionado. Eventualmente acontece uma mensagem igual à abaixo: A unidade m:\ é unidade mapeada da rede onde os xmls são armazenados por cnpj. Será influência do erro da consulta, que alterei os valores de tentativas e tempo de aguardo ? Vou aguardar o pessoal da empresa cliente executar em massa na segunda feira. Grato., Daniel.

Boa tarde Ítalo e demais membros do forum. Estou retornando para informar que depois que ajustei as configurações da consulta do lote após o envio, conforme orientação do Ítalo, não recebi mais nenhum erro no retorno dos xmls. Agradeço imensamente ao Ítalo, pela disposição em me esclarecer alguns fundamentos do componente como um todo e pela paciência com minha insistência na busca da solução. Na segunda vai pra produção e daí retorno o resultado. Bom fim de semana. Daniel.

Obrigado Ítalo. Vou fazer estas alterações e ir testando. Mas só amanhã agora. Obrigado e bom fim de semana. Daniel.

Ítalo, boa tarde. Acabei fazendo meio a meio o que vc orientou, e cheguei no seguinte ponto. Usei minha rotina padrão, com o consultaloteaposenvio = true, e com a ajuda do suporte da prefeitura, fui monitorando quando o xml chegava no servidor. Tui debugando as ações como sempre dava erro logoa pos o envio, coloquei um break na linha 6176 do acbrnfsewebservices, e linha 6193, tem o metodo Result := FEnviarLoteRPS.Executar, vi que o resultado foi true, isso é o xml foi enviado para o servidor. Imeditamente chequei a lista de lotes no servidor, este ainda não estava lá, segui com o debug até a linha 6233, Result := FConsSitLoteRPS.Executar; e antes de executar, chequei novamente a lista do servidor, e o lote estava lá, daí deixei correr a rotina, e finalizou a nota tranquilamente. Creio que se passaram de 8 a 10 segundos até que eu checasse novamente e executasse. Então, como recebia mensagem de erro que o xml não estava no servidor, imagino que a consulta deva ter um delay, não acha ?? Até porque estes que me retornavam a mensagem, quando eu consultava o servidor da prefeitura estavam emitidas regularmente. Consegui me explicar ? Decidi fazer isso, pois atualizei a rotina no cliente para um teste, para capturar os erros de processamento no servidor da prefeitura, e daí a primeira nota processou certinho, a segunda tb, já ia soltar foguete, quando a terceira deu o erro, mas estavam todas geradas na prefeitura. Então me veio a imaginação que talves fosse a consulta do lote, antes da liberação pelo servidor da prefeitura. É a unica explicação que posso ter.. Bem, qual a sua sugestão para alterar o comando da consulta, para atrasar alguns segundos e eu conseguir testar se é isso mesmo ? Muito obrigado pela paciência. Daniel.

Ok, Ítalo. Vou continuar isso agora de tarde.

Ítalo, se eu te passar um certificado válido, vc consegue testar ? Estou com os componentes todos atualizados de ontem, e ainda assim não consigo finalizar o processo. Se puder, me avise como lhe encaminho o certificado de modo seguro. Grato.

Obrigado pela orientação, Ítalo. Vou mexer nisso. Abraço.

Amigos, ainda sobre o meu post anterior. Li algumas mensagens anteriores e entendi que o consulta lote, é exatamente para finalizar o processo. Alterei minha rotina para fazer a consulta ao lote, acionada somente depois do retorno do envio, informando o rps, lote e o tipo. Daí recupero as informações do numero e codigo de verificação para montar o link. Funciona em alguns momentos, em outros recebo a mensagem que o lote não foi enviado para o servidor, embora a nota já esteja gerada, lá. Alguém faz diferente disso ? Poderia compartilhar a experiência ? Voltei o flag para consulta o lote após o envio e fiz um debug mais minucioso. O enviadados, sempre retorna 200; O problema é na consulta ao lote. Depois de algums repetições, ele entra nesta rotina, com erro em branco. Não consegui identifcar, o que faz entrar nestar exception. Pra mim não importa se a consulta é automatica ou comandada por mim, só preciso recuperar o numero da nota e codigo de verificação. Aguardo sugestões. Grato, mais uma vez.

Prezados, eu sempre usei esta propriedade setada como true. Mas de umas semanas para cá, começou a apresentar um erro no processo. A Nota era gerada, mas não retornava o xml e as informações da emissão. Achei que fosse problema de timeout. Hoje fiz um teste deixando esta propriedade como false e gerou rapidamente, sem erro. Só que não retorna o numero da nfse. Ela vem em branco, e consequentemente no link para acessar a nota posteriormente vem sem esta informação. Reduzi o numero de tentativas da emissão para 1, pois fazendo o debug, percebi que na primeira vez já tinha o protocolo gerado, e quando entrava no loop abaixo da linha 6072 até 6135. with TACBrNFSe(FACBrNFSe) do begin if (Configuracoes.Geral.ConsultaLoteAposEnvio) and (Result) then begin na quinta vez, que era o numero de tentativas setadas, retornava false, embora nas 4 primeiras retornasse true, na linha 6139 da unit ACBrNFSeWebServices e daí dá o erro no retorno, mas a nota e gerada. if not (Result) then FConsLote.GerarException( FConsLote.Msg ); Alguma luz ? Todos os componentes atualizados. Meu cliente já está me olhando torto. Grato. Daniel.

Bom dia prezados. Estou tentando homologar uma nova versão do emissor de NFE incluindo as modalidades de forma de pagamento, opções 16 a 19, conforme nota técnica. Quando faço o envio, na geração do xml recebo esta mensagem. 1824 - Element '{http://www.portalfiscal.inf.br/nfe}tpag':'18' is nota valid value of the local atomic type na tag tpag uso FpTransfBancario. Se eu usar uma outra opção, 13 por exemplo, que já estava em uso, gera o xml. Pelo que li, a partir de 01/02/2021, na homologação não será mais aceito o tipo 99-Outros e foram incluidos os codigo de 16 a 19, e que em 01/09/2021, serão obrigatórios na base de produção. Componentes atualizados em fevereiro 2021, e estas opções aparecem no PcnConversao. Alguma sugestão ? Grato pela atenção.

Bom dia! Já uso o AcbrMail com sucesso. Agora um cliente solicitou uma remessa de emails, mas ele quer que o anexo, em PDF, seja apresentado no corpo do email. Alguém tem alguma dica ? É possível fazer isso pelo AcbrMail ? Uma idéia que me ocorreu foi copiar conteudo do .pdf e gravar como Html no corpo. Alguém sugere algo diferente ? Grato. Daniel.