prosta obs uga magazynu - jak to zrob

pyt Q

Witam, Coś co z pozoru wydawało mi się trywialne, od kilku godzin nie daje mi żyć. Piszę prostą aplikację do ilościowej obsługi magazynu. Strukturę bazy, w uproszczeniu, wymyśliłem taką: 1. Słownik typów dokumentów 2. Słownik jednostek miar 3. Słownik towarów 4. Słownik magazynów/kontrahentów 5. Miejsca składowania 6. Dokumenty magazynowe 7. Pozycje dokumentów magazynowych 8. Stany magazynowe
Miałoby to działać w ten sposób, że po przyjęciu dokumentu, np PZ, uruchamia się trigger, który na podstawie zawartości dokumentu uaktualni tabelę 8 Stany magazynowe. I już tutaj mam zgryz, bo nie jestem pewien jaki typ klucza głównego zastosować: jakiś sztuczny (inkrementowane id) czy złożony: id_towaru, id_miejsca_składowania, id_magazynu, data_przyjęcia (potrzebna do fifo), data_przydatności_do_użycia (potrzebna ze względu na specyfikę towarów). Tak to się robi? Tzn. czy w takich aplikacjach tworzy się w ogóle osobną tabelę do przechowywania stanów magazynowych? Wystawiając WZ użytkownik musi mieć możliwość wyboru wyboru z którego stanu magazynowego chce pobrać towar. Czy w takim przypadku powinienem zrobić jakieś powiązanie pomiędzy tabelą 7 pozycji dokumentów magazynowych a 8 stanów magazynowych? Aplikację piszę w Ruby on Rails. Nie jestem całkiem zielony jeśli chodzi o bazy danych, ale przyznaję, tematyka logistyczno-magazynowa jest mi raczej mało znana.
Będę wdzięczny za wszelkie sugestie.
Pozdrawiam, Adam ak wrote at 08.12. 16:34:
* klucz główny sztuczny, kombinacja tylko (i aż) unikalna.
* triggery raczej odradzam. po paru latach stanie się to niemożliwe do utrzymania. może raczej jakieś "eventy" w aplikacji?
* stany magazynowe owszem powinny być gdzieś przechowywane ale muszą mieć też możliwość odbudowy na podstawie dokumentów.
* fifo nie jest jedynym podejściem, czasami trywialna zmiana timestampa rozłoży całą bazę.
* rodzaje dokumentów magazynowaych muszą być dobrze przemyślane. może słownik typów dokumentów z działaniem na stan (-1,0,1).
* użytkownik/system który wystawia WZ może nie mieć pojęcia o miejscach składowania. wtedy do WZ będzie potrzeby osobny dokument przesunięcia. i powiązanie raczej między 7 i 5 a nie 7 i 8
* temat jest szeroki. wiem jedno - "prosta" i "obsługa magazynu" jakoś nie grają ze sobą.
miałem do czynienia z produktem komercyjnym tego typu.

odp A

rs-anakonda.org/
A to ?? Jest tam też na stronce dokumentacja elegancka (do bazy również), no i projekt na otwartej licencji.
Dzięki, o tym nie słyszałem.
Szybkie spojrzenie na tabele związane z magazynem wywołało u mnie wrażenie, że ich struktury nie są jeszcze dopracowane. Np tabela rs_miejsca_skladowania - w żadnej innej nie znalazłem do niej odniesienia, co pewnie oznacza, że magazyn adresowy nie został jeszcze zaimplementowany. Ale ogólnie projekt ciekawy, nie powiem.
ak pisze:
Można powiedzieć, że struktury są niedopracowane, ale wynika to z tego, że system jest ciągle w fazie rozwojowej. Zapewnia obecnie funkcjonalność wystarczającą do wykorzystywania w bieżącej pracy kilkunastu firm, które z niego korzystają. Z oczywistych względów (pieniądze ;-) ) wprowadzane są do niego w pierwszej kolejności funkcjonalności zamawiane przez aktualnych i przyszłych użytkowników.
Pozdrawiam Jan Raburski

Dodaj odpowied¼

Tytu³:

Mail: (w celu weryfikacji posta)