All Activity

Call Me +91-7742308551 World Famous Top Tailoring Shop Goyal Tailors In Jhunjhunu

World Famous Top Tailoring Shop Goyal Tailors In Jhunjhunu

World Famous Top Tailoring Shop Goyal Tailors In Jhunjhunu

Currently, the returns feature only works for orders with the statuses “Shipped” and “Delivered,” which makes sense, since it would be difficult for a customer to return products they haven't received. Therefore, adding the ability to cancel orders to the returns feature would require a major overhaul of that functionality.

Database, PREFIX_employee table, campaign_disabled field. Set the date 100 years in the future.

Click on the x and then on the last entry on the new page that shows. This will mute the banner for 1 month.

great, care to share the location (s)?

3.8.3 - 03/24/2026 Fixed HTML content displayed as raw code in the front-office form (form text and confirmation message) Fixed hardcoded 'classic' theme fallback, now uses the configured theme Removed unused images and dead code

I don't know the regulation and I am not affected by it. But in general I agree with @Yabber how it should be handled. A clean/standardized process, that is triggred by a button. Afterwards I would check if the order involves multiple products. If yes, I would ask the customer, if he wants to cancel the whole order or only some products. A contact form might work as the oldfashioned solution, but imo it has only drawbacks (for merchant and customer). I would only disagree with @Yabber, that cancellation and refund are totally different things. From a coding perspective, they are pretty strongly related. In both processes you have questions like: Needs the current_state (order) be changed? Is there a money refund involved? Is the whole order involved or only some products? In both cases restock might be needed. So in short I would say, cancellation is a simple case of returns.

Let's keep the discussion polite.

@DRMasterChief Whether a customer sends an email via the contact form or through an email client, it’s always just sending emails with no integration with the store’s functionality. This doesn’t automate any operations in the store and requires labor-intensive handling by store staff. There are industries where the return rate reaches as high as 40%. At a company like Zalando, they have to process thousands of returns every day. So the number of canceled orders will also be enormous.

Oh dear, good grief! There's no need to send an email to the shop using an email program. The regulation specifies a button that may link to a form. The form can be pre-filled or not; there are no further regulations regarding this. And yes, when the "confirm cancellation" button is clicked, the shop receives a notification in the background. The regulation, effective from June, simply aims to prevent customers from having to use an email program, a letter, a fax, or even a carrier pigeon. That's the basic idea. The customer simply fills out a form or checks a box, and then submits the declaration that they wish to cancel the order. Why is so much more being read into the regulation than it actually stipulates? Thanks @vir for your post before.

@vir The module you're promoting includes the following description: “This module adds a withdrawal request button to the order detail page in the customer account.” So I assume that the customer must be logged in to submit a request to cancel an order. There isn't a demo of the module, so it's hard to say much more about how it works. I provided the WooCommerce and Shopware examples to show that in every e-commerce application, the customer must be logged in to manage their orders. Without logging in, the only option is to send emails to the store.

@Yabber Sorry if I say this but you're just creating confusion and confusing whoever reads this post. Your screenshot shows a section where the customer can access after logging in, correct?...I also remind you that this forum should only refer to Thirtybees, not WooCommerce..... So we have a login and a much more complex procedure than the one provided for by the module I'm using, which simply requires clicking a button (a button expressly required by the directive). Sorry to insist, but I'd like this to be clear for everyone....

@vir When processing a return, the customer simply selects the items to be returned and, if necessary, adjusts the quantity (they don’t have to return all the items). What is difficult about this interface, and what could be simplified? What aspect of this procedure is inconsistent with EU directives? Is it true that, under EU directives, a customer can cancel an order at any time (even 10 years after purchase), the store must refund 100% of the payment, and the customer does not have to return any products?

I have to disagree with you Yabber. The procedure you described is too complicated and violates the EU Directive. Without the module https://psitsolution.com/tools/en/thirtybees-ps-mandatory-withdrawal-button-module (or a modification to the current Thirtybees core), you cannot comply with the directive. The module does what it needs to do and costs less than 30 euros. Lifetime license and updates, so, if there are any future changes or adjustments to be made, they will certainly be implemented by the developer.....This is my experience and my choice. I'm very satisfied and just want to share. Feel free to do as you wish, but be careful with German lawyers! ;)

@DRMasterChief You are confusing two completely different procedures: "Order Cancellation" and "Order Return". If the order has not yet been shipped, the customer can cancel the order, and the store will issue a 100% refund for the order. If the store has already shipped the order, there can be no question of canceling it. In that case, the "Return" procedure is followed. The customer sends the products back to the store, the store checks whether the products are damaged or used, and only then issues a refund for the order, minus the shipping costs incurred by the store. In Thirtybees, the order return functionality is very well implemented. We configure the timeframe allowed for order returns; the minimum period required by law is 14 days, but many stores set it to 30 days or even 60. Thirtybees automatically monitors the timeframe allowed for returns. Of course, both procedures must be described in the store’s terms and conditions.

I've also come to the conclusion that we're talking about different things. On the one hand, there's the simple cancellation "I don't want the goods / I want to return them," and on the other hand, there's an automated process with a possible automatic refund. These are indeed different things, and the EU regulation doesn't require any refund function. The conditions for a refund are fully and clearly regulated elsewhere, and have been for a long time; there won't be any changes to that in June 2026. And we certainly don't use a shop system for this, but rather an inventory management system, which undoubtedly operates on a different level. But thank you for the hint to keep our business going. Now nothing can go wrong. 🤙 🤠

German Shopware store app. Extension: "Order Revocation for Customers", a legally compliant implementation in accordance with EU Directive 2023/2673. The customer LOGS IN to their order dashboard and sees a “Revoke” button for the relevant order.

@DRMasterChief You yourself described this feature as not wanting a "Cancel order" button for orders, but rather buttons that lead to a contact form where the customer can submit a request to cancel the order. To me, these are two completely different features. This standard contact form includes everything you need. There is a "Subject Heading" field, and in the store's contact settings, you can create a contact titled "Order Cancellation". There is a field for the customer's email address, an "Order Reference" field, and a "Message" field where the customer can enter their request to cancel the order. Many stores are already implementing advanced AI-based automation procedures to minimize operating costs. If your store relies entirely on manual email communication, you won’t stand a chance against these fully automated stores.

@vir and @Yabber: The simplest form has three lines: name, email address, order number, and a text field for free-form comments if the customer wishes to provide them. And nothing is automatically pulled from the shop data in the simplest version. Submit button – done. Does it really take an hour to fill it out? Is there anything about it that isn't GDPR-compliant? I completely understand the need for a more sophisticated solution, but I don't quite understand why other opinions aren't being understood. Some people are interpreting the EU regulation to mean that a login wouldn't be a problem. We're not there yet, folks. At worst, time will tell. There's plenty of written guidance on implementation, based on the current assessments from lawyers and trade associations. We don't manage inventory, packing lists, invoices, etc., in the Thirtybees shop. The shop system is simply the customer frontend for us. All orders are transferred to our inventory management system, where everything else is handled, including picking in the warehouse, label printing, etc. Perhaps the requirements are simply too different. But it's good that we're discussing it, and I think the topic will become more prominent in this forum in the near future as more people look for a solution.

Thank you for doing this ... Enjoy your coffee ... Cheers

Any news on an updated Mollie module?

@DRMasterChief What you want to implement in your store doesn’t require any changes to Thirtybees or any additional modules. You want a button that links to a contact form where the customer must submit a request to cancel their order. Just add a link or button anywhere in your store that leads to the standard contact form, and that’s it. And since this solution has nothing to do with the functionality of the "Cancel order" button, has no integration with the store, and doesn’t automate any actions in the store (such as automatically changing the order status), that’s a different matter. What you’re proposing is just plain old email writing. The customer has to write an email providing all their details, then the store staff has to read that email and take some further action on the order. And this whole "canceling orders without logging into the customer’s account" thing is total nonsense. Hackers will be canceling all the orders in the store every day. There are no safety measures in this solution. Here’s an example of how it’s done in WooCommerce: https://woocommerce.com/products/customer-order-cancellation-for-woocommerce/ The customer logs into their account, sees a list of their orders, and on that list there’s a "Cancel order" button—they don’t have to spend an hour filling out confusing forms where they have to provide all their personal information. In my module, I implemented this as follows: the "Cancel order" button is always visible in the store's navigation bar; when the customer clicks it, they are taken to their order list and can cancel the order with a single click. In the module’s configuration, you can exclude order cancellations for virtual products and customer personalized products; by law, such products are non-returnable. When the customer clicks the "Cancel order" button, the order status is automatically changed to "Order canceled". Many electronic payment gateways offer automatic refunds when the status is changed to the one specified in their configuration—in this case, we achieve 100% automation of store operations that require no action from store staff.

The module I'm using implements the contract withdrawal request button in the details of the order just completed (see attached screenshot). Therefore, the consumer will immediately find the button to access the contract withdrawal function in the details of the order just placed. It's already there, ready to be used. The login, which you see as a complication, will only be necessary to return to the order details at a later time and is an essential requirement (required by other regulations and directives) to ensure the appropriate level of confidentiality and security of the system in use. Avoiding the login to an e-commerce site that provides a personal customer area that collects personal and sensitive data would violate other equally stringent and stringent regulations, not only in Germany, such as the Privacy Act. I repeat, therefore, the login cannot be seen as "a complication to access the procedure" but as a "conditio sine qua non" due to the Privacy Act. exactly what is provided for in Article 11a of the law.