core/packing — kosze, zbieranie i pakowanie

Stałe kosze konfiguruje kierownik. Automat przydziela do nich zamówienia przez kontrakty hooków. Nie tworzy nowych koszy. Zbieranie jest osobnym etapem od pakowania: potwierdzenie produktu w turze nie zwiększa packedQty w zamówieniu.

Konfiguracja i kolejność

Kierownik dodaje, edytuje i usuwa kosze na stronie „Kosze magazynowe”. Konfiguracja obejmuje nazwę, instancję źródła zamówień, katalog lokalizacji, opcjonalną instancję obsługi przesyłek, status zamówienia, wykluczone SKU, limit zamówień, przedział masy zamówienia i maksymalną masę kosza. Każda instancja jest wybierana jawnie, również przy kilku kontach tego samego modułu. Brak dostawcy nie powoduje powrotu do RPC ani wybrania pierwszej odpowiedzi. Zmiana źródła zamówień odświeża tylko listę statusów. Nazwa, limity, wykluczenia SKU i pozostałe wybory pozostają w formularzu, także przy błędzie pobierania statusów.

Grupie pracowników (np. „Zbieracz”) nadaj uprawnienie packing.collect („Zbieranie produktów do koszy”). To wystarcza do otwarcia widoku i zbierania; nie ma rejestracji, dyżuru ani dodatkowego przycisku. Gotowe kosze są wspólną kolejką dla uprawnionych pracowników. Rozpoczęcie tury rezerwuje wybrane kosze wyłącznie dla pracownika, który ją rozpoczął. Odebranie uprawnienia blokuje kolejne operacje. Historyczny rejestr zbieraczy nie jest już używany.

Widoki zachowują nawigację, nagłówek, motyw i standardowe kontrolki Orbito. Lokalny CSS obejmuje wyłącznie układ zawartości modułu, bez nadpisywania aplikacji.

Maski wykluczeń wpisuje się w osobnych wierszach. * oznacza dowolny ciąg, ? jeden znak. Dopasowanie obejmuje całe SKU i ignoruje wielkość liter. Pozostałe znaki są dosłowne; nie jest wykonywany dowolny regex użytkownika. Wykluczenie SKU produktu lub składnika zestawu wyklucza całe zamówienie.

Masa jest sumą mas fizycznych pozycji pomnożonych przez ilości, z jednokrotnym rozbiciem zestawów. Brak masy uzupełnia katalog. Brak masy lub miejsca magazynowego blokuje przydział i jest widoczny kierownikowi jako błąd synchronizacji. Przedział masy jest lewostronnie domknięty: [od, do). Limit masy kosza jest włącznie.

Kosze mają zapisaną kolejność FIFO. Zamówienia, od najstarszych, trafiają do pierwszego pasującego kosza, który ma wolną pojemność. Nie są rozdzielane między kosze. Wyczerpanie limitu liczby zamówień albo osiągnięcie limitu masy zamyka kosz do zbierania. „Tolerancja wagi kosza” w konfiguracji modułu obniża próg zamknięcia wszystkich koszy w tej instancji modułu: dla limitu 100 kg i tolerancji 0,5 kg kosz jest gotowy od 99,5 kg. Domyślnie wynosi 0 kg; nie zwiększa dopuszczalnej masy kosza. Niepełny kosz można zamknąć ręcznie. Zamówienie, które nie mieści się w pozostałym limicie masy, jest sprawdzane względem następnych koszy.

Konfigurację zmienia się po opróżnieniu kosza. Kosz można usunąć w każdym statusie, z zachowaniem historii. Usunięcie kosza podczas zbierania anuluje całą jego turę; pracownik odkłada produkty z tej tury, a pozostałe kosze wracają do napełniania. Nieuzgodnione nadania pozostają zapisane z aktywną rezerwacją zamówienia także po ukryciu kosza, bez ponowienia wysyłki. Kosz gotowy do zbierania można ponownie otworzyć przed rozpoczęciem tury.

Przepływ pracy

Pusty → Napełnianie → Do zebrania → Zbieranie → Zebrany → Pakowanie → Pusty

1. Automat uruchamia się przy starcie, następnie domyślnie co 5 minut. Interwał

od 1 do 1440 minut ustawia się w konfiguracji modułu, w bloku automatycznego przydzielania zamówień do koszy. Worker odczytuje ustawienie co 30 sekund, bez restartu. Pełny interwał liczy się od zakończenia poprzedniego przebiegu. Synchronizacja ma osobną blokadę workera i pobiera dane bez blokowania operacji użytkownika. Zapisy chronią wyłącznie zmieniane kosze i turę, bez wspólnej blokady całej listy. Krótkie zapisy sprawdzają ponownie stan i konfigurację kosza. Odczyt dostawcy ma limit 5 sekund, przebieg budżet 45 sekund, a większe listy są kontynuowane od zapisanego miejsca w kolejnym przebiegu.

1. Gotowy kosz tworzy trwałe powiadomienie dla uprawnionych zbieraczy. Powiadomienia

są wewnątrz modułu. Po zapisie emitowany jest hook event:packing.baskets.changed z { instanceId }, rozsyłany przez WebSocket platformy. Dashboard nasłuchuje zmian własnej instancji i aktualizuje tylko dane, zachowując wyszukiwanie, zaznaczenia i otwarty formularz. Nie odpytuje okresowo serwera. Synchronizacja emituje jedno zdarzenie po całej zapisanej partii; sam odczyt nie emituje zmian. Błąd wysłania zdarzenia jest logowany i nie zmienia wyniku ukończonej operacji.

1. Zbieracz zaznacza w tabeli wolne kosze z zamówieniami (do 50 na turę),

także niepełne. Przyciskiem „Zbieraj” w nagłówku rozpoczyna zbieranie. Powstaje zapisany plan produktów, posortowany alfabetycznie po miejscu magazynowym z wybranego katalogu. Wspólne SKU w tej samej instancji katalogu i lokalizacji są sumowane. Jeśli ma rozpoczętą turę, może zaznaczyć jej kosze i wrócić do tego samego planu przyciskiem „Zbieraj”.

1. Responsywny widok pokazuje jeden produkt: miejsce, nazwę, SKU, EAN, sumę i

ilości do każdego kosza. „Umieszczono w koszach — dalej” potwierdza cały podział. Zamknięcie strony nie gubi postępu. Powtórzony request nie potwierdza kolejnej pozycji.

1. PDF korzysta z tego samego zapisanego planu. Samo pobranie dokumentu nie zmienia

postępu. Zmiana pozycji lub statusu zamówienia podczas tury blokuje potwierdzenie.

1. Po potwierdzeniu ostatniej pozycji kosze są „Zebrane”. Pakowacz przypisuje

kosz do siebie. Serwer sprawdza zarówno stan kosza, jak i właściciela każdej operacji.

1. Zachowany ekran pakowania obsługuje kolejkę zamówień, EAN, ilości, notatki,

adres, zdjęcia, nadanie i własną etykietę. Niepewne nadanie jest uzgadniane z rejestrem przesyłek, bez automatycznego powtarzania efektu.

1. Po nadaniu wszystkich zamówień zamykana jest partia, a fizyczny kosz wraca

pusty na koniec kolejki. Nieuzgodnione nadania blokują zwolnienie.

Brak produktu na półce: zbieracz pozostawia bieżący produkt niepotwierdzony i wraca do tury po uzupełnieniu towaru. Nie rejestrujemy częściowego zebrania ani rezerwacji stanu magazynowego. Zmiany zamówienia wymagają wyjaśnienia przed kontynuacją; tura nie podmienia po cichu już wydanego planu. Można anulować niezakończoną turę po fizycznym opróżnieniu koszy i odłożeniu produktów. Kosze wracają wtedy do napełniania, a nowa tura wymaga ponownego zebrania produktów.

Na stanowisku pakowania klawisze ← / → wybierają poprzednie lub następne zamówienie z bieżącej listy. Skrót nie działa podczas edycji pól lub adresu dostawy ani w otwartym oknie dialogowym. Spacja wykonuje bieżący krok pakowania.

Dane i kontrakty

W konfiguracji modułu, w bloku „Tryb testowy”, opcja „Zdjęcie testowe bez kamery” pozwala testować krok zdjęcia bez urządzenia. Jest domyślnie wyłączona. Po włączeniu i odświeżeniu stanowiska spacja lub „Zrób zdjęcie testowe” zapisuje obraz PNG z wyraźnym oznaczeniem testowym przez zwykły kontrakt zdjęcia zamówienia. Obowiązują uprawnienia pakowacza, przypisanie kosza, komplet produktów i kontrola aktualnej zawartości zamówienia. Po testach wyłącz opcję i odśwież stanowisko. Zdjęcie testowe pozostaje w historii zamówienia; kolejne kroki działają normalnie.

Nowe kolekcje: packing_collection_baskets, packing_collection_cycles, packing_collection_flows, packing_collection_sessions, packing_collection_notices, packing_collection_state. Unikalne aktywne przypisanie ma klucz (ordersInstanceId, orderId). Zapisane plany zawierają powiązania z koszami i partiami oraz odciski zawartości zamówień.

Wykorzystane kontrakty:

• orders.workflow.searchOrders, orders.workflow.getOrder, orders.workflow.listStatuses;
• products.resolveBySkus;
• orders.workflow.adjust, orders.packing.packAll, orders.workflow.scan,

orders.workflow.addPhoto, orders.workflow.updateDelivery, orders.workflow.updateStaffNote;

• shipping.getQuickShipOptions, shipping.ship,

shipping.shipments.getByOrderId, shipping.shipments.createManual.

Każde wywołanie korzysta z lokalnego hook-contract.js i zapisanej instancji odpowiedniego dostawcy. Instancja obsługi przesyłek musi być skonfigurowana do obsługi tego źródła zamówień; moduł nie zgaduje relacji między kontami.

Publiczne metody konfiguracji: baskets.config, baskets.save, baskets.delete, baskets.close, baskets.reopen, baskets.sync. Zbieranie: collection.start, collection.state, collection.next, collection.cancel, collection.pdf. Pakowanie: baskets.claim, baskets.release oraz dotychczasowe metody work.*.

Uprawnienia: packing.view (widoki), packing.collect (zbieranie), packing.work (pakowanie), baskets.manage (konfiguracja koszy).

Dane poprzedniej wersji

Starsze kolekcje są zachowane, bez automatycznej migracji i zgadywania instancji źródłowych. Dashboard informuje o starszych koszach. Identyfikatory zamówień z aktywnych starszych przypisań są konserwatywnie wyłączone z nowego automatu. Przed publikacją należy dokończyć stare partie w dotychczasowej wersji albo przygotować jawną migrację, wiążącą je ze zweryfikowanymi instancjami dostawców. Sam build nie oznacza aktualizacji działającej instancji.

Sprawdzenie lokalne

npm run build:pages
npm test
node --test --test-concurrency=1 --test-force-exit ../module-contracts/*.test.js

test/preview.cjs uruchamia lokalny podgląd z atrapami hooków, bez zapisów do produkcyjnego API. Wymaga Chrome, Playwright z runtime Codex oraz bieżącego bundla OVE w tmp/ove-preview.js i store/event-bus wyciętych z odpowiadającego mu pliku aplikacji w tmp/ove-store-preview.js. Wykorzystany renderer: index-CA1NQraF.js. Sprawdza natywny formularz oraz widoki desktop, 390 px i 320 px. Obrazy kontroli są zapisywane w ignorowanym test/artifacts/.

Zamówienia spakowane poza stanowiskiem

Zdarzenie event:order:packed oznacza do odświeżenia tylko aktywne przypisanie danego zamówienia w instancji wskazanej przez uwierzytelniony kontekst hooka. Osobny proces łączy serię zdarzeń i pobiera stan przez orders.workflow.getOrder; zapisuje wyłącznie informację „Już spakowane” oraz podsumowanie. Przydział kosza, postęp tury, zdjęcie i próba nadania pozostają pod kontrolą pracownika. Niedostarczone zdarzenia nadrabia okresowa synchronizacja, a odłożone odświeżenia są przechowywane w bazie.

Lista na stanowisku odświeża się bez przebudowy formularza. W zbieraniu pominięte zamówienia nie zwiększają ilości do pobrania ani listy PDF. Zmiana ilości wymaga ponownego potwierdzenia aktualnego widoku, bez przesuwania bieżącego produktu. Produkty już odłożone dla spakowanego zamówienia należy odłożyć osobno lub zwrócić na miejsce. Ponowne otwarcie pominiętego zamówienia wymaga weryfikacji fizycznej zawartości kosza.

Ręczne zgłaszanie problemów jest usunięte. Wcześniejsze zgłoszenia nie blokują pakowania. Folder „Do sprawdzenia” obejmuje wyłącznie nieuzgodnione nadania; sprawdzenie przesyłki nie powtarza operacji o niepewnym wyniku.