Danilo Ziza

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

Boa noite, A partir de 02/05 o município de Vilhena/RO passou a utilizar a WebISSv2, ajustes em anexo a quem interessar e se possível atualização no repositório. Cidades.ini WebISSv2.ini

Boa tarde, Apenas para alinhar, conforme verificado nos logs do SVN estes campos já estavam como obrigatórios na validação ANTES dessa alteração do dia 28/12, a implementação realizada foi apenas para avisar qual campo não estava preenchido, logo não foi essa alteração que afetou os teus clientes.