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

Odpowiedz Nowy wątek
2018-03-18 20:57
0

Ciekawy problem (sklep/hurtownia).
Powiedzmy, że jest tabela towary (ean, nazwa, cena).
Towary możemy kupować i sprzedawać po różnych cenach.
Mamy więc tabelę składowane_towary (ean, data_dodania, liczba_sztuk, cena_zakupu) //cena, po której towar został kupiony.
Przykład: kupujemy towary
Dnia 18/03/18 18:53:39,049 dodajemy towar 0001 w liczbie sztuk 30, cena zakupu 490 zł/szt.
Dnia 22/03/18 15:45:10,082 dodajemy towar 0001 w liczbie sztuk 50, cena zakupu 370 zł/szt.

Teraz sprzedaż. Raz wprowadzona do bazy cena zakupu jest stała. A cena sprzedaży w skrajnym przypadku może być inna dla każdego egzemplarza, jeżeli będzie się często zmieniać.
Jak zachować historię sprzedaży, np do późniejszego obliczenia jaki zysk wygenerował towar 0001? Muszę pamiętać liczbę sprzedanych sztuk, cenę zakupu i sprzedaży.

  1. Myślałem nad stworzeniem nowej tabeli i wrzucaniem do niej historii sprzedaży. A w tabeli składowane_towary zmniejszać liczba_sztuk po sprzedaniu towaru. Taka tabela szybko może się rozrosnąć, ale można zrobić miesięczne statystyki i inne bajery.
  2. Lub zamiast trzymania w tabeli składowane_towary dla różnych dat różnych cen produktów - przy dodawaniu jakiejś partii produktu który już jest w tabeli, obliczać nową średnią cenę zakupu dla wszystkich i trzymać ją w kolumnie. Trzeba by wtedy dodać kolumnę do sumowania zysku ze sprzedaży. Tu nie mam pełnej historii, ale tyle mi prawdopodobnie wystarczy + rekordów jest nie więcej niż produktów.
    Wyglądałoby to tak: (ean, liczba_niesprzedanych, liczba_sprzedanych, śr_cena_zakupu, całkowity_zysk).
  3. A może jeszcze inaczej?

Czy któryś sposób polecacie/odradzacie? Jak się to robi w profesjonalnych aplikacjach?

Pozostało 580 znaków

2018-03-19 13:34
0

Ja bym dorzucił unikalne '''ID''' dla dostaw na magazynie i te '''ID''' przenosił dalej do sprzedaży. Byłoby powiązanie bez przenoszenia jakichkolwiek informacji.
Kolejne co bym dodał to '''ilosc_przyjeta''' i '''ilosc_wydana''' na magazynie. Przy sprzedaży bym uaktualniał pole ilości wydanej, żeby dwa razy tego samego nie sprzedawać, plus to co niżej jeszcze.
Do tego można dodać statusy dostaw na magazynie, żeby było łatwiej odfiltrować to, które jeszcze nie zostały rozchodowane. Pomocne przy wyliczaniu ilości/wartości magazynu.

Do sprzedaży przenosimy tylko '''ID'' z magazynu i ilość przy okazji uaktualniając ilość wydaną w magazynie dla dostawy. Jeśli jedna dostawa to za mało to wstawiana jest kolejna pozycja tak aby wydać tyle ile chcemy po różnych cenach zakupu, gdzie cena sprzedaży jest taka sama dla różnych przyjęć tego samego towaru.

Ogólnie to temat bardzo rozległy. Taki zalążek systemu ERP :)

to unikalne id już jest - partia, magazyn ma stan aktualny, który powinien się aktualizować na podstawie ruchów magazynowych a nie ile było przyjęte i wydane (to jest na dokumentach) - abrakadaber 2018-03-19 13:38
Nie zauważyłem tej partii, moja ślepota :). A dalej to znaczy, że partia po sprzedaży w całości znika z magazynu? Nie będzie już wpisu? Bo ja to tak rozumiem w tej chwili. Wydaje mi się, że prościej jest uaktualniać ilość wydaną na partii i móc filtrować partie niż wiązać to jeszcze ze sprzedażą i dorzucić do tego status tej partii. - endrius 2018-03-19 14:02
nie bardzo wiem o co pytasz. Na tabeli z pozycjami może być trigger, który będzie stan magazynu aktualizował. Może to robić program albo stored proc - zależy od tego jak to sobie wymyślisz. Partia towaru (fizyczny rekord w tabeli magazyn), nawet ze stanem 0 powinna w tabeli zostać aż to inwentaryzacji - abrakadaber 2018-03-19 14:15
Powiedz mi w czym przeszkadza mieć dodatkową informację w tabeli partii, która by pokazała ile z niej zostało rozchodowane, bez sumowania wszystkich wydań? Tak jak napisałeś może być uaktualniane poprzez trigger. Będzie podana ilość z przyjęcia (która pojawi się w momencie załóżmy, że z dokumentu Pz). Jak robimy wydania to uaktualniamy konkretną partię. Gdy robimy inwentaryzację to nie będzie trzeba iść do pozycji, żeby sprawdzać ile na tej partii przyjęliśmy - endrius 2018-03-19 14:30

Pozostało 580 znaków

2018-03-19 16:39
0

Mówiąc o zmianie wysokości podatku miałem na myśli zmiany ustawowe.

Na razie zostanę przy tym co mam. Zgłębiając się w temat jest coraz więcej komplikacji papierkowych i niedługo wyjdzie na to, że muszę stworzyć klona Subiekta :P a chcę się skupić na innych bajerach do tej aplikacji. Bardziej chcę pójść w samą obsługę magazynu, niż szczegóły handlowe, dorzucić jakiś wewnętrzny komunikator i inne :)

Najostatniejsze pytania.

  1. Klientami mogą być firmy lub osoby fizyczne (w tym anonimowe).
    W takim przypadku trzymać wszystkich w jednej tabeli
    klienci(id, nazwa, telefon, email, adres, nip, typ_klienta)
    i wtedy
    w przypadku firmy w polu nazwa będzie jej nazwa, pole NIP będzie wypełnione.
    w przypadku osoby fizycznej w polu nazwa będzie jej imię i nazwisko (lub puste). NIP pusty.
    ?
    Czy stworzyć taką tabelę klienci
    klienci(id, typ) - gdzie typ będzie odsyłał do tabeli firmy/osoby_fizyczne?

  2. Jest jeszcze kwestia osób fizycznych. Co jest kluczem w sklepach internetowych, jeżeli nie wymagają peselu? Patrzę sobie teraz na jednym sklepie konto i obowiązkowe jest tylko imię, nazwisko i email. Jeżeli przyjmę tylko email za klucz, czy jest tu jakaś pułapka?

edytowany 2x, ostatnio: Potat0x, 2018-03-19 16:41

Pozostało 580 znaków

2018-03-19 16:51
0

1). Dorzuć ewentualnie pole pesel dla indywidualnych. Dla anonimowych możesz mieć klienta własnego jako np. Anonim, a adresy dla niego trzymać w oddzielnej tabeli z adresami
2). Przerabiałem ze sklepem internetowym i importem do systemu. Jeśli nie zakłada konta i dane wprowadza zawsze z ręki to może zrobić literówkę i będzie potraktowane jako nowy klient.

Pozostało 580 znaków

2018-03-19 17:00
0
  1. Czyli wszystko co jest klientem w jednej tabeli?
  2. Ok, mimo to u siebie też zrobię klucz-email. Nazwisko może się zmienić więc może być problem.
edytowany 2x, ostatnio: Potat0x, 2018-03-19 17:58
Adres możesz oddzielnie trzymać. Czasami jeden klienta zamawia na różne adresy - endrius 2018-03-19 17:01
Oddzielnie od czego? - Potat0x 2018-03-19 17:05
Główny adres trzymaj razem z kontrahentem. Adres dostawy trzymaj w oddzielnej tabeli - endrius 2018-03-19 17:21
Ok, ale jak to zorganizować, jeżeli nie chcę wymagać od klientów podawania PESELu? - Potat0x 2018-03-19 17:22

Pozostało 580 znaków

2018-03-19 17:34
1

Robisz tabelę w której masz id adresu dostawy, id klienta i adres dostawy, email. Dla firm zapisujesz w nowej tabeli i na poziomie sprzedaży wskazujesz gdzie ma być dostarczone. Jeśli adres dostawy jest taki sam jak firmy to można to pominąć.

Jeśli chodzi o indywidualnych to możesz mieć jednego klienta wprowadzonego jako ANONIM, INDYWIDUALNY i rejestrować tylko adresy dostaw w nowej tabeli i na tym się opierać do paragonu.Jeśli nie ma faktury to nie ma problemu. Jeśli klient zażyczy sobie fakturę to i tak musisz założyć klienta i jak chcesz to pesel możesz pominąć. Załóżmy, że klienta podaje do faktury adres Warszawa, ale chce dostarczyć towar do Krakowa. W tym wypadku masz w tabeli klientów wpis o kliencie Warszawa, a w tabeli adresów dostaw zapisujesz Kraków.

Na firmach to weź taką Castoramę. Faktura jest na centralę, ale dostawa na drugi koniec kraju. To jako przykład tylko

edytowany 1x, ostatnio: endrius, 2018-03-19 17:35

Pozostało 580 znaków

2018-03-19 17:59
0

Poza pierwszym akapitem rozumiem.

id adresu dostawy, id klienta i adres dostawy, email


Jeżeli chodzi o adres dostawy to nie ma problemu, mogę go dorzucić do tabeli zamówienia. Ogólnie jak teraz czytam wątek, to nie wiem dlaczego zeszliśmy na ten temat :P
Problem mam w tym: chcę jednoznacznie zidentyfikować osobę fizyczną nieanonimową bez znajomości PESEL, czy mogę to bezpiecznie robić za pomocą emaila.

I nowy problem.
Chcę rozdzielić składowanie towarów na wiele magazynów (budynków). Aktualnie tabela magazynowanych towarów tak wygląda:
magazyn(ean, partia, cena_zakupu, liczba_sztuk).//podkreślone klucze
Zamierzam dorzucić nr_magazynu (do klucza). Będzie ok?

edytowany 1x, ostatnio: Potat0x, 2018-03-19 18:01
Po email powinno wystarczyć. Chyba, że ktoś zrobi literówkę, ale na to nie masz wpływu - endrius 2018-03-19 18:01
nr_magazynu będzie bardzo dobry do tego. Tak w erp miałem - endrius 2018-03-19 18:01
Ok, dzięki :) - Potat0x 2018-03-19 18:03
Co do samego tematu to zaczyna to być taka rozbudowana magazynówka :P - endrius 2018-03-19 18:04
Tak, może jeszcze jakiś system alarmowy: uwaga sanepid :D PS: zakładam z tym dorzuceniem nr_magazynu, że towary z jednej partii mogą zostać rozłożone po różnych magazynach. - Potat0x 2018-03-19 18:08
Ja bym to tak rozbudował, że długo byś siedział z tym :P - endrius 2018-03-19 18:26

Pozostało 580 znaków

2018-03-19 20:32
0

Ok, wysmażyłem taki schemat. Wcześniej nie robiłem takich rozbudowanych. Ma to sens (klucze i relacje)?
titleasd

Klienci i dostawcy mogą być jako jedno. Dokładasz pole dostawca i odbiorca. I zero jedynkowo oznaczasz czy jest dostawcą czy odbiorcą albo jednym i drugim - endrius 2018-03-19 20:37
W czym to robiłeś? - endrius 2018-03-19 20:37
W sumie racja. Robiłem Paincie. Nie widać? :D - Potat0x 2018-03-19 20:39
Jest ok. W statusie zamówienia nie widać tekstu tylko :P - endrius 2018-03-19 20:41
Opiszę co bym zmienił w oddzielnym wpisie :) - endrius 2018-03-19 20:41
Tam jest tylko mała informacja dla mnie (oczekujące/odrzucone/zaakceptowane/zrealizowane). - Potat0x 2018-03-19 20:42

Pozostało 580 znaków

2018-03-19 21:02
1

Na początek to tak:
Tabela Kontrahenci (Dostawcy + Klienci)
Tabela Towary + tabela Towary_kontrahenci żeby zapisywać nazwy, ean itp towaru dla różnych dostawców i odbiorców
Dodałbym dodatkowo tabelę kartotek towarowych przypisanych do magazynów tj. Magazyn_kartoteki - nr_magazynu, id_towaru. Żeby określić ma którym magazynie konkretne id_towaru mogą być. To opcjonalnie tylko.
Tabela zamówienia: Zamówienia pobiera tylko kontrahenta z tabli Kontrahenci. Jest powiązana z Zamówione_towary. Zamówione_towary pobierają dane z tabeli Towary. Ilość i cenę z ręki.
Tabele Transakcje nazwałbym Dokumenty_spd. Pobiera dane z Kontrahenci. Nie wiem czy na nagłówku jest sens pobierania zamówienia. Jeśli to zawsze będzie jedno zamówieni, jeden dokument sprzedaży to może być. Ja bym przerzucił zamówienie do pozycji tj. Sprzedane_towary
Sprzedane_towary łączyłbym z Transakcje (Dokumenty_spd) i tutaj bym pobierał któej pozycji zamówienia to dotyczy ze względu na to, że jeden klient może mieć kilka zamówień.

W załączniku coś co na szybko zrobiłem

  • 111.png (0,03 MB) - ściągnięć: 39
edytowany 1x, ostatnio: endrius, 2018-03-19 21:33
Pokaż pozostałe 4 komentarze
Wcześniej o tym nie pisałem ;) - Potat0x 2018-03-19 22:46
Jeśli chodzi o tabele to Kontrahenci, Towary, Kontrahenci_towary zawierają dane, z których możemy korzystać dalej. Przykładowo wprowadzamy zamówienie: na nagłówku wybieramy kontrahenta z tabeli Kontrahenci, a na pozycjach towary z tabeli Towary. Przy robieniu przyjęcia możemy pobrać nazwę towaru dostawcy według naszego id_towaru i id_kontrahenta i to wpisać do tabeli Magazyn - endrius 2018-03-19 22:55
To jest bardzo spory temat i można opisać bardzo dużo zależności i dodatkowych funkcjonalności :) - endrius 2018-03-19 22:56
Temat chyba nawet zbyt spory jak na taką frytę jak ja :P Dzięki za pomoc. - Potat0x 2018-03-19 23:06
Dasz radę :). W miarę jak się robi to co chwilę coś nowego przychodzi do głowy :) - endrius 2018-03-19 23:21

Pozostało 580 znaków

2018-03-20 19:57
1

@endrius i tak nazewnictwo tabel jest z czapy :] Naprawdę uważasz, że SprzedaneTowary to dobra nazwa tabeli? Według tego nazewnictwa nie wiem gdzie miałbym umieścić zakupy, bo chyba nie w tej właśnie tabeli.... Należałoby zrobić tabele Dokumenty zawierające faktury zakupu, sprzedaży oraz DokumentyPozycje Analogicznie Zamowienia oraz ZamowieniaPozycje Ewentualnie DokumentyTowary oraz ZamowieniaTowary coby trzymać się konwencji.

Co ciekawe można na tabeli pozycji dokumentów warto trzymać sobie znacznik typu transakcji np:
1 - przychód
2 - rozchód
albo jeszcze lepiej po prostu znak w polu int:
1 - przychod
-1 - rozchód
Dzięki czemu bardzo prosto policzymy sobie stany na magazynie coś w ten deseń:

SELECT towar_id, SUM(znak*ilosc) AS stan FROM DokumentyPozycje GROUP BY towar_id
Pokaż pozostałe 12 komentarzy
Nie mniej jednak uważam, że w przypadku klasycznym dla początkującego moja wersja z jedną tabelą pozycji dokumentów jest ok :P - Mr.YaHooo 2018-03-20 20:31
Ja niczego nie neguję. Spójrz, że auto założył już tabelę z partiami :) - endrius 2018-03-20 20:36
Dla mnie rekordzistką byłą firma, która rozliczając produkcję potrafiła wygenerować korekt do dokumentów od 30 tys do prawie 100 tys :) - endrius 2018-03-20 20:37
Mi się wydaje, że jeśli chce się to później rozbudowywać to lepiej założyć tabele dodatkowe na kilkoma danymi tam przechowywanymi niż później tracić dużo czasu na generowaniu wpisów z już istniejących danych :) - endrius 2018-03-20 20:40
@endrius są firmy i firmy ;) Jeśli chodzi o postępowanie to nie wiem czy na początku drogi warto zajmować się takimi rzeczami jak nadmiarowe dane w tabelach pomocniczych zwłaszcza, że mam wrażenie, że autor nie jest zbyt zaawansowany. Ale jego wybór :) - Mr.YaHooo 2018-03-21 18:55

Pozostało 580 znaków

2018-04-08 22:52
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.

Na dokumencie jeszcze można by było dorzucić magazyn - endrius 2018-04-08 22:57
Też o tym myślałem, wtedy by nie było tej czerwonej relacji. A poza tym jest to akceptowalne? - Potat0x 2018-04-08 23:12
W sumie to jest dużo lepiej niż na początku :). Ja i tak obstaję przy swoim :P - endrius 2018-04-08 23:28

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

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