Danilo Ziza

Boa tarde, Eu consegui falar com outro contato na prefeitura essa semana e liberaram o ambiente de homologação, obrigado.

Boa tarde, Para emitir NFS-e via WebService em Uberlândia é necessário que a prefeitura realize uma liberação no CNPJ, eles chamam de "liberação do regime especial RPS", e para tal eles solicitam um modelo de RPS impresso para homologar, nós fizemos a impressão preenchendo o componente (NFSeX) e chamando "ACBr.NotasFiscais.ImprimirPDF" utilizando o FastResport e o template "DANFSeNovo.fr3", porém a prefeitura recusou afirmando que essa impressão é da NFS-e e não do RPS, alguém sabe dizer se existe alguma outra forma de imprimir RPS? Segue em anexo o nosso modelo impresso e também o exemplo da prefeitura. Resposta da prefeitura: "O modelo anexado é de NFSe e não do RPS, deve seguir o modelo padrão do anexo VI da portaria 14/2024, favor nos enviar um modelo correto preenchido e impresso no sistema proprio, duvidas ligar no 3239-3120 período da manha com Welfares." Documentos necessários para Regime especial RPS.pdf exemplo-impresso-acbr.pdf

Bom dia, deu certo, muito obrigado.

Oi Juliana, O layout atualizado (baixei do site do BB) diz apenas que quando o convênio possui 7 dígitos (acima de 1.000.000) o nosso número deverá ter 17 dígitos, independente da carteira, então não deve ter problema em liberar para a carteira 17 (estava liberado apenas para a carteira 18). Doc5175Bloqueto.pdf

Boa noite, Adicionado condição para permitir nosso número de 17 dígitos para carteira 17 (só estava permitindo na carteira 18 e nos deparamos com clientes que usam na carteira 17 dessa forma) quando o convênio possuir 7 dígitos, conforme definido no layout, já testado e homologado com o banco. Arquivo em anexo a quem interessar e se possível atualização no repositório. Print da alteração em anexo. Obrigado. ACBrBancoBrasil.pas

Boa noite, Funcionou

Corrigindo, sugiro a alteração na ACBrNFSeConfiguracoes onde primeiro verificamos se existe a URL para o município em específico (RecepcaoLoteRPS_ + CodIBGE) e caso não exista pegamos a URL padrão (RecepcaoLoteRPS), considerar o "Centi.ini" anexo. Centi.ini

Para funcionar dessa forma foi necessário setar a URL de Rio Verde no "Centi.ini" (em anexo), porém isso causa outro problema, pra setar a URL específica de um município no ".ini" do provedor é necessário setar também as URL's de todos os outros municípios deste provedor (no Centi são 32 municípios) o que tornaria a manutenção deste arquivo trabalhosa, pra contornar isso sugiro a alteração na unit em anexo onde primeiro verificamos se existe a URL para o município em específico (GerarNFSe_ + CodIBGE) e caso não exista pegamos a URL padrão (GerarNFSe). Centi.ini ACBrNFSeConfiguracoes.pas

Boa noite, Com esta alteração começou a dar erro pois Rio Verde é uma exceção na montagem da URL, as demais cidades desse provedor seguem o padrão: http://app.centi.com.br/%NomeURL_P%/wcf/service/ServiceNfse.svc/ws Enquanto Rio Verde segue: http://rioverde.centi.com.br/servicos/wcf/service/servicenfse.svc Dessa forma a URL passou a ser montada assim "http://app.centi.com.br/http://rioverde.centi.com.br/servicos/wcf/service/servicenfse.svc/wcf/service/ServiceNfse.svc/ws"

Boa tarde @Márcio Baroni Pois é, pessoalmente acho errado o retorno ler apenas 8 posições (sem DV) enquanto na remessa é gerado 9 posições (com DV), com a alteração que sugerimos lendo pelo "TamanhoMaximoNossoNum" daria pra contornar isso e o demais não seriam afetados, vou ter que manter a alteração local também.

Bom dia Dercide, Visto que o valor default do "TamanhoMaximoNossoNum" é 8 ninguém que já utiliza dessa forma seria afetado, continuariam recebendo o nosso número normalmente com 8 posições e sem o DV, da forma como está o programador terá que fazer como você fez (calcular o DV manualmente), o que acho desnecessário já que o mesmo vem no arquivo de retorno. Mas tudo bem, podem desconsiderar a colaboração. Obrigado.

Juliana o banco está retornando 9 posições no nosso número, esse é o registro de retorno: 7480001300001T 0603950 0000000423289 192000175 1436 28062019000000000080000000072314436 092007220788000190DCK COMERCIO DE COMBUSTIVEIS LTDA 000000000000000000000000000 O ACBr também está gerando o nosso número com 9 posições, a última posição é o dígito verificador, não existe formatação, apenas um filler com zeros: 7480001300019P 0103950 0000000423289 1920001750000000000011122436 2806201900000000008000000000 03N21062019100000000000000000000093100000000000000000000000000000000000000000000000000000436 3001060090000000000 Dessa forma se considerarmos apenas 8 posições no retorno virá apenas 19200017, sem o dígito verificador, e o título não será localizado no sistema pois ao gerar a remessa o ACBr nos retorna o nosso número com 9 posições (considerando o dígito verificador), a forma mais simples de resolver isso é a implementação anexada onde o programador pode alterar o "TamanhoMaximoNossoNum" que será lido no retorno. ACBrBoleto.Banco.TamanhoMaximoNossoNum := 9; ou ACBrBoleto.Banco.TamanhoMaximoNossoNum := 20; E quem não quiser o nosso número com o dígito verificador (nono dígito) não será afetado pois o valor default do "TamanhoMaximoNossoNum" é 8.

No manual todas as referências ao nosso número indicam 20 posições, tanto remessa quanto retorno (manual em anexo), não significa que o nosso número tenha 20 dígitos mas sim que deveríamos ler todas as 20 posições pra extrair o nosso número, hoje o ACBr lê apenas 8 posições: NossoNumero := Trim(Copy(SegT,38,8)); Sicredi_Manual_Empresas_Conveniadas___CNAB_240___18062014.pdf

Não que eu saiba, na verdade o correto seria considerar os 20 dígitos conforme indicado no manual, porém o ACBr completa com zeros a esquerda, dessa forma poderia causar problemas para o pessoal que usa apenas com 8 dígitos pois passaria a vir "00000000000012345678" ao invés de "12345678": fNossoNumero := PadLeft(wNossoNumero,wTamNossoNumero,'0'); // ACBrBoleto -> Linha 1612 Temos 2 opções então: 1 - Deixar conforme implementado em anexo e quem trabalhar com mais de 8 dígitos altera o "TamanhoMaximoNossoNum" no componente 2 - Alteramos para pegar sempre as 20 posições conforme indicado no manual, neste caso tem que decidir se mantemos os zeros a esquerda que o ACBr adiciona (ACBrBoleto -> Linha 1612) ou se deixamos sem os zeros a esquerda.

Pode ser alterado no componente: ACBrBoleto.Banco.TamanhoMaximoNossoNum := 20;

Boa tarde, Ao ler o retorno do Sicred 240 o nosso número está retornando apenas os primeiros 8 dígitos: NossoNumero := Trim(Copy(SegT,38,8)); Porém temos clientes onde o arquivo de retorno apresenta 9 dígitos, e no manual em anexo é indicado até 20 dígitos (pág. 19). 7480001300001T 0603950 0000000423289 192000175 1436 28062019000000000080000000072314436 092007220788000190DCK COMERCIO DE COMBUSTIVEIS LTDA 000000000000000000000000000 Realizei um ajuste para que o nosso número seja lido de acordo com o "TamanhoMaximoNossoNum" indicado no componente, por default está como 8 então não irá afetar quem já estiver usando. NossoNumero := Trim(Copy(SegT,38,fpTamanhoMaximoNossoNum)); Ajuste em anexo a quem interessar, e se possível atualização no repositório. Sicredi_Manual_Empresas_Conveniadas___CNAB_240___18062014.pdf ACBrBancoSicredi.pas

Bom dia, Nas alterações realizadas no dia 01/03 na pmdfeMDFe (linha 229 > TinfContratanteCollection.New) ficou faltando adicionar o objeto na lista, com isso os contrantes informados não saem no XML, ajuste em anexo. pmdfeMDFe.pas

Boa tarde Ítalo, Mesmo erro, utilizei a tua ACBrDFeXsLibXml2 + ACBrNFSeWebServices atualizada do repositório + libWinCrypt + xsLibXml2, xml inválido em anexo: "Arquivo enviado com erro na assinatura. Erro no elemento: Pedido Acerte a assinatura do arquivo. Pedido de Cancelamento nao esta assinado. O pedido de cancelamento deve conter assinatura digital." Com libWinCrypt + xsMsXml + ACBrNFSeWebServices que eu anexei no topo dá certo, xml válido em anexo. 201900000000170-ped-can-INVALIDO.xml 201900000000170-ped-can-VALIDO.xml

A unit ACBrDFeXsXmlSec utiliza a função "AdicionarNode", que está com 1 parâmetro a mais nessa ACBrDFeXsLibXml2 que tu me enviou.

Erro na ACBrDFeXsXmlSec por causa dos parâmetros.

Boa tarde, Ao realizar cancelamento de NFS-e pelo provedor WebISSv2 está retornando o erro abaixo: "Arquivo enviado com erro na assinatura. Erro no elemento: Pedido Acerte a assinatura do arquivo. Pedido de Cancelamento nao esta assinado. O pedido de cancelamento deve conter assinatura digital" Unit ajustada em anexo para quem interessar, e se possível atualização no repositório. Validado utilizando libCapicom e libWinCrypt, no caso da libWinCrypt também é necessário setar SSLXmlSignLib = xsMsXml. ACBrNFSeWebServices.pas

Capicom. Com WinCrypt ocorre "Falha ao Assinar - Cancelar NFS-e: Nenhum elemento encontrado", testado com e sem as alterações acima.

Bom dia, Mesmo problema aqui com provedor WebISS, revertido alterações nas linhas 4504, 4709 e 4743 (ACBrNFSeWebServices) e a assinatura do cancelamento voltou a funcionar, unit em anexo a quem tiver interesse. ACBrNFSeWebServices.pas

Boa tarde, Quando o veículo é próprio o RNTRC não está saindo no DAMDFE (FastReport) pois está pegando da propriedade "veicTracao.prop.RNTRC" que deve ser preenchida apenas quando veículo de terceiros, ajuste em anexo a quem tiver interesse e se possível atualização no repositório. ACBrMDFeDAMDFEFR.pas

Boa tarde, Ao enviar 2 (ou mais) registros R2010/R2020 o retorno está trazendo apenas 1 registro (EnvioLote.RetEnvioLote.evento.Count = 1), unit corrigida em anexo a quem interessar, e se possível atualização no repositório. pcnReinfRetEventos.pas