Jump to content

botao.pngbotao.png

botao.pngbotao.png

logo_acbr_paygo.png

TEF ACBr PayGo
Seja um revendedor e ofereça uma solução completa para seu cliente.


botao.png

beneficios.png

Renato Chiari

Membros
  • Content Count

    90
  • Joined

  • Last visited

Community Reputation

31 Excellent

About Renato Chiari

  • Rank
    Membro

Recent Profile Visitors

1,630 profile views
  1. Boa tarde, Na verdade esse cliente fez confusão, o que eles vão precisar é da NFS-e e não da NF-e. De qualquer forma obrigado pelos esclarecimentos.
  2. Boa tarde, Vamos implantar nosso software emissor da NF-e em um novo cliente de MG, será nosso primeiro cliente em MG, gostaria de confirmar se existem alguma particularidade quanto a NF-e em Minas, algo que funcione diferente de SP e que eu precise me atentar. Vi aqui pelos Mapas Fiscais que lá existe o PAF-ECF, até onde sabemos não implica em nada com a NF-e, esta informação está correta? Agradeço a ajuda e dicas que possam me dar.
  3. É exatamente isso que você disse @Juliomar Marchetti olhando a norma da ABNT no link que o @Daniel Simoes postou, o valor correto deve ser mesmo o 244,36, confesso que não sabia da regra que o 5 só pode ser arredondado "pra cima" caso o número seguinte a ele for >= 0, ou se o número anterior a ele (casa que será mantida) for ímpar, sendo assim 244,365 de acordo com a ABNT deve ficar 244,36, pra mim que o 5 sempre era arredondado "pra cima", rs. Sendo assim, meu sistema estava arredondando da forma correta desde o início... E realmente o erro está na API da prefeitura que nesse caso
  4. Boa tarde Daniel, não conhecia a RoundABNT. Porém testando com ela houve o mesmo problema, mas consegui o arredondamento correto utilizando o SimpleRoundTo fazendo uma alteração no meu código, antes o cálculo era feito da seguinte maneira: Servico.Valores.ValorIss := SimpleRoundTo(Servico.Valores.BaseCalculo * (Servico.Valores.Aliquota / 100), -2); Notei que existe uma diferença de tipos de dados entre as propriedades BaseCalculo e Aliquota, a BaseCalculo é do tipo Currency, já a Aliquota é do tipo Double, resolvi testar atribuindo o valor da Aliquota a uma variável do tipo Curr
  5. Boa tarde, hoje passei por um problema de arredondamento em um cálculo de ISS, consegui resolver com uma "gambiarra" que encontrei na internet, rs, mas gostaria de entender o motivo do problema, vou explicar melhor. Um cliente estava emitindo uma nota de serviço onde o valor do serviço prestado era de R$ 11.000,00 e a alíquota do ISS era de 2,2215%. Calculando o ISS ficaria da seguinte maneira: 11000,00 * (2,2215 / 100) = 244,365 Até aí tudo certo, o problema está na hora de arredondar o valor o ISS para 2 casas decimais, o correto nesse caso seria ficar 244,37, porém as funções
  6. Deu certo Luis, era isso mesmo, não tinha me atentado a esta propriedade. Valeu, obrigado!
  7. Bom dia, Gostaria de uma orientação, de alguém que já passou pelo problema abaixo ou sabe como proceder Temos um cliente que emitiu um CT-e de forma incorreta, ele indicou que o tomador do frente era o Remetente, porém o correto seria o Destinatário, o problema é que perceberam o erro quando já não era mais possível cancelar este CT-e para assim emitir um novo com a correção. Portanto o Remetente emitiu o evento de "Prestação de Serviço em Desacordo" e agora pelo que entendi cabe a transportadora (nosso cliente) emitir um CT-e de Anulação e depois um de Substituição corrigindo a info
  8. Tentei atualizar a Midas e nada. Fiz até um novo projeto só para testar com um DBEdit ligado a um ClientDataSet sem conexão com BD, apenas trabalhando em memória e o problema ocorre, sinal que não tem nada relacionado com o BD apenas entre DBEdit/ClientDataSet. Inclusive testei a Midas de duas formas, usando a dll registrada e apenas adicionando MidasLib aos uses.
  9. Fiz um teste aqui, No evento "onChange" do DBEdit o valor é "Ã", em seguinda no evento "onChange" do Field no Client Data Set o valor já é "A".
  10. Mas também ocorre no Seattle. O estranho é que somente nesta máquina, em outra máquina do cliente não ocorre, e esta outra máquina utiliza a máquina que apresenta o problema como servidor do BD. Eu acho que deve ser alguma coisa no Windows.
  11. Boa tarde a todos, Estou tento problemas de acentuação com uma máquina Windows 7 de um cliente. Temos 2 softwares rodando nesta máquina, um Delphi 7 com Firebird 1.5 e o outro Delphi Seattle com Firebird 2.5. No Delphi 7 os acentos são substituídos por uma espécie de pipe |, inclusive em locais onde o texto não vem do banco de dados, como o caption do CheckCox e títulos do DBGrid. No Delphi Seattle ocorre mais nos dados vindos do BD, o estranho que se eu digito um à em um DBEdit ligado a um ClientDataSet ele aparace normalmente (A com o til), porém quando o foco sai do campo o "til"
  12. Então, geralmente os que acontecem são contas do Outlook/Hotmail e Gmail, mas esses são usados por 90% dos nossos clientes. Quanto aos destinatários na maioria exite apenas 1, algumas notas são enviadas para 2 ou 3 cópias, mas acredito que não seria isso que ira caracterizar spam. Faz sentido, pois no assunto vai informando que esta sendo enviada uma nota fiscal, muitos vírus vem desta forma, rsrs. Mas o estranho é que em alguns clientes que emitem bastante nunca tiveram problemas, esta semana um criou uma nova conta no Outlook para o envio, e após cerca de 7 e-mails
  13. Problema resolvido! O pessoal da Fiorilli analisou o XML e identificou o problema, eu estava passando o valor da tag "CodigoCnae" da seguinte forma: "0105", e o servidor deles remove o 0 a esquerda, ficando assim: "105", com isso o arquivo XML acabava ficando diferente do envidado, gerando a inconsistência na assinatura. Aí que percebi que na verdade não devo passar nada na tag "CodigoCnae", somente a tag "ItemListaServico", isso para a Fiorilli. Obrigado pela ajuda de todos!
×
×
  • Create New...