update

DOCS/ARCHITECTURE.md

@@ -82,6 +82,7 @@
 - `POST /settings/integrations/shoppro/save`
 - `POST /settings/integrations/shoppro/test`
 - `POST /settings/integrations/shoppro/statuses/save`
+- `POST /settings/integrations/shoppro/statuses/save-pull`
 - `POST /settings/integrations/shoppro/statuses/sync`
 - `POST /settings/integrations/shoppro/delivery/save`
 - `GET /settings/accounting`
@@ -337,6 +338,7 @@
   - `ShipmentController::prepare(Request): Response`,
   - laduje uslugi dostawy providerow z `ShipmentProviderRegistry` (aktualnie: `allegro_wza`, `apaczka`),
   - pobiera automatyczne mapowanie formy dostawy przez `CarrierDeliveryMethodMappingRepository` (`source_system` + `source_integration_id` + `order_delivery_method`),
+  - `buildReceiverAddress` laczy delivery + customer z fallbackami: jezeli delivery nie ma ulicy (`street_name`), wszystkie brakujace pola adresowe (name, street, city, zip, country, phone, email) sa uzupelniane z customer,
   - dla dostaw punktowych (`parcel_external_id`/`parcel_name`) prefillem `receiver_name` sa dane klienta (a nie nazwa punktu/metody dostawy),
   - gdy mapowanie nie zostanie znalezione, buduje komunikat diagnostyczny (brak mapowan dla instancji lub brak mapowania konkretnej metody) i przekazuje go do widoku.
 - `POST /orders/{id}/shipment/create`:
@@ -562,6 +564,11 @@
   - zapisuje mapowania per instancja shopPRO przez `ShopproStatusMappingRepository::replaceForIntegration(...)` do `order_status_mappings` (klucz: `orderpro_status_code`).
   - `ShopproStatusMappingRepository::listExternalStatuses(int)` — zwraca liste zewnetrznych statusow shopPRO dla danej integracji.
   - `ShopproIntegrationsController` uzywa `buildMappingIndex()` + `buildExternalStatusOptions()` zamiast poprzedniego `buildStatusRows()`.
+- `POST /settings/integrations/shoppro/statuses/save-pull`:
+  - `ShopproIntegrationsController::savePullStatusMappings(Request): Response`
+  - waliduje CSRF, `integration_id` i kody statusow,
+  - zapisuje mapowania pull (shopPRO → orderPRO) przez `ShopproPullStatusMappingRepository::replaceForIntegration(...)` do `order_status_pull_mappings` (klucz: `shoppro_status_code`).
+  - `ShopproIntegrationsController` uzywa `buildPullMappingIndex()` do zaladowania pull mappings do widoku.
 - `POST /settings/integrations/shoppro/delivery/save`:
   - `ShopproIntegrationsController::saveDeliveryMappings(Request): Response`
   - waliduje CSRF i `integration_id`,
@@ -575,6 +582,7 @@
   - mapuje adres faktury do `order_addresses.address_type=invoice` (firma/NIP/adres) na podstawie pol `invoice`/`billing*`/`firm_*`,
   - mapuje punkty odbioru (`inpost_paczkomat` / `orlen_point`) do adresu `delivery` (`parcel_external_id`, `parcel_name`, ulica/kod/miasto),
   - uzupelnia `delivery` o telefon/e-mail klienta i etykiete metody dostawy z kosztem (`transport_cost`).
+  - `ShopproOrderMapper::extractPersonalization()` buduje personalizacje z pol: `attributes`, `custom_fields` i `message` (wiadomosc klienta z prefiksem "Wiadomosc:").
 - `ShopproStatusSyncService`:
   - uruchamiany z crona (`shoppro_order_status_sync`),
   - obsluguje oba kierunki synchronizacji statusow:

DOCS/DB_SCHEMA.md

@@ -105,6 +105,7 @@ Migracje z prefiksem `ensure_` to migracje kompensujące — zostały dodane
   - indeksy pod filtrowanie po czasie/zdarzeniu/statusie/regule/zamowieniu,
   - seed harmonogramu `cron_schedules` dla joba `automation_history_cleanup` (retencja historii starszej niz 30 dni).
 - 2026-04-04: Hotfix trackingu Allegro Delivery (edge API) - rozszerzono mapowanie statusow EN i fallback keyword matching (`Parcel is awaiting pick-up`, `Parcel has been delivered`, itp.) w warstwie aplikacyjnej; bez zmian schematu bazy.
+- 2026-04-07: Dodano tabele `order_status_pull_mappings` — dedykowane mapowanie pull (shopPRO → orderPRO) z UNIQUE na `(integration_id, shoppro_status_code)`. Migracja `20260407_000079_pull_status_mappings.sql` tworzy tabele i pre-populuje z istniejacych danych push mappings.
 
 ## Tabele
 
@@ -190,6 +191,19 @@ Migracje z prefiksem `ensure_` to migracje kompensujące — zostały dodane
 - Klucze obce:
   - `order_status_mappings_integration_fk`: `integration_id` -> `integrations.id` (`ON DELETE CASCADE`, `ON UPDATE CASCADE`).
 
+### `order_status_pull_mappings`
+- Mapowanie pull statusow shopPRO na statusy orderPRO (kierunek import/pull). UNIQUE na shoppro_status_code per integracja.
+- Kolumny:
+  - `id` (PK, int, AI),
+  - `integration_id` (int, NOT NULL),
+  - `shoppro_status_code` (varchar 100, NOT NULL),
+  - `shoppro_status_name` (varchar 255, nullable),
+  - `orderpro_status_code` (varchar 100, NOT NULL),
+  - `created_at`, `updated_at`.
+- Indeksy:
+  - `order_status_pull_mappings_integration_shoppro_unique` (UNIQUE: `integration_id`, `shoppro_status_code`),
+  - `order_status_pull_mappings_integration_idx` (`integration_id`).
+
 ### `allegro_integration_settings`
 - Konfiguracja OAuth i sync dla integracji Allegro per srodowisko (`sandbox|production`) zarzadzana z `Ustawienia > Integracje > Allegro`.
 - Kolumny:

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.