update

DOCS/TECH_CHANGELOG.md

@@ -1,5 +1,59 @@
 # Tech Changelog
 
+## 2026-04-07 — Phase 79: Personalization Message Field
+
+Rozszerzenie importu personalizacji o pole `message` z API shopPRO.
+
+- **Problem:** ShopPRO API zwraca pole `message` na pozycjach zamowienia (wiadomosc personalizacji klienta, np. dedykacja), ale `extractPersonalization()` sprawdzalo tylko `attributes` i `custom_fields`. Pole `message` bylo ignorowane.
+- **Fix:** `ShopproOrderMapper::extractPersonalization()` sprawdza teraz 3 pola: `attributes`, `custom_fields`, `message`. Pole `message` jest poprzedzone etykieta "Wiadomosc:". Migracja backfill uzupelnila 21 istniejacych pozycji.
+- **Pliki:** `src/Modules/Settings/ShopproOrderMapper.php`, `database/migrations/20260407_000080_backfill_personalization_message.sql`
+
+## 2026-04-07 — Phase 78: Preset Auto Submit
+
+Presety przesylek automatycznie submituja formularz po autofill.
+
+- **Zmiana:** Funkcja `applyPreset()` po wypelnieniu pol formularza (200ms) czeka dodatkowe 300ms i wywoluje `form.submit()`. Dodano `id="shipment-form"` na formularz.
+- **Pliki:** `resources/views/shipments/prepare.php`
+
+## 2026-04-07 — Phase 77: COD Amount Fix
+
+Naprawa automatycznego uzupelniania kwoty pobrania (COD) przy generowaniu przesylki dla zamowien shopPRO.
+
+- **Problem:** Widok `prepare.php` i `OrdersController` sprawdzaly `external_payment_type_id === 'CASH_ON_DELIVERY'` (format Allegro). ShopPRO wysyla pelna polska nazwe np. `"Platnosc przy odbiorze"`, wiec zamowienia shopPRO nigdy nie byly rozpoznawane jako pobraniowe.
+- **Fix:** Nowa centralna metoda `StringHelper::isCodPayment()` z dwupoziomowa detekcja: exact match (CASH_ON_DELIVERY, COD, POBRANIE, ZA POBRANIEM) + keyword match (PRZY ODBIORZE, POBRANIEM, POBRANIE). `ShopproOrderMapper` normalizuje COD na `CASH_ON_DELIVERY` przy nowych importach. Wszystkie hardcoded sprawdzenia zastapione helperem.
+- **Pliki:** `src/Core/Support/StringHelper.php`, `src/Modules/Settings/ShopproOrderMapper.php`, `resources/views/shipments/prepare.php`, `resources/views/orders/show.php`, `src/Modules/Orders/OrdersController.php`
+
+## 2026-04-07 — Phase 76: Shipment Receiver Fallback
+
+Naprawa pustych danych odbiorcy na stronie przygotowania przesylki dla zamowien shopPRO.
+
+- **Problem:** Gdy shopPRO zwraca zamowienie z metoda dostawy (np. "Kurier - przedplata: 0 zl") ale bez osobnego adresu dostawy, mapper tworzyl adres delivery z nazwa metody jako `name` i pustymi polami street/city/zip. `buildReceiverAddress` uzywal tego niekompletnego delivery jako bazy bez fallbacku na dane customer.
+- **Fix:** `ShipmentController::buildReceiverAddress` — rozszerzono fallbacki z customer na pola `street_name`, `street_number`, `city`, `zip_code`, `country` (obok istniejacych `phone`, `email`). Dodano warunek: jezeli delivery nie ma `street_name`, `name` tez jest pobierane z customer (pokrywa przypadek gdy delivery name to label metody dostawy).
+- **Pliki:** `src/Modules/Shipments/ShipmentController.php`
+
+## 2026-04-07 — Phase 75: Pull Status Mapping
+
+Rozdzielenie mapowania statusow shopPRO na dwa niezalezne kierunki: PUSH (orderPRO→shopPRO) i PULL (shopPRO→orderPRO).
+
+**Problem:** Phase 74 usunal UNIQUE na shoppro_status_code, pozwalajac wielu statusom orderPRO mapowac na ten sam kod shopPRO. Logika "first wins" w buildStatusMap() + ORDER BY orderpro_status_code ASC powodowala, ze import zawsze wybieralal alfabetycznie pierwszy status (np. "do_odbioru" zamiast "w_realizacji").
+
+**Rozwiazanie:** Nowa tabela `order_status_pull_mappings` z UNIQUE na `(integration_id, shoppro_status_code)` — dedykowana do pull direction. Push mapping w `order_status_mappings` pozostaje bez zmian.
+
+**DB:** Migracja 20260407_000079 — nowa tabela order_status_pull_mappings, pre-populate z istniejacych danych.
+
+**Ochrona statusu przy re-imporcie:** Re-import z shopPRO nie nadpisuje `external_status_id` istniejacego zamowienia, CHYBA ZE obecny status to `nieoplacone` i shopPRO potwierdza platnosc (`payment_status = 2`). Wtedy status zmienia sie na zmapowany (np. `w_realizacji`) i importowane sa dane platnosci. W kazdym innym przypadku status jest zachowany — orderPRO jest master.
+
+**Pliki:**
+- database/migrations/20260407_000079_pull_status_mappings.sql
+- src/Modules/Settings/ShopproPullStatusMappingRepository.php — nowy repository (listByIntegration, replaceForIntegration)
+- src/Modules/Settings/ShopproIntegrationsController.php — nowa zależność pullStatusMappings, savePullStatusMappings(), buildPullMappingIndex()
+- src/Modules/Settings/ShopproOrdersSyncService.php — buildStatusMap() korzysta z pull tabeli gdy dostępna, activity log dla payment transition
+- src/Modules/Orders/OrderImportRepository.php — ochrona statusu przy re-imporcie, payment transition logic, getCurrentStatus()
+- src/Modules/Cron/CronHandlerFactory.php — wstrzyknięcie ShopproPullStatusMappingRepository
+- resources/views/settings/shoppro.php — sekcja pull mapping pod push
+- resources/lang/pl.php — klucze tłumaczeń pull + zmiana tytułów push
+- routes/web.php — nowa route POST /settings/integrations/shoppro/statuses/save-pull
+
 ## 2026-04-07 — Phase 74: Reverse Status Mapping
 
 Odwrocenie kierunku mapowania statusow w integracjach shopPRO i Allegro.