Valdir Dill
-
Total de ítens
941 -
Registro em
-
Última visita
-
Days Won
5
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por Valdir Dill
-
-
Bom dia,
Estamos tendo problema de rejeição em cancelamento de NFCe.
Até o momento ocorreram dois casos nas UFs PE e BA.
A rejeição: "Rejeicao 501: Prazo de Cancelamento Superior ao Previsto na Legislacao".
A questão é que as tentativas de cancelamentos foram feitas, uma 40 minutos depois do envio, e a outra 4 horas depois do envio, ou seja, dentro do prazo de 24 horas.
Temos notícias que a SEFAZ-MS estaria mudando o prazo de cancelamento para 30 minutos. Mas essas duas UFs (PE e BA), até onde sabemos ainda é 24 horas.
Alguma sugestão do que pode estar causando essa rejeição?
Obrigado.
-
16 minutos atrás, EMBarbosa disse:
Enviei ao SVN uma alteração baseada na do Valdirdill, mas levando em conta o que o BigWings mencionou, na revisão 16926.
Assim, o arquvo Setor vai ser gerado apenas se for preenchido pelo menos a descrição ou a tecla para o produto.
Queiram por favor atualizar, testar e reportar qualquer problema.
Boa noite,
A tua alteração funcionou, mas a property Tecla é do tipo integer.
Então precisa mudar de: if (Produtos.Setor.Descricao <> '') or (Produtos.Tecla <> '') then
Para: if (Produtos.Setor.Descricao <> '') or (Produtos.Tecla > 0) then
Teste e está funcionando corretamente, ou seja, gerando apenas o CADTXT
Obrigado.
-
2
-
-
19 horas atrás, BigWings disse:
Não é preciso incluir uma condição para gerar a linha caso não seja informado o setor, mas seja informada a tecla associada ao produto?
Bom dia,
Não entendia sua paergunta @BigWings
O que ocorre é que quero gerar apenas o arquivo CADTXT.TT, mas não gerar o SETORTXT.txt.
Por isso informo os dados do produto, sem informar nada dos dados do setor. Imagino que fazendo dessa forma, ou seja, não informando dados do setor, não deveria gerar o SETORTXT.txt. Por isso fiz essa sugestão.
Obrigado.
-
Bom dia,
A função procedure TACBrCargaBal.PreencherFilizola(Arquivo, Setor, Nutricional, Receita: TStringList) da ACBrCargaBal.pas está alimentando a lista de setor mesmo se não tiver sido informado setor.
Sugiro alterar essa procedure (PreencherFilizola) na ACBrCargaBal.pas
De:
Setor.Add(
RFill(Produtos.Setor.Descricao, 12) +
LFIll(Produtos.Codigo, 6) +
LFIll(i + 1, 4) +
LFill(Produtos.Tecla, 3)
);Para:
if Produtos.Setor.Descricao <> '' then
Setor.Add(
RFill(Produtos.Setor.Descricao, 12) +
LFIll(Produtos.Codigo, 6) +
LFIll(i + 1, 4) +
LFill(Produtos.Tecla, 3)
);
Envio unit já alterada, em anexo.Obrigado.
-
2
-
-
Bom dia,
Estamos tendo a rejeição "Nota(s) não confirmadas: 189->245-Rejeicao: CNPJ/CPF Emitente nao cadastrado" na SEFZ-PA.
É produtor rural, ou seja, nota com CPF.
Pelo texto da rejeição está claro que o problema seria o CPF do emitente lá na SEFAZ. Mas, segundo o cliente, a SEFAZ alega que está tudo certo lá com o CPF dele e também com o sistema de recepção de notas.
O curioso é que esse cliente já emitia notas normalmente com CPF. De repente começou a retornar o erro.
Alguma sugestão do que pode ser a causa?
Em anexo o XML de retorno e também o XML da nota com tentativa de envio.
Obrigado
154000422445591-pro-rec.xml 15190400051778653200559200000001891939436018-nfe.xml
-
15 minutos atrás, Amarildo de Matos disse:
Assim..
cada 1, é um retorno de algo, tem de ler para ver , o que signfica cada um..
pode ser uma tarifa, pode ser uma baixa, ou entrada. etc..
Sim, isso eu entendi.
A questão é que esse não é o padrão. Todos os demais bancos (pelo menos que já analisamos) trazem o valor da tarifa na mesma linha da baixa.
E pior, tenho que ter uma rotina diferente para esse banco.
Mas beleza. Vamos analisar.
Obrigado.
-
1
-
-
1 minuto atrás, Amarildo de Matos disse:
bom dia..
Mande o arquivo de retorno para analise.
Bom dia,
Em anexo.
Obrigado.
8 minutos atrás, José M. S. Junior disse:Bom dia
Chegou a validar se este arquivo de retorno está seguindo o padrão especificado no manual desse Banco?
Bom dia,
Sim, analisei.
Os dados do arquivo estão dispostos nas colunas corretas, conforme prevê o manual. O problema é que na linha da liquidação (ocorrencia 06), não tem o valor da tarifa. Esse valor vai ter apenas na linha 2 (ocorrencia 28).
Mas no manual não fala nada sobre uma ou duas linhas.
Obrigado.
-
bom dia,
Estou analisando o tratamento do arquivo de retorno Sicredi
Minhas rotinas estão assim:
- ACBrBoleto1.LerRetorno();
- for I := 0 to ACBrBoleto1.ListadeBoletos.Count - 1 do
begin
if ACBrBoleto1.ListadeBoletos.Objects.OcorrenciaOriginal.Tipo = toRetornoLiquidado then
begin
BoletoPago := true;
ValorTarifa := ACBrBoleto1.ListadeBoletos.Objects.ValorDespesaCobranca;
...
end;
end;
Essa rotina funciona muito bem para quase todos os bancos.
Mas, na cobrança cnab400 Sicredi estou tendo problema porque, ao que parece, o Sicredi retorna cada boleto em duas linhas. Uma para os dados da baixa em si (ocorrencia 06) e outra linha para trazer a tarifa (ocorrencia 28).Nesse caso eu teria que fazer mais um laço para ver a tarifa?
if ACBrBoleto1.ListadeBoletos.Objects.OcorrenciaOriginal.Tipo = toRetornoDebitoTarifas then
begin
ValorTarifa := ACBrBoleto1.ListadeBoletos.Objects.ValorDespesaCobranca;
end;
Ou haveria uma opção melhor para tratar isso?Outra coisa, tem como saber quais bancos fazem dessa forma, ou seja, trazem o valor da tarifa numa linha separada no arquivo retorno?
Obrigado.
-
2 minutos atrás, EMBarbosa disse:
Teria que verificar no código fonte do Fortes. Mas isso não deveria ser necessário.
De modo geral, todos os usuários tem acesso a pasta temporária do sistema operacional, mesmo que você tenha alterada para outra pasta.
Se isso não está acontecendo, seria melhor você verificar o ambiente em que seu software está rodando.
Bom dia,
Certo. Esclarecido.
Obrigado.
-
1
-
-
Bom dia,
Na geração de .pdf do danfe (com Fortes Report) estou com um usuário tendo erro: 'EFCreateError(Cannot create file C:\users\...\tmp\~fr16...tmp...'.
Pelo que analisei é algum problema de permissão do usuário (do Windows) em gravar arquivos nessa pasta.
Analisando ainda mais a fundo, constatei que o Fortes busca esse path para salvar os arquivos temporário que gera e guarda o valor na @var TempDir da RLUtils.pas.Sim, o ideal é que o operador do Windows ter permissão para essa pasta \Temp do sistema operacional.
Mas, caso queiramos definir o path da TempDir, há alguma possbilidade que o Fortes permita setá-la dinamicamente?Obrigado.
-
59 minutos atrás, Italo Jurisato Junior disse:
Boa tarde Valdir,
Só existe dois tipos de consulta:
Pelo numero do Recibo que é retornado assim que a nota é enviada e pela Chave.
Portanto não existe uma consulta pelo numero do Protocolo.
Não devemos confundir o numero do Recibo com o numero do Protocolo.
Como dito acima o numero do Recibo é retornado pela SEFAZ assim que ela recebe o lote de notas, logo temos um Recibo atrelado ao lote inteiro independente da quantidade de notas contidas nesse lote.
Já o numero do Protocolo só é retornado após o processamento do Lote, ou melhor, ao realizar uma consulta pelo numero Recibo teremos o resultado do processamento, o Protocolo é atrelado a nota, portanto se for enviado um lote com 30 notas, a SEFAZ vai retornar um numero de protocolo para cada nota que por ventura foi autorizada.
As notas rejeitadas não são armazenadas no banco de dados da SEFAZ e portanto não tem numero de protocolo.
Agora você precisa analisar a sua rotina para descobrir se ela não esta salvando no banco de dados da sua aplicação o protocolo de uma nota autorizada em uma outra que não foi.
Uma observação importante:
Quando enviamos um lote de NF-e, mesmo que esse lote tenha apenas uma nota, a SEFAZ sempre vai retornar o numero do recibo.
Por outro lado quando enviarmos um lote de NFC-e no modo síncrono (somente uma nota), a SEFAZ demora um pouco mais para responder, pois nesse modo ela já processa as informações da nota e retorna o protocolo de autorização caso esteja tudo OK, caso contrario a nota é rejeitada.
É uma ou outra SEFAZ que retorna o numero do recibo também.
Agora se enviarmos um lote com duas ou mais NFC-e, o envio é assíncrono, neste caso o funcionamento é o mesmo da NF-e, ou seja, a SEFAZ retorna o recibo, de posse dele devemos fazer a consulta para obter o resultado do processamento das notas.
Certo, entendi Italo.
Eu envio uma única NFCe em cada lote. Aí trato o retorno. Se houver autorização, também pego o protocolo (...procNFe.nProt).
Pelo que entendi, no caso da NFCe o protocolo retornado pela SEFAZ não serve para nada, pelo menos não para se fazer uma consulta a posteriore. Se, por exemplo, por uma situação qualquer não tivermos a chave da nota, mas tivermos o protocolo dela, isso não adiantaria nada, pois não temos como consultar pelo protocolo, estou certo?
Obrigadgo.
-
3 horas atrás, Daniel Simoes disse:
Consultando no Portal da SEFAZ (Web), você consegue achar o documento ?
Boa tarde,
Não. Não encontrei em lugar em lugar algum, nem consultando pela chave, nem pelo protocolo.
Ao que tudo indica, a nota não existem mesmo, mas o estranho é como o nosso sistema tem esse protocolo gravado! É uma nota do mês passado. Mas o sistema só registra valor no campo do protocolo no banco de dados quando recebe cStat = 100 ao enviar a nota.
Obrigado.
-
Bom dia,
Estou tendo dificuldade de consultar uma NFCe. Nas consultas pela chave, não é encontrada no servidor.
Mas no banco de dados local do sistema está gravada como autorizada e com o número do protocolo.
Se consulto pelo recibo, dá erro 553 - Rejeicao: Tipo autorizador do recibo diverge do orgao Autorizador.
Chave: 26190214393638000144650010000294171553700290
Recibo/protocolo: 326190105858774
Alguma dica?
Obrigado.
-
40 minutos atrás, José M. S. Junior disse:
Sabe dizer se existe alguma especificação para qtd de casas decimais nas instruções impressas no Boleto? Aparentemente o padrão é duas casas decimais, se fosse manter esse padrão no valor impresso nas instruções sem o arredondamento, também ficaria errado: (R$ 0,05). Nesse caso teria que ser especificado a qtd de casas decimais.
Boa tarde,
Não entendi. Porque 0,05 ficaria errado?
Veja bem, se o valor calculado exato fica = 0,055, com duas decimais, que é o padrão do Real e, portanto não creio que o banco tenha uma parametrização do número de decimais e, se arredondarmos esse valor para mais, que é o que o Acbr faz, o valor ficará em R$ 0,06. Porém, segundo a análise da homologação do banco, o sistema do banco não arredonda, apenas despreza a terceira decimal, ou seja, o valor correto (para o banco) é R$ 0,05.
Obrigado.
-
52 minutos atrás, José M. S. Junior disse:
Bom dia
A rejeição do banco está sendo no boleto impresso?
Bom dia,
Sim, isso mesmo. Veja o retorno deles após análise.
Conforme análise realizada, abaixo o relatório de
inconsistência localizado no arquivo.
· Referente ao boleto de Nosso Numero 8-6, a informação
do valor de multa após vencimento no boleto em PDF está de R$
0,06. Porém no arquivo remessa é informado a porcentagem de 2% de
multa após vencimento, que sobre o valor do titulo cobrado no
boleto de R$ 2,75, ficaria no valor exato de R$0,05. Acredito que
seu sistema tenha arredondado o valor , porém o sistema do banco
não arredondará o valor conforme é informado no boleto em PDF,
será cobrado apenas R$0,05 de multa após vencimeto.Obrigado.
-
Boa tarde,
A linha 2.114 (rotina abaixo) da AcbrBoleto.pas está gerando um valor de multa com arredondamento, o que está gerando rejeição da homologação dos boletos pelo banco.
ACBrStr('Cobrar multa de ' + FormatCurr('R$ #,##0.00',
IfThen(MultaValorFixo, PercentualMulta, ValorDocumento*( 1+ PercentualMulta/100)-ValorDocumento)) +
' para pagamento'+ IfThen(DataMulta = Vencimento, ' após o vencimento.',
' a partir de '+ FormatDateTime('dd/mm/yyyy',DataMulta)))Num exemplo prático de um título com valor de R$ 2,75, se informarmos um percentual de multa de 2%, o cálculo exato seria R$ 0,055. Mas esse formato de cálculo utilizado pelo ACbr (nessa linha acima) gera um valor de R$ 0,06 e que é impresso nas instruções do boleto.
Isso está gerando rejeição de homologação do Santander.
O motivo que alegam é que no arquivo remessa vai só o percentual da multa de 2% e, como o sistema do banco não faz o arredondamento, ou seja, o valor de 2,75 x 2% = 0,05, fica inconsistente.Como eu poderia proceder nesse caso?
Obrigado.
-
Boa tarde,
Também estou com esse problema. Não sei se é alguma coisa no Acbr que mudou, pois até semana passada não fazia isso.
E não é o Gmail o problema, pois testei tanto com Gmail com outros servidores e acontece a mesma coisa.
Ele vai como anexo e também como texto no corpo do e-mail.
Obrigado.
-
23 horas atrás, valdirdill disse:
Bom dia,
Estamos tendo rejeições de NFCes por problema de padrão de hora configurada incorretamente no Windows do usuário.
Ele tem configurada a hora no padrão 12 horas ao invés do padrão 24.Aí ele gera uma nota no sistema às 15:00, mas no XML acaba indo 03:00 horas, o que logicamente, será incorreto e gerará a rejeição.
A minha pergunta/questão é: existe alguma rotina em Delphi para se verificar se a hora está no padrão 12/24?
Se existir, o sistema poderia verificar e impedir que o usuário tomasse rejeição por esse motivo.Tentei algo assim:
Var
VFormats : TFormatSettings;
begin
GetLocaleFormatSettings(LOCALE_USER_DEFAULT, VFormats);
if VFormats.ShortDateFormat = 'HH:MM' then ShowMessage('Está no formao 24')
else if VFormats.ShortDateFormat = 'hh:mm' then ShowMessage('Está no formao 12').
end;Mas isso não funciona. Parece que não é o maiúsculo e minúsculo que define o padrão configurado.
Essa rotina acima foi a única coisa que encontrei sobre o assunto nas pesquisa por aí.Se alguém tiver alguma dica...
Obrigado.
O VFormats.ShortDateFormat que postei inicialmente está errado. O correto é VFormats.ShortTimeFormat.
Bom dia,
Consegui uma solução. O problema ocorria porque GetLocaleFormatSettings(LOCALE_USER_DEFAULT, VFormats) traz sempre todo o texto em minúsculo. Aí não tem como avaliar se está configurado para 12 horas (hh:mm) ou para 24 horas (HH:MM).
A solução é ler diretamente no registro. Deixo a função para quem sabe ajudar outros.
class function TFuncPubl.GetHoraCurtaFormat : String;
Var
VReg : Tregistry;
begin
//não pode usar o GetLocaleFormatSettings( aqui pqe essa função retorna sempre tudo em minúsculo. Aí sempre daria erro.
result := 'HH:MM'; //para se der erro retornar o correto do GFIL.VReg := TRegistry.Create;
try
VReg.RootKey := HKEY_CURRENT_USER;
VReg.OpenKey('Control Panel\International', false);result := VReg.ReadString('sShortTime');
finally
FreeAndNil(VReg);
end;
end;Tópico resolvido.
Obrigado.
-
3
-
-
Bom dia,
Estamos tendo rejeições de NFCes por problema de padrão de hora configurada incorretamente no Windows do usuário.
Ele tem configurada a hora no padrão 12 horas ao invés do padrão 24.Aí ele gera uma nota no sistema às 15:00, mas no XML acaba indo 03:00 horas, o que logicamente, será incorreto e gerará a rejeição.
A minha pergunta/questão é: existe alguma rotina em Delphi para se verificar se a hora está no padrão 12/24?
Se existir, o sistema poderia verificar e impedir que o usuário tomasse rejeição por esse motivo.Tentei algo assim:
Var
VFormats : TFormatSettings;
begin
GetLocaleFormatSettings(LOCALE_USER_DEFAULT, VFormats);
if VFormats.ShortDateFormat = 'HH:MM' then ShowMessage('Está no formao 24')
else if VFormats.ShortDateFormat = 'hh:mm' then ShowMessage('Está no formao 12').
end;Mas isso não funciona. Parece que não é o maiúsculo e minúsculo que define o padrão configurado.
Essa rotina acima foi a única coisa que encontrei sobre o assunto nas pesquisa por aí.Se alguém tiver alguma dica...
Obrigado.
-
14 minutos atrás, EMBarbosa disse:
Talvez você tenha excedido sua cota. Tente apagar arquivos antigos não mais necessários em
https://www.projetoacbr.com.br/forum/attachments/
Bom dia,
De fato, era limite excedido. Nem sabia que existia essa cota. Tinha arquivos de 2012 lá, kkkk...
Beleza, após limpeza estou enviando o arquivo.
Obrigado.
-
3
-
-
Bom dia,
O manual do Bancoob disponível no svn está desatualizado.
Solicitei e o banco me enviou um atualizado (set/18).
Gostaria de enviar o arquivo para que seja atualizado no repositório. Mas, mesmo compactado, ele dá 1,4 mb e aqui só aceita anexos até 860 kb.
Como procedo para enviar?
Obrigado.
-
32 minutos atrás, José M. S. Junior disse:
Disponibilizado no SVN um ajuste referente a este possível problema... Favor atualizar todos os fontes e refazer os testes.
Boa tarde,
Fontes atualizados, testados e problema resolvido.
Obrigado.
-
3
-
-
Boa tarde,
Fontes atualizados, testados e problema resolvido.
Obrigado.
-
2
-
-
Boa tarde,
Estou tendo o erro: "cannot create file "". A sintaxe do nome do arquivo, do nome do diretório ou do rótulo do volume está incorreta"
Ocorre ao tentar imprimir o Danfe com ACBrNFeDANFeRL1 -> ACBrNFe1.NotasFiscais.Imprimir
Passou a acontecer após a atualização dos fontes ontem.A geração do .pdf (ACBrNFe1.NotasFiscais.ImprimirPDF) e também da impressão em vídeo, ou seja, com ACBrNFeDANFeRL1.MostraPreview = true, nessas duas opções o erro não ocorre.
Acontece somente quando direciona a impressão diretamente para impressora.Pensei que pudesse ser algo na impressora, mas deu erro em 3 clientes diferentes.
Alguma sugestão?
Obrigado.
Erro Cancelamento NFCe
em NFe/NFCe - Nota Fiscal Eletrônica
Postado
Putz, passamos batidos nessa, hehe!
Obrigado @BigWings.
Pode fechar o tópico.
Abraços.