Leaderboard

My idea is to split the RMA process into a tree They choose reason for the RMA: - Exchange. - Warranty claim. If they choose Exchange, they are presented with an option to choose another combination from the same product. If they are at the same price- perfect - the customer sees guidance on how and where to return the item and how/when they will receive the exchange. If the combination they choose is cheaper they are presented with an option to receive store credit or get a refund after the process is completed. If they end up with the first option, we're using the new credit system. If they choose a combination that is more expensive, we might generate them a virtual product, add it to new cart for them and escort them to the checkout after they complete their RMA request. The virtual product should be limited to this customer and hiden from the normal catalog. Product name Price difference – RMA #000184 Short description: Price difference for exchange associated with RMA #000184. Original item: hmlCORE XK Jersey Size M Replacement: hmlCORE XK Jersey Size XL Returned-item credit: €31.95 Replacement value: €36.95 Amount payable: €5.00 Original order: #001284 That way they can use any payment method we offer, even COD which can be attached to the replacement product we ship to them. We only ship the replacement when they have returned the original product and paid the difference (if use of prepayment method like card/bank wire is selected). Same for choosing an entirely different product in the other branch - we can display a normal search field, where they can find all products by name/ref number, select combinations if present and proced with the flow in the same way - same value - perfect, replacement is cheaper - choose store credit or refund, replacement is more expensive - generate the virtual product and make them check it out. For warranty claims, we can have a configurable form where they select a predefined issue (delivered broken, broken after usage, defective part, etc), they might be asked to describe the issue in writing, and of course to upload mandatory images so we can inspect the defect. Then after we process the request in BO the customer receives a special RMA contact email with instructions how we proceed with it. We can even expose hooks so external shipment modules like the one Codex generated for me for our local courier can generate a return label and send it out with the email. In general, the idea of a custom module doing this is good but i think that RMA process should be part of the core as every shop is mandated to have this process in one way or another. We simply have to modernize and optimize it so the customers find it easy to use and detailed enough so they don't think they are left in the deep and have to email or phone us. If the form is descriptive enough and acts more like a wizard with 2-3-4 steps, I think the user will gladly use the RMA flow more and leave the emails as a last resort.

Hallo @Bird der Aufwand ist sehr unterschiedlich. Für das Gewährleistungslabel ist es relativ einfach (das ist das Label das man immer anzeigen muss und auch im stationären Handel aushängt). Für das Garantielabel (das ist auch technisch was ganz anderes als das Gewährleistungslabe), ist es schon deutlich aufwändiger es gut im Shop umzusetzen. >> Wir dürfen die Anforderungen und Technik dahinter keinesfalls vermischen 😝 - das passiert aber leider sehr häufig wenn man online unterwegs ist. (ist dir das soeben auch passiert? )

It's broken as in "We can't guarantee that the page will always display the correct data", not as in "it's not working". It does work, but the cache invalidation is wonky. For a lot of stores (that don't care about the data displayed to be 100% up-to-date) it's still a good option to have a blazing fast shop. Although, I believe with server-side cache for smarty enabled, the difference in speed is not significant enough. So maybe we should finally rip this out

The upgrade to this new version from TB 1.6 was so easy ! Thank you for your hard work!

Any news on a Mollie update? Wero is now actively being pushed.

OK, thank you Smile for the answer, that makes sense. This release gives me the will to get a nice modern theme to work with. Could that be done natively for once, instead of a theme that drags a pile of modules along with it? A default theme should work on its own, that's also easier for you to maintain. I'd be really happy to see a Bootstrap 5 theme in TB, and I'm willing to do the work. I did one a few years ago (Cisero), so I know where the landmines are. It would ship alongside Niara rather than replace it, so nothing breaks for existing shops, and with no build chain at all, plain CSS and variables, so anyone can edit it. Happy to talk about it whenever you have time.

Yes, we have decided to deprecate the old paypal module. We thought about creating a new major version of paypal module, but decided to go with a brand-new module, so if any one of you guys wanted to keep using the old one, you could. The new module will be released shortly. It's based on latest paypal API. At the beginning it will not contain as many features as the old one, it just focuses on accepting payments reliably. In the future, we will implement other features like refunds etc, if there is a demand for it. Feel free to use old version of the module for now. Just know that it's been officially deprecated, and we will not invest any time into it.

Maybe it would be interesting to create a special forum topic where people can share their with ai created modules if they want to