Jéter Rabelo Ferreira
-
Total de ítens
539 -
Registro em
-
Última visita
-
Days Won
5
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por Jéter Rabelo Ferreira
-
-
Boa tarde.
Em consulta a SEF/MG a respeito disso, a resposta enviada por eles foi a seguinte:
"A NF-e foi criada para substituir APENAS as notas ficais modelo 1 e 1A. Os demais modelos não sofreram alteração, continuando a emissão da mesma forma que é feita atualmente.".
Atenciosamente.
Jéter Rabelo Ferreira.
-
Não. O SCAN é definitivo.
Atenciosamente.
Jéter Rabelo Ferreira
-
Boa tarde.
Somente um cliente meu emitiu NF's em modo SCAN ontem na parte da manhã.
O demais, estão emitindo no modo normal desde ontem de manhã, embora que alguns reclamaram que está meio lento.
Hoje de manhã um cliente meu me ligou falando que uma NFe caiu em lote em processamento. Demorou 40 minutos para que a mesma fosse autorizada.
Tirando isso, o restante está normal.
Atenciosamente.
Jéter Rabelo Ferreira
-
Bom dia.
Como informei no meu post acima, o sistema voltou ao normal.
Tente enviar a NFe da forma normal, e não via SCAN.
O SCAN foi disponizilizado somente poucos minutos na parte da manhã.
Atencisoamente.
Jéter Rabelo Ferreira
-
Bom dia
O problema foi corrigido agora de manhã.
Houve um comunicado no Portal NFe que o SCAN havia sido liberado por tempo indeterminado para MG. O mesmo comunicado não encontra-se mais no portal NFe.
Tenho um cliente que chegou a emitir algumas NFe no SCAN devido a urgências.
Um detalhe importante é que, as NF-e emitidas ontem foram todas autorizadas.
Portanto, caso alguém tenha algum cliente que chegou a utilizar o SCAN, deve-se providenciar o cancelamento das NF-e emitidas ontem, senão serão duas NF-e para a mesma situação.
Atenciosamente.
Jéter Rabelo Ferreira
-
Bom dia.
O sistema de MG apresentou problemas ontem na parte da tarde.
Foi corrigido agora de manhã.
As notas emitidas ontem foram todas autorizadas.
Atenciosamente.
Jéter Rabelo Ferreira
-
Boa tarde.
A mensagem de erro mudou agora! ( Anexo)
/nfe2/services/NfeRecepcao2(404) - https://nfe/fazenda/mg.gov.br/nfe2/serv ... eRecepcao2
Atenciosamente.
Jéter Rabelo Ferreira
-
Boa tarde.
Essa alteração que a Juliana colocou no Banco do Brasil, foi eu que solicitei.
Porque o meu cliente emite boletos de carteira 18 Convenio 6 digitos e essas informações eu peguei de um arquivo do próprio Banco do Brasil.
Procurei o arquivo aqui e não consegui achar, acho que infelizmente eu o exclui indevidamente.
Essa carteira é de emissão do próprio cliente, não é enviado arquivo de remessa e o retorno é o CNAB400.
Juliana, o componente RLBoleto, do qual op ACBrBoleto herdou algumca coisa, tinha uma propriedade para a geração de nosso número.
/////////////////////////////////////
{Define o layout do nosso número}
TLayoutNN = ({Nosso Número com 11 digitos}
lnN11,
{Nosso Número com 16 digitos}
lnN16,
{Nosso Número com 17 digitos}
lnN17,
{Convênio com 7 digitos e Nosso Número com 10 digitos}
lnC7_N10,
{Convênio com 4 digitos e Nosso Número com 7 digitos}
lnC4_N7,
{Convênio com 6 digitos e Nosso Número com 5 digitos}
lnC6_N5);
//////////////////////////////
Isso somente era utilizado em alguns bancos, dos quais um era o Banco do Brasil.
Não seria o caso de pensar a respeito disso? Implementar uma propriedade a mais para que, caso haja necessidade, o usuário modifique a geração do Nosso Número?
Diga o que acha a respeito e, caso haja um consenso, posso ajudar a implementar isso.
Aguardo respostas.
Atenciosamente.
Jéter Rabelo Ferreira
-
Bom dia Juliana.
Existem alguns clientes meus que utilizam um nosso número, em algumas vezes, maiores que o tipo Integer, precisando ser um Int64.
Eu notei esse mesmo problema numa outra Unit ontem a tarde, Banco do Brasil.
Uma dica, pra não termos mais esse tipo de problema, eu acho que essa alteração, do StrToInt para StrToInt64 nas conversões de "nossos números", deveria ser feita em todas as units, pois resolveria os problemas quanto a conversão dos valores.
Pra você ter uma ideia, o Banco do Brasil, na sua carteia 18, pode-se informar 17 dígitos no nosso número. Como pode-se notar, isso é uma quantidade de dígitos bem acima que o tipo Integer suporta. (máx 2.147.483.647).
Em tempo, respondendo a sua pergunta: Um "Nosso Número" do meu cliente -> 81234567890 (81.234.567.890: bem superior ao tipo Integer).
Obrigado pela atenção.
Jéter Rabelo Ferreira
-
Boa tarde.
Ocorreram problemas comigo ao gerar boletos da Caixa Federal.
O erro ocorre ao tentar efetuar a conversão utilizando a função StrToInt().
Correção: Subsituir a mesma por StrToInt64.
Segue a unit corrigida anexa.
Atenciosamente.
Jéter Rabelo Ferreira
-
-
Boa tarde.
Tenho um cliente que acabei de implantar um sistema, e o mesmo utiliza carteira do Banco do Brasil, de convênio de 6 dígitos carteira número 18. Essa carteira o nosso número é composto de 17 dígitos e tem o número 21 fixo como parte final do nosso número. Essa carteira é sem registro.
Atualmente, a classe do Banco do Brasil somente trata nossos números até no máximo com 11 dígitos.
Devido a isso, tive que fazer duas alterações em duas funções.
Segue abaixo as correções que efetuei, caso acharem necessário implementar essas alterações na classe do Banco, ou se alguém precisar:
function TACBrBancoBrasil.FormataNossoNumero(const ACBrTitulo :TACBrTitulo): String;
var
ANossoNumero, AConvenio : string;
aCarteira: LongInt;
begin
with ACBrTitulo do
begin
AConvenio := ACBrBoleto.Cedente.Convenio;
ANossoNumero := trim(inttostr(strtoint(NossoNumero)));
aCarteira := StrToIntDef(Carteira,0);
if (aCarteira = 16) or (aCarteira = 17) or (aCarteira = 18) then
begin
if (ACBrTitulo.Carteira = '18') and (Length(AConvenio) = 6) then
ANossoNumero := padR(ANossoNumero, 17, '0')
else if Length(AConvenio) <= 4 then
ANossoNumero := padR(AConvenio, 4, '0') + padR(ANossoNumero, 7, '0')
else if (Length(AConvenio) > 4) and (Length(AConvenio) <= 6) then
ANossoNumero := padR(AConvenio, 6, '0') + padR(ANossoNumero, 5, '0')
else if Length(AConvenio) = 7 then
ANossoNumero := padR(AConvenio, 7, '0') + padR(ANossoNumero, 10, '0');
end
else
ANossoNumero := padR(AConvenio, 7, '0')+ padR(ANossoNumero, 11, '0');
end;
Result := ANossoNumero;
end;
function TACBrBancoBrasil.MontarCodigoBarras(const ACBrTitulo : TACBrTitulo): String;
var
CodigoBarras, FatorVencimento, DigitoCodBarras :String;
ANossoNumero, AConvenio: string;
begin
AConvenio := ACBrTitulo.ACBrBoleto.Cedente.Convenio;
ANossoNumero := FormataNossoNumero(ACBrTitulo);
{Codigo de Barras}
with ACBrTitulo.ACBrBoleto do
begin
FatorVencimento := CalcularFatorVencimento(ACBrTitulo.Vencimento);
if (ACBrTitulo.Carteira = '18') and (Length(AConvenio) = 6) then
begin
CodigoBarras := IntToStrZero(Banco.Numero, 3) +
'9' +
FatorVencimento +
IntToStrZero(Round(ACBrTitulo.ValorDocumento * 100), 10) +
AConvenio + ANossoNumero + '21';
end
else
begin
CodigoBarras := IntToStrZero(Banco.Numero, 3) +
'9' +
FatorVencimento +
IntToStrZero(Round(ACBrTitulo.ValorDocumento * 100), 10) +
IfThen((Length(AConvenio) = 7), '000000', '') +
ANossoNumero +
IfThen((Length(AConvenio) < 7), padR(Cedente.Agencia, 4, '0'), '') +
IfThen((Length(AConvenio) < 7), padR(Cedente.Conta, 8, '0'), '') +
copy(ACBrTitulo.Carteira, 1, 2);
end;
DigitoCodBarras := CalcularDigitoCodigoBarras(CodigoBarras);
end;
Result:= copy( CodigoBarras, 1, 4) + DigitoCodBarras + copy( CodigoBarras, 5, 44) ;
end;
Obs: Esse cliente meu emite mais de 4.500 boletos/mês. E dessa forma, tudo correu normal.
Atenciosamente.
Jéter Rabelo Ferreira
-
Olá
Retire essa unit do requires do arquivo ACBr_BoletoFC_Fortes.dpk e recompile e instale novamente.
Se não der certo, poste novamente.
Atenciosamente.
Jéter Rabelo Ferreira
Erro na transmissão de notas para sefaz
em ACBrNFe
Postado
Bom dia.
O SCAN é definitivo, uma vez enviado, não há necessidade de fazer mais nada.
A série do SCAN começa em 900 e vai até 999.
Numeração das NF`s, a cada série, sempre começa em 1.
Atencisoamente.
Jéter Rabelo Ferreira