Wellington Alamino
-
Total de ítens
70 -
Registro em
-
Última visita
Últimos Visitantes
1.201 visualizações
Wellington Alamino's Achievements
-
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 protocolo. e temos outras possibilidades de retorno dependendo do nosso pedido. 2º Mas o segredo e fazer o mesmo pedido novamente O retorno >>>>>>>>>>>>>>>>>>>>>> 563|Rejeição: Já existe pedido de Inutilização com a mesma faixa de inutilização[N prot. 2316465468798] Somente devemos extrair o número de protocolo e se tivermos armazenado as informações do pedido corretamente, como você mesmo disse podemos até montar o XML do recibo. Uma boa tarde a todos. Desculpe-me pela demora. Edit - NT 2015 - Sobre o comentado acima. 03. Serviço:Inutilização de numeração(item 4.4 do MOC) 03.1 Sobre o Processamento do Pedido de Inutilização Atualmente já é verificada a existência de um Pedido de Inutilização de Numeração em duplicidade (mesma faixa de numeração a ser inutilizada), rejeitando o novo Pedido de Inutilização com o erro “563-Rejeição: Já existe pedido de Inutilização com a mesma faixa de inutilização”. Para esta rejeição, será informado na resposta o Número do Protocolo de Autorização do Pedido de Inutilização anteriormente autorizado (tag: retInutNFe/infInut/nProt). Ou seja se houver protocolo na mensagem de retorno, significa que já se encontra devidamente autorizado e registrado na SEFAZ a dita inutilização
-
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.
-
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.
-
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 tarifas/Custas sendo que existem diversos : function TACBrBancoob.CodOcorrenciaToTipo Conteúdo [28: Result := toRetornoDebitoTarifas;] function TACBrBancoob.TipoOCorrenciaToCod Conteúdo [toRetornoManutencaoTituloVencido : Result :='28';] function TACBrBancoob.TipoOcorrenciaToDescricao Conteúdo [28: Result:='28-MANUTENÇÃO TÍTULO VENCIDO' ;] Como ficou, agora CodOcorrenciaToTipo e TipoOCorrenciaToCod são inversamente equivalentes e TipoOcorrenciaToDescricao retorna DÉBITO DE TARIFAS/CUSTAS conforme manual: function TACBrBancoob.CodOcorrenciaToTipo Mantido em [28: Result := toRetornoDebitoTarifas;] function TACBrBancoob.TipoOCorrenciaToCod Alterado para [toRetornoDebitoTarifas : Result :='28';] function TACBrBancoob.TipoOcorrenciaToDescricao Alterado para [28: Result:='28-DÉBITO DE TARIFAS/CUSTAS' ;] Em anexo o fonte em questão e discriminação mais organizada das alterações; Alterações conforme manual Layouts_para_troca_de_informações_03-09-2018 na planilha "04 Retorno - Opção CNAB240" segmento U: Fico a disposição.
- 4 replies
-
- 1
-
-
- boleto
- ocorrência
- (e 3 mais)
-
Contribuição - Ajuste das funções relacionadas as Ocorrências do Bancoob
um tópico no fórum postou Wellington Alamino ACBrBoleto
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 Conteúdo [toRetornoManutencaoTituloVencido : Result :='28';] Line 1382 Conteúdo [28: Result := toRetornoDebitoTarifas;] Mantido em [28: Result := toRetornoDebitoTarifas;] Contido em [function TACBrBancoob.CodOcorrenciaToTipo]; Line 1445 Conteúdo [toRetornoManutencaoTituloVencido : Result :='28';] Alterado para [toRetornoDebitoTarifas : Result :='28';] Contido em [function TACBrBancoob.TipoOCorrenciaToCod]; Line 1486 Conteúdo [28: Result:='28-MANUTENÇÃO TÍTULO VENCIDO' ;] Alterado para [28: Result:='28-DÉBITO DE TARIFAS/CUSTAS' ;] Contido em [function TACBrBancoob.TipoOcorrenciaToDescricao]; ACBrBancoBancoob.pas Discriminação das alteracoes em ACBrBancoBancoob 04-12-2019.txt -
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.
- 22 replies
-
- 1
-
-
- tipo de serviço
- cnab240
- (e 4 mais)
-
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.
-
Obrigado.
-
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.
- 22 replies
-
- 2
-
-
- tipo de serviço
- cnab240
- (e 4 mais)
-
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?
-
@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
-
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.
-
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.
-
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á