Daniel Braz de Oliveira

Resolvido.
Devia ser alguma instabilidade no servidores da SEFAZ-PR
Reenviado com sucesso.
 

Desculpe... ato falho.
Com o ';' funcionou.
Acabei reabrindo o xml errado..
 

Bom dia a todos.
EStou marcando este post como resolvido.
Mas na verdade ficou o mistério.
Refiz diversas vezes o processo da instalação do D7 e não importanto a sequencia de registro dos componentes, quando instalava o ACBR via instalador, havia os conflitos com o Indy10 e o UserControl. Cheguei a criar uma VM, pensando que pudesse ser conflito com o Rad10.4, que também tem estes componentes instalados, mas foi a mesma coisa.
Resolvi, instalando o ACBR manualmente, conforme o guia que está no trunk2, o que me leva a crer que há alguma coisa com o instalador, que por algum motivo desconhecido, tem gerado este erro. Sei que parece ser insano isso, pois até agora ninguém relatou situação semelhante.
Como resolvi por aqui, só fica mesmo o meu relato.
Obrigado ao Juliomar pela interação.,
 

Fechando este assunto.
Na unit do banco santander, há uma rotina, que foi alterada recentemente creio, pois no fonte de março estava diferente.
A função DefineNumeroDocumentoModulo agora faz distinção do layout c240 e c400.
Vou alterar a minha rotina de emissão de boletos e remessa, setando o cnab240.
Obrigado.
 

Bom dia.
Fiz procedimento indicado, inclusive baixando o isscuritiba.ini do Rodrigo, mas agora recebo mensagem de xml corrompido:
O lote de RPS Nº 20230303026 com o protocolo Nº 638138692052876318 está corrompido. Verifique as tags e seus conteúdos e retransmita o lote de RPS.

 

Prezados, era um erro de instabilidade na Prefeitura.
O estranho foi a mensagem, relacionada a estrutura do xml.
Pode fechar o chamado.

Em tempo, já me encontrei aqui.
Na verdade,  a VlVersao115 equivale à versão 016.
Pode fechar o chamado.
 

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.
 

Ítalo, bom dia.
Desculpe pelo ato falho. Queria destacar em qual parte do codigo que via o erro, através do debug.
Na verdade, meu problema é o de não conseguir homologar as notas do sentido completo: enviar, registrar e receber o retorno
A última parte, receber o retorno, retorna um erro não especificado, gerando um tela com 'x' da minha aplicação.
Fazendo o debug, era neste bloco de código que acontece a exceção.
Apesar do site da prefeitura informar que estão com problemas, agora a rotina me dá a mensagem que não encontrou o certificado digitar, embora ele esteja lá.
No componente consigo ler o numero de série, cnpj, emissor, tudo..
Vou aguardar a prefeitura resolver a parte deles e daí tentar descobrir com mais clareza o que está acontecendo.
Se tiver alguma sugestão, agradeço.
 

Pois é, fui marcando e desmarcando opções e testando, até que com SSL=false e TLS=true, funcionou.
Obrigado.
 
Podemos fechar !
Resolvido.