Ir para conteúdo
  • Cadastre-se
Seja bem-vindo
Curso Dominando a NFCe - Fim do SAT em São Paulo? Esteja preparado Curso Responsável Técnico na NFe - Atenda à nova legislação Curso Dominando o ACBrBoleto - Via API ou CNAB Seja um membro do ACBr Pro e agilize seu software Participe do Discord do ACBr Regras e orientações da nossa comunidade

marcianobandeira

Membros
 Perfil  Explorar Conteúdo

  • Total de ítens

    133

  • Registro em

  • Última visita

 Tipo de Conteúdo 

Tudo que marcianobandeira postou

  1. marcianobandeira
    Boa tarde Ao atender um chamado de um cliente, notei que o CT-e (Fortes Retrato) não está imprimindo os dados do veículo nem do motorista. Ao analisar o método rlb_10_ModRodFracionadoBeforePrint notei o seguinte trecho de código: rlb_11_ModRodLot104.Enabled := False; A única possibilidade dessa propriedade receber True é se a versão do XML do CT-e for inferior a 3.0. Se eu simplesmente atribuir True nessa propriedade eu tenho o funcionamento esperado. Porém analisando o código, notei uma variável global dentro da unit ACBrCTeDACTeRLRetrato "Versao: integer;" também há uma verificação sobre qual banda habilitar conforme esta variavel if Versao = 103 then rlb_11_ModRodLot103.Enabled := True else rlb_11_ModRodLot104.Enabled := True; De qualquer forma esse trecho de código só é acionado se a versão do XML for inferior a 3.0. Não consegui entender o objetivo da variavel Versao, uma vez que essa variável é preenchida diretamente com o valor 200 no método RLCTeBeforePrint. Se alguem puder dar uma luz. Grato
  2. marcianobandeira
    Pois eh, tive o mesmo problema com o tef auttar que não aceitava parametrização alguma, então sempre indico CliSitef ou Pay&Go aos meus clientes, nessa ordem.
  3. marcianobandeira
    Esse OperacaoCRT creio que so vai funcionar para o CliSitef. Esse GlobalTef Plus eu nao conheço. No caso do pay&go vai ter que usar como voce postou acima mesmo.. Req.GravaInformacao(10,0,'Cielo'); // Operadora Req.GravaInformacao(11,0,'10'); // No meu caso nao informo isso Req.GravaInformacao(18,0,'02'); // qtd parcelas apenas para teste Req.GravaInformacao(730,0,'1'); // VENDA Req.GravaInformacao(731,0,'1'); // CREDITO se fosse DEBITO vc informaria 2 Req.GravaInformacao(732,0,'1'); // AQUI PARECE ESTAR SEU PROBLEMA, POIS ESTA INFORMANDO SE TRATAR DE UMA VENDA A VISTA - NO CASO DE PARCELADO LOJA INFORMAR 3 Req.GravaInformacao(739,0,'001'); // isso aqui também nao informo aqui no meu caso.
  4. marcianobandeira
    Voce ta usando o CliSitef ou o Pay&Go?
  5. marcianobandeira
    Veja esta postagem: Postado por giulianon em 29/12/2017 https://www.projetoacbr.com.br/forum/topic/39273-clisitef-autoatendimento/ Para iniciar direto no débito ACBrTEFD.TEFCliSiTef.OperacaoCRT := 2; Para iniciar direto no crédito ACBrTEFD.TEFCliSiTef.OperacaoCRT := 3; Na documentação do clisitef tem todos os códigos de todas as operações que você pode utilizar. Qualquer dúvida estamos a disposição.
  6. marcianobandeira
    Boa tarde, Basta informar a propriedade OperacaoCRT. ACBrTEFD.TEFCliSiTef.OperacaoCRT := Se não me falha a memória, 2 pra débito e 3 pra crédito.
  7. marcianobandeira
    Bom dia Alguém passado por problemas com a emissão de NFS-e com o provedor PronimV2? Desde semana passada estou recebendo a mensagem: "Empresa - A entidade não satisfaz a especificação: OptanteSimplesNacional: Deve ser informado se a empresa e optante do Simples Nacional" Meu xml gerado tem a tag <OptanteSimplesNacional>1</OptanteSimplesNacional> Tentei entrar em contato com a prefeitura, mas só me dizem que o xml está fora do padrão. Se alguém puder dar uma luz. Grato
  8. marcianobandeira
    Boa tarde Senhores, Segue em anexo a minha proposta de mudança. Basicamente eu removi a propriedade CodigoMora deixando apenas a propriedade CodigoMoraJuros. Adicionei também a propriedade CodigoJurosMoraAceitos para que cada classe de banco possa informar quais sao os aceitos, caso sejam diferentes de (Valor por dia, Taxa mensal e Isento). Criei os metodos CodigoMoraJurosToStr e StrToCodigoMoraJuros na classe TACBrBancoClass.. esse método pode ser sobrescrito por outras classes, mas a exemplo da classe TACBrBanrisul podem ver que não é necessário sobrescrever o método. Algo que pode ser chato e provavelmente alguns desenvolvedores tenham que ajustar seus codigos é quanto a validação adicionada ao gerar o arquivo de remessa. Apesar de poder causar alguns transtornos, não causará a falsa sensação de estar tudo bem, podendo neste caso sim, gerar transtornos maiores no futuro. Realizei os testes aqui basicamente com o sicredi. Att, ACBrBoleto.rar
  9. marcianobandeira
    Boa tarde @Juliana Tamizou e @José M. S. Junior Temos duas propriedades na classe ACBrTitulo, CodigoMora e CodigoMoraJuros. Notei que algumas classes provavelmente mais recentes, usam esta propriedade CodigoMoraJuros. Estou criando as validações aqui para a propriedade CodigoMora, mas creio que talvez fosse melhor eliminar essa propriedade, deixando apenas a propriedade CodigoMoraJuros. Assim cada classe de banco nova que fosse diferente do padrão, poderia simplesmente sobrescrever um método para deixar com o código correto, a exemplo da função CodJurosToStr que tem na unit TACBrBancoUnicredES. Creio que neste caso também poderia ser eliminado a propriedade CodigosMoraAceitos, ou ao menso ser trocada para um Set of TACBrCodigoJuros ao invés de string. O que acham?
  10. marcianobandeira
    Bom dia, vou implementar uma sugestão e anexo os fontes aqui mais tarde.
  11. marcianobandeira
    Boa tarde Juliana, Obrigado por responder, mas na minha humilde opinião, dessa forma o desenvolvedor tem a falsa sensação de que está tudo ok, como foi o que aconteceu comigo, eu so vi o problema estourar quando ja era bem tarde, ja havia varios boletos emitidos. Creio que talvez fosse melhor separar a propriedade CodigosMoraAceitos em (CodigosMoraAceitosCnab400 e CodigosMoraAceitosCnab240). Também seria interessante tirar a validação do metodo TACBrTitulo.SetCodigoMora e colocar na geração do arquivo de remessa, pois como teríamos uma validação para cada tipo de layout, esse método poderia ser falho. Caso ache que fica interessante, eu me proponho a desenvolver sim. Att,
  12. marcianobandeira
    Bom dia Joel e demais participantes desse debate. Os códigos de mora A e B não são aceitos pelo sicredi no layout CNAB240... descobri isso da pior forma, quando fui ver que mais de 150 boletos que eu enviei aos clientes nos últimos dias estão com o registro recusado devido ao código de mora. Se possível, adicionar uma validação para não aceitar codigos inválidos, como A e B para o cnab 240. Grato
  13. marcianobandeira
    Olá Mateus, obrigado pelo seu retorno, tentei dar uma pesquisada antes e não havia encontrado, afinal o título do topico onde estão tratando não está muito sugestivo. Estamos no aguardo. Grato
  14. marcianobandeira
    Bom dia Pessoal, Me deparei com um pequeno problema mas que é bem incômodo, quando realizei a leitura do retorno sicredi, cnab240, vi que alguns boletos que foram baixados pelo banco, o sistema identificou com a descricao 'Entrada Confirmada'. Quando fui investigarm, reparei o seguinte, na unit ACBrBancoSicredi.pas ocorre o seguinte.. Considerando o tipo de ocorrência 09 a rotina CodOcorrenciaToTipo me devolve toRetornoBaixadoViaArquivo. Ja a rotina TipoOCorrenciaToCod não esta tratando toRetornoBaixadoViaArquivo mas sim toRetornoBaixado Com essa divergência acaba caindo no default da rotina que seria '02'. Não vejo problema na rotina TipoOCorrenciaToCod tratar tanto toRetornoBaixadoViaArquivo quanto toRetornoBaixado, com ambos retornando 09. Segue em anexo a minha sugestão de alteração para que possa ser analisada. Grato ACBrBancoSicredi.pas
  15. marcianobandeira
    Boa tarde Graça, Conforme o manual atualizado em anexo, o correto seria preencher sempre com zeros: "Dígito Verificador da Ag/Conta: Preencher com zeros" Mas uma propriedade ja resolve o problema. Obrigado.
  16. marcianobandeira
    Boa tarde, Recebi um manual do bancoob com atualização em 10/02/2017. Neste manual há uma alteração no header na posição 72. "Dígito Verificador da Ag/Conta: Preencher com zeros" Segue em anexo a unit alterada e o manual. Grato LAYOUT BANCOOB atualizado.rar ACBrBancoBancoob.pas
  17. marcianobandeira
    Bom dia Juliana, Obrigado por responder. Estive analisando a remessa, no meu caso o cliente está usando o CNAB 400, onde o dígito verificador não é enviado, percebi que ao gerar o registro de transação 400, é removido a carteira e enviado apenas os 8 primeiros digitos, ignorando assim o dígito verificador. Fiz um teste com o layout CNAB 240 e percebi que la o nosso número está completo incluindo a carteira e o dígito verificador. Por hora vou tentar fazer o cliente alterar o layout. Obrigado.
  18. marcianobandeira
    Boa tarde Senhores, Estou tendo um problema estranho, tenho um cliente que trabalha com boletos do banco Itau. Os boletos são registrados normalmente por meio da remessa, os pagamentos são contabilizados tranquilamente. O problema ocorre quando é feito a antecipação dos recebimentos dos boletos, ocorre que o itau gera dois arquivos de retorno, um Retorno A e um Retorno B Este retorno B são os títulos que foram antecipados e pagos clientes destinatários.. ou seja, quando se faz a antecipação não são informados quais títulos, o próprio sistema do itaú escolhe os titulos, e quando o boleto é pago, vem por meio deste retorno B. O retorno A consigo ler normalmente, o retorno B vem com o digito verificador do nosso número diferente do que foi gerado pelo meu sistema por meio do ACBr. Entrando em contato com o banco, eles me disseram que o sistema estaria calculando o DAC do nosso número de forma errada. Alguém poderia me dar uma luz? Obrigado
  19. marcianobandeira
    Tudo ok, muito obrigado Régys.
  20. marcianobandeira
    Boa tarde, Também percebi o problema no Delphi 10.2 Tokyo. Investigando aqui cheguei a uma solução, a qual testei no delphi 10.2 e no lazarus. Em ambos os casos funcionou com sucesso. Basta remover a palavra reservada "const" do método GetFields. Segue em anexo os prints e a unit corrigida. att, ACBrBase.pas
  21. marcianobandeira
    boa tarde, ja está no svn a algum tempo.
  22. marcianobandeira
    Acho que estava faltando um rebuild all no projeto.
  23. marcianobandeira
    Bom dia Senhores, Ao utilizar vlVersao202 recebo a informação no validador passando de 1000 erros informando "Organização Hierárquica dos Blocos/Registros do arquivo está fora dos padrões estabelecidos". Será algo com meu código ou o componente ainda precisa de ajustes pra nova versão? (caso sim estou a disposição pra tentar ajustar). Grato
  24. marcianobandeira
    Bom dia, Segue em anexo as alterações para análise. ACBrBancoSicredi.pas ACBrBoleto.pas Bom dia Creio que nem todos os bancos façam o tratamento deste campo, por isso ainda não houve uma demanda maior dessa correção. Com relação a fixar o campo eu havia feito dessa forma mesmo, porém agora enviei uma sugestão de alteração pra ser analisada e liberada no svn
  25. marcianobandeira
    Bom dia, Deixei fixo como 1 e foi homologado normalmente, porém tem que ficar atento a possíveis alterações vindos do svn. Att Desculpe não havia visto isso antes.. vou realizar as alterações e anexo os fontes.
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.