Good evening all,
I have a problem with presta 1.7.5, the shipping costs are not displayed correctly,
this is both logged in and not.
Also the shipping costs are not fully calculated, see attachments.
I can only find it on the forum about deleting the display of free shipping, but that's not the problem.
I have configured everything (carriers, countries etc) It is also available as a carrier.
Anyone have an idea?
I have been familiar with prestashop and the systems for years, but here I just do not get out.
Shoppingcart
carrier select
overview order (Total is not calculated right, and bottom, and also not for payment)
I don't got an answer to your question, but you might want to change your overview order picture, all your details are in there ;-)
Related
I've gotten a message that my site may be knocked off of Google Merchant Center due to "Inaccurate availability (due to inconsistent availability between the landing page and checkout pages on your website)".
This affects only a small amount of products (only around 0.3% of my 40,000-ish products), so I know it's not an engine issue. After asking Google to recheck the results, they came back with the same error, but with a completely different list of products with no overlap, so I know it's not a problem on the individual product level.
There's no geo-locking on these products, and Google says that the problem exists on US IPs.
Nearly all of the errors look like this:
Value on the landing page - v:out_of_stock
Value in the data feed - v:in_stock
Performing an audit on the products in question shows that none of them have been out of stock for weeks, so the data feed is correct.
None of Google's suggested common issues (geolocking, buy button not working, product can't be shipped to an address, products not available country-wide) seem to apply. The country Google checked this on was a US-based IP.
I'm running out of ideas here, does anyone have any other suggestions?
The answer turned out to be something silly for my site, but I'm posting the answer here just in case this helps someone else.
Google's crawler was setting their country to be Andorra and attempting to check out using the US site. This is obviously not a good representation of the US experience. Google advised us that this was a mistake on their crawler's part, and that we would pass the next audit without any modifications. So if you're here looking for a solution, the absolute best advice I can give you is to find a phone number for Google Merchant Center and give them a call because the error may not be on your end at all.
Update: We passed the audit with no changes made on our part.
I have an online shop in development, all went well until I decided to do SEO on the shop. After this, if I chose a product variation from front-end it just redirects me to a random product.
This picture describes the first state. The default product load.
This picture describes what is happening after you select a variation. As you can see the product name stays the same, but the link indicates that a totally different product is displayed.
If I have the debug mode enabled when selecting a variation it throws "An error occurred while processing your request" and in the request file I can see that besides some errors (Deprecated: array_key_exists(): Using array_key_exists()) it shows the request for a different product.
I can't understand why this is happening, so I am in dying need of your help.
That's the way Prestashop 1.7 works :
First time a customer lands in a multi-variation page, the default attribute will be loaded,
URL will show only the ID product.
Once you choose an attribute , an AJAX call will refresh the page
with the current attribute and URL will change with id_product-id_product_attribute value.
Not sure what you mean by "random product" as in both of your examples I see an attribute
being selected.
Anyway there are several (paid) modules to change this behaviour in a better SEO perspective,
this is definitely one of the most famous :
https://addons.prestashop.com/en/url-redirects/16633-pretty-urls-seo-friendly-url-remove-ids-numbers.html
EDIT: Just noticed that the ID product is different in the two screenshot, this could be related to some DB issues with attribute too, you should check if you have some not coherent values between id_product and id_product_attribute(s)
I found a fix for this. Apparently or appeared because I was using the duplicate function for uploading products. I don't know why but on some products it makes this behavior.
I've spent over 12 hours to find a explanation for this and I was unable to find one. The PrestaShop forum straight up banned me for posting this topic.
My advice is to NOT USE PRESTASHOP it's and old sistem and full of bugs, the support is expensive and I get the impression that even they don't understand their system.
If you find yourself in this situation, know this. Don't duplicate and upload products using "add new" function.
And I can't state this enough, do yourself a favour and don't use Presta, with all the expenses the time to invest and what the product looks like at the end of the road, is just a waste of time. Even after you finish is guaranteed to break in 1-2 years, any updates will break your store and you will need to invest even more more to fix it. It's an old, slow and buggy CMS. It's days are numbered.
Thanks a lot for help.
Best regards, Daniel.
I just want to start out this post by saying that I am not a programmer, nor do I play one on TV. I have found this site because I have been trying to manage our Magento instance, after pretty much left high and dry by the developers we had building this for us. I will try and explain it the best I can below:
When we apply a shopping cart coupon to the sales order, and the discount is applied to each item, a new line item total is configured by Magento. We then have a connector that takes the information from Magento's API and it is then connected to Open Bravo, which is our ERP accounting software. Open Bravo is grabbing the information as it normally does, however it doesn't see the discount information, so the order total is different in our accounting program then what Magento has. Open Bravo is teling me they need to know where the discounted amount on the sales order in Magento is on the API. It's obviously in a different spot then the standard sales order amount.
I might be able to describe a little better if you hit me with questions. Any help you could provide would be highly appreciated. Maybe we could barter for some office supplies, as that is what we sell.
Thanks!
If you are using Magento API to fetch order information from magento, then below link will be helpful to find actual value.
http://www.magentocommerce.com/api/soap/sales/salesOrder/sales_order.info.html
It seems that your ERP is storing "base_grand_total" value in stead of "grand_total".
I'm currently finishing up a fairly customized Zen Cart setup for a client and while overall the site is 99% functional when it comes to ordering, I'm having an issue on the checkout page where the customer is able to see the item totals and the sales tax, along with the grand total.
The issue however is that the grand total accounts for the shipping rate (as shown below the order form) however I'd like to also have it displayed above the sales tax line.
Does anyone know which files I'd need to access to edit the cosmetics of the checkout total?
Aside from that, I'm pretty sure I'd be able to plug in the custom values since I have the variable names on hand from coding the site till now.
Thanks very much in advance for any assistance,
The order in which the totals are displayed is determined by their sort order on the Admin >> Modules >> Order Totals page.
I've changed them this way a few times for clients, but you do need to be check that the tax calculations still work (there have been quite a few changes to recent versions to try to get that right in all cases).
Recently a bug in our web store caused the prices to be doubled at checkout. This lead to a drop in orders from about 25 to 2 over a period of 19 hours. We have lost quite some money over this. What I wonder is: is there any way to measure how many of those "dropped" customers will come back and re-place their orders?
If they logged in, their user details. If not, compare IP addresses from your server log, IPs which left without buying during the price doubling, to IPs in the next week, to get a rough idea.
I would say if your product is good your customers will come back. I would say now is a good time to start collecting some analytics on your site. You won't have much to compare to but it would be a place to start. To tell if your customers are coming back you could compare the purchase data from before the issue to after. I would think you'd have some type of userid they would have to either log in with or enter when purchasing. Our sites all require a username to login, we also offer a guest checkout which is just an email address but we could comparisons if we needed to.
A non-programming solution is to offer customers who had the problem some kind of discount or additional product if they finalise their order. This doesn't help you find out how many come back because you are changing the rules, but it will help you lose some of the lost money.
If you have a mailing list, mail out the special offer, else put it up on your website somewhere.
Ask them to fill in the details of the order again, if it matches a previous order in that time period offer them the special deal.