




Thanks for reporting this issue. Please add more details to your description of the steps you followed when identifying this. Also provide tax configuration, price and shopping cart display settings and any information which will be helpful to reproduce this issue.
maybe this issue is related to https://github.com/magento/magento2/issues/9929, which could be resolved by commit https://github.com/magento/magento2/commit/ab0f7ef2996d63bac0e520f96140723cc9de92ef
@lfritsche thank you for your report and your update.
Did mentioned commit resolve your problem?
@veloraven I have updated to 2.1.6 where the fix helped. For 2.0.4 I cannot test any more.
Wrong refund is also present in 2.1.7 - this really sucks.


Refund without shipping costs should be clear 20,95 Euros but is 21,55 Euros.
Another bug reported month ago and not solved even in 2.1.9 - i am not shure why bugreuports get so permanently ignored here. 2.1.9 is a security update - really funny with over 2.000 bug reports open here...
@andidhouse reporting problems in closed issues decreases probability of fix even more. Please report a new issue referring to this one.
thanks @orlangur i understand and it makes sense - sry.
But we won´t do it for this any more. Most of the bugs we reported (and there are 100% confirmed bugs like "active navigation class with varnish not working") so far are not solved and only internal tickets are created - some for over 1 year now. So our team does not see any sense on this any more as we do not need solutions in 1-2 years but 1-2 month - and magento proved it is not capable to deliver bugfixes in mid or short time (see the 2.1.9 release - a security release - really???).
Hope you understand.
@andidhouse oki, no problem :) I don't find your attitude really collaborative but anyone definitely have a right to not report bugs. Let's see how the big issues cleanup worked in 6-9 months.
By the way, 2.1.10-preview was created a long time ago and it was known 2.1.9 will be a security release.
@orlangur - we are totally disappointed here of the behavior of the magento team regarding the bug fixing - sry to be harsh sometimes here. Maybe if you see it from a agency / shop owner perspective you understand that more. We (our whole team) began to report bugs here far over 1 year now - others also did.
And most of the bugs are still not fixed at all (indexing problems, wrong calculations, checkout problems etc.etc you name it!) also this are major bugs which cause major problems in the productivity of a commerce shop.
I think the main problem is that a) magento2 has much more bugs then anyone expected and much more then the other comparable systems and b) nothing changes here if you look at new bugs introduced in 2.1.8 - each version introduced new ones.
I am not shure how you see this but i am shure this is a management fail. You have a great system but you do not get it to work properly (and i am not talking about small bugs - just take the big ones mentioned before).
So sry to sound harsh here sometimes but it is frustrating what is going on here since over 1.5 years now.
it was known 2.1.9 will be a security release.
And yet includes a couple improvements not related to security, like logging the exceptions during checkout.
By the way, 2.1.10-preview was created a long time ago
IMHO this just seems to confirm the fact that the current Magento's development cycle is way too slow and isn't capable of providing bugfixes in a timely manner.
@orlangur
reporting problems in closed issues decreases probability of fix even more. Please report a new issue referring to this one.
To be honest, I don't see how posting an extra report of the same bug is speeding things up.
I'd rather see the original issue reopened. If only we had someone with such power nearby :)
@korostii easy: closed issues are not managed at all. The only situation when I think reopening would be useful is when some fix was mentioned in release notes but accidentally not merged into release.
Here you can see that issue is closed by author as upgrade did help (or issue disappeared due to some other reasons). Sometimes even if the issue contains similar scenario but not identical there could be 2+ different bugs.
In a bug report we need steps to reproduce straight from the horse's mouth which can be checked on the latest stable version and adjusted if another behavior occurs on another instance. Reopening an old issue would not bring any value here while opening a new one with relevant steps will definitely lead to bugfix.
UPD: by the way, 9929 is still open but seems to be fixed in 2.2.x only yet. Instead of complaining how buggy 2.1.x is one Community member shared the fix with another Community and it worked. Perfect example of collabotation 👍
I do not think this behavior makes any sense - you can see this now for over 1.5 years - you do not get to manage and fix bugs right in a valid time frame (you can see this here on many tickets - some small issues are solves on a topic and most of the time in a new version the same or a similar issue is introduced again.) - You can check this for nearly any bugs here - just type in for example "indexing", "reindex" - you see this is a permanent issue on all versions so far not solved clean in any version.
So your management should overthink the bug fixing here in principal. A bug should be reported only once here - and if it is fixed it should not be valid again in any new version - (otherwise the whole process makes no sense at all).
Why is it so complicated to have a workflow like this:
I think what we have seen so far here is way far away from productive in any way.
Your team fixes one bug - which causes other new bugs etc.
In my opinion this is a bad management - and you see this here as there are over 2.000 bugreuports not solved - i think this speaks for itself.
Sry i do not agree with you that your process is good - and this is ongoing for over 1.5 years now.