Danilo Ziza
-
Total de ítens
35 -
Registro em
-
Última visita
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por Danilo Ziza
-
-
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).
-
1
-
-
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.
-
1
-
-
Boa noite,
Funcionou
-
2
-
-
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.
-
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).
-
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/wsEnquanto Rio Verde segue:
http://rioverde.centi.com.br/servicos/wcf/service/servicenfse.svcDessa 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 1612Temos 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.
-
2
-
-
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.
-
1
-
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
Validação Nosso Número BB
em ACBrBoleto
Postado
Bom dia, deu certo, muito obrigado.