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

0

Ciężko doradzić, skoro programu nikt nie będzie używał, a od spraw księgowych chcesz być daleko.

Ale od początku: Jeżeli wydajesz coś z magazynu (WZ) to tam nie ma podatku, WZ nie jest dokumentem księgowym (poza wyjątkami), na podstawie WZ generujesz fakturę w której dopiero obliczasz VAT.
I teraz najlepsze VAT można policzyć na 3 sposoby (http://ksiegowosc.infor.pl/po[...]AT-podawanej-na-fakturze.html)...

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 :)

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?

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.

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.
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

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?

0

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

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

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

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