BigWings

Está correto, no caso do ICMS monofásico (CST 02, 15, 53, 61), será usado CST mesmo para emitente do Simples Nacional.

Tente informar o código IBGE da cidade para a tag MunicipioIncidencia em vez do nome.

Talvez esteja relacionado com isto aqui:

Não entendi por que ele precisaria imprimir 3 vezes o mesmo boleto. Todos os layouts já tem a ficha de compensação e o recibo, uma impressão já é suficiente. E tem alguns layouts com o comprovante de entrega, espécie de "canhoto" que pode ser destacado para comprovar que o boleto foi entregue ao pagador.

O erro é de validação contra os schemas, e não rejeição da prefeitura... Nos schemas que estão no SVN para o provedor Giss a alíquota deve ter 4 dígitos:

A via "Ficha de caixa" não existe há muitos anos... hoje é exigida a ficha de compensação e o recibo do pagador apenas. Que saiba não tem nenhum layout do componente que imprima essa via.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Não, está correta, faça o teste.

Me parece que este é o modo correto, qual o erro exato?

A mensagem era essa: Ou esta? Para resolver a primeira teria que voltar o parâmetro Dividir100: Mas não teria como fazer isso apenas com 2 dígitos na alíquota, e usar a alíquota 3,04%

Tem mais relatos desse problema, que nesse caso parece ser na SEFAZ-PR, no Discord do ACBr.

Se está gerando no XML, não tem motivo pra ter a rejeição. O erro é o tratamento da rejeição da SEFAZ, correto? Veja se no XML do lote de envio (*-env-lot.xml) foi gerado o idCSRT e hashCSRT.

Tenta tirar a linha Params=Dividir100: Do arquivo ACBrNFSeXServicos.ini para a cidade em questão.

Não precisa mais desde o dia 01/02/2025, pode usar só NFCe.

Alguns pontos: - O SAT está com os dias contados, a partir de 2026 não será mais permitido em SP e CE, terá que trocar para NFCe - O Bling aparentemente não dá suporte aos usuários que optam pela integração com o ACBrMonitorPLUS para emissão de CFe SAT - O fórum do ACBr é destinado a desenvolvedores, e não usuários finais do ACBrMonitorPLUS Então a sugestão é já optar pela NFCe, creio que o Bling faça isso nativamente.

Já foi enviada uma correção para o SVN, atualize novamente.

Fiz um teste aqui e tive o mesmo erro. Eu acho que o problema é na SEFAZ autorizadora, a SVRS, que não está fazendo a validação correta da NFCe com emitente CPF. A sugestão é entrar em contato na SVRS e questionar.

Faltou fechar com " o comando BOLETO.ConfigurarDados.

Já recebi email que vão descontinuar a V2 em 31/03/2025.

Subi um ajuste porque o acima estava causando erro de compilação no Delphi. @Desenvolvimento Automafour favor atualizar com os fontes do SVN e testar.

Enviei um ajuste para o SVN, rev. 37049, para não exigir o client secret se não informado. Testei na minha própria conta, em produção, migrei da V2 para a V3, só precisei criar o aplicativo novo no portal developers do Sicoob, na nova API, usei o mesmo certificado, e configurar no componente a versão 'V3', o novo Client ID e os novos escopos.

Estranho porque a validação no componente é de janeiro de 2023. Parece ser algo errado com as credenciais, o certificado foi gerado e enviado para o banco na criação da aplicação? Você está emitindo em produção ou homologação (sandbox)?

Parece uma validação indevida feita pelo componente. Na V2 o ACBr copia o ClientID para não levantar o erro, mas na V3 isso não é feito. Tenta informar qualquer coisa (repetir o ClientID por exemplo) no ClientSecret.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.