wakabayashi

@davidp said in 1.0.4 soon?: I see there's blog posts going up about migrating from Magento to Thirty Bees, migrating to Thirty Bees with support and now new crowdfunding stuff. Also I've been offered help with omnipay payment methods stuff (which I appreciate) but don't you think for the benefit of all that you concentrate on getting 1.0.4 released before looking at these other side projects? There's a lot of people want to go to 1.0.4 via the updater and I suspect a lot of them are holding off doing a migrate until this is out given that 1.0.4 is going to be such a big update from 1.0.3. By crowdfunding some new stuff you're taking your time away from the core product. Please don't turn into Prestashop with the 'well the core's broken but here's some new sparkly stuff', that's the reason a lot of people are leaving PS in the first place! The question is: What is broken and what is not? I dont see too many real bug reports, which are open for now. The most of them are from me (on github) and they are about multistore and advanced stock management. You may be right, that many people are waiting for 1.0.4. But are these people also testing the beta? I guess more feedback would not only help, but also motivate the devs...

@datakick @nickon Yeah, if you want reviews, you have to ask them by email. There is no doubt about it. But as a merchants you also have to be careful, that you don't upset your own customers. I for myself would never send more than one email per order, where I ask for a review. I even wondered, if we should give a customer the option, to disable this kind of email notification? I have no idea, if there is any time left for this option. But my experience with newsletters tell me, that it could be an important function...

That's a really interesting question! I would also like to know the answer. I once had the feeling that statistics for best sales, doesn't work anymore. But it's long ago I looked at it.

Its very hard, to find the reasons for better/worse results in SEO, Bounce Rates and so on. I would guess, that it's the better speed. Especially when you talk about Bounce Rate...

@datakick thx a lot! you are a hard worker ;) Don't worry about the thumb feature. It's really not that important. I just wondered, if its a bug or not yet done. Keep Going ;)

@vincentdenkspel It dosen't occur here. But I wonder, if there is any functionality behind. Thumbs go away, but I dont see any stats or something...

I move this topic no to the tipps section ;)

@datakick you are right. the gmail emails were in the spam folder. The others maybe blocked completly. It's a very interesting idea with the email automation. I am not sure, what already exists. I can find "mailchimp", "mail alerts" and "mail hook" module. Mail chimp is clear, but not sure, what the other two are doing.

@datakick I have changed the email in your backoffice to mine. I still got no emails... I tried it even with two different mail addresses. I have changed it now back to yours email again. Btw my logs are empty...

Does the email notification work for you? I don't get any admin emails, when I review is added... Normal order email is coming, so can't be an server issue.

Cool!

Ok nice! have you checked, if no email is going out?

Can you please show me the error or your code. I cant solve it otherwise.

Sorry forget my answer before... Change this: if (@Mail::Send( (int) $order->id_lang, 'in_transit', Mail::l('Package in transit', (int) $order->id_lang), $templateVars, $customer->email, $customer->firstname.' '.$customer->lastname, null, null, null, null, _PS_MAIL_DIR_, true, (int) $order->id_shop )) { Hook::exec('actionAdminOrdersTrackingNumberUpdate', ['order' => $order, 'customer' => $customer, 'carrier' => $carrier], null, false, true, false, $order->id_shop); Tools::redirectAdmin(static::$currentIndex.'&id_order='.$order->id.'&vieworder&conf=4&token='.$this->token); } else { $this->errors[] = Tools::displayError('An error occurred while sending an email to the customer.'); } To: Hook::exec('actionAdminOrdersTrackingNumberUpdate', ['order' => $order, 'customer' => $customer, 'carrier' => $carrier], null, false, true, false, $order->id_shop); Tools::redirectAdmin(static::$currentIndex.'&id_order='.$order->id.'&vieworder&conf=4&token='.$this->token); I have tried this solution. So please test it out!

Maybe this topic is intresting for you too: https://forum.thirtybees.com/topic/1381/brainstorming-handling-orders-in-bo/20 I am talking a bit about emails too.

You need to modify the if (@Mail::Send) a bit. if you want to get clean code answer, you shouldn't add the code by screenshot...

@daokakao said in BrainStorming: Handling Orders in BO: Can't beleive this is impossible in BO. What if you stop to collaborate with some carrier? In that case you want to have a possibility to replace him for another one. Whether current PS/TB doesn't give that capability? Where should this function be? Changing carrier for an order has been requested a lot of times. I don't believe all this merchants missed the option in the backoffice.

@daokakao said in BrainStorming: Handling Orders in BO: Anyway, the possibility to choose the carrier after order being payed (until it shipped at least) is good option. In Russia virtually all ecommerce companies allow delivery method changing after order been payed (NOT thru website, but via phonecall/messengers/emails instead) Yeah the point is, that I want to change it in the backoffice. Cause as you said, the customer will ask you trough phone, emails or whatever. Five minutes later the same customer places another order. We as a merchant merge the two orders into one Should it merge be agreed with customer? What if he made 2 or 3 small orders intentionally? As far as i know, in PS/TB there's feature for customer to "split" order and deliver its parts to different addresses, so the reverse operation could be easy as well - don't merge some orders, but merge its delivery instead. I see no point, in making 2-3 orders shorty after eachother, which are shipped/paid to same address. Yeah order merging is an idea. But it is very advanced and complicated. You have to take care, which delivery method will be chosen. I am also not sure, if multiple warehouses could be a problem. From my opinion it's not worth to invest much time for it right now. Products Returns: .... if he only returns some items, it gets tricky. Too tricky. I can’t regenerate the invoice in that case. As far as i know, it is not a big problem if customer returns some part of order - a return order should be generated then. IMO, worst problem will be when customer intends to return a part of product pack. What should i do as a seller in that case? Require returning of all pack, or just its defective/wrong parts? How to handle it? Yeah I like your example! It shows a serious issue with product packs. The problem for us is, that the return function is limited. You can create something called "order slip". But in fact we would need to regenerate the invoice.

@datakick said in BrainStorming: Handling Orders in BO: @mockob it's actually quite easy to delete order - simply open order, and in page url replace vieworder to deleteorder As @MockoB said: The deletion is not clean. I also doubt, that it handles stock. But in general I think, that we should make it as easy as possible for merchants. Thats why I would like to see a delete button...

@Baarssen I guess you change the order basically trough your module, right? For example the carrier change. Which functions of this module do you need (because they aren't working in the core of tb)?

And how are you generating this new invoice in tb? Actually we use this ugly trick too, but wouldn't it be much better to have the option, to change carrier? Is your invoice attached to the order email? And from that point on, you are legally no more allowed to change anything?

@Kleijn36 Sir I live in Europe ;) Not sure if I understood you correct: so you cancel the old order and make a new one?

yeah I agree with that. That is the purpose of this thread. Since I only have my view. Others should bring in their view ;)

Yeah but that doesn't mean it's not important for tb. I believe almost every merchants needs to handle it. Some often, some others rarely. I just checked google shortly. Ofc Paypal and Credit Cards are becoming more and more popular. But still a lot of countries know classical payment systems: https://ecommercenews.eu/online-payment-methods-europe/ If you sum them (Invoice, Bank Transfer, COD, Cash on Delivery) up, it becomes a serious market share. I wouldn't see, how editable features, could harm merchants, who only use paypal!? Do I miss something?

In both cases? I mean a case, when somebody sends only 2/10 items back...