Ir para conteúdo
  • Cadastre-se

valdirdill

Usuários SAC
  • Total de ítens

    624
  • Registro em

  • Última visita

  • Days Won

    1

valdirdill last won the day on 19 Março 2017

valdirdill had the most liked content!

Reputação

115 Excelente

1 Seguidor

Sobre valdirdill

  • Rank
    Membro Ativo
  • Data de Nascimento 22-07-1967

Profile Information

  • Sexo
    Masculino
  • Localização
    Curitiba-PR

Últimos Visitantes

1.603 visualizações
  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.
  2. 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. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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. Layouts_para_troca_de_informações_03-09-2018.xls
  12. valdirdill

    RESPONDIDO Manaul Bancoob

    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.
  13. Boa tarde, Fontes atualizados, testados e problema resolvido. Obrigado.
  14. Boa tarde, Fontes atualizados, testados e problema resolvido. Obrigado.
×
×
  • Criar Novo...