Discussion:
[tryton-es] Producto único (no stock 1)
Gonzalo González Domínguez
2018-01-11 11:30:41 UTC
Permalink
¿Alguno ha hecho alguna implantación con producto único? Caso productos
usados.

No son productos con stock 1, sino productos que cuando vendes das de baja
exactamente un producto concreto y nunca más entrará otro igual, como si
vendieras IMEI para por un ejemplo.

Estaba valorando crear una variante por cada uno, pero me supondría que si
hago una compra de 1000 cables tendría que dar de alta 1000 variantes y
sobre todo crear 1000 lineas de compra (administración me cuelga).

Lo ideal sería usar lo de obligar a una unidad el producto y que quede la
línea de compra con 1000 unidades pero con 1000 entradas en stock
distintas, pero así no pueden ser variantes evidentemente. Luego en venta
no buscar quizás por variante sino por número de serie interno.

Orta opción sería hacer lotes, pero entonces tendría que 'bajar' toda la
informacion de precios, atributos, descripción, fotos, etc, a lotes que son
productos únicos y esto me parece cambiar 100% como funciona tryton.

No se si alguien ha planteado algún flujo similar y puede darme un tip :)
Sergi Almacellas Abellana
2018-01-11 15:39:44 UTC
Permalink
¿Alguno ha hecho alguna implantación con producto único? Caso productos
usados.
No son productos con stock 1, sino productos que cuando vendes das de
baja exactamente un producto concreto y nunca más entrará otro igual,
como si vendieras IMEI para por un ejemplo.
Entiendo que lo que necessitar es saber si has vendido uno o otro en
concreto, aunque sean unidades del mismo producto.

Para ello debes assignar un número de lote único para cada producto y
marcar los movimientos de ese producto cómo lote obligatorios. Además lo
puedes gestionar con:

https://bugs.tryton.org/issue6442
Estaba valorando crear una variante por cada uno, pero me supondría que
si hago una compra de 1000 cables tendría que dar de alta 1000 variantes
y sobre todo crear 1000 lineas de compra (administración me cuelga).
¿Que ganas con una variante para cada unidad? A parte de tener que darle
un código distinto y tener muchísima información duplicada
Lo ideal sería usar lo de obligar a una unidad el producto y que quede
la línea de compra con 1000 unidades pero con 1000 entradas en stock
distintas, pero así no pueden ser variantes evidentemente. Luego en
venta no buscar quizás por variante sino por número de serie interno.
Orta opción sería hacer lotes, pero entonces tendría que 'bajar' toda la
informacion de precios, atributos, descripción, fotos, etc, a lotes que
son productos únicos y esto me parece cambiar 100% como funciona tryton.
¿Porqué tienes que bajarlo? El lote esta relacionado con el producto,
por lo que este ya hereada todos los atributos de los productos.
--
Sergi Almacellas Abellana
www.koolpi.com
Twitter: @pokoli_srk
Gonzalo González Domínguez
2018-01-11 16:01:37 UTC
Permalink
El jueves, 11 de enero de 2018, 16:39:47 (UTC+1), Sergi Almacellas Abellana
Post by Sergi Almacellas Abellana
Post by Gonzalo González Domínguez
¿Alguno ha hecho alguna implantación con producto único? Caso productos
usados.
No son productos con stock 1, sino productos que cuando vendes das de
baja exactamente un producto concreto y nunca más entrará otro igual,
como si vendieras IMEI para por un ejemplo.
Entiendo que lo que necessitar es saber si has vendido uno o otro en
concreto, aunque sean unidades del mismo producto.
Para ello debes assignar un número de lote único para cada producto y
marcar los movimientos de ese producto cómo lote obligatorios. Además lo
https://bugs.tryton.org/issue6442
Le echo un ojo
Post by Sergi Almacellas Abellana
Post by Gonzalo González Domínguez
Estaba valorando crear una variante por cada uno, pero me supondría que
si hago una compra de 1000 cables tendría que dar de alta 1000 variantes
y sobre todo crear 1000 lineas de compra (administración me cuelga).
¿Que ganas con una variante para cada unidad? A parte de tener que darle
un código distinto y tener muchísima información duplicada
Efectivamente, de ahí la pregunta, me parece muy 'sucio' y enrevesado. Eso
si, aquí no tnemos catálogo, el catalogo se crea de contínuo cuando alguien
entra con la puerta y nos vende un producto que nunca hemos tenido.
Post by Sergi Almacellas Abellana
Post by Gonzalo González Domínguez
Lo ideal sería usar lo de obligar a una unidad el producto y que quede
la línea de compra con 1000 unidades pero con 1000 entradas en stock
distintas, pero así no pueden ser variantes evidentemente. Luego en
venta no buscar quizás por variante sino por número de serie interno.
Orta opción sería hacer lotes, pero entonces tendría que 'bajar' toda la
informacion de precios, atributos, descripción, fotos, etc, a lotes que
son productos únicos y esto me parece cambiar 100% como funciona tryton.
¿Porqué tienes que bajarlo? El lote esta relacionado con el producto,
por lo que este ya hereada todos los atributos de los productos.
No, porque cada lote (con este flujo) tendría su precio propio de venta y
coste, sus fotos, su descripción, sus atributos ....* es el producto en si*,
por eso matizo que no es mover stock 1 de producto/variante, sino que si
manejamos lotes se necesita tener todos los atributos, su propio coste(esto
vendría de la compra), precio de venta, fotos, anotaciones, etc

Dicho de otra forma, para ver si queda más claro, en mi caso los
productos/variantes serían meras plantillas para preconfigurar y crear
lotes (si usamos esta idea) que necesitarían llevar toda la información y
ser el item concreto que se vende, no movería stock de variantes como hace
por defecto en tryton, se conprarían y venderían eose lote de 1 producto.
En cada* línea de compra *me tiene que especificar el comprador nombre de
producto, la descripción y configurarme los atributos como si una variante
fuese y poner* precio de compra y de venta* especifico por lote (por eso
pensaba reusar variante), y luego en almacen se sacan fotos, se testea
(informe de verificación) y se ubica, en venta me tienen que salir los
datos del* lote/línea de compra, no de producto* y variante, por eso digo
que no es el proceso estandar tryton. Afectaría también a como se
calcularía el iva en venta, pero esa es otra historia.

Probablemente se me escapen muchas cosas, no conozco las interioridades de
tryton y quizás sea más sencillo de lo que parece, pero estoy perdido ahora
mismo.
Post by Sergi Almacellas Abellana
--
Sergi Almacellas Abellana
www.koolpi.com
Sergi Almacellas Abellana
2018-01-11 16:31:24 UTC
Permalink
Orta opción sería hacer lotes, pero entonces tendría que 'bajar' toda la
informacion de precios, atributos, descripción, fotos, etc, a
lotes que
son productos únicos y esto me parece cambiar 100% como funciona
tryton.
¿Porqué tienes que bajarlo? El lote esta relacionado con el producto,
por lo que este ya hereada todos los atributos de los productos.
No, porque cada lote (con este flujo) tendría su precio propio de venta
y coste, sus fotos, su descripción, sus atributos ....
Vamos por partes:

- Precio de coste: Este serà el precio unitario del movimiento de
entrada de este producto en el almacen. Si lo necessitas lo puedes
mostrar en el lote como campo funcional, però no tienes porqué necesitarlo.
- Precio de venta: No nos has explicado como calculáis los precios de
venta en vuestro negocio por lo que no puedo opiniar. Si es un margen
sobre el precio de coste, puedes añadir otro funcional y que te lo
calcule el sistema.
- Sus fotos: Las puedes añadir como adjuntos del propio lote
- La descripción: Puedes usar las notas.

Los attributos, pues depende de lo que guardes en atributos. Pero si
pueden variar para cada unidad, evidentmente lo tienes que guardar en el
lote.

*es el producto en
si*, por eso matizo que no es mover stock 1 de producto/variante, sino
que si manejamos lotes se necesita tener todos los atributos, su propio
coste(esto vendría de la compra), precio de venta, fotos, anotaciones, etc
Has repetido lo mismo de antes :P
Dicho de otra forma, para ver si queda más claro, en mi caso los
productos/variantes serían meras plantillas para preconfigurar  y crear
lotes (si usamos esta idea) que necesitarían llevar toda la información
y ser el item concreto que se vende, no movería stock de variantes como
hace por defecto en tryton, se conprarían y venderían eose lote de 1
producto. En cada*línea de compra *me tiene que especificar el comprador
nombre de producto, la descripción y configurarme los atributos como si
una variante fuese y poner*precio de compra y de venta* especifico por
lote (por eso pensaba reusar variante), y luego en almacen se sacan
fotos, se testea (informe de verificación) y se ubica, en venta me
tienen que salir los datos del*lote/línea de compra, no de producto* y
variante, por eso digo que no es el proceso estandar tryton.
Igual te vale la hacer te unas vistas personalizadas para "Comprar
Lotes" y "Vender Lotes".

Seguramente ganaras marcando como inactivo un lote una vez lo hayas
vendido. Así te "desaparecerà del sistema".


Afectaría
también a como se calcularía el iva en venta, pero esa es otra historia.
El iva en venta se pone a traves del campo precio unitario. Si guardas
el precio en el lote seria questión de poner el precio de ese lote en
concreto en la linea de venta y ya lo tienes.
--
Sergi Almacellas Abellana
www.koolpi.com
Twitter: @pokoli_srk
Gonzalo
2018-01-11 16:49:30 UTC
Permalink
El jue., 11 ene. 2018 a las 17:31, Sergi Almacellas Abellana (<
Post by Gonzalo González Domínguez
Orta opción sería hacer lotes, pero entonces tendría que 'bajar'
toda la
Post by Gonzalo González Domínguez
informacion de precios, atributos, descripción, fotos, etc, a
lotes que
Post by Gonzalo González Domínguez
son productos únicos y esto me parece cambiar 100% como funciona
tryton.
¿Porqué tienes que bajarlo? El lote esta relacionado con el producto,
por lo que este ya hereada todos los atributos de los productos.
No, porque cada lote (con este flujo) tendría su precio propio de venta
y coste, sus fotos, su descripción, sus atributos ....
- Precio de coste: Este serà el precio unitario del movimiento de
entrada de este producto en el almacen. Si lo necessitas lo puedes
mostrar en el lote como campo funcional, però no tienes porqué necesitarlo.
Si lo necesito, por ser el negocio que es. A nosotros relamente los datos
de coste de producto y variante nos sirven de cero (son meras plantillas,
de hecho nos sobraría el nivel variante incluso) si usamos lotes, nos
interesan uno a uno los datos de cada movimiento de producto único, si
englobamos esto en lotes me interesa todo en lotes, sea funcional o
guardado. No había caído en sacarlo funcional, pero en listados no dará
mucha tralla al sistema?

- Precio de venta: No nos has explicado como calculáis los precios de
venta en vuestro negocio por lo que no puedo opiniar. Si es un margen
sobre el precio de coste, puedes añadir otro funcional y que te lo
calcule el sistema.
Lo pone el comprador, por eso tiene que ir en el mismo lote, ya que depende
del estado del producto, es el comprador el que valora cuanto se paga por
el tanto en compra como en venta.
- Sus fotos: Las puedes añadir como adjuntos del propio lote
Compro

- La descripción: Puedes usar las notas.
Idem
Los attributos, pues depende de lo que guardes en atributos. Pero si
pueden variar para cada unidad, evidentmente lo tienes que guardar en el
lote.
Exacto, por ejemplo un caso visual es cargador de móvil, según como te lo
vendan puede ser si o no, o venir con caja e intrucciones o no, o ser de X
proveedor de telefonía, por eso digo que son plantillas puras, en compra me
tienen que decir que estado están las cosas y si las trae.
*es el producto en
Post by Gonzalo González Domínguez
si*, por eso matizo que no es mover stock 1 de producto/variante, sino
que si manejamos lotes se necesita tener todos los atributos, su propio
coste(esto vendría de la compra), precio de venta, fotos, anotaciones,
etc
Has repetido lo mismo de antes :P
Se me fue :P
Post by Gonzalo González Domínguez
Dicho de otra forma, para ver si queda más claro, en mi caso los
productos/variantes serían meras plantillas para preconfigurar y crear
lotes (si usamos esta idea) que necesitarían llevar toda la información
y ser el item concreto que se vende, no movería stock de variantes como
hace por defecto en tryton, se conprarían y venderían eose lote de 1
producto. En cada*línea de compra *me tiene que especificar el comprador
nombre de producto, la descripción y configurarme los atributos como si
una variante fuese y poner*precio de compra y de venta* especifico por
lote (por eso pensaba reusar variante), y luego en almacen se sacan
fotos, se testea (informe de verificación) y se ubica, en venta me
tienen que salir los datos del*lote/línea de compra, no de producto* y
variante, por eso digo que no es el proceso estandar tryton.
Igual te vale la hacer te unas vistas personalizadas para "Comprar
Lotes" y "Vender Lotes".
Comprado también :)
Seguramente ganaras marcando como inactivo un lote una vez lo hayas
vendido. Así te "desaparecerà del sistema".
Perfecto
Afectaría
Post by Gonzalo González Domínguez
también a como se calcularía el iva en venta, pero esa es otra historia.
El iva en venta se pone a traves del campo precio unitario. Si guardas
el precio en el lote seria questión de poner el precio de ese lote en
concreto en la linea de venta y ya lo tienes.
Lo del iva viene a que si es prodcuto usado, en venta se calcula sobre
beneficio no sobre neto, pero como decía, esa es otra batalla ;)
--
Sergi Almacellas Abellana
www.koolpi.com
Sergi Almacellas Abellana
2018-01-11 16:59:36 UTC
Permalink
Post by Gonzalo
El jue., 11 ene. 2018 a las 17:31, Sergi Almacellas Abellana
     Orta opción sería hacer lotes, pero entonces tendría que 'bajar'
     toda la
     > informacion de precios, atributos, descripción, fotos, etc, a
     lotes que
     > son productos únicos y esto me parece cambiar 100% como funciona
     tryton.
     ¿Porqué tienes que bajarlo? El lote esta relacionado con el
producto,
     por lo que este ya hereada todos los atributos de los productos.
No, porque cada lote (con este flujo) tendría su precio propio de
venta
y coste, sus fotos, su descripción, sus atributos ....
- Precio de coste: Este serà el precio unitario del movimiento de
entrada de este producto en el almacen. Si lo necessitas lo puedes
mostrar en el lote como campo funcional, però no tienes porqué necesitarlo.
Si lo necesito, por ser el negocio que es. A nosotros relamente los
datos de coste de producto y variante nos sirven de cero (son meras
plantillas, de hecho nos sobraría el nivel variante incluso) si usamos
lotes, nos interesan uno a uno los datos de cada movimiento de producto
único, si englobamos esto en lotes me interesa todo en lotes, sea
funcional o guardado.
De hecho, creo que se debatio en algun lugar de hacer los campos
cost_price y list_price del producto opcionales. Supongo que esto te
ayudaría a esconder-los de las vistas.

No había caído en sacarlo funcional, pero en
Post by Gonzalo
listados no dará mucha tralla al sistema?
Si lo haces bien: NO Si lo haces mal es possible que te tarde en cargar
los listados.
Post by Gonzalo
- Precio de venta: No nos has explicado como calculáis los precios de
venta en vuestro negocio por lo que  no puedo opiniar. Si es un margen
sobre el precio de coste, puedes añadir otro funcional y que te lo
calcule el sistema.
Lo pone el comprador, por eso tiene que ir en el mismo lote, ya que
depende del estado del producto, es el comprador el que valora cuanto se
paga por el tanto en compra como en venta.
 
Entonces lo debes guardar-lo, no hay mas opciones.
Post by Gonzalo
- Sus fotos: Las puedes añadir como adjuntos del propio lote
Compro
- La descripción: Puedes usar las notas.
Idem 
Los attributos, pues depende de lo que guardes en atributos. Pero si
pueden variar para cada unidad, evidentmente lo tienes que guardar en el
lote.
Exacto, por ejemplo un caso visual es cargador de móvil, según como te
lo vendan puede ser si o no, o venir con caja e intrucciones o no, o ser
de X proveedor de telefonía, por eso digo que son plantillas puras, en
compra me tienen que decir que estado están las cosas y si las trae.
Siempre lo puedes poner en la descripción. Si hay tantas opciones
distintas de attributos, realmente vale la pena parametrizar-lo?
--
Sergi Almacellas Abellana
www.koolpi.com
Twitter: @pokoli_srk
Gonzalo
2018-01-11 17:04:15 UTC
Permalink
El jue., 11 ene. 2018 a las 17:59, Sergi Almacellas Abellana (<
Post by Gonzalo González Domínguez
Post by Gonzalo
El jue., 11 ene. 2018 a las 17:31, Sergi Almacellas Abellana
Post by Gonzalo González Domínguez
Orta opción sería hacer lotes, pero entonces tendría que
'bajar'
Post by Gonzalo
Post by Gonzalo González Domínguez
toda la
Post by Gonzalo González Domínguez
informacion de precios, atributos, descripción, fotos, etc, a
lotes que
Post by Gonzalo González Domínguez
son productos únicos y esto me parece cambiar 100% como
funciona
Post by Gonzalo
Post by Gonzalo González Domínguez
tryton.
¿Porqué tienes que bajarlo? El lote esta relacionado con el
producto,
Post by Gonzalo González Domínguez
por lo que este ya hereada todos los atributos de los
productos.
Post by Gonzalo
Post by Gonzalo González Domínguez
No, porque cada lote (con este flujo) tendría su precio propio de
venta
Post by Gonzalo González Domínguez
y coste, sus fotos, su descripción, sus atributos ....
- Precio de coste: Este serà el precio unitario del movimiento de
entrada de este producto en el almacen. Si lo necessitas lo puedes
mostrar en el lote como campo funcional, però no tienes porqué
necesitarlo.
Si lo necesito, por ser el negocio que es. A nosotros relamente los
datos de coste de producto y variante nos sirven de cero (son meras
plantillas, de hecho nos sobraría el nivel variante incluso) si usamos
lotes, nos interesan uno a uno los datos de cada movimiento de producto
único, si englobamos esto en lotes me interesa todo en lotes, sea
funcional o guardado.
De hecho, creo que se debatio en algun lugar de hacer los campos
cost_price y list_price del producto opcionales. Supongo que esto te
ayudaría a esconder-los de las vistas.
En nuestro caso pueden valer para poner el precio por ejemplo que se
pagaría y vendería si fuese 'como nuevo', vamos, otra guía.
Post by Gonzalo González Domínguez
No había caído en sacarlo funcional, pero en
Post by Gonzalo
listados no dará mucha tralla al sistema?
Si lo haces bien: NO Si lo haces mal es possible que te tarde en cargar
los listados.
Cojo la indirecta :P
Post by Gonzalo González Domínguez
Post by Gonzalo
- Precio de venta: No nos has explicado como calculáis los precios de
venta en vuestro negocio por lo que no puedo opiniar. Si es un
margen
Post by Gonzalo
sobre el precio de coste, puedes añadir otro funcional y que te lo
calcule el sistema.
Lo pone el comprador, por eso tiene que ir en el mismo lote, ya que
depende del estado del producto, es el comprador el que valora cuanto se
paga por el tanto en compra como en venta.
Entonces lo debes guardar-lo, no hay mas opciones.
Ok
Post by Gonzalo González Domínguez
Post by Gonzalo
- Sus fotos: Las puedes añadir como adjuntos del propio lote
Compro
- La descripción: Puedes usar las notas.
Idem
Los attributos, pues depende de lo que guardes en atributos. Pero si
pueden variar para cada unidad, evidentmente lo tienes que guardar
en el
Post by Gonzalo
lote.
Exacto, por ejemplo un caso visual es cargador de móvil, según como te
lo vendan puede ser si o no, o venir con caja e intrucciones o no, o ser
de X proveedor de telefonía, por eso digo que son plantillas puras, en
compra me tienen que decir que estado están las cosas y si las trae.
Siempre lo puedes poner en la descripción. Si hay tantas opciones
distintas de attributos, realmente vale la pena parametrizar-lo?
Si porque eso es justo lo que dice que se paga, no se paga lo mismo
teniendo caja que no teniendola por ejemplo. Los atributos en nuestro caso
son como fichas para que el comrpador rellene, y valore precio, además
sirven luego para ver si se estravió un cargador, necesitas saber si venía
o no. La clave está aquí.
Post by Gonzalo González Domínguez
--
Sergi Almacellas Abellana
www.koolpi.com
Loading...