30knees

That's a good point. However, for this scenario to actually take place in my shop, the new order would have to be <5% of the previous order. That is *highly* unlikely. I don't know how likely it would be for other merchants, but I would guess that a single expiry of points coins would only lead to problems in the rarest of cases.

But isn't that the same principle? The main idea is that you need to place an order within a certain time period. And you never accumulate more coins than you spend because they're always automatically applied to the next order.

@wakabayashiThe native module has a validity period setting, see below. The idea is that the coins a customer gets give a discount on their next order, if placed within the validity period. So in my case below, if the customer orders again within 180 days, they get a 5%-of-the-previous-order discount on the new order. If they don't, the points expire and there's no discount. I came across this in another store and found it a quite strong motivator to order again.

The stats module already has best selling products (though unfortunately not by variant). It also knows the stock levels. Would it be possible to have a simple stock predictor that takes eg sales over the last 90 days, checks against current stock level, and predicts how long the stock will last?

The manual is really great! I also like the flexibility of adding different triggers. Especially awarding points for reviews is awesome. I scrolled through the early posts and remembered we talked about expiring points and sending an email to the customer eg 30 days before their points expire. You said it's quite difficult to implement. That's one of the main elements I want to use to get customers to come back to our store, so I'm thinking about either staying with the native module and Consequences or whether I can somehow get the same result with Krona and Consequences via Customer Groups. Another possibility: Use native and Krona together: Krona to award points for reviews, where these points don't expire, and native for expiring points for orders. I'll think about it some more.

I am setting up Krona and I just realised: Does this trigger work only with the native loyalty module or also Krona?

Datakick pointed me to the correct tab (Players) where one can import. I am also now reading the great manual that's under the support tab.

Ah, I was looking in the wrong tab for an import function. Thank you!

I've not used it but I think it's appreciated by a lot of users. You can check out the theme here: https://www.sunnytoo.com

@Brent DacusI think you'll need to do this. What you're quoting is for a theme called Transformer.

I want to start using it together with datakick's consequences module. I'm currently using the standard loyalty points module. Is there a way to import points from that one to your module?

This is awesome! Thank you so much. I already upgraded. Now to somehow transfer existing loyalty points to the krona module.

Depending on how much work it is, it would be great if you could hook it into https://github.com/thirtybees/loyalty so customers will be contacted before their points expire. Note: If possible, customers should be able to unsubscribe from any such emails after the first one is set. Perhaps also an opt-in/out feature like for Revws during the order process?

It sounds like you have one store on 1.6 and one on 1.7. It will likely be easier to switch from 1.6 to tb than from 1.7. tb tries to be compatible with 1.6, so you can (hopefully) use all your modules.

@datakick found and fixed the bug in 20 minutes. Thanks! I highly recommend his services: https://store.getdatakick.com/en/services He's fixed many buggy modules I've purchased elsewhere where the module developers couldn't or wouldn't provide support. I contacted the folks at @Common-Services offering them datakick's patch, but they tried to sell me their support instead and then ultimately declined the patch.

The demo in your account looks great. This is an amazing module, truly fantastic! It opens up so many possibilities. I don't think I saw customer groups or country zones as conditions. Would these be possible, too?

Maybe @Jonny can help if Panda is missing something for AEUC.

I'm manually creating an order in the back-end. I can't edit the price for a product that has a quantity of 2 or more; the price always jumps back. Only when the quantity is 1 does the manually edited price stay. Oddly, this only affects a certain (attribute) product. Other products aren't affected. Any ideas what this could relate to?

About the first one: I was thinking of adding a line in the shopping cart summary, in case that makes it easier.

In an old module someone implemented as a trigger each time the store was visited (I guess visit saved to database?) to get around having a cron task. Would this be an easy workaround, i.e. having a "universal" trigger?

I like the idea! Some use cases I see in addition to the ones you mentioned (and I'm sure there are lots more) are: - If products in shopping cart are under free shipping amount, show text: Only X Euro to get free shipping! Here are some products to help you get free shipping: (Display products close to the missing amount) - I use the loyalty points module. I'd love to have an email sent to customers ca. 10 days before the loyalty points expire. (Could one use as a general trigger to get around the required cron something like every new customer registration?) - If product X with attribute Z is sold, deduct stock from product Y with attribute Q. - If visitor visits a sold out product X, recommend product Y instead.

@lesley FYI

Thanks for the clarification and the help! 🙂 You're right! I've narrowed the bug down to the @Common-ServicesAmazon module. All orders imported from Amazon display for order_detail the weight x number of products (but we mostly get 1 item orders, so that's why it's such a rare occurrence).

Thanks, @musicmaster! Some additional information: It's with regard to variants/combinations. My main product has a weight of 0 and the variant has an additional weight of 1kg per unit. I checked the tables (albeit after having corrected the weight in the DHL module) and I think we've found the culprit: tb_product: It's correct, 0 for the main product. tb_product_attribute: It's correct, 1kg. tb_cart_product: Mine doesn't have weight. tb_order_detail: It's correct, 10kg. tb_orders: 139! (total_products_wt) Where does the total_products_wt come from?

This has happened again - and it looks like it's only triggered when the weight exceeds 10kg. It then registers as 100kg. Is there anything I can do to troubleshoot?