Frederico Hahn Pesenti

Deu certo! Muito obrigado!

Bom dia, obrigado, vou fazer os testes e retorno.

Obrigado pela atenção @Italo Giurizzato Junior, se possível, peço certa urgência pois já estamos a quatro dias sem emitir notas pelo ACBr em Porto Alegre.

Bom dia, @mkonat, tu estas usando o monitor ou a lib? A solução do @Fabiano Oliveira de Castro só funciona direto no Delphi. Identificamos na sexta que, mesmo colocando a configuração no INI, a mudança de valor não vai para o XML mesmo usando a lib ou o monitor atualizados na sexta-feira.

Continua com problema, está correta a grafia do meu INI? Vi que todas as outras configurações começam com letra maiúscula.

Bom dia pessoal, desculpa reviver a questão mas, este erro continua aparecendo para Porto Alegre, RS. A obrigatoriedade de ME/EPP no Gov.br era para ter começado dia 01/11 mas em função daquele outro problema que discutimos aqui bastante foi postergada para hoje. Parou de dar aquele erro do mês passado mas agora fica aparecendo esse E0690... alguém daqui conseguiu emitir? Eu uso o monitor na versão 1.4.0.211, tentei alimentar via INI indTotTrib = 1 e pTotTribSN mas percebi que no XML a ser enviado o indTotTrib continua como zero.

Estava até o meio da manhã tentando enviar por ele e estava dando erro de timeout, agora consegui enviar. Usar o "antigo" me preocupa porque ontem falei com um atendente da prefeitura e ele disse que quando virou pro MEI e o pessoal ignorou a mudança, tiveram que reemitir tudo de novo no Gov.br.

Obrigado. Essa mudança do Banrisul nos foi forçada, temos clientes que usam CNAB 400, CNAB 240 com padrão antigo, todos funcionando perfeitamente. Agora no fim do ano eles definiram que todas as novas homologações devem usar apenas o formato novo.

Bom dia, estou usando o novo, 10.3, 240 posições.

Boa tarde pessoal, primeiro quero agradecer o empenho do colega por fazer as modificações, estão funcionando muito bem, tivemos apenas que mudar algumas parâmetros na alimentação do componente e usar o Convênio, que antes não usávamos para este banco. Só para tocar em mais um ponto deste assunto, em relação à protestos, vi que o ACBrBancoBanrisul.pas apenas considera a variável CodigoNegativacao e não a TipoDiasProtesto que era usada anteriormente (não sei se antes das mudanças já era assim). Vi que ACBrBancoBrasil.pas e ACBrBancoItau.pas fazem uso das duas variáveis (CodigoNegativacao e TipoDiasProtesto). Além destes 3 bancos citados apenas ACBrBancoBancoob.pas, ACBrBancoBanestes.pas e ACBrBancoCecred.pas utilizam CodigoNegativacao. Os demais estão todos utilizando TipoDiasProtesto ou DefineTipoDiasProtesto. Minha pergunta é, em relação à padronização, devemos considerar as duas como coisas distintas, variando de um banco para outro ou conseguimos chegar a um meio comum de configuração?

Boa tarde, nova cidade: [5200258] Nome=Aguas Lindas de Goias UF=GO Provedor=Prodata NomeURL_H=200.199.213.78:8080 NomeURL_P=200.199.213.78:8080

O provedor DIGIFRED para a cidade de Ernestina no RS exige que só seja incluída a TAG de CodigoPais quando for um país diferente do Brasil, resultando nos erros abaixo: CEP do tomador do servico informado indevidamente. Nao informe o CEP do tomador do servico quando ele for domiciliado no exterior. CPF/CNPJ do tomador do servico informado indevidamente. Nao informe o CPF/CNPJ do tomador do servico quando ele for domiciliado no exterior. Pais da prestacao do servico indevido. O codigo do pais da prestacao do servico somente devera ser informado quando a exigibilidade do ISS for 4-Exportacao. Pais da prestacao do servico indevido. O codigo do pais da prestacao do servico somente devera ser informado quando a exigibilidade do ISS for 4-Exportacao. Pais do tomador do servico indevido. O codigo do pais do tomador do servico somente devera ser informado quando o municipio for igual a <9999999>. Fiz as correções e anexei abaixo. Não sei como ficam para outras cidades com o mesmo provedor. pnfsNFSeW_ABRASFv2.pas Cidades.INI

Obrigado Gabriel, mas na realidade, o que estava "errado" era a modalidade, não a carteira, alterando de 101 para 104 a linha digitável ficou igual a do banco e a remessa não se modificou. Obrigado a todos pela atenção!

Lendo o o código de barras, os números são os mesmos da linha digitável. Vou verificar, mas o que ocorre hoje é que os boletos enviados pelos correios têm a mesma linha digitável dos boletos reemitidos pela web no site do banco, mas quando mando criar o PDF deles no ACBr, muda a linha digitável.

Boa tarde, hoje temos configurado no ACBr a emissão dos boletos pelo banco, logo, geramos os boletos e os clientes recebem os mesmos por correio, tudo feito direto pelo banco. Para facilitar a vida dos clientes e contornar os problemas recorrentes de entrega por parte dos correios, enviamos também "lembretes de vencimento" por e-mail. Fazemos isso há pelo menos 3 anos já. Antes utilizávamos o Banrisul e hoje utilizamos o Santander. A questão é que, para os dois bancos, a linha digitável impressa pelo banco sempre foi ligeiramente diferente à gerada pelo ACBr, até cheguei a criar uma postagem sobre isso aqui certa vez (https://www.projetoacbr.com.br/forum/topic/23429-linha-digitável-de-boletos-do-banrisul-gerados-pelo-acbr-diferente-do-boleto-enviado-pelo-banco), mas como nunca tive problemas com isso pois, indiferente do cliente pagar com um ou com outro, o dinheiro entrava na minha conta e o boleto era liquidado normalmente, não levamos a discussão à frente. O problema é que, depois das últimas reformas da Febraban e da unificação do recebimento de boletos, meus clientes que tentam pagar pela linha digitável recebida por e-mail recebem um aviso de erro dizendo que o título é inválido, certamente pela diferença na linha digitável. Seguem exemplos: ACBr 03399918125200000000101413301019776840000023000 Santander 03399918125200000000101413301043176840000023000 Alguém já notou isso? Santander.pdf ACBr.pdf