Jump to content
Notícias do ACBr

click.png

click.png

click.png

click.png

click.png

click.png

click.png

click.png

click.png

consultoria_sticker.png

Conteúdo para desenvolvedores
 ao vivo de terça a quinta!
Saiba mais

dev.png

logo_acbr_paygo.png

TEF ACBr PayGo
Seja um revendedor e ofereça uma solução completa para seu cliente.


Saiba mais

beneficios.png

Danilo Ziza

Membros
  • Content Count

    32
  • Joined

  • Last visited

Community Reputation

7 Neutral

1 Follower

About Danilo Ziza

  • Rank
    Membro
  • Birthday 06/30/1988

Contact Methods

  • Website URL
    udisoft.com.br
  • Skype
    danilo.ziza

Profile Information

  • Sexo
    Masculino
  • Location
    Uberlândia

Recent Profile Visitors

808 profile views
  1. 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
  2. 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
  3. 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"
  4. 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.
  5. 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.
  6. 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 03N21062019100000000000
  7. 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
  8. 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 confo
  9. Pode ser alterado no componente: ACBrBoleto.Banco.TamanhoMaximoNossoNum := 20;
  10. 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 acor
  11. 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
  12. 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
  13. A unit ACBrDFeXsXmlSec utiliza a função "AdicionarNode", que está com 1 parâmetro a mais nessa ACBrDFeXsLibXml2 que tu me enviou.
  14. Erro na ACBrDFeXsXmlSec por causa dos parâmetros.
×
×
  • Create New...