Calculo de IVa

On 30 abr, 10:01, juker
wrote:

Saludos al grupo y agradecer las colaboraciones desinteresadas.

Mi problema es el siguiente y no tengo claro cual sería la mejor forma
de enfocarlo.
La aplicacion que estoy creanodo, saca los datos de unas tablas en las
cuales los precios son sin IVA.
Mi aplicacion trabaja con precios IVAS incluido, por lo tanto al
precio le calculo el iva y saco el precio final.
Pero luego traslado los datos a la aplicacion de la cual saco los
datos, por lo que realizo el proceso inverso,desgloso la base
imponible y el iva.
Pero por los redondeos entre operaciones los resultados no son
correctos.
Hago una factura precios iva incluido arts A,B,C,..total 128,65
Al trasladfarlo al programa de donde toma los datos que son precios
sin iva y le paso las bases desglosadas y unidades me calcula por ej:
128.32
La funcion format y round hacen que me muestre los precios+iva con dos
decimales pero para calculos al descartar el tercer decimal es de
donde parten las diferencias.
Por ejemplo en excel puedo hacer un calculo y formatear la celda a dos
decimales,pero los calculos los hace teniendo en cuenta el tercer
decimal.
¿Alguna funcion equiparable en Visual basic? .¿Podria ser lo mas
aconsejable acumular las difrencia del redondeo en una variable para
restarla luego del total?

Agradeceria cualquier sugerencia.

Hola,

En noviembre de 2007, Leonardo Azpurua (genuflexión de respeto
profundo), nos dijo lo siguiente:

No entiendo por que pierde el pierde un peso, pero encontre que hasta esta
cantidad el fix funciona bien :

? fix(32767.79*100) = 3276779


apartir del 32767.80 empieza la perdida el resultado es 3276779


:{

Hola, ambos:

Es un problema "conocido" con la representación de números de punto
flotante.


Nuestro sistema decimal no nos permite representar exactamente
algunas
cantidades (10/3, por ejemplo). Igualmente, las cantidades de punto
flotante
no siempre pueden representar correctamente el resultado de una
operación
que en nuestro sistema decimal no debería dar ningún problema.
Especialmente
las multiplicaciones por diez, que para nosotros simplemente
representan
agregar un cero a la derecha, para la máquina representa el
equivalente de
rotar el resultado 3,32192809488736 (que según Excel es el logaritmo 2
de
10) posiciones hacia la izquierda.


Por otra parte, la representación de punto flotante usada para los
numeros
Double contribuye a agravar esa situación.


Hay dos soluciones. La primera es utilizar valores de tipo Currency
siempre
que la precisión sea más importante que la magnitud (el mayor valor
absoluto
que puede almacenar una variable de tipo currency es (2 ^ 63) / 10000,
algo
asi como 922.3 billones). Mira este "diálogo" sostenido con la ventana
de
ejecución inmediata:


? Fix(32767.8*100)
3276779
? Fix(32767.8@ * 100@)
3276780


La segunda es sumarle una cantidad mínima al resultado de la
multiplicación
*antes* del Fix (la magnitud de la diferencia normalmente es muy
pequeña):


? Fix(32767.8*100)
3276779
? Fix(32767.8*100 + 0.000000000001)
3276779
? Fix(32767.8*100 + 0.0000000001)
3276780


aquí vemos que sumando una billonésima de unidad el resultado se
corrije.


Cuando VB "prepara" el número para su presentación (sea con Print,
Format o
al asignarlo a la propiedad Text de un control), ejecuta internamente
un
ajuste del valor (imagino que en secuencias del tipo de ,...000000x
o
,...999999x reducirá o aumentará a la unidad más cercana); pero los
valores
almacenados internamente durante la ejecución de operaciones
aritméticas no
son ajustados de esta manera. Al llamar a Fix con una secuencia ,...
99999x,
la parte decimal es tratada como una parte decimal, y eliminada sin
contemplaciones, produciendo ocasionalmente errores como el
observado.


Es un problema conocido con las operaciones de punto flotante,
documentado
en fuentes tan antiguas como los libros fundamentales de Peter Naur,
de
finales de los cincuenta.


Salud!

Como puedes ver, esto resuelve el problema de pérdida de precisión en
numeroas de punto flotante.

Saludos!