Awizacja jest jedynym miejscem, w którym dane o przewozie i dane o towarze muszą się spotkać przed przyjazdem pojazdu. Ustalenie, który system jest źródłem którego pola, przesądza o tym, czy po pół roku kartoteki nadal się zgadzają. Co zapisuje sam system YMS, a co przychodzi z zewnątrz, rozdziela przegląd kategorii.
Co leży po której stronie
System transportowy zna przewóz: kto wiezie, czym, skąd i dokąd. System magazynowy zna towar: jaki indeks, w jakiej ilości, na którą lokalizację. Awizacja potrzebuje obu zestawów, bo termin zależy od dostępności rampy, a długość obsługi od charakteru ładunku.
Rozdzielenie tych zakresów bywa niejasne, bo oba systemy mają pola o podobnych nazwach. Kontrahent w systemie handlowym oznacza zwykle stronę umowy, a w rejestrze wizyt podmiot, dla którego realizowany jest transport - i nie zawsze jest to ten sam rekord.
| Dane | Źródło | Kto z nich korzysta |
|---|---|---|
| Kartoteka kontrahentów | System handlowy | Wszystkie warstwy |
| Numer i pozycje zamówienia | System handlowy | Magazyn przy przyjęciu |
| Pojazd, kierowca, przewoźnik | Zgłoszenie awizacyjne | Ochrona na bramie |
| Termin i rampa | Warstwa placowa | Magazyn i przewoźnik |
| Ilość przyjęta | Magazyn | System handlowy przy rozliczeniu |

Kierunek wymiany dla każdego zbioru
Najczęstszy błąd polega na dopuszczeniu dwóch równorzędnych źródeł tej samej kartoteki. Kontrahent dopisany po stronie awizacji i ten sam kontrahent dopisany w systemie handlowym tworzą dwa rekordy, które po kilku miesiącach różnią się adresem, nazwą i osobą kontaktową.
Ustalenie kierunku wymaga decyzji dla każdego zbioru osobno i zapisania jej, bo wraca przy każdej kolejnej integracji. Praktyczny układ wygląda tak, że kartoteki i zamówienia płyną z systemu handlowego, dane pojazdu powstają w zgłoszeniu, a ilości przyjęte wracają do systemu handlowego po zamknięciu obsługi.
Dopisywanie kontrahentów po obu stronach wygląda na wygodne przez pierwszy kwartał. Potem zaczyna się ręczne dopasowywanie rekordów, a historia wizyt rozdziela się między dwa identyfikatory tej samej firmy.
Kiedy dane przechodzą przez granicę
Wymiana nie musi być ciągła i zwykle nie powinna. Cztery momenty wystarczają, żeby pokryć proces, a każdy dodatkowy zwiększa liczbę miejsc, w których coś się rozjedzie.
- Przy zakładaniu zgłoszenia - pobranie numeru zamówienia i oczekiwanej ilości.
- Przy potwierdzeniu terminu - odesłanie daty dostawy do systemu handlowego.
- Przy podstawieniu pod rampę - przekazanie danych transportu do obsługi przyjęcia.
- Po zamknięciu obsługi - zwrot ilości faktycznie przyjętej wraz z rozbieżnościami.
Ostatni moment jest tym, na którym zależy księgowości, więc bywa wdrażany pierwszy. Bez pozostałych trzech daje jednak mniej, niż mógłby: ilość przyjęta wraca do systemu, który nie wiedział, że dostawa w ogóle jedzie. Dostępne sposoby połączenia zebrano na stronie o integracjach.
Co się psuje na granicy
Problemy w tym miejscu mają powtarzalny charakter i żaden nie wynika z ograniczeń oprogramowania. Pierwszy to zamówienie zamknięte w systemie handlowym, gdy pojazd jest już w drodze - przyjęcie nie ma wtedy do czego się przypiąć.
Drugi to zmiana ilości na zamówieniu po zarezerwowaniu okna. Dostawa zajmie wtedy inny czas obsługi niż zaplanowany, co przesuwa kolejne transporty. Trzeci to indeks nieistniejący w kartotece magazynu, wymagający założenia przy rampie, gdy pojazd czeka.
Wszystkie trzy da się wyłapać przed przyjazdem przez kontrolę zgodności uruchamianą na dzień przed dostawą. Zestawienie rozbieżności między zamówieniem a awizacją kosztuje jedno zapytanie i oszczędza godziny przy rampie. Sposób budowania takich zestawień opisuje strona o usługach raportowych SQL Server.
Co awizacja daje magazynowi
Zgłoszenie z listą pozycji pozwala przygotować przyjęcie przed podstawieniem pojazdu: zarezerwować miejsce odkładcze, przydzielić osobę do kontroli, przygotować dokumenty. Bez tych danych przyjęcie zaczyna się od ustalania, co właściwie przyjechało.
Powiązanie awizacji z pozycją asortymentową działa też w drugą stronę. Magazyn poszukujący konkretnego indeksu widzi, którym transportem i kiedy przyjedzie, zamiast pytać zakupy. Zakres kontroli przy przyjęciu opisuje strona o przyjmowaniu dostaw, a organizację stref - materiał o zarządzaniu logistyką magazynową.
Ile integracji uruchomić na start
Pokusa objęcia wszystkich czterech momentów wymiany od razu jest zrozumiała i zwykle wydłuża wdrożenie. Sensowniejsza kolejność zaczyna się od pobrania numeru zamówienia przy zakładaniu zgłoszenia, bo to najprostszy element i od razu podnosi jakość danych.
Zwrot ilości przyjętej wchodzi jako drugi, gdy struktura zgłoszenia jest już stabilna. Pozostałe dwa momenty dokłada się tam, gdzie wynika z nich realna korzyść, a nie z założenia, że integracja ma być pełna. Granice między klasami systemów porządkuje strona o systemach zarządzania transportem.
Zachowanie przy przerwie w wymianie danych
Integracja przestaje działać w najmniej dogodnym momencie i trzeba z góry ustalić, co wtedy. Dwa zachowania są skrajne i oba złe: zatrzymanie zgłoszeń do czasu naprawy oraz ciche przyjmowanie danych bez weryfikacji.
Rozwiązanie pośrednie polega na dopuszczeniu zgłoszenia z numerem zamówienia wpisanym ręcznie, oznaczonego jako niezweryfikowany. Po przywróceniu połączenia kontrola zgodności wychwytuje przypadki, które nie mają odpowiednika w systemie handlowym, a dyspozytura uzupełnia je przed przyjazdem.
Druga decyzja dotyczy kolejki komunikatów. Potwierdzenia przyjęcia wygenerowane w czasie przerwy powinny czekać na wysłanie, a nie przepaść. Bez tego księgowość dostaje niekompletny zestaw danych za dany dzień i wykrywa to dopiero przy zamknięciu miesiąca.
Warto też ustalić, kto jest informowany o przerwie. Komunikat trafiający wyłącznie do dziennika serwera oznacza, że problem zostanie zauważony wtedy, gdy ktoś zacznie szukać brakujących danych. Wymagania infrastrukturalne opisuje strona o architekturze oprogramowania YMS.