Zmiana numeru zapasu

Problem, który chciałbym omówić nie dotyczy wszystkich systemów ERP. Wpływ zmiany klucza głównego rekordu w bazie danych jest bowiem różny w różnych systemach. W systemie takim jak Microsoft Dynamics NAV zmiana np. numeru zapasu powoduje automatyczną zmianę w bardzo wielu innych powiązanych miejscach, takich zapisy księgi zapasów, wiersze dokumentów, czy BOMy produkcyjne.

Z tego powodu operacja jest bardzo czasochłonna i mocno obciąża zasoby bazy danych (programów magazynowych). Kiedy więc zmieniamy numer tego samego zapasu w wielu różnych bazach danych jednocześnie, a firmy pracujące na tych bazach prowadzą między sobą transakcje może to doprowadzić do sytuacji, w której jedna z firm (stron transakcji) przeszła już proces zmiany numeracji, a inna wykorzystuje jeszcze stary numer.

Zmiana numeru zapasu

Kolejne kroki podwyższające spójność i jakość danych w firmie z wieloma oddziałami

W przypadku firm z wieloma oddziałami przemianowanie zapasów (tzw. rename) może być potrzebne po wdrożeniu Systemu Zarządzania Danymi Podstawowymi. Poniższy schemat obrazuje kolejne kroki, które przechodzą firmy wielooddziałowe na drodze do uzyskania pełnej spójności danych dotyczących zapasów we wszystkich oddziałach.

Krok pierwszy, czyli tworzenie procedury omówiłem w poście: Ustrukturyzowane numery zapasów w globalnej firmie. Wyzwania związane z oczyszczaniem danych w poście: Oczyszczanie danych w firmie przechodzącej globalną standaryzację Microsoft Dynamics NAV. Informacje na temat Systemu Zarządzania Danymi Podstawowymi można znaleźć na naszej stronie internetowej. Samo zaś przemianowanie zapasów dotyczy sytuacji, kiedy w trakcie oczyszczania danych lub w bieżącej pracy popełniony został błąd i w centralnej bazie danych MDMS znajduje się zapas o nieprawidłowym numerze.

Powstawanie duplikatów w trakcie przemianowania zapasów

Jeśli kartoteki zapasów używanych przez grupę firm są przechowywane w centralnej bazie danych MDMS, wówczas w przypadku przemianowania zapasów konieczne jest jednoczesne wysłanie odpowiedniej informacji do wszystkich lokalnych baz danych. Chodzi o to, aby w momencie kiedy oddziały zaczną wymieniać się między sobą zapasami, dane o zapasach były już zaktualizowane.

Numer jest jedynym parametrem jednoznacznie identyfikującym zapas w systemie erp Microsoft Dynamics NAV. Dlatego gdyby ograniczyć się jedynie do zmiany numeru zapasu w centralnej bazie danych MDMS, wówczas po chwili w bazach lokalnych powstałby nowy zapas, ale nadal istniałby stary. W lokalnych bazach danych mielibyśmy wówczas dwie kartoteki zapasu o różnych numerach dotyczących tego samego produktu.

Jak uniknąć powstawania duplikatów w lokalnych bazach danych?

Aby uniknąć omówionego wyżej problemu w zarządzaniu firmą, od razu po zmianie numeru zapasu w centralnej bazie danych MDMS do baz lokalnych wysyłana jest odpowiednia informacja. Na jej postawie stary numer zapasu jest blokowany przez cały dzień, a następnie w nocy odbywa się przemianowanie zapasów. Po przemianowaniu w lokalnej bazie istnieje już tylko zapas o nowym numerze. W tym momencie zapas może zostać odblokowany.

Przeprowadzenie odpowiedniej zmiany w centralnej bazie danych MDMS, a następnie przesłanie tej informacji jednocześnie do wszystkich lokalnych baz danych w nocy jest tym, co moim zdaniem sprawdza się najlepiej w przypadku przemianowania zapasów.

Właściwy czas na przemianowanie zapasów

Czas przeprowadzenia całej operacji ma duże znaczenie. Przemianowanie zapasów bardzo obciąża lokalne bazy danych i najlepiej jeśli w jej trakcie użytkownicy Microsoft Dynamics NAV nie korzystają z systemu erp. Oczywiście sprawę może dość mocno utrudnić geograficzne rozlokowanie oddziałów. Trudniej wybrać odpowiednią godzinę na przemianowanie zapasów, jeśli oddziały znajdują się na różnych kontynentach. Z naszych doświadczeń wynika jednak, że nawet w takich sytuacjach przedstawione podejście sprawdza się w praktyce.