Stany w jednostkach bazowych produktu (szt./kg — wg karty produktu). Wartość magazynu = ilość × koszt nabycia z karty produktu (netto, waluty po NBP). Dokumenty magazynowe są ilościowe; koszty partii z PZ (cena zakupu + transport) trzymane osobno, tylko dla admina i administracji. Pozycje PZ z ceną tworzą partie FIFO — sprzedaż konsumuje je po kolei i rentowność każdego zamówienia liczy koszt jego konkretnych partii (bez uśredniania; karta produktu = tylko fallback i wycena stanów). Korekta stanu: dokument INW — dokumentów się nie kasuje. Od V535 dostawy zdejmują stan automatycznie (dokument WZ-AUTO/<FR> przy statusie „Dostarczone", z pozycji faktycznie wydanych) — ręczne WZ tylko dla wydań poza zamówieniami, żeby nie zdejmować dwa razy.

🚗 Magazyn podręczny (bagażnik) — osobisty magazyn handlowca/dostawcy. Tworzony automatycznie przy dodaniu nowego użytkownika z rolą handlowiec/dostawca; dla istniejących utwórz poniżej. Towar do bagażnika wjeżdża dokumentem MM (przesunięcie z magazynu głównego). Handlowiec widzi swój bagażnik w swoim panelu (Konto → 📦 Mój bagażnik).

Gdy jeden handlowiec jest na urlopie/L4, drugi może obsługiwać jego klientów. Zastępstwo działa w wybranym zakresie dat. Klienci nie zmieniają opiekuna, ale zastępca widzi ich w swoim panelu i może składać zamówienia/wizyty w ich imieniu. Konwersja i statystyki nadal liczą się oryginalnemu opiekunowi.

Kierowca na urlopie? Wyznacz zastępcę (innego dostawcę lub handlowca) na wybrany zakres dni. Niezrealizowane dostawy z tych dni zostaną przepisane na zastępcę, awizacja go nazwie, a gotówka pójdzie na jego konto. Zastępca-handlowiec loguje się do panelu dostawcy (/dostawca.html) — ma tam pełną optymalizację trasy. Zastępstwo kończy się samo w dniu „do".

Wprowadzaj miesięczne koszty per handlowiec (pensja, samochód, paliwo, inne). Na podstawie tych danych CRM liczy profit = marża sprzedaży − koszty − próbki dla każdego handlowca. Brak wpisu → 0 zł, fallback do poprzedniego miesiąca.

Wpisz stawkę godzinową, premię dzienną (za rozpoczęcie dniówki), premię sobotnią oraz koszt 1 km (paliwo + amortyzacja razem). System liczy koszt całego dnia jako: (loadedAt → deliveredAt + 1h) × stawka + km × stawka/km + premie, a potem dzieli proporcjonalnie do liczby punktów dostawy. Liczbę km dla danego dnia możesz wpisać w karcie zamówienia (pole dayDistanceKm) lub pozostawić 0.

Handlowcy wybierają typ lokalu z tej listy przy dodawaniu nowego klienta. Pomaga segmentować bazę (kawiarnia/restauracja/hotel...) i analizować sprzedaż per typ.

Handlowcy wybierają rolę osoby kontaktowej z tej listy (Właściciel/Manager/Barista/Kucharz...). Listę można rozszerzać o role specyficzne dla branży klientów.

⚠ Akcja masowa, nieodwracalna. Używaj gdy handlowiec odchodzi/zmienia rejon. Wszyscy jego klienci zostaną przepisani do drugiego handlowca. Statystyki historyczne pozostają u oryginalnego opiekuna; nowe wizyty i zamówienia są przypisywane do nowego.

Fundament planera tras handlowców (v501): zasysanie punktów POI (restauracje, hotele, sale zabaw…) z Google Places do naszej bazy. Codzienny planer (v502) będzie czytał wyłącznie z naszej bazy — zero wywołań Google przy generowaniu tras. Zwiad ma twardy miesięczny limit wywołań poniżej darmowego progu Google — po jego osiągnięciu sam się zatrzymuje (koszt: 0 zł). Punkty pokrywające się z istniejącymi klientami dostają status klient (nie trafią do planera), sieciówki z listy wykluczeń — status wykluczony. Zamknięte na stałe lokale są pomijane.

Serie numeracji jak w Optimie: symbol + format per typ dokumentu. Tokeny formatu: NNNN = licznik (liczba N = szerokość zer), MM = miesiąc, RRRR/RR = rok, SYMBOL = symbol serii. Reszta znaków (np. /) dosłownie. Typ dokumentu bez aktywnej serii numeruje się po staremu — nic się nie zmienia, dopóki nie skonfigurujesz.

💡 FV z datą wsteczną / osobna pula: nie zmieniaj formatu istniejącej serii w trakcie roku (jest blokowany po pierwszym użyciu) — dodaj nową serię z własnym symbolem, ustaw ją jako domyślną, wystaw dokument, przełącz domyślną z powrotem.
ℹ Numer zamówienia FR/RRRR/MM/NNNN oraz WZ do zamówienia (pochodna numeru FR) są systemowe i nie podlegają konfiguracji.

Listy Typów lokali (Kawiarnia, Restauracja...) oraz Ról kontaktu (Właściciel, Manager, Barista...) są edytowalne w sekcji Zespół. Tam też zarządzasz substytucjami i kosztami handlowców/dostawców.

Magazyny służą do grupowania produktów przy planowaniu załadunku kierowcy (jeden kierowca, jeden magazyn).

Firmy transportowe do obsługi dostaw paletowych przez Transport Zewnętrzny. Kinga wybiera przewoźnika z tej listy podczas planowania dostawy. Domyślną cenę można zmienić per zlecenie.

System automatycznie wysyła maile do klientów: T-1 (gdy oryginalny termin >3 dni), T+2, T+7, T+14, oraz 4b dzień po przedłużonym terminie, T+30 wezwanie, T+45 ostateczne przedsądowe. Scheduled o 7:00 codziennie.

Codziennie o 02:00 pełny snapshot CRM (Firestore + pliki Storage) ląduje w buckecie foodoro-crm-backups (jurysdykcja UE). Rotacja: 30 dziennych / 12 tygodniowych / 24 miesięczne. Niezależnie działają: PITR (cofnięcie bazy do 7 dni), Delete Protection i managed backupy Firestore.

Koszty produktów i koszt próbek przeniesione do osobnej kolekcji product_costs (widzą i edytują admin + Kinga; handlowiec/klient nie widzą). Po wgraniu tej wersji uruchom obie migracje raz (są bezpieczne, idempotentne — można klikać wielokrotnie; masz backupy/PITR). A domyka wyciek z produktów, B z historycznych zamówień i wizyt.

Z tej skrzynki lecą: potwierdzenie zrealizowanej dostawy do klienta (lista produktów, zdjęcia, kto odebrał, podpis, kwota; przy gotówce — kwota + imię i nazwisko dostawcy) oraz ostrzeżenie do administracji, gdy klient nie ma adresu e-mail (handlowiec + Kinga).

Wpływają na szacowany czas trasy u dostawcy. Czas jazdy liczy Google (free-flow, bez korków); poniżej ustawiasz postoje. Trasa liczona jest: dom → magazyn(y) → klienci → powrót do domu.

Kategorie tworzą drzewko o dowolnej głębokości, np. Kawa › Ziarna › Brazylia › Świeża. Przy każdej kategorii użyj „+ podkategoria" aby dodać poziom niżej. Struktura może być rozszerzana również z poziomu dodawania produktu.

Klient B2B nie widzi liczby dostaw. Gdy na dany dzień jest już zaplanowanych tyle dostaw kierowcą (bez anulowanych, bez samoodbioru/przewoźnika/„ja dostarczam"), dzień świeci mu się na czerwono i nie da się na niego zamówić dostawy kierowcą. Handlowca i Kingi limit nie blokuje — oni widzą obłożenie.

Adres, który klient dostaje w mailu z linkiem do ustawienia hasła i jako powrót po ustawieniu hasła. Domyślnie https://crm-foodoro-v2.web.app/klient.html. Po podpięciu własnej domeny (np. https://panel.foodoro.pl) wpisz ją tutaj — musi być też dodana w Firebase Auth → Authorized domains, inaczej link wróci na adres domyślny.

Wybierz kierowcę, do którego będą automatycznie trafiały nowe zamówienia od klientów (z limitu lub gotówką). Zamówienia na przelew (oczekujące na płatność) NIE są przypisywane automatycznie — przypisują się dopiero po zaksięgowaniu wpłaty przez Kingę/Admina.

Co to robi: jednorazowo naprawia historyczne niespójności w bazie:

1. Anulowane zamówienia z niezamkniętymi fakturami — gdy zamówienie ma status „Anulowane", ale powiązana proforma/FV nadal ma status unpaid (i świeci na czerwono w panelu Kingi).
→ Naprawa: faktury zostaną oznaczone jako cancelled z notatką „Backfill v256 — zamówienie było anulowane".

2. Faktury VAT wystawione mimo opłaconej proformy — gdy klient zapłacił proformę, a Kinga potem wystawiła FV (która jest unpaid mimo, że klient już zapłacił = podwójne księgowanie długu).
→ Naprawa: FV zostanie oznaczona jako paid ze źródłem „proforma-coverage-backfill" i odwołaniem do proformy.

Bezpieczeństwo: przed wykonaniem zobaczysz listę dokumentów do naprawy i potwierdzasz. Wszystko jest logowane do payments_audit (kolekcja zawierająca historię zmian; nadaje się do rekonstrukcji w razie potrzeby).

Co to robi: naprawia bug który był aktywny do v257 — automatyczne wystawianie FV ze strony CRM.

Mechanika buga: przycisk „📅 FV zbiorcze miesięczne" (Kinga / Admin) generował automatycznie numer FV w formacie FV/YYYY/MM/NNNN (CRM-owy) i zapisywał invoice w bazie BEZ pytania o numer KSeF. Gdy Kinga potem wgrywała PRAWDZIWĄ FV z KSeF do tego samego klienta — powstawały 2 dokumenty w bazie:
• CRM-owy duplikat (np. FV/2026/05/0001) z generatedBy: 'kinga_monthly_batch'
• Prawdziwy z KSeF (np. 189/05/2026/REST) z generatedBy: 'kinga_manual_v170'

Identyfikacja duplikatów: CRM-owy FV uznajemy za duplikat gdy istnieje INNA paid/unpaid FV od Kingi (manual) z tym samym clientId i pokrywającymi się aggregatedOrderIds.

Naprawa:

• CRM-owy duplikat → cancelled z reason „Backfill v258 — duplikat CRM zastąpiony FV z KSeF"
• Zamówienia (orderIds) → fvInvoiceId przepisany na prawdziwą FV z KSeF
• Log w payments_audit z pełną informacją (ID duplikatu, ID prawdziwej, numer, klient, kwota)

OD v258 nie powstają nowe duplikaty — przycisk „FV zbiorcze miesięczne" teraz otwiera modal kolejkowy, w którym Kinga wpisuje numer KSeF dla każdego klienta osobno.

Co to robi: przed v261 funkcja deleteOrderHard NIE usuwała powiązanych proform. Skutek: po trwałym usunięciu zamówienia jego proforma wisiała w bazie jako unpaid — klient widział ją jako zaległość mimo że zamówienia już nie ma.

Identyfikacja sierot:

• Proforma (type zaczyna się od proforma) z status: 'unpaid'
• orderId wskazuje na nieistniejące zamówienie LUB orderId wskazuje na zamówienie z status: 'Anulowane'

Naprawa: proforma → status: 'cancelled' z reason "Backfill v261 — zamówienie nie istnieje / anulowane". Log w payments_audit.

OD v261 nowy bug nie powstaje — deleteOrderHard teraz automatycznie anuluje powiązane proformy.

Co to robi: historyczny problem do v261: gdy Kinga wystawiała FV do zamówienia z istniejącą proformą, proforma zostawała unpaid mimo że to księgowo to samo. Klient widział 2 dokumenty do zapłaty, choć to jedna kwota. Limit kredytowy źle liczony.

Logika:

• Proforma unpaid + istnieje FV dla tego samego zamówienia → zamknij proformę
• Jeśli FV jest paid → proforma też paid (pokryta przez FV, fv-coverage)
• Jeśli FV jest unpaid → proforma superseded (zastąpiona, klient ma teraz płacić FV)

OD v262 nowy bug nie powstaje — przy każdym wystawieniu FV (Kinga + admin) proformy są automatycznie zamykane.
Plus przy płatności gotówkowej przy dostawie (CF) — analogicznie.