x97wehner

Hello, I have a amazon sync module for PS 1.6 that the developer told me they will not support with TB 1.4 since there is no class = attribute anymore. I'm sure @datakick has a solution for this with the latest version. If there is one, can you outline how to fix it please? I can share more info if needed. This is a big problem for us. Thanks

Kind of what I was figuring. Thanks for confirming my suspicions.

I originally posted this under a different folder, but think it may get missed there. I'm curious on the module's usage and whether it should be enabled or not on my site. Currently, I use @datakick's reviews module and it works great. Given that information, is there any value in using this JSON module for everything else within it? Can they work together correctly or does it create conflicts that will break SEO?

I expect the easiest would be for your theme to have a homepage component that allows modules to be added. Then you'd be able to easily put it where you wish. Otherwise it would require some code to get a hook that would allow it as I doubt that hook would be native to that module. I could be wrong though.

Bringing this back to the top for some guidance on it's usage and whether it should be enabled or not on my site. Currently, I use @datakick's reviews module and it works great. Given that information, is there any value in using this JSON module for everything else within it? Can they work together correctly or does it create conflicts that will break SEO?

Hi. I currently use SendInBlue for our digital marketing efforts. But they've now discontinued support for PS 1.6, removed the module from their site, and only support PS 1.7. Their current module that I already have, doesn't fully work anymore because of this. I'm curious what other comparable tools others may be using that natively integrate with TB?

I just checked my site and I do not have the same issue. The only setting that I can see different is the last checkbox to disable Apache mod_security. Mine is set to yes. Not sure that this will resolve your issue though.

Oh, wait, I'm getting somewhere now. I didn't have my subdomain cleared to access the API. Now that I added it to the website credentials, it seems to be working. Thanks for the help @the.rampage.rado

Thanks. I found it. Inserted the API I just created but now getting a different error. Any other secrets to getting this functioning?

Where is that setting? I don't see it on the locator menu.

I thought I would just be able to turn this on, but the map doesn't seem to work correctly. It throws up a window saying that it can't load the google maps correctly as shown below. I checked the demo TB store on the website and it's doing the same thing. Anyone else seen this previously or know how to resolve?

Good to know

We use stripe, which allows afterpay installments. The TB module is not current with the latest API so you can't just have a pay option in checkout for afterpay. But if they click into stripe, it is presented as an option to finish payment. I assume TB gets a cut of every payment processed so I am very surprised they have not kept the module up to date.

Yes, it's still a little clunky, but far better than it was prior. I find it a bit easier for our company to just manually enter B2B orders so we can adjust pricing for product and shipping a little easier. We don't do that many b2b so it's easier than maintaining another set of prices in the system.

@datakickAlright, found a new bug. Everything seems to work fine on the page all the way through, until the actual payment processing. When the customer clicks button to make payment at the bottom, they redirect to processor whose page is receiving only the amount that appeared when the chex page originally loaded. Not the revised amount based upon customer selections. I have had multiple people complaining about the error in the last 2 weeks and was forced to roll back to version 0.8 to get around it.

No gamble. It will work to stop the orders. It won't pop a message on why there are no couriers available, it would just say shipping is not available. This is why we just use the rule to inject the true shipping cost if the order is below our minimum. It stops most, but some people still don't care and pay the higher fee to get our product.

I have not. I'm guessing you have a similar situation to us where you have this minimum instituted because there is no way to make a profit after shipping by selling a smaller amount? If so, perhaps a solution like what we did would work for you. We've implemented the below module to handle that situation. For us, we have a rule on a handful of products that raises the shipping cost to the real postage cost if they are only selecting these few products. You could easily implement the same rule you currently have with this module as well, to disable all couriers unless the amount is over your minimum.

I have built a dashboard in Microsoft Power BI that connects to the TB table structure to give me better analytics across the board.

I try to, but the lack of accuracy in calculating actual shipping costs restricts it's accuracy and effectiveness. We have to use a separate reporting tool to figure this stuff out. Allowing a percentage over 100% in cost calculations as well as a fixed fee option would make this reporting so much better.

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.