-
Notifications
You must be signed in to change notification settings - Fork 12
Calculo dimensiones en multiples productos . #15
Comments
Esto sería una buena mejora al plugin. Cuando tenga tiempo lo puedo ver. |
Listo el pull request : #16 Por alguna razón pasados los 3 productos se pega un salto absurdo de precio, si alguien pudiera pegarle una mirada bacan. saludos |
@TCattd , hice unas modificaciones en la función que realiza el cálculo del paquete y quedó bastante mejor de lo que estaba.
Eso sería. No es lo óptimo pero con este cambio el paquete final es bastante más pequeño que el que está calculando el plugin actualmente, y la diferencia de precio es tremenda.
|
Hice algunas pruebas rápidas con productos de las mismas medidas y cumple el propósito. Gracias @albetix ojalá se apruebe el cambio |
@albetix Peso=6.8 Largo=87 Ancho=7 Alto=7 18 productos de 20x15x5 0.4 kg Peso=7.2 Largo=92 Ancho=22 Alto=17, Quizás está bien pero no me hace sentido que una dimensión se dispare siendo que se podría distribuir el total de otra manera. Revisando más en detalle el código hay lineas que me llaman la atención, las dejo con un comentario por si aportan en algo : $can_bulto = count($package['contents']); $bultos[$nro_bulto][0] = round( $bultos[$nro_bulto][0] * $values['quantity'],1 ); No sé por qué creo que haciendo un for de productos con un for de su cantidad dentro deberia arreglarse esto, qué opinan?. Atte. |
En la versión actual del plugin (no la tuya), todas las dimensiones de cada producto se están multiplicando por la cantidad, por lo que el tamaño crece en forma exponencial. $package['contents'] contiene la cantidad de productos distintos en el carro (no las unidades de cada uno de éstos), por lo que es correcto. Efectivamente en $bultos[$nro_bulto][0] = round( $bultos[$nro_bulto][0] * $values['quantity'],1 ); se está multiplicando la medida más pequeña del producto por la cantidad de unidades solicitadas. Con esto queda un paquete bastante óptimo para pocas cantidades, pero muy largo en una sola dimensión cuando son muchas. Pero es mejor de lo que está actualmente en el plugin y creo que en general aplica bien a una gran parte de las soluciones de comercio electrónico. Obviamente es mejorable, pero el cálculo actual del plugin te asesina con las tarifas. En mi caso, con varias pruebas me salía más caro el despacho que el producto. Lo que tu mencionas creo que se debe abordar en una segunda etapa, ya que la optimización del paquete puede tornarse bastante complicada, sobre todo si se pretende lograr llenar una caja de manera óptima. No lo veo tan fácil como un par de for. Saludos. |
Ya había revisado tu alternativa, pero sólo considera el cálculo con dos dimensiones y no con las tres:
Por eso preferí buscar una solución que considerara las tres. |
Me referia a la parte de mi alternativa que itera la cantidad de unidades por item. Tengo muy claro como funciona en plugin actualmente y que mi propuesta es inferior a la tuya al basarse en una funcion hecha que considera solo 2 lados. En tu codigo si en vez de multiplicar la cantidad de items de un producto por el lado mas corto haces una iteracion por la cantidad de items donde en cada pasada vuelves a ordenar por el lado mas corto debería resultar y no dispararse un lado ya que estarías recalculando en cada iteración. Corrígeme si me equivoco. Para qué esperar hasta el final para generar el paquete final si puedes meter esa iteración dentro de la otra para ir sumandole al paquete final cada item de cada producto. por cada producto del carro P.S : Estamos de acuerdo en que es mucho mejor que multiplicar los lados x la cantidad ,pero por otro lado es importante corregirlo ya que matas a 2 tipos de vendedores dejando de lado las cantidades grandes
|
Insisto en que no es tan sencillo. Puedes hacer la prueba con papel y lápiz haciendo la iteración por cada unidad del producto, considerando 10 unidades de un producto de 10 x 10 x 8 y comprobarás que ya en la 4 unidad se empiezan a producir aberraciones. Y esto empeora si haces el mismo ejercicio con tres productos distintos y entre 5 y 7 unidades de cada uno considerando aproximadamente las mismas medidas. Prefiero dar solución a un problema concreto que lleva varios días esperando un avance y que puede ayudar a muchos sitios. La solución para grandes cantidades requiere de más tiempo para poder llegar a un buen diseño conceptual. |
Definitivamente se me debe estar pasando algo por alto :
1 10x10x8
2 10x10x16
3 20x10x16
4 20x20x16
5 20x20x24
6 30x20x24
7 30x30x24
8 30x30x32
9 40x30x32
10 40x40x32
11 40x40x40
12 50x40x40
13 50x50x40
14 50x50x48
15 50x50x56
16 60x50x56
17 60x60x56
18 60x60x62
19 70x60x62
20 70x70x62
21 70x70x70
2017-07-22 19:05 GMT-04:00 Alberto Morales <notifications@github.com>:
… @llermaly <https://github.com/llermaly>,
Insisto en que no es tan sencillo. Puedes hacer la prueba con papel y
lápiz haciendo la iteración por cada unidad del producto, considerando 10
unidades de un producto de 10 x 10 x 8 y comprobarás que ya en la 4 unidad
se empiezan a producir aberraciones.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#15 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AILaUXLL944NTTlrWUhs1eN4szgeB1s-ks5sQoBCgaJpZM4OY65l>
.
|
A continuación va el desarrollo correcto con el ciclo adicional que propones: 1: 10x10x8 => 8x10x10 (reordenado de menor a mayor dimensión) Opción con la lógica que propuse en el código resulta en 1 torre de 10 unidades: Opción paquete manual: Dos torres de 5 unidades lado a lado: Conclusión: Con el ciclo que tu propones se obtiene casi 4 veces el volumen necesario. Si quieres visualizarlo de forma más espacial, puedes hacer el mismo ejercicio con 10 piezas de dominó. Es importante recordar que para el despacho lo relevante es el peso y el volumen del paquete. |
Mejoré la parte de la generación del paquete final. Estaba sumando todas dimesiones y eso estaba mal ya que para la segunda y tercera dimensión sólo debe considerar la más grande.
|
Si están de acuerdo con la última versión enviada a continuación va el código para llegar y reemplazar en el archivo.
|
A continuación va una versión más avanzada que estuve trabajando. Las mejoras que tiene respecto a la última enviada son las siguientes:
Lo estuve probando con cuatro y cinco productos. Funciona bastante bien. Este código va con todos los error_log para que puedan ver y comparar los resultados:
Si lo aprueban, le saco los error_log y lo que no debe ir, para dejarlo listo para ser publicado. |
Primero que todo, totalmente agradecido por la ayuda con esto, de verdad :) Dudas @albetix
Si puedes, comparte el método completo por favor (calculate_shipping) para publicarlo (con los cambios solicitados acá, por favor). No saques los error_log. No los saques, por favor. Tengo otra idea mejor al respecto para que convivan ahí y no molesten a los usuarios finales (no los necesitan), pero si nos ayuden a nosotros a debugear a futuro ;) Y agradecido desde ya, lógicamente. Totalmente :) Si quieres intentar hacer un PR tu mismo, te recomiendo https://desktop.github.com/ es muy sencillo de usar (facilita harto el trabajo con git en general). |
@albetix , se agradece la explicación, ya me queda más claro el tema de ir armando los montones, efectivamente aumentar el lado más corto sin más considera que siempre tenemos un cuadrado perfecto cuando no es así. Gracias. Respecto al sobredimensionado comentar que el cotizador de Chilexpress no lo considera, solo tira un aviso, por lo que da igual que un lado quede de 2 metros y los demás de centímetros, estaba dando por sentado que sí le agregaba este monto al total final. |
Sobre tus consultas:
Sobre el código, cambié los nombres de las variables y ajusté el código a las normas. Instalé Desktop GitHub pero no me deja hacer el pull request. Arroja el siguiente mensaje:
|
Gracias por aclarar las dudas, @albetix :) Para poder hacer un PR en GitHub, primero tienes que hacer un fork en tu propia cuenta de GitHub. El fork acá arriba: http://prntscr.com/fzoxm0 Si no quieres darte ese trabajo aún, puedes compartir el método acá completo, no hay problema tampoco (por ahora). ¡Gracias desde ya! |
Listo el Pull Request. |
Lanzada la versión 1.1.7 Agradecimientos totales a ambos por la ayuda en esto. En especial a @albetix que se pasó :) |
De nada. Feliz de aportar! |
Consulta, ¿cómo puedo mantener el fork de este plugin actualizado en GitHub Desktop?. No encontré ninguna opción que permita hacerlo. |
@albetix puedes hacerlo directamente desde la interfaz web de GitHub https://stackoverflow.com/a/23853061/920648 O puedes aplicar linea de comandos en tu copia local del repo fork: https://stackoverflow.com/a/7244456/920648 Ignoro si GitHub Desktop tiene algo por el estilo implementado aún o no. |
Estimados,
Probando el plugin me encontré con que al comprar multiples productos entrega costos de envío erroneos, creo porque se están sumando las dimensiones de los productos acá :
https://github.com/whooohq/whq-woocommerce-chilexpress-shipping/blob/master/classes/WC_WHQ_Chilexpress_Shipping.php
Es decir, si por ej tengo 10 productos de 20x30x40 lo normal seria terminar con una pila de 200x30x40 como minimo, sin embargo con la formula queda un total de 200x300x400 . El peso lo omito porque ese si se suma.
Habría que elaborar un algoritmo que calcule el tamaño total tratando de conseguir "lo mas cuadrado posible" ya que si se hacen pilas sumando 1 de los lados solamente se podria caer en sobredimensionado sin que necesariamente sea así :
11. ¿Qué es un envío sobredimensionado?
Es toda encomienda que no cumpla el estándar establecido por Chilexpress, ya que posee una o más de estas características:
Tiene un embalaje irregular.
Pesa más de 50 kilos.
Sobrepasa alguna de estas tres medidas: 1,2 metros (largo) x 0,8 metros (ancho) x 0,8 metros (alto).
Encontré esta librería para hacer cajas , no sé si cumple el propósito o se puede sacar algo útil :
https://github.com/yetzt/boxing/blob/master/boxing.class.php
Y esta que es más producida :
https://github.com/dvdoug/BoxPacker
No creo que sea necesario ser tan precisos pero sí que la estimación no tire envíos de $100.000+ pesos si alguien compra 10 productos chicos.
Muchos saludos, si pillo algo más específico lo posteo acá.
The text was updated successfully, but these errors were encountered: