datakick

No, you can connect multiple installations to your account, and you can use premium modules on all of them.

If you want to import product supplier information, and if you are on tb1.5, you can use my free module https://store.getdatakick.com/en/free-stuff/import-product-supplier This module does not perform the import itself. It simply registers new CSV import entity Product Supplier. Standard thirty bees CSV Import will see this entity type and can work with it. New version of the module also supports two new fields Supplier Product Name and Additional comments.

This functionality is now in bleeding edge. You can now set custom email subjects for your order statuses

You need to look into error logs (collectlogs module) to find out if there is any error. It may be caused by override, module, or whatnot. I personally can't reproduce this issue, and I do sell virtual products.

This is new bug in 1.5 (the customizable one) -- tracked here https://github.com/thirtybees/thirtybees/issues/1730 Thanks for reporting it. I've fixed it already, and will push the fix to bleeding edbe and 1.5.x branch

This is very common problem with a lot of older modules. When you see this error (on PHP8) or warning (on PHP7), then replace key_exists($key, $this) array_key_exists($key, $this) with property_exists($this, $key) The first two functions can be used with array only. If object is passed instead, older versions of PHP converted this object to array automatically (silently, or with warning). PHP8 do not do this automatic conversion, and fails instead.

I looked into logs, and it looks like your site isn't reachable from our accounts server. Your site renders some sort of captcha/challenge, which blocks integration.

Last week we have released new premium module Remove account. This module adds your customers an option to request account deletion, directly from their customer account in front office. Account is not immediately deleted, but rather scheduled for deletion. Your customers can change their mind during the waiting period. Merchants have the option to approve or reject the deletion request. Or you can set it up to automatically approve account deletions. Technical notes: Customer account is not really deleted. Rather, all customer data are merged with one (hidden) customer account. This removes all personal information from customer record (compliance with GDPR), yet it keeps data for accounting and statistics purposes. Invoices are kept intact, as required by (most EU) laws. PII data on invoices are not subject to GDPR law, so it's OK to keep customer name, email, or address there even after account deletion. Let us know what other functionality would you like in this module.

yes, tbhtmlblock module is not multistore-ready https://github.com/thirtybees/tbhtmlblock/issues/3

core updater should take care of it for you

I've just pushed fix for this problem into bleeding edge: https://github.com/thirtybees/thirtybees/commit/554e9967340a34bee0bdf51a4cf957f8f97a865b I'm also thinking about adding the key to the database. It will make the table bigger, but should help performance significantly.

We can safely drop this, as browser support for webp is very good now: https://caniuse.com/?search=webp

Yes, since thirty bees 1.4 (I think) we track pack items sales as well. This info is taken into account. So, if you sell product A separately 1 times, and as part of pack 9 times, purchases module will see 10 sales of this product. Sure, let's add this to backlog. For MOQ -- we already have something similar to this, but little bit more generic -- custom notes for products. So you will be able to notes for product A and Supplier S, for example "Always order whole box" This is settings for Export section. It's a remnant from first version of the module, we will probably remove the export functionality completely. Export was used before we had purchase orders to gather data for it. Yes, shop default currency Module already do this. If it doesn't work for you, please check javascript console -- maybe there is some error that blocks this js functionality. Safety stock represents minimum quantity you should have on stock to be able to achieve expected service rate. It takes into account only demand and service rate settings. Reorder point represents quantity on stock when you should reorder the product. This will never be less than safety stock, but it can be higher. It takes into account order placement costs, and stock ownership costs. This is what we use to suggest products to order.

I've added this to the backlog. Thanks for the suggestion

I have no issues with importing product with features. Can you provide sample csv import file?

Yes, paid version is an extension of free one. Do NOT uninstall the free version. Just upload the premium version over it. Thanks for the report

Exactly Yes, that would do that. If you manually update the module and remove the function handler, the system will still try to call it I agree. I don't like the original Logger much, but at 1.2 there wasn't an alternative. We can modify this place in Hook to simply trigger PHP warning and let collect logs do its job. Or even better, we can simply unregister the hook, since we already know that the handler doesn't exists.

Thank you so much, that's interesting. Unfortunately it also makes it much more complicated to implement, as usual 🙂

This premium module can help you optimize and streamline your inventory purchases. Purchases module is build around an algorithm to calculate optimal quantity to order for each product. This algorithm takes into account your desired service rate for product (for example, you want to have product readily on stock with 95% probability) cost of placing supply orders (overhead you pay for purchasing) cost of stock ownership (overhead you pay for keeping stock in your warehouse) supplier lead time (some supplier can deliver in 3 days, other in 90 days) actual demand on product -- how much have you been selling this product (weight average) The algorithm will take all this, and for each product generates information like safety stock, reorder point, reorder quantity, etc. The numbers heavily depen on algorithm input parameters. Initially, you should tweak the parameters and observe how these calculated metric changes, until you are satisfied. On top of these data we have build a Purchase Order tool. You can easily create purchase orders for each supplier. The module will advice you what and how many items you should order. You can also set up module to automatically generate Purchase Order drafts for you (for products that are low on stock and should be ordered). This can greatly help you with your purchase process. And, if set up correctly, it can help you optimise you cash flow -- don't keep all your operational money in stock that can depreciate in time.

Hi everyone, I would like to ask your opinions / experiences with VAT on pack of products. Currently, pack of product is treated as a separate product with single tax rate. I believe this is not correct, especially when pack contains products with different tax rates. What is your take on this? How should system work?

Logger::addLog method, when called with $allowDuplicate=false, can be very slow. Method checks if the error log is already present in the table, and insert it only if it is missing. Uniqueness is queried like this: 'SELECT COUNT(*) FROM `'._DB_PREFIX_.'log` WHERE `message` = \''.pSQL($this->message).'\' AND `severity` = \''.$this->severity.'\' AND `error_code` = \''.$this->error_code.'\' AND `object_type` = \''.pSQL($this->object_type).'\' AND `object_id` = \''.$this->object_id.'\' ' There is no DB index that could be used, so full table scan is required. That can be very slow once the table increases in size. This is causing performance problem during every Logger::addLog (or PrestaShopLogger::addLog) call with $allowDuplicate=false, and there are a lot of such calls in core and modules. One of them is in the Hook, as you mentioned. Truncating db table regularly helps. Alternatively, creating index on those 5 columns would help as well. For example, creating key on the first 150 chars of message, and all other columns: alter table tb_log add key(`message`(150), `severity`,`error_code`,`object_type`, `object_id`); Related to Logger::addLog in Hook -- this points to consistency issue. You have some module that registered hook, but does not provide hook handler. Every time the hook is triggered, thirty bees is trying to call module hook function, and every times it fails to do so -- wasting resources. Module should have never register this hook in the first place. Since tb 1.2 this is not a problem, because core checks during module installation that the hook handler exists. If not, warning is thrown during installation time, and hook is NOT registered. Which means this Logger::addLog would not be called later. This Logger::addLog is called only for modules that were installed prior 1.2. Or for modules that removed hook handler in some update after installation, but did not unregister hook as well. You can use my consistency module to detect and fix this: https://store.getdatakick.com/en/modules/consistency

Yep, another issue in the module. Will be fixed

Thanks for reporting this. It's both (old) bug in the core, and bug in new premium Purchases module. I've already fixed this in Purchases module, will be part of next module release. I will create issue for core to prevent this kind of problems as well

tbpdater module existed to keep your installed thirty bees modules updated. In 1.5.0, this functionality was moved to the core. The module is no longer needed. Having this module installed would actually cause troubles. You have to uninstall this module before updating to thirty bees 1.5.0. I also recommend to delete the module from disk.

uninstall tbupdater module. Its no longer needed.