El jue., 11 ene. 2018 a las 17:59, Sergi Almacellas Abellana (< se...@koolpi.com>) escribió:
> El 11/01/18 a les 17:49, Gonzalo ha escrit: > > > > > > El jue., 11 ene. 2018 a las 17:31, Sergi Almacellas Abellana > > (<se...@koolpi.com <mailto:se...@koolpi.com>>) escribió: > > > > El 11/01/18 a les 17:01, Gonzalo González Domínguez ha escrit: > > > 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. > > > > > > 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. > No había caído en sacarlo funcional, pero en > > 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 > > > - 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. > Ok > > > - 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? > 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í. > > > > -- > Sergi Almacellas Abellana > www.koolpi.com > Twitter: @pokoli_srk >
