Bem-vindo, Visitante
Nome do utilizador: Senha: Memorizar
  • Página:
  • 1
  • 2

TÓPICO: Arredondamentos e SAFT

Arredondamentos e SAFT 04 Fev. 2014 20:52 #7402

  • marcolopes
  • Avatar de marcolopes
  • Offline
  • Mensagens: 5566
  • Obrigado recebido 767
mike escreveu:
O que penso que possa estar a provocar estas diferenças (é apenas uma análise, obviamente que vocês saberão melhor o que acontece na aplicação) é o seguinte:
- quando utilizam artigos/preços já presentes em base de dados, devem estar a usar o preço sem IVA, que apesar de ter 6 casas decimais, não deixa de ser, em certos casos, um arredondamento.
- quando utilizam os preços inseridos na linha, calculam o preço sem IVA com base no valor inserido, e esse calculo não é arredondado.
No primeiro caso, ao calcular o valor da linha, estão a multiplicar o valor arredondado pela quantidade. quando maior a quantidade, maior o desvio relativo ao valor real.
No segundo caso, estão a multiplicar a quantidade pelo valor obtido pelo calculo sobre o valor com IVA, valor ele não arredondado.
No final, somando as migalhas, podemos acabar por ter diferenças no total da fatura, tal como é o caso aqui.

Os valores encontrados na tabela "entidadesdocumentoslinhas" parecem confirmar estas conclusões.

Uma sugestão para que os valores batam sempre certos: mesmo quando utilizam preços de artigos que estão na base de dados, partam do preço com IVA e calculem na hora o valor sem IVA.

O seu raciocínio está 100% correcto!

A sua sugestão seria a solução ideal (aliás, diga-se, é o processo utilizado no "módulo" de POSTO de VENDA), não fosse um pequeno (grande) aspecto de implementação:

- A inicialização de uma LINHA de documento tem por base o PREÇO SEM IVA, isto porque, existe um processo bastante complexo por trás, que verifica se a ENTIDADE trabalha com o PREÇO do ARTIGO ou com o ULTIMO PREÇO, caso seja o ULTIMO PREÇO, é consultada a tabela ENTIDADESARTIGOS, e nesta tabela está a ser guardado o PREÇO SEM IVA (bem como eventuais descontos efectuados), isto porque, posteriormente é aplicado o IVA de acordo com as parametrizações consantes no REGISTO da ENTIDADE (que pode ser o IVA do ARTIGO, ou um IVA FIXO).

Técnicamente a sua análise está perfeita. A solução seria guardar o PREÇO COM IVA na tabela ENTIDADESARTIGOS, sendo este a base para o cálculo do PREÇO SEM IVA. É um caso a analisar para a versão 10.
Marco Lopes
Gestor de projecto
Análise e Programação
Última Edição: 04 Fev. 2014 20:56 por marcolopes.
O adminstrador desactivou a escrita pública.

Arredondamentos e SAFT 04 Fev. 2014 18:41 #7400

  • mike
  • Avatar de mike
  • Offline
  • Mensagens: 8
  • Obrigado recebido 4
Boa tarde,

Queria acrescentar aqui algumas coisas que vim a descobrir, baseando os meus testes no 2º exemplo, que era o que me preocupava mais.

Enquanto que os exemplos que aqui deixei no outro dia foram gerados por uma colega minha diretamente através da interface do colibri, hoje estive a fazer mais testes, inclusive utilizando a API. Resultado: os calculos são efetuados de maneira diferente consoante como são gerados os documentos, o que pode, como é o caso aqui, resultar em totais diferentes.

Se quiserem reproduzir o teste podem efetuar os seguintes passos:

1- Criar 4 artigos com os preços com IVA(23) de 10, 0.15, 2 e novamente 2 euros.
2- Criar uma nova fatura recibo onde irão ser incluídos os artigos criados com as seguintes quantidades:
- artigo1, quantidade 1, preço 10€
- artigo2, quantidade 11700, preço 0.15€
- artigo3, quantidade 4, preço 2€
- artigo4, quantidade 2, preço 2€
O resultado desta fatura será de 1776.99€. Existe aqui uma discrepância de 1 cêntimo.
3- Agora vamos criar uma outra fatura recibo, e em vez de chamar os artigos criados, vamos acrescentar linhas sem artigo mas com os mesmo preços/quantidades.
Resultado 1777.00€
4- Fazendo o teste pela API, irá obter também 1777.00€ que é o valor correto.

O que penso que possa estar a provocar estas diferenças (é apenas uma análise, obviamente que vocês saberão melhor o que acontece na aplicação) é o seguinte:
- quando utilizam artigos/preços já presentes em base de dados, devem estar a usar o preço sem IVA, que apesar de ter 6 casas decimais, não deixa de ser, em certos casos, um arredondamento.
- quando utilizam os preços inseridos na linha, calculam o preço sem IVA com base no valor inserido, e esse calculo não é arredondado.
No primeiro caso, ao calcular o valor da linha, estão a multiplicar o valor arredondado pela quantidade. quando maior a quantidade, maior o desvio relativo ao valor real.
No segundo caso, estão a multiplicar a quantidade pelo valor obtido pelo calculo sobre o valor com IVA, valor ele não arredondado.
No final, somando as migalhas, podemos acabar por ter diferenças no total da fatura, tal como é o caso aqui.

Os valores encontrados na tabela "entidadesdocumentoslinhas" parecem confirmar estas conclusões.

Uma sugestão para que os valores batam sempre certos: mesmo quando utilizam preços de artigos que estão na base de dados, partam do preço com IVA e calculem na hora o valor sem IVA.

Quanto ao meu problema, ficou resolvido a partir do momento em que passando pela API, os resultados não são arredondados e batem certo com o pretendido, inclusive no SAFT.

Cumprimentos
Última Edição: 04 Fev. 2014 19:15 por marcolopes.
O adminstrador desactivou a escrita pública.
The following user(s) said Thank You: marcolopes

Arredondamentos e SAFT 02 Fev. 2014 14:00 #7385

  • marcolopes
  • Avatar de marcolopes
  • Offline
  • Mensagens: 5566
  • Obrigado recebido 767
mike escreveu:
- No primeiro caso, os 2 produtos valem 2€ cada com IVA dando um preço unitario sem IVA de 1.626016
A primeira linha, de 4 unidades, soma um valor sem IVA de 6,50.

- Agora o segundo caso com:
A primeira linha, de 1 unidade, soma um valor sem IVA de 8.13 (unidade a 10€ com iva)

A minha questão aqui é a seguinte. Posso "forçar" o valor para 1777€? ou fazendo isso, estou a "dissimular" 0,01€ de faturação ao estado?

1) A primeira linha de 4 unidade, soma um valor sem IVA de 6.504064 (e não 6.50!)

2) A primeira linha, de 1 unidade, soma um valor sem IVA de 8.130081 (e não de 8.13!)

Claro que, se arredondar mentalmente os valores, terá discrepâncias nos resultados. O Colibri NÃO efectua arredondamentos POR LINHA, e internamente trabalha sempre com 6 casas decimais nos preços SEM IVA. Terá de ter em conta este cenário em todas as análises que fizer.

Relativamente à alteração do TOTAL geral através da API, poderá fazê-lo, mas deverá ter em conta que o TOTAL = TOTAL LIQUIDO + TOTAL IVA, e deverá jogar com os 2 valores, recalculando o TOTAL, caso contrário, andará 1 cêntimo perdido!
Marco Lopes
Gestor de projecto
Análise e Programação
Última Edição: 04 Fev. 2014 19:15 por marcolopes.
O adminstrador desactivou a escrita pública.

Arredondamentos e SAFT 31 Jan. 2014 15:46 #7361

  • mike
  • Avatar de mike
  • Offline
  • Mensagens: 8
  • Obrigado recebido 4
Boa tarde,

Estamos aqui com uma dúvida relativo a estas questões de arredondamentos.
No caso do cliente para o qual estamos a integrar o Colibri, os preços definidos são os preços para o consumidor final, ou seja já com IVA. Isto pode ter várias consequencias no momento de criar a fatura.
Em anexo envio 2 exemplos distintos, cada um apresentando um problema.
(não aparecendo nada depois de anexar os ficheiros. Não sabendo se vão de facto ficar em anexo, vou ter de detalhar aqui toda a situação)

- No primeiro caso, os 2 produtos valem 2€ cada com IVA dando um preço unitario sem IVA de 1.626016
A primeira linha, de 4 unidades, soma um valor sem IVA de 6,50.
A segunda linha, de 2 unidades, soma um valor sem IVA de 3,25.
O total, sendo assim deverir ser de 9.75, no entanto, na fatura, aprece 9.76, que apesar de contradizer os subtotais é de facto o valor correto. Pois somando o IVA aos 9.76, obtemos os 12€ pretendidos.

Para resolver este problema, pensamos em alterar a template, de forma a apresentar nas linhas os valores com iva. Nos totais iriamos então indicar que dos 12€ da fatura, 2.24€ são correspondentes ao IVA a 23%.

- Agora o segundo caso com:
A primeira linha, de 1 unidade, soma um valor sem IVA de 8.13 (unidade a 10€ com iva)
A segunda linha, de 11700 unidades, soma um valor sem IVA de 1426.83 (unidade a 0.15€ com iva)
A terceira linha, de 4 unidades, soma um valor sem IVA de 6,50 (unidade a 2€ com iva)
A quarta linha, de 2 unidades, soma um valor sem IVA de 3,25 (unidade a 2€ com iva)
Os totais apresentados são de 1444.71 sem iva, que desta vez corresponde bem a soma das partes, mas no entanto não corresponde à realidade. Pois somando o IVA dá um total de 1776.99 quando o valor a pagar deve ser 1777€.

Ao apresentar os valores com iva nas linhas como indicado anteriormente continuaria aqui a dar uma diferença de 1 centimo com o total.
Como estámos a integrar através da API, reparei na possibilidade de "forçarmos" o valor total para apresentar os 1777. No entanto, calculando o valor sem iva partindo deste total, temos um resultado de 1444,72.
O valor REAL devendo ser faturado ao cliente é de 1777€, mas fazendo assim, enquanto que na fatura o valor sem iva apresentado seria de 1444.72, no colibri e por consequência, no SAFT, esse valor iria continuar a ser de 1444,71.
A minha questão aqui é a seguinte. Posso "forçar" o valor para 1777€? ou fazendo isso, estou a "dissimular" 0,01€ de faturação ao estado?

Cumprimentos
O adminstrador desactivou a escrita pública.
The following user(s) said Thank You: marcolopes

Arredondamentos e SAFT 06 Ago. 2013 15:51 #6216

  • marcolopes
  • Avatar de marcolopes
  • Offline
  • Mensagens: 5566
  • Obrigado recebido 767
Tex escreveu:
Olá Marco, quando tirei o SAFT de julho tive o mesmo erro reportado no meu post anterior, mas desta vez o SAFT tinha 0,01€ a menos em relação ao Colibri. Tal como anteriormente o valor correto é o do Colibri e já fiz a alteração no ficheiro SAFT.
Versão: Colibri win32 9.2.1 e Saft 1.02.01

Caro Joel,

O meu conselho é que, no futuro, não se preocupe com esta discrepância. Reescrevemos o acumulador de totais para estar conforme as indicações técnicas do SAFT, e como tal, não existem milagres. Os valores podem realmente não estar de acordo, pois essa é apenas uma SOMA DE CONTROLE de todas as linhas dos documentos, e como tal, são valores NÃO ARREDONDADOS.

4.1.2. * Total dos debitos (TotalDebit) Deve conter a soma de controlo do campo 4.1.4.18.11 - Valor a debito (DebitAmount)
4.1.3. * Total dos creditos (TotalCredit) Deve conter a soma de controlo do campo 4.1.4.18.12 - Valor a credito (CreditAmount)


Aliás, se pensarmos claramente, ao EDITAR esse controle, estará a calcular um total que NÃO está de acordo com a SOMA de todas as linhas do documento...
Marco Lopes
Gestor de projecto
Análise e Programação
Última Edição: 06 Ago. 2013 15:52 por marcolopes.
O adminstrador desactivou a escrita pública.
The following user(s) said Thank You: Tex

Arredondamentos e SAFT 06 Ago. 2013 15:49 #6215

  • marcolopes
  • Avatar de marcolopes
  • Offline
  • Mensagens: 5566
  • Obrigado recebido 767
Tex escreveu:
Olá Marco, quando tirei o SAFT de julho tive o mesmo erro reportado no meu post anterior, mas desta vez o SAFT tinha 0,01€ a menos em relação ao Colibri. Tal como anteriormente o valor correto é o do Colibri e já fiz a alteração no ficheiro SAFT.
Versão: Colibri win32 9.2.1 e Saft 1.02.01

Caro Joel,

O meu conselho é que, no futuro, não se preocupe com esta discrepância. Reescrevemos o acumulador de totais para estar conforme as indicações técnicas do SAFT, e como tal, não existem milagres. Os valores podem realmente não estar de acordo, pois essa é apenas uma SOMA DE CONTROLE de todas as linhas dos documentos, e como tal, são valores NÃO ARREDONDADOS.
4.1.2. * Total dos debitos (TotalDebit) Deve conter a soma de controlo do campo 4.1.4.18.11 - Valor a debito (DebitAmount)
4.1.3. * Total dos creditos (TotalCredit) Deve conter a soma de controlo do campo 4.1.4.18.12 - Valor a credito (CreditAmount)

Aliás, se pensarmos claramente, ao EDITAR esse controle, estará a calcular um total que NÃO está de acordo com a SOMA de todas as linhas do documento...
Marco Lopes
Gestor de projecto
Análise e Programação
Última Edição: 06 Ago. 2013 15:50 por marcolopes.
O adminstrador desactivou a escrita pública.
  • Página:
  • 1
  • 2
Moderadores: marcolopes
Desenvolvido por Kunena