Jeśli rozważasz uruchomienie aplikacji Kod kreskowy w Odoo albo właśnie kupiłeś terminale i pierwsze testy idą opornie — ten artykuł jest dla Ciebie. Opisujemy, co realnie zmienia skanowanie w magazynie, jak Odoo odbiera dane ze skanera i gdzie najczęściej zaczynają się schody. Bo w praktyce problem prawie nigdy nie leży w Odoo.
Co właściwie daje aplikacja Kod kreskowy
Kod kreskowy to osobna aplikacja w Odoo, zaprojektowana pod pracę jedną ręką, na ekranie terminala, w ruchu. Nie jest to ten sam interfejs co magazyn na komputerze — to uproszczony widok pod operatora, który ma rękawicę i mało czasu.
Co zyskujesz po uruchomieniu:
- Przyjęcia i wydania bez klawiatury — operator skanuje lokalizację, produkt i ilość, zamiast wyszukiwać pozycje z listy.
- Kontrola przy kompletacji — system nie pozwala wydać produktu spoza dokumentu, więc pomyłka wychodzi na miejscu, a nie u klienta.
- Inwentaryzacja w trakcie pracy — spis z natury bez zamykania magazynu i bez papierowych arkuszy przepisywanych wieczorem.
- Numery partii i serii — skanowane razem z produktem, dzięki czemu identyfikowalność powstaje sama, a nie w Excelu obok.
- Stany w czasie rzeczywistym — dokument zamyka się w momencie fizycznej operacji, nie kilka godzin później.
Efekt biznesowy jest zwykle ten sam: mniej pomyłek w wysyłce, krótsza inwentaryzacja i stany magazynowe, którym zarząd zaczyna ufać.
Jak Odoo „słyszy" skaner
Tu jest sedno całej sprawy i źródło większości problemów.
Terminal magazynowy nie przesyła kodu do Odoo żadnym specjalnym kanałem. Skaner udaje klawiaturę. Po zeskanowaniu „wpisuje" zawartość kodu znak po znaku, tak jakby ktoś bardzo szybko stukał w klawisze, a na końcu dodaje Enter. Odoo nasłuchuje zdarzeń klawiatury, składa z nich ciąg znaków, a Enter traktuje jako sygnał „koniec kodu, przyjmij i czekaj na następny".
Z tego wynikają dwa warunki, które muszą być spełnione jednocześnie:
- Skaner musi wysyłać pojedyncze zdarzenia klawiszy, a nie gotowy blok tekstu.
- Na końcu musi pójść Enter.
Gdy którykolwiek z nich nie jest spełniony, Odoo nie ma z czego złożyć kodu — mimo że na terminalu wszystko wygląda poprawnie.
Objaw, który zgłasza się najczęściej: „trzeba strzelić dwa razy"
Operator celuje w kod, skaner piszczy, na ekranie nic. Drugi strzał w ten sam kod działa. I tak przy każdej pozycji.
Przy kilkuset liniach dziennie to nie jest drobiazg. To podwojony czas kompletacji i operator, który po tygodniu wraca do kartki.
Przyczyna jest zwykle jedna: skaner wrzuca cały kod jednym blokiem, korzystając z mechanizmu wprowadzania tekstu Androida, zamiast wysyłać osobne zdarzenia klawiszy. Odoo dostaje wtedy zdarzenie, które nie niesie żadnego znaku. Pierwszy skan jedynie ustawia kursor w polu. Dopiero drugi trafia inną drogą i zostaje przyjęty.
Na terminalach Zebra odpowiada za to aplikacja DataWedge — warstwa pośrednicząca między skanerem a aplikacją. I to w niej, nie w Odoo, leży rozwiązanie.
Pięć pułapek konfiguracji, które kosztują najwięcej czasu
1. Profil, którego aplikacja w ogóle nie używa
DataWedge przypisuje aplikacje do profili. Aplikacja, której nie ma na liście powiązanych aplikacji żadnego profilu, trafia na profil domyślny. Można wtedy godzinami poprawiać starannie przygotowany profil, który nie ma najmniejszego wpływu na to, co się dzieje.
Zanim zaczniesz cokolwiek zmieniać — ustal, który profil faktycznie obsługuje przeglądarkę i aplikację Odoo.
2. Jedno ustawienie to za mało
W dokumentacji przewija się jeden parametr odpowiadający za wysyłanie znaków jako zdarzeń klawiszy. To prawda, ale niepełna. Obok niego stoją jeszcze cztery powiązane ustawienia i komplet musi być spójny.
Typowy scenariusz: włączasz ten jeden parametr, a skaner przestaje wysyłać cokolwiek. Powód? Konflikt z inną opcją, która nadal każe wysyłać Enter jako tekst. Dwa tryby naraz dają wynik gorszy niż każdy z osobna.
3. Opóźnienie, które działa w dwie strony
Opóźnienie między znakami to parametr, który w jednym trybie pracy trzeba zmniejszyć, a w drugim zwiększyć. W trybie blokowym zbyt duże opóźnienie rozbija kod na kawałki. W trybie zdarzeń klawiszowych zbyt małe powoduje, że zdarzenia gubią się po drodze.
Rada „ustaw zero" i rada „ustaw pięćdziesiąt" są obie poprawne — tyle że w różnych konfiguracjach. Bez wiedzy, w którym trybie pracujesz, to rzut monetą.
4. Ustawienia, które wyglądają na zapisane
Wyjście z ekranu profilu przyciskiem ekranu głównego nie zapisuje zmian. Trzeba wyjść przyciskiem wstecz. Konfiguracja wygląda na wprowadzoną, a obowiązuje stara.
To brzmi banalnie i właśnie dlatego potrafi pochłonąć pół dnia — bo każdy kolejny test sprawdza ustawienia, których tam nie ma.
5. Test w notatniku, który niczego nie dowodzi
Naturalny odruch: otwórz notatnik, strzel w kod, sprawdź czy się wpisuje. Wpisuje się. Wniosek — skaner działa, więc winne jest Odoo.
Wniosek jest błędny. Zwykłe pole tekstowe w Androidzie przyjmuje oba tryby wysyłania danych. Odoo akceptuje tylko jeden. Notatnik przejdzie test nawet przy konfiguracji, przy której Odoo nie ma szans zadziałać. Dodatkowo notatnik może pracować na zupełnie innym profilu niż Odoo.
Jak sprawdzić, co naprawdę wysyła skaner
Zamiast zgadywać, można to zmierzyć — bez instalowania czegokolwiek na terminalu.
W przeglądarce na terminalu otwiera się publiczne narzędzie diagnostyczne W3C, które wypisuje wszystkie zdarzenia klawiatury docierające do strony. Wystarczy wyczyścić tabelę i strzelić raz w kod. Wynik czyta się tak:
- Wiele osobnych zdarzeń, każde z kodem odpowiadającym konkretnej cyfrze, na końcu Enter — konfiguracja poprawna.
- Jedno zdarzenie bez znaku i cały kod naraz w jednej kolumnie — skaner pracuje w trybie blokowym. To jest przyczyna podwójnego skanowania.
- Pusta tabela — dane nie docierają w ogóle. Zły profil albo wyłączone wyjście.
Jest jeszcze kontrola, o której łatwo zapomnieć: czy wszystkie znaki dotarły. Poprawny odczyt generuje pięć zdarzeń na każdy znak kodu plus cztery na końcowy Enter. Dla kodu szesnastoznakowego daje to osiemdziesiąt cztery zdarzenia. Jeśli licznik pokazuje mniej, część znaków ginie po drodze i trzeba wrócić do opóźnień. Kod skanuje się wtedy raz na jakiś czas poprawnie, co jest znacznie trudniejsze do wykrycia niż awaria całkowita.
Dlaczego to zajmuje więcej czasu, niż powinno
Żadna z powyższych pułapek nie jest trudna sama w sobie. Trudność polega na tym, że objawy są mylące. Skaner działa w notatniku, ale nie w Odoo. Włączenie właściwego ustawienia pogarsza sytuację zamiast poprawić. Zmiany nie przynoszą skutku, bo nie zostały zapisane. Każdy z tych sygnałów prowadzi w złą stronę.
Bez pomiaru — czyli bez sprawdzenia, co faktycznie dociera do przeglądarki — konfiguracja zamienia się w serię prób. Z pomiarem to zwykle kilkadziesiąt minut.
Podsumowanie
Aplikacja Kod kreskowy w Odoo działa dobrze i daje realny efekt w magazynie. Ale między skanerem a Odoo stoi warstwa konfiguracji terminala, o której łatwo zapomnieć przy planowaniu wdrożenia — a która potrafi zablokować cały proces na etapie pierwszych testów.
Mamy tę konfigurację przerobioną na terminalach Zebra, razem z diagnostyką pozwalającą ustalić przyczynę zamiast zgadywać. Jeśli utknąłeś na skanerach albo chcesz uruchomić skanowanie bez tracenia czasu na próby — możemy wziąć konfigurację terminali na siebie w ramach zlecenia.