Daniel Braz de Oliveira

É só uma prática. Depois de rodar os sistemas na nova atualização, apago a pasta anterior. Identifico com a data que baixei. Voltando ao tópico, apesar do segimento R ficar zerado agora, com a inclusão da tag dataMulta, o banco não recusou e registrou o título, mas ainda assim fica sem a informação de quando e nem quanto cobrar de multa por atraso no pagamento. Antes desta inclusão a posição fica com '31121899' gerando a rejeição.

Bom dia Juliomar. Tenho por prática a cada atualização do Acbr, salvar em nova pasta e reinstalar tudo. É este bloco q comentei, do acbrBancoItau.pas. Inicia linha 568 {Segmento R} if(MatchText(TipoOcorrenciaRemessa,['01','49','31']))then begin ListTransacao.Add(IntToStrZero(ACBrBanco.Numero,3) + // 001 a 003 - Codigo do Banco '0001' + // 004 a 007 - Lote de Serviço '3' + // 008 a 008 - Registro Detalhe IntToStrZero(fpQtdRegsLote + 1 ,5) + // 009 a 013 - Seq. Registro do Lote 'R' + // 014 a 014 - Codigo do Segmento registro detalhe ' ' + // 015 a 015 - Complemento de Registro TipoOcorrenciaRemessa + // 016 a 017 - Identificação da Ocorrencia ===> linha 576. Daqui já pula pra linha 605, ignorando todos os comandos seguinte. Grato.

Boa noite. Sim, Juliomar. É no segmento R, mas quando chega no método tipodeocorrência, no caso '01', coluna 16 e 17, já pula pro final e gera o registro zerado.

Boa noite. Na geração da remessa para o banco Itau, não estou conseguindo gravar a informação de codigo de multa, data para cobrança e valor/percentual da multa. Informei no objeto: CodigoMulta := cmPercentual; DataMulta := IncDay(Vencimento,1); PercentualMulta := v_multa; Mas no arquivo texto gerado, o campos de 66 a 89 ficam zerados. Preciso marcar alguma outra coisa ? Até 30/04/2022, não era informado o codigo e a data da multa. Já atulizei hoje todos os componentes. Grato.

Prezados. Encontrado o problema. Realmente, a dica do Victor complementou todas as outras. Na rotina do faturamento, que entecede o borderô e a remessa há uma instrução do SetRoundMode(rmUp); E fui eu quem pus lá. Me lembrei que no final do ano, a pessoa do financeiro me passou a reclamação de um cliente que queria que fosse alterado o arredondamento da nota fiscal, pois como era orgão público tinham uma política rígida. Sinceramente, não sei porque eu inseri esta instrução. Por ora, problema está resolvido quanto à geração da remessa na 'mesma sessão', resumindo assim. Agora vou rever a rotina do faturamento e tentar entender porque a instrução está lá. Agradeço a todos que cooperaram e foram me abrindo a mente. Quem está no meio do problema, geralmente olha sómente numa direção. Se cumpriu aqui o que está no livro de Provérbios 24:6b - 'há sabedora na multidão de conselheiros'. Valeu mesmo gente. Abraço.

Victor, creio que sim. Mas o módulo de nota fiscal é executado em separado, então não teria influência neste caso.

Victor, bom dia. Sinceramente, não tive paciência ainda em tentar descobrir isso. Adicionou uma instrução para setar para rmNearest e à principio funcionou. Vou fazer testes ao longo do dia. Agradeço a todos que

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.