Occam
-
Posts
303 -
Joined
-
Last visited
-
Days Won
5
Content Type
Profiles
Forums
Gallery
Downloads
Articles
Store
Blogs
Posts posted by Occam
-
-
38 minutes ago, wakabayashi said:
The distinction between partial refund and product return doesn't make big sense.
I wouldn't agree! The distinction makes sense! See my tutorial here: https://forum.thirtybees.com/blogs/entry/43-properly-create-refunds/
-
Hmmh ... bleeding what? I'm not so familiar with this kind of insider tb-speak.
I suppose you mean some kind of development version. A link would be fine.
-
Like I already told @RabbitZzZ you need to apply the the fix proposed by Karlo Šimunović. However, this alone does not solve the cache error which may happen to AEUC from time to time. The hookDisplayProductPriceBlock.tpl will not show up when the Smarty cache is enabled. This is why I patched smarty.config.inc.php, too. In some parts it is a rollback of some improvements by @datakick, who totally dropped assigning variables by reference. Regardless of advices at Stackoverflow like i.e. this one, that assigning variables (with an ampersand prefix) as reference are deprecated in PHP 7 it seems that it still makes a difference. These changes didn't allow my AEUC module to correctly display the hook for tax and delivery costs.
I attach both patched files here: Fix_translations_&_avoid cache_bug for AEUC.zip (removed following the moderator's suggestion)
-
On 8/29/2019 at 11:37 PM, Traumflug said:
This is not about the size of the admin.php. As the BO is fully translated the admin.php is complete. So why don't you just apply the fix that Karlo Šimunović has proposed in the above topic at Github. Though this does not help cure the strange behavior of AEUC under 1.1.0, it's a step in the right direction. Anyway, I currently wouldn't recommend 1.1.0 in Germany in production mode.
-
On 5/31/2019 at 11:25 AM, Jonny said:
I found the problem existed on the community theme too, see attached pics. So I guess TB team should take a look and fix it permanently.
Here is a temporary solution to add this code to the hookHeader function in the \modules\advancedeucompliance\advancedeucompliance.php file.
if (Configuration::get('AEUC_FEAT_ADV_PAYMENT_API') && isset($this->context->controller->php_self) && $this->context->controller->php_self=='order' && Tools::getValue('step')==3) $this->context->controller->addJS(_THEME_JS_DIR_.'order-address.js');
Great! Works perfect for 5-Step-Checkout in 1.1.0, too, because this bug is still unsolved.
-
Just for the record:
- What language are we talking about?
- Do parts show up or is everything English in BO?
-
Considering other weird mistakes you've posted lately:
What PHP version do you have?
Are all minimum requirements for thirtybees/Prestashop met?
-
To just change the message would have been my first (and easiest to realise) advice, too. But I would prefer to drop this message completely and display instead a linked iframe with a SMS page containing delivery options.
-
i tested the same for orders with single or several products. The only difference is: I did it on a fresh (and not upgraded) 1.1.0. And with only native modules installed.
-
2 hours ago, RabbitZzZ said:
order slip = credit note
Yep
2 hours ago, RabbitZzZ said:Was it also the one and only product in that same order?
Same result, no matter if one or more products. Testet only with tb 1.1.0.
-
3 hours ago, RabbitZzZ said:
It's not a problem of the stats but merely of having correct accounting. The invoices and order slips have to conform to bank account activity. This is important because of correct tax calculation and everything.
Which they do! But after the refund you find another document - the credit note for refund. This is the proper way to refund or partially refund an order. Neither the original order nor the invoice should be changed for legal reasons. In PrestaShop it's just the same.
6 hours ago, RabbitZzZ said:I have an order which has already been refunded. The partial refund of the products worked but the shop manager forgot to put in the value for the shipping costs I suppose. If we now want to do partial refund again (1 product in the order already completely refunded) and only put in the value in the shipping field and try to save it, we always get the error "The partial refund data is incorrect.".
Must be for some other reason. I cannot confirm the described behavior. I made 2 different partial refunds for he same order (first a product, then the shipping costs) and both worked without any error message. And for each action a correct credit note was generated. This even works if a state Payment refund was added after the first refund.
-
No fix, but a bypass:
- If bigger than 49 Bytes save file /translations/<yourlanguage>/admin.php
- Import the English language
- Go to Employees
- Change BO language to English and save
- Change BO language back to your language and save
- Clear cache and recompile
- If this does not help, check length of /translations/<yourlanguage>/admin.php
- If it is now (emptied to) 49 bytes, replace it with the formerly saved file
This should do the trick, provided that your language is fully translated. Check this at Crowdin.
-
Seems to be even worse. If you clear cache and even import the latest translation files, you will face this issue that the translations are perhaps nearly complete while the whole BO is in English. This even happens for a language like German that provides apart from some minor lacks a full translated thirty bees. This bug is new and first appeared with TB 1.0.1.
-
I wouldn't think it's a matter of the PHP version but a known issue for releases elder than thirty bees Paypal 6.0. The const DEBUG_MODE = 'PAYPAL_DEBUG' was not defined.
-
2
-
-
Seems to refer to a non-existent configuration field in the database. I guess it would help to delete the waste line
Configuration::deleteByName(static::DEBUG_MODE);In function deleteConfiguration() of your paypal.php.
-
2
-
-
1 hour ago, netamismb said:
thank you very much! i've unistall and delete the module cheque - i don't use it anyway.
Anyway, your initial error message had nothing to do with this module. The advice of Traumflug referred to the PHP 7.3 notice on using count() in error.logs.
-
First of all this doesn't seem to be the current release of the cheque module because there is no count() argument in line 66. However, if you meet this error or warning in PHP 7.3, then do this:
- Open the file, in this case cheque.php,
- go to the the questioned line and
- change the expression count to is_countable.
This will help to avoid the message.
That said, let's go to the ERR_EMPTY_RESPONSE, an error known from the Chrome browser. Try this: https://blog.pcrisk.com/windows/12807-err-empty-response
-
1
-
Did you regenerate the thumbnails?
-
1 hour ago, Factor said:
Not sure what AEUC is.
Well, I don't have a clue what your home country is, but just for the record: AEUC (abbreviation for the module advancedeucompliance) is the only way for shop systems like PrestaShop or thirty bees, that are not legally compliant by default, to comply with European law. Without such a module you cannot run TB in European countries, not in France, not in Austria, not in the Netherlands or in my homeland Germany.
1 hour ago, Factor said:Are you asking me to not post issues?
Nope, you got me wrong. Do whatever you think you should. what I wanted to say was just that the focus for current developments should be on issues not yet solved at all.
-
Babysteps, please.
Let them do it one by one. Currently the latest 1.6 PrestaShop module seems to work properly, as @toplakd said. So there is one working module. It's like AEUC with tb 1.1.0. The tb module throws a 500, my own module works properly. That's enough for now, right?
-
8 minutes ago, Factor said:
I see just looked here https://addons.prestashop.com/en/payment-card-wallet/1748-paypal-braintree-official.html
I assume this one.
You better download the convenient module directly from Github: https://github.com/PrestaShop/paypal/tree/1.6.x
-
1.7 modules start with 4.0; currently its 4.0.1
-
2 minutes ago, Factor said:
Occam. I sort of found the same thing. I cant find any definite answer. I suspect refunding doesn't work. Which is a bummer. I wanted to check with everyone before post an issue on GitHub
I guess that the tb module is based on an older release of the PrestaShop PayPal module. Just my 2 cents ...
-
5 hours ago, toplakd said:
I'm using PS Paypal Module 3.11.4 and I was always able to make full refound directly from the store backend by clicking on "Refound total transaction".
Was able to do that when I was on PS and now on Thirtybees. And after refound, the order status is automaticly changed to "Refounded"
Sounds good, I wasn't really aware of that. But for 3.11.4 as for all 3.11x the same applies: that the page structure is noticeably delayed. PayPal does a POST-Request for every page called up. And that for every single page! Result: maybe your shop has a super-fast page structure, but then comes the PayPal request and takes 2-3 seconds.
@Factor You are talking of tb's own Paypal module, whereas 3.11.4 is the PrestaShop native module.
-
Actually this refund thing has been an issue since PrestaShop 1.5. As far as I know the official PayPal module never worked properly when trying to refund, not to mention a partial refund. I presume that similar problems persist in thirty bees's PayPal module.
However, there are other (though a bit expensive) PayPal modules which can handle this. Like e.g.
- the Swiss made https://www.sellxed.com/shop/en/prestashop-paypal-zahlungs-modul.html
- or, much cheaper: https://www.modulebazaar.com/prestashop-paypal-payments-advanced-module/00100086
Alternatively you may use a special refund module like the following, which hopefully is compatible with thirty bees: https://addons.prestashop.com/en/order-management/45387-paypal-automatic-refund-customer-order-cancellation.html
I suppose you mean some kind of development version. A link would be fine.
How to handle returns?
in English
Posted
Sure you can, but given a long list of purchased products a total refund is easier to handle on click. If you would try the same in partial refund mode, you would have to refund every single product.