FERMB

Espero que en este tiempo ya hayas encontrado la solución pero por si no ha sido así, te cuento que no puedes dar precios distintos para estados diferentes de un mismo pais, pero si puedes recuperarlo con los gastos de envío, poniendo las provincias de Canarias, Ceuta y Melilla, con su regla de impuestos correspondiente, que sería sin iva y en una zona geográfica diferente al resto de la peninsula, para la que creas un transportista específico con otros precios (donde recuperas lo que quieres incluirle a canarias).

Esto a mi me sucede en una tienda prestashop 1.5.6, creada hace años. Lo que sucede en esa versión (y creo que tambien en ps1.6) es que los precios específicos se aplican directamente sobre el precio final del producto (con IVA), yo quisiera saber que archivo es el que controla esa conversión de precios, para decirle que lo aplique sobre el precio inicial sin impuestos, por que... El problema grave, con los precios específicos, está al configurar los envíos a Canarias y paises Europeos, donde los productos se cobran sin iva. En mi caso la tienda muestra siempre los precios de los productos sin IVA, ya sea para Europa, Canarias o resto de España. El precio que muestra la ficha es el mismo antes de registrase como cliente o cuando te identificas como cliente de España (no canarias). Pero... si me registro con una dirección de envío a Canarias o un pais europeo donde no hay que cobrar el iva, o incluso si me identifico con dirección de la Península, pero cambio el envío a Canarias, el precio me cambia por esa forma de aplicarse el precio específico. Por ejemplo: Producto que vale 15€ sin iva es decir 18.15 con el 21% de iva. Si lo pongo en rebajas con un precio específico para que reduzca un importe de 10.89€, prestashop hace el siguiente calculo (PS1.5.6 no tiene opción de indicar si el descuento es con o sin iva): Toma el precio final 18.15 y le quita el precio específico: 18.15-10.89= 7.26€ como la tienda muestra el precio sin iva lo que vemos en la ficha del producto es 6.00€ (que es 7.26 sin iva 7.26/1.21=6) Pero al registrarse o cambiar la dirección de envío a canarias o paises europeos, el precio final del producto ya no es 18.15 sino 15 por que esas zonas van sin iva por lo que el descuento que aplica es mayor porque precio específico lo calcula así: Toma el precio final 15 y le quita el precio específico: 15-10.89=4.11euros. como el precio que muestra la tienda es sin iva, pues muestra esos 4.11 que ya son sin iva. Creo que el descuento por importe en los precios específicos, debería aplicarse siempre sobre el precio sin impuesto, en mi caso así se vería siempre el mismo precio y luego aplicar los impuestos que correspondan o no, según zona de envío. He revisado ya varios archivos en controllers, tanto admin como front, classes/product.php, y tools que hacen el convert_price pero no consigo dar con el que gestiona esa reducción de precio, para hacer que el descuento (specific_price) lo aplique siempre sobre el precio sin iva (lo que solucionaría mi problema y todos los que he leido que hay con los precios espcíficos). Por favor, alguna sugerencia?

Nadie, se le ocurre que puede suceder?. Aun sigo con el problema por que no veo que pasa

Simple, pero efectivo. Gracias

It´s a problem if you load de fontawesome in prestashop, but not if you load fontawesome out link. You can replace in the css "icon-" to "fa fa-", and into all the archives .tpl and include <link href="//netdna.bootstrapcdn.com/font-awesome/4.0.3/css/font-awesome.css" rel="stylesheet"/> into yhe head of header.tpl. All it´s ok. jajajaja, it´s all lof of changes. I hope Prestashop resolve this problem with fontawesome when open, edit and save the global.css

Hola a todos. Os transmito mi desesperación por este error que no logro comprender. Se trata de una tienda prestashop 1.5.6.1 en la que no funciona correctamente el listado de pedidos. Accedo a la pestaña de pedidos y en principio muestra todo correctamente. Hay más de los 50 pedidos que por defecto muestra, e indica una paginación acorde con el numero de pedidos totales 1/3. Pero cuando hago cualquier accion, ya sea pasar página o cambiar el numero a mostrar de 50 a cualquier otro del desplegable, me da resultados cero, en el caso de pasara pagina con un extraño 2/1 en la paginación en lugar de 2/3 y no muestra ningun resultado. Si vuelvo a la pagina 1, la paginación indica ahora 1/1 (en lugar de 1/3) y sigue sin mostrar pedidos... hasta que pulso en el botón "borrar filtro" que entonces todo vuelve a la normalidad de la primera pagina 1/3 y vuelta a empezar, si hago cualquier accion. Ahora en esa tienda hay 130 y pico pedidos y para verlos todos hay que cambiar el numero de resultados a 300, me sale pantalla de pedidos con cero resultados, pulso "borrar filtros" y ya muestra todos los pedidos, pero cuando tenga más de 300 si quisiera ver los primeros?? no se podrá ni con ese apaño. El caso es que este sistema de paginación funciona correctamente en productos, clientes, etc... solo falla en pedidos, que salvo eso de que cambia la paginación de 1/3 a 2/1, es como si añadiera algun filtro al listado. NO he visto nada raro en las tablas orders de la BBDD, he reemplazado archivos de prestashop por los originales de la instalación por si se hubieran corrompido, he revisado php, he rezado, cruzado dedos, .... he activado el debug de errores pero no muestra ninguno y por supuesto algo se me está pasando de algun archivo php o bbdd, quizá de javascript (o a lo mejor he cruzado mal los dedos), por lo que ahora me encomiendo a la ayuda del foro por si a alguien se le ocurre una sugerencia o sabe que puede suceder. Un saludo y gracias por vuestras aportaciones a este tema.

No dices la versión de prestashop usas en tu tienda. Ya apunté, que si usas presathop 1.5 o 1.4, la solución más rápida sin mareos de correciones en la progamación es el módulo que ofrece juferlover en https://www.prestash...nado/?p=2194173 a mi me han funcionado en ps1.5.6 con certificado de comodo, activado en toda la web. Otra cosa sería que el certificado que tienes, estuviera mal configurado o no fuera válido. Que no tengas puesto nada en la configuración desde el admintpv de las URL KO y OK, no influye para nada. Si es ps1.6 entonces, el módulo anterior no te vale y hay que seguir investigando, yo me decantaría por la configuración del certificado. Has probado a deshabilitar SSL y hacer pago con el tpv?

Según redsys el modulo que ellos facilitan es compatible desde la 1.5, sin distinción de versión, pero... con ssl a mi no me ha funcionado bien y aunque menores, eran muchas las modificaciones que he tenido que ir haciendo para resolver cada error que surgía al arreglar el anterior. La saolución más rápida y comprobado que funciona en prestahop 1.5.6 con ssl activado en toda la tienda es el módulo que ofrece juferlover de forma gratuita, en este mismo foro https://www.prestashop.com/forums/topic/476640-módulo-pago-servired-v151-con-firma-sha-256-solucionado/?p=2194173 Es el antiguo módulo servired 1.5, pero adpatado para que funcione con SHA256. Hablamos siempre de que está instalada en el servidor la libreria mcrypt, que activamos la opcion en el backoffice de prestashop forzar compilación y desactivar cache en el rendimiento de prestashop (despues se vuelve a dejar como estaba). Y funciona, por mi propia experiencia puedo decir que funciona (PS1.5.6).

Yo si tengo ssl en un prestashop 1.5.5.6, como he escrito en la anterior entrada. Es prestashop, puedes darme alguna sugerencia, quizá la url ok debe apuntar al modulo de redsys/validation.php directamente con https, en lugar de a order-confirmation.php como se hacía antes??. Si es que... mira que dejarlo todo para los útlimos días!!. Alguna idea??

A mi sucede lo mismo en un prestashop 1.5.5.6 y si tengo ssl, es decir https activado en toda la tienda. He configurado el modulo de redsys 2.8.3 y modificado en el admintpv Parámetros en las URLs: SI, como dicen en su manual y hace el cobro pero no vacia el carrito, ni registra el pedido. He cambiado las url ok y url ko pero con protocolo https y vuelve a hacer lo mismo, cobra, perono vacia el carrito. así que he dejado las url ko y ok como lasy he forzado para que validation.php no haga el https, cambiandolo en redsys.php //URL de Respuesta Online if (empty($_SERVER['HTTPS'])) { $urltienda = $protocolo.$_SERVER['HTTP_HOST'].__PS_BASE_URI__.'modules/redsys/validation.php'; } else { */ $urltienda = $protocolo.$_SERVER['HTTP_HOST'].__PS_BASE_URI__.'modules/redsys/validation.php'; } y volia!! ahora tras hacer la compra, vacia el carrito y redirecciona a la pagina de ok, pago correcto, pero... AGGGG!!! no coge el precio correcto y dice que hay un error de pago, ya que cobra lo que debe cobrar, pero devuelve a prestahop un pedido de 0,00€ por lo que el estado del pedido es error de pago (por haber pagado de más) y al cliente le llega el mail de error de pago pongase en contacto con la tienda... lo cual es un problema por que el cliente ha pagado lo correcto pero el modulo no devuleve a prestashop el registro bien. Así que toca seguir tocando código, salvo que alguien tenga una sugerencia de por qué sucede esto con el ssl. ya que por lo que dice casi todo el mundo el modulo oficial de redsys estaba funcionando ok. Se acepta cualquier idea.

Tras instalar la libreria mcrypt que faltaba en el servidor vps, forzar compilación y desactivar cache en el rendimiento de prestashop (despues se vuelve a dejar como estaba) y borrar los archivos de la carpeta tools/smarty/compile (todo menos el archivo index.php) está comprobado que en la versión prestashop 1.4.4.1 también funciona este modulo de juferlover. Muchas gracias por el aporte.

Bien Ventura. gracias por el código, pero no sé porqué me repetia varias veces el listado de productos de un unico pedido, pero a partir de él, pude hacer este codígo con lo que necesitaba, así que gracias por el aporte. Con este código, con encabezados en español, muestra todos los artículos de cada pedido, unidades compradas, stock restante, fecha, nombre de cliente, direcciones de envio y facturación, mail de cliente, etc... y ordenando los pedidos para ver los últimos en primer lugar. SELECT d.id_order, os.name AS estado, o.date_upd AS fecha, d.product_name AS producto, d.product_reference AS ref_ReleMat, d.product_supplier_reference AS ref_proveedor, d.product_quantity AS uds, d.product_price, s.quantity AS en_stock, o.payment, CONCAT_WS( ' ', g.firstname, g.lastname ) AS cliente, CONCAT_WS(' ', ad.address1, ad.address2, ad.postcode, ad.city, ad.other, ad.phone, ad.phone_mobile) AS envio, CONCAT_WS(' ', ai.address1, ai.address2, ai.postcode, ai.city, ai.other, ai.phone, ai.phone_mobile) AS facturacion, g.email, gl.name AS grupo FROM ps_order_detail d LEFT JOIN ps_orders o ON ( d.id_order = o.id_order ) LEFT JOIN ps_customer g ON ( o.id_customer = g.id_customer ) LEFT JOIN ps_stock_available s ON (d.product_id = s.id_product) LEFT JOIN ps_address ad ON (o.id_address_delivery = ad.id_address) LEFT JOIN ps_address ai ON (o.id_address_invoice = ai.id_address) LEFT JOIN ps_group_lang gl ON ( g.id_default_group = gl.id_group ) LEFT JOIN ps_order_state_lang os ON ( o.current_state = os.id_order_state ) WHERE os.id_lang =1 GROUP BY d.id_order, d.product_name ORDER BY d.id_order DESC Espero que alguien más le de utilidad, para mejorar/completar la exportación de datos de los pedidos que recuerdo a todos se puede hacer también desde el listado de pedidos del backoffice, con el botón superior derecha que exporta a excel (aunque sólo los datos que muestra el listado de pedidos)

Thanks for your post Beluga. I use it to write a similar sql, in spanish and group only by d.id_order. In this form don´t duplicate and don´t erase any product. if you need to see all the products and all the orders, you can get it with a code like this: SELECT d.id_order, os.name AS estado, o.date_upd AS fecha, d.product_name AS producto, d.product_reference AS ref_ReleMat, d.product_supplier_reference AS ref_proveedor, d.product_quantity AS uds, d.product_price, s.quantity AS en_stock, o.payment, CONCAT_WS( ' ', g.firstname, g.lastname ) AS cliente, CONCAT_WS(' ', ad.address1, ad.address2, ad.postcode, ad.city, ad.other, ad.phone, ad.phone_mobile) AS envio, CONCAT_WS(' ', ai.address1, ai.address2, ai.postcode, ai.city, ai.other, ai.phone, ai.phone_mobile) AS facturacion, g.email, gl.name AS grupo FROM ps_order_detail d LEFT JOIN ps_orders o ON ( d.id_order = o.id_order ) LEFT JOIN ps_customer g ON ( o.id_customer = g.id_customer ) LEFT JOIN ps_stock_available s ON (d.product_id = s.id_product) LEFT JOIN ps_address ad ON (o.id_address_delivery = ad.id_address) LEFT JOIN ps_address ai ON (o.id_address_invoice = ai.id_address) LEFT JOIN ps_group_lang gl ON ( g.id_default_group = gl.id_group ) LEFT JOIN ps_order_state_lang os ON ( o.current_state = os.id_order_state ) WHERE os.id_lang =1 GROUP BY d.id_order, d.product_name ORDER BY d.id_order DESC I use it in PS1.5 and it´s ok.

Muchas gracias por el ofrecimiento pero finalmente está solucionado hace tiempo. No sólo hicimos que se ordenara alfabéticamente, sino que previamente se seleccionará el atributo, para que mostrara sólo los valores dentro de ese atributo y así reducir el listado tan amplio de combinaciones que requería la tienda No puedo dar más detalles sobre la solución, pues la conseguí hace tiempo. Tendría que revisar esa tienda que hicimos para recordar lo que tocamos y en qué archivos. Gracias de todos modos.

En alguna tienda, seguro que teneis instalado modulo de paypal con recargo, que pasa con ese modulo?, por que supongo que este modulo de paypal 3.8 al que obligan actualizar no lleva configuración para aplicar recargo al cliente, verdad?. Segun, las indicaciones para corregir el codigo del modulo paypal (sin necesidad de actualizarlo), hay que cambiar unas lineas en modules/paypal/api en el archivo paypal_connect.php En este fichero buscaremos la línea con este código: @curl_setopt($ch, CURLOPT_SSLVERSION, 3); Y la borraremos. A continuación reemplazaremos la linea: $fp = @fsockopen(‘sslv3:**’.$host, 443, $errno, $errstr, 4); Por esta otra: $fp = @fsockopen(‘tls:**’.$host, 443, $errno, $errstr, 4); Dicen, que de está forma quedaría reemplazado el protocolo ssl3. OJO!, en realidad el codigo, en lugar de ** lleva //, pero no se porque no me deja pegarlo si lo escribo completo. Pero en en el modulo paypal fee 2.0 (no hay carpeta api) la unica refencia que hace al ssl, está el archivo validation.php y es: elseif (($fp = @fsockopen('ssl:**' . $paypalServer, 443, $errno, $errstr, 30)) || ($fp = @fsockopen($paypalServer, 80, $errno, $errstr, 30))) Igual que antes ** es // - ¿Valdría con cambiar 'ssl: por 'tls: , tal y como se indica para el archivo paypal_connect.php? - ¿o como he leido en algun post de este tema y otros blogs, las versiones inferiores no se ven afectadas por este cambio?. Ya llega la fecha señalada y ahora sabremos si el no actualizar el modulo paypal o hacer estos cambios en la programacion, da fallos de verdad o no.