x97wehner

I have it turned off on the checkout page so I'm not experiencing that issue.

Yeah, auto set it but leave the option there to switch it as you've mentioned.

This stuff is where I think I can help. I'm a business application software architect for enterprise-level ERP and CRM systems by day. For the situation you're outlining, the reality is that you almost always need to capture both a operators local currency price as well as the converted to shop's default currency price in nearly every scenario. The reason is that for most backend operations, the main value than needs to be factored and used is the shops default currency value. For the front-end operations, ordering, refunds, etc, the customer's (operators) local currency value is nearly always the number needed. Plus, from the front end standpoint, knowing the customer's localized value and it's converted default value at point of entry it's vital, rather than having to go back and try and figure it out later for reporting. It's tough to know exactly when you'll need one value over the other in all scenarios, so the best practice in our development is to store both at point of data entry/change. Now, I don't know the exact purpose of the columns mentioned above, but they seem to be servicing the backend store owner, who generally will operate within just their primary default currency. Hope that helps.

Thanks. Ran the new version through some basic testing and seems to work fine now. Since we can't pinpoint what was causing the address switch exactly, going to put into production and see if hopefully it never happens again.

Hi, Now that holiday season is passed, I'm testing this out. First thing I notice is that the state/province selector has disappeared in the new 0.9 version. We are using that field to display correct shipping options to customers in the U.S. in an order flow that makes sense. It's also removed in the shipping address tab. I've validated via reinstall that it's included in 0.8 but not 0.9 This must be a bug.

I've used CSS to handle most of what you're outlining here. Let me see if I can grab it and paste it in.

I will do that. Thank you

I've been trying to reproduce it as well and haven't figured out the sequence. All I know is that it is happening far two often. I had two of them already this week. Being a U.S. company that sells into Canada, we require state or province. In the U.S., the incorrect injected shipping customer is always in the state of Alabama. We had our first Canadian issue this week as well and the injected shipping customer was based in Ottawa. I'm unable to tell if it is showing the customer the wrong information ahead of them processing the order. I have confirmed that the wrong shipping information shows on their order documents and within the system after being processed. Also, the link of the incorrect shipping information doesn't ever link to the ordering customer's record. If we catch it ahead of shipping, I can switch the order's shipping information to the ordering customers correct address, and then that incorrect address that previously was linked is no longer linked to the order or the customer anywhere that I can see at the database level.

Did you ever produce a module update that addresses this issue. I've dealt with the same problem for multiple years now. It doesn't happen often, but it definitely happens exactly as @Herrosik explained. Then our fulfillment team ships to the wrong address that was injected and it costs us on every order to fix and replace. It happens enough that we're considering leaving TB because the service costs associated with fixing orders are negating value gained by using the software. @datakick, can you advise if and you we can resolve this issue?

I actually use a more expensive version since google changed their tracking mechanism away from UA recently. It works well, but it's a little more https://addons.prestashop.com/en/analytics-statistics/27146-premium-google-tag-manager.html

Seems they tend to go hand-in-hand with a theme, for styling and such. The whole front-end needs that overall out of the box package redone by someone who understands themes can make the whole standard TB experience much more rich. That person is not me. 😉

From a backend perspective, the fact that I have to load the RMA page to update the status on it is a big inconvenience. If could be accessed/updated from the order it would be much more efficient. Also, from the RMA screen, it's not a quick jump back to the order.

This has always been a pain point for us. We use the RMA and it took a long time to figure out how TB/PS actually handled it to make the process with well for both customers and staff. Please keep up the improvements on this.

Worked like a charm. Thanks again.

I will give this a try and report back. Thank you.

There is a bug logged in Github outlining the need for the API to be updated to Stripe's new version. I

I know the theme does not natively support it. But honestly, this is the only issue I have with the theme at this point. I have no idea what it would take to make the theme support it. Is it a few lines of code to change or many, many updates across many files? If it's not much, I'd love some guidance on how to do it. Anyone done this before? Thanks!

I speculate this is likely an issue with your theme. I do not have this problem.

I haven't looked at that. I use @datakick's. It works very well.

Yes, Sunny has a TB version of Panda V1 that is TB compatible. You can download it with his standard v1 license.

Mine operates correctly

Install datakicks free blackhole for bots module. It works nicely to funnel a bunch away from your site as well.

@datakick's module works really well for this. We use it for facebook shopping feeds as well.

No. Turn on recapcha to minimize spam

I believe you can adjust this in Localization>Translations. Just make sure you have selected the correct theme that you are translating for.