[tryton-es] TRYTON ME ENVÍA A LA QUIEBRA

[Pedro Enrique José de León Ayçaguer]

Estimados: arranco de nuevo. Creo que no termino de explicarme o algo estoy
entendiendo mal. Sergi Almacellas me señala que en el módulo de Facturación
al efectuar una compra y marcar MONEDA diferente de la del sistema Tryton
hace la conversión para el apunte contable. ESO ESTÁ CLARO. Pero no es el
problema que intento compartir con Uds.


*Primero:* Tryton asume que los precios de COSTO y VENTA de los
productos están fijados en la MONEDA POR DEFECTO de la Empresa.
*Segundo:* Tryton necesita que le anotemos el precio de COSTO y de VENTA
de cada producto.




*ESTOY TOMANDO ÉSTO COMO CIERTO por más que no es lo que pretendo. (Mi
aspiración es que guarde COSTO en la moneda de compra y el VALOR según
criterio fijado, ya sea última compra, compra más antigua o promedio. Y que
ésto se realice de forma automática para cada compra de producto. Los
precios de VENTA a partir de allí.)Si lo asumido arriba que TRYTON hace es
correcto:*
Compro producto "A" que me lo facturan (y debo pagar) en dólares
americanos. U$S 15 con una Tasa de Cambio de 27 pesos uruguayos =>
costo $ 405,00 en el momento de la compra. *Entiendo que es el precio
que debo asignar al producto en la moneda del sistema en el campo **precio
de costo*

Fijo precio de venta con margen 25 % => 15 * 1,25 = U$S 18,75 Tasa de
Cambio de 27 pesos uruguayos => venta $ 506,25
*y asigno ese importe en pesos (moneda del sistema) en el campo **precio
de venta*


Un año después Tasa de Cambio U$S 1 => 35,10 pesos uruguayos
Facturo en dólares ese producto y Tryton dice en la factura que vale *precio
de venta=*$ 506,25 / cotización 35,1 = U$S 14,4231

*Compré a U$S 15 y estoy vendiendo un año después a U$S 14,4231 con
lo que ni siquiera cubro los costos... *

Me inclino a creer que el tema de poner los precios en los campos del
producto debe ser para permitir la modificación manual, pero que de algún
modo ellos deben ser "levantados" por el sistema desde las compras... Si
así fuera bastaría con establecer tarifas para la venta en dólares y otras
para la venta en moneda del sistema teniendo también en cuenta si partimos
de compras efectuadas en una u otra moneda..... NO se. Ando bastante
embarullado con esto.
GRACIAS POR VUESTRO "piense"
*> *

[Sergi Almacellas Abellana]

Post by Pedro Enrique José de León Ayçaguer
Estimados: arranco de nuevo. Creo que no termino de explicarme o algo estoy
entendiendo mal. Sergi Almacellas me señala que en el módulo de
Facturación
al efectuar una compra y marcar MONEDA diferente de la del sistema Tryton
hace la conversión para el apunte contable. ESO ESTÁ CLARO. Pero no es
el
problema que intento compartir con Uds.
*Primero:* Tryton asume que los precios de COSTO y VENTA de los
productos están fijados en la MONEDA POR DEFECTO de la Empresa.

Eso es asi.

Post by Pedro Enrique José de León Ayçaguer
*Segundo:* Tryton necesita que le anotemos el precio de COSTO y de VENTA
de cada producto.

Eso no es verdad. En cada compra/venta puedes entrar el precio a mano i este puede ser el que tu quieras.

Post by Pedro Enrique José de León Ayçaguer
*ESTOY TOMANDO ÉSTO COMO CIERTO por más que no es lo que pretendo. (Mi
aspiración es que guarde COSTO en la moneda de compra y el VALOR según
criterio fijado, ya sea última compra, compra más antigua o promedio.

En el metodo de coste le puedes assignar el promedio y tryton te lo va a calcular. Eso si... siempre en la moneda de la empresa.

Y

Post by Pedro Enrique José de León Ayçaguer
que
ésto se realice de forma automática para cada compra de producto. Los
precios de VENTA a partir de allí.)

Debes extender las lineas de tarifa para poder asignar tarifas a partir del precio de coste. Una vez tengas esto puedes usar una formula para aplicar el margen que quieras.

Si especificas una divisa distinta en la venta, tryton te va hacer la conversion en el momento.

Utilizando este metodo, nadie te va a arruinar. De nada ;)

Un saludo,

[Pedro Enrique José de León Ayçaguer]

*Eso no es verdad. En cada compra/venta puedes entrar el precio a mano i
este puede ser el que tu quieras. *

Acá la pregunta es: ¿el precio de la compra se ve reflejado en el campo *precio
de costo* si voy a la ficha del producto a consultarlo..?

*En el metodo de coste le puedes assignar el promedio y tryton te lo va a

calcular. Eso si... siempre en la moneda de la empresa.*

Bueno, ese es el problema. Tanto si el precio de costo es fijo como si es
promediado, al no guardarlo en la moneda de compra cuando lo reconvierta
con una cotización diferente nos devolverá un valor que no es el
original... y cuando la moneda del sistema se deprecia en relación a la
moneda de compra, las tarifas de venta arrojan valores que van reduciendo
cada vez más los márgenes de utilidad.


El miércoles, 27 de septiembre de 2017, 18:22:47 (UTC-3), Sergi Almacellas

On 27 de setembre de 2017 23.13.48 CEST, "Pedro Enrique José de León

Post by Pedro Enrique José de León Ayçaguer
Estimados: arranco de nuevo. Creo que no termino de explicarme o algo estoy
entendiendo mal. Sergi Almacellas me señala que en el módulo de Facturación
al efectuar una compra y marcar MONEDA diferente de la del sistema Tryton
hace la conversión para el apunte contable. ESO ESTÁ CLARO. Pero no es el
problema que intento compartir con Uds.
*Primero:* Tryton asume que los precios de COSTO y VENTA de los
productos están fijados en la MONEDA POR DEFECTO de la Empresa.

Eso es asi.

Post by Pedro Enrique José de León Ayçaguer
*Segundo:* Tryton necesita que le anotemos el precio de COSTO y de VENTA
de cada producto.

Eso no es verdad. En cada compra/venta puedes entrar el precio a mano i
este puede ser el que tu quieras.

Post by Pedro Enrique José de León Ayçaguer
*ESTOY TOMANDO ÉSTO COMO CIERTO por más que no es lo que pretendo. (Mi
aspiración es que guarde COSTO en la moneda de compra y el VALOR según
criterio fijado, ya sea última compra, compra más antigua o promedio.

En el metodo de coste le puedes assignar el promedio y tryton te lo va a
calcular. Eso si... siempre en la moneda de la empresa.
Y

Post by Pedro Enrique José de León Ayçaguer
que
ésto se realice de forma automática para cada compra de producto. Los
precios de VENTA a partir de allí.)

Debes extender las lineas de tarifa para poder asignar tarifas a partir
del precio de coste. Una vez tengas esto puedes usar una formula para
aplicar el margen que quieras.
Si especificas una divisa distinta en la venta, tryton te va hacer la
conversion en el momento.
Utilizando este metodo, nadie te va a arruinar. De nada ;)
Un saludo,
--
Enviado desde mi dispositivo Android con K-9 Mail. Por favor, disculpa mi brevedad.

[Sergi Almacellas Abellana]

*Eso no es verdad. En cada compra/venta puedes entrar el precio a
mano i este puede ser el que tu quieras. *
Acá la pregunta es:  ¿el precio de la compra se ve reflejado en el campo
*/precio de costo/* si voy a la ficha del producto a consultarlo..?

Depende del método de coste. Si es fijo no se actualiza pero los otros si.

Un pequeño matiz: El precio de coste se actualiza al realizar un
movimiento de stock, no con el de la compra. Al crear los movimientos de
entrada de una compra, se pone el precio de coste de la compra, pero se
puede ajustar mas tarde en caso que este sea diferente.

*En el metodo de coste le puedes assignar el promedio y tryton te lo
va a calcular. Eso si... siempre en la moneda de la empresa.*
Bueno, ese es el problema. Tanto si el precio de costo es fijo como si
es promediado, al no guardarlo en la moneda de compra cuando lo
reconvierta con una cotización diferente nos devolverá un valor que no
es el original...

Si haces compras en distintas divisas, no sabrías en que divisa lo
tienes. Se hace en la moneda de la empresa para poder convertir todas
las otras divisas en una sola.

y cuando la moneda del sistema se deprecia en relación

a la moneda de compra,  las tarifas de venta arrojan valores que van
reduciendo cada vez más los márgenes de utilidad.

Creo que no haces bien las cuentas en este punto. Si tu te ha costado X
en la moneda de la empresa, y lo vendes por X + Y (convertido en
dolares). Siempre vas a ganar Y independientemente de la tasa de
cambio. Por ejemplo:

Compras a 100$, la tasa de cambio con el euro es 0.8, por lo que tienes
80€ de precio de coste
Aplicas un margen de 20€ por lo que el precio de venta es 100€
A la hora de vender el cambio es de 0.6, por lo que lo estarias
vendiendo por 166$ (en vez de los 125$ que seria con la tasa de cambio
de 0.8).

De hecho se hace así para evitar las diferencias de cambio.

Un saludo,

P.S: Un cafetito com agradecimiento por salvarte de la quiebra?
https://ko-fi.com/A6544A06

[Pedro E.J. de León]

A ver Sergi:   para el cafetito, que nosotros diríamos cafecito, vamos
estando un poco lejos, salvo que lo tomemos cada uno por su lado.
Compro producto en € 8 y tryton guarda $ 280 como costo porque *pesos*
es la moneda del sistema. ($ 35 cada Euro)
Aplico Tarifa de venta con margen 25 %   $ 280 x 1,25 = $ 350 es mi
precio de VENTA  (Obtengo € 10     350/35= €10)
Mi costo fueron € 8 y obtuve € 10  con lo que € 2  han quedado en mis
arcas*porque la cotización no varió.*

Un año después vendo de nuevo el producto. Tryton mira el costo, aplica
la Tarifa y cuando hace la conversión para cobrar la factura en Euros
encuentra que necesito*$ 40 para comprar cada Euro.*.   Así  los 350
pesos / 40 darán un valor de € 8,75 a la factura de VENTAS..   
Claramente mi margen de utilidad va "en picada" ...

El tema y su dificultad estriba en que la MONEDA DEL SISTEMA en nuestro
caso es la moneda débil,  la que se deprecia con respecto a la MONEDA DE
COMPRA.  No a la inversa.

Yo necesito que el sistema pueda determinar el valor en que realmente
fue comprado el producto. Que si costó € 8 no me diga un año después que
costó € 7 ...

    *Eso no es verdad. En cada compra/venta puedes entrar el precio a
    mano i este puede ser el que tu quieras. *
Acá la pregunta es:  ¿el precio de la compra se ve reflejado en el
campo */precio de costo/* si voy a la ficha del producto a
consultarlo..?

Depende del método de coste. Si es fijo no se actualiza pero los otros
si.
Un pequeño matiz: El precio de coste se actualiza al realizar un
movimiento de stock, no con el de la compra. Al crear los movimientos
de entrada de una compra, se pone el precio de coste de la compra,
pero se puede ajustar mas tarde en caso que este sea diferente.

    *En el metodo de coste le puedes assignar el promedio y tryton te lo
    va a calcular. Eso si... siempre en la moneda de la empresa.*
Bueno, ese es el problema. Tanto si el precio de costo es fijo como
si es promediado, al no guardarlo en la moneda de compra cuando lo
reconvierta con una cotización diferente nos devolverá un valor que
no es el original...

Si haces compras en distintas divisas, no sabrías en que divisa lo
tienes. Se hace en la moneda de la empresa para poder convertir todas
las otras divisas en una sola.
 y cuando la moneda del sistema se deprecia en relación

a la moneda de compra,  las tarifas de venta arrojan valores que van
reduciendo cada vez más los márgenes de utilidad.

Creo que no haces bien las cuentas en este punto. Si tu te ha costado
X en la moneda de la empresa, y lo vendes por X + Y (convertido en
dolares). Siempre vas a ganar  Y independientemente de la tasa de
Compras a 100$, la tasa de cambio con el euro es 0.8, por lo que
tienes 80€ de precio de coste
Aplicas un margen de 20€ por lo que el precio de venta es 100€
A la hora de vender el cambio es de 0.6, por lo que lo estarias
vendiendo por 166$ (en vez de los 125$ que seria con la tasa de cambio
de 0.8).
De hecho se hace así para evitar las diferencias de cambio.
Un saludo,
P.S: Un cafetito com agradecimiento por salvarte de la quiebra?
https://ko-fi.com/A6544A06

[Sergi Almacellas Abellana]

A ver Sergi:   para el cafetito, que nosotros diríamos cafecito, vamos
estando un poco lejos, salvo que lo tomemos cada uno por su lado.

Por mi lo podemos tomar cada uno por su lado.

Compro producto en € 8 y tryton guarda $ 280 como costo porque *pesos*
es la moneda del sistema. ($ 35 cada Euro)
Aplico Tarifa de venta con margen 25 %   $ 280 x 1,25 = $ 350 es mi
precio de VENTA  (Obtengo € 10     350/35= €10)
Mi costo fueron € 8 y obtuve € 10  con lo que € 2  han quedado en mis
arcas*porque la cotización no varió.*
Un año después vendo de nuevo el producto. Tryton mira el costo, aplica
la Tarifa y cuando hace la conversión para cobrar la factura en Euros
encuentra que necesito*$ 40 para comprar cada Euro.*.

Tu no eres quien compra en euros, sinó la persona que te compra tu
producto.

  Así  los 350

pesos / 40 darán un valor de € 8,75 a la factura de VENTAS..
Claramente mi margen de utilidad va "en picada" ... > El tema y su dificultad estriba en que la MONEDA DEL SISTEMA en nuestro
caso es la moneda débil,  la que se deprecia con respecto a la MONEDA DE
COMPRA.  No a la inversa.

El problema no es de tryton, sinó del tipo de negocio que tiene
asociados unos riesgos por los que te debes cubrir. Para esto existe un
producto financiero que se llama opciones sobre divisa. Reducen un poco
el margen pero te permiten asegurar que lo que perderías por un lado lo
ganes por el otro.

Yo necesito que el sistema pueda determinar el valor en que realmente
fue comprado el producto. Que si costó € 8 no me diga un año después que
costó € 7 ...

Utiliza un lote único para cada producto, de esa forma podrás
identificar que movimiento fue el que compraste el producto exacto y
saber el costo exacto. En ese movimiento tienes la referencia a la
compra asociada, por lo que puedes saber la divisa el precio y teniendo
el historico de cotizaciones (o bien guardar la tasa de cambio en la
linea para tener el valor exacto utilizado) podrás saber los valores en
las dos divisas.

Con esas información, haz toda la matemática que quieras para que tu
negocio sea rentable :)

[Pedro E.J. de León]

Tu no eres quien compra en euros, sinó la persona que te compra tu
producto.

Sergi, *SÍ COMPR**O *en Euros (en dólares en realidad pero a los efectos
es lo mismo) y vendo también en esa divisa que no es la del sistema. De
ahí la importancia de no "perder la referencia" cuando se calcula el
precio de venta.  De otro modo, cuando voy a reponer el Stock con pesos
"flacos" ya no no puedo comprar los Euros necesarios (dólares en mi
caso) para recuperar las unidades vendidas.

Para esto existe un producto financiero que se llama opciones sobre
divisa.

Esto parece interesante. Pero tendré que indagar dónde lo encuentro y
cómo funciona.

Utiliza un lote único para cada producto, de esa forma podrás
identificar que movimiento fue el que compraste el producto exacto y
saber el costo exacto. En ese movimiento tienes la referencia a la
compra asociada, por lo que puedes saber la divisa el precio y
teniendo el historico de cotizaciones (o bien guardar la tasa de
cambio en la linea para tener el valor exacto utilizado) podrás saber
los valores en las dos divisas.

Estuve mirando un poco en la pestaña /*Lotes*/ de un producto pero no
llegué a interpretar demasiado el procedimiento..

Sobre esta idea, aunque yo iba por el lado de los ATRIBUTOS,  tenía
alguna esperanza de solucionar guardando la COTIZACIÓN correspondiente a
la fecha de la operación de compra.  Los precios en moneda local, de
Venta y de Compra, se establecerían a partir de ella.

TARIFA calcularía precio de VENTA en moneda de sistema=/(*precio de
venta* / *atributo COTIZACIÓN* x *margen ganancia *x *cotización del día*)/

/para que Tryton recupere el valor correcto en la otra Divisa volviendo
a dividir entre *cotización del día* con lo que obtendremos lo deseado. /

Supongo que así podría funcionar sin tocar el programa.... y tendría
toda la información reunida en la "ficha" del producto.

*Claro que para escribir aquella instrucción en la TARIFA necesitaré de
vuestro concurso porque no sabría como decírselo...  Todavía no me he
familiarizado lo suficiente como para saber dónde encontrar los nombres
internos de los campos donde se almacenan los datos...***Ténganle
paciencia al anciano....  Que queda a Uds.  más que muy agradecido.

**

[Sergi Almacellas Abellana]

Post by Sergi Almacellas Abellana
Tu no eres quien compra en euros, sinó la persona que te compra tu
producto.

Sergi, *SÍ COMPR**O *en Euros (en dólares en realidad pero a los efectos
es lo mismo) y vendo también en esa divisa que no es la del sistema. De
ahí la importancia de no "perder la referencia" cuando se calcula el
precio de venta.  De otro modo, cuando voy a reponer el Stock con pesos
"flacos" ya no no puedo comprar los Euros necesarios (dólares en mi
caso) para recuperar las unidades vendidas.

Post by Sergi Almacellas Abellana
Para esto existe un producto financiero que se llama opciones sobre
divisa.

Esto parece interesante. Pero tendré que indagar dónde lo encuentro y
cómo funciona.

Habla con tu entidad financiera.

Post by Sergi Almacellas Abellana
Utiliza un lote único para cada producto, de esa forma podrás
identificar que movimiento fue el que compraste el producto exacto y
saber el costo exacto. En ese movimiento tienes la referencia a la
compra asociada, por lo que puedes saber la divisa el precio y
teniendo el historico de cotizaciones (o bien guardar la tasa de
cambio en la linea para tener el valor exacto utilizado) podrás saber
los valores en las dos divisas.

Estuve mirando un poco en la pestaña /*Lotes*/ de un producto pero no
llegué a interpretar demasiado el procedimiento..

Creo que la parte relevante es la de los movimientos de stock, que es
dónde le assignas el lote a cada movimiento.

Sobre esta idea, aunque yo iba por el lado de los ATRIBUTOS,  tenía
alguna esperanza de solucionar guardando la COTIZACIÓN correspondiente a
la fecha de la operación de compra.  Los precios en moneda local, de
Venta y de Compra, se establecerían a partir de ella.

Si vas a añadir este tipo de campos, mejor un módulo y añadir el campo
explícitamente que no utilizar atributos.

TARIFA calcularía precio de VENTA en moneda de sistema=/(*precio de
venta* / *atributo COTIZACIÓN* x *margen ganancia *x *cotización del día*)/
/para que Tryton recupere el valor correcto en la otra Divisa volviendo
a dividir entre *cotización del día* con lo que obtendremos lo deseado. /
Supongo que así podría funcionar sin tocar el programa.... y tendría
toda la información reunida en la "ficha" del producto.

La gracia de todo es que hagas un par de módulos para tocar el programa
y adapatarlo a tus necessidades. Por lo que comentas no debería ser muy
complicado.

*Claro que para escribir aquella instrucción en la TARIFA necesitaré de
vuestro concurso porque no sabría como decírselo...  Todavía no me he
familiarizado lo suficiente como para saber dónde encontrar los nombres
internos de los campos donde se almacenan los datos...***Ténganle
paciencia al anciano....  Que queda a Uds.  más que muy agradecido.

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.

Un saludo,

**

[Pedro E.J. de León]

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*

[Marcelo Zunino]

El viernes, 29 de septiembre de 2017, 18:57:43 (UTC-3), Pedro Enrique José

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

[Marcelo Zunino]

He cambiado el tópico de hilo, adecuándolo a la temática.

...  No tengo claro a qué llamas "bandera" ni a qué te refieres cundo
dices "documento"..  Un campo de Tipo booleano me es familiar pero si
se trata de eso me pregunto por qué no un campo de Selección que
permita, si quieres,  agregar otras monedas...

*Acotado a los requerimientos* que has planteado, por "documentos"
refiero a entidades creadas para modelar operaciones de la gestión que
necesariamente deban ser expresados en dos monedas diferentes.
Para el caso, *facturación* de compras y ventas. Incluyo operaciones
derivadas, por ejemplo, contabilidades, accounting y valoración de
inventarios.
La "bandera" booleana sería a efectos de marcar éstos _documentos_ al
momento de su creación/alta en el sistema. El mantenimiento de
cotizaciones es un elemento de Tryton que sería interesante automatizar.

Estos elementos deberían alcanzar para analizar las posibilidades de
cubrir tus necesidades, apelando a la extensión de módulos.

En cuanto a "selección/booleano". La inclinación por éste último en
principio es por una cuestión de simplicidad. Claro que todo es muy
preliminar y en el aire.

Saludos.
Marcelo.

[Pedro E.J. de León]

La "bandera" booleana sería a efectos de marcar éstos_documentos_ al
momento de su creación/alta en el sistema. El mantenimiento de
cotizaciones es un elemento de Tryton que sería interesante automatizar.

Sigue tu afirmación necesitando "traducción"...  a los efectos
prácticos,  cuando el operador va a facturar, o a ingresar un pedido a
proveedor, obligadamente debería tomar una de dos opciones de
moneda...???  O si va a registrar una operación bancaria...?  Me imagino
que estás hablando de algo que se hace de una vez, tipo configuración, 
y luego funciona simplemente obligando al operador a transitar ese
camino de opciones...
Igual, por algunas exploraciones que he realizado tengo la impresión de
que esto ya ocurre desde las compras y las ventas al menos,  por más que
utilizando un "ventana" de selección que escoge en la tabla de monedas......
O se trata de otras "banderas"...  Yo daba por hecho que cuando me pide
la moneda para la factura, y no es la del sistema,  hacía los registros
con valores en PESOS y en DÓLARES...  ¿No ocurre esto así??

De cualquier modo ésto no me resolvería el problema de los precios de la
facturación... a menos que cuando dices antes

El mantenimiento de cotizaciones es un elemento de Tryton que sería
interesante automatizar.

 te estés refiriendo a mantener la PARIDAD entre monedas al momento de
la compra de los productos y reproducirla al momento de la venta a
partir de una cotización actualizada.  ESO ES LO QUE YO PRETENDÍA HACER
DESDE LA TARIFA pero para lo que necesitaba poder recoger en ella la
COTIZACIÓN DE COMPRA y la COTIZACIÓN del día de la factura de venta.  
Seguramente sería más "prolijo" que,  al menos los precios de productos
comprados en dólares,  se actualizaran automáticamente en su valor
PESOS  para que el sistema no distorsionara su valor real...
No estaría demás que también "salvaguardara" el valor de lo adquirido en
PESOS poniéndolo a cubierto del efecto inflacionario...

Saludos cordiales
                                Enrique

[Marcelo Zunino]

Post by Marcelo Zunino
La "bandera" booleana sería a efectos de marcar éstos _documentos_ al
momento de su creación/alta en el sistema. El mantenimiento de
cotizaciones es un elemento de Tryton que sería interesante automatizar.

Sigue tu afirmación necesitando "traducción"...  a los efectos
prácticos,  cuando el operador va a facturar, o a ingresar un pedido a
proveedor, obligadamente debería tomar una de dos opciones de
moneda...??? 

Te faltó un trozo de cita: 

... *operaciones* de la gestión que necesariamente deban ser expresados en dos monedas diferentes. Para el caso, *facturación* de compras y ventas. Incluyo operaciones derivadas, por ejemplo, contabilidades, accounting y valoración de
inventarios.

y sí, estos documentos tendrían un checkbox con una leyenda del tipo:
`Los valores ingresados son dólares` o simplemente `u$s ?` si estás
corto de espacio en pantalla. Bueno, así sería si optas por Pesos como
moneda principal, de lo contrario será al revés.

Las operaciones derivadas son un ejemplo. Obviamente que podrían quedar
sin marca, o sea en la moneda default.


Pedro, estamos hablando sobre una idea de diseño para módulo/s de

... analizaría el conjunto requerimientos y las posibilidades de
resolverlos a partir de allí.
...
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.

Creo que profundizar en detalles de implementación escapa al ámbito de
una lista de ayuda. Corremos el riesgo de aburrir a mucha gente por
aquí, dado que acabaríamos en una suerte de hilo de consultoría
voluntaria...

Te he comentado antes que mi experiencia con Tryton no llega siquiera a
elemental. Sólo puedo aportar ideas generales, muy a la "vaporware"...
:)  y ni siquiera dispongo de mucho tiempo libre para eso :(

Creo que no sería mala idea que tomaras seriamente la sugerencia de
Sergi, por ejemplo

P.S: Un cafetito ... https://ko-fi.com/A6544A06

Seguro te quitarás las dudas sobre si Tryton es o no la herramienta
adecuada, además de adquirir una buena idea del esfuerzo y recursos que
insumiría la adaptación que necesitas.

Saludos,
Marcelo.

[Marcelo Zunino]

Gracias Marcelo.  Creo que ahora sí estamos más claro. En todos los
casos que uso Moneda Secundaria *efectivamente necesito obtener los
reportes en ambas monedas*. Razón por la cual debería poder indicárselo.
Te mando un abrazo y mi reconocimiento por tu invalorable ayuda.  Te
tendré al tanto por si logramos algo que sirva para la comunidad. 

Sería muy buena idea si pudieras compartirlos, claro. A todos nos gustaría!

Después veré de avisarte de un script de instalación que preparó el
Dr. González Barbone y que yo utilicé con buen suceso.  Hasta pronto
Enrique

Saludos,
Marcelo.

Post by Marcelo Zunino

Post by Marcelo Zunino
La "bandera" booleana sería a efectos de marcar éstos _documentos_ al
momento de su creación/alta en el sistema. El mantenimiento de
cotizaciones es un elemento de Tryton que sería interesante automatizar.

Sigue tu afirmación necesitando "traducción"...  a los efectos
prácticos,  cuando el operador va a facturar, o a ingresar un pedido a
proveedor, obligadamente debería tomar una de dos opciones de
moneda...??? 

Te faltó un trozo de cita: 

... *operaciones* de la gestión que necesariamente deban ser expresados en dos monedas diferentes. Para el caso, *facturación* de compras y ventas. Incluyo operaciones derivadas, por ejemplo, contabilidades, accounting y valoración de
inventarios.

`Los valores ingresados son dólares` o simplemente `u$s ?` si estás
corto de espacio en pantalla. Bueno, así sería si optas por Pesos como
moneda principal, de lo contrario será al revés.
Las operaciones derivadas son un ejemplo. Obviamente que podrían quedar
sin marca, o sea en la moneda default.
Pedro, estamos hablando sobre una idea de diseño para módulo/s de

... analizaría el conjunto requerimientos y las posibilidades de
resolverlos a partir de allí.
...
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.

Creo que profundizar en detalles de implementación escapa al ámbito de
una lista de ayuda. Corremos el riesgo de aburrir a mucha gente por
aquí, dado que acabaríamos en una suerte de hilo de consultoría
voluntaria...
Te he comentado antes que mi experiencia con Tryton no llega siquiera a
elemental. Sólo puedo aportar ideas generales, muy a la "vaporware"...
:)  y ni siquiera dispongo de mucho tiempo libre para eso :(
Creo que no sería mala idea que tomaras seriamente la sugerencia de
Sergi, por ejemplo

P.S: Un cafetito ... https://ko-fi.com/A6544A06

Seguro te quitarás las dudas sobre si Tryton es o no la herramienta
adecuada, además de adquirir una buena idea del esfuerzo y recursos que
insumiría la adaptación que necesitas.
Saludos,
Marcelo.

[Sergi Almacellas Abellana]

Post by Marcelo Zunino

Post by Marcelo Zunino
La "bandera" booleana sería a efectos de marcar éstos _documentos_ al
momento de su creación/alta en el sistema. El mantenimiento de
cotizaciones es un elemento de Tryton que sería interesante automatizar.

Sigue tu afirmación necesitando "traducción"...  a los efectos
prácticos,  cuando el operador va a facturar, o a ingresar un pedido a
proveedor, obligadamente debería tomar una de dos opciones de
moneda...???
... *operaciones* de la gestión que necesariamente deban ser expresados en dos monedas diferentes. Para el caso, *facturación* de compras y ventas. Incluyo operaciones derivadas, por ejemplo, contabilidades, accounting y valoración de
inventarios.

`Los valores ingresados son dólares` o simplemente `u$s ?` si estás
corto de espacio en pantalla. Bueno, así sería si optas por Pesos como
moneda principal, de lo contrario será al revés.

Eso seria redudante con el campo divisa que ya existe en estos documentos...

[Pedro E.J. de León]

En efecto Sergi,  estuve revisando como guarda los documentos y es como
tú dices...  En cuanto a la actualización de la Tabla de cotizaciones
acá en Uruguay el Banco Central proporciona una bastante completa
relacionada con la Moneda local..

Post by Sergi Almacellas Abellana
Eso seria redudante con el campo divisa que ya existe en estos
documentos...

[Sergi Almacellas Abellana]

Post by Marcelo Zunino
El mantenimiento de
cotizaciones es un elemento de Tryton que sería interesante automatizar.

No es muy complicado crear un módulo que obtenga las cotizaciones de
algún webservice oficial y las actualitze en la base de datos.

Un saludo,

[Marcelo Zunino]

Post by Sergi Almacellas Abellana

Post by Marcelo Zunino
El mantenimiento de
cotizaciones es un elemento de Tryton que sería interesante automatizar.

No es muy complicado crear un módulo que obtenga las cotizaciones de
algún webservice oficial y las actualitze en la base de datos.
Un saludo,

Hola,
Usando `suds` resultó muy fácil, realmente.

Es menos que un aprueba de concepto, pero funciona. Los valores de
configuración están forzados en el código. Como mínimo las fechas
deberían ser parámetros, apenas tenga un tiempo.... Tal vez alguien se
anima a transformarlo en un script útil.

    https://bitbucket.org/mzunino/cotiza_bcu

Saludos

[Marcelo Zunino]

He puesto un commit que corrige la falta de llamado a la función que genera
las definiciones.
En las pruebas me funcionó porque ya tenía el xml con las definiciones... :/

Saludos.


https://bitbucket.org/mzunino/cotiza_bcu/commits/all

Hola,
Usando `suds` resultó muy fácil, realmente.
Es menos que un aprueba de concepto, pero funciona. Los valores de
configuración están forzados en el código. Como mínimo las fechas
deberían ser parámetros, apenas tenga un tiempo.... Tal vez alguien se
anima a transformarlo en un script útil.
https://bitbucket.org/mzunino/cotiza_bcu
<https://www.google.com/url?q=https%3A%2F%2Fbitbucket.org%2Fmzunino%2Fcotiza_bcu&sa=D&sntz=1&usg=AFQjCNFL_TvmrjcsUtMp_ztf1FJy908ZRg>
Saludos

[Pedro E.J. de León]

Buen día Marcelo:

Vamos con algunas precisiones.

COMPRO en Euros  (en dólares en realidad pero a los
efectos es lo mismo) y vendo también en esa divisa ...

Esto es así pero no  exclusivamente así. Las compras y ventas se hacen
en las dos monedas (Moneda Nacional y Dólares) y también las ventas. Son
los productos comprados en dólares, cuya reposición de stock vuelve a
requerir una compra en dólares, los que representan una situación de
riesgo desde el punto de vista de la rentabilidad.

Hoy la Empresa (en su viejo Clipper) almacena el último Precio de cada
producto y la Moneda en que está comprado.  Y se maneja así:

*Venta en PESOS  1*)  Si Precio "viene" en DÓLARES hace la conversión al
cambio establecido en la Tabla MONEDAS en campo DOLAR FUTURO que se
revisa periódicamente para que esté "un pasito adelante" de la
cotización vigente en el momento de la operación con lo cual se cubren
dos objetivos: a) los pesos obtenidos de la venta permiten comprar en el
mercado los dólares necesarios a realizar la ganancia y hacer la
reposición del producto..   b) los precios en Moneda Nacional de los
productos comprados en dólares no sufren modificaciones diarias sino
periódicamente cuando se hace el ajuste del DOLAR FUTURO.

*Venta en PESOS  2)*  Si Precio "viene" en PESOS se utiliza directamente
el valor para la facturación.

*Venta en D**Ó**LARES**  3)* Si Precio "viene" en PESOS se convierte a
Dólares con una cifra decimal dividiendo los pesos entre la cotización
Interbancaria Compradora.

*Venta en DÓLARES  4)*  Si Precio "viene" en DÓLARES se utiliza
directamente aplicando para la contabilidad en PESOS la tasa de
cotización Inter Bancaria Compradora del cierre del día anterior a la
operación.

No sé si llegaste a ver los comentarios de Sergi Almacellas en el
sentido de que sería mejor hacer un módulo que contemple estos
aspectos..  Por supuesto que la tarea me queda grande hoy por hoy y no
tengo el tiempo para abordarla.  Me gusta el desafío pero no puedo
encararlo en este momento. Ya estoy más que excedido de tiempo sin
presentar resultados concretos a la Empresa.  Por esa razón intento ver
si puedo resolver con modificaciones pequeñas, por la vía de las TARIFAS.

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.

Sergi Almacellas sugiere que es mejor que ir por el lado de los
ATRIBUTOS del producto, agregar Campos y extender en el módulo de
Tarifas los campos a los que se pueda acceder...  eso creí entender al
menos. No sé. Yo agregaría campos a la tabla de productos, básicamente
MONEDA DE COMPRA y COTIZACIÓN DE COMPRA.

Los productos comprados en Moneda del Sistema tendrían por defecto (y no
modificable) el valor 1.

Los productos comprados en Segunda Moneda obligadamente deberían tener
un valor<> 0 correspondiente a la cotización de compra. (Valor <>0
porque será utilizado como divisor en la tarifa y no se puede dividir
por cero)..

Con estos dos elementos creo resolveríamos la situación de darle al
sistema el precio actualizado en *PESOS* para que recupere el valor
correcto del precio en *DÓLARES ... *y de ahí en más el proceso seguiría
sin modificaciones

TARIFA VENTA CONTADO comprados en ambas Monedas =*precio de venta* /
*cotización compra* x *cotización del día* x margen contado

Naturalmente es preciso que la TARIFA pueda recoger las dos variables de
cotización, a mi juicio una desde la ficha del producto y la otra desde
la tabla de Monedas...  O desde donde estuvieren almacenadas.

Quizás habría que prever cómo obtener estos resultados en otro tipo de
consultas de precios..

*Saludos cordiales   Enrique*

No había pensado en esa posibilidad por cuanto pensé que no era
posible que registrara los asientos contables en pesos si fijaba
dólares como moneda del sistema... Mañana lo miro un poco. Ahora me
permitiré una función de cine... Gracias Marcelo

*No* es lo que he pensado.
Si fijas `dólares` como moneda en tu instalación de Empresa, la
contabilidad de dicha Empresa se *registrará* en `dólares`.

COMPRO en Euros  (en dólares en realidad pero a los
efectos es lo mismo) y vendo también en esa divisa ...

Aún definiendo `dolares` como divisa en tu instalación de Empresa sería
posible *expresar* reportes contables en Pesos.
Eso debería resultar más simple que modificar la implementación de
facturación.
Bastaría que se mantenga una tabla de cotizaciones diaria, que permita
calcular los Pesos al momento de emitir reportes.
(en teoría alcanza con registrar el "tipo de cambio" para cada fecha en
la que existan operaciones)
Esto sería posible con independencia de la moneda/divisa en que estén
*registradas* la operaciones.
Creo que vale la pena evaluarlo.
Saludos.

El sep 28, 2017 6:50 PM, "Marcelo Zunino"

Tu no eres quien compra en euros, sinó la persona que te compra tu
producto.

Sergi,  *SÍ COMPR**O *en Euros  (en dólares en realidad pero a los
efectos es lo mismo) y vendo también en esa divisa que no es la del
sistema. De ahí la importancia de no "perder la referencia"

cuando se

calcula el precio de venta.  De otro modo, cuando voy a reponer el
Stock con pesos "flacos" ya no no puedo comprar los Euros necesarios
(dólares en mi caso) para recuperar las unidades vendidas.

Ahora termino de entender, creo. En ese caso quizá convenga evaluar si
no es conveniente fijar Dólares o Euros como moneda principal del
sistema. Si tu facturación de compra y de venta es en
Euros/Dólares sólo
vas a necesitar la divisa Pesos para expresar la contabilidad, que
también podrás registrar en Euros/Dólares. Si las disposiciones
legales
obligan a presentar los estados contables en Pesos, quizá sea más
sencillo mostrar los reportes contables en Pesos que modificar el
sistema para que resuelva la facturación a tus requerimientos.
Saludos.

.

[Pedro E.J. de León]

Post by Pedro E.J. de León
Los productos comprados en Moneda del Sistema tendrían por defecto (y
no modificable) el valor 1.

*Esto NO debe ser así.  Por cierto los precios de compras en pesos se
verían "catapultados" si se utiliza el valor 1 para cotización de
compra...  SIEMPRE SE DEBE REGISTRAR LA PARIDAD MONETARIA DEL MOMENTO DE
LA COMPRA de manera que los precios de venta mantengan, aún con
facturación en moneda local, un valor actualizado.  Siempre se pueden
introducir correcciones si en algún momento fuesen necesarias. *

Post by Pedro E.J. de León
Vamos con algunas precisiones.

COMPRO en Euros  (en dólares en realidad pero a los
efectos es lo mismo) y vendo también en esa divisa ...

Esto es así pero no  exclusivamente así. Las compras y ventas se hacen
en las dos monedas (Moneda Nacional y Dólares) y también las ventas.
Son los productos comprados en dólares, cuya reposición de stock
vuelve a requerir una compra en dólares, los que representan una
situación de riesgo desde el punto de vista de la rentabilidad.
Hoy la Empresa (en su viejo Clipper) almacena el último Precio de cada
*Venta en PESOS  1*)  Si Precio "viene" en DÓLARES hace la conversión
al cambio establecido en la Tabla MONEDAS en campo DOLAR FUTURO que se
revisa periódicamente para que esté "un pasito adelante" de la
cotización vigente en el momento de la operación con lo cual se cubren
dos objetivos: a) los pesos obtenidos de la venta permiten comprar en
el mercado los dólares necesarios a realizar la ganancia y hacer la
reposición del producto..   b) los precios en Moneda Nacional de los
productos comprados en dólares no sufren modificaciones diarias sino
periódicamente cuando se hace el ajuste del DOLAR FUTURO.
*Venta en PESOS  2)*  Si Precio "viene" en PESOS se utiliza
directamente el valor para la facturación.
*Venta en D**Ó**LARES**3)*  Si Precio "viene" en PESOS se convierte a
Dólares con una cifra decimal dividiendo los pesos entre la cotización
Interbancaria Compradora.
*Venta en DÓLARES  4)*  Si Precio "viene" en DÓLARES se utiliza
directamente aplicando para la contabilidad en PESOS la tasa de
cotización Inter Bancaria Compradora del cierre del día anterior a la
operación.
No sé si llegaste a ver los comentarios de Sergi Almacellas en el
sentido de que sería mejor hacer un módulo que contemple estos
aspectos..  Por supuesto que la tarea me queda grande hoy por hoy y no
tengo el tiempo para abordarla.  Me gusta el desafío pero no puedo
encararlo en este momento. Ya estoy más que excedido de tiempo sin
presentar resultados concretos a la Empresa.  Por esa razón intento
ver si puedo resolver con modificaciones pequeñas,  por la vía de las
TARIFAS.

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.

Sergi Almacellas sugiere que es mejor que ir por el lado de los
ATRIBUTOS del producto, agregar Campos y extender en el módulo de
Tarifas los campos a los que se pueda acceder...  eso creí entender al
menos. No sé. Yo agregaría campos a la tabla de productos, básicamente
MONEDA DE COMPRA y COTIZACIÓN DE COMPRA.
Los productos comprados en Moneda del Sistema tendrían por defecto (y
no modificable) el valor 1.
Los productos comprados en Segunda Moneda obligadamente deberían tener
un valor<> 0 correspondiente a la cotización de compra. (Valor <>0
porque será utilizado como divisor en la tarifa y no se puede dividir
por cero)..
Con estos dos elementos creo resolveríamos la situación de darle al
sistema el precio actualizado en *PESOS* para que recupere el valor
correcto del precio en *DÓLARES ... *y de ahí en más el proceso
seguiría sin modificaciones
TARIFA VENTA CONTADO comprados en ambas Monedas =*precio de venta* /
*cotización compra* x *cotización del día* x margen contado
Naturalmente es preciso que la TARIFA pueda recoger las dos variables
de cotización, a mi juicio una desde la ficha del producto y la otra
desde la tabla de Monedas...  O desde donde estuvieren almacenadas.
Quizás habría que prever cómo obtener estos resultados en otro tipo de
consultas de precios..
*Saludos cordiales   Enrique*

No había pensado en esa posibilidad por cuanto pensé que no era
posible que registrara los asientos contables en pesos si fijaba
dólares como moneda del sistema... Mañana lo miro un poco. Ahora me
permitiré una función de cine... Gracias Marcelo

*No* es lo que he pensado.
Si fijas `dólares` como moneda en tu instalación de Empresa, la
contabilidad de dicha Empresa se *registrará* en `dólares`.

COMPRO en Euros  (en dólares en realidad pero a los
efectos es lo mismo) y vendo también en esa divisa ...

Aún definiendo `dolares` como divisa en tu instalación de Empresa sería
posible *expresar* reportes contables en Pesos.
Eso debería resultar más simple que modificar la implementación de
facturación.
Bastaría que se mantenga una tabla de cotizaciones diaria, que permita
calcular los Pesos al momento de emitir reportes.
(en teoría alcanza con registrar el "tipo de cambio" para cada fecha en
la que existan operaciones)
Esto sería posible con independencia de la moneda/divisa en que estén
*registradas* la operaciones.
Creo que vale la pena evaluarlo.
Saludos.

El sep 28, 2017 6:50 PM, "Marcelo Zunino"

Tu no eres quien compra en euros, sinó la persona que te compra tu
producto.

Sergi,  *SÍ COMPR**O *en Euros  (en dólares en realidad pero a los
efectos es lo mismo) y vendo también en esa divisa que no es la del
sistema. De ahí la importancia de no "perder la referencia"

cuando se

calcula el precio de venta.  De otro modo, cuando voy a reponer el
Stock con pesos "flacos" ya no no puedo comprar los Euros necesarios
(dólares en mi caso) para recuperar las unidades vendidas.

Ahora termino de entender, creo. En ese caso quizá convenga evaluar si
no es conveniente fijar Dólares o Euros como moneda principal del
sistema. Si tu facturación de compra y de venta es en
Euros/Dólares sólo
vas a necesitar la divisa Pesos para expresar la contabilidad, que
también podrás registrar en Euros/Dólares. Si las disposiciones
legales
obligan a presentar los estados contables en Pesos, quizá sea más
sencillo mostrar los reportes contables en Pesos que modificar el
sistema para que resuelva la facturación a tus requerimientos.
Saludos.

.

[Pedro Enrique José de León Ayçaguer]

El jueves, 28 de septiembre de 2017, 9:02:15 (UTC-3), Pedro Enrique José de

*Eso no es verdad. En cada compra/venta puedes entrar el precio a mano i

este puede ser el que tu quieras. *

Acá la pregunta es: ¿el precio de la compra se ve reflejado en el campo *precio
de costo* si voy a la ficha del producto a consultarlo..?
*En el metodo de coste le puedes assignar el promedio y tryton te lo va a

calcular. Eso si... siempre en la moneda de la empresa.*

Bueno, ese es el problema. Tanto si el precio de costo es fijo como si es
promediado, al no guardarlo en la moneda de compra cuando lo reconvierta
con una cotización diferente nos devolverá un valor que no es el
original... y cuando la moneda del sistema se deprecia en relación a la
moneda de compra, las tarifas de venta arrojan valores que van reduciendo
cada vez más los márgenes de utilidad.
El miércoles, 27 de septiembre de 2017, 18:22:47 (UTC-3), Sergi Almacellas

On 27 de setembre de 2017 23.13.48 CEST, "Pedro Enrique José de León

Post by Pedro Enrique José de León Ayçaguer
Estimados: arranco de nuevo. Creo que no termino de explicarme o algo estoy
entendiendo mal. Sergi Almacellas me señala que en el módulo de Facturación
al efectuar una compra y marcar MONEDA diferente de la del sistema Tryton
hace la conversión para el apunte contable. ESO ESTÁ CLARO. Pero no es el
problema que intento compartir con Uds.
*Primero:* Tryton asume que los precios de COSTO y VENTA de los
productos están fijados en la MONEDA POR DEFECTO de la Empresa.

Eso es asi.

Post by Pedro Enrique José de León Ayçaguer
*Segundo:* Tryton necesita que le anotemos el precio de COSTO y de VENTA
de cada producto.

Eso no es verdad. En cada compra/venta puedes entrar el precio a mano i
este puede ser el que tu quieras.

Post by Pedro Enrique José de León Ayçaguer
*ESTOY TOMANDO ÉSTO COMO CIERTO por más que no es lo que pretendo. (Mi
aspiración es que guarde COSTO en la moneda de compra y el VALOR según
criterio fijado, ya sea última compra, compra más antigua o promedio.

En el metodo de coste le puedes assignar el promedio y tryton te lo va a
calcular. Eso si... siempre en la moneda de la empresa.
Y

Post by Pedro Enrique José de León Ayçaguer
que
ésto se realice de forma automática para cada compra de producto. Los
precios de VENTA a partir de allí.)

Debes extender las lineas de tarifa para poder asignar tarifas a partir
del precio de coste. Una vez tengas esto puedes usar una formula para
aplicar el margen que quieras.
Si especificas una divisa distinta en la venta, tryton te va hacer la
conversion en el momento.
Utilizando este metodo, nadie te va a arruinar. De nada ;)
Un saludo,
--
Enviado desde mi dispositivo Android con K-9 Mail. Por favor, disculpa mi brevedad.