Wellington Alamino
-
Total de ítens
70 -
Registro em
-
Última visita
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por Wellington Alamino
-
-
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
endTenha uma boa tarde.
-
1
-
-
Em 13/12/2019 at 16:40, José M. S. Junior disse:
Boa tarde,
Atualizado no repositório. Obrigado pela contribuição!
Boa tarde.
Estamos juntos.
-
1
-
-
Em 04/03/2019 at 15:09, doidopb disse:
Se não houver problemas, quero deixar o tópico aberto para que alguém que emita NFCes e siga a orientação do Manual de Contingência, me diga ...
Como lidam com os contadores/clientes nos casos de Inutilizações ocorridas sem XML por falha de internet?
Desde já agradeço a atenção de todos
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.
-
2
-
-
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.
-
1
-
-
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
-
17 minutos atrás, Juliana Tamizou disse:
Boa tarde @Wellington Alamino
Me parece ninguém conseguiu dar andamento, pelo menos não que tenham nos informado, se quiser iniciar, fique a vontade para postar aqui.
Att.
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.
-
1
-
-
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.
-
20 horas atrás, José M. S. Junior disse:
Suas sugestões foram disponibilizadas nos fontes do Projeto ACBr.
Obrigado pela contribuição!
Obrigado.
-
1
-
-
Em 27/08/2019 at 16:51, Juliana Tamizou disse:
Boa tarde pessoal.
Pelo que estou observando um arquivo retorno nunca trará informações relativas aos 2 tipos de serviço, correto?
Neste caso também me parece que o ideal seria separar essas funcionalidades, não necessariamente criar um novo componente.
@José M. S. Junior pode nos dar sua opinião?
Att.
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"
1 minuto atrás, José M. S. Junior disse:Na minha opinião poderia ser definido uma propriedade como "TipoServico" mesmo. Conforme esse Tipo Serviço gera o arquivo especifico e para leitura a mesma coisa. Acho que seria melhor implementar este serviço em outra função, ex: GerarRegistroEmprestimo400 para não precisar ficar adicionando IFs nos registros já existentes.
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.-
2
-
-
4 horas atrás, José M. S. Junior disse:
Bom dia, Por se tratar de um serviço de Adiantamento de Recebíveis e se tratar dos mesmo dados dos títulos, creio que pode ser implementado no componente Boleto mesmo... Apenas separando em um outro layout para esse tipo de serviço, para não bagunçar o layout de Cobrança já existente...
Seria interessante verificar com o banco se este serviço está disponível também por WebService, com o caso de registro de Boletos, já temos desenvolvimento em andamento em relações a serviço de Registro de Boleto WebService...
3 horas atrás, Juliana Tamizou disse:Bom dia pessoal.
Caso queiram iniciar o desenvolvimento, fiquem a vontade para continuar interagindo neste tópico para quaisquer dúvidas.
Att.
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?
-
16 horas atrás, BigWings disse:
Na pasta branches tem o desenvolvimento do ACBrCNAB que se não me engano está apto a tratar de remessa de pagamentos.
https://svn.code.sf.net/p/acbr/code/branches/Fontes/ACBrCNAB
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. -
14 horas atrás, prevedello_sistemas disse:
Na minha ideia, para não complicar muito, o acbr seria o responsável apenas por ler essa propriedade.
e o ERP faria o tratamento se for tipo 4 em um nível a cima.
claro que se isso jah fosse tratado ao ler o arquivo melhor. Mas...
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á -
4 horas atrás, prevedello_sistemas disse:
somos Software House, e estou precisando desse recurso, podemos desenvolver,
pelo que analisei, por cima, não seria algo complexo,
apenas criar uma nova Propriedade no componente chamado "tiposervico". e alimentar na leitura do retorno,
vc chegou a analisar alguma coisa?
Analisei sim,
Sua primeira analise, está correta. Mas gostaria de pontuar algumas coisas.
Remessa e retorno são como uma conversação então também é necessário implementar na remessa, e no caso da remessa setar como padrão o código da cobrança para não causar problemas pra os outros usuários da comunidade, e por fim eu queria fazer uma pesquisa para criar os tipos necessários ao invés de apenas armazenar apenas os valores dos códigos, até por questão de confirmar que se em todos os bancos os códigos do tipo de serviço são os mesmos.Podemos manter contato pra que não desenvolvamos a mesma coisa e desse duplicidade na análise.
-
11 horas atrás, prevedello_sistemas disse:
Olá Wellington, também estou com a mesma necessidade.
vc chegou a implementar isso?
Bom dia.
Ainda não comecei, porem está planejado.
Tenho umas demandas internas aqui da empresa pra liberar antes.
Você pretende iniciar, ou não você não desenvolve? -
7 horas atrás, Juliana Tamizou disse:
Bom dia.
Se desejar pode implementar e submeter para análise.
Att.
Obrigado, vou desenvolver e submeter.
-
1
-
-
Boa tarde a todos da comunidade.
A minha situação é a seguinte:
Realizo todo meu processo de gestão de cobrança pelo AcbrBoleto no banco Itaú e outros, porem no itau temos o desconto de titulo quando descontado o titulo é baixado do cobrança e vai pro empréstimos solicitamos ao Itaú e passamos a receber o arquivo de retorno referente aos descontados[04-EMPRESTIMO], porem na leitura do retorno a identificação do tipo do serviço é ignorada, ou melhor não temos uma propriedade do componente AcbrBoleto para carregarmos qual serviço estamos tratando.Gostaria de saber dos moderadores e responsáveis se seria viável e interessante o desenvolvimento desta propriedade. Desde já gostaria de me por a disposição para desenvolver uma versão de teste para comunidade.
-
Boa tarde @Juliana Tamizou
Gostaria que colocasse minha contribuição para analise, seria muito importante para mim.
Estou mandando novo arquivo em anexo nesta mensagem.
Agradeço enormemente.
-
Boa tarde,
Realizei algumas implementações no arquivo “ACBRNFe2_Trunk2\Fontes\ACBrBoleto\ACBrBancoItau.pas” e gostaria de que a colocar para análise e atualização no projeto.
1 – Add function CodigoLiquidacao_Descricao;
2 – Captura do Sacado.NomeSacado, CodigoLiquidacaoDescricao, Liquidacao.Banco, Liquidacao.Agencia, Liquidacao.Origem na Procedure LerRetorno400;
Utilizei como consulta o arquivo AcbrTools\Bancos\Itau\layout_cobranca_400bytes_cnab_itau.pdf e testei com arquivos de retorno cnab 400 na pratica.
O arquivo da Caixa, somente ajustei uma tabulação de uma unica linha.
Sucesso a todos;
-
Debugar este trecho do arquivo Fontes\AcbrBoleto\ACBrBoleto.pas
procedure TACBrBoleto.AdicionarMensagensPadroes(Titulo: TACBrTitulo;
AStringList: TStrings);
begin
if not ImprimirMensagemPadrao then
exit;with Titulo do
begin
if DataProtesto <> 0 then
begin
if TipoDiasProtesto = diCorridos then
AStringList.Add(ACBrStr('Protestar em ' + IntToStr(DaysBetween(Vencimento, DataProtesto))+ ' dias corridos após o vencimento'))
else
AStringList.Add(ACBrStr('Protestar no '+IntToStr(max(DiasDeProtesto,1)) + 'º dia útil após o vencimento'));
end;
-
15 horas atrás, Antonio Paulo Mangili disse:
boa noite estou com o mesmo problema. a minha sorte é que atualizei somente um cliente, e tinha um executavel de dia anterior.
alguma novidade sobre essa resolução.
obrigado
Baixe o arquivo disponibilizado pelo Jéter Rabelo, substitua no seu diretório, provisoriamente é isso.
Temos de esperar a analise do novo arquivo para que possa ser testado pela equipe e subido em produção.Att,
-
1
-
-
36 minutos atrás, Jéter Rabelo Ferreira disse:
Olá,
Sim, retirar o Double ou utilizar o RoundABNT dá na mesma.
Mas se você verificar a commit efetuado no dia 07/04/2019 as 20:27, que foi quando alteraram isso e ocasionou o problema, colocaram a mensagem no commit de "Correção para Compilação em 64 bits"
Portanto, ao utilizar o RoundABNT, uma função contida no ACBrUtil, a mesma deve estar compatibilizada com x64. Por isso a utilização dela por minha parte.
Atenciosamente.
Entendi, Ciente agora.
-
1
-
-
1 hora atrás, Jéter Rabelo Ferreira disse:
Bom dia
Resolvi aqui mudando o RoundTo para RoundABNT (ACBrUTIL)
Segue unit modificada.
Atenciosamente,
Baixei seu arquivo aqui, sua correção não se deve ao RoundABNT e sim a supressão da conversão Double.
Mas de qualquer forma resolve.
1 hora atrás, Juliana Tamizou disse:Bom dia,
Obrigada pela contribuição, adicionada para análise.
Att.
Obrigado pela presteza e velocidade Juliana.
1 hora atrás, farnetani disse:Nossa, estou com o mesmo problema!
Edite a o seu Arquivo ...\ACBRNFe2_Trunk2\Fontes\ACBrBoleto\ACBrBoleto.pas na função que foi citada acima.
-
3
-
Recuperar XML de Cancelamento e Inutilização
em NFC-e - Nota Fiscal do Consumidor Eletrônica
Postado · Editado por Wellington Alamino
Imcompleto
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