Renato Chiari

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.

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.

É 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

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

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

Deu certo Luis, era isso mesmo, não tinha me atentado a esta propriedade. Valeu, obrigado!

Está OK, desculpe por ter lançado em local errado!

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

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.

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".

Somente com DBEdit

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.

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"

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

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!