How taxes calculated for bundle products?

[igoraugustynski]

Hi,
I am facing the following issue:
I have a bundle which contains multiple items (come which cannot be bought separately, so have no price set) priced at 140 euro. I'm applying a discount at checkout od 71 euro, which brings the price down to 69 euro. The issue is with the calculated tax:

            "taxes": [
                {
                    "id": "main",
                    "amount": -12.8033
                },
                {
                    "id": "main",
                    "amount": -12.8033
                },
                {
                    "id": "main",
                    "amount": -12.8033
                },
                {
                    "id": "main",
                    "amount": -12.8033
                },
                {
                    "id": "main",
                    "amount": -12.8033
                },
                {
                    "id": "main",
                    "amount": -12.8033
                },
                {
                    "id": "main",
                    "amount": -6.4918
                },
                {
                    "id": "main",
                    "amount": -6.4918
                },
                {
                    "id": "main",
                    "amount": -6.4918
                }
            ],
            "tax_total": -96.2951,
            "tax_each": -96.2951,

It's below zero, while it should be 23% of 69 euro.

[logeshswell]

@igoraugustynski We'll take a deeper look at this issue and get back to you if I get some updates.

[johnrisby]

This is strange. I'm about to set some bundles up but I presumed we would set the value for the bundle ourselves (ie, we might want to put 12 items together and sell them for 10% less than they would be individually). If we do, the tax is the % of the price we sell it for, not the price of the unbundled items. Are you sure @logeshswell that's how it works, and if so, why?

[ericingram]

Taxes are typically based on the price you sell an item (or bundle) for.

[johnrisby]

@ericingram yes, of course, but say we have 100 items that cost 9.99 each, for instance. So if you buy 12 of them, it would cost 119.88. But then, as a shop, we choose to sell some pre-mixed bundles and charge, say, 109.99 total. That is the product - the bundle. It's priced 109.99, so the tax should be based on the bundle price of 109.99, not on 119.88. Are you saying Swell would calculate it on the 119.88?

[ericingram]

Oops, I assumed you were suggesting the opposite. You're right, the taxes should be based on the price of the bundle and not individual items. If that's happening we'd consider it a bug @logeshswell

[logeshswell]

@igoraugustynski I filed a bug ticket and will keep you posted if I get some updates on the fix.

[johnrisby]

Oops, I assumed you were suggesting the opposite. You're right, the taxes should be based on the price of the bundle and not individual items. If that's happening we'd consider it a bug @logeshswell

I should clarify I've not tried this, I'm going on the discussion above where this is what appears to be being said.

Due to issues with the way the models work* we're creating our own admin backend using PayloadCMS (which we use for other content), so we're also effectively creating our own bundles product type too, so it may not be an issue for me personally - but obviously if it is doing what was originally said, it would need fixing.

• I'll add this here because I don't think it's currently documented so at least someone may find it while searching..? I'm not trying to go off-topic - there's no need for a discussion from my point of view - just wanted to get it documented for others.

The issue is I need to add a custom field to the product model which uses a lookup to show the variants of the product currently being edited.

Last year, when I first looked at this, there was no way to do it and the admin user would have had to select the product (that they were already editing...) before being able to see the variants for that product. Obviously this could lead to errors if the user selected the wrong product.

This was improved when you added the ability to use "parent_id": "{id}" in the custom query, which is a way to look up the currently edited product.

The problem is, I need to do it in a collection field, and when you use that query in a field inside a collection then {id} no longer references the product, but the collection itself - ie {id} is always the id of the current object.

I asked support to ask the developers to add a way to use {parent.id} or {id.id} similar to get around this, but the lack of this feature right now has pushed us to build the custom admin UI. Hopefully something can be added in the future to improve this. Thanks.

[logeshswell]

@igoraugustynski This bug is fixed and deployed at our end. Can you check and confirm please?