orderPRO/.paul/codebase/tech_changelog.md

Technical Changelog

2026-05-10 - Phase 115 Plan 01: Wystawianie faktury z zamowienia

Co zrobiono:

• GUS lookup (Task 3b): FakturowniaApiClient::lookupClientByNip() — GET /clients/gus.json?nip=...&api_token=... z walidacja NIP (10 cyfr) i parsowaniem {name, tax_no, street, post_code, city, country}. InvoiceController::gusLookup() jako AJAX endpoint GET /api/fakturownia/gus-lookup?nip=...&config_id=... — resolwer konta Fakturownia (preferuje invoice_configs.integration_id gdy delegated, fallback na pierwsze aktywne konto type='fakturownia'). invoice_form.php ma przycisk "Pobierz z GUS" obok pola NIP — vanilla JS fetch + auto-fill buyer_company_name/street/postal_code/city. Czyni "wystaw fakture" jednoklikowym po wpisaniu NIP. InvoiceController ctor rozszerzony o 2 deps (FakturowniaIntegrationRepository, FakturowniaApiClient).
• InvoiceRepository (nowy) — CRUD dla invoices: findByOrderId, findById, insertLocal, insertDelegated, nextLocalNumber (atomowy INSERT ON DUPLICATE KEY UPDATE na invoice_number_counters), paginate z filtrami search/config/mode/date.
• InvoiceService (nowy) — orchestrator wystawiania:
  • issue() rozgalezia na issueLocal() (numer lokalny + Dompdf-ready snapshot) lub issueDelegated() (POST do Fakturowni PRZED INSERT lokalnym; na sukcesie zapis external_invoice_id/external_pdf_url/invoice_number z odpowiedzi).
  • Static extractBuyerTaxNumber() parsuje NIP z roznych sciezek payload_json (Allegro invoice.address.taxId, shopPRO buyer.tax_number i pokrewne).
  • Snapshot pattern (snapshoty seller/buyer/items z Phase 8 wzorca) + obliczanie netto/brutto z VAT per pozycja.
  • buildFakturowniaPayload() mapuje na format https://app.fakturownia.pl/api.
• InvoiceIssueException (nowy) — typed exception dla bledow biznesowych.
• FakturowniaApiClient rozszerzony — nowe createInvoice() (POST /invoices.json z body {api_token, invoice}, parsuje response na id/number/view_url/pdf_url/raw) i buildPdfUrl() (helper bez fetcha, do redirect 302). Stary stub downloadPdf() zastapiony.
• InvoiceController (nowy) — endpointy dla zamowienia (create, store, show, pdf) i lista issuedList. PDF: lokalna -> Dompdf inline (mirror ReceiptController::pdf); delegowana -> redirect 302 na external_pdf_url. Walidacja invoice_requested=1 przed otwarciem formularza.
• OrdersController::toggleInvoiceRequested (nowy) — AJAX endpoint POST /orders/{id}/invoice-requested/toggle z CSRF + recordActivity('invoice_requested_changed').
• OrdersRepository::setInvoiceRequested(int, bool) (nowy) — UPDATE orders.invoice_requested.
• OrdersController::show() rozszerzone — przekazuje invoices + invoiceConfigs do widoku przez 2 nowe optional ctor params (InvoiceRepository, InvoiceConfigRepository).
• AllegroOrderImportService::importSingleOrder — przy wasCreated=true i payload.invoice.required -> ustawia orders.invoice_requested=1 (delta-only re-import nie nadpisuje manualnej flagi).
• ShopproOrdersSyncService::shouldRequestInvoice() (nowy) — flexible parser sprawdzajacy wants_invoice, invoice_required, invoice.required, buyer.wants_invoice, buyer.invoice w raw payload. Dziala tylko przy pierwszym imporcie.
• 4 nowe widoki:
  • resources/views/accounting/invoice_form.php — formularz wystawiania (config select z label "Lokalnie/Fakturownia: {prefix}", NIP prefilled z payload, manualne nadpisanie buyer fields, podglad pozycji + sprzedawca; confirm dialog dla powtornego wystawienia uzywa OrderProAlerts.confirm z options-object API).
  • resources/views/accounting/invoice_preview.php — HTML preview faktury z badgem trybu (Lokalnie/Fakturownia: {prefix}) + dual-button PDF.
  • resources/views/accounting/invoice_pdf.php — Dompdf template "FAKTURA VAT" z parties section, items table (netto/brutto/VAT per pozycja), termin platnosci, konto bankowe.
  • resources/views/accounting/invoices_issued_list.php — lista wystawionych faktur z filtrami (search/config/mode/date_from/date_to) + paginacja + badge Tryb (Lokalnie / Fakturownia: {prefix}).
• resources/views/orders/show.php — header dostal data-invoice-button-wrap z przyciskiem "Wystaw fakture" (visible tylko gdy invoice_requested=1); pod headerem checkbox data-invoice-requested-toggle (auto-bound przez invoice-requested-toggle.js); pod tabem "Documents" nowa sekcja "Faktury" z badgem Tryb i akcjami Podglad/PDF.
• resources/views/settings/accounting.php — link "Faktury wystawione" w karcie Faktury.
• public/assets/js/modules/invoice-requested-toggle.js (nowy) — vanilla JS, AJAX POST z _token przy change, rollback checkbox state przy bledzie, optimistic show/hide data-invoice-button-wrap. Idempotent guard data-bound.
• resources/views/layouts/app.php — rejestracja invoice-requested-toggle.js z cache-busting.
• 6 nowych routes: POST /orders/{id}/invoice-requested/toggle, GET /orders/{id}/invoice/create, POST /orders/{id}/invoice/store, GET /orders/{id}/invoice/{invoiceId}, GET /orders/{id}/invoice/{invoiceId}/pdf, GET /settings/accounting/invoices/issued. Wszystkie pod AuthMiddleware.
• DI wiring w routes/web.php: InvoiceRepository, InvoiceService, InvoiceController. OrdersController instantiation rozszerzona o 2 params ($invoiceRepository, $invoiceConfigRepository).
• Docs: architecture.md (nowa sekcja "Phase 115"), tech_changelog.md, todo.md (INVOICE-IDEMP-115).

Dlaczego:

• Plan zatwierdzony jako pelny vertical slice — Phase 113 (DB) + 114 (configs CRUD) byly fundamentem; bez wystawiania z zamowienia funkcja byla bezuzyteczna operacjonalnie.
• Kolejnosc "POST do Fakturowni najpierw, INSERT lokalny po sukcesie" (per user decision) gwarantuje ze nie ma orphan rows w invoices gdy API padnie. Trade-off: brak idempotencji przy double-POST -> notatka INVOICE-IDEMP-115.
• Auto-set invoice_requested z importu pozwala operatorowi nie myslec o flagi dla typowych przypadkow (Allegro invoice.required=true, shopPRO klienci wpisujacy NIP). Manualny toggle dla edge cases / korekty.
• Dual PDF flow (Dompdf lokalny / redirect 302 do Fakturowni) — operator dostaje "natywny" PDF z Fakturowni dla delegowanych (ten sam co ksiegowy widzi w Fakturowni), brak ryzyka rozjazdu wygladu/numeracji.
• is_delegated=0 config zachowany jako pelny tryb lokalny — dla scenariuszy gdzie operator nie chce/nie ma konta Fakturowni.

BREAKING: Brak. OrdersController ctor dostal 2 NEW optional params (default null) — backwards compatible.

Szczegolne uwagi:

• invoice-config-form.js (Phase 114) i invoice-requested-toggle.js (Phase 115) — dwa rozne moduly, oba w layouts/app.php. Nazwa "invoice-*" ale rozne kontekstowo (jeden formularz config, drugi zamowienie).
• OrderProAlerts.confirm w invoice_form.php uzywa options-object API zgodnie z memory (Phase 114 fix).
• Migracje no-op nie potrzebne — Phase 113 dostarczyla orders.invoice_requested, invoice_* tabele i fakturownia_integration_settings.
• Skill audit: brak required skills dla tego planu.

---

2026-05-10 - Phase 114 Plan 01: Accounting Configs Refactor

Co zrobiono:

• Migracja 20260511_000107_seed_default_invoice_config.sql - idempotentny seed Domyslny VAT config (format FV/%N/%M/%Y, monthly, lokalna numeracja, payment_to_days=7) przez NOT EXISTS guard.
• InvoiceConfigRepository - pelne CRUD invoice_configs z walidacja serwerowa wszystkich pol + krytyczna regula delegacji: is_delegated=1 wymaga integration_id z integrations.type='fakturownia'. delete() pre-checkuje invoices zeby zwrocic PL komunikat zamiast SQLSTATE.
• InvoiceConfigController - index/edit/save/toggle/delete dla /settings/accounting/invoices. Flash accounting.invoices.save/.error. Edycja na osobnej podstronie.
• ReceiptConfigController refactor - rozdzielenie index() na hub() + list() + nowa edit(). Save/toggle/delete redirectuja na /settings/accounting/receipts (nie hub).
• 4 nowe widoki:
  • accounting.php (REFAKTOR) - hub-rozdroze z 2 kartami Paragony/Faktury (usunieta lista i formularz inline).
  • accounting-receipts.php - lista paragonow w stylu spojnym z fakturami (table.table + badge).
  • accounting-receipt-edit.php - formularz paragonu na osobnej podstronie.
  • accounting-invoices.php - lista faktur (7 kolumn z dodatkami Tryb, Konto Fakturowni).
  • accounting-invoice-edit.php - formularz faktury z conditional integration_id select.
• invoice-config-form.js - vanilla JS toggle dla is_delegated checkbox -> show/hide integration_id select wrapper + dynamiczny required.
• layouts/app.php - rejestracja nowego modulu JS invoice-config-form.js (z cache-busting ?ver=mtime).
• Routy: 12 nowych endpointow ksiegowosci (6 receipts + 6 invoices) + 3 legacy aliasy starych /settings/accounting/save|toggle|delete.
• Docs: db_schema.md (notka o seed), architecture.md (nowa sekcja "Phase 114"), tech_changelog.

Dlaczego:

• Phase 113 dostarczyl tabele invoice_configs - bez UI/CRUD nie da sie operacjonalnie wystawiac faktur. Phase 115 (wystawianie faktury z zamowienia) wymaga gotowych invoice_configs.
• Edycja paragonu pod tabela na /settings/accounting (stary uklad) miala 2 problemy: dlugi scroll przy wielu configach + brak miejsca na rosnacy formularz faktury (z conditional fields). Refaktor na osobne podstrony rozwiazuje oba.
• Seed Domyslny VAT - operator od razu po deployment moze wystawiac faktury bez recznego skonfigurowania (zerowy onboarding).
• Legacy aliasy /settings/accounting/save|toggle|delete - istniejace formularze w cache'u przegladarki / bookmarki / zewnetrzne narzedzia (jesli sa) dalej dzialaja bez 404.
• JS toggle - operator nie zaznaczy delegacji bez wybrania konta (UX + serwerowa walidacja jako backup).

BREAKING:

• Brak. Stare endpointy zachowane jako aliasy. Stary widok /settings/accounting to teraz hub z linkami zamiast listy - operator wie ze trzeba kliknac "Zarzadzaj paragonami".

---

2026-05-10 - Phase 113 Plan 01: Fakturownia Integration Foundation

Co zrobiono:

• Migracje SQL:
  • 20260510_000104_create_invoices_tables.sql - cztery nowe tabele: invoice_configs, invoices, invoice_number_counters, fakturownia_integration_settings (multi-account, integration_id UNIQUE FK -> integrations).
  • 20260510_000105_add_invoice_requested_to_orders.sql - orders.invoice_requested TINYINT(1) NOT NULL DEFAULT 0 + index idx_orders_invoice_requested.
  • 20260510_000106_seed_fakturownia_integration_type.sql - no-op placeholder dokumentujacy uznanie integrations.type='fakturownia' jako oficjalnie wspieranego.
• FakturowniaIntegrationRepository - CRUD kont Fakturowni z resolved encryption (integrations.api_key_encrypted jako zrodlo prawdy, settings.api_token_encrypted jako cache). findAll/findByIntegrationId/save/delete/getDecryptedToken.
• FakturowniaApiClient::testConnection() - GET https://{prefix}.fakturownia.pl/account.json?api_token=... z cURL + SslCertificateResolver. createInvoice/downloadPdf jako STUB-y rzucajace RuntimeException (do implementacji w kolejnym planie).
• IntegrationsRepository::updateTestResult() - nowa publiczna metoda do zapisu last_test_status / last_test_http_code / last_test_message / last_test_at. Wykorzystywana przez FakturowniaIntegrationController::test().
• FakturowniaIntegrationController - lista (/settings/integrations/fakturownia), edycja (/edit, /new), save, test, delete. CSRF via _token, flash fakturownia.save/.test/.error.
• Widoki resources/views/settings/fakturownia.php (lista z badge'ami) i resources/views/settings/fakturownia-edit.php (form: name, account_prefix, api_token, department_id, default_kind, default_payment_to_days, is_active).
• IntegrationsHubController::buildFakturowniaRow() - karta Fakturowni w hubie /settings/integrations z agregowanym statusem wszystkich kont.
• Routy w routes/web.php (get /index, get /new, get /edit, post /save, post /test, post /delete) + DI wiring ($fakturowniaIntegrationRepository, $fakturowniaApiClient, $fakturowniaIntegrationController).
• Dokumentacja: db_schema.md (sekcja "Invoices" + fakturownia_integration_settings + kolumna orders.invoice_requested, total tables 55 -> 59), architecture.md (sekcja "Phase 113").

Dlaczego:

• v3.7 Invoices wprowadza wystawianie faktur dla klientow wymagajacych dokumentu z NIP (clarifications: orders.invoice_requested z importera + manual override). Bez fundamentu DB i konfiguracji konta Fakturowni zaden kolejny plan v3.7 (CRUD configs, wystawianie, lista) nie ma sensu.
• Multi-account przez integrations.type='fakturownia' zachowuje spojnosc z Allegro/shopPRO (rozne instancje) i pozwala na rozne konta Fakturowni dla roznych marek/oddzialow.
• is_delegated flag w invoice_configs umozliwia w przyszlym planie dwa tryby: lokalna numeracja+PDF dompdf (default) lub delegacja do Fakturowni (numer+PDF z API).
• STUB-y createInvoice/downloadPdf celowo rzucaja exception zamiast "TODO" - kazda przedwczesna probaba uzycia rzuci jasny blad zamiast cichego no-op.
• IntegrationsRepository::updateTestResult() jest reusable - przyszle integracje (np. kolejne API) beda mogly korzystac z tej samej metody zamiast inline UPDATE.

BREAKING:

• Brak zmian breaking. IntegrationsHubController ma nowy parametr konstruktora (FakturowniaIntegrationRepository) - wszystkie miejsca wywolania zaktualizowane.

---

2026-05-07 - Phase 112 Plan 01: Re-import Data Protection

Co zrobiono:

• OrderImportRepository::upsertOrderAggregate - rozdzielono sciezke created (pierwszy import) od else (re-import). replaceAddresses, replaceItems, replaceNotes, replacePayments, replaceShipments, replaceStatusHistory wywolywane sa teraz wylacznie przy pierwszym imporcie. Logika paymentTransition / statusOverwriteAllowed (Phase 111) i preservacja status_code (Phase 62) bez zmian.
• OrderImportRepository::updateOrderDelta() - nowa prywatna metoda zastepujaca updateOrder(). Aktualizuje wylacznie status_code, payment_status, total_paid, is_canceled_by_buyer, source_updated_at, payload_json, fetched_at, updated_at. Pozostale kolumny zamowienia nie sa nadpisywane przez re-import.
• Propagacja anulowania: gdy is_canceled_by_buyer=1 ze zrodla LUB zmapowany pull status_code='anulowane' (Phase 75/83), wymuszone jest orders.status_code='anulowane' niezaleznie od statusOverwriteAllowed.
• Identical-payload guard: porownanie znormalizowanego payload_json (nowy vs aktualny w DB). Identyczny payload + brak paymentTransition/statusOverwriteAllowed/cancelledBySource -> commit transakcji bez wywolywania UPDATE; fetched_at i updated_at pozostaja niezmienione.
• OrderImportRepository::getCurrentOrderState() - rozszerzenie getCurrentStatusAndPaymentStatus() o kolumne payload_json (jeden SELECT zamiast dwoch).
• OrderImportRepository::normalizePayloadJson() - nowy helper deserializujacy/reserializujacy payload do porownywalnej formy (JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES).

Dlaczego:

• Bug case #882: po re-imporcie zamowienia produkty w /orders/{id} wyswietlaly badge "Brak projektu" mimo wczesniej wygenerowanych projektow PSD. Przyczyna: replaceItems() wykonywal DELETE+INSERT na order_items przy kazdym re-imporcie, co (a) zerowalo flagi project_generated/project_generated_at (Phase 97) na default 0/NULL i (b) zmienialo order_items.id, co lamie referencje skryptu batch tools/generowanie/_batch_run.sh (UPDATE ... WHERE id IN (...)).
• Phase 111 dodala emisje payment.status_changed przy re-imporcie z tranzycja platnosci, wiec re-import istniejacych zamowien stal sie regularny - problem #882 stal sie regresja systemowa, nie krawedziem.
• Zamowienia (orderPRO jako narzedzie zarzadzania) sa edytowane w aplikacji, nie w zrodle (Allegro/shopPRO). Re-import ze zrodla powinien aktualizowac wylacznie stan platnosci, anulowanie i znaczniki synchronizacji - reszta jest stanem lokalnym.
• Identical-payload guard eliminuje niepotrzebne write'y do binloga/replikacji oraz sztuczne odswiezanie updated_at przy cyklicznym imporcie tych samych zamowien.

BREAKING:

• Brak zmian breaking dla istniejacego API/UI/automatyzacji. Wewnetrznie usunieto updateOrder() i getCurrentStatusAndPaymentStatus() (oba private) - referencje zewnetrzne nie istnialy.
• Backfill zamowien z resetowanymi flagami project_generated (np. #882) wykonywany recznie przez operatora poza zakresem planu.

2026-05-05 - Phase 111 Plan 01: Payment Transition Event

Co zrobiono:

• OrderImportRepository::upsertOrderAggregate - rozszerzona detekcja payment_transition. Teraz porownuje poprzedni payment_status z nowym (warunek 0/1 -> 2) zamiast polegac wylacznie na status_code='nieoplacone'. Logika preservacji status_code z Phase 62 (statusOverwriteAllowed) zostala wydzielona jako osobna decyzja.
• OrderImportRepository::getCurrentStatusAndPaymentStatus() - nowa metoda pomocnicza zastepujaca getCurrentStatus(), zwraca i status_code, i payment_status w jednym SELECT.
• AllegroOrderImportService::importSingleOrder - dodaje emit payment.status_changed gdy payment_transition && !$wasCreated.
• ShopproOrdersSyncService::importOneOrder - analogiczny emit payment.status_changed.
• bin/backfill_payment_transition_111.php - jednorazowy CLI dla zamowien z payment_status=2 && status_code='nieoplacone' (allegro + shoppro), idempotentny, wzorzec z Phase 98.

Dlaczego:

• Zamowienie #864 (Allegro) zaimportowane 10s po zlozeniu, gdy Allegro jeszcze nie potwierdzilo platnosci. Re-import 2 minuty pozniej zaktualizowal payment_status na 2, ale order.imported jest gated przez $wasCreated (Phase 98), wiec automatyzacja "Zmien status na w realizacji (allegro)" nigdy nie odpalila.
• Allegro nie mial odpowiednika ShopproPaymentStatusSyncService, wiec tranzycja platnosci znikala cicho. ShopPRO mial analogiczna luke w ShopproOrdersSyncService (flaga payment_transition byla wykrywana, ale nie emitowala eventu).
• Regula automatyzacji #7 (payment.status_changed -> update_order_status na w_realizacji) nie ma warunku integration_id, wiec po wyemitowaniu eventu obejmie zarowno Allegro jak i shopPRO.
• Idempotencja zalatwiona przez logike repo: po pierwszej tranzycji DB ma payment_status=2, kolejny re-import widzi old=2/new=2 i payment_transition=false. Brak duplikatow eventow.

2026-04-28 - Phase 110 Plan 01: Statistics Summary

Co zrobiono:

• /statistics/summary - nowy widok podsumowania w menu Statystyki -> Podsumowanie.
• OrdersStatisticsController::summary() - buduje miesieczny view-model dla wykresow liczby i wartosci zamowien.
• OrdersStatisticsRepository::aggregateByMonth() - agreguje istniejace zamowienia po miesiacu i kanale/integracji.
• public/assets/js/modules/statistics-summary-charts.js - renderer dwoch interaktywnych wykresow liniowych oparty o Chart.js 4.4.8 CDN.
• resources/views/statistics/summary.php - filtry zgodne z raportem dziennym, dwa wykresy obok siebie na desktopie oraz dwie tabele fallback pod nimi.
• Domyslny poczatek historii ustawiony na 2026-04-01 (04-2026) mimo starszych danych.

Dlaczego:

• Operator potrzebuje szybkiego trendu miesiecznego przed przejsciem do szczegolowych dziennych statystyk.
• Wykresy uzywaja obecnych tabel orders, integrations, order_status_groups i order_statuses, wiec migracja DB nie jest potrzebna.
• Seria Razem jest liczona z tych samych danych co serie integracji, co ulatwia sprawdzenie sum miesiecznych.

2026-04-28 - Phase 109 Plan 01: Checkbox Multiselect Filters

Co zrobiono:

• public/assets/js/modules/checkbox-multiselect.js - nowy vanilla JS enhancer dla natywnych <select multiple data-checkbox-multiselect>.
• resources/views/layouts/app.php - globalne podpiecie modulu z cache busting przez filemtime().
• resources/views/statistics/orders.php - filtry channels[] i status_groups[] oznaczone do progresywnego ulepszenia bez zmiany nazw pol formularza.
• resources/scss/app.scss - kompaktowe style dropdownu z checkboxami i opcja "Wszystkie".

Dlaczego:

• Natywne selecty multiple byly malo czytelne i zajmowaly za duzo miejsca w filtrach statystyk.
• Zachowanie oryginalnego selecta w DOM utrzymuje obecny kontrakt GET i fallback bez JavaScript.
• Brak zmian w schemacie DB i logice agregacji statystyk.

Chronologiczny log zmian technicznych — co i dlaczego.

2026-04-27 — Phase 108 Plan 02: Automation Dropdowns z DB

Co zrobiono:

• AutomationController — usunięto stałą SHIPMENT_STATUS_OPTIONS (8 grupowych kluczy)
• Dropdown statusów w warunku shipment_status i akcji update_shipment_status ładuje statusy z DB przez DeliveryStatus::getAllOptions()
• Walidacja w parseConditionValue() i parseActionConfig() używa DeliveryStatus::getAllStatuses()
• AutomationService — usunięto stałą SHIPMENT_STATUS_OPTION_MAP; ewaluacja evaluateShipmentStatusCondition() porównuje klucze bezpośrednio
• resolveStatusFromActionKey() — bezpośredni klucz statusu z DB jako target (zamiast pierwszego z grupy)

Dlaczego:

• Zamknięcie integracji z Plan 01 — operator dodaje status w /settings/delivery-statuses i jest on od razu dostępny w dropdownach automatyzacji bez deploymentu
• Eliminacja kolizji semantycznej: stary klucz grupowy picked_up mapował na delivered (paczka odebrana przez klienta), nowy klucz DB picked_up to "Odebrana przez kuriera" (od nadawcy)
• BREAKING: stare reguły z grupowymi kluczami (registered, courier_pickup, dropped_at_point, unclaimed, picked_up_return, oraz picked_up/ready_for_pickup/cancelled w starym znaczeniu) nie matchują — wymagają ręcznego odtworzenia z nowymi kluczami DB

2026-04-27 — Phase 108 Plan 01: Delivery Status Management

Co zrobiono:

• Tabela delivery_statuses z seedem 11 statusów (migracja 20260427_000103)
• DeliveryStatusRepository — CRUD + per-request cache
• DeliveryStatus.php — dynamiczne ładowanie statusów z DB (setRepository())
• Panel /settings/delivery-statuses z CRUD (zakładka "Statusy") i mapowaniem (zakładka "Mapowanie dostawy")
• Sidebar: "Statusy" → "Statusy zamówień", nowe "Statusy przesyłek" z badge niezmapowanych
• Badge przesyłek: inline CSS custom property --status-color dla niestandardowych statusów

Dlaczego:

• Dodanie nowego statusu wymagało zmiany kodu + deploymentu; teraz z UI
• Operator może definiować własne statusy znormalizowane bez ingerencji w kod