Sprzedawanie i kupowanie tego samego towaru po różnych cenach. Historia kosztów i przychodów.

0

Podszedłem do tego jeszcze raz i jest schemat jest prostszy niż poprzedni.
Tak jak poradził @Mr.YaHooo jedna tabela ze znacznikiem transakcji. +założenie jest takie, że użytkownik wystawia PZ i WZ.
Co sądzicie? Wydaje mi się, że niezbyt dobrze jest to zrobione.

0

@Potat0x jak dla mnie na początek starczy :)

0

Ostateczna wersja w załączniku, tym razem chyba jest ok. (jeszcze będę dorabiał komunikację między pracownikami, ale to już prosta sprawa).

I pytanie z innej beczki. Wnioskuję z tego co pisaliście, że w pracy macie np tabele "dokumenty" - czyli polskie nazwy. A kod jest po angielsku? Jeżeli tak, to czy są tam rzeczy typu getMiejscowosc, setJednostka? Wygląda to niefajnie. Widzę 2 sposoby na uniknięcie tego: pisać kod po polsku/przetłumaczyć nazwy w bazie na angielski. Najchętniej zostawiłbym bazę po polsku (specyficzne nazwy), a kod pisał normalnie po angielsku. Tylko to setPodatek, ble :/

0

Generalnie jest ok. Dopatrzyłem się tylko jednej rzeczy. Stawki VAT. Niech klucz główny będzie też sztucznym ID. Wtedy na pozycji dokumentów, kartotece towarowej, czy gdzieś indziej będziesz używać ID stawki VAT. Jestem zwolennikiem podejścia gdzie każdy PK powinien być sztuczny i kolumna typu int.

Co do nazewnictwa w bazie. To ja akurat mam w bazie nazwy PL. Tylko, że ja pracuję z kodem legacy, tak więc kod tez jest PL. Osobiście jakbym miał zaczynać nowy projekt wybrałbym całość w języku EN. Chyba, żeby to była wąska domena gdzie trudno się tłumaczy nazwy. Wtedy bym zostawił nazwy domenowe PL, reszta kodu EN.

0

Rola tabeli "Stawki VAT" miała być tylko taka, że będzie ładowana do comboboxa - ma tylko podawać użytkownikowi stawki do wyboru, a te będą zapisane jako wartość przy towarze.
To przetłumaczę wszystko. Przy okazji zmienię z VATem tak jak mówisz :)

1

Bardzo dobre rozwiązanie ze słownikiem. Ale sama stawka nic Ci nie da. W Polsce mamy 3 stawki zerowe:

  • 0%
  • ZW
  • NP

I w realnym świecie interesuje księgową ile było sprzedaży/zakupów NP, a ile ZW. Zatem musiałbyś trzymać oprócz stawki w procentach jej symbol. Łatwiej trzymać po prostu ID stawki ze słownika.

0

Do rejestru przedmiotów dodałem id stawki.
Do rejestru przedmiotów na dokumentach (pozycje) dodałem id stawki oraz jej wysokość na wypadek, gdyby się zmieniła w przyszłości.
Poprawiłem też relację towary/dokumenty_pozycje

0

Cześć wszystkim!

Chciałbym się podpiąć pod temat, bo mam dość podobny system ale nieco specyficzny i coś czuję, że się zamotałem.
Czuję, że gdzieś popełniam błąd. System działa ale...
Już mówię o co chodzi.
Część systemu który piszę, to magazyn blach.
Blachy przyjmowane są dokumentem pz (tylko i wyłącznie) którego nagłówek jest standardowy za to pozycje wyglądają następująco:

id_dok
nazwa_materialu //ze słownika
grubosc_arkusza //ze słownika
szerokosc_arkusza
dlugosc_arkusza
ilosc_arkuszy
cena_za_kg
nr_regalu //ze słownika
nr_polki //ze słownika

(myślę, że nazwy pól są na tyle opisowe, że nie wymagają komentarza)

te pozycje modyfikują bazę magazyn która ma strukturę

id
nazwa_materialu
grubosc_arkusza
szerokosc_arkusza
dlugosc_arkusza
nr_dostawy //zawarte w nagłówku pz-ta
cena_za_kg
nr_regalu
nr_polki
ilosc_arkuszy

Blachy wydawane są na podstawie rw (bardzo rzadko wz, ale jako że idea taka sama skupie się na rw)

Klient wystawiając dokument rozchodowy widzi stany magazynowe według powyższej specyfikacji, wybiera sobie blachę np alu, grubość np 7,5 mm, rozmiary arkusza np 1800x1200 mm - i to nie budzi wątpliwości. Następnie musi wybrać nr_dostawy (cena_za_kg jest z tym powiązana, to trochę pole nadmiarowe ale upraszcza zapytania), nr_regalu, nr_polki i jest wiersz rw-tki :)

Klient wolałby coby podał te dane oczywiste, a następnie ilość potrzebnych arkuszy (nie przekraczającą stanu mag arkuszy o danych parametrach, materiał, grubość, szerokość, długość) a system sam zaciągałby najstarsze numery dostawy i podawał mu z którego regału i półki ma zdjąć.
Nie widzę innej możliwości zrobienia tego niż chyba niezbyt eleganckie przejechanie pętlami bazy magazynowej i pozciąganie tego według jakiegoś narzucanego kryterium. Na przykład najstarsze dostawy, najdalsze regały, najwyższe półki.

Dobrze myślę? Czy można to jakoś uprościć.

Torin - zupełnie bez długiego weekendu :) :/

1

@Torin: Potrzebujesz funkcji, która by robiła rozchód według zadanych parametrów i powielała pozycje na dokumencie RW dla wybranych parametrów. Na pewno też przydałby się komunikat o tym, że jest mniejsza ilość niż ta którą chce rozchodować.
Np:
Chcemy rozchodować 15 kg o grubości 7,5 mm blachy. Mamy w tym momencie na magazynie 34 kg w 5 dostawach: 5,5,3,14,7. W kolejności od najstarszych. Czyli rozchodowując będziemy mieli pozycje z ilościami
5 - cała dostawa
5 - cała dostawa
3 - cała dostawa
2 - część z dostawy 14 kg.
Pracownik powinien wybrać tylko towar, grubość, rozmiary arkusza oraz ilość którą chce rozchodować (i co tam jeszcze przyjdzie do głowy, żeby zawęzić ilość dostaw). Dalej funkcja z automatu wyszukuje najstarsze dostawy i generuje tyle pozycji na dokumencie ile jest dostaw. Komunikat o braku ilości dla parametrów można dodać w momencie potwierdzania pozycji do dokumentu

Jeśli coś nie zrozumiałe to pytaj. Czasami potrafię się zakręcić z tłumaczeniem :)

0

@endrius Właśnie powoli siedzę i rzeźbie podobna funkcję.
W momencie wystawiania rw pacjent wybiera typ blachy, grubość i rozmiary (to ich interesuje) a system zlicza ile jest łącznie arkuszy o tych parametrach i nie pozwala wybrać większej ilości.
Potem iteruje po magazynie od najstarszej dostawy i regałów i półek.
Na razie schemat jest ino nie chce działać tak jak bym chciał. (funkcja tworzy się w php)
Idę się przewietrzyć i wrócę do tematu za chwile.
Dzięki za sugestie - zawsze to spojrzenie z boku otwiera klapki na oczach :)

Torin - idący się przewietrzyć ;)

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0