Jump to content

Welcome, Guest!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

  • 0
30knees

classes/cart.php TB vs PS 1.6 code - can I replace?

Question

I'm still trying to get the issue at the end of this post fixed. For that, I'd like to replace the code in classes/cart.php TB with the code in PS 1.6. Can anyone see estimate whether it's safe to do so? 

PS 1.6 code via https://github.com/PrestaShop/PrestaShop-1.6/blob/master/classes/Cart.php

TB code via https://github.com/thirtybees/thirtybees/blob/1.1.x/classes/Cart.php

 

Edited by 30knees

Share this post


Link to post
Share on other sites

7 answers to this question

Recommended Posts

  • 0
On 12/13/2020 at 9:10 AM, 30knees said:

Update: Replacing cart.php fixes this bug ... I just don't know whether there might be any other issues that pop up. I think it would be better to pinpoint the problem in cart.php and do a targeted fix.

 

Please don't do that, this is one of the most important part of the code. It's like replacing car engine because your 'Check engine' light is on.

  • Thanks 1

Share this post


Link to post
Share on other sites
  • 0

Update: Replacing cart.php fixes this bug ... I just don't know whether there might be any other issues that pop up. I think it would be better to pinpoint the problem in cart.php and do a targeted fix.

 

Share this post


Link to post
Share on other sites
  • 0

Thank you for the (fun) reply. 🙂 I’m having trouble finding someone who would take the paid time to properly transpose the proper element from the PS cart.php to the tb cart.php. It’s an important element for me - more than just a ‘check engine light’. 😅

Share this post


Link to post
Share on other sites
  • 0

I could look into that, if you could provide exact reprosteps for vanilla installation of thirtybees 1.1.x. I mean what taxes I need to enable, how to create order, etc... 

  • Like 1

Share this post


Link to post
Share on other sites
  • 0

Essentially he wants a constant carrier price with tax included, while the tax rate changes according to the kind of products in the cart.

To reproduce this, one needs products with distinct tax rate (e.g. German VAT with 7% and 19%) and one of each tax rate in the cart. Also, set the carrier to "no taxes". Third, install module AEUC and enable 'Proportionate tax for shipping and wrapping' there. The latter after setting the carrier to no taxes, because this AEUC setting happens to remove the tax selector on the carrier configuration page. This switch in AEUC sets configuration 'PS_ATCP_SHIPWRAP', which changes behavior in quite a number of places in core code.

Current behavior is, carrier price is taken as without taxes, average tax rates of both products get applied on top. Which increases shipping costs seen by the customer. If one increases the number of products with the lower tax rate in the cart, shipping costs get reduced (less increased), due to the lower average tax rate. Increasing the number of products with the higher tax rate accordingly raises shipping costs.

What @30knees expects is to adjust shipping costs without tax according to the calculated average tax rate. This way the customer would see a constant price, while the price recorded in core changes. Certainly possible in theory, but to my understanding all price calculations in core are based on a fixed price without tax, so one would have to overhaul half of core to allow price calculations in the opposite direction.

Perhaps you have some luck and find some magic place to implement this without a dozen overrides 🙂

Share this post


Link to post
Share on other sites
  • 0

Thank you, @Traumflug. But what is the behavior shown on PS 1.6 cart.php if not what I’m looking for? I’d be happy for an explanation instead of a dismissal. 🙂

Share this post


Link to post
Share on other sites
  • 0

An update 

Reverting to PS 1.6 cart.php leads to errors elsewhere, eg a wrong shipping price is displayed during the checkout. So one would need to audit the whole code and it's not clear how much effort that would take. 

Unfortunately, this means that invoices with products that have mixed tax rates will remain non-compliant in Germany. Or you have compliant invoices but you can't tell the customer the gross shipping price in advance because the shipping price is calculated based on the net price and the 'proportional taxes' depend on the exact mix of tax rates resulting from the products in the shopping cart.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...