Kompatibilität mit PDF Invoice Plugin von WP Overnight

@vendidero thanks for responding. I am the plugin author of WooCommerce PDF Invoices & Packing Slips.

You are referring to the tax amounts and tax rates, but the issue (and non-compliance) is not with that data, but the fact that you are using compound tax rates based on a partial excluding-tax amount that is not stored anywhere in the order data (the code you are linking to is the function responsible for calculating the tax amounts, but do you also have a function for retrieving the ex-tax amounts for each rate?)

Taking the example from your documentation:
https://vendidero.de/dokument/steuerberechnung-fuer-versandkosten-und-gebuehren

The resulting line item in the order data only contains the ex-tax amount (€4,40) and the two tax amounts plus rates (€0,14 / 7% and €0,45 / 19%). But the ex-tax amounts that below to those taxes (€1,99 / €2,41) are not stored in the order data anywhere. This is the “Tax base” that @hempion1 is referring to in their question.
The WooCommerce “standard” that I am referring to (e.g. how WooCommerce applies multiple compounding rates normally) is that the tax is normally always calculated from the entire ex-tax amount of the line item.So in the example of a 7% and 19% rate applied to a €4,40 price, it would result in 4.40 * 7% = €0.308 plus 4.40 * 19% = €0.836 and an including tax total of €5.544.
I fully understand that’s not how the split taxes works fiscally, but in your current implementation, the order ends up with data missing to verify the calculation. To comply with the WooCommerce ‘standard’, you should store the tax rates and amounts as separate line items (since they are not true compounding taxes) so that all data is present and all regular tax calculations can be applied. Taking the same example: instead of one line 4.40 + 0.14 + 0.45, you would end up with two lines 1.99 + 0.14 / 2.41 + 0.45. Then all the data is there and if you still want to present this as one single line to the customer you can simply add the data.

Calculating backwards from the percentage and tax amount is not an option, taking rounding settings into account and also defeats the point of storing the taxes amounts in the first place (after all, you could calculate everything, theoretically).

these split taxes are not compound taxes as compound taxes are applied one after another and split taxes are applied at once by splitting up the total amount into separate pieces.

Exactly, this is what I was referring to and where your implementation is diverging from the WooCommerce “standards”.

compatibility issues with fee and shipping plugins

Could you elaborate on this? WooCommerce already offers adding multiple shipping lines per order out of the box. In my opinion this is the solution that offers the most all-round compatibility because it doesn’t require any third party to read plugin specific item meta.

• This reply was modified 2 years, 9 months ago by Ewout.

Woo does support multiple tax rates/amounts per item that’s why I guess it is not against the standard.

If you add 2 tax rates to a line item and let WooCommerce calculate the taxes, it will use the entire ex-tax amount to calculate the amount:

• If the tax rate is set to compound, it will calculate the second tax amount on top of the first (so 5.00 => 20% = 1.00 (subtotal 6.00) => 10% = 0.60 => total = 6.60)
• If the tax rate is NOT set to compound, it will calculate them separately ( 5.00 => 20% = 1.00 and 10% = 0.50 => total = 6.50).

In both cases all the data to verify the calculations is present in the line items.
Your plugin does custom calculations to override this behavior and the data it uses to make these calculations is not stored.

Excellent, that certainly helps! Just to confirm: this is under the assumption that a single tax class would never have more than one rate, correct? (Because that’s actually how you normally setup multiple rates for a product in the first place: a single tax class with multiple rates, with distinctive priorities).
I’m asking because you’re storing the share and taxable amount per tax-class rather than per rate (ID).

@vendidero excellent, I can definitely work with that. Thank you so much for the swift action and providing this data!