the.rampage.rado

You know our module is completely different from theirs, right? The version we have is long archived and not used in PS.

Looks great!

Regarding the modules - I mean that I think there could be modules that change the shipping status via API. Regarding the statistics - I'm sure there is none. 🙂 Those KPIs are internal parameters and every large organization is tracking them. I'm working on a module that could track such data and I'm thinking if we can modify the delivery date-time when we set the Delivered status.

Hi there, I'm curious if any of us is tracking those two vital KPIs for their shops? Handling time (TTS - time to ship) - the time between receiving an order and shipping it. Shipping time - the time between shipping from your warehouse and delivery to the customer. Delivery time - sum of both. So are any of us using modules or internal tools to measure those KPIs? This is useful for inner workings optimizations and, of course, for comparing carriers serving the same delivery zones. I'm curious if editing the delivery timestamp in the table during marking it as Delivered or at a later point is a viable option for making those stats more accurate. I, as a small merchant, do this in bulk when I have free time to clear the 'Shipped' orders from my list. I imagine there are shipping modules that also track delivery and will mark the orders as Delivered or Returned, etc, but I've never worked with similar.

@beetea2, thank you for reporting this bug. You can test the fix from here: https://github.com/thirtybees/thirtybees/pull/2068 But keep in mind that it might be changed during merging so if it's critical and you don't update to edge regularly keep an eye on github so if there are changes in the final fix you can apply them manually. Cheers!

You should not use the global Free shipping if you set it per carrier.

I replicated the bug with my test setup. It does not take into account the conversion rate at this step "Minimum order value".

Can you describe me the exact settings for both carriers in your initial setup to try and replicate this issue with the minimal order value on my test@

How do you hide your 'weight' courier when the price goes over $60? The customer should see your 'free' courier with FREE and under it same courier with some cost for the weight bracket the order falls into. For me this is very confusing both from customer UI perspective and from administration side.

You're misusing the settings. You should have only one carrier for every single carrier you work with and assign free shipping according to weight/price in it as follows: In my case - I offer free shipping over 100 BGN, as you can see you have to add second range (upwards of 100 BGN) and assign 0.00 as cost. Then in FO in BGN (ignore the double currency, this is a local requirement currently as we are addopting the Euro from Januar 1st): And in Euro: In general don't make 'paid' courier up to your free delivery and then second courier for free deliveries for over XXX. This will skew your statistics for courier usage later on.

I've deleted around 50 spam accounts of yours, but let's hear what your offer is today. 🙂

Sorry, I was confused by the previous topic. No, currently the client can have only one email. Multiple addresses, yes, but not multiple emails. Moved your question to a new thread.

Go to the user you want to merge and (REMOVED SCREENSHOT) EDIT: Not looking at the last post. Question was split in new thread.

The point of github is to optimize the work of the developers supporting the platform. If you want your problem to be fixed quicker you'll take the 'extra effort' to register a github profile and submit your issue there. Otherwise we should have separate person gathering issues here (some of which can't be replicated on third party installations due to module conflicts) and you can imagine this will be far from optimal.

As there is an update that there is work being done behind the scenes I don't find any reason for this thread to be pulled up. Of course it will remain open but if you have some issues with your installations - bugs, etc - you should file them in github so when work commences on bugs again they get resolved quickly. If you have found a solution for your bugs - even better - put it again on github.