Mam koszty w innej wtyczce. Dlaczego raport pokazuje braki?

Krótka odpowiedź

Bo te koszty siedzą tam, gdzie trzyma je tamta wtyczka — we własnych polach meta albo, w przypadku ATUM-a, we własnej tabeli — a ten raport czyta pole rdzenia WooCommerce. Inne miejsce, inne nazwy, zero części wspólnej.

Wtyczki kosztowe są starsze od pola rdzenia o lata — rdzeń dostał swoje dopiero w WooCommerce 10.3, na przełomie 2025 i 2026 — więc każda wymyśliła własne. Sklep, który prowadzi koszty od 2019 roku, ma je w całkiem innym miejscu.

Co naprawdę robi WooCommerce

Pole rdzenia to _cogs_total_value na produkcie i _cogs_value na pozycji zamówienia. Ta druga część jest tym, czego żadna wtyczka nie dorobi wstecz: wpisuje ją rdzeń w chwili sprzedaży, i to właśnie czyni z niej zapis historyczny, a nie odczyt dzisiejszej ceny.

Wtyczka trzymająca koszty we własnej meta ma zwykle tylko stronę produktu. To wystarczy, żeby policzyć marżę wobec dzisiejszego kosztu, i nie wystarcza, żeby powiedzieć, ile naprawdę zarobiły zamówienia z zeszłego marca.

Co z tym zrobić

Przeniesienie wartości do pola rdzenia jest odpowiedzią trwałą i jest zapisem do sklepu, więc tak to traktuj:

1. Upewnij się, co znaczy wartość w tym polu — netto czy brutto, za sztukę czy za pozycję. Miejsca używane przez te wtyczki są wypisane na stronie niżej; swój i tak warto sprawdzić.
2. Przepisz go do pola rdzenia skryptem ze strony przeniesienie kosztów z innej wtyczki — czyta cudze pola, pokazuje, co by zapisał, zanim cokolwiek zapisze, i wypisuje produkty, przy których dwie wtyczki się nie zgadzają, zamiast wybierać za Ciebie.
3. Zostaw dane starej wtyczki. Nic nie zyskujesz na ich usunięciu, a to Twój jedyny zapis tego, jakie te koszty były.
4. Pamiętaj, że zapisany koszt będą miały tylko zamówienia złożone po przepisaniu. Migracja naprawia przyszłość, nie historię.

Opcjonalny import z podglądem zmian jest rozważany na później. Nic w tej sprawie nie jest obiecane, dopóki nie zostanie wydane.

Jak to pokazuje Merchgain

Merchgain szuka tych pól, liczy produkty i nazywa wtyczkę, która je trzyma, nazwą, jaką ta sama sobie nadaje: Cost of Goods: Product Cost & Profit Calculator for WooCommerce, WooCommerce Cost of Goods, ATUM Inventory Management for WooCommerce, Booster for WooCommerce, BjornTech PayPal POS integration for WooCommerce, Ni Cost of Goods for WooCommerce i Cost Of Goods For WooCommerce. Widać to w ostrzeżeniu o brakujących kosztach, obok listy produktów. Pusty raport przestaje być zagadką.

Robi to od wersji 0.2.2; Boostera, BjornTech PayPal POS i ATUM-a znajduje dopiero od 0.2.4. ATUM to luka warta nazwania: wcześniejsze wersje szukały go w polu produktu, do którego ATUM przestał pisać w 2018 roku, kiedy przeniósł dane do własnej tabeli.

Liczy je. Nigdy z nich nie liczy — i to się nie zmieni. Dwa powody, przy czym drugi jest tym prawdziwym:

• nie wie, które pole jest właściwe. Trzy wtyczki kosztowe w historii sklepu to trzy pola, często sprzeczne i żadne z datą;
• liczba, której nikt nie może sprawdzić, jest gorsza niż luka. „Koszt jest znany dla 74% przychodu” da się zweryfikować na liście produktów. „Koszt jest znany, z jednego z pięciu możliwych pól” nie da się sprawdzić nikomu, nam też.

Policzyć to nie to samo, co policzyć z tego: jedno mówi, gdzie są Twoje dane, drugie stawia na ekranie liczbę, której nie masz jak sprawdzić.