chore: move TODO to .paul/codebase/todo.md
This commit is contained in:
@@ -1,43 +1,3 @@
|
|||||||
# TODO — odlozone zadania techniczne
|
# TODO
|
||||||
|
|
||||||
> Lista nieformalnych zadan do zrobienia pozniej. Kazdy wpis ma wlasny tag (np. `STAT-NET`) zeby mozna go bylo zlinkowac z komentarzy w kodzie.
|
> Przeniesione do `.paul/codebase/todo.md`
|
||||||
|
|
||||||
## STAT-NET — netto zamowien w statystykach (data: 2026-04-19)
|
|
||||||
|
|
||||||
### Kontekst
|
|
||||||
- Statystyki `/statistics/orders` pokazuja `Netto` per dzien/kanal.
|
|
||||||
- shopPRO nie wysyla kwoty netto ani na poziomie zamowienia (`orders.total_without_tax`), ani produktow (`order_items.original_price_without_tax` — rowniez puste).
|
|
||||||
- Allegro: `orders.total_without_tax` rowniez moze byc puste.
|
|
||||||
- Obecnie dziala fallback: netto = `ROUND(total_with_tax / 1.23, 2)` gdy kolumna netto jest pusta/zerowa. Zaklada 23% VAT dla wszystkich.
|
|
||||||
|
|
||||||
### Zadania
|
|
||||||
1. **Ustalic zrodlo prawdy dla netto**:
|
|
||||||
- Sprawdzic, czy API shopPRO udostepnia `price_netto` lub `total_netto` (payload zawiera tylko `price_brutto` + `vat`).
|
|
||||||
- Jesli TAK → rozszerzyc mapping importu (`src/Modules/ShopPro/...`) i backfill migracja dla historycznych rekordow.
|
|
||||||
- Jesli NIE → liczyc netto deterministycznie z `order_items.original_price_with_tax` i `order_items.tax_rate` (wtedy nie zakladamy sztywno 23%).
|
|
||||||
2. **Backfill historycznych zamowien** po wdrozeniu zrodla netto (migracja SQL + idempotentny skrypt).
|
|
||||||
3. **Zastapic fallback /1.23** w `OrdersStatisticsRepository::netAmountSql()`:
|
|
||||||
- Preferuj `orders.total_without_tax`.
|
|
||||||
- Jesli brak — `SUM(order_items.original_price_with_tax / (1 + order_items.tax_rate / 100) * order_items.quantity)`.
|
|
||||||
- Stala 1.23 tylko jako ostateczny fallback przy braku item-levelu.
|
|
||||||
|
|
||||||
### Linki w kodzie
|
|
||||||
- `src/Modules/Statistics/OrdersStatisticsRepository.php` — metoda `netAmountSql()` (komentarz `TODO(STAT-NET)`).
|
|
||||||
|
|
||||||
## DELIVERY-STATUS-MGMT — zarządzanie statusami znormalizowanymi z panelu (data: 2026-04-26)
|
|
||||||
|
|
||||||
### Kontekst
|
|
||||||
- Aktualnie statusy znormalizowane (`created`, `confirmed`, `picked_up`, `in_transit`, itd.) są stałymi w kodzie (`DeliveryStatus.php`).
|
|
||||||
- Dodanie nowego statusu wymaga zmiany kodu + deploymentu.
|
|
||||||
- Panel ustawień pozwala tylko mapować surowe statusy kurierów na istniejące statusy znormalizowane — nie można dodać nowego znormalizowanego statusu z UI.
|
|
||||||
|
|
||||||
### Zadania
|
|
||||||
1. Wynieść listę statusów znormalizowanych do tabeli DB (np. `delivery_statuses`) z kolumnami: `key`, `label_pl`, `color`, `sort_order`, `is_terminal`, `is_system`.
|
|
||||||
2. Statusy systemowe (`delivered`, `returned`, `cancelled`) oznaczać flagą `is_system = true` — nieedytowalne z UI (mają specjalne znaczenie w kodzie).
|
|
||||||
3. Panel `/settings/delivery-statuses` — CRUD dla statusów niebędących systemowymi (dodaj, zmień etykietę/kolor, usuń jeśli nieużywany).
|
|
||||||
4. `DeliveryStatus::ALL_STATUSES`, `LABEL_PL` i badge CSS zastąpić dynamicznym ładowaniem z DB (cache per-request).
|
|
||||||
5. Automatyzacje i mapowania kurierów — dropdown statusów znormalizowanych pobierany z DB zamiast hardcoded.
|
|
||||||
|
|
||||||
### Uwagi
|
|
||||||
- `TERMINAL_STATUSES` musi zostać zachowane jako lista systemowych statusów końcowych — te nie powinny być usuwalne.
|
|
||||||
- Przy usuwaniu statusu znormalizowanego — blokada jeśli używany w `delivery_status_mappings` lub `shipment_packages.delivery_status`.
|
|
||||||
|
|||||||
43
.paul/codebase/todo.md
Normal file
43
.paul/codebase/todo.md
Normal file
@@ -0,0 +1,43 @@
|
|||||||
|
# TODO — odlozone zadania techniczne
|
||||||
|
|
||||||
|
> Lista nieformalnych zadan do zrobienia pozniej. Kazdy wpis ma wlasny tag (np. `STAT-NET`) zeby mozna go bylo zlinkowac z komentarzy w kodzie.
|
||||||
|
|
||||||
|
## STAT-NET — netto zamowien w statystykach (data: 2026-04-19)
|
||||||
|
|
||||||
|
### Kontekst
|
||||||
|
- Statystyki `/statistics/orders` pokazuja `Netto` per dzien/kanal.
|
||||||
|
- shopPRO nie wysyla kwoty netto ani na poziomie zamowienia (`orders.total_without_tax`), ani produktow (`order_items.original_price_without_tax` — rowniez puste).
|
||||||
|
- Allegro: `orders.total_without_tax` rowniez moze byc puste.
|
||||||
|
- Obecnie dziala fallback: netto = `ROUND(total_with_tax / 1.23, 2)` gdy kolumna netto jest pusta/zerowa. Zaklada 23% VAT dla wszystkich.
|
||||||
|
|
||||||
|
### Zadania
|
||||||
|
1. **Ustalic zrodlo prawdy dla netto**:
|
||||||
|
- Sprawdzic, czy API shopPRO udostepnia `price_netto` lub `total_netto` (payload zawiera tylko `price_brutto` + `vat`).
|
||||||
|
- Jesli TAK → rozszerzyc mapping importu (`src/Modules/ShopPro/...`) i backfill migracja dla historycznych rekordow.
|
||||||
|
- Jesli NIE → liczyc netto deterministycznie z `order_items.original_price_with_tax` i `order_items.tax_rate` (wtedy nie zakladamy sztywno 23%).
|
||||||
|
2. **Backfill historycznych zamowien** po wdrozeniu zrodla netto (migracja SQL + idempotentny skrypt).
|
||||||
|
3. **Zastapic fallback /1.23** w `OrdersStatisticsRepository::netAmountSql()`:
|
||||||
|
- Preferuj `orders.total_without_tax`.
|
||||||
|
- Jesli brak — `SUM(order_items.original_price_with_tax / (1 + order_items.tax_rate / 100) * order_items.quantity)`.
|
||||||
|
- Stala 1.23 tylko jako ostateczny fallback przy braku item-levelu.
|
||||||
|
|
||||||
|
### Linki w kodzie
|
||||||
|
- `src/Modules/Statistics/OrdersStatisticsRepository.php` - metoda `netAmountSql()` (komentarz `TODO(STAT-NET)`).
|
||||||
|
|
||||||
|
## DELIVERY-STATUS-MGMT — zarzadzanie statusami znormalizowanymi z panelu (data: 2026-04-26)
|
||||||
|
|
||||||
|
### Kontekst
|
||||||
|
- Aktualnie statusy znormalizowane (`created`, `confirmed`, `picked_up`, `in_transit`, itd.) sa stalymi w kodzie (`DeliveryStatus.php`).
|
||||||
|
- Dodanie nowego statusu wymaga zmiany kodu + deploymentu.
|
||||||
|
- Panel ustawien pozwala tylko mapowac surowe statusy kurierow na istniejace statusy znormalizowane - nie mozna dodac nowego znormalizowanego statusu z UI.
|
||||||
|
|
||||||
|
### Zadania
|
||||||
|
1. Wyniesc liste statusow znormalizowanych do tabeli DB (np. `delivery_statuses`) z kolumnami: `key`, `label_pl`, `color`, `sort_order`, `is_terminal`, `is_system`.
|
||||||
|
2. Statusy systemowe (`delivered`, `returned`, `cancelled`) oznaczac flaga `is_system = true` - nieedytowalne z UI (maja specjalne znaczenie w kodzie).
|
||||||
|
3. Panel `/settings/delivery-statuses` - CRUD dla statusow niebedacych systemowymi (dodaj, zmien etykiete/kolor, usun jesli nieuzywany).
|
||||||
|
4. `DeliveryStatus::ALL_STATUSES`, `LABEL_PL` i badge CSS zastapic dynamicznym ladowaniem z DB (cache per-request).
|
||||||
|
5. Automatyzacje i mapowania kurierow - dropdown statusow znormalizowanych pobierany z DB zamiast hardcoded.
|
||||||
|
|
||||||
|
### Uwagi
|
||||||
|
- `TERMINAL_STATUSES` musi zostac zachowane jako lista systemowych statusow koncowych - te nie powinny byc usuwalne.
|
||||||
|
- Przy usuwaniu statusu znormalizowanego - blokada jesli uzywany w `delivery_status_mappings` lub `shipment_packages.delivery_status`.
|
||||||
Reference in New Issue
Block a user