Ir al contenido principal

Ubercart, atributos o CCK ?

El uso de atributos y clases para categorizar los productos de la tienda puede resolver en muchas situaciones y está muy bien pensado. Pero como no todo es perfecto acabo de chocar con una de esas situaciones que parece ser la excepción de la regla y donde he tenido que sacrificar los atributos de Ubercart por los conocidos y siempre bienvenidos campos de CCK.
La idea inicial era facilitar al vendedor que subiera un solo producto, con su modelo y precio básico, y que luego los clientes pudieran seleccionar los atributos requeridos. La cuestión se complicó porque los cinco (5) atributos asociados a la clase de producto X están muy poblados. Cuando intenté crear los números SKU únicos para cada combinación posible el servidor de la base  colapsó y es que no me había percatado de que las posibles combinaciones ascendían a más de 10 millones!!
Evidentemente no hay forma humana de controlar esto, y además no resulta una solución real, puesto que evidentemente, el proveedor nunca tendrá en stock las 10 millones de opciones posibles de ese producto. En este caso, es más conveniente usar los campos de CCK dentro del tipo de contenido del producto X y que el proveedor suba al sitio los productos que tiene. Dejar solamente para los atributos quizás un solo campo, me imagino que el que más varíe, pienso por ejemplo, en el siempre recurrido ejemplo de las camisetas, dejar el atributo color o talla, y eso reduciría muchísimo las posibles combinaciones.
Concluyo, hasta que me demuestre lo contrario, que en el caso de que los atributos sean muy numerosos, es mejor usar CCK. La comparación la estoy estableciendo entre la cantidad de combinaciones posibles que puedan generar el uso de los atributos, que obligaría al vendedor a contabilizar el stock de esa cantidad, y por otra parte la cantidad de productos que el vendedor tuviese que ingresar al sitio en caso de que usara CCK.
Poniendo un ejemplo hipotetico, si se venden camisetas con 3 tallas y 3 colores posibles, se usarían los atributos de UC y tenemos 9 combinaciones. Así que el vendedor sube solamente 1 producto y actualiza el stock de 9 SKU posibles. Por otro lado suponiendo que un producto, por ejemplo zapatos, tengamos 12 posibles tallas y 15 colores posibles, eso nos generaría 180 (12x15) combinaciones. si además por ejemplo, dieramos la opción de que ese modelo tenga cordones o no, se duplicaría a 360!!! No creo que nadie que tenga una tienda de zapatos tenga las 360 variantes de un modelo de una marca en específico!! Si acaso tendrá quizás 5 tallas de 2 colores cada una y entonces seria más conveniente usar fields de CCK y que el vendedor entre 10 productos diferentes. La otra opción sería dejar para los atributos uno de los campos, por ejemplo, los colores y que el vendedor entre solamente un producto por cada talla.
Por supuesto, es sólo mi teoría... cualquier otra opinión o experiencia será bienvenida.



Publicar un comentario

Entradas populares de este blog

Condicionar el destinatario de email en Webform, Drupal

A pesar de que Drupal cuenta en su núcleo con el módulo 'Contact' para generar un formulario de contacto por defecto, lamentablemente no es todo lo flexible que quisiéramos, espero que en el futuro se maneje como una entidad a la cual le podamos agregar campos. Por eso, algunas veces tenemos que recurrir a Webform cuando necesitamos un formulario de contacto personalizado. Como crear un formulario con el módulo Webform no es el asunto de esta entrada y existe bastante documentación. Lo que haremos será condicionar el correo electrónico de destino según el valor de un componente del formulario. Por ejemplo, el sitio web corporativo de una empresa X que en su formulario de contacto se le ha agregado una lista desplegable con diferentes temáticas: facturación, asistencia técnica, otros temas. Cuando se agrega un componente 'select options' en un webform es necesario para cada opción, agregar un par 'llave|valor', y usualmente le asignamos un valor entero o algún …

Drupal Commerce - producto con varios precios

Montando un marketplace con Drupal Commerce, apareció un caso de uso donde el cliente quería agregar a cada producto un precio de envío diferente. Por tanto no valía una Flate Rate u alguna solución clásica de 'shipping', así que pensé que Rules y encontré esta simple solución de Josh Miller:
La idea es agregar un campo 'envío' tipo 'price' al tipo de producto en cuestión, y luego con rules, sumar al precio del producto, el precio del envío.
Crear una nueva regla de cálculo de precio. Ir a admin/commerce/config/product-pricing/rules/add y darle un nombreAgregamos una primera condición "Entity has field" a la entidad "commerce-line-item" y seleccione el campo "commerce_product". Con este paso se carga el producto para la siguiente inspección.Segunda condición, cargamos el campo con el precio: "Entity has field" a la entidad "commerce-line-item:commerce-product" y seleccionamos el campo creado previamente en el ti…