x97wehner

I use it in the standard format. Allowing customers to submit for a return, generally because they ordered the wrong thing. I serves it's purpose to help us understand why packages are showing up at our door. It functions good enough for that, but could definitely be improved. I don't do defective/warranty returns via RMA. I also do not do direct exchanges due to the fluid nature of our inventory and the varying prices between combinations. Generally I handle those via manual email. I have the RMA emails automatically sending on status change and that works well. A couple things on this though: - I work with very large companies on a regular basis, and most struggle with their RMA process and have very manual workstreams. - It seems that larger storefronts like Shopify are embracing that most robust RMA workflows move to 3rd party modules (Like Shipstation) so that customer submission via portal page and return label generation is automated and data integrates into the main shipping platform. - It would be great if there was a capability to let the customer choose another combination of the product to exchange with and eliminate our human interaction requirement, but that would even be challenging since our combinations are offered at different prices.

Is there any information available on how the store credit works? I've tried to navigate it via back office to no avail

I'm sure you've probably already done this, but running your domain through https://mxtoolbox.com/ can maybe provide insight as well.

If delivering to MS services, I expect this is B2B communications? If so, it's very likely the client would need to whitelist your domain before your emails can reach them. I've run into this many times before.

Sure. Pardon if you are aware of this, but I will lay out what I have to advise most companies below. I suspect that you historically were sending all email from one domain: yourdomain.de or similar. This setup can cause many issues with deliverability over time, which it sounds like you are now seeing. Fixing it is not quick but can be achieved easily. Business and transactional emails need to be separated from marketing communications by sending domain Business (Customer service responses) and transactional (Order confirmations) send from yourdomain.de, but marketing communications send from another domain or subdomain: email.yourdomain.de as example. (Check your spam folder at your personal inbox and you will see that most companies follow this practice as it protects you main domain from being flagged as spam by email companies.) Typically, you would only configure Brevo and their servers to handle marketing communications since they are usually larger volume and more likely to be flagged as spam. Your reply-to address in brevo can be a transactional address You can keep your transactional communications coming directly out of TB if you'd like using smtp. Brevo can handle these as well though if you'd like but more sending = additional cost. Ensure that you are not sending attachments in any emails by default, ever. This is almost a guaranteed spam flag against your domain. TB adds invoice attachments by default to order confirmations if you enable invoices. TB can be updated so that it still creates invoices, but does not add the attachment to the emails. The switch to using a new sending domain for marketing will take some warming to build a reputation. Start your first few sends to known recipients so that they do not flag you as spam manually on their side to help warm your domain. Additionally, in a different thread in this forum is a post with my latest version of the Brevo module that works with TB 1.6 and php 8+ and offers the ecommerce capability sync. If not using it, i advise testing on your site... it works really well to keep order data and lists synced to brevo.

Thanks for this. Testing it out currently.

I have been using Brevo for a few years for marketing communications only. This separation from has kept our transactional communications from the stock TB setup delivering smoothly for the most part.

Refunds with the current module have always been a pain point. Let me be the first to chime in for this. Similar operation to the stripe module would be ideal for continuity across providers. Appreciate your work.

I am seeing this same message. What does it mean? @datakick, perhaps you can answer since the latest commit was yours I see.

You've got my attention on the FontAwesome side. If you've got any instruction on what you did and how, I'd appreciate it. I'm running Warehouse on php 8.3 as well.

I use Brevo. It works well. I modified their PS module to make it work with TB. If you search in this forum, you'll find the latest copy.

They do outline the script code to look for. I just searched my website via f12 and then looked through the website code via MS Code and didn't find this expression anywhere, so I assume that I am not affected. " <script>(function(){var x=new XMLHttpRequest;x.open('GET',atob"

There is an open issue on github for this. However, it's a pretty easy fix to get working. Just read the item here for direction https://github.com/thirtybees/stripe/issues/86

Please check the forum before posting. I modified the Brevo (Formerly SendInBlue) latest module to work on thirty bees. You can download it here https://forum.thirtybees.com/topic/6963-brevo-marketing-module/

I'm not certain this will help, but have you tried selecting force recompile in advanced parameters> performance and also clearing smarty cache from that spot?