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

Wellington Alamino

Membros
  • Content Count

    70
  • Joined

  • Last visited

Community Reputation

21 Excellent

About Wellington Alamino

  • Rank
    Membro

Profile Information

  • Sexo
    Masculino
  • Location
    Eugenópolis - mg

Recent Profile Visitors

883 profile views
  1. Boa tarde. Não fui claro o suficiente, me perdoe por isso. Vamos construir um cenário: 1º Pedido de inutilização de 1025 ate 1030 - Gravamos no nosso sistema que vai ser pedido está inutilização 2º Sefaz não responde em tempo, ou a internet caí. Como sabemos não existe consulta, certo? Mas temos como nos virar, a partir disto vamos as possibilidades 1º Pedimos a inutilização novamente some da 1025 até 1026 por exemplo >>>>>>>>> Retorno: 256|Rejeição: Uma NF-e da faixa já está inutilizada na Base de dados da SEFAZ e ficamos sem p
  2. A margens dos documentos do fast-report no acbr passaram a ser interpretadas como "mm" em vez de "cm". Considere essa propriedades. object ACBrNFeDANFEFR1: TACBrNFeDANFEFR MargemInferior = 8.000000000000000000 MargemSuperior = 8.000000000000000000 MargemEsquerda = 6.000000000000000000 MargemDireita = 5.000000000000000000 EspessuraBorda = 10 end Tenha uma boa tarde.
  3. XML de retorno de inutilizações não são assinados, então não documentos com validade e nem precisam ser armazenados. Para inutilização o bom controle das faixas de pedido de inutilização bem como seu protocolo de retorno autorizando a inutilização é o suficiente. Número inutilizado não configura documento, lembrando que deve proceder com a inutilização em no máximo no 10 dia do mês subsequente ao salto na numeração. Boa tarde a todos.
  4. Redação corrigida, Bom dia, gostaria de por a disposição uma correção no arquivo ACBrBancoBancoob.pas. Com relação as ocorrências temos três funções importantes no AcbrBoleto, são elas CodOcorrenciaToTipo, TipoOCorrenciaToCod e TipoOcorrenciaToDescricao. Sendo que CodOcorrenciaToTipo e TipoOCorrenciaToCod devem ser inversamente equivalentes e TipoOcorrenciaToDescricao trazer a descrição mais fidedigna da ocorrência. Como estava, perceba que CodOcorrenciaToTipo e TipoOCorrenciaToCod não estão inversamente equivalentes e TipoOcorrenciaToDescricao retorna um dos tipos de tarif
  5. Bom dia, gostaria de por a disposição uma correção no arquivo ACBrBancoBancoob.pas. Com relação as ocorrências temos três funções importantes no AcbrBoleto, são elas CodOcorrenciaToTipo, TipoOCorrenciaToCod e TipoOcorrenciaToDescricao. Sendo que CodOcorrenciaToTipo e TipoOCorrenciaToCod devem ser inversamente equivalentes e TipoOcorrenciaToDescricao trazer a descrição mais fidedigna da ocorrência. Como estava: function TACBrBancoob.CodOcorrenciaToTipo Conteúdo [28: Result := toRetornoDebitoTarifas;] function TACBrBancoob.TipoOCorrenciaToCod
  6. Boa tarde Juliana. Obrigado pelo retorno. Eu consegui a parte do retorno de forma funcional aqui, falta a questão a remessa em "empréstimo". E a partir de hoje estou trabalhando em produção com o componente modificado. Com mais alguns dias de teste trarei aqui minhas implementações. Att, Wellington.
  7. Gostaria de saber se alguém iniciou o desenvolvimento conforme a orientação dos moderadores, pois surgiu um intervalo aqui na empresa pra eu poder me dedicar a isto, peço que me informem para eu não cair no retrabalho. Desde já agradeço! Uma boa tarde a todos.
  8. Correto, quando um titulo "normal" é descontado, vem pro cobrança um instrução tipo "baixa por desconto". E no empréstimo este mesmo titulo em uma instrução de entrada e depois segue seu ciclo pelo "empréstimo" Entendi, gostei da forma de desenvolvimento que você sugeriu. Eu posso desenvolver isto aqui com base no Itaú, o qual tenho o manual, e possuo meios de testar principalmente os retornos deste tipo de serviço [emprestimo] novo.
  9. Entendido, só pra ficar mais claro. Então criaríamos a propriedade tipo de serviço, implementaríamos as instruções especificas deste serviço, tanto de retorno quanto remessa , e passaríamos a levar em conta o tipo de serviço para decodificar os retornos? Seria isso, ou quando se fala em layout está se referindo a alguma outra coisa ou propriedade?
  10. @prevedello_sistemas Conforme prometido verifiquei no banco e realmente se trata de algo totalmente distinto como você pode ver com o manual que envio em anexo, comparado com o manual da cobrança que se encontra em ..\AcbrTools\Bancos\Itau\layout_cobranca_400bytes_cnab_itau.pdf então instruções de remessa e retorno são bem distintas, no meu entendimento o melhor e partir para criação de um componente similar porem diferente, especializado no tipo serviço 04-empréstimo "desconto de duplicatas". O que acham? desconto_duplicatas_escriturais400.pdf
  11. Perfeito, mas o tipo serviço 04-empréstimo é referente a títulos porem em Descontário. Não é o caso do Acbr Cnab que implementa movimentações. Agradeço o comentário.
  12. Entendi, mas o que salientei é que eu creio que os códigos de ocorrências dos títulos são diferentes para o tipo serviço 04 então não adianta só passar a ler esta propriedade, se pode ocorrer confusão na decodificação da ocorrência, vou ligar no meu banco pra confirmar isso e mando aqui no post.
  13. Estudei mais agora pela tarde e possivelmente não será um boa colocar 01-COBRANÇA E 04-EMPRÉSTIMO JUNTOS a estrutura de ocorrências do Acbr-boleto é toda voltada para cobrança sendo necessária mais esta alteração, a chance de uma grande confusão aumenta visto que todos os fontes de cada banco teriam de ser alterados. @Juliana Tamizou Concorda? e já te pergunto existe outro componente em desenvolvimento ou pronto para troca de informações no padrão CNAB que não o serviço de 01-COBRANÇA que o acbr boleto trata muito bem? Obrigado desde já
×
×
  • Create New...