Czy działa z HPOS?

Krótka odpowiedź

Tak, z obydwoma. HPOS i klasyczny zapis oparty na wpisach są obsługiwane równorzędnie i nie ma tu czego konfigurować.

Powód jest konstrukcyjny, a nie sprytny: HPOS przeniósł do własnych tabel zamówienia, a nie pozycje zamówień. Koszt każdej sprzedanej sztuki siedzi na pozycji, czyli w tym samym miejscu w obu układach.

Co naprawdę robi WooCommerce

• Pozycje zostają w woocommerce_order_items i woocommerce_order_itemmeta, niezależnie od trybu zapisu. _cogs_value jest meta pozycji, więc leży w tej samej tabeli u wszystkich.
• Zamówienia są w wc_orders przy HPOS i w posts przy układzie klasycznym. Suma kosztu zamówienia to meta zamówienia, więc trafia odpowiednio do wc_orders_meta albo do postmeta.
• Produkty są wpisami w obu przypadkach, z kosztem w postmeta i kolumną pomocniczą.

Raport musi więc znać tryb zapisu na potrzeby części zapytania dotyczącej zamówień i wcale nie musi go znać na poziomie pozycji — a to na poziomie pozycji siedzi ciekawa liczba.

Co z tym zrobić

Po stronie kosztów: nic. Jeśli jesteś jeszcze na zapisie klasycznym i rozważasz migrację, ta decyzja nie ma nic wspólnego z tym raportem — wartości kosztu nie są przy niej ruszane ani wyliczane od nowa.

Jednej rzeczy warto uniknąć przy każdej migracji: zwrotów i edycji zamówień przy wyłączonej funkcji kosztu. Powód stoi w wyłączeniu funkcji kosztu.

Jak to pokazuje Merchgain

Merchgain deklaruje zgodność z HPOS tak, jak WooCommerce o to prosi (FeaturesUtil::declare_compatibility() na before_woocommerce_init), i buduje zapytanie przeciwko tabeli zamówień faktycznie używanej w Twoim sklepie.

Nie wymaga też modułu Analityki WooCommerce. Analityka trzyma własne tabele pomocnicze, a te nie mają kolumny kosztu w ogóle — więc ten raport pyta wprost tabele zamówień, dzięki czemu działa także w sklepach z Analityką wyłączoną.