W firmie zajmującej się importem i handlem produktami spożywczymi zakupy nie przypominają klasycznego zaopatrzenia produkcji. Kupuje się kontrakty — partie surowca z konkretnych upraw i zbiorów, notowane w odniesieniu do giełdowych kontraktów terminowych, wysyłane kontenerami zza oceanu do portów europejskich. Każdy kontrakt to PDF od dostawcy lub brokera, potem potwierdzenie bookingu, konosament, numer kontenera — i długie tygodnie, w których towar płynie, a firma musi dokładnie wiedzieć: co, ile, na jakim statku i kiedy dopłynie.
Przed wdrożeniem ten proces żył w skrzynkach mailowych i arkuszach. Wdrożyliśmy go w Odoo — a poniżej opisujemy, jak wyglądało uruchomienie modułu zakupów, co się udało od razu, a co wymagało kilku podejść.
Punkt wyjścia: plan go-live zamiast „włączamy i zobaczymy"
Uruchomienie zaczęliśmy od wspólnie uzgodnionego planu, z jasnym podziałem odpowiedzialności: klient weryfikuje kompletność danych źródłowych, my sprawdzamy ich jakość i przygotowujemy szablony importu zgodne z wymaganiami Odoo, pierwsze importy idą na bazę testową, a na produkcję trafiają dopiero dane przetestowane na rzeczywistych zamówieniach.
Ten etap był mniej efektowny niż automatyzacje, o których za chwilę — i absolutnie kluczowy. Asortyment importowanego surowca to setki wariantów: ten sam produkt w różnych jakościach, zbiorach i konfekcjach. Wszystkie trzeba było zamodelować jako warianty produktów z unikalnymi SKU i zaimportować z użyciem identyfikatorów zewnętrznych, tak żeby kolejne importy aktualizowały istniejące rekordy zamiast tworzyć duplikaty.
Zakupy skrojone pod trading,
nie pod magazyn
Standardowy moduł zakupów Odoo dostał warstwę dopasowań do specyfiki handlu surowcami spożywczymi:
- jednostki zgodne z rynkiem — poszczególne typy kontraktów domyślnie w tonach lub funtach, tak jak notuje je giełda,
- pola logistyczne na liniach zamówień — numer bookingu, nazwa statku, termin dostarczenia ładunku, numer kontenera,
- status ładunku wyliczany z danych — każda linia zakupowa ma status w cyklu: do załadunku (brak bookingu) → zabookowany (jest numer bookingu) → w drodze (jest numer kontenera) → dostarczony (status z systemu śledzenia). Zespół widzi cały portfel kontraktów pogrupowany po etapach, bez ręcznego przestawiania czegokolwiek,
- widoczność kwot w walutach (USD, EUR, PLN) dopasowana do ról użytkowników.
Kontrakty czytają się same
Najciekawsza część wdrożenia: automatyczne przetwarzanie dokumentów. Kontrakty przychodzą jako PDF-y — każdy dostawca formatuje je inaczej. Zamiast ręcznego przepisywania skonfigurowaliśmy obieg, w którym e-mail z kontraktem trafia na dedykowany adres, Odoo pobiera załącznik, a agent AI (oparty o OpenAI) wyciąga z dokumentu dostawcę, produkt, wariant, ilości i odniesienie do kontraktu giełdowego — i tworzy z tego zamówienie zakupu z pozycjami. Automat sprawdza skrzynkę co 30 minut; podobnie przetwarzane są potwierdzenia bookingu i konosamenty, z których system dokłada numery kontenerów do właściwych zamówień.
Kontener na mapie
Ostatni element układanki to integracja z ShipsGo — serwisem śledzenia kontenerów morskich. Odoo pobiera statusy kontenerów przypisanych do zamówień: zespół widzi w systemie, że kontener został załadowany, płynie albo dotarł do portu, a status ładunku na linii zakupowej aktualizuje się sam. W trakcie wdrożenia okazało się, że pierwotna integracja potrafiła tylko odczytywać dane o kontenerach już dodanych do konta — rozszerzyliśmy ją więc o automatyczne rejestrowanie nowych kontenerów przez API, żeby proces był kompletny: od konosamentu, przez rejestrację śledzenia, po status „dostarczony".
Co nie zadziałało od razu...
...i czego nas to nauczyło
Historie sukcesu zwykle pomijają ten rozdział. My go zostawiamy, bo w nim jest połowa wartości.
Agent AI wymagał strojenia. W pierwszych tygodniach zdarzało mu się przypisać kontrakt do niewłaściwego dostawcy, założyć nowy kontakt zamiast użyć istniejącego albo nie utworzyć wariantu produktu. Każdy taki przypadek analizowaliśmy na konkretnym dokumencie i poprawialiśmy skrypty oraz prompty agentów. Wniosek praktyczny: automatyczne rozpoznawanie dokumentów to nie przełącznik, który się włącza, tylko proces, który się kalibruje — a przez okres kalibracji dane wyjściowe musi weryfikować człowiek.
Numeracja SKU wymagała przeprojektowania. Pierwotna logika nadawała numery wariantów w obrębie produktu, co przy setkach wariantów prowadziło do powtórzeń między produktami. Zmieniliśmy ją na numerację unikalną globalnie i dodaliśmy narzędzie do porządkowania wariantów archiwalnych.
Presja czasu była realna. W trakcie wdrożenia klient zatrudniał nowych pracowników, dla których moduł zakupów miał być podstawowym narzędziem pracy od pierwszego dnia. To wymusiło dyscyplinę: poprawki najpierw na środowisku testowym, szybkie iteracje, cotygodniowe uzgodnienia — i jasne rozdzielenie tego, co blokuje pracę, od tego, co jest usprawnieniem.
Efekt
Po zakończeniu wdrożenia zespół zakupów pracuje w jednym systemie, który obsługuje pełny cykl życia kontraktu:
- kontrakt z PDF-a trafia do Odoo bez przepisywania — automat przetwarza dokumenty przychodzące co pół godziny,
- statusy całego portfela dostaw (do załadunku / zabookowany / w drodze / dostarczony) wyliczają się z danych, a nie z pamięci pracowników,
- śledzenie kontenerów działa wprost z systemu — łącznie z automatyczną rejestracją nowych kontenerów,
- nowi pracownicy zostali wdrożeni od razu do pracy w Odoo, bez okresu przejściowego na arkuszach,
- e-maile i arkusze przestały być źródłem prawdy o tym, gdzie jest towar wart setki tysięcy dolarów.
Ten projekt dobrze pokazuje, czym różni się wdrożenie modułu od wdrożenia procesu. Moduł zakupów był w Odoo od zawsze — wartość powstała tam, gdzie zmapowaliśmy go na rzeczywistość konkretnego biznesu: giełdowe jednostki, statusy ładunku, dokumenty czytane przez AI i kontener widoczny na mapie. A największym sukcesem nie jest żadna z tych funkcji z osobna, tylko to, że działają razem — jako jeden proces, od podpisu na kontrakcie do towaru na magazynie.