Algorytm LIFO w gospodarce magazynowej

07:07 Jakub Bauman 0 Comments

W jednym z poprzednich postów przedstawiony został algorytm FIFO. Teraz przedstawiony zostanie algorytm, który jest jakby odwróceniem koncepcji tj algorytm LIFO (ang. Last in, first out). W algorytmie tym stosuje się zasadę: ostatnie weszło, pierwsze wyszło.

Zasada działania tego algorytmu jest tożsama ze stosem, w którym jako pierwsze pobierane są elementy przychodzące jako ostatnie.

Rozważmy przykład z danymi takimi samymi jak w przykładzie dotyczącym FIFO: Firma zakupiła 10 sztuk towaru A w cenie 10 zł za sztukę,
po czym zakupiła kolejne 10 sztuk towaru w cenie 11 zł za sztukę. A następnie sprzedała 2 sztuki Towaru A. Jaka jest wartość towaru A w magazynie.

Algorytm FIFO w gospodarce magazynowej

02:29 Jakub Bauman 2 Comments

Dokument PZ

03:56 Jakub Bauman 3 Comments

Wszelkie operacje magazynowe, niezależnie od tego czy magazyn jest prowadzony za pomocą programu komputerowego czy bez, należy dokumentować. Służą do tego dokumenty magazynowe.
W niniejszym artykule zostanie omówiony dokument PZ - Przyjęcie zewnętrzne.

Przyjęcie zewnętrzne to operacja polegająca na przyjęciu do magazynu towarów bądź materiałów.
Dokument przyjęcia zewnętrznego, określany często symbolem PZ jest wystawiany przez magazyniera lub inną osobę przyjmującą towar na podstawie (w zależności od przyjętych zasad):

- Dokumentu WZ od dostawcy
- Faktury od dostawcy
- Rzeczywistych ilości dostarczanego towaru.

Oczywiście konieczna jest zgodność rzeczywistych ilości z dokumentami.
Należy tutaj pamiętać, że osoba podpisująca się na dokumencie poświadcza prawdziwość operacji. Jest to szczególnie ważne dla magazynierów odpowiedzialnych majątkowo za prowadzony magazyn.
W przypadkach niezgodności należy sporządzać protokoły niezgodności i wyjaśniać zaszłość z dostawcą.

Obejrzyj film o przyjęciu magazynowym.

Dokument PZ powinien zawierać następujące dane:

Dane nagłówkowe:
- Numer
- Datę wystawienia
- Dane kontrahenta - nazwa i adres
- Dane magazynu - nazwa i adres (istotne gdy dostawca ma wiele lokalizacji lub korzysta z magazynów prowadzonych przez podmioty trzecie)

Dane pozycji (PZ może zawierać wiele pozycji):
- Określenie towaru
- Ilość
- Cenę zakupu (w zależności od przyjętych warunków handlowych cena może nie być podawana na dokumentach PZ)

Oryginalne druki dokumentów PZ zawierają dwie ilości: ilość deklarowaną i ilość otrzymaną.

Przykładowy wydruk dokumentu PZ przedstawiono poniżej.



Używając dokumentów PZ w różnych branżach możemy spotkać się z potrzebą przenoszenia innych informacji np.:
- numerów seryjnych,
- numerów partii produkcyjnej,
- daty ważności,
- innych opisujących parametry towaru.
O tym jakie dane są potrzebne powinna decydować dogłębna analiza.

Obsługa tych informacji może decydować o wyborze systemu informatycznego. Gdy projektujemy system uniwersalny warto aby pozwalał na określenie tych danych w konfiguracji. Dla przykładu w oprogramowaniu enova365 możliwe jest zdefiniowanie cech do pozycji dokumentu, które pozwalają na przechowywanie dodatkowych informacji.

Projektowanie dokumentu typu Faktura UML i Baza danych

07:13 Jakub Bauman 14 Comments

Prowadząc zajęcia często spotykam się u studentów z problemami ze zrozumieniem czym jest i jak powinno się zaprojektować w systemie informatycznym dokument taki jak Faktura.
Posłużę się przykładem faktury jednak idea jaką zaprezentuje dotyczy wszelkich dokumentów.

Budowa dokumentu Faktura

Po pierwsze należy sobie uświadomić co powinna zawierać faktura. Wymienię tu najważniejsze elementy:

W nagłówku:

• Numer
• Data wystawienia
• Data sprzedaży
• Dane kontrahenta
• Termin płatności (*)
• Kwota brutto do zapłaty (**)

(*) - W bardziej złożonych systemach możemy rozważać wiele terminów płatności
(**) - Kwota brutto faktury nie zawsze będzie tożsama z kwotą do zapłaty np. gdy występowały wcześniej zaliczki


Pozycje faktury:

• Liczba porządkowa
• Nazwa towaru/usługi
• Cena jednostkowa
• Ilość
• Jednostka miary
• Wartość

Pozostałe

• Tabela VAT
• Tabela zaliczek
• Tabela płatności 

Jedna faktura - wiele pozycji

Projektując diagram klas UML czy diagram ERD dla baz należy przede wszystkim zwrócić uwagę na to, że na jednej fakturze może wystąpić wiele pozycji. Zatem projektując musimy rozważać dwie klasy i analogicznie dwie tabele bazy danych:

• Nagłówek Faktury
• Pozycje Faktury

Jak nietrudno się domyślić klasy te (jak i tabele) powinny być w relacji 1 do n. Jedna faktura ma n pozycji.

Dane kontrahenta w fakturze

Projektując tabelę nagłówkową można założyć, że znajdzie się w niej klucz obcy wskazujący na kontrahenta. Natomiast w UML klasa nagłówka będzie posiadała atrybut typu Kontrahent.
Warto tutaj zwrócić uwagę na to, że faktura jest dokumentem, który według przepisów należy przechowywać w niezmienionej formie. Zmiana danych adresowych kontrahenta nie może pociągać za sobą zmiany danych na zapisanej w bazie fakturze. Mamy tutaj dwie możliwości.

1. Przepisać dane do dokumentu 
2. Zwielokrotnić rekordy kontrahenta

W pierwszym rozwiązaniu naruszamy oczywiście drugą postać normalną bazy danych, jednak to rozwiązanie jest znacznie częściej wybierane przez projektantów systemów ERP i dodatkowo jest bardziej wydajne obliczeniowo oraz pozwala na realizację dostępu do danych za pomocą zapytań SQL o mniejszej złożoności składniowej.
Drugie rozwiązanie jest z punktu widzenia teorii baz danych bardziej poprawne jednak powoduje większą złożoność zapytań SQL jakich należy używać aby pobierać dane, a tym samym większą złożoność obliczeniową.

Zwiększenie mocy obliczeniowej jest znacznie droższe niż zwiększenie pamięci dyskowej komputera zatem ekonomia wskazuje również na pierwsze rozwiązanie.

Towary w pozycjach faktury

Kolejnym błędem jest interpretacja polegająca na tym, że pozycje faktury to towary. Nic bardziej mylnego.Towar to jeden z elementów pozycji. Pozycja zawiera również co najmniej informacje: o sprzedawanej ilości, o cenie sprzedaży...
Projektując system informatyczny mamy na celu usprawnienie pracy poprzez wybór towarów z tzw. kartoteki zatem klasa Towar, czy tabela Towary w bazie danych jest jak najbardziej zasadna jednak nie jest ona tożsama z pozycją.
Towary pozostają w relacji 1 do n do pozycji faktury. Jeden towar może wystąpić w wielu pozycjach dokumentów.

Inne elementy dokumentu

Dokumenty typu faktura powinny zawierać również informację o płatności. W prostych systemach można to rozwiązać wprowadzając pole termin płatności do nagłówka. Nie jest to jednak rozwiązanie zbyt dobre gdyż uniemożliwia wystawianie faktur zawierających wiele płatności. Na przykład przy zakupie jakaś wpłata gotówką, a pozostała kwota przelewem w określonym terminie. Inny przykład to plan wpłat. Dlatego należałoby utworzyć tabelę płatności w relacji 1 do n do nagłówka faktury.
Tabela taka powinna zawierać informacje takie jak:
- sposób płatności
- termin płatności
- kwota

Suma kwot płatności powinna być taka sama jak wartość brutto faktury.

Inny element jaki powinien być uwzględniony przy projektowaniu dokumentu typu faktura to informacja o zasobach (pozycjach przychodowych). Gdy stosujemy na przykład algorytm FIFO to przy sprzedaży rozchodujemy towar wg kolejności w jakiej pojawił się na magazynie. Zasadę tę wyjaśnia film . Gdy stosujemy taki algorytm magazynowy może się zdarzać, że gdy sprzedajemy towar pochodzi on z różnych partii zakupowych, które mogą mieć różne ceny. Wówczas na przykład na potrzeby kalkulacji marży powinniśmy powiązać pozycje faktury z pozycjami dokumentów zakupowych. Oczywiście to powiązanie jest bardziej zasadne w dokumencie PZ. Dlaczego? To zostanie wyjaśnione w osobnym artykule.

Autor zdaje sobie sprawę, że powyższy artykuł nie wyczerpuje tematu. Żywi jednak nadzieję, że chociaż w pewnym stopniu będzie pomocny dla projektujących systemy biznesowe.