30knees

The way we do it is to manually generate a return label in DHL that gets sent to the customer. For us it's not really too important (at this time) for the customer to be able to generate a return slip automatically. But I'm happy to exchange thoughts on the topic if it can help. I think it's cool you're working on this. :)

Yes, the old modules are headache because they're not being supported anymore. So there's no way they'll be updated to PHP 8. That's also why I'm hesitant to upgrade, even though 1.4 and the future plans look really, really good, much better than I had hoped for, and show a promising future for tb. For those who understand what's required: Is going through modules and making them ready for PHP 8 always a major undertaking or is it highly dependent on the module?

"Being prepared for shipping" is actually "DHL - erfasst". I just translated it for the forum. It's when the shipment has been electronically generated with DHL. We only do this once the order is paid. Only in rare circumstances do we ship when it's unpaid, for example because we know the B2C customer or it's a B2B order. Refunded - no, unfortunately. It can mean we just refunded or that something was returned and is sellable. In the latter case, though, we typically do "cancel". It's not clean but it works as a hack. The whole refund system is somewhat a mess. Also, the states don't play too well with third party modules, eg for VAT calculation. We don't use ASM because we've heard of all the problems with it. I agree with you, the system could use some improvement.

We do it similar to how you do it. There are many order states that have been introduced by modules but we don't use them and the modules mostly don't, either. Basically, we have: Awaiting bank payment Paid (and variants for payment modules) Being prepared for shipping Shipped Shipped - Unpaid Refunded Cancelled Delivered Bold indicates paid and italics indicates shipped. Bold and italic indicates both states.

They've replied. They said the missed the ticket.

Any success yet? They've been silent for about two weeks now for me.

Yes, they're quite slow. Also, my inventory synchronization isn't working. I've been in contact with them about this for quite some while but so far unsuccessfully.

I'm using @Mediacom87's module (https://www.prestatoolbox.com/international-localization/460-simple-declaration-of-your-quarterly-intra-community-vat.html) now and it's fantastic. Very easy and straightforward to use. Super support. Highly recommended!

That's a blessing, thank you!

@Mediacom87Thanks, I thought you had replied to my last question about the export. :-) That clears things up. Yes, documentation requires a lot of time. Good luck with that! I hope your module can export according to multiple order statuses, too. I'd be very interested in that. Thank you, @datakick. Unfortunately, it didn't work for me, even though I've tried altogether for about 2-3 hours, but it's OK. I'll find another solution. For others who want to try, some hints: With these collections: Ordered products Orders Addresses I could get these columns: Unit price Unit price tax excl. Country ID Invoice number Invoice date Is validated But that still means you have to manually associate the country ID with the country (not sure how that works where invoice and shipping addresses are different) the tax for the shipping costs is missing

@Mediacom87Understood. But without your module your post isn't very helpful for someone who is looking to export the amounts of VAT. :) Then I guess it's back to @datakickto hopefully help with his module, which I already have (see above), if @Mediacom87isn't selling his module (yet).

Thanks! If I understand the translation, you have a module that isn't available but that you might be willing to make available? This is the translation (note: I saw the shop setup requirements and I believe my tb is properly configured):

Yep, that's us. :) Thanks for the update.

Thank you! I'm not succeeding with that, either, though. I'm not succeeding in getting the tax rate breakdown. This is what I have right now: and What am I missing?

What tools do you all use to get an overview of the VAT sums per VAT rate per Member State for the tax reporting? I'm struggling with that right now. I'm hoping Prestools will be able to do this:

I'd like to use the EU Order Tax feature to comply with the One Stop Shop VAT requirements. However, the One Stop Shop requires the sums per tax rate, so eg for Belgium 100 Euro for reduced 6%, 20 Euro for reduced 12%, and 40 Euro for standard 21%. Is there a way to do this?

That sounds great. I could imagine quite a few here would buy your theme. :D

Has anyone gotten Google Pay or Apple Pay to show in Chex with the official (not tb) Stripe module? They don't show for me. The module developers say: I'm guessing for now that there's an incompatibility but I'd like to ask for your experience. :)

The involic module is working now. Remaining issues that will be addressed in a future update: - more EU marketplaces (hopefully) - proper order method mapping

@BeetaIs your order tracking information being sent to Amazon with the involic module? Mine isn't. Edit 1: I also see now why the error was thrown. Orders don't have shipment information (price, weight, method) assigned to them when they're imported. That may have been because I didn't define a method (as proper shipment method mapping isn't supported yet). I've now defined a method and let's see. I'll update here.

I'm also using the involic one now. Setup was quick and easy. A couple of problems (I've contacted involic but they've not replied yet): It imported a bunch of old orders even though they had the status 'shipped'. It seems to have been a one-time thing. The orders that get imported throw an exception when I try to generate DHL shipments from them. I think some order status is missing from some tables: the orders also aren't being picked up by my warehouse order pick module, which relies on the order status. This is the error: Property OrderCarrier->id_order is empty in file classes/ObjectModel.php at line 1095 Source file: classes/ObjectModel.php 1076: * @throws PrestaShopException 1077: * 1078: * @since 1.0.0 1079: * @version 1.0.0 Initial version 1080: */ 1081: public function validateFields($die = true, $errorReturn = false) 1082: { 1083: foreach ($this->def['fields'] as $field => $data) { 1084: if (!empty($data['lang'])) { 1085: continue; 1086: } 1087: 1088: if (is_array($this->update_fields) && empty($this->update_fields[$field]) && isset($this->def['fields'][$field]['shop']) && $this->def['fields'][$field]['shop']) { 1089: continue; 1090: } 1091: 1092: $message = $this->validateField($field, $this->$field); 1093: if ($message !== true) { 1094: if ($die) { 1095: throw new PrestaShopException($message); 1096: } 1097: 1098: return $errorReturn ? $message : false; 1099: } 1100: } 1101: 1102: return true; 1103: } 1104: 1105: /**

No work around, unfortunately. It's the way the module connects to Amazon. That method isn't supported anymore.

Has anybody else's Amazon Marketplace module stopped importing orders because of MWS deprecation and the module not being updated anymore? My Prestalia module is now non-functioning because of that. The error I get is: {"status":"Developer is blocked from making calls for the MWS section Orders as part of MWS Deprecation process"} Any recommendations for an Amazon Marktplace module that still works with thirtybees?

Shopify also has it: https://help.shopify.com/en/manual/your-account/legal/pricing-indication-directive It's just crazy how thirtybees basically says:

Currently, it looks like @Smileand @datakickwill maintain the software. But you're on your own for any further requirements that aren't in the core. If you develop yourself and are happy to develop/maintain modules, you're probably good with tb. If you need external help with modules and what the core offers isn't sufficient, you may be better of looking elsewhere.