Bug / Show Stopper: CoD Fee Tax not included in Assigned Tax Group when Invoicing

[winkelsdorf]

Hi,

currently I am testing magento 1.9.1.1 with current mageSetup. I want to use this extension to allow Cash on Delivery only for a single country (Germany).

If I use this extension (from here), the tax is not included correctly in the total taxes. See 1st attached screenshot.

Total Tax should be the same amount as 19% Tax, as CoD is setup to have the same tax class (19%).

The other screenshots show my tax settings.

Any idea?

Regards, Frederik

[winkelsdorf]

Seems to be fixable by setting Tax classes for CoD & Delivery to Item Tax class.

Bug in this extension or magento?

[winkelsdorf]

Still not correct :(

The bug is only visible when creating invoices.. The difference between 23,05 and 22,34 is exactly the tax amount of CoD (0,71 of 4,50).

[winkelsdorf]

This only happens when there is a CoD fee set. Trying to check your code now.

It is only related to the Invoice (probably CreditMemo too), not the Quotes as far as I can see. At least the quotes are right in the backend. But the Invoice Calculation is not when applying a taxed CodFee (incl. tax):

[winkelsdorf]

Sad to see no one takes part in this :( Hopefully people don't get any trouble from using this white spread extensions where tax calc in Invoices is wrong..

[seangreen]

I have exactly the same problem... have you found a solution yet?

[winkelsdorf]

Hi Sean! No, unfortunately not :( Currently this widespread extension is unusable.

[seangreen]

Bummer. Did you find a workaround (e.g. with another extension)? I'm trying extra-fee extensions in combination with the magento built in cash on delivery extension right now, but so far I haven't found a solution that displays all taxes properly...

[winkelsdorf]

No, this is really a bummer :(

My scenario needs to limit the availability of CoD depending on the delivery country, not billing country. Magento defaults to the billing one.

However I didn't find a simple solution yet, or an extensions which handles the above and allows setting of a delivery fee.

[Webmasterei]

Hi Frederik, any solution / workaround? Maybe a good payed extension which is maintained? I only found another free on which is doing things wrong too.

[seangreen]

Hi. I switched to using the multifees extension by MageWorx. Then I used the Magento builtin CoD and added a fee with multifees... I still experienced some tax issues, but the MageWorx support team fixed those for me... don't know, if they added those fixes to the main branch of their extension.

I don't know about limiting the availability of CoD on the delivery country though.. that wasn't relevant in my case.

[Webmasterei]

That's quite a workaround for this bug. Actually I'm still hoping that somebody at Phoenix -Media is reading this thread and fix it.

[seangreen]

Well.. I contacted them and it didn't really seem liek they were going to do that... ;P

[PHOENIX-MEDIA]

You know, Github is all about community and collaboration. It is not our public bug tracker which we work off for free ;-) All pull requests are welcome!

[seangreen]

Yeah, I know... and I can completely understand, that you don't have the time / resources or investment to fix these issues in this extension... but many people that use our extensions (me included) might not have the programming / magento knowhow to fix these issues...

[schmerbeck]

But it´s ok, that the community reports issues? Maybe there´s someone out there who is able to identify the bug easily and make a pull request?

Maybe it´s in the config.xml?

[winkelsdorf]

@schmerbeck: No, I don't believe it's that easy.

My educated guess is that it's related to this PR checked in: https://github.com/PHOENIX-MEDIA/Magento-CashOnDelivery/pull/2

@PHOENIX-MEDIA: Absolutely right, but honestly - as I am providing OpenSource on my own - publishers, especially Companies, benefit from the reputation they get by providing a library which gathers a lot of Users. On the other hand, having a basic functionality failure (or security issue) can damage that reputation as well in no time.

That's always the pity with OpenSource..

Source of knowledge: I am the 2nd link on the OpenSSL.org Binary download page [http://openssl.org/about/binaries.html]. You probably heard of the problems with OpenSSL in 2014 ;)

I have the contrary opinion that GitHub is actually something like a public bugtracker. Not speaking of who is responsible to fix it, but to give other Users/Developers the chance to check for known bugs.

If it's related to PR2 than it's undetected and unfixed for > 1 year. I hope that's not the case. I'll test a previous version of this extension as soon as I have some spare time to spend.

Of course, Unit Testing and Continuous Build help detecting problems with check-ins at an early stage of development.

PHOENIX-MEDIA does not have the time right now to fix it, it may be to expensive to spend unpaid developer working hours on this. That's nothing evil.

But until it's fixed it's probably best to: a) provide a warning on the project front-page https://github.com/PHOENIX-MEDIA/Magento-CashOnDelivery b) let the main blogs and sites, mentioning this as something like an essential extension for magento, know about so others don't spend hours after hours searching the bug somewhere else.

I spent several unpaid hrs until I tracked the error down to this extension.

But again, nothing evil here, it's just an extension which provides some extra functionality which is broken. So don't use this PHOENIX-MEDIA extension is my current fix. Probably I'll check back to the work of PHOENIX-MEDIA in some months or years, for now they don't have the time to fix their bug and I don't have the time to fix other developers bugs.

[PHOENIX-MEDIA]

This issue is not a roadblock, it is a minor issue when generating invoices in Magento.

But @winkelsdorf, I personally like the discussion. Because it is about "who is able and willing to give development resources". This extension is around for more than five yours now and maintained by us since early Magento days. Our focus is currently on Magento 2 and the question "which Magento 1 modules will make it in the Magento 2 world?". Of course we will continue to invest in Magento 1 where it make sense, but it is not our primary concern. And regarding reputation: As company we gave a lot to the community for free, more than many others including Gold partners. Blaming us for minor bugs which we currently don't have a focus on has nothing to do with reputation, it is simply a way to beg for our attention. The other truth in this topic is: one is not able to fix it, the other one does not want to fix it. But both of them are not willing to invest here (e.g. pay someone (not us!) to fix it and contribute a fix) and this is IMHO today's problem of Open Source. Everyone is using it and is expecting others work (for free) on the project but no one wants to spent a dime to improve a product they rely on.

This is off topic and just my 2 cents. Don't feel personally offended, it is a general observation I've made in several comments on our modules on different platforms which just make me sad.

Cheers Björn Kraus CTO @ PHOENIX MEDIA

PS: I'll assign the ticket to our backend team to analyze the issue - not to improve our reputation, just to demonstrate that if someone is willing to get an issue fixed there is always a way to do that, without much noise, just #realmagento.

[schmerbeck]

The assumption that no one here is willing to pay for a solution is wrong. At least in my case. But i always wonder, why the community is that silence in case of Magento. Are there really only four person who are in trouble with this specific issue (at nearly 50.000 downloads)?

Thank you Björn for your PS

[seangreen]

Well.. I would have been willing to pay to... I actually contacted your team regarding a paid solution of this bug... but I really didn't know of anybody else who would have known enough of this extension to create a fix in a realistical amount of time...

[winkelsdorf]

@PHOENIX-MEDIA Hi Björn,

Thank you very much for your response! I really appreciate this. Sorry that I didn't have the time to answer earlier due to personal reasons, not meant as ignorance or something like that.

I want to take the time to answer your response fully, not at least as a respect to you and your work.

This issue is not a roadblock, it is a minor issue when generating invoices in Magento.

Technically this is not a roadblock, correct. It's easy to work around by disabling, if you know which extensions is responsible. Probably even easy to fix technically for your team. But from a (limited) but educated legal point of view generating Invoices with incorrect tax sums is the worst case for a ordering and invoicing system. Due to my work I am not only thinking of the technical parts of a problem. That lead to my statement. For a short overview of the current legal situation in Germany please see: http://www.haufe.de/finance/steuern-finanzen/rechnungsberichtigung-umsatzsteuer-falsch-ausgewiesen-was-tun_190_129472.html

To sum it up: Despite the consequences for the invoice creating company, a (corporate) recipient of an invoice may only reduce it's own tax amount by the value exactly stated on the invoice.

But @winkelsdorf, I personally like the discussion. Because it is about "who is able and willing to give development resources". This extension is around for more than five yours now and maintained by us since early Magento days. Our focus is currently on Magento 2 and the question "which Magento 1 modules will make it in the Magento 2 world?".

Yeah, that's probably something for a very interesting small talk :) Good catch, that's what I meant that the error somehow slipped it: It's a long existing extension which some code history. I still believe that the functionality this extension aims to provide is really helpful for some stores. Probably a good candidate for the Magento 2 world as well.

Of course we will continue to invest in Magento 1 where it make sense, but it is not our primary concern.

Duly noted. Neither as OpenSource developer nor speaking for a Corporation it's always possible to support newest and oldest technologies at the same time. It might lead to a huge investment of time and money where those projects have to be cut at some point.

A small but: If the technology is the very current one it should be supported if the project is still alive. Magento 1 (in versions 1.8x./1.9.x) is what is supposed to be used as of the time of writing the above, May 2015. Except for developer / merchant betas now.

Otherwise a Repo can always be marked as abandoned or not longer supported by it's developers. That's what I said. For the sake, It just could have been marked as defective or broken, so others don't invest as much time as I did.

And regarding reputation: As company we gave a lot to the community for free, more than many others including Gold partners. Blaming us for minor bugs which we currently don't have a focus on has nothing to do with reputation, it is simply a way to beg for our attention.

Well it was a good discussion until that line. You probably noted that smiley when I spoke about gaining and loosing reputation quickly with the example mentioned, OpenSSL, which affected me as well.

From your point of view that's a minor bug, from the above mentioned non-technical point of view it's not minor. Period.

Sum up: This extension currently breaks tax handling and leads to wrong Invoices with possible tax legal consequences. What else is needed to make a major bug in an Magento extension? Database corruption is a good candidate ;)

Regarding your "beg for attention", to make it clear: No, I am surely not begging for your attention. That's not what I have to do after being 20 years in this Business ;)

A beg for attention would require that I am in need for a fix. To be honest, I don't care if it's fixed anymore. Should I, after 7 months from my report?

I was just ranting about not accepting this bug (GH labels) and mentioning in the places where Users can obtain that component: GH and magento Extensions page. That's also a way the community works: If you know about, mention it. Don't let others do the same over and over again. Even a one liner in a FAQ would be better than the current situation.

The other truth in this topic is: one is not able to fix it, the other one does not want to fix it. But both of them are not willing to invest here (e.g. pay someone (not us!) to fix it and contribute a fix) and this is IMHO today's problem of Open Source. Everyone is using it and is expecting others work (for free) on the project but no one wants to spent a dime to improve a product they rely on.

Absolutely right and fully agreed. Example: I'd taken care of another crypto component for the past 8 years and despite the confirmed use in a couple of top fortune 500 companies and inside of other 3rd party sold (!) database libraries only 2 paid support requests were made and a smaller, negligible donation received (less than 20 USD). Again, this leads to a more philosophical discussion about OpenSource and the common behavior of people taking for free but not giving back.

I cannot comment on others mentioning that they tried to get paid support from your company.

This is off topic and just my 2 cents. Don't feel personally offended, it is a general observation I've made in several comments on our modules on different platforms which just make me sad.

I do fully understand, as I am sitting in the same boat. Just a bit offended by this "beg for attention" thing ;) If you had a look at my GH profile you would have seen that I contribute to many repositories a lot (not limited to Magento repos, but Cask/HomeBrew, PHP, JS, ObjC and Swift libraries). I try to help where I can when I stumble about errors or problems. Many times with PRs.

Regarding this error I was unable to fix it, due to the lack of knowledge of it's source. What I usually do in those cases is to report it to the developer with as much and detailed information as possible. Been working for a software development language creator I know that these steps are essential, i.e. Category, Priority, Steps to Reproduce, affected areas etc.

GH is about collaboration, so a technical feedback from the developer within a few months would have been nice, but again in turn that's not always the case or possible.

PS: I'll assign the ticket to our backend team to analyze the issue - not to improve our reputation, just to demonstrate that if someone is willing to get an issue fixed there is always a way to do that, without much noise, just #realmagento.

Thank you. But again I do understand it had low priority for you and your company before. Again the noise was more about just about accepting the bug and warning/mentioning about it now, where appropriate, which is still not done yet. That's too bad :(

I don't think a single GH issue with less roughly a dozen comment's is noise at all. If you ever had to deal with people from marketing and social media support that's nothing like a small note ;)

I mentioned before:

Of course, Unit Testing and Continuous Build help detecting problems with check-ins at an early stage of development.

I don't know the internals of your development cycle but I think it may help to keep up the good quality by allowing automated builds and tests on your own components? Continuous build and integration are really great for that. Using a test case, done in e.g. PHPUnit, parsing the information used to generate the invoice pdf, the commit creating that bug would have never slipped through for such a long time. If it's really related to PR #2 that's 2 years now, which is quite long for a 5 year old component.

But I don't know if the CI/Testing is something usually done when developing for Magento. Probably over sized.. Again something for a smalltalk. Feel free to contact me directly if clarification is needed or wanted.

tl;dr The bug seems to be reproducible for others. PHOENIX MEDIA team is going to work on it/already working on it. Others are welcome to send in PR with fixes and contribute.

Cheers, Frederik

[possi]

Just FYI. I came across a similiar issue: https://github.com/magespecialist/MSP_CashOnDelivery/issues/7 Which I blame a Magento-Bug for.

[PHOENIX-MEDIA]

Fixed.