Import zamówień z ERP przez API działa w opisywanym wdrożeniu przyrostowo: system pyta interfejs ERP o listę zamówień zmienionych od wczoraj i pobiera ich szczegóły, a pozycje, które już zna, aktualizuje. Pozycja usunięta w ERP zostaje w danych jako usunięta i znika z list wyboru w awizacji. Import uruchamia się z zewnątrz, bez ustalonej częstotliwości.
Kupiec zmienia w ERP ilość na zamówieniu, a dostawca otwiera w tym samym czasie formularz awizacji. Czy zobaczy nową liczbę, zależy od tego, kiedy portal ostatnio pytał ERP o to zamówienie. Import zamówień z ERP przez API jest w opisywanym wdrożeniu ułożony tak, żeby takie zmiany trafiały do portalu bez wczytywania całej historii.
Dlaczego system pobiera zamówienia, a nie czeka na wysyłkę z ERP
Z ustaleń na etapie wymagań wynikało, że zamówienie wystawione w ERP ma trafiać do systemu awizacji automatycznie. W opisywanym wdrożeniu realizuje to pobieranie: system sam wywołuje interfejs API programu ERP z procedury bazy danych i pyta o zamówienia zakupu, a ERP niczego do niego nie wysyła. Ogólne opisy integracji, na przykład strona o integracji systemu awizacji z ERP albo o REST API systemu awizacji, pokazują kierunek od ERP do systemu. Tutaj kierunek jest odwrotny.
Wywołania są sekwencyjne i synchroniczne: system wysyła zapytanie i dopiero po odpowiedzi przechodzi do następnego. Każde wywołanie zapisuje się w dzienniku wywołań interfejsów. Szersze omówienie wymiany danych z ERP przez REST daje opis integracji awizacji z programami ERP, a zasady interfejsu w samym produkcie opisuje instrukcja API Studio VSS.net.
Procedura importu nie ma parametrów, a w menu aplikacji nie ma pozycji, która by ją uruchamiała. W opisywanym wdrożeniu uruchamia się ją więc z zewnątrz. Dokumentacja nie określa częstotliwości i nie podajemy jej tutaj. Import zamówień z pliku, który działa inaczej i ma własny ekran, opisuje import zamówień z pliku.
Okno od wczoraj i lista zmian
Pobieranie zaczyna się od listy zmian. ERP zwraca listę zamówień ostatnio zmodyfikowanych, a przy każdym z nich czas zmiany. Okno stosuje dopiero system: odrzuca wpisy starsze niż początek wczorajszego dnia. Zamówienie zmienione w ERP wczoraj albo dzisiaj przechodzi dalej, a starsze zostaje pominięte w tym przebiegu.
Początek okna wynika z dnia, w którym uruchomiono import. System nie zapisuje, kiedy poprzedni przebieg się zakończył, więc okno nie przesuwa się od ostatniego udanego pobrania. Za każdym razem sięga do początku wczorajszego dnia. Opisujemy tu regułę dla zwykłego dnia i na niej opieramy schemat.
Import pyta ERP tylko o zamówienia zmienione od wczoraj.
Z tej konstrukcji wynika pytanie, które zadajemy przy analizie: jak długa przerwa w uruchamianiu importu jest dopuszczalna, skoro okno obejmuje wczorajszy dzień i dzisiejszy. Opis wdrożenia na nie nie odpowiada, bo częstotliwość uruchamiania leży poza nim.
Szczegóły zamówień pobierane zbiorczo i pojedynczo
Lista zmian informuje tylko o tym, które zamówienia się zmieniły i kiedy. Szczegóły system pobiera osobno, w dwóch krokach. Pierwszy jest zbiorczy: jedno zapytanie z listą identyfikatorów zamówień zwraca dostawcę oraz pozycje z ich atrybutami. Drugi jest pojedynczy: system pyta o każde zamówienie z listy i z tej odpowiedzi odczytuje pozycje oraz ich atrybuty.
Atrybuty pozycji mają w opisywanym wdrożeniu jedno zastosowanie, które wskazujemy dla porządku: z nich import odczytuje oznaczenie dostawy na wywołanie. Sam mechanizm wywołania opisuje tekst o wywołaniu dostawy i gotowości pozycji, a na tej stronie poprzestajemy na tym zdaniu.
Co trafia do systemu i w jakiej postaci
Zapis obejmuje dwanaście wartości: siedem z nagłówka zamówienia i pięć z pozycji. Zestawia je tabela.
| Źródło w ERP | Co system zapisuje |
|---|---|
| Nagłówek zamówienia | Identyfikator zamówienia w ERP |
| Nagłówek zamówienia | Pełny numer zamówienia |
| Nagłówek zamówienia | Dostawca |
| Nagłówek zamówienia | Stan zamówienia |
| Nagłówek zamówienia | Data utworzenia |
| Nagłówek zamówienia | Druga data zamówienia (termin) |
| Nagłówek zamówienia | Wartość brutto |
| Pozycja zamówienia | Towar |
| Pozycja zamówienia | Ilość |
| Pozycja zamówienia | Numer pozycji |
| Pozycja zamówienia | Wartość brutto pozycji |
| Pozycja zamówienia | Stawka VAT |
Data utworzenia przychodzi z ERP jako liczba dni od stałej daty bazowej systemu ERP, a import przelicza ją na datę kalendarzową. W zestawieniach pozycja ma też datę z zamówienia, którą formularz awizacji podpowiada jako dzień awizacji.
Stan zamówienia pochodzi z ERP. Zamówienia otwarte w ERP widać w portalu ze stanem Potwierdzone albo W Realizacji, a zamknięte ze stanem Zrealizowane. Tych trzech oznaczeń używamy w całym opisie.
Pozycje zmienione i pozycje usunięte w ERP
Zapis ma dwa etapy. Najpierw system aktualizuje pozycje, które już ma, dopasowując je po zamówieniu i numerze pozycji. Potem dopisuje pozycje, których jeszcze nie ma.
Reguła dla zamówień zamkniętych jest asymetryczna. Nowe pozycje wchodzą do systemu tylko z zamówień otwartych w ERP. Pozycje już znane są aktualizowane (ilość, wartości, stan i oznaczenia) niezależnie od stanu zamówienia, także w zamówieniu zamkniętym, ale z takiego zamówienia import nie dopisuje nowych pozycji.
Pozycja, której nie ma już w zamówieniu w ERP, jest oznaczana w systemie jako usunięta. Wiersz zostaje w danych, a pozycja przestaje być podpowiadana w formularzu awizacji. System porównuje pozycje po numerze pozycji i towarze, więc zmiana towaru na tej samej pozycji wygląda dla niego jak zniknięcie jednej pozycji i pojawienie się drugiej.
Pięć typowych zdarzeń w ERP i ich skutek w formularzu zestawia tabela.
| Zdarzenie w ERP | Co robi import | Skutek w formularzu awizacji |
|---|---|---|
| Nowe zamówienie otwarte | Dopisuje pozycje, których jeszcze nie ma w systemie | Pozycje pojawiają się na listach wyboru, gdy mają kartotekę towarową |
| Zmiana ilości pozycji | Aktualizuje ilość i wartości istniejącej pozycji | Ilość pozostała do awizowania liczy się z nowej ilości |
| Pozycja usunięta z zamówienia | Oznacza pozycję jako usuniętą | Pozycja znika z list wyboru |
| Zamówienie zamknięte w ERP | Aktualizuje znane pozycje, w tym stan, i nie dopisuje nowych | Zamówienie znika z list wyboru |
| Zamówienie wskazuje nieznanego dostawcę | Zakłada dostawcę z kontaktami | Dostawca jest dostępny na liście kontrahentów |
Środowa zmiana i czwartkowy import w jednym przykładzie
Przykład z danymi fikcyjnymi. W środę w ERP zmienia się Zamówienie 26-1001 Dostawcy Testowego: zmniejszono ilość pozycji Artykuł A, a pozycję Artykuł B usunięto. W czwartek rano import pyta ERP o listę zmian i zostawia wpisy z czasem zmiany od środy. Na liście znajduje Zamówienie 26-1001.
System pobiera jego szczegóły, najpierw zbiorczo, potem osobnym zapytaniem. Aktualizuje ilość Artykułu A i oznacza pozycję Artykułu B jako usuniętą. Gdy dostawca otwiera formularz awizacji, na liście pozycji widzi Artykuł A z nową ilością, a Artykułu B już nie ma. Stan zamówienia nadal brzmi Potwierdzone, bo ERP go nie zmieniło.
Gdyby ten sam import uruchomiono dopiero w piątek, wpis ze środy leżałby poza oknem, bo początek okna przesunąłby się na czwartek. To jest powód, dla którego częstotliwość uruchamiania jest dla takiego rozwiązania ważnym parametrem wdrożenia.
Co decyduje o tym, że dostawca zobaczy pozycję w awizacji
Formularz awizacji podpowiada pozycję dopiero wtedy, gdy spełnione są trzy warunki: zamówienie jest otwarte, pozycja ma w systemie aktywną kartotekę towarową i ma dodatnią ilość pozostałą do awizowania. Pozycja bez kartoteki towarowej jest w systemie zapisana, ale na listach wyboru jej nie ma.
Ilość pozostałą do awizowania liczy się według zasad opisanych w tekście o bilansie pozycji zamówienia z trzech stanów. Układ kartotek, w tym kartoteki towarowej, opisuje strona o kartotekach w Studio VSS.net.
Gdy zamówienie wskazuje dostawcę, którego nie ma w kartotece, import zakłada go razem z jego kontaktami. Ten krok opisuje tekst o dostawcy zakładanym na żądanie. Kierunek odwrotny, czyli status awizacji wracający do ERP jako status pozycji zamówienia, opisuje tekst o statusie awizacji w ERP.
Czego opis wdrożenia nie rozstrzyga
Opis wdrożenia ma granice, które warto znać przed rozmową o podobnym rozwiązaniu.
- Częstotliwość - dokumentacja nie określa, jak często import jest uruchamiany z zewnątrz.
- Przerwy - system nie zapisuje końca poprzedniego przebiegu, a opis nie twierdzi, że przerwa dłuższa niż okno jest nadrabiana.
- Usunięcia - opis nie obejmuje wpływu usunięcia pozycji w ERP na awizacje już zapisane ani na ilość w zamówieniu.
- Odpowiedzi interfejsu - opis nie twierdzi, że błędy odpowiedzi interfejsu ERP są kontrolowane w pełni.
Pytania do ustalenia przed takim importem
Zanim w innym obiekcie powstanie podobny import, zadajemy cztery pytania.
- Przerwa - jak długa przerwa w uruchamianiu importu jest dopuszczalna, skoro okno obejmuje tylko wczorajszy dzień i dzisiejszy.
- Źródło prawdy - który system ma być źródłem prawdy o stanie zamówienia i kto zamyka pozycje, które w ERP wiszą.
- Czas modyfikacji - czy interfejs ERP pozwala pytać o zmiany po czasie modyfikacji i w jakiej strefie czasowej ten czas jest zapisany.
- Pozycja już zaawizowana - co ma się stać z pozycją usuniętą w ERP, jeśli dostawca zdążył ją zaawizować.