Magazyn zewnętrzny w osobnej bazie: dokumenty oddzielone, konfiguracja wspólna

Administrator, który ma oddzielić dokumenty magazynu zewnętrznego od własnych, a konfigurację aplikacji zachować w jednym miejscu, musi rozstrzygnąć, gdzie leży co. Opisujemy, jak rozwiązano to w jednym wdrożeniu Studio WMS.net: magazyn zewnętrzny w WMS dostał osobną bazę dokumentów (według dokumentacji jest to magazyn obsługiwany przez operatora logistycznego), a konfiguracja pozostała w bazie głównej.

Tekst jest napisany dla administratora i architekta wdrożenia. Opisujemy zapytania i skrypt wdrożeniowy, ale bez nazw obiektów bazy z wdrożenia i bez liczby dokumentów. Model odwrotny, w którym jedna baza obsługuje wiele obiektów, opisuje strona o operatorze logistycznym w systemie WMS, a wspólną bazę stanów dla oddziałów strona o zarządzaniu wieloma magazynami.

Dwie bazy i jedna konfiguracja

W opisywanym wdrożeniu dokumenty magazynu zewnętrznego leżą w osobnej bazie, we własnej tabeli dokumentów. Menu i rejestry oraz transakcje formularzy zostają w bazie głównej. Tam zostają też słowniki i zapisane zapytania.

Aplikacja jest jedna i ma jedną konfigurację w bazie głównej. Formularze magazynu zewnętrznego to osobne transakcje, które czytają i zapisują dokumenty w bazie dokumentów. Dla administratora oznacza to jedno miejsce, w którym zmienia się menu i zapisane zapytania, i drugie, w którym leżą dokumenty. Obsługę wielu klientów w jednej hali opisuje strona o WMS dla operatorów logistycznych, a tutaj chodzi o dokumenty jednego magazynu w osobnej bazie.

Tabela pokazuje, co leży w której bazie.

Formularz nie zna nazwy bazy dokumentów, bo połączenie jest zapisane przy zapytaniu, a odwołania między bazami idą po pełnej nazwie.

Połączenie zapisane przy zapytaniu, a nie w formularzu

Każde zapisane zapytanie ma przypisane połączenie. Formularz woła zapytanie po identyfikatorze, a serwer wykonuje je na połączeniu zapisanym przy zapytaniu. Kod formularza nie zawiera więc nazwy bazy. O tym, do której bazy trafia zapytanie, decyduje jego wpis w konfiguracji, a nie plik skryptu formularza.

Formularze magazynu zewnętrznego korzystają z zapytań wspólnych z formularzem przyjęcia ze zlecenia: trzy rodzaje zapytań, czyli listy pozycji, sumy i edycja, są te same.

Transakcja formularza to wpis z trzema ustawieniami: plikiem skryptu, funkcją startową i sposobem powrotu. Znacznik wersji w adresie pliku wymusza ponowne pobranie skryptu przez przeglądarki po zmianie. Podobny mechanizm transakcji i znaczników wersji opisuje artykuł o testowaniu nowych transakcji terminala.

Odwołania między bazami po pełnej nazwie

Zapytania wykonywane na połączeniu bazy dokumentów sięgają do bazy głównej po pełnej nazwie obiektu, czyli po nazwie złożonej z trzech części: bazy, schematu i samego obiektu. Robią to w trzech miejscach: po adres lokalizacji z kartoteki lokalizacji, po numer dokumentu z procedury numeracji i przy zapisie wpisu w dzienniku zdarzeń.

W drugą stronę rejestry dokumentów i licznik dokumentów w buforze przy pozycji menu odwołują się do bazy dokumentów po pełnej nazwie obiektu. Konfiguracja w bazie głównej pokazuje więc dokumenty z drugiej bazy bez przenoszenia ich.

Odwołanie po pełnej nazwie działa w obrębie jednego serwera SQL. W opisywanym wdrożeniu przyjmujemy więc, że obie bazy stoją na jednym serwerze. Jest to wniosek z postaci zapytań, a nie ustalenie z konfiguracji serwera.

Numeracja z bazy głównej dla dokumentów w bazie dokumentów

Numerację dokumentów prowadzi baza główna. Licznik jest zapisany osobno dla roku i dla pary prefiks-typ dokumentu. Zapytanie zatwierdzające, wykonywane na połączeniu bazy dokumentów, pobiera numer z procedury numeracji w bazie głównej, więc dokument leży w jednej bazie, a jego numer pochodzi z drugiej.

Jeden z formularzy magazynu zewnętrznego, przyjęcie bezpośrednie, ma własną parę prefiksu i typu, więc ma własny licznik.

Numer mieści się w dwudziestu znakach: taka jest pojemność zmiennej, do której przyjmuje się wynik procedury numeracji. Długość pola w tabeli dokumentów magazynu zewnętrznego nie została sprawdzona, więc przy integracji z systemem zewnętrznym trzeba ją uzgodnić osobno. Maski i liczniki w innym wdrożeniu opisuje strona o numeracji dokumentów KM i PM.

Stan magazynu zewnętrznego i właściciel towaru na pozycji

Stan magazynu zewnętrznego czyta osobny widok stanu per lokalizacja, wzorowany na standardowym i rozróżniający także dostawcę. Jego treści nie opisujemy.

Według dokumentacji skryptu wdrożeniowego stan rozróżnia osiem cech: firmę będącą właścicielem towaru, dostawcę, asortyment, lokalizację, paletę, partię, termin ważności i datę produkcji.

Na każdej pozycji dokumentu zapisują się firma, czyli właściciel towaru, i dostawca, czyli kontrahent z kartoteki dostawców. Model właściciela i dostawy opisuje artykuł o stanie magazynu per dostawa i właściciel.

Wdrożenie skryptem, który wie, na której bazie pracuje

Skrypt wdrożeniowy wykonuje się w bazie głównej i zaczyna od kontroli nazwy bazy: przy innej bazie zatrzymuje się z komunikatem. Każdy element jest sprawdzany przed dodaniem, więc ponowne wykonanie niczego nie dubluje.

Funkcję listy dokumentów skrypt tworzy w bazie dokumentów przez wywołanie procedury systemowej w kontekście tej bazy. Definicję bierze z istniejącej funkcji listy przyjęć i podmienia w niej typ dokumentu. Gdy podmiana nie trafiła, zatrzymuje się z błędem.

Pozycje menu dla nowych formularzy skrypt dodaje roli działu zamówień, a na końcu uruchamia zapytanie kontrolne, które sprawdza, czy inne role nie dostały nowych pozycji.

Ogólną praktykę skryptów wdrożeniowych, z trybem próbnym i osobną rolą testową, opisuje wspomniany wyżej artykuł o testowaniu nowych transakcji terminala. Tutaj liczy się to, że skrypt zna bazę, na której pracuje, i dotyka dwóch baz.

Przykład: administrator wdraża nową funkcję magazynu zewnętrznego

Przykład ze zmyślonymi danymi. Administrator wdraża nową funkcję magazynu zewnętrznego i uruchamia skrypt w bazie głównej. Skrypt najpierw sprawdza nazwę bazy i zatrzymuje się, gdy otwarto inną.

Potem dodaje zapytania z połączeniem do bazy dokumentów i wpis transakcji formularza, a w bazie dokumentów tworzy funkcję listy dokumentów. Kontrolne zapytanie po wdrożeniu zwraca w naszym przykładzie cztery sprawdzenia: dwa zapisane zapytania z połączeniem do bazy dokumentów, funkcję listy utworzoną w bazie dokumentów, dwa rejestry w bazie głównej i wpis transakcji formularza.

Rejestry dokumentów w menu i licznik dokumentów w buforze odwołują się potem do bazy dokumentów po pełnej nazwie obiektu, a formularz nadal nie zna nazwy bazy.

Pytania do zadania na etapie analizy

Przed rozdzieleniem dokumentów na dwie bazy zadajemy cztery pytania. To pytania do czytelnika, a nie fakty o opisywanym wdrożeniu. Rolę administratora opisuje strona o zadaniach administratora systemu WMS, a przebieg projektu strona o wdrożeniu systemu WMS.

• Rozdzielenie dokumentów - dlaczego dokumenty operatora mają być oddzielone od własnych i kto ma mieć dostęp do bazy dokumentów.
• Serwer i kopie zapasowe - czy obie bazy mogą działać na jednym serwerze i kto odpowiada za kopie zapasowe każdej z nich.
• Kartoteki wspólne - które kartoteki mają zostać wspólne, a które mają mieć własną kopię w bazie dokumentów.
• Numeracja - jak ma wyglądać numeracja dokumentów magazynu zewnętrznego i ile znaków ma mieścić numer.

Czego ta strona nie opisuje

Strona nie podaje nazw obiektów bazy z wdrożenia, nazw ról, kodów menu ani liczby dokumentów. Nie wyjaśnia powodu podziału na dwie bazy i nie opisuje wymiany plików z operatorem ani wydań z magazynu zewnętrznego. Opisuje budowę zapytań i skryptu, a nie sposób użycia formularzy przez użytkowników.