El viernes, 29 de septiembre de 2017, 18:57:43 (UTC-3), Pedro Enrique José 
de León Ayçaguer escribió:
>
> El módulo de tarifas por defecto sólo acepta la clave *list_price* para 
> hacer referencia al precio de venta del producto. Pero se puede extender 
> para añadir campos addicionales. En tu caso deberias añadir un campo que 
> tenga en cuenta las diferèncias de cotización. 
>
> De nuestros intercambios y otros con Marcelo Zunino llego a la conclusión 
> de que podría desde las TARIFAS resolver el manejo de los precios  en las 
> dos divisas.
>
> 1) Ya tengo donde almacenar en la Tabla de Monedas la paridad monetaria de 
> las dos divisas. 
>
> 2) Necesitaría 1 campo numérico para almacenar la PARIDAD DE COMPRA en la 
> ficha del producto.. Lo cargaría manualmente por ahora y para simplificar 
> levantando *el valor para la fecha de la compra* en la Tabla de Monedas..
>
> 4) Necesitaría poder "recoger" de la ficha del producto,  el valor PARIDAD 
> DE COMPRA,  y de la tabla de MONEDAS,    el valor COTIZACIÓN DEL DÍA,  para 
> operar en las TARIFAS con estos elementos.
>
> Con eso bastaría para "proteger" los precios de la devaluación monetaria 
> de la divisa del sistema.
>
> Mis TARIFAS serían del tipo:
>
> PRECIO PÚBLICO CONTADO ==> 
> **precio de venta* / *paridad de compra* x *cotización del día* *
>
> *Esto me proporcionaría siempre precios en PESOS actualizados siempre 
> acompañando las fluctuaciones de la moneda fuerte.*
>
> *Cuando la facturación es en Dólares Tryton tomará ese precio generado por 
> la TARIFA y lo dividirá por COTIZACIÓN DEL DÍA  obteniendo exactamente el 
> valor que al comprar fijamos como precio de venta en dólares.*
>
> Naturalmente que para obtener este resultado debemos siempre pasar por el 
> uso de TARIFAS.  
>
> Y también genera un tema no del todo deseable comercialmente que es la 
> variabilidad diaria de los precios cuando se factura en PESOS pero ello no 
> sería en definitiva demasiado problemático.
>
> *¿ Se puede lograr ésto sin grandes cambios..?  Intuitivamente me inclino 
> a pensar que sí pero ignoro cómo proceder... Lo de arriba, sí por cierto..  
> pero, ¿cómo se logra esa extensión..??*
>
> *Dicen que la ignorancia es tan respetable como la sabiduría,  ahora, es 
> mucho menos eficaz para resolver los problemas.. No se rían del "veter" y 
> echenle una mano..    Saludos cordiales.*
>
> *Enrique*
>
>  
>

Crear módulos, extender, puede adecuar el sistema a infinidad de
necesidades. Eso es indudable.
Pensaba en algo más simple, como crear reportes que expresen los valores
en una moneda diferente.

Ahora, tus requerimientos son algo más exigente. Necesitas operar y
reportar indistintamente en 2 monedas diferentes.

Sería cauteloso. Intentaría mantener en lo posible inalterado el modelo
de datos. No me entusiasmaría tanto con el agregado de campos/attributos
en las líneas de facturación (compras o ventas).

Si con dos monedas te alcanza, fijaría como moneda base aquella que
tenga mayor cantidad de movimientos. Luego marcaría sólo documentos que**no** 
correspondan a la moneda base, una simple bandera.
Esto resultaría en un modelo de datos casi sin modificaciones, que
permitiría el manejo de cálculo en todo momento. Quizá automatizar el
mantenimiento de la tabla cotizaciones de divisa que ya existe.
Con la bandera booleana tendrás la operativa limitada a solo dos divisas.

Ahora analizaría el conjunto requerimientos y las posibilidades de
resolverlos a partir de allí. Con la bandera booleana tendrás la
operativa limitada a solo dos divisas.

Sí la conclusión acaba indicando que debes agregar 4 clases más a tu
modelo y una docena de métodos... entonces ahí es otro canto. Pero no
empezaría simplemente por agregar elementos a priori.

Si a resueltas fuera ese tu camino, la sugerencia es empezar por este
comando de consola:
    
    $ python -c "import this"

De esa salida me centraría en estas 4:

    Simple is better than complex.
    Complex is better than complicated.
   
    If the implementation is hard to explain, it's a bad idea.
    If the implementation is easy to explain, it may be a good idea.
http://bit.ly/2xGEDtW


No es tan sencillo lo que necesitas. Pero tal vez, mejor que este
recetario de aficionado, sea que invites a https://github.com/pokoli con
un jarrón de buen café. Seguro de esa charla salgan mejores ideas.
Buena suerte!

Marcelo


 

Responder a