Magento 2 FPT Discrepancy: Unpacking Configurable Product Tax Mismatches on Invoices

Magento 2 FPT Discrepancy: Unpacking Configurable Product Tax Mismatches on Invoices

As e-commerce migration experts at Shopping Mover, we often encounter complex challenges within the Magento ecosystem. One recurring theme is the intricate nature of tax calculations, especially when dealing with product types like configurable products. A recent GitHub issue (Issue #41266) sheds light on a critical bug affecting Fixed Product Tax (FPT) for configurable variants, leading to significant financial discrepancies on invoices and impacting payment gateway integrations.

The Core Problem: FPT Missing from Invoice Grand Total

The issue, reported on Magento 2.4.9 (and later confirmed on 2.4-develop), describes a scenario where the FPT amount for configurable product variants is not correctly added to the invoice's Grand Total. While the FPT amount is listed in the admin panel, its exclusion from the Grand Total creates a mismatch between the order's total and the actual paid amount. This results in an erroneous "Total Due" in financial systems, causing headaches for finance departments and suggesting customers have underpaid, even when the correct amount was processed by the Payment Service Provider (PSP).

The original reporter, DuckThom, initially traced the issue to vendor/magento/module-weee/Model/Total/Invoice/Weee.php. The problem appeared to be that the code was incorrectly using the configurable parent $orderItem instead of the specific variant for FPT getters, causing them to return zero. A potential immediate workaround was suggested:

if ($orderItem->getProductType() === \Magento\ConfigurableProduct\Model\Product\Type\Configurable::TYPE_CODE) {
    $children = $orderItem->getChildrenItems();

    if ($children) {
        $orderItem = reset($children);
    }
}

This snippet aims to ensure the FPT calculation correctly targets the child variant's data rather than the parent configurable product's data.

A Deeper Dive: The FPT Double-Counting Conundrum

Further investigation by the community member revealed an even more complex layer to this FPT bug. When Magento's tax configuration has "Display X: Including Tax" options enabled, particularly affecting how totals are displayed, the FPT amount can be doubled on both the order and invoice. This happens within functions like getTotalAmounts and getBaseTotalAmounts in vendor/magento/module-weee/Helper/Data.php.

The root cause lies in how these functions iterate through order items. For a configurable product with a variant, the loop counts both the configurable parent line and its associated simple product variant line. When getRowWeeeTaxInclTax($item) is called, it can effectively read and sum the FPT data twice – once for the parent (which aggregates child data) and once for the child itself. This leads to an inflated FPT display (e.g., $2 instead of $1), causing discrepancies not only in the admin panel but also in data sent to payment gateways like Klarna, which then expects an incorrect Grand Total.

Community Collaboration and Issue Confirmation

The thread highlights the importance of precise reproduction steps in debugging Magento issues. Initially, the Magento engineering team struggled to reproduce the bug. However, after DuckThom provided highly detailed steps, emphasizing the crucial tax display settings and the specific action of adding a configurable product (not a simple one) to the order, the issue was finally reproduced and confirmed by the Magento team. This back-and-forth underscores how nuanced Magento's core logic can be and how vital community input is for identifying and resolving such intricate bugs.

Impact for Merchants and Developers

This FPT bug for configurable products is more than just a display error; it's a critical financial inaccuracy that can disrupt accounting processes and lead to failed payment authorizations or reconciliation issues with PSPs. For merchants relying on accurate tax reporting and seamless payment flows, this bug presents a significant challenge. Developers working with Magento 2.4.x, especially those involved in migrations or custom tax implementations, should be aware of this confirmed issue and consider its implications for their clients' financial operations and integrations. While a full official fix is pending, understanding the underlying mechanism is the first step towards implementing robust workarounds or ensuring proper testing of tax configurations.