Estructuras de datos como dominios.
Hay un problema que hace tiempo me da vueltas en la cabeza y no le encuentro una buena solución.
El problema:
Supongamos que tenemos una tabla de la forma:
Cada operación que hago sobre importe, no tiene sentido si no se toma en cuenta la moneda. Si sumo los importes, tengo que tener instanciado MonedaImporte o el resultado es erróneo.
Sin embargo, no conozco en la base de datos como evitar este tipo de errores y tampoco es fácil hacerlo en GeneXus.
Sentencias erróneas.
En GeneXus estaría bueno que pudiera definir un dominio ImporteFactura= {Importe,Moneda} y que siempre trabajara con ImporteFactura, pudiendo referenciar a ImporteFactura.Importe y ImporteFactura.Moneda. En la pantalla y en los listados, se podría definir la forma en que se piden estos campos, pero estaría bueno poder poner directamente ImporteFactura y que se despliegue “100 U$S”. En la base de datos, se crearían dos campos como hasta hoy, pero en el código, no se podría utilizar uno independiente del otro.
Igual se pueden cometer errores, pero se minimizan mucho las posibilidades de meter la pata. En la próxima versión de GeneXus (PINAR) van a trabajar en hacer los dominios mas inteligentes, por lo que a lo mejor puede considerarse algo similar a esto.
Otros ejemplos de este problema.
Direccion = {Pais,Ciudad,Calle,Numero,Telefono}
Cantidades = {Cantidad,TipoBulto}
Supongo que varios deben haberse chocado con problemas similares. Como lo solucionaron?
El problema:
Supongamos que tenemos una tabla de la forma:
| Factura | Importe | MonedaImporte |
| 1 | 100 | U$S |
| 2 | 200 | Colones |
| 3 | 10 | U$S |
| 4 | 1.000 | $ |
| 5 | 30 | Yenes |
| 6 | 500 | $ |
| 7 | 800 | $ |
Cada operación que hago sobre importe, no tiene sentido si no se toma en cuenta la moneda. Si sumo los importes, tengo que tener instanciado MonedaImporte o el resultado es erróneo.
Sin embargo, no conozco en la base de datos como evitar este tipo de errores y tampoco es fácil hacerlo en GeneXus.
Sentencias erróneas.
Select Importe from factura //Muestra una lista de importe, pero no dice en que moneda estaSelect sum(Importe) from factura //Suma importes en diferentes monedas
En GeneXus estaría bueno que pudiera definir un dominio ImporteFactura= {Importe,Moneda} y que siempre trabajara con ImporteFactura, pudiendo referenciar a ImporteFactura.Importe y ImporteFactura.Moneda. En la pantalla y en los listados, se podría definir la forma en que se piden estos campos, pero estaría bueno poder poner directamente ImporteFactura y que se despliegue “100 U$S”. En la base de datos, se crearían dos campos como hasta hoy, pero en el código, no se podría utilizar uno independiente del otro.
Igual se pueden cometer errores, pero se minimizan mucho las posibilidades de meter la pata. En la próxima versión de GeneXus (PINAR) van a trabajar en hacer los dominios mas inteligentes, por lo que a lo mejor puede considerarse algo similar a esto.
Otros ejemplos de este problema.
Direccion = {Pais,Ciudad,Calle,Numero,Telefono}
Cantidades = {Cantidad,TipoBulto}
Supongo que varios deben haberse chocado con problemas similares. Como lo solucionaron?
Podes tener un ATT formula que sea el importe en la moneda de referencia onda
ResponderBorrarImporteX = Importe * TC(Moneda)
y luego, al que use el ATT Importe le das un shock electrico y ya.. a la tercera vez o queda estéril o aprende y usa el ImporteX
Alejandro:
ResponderBorrarLo que estas haciendo es convertir el importe a una misma moneda, lo cual es util en muchos casos, pero no resuelve el problema original.
Lo que quiero es poder usar el campo Importe sin que se referencie las moneda.
Hola Enrique,
ResponderBorrarYo lo he solucionado de la siguiente manera:
Puedes definir una tabla divisa o moneda, donde definas el tipo de cambio de cada de divisa y relacionarla con la factura.
Si necesitaras que al momento de registrar la factura guarde el tipo de cambio que estaba la divisa, guarda en la tabla factura el tipo de cambio.
Podrías consultar mutiplicando importe * tipo de cambio, o bien, definir un campo fórmula q ya lo multiplique.
Recibe un cordial saludo!!!
De acuerdo con el comentario anterior, sino se podría solucionar con un Where o un group by no? (nunca usé Genexus, pero llevándolo a SQL...).
ResponderBorrarIgual me quedo con la idea de tener una tabla aparte con los tipo de monedas, por qué?, imagínate que quieres saber cuántos tipos de monedas hay, con la tabla anterior tienes que recorrerla toda si o si (no tú, pero Genexus seguro).
Saludos,
@andrescanavesi
Andres y Wual:
ResponderBorrarLa tabla de monedas tiene que existir. No la puse, pues no aporta para el problema que quiero plantear y resolver.
Como dice antres, en SQL la consulta para la suma, deberia ser:
Select sum(Importe), moneda from factura group by moneda
De otra forma, el resulta es incorrecto.
A lo mejor no quedo del todo claro, pero el problema NO ES SOLO el sumar en una misma moneda o convertir todo a una sola moneda, sino evitar que los programadores cometamos errores sumando cosas en diferentes moendas.
Gracias por los comentarios
Este post entra en la categoria 'que inteligente que es este tipo, dijo lo que yo pienso!' :)
ResponderBorrarCon los nuevos domains en la Pinar pensamos hacer exactamente lo que sugeris en el post, de hecho uno de los ejemplo es justamente el Domain Importe (que contiene Cantidad y Moneda).
Uno de los temas que mas nos complico es como resolver la integridad referencial dentro del Domain (en el caso Moneda podria tener una tabla asociada), pero creo que ya lo tenemos resuelto.
Anonimo:
ResponderBorrarEs bueno saber que estan trabajando en esa linea, pues creo que puede servirnos a todos.
Si en forma "independiente" se llega a conclusiones parecidas, indica que el problema que se esta resolviendo es relevante y que la solucion esta bien rumbeada.
Gracias por el comentario.
Lo que no aclara anónimo es si no se podrá acceder a cada atributo en forma individual, es decir si serán "privados" en el dominio.
ResponderBorrarEstamos hablando de SDT con métodos?
Javier:
ResponderBorrarEs algo asi como SDT con metodos. No conozco detalles de la implementacion, pero creo que acceder a los campos individualmente es algo indispensable.
Lo importante es saber que los campos estan agrupados y hara mas dificil usar el importe, sin usar la moneda.